イミュータブルなインフラ運用
デジタル庁クラウドチーム
Cloud Architect 山本教仁
前回は、ガバメントクラウドにおけるIaC(Infrastructure as Code)の考え方を説明しました。
IaCでは、インフラの構成をプログラムコードとして記述し、そのコードでインフラを構成管理し、構築を行います。前回も少し触れたように、その効果はイミュータブルなインフラ運用と組み合わせて効果を最大化します。
今回は、ガバメントクラウドで考えるイミュータブルなインフラ運用について説明します。
イミュータブルについて
Immutable Infrastructure（イミュータブル・インフラストラクチャ）について
Immutable Infrastructureという考え方があります。Immutableは「変化しない」ことを意味します。
Immutable Infrastructureは、変化しないインフラ、つまり、一度構築したらその後構成変更したりパッチ適用したりせずインフラ全体をある一時点の状態で固定化することを意味します。
Immutable Infrastructureでインフラ構成変更やパッチ適用等なんらか構成変更が必要な場合には、構成変更済みパッチ適用済みの新しいインフラ環境を新たに別途構築し、既存環境から新環境に全体を切り替えて運用を続けることになります。
サポート対象外のハードウェアやソフトウェアを含むインフラを運用し続けなければならない、いわゆる「インフラ環境全体の塩漬け運用」を意味するものではありません。
Immutable Infrastructureを実装し運用していくためには、
(1)同じIaCコード等からまったく同じインフラ環境が構築されること（＝冪等性）
(2)アプリケーションデータはImmutable Infrastrucureの外部に保管されていること、もしくはすぐに移行できること
などが必須の前提となります。
簡単に一から同じインフラ環境を構築できるようになったのは、前回説明したIaCのツールでコードから自動的にインフラが構成されたり、静的解析ツールにより事前にIaCコードのエラーチェックを行えたり、CI (Continuous Integration) によりインフラ構成のテストや前回構成時のインフラとの差分のテスト（スナップショットテスト）が行えたり、 CD（Continuous Delivery）のツールでIaCコードのリリースとインフラのプロビジョニングを一連の流れで自動化できるようになったり、ツール群が便利になってきたことも貢献しています。
一から環境を作ったり、既存環境から新環境へ切り替える運用は、上記のツールの進歩や、従量課金が特徴となったクラウドサービスの登場によって現実的になってきたと考えられます。
Immutable Infrastructureの効果
インフラ全体をImmutable Infrastructureの考え方にそって運用することで、本番環境に都度手作業で変更を加えてサーバによって構成が違ってしまったり現在の構成がわからなくなったりといったことがなくなるため、インフラ構成のブラックボックス化を防ぐことができます。
現在のインフラ構成はつねにIaCコードに記述されたとおりで明確です。また、新たに環境を作って既存環境から切り替えていくことで、なにか問題があったときに切り戻しがしやすく、インフラ構成変更の本番稼働影響を最小限に抑えることも可能です。
とはいえ、ちょっとしたインフラ構成の変更で環境まるごと切り替えはテストなども考えると負荷が高すぎるのではないか、ごく一部のソフトウェアへセキュリティパッチを緊急であてるだけなのに環境全体の切り替えで逆にシステム稼働に影響があったらどうするのか、IaCコードが間違っていたり悪意のあるコードが入れ込まれたら本番環境への影響が大きすぎるのではないかなど、システムの規模や構成内容、運用する組織などによっては考慮点もあります。
環境切り替えの負荷やシステム稼働への影響については、前提(1)の冪等性により解消可能です。従来の手法でもインフラ構成変更を本番へ適用する前に検証環境でのテストは実施していたと思います。
イミュータブルなインフラ運用になっても、事前の検証環境でのテストは変わりません。検証後の本番環境への変更適用時に、IaCコードとその冪等性で検証環境とまったく同じ環境を本番環境として実現できることで、従来の手作業による本番環境操作よりも安全で確実な本番への変更が実施でき、実は作業負荷も下がっていると言えます。
また、最近のクラウドのIaCツールでは、既存環境への変更反映が実施しやすくなってきています。
システム全体ではなく、影響範囲やメンテナンス容易性の観点で意図的に区切った範囲でのシステム構成変更が実現できたり、変更内容によって既存環境への設定変更やリソースの入替を自動で判断して実施してくれたり、失敗時やエラー時に切り戻し（ロールバック）も実現できるようになっています。
つまり、既存環境をいっさい変更しない厳密な意味でのImmutable Infrastructureを実現しなくても、既存環境の更新でImmutable Infrastructureと同じ効果を実現できるようになってきています。
ガバメントクラウドでのイミュータブルなインフラ運用の考え方
現実的なイミュータブルのあり方
こうしたIaCツールの進化なども踏まえ、ガバメントクラウドのイミュータブルなインフラ運用の考え方としては、現実的な運用を考慮して、厳密なImmutable Infrastructureを必須とするのではなく、クラウドIaCツールの機能を使って既存環境を更新しつつImmutable Infrastructureと同じ効果を得ることを考えていきます。
ここで、「イミュータブルな運用」と書くときは、厳密な意味でのImmutable Infrastructureではなく、既存環境に対して手作業で変更を加えず、変更する場合は必ずIaCコードを使う運用を指します。
ガバメントクラウドでのイミュータブルな運用
ガバメントクラウドでIaCコードによるイミュータブルな運用を実現するために、AWSではCDKやCloudFormation、GCPではConfig Controllerなどのツールを活用していきます。
これらIaCツールは、インフラ構成の状態を定義するもので、このIaCコードを見れば現在の構成がすべてわかるものです。したがって、適用したIaCコードを過去からのバージョンで管理していけば、インフラの構成管理も可能となります。
こうしたIaCコードによる構成管理は、クラウドサービスへのコマンドやAPI呼び出しをスクリプト化し自動化することとは大きく違います。
インフラ構成の自動化スクリプトでは、構成の命令が記述されているだけで現在の全体構成がわかりにくく、現在のシステム全体の構成状態を捉えることが困難です。
また、それがゆえにエラーなどで戻す必要が出たときも、手作業での戻しとなります。一方で、そのときどきの構成情報をコードとしてすべて持っているIaCツールでは、エラー時の切り戻し（フォールバック）も過去のバージョンの構成状態へ戻す機能として持っています。
したがって、Immutable Infrastructureと同等の効果は、単なる自動化スクリプトでは得られず、IaCツールとそのコードによるイミュータブルな運用で実現できる効果となります。
イミュータブルな運用を行うためには、クラウドサービスが提供するIaCツールを使って既存環境を構築、変更し、原則として、それ以外の方法、たとえば管理コンソールに入っての手作業での構成変更や、SSHでOSにログインしての変更をしないことを考えていきます。手作業で構成変更してしまうと、IaCコードに定義された構成とのズレが生じるためです。
もっとも、最近のIaCツールでは、手作業での変更が加えられた現状の環境とIaCコードとの差分を検出する機能もあるため、原則として手作業を禁止しつつ、こうした差分検出機能を使ってのIaCコードのメンテナンスの運用ルールも決めて、例外的な手動対応もルール化していくことが重要です。
また、OSにログインせず運用するためには、マネージドサービスをフル活用したり、コンテナやFunction as a Serviceであるサーバレスの活用も重要になります。マネージドサービスやコンテナを使ったOSに依存しない運用についてのガバメントクラウドでの考え方はまた機会を改めて説明します。
イミュータブルなインフラ運用でIaCコードを環境に適用していくためには、CDパイプラインの整備も重要となります。実際にインフラを構築する前に、IaCコードをレビューし検証環境で検証し、承認後に本番環境へ適用する一連の流れをプロセス化して半自動的に流していく仕組みを構築する必要があります。
一度このパイプラインを構築すれば、あとはIaCコードの適用が厳密かつ容易になるため、CDパイプラインはイミュータブルなインフラ運用上必須の機能となります。
こうしたパイプラインを先に整備することで、IaCコードのセキュアな運用も可能となります。コードのレビューや実機検証、リリースの承認などをプロセス化することで、間違ったコードが適用されたり、悪意のあるコードが入ることを防げます。
このパイプラインは、アプリケーションのリリースで実装されているパイプラインと類似のもので作ることができ、アプリケーションコードとそのリリースのセキュリティと同じレベルのセキュリティを実現できます。
IaCコードは、前述したとおり、すべての構成情報を持つため、前回のコードとの差分を把握しやすく、差分の確認はレビューにも使えます。また、IaCツールによっては、事前に影響範囲を確認する機能もあるため、こうした機能を使ってレビューを行うことで、よりセキュアなIaCコードの運用管理が可能となります。
イミュータブルなインフラ運用の効果
イミュータブルなインフラ運用で得られるガバナンス効果
IaCコードを使ってイミュータブルなインフラ運用をすれば、ガバメントクラウドが目指す、コスト効率がよく、迅速かつ柔軟で、セキュアなインフラを実現していくことができます。
コスト効率や迅速さ、柔軟さは主にIaCコードで実現され、イミュータブルな運用では、これまで述べてきたように次のようなセキュリティも含むガバナンスについて一定の効果が得られます。
IaCコードで構成管理ができ、インフラ構成のブラックボックス化を防ぐ
既存環境への更新であっても、部分的な更新ができたり、事前に影響範囲を確認できたり、エラー時にはフォールバックもできる
検証環境と本番環境をまったく同一にできるため、事前テストが確実に実施できる
IaCコードのリリースパイプラインを定義することで、アプリケーションリリースと同等のコードレビューやリリース承認が実現でき、リスクを軽減できる
手作業でのインフラ構成変更をなくすことによるセキュリティとコスト削減の効果
さらには、手作業でのインフラ構成変更を禁止することで、インフラ運用まわりの仕組みを簡素化でき、よりセキュアに、かつコスト削減につなげられます。
従来のインフラ運用では、サーバOSにログインするための踏み台サーバであったり、OSログイン用のユーザ管理であったり、環境にアクセスするためのVPNや専用線の仕組みであったり、それら多数のログを監視する仕組みであったり、さまざまなセキュリティ運用上の対策が必要でした。
また、クラウドでは環境を操作できる管理コンソールをどう制限かけて保護するかが設計テーマとなり、無理やりインターネットからの接続を禁止しようとしたり、各種制約をつけようとしたりされることもあります。
これらはすべて手作業でのインフラ構成変更を許容しているためです。インフラ構成変更をIaCコードからだけに限定することで、IaCコードやコンテナ等をリリースするパイプラインのセキュリティを考えればあとの対策は不要となり、管理コンソールもRead Onlyでの運用ができるようになります。
また、検証環境と本番環境はまったく同一構成なので、検証環境ですべてのテストや実機確認操作ができ、違いはデータが本番か検証かだけになります。こうしたセキュリティ運用設計の簡素化や標準化を実現するのがイミュータブルな運用であり、セキュリティとコスト効率の観点で、インフラ運用に大きな効果があります。
ガバメントクラウドでのイミュータブルなインフラ運用の方向性
デジタル庁クラウドチームでは、IaCコードの整備とともにイミュータブルなインフラ運用も推進していきます。IaCコードをリリースするためのパイプラインを簡単に構築できるようなIaCコードのテンプレートを用意したり、イミュータブルなインフラ運用にあたっての各種ガイド等を検討しています。
従来のサーバ運用を中心としたインフラ運用からは、イミュータブルな運用では大きく変更を求められるため、この方法に慣れるのに時間がかかるかもしれません。また、システム環境やシステム構成、運用体制によっては従来型のサーバ運用のほうがコスト効率が高いこともあるかもしれません。
しかしながら、中長期的に見ると、マネージドサービスの活用やコンテナ化、サーバレス化と合わせて、イミュータブルな運用を実現していくことが、ITインフラ運用全体の効率化と品質向上、コスト削減に貢献すると考えています。ガバメントクラウドでは、IaCとともにイミュータブルな運用の実効性を高めていくことに取り組んでいきたいと考えています。
◆デジタル庁Techブログの記事はこちら。
◆デジタル庁の採用に関する情報はこちら。