[re:Invent 2019 번외편] Chaos Engineering with Gremlin #reinvent

안녕하세요! 클래스메소드 주식회사 의 김태우입니다!

최근에 카오스 엔지니어링에 부쩍 관심이 늘어서 어제의 Meetup에서 들었던 Gremlin 부스에 찾아가보았습니다. 어제 이야기 나눈 분들이 계셔서 반갑게 인사하면서 실습을 진행할 수 있는 AWS 환경과 Gremlin 환경을 제공받았습니다.

카오스 엔지니어링이라는 용어를 들어보신 분들은 꽤 계실 것 같은데, 어떤 내용인지를 알고 계신분들은 잘 없을거라 생각됩니다! (왜냐하면 Gremlin 이라는 회사가 카오스 엔지니어링의 사실상의 선구자인데, 한국이나 일본에는 고객이 거의없다고 하더라구요...ㅎㅎ)

본 포스팅에서는 카오스엔지니어링과 Gremlin 에 대한 간단한 소개 및 Gremlin 의 기능에 대해 소개드리겠습니다!

목차

What the heck is Chaos engineering?

개발자이신분들은 너무나 익숙하고 필요하다고 생각하면서도 잘 실천하지 못하는 테스트. 코드가 정상적으로 작성하는지를 테스트하기 위해 테스트 코드를 작성하는 걸 좋아하시는 분들도 계시겠지만(정말 계신가요..?) 대부분은 시간적 여유와 여러가지 환경속에서 유닛테스트 정도만 작성하고 통합테스트, 시나리오 테스트 등 다른 테스트는 그때그때마다 해결하는 경우가 많은 줄로 압니다. 그렇지만 어쨌든 코드를 짜면, 테스트를 자동화 할 수 있다는 건 무척 좋고 편리한 일이죠.

그렇다면 인프라 레벨에서는 어떤식으로 테스트를 해야할까요? 개발한 코드가 동작하고 있는 인프라가 장애가 일어난다면? CPU 나 메모리등의 리소스가 특정 임계치 이상 사용될때 서비스에 장애가 생기지 않을까요? 어떠한 이유에서든지 특정시간 이상의 latency 가 발생한다면 서비스는 과연 안정적으로 버텨낼 수 있을까요? DB 가 뻗으면? 어떠한 이유에서인지 호스팅되고 있는 VM 자체가 죽어버린다면?

전혀 예상하지 못하게도 인프라에도 장애가 종종 일어납니다. AWS 도 예외는 아니죠. 따라서 AWS 에서는 DR(Disaster Recovery) 관련한 화이트페이퍼 나 다양한 교육지원을 통해 사용중인 인프라에서 장애가 일어날 수 있을때 극복할 수 있는 여러가지 전략과 방법론에 대해 자세히 설명해줍니다.

하지만 DR 대책을 잘 세워두고, 이를 이미 실제 인프라에 다 적용해두었다고 하더라도 실제로 장애가 일어나지 않는이상, 정말로 내가 설정한 DR 대책이 장애시에 문제없이 완벽하게 동작할 지에 대한 확신은 할 수가 없습니다. 또한, 장애가 일어났을때 생각지 못한 곳에서 원인이 되어 서비스에 영향을 주는 경우도 흔하고, 내가 세운 대책만으로는 부족한 경우가 많습니다. 즉, DR 전문가가 아닌 이상에야 DR 대책을 세워도 그것에 대해 확신할 수 없습니다.

개발 측면에서의 코드의 경우, 아예 적극적으로 테스트를 하자라는 TDD(Test-Driven Development) 라는 개발 문화가 있죠. 다들 아시다시피 먼저 테스트 케이스를 작성해두고, 실패하는 테스트 케이스부터 시작해서 실제 코드를 작성하는 방법론입니다. 인프라의 경우에도 비슷하게 적극적인 장애 대책에 대한 문화이자 프랙티스가 있습니다. 이게 바로 카오스 엔지니어링이라고 불리는 개념입니다. 멀쩡한 인프라에 일부러 장애를 발생시키는 무언가를 주입시켜서 다양한 리소스와 상태 등에 대해 장애를 일으키고, 장애가 발생해도 견뎌낼 수 있는 인프라 구성이라면 실제 환경에 디플로이하자! 라는 개념이죠. (물론 좀 더 나아가서 ChaosMonkey 를 사용해서 프로덕션 환경에서 항상 장애를 일으켜서 항상 장애에 대한 면역을 갖게하자! 라고하는 수준의 굉장한 수준의 카오스 엔지니어링도 있습니다만 이 글에서는 다루지 않습니다.)

