ブルーグリーンデプロイメントの効果と課題：OpenStack上に構築する、ブルーグリーンデプロイメント実践入門

TDDのプロセス

　前回は、リリースにおける6つの課題をブルーグリーンデプロイメントの手法によって解決できること、そして、ユニアデックスの開発したソリューションを例に、OpenStack上に構築したブルーグリーンデプロイメントの仕組みを説明しました。

ロードバランサーを用いたブルーグリーンデプロイメントにおける両系アクセスの課題

　今回はこれを踏まえて、OpenStackを基板とするブルーグリーンデプロイメントの効果と、導入における課題を具体的な導入を考える管理者に向けて考察していきます。

●「リリース工数の削減」と「リスク低減」の効果を考察する

　ブルーグリーンデプロイメントは、「リリース工数の削減」と「リスクの低減」に効果があることを前回説明しました。まず、リリースにかかる時間がどれだけ削減できるかを考察してみます。

　以下は、あるWebアプリケーションシステム（以下、従来システム）を想定した、リリースにおける2時間のサービス停止を伴うメンテナンスタイムテーブル例です。

時刻　／　作業内容　／　備考
23:00　／　リリース作業開始、本番系停止　／　強制ログアウト処理5分、アクセス停止処置5分
バックアップ20分
22:30　／　本番系適用作業開始　／　適用作業30分
24:00　／　本番系適用確認テスト開始　／　テスト可能時間30分
24:30　／　切り戻し判断期限時刻　／　切り戻し所要時間20分
24:55　／　本番系サービス再開準備　／　アクセス開始処置5分
25:00　／　メンテナンスタイム終了　／　本番系サービス再開

　リリース作業における「2時間」は、あっという間です。上記のように個々の作業に時間を割り振っていくと、適用自体の作業に使える時間とテストに使える時間は、それぞれ30分しかありません。この例では、バックアップとリストアの時間にそれぞれ20分を取っていますが、大きな規模のデータベースを扱うシステムならば、もっと時間が必要かもしれません。
　それに対して、このシステムへブルーグリーンデプロイメントの仕組みを導入すると、こうなります。

23:00　／　メンテナンス開始、本番系停止　／　強制ログアウト処理5分
23:05　／　本番系切り替え作業を実施→本番系サービスが再開　／　強制ログアウト終了後、約3秒で本番系の切り替えが完了
23:15　／　メンテナンスタイム終了　／　本番系の切り替え後5分を切り戻しの判断時間に割り当てる（問題がなければ作業なし）

　2時間の所要時間は15分に短縮されます。しかもほとんど焦る必要がない、余裕のある15分です。

　もっとも、ブルーグリーンデプロイメントでは設定済みの環境をあらかじめ準備しておくので、プロジェクト全体の時間は変わらないのでは？　と思う人はいるでしょう。しかし、作業タイミングが違うことに大きな意義があります。

　まず、圧倒的にすべきことが減ります。従来システムでは、限られた時間内に多くの工程を迅速かつ正確に実行する必要があります。そのために、前もって入念な計画を行い、作業をこなす人員を確保して作業を並列化しなければなりません。併せて、臨時で確保した人員については対象のシステムに関する事前教育が必要ですし、作業前のリハーサルを行うことなども考察しなければなりません。

　それに対してブルーグリーンデプロイメントならば、入念な作業計画を立てる時間とリリース時の追加人員はずっと少なくて済むでしょう。つまり、リリースにかかる時間だけではなく、工数を削減できることになります。

　また、仮にプロジェクト全体の所要時間や工数には大きな差がなかったとしても、ブルーグリーンデプロイメントにはもう1つ大きなメリットがあります。それは「作業時間を平準化できること」です。例えば、リリースに向けて新たな人員が必要なのに、それを確保できなかったらどうするか、原価が想定以上に掛かったらどうするか、新たな人員を確保したはいいがスキルが低かったらどうなるか、などの不確定要素も考慮する必要があります。ブルーグリーンデプロイメントを適用すれば、そのような不安定性の影響を受けにくく、かつ、作業が集中してしまうことで生じるリスクを避けることができます。

