NGINXをAPIゲートウェイとして導入する：第3回 gRPCサービスの公開

Liam Crillyプロダクトマネジメント担当シニアディレクター

これは、NGINX Open SourceとNGINX PlusをAPIゲートウェイとして導入する方法を紹介するブログシリーズの第3回です。

• パート1では、RESTfulなHTTPベースのAPI向けAPIゲートウェイとしてNGINX Open SourceとNGINX Plusを使用する複数のユースケースについて、詳細な手順を説明します。
• パート2では、これらのユースケースを拡張し、本番環境のバックエンドAPIサービスを保護し、セキュリティを確保するために適用できるさまざまな保護対策について説明します。
• この投稿では、NGINX Open SourceとNGINX PlusをgRPCサービスのAPIゲートウェイとして導入する方法について説明します。2018年に初めて公開されたこの投稿は、NGINX Plus Release 23で導入されたネイティブgRPCヘルスチェックプロトコルのサポートを活用する内容に更新されています。詳しくは「ヘルスチェックの実装」をご覧ください。

注： 特に記載がない限り、この記事のすべての情報はNGINX PlusとNGINX Open Sourceの両方に適用されます。読みやすくするため、以降では両方のバージョンに該当する内容について、単に「NGINX」と表記します。

近年、マイクロサービスアプリケーションアーキテクチャの概念とメリットについては多くの情報が公開されており、特に詳しく取り上げているのがNGINXブログです。マイクロサービスアプリケーションの中核を成すのはHTTP APIです。本シリーズの最初の2つの記事では、架空のREST APIを使用して、この形式のアプリケーションにNGINXがどのように対応するかを説明します。

JSONメッセージ形式を使用するREST APIは、最新のアプリケーションで広く普及していますが、あらゆる状況や組織に適したアプローチとは限りません。主な課題は次のとおりです。

• ドキュメント標準 – 開発者の規律が十分でない場合や、ドキュメント作成要件が義務付けられていない場合、正確な定義を欠くREST APIが増えてしまいがちです。Open API SpecificationはREST API向けの汎用インターフェース記述言語として普及していますが、その使用は任意であり、開発組織内での強力なガバナンスが必要です。
• イベントと長時間接続 – REST APIではHTTPをトランスポートとして使用するため、ほぼすべてのAPI呼び出しがリクエスト／レスポンス型になります。アプリケーションでサーバー生成イベントが必要な場合は、HTTPロングポーリングやWebSocketなどのソリューションが役立ちますが、最終的には別途、連携するAPIを構築する必要があります。
• 複雑なトランザクション – REST APIは、それぞれがURIで表される一意のリソースという概念に基づいて構築されています。アプリケーションイベントで複数のリソースを更新する必要がある場合、非効率な複数回のAPI呼び出しを行うか、RESTの基本原則に反してバックエンドに複雑なトランザクションを実装する必要があります。

近年、分散アプリケーション、特にマイクロサービスアプリケーションを構築するための代替アプローチとして、gRPCが登場しました。Googleで開発されたgRPCは、2015年にオープンソース化され、現在はCloud Native Computing Foundationのプロジェクトとなっています。特筆すべき点として、gRPCはHTTP/2をトランスポートメカニズムとして使用し、そのバイナリデータ形式と多重化ストリーミング機能を活用しています。

gRPCの主なメリットは次のとおりです。

• 密接に統合されたインターフェース定義言語（Protocol Buffers）
• ストリーミングデータをネイティブにサポート（双方向）
• 効率的なバイナリデータ形式
• 多くのプログラミング言語に対応したコードの自動生成により、相互運用性の問題を生じさせることなく、真の多言語開発環境を実現

gRPC Gatewayの定義

このシリーズの最初の2つの記事では、複数のAPIを単一のエントリポイント（例：https://api.example.com）経由で提供する方法について説明しました。gRPCトラフィックのデフォルトの動作と特性を踏まえると、NGINXをgRPCゲートウェイとして導入する場合にも、同じアプローチが適しています。HTTPトラフィックとgRPCトラフィックで同じホスト名とポートを共有することも可能ですが、両者を分離することが望ましい理由はいくつかあります。

