AWS SAA 자격증 준비 (6) - 모니터링, 자동화, 메시지 서비스, 장애 및 복구
AWS에서는 모니터링 서비스도 제공한다. AWS CloudTrail, CloudWatch, EventBridge가 그 대표적인 서비스들이다. 이에 대해 하나씩 살펴보자. 모니터링은 1) 운영상태 가시성 및 인사이트 확보를 위해서, 2) 어플리케이션 성능 데이터 수집을 위해서, 3) 리소스 사용률 최적화를 위해서, 4) 보안 감사를 위해서 진행하게 된다.
AWS CloudWatch
CloudWatch는 가장 유명하고도 자주 사용되는 서비스이다. CloudWatch는 시간별로 지표를 모두 수집하여 대시보드화하는 서비스로서 이 서비스를 통해 AWS 및 온프레미스 인프라, 리소스를 실시간 모니터링할 수 있다. 즉 실시간으로 리소스/서비스/앱의 관찰을 할 수 있는 것이다. 또한 CloudWatch를 활용하여 Alarm을 구성하고 이에 대한 대응체계를 자동화할 수도 있다. 예를 들어 EC2 CPU 사용률 등을 모니터링 지표로 삼아 CloudWatch의 경보 기능을 이용하여 임계값을 넘기게 되면 정의된 작업(ex. AutoScaling)을 실행하는 등으로 아키텍쳐를 구성할 수 있다. 뿐만 아니라 경보 및 기간, 즉 임계값이 넘어가더라도 특정 기간값 이상을 만족해야 알람 작동하도록 한 단계 더 나아간 구성을 할 수도 있다.
CloudWatch의 ‘지표’는 OK / Alarm / Insufficient Data 로 세 가지의 상태값을 지니게 된다. Insufficient Data는 CloudWatch를 연결한지 얼마 되지 않았을 때 등에 나타나게 된다.
이처럼 CloudWatch를 통해 데이터를 수집하고 모니터링하여 이상 상황에 대해 대응하고 로그를 분석할 수 있다.
AWS CloudTrail
다른 서비스로는 CloudTrail이 있는데, 이 서비스는 인프라에서 계정 활동에 대한 로깅과 모니터링을 가능하게끔 해준다. 예를 들어 루트 사용자의 로그인 실패를 캡처하거나 API자체에 대한 호출을 기록하는 등 인프라에 연결된 ‘계정’들에 대한 활동을 기록한다. AWS 서비스에 대한 API 호출 상호 작용을 기록할 때는 관리콘솔/CLI/SDK 등 접속 방법과 무관하게 호출된 API를 기록한다. CloudTrail은 이렇게 수집한 로그를 Amazon S3에 자동으로 저장한다.
AWS VPC Flow Logs
추가로 VPC Flow Logs라는 서비스는 VPC의 네트워크 인터페이스에서 송수신되는 IP트래픽 정보를 수집한다. 이 때 ENI (탄력적 네트워크 인터페이스) 에서 수집되는 로그를 남기게 된다.
AWS에서는 메시지 대기열 서비스도 제공한다. 대표적인 서비스가 AWS SQS, SNS이다.
AWS SQS (Simple Queue Service)
대기열의 유형은 두 가지로 나뉜다.
- 표준
- 순서가 정해져있지 않다. 메시지가 최소 1회 전송되는 것을 보장(중복하여 2번 이상 전송할 수도 있음)
- 초당 API호출인데 거의 제한이 없다. 즉 처리량 중심의 유형이다.
- FIFO
- 순서가 지정되어있다. 메시지가 1번만 전송되도록 보장한다.
- 초당 API호출에 제한이 있다. (초당 300건)
SQS는 아래와 같은 기능들을 보유하고 있다.
1. 수명 주기 및 가시성 시간 제한
생산자가 메시지를 대기열에 전송한 후 소비자가 메시지 처리를 위해 픽업하는 순간부터 가시성 시간 제한이 시작된다. 가시성이 제한된 시간 동안에는 다른 소비자가 해당 메시지를 가져갈 수 없게된다. 이 때 메시지가 처리된 후에는 소비자가 메시지를 삭제해야한다. (ex. delete 명령)
2. 짧은 폴링 vs 긴 폴링
폴링 방식의 차이가 있는데, 짧은 폴링은 메시지를 수신할 것이 없다면 돌아오게 된다. 그리고 수신할 메시지를 무작위로 샘플링하여 폴링한다.
반면 긴 폴링은 폴링했을 때 메시지를 수신할 것이 없다고 하면 몇 초간 기다려 메시지 수신을 추가로 확인하게 된다. 그리고 메시지를 수신할 때에도 전수검사하여 메시지를 수신한다. 긴 폴링은 짧은 폴링에 비해 빈 응답과 거짓 빈 응답 (= 메시지가 있지만 응답에 포함되지 않은 경우)의 발생 확률을 줄여 SQS 사용 비용을 절감할 수 있다.
3. 배달 못한 편지 대기열 (DLQ, Dead Letter Queue)
메시지를 필터링하여 사용자가 직접 처리할 수 있는 기능이다. 배달을 하지 못할 경우 재시도 가능한 최대 횟수 limit을 둘 수 있고, 이 limit을 넘길 경우 운영자가 직접 처리하게 된다.
SQS는 특정 메시지 선택, 즉 필터링 기능이 없어 원하는 메시지만을 수신할 수는 없다. 또한 대용량 메시지에는 서비스 사용이 적합하지 않다.
AWS SNS (Simple Notification Service)
SNS는 SQS와 유사하면서도 차이점이 있다.
SNS는 경보 알림, 혹은 이메일 및 SMS, 앱푸시 알림 목적으로 주로 사용된다.
SNS는 단일 메시지라는 특성이 있다. 즉 메시지의 지속성이 없다. 알림용으로 사용하기 적합한 서비스이다.
SQS와는 다르게 메시지를 푸시하게 된다. 참고로 SQS는 대기열에 있는 메시지를 폴링해오는 서비스이다. 즉 SQS는 지속적으로 애플리케이션에게 업데이트를 확인하거나 '폴링'해올 필요 없이 시간이 중요한 메시지를 구독자에게 일대다로 배포하게 된다.
또한 SQS는 생산자와 소비자가 각각 발송자 또는 수신자였는데, SNS는 각각 게시자 및 구독자라고 명칭이 구분되어있다.
SNS와 SQS를 결합하여 아키텍쳐를 구상할 수도 있다. 예를 들어 온라인 쇼핑몰에서 메시지 기반 작업 처리 프로세스를 개발한다고 했을 때, 온라인 주문이 발생하게 되면 SNS가 여러 SQS로 각각 메시지를 전송하게 되고, 각 SQS는 대기열에 있는 메시지를 처리하여 이후 작업을 진행하게 된다.
SNS는 구독자 유형을 선택하여 어떤 메시지를 구독할 것인지를 선정하는데,
- Email / Email-JSON
- 휴대폰 문자 메시지 (SMS)
- 모바일 푸시 알림
- HTTP / HTTPS
- AWS Lambda
위 목록을 모두 구독할 수 있다.
참고로 SNS는 회수 옵션이 없다. 그리고 SNS 역시 SQS와 마찬가지로 표준 혹은 FIFO로 유형 선택이 가능하다.
AWS에서는 자동화 서비스를 제공한다.
AWS Elastic Beanstalk
인프라를 프로비저닝하고 운영하는 서비스이다. 사용자 대신 애플리케이션 스택을 관리한다.
AWS System Manager
여러대의 EC2를 한번에 관리하게 할 수 있는 서비스이다. EC2를 동시에 운영 관리할 수 있으며 작업을 생성하거나 여러 대에 동일한 명령어를 run하거나, 패치를 관리할 수도 있다. 특히 session manager 라고 하여 SSH 포트를 별도로 설정할 필요 없이(ex. SG설정 등) AWS 콘솔에서 바로 EC2 터미널 접근이 가능하게 해주는 기능도 제공한다.
아래와 같은 이점을 지니고 있다:
- 문제 탐지에 걸리는 시간을 단축
- 작업을 자동화하여 효율성을 향상
- 가시성 및 제어를 개선
- 하이브리드 환경을 관리
- 보안 및 규정 준수를 유지
AWS Cloud Formation
코드형 인프라(IaC)이다. 사용자는 JSON혹은 YAML 형식의 템플릿만 작성하면 이 템플릿에 따라 인프라를 AWS가 구성해준다. 다시 정리하자면 사용자가 아키텍쳐 템플릿을 생성하면 CloudFormation 엔진이 아케틱쳐 스택을 생성하고 그에 따라 인프라를 구성한다. 템플릿은 생성할 리소스 혹은 수정할 리소스를 설명하도록 되어있다.
코드형 인프라의 이점은 인프라 및 앱에서의 버전관리를 제어할 수 있으며 복제하여 재배포하기도 쉽다는 것이다. 작성한 템플릿은 소스코드로 취급되어 리포지토리에 저장하게 된다.
'변경세트'라는 기능을 제공하는데 이는 원래 스택에서 변경될 예정인 사항만을 기록하는 것이다. 이 변경 세트를 사용자에게 확정 여부를 묻고, 확정을 받게 되면 변경세트를 반영하여 인프라를 변경한다.
백업 및 복구 서비스에 대해서도 살펴보자.
손쉬운 백업 및 복구를 위해 AWS는 가용성을 추구한다. 고가용성일수록 내결함성을 가지게 되며, 이에 따라 백업 및 재해 복구가 손쉬워진다.
백업과 복구를 위해 대표적인 서비스별로 어떤 대응책이 있는지 간략하게 살펴보자.
S3의 경우 앞서 보았듯 교차 리전 복제가 디폴트로 되어있다.
EC2의 경우 복구용 AMI를 구성하여 해당 이미지로 빠르게 재생성이 가능하다.
혹은 복구 전략으로 다음과 같이 제시하기도 한다.
- 파일럿 라이트 : 프로덕션 인프라를 그대로 복제하여 예비본을 만들 수 있다. 예를 들어 예비 EC2는 실행하지 않은 상태로 두고 예비 DB에는 데이터 복제만 간간히 진행한다. 그리고서 재해 발생시 Route 53으로 트래픽을 예비 영역으로 우회시켜 프로덕션 인프라가 seamless하게 운영되도록 한다.
- 완전 동작 저용량 스탠바이 : 파일럿 라이트보다 좀 더 리소스가 실제로 실행되고 있는 전략이다. 대신 저용량으로 스탠바이하게 된다.
- 다중 사이트 액티브-액티브 : 필요한 리소스를 늘 프로덕선 로드 수용이 가능한 수준만큼 운영하는 전략이다.
복구의 경우 AWS에서는 두 가지 목표를 삼는다.
1. RPO : 복구 시점 목표
얼마나 자주 데이터를 백업해야하는지를 결정한다. 즉 재해가 발생했을 때 백업된 데이터로 복구해야할 텐데, 최소한의 백업 주기를 언제로 해야하는지 결정해야한다.
2. RTO : 복구 시간 목표
애플리케이션을 얼마나 오래 사용할 수 없는지를 결정한다. 가동 중단 시간이 얼마만큼의 이내로 되어야 애플리케이션이 정상적으로 운영될 수 있는지를 결정한다.
이 글을 마지막으로 AWS SAA 자격증을 취득하기에 필요한 지식과 자료 정리는 마무리가 된다.
첨부된 그림은 전부 AWS 공식 문서에서 발췌하였습니다.