出版書誌データベース

クラウド上のアプリケーション運用の効率化や信頼性の向上のために、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の設計・運用に5年従事。新規事業のシステム開発を対象に、AWSクラウドの管理やWebアプリケーション開発の支援を全社的に行っている。また、事業部の新規事業の立ち上げまでの期間の短縮を目指して、社内用の内製フレームワークの開発し、普及活動を行っている。

著：畝 孝雄
九州大学大学院システム情報科学府修了後、大手精密化学メーカーでソフトウェアの設計・開発に従事。これまでに、印刷事業向けのアプリケーション開発や、医薬事業向けのシステム開発を担当。また、社内利用を目的としたシステムの開発も多数手がけており、社内のDX推進に貢献をしてきた。直近は新規ソリューションビジネスの立ち上げに奮闘している。

著：馬石 直登
関西大学大学院総合情報学研究科博士前期課程修了後、精密機器メーカの事業部門、開発部門を経て、画像・ＡＩ研究所にて研究マネージャとして従事。印刷分野、医療分野、公共分野、全社IT戦略部門等において新規事業企画、開発、研究推進を経験。小さくとも世の中の困っている人の顔が笑顔になることを想像し、業務に取り組んでいる。 論文：映像メディア学会［動画像による個人識別技術を用いた勤怠管理に関する研究］ 著書：基礎からわかる画像処理（工学社）