4章gRPCによるリクエスト処理
プロジェクトとプロトコルバッファを設定し、ログライブラリを作成しました。現在、私たちのライブラリは、一度に一人が1台のコンピュータ上でしか使えません。さらに、その人はライブラリのAPIを学び、私たちのコードを実行し、ログを自分のディスクに保存しなければなりません。ほとんどの人はそのようなことはしないでしょうから、私たちのライブラリの利用者は限られます。多くの人にアピールするには、ライブラリをウェブサービス化する必要があります。1台のコンピュータ上で動作するプログラムに比べて、ネットワークサービスには三つの大きな利点があります。
- 可用性と拡張性のために、複数のコンピュータで実行できます。
- 複数の人が同じデータを扱えます。
- 人々にとって使いやすいアクセス可能なインタフェースを提供します。
このような利点を得るためにサービスを作りたい状況としては、フロントエンドが利用する公開APIの提供、社内サービス基盤ツールの構築、自分のビジネスを構築するためのサービスの構築などが挙げられます(ライブラリだけを利用するためにお金を払う人はほとんどいません)。
この章では、私たちのライブラリを使って、複数の人が同じデータを扱い、複数のコンピュータで動作するサービスを作成します。この章では、クラスタのサポートはまだ行いません。「8章 合意形成によるサービス連携」で行います。私が、分散サービスでリクエストを提供するために見つけた最良のツールは、GoogleのgRPCです。
4.1 gRPCとは何か
以前、分散サービスを構築したとき、私を悩ませたのは、クライアントとサーバ間の互換性の維持とパフォーマンスの維持でした。
私は、クライアントとサーバで常に互換性があることを保証したかったのです。つまり、クライアントはサーバが理解できるリクエストを送信し、その逆にサーバのレスポンスも理解できることを保証したかったのです。互換性のない変更をサーバに行う際には、古いクライアントも継続して動作できるようにする必要があったので、APIをバージョン管理することで実現しました。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access