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

てくなべ

インフラ、ネットワーク、自動化などの技術的なことを書いていきます。

オライリー「Infrastructure as Code」で印象に残ったポイント

先日、オライリー「Infrastructure as Code」の日本語版が発売されました。 www.oreilly.co.jp

副題にある通り「原則とプラクティス」をメインに書かれていて、特定のツールに依存しない内容になっています。 特に1章「課題と原則」は何度も読み直したくなる内容でした。(さらに言うと"1.2.1 Infrastructure as Code の目標" は壁に貼っておきたいような内容)

全体としては 「 予防より復旧 」が重要という印象をうけました。

一通り読んでみましたので、個人的に印象に残ったポイントをまとめます。

1. 大きな変更より小さな変更を日常的にする

  • 小さな変更のほうが失敗したときに問題を特定しやすく、戻しやすい。
  • 小さな変更のほうが確実に改善でき、モチベーションも保たれる。

2. システムを絶えず変更し、改良しているチームの方が大小の障害に対処できる力を持っている

  • “1.6 アンチフラジャイル:「堅牢」を超えて” からの引用。
  • 人体と同じように負荷、変更を避けると弱くなる。負荷、変更によって強化される。

3. 正しい設計は継続的に変化していく

  • “15.1 発展的なアーキテクチャ” からの引用。
  • 完全で「最終的な」設計にたどり着くことはない

4. 高速フィードバック

  • 誤りは早く検出、フィードバックさせることが品質を向上させる。
  • そのためにはモニタリングが重要。

5. 従来のインフラからマイグレーション時の注意点

  • 従来のパターンを当てはめようとすると、かえって複雑になる可能性があるため、今までの概念を破る必要がある。

6. おまけ:初めて聞いた言葉

「変更ドリフト」

  • 設定差異のこと。差異があること自体は悪くないが、管理できていなくてはならない。管理できていない差異はオートメーション恐怖症を生み出す。

スノーフレークサーバー」

  • 他と異なるサーバーのこと。なぜ異なるのか分からなかったり、再構築できない状態は問題である。

「システム疲労」

  • 時間の経過でインフラが壊れていくこと。要因としては、脆弱性、ストレージの残容量など。

「フェニックス交換」

  • ブルー - グリーン 交換の進化形で、Immutable Infrastructure の基礎。

Infrastructure as Code の考え方を知るにとても良い本だと感じました。