バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 / understanding gob encoding

Go Conference 2024 の発表資料
Room1 15:50~

Transcript

1. バイナリを眺めてわかる gob encoding の仕様と性質、適切な使い方 2024/06/08 Go Conference 2024
2. 自己紹介 @convto 株式会社LayerX所属 レイヤ低めの技術などに興味がありま す (読みはこんぶとです)
3. はじめに - この発表は積極的に gob の採用を勧めているわけではありません！ - ちゃんとシステム性質に合わせて判断できることが一番望ましく、そのた めに詳細な理解が必要！という主張です - この発表では、仕様を深掘りして性質を評価する過程をみんなで楽しめれ ばと思っています - もちろん評価した上で用途に合うケースがあるなら、どんな技術であれ自 信を持って採用すると良いと思います
4. はなすこと - gobの概要, モチベーション紹介 - message encoding 評価の観点整理 - バイナリを見ながらgob仕様を深掘り - gobの評価 - まとめ
5. gobの概要, モチベーション紹介
6. gob ってなに？ - データのエンコーディングのひとつ！ - 有名なのは json, xml, protobuf(wire), など... - Go が標準パッケージで実装してる独自のエンコーディング！
7. gob ってなに？ - データのエンコーディングのひとつ！ - 有名なのは json, xml, protobuf(wire), など... - Go が標準パッケージで実装してる独自のエンコーディング！ なんで独自のものが 必要だったの？
8. https://go.dev/blog/gob go blog に詳しい
9. gob のモチベ - Go のプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - 自己言及的 (self-describing) であること - Protobuf での学びを取り込むこと
10. gob で達成したかったこと - Go のプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - 自己言及的 (self-describing) であること - Protobuf での学びを取り込むこと 少し解説
11. 自己言及的 (self-describing) であるとは - メッセージ自身にどのような構造をしているかについての情報が含まれて いること - 構造を復元できるメタ情報を body に持っていると言い換えられる
12. 自己言及的 簡易的な例 - 右のような構造は自己言及的 - type の解釈だけルールを決めてお けば、何が来ても値を受け取れる
13. 自己言及的でなにがうれしいの？ - メッセージ一つで構造が解釈可能 - 事前に準備するものも不要 - 埋め込む情報の量によっては高度 に元の状態を再現できる
14. Protobuf で学んだこととは？ - Go では struct 定義でしか動作しないこと - proto2 required は後方/前方互換担保を難しくした - required 実装を追加すると server/client 間で互換が壊れる - proto2 では default を設定できたが、実装や挙動が複雑になる - type ごとのゼロ値のような概念の方が取り回しやすい
15. Protobuf で学んだこととは？ - Go では struct 定義でしか動作しないこと - proto2 required は後方/前方互換担保を難しくした - required 実装を追加すると server/client 間で互換が壊れる - proto2 では default を設定できたが、実装や挙動が複雑になる - type ごとのゼロ値のような概念の方が取り回しやすい proto3 で解決されてるのでちょっと古い
16. 現代的な観点でみたときの良いところ - Goのプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - self-describing であること - struct 必須など, 利用する encoding によって構造の持ち方が制限さ れない
17. 現代的な観点でみたときの良いところ - Goのプログラム上から特別な宣言なしに利用できる - バイナリエンコーディングで情報の転送効率がよいこと - self-describing であること - struct 必須など, 利用する encoding によって構造の持ち方が制限さ れない これらを全て満たすエンコーディングはない！ので作った
18. message encoding 評価の観点整理
19. メッセージエンコーディングの性質いろいろ - パフォーマンス - サイズ - 後方/前方互換性 - 自己言及的 (self-describing) であるか - エコシステム - etc …
20. 今回は以下の観点で gob を評価 - パフォーマンス - サイズ - 後方/前方互換性 - 自己言及的 (self-describing) であるか - エコシステム - etc …
21. バイナリを見ながら gob仕様を深掘り
22. ざっとバイナリをみてみる
23. ざっとバイナリをみてみる
24. ざっとバイナリをみてみる
25. 型情報がそのまま埋められてそう ざっとバイナリをみてみる
26. 型情報がそのまま埋められてそう 終端がありそう ざっとバイナリをみてみる
27. ざっとバイナリをみてみる 型情報がそのまま埋められてそう 終端がありそう このへんにメッセージ内容がいそう 型情報は最初の一回しか送らなそう
28. 雰囲気で感じ取れること - ぱっとみ型情報をゴリっと送ってそう - 同一 stream 上だと最初の一回しか型を送ってなさそう - 明らかに終端っぽいやつがいそう - フィールド名とかを構造としてベタっと送ってるので、Protobuf (wire) み たいに field num 同じなら名前変えても無問題！とはならなさそう
29. 仕様をみてみる - https://pkg.go.dev/encoding/gob#hdr-Encoding_Details あたりを みてみる - ボトムアップで説明してるので、このドキュメントだけでは全体像はわから ない感じ。実装に眼を通す必要がありそう
30. いい感じの summary を発見 https://pkg.go.dev/encoding/gob#hdr-Encoding_Details
31. こんな感じそう
32. cnt: 36 こんな感じそう
33. cnt: 36 こんな感じそう
34. cnt: 36 id: -64 こんな感じそう
35. cnt: 36 id: -64 符号付き int は2の補数表現と 異なる形式で扱われています 取り扱いがすこし面倒なため ここでは飛ばします (後ほど説明します) こんな感じそう
36. 思い出そう https://pkg.go.dev/encoding/gob#hdr-Encoding_Details id が負数なら型情報了解！
37. cnt: 36 id: -64 wireType こんな感じそう
38. cnt: 14 cnt: 36 id: -64 wireType こんな感じそう
39. cnt: 14 cnt: 36 id: -64 wireType こんな感じそう
40. cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id: 64 こんな感じそう
41. 思い出そう https://pkg.go.dev/encoding/gob#hdr-Encoding_Details id が正なら値了解！
42. cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id: 64 wireType value こんな感じそう
43. cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id: 64 wireType value cnt: 13 cnt: 1 id: 64 value こんな感じそう
44. こんな感じそう cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id: 64 wireType value cnt: 13 cnt: 1 id: 64 wireType と value の詳細がわかれば勝てそう value
45. debug 用のよさげな内部実装を発見 - 構造をパースして良さげに出力する debug 用の実装を発見 - みるかぎり単純に端っこから consume していって解釈してるだ けでとても読みやすい - この実装を追えば wireType と value の詳細がわかりそう！
46. cnt: 36 id: -64 wireType まずは wireType から読み取るぞ！ この先スペースなさすぎに つきレイアウト変更
47. cnt: 36 id: -64 wireType id が負数なら type def と判断 debug 実装
48. cnt: 36 id: 64 wireType type def なら以下みたいな構造で パースされる(gob pkg で定義)
49. cnt: 36 id: 64 wireType 初期値 -1 で delta encoding されると 仕様で言及されてる debug 実装もそうなってる
50. cnt: 36 id: 64 wireType 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！ type def なら以下みたいな構造で パースされる(gob pkg で定義)
51. cnt: 36 id: 64 wireType 今回は StructT や！ 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！
52. cnt: 36 id: 64 wireType 今回は StructT や！ 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！ debug 実装も 2 なら struct として食べ てる
53. cnt: 36 id: -64 wireType struct type はこんな感じ 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！
54. cnt: 36 id: -64 wireType 説明のために簡略化してまとめるとこ んな感じ！ 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！
55. cnt: 36 id: -64 wireType 説明のために簡略化してまとめるとこ んな感じ！ 0b11 = 3 delta encoding 初期値 -1 を考えて, field_number: 2 を表現 structType である！ いまここ！
56. cnt: 36 id: -64 wireType ← の 1byte から 大まかな構造が わかる！ 説明のために簡略化してまとめるとこ んな感じ！ いまここ！
57. cnt: 36 id: -64 wireType 0b1 = 1 delta encoding 初期値 -1 を考えて, field_number: 0 説明のために簡略化してまとめるとこ んな感じ！ いまここ！
58. cnt: 36 id: -64 wireType 0b1 = 1 delta encoding 初期値 -1 を考えて, field_number: 0 説明のために簡略化してまとめるとこ んな感じ！ いまここ！
59. cnt: 36 id: -64 wireType 0b100 = 4 len: 4 string はよくある len が先に来て そのあと val があるパターン debug 実装
60. cnt: 36 id: -64 wireType 眼力で `item` とわかる string はよくある len が先に来て そのあと val があるパターン debug 実装
61. cnt: 36 id: -64 wireType 眼力で `item` とわかる ほんとはこれがある → string はよくある len が先に来て そのあと val があるパターン debug 実装
62. cnt: 36 id: -64 wireType = item ようはこう 眼力で `item` とわかる
63. cnt: 36 id: -64 wireType 次は id 0b1 = 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
64. cnt: 36 id: -64 wireType 次は id いまここ！ 0b1 = 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
65. cnt: 36 id: -64 wireType 取り出して先頭bitが立ってなければ val 返す 立ってたら符号反転したものが len 数値も len のあと val っぽい ちょっと癖ある
66. cnt: 36 id: -64 wireType 取り出して先頭bitが立ってなければ val 返す 立ってたら符号反転したものが len 数値も len のあと val っぽい ちょっと癖ある 先頭bitが立ってるので len を表す int8(uint8(0xff)) = -1 反転して 1 len: 1
67. cnt: 36 id: -64 wireType とった len で値を読む (複数桁あったらいい感じに加算) int だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ
68. cnt: 36 id: -64 wireType 1bit 右shift 末尾が立ってないからそ のまま 0b01000000 = 64 id: 64 とった len で値を読む (複数桁あったらいい感じに加算) int だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ
69. cnt: 36 id: -64 wireType 1bit 右shift 末尾が立ってないからそ のまま 0b01000000 = 64 id: 64 とった len で値を読む (複数桁あったらいい感じに加算) int だったら最下位bitが立ってたら反転 zigzag encoding ぽいかんじ gob の数値は全部これ これで飛ばしてた 箇所も読める
70. cnt: 36 id: -64 wireType つぎは終端！common type おわり！
71. cnt: 36 id: -64 wireType ようはこう Name = item Id = 64
72. cnt: 36 id: -64 wireType ようはこう 解決ずみ ✅ Name = item Id = 64
73. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b1 = 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
74. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0x10 = 2 先頭立ってないから そのまま値 len: 2
75. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b1 = 1 delta encoding 初期値 -1 を考慮して field_number: 0
76. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 0b100 = 4 len: 4
77. cnt: 36 id: -64 wireType つぎは field 眼力で `Name` 解決ずみ ✅
78. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 眼力で `Name`
79. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ ✅ 0b1 = 1 delta encoding 初期値 -1, 直前が0なので, field_number: 1
80. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ ✅ 0b1100 = 6 先頭立ってないから 値, 末尾0で反転なし val: 6
81. cnt: 36 id: -64 wireType つぎは field 解決ずみ ✅ 解決ずみ ✅ 終端
82. cnt: 36 id: -64 wireType つまりひとつめの field は... 解決ずみ ✅ 解決ずみ ✅ 終端 Name = Name Id = 6
83. cnt: 36 id: -64 wireType つまりひとつめの field は... 解決ずみ ✅ 解決ずみ ✅ 終端 Name = Name Id = 6 👍
84. cnt: 36 id: -64 wireType ふたつめの field ！ (サボります) 解決ずみ ✅ 解決ずみ ✅ Name = Price Id = 4 終端
85. cnt: 36 id: -64 wireType ふたつめの field ！ (サボります) 解決ずみ ✅ 解決ずみ ✅ Name = Price Id = 4 終端 👍
86. cnt: 36 id: -64 wireType あとは終端！ 解決ずみ ✅ 解決ずみ ✅ 終端
87. cnt: 36 id: -64 wireType あとは終端！ 🎉🎉🎉🎉 終端
88. つぎは value を！ cnt: 14 cnt: 1 id: 64 value
89. cnt: 14 cnt: 1 id: 64 value 余談: さっき skip したこまいところもいまは読める 先頭立ってるから len, 符号反転して len: 1
90. cnt: 14 cnt: 1 id: 64 value 1bit 右 shift して 0b01000000 末尾0だから 64 余談: さっき skip したこまいところもいまは読める
91. cnt: 14 cnt: 1 id: 64 value id: 64 の構造は これ 構造をみていく
92. cnt: 14 cnt: 1 id: 64 value id: 64 の構造は これ 構造をみていく ようはこれがわかればよい
93. cnt: 14 cnt: 1 id: 64 value id: 64 の構造は これ id が負数でないので val で解釈 debug 実装
94. cnt: 14 cnt: 1 id: 64 value id: 64 の構造は これ wireType によってちょっと挙動がかわる debug 実装
95. cnt: 36 id: -64 wireType id: 64 はこんな感じの型だったのを思い出して 🎉🎉🎉🎉
96. cnt: 14 cnt: 1 id: 64 value id: 64 の構造は これ wireType によってちょっと挙動がかわる こっちを通る
97. cnt: 14 cnt: 1 id: 64 value どんな感じで評価する？ debug 実装
98. cnt: 14 cnt: 1 id: 64 value どんな感じで評価する？ debug 実装 delta encoding field num
99. cnt: 14 cnt: 1 id: 64 value どんな感じで評価する？ debug 実装 field num に登録された型でパース
100. cnt: 14 cnt: 1 id: 64 value Name field 0b1 = 1 delta encoding 初期値 -1 を考慮して field_number: 0
101. cnt: 14 cnt: 1 id: 64 value Name field len: 6
102. cnt: 14 cnt: 1 id: 64 value Name field Name: banana
103. cnt: 14 cnt: 1 id: 64 value Name field Name: banana 👍
104. cnt: 14 cnt: 1 id: 64 value Price field 0b1 = 1 delta encoding 初期値 -1, 直前0を考慮して field_number: 1
105. cnt: 14 cnt: 1 id: 64 value Price field 先頭bitが立ってるので len を表す int8(uint8(0xff)) = -1 反転して 1 len: 1
106. cnt: 14 cnt: 1 id: 64 value Price field 1bit 右shift 末尾が立ってないからそ のまま 0b01100100 = 100 val: 100
107. cnt: 14 cnt: 1 id: 64 value Price field 1bit 右shift 末尾が立ってないからそ のまま 0b01100100 = 100 val: 100 👍
108. cnt: 14 cnt: 1 id: 64 value item type の値を読み切った！！ 終端 🎉🎉🎉🎉
109. 宿題: 2こめの val 自分で読んでみてね cnt: 13 cnt: 1 id: 64 value
110. gobの性質の評価
111. 今回は以下の観点で gob を評価 - パフォーマンス - サイズ - 後方/前方互換性 - 自己言及的 (self-describing) であるか - エコシステム - etc …
112. 今回は以下の観点で gob を評価 性質 \ encoding gob json protobuf (wire) サイズ 前方/後方互換性 自己言及的か エコシステム
113. ざっくりこんなレイアウトだったのを思い出そう cnt: 14 cnt: 36 id: -64 wireType cnt: 1 id: 64 wireType value cnt: 13 cnt: 1 id: 64 value
114. 型定義も含むため val 1こなら json の方が安い
115. val 単体なら gob の方が安い
116. 単一 stream 内では型定義は 1つしか流れないの で stream で使おう！
117. サイズはこんな感じ 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 自己言及的か エコシステム
118. cnt: 36 id: -64 wireType 眼力で `Name` フィールド名を含めた型情報を持っている ことを思い出そう
119. フィールド名を変えると値が取れなくなる - のでおおよそ互換性については json と同じ性質を持っていそう - ただ gob はアプリケーション側の型の差分についてはわりといい感じにし てくれる - ポインタあるなしとか、フィールドなかったら単に無視とか - protobuf(wire) と違って具体的なフィールド名などが露出するので、命 名変えた時とかは気をつけないと過去のメッセージから値を取り出せない
120. 互換性 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か エコシステム
121. cnt: 36 id: -64 wireType 完全な型情報を持つことを思い出そう
122. 自己言及的か 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム
123. エコシステムは ...? - json はどこでも使える - protobuf(wire) は高度なエコシステムのサポートがある - 一方 gob は現時点で Go からしか使えない！ - 言語埋め込みだから実現できる高度な機能とのトレードオフ - 理屈上他言語にも実装できるから、どうしても困ったら最悪そうすればえ えかくらい
124. こうなった！ 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる
125. 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる gob はどういうときに使えるか
126. 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる これが許容できて gob はどういうときに使えるか
127. 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる この性質を強く 求めていて gob はどういうときに使えるか
128. 性質 \ encoding gob json protobuf (wire) サイズ 🔺 stream で上手 く使えば小さい ❌ 比較的大きい ⭕ 小さい 前方/後方互換性 🔺 Go の型は多少 うまくしてくれる ❌ なし ⭕ filed_num の み露出 自己言及的か ⭕⭕ 完全な型情 報を持ち実装の高 度なサポートあり 🔺~ ⭕ 構造の情 報あり 🔺 6種類くらいの 大まかな種別あり エコシステム ❌ Go だけ ⭕ どこでもOK ⭕ そこそこ使える し周辺ツールが発 展してる かつ json, protobuf (wire) の中間みたいな　 バランスが噛み合う用途 gob はどういうときに使えるか
129. gob はどういうときに使えるか - Go でしか使えない制約を受け入れられるとき - 検証用途のコードで使うとか - データライフサイクルが短いもの - キャッシュとか - RPC やりとりの encoding として - 後述するメリットとバランスがとれるとき
130. - Go でしか使えない制約を受け入れられるとき - 検証用途のコードで使うとか - データライフサイクルが短いもの - キャッシュとか - RPC やりとりの encoding として - 後述するメリットとバランスがとれるとき gob はどういうときに使えるか じつは標準の net/rpc と かでも使われてる
131. gob の嬉しい性質 - Go で完結してすぐ使えて嬉しい - 大抵嬉しいと思う - Go でしか使えないこととのトレードオフという感じ - そこそこ効率がよかったり、まあまあメッセージの互換性が取れることが嬉しい - デメリットとバランスするなら採用余地あり！
132. まとめ
133. まとめ - みんなでバイナリを読んで gob を完全理解しました - 大体どれもこんな感じなんで興味あったら protobuf (wire) の spec も読ん でみてください - encoding 仕様からいくつかの性質について整理した - gob が使えそうなところや, 採用した時の嬉しさを整理した - キャッシュやRPCにおすすめ - Go から便利に使えること, その他の性質が程よいところがメリット - pros/cons 整理してバランスするならいい選択肢
134. みんなでバイナリを読もう！
135. 完
136. ご清聴ありがとうございました