Server」)が注目を集めています。ブルーグリーン・デプロイメントとはブルーグリーン・デプロイメントでは、まずブルーとグリーンという2つの環境を用意し、ルータやロードバランサの振り向け先をどちらか一方に割り当てておきます。現在のブルー側でサービスが稼働してるとすると、新しいアプリケーションをデプロイする時にブルーで動いているアプリケーションを置き換えるのではなく、もう1つの環境(グリーン)のアプリケーションを更新して、ルータやロードバランサの振り向け先をグリーンに振り向けることでバージョンアップを行うというものです。問題が発生した場合は、ロードバランサの振り向け先を戻すだけで済みます。次にリリースするときはグリーンとブルーを入れ替えます。Infrastructureは、このブルーグリーン・デプロイメントを一歩進めたアプローチの1つで、「1度構成したサーバには2度と変更を加えない」という考え方です。何らかの変更を加えたい場合には、全く新しい環境を立ち上げて、そこに新たな変更を加えるというものです。Infrastructure以下の図は、おのおのの手法において、サービスを提供する「アクティブ」な環境がどう切り替わるのかの違いを表しています。Infrastructureのイメージ先に紹介したChefなどのサーバ構成ツールには「冪等性」という考え方があり、何度適用してもある状態に収束するという特性があります。サーバは長時間運用されていると、突発的な対応を行うこともあって、現実問題としてその状態が分かりにくくなるという傾向があります。これまで使っていたAというパッケージが不要になった場合、「Aが存在しないこと」という設定を構成管理ツールに追加して適用しないといけなくなりますが、得てして設定の複雑化を招きます。いったことが積み重なると、長時間動いているサーバと、新たに作ったものに本当に違いがないのか分からなくなります。代わりに全く新しく環境を立ち上げることで、常に稼働しているサーバの状態に対して確信が持てるようになります。Infrastructureを実現するためには、新たな環境を素早く立ち上げられることが求められます。そのためにサーバ構成管理ツールと協調してOSイメージを簡単に作るためのツールとして「Packer」などが注目を集めています。サーバ環境をテストするための「serverspec」などのテスティングツールも整備されてきており、これらのツールを組み合わせることで、例えばChefなどの構成管理ツールの設定に変更がなされたら、CIで自動的にイメージを作成しテストも実行する、といったところまで自動化が可能です。環境の立ち上げ時間そのものに着目すると、例えばAWSのようなハイパーバイザ型の環境は、新たに立ち上げるための時間がそれなりにかかります。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つの役割を果たしたといえるのではないかと考えています。いった際には、筆者らにお声掛けいただけるとうれしく思います。改善に終わりはありません。今後も私たちは「継続的」にオフライン、オンライン問わず私たちの取り組みについて共有していきたいと思います。ありがとうございました。いった開発環境の整備に面白さを感じ、「Backlog」というBTSを提供しているヌーラボに転職。ヌーラボで、プロジェクト管理ツール「Backlog」、ドローツール「Cacoo」の開発、インフラ運用などにたずさわる。入社5年目の技術者の声からDevOpsの手法を考える際、ツールや環境整備に目が行きがちだが、最も重要なのは、チームコミュニケーションとチームの目的の持ち方である。ビジネスを推進する情報システム部門の位置付けを考える。HQ、Scalr、Aeolusの特徴をまとめて紹介します。筆者が体当たりで検証。運用面でのハウツーも紹介していきます。配備を自動化するビルドが自動化されたら、デプロイも自動化しよう。Serverを使ってアプリのデプロイを自動で行う手順を説明する。CloudStackによるプライベートクラウド構築術(8):ChefのKnifeでCloudStackを操作する方法knife-cloudstackを用意してコマンドラインでCloudStackを操作してみよう。Foundry」を理解するオープンなクラウドで重要性を増すJava。DevOps時代のJavaプログラマはアプリケーション開発者(Dev)もデプロイや運用(Ops)面におけるクラウド/インフラ技術への幅広い理解が必要となる。本連載では、さまざまなオープンクラウド技術を紹介していく。Foundry」を紹介。Foundryの開発用稼働環境を用意してみよう。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。