카오스 엔지니어링

소개: 소개: 혼돈의 탄생

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

카오스 엔지니어링( )은 소프트웨어 개발 분야에서 아직 비교적 새로운 분야입니다. 이 소개에서는 카오스 엔지니어링의 소박한 시작부터 모든 주요 산업에서 어떤 형태로든 카오스 엔지니어링을 채택하고 있는 현재에 이르기까지 그 역사를 설명합니다. 지난 3년 동안 질문은 "카오스 엔지니어링을 해야 하는가?"에서 "카오스 엔지니어링을 시작하는 가장 좋은 방법은 무엇인가?"로 바뀌었습니다.

초기 학문의 역사는 우리가 첫 번째 질문에서 방금 제기한 두 번째 질문으로 어떻게 전환했는지 설명합니다. 단순히 사실관계를 바로잡기 위해 날짜와 동기에 대한 이야기만 하려는 것이 아닙니다. 우리는 이것이 어떻게 등장했는지에 대한 이야기를 들려줌으로써 왜 그런 방식으로 등장했는지, 그리고 그 경로에서 어떻게 배울 수 있는지 이해하여 실무에서 최대한의 효과를 얻을 수 있도록 돕고자 합니다.

이 책의 저자인 케이시 로젠탈과 노라 존스는 카오스 팀에서 카오스 엔지니어링을 정의하고 전파할 때 근무했던 넷플릭스에서 이야기를 시작합니다.¹ 넷플릭스는 카오스 엔지니어링에서 실질적인 비즈니스 가치를 발견했고, 이를 다른 사람들이 알게 되면서 카오스 엔지니어링을 기술 분야 전반으로 확산하기 위한 커뮤니티가 형성되었습니다.

강령으로서의 관리 원칙

넷플릭스는 2008년 을 시작으로 데이터 센터에서 클라우드로 전환하는 과정을² 데이터 센터에서 Cloud로 이전하는 것을 공개적으로 발표했습니다. 그해 8월, 데이터센터의 대규모 데이터베이스 손상으로 인해 Netflix는 3일 동안 DVD를 배송할 수 없었습니다. 이 시기는 스트리밍 비디오가 보편화되기 전으로, DVD 배송이 사업의 대부분을 차지했습니다.

당시에는 데이터센터가 대규모 데이터베이스와 같은 단일 장애 지점과 수직적으로 확장된 구성 요소로 이루어진 아키텍처에 갇혀 있다고 생각했습니다. Cloud로 이전하면 수평적으로 확장된 구성 요소가 필요하며, 이를 통해 단일 장애 지점을 줄일 수 있습니다.

모든 것이 계획대로 진행되지는 않았습니다. 우선, 데이터센터에서 완전히 빠져나오는 데 8년이 걸렸습니다. 더 큰 문제는 수평적 확장 Cloud 배포 관행으로의 전환이 기대했던 스트리밍 서비스의 가동 시간 향상과 일치하지 않았다는 점입니다.³

이를 설명하기 위해 2008년에는 Amazon 웹 서비스(AWS)가 지금보다 훨씬 덜 성숙했다는 점을 상기해야 합니다. Cloud 컴퓨팅은 아직 상품이 아니었고, 지금처럼 당연한 기본 배포 옵션도 아니었습니다. 당시 Cloud 서비스는 많은 가능성을 내포하고 있었는데, 그 중 하나가 인스턴스가 가끔씩 사라진다는 것이었습니다.⁴ 가 때때로 경고 없이 사라진다는 것이었습니다. 이러한 특정 형태의 장애 이벤트는 강력한 대형 머신을 잘 관리하고 특정 머신의 특성을 잘 알고 있는 데이터센터에서는 드물게 발생했습니다. 하지만 상용 하드웨어에서 실행되는 ...