• RESTアプリケーションとgRPCアプリケーションのAPIクライアントでは、想定されるエラーレスポンスの形式が異なります
• アクセスログの関連フィールドは、RESTとgRPCで異なります
• gRPCはレガシーWebブラウザを扱わないため、より厳格なTLSポリシーを適用できます

この分離を実現するため、gRPCゲートウェイの設定を、server{}ブロックとして、/etc/nginx/conf.dディレクトリにあるメインのgRPC設定ファイルgrpc_gateway.confに記述します。

コード例を読み込み中…

まず、gRPCトラフィックのアクセスログに記録するエントリの形式を定義します（1～4行目）。この例では、各リクエストから特に重要なデータを取得するためにJSON形式を使用します。たとえば、すべてのgRPCリクエストでPOSTが使用されるため、HTTPメソッドは含めません。また、HTTPステータスコードとともにgRPCステータスコードも記録します。ただし、gRPCステータスコードが生成される方法は複数あります。通常、grpc-statusはバックエンドからHTTP/2トレーラーとして返されますが、一部のエラー条件では、バックエンドまたはNGINX自体からHTTP/2ヘッダーとして返される場合があります。アクセスログを簡素化するため、mapブロック（6～9行目）を使用して新しい変数$grpc_statusを評価し、生成元にかかわらずgRPCステータスを取得します。

この設定には、平文（ポート50051）とTLSで保護された（ポート443）トラフィックの両方をテストできるように、2つの「listen」ディレクティブ（12行目と13行目）が含まれています。「http2」パラメーターは、HTTP/2接続を受け入れるようにNGINXを設定します。これは「ssl」パラメーターとは独立している点に注意してください。また、ポート50051はgRPCの平文通信で慣例的に使用されるポートですが、本番環境での使用には適していません。

TLS構成は一般的なものですが、例外としてssl_protocolsディレクティブ（23行目）では、許容される最も低いバージョンのプロトコルとしてTLS 1.2を指定しています。HTTP/2仕様ではTLS 1.2（またはそれ以降）の使用が必須とされており、すべてのクライアントがTLSのServer Name Indication（SNI）拡張をサポートすることが保証されます。そのため、gRPCゲートウェイは、他のserver{}ブロックで定義された仮想サーバーとポート443を共有できます。

サンプルgRPCサービスの実行

NGINXのgRPC機能を検証するため、複数のgRPCサービスをデプロイし、gRPCゲートウェイの主要コンポーネントを再現したシンプルなテスト環境を使用します。使用するのは、gRPC公式ガイドに掲載されている2つのサンプルアプリケーション、helloworld（Goで記述）とRouteGuide（Pythonで記述）です。RouteGuideアプリケーションには、4種類すべてのgRPCサービスメソッドが含まれているため、特に有用です。

• シンプルRPC（単一のリクエストとレスポンス）
• レスポンスストリーミングRPC
• リクエストストリーミングRPC
• 双方向ストリーミングRPC

両方のgRPCサービスは、NGINXホスト上にDockerコンテナとしてインストールされています。テスト環境の構築手順について詳しくは、「付録」を参照してください。

NGINXにRouteGuideサービスとhelloworldサービス、および利用可能なコンテナのアドレスを設定します。

コード例を読み込み中…

各gRPCサービス（40～45行目および47～51行目）に「upstream」ブロックを追加し、gRPCサーバーコードを実行している各コンテナのアドレスを設定します。

gRPCリクエストのルーティング

NGINXがgRPCの標準的な平文通信ポート（50051）でリッスンしている状態で、クライアントリクエストが適切なバックエンドサービスに到達するよう、設定にルーティング情報を追加します。ただし、その前に、gRPCメソッド呼び出しがHTTP/2リクエストとしてどのように表現されるかを理解する必要があります。次の図は、RouteGuideサービスのroute_guide.protoファイルを簡略化したもので、NGINXから見たパッケージ、サービス、RPCメソッドによるURIの構成を示しています。

したがって、HTTP/2リクエストに含まれる情報は、パッケージ名（ここでは「routeguide」または「helloworld」）と照合するだけで、ルーティングに使用できます。

コード例を読み込み中…

