読了: Infrastructure as Code
Infrastructure as Codeを読み終えた。これは読み返さねばならない。なにより振り返りながら会社の現状に諦めずに直そうと感じた。
本書ではダイナミックインフラ(クラウド的な計算リソース)を利用してインフラのオートメーションを実現するプラクティスや指針と実践例を説明している。
本の流れ
Infrastructure as Code を解説している。
これはインフラのオートメーションを生み出すアプローチで、インフラ定義をテキスト管理することを基礎にしている。 テキスト化することで継続的インテグレーション(CI)をはじめとしたソフトウェア開発のプラクティスを適用できる。 統一的で反復的なテスト・検証を通過させ継続的デリバリーを実現する。
目指すのはアンチフラジャイル(堅牢性の先にあるもの)。
継続的デリバリーを基盤として、サービスの継続性・ゼロダウンタイム・データの継続性・ディザスタリカバリ・セキュリティ対策といった運用品質の向上を図っていくか説明している。
最後に、これらを生み出し改善し続ける組織や実践例で締めている。
感想
継続的デリバリーを実現できれば、検証された成果物が安定的に供給され続ける。 そこで考えるべきは、システムをどのような成果物の組み合わせとして捉えるかになる。
この成果物はパッケージやバイナリの他にサーバーイメージやコンテナ、構成定義ファイルなどがある。 明記されなかったがインフラ定義ファイルも含まれる。
インフラ定義の継続的デリバリーでは、インフラ定義ファイルや構成レジストリへの登録を成果とするときもあれば、それらを使ったプロビジョニングとするときもある。この選択はビジネス的な選択になる。
インフラ定義のテストにもロールテストやサービス全体といった高水準なテストがある。 これは他の多くの成果物に依存している。
他の成果物のパイプラインとインフラ定義のパイプラインをどのように関連づけるかで悩みそうだと感じた。 本書で書かれていたファンインは書かれていた通り無駄に頻度が高くなりそうだと感じる。
とりあえずパイプラインの嬉しい条件を考えてみた。
- 定義ファイルのパイプラインは定期実行される
- 依存している成果物は全てのテストが通過したデリバリー済みバージョンを利用する
- 依存する成果物のバージョンを外部から指定することも可能
- 通過したら構成レジストリなどに記録される
- 定義ファイルの成果物を使ったプロビジョニングできる
次に、稼働しているシステムの運用品質を高めるためにどうするかも自分なりのアプローチを整理する。
- 基本的にイミュータブルサーバーイメージやコンテナといった方法で実行環境の可変部分を減らして利用する
- イメージの実行を管理してくれるマネージャを利用する
- コンテナならk8s
- サーバーイメージならそれぞれのダイナミックインフラから提供されているサービス
- サーバーイメージの場合に構成管理ツールを使う場合がある
- パイプラインで稼働しているサーバーに対して定期実行することで差が生まれることを避ける
- プールとして管理されているコンテナ、サーバーイメージは寿命などでランダムに停止させて入れ替える(フェニックスサーバー)
ほぼ書かれていることをピックアップしているだけだが、現場で考えるべきところは自分で選べ考えろという感じが伝わってきた。
実行環境の定義は基本的にコンテナを選ぶべきだと考えている。 ただしDigdagなどDockerを呼び出す使い方をするスケジューラやJava10未満などはサーバーイメージで準備することになると考えている。
アンチフラジャイルなシステムを目指すうえで役立つ指標が載せられていた。
- リードタイム
- 平均修復時間(MTTR)
- 平均故障間隔(MTBF)
- 可用性
- 本物の可用性(計画メンテナンスを考慮しない)
MTBFだけなど重要性に偏りを持たせ過ぎずにすることが大事。
他には、テストの実践方法や定義やリポジトリの構成をどうするか障害対応など色々なことが書かれていて消化しきれていない。読み返そうと思った。
まずは早くサーバーイメージ化とコンテナ化を完了させてパイプラインを安定稼働させたい。 そのあとテストを増やしたり構成レジストリを利用したりプロビジョニングをバージョニングしたい。