Hook

주문이 들어오면 결제, 재고, 배송, 알림이 차례로 기다려야 합니다. 하나라도 실패하면 전체가 멈춥니다. 이 강결합을 끊어주는 것이 메시징이고, 늘어난 마이크로서비스를 가볍게 띄워주는 것이 컨테이너입니다.

분산 시스템에서 서비스 간 통신은 동기식과 비동기식으로 나뉩니다. SQS/SNS/Kinesis/EventBridge는 통신을 비동기화하여 시스템을 디커플링하고, ECS/EKS/Fargate는 컨테이너 단위로 애플리케이션을 가볍고 빠르게 배포합니다. 이 글에서는 Part 1에서 SQS의 큐 유형과 가시성 제한, SNS의 Pub/Sub, Fan-out 패턴, Kinesis의 Streams/Firehose/Analytics, EventBridge와 MSK까지 정리하고, Part 2에서 VM과 컨테이너의 차이, Docker 기초, ECS의 Fargate/EC2 시작 유형, ECR, Kubernetes 핵심 개념, EKS, Fargate 비교까지 다룹니다.

TL;DR

• 동기 vs 비동기 — 동기는 강결합·장애 전파, 비동기 메시징은 느슨한 결합·메시지 보존으로 복구 후 처리
• SQS는 Pull, SNS는 Push — SQS는 작업 큐(최소 1회), SNS는 Pub/Sub 브로드캐스트, 둘을 묶으면 Fan-out
• Kinesis 3종 — Streams(실시간 샤드), Firehose(준실시간 자동 적재), Analytics(SQL/Flink 실시간 분석)
• EventBridge는 2026 핵심 — 콘텐츠 기반 필터링·스키마 레지스트리·아카이브/재생 지원, 단순 브로드캐스트 SNS와 역할 분담
• 컨테이너는 VM보다 가볍다 — OS 커널 공유, MB 단위, 초 단위 시작, 높은 밀도
• ECS는 단순, EKS는 표준 — ECS+Fargate로 서버리스 컨테이너, EKS로 K8s 네이티브 생태계 활용

Part 1. 메시징 서비스

동기식 vs 비동기식 통신

분산 시스템에서 메시징 서비스는 서비스 간 결합도를 낮춰 독립성과 확장성을 확보합니다.

SQS (Simple Queue Service)

완전관리형 메시지 큐 서비스입니다. Pull 기반으로 소비자가 큐에서 메시지를 가져옵니다.

Standard vs FIFO Queue:

주요 속성:

가시성 시간 제한(Visibility Timeout)은 한 소비자가 메시지를 처리하는 동안 다른 소비자가 같은 메시지를 꺼내지 못하게 숨깁니다. 처리가 끝나면 삭제하고, 시간 초과 시 다시 노출되어 재시도됩니다.

보안:

• 전송 중 암호화: HTTPS (TLS)
• 저장 시 암호화: SSE-SQS (AWS 관리 키) 또는 SSE-KMS
• 액세스 제어: IAM 정책, 큐 정책

SNS (Simple Notification Service)

Publish/Subscribe 모델의 완전관리형 알림 서비스입니다. Push 방식으로 구독자에게 메시지를 전달합니다.

FIFO Topic:

• 순서 보장 + 중복 제거
• SQS FIFO Queue와만 호환
• 초당 300개 메시지 (배치 시 3000개)
• 메시지 그룹 ID 기반 파티셔닝

SNS + SQS Fan-out 패턴

하나의 이벤트를 여러 소비자에게 병렬로 전달하는 아키텍처 패턴입니다.

┌───────────────────────────┐
│        Producer           │
│    (S3 Event, Lambda 등)  │
└────────────┬──────────────┘
             │ Publish
┌────────────▼──────────────┐
│       SNS Topic           │
└─┬──────────┬──────────┬───┘
  │          │          │
  ▼          ▼          ▼
┌─────┐  ┌─────┐  ┌─────┐
│ SQS │  │ SQS │  │ SQS │
│Queue│  │Queue│  │Queue│
│ #1  │  │ #2  │  │ #3  │
└──┬──┘  └──┬──┘  └──┬──┘
   │        │        │
   ▼        ▼        ▼
