ひだまりソケットは壊れない

ソフトウェア開発に関する話を書きます。 最近は主に Android アプリ、Windows アプリ (UWP アプリ)、Java 関係です。

まじめなことを書くつもりでやっています。 適当なことは 「一角獣は夜に啼く」 に書いています。

読んだ : Infrastructure As Code

書籍 書評 インフラ

インフラやっていくぞー、という気持ちで去年の中ごろに読んだ。

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

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

本書では最初 (第 1 部) に 「なぜ Infrastructure as Code が必要なのか」 「Infrastructure as Code とは何なのか、何を目指しているのか」 といった説明から始まり、Infrastructure as Code に関わるサービスやツールの紹介がなされる。 そして 2 部では、1 部で紹介されたツールなどを使ったサーバーの追加や変更といったインフラストラクチャの運用のパターンが紹介される。 最後の 3 部はプラクティスで、ソフトウェア工学のプラクティスを応用することや Infrastructure as Code のための組織といった部分の話がなされる。

自分は、Infrastructure as Code とはインフラ構成管理をコード化することで手順を再現できるようにしたり、バージョン管理できるようにしたり、自動化できるようにすること、というぐらいの理解しかない状態で読み始めたのだが、本書で説明される Infrastructure as Code はソフトウェア工学のプラクティスを応用するなど、もともと自分が想定していたものよりもさらに進んだものだった。 また、本書は 「なぜこういう考え方をするのか」 という思想的な部分も丁寧に説明しており、納得しやすい。 学びの多い良い本であった。

特に気になった内容のメモや感想

  • Infrastructure as Code の原則
    • 簡単に再現できるシステム
    • 使い捨てにできるシステム
    • 統一的なシステム
    • 反復できるシステム
    • 絶えず変化する設計
  • Infrastructure as Code の原則
    • 定義ファイルの利用
    • 自己記述システムとプロセス
    • あらゆるものをバージョン管理
    • 継続的テストシステム、プロセス
    • 一斉変更ではなく小刻みな変更
    • 継続的にサービスを利用可能状態に保つ
  • 「アンチフラジャイル」 という概念 : ストレスを受けたときに通常よりも強くなるシステム (インシデント発生時の対応として改良することをデフォルトの対応とする)
  • 「スタック」 の概念 : 一つの単位として定義・変更される、インフラストラクチャ要素の集合
    • スタックの単位で構造化していく : 単純な構成だとスタックへの分割の恩恵はないが、リソースの共有などをする場合には意味がある
    • スタック間の情報のやり取りに構成レジストリが役に立つ
  • システムの品質について、機能的な正しさの問題だと思われてしまうことが多いが、実際には変化を許すかどうかを決める鍵を握っている
    • 高品質システムは従来よりも簡単かつ安全に変更できる
  • 継続的なブランチのテストは継続的インテグレーションではない
    • 継続的インテグレーションとは、すべての作業がトランクで行われて、すべてのコミットがテストされることが保証される。 完全にチェックされた変更だけが本番システムに適用されることを保証するためには継続的デリバリーパイプラインを使う。
    • 思想としてはよいと思うが実践的にはレビュー等どうするのだ？？ という気がする。 (機能を完全に実装する前の小さい変更の状態でブランチをマージしていく、ぐらいが実践的な気がする。)
  • 変更パイプライン : ソフトウェアのデプロイパイプラインに相当するもの (ソフトウェアのデプロイとは違うことを区別するために著者はこう呼んでいる)
  • 継続的デリバリーは継続的デプロイではない : 継続的デリバリー (CD) とは、すべての変更をすぐに本番に送り込める状態に高めること。 デプロイ判断を下したら後はツールがデプロイしていく (システムの稼働が技術的な判断になるのではなくビジネス上の判断になる)
  • インフラストラクチャの変更のテストでもソフトウェアのテストと同じく、低水準のものを多く、高水準のものを少なくする (テストピラミッド)
    • これに限らず、テストのプラクティスは結構ソフトウェアのテストと似ている部分が多いなーと感じた
  • リリースとデプロイを切り離すというプラクティス
    • 機能トグルとかゼロダウンタイム交換パターンとか
  • コンシューマ主導のコントラクト (CDC) テスト
    • コンシューマが提供するテストをプロバイダ側のパイプライン上で動かす
    • ソフトウェア開発のクライアントとサーバー間でも使えそう
  • ワークフローにガバナンスを組み込む
    • 承認などのフローも自動化してログの保持などをすることで、手での承認よりも良いものになる
  • ゼロダウンタイム変更のパターン
    • ブルー・グリーン交換 : ソフトウェアにおけるブルー・グリーンデプロイパターンをインフラストラクチャに応用したもの。 2 つのインスタンス群を切り替える
    • フェニックス交換 : ブルー・グリーン交換を進化させたもの。 常にインスタンス群を 2 つ用意しておくのではなく、必要になったときに新たに用意する
    • カナリア交換 : 全体を一気に切り替えるのではなく、システム全体のうちの一部ずつを新しいものに変えていく。 大規模システムでは上記は採用できないので、この方法になる (Google や Facebook などで採用)
  • 企業が変化するニーズに対して信頼できる高品質のサービスで応えていくための組織面での原則
    • サービスの設計、実装、改良に対して継続的にアプローチしていくこと
    • 継続的にサービスをデリバリー、改良する権限をチームに与えること
    • 継続的にスピーディに変更をデリバリーしつつ、高い品質とコンプライアンスを保証すること
  • 効果測定。 目標と状況に基づいて役に立つものを選択
    • インフラチームが良く使っているのはリードタイム、平均修復時間 (MTTR)、平均故障間隔 (MTBF)、可用性、本物の可用性など
  • ユーザーに力を与える組織
    • プラクティス
      • セルフサービスモデル (使う人が作る)
      • Dev と Ops を (構築も運用も) 同じチーム : 運用時の問題から構築のチームが学習しづらい
      • 職能横断型チーム : 複数のプロジェクトの間でマルチタスクをこなす必要がなくなり、効率的に
        • このチームでは専門性の維持に課題があるが、「トライブ」 などのチーム横断型のコミュニティで対応
    • 職能分割モデルには落とし穴がある
      • 設計の細分化 : 設計と仕様が中央で作られて、実装のために様々なチームに分配される。 チームからは全体像が見えない
      • 厳格な日程管理 : 各チームが複数プロジェクトに関わることになるので、日程管理が重要になってくる
      • 長いリードタイム : チーム間の作業の一つ一つがオーバーヘッドを生む



ウケた