Zenn
Open8

gRPCに入門する

ホークホーク

Protocol Buffersの特徴

  • gRPCのデータフォーマット
  • プログラミング言語からは独立
  • バイナリ形式にシリアライズされ、サイズが小さく高速な通信が可能
  • 型安全
  • json変換も可能

JSONとの違い

  • JSON
  1. 配列やネスト等の複雑な形式の取り扱いも可能
  2. フーマンリーダブル
  3. データスキーマを強制できない
  4. データサイズの巨大化
  • Protocot Buffers
  1. 複雑な形式には不向き
  2. バイナリ変換後には人間は読めない
  3. 型保証
  4. データサイズ小さめ

開発の進め方

  1. スキーマ定義
  2. 開発言語のオブジェクトを自動生成
  3. バイナリ形式へシリアライズ
ホークホーク

message

  • 複数のフィールドを持つことができる型定義
    • それぞれのフィールドはスカラ型もしくはコンポジット型
  • 各言語のコードとしてコンパイルした場合、構造体やクラスとして変換
  • 1つのprotoファイルに複数のmessage型を定義することも可能
ホークホーク

Tag

  • Protocol Bufferesではフィールド名ではなく、タグ番号によって識別される
  • 重複はダメ
  • 1-15までは1byteで表すことができるため表すことができるため、よく使うフィールドはこれらを割り当てる
ホークホーク

デフォルト値

  • string: 空文字列
  • bytes: 空byte
  • bool: false
  • 整数型・浮動小数点型: 0
  • 列挙型: tag番号0の値
  • repeated: 空のリスト
ホークホーク

gRPCとは

Remote Procedure Call

  • ネットワーク上の他の端末と通信
  • REST APIっぽくpathやmethodを指定する必要はない代わりに、メソッド名と引数を指定する
  • データフォーマットにProtocol Bufferを使用する
    • バイナリにシリアライズでシリアライズされることにより高速
  • IDLからサーバー・クライアントに必要なコードを自動生成
  • 通信にはHTTP/2を使用
ホークホーク

適するユースケース

  • micro service
    • 複数の言語、プラットフォームで構成される可能性
    • バックエンドであれば、gRPCの恩恵が大きい
  • 速度が要求される場合
ホークホーク

開発の流れ

  • protoファイルの流れ
  • protoファイルをコンパイルしてサーバー・クライアントの雛型を生成
  • 雛形を使用して実装
ホークホーク

HTTP/2について

HTTP/1.1の課題

  • リクエスト多重化
    • request:response = 1:1成約ゆえ、大量のリソースで構成されるページを表示するには大きなネックとなる
  • プロトコルオーバーヘッド
    • cookieやトークン等を毎度リクエストヘッダに付与してリクエストするためオーバーヘッドが大きくなってしまう

HTTP/2の特徴

  • ストリームという概念
    • 1つのTCP接続で複数のリクエスト/レスポンスのやり取りが可能
    • TCP接続回数が減らせる
  • ヘッダーの圧縮
    • HPAC圧縮方式で圧縮し、キャッシュすることで差分のみを送受信
  • サーバープッシュ
    • クライアントからのリクエストなしにサーバーからリクエストを送信できる
    • 事前に必要と思われるリソースを送信しておくことでラウンドどリック回数を削減