주간SaaS 오늘의 소개글
가장 효과적인 배움은 경험으로 부터 오는 것이 사실이지만, 시스템 신뢰성에 대한 배움만큼은 이야기가 다릅니다. 값비싼 비용 치르거나 되돌릴 수 없는 치명적인 결과를 받아들여야 할수도 있기 때문이죠. 그래서 다른 곳의 성공과 실패 사례로 부터의 간접 경험이 소중한것 같습니다. 오늘은 Zendesk가 오랜 시간 동안 신뢰성 높은 B2B SaaS 시스템을 구축하며 겪었던 시행착오와 교훈을 담은 글 입니다.
젠데스크는 누구나 사용하는 IT 지원 데스크 소프트웨어에서 기업의 핵심 시스템을 책임지는 솔루션으로 거듭나기까지, 험난했던 안정성 확보를 위한 여정과 그 과정에서 얻은 소중한 원칙들을 공유하고자 합니다.
현재(2022년) 젠데스크는 최대 트래픽 시간대를 기준으로 초당 약 25만 건의 요청을 처리하며, 그중 절반 이상이 데이터베이스 읽기 또는 쓰기 작업을 수행합니다. 젠데스크의 심장과도 같은 존재는 바로 파티셔닝 및 샤딩 처리된 Ruby on Rails 애플리케이션입니다. 불과 10년 전만 해도 젠데스크의 인프라는 Ruby 백엔드와 단일 MySQL 데이터베이스를 갖춘 Nginx라는 단순한 구조에 불과했습니다.
지난 10년을 돌아보면 마치 폭풍 속을 헤쳐 온 것만 같습니다. 의도적이든 아니든, 내부 직원과 외부 사용자 모두로 인해 시스템은 끊임없이 위험에 노출되었습니다. 핵심 기술의 확장 한계에 부딪히기도 했고, 당장의 위기를 모면하기 위해 임시방편적인 파티셔닝 전략을 찾아 헤매기도 했습니다. 때로는 시스템 병목 현상을 해결하기 위해 아키텍처를 밑바닥부터 다시 설계해야 했습니다.
이러한 폭풍 같은 시간 속에서 젠데스크의 엔지니어링 조직은 30명에서 1,400명으로 괄목할 만한 성장을 이루었고, 이제는 매년 8만 번 이상 프로덕션 환경에 변경 사항을 배포합니다. 물론 탄탄대로만 걸어온 것은 아닙니다. 크고 작은 안정성 문제는 젠데스크의 발목을 끊임없이 붙잡았습니다. 다행히 대부분의 문제는 신속하게 파악하고 해결할 수 있었지만, 때로는 고객이 먼저 문제를 제기하는 당혹스러운 상황에 직면하기도 했습니다.
뼈아픈 경험을 통해 젠데스크는 지난 몇 년 동안 그 어느 때보다 안정성 확보에 전력을 기울였습니다. 그리고 이 여정의 나침반 역할을 해준 것은 바로 탄력적인 시스템 구축을 위한 8가지 핵심 원칙입니다. 놀랍게도 이 원칙들은 젠데스크가 안정성 문제로 정당한 불만을 제기한 고객과의 중요한 미팅을 준비하는 과정에서 탄생했습니다. 당시 내부적으로만 공유하던 원칙들이었지만, 곧 이 원칙들이 실제로 매우 유용하며, 모든 직원들이 공유하고 실천한다면 훨씬 더 효과적으로 안정성을 확보할 수 있다는 것을 깨달았습니다.
사실, 이 원칙들 중 다수는 젠데스크 스스로가 겪었던 시행착오에서 비롯되었습니다. 지나치게 높은 안정성 목표를 설정하거나, 제어 가능한 시스템의 안정성만 측정하는 우를 범했던 것입니다. 물론 젠데스크만의 노력으로 만들어진 것은 아닙니다. 클라우드 분야를 선도하며 젠데스크보다 훨씬 큰 규모의 시스템과 팀을 운영하는 AWS나 Netflix와 같은 기업의 경험에서 영감을 얻기도 했습니다.
이제 젠데스크가 깨달은 안정성 확보를 위한 여정을 여러분과 공유하고자 합니다. 가장 중요한 첫 번째 핵심은 바로 "고객의 입장에서 바라보지 않으면, 진정한 변화를 이끌어낼 수 없다"는 것입니다.
1. 실질적인 고객 영향 측정
오랫동안 젠데스크는 시스템 가용성 수치에 집착해 왔지만, 모니터링 시스템이 항상 고객의 실제 경험을 정확하게 반영하는 것은 아니라는 사실을 간과했습니다. 역설적이지만, 젠데스크는 실질적인 고객 영향 측정과는 점점 더 멀어지고 있었습니다.
돌이켜보면, 젠데스크는 몇 년 전까지만 해도 "99.99% 안정성"이라는 환상에 사로잡혀 있었습니다. 이사회에서 저조한 안정성에 대한 질책이 쏟아졌던 날, 한 이사가 "진정한 엔터프라이즈 SaaS 기업이 되려면 99.99%의 안정성은 필수"라고 강하게 주장했습니다. 그의 메시지는 마치 폭포수처럼 경영진을 거쳐 모든 직원에게 전달되었고, 젠데스크는 "99.99%를 반드시 달성하겠습니다!"라고 선언했습니다. 하지만 이는 곧 한 달에 단 5분 미만의 장애만 허용하겠다는 무모한 선언과도 같았습니다. 당시 젠데스크의 당직 팀은 한 달에 무려 3만 건의 페이지 호출에 시달리고 있었습니다.
이는 24시간 내내 3초마다 한 번씩 호출을 받는 것과 마찬가지 였습니다. 이런 상황에서 99.99%는 도달 불가능한 목표였습니다. 외부 업체로 인한 사고를 제외하는 꼼수를 쓰지 않는 한 말입니다. 다시 말해, 우리가 통제할 수 있는 시스템만을 평가하기로 한 것입니다. 지금 생각해 보면 참으로 순진한 발상이었습니다. 고객들은 장애가 젠데스크 시스템 자체의 문제인지, 아니면 젠데스크가 사용하는 외부 업체의 문제인지 전혀 신경 쓰지 않습니다. 그저 젠데스크 서비스를 이용하지 못하게 되었다는 사실에만 분노할 뿐입니다.
그렇기에 젠데스크는 이제 "무장애 가용성(Trouble Free Availability, TFA)" 측정 기준을 고객에게 미치는 실질적인 영향을 기반으로 합니다. 문제의 원인이 젠데스크 자체 시스템이든, Twilio, Cloudflare, AWS와 같은 외부 업체든 전혀 상관하지 않습니다. 외부 업체의 안정성을 직접 통제할 수는 없지만, 어떤 업체와 파트너십을 맺고 어떻게 의존할지는 젠데스크가 결정할 수 있기 때문입니다.
결국 젠데스크는 (외부 업체를 포함한) 무장애 가용성 목표를 99.95%로 하향 조정했습니다. 지금 생각해 보면 더 낮췄어야 했을지도 모릅니다. 하지만 당시에는 99.95% 정도라면 운이 좋으면 달성할 수 있을 것 같았습니다. 또한, 실질적인 고객 영향을 정확하게 측정할 수 있는 시스템이 필요했습니다. 젠데스크의 내부 시스템 관점이 아닌, 고객의 관점에서 발생하는 오류를 정확하게 파악해야 했습니다. 이를 위해서는 관측 가능성(Observability)을 개선해야 했습니다.
관측 가능성을 개선한 덕분에, 이제는 문제가 발생할 때마다 일일이 수동으로 사고를 선언하는 대신, 사전에 경고를 통해 문제를 감지하는 능력이 크게 향상되었습니다. 특히 내부적으로 가동 시간 모니터링에서 'Rate-Error-Duration' 모니터링으로 전환한 것은 매우 성공적인 결정이었습니다. 젠데스크는 이제 고객 브라우저, CDN, 프록시 계층, 외부 업체 서비스까지 아우르는 다양한 지점에서 고객 경험 지표를 수집하고 분석합니다. 서비스 경계를 넘어 측정값을 비교했을 때 의미 있는 인사이트를 얻을 수 있는 경우가 많기 때문에 다양한 지점에서 데이터를 수집하는 것이 중요합니다.
물론 실질적인 고객 영향을 측정하는 것이 쉽지만은 않습니다. 경영진에게 실제 안정성 수치가 얼마나 낮은지 솔직하게 보고하는 것은 더욱 어려운 일입니다. 하지만 젠데스크는 통제 가능한 영역만을 평가하는 대신, 언제나 고객에게 미치는 실질적인 영향을 측정하는 것이 올바른 길이라는 믿음을 가지고 있습니다.
2. 핵심 기능에 집중
젠데스크는 시스템 불안정 문제에 직면할 때마다, 많은 기업들이 그렇듯 더 복잡한 프로세스를 도입하거나 모든 프로덕션 라인을 중단하고 문제 해결에 매달리는 오류를 범하곤 했습니다. 물론 어느 정도는 효과가 있었지만, 고객에게 중요하지 않은 기능의 안정성을 확보하는 데 시간과 노력을 낭비하는 결과를 초래하기도 했습니다. 젠데스크는 최대의 효과를 얻기 위해 고객에게 가장 중요한 것에 집중해야 했습니다. 그리고 그 해답은 바로 "핵심 기능"이었습니다.
젠데스크는 "핵심 기능"을 "해당 기능에 장애가 발생할 경우, 전체 제품의 중단과 거의 동일한 수준의 영향을 고객에게 미치는 기능"으로 정의했습니다. 예를 들어, 고객이 티켓을 생성할 수 없다면, 이는 지원 제품 전체를 사용할 수 없는 것과 마찬가지입니다. 젠데스크는 가장 먼저 핵심 기능을 정의하고 담당자를 지정했습니다. 이를 통해 젠데스크는 SLI 및 SLO 구현, 스모크 테스트, 오류율 및 오류 모니터링에 집중할 수 있었습니다. 이제 SLI 및 SLO는 제품 수준 오류 예산에도 반영됩니다. 핵심 기능 정의 및 관리 시스템이 자리를 잡은 지 약 6개월 후, 젠데스크는 이를 SEV1(심각도 1) 정의에 포함하기로 결정했습니다.
사실, 조직의 리소스를 집중하기 위해 젠데스크가 처음으로 시도한 방법은 핵심 기능이 아니었습니다. 처음에는 서비스의 중요도를 0에서 4까지 분류하는 시스템을 도입했고, 0단계가 가장 중요한 서비스였습니다. 0단계 시스템에 장애가 발생하면 여러 제품의 핵심 기능이 중단되는 심각한 상황이 발생합니다. 젠데스크의 Nginx 프록시 계층, Kubernetes 클러스터, MySQL 데이터베이스, 모든 요청이 통과하는 인증 서비스 등이 이에 해당됩니다. 물론 서비스 중요도 분류는 여전히 유용하게 사용되고 있지만, 고객 경험과 직접적으로 연결하기가 어렵다는 단점이 있었습니다.
젠데스크는 핵심 기능과 서비스 중요도 분류를 통해 더 많은 투자가 필요한 영역을 명확하게 파악할 수 있었습니다. 모든 시스템의 안정성을 동시에 완벽하게 확보하는 것은 불가능하지만, 이 두 가지 분류 시스템은 고객에게 가장 큰 영향을 미치는 영역을 파악하고, 안정성 작업의 우선순위를 정하는 데 큰 도움이 되었습니다.
3. 장애를 예상하고 시뮬레이션
초창기 젠데스크는 전 세계 여러 곳의 코로케이션 데이터 센터에 자체 하드웨어를 구축하여 운영했습니다. 거의 모든 시스템을 이중화했고, 대부분의 서버는 수년 동안 재부팅은커녕 장애 한 번 없이 안정적으로 작동했습니다. 하지만 AWS로 이전하면서 젠데스크는 사고방식을 전환하고 인프라를 현대화해야 했습니다. 더 이상 서버가 오랜 시간 안정적으로 작동할 것이라고 가정할 수 없게 되었고, 예고 없이 EC2 인스턴스가 재시작될 가능성에 대비해야 했습니다. 모든 시스템을 설계할 때 언제든 재시작되거나 사라질 수 있다는 점을 염두에 두어야 했습니다. Chef를 사용하여 인스턴스를 프로비저닝하는 데 30분이나 걸리는 것은 용납될 수 없는 일이 되었습니다. 이제는 단 몇 초 만에 시스템을 시작할 수 있어야 했습니다. 재시작 후 엔지니어가 직접 개입해야 하는 상황은 절대적으로 피해야 했습니다. AWS로 이전하는 초기에는 수많은 시행착오를 겪었습니다.
AWS에서는 프로덕션 환경에서 매일같이 장애가 발생했기 때문에, 굳이 장애를 가정하고 시뮬레이션할 필요조차 없었습니다! 젠데스크는 모든 서비스를 Kubernetes에서 실행하기 위해 인프라를 이전하는 과정에서 수많은 문제에 직면했습니다. 마치 두더지 잡기 게임과 같았습니다. 이러한 경험을 통해 젠데스크 엔지니어링 팀은 Kubernetes 파드가 언제든지 사라질 수 있다는 가정하에 시스템을 구축해야 한다는 것을 뼈저리게 깨달았습니다. 모든 것을 Kubernetes로 이전하면서 시스템 안정성이 크게 향상되었지만, 이것만으로는 충분하지 않았습니다.
문제는 시스템이 여전히 너무 밀접하게 연결되어 있어서 한 부분에서 장애가 발생하면 모든 시스템이 마비된다는 것이었습니다. 서비스 디스커버리가 대표적인 예입니다. 젠데스크는 Kubernetes로 이전하는 과정에서도 서비스 디스커버리 시스템으로 Consul을 광범위하게 사용했습니다. 그러던 어느 날 Consul에 장애가 발생했고, 그 결과 모든 시스템이 마비되는 사태가 발생했습니다. 서비스 디스커버리 시스템의 장애를 전혀 대비하지 않았던 것입니다. 당시 젠데스크는 시스템 이전과 끊임없이 발생하는 사고 대응에만 급급한 나머지 미래에 발생할 수 있는 장애 상황을 고려할 여유가 없었습니다. 하지만 이제는 달라져야 했습니다. 언제나 예상치 못한 상황이 발생할 수 있다는 것을 인지하고, 실제 프로덕션 환경에서 장애가 발생하기 전에 사전에 테스트 환경에서 다양한 장애 상황을 시뮬레이션해야 했습니다.
테스트 환경은 물론, 최근에는 프로덕션 환경에서도 장애 상황을 시뮬레이션하면서 젠데스크의 시스템 안정성은 비약적으로 향상되었습니다. 현재 젠데스크는 카오스 엔지니어링 팀을 구성하여 매월 전사적인 장애 대응 훈련을 실시하고 있으며, 매주 서비스별 장애 대응 훈련도 진행하고 있습니다. 실제로 도쿄 가용 영역의 냉각 시스템 고 장으로 인해 해당 영역을 비워야 했던 사고가 발생하기 전날, 동일한 팀원들이 가용 영역 장애 대응 훈련을 실시했던 일도 있었습니다! 젠데스크는 장애 대응 훈련을 통해 실제 사고 발생 시 대응 프로세스를 점검하고, 데이터 저장소 지연 시간 증가, 시스템 부팅 시 발생할 수 있는 새로운 종속성 문제 등을 사전에 파악하고, 다양한 장애 시나리오에서 서비스가 정상적으로 배포되는지 확인할 수 있었습니다.
물론 아직 갈 길이 멀지만, 젠데스크는 매번 장애 대응 훈련을 거치면서 시스템 안정성을 한 단계씩 발전시키고 있습니다. 앞으로 테스트 환경에서 상시적으로 장애 시뮬레이션을 실시하고, 이를 배포 파이프라인에 통합하는 것을 목표로 하고 있습니다.
젠데스크는 컴퓨터 시스템은 언제든 장애가 발생할 수 있다는 것을 잘 알고 있습니다. 따라서 탄력적인 시스템을 구축하기 위해서는 장애를 당연한 것으로 받아들이고, 실제로 문제가 발생했을 때 당황하기보다는 침착하게 대응하는 훈련을 반복해야 합니다.
4. 장애 범위 최소화
작은 단위로 장애를 격리하는 것은 매우 어렵지만, 젠데스크의 전반적인 안정성 전략에서 매우 중요한 부분입니다. 젠데스크는 파티셔닝, 서킷 브레이킹, 제한 설정, 신속한 장애 처리, 변경 사항 도입 방식 개선 등과 같은 일반적인 방법들을 통해 시스템을 개선해 왔습니다.
초창기 젠데스크는 Rackspace에 호스팅된 단일 환경, 단일 파티션에서 젠데스크 전체를 운영했습니다. 당시 젠데스크는 최악의 DDoS 공격을 경험했습니다. 단 한 명의 고객을 대상으로 한 공격이 네트워크 대역폭을 모두 차지하면서 Rackspace는 젠데스크 서비스를 강제로 중단시켰습니다. 모든 고객이 서비스를 이용할 수 없게 된 것입니다. 설상가상으로 외부에서 인터넷을 통해 접속해야 했기 때문에 젠데스크조차 자체 인프라에 접속할 수 없는 상황이었습니다. 뼈아픈 경험을 통해 젠데스크는 많은 것을 배웠습니다. 무엇보다 중요한 것은 바로 장애 범위를 최소화해야 한다는 것이었습니다.
뼈아픈 DDoS 공격 이후 젠데스크는 시스템을 파티셔닝하는 것이 얼마나 중요한지 깨달았습니다. 젠데스크는 AWS가 영역 단위로 인프라를 구축하는 방식, Route 53의 셔플 샤딩 기술, 그리고 안정적인 멀티테넌트 시스템을 구축하기 위해 권장되는 다양한 모범 사례에서 영감을 얻었습니다. 또한, AWS 환경에 변경 사항을 배포할 때 단일 영역의 단일 인스턴스에서 시작하여, 안정성이 검증될수록 점진적으로 범위를 확장하는 방식에서도 아이디어를 얻었습니다. AWS는 이러한 프로세스를 자동화하기 위해 많은 노력을 기울였습니다. AWS의 클레어 리구오리(Clare Liguori)가 작성한 "안전하고 자동화된 핸즈오프 배포(Automating safe, hands-off deployments)"라는 글에서 자세한 내용을 확인할 수 있습니다.
현재 젠데스크는 모든 수준에서 인프라를 파티셔닝하는 데 집착에 가까울 정도로 많은 노력을 기울이고 있습니다. 젠데스크의 목표는 각 파티션을 완벽하게 분리하여 한쪽에서 장애가 발생하더라도 다른 쪽에는 영향을 미치지 않도록 하는 것입니다. 그리고 이러한 전략은 매우 효과적이었습니다.
일관된 배포 방식 또한 새로운 변경 사항이 프로덕션 환경에 배포될 때 발생할 수 있는 장애 범위를 줄이는 데 매우 효과적입니다. 이는 조직 전체에 큰 변화를 가져왔지만, 그만큼 놀라운 결과를 가져왔습니다. 이제 새로운 변경 사항이 테스트 환경에서 모든 검증을 통과하면 젠데스크의 모든 내부 시스템(고객 지원 포털 https://support.zendesk.com 포함)을 호스팅하는 카나리 환경에 배포됩니다. 그리고 충분한 시간 동안 안정적으로 작동하는 것이 확인되고 스모크 테스트를 통과하면, 부하와 매출을 기준으로 단계적으로 프로덕션 환경에 배포됩니다.
5. 오용으로부터 인프라를 보호하고 점진적으로 용량 증대
얼마 전 젠데스크의 미켈(Mikkel)은 이런 말을 했습니다. "지루하기 짝이 없는 B2B 서비스에 얼마나 많은 악의적인 공격이 들어오는지 알면 정말 놀랄 거예요. 누가 감히 고객 지원 회사를 공격하겠어요?" 하지만 젠데스크는 매주 새롭고 기상천외한 방식으로 공격받고 있습니다. 대부분은 악의적인 의도를 가진 공격자들이지만, 때로는 실수로 젠데스크 시스템에 과부하를 일으키는 경우도 있습니다. 예를 들어, 한 지원 관리자가 실수로 API 호출 스크립트를 잘못 작성하여 동일한 티켓에 수천 건의 업데이트를 동시에 시도하는 경우가 있습니다.
하지만 가장 당황스러운 것은 젠데스크 자체 시스템이 오용의 원인을 제공하는 경우입니다. 몇 년 전 젠데스크는 성능 향상을 위해 모바일 SDK에 사전 로딩 기능을 추가했습니다. 당시 젠데스크는 개발자들에게 앱이 실행될 때마다 SDK가 서버에 접속하도록 코드를 작성할 것을 권장했습니다. 테스트 환경에서는 아무런 문제가 없었습니다! 하지만 고객들이 새로운 버전의 SDK를 적용하기 시작하면서 문제가 발생했습니다. 젠데스크 고객 중에는 세계 최대 규모의 모바일 게임 회사와 소셜 네트워크 회사들이 포함되어 있습니다. 젠데스크의 안내에 따라 새로운 SDK를 적용한 한 고성장 기업은 예상치 못한 폭풍을 맞게 됩니다. 전 세계 수백만 대의 스마트폰에서 동시에 젠데스크의 Nginx 서버로 중요하지 않은 트래픽이 쏟아진 것입니다. 이 사건을 계기로 젠데스크는 중요한 교훈을 얻었습니다.
오용은 의도적이든 아니든, 자체적인 문제이든 외부적인 문제이든, 언제 어떤 형태로든 발생할 수 있습니다. 지난 10년 동안 젠데스크는 안정적인 시스템을 구축하기 위해서는 다층적인 방어 시스템이 필수적이라는 것을 깨달았습니다. 기존의 DDoS 및 WAF(웹 애플리케이션 방화벽) 방식의 보안 시스템 외에도, 사용량 제한은 가장 효과적인 전략 중 하나였습니다. 모든 것에 제한(limiting)을 두어야 했습니다.
물론 엔지니어링 부서 외부에서는 사용량 제한을 달가워하는 사람이 많지 않았습니다. 젠데스크는 내부적으로, 그리고 일부 고객과는 매우 조심스럽게 문화를 바꿔나가야 했습니다. 새로운 제한을 도입하기 위해서는 현재 사용량을 파악하고, 적절한 제한 기준을 설정하고, 기존 고객들에게 새로운 제한 사항을 안내하는 등 많은 노력이 필요했습니다. 때로는 개별 고객이 다른 API 엔드포인트로 마이그레이션할 수 있도록 지원해야 하는 경우도 있었습니다. 결코 쉽지 않은 과정이었습니다.
물론 모든 노력이 그에 상응하는 결과로 이어지는 것은 아닙니다. 하지만 젠데스크는 Nginx에 단 5줄의 코드를 추가하여 오용 방지를 위한 속도 제한(Rate Limit)을 구현했고, 이는 매우 성공적인 결과로 이어졌습니다.
젠데스크는 사용량 제한과 상시 방어 메커니즘을 통해 엔지니어들에게 명확한 확장 경계를 제시할 수 있었습니다. 또한, 고객들에게 플랫폼 확장 방식을 투명하게 공개하고, 필요에 따라 제한을 상향 조정하는 프로세스를 구축했습니다.
6. 자동화 및 자가 치유 기능 강화
젠데스크는 핵심 기능에 대해 99.95%의 무장애 가용성 목표를 설정했으며, 이는 매월 21분 54초의 성능 저하 시간을 허용한다는 것을 의미합니다. 하지만 사람이 20분 이내에 경고를 받고, 문제를 진단하고, 해결 방안을 찾아서 실행하는 것은 사실상 불가능합니다. 따라서 젠데스크는 안정성 목표를 달성하기 위해 장애 대응 및 시스템 자가 치유 기능을 자동화해야 했습니다. 예를 들어, 네트워크 오류가 특정 임계값을 초과하면 Kubernetes 노드를 자동으로 격리하는 시스템이나, 문제가 발생한 컨테이너를 우회하도록 Istio를 OutlierDetection과 함께 구성한 것 등이 있습니다.
또한, 젠데스크는 자동화를 통해 문제 진단 속도를 높였습니다. 젠데스크에서 흔히 발생하는 장애 중 하나는 느린 요청이 누적되어 Unicorn 사용량이 급증하는 것입니다. 이제 경고가 발생하면 자동 복구 시스템이 Datadog APM에서 데이터를 가져와 담당 엔지니어에게 문제를 일으키는 계정, 엔드포인트, 그리고 단기적인 제한 조치 등을 제안합니다.
물론 아직 자동화 여정은 초기 단계에 불과합니다. 특히 AWS 네트워킹 및 EC2 팀과 이야기를 나누다 보면, 젠데스크의 자동화 수준은 아직 한참 멀었다는 것을 느낍니다. AWS는 놀라운 안정성을 제공하기 위해 자동화된 상태 확인 시스템을 구축하는 데 많은 노력을 기울였습니다.
7. 고객 커뮤니케이션 개선
젠데스크는 장애 발생 시 고객에게 신속하게 정보를 제공하고, 문제의 원인과 해결 방안을 투명하게 공개하여 고객이 적절하게 대응할 수 있도록 하고, 동일한 문제가 재발하지 않을 것이라는 신뢰를 제공하기 위해 노력하고 있습니다. 물론 말처럼 쉬운 일은 아닙니다. 젠데스크에서 발생하는 사고는 대부분 전례 없는 새로운 유형의 사고이기 때문에, 근본 원인을 파악하기 위해서는 상당한 시간이 소요됩니다. 문제의 원인을 파악한 후에도 영향을 받는 고객을 정확하게 파악하고 이들에게 상황을 알리기까지는 또다시 많은 시간이 필요합니다. 많은 기업들이 사고 발생 시 고객의 기대에 부응하는 데 어려움을 겪고 있습니다. 젠데스크는 고객과의 커뮤니케이션에서 만큼은 최고 수준을 목표로 합니다.
젠데스크는 고객과의 소통 방식을 개선하기 위해 끊임없이 노력하고 있지만, 아직 갈 길이 멉니다. 젠데스크는 사전 예방 차원에서 고객과 파트너에게 젠데스크의 시스템 아키텍처, 장애 발생 가능성, 사고 관리 방식 등을 자세히 설명하여, 고객이 젠데스크 시스템과 안정적으로 통합하고 장애 발생 시 적절하게 대응할 수 있도록 지원하고 있습니다. 또한, 사고 발생 시 영향을 받는 고객을 신속하게 파악하고, 상태 페이지를 통해 더욱 효과적으로 정보를 제공하기 위해 노력하고 있습니다. 가장 큰 변화 중 하나는 숙련된 엔지니어링 리더를 지정하여 사고 관리자를 지원하고, 내부 및 고객 커뮤니케이션을 담당하도록 한 것입니다.
8. 안정성 목표 점진적 상향 조정
목표는 달성 가능해야 동기 부여가 됩니다. 따라서 엔지니어들이 목표를 달성하기 위해서는 현실적인 목표 설정이 중요합니다. 물론 젠데스크는 99.95%에 만족하지 않습니다. 젠데스크 이사회의 지적처럼, 젠데스크의 고객에게는 99.99%의 안정성이 필요합니다. 젠데스크는 고객의 비즈니스를 완성하는 핵심 파트너가 되고자 합니다. 작년 젠데스크는 핵심 기능을 SEV1 정의에 포함하여 안정성 목표를 한 단계 높였습니다. 앞으로도 6개월 동안 현재 목표를 안정적으로 달성한다면, 다시 한번 목표를 상향 조정할 것입니다.
안정성 목표를 단 0.01%라도 높이는 것은 매우 어려운 일이며, 이를 유지하는 것은 더욱 어렵습니다. 앞으로도 젠데스크는 단순히 운이 좋아서 목표를 달성한 것인지, 아니면 진정한 안정성을 확보했기 때문에 목표를 달성한 것인지 끊임없이 자문해야 할 것입니다.
앞으로 나아갈 길
젠데스크는 안정성이라는 과제에 완벽한 정답은 없다고 생각합니다. 젠데스크는 이상주의자가 아닌 현실주의자입니다. 안정성 확보는 마치 끝없이 높아지는 벽을 끊임없이 넘어야 하는 게임과 같습니다. 젠데스크는 앞서 소개한 8가지 원칙이 내부적으로 젠데스크의 장기적인 비전을 공유하고, 외부적으로는 고객과 소통하는 데 큰 도움이 되었다고 생각합니다. 이러한 원칙들은 젠데스크의 모든 팀의 로드맵과 실질적인 업무에 반영됩니다. 앞으로도 젠데스크는 안정성을 확보하기 위한 다양한 계획을 추진할 것입니다. 가용 영역 선호도 라우팅, 자동 배포, 핵심 시스템의 DynamoDB 마이그레이션, 그리고 아키텍처 개선 등 흥미로운 과제들이 기다리고 있습니다. 만약 여러분이 젠데스크의 원칙에 공감하고, 빠르게 성장하는 대규모 시스템의 안정성을 확보하는 도전적인 과제에 매력을 느낀다면, 젠데스크에 문을 두드려 주십시오.
의견을 남겨주세요