シリアライズの仕組み ― オブジェクトはどうやってバイト列になるのか

プログラムが動いてるとき、メモリ上にはオブジェクトっていうデータの塊があるんだけど、これはそのままだとファイルに保存したりネットワークで送ったりできないんだよ。シリアライズは、このオブジェクトを一列のバイト列に変換する処理のことだね。逆にバイト列からオブジェクトに戻すのがデシリアライズだよ。

そうだよ。JSONやXML、YAMLはテキストベースのシリアライズ形式だね。JSONは人間が読みやすくて、Web APIではほぼ標準。XMLはちょっと冗長だけどスキーマで厳密にデータ構造を定義できる強みがある。YAMLは設定ファイルでよく使われるね。テキスト形式は人が目で見て確認できるのが最大のメリットだよ。

バイナリ形式は人間には読めないけど、サイズが小さくて処理も速いのが特徴だよ。代表的なのはGoogleのProtocol Buffers（Protobuf）、MessagePack、Apache Avro、Apache Thriftあたりだね。例えば同じデータをJSONとProtobufで比べると、Protobufの方がサイズが30〜80%くらい小さくなることもあるよ。

まず .proto っていうスキーマファイルにデータ構造を定義するんだよ。例えば「Userというメッセージにはstring型のnameがフィールド番号1、int32型のageがフィールド番号2」みたいにね。これをprotocっていうコンパイラに通すと、各言語用のコードが自動生成される。フィールド番号がポイントで、データにはフィールド名じゃなく番号で格納されるから、とてもコンパクトになるんだ。

実はそこがProtobufの賢いところでね。フィールド番号さえ変えなければ、新しいフィールドを追加しても古いコードはそのフィールドを無視するだけだし、フィールドを削除しても新しいコードは「値がない」として扱うだけ。これをスキーマエボリューション、つまり前方互換性・後方互換性と呼ぶんだよ。マイクロサービスで各チームが独立してデプロイできるのはこの仕組みのおかげだね。

ざっくり言うと、データサイズはProtobufがJSONの1/3〜1/5くらい。MessagePackはJSONの半分くらいだね。シリアライズ・デシリアライズの速度もProtobufが最速で、JSONの2〜10倍速いケースが多いよ。MessagePackはスキーマ不要でJSONに近い使い勝手なのにバイナリで速い、というバランス型だね。

使い分けが大事なんだよ。JSONはWeb APIや設定ファイルに最適。人が読めるし、ブラウザがネイティブに対応してるからね。Protobufは社内のマイクロサービス間通信に向いてる。gRPCという高速なRPCフレームワークがProtobufを採用してるよ。Avroはスキーマをデータと一緒に保存できるから、HadoopやKafkaなどデータパイプラインで重宝されるんだ。

いい質問だね。デシリアライズの脆弱性は実はセキュリティの世界では超有名な問題なんだ。Javaの ObjectInputStream は信頼できないデータをデシリアライズすると、任意のコードが実行されてサーバーを乗っ取られる危険がある。実際に2015年のApache Commons Collectionsの脆弱性で大問題になったよ。

その通り。Pythonのpickleは「任意のPythonオブジェクトをシリアライズできる」という便利さの裏返しで、悪意あるpickleデータを読み込むとos.systemで任意のコマンドが実行できてしまうんだよ。だから公式ドキュメントにも「信頼できないデータにpickleを使うな」と書いてある。機械学習のモデルファイルでpickleが使われることが多いから、出所不明のモデルを読み込むのはリスクがあるね。

速さに加えて、スキーマ駆動開発ができる点が大きいんだよ。.protoファイルがサーバーとクライアントの契約書になるから、APIの仕様が曖昧にならない。さらにHTTP/2の上でストリーミング通信ができて、フィールド番号のおかげで後方互換性も担保できる。Log4Shellの根本原因の一つもJNDIルックアップ経由のデシリアライズだったけど、Protobufのように構造が厳密に定義された形式なら、そういう予期しないオブジェクト生成は起きにくいんだよ。型安全なシリアライズ形式を選ぶことが、セキュリティにも直結するってことだね。