대규모 동적 설정 변경을 안전하게 지키는 법

Dynamic configuration은 서비스 재배포 없이 런타임 동작을 바꾸게 해주지만, 잘못된 변경은 바로 장애로 이어질 수 있다. Airbnb는 이를 위해 내부 플랫폼 Sitar를 두고, 변경을 정의-검토-테스트-배포하는 흐름 전체를 하나의 체계로 묶었다.

플랫폼이 갖춰야 할 핵심은 네 가지다.

• Configs as code: config를 서비스 코드처럼 Git에서 버전 관리하고 리뷰와 승인, 감사 추적을 적용한다.
• 안전한 롤아웃: 모든 변경은 schema validation과 자동 검사를 통과해야 하며, 이후 제한된 범위부터 단계적으로 확장된다.
• 격리된 테스트: local 또는 canary 환경에서 미리 검증해 생산 환경 위험을 줄인다.
• 멀티테넌트 유연성: tenant별로 배포 트리거, guardrail, rollout 전략을 다르게 설정할 수 있다.

Sitar의 아키텍처는 developer-facing layer, control plane, data plane, 그리고 서비스 옆에서 동작하는 agent sidecar와 client library로 나뉜다. 개발자는 GitHub 중심의 기본 워크플로로 config를 관리하고, 예외 상황이나 긴급 대응은 sitar-portal에서 처리한다. control plane은 검증, ownership, access control, rollout 정책을 담당하고, data plane은 config의 저장과 대규모 배포를 맡는다.

롤아웃은 한 번에 전체에 퍼뜨리지 않는다. main branch에 합쳐진 뒤에는 제한된 scope에 먼저 적용하고, 상태를 보며 점진적으로 확장하며, 이상 징후가 보이면 즉시 rollback할 수 있다. 이 방식은 잘못된 config의 blast radius를 줄이고, 장애 대응 속도를 높인다.

서비스 측면에서는 local cache가 중요하다. agent sidecar가 backend에서 주기적으로 config를 가져와 로컬에 저장하고, client library는 그 캐시를 읽는다. 그래서 backend가 일시적으로 느려지거나 내려가도 서비스는 마지막으로 정상 확인된 config로 계속 동작할 수 있다.

이 구조 덕분에 product team은 더 작은 단위로 안전하게 기능을 바꾸고, 자동/수동/cron rollout 같은 방식을 팀 성격에 맞게 선택할 수 있다. 장애가 나면 관측 도구로 어떤 config가 언제 누구에게 영향을 줬는지 추적한 뒤, portal의 emergency flow로 빠르게 수정할 수 있다.