監訳者のmizzyさんからご連絡いただき、出版社の方からご献本いただきました。いつもありがとうございます!
原著、ずっと読みたいと思っていたところにすごく良いタイミングでの訳書出版で大変ありがたいです。
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者: Kief Morris,宮下剛輔,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/03/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
ここ数年、Infrastructure as Code や DevOps といったコンテキストで様々ツールが登場し、注目され、多くの現場で活用されているとは思いますが、まだまだ成熟しきっていない分野でかつ比較的トレンドやツールが移り変わりの激しいフェーズで、ツールで語られることも多い中、本書ではツールの使い方にフォーカスを当てるのではなく、あくまで「Infrastructure as Code」に対する考え方やコンセプトといった視点でわかりやすく網羅的に解説してくれます。
中身については、かなり詳細な目次が公開されており、本エントリの文末に引用させていただいているので、そちらをご覧いただければと思いますが、文中にサンプルコードは一部出てくるものの、特定のプロダクトに寄った具体的な手法の解説ではなく、あくまで思想・考え方やパターンなどのプラクティスが網羅的に解説されている良書だと思います。
前職の頃、私が担当していたサービスでは1000を超えるサーバノードを管理していて、サーバプロビジョニングという領域においてはかなり泥臭い運用をしていた事実もありますが、ハイトラフィックでかつ右肩上がりな成長サービスにおいて、それなりにツールを使った運用をして得られたノウハウがありました。それがこの書籍内において、ほぼ近い言葉やニュアンスで"プラクティス"や"アンチパターン"としてまとめられているものだから、筆者はそれなりに「サービス運用上での苦労」を積み重ね、この書籍を執筆したのだと想像がつきました。
例えば本書では、度々「オートメーション恐怖症」というキーワードが出てきますが、あるあるというかすごくよく分かるし、半自動化で運用されている現場はそれなりに多いのではないかなと勝手に思っています。
Aさんがあるオペレーションを自動化したとする。Aさんが退職等でその現場にいなくなる。その自動化されたオペレーションはしばらく動き続けるが、ビジネスの進化にあわせて追従できなくなり、次第に別の手法に置き換えられる。非属人的なオペレーションを正しく継続させるのは何気に難しい。
— Y.Namikawa / id:rx7 (@namikawa) March 12, 2017
そういえば1週間くらい前に上記のようなtweetをしました。これに関して意見・方法論は色々あるとは思うのですが、こういった話に対する考え方が15章の「Infrastructure as Codeのための組織」に書かれてあるなぁ、と思いながら読みました。15章は、いわゆる"DevOps"なチーム・組織を形成するための考え方やメソッド的な話が多く、原則としても「継続」といったキーワードが目立つ章です。
最後のまとめである「15.5 まとめ:決して終わりはない」がズバリな気はしますが、イニシャルコスト(一度限りのコスト)を支払ってITシステムでは終わりではなく、日々変化していくニーズに対して企業やビジネスが変わっていくのを助ける中心的な力である、と。ITシステムが満足させなければならないニーズは絶えず変化するものであり、それにあわせてITシステムを絶えず変化していくものだ、と締めていて、わかる人間からするとそりゃそうだよね、と全体を通して納得しました。
だらだらと感想を書いてしまいましたが、本書は、インフラに限らずシステムアーキテクトやエンジニアリングマネージャのポジションにいる方にも必携の書籍だと思います。
クラウドサービスを使ったサービス開発・運用をされている方は、目次を眺めるだけでもビビッとくるものがあるはず。
それでは!=͟͟͞͞(๑•̀=͟͟͞͞(๑•̀д•́=͟͟͞͞(๑•̀д•́๑)=͟͟͞͞(๑•̀д•́
Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス
- 作者: Kief Morris,宮下剛輔,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/03/18
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る
おまけ: 目次
第?部 基礎 1章 課題と原則 1.1 なぜInfrastructure as Codeなのか 1.2.I InfrastructureasCodeとは何か 1.2.1 Infrastructure as Codeの目標 1.3 ダイナミックインフラストラクチャが生み出した課題 1.3.1 サーバースプロール 1.3.2 構成ドリフト 1.3.3 スノーフレークサーバー 1.3.4 脆いインフラストラクチャ 1.3.5 オートメーション恐怖症 1.3.6 システム疲労 1.4 Infrastructure as Codeの原則 1.4.1 簡単に再現できるシステム 1.4.2 使い捨てにできるシステム 1.4.3 統一的なシステム 1.4.4 反復できるプロセス 1.4.5 絶えず変化するデザイン 1.5 プラクティス 1.5.1 定義ファイルの利用 1.5.2 自己記述システムとプロセス 1.5.3 あらゆるものをバージョン管理する 1.5.4 継続的テストシステム、プロセス 1.5.5 一斉変更ではなく小刻みな変更 1.5.6 継続的にサービスを利用可能状態に保つ 1.6 アンチフラジャイル:「堅牢」を越えて 1.6.1 アンチフラジャイルなITシステムの秘密の成分 1.7 まとめ 1.8 このあとの章について 2章 ダイナミックインフラストラクチャプラットフォーム 2.1 ダイナミックインフラストラクチャプラットフォームとは何か 2.2 ダイナミックインフラストラクチャプラットフォームの要件 2.2.1 プログラマブル 2.2.2 オンデマンド 2.2.3 セルフサービス 2.3 プラットフォームから提供されるインフラストラクチャリソース 2.3.1 計算リソース 2.3.2 ストレージリソース 2.3.3 ネットワークリソース 2.4 ダイナミックインフラストラクチャプラットフォームのタイプ 2.4.1 パブリッククラウドのIaaS 2.4.2 コミュニティクラウドのIaaS 2.4.3 プライベートクラウドのIaaS 2.4.4 アンチパターン:手回し式クラウド 2.4.5 ハイブリッド、ミックスクラウド 2.4.6 ベアメタルクラウド 2.5 ダイナミックインフラストラクチャプラットフォームに関する判断のポイント 2.5.1 パブリックかプライベートか 2.5.2 クラウドのポータビリティ 2.6 クラウドと仮想化に対するマシンレベルの共感 2.7 まとめ 3章 インフラストラクチャ定義ツール 3.1.I Infrastructure as Codeのためのツールの選択 3.1.1 要件:スクリプトで操作できるインターフェイス 3.1.2 要件:コマンドラインツールの無人モード 3.1.3 要件:無人実行のサポート 3.1.4 要件:設定の外在化 3.2 構成定義ファイル 3.2.1 構成定義の再利用可能性 3.3 インフラストラクチャ定義ツールの操作 3.3.1 手続き型スクリプトによるインフラストラクチャのプロビジョニング 3.3.2 インフラストラクチャの宣言的な定義 3.3.3 インフラストラクチャ定義ツールの使い方 3.3.4 サーバーの構成/設定 3.4 構成レジストリ 3.4.1 軽い構成レジストリ 3.4.2 構成レジストリはCMDBか 3.4.3 CMDBの監査、修正のアンチパターン 3.4.4 CMDBに対するInfrastructure as Codeのアプローチ 3.5 まとめ 4章 サーバー構成ツール 4.1 自動化されたサーバー管理の目標 4.2 さまざまなサーバー管理機能に対応するツール 4.2.1 サーバー作成のためのツール 4.2.2 サーバーの構成/設定のためのツール 4.2.3 サーバーテンプレートのパッケージングのためのツール 4.2.4 サーバー上でコマンドを実行するためのツール 4.2.5 中央のレジストリに格納されている構成/設定情報の使い方 4.3 サーバー変更管理のモデル 4.3.1 随時変更 4.3.2 構成/設定の同期 4.3.3 イミュータブルインフラストラクチャ 4.3.4 コンテナ化されたサービス 4.4 コンテナ 4.4.1 Rubyアプリケーション管理がコンテナによってどのように変わるか 4.4.2 コンテナは仮想マシンか 4.4.3 仮想マシンよりもコンテナ 4.4.4 コンテナの実行 4.4.5 コンテナのセキュリティ 4.5 まとめ 5章 主要なインフラストラクチャサービス 5.1 インフラストラクチャサービス、ツールが満たすべき条件 5.1.1 外部定義を使えるツールを選ぶ 5.1.2 インフラストラクチャがダイナミックだという前提で作られたツールを選ぶ 5.1.3 ライセンスがクラウド互換になっている製品を選ぶ 5.1.4 疎結合をサポートする製品を選ぶ 5.2 チーム間でのサービスの共有 5.2.1 サービスインスタンステンプレート 5.3 モニタリング:アラート、計測、ロギング 5.3.1 アラート:何かまずいことが起きたら教えてくれ 5.3.2 指標計測:データの収集と分析 5.3.3 ログの集約と分析 5.4 サービスディスカバリ 5.4.1 サーバーサイドサービスディスカバリのパターン 5.4.2 クライアントサイドサービスディスカバリのパターン 5.5 分散プロセス管理 5.5.1 サーバーロールによるプロセスのオーケストレーション 5.5.2 コンテナによるプロセスのオーケストレーション 5.5.3 短いジョブのスケジューリング 5.5.4 コンテナオーケストレーションツール 5.6 ソフトウェアのデプロイ 5.6.1 デプロイパイプラインソフトウェア 5.6.2 ソフトウェアのパッケージング 5.7 まとめ 第?部 パターン 6章 サーバーのプロビジョニングのパターン 6.1 サーバーのプロビジョニング 6.1.1 サーバーのライフサイクル 6.1.2 サーバーには何が含まれるか 6.1.3 サーバーに含まれるものの分類 6.1.4 サーバーロール 6.2 サーバー作成のパターン 6.2.1 アンチパターン:手作りサーバー 6.2.2 プラクティス:サーバー作成オプションをスクリプトでラッピングせよ 6.2.3 アンチパターン:ホットクローンによって作成されたサーバー 6.2.4 パターン:サーバーテンプレート 6.2.5 アンチパターン:スノーフレークファクトリ 6.3 新サーバーのブートストラップのパターン 6.3.1 プッシュブートストラップ 6.3.2 プルブートストラップ 6.3.3 プラクティス:すべての新サーバーインスタンスをスモークテストせよ 6.4 まとめ 7章 サーバーテンプレート管理のパターン 7.1 ストックテンプレート:ほかに管理してくれる人はいないか? 7.2 テンプレートを使ったサーバーのプロビジョニング 7.2.1 作成時のプロビジョニング 7.2.2 テンプレート内でのプロビジョニング 7.2.3 作成時のプロビジョニングとテンプレートによるプロビジョニングのバランスの取り方 7.3 サーバーテンプレートの構築プロセス 7.3.1 複数のプラットフォームのためのテンプレートの作成 7.4 原始イメージ 7.4.1 アンチパターン:ホットクローンによって作成されたサーバーテンプレート 7.4.2 OSインストレーションイメージからのテンプレートの焼き込み 7.4.3 ストックイメージからのテンプレートの焼き込み 7.4.4 ユニカーネルからのテンプレートの構築 7.4.5 ブートをしないサーバーテンプレートのカスタマイズ 7.5 サーバーテンプレートのアップデート 7.5.1 テンプレートの「温め直し」 7.5.2 フレッシュなテンプレートの焼き込み 7.5.3 サーバーテンプレートのバージョン管理 7.6 ロールのためのテンプレートの構築 7.6.1 パターン:階層化テンプレート 7.6.2 テンプレートのためのベーススクリプトの共有 7.7 サーバーテンプレート管理の自動化 7.7.1 焼き込み前のサーバーのカスタマイズ 7.7.2 プラクティス:サーバーテンプレートを自動テストせよ 7.8 まとめ 8章 サーバーのアップデート/変更のパターン 8.1 サーバー変更管理モデル 8.1.1 随時変更 8.1.2 継続的な構成/設定の同期 8.1.3 イミュータブルサーバー 8.1.4 コンテナ化サーバー 8.2 一般的なパターンとプラクティス 8.2.1 プラクティス:サーバーテンプレートを最小化せよ 8.2.2 プラクティス:サーバーテンプレートの変更時にサーバーを交換せよ 8.2.3 パターン:フェニックスサーバー 8.3 継続的デプロイのパターンとプラクティス 8.3.1 パターン:マスターレス構成管理 8.3.2 プラクティス:cronを利用せよ 8.3.3 継続的同期フロー 8.3.4 構成管理の対象外の部分 8.4 イミュータブルサーバーのパターンとプラクティス 8.4.1 アーティファクトとしてのサーバーイメージ 8.4.2 イミュータブルサーバーによる構成管理ツールの単純化 8.4.3 イミュータブルサーバーのフロー 8.4.4 イミュータブルサーバーのブートストラップ時の構成/設定 8.4.5 サーバーアップデートのトランザクション化 8.5 構成定義管理のプラクティス 8.5.1 プラクティス:構成定義を最小限に抑えよ 8.5.2 定義の構造化 8.5.3 プラクティス:優れた設計を生み出すテスト駆動開発(TDD)を使え 8.6 まとめ 9章 インフラストラクチャ定義のパターン 9.1 環境 9.1.1 アンチパターン:手作りのインフラストラクチャ 9.1.2 インフラストラクチャスタックをコードとして定義する 9.1.3 アンチパターン:環境ごとの定義ファイル 9.1.4 パターン:再利用できる定義ファイル 9.1.5 プラクティス:スタック定義をテスト、プロモートせよ 9.1.6 セルフサービス環境 9.2 インフラストラクチャの構造化 9.2.1 アンチパターン:モノリシックスタック 9.2.2 「リフトアンドシフト」によるインフラのマイグレーションを避ける 9.2.3 アプリケーション環境の複数のスタックへの分割 9.2.4 スタック間での構成/設定パラメータの管理 9.2.5 インフラストラクチャ要素の共有 9.2.6 プラクティス:アプリケーションコードとインフラストラクチャコードを統一的に管理せよ 9.2.7 定義の共有に対するアプローチ 9.2.8 プラクティス:変更の範囲に合わせてインフラストラクチャを設計せよ 9.2.9 実例:マイクロサービスのためのインフラストラクチャ設計 9.3 定義ツールの実行 9.4 まとめ 第?部 プラクティス 10章 インフラストラクチャのためのソフトウェア工学プラクティス 10.1 システムの品質 10.1.1 品質の低いシステムは変更が難しい 10.1.2 高品質システムは従来よりも簡単かつ安全に変更できる 10.1.3 インフラストラクチャの品質の着目点 10.1.4 高速フィードバック 10.2 インフラストラクチャ管理のためのVCS 10.2 .1 VCSで管理すべきもの 10.3 継続的インテグレーション(CI) 10.4 継続的なブランチのテストは継続的インテグレーションではない 10.4.1 ビルドエラーの原因究明 10.4.2 失敗したテストの無視 10.4.3 インフラストラクチャのためのCI 10.5 継続的デリバリー(CD) 10.5.1 インテグレーション段階の問題点 10.5.2 デプロイパイプラインと変更パイプライン 10.5.3 継続的デリバリーは継続的デプロイではないということ 10.6 コードの品質 10.6.1 クリーンコード 10.6.2 プラクティス:技術的負債をマネジメントせよ 10.7 大きなインフラストラクチャ変更の管理 10.7.1 機能トグル 10.8 まとめ 11章 インフラストラクチャの変更のテスト 11.1 テストに対するアジャイルのアプローチ 11.1.1 高速フィードバックのためのテストの自動化 11.1.2 テストスイートの有機的な構築 11.2 テストスイートの構造化:テストピラミッド 11.2.1 バランスの悪いテストスイートにならないようにするために 11.2.2 プラクティス:できる限り低い水準でテストせよ 11.2.3 プラクティス:必要な階層だけを実装せよ 11.2.4 プラクティス:テストスイートをひんぱんに刈り込め 11.2.5 プラクティス:テストの有効性を継続的に評価せよ 11.3 バランスの取れたテストスイートの実装 11.3.1 低水準テスト 11.3.2 中水準テスト 11.3.3 高水準テスト 11.3.4 運用品質のテスト 11.4 テストコードの管理 11.4.1 プラクティス:テストコードとテスト対象のコードをいっしょに管理せよ 11.4.2 アンチパターン:反射的テスト 11.4.3 テストのためのコンポーネントの切り離しのテクニック 11.4.4 コンポーネントを切り離せるようにするためのリファクタリング 11.4.5 外部依存コンポーネントの管理 11.4.6 テストのセットアップ 11.5 テストのロールとワークフロー 11.5.1 原則:構築したものに対するテストは自分で書け 11.5.2 テストを書く習慣 11.5.3 原則:全員がテストツールを使えるようにせよ 11.5 .4 QAアナリストの価値 11.5.5 テスト駆動開発(TDD) 11.6 まとめ 12章 インフラストラクチャの変更管理パイプライン 12.1 変更管理パイプラインのメリット 12.2 パイプライン設計のガイドライン 12.2.1 ステージ間での統一性を保証せよ 12.2.2 すべての変更にすばやくフィードバックを返せ 12.2.3 マニュアルステージの前に自動ステージを実行せよ 12.2.4 できる限り早く本番環境に近い環境でテストせよ 12.3 パイプラインの基本設計 12.3.1 ローカル開発ステージ 12.3.2 ビルドステージ 12.3.3 構成アーティファクトの公開 12.3.4 自動テストステージ 12.3.5 人間による確認/チェックステージ 12.3.6 本番環境への適用 12.3.7 パイプラインのリズム 12.4 パイプラインを使うためのプラクティス 12.4.1 プラクティス:すべての変更で本番対応の品質を証明せよ 12.4.2 プラクティス:すべての変更をパイプラインの先頭からスタートさせよ 12.4.3 プラクティス:失敗が起きたらラインを止めよ 12.5 より複雑なシステムへのパイプラインのスケールアップ 12.5.1 パターン:ファンインパイプライン 12.5.2 プラクティス:パイプラインを短く保て 12.5.3 プラクティス:パイプラインを分割せよ 12.5.4 インテグレーションモデル 12.6 コンポーネントの間の依存関係を処理するテクニック 12.6.1 パターン:ライブラリ依存 12.6.2 パターン:サービスインスタンスのセルフプロビジョニング 12.6.3 プレリリースライブラリのビルドの提供 12.6.4 コンシューマに対するサービスのテストインスタンスの提供 12.6.5 コンシューマとしてサービスのテストインスタンスを利用する 12.7 コンポーネント間のインターフェイスを管理するためのプラクティス 12.7.1 プラクティス:インターフェイスの下位互換性を確保せよ 12.7.2 プラクティス:リリースとデプロイを切り離せ 12.7.3 プラクティス:バージョン耐性を保証せよ 12.7.4 プラクティス:テストダブルを用意せよ 12.7.5 プラクティス:コントラクトテストでプロバイダをテストせよ 12.7.6 プラクティス:参照コンシューマを使ってテストせよ 12.7.7 プラクティス:プロバイダインターフェイスをスモークテストせよ 12.7.8 プラクティス:コンシューマ主導のコントラクト(CDC)テストを実施せよ 12.8 まとめ 13章 インフラストラクチャチームのワークフロー 13.1 動くものは何でも自動化する 13.1.1 手作業による変更 13.1.2 その場しのぎのオートメーション 13.1.3 自律的なオートメーション 13.1.4 自律的なオートメーションのワークフロー 13.2 ローカルサンドボックスの使い方 13.2.1 ローカル仮想化を使ったサンドボックス 13.2.2 ローカルテストのサンプルワークフロー 13.2.3 仮想化プラットフォームを使ったサンドボックス 13.3 コードベースの構造化のパターン 13.3.1 アンチパターン:ブランチを基礎とするコードベース 13.3.2 パターン:コンポーネントごとのトランク 13.3.3 パターン:単一のトランク 13.4 ワークフローの有効性 13.4.1 変更の加速 13.4.2 コードレビュー 13.4.3 ワークフローにガバナンスを組み込む 13.5 まとめ 14章 継続性とダイナミックインフラストラクチャ 14.1 サービスの継続性 14.1.1 本物の可用性 14.1.2 復旧のためのダイナミックサーバープール 14.1.3 ダイナミックインフラストラクチャを意識したソフトウェア設計 14.1.4 継続性のためのコンパートメント化 14.2 ゼロダウンタイム変更 14.2.1 パターン:ブルー-グリーン交換 14.2.2 パターン:フェニックス交換 14.2.3 プラクティス:交換のスコープを絞り込め 14.2.4 パターン:カナリア交換 14.2.5 ゼロダウンタイム交換のためのトラフィックのルーティング 14.2.6 データをともなうゼロダウンタイム変更 14.3 データの継続性 14.3.1 レプリケートによる冗長なデータの生成 14.3.2 データの再生成 14.3.3 データの永続化の委託 14.3.4 永続ストレージへのバックアップ 14.4 ディザスタリカバリ 14.4.1 継続的ディザスタリカバリ 14.4 .2 DRプラン:災害のためのプランニング 14.4.3 プラクティス:コールドスタンバイではなく再構築せよ 14.4.4 パイプラインによる継続的なモニタリング 14.5 セキュリティ 14.5.1 システムブリーチの自動的な消去 14.5.2 防御としての信頼性の高いアップデート 14.5.3 パッケージの出所 14.5.4 ハードニングの自動化 14.5.5 パイプライン内でのセキュリティチェックの自動化 14.5.6 脆弱性としての変更管理パイプライン 14.5.7 クラウドアカウントによるセキュリティリスクのマネジメント 14.6 まとめ 15章 Infrastructure as Codeのための組織 15.1 発展的なアーキテクチャ 15.1.1 実戦演習 15.1 .2 Trailblazerパイプラインから始める 15.2 効果測定 15.2.1 求める結果について合意を得ることを優先する 15.2.2 チームのために役立つ指標を選択する 15.2.3 リードタイムの監視と改善 15.2.4 カンバンを使った仕事の可視化 15.2.5 レトロスペクティブとポストモーテム 15.3 ユーザーに力を与える組織 15.3.1 職能分割モデルの落とし穴 15.3.2 セルフサービスモデルを採り入れる 15.3.3 完全な責任を引き受ける:構築するのも運用するのも同じチーム 15.3.4 職能横断型チームの組織 15.4 継続的変更管理を通じたガバナンス 15.4.1 信頼できる部品の供給 15.4.2 パイプラインによる運用準備完了の証明 15.4.3 品質に対する責任の共有 15.4.4 自動プロセスのレビューと監査 15.4.5 問題点を検出、是正するための時間の短縮化 15.5 まとめ:決して終わりはない