koie blog : 歌舞伎座.tech#12「メッセージフォーマット/RPC勉強会」

https://kbkz.connpass.com/event/40629/
日時: 2016-11-27 14:00〜18:00
場所: ドワンゴセミナールーム（銀座松竹スクエア13F）
- 座席数: 3 x (8 + 10 + 10 + 11) = 117
http://togetter.com/li/1053413

[2016-11-27 13:47]

新宿→銀座→東銀座出口5ですぐだった。早く着きすぎて、まだ会場設営しおわったところだった。電源タップは潤沢に用意されていて席えらびには困らず。

[2016-11-27 14:00]

前説

仕事でつかっているけどみんだどうしてるのかな?ってことで勉強会開催した。
何つかっている? (30人くらい)
- XML: 4
- JSON: 多い
- messagepack: 仕事1
- Thrift: 4
- protocolbuffer: 10
- avro: 3
- CBOR(RFC7049): 1
質問は手を挙げてマイクがくるのをまってから。

[2016-11-27 14:10]

ProtocolBuffer / @tayama0324

http://tayama0324.github.io/slides/20161127-kbkz-tech.html#/
RESTよりgRPCの方が便利って布教中
ドワンゴ社内ではScalaをつかっているのでgRPCをさくっと対応
- https://github.com/scalapb/ScalaPB
gRPCでprotocolbufferを知った人 → 0人; もともとprotocolbufferを知ってた人 → 3人
- 日本ではprotocolbufferは流行ってないとおもってた。。
googleの社内でRPC系はgrpcになっている。ログもprotocolbufferで保存してたり。
IDL
- 変数名フィールド名 = タグ名;
- タグ名はフィールド名に対応した番号。いちいちエンコードするのは無駄なので。
immutableなデータ構造をつかうためだけにprotocolbufferをつかうのもあり。builderを書くのはめんどくさいので。
vs JSON/JSON schema:
- jsonは静的型付け言語と相性がわるい
- protocolbufはデータ構造を定義、JSON schemaは値の範囲を記述。JSON schemaでは再帰的データ構造は書けない。
- バイナリフォーマットなのでサイズが小さい。
- protocolbuf<->jsonの変換規則はgoogleが決めている。
フォーマットの基本的な方針: タグ・ワイヤータイプ・フィールド値をエンコードしたものを並べる。
フィールドタイプとワイヤータイプは1:1ではない。ワイヤータイプは4種類しかない。
- varint(可変長int),32bit fixed,64bit fiexed,byte-array.
- 文字列はUTF8をbyte-arrayにのせる。
signedで負の値のときは最上位ビットが立ってvarintに乗せると損→sint32: 絶対値が小さいもの順にエンコードしていく。0→0,1→1 -1→2...
robustness principle
- IDL ver3が最新、ver2ではrequired/optional/repeated修飾子が必須だった。
- requiredはbad parts: フィールドが不要になっても削除できない(システム全体で切り替えないといけないので現実的でない)。この話はprotobufにかぎらない話。
  - データ保存で、新しいバージョンをリリースしたあとバグが発覚して古いバージョンに戻したときに死亡...
- requiredをやめてデフォルト値を導入した。ver2でもデフォルト値があって任意の値が指定でき、デフォルト値なのかデータが飛んできたものかのビットがあった。v3でコンパイルしたコードが小さくなるメリットがある。v3では区別できなくなった。
- フィールドの追加削除が自由にできるようになった。
protocolbufferをつかわなくてもlanguage guideは読んでおくとよい。
ガイドラインを読んでおくとたいていの罠を回避できる。

[2016-11-27 14:44]

Q: Thriftではrequiredで送ってoptionalで受け取るのができるが? protobufではどうなっている?
A: protobufでもできるが基本的にやらない。バージョンが戻るときもあるし。
Q: jsonと変換するときにIDLは必要?
A: 自動生成されるコードにIDL相当の情報が入っているので不要らしい。

[2016-11-27 14:49]

10分休憩

[2016-11-27 15:00]

ZeroFormatter/MagicOnion / @neuecc

http://www.slideshare.net/neuecc/zeroformattermagiconion-fastest-c-serializergrpc-based-c-rpc
ググってもないよ。おれおれなので。C#
よのなかにフォーマットはいっぱいある。
パフォーマンスとは: 速度は実装に依存するので比較するときに注意。
スキーマレスならデバッグ耐性がある(ダンプしやすい).
バージョニング: キーに文字列をとるものは型の変更に追随しやすい。
古いandroidで速度が問題になることも。サイズが大きいと展開に数秒かかったり。圧縮すると遅くなるし。
ひらめいてzeroformatter開発 → deserializeしなければ速い!
- googleのflatbuffersを同じような仕様だがC#フレンドリーなのがちがう。
byte[]をかかえているだけ。プロパティにアクセスしたときに遅延評価でデシリアライズ。先頭にインデックスをおく。
あんがい全てのデータは必要ないことが多い。(マスタデータがでかいときとか). 簡易データベースとしてもつかえないこともない。
IDL不要。だいきらい。書きやすくない。シンタックスハイライトがない。コンパイラの力がつかえない。protobufでインデックスふるのやだ。
unionもサポートしてる。
ruby/swiftのフォーマッターを書いてくれる人も。
なぜRPCなのか?
- RESTで手書き。
- gRPCで自動生成。
- 自動生成はダルい!つらい! CIの自動化も複雑化の元。ミクロな自動化のせいでマクロがカオスに!
- C#のDLLにすれば外部スキーマが不要に。
- クライアント自動生成が残ってしまった。。。 → MagicOnion
MagicOninonはgRPCの上にC#のつかいやすさをくわいる。gRPC based C# Network Framework.
- 通信部分はあまりさわりたくない。
- gRPCはrpcの引数返り値をいちいち定義するのがダルい。
- skin layer: うすくラップする。
- gRPCはmarchalerを切り替えられるので、zeroformatterにかえてる。
C#で統一することでの強みがある。

