AWS CDK入門 ――IaCによる安全・効率的なWebアプリ運用（技術評論社） [電子書籍]

AWS CDK入門 ――IaCによる安全・効率的なWebアプリ運用（技術評論社） の 商品概要

• クラウド上のアプリケーション運用の効率化や信頼性の向上のために，IaC（Infrastracture as Code）の導入の方法や運用の仕方を紹介します。よくありがちな失敗事例に触れながらIaCツールであるAWS CDK（Amazon Cloud Development Kit）を用いた安全で効率的なシステムの運用方法について示します。「システムテストは問題なかったのにいざリリースしたら問題が起きてしまった」のように，単にIaCを単に活用しても本質的な課題の解決になりません。真正面から問題をとらえ，どのように解決したか，実例を挙げながら解説していきます。
  

• 目次

  第0章 Webアプリケーションの運用の理想と現実
  0.1 業務向けWebアプリの開発スタート
  0.1.1 クラウドでシステム構築する際の問題解決
  0.1.2 QCDSの決定とウォーターフォールモデル
  0.1.3 クラウドにすべきか，オンプレミスにすべきか
  0.2 理想の業務システム
  0.2.1 変化に対応するシステムが理想
  0.3 本書で取り上げるシステムのアーキテクチャ
  0.3.1 AWSアーキテクチャ
  0.3.2 各種環境の解説
  0.3.3 Infrastructure as Codeの必要性
  0.4 開発チーム・基盤チーム・デリバリーチームの役割
  0.5 本書の読み進め方
  0.5.1 IaCは魔法の杖か
  0.5.2 運用改善のサイクルを作る
  
  第1章 本番リリースをすると，なぜか問題発生
  1.1 本番システムをリリースするときに問題が起こるのはなぜか
  1.2 リリース作業時トラブルの実際
  1.2.1 テストでは問題なし。しかし本番環境で動作不良？
  1.3 リリース作業に向けたプロセス
  1.3.1 ［1］リリース計画の作成
  1.3.2 ［2］各チームの作業項目の整理
  1.3.3 ［3］手順書の作成
  1.3.4 ［4］リハーサルの実施
  1.4 リリース作業でのエラー発生
  1.4.1 再デプロイの実施，動作確認終了まで3時間超過
  1.4.2 一難去ってまた一難
  1.4.3 手探りで原因の切り分け
  1.5 ECS構築時のトラブル
  1.6 AWSの設定構築の落とし穴
  1.6.1 原因［その1］「大量の設定パラメータと頻繁な変更？」
  1.6.2 原因［その2］「クラウド運用とアプリケーション運用が絡みあう？」
  1.6.3 原因［その3］「チーム間の連携の不備？」
  1.7 まとめ
  
  第2章 IaCの導入による問題解決
  2.1 AWS CDKの導入
  2.1.1 AWSの設定値情報を振り返る
  2.1.2 AWSの構成管理
  2.1.3 AWSの設定値の管理の難しさ
  2.1.4 IaCを使った改善活動
  2.2 AWSを管理するためのドキュメントの整理
  2.2.1 システム概要図
  2.2.2 アーキテクチャ図
  2.2.3 プロトコル図
  2.2.4 基本設計書
  2.2.5 パラメータシートや管理台帳
  2.3 リリース手順の標準化
  2.3.1 作業項目の洗い出し
  2.3.2 作業項目の整理
  2.3.3 例外的な処理から対応策を準備する
  2.4 変更発生に即時更新するために
  2.5 IaCによる構成管理とは
  2.5.1 IaCの利用例
  2.5.2 CloudFormationとAWS CDK
  2.5.3 IaC導入の観点①
  2.5.4 IaC導入の観点②
  2.6 リリース手順のIaC化の実際
  2.7 運用ルールの検討と決定
  2.7.1 リリースの判断基準
  2.7.2 IaCの運用
  
  第3章 障害対応が遅れる根本原因
  3.1 なぜ障害対応が遅れてしまうのか
  3.2 場当たり的なトラブル対応でおざなり運用
  3.2.1 問題の勃発
  3.3 障害復旧が大幅に遅延した理由とは
  3.3.1 後回しの運用設計
  3.4 障害と対応項目の洗い出し方
  3.4.1 対応プロセスの定義の仕方
  3.4.2 懸念材料と検討方法
  3.5 ログの分析による対応の迅速化
  3.5.1 ログ分析の準備
  
  第4章 無視されるシステムアラートを見直す
  4.1 なぜアラートが軽視されるのか
  4.1.1 アラート設定の2つの落とし穴
  4.2 アラートのオオカミ少年問題
  4.2.1 アラートの発生
  4.3 アラートの見直し
  4.3.1 念のため設定の陥穽――無駄なのか有用なのか
  4.3.2 アラートの隠蔽――障害修正の先送り
  4.3.3 困難な問題の切り分け――多面的な原因のため修正箇所がわからない
  4.4 アラート設計の基本
  4.5 障害発生のリスクをベースにアラート設計を見直す
  4.5.1 アラートとインシデントの現状分析
  4.5.2 既存アラートの課題抽出
  4.5.3 モニタリング手法の再検討
  4.6 アラートの定期的評価と改善
  4.6.1 アラートかノイズか見極めるには
  4.6.2 重要度の見直し・設定
  4.6.3 アラートに対してのアクション定義
  
  第5章 効率化という名の属人化による弊害
  5.1 属人化で生まれる負のスパイラル
  5.2 1人に集中するトラブル対応
  5.2.1 トラブルシュート体制作り
  5.2.2 負のスパイラルの発生
  5.3 実は理解されていなかったシステムの勘所
  5.3.1 振り返りミーティングでわかったこと
  5.3.2 知見共有の大切さ
  5.4 孤独な担当者にしないために――関係者のコミュニケーション
  5.5 アプリのトレーニング環境の構築
  5.5.1 プレイグラウンドの導入
  5.5.2 プレイグラウンドから本番環境へ
  5.6 暗黙知の減らし方
  5.7 ポストモーテムの実施
  5.7.1 タイムラインの整理
  5.7.2 振り返りの意義
  5.7.3 振り返りのポイント
  5.8 開発部の風通しをよくするには
  
  第5章 IaCコードの良い育て方・悪い育て方
  6.1 インフラをコードとして管理するメリット
  6.1.1 インフラの効率化を推進するために必要なこと
  6.2 本末転倒のIaC導入による問題発生
  6.2.1 エラー発生の原因調査と設計の見直し
  6.3 AWS設定値が原因で変更がロック
  6.3.1 スタック内での参照
  6.3.2 クロススタック参照
  6.4 CloudFormationのサービスの仕様
  6.4.1 スタックのデプロイ
  6.5 CDK/CloudFormationのアンチパターン
  6.5.1 ①過度なスタック分割
  6.5.2 ②IaCと手動作業の混在による構成ドリフト
  6.5.3 ③相互参照の多用
  6.6 CDKのコードの書き方
  6.6.1 縦方向の依存方向を一方向にする
  6.6.2 環境変数による疎結合な設計
  6.7 IaCで管理した方がいいものとしなくてもよいもの
  6.7.1 インフラの上で動作するアプリケーション
  6.7.2 IAMリソースやVPCリソース，WAF等のセキュリティ統制にかかわるリソース
  6.7.3 SES，Route53，Certificate Managerなど，DNSレコードの登録を伴うサービス
  6.7.4 機密情報の管理に関わるリソース
  6.7.5 システム運用に応じて頻繁に変更が入る可能性があるリソース
  
  第7章 ISO/IEC：27017規格への対応
  7.1 ISO/IEC 27017とIaC
  7.2 ISO/IEC：27017規格とは何か？
  7.2.1 ISO認証とは？
  7.2.2 ISO27001(ISMS)とISO27017
  7.3 規格をとるか，それとも運用をとるか？
  7.3.1 内部監査で発覚したIaCの問題点
  7.3.2 IaC運用の中止の危機
  7.4 業務システム成長のトレードオフ
  7.5 中期的な将来を見据えた運用設計
  7.6 IaCの利便性とセキュリティのトレードオフ
  7.6.1 IaC運用におけるアクセス統制
  7.6.2 AWS Configによる変更検知
  7.7 懸念される事柄
  7.7.1 IaCコード品質の維持
  7.7.2 教育
  7.8 全社的なナレッジにする方法
  

AWS CDK入門 ――IaCによる安全・効率的なWebアプリ運用（技術評論社） の商品スペック