小野マトペの納豆ペペロンチーノ日記スマートフォン用の表示で見る小野マトペの納豆ペペロンチーノ日記2016-01-05GoとgRPCでKVS的なものを作ってみたGo正月で時間があったので、以前から触ってみたかったgRPCをGo言語から使い、キー・バリュー・ストアのようなものを作ってみた。KVSといっても、GoのmapへのGet/Put/Delete/ScanをgRPC経由で叩けるようにしただけのもの。それだけだとあまり面白く無いので、gRPCらしく、Watch機能をつけてmapへの更新を監視できるようにした。ProtoBuf)のメリットや違いが気になっていたので、そのあたりを気をつけながら書いた。3でKVSのサービスを定義する。サンプルを見ながら適当に書いた。}メソッドの引数と戻り値はmessageで定義した構造体である必要があるらしい。Streamingの宣言で、レスポンスをEntry構造体のストリームにすることができる。Eventのようにサーバープッシュ用途にも使える。Streaming)。上のkvs.protoから、protocコマンドでkvs.pb.goを生成する。サービス実装protocに成功すると、kvs.pb.goに下のようなサーバー用interfaceが定義されるので、これを実装してやれば良い。error}サーバー側実装はこのようになった。nil}通常のRPCは、フレームワーク経由でnet/httpのハンドラを書くの感覚と大して変わらない。コード生成によりリクエストフィールドが全て静的にアクセスできるので、ボイラープレートコードが不要で良い。定義されているエラーコードを渡してやるのが流儀らしい。サーバー起動部分はこれだけ。GitHubprotocにより完全なクライアントコードが生成されているので、クライアントの接続部分はこれだけでよい。あとはKvsClientに実装されたメソッドを使えば良い。APIで設計する場合、そこそこ綺麗に書いたとしても、どうしても認証・ハンドラルーティング、リクエスト・レスポンスのエンコーディングなど、ボイラープレートコードは発生してしまう。ステータスコードなどREST表現の全体としての整合性を考慮しなければならず、しかも使用しているURLルータによっては変更を余儀なくされたりとつらさを感じていた。そんな理由でRPCに魅力を感じてはいたが、できること・できないことがいまひとつ分からず、乗り換えられずにいた。gRPCを試してみて、サービスの定義さえしてしまえばサーバ・クライアント実装が自動生成されるため、ボイラープレートコードも発生せず、本質的なロジックに集中して書き進めていけるのは快適だった。コードの質もよくなっていると思う。そのうえで、HTTPハンドラに出来てgRPCに出来ないことはあまりなさそうということも分かった。APIで流せば大丈夫そうとか。RPCの使用にはコネクティビティの心配もあるが、gRPCは主要な多くのプログラミング言語へのコード生成に対応しているので、実際に問題なることはなさそう。APIよりクライアント/サーバーの実装が楽になって結果的にRESTより相互接続性が上がりそう。参考に、Getのパフォーマンスを比較してみた。jobs/sec(サーバ・クライアント同居での雑な計測です)遅い...。便利であるとはいえ、スループットが生REST時の半分以下になるのはちょっと厳しい。gotipでビルドしたところかなりパフォーマンスが改善しているので、今後のgoの実装の改善を期待しつつ、パフォーマンスが重要でないところから導入したほうがいいかもしれない。00:32GoとgRPCでKVS的なものを作ってみたTweet広告を非表示にする関連記事2014-08-14Golangで関数をグローバル変数に代入してテスト時にスタブするこんにちは、小野マトペです。GroupsのRSS/Atomフィードってどこにあるんだっけカメラ初心者がカメラ沼に入ってみた。ディスクキャッシュを保存する容量がないと言い張るときはTimeMachineローカルスナップショットを消せ月別アーカイブはてなブログをはじめよう!ono_matopeさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。