Infrastructure as Code - イノベーションの風に吹かれて

Infrastructure as CodeはOpenStack Heatなどのクラウドオーケストレーションの環境より柔軟に変化に対応できるコードベースの環境を提供します。2010年頃からクラウド上で複数のサーバーから成るアプリケーションシステム全体を一つのシステムとしてプロビジョニングする技術として登場したのがOpenStack Heatなどのクラウドオーケストレーション技術です。OASIS TOSCA （Topology and Orchestration Specification for Cloud Applications）はクラウドのオーケストレーションの仮想アプリケーションパターン標準定義機能です。TOSCAではアーティファクトというサーバーやOSなどの実体定義とアプリケーションサービスのモデルを定義するアプリケーション・アーキテクトをサービステンプレート上で統合します。HeatテンプレートやTOSCAテンプレートの開発には企業レベルでの標準化活動が必要でとても困難な努力が必要でした。また、高速に変化するオープンソースの取り込みや外部のインターフェースを呼び出すというような処理トポロジーの変化に追従するたびに新しいテンプレートを開発していたのでは、結局標準化が進まないという面もありました。こうした課題を軽量化したスクリプトで解決したのがInfrastructure as Codeです。ハードウェア、OS、ミドルウェア、DB等のバックエンドサービス、ライブラリ、処理トポロジー、アプリケーションテンプレートなど多岐にわたる標準化項目を軽量化し、最低限のOS、ミドルウェア、システム管理モジュールを共通のプロビジョニングライブラリとして準備し、その上にアプリケーション毎にスタックされるライブラリ、アプリケーション、処理トポロジーを導入構成管理スクリプトでひとまとめにしてアプリケーションと同様にgitやchefの構成管理レポジトリーで管理する考え方です。一つの実行環境が依存関係を含めてパッケージングされ、スクリプトとして管理される環境になります。内部的に接続関係などの管理にHeatテンプレートも活用できます。Infrastructure as CodeではOSの導入からブートまでをブートストラップといいます。その後、ミドルウェアやライブラリの導入と設定、運用やセキュリティツールの設定などがプログラムのように管理されます。こうすることでアプリケーションのリリースごとに必要なモジュール、トポロジーがソフトウェアとして管理することができるようになります。さらにパッケージは環境への依存性を極力少なく設計されるため、複数のクラウド環境で実行することができます。

一旦Infrastructure as Codeでインスタンス化されたサーバーは、その後管理者による手作業の変更作業を受け付けません。冪等性を持っているパッケージは変更部分だけを実行できるので変更作業はパッケージに対して行って走らせるだけで目的とした状態に変更されます。また、こうしてメンテナンスされたパッケージはサーバーを他のクラウドに一時的に退避したり、突然のトランザクションの増加に対応したりする場合に常に最新の状態のサーバーの複製を作ることができるという利点をもたらします。クラウドサービスでありがちなメンテナンスのための突然の停止や共有インフラのパッチ修正作業などでサービスを停止しない工夫が可能になります。

Infrastructure as Codeが構成管理ツールであって自動化ツールでは無いと言われるのはこのような特性によるものです。インスタンスの作成の省力化だけではなく、スケールしたサーバーのメンテナンス、構成管理という運用全体の問題として捉える必要があります。また、Infrastructure as Codeは基本的にブートストラップ（OSインスタンスを作るプロビジョニングの第一段階）からクラウドによるソフトウェア制御が前提と考えるべきです。オンプレミスのサーバー環境やプライベートクラウド環境ではよほど大規模でサイト分散ができていない限り本格的なメリットは得られません。さらに、インスタンス作成の省力化効果で費用対効果を算出するのはナンセンスです。構成管理のミスを減らし、運用品質をあげることがサービスの継続性を高めるということや、アプリケーションと歩調を合わせて非機能要件を改善したリリースを継続できるという費用算定できないメリットを手に入れます。こうしたことは運用管理の現場を理解していない上層部には肌感覚で理解できないため、費用対効果を求められ導入が進まないという面があります。運用の現場にツール採用の判断が委譲されていることがDevOpsを推進していく鍵となります。