[reinvent 2024] 혼돈 공학: 시스템 복원성에 대한 선제적 접근법

들어가며

가정(Assumption)에 대한 검증과 편향(Bias) 극복의 중요성

카오스 엔지니어링을 ‘시스템이 실제 프로덕션 환경에서 겪을 수 있는 혼란스러운 상황을 견뎌낼 수 있는지에 대한 확신을 쌓기 위해 실험하는 하나의 규율(discipline)’로 정의하고 있습니다. 단순히 시스템이 정상 작동하리라 추측하거나 낙관하는 것이 아니라, 실제로 불안정한 상황을 주입함으로써 우리 가정이 얼마나 현실적인지 끊임없이 점검하는 것이며, 이를 ‘가정 검증’이라고 합니다.

우리가 어떤 시스템의 특성에 대해 가설을 세웠다면, 반드시 실제 실험을 통해 이를 확인하고, 그 결과로 새로운 지식을 얻어 다시 가설을 수정·보완해야 합니다. 즉, 단 한 번의 검증으로 끝나는 것이 아니라, 지속적으로 선입견과 편향을 걷어내며 진짜 안정성을 확보하는 과정을 거쳐야 합니다.

가장 인상 깊었던 첫 번째 포인트는 우리가 시스템을 설계하고 운영할 때 흔히 저지르는 “편향”과 “잘못된 가정”에 대한 문제 제기였습니다. 네트워크 지식이나 운영체제 원리에 능숙한 솔루션 아키텍트라고 해도, 새로운 기능이나 패치를 적용할 때 우리는 종종 특정 상태가 항상 유지될 것이라 믿거나, 특정 에러 상황이 일어나지 않을 것이라고 넘어가는 상황이 생길 수 있습니다만, 현실은 그렇지 않습니다.

세션에서 예로 든 파이썬 requests 라이브러리의 디폴트 타임아웃 문제, 또는 .NET 웹 요청의 상대적으로 긴 기본 타임아웃은 단순한 설정 하나가 전체 서비스 품질에 얼마나 큰 영향을 미칠 수 있는지를 잘 보여줍니다. 이는 엔지니어의 선입견이나 “설마 이렇게 되겠어?”라는 낙관적 가정을 여지없이 깨뜨리는 사례입니다. 실제 장애 상황에서, 무한히 기다리는 HTTP 요청은 장애를 전파하고, 사용자 경험을 훼손하며, 결국 비즈니스 비용을 상승시킵니다.

따라서 카오스 엔지니어링의 핵심은 단순히 결함을 주입하는 행위가 아니라, 그 과정을 통해 우리가 숨겨둔 가정을 밝히고, 이를 검증하는 것입니다. 사람은 흔히 최신 기술이나 재미있는 기능에 끌리는 경향이 있습니다. 이는 의도치 않게 중요하지만 지루한 안정성 관련 요소를 간과하게 만듭니다. 세션에서 강조한 메시지는 명확했습니다. “데이터는 거짓말하지 않는다.” 시스템의 실제 반응, 즉 메트릭, 로깅, 모니터링 지표를 통해 우리는 우리의 가정이 옳았는지 틀렸는지 명확히 확인할 수 있습니다.

이를테면, 캐시 서버에 지연을 인위적으로 주어본 뒤, 예상대로 애플리케이션이 데드락 없이 즉시 데이터베이스로 폴백하는지, 혹은 무한 대기에 빠지는지를 확인해볼 수 있습니다. 이렇게 실험적인 접근을 통해 우리는 “기본 타임아웃이 없으면 문제가 생길 것이다”라는 가정을 증명하거나, “이 정도 상황에서는 시스템이 알아서 복구할 것”이라는 낙관적 믿음을 배제할 수 있습니다. 편향을 걷어내고, 검증된 신뢰성을 확보하는 것, 이것이 카오스 엔지니어링을 시작하는 첫번째 단계입니다.

복구 능력(Recovery Skill)의 단련과 게임데이(Game Day)의 가치

기업 대다수(90%)가 한 시간의 다운타임으로 약 30만 달러를 손실하며, 심한 경우 한 시간에 100만에서 500만 달러를 잃는 기업도 약 41%에 달합니다. 이는 단순한 지연이나 기능 저하가 아닌, 실질적 금전적 손실과 직결된다는 점을 여실히 보여줍니다. 또한 자주 장애를 겪는 기업은 그렇지 않은 기업보다 장애 비용이 최대 16배 더 높다는 통계는 복구 능력이 곧 비용 효율성과 연결된다는 점을 명확히 합니다.

다시 말해, 장애가 발생했을 때 단순히 “시스템을 재시작하고 기다리는” 소극적 대응으로는 현재의 복잡한 환경을 극복하기 어렵습니다. 효율적인 복구 능력을 갖춘 조직은 더 적은 비용, 더 짧은 다운타임, 더 높은 고객 만족도를 달성합니다.

