アプリケーションのアーキテクチャ コンポーネントは、フロントエンドまたはバックエンドのいずれかに分類できます。シナリオによっては、これらのコンポーネントをホストして、異なるコンピューティング環境で動作させることができます。階層型ハイブリッド アーキテクチャ パターンの一部として、コンピューティング環境はオンプレミスのプライベート コンピューティング環境と Google Cloud に配置されます。
フロントエンド アプリケーション コンポーネントは、エンドユーザーまたはデバイスに直接公開されます。そのため、フロントエンド アプリケーションでは、パフォーマンスが重視されることが多くなります。新しい機能や改善項目を開発するため、ソフトウェアの更新は頻繁に行われる可能性があります。フロントエンド アプリケーションは通常、データの保存と管理（ビジネス ロジックやユーザー入力処理が含まれる場合もあります）をバックエンド アプリケーションに依存するため、多くの場合にステートレスであるか、管理するデータの量が限られています。
アクセスしやすく使いやすいように、さまざまなフレームワークとテクノロジーを使用してフロントエンド アプリケーションを構築できます。フロントエンド アプリケーションを成功させるための主な要素には、アプリケーションのパフォーマンス、レスポンス速度、ブラウザの互換性などがあります。
バックエンド アプリケーション コンポーネントは通常、データの保存と管理に重点を置いています。一部のアーキテクチャでは、ビジネス ロジックがバックエンド コンポーネントに組み込まれる場合があります。バックエンド アプリケーションの新しいリリースの頻度は、フロントエンド アプリケーションよりも低くなる傾向にあります。バックエンド アプリケーションには、管理すべき次の課題があります。
- 大量のリクエストの処理
- 大量のデータの処理
- データの保護
- すべてのシステム レプリカでの現行データと更新データの維持
3 層アプリケーション アーキテクチャは、さまざまなアプリケーション コンポーネントを含む e コマース ウェブサイトなど、ビジネス ウェブ アプリケーションの構築に最も頻繁に使用される実装の一つです。このアーキテクチャには、次の階層が含まれています。各階層は独立して動作しますが、密接にリンクされており、すべてが連携して機能します。
- ウェブ フロントエンドとプレゼンテーション階層
- アプリケーション階層
- データアクセスまたはバックエンド階層
これらのレイヤをコンテナに配置すると、スケーリング要件などの技術的なニーズが分離され、段階的なアプローチで移行できるようになります。また、環境間で移植可能であり、自動管理を使用でき、Cloud Run や Google Kubernetes Engine（GKE）Enterprise エディションなどのクラウド マネージド プラットフォームでスケーリングできる、プラットフォームに依存しないクラウド サービスにデプロイすることもできます。さらに、Cloud SQL などの Google Cloud マネージド データベースは、データベース レイヤとしてバックエンドを提供する際に活用できます。
階層型ハイブリッド アーキテクチャ パターンでは、既存のフロントエンド アプリケーション コンポーネントをパブリック クラウドにデプロイすることに重点を置いています。このパターンでは、既存のバックエンド アプリケーション コンポーネントをプライベート コンピューティング環境に保持します。アプリケーションの規模と具体的な設計に応じて、フロントエンド アプリケーション コンポーネントをケースバイケースで移行できます。詳細については、Google Cloud への移行をご覧ください。
オンプレミス環境でホストされているバックエンド コンポーネントとフロントエンド コンポーネントを含む既存のアプリケーションがある場合は、現在のアーキテクチャの制限事項を検討してください。たとえば、アプリケーションがスケーリングされ、パフォーマンスと信頼性に対する要件が増加した場合は、アプリケーションの一部をリファクタリングするか、別のより最適なアーキテクチャに移行するべきであるかどうかを最初に評価する必要があります。階層型ハイブリッド アーキテクチャ パターンを使用すると、完全な移行を行う前に、アプリケーションの一部のワークロードとコンポーネントをクラウドに移行できます。また、このような移行に伴う費用、時間、リスクも考慮する必要があります。
次の図は、典型的な階層型ハイブリッド アーキテクチャを示しています。
上の図では、クライアント リクエストは Google Cloud でホストされているアプリケーション フロントエンドに送信されます。次に、アプリケーション フロントエンドは、アプリケーション バックエンドがホストされているオンプレミス環境にデータを返送します（API ゲートウェイを経由することが理想です）。
次の図のアーキテクチャ例に示すように、階層型ハイブリッド アーキテクチャ パターンを使用すると、Google Cloud インフラストラクチャとグローバル サービスを活用できます。アプリケーション フロントエンドには Google Cloud 経由でアクセスできます。また、自動スケーリングを使用して、インフラストラクチャを過剰にプロビジョニングすることなく、スケーリング需要に動的かつ効率的に応答することで、フロントエンドの弾力性を高めることもできます。Google Cloud でスケーラブルなウェブアプリを構築して実行するために使用できるアーキテクチャはいくつかあります。アーキテクチャによって、さまざまな要件に対するメリットとデメリットが異なります。
詳細については、YouTube で Google Cloud でスケーラブルなウェブアプリを実行する 3 つの方法をご覧ください。Google Cloud で e コマース プラットフォームをモダナイズするさまざまな方法について詳しくは、Google Cloud でデジタル コマース プラットフォームを構築する方法をご覧ください。
上の図では、アプリケーション フロントエンドは Google Cloud でホストされています。これにより、グローバルなロード バランシング、自動スケーリング、Google Cloud Armor による DDoS 保護を使用して、マルチリージョンでグローバルに最適化されたユーザー エクスペリエンスを提供できます。
時間の経過とともに、パブリック クラウドにデプロイされるアプリケーションの数が増え、バックエンド アプリケーション コンポーネントのパブリック クラウドへの移行が検討される状態に達する場合があります。大量のトラフィックを処理する必要がある場合は、クラウド マネージド サービスを利用すると、独自のインフラストラクチャを管理する際のエンジニアリング リソースを節約できます。制約や要件でバックエンド アプリケーション コンポーネントをオンプレミスでホストすることが義務付けられている場合を除き、このオプションを検討してください。たとえば、バックエンド データが規制による制限の対象である場合は、データをオンプレミスに保持する必要があると考えられます。ただし、適用可能でありコンプライアンスを遵守している場合は、匿名化の手法などの Sensitive Data Protection の機能を使用して、必要に応じてデータを移動できます。
階層型ハイブリッド アーキテクチャ パターンでは、一部のシナリオで Google Distributed Cloud を使用することもできます。Distributed Cloud を使用すると、Google が提供し Google Cloud データセンターと分離して管理する専用ハードウェアで Google Kubernetes Engine クラスタを実行できます。Distributed Cloud が現在の要件と将来の要件を満たすようにするには、従来のクラウドベースの GKE ゾーンと比較した場合の Distributed Cloud の制限事項を把握してください。
利点
最初にフロントエンド アプリケーションに焦点を当てることには、以下に示すものを含めいくつかのメリットがあります。
- フロントエンド コンポーネントは、バックエンド リソースに依存します。場合によっては、他のフロントエンド コンポーネントに依存することもあります。
- バックエンド コンポーネントはフロントエンド コンポーネントに依存しません。したがって、フロントエンド アプリケーションの分離と移行は、バックエンド アプリケーションの移行ほど複雑ではない傾向があります。
- 一方、フロントエンド アプリケーションは、ステートレスであるか、それ自身はデータを管理しない場合が多いため、バックエンドよりも移行が容易である傾向があります。
- フロントエンド コンポーネントは、ステートレス アーキテクチャを使用するように移行の一環として最適化できます。詳細については、YouTube で ステートフル ウェブアプリを Cloud Run に移植する方法をご覧ください。
既存または新規開発のフロントエンド アプリケーションをパブリック クラウドにデプロイすることには、いくつかのメリットがあります。
- 多くのフロントエンド アプリケーションは頻繁に変更されます。パブリック クラウドでこれらのアプリケーションを実行すると、継続的インテグレーション / 継続的デプロイ（CI / CD）プロセスの設定が簡略化されます。CI / CD を使用すると、効率的かつ自動的にアップデートを送信できます。詳細については、Google Cloud での CI / CD をご覧ください。
- トラフィック負荷が変動するパフォーマンス重視のフロントエンドでは、クラウドベースのデプロイで利用できるロード バランシング、マルチリージョン デプロイ、Cloud CDN キャッシュ、サーバーレス、自動スケーリング機能（理想的にはステートレス アーキテクチャを使用）による大きなメリットが得られます。
GKE などのクラウド管理プラットフォームを使用してコンテナでマイクロサービスを採用すると、マイクロサービスをフロントエンド コンポーネントに拡張するマイクロフロントエンドなどの最新のアーキテクチャを使用できます。
マイクロサービスの拡張は、同じアプリケーションで複数のチームがコラボレーションするフロントエンドに対して一般的に使用されます。このようなチーム構造では、反復的なアプローチと継続的なメンテナンスが必要です。マイクロフロントエンドの使用には次のような利点があります。
- 開発、テスト、デプロイ用の独立したマイクロサービス モジュールにできます。
- 個別の開発チームが適したテクノロジーとコードを選択できる分離を実現します。
- これにより、他のチームが管理している可能性がある他のフロントエンド コンポーネントに影響を与えることなく、開発とデプロイの迅速なサイクルを促進できます。
ユーザー インターフェースや API を実装している、またはモノのインターネット（IoT）データの取り込みを処理している場合でも、フロントエンド アプリケーションでは、Firebase、Pub/Sub、Apigee、Cloud CDN、App Engine、Cloud Run などのクラウド サービスの機能を活用できます。
Cloud マネージド API プロキシは、次の目的に役立ちます。
- アプリ側の API をバックエンド サービス（マイクロサービスなど）から分離します。
- バックエンド コードの変更からアプリを保護します。
- バックエンド フォー フロントエンド（BFF）、マイクロフロントエンドなど、既存の API ドリブンのフロントエンド アーキテクチャをサポートします。
- Apigee で API プロキシを実装して、Google Cloud などの環境で API を公開します。
プライベート コンピューティング環境でフロントエンド アプリケーションを維持しながら、クラウドでバックエンドをデプロイすることによって、階層型ハイブリッド パターンを逆方向に適用することもできます。あまり一般的ではありませんが、このアプローチは、大規模でモノリシックなフロントエンド アプリケーションを扱う場合に適しています。そのような場合は、バックエンド機能の抽出を繰り返しながら、クラウドで新しいバックエンドをデプロイするほうが簡易であることが考えられます。
このシリーズの第 3 部では、このようなアーキテクチャを実現するために考えられるネットワーキング パターンについて説明します。Apigee ハイブリッドは、ハイブリッド デプロイモデルで API プロキシを構築して管理するためのプラットフォームとし活用できます。詳細については、階層型モノリシック アーキテクチャとマイクロサービス アーキテクチャを含む疎結合アーキテクチャをご覧ください。
ベスト プラクティス
階層型ハイブリッド アーキテクチャを計画する際には、このセクションの情報を使用してください。
複雑さを軽減するためのベスト プラクティス
階層型ハイブリッド アーキテクチャ パターンを適用する際は、全体的なデプロイと運用の複雑さを軽減できる次のベスト プラクティスを検討してください。
- 特定されたアプリケーションの通信モデルの評価に基づいて、それらのアプリケーションに最も効率的で効果的な通信ソリューションを選択します。
ユーザーの操作のほとんどが複数のコンピューティング環境をまたがるシステムに関係しているため、システム間の高速かつ低レイテンシの接続が重要になります。可用性とパフォーマンスの要件を満たすには、高可用性、低レイテンシ、適切なスループット レベルを実現するように設計する必要があります。セキュリティの観点から、通信は詳細に制御する必要があります。理想的には、安全な API を使用してアプリケーション コンポーネントを公開する必要があります。詳細については、下り（外向き）ゲート型をご覧ください。
- 環境間の通信レイテンシを最小限に抑えるには、アプリケーション バックエンド コンポーネントがホストされているプライベート コンピューティング環境に地理的に近い Google Cloud リージョンを選択します。詳細については、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
- 異なる環境で動作するシステム間の高い依存性を最小限に抑えます（特に、通信が同期的に処理されている場合）。こうした依存関係は、パフォーマンスの低下、全体的な可用性の低下、アウトバウンド データ転送の追加料金が発生する原因となる可能性があります。
- 階層型ハイブリッド アーキテクチャ パターンでは、Google Cloud からのアウトバウンド トラフィック量よりも、オンプレミス環境から Google Cloud へのインバウンド トラフィック量が多い場合があります。ただし、Google Cloud から送信されるアウトバウンド データ転送の予測量を把握しておく必要があります。アウトバウンド データ転送量が多い状態でこのアーキテクチャを長期的に使用する場合は、Cloud Interconnect の使用を検討してください。Cloud Interconnect を使用すると、接続パフォーマンスを最適化し、特定の条件を満たすトラフィックのアウトバウンド データ転送料金を削減できます。詳しくは、Cloud Interconnect の料金をご覧ください。
- 機密情報を保護するため、転送中のすべての通信を暗号化することをおすすめします。接続レイヤで暗号化が必要な場合は、VPN トンネル、Cloud Interconnect を介した HA VPN、Cloud Interconnect の MACsec を使用できます。
さまざまなバックエンド間でプロトコル、API、認証メカニズムの不整合を解消するには、必要に応じて、統合ファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
ハイブリッド設定の確立を容易にするには、ハイブリッド接続で Cloud Load Balancing を使用します。つまり、クラウドのロード バランシングによるメリットの対象を、オンプレミス コンピューティング環境でホストされているサービスに拡張できます。このアプローチでは、サービスを中断することなく、または中断を最小限に抑えながら、Google Cloud へのワークロードの段階的な移行が可能になり、分散サービスのスムーズな移行が実現します。詳細については、ハイブリッド接続ネットワーク エンドポイント グループの概要をご覧ください。
API ゲートウェイ、またはプロキシとアプリケーション ロードバランサを組み合わせて使用すると、API トラフィックの大規模な管理、保護、分散を行うための、より堅牢なソリューションを実現できます。API ゲートウェイで Cloud Load Balancing を使用すると、次のことができます。
- Apigee と Cloud CDN を使用して高パフォーマンスの API を提供することでレイテンシを短縮し、API をグローバルにホストして、トラフィックのピーク時の可用性を高めます。詳細については、YouTube で Apigee と Cloud CDN を使用した高パフォーマンスの API の提供をご覧ください。
- 高度なトラフィック管理を実装します。
- Google Cloud Armor を DDoS 保護サービスとネットワーク セキュリティ サービスとして使用し、API を保護します。
- 複数のリージョンにあるゲートウェイ間の効率的なロード バランシングを管理します。詳細については、YouTube で Private Service Connect と Apigee による API の保護とマルチリージョン フェイルオーバーの実装をご覧ください。
API 管理とサービス メッシュを使用して、マイクロサービス アーキテクチャでサービスの通信と公開を保護して制御します。
- Cloud Service Mesh を使用すると、分散サービスで構成されたシステムでサービスの品質を維持するサービス間通信が可能になり、サービス間の認証、認可、暗号化を管理できます。
- Apigee などの API 管理プラットフォームを使用して、組織と外部エンティティが API として公開することで、これらのサービスを使用できるようにします。
システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。
CI / CD システムと構成管理システムをパブリック クラウドにデプロイします。詳細については、ミラーリングされたネットワーキング アーキテクチャ パターンをご覧ください。
運用効率を高めるために、環境間で一貫したツールと CI / CD パイプラインを使用します。
個別のワークロードとアプリケーション アーキテクチャのベスト プラクティス
- このパターンでは、フロントエンドに重点を置いていますが、バックエンド アプリケーションをモダナイズする必要性にも注意してください。バックエンド アプリケーションの開発ペースがフロントエンド アプリケーションの開発ペースより大幅に遅い場合、その差は複雑さを増加させる要因となる可能性があります。
- API をバックエンド インターフェースとして扱うことで、インテグレーション、フロントエンド開発、サービス インタラクションを効率化し、バックエンド システムの複雑さを隠すことができます。これらの課題に対処するため、Apigee は、ハイブリッド クラウドとマルチクラウドのデプロイに関する API ゲートウェイ / プロキシの開発と管理を容易にします。
- コンテンツ（静的か動的か）、検索エンジン最適化のパフォーマンス、ページ読み込み速度に関する期待値に基づいて、フロントエンド ウェブ アプリケーションのレンダリング アプローチを選択します。
- コンテンツ ドリブン ウェブ アプリケーションのアーキテクチャを選択する場合は、モノリシック、サーバーレス、イベントベース、マイクロサービスのアーキテクチャなどのさまざまなオプションがあります。最適なアーキテクチャを選択するには、現在のアプリケーション要件と将来のアプリケーション要件を踏まえて、これらのオプションを徹底的に評価します。ビジネスと技術の目標に沿ったアーキテクチャの決定を行うには、コンテンツ ドリブンのウェブ アプリケーション バックエンドのさまざまなアーキテクチャの比較とウェブ バックエンドの主な考慮事項をご覧ください。
マイクロサービス アーキテクチャでは、Kubernetes を共通のランタイム レイヤとして使用して、コンテナ化されたアプリケーションを使用できます。階層型ハイブリッド アーキテクチャ パターンでは、次のいずれかのシナリオで実行できます。
両方の環境（Google Cloud 環境とオンプレミス環境）にわたって。
- 環境全体でコンテナと Kubernetes を使用すると、ワークロードをモダナイズしてから Google Cloud に移行するタイミングを柔軟に選択できます。これは、ワークロードが別のワークロードに大きく依存しているために個別に移行できない場合や、ハイブリッド ワークロードのポータビリティを使用して各環境で利用可能な最適なリソースを使用する場合に有効です。いずれの場合も、GKE Enterprise は重要な実現技術になります。詳細については、GKE Enterprise ハイブリッド環境をご覧ください。
移行して最新化したアプリケーション コンポーネントの Google Cloud 環境。
- このアプローチは、コンテナ化のサポートがないレガシー バックエンドがオンプレミスにある場合や、短期間でモダナイズするために大量の時間とリソースを必要とする場合に使用します。
モノリシック アプリをマイクロサービス アーキテクチャに設計してリファクタリングし、ウェブ アプリケーション アーキテクチャをモダナイズする場合について詳しくは、マイクロサービスの概要をご覧ください。
ウェブ アプリケーションのニーズに応じて、データ ストレージ テクノロジーを組み合わせることができます。構造化データに Cloud SQL を使用し、メディア ファイルに Cloud Storage を使用することは、さまざまなデータ ストレージのニーズに対応するための一般的な方法です。ただし、選択はユースケースに大きく依存します。コンテンツ ドリブン アプリケーションのバックエンドと効果的なモダリティのデータ ストレージ オプションの詳細については、コンテンツ ドリブン ウェブアプリのデータ ストレージ オプションをご覧ください。Google Cloud のデータベース オプションについての説明もご覧ください。