Amazon Web Services ブログ
Amazon CloudFront がアプリケーションの gRPC 呼び出しを受け入れるようになりました
11 月 20 日より、弊社のグローバルコンテンツ配信ネットワーク (CDN) である Amazon CloudFront を gRPC API エンドポイントの前にデプロイできるようになりました。
gRPC は API を構築するための効率的なモダンフレームワークで、言語に依存しません。インターフェイス定義言語 (IDL) として Protocol Buffers (protobuf) を使用しているため、プラットフォームに依存しない方法でサービスとメッセージタイプを定義できます。gRPC では、HTTP/2 を介した軽量で高性能なリモートプロシージャコール (RPC) を通じてサービス間の通信が実現されます。サービス間の効率的で低遅延の通信が促進されるので、マイクロサービスアーキテクチャに最適です。
gRPC は、双方向ストリーミング、フロー制御、さまざまなプログラミング言語用の自動コード生成などの機能を提供します。これは、高性能、効率的な通信、リアルタイムのデータストリーミングが必要なシナリオに最適です。アプリケーションが大量のデータを処理する必要がある場合や、クライアントとサーバー間の低レイテンシー通信が必要な場合は、gRPC を選択することを検討してください。ただし、gRPC は REST に比べて習得が難しい場合があります。例えば、gRPC は protobuf シリアル化形式に依存するので、デベロッパーはデータ構造とサービスメソッドを .proto
ファイルで定義する必要があります。
gRPC API エンドポイントの前に CloudFront をデプロイすることには 2 つのメリットがあります。
まず、クライアントアプリケーションと API 実装の間のレイテンシーを短縮できます。CloudFront は、最も近いエッジへのインテリジェントなルーティング機能を備えた 600 以上のエッジロケーションで構成されたグローバルネットワークを提供します。エッジロケーションは TLS ターミネーションに加えて、静的コンテンツのキャッシュ (オプション) を提供します。CloudFront は、フルマネージド型、低レイテンシー、高帯域幅のプライベート AWS ネットワークを介してクライアントアプリケーションのリクエストを gRPC オリジンに転送します。
次に、トラフィックの暗号化、AWS Web アプリケーションファイアウォールによる HTTP ヘッダーの検証、分散型サービス拒否 (DDoS) 攻撃に対する AWS Shield Standard 保護など、エッジロケーションにデプロイされた追加のセキュリティサービスをアプリケーションで利用できるというメリットがあります。
実際の動作を見てみましょう
このデモを開始するために、公式の gRPC コードリポジトリにある gRPC route_guide デモを使用します。デプロイを簡単にするために、このサンプルアプリケーションをコンテナにデプロイします (他のデプロイオプションもサポートされています)。
この Dockerfile
を使用します。
FROM python:3.7
RUN pip install protobuf grpcio
COPY ./grpc/examples/python/route_guide .
CMD python route_guide_server.py
EXPOSE 50051
また、 AWS Copilot コマンドラインを使用して Amazon Elastic Container Service (Amazon ECS) にコンテナをデプロイします。Copilot コマンドを実行すると、コンテナーのビルドとデプロイに必要な情報を収集するように求められます。次に、ECS クラスター、ECS サービス、ECS タスクが自動的に作成されます。また、TLS 証明書とロードバランサーも作成されます。ロードバランサーリスナーエンドポイントの DNS 名を使用するように 122 行目を変更して、クライアントアプリケーションをテストします。また、ロードバランサーがアプリケーションに HTTPS エンドポイントを提供するので、grpc.insecure_channel
の代わりに grpc.secure_channel
を使用するようにクライアントアプリケーションのコードを変更します。
API が正しくデプロイされて動作していることが確認できたら、CloudFront を設定します。
まず、AWS マネジメントコンソールの CloudFront セクションで [ディストリビューションを作成する] を選択します。
[オリジン] で、オリジンドメインとして gRPC エンドポイントの DNS 名を入力します。[プロトコル] として [HTTPS のみ] を有効にして、HTTPS ポートはそのまま (443) にしておきます。次に、ディストリビューションの [名前] を選択します。
[ビューワー] で、[ビューワープロトコルポリシー] として [HTTPS のみ] を選択します。次に、[許可された HTTP メソッド] として [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE] を選択します。[Allow gRPC requests over HTTP/2] で [有効化] を選択します。
[キャッシュキーとオリジンリクエスト] で、[オリジンリクエストポリシー] として [AllViewer] を選択します。
デフォルトのキャッシュポリシーは [CacheOptimized] ですが、gRPC はキャッシュ可能な API トラフィックではありません。そのため、[キャッシュポリシー] として [CachingDisabled] を選択します。
AWS WAF は、可用性に影響する可能性、セキュリティを侵害する可能性、リソースを過剰に消費する可能性のある一般的なウェブエクスプロイトやボットからユーザーを保護するのに役立ちます。gRPC トラフィックの場合、AWS WAF を使用して、リクエストの HTTP ヘッダーを検査し、アクセスコントロールを適用することができます。protobuf 形式のリクエスト本文は検査されません。
このデモでは、AWS WAF を使用しません。[ウェブアプリケーションファイアウォール (WAF)] で、[Do not enable security protections] を選択します。
他のすべてのオプションはデフォルト値のままにします。HTTP/2 のサポートはデフォルトで選択されています。これは gRPC に必要なので無効にしないでください。
最後に、[ディストリビューションを作成] を選択します。
通常の設定に加えて gRPC を有効にするスイッチは 1 つだけです。HTTP/2 と HTTP POST が有効な状態でオンにすると、CloudFront は gRPC クライアントトラフィックを検出し、それを gRPC オリジンに転送します。
数分後、ディストリビューションの準備が完了します。CloudFront ディストリビューションのエンドポイント URL をコピーして貼り付けます。クライアント側のアプリケーションを変更して、以前に作成したロードバランサーの代わりに CloudFront をポイントします。
再度テストすると、アプリケーションが動作します。
料金と利用可能なリージョン
gRPC オリジンは、追加料金なしで 600 以上のすべての CloudFront エッジロケーションで利用できます。通常のリクエストとデータ転送の料金が適用されます。
今すぐ、CloudFront オリジンで gRPC エンドポイントをポイントしてください。
原文はこちらです。