gRPCに関する初のカンファレンス、gRPC ConfがGoogle本社で開催

連載 :

イベント・セミナー2019

2019年4月23日(火)

マイクロサービスのベースとなるRPCフレームワークのgRPCに関するカンファレンスが、Google本社で開催された。

クラウドネイティブなアプリケーションでは、アプリケーション全体を小さなプロセスに分割してステートレスなコンテナの集合体として実装することが最近のトレンドだ。その際の「プロセス間の通信をどうするのか？」については、REST APIというのが大凡の解答だったように思える。

それに対して、Googleが社内で使用していたStubbyの経験を活かして、オープンソースとして公開したのがgRPCだ。2016年にGoogleがgRPC 1.0を公開し、CNCFでのインキュベーションプロジェクトとなったのが約半年後の2017年1月、その後2019年3月に至るまですでに多くのユースケースで利用が拡がっている。そのgRPCに関する初めてのカンファレンスgRPC Conf 2019が、Googleの本社で開催された。この記事では、カンファレンスのようすを報告する。

gRPCの概説と進化の過程

最初に登壇したのは、当然だがGoogleのDistinguished EngineerであるAnna Berenberg氏だ。

GoogleのAnna Berenberg氏

Berenberg氏は、gRPCの前身であるStubbyとProtocol Buffersについて過去を簡単に振り返る部分を紹介した。特にgRPCが使っているシリアライゼーションのためのIDLであるProtocol Buffers（通称、Protobuf）とStubbyが、Google社内でどのように進化してきたのかを解説した。

ProtobufとStubbyの歴史

ここではNetflixがProtobufについて、LyftのMatt KleinがgRPCについて賞賛していることが、この2つの技術の良さを物語っているように思える。そこからService Discovery、Load Balancing、Health Check、Auto Scaling、Securityなどについて、StubbyとgRPCの違いを細かく解説し、gRPCの優位点を説明した。

Health CheckにおけるStubbyとgRPCの違い

最終的に、gRPCはエンタープライズからGoogleのようなパブリッククラウドプロバイダーまで幅広く利用可能な堅牢なソフトウェアであるとして、最初のセッションを終えた。

参考：Berenberg氏のプレゼンテーション：gRPCconf keynote.pdf（PDF）

gRPCの長所は？

次に登壇したのはLightStepのエンジニア、Joe Blabaugh氏だ。元Google、その後Twitterなどでのエンジニア職を経て、LightStepに至ったという経歴の持ち主だ。2011年ごろにGoogleに在籍してStubbyとProtobuf2.0の開発を経験した後に、TwitterのFinagleとThriftの開発に携わっている。FinagleはTwitterのRPCシステム、ThriftはFacebookが開発したIDL（Interface Description Language、インターフェース記述言語）で、Apache Thriftとして開発が進んでいるものだ。

Blabaugh氏の経歴。RPC関連の経験が豊富

ここからPRCとしてのgRPCがどうして優れているのか？　をプレゼンテーションした。

gRPCはほぼ理想に近い

RESTに対する優位点が強調されるgRPC（とProtobuf）だが、実際にAPIをデザインする際にgRPCが全てをやってくれるわけではなく、やはりガイドラインに沿って設計をするべきというのがBlabaugh氏の忠告だ。

APIの設計には注意が必要

いかにツールが良くても、複雑なAPIや解読しづらいコードを書いてしまうことはあるというのは、GoogleやTwitterでの経験が活きているということだろうか。

参考：Blabaugh氏のプレゼンテーション：Setting Yourself Up for gRPC Success（PDF）

DropboxとSlackのユースケース

その後は、DropboxとSlackのエンジニアによるユースケースが紹介された。

Dropboxのユースケース：Courier gRPC Conf 2019

DropboxのHehrdad Afshari氏

Dropboxのユースケースは、CourierというgRPCをベースにしたマイクロサービス間通信のインフラを開発して、全社的に使っているというものだった。

Slackのユースケース：gRPC For The Thrifty

SlackのJosh Wills氏

SlackはFinagle＋Thriftという組み合わせから、Lineが開発したArmeriaを利用しているという。Armeriaに関してはLINEのエンジニアが書いたこの記事が参考になると思われる。

参考：RxJava 2とArmeriaでマイクロサービスを非同期化してみた

盛り沢山の内容となったgRPC Conf 2019

その後のランチ以降にもJoyentのエンジニアによるNode.jsでのユースケース、サービスメッシュのIstioを推進するVMware、軽量ProxyのLinkerdを開発するBuoyantなどのエンジニアがプレゼンテーションを行い、ユースケースから監視や可視化の取り組み、他のPRCとの性能比較などが語られ、1日とはいえ盛り沢山のカンファレンスとなった。

Linkerdを紹介するBuoyantのThomas Rampelberg氏

gRPCは主にGoogleで開発が行われているが、CNCFにホストされていることからも分かるように透明性を高めてガバナンスをしっかりと行うことで、Google以外のエンジニアの参加を推奨しているのがこのカンファレンスでも見て取れた。

全体を通じて感じたことは、REST APIのようにすでにデファクトスタンダードと思われていた技術であっても、時とともに陳腐化することは避けられず、常に新陳代謝が行われているということだ。FacebookがGraphQLを開発し公開したのもREST APIの限界を感じた結果だったし、GoogleがgRPCを公開した理由の根底にはREST APIで苦労している外部のデベロッパー救済の意味があったと思われる。どちらも自社の技術を積極的に公開することで、全体を良くするソーシャルグッドの発想があるように感じる。そして個人に依存してしまうコミュニティに任せず、Foundationを通じて仕組みを作った上で対話と改善を止めないという方法論は有効ということだろう。次回以降も楽しみなカンファレンスとなった。

最後にgRPCのキャラクターを紹介しよう。これはgRPCを「ゴールデンレトリバーのパンケーキ」（Golden Retriever Pan Cakes）の頭文字に当てたもので、パンケーキ色のゴールデンレトリバーとなる。当然名前はパンケーキだ。