P1110352x

[2016-11-27 13:47]

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

P1110351P1110354xP1110355x

[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をさくっと対応
  • 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人くらい?

P1110356x

[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]

[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しちゃう?

[2016-11-27 17:43]

↓LT

API for Front-end / @koba789

[2016-11-27 17:49]

[2016-11-27 17:50]

Web APIでThriftをシリアライザとして使う / @h_kishi

  • http://www.slideshare.net/h_kishi/20161127-web-apithrift
  • JSONつらみ: パフォーマンスでないメモリ食う長期運用してるとフィールドの意味がわからなくなったり
  • 今回はthriftを選定したがprotobuf v3もよさげ。
  • プルリクエストベースでフィールド追加の依頼ができるメリット。
  • チート対策: デシリアライザを難読化
  • IDL書くのメンドクサイがチームが大きくなるとメリットあるはず。

[2016-11-27 17:58]

  • Q: 難読化: スマホアプリで名前がまるみえ(リリース前の秘密の機能がみえちゃう), protobufだとproguardかけるときれいに消えるがthriftではどう?
  • A: 知らず。リフレクションをつかっているところがあるのでムリかも。

[2016-11-27 18:00]

Closing

  • ドワンゴ会場よかった
  • 「みなさんslideshareやspeakerdeckにアップロードしてくれてますがニコナレもあるのでよろしく」

[2016-11-27 18:03]

P1110359P1110360xP1110361P1110363

懇親会は参加せず帰宅。1階では結婚式?をやってた。帰りは雨だった。

センターのプロジェクタが暗いのがアレだな。前の席に座るか後ろに座って天井マウントの液晶ディスプレイみるかの二択。

参加59+発表7に対して実際に来たひとが30未満って、あまり人気のない話題だったのかもしれない。直前キャンセルもいっぱいあったみたいだし。