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

はじめに

FastComments自動ルーティング輸送システム（FARTS）は、私たちの輸送およびサービス層です。FARTSは、混雑を緩和し、ユーザーの位置に基づいてトラフィックをルーティングし、将来的には負荷に基づいてトラフィックをルーティングします。これには、地理的に認識されたDNSレイヤー、DBプロキシ、DBレプリケーション、SSL証明書管理、リバースプロキシ、およびディスク上のLRUキャッシュを使用してエッジで資産をキャッシュするCDNなど、いくつかの異なるシステムが含まれています。

アクティブ-アクティブ

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

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

スケールでのRust

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

私たちは旧Javaシステムを異なるGCなどで調整するのに多くの時間を費やしましたが、最終的には非同期Rust + Mimallocが同じハードウェア上で非常に優れたパフォーマンスを発揮し、メモリ要件が大幅に低かったため、切り替えは明白な選択でした。

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

FARTマスター

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

顧客への影響

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

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

デプロイメント

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

デプロイメント後のFARTアラートはエスカレーションポリシーに従います：最初は部屋、その後はフロア、最後はビルです。

結論

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

すべての主要なリリースと同様に、この変更を最適化し、テストし、適切にリリースするための時間を取ることができたことを嬉しく思います。今後の展開に期待しています。FastCommentsは、この作業によってより良いスケーラビリティと長期的な稼働時間を実現するはずです。FARTのランブックにあるように：「何かを感じたら、何かを言ってください」。問題を発見した場合は、以下にお知らせください。