Amazon Web Services ブログ
マルチクラウド戦略を策定するための実証済みのプラクティス
エンタープライズストラテジストである私は、マルチクラウドのトピックが、混乱、誤った確信、暫定性をはらんだ多くの議論の中で取り上げられていることに気づいています。企業は、マルチクラウドアプローチを決して採用しないようにというメッセージや、「どの企業もマルチクラウドに切り替えている」のだからマルチクラウドアプローチが必要だ、という相反するメッセージにさらされています。
マルチクラウド戦略を追求するにしても避けるにしてもそれなりの理由があります。このブログでは、マルチクラウドで成功するための 8 つの実証済みのプラクティスに焦点を当てます。これには、どういった場合にマルチクラウドが理にかなっているか、 AWS がどのように企業のマルチクラウド戦略の成功を支援する立場にあるのかを紹介します。
マルチクラウドとは、組織全体で、複数のクラウドサービスプロバイダー ( CSP ) を同時に利用することを指します。その前に、いくつかの用語を明確にしておきましょう。メールやプロジェクト管理ソフトウェアなどの SaaS 製品を CSP と併用するのは、純粋なマルチクラウド環境とは言いません。これは良い戦略であり、複数のクラウドを活用できる可能性があります。ただし、このブログの中では、パブリッククラウドのマルチクラウドとは言いません。
1. 正当なビジネスニーズを満たすためのみにマルチクラウドを追求すること
AWS のお客様には、ワークロードの大部分を単一の CSP 上に配置するプライマリのクラウドプロバイダーを選択することでクラウドの利点を十分に実現することをお勧めします。しかしながら、マルチクラウドアプローチが組織に適していることには正当な理由がある場合があります。マルチクラウドインフラストラクチャの複雑さが必要となる状況には、次のようなものがあります。
合併と買収
買収企業があるプライマリの CSP を採用しており、被買収企業が別のプライマリの CSP を採用している場合、M&A取引の結果、マルチクラウド環境の状態になります。私のエンジニア経験から、マルチクラウド環境に突入するのはあまり嬉しいことではないと考えています。統合したり、コンパクトにまとめられた方が良いと考えています。しかし、統合を急いで行うことに意味がない場合もあります。全体的なテクノロジー統合戦略と評価アプローチをこのプロセスに反映し、M&A プレイブックの一部にする必要があります。あるプロバイダーから別のプロバイダーに何を移すか、いつ移転するか、何をそのままにしておくかは、それぞれ異なる可能性があります。しかし、統合戦略の確立は、ERPの複数のインスタンスが永遠に稼働し続けることを防ぐのと同じくらい重要です。
他社の CSP が持つ長期的に差別化された機能を活用したい
取りこぼしを恐れて、一部の企業は、あらゆるクラウドの一部の機能を活用したいと考える場合もあります。私たちは、より分散した戦略を採用するよりも、組織の課題の大部分を解決できる CSP を選択した方が、企業にとってより良いサービスを提供できると考えています。これを考えるには、80:20の法則が適しています。(20%の方ではなく)80%の優先順位を検討することは、効率性や、人材の有効活用、価値の向上につながります。特定のテクノロジーを必要とする特殊なワークロードもあるかもしれませんが、メリットとのトレードオフを検討して、ケースバイケースで対処すべきです。
企業は「適切なクラウドに適したワークロード」について考えるかもしれません。「適切なクラウド」とは何かを分析することが、特定のワークロードに関する考慮事項にとどまらないようにしましょう。このワークロードを別の CSP に分散させると、全体的な複雑さにどのような影響が出るかを確認してみてください。各クラウドの各ワークロードの価格とパフォーマンスを注意深く分析して、その価値がこれを正当化するのに十分であることを確認することをお勧めします。
持株会社のマルチクラウド、事業会社/LOBのプライマリのクラウド
プライベート・エクイティ組織や、複数のポートフォリオ企業を持つ大規模な持株会社の場合、各ポートフォリオ企業が独自の CSP 戦略 (多くの場合 M&A によって推進される) を持つことは理にかなっています。1 つのクラウドプロバイダーにより多くの支出を集中させることで、そのボリュームディスカウントやインスタンス予約のインセンティブを活用できる可能性があります。しかし、人材不足、細分化されたワークロード、リスクの増大といったその他の欠点は、各組織が独立して運営されているため、ほとんど回避できます。
2. マルチクラウドに関する誤解に注意しましょう
誤解 1: 誰もがマルチクラウド戦略を採用している
アドバイザリー会社とメディア企業は、企業がどの程度ワークロードを複数のクラウドに配置しているかについて、さまざまな調査結果を発表しています。私たちのアドバイスは、この慣行がどれほど蔓延しているかにかかわらず、企業にとって正しいことを行い、コストとリスクに基づいて意思決定を行うことです。
誤解 2: マルチクラウドはベンダーロックインのリスクを軽減する
マルチクラウド戦略を追求する主な理由として、（契約上の観点と技術的観点の両方から）ロックインの恐れを挙げている企業もあります。オンプレミス環境では、企業は長期にわたる大規模な設備投資に駆り立てられ、多くの場合、長期的で複雑なサービス契約に縛られます。これらは企業にとって一方通行の大きな決定であり（つまり、取り消すのは困難でコストがかかる）、リスクの軽減に重点を置く必要があります。
クラウドは違います。複数のクラウドプロバイダーで同じワークロードを実行している企業は、「最も低い共通点」、つまり複数 CSP で利用できる技術のみを採用して開発しなければならないというプレッシャーを感じることがよくありますが、これはクラウドの利点を最大限利用できないという制限となっていることを考慮する必要があります。場合によっては、プロバイダーごとに異なるワークロードを実行することでこの問題を回避できる場合もあります。
企業には、既存の CSP のサービス利用を終了する場合に発生する切り替えコストと、その可能性を十分に理解するよう努めることをおすすめします。そこから、CSP を変更する必要があるコストと可能性と、主要プロバイダーを持つことの戦略的メリットを比較して、ロックインを減らすための最善のアプローチを定義することができます。
また、クラウドは本質的に従来の IT モデルよりもオープンであり、ロックインを回避するためにマルチクラウドは必要ないという点にも留意してください。AWS が SQL、Linux、コンテナなどのオープンソーステクノロジーと標準に基づいてサービスを構築する点に着目してください。お客様は、MySQL 向けの Amazon Relational Database Service ( Amazon RDS ) や PostgreSQL 向けの Amazon RDS などのマネージド型オープンソースサービス、あるいは基本的なビルディングブロックに基づいて構築するかを選択できます。従量課金制であり、長期にわたる先行契約はありません。AWS では、お客様が使用したいサービスを構築するよう努めていますが、お客様が移転を選択した場合でも、AWS ではこれをできる限り簡単にします。AWS は、お客様がリソースをオンプレミスから AWS に簡単に移動できるようにするだけでなく、お客様が希望すればオンプレミスや他のクラウドに戻すことができるように、複数の移行ツールを提供しています。
誤解 3: マルチクラウドは可用性を向上させる
企業で利用しているプライマリの CSP が停止した場合、そのサービスが中断されるリスクを軽減するために、マルチクラウド戦略を採用するのは、稀なケースになってきています。このような場合、企業はワークロードを簡単かつシームレスにセカンダリ CSP に切り替えることができると考えている場合があります。マルチクラウド・フェイルオーバーは、アプリケーションを別のクラウドにフェイルオーバーできることを前提としています。多くの企業が気づいているように、これは極めて困難です。これを実現するには、2 つの CSP 間の完全なポータビリティを維持する必要があるため、複雑さが増し、リスクが高まり、フェイルオーバーが可能であると信じているとするならさらに作業が増えます。
Gartnerのアナリストでディスティングイッシュト バイスプレジデントのリディア・レオン（Lydia Leong）氏は、マルチクラウド・フェイルオーバーの問題点をツイートにまとめています。「マルチクラウドのフェイルオーバーは複雑でコストがかかり、ほとんどの場合非現実的であり、クラウドやレジリエンスのリスクに対処する上でも特に効果的な方法ではありません。」フェイルオーバーを機能させる際の問題は、CSP の差別化要因（たとえば、ネットワークアーキテクチャと機能の違い、ストレージ機能の違い、独自の高レベルサービス、データベース層、MLサービス、セキュリティ機能の違いなど）にあります。ワークロードが複数の CSP に分散している場合、いずれかの CSP に障害が発生すると機能停止が発生する可能性があります。この場合、ワークロードを複数の CSP に分散させると、実際にはリスクが高まります。
代わりに、「実装と簡素化」によってリスクを軽減することを企業にお勧めします。特定のワークロードやアプリケーションを単一のクラウドを対象とし、それを移行し、マスターし、コストとリスクを軽減し、それを繰り返します。トレーニングを通じて CSP 固有の特徴や能力をより深く学ぶよう促し、すでに統合されている CSP 固有のより高度なサービスやツールを活用しましょう。最後に、そしておそらく最も重要なのは、AWS のリージョンとアベイラビリティーゾーンを活用することです。この分野の AWS の機能は、すでに AWS のお客様に、可用性と信頼性の高いソリューションを実現するための優れた機能を提供しています。
誤解 4: マルチクラウドの方が価格競争力を高める
価格競争力は、マルチクラウドにとって最も弱い論点かもしれません。複雑で高価なソフトウェアやデータセンター契約を複数年契約に縛られるような経験を持つ組織は、ITサービスの調達に慎重になっています。従来の調達アプローチは、従量課金制購入、大量割引、またはクラウドにおける価格競争の現実に適応していませんでした。(AWS はサービス提供以来 129 回も価格を引き下げてきました)。
コスト削減の最大の要因は、企業のクラウド環境がいかに適切に管理され、最適化されているかということです。コストパフォーマンスに優れ (AWS Graviton のようなカスタム設計のチップをベースにしたコンピュートインスタンスなど)、優れたクラウド財務管理ソリューションを提供するサービスを提供するプロバイダーを主に利用することで、コスト最適化が向上する可能性があります。Hackett Group が 1,000 社を超える組織を対象に実施した 2021 年の調査によると、IT 支出総額に占めるインフラストラクチャ支出の割合は、マルチクラウド組織よりも AWS のお客様が 20% 低いことがわかりました。
私たちの経験から、企業は複数のクラウドでの運用による追加コストや複雑さを予測しておらず、直接的なソーシング契約で得られる利益と適切に比較検討していないことがわかっています。
3. 明確な戦略とそれを支えるガバナンスを確立する
マルチクラウド戦略を追求すると決めただけでは十分ではありません。どのワークロードをどこに、なぜ使用するかの明確なガバナンスを含め、マルチクラウドの目標を達成するための戦略を確立する必要があります。評価基準を使用してワークロードとその依存関係を最適化する必要があります。個人に任せれば、CSP 間の無秩序な拡大は、マルチクラウド戦略が達成しようとしていた価値を損なう可能性があります。CSP のワークロードパフォーマンスを定期的に評価し、その評価を CSP の選択、基準、将来の利用に関する重要な情報として活用してください。
全体的なガバナンス戦略の一環として、企業全体で使用されるサービス、アプリケーション、コンポーネントの総数を包括的に把握することが重要です。そのためには、CSPにまたがり、デプロイされたリソースの 100% の所有権、使用状況、環境 (開発、QA、ステージ、プロダクションなど) を明確に確立する強固なタグ付け戦略が不可欠です。すべて所有者にタグ付けする必要があります。タグ付けされていない場合や所有者が特定できない場合は、削除する必要があります。これにより、進捗を妨げるゲートではなく、ガードレールを設けて、ガバナンスルールを体系化し、運用を自動化できます。コスト、運用、セキュリティを同じ方法で追跡、監視、対応し、CSP全体で同じ量のデータと透明性を保たなければなりません。特定のニーズに対応し、複数のCSPで運用できる単一のツールが望ましいです。
4. 連続するワークロードを複数の CSP に分散しない
私の考えでは、複数の CSP にまたがるワークフローは、不必要な複雑さ、リスク、コストをもたらす一方で、サポート、導入、アーキテクチャを複雑にし、付加価値もほとんどありません。連続したワークロードには大量のデータが含まれることが多く、それらをまとめて処理して分析する必要があります。データが複数のクラウドプロバイダーに分散していると、データの移動、同期、一貫性の維持に課題が生じる可能性があります。さらに、複数の CSP にまたがる連続したワークロードの管理は複雑で時間がかかる場合があります。CSP ごとに異なる API、管理インターフェース、セキュリティモデル、運用プロセスを扱う必要があります。このような複雑さは、エラーの可能性を高め、運用上のオーバーヘッドを増大させ、アジリティとスケーラビリティを妨げる可能性があります。
この種の設計やビジネスニーズを評価する際には、具体的な基準と指針を定める必要があります。
5. アプリケーションはトランザクションデータと共にあるべき
開発者が異なるクラウドのアプリケーション間で大量のデータを移動する必要がある場合、特にコンピューティング/アプリケーションをある CSP にデプロイし、別の CSP にデータストレージをデプロイする場合には注意が必要です。このような状況では複雑さが増し、待ち時間が増え、得られるメリットが相殺されてしまう可能性があります。
ワークロードの CSP を決定する決定基準には、そのワークロードを他のワークロードと統合するという長期的な視点を含める必要があります。そのデータは、現在の範囲を超えて高度な分析や機械学習に必要になるのでしょうか？提供されるサービスは他の CSP に広く利用されるのか、それともその CSP のワークロードに限定されるのか。導入に関する考慮事項に関する詳細なガイダンスと意思決定モデルについては、同僚の Gregor Hohpe の「Multi-Cloud: From Buzzword to Decision Model」というブログをご覧ください。
6. コンテナは役に立つがすべてのユースケースを解決できるわけではないことを理解する
コンテナの使用は、現代のあらゆるアプリケーションにとって一般的に良いアイデアであり、移植性の多くの要素に役立ちます。コンテナはプラットフォームに依存しないため、コンテナ化をサポートするあらゆるクラウドプラットフォームやインフラストラクチャで実行できます。これにより、アプリケーションを一度開発してパッケージ化すれば、大きな変更を加えることなく、複数のクラウドプロバイダーやオンプレミス環境に一貫してデプロイできます。ただし、コンテナはすべてのケース (大規模なモノリシックアプリケーションなど) で機能するわけではなく、CSP 間の移植性に関する問題 (特にデータ、ポリシー、セキュリティ) をすべて解決するわけでもないため、注意が必要です。
7. 単一のクラウド・センター・オブ・エクセレンス ( CCoE ) を持ち、その上で専門性を持つ
AWS の多くのお客様にお勧めしているように、クラウド導入のリーダーシップ、標準化、加速を実現するには、組織内の CCoE を活用する必要があります。マルチクラウドに関して言えば、最も成功している企業は CCoE を 1 つだけ持っていながら、特定の CSP に固有のスキル、ツール、メカニズムをその CCoE に特化していることがわかりました。AWS のお客様が CSP ごとに複数の CCoE を持っていると、単一の CCoE によるより協調的なアプローチではなく、分散、再エンジニアリング、無駄につながることが多いことがわかりました。
8. セキュリティが常に最優先事項であることを確認する
マルチクラウドは、不正アクセスやデータ侵害のリスクを高め、セキュリティをより困難にします。マルチクラウドでは、企業は ID 管理、ネットワークセキュリティ、資産管理、監査ログなどの分野で、CSP 全体で複数のセキュリティモデルに対処する必要があります。
このような複雑さは、透明性を難しくし、セキュリティチームの負担を増大させ、リスクを高めます。マルチクラウドに限ったことではありませんが、(1) デリバリーパイプライン、クラウド環境やチームの優先事項にセキュリティにおけるシフトレフトを組み込み、自動化していくこと、(2) CSP 内またはCSP間で保存中および転送中のデータを暗号化することなど、いくつかのコアセキュリティプラクティスがより重要になっています。
マルチクラウド導入に役立つアプローチの 1 つは、セキュリティデータの保存先を 1 つ (つまり、一元管理) にすることです。各 CSP が開発したクラウドネイティブなツールでこれを補強して、その環境内で意味のあるデータが表示されるようにします。
結論
ほとんどの組織にとって、プライマリのクラウド戦略は、シンプルさ、集中力、リスク軽減を通じて最大の価値をもたらすと同時に、企業がパートナーシップを深め、主要な CSP やサービスに関する実務上の知識を深めることを可能にします。これにより、組織はより高度なサービスを活用し、優秀な人材を引き付けて定着させると同時に、企業により早く価値を提供できるようになります。
マルチクラウドのアプローチは理にかなっていますが、企業はこのようなアプローチを採用する決定をビジネスニーズに基づいて行い、関連するトレードオフを明確に理解した上で行う必要があります。このような場合は、単一の CSP から提供でき、CSP 間でデータを共有する可能性が低く、どのワークロードがどこに行くのかを明確に管理できる、アプリケーションとビジネスワークフローに焦点を当てたクラウドモデルをお勧めします。
ハイブリッド環境とマルチクラウド環境の管理と監視を一元化および簡素化し、保存されている場所を問わずすべてのデータへのアクセスを提供し、AWS、オンプレミス、および AWS コンテナサービスを備えたその他のクラウドでアプリケーションを実行するのに役立つ AWS サービスの詳細については、ハイブリッドおよびマルチクラウド向けの AWS ソリューションをご覧ください。