10
システムは構築した後が勝負。安定運用は顧客への価値提供の前提条件。
u システムに関する運用とは、システムを安定させるために必要なことすべて
u 障害発生における原因特定と早期復旧
u セキュリティの維持
Slide 11
Slide 11 text
11
運用を「設計」として落とし込む
u 日々求められるシステムの運用に対して、どれだけ事前に設計に落とせるかが重要
u 想定外を減らす努力
u 設計には通常複数の選択肢が存在する
u 非機能の観点はトレードオフの世界
u 主要な設計の利点・欠点を押さえておき、自分たちの要件と照らし合わせる
u 日々のクラウドの進化に並走して、運用側面でもアップデートが必要
u クラウド上でシステムを運用する者としての責務
20
ちょっとまって！FireLens用イメージ(aws-for-fluent-bit)の意外な盲点
u Fluent Bitの最新バージョンはv4.0.3
u aws-for-fluent-bit の最新イメージで内部利用されているFluent Bitはv1.9.10
u v1.9.10は2022-12-05にEOL済み、v2以降の以下恩恵は現状受けられない
u Prometheusフォーマットのメトリクス提供 (v2)
u OpenTelemetryプロトコルによるテレメトリの送受信 (v2)
u メモリリーク等のバグ修正 (v2)
u YAMLによるコンフィグ定義 (v3.2)
u セキュリティ関連の改善(TLSバージョンの指定) (v4)
ロギング設計
35
AWS Distro for OpenTelemetry (ADOT)の登場と利用の推奨
u AWS Distro for OpenTelemetryにより、OpenTelemetry準拠で計装が可能
u サードパーティやX-Ray含む、複数にテレメトリを送信可能
u X-Ray SDKと比較して、ADOTはサポートしているランタイムが多い(Swift, Rust,
PHP…)
トレース設計
Slide 35
Slide 35 text
36
トレース設計
AWS Distro for OpenTelemetry (ADOT)の登場と利用の推奨
51
アプリケーションコンテナ環境のデバッグ：ECS Execの事前検討と考慮
デバッグ設計
u 特に、操作ログ出力に対するOSパッケージ、権限、ネットワーク設定周りの考慮が必要
Slide 44
Slide 44 text
52
ネットワークのデバッグユースケース
デバッグ設計
Slide 45
Slide 45 text
53
ネットワークのデバッグ：Reachability Analyzerの検討と考慮
デバッグ設計
u ECSタスクにアタッチされているENIを指定する必要がある点を押さえておく
Slide 46
Slide 46 text
54
意外と役立つデバッグ用カスタムコンテナ(ECS Execとの組み合わせ)
デバッグ設計
u デバッグの柔軟性は高いが、イメージの作成とメンテナンスが必要
Slide 47
Slide 47 text
デバッグ設計(生成AI編)
Slide 48
Slide 48 text
56
生成AI活用によるデバッグでラストワンマイルまでの時間を最小化する
u AWSでは、すでに様々なMCPサーバーを提供
u Amazon ECS MCP Server(ベータ版)
u AWS Documentation MCP Server
デバッグ設計 (生成AI編)
Slide 49
Slide 49 text
57
生成AI活用によるデバッグでラストワンマイルまでの時間を最小化する
u LLMだけでは、「事前学習済みの知識」の回答にとどまる（陳腐化の可能性）
u MCPサーバー連携により、最新の情報源の参照や関連するAPI等の実行が可能
u 「問題発生→原因調査→特定→修正」リードタイムの改善が期待
デバッグ設計 (生成AI編)
60
AIアプリ・LLM・MCPサーバーを活用したAWS環境デバッグの流れ
以下の環境を想定
u AWSはIaC (Infrastructure as Code) に従ってTerraformで構築・管理
u LLMはClaude 4 Sonnetを利用
u AIアプリ(コードエディタ)としてCursorを利用 (Claude CodeやAmazon Qでも動作)
u MCPサーバーとして、以下を利用
u Amazon ECS MCP Server
u Amazon Documentation MCP Server
u Terraform MCP Server
デバッグ設計 (生成AI編)
70
デバッグケースの結果 (問題の修正)
デバッグ結果
u バックエンドAppに適用されているセ
キュリティグループのTerraform定義を
特定
u 修正用Commitを作成
発生した問題
Amazon ECS上のフロントエンドAppから
バックエンドAppに接続できない
実際のCursorにおける出力結果
問題特定から修正まで約90秒で完了
デバッグ設計 (生成AI編)
Slide 63
Slide 63 text
71
AWSデバッグ運用時におけるAmazon ECS MCP Server利用の注意点(1/2)
u現時点では開発中段階であり、開発・テスト用途での利用を想定
u プロダクション環境での利用は非推奨
u機密情報の結果出力を拒否するフラグがある
u 有効にするとトラブルシューティング系のツール利用が大きく制限される
u デバッグ運用活用のため、設定を有効にしつつ、開発用途の利用に限定
{
"status": "error",
"error": "Action fetch_network_configuration is not allowed without ALLOW_SENSITIVE_DATA=true in your
environment due to potential exposure of sensitive information."
}
デバッグ設計 (生成AI編)
Slide 64
Slide 64 text
72
AWSデバッグ運用時におけるAmazon ECS MCP Server利用の注意点(2/2)
u IaCのコード修正は許容できるが、AIツールによるクラウド上の直接的な
変更が可能な出力設定は避けたほうが良い(コスト・セキュリティ観点)
u MCP Serverの書き込み操作フラグを無効化、AIツール側ルールで指示することでリスク緩和
デバッグ設計 (生成AI編)