AWS 기술 블로그
Amazon EKS 워크로드의 지속적인 복원력 확인을 위한 카오스 엔지니어링 (Chaos Engineering)
카오스 엔지니어링은 실제 운영환경에서 발생하는 다양한 장애 상황을 견딜 수 있는 시스템을 구축하기 위해 시스템의 신뢰성을 실험하는 방법입니다. 대규모 분산 소프트웨어 시스템의 발전은 산업의 발전 방향을 바꾸고 있습니다. 엄청난 규모의 데이터를 기반으로 기계학습, 빅데이터 분석, 사물인터넷 등이 가능하게 되었습니다. 또한, 소프트웨어 엔지니링의 판도도 바꾸었습니다. 하나의 산업으로서, 우리는 개발의 유연성과 배포 속도를 높이는 모범 사례들을 빠르게 적용하게 되었습니다.
그러나 이러한 장점 이면에는, 운영에 배포한 복잡한 시스템에 대해 어느 정도 확신을 가질 수 있을 지에 대한 의문이 남게 됩니다. 분산 시스템 내의 모든 개별 서비스가 정상적으로 작동하더라도, 각 서비스 간의 상호 작용으로 인해 예기치 못한 결과가 발생할 수 있으며, 이러한 현상은 시스템 전체에서 비정상적인 행동으로 나타날 수 있습니다. 잘못 설정된 타임아웃 값으로 인한 지나친 재시도, 백엔드(Back-end) 시스템이 대규모 트래픽을 견디지 못해 발생한 장애, 한 지점의 장애로 인해 연달아 발생하는 장애 등의 문제 상황이 일어날 수 있습니다.
이와 같은 문제들이 실제 운영환경에서 고객 경험에 영향을 미치기 전에, 우리는 가장 중요한 약점들을 찾아내어 적극적으로 해결해야 합니다. 이러한 시스템에 내재된 문제요소를 관리하고, 유연성과 속도를 높여주며, 아무리 복잡할지라도 운영 환경에서의 배포에 확신을 가질 수 있는 과학적인 방법이 필요합니다. 그래서 과학적인 실험을 통하여 취약점을 미리 식별하고 예방 조치하는 일이 필요하며, 이러한 과정을 카오스 엔지니어링이라고 부릅니다. 카오스 엔지니어링은 시스템의 안정성을 높이고 근거있는 자신감을 가지기 위한 소프트웨어 엔지니어링 기법 입니다.
카오스 엔지니어링 실전
그림 1 카오스 엔지니어링 절차
안정 상태 정의
카오스 엔지니어링에서 안정 상태를 정의하는 것은 중요합니다. 시스템이 계획한 대로 잘 동작하여 서비스가 의도한 것과 같이 잘 운영되고 있다는 기준을 정의하는 것입니다. 기준을 정의해야 서비스에 문제가 없는 지 판단할 수 있기 때문입니다. 안정 상태를 정하는 기준으로 가장 많이 사용하는 것은 가용성 (Availability)과 응답 시간(Response Time)입니다. 사용자들이 서비스에 접속했을 때 사용 가능하다는 것이 매우 중요하기 때문에, 일반적으로 고가용성 (High Availability)을 안정상태로 정의했습니다.
최근에는 응답 시간을 안정 상태의 기준으로 보는 경우가 많아졌습니다. 단순하게 사용 가능하다는 것만으로는 고객 만족도를 높이기 어렵기 때문입니다. 만약, 어떤 상점이 정상 영업 중이지만 계산 대기 줄이 너무 길다면, 고객들이 다른 상점으로 이동하는 것과 같은 원리입니다. 가장 중요한 점은 안정 상태를 정의할 때, 단순히 시스템이 동작한다는 지표뿐만 아니라 비지니스와 연관된 지표를 함께 판단해야 한다는 것입니다.
가용성
서비스가 사용 가능하다는 것을 측정하기 위하여 가장 많이 사용하는 지표는 시간 기반 가용성 지표입니다. 측정한 전체 기간 대비 사용 가능했던 시간 비율을 계산합니다. 표와 같이 가용성 수준이 99% 이고 측정 기간이 1년이라면, 서비스를 사용할 수 없는 누적 시간은 3일 15시간 입니다. 그 시간보다 더 많은 시간동안 서비스를 사용하지 못했다면 서비스 수준 계약 (Service Level Agreement)을 지키지 못한 것이고, 계약된 내용에 따른 보상을 제공하게 됩니다.
하지만, 무조건 가용성을 높이는 것만이 좋은 것은 아닙니다. 서비스 가용성 수준을 높이기 위해서는 더 많은 IT 자원을 사용하고, 일관성 유지를 위한 설계가 포함되어야 하기 때문에 많은 비용이 들어갑니다. 따라서 서비스의 중요도에 따라 적절한 가용성 수준을 선택할 필요가 있습니다. 다음 표는 가용성 수준과 대표 애플리케이션을 보여 주고 있습니다.
| 가용성 수준 | 최대 장애 시간(연간) | 대표 어플리케이션 종류 |
| 99% | 3일 15시간 | 배치 프로세싱, 데이터 ETL(Extract-Transfer-Load) 작업 |
| 99.9% | 8시간 45분 | 내부 활용 도구(문서 공유, 프로젝트 관리) |
| 99.95% | 4시간 22분 | 온라인 커머스, Point of Sale |
| 99.99% | 52분 | 비디오 전송, 방송과 같은 미디어 서비스 |
| 99.999% | 5분 | 은행 자동화 기기 또는 통신 사업 서비스 |
표 1 가용성 표
가설 수립
가설 수립 단계에서는 기본적으로 시스템이 안정 상태를 유지 할 것이라는 가설을 세웁니다. 아키텍처가 고가용성을 지원하도록 설계했는데, 기대한대로 동작하는 지 검증해야 하기 때문입니다. 필요에 따라서는 시스템이 예상한 방식대로 예외를 발생시키는 지 확인하는 가설을 세울 수도 있습니다. 단위 테스트를 할 때, 예외가 발생하면 테스트가 실패하는 것 뿐아니라 기대한 예외가 발생하는 테스트를 하는 것과 비슷합니다.
실험
가설을 검증하기 위한 실험을 수행합니다. 네트워크 단절이 있더라도 안정 상태를 유지할 것이라고 가설을 세웠다면, 일정 시간동안 네트워크를 차단하는 실험을 수행할 수 있습니다. Amazon Elastic Compute Cloud (EC2) 인스턴스가 Amazon EC2 Auto Scaling 정책에 의해 종료되는 상황이 발생하더라도 안정 상태를 유지할 수 있다는 가설을 세웠다면, 임의로 EC2 인스턴스를 종료하는 실험을 수행할 수 있습니다.
검증
실험 결과를 분석하는 단계입니다. 통계적인 분석법에 따라 가설을 채택하거나 기각할 수 있습니다. 만약 안정 상태를 유지하는 것이 가설이었고, 수 차례 실험을 반복하였음에도 연속적으로 안정 상태를 유지했다면, 안정 상태를 유지한다는 가설을 채택할 수 있습니다. 반대로 안정 상태를 유지 하지 못한 경우가 일부 발견되었다면, 안정 상태를 유지한다는 가설을 기각해야 합니다. 높은 확률로 안정 상태를 유지한다는 증거가 없다면, 시스템 개선 방법을 찾고 다시 실험을 해야 합니다.
개선
시스템을 개선하기 위해서 실험 중 발생하는 정보를 관찰해야 합니다. 관측성 (Observability)은 시스템의 상태를 진단하고 문제의 원인을 파악하기 위한 도구입니다. 관찰 가능성은 지표(Metric), 로그(Log), 트레이스(Trace)로 구성됩니다. 지표는 현재 상태를 측정해서 표시합니다. 로그는 시스템의 동작에 대한 내용을 기록합니다. 트레이스는 요청들 사이의 흐름을 기록합니다. 지표를 통해서 상태를 확인할 수 있고, 로그를 통해서 원인을 분석할 수 있으며, 트레이스를 활용해서 순서를 파악할 수 있습니다.
AWS Fault Injection Simulator
카오스 엔지니어링이 어려운 이유는 다음과 같습니다.
- 다양한 도구를 서로 엮거나 직접 스크립트를 작성해야 합니다.
- 에이전트 또는 라이브러리를 설치해야 합니다.
- 안전하게 진행하기 까다롭습니다.
- “사실적인” 문제 상황을 재현하기 어렵습니다.
AWS Fault Injection Simulator (FIS)는 이러한 문제들을 해결하여 보다 수월하게 시스템의 안정성을 점검할 수 있도록 돕는 관리형 카오스 엔지니어링 서비스입니다. AWS 서비스와 유기적으로 연동되어 네트워크 단절, CPU 부하 증가, Disk 공간 부족 등과 같은 사실적인 문제 상황들을 쉽게 발생 시킬 수 있도록 해줍니다. 그리고 보다 사실 적인 상황을 연출할 수 있도록 장애 주입 실험을 순차적 또는 병렬적으로 수행할 수 있도록 해 줍니다. 또한 장애 주입 실험이 실제 고객에게 끼칠 수 있는 영향을 최소화하기 위한 다양한 안전 장치도 제공하고 있습니다.
그림 2 AWS FIS 아키텍처
장애 주입 실험
사전 준비 사항
예제를 실행하기 위해서는 다음이 필요합니다.
- AWS 계정
- AWS Command Line Interface (CLI)
- AWS Cloud Development Kit (AWS CDK)
- Python 3
- Kubernetes CLI (kubectl)
- Helm
단계 1: 실험 준비
실험을 위하여 먼저, 예제를 내려받기 합니다. 실습에 사용한 소스코드는 AWS Samples: Chaos Engineering with AWS Fault Injection Simulator에 있습니다.
git clone --depth 1 --branch aws-tech-blog https://github.com/aws-samples/chaos-engineering-with-aws-fault-injection-simulator.git다음, Amazon Elastic Kubernetes Service (EKS) 클러스터를 생성합니다. CDK를 활용하면, 익숙한 프로그래밍 언어를 사용하여 쉽게 AWS 자원을 생성하고 관리할 수 있습니다.
cd chaos-engineering-with-aws-fault-injection-simulator/eks/cdk다음은 파이썬(Python) 코드로 EKS 클러스터를 생성하는 예제입니다. EKS 클러스터를 생성하고, 필요한 도구들을 설치하는 내용을 담고 있습니다.
class EKS(core.Stack):
def __init__(self, app: core.App, id: str, props, **kwargs) -> None:
super().__init__(app, id, **kwargs)
vpc = aws_ec2.Vpc(self, "vpc", nat_gateways = 1)
eks = aws_eks.Cluster(self, "eks",
vpc = vpc,
version = aws_eks.KubernetesVersion.V1_24,
default_capacity = 0
)
mng = eks.add_nodegroup_capacity("mng",
instance_types = [aws_ec2.InstanceType("t3.small")],
desired_size = 3,
min_size = 3,
max_size = 9
)
eks.add_helm_chart("chaos-mesh",
chart = "chaos-mesh",
release = "chaos-mesh",
version = "2.2.2",
repository = "https://charts.chaos-mesh.org",
namespace = "chaos-mesh",
create_namespace = True
)
# fis role
fis_role = aws_iam.Role(self, "fis-role", assumed_by = aws_iam.ServicePrincipal("fis.amazonaws.com"))
fis_role.add_managed_policy(aws_iam.ManagedPolicy.from_aws_managed_policy_name("AdministratorAccess"))
with open('../kubernetes/manifest/cm-manager.yaml', 'r') as f:
cmm_manifest = yaml.safe_load(f)
eks.add_manifest("cm-manager", cmm_manifest)
f.close()
# update aws-auth config map
eks.aws_auth.add_role_mapping(fis_role, groups=["system:masters", "chaos-mesh-manager-role"])쿠버네티스 버전은 지속적으로 업그레이드되기 때문에, 사용 가능한 버전을 확인한 후 가능한 최신 버전으로 변경하여 적용하시길 바랍니다. 아래 예제에서처럼 쿠버네티스 버전을 지정할 수 있습니다. V1_24는 쿠버네티스 1.24 버전을 의미합니다. 이 블로그에서는 쿠버네티스 클러스터는 1.24 버전, kubectl은 1.23을 활용하였습니다.
버전이 확인 되었다면, 쿠버네티스 클러스터를 배포할 수 있습니다.
bash deploy.sh쿠버네티스 클러스터 생성이 완료 되었다면, 쿠버네티스 클러스터를 kubectl로 관리하기 위해서 클러스터 인증 정보를 내려받기 해야 합니다. 이 작업을 위한 명령어는 쿠버네티스 생성이 완료되었을 때 다음과 비슷한 모양으로 출력됩니다. CDK 실행 결과 중에서 아래 그림의 출력과 같이 “aws eks update-kubeconfig” 가 포함된 부분을 복사한 후 붙여넣기하여 실행합니다.
그림 3 Amazon EKS 생성 결과
실습 예제를 배포하기 위하여 다음과 같이 명령을 실행합니다.
cd chaos-engineering-with-aws-fault-injection-simulator/eks/kubernetes/manifest/
kubectl apply -f sockshop-demo-ha.yaml단계 2: EKS 노드(Node) 종료 실험
이 실험은 EKS의 노드가 갑자기 종료되더라도 전체 워크로드에는 큰 영향이 없도록 만드는 고가용성 설계를 점검합니다. EKS 클러스터의 관리형 노드 중에서 일부가 갑자기 동작하지 않는 상황일 때, 애플리케이션이 어떻게 동작하는 지 살펴보는 것입니다. 일부 노드가 정상 동작 하지 않더라도 다른 노드의 포드(Pod)가 요청을 대신 받아서 처리해 주며, 늘어난 전체 요청을 분산 처리 하기 위하여 새로운 노드가 자동으로 추가되는 지 확인 하는 실험입니다. 특정 EC2 인스턴스에 하드웨어 문제가 발생하면서 종료 되는 상황 또는, 특정 가용 영역 (Availability Zone)의 인스턴스들이 응답이 없어서 자동 종료되는 상황 등을 모사해 볼 수 있습니다. 이러한 문제 상황이 발생했을 때 시스템이 자동으로 문제를 극복하는 아키텍처인 지 점검해 볼 수 있습니다.
안정 상태 정의
실험을 위한 예제를 배포합니다. 일정 시간이 지나면, 지표들을 측정할 수 있습니다. 포드와 서비스가 정상적으로 동작한다는 지표를 정의합니다. CloudWatch를 보면 서비스가 정상 상태인 지 지표로 확인할 수 있습니다. 포드가 적어도 1개 이상일 경우 알람이 울리지 않고, 서비스를 제공하는 포드가 한 개도 없다면 알람을 울리도록 설정하였습니다. 배포가 잘 되었다면, 프론트엔드 서비스를 위해 3개의 포드가 동작하고 있을 것입니다.
그림 4 Amazon CloudWatch Alarm
가설 수립
여러 가용영역에 대하여 노드가 분산되어 있고, 그 위에 포드가 같은 방식으로 분산되어 있다면, 일부 노드가 갑자기 동작하지 않는 장애는 전체 서비스에 별다른 영향을 주지 않을 것 입니다. 그리고 EC2 오토스케일링 그룹의 기능을 이용하여 새로운 EC2 인스턴스를 생성하고 쿠버네티스 노드로 등록할 것입니다. 동시에 쿠버네티스는 갑자기 종료된 노드 위에 있던 포드들의 상태를 확인하였다가 응답이 없으면 다른 노드에 포드를 새로 배포할 것입니다. 만약 배포할 공간이 부족하다면, 포드 배포를 잠시 중단하고 대기할 것이며. 새로운 EC2 인스턴스가 등록되면 그 곳에 포드들을 배포할 것 입니다. 계획대로 동작한다면, 서비스 전체의 가용성에 대한 영향은 크지 않을 것입니다.
그림 5 Amazon EKS 고가용성 아키텍처
실험 템플릿
class FIS(core.Stack):
def __init__(self, app: core.App, id: str, props, **kwargs) -> None:
super().__init__(app, id, **kwargs)
# copy properties
self.output_props = props.copy()
# terminate eks nodes experiment
terminate_nodes_target = aws_fis.CfnExperimentTemplate.ExperimentTemplateTargetProperty(
resource_type = "aws:eks:nodegroup",
resource_arns = [f"{props['ng'].nodegroup_arn}"],
selection_mode = "ALL"
)
terminate_nodes_action = aws_fis.CfnExperimentTemplate.ExperimentTemplateActionProperty(
action_id = "aws:eks:terminate-nodegroup-instances",
parameters = dict(instanceTerminationPercentage = "40"),
targets = {'Nodegroups': 'eks-nodes'}
)
aws_fis.CfnExperimentTemplate(
self, "eks-terminate-nodes",
description = "Terminate EKS nodes",
role_arn = props['fis_role'].role_arn,
targets = {'eks-nodes': terminate_nodes_target},
actions = {'eks-terminate-nodes': terminate_nodes_action},
stop_conditions = [
aws_fis.CfnExperimentTemplate.ExperimentTemplateStopConditionProperty(
source = "aws:cloudwatch:alarm",
value = f"{props['cpu_alarm'].alarm_arn}"
),
aws_fis.CfnExperimentTemplate.ExperimentTemplateStopConditionProperty(
source = "aws:cloudwatch:alarm",
value = f"{props['svc_health_alarm'].alarm_arn}"
)
],
tags = {'Name': 'Terminate EKS nodes'}
)실험
실험 시작 전에, 중단 조건 (Stop Condition)을 확인합니다. 실험 중단 조건은 서비스가 안정 상태가 아닌 경우에 울리는 알람으로 지정할 수 있습니다. 장애 주입 실험이 아무리 중요하더라도 실제 사용자에게 영향을 끼치게 할 수 없기 때문입니다. 그래서 AWS FIS는 중단 조건 알람이 OK 상태일 때만 실험을 시작할 수 있으며, 알람이 울리면 실험을 중단하여 사용자 영향을 최소화 합니다. 실험을 시작할 준비가 되었다면, ‘EKS 노드 종료(Terminate EKS Nodes)’ 실험을 선택하고 ‘실험 시작’ 단추를 눌러서 실험을 시작합니다.
그림 6 AWS FIS 실험 템플릿
그림 7 AWS FIS 실험 시작
검증
실험을 수행하였다면, 결과를 분석합니다. 여러 가용영역에 나누어 노드가 고르게 분산되어 있고, 그 위에 포드가 같은 방식으로 분산되어 있다면, 일부 노드가 갑자기 동작하지 않는다 하더라도 전체 서비스는 무리 없이 동작할 것입니다. 이러한 가설이 증명될 수 있도록 실험 결과를 확인합니다. 안정 상태가 아니라는 의미의 종료 조건 알람이 울렸는 지 확인하고, 여러 지표들을 확인하여 가설을 채택할 수 있는 근거를 수집합니다. 실험 검증을 위한 지표는 한 번의 실험만으로는 획득할 수 없으며, 여러 번 반복실험을 하여 증명해야 합니다.
단계 3: EKS 포드(Pod) 종료 실험
안정 상태 정의
첫 번째 실험과 마찬가지로, 포드와 서비스가 정상적으로 동작한다는 지표를 정의합니다. 클라우드 와치 알람이 OK 상태인 지 확인합니다. 알람이 울리지 않았다는 것은 서비스가 안정 상태에 있다고 볼 수 있습니다.
가설 수립
여러 가용영역에 대하여 노드가 분산되어 있고, 그 위에 여러 개의 포드가 분산 배포 되어 있다면, 일부 포드에 이상이 발생하여 동작하지 않더라도 다른 포드를 통해서 서비스를 계속 제공할 수 있을 것입니다. 쿠버네티스에서는 디플로이먼트를 통해서 몇 개의 포드를 생성하고 배포할 지 결정할 수 는데, 만약 일부 포드가 어떠한 이유로 사라지게 되면, 디플로이먼트에 지정한 수의 포드를 맞추기 위해서 자동으로 복구 절차를 수행합니다. 포드를 배포할 수 있는 노드를 확인하고, 새로운 포드를 배포해서 전체 서비스가 안정 상태를 유지하도록 동작할 것입니다. 계획대로 동작한다면, 서비스 전체의 가용성에 대한 영향은 크지 않을 것입니다.
실험 템플릿
이 번 실험은 특정 포드를 종료시키는 실험입니다. 노드는 이상 없이 잘 동작하더라도 그 위에서 실행되는 포드가 갑자기 종료되는 상황이 있을 수 있습니다. 이런 경우 고가용성 설계가 되어 있다면, 쿠버네티스가 포드의 상태를 확인하여 새로운 노드에 포드를 새로 생성하게 됩니다. 이 번 실험을 위해서 카오스 메시(Chaos Mesh)를 사용합니다.
class FIS(core.Stack):
def __init__(self, app: core.App, id: str, props, **kwargs) -> None:
super().__init__(app, id, **kwargs)
# copy properties
self.output_props = props.copy()
# chaos-mesh pod-kill
aws_fis.CfnExperimentTemplate(
self, "eks-chaos-mesh-disrupt-pod",
description = "Disrupt pod",
role_arn = props['fis_role'].role_arn,
targets = {'eks-cluster': aws_fis.CfnExperimentTemplate.ExperimentTemplateTargetProperty(
resource_type = "aws:eks:cluster",
resource_arns = [f"{props['eks'].cluster_arn}"],
selection_mode = "ALL"
)},
actions = {'eks-kill-pod': aws_fis.CfnExperimentTemplate.ExperimentTemplateActionProperty(
action_id = "aws:eks:inject-kubernetes-custom-resource",
parameters = dict(
kubernetesApiVersion = "chaos-mesh.org/v1alpha1",
kubernetesKind = "PodChaos",
kubernetesNamespace = "chaos-mesh",
kubernetesSpec = json.dumps({
"action": "pod-kill",
"mode": "one",
"selector": {
"namespaces": ["sockshop"],
"labelSelectors": {"name": "carts"},
},
"gracePeriod": 0
}),
maxDuration = "PT5M"
),
targets = {'Cluster': 'eks-cluster'}
)},
stop_conditions = [aws_fis.CfnExperimentTemplate.ExperimentTemplateStopConditionProperty(
source = "aws:cloudwatch:alarm",
value = f"{props['cpu_alarm'].alarm_arn}"
)],
tags = {'Name': 'Inject pod failure using chaos mesh'}
)실험
가설 수립을 검증하기 위한 실험을 수행합니다. 노드 종료 실험과 같은 방법으로 ‘포드 종료(Terminate Pods)’ 실험을 찾아서 시작합니다. 중단 조건에 해당하는 알람이 울리지 않았다면, 실험이 시작됩니다.
검증
FIS 실험 화면에서 Completed 상태 표시가 나왔다는 것은 포드를 종료시키는 작업을 완료했다는 뜻입니다. 이제 결과를 분석하기 위하여 알람이 울렸는 지 확인해 보겠습니다. 포드를 삭제하는 실험을 수행했음에도 알람이 울리지 않았다면 안정 성태가 유지된다는 가설을 증명하는 근거가 나왔다는 뜻입니다. 여러 가용영역에 나누어 노드가 고르게 분산되어 있고, 그 위에 여러 개의 포드가 분산 배치되어 있다면, 일부 포드가 갑작스럽게 종료되더라도 다른 포드가 대신 요청을 처리할 수 있습니다. 따라서 전체 서비스에는 영향이 없을 것입니다. 반대로 알람이 울렸다면 안정 상태를 유지 하지 못했다는 의미이므로 여러 지표들을 확인하여 원인을 분석해야 합니다. 여기서 중요한 것은 가설 검증이 단 한 번의 실험으로는 불가능하기 때문에 반복 실험을 통한 증명이 필요하다는 것 입니다.
개선
특별한 문제가 없다면, 포드가 종료된 뒤 바로 새로운 포드가 배포될 것입니다. 하지만, 포드를 배포할 노드가 없다면 쿠버네티스는 포드를 배포할 수 없고 새로운 노드가 생성될 때까지 기다릴 것입니다. 이러한 상황을 자동으로 판단하고 빠르게 새로운 노드를 추가해 줄 방법이 필요합니다. 이러한 방법이 궁금하다면 Cluster Autoscaling과 Karpenter를 참고하시기 바랍니다. 처음 포드를 만들었을 때, 너무 적은 복제본을 만들었거나 1개의 포드만을 배포했다면, 가용성이 떨어지게 됩니다. 1개의 포드만을 만들었다면, 그 포드가 종료되고 다시 복구될 때까지 서비스는 사용할 수 없는 상태가 됩니다. 안정 상태에서 정의한 기준이 서비스 중단을 허용하지 않는다면, 충분히 많은 수의 포드를 배포해서 서비스 가용성을 높이는 방법을 찾아야 합니다.
단계 4: Amazon EventBridge 활용한 지속적인 검증
한 번의 실험만으로 분산 시스템의 신뢰성을 증명할 수는 없습니다. 주기적으로 장애 주입 실험을 수행하여 시스템이 다양한 상황에서도 안정 상태를 유지할 수 있다는 것을 확인해야 합니다. 지속적인 통합(CI)과 지속적인 전달(CD)을 통하여 민첩하면서도 안정적으로 서비스를 개발하고 배포할 수 있게 된 것처럼, 지속적인 검증을 통하여 복원력 있는 시스템을 만들 수 있도록 하는 것이 중요합니다. Amazon EventBridge는 사용자가 원하는 스케쥴에 이벤트를 발생시키는 기능을 제공하며, AWS Lambda는 이벤트 핸들러를 손쉽게 구축하는 기능을 제공합니다. 이벤트 브릿지와 람다를 활용하여 지속적인 장애 주입 실험을 수행할 수 있습니다. 다음은 지속적 검증을 위한 아키텍처 예제입니다.
그림 8 Amazon EventBridge와 AWS Lambda를 활용한 지속적인 안정성 테스트 아키텍처
리소스 정리하기
이 블로그에서 사용했던 리소스는 향후 불필요한 과금 방지를 위해 삭제해 주시길 바랍니다.
cd chaos-engineering-with-aws-fault-injection-simulator/eks/cdk
bash cleanup.sh정리
AWS 환경에서 카오스 엔지니어링을 통하여 서비스 신뢰성을 높일 수 있는 사례를 소개하였습니다. 고가용성 아키텍처의 동작을 확인하고 점검하는 과학적인 방법인 카오스 엔지니어링을 활용하여 실제 운영환경에서 겪을 수 노드 또는 포드가 종료되는 상황을 대비하는 방법을 알아보았습니다. 클라우드 컴퓨팅 환경을 활용하여 인프라스트럭처의 고가용성을 확보하였다고 하더라도, 새로 배포하는 애플리케이션이 고가용성 설계가 되어 있는지 별도로 확인이 필요합니다. 다양한 재해 상황을 지속적으로 재현하여 시스템과 애플리케이션의 안정성을 실측하고 취약점을 개선하는 방법인 카오스 엔지니어링을 위해 AWS FIS를 도입해 보시길 바랍니다.