読者です 読者をやめる 読者になる 読者になる

技術書典2 振り返り

4月9日にアキバ・スクエアで開催された「技術書典2」にサークル「ふぃーるどのーつ」で参加してきました。

techbookfest.org

techbookfest.org

電子書籍(PDF)版は、booth.pmで販売しています。

fieldnotes.booth.pm

当日は雨天で足下の悪い中、3100人以上の一般来場の方にお越し頂き、当サークルも、印刷所への発注数の殆どを売り切るという、望外の結果に恵まれました。ブースにお越しいただいた皆様、厚く御礼申し上げます。

時系列別振り返り

2016-12~2017-1
  • 2016-12 知識のアウトプットの形式として同人誌を考え出す。コミケを見に行く。
  • 2017-正月 技術書典2の開催を知り、参加を考え出す。主催のtechbooster (以下てくぶ)の中の人に威嚇(?)いいねされる。

twitter.com

  • 2017-1-4意を決して申し込む。

twitter.com

  • 2017-1-7(正月休みの後の三連休) 原稿のgitレポジトリーをBitbucketに作成する
  • 2017-1-9 markdownからpandoc+lualatexでPDFを作成してDropboxにデプロイする仕組みをBitbucket Pipelinesに作成して悦に入る。
  • 2017-1-16 参加当選が決まる。コミケで噂に聞く壁サークルの配置と言うことを知りビビる
  • 2017-1 中旬~下旬 このブログの記事をブラッシュアップしてコンテンツにすることを決め、執筆を進める。
2017-2
  • 2017-2 上旬 他のプライベートのことを考えると2月中には執筆の大枠を固める必要があるとの見込みの元、ひいひい言いながら執筆する

twitter.com

  • 2017-2-5 「技術書典2 技術書の作り方勉強会 ~執筆環境をワイワイはなそう~ 」に参加する。てくぶの「技術書をかこう! ~はじめてのRe:VIEW~」を購入する。

techbookfest.connpass.com

techbooster.booth.pm

  • 2017-2-5 ノリと勢いでコミケ92(夏コミ)に申し込む。
  • 2017-2 中旬 この頃から意に反して仕事が忙しくなり始める。
  • 2017-2 下旬 「Pactではじめるコンシューマー駆動契約」の技術検証がうまく進まずに行き詰まる。1マス戻る。

twitter.com

  • 2017-2-26 「技術書典2 もくもく執筆レビュー会 ~進捗はそこにあるか~ 」に参加する。レビュー会と帰宅してから技術検証を続けた結果、技術検証が終わる。2マス進む。

techbookfest.connpass.com

twitter.com

2017-3
  • 2017-3-上旬 いよいよ仕事が忙しくなり、職場で暗黒オーラをまき始める
  • 2017-3-9 「まべ☆てっく vol.3」で宣伝LTをする。ちなみにこの段階で「テストと『品質』」はまだ書き上がっていない。

marv-tech.connpass.com

  • 2017-3-20 一通り書き上がる。校正・レイアウト等の作業に入る。計画からは一週間遅れ。
  • 2017-3-21 POP立て等の必要な資材を買いそろえる。
  • 2017-3-27 他の私用のため有給を取っていたがその予定がキャンセルになったので、終日レイアウト作業に費やす。
  • 2017-3-28 入稿する。
  • 2017-3-31 「来月もプレミアムに過ごすためのインフラ構成管理ツール入門編」でLTをする。その中で技術書典2の宣伝もする。

techcircle.connpass.com

2017-4~当日
  • 2017-4-1 ブースに必要な資材の買い出し、キンコーズでダウンロードシリアルを印刷したペーパーの用意など。 告知エントリーを作成する。
  • 2017-4-2 電子書籍版(PDF)の用意。結局この後前日まで細部の調整でPDF版の再作成を繰り返すことになる。
  • 2017-4-4 ダウンロードシリアルのペーパーにURLのQRコードを掲載した方が便利なことに気づき、キンコーズで再度作成
  • 2017-4-7 一応出社していたのですが、心ここにあらず
  • 2017-4-8 サポートページのエントリーを作成して予約投稿をかける。
  • 2017-4-9 当日を迎える