┌─────┐  ┌─────┐  ┌─────┐
│Lambda│ │EC2  │ │Email│
│처리  │ │배치 │ │알림 │
└─────┘  └─────┘  └─────┘

• 각 소비자는 독립적으로 메시지를 처리합니다
• 한 소비자의 장애가 다른 소비자에게 영향을 주지 않습니다
• SQS의 재시도 및 DLQ(Dead Letter Queue)를 활용할 수 있습니다

Kinesis Data Streams

대규모 실시간 데이터 스트리밍 서비스입니다. 데이터를 수집, 저장, 처리할 수 있습니다.

💡 Kinesis vs SQS: Kinesis는 실시간 스트리밍과 데이터 재생이 필요한 경우, SQS는 작업 큐와 비동기 메시징에 적합합니다.

Kinesis Data Firehose

스트리밍 데이터를 변환 및 전송하는 완전관리형 서비스입니다. 실시간보다는 준실시간(Near Real-time) 처리에 적합합니다.

┌──────────┐     ┌─────────────────────┐     ┌─────────────┐
│  Data     │────▶│  Kinesis Firehose   │────▶│  S3         │
│  Source   │     │  (변환 Lambda 포함) │     │  Redshift   │
└──────────┘     └─────────────────────┘     │  OpenSearch  │
                                              │  Snowflake   │
                                              └─────────────┘

• 버퍼링: 크기(1~128MB) 또는 시간(60~900초) 기반 자동 적재
• 변환: Lambda 함수로 데이터 변환 가능
• 전송 대상: S3, Redshift, OpenSearch, Splunk, Snowflake 등
• 샤드 관리 불필요, 자동 확장

Kinesis Data Analytics

스트리밍 데이터를 SQL 또는 Python(Apache Flink)로 실시간 분석합니다.

• SQL 기반 실시간 쿼리
• Apache Flink 기반 Python 애플리케이션
• 창 함수(Window Functions): Tumbling, Sliding, Session
• 입력: Kinesis Data Streams, Firehose
• 출력: S3, Firehose, Lambda

Amazon EventBridge — 2026 핵심

서버리스 이벤트 버스 서비스로, 이벤트 기반 아키텍처의 핵심입니다.

• 기본 버스: AWS 계정의 기본 이벤트 버스
• 커스텀 버스: 애플리케이션 전용 이벤트 버스
• 파트너 버스: SaaS 파트너 이벤트 수신
• 규칙(Rule): 이벤트 패턴 매칭으로 타겟 라우팅

이벤트 기반 아키텍처 패턴:

┌────────┐  ┌────────┐  ┌────────┐
│ S3     │  │DynamoDB│  │EC2     │
│ 이벤트 │  │Streams │  │앱 이벤트│
└───┬────┘  └───┬────┘  └───┬────┘
    │           │           │
    └───────────┼───────────┘
                ▼
┌───────────────────────────┐
│    EventBridge 이벤트 버스  │
│    ┌─────────────────┐    │
│    │ Rule (필터링)    │    │
│    └──┬──────┬───────┘    │
└───────┼──────┼────────────┘
        │      │
   ┌────▼──┐ ┌─▼─────┐
   │Lambda │ │Step   │
   │함수   │ │Function│
   └───────┘ └───────┘

스트리밍 파이프라인 패턴:

┌──────────┐   ┌─────────────┐   ┌──────────────┐   ┌──────────┐
│ IoT /    │──▶│   Kinesis   │──▶│   Kinesis    │──▶│   S3     │
│ Click    │   │   Data      │   │   Data       │   │  (Data   │
│ Stream   │   │   Streams   │   │   Firehose   │   │   Lake)  │
└──────────┘   └──────┬──────┘   └──────────────┘   └──────────┘
                      │
                      ▼
               ┌──────────────┐
               │   Kinesis    │
               │   Analytics  │
               │   (실시간    │
               │    분석)     │
               └──────────────┘

Amazon MSK (Managed Streaming for Apache Kafka)

