Yeap CDN の新しいエッジ：Rust を選んだ理由

この1年で、Yeap CDN のエッジを OpenResty（nginx と Lua）から、Rust で自社開発したエッジへ移行しました。基盤には、Cloudflare がオープンソース化したプロキシフレームワーク Pingora を使用しています。現在、トラフィックの大半は新しいエッジが処理しており、残りのノードも予定どおり切り替えを進めています。

この記事では内部実装の詳細は控え、次の問いにお答えします。新しいエッジによって、皆さまの Web サイトはどう変わるのでしょうか。

移行の理由

従来のエッジは、nginx の設定、Lua スクリプト、C モジュール、組み込み JavaScript エンジンを組み合わせた構成でした。高速ではありましたが、ドメインごとの機能を変更するたびに、複数の層を同時に修正する必要がありました。また、設定に誤りがあってもエラーにならず、気づかないうちに正常に動作しなくなることがよくありました。機能が増えるにつれ、より統一された信頼性の高い基盤が必要になりました。

Rust を選んだ理由は3つあります。

• メモリ安全性。 C コードのクラッシュや脆弱性の主な原因となるバッファオーバーフローやダングリングポインタを、言語自体の仕組みで防げます。
• 厳密な型を持つ設定。 各ドメインの設定は、ノードに届いた時点で検証されます。フィールド名のタイプミスや型の誤りは無視されず、明示的に拒否されます。
• テストのしやすさ。 エッジ全体を単一言語のプログラムとして実装し、毎回のリリース前に実行する1,000件以上の自動テストで検証しています。

利用時に感じられる変化

接続の高速化

新しいエッジは HTTP/3（QUIC）に対応しており、モバイルネットワークやパケット損失のある回線でも安定した性能を発揮します。TLS セッションチケットはノードの再起動後も有効なため、再訪問者はフルハンドシェイクを省略でき、最初の画面がより早く表示されます。

数秒で反映される設定

コンソールでキャッシュ、ファイアウォール、ページルールを変更すると、新しい設定は数秒以内にすべてのエッジノードへ届き、アトミックに切り替わります。処理中のリクエストは古い設定で完了し、新しいリクエストには新しい設定が使われます。ノードの再起動や接続の切断は発生しません。

きめ細かなキャッシュ制御

キャッシュキーでは、クエリパラメータの正規化、並べ替え、許可リスト、拒否リストを設定できます。パージでは、特定のパラメータを持つ1つのバリアントを削除することも、あるパスのすべてのバリアントを一括で削除することもできます。

エッジでのセキュリティ対策

WAF ルールセット、レート制限、ボットのフィンガープリント判定、地域や IP に基づくルールはすべてエッジで実行されるため、悪意のあるリクエストをオリジンに届く前に遮断します。遮断のたびに、適用されたルールとともにログが記録されます。

確実に分離されたエッジ関数

Edge Workers は個別の WebAssembly サンドボックスで動作し、実行ごとに専用のメモリと厳格な CPU 時間制限が設けられます。あるお客様のスクリプトが異常な動作をしても、ほかのお客様に影響を与えたり、ノードを停止させたりすることはありません。

どれくらい速いのか

実際のブラウザトラフィックに近い条件（TLS、HTTP/2、圧縮）では、新しいエッジは同等の設定の nginx よりも高いスループットと良好なテールレイテンシを実現します。主な理由は、圧縮済みのコンテンツをそのままキャッシュするため、キャッシュヒット時に再圧縮する必要がないことです。

この性能を実現するために、Pingora をブラックボックスとして扱うことはしませんでした。内部に踏み込んだカスタマイズを行い、どの CDN でも最も頻繁に実行されるキャッシュヒット時の処理経路を最適化しました。

利用者の変更作業が不要な移行

新旧のエッジは同じコントロールプレーンと設定を共有し、アクセスログの形式もすべてのフィールドが一致しています。お客様による変更は不要です。ドメイン、証明書、キャッシュルール、ファイアウォールルールは自動的に引き継がれます。

今後の予定

新しいエッジにより、これまで実装が難しかった多くのことが可能になりました。今後の記事では、HTTP/3 と TLS セッション再開の実装、個々のバリアントまで対象にできるキャッシュパージの仕組み、DNS がゾーンにネームサーバーを割り当てる方法をご紹介します。

まだお試しでない方は、コンソールでサイトを追加してみてください。無料の CDN プランも、すでに新しいエッジで動作しています。