그러나 인프라의 경우 테스트 코드처럼 간단히 그러한 장애를 일으키는 무언가의 도구를 만드는게 귀찮고, 너무 범위도 넓고, 만들어도 재사용하기가 어려운 경우가 대다수입니다만 범용적으로 사용할 수 있는 굉장히 직관적이고 사용하기 쉬운 툴이 바로 Gremlin 입니다.

본 글에서는 re:Invent 중에 제가 진행했던 Gremlin 튜토리얼과 함께 Gremlin 에 어떤 기능이 있는지 살펴보겠습니다.

Gremlin Tutorials

Gremlin 은 다양한 시나리오에 대한 튜토리얼 을 제공합니다. 제가 진행했던 튜토리얼은 AWS re:Invent 행사 중에만 진행했던 프라이빗 튜토리얼이라 검색해도 나오지는 않지만 우선 링크는 이곳이었습니다. (링크가 언제까지 살아있을지는 모르겠습니다.)

먼저 AWS 및 Gremlin 환경 세팅을 진행합니다. 세팅을 마치고 CloudWatch Container Insight 로 들어가보면 아래와 같은 화면이 나옵니다.

세팅이 끝났으므로 본 실습으로 넘어갑니다. 대상은 EKS 위에서 동작하는 양말쇼핑몰입니다.

엔드포인트를 통해 실제로 접속해보니 어처구니가 없이 웃음이 나오는 양말들이었습니다ㅎㅎ

Gremlin Attack

Gremlin 에서는 다양한 대상에 다양한 종류의 attack 을 지원합니다.

우선 대상으로는 Hosts, Containers, Applications, Kubernetes 를 지정할 수 있네요.

Containers 의 경우에는 태그나 직접 지정이 가능한 것 같습니다.

특정 Containers 가 지정되었다면, 실제로 어떤 종류의 attack 을 할지를 정합니다. 하나의 attack 은 하나의 종류의 attack 만 지정가능하고, 뒤에서 설명할 scenario 에서 다양한 어택을 묶어서 시나리오로서 실행할 수 있습니다.

리소스, 상태, 네트워크와 관련된 다양한 어택과 함께 그에 맞는 애트리뷰트를 설정할 수 있습니다. 예를 들어, 위의 화면에서는 Network 의 Latency 공격을 하고, 5분간 일부러 1초동안 latency 를 지연시키는 설정입니다. (1초를 설정하는 부분은 화면에서 잘렸지만, 우측 상단에 1000 이라는 숫자가 ms 단위로 1초가 지정되었음을 확인할 수 있습니다.)

이렇게 해서 Unleash Gremlin 이라는 버튼을 누르면 Gremlin 이 실행되면서 진행되는 상황을 확인 할 수 있습니다. 테스트가 진행됨과 동시에, 메트릭을 확인하거나, 직접 서비스를 이용해보며 (이부분은 테스트 자동화를 통해 간편하게 진행할 수 있을 것 같습니다.) 해당 공격이 서비스에 장애를 일으키지 않는지 확인하며 특이사항을 Gremlin 에 메모를 통해 기록할 수 있습니다. 실행했던 기록은 성공/실패 유무와 메모 등과 함께 저장되고 나중에 참조할 수 있도록 리스트로 제공됩니다.

Gremlin Scenario

Scenario 는 말그대로 시나리오를 적용해서 카오스 엔지니어링을 실현하는 기능입니다. 화면 스크린샷을 직접 보면 직관적으로 어떤 기능인지 알 수 있습니다.

시나리오명과 설명, 그리고 해당 시나리오에서 무엇을 가정하는가를 적는 란이 있습니다. 위의 스크린샷은 Auto Scaling 을 위한 시나리오 작성의 한 예입니다.

기존에 만들어두었던 attack 이나 신규로 즉석에서 attack 을 생성해서 붙여넣을 수도 있습니다.

선택적으로 스케줄을 설정할 수도 있습니다.

Gremlin + CI/CD 통합

Gremlin 은 API 를 제공하고 있어서 스크립팅이 가능한 CI/CD 툴이라면 Gremlin 스테이지를 별도로 작성할 수가 있습니다. 혹은, Spinnaker 의 경우 네이티브로 Gremlin 스테이지를 선택가능하고, 다양한 옵션을 지정할 수가 있어서 편리하게 사용할 수 있습니다.

마치며

생각보다 굉장히 간단하고 직관적인 Gremlin 의 인터페이스를 직접 경험해볼 수 있는 유익한 시간이 되었습니다. 개발자의 덕목중의 하나가 테스트에 관련한 것들이라면, 인프라 엔지니어도 이제는 카오스 엔지니어링을 받아들이고 적극적으로 DR 에 대처할 수 있어야하지 않을까 싶습니다.

그럼, 이상 컨설팅부의 김태우였습니다.