書籍概要

AWS CDK入門
――IaCによる安全・効率的なWebアプリ運用

著者
発売日
更新日

概要

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

こんな方におすすめ

  • Infrastracture as CodeをAWS上で実践したいシステム管理者・運用者，SRE従事者

サンプル

samplesamplesamplesamplesample

目次

第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　全社的なナレッジにする方法

サポート

現在サポート情報はありません。

商品一覧