雑感

スケジュールについて

印刷所の期限のだいぶ前に入稿していますが、これは自分のスケジュールが

  • 開催の前日(土曜)はプライベートの都合で準備に時間を割けない
  • なので、その前の週の土日をブースの準備に使う必要がある
  • ということは、その前に入稿しておく必要がある

ということで、このようなスケジュールになっています。もう数日少し遅らせておけば細部のクオリティーをあげられたのではないかというのはあるのですが、その時期は業務の方の稼働もいっぱいいっぱいだったので、これはこれでよかったと思います。炎上案件良くない。

入稿

てくぶ様の方でRe:VIEWでPDF入稿のテンプレートを作っていただきましたが、今回は作業環境がWindowsだったとか、その当時だと、PDF/Xのフォーマットとかフォントの埋め込みのところがちんぷんかんぷんだったとかあり

  • markdownで書いた原稿を Pandoc - About pandoc でLuaLatexでtexに変換し、そこからPDFを生成
  • 生成したPDFをプリンターで漫画用原稿用紙に出力し、版下を入稿

というプロセスでやっています。この手順だと、極端な話原稿用紙のコーナートンボの内側に文字が出力されていれば入稿できるのと、入稿時に印刷所の店員さんに版下をチェックして貰えるので、データをアップロードしてから差し戻し→修正の手間を踏まずに済んだのはよかったと思います。ただ、仕上がりのきれいさはやはりPDF入稿のほうが優るので、次回からPDF入稿を検討したいです。

markdownをBitbucketにpushするとBitbucket PipelinesでCIが実行され、作際されたPDFがDropboxにデプロイされるということをやっていたのですが、主にフォントの埋め込みの関係で、最終工程はWindows上で作成しています。LuaLatexの仕様上はコマンド実行時のカレントディレクトリーにフォントのttfファイルを置けば認識できるのですが、リモートのCI環境でそれをやるのはライセンス上アレでソレなもので。ちょうど開催直前にAdobeオープンソースの「源ノ明朝」フォントをリリースしたというニュースが出たので、次回はそちらを使ってCIでの入稿PDF作成にチャレンジしたいです。

forest.watch.impress.co.jp

あと表紙作成時にテンパっていて表紙のフォントはメイリオなのですが、クリアPPの明るさとマッチして意外と悪くないです。とはいえ、このようなイベントではどれだけ目立つかが勝負なところがあるので、表紙にはもっと力をいれるべきだと思いました。

釣り銭

当日、他のサークルさんでこんな話がありました。

実は当サークルでも釣り銭が足りなくなり、早々に売り切れて店じまいした隣のサークルに両替してもらって窮地を脱したという一幕がありました。(docker-machineさんありがとうございました)。釣り銭は500円玉を10枚用意していましたが、訓練されたコミケ参加者のように500円玉を束で持ってくるのかと思ったら思いの外札での支払いが多く、足りなくなったという…。当日の売り上げ実績だと500円玉が20枚は必要のようです。ただこれで1万円になるので、個人が用意する額としてはこれが限界ですね。

サンプルコード

今回、「Pactではじめるコンシューマー駆動契約」内の記述の進行と、GitHubに公開しているサンプルコードのコミットが連動しているという試みをしています。よく頑張った。褒めて欲しい。

github.com

サポートについて

てくぶさんが開催された事前の勉強会に参加しました。サークル出展ははじめてで勝手がわからないところがあったので、情報や雰囲気が色々知れてよかったです。また公式サイトでのサークルリスト関連の機能など細かくサポートしていただき、ありがたかったです。

techbookfest.connpass.com

後、持ち込む冊子数をどれくらいに見込むかですが、「techboosterの見込み数×(自サイトのサークルチェック数/techboosterのサークルチェック数)」というのが、技術書典では一番正確に見積もれるようです。

あと、今回の技術書典2にも参加されていたid:kakkun61の以下のエントリーは大いに参考になりました。

kakkun61.hatenablog.com

kakkun61.hatenablog.com

収支

収支ですが、以下の通りです。