Apache Kafka 클러스터를 완전관리형으로 제공합니다. Kafka 네이티브 API를 그대로 사용할 수 있습니다.

Part 2. 컨테이너 서비스

VM vs Container

컨테이너는 OS 레벨 가상화로 호스트 커널을 공유하여 가볍고 빠릅니다.

┌─── VM ───────────────────┐  ┌─── Container ──────────────────┐
│  ┌─────────┐ ┌─────────┐ │  │ ┌───────┐ ┌───────┐ ┌───────┐ │
│  │  App A  │ │  App B  │ │  │ │ App A │ │ App B │ │ App C │ │
│  ├─────────┤ ├─────────┤ │  │ ├───────┤ ├───────┤ ├───────┤ │
│  │Guest OS │ │Guest OS │ │  │ │Bins/  │ │Bins/  │ │Bins/  │ │
│  │         │ │         │ │  │ │Libs   │ │Libs   │ │Libs   │ │
│  ├─────────┴─┴─────────┤ │  │ ├───────┴─┴───────┴─┴───────┤ │
│  │     Hypervisor       │ │  │ │   Container Runtime       │ │
│  ├──────────────────────┤ │  │ ├───────────────────────────┤ │
│  │     Host OS          │ │  │ │       Host OS             │ │
│  ├──────────────────────┤ │  │ ├───────────────────────────┤ │
│  │    Infrastructure    │ │  │ │     Infrastructure        │ │
│  └──────────────────────┘ │  │ └───────────────────────────┘ │
└──────────────────────────┘  └───────────────────────────────┘

Docker

컨테이너를 생성, 관리, 실행하는 오픈소스 플랫폼입니다.

# Dockerfile 예시
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

ECS (Elastic Container Service)

AWS의 관리형 컨테이너 오케스트레이션 서비스입니다. Kubernetes 없이 간단하게 컨테이너를 실행할 수 있습니다.

핵심 구성 요소:

시작 유형 — EC2 vs Fargate:

IAM Role 3종:

• EC2 인스턴스 Role: EC2 호스트가 ECR에서 이미지를 Pull, CloudWatch에 로그 전송
• Task Role: 컨테이너 내 애플리케이션이 AWS 서비스에 접근 (S3, DynamoDB 등)
• Task Execution Role: ECS Agent가 ECR 이미지 Pull, 로그 전송, Secrets 가져오기

ELB & EFS 연동:

• ALB/NLB 연동: Service별 대상 그룹 자동 등록, 동적 포트 매핑
• EFS 연동: 여러 Task 간 공유 파일 시스템, 영구 스토리지

ECR (Elastic Container Registry)

완전관리형 Docker 컨테이너 이미지 저장소입니다.

• 이미지 저장, 버전 관리, 취약점 스캔
• 프라이빗 / 퍼블릭 레지스트리 지원
• Lifecycle Policy로 오래된 이미지 자동 정리
• 교차 리전 / 교차 계정 복제 지원
• IAM 기반 액세스 제어

Kubernetes 개념

컨테이너 오케스트레이션의 사실상 표준(De Facto Standard)입니다.

EKS (Elastic Kubernetes Service)

AWS의 관리형 Kubernetes 서비스입니다. Control Plane을 AWS가 완전 관리합니다.

관리형 컨트롤 플레인:

• 고가용성: 여러 AZ에 걸쳐 배포
• 자동 업데이트 및 패치
• etcd 백업 자동 관리
• API Server 엔드포인트: 퍼블릭 / 프라이빗 / 하이브리드

노드 유형:

AutoScaling:

💡 2026 권장: Karpenter는 Cluster Autoscaler 대비 빠른 스케일링, 유연한 인스턴스 선택, GPU/ARM 지원 등의 장점이 있습니다.

Fargate — Serverless 컨테이너

서버를 관리하지 않고 컨테이너를 직접 실행할 수 있습니다.

컨테이너 아키텍처 패턴

마이크로서비스 아키텍처:

