いまさらgRPC入門：gRPCのドキュメント実況中継

TL;DR: gRPCの公式ドキュメントを読んで動かしてみた様子をGif動画付きでお届け。

こんにちは、kadoyauです。ドワンゴではニコニコ動画の開発をしています。

今日は業務は関係なく、自分が新しい技術を身につけるときの流れに沿ってgRPCを触るところを実況中継風にお届けします。この記事は入門そのものなので、経験がある方には退屈です。その場合、次の記事はいかがでしょう。

CPUレジスタ上の整数除算のおはなし

レンダリング結果を目標画像に近づけるために、オブジェクトや光源などの環境を求めるという逆問題

このままだとこの記事が「2020年おすすめ動画まとめ」になってしまうので、（そっちも魅力的ですが）本題に入りたいと思います。

この記事の目次

まえがき

gRPCイントロダクション

gRPCコアコンセプト

gRPCを実際に触ってみる

まえがき

OpenAPIとかgRPCとかGraphQLとかいっぱい出てきたな！

みなさんは、サービス間の連携には、どのような手法をつかっていますか？

一昔まではRESTのAPIがスタンダードだったと思いますが、次のような課題や革新がありました

外的環境の変化：PCだけでなく様々なモバイル機器からの利用の増加（多デバイスからAPIが叩かれることが前提になった）

課題：増えるAPI、信用ならざるドキュメント。当然増えるドキュメントと実装の食い違いによるコミュニケーションコスト。

革新：HTTP/2などの基礎技術の発展

この結果、OpenAPIやgRPC、GraphQLなどの技術が生まれてきたと認識しています。

未知との遭遇

私の所属する伝統的なサービスの開発チームではおなじみのREST APIを利用しています。

gRPCは弊社の別チームで採用されておりますが、私自身はWebで記事を読んだぐらいで、触ったことはありません。

パラダイムが変わる前に

このとき、以前Shiro Kawaiさんがおっしゃっていたことを思い出しました。

与えられた問題に100%の力で取り組む、というのは美徳とされがちだけど、同種の問題が途切れなく与えつづけられた場合、他の問題解決への適応を試しておく余力が無いので、パラダイムが変わった時に詰むよ、というのはどのくらい(意識され|教えられ)ているんだろうか。

わたしにとってgRPCは、

「現状使わなくても不自由がなく」

「取り入れるのがしんどそうな気がする」

技術です。「RESTがもうダメだ〜」となるまで触るモチベーションは起きづらい、というのが正直なところです。これは「同種の問題が途切れなく与え続けられた場合」に該当します。ユーザーがUI変更を嫌がるのと心理は似ていますね。このような構造は生きているといたるところにあり、昔から様々な啓蒙書（いいプログラマーになるにはというような本）で対策が提唱されているかと思います。

いまこそ学ぶべきときだと思いました。

注：完全に翻訳しているわけではありません。詳細は原文を見てください。

gRPCのイントロダクション

低レイテンシ、高スケーラブル、分散システム

モバイルのクライアントからクラウドのサーバと通信するような構成での開発をするとき

正確で効率的で言語非依存の新しいプロトコルを設計したいとき

拡張できるレイヤードな設計にしたいとき

gRPCの特徴

gRPCでは、クライアントは異なるホストのサーバーのメソッドを直接呼び出すことができる

clientとserverの言語が違っていてもOK

ただし、gRPCがサポートしている言語に限られる

gRPCを使うためにすること

gRPC以外のRPCでもこの手順は同様

serviceの定義にはProtocol Buffersというフォーマットを使う（後述）

サービスの定義以外に次のことをする必要がある

サーバーサイドがやること

定義したインタフェースを実装する

クライアントサイドがやること

メソッドをサービスとして実装したstub（他の言語ではクライアントといわれるもの）というobjectが提供されるので、たんにそれを呼べばよい

以上。あとはgRPCが、リクエストをサーバに送った後、サーバのprotocol bufferのレスポンスを返してくれるらしい

Protocol Buffer

Protocol BuffersはIDLとメッセージ交換フォーマットをかねたもの

Protocol Buffersをつかってみる

まず、シリアライズしたいデータのための構造をprotoファイルに定義する

code:simple example.proto

message Person {

string name = 1; // このペアを field と呼ぶ

int32 id = 2;

bool has_ponycopter = 3;

}

これで、データ構造が定義できた

メッセージに定義した各fieldに対して、単純なアクセサが自動生成される。

もちろん、シリアライズ/デシリアライズのためのメソッドも自動生成される

code:gRPC services example.proto

// Greeterというサービスを定義する

service Greeter {

// このメソッドは、HelloRequest型を受け取り、HelloReply型を返す

// このメソッドの定義方法は4つある（後述）。これは最も単純なUnary RPCという形式

rpc SayHello (HelloRequest) returns (HelloReply) {}

}

// HelloRequestの定義

message HelloRequest {

string name = 1; // リクエストメッセージはユーザ名を含む

}

// Hello Replyの定義

message HelloReply {

string message = 1; // レスポンスメッセージは挨拶（message）を含む

}

Protocol bufferの最新バージョンは3

Protocol buffersにはバージョンが有る。いままでよくつかわれていたのはversion 2なので殆どの例がv2のものだ

このドキュメントではversion 3（proto3）を使っている。2と比べて

構文がちょっと簡単

いくつか機能追加がある

gRPCのコアコンセプト

gRPC serviceで定義できるメソッドは次の4種類がある