●頻繁なリリースを実現する基盤に必要な、「Infrastructure as Code」と「Immutable Infrastructure」の考え方

　前回紹介したように、ブルーグリーンデプロイメントを実現し、さらに環境構築を自動化すれば、これまで以上に迅速かつ高頻度にアプリケーションを更新していけるようになります。米Amazon.comのように1時間に最大1000回以上もの更新を実現するためには、「Infrastructure As Code」と「Immutable Infrastructure」の考え方が極めて重要になります。

　Infrastructure As Codeとは、OSやミドルウェア、アプリケーション導入の仕様、構成、設定を、テキストとして記述した「コード」で表現し、自動的にインフラを構築する手段のことです。運用者が手順書を参照しながら、コマンドを手入力して行っていた作業に代え、コード化して、プログラムとして実行します。手作業によるヒューマンエラーを排除できる上、低コストで繰り返し実行していくことが可能になります。これを実現するフレームワークには、例えば「Chef」「Ansible」「OpenStack Heat」などがあります。

　なぜコードで表現することが重要なのでしょう。例えば、Microsoft WordやExcelなどで作成されたインフラ構築の手順書の「中身の正しさ」を検証するには、実際に検証環境を準備した上で検証を実施する工程が必要です。当然、工数がそれだけかかります。対してInfrastructure As Codeは、コードとして自動実行が可能です。人力での作業工程がなくなるだけでなく、繰り返し実行することで正確性を向上させていくことができます。

　なお、繰り返し実行によって正確性を向上させる手法には、ソフトウェア開発における「ユニットテスト」と呼ばれる先例があります。ユニットテストでは、「コードをコードでテスト」して正確性を高めます。この他に、ユニットテストを利用した「TDD（Test Driven Development）」と呼ばれる手法もあります。TDDは、テストコードを用いて開発対象のコードを動かしながら作り上げ、さらにきれいなコードに書き換えて品質を高めるプロセスです。テストコードと開発対象コードが繰り返し実行されることで、その正確性を向上させます。

　このソフトウェア開発における考え方をインフラ構築に取り入れた「Serverspec」というツールがあります。Serverspecでは、コードによって自動構成された環境が本当に正しいかを検証するテストを自動化できます。また、繰り返し実行が容易なため、品質をより担保できるようになります。

　このように、Infrastructure As Codeは既存のインフラは更新せずに、構成を変更するという考え方です。

　対してImmutable Infrastructureは、元の環境を捨てて、毎回ゼロから構築し直すという考え方となります。Immutableは不変と訳される単語のために少し困惑するかもしれませんが、今あるものを「変更せずに捨てて、作り直す」と理解するとよいでしょう。ともあれ、ソフトウェア更新のたびに構成を変更した環境を作り直すので、Infrastructure As Codeが前提となる考え方でもあります。

　ではImmutable Infrastructureにはどんなメリットがあるのか。初期導入後、10回更新を行ったシステムの構築手順書を例に説明します。

　このシステムには、最初の導入手順と10回の更新作業で、合計11個の更新手順が存在します。この段階で、仮にサーバの保守切れなどでゼロから環境を作り直すとなるとどうなるか。……最新版への更新手順書はあれど、「最新版を構築」する手順書が存在しない問題が発生します。今さら合計11個もの更新手順を統合するのは困難ですし、過去の全ての手順書が正しいという保証もなかったりします。

　このように、更新を繰り返しているうちにゼロからの構築手順が不明となってしまう状況はよくあることです。しかし、それは現時点の環境を正しく把握できていない状況とも言い換えられます。リリースにおけるトラブル事例である「本番環境とテスト環境の差異が不具合を招く」が生じる根本の要因です。

　Immutable Infrastructureとして毎回自動的にインフラを構築し直すならば、このような問題を避けられます。これが最大のメリットになるでしょう。

●ブルーグリーンデプロイメントの課題と対策

　続いて、ブルーグリーンデプロイメントの課題を考察します。

　課題の1つは、「自動切り替えの手法に応じて、さまざまな考察が必要となる」ことです。

　ブルーグリーンデプロイメントでは、DNS、ロードバランサー、NATのいずれかを用いてブルー系とグリーン系環境の自動切り替えを実現します。それぞれに異なる課題があります。