最初のlocationブロック（26行目）には修飾子がなく、プレフィックス一致が定義されているため、/routeguide.は、そのパッケージに対応する.protoファイルで定義されたすべてのサービスおよびRPCメソッドに一致します。そのため、grpc_passディレクティブ（27行目）は、RouteGuideクライアントからのすべてのリクエストをアップストリームグループrouteguide_serviceに渡します。この設定（および29行目と30行目にあるhelloworldサービス用の同様の設定）により、gRPCパッケージとそのバックエンドサービスを簡単にマッピングできます。

Notice that the argument to the grpc_passディレクティブの引数は、grpc://スキームで始まることに注意してください。このスキームでは、平文のgRPC接続を使用してリクエストをプロキシします。バックエンドでTLSが構成されている場合は、grpcs://スキームを使用し、エンドツーエンド暗号化によってgRPC接続を保護できます。

RouteGuideクライアントを実行した後、ログファイルのエントリを確認することで、ルーティングの動作を検証できます。ここでは、RouteChat RPCメソッドがポート 10002で稼働しているコンテナにルーティングされたことを確認できます。

$ python route_guide_client.py...
$ tail -1 /var/log/nginx/grpc_log.json | jq
{
  "timestamp": "2021-01-20T12:17:56+01:00",
  "client": "127.0.0.1",
  "uri": "/routeguide.RouteGuide/RouteChat",
  "http-status": 200,
  "grpc-status": 0,
  "upstream": "127.0.0.1:10002",
  "rx-bytes": 161,
  "tx-bytes": 212
}

精密なルーティング

上記のとおり、複数のgRPCサービスを異なるバックエンドにルーティングする処理はシンプルかつ効率的で、必要な設定もごく数行です。ただし、本番環境ではルーティング要件がより複雑になり、URI内の他の要素（gRPCサービスや個々のRPCメソッド）に基づくルーティングが必要になる場合があります。

次の設定スニペットは前の例を拡張し、双方向ストリーミングRPCメソッド「RouteChat」を一方のバックエンドに、その他すべての「RouteGuide」メソッドを別のバックエンドにルーティングします。

コード例を読み込み中…

2つ目の「location」ディレクティブ（7行目）では、「=」（等号）修飾子を使用して、これが「RouteChat」RPCメソッドのURIとの完全一致であることを示します。完全一致は前方一致より先に処理されるため、「location」ブロックはほかに「RouteChat」のURIについて評価されません。

エラーへの対応

gRPCのエラーは、従来のHTTPトラフィックのエラーとは多少異なります。クライアントは、エラー状態がgRPCレスポンスとして表現されることを想定しています。そのため、NGINXをgRPCゲートウェイとして構成する場合、NGINXのデフォルトのエラーページ一式（HTML形式）は適していません。この問題には、gRPCクライアント向けのカスタムエラーレスポンス一式を指定することで対処します。

コード例を読み込み中…

gRPCエラーレスポンスの完全なセットは比較的長く、ほとんど変更されない設定であるため、別のファイル「errors.grpc_conf」に保存し、includeディレクティブ（34行目）を使用して参照します。HTTP/RESTクライアントとは異なり、gRPCクライアントアプリケーションは、さまざまなHTTPステータスコードを処理することを想定していません。gRPCドキュメントでは、クライアントが常に適切なレスポンスを受信できるように、NGINXなどの中間プロキシがHTTPエラーコードをgRPCステータスコードに変換する方法を規定しています。このマッピングには、error_pageディレクティブを使用します。

コード例を読み込み中…

標準HTTPステータスコードはそれぞれ、@プレフィックスを使用して名前付きロケーションに渡され、gRPC準拠のレスポンスが生成されます。たとえば、HTTP 404レスポンスは、ファイル内で後ほど定義される@grpc_unimplementedロケーションに内部リダイレクトされます。

コード例を読み込み中…

The @grpc_unimplementedという名前付きロケーションは、NGINXの内部処理でのみ使用できます。ルーティング可能なURIが存在しないため、クライアントから直接リクエストすることはできません。このロケーションでは、必須のgRPCヘッダーを設定し、レスポンス本文を含めずにHTTPステータスコード204（No Content）で送信することで、gRPCレスポンスを構成します。

We can use the curl(1)コマンドを使用すると、存在しないgRPCメソッドをリクエストする不正な動作のgRPCクライアントを再現できます。ただし、プロトコルバッファはバイナリデータ形式を使用するため、curlは通常、gRPCテストクライアントには適していません。コマンドラインでgRPCをテストする場合は、grpc_cliの使用をご検討ください。

