Cloud DiagramsならAWSインフラをリアルタイムに可視化。常に最新のアーキテクチャマップで、インシデント解決時間の短縮、セキュリティ脆弱性の発見、チーム間の連携強化を同時に実現します。
本番環境で重大なインシデントが起きたとき、エンジニアは古くなった構成図と複数のクラウドコンソールのタブを行き来しながら、原因と疑わしいサービスを次々と切り替え、貴重な時間を奪われてしまいがちです。
こうした光景は、ドキュメント整備が追いつかないほどクラウド環境が拡大した企業で日常的に繰り広げられています。結果として、SREやInfoSecの担当者は、根本原因の解決ではなく状況の把握そのものに時間を費やすことになります。その間にも顧客への影響は広がり、売上は失われ、インシデント対応のタイマーは刻々と進んでいきます。
そこで本日、Cloud Diagramsを発表できることを大変嬉しく思います。先日のLiveDiagrams買収から生まれたCloud Diagramsは、SREおよびセキュリティチームに対し、AWSアーキテクチャをほぼリアルタイムで把握できるビューを提供します(対応プラットフォームは今後さらに拡大予定)。問題を根本から解決できることに加え、コンテキストに富んだアーキテクチャ議論を後押しし、より良い意思決定へとつなげます。
常に最新のインフラ図があれば、何が落ちているかだけでなく、依存関係をたどって_なぜ_落ちているのかまで素早く特定でき、解決までの時間を数時間から数分へと一気に短縮できます。
本記事では、複雑化するクラウド環境の現状と、そこから生じる課題、そしてCloud Diagramsがどのようにチームに必要な可視性をもたらすのかをご紹介します。
Cloud Diagramsをご自身で体験してみたい方は、下のリンクからセルフガイド型のインタラクティブデモをお試しください。
複雑化するクラウド環境
アプリケーションは時間をかけて少しずつ積み上げられていくものですが、いざアーキテクチャ判断を見直したり、インシデントを調査したりする段になると、当時の経緯や判断理由はすでに忘れ去られているか、失われていることがほとんどです。
意思決定を担った人がもう社内にいないかもしれません。すべてを一変させた大規模デプロイがドキュメント化されていなかったかもしれません。いずれにせよ、誰の頭にも収まりきらないほど肥大化したクラウド環境だけが残されます。
そこから、企業を日々悩ませる3つの課題が生まれます。
#1 - 見えない相互依存関係
既存ツールは生のデータは出してくれても、インフラが語っているストーリーまでは見せてくれません。
たとえばAWS Resource Explorerは、AWSが自動でプロビジョニングしたものまで含めて何千行ものリソース一覧を示すだけで、デプロイ済みコンポーネントのつながりを示すビューにはなっていません。下の例でも、サブネット_の中に_リソースがあるかどうかすら判断できません。
EC2 Global Viewはインスタンスの数と所在地は教えてくれますが、それらがどう連携し、周囲に何があり、ロードバランサーやEKSクラスターとどうつながっているかまでは説明してくれません。
結局、チームは探偵役に回り、なぜそう構築されたのかという背景もわからないまま、サービス間のつながりをひとつずつ解きほぐしていくことになります。
しかも、それぞれのサービス内のクラウドリソースはさらに複雑な関係を抱えています。
インスタンスはサブネット上で動き、サブネットはVPCに属し、そのVPCは別のVPCと接続されている可能性があり、それらすべてをセキュリティグループが制御しています。ロードバランサー、APIゲートウェイ、Lambda関数、コンテナ、データベース、S3バケットにも、サービスを成立させるために欠かせない固有のプロパティと依存関係があります。
これらのつながりが見えないままでは、チームは断片的な理解で運用を続けることになり、_自分たちが直接管理している_システム内ですら重要な関係性を見落としてしまいます。その結果、エンジニアは不完全な情報のまま変更を加え、下流で何も壊れないことを祈るしかなくなります。
#2 - 古くなったドキュメント
チームで丹念に描き上げたあの詳細なアーキテクチャ図は、新しいリソースが1つ追加された瞬間に、もう古いものになっています。
アーキテクチャ図はおおむね静的で、本来あるべき頻度では更新されません。デプロイや構成変更のたびに図を描き直す余裕がある人など、現実にはほとんどいないからです。
その結果、チームは個人の記憶を非公式なドキュメントとして頼るようになります。
このやり方は、リードアーキテクトが休暇に入るか、退職するそのときまでは問題なく回ります。そしてある日突然、重要なコンテキストが一夜にして消え去るのです。
#3 - 解決時間の長期化
インフラ可視性のギャップは、単なる技術的なストレスにとどまらず、ビジネスにも実害を及ぼします。
アーキテクチャがクリアに見えなければ、トラブルシュートは複雑なパズルになります。エンジニアはサービス間の接続を手作業でたどり、複数のログを突き合わせ、リソースの関係性を記憶を頼りに組み立てていく羽目になり、貴重な時間を浪費します。
そのレイテンシは過負荷のデータベースが原因なのか。ネットワーク設定のミスなのか。それとも依存関係のどこかに潜むリソース上限なのか。
こうした犯人探しは、本来の修復作業から時間を奪い、インシデント解決を長引かせ、結果として顧客と売上に直接の打撃を与えます。
Cloud Diagramsは、チームが効率的に運用するために必要な、明確で網羅的なインフラ可視性を提供することで、こうした課題に正面から向き合います。次に、インフラの問題を素早く把握・解消するための仕組みを見ていきましょう。
Cloud Diagramsで実現するインフラの完全な可視化
Cloud Diagramsには、インフラを把握するための主要な2つのビューがあります。
- アカウントダイアグラム:接続済みのAWSアカウントごとに1つのダイアグラムを生成し、リソースの可視化と分析、そして相互の関係性の把握を行えます。
- ネットワークフロー:接続されたすべてのアカウントにまたがるクラウドネットワークトポロジー全体を、1つの統合ビューで表示します。
AWSアカウントを可視化するには、対象アカウントのネットワーク、コンピュート、ストレージ、セキュリティの各サービスに対して_読み取り専用_権限を付与する必要があります。これによりCloud Diagramsは、アカウント内のネットワークトポロジー、コンテナサービス、ストレージシステム、セキュリティ設定、サービス間接続をマッピングできるようになります。
AWSアカウントのインフラを可視化する
AWSアカウントを接続すると、Cloud Diagramsはリソース、サービス、それらの接続関係まで含めた、現在のインフラを網羅するリアルタイムマップを自動生成します。
リソースの追加・変更・削除に応じて、ダイアグラムは自動的に更新されます。
Cloud DiagramsによるAWSアカウントのインフラマッピング
これにより、サービス間の関係性を直感的に理解しやすくなり、見落とされがちなアーキテクチャ上の不整合も発見できます。
ダイアグラムは、ネットワークデータの自然な流れに沿って左から右へ配置されます。Route 53やロードバランサーといった公開リソースから始まり、ネットワークレイヤーを経て、内部S3バケットやデータベースサービスといったプライベートリソースへと続いていきます。
Cloud DiagramsでAWSアカウントのインフラと接続関係を辿る
任意のサービスインスタンスをクリックすると、それに接続された他のインスタンスがハイライトされ、対象リソースの詳細プロパティや情報が表示されます。
たとえば下の画像では、ALBの構成情報、ネットワーク設定、セキュリティルールが確認できます。さらに、関連するサービスはハイライトされ、無関係なリソースはフェードアウトするため、トラフィックの流れと依存関係を直感的に把握できます。
Cloud Diagrams上のApplication Load Balancer(ALB)のプロパティ
こうした可視性のおかげで、本来なら長い調査を要するような重大な問題も、ひと目で発見できるようになります。
たとえば下の画像では、何にも接続されていない孤立したネットワークロードバランサーに対して、毎月料金を払い続けていることが見て取れます。
Cloud Diagramsで検出した孤立Network Load Balancer(NLB)
潜在的なセキュリティリスクを示唆する、一貫性のないルーティング構成も発見できます。
1つ目の経路は組み込みのWAF機能を備えるCloudFrontを経由しているのに対し、2つ目はそれをバイパスしてロードバランサーに直接つながっている点に注目してください。
CloudFrontを経由せずApplication Load Balancerに到達してしまっているRoute 53ルートを特定
狙い撃ちの調査に向けたリソースの絞り込み
複雑な環境でインシデント対応を行う際、無数のサービスや接続を渡り歩くのは大きな負担です。
そこでFilterを使えば、注目したいリソースだけを視覚的に絞り込めます。
たとえば、コスト急増やパフォーマンス問題がEC2絡みだとわかっており、調査を楽にするためにEC2インスタンスとその接続だけを抜き出したいとします。EC2リソースで絞り込むのはもちろん、特定のタグキー・値ペアを持つサービスリソースだけにさらに絞り込むこともできます。
Cloud DiagramsでEC2リソースとその接続のみを抽出
すると、ダイアグラムは指定したキー・値ペアを持つEC2インスタンスと関連する接続コンポーネントだけのターゲットビューに変わり、依存関係を辿ってインシデントの根本原因を特定しやすくなります。
特定のkey:valueペアを持つEC2リソースとその接続だけを抽出したCloud Diagramsのビュー
類似リソースをまとめて見やすくする
大規模なクラウド環境では、下のS3バケットのように個々のリソースが何十も並ぶと視覚的に圧倒され、肝心な部分に集中しづらくなります。お客様からも、既存のダイアグラムツールは「情報量が_多すぎる_」ことが課題だという声をよく伺います。
Cloud Diagramsのインフラビューに表示された複数のS3バケット
Cloud DiagramsのCombine機能を使えば、類似リソースを論理的なグループにまとめて、より見通しのよいビジュアルにできます。Filterと同じく、サービス単位や特定のkey:valueペアを基準に結合可能です。
S3リソースをまとめてインフラビューを整理
このように14個のS3バケットを1つのノードに統合するだけで、ダイアグラムは大幅にすっきりします。
14個のS3バケットを1つのノードに統合し、インフラ図を整理
インフラのバージョン履歴とスナップショット
Cloud Diagramsは現在の状態を可視化するだけでなく、AWSアカウントのインフラがどのように変化してきたかも継続的に追跡します。
Historyをクリックすると、環境内で何がいつ作成・変更・削除されたかを示す時系列の監査証跡が表示され、過去のインフラスナップショットと比較できます。
Cloud DiagramsにおけるAWSアカウントのインフラバージョン履歴
もっと特定の前後比較がしたい場合は、Snapshotsを使って、サービスタイプやAWSアカウント、その他の軸で絞り込んだカスタム比較ビューを作成できます。
これにより、アーキテクチャの特定部分の変更だけを切り出して把握しやすくなります。たとえば下のスナップショット比較では、Webサーバーインスタンスが停止状態から実行状態へ変わり、パブリックIPアドレスを取得し、関連するセキュリティ構成も変化していることが確認できます。
AWSアカウントのCloud Diagramに含まれるEC2インスタンスの変更履歴を追跡
Network Layer:ネットワーク障害を数分で解消
個別のアカウントダイアグラムはリソース単位の貴重なコンテキストをもたらしてくれますが、複数のVPCやリージョン、さらにはAWSアカウントをまたぐ接続性の問題に直面することもあります。
そこで真価を発揮するのが、Cloud DiagramsのNetwork layerビューです。
Network layerは、接続されたすべてのアカウントを横断するクラウドネットワーク基盤の全体像をビジュアルで提示します。異なるVPC、リージョン、アカウントをまたぐサブネット間のネットワークフローを把握でき、ネットワークトポロジーの包括的なマップを描き出します。
ネットワーク構成をひと目で把握
Network layerは、リソースをアカウント単位(縦の列)とリージョン単位(各アカウント内の横のセクション)で整理して表示するため、インフラ全体でネットワークコンポーネントがどう関係しているかが一目瞭然です。
Cloud Diagramsに接続されたAWSアカウントのNetwork layerビューと、ネットワークコンポーネント間の接続関係
このビューを使うと、次のことが可能です。
- ネットワーク接続のマッピング:複数のアカウントやハイブリッドクラウド構成にまたがるCloudWAN、TransitVPC、VPNネットワークを可視化できます。
- NATおよびインターネットゲートウェイの一覧化:これらのコンポーネントを1つの統合ビューでまとめて確認できます。
- ルーティング問題のトラブルシュート:ネットワーク全体のルーティングテーブルが正しく構成されているかを確認し、サービス障害につながる前に設定ミスを発見できます。
実例:VPC間通信の問題を解消する
異なるVPCにある2つのアプリケーションが、セキュリティグループを正しく設定しているにもかかわらず通信できない、というケースを想像してみてください。
従来のツールなら、複数のAWSコンソール画面を行き来し、サブネット構成を確認し、ルーティングテーブルを比較するのに何時間もかかります。Cloud Diagramsを使えば、その解決ははるかに簡単です。
Network Layerは、2つのAWSアカウントにまたがる3つのVPCサブネットへの接続を持つCore Networkを即座に表示します。
Cloud DiagramsのNetwork layerビューで特定された3つのVPCサブネット
1つ目のAWSアカウントへの最初の接続をたどると、Network Manager Core Networkを指すように正しく構成されたルーティングテーブルを持つサブネットが確認できます。
Network Manager Core Networkに正しく設定されたVPCサブネット
ところが2つ目のAWSアカウントの2つ目のサブネットを確認すると、戻りトラフィックに必要な肝心のルートエントリが欠けていることがすぐに判明します。
Network Manager Core Networkへのルートエントリが欠けているVPCサブネット
原因がわかれば、AWSコンソールへの直接リンクから不足しているルートをそのまま追加できます。
チーム間の知識のサイロを打ち破る
Cloud Diagramsはインシデント対応にとどまらず、チーム間で認識を揃えるための強力なツールでもあります。
「自分が直接管理していないサービスにはなかなか踏み込めない」というEngineersの声を、私たちもよく耳にしてきました。
Cloud Diagramsは、そうした未知の領域を視覚的に探索する手段を提供します。抽象的すぎたり、逆に細かすぎたりする従来のドキュメントと違い、Cloud Diagramsはちょうど良い粒度で、必要に応じてズームイン・ズームアウトできます。
また、丹念に作り込んだConfluenceのドキュメントやLucidChart/Visio/Gliffyの図が、インフラの急速な変化によって作成直後にほぼ陳腐化してしまった、というお話も多くの企業から伺っています。
Cloud Diagramsの常に最新のビジュアライゼーションを使えば、図の手作業メンテナンスに時間を取られることなく、アーキテクチャ判断にあたってコンテキストの濃い議論を進められます。
Cloud Diagramsの今後
私たちはCloud Diagramsの開発を続ける中で、機能を一段と拡張し、クラウド環境に関する技術的・財務的な意思決定をしっかり後押しできる、より強力なツールへと進化させていきます。
今後ご期待いただきたい主なアップデート:
- コストデータをダイアグラム上のリソースに直接重ねて表示し、クラウドインフラの構造だけでなく、各コンポーネントが全体コストにどれだけ寄与しているかも一目で把握できるようにします。
- Google Cloudをはじめとする追加のクラウドプラットフォームへの対応により、単一インターフェースから真のマルチクラウド可視性を実現します。
- Anomaly DetectionなどDoiT Cloud Intelligenceの他機能との連携を強化。たとえばコスト急増のアラートを受け取った瞬間に、該当リソースとその依存関係をすぐに可視化し、根本原因を素早く特定できます。
- さらに、Wizなどのサードパーティツールとの連携にも取り組んでおり、セキュリティイベントやその他の運用データでダイアグラムをより充実させていきます。
Cloud Diagramsの実際の動きをご覧になりたい方は、ステップ・バイ・ステップのウォークスルーをご確認いただくか、DoiTのエキスパートまでお問い合わせのうえ、AWSインフラの可視化をどう始められるかをぜひお確かめください。
Cloud Diagramsは、DoiT Cloud IntelligenceのEnhancedまたはEnterpriseティア、ならびにDoiT Cloud NavigatorのEnhanced、Premium、Enterpriseティアをご利用のすべてのお客様にご利用いただけます。