継続的デリバリ／デプロイを実現する手法・ツールまとめ：DevOps時代の開発者のための構成管理入門（終）（2/2 ページ）

注目を集める継続的デプロイメントの手法「ブルーグリーン・デプロイメント」「Immutable Infrastructure」

　さて、その継続的デリバリの構成要素の中で、継続的デプロイメントの手法として「ブルーグリーン・デプロイメント」や「Immutable Infrastructure」（もしくは「Immutable Server」）が注目を集めています。

ブルーグリーン・デプロイメントとは

　ブルーグリーン・デプロイメントでは、まずブルーとグリーンという2つの環境を用意し、ルータやロードバランサの振り向け先をどちらか一方に割り当てておきます。現在のブルー側でサービスが稼働してるとすると、新しいアプリケーションをデプロイする時にブルーで動いているアプリケーションを置き換えるのではなく、もう1つの環境（グリーン）のアプリケーションを更新して、ルータやロードバランサの振り向け先をグリーンに振り向けることでバージョンアップを行うというものです。

　問題が発生した場合は、ロードバランサの振り向け先を戻すだけで済みます。また次にリリースするときはグリーンとブルーを入れ替えます。

Immutable Infrastructureとは

　Immutable Infrastructureは、このブルーグリーン・デプロイメントを一歩進めたアプローチの1つで、「1度構成したサーバには2度と変更を加えない」という考え方です。もし何らかの変更を加えたい場合には、全く新しい環境を立ち上げて、そこに新たな変更を加えるというものです。

ブルーグリーン・デプロイメントとImmutable Infrastructure

　以下の図は、おのおのの手法において、サービスを提供する「アクティブ」な環境がどう切り替わるのかの違いを表しています。

ブルーグリーン・デプロイメントとImmutable Infrastructureのイメージ

　先に紹介したChefなどのサーバ構成ツールには「冪等性」という考え方があり、何度適用してもある状態に収束するという特性があります。しかしサーバは長時間運用されていると、突発的な対応を行うこともあって、現実問題としてその状態が分かりにくくなるという傾向があります。

　また、例えばこれまで使っていたAというパッケージが不要になった場合、「Aが存在しないこと」という設定を構成管理ツールに追加して適用しないといけなくなりますが、得てして設定の複雑化を招きます。こういったことが積み重なると、長時間動いているサーバと、新たに作ったものに本当に違いがないのか分からなくなります。代わりに全く新しく環境を立ち上げることで、常に稼働しているサーバの状態に対して確信が持てるようになります。

Immutable Infrastructureを実現するためのツール

　そういったImmutable Infrastructureを実現するためには、新たな環境を素早く立ち上げられることが求められます。そのためにサーバ構成管理ツールと協調してOSイメージを簡単に作るためのツールとして「Packer」などが注目を集めています。

　サーバ環境をテストするための「serverspec」などのテスティングツールも整備されてきており、これらのツールを組み合わせることで、例えばChefなどの構成管理ツールの設定に変更がなされたら、CIで自動的にイメージを作成しテストも実行する、といったところまで自動化が可能です。

　また環境の立ち上げ時間そのものに着目すると、例えばAWSのようなハイパーバイザ型の環境は、新たに立ち上げるための時間がそれなりにかかります。それを解決するために、「例えばAmazon EC2インスタンス上に、『Docker』などのツールでコンテナ型の仮想環境を構築することで、より迅速なImmutable Infrastructureが実現できるのではないか」といった議論もなされています。

ヌーラボにおける継続的デリバリの事例

　ここからは実際に先に述べたツールなどを活用して、ヌーラボで取り組んでいる継続的デリバリの例を紹介します。

• Webアプリケーションの自動デプロイ
• ドキュメントのBTS上へのアップロード

　前者は継続的デリバリで最も一般的に取り上げられるもので、読者の皆さんにもイメージしやすい例でしょう。

　開発者は、ソースコードを修正してリポジトリにコミットします。コミット後、CIサーバがそのコミットを検知して、ユニットテスト（単体テスト）やステージング環境へのデプロイを自動的に行うよう設定しています。ユニットテスト時には、AWS上にインスタンスを動的に構築して、そのインスタンス上でテストを行っています。ユニットテスト用のインスタンスはAnsibleで構築しています。

　ユニットテストが正常に完了すると、自動でステージング環境へデプロイされます。ステージング環境での確認で問題がなければ、本番環境へ修正内容を反映します。これらはJenkins上で設定しており、技術者だけではなく誰でも実行できます。

　また、複数のサーバに対してのデプロイは、Fabricを用いて1コマンドで実行できるようにしています。

ヌーラボでの継続的デリバリ

　また、連載第4回の事例紹介でも触れましたが、いわゆるプログラム的なソースコードだけではなく、ドキュメント類も継続的デリバリの管理対象としています。

　技術者はSphinxやMarkdown記法でドキュメントを記載し、そのドキュメントをコミットします。その後、CIサーバ上でSphinxなどの一次ドキュメントからHTMLを生成した後、そのドキュメントに携わる人がアクセスしやすいようにBTS上へアップロードしています。これも大きな枠で捉えれば、継続的デリバリの一種といえるでしょう。

デリバリをユーザーに意識させない