売上
項目 単価 売上数 売上金額
冊子 500 143 71500
出費
項目 金額
印刷費(B5・40ページ×150部) 18140
参加費 7000
備品・文具 7041
コピー代(ダウンロードのペーパー用) 5553
Adobe Creative Cloud(Acrobat) 20476
typekit ポートフォリオプラン※ドル決済のため概算 5850
合計 64060

ということで、差し引き7000円強の黒字ということになります。はじめてのサークル参加で赤字にならなかったので、収支面では望外の結果となりました。

なお手元に、技術書典2の参加が決まった直後に気が大きくなって買ったQHDモニターの領収書があることを申し添えておきます。

最後に

今回このような形で自分の知識をまとめて発表する機会を得ることができ、大いに得るものがありました。また当日も楽しませていただきました。次回技術書典が開催されたらまた参加を検討したいと思います。

主催のtechboosterさん、印刷・製本の日光企画さん、サークル参加者および一般参加者をはじめとして関係者のみなさん、ありがとうございました!

2016年を振り返る

お仕事

前半はBlue-Green Deploymentの導入やっていた。技術的には去年やっていたことの焼き直しだったので、モチベーション的には苦しいものがあったが、何とかかたちになるアウトプットを出せたと思う。

twitter.com

転職してから丸三年になりますが、同じお客様を担当して四年目に突入することになりました。SIの世界では結構異例なことですが、ありがたいことだと思います。

その一方で、春からは社内の他の案件の支援も担当することになった。来年も頑張る。

コミュニティー活動

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

主催
  • BDD in Action読書会

アウトプットを一段上のレベルに出そうとして、講演では色々チャレンジした。その結果として消化不良気味になったものもあるが、次につなげていきたい。

趣味

  • miwa「miwa “ballad collection” tour 2016 ~graduation~」3公演
  • いきものがかり 「超いきものまつり2016 地元でSHOW!! 〜海老名でしょー!!!〜 / 〜厚木でしょー!」 3公演

まとめ

もう若さまかさでどうこうする年齢でもないですが、一日一日を健康を大事にして、明るく楽しく生きていたい。

Bitbucket PipelinesとBambooのブランチモデルの違いに見るデプロイ戦略の構造

このエントリーは、Atlassian User Group Tokyo Advent Calendar 2016 - Qiitaの23日目エントリーです。

qiita.com

2016年10月に開催されたアトラシアンサミットソースコードホスティングサービスBitbucket Cloud継続的インテグレーション(CI)によるビルド・デプロイを統合した新サービス、Bitbucket pipelinesのサービスインが発表されました。

Bitbucket Pipelinesは、Bitbucket上で管理されているソースコードにビルド設定を記述したbitbucket-pipelines.yml()をコミットすると、Bitbucketへのソースコードのpushをトリガーとしてビルド及びデプロイを実行するというサービスで、Travis CIを始めとするGitHubに統合されたCIホスティングサービスと同様のサービス形態になっています。また、本年12月一杯までは無料で使用できます(2017年1月以降は1セント/1分の予定)。

Bitbucket Pipelinesの特徴としては、以下の四点が挙げられます

  • Bitbucket Cloudとの統合
  • DSL(bitbucket-pipelines.yml)でのビルド記述
  • Dockerベースでのビルド環境
  • プルリクエストベースでのビルドフロー

このエントリーでは、同じくアトラシアン社のオンプレミスでのCIパッケージであるBambooと比較した場合に大きな特徴となる、プルリクエストベースでのビルドフローについて、Bambooとの比較をしながら、述べていきます。このエントリーで試用したサンプルはBitbucket上で公開しています

プルリクエストベースでのビルドフロー

Bitbucket Pipelinesでは、bitbucket-pipelines.yml上での記述により、ブランチごとにビルドの設定をカスタマイズすることができます。

Bitbucket Pipelinsでデプロイを行うには、デプロイの対象となるブランチに対して、プルリクエストを作成します。例えばbitbucket-piplelines.yml上で、masterブランチをビルドした際に本番環境へデプロイを行うように記述されている場合、本番環境へのデプロイを行う場合には、masterブランチに対して、プルリクエストを作成します。