同期 v.s. 非同期

同期RPC呼び出しは、サーバからのレスポンスがかえるまでブロックする

でもネットワークは本質的に非同期で、いろんな場合がある

現在のスレッドでブロッキングせずにRPCを開始できると便利

殆どの言語のgRPC programming APIは同期/非同期両方のflavorがある。チュートリアル読んでね。

実際の詳細は言語ごとに異なる

タイムアウト

クライアント

サーバー

特定のRPCに対して、次のことがわかる

RPCがタイムアウトしたか

タイムアウトまであと何秒？

デフォルト値があるかは実装依存

RPC termination

クライアントとサーバは独立して、callの成功を決定できる。一致する保証はない

つまり、サーバーサイドではレスポンスを返したと判定したが、クライアントサイドでは失敗したと判定されたというRPCが存在しうる

キャンセル

クライアントでもサーバーでもRPCはいつでもキャンセルできる

キャンセルすると直ちにRPCが終了する。それ以上何も起きない

キャンセル前の状態にロールバックはしない

メタデータ

特定のRPC callに対する情報(認証情報とか）

key-valueペアのリスト

Metadata is opaque to gRPC itself

クライアントやサーバー間でgRPC callに関係する情報を提供できる

言語によってアクセス方法が違う

チャンネル

gRPC channelは指定されたのhost/portでgRPC serverへのコネクションを提供する。これはクライアントのstubを作成するときに利用される

gRPCのデフォルトの挙動を変更するために、クライアントはチャンネルの引数を指定することができる

メッセージ圧縮のON/OFFの切り替えとかが切り替えられる

どのようにgRPCがチャンネルを閉じるかは実装依存

言語によってはquerying channel stateが許されている

手を動かしてみる

ここまでで概要は理解できたので、いよいよgRPCに入門していきます

確認環境：macOS 11.0.1

PHPは諦めてGoでやります

準備

code:zsh

# goの入門のプロなので入ってる

$ go version

go version go1.15.6 darwin/amd64

# protocのインストール

$ brew install protobuf

$ protoc --version

libprotoc 3.14.0 # 3以上なのを確認

# 手順に従ってプラグインを入れる

$ export GO111MODULE=on # Enable module mode

$ go get google.golang.org/protobuf/cmd/protoc-gen-go \

google.golang.org/grpc/cmd/protoc-gen-go-grpc

サンプルリポジトリをひっぱってくる

code:zsh

実行する

https://gyazo.com/0707355944bc4e595cfe9f5bf85016a7

左がサーバーで、右がクライアントです

gRPC serviceにRPCを追加してみる

yak shavingのコーナー：IntelliJで開くとprotobufのpluginのインストールを促されるので入れた

code:hellowold.proto

service Greeter {

// Sends a greeting

rpc SayHello (HelloRequest) returns (HelloReply) {}

// rpcを追加

rpc SayHelloAgain (HelloRequest) returns (HelloReply) {}

}

コンパイルする

code:compile

$ protoc --go_out=. --go_opt=paths=source_relative \

--go-grpc_out=. --go-grpc_opt=paths=source_relative \

helloworld/helloworld.proto

するとgoのファイルが2種類生成されます

helloworld/helloworld.pb.go

helloworld/helloworld_grpc.pb.g

https://gyazo.com/b4dbc29881f2d2795f175feadf731ac7

yak shavingのコーナー：コードを見てみようとしてIntelliJ IDEAを最新にすると、IntelliJ IDEAのGo pluginが動かない

https://gyazo.com/6cd2c77150c54ab7934197e98901a0fc

車両進入禁止を主張するGopher

サーバーサイドの実装を追加

code:greeter_server/main.go

// もとからある実装

func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {

log.Printf("Received: %v", in.GetName())

return &pb.HelloReply{Message: "Hello " + in.GetName()}, nil

}

// SayHelloAgainの実装を追加

func (s *server) SayHelloAgain(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {

return &pb.HelloReply{Message: "Hello again " + in.GetName()}, nil

}

クライアントサイドでstubの呼び出しを追加する

code:greeter_client/main.go

// もともとある実装

r, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})

if err != nil {

log.Fatalf("could not greet: %v", err)

}

log.Printf("Greeting: %s", r.GetMessage())

// 末尾にSayHelloAgainの呼び出しを追加

r, err = c.SayHelloAgain(ctx, &pb.HelloRequest{Name: name})

if err != nil {

log.Fatalf("could not greet: %v", err)

}

log.Printf("Greeting: %s", r.GetMessage())

動かす

https://gyazo.com/8acf399f1fc2afbb9c701b68cdbc8e99

というわけでざっくりとgRPCを触ってきました。

このチュートリアルはUnary RPCなのでかなり基本的でした

ここまででまだわかっていないが、本格導入にあたって知りたいこと

Streamingを前提にしたアプリケーションのアーキテクチャのパターンが知りたい

APIドキュメントを自動生成したい

開発中にAPIを叩きたくなったらどうするの？

自動生成したクライアントでAPIを叩いて回る結合テストがしたい（サーバサイドの実装漏れをなるべく自動検知したい）

evansのドキュメントを読んだらまさにそれっぽいことが書いてあったのでつかえるらしい

If you want to keep your product quality, you must use CI with gRPC testing, should not do use manual testing.

蛇足：遊んでみる

サーバーを多重起動させてみる→同じportではたてることができない

https://gyazo.com/ee03a91be37433606f2a32a196c22629

あとがき