reliability-engineering

3 개의 포스트

Temporal이 넷플릭스의 안정 (새 탭에서 열림)

넷플릭스는 배포 시스템인 Spinnaker의 클라우드 작업 안정성을 높이기 위해 '지속 가능한 실행(Durable Execution)' 플랫폼인 Temporal을 도입했습니다. 기존 시스템은 인스턴스 재시작이나 네트워크 일시 오류 발생 시 작업 상태를 잃어버리는 구조적 한계로 인해 약 4%의 배포 실패율을 보였습니다. Temporal 도입 후, 상태 정보를 자동으로 유지하고 장애 시 중단 지점부터 재개하는 방식을 통해 일시적 장애로 인한 실패율을 0.0001%까지 획기적으로 낮추는 성과를 거두었습니다. **기존 Spinnaker 구조와 상태 관리의 한계** * 배포 엔진인 Orca가 Clouddriver에 작업을 요청하면, Clouddriver는 내부 오케스트레이션 엔진을 통해 클라우드 제공업체의 API를 호출하는 구조였습니다. * 작업 상태가 메모리나 휘발성 저장소에 유지되었기 때문에, 클러스터 업데이트나 인스턴스 종료와 같은 운영 작업 중 실행 중인 모든 작업이 유실되거나 일관성이 깨지는 문제가 빈번했습니다. * 복잡한 다단계 클라우드 작업 중 중간 단계에서 오류가 발생하면, 수동으로 개입하여 상태를 정리하거나 재시도 로직을 직접 복잡하게 구현해야만 했습니다. **Temporal을 이용한 지속 가능한 실행 구현** * 비즈니스 로직을 담당하는 '워크플로우(Workflow)'와 외부 API 호출 등 부수 효과를 수행하는 '액티비티(Activity)'를 분리하여 설계했습니다. * Temporal은 작업의 모든 실행 단계를 데이터베이스에 기록(Event Sourcing)하므로, 실행 중 프로세스가 죽더라도 새 인스턴스에서 마지막 상태를 복구하여 즉시 재개할 수 있습니다. * 개발자는 일시적인 네트워크 오류나 API 제한에 대비한 복잡한 재시도 코드를 작성하는 대신, Temporal의 선언적 재시도 정책을 활용해 "장애가 없는 것처럼" 코드를 작성할 수 있게 되었습니다. **도입 결과 및 운영 효율성 향상** * 일시적 장애로 인한 배포 실패율이 4%에서 0.0001%로 감소하며 시스템 신뢰도가 비약적으로 상승했습니다. * CDN 장비 업데이트와 같이 며칠 혹은 몇 주가 소요되는 장기 실행 작업도 타임아웃이나 상태 유실 걱정 없이 안정적으로 관리할 수 있게 되었습니다. * 인프라 운영 팀은 시스템 점검이나 배포를 위해 기존 작업을 강제로 중단하거나 완료될 때까지 기다릴 필요가 없어져 운영 유연성이 크게 확보되었습니다. 복잡한 분산 시스템에서 상태 관리와 재시도 로직을 직접 구현하는 것은 매우 까다롭고 오류가 발생하기 쉽습니다. 넷플릭스의 사례처럼 장기 실행 작업이나 높은 신뢰성이 요구되는 마이크로서비스 환경에서는 Temporal과 같은 워크플로우 엔진을 도입하여 인프라 수준에서 안정성을 보장받는 것이 효율적입니다.

실패는 피할 수 없습니다: (새 탭에서 열림)

