オライリーの「Infrastructure as Code」を読んで思ったことや自分的メモをまとめておく．太字は自分の感想， 斜字体は本からの引用 ，そのほかは本の要約など．

ダイナミックインフラストラクチャの要件

• NISTのクラウドの要件より広い．
  • 「オンプレミスで，ただひとつのシステムを稼動させるためのインフラ」も考慮に入れているからだろう

プラットフォームから提供されるリソース

• 計算リソース
• ストレージリソース
  • ブロックストレージ
  • オブジェクトストレージ
  • ネットワーク化されたファイルシステム
    • NFS，SMB
      • これらのテクノロジは，サーバーが頻繁に追加，削除されるような環境にはうまく適合しない
    • GlusterFS，HDFS，Ceph
      • 上記の課題に対応できるよう設計されているが，自分の環境でそれがうまくいっていることをきちんとテストすることが重要
      • 代わりにアプリケーションレベルやブロックレベルのレプリケーションで事足りる場合もある
• ネットワークリソース
  • 特定のデバイスが高価過ぎて，チームがテストインスタンスを確保できない場合がある．そのような状況に置かれたチームは，優先順位を考えてもっと安いデバイスを使うようにすべきだ
    • 確かに，結局のところ同じハードを同じだけ用意しないとテストできないのだが，そのために使うデバイスを安いものにしろ，という言説は初めて見た．だいたいは仮想化してお茶を濁すのに．

独自クラウドを構築するためのトータルコスト

• 既存のインフラ，データセンター，知識にかけたコストも自前のホスティングを続ける理由としてよく挙げられる．(中略) しかし，これはサンクコストの呪縛というものだ．

クラウドのポータビリティ

• クラウドインフラへの移行を計画するときによく浮上する要件のひとつに，ひとつのクラウドベンダーによる囲い込みを避けるというものがある．(中略) しかし，この要件に時間と金を注ぎ込みすぎないよう注意しなければならない
  • 確かに，クラウドの一部の機能をサードパーティ製のツールで置き換えたところで依然として移行のコストは大きいし，だいたいの場合は運用のコストが上がる
  • あるクラウドでのやり方が(将来にわたって)それが別のクラウドでそのまま利用できるとは限らない
    • 例えば，TerraformでEC2とGCEにインスタンスを作るだけで全く文法が違う(Terraformの批判をしているわけではない)
    • クラウドやツールが将来仕様変更をするかもしれないし
  • サードパーティ製のものを使うことでよりよりワークフローを得られる可能性がある場合は検討すべき(CodeCommitとCodeBuildの代わりにGithubとTravisCIとか)
• 自動テストプロセスを継続して維持・使用することで，自信をもって移行を実施できるようにしておくのが現実的な方策

クラウドと仮想マシンに対するマシンレベルの共感

• そのプラットフォームで最大のパフォーマンスを引き出すための話？
• 必要性は分かるが，ポータビリティとは真逆の話に見える
  • あまりにそのクラウドに最適化してしまうとポータビリティを落とす要因になりそう
• オンプレの場合でも，構成に応じて最適化しつつそれらを管理するのは大変そう．妥協して汎用的なサーバーを横に並べる形になりそう

参考文献

1. Kief Morris, Infrastructure as Code クラウドにおけるサーバ管理の原則とプラクティス, 長尾高弘訳, オライリー・ジャパン, 2017

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス amazon.co.jp