Zendesk의 아키텍처는 초기 다수의 Rails 애플리케이션이 공통 로직을 공유하는 형태에서 시작하여, 기업 인수합병을 계기로 서비스 간 데이터 공유 모델로 진화했습니다. 현재는 Kafka를 활용한 이벤트 기반 아키텍처를 도입하여 시스템 간의 유연한 상호작용을 구현하고 있습니다. 발표자는 마이크로서비스가 만능 해결책이 아니며, 모놀리스와 마이크로서비스는 기업의 성장 단계에 따라 적절히 선택되어야 하는 스펙트럼의 개념임을 강조합니다. 특히 스타트업 초기에는 모놀리스가 빠른 시장 적합성 탐색과 반복 개발에 유리하며, Zendesk 역시 필요에 따라 모놀리스를 점진적으로 분리하는 경로를 따랐다고 설명합니다.
성능 측면에서 Anatoli는 Zendesk와 같은 대규모 조직에서 진정한 병목은 Ruby 언어 자체가 아닌 데이터베이스라고 역설합니다. Zendesk는 샤딩된 데이터베이스 인프라를 통해 방대한 고객 데이터를 관리하며, 활성 데이터와 비활성 데이터를 명확히 구분하여 효율성을 높였습니다. ‘성능, 쿼리 처리 능력, 데이터 가용성’ 중 두 가지만 선택할 수 있다는 원칙을 통해, 대규모 시스템에서 데이터셋의 크기 관리가 성능에 미치는 지대한 영향을 강조합니다.
신뢰성 확보를 위해 Zendesk는 160만 라인 이상의 코드 베이스와 55,000개가 넘는 방대한 테스트 스위트를 운영하고 있습니다. Ruby 테스트 프레임워크인 MiniTest의 창시자이자 유지보수자인 Ryan Davis가 Zendesk 내부에서 테스트 문화를 선도하고 있으며, MiniTest가 빠르고, 간결하며, ‘마법’이 적어 대규모 테스트 환경에 최적화되어 있다고 설명합니다. 배포 파이프라인은 스테이징 환경에서의 통합 테스트와 카나리 배포를 포함하며, 각 단계에서 충분한 ‘베이크 타임’을 통해 잠재적 문제를 조기에 발견하고 시스템의 안정성을 극대화합니다. 또한, GitHub의 ‘Code Owners’ 기능을 활용하여 코드 소유권을 명확히 하고, 변경 사항에 대한 책임과 협업 효율성을 높이고 있습니다.
Rails 버전 업그레이드는 Zendesk의 오랜 모놀리스 운영에서 가장 큰 도전 중 하나였습니다. Rails 1.0부터 현재 7.x 버전까지의 업그레이드 과정에서 메타프로그래밍의 과도한 사용이 주요 난관으로 작용했습니다. 특히 Rails 4에서 5로의 업그레이드는 2년 반이라는 긴 시간이 소요되었는데, 이는 복잡한 ‘마법’ 코드를 단순화하고 제거하는 과정이 필요했기 때문입니다. Zendesk는 Rails의 핵심 기능이 공식적으로 도입되기 전에 자체적으로 구현했던 ‘선발 주자 불이익(First Move Disadvantage)’ 사례(예: Strong Parameters, Sharding)를 공유하며, Rails 커뮤니티와의 활발한 소통과 협업을 통해 이러한 문제를 극복할 수 있음을 제안합니다.