2023년 3월, 데이터독(Datadog)은 인프라의 약 50~60%가 중단되는 대규모 장애를 겪으며 시스템의 일부가 마비될 때 플랫폼 전체가 완전히 다운된 것처럼 보이는 '정방형 파형(Square-wave)' 장애 패턴을 확인했습니다. 이를 계기로 데이터독은 모든 장애 상황을 완벽히 방지하는 것은 불가능하다는 점을 인정하고, 장애 발생 시에도 시스템이 점진적으로 기능을 유지하는 '우아한 성능 저하(Graceful Degradation)'를 최우선 가치로 삼게 되었습니다. 데이터 유실 방지, 실시간 데이터 우선 처리, 부분적인 결과 제공을 핵심 원칙으로 설정하여 인프라 전반의 회복 탄력성을 재설계하는 대대적인 변화를 추진하고 있습니다. **"결함 없음" 설계의 한계와 Square-wave 장애** - 과거 데이터독은 데이터의 '정확성'을 보장하기 위해 100% 완벽한 데이터가 수집될 때까지 쿼리 결과를 반환하지 않도록 시스템을 최적화했습니다. - 이러한 설계는 일부 노드가 다운되었을 때 시스템 전체가 응답을 멈추게 하여, 사용자에게는 플랫폼이 완전히 중단된 것처럼 보이는 이진적(Binary) 장애를 초래했습니다. - 고전적인 근본 원인 분석(RCA)을 통해 특정 트리거를 제거할 수는 있지만, 소프트웨어 업데이트, 인증서 만료 등 무한한 장애 원인을 모두 예방하는 것은 불가능하다는 결론에 도달했습니다. **우아한 성능 저하를 위한 새로운 우선순위** - 시스템 구성 요소가 완벽하게 작동해야만 가치를 제공하는 '결함 방지(Never-fail)' 아키텍처에서 '더 잘 실패(Fail better)'하는 구조로 전환했습니다. - 데이터 유실 방지: 처리가 늦어지더라도 고객의 데이터가 영구적으로 사라지지 않도록 보장합니다. - 실시간성 우선: 가용 자원이 부족할 때 오래된 데이터보다 실시간 데이터를 우선적으로 처리하여 현재 상태를 파악할 수 있게 합니다. - 부분 결과 제공: 모든 데이터가 준비되지 않았더라도 정확도가 확인된 범위 내에서 부분적인 데이터를 즉시 시각화합니다. **데이터 유실 방지를 위한 영구적 수집 저장소(Persistent Intake Storage)** - 장애 당시 메모리나 로컬 디스크에만 머물던 미복제 데이터가 노드 유실과 함께 사라졌던 문제를 해결하기 위해 파이프라인 초기 단계에 디스크 기반 영구 저장소를 도입했습니다. - 수집(Intake) 직후 데이터를 복제된 저장소에 즉시 기록함으로써, 후속 처리 시스템이 정체되거나 노드가 유실되더라도 데이터 손실 없이 재처리가 가능하도록 설계했습니다. - 이를 통해 네트워크 지연이나 하위 시스템의 과부하 상황에서도 데이터 수집 단계에서의 안정성을 확보했습니다. 모든 장애를 차단하려는 시도보다는, 장애 상황에서도 시스템이 어떻게 부분적으로나마 작동할 수 있을지를 설계 단계부터 고민해야 합니다. 대규모 분산 시스템을 운영한다면 데이터의 완전성(Completeness)과 가용성(Availability) 사이의 균형을 재검토하고, 최악의 순간에도 사용자에게 최소한의 가시성을 제공할 수 있는 복구 탄력성을 구축하는 것이 권장됩니다.

디스코드 패치 (새 탭에서 열림)

디스코드의 '패치 노트(Patch Notes)' 시리즈는 성능, 신뢰성, 응답성 및 사용성 개선을 위한 기술적 변화와 버그 수정 내역을 사용자에게 공유하는 정기적인 소통 창구입니다. 엔지니어링 팀은 이를 통해 서비스 품질을 고도화하고 개발 진척 상황을 투명하게 공개합니다. 특히 커뮤니티와의 긴밀한 협력을 통해 실시간으로 발생하는 문제점을 식별하고 해결하는 데 주력하고 있습니다. ### 패치 노트 시리즈의 목적과 범위 * 서비스의 핵심 지표인 성능(Performance), 신뢰성(Reliability), 응답성(Responsiveness), 사용성(Usability) 전반에 걸친 개선 사항을 다룹니다. * 일반적인 버그 수정(Bug-squishing) 과정을 상세히 공유하여 디스코드 사용 환경을 최적화하는 과정을 투명하게 보여줍니다. ### 커뮤니티 기반의 버그 리포팅 체계 * 레딧(Reddit)의 r/DiscordApp 서브레딧에서 운영되는 '격월 버그 메가스레드(Bimonthly Bug Megathread)'를 통해 사용자 피드백을 직접 수렴합니다. * 사용자가 발견한 버그를 제보하면 디스코드 엔지니어링 팀이 이를 직접 검토하고 해결하는 프로세스를 갖추고 있습니다. ### 수정 사항의 배포 및 반영 프로세스 * 패치 노트에 기재된 모든 수정 사항은 이미 코드 베이스에 커밋(Committed) 및 병합(Merged)이 완료된 상태입니다. * 다만, 기술적인 배포 방식에 따라 개별 플랫폼(PC, 모바일, 웹 등) 및 사용자별로 실제 업데이트가 반영되는 시점에는 차이가 있을 수 있습니다(Rolling out). 사용 중인 디스코드에서 기술적인 결함을 발견했다면 공식 레딧의 메가스레드를 적극 활용하여 제보하시기 바랍니다. 패치 노트에 언급된 기능이 아직 보이지 않는다면, 플랫폼별 순차 배포가 진행 중일 수 있으므로 최신 버전 업데이트를 주기적으로 확인하는 것이 좋습니다.