서비스를 운영할 때 고객이 중단 없이 서비스를 이용할 수 있도록 이중화, 부하 분산, 캐싱등의 방법을 사용한다. 애플리케이션 비즈니스 로직을 프로그래밍 하고 단위 테스트, 통합 테스트를 수행하며 여러 테스트 케이스에 대한 대처가 이루어졌는지 확인하는 것처럼 클라우드 인프라 아키텍처 또한 요구사항이 잘 반영 되었는지 테스트 해야한다.
테스트 방법 또한 다양하다. IaC 코드를 테스트 할 수도 있고 직접 트래픽을 흘려보내며 시스템이 정상적으로 작동하는지 확인할 수도 있다. 코드 레벨에서 테스트를 하는 것도 중요하지만 직접 구축된 시스템에 스트레스를 주어 내가 예상한 문제 외에도 다른 문제점이 있는지 확인하는 것이 중요하다.
직접 장애를 주입하여 클라우드 인프라의 가용성을 확인할 수 있는 AWS Fault Injection Service로 카오스 엔지니어링 기법을 이용해 간단한 시스템을 테스트해보자.
카오스 엔지니어링이란 갑자기 발생한 장애 상황을 시스템이 견딜 수 있는지 테스트할 수 있는 훈련이다.
시스템 중단, 가용영역 셧다운 등의 재해가 발생했을 때 시스템이 어떻게 동작 하는지 확인하기 위해 의도적으로 장애를 유발하고 시스템의 반응을 살피고 문제를 개선하는 과정이다.
AWS Fault Injection Service(AWS FIS)는 AWS 리소스에 대해서 결함 주입 실험을 할 수 있는 서비스이다.
실험 과정을 정의한 실험 템플릿을 생성하고 실험을 시작하면 직접 정의한 이벤트를 실제 리소스에 수행하여 애플리케이션에 스트레스를 주는 방식이다.
실습에서 사용할 아키텍처는 AWS에 배포한 아파치 서버이다.
부하 분산을 위해 두 가용영역에 이중화 구성을 하였고, ALB를 이용해 라운드로빈 방식으로 트래픽을 분산한다.
직접 AWS 콘솔을 이용해 생성할 수도 있지만 실습 환경을 쉽게 생성하고 지우기 위해 IaC 도구인 terraform을 사용하여 구성한다. 모든 나머지 설정(헬스체크, 스케쥴링 방식 등)은 기본값을 사용한다.
#!/bin/bash
yum update -y
yum install -y httpd.x86_64
systemctl start httpd.service
systemctl enable httpd.service
echo “Hello World from $(hostname -f)” > /var/www/html/index.html
위 UserData를 EC2에 설정하여 EC2 생성 시 자동으로 아파치 서버를 실행하도록 구성한다.
생성 후 curl 명령어로 alb 퍼블릭 DNS 이름에 GET 요청을 보냈을 때 정상적으로 두 웹서버에 번갈아가며 트래픽이 분산되는 것을 확인한다.
구성한 서비스의 가용성을 카오스 엔지니어링 과정을 통해 테스트 해보자.
시스템의 정상 상태를 정의한다. 이번 실습에서는 95% 이상의 요청에 정상적인 200 OK 응답을 반환한다면 정상적인 상태
로 정의 해보겠다.
실제로 현재 시스템에 1초 간격으로 curl 요청을 5분동안 보냈을 때 5xx 에러가 나지 않는 것을 확인할 수 있다.
특정 변수에 의해 방해를 받을 경우 시스템이 어떻게 대응 하는지를 예측한다. 현재 이중화 구성이 되어있는 두 EC2 인스턴스 중 하나가 장애로 사용 불가가 되었을 때를 테스트 해볼 수 있다. 하나의 인스턴스가 장애가 나더라도 이중화 구성이 되어 있기 때문에 서비스는 문제 없이 정상 상태를 유지해야 할 것이다.
AWS FIS를 이용해 가설을 실험한다. AWS FIS에는 여러가지 실험 시나리오에 대해 미리 실험 템플릿이 만들어져 있어 실험을 할 수 있는 환경을 쉽게 구축할 수 있다.
AWS Fault Injection Service 콘솔이 접속하고 “시나리오에서 실험 생성” 버튼을 클릭한다.
시나리오 라이브러리에서 “EC2 스트레스: 인스턴스 장애” 항목을 클릭 후 “시나리오가 포함된 템플릿 생성” 버튼을 클릭한다.
AWS FIS는 EC2 인스턴스 태그를 기반으로 실험 대상이 될(장애를 만들) 인스턴스를 쉽게 선택할 수 있다. 기본값으로는 Ec2InstanceFailure=Allowed
태그가 있는 인스턴스에 장애를 만들어 실험할 수 있다.
다음 페이지에서 실험에서 사용할 IAM 역할을 만들고 이름을 지정해 실험 준비를 완료한다.
위에서 보는 것처럼 EC2 인스턴스에 장애를 일으키고, 시스템이 안정적으로 동작하는지 테스트 할 것이기 때문에 EC2 인스턴스 중 하나에 위에서 설명한 태그를 추가한다.
이제 “실험시작” 버튼을 클릭해 실험을 시작한다.
5분동안 시스템이 잘 동작하는지 확인하기 위해 로컬 PC 터미널에서 아래 스크립트를 이용해 curl요청을 반복적으로 보낸다.
while true; do curl test-alb-1312064039.ap-northeast-2.elb.amazonaws.com; sleep 1; done
실험을 시작하자 AWS FIS가 EC2 인스턴스를 종료시켰고 종료된 EC2 인스턴스가 대상 그룹에서 빠지는 약 10초간 6번의 장애응답을 제외하고는 정상적으로 정상적인 노드에 트래픽이 전달되면서 서비스가 안정을 찾은 것을 볼 수 있다.
약 2%의 요청에 대해서 5xx 에러가 났고 처음 정의하였던 95%의 정상 응답 요건을 충족하기 때문에 EC2 인스턴스 장애 상황에서도 가용성을 가지는 아키텍처임을 테스트할 수 있었다.