Last reviewed 2023-12-14 UTC
クラウドでワークロードを実行するには、一部のシナリオにおいてクライアントが高速かつ信頼性の高いインターネット接続性を備えている必要があります。今日のネットワークにおいては、この要件がクラウド導入の障害になることはほとんどありません。ただし、次に示すように継続的な接続を利用できないシナリオが考えられます。
- 海洋を航行する船舶、その他の車両においては、断続的な接続のみが利用可能、またはレイテンシの高い衛星リンクを介してのみアクセスが可能な場合があります。
- 工場や発電所がインターネットに接続されている可能性があります。インターネット プロバイダによって保証される可用性では、これらの施設における信頼性の要件を満たすのに不十分な場合があります。
- 小売店やスーパーマーケットでは、接続に間断がある、または使用している接続において、ビジネス クリティカルな取引の処理に必要な信頼性やスループットが実現されない場合もあります。
エッジ型アーキテクチャ パターンでは、時間またはビジネスの面でクリティカルなワークロードをネットワークのエッジでローカル実行し、他の種類のワークロードにクラウドを使用することで、これらの課題に対処しています。エッジ ハイブリッド アーキテクチャでは、インターネット接続は、管理目的やデータの同期化またはアップロード（多くの場合に非同期で）に使用される重要でないコンポーネントであり、緊急時や重要業務のトランザクションには関与しません。
利点
特定のワークロードをエッジで実行し、他のワークロードをクラウドで実行することには、いくつかのメリットがあります。
- インバウンド トラフィック（エッジから Google Cloud へのデータ移動）は追加料金なしで利用できる場合があります。
- 時間やビジネスの面でクリティカルなワークロードをエッジで実行した場合、レイテンシが低下し自足性も向上します。また、インターネットに接続できない場合や一時的に利用できない場合でも、重要なトランザクションをすべて実行できます。同時に、全体のワークロードのかなりの部分をクラウドで実行することは有益です。
- 既存の投資をコンピューティングおよびストレージ機器に再利用できます。
- 時間の経過に伴い、特定のアプリケーションをリワークするか、エッジが所在する場所に信頼性の高いインターネット接続を装備することによって、エッジで実行されるワークロードの割合を徐々に低減し、クラウドに移行できます。
- モノのインターネット（IoT）関連のプロジェクトでは、ローカルでデータ計算を行うことで費用対効果を高めることができます。これにより、企業は一部のサービスをデータソースにより近いエッジでローカルに実行できます。また、企業はデータをクラウドに選択的に送信できるため、IoT ソリューションの容量、データ転送、処理、全体的なコストを削減できます。
- エッジ コンピューティングは、従来のサービスと最新のサービス間の中間通信レイヤとして機能します。たとえば、コンテナ化された API ゲートウェイ（Apigee ハイブリッドなど）を実行しているサービスが該当します。これにより、レガシー アプリケーションとシステムを、IoT ソリューションなどのモダナイズされたサービスと統合できます。
ベスト プラクティス
エッジ型アーキテクチャ パターンを実装するときは、次の推奨事項を考慮してください。
- 通信が単方向である場合は、上り（内向き）ゲート型パターンを使用します。
- 通信が双方向の場合は、下り（外向き）ゲート型と上り（内向き）ゲート型のパターンを検討してください。
- ソリューションが、公共のインターネット経由で Google Cloud に接続する多数のエッジ リモートサイトで構成されている場合は、ソフトウェア定義 WAN（SD-WAN）ソリューションを使用できます。また、Google Cloud パートナーがサポートするサードパーティの SD-WAN ルーターと Network Connectivity Center を組み合わせて使用すると、大規模なセキュア接続のプロビジョニングと管理を簡素化できます。
- エッジで実行されるシステムとクラウド環境で実行されるシステムの間の依存関係を最小限に抑えます。依存関係があると、エッジ型ハイブリッド設定で得られる信頼性とレイテンシに関するメリットが損なわれる可能性があります。
- 複数のエッジのロケーションを効率的に管理して操作するには、クラウドに一元管理プレーンとモニタリング ソリューションを用意する必要があります。
- クラウド環境とエッジ環境間で、CI / CD プロセス、および、デプロイとモニタリング用のツールが一貫していることを確認します。
- 適用可能かつ実現可能な場合は、コンテナと Kubernetes を使用して、さまざまなエッジ ロケーション間、およびエッジ ロケーションとクラウド間の差異を抽象化することを検討してください。Kubernetes は共通のランタイム レイヤを提供するため、コンピューティング環境全体でワークロードを一貫して開発、実行、操作できます。エッジとクラウド間でワークロードを移動することもできます。
- ハイブリッドの設定とオペレーションを簡素化するために、このアーキテクチャに GKE Enterprise を使用できます（環境間でコンテナが使用されている場合）。オンプレミス環境またはエッジ環境で実行されている GKE Enterprise クラスタを Google Cloud に接続するために必要な使用可能な接続オプションを検討します。
- このパターンでは、GKE Enterprise コンポーネントの一部は Google Cloud への接続が一時的に中断されても動作する場合がありますが、通常の動作モードとして Google Cloud から切断された GKE Enterprise を使用しないでください。詳細については、Google Cloud からの一時的な接続解除の影響をご覧ください。
- さまざまなバックエンド サービスとエッジサービス間でプロトコル、API、認証メカニズムの不整合を克服するには、必要に応じて、統合されたファサードとして API ゲートウェイまたはプロキシをデプロイすることをおすすめします。このゲートウェイまたはプロキシは、一元化された制御ポイントとして機能し、次の対策を行います。
- 追加のセキュリティ対策を実装します。
- クライアント アプリやその他のサービスをバックエンド コードの変更から保護します。
- すべてのクロス環境アプリとその分離されたコンポーネント間の通信の監査証跡を容易にします。
- レガシー サービスと最新のサービス間の中間通信レイヤとして機能します。
- Apigee と Apigee ハイブリッドを使用すると、オンプレミス環境、エッジ、他のクラウド、Google Cloud 環境にわたってエンタープライズ クラスのハイブリッド ゲートウェイをホストして管理できます。
- システムが環境の境界を越えて安全に認証できるように、環境間に共通の ID を確立します。
- 環境間で交換されるデータは機密情報であることが考えられるため、VPN トンネル、TLS、またはその両方を使用して、すべての通信が暗号化されるようにしてください。