　まずDNSで切り替える方法は、DNSキャッシュの影響によって、切り替えに数秒から数分を要することが課題に挙がります。これは、「DNSの浸透待ち」などと呼ばれる課題です。DNSを早く浸透させるために、キャッシュ保持期間であるTTL（Time To Live）パラメータを短くすると、今度はDNSサーバのパフォーマンスや、DNSキャッシュポイズニングといったセキュリティ上の懸念が増えてしまいます。また、完全に環境が切り替わっていない時間帯にブルー／グリーンの両系へアクセスされる可能性もあります。こちらはアプリケーションレベルで不整合などが起こらないように考慮しておく必要があります。

　ロードバランサーで切り替える方法も、前述した両系への同時アクセス、あるいは両系へのアクセスが不能になるタイミングの存在が課題となります。例えば、ロードバランサー配下に新しいノードを追加した場合には、すぐにそのノードが使われず、ヘルスチェック機構によって数十秒程度の死活監視が行われてから利用されます。このため、本番系を切り替えただけでは、どのノードもアクセスが不能になる時間帯ができてしまいます。この解決のために、追加した系がオンラインになった時点で旧本番系を除去する施策を取る施策も考えられるでしょう。しかし、追加した系がオンラインになるタイミングは正確に把握できず、厳密な指定もできません。やはり、両系へアクセスできてしまう問題は残ります（図2）。

　NATで切り替える方法は、HTTPのKeep-Alive接続によって切り替えが発生しない状況が生じます。OpenStack Neutronにおけるデフォルトの実装ではiptablesのNATテーブルを利用してフローティングIPを実現しますが、TCPセッションの確立時点しかNATテーブルが評価されません。HTTP Keep-Aliveは確立済みTCPセッションを使い回すために、HTTP通信が頻繁に行われるような場合にはNATテーブルが評価されず、切り替えが発生しないのです。

　なお、2017年1月現在ではほとんどの通信がHTTP/1.1であり、デフォルトでKeep-Aliveが有効です。このKeep-Alive対策として、ユニアデックスの構築したブルーグリーンデプロイメントソリューションでは、LBaaSのソースコードに改変を行ってKeep-Aliveを無効化しています。

○アプリケーションにおける切り替えの考慮

　アプリケーションの更新に伴う本番系の切り替え時には、ブルーグリーンデプロイメント特有の考慮が必要です。特にデータベースに課題があります。

　リレーショナルデータベースには、「データベースのバージョニング」と呼ばれる手法が有効です。通常データベースのスキーマを変更する場合は、バックアップを取得した上で「DDL（Data Definition Language）」を発行します。さらに、追加したカラムの初期値設定などのデータの洗い替えを実施します。

　データベースのバージョニングにおいては、データベース自身にデータベースバージョンを記録します。アプリケーション起動時などにこのバージョン名を評価して、アプリケーションが認識するバージョンと異なるデータベースを検出した場合には、バージョンアップ、またはバージョンダウンのDDLを発行してスキーマを変更し、さらに、必要に応じてデータの洗い替えを実施するようにします。こう対処しておくことで、本番系の切り替え時にデータベースを正しく認識し、矛盾のない動作を実現することが可能となります。

●終わりに

　今回は、ブルーグリーンデプロイメントの効果とその課題を解説しました。昨今のITインフラ管理者には、単にシステムのお守りをしていればよいのではなく、ビジネス躍進の担い手としての役割がより強く求められてきています。特に継続的インテグレーション、継続的デリバリーといった開発現場の潮流が運用のスタイルを大きく変える渦となっています。この流れは今後さらに加速するでしょう。

　次回は、実際にOpenStackにブルーグリーンデプロイメントを構築する手順を紹介します。

●筆者紹介
佐々木智一
ユニアデックス株式会社　自社IP電話関連プロダクトなど、ソフトウェア開発を経験した後、近年はSDNやOpenStack、IoTなどに関するR&Dを担当。IKEAでDIYが休日の楽しみ。
共著：田中克弥
ユニアデックス株式会社　パワポと戯れるOpenStack商品企画担当。バックパック片手に世界をぶらり旅。次の旅先を妄想中。