┌──────────────────────────────────────────────────────┐
│                    ALB / NLB                          │
│  /api/users    /api/orders    /api/products          │
└──────┬─────────────┬──────────────┬──────────────────┘
       │             │              │
  ┌────▼────┐  ┌─────▼─────┐  ┌────▼────┐
  │  ECS    │  │   ECS     │  │  ECS    │
  │ Service │  │  Service  │  │ Service │
  │ (Users) │  │ (Orders)  │  │(Products│
  │ ┌─────┐ │  │ ┌───────┐ │  │┌──────┐│
  │ │Task1│ │  │ │Task1  │ │  ││Task1 ││
  │ │Task2│ │  │ │Task2  │ │  ││Task2 ││
  │ └─────┘ │  │ └───────┘ │  │└──────┘│
  └────┬────┘  └─────┬─────┘  └────┬────┘
       │             │              │
  ┌────▼────┐  ┌─────▼─────┐  ┌────▼────┐
  │  RDS    │  │ DynamoDB  │  │ElastiC. │
  │(Users)  │  │ (Orders)  │  │(Cache)  │
  └─────────┘  └───────────┘  └─────────┘

CI/CD 파이프라인:

┌────────┐  ┌─────────┐  ┌─────┐  ┌─────┐  ┌──────────┐
│ GitHub │─▶│CodeBuild│─▶│ ECR │─▶│ ECS │  │ECS       │
│ Push   │  │(이미지   │  │(저장)│  │Deploy│ │Blue/Green│
│        │  │ 빌드)    │  │     │  │     │  │배포      │
└────────┘  └─────────┘  └─────┘  └──┬──┘  └──────────┘
                                     │
                              ┌──────▼──────┐
                              │ CodeDeploy  │
                              │ (Blue/Green)│
                              └─────────────┘

Best Practices

메시징 서비스 선택 가이드:

컨테이너 런타임 선택 가이드:

핵심 모범 사례 6가지:

1. DLQ 필수 설정 — SQS/SNS 모두 Dead Letter Queue를 구성하여 반복 실패 메시지를 격리합니다
2. Long Polling 활성화 — SQS 빈 응답을 줄여 API 호출 비용과 빈 폴링을 감소시킵니다
3. Visibility Timeout 튜닝 — 처리 시간보다 여유 있게 설정하여 중복 처리를 방지합니다
4. 이미지 취약점 스캔 — ECR 자동 스캔을 켜고 Lifecycle Policy로 오래된 이미지를 정리합니다
5. 최소 권한 Task Role — 컨테이너별 전용 IAM Role을 부여하고 Execution Role과 분리합니다
6. Graviton(ARM) 활용 — 다중 아키텍처 이미지로 빌드하여 최대 20% 비용 절감, 40% 성능 향상을 얻습니다

Takeaway

1. 메시징으로 결합도를 낮춥니다 — 동기 호출의 강결합과 장애 전파를 비동기 메시징으로 해소합니다. 작업 큐는 SQS(Standard/FIFO), 이벤트 브로드캐스트는 SNS, 두 개를 결합한 Fan-out으로 독립적 병렬 처리를 구성하고, 실패 메시지는 DLQ로 격리하여 복구합니다.
2. 데이터 성격에 따라 스트리밍 서비스를 선택합니다 — 실시간 재생이 필요한 대용량 스트림은 Kinesis Data Streams, S3/Redshift로의 준실시간 적재는 Firehose, SQL/Flink 실시간 분석은 Analytics를 사용하고, 콘텐츠 기반 라우팅과 아카이브/재생이 필요한 애플리케이션 이벤트는 EventBridge, Kafka 네이티브 API가 필요하면 MSK로 분담합니다.
3. 워크로드 복잡도에 따라 컨테이너 플랫폼을 고릅니다 — 단순하고 서버 관리를 피하고 싶으면 ECS + Fargate, 세밀한 제어와 대규모 운영이 필요하면 ECS + EC2, Kubernetes 생태계와 이식성이 중요하면 EKS(노드 자동화는 Karpenter 권장)를 선택하고, 이미지는 ECR에서 취약점 스캔과 Lifecycle 정책으로 관리합니다.

AWS 시리즈 12/16

← 운영 & IaC — CloudWatch, CloudTrail, CloudFormation
	서버리스 — Lambda & API Gateway →