ほとんどのソフトウェアアプリケーションは、いくつかの理由で他のコードと接続できる必要があります。これは、統合から新機能の追加まで、何でもありです。ソフトウェアが他のアプリケーションとリンクできるように、また他のプログラムとの統合を確実にするために、開発者はAPIを使用します。これが、ほとんどのソフトウェアにApplication Programming Interfaceが必要な理由です。APIは、システム間の橋渡しの役割を果たすことで、個人がさまざまなWebサービスにアクセスすることを可能にします。したがって、プロジェクトにAPIを提供するために適切な技術を選ぶことが重要である。
アプリケーションやプラットフォームをユーザーと共有したい組織は、APIを使用する必要がある。APIを開発し、アプリケーションに最適なものにするために微調整する方法はたくさんある。プログラマがAPIを設計するために使用している最新の方法の1つがgRPCです。ここでは、gRPCとは何か、またその長所と短所について見ていきましょう。
gRPC とは？
gRPCはGoogle Remote Procedure Call の略です。gRPC はオープンソースの RPC フレームワークで、スケーラブルで迅速な API を作成するために使用されます。gRPC は、Google、IBM、Netflix などのトップクラスの技術企業で採用されています。gRPCフレームワークは、HTTP/2、プロトコルバッファなどの最先端技術スタックに依存し、最適なAPI保護、高性能なリモートプロシージャコール、およびスケーラビリティを実現しています。
RPCsとは何ですか？
RPC とREST（ ）は、歴史的にAPIを構築するための2つの別個のアプローチであった。さらに、Representational State TransferSOAPや GraphQL のようなプロトコルもこの目的のために使用されています。リモートプロシージャコールは、異なるデバイス上で実行されるかもしれないが、ローカルで実行されるかのようにソフトウェアを書くことができます。
APIを設計するためのフレームワークとしては、最も慣用的なものです。RPC は、やり取りがシンプルで内容が軽量なため、API を作成するための生産的な手法です。gRPC サービスもこの通信アーキテクチャを模倣しています。RPC はIDL -Interface Definition Language でデータ型と呼び出されるメソッドを契約しています。RPCから採用されたgRPCサービスは、近年、非常に人気があります。
なぜgRPCサービスが開発されたのでしょうか。
多くの企業が統合のためのチャネルを開放するにつれ、そのようなソフトウェアをリンクすることが困難になってきています。RPC APIは統合するのが難しく、配布するにも内部仕様が開示される可能性があるためリスクが高い。また、APIは多くのプログラミング言語で開発され、その基盤となるフレームワークと密接に結びついています。
この問題を解決し、APIへのアクセス性を高めたのが、2000年に登場したREST APIだ。具体的には、GET 、PUT 、 POST などの標準的な HTTP 技術を使って、アセットを介して間接的に情報を取得する一貫した方法をユーザーに提供しました。RPC とREST API の主な違いは、RPC では、プロセスに対応しているが、様々なシステムにおけるプロセスがどのようなものでありうるかを予測することは容易ではない。
REST API は、多くのアプリケーションを扱うための拡張フォーマットを提供しながらも、大量のメタデータを生成するため、ストレートで軽量のRPC を完全に置き換えることはできませんでした。その結果、最終的にFacebookのGraphQL 、GoogleのgRPCサービスが登場することになったのです。
Googleは2015年に、様々な手法で作られた多数のマイクロサービスアーキテクチャを接続するためのRPCフレームワークの追加としてgRPCを構築しました。 gRPCはもともとGoogleのコアインフラと密接に関係していましたが、最終的にはオープンソース化され、一般ユーザーによる利用も標準化されました。
gRPCのコンセプトの概要
JSONやXMLよりも高性能で、APIの整合性が高いという最先端技術の活用が、gRPCの誕生と普及に寄与しています。gRPCの概念として知っておくべきものをいくつか紹介します。
プロトコル・バッファ
Protobuf として知られるプロトコル・バッファは、アプリケーションの定義とクライアント・ライブラリのコード生成を自動的に行うことを容易にするシリアライズまたはデシリアライズの標準です。最新版であるproto3 は、よりシンプルに使用でき、gRPC の最新機能を提供します。
.Proto ファイルは、gRPC サービスと、gRPC クライアントとサーバメッセージ間の通信を可能にします。.proto ファイルは、実行時にProtobuf コンパイラ -protoc によってメモリにロードされます。このコンパイラは、バイナリデータをシリアライズ、デシリアライズするためにメモリ内構造を採用した gRPC クライアントと gRPC サーバアプリケーションを構築します。各通信は、gRPC のコード生成に続いて、ユーザとリ モートサービス間で送受信されます。
データがバイナリ形式に変換され、暗号化された信号が小さくなるため、Protobuf による解析は gRPC のCPU の使用電力が少なくなります。そのため、携帯電話のようなCPU の弱いコンピュータでも、gRPC を使えばより速くメッセージが送信されます。
HTTP/2
gRPC サービスは、HTTP/1.1 の制限の少ないバージョンである HTTP/2 で構築されています。古い HTTP プロトコルでも動作しますが、HTTP/2 は gRPC のためにいくつかの高度な機能を備えています。これにはバイナリフレームレイヤーが含まれ、HTTP/2の各クエリと返信をより小さなメッセージに分割し、バイナリ形式でフレーム化することでメッセージの配信を改善します。さらに、gRPCは、クライアントとgRPCサーバーからの双方向全二重ストリーミングによる複数のリクエストとレスポンスをサポートします。
HTTP/2は、飛行中のパケットをバッファリングするために必要なRAM を正確に制御することができるフロー制御方式を備えています。また、gRPCサービスのヘッダー圧縮も可能です。HTTP/2 では、ヘッダも含めてすべてが送信前に暗号化され、高性能なリモートプロシージャコールを提供します。gRPC は HTTP/2 で非同期と同期の両方の処理を提供し、さまざまな対話型およびストリーム型の RPC の実行を可能にします。
これらのHTTP/2の特徴を生かし、gRPCサービスはより少ないリソースで利用できるため、クラウドベースアプリケーションとgRPCサービス間の応答時間の短縮や、モバイルデバイスで動作するgRPCクライアントのバッテリーライフの延長につながります。
ストリーミング
gRPC がサポートする重要なアイデアは、単一のリクエスト内で複数のプロセスを実行できるストリーミングです。gRPC は HTTP/2 の多重化機能によってこれを実現し、1 つのTCP -Transmission Control Protocol - 接続で複数の応答またはリクエストを同時に送信または受信することが可能になります。主なストリーミング形式は、サーバストリーミング RPC、クライアントストリーミングRPCs、および双方向ストリーミングRPCs です。
チャンネル
HTTP/2ストリームが1つのリクエスト接続で多数の同時ストリームを許可するのとは対照的に、gRPCのチャンネルは複数のリクエストにまたがる複数の連続したストリームをサポートします。チャネルは、クライアントスタブを構築し、特定の IP とポートにある gRPC サーバにリンクするメカニズムを提供するために採用されます。
gRPCアーキテクチャ
gRPC アーキテクチャは gRPC クライアントと gRPC サーバから構成されます。全ての gRPC クライアントサービスはスタブまたは自動生成されたファイルを含んでおり、これはアクティブなリモートプロセスを含むインタフェースに類似しています。gRPCクライアントは、gRPCサーバのメッセージに転送される引数を含むスタブに対してローカルプロシージャコールを開始します。gRPCクライアントのスタブは、Protobuf マーシャリング手順を用いて引数をシリアライズした後、ローカルコンピュータ上のローカルクライアント時間ユニットにクエリを送信します。
OSはHTTP/2プロトコルを用いて遠方のサーバーコンピュータと通信する。サーバーのOSはメッセージを受け取り、サーバースタブプロセスを呼び出す。サーバースタブプロセスは、受信したパラメーターをデコードした後、Protobuf を使用して適切なオペレーションを呼び出す。その後、クライアントのトランスポート層は、サーバスタブから暗号化された応答を受信する。gRPCクライアントスタブが応答メッセージを受け取り、提供された引数をアンラップした後、実行は呼び出し元に戻されます。
gRPCの長所
gRPC は他の API 設計メカニズムに比べ、いくつかの利点があります。また、gRPC はRPC の構造を改良しています。以下は、gRPC サービスの最も顕著な利点です。
- 高性能なリモートプロシージャコール
Protobuf と HTTP/2 を使用することで、gRPC サービスは REST+JSON インタラクションの最大 10 倍のハイパフォーマンスと API プロテクションを提供します。サーバープッシュ、マルチプレクシング、ヘッダー圧縮の使用により、HTTP/2はgRPCサービスに高性能なランキングを提供します。多重化によって行頭の遅延をなくす一方で、サーバープッシュによって、HTTP/2は必要な前にサーバーからクライアントに資料をプッシュすることができます。メッセージは HTTP/2 によってより効果的に圧縮され、その結果 gRPC サービスでより速い読み込みを実現します。
- ストリーミング
ストリーミングgRPCサービスのサービス記述には、クライアントまたはサーバー側のストリーミングの原則が既に含まれています。その結果、gRPCクライアントやストリーミング・サービスの構築が非常に容易になります。
- コード生成
gRPC クライアントおよび gRPC サーバプロ グラムのコード生成は、gRPC web アプローチの 重要なコンポーネントです。.proto ファイルからのコード生成のために、gRPC モジュールは.protoc コンパイラを採用しています。Protobuf 形式は、gRPC のコード生成を通じて制御され、データ形式とアプリケーションエンドポイントの両方を定義するために使用されます。クライアント側のネットワークスタブやサーバ側のスケルトンを作成することができ、gRPCサービスにおける様々なサービスを利用したプログラムの設計に必要な時間を短縮することができます。
- 相互運用性
Java、Ruby.、C# など、数多くのシステムや プログラミング言語があります。 GoC# など、数多くのシステムとプログラミング言語が、gRPC のリソースとライブラリによってサポートされています。これらのプログラミング言語により、開発者は gRPC の完全なクロスプラットフォーム互換性を利用しながら、パフォーマン トなアプリケーションを作成することができます。これは、Protobuf バイナリ配線形式と、ほぼすべてのシステムに対する効果的なコード生成のおかげです。
- セキュリティ
gRPCは、サーバーとgRPCクライアント間のデータ暗号化および認証にSSL/TLSを採用することを推奨しており、TLSエンドツーエンド暗号化セッション上でHTTP/2を用いてAPIセキュリティを確保しています。
- 生産性とユーザビリティ
gRPC はRPC の完全な代替であるため、幅広いシステム や言語で問題なく動作します。また gRPC には優れたツールがあり、必要な定型 コードの多くは手動で生成されます。gRPC を使用することで大幅に時間を節約できるため、エンジニアはコア機能により集中することができます。
gRPC の短所
gRPCの欠点がいずれ解決されることを期待することはできますが、現在、その使用にはいくつかの問題があります。gRPCの短所としては、以下のようなものがあります。
- 成熟度の低さ
技術の発展は、採用の大きな障壁となり得ます。これは gRPC を使用する際にも明らかです。GraphQLgRPC の同業者の一つである、株式会社エヌ・ティ・ティ・ドコモは、StackOverflow で 14k 以上のクエリを持っていますが、gRPC は現在 4k を少し下回るだけです。gRPC コミュニティは、HTTP/2 やプロトコ ルバッファに対するプログラマの支援が Google 以 外にはあまりないため、ベストプラクティスや解 決策、成功例に関する知識に欠けています。しかし、gRPCコミュニティが拡大し、新しい開発者を引き込むにつれて、これは最終的に進化するでしょう。
- 限られたブラウザのサポート
現在のgRPC WebブラウザはHTTP/2フレームを処理できないため、ブラウザからgRPCサービスを効果的に呼び出すことができません。その結果、gRPCでプロキシを利用する必要がありますが、これにはいくつかの欠点があります。
- 人間には読めない
XML や JSON とは異なり、Protobuf ファイルはデータがバイナリ形式に圧縮されているため、人間が読むことはできません。開発者は、ペイロードの評価、トラブルシューティング、手動クエリの作成に、server reflection protocol や gRPC command prompt などの追加ツールを使用する必要があります。
- 深い学習曲線
RESTやGraphQLが主にJSONを使用するのとは対照的に、プロトコル・バッファに慣れ、HTTP/2の摩擦に対処する方法を発見するのに時間がかかるだろう。
AppMaster はどのように役立つのか？
ノーコード生成は、人々のプログラミングに対する見方を変えつつある。ノーコード生成によって、人々はコード生成でより速くソフトウェアを学び、作成することができるようになります。AppMasterのようなノーコード生成プラットフォームを使えば、アプリケーションのコード生成はよりシンプルになります。コード生成は保護されており、作成されたコードはあなただけに帰属するため、所有権の問題もありません。AppMasterを使用することで、クライアントおよびサーバ・アプリケーションをより速く、より簡単に作成することができます。
AppMasterのコード生成不要のプラットフォームにより、開発者はgRPCプロトコルを使用して、バックエンドのマイクロサービス・アーキテクチャ間でリクエストを行うことができます。来年は、gRPC WebとgRPC Mobileアプリケーションの両方へのAPIを含めることで、gRPCサポートを拡張する予定です。
まとめ
gRPC サービスには、企業や開発者にとって魅力的ないくつかの利点がありますが、最終的に、REST や SOAP のような他のサービスではなく gRPC サービスを使用するかどうかは、アプリケーションに依存します。あるソフトウェアは gRPC を使用することで高いパフォーマンスを得ることができますが、他のソフトウェアはその代用品に適しているかもしれません。gRPC サービスの欠点と利点を理解した上で、自分にとって有効かどうかを判断する必要があります。