[2016-11-27 15:30]

Q: 多言語に移植してほしい?
A: zeroformatterは移植してほしい。C#をIDLのようにつかってくれ!
Q: 互換性は?
A: フィールドを増やす方向は対応する。フィールド消すのは欠番で対応。運用で回避できる範囲。

[2016-11-27 15:33]

10分休憩

[2016-11-27 15:44]

Ad Serving System on Finagle and Thrift / @daimatz

https://speakerdeck.com/daimatz/ad-serving-system-on-finagle-and-thrift
フォーマットの話よりは運用面の話。
Finagleはtwitterが開発。 Your Service as a Funciton.
Futureはcomposableなのがcallbackとのちがい。
sequential composition: map, flatMap
consurrent composition: collect, join, select. selectは最初に終わったfutureをとりだして残りのfutureのseqを返す。
FinableのServiceはapply(req)がFuture(resp)を返すかたちになっている。
Thriftはfacebookがつくってopensource apache projectにしてまたfacebookがいじってるらしい(fbthrift)。
- プリミティブ:bool,byte,i16,i32,i64,double,binary,string
- ユーザ定義型: enum, struct, union, oneof
- コンテナ: optional, list, set, map
- protobufにくらべるとコンパクションは弱いかも。
DBとloggingでThriftをつかっている。
- bytesをBLOBとしてMySQLにつっこむ。JOINはアプリでがんばる。
DBをアップデート(データマイグレション)するときは、いちいち変換プログラムを書かないといけない。つらい。わりと似たようなことがおおい。 → カジュアルに変換スクリプト(ScalaScript)を書けるようにした。
社内のライブライをすべてつっこんだ fat-jar を用意。scalaのリフレクションもつかう。型チェックもはいるのでうれしい。
dashboardをつくってもその機能の管理画面をつくるまで余裕がない問題。→ ScroogeのparserをつかってASTを吐かせてHTMLフォームを自動生成。
cold dataはプロセス内でキャッシュ。redisへのアクセスを減らすが、master dataの更新はたまにはあるのでそのときはリロードする。
scorer: adサーバでさばききれないときにスコアリングしてくれる。
(インターネット越しの)外部のサーバに問い合わせることもある。いい広告がないときに提携している広告会社からもらうときに。
広告系ではオープンソースのを名前空間だけ変えてプロジェクトにつっこむということをよくやるが、バイナリサイズが大きくなってしまう。

[2016-11-27 16:29]

10分休憩

会場は25人くらい?

[2016-11-27 16:40]

CBOR RFC7049 / @fumieval

https://www.dropbox.com/sh/j9mt5i95mcf6e66/AADbnVJdhSyOe2c8vps_Q40Ka
鳥とコーヒーが好きな写真家
イラストレーターでプレゼン
Concise Binary Object Representation
encoder/decoderが簡潔にできるようにっている。スキーマレス。
http://cbor.me/
プリミティブは多め。
無限に長いものも扱える。
タグ付きオジェククト: オブジェクトに意味をつける。1は時刻とか、35が正規表現とか。
jqみたいなツールを開発中: cbor-tool
[2016-11-27 16:59] (発表者:あと何分? → 運営:時間決めてない)
実装はわりといっぱいある。 http://cbor.io/impls.html

[2016-11-27 17:03]

Q: RFCに書いてない独自のタグをつくるのはあり?
A: IANAに登録すればok! (あるいは55800以降をつかうか)
- http://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

[2016-11-27 17:05]

[2016-11-27 17:15]

Rustで非同期Thrift / @blackenedgold

https://keens.github.io/slide/RustdehidoukiThriftshitai/
「SAで広告部門なのでまるかぶりです」
RPC: 言語を跨げる + リモートで呼べる
protobufはJSONは効率2倍(cpu,mem,net)。
avroはプロトコルが柔軟?
Thriftは対応言語が豊富。
非同期重要。クライアントに届くまで80%は待ち時間。
thrust: コード生成がコンパイラプラグインになっているのがおもしろい
RPCはロードバランシングできない。クライアントはサーバにつないだらつなぎっぱなしになりがち。Finagleクライアントはfault-toleranceがある。
mioはlibeventのラッパーみたいなもの。ループ内でメモリallocしない。ソケット以外にもメモリチャンネルも監視できる。
zero-cost futures in Rust: コンパイル時に解決して状態マシンにしちゃう。型付けはたいへんなことになっている。
tokio-service: リクエストをもらってFutureをかえすtrait.
tokio-thrift: この発表のためにつくった。
ThriftでJSONはやめとけ。(出てくるデータが期待したものとちがって内部構造そのまま)
所有権とゼロコピー: parseするときにバッファをコピーしないようになっている。
複数メソッド: enum化しないといけないムダ。→懇親会で回避方法しってたらおしえて
コード自動生成の問題: 生成したコードもコミットしないといけない。コミットしないとツールのバージョンが変わったときにバグったり→バージョン指定するしか
多重化: pipelineとmultiplex. multiplexはシーケンス番号を振るのでオーバヘッドがあるし独自実装。
Thriftはストリーミング指向なのにtokio-thriftはバッファ持って何度もparseしちゃう?