なぜ“リリースの自動化”が重要か──今こそ「ブルーグリーンデプロイメント」を考える：OpenStack上に構築する、ブルーグリーンデプロイメント実践入門（1）（2/2 ページ）

[佐々木智一，ユニアデックス株式会社]

今、強く求められる「ブルーグリーンデプロイメント」

　このような、ITシステムのリリースにおける課題を解決する手法の一つが「ブルーグリーンデプロイメント」です。ブルーグリーンデプロイメントは、既存のシステム（ブルー）を稼働させながら、次のバージョンとなる「もう一つの新しいシステム」（グリーン）を準備して、短時間で切り替える、という方法論です。

　これまでの既存のシステムを停止して、更改のための差分を適用するシーンを想像してみてください。この差分は、更新版のプログラム、データベースなどのミドルウェア、OSの設定変更、設定追加などが含まれます。このとき、以下の課題が挙がります。

1. システムの停止時間が発生する
2. システムを停止できる時間は限られる。時間に追われた作業となり、ミスの発生が懸念される
3. 時間の制約から、十分なテストを実施できない
4. 本番環境とテスト環境の差異が生じやすく、この違いが不具合を招く可能性がある
5. （4）のために綿密な作業計画や調査などの準備が必要で、一度のリリースに大きな工数がかかる
6. （5）のために大掛かりなリリースとなりがちで、リリースの複雑さを原因とする不具合が発生する可能性が高まる

　ブルーグリーンデプロイメントは、この（1）から（5）への解決策を実現します。既存のシステムを動作させながら、じっくり時間をかけて次期バージョンのためのシステムを別に作っておき、そちらへ瞬時に切り替えることでリリースします。システムの停止時間の短縮と、環境構築やテストに必要な時間をかけることを両立できます。

　また、アプリケーションを置き換えるのではなく、テスト済みの「環境と差分を反映したアプリケーション」をそのまま本番環境化することになるので、本番とテスト環境の差に起因した問題発生リスクも回避できます。アプリケーションに差分を適用するのではなく、アプリケーションを作り直すことによって、移行計画で考慮すべきことである「本番環境の設定状態の調査」などの行程も省略できます。

　（1）から（5）の課題を解決すると、リリースの頻度を上げることも可能になります。結果的に、（6）の解決につながることも重要です。細かいリリースによって不具合のリスクを減らすことができ、スクラムとも相性が良い──。それは、「継続的インテグレーション」の目指すところでもあります。

※継続的デプロイメント／インテグレーションの手法の詳細については、こちらでも詳しく解説しています。ぜひ、併せて参照ください。

（参考記事）継続的デリバリ／デプロイを実現する手法・ツールまとめ

　万一リリース後に問題が発生したとしても、「Ctrl+Z（やり直し）」をするかのように、これまで正常に動作していたシステム環境に切り戻せます。これで清水の舞台から飛び降りるかのような思いをせずに済みます。

OpenStackを基盤に、ブルーグリーンデプロイメントを構築する

　では、実際にどのようにシステムを構成し、運用すればよいのでしょう。切り替えの手段にはルーターやロードバランサ、DNSを使う例がありますが、本連載では、自動化を行いやすい特徴を持つIaaS（Infrastructure as a Service）基盤である「OpenStack」上でブルーグリーンデプロイメントを実現する手法を解説していきます。

　OpenStackでは、各機能をAPI経由でやりとりし、全体としてIaaS機能を提供します。自動化しやすいのは、このAPIに理由があります。

OpenStackの構成とAPIの役割

　次回は、「ブルーグリーンデプロイメントをOpenStackで実現する」具体的なノウハウを紹介します。お楽しみに。

筆者紹介

佐々木智一

ユニアデックス株式会社 未来サービス研究所　自社IP電話関連プロダクトなど、ソフトウェア開発を経験した後、近年はSDNやOpenStack、IoTなどに関するR&Dを担当。IKEAでDIYが休日の楽しみ。

共著：吉本昌平

ユニアデックス株式会社 未来サービス研究所　ベンチャー企業でASPシステムの設計／開発を経験した後、現職。近年はSDNやIoT関連の企画推進を担当。