$ curl -i --http2 -H "Content-Type: application/grpc" -H "TE: trailers" -X POST https://grpc.example.com/does.Not/ExistHTTP/2 204 
server: nginx/1.19.5
date: Wed, 20 Jan 2021 15:03:41 GMT
grpc-status: 12
grpc-message: unimplemented

上記の「grpc_errors.conf」ファイルには、タイムアウトやクライアント証明書エラーなど、NGINXが生成する可能性のあるその他のエラーレスポンスについても、HTTPからgRPCへのステータスコードのマッピングが含まれています。

gRPCメタデータによるクライアント認証

gRPCの「メタデータ」を使用すると、クライアントは追加情報をRPCメソッド呼び出しとともに送信できます。そのデータをProtocol Buffersの仕様（ .protoファイル）に含める必要はありません。メタデータはキーと値のペアからなる単純なリストで、各ペアは個別のHTTP/2ヘッダーとして送信されます。そのため、NGINXから簡単にアクセスできます。

メタデータには多くのユースケースがありますが、gRPC APIゲートウェイではクライアント認証が最も一般的です。次の設定スニペットは、NGINX PlusがgRPCメタデータを使用してJWT認証を実行する方法を示しています（JWT認証はNGINX Plusのみで利用できます）。この例では、JWTはauth-tokenメタデータで送信されます。

コード例を読み込み中…

すべてのHTTPリクエストヘッダーは、NGINX Plusで$http_headerという変数として使用できます。ヘッダー名のハイフン（-）は変数名ではアンダースコア（_）に変換されるため、JWTは$http_auth_tokenとして使用できます（2行目）。

既存のHTTP/REST APIなどで認証にAPIキーを使用している場合、そのAPIキーをgRPCメタデータに含め、NGINXで検証することもできます。APIキー認証<.htmla>の設定については、このブログシリーズのパート1で紹介しています。

ヘルスチェックの実装

複数のバックエンドにトラフィックを負荷分散する場合、停止中または何らかの理由で利用できないバックエンドにリクエストを送信しないことが重要です。NGINX Plusでは、アクティブヘルスチェックを使用して、バックエンドに帯域外リクエストをプロアクティブに送信できます。バックエンドがヘルスチェックに対して想定どおりに応答しない場合は、負荷分散の対象から除外します。これにより、クライアントリクエストがサービス停止中のバックエンドに到達することを防ぎます。

以下の構成スニペットでは、RouteGuideおよびhelloworld gRPCサービスのアクティブヘルスチェックを有効にしています。関連する構成を明確に示すため、前のセクションで使用したgrpc_gateway.confファイルに含まれる一部のディレクティブは省略しています。

コード例を読み込み中…

各ルートに対して、health_checkディレクティブも指定するようになりました（17行目と21行目）。type=grpc引数の指定に従い、NGINX PlusはgRPCヘルスチェックプロトコルを使用して、アップストリームグループ内の各サーバーにヘルスチェックを送信します。ただし、ここで使用するシンプルなgRPCサービスはgRPCヘルスチェックプロトコルを実装していないため、「未実装」を意味するステータスコード（grpc_status=12）が返されることを想定しています。このコードが返されれば、稼働中のgRPCサービスと通信できていることを確認するには十分です。

この構成により、gRPCクライアントで遅延やタイムアウトが発生することなく、任意のバックエンドコンテナを停止できます。アクティブヘルスチェックはNGINX Plus独自の機能です。詳しくは、ブログの「gRPCヘルスチェック」をご覧ください。

レート制限およびその他のAPIゲートウェイ制御の適用

The sample configuration in grpc_gateway.confのサンプル構成は、TLS向けに若干変更すれば本番環境で使用できます。パッケージ、サービス、またはRPCメソッドに基づいてgRPCリクエストをルーティングできるため、既存のNGINX機能をHTTP/REST APIや通常のWebトラフィックの場合とまったく同じようにgRPCトラフィックにも適用できます。いずれの場合も、該当するlocationブロックに、レート制限や帯域幅制御などの設定を追加できます。

まとめ

