---
title: "Webhooks・WebSockets・gRPCの比較"
description: "リアルタイムデータ配信を支配する3つのプロトコル。webhooks、WebSockets、gRPCの違い、それぞれが破綻する条件、そして選び方について解説します。"
---

# Webhooks・WebSockets・gRPCの比較

<ImageBlock
  src="https://media.alchemy.com/webhooks-vs-websockets-vs-grpc.png"
  alt="webhooks、WebSockets、gRPCによるリアルタイムデータ配信を比較するカバー画像"
  width={1920}
  height={900}
  priority
/>

ブロックチェーンデータを読み取るアプリケーションは、すべて同じアーキテクチャ上の問いに直面する。データをどうやってシステムに届けるかだ。数秒おきにAPIをポーリングすれば、計算資源を無駄にし、イベントを取りこぼし、レイテンシーが増える。代わりにデータをプッシュするなら、配信モデルを選ぶ必要がある。

リアルタイムデータ配信は主に3つのプロトコルが担っている。[webhooks](https://www.alchemy.com/overviews/what-is-a-webhook)、[WebSockets](https://www.alchemy.com/overviews/what-is-a-websocket)、gRPCだ。これらは互換性のあるものではない。webhookはバックエンドに何かが起きたことを通知する。WebSocketsはブラウザにライブデータをストリーミングする。gRPCはバックエンドサービス間で高スループットのデータ転送を行う。選択を誤ると、その代償は後になって現れる。イベントの取りこぼし、計算資源の浪費、予定になかったシステムの再設計だ。

## webhooks、WebSockets、gRPCとは何か

3つとも、ポーリングなしにサーバーからアプリケーションへデータを移動させる。共通点はそこまでだ。

[webhook](https://www.alchemy.com/webhooks)は通常のAPIの向きを逆転させる。コード側がサーバーを呼び出すのではなく、サーバーが関心のある出来事が発生するたびに、登録済みのURLをJSONペイロード付きで呼び出す。webhookの配線は単純だが、その代わりに届く内容やタイミングを自分では制御できない。

[WebSocket](https://www.alchemy.com/smart-websockets)はクライアントとサーバー間の永続的なTCP接続だ。どちらの側も、接続を再確立することなく、いつでも小さなバイナリフレームを送信できる。プロトコルはHTTPリクエストとして始まり、両者がアップグレードに合意した時点で生のソケットに切り替わる。

gRPCはリモートプロシージャコール(RPC)フレームワークであり、あるサービスが別のサービスの関数を、あたかもローカル関数を呼び出すかのように呼び出せるようにする仕組みだ。GoogleがStubby(社内RPCシステム)の公開後継として開発したgRPCは、HTTP/2上で動作し、データをProtocol Buffersでシリアライズし、完全な双方向を含む4種類のストリーミングモードをサポートする。構造化データをマシン間で高速に移動させるバックエンドサービス向けに構築されており、リトライ、デッドライン伝播、型付き契約が組み込まれている。

<EmbeddedTable
  table={{
    columns: [
      { key: "dimension", width: 180, title: "観点", dataType: "object" },
      { key: "webhooks", width: 220, title: "Webhooks", dataType: "object" },
      { key: "websockets", width: 220, title: "WebSockets", dataType: "object" },
      { key: "grpc", width: 240, title: "gRPC", dataType: "object" },
    ],
    data: [
      {
        dimension: { title: "プロトコル", tooltip: "", icon: "" },
        webhooks: { title: "HTTP POSTコールバック", tooltip: "", icon: "" },
        websockets: { title: "永続的TCP(<a href=\"https://www.rfc-editor.org/rfc/rfc6455.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 6455</a>)", tooltip: "", icon: "" },
        grpc: { title: "HTTP/2 + <a href=\"https://protobuf.dev/\" target=\"_blank\" rel=\"noopener noreferrer\">Protocol Buffers</a>", tooltip: "", icon: "" },
        id: 0,
      },
      {
        dimension: { title: "方向", tooltip: "", icon: "" },
        webhooks: { title: "サーバーから受信側へ(一方向)", tooltip: "", icon: "" },
        websockets: { title: "双方向", tooltip: "", icon: "" },
        grpc: { title: "双方向(4種のストリーミングモード)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        dimension: { title: "接続モデル", tooltip: "", icon: "" },
        webhooks: { title: "ステートレス(イベントごとに新規リクエスト)", tooltip: "", icon: "" },
        websockets: { title: "ステートフル(永続的)", tooltip: "", icon: "" },
        grpc: { title: "ステートフル(永続的、多重化)", tooltip: "", icon: "" },
        id: 2,
      },
      {
        dimension: { title: "データ形式", tooltip: "", icon: "" },
        webhooks: { title: "JSON", tooltip: "", icon: "" },
        websockets: { title: "JSONまたはバイナリ", tooltip: "", icon: "" },
        grpc: { title: "Protobuf(バイナリ)", tooltip: "", icon: "" },
        id: 3,
      },
      {
        dimension: { title: "メッセージごとのオーバーヘッド", tooltip: "", icon: "" },
        webhooks: { title: "500〜2,000バイト(HTTPヘッダー)", tooltip: "", icon: "" },
        websockets: { title: "2〜6バイト", tooltip: "", icon: "" },
        grpc: { title: "5バイトフレーム+圧縮ヘッダー", tooltip: "", icon: "" },
        id: 4,
      },
      {
        dimension: { title: "ブラウザサポート", tooltip: "", icon: "" },
        webhooks: { title: "該当なし(サーバー側)", tooltip: "", icon: "" },
        websockets: { title: "ネイティブ対応(99%以上)", tooltip: "", icon: "" },
        grpc: { title: "gRPC-Webプロキシが必要", tooltip: "", icon: "" },
        id: 5,
      },
      {
        dimension: { title: "配信保証", tooltip: "", icon: "" },
        webhooks: { title: "少なくとも1回(リトライあり)", tooltip: "", icon: "" },
        websockets: { title: "組み込みなし", tooltip: "", icon: "" },
        grpc: { title: "設定可能なリトライ+デッドライン", tooltip: "", icon: "" },
        id: 6,
      },
      {
        dimension: { title: "適した用途", tooltip: "", icon: "" },
        webhooks: { title: "イベント通知", tooltip: "", icon: "" },
        websockets: { title: "リアルタイムのブラウザUI", tooltip: "", icon: "" },
        grpc: { title: "サービス間パイプライン", tooltip: "", icon: "" },
        id: 7,
      },
    ],
  }}
/>

## webhooksはどのように機能するか

webhookはAPIモデルを逆転させる。サーバーを呼び出すのではなく、サーバーがあなたを呼び出す。プロバイダーにURLを登録し、どのイベントが重要かを伝え、あとは待つだけだ。何かが起きると、プロバイダーはエンドポイントにJSONをPOSTし、2xxのレスポンスを期待する。

<CodeSnippet
  language="javascript"
  code={`app.post('/webhook', (req, res) => {
  const sig = req.headers['x-alchemy-signature'];
  if (!verify(sig, req.rawBody, SECRET)) return res.status(401).end();
  queue.enqueue(req.body);
  res.status(200).end();
});`}
/>

上記のスニペットはwebhookハンドラーで、署名を検証し、ペイロードをキューに入れ、200を返す。この単純な形が、本番環境のwebhook障害の大半の元凶でもある。単純なハンドラーと本番用のハンドラーを分けるのは、単純な版が誤りやすい3つの点、署名検証、リトライ処理、バースト過負荷への対応だ。

1つ目の失敗パターンは、署名検証の甘さだ。プロバイダーは共有シークレットを使ってすべての配信にHMAC署名を付ける(Alchemyは`X-Alchemy-Signature`を使い、Stripeは`Stripe-Signature`を使う)。ハンドラー側はHMACを再計算し、タイミング攻撃を避けるために定数時間で比較し、タイムスタンプが5分より古いものは拒否する必要がある。`verify()`を呼び出すのは1行だが、正しく実装するには複数のステップがかかる。どれか一つでも省くと、エンドポイントのURLを知っている任意のプロセスを信頼することになる。

2つ目の失敗パターンは、リトライ時の非冪等な処理だ。配信が失敗すると(タイムアウト、部分的な障害、5xxレスポンス)、プロバイダーは指数バックオフ(通常1秒から倍々に増え、ジッターを加え、上限1時間)で数時間から数日にわたってリトライし、最終的にデッドレターキューに送る。webhookが保証するのは少なくとも1回の配信であって、正確に1回ではない([分散システムにおいて正確に1回の配信は不可能](https://en.wikipedia.org/wiki/Two_Generals%27_Problem))。したがって重複配信は日常的に発生する。ハンドラーは冪等でなければならない。同じイベントを2回処理しても、1回処理した場合と同じ結果になる必要がある。イベントIDを重複排除ストアで追跡し、繰り返しには200を返せばよい。

3つ目の失敗パターンはバースト過負荷であり、これが大規模なwebhookシステムを破綻させるものだ。単一のオンチェーンイベントが数百万件の同時配信を引き起こすことがある。エンドポイントがボトルネックになれば、プロバイダーのリトライキューがそのままDoS攻撃者と化す。

ブロックチェーンインフラでは、webhookがイベント駆動型ワークフローを支えている。当社の[Custom Webhooks](https://www.alchemy.com/docs/reference/notify-api-quickstart)は、30以上のEVMチェーンとSolanaにわたって、アドレスアクティビティの監視、NFT転送アラート、GraphQLでフィルタしたスマートコントラクトイベントをサポートし、すべてHTTP POSTコールバックとしてエンドポイントに配信する。

## WebSocketsはどのように機能するか

WebSocketは、`Upgrade: websocket`ヘッダーを含む通常のHTTPリクエストとして始まる。サーバーはHTTP 101(Switching Protocols)で応答し、その時点から接続はHTTPを話さなくなる。この折衝がWebSocketハンドシェイクだ。その後に残るのは、メッセージごとのヘッダーもリクエスト-レスポンスのサイクルもない、薄いフレーミング層を上に持つ生のTCPソケットだ。

HTTPを取り除くことで、WebSocketsはメッセージあたりのコストが劇的に下がる。各WebSocketメッセージのオーバーヘッドは[2〜6バイト](https://websocket.org/guides/websocket-protocol/)(FINビット、オペコード、ペイロード長)だ。これに対しHTTPでは、リクエストごとに数百バイトのヘッダーが付く。毎秒100メッセージの場合、WebSocketのオーバーヘッドは毎秒約600バイトなのに対し、同等のHTTPトラフィックでは毎秒60,000バイトになる。

<CodeSnippet
  language="javascript"
  code={`const ws = new WebSocket('wss://eth-mainnet.g.alchemy.com/v2/KEY');
ws.send(JSON.stringify({
  jsonrpc: '2.0', id: 1, method: 'eth_subscribe',
  params: ['newHeads']
}));
ws.on('message', (data) => handleBlock(JSON.parse(data)));`}
/>

[WebSocket](https://www.alchemy.com/docs/reference/webhook-types)接続はステートフルで長寿命だ。どちらの側も、相手を待たずにいつでもデータを送信できる。サーバーは定期的にpingフレームを送り、クライアントはpongフレームで応答して接続が生きていることを示す。このハートビートがなければ、切断済みの接続("ゾンビ")がサーバーリソースを消費し続け、リバースプロキシは30〜120秒でアイドル接続を切断する。

トレードオフとして、接続のライフサイクルを自分で管理する必要があり、そのライフサイクルは見た目以上に複雑だ。接続が切れると、クライアントは再接続しなければならないが、指数バックオフ(リトライ間隔を段階的に長くする)を伴わなければ、数千のクライアントが一斉に再接続してサーバーを圧倒してしまう。ロードバランサーの背後に複数のWebSocketサーバーを配置する場合、あるクライアントの再接続は必ず同じマシンにルーティングされなければならない。そのマシンがクライアントのサブスクリプション状態を保持しているからだ。このルーティングルールはセッションアフィニティと呼ばれる。さらに、あるサーバーで発生したメッセージが別のサーバーに接続しているクライアントに届く必要がある場合、サーバー間で状態を共有する必要がある。WebSocketsが提供するのはワイヤープロトコルであり、その上に構築するものはすべて自分で作らなければならない。

ブロックチェーンアプリケーションにおいて、[WebSockets](https://www.youtube.com/watch?v=hM1cf_7O2VY)はライブイベントのサブスクリプションにおける標準インターフェースだ。Ethereumの[eth_subscribeエンドポイント](https://www.alchemy.com/docs/reference/eth-subscribe)は、新しいブロックヘッダー、ログイベント、保留中のトランザクションを、永続的なWebSocket接続を通じてプッシュする。当社の[Smart WebSockets](https://www.alchemy.com/smart-websockets)は、基本プロトコルの上にフィルタ済みサブスクリプションと自動再接続を追加する。

ブラウザへのライブデータストリーミングは、WebSocketsが解決するために作られた問題だ。WebSockets以前の代替手段(ロングポーリング、サーバー送信イベント)は、メッセージごとにHTTPの全オーバーヘッドを払うか、一方向にしか動作しなかった。WebSocketsは、生のTCPソケットが通常存在できない場所、つまりブラウザにおいて、永続的で低オーバーヘッドな双方向接続を実現する。

その明快さは同時に限界でもある。WebSocketsは、消費者がブラウザでない場合、データが構造化されている場合、ボリュームが大きい場合、そしてWebSocketsが決して約束していないもの(型付きスキーマ、多重化されたストリーム、デッドライン伝播、バックプレッシャー)が必要な場合に苦戦する。それを解決するために作られたのがgRPCだ。

## gRPCはどのように機能するか

gRPCは設計空間の反対側から出発する。webhookがHTTPコールバックで、WebSocketsがTCP上の薄いフレーミング層であるのに対し、gRPCは中核に型付き契約を持つ完全なRPCフレームワークだ。ビジネスロジックを書く前に、サービスとそれが送受信するメッセージを定義する`.proto`ファイルを書く。protobufコンパイラがこのファイルを、自分の言語(スタブと呼ばれる)による生成済みのクライアントコードとサーバーコードに変換し、リモートメソッドの呼び出しがコード上ではローカル関数の呼び出しのように見えるようにする。

<CodeSnippet
  language="protobuf"
  code={`service Geyser {
  rpc Subscribe(stream SubscribeRequest)
    returns (stream SubscribeUpdate);
}`}
/>

トランスポート層はHTTP/2で、シリアライズにはProtocol Buffersが組み合わされる。両者が合わさることで、gRPCは典型的なREST + HTTP/1.1 + JSONスタックに対して3つの優位性を持つ。

- 多重化により、HTTP/1.1の問題であるヘッドオブラインブロッキング(1つの遅いレスポンスが同一接続上の後続リクエストすべてを詰まらせる問題)が解消される。gRPCでは、各呼び出しが同一のTCP接続を共有する独立したHTTP/2ストリームとして動作する。Squareは、接続オーバーヘッドを削減するために[内部のサービス間トラフィックをgRPCに移行した](https://grpc.io/about/)多くのエンジニアリングチームの一つだ。
- ヘッダー圧縮(HPACK)は、繰り返されるヘッダーをコンパクトな参照に置き換える。RPCトラフィックでは同じメソッド、コンテンツタイプ、認証ヘッダーが呼び出しごとに繰り返されるため、これによって[ヘッダーのオーバーヘッドが85〜90%削減](https://www.digitalocean.com/community/tutorials/http-1-1-vs-http-2-what-s-the-difference)される。
- Protocol Buffersはメッセージをテキストではなくコンパクトなバイナリにシリアライズする。ペイロードは非圧縮環境でJSONより34%小さく、デシリアライズは言語によっては[最大6倍高速](https://auth0.com/blog/beating-json-performance-with-protobuf/)になる。トレードオフとして、バイナリペイロードは人間が読める形式ではないため、トラフィックを確認するにはgrpcurlやPostmanのようなツールが必要になる。

gRPCは4種類のストリーミングモードをサポートする。単項(1リクエスト、1レスポンス)は通常のAPI呼び出しのように動作する。サーバーストリーミング(1リクエスト、複数レスポンス)はフィードやデータプッシュに向く。クライアントストリーミング(複数リクエスト、1レスポンス)はバッチアップロードを処理する。双方向ストリーミング(両側が独立して送信)はリアルタイムでステートフルなやり取りを実現する。

gRPCは汎用プロトコルではない。両端を自分で制御できるマシン間で構造化データを高頻度で移動させるバックエンドサービスに狭く最適化されており、その集中したニッチにおいてこそ、スキーマを書きコード生成を実行する初期コストが見合う。gRPCがこの地位を得ているのは、バイナリエンコーディングだけが理由ではなく、プロトコルに組み込まれた本番向けのプリミティブが理由でもある。[デッドライン伝播](https://grpc.io/docs/guides/deadlines/)は、すべてのタイムアウトを呼び出しチェーン全体を通過する絶対的な時点に変換する。サービスAが5秒のデッドラインを設定してサービスBを呼び出し、サービスBがサービスCを呼び出す場合、各ホップは残り時間を正確に把握できる。デッドラインが切れると、下流の作業はすべてキャンセルされ、リソースが解放される。[フロー制御](https://grpc.io/docs/guides/flow-control/)はHTTP/2から継承されており、消費側が遅い場合、送信側は自動的に速度を合わせて落とす。これは組み込みのバックプレッシャーであり、webhookもWebSocketsもネイティブでは提供していない。

[Solanaでは、gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc)が利用可能な最高性能のデータストリーミングを支えている。[Yellowstone gRPCプラグイン](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview)(Geyser)はバリデーターのメモリ空間に直接ロードされ、ディスクに書き込まれる前にアカウントやトランザクションの更新を捕捉し、protobufとしてシリアライズし、永続的なHTTP/2ストリームを通じてプッシュする。

## 3つのプロトコルはパフォーマンス面でどう比較されるか

スループットとレイテンシーのベンチマークは、サービス間通信について明確な線を引く。バイナリのprotobufエンコーディングとHTTP/2の多重化が組み合わさることで、gRPCはREST over HTTP/1.1よりも計測可能なほど高いスループットと低いレイテンシーを実現する。特にペイロードが小さく同時呼び出し数が多いワークロードで顕著だ。

WebSocketsは別の点で勝る。ブラウザ-サーバー間ストリーミングにおけるメッセージあたりのオーバーヘッドの低さだ。初回のハンドシェイクの後、各メッセージが運ぶフレーミングのオーバーヘッドは2〜6バイトで、ブラウザのネイティブWebSocket APIがプロキシやビルドツールなしに接続を扱う。

webhookはパフォーマンス向けに設計されていない。各配信は、完全な接続確立オーバーヘッドを伴う独立したHTTPリクエストだ。webhookが解決するのは別の問題、すなわちスループットよりも単純さと互換性を重視した、信頼性のある非同期イベント通知だ。

<EmbeddedTable
  table={{
    columns: [
      { key: "metric", width: 200, title: "指標", dataType: "object" },
      { key: "webhooks", width: 220, title: "Webhooks", dataType: "object" },
      { key: "websockets", width: 220, title: "WebSockets", dataType: "object" },
      { key: "grpc", width: 260, title: "gRPC", dataType: "object" },
    ],
    data: [
      {
        metric: { title: "メッセージあたりのレイテンシー", tooltip: "", icon: "" },
        webhooks: { title: "最も高い(完全なHTTPラウンドトリップ)", tooltip: "", icon: "" },
        websockets: { title: "低い(2〜6バイトのフレーム)", tooltip: "", icon: "" },
        grpc: { title: "最も低い(バイナリ+多重化)", tooltip: "", icon: "" },
        id: 0,
      },
      {
        metric: { title: "スループットの上限", tooltip: "", icon: "" },
        webhooks: { title: "HTTPオーバーヘッドに制限される", tooltip: "", icon: "" },
        websockets: { title: "単一ストリームでは高い", tooltip: "", icon: "" },
        grpc: { title: "最も高い(多重化されたストリーム)", tooltip: "", icon: "" },
        id: 1,
      },
      {
        metric: { title: "シリアライズコスト", tooltip: "", icon: "" },
        webhooks: { title: "JSONのみ", tooltip: "", icon: "" },
        websockets: { title: "JSONまたはバイナリ", tooltip: "", icon: "" },
        grpc: { title: "<a href=\"https://auth0.com/blog/beating-json-performance-with-protobuf/\" target=\"_blank\" rel=\"noopener noreferrer\">Protobuf: JSONより最大6倍高速</a>", tooltip: "", icon: "" },
        id: 2,
      },
      {
        metric: { title: "接続確立", tooltip: "", icon: "" },
        webhooks: { title: "イベントごと(または接続の再利用)", tooltip: "", icon: "" },
        websockets: { title: "1回のみ、その後は永続的", tooltip: "", icon: "" },
        grpc: { title: "1回のみ、その後は永続的+多重化", tooltip: "", icon: "" },
        id: 3,
      },
      {
        metric: { title: "バックプレッシャー", tooltip: "", icon: "" },
        webhooks: { title: "なし(受信側が吸収するか失敗する)", tooltip: "", icon: "" },
        websockets: { title: "組み込みなし", tooltip: "", icon: "" },
        grpc: { title: "組み込み(HTTP/2フロー制御)", tooltip: "", icon: "" },
        id: 4,
      },
    ],
  }}
/>

ブロックチェーン固有の数値もこの傾向を裏付けている。SolanaのYellowstone gRPCはスロットレイテンシー約5msでデータをストリーミングし、ネイティブのWebSocketsは約10ms、RPCポーリングは約150msと遅れをとる。プロトコルの複雑さが一段上がるごとに、計測可能な速度向上が得られる。

## 各プロトコルはどこで破綻するか

webhookは高頻度イベントで苦戦する。毎秒数百件の配信になると、コールバックごとのHTTPオーバーヘッドがボトルネックになる。バーストイベントはサンダリングハード問題を引き起こす。大規模なオンチェーンイベントが数百万件のwebhook配信を同時に引き起こし、プロバイダーのリトライキューと受信側のエンドポイントの両方を圧倒する。webhookはまた厳密に一方向だ。双方向通信が必要なユースケースには別のプロトコルが必要になる。webhookインフラを構築したあるエンジニアが[述べている](https://brandur.org/webhooks)ように、「webhookの運用はつらい」。

WebSocketsは規模が拡大すると苦戦する。各接続はサーバーリソースを保持する(アイドル時2〜10 KB、稼働時はさらに多い)。チューニングされたサーバーは[50万以上のアイドル接続](https://websocket.org/guides/connection-limits/)を扱えるが、本当のボトルネックは接続の入れ替わりだ。TLSハンドシェイクはCPUコア1つあたり毎秒1,000〜3,000件を消費する。サーバーが再起動すると、接続していたクライアントすべてが同時に再接続し、再接続の嵐が全体障害へと連鎖しうる。Solanaでは、標準的なWebSocket実装が「負荷下で不安定になり」、パフォーマンスが低下し頻繁に切断が発生したため、Solanaチームはこれを機にgRPCへと移行した。

gRPCはブラウザの端で苦戦する。ブラウザはネイティブでgRPCを話せない。[gRPC-Webプロトコル](https://github.com/grpc/grpc-web)はプロキシ(通常Envoy)を介してこの隙間を埋めるが、その過程でクライアントストリーミングと双方向ストリーミングを失う。バイナリのprotobufペイロードはcurlやブラウザのDevToolsで確認できないため、開発者体験が重要な公開向けAPIにはgRPCは向いていない。protobufのツールチェーン(スキーマ定義、コード生成、ビルド統合)は、単純な統合にとっては無視できないセットアップコストになる。

## webhooks、WebSockets、gRPCはどう選ぶべきか

まずユースケースが求める通信パターンから考える。

webhookがデフォルトの選択肢だ。バックエンドが離散的なイベント(トランザクションの確定、NFTの転送、支払いの完了)の発生を知る必要があり、イベントレートが毎秒数百件以下であれば、webhookはどの言語、どのフレームワーク、どのファイアウォールでも動作する最も低コストな統合方法だ。永続接続もストリーミングインフラもクライアントSDKも不要だ。

イベントレートが上がる、あるいはデータが双方向に流れる必要がある場合は、WebSocketsが担う。ライブ価格ティッカー、オーダーブックの更新、メンプール監視、共同編集ダッシュボードなど、ブラウザへの永続接続がAPIへの過剰なアクセスを避ける場面を思い浮かべればよい。ネイティブなブラウザサポート、プロキシ不要、バイト単位のフレームオーバーヘッドだ。

バックエンドサービス間で最大限のスループットが必要な場合はgRPCを選ぶ。インデクサーのパイプライン、バリデーターデータのストリーミング、マイクロサービス間通信、そして接続の両端を自分で制御できるワークロードは、バイナリシリアライゼーション、多重化されたストリーム、型付き契約、組み込みのバックプレッシャーから恩恵を受ける。ネックとなるのはツールチェーンだ。protobufスキーマ、コード生成、ネイティブなブラウザサポートの欠如。パフォーマンスと信頼性がセットアップの複雑さを上回るなら、その価値はある。

アーキテクチャが求めるなら、これらを組み合わせる。多くの本番システムは3つすべてを使う。gRPCがバリデーターからインデクサーへデータをストリーミングし、WebSocketsが処理済みデータをブラウザダッシュボードにプッシュし、webhookが離散イベントを外部システムに通知する。単一のプロトコルにすべてを賭ける理由はない。

<EmbeddedTable
  table={{
    columns: [
      { key: "useCase", width: 280, title: "ユースケース", dataType: "object" },
      { key: "protocol", width: 180, title: "推奨プロトコル", dataType: "object" },
      { key: "why", width: 320, title: "理由", dataType: "object" },
    ],
    data: [
      {
        useCase: { title: "トランザクション確定アラート", tooltip: "", icon: "" },
        protocol: { title: "Webhooks", tooltip: "", icon: "" },
        why: { title: "離散イベント、単純な統合、少なくとも1回の配信", tooltip: "", icon: "" },
        id: 0,
      },
      {
        useCase: { title: "取引UIにおけるライブ価格フィード", tooltip: "", icon: "" },
        protocol: { title: "WebSockets", tooltip: "", icon: "" },
        why: { title: "ブラウザへの継続的なデータ、低レイテンシー、双方向", tooltip: "", icon: "" },
        id: 1,
      },
      {
        useCase: { title: "Solanaバリデーターデータパイプライン", tooltip: "", icon: "" },
        protocol: { title: "gRPC", tooltip: "", icon: "" },
        why: { title: "最大スループット、バイナリシリアライゼーション、バックプレッシャー", tooltip: "", icon: "" },
        id: 2,
      },
      {
        useCase: { title: "Ethereumの新規ブロックサブスクリプション", tooltip: "", icon: "" },
        protocol: { title: "WebSockets", tooltip: "", icon: "" },
        why: { title: "標準的なeth_subscribeインターフェース、ブラウザ互換", tooltip: "", icon: "" },
        id: 3,
      },
      {
        useCase: { title: "バックエンドのマイクロサービス間通信", tooltip: "", icon: "" },
        protocol: { title: "gRPC", tooltip: "", icon: "" },
        why: { title: "型付き契約、多重化、デッドライン伝播", tooltip: "", icon: "" },
        id: 4,
      },
      {
        useCase: { title: "サードパーティ統合のコールバック", tooltip: "", icon: "" },
        protocol: { title: "Webhooks", tooltip: "", icon: "" },
        why: { title: "汎用的なHTTP互換性、永続接続不要", tooltip: "", icon: "" },
        id: 5,
      },
    ],
  }}
/>

## Alchemyでリアルタイムのブロックチェーンデータを扱う

当社は[100以上のチェーン](https://www.alchemy.com/rpc)にわたって3つすべてのプロトコルをサポートしている。

当社の[Custom Webhooks](https://www.alchemy.com/webhooks)は、トランザクション確定、アドレスアクティビティ、NFTイベントを、HMAC署名検証と自動リトライ付きのHTTP POSTコールバックとして配信する。GraphQLフィルタを使えば、アプリケーションに必要なコントラクトイベントだけを正確に購読できる。

[Smart WebSockets](https://www.alchemy.com/smart-websockets)は、フィルタ済みのeth_subscribeストリームを、自動再接続とレイテンシー削減付きで、リアルタイムのフロントエンドアプリケーション向けに提供する。

大量データを処理するSolanaチーム向けに、当社の[Yellowstone gRPCストリーミング](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview)は、バリデーターのメモリから直接アカウント更新とトランザクションを10ms未満のレイテンシーで配信する。

3つすべて無料プランで利用できる。契約もウェイトリストも不要だ。[サインアップ](https://dashboard.alchemy.com/signup)して数分でストリーミングを始めよう。

## よくある質問

### webhooks、WebSockets、gRPCの主な違いは何か

webhookはサーバー間のイベント通知向けの一方向HTTPコールバックであり、WebSocketsはクライアントとサーバー間の永続的な双方向接続を提供し、gRPCは型付き契約を備えた高スループットのサービス間通信向けに設計されたHTTP/2上のRPCフレームワークだ。

### WebSocketsやgRPCの代わりにwebhookを使うべきなのはどんな時か

トランザクション確定やNFT転送のような離散的なイベント通知が毎秒数百件未満のレートで必要で、永続接続を必要としない場合はwebhookを使う。専用のクライアントSDKやインフラを必要としない、最も単純な統合方法だ。

### WebSocketsがより良い選択肢になるのはどんな時か

WebSocketsは、ライブ価格ティッカー、オーダーブックの更新、ダッシュボードなど、ブラウザクライアントへの継続的なリアルタイムデータストリーミングに最適だ。最初のハンドシェイクの後は、ネイティブなブラウザサポートと低いメッセージあたりのオーバーヘッド(2〜6バイト)を提供する。

### gRPCはどのような問題を解決するために設計されているか

gRPCは、インデクサーのパイプラインやバリデーターデータのストリーミングなど、構造化データを高頻度で移動させるバックエンドサービス向けに最適化されている。バイナリシリアライゼーション、多重化されたストリーム、Protocol Buffersによる型付き契約、組み込みのバックプレッシャー、デッドライン伝播を提供する。

### webhooks、WebSockets、gRPCを同じシステム内で組み合わせて使えるか

はい、多くの本番システムはこの3つすべてを組み合わせている。バックエンドのサービス間通信にはgRPC、ブラウザへのリアルタイム更新にはWebSockets、外部システムへの離散イベント通知にはwebhookを使う。それぞれのプロトコルが異なるアーキテクチャ層を解決する。

### これらのプロトコル間のパフォーマンスの違いは何か

gRPCはバイナリエンコーディングとHTTP/2の多重化により最も低いレイテンシーと最も高いスループットを実現し、WebSocketsはブラウザストリーミング向けに低いオーバーヘッド(メッセージあたり2〜6バイト)を提供し、webhookは完全なHTTPラウンドトリップのオーバーヘッドのためメッセージあたりのコストが最も高いが、パフォーマンスよりも単純さを優先する。

### 各プロトコルの主な欠点は何か

webhookは高頻度イベントとバーストトラフィックに苦戦し、WebSocketsは接続の入れ替わりとサンダリングハード型の再接続の嵐によるスケーリング上の課題に直面し、gRPCはprotobufツールチェーンのセットアップが必要で、ネイティブなブラウザサポートを欠き、Webクライアント向けにはプロキシ(gRPC-Web)が必要になる。

### Alchemyはブロックチェーンアプリケーション向けにこれらのプロトコルをどのようにサポートしているか

Alchemyは、100以上のチェーンにわたるイベント通知向けのCustom Webhooks、自動再接続付きのフィルタ済みeth_subscribeストリーム向けのSmart WebSockets、そしてバリデーターのメモリから直接10ms未満のレイテンシーでアカウント更新を配信するSolana向けのYellowstone gRPCストリーミングを提供している。