ecdysisによる古いコードの脱皮：CloudflareのRustサービスにおける優雅な再起動

ecdysisによる古いコードの脱皮：CloudflareのRustサービスにおけるグレースフルな再起動 ![](https://blog.cloudflare.com/cdn-cgi/image/format=auto,dpr=3,width=64,height=64,gravity=face,fit=crop,zoom=0.5/https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2uZSzrusd3hAe2Kvrmszdw/4a943f81c48a875d6bcf85cbfdb248d4/2490c1bf-8abb-4022-9821-bca06ab87b2d_224x224.png) Manuel Olguín Muñoz ecdysis | ˈekdəsəs | （爬虫類における）古い皮を脱ぐ、または（昆虫やその他の節足動物における）外殻を脱ぎ捨てるプロセス。 世界中で毎秒数百万リクエストを処理するネットワークサービスを、たった一つの接続も切断することなく、どのようにアップグレードすればよいでしょうか？ この巨大な課題に対するCloudflareでの解決策の一つが、長らくecdysisでした。これは、稼働中の接続が一つも切断されず、新しい接続も拒否されないグレースフルなプロセス再起動を実装するRustライブラリです。 先月、私たちはecdysisをオープンソース化しました。これで誰でも利用できるようになりました。Cloudflareでの5年間の本番運用を経て、ecdysisは、当社の重要なRustインフラストラクチャ全体でダウンタイムゼロのアップグレードを可能にし、Cloudflareのグローバルネットワークにおける各再起動ごとに数百万のリクエストを救うことで、その実力を証明しています。 特にCloudflareネットワークの規模では、これらのアップグレードを正しく行うことの重要性はいくら強調してもしすぎることはありません。当社のサービスの多くは、トラフィックルーティング、TLSライフサイクル管理、ファイアウォールルールの適用などの重要なタスクを実行しており、継続的に動作しなければなりません。これらのサービスの一つがダウンした場合、ほんの一瞬であっても、連鎖的な影響は壊滅的になり得ます。切断された接続と失敗したリクエストは、すぐに顧客のパフォーマンス低下とビジネスへの影響につながります。 これらのサービスに更新が必要な場合、セキュリティパッチは待てません。バグ修正はデプロイする必要があり、新機能はロールアウトされなければなりません。 単純なアプローチでは、古いプロセスが停止するのを待ってから新しいプロセスを起動しますが、これでは接続が拒否されリクエストがドロップされる時間の窓が生じてしまいます。一箇所で毎秒数千のリクエストを処理するサービスを、数百のデータセンターで掛け合わせれば、短い再起動が世界中で数百万の失敗したリクエストになるのです。 問題と、ecdysisがどのように私たちの解決策となったか（そしておそらくあなたにとってもそうなるかもしれないか）を掘り下げてみましょう。 リンク: GitHub | crates.io | docs.rs なぜグレースフルな再起動が難しいのか 前述のように、サービスを再起動する単純なアプローチは、古いプロセスを停止して新しいプロセスを起動することです。これはリアルタイムリクエストを処理しない単純なサービスでは許容範囲で機能しますが、ライブ接続を処理するネットワークサービスでは、このアプローチには重大な制限があります。 第一に、単純なアプローチでは、着信接続をリッスンするプロセスが存在しない時間の窓が生じます。古いプロセスが停止すると、そのリッスンソケットを閉じ、これによりOSは新しい接続をECONNREFUSEDですぐに拒否します。 第二に、古いプロセスを停止すると、すでに確立されたすべての接続が切断されます。大きなファイルをアップロードしているクライアントやビデオをストリーミングしているクライアントは、突然切断されます。WebSocketやgRPCストリームのような長寿命の接続は、操作の途中で終了します。クライアントの視点では、サービスが単に消えてしまいます。 古いプロセスをシャットダウンする前に新しいプロセスをバインドすれば、これは解決するように見えますが、同時に追加の問題も引き起こします。カーネルは通常、一つのプロセスだけがアドレス:ポートの組み合わせにバインドすることを許可しますが、SO_REUSEPORTソケットオプションは複数のバインドを許可します。しかし、これによりプロセス遷移時に問題が生じ、グレースフルな再起動には適さなくなります。 SO_REUSEPORTが有効な場合、複数のプロセスが同じアドレスとポートにバインドできます。しかし、カーネルはこれらのプロセス間で接続を分配します。古いプロセスが停止すると、そのプロセスに割り当てられていた接続はすべて切断されます。新しいプロセスは新しい接続を受け付けますが、古いプロセスに割り当てられていた既存の接続は失われます。これではグレースフルな再起動にはなりません。 ecdysisの仕組み ecdysisの設計と構築に着手した際、私たちはこのライブラリに対して4つの主要な目標を設定しました： アップグレード後、古いコードを完全にシャットダウンできること。 新しいプロセスには初期化のための猶予期間があること。 初期化中に新しいコードがクラッシュしても許容され、稼働中のサービスに影響を与えないこと。 連鎖的な障害を避けるため、並行して実行されるアップグレードは一つだけであること。 ecdysisは、初期の頃からグレースフルなアップグレードをサポートしてきたNGINXによって開拓されたアプローチに従い、これらの要件を満たします。そのアプローチは単純明快です： 親プロセスがfork()を呼び出して子プロセスを作成します。 子プロセスはexecve()で自身を新しいバージョンのコードに置き換えます。 子プロセスは、親と共有する名前付きパイプを介してソケットファイル記述子を継承します。 親プロセスは、シャットダウンする前に子プロセスが準備完了のシグナルを送るのを待ちます。 重要な点は、ソケットが遷移全体を通じて開いたままであることです。子プロセスは、名前付きパイプを介して共有されたファイル記述子として、親からリッスンソケットを継承します。子の初期化中、両プロセスは同じ基盤となるカーネルデータ構造を共有し、親は新しい接続と既存の接続の受け付けと処理を継続できます。子が初期化を完了すると、親に通知し、接続の受け付けを開始します。この準備完了通知を受け取ると、親は直ちに自身のリッスンソケットのコピーを閉じ、既存の接続の処理のみを継続します。 このプロセスにより、カバレッジのギャップを排除しつつ、子に安全な初期化ウィンドウを提供します。親と子の両方が同時に接続を受け付ける可能性がある短い時間の窓があります。これは意図的なものです。親によって受け付けられた接続は、ドレイン処理の一部として単純に完了まで処理されます。 このモデルはまた、必要なクラッシュ安全性も提供します。もし子プロセスが初期化中に（例えば設定エラーにより）失敗した場合、単に終了します。親はリッスンを止めていないため、接続は切断されず、問題が修正されればアップグレードを再試行できます。 ecdysisは、Tokioとsystemdを通じた非同期プログラミングのファーストクラスサポートを備えたフォークモデルを実装しています。 Tokio統合： Tokioのためのネイティブな非同期ストリームラッパー。継承されたソケットは追加のグルーコードなしでリスナーになります。同期サービスの場合、ecdysisは非同期ランタイム要件なしでの動作をサポートします。 systemd-notifyサポート： systemd_notify機能が有効な場合、ecdysisは親プロセスと子プロセスの両方でsd_notify(3)呼び出しを管理し、systemdに状態を通知します。これにより、サービスユニットでType=notify-reloadを使用できるようになり、systemdがアップグレードを追跡し、失敗した場合にサービスを再起動できるようになります。 systemd名前付きソケット： systemd_sockets機能が有効な場合、ecdysisはsystemdから継承されたソケットを自動的に検出し、それらを新しいプロセスに渡します。これにより、systemdのソケットアクティベーションメカニズムとシームレスに統合できます。 プラットフォームに関する注意： ecdysisは、ソケット継承とプロセス管理のためにUnix固有のシステムコールに依存しています。Windowsでは動作しません。これはフォーキングアプローチの根本的な制限です。 セキュリティ上の考慮事項 グレースフルな再起動はセキュリティ上の考慮事項を導入します。フォークモデルでは、2つのプロセス世代が共存する短い時間の窓が生じ、両方が同じリッスンソケットと潜在的に機密性の高いファイル記述子にアクセスできる状態になります。 ecdysisはその設計を通じてこれらの懸念に対処します： フォーク後実行： ecdysisは、fork()の直後にexecve()を呼び出すという伝統的なUnixパターンに従います。これにより、子プロセスは親のメモリ空間や実行状態を継承しません。子は新しいバイナリをゼロからロードします。 明示的な継承： リッスンソケットと通信パイプのみが継承されます。他のファイル記述子はCLOEXEC（exec時に閉じる）フラグによって閉じられます。これにより、子が意図せず機密性の高いファイル記述子にアクセスすることを防ぎます。 seccomp互換性： seccompフィルターを使用するサービスは、fork()、execve()、および関連するシステムコールを許可する必要があります。これは、フォーク実行モデルを使用するほとんどのサービスでは一般的な要件です。 ほとんどのネットワークサービスでは、これらのトレードオフは許容範囲内です。フォーク実行モデルのセキュリティは十分に理解されており、NGINXやApacheなどのソフトウェアで何十年にもわたって実戦でテストされています。 実用的な例を見てみましょう。以下は、グレースフルな再起動をサポートする簡略化されたTCPエコーサーバーです： use ecdysis::tokio_ecdysis::{SignalKind, StopOnShutdown, TokioEcdysisBuilder}; use tokio::{net::TcpStream, task::JoinSet}; use futures::StreamExt; use std::net::SocketAddr; #[tokio::main] async fn main() { // ecdysisビルダーを作成 let mut ecdysis_builder = TokioEcdysisBuilder::new( SignalKind::hangup() // SIGHUPでアップグレード/リロードをトリガー ).unwrap(); // SIGUSR1で停止をトリガー ecdysis_builder .stop_on_signal(SignalKind::user_defined1()) .unwrap(); // リッスンソケットを作成 - 子プロセスに継承される let addr: SocketAddr = "0.0.0.0:8080".parse().unwrap(); let stream = ecdysis_builder .build_listen_tcp(StopOnShutdown::Yes, addr, |builder, addr| { builder.set_reuse_address(true)?; builder.bind(&addr.into())?; builder.listen(128)?; Ok(builder.into()) }) .unwrap(); // 接続を処理するタスクをスポーン let server_handle = tokio::spawn(async move { l

ecdysisによる古いコードの脱皮：CloudflareのRustサービスにおける優雅な再起動

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト