1. 강의 내용
학습 범위
- 17. 디커플링 애플리케이션: SQS, SNS, Kinesis, Active MQ
- 18. AWS의 컨테이너: ECS, Fargate, ECR 및 EKS
- 19. 솔루션 설계자 관점의 서버리스 개요
2. 강의 정리
1) SQS
: 메시지 큐 서비스로, 애플리케이션 간에 데이터를 주고받을 때 중간에 메시지를 임시로 저장하고 전달하는 기능을 한다.
1. 특징
- 완전 관리형: 인프라 관리 없이 사용할 수 있음
- 확장성: 무제한에 가까운 처리량, 대기열 메시지
- 비동기 처리: 메시지를 보내고 즉시 다음 작업을 수행할 수 있음
- 안전성: 메시지 손실 방지
→ 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임
2. SQS 구성 요소
- 메시지(Message)
- 전달하려는 데이터
- 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
- 기본적으로 4일 동안 저장되며, 최대 14일까지 연장 가능
- 큐(Queue)
- 메시지가 저장되는 공간
- Standard Queue
- 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
- 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
- 메시지 순서 보장 X, 중복 전달 방지 X
- FIFO Queue
- 기본으로 300 TPS, 높은 처리량 모드 시 최대 3000 TPS 지원
- 중복 처리가 없도록 정확히 한 번만 전달된다. (Exactly Once Delivery)
- 메시지 순서 보장 O, 중복 전달 방지 O
- 생산자(Producer)
- 큐에 메시지를 보내는 서비스
- 큐에 메시지를 보내는 서비스
- 소비자(Consumer)
- 큐에서 메시지를 가져와 처리하는 서비스
3. 주요 기능
- 가시성 타임아웃(Visibility Timeout)
- 소비자가 메시지를 처리하는 동안 다른 소비자가 동일한 메시지를 중복 처리하지 않도록 설정된 시간
- 기본값 30초, 최대 12시간까지 조정 가능
- 긴 폴링(Long Polling)
- 소비자가 큐에 메시지를 요청할 때, 대기열에 메시지가 없다면 메시지가 도착할 때까지 기다림
- 빈 응답을 줄여 비용과 대기 시간을 최적화
- 짧은 폴링(Short Polling)
- 소비자가 큐에 메시지를 요청할 때, 즉시 응답을 반환하며 메시지가 없으면 빈 응답을 받음 (기본 설정)
- 데드 레터 큐(Dead Letter Queue, DLQ)
- 일정 횟수 이상 처리 실패한 메시지를 별도의 큐로 이동시킴
- 디버깅 및 문제 분석 가능
- 메시지 지연(Delay Queues)
- 메시지를 큐에 추가한 후 일정 시간 동안 소비자에게 보이지 않도록 설정 (최대 15분)
4. SQS 동작 방식
- 생산자가 SQS 큐에 메시지를 전송 (SendMessage API 호출)
- 메시지는 SQS에 저장되며, 필요에 따라 복제되어 내구성을 보장
- 소비자가 큐에서 메시지를 polling하여 가져옴 (ReceiveMessage API 호출)
- 처리 중 메시지가 다른 소비자에게 다시 할당되지 않도록 가시성 타임아웃이 설정됨.
- 메시지를 처리한 후, 소비자가 처리 완료를 알리기 위해 메시지를 삭제 (DeleteMessage API 호출)
5. 사용 사례
2) SNS
: 메시지를 발행(Publish)하면 이를 구독(Subscribe)한 모든 수신자에게 동시에 전달하는 push 기반 서비스이다.
SQS와 달리 메시지를 큐에 저장하고 소비자가 가져가기를 기다리는 방식이 아니라, 실시간으로 메시지를 push한다.
1. 특징
- 완전 관리형: 인프라 관리 없이 사용할 수 있음
- 확장성: 수백만 구독자에게 메시지 전송 가능
- 실시간성: 메시지를 즉시 전달
- 다양한 서비스 지원: 이메일,
→ 서비스 간의 의존성이 최소화 되고, 독립적으로 실행되어 전체적인 서비스의 유연성을 높임
2. SQS 구성 요소
- 메시지(Message)
- 전달하려는 데이터
- 최대 256KB 텍스트 데이터 (더 큰 데이터는 S3와 연계 처리)
- 속성(Message Attributes)을 추가해 필터링 가능
- 토픽(Topic)
- 메시지를 발행하고 구독자가 수신하는 논리적 채널
- 각 토픽은 고유한 ARN(Amazon Resource Name)을 가짐.
- Standard Topic
- 무제한에 가까운 처리량(자동 확장)과 최소 지연 시간 지원
- 메시지가 적어도 한 번 이상 전달된다. (At Least Once Delivery)
- 메시지 순서 보장 X, 중복 전달 방지 X
- 다양한 서비스 구독자를 지원한다. (Email, SMS, HTTP, SQS, Lambda 등)
- FIFO Topic
- 기본으로 300 TPS , 높은 처리량 모드 시 최대 3000 TPS 지원
- 중복 처리가 없도록 정확히 한 번만 전달 (Exactly Once Delivery)
- 메시지 순서 보장 O, 중복 전달 방지 O
- SQS FIFO Queue 구독자만 지원한다.
- 발행자(Publisher)
- 토픽에 메시지를 보내는 애플리케이션 또는 서비스.
- 토픽에 메시지를 보내는 애플리케이션 또는 서비스.
- 구독자(Subscriber)
- 토픽에서 메시지를 받는 엔드포인트 (ex: 이메일, SMS, Lambda, SQS 등)
3. 주요 기능
- 메시지 필터링(Message Filtering)
- 구독자가 메시지 속성을 기반으로 수신 여부를 결정(예: "type=error" 메시지만 수신)
- 팬아웃(Fan-out)
- 하나의 토픽에서 여러 SQS 큐로 메시지를 분배 가능
- SQS 큐의 액세스 정책에서 SNS가 메시지를 보낼 수 있도록 허용해야 함
- 데드 레터 큐(Dead Letter Queue, DLQ)
- 전달 실패한 메시지를 별도의 SQS 큐로 저장
4. SQS 동작 방식
- 발행자가 SNS 토픽에 메시지를 발행 (Publish API 호출)
- 메시지는 해당 모든 토픽 구독자에게 실시간으로 푸시
- 메시지 필터링 정책이 적용된 경우, 조건에 맞는 구독자에게만 전달됨
- 구독자가 메시지를 수신하고 처리함
- SNS 메시지 전달 확인 (Optional)
- SNS가 메시지 전달이 성공적으로 되었는지 확인하여, 실패 시 DLQ로 메시지를 보냄
5. 사용 사례
3) Kinesis
: 실시간으로 스트리밍 데이터를 빠르게 수집/처리/분석할 수 있도록 지원하는 완전 관리형 서비스이다.
1. Kinesis Data Streams
- 실시간으로 데이터 스트림을 수집하는 서비스
- 샤드(Shard) 기반 아키텍처
- 데이터 스트림은 샤드 단위로 나뉘어짐
- 각 샤드의 초당 1MB 쓰기, 2MB 읽기 처리 가능
- 처리량은 샤드 수에 비례하여 확장됨
- 프로비저닝 모드
- 사용자가 직접 샤드 개수를 지정하여 용량 설정
- 지정한 샤드 개수에 따른 시간 단위의 비용
- 온디멘드 모드
- 마지막 30일간의 최대 처리량을 기준으로 자동 스케일링
- 입출력 된 데이터(GB) 기준 비용
- 데이터 레코드
- 스트림에 저장되는 데이터
- 각 레코드는 Partition Key와 Sequence Number로 식별된다.(Partition Key는 저장될 샤드를 결정한다.)
- 데이터를 스트림에 넣는 Producer
- 직접 개발: AWS SDK / Kinesis Agent / KPL(Kinesis Producer Library)
- 직접 개발: AWS SDK / Kinesis Agent / KPL(Kinesis Producer Library)
- 데이터를 읽어 처리하는 Consumer
- 직접 개발: AWS SDK / KCL(Kinesis Client Library)
- 관리형 서비스: Lambda / Kinesis Data Firehose / Kinesis Data Analytics
- 최소 1일 ~ 최대 365일까지 데이터가 보관된다.
- 한 번 삽입된 데이터는 삭제할 수 없다.
2. Kinesis Data Firehose
- 스트리밍 데이터를 지정된 AWS 데이터 저장소나 분석 서비스로 자동 전송하는 서비스 (S3, Redshift, OpenSearch)
- Lambda를 통한 데이터의 변환(포맷, 필터링) 지원
- 데이터를 일정 크기나 시간 간격으로 묶어 배치 단위로 저장소에 전송함 → Near Real-Time Service
Kinesis Data Streams vs Kinesis Data Firehose
Kinesis Data Streams | Kinesis Data Firehose | |
목적 | 대규모 데이터 스트리밍 수집 | 스트리밍 데이터를 AWS 및 외부 저장소로 전송 |
직접 개발 | Custom Producer/Consumer 코드 작성 필요 | 완전 관리형(Fully Managed), 개발 없이 사용 가능 |
실시간 처리 | 실시간(Real-time, 약 200ms 지연) | 거의 실시간(Near Real-time), 버퍼링 적용됨 |
확장성 | 샤드(Shard) 기반 수동 확장 또는 API로 확장 가능 | 자동 확장(Auto Scaling) |
데이터 저장 기간 | 최소 1일 ~ 최대 365일 | 데이터 저장 없음 (즉시 대상 시스템으로 전송) |
데이터 재처리 | 지원 (데이터 저장 후 다시 읽기 가능) | 미지원 (한 번 전송 후 다시 불러올 수 없음) |
3. Kinesis Data Analytics
- 스트리밍 데이터를 실시간으로 분석하는 서비스
SQL 쿼리 또는 Apache Flink를 사용해 실시간 데이터 분석 - 실시간 분석 결과를 다른 Kinesis Stream, S3, Lambda 등으로 전송
4. Kinesis Video Streams
- 비디오와 오디오 스트림을 실시간으로 수집, 처리, 저장하기 위한 서비스 (CCTV, 드론, IoT 카메라)
4) Amazon MQ
: 오픈소스인 Apache ActiveMQ와 RabbitMQ 를 기반으로 한, 메시지 브로커 서비스이다.
(메시지 브로커는 분산 시스템이나 MSA 환경에서 서비스들 간의 통신을 중개하는 역할을 하면서, 안정적(부하 분산)이고 비동기적인 처리를 가능하게 한다.)
특징
- 기존에 ActiveMQ, RabbitMQ와 같은 오픈소스 메시지 브로커를 사용하던 온프레미스 애플리케이션을, 코드 변경을 최소화하여 AWS로 마이그레이션 할 수 있도록 한다.
- 표준 메시지 프로토콜(AMQP, MQTT, STOMP 등)을 그대로 사용 가능
- 완전한 서버리스 구조가 아니기 때문에, SQS, SNS와 같은 확장성은 상대적으로 낮다.
───
5) ECS
: ECS(Elastic Container Service), AWS에서 도커 컨테이너를 실행하고 관리할 수 있도록 하는 완전관리형 서비스이다.
1. ECS 실행 환경
EC2
- 사용자가 도커 컨테이너가 실행되는 EC2 인스턴스를 직접 구성하고 관리해야 함.
- 인스턴스 모니터링, Auto Scaling 과 같은 부분을 직접 관리
- Spot Instance 사용하여 비용을 절약할 수 있음
- ECS Agent가 EC2 인스턴스에서 실행되어, 해당 인스턴스를 ECS 클러스터에 등록함.
- Task 정의에 따라 ECS 서비스가 EC2에 Task 컨테이너를 실행시킴.
Fargate
- 사용자가 EC2 인스턴스를 전혀 관리하지 않음 (Serverless)
- OS 수준의 접근은 안 됨
- CI/CD, 무중단 배포 쉽게 적용 가능
- Task 만 정의하면, AWS가 자동으로 Task 컨테이너를 실행할 인프라를 할당하고 관리함
- Task 단위로 CPU / RAM 개별 지정해서 최적화 가능
2. ECS IAM Roles
EC2 Instance Profile
- EC2 실행 방식 전용으로, 해당 EC2 인스턴스에서 실행되는 ECS Agent가 ECS나 다른 AWS 리소스와 통신할 수 있도록 IAM 권한을 부여함
- ECR에서 Docker 이미지 pull
- CloudWatch에 로그 전송
ECS Task Role
- Task A, Task B가 각자 다른 AWS 리소스를 사용하는 경우, 각자의 Task Role로 IAM 권한을 분리하여 설정할 수 있음
3. ECS 로드 밸런서 통합
- ECS + ALB 연동 시, 컨테이너 상태에 따라 자동으로 Target 등록 / 해제함 (ex. unhealthy 컨테이너)
4. ECS 데이터 볼륨 (EFS)
- Task 컨테이너에서 EFS 마운트가 가능함
5. ECS (Task) Auto Scaling
- 서버에서 실행 중인 Task 수를 자동으로 스케일링 해줌
- ECS 평균 CPU / RAM 사용률
- ALB Target 당 요청 수
- CloudWatch Metric / Alarm
- EC2 인스턴스로 실행했을 시, EC2 인스턴스 수를 스케일링 해주지는 않는다.
- Task 수가 스케일링 되면, 이를 수용하는 EC2 인스턴스의 확장도 필요해진다.
- EC2 인스터는 ASG로 묶어서 관리를 해야 함.
- ECS Capacity Provider를 통해 ASG와 ECS Task Auto Scaling을 연동하여, EC2 인스턴스를 자동으로 확장시킬 수 있음.
- Fargate 실행 시의 서버리스이기 때문에 AWS에서 자동으로 스케일링 해준다.
6) ECR
: ECR(Elastic Container Registry), AWS에서 제공하는 도커 이미지 저장소 서비스이다.
특징
- 도커 이미지는 S3 기반으로 안전하게 저장된다.
- private 저장소뿐만 아니라, public 제공하여 도커 이미지 공유가 가능하다.
- 접근 권한은 AWS IAM(Identity and Access Management)을 통해서 관리한다
7) EKS
: EKS(Elastic Kubernetes Service), AWS에서 쿠버네티스를 실행하기 위한 서비스이다.
쿠버네티스
- 애플리케이션 컨테이너를 자동으로 배포, 확장, 관리하는 오픈소스 오케스트레이션(조율) 서비스이다.
- 클라우드 독립적이기 때문에, 어디서든 동일한 환경으로 운영할 수 있다.
특징
- 이미 구축된 쿠버네티스 환경을 AWS EKS로 그대로 마이그레이션 해 사용할 수 있다.
- 쿠버네티스의 제어 플레인(마스터 노드)을 AWS가 대신 관리하여, 사용자는 워커 노드를 손쉽게 생성하고 운영할 수 있다.
실행 방식
- Managed Node Groups
- AWS가 EC2 노드를 자동으로 생성하고 관리해준다.
- AWS가 EC2 노드를 자동으로 생성하고 관리해준다.
- Self Managed Nodes
- 사용자가 EC2 인스턴스를 직접 생성하고 클러스터에 등록해야 한다.
- ASG 또한 직접 구성해야 되며, EC2 AMI도 선택이 가능하다. (EKS Optimized AMI 추천)
- Fargate
- 사용자가 워커 노드를 직접 생성하거나 관리할 필요 없이, 서버리스로 컨테이너 단위로 실행된다.
───
8) App Runner
: 서버와 인프라 구성 없이, 웹 애플리케이션을 쉽게 배포하고 실행할 수 있게 하는 완전 관리형 서비스
특징
- GitHub, ECR 에서 소스코드 또는 컨테이너 이미지를 가져와 자동으로 빌드 및 배포가 가능하다.
- 로드 밸런서, HTTPS 암호화, ASG, VPC 보안 등의 기능이 기본으로 제공된다.
9) App2Container (A2C)
: 온프레미스에서 실행 중인 Java 또는 .NET 애플리케이션을 컨테이너로 변환해 AWS로 마이그레이션하여 배포할 수 있게 하는 서비스
특징
- 실행 중인 Java 또는 .NET 애플리케이션을 분석하여 Dockerfile을 생성한다.
- 컴퓨팅 환경, 네트워크 구성을 분석하여 실행 시 자동으로 설정한다.
10) Lambda
: 이벤트 요청이 발생했을 때, 함수 단위의 코드를 서버리스로 실행시켜주는 서비스
(이벤트 요청 예시. S3 파일 업로드, DynamoDB 데이터 변경, CloudWatch Events EventBridge 스케줄링, API Gateway 요청)
특징
- 기본적으로 Lambda 함수는, 사용자가 만든 VPC 밖에서 실행된다.
- 즉, 사용자 VPC 내부의 리소스에 직접 접근이 불가능하다.
- 따라서 VPC 내부에서 실행되도록 하기 위해서는, VPC 설정(VPC ID, 서브넷, 보안 그룹)을 지정해주어야 한다.
실행 환경 (Lambda 함수 인스턴스)
- RAM: 128MB ~ 10GB
- 최대 실행 시간(Timeout): 15분
- 환경변수: 4KB
- 임시 디스크 용량(/tmp): 512MB ~ 10GB
- Lambda 함수가 실행될 때 사용되는 임시 파일을 저장할 때 사용된다.
배포 환경
- 배포 패키지(.zip, .jar) 크기: 50MB
- 압축 해제 후 코드 + 의존성 크기: 250MB
- Lambda 함수 배포는 AWS 내에서 코드를 작성할 수도 있지만, 직접 zip이나 jar 파일로 패키징해서 업로드 할 수도 있다.
SnapStart (Java 11)
- Lambda 함수가 생성될 때, Java 함수를 미리 초기화시킨 스냅샷을 생성시키고 이를 저장한다.
- 그리고 Java 함수가 실행될 때, 해당 스냅샷을 재사용하여 초기 실행시간을 크게 줄여 함수가 빠르게 실행될 수 있게 한다.
Lambda with RDS Proxy
- Lambda 함수가 DB에 직접 연결을 하게 되면, 이벤트 요청이 늘어나게 되면 DB 커넥션 풀이 빠르게 고갈될 수 있다.
- 이를 방지하기 위해, RDS Proxy를 두어 Lambda와 DB 간의 연결을 안정적으로 관리하도록 돕는다.
Invoking Lambda from RDS & Aurora
- DB 내에서 내부 트리거나 프로시저를 통해, Lambda를 호출할 수 있도록 지원한다.
- DB 인스턴스에서 Lambda 호출 권한과, Lambda로 아웃바운드 트래픽이 나갈 수 있도록 설정해야 한다.
RDS Event Notifications
- RDS에서 발생한 이벤트에 대한 알림 기능을 제공한다.
- ex. DB 인스턴스 생성, 삭제, 스냅샷 완료 등
- SNS로 알림을 전송하거나, EventBridge와 연동하여 추가적인 이벤트 기반의 워크플로우 구현이 가능하다.
- DB 데이터 변경에 대한 정보는 제공하지 않는다.
11) DynamoDB
: AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스이다.
특징
- 분산 데이터베이스로, 초당 수백만 요청을 처리 가능한 높은 성능을 가지고 있다.
- 읽기 / 쓰기 처리량을 독립적으로 할당해 조정이 가능하다. (RCU / WCU, Capacity Units)
- 테이블 구조는 Table, Item, Attribute으로 구성되어 있다.
- Table이 최상위 개념으로, Table 안에 Item(=Row)들이 있고, Item은 Attribute(Key-Value)로 구성된다.
- Primary Key는 단일 Partition Key와 Partition Key와 Sort Key를 조합한 복합키 형태로 관리한다.
- 각 테이블은 반드시 Partition Key를 가져야 하고, 선택적으로 Sort Key를 지정할 수 있다.
- 테이블의 스키마, 속성(Attribute)은 유연하게 저장할 수 있다.
DynamoDB Accelerator (DAX)
- DynamoDB용 완전관리형 인메모리 캐시
- 일반적인 DynamoDB도 ms 단위로 응답하지만, DAX 적용 시 μs 단위로 응답한다.
백업
- Point in Time Recovery: 최대 35일간 모든 변경 이력을 보관하여, 새 테이블로 임의 시점 복구가 가능하다.
- On-Demand 백업: 사용자가 수동으로 진행하는 백업으로, 삭제하기 전까지 유지된다. 또한 백업이 진행되는 동안 테이블 성능에 영향을 주지 않는다.
- AWS Backup 서비스를 활용해 다른 리전으로의 백업 복사도 가능하다.
12) API Gateway
: API를 손쉽게 생성할 수 있도록 하는 완전관리형 서비스
REST API, HTTP
특징
- API Gateway + Lambda 조합으로, 서버 구축 없이 API를 쉽게 배포할 수 있다.
- Lambda 이외에도 다른 AWS 서비스 API를 호출이 가능하다.
- REST API, HTTP API, WebSocket API Gateway 세 가지 유형의 API 배포가 가능하다.
- HTTP API는 REST API Gateway의 일부 기능들을 제외하는 대신, 더 빠르게 동작하며 저렴한 비용으로 서비스를 제공한다.
(제외 기능: 클라이언트별 API Key 발급, 요청 및 응답 데이터 변환, 요청 검증, 응답 캐싱 등)
- HTTP API는 REST API Gateway의 일부 기능들을 제외하는 대신, 더 빠르게 동작하며 저렴한 비용으로 서비스를 제공한다.
- AWS IAM, JWT, OAuth, API Key 등 여러 인증 및 인가 방식을 지원한다.
API Gateway Endpoint 타입
- Edge-optimized
- 전 세계에 사용자가 있는 글로벌 서비스에 적합하다.
- CloudFront Edge 로케이션에서 API Endpoint가 배포되어 접근하는 방법이다.
- Regional
- 특정 리전 내에 사용자가 다수 있는, 로컬 서비스에 적합하다.
- Private
- VPC 내부에서만 접근이 가능한 엔드포인트이다.
- 인터넷을 통해서 직접 엑세스가 불가능하고, VPC Endpoint를 통해서만 접근이 가능하다.
13) Step Functions
: AWS 서비스의 복잡한 워크플로우를 시각적으로 구성하고, 실행할 수 있게 하는 서비스
풀어서 정리를 하면, 여러 AWS의 여러 서비스(Lambda, ECS, DynamoDB 등)들의 복잡한 워커플로우를 시각적으로 구성한여, 각 작업을 순차 실행, 병렬 처리, 조건 분기, 타임아웃, 에러 처리와 같이 어떻게 실행할 것인지 워크플로우를 구성할 수 있도록 하는 오케스트레이션 서비스이다.
14) Cognito
: 사용자가 웹, 모바일 애플리케이션에서 안전하게 로그인할 수 있도록, 인증/인가 기능을 제공하는 완전 관리형 서비스이다.
User Pools
- 사용자 계정 정보를 저장하고 관리하는, 사용자 디렉토리 서비스이다.
- 소셜 로그인(Google, Facebook, Apple, etc.), SAML, MFA 연동을 지원한다.
Identity Pools (Federated Identity Management)
- User Pools, 소셜 로그인, SAML을 통해 로그인한 사용자에게 AWS 리소스에 접근할 수 있는 임시 IAM Role 권한을 발급한다.
- ex. S3 업로드, DynamoDB 접근
(애플리케이션에서 등록된 사용자들에게, S3 버킷에 있는 자신의 폴더에서 이미지를 업로드 또는 다운로드할 수 있도록 구현 가능)
- ex. S3 업로드, DynamoDB 접근
'DevOps > AWS' 카테고리의 다른 글
AWS SAA 6주차 (0) | 2025.03.29 |
---|---|
AWS SAA 5주차 (0) | 2025.03.24 |
AWS SAA 4주차 (1) (0) | 2025.03.14 |
AWS SAA 3주차 (0) | 2025.03.08 |
AWS SAA 2주차 (0) | 2025.03.01 |