AWS FIS를 사용한 카오스 엔지니어링

AWS Hands-on Lab #5 : AWS FIS를 사용한 카오스 엔지니어링(Chaos Engineering)

Written by Minhyeok Cha

오늘은 AWS 서비스 중 간단하게 서버의 스트레스 테스트 진행을 하는 서비스인 FIS(Fault Injection Simulator)를 확인하려고 합니다.

AWS FIS는 애플리케이션 내부에서 강제로 장애를 주입하여 시뮬레이션 후 시스템의 강건성(robustness)과 신뢰성을 향상하는 데 도움을 주는 서비스입니다. 클라우드 환경에서의 장애 상황을 대비하고 애플리케이션의 장애를 식별하고 탄력성을 실험하기 위해서도 꼭 필요한 카오스 엔지니어링 도구입니다.

카오스 엔지니어링(Chaos Engineering)이란?

서비스가 다운되기 전에 장애를 식별하기 위한 방법으로, 스트레스 테스트를 진행하며 시스템이 어떻게 반응하는지 사전에 테스트를 진행해 오류를 식별하여 prod에 올라가기 전 서비스를 수정할 수 있습니다.

카오스엔지니어링을 사용하면 사용자가 생각한 대비 결과(예: 50명의 동시 접속자 - 3초 안에 접근, 이를 통한 응답 시간, 통과/실패 트랜잭션 수, 메모리 사용률 등)와 시스템에서 실제로 발생하는 결과를 비교할 수 있습니다.

이러한 수치를 얻기 위해 일부러 서버에 데미지를 가하는 방법이 카오스 엔지니어링입니다.

카오스 엔지니어링을 Prod에 맞춰 사용하기

그렇다면 AWS 안에서의 카오스 엔지니어링을 다루기 위해서는 어떻게 해야 할까요?

실제로 카오스엔지니어링 프로세스는 다음과 같습니다.

1. 장애 가설 예상 시스템 내부에 잠재적인 약점이나 문제를 예측합니다. 카오스엔지니어링 실험을 실시할 목표를 설정하는 첫 번째 단계이며 어떤 종류의 장애 시나리오를 시뮬레이션할지 결정합니다.

2. 테스트 위에서 작성된 가설 템플릿을 바탕으로 테스트 환경을 구성합니다. (서버 중단, 네트워크 부하 강제 주입 등)

3. 결과 확인 테스트 된 시스템의 동작과 성능에 대한 결과를 확인합니다. (문제를 인지한 시간과 알림 시간, 자동 롤백 시점, 전체 복구 및 안정화 시간 등

4. 수정 및 해결 결과 값을 갖고 식별한 문제를 해결하고 개선하기 위한 조치를 취합니다.

AWS FIS란?

장애를 강제로 주입할 때 각 리소스 단위부터 네트워크, 가용 영역으로 테스트를 넓혀갑니다.

그리고 해당 장애를 대비하는 롤백 계획까지도 구성해야 하는 것이 AWS FIS 템플릿 생성의 핵심입니다.

작업 설정

대상 리소스에 오류를 강제로 주입할 활동을 설정합니다. AWS FIS에서는 다양한 실험 템플릿이 있으며 간단하게 기존 서버를 타겟 인스턴스를 다운시켜 Scaleout 기능 작동 확인부터 서버 속성 (CPU, disk, memory), 네트워크 관련 패킷 손실, 강제 지연 및 누락 등 다양한 작업 유형들이 있습니다.

💡 AWS FIS에서 사용 가능한 SSM문서를 확인할 수 있으며 뿐만 아니라 ECS, ESK, RDS 등 다양한 템플릿이 있습니다. 

하나의 템플릿에 여러 작업을 겹쳐서 사용이 가능하며 사용된 작업 유형이 SSM의 문서를 사용하기 때문에 FIS 대상이 된 서버는 SSM Agent가 설치되어 있어야 합니다.

💡 현재 사용된 작업을 확인하면 Disk와 Memory가 있습니다. 이는 기존 CloudWatch에서 확인이 안 되기 때문에 CloudWatch 에이전트를 별도로 설치해야 모니터링(중지 조건)이 가능합니다.
   

사용된 FIS - SSM 문서

작업 프로세스는 위에서 사용된 SSM에서 지급되는 문서를 확인했습니다. 총 4개를 사용했으며 그중 대표로 Memory 관련 설명을 확인하였고 내용은 해당 스트레스 테스트 툴은 “stress-ng”라는 툴을 사용한다는 것과 필요한 변수 기입이 있다는 것을 확인했습니다.

중지 조건

작업 설정이 끝나면 실험을 안전하게 실행하기 위한 중지 조건을 선택합니다. 이는 CloudWatch 경보에서 미리 정의된 임계값에 도달하면 실험을 종료하도록 제한을 설정합니다.

임계값에 도달하면 실험 자체가 취소되고 서비스가 즉시 다시 시작됩니다.

직접 사용 후 느낀 점

FIS 타임라인

하나의 템플릿에 단일 리소스를 대상으로 여러 작업을 적용할 때 동시에 돌리면 바로 실패가 됩니다.

💡 따라서 작업마다 다음 사진과 같이 이전 작업을 선택 후 작업이 진행되도록 조율해야 합니다.

변수 기입

단순히 SSM 런북으로 사용 중엔 기입하기 편한 상태로 출력되지만, FIS로 사용하면 직접 매개변수를 JSON 형식으로 넣어야 하므로 번거로움이 있습니다.

(좌) SSM 콘솔 파라미터 기업 | (우) FIS 파라미터 기입

마무리

이 블로그에서는 간단하게 카오스 엔지니어링이란 무엇인지와 AWS에서 쉽게 카오스엔지니어링을 구사할 수 있는 AWS FIS를 알아보았습니다. 스트레스 상황에서 시스템이 어떻게 반응하는지 사전에 테스트함으로써 오류를 식별하고 수정할 수 있습니다.

AWS FIS는 간단한 가용성 테스트 뿐만 아니라 EC2, ECS, EKS, RDS 서비스 장애 주입 및 API 오류, 단일 서버 장애 등의 다양한 작업과 모니터링, 실험 결과 공유 등이 가능합니다.

추가로 JSON/YAML 기반 실험 템플릿과 SSM를 사용하여 더 복잡한 카오스 엔지니어링을 설계할 수 있습니다.