　実運用を始めたサービスでは、デリバリに際して極力ユーザーに影響を与えないようにすることが重要です。極端な例ですが、1日に100回デリバリできるような体制を整えても、デリバリのたびにサービスを一時停止するようでは常用するには不安があるサービスといえるでしょう。

　最初に検討すべきなのは、サービスを停止させないでデリバリできるようにすることです。ヌーラボでは、アプリケーションサーバを複数台構成にしておき、それぞれに対して順次に更新を掛けていくことによって、無停止でのデリバリを実現しています。その際、「Nginx」からアプリケーションサーバへのリクエスト振り分け先定義も順次調整していきます。

無停止でのデリバリ

　ただし、サービス無停止でのデリバリが難しいこともあります。特にDBの変更が絡む場合、無停止で行うには仕組み作りや運用コストが非常に大きなものとなります。そういった場合は、事前にユーザーへアナウンスをした上で、メンテナンス時間を設けてサービスを停止してのデリバリとした方がよい場合もあるでしょう。

　実際に、ヌーラボでもDBが絡む変更の場合は基本的にメンテナンス時間を設けて対応しています。何でもかんでもサービス無停止で行おうとせず、ユーザーの利便性と運用コストとを比較検討した上で判断してください。

UIの変更を伴うデリバリは慎重に

　継続的デリバリの文脈において、継続的デプロイメントが実現できているからといって、ありとあらゆるものを即座にデリバリしていいかというと、答えはNoとなります。

　確かに、不具合修正などは対応でき次第、極力早くデリバリすべきです。ですが、機能追加・変更などに伴ってUIが変更となる場合、デリバリのタイミングは検討する余地があります。たとえどんなに良い改善でも、UIの変更は学習コストという意味で少なからずユーザーに負担を掛けてしまいます。そのため、UIの不要な変更は極力避けるべきで、新機能リリース時もUIを完成させた状態でデリバリすべきです。

実際に利用して、開発中の機能を洗練していく

　ですが、特に新規機能の場合、実際に試してみないとUIの良し悪しが判断できないのもまた事実です。その場合、限定的なデリバリを行うのが効果的です。開発途中の機能でUIの変更が起こりうる場合は、全ユーザーにデリバリするのではなく、特定のユーザーにのみ利用できるようにするのです。

　ヌーラボの提供するサービス「Backlog」では、「ベータ環境」と呼ばれる、ヌーラボ社内のメンバーだけが使える特別な環境を用意しています。ベータ環境上に開発中の機能をデリバリしていき、社内のメンバーで利用してUI含めた機能の完成度を高めていきます。

　ここで大事なことは、「ベータ環境を実際に業務で利用している」ということです。テスト的な扱いではなく、実業務で使ってこそ改善ポイントや使いづらい点などが浮かび上がってきます。このようなプロセスを経た上で、全ユーザーが利用できるようにデリバリしています。

　この開発プロセスを整えた後、私達が提供する機能はより洗練された状態でデリバリできるようになりました。少なくとも、大ハズレな機能・UIは提供していないと自信を持っていえます。継続的デリバリの仕組みがビジネス価値を高めている、好例といえるでしょう。

終わりに

　これで「DevOps時代の開発者ための構成管理入門」の連載は最後となります。

　今回は「ビジネス面での価値創造」というと技術者にとってはピンと来ないかもしれない内容から始めました。それを「自分には関係ない」ものと捉えるのではなく、例えば以下のようなソフトウェアを作る、という言葉に置き換えれば、モノ作りに携わる技術者として情熱を注ぐことができるものではないでしょうか？

• より多くの人に使ってもらえる
• これまで解決できなかった問題を解決する
• ユーザーのライフスタイルや行動を変える

　先日、筆者たちヌーラボが開発、運営する「Cacoo」というサービスのユーザー数が100万を突破しました。20数名の小さな会社でこれを成し遂げられたのは、開発チームが常に「ユーザーにとっての価値」を中心にすえて、サービスの開発や運用をマーケティング、サポート、経理などのスタッフと協力しながら行ってきた結果だと考えています。

　そんなソフトウェア作りに携われるということは、技術者冥利に尽きることですし、何より楽しいものです。そういった意味で「継続的デリバリ」が目指すゴールは、技術者にとっても挑戦しがいのあるものです。

　また継続的デリバリは「DevOps」という文脈の中でよく語られますが、実のところツールやプロセスなどには、まだまだ改善の余地があり、模索のまっただ中であるというのが筆者の正直な感想です。

　今回紹介したヌーラボでの取り組みについても、筆者たち自身がこれを完全なものだとは考えておりませんし、これからも進化させていく必要があります。

　そういった状況であるからこそ、まずは実践した上でその成功や失敗などを振り返り、それを共有することで、また新たな知見を生み出すことが求められています。

　もし読者の方々が本連載をきっかけとして構成管理プロセスの導入を行い、そこで得られた知見を何らかの形で共有していただければ、本連載は1つの役割を果たしたといえるのではないかと考えています。そういった際には、筆者らにお声掛けいただけるとうれしく思います。

　改善に終わりはありません。

　今後も私たちは「継続的」にオフライン、オンライン問わず私たちの取り組みについて共有していきたいと思います。ありがとうございました。