マルチクラウド戦略を成功させるための実証済みのプラクティス

この記事は Proven Practices for Succeeding with a Multicloud Strategy を翻訳したものです。

企業戦略家としての経験から、マルチクラウドに関する議論は多くの場合、混乱と矛盾したアドバイスに悩まされていることがわかります。マルチクラウド戦略を採用しないよう警告するアドバイザーもいれば、採用しなければ業界全体の変革に乗り遅れると指摘するアドバイザーもいます。マルチクラウド戦略の採用には正当な理由がありますし、また反対も同様です。成功には、マルチクラウド戦略がもたらす潜在的なビジネス価値と複雑性およびリスクのバランスをとることが不可欠です。

企業は通常、戦略的な理由からマルチクラウドを採用します。異なるプラットフォームで事業を展開する新たに買収した企業を統合したり、異なるプロバイダーの専門的な機能を活用したり、持株会社と事業会社のレベルで異なるクラウド戦略をサポートしたりするためです。

ただし、企業はマルチクラウド戦略を一般的な誤解、例えば全面的な採用、ベンダーロックインの軽減、可用性の向上、コストの優位性などに基づいて策定すべきではありません。 ( これらの考慮事項についてより深く掘り下げた議論は、以前の私の記事 Proven Practices for Developing a Multicloud Strategy をご覧ください。 )

マルチクラウドアプローチを成功させるには、既存のツールや将来の選択肢と シームレスに 連携するクラウドプラットフォームが必要です。他のクラウドサービスプロバイダ ( CSP ) の機能を追加する際に、すべてを再構築する必要はありません。また、すべてのプラットフォームのエキスパートになる必要もありません。 ( これが Multicloud on AWS において直接接続ポイントを構築する理由です。AWS 上で実行されるワークロードの性能を最大化しつつ、CSP 間の管理を簡素化するようにツールを設計しています。 )

お客様との経験に基づき、以下のプラクティスを推奨します。

1. 明確な戦略とそれを支えるガバナンスを確立する

マルチクラウドアプローチを追求すると決めただけでは不十分です。どのワークロードをどこに、何のために配置するかについての明確なガバナンスを含め、マルチクラウドの目的を達成するための戦略も確立する必要があります。ワークロードとその依存関係を最適化する評価基準を選択してください。このような決定を個人任せにすると、 CSP 間の無秩序な拡大が生じ、達成しようとした価値を損なう可能性があります。CSP のパフォーマンスを定期的に評価し、その評価を CSP の選択、ワークロード配分基準、および将来の利用計画に活用してください。
ガバナンス戦略をサポートするためには、企業全体のサービス、アプリケーション、コンポーネントの総数について可視化する必要があります。そのためには、CSPを横断してタグ付け戦略を確立し、明確な所有権、利用状況、環境 ( 開発、QA、ステージ、本番など ) を定義してください。所有者が特定できない場合は、そのリソースを削除する必要があります。これによりガバナンスが明確化され、進捗を阻害することなく自動的に施行されます ( ゲートではなくガードレール ) 。
コスト、運用プロセス、セキュリティは、CSP 間で同じ方法で、同じ深さのデータと透明性をもって監視され、対処されなければなりません。

2. 隣接するワークロードをCSP間に分散させない

複数の CSP に跨がる単一のワークロードは、不必要な複雑性、リスク、コストをもたらし、サポート、デプロイ、アーキテクチャを複雑にするだけで付加価値はほとんどありません。
隣接したワークロードは通常、一緒に処理・分析する必要のある大量のデータを伴います。データを複数の CSP に分散させると、データの移動、同期、整合性に課題が生じます。また、複数の CSP 上の単一のワークロードを管理することは複雑で時間がかかります。各 CSP の API 、管理インターフェース、セキュリティモデル、運用プロセスに対応する必要があるためです。複雑性の増加は、エラーの可能性を高め、運用オーバーヘッドを増加させ、アジリティとスケーラビリティを阻害する可能性があります。

3. より長期的な統合戦略を持つ

