このドキュメントでは、ビジネスの目標、推進要因、要件の定義とその説明を示すとともに、これらの要素がハイブリッドとマルチクラウドのアーキテクチャを構築するときの設計上の意思決定にどのように影響するかを説明します。
目標
組織は、ハイブリッドまたはマルチクラウド アーキテクチャを特定のビジネス目標達成のための恒久的なソリューションとして採用することもあれば、特定の要件（たとえばクラウドへの移行）の達成を容易にするための一時的な状態として採用することもあります。
ビジネス要件を定義するために、およびビジネス目標を達成する方法について具体的な見通しを立てるために、ビジネスに関する次の質問への答えを考えることをおすすめします。これらの質問の焦点は、お客様のビジネスに何が必要かであり、それを技術的にどう実現するかではありません。
- どのビジネスゴールが動機となって、ハイブリッドまたはマルチクラウド アーキテクチャの採用という決定に至っているのですか？
- ハイブリッドまたはマルチクラウド アーキテクチャの採用によって達成されるのは、ビジネス面と技術面のどのような目標ですか？
- これらの目標に影響を与えるビジネス推進要因は何ですか？
- 具体的なビジネス要件はどのようなものですか？
ハイブリッドやマルチクラウドのアーキテクチャに関して、エンタープライズ企業が持つビジネスゴールの例としては、オンライン販売の事業運営または市場を単一地域から拡張してその市場セグメントでのグローバル リーダーになるというものが考えられます。ビジネス目標の例としては、世界中の（または特定の地域の）ユーザーからの発注の受け付けを 6 か月以内に開始するというものが考えられます。
前述のビジネス要件と目標をサポートするための、技術面での主な目標の例としては、パブリック クラウドのグローバルな能力とサービスを使用して会社の IT インフラストラクチャとアプリケーション アーキテクチャをオンプレミスのみのモデルからハイブリッド アーキテクチャに拡張するというものが考えられます。この目標は具体的かつ測定可能であることが必要であり、これで拡張のスコープがターゲットの地域およびタイムラインとして明確に定義されます。
一般に、ハイブリッドまたはマルチクラウド アーキテクチャはそれ自体がゴールとなることはまれであり、特定のビジネス要件を満たすために設定された技術面の目標を達成するための手段となります。したがって、ハイブリッドまたはマルチクラウド アーキテクチャを適切に選択するには、最初にこれらの要件を明確にする必要があります。
重要なのは、IT プロジェクトのビジネス面の目標と技術面の目標を区別することです。ビジネス面の目標は、組織のゴールと使命に焦点を当てたものとなるようにしてください。技術面の目標では、組織のビジネス面の要件と目標の達成を可能にする技術基盤の構築に焦点を当ててください。
ビジネス推進要因は、ビジネス面の目標とゴールの達成に影響を与えます。したがって、ビジネス推進要因が明確に特定されていれば、ビジネス面の目標またはゴールを市場のニーズやトレンドに合わせて形成するのが容易になります。
次のフローチャートは、ビジネス面の推進要因、ゴール、目標、要件と、技術面の目標と要件が、相互にどのように関連しているかを示しています。
ビジネス面と技術面の推進要因
ビジネス面の推進要因が技術面の目標にどのように影響するかを考慮してください。ハイブリッド アーキテクチャを選ぶときに影響を与える、一般的なビジネス推進要因の例を次に示します。
- データ主権に関する法律および規制への留意。
- 資本的支出（CAPEX）または IT 全般の支出を、クラウド財務管理とコスト最適化の規律（たとえば FinOps）を利用して縮小する。
- CAPEX 縮小につながるシナリオがクラウド導入の推進要因となることがあります。たとえば障害復旧ソリューションをハイブリッドまたはマルチクラウドのアーキテクチャで構築することです。
- ユーザー エクスペリエンスの向上。
- 変化する市場の需要に対応するための柔軟性とアジリティの向上。
- コストとリソース消費に関する透明性の向上。
ハイブリッドまたはマルチクラウド アーキテクチャ採用へのビジネス面の推進要因を、リストにまとめて検討してください。個別に検討することは避けてください。最終的な決定は、ビジネスの優先事項のバランスに基づいて行ってください。
クラウドのメリットを認識した組織は、完全移行を決定する可能性がありますが、それには制約がないことが条件となります。制約の一例がコストであり、他にもコンプライアンスの要件としてきわめて機密性の高いデータをオンプレミスでホストすることが義務付けられている場合は、完全移行は難しくなります。
単一クラウド プロバイダ採用には多数のメリットがあり、たとえば複雑さの軽減や、サービス間の統合の組み込み、コスト最適化オプション（たとえば確約使用割引）が考えられますが、マルチクラウド アーキテクチャがビジネスにとって有益となるシナリオもあります。次に示すのは、マルチクラウド アーキテクチャ採用へのビジネス推進要因として一般的なものと、それぞれに付随する考慮事項です。
- データ主権に関する法律および規制への留意: 最も一般的なシナリオは、組織がビジネスを新たな地域または国に拡張するときにデータ ホスティングに関する新たな規制の遵守が必要であるというものです。
- すでに使用しているクラウド サービス プロバイダ（CSP）にはその国でのローカル クラウド リージョンがないという場合は、その国にローカル クラウド リージョンを持つ別の CSP を使用するのが、コンプライアンスの目的を果たすための一般的な解決策です。
- コスト縮小: コスト縮小は多くの場合、特定の技術またはアーキテクチャ採用へのビジネス推進要因として最も一般的です。ただし、マルチクラウド アーキテクチャを採用するかどうかを決定するときは、サービスのコストと想定される価格割引以外についても考えることが重要です。複数のクラウドにまたがるソリューションの構築と運用に要するコストと、既存のシステムに起因するアーキテクチャ面の制約（ある場合）を考慮に入れてください。
時には、マルチクラウド戦略に付随する潜在的な課題がメリットを上回ることもあります。マルチクラウド戦略を採用した結果、追加コストが後で発生することもあります。
マルチクラウド戦略の策定に付随する一般的な課題としては、次のものがあります。
- 管理の複雑さの増大。
- 一貫したセキュリティの維持。
- ソフトウェア環境の統合。
- クロスクラウドでの一貫したパフォーマンスと信頼性の達成。
- マルチクラウドのスキルを持つ技術チームを作るには高額のコストがかかる可能性があり、第三者企業によって管理されるものでない場合は、チームの拡張が必要になる可能性があります。
- 各 CSP のプロダクトの価格と管理ツールの管理。
- コストの可視化とダッシュボードをまとめて提供するソリューションがなければ、複数の環境にまたがるコスト管理を効率的に行うことは困難です。これに該当する場合は、可能であれば Looker のクラウドコスト管理ソリューションを使用することをおすすめします。詳細については、クラウド料金請求コスト管理を効果的に最適化するための戦略をご覧ください。
- 各 CSP 提供の独自機能の使用: マルチクラウド アーキテクチャを採用する組織は、自らの強みを活かした商品やサービスを向上させる新しいテクノロジーを追加するときに、単一クラウド プロバイダが提供する選択肢しか選べないという制限はなくなります。
- 予期しないリスクや複雑さを回避するには、どのような課題が考えられるかを実現可能性と有効性の評価を通じて明らかにしてください。これには前述の一般的な問題も含まれます。
- ベンダー ロックインの回避: エンタープライズ企業は、単一のクラウド プロバイダのみへの依存を避けることが必要になる場合もあります。マルチクラウド アプローチを採用すると、ビジネスのニーズに応じて最適なソリューションを選択できます。ただし、この決定が現実的かどうかは、次のようなさまざまな要因に左右されます。
- 技術的な依存関係
- アプリケーション間の相互運用性に関する考慮事項
- アプリケーションのリビルドまたはリファクタリングのコスト
- 技術的なスキルセット
- 一貫したセキュリティと管理性
- ビジネス クリティカルなアプリケーションの信頼性と可用性のレベル向上: シナリオによっては、マルチクラウド アーキテクチャを採用するとサービス停止時のレジリエンスを実現できます。たとえば、ある CSP の 1 つのリージョンがサービスを停止した場合に、トラフィックの宛先を同じリージョン内の別の CSP にすることができます。このシナリオは、必要な機能またはサービスを両方のクラウド プロバイダがそのリージョンでサポートしていることを前提としています。
特定の国または地域にデータ所在地に関する規制があり、センシティブ データ（たとえば個人を特定できる情報）をその場所の中に保存することが義務付けられている場合は、マルチクラウド アプローチを採用すると、規制を遵守するソリューションが実現します。サービス停止時のレジリエンスを実現するために 2 つの CSP を 1 つのリージョン内で使用することによって、規制による制限の遵守と同時に、可用性の要件にも対処することができます。
レジリエンスに関しては、マルチクラウド アーキテクチャを採用する前に次のことを明らかにしてください。
- データの移動: マルチクラウド環境内でデータが移動する頻度はどの程度ですか？
- データの移動が理由で高額のデータ転送料金が請求される可能性はありますか？
- セキュリティと管理性: セキュリティまたは管理性が複雑になる可能性はありますか？
- 機能の同等性: どちらの CSP も、選択されたリージョン内で必要な機能とサービスを提供していますか？
- 技術的なスキルセット: 技術チームはマルチクラウド アーキテクチャの管理に必要なスキルを持っていますか？
レジリエンス向上を目的とするマルチクラウド アーキテクチャ使用の実現可能性を評価するときは、これらの要素すべてを考慮してください。
マルチクラウド アーキテクチャの実現可能性を評価するときは、長期的なメリットを考慮することが重要です。たとえば、障害復旧または信頼性向上を目的としてアプリケーションを複数のクラウドにデプロイすると、短期的にはコストが増加する可能性がありますが、サービスの停止や障害を防ぐことができます。このような障害が実際に発生すれば、長期に及ぶ財務的損失や評判の低下につながる可能性があります。したがって、マルチクラウド採用の短期的なコストと長期的に期待できる価値を比較することが重要です。また、長期的に期待できる価値は、組織の規模、テクノロジーのスケール、テクノロジー ソリューションのクリティカル性、業種によって異なります。
ハイブリッドまたはマルチクラウド環境作りの成功に向けた計画を立てている組織は、Cloud Center of Excellence（COE）の構築を検討する必要があります。COE チームがパイプ役となって、組織内の各チームがビジネスに貢献する方法をクラウドへの移行時に変革することができます。COE は、組織がクラウドの導入に要する時間を短縮し、標準化を推進し、組織のビジネス戦略とクラウド投資の整合性をより強固に維持するための方法の一つです。
一時的な状態を作ることがハイブリッドまたはマルチクラウド アーキテクチャの目標である場合の、一般的なビジネス推進要因には次のものがあります。
- 短期プロジェクトの CAPEX または IT 全般支出の削減の必要性。
- 特定のビジネス ユースケースをサポートするインフラストラクチャを短時間でプロビジョニングする能力。次に例を示します。
- このアーキテクチャは、期間限定のプロジェクトに使用されるものです。あるプロジェクトで大規模な分散インフラストラクチャが一定の期間だけ必要となり、しかもオンプレミスにあるデータを使用したいという場合に、このようなプロジェクトをサポートするのに使用できます。
- 大企業が複数年にわたるデジタル トランスフォーメーション プロジェクトを必要としており、インフラストラクチャとアプリケーションのモダナイゼーションをビジネスの優先事項に整合させるために、ハイブリッド アーキテクチャを確立してしばらくの間使用する必要がある。
- 企業合併後に一時的なハイブリッド、マルチクラウド、または混合型のアーキテクチャを作成する必要がある。これで、新組織が新しいクラウド アーキテクチャの最終的な状態に向けた戦略を定義できます。合併する 2 社がそれぞれ別のクラウド プロバイダを使用している、あるいは一方がオンプレミスのプライベート データセンターを使用し他方がクラウドを使用しているということはよくあります。どちらの場合でも、M&A の最初のステップは IT システムの統合であることがほとんどです。
技術面の推進要因
前のセクションでは、ビジネス面の推進要因について説明しました。アーキテクチャに関する重要な意思決定の承認を得るには、ほぼすべての場合に、これらの推進要因の支持が必要になります。しかし、技術面の推進要因（その基になるのは技術的な利得のことも、制約のこともあります）も、ビジネス面の推進要因に影響を与えることがあります。場合によっては、技術面の推進要因をビジネス面の推進要因に言い換えて、それがどのようにビジネスにプラスまたはマイナスの影響を与えるかを説明することが必要になります。
次に示すのは、ハイブリッドまたはマルチクラウド アーキテクチャの採用への技術面の一般的な推進要因のうち、ごく一部のリストです。
- 高度な分析サービスや AI などの技術的能力を発展させたいが、既存の環境では実装が困難である。
- サービスの品質とパフォーマンスの向上。
- 製品化までの時間とサイクル時間の短縮を目的とする、アプリケーションのロールアウトの自動化とスピードアップ。
- 開発スピードを上げるための、ハイレベルの API とサービスの活用。
- コンピューティングとストレージのリソース プロビジョニングのスピードアップ。
- サーバーレス サービスを使用して、弾力性のある（エラスティックな）サービスと機能を短期間で大規模に構築する。
- グローバル インフラストラクチャの能力を使用して、特定の技術要件を満たすグローバルまたはマルチリージョンのアーキテクチャを構築する。
一時的なハイブリッドと一時的なマルチクラウドの両アーキテクチャに共通する技術面の推進要因として最も一般的なものは、オンプレミスからクラウドへの、または追加のクラウドへの移行を容易にすることです。一般的に、クラウド移行のほとんどは自然に、ハイブリッド クラウド セットアップに至ります。エンタープライズ企業の多くは、アプリケーションとデータの移行を体系的に、自社の優先順位に基づいて行う必要があります。同様に、短期的なセットアップの目的は、概念実証を行うために、クラウドで利用可能な高度なテクノロジーを特定の期間だけ使用するというものが考えられます。
技術的設計の決定
特定された技術面の目標とその推進要因は、ビジネス ドリブンでアーキテクチャを決定するための、およびこのガイドで説明するアーキテクチャ パターンの 1 つを選ぶための鍵となります。たとえば、特定のビジネスゴールをサポートするために企業が設定するビジネス目標の例として、3～6 か月間の研究開発業務を構築するというものがあります。この目標をサポートする主たるビジネス要件は、研究と設計に必要なテクノロジー環境を、可能な限り CAPEX を抑えて構築することです。
このケースの技術面の目標は、一時的なハイブリッド クラウド セットアップを用意することです。この技術面の目標の推進要因は、クラウドの利点であるオンデマンド価格モデルを利用して前述のビジネス要件を満たすことです。もう一つの推進要因には特定のテクノロジー要件が影響を与えており、この要件ではコンピューティング容量が高く短時間でのセットアップが可能なクラウドベースのソリューションが求められています。
Google Cloud をハイブリッドとマルチクラウドのアーキテクチャに使用する
オープンソースのソリューションを使用すると、ハイブリッドとマルチクラウドのアプローチを取り入れるのが簡単になるとともに、ベンダー ロックインを最小限に抑えることができます。ただし、次の点での複雑さが考えられるため、アーキテクチャを計画するときにこれらを考慮する必要があります。
- 相互運用性
- 管理性
- コスト
- セキュリティ
オープンソースをサポートするとともにそれに貢献しているクラウド プラットフォームを基盤として選ぶと、ハイブリッドとマルチクラウドのアーキテクチャの導入への過程を単純にできる可能性があります。オープン クラウドというアプローチを取ると、選択肢を最大限に増やすとともに、複雑さを取り除くことができます。加えて、柔軟性を特徴としている Google Cloud では、アプリケーションの移行、構築、最適化をハイブリッドとマルチクラウドの環境を横断して行うと同時にベンダー ロックインを最小限に抑え、各分野の最高水準のソリューションを使用でき、規制要件を満たすことができます。
Google はオープンソース エコシステムへの貢献が最大の参加者でもあり、オープンソース コミュニティと協力して、よく知られているオープンソース テクノロジーを開発していますが、その一つが Kubernetes です。Kubernetes をマネージド サービスとしてロールアウトすると、ハイブリッドとマルチクラウドの管理性とセキュリティにまつわる複雑さを軽減できます。