大規模環境でどのように監視を実現する？

Transcript

1. 大規模環境でどのように監視を実現する？ 2026年5月20日 NRIネットコム株式会社 デジタルソリューション事業本部 クラウドソリューション事業部 大林 優斗
2. 1 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します クラウドエンジニア ◼ AWSクラウドアーキテクトとして、エンタープライズ企業の内製開発・ 運用を支えるクラウド基盤設計に従事 ◼ 大規模マルチアカウント環境におけるセキュリティガバナンス改善や CCoE支援を中心に、要件定義から運用設計までを一貫して担当 過去のアウトプット ◼ 著書 ◼ 登壇資料：https://speakerdeck.com/yuobayashi ◼ ブログ：https://tech.nri-net.com/archive/author/y- obayashi 自己紹介 大林 優斗 Yuto Obayashi
3. 2 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 大規模な AWS 環境では、監視対象が増えるだけでなく、アカウント、リージョン、システム、運用担当が分散していき ます。 ◼ 本セッションでは、CloudWatch の横断監視に関する3つの機能を取り上げ、どのような場面で、どの機能を使うべき かを整理します。 マルチアカウント・マルチリージョン環境の監視設計 分析 保存
4. 3 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 大規模環境では、アカウント、リージョン、システム、運用担当が増え、障害発生時に「どこを見ればよいのか」が分か りづらくなります。 ◼ 監視対象が増えること以上に、監視の入口が増えること が運用負荷につながります。 大規模環境では、監視の入口が増えていく 小規模環境 大規模環境 AWS account Amazon CloudWatch AWS account Amazon CloudWatch AWS account Amazon CloudWatch AWS account Amazon CloudWatch AWS account Amazon CloudWatch
5. 4 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 多くの環境では、メトリクスやログはすでに出力されています。 ◼ それでも運用が難しくなるのは、システムごとにアラーム、ログ、ダッシュボード、通知ルールの作り方が異なるためです。 ◼ 中央から見えるようにするだけではなく、何を見るか、どの粒度で見るか、どう通知するか を揃える必要があります。 監視の難しさは「データがない」ではなく「見方が揃わない」こと System A Alarm: CPU 80% Logs:/app/prod/a Notify: Mail System B Alarm: CPU 80% Logs:/service/b/error Notify: Mail System C Alarm: なし Logs:不明 Notify: 個別運用 中央化だけではなく、標準化が必要
6. 5 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 監視には、少なくとも3つの目的があります。 監視は「見る・調べる・残す」で分けて考える 目的 確認したいこと 必要な仕組み 見る 今、正常か異常か メトリクス、アラーム、ダッシュボード 調べる どこで何が起きたか ログ、トレース、相関分析 残す 後から説明・分析できるか 長期保管、監査証跡、検索基盤
7. 6 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ CloudWatch には、マルチアカウント・マルチリージョン環境を扱うための複数の選択肢があります。 ◼ 本セッションでは、以下の3つを取り上げます。 CloudWatch で使える3つの横断監視の選択肢 機能 主な役割 クロスアカウントオブザーバビリティ 複数アカウントのメトリクス、ログ、トレースを監視ア カウントから扱う クロスアカウントクロスリージョン CloudWatch コンソール 複数アカウント・複数リージョンの状態を画面上で 俯瞰する クロスアカウントクロスリージョンログ一元化 ログを運用用のアカウントにコピーし、保管・分析・ 監査に利用する
8. 7 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ クロスアカウントオブザーバビリティは、監視アカウントに Sink を作成し、各ソースアカウントから Link を作成することで、 複数アカウントのテレメトリを横断的に扱う仕組みです。 ◼ メトリクス、ログ、トレース、Application Signals などを監視アカウントから確認できるため、障害対応時にアカウントを 切り替えながら調査する負荷を下げられます。 ◼ 特に、複数アカウントにまたがるシステムや、共通運用チームが複数システムを見る環境に向いています。 クロスアカウントオブザーバビリティは、日々の運用監視の中心 Ops account AWS account Amazon CloudWatch Cross-account observability Amazon CloudWatch AWS account Amazon CloudWatch AWS account Amazon CloudWatch Sink Link Link Link
9. 8 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ クロスアカウントクロスリージョン CloudWatch コンソールは、複数アカウント・複数リージョンのメトリクス、アラーム、ダッ シュボードを画面上で確認するための仕組みです。 ◼ リージョンをまたいだ状態確認や、複数環境のダッシュボードをまとめて見たい場合に有効です。 ◼ 一方で、ログやトレースを深く相関させて調査する用途では、クロスアカウントオブザーバビリティのほうが適しています。 クロスアカウントクロスリージョン CloudWatch コンソールは、広く俯瞰するためのビュー ap-northeast1 AWS account AWS account us-east1 AWS account AWS account Monitoring account Monitoring account Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch
10. 9 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ ログ一元化は、各アカウント・各リージョンで出力されたログを中央のアカウントにコピーし、長期保管や分析に利用す る設計です。 ◼ CloudWatch Logs、Kinesis Data Firehose、S3、Athena、OpenSearch Service などを組み合わせることで、障 害後の分析、監査証跡、セキュリティ調査に活用できます。 ◼ 日々の障害一次対応というより、後から説明できる状態で残すこと に強みがあります。 ログ一元化は、後から分析・監査できる状態で残すための基盤 AWS account AWS account AWS account AWS account Monitoring account Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch Amazon CloudWatch
11. 10 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 結論として、日々の運用監視はクロスアカウントオブザーバビリティ、広域の俯瞰はクロスアカウントクロスリージョン CloudWatch コンソール、長期保管と分析はログ一元化で役割を分けます。 3つの機能は、優劣ではなく目的で使い分ける 観点 クロスアカウントオブザーバ ビリティ クロスアカウントクロスリー ジョン CloudWatch コンソール ログ一元化 主な目的 障害対応・原因調査 全体俯瞰 長期保管・監査・分析 データの考え方 ソースアカウントのデータを中央 から扱う 各アカウント・各リージョンを画 面上で参照する 中央アカウントへログをコピーす る 向いているデータ メトリクス、ログ、トレース メトリクス、アラーム、ダッシュ ボード ログ 強み 相関分析、影響範囲特定、 MTTR 短縮 複数リージョンの俯瞰 監査証跡、長期分析 注意点 リージョン単位で設計が必要 深い調査には向かない 転送・保管・検索コストを設計 する必要がある
12. 11 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 横断監視の仕組みを導入すると、複数アカウントの情報を中央から確認できるようになります。 ◼ しかし、アラーム名、ロググループ名、タグ、通知ルール、ダッシュボードの粒度がシステムごとに異なると、運用チームは判 断に時間がかかります。 ◼ そのため、大規模環境では、横断監視とあわせて監視標準を整備する必要があります。 中央化だけでは運用は楽にならない 標準化するもの 具体例 タグ SystemName、Environment、Owner、MonitoringLevel アラーム 命名規則、重要度、通知先、閾値設計 ログ ロググループ名、保持期間、収集対象 ダッシュボード システム別、サービス別、重要度別のテンプレート 通知 メール、チャット、チケット、電話連絡の使い分け
13. 12 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 標準リソースを自動デプロイ仕組みを導入することで、セキュリティ設定のばらつきや、ログの取得漏れがないAWS環 境を迅速に構築することもポイントです。 監視標準化と自動展開
14. 13 Copyright（C） NRI Netcom, Ltd. All rights reserved. 転載、複製、改変等、および許諾のない二次利用を禁止します ◼ 大規模環境の監視では、すべてを1つの機能に寄せるのではなく、目的ごとに役割を分けることが重要です。 ◼ 監視の中央化と標準化を組み合わせることで、運用チームの負荷を下げ、開発チームが本来の開発に集中できる環 境を作ることができます。 監視基盤は開発を加速させる 目的 選択肢 今の状態を広く見る クロスアカウントクロスリージョン CloudWatch コンソール 障害原因を横断的に調べる クロスアカウントオブザーバビリティ ログを後から分析・監査できるように残す ログ一元化 継続的に運用負荷を下げる 監視標準化と自動展開