f:id:setoazusa:20161223213713p:plain

f:id:setoazusa:20161223220216p:plain

これは、GitHubに統合するかたちでのCIサービスで広く採用されているワークフローと同様なっています。これに対してBambooのデプロイは、それぞれのブランチのビルドを起点としてリリースを作成し、そのリリース内の成果物(artifafct)を各環境にデプロイするワークフローとなっています。

プルリクエストでのデプロイの特徴

プルリクエストを中心としたワークフローベースのデプロイの特徴としては、やはりワークフローが簡潔となることが挙げられます。どのような手順を踏めばデプロイされるかということが、「masterブランチにブランチをマージすれば本番環境にデプロイ」されるというように明快になります。また、ワークフローが単純になることのメリットとして、チャットを運用のワークフローに組み込む、ChatOpsへの親和性も高くなります。

これに対するデメリットは、ブランチのビルド設定とデプロイのワークフローを結びつけたことにより、一つの環境にデプロイされるのは特定のブランチの最新ビルドとなることがあげられます。これに対し、BambooのようにCIのビルドからリリースを作成するデプロイの場合は、任意ブランチの任意ビルドがデプロイ可能です。

今のプロジェクトで、releaseのブランチがリリース準備の作業中の時に、本番環境で緊急に修正を要する障害が発生した場合のデリバリーのワークフローの検討を行ったりもしたのですが、こういう場合はやはりBambooのようなリリースとブランチが疎結合になっているモデルのほうが都合が良い、と考えます。

また、リリース時に問題が発生し、一個前のバージョンに戻す、いわゆる「切り戻し」を行う場合は、プルリクエストベースのデプロイの場合は、

  • リリース内容をrevertするコミットを作成して再度プルリクエストを作成する
  • リリースブランチをリリース前のリビジョンでハードリセットする
  • immutable infrastructureにして一個前のインフラ構成に戻す

のいずれかの手順を踏むことになります。

これに対して、Bambooのようなリリース内の成果物をデプロイする場合は、CIサーバー上で一個前のバージョンのリリースをデプロイすることによって、切り戻しを行う事ができます。

また、複数モジュールからなるシステムを構築する際、モジュールが親モジュール(いわゆる「共通モジュール」)と子モジュールに別れている場合に、Bambooではブランチごとに独立してビルドの依存関係を持たせてビルドチェーンを構築することができますが、Bitbucket Pipelinesではそのような機能を有していません。

まとめ

このようにBitbucket PipeliesのようなプルリクエストベースのワークフローとBambooのようなリリースベースのワークフローを比較した場合に、プルリクエストベースでのデプロイの特徴としてあげられるのは、パイプラインがバージョン管理システム(VCS)のブランチと密結合になるかわりに、身軽さを得たワークフローだということです。このようにデプロイのワークフローについての設計思想がBambooと根幹から違うため、Bitbucket PipelinesはBambooの代替にそのままでなるものではなく、実際Bambooにも新機能の追加は活発に行われていますので、ワークフローに対して求められる厳格さに応じて、しばらくはBitbucket PipelinesとBambooの棲み分けが続くと考えられます。

参考

私といきものがかり

このエントリーは、いきものがかり Advent Calendar 2016 - Adventarの20日目エントリーです。

www.adventar.org

さて明日12/21*1は、2016年8月と9月にいきものがかりの地元と海老名と厚木で行われた屋外ライブ「超いきものまつり2016 地元でSHOW!!」のブルーレイ発売日ですね。みなさんこのエントリーを読んだらブルーレイをポチるのですよ?

えっ、DVDプレイヤーしかない?いえいえ、世界で一番可愛い32歳こと吉岡聖恵さんのお姿を堪能するにはブルーレイじゃないと駄目です、プレイヤーも一緒にカートにいれてくださいw

...という振りはさておき、いきものがかりの魅力と言えばライブです。ステージを所狭しと走り回るパフォーマンスに、楽曲だけでなくMCでも観客を魅了する姿。いきものがかりの公演って週末公演や地方公演だと開演から終演まで3時間くらいかかるのが*2通常です。で、そのかなりの時間がMCなのですが、自分も他のアーティストのライブに行くようになって気づいたのですが、アーティストがみんなMCに多くの時間を割くわけではないらしいのですね。後MCでリード役をつとめるリーダー水野良樹さんの自虐ネタのトークも見物です。

