---
title: "Alchemyが速度と信頼性のためにRPCをファインチューニングする方法"
description: "大きなRPCレスポンスの圧縮処理をサービングパスのより適切なレイヤーに移動し、重い呼び出しのP95レイテンシを削減し、コネクションの入れ替わりを減らしました。"
---

# Alchemyが速度と信頼性のためにRPCをファインチューニングする方法

<ImageBlock
  src="https://media.alchemy.com/blog/how-we-fine-tune-our-rpc-for-speed-and-reliability.png"
  alt="RPCの速度チューニング"
  width={1024}
  height={480}
  priority
/>

私たちは[パフォーマンス](https://www.alchemy.com/benchmarks)に強いこだわりを持っており、プラットフォームをさらに最適化するための調整を絶えず行っています。最近、プラットフォームが大きなRPCレスポンスを圧縮する方法を変更しましたが、その変更の一部がWorldchainに特に大きな影響を与えました。大きな呼び出しに対する圧縮レスポンスが約33%高速化され、これによりフルブロック読み取りなどの重い呼び出しが速くなり、パフォーマンスが安定し、トラフィック増加に対応する余地が増えました。

## GOAWAYフレームとは何か

HTTP/2でスループットの高いワークロードを運用しているなら、GOAWAYフレームを調べたことがなくても、その存在を知っているはずです。GOAWAYとは、サーバーがクライアントに対して、そのコネクション上で新しいストリームを開くのをやめるよう伝える信号で、通常はサーバーが負荷を軽減しようとしている際に送られます。クライアント側から見ると、GOAWAYの連続発生はコネクションの churn(入れ替わり)として現れます。ストリームが切断され、リクエストは新しいコネクション上で再試行され、テールレイテンシが上昇します。

GOAWAYが減るということは、[コネクションがより安定し](https://www.alchemy.com/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale)、再試行が減り、サービスが速くなることを意味します。したがって、あるカスタマーのGOAWAY数が急激に減少したときは、どこかの上流で余裕が大きく増えたということです。今回のケースでは、それはCPUでした。

## 圧縮処理がどこで行われていたか

私たちが返すすべてのRPCレスポンスは、ネットワークを離れる前に圧縮できます。ほとんどのHTTPクライアントは`Accept-Encoding: gzip`ヘッダーを送ることでこれを要求し、私たち自身の[node-gateway](https://www.alchemy.com/blog/migrate-self-hosted-nodes-dedicated-infrastructure)を含むほとんどのWebサーバーは、そのヘッダーを自動的に尊重します。これは私たちが構築した特別な機能ではなく、標準的な挙動です。フルブロック読み取りや大きな[`eth_getLogs`](https://www.alchemy.com/overviews/rpc-node)の結果セットのような大きなペイロードでは、圧縮によってネットワーク越しに送信されるバイト数が大幅に削減されます。インターネットの帯域幅は有限であるため、これは重要です。

node-gatewayで圧縮を行うことは、長い間理にかなっていました。node-gatewayはIOバウンドなサービスで、その時間の大半を、カスタマーからであれ私たち自身のノードからであれ、ネットワーク呼び出しの待機に費やすため、歴史的にCPUに余裕がありました。圧縮は[CPUバウンドな処理](https://www.alchemy.com/overviews/how-dedicated-blockchain-infrastructure-works)であり、そのコストはレスポンスサイズに応じて増大します。規模が大きくなるにつれ、圧縮はgatewayが行う中で最も忙しく、レイテンシに敏感なジョブの一つとなり、あらゆるリクエストをルーティングし処理するために必要な同じCPUを奪い合うようになりました。

gatewayが高負荷になると、それが行うすべてのことが同時に遅くなります。そして負荷がかかった状態でのgatewayへのCPU負荷こそが、まさにコネクションの遮断とGOAWAYフレームを引き起こす条件です。

## 何を変更したか

データ圧縮が行われる場所を、node-gatewayからサービスメッシュ内のIstioプロキシへと移動しました。node-gatewayはもはやレスポンスを圧縮しません。その処理は今では別のステップで、それにより適したインフラ上のIstioプロキシで行われます。これにより、Alchemyのnode-gatewayは速度と信頼性の最適化に専念でき、圧縮のステップはIstioが担当します。

結果として、カスタマーに届く圧縮レスポンス自体は同じですが、パフォーマンスを左右するホップ上でサイクルを奪い合うことなく、より効率的に処理できる場所で生成されるようになりました。スタックも出力も同じで、ただより適した場所で行われているだけです。

## これはあなたにとって何を意味するか

大きな呼び出しに対する圧縮レスポンスは今や約33%速く返ってくるようになりました(P95レイテンシは約35%改善)。これは3つの要素に分解できます。

**コネクションの安定化。** リクエストを処理するホップがCPUを奪い合っていなければ、負荷の遮断を行わなくなり、その結果GOAWAYが減り、切断されるストリームが減り、強制的な再試行も減ります。これがWorldchainで見られたことで、コネクションエラーが1時間あたり約1,500件から約100件に減少しました。

**重い呼び出しの高速化。** Istioプロキシで圧縮を処理することで、大きなレスポンスの最初のバイトがより早く送出されるようになります。フルブロック読み取りや大きな`eth_getLogs`の結果セットのような大きなペイロードでは、これによりレスポンスの最初のチャンクが届くまでの時間が短縮されます。

**下支えする余地の増加。** パフォーマンスを左右するまさにそのホップ上で、意味のあるCPU容量を解放しました。この改善はリクエストごとに効果を発揮するため、トラフィックが増加しても効果は持続します。恩恵を受けるために何かを変更する必要はありません。すでに、あなたが送るすべてのリクエストの下で機能しています。

## なぜ重要なのか

RPCプロバイダーを速く信頼性の高いものにしている要素の大半は、こうしたホップのように、あなたの目に触れない場所で起きています。一つのサービスが誤った処理を減らし、正しい場所で行うようにしただけで、コネクションの安定化とレスポンスの高速化が一夜にしてもたらされ、カスタマー側で何かを変更する必要は一切ありませんでした。

これは、私たちのサービングパスを改善し続ける取り組みの中の一つの変更にすぎません。[Alchemyで構築を始める](https://www.alchemy.com/contact-sales)。