異なるクラウドのアプリケーション間でデータを移動する際には注意が必要です。特に、ある CSP にコンピューティング／アプリケーションをデプロイし、別の CSP にデータ、ストレージをデプロイする場合はなおさらです。ワークロードとデータの配置を決定する際は、ワークロードとデータを他の機能と統合する長期的なニーズを考慮する必要があります。データが現在の範囲を超えて、高度な分析や ML に必要となるでしょうか?そのサービスは他の CSP でも幅広く利用されるでしょうか、それとも特定の CSP 内に限定されるでしょうか?
より詳しいガイダンスと導入検討のための意思決定モデルについては Gregor Hohpe の以前の記事 Multi-cloud: From Buzzword to Decision Model をご覧ください。

4. コンテナを戦略的に活用する

コンテナはモダンなアプリケーションに適していることが多く、ポータビリティの面で役立ちます。コンテナはプラットフォームに依存しないため、コンテナ化をサポートするあらゆるクラウドプラットフォームやインフラにも展開できます。アプリケーションを一度開発、パッケージ化すれば、大幅な修正なしに複数の CSP やオンプレミス環境に展開できます。
ただし注意が必要です。コンテナはすべてのケースに適しているわけではなく ( 大規模なモノリシックアプリケーションなど )、CSP 間のポータビリティのすべての問題 ( 特にデータ、ポリシー、セキュリティ ) を解決するわけではありません。

5. 単一のCCoE ( Cloud Center of Excellence ) を持ち、その中で専門化する

多くのお客様にアドバイスしているように、組織内に CCoE を形成し、クラウドに関する取り組みをリードし、標準化を推進することで、クラウドジャーニーを加速するべきです。マルチクラウドの場合、単一の CCoE を設置し、その中で各 CSP 特有のスキル、ツール、メカニズムに特化することで、企業はより成功しやすくなると我々は考えています。CSP ごとに別々の CCoE を設置すると、多くの場合、分断、再設計、無駄が生じがちです。

6. セキュリティが常に最優先事項であることを確認する

複数のセキュリティモデルを管理すると攻撃対象領域が広がり、ギャップが生まれます。マルチクラウドでは、アイデンティティ管理、ネットワークセキュリティ、資産管理、監査ログなど、複数の CSP のセキュリティモデルに対処する必要があります。その結果、複雑さにより透明性が低下し、セキュリティチームの負担が増大し、リスクが高まります。いくつかのセキュリティ実践がより重要になります:
(1) セキュリティ運用を自動化し、デリバリパイプライン、クラウド環境、チームの優先事項に組み込むことによって、セキュリティ運用をシフトレフトする、(2) CSP 内または CSP 間で保存中および転送中のデータを暗号化する。

セキュリティ運用データの送信先を1つに絞る ( Single Pane of Glass ) ことが有効です。その上で、各 CSP のクラウドネイティブツールを使用して、その環境に最適なデータを表示します。

7. 均等分散ではなく 80/20 のアプローチを受け入れる

CSP間でワークロードをどのように配分するかは、マルチクラウドの成功を左右します。投資の80％をプライマリプロバイダに集中させ、その他のプロバイダを特定機能の利用に限定することで、コストと複雑さを軽減できます。
80/20の配分により、プライマリプラットフォームの高度なサービスの活用を通じたイノベーションが加速します。トレーニングとツールの重複が減り、単一のセキュリティモデルのみ管理すればすみます。
エンジニアが1つのプラットフォームに精通することで、より効率的に構築し、より迅速にトラブルシューティングし、より洗練されたソリューションを実装できます。また、人材の定着にも良い影響があり、多くの技術に跨がってスキルを薄めるのではなく、市場価値の高い専門性を身につけられます。

マルチクラウド環境の管理と監視を簡素化し、どこに保存されていてもすべてのデータへのアクセスを提供し、マルチクラウド環境で生成AIを活用するのに役立つAWSサービスの詳細については、Multicloud on AWS をご覧ください。

翻訳はカスタマーソリューションマネージャー 西部 信博が担当しました。原文はこちらです。