さて、このアドベントカレンダーの作成者である (id:noobow34)の私といきものがかりの6年間 - ぬぼろぐにならって、私のいきものがかりライブ参戦歴を振り返ってみたいと思います。ちなみに私のものぐさな性格を反映して参戦歴を洗い出すのに、Twitterの過去つぶやきやらgoogleカレンダーやらmixiのつぶやきやら日記やらカレンダーやら掘り起こして大捜索になりましたが、色々と昔のことも思い出してきますね。

2009年

2010年

このころからチケットの取りやすさ等の関連で地方公演が増えてますね。ちなみに沖縄公演はファイナルの予定だったのですが、チケット二重発券の振り替え公演の影響で幻のファイナルになったことは尾を引き、いきものがかりの公演のファイナルに立ち会うのは2016年まで待つことになります。ローチケ許すまじ

2011年

この年のいきものがかりと言えばハマスタ公演ですが、広島でのファンクラスライブの時に私、仕事の関係で「夜公演終了(広島)→最終の新幹線で大阪→一泊→翌朝の始発新幹線で東京へ→会社のロッカーで背広に着替えて出社」というのをやっているのですが...何をやりたかったのでしょうね、私。

2012年

twitter.com

www.instagram.com

遠征はいいぞ。

2013年

この時期仕事が大炎上している中転職活動もしつつ、miwaもふくめると4ヶ月でライブ6本行っているのですが...我ながらこのパワーはどこから出てくるのでしょうね。

2014年

ライブツアーなし

2015年

この年はこれでしょうね。人生の運を使い切ったと思った。*3

twitter.com

2016年

いきものがかり10周年イヤー。開演前から降り続く本降りの雨のためずぶ濡れ、泥まみれの最悪のコンディションになった海老名初日が思い出深いです。

twitter.com

2017年

まだまだ続くよ!

*1:担当日基準

*2:平日の公演の場合は観客の帰りの便を考えて、若干つめる

*3:この時のライブは座席券が当日発券のため、席が決まるのは当日

Gebでインフラをテストする。

Geb Advent Calendar 2016 - Qiitaの12日目エントリーです。

qiita.com

先日の「JJUG CCC 2016 Fall」で「実録Blue-Green Deployment導入記」というテーマで発表しましたが、その中でインフラ観点でのシステムテストにGebを活用した事例の紹介をしました。

インフラのテストの観点の特徴としてあげられるのは、最終的な動作の確認をアプリケーション層に依存することがあげられます。

  • 設定ファイルの項目の確認
  • アプリケーションのプロセスが起動しているかの確認
  • ヘルスチェックのURLにアクセスして行う疎通の確認
  • サーバーおよびネットワーク機器間の疎通の確認

という観点まではServerspec等を用いたテストが可能ですが、それより上位レベルの観点はデプロイしたアプリケーション上の動作で確認することになります。

このような場合、インフラ側のテスト担当者が

  • アプリケーション側の機能ドキュメント、テストケース一覧
  • 過去のインフラ観点でのテストケース
  • インフラ側のテスト担当者の勘

などを参照して、テストケースを作成します。

ですが、

  • アプリケーションの規模
  • サーバーやネットワーク構成
  • 外部との連携先

などの構成が複雑になるにつれ、インフラのテスト担当者がアプリケーション観点でテストケースを作成することへのハードルはあがってきます。

また、この事例で取り上げたシステムの場合、システムが

  • 「エンドユーザーからのアクセスを受け付けるモードか」(主系)
  • 「動作確認のためのアクセスを受け付けるモードか」(副系)

の二つのモードをもっており、その結果として

  • Blueサーバーが主系の場合のBlueサーバーへのアクセス
  • Blueサーバーが主系の場合のGreenサーバーへのアクセス
  • Greenサーバーが主系の場合のGreenサーバーへのアクセス
  • Greenサーバーが主系の場合のBlueサーバーへのアクセス

