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

頻繁なリリースを実現する基盤に必要な、「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は、テストコードを用いて開発対象のコードを動かしながら作り上げ、さらにきれいなコードに書き換えて品質を高めるプロセスです。テストコードと開発対象コードが繰り返し実行されることで、その正確性を向上させます（図1）。

図1　TDDのプロセス

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

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

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

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

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

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

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