「Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス」を読んでIaCを学びなおした

少し前の本ですが、「Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス」を読みました。
IaCについて理解が深まる良書だと思ったので紹介します。

対象となる読者

本書は、サーバーやサーバー群を管理する人々を対象にしています。

システム管理者
インフラエンジニア
技術に関心を持つ管理職
インフラを自分で構築したいソフトウェアエンジニア

はじめに

本書は特定のツールについてのノウハウというわけではなく、「Infrastructure as Code」全般について触れています。

以下のようにツールを分類して、それぞれ説明しています。

ダイナミックインフラストラクチャプラットフォーム
- AWS、Azure、OpenStack、VMware vCloud
インフラストラクチャ定義ツール
　- Cloud Formation、Teraform、AWS CDK
サーバー構成ツール
- Chef、Ansible、Puppet
インフラストラクチャサービス
- モニタリング、サービスディスカバリ、分散プロセス管理、デプロイ系のツール

課題と原則
ダイナミックインフラストラクチャプラットフォーム
インフラストラクチャ定義ツール
サーバー構成ツール
主要なインフラストラクチャサービス
サーバーのプロビジョニングのパターン
サーバーテンプレート管理のパターン
サーバーのアップデート/変更のパターン
インフラストラクチャ定義のパターン
インフラストラクチャのソフトウェア工学プラクティス
インフラストラクチャの変更のテスト
インフラストラクチャの変更管理パイプライン
インフラストラクチャチームのワークフロー
継続性とダイナミックインフラストラクチャ
Infrastructure as Codeのための組織

印象的だったところ

業務でAWS CDKを使うことがよくあり「インフラストラクチャ定義ツール」の部分が気になっていたので3章と9章が印象的でした。

3章インフラストラクチャ定義ツール

この章では、インフラストラクチャ定義ツールを選択、利用する際のガイドラインを説明しています。

選択の要件は以下があります。

スクリプトで操作できるインターフェース
- GUIよりスクリプトで操作できるツール
コマンドラインツールの無人モード
- 自動化実行がしやすい
  　　- 実行時の(y/n)とかスキップできる
- 認証情報をコンソールに入れる代替手段が用意されている
無人実行のサポート
- 冪等性、事前・事後チェックが可能、パラメータを渡せる
設定の外在化
- 設定データをツール内にブラックボックス的に置かない
- 外部ファイルに設定データを置いて、渡せる形がいい

メジャーなツール(Teraform、CloudFormation、CDK)は上記の要件を満たしていると思います。

設定情報を渡す手段に構成レジストリを使うパターンがあります。
構成レジストリは設定値を集積する場所で、インフラストラクチャ定義ツールでその設定を使います。
(製品で言えば、Zookeeper、Consul、etcd)

構成レジストリとの密結合してしまうとエラーの原因になるという落とし穴があります。
著者が構成レジストリのWebサーバーのエントリ名を変更して、他の人が管理しているスクリプトで問題が発生したという話がありました。
問題を防止するために、設計と密なコミニケーションが必要と述べられていました。

私自身もIaCツールで色々な部分から参照されている設定値の編集時に、「ダウンタイムやエラーがでるんじゃないか」と恐怖を感じることがあります。
恐怖感を感じるとつい手動でやってしまって、IaC管理に挫折するきっかけになると思います。

設計を見直して本当にそこは共通の設定値にするべきかを検討するのが必要だと思いました。

9章　インフラストラクチャ定義のパターン

インフラの規模、複雑度増えると、中央集権的な統制を強化する方向に向かうことが多いです。
(インフラチームを作って、そのチーム以外は変更しないようなルールにしたり)

開発チームでインフラの変更を加えれないと、インフラチームとの調整などの手間が増えます。
スタックやインフラストラクチャ要素・IaCコードを適切に分割・共有することで開発チームでインフラの変更をしやすくします。

スタック

モノリスなスタックでは、変更が面倒になります。(フロント、アプリ、データベースですべて同じスタックにするなど)
変更の影響範囲も大きいですし、誰かにどこか壊される危険性が大きくなります。

適切な大きさに分割することで、上記のリスクを減らせます。
スタックの分割単位としては、独立に構築・アップデートできることを目安にするといいです。

分割することで、特定リソースの共有もしやすくなります。(異なるアプリスタックでデータベーススタックを共有したり。)

インフラストラクチャ要素

インフラストラクチャ要素の共有に関しても、紹介されていました。
アップデートしやすい単位に分けることで、変更プロセスにかかる時間を減らせます。

VPC、サブネット、セキュリティグループなど、頻繁な変更が発生せず、アプリケーションごとに異なってはいけないものは共有したほうがいいです。

IaCコード

IaCコードを共有する際は、以下の点に気をつけることで、問題点を回避できます。

共有モジュールのバージョン管理
共有ではなくコピー
オプションとしての共有
オーバーライドできるモジュール

「共有ではなくコピー」が印象的でした。
私自身もIaCコードを共有しすぎて、1つの変更が複数チームに影響を及ぼす問題を経験したことがあります。

具体的には、CDKでECSのライブラリを作っていました。
その際に、タスク定義やサービスの設定もライブラリに含んでいました。

ある日、ECSのサービスに設定変更(デプロイメントサーキットブレイカーの設定追加)を行いました。
使っているすべてのチームで、「cdk diff」でECSサービスの置き換えが発生しました。
ライブラリ側のCDKでCFnのプロパティ上書きするような書き方をすることで、なんとか置き換えを回避できましたが余計な変更コストが発生しました。

下手に共有しすぎると、迅速に変更できなくなるため本書で紹介されているように、設定値などはコピーするほう良さそうです。

IaCコードの共有が意味を持つ際の原則も紹介されていました。