で、一つのテストパターンについて、都合四通りのテストの組み合わせを実施することになりました。

そこで、この事例ではアプリケーションの観点から見たインフラのテストについて、全面的にアプリケーションの開発チームがGebによって作成したエンドツーエンドのテストを使用することになりました。エンドユーザー側から見た、アプリケーションの機能および外部サービスへの連携について、構築した環境上でGebによるエンドツーテストを実行し、その結果を確認することで、インフラ観点でのシステムテストを行うわけです。

このことによって、

  • テストケースの作成コストの削減
  • テストケースの網羅度、信頼性向上
  • 組み合わせでテストを実行する場合の、実行コスト削減

という効果を得ることができました。

エンドツーエンドのテストを実装する場合、その効果はアプリケーションを開発する側のアプリケーションの修正に関わるコストの範囲内で語られがちです。しかし、エンドツーエンドの自動テストである程度の網羅性を担保することによって、インフラ側のテストの効率や精度の向上にも寄与することができる、というのが今回の事例で得られた知見です。

テスト自動化あれこれ

ソフトウェアテスト Advent Calendar 2016 - Qiitaの9日目エントリーです。

qiita.com

エラーが「自動的に」増殖するのがDevOps

継続的デリバリーの核心は、フィードバックのサイクルを素早く回すことにありますが、それはユニットテストカバレッジが十分になければ不可能です。 A/Bテスト、オートスケール、カナリヤテスト、Blue-Green Deploymentなど、DevOpsを推進する上での各種プラクティスは、いずれも、プロダクトの品質が安定していることを前提としています。品質が安定していない状態でリリースサイクルを早く回してもバグが素早くデリバリーされるだけです。

サービス開発は、開発者だけで行うものでなく、プロダクトオーナー、QAエンジニア、インフラエンジニア、運用エンジニア、リモート開発チームなど、多数のステークホルダーが協調して行うものです。チーム相互の信頼をもたらすために必要なのは安定したプロダクトの品質であり、継続的インテグレーション(CI)を軸としたデリバリーのワークフローの確立のためには、自動化されたテストが足場として必要です。

迅速なサービス開発の手助けにならない自動化テスト

翻って現場に目を向けたときに、最近複数の現場で見聞きするのは、

  • 必要とするミドルウェアや連携先サービスとの関係でテストがモックだらけになり、ユニットテストの可読性や保守性があがらない
  • それを補完すべくエンドツーエンドのテストに取り組んでいるが、テストケースが増えてきてメンテナンスコストや実行コスト(時間)が増大している

というものです。各種パブリッククラウド上でのサービス構築に代表されるように、システムを構築し、テストを実装するときに依存するサービスやミドルウェアが増えたこと、そしてマイクロサービスアーキテクチャーがその流れを加速しています。

それに対して、テストをはじめとして開発の方法論はいわゆる三層アーキテクチャーにいまだに最適化されており、そのことが自動テストの普及の妨げになっています。

テスト自動化ピラミッドとサービステスト

Mike Cohnは書籍「Succeeding with Agile」の中で、テスト自動化の戦略をレイヤーを「UI」「Service」「Unit」の3つに分類し、「テスト自動化ピラミッド」と命名しています。「Unit」の層はいわゆるユニットテストに相当し、「UI」の層はエンドツーエンドのテストに相当します。このピラミッドの特徴は「Service」の層にあって、アプリケーションのインターフェースに対するテストを、UIを迂回して実行することです。

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

Succeeding with Agile: Software Development Using Scrum (Addison-Wesley Signature Series (Cohn))

f:id:setoazusa:20161208200716p:plain

*1

このピラミッド自体は一種の概念モデルですが、Sam Newmanは書籍「マイクロサービスアーキテクチャ」の中でこのモデルに着目しています。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャーにおけるサービステストとは、外部のサービス呼び出しをモック化した上で、個々のサービスの機能に対して、UIを迂回してテストを実行します。このことにより、ユニットテストよりも広い範囲をカバーするテストを、エンドツーエンドのテストよりも安定かつ高速に実行できることを目指しています。

f:id:setoazusa:20161208200648p:plain

