「Seeking SRE Chapter 11. Immutable Infrastructure and SRE」メモ

はじめに

Seeking SREで気になる章を読んでいます。

Sre in Practice

前回はサービスをメッシュしていました。

blog.chaspy.me

今回はImmutable Infrastructureがテーマ。

結論、あんまり真新しいことは言っておらず、「Immutable Infrastructure最高！！！いろんな面で！！！」って感じで、まぁ内容も確かになって感じでした。

個人的にはConfiguration Managent Tool（like Chef, Puppet)との比較がされていて、そちらと対するようなことを言っていて、別に対立するものではなく両立するものでは？と思いました。あくまでアプリケーションの話だろうけど。周辺のインフラの設定に対してはどういう考えなんだろう。そこはConfiguration Managent Toolを使うべきだと思うけどなぁ。

あとは利点ばかりではなく（たった２つだけど）不利な点も述べられていてよかった。まぁそりゃそうだって感じだけど。ここでデータベースが出てくるってことはやっぱりELBみたいなものの設定変更もイメージに固めてしまえって感じなのかなぁ。ELB自体もイメージから再作成する感じで。まぁ悪くはないけど、設定変更して再起動するだけ、であれば別にConfiguration Managent Toolで十分感はある。

では以下簡単なメモ。

Chapter 11. Immutable Infrastructure and SRE

• Immutable Inftastractureは大規模なサーバを管理するコストを減らしたよ
• システム内の変数を減らして、同一のサーバを作り出すことで変更可能性を高めたよ

Scalability, Reliability, and Performance

• SREは大変だけど、Immutable Infrastractureの効果は絶大だよ
• 小さなイメージに必要なソフトウェアをインストールしたものをリリースし、その後Puppet, Chef, SSHなどあらゆる方法でも一切変更がされない方法をImmutable Infrastractureというよ。
• Immutable Infrastructureはスケーラビリティとパフォーマンスを提供するよ。手動で数十台なら変更できたとしても、100台、1000台は骨が折れるし、エラーを起こしがちだけど、Immutable Infrastactureであればそれを回避できるよ。
• ChefやPuppetのような構成管理ツールは最初はうまくいくけど、規模が大きくなると、特に動的に拡張するときにうまくいかなくなるよ。

Failure Recovery

• Immutable infrastructureは障害からすぐに復旧するのにも役立つよ。ハードウェア障害が起きてもイメージからすぐに再作成すればいいからね。加えてNetflixのChaos Monkeyテストのように耐障害性を高める取り組みもできるよ。

Simpler Operations

• Immutable infrastructureであれば変更操作もシンプルになるよ。だって新しいものに置き換えるだけだから、状態変化に気を使う必要がなくなるよね。

Faster Startup Times

• Immutable infrastructureであれば、ビルドには時間がかかるけど、起動時間ははるかに短縮できるよ。このおかげで、短い起動時間の範囲のみ予想すればよく、スケールアウト/ダウンが容易かつ効果的になるよ。

Known State

• SREやセキュリティーチームにとってもImmutableでないサーバの管理は懸念がたくさんだよ。

Continuous Integration/Continuous Deployment with Confidence

• Immutable infrastructureでない場合、微妙な変更差分がデプロイの失敗を招き、「テスト環境ではうまくいったんだ！」ということを起こしかねないよ。Immutable infrastructureであれば、Blue/Green Deploymentによってロールアウトとロールバックがスムーズにできるからいいよ。

Security

• セキュリティの観点でもImmutable infrastructureは大切だよ。
  • 一時的にインストールしたライブラリがあったりして脆弱性を放置してしまうことを防ぐ
  • セキュリティパッチの適用も通常のデプロイと同じフローで行えるから安全
  • 何よりKernelのアップデートのような再起動を伴うパッチ適用も、事前にインストールした状態で配れるから安全だし速いよ

Multiregion Operations

• 複数リージョンでもImmutable infrastructureであれば複製が容易だよ。構成管理だと難しいよ。

Release Engineering

• 開発者にとってインフラの設定変更はおそろしいものであり、運用者のレビューなしでは適用できず、設定管理ツールが持つ言語を習得する必要があるよ。Immutable infrastructureであればこういった懸念事項はなくなるよ。

Building the Base Image

• immutable infrastructureを行う最初の一歩は良いイメージを作ることだよ。
• 小規模なサービス（shop）であればLinux Dist.のイメージを使うといいよ。
• それなりに規模のあるサービスであれば、
  • 不要なパッケージを取り除き、
  • セキュリティアップデートがされ、
  • 共通ライブラリや内部で使うパッケージをインストールされたイメージを作るといいよ。
• 新しいイメージを展開するときは、優先度の低いサービスに対して、カナリアでリリースするといいよ。

Deploying Applications

• 必要なパッケージはベースイメージにインストールされ、展開するコードも何らかのパッケージングシステムにより更新されるよ。

Disadvantages

• 永続的なデータレイヤーにはImmutable Infrastructureの適用は難しいよ。1台ずつ変更すべきで、構成管理の方法が向いてるよ。
• イメージの更新に時間がかかるのも問題だよ。開発者がちょっとした変更を行うのにビルドを待つのはやりたくないよね。一時的に開発環境へのコードの変更を容易にすることでバランスをとりたいよね。

Conclusion

• 導入できたら開発者はよりプロダクト開発に集中でき、アプリケーションの展開時間を短縮でき、信頼性のあるインフラを実現できるね！ :+1