読者です 読者をやめる 読者になる 読者になる

Immutable Infrastructure の現実的なポイント(抄訳+アルファ)

インフラ

Why you should build an Immutable Infrastructure | via @codeship

こないだの Codeship のブログ見てて、自分も今ちょうどまさにそこに取り組んでいたのでいやほんとそうだなーって思って、でもアホだからほっとくと自分でも自分がどういうゴールで仕事してるのかわかんなくなるんですよね…。なのでポイントだけ抜き出してみました。また例によって僕の言葉も入ってるので、実際に彼らが何と言ってるかは原文を確認してください。ちなみに会社にいる時間で20分くらいかけて書きました!!。ありがとうございます!!。

Immutable Infrastructure とは

  • その場で更新されること無く、必要に応じてデプロイ毎に交換される Immutable Component の集まり。
  • Immutable Component は単独及び独立にテスト・バリデート可能。

状態の隔離

  • システム全体としては状態を持つが、状態自体は特定のコンポーネント(群)に隔離する。
  • 状態による振る舞いの変更を予測可能な規模に丸め込むことが大事。
  • 複数のドメインの状態が混じると、何かが起こったときにそのシステムの神しか対応できなくなる。

Atomic なデプロイとバリデーション

  • 論理・物理ホストの構築からアプリケーションの設置までの「デプロイ」が Atomic でないと、その場限りの悪い意味でユニークな状態になってしまうことがある。
  • 今どんな状態か分からない、他に例が無い場合、デバッグが難しい。本番デバッグとかになる。
  • (可能なかぎりにおいて)デプロイを Atomic に近づけ、毎デブロイごとにホストからアプリケーションまで、コードによって構築する。
  • リリースはその Immutable Component を例えばロードバランサで切り替えることで行う。

時間がかかりすぎるのでは?

  • 構築用イメージをレイヤリングする。
  • それでもまだこれまでにくらべて時間がかかる。あるレイヤーの構築が外部リソース( gem, yum, curl... )に依存する場合失敗することもある。
  • Chef, Puppet, CFEngine, Ansible などを使うのだが、これらは Immutable Infrastructure のためのものでは無いので、大抵工夫が必要になる。
  • 新しいツールが待たれる。

速いリカバリー(歴史がそのまま残っているから)

  • 全てのデプロイは新しいイメージを作ることで行われる。
  • 古いイメージはそのまま歴史としてロールバックに利用できる。
  • データスキーマの変更は問題だが、それは未だロールバックというプロセスの問題だ。

実験とか新しいバージョンの導入が楽になるよ

  • なるよ

ログという状態はログ担当 Component に任せろ

  • Component を手で弄れないのは、ログという状態を切り出して隔離するよいきっかけ

まとめ

  • 状態!状態!状態!
  • 状態を把握しやすくする。
  • ある知見がどの状態において有効なのか把握しやすくする。蓄積しやすくする。
  • 状態に根ざした例外を把握しやすくする。