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로 조정하는 데 많은 시간을 보냈고, 결국 async Rust + Mimalloc이 동일한 하드웨어에서 메모리 요구 사항이 훨씬 낮으면서도 성능이 눈에 띄게 향상되었다는 결론에 도달했기에 전환은 당연한 선택이었습니다.

Rust는 공유 힙과 잠금을 사용하는 네트워크 관련 코드를 위해 정말 훌륭하게 작동했습니다. 그러나 런타임 문제에는 면역이 아닙니다. LLMs에 의해 Rust로 작성된 코드가 교착 상태에 빠지기 쉽기 때문에, 이를 피하는 방법 중 하나는 시스템을 단순한 상태 기계로 설계하는 것입니다. 단순히 async/await의 집합이 아닌 것입니다.

FART 마스터

각 배포에는 자체 FART 마스터가 포함되어 있습니다. 마스터는 크론, 웹훅 등의 오케스트레이션을 책임집니다.

고객 영향

FART 시스템은 이제 약 1년 동안 운영되고 있습니다. 최근에야 액티브-액티브 배포로 마이그레이션을 수행했습니다. 지역 간에 자신의 쓰기를 읽는 데 약간의 영향이 있으며, 이는 위 링크 블로그 게시물과 문서에서 다루어집니다.

FART는 백그라운드에서 조용히 작동하지만, 그 존재는 항상 느껴집니다. 우리의 시스템이 여러분의 사용 사례에 대해 더 빠르기를 바라며 (주로 데이터 변경을 초래하는 사용자 행동이 일부 지역에서 더 빠르게 수행될 것입니다).

배포

배포는 서비스 배포에 사용하는 동일한 글로벌 오케스트레이션 시스템을 사용합니다. FART 문서에서는 Sloperators가 절대 배포를 신뢰하지 말고, 출시 전에 항상 페이로드를 확인할 것을 권장합니다.

배포 후 FART 알림은 에스컬레이션 정책을 따릅니다: 먼저 방, 그 다음 층, 그 다음 건물입니다.

결론

인터넷은 일련의 튜브라고 하지만, 사실 그것은 일련의 방귀입니다.

모든 주요 릴리스와 마찬가지로, 우리는 이 변경 사항을 최적화하고 테스트하며 적절하게 배포할 수 있는 시간을 가질 수 있어 기쁩니다. 앞으로 다가올 일들에 대해 기대가 큽니다. 이 작업 덕분에 FastComments는 더 나은 확장성을 가지며, 장기적으로 더 나은 가동 시간을 보장할 것입니다. FART 운영 매뉴얼에 따르면: "냄새가 나면, 말하세요". 문제가 발견되면 아래에 댓글로 알려주십시오.