NGINX Open SourceとNGINX PlusをAPIゲートウェイとして導入する方法を取り上げたシリーズの第3回（最終回）となる本ブログ記事では、マイクロサービスアプリケーションを構築するためのクラウドネイティブ技術であるgRPCに焦点を当てました。NGINXがHTTP/REST APIと同様にgRPCアプリケーションも効果的に配信できること、また、どちらの形式のAPIも多目的APIゲートウェイとしてのNGINXを通じて公開できることを紹介しました。

Instructions for setting up the test environment used in this blog post are in the appendix below, and you can download all of the files from our GitHub Gist repo.

このシリーズの他のブログ記事もご覧ください：

• パート1では、HTTPベースのAPIゲートウェイに不可欠ないくつかのユースケースに合わせてNGINXを構成する方法を説明します。
• パート 2では、悪意のあるクライアントや不適切な動作をするクライアントからバックエンドサービスを保護するための、より高度なユースケースについて説明します。

NGINX PlusをAPIゲートウェイとしてお試しいただくには、今すぐ30日間の無料トライアルを開始するか、ユースケースについてお問い合わせください。トライアル期間中は、GitHub Gistリポジトリにある構成ファイル一式をご利用ください。

付録：テスト環境のセットアップ

以下の手順では、テスト環境を分離し、同じ環境を再現できるように、仮想マシン上にインストールします。ただし、物理的な「ベアメタル」サーバーにもインストールできます。

テスト環境を簡素化するため、DockerコンテナでgRPCサービスを実行します。これにより、テスト環境に複数のホストを用意する必要がなくなる一方で、本番環境と同様に、NGINXからネットワーク経由でプロキシ接続を確立できます。

Dockerを使用すると、コードを変更することなく、各gRPCサービスの複数のインスタンスをそれぞれ異なるポートで実行することもできます。各gRPCサービスはコンテナ内のポート50051でリッスンし、このポートは仮想マシン上の一意のlocalhostポートにマッピングされます。これによりポート50051が空き、NGINXのリッスンポートとして使用できるようになります。そのため、テストクライアントが事前設定済みのポート50051を使用して接続すると、NGINXに到達します。

NGINX Open SourceまたはNGINX Plusのインストール

1. インストールします。NGINX Open SourceまたはNGINX PlusをNGINX Plus管理者ガイドの手順に従って
2. 次のファイルをGitHub Gistリポジトリから/etc/nginx/conf.dにコピーします。注：TLSを使用しない場合は、ssl_*ディレクティブをgrpc_gateway.conf内でコメントアウトしてください。
   • grpc_gateway.conf
   • errors.grpc_conf
3. NGINX Open SourceまたはNGINX Plusを起動します。

$ sudo nginx

Dockerのインストール

DebianおよびUbuntuでは、次のコマンドを実行します。

$ sudo apt-get install docker.io

CentOS、RHEL、Oracle Linuxでは、次のコマンドを実行します。

$ sudo yum install docker

RouteGuideサービスコンテナのインストール

1. 次のDockerfileからRouteGuideコンテナ用のDockerイメージをビルドします。

   コード例を読み込み中…

   ビルド前にDockerfileをローカルのサブディレクトリにコピーするか、DockerfileのGistのURLをdocker buildコマンドの引数として指定できます。

$ sudo docker build -t routeguide https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/routeguide.Dockerfile

1. イメージのダウンロードとビルドには数分かかる場合があります。メッセージ「Successfully built」と16進数文字列（イメージID）が表示されたら、ビルドは完了です。
2. 次のコマンドを実行して、イメージがビルドされたことを確認します。docker images.

$ sudo docker imagesREPOSITORY     TAG          IMAGE ID          CREATED         SIZE
routeguide     latest       63058a1cf8ca      1 minute ago    1.31 GB
python         latest       825141134528      9 days ago      923 MB

1. RouteGuideコンテナを起動します。

$ sudo docker run --name rg1 -p 10001:50051 -d routeguide$ sudo docker run --name rg2 -p 10002:50051 -d routeguide
$ sudo docker run --name rg3 -p 10003:50051 -d routeguide

1. 各コマンドが正常に実行されると、実行中のコンテナを表す長い16進数文字列が表示されます。
2. 次のコマンドを実行して、3つのコンテナがすべて稼働していることを確認します。docker ps。（サンプル出力は読みやすいように複数行に分割されています。）

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ...
d0cdaaeddf0f  routeguide  "python route_g..."  Up 2 seconds  ...
c04996ca3469  routeguide  "python route_g..."  Up 9 seconds  ...
2170ddb62898  routeguide  "python route_g..."  Up 1 minute   ...

      ... PORTS                     NAMES
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

