LinkedInは、Microservices platformのサービス間通信にProtocol Buffersを使ったgRPCに移行すると発表した。従来は、オープンソースのRest.liフレームワークが主要なシリアライゼーションフォーマットとしてJSONと共に使われていた。
InfoQは、LinkedInの著名なエンジニアであるKarthik Ramgopal氏と、LinkedInの主任スタッフエンジニアであるMin Chen氏に、この決定とその背後にある企業の動機について詳しく話を聞いた。
InfoQ：RESTを使ったJSONではなく、gRPCとProtocol Buffersを選択した主な理由は何でしょうか？
Karthik Ramgopal氏/Min Chen氏： 現在のRESTフレームワークRest.liを置き換えるためにgRPCを選んだのは、以下の理由からです。
優れた機能 - gRPCは、Rest.liがサポートしていない双方向ストリーミング、フロー制御、デッドラインのような高度な機能をサポートしており、私たちが詳しく説明するように、非常に高機能なフレームワークです。
効率性 - gRPCは、完全に非同期のノンブロッキングバインディングや高度なスレッドモデルのような、その実装に性能を焼き付けており、非常に効率的なフレームワークです。私たちは、gRPCとRest.liサービスを並行して実行する合成ベンチマークと実運用ランプによって、このことを検証しました。
多言語サポート - Rest.liは主にJavaで実装されており、他のプログラミング言語のサポートは不完全または存在しません。gRPC は、いくつかのプログラミング言語に対して高品質のサポートを備えています。これは、LinkedIn のインフラサポート要件を考慮する時に重要です。
これらすべてを超えて、gRPCは大規模で活気のあるOSSコミュニティの支持を得ており、業界全体で広く利用されています。Rest.liはオープンソースでありながら、主にLinkedInによって貢献され、使用されています。
InfoQ：以前、Rest.liフレームワークのシリアライゼーション形式としてProtocol Buffersを採用していました。この経験から何を学び、他のシリアライゼーション形式を評価しましたか？
Karthik Ramgopal氏： ブログ記事で詳しく説明していますが、主な学びはJSONからProtobufに切り替えることで、大規模なレイテンシーとスループットの向上が得られる点です。Protobufに加えて、CBOR、MessagePack、SMILE、Avro、Kryo、Flatbuffers、Cap'n'Protoを評価しました。最終的にProtobufを選んだのは、実行時のパフォーマンス（レイテンシ、ペイロードサイズ、スループット）、開発者のエクスペリエンス（IDEオーサリング、スキーマ検証、アノテーションサポートなど）、多言語/環境サポートのトレードオフがもっとも優れていたからです。
InfoQ：Rest.liのGitHubページで、このフレームワークは今後開発されず、非推奨になると発表しました。現在フレームワークを使っているユーザーに何かアドバイスはありますか？
Karthik Ramgopal氏/Min Chen氏： Rest.liからgRPCへの移行を検討してみてください。自動化による移行をスピードアップするためのヒントが必要であれば、LinkedInを通じて私たちに連絡してください。
InfoQ：ブログ投稿の中で、いくつかのサービスで最大60%のレイテンシの改善を確認したと述べています。その詳細を教えてください。
Karthik Ramgopal氏： 待ち時間の改善のほとんどは、ペイロードサイズが小さくなり、シリアライズ/デシリアライズに費やされるCPU時間が減ったことによります。60％という数字は、非常に大きく複雑なペイロードを持つサービスに対するもので、これらのコストが待ち時間の主な原因となっています。また、Protobufを使用するとGCが大幅に削減されるため、多くのサービスでテールレイテンシ（p95/p99）が大幅に改善されました。
InfoQ：LinkedInでは、現在50,000を超えるRest.liエンドポイントが運用されていると伺ってます。これは驚くべき数だが、なぜそんなに多いのか説明してもらえますか？
Karthik Ramgopal氏： 最大のプロフェッショナルネットワークの1つとして、我々はエンティティの複雑な「経済グラフ」を持っています。この中には、私たちのエンタープライズビジネス（Recruiter、LinkedIn Learning、Sales Navigatorなど）が含まれており、それぞれ独自の事業体を持っていて、社内アプリケーションやツールシステムなどもあります。さらに私たちは通常、BFF（Backend For Frontends）、ミッドティア、バックエンドの3層アーキテクチャを使用しています。過去10年間これらのユースケースはすべてRest.liを使ってモデル化されており、これがエンドポイントの多さの理由であります。
InfoQ：gRPC+Protobuf 導入プロジェクトの主な目標・理由は何だったのでしょうか？LinkedInは、同様の目標をサポートする他のイニシアチブに取り組んでいるか、取り組む予定がありますか？
Karthik Ramgopal氏/Min Chen氏： 採用の理由は、REST+JSONではなくgRPC+Protobufを選んだ理由と一致している。
我々は、すべてのステートフルストレージとストリーミングシステムをAvroからProtobufへの移行作業として行っています。また、一般的なインフラ機能（AuthZ、コールトレース、ロギングなど）をJavaライブラリからサイドカーに移行し、gRPC over UDS APIを公開することで、複数のプログラミング言語サポートのコストを削減しています。我々はまた、gRPC xDS SDKとEnvoyサイドカーの両方で動作するように、業界標準のxDSプロトコルを採用するために、特注の社内サービスディスカバリーとロードバランサーを改良しています。