감지(Detection) – 평가(Evaluation) – 대응(Response) – 복구(Recovery) – 확인(Confirmation)’으로 이어지는 장애 대응 프로세스에서, 장애 직후에는 스트레스 지수가 급등하고, 시간이 지날수록 해당 상황을 평가하고 대응하는 과정이 이어집니다. 이 기간동안 팀원들은 높은 심리적 압박감을 받게 되며, 복구 단계에 이르러야 비로소 시스템이 원래 상태로 돌아올 수 있습니다.

하지만 이 과정에서 임기응변이나 단발성 해결책에 의존한다면, 향후 유사한 장애가 반복되었을 때 동일한 실수를 되풀이하거나 더 큰 손실로 이어질 수 있습니다. 결국 이 스트레스 곡선을 누그러뜨리고, 효율적으로 대응하기 위해서는 사전에 팀 차원에서 ‘훈련된 복구 능력’이 필요합니다.

여기서 게임데이(Game Day)가 등장합니다. 게임데이는 단순히 “시뮬레이션 실험”이 아니라, 팀 전반의 운영 역량을 점검하는 전투 훈련과도 같습니다. 예를 들어, AWS의 Jesse Robbins가 시행한 게임데이 사례처럼, 의도적으로 특정 의존성이나 인프라 요소를 비활성화하고 팀원들이 이를 어떻게 감지하고, 대응하며, 복구하는지를 실시간으로 연습할 수 있습니다. 이는 단순히 기술적 역량뿐 아니라, 커뮤니케이션, 결함 분석 능력, 복구 절차 표준화, 정보 공유 문화 개선에 크게 기여합니다.

결국 목표는 장애가 실제로 닥쳤을 때, 당황하지 않고 신속하게, 이미 훈련된 절차대로 문제를 해결하도록 하는 데 있습니다. 게임데이를 통해 팀은 복구 능력을 단련하고, 실제 장애 때보다 더 빠르고 정확하게 대응할 수 있게 됩니다. 이는 가용성 목표 달성, 고객 경험 개선, 나아가 비즈니스 연속성 확보에도 직접적으로 기여하는 부분입니다.

BMW 예제를 통한 복원력 확보 전략 탐구

최근 자동차 산업은 단순한 이동 수단을 넘어 끊임없이 연결되고 진화하는 “모바일 디바이스”로서의 차량 시대를 맞이하고 있습니다. 이 흐름 속에서 BMW는 전 세계적으로 2천3백만 대 이상의 커넥티드 차량(Connected Vehicles)을 운영하며, 이 수치는 앞으로 2년 내에 세 배 이상 증가할 전망입니다. 하루에만 140억 건 이상의 요청(Request)이 처리되고, 1,300개가 넘는 마이크로서비스(Microservices)들이 유기적으로 작동하며, 매일 197 TB에 달하는 데이터가 플릿(Fleet)에 전달됩니다. 그럼에도 안정성은 99.95%라는 높은 가용성을 유지하고 있습니다.

BMW는 차량과 백엔드 사이에서 메시지 전송을 담당하는 MQTT 서비스에 고의적으로 높은 트래픽을 유도하여, 시스템이 과부하 상태에서 어떤 반응을 보이는지 관찰했습니다. 그 결과, 트래픽이 몰릴 때 서비스 응답이 지연되고, 클라이언트 측에서 재시도 요청이 증가하는 문제가 발견되었습니다. 이는 실시간 데이터 전송이 중요한 차량 통신 시스템에서 심각한 병목을 초래할 수 있는 상황이었죠.

이를 해결하기 위해 BMW는 소프트웨어 공급업체와 협력해 MQTT 서비스의 기본 구성을 재점검하고, 메시지 처리 로직과 재시도 정책을 개선하는 등 성능 최적화에 착수했습니다. 결국 이 문제 파악을 통해 BMW는 향후 더 탄탄한 실시간 커뮤니케이션 환경을 구축할 수 있게 되었고, 이는 궁극적으로 고객 경험 개선으로 이어질 것으로 기대됩니다.

또한 BMW는 한 가용 영역 내의 모든 리소스를 의도적으로 종료하는 시나리오를 수행했습니다. 여기서 기대했던 것은 장애가 발생한 영역을 제외한 나머지 AZ들이 문제없이 서비스를 이어받는 것이었습니다. 하지만 실제 실험 결과, EBS 볼륨이 특정 가용 영역에 종속되어 있어, 클러스터가 새로운 노드를 다른 영역에 띄우는 동안 애플리케이션 오류가 발생하는 문제가 드러났습니다. 이로써 BMW는 EBS 볼륨의 영역 의존성이 장애 복구에 걸림돌이 될 수 있음을 명확히 인식하게 되었고, 이를 개선하기 위해 멀티 AZ 지원 확장이나 자동 장애 전환 전략 등을 모색하기 시작했습니다.

결론