FastCommentsの自動ルーティング輸送システム

はじめに

FastCommentsの自動ルーティング輸送システム（FARTS）は、私たちの輸送およびサービスレイヤーです。FARTSは、混雑を解消し、ユーザーの位置情報に基づいてトラフィックをルーティングします。将来的には負荷に応じたルーティングも可能になるでしょう。これは、地理に基づいたDNSレイヤー、DBプロキシ、DBレプリケーション、SSL証明書管理、リバースプロキシ、エッジでアセットをキャッシュするためのオンディスクLRUキャッシュを使用するCDNなど、いくつかの異なるシステムで構成されています。

アクティブ-アクティブ

FARTの最新バージョンには、データベース用の組み込みプロキシおよびレプリケーションレイヤーが含まれています。これにより、FastCommentsはアクティブ-アクティブになり、グローバルな書き込み可用性を確保し、FARTSが最終的に一貫性を持つことを保証します。詳細はこちら。

実際に私たちが初期に取ったアプローチの一つは、MongoDBのアクティブ-アクティブフォークを作成できるかどうかを調べることでした。私たちのエンジニアの一人（Sloperators）は、Opus 4.6を使用してこれを達成することができましたが、私たちはこれを行うリスクが独自の隔離されたシステムを構築するよりも高いと判断しました。

スケールでのRust

FARTを作成する動機の一部は、Javaで書かれた既存のサービスを置き換えることでした。しばらく考えた後、私たちはこれらを1つのRustサービスに統合してランタイムオーバーヘッドを減らすことにしました。頻繁にFARTを展開しないため、これは許容できるトレードオフでした。FARTはLTOでコンパイルされているため、本当に自由に動作させることができます。

私たちは、異なるGCなどを使用して古いJavaシステムをチューニングするのに多くの時間を費やしましたが、最終的にはasync Rust + Mimallocの方が同じハードウェアでかなり性能が良く、メモリ要件もかなり低いため、切り替えは容易でした。

Rustは、共有ヒープとロックを使用するネットワーク関連のコードに非常に適していることがわかりました。ただし、ランタイムの問題に対して無敵というわけではありません。LLMによってRustで書かれたコードはデッドロックに陥りやすく、これを回避する方法は、単なる非同期/待機のスタックではなく、理解しやすい状態マシンとしてシステムを設計することです。

FARTマスター

各デプロイメントには独自のFARTマスターが含まれています。マスターは、Cron、Webhookなどを調整する責任があります。

顧客への影響

FARTシステムは、約1年前から本番環境で稼働しています。最近、アクティブ-アクティブデプロイメントへの移行を行いました。地域間で自分の書き込みを読む際には影響がありますが、これは上記のリンクされたブログ投稿およびドキュメントに記載されています。

FARTはバックグラウンドで静かに動作していますが、その存在は常に感じられます。私たちは、私たちのシステムがあなたのユースケースにとってより速いことを願っています（主にデータの変更をもたらすユーザーアクションは、一部の地域でより速くなるでしょう）。

デプロイメント

デプロイメントは、サービス自体をデプロイするために使用するのと同じグローバルオーケストレーションシステムを使用します。FARTのドキュメントでは、Sloperatorsはデプロイを決して信頼せず、リリースの前にペイロードを常に確認することを推奨しています。

デプロイ後のFARTアラートはエスカレーションポリシーに従います：最初は部屋、次に階、最後に建物です。

結論

インターネットはチューブの連続だと言われていますが、実際にはガスの連続です。

すべての主要なリリースと同様に、私たちはこの変更を最適化し、テストし、適切にリリースする時間を取れたことを嬉しく思っています。今後の展開にワクワクしています。FastCommentsは、これにより長期的にはよりスケールしやすく、より良い稼働時間を持つはずです。FARTのランブックにはこう記されています：「何か匂いを感じたら、言ってください」。問題があれば、下にお知らせください。