1. 出力の「PORTS」列には、各コンテナでそれぞれ異なるローカルポートがコンテナ内のポート 50051にマッピングされていることが示されます。

helloworldサービスコンテナのインストール

1. 以下のDockerfileからhelloworldコンテナ用のDockerイメージをビルドします。

   コード例を読み込み中…

   ビルド前にDockerfileをローカルのサブディレクトリにコピーするか、DockerfileのGistのURLをdocker buildコマンドの引数として指定します。

$ sudo docker build -t helloworld https://gist.githubusercontent.com/nginx-gists/87ed942d4ee9f7e7ebb2ccf757ed90be/raw/ce090f92f3bbcb5a94bbf8ded4d597cd47b43cbe/helloworld.Dockerfile

1. イメージのダウンロードとビルドには数分かかる場合があります。メッセージ「Successfully built」と16進数文字列（イメージID）が表示されると、ビルドは完了です。
2. 次のコマンドを実行して、イメージがビルドされたことを確認します。docker images。

$ sudo docker images
REPOSITORY     TAG          IMAGE ID          CREATED           SIZE
helloworld     latest       e5832dc0884a      10 seconds ago    926MB
routeguide     latest       170761fa3f03      4 minutes ago     1.31GB
python         latest       825141134528      9 days ago        923MB
golang         latest       d0e7a411e3da      3 weeks ago       794MB

1. helloworldコンテナを起動します。

$ sudo docker run --name hw1 -p 20001:50051 -d helloworld$ sudo docker run --name hw2 -p 20002:50051 -d helloworld

1. 各コマンドが正常に実行されると、実行中のコンテナを表す長い16進数文字列が表示されます。
2. 次のコマンドを実行して、2つのhelloworldコンテナが稼働していることを確認します。docker ps.

$ sudo docker psCONTAINER ID  IMAGE       COMMAND              STATUS        ... 
e0d204ae860a  helloworld  "go run greeter..."  Up 5 seconds  ... 
66f21d89be78  helloworld  "go run greeter..."  Up 9 seconds  ... 
d0cdaaeddf0f  routeguide  "python route_g..."  Up 4 minutes  ... 
c04996ca3469  routeguide  "python route_g..."  Up 4 minutes  ... 
2170ddb62898  routeguide  "python route_g..."  Up 5 minutes  ... 

      ... PORTS                     NAMES
      ... 0.0.0.0:20002->50051/tcp  hw2
      ... 0.0.0.0:20001->50051/tcp  hw1
      ... 0.0.0.0:10003->50051/tcp  rg3
      ... 0.0.0.0:10002->50051/tcp  rg2
      ... 0.0.0.0:10001->50051/tcp  rg1

gRPCクライアントアプリケーションのインストール

1. プログラミング言語の前提条件をインストールします。一部はテスト環境にすでにインストールされている場合があります。なお、python-pipを使用するには、EPELリポジトリを有効にする必要があります（必要に応じて、最初にsudo yum install epel-releaseを実行してください）。
   • UbuntuおよびDebianでは、次のコマンドを実行します。

$ sudo apt-get install golang-go python3 python-pip git

• CentOS、RHEL、Oracle Linuxでは、次を実行します：

$ sudo yum install golang python python-pip git

1. helloworldアプリケーションをダウンロードします：

$ go get google.golang.org/grpc

1. RouteGuideアプリケーションをダウンロードします：

$ git clone -b v1.14.1 https://github.com/grpc/grpc
$ pip install grpcio-tools

セットアップのテスト

1. helloworldクライアントを実行します：

$ go run go/src/google.golang.org/grpc/examples/helloworld/greeter_client/main.go

1. RouteGuideクライアントを実行します：

$ cd grpc/examples/python/route_guide
$ python route_guide_client.py

1. NGINXログを確認し、テスト環境が稼働していることを確認します：

$ tail /var/log/nginx/grpc_log.json

著者について

Liam Crillyプロダクトマネジメント担当シニアディレクター

Liam Crillyのその他のブログ記事