「ブルーグリーンデプロイメントの仕組み」を理解する：OpenStack上に構築する、ブルーグリーンデプロイメント実践入門（2）（1/3 ページ）

本連載では、「OpenStackを基盤としたブルーグリーンデプロイメント」を実現する“現場目線”のノウハウを解説していきます。今回は、「ブルーグリーンデプロイメントの利点とその仕組み」を説明します。

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

連載バックナンバー

　前回はシステムのリリースにおける6つの課題を「ブルーグリーンデプロイメント」と呼ばれる手法によって解決できることを説明しました。今回は、この6つの課題を具体的にどのように解決できるのかを深掘りしていきます。参考例として、筆者の所属するユニアデックスで手法を開発し、提案しているOpenStackにおけるブルーグリーンデプロイメント展開ノウハウから、その実現方法を紹介します。

システムのリリースにおける「6つの課題」とその背景

　前回説明した、システムリリースにおける「6つの課題」と、その背景を整理しましょう。

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

　1つ目の課題「システムの停止時間が発生する」は、システムを停止しなければ更新できないという制約が原因です。システム観点では「仕様だから仕方ない」と思いがちですが、ビジネス観点では「そんなの関係ない」となります。機会や売上の損失につながる停止時間などはないに越したことはありません。ここがシステム側とビジネス側に存在する大きなギャップです。これは続く2つの課題を派生させます。

　続く課題「システムの停止時間は限られ、時間に追われてミスが懸念される」と「時間の制約から十分なテストができない」は、一言で言えば、与えられた時間に対して、すべきことが多すぎることが要因です。

　一般的に、リリース作業までには以下の項目が発生します。

• リリース前に戻すためのバックアップ
• OSやミドルウェアの配備や設定
• データベースのスキーマ追加やデータの洗い替え
• アプリケーションの配備と設定
• 妥当性を確認するためのテスト

　さらに、

• 切り戻すための時間を別に確保する

　という工程も必要となります。やはり時間のやりくりは苦しいことでしょう。だからといって、苦しまぎれに──例えば、テストを省いて時間の帳尻を合わせたり、作業を無理やり詰め込んだりしてしまうと、もっと重大なデグレード（新しいバージョンのソフトウェアのパフォーマンスが、以前より悪くなってしまうこと）やヒューマンエラーによる失敗やミスを招いてしまいます。

　さらには、足りない時間をやりくりするために「バックアップや切り戻しを考慮しないで突き進む」という暴挙に出てしまうことも、トラブルが発生した現場では、皆さんの想像以上によく聞かれます。これでは、何かあった場合にリリース時間内の切り戻しができず、結果として長時間のシステム／サービス停止に陥るという最悪の事態になるのは言うまでもありません。

　4つ目の「本番環境とテスト環境の差異が不具合を招く」という問題は、本番環境として稼働してから初めて発覚するので、非常に厄介です。ライブラリのバージョン違いがバグの引き金となるケースや、本番環境だけに存在する緊急パッチを上書きした結果、デグレードを起こすケースが挙げられます。これらはいくらテスト環境でテストをしても防ぎようがありません。

　こうした懸念を払拭するために、皆さんは事前に環境の調査を行うはずです。しかしこれは、5つ目の課題である「綿密な作業計画や調査などの準備が必要となり、リリースまでに大きな工数が掛かる」ことの要因になります。本番環境への移行に際し、悩ましい問題は数多くあるはずですが、この手順の策定には、やはり多くの工数が必要です。行程が多くなればなるほど、手順を作成する難易度も高くなるでしょう。当然、時間が限られる中で多くの作業を確実に行わなければならないことも、綿密な作業計画が必要とされる、つまりは、多くの工数が必要となる理由です。

　最後の課題である「大掛かりなリリースで、かつリリースが複雑になるために不具合が起きやすい」では、例えば、ビジネス観点でシステム／サービス停止自体を設けにくいことが背景にあれば、各部署と連携しながら、綿密な作業計画を立てるために、長い準備期間を要することが想定されます。作業も準備も大変なので、リリースの頻度が減り、一度のリリースにまとめてしまう。結果として大掛かりなリリースになります。課題（5）と同様に、一度にリリースする内容が多ければ、それだけ機能間の依存関係なども複雑化します。リリースの複雑度が増すことで、難易度が高く、リスクの高いリリースとなってしまうわけです。

　これら6つの課題を、ブルーグリーンデプロイメントの仕組みによって回避／改善することが可能となります。