QCon London 2026: マルチクラウド戦略は製品の問題である ― そのように扱え

QCon London 2026において、JPモルガン・チェースのルイス・アルビナティ氏とスラブヒ・マハジャン氏は、多くの企業がマルチクラウドを誤ったアプローチで捉えていると主張しました。問題の本質は技術的なものではなく、組織的なものです。企業は、買収やシャドーIT（Shadow IT）、規制圧力、あるいはAIワークロードのためのGPU確保を追うことで、結果として複数のクラウドにまたがる運用を余儀なくされます。そして彼らは、その結果生じた混乱を、火事一つずつ消すように技術で解決しようと試みます。アルビナティ氏とマハジャン氏は、持続可能な解決策はマルチクラウドをプロジェクトではなく製品として扱うことだと論じました。 JPモルガン・チェースのマルチクラウドプラットフォームにおける需要およびポートフォリオ管理を担当するプロダクトディレクターであるアルビナティ氏は、「カオスツリー（Chaos Tree）」と呼ばれる概念で講演を開始しました。クラウド移行は当初、コスト最適化とアジリティ（Agility）の観点から推進されましたが、どちらも期待通りに機能しませんでした。企業は支出が増大し、ガバナンスされていないワークロードを運用し、FinOps、ガバナンス、SaaSコンプライアンスといったリメディエーションプログラムを次々と積み重ねる結果となりました。それぞれに独自のツールセットと人員が必要となり、最終的には16件以上のアクティブなプロジェクトが同じエンジニアリング予算を巡って競い合う状態になりました。 中核的な問題は、チームがサイロ（Silo）化して運用されている点にあります。一つのチームがGCPを担当し、別のチームがAWS、さらに別のチームがAzureを担当し、それぞれに独自のロードマップを持っています。AIの導入が進むと、Vertex AI、Bedrock、Azure OpenAIへの同時アクセスを望むチームが増え、サイロはさらに増殖します。誰一人として全体像を把握している者はいません。 彼らが提案した解決策は、製品管理の手法を借用しています。クラウドプロバイダーごとに組織するのではなく、アルビナティ氏は機能（capabilities）ごとに組織化することを推進しました：観測可能性、コスト管理、アイデンティティ、ネットワーク、デリバリーです。各機能はすべてのクラウドとビジネスラインに横断的に存在し、「AWS のロードマップはどうなっているか」という議論から「どこでも統合された観測可能性を提供できているか」へと転換させます。彼は構造化された需要ガバナンスを強調し、定期的な受入窓口（intake windows）を設定してチームに要件の提出を義務付け、計画期間中にその窓を閉じることを求めました。 JP モーガン・チェース社のログプラットフォームにおけるシニアアーキテクト兼テクニカルプロダクトマネージャーであるマハジャン氏は、具体的な例を通じて議論を実践的なレベルに引き下げました。彼女は「フランケンシュタイン型ログ」と呼ぶ状況を説明しました。これは、GCP、AWS、オンプレミスシステムからのデータをすべて AWS の S3 バケットへ流し込むことで中央集権型のログプラットフォームを運用する現実です。その結果、膨大なエグレスコストが発生し、ノイズの多いデータとなり、SRE（サイトエンジニアリング）担当者が午前 2 時のインシデント対応中に 3 つのブラウザウィンドウ間でタイムスタンプを照合して苦労することになりました。 彼らの解決策は、これをプロダクトチームのように捉えることでした。対象となるユーザーである SRE（サイトエンジニアリング）やサイバーオペレーションを特定し、過去 1 年間に実際のインシデント発生時にこれらのユーザーがどのようにデータを照会していたかを調査しました。その後、各クラウドのエッジに OpenTelemetry コレクターを展開し、ネットワーク境界を越える前にヘルスチェックや低価値のイベントをフィルタリングしました。マハジャン氏は、このアプローチによりログ量が 60% から 80% 削減され、「ノイズではなくシグナル」のみを送信できたと報告しています。また、すべての環境にわたって流れる「黄金の糸」として分散トレーシング ID を標準化し、特定までの平均時間を数時間や数日から数分に短縮しました。 マハジャン氏は聴衆に対して、実践的な教訓として「コンソールテスト」を提示しました。これは、どのプラットフォームチームでも自社のロギングインフラストラクチャに対して実行できる一連のシナリオです。もしこのテストにパスすれば、クラウドプロバイダーを統一されたエンジニアリング体験のための原材料として扱うものが構築できたことになります。もし失敗すれば、次に何を修正すべきかが明確になります。 アルビナーティ氏は、能力をサイロ化されたソリューションよりも優先し、孤立した優先順位よりも共有された発見を重視し、個別の対応ではなくゴールデンパス（標準的な成功への道筋）を採用し、設計によるガバナンスを実現し、単なるポータビリティよりもレジリエンスを重視するという原則をマニフェストとしてまとめました。彼は最後の点について率直に述べました。ポータビリティは一部の課題を解決しますが、時には答えはより優れた Kubernetes デプロイメントではなく、差別化された SLA（サービスレベルアグリーメント）に関するより良い契約を含むものであると。 著者について Steef-Jan Wiggers Steef-Jan Wiggers は、InfoQ のシニアクラウド編集者の一人であり、オランダの VGZ でドメインアーキテクトとして勤務しています。彼の現在の技術的専門分野は、統合プラットフォームの実装、Azure DevOps、AI、および Azure プラットフォームソリューションアーキテクチャに焦点を当てています。Steef-Jan は会議やユーザーグループでの定期的なスピーカーであり、InfoQ 向けにも執筆活動を行っています。さらに、マイクロソフトからは過去 16 年間にわたり Microsoft Azure MVP（Most Valuable Professional）として認定されています。 詳細を表示する表示しない

QCon London 2026: マルチクラウド戦略は製品の問題である ― そのように扱え

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト