次世代webカンファレンス のserver_archセッションでお話することになった。 イベント趣旨にある「答えの出ていない問題を登壇者が話し合う」というのが面白そうであり、当日はどのように話が進むのか私も楽しみにしている。
私としてはやはり最大の持ちネタはgRPCで、gRPCを使うようなサーバーサイドアーキテクチャはいかなる物なのかというところから切り込んでいくことになるだろう。
次世代webカンファレンス のserver_archセッションでお話することになった。 イベント趣旨にある「答えの出ていない問題を登壇者が話し合う」というのが面白そうであり、当日はどのように話が進むのか私も楽しみにしている。
私としてはやはり最大の持ちネタはgRPCで、gRPCを使うようなサーバーサイドアーキテクチャはいかなる物なのかというところから切り込んでいくことになるだろう。
最近 Jsonnet という設定ファイル言語を触っていて、とりあえず公式のC++ライブラリをラップした Ruby拡張ライブラリ を書いてみた。 本当はpure-Go実装を書きたいのだが、当分先になりそうだ。
合わせて、Qiitaに Jsonnetの解説記事 も書いてみた。
@vvakame さんが TechBooster の新刊"JavaScriptoon"の中でgRPCを解説していて、その中で grpc-gateway にも触れている。これはとてもよい記事だったので、みんなこの本の電子書籍版を買えば良いと思う。 ただし、grpc-gatewayは記事中で使われているだけで主題ではないので、すべてのトピックをカバーしてくれているわけではない。それは仕方が無いが、そろそろgrpc-gatewayの機能を見渡す日本語記事が欲しいと思ったので自分で書くことにする。
gRPC (HTTP/2 + ProtocolBuffers)をwrapして古典的なJSON API (HTTP 1.1 + JSON)を提供するリバースプロキシを生成するコード生成機だ。 別記事 にも書いた。
gRPCで使うサービス定義(IDLみたいなやつ)を元にリバースプロキシの中核部分を実装するgolangのHTTP handlerライブラリを生成する。 リバースプロキシはgolangで書かれているが、これはwrapされるgRPCサービスとは別プロセスで動作するためサービス自体をgolangで書く必要はない。C++, Java, Ruby, Python, PHP, C#, Node.jsなどgRPCがサポートする任意の言語で書いて良い。
では、生成されたレバースプロキシは何ができるのか。 基本的にはHTTP/1.1 リクエストをサービス定義ファイルに埋め込まれた情報に基づいて解釈し、gRPC用のリクエストメッセージを構築したうえでgRPCエンドポイントに転送、 その後はエンドポイントからレスポンスを受け取ってからJSONに変換し直してクライアントに転送する。
もうちょっと詳しく見てみよう。まず、RPCのパラメータは次の3種類の形で受け付けて、3つを任意に組み合わせることもできる。
Body parameter
プロキシが受けたHTTP request bodyをProtocol Buffers messageのJSON表現として解釈し、そのmessageをgRPCエンドポイントに転送する gRPCに引き渡すmessageの一部分だけをrequest bodyから受け取ることもできる。その場合は、他の部分はpath parameterやquery parameterとして受け取る必要がある。
勿論、HTTP methodがGETやDELETEなどの場合はbody parameterは受け取れないので、path parameterやquery parameterで受け取る必要がある。
Path parameter
プロキシが受けるHTTP request pathパターンの中に変数部分を埋め込んでおくことができる。この変数部分の値を対応するmessageのフィールドに反映してからgRPCエンドポイントに転送する
Query parameter
同じく、query stringをmessageのフィールドに反映する
これらのマッピングの詳細は、Googleが公開している google.api.http というカスタムオプションを用いてサービス定義ファイルの中に指定する。下記はその例である。
service EchoService { rpc Echo(SimpleMessage) returns (SimpleMessage) { option (google.api.http) = { post: "/v1/example/echo/{id}" }; } rpc EchoBody(SimpleMessage) returns (SimpleMessage) { option (google.api.http) = { post: "/v1/example/echo_body" body: "*" }; } }
次のような項目が設定できる。
HTTP request pathのパターン(+ HTTP method)とgRPCメソッドの対応関係
Protocol Buffers messageのどの部分を(または全部を)bodyとして受け取るのか
EchoBody
では SimpleMessage
内の全fieldをbodyで受けているPath pattern内の可変部分とmessage fieldの対応
Echo
ではパスの最後にある可変部分を SimpleMessage
の id
フィールドに対応させているBodyやpathで受け付けなかったパラメータはすべて省略可能のquery parameterであると仮定される
gRPCはリクエストを受け取る際にリクエストメッセージ本体の他にmetadataという名前=値ペアの列を受け取ることができる。 これをHTTP/1.1で提供するため、以下のようにHTTP headerをmetadataに変換する
ところで今 RFC 2617 を見ていたらWWW-Authenticateヘッダを完全に忘れていたことに気がついたので、あとでサポートした方が良いかもしれない。
gRPCにはstreamingという機能がある。1つリクエストを受け取って1つレスポンスを返す代わりに、リクエストのストリームやレスポンスのストリームを受け付けるものだ。 更に言うと次の3パターンがある。
grpc-gatewayは最初の2つをサポートし、メッセージの列はJSON Streamとして表現される。 bidirectionalなstreamingも限定的にサポートしているが、すべてのリクエストを受け取ってからレスポンスを返し始めるという使い方しかできない。本当にbidirectionalにしようと思ったらWebSocketsにugpradeとかしなければならないだろう。現在はそこまでする予定はない。
なお、client streamingとbidirectional streamingではすべてのリクエストパラメータをbodyで渡す必要がある。リクエストメッセージが複数個である以上、特定のリクエストメッセージに紐付かない形のパラメータは解釈が曖昧になるからだ。
gRPCサービスがエラーを返した場合はエラーコードを適切なHTTP response statusに対応させて返す。またエラー時のresponse bodyにはgRPCサービスが返したエラーメッセージを含むJSON objectが入っている。
The service you are developing provides APIs for users. When an user calls an API, (s)he must show a short-living authorization credential, e.g. an OAuth2 token.
The user creates, owns, updates or deletes resources in the service on behalf of the account to which the credential is associated. Here, the `user' might be (an user-agent operated by) a human but also it might be an automated program running in background.
Also you want to use captcha to prevent huge number of accounts from being registered for some fraud purpose.
And you might even want to let users register their billing address for charging.
It is hard for users to securely manage accounts which automated programs use.
"manage" here basically means to create/update credentials as necessary and handle bills. A human (or a specialized billing-system, at least) must handle these things instead of the automated program because such a program tends to be bad at solving captcha -- it is by design and raison d'être of captcha --, and it is even worse at receiving bills by mail and going to bank to pay.
Then, how can (s)he manage the account for the program? Although some easy solutions come to the mind of the user, they do not work fine enough.
Reuse the account of the human for the program
Individual members in the team which manage the program can leave the team.
So suppose that the owner of the account leaves the team. Then the resources owned by the person can be deleted, or access to the resources can be restricted. At least, it would get hard to manage authentication credentials of the account.
Create an account only for the program
In this approach, (s)he creates a new account for the program in the same way as (s)he creates an account for human. Then the person lets the program use the new account. This account is shared by the team. So even if someone leaves the team, someone else in the team can manage the account.
There are, however, some scenarios in which this approach will not work fine. First, members in the team must share the authentication credential, e.g. passwords, to manage the account. But it is hard to track usage of the credential for audit. Second, even though it would get harder to keep the authentication credential secret as the team gets larger and the team needs to update the credential when necessary, it would also get harder to notify the update to all members in the team. Finally, even if they solve the issues above, it still tends to happen that someone in the team creates an account but (s)he leaves the team without sharing the account with others. Then none can manage the account.
To make things worse, they need to keep the account for the program having the minimum rights for security. It means that they will have more number of accounts per usage and the issues above becomes more serious.
System
Resource
private repositories
Account
github account
short-living authorization credential
OAuth2 token issued by github
Authentication information to manage the account
Password of the github account
Automated Program
Build processes running on Travis CI.
System
Resource
S3 bucket
Account
AWS account
short-living authorization credential
Authentication information to manage the account
AWS password
Authomated program
The feature that allows users of Cookpad to upload their pictures of dishes.
Define another kind of accounts ( Automation Account ), which is only for automated programs.
Distinguish this kind of accounts from ordinal accounts for humans.
Do not assign any passwords to automation accounts. Instead, associate the automation account to a list of human accounts who can manage the automation account.
Humans in the list just need to login to the system with their own human accounts when they manage the automation account. So they don't need to share the password of the automation account. Moreover, the automation account does not need to have its own password.
There are two kinds of accounts: ordinal (human) accounts and service accounts
Since service accounts do not have passwords for login, you can not use service accounts when you log into web pages but you can use them only for API calls with their OAuth2 tokens. Also you have to use your own human account and the the account must be an owner of the project when you manage the service account.
You can create arbitrary number of IAM accounts under the root account.
You have to use the root account or an IAM account for human when you need to login to the web console to manage IAM accounts.
Let's compare the two implementations.
The approach of GCP is a bit more complicated for hobby developers because GCP requires the developer to create a "project" in addition to his/her human account even though (s)he is the only developer in the development team. On the other hand, (s)he would be able to do everything just with his/her root accounts in AWS.
Next, let's think about larger development projects. AWS is a bit less secure because root account itself is an account with username and password and the dev team must keep the account secure in addition to their IAM accounts. On the other hand, GCP is secure because it does not have this kind of extra authentication credential which is not usually used.
あなたが開発しているサービスはユーザー向けにAPIを提供している。そして、APIを利用するにはユーザーは短寿命の認可情報(たとえばOAuth2トークン)を提示しなければならない。
ユーザーは認可情報が紐付いているアカウントの権限でリソースを読み取ったり、作成したり、所有したり、編集または削除したりする。 ここで、ユーザーは人間(が操作するユーザーエージェント)であることもあるが、人間の手を離れてバックグラウンドで自動実行されるプログラムかもしれない。
また、あなたは悪用目的でアカウントが大量登録されるのを防ぐためにCaptchaを利用したいと思っている。 さらに、課金目的で請求書送付先を登録させたいとも思っているかもしれない。
プログラムが利用するアカウントを安全に管理するのがユーザーにとって困難である。
プログラムは自分でCaptchaを解いたりEメールを受け取るのが苦手だし(そうでないとCaptchaの意味がない)、 また郵便物で請求書を受け取って銀行に振り込みに行くのは更に苦手である。 よって、プログラムが利用するアカウントを作成し、管理し、対応する請求書を処理するのは人間(か、少なくともそれ専用の別のシステム)でなければならない。
ではその人間はどのようにそのプログラムが利用するアカウントを管理すれば良いのか。幾つかの簡単な解決策を思いつくが、いずれも十分とは言えない。
人間のアカウントを使い回す
プログラムを管理しているチームの誰かのアカウントを使う、という解決法。
しかし、個々の人間は自動プログラムを管理ししているチームを離れることがある。このアカウントを所有していた人物がいなくなると、 アカウントの元に所有されていたリソースは消滅したり、アクセスが制限されたりする可能性がある。 最低でも、そのアカウントの認可情報を更新するのは困難となる。
プログラム専用のアカウントを共有する
人間用のアカウントを作るのと同様にして、人間がプログラム専用のアカウントを作成する。そしてそのアカウントをプログラムに利用させる、という解決法。 アカウントは自動プログラムを管理する人間たちによって共有されており、たとえ誰かがチームから居なくなっても 他の者がアカウントの管理、認可情報の更新などを行える。
しかし、これもまた十分とは言えない。人間たちはアカウントを管理するためのパスワードなどの認証情報を共有しなければならないが、 その周知の情報をいつ誰が利用したのか監査記録を付けるのは大きなチームでは難しい。 また大きくなるほど認証情報漏洩のリスクは高まって適時の更新が必要とされるが、大きくなるほど更新したという事実を全員に伝えるのも難しい。 苦労してこれらの問題を解決したところで、誰かが開発用にアカウントを作ったが良いが周知するのを忘れたままチームを去って、結局誰も管理できないアカウントになったりするのもありがちな問題である。
更に、セキュリティ上はプログラム専用アカウントは最小限の権限を持つのが望ましいが、最小化するために権限ごとにアカウントを設定すると 管理すべきアカウントの数が増えて管理にまつわる問題は酷くなっていく。
システム
リソース
プライベートリポジトリ
アカウント
githubアカウント
短寿命認可情報
githubのOAuth2 token
管理のための認証情報
githubのパスワード
自動化プログラム
travisによるビルドプロセス
自動化プログラム用のアカウント種別(Automation Account)を作って、人間用のアカウントとは区別する。 また、Automation Accountには管理用のパスワードを割り当てず、代わりに「このAutomation Accountを管理できる人間用アカウントのリスト」を対応させておく。
人間たちは自分自身の人間用アカウントでログインするだけで(リストに載っていれば)Automation Accountを管理できる。 このため、Automation Accountのパスワードを共有する必要はない。 それどころか、プログラム用のアカウントはどうせ人間の誰かが自分のアカウントで管理するのだからAutomation Accountにはパスワードがなくても差し支えない。
GCPのAPIが提供するほとんどのリソースは「プロジェクト」という単位に所属する。
ユーザーアカウントはプロジェクトとは独立したアカウント(GmailアカウントまたはGoogle Apps for Workアカウント)で、 任意の数のプロジェクトに読み取り専用、書き込み可、またはオーナーとして参加できる。
これに対してサービスアカウントはプログラム専用のアカウントで、ただ1つのプロジェクトに一意に属し、プロジェクトが削除されると他のリソースと同様サービスアカウントも削除される。
サービスアカウントはログイン用のパスワードを持たないためWebページのログインには利用できず、OAuth2トークンを用いてプログラムからAPIを呼ぶためにしか利用できない。 サービスアカウントを管理するには、そのプロジェクトのオーナーになっている人間のアカウントを利用する。
課金先情報はプロジェクトごとに登録管理される。サービスアカウントであれ一般のユーザーアカウントであれ、プロジェクト内のリソースに対する操作はプロジェクトに対して課金される。
APIが提供するリソースは特定のAWSユーザーアカウント(rootアカウント)に属する。
権限を分割するために、ユーザーアカウント内に任意個のIAMアカウントを作成できる。 IAMアカウントはパスワードを設定して人間に割り振ることもできるし、パスワードを与えないでおいてプログラムに利用させることもできる。 プログラム用のIAMアカウントを管理するためにwebコンソールにアクセスする場合は、パスワードを割り振られた人間用のIAMアカウントまたはrootアカウントを利用する。
課金情報はrootアカウントごとに登録管理される。IAMアカウントが利用したリソースはその属するrootアカウントに対して課金される。
2つの実現例を比べてみよう。
GCPのアプローチは一個人が趣味で開発しているような小規模開発においても、開発者のアカウントの他にプロジェクトという単位を作成する必要があるのでやや煩雑である。 一方AWSのアプローチは個人の小規模開発であれば人間用にはIAMアカウントを発行せず、rootアカウントだけですべてを済ませることも可能なので単純である。
大規模な場合に目を移すと、AWSのアプローチはrootアカウントそれ自体がユーザー名とパスワードを持つアカウントであるため、守るべき対象が1つ多い分だけほんの少しセキュアでない。 またそもそもこのrootアカウントのパスワードをどう管理するかという点において上記と類似の問題が残されたままである。 これに対してGCPでは、この通常使われることのない余分な認証情報はそもそも存在しないのでセキュアである。
先日公開した grpc-gatewayだが、gRPCのメーリングリストで宣伝したらGoogleからフィードバックがあったので対応した。
実はGoogleは社内にgrpc-gatewayに似た仕組みを持っていて、RESTful APIとgRPCの変換にはそれを使っている。 んで、今回Googleはその変換の設定に使っているスキーマを https://github.com/google/googleapis/tree/master/google/api に公開してくれたのだ。
これを受けてgrpc-gateway独自のカスタムオプションを捨ててGoogleが公開したオプションを使うことにした( grpc-gateway#12 )。これには幾つか理由がある。
Googleの長年の経験を踏まえて設計された語彙のほうが、私がとりあえずプロトタイプとして適当に設計した語彙より拡張性と十分性において信頼に足る
似たようなスキーマがいくつもあるとユーザーとっては不便であるから統一した方が良い。
なお、古い独自オプションのサポートはバッサリ切り捨てた。
それから、HTTP Request pathのテンプレートの文法もちょっと複雑になって従来の goji のルーティング設定に頼る方式では限界が来たので、 独自にtemplate parserと実行時にマッチするためのスタックマシンを書いた。 ASTそのままでInterpreterパターンすれば十分かとも思ったのだが、よく考えたらparseするのはgatewayのコードを生成するときで、パターン照合が走るのはgatewayのコードが実行される時だ。 よってparse結果を何らかの形でgatewayのソースコードとして保存しなければならないのだが、ASTを表すGoの式を生成しつつ将来の拡張もできる符号化とかも考えると面倒になってきたので スタックマシンのopcodeとして符号化することにしてしまった。 Railsの経験からもルーティングはボトルネックになりがちなので、この意味でもASTを再帰的に辿るよりはopcodeでloop + switchのほうが良いかもしれぬ。
grpc-gateway という gRPC からJSON APIへの変換プロキシ生成機を書いた。
これを使えばシステム内部ののmicroservicesはgRPCで通信しつつ公開APIはJSON APIで提供する、みたいなことが簡単になる。
なお、gRPCそのものについては mattnさんの記事 が参考になる。
gRPCの良い点はいくつもある。
gRPCの素晴らしさは認めるものの、一方では欠点もある。まず、クライアントライブラリの多くはCで書かれたバイナリ拡張を含む。
これはRuby界ではあまり歓迎されていないし、多くのユーザーにAPIを使ってもらうということを考えればどうしたってクライアントは利用言語ネイティブで書かれていた方が良い。
また、そもそもgRPCはまだそんなに普及していない。gRPCがサポートしていない言語だってなくはない。
だからコントロールの効く範囲のシステム内部の通信にgRPCを使うのは極めて妥当な選択だが、現時点で公開APIをgRPCだけで提供するっていう決断はAPI提供者としてはなかなか勇気が要る。
だったら公開APIはJSONのままでいきたいというのは自然な発想だ。
gRPCのJSONシリアライゼーション機能を使っても良いのだけど、それでもHTTP 2.0必須だし、呼び出しパスもちょっと独特なのでちょっとまだ敷居が高い。
そこで、コモディティとしての従来型のRESTful JSON API over HTTP 1.xがやっぱり必要なわけだ。grpc-gatewayはgRPCで書いたサービスを簡単にそうしたRESTful JSON APIに変換してくれる。
grpc-gatewayはgRPCそのものと同じく、protoc (protocol buffers compiler)のプラグインとして実装されている。
gRPCサービスを定義してある.protoファイルに専用のカスタムオプションでちょっとだけ情報を足すと、protoc-gen-grpc-gatewayプラグインがgRPCとJSON APIを仲立ちするreverse proxyを生成してくれるようになる。
カスタムオプションには次のような情報を指定できる
生成されるproxyはgolangだが、バックエンドのgRPCサービスとはgRPCで通信さえ出来れば良い。よってgRPCサービスのほうは普段通り好きな言語で書けば良い。
現時点ではgRPCのstreaming機能はサポートしていないが、これはすぐにサポートする予定だ。サポートした
そのほかにもREADME.mdに書いてあるようないくつかの機能をサポートしていきたいと思っている。
中でもSwagger API definitionの出力は是非対応したいポイントだ。protoからAPI definitionは作るからあとはJSON API clientはswaggerで勝手に作れ、という風にしたい。