*2

まとめ

方向性としては、システムのコンポーネント間の関係、規模など、複雑度が増大するに伴い、自動化されたテスト、手動で行うテスト双方とも、レイヤーの分割を細かくして、テストのどこのレイヤーでどの品質を担保していくかを事前に設計した上で開発に望んでいくということになります。我が国では業界の生い立ちや歴史的背景から、ソフトウェア開発の職種とソフトウェアテストの職種の相互交流はまだはじまったばかりですが、開発エンジニアとテストエンジニアが共通の言語で会話しながら、システムの品質に対する責任を相互で分担できる未来が来ることを望みます。

*1:Mike Cohn(2010)「Successiding with Agile」312ページより

*2:Sam Newman著(2015)・佐藤直生監訳「マイクロサービスアーキテクチャ」160ページより

JJUG CCC 2016 FallでBlue-Green Deploymentの導入について発表しました #jjug_ccc

2016/12/3に開催されたJJUG CCC 2016 Fallで「実録Blue-Green Deployment導入記」というテーマで発表しました。

講演中でもちょっと触れたとおり、案件での事例に特化したセッションですので、皆様の現場で一般的に使えるノウハウではないかもしれません。

ですが、セッションで挙げた三つのテーマである

  • サイトの切替にDNSを使う場合の接続元クライアントの挙動の制御
  • データベースの取扱い
  • Blue Greenの稼働系を切り替える場合の切り替え手順の考慮

については、サービス無停止でリリースを行う上で、どこでも考慮が必要になるポイントだと考えています。

質疑応答で、「Blue-Greenの切替時に処理途中で処理する稼働系が切り替わるようなケースがないのか?」という質問がありましたが、この事についてうまく回答ができなかったので、この場で補足をいたします。

例えばGreenサーバーに新しいバージョンをデプロイしてBlueサーバーからGreenサーバーに稼働するシステムを切り替える場合、Greenサーバーではセッション中で説明した通り、テスト用のグローバルIPアドレスを使って動作確認済み(スライド内で「副系」と読んでいるもの)ですので、Blueサーバーへのリクエストが途中でGreenサーバーに乗りかわるのは問題ありません。問題となるのは、Greenサーバーへのリクエストが途中でBlueサーバーに移行するようなシーケンスが発生すると、機能的に一個前のバージョンとなりますので、例えば呼び出し先のAPIがないなどの問題が発生します。

このことに対応するために、切替元となるBlueサーバーの随時バッチが起動するサーバー(スライド中の「データ連携サーバー」と呼んでいるもの)のプロセスを切替時にいったん停止する手順を入れています。(発表スライド中の以下のページなります。)このことによって、切替時にGreenサーバー(切替先)へのリクエストが途中でBlueサーバー(切替元)に乗り変わることを防いでいます。

スライドの最後で「日本のDevOpsはSIがリードする」なんていう大風呂敷を広げましたが、これについて。各種ソーシャルメディアで現場に対するネガティブな面を振りまくのは言論の自由の範疇ですが、最近、何か事をなし得たというエントリーに対して、揚げ足を取ったり話の腰を折ったりするコメントが多すぎます。ストレスの捌け口というのも必要でしょうし、キャリアの浅さやスキルの至らなさで自分のやりたいことが実現できない現場にいる方もいらっしゃるでしょうが、もうすぐ40代の自分たちの世代は、現場と業界をどうやればよりよくできているかが求められる役割なので、それが後の世代への責任ではないのかと。自分が2年前のJJUG CCCで言った「ミッションを共有するする仲間が集うコミュニティーで、プログラマーが一人一人知恵を持ち寄り、議論し、勇気づけるときに、世界はかわる、そう思う。」を、自分はまだ取り下げるつもりはないです。

JJUG CCCが終わって感想ですが、ここ2年ばかりかかり切りだった案件の成果を世に発表できたので、今は安堵しているところです。

最後になりますが、

  • 発表の機会をいただいたJJUGのみなさま
  • スライドのレビューをいただいたプロジェクト関係者
  • 発表リハサールに立ち会っていただいた弊社同僚

以上のみなさま、ありがとうございました!