爆速でGo!

GoGo!

gRPCは何故誕生したのか

Click here for English version

gRPCという言葉はすっかり有名になり、日本でも「社内でgRPCを導入した」「gRPCサーバーを構築する方法」といったような記事が溢れかえるようになりました。
これにより、gRPCの導入ハードルは下がり、比較的簡単にプロダクションレディなgRPCサーバーを作ることが出来るようになりました。
しかしそもそもどういった背景でgRPCが誕生したのでしょうか。

背景

gRPC Blogには、以下のように記載されています。

GoogleはstubbyというRPCインフラストラクチャ持っており、10年以上Googleのデータセンター内のマイクロサービスを接続してきた。
統一されたクロスプラットフォームのRPCインフラストラクチャを持つことで、全体の効率、セキュリティ、信頼性の改善の展開を可能にし、その期間の信じられないほどの成長を支えた。

stubbyには多くの素晴らしい機能があるが、社内のインフラに密接に結びつきすぎて一般公開には適していなかった。
SPDY, HTTP/2, QUICの登場により Stubbyをもっと汎用的に作り直して、モバイル、IoT、クラウド等のユースケースに適用させるべき時期が来たことが明らかになった。

また、Google Cloud Platform Blogには、以下のように記載されています。

高度にスケーラブルで疎結合のシステムを構築することは、常に困難だった。 モバイル機器やIoT機器の普及、データ量の急増、顧客の期待の高まりに伴い、インターネット規模で効率的かつ確実にシステムを開発して運用することが重要である。
この種の環境では、開発者は複数の言語、フレームワーク、テクノロジー、複数の第一および第三者サービスを扱うことがある。 これにより、サービス契約を定義して実施したり、認証や承認、ヘルスチェック、ロードバランシング、ロギングと監視、トレースなどの横断的な機能を全体にわたって一貫性を持たせることが難しくなる。 今日のクラウドネイティブの世界では、新しいサービスをすばやく追加する必要があり、各サービスの期待は柔軟で弾力性があり、可用性が高く、構成可能であることが特に課題となる。
過去15年間、Googleはこれらの問題を内部的にStubbyというRPCフレームワークで解決した。このRPCフレームワークは、数十億回のリクエストをインターネット規模で処理できるコアRPCレイヤーで構成されている。 今この技術は、gRPCと呼ばれるオープンソースプロジェクトの一環として、誰でも利用可能である。 これは、私たちがGoogleで楽しむのと同じスケーラビリティ、パフォーマンス、機能をコミュニティ全体に提供することを目的としている。

以上を踏まえ、誕生の経緯を雑にまとめるとこんな感じでしょうか

  • スケーラブルで疎結合なシステムを作るのは難しいけど、モバイルとか普及している現代はやらないといけない
  • GoogleではクロスプラットフォームのRPCフレームワーク使って対応していた
  • でもGoogle内部のインフラにめっちゃ依存してた
  • HTTP/2とか出てきて、Googleのインフラに依存せずとも標準規格で同等以上のものを作れるようになった
  • 標準規格ベースで作り変えて一般公開しよう!

参考

gRPCについて理解を深めたい場合は、以下から眺めていくと徐々に分かっていくと思います

間違い等ありましたら、コメントやtwitter等でご指摘頂けると嬉しいです。