Sun Mar 29 2026

...

FastComments가 우주를 준비했습니다!

! 이 글에는 기술 전문 용어가 포함되어 있습니다.

새로운 소식

각 FastComments point-of-presence는 이제 로컬로 쓰기를 처리하고 이를 비동기적으로 모든 다른 노드로 복제합니다. 이는 이전 시스템에 비해 내구성이 증가하며, 일부 지역의 사용자에게는 중재 도구를 더 빠르게 제공합니다. 다만 몇 가지 트레이드오프가 있습니다.

“우주를 준비했습니다”는 다소 낙관적이지만, 이 아이디어는 우리가 FastComments를 다른 행성에 배포할 수 있으며 결국 시스템이 동기화되는 것입니다. 그러나 명왕성의 사용자들은 자신의 청구서 페이지에서 변경 사항이 반영되기까지 약 하루를 기다려야 할 것입니다. 현재 각 지역마다 하나의 마스터만이 청구 정보를 집계할 수 있기 때문입니다.

일부 역사, 변화의 이유

FastComments가 처음 출시될 때 우리는 매우 전형적인 아키텍처를 갖추고 있었습니다. 우리는 프록시 계층, 앱 계층, 데이터베이스, 일부 복제본, 그리고 나중에는 추가 중복성을 위해 지역과 클라우드 공급자에 걸쳐 복제본을 두었습니다.

결국 우리는 DB 복제본을 대부분의 사용자들이 있는 모든 구역으로 이전하고, 앱도 그곳에 배포했으며, 요청을 가장 가까운 앱 노드로 라우팅하기 위해 자체 DNS 및 프록시 시스템을 만들었습니다(이는 나중에 블로그 게시물에서 설명됩니다). 이렇게 하면 읽기가 빨라지지만, 쓰기는 느려집니다. 이제 백엔드로의 하나의 HTTP 왕복을 기다리는 대신, 가까운 노드로의 HTTP 왕복을 기다려야 하고, 그 노드는 다시 기본 노드로 여러 번 데이터베이스 쓰기를 할 수 있습니다. 좋지 않습니다!

그래서 이를 극복하기 위해 우리는 애플리케이션의 많은 영역을 재구성하여 함수 인수에서 readPreference를 사용할 수 있게 했습니다. 이를 통해 호출자는 읽기가 얼마나 오래된 것에 대해 괜찮은지를 결정할 수 있습니다. 게다가, 더 많은 쓰기 작업(예: 중재자 행동에 대한 통계 기록)을 fire-and-forget 방식으로 만들었습니다. 완벽하지는 않지만, 속도가 상당히 빨라졌습니다.

Mongo를 전 세계적으로 운영하면서 겪는 한 가지 문제는 네트워크 분할입니다. 충분한 노드가 분리되면 각 노드는 읽기를 제공하는 것이 허용되는지 불확실해져서 읽기가 중지됩니다. 이에 대한 해결책이 몇 가지 있지만, 엣지 케이스는 복잡해집니다. 이는 이론적인 문제가 아닙니다 - 3AM에 페이지가 발생할 정도로 여러 번 발생했기 때문에 우리는 지치게 되었고, MongoDB가 복제 세트 선출 불확실성에 대해 최대 1분까지 괜찮도록 조정하려고 했습니다. 안타깝게도, 예를 들어 상파울루에서 팔켄슈타인까지의 네트워크는 우리 호스팅 제공자 중 일부에 대해 좋지 않았습니다. 혼잡 제어 등을 조정하는 것은 도움이 되었지만 문제를 해결하지 못했습니다.

궁극적인 해결책은 특정 트레이드오프에 괜찮다면, 해당 노드에서 로컬로 쓰기를 수용하고(양호한 하드웨어, RAID 등을 갖춘), 사용자에게 데이터가 저장되었다고 알리는 것입니다. 또한, 해당 포인트-오브-프레즌스에서 내구성을 위해 핫 복제본으로서 두 번째 노드를 유지할 수 있습니다.

그래서 우리가 도달한 것은 이렇습니다. 오리건, 버지니아, 팔켄슈타인, 상파울루, 싱가포르는 모두 자율 복제 세트를 갖추고 있으며 쓰기를 수용합니다. EU 배포(비록 세 개의 PoP만 있지만)도 동일한 동작을 합니다.

작동 방식

일부는 이전 섹션에서 다룬 내용이지만, TL;DR는 CRDT-lite입니다. 우리는 애플리케이션과 Mongo 간에 위치하여 다중 마스터를 만드는 프록시(물론 Rust로) 을 만들었습니다. 프록시는 피어 인식, 체크포인트 관리, 복제, 모니터링 및 초기 동기화를 처리합니다. 이는 Mongo의 복제 시스템을 위한 다중 마스터 교체이며, 일부 DDL 명령을 포함합니다.

다른 도구와의 차이점은 oplog을 tail하지 않는다는 것입니다. oplog을 tail하거나 변경 스트림을 사용하는 것은 작동하지 않으며, 이는 해당 객체의 최종 상태만 보여주기 때문에 충돌을 처리하는 것이 불가능합니다. 각 $set, $inc 작업을 캡처하고 그 작업 자체를 복제해야 합니다.

이는 도메인 특정 솔루션입니다. 모든 제품에 적용되지 않을 것입니다. 이를 도메인 주도 설계(domain-driven design)라고 할 수 있습니다 :). 우리는 처음부터 문서의 필드만 $set하여 변경하는 것을 매우 신중하게 해왔습니다 - 예를 들어, Mongo의 replaceOne은 절대 사용하지 않습니다. 카운터도 마찬가지입니다. 절대 SET VOTES = 5를 하지 않습니다. 대신, INCREMENT VOTES BY 5라고 작성해야 합니다. 이는 결국 일관성을 허용합니다. 분산 잠금은 완전히 피함으로써 처리됩니다. 클러스터당 하나의 노드만 크론을 실행하기 위해 플래그가 설정되어 있습니다. 이는 제한된 것처럼 보일 수 있지만, 우리는 테라바이트의 RAM을 가진 서버를 구매할 수 있으므로 이 트레이드오프를 통해 위험과 복잡성을 줄일 수 있습니다.

자신의 쓰기 읽기

API를 사용하는 개발자는 이전과 마찬가지로 자신의 쓰기를 읽을 수 있어야 합니다(댓글을 생성하는 API 호출을 하여 댓글 목록을 나열하고 그 목록에서 새 항목을 확인). 단, 주의사항은 지역 간에 이 작업을 수행할 수 없다는 것입니다. 귀하의 백엔드가 하나의 지역(예: us-west)에서만 실행된다면, 쓰기와 읽기 사이에 해당 노드가 다운되거나 DNS 캐시가 다음 가까운 노드를 가리키도록 업데이트되지 않는 한 자신의 쓰기를 읽을 수 있어야 합니다. 이러한 상황이 발생하지 않으면, 자신의 쓰기를 읽는 것은 신뢰할 수 있습니다.

테스트 및 마이그레이션

시스템의 코드의 약 절반은 테스트 하니스, 프레임워크 및 테스트로 구성됩니다. 여전히 출시가 다소 매끄럽지 않았으며, 원하는 것보다 더 긴 다운타임(유럽 1시간, 전 세계 20분)이 소요되었지만, 이 이정표를 통과한 것에 기쁘게 생각하며 여러분의 인내에 감사를 드립니다!

결론 및 여러분에게 의미하는 바

FastComments는 이제 그 어느 때보다 빠르고 더 내구성이 강해졌으며, 이제 기능 작업으로 돌아갈 수 있습니다 :)

건배!