Immutable Infrastructure Conference #1 に参加してきた #immutableinfra

とてもおもしろかったです。ありがとうございました！

以下個人メモ

Chef

• 手順書の代わりにコードにする
• Communityモノは必要以上に汎用性を持たせて複雑化していたり
  include_recipeなど必要以上に密結合していたりするので基本的に利用しない
• 複雑なコード、複雑な処理にならないようにする
• ShellScriptやSalt、Ansibleなどで問題が解決できるなら何でもいい

Golden Image

• 同じ環境のサーバが簡単にできる
• Golden Imageを常にゼロからつくれることが前提
• Golden Imageに変更があればドキュメントを更新する？

サービスを最新の状態にする

• pull？
• rsync？
• ミドルウェアの変更は手動？

機能毎のサーバの理想型

• インスタンスが勿体無いという理由で複数の機能を持たせている
• 機能毎にインスタンスが分かれていれば疎結合で柔軟性を持たせることができる
• インスタンスに障害が発生した時に影響を最小限にしつつ、
  容易に同じインスタンスが作成できる

2014年にも存在している問題

• 秘伝のタレ化したサーバ
• 更新されることのないサーバ構築手順書
• 何が動いているかわからないサーバ
• 担当者しかわからない構成
• 入り組んだシンボリックリンク
• 謎のパーミッション
• 誰も知らないプロセス

Immutable Infrastructureで解決できるか

• サーバは最小限の機能だけを持たせる
• 機能が最小限なので何が動いているか理解しやすい
• サーバは最小限の機能だけを持つので
  サーバに問題があった場合、少ない工数で新しいサーバを起動できる

課題

• サーバの状態のバージョニング管理(Docker以外で)
• メトリクスデータの管理方法(Host毎ではなくRole毎に管理する方法の確立)
  (@mirakuiさんとちょっと話したんですが、上手く動けばまたちゃんと書きます)
• 機能毎のサーバとは言うものの、サーバが増えれば管理コストが増えたり
  費用が増えたりするので、そういうところに投資できる
  一部の余裕のある企業だけが導入できる話であって基本的な企業では不可能なのでは

Immutable Infrastructure、海外だとNetflix社が圧倒的な感じでやっていて
他にもこんな話などちょくちょく見つかるけど、
まだまだ色々試されている段階だと思う。

個人的には、便利にする為の機械を扱う為に、1byteでも間違えると
サービスが落ちたりデータが損失したりするのは原始的だと思う。
本当なら影響の度合いによって、作業する前に祈りとか踊りとかする必要がある。
そうすることで作業自体の重要性を理解して、集中することができる。

しかし、現実はそんなことをしていたらサービスはどんどん腐っていく。

例えば靴のことを考えると、
靴を24時間365日履いて歩き続けたらどこかで問題が出ると思う。

• 靴紐が解ける
• 靴底に穴が開く

その時に歩くのを止めるという選択肢がない場合

• 別の靴を履く
• 靴紐がほどけた時にすぐに結べるようにしておく
• 靴底が簡単に外せて新品のものに簡単に交換できるとか
  

そういうことを考える。

技術によって、選択肢が増えた2014年の現在
どのようにサービスを発展させて、運用を楽にするか考える良いタイミングだと思う。

良いタイミングだけど、歴史を紐解くと
革新的な出来事は常に一人の天才が行ってきたことで
群衆はそれに感動する場合が多い。

天才にはなれないけどああだこうだやるのはできるので、
ああだこうだしていきたい。

歴史を紐解くの紐と靴のくだりの紐は結果的に踏んだ感じになっただけです。