DevOps vs. SRE vs. 카오스 엔지니어링

첫모임에 이어 카오스엔지니어링 커뮤니티 두번째 모임을 개최했습니다.

이번 모임에서는 카오스 엔지니어링에 대해 현업에서 느끼는 바를 장경철 (NC소프트), 이창욱 (포시어코리아) 두 분이 발제를 해주셨습니다. 먼저 이창욱님은 스타트업 수준에서 카오스 엔지니어링 도입에 대해 도구 중심으로 이야기해 주셨습니다.

소개해 주신, PowerfulSeal은 Kubernetes 클러스터에 장애를 주입하므로 가능한 한 빨리 문제를 감지 할 수 있습니다. 완전한 카오스 실험 시나리오를 작성할 수 있는데, 이러한 도구가 많이 나와야만 스타트업 같은 작은 조직에서도 활용 가능할 것 같습니다.

두번째 발제는 중견 게임 업체에서 데브옵스 엔지니어로 일하는 장경철님이 넷플릭스와 AWS의 장애 사례와 그 포스트모템을 중심으로 어떤 일이 있었는지 재미있게 소개해 주셨습니다. 아무래도 넷플릭스가 왜 카오스 엔지니어링이라는 극한의 기법까지 도입하게 되었는지 잘 설명해 주셨습니다.

클라우드 기반 인프라에 대한 접근 방법에 큰 화두 중 하나는 SRE(사이트 신뢰성 엔지니어링 )에 대해서도 잘 설명해 주셨습니다. 카오스 엔지니어링 보다는 SRE에 대한 관심이 더 높아져있는 추세이고 많은 분들이 책을 통해 어느 정도 인지하고 계시더라구요. 그러다 보니 몇 가지 토론 주제들이 나왔습니다.

Q: DevOps vs SRE(Site Reliability Engineering) vs. Chaos Engineering?
데브옵스와 SRE의 관계에 대해서는 SRE를 소개하는 과정에서 나옵니다. DevOps의 공식 정의는 “소프트웨어 개발과 운영을 통합하는 것을 목표로 하는 개발 문화 및 원칙”이며, SRE는 구글에서 소프트웨어 엔지니어가 이전에 운영이라고 부르던 작업을 맡을 때 일어나는 일을 정의한 개념으로 흔히 DevOps가 문화라면, SRE는 이를 실행하는 도구로 말하고 있습니다.

두 가지 원칙은 사실상 같은 목표를 가지고 있지만, 몇 가지 차이가 있습니다. 데브옵스 개념은 기존 개발/운영의 분리의 사일로 조직을 줄이면서 개발/배포 중 문제 발생 확률을 줄이려는 데 집중하고, SRE는 실제로 문제를 어느 정도 허용하고 그 서비스 수준 지표를 관리한다는 차이가 있습니다. (실제 문제는 언제든지 일어나고 비지니스 영향도만 낮으면 되는 것이죠.) 그 외에 인프라 자동화, 모니터링 등은 모두 비슷합니다. 카오스 엔지니어링은 SRE와 이해를 같이하면서도 여기서 한발 더 공격적으로 나아갑니다.

장애의 발생 확률을 낮추는데 머물지 않고, 실제로 일어날 수 있는 문제를 모두 적극적으로 밝히는 것이죠. 고객에 영향을 미치는 여파에 대해서는 SRE도 어느 정도 인정하고 있고, 카오스엔지니어링에서는 프로덕션의 일부 서비스나 전체 서비스에 대해 장애를 직접 주입합니다. 장애가 일어나지 않으면 알 수 없는 일들을 찾아내는 것이죠.

DevOpsSREChaos Engineering
주요 관심개발 배포 과정 통합확장성, 운영 지표, 자동화예측 가능성, 장애 복원성
담당자개발에 관심 있는 운영팀운영에 관심 있는 개발팀 마이크로서비스 운영팀
측정 지표주로 시스템 Telemetry 서비스 수준 목표(SLO)의 최대/최소치 (SIO)비지니스에 영향에 대한 최소 수치
적용 기업온-프레미스에서 클라우드로 전향하는 기업클라우드-네이티브 환경에서 IT 서비스 기업마이크로서비스 환경으로 이전한 기업
데브옵스 vs. SRE vs. 카오스 엔지니어링 비교 도표 (by Channy)

Q: 실 서비스 중 장애 주입에 대한 태도와 요건은?
많은 분들이 가진 의문입니다. 실 서비스에 장애가 주입되면, 당연히 고객이나 사용자에게 여파가 갈텐데 어떻게 시행하냐는 거죠. 경영진들이 이해를 못할 것이라는 이야기입니다. 그런데, 넷플릭스를 비롯 실제로 이를 시행하는 기업들이 많이 있습니다. 이를 위해서는 몇 가지 전제가 필요한데요. 

우선 클라우드-네이티브 아키텍처를 가지고 어느 정도 장애 복원성을 확보해야 한다는 점입니다. 데이터 센터에 서버 한대를 켜 놓고 장애를 주입할 수는 없는 것이죠. 두번째는 마이크로 서비스 아키텍처(MSA)를 구성하여 장애의 전파 반경을 줄여야 합니다. MSA 구조는 서킷 브레이크, 폴백 등을 통해 다른 서비스의 장애와 차단하는 능력을 얻을 수 있습니다. 그렇다면, 실 서비스에 장애를 주입하더라도 그 여파가 줄어들 수 있습니다.

세번째는 실 서비스 장애 주입 전에 많은 테스트를 해야 한다는 것입니다. 소방관들이 화재를 대비한 훈련을 하듯이 테스트 장비, 일부 서비스, 실 서비스 등에 단계적으로 시나리오를 가지고 접근해야 합니다. 이러한 훈련을 Game Day라고 부르기도 합니다. 

Q: 개발자의 몫인가? 운영자의 몫인가 아니면 DevOps의 몫인가?
데브옵스, SRE, 카오스 엔지니어링 모두 같은 목표를 지향합니다. 누군가 맡을 일이 아니라 모두가 관심을 가져야 할 일입니다. 데브옵스는 적어도 기존 온-프레미스 환경에서 클라우드로 이전하는 기업들이 1차적으로 관심을 가져야 할 방법론이고, SRE는 클라우드 환경에서 모놀리식 기반 애플리케이션의 장애의 발생에 대한 예측 및 관리에 중점을 두는데 초점을 맞추었다면, 카오스엔지니어링은 마이크로서비스 환경으로 이전하는 단계에서 좀 더 적극적으로 도입할 수 있는 방법으로 생각하면 좋을 듯 합니다.

오늘 오신 분들을 중심으로 활동 계획도 세웠습니다. 앞으로 3개월 동안 시중에 나와 있는 카오스 엔지니어링 도구와 무료로 배포된 전자책을 요약해 보는 시간을 가지려고 합니다.

  • 3월 Chaos Monkey: 변정훈 / Game day in Action: 윤석찬
  • 4월 Gremlin: 김신 / Chaos Engineering e-Book 요약: 인보석
  • 5월 kube-monkey: 장경철 / PowerfulSeal: 이창욱

관심 있으신 분들은 페이스북 혹은 밋업 닷컴에 가입해 주시면 감사하겠습니다. 오늘 많은 분들이 오셔서 조금 놀랐는데요. 앞으로도 같이 배우고 공부하면 좋겠네요.

세번째 모임 공고

Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources.)

- ;