01. 기존 배포 방식의 문제 — Push 방식

• CI가 완료되면 Runner가 kubectl apply를 직접 실행해서 클러스터에 배포했음 (Push 방식)

[Push 방식]

  개발자 코드 Push
        |
        v
  GitHub Actions Runner
        |
        |  kubeconfig 필요 (외부에서 클러스터 접근)
        |  kubectl apply -f deployment.yaml
        v
  k8s 클러스터

  문제점:
    1. Runner 가 클러스터 외부에서 접근 -> kubeconfig 시크릿 노출 위험
    2. 배포 후 누군가 kubectl 로 직접 변경해도 감지 불가
    3. 롤백하려면 워크플로우를 다시 실행해야 함
    4. "지금 실제로 뭐가 배포되어 있지?" 를 Git 만으로 알 수 없음

02. GitOps 란 무엇인가 — Pull 방식

• GitOps는 배포 방식을 근본적으로 바꿈
• 클러스터가 스스로 Git 을 감시하다가 "Git 에 변경이 생기면 내가 알아서 맞춰나간다" 는 방식

[Pull 방식 — GitOps / ArgoCD]

  개발자 코드 Push
        |
        v
  App Repo    GitHub Actions CI 만 담당
        |     (빌드, 테스트, 이미지 Push)
        |
        v  이미지 태그만 업데이트
  Config Repo  (k8s 매니페스트만 있는 저장소)
        |
        |  ArgoCD 가 주기적으로 감시 (Pull)
        |  "Config Repo 가 바뀌었다 -> 클러스터도 맞춰야 한다"
        v
  k8s 클러스터
  ArgoCD Controller 가 내부에서 동기화
  (외부에서 접근 불필요 -> 보안 강화)

Push vs Pull 비교

03. 핵심 용어 정리

06. 이중 레포지토리 전략

• GitOps 에서 가장 중요한 패턴 중 하나
• 소스 코드와 배포 설정을 반드시 분리해서 관리

왜 분리해야 하는가?

• 개발자는 소스 코드만 변경해야 함 (배포 설정 실수 방지)
• 배포 이력을 소스 커밋과 별도로 추적
• 운영팀이 배포 설정만 별도 검토/승인 가능

┌─────────────────────────────────────────────────────────────┐
│                  이중 레포지토리 전략                     │
├───────────────────────────┬─────────────────────────────────┤
│  App Repository         │  Config Repository           │
│  (소스 코드)             │   (k8s 매니페스트)             │
│                         │                              │
│  src/                   │  apps/spring-boot/           │
│  Dockerfile             │    base/                     │
│  pom.xml                │      deployment.yaml         │
│  .github/workflows/     │      service.yaml            │
│    ci.yml  <- CI 전담    │    overlays/                 │
│                         │      dev/                    │
│  변경 주체: 개발자        │      staging/                │
│                         │      prod/                   │
│                         │  argocd/                     │
│                         │    applicationset.yaml       │
│                         │                              │
│                         │  변경 주체: CI 봇 + 운영팀      │
└───────────────────────────┴─────────────────────────────────┘
          |                              |
          | 이미지 빌드 완료                | ArgoCD 가 감시
          | 태그 업데이트 커밋 -------->    |
          v                              v
      ECR / DockerHub              k8s 클러스터

01. ArgoCD 컴포넌트 아키텍처

• ArgoCD 는 단일 프로세스가 아니라 여러 컴포넌트가 역할을 나눠서 동작
• 각 컴포넌트는 독립된 Pod 로 배포되며 Redis 를 통해 상태를 공유

┌─────────────────────────────────────────────────────────────┐
│           ArgoCD 컴포넌트 (argocd Namespace)            │
├─────────────────────────────────────────────────────────────┤
│                                                        │
│  ┌─────────────────────┐   ┌─────────────────────────────┐  │
│  │     API Server    │   │   Application Controller  │  │
│  │  UI / CLI / API   │   │  Reconciliation Loop      │  │
│  │  RBAC 적용         │   │  Desired vs Live 비교     │  │
│  │  SSO 연동          │   │  Sync 실행                │  │
│  └──────────┬──────────┘   └──────────────┬──────────────┘  │
│            │                           │                │
│  ┌──────────┴──────────┐   ┌──────────────┴──────────────┐  │
│  │     Repo Server   │   │           Redis           │  │
│  │  Git clone        │   │  App 상태 캐시             │  │
│  │  매니페스트 렌더링   │   │  세션 관리                 │  │
│  └─────────────────────┘   └─────────────────────────────┘  │
│                                                        │
│  ┌─────────────────────┐                                 │
│  │        Dex        │  SSO / OIDC Provider            │
│  └─────────────────────┘                                 │
└─────────────────────────────────────────────────────────────┘

동작 흐름

사용자가 App 을 등록하면

  1. API Server
     요청 수신, RBAC 검사
         |
         v
  2. Repo Server
     Config Repo 에서 YAML 가져와서 렌더링
         |
         v
  3. Application Controller
     Git YAML 과 클러스터 상태 비교
     차이 있으면 Sync 실행
         |
         v
  4. Redis
     결과 상태 캐시 저장

매니페스트 관리 — Kustomize

01. Kustomize란

• Kustomize는 템플릿 없이 YAML을 오버레이 방식으로 커스터마이징하는 도구
• kubectl에 내장되어 있고 ArgoCD가 기본 지원

02. Kustomize 핵심 문법

• kustomization.yaml이 핵심 파일
• resources, images, patches, namespace 4가지 필드를 중심으로 구성

03. ApplicationSet — 멀티 환경 자동화

• ApplicationSet은 하나의 템플릿으로 여러 Application을 자동 생성
• Config Repo 디렉토리 구조만으로 dev/staging/prod 환경을 자동 감지

매니페스트 관리 — Helm (서드파티 패키지)

01. Helm이란

• Helm은 Kubernetes의 패키지 매니저
• Prometheus, Grafana, ArgoCD 자체 설치 등 서드파티 패키지에 주로 사용

02. Prometheus + Grafana 설치 (kube-prometheus-stack)

• kube-prometheus-stack은 Prometheus Operator + Grafana + AlertManager + node-exporter를 묶은 Helm Chart

GitHub Actions CI + ArgoCD CD 연동

01. CI/CD 역할 분리

• GitHub Actions 는 CI(빌드, 테스트, 이미지 Push) 만 담당하고 CD(배포) 는 ArgoCD 가 담당
• CI 가 Config Repo 의 이미지 태그만 업데이트하면 ArgoCD 가 감지하고 자동으로 배포

gitops-app (App Repo)
STS: C:\CE\99.practice\argocd-lab\gitops-app\

  개발자 코드 Push
       |
       v
  GitHub Actions CI
    테스트 실행
    Docker 이미지 빌드
    DockerHub Push (sha-xxxxxxx 태그)
    gitops-config 이미지 태그 업데이트 [skip ci]
       |
       v
gitops-config (Config Repo)
/home/k8s/argocd-lab/gitops-config/

  apps/gitops-app/overlays/dev/kustomization.yaml
    images:
      newTag: sha-xxxxxxx  <- 업데이트됨
       |
       v
  ArgoCD 3분 폴링 감지
       |
       v
  k8s 클러스터 자동 배포

ArgoCD 접속

# port-forward 실행
kubectl port-forward svc/argocd-server \
  -n argocd 8080:443 --address=0.0.0.0 &

# 호스트 PC 브라우저에서 접속: https://192.168.56.10:8080

# CLI 비밀번호 확인
ARGOCD_PASS=$(argocd admin initial-password -n argocd | head -1)
echo "초기 비밀번호: $ARGOCD_PASS"

Spring Boot 멀티 앱 CI — 분산 호출 GitOps 완성

01. Spring Boot 소스 대체

• 매니페스트 골격은 완성
• 그 위에 Spring Boot 소스 코드를 얹어서 두 앱 간 분산 호출이 동작하는 시스템 구현

동작 흐름

[개발자]
  ↓ git push (gitops-app, ops-app1/ 변경)
[GitHub Actions]
  ↓ ci-ops-app1.yml만 트리거 (paths filter)
  ↓ Maven 빌드·테스트·Docker 빌드
  ↓ DockerHub Push (sha-xxxxxxx 태그)
  ↓ gitops-config의 ops-app1/overlays/dev/kustomization.yaml 업데이트
[ArgoCD]
  ↓ Config Repo 변경 감지 (또는 Refresh)
  ↓ ops-app1-dev Application 자동 Sync
[ops-app1 Pod]
  ↓ 새 이미지로 롤링 배포
  ↓ ops-app1 → ops-app2 분산 호출 가능
[사용자]
  → kubectl port-forward로 외부 접근 → 응답 확인

02. App Repo 디렉토리 구조 — 모노리포

• gitops-app 저장소를 모노리포로 구성
• 두 앱 소스가 한 저장소에 공존하지만 각 앱의 변경만 해당 워크플로우 트리거

모노리포 장점

1. 한 저장소에서 두 앱 동시 작업 가능
   - 두 앱이 함께 변경되는 기능 개발 (예: API 스펙 변경)
   - 한 PR로 두 앱 변경 묶음 관리

2. CI/CD 자동화 패턴 통일
   - 같은 워크플로우 패턴을 두 앱에 일관 적용
   - paths filter로 변경된 앱만 CI 실행

3. 의존성 버전 통일
   - 두 앱 Spring Boot·JDK 버전 자동 일치

4. 코드 공유 용이
   - 공통 DTO·예외 클래스 등을 한 저장소에서 관리 (향후 확장)

EKS GitOps

01. EKS에서의 GitOps 확인

• 로컬 kubeadm 환경에서 완성한 GitOps 환경(ArgoCD + Spring Boot 두 앱)을 AWS EKS 운영 환경 이식
• GitOps 구조는 동일, 인프라만 교체. 외부 노출은 K8s 표준 Gateway API(Ingress 미사용)

로컬 환경 vs EKS 환경 차이점

                       로컬 환경             EKS 환경
─────────────────────────────────────────────────────────────
인프라 구축             VirtualBox·UTM        Terraform (Bastion+VPC+EKS+IRSA)
K8s 설치                kubeadm               EKS 1.35 + Managed Node
이미지 저장소            DockerHub             ECR (Private, IMMUTABLE)
CI 인증                 Token (Access Key)    GitHub OIDC (Access Key 제거)
ArgoCD UI 접근          port-forward          Gateway API HTTPRoute
앱 외부 노출            port-forward           Gateway API (ALB)
외부 노출 방식         Ingress (수동 NodePort)  Gateway API CRD 5종
Secret 관리             매니페스트 평문          SSM Parameter + ESO
IAM·IRSA                 없음                 Terraform 자동 Role 생성
EBS Storage             hostPath              EBS CSI Driver + gp3

핵심: 매니페스트·CI·ArgoCD 구조는 동일, 인프라만 교체

External Secrets Operator

• 쿠버네티스 외부의 시크릿 저장소(AWS Secrets Manager, SSM Parameter Store, HashiCorp Vault, GCP Secret Manager 등)에 보관된 값을 클러스터 내부 Secret 리소스로 동기화하는 오퍼레이터

┌──────────────────────────────────────────────────────────────┐
│                      AWS Secrets Manager                │
│         secret name: prod/order-service/db              │
│         { "username": "admin", "password": "***" }      │
└───────────────────────────────┬──────────────────────────────┘
                             │ (1) IRSA로 인증 후 GetSecretValue
                             ▼
┌──────────────────────────────────────────────────────────────┐
│                  External Secrets Operator              │
│                                                         │
│ ClusterSecretStore ──── 인증/엔드포인트 정의 (클러스터 공용) │
│         ▲                                               │
│         │ 참조                                           │
│  ExternalSecret ─────── 어떤 외부 키 → 어떤 K8s Secret으로  │
│         │                                               │
│         ▼ (2) refreshInterval 마다 동기화                 │
│   Secret (Opaque)                                       │
└───────────────────────────────┬──────────────────────────────┘
                             │ (3) volume / envFrom
                             ▼
                         Application Pod

운영 환경 이식의 핵심 통찰

  1. GitOps 자산의 80%는 그대로 이식
     - Spring Boot 소스 100% 동일
     - Kustomize base 100% 동일
     - ApplicationSet 구조 동일

  2. 변경 영역
     - Image URL (DockerHub → ECR)
     - Namespace 이름 (env 접두사)
     - 외부 노출 방식 (port-forward → Gateway API)
     - Secret 관리 (평문 → ESO + SSM)
     - CI 인증 (Access Key → OIDC)

  3. 인프라 영역
     - 로컬: VirtualBox·UTM 수동 관리
     - 운영: Terraform IaC 자동 관리
       (ALB Controller·EBS CSI·ESO IRSA + ECR + OIDC)

EKS Prometheus + Grafana — ServiceMonitor·골든 시그널·분산 호출 관찰

01. EKS 환경의 멀티 앱 모니터링 풀스택

• EKS 위에 kube-prometheus-stack을 신규 설치하고 ops-app1·ops-app2의 메트릭을 통합 수집하여 멀티 앱 분산 환경의 골든 시그널 관찰
• 부하 시뮬레이션 → 4가지 핵심 지표 변화 → 분산 호출 흐름 추적까지 완성

동작 흐름

[ops-app1 Pod / ops-app2 Pod]
  ↓ Actuator + Micrometer가 /actuator/prometheus 엔드포인트 노출
  ↓ http_server_requests_seconds, jvm_memory_used_bytes 등 자동 수집

[Prometheus]
  ↑ ServiceMonitor를 통해 15초마다 스크랩
  ↑ Service 라벨 selector로 두 앱 Pod 자동 발견

[Grafana]
  ↑ Prometheus를 데이터소스로 시각화
  ↑ JVM 대시보드·Spring Boot 대시보드 자동 Import
  ↑ 골든 시그널 4가지 패널 사용자 정의

[부하 시뮬레이션]
  curl /load?type=slow  → Latency 폭증 관찰
  curl /load?type=error → 5xx 비율 폭증 관찰
  curl /load?type=cpu   → CPU 사용률 폭증 관찰

02. kube-prometheus-stack 설치

• EKS 클러스터(monitoring 네임스페이스)에 kube-prometheus-stack을 Helm으로 신규 설치

kube-prometheus-stack (단일 Helm Chart로 모든 포함)
├── Prometheus Operator   CRD 관리 (ServiceMonitor·PrometheusRule·Alertmanager)
├── Prometheus            메트릭 수집·저장 (15초 스크랩, 7일 보관)
├── Grafana               시각화 대시보드
├── AlertManager          알림 관리 (학습 환경 비활성)
├── node-exporter         EKS 노드 메트릭
└── kube-state-metrics    K8s 오브젝트 메트릭 (Pod·Deployment 등)

03. Spring Boot Actuator + Micrometer Prometheus

• Spring Boot Actuator의 기본 메트릭(HTTP 요청·JVM 메모리·GC 등)을 Prometheus 형식으로 노출하려면 micrometer-registry-prometheus 의존성 1개 추가
• 추가 코드 작성 없이 /actuator/prometheus 엔드포인트 자동 생성

자동 노출되는 핵심 메트릭

[HTTP 요청 메트릭 — 골든 시그널의 핵심]
  http_server_requests_seconds_count
    {application="ops-app1", method="GET", uri="/api/orders", status="200"} 42

  http_server_requests_seconds_sum
    {application="ops-app1", ...} 1.234

  http_server_requests_seconds_bucket    (Histogram)
    {application="ops-app1", le="0.5"} 38
    {application="ops-app1", le="1.0"} 41
    {application="ops-app1", le="2.0"} 42

[JVM 메모리 메트릭]
  jvm_memory_used_bytes{area="heap", id="..."}
  jvm_memory_max_bytes{area="heap", id="..."}
  jvm_gc_pause_seconds_count
  jvm_threads_live_threads

[시스템 메트릭]
  system_cpu_usage
  process_cpu_usage
  system_load_average_1m
  process_uptime_seconds

[Tomcat 메트릭]
  tomcat_sessions_active_current_sessions
  tomcat_threads_busy_threads
  tomcat_threads_current_threads

04. ServiceMonitor CRD — Prometheus 자동 스크랩

• ServiceMonitor는 Prometheus Operator의 CRD. K8s Service의 어떤 포트·경로에서 메트릭을 가져올지 선언
• Service 라벨 selector로 자동 발견 — 새 Pod 추가/삭제 시 즉시 반영

ServiceMonitor 동작 흐름

[ServiceMonitor 생성]
  apiVersion: monitoring.coreos.com/v1
  selector.matchLabels: app.kubernetes.io/name=ops-app1
       ↓
[Prometheus Operator]
  - ServiceMonitor CRD 감시
  - Service selector 매칭
  - Prometheus 설정에 추가
       ↓
[Prometheus]
  - 15초마다 매칭된 Service의 모든 Pod의 /actuator/prometheus 스크랩
  - Pod 추가/삭제 자동 반영
       ↓
[메트릭 수집]
  http_server_requests_seconds_count{
    application="ops-app1",
    namespace="ops-app1-dev",
    pod="ops-app1-xxx-yyy"
  }

05. SRE Golden Signals 4가지

• Google SRE Book이 정의한 운영의 핵심 4가지 지표

SRE 4 Golden Signals

  1. Latency (지연시간)
     - p50 / p95 / p99 응답 시간
     - 사용자 경험의 핵심
     - 본 강의 측정: /load?type=slow → 폭증

  2. Traffic (트래픽)
     - 초당 요청 수 (RPS)
     - 시스템 부하 측정
     - 본 강의 측정: 반복 요청 → 증가

  3. Errors (에러)
     - 4xx, 5xx 비율
     - 정상성 측정
     - 본 강의 측정: /load?type=error → 5xx 폭증

  4. Saturation (포화도)
     - CPU·메모리·디스크·스레드풀 등 리소스 사용률
     - 한계 도달 임박 지표
     - 본 강의 측정: /load?type=cpu → CPU 폭증

이상 패턴 식별

CloudWatch 기초·메트릭·로그

01. CloudWatch

• AWS의 통합 모니터링·관측 가능성 서비스
• 3대 데이터(Metric·Log·Event)와 부가 기능(Alarm·Dashboard·Insights·EventBridge)으로 구성
• AWS 모든 서비스가 기본 메트릭을 자동 전송하며 사용자 정의 메트릭·로그도 수집 가능

CloudWatch 전체 구조

┌──────────────────────────────────────────────────────────────────┐
│                     CloudWatch 핵심 데이터                   │
│                                                            │
│  Metric (메트릭)         Log (로그)         Event (이벤트)    │
│  - 시계열 숫자 데이터     - 텍스트 로그       - 상태 변경 이벤트  │
│  - 네임스페이스·차원      - Log Group 단위   - EventBridge 통합│
│  - 통계 (Avg/Sum/p99)   - Logs Insights    - 자동 대응 가능   │
│                                                            │
└──────────────────────────────────────────────────────────────────┘
                          │
                          ▼
┌─────────────────────────────────────────────────────────────────┐
│                     CloudWatch 부가 기능                    │
│                                                            │
│   Alarm                   Dashboard            Insights    │
│   - 임계치 기반 알림        - 시각화·공유         - 로그 쿼리   │
│   - SNS → Slack 등        - 위젯 조합           - 패턴 분석   │
│                                                            │
│  EventBridge           Container Insights   Logs Insights  │
│  - 자동 대응 규칙        - EKS 통합 모니터링    - SQL 유사 쿼리 │
│  - Lambda·SNS 트리거                                        │
└─────────────────────────────────────────────────────────────────┘

모니터링 vs 알람 vs 감사 구분

**모니터링 (Monitoring)**
  - 현재·과거 상태를 시각화
  - 대시보드·메트릭 차트
  - 트렌드 분석·용량 계획

**알람 (Alerting)**
  - 임계치 기반 자동 알림
  - 운영자에게 행동 요구
  - SNS·Slack·이메일 전송

**감사 (Auditing)**
  - 누가·언제·무엇을 했는가
  - CloudTrail (API 호출)
  - 컴플라이언스·포렌식

02. CloudWatch Metric — 시계열 수집·저장

• CloudWatch Metric은 시계열 숫자 데이터
• 모든 AWS 서비스가 기본 메트릭을 자동 전송. 네임스페이스(AWS/EC2 등)·차원(InstanceId 등)·통계(Avg/Sum/Max/p99)로 구조화

메트릭 구조

네임스페이스 (Namespace)
  - AWS 서비스 단위 (AWS/EC2, AWS/RDS, AWS/EKS)
  - 사용자 정의 (Custom/MyApp)

메트릭 이름 (Metric Name)
  - CPUUtilization, NetworkIn 등

차원 (Dimension)
  - 메트릭을 구분하는 키-값 쌍
  - 예: InstanceId=i-xxx, AutoScalingGroupName=asg-1
  - 최대 30개까지

통계 (Statistic)
  - Average, Sum, Maximum, Minimum, SampleCount
  - 백분위수: p50, p90, p95, p99

표준 메트릭 vs 상세 모니터링

EC2 기본 모니터링 (Basic, 5분 주기)
  - 무료
  - 5분 데이터 포인트

EC2 상세 모니터링 (Detailed, 1분 주기)
  - 인스턴스당 약 $2.10/월
  - 1분 데이터 포인트
  - 빠른 이상 감지·HPA·CloudWatch Alarm 정밀도 ↑

EKS·ECS·Lambda 등은 기본적으로 1분 주기 메트릭

03. CloudWatch Logs — 로그 수집·저장·조회

• CloudWatch Logs는 텍스트 로그를 Log Group·Log Stream 구조로 수집·저장

Log Group / Log Stream 구조

Log Group (로그 그룹)
  - 보존 기간·암호화·구독 등 설정 단위
  - 예: /aws/eks/ops-platform-eks/cluster
        /aws/lambda/my-function
        /aws/containerinsights/<cluster>/application

Log Stream (로그 스트림)
  - 단일 소스의 시간 순 로그
  - 예: ec2/i-xxx
        pod/ops-app1/<container-id>

04. Dashboard — 시각화·공유

• 메트릭·로그를 한 화면에서 시각화

위젯 종류

Container Insights

• EKS 클러스터의 노드/Pod/컨테이너/네임스페이스 단위 메트릭과 로그를 자동 수집하여 CloudWatch로 통합 전송하는 관리형 옵저버빌리티 서비스
• Add-on 한 번 설치로 80여 개 지표가 자동 활성화

Control Plane Metrics와의 차이

┌──────────────────────────────────────────────────────────────┐
│  EKS CloudWatch 지표 체계                                │
├──────────────────────────────────────────────────────────────┤
│  [A] Control Plane Metrics  ── EKS 클러스터 옵션에서 활성화 │
│      ├─ Namespace: AWS/EKS                              │
│      ├─ apiserver_*, scheduler_*, etcd_*                │
│      └─ "클러스터 자체가 건강한가" 진단                     │
│                                                         │
│  [B] Container Insights     ── Add-on 별도 설치          │
│      ├─ Namespace: ContainerInsights                    │
│      ├─ cluster_*, node_*, pod_*, container_*, service_*│
│      └─ "워크로드와 노드가 건강한가" 진단                    │
└──────────────────────────────────────────────────────────────┘

CloudWatch Alarms + Logs Insights — 알람·자동화·로그 분석

01. CloudWatch Alarm 동작 원리

• Alarm은 메트릭이 임계치를 초과하면 자동으로 알림을 발송하거나 AWS 동작을 트리거하는 기능
• 운영 자동화의 핵심. SNS·EventBridge·Auto Scaling·EC2 Action 등 다양한 대상에 연결 가능

Alarm 상태 3종

OK
  - 임계치 안에 있음 (정상)
  - 알림 발송 없음

ALARM
  - 임계치 초과 (이상)
  - SNS·EventBridge로 알림 발송
  - 상태 변경 시 1회 발송 (지속 발송 아님)

INSUFFICIENT_DATA
  - 데이터 부족 (메트릭 수집 안 됨)
  - 운영 환경에서 알림 발송 정책 결정 필요

02. SNS + Slack 알림 체계 (콘솔 필수)

• CloudWatch Alarm은 직접 Slack 발송 안 함
• SNS(Simple Notification Service)를 거쳐서 알림 라우팅

알림 흐름

[CloudWatch Alarm]
  ↓ 상태 변경 시 발행
[SNS Topic]
  ↓ 구독자에게 fan-out
  ├──→ Email (직접 구독)
  ├──→ SMS
  ├──→ Lambda (자동 대응)
  ├──→ SQS (지연 처리)
  └──→ AWS Chatbot
       ↓
       └──→ Slack 채널

03. EventBridge 자동화

• EventBridge는 AWS의 이벤트 라우팅 서비스
• 자가 치유(Self Healing) 패턴의 핵심

01. 스케줄링 개요

• 스케줄링(Scheduling) 은 새로 생성된 Pod을 어느 노드에 실행할지 결정하는 과정

                         ┌─────────────────────────────────┐
   사용자 요청             │  kube-scheduler              │
   (Pod 생성)             │                              │
        │                │  1. 미할당 Pod 감지            │
        │                │ 2. Filtering (가능한 노드 선별) │
        ▼                │  3. Scoring (점수로 순위 매김)  │
   ┌─────────┐            │  4. Binding (최종 배정)        │
   │ K8s API│  ───────►   │                              │
   └─────────┘            └────────────────┬────────────────┘
                                         │
                          ┌───────────────┼───────────────┐
                          ▼              ▼              ▼
                     ┌────────┐     ┌────────┐     ┌────────┐
                     │node-1 │     │ node-2 │     │node-3 │
                     │ (선택) │     │        │    │       │
                     └────────┘     └────────┘     └────────┘

스케줄링의 3단계

  1단계 Filtering         2단계 Scoring         3단계 Binding
 ─────────────────       ────────────────       ───────────────
  실행 가능한 노드        각 노드에 점수         최고 점수 노드에
  목록 추출 (큐)          부여 후 순위 결정      Binding 이벤트 발행

02. Label과 Selector

• 스케줄링 동작의 대부분은 Label(키-값 메타정보)과 Selector(라벨 기반 질의)로 이루어짐

03. 스케줄링 방법 5가지 비교

• Kubernetes는 Pod을 특정 노드에 배치하는 5가지 메커니즘을 제공
• 각각 사용 시점과 강점이 다르므로 상황에 맞게 선택

04. 5가지 방법 최종 정리

[Pod을 어느 노드에 둘까?]
        │
        ▼
┌─────────────────────────────────────────────────────┐
│ Q1. 정확히 한 노드에 강제 배치?                    │
│      Yes → nodeName (디버깅 외 비권장)            │
│      No  ↓                                      │
│                                                 │
│ Q2. 단순 라벨 매칭으로 충분?                       │
│      Yes → nodeSelector                         │
│      No  ↓                                      │
│                                                 │
│ Q3. 다양한 연산자/가중치 필요?                      │
│      Yes → nodeAffinity                         │
│      No  ↓                                      │
│                                                 │
│ Q4. 다른 Pod의 위치 기준?                         │
│      Yes → podAffinity / podAntiAffinity        │
│      No  ↓                                      │
│                                                 │
│ Q5. 노드가 특정 Pod만 받게 하려는가?                │
│      Yes → taints + tolerations                 │
└─────────────────────────────────────────────────────┘

Kubernetes 오토스케일링 (Autoscaling)

01. 오토스케일링 개요

• 워크로드 부하에 따라 클러스터 또는 워크로드 용량을 자동으로 조정하는 기능

오토스케일링 3종 비교

02. Metrics Server

• 오토스케일링의 모든 출발점은 Metrics Server
• Pod·Node의 CPU·Memory 사용량을 수집하여 K8s API 표준 형식으로 노출하며, HPA·VPA 모두 이 데이터를 참조

03. HPA (Horizontal Pod Autoscaler)

• HPA는 Pod의 개수(replicas) 를 부하에 따라 자동 조정

HPA 동작 흐름

   ┌─────────────────────────────────────────────────────────┐
   │  1. 사용자가 HPA 리소스 생성                          │
   │     - target: Deployment / StatefulSet / ReplicaSet│
   │     - min/max replicas                             │
   │     - 메트릭과 임계값                                │
   └─────────────────┬───────────────────────────────────────┘
                     │
                     ▼ 15초 주기로 반복
   ┌────────────────────────────────────────────────────────────┐
   │  2. HPA Controller                                    │
   │     - Metrics Server에서 현재 메트릭 조회                │
   │     - 목표 replicas 계산                               │
   │       desiredReplicas = ceil(currentReplicas ×        │
   │                         currentMetric / targetMetric) │
   └─────────────────┬──────────────────────────────────────────┘
                     │
                     ▼
   ┌────────────────────────────────────────────────────────┐
   │  3. Deployment.spec.replicas 변경                  │
   │     → ReplicaSet이 Pod 추가/제거                    │
   └────────────────────────────────────────────────────────┘

대상 Deployment 작성

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scalable-web
  labels:
    app.kubernetes.io/name: scalable-web
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: scalable-web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: scalable-web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: 50m                        # HPA 계산 기준 (필수)
            memory: 50Mi
          limits:
            cpu: 200m
            memory: 100Mi
        ports:
        - containerPort: 80

HPA 리소스 작성

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: scalable-web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: scalable-web
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50              # 목표 CPU 사용률 50%

04. VPA (Vertical Pod Autoscaler)

• VPA는 Pod의 리소스 요청량(requests/limits) 을 자동 조정
• HPA가 "Pod 개수를 바꾼다"면 VPA는 "Pod 한 개의 크기를 바꾼다"는 차이가 핵심

   ┌─────────────────────────────────────────────┐
   │  VPA Recommender                        │
   │   - Metrics Server 데이터 수집            │
   │   - 사용량 히스토리 분석                   │
   │   - 적정 cpu/memory 추천 계산             │
   └────────────────────┬────────────────────────┘
                        │ 추천값 저장
                        ▼
   ┌─────────────────────────────────────────────┐
   │  VPA Updater                            │
   │   - 1분 주기로 실행 중 Pod 검사            │
   │   - 추천값 범위 벗어나면 Pod 축출(eviction) │
   └────────────────────┬────────────────────────┘
                        │
                        ▼ Pod 재생성 시점
   ┌─────────────────────────────────────────────┐
   │  VPA Admission Webhook (Mutating)       │
   │   - 새 Pod 스펙 가로채기                   │
   │   - resources.requests/limits 수정       │
   │   - 수정된 스펙으로 Pod 생성               │
   └─────────────────────────────────────────────┘

05. Cluster Autoscaler 개념

동작 흐름

   1. HPA가 Pod 추가 요청 → replicas 증가
            ↓
   2. 노드 리소스 부족 → 새 Pod이 Pending
            ↓
   3. Cluster Autoscaler가 Pending Pod 감지
            ↓
   4. 클라우드 API 호출 (AWS Auto Scaling Group, GCP MIG 등)
            ↓
   5. 새 노드 생성 (1~3분) → Pod이 새 노드에 배치
            ↓
   6. 부하 감소 시 빈 노드 감지 → 노드 제거

ubernetes 인증 (Authentication)

01. 인증 개요

• 클러스터에 접근하려는 주체가 "누구인지"를 증명하는 과정
• Kubernetes API Server는 모든 요청에 대해 다음 두 단계를 거침

02. 인증 방식 종류

• Kubernetes는 여러 인증 방식을 동시에 지원
• API Server는 설정된 인증 모듈을 순서대로 시도하며, 하나라도 성공하면 통과

방식별 비교

03. kubeconfig 구조

• kubeconfig는 kubectl이 어떤 클러스터에, 어떤 사용자로 접속할지 정의한 YAML 파일

apiVersion: v1
kind: Config
clusters:
- name: k8s-cluster                      # 클러스터 별칭
  cluster:
    server: https://172.16.0.10:6443     # API Server 주소
    certificate-authority-data: <BASE64>  # CA 인증서 (서명 검증용)

users:
- name: kubernetes-admin                  # 사용자 별칭
  user:
    client-certificate-data: <BASE64>    # 클라이언트 인증서
    client-key-data: <BASE64>            # 클라이언트 개인키

contexts:
- name: admin@k8s-cluster                 # 컨텍스트 별칭
  context:
    cluster: k8s-cluster                  # 위 clusters 참조
    user: kubernetes-admin                # 위 users 참조
    namespace: default                    # 기본 네임스페이스

current-context: admin@k8s-cluster        # 현재 활성 컨텍스트

Kubernetes 인가 — RBAC

01. 인가(Authorization) 개요

• 인증된 사용자가 "어떤 리소스에 어떤 동작을 할 수 있는지"를 결정하는 과정

인가 모듈 종류

02. RBAC 4대 리소스

03. Role / ClusterRole 정의

• Role과 ClusterRole은 "어떤 리소스(resources)에 대해 어떤 동작(verbs)을 허용할지"를 명시

Role 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev                # ← Role은 반드시 네임스페이스 지정
  name: pod-reader
rules:
- apiGroups: [""]               # ← "" = core API group (Pod, Service 등)
  resources: ["pods"]           # ← 대상 리소스
  verbs: ["get", "list", "watch"]  # ← 허용 동작
- apiGroups: [""]
  resources: ["pods/log"]       # ← 서브리소스 (Pod 로그 조회)
  verbs: ["get"]

ClusterRole 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader              # ← 클러스터 스코프 (namespace 필드 없음)
rules:
- apiGroups: [""]
  resources: ["nodes"]           # ← Node는 클러스터 스코프 리소스
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["nodes"]
  verbs: ["get", "list"]

04. RoleBinding / ClusterRoleBinding

• RoleBinding은 "누구(subjects)에게 어떤 Role(roleRef)을 부여하는지"를 정의

RoleBinding 예시

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: dev                  # ← 어느 네임스페이스에서 효력 발생
  name: alice-pod-reader-binding
subjects:
- kind: User                       # ← User / Group / ServiceAccount
  name: alice                      # ← 인증서 CN과 동일
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: dev-team                   # ← 인증서 O와 동일 (그룹 단위 부여)
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                       # ← Role 또는 ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

EKS 개념 이해

01. 왜 EKS가 필요한가

• 로컬 클러스터(kubeadm)는 Control Plane을 직접 설치하고 운영
• EKS는 Control Plane을 AWS가 완전 관리하므로 운영 부담이 없음

[ 로컬 클러스터 vs EKS 책임 범위 비교 ]

  로컬 (kubeadm)                     EKS
  ┌───────────────────────┐           ┌───────────────────────────────────┐
  │  사용자 직접 관리     │           │  AWS 관리 영역                   │
  │  ┌──────────────────┐ │           │  ┌──────────────────────────────┐ │
  │  │ Control Plane  │ │           │  │ EKS Control Plane          │ │
  │  │ kube-apiserver │ │  ──────▶  │  │ kube-apiserver (Multi-AZ)  │ │
  │  │ etcd           │ │           │  │ etcd (자동 백업)            │ │
  │  │ scheduler      │ │           │  │ scheduler / controller-mgr │ │
  │  │ controller-mgr │ │           │  └──────────────────────────────┘ │
  │  └──────────────────┘ │           │                                │
  │  ┌──────────────────┐ │           │  사용자 관리 영역                │
  │  │  Worker Node   │ │           │  ┌──────────────────────────────┐ │
  │  │  kubelet       │ │           │  │ Data Plane (EC2 / Fargate) │ │
  │  │  kube-proxy    │ │           │  │ kubelet / kube-proxy       │ │
  │  │  containerd    │ │           │  │ [Pods]                     │ │
  │  └──────────────────┘ │           │  └──────────────────────────────┘ │
  └───────────────────────┘           └───────────────────────────────────┘

02. EKS 아키텍처

• EKS Control Plane은 AWS가 관리하는 별도 VPC에서 실행
• Worker Node(Data Plane)는 사용자 VPC에 위치하며 ENI(Elastic Network Interface)를 통해 Control Plane과 통신

[ EKS 전체 아키텍처 ]

  외부 접근
  ┌──────────┐   HTTPS
  │ kubectl │──────────────┐
  └──────────┘             │
  ┌──────────┐   AWS API   │
  │ AWS CLI │──────────────┤
  └──────────┘             │
  ┌──────────┐   HTTPS     ▼
  │ Console │────────── 사용자 VPC
  └──────────┘  │
               │   ┌─────────────────────────────────────────────┐
               │   │  EKS Control Plane (AWS 관리 VPC)        │
               │   │  ┌────────────┐  ┌────────┐  ┌───────────┐  │
               └─▶│  │kube-      │  │ etcd   │  │scheduler │  │
                   │  │apiserver  │  │Multi-AZ│  │controller│ │
                   │  └────────────┘  └────────┘  └───────────┘  │
                   └──────────────────────┬──────────────────────┘
                                          │ ENI 연결
                   ┌──────────────────────▼───────────────────────┐
                   │  Data Plane (사용자 VPC)                  │
                   │  ┌──────────────────┐  ┌──────────────────┐  │
                   │  │  Node Group     │  │  Node Group    │  │
                   │  │  AZ: 2a         │  │  AZ: 2c        │  │
                   │  │  EC2 [Pod][Pod] │  │  EC2 [Pod][Pod]│  │
                   │  └──────────────────┘  └──────────────────┘  │
                   │                                           │
                   │  ┌──────────┐  ┌──────────┐  ┌───────────┐   │
                   │  │   ECR   │  │   IAM   │  │CloudWatch│   │
                   │  └──────────┘  └──────────┘  └───────────┘   │
                   └──────────────────────────────────────────────┘

로컬 k8s vs EKS 비교

05. EKS 핵심 구성 요소

Data Plane 옵션 비교

VPC CNI — EKS 네트워킹의 핵심

• Calico CNI를 사용하여 BGP 기반으로 Pod 간 통신
• EKS VPC CNI는 Pod IP = VPC의 실제 IP를 사용하는 방식으로 구조가 다름

[ Calico(k8s1 로컬) vs VPC CNI(EKS) 비교 ]

  Calico (BGP 라우팅)               VPC CNI (네이티브)

  Node: 10.0.1.10                   Node: 192.168.1.10
  Pod:  172.16.0.x                  Pod:  192.168.1.x  ← VPC IP 직접 사용
        │                                  │
  BGP 피어링 / IPIP 터널              ENI 통한 VPC 네이티브 라우팅
  Pod CIDR ≠ Node IP 대역             Pod IP = VPC IP 대역
  별도 CNI 설치 필요                   aws-node DaemonSet 기본 탑재

eksctl 클러스터 생성 — YAML 기반 EKS 클러스터 구성

01. eksctl 클러스터 생성 개요

• AML 파일 하나로 VPC, IAM Role, EKS 클러스터, Node Group을 한 번에 생성
• 내부적으로 CloudFormation 스택 2개를 생성하여 전체 인프라를 관리

02. cluster.yaml 주요 프로퍼티

YAML

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: eks-lab-cluster        # 클러스터 이름
  region: ap-northeast-2       # 서울 리전
  version: "1.35"              # Kubernetes 버전

vpc:
  nat:
    gateway: Single            # NAT Gateway 개수
    # gateway: HighlyAvailable  # AZ별 NAT GW — 비용 높음, HA 보장
    # gateway: Disable          # NAT GW 없음 — Private 서브넷 외부 통신 불가

  clusterEndpoints:
    publicAccess: true    # 인터넷에서 kubectl 접근 허용
    privateAccess: true   # 클러스터 VPC 내부에서 접근 허용

addons:
  - name: vpc-cni
    version: latest

iam:
  withOIDC: true               # IRSA 사용을 위한 OIDC Provider 자동 생성

managedNodeGroups:
  - name: ng-general
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 3
    amiFamily: AmazonLinux2023
    volumeSize: 30               # EBS 볼륨 크기(GB)
    volumeType: gp3              # 최신 EBS 타입, gp2 대비 성능 향상
    privateNetworking: true      # Private Subnet 배치 (보안 권장)
    labels:
      role: worker
      env: lab

최상위 필드

03. 주요 kubectl 명령어

클러스터 생성/삭제

# 클러스터 생성 (dry-run으로 사전 검증)
eksctl create cluster \
  --config-file cluster.yaml \
  --dry-run

# 클러스터 생성 (실제 실행, 약 15~20분)
eksctl create cluster \
  --config-file cluster.yaml

# 클러스터 삭제 (모든 리소스 함께 삭제)
eksctl delete cluster \
  --name $CLUSTER_NAME \
  --region $AWS_REGION \
  --wait

EKS 네트워킹 & IRSA — VPC CNI 원리와 Pod 단위 AWS 권한 부여

01. VPC CNI 동작 원리

• EKS에서 Pod IP는 VPC의 실제 IP를 직접 사용
• 노드에 ENI(Elastic Network Interface)를 추가로 연결하고, 각 ENI의 Secondary IP를 Pod에 할당

[ Calico(로컬 k8s1) vs VPC CNI(EKS) 비교 ]

  Calico — BGP 기반 라우팅 방식 (k8s 로컬 환경)
  Node A: 10.0.1.10                        Node B: 10.0.1.20
  ┌──────────────────────┐                 ┌──────────────────────┐
  │  Pod (172.16.0.2)  │                 │  Pod (172.16.1.2)  │
  │       │            │                 │       ▲            │
  │     veth           │                 │     veth           │
  │  cali* (veth pair) │ ──BGP 라우팅───▶ │  cali* (veth pair) │
  │  eth0 (10.0.1.10)  │  or IPIP 터널    │  eth0 (10.0.1.20)  │
  └──────────────────────┘                 └──────────────────────┘
  Pod IP ≠ Node IP (별도 Pod CIDR 사용)
  BGP 피어링 시 오버헤드 최소 / IPIP 모드 시 캡슐화 발생

---

  VPC CNI — 네이티브 방식 (EKS 환경)
  Node A: 192.168.1.10 (ENI 3개)          Node B: 192.168.2.10 (ENI 3개)
  ┌──────────────────────┐                ┌──────────────────────┐
  │ Pod (192.168.1.21) │                │ Pod (192.168.2.21) │
  │      │             │                │       ▲            │
  │    veth            │                │     veth           │
  │ ENI (VPC IP 직접)   │──VPC 라우팅───▶│ ENI (VPC IP 직접)   │
  └──────────────────────┘  터널 없음      └──────────────────────┘
  Pod IP = VPC IP → 별도 CNI 설치 불필요, VPC 라우팅 테이블 직접 활용

02. aws-node DaemonSet 확인

• VPC CNI는 aws-node DaemonSet으로 모든 노드에 1개씩 배포

# aws-node DaemonSet 확인
kubectl get daemonset aws-node -n kube-system

03. CoreDNS 동작 확인

• CoreDNS는 클러스터 내부 DNS 서버
• Pod 간 통신 시 서비스명.네임스페이스.svc.cluster.local 형태로 DNS 조회

04. OIDC Provider와 IRSA 개념

• Pod가 AWS 리소스(S3, DynamoDB 등)에 접근하는 방법은 3가지
• IRSA(IAM Roles for Service Accounts)가 유일하게 권장되는 방식

[ Pod의 AWS 리소스 접근 방식 비교 ]

  방법 1 — Access Key 하드코딩 (금지)
  ──────────────────────────────────────────────────
  Pod 환경변수에 AWS_ACCESS_KEY_ID, SECRET 직접 입력
  → 키 유출 시 전체 계정 위협, 로테이션 어려움

  방법 2 — Node IAM Role 과다 부여 (비권장)
  ──────────────────────────────────────────────────
  Worker Node EC2에 강력한 IAM Role 연결
  → 같은 노드의 모든 Pod가 동일한 강력한 권한 획득
  → 최소 권한 원칙 위반

  방법 3 — IRSA (권장)
  ──────────────────────────────────────────────────
  ServiceAccount ↔ IAM Role 1:1 연결
  → Pod 단위 최소 권한 적용
  → Access Key 없음, 자동 갱신
  → CloudTrail에 Pod 단위로 기록됨

IRSA 동작 흐름

[ IRSA 전체 동작 흐름 ]

  사전 설정:
  ┌─────────────────────────────────────────────────────────┐
  │ 1. EKS OIDC Endpoint → AWS IAM OIDC Provider로 등록 │
  │ 2. IAM Role 신뢰 정책: 이 SA에서 온 토큰만 Assume 허용  │
  │ 3. ServiceAccount에 IAM Role ARN 어노테이션 추가      │
  └─────────────────────────────────────────────────────────┘

  런타임 동작:
  Pod 시작
      │
      ▼
  k8s가 OIDC JWT 토큰 자동 마운트
  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
      │
      ▼
  AWS SDK → STS AssumeRoleWithWebIdentity 요청
      │
      ▼
  STS가 OIDC Provider를 통해 토큰 검증
      │
      ▼
  임시 자격증명 발급 (자동 갱신)
      │
      ▼
  S3 / DynamoDB 등 AWS 서비스 호출 성공

워크로드 배포 및 외부 노출 — Deployment / Gateway API / ALB Controller

01. 워크로드 배포 전체 흐름

• EKS에서 애플리케이션 배포는 ECR 이미지 푸시 → Deployment 생성 → Service 생성 → Gateway API로 외부 노출 순서로 진행

[ EKS 워크로드 배포 흐름 ]

     로컬 빌드               ECR                  EKS 클러스터
  ┌──────────────┐       ┌──────────┐         ┌────────────────────────────────┐
  │ Dockerfile  │─────▶ │  Image  │───────▶ │  Deployment (Pods)          │
  └──────────────┘ push  │ Registry│  pull   │  ┌──────────┐  ┌──────────┐   │
                        └──────────┘         │  │  Pod 1  │  │  Pod 2  │   │
                                            │  └────┬─────┘  └────┬─────┘   │
                                            │      └──────┬───────┘        │
                                            │        ClusterIP Service    │
                                            │              │              │
                                            │         HTTPRoute           │
                                            │              │              │
                                            │          Gateway            │
                                            └──────────────┼─────────────────┘
                                                          │
                                            ┌──────────────▼─────────────────┐
                                            │AWS Application Load Balancer│
                                            └────────────────────────────────┘

02. ECR 이미지 관리

• ECR(Elastic Container Registry)은 AWS 완전 관리형 컨테이너 이미지 저장소

# ECR 리포지토리 생성
export APP_NAME="spring-demo"
export ECR_URI="${ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${APP_NAME}"

aws ecr create-repository \
  --repository-name $APP_NAME \
  --region $AWS_REGION \
  --image-tag-mutability IMMUTABLE    # 같은 태그 덮어쓰기 방지

Node Group 스케일링 / Add-on 업데이트 / 버전 업그레이드

01. Node Group 스케일링

• EKS Managed Node Group은 Auto Scaling Group 기반으로 동작
• 노드 수는 콘솔, CLI, eksctl 모두로 조정 가능

# 스케일 아웃 (노드 증가)
NODEGROUP_NAME=$(aws eks list-nodegroups \
  --cluster-name $CLUSTER_NAME \
  --region $AWS_REGION \
  --query 'nodegroups[0]' \
  --output text)

aws eks update-nodegroup-config \
  --cluster-name $CLUSTER_NAME \
  --nodegroup-name $NODEGROUP_NAME \
  --region $AWS_REGION \
  --scaling-config desiredSize=3,minSize=1,maxSize=5

# 노드 추가 확인 (watch 모드)
kubectl get nodes -w

# 스케일 인 (노드 감소)
aws eks update-nodegroup-config \
  --cluster-name $CLUSTER_NAME \
  --nodegroup-name $NODEGROUP_NAME \
  --region $AWS_REGION \
  --scaling-config desiredSize=2,minSize=1,maxSize=5

02. 노드 유지보수 — Cordon & Drain

• 노드 유지보수나 업그레이드 전, 해당 노드의 Pod를 안전하게 다른 노드로 이동

[ Cordon & Drain 동작 흐름 ]

  kubectl cordon node-A
        │
        ▼
  node-A에 NoSchedule Taint 추가
  (새 Pod 할당 차단)
        │
  kubectl drain node-A
        │
        ▼
  기존 Pod에 Eviction API 요청 (PDB 존중)
        │
  ┌─────┴───────────────────────────┐
  │                              │
  ▼                              ▼
DaemonSet Pod                 일반 Pod
(--ignore-daemonsets로 유지)   다른 노드에 재스케줄됨
        │
        ▼
  node-A 유지보수 / 업그레이드 진행
        │
  kubectl uncordon node-A
        ▼
  node-A 다시 스케줄 허용

IaC 왜 코드로 인프라를 관리하는가

01. IaC란

Infrastructure as Code

• 인프라를 콘솔 UI로 관리하는 것이 아니라 코드로 관리하는 방법론
• DevOps의 효율성과 클라우드 인프라 자동화 구축을 위해 반드시 필요한 기술

전통적 방식                          IaC 방식

개발자 A -> 콘솔 클릭 -> EC2 생성     개발자 A -> 코드 작성 -> apply -> EC2 생성
개발자 B -> 콘솔 클릭 -> 다른 EC2     개발자 B -> 동일 코드 -> apply -> 동일 EC2

결과: 환경 불일치                     결과: 환경 일관성 보장
재현: 불가능                          재현: Git clone 후 apply
추적: 개인 기억에 의존                추적: Git 커밋 이력
협업: 구두 전달                       협업: PR 리뷰

02. 핵심 개념

선언형 vs 명령형

• 명령형(Imperative) 은 "어떻게 만들지"를 순서대로 기술하는 방식
• 선언형(Declarative) 은 "무엇이 있어야 하는지"를 기술하는 방식

State 개념

• IaC 도구는 현재 실제 인프라 상태를 추적하기 위해 State를 사용
• State가 없으면 "현재 AWS에 어떤 VPC가 있는지, 없는지"를 도구가 알 방법이 없음

03. IaC 도구 생태계

• 현재 IaC 도구는 AWS 네이티브와 멀티클라우드 계열로 구분

AWS 네이티브                           멀티클라우드

CloudFormation   <- AWS 전용 표준       Terraform    <- 업계 표준 (HCL)
AWS SAM          <- 서버리스 특화       OpenTofu     <- Terraform 오픈소스 포크
AWS CDK          <- 코드로 CFN 생성     Pulumi       <- TS/Python/Go 코드형

CloudFormation 기초 — AWS 네이티브 IaC

01. 왜 CloudFormation인가

• AWS가 공식 제공하는 IaC 서비스
• YAML 또는 JSON 형식의 템플릿 파일을 작성하면 AWS가 해석해 스택(Stack) 단위로 리소스를 생성·관리
• CloudFormation의 가장 큰 장점은 별도 State 파일이 필요 없다는 것

02. 핵심 개념

템플릿 구조

• CloudFormation 템플릿은 최대 7개 최상위 섹션으로 구성

AWSTemplateFormatVersion: '2010-09-09'   # 버전 — 항상 이 값 사용
Description: '템플릿 설명'               # 스택 설명 (선택)

Metadata:     # 콘솔 UI 표시 설정 (선택)
Parameters:   # 배포 시 입력받는 변수 (선택) — 환경별로 달라지는 값을 여기서 받음
Mappings:     # 조건별 값 매핑 테이블 (선택) — 리전별 AMI ID 등
Conditions:   # 조건문 정의 (선택) — dev/prod 환경 분기
Resources:    # 필수 — 실제로 만들 AWS 리소스를 정의하는 곳
Outputs:      # 스택 출력값 (선택) — 다른 스택이나 콘솔에서 참조

03. YAML 프로퍼티 상세

기본 YAML

AWSTemplateFormatVersion: '2010-09-09'
Description: 'EKS Study - VPC Stack'

Parameters:
  EnvironmentName:
    Type: String
    Default: eks-study
    AllowedValues: [dev, staging, prod]   # 이 세 값만 허용
  VpcCidr:
    Type: String
    Default: '10.0.0.0/16'
    AllowedPattern: '^(\d{1,3}\.){3}\d{1,3}/\d{1,2}$'   # CIDR 형식만 허용

Resources:
  MyVPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VpcCidr            # Parameters에서 입력받은 값 참조
      EnableDnsHostnames: true           # EKS 필수 옵션
      EnableDnsSupport: true             # EKS 필수 옵션
      Tags:
        - Key: Name
          Value: !Sub '${EnvironmentName}-vpc'   # 변수 치환으로 이름 생성

Outputs:
  VpcId:
    Description: 'VPC ID'
    Value: !Ref MyVPC
    Export:
      Name: !Sub '${AWS::StackName}-VpcId'   # 다른 스택에서 !ImportValue로 참조

04. 주요 명령어

스택 관리

# 템플릿 문법 검증 (배포 전 필수 — 문법 오류를 배포 전에 잡을 수 있음)
aws cloudformation validate-template \
  --template-body file://vpc-stack.yaml

# 스택 생성
aws cloudformation create-stack \
  --stack-name eks-study-vpc \
  --template-body file://vpc-stack.yaml \
  --parameters ParameterKey=EnvironmentName,ParameterValue=eks-study \
  --capabilities CAPABILITY_IAM

# 생성 완료까지 대기 (완료되면 프롬프트가 돌아옴)
aws cloudformation wait stack-create-complete \
  --stack-name eks-study-vpc

# Output 값 조회 — VPC ID, Subnet ID 등 확인
aws cloudformation describe-stacks \
  --stack-name eks-study-vpc \
  --query 'Stacks[0].Outputs[*].{Key:OutputKey,Value:OutputValue}' \
  --output table

# 스택 삭제
aws cloudformation delete-stack --stack-name eks-study-vpc
aws cloudformation wait stack-delete-complete --stack-name eks-study-vpc

ChangeSet 명령어

# ChangeSet 생성 — 실제 변경 없이 무엇이 바뀔지만 계산
aws cloudformation create-change-set \
  --stack-name eks-study-vpc \
  --change-set-name my-changes \
  --change-set-type UPDATE \
  --template-body file://vpc-stack.yaml

# ChangeSet 완료 대기
aws cloudformation wait change-set-create-complete \
  --stack-name eks-study-vpc \
  --change-set-name my-changes

# 변경 내용 확인 — Replacement 컬럼 반드시 확인
aws cloudformation describe-change-set \
  --stack-name eks-study-vpc \
  --change-set-name my-changes \
  --query 'Changes[*].{Action:ResourceChange.Action,Type:ResourceChange.ResourceType,Replace:ResourceChange.Replacement}' \
  --output table

# 확인 후 실행
aws cloudformation execute-change-set \
  --stack-name eks-study-vpc \
  --change-set-name my-changes

AWS SAM — 서버리스 특화 IaC

01. 왜 SAM인가

• AWS SAM(Serverless Application Model)은 CloudFormation 위에서 동작하는 서버리스 전용 IaC 프레임워크

02. YAML 프로퍼티 상세

기본 YAML

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31   # SAM Transform 선언 필수
Description: 'EKS Health Check Lambda (SAM)'

Globals:
  Function:
    Runtime: python3.12
    Timeout: 30
    MemorySize: 128
    Environment:
      Variables:
        ENV: !Ref Environment
        CLUSTER_NAME: !Ref ClusterName

Parameters:
  Environment:
    Type: String
    Default: dev
    AllowedValues: [dev, staging, prod]
  ClusterName:
    Type: String
    Default: eks-study-cluster

Resources:
  EksHealthCheckFunction:
    Type: AWS::Serverless::Function
    Properties:
      FunctionName: !Sub 'eks-health-check-${Environment}'
      CodeUri: src/health_check/        # sam build 시 패키징할 소스 경로
      Handler: app.lambda_handler       # 파일명.함수명
      Policies:
        - AWSLambdaBasicExecutionRole   # 관리형 정책 (CloudWatch Logs 권한)
        - Statement:
            - Effect: Allow
              Action:
                - 'eks:DescribeCluster'
                - 'eks:ListNodegroups'
              Resource: !Sub 'arn:aws:eks:${AWS::Region}:${AWS::AccountId}:cluster/${ClusterName}'
      Events:
        HealthApi:
          Type: Api
          Properties:
            Path: /health
            Method: get
            RestApiId: !Ref HealthApi

  HealthApi:
    Type: AWS::Serverless::Api
    Properties:
      Name: !Sub 'eks-health-api-${Environment}'
      StageName: !Ref Environment
      Cors:
        AllowMethods: "'GET,OPTIONS'"
        AllowHeaders: "'Content-Type,Authorization'"
        AllowOrigin: "'*'"

Outputs:
  ApiEndpoint:
    Description: 'Health Check API 엔드포인트'
    Value: !Sub 'https://${HealthApi}.execute-api.${AWS::Region}.amazonaws.com/${Environment}/health'
  FunctionArn:
    Value: !GetAtt EksHealthCheckFunction.Arn

Terraform 아키텍처 & HCL 문법

01. 왜 Terraform인가

• HCL(HashiCorp Configuration Language)로 작성된 코드를 Provider 플러그인을 통해 실제 클라우드 API 호출로 변환하는 선언형 IaC 도구

Terraform 전체 아키텍처

+------------------------------------------------+
|              Terraform Core                    |
|  HCL 파싱 -> Dependency Graph -> Plan -> Apply  |
+--------------------+---------------------------+
                     | Plugin Protocol (gRPC)
          +----------+-----------------+
          |                            |
+---------v--------+       +-----------v-----------+
|   AWS Provider   |       |   기타 Provider        |
|   aws_vpc        |       |   (GCP, Azure, K8s..) |
|   aws_eks_*      |       +-----------------------+
|   aws_rds_*      |
+-----+------------+
      | AWS API 호출
+-----v------------+
|   실제 AWS 리소스  |
+------------------+

Terraform 실행 흐름

terraform init
    |
    v Provider 다운로드 (.terraform/) + Lock 파일 생성
terraform plan
    |
    v State + 실제 AWS 비교 -> diff 계산 (실제 변경 없음)
terraform apply
    |
    v 계획 적용 -> State 파일 업데이트 (terraform.tfstate)
terraform destroy
    |
    v State 기반으로 모든 리소스 삭제

02. HCL 기본 문법 실습

terraform & provider 블록

• terraform 블록은 Terraform CLI 자체와 사용할 Provider의 버전을 선언
• provider 블록은 해당 Provider의 동작 방식(리전, 인증, 공통 태그 등)을 설정

[ 학습자 PC ]
      │
      │  terraform init
      ▼
┌─────────────────────────────────────────────┐
│ terraform 블록 읽기                      │
│   └─ required_providers 확인             │
│      └─ registry.terraform.io에서 다운로드│
│            └─ .terraform/ 디렉토리에 저장  │
└─────────────────────────────────────────────┘
      │
      │  terraform apply
      ▼
┌──────────────────────────────────────────┐
│  provider 블록 읽기                    │
│    └─ 인증·리전 설정 적용               │
│         └─ resource 블록 실행          │
└──────────────────────────────────────────┘

버전 표기법

variable 블록

• variable은 외부에서 주입받는 입력값
• 같은 코드를 dev/staging/prod 환경에서 다른 값으로 재사용할 수 있게 해줌

값 주입 우선순위 (높은 순)
┌────────────────────────────────────────┐
│ 1. -var / -var-file CLI 옵션        │
│ 2. *.auto.tfvars 파일               │
│ 3. terraform.tfvars 파일            │
│ 4. TF_VAR_<이름> 환경 변수            │ 
│ 5. variable 블록의 default 값        │
└────────────────────────────────────────┘

HCL 타입 시스템

locals 블록

• locals는 모듈 내부에서만 사용하는 계산값
• variable과 달리 외부에서 주입할 수 없고, 반복되는 표현식이나 계산 결과를 한 곳에서 관리할 때 사용

03. HCL 블록 상세 실습

data 블록

• data 블록은 이미 존재하는 리소스의 정보를 읽기만 함
• 새로 생성하지 않으므로 destroy 대상이 아님

resource 블록          data 블록
    │                      │
    │  생성·관리            │  읽기만
    ▼                      ▼
┌────────┐            ┌────────┐
│CREATE │            │  READ  │
│ ESTROY│            │  ONLY  │
└────────┘            └────────┘
    │                      │
    ▼                      ▼
 .tfstate              .tfstate
 (등록됨)              (참조 캐시)

AWS에서 자주 쓰는 data 블록

• aws_caller_identity (계정 ID)
• aws_region (현재 리전)
• aws_ami (최신 AMI)
• aws_availability_zones (AZ 목록)

output 블록

• output은 apply 완료 후 콘솔에 노출되는 값
• 다른 모듈에서 호출 시 반환값 역할 수행

lifecycle 메타 인자

• lifecycle은 리소스의 생성·수정·삭제 동작을 변경

조건 표현식과 조건부 리소스 생성

• 삼항 연산자 조건 ? 참 : 거짓으로 환경에 따라 다른 값을 적용할 수 있음
• count = 조건 ? 1 : 0 패턴으로 리소스 자체의 생성 여부를 조건부로 결정

조건부 값                          조건부 리소스
───────────────                    ────────────────
instance_type =                    count = var.enable ? 1 : 0
  var.env == "prod"                  │
    ? "t3.large"                     ├─ true → 1개 생성
    : "t3.micro"                     └─ false → 0개 (생성 안 함)

04.Loop (반복문)

count — 정수 기반 반복

• count는 리소스를 정수 횟수만큼 반복 생성
• count.index는 0부터 시작하며 각 인덱스에 다른 값을 주입할 수 있음

count = 3
   │
   ├─ count.index = 0 ──→ 리소스 [0]
   ├─ count.index = 1 ──→ 리소스 [1]
   └─ count.index = 2 ──→ 리소스 [2]

참조: local_file.users[0], local_file.users[1] ...
state: local_file.users[0], local_file.users[1] ...

for_each — map/set 기반 반복

• for_each는 map 또는 set의 키 개수만큼 반복함
• 키 기반이므로 중간 항목이 빠져도 다른 리소스에 영향을 주지 않음

for_each = {
  dev     = "debug"
  staging = "info"
  prod    = "error"
}
   │
   ├─ each.key = "dev",     each.value = "debug"
   ├─ each.key = "staging", each.value = "info"
   └─ each.key = "prod",    each.value = "error"

참조: local_file.envs["dev"], local_file.envs["prod"]
state: local_file.envs["dev"], local_file.envs["prod"]   ← 키로 저장

for 표현식

• for 표현식은 list/map을 변환해 새 list/map을 만듦
• 데이터 가공이 필요할 때 사용

list → list      [for x in list : 가공(x)]
list → map       {for x in list : 키 => 값}
map  → list      [for k, v in map : 가공(k, v)]
map  → map       {for k, v in map : 키 => 값}
필터링            [for x in list : x if 조건]

dynamic 블록

• 리소스 안에 같은 구조의 nested block이 여러 개 필요할 때 사용

일반 블록 (정적)              dynamic 블록 (동적)
─────────────────             ────────────────────
ingress {                     dynamic "ingress" {
  from_port = 22                for_each = var.ports
}                               content {
ingress {                         from_port = ingress.value
  from_port = 80                }
}                             }
ingress {
  from_port = 443             → 입력 변수만 바꾸면
}                               규칙 개수가 자동 조절됨

05.Remote Backend 실습 (S3 + DynamoDB)

• State 파일을 어디에 저장할지 결정하는 설정
• 기본은 로컬 terraform.tfstate이지만, 팀 협업·CI/CD 환경에서는 반드시 원격 Backend가 필요

[ State Lock 동작 흐름 ]

학습자 A: terraform apply
   │
   ├─ 1) DynamoDB에 LockID 기록 (획득)
   ├─ 2) S3에서 State 읽기
   ├─ 3) AWS API 호출 → 리소스 생성
   ├─ 4) S3에 새 State 쓰기
   └─ 5) DynamoDB에서 LockID 제거 (해제)

학습자 B: terraform apply (A가 작업 중)
   │
   └─ Lock 시도 → DynamoDB에 이미 LockID 있음
       └─ 대기 또는 에러 (충돌 방지)

아키텍처 전체 흐름

┌──────────────────────────────────────────────────────────┐
│     학습자 PC (Windows + Git Bash / macOS + zsh)     │
│                                                     │
│  ~/terraform-lab/13-backend-bootstrap/              │
│   ├─ main.tf       ← 1단계: 로컬 State로 S3/DDB 생성   │
│   └─ tfstate       ← 처음엔 로컬에 저장                │
│                                                     │
│  ~/terraform-lab/14-backend-use/                    │
│   ├─ backend.tf    ← 2단계: 원격 Backend 선언         │
│   └─ main.tf       ← State는 S3로 저장됨              │
└──────────────────────┬───────────────────────────────────┘
                     │ AWS CLI 인증
                     │ (~/.aws/credentials)
                     ▼
┌──────────────────────────────────────────────────────────┐
│  AWS (ap-northeast-2)                               │
│                                                     │
│   ┌────────────────────┐      ┌──────────────────────┐  │
│   │  S3 Bucket       │      │  DynamoDB Table    │  │
│   │  tf-backend-     │      │  terraform-lock    │  │
│   │   <account-id>   │      │                    │  │
│   │                  │      │  PK: LockID (S)    │  │
│   │ - Versioning ON  │      │  Billing: On-Demand│  │
│   │ - Public Block ON│      │                    │  │
│   │ - Encryption ON  │      │                    │  │
│   └────────────────────┘      └──────────────────────┘  │
│           ▲                          ▲              │
│           │ State R/W                │ Lock 획득/해제│
│           └──────────┬─────────────────┘              │
│                     │                               │
│              Terraform CLI                          │
└──────────────────────────────────────────────────────────┘

06. tfvars 환경 분리 실습

• 동일한 인프라 코드를 dev / staging / prod 환경에서 다른 값으로 재사용하기 위한 패턴
• 변수 선언(variables.tf)과 변수 값(*.tfvars)을 분리해 관리

┌──────────────────────────────────────────────────┐
│  공통 코드 (모든 환경 공유)                     │
│   ├─ main.tf                                 │
│   ├─ variables.tf      ← 변수 선언만 (값 없음)  │
│   └─ outputs.tf                              │
│                                              │
│  환경별 값 (분리 보관)                          │
│   └─ environments/                           │
│       ├─ dev.tfvars     ← 개발 환경 값         │
│       ├─ staging.tfvars ← 스테이징 값          │
│       └─ prod.tfvars    ← 운영 환경 값         │
└──────────────────────────────────────────────────┘

배포 시:
terraform apply -var-file="environments/dev.tfvars"
terraform apply -var-file="environments/prod.tfvars"

07. terraform import

• 콘솔로 이미 만든 AWS 리소스를 Terraform State에 등록해서 코드로 관리하는 기능
• "콘솔로 만들었지만 이제 IaC로 전환하고 싶다" 상황의 핵심 도구

두 가지 import 방식

Terraform 모듈 & CI/CD

01. 왜 모듈인가

• 인프라 관리 규모가 커질수록 코드 중복, 유지보수 어려움, 종속성 파악 어려움이 발생
• 모듈(Module)은 이를 해결하는 재사용 가능한 인프라 코드의 집합

02. 핵심 개념

모듈 구조

기본 구조:

project/
 +-- main.tf       # 실제 리소스 정의
 +-- variables.tf  # 입력 변수 정의
 +-- outputs.tf    # 출력 값 정의
 +-- README.md     # 모듈의 사용 방법과 목적 설명

표준 구조 (루트 모듈 + 자식 모듈):

Terraform 프로젝트 (루트 모듈)
+-- main.tf
+-- provider.tf
+-- variables.tf
+-- outputs.tf
+-- modules/
    +-- vpc (자식 모듈 1)
    |   +-- main.tf
    |   +-- variables.tf
    |   +-- outputs.tf
    +-- ec2 (자식 모듈 2)
        +-- main.tf
        +-- variables.tf
        +-- outputs.tf

EKS 클러스터 구축 — 실무형 완전 구성

01. 전체 아키텍처 개요

• 실무에서 사용하는 방식과 동일하게 EKS 클러스터를 구성

전체 아키텍처

로컬 PC (VSCode)
    |  SSH (Termius / 터미널)
    v
tf-bastion (퍼블릭 서브넷, t3.micro)
    |  kubectl / aws cli (VPC 내부 통신)
    v
tf-cluster API Server (프라이빗, 외부 접근 차단)
    |
    +-- Node Group (프라이빗 서브넷 2a, 2c)
    |     t3.medium x 2 (AL2023)
    |
    +-- EBS CSI Driver  (IRSA: EBS 볼륨 관리)
    +-- ALB Controller  (IRSA: ALB 생성/관리)
    +-- Gateway API     (HTTPRoute -> ALB)

Terraform 모듈 구조

06.eks-terraform/
+-- main.tf              루트 모듈 (모듈 조합)
+-- variables.tf         루트 변수 선언
+-- outputs.tf           루트 출력값
+-- backend.tf           S3 Remote Backend
+-- terraform.tfvars     실습용 변수값
+-- modules/
|   +-- vpc/             VPC + 서브넷 + IGW + NAT GW + Route Table
|   |   +-- main.tf
|   |   +-- variables.tf
|   |   +-- outputs.tf
|   +-- bastion/         Bastion EC2 + 보안그룹
|   |   +-- main.tf
|   |   +-- variables.tf
|   |   +-- outputs.tf
|   +-- eks/             EKS 클러스터 + 노드그룹 + IRSA + 애드온
|   |   +-- main.tf
|   |   +-- variables.tf
|   |   +-- outputs.tf
|   +-- irsa-test/       IRSA 검증용 S3 버킷 + IAM Role
|       +-- main.tf
|       +-- outputs.tf
+-- manifests/           kubectl apply용 YAML 파일
    +-- 01-nginx-test.yaml     기본 Pod 동작 확인
    +-- 02-irsa-test.yaml      IRSA 권한 격리 검증
    +-- 03-ebs-test.yaml       EBS CSI Driver 검증
    +-- 04-gateway-test.yaml   Gateway API + ALB 검증

02. 핵심 개념

IRSA (IAM Roles for Service Accounts)

• Pod 단위로 최소 권한 IAM Role을 부여하는 패턴

IRSA 없는 경우 (위험)

노드 EC2 IAM Role에 모든 권한 부여
  -> 이 노드의 모든 Pod이 동일한 권한 사용
  -> Pod 탈취 시 노드 전체 권한 노출

---
IRSA 있는 경우 (안전)

각 Pod의 ServiceAccount에 Role ARN annotation
  -> 해당 Pod만 특정 AWS 서비스 접근 가능
  -> 다른 Pod은 권한 없음 (AccessDenied)

Terraform CI/CD — GitHub Actions + OIDC

01. 왜 CI/CD가 필요한가

• Terraform 코드를 로컬에서만 실행하면 팀 협업 시 여러 문제가 발생

로컬 실행의 문제점

팀원 A                        팀원 B
terraform apply               terraform apply
    |                             |
    v                             v
AWS 리소스 변경               AWS 리소스 변경 (충돌!)

누가 언제 무엇을 바꿨는지 추적 불가
plan 없이 apply -> 의도치 않은 변경
Access Key가 각 개발자 PC에 분산 -> 보안 위험

CI/CD 파이프라인으로 해결:

모든 변경은 Git PR을 통해서만 반영

팀원 A -> PR 오픈 -> GitHub Actions: plan 자동 실행
팀원 B -> 코드 리뷰 + plan 결과 확인
리뷰 승인 -> main 머지 -> GitHub Actions: apply 자동 실행
    |
    v
AWS 리소스 변경 (이력 = Git 커밋)

03. 워크플로우 YAML 상세

3-Job 파이프라인 구조

PR 오픈 시:
  Job 1: validate   fmt-check, init, validate
  Job 2: plan       plan 실행 -> artifact 저장 -> PR 코멘트

main 머지 시:
  Job 1: validate
  Job 2: plan
  Job 3: apply      저장된 plan artifact로 apply 실행

전체 워크플로우 YAML

# .github/workflows/terraform.yml
#
# 역할: Terraform CI/CD 파이프라인
#   - PR 오픈 시: validate -> plan -> PR 코멘트 게시
#   - main 머지 시: validate -> plan -> apply (production 승인 후)
#
name: Terraform CI/CD

on:
  pull_request:
    branches: [main]
    paths:
      - 'terraform/**'
      - '.github/workflows/terraform.yml'
  push:
    branches: [main]
    paths:
      - 'terraform/**'

env:
  TF_VERSION: '1.15.2'
  AWS_REGION: 'ap-northeast-2'
  TF_WORKING_DIR: './terraform/eks-infra'

permissions:
  id-token: write       # OIDC 토큰 발급 필수
  contents: read
  pull-requests: write  # PR 코멘트 작성

jobs:
  validate:
    name: Validate
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ${{ env.TF_WORKING_DIR }}

    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      - name: Terraform 설치
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - name: AWS OIDC 인증
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-terraform-role
          aws-region: ${{ env.AWS_REGION }}

      - name: Terraform Init
        run: terraform init

      - name: 포맷 검사
        run: terraform fmt -check -recursive

      - name: 문법 검증
        run: terraform validate

  plan:
    name: Plan
    needs: validate
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ${{ env.TF_WORKING_DIR }}

    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      - name: Terraform 설치
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - name: AWS OIDC 인증
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-terraform-role
          aws-region: ${{ env.AWS_REGION }}

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        id: plan
        run: |
          terraform plan -no-color -out=tfplan 2>&1 | tee plan-output.txt
          echo "exit_code=${PIPESTATUS[0]}" >> $GITHUB_OUTPUT

      - name: Plan 결과 PR 코멘트 게시
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const plan = fs.readFileSync('${{ env.TF_WORKING_DIR }}/plan-output.txt', 'utf8');
            const maxLength = 65000;
            const truncated = plan.length > maxLength
              ? plan.substring(0, maxLength) + '\n... (출력 생략)'
              : plan;

            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `## Terraform Plan 결과\n\`\`\`hcl\n${truncated}\n\`\`\``
            });

      - name: Plan Artifact 저장
        uses: actions/upload-artifact@v4
        with:
          name: tfplan
          path: ${{ env.TF_WORKING_DIR }}/tfplan
          retention-days: 1

  apply:
    name: Apply
    needs: plan
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    environment: production    # GitHub Environment 보호 규칙 적용
    defaults:
      run:
        working-directory: ${{ env.TF_WORKING_DIR }}

    steps:
      - name: 코드 체크아웃
        uses: actions/checkout@v4

      - name: Terraform 설치
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: ${{ env.TF_VERSION }}

      - name: AWS OIDC 인증
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-terraform-role
          aws-region: ${{ env.AWS_REGION }}

      - name: Terraform Init
        run: terraform init

      - name: Plan Artifact 다운로드
        uses: actions/download-artifact@v4
        with:
          name: tfplan
          path: ${{ env.TF_WORKING_DIR }}

      - name: Terraform Apply
        run: terraform apply -auto-approve tfplan

01. 왜 Kubernetes인가

Docker로 컨테이너 하나를 실행하는 것은 쉬움 하지만 실제 서비스를 운영하다 보면 금방 한계에 부딪힘

• Docker는 단일 호스트 위에서 컨테이너를 실행하는 도구
• Kubernetes(이하 K8s)는 여러 서버(노드)에 걸쳐 컨테이너를 자동으로 배포·관리·복구하는 컨테이너 오케스트레이션(orchestration) 플랫폼

오케스트레이션(Orchestration)

• 여러 컨테이너의 배포, 확장, 복구, 네트워킹을 자동으로 조율하는 것

클러스터(Cluster)

• 여러 서버(노드)를 하나의 시스템처럼 묶어 관리하는 단위
• K8s에서는 Control Plane 노드 1개 이상과 Worker 노드 여러 개가 하나의 클러스터를 이룸

02. Kubernetes 전체 아키텍처

Kubernetes 클러스터는 크게 두 역할로 나뉨

• Control Plane: 클러스터 전체를 관리하고 명령하는 두뇌
• Worker Node: 실제 컨테이너(Pod)가 실행되는 서버

┌──────────────────────────────────────────────────────────────┐
│                     Kubernetes Cluster                  │
│                                                         │
│      ┌───────────────────────────────────────────┐          │
│      │              Control Plane             │         │
│      │  ┌──────────────┐  ┌────────────────────┐ │         │
│      │  │ kube-       │  │       etcd       │ │         │
│      │  │ apiserver   │  │  (상태 저장소)     │ │         │
│      │  └──────────────┘  └────────────────────┘ │         │
│      │  ┌──────────────┐  ┌────────────────────┐ │         │
│      │  │ kube-       │  │ kube-controller- │ │         │
│      │  │ scheduler   │  │ manager          │ │         │
│      │  └──────────────┘  └────────────────────┘ │         │
│      └───────────────────────────────────────────┘         │
│         │                 │                │           │
│  ┌──────┴──────┐   ┌────────┴────┐   ┌────────┴────┐       │
│  │  Worker 1  │   │  Worker 2  │   │  Worker 3  │       │
│  │  kubelet   │   │  kubelet   │   │  kubelet   │       │
│  │  kube-proxy│   │  kube-proxy│   │  kube-proxy│       │
│  │  containerd│   │  containerd│   │  containerd│       │
│  │  [Pod][Pod]│   │  [Pod]     │   │  [Pod][Pod]│       │
│  └─────────────┘   └─────────────┘   └─────────────┘        │
│                                                         │
│  kubectl  <──── 사용자가 클러스터에 명령을 내리는 CLI 도구    │
└──────────────────────────────────────────────────────────────┘

03. Control Plane 컴포넌트

• Control Plane은 4개의 핵심 컴포넌트로 구성
• 각 컴포넌트는 kube-system 네임스페이스의 Static Pod로 실행

① kube-apiserver — 모든 통신의 단일 진입점

• kubectl, 내부 컴포넌트, 외부 시스템 등 모든 요청은 반드시 API Server를 거침
• REST API 형태로 동작하며 인증(Authentication)·인가(Authorization)를 처리
• etcd에 쓰고 읽는 유일한 컴포넌트 — 다른 컴포넌트는 API Server를 통해서만 etcd에 접근

② etcd — 클러스터의 유일한 상태 저장소

• 클러스터의 모든 상태 데이터를 저장하는 분산 Key-Value 스토어
• Pod 목록, 설정, 시크릿, 노드 상태 등 오브젝트 전체가 여기에 저장됨
• etcd가 손상되면 클러스터 전체가 동작 불능이 되므로 정기 백업이 필수

③ kube-scheduler — Pod 배치 결정자

• 새로 생성된 Pod를 어떤 Worker 노드에 배치할지 결정하는 컴포넌트
• 노드의 CPU·메모리 여유량, 레이블, 제약 조건(Taint/Affinity) 등을 종합 판단
• 결정만 하고 실제 실행은 kubelet이 담당

④ kube-controller-manager — 상태 유지 자동화

• Desired State(원하는 상태)와 Current State(현재 상태)를 지속적으로 비교하고 차이를 자동으로 맞춤
• 내부에 여러 Controller가 하나의 프로세스로 실행

04. Worker Node 컴포넌트

• Worker Node에는 3가지 컴포넌트가 항상 실행

① kubelet — 노드의 현장 관리자

• Control Plane으로부터 "이 Pod를 실행해라"는 명령을 받아 Container Runtime에 전달
• Pod의 실행 상태를 주기적으로 API Server에 보고
• 노드의 헬스체크(Liveness/Readiness Probe) 실행도 담당

② Container Runtime — 컨테이너 실행 엔진

• 컨테이너 이미지를 레지스트리에서 pull하고 컨테이너를 실제로 실행
• K8s는 CRI(Container Runtime Interface) 규격을 지원하는 런타임만 사용 가능

③ kube-proxy — 네트워크 규칙 관리자

• 각 노드에서 iptables(또는 ipvs) 규칙을 설정·관리
• Service 오브젝트가 생성되면 해당 Service로 오는 트래픽이 올바른 Pod로 전달되도록 규칙을 업데이트

05. Kubernetes 핵심 오브젝트 개요

• Kubernetes에서 모든 것은 오브젝트(Object) 로 표현

선언형(Declarative) vs 명령형(Imperative)

• 명령형: "컨테이너를 실행해라" (docker run처럼 직접 동작 지시)
• 선언형: "nginx Pod가 3개 있는 상태가 되기를 원한다"고 선언만 함 (K8s가 사용하는 방식)

핵심 오브젝트

Pod             → 컨테이너를 담는 최소 실행 단위
Deployment      → Pod를 N개 유지하고 롤링 업데이트를 관리
StatefulSet     → 순서와 고정 ID가 필요한 Pod 집합 (DB 등)
DaemonSet       → 모든 노드에 1개씩 배치되는 Pod (모니터링 에이전트 등)
Service         → Pod에 고정 주소(ClusterIP)와 DNS를 부여하는 로드밸런서
ConfigMap       → 비민감 설정 값을 컨테이너에 주입
Secret          → 패스워드·토큰 등 민감 정보를 컨테이너에 주입
Namespace       → 클러스터를 논리적으로 분리하는 경계 (dev / prod 등)
PersistentVolume→ 컨테이너가 삭제되어도 유지되는 영속 스토리지

06. kubectl 기본 사용법

• kubectl은 Kubernetes API Server와 통신하는 CLI 도구

사용자
  ↓ kubectl 명령어 입력
kubectl (CLI 도구)
  ↓ HTTPS로 REST API 요청
kube-apiserver
  ↓
etcd / Scheduler / Controller

07. kubectl apply 실행 시 내부 흐름

전체 흐름 다이어그램

• kubectl apply -f deployment.yaml 한 줄을 실행했을 때 내부에서 일어나는 일

① kubectl apply -f deployment.yaml
        │ HTTPS POST 요청
        ↓
② kube-apiserver
        │ 인증 → 인가 → YAML 유효성 검사
        │ etcd에 Deployment 오브젝트 저장
        ↓
③ kube-controller-manager (Deployment Controller)
        │ "Deployment 생성됨" 이벤트 감지
        │ ReplicaSet 생성 → etcd 저장
        ↓
④ kube-controller-manager (ReplicaSet Controller)
        │ "replicas: 3, 현재 0개" 감지
        │ Pod 3개 생성 요청 → etcd 저장
        ↓
⑤ kube-scheduler
        │ "nodeName 없는 Pod 3개" 감지
        │ 각 Pod를 어느 노드에 배치할지 결정
        │ Pod.spec.nodeName 업데이트 → etcd 저장
        ↓
⑥ 해당 Worker 노드의 kubelet
        │ "내 노드에 배치된 Pod 있음" 감지
        │ containerd에 이미지 pull + 컨테이너 실행 요청
        ↓
⑦ containerd
        │ 이미지 다운로드 → 컨테이너 실행
        ↓
⑧ kubelet → API Server에 "Pod Running" 상태 보고
        ↓
⑨ kubectl get pods → STATUS: Running 확인

클러스터 구축

CNI(Container Network Interface)

• Pod 간 통신을 가능하게 하는 네트워크 플러그인
• CNI 없이는 Pod가 서로 통신할 수 없고 CoreDNS도 동작하지 않음

Kubernetes Pod

01. Pod란

• Pod는 Kubernetes에서 배포할 수 있는 가장 작은 단위
• Kubernetes 환경에서는 컨테이너를 직접 배포하지 않고, Pod라는 껍데기 안에 컨테이너를 넣어서 배포

[ Docker 단독 환경 ]                 [ Kubernetes 환경 ]

    컨테이너 (최소 단위)                  Pod (최소 단위)
  ┌──────────────────┐                  ┌──────────────────────┐
  │   nginx:1.27    │                 │  ┌────────────────┐  │
  │  IP: 172.17.0.2 │     →           │  │   nginx:1.27  │  │
  │   :80           │                 │  │   :80         │  │
  └──────────────────┘                  │  └────────────────┘ │
                                      │ Pod IP: 10.244.1.5 │
                                      └──────────────────────┘
                                              Node

핵심 특성 4가지

네임스페이스(Linux Namespace) : Linux 커널이 제공하는 격리 기술

02. Docker vs Kubernetes Pod 비교

동작 흐름 비교

[ Docker 환경에서 컨테이너 실행 ]

사용자
  │
  │ docker run nginx:1.27
  ▼
docker daemon
  │
  ▼
컨테이너 시작 → 죽으면 그냥 죽음 (재시작 없음)

---

[ Kubernetes 환경에서 Pod 생성 ]

사용자
  │
  │ kubectl apply -f pod.yaml
  ▼
kube-apiserver (요청 접수)
  │
  ▼
etcd (원하는 상태 저장)
  │
  ▼
kube-scheduler (어느 노드에 배치할지 결정)
  │
  ▼
kubelet (해당 노드에서 실행)
  │
  ▼
containerd (실제 컨테이너 생성)
  │
  ▼
Pod 시작 → 죽어도 워크로드 리소스가 자동 복구

03. Pod 내부 구조

• 사용자가 정의한 앱 컨테이너 외에도 보이지 않는 pause 컨테이너가 함께 존재

                    Node (Ubuntu Server)
┌──────────────────────────────────────────────────────────┐
│                                                     │
│   Pod: my-app-pod                                   │
│  ┌────────────────────────────────────────────────────┐  │
│  │  Pod IP: 10.244.1.5  (Pod 내부 컨테이너가 공유)   │  │
│  │                                                │  │
│  │  ┌─────────────────┐                             │  │
│  │  │pause container │ ← 네트워크 네임스페이스 보유   │  │
│  │  │ (보이지 않음)   │                             │  │
│  │  └─────────────────┘                             │  │
│  │                                                │  │
│  │  ┌─────────────────┐    ┌────────────────┐        │  │
│  │  │  app container │    │ Volume (공유) │        │  │
│  │  │  Spring Boot   │    │  /data       │         │  │
│  │  │  :8080         │    │              │         │  │
│  │  └─────────────────┘    └────────────────┘         │  │
│  └─────────────────────────────────────────────────────┘  │
│                                                      │
└───────────────────────────────────────────────────────────┘

04. Pod YAML 기본 구조

# my-pod.yaml
apiVersion: v1               # API 버전
kind: Pod                    # 리소스 종류
metadata:                    # 식별 정보
  name: my-app-pod
  labels:
    app: my-app
spec:                        # 원하는 상태(Desired State)
  containers:
  - name: app
    image: nginx:1.27
    ports:
    - containerPort: 80

apiVersion 상세

04. 멀티 컨테이너 패턴

• 대부분의 Pod는 컨테이너 1개로 구성하지만, 명확한 이유가 있을 때 여러 컨테이너를 한 Pod에 넣음

05. 주요 kubectl 명령어

# Pod 생성
kubectl apply -f my-pod.yaml

# Pod 목록
kubectl get pods
kubectl get pods -o wide                # IP, 노드 포함
kubectl get pods --show-labels          # 라벨 포함
kubectl get pods -A                     # 모든 네임스페이스

# Pod 상세 정보
kubectl describe pod my-app-pod

# Pod 로그
kubectl logs my-app-pod
kubectl logs my-app-pod --previous      # 재시작 직전 로그
kubectl logs my-app-pod -c app          # 멀티 컨테이너에서 특정 컨테이너

# Pod 진입
kubectl exec -it my-app-pod -- /bin/bash

# Pod 삭제
kubectl delete pod my-app-pod

# 라벨 기반 검색
kubectl get pods -l app=spring-app
kubectl get pods -l 'tier in (backend, frontend)'

# YAML 초안 빠르게 생성
kubectl run my-app-pod --image=nginx:1.27 --dry-run=client -o yaml > my-pod.yaml

# 실시간 상태 감시
kubectl get pods -w

Kubernetes Pod 라이프사이클

Probe

• Kubernetes가 컨테이너의 건강 상태를 주기적으로 검사하는 메커니즘

Kubernetes Service

01. Service란

• 고정된 가상 IP(ClusterIP) 와 DNS 이름 을 제공하고, 그 뒤에 있는 Pod들로 트래픽을 자동 분산

[ Service 없이 직접 Pod 접근 — 문제 ]

클라이언트
   │  http://10.244.1.5:8080
   ▼
Pod A (10.244.1.5)  ← 재시작 → IP 변경 (10.244.1.9)
                                 │
                             연결 끊김!

---
[ Service 사용 — 해결 ]

클라이언트
   │  http://my-svc:80   (고정 주소)
   ▼
Service (ClusterIP: 10.96.100.1, 영구 고정)
   │
   ├──► Pod A (10.244.1.5)  ← 재시작되어도
   ├──► Pod B (10.244.1.6)  ← IP가 바뀌어도
   └──► Pod C (10.244.1.7)  ← Service가 알아서 연결

Service가 제공하는 3가지 기능

• 서비스 디스커버리(Service Discovery): Pod의 IP가 변해도 Service 이름으로 접근 가능
• 로드 밸런싱(Load Balancing): 여러 Pod로 트래픽 자동 분산
• 외부 노출(External Exposure): NodePort, LoadBalancer 타입으로 클러스터 외부에서 접근 가능

02. Selector와 Label 연결 메커니즘

• 어떤 Pod로 트래픽을 보낼지 어떻게 알까? Label Selector 라는 메커니즘을 사용

03. ClusterIP (기본 타입)

• Service의 기본 타입
• 클러스터 내부에서만 접근 가능한 가상 IP를 할당받음

┌─────────────────── Kubernetes 클러스터 ───────────────────┐
│                                                      │
│   Frontend Pod ──► Service (ClusterIP: 10.96.100.1)  │
│                       │                              │
│                       ├──► Backend Pod 1             │
│                       ├──► Backend Pod 2             │
│                       └──► Backend Pod 3             │
│                                                      │
│   ※ 외부에서는 10.96.100.1 직접 접근 불가               │
└───────────────────────────────────────────────────────────┘

YAML 예시

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: ClusterIP                # 생략 시 기본값
  selector:
    app: my-app
  ports:
  - port: 80                     # Service 포트 (클라이언트가 접근하는 포트)
    targetPort: 8080             # Pod의 실제 포트
    protocol: TCP                # TCP / UDP / SCTP

04. NodePort

• NodePort는 클러스터 외부에서 접근 가능하게 만드는 가장 단순한 타입
• 모든 노드의 특정 포트를 열어두고, 그 포트로 들어온 트래픽을 Service로 전달

외부 브라우저
    │  http://192.168.56.11:30080
    │       또는
    │  http://192.168.56.12:30080
    ▼
┌─── 모든 노드의 30080 포트 동일하게 열림 ──────┐
│                                          │
│   Node 1 (192.168.56.11) :30080          │
│        │                                 │
│        ▼                                 │
│   Service (ClusterIP) :80                │
│        │                                 │
│        └──► Pod (위치는 어느 노드든 가능)    │
│                                          │
└──────────────────────────────────────────────┘

YAML 예시

apiVersion: v1
kind: Service
metadata:
  name: my-app-nodeport
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - port: 80                     # Service 포트 (클러스터 내부)
    targetPort: 8080             # Pod 포트
    nodePort: 30080              # 노드에서 열리는 포트

05. LoadBalancer

• LoadBalancer는 클라우드 환경(AWS, GCP, Azure)에서 사용하는 타입
• 클라우드의 로드 밸런서(AWS의 NLB/ALB 등)를 자동으로 프로비저닝하여 외부에서 접근 가능한 IP/DNS를 제공

인터넷
   │
   ▼
AWS NLB (자동 프로비저닝)
   │  EXTERNAL-IP: a1b2c3.ap-northeast-2.elb.amazonaws.com
   │  Port: 80
   ▼
NodePort (내부 자동 생성)
   │
   ▼
ClusterIP
   │
   ▼
  Pod

YAML 예시 (AWS EKS)

apiVersion: v1
kind: Service
metadata:
  name: my-app-lb
  annotations:
    # AWS Load Balancer Controller 어노테이션
    service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

06. ExternalName

• ExternalName은 클러스터 내부에서 외부 서비스를 마치 내부 Service인 것처럼 사용할 수 있게 해주는 타입 (DNS CNAME 레코드로 매핑)

앱 코드:
  jdbc:mysql://external-db:3306/orderdb
            ↓ (클러스터 DNS가 CNAME 변환)
  jdbc:mysql://my-rds.xxxxxx.ap-northeast-2.rds.amazonaws.com:3306/orderdb

YAML 예시

apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  type: ExternalName
  externalName: my-rds.xxxxxx.ap-northeast-2.rds.amazonaws.com

Kubernetes Ingress

01. Ingress란

[ Ingress 사용 시 ]

인터넷
   │  http://example.com/...
   ▼
Ingress (1개 진입점)
   │
   ├── /web      → frontend Service
   ├── /api      → api Service
   ├── /admin    → admin Service
   ├── api.example.com → api Service
   └── shop.example.com → shop Service

장점:
- 단일 진입점 (LB 1개로 충분, 비용 절감)
- 도메인 기반 라우팅 (host)
- 경로 기반 라우팅 (path)
- HTTPS 종료 (TLS 인증서 통합 관리)
- HTTP 헤더 조작, 리다이렉트, rewrite

02. Ingress의 핵심 — Controller가 필요

• Ingress 리소스 자체는 단순한 "규칙 정의"
• 실제 트래픽을 처리하려면 Ingress Controller 라는 별도의 프로그램이 필요

[ Ingress의 두 구성 요소 ]

Ingress 리소스 (YAML)              Ingress Controller (Pod)
       ↓                                  ↓
"규칙 선언"                         "실제 트래픽 처리"
"/web → web-svc"                    NGINX, HAProxy, Envoy 등으로 동작
"/api → api-svc"                    Ingress 리소스를 읽고 자기 설정 변경

규칙만 있다고 동작하지 않음.
Controller가 그 규칙대로 트래픽을 처리해야 비로소 동작.

주요 Ingress Controller 종류

03. Ingress 동작 흐름

[ Ingress 동작 흐름 — 6단계 ]

1. 사용자: curl http://demo.local/web
              │
              ▼
2. DNS: demo.local → 노드 IP (192.168.56.11) 변환
   (호스트 PC의 /etc/hosts 또는 실제 DNS 서버)
              │
              ▼
3. 노드 IP의 NodePort (예: 31234) 도달
   (ingress-nginx-controller Service의 NodePort)
              │
              ▼
4. ingress-nginx-controller Pod (NGINX)
   Ingress 리소스의 규칙 평가:
   - host: demo.local → 매칭
   - path: /web (Prefix) → 매칭
              │
              ▼
5. 백엔드 Service로 트래픽 전달 (web-svc)
              │
              ▼
6. Service의 Endpoints 중 한 Pod로 라우팅 (web-app Pod)
              │
              ▼
   응답 반환 → 사용자

04. Ingress YAML 기본 구조

apiVersion: networking.k8s.io/v1     # Ingress의 API 그룹
kind: Ingress
metadata:
  name: demo-ingress
  namespace: lab-ingress
spec:
  ingressClassName: nginx            # 어떤 Controller가 처리할지
  rules:
  - host: demo.local                 # 도메인 (선택)
    http:
      paths:
      - path: /web                   # 경로
        pathType: Prefix             # 매칭 방식
        backend:
          service:
            name: web-svc            # 대상 Service
            port:
              number: 80             # Service 포트

Kubernetes 워크로드 리소스 & ReplicaSet

01. 왜 Pod를 직접 관리하면 안 되는가

• 실제 운영에서는 Pod를 직접 만들지 않음. (직접 생성한 Pod는 죽으면 다시 살아나지 않음)

02. 워크로드 리소스 종류

• Kubernetes는 사용 목적에 따라 다양한 워크로드 리소스를 제공

Kubernetes 워크로드 리소스
│
├── Deployment      ← 무상태(Stateless) 앱 배포 (가장 많이 사용)
│      └── ReplicaSet (Deployment가 자동 관리)
│
├── StatefulSet     ← 유상태(Stateful) 앱 배포 (DB 등)
│
├── DaemonSet       ← 모든 노드에 1개씩 배포 (로그, 모니터링)
│
├── Job             ← 한 번 실행 후 완료 (배치 작업)
│
└── CronJob         ← 주기적 실행 (스케줄 배치)

03. ReplicaSet 개념

• 항상 지정한 수의 Pod 복제본(replica)을 유지하는 가장 기본적인 워크로드 리소스

Pod 복제 vs 재시작의 차이

04. ReplicaSet YAML 프로퍼티 상세

apiVersion: apps/v1                  #  Pod와 다름! apps/v1
kind: ReplicaSet
metadata:
  name: my-app-rs
  labels:
    app: my-app
spec:
  replicas: 3                        # 유지할 Pod 개수
  selector:
    matchLabels:
      app: my-app                    # 이 라벨의 Pod를 관리
  template:                          # 새 Pod를 만들 때 사용할 설계도
    metadata:
      labels:
        app: my-app                  #  selector와 반드시 일치
    spec:
      containers:
      - name: app
        image: nginx:1.27
        ports:
        - containerPort: 80

Kubernetes Deployment

01. Deployment란

• Deployment는 Kubernetes에서 가장 많이 사용하는 워크로드 리소스
• 무상태(Stateless) 앱 배포에 사용하며, 내부적으로 ReplicaSet을 자동 관리

Deployment가 추가로 제공하는 기능

02. Deployment 계층 구조 상세

• Deployment는 직접 Pod를 만들지 않고, ReplicaSet을 통해 간접적으로 Pod를 관리
• 3계층 구조가 롤링 업데이트의 기반

03. Deployment YAML 프로퍼티 상세

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  annotations:
    kubernetes.io/change-cause: "nginx 1.28 보안 패치 CVE-2025-xxxx"
spec:
  replicas: 4
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 300
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0           # 무중단 배포
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        version: "1.28"
    spec:
      containers:
      - name: app
        image: nginx:1.28
        ports:
        - containerPort: 80
          name: http
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "300m"
            memory: "256Mi"
        readinessProbe:
          httpGet:
            path: /
            port: http
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: http
          initialDelaySeconds: 10
          periodSeconds: 10
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "5"]
      terminationGracePeriodSeconds: 30

04. 롤링 업데이트 동작 원리

• 롤링 업데이트는 새 버전으로 한 번에 모두 바꾸지 않고, 하나씩 또는 일부씩 점진적으로 교체하는 방식

흐름 (replicas=4, maxSurge=1, maxUnavailable=0)

초기 상태: v1 Pod × 4
[v1] [v1] [v1] [v1]                      replicas=4 (정상)

──────────────────────────────────────────────────
Step 1: v2 Pod 1개 추가 (maxSurge=1로 +1 허용)
[v1] [v1] [v1] [v1] [v2]                  총 5개 (4+1)
                          ↑ Ready 대기

──────────────────────────────────────────────────
Step 2: v2 Ready 확인 → v1 Pod 1개 제거
[v1] [v1] [v1] [v2]                       총 4개

──────────────────────────────────────────────────
Step 3: v2 Pod 1개 추가
[v1] [v1] [v1] [v2] [v2]                  총 5개

──────────────────────────────────────────────────
Step 4: v2 Ready → v1 1개 제거
[v1] [v1] [v2] [v2]                       총 4개

... 계속 반복 ...

──────────────────────────────────────────────────
완료: v2 × 4
[v2] [v2] [v2] [v2]                       업데이트 완료

Kubernetes StatefulSet

01. StatefulSet이란

• Deployment가 만드는 Pod는 모두 교체 가능한 일회용
• 이름도 랜덤(my-app-5d4b7f-xk9p2), 어느 Pod에 트래픽이 가도 같은 결과를 반환하므로 IP가 바뀌어도 문제 없음

Deployment vs StatefulSet 비교

02. StatefulSet YAML 프로퍼티 상세

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql-headless"        #  Headless Service 이름 필수
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.4
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "mypassword"
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:                #  Pod마다 PVC 자동 생성
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

03. 실무 패턴 — MySQL Primary-Replica

• MySQL을 StatefulSet으로 배포할 때의 패턴
• Init Container로 Pod 순서에 따라 Primary/Replica를 자동 설정

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql-headless"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      initContainers:
      - name: init-mysql
        image: mysql:8.4
        command:
        - bash
        - -c
        - |
          # Pod 이름 끝의 숫자 추출
          [[ $HOSTNAME =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}

          # 0번 Pod는 Primary, 나머지는 Replica
          if [[ $ordinal -eq 0 ]]; then
            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi
        volumeMounts:
        - name: conf
          mountPath: /mnt/conf.d
        - name: config-map
          mountPath: /mnt/config-map
      containers:
      - name: mysql
        image: mysql:8.4
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
        - name: conf
          mountPath: /etc/mysql/conf.d
        livenessProbe:
          exec:
            command: ["mysqladmin", "ping", "-uroot", "-p$MYSQL_ROOT_PASSWORD"]
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command: ["mysql", "-uroot", "-p$MYSQL_ROOT_PASSWORD", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
      volumes:
      - name: conf
        emptyDir: {}
      - name: config-map
        configMap:
          name: mysql-config
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: "standard"
      resources:
        requests:
          storage: 20Gi

DaemonSet · Job · CronJob

01. DaemonSet이란

• DaemonSet은 클러스터의 모든 노드에 Pod를 1개씩 자동 배포하는 워크로드 리소스
• 새 노드가 추가되면 자동 생성, 노드가 제거되면 자동 삭제

02. DaemonSet YAML 프로퍼티

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: log-agent
spec:
  selector:
    matchLabels:
      app: log-agent
  template:
    metadata:
      labels:
        app: log-agent
    spec:
      containers:
      - name: fluent-bit
        image: fluent/fluent-bit:3.2
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:                  #  노드의 실제 디렉토리 마운트
          path: /var/log

03. Job이란

• Job은 정해진 작업을 완료할 때까지 실행 하는 워크로드 리소스
• 작업이 끝나면 Pod는 Completed 상태로 유지 (자동 삭제 X)

04. Job YAML 프로퍼티 상세

apiVersion: batch/v1                #  Pod와 다름! batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  template:                          # Pod 템플릿 (selector는 자동)
    spec:
      restartPolicy: OnFailure       #  Job은 Always 불가
      containers:
      - name: migration
        image: my-migration:1.0
        command: ["./migrate", "--up"]

05. CronJob이란

• CronJob은 주기적으로 Job을 자동 실행 하는 워크로드 리소스
• Linux의 cron과 동일한 문법을 사용

06. CronJob YAML 프로퍼티

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-backup
spec:
  schedule: "0 2 * * *"            #  cron 표현식
  timeZone: "Asia/Seoul"            # v1.27+ Stable
  jobTemplate:                      # 실행할 Job 정의
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: backup
            image: my-backup:1.0
            command: ["/backup.sh"]

ConfigMap

01. 왜 ConfigMap이 필요한가

• ConfigMap은 설정 데이터를 이미지에서 분리하여 Kubernetes 오브젝트로 관리하는 방법

ConfigMap                        Pod
┌───────────────────────────┐    ┌──────────────────────┐
│ APP_ENV: development    │───>│ 컨테이너             │
│ DB_HOST: mysql-svc      │    │ (설정값이 주입됨)     │
│ LOG_LEVEL: DEBUG        │    └──────────────────────┘
└───────────────────────────┘

02. ConfigMap 개념

• key-value 형태로 설정 데이터를 저장하는 오브젝트
• 텍스트 데이터(문자열, 설정 파일 내용 등) 저장 가능
• Pod에서 환경변수 또는 파일(볼륨) 형태로 주입 가능
• 데이터는 암호화되지 않음 → 민감 정보 저장 금지

03. ConfigMap 생성 방법

방법 3 — YAML 파일로 생성 (권장)

# configmap-app.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  APP_ENV: "development"
  DB_HOST: "mysql-svc"
  DB_PORT: "3306"
  LOG_LEVEL: "DEBUG"

04. Pod에서 ConfigMap 사용하는 방법

ConfigMap
┌──────────────────┐
│ APP_ENV=dev     │
│ DB_HOST=mysql   │
│ LOG_LEVEL=DEBUG │
└────────┬─────────┘
        │
    ┌────┴──────────────────────┐─────────────────────────┐
    ▼                         ▼                       ▼
방법 1: envFrom       방법 2: env.valueFrom    방법 3: 볼륨 마운트
(전체 key → 환경변수)  (특정 key → 환경변수)      (key → 파일)

3가지 방법 비교

Secret

01. 왜 Secret이 필요한가

• ConfigMap은 데이터가 평문으로 저장되어 민감 정보 저장에 부적합
• Secret은 ConfigMap과 구조가 거의 동일하지만 민감 정보 처리에 특화된 오브젝트

02. Secret 개념

• 민감 데이터를 Base64 인코딩하여 저장하는 오브젝트
• ConfigMap과 사용 방법이 거의 동일 (envFrom, env.valueFrom, 볼륨 마운트)
• Pod에서 참조할 때 자동으로 Base64 디코딩되어 원본값으로 주입됨
• 볼륨으로 마운트 시 tmpfs(메모리 기반) 에 저장 → 디스크에 기록되지 않음

03. Secret 생성 방법

• 방법 1 — kubectl 명령어 (값 자동 인코딩)
  • kubectl create secret 명령어는 Base64 인코딩을 자동으로 처리
• 방법 2 — YAML + data 필드 (Base64 직접 입력)
• 방법 3 — YAML + stringData 필드 (평문 입력)
  • apply 시 자동으로 data 필드(Base64)로 변환·저장

04. Pod에서 Secret 사용하는 방법

• ConfigMap과 동일한 구조
• configMapRef → secretRef, configMapKeyRef → secretKeyRef 로 변경

ConfigMap vs Secret 비교

볼륨 기초 — emptyDir · projected · configMap 볼륨

01. 왜 볼륨이 필요한가

볼륨 없음
컨테이너 실행 → /data/log.txt 생성
       │
       ▼ 컨테이너 재시작
/data/log.txt 없어짐 (데이터 소실)

볼륨 있음
컨테이너 실행 → /data/log.txt 생성 (볼륨에 저장)
       │
       ▼ 컨테이너 재시작
/data/log.txt 유지 (볼륨에서 읽어옴)

02. emptyDir — 임시 공유 볼륨

• Pod가 노드에 할당될 때 빈 디렉토리로 생성되는 볼륨
• 같은 Pod 안의 여러 컨테이너가 공유 가능. Pod 삭제 시 데이터도 삭제

# pod-emptydir.yaml
apiVersion: v1
kind: Pod
metadata:
  name: emptydir-pod
  namespace: lab-volume
spec:
  containers:
  - name: writer
    image: busybox:1.36
    command:
    - sh
    - -c
    - |
      while true; do
        echo "$(date) - Hello from writer" >> /shared/log.txt
        sleep 5
      done
    volumeMounts:
    - name: shared-data
      mountPath: /shared              # 쓰기 경로

  - name: reader
    image: busybox:1.36
    command: ["sh", "-c", "tail -f /data/log.txt"]
    volumeMounts:
    - name: shared-data
      mountPath: /data                # 같은 볼륨, 다른 경로로 마운트

  volumes:
  - name: shared-data
    emptyDir: {}                      # 기본 emptyDir

03. configMap / secret 볼륨

volumes:
- name: config-vol
  configMap:
    name: app-config
    defaultMode: 0644         # 파일 권한

- name: secret-vol
  secret:
    secretName: app-secret
    defaultMode: 0400         # Secret은 0400 권장 (owner 읽기만 가능)

04. projected 볼륨 — 여러 소스를 하나의 경로로

• ConfigMap, Secret, Downward API, ServiceAccountToken을 하나의 디렉토리에 합쳐서 마운트
• 별개의 volumeMounts를 여러 개 쓰는 대신 하나로 통합 가능

volumes:
- name: all-in-one
  projected:
    sources:
    - configMap:
        name: app-config
        items:
        - key: APP_ENV
          path: app-env           # /etc/app/app-env 파일 생성
    - secret:
        name: app-secret
        items:
        - key: DB_PASSWORD
          path: db-password       # /etc/app/db-password 파일 생성
        mode: 0400                # Secret 파일만 0400 적용
    - downwardAPI:
        items:
        - path: pod-name
          fieldRef:
            fieldPath: metadata.name

PersistentVolume / PVC — 영구 데이터 저장

01. 영구 볼륨이 필요한 이유

• emptyDir은 Pod 삭제 시 데이터가 사라짐
• DB나 파일 업로드 서버처럼 Pod가 교체되어도 데이터가 남아야 하는 경우 PersistentVolume을 사용

emptyDir (임시)
Pod 삭제 → 데이터 소실

PersistentVolume (영구)
Pod 삭제 → 외부 스토리지에 데이터 보존
새 Pod 생성 → 동일 데이터 다시 마운트

PV / PVC / StorageClass 역할

관리자      PersistentVolume (PV)      실제 스토리지 자원 준비
개발자      PersistentVolumeClaim(PVC) 스토리지 요청서 작성
Kubernetes  조건이 맞는 PV와 PVC를 자동 바인딩
Pod         PVC를 참조하여 스토리지 사용

02. 접근 모드 (AccessMode)

볼륨이 어떻게 마운트될 수 있는지 정의

03. 반환 정책 (Reclaim Policy)

PVC가 삭제된 후 PV를 어떻게 처리할지 결정

04. PV / PVC 생성 및 사용

정적 프로비저닝 (수동 PV 생성)

# pv-hostpath.yaml (실습용 — 실제 운영에서는 EBS, NFS 등 사용)
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mysql-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/mysql-data
    type: DirectoryOrCreate         # 없으면 디렉토리 자동 생성

# pvc-mysql.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
  namespace: lab-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi
  storageClassName: ""              # 빈 문자열: 정적 PV 바인딩 강제

# Pod에서 PVC 사용
spec:
  volumes:
  - name: mysql-storage
    persistentVolumeClaim:
      claimName: mysql-pvc          # PVC 이름 참조
  containers:
  - name: mysql
    volumeMounts:
    - name: mysql-storage
      mountPath: /var/lib/mysql

StorageClass — 동적 프로비저닝

01. StorageClass가 왜 필요한가

• 정적 프로비저닝에서는 관리자가 PV를 미리 만들어야 함
• StorageClass를 사용하면 PVC 생성 시 PV가 자동으로 만들어짐 — 동적 프로비저닝

정적 프로비저닝의 문제

관리자가 PV를 미리 생성 → 용량이 딱 맞지 않아도 PV 하나 전체 배정 (낭비)
개발자가 PVC 요청할 때마다 관리자가 대응해야 함

---
동적 프로비저닝 흐름

개발자: PVC 생성 (storageClassName: gp3)
              │
              ▼
StorageClass(gp3) → 프로비저너에게 PV 생성 요청
              │
              ▼
CSI 드라이버 → 외부 스토리지(EBS 등)에 볼륨 자동 생성
              │
              ▼
PV 자동 생성 + PVC와 자동 바인딩

02. StorageClass 주요 설정

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"   # 기본 SC 지정
provisioner: ebs.csi.aws.com          # 사용할 CSI 드라이버
reclaimPolicy: Delete                 # Delete(기본) / Retain
allowVolumeExpansion: true            # PVC 확장 허용
volumeBindingMode: WaitForFirstConsumer  # Pod 스케줄링 후 PV 생성 (권장)
parameters:
  type: gp3
  iops: "3000"
  throughput: "125"
  encrypted: "true"

주요 필드

종합 실습

MySQL StatefulSet + Spring Boot 통합 배포

Step 1. ConfigMap 생성

Step 2. Secret 생성

Step 3. MySQL Headless Service + StatefulSet

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: lab-final
spec:
  clusterIP: None           # Headless Service 선언 값
  selector:
    app: mysql
  ports:
  - port: 3306
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: lab-final
spec:
  serviceName: mysql         # 위에서 생성한 Service 이름
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Delete       # StatefulSet 삭제 시 PVC도 함께 삭제
    whenScaled: Retain        # 스케일 다운 시 PVC 유지
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:                        # Secret에서 값 참조하는 방식
              name: app-secret
              key: DB_ROOT_PASSWORD
        - name: MYSQL_DATABASE
          valueFrom:
            configMapKeyRef:                        # ConfigMap에서 값 참조하는 방식
              name: app-config
              key: DB_NAME
        volumeMounts:
        - name: mysql-data
          mountPath: /var/lib/mysql
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
        readinessProbe:
          exec:
            command: ["mysqladmin", "ping", "-h", "localhost"]
          initialDelaySeconds: 30
          periodSeconds: 10
  volumeClaimTemplates:                                  # Pod별 PVC를 자동 생성하는 StatefulSet 전용 필드
  - metadata:
      name: mysql-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 2Gi

Step 4. 초기 데이터 생성

# 방법 1 : 직접 들어가서 생성
kubectl exec -it mysql-0 -n lab-final — bash
    mysql -uroot -prootpass123 shopdb
    USE shopdb;

# 방법 2
kubectl exec mysql-0 -n lab-final -- \
mysql -uroot -prootpass123 shopdb -e \
"CREATE TABLE IF NOT EXISTS products (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    price INT NOT NULL
);
INSERT INTO products (name, price) VALUES ('Apple', 1500), ('Banana', 800);
SELECT * FROM products;"

Step 5. Spring Boot Deployment + Service

apiVersion: v1
kind: Service
metadata:
  name: spring-app-svc
  namespace: lab-final
spec:
  type: NodePort                # 외부에서 노드 IP로 접근 가능한 타입
  selector:
    app: spring-app
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: spring-app
  namespace: lab-final
  annotations:
    kubernetes.io/change-cause: "초기 배포"
spec:
  replicas: 2
  selector:
    matchLabels:
      app: spring-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0               # 배포 중 사용 불가 Pod 수 (무중단 보장)
  template:
    metadata:
      labels:
        app: spring-app
    spec:
      initContainers:
      - name: wait-for-mysql
        image: busybox:1.36
        command:
        - sh
        - -c
        - |
          until nc -z mysql 3306; do
            echo "MySQL 준비 대기 중..."
            sleep 3
          done

      containers:
      - name: spring-app
        image: nginx:1.25-alpine
        ports:
        - containerPort: 80
        envFrom:                            # ConfigMap 전체를 환경변수로 주입
        - configMapRef:
            name: app-config
        - secretRef:
            name: app-secret
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name        # Downward API 필드 경로 지정 키
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        volumeMounts:
        - name: log-vol
          mountPath: /logs
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 10
          failureThreshold: 3
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "300m"
            memory: "256Mi"
        lifecycle:
          preStop:
            exec:
              command: ["sleep", "5"]

      - name: log-sidecar
        image: busybox:1.36
        restartPolicy: Always                     # 네이티브 사이드카 선언 필드
        command: ["sh", "-c", "tail -f /logs/app.log 2>/dev/null || sleep 3600"]
        volumeMounts:
        - name: log-vol
          mountPath: /logs

      volumes:
      - name: log-vol
        emptyDir: {}                         # Pod 수명과 동일한 임시 공유 볼륨 타입

      terminationGracePeriodSeconds: 30

Step 6. 전체 리소스 상태 확인

조회 대상: Deployment, StatefulSet, Pod, Service, PVC, ConfigMap, Secret

Step 7. 환경변수 주입 검증

spring-app Pod 이름을 변수에 저장

SPRING_POD=$(kubectl get pod -n lab-final -l app=spring-app -o jsonpath='{.items[0].metadata.name}')

Step 8. MySQL 데이터 영속성 검증

# 1. 삭제 전 데이터 조회
kubectl exec mysql-0 -n lab-final -- \
> mysql -uroot -prootpass123 shopdb -e "SELECT * FROM products;"

# 2. Pod 강제 삭제
kubectl delete pod mysql-0 -n lab-final

# 3. 재생성 대기
kubectl get pod -n lab-final

# 4. 재생성 후 데이터 조회 (영속성 검증)
kubectl exec mysql-0 -n lab-final -- \
> mysql -uroot -prootpass123 shopdb -e "SELECT * FROM products;"

Step 09. 롤링업데이트 + 롤백 — 완전 작성형

개념

• 소프트웨어 개발(Development)과 운영(Operations)의 합성어
• 두 조직 사이의 협업·자동화·지속적 개선을 통해 소프트웨어를 빠르고 안정적으로 제공하는 문화·철학·방법론의 집합

[전통적 개발 방식 — 사일로(Silo) 구조]

  개발팀(Dev)           운영팀(Ops)
  ┌──────────┐          ┌──────────┐
  │ 코드 작성 │ ──────►  │ 배포·운영 │
  │ 기능 개발 │         │ 장애 대응 │
  └──────────┘          └──────────┘
       ↑                     │
       └─────────────────────┘
           장애 발생 시 책임 전가

---
[DevOps 구조 — 단일 팀이 전체 수명주기 담당]

  ┌──────────────────────────────────────────┐
  │              DevOps 팀                │
  │  계획 → 코드 → 빌드 → 테스트 → 배포 →     │
  │  운영 → 모니터링 → (피드백) → 계획 →      │
  └──────────────────────────────────────────┘
              무한 루프(Infinite Loop)

02. DevOps 루프 — 8단계 무한 사이클

개념

• 단방향 프로세스가 아니라 무한 루프(Infinite Loop) 구조

        [DevOps 8단계 무한 루프]

             ┌──────────┐
        ┌───►│  PLAN    │◄───────────────────────────┐
        │    │  계획    │ 백로그, 이슈 트래킹         │
        │    └────┬─────┘ (Jira, GitHub Issues)    │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │  CODE   │ 버전 관리, 코드 리뷰        │
        │    │  코드    │ (Git, GitHub, GitLab)    │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │  BUILD  │ 컴파일, 의존성 해결         │
        │    │  빌드    │ (Maven, Gradle, Docker)  │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │  TEST   │ 단위·통합·보안 테스트       │
        │    │  테스트  │ (JUnit, Selenium, Trivy) │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │ RELEASE │ 아티팩트 생성·버전 태깅     │
        │    │  릴리즈  │ (Docker Image, ECR)      │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │  DEPLOY │ 환경에 배포                │
        │    │  배포    │ (ArgoCD, ECS, EKS)       │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        │    │ OPERATE │ 인프라 운영·스케일링        │
        │    │  운영    │ (Kubernetes, ASG)        │
        │    └────┬─────┘                          │
        │         ▼                               │
        │    ┌──────────┐                          │
        └────│ MONITOR │ 로그·메트릭·알람            │
             │ 모니터링 │ (Prometheus, Grafana, CloudWatch)
             └──────────┘
                  │ 피드백 → 다음 PLAN에 반영

03. DevOps 아키텍처 구조

상황

• 실제 한국 핀테크 기업 수준의 DevOps 아키텍처를 구조적으로 이해

[핀테크 서비스 DevOps 아키텍처 — 전체 흐름]

  개발자 PC
  ┌──────────────────┐
  │  IntelliJ IDEA  │
  │ Spring Boot 3.x │
  │ Git commit/push │
  └────────┬─────────┘
           │ git push (feature 브랜치)
           ▼
  ┌──────────────────────────────────────────────────┐
  │                   GitHub                     │
  │  ┌─────────────────────────────────────────────┐ │
  │  │Pull Request → Code Review → Merge to main│ │
  │  └──────────────────────┬──────────────────────┘ │
  └─────────────────────────┼────────────────────────┘
                            │ Push event (webhook)
                            ▼
  ┌──────────────────────────────────────────────────┐
  │           GitHub Actions (CI Pipeline)       │
  │                                              │
  │  [1] 단위 테스트 (JUnit 5)                     │
  │  [2] 코드 품질 검사 (SonarQube)                 │
  │  [3] 보안 취약점 스캔 (Trivy)                   │
  │  [4] Docker 이미지 빌드                        │
  │  [5] ECR(Elastic Container Registry)에 Push   │
  │  [6] GitOps 저장소 image tag 업데이트           │
  └───────────────────────────────────────────────────┘
                            │ GitOps repo 변경 감지
                            ▼
  ┌──────────────────────────────────────────────────┐
  │              ArgoCD (CD — GitOps)            │
  │                                              │
  │  GitOps Repo 변경 감지 → K8s 클러스터 동기화     │
  │  Staging 자동 배포 → Production 수동 승인       │
  └──────────────────────────────────────────────────┘
                            │
                            ▼
  ┌──────────────────────────────────────────────────┐
  │              AWS EKS (Production)            │
  │                                              │
  │  ap-northeast-2 (서울 리전)                   │
  │  AZ-a: Pod 그룹 A     AZ-c: Pod 그룹 B        │
  │                                              │
  │  ALB → Service → Deployment(Pods)            │
  │  RDS MySQL 8.x (Multi-AZ)                    │
  │  ElastiCache Redis (Multi-AZ)                │
  └──────────────────────────────────────────────────┘
                            │
                            ▼
  ┌──────────────────────────────────────────────────┐
  │          모니터링 스택 (Observability)         │
  │                                              │
  │  Prometheus → 메트릭 수집                      │
  │  Grafana    → 대시보드 시각화                  │
  │  Loki       → 로그 수집·조회                   │
  └──────────────────────────────────────────────────┘

GitHub Actions

01. CI / CD 개념

개념

• CI/CD는 코드 변경부터 배포까지 전 과정을 자동화하는 방법론

CI (Continuous Integration, 지속적 통합)

• 다수의 개발자가 협업할 때 발생하는 충돌을 조기에 탐지하고, 코드 변경 사항을 자동으로 빌드·테스트하여 통합하는 프로세스

CD (Continuous Deployment / Delivery, 지속적 배포)

• CI를 통과한 코드를 자동으로 스테이징 또는 프로덕션 환경에 배포하는 프로세스

[CI/CD 전체 흐름]

  개발자 코드 작성
       |
       v
  git push / PR
       |
       v
  ┌────────────────────────────────┐
  │           CI 단계            │
  │  빌드 → 단위테스트 → 통합테스트 │
  └────────────────────────────────┘
       |
       v
  ┌─────────────────────────────────┐
  │           CD 단계             │
  │ 스테이징 배포 → 검증 → 운영 배포 │
  └─────────────────────────────────┘
       |
       v
   서비스 운영 중

02. GitHub Actions 개요

개념

• GitHub Actions는 GitHub 리포지토리 이벤트(push, PR 등)를 트리거로 워크플로우를 자동화하는 플랫폼
• YAML 파일로 워크플로우를 정의하며, 반드시 .github/workflows/ 디렉토리에 저장

구성 요소

03. 워크플로우 파일 기본 구조

개념

• 워크플로우 파일은 YAML 형식이며 다음 키워드들로 구성

[워크플로우 파일 구조]

  name:        ← Workflow 이름 (Actions 탭에 표시)
  run-name:    ← 실행 이름 (실행 목록에 표시, 표현식 사용 가능)
  on:          ← 트리거 이벤트 정의
    ...
  jobs:        ← Job 목록
    job-이름:
      runs-on: ← Runner 환경
      steps:   ← Step 목록
        - name: Step 이름
          run:  ← shell 명령어
          uses: ← 외부 Action 참조

GitHub Actions YAML 문법

01. 워크플로우 최상위 키워드

• on — 트리거 이벤트 : 워크플로우를 실행할 이벤트를 정의
• jobs — Job 정의 : jobs 키워드 하위에 실행할 Job을 정의
• steps — Step 정의 : Job 내부에서 순서대로 실행되는 작업 단위 , 각 Step은 run(shell) 또는 uses(외부 Action) 중 하나를 반드시 포함

02. env — 환경변수

• 환경변수는 워크플로우 레벨, Job 레벨, Step 레벨 세 곳에서 정의 가능하며, 하위 레벨이 상위 레벨을 덮어씀

[환경변수 우선순위]

  워크플로우 레벨 env (가장 낮음)
       |
       ▼ override
  Job 레벨 env
       |
       ▼ override
  Step 레벨 env (가장 높음)

03. uses & with — 외부 Action

개념

• uses는 GitHub Marketplace의 Action을 참조
• with는 Action에 입력값을 전달

# actions/checkout — 리포지토리 코드를 Runner에 내려받음
- name: 소스코드 체크아웃
  uses: actions/checkout@v4
  with:
    ref: main               # 특정 브랜치/태그/SHA 체크아웃
    path: ./app             # 체크아웃 경로 (기본: 워크스페이스 루트)
    fetch-depth: 0          # 전체 히스토리 (기본 1, 얕은 복제)

# 다른 리포지토리 체크아웃
- name: 외부 리포지토리 체크아웃
  uses: actions/checkout@v4
  with:
    repository: actions/checkout
    path: ./other-repo

GitHub Actions Context & Expressions & Variables & Secrets

01. Context

• 워크플로우 실행 시점에 GitHub Actions가 자동으로 주입하는 정보 객체

02. github Context

• github Context는 워크플로우 실행을 유발한 이벤트와 리포지토리 관련 정보를 담음

steps:
  - name: github context 주요 값
    run: |
      echo "actor: ${{ github.actor }}"
      echo "repository: ${{ github.repository }}"
      echo "ref_name: ${{ github.ref_name }}"
      echo "sha: ${{ github.sha }}"
      echo "event_name: ${{ github.event_name }}"
      echo "run_number: ${{ github.run_number }}"

  - name: github context 전체 (JSON)
    env:
      GITHUB_CONTEXT: ${{ toJson(github) }}
    run: echo "$GITHUB_CONTEXT"

03. runner Context

• runner Context는 현재 Job이 실행되는 Runner 환경 정보를 제공

04. steps Context & GITHUB_OUTPUT

• steps Context는 현재 Job 내의 이전 Step들의 실행 결과를 참조

[Step 간 데이터 전달 흐름]

  Step 1 (id: generate)
    └─ run: echo "result=Hello" >> $GITHUB_OUTPUT
                                   │
                                   │ GITHUB_OUTPUT 파일에 기록
                                   ▼
  Step 2
    └─ run: echo "${{ steps.generate.outputs.result }}"
                                   ↑
                          steps.{id}.outputs.{키} 로 참조

05. vars & secrets Context

• vars는 일반 구성 변수를 참조 (로그에 평문 노출)
• secrets는 암호화된 민감한 정보를 참조하며 로그에 ***로 마스킹

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: vars 출력 (평문)
        run: echo "환경: ${{ vars.APP_ENV }}"

      - name: secrets 출력 (마스킹)
        run: echo "토큰: ${{ secrets.API_TOKEN }}"
        # 로그: 토큰: ***

06. Expressions — 표현식

• 표현식은 ${{ }} 안에 작성하며, Context 값 참조, 연산, 함수 호출을 지원
• if 조건, run-name, env 값, with 입력값 등에서 사용 가능

07. inputs Context — workflow_dispatch 입력값

• workflow_dispatch 이벤트에 inputs를 정의하면 Actions 탭의 "Run workflow" 버튼 클릭 시 사용자가 직접 값을 입력할 수 있음

on:
  workflow_dispatch:
    inputs:
      name:
        description: '이름 (영소문자)'
        required: true
        default: 'user'
        type: string
      environment:
        description: '배포 환경'
        required: true
        default: 'staging'
        type: choice
        options:
          - staging
          - production
      debug:
        description: '디버그 모드'
        required: false
        default: false
        type: boolean

jobs:
  use-inputs:
    runs-on: ubuntu-latest
    steps:
      - name: 입력값 확인
        run: |
          echo "이름: ${{ inputs.name }}"
          echo "환경: ${{ inputs.environment }}"
          echo "디버그: ${{ inputs.debug }}"

GitHub Actions Job 제어

01. needs — Job 의존성 및 순차 실행

• 모든 Job은 병렬 실행
• needs 키워드로 선행 Job을 지정하면 해당 Job 완료 후 현재 Job이 실행

[needs를 활용한 Job 실행 순서 설계]

  병렬 실행 (기본)        needs 활용 순차/혼합 실행

  ┌──────┐ ┌──────┐      ┌──────┐
  │ job1│ │ job2 │      │ job1 │ ── lint
  └──────┘ └──────┘      └──────┘
                              │
                    ┌─────────┼──────────┐
                    ▼         ▼          ▼
                 ┌──────┐ ┌──────┐   ┌──────┐
                 │ job2│ │ job3 │   │ job4 │  ← 동시 실행 (모두 job1 needs)
                 └──────┘ └──────┘   └──────┘
                    │         │
                    └────┬────┘
                         ▼
                      ┌──────┐
                      │ job5│ (needs: [job2, job3])
                      └──────┘

02. strategy.matrix — 다중 환경 병렬 빌드

• strategy.matrix는 하나의 Job 정의로 여러 변수 조합을 생성하여 각각 독립된 Runner에서 병렬 실행

03. if — 조건부 실행

• Job 또는 Step 레벨에서 사용하며, 조건이 true일 때만 실행

jobs:
  # Job 레벨 if
  deploy:
    runs-on: ubuntu-latest
    if: ${{ github.ref_name == 'main' }}
    steps:
      - run: echo "main 배포"

  # Step 레벨 if
  conditional-steps:
    runs-on: ubuntu-latest
    steps:
      - id: random
        run: echo "num=$(($RANDOM % 2))" >> $GITHUB_OUTPUT

      - name: 0일 때 실행
        if: ${{ steps.random.outputs.num == '0' }}
        run: echo "0 출력"

      - name: 실패 시에만 실행
        if: ${{ failure() }}
        run: echo "이전 Step 실패"

      - name: 항상 실행 (실패해도)
        if: ${{ always() }}
        run: echo "항상 실행됨"

04. concurrency — 동시 실행 제어

• 동일 그룹에서 동시에 실행되는 워크플로우/Job 수를 제한
• 연속 push 시 이전 배포가 완료되기 전 새 배포가 시작되는 문제를 방지

[concurrency 동작]

  Push 1 → 배포 A 실행 중 ────────────────▶ 완료
  Push 2 →       대기 (A가 실행 중이므로)
  Push 3 →             A 취소 후 C가 실행    (cancel-in-progress: true)
           → Push 2는 취소됨 (가장 최신만 실행)

# 워크플로우 레벨 적용 (가장 일반적)
name: 배포 워크플로우
on: push

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}    # 브랜치별 독립 그룹
  cancel-in-progress: true                            # 진행 중 취소

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "배포"

GitHub Actions Artifacts & Caching

01. Artifacts — 빌드 결과물 저장 및 공유

• 워크플로우 실행 중 생성된 파일을 GitHub에 업로드하여 Job 간 공유하거나 실행 후 다운로드할 수 있도록 하는 기능
• CI에서 빌드한 JAR, 테스트 리포트, 로그 파일 등을 저장하고 CD Job에서 사용하는 패턴이 가장 일반적

[Artifact 흐름]

  Job 1 (Runner A)
  ├── 파일 생성 (예: app.jar)
  └── actions/upload-artifact ──▶ GitHub Artifact 저장소
                                          │
                                          │ (Job 경계 초월)
                                          ▼
  Job 2 (Runner B)              GitHub Artifact 저장소
  ├── actions/download-artifact ◀──────────┘
  └── 파일 사용

jobs:
  produce:
    runs-on: ubuntu-latest
    steps:
      - name: 파일 생성
        run: |
          mkdir output
          echo "빌드 결과" > output/result.txt

      - name: Artifact 업로드
        uses: actions/upload-artifact@v4
        with:
          name: my-artifact              # Artifact 이름 (다운로드 시 참조)
          path: output/                  # 업로드할 파일 또는 디렉토리
          retention-days: 7              # 보관 기간 (기본 90일)
          if-no-files-found: error       # 파일 없을 때 처리: error|warn|ignore

  consume:
    needs: produce
    runs-on: ubuntu-latest
    steps:
      - name: Artifact 다운로드
        uses: actions/download-artifact@v4
        with:
          name: my-artifact              # 업로드 시 지정한 이름
          path: ./received               # 다운로드 경로

      - name: 다운로드 확인
        run: |
          ls -al ./received
          cat ./received/result.txt

02. actions/cache — 의존성 캐싱

• 의존성 파일(node_modules, ~/.m2, ~/.gradle 등)을 캐싱하여 워크플로우 실행 시간을 단축
• 캐시 키가 일치하면 이전에 저장한 캐시를 복원하고, 불일치 시 새로 다운로드 후 저장

GitHub Actions Reusable Workflows & Composite Actions

01. 재사용의 필요성

• 여러 리포지토리 또는 여러 워크플로우에서 동일한 작업(JDK 설정, 빌드, 배포 등)을 반복 정의하는 문제를 해결하기 위해 GitHub Actions는 두 가지 재사용 메커니즘을 제공

02. Reusable Workflow — workflow_call

• on: workflow_call로 정의된 워크플로우는 다른 워크플로우에서 uses 키워드로 호출 가능
• inputs로 파라미터를 받고, secrets로 시크릿을 전달받으며, outputs로 결과를 반환

# .github/workflows/reusable-deploy.yml (재사용 가능한 워크플로우)

name: Reusable Deploy
on:
  workflow_call:               # 이 키워드로 재사용 가능하게 정의
    inputs:
      environment:
        required: true
        type: string
      version:
        required: true
        type: string
    outputs:
      result:                  # 호출한 워크플로우로 반환할 값
        description: "배포 결과"
        value: ${{ jobs.deploy.outputs.result }}

jobs:
  deploy:
    runs-on: ubuntu-latest
    outputs:
      result: ${{ steps.run.outputs.result }}
    steps:
      - id: run
        run: |
          echo "환경: ${{ inputs.environment }}"
          echo "버전: ${{ inputs.version }}"
          echo "result=success-${{ inputs.environment }}" >> $GITHUB_OUTPUT

# .github/workflows/main-pipeline.yml (호출하는 워크플로우)

name: Main Pipeline
on: workflow_dispatch

jobs:
  call-deploy:
    uses: ./.github/workflows/reusable-deploy.yml    # 로컬 호출
    with:
      environment: staging
      version: "1.0.0"

  use-result:
    needs: call-deploy
    runs-on: ubuntu-latest
    steps:
      - run: echo "결과: ${{ needs.call-deploy.outputs.result }}"

GitHub Actions CI/CD 실습

• 간단한 REST API를 가진 Spring Boot 프로젝트를 GitHub Actions를 통해 mylab-bastion EC2에 자동 배포하는 흐름을 단계별로 구축

[전체 흐름]

  단계 1. SSH + Private Key 직접 실행
       JAR을 SCP로 EC2에 직접 전송, SSH로 java -jar 실행
       장점 : 가장 단순, Docker 불필요
       한계 : 컨테이너 격리 없음, 환경 의존성 노출

       전환 동기 : 컨테이너로 환경 격리 필요
              ↓

  단계 2. Docker Hub + 컨테이너 실행
       JAR을 Docker 이미지로 빌드, Docker Hub에 push
       EC2가 Docker Hub에서 pull하여 컨테이너 실행
       장점 : 환경 격리, 이미지 버전 관리 용이
       한계 : Private Key, Docker Hub Token 모두 GitHub Secrets에 저장

       전환 동기 : 장기 자격증명을 모두 제거하고 싶음
              ↓

  단계 3. OIDC 인증으로 전환
       장기 자격증명 제거, AWS IAM Role을 임시 토큰으로 Assume
       장점 : Secret 노출 위험 최소화, 자동 회전
       실무 표준 : AWS와 GitHub Actions의 권장 패턴

사용할 Action 참고 URL

cicd.yml 작성

• ci Job(빌드 + Artifact 업로드)과 cd Job(다운로드 + SCP + SSH 실행)을 하나의 워크플로우 파일에 분리해서 작성
• needs로 cd가 ci 완료 후 자동 실행되도록 연결.

name: CI/CD - cicd-basic-lab to mylab-bastion

# 빈칸 1: main 브랜치 push와 수동 실행 두 가지 트리거 작성
on:
  push:
    branches: [main]
  workflow_dispatch:

# 빈칸 2: 같은 워크플로우/브랜치 동시 실행 시 이전 실행 취소되도록 설정
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true
jobs:
  ci:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./cicd-basic-lab

    # 빈칸 3: cd Job에서 참조할 Artifact 이름을 outputs로 노출
    outputs:
      artifact_name: ${{ steps.set-name.outputs.value }}

    steps:
      - name: 소스코드 체크아웃
        uses: actions/checkout@v4

      - name: JDK 17 설정
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          # 빈칸 4: Maven 의존성 캐시 키워드
          cache: maven

      - name: Maven 빌드
        run: mvn -B package -DskipTests 

      - name: JAR 파일명 정리
        run: mv ./target/*.jar ./target/app.jar

      - name: Artifact 이름 설정
        id: set-name
        # 빈칸 5: GITHUB_OUTPUT에 value=app-{run_number} 형식으로 저장
        run: echo "value=app-${{ github.run_number }}" >> $GITHUB_OUTPUT

      - name: JAR Artifact 업로드
        uses: actions/upload-artifact@v4
        with:
          name: ${{ steps.set-name.outputs.value }}
          # 빈칸 6: 업로드할 파일 경로
          path: ./cicd-basic-lab/target/app.jar
          retention-days: 1

  cd:
    # 빈칸 7: ci Job 완료 후 실행되도록 의존성 선언
    needs: ci
    runs-on: ubuntu-latest

    steps:
      - name: JAR Artifact 다운로드
        uses: actions/download-artifact@v4
        with:
          # 빈칸 8: ci Job의 outputs에서 artifact_name 값 참조
          name: ${{ needs.ci.outputs.artifact_name }}
          path: .

      - name: SCP로 EC2에 JAR 전송
        # 빈칸 9: SCP 액션 (소유자/저장소 형식)
        uses: appleboy/scp-action@v1
        with:
          # 빈칸 10: 등록한 secrets 3개를 각각 참조
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          source: "app.jar"
          target: "/home/ubuntu/app"

      - name: SSH로 EC2에서 앱 실행
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          # 빈칸 11: 스크립트 중 실패 시 즉시 중단되도록 설정
          script_stop: true
          script: |
            mkdir -p /home/ubuntu/app/deploy
            mv /home/ubuntu/app/app.jar /home/ubuntu/app/deploy/app.jar
            sudo fuser -k -n tcp 8080 || true
            cd /home/ubuntu/app/deploy
            nohup java -jar app.jar > ./output.log 2>&1 &
            sleep 3
            echo "앱 실행 완료"

단계 1의 한계점

이 한계를 해결하기 위해 Docker 컨테이너로 전환

GitHub Variables 추가

리포지토리 → Settings → Secrets and variables → Actions → Variables 탭 → New repository variable

GitHub Secrets 추가

Secrets 탭 → New repository secret

사용할 Action 참고 URL

cicd.yml 작성

name: CI/CD - cicd-basic-lab to mylab-bastion (Docker)

on:
  push:
    branches: [main]
  workflow_dispatch:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  ci:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./cicd-basic-lab
    # 빈칸 1: cd Job에서 참조할 이미지 태그를 outputs로 노출
    outputs:
      image_tag: ${{ steps.tag.outputs.value }}
    steps:
      - uses: actions/checkout@v4

      - name: JDK 17 설정
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: maven

      - name: Maven 빌드
        run: mvn -B package -DskipTests

      - name: JAR 파일명 정리
        run: mv ./target/*.jar ./target/app.jar

      - name: 이미지 태그 생성
        id: tag
        # 빈칸 2: {DOCKERHUB_USERNAME}/cicd-basic-lab:{run_number}-{sha 앞 7자리} 형식 생성
        # 힌트: SHORT_SHA로 SHA 7자리 추출 → TAG 변수에 조합 → $GITHUB_OUTPUT에 저장
        run: |
          SHORT_SHA=$(echo "${{ github.sha }}" | cut -c1-7)
          TAG="${{ vars.DOCKERHUB_USERNAME }}/cicd-basic-lab:${{ github.run_number }}-$SHORT_SHA"
          echo "value=$TAG" >> $GITHUB_OUTPUT

      - name: Docker Hub 로그인
        # 빈칸 3: Docker 로그인 액션 (소유자/저장소@v3)
        uses: docker/login-action@v3
        with:
          # 빈칸 4: vars로 username, secrets로 token 참조
          username: ${{ vars.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Docker Buildx 설정
        # 빈칸 5: Buildx 설정 액션
        uses: docker/setup-buildx-action@v3

      - name: 이미지 빌드 및 Push
        uses: docker/build-push-action@v6
        with:
          # 빌드 컨텍스트는 Dockerfile이 있는 프로젝트 폴더
          context: ./cicd-basic-lab
          # 빈칸 6: Push를 위한 boolean 값
          push: true
          tags: |
            ${{ steps.tag.outputs.value }}
            ${{ vars.DOCKERHUB_USERNAME }}/cicd-basic-lab:latest
          # 빈칸 7: GitHub Actions 캐시를 Docker 레이어 캐시로 활용
          cache-from: type=gha
          cache-to: type=gha,mode=max # mode=max : 중간 빌드 단계의 레이어까지 모두 저장 / mode=min : 최종 레이어만 저장

  cd:
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - name: 배포할 이미지 출력
        run: |
          echo "배포 이미지: ${{ needs.ci.outputs.image_tag }}"

      - name: SSH로 EC2에서 docker pull & run
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USERNAME }}
          key: ${{ secrets.EC2_PRIVATE_KEY }}
          script_stop: true
          # 빈칸 8: pull → 기존 컨테이너 stop/rm → run -d 순서로 작성
          # 힌트:
          #   docker pull {image_tag}
          #   docker stop cicd-basic-lab || true
          #   docker rm cicd-basic-lab || true
          #   docker run -d --name cicd-basic-lab -p 8080:8080 -e TZ=Asia/Seoul --restart unless-stopped {image_tag}
          #   docker image prune -f
          script: |
            docker pull ${{ needs.ci.outputs.image_tag }}
            docker stop cicd-basic-lab || true
            docker rm cicd-basic-lab || true
            docker run -d \
              --name cicd-basic-lab \
              -p 8080:8080 \
              -e TZ=Asia/Seoul \
              --restart unless-stopped \
              ${{ needs.ci.outputs.image_tag }}
            docker image prune -f
            docker ps
            echo "배포 완료"

실습 아키텍처

단계 2의 한계점

AWS IAM OIDC Provider 및 Role 생성

• Docker Hub 부분은 다음 과정에서 ECR로 전환

[단계 2 → 단계 3 전환]

[단계 2: SSH + Docker Hub]
  GitHub Actions
       │
       │ Docker Hub Token (장기)
       ├─▶ Docker Hub Push
       │
       │ EC2_PRIVATE_KEY (장기, 가장 위험)
       └─▶ SSH/SCP ─▶ EC2

[단계 3: OIDC + Docker Hub + SSM]
  GitHub Actions
       │
       │ Docker Hub Token (단계 2 그대로 유지)
       ├─▶ Docker Hub Push
       │
       │ OIDC 임시 자격증명 (15분~1시간)
       └─▶ AWS STS ─▶ SSM Send-Command ─▶ EC2
                                          (SSH Agent 없이 명령 실행)

GitHub Variables 추가

사용할 Action 참고 URL

cicd.yml 작성

name: CI/CD - cicd-basic-lab to mylab-bastion (OIDC + SSM)
on:
  push:
    branches: [main]
  workflow_dispatch:

# 빈칸 1: OIDC 토큰 발급을 위한 권한
permissions:
  id-token: write
  contents: read

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  ci:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: ./cicd-basic-lab
    outputs:
      image_tag: ${{ steps.tag.outputs.value }}
    steps:
      - uses: actions/checkout@v4

      - name: JDK 17 설정
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: maven

      - name: Maven 빌드
        run: mvn -B package -DskipTests

      - name: JAR 파일명 정리
        run: mv ./target/*.jar ./target/app.jar

      - name: 이미지 태그 생성
        id: tag
        run: |
          SHORT_SHA=$(echo "${{ github.sha }}" | cut -c1-7)
          TAG="${{ vars.DOCKERHUB_USERNAME }}/cicd-basic-lab:${{ github.run_number }}-$SHORT_SHA"
          echo "value=$TAG" >> $GITHUB_OUTPUT

      - name: Docker Hub 로그인
        uses: docker/login-action@v3
        with:
          username: ${{ vars.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Docker Buildx 설정
        uses: docker/setup-buildx-action@v3

      - name: 이미지 빌드 및 Push
        uses: docker/build-push-action@v6
        with:
          # 빌드 컨텍스트는 Dockerfile이 있는 프로젝트 폴더
          context: ./cicd-basic-lab
          push: true
          tags: |
            ${{ steps.tag.outputs.value }}
            ${{ vars.DOCKERHUB_USERNAME }}/cicd-basic-lab:latest
          cache-from: type=gha
          cache-to: type=gha,mode=max

  cd:
    needs: ci
    runs-on: ubuntu-latest
    steps:
      - name: 배포할 이미지 출력
        run: |
          echo "배포 이미지: ${{ needs.ci.outputs.image_tag }}"

      - name: AWS 자격증명 설정 (OIDC)
        # 빈칸 2: configure-aws-credentials 액션 (소유자/저장소@v4)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          # 빈칸 3: vars로 등록한 Role ARN 참조
          role-to-assume: ${{ vars.AWS_ROLE_ARN }}
          aws-region: ${{ vars.AWS_REGION }}

      - name: 자격증명 검증
        # 현재 어떤 Role로 인증되었는지 확인 (디버깅 목적)
        run: aws sts get-caller-identity

      - name: SSM Send-Command로 EC2 배포
        id: ssm
        # 빈칸 4: SSM SendCommand 호출 (AWS-RunShellScript 사용)
        # 힌트: aws ssm send-command --instance-ids {EC2_INSTANCE_ID} --document-name "AWS-RunShellScript" --parameters commands=...
        run: |
          COMMAND_ID=$(aws ssm send-command \
            --instance-ids ${{ vars.EC2_INSTANCE_ID }} \
            --document-name "AWS-RunShellScript" \
            --comment "Deploy cicd-basic-lab run #${{ github.run_number }}" \
            --parameters '{"commands":[
              "docker pull ${{ needs.ci.outputs.image_tag }}",
              "docker stop cicd-basic-lab || true",
              "docker rm cicd-basic-lab || true",
              "docker run -d --name cicd-basic-lab -p 8080:8080 -e TZ=Asia/Seoul --restart unless-stopped ${{ needs.ci.outputs.image_tag }}",
              "docker image prune -f",
              "docker ps"
            ]}' \
            --query "Command.CommandId" \
            --output text)
          echo "command_id=$COMMAND_ID" >> $GITHUB_OUTPUT
          echo "SSM Command ID: $COMMAND_ID"

      - name: SSM 명령 결과 대기 및 확인
        # 빈칸 5: 명령 실행 완료까지 대기 후 결과 출력
        # 힌트:
        #   sleep 10  (또는 폴링 로직)
        #   aws ssm get-command-invocation --command-id {command_id} --instance-id {EC2_INSTANCE_ID}
        run: |
          sleep 10
          aws ssm get-command-invocation \
            --command-id "${{ steps.ssm.outputs.command_id }}" \
            --instance-id ${{ vars.EC2_INSTANCE_ID }} \
            --query "{Status:Status, Output:StandardOutputContent, Error:StandardErrorContent}" \
            --output table

실습 아키텍처

컨테이너 서비스 개요 & 아키텍처

01. 컨테이너란

• 애플리케이션과 그 실행에 필요한 모든 의존성(라이브러리, 런타임, 환경변수, 설정 파일 등)을 하나의 패키지로 묶어 격리된 환경에서 실행하는 기술

02. Docker 핵심 개념

• 컨테이너를 빌드·실행·배포하기 위한 플랫폼

[Docker 핵심 구성 요소]

  Dockerfile    docker build                 docker push
  (빌드 명세서) ──────────────► Docker Image ──────────────► Registry (읽기 전용)  
                                                                                                                      (ECR / Docker Hub)
                                                                                                                                  │
                                                                                                              docker run│
                                                                                                                                  ▼
                                                                                                                          Container
                                                                                                                 (Image + 쓰기 레이어)

03. AWS 컨테이너 서비스 전체 맵

• AWS는 컨테이너 생명주기 전반을 지원하는 완성된 서비스 생태계를 제공

[AWS 컨테이너 서비스 전체 맵]

┌──────────────────────────────────────────────────────────────┐
│  빌드 (Build)                                            │
│  로컬 Docker CLI / GitHub Actions / AWS CodeBuild        │
│   → Dockerfile → Docker Image 생성                       │
└─────────────────────────────┬────────────────────────────────┘
                              │ docker push
                              ▼
┌──────────────────────────────────────────────────────────────┐
│  저장 (Registry) - ECR                                  │
│  Private Registry (계정·리전 격리)                        │
│   - mylab-backend:1.0.0                                 │
│   - mylab-backend:{git-sha}                             │
│ Tag Immutability / Enhanced Scanning / Lifecycle Policy │
└─────────────────────────────┬────────────────────────────────┘
                              │ docker pull (IAM Role 자동 인증)
                              ▼
┌──────────────────────────────────────────────────────────────┐
│  실행 (Orchestration)                                    │
│                                                         │
│   Amazon ECS                    Amazon EKS              │
│   (AWS 관리형 오케스트레이터)   (관리형 Kubernetes)         │
│   mylab-cluster                 Kubernetes Cluster      │
│  Fargate / EC2 선택            Fargate / EC2 / Karpenter │
└─────────────────────────────┬────────────────────────────────┘
                              │
                              ▼
┌──────────────────────────────────────────────────────────────┐
│  관찰 & 보안 (Observability & Security)                  │
│  CloudWatch (메트릭·로그)       CloudTrail (API 감사)     │
│  AWS X-Ray (분산 추적)          Amazon Inspector (취약점) │
│  IAM (접근 제어)                AWS KMS (이미지 암호화)    │
└──────────────────────────────────────────────────────────────┘

04. ECR + ECS 핵심 흐름 이해

• ECR과 ECS는 독립적인 서비스이지만 항상 함께 사용

Amazon ECR - 이미지 레지스트리

01. Amazon ECR 개요

• Amazon ECR(Elastic Container Registry)은 AWS가 제공하는 완전 관리형 컨테이너 이미지 레지스트리 서비스. Docker 이미지, OCI 이미지, Helm Chart 등을 안전하게 저장·관리·배포
• 자체 레지스트리(Harbor, Nexus 등)를 운영할 필요 없이 AWS가 인프라 유지보수·확장·가용성을 완전히 관리

[ECR 서비스 개념 구조]

  AWS 계정 (123456789012)
  ┌───────────────────────────────────────────────────────────┐
  │  ECR Private Registry                                │
  │URI: 123456789012.dkr.ecr.ap-northeast-2.amazonaws.com│
  │                                                      │
  │   ┌─────────────────────────┐                          │
  │   │ Repository            │                          │
  │   │ (mylab-backend)       │                          │
  │   │                       │                          │
  │   │  mylab-backend:1.0.0  │                          │
  │   │  mylab-backend:1.1.0  │                          │
  │   │  mylab-backend:latest │  ← 각 이미지는             │
  │   │  mylab-backend:{sha}  │    Tag + Digest로 식별    │
  │   └─────────────────────────┘                          │
  │                                                      │
  └───────────────────────────────────────────────────────────┘

  이미지 URI 형식:
    {계정ID}.dkr.ecr.{리전}.amazonaws.com/{레포지토리명}:{태그}

  예시:
    123456789012.dkr.ecr.ap-northeast-2.amazonaws.com/mylab-backend:1.0.0

02. ECR 인증 메커니즘

• Docker 표준 인증(Username/Password)이 아닌, AWS IAM 기반 토큰 인증을 사용
• 인증 토큰은 12시간 유효하며, Push/Pull 전 반드시 획득해야 함

[ECR 인증 흐름]

  mylab-bastion (Docker CLI)
  │
  │ 1. aws ecr get-login-password
  ▼
  AWS IAM 서비스
  │ IAM 권한 검증
  │ 2. 임시 인증 토큰 발급 (유효기간: 12시간)
  ▼
  mylab-bastion
  │
  │ 3. docker login --username AWS --password-stdin
  │  {계정ID}.dkr.ecr.ap-northeast-2.amazonaws.com
  ▼
  ECR 엔드포인트
  │ 토큰 검증 완료
  │ 4. docker push / docker pull 허용
  ▼
  ECR Repository (mylab-backend)

03. Pull-through Cache & Cross-Region Replication

• Pull-through Cache는 Docker Hub 등 외부 레지스트리 이미지를 ECR Private Registry에 자동 캐싱하는 기능

ECR 보안 & 운영 관리

01. ECR 보안 설계

• ECR 보안은 이미지의 생성·저장·배포 전 단계에 걸쳐 적용

1순위: Tag Immutability 활성화 (운영 환경 필수) 2순위: Enhanced Scanning + Scan-on-Push 활성화 3순위: Lifecycle Policy 설정 (비용 최적화) 4순위: Secrets Manager 연동 (민감 정보 분리) 5순위: Image Signing 적용 (공급망 보안)

02. Lifecycle Policy (수명주기 정책)

• Lifecycle Policy는 레포지토리의 이미지를 규칙 기반으로 자동 삭제하는 기능
• CI/CD 파이프라인에서 이미지가 지속적으로 Push되면 저장 비용이 증가하므로 필수 설정

┌─────────────────────────────────────────────────────────┐
│         ECR Lifecycle Policy 동작 흐름               │
└─────────────────────────────────────────────────────────┘

   Push 누적                Lifecycle Policy           정리 후
   ┌─────────┐              평가(매일 1회)             ┌─────────┐
   │ 이미지  │              ┌──────────────┐           │ 필요한  │
   │ 100개  │  ────────►    │ 규칙 매칭    │  ──────►   │ 30개만  │
   │ (난잡함)│              │ → expire    │           │ 보존    │
   └─────────┘              └──────────────┘           └─────────┘
                                                      스토리지 비용 절감

Amazon ECS

01. 개요

• Amazon ECS(Elastic Container Service) AWS가 제공하는 완전 관리형 컨테이너 오케스트레이션 서비스
• 컨테이너의 배포·스케일링·상태 관리를 자동화하며, AWS 생태계(ECR, ALB, IAM, CloudWatch 등)와 긴밀하게 통합

[ECS 핵심 구성 요소 계층 구조]

  mylab-cluster (ECS Cluster)
  ─ 컨테이너를 실행하는 논리적 그룹
  │
  └── mylab-backend-service (ECS Service)
              ─ 지정한 수의 Task를 항상 실행 유지
              ─ 실패한 Task 자동 재시작
                  │
                  ├── Task #1 (private-app-2a)
                  │    └── mylab-backend 컨테이너
                  │    (mylab-backend:1.0 이미지)
                  │
                  └── Task #2 (private-app-2c)
                           └── mylab-backend 컨테이너
                           (mylab-backend:1.0 이미지)

  Task Definition: mylab-backend
  ─ Task 실행 청사진 (이미지, CPU, 메모리, 환경변수, 시크릿 등)
  ─ Revision으로 버전 관리 (mylab-backend:1, mylab-backend:2 ...)

02. Task Definition 구조

• Task Definition은 ECS Task를 실행하기 위한 설계도

[mylab-backend Task Definition 구조]

  Task Definition: mylab-backend (Revision 1)
  ┌──────────────────────────────────────────────────────────────────┐
  │  Family:        mylab-backend                               │ 
  │  Launch Type:   FARGATE                                     │
  │  Network Mode:  awsvpc                                      │
  │  Task CPU:      512 (0.5 vCPU)                              │
  │  Task Memory:   1024 MB                                     │
  │                                                             │
  │  Execution Role: mylab-backend-execution-role               │
  │   ├─ ECR Pull 권한                                           │
  │   ├─ CloudWatch Logs 전송 권한                                │
  │   └─ Secrets Manager 조회 권한                                │
  │                                                             │
  │  Task Role: mylab-backend-task-role                         │
  │   ├─ S3 접근 (애플리케이션 요건)                               │
  │   └─ SQS 접근 (애플리케이션 요건)                              │
  │                                                             │
  │  Container: mylab-backend                                   │
  │  ┌────────────────────────────────────────────────────────────┐  │
  │  │  Image:                                               │  │
  │  │   {계정}.dkr.ecr.ap-northeast-2.amazonaws.com          │  │
  │  │   /mylab-backend:1.0                                  │  │
  │  │                                                       │  │
  │  │  Port: 8080                                           │  │
  │  │                                                       │  │
  │  │  Environment:                                         │  │
  │  │   SPRING_PROFILES_ACTIVE = prod                       │  │
  │  │   DB_HOST = mylab-rds.xxx.rds.amazonaws.com           │  │
  │  │                                                       │  │
  │  │  Secrets (Secrets Manager 참조):                       │  │
  │  │   DB_PASSWORD → mylab/db-password                     │  │
  │  │   JWT_SECRET  → mylab/jwt-secret                      │  │
  │  │                                                       │  │
  │  │  Log Driver: awslogs → /ecs/mylab-backend             │  │
  │  └────────────────────────────────────────────────────────────┘  │
  └──────────────────────────────────────────────────────────────────┘

Task Role vs Task Execution Role 구분

[Execution Role vs Task Role 비교]

  mylab-backend-execution-role          mylab-backend-task-role
  ──────────────────────────────        ──────────────────────────────
  ECS 인프라(Agent)가 사용               컨테이너 애플리케이션이 사용

  ECR            → 이미지 Pull           S3        → 파일 업로드/다운로드
  CloudWatch     → 로그 전송             DynamoDB  → 데이터 접근
  Secrets Manager → 시크릿 조회          SQS       → 메시지 처리

           ↑                                       ↑
   ECS가 자동 사용                        Spring Boot AWS SDK가 사용
   (컨테이너 시작 전)                     (컨테이너 실행 중)

03. ECS 보안 그룹 설계

• ECS Task는 private-app-2a/2c에 배치
• 보안 그룹은 최소 권한 원칙에 따라 mylab-alb-sg와 mylab-bastion-sg에서 오는 트래픽만 허용

[mylab-ecs-task-sg 설계]

                      인터넷
                        │
                        ▼
              mylab-alb (mylab-alb-sg)
                        │
                        │ 8080 허용
                        │ (mylab-alb-sg → mylab-ecs-task-sg)
                        ▼
         ┌──────────────────────────────────────┐
         │  ECS Task (mylab-ecs-task-sg)     │
         │                                   │
         │  인바운드 규칙:                     │
         │   ① 8080 ← mylab-alb-sg 참조       │  ← ALB에서만 허용
         │   ② 22   ← mylab-bastion-sg 참조   │  ← Bastion에서만 허용
         │                                   │
         │  아웃바운드 규칙:                   │
         │   All traffic → 0.0.0.0/0         │  ← ECR Pull, RDS 접근 등
         └──────────────────────────────────────┘
                        │
                        │ 3306
                        │ (mylab-ecs-task-sg → sg-db)
                        ▼
                 RDS MySQL (sg-db)

ECS Fargate 실전 배포

01. 실습 목표 아키텍처

• shop-vpc 3계층 구조를 기반으로, ALB는 퍼블릭 서브넷에, ECS Task는 프라이빗 서브넷에 배치하는 실무 표준 구조

02. Fargate 동작 원리

• AWS Fargate는 ECS의 서버리스 컴퓨팅 엔진
• Task 실행 시 AWS가 내부적으로 전용 마이크로 VM을 프로비저닝하여 컨테이너를 격리 실행

[사용자 관리 영역 vs Fargate 관리 영역]

  사용자가 설정하는 영역
  ┌──────────────────────────────────────────────────┐
  │  Task Definition (이미지, CPU, 메모리, 포트)   │
  │  ECS Service (desired count, 배포 전략)       │
  │ VPC 서브넷:    private-app-2a / private-app-2c│
  │  보안 그룹:     mylab-ecs-task-sg             │
  │  IAM Role:      Execution Role / Task Role   │
  └──────────────────────────────────────────────────┘
                          │
                          │ Task 실행 요청 (RunTask API)
                          ▼
  AWS Fargate가 자동 처리하는 영역
  ┌──────────────────────────────────────────────────┐
  │  마이크로 VM 프로비저닝 (Firecracker)           │
  │  컨테이너 런타임 설치 (containerd)              │
  │  ECR에서 mylab-backend:1.0 Pull               │
  │  private-app 서브넷에 ENI 연결 (awsvpc 모드)    │
  │  컨테이너 실행 및 상태 모니터링                  │
  │  OS 패치 및 보안 업데이트                       │
  │  EC2 인스턴스 관리 / 클러스터 스케일링            │
  └──────────────────────────────────────────────────┘

ECR + ECS 통합 아키텍처 & CI/CD

01. ECR + ECS 전환

[단계별 발전 흐름]

단계 1. SSH + Private Key
  GitHub Actions → SCP → EC2 (JAR 직접 전송) → SSH 실행
  문제: 장기 자격증명(Private Key) 노출 위험, EC2 직접 관리 부담

단계 2. Docker Hub + 컨테이너
  GitHub Actions → Docker Hub Push → EC2 docker pull + run
  문제: Docker Hub Rate Limit, 민간 레지스트리 의존, EC2 여전히 존재

단계 3. OIDC + SSM
  GitHub Actions (OIDC) → SSM Send-Command → EC2 docker pull + run
  문제: EC2가 여전히 존재, 인프라 관리 필요

[ECR + ECS 전환]

단계 4. OIDC + ECR + ECS (목표)
  GitHub Actions (OIDC)
  → ECR Push (AWS 전용 프라이빗 레지스트리)
  → ECS Rolling Update (서버리스 컨테이너 실행)
  → EC2 없음 / 인프라 관리 없음 / 무중단 배포

02. 전체 CI/CD 파이프라인 흐름

[cicd-basic-lab → mylab-backend ECR + ECS CI/CD 파이프라인]

  개발자
  │ git push origin main
  ▼
  GitHub Repository (cicd-basic-lab)
  │ main 브랜치 Push → cicd.yml 트리거
  ▼
  ┌─────────────────────────────────────────────────────────────┐
  │  Job 1: ci (빌드 + ECR Push)                            │
  │                                                       │
  │  [1] OIDC 인증                                          │
  │      mylab-github-actions-role 임시 자격증명 발급        │
  │                                                        │
  │  [2] Maven 빌드                                        │
  │      ./mvnw clean package -DskipTests                  │
  │                                                        │
  │  [3] Docker 멀티 스테이지 빌드                           │
  │      이미지 태그: {run_number}-{sha7}                   │
  │      예: mylab-backend:42-abc1234                      │
  │                                                        │
  │  [4] ECR 인증 + Push                                    │
  │      aws ecr get-login-password | docker login         │
  │      docker push → mylab-backend:{태그}                 │
  │                                                        │
  │  [5] ECR Enhanced Scanning 결과 확인                     │
  │      Critical 발견 시 → 파이프라인 중단 (배포 차단)         │
  │                                                        │
  │  outputs: image-uri → Job 2로 전달                      │
  └──────────────────────────┬──────────────────────────────────┘
                             │ needs: ci
                             ▼
  ┌─────────────────────────────────────────────────────────────┐
  │  Job 2: cd (ECS 배포)                                   │
  │                                                        │
  │  [6] OIDC 인증 (재인증)                                  │
  │                                                        │
  │  [7] Task Definition ACCOUNT_ID 동적 치환                │
  │                                                        │
  │  [8] 이미지 URI 교체                                     │
  │      amazon-ecs-render-task-definition                 │
  │      mylab-backend 컨테이너 이미지를 새 URI로 교체         │
  │                                                        │
  │  [9] ECS Rolling Update 배포                           │
  │      amazon-ecs-deploy-task-definition                 │
  │      mylab-cluster / mylab-backend-service             │
  │      배포 안정화까지 대기 (wait-for-service-stability)    │
  └─────────────────────────────────────────────────────────────┘
                             │
                             ▼
  ECS mylab-cluster
  └── mylab-backend-service
       ├── Task (private-app-2a): mylab-backend:{새 태그}
       └── Task (private-app-2c): mylab-backend:{새 태그}
             ↑ Rolling Update (무중단)

GitHub Secrets / Variables 설정

경로: GitHub → cicd-basic-lab 레포지토리
→ Settings → Secrets and variables → Actions

[Secrets]
→ [New repository secret]
Name: AWS_ACCOUNT_ID
Value: 123456789012    ← 본인 AWS 계정 ID

OIDC 방식이므로 ACCESS_KEY 등 장기 자격증명은 저장하지 않음

[Variables]
→ [New repository variable]
Name: ECR_REPOSITORY  / Value: mylab-backend
Name: ECS_CLUSTER     / Value: mylab-cluster
Name: ECS_SERVICE     / Value: mylab-backend-service
Name: CONTAINER_NAME  / Value: mylab-backend

사용할 Action 참고 URL

cicd.yml 작성 (ECR + ECS 버전)

name: CI/CD — ECR + ECS

on:
  push:
    branches: [ main ]
  workflow_dispatch:

permissions:
  id-token: write    # OIDC JWT 토큰 발급
  contents: read

env:
  AWS_REGION: ap-northeast-2
  ECR_REPOSITORY: ${{ vars.ECR_REPOSITORY }}
  ECS_CLUSTER:    ${{ vars.ECS_CLUSTER }}
  ECS_SERVICE:    ${{ vars.ECS_SERVICE }}
  CONTAINER_NAME: ${{ vars.CONTAINER_NAME }}
  TASK_DEFINITION: .aws/task-definition.json

jobs:

  ci:
    name: CI — Build & Push to ECR
    runs-on: ubuntu-latest

    outputs:
      image-repo-tag: ${{ steps.build-push.outputs.image-repo-tag }}

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up JDK 17
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'maven'

      - name: Build with Maven
        working-directory: cicd-basic-lab
        run: mvn clean package -DskipTests -B

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-cicd-basic-lab-role
          aws-region: ${{ env.AWS_REGION }}
          role-session-name: GitHubActions-CI-${{ github.run_id }}

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build, tag and push image to ECR
        working-directory: cicd-basic-lab
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        run: |
          SHORT_SHA="${{ github.sha }}"
          SHORT_SHA="${SHORT_SHA:0:7}"
          TAG="${{ github.run_number }}-${SHORT_SHA}"
          IMAGE_URI="${ECR_REGISTRY}/${{ env.ECR_REPOSITORY }}:${TAG}"

          docker build -t ${IMAGE_URI} .
          docker push ${IMAGE_URI}

          # working-directory 스텝에서 GITHUB_OUTPUT 직접 쓰면 cd Job 전달 불가
          # GITHUB_ENV로 다음 스텝에 전달
          echo "IMAGE_TAG=${TAG}" >> $GITHUB_ENV

      # working-directory 없이 실행해야 GITHUB_OUTPUT 정상 동작
      - name: Export image outputs
        id: build-push
        run: |
          echo "image-repo-tag=${{ env.ECR_REPOSITORY }}:${IMAGE_TAG}" >> $GITHUB_OUTPUT

  cd:
    name: CD — Deploy to ECS
    runs-on: ubuntu-latest
    needs: ci

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::${{ secrets.AWS_ACCOUNT_ID }}:role/github-actions-cicd-basic-lab-role
          aws-region: ${{ env.AWS_REGION }}
          role-session-name: GitHubActions-CD-${{ github.run_id }}

      # ACCOUNT_ID 플레이스홀더 치환
      # find로 동적 탐색 (경로 중복 문제 회피)
      - name: Inject Account ID into task definition
        run: |
          ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
          TASK_DEF_PATH=$(find $GITHUB_WORKSPACE -name "task-definition.json" | head -1)
          sed -i "s/ACCOUNT_ID/${ACCOUNT_ID}/g" ${TASK_DEF_PATH}

      # . / 포함 값은 Job outputs 전달 불가
      # → image-repo-tag (mylab-backend:36-761c224) 만 전달받고
      # → cd Job에서 ECR registry 주소를 직접 조합
      - name: Render new task definition with updated image
        id: task-def
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: ${{ env.TASK_DEFINITION }}
          container-name:  ${{ env.CONTAINER_NAME }}
          image:           ${{ secrets.AWS_ACCOUNT_ID }}.dkr.ecr.${{ env.AWS_REGION }}.amazonaws.com/${{ needs.ci.outputs.image-repo-tag }}

      - name: Deploy to ECS (Rolling Update)
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: ${{ steps.task-def.outputs.task-definition }}
          service:  ${{ env.ECS_SERVICE }}
          cluster:  ${{ env.ECS_CLUSTER }}
          wait-for-service-stability: true  # NEW TASK가 healthy + OLD TASK가 종료 여부 확

실습 아키텍처

RDS Proxy 설정 중 “사용할 수 없음” 에러 발생

원인

[Proxy 도입 구조]
  EC2 Task × 50         RDS Proxy              RDS Primary
  ┌────────────┐        ┌────────────────┐    ┌─────────────┐
  │ HikariCP ×5│ ──────►│ 연결 풀 관리    │──► │ 실제 연결 30│
  │ 250 요청   │        │ (Multiplexing) │    │ 한도 이내    │
  └────────────┘        └────────────────┘    └─────────────┘
                        ↑ 여러 앱 연결을 소수 DB 연결로 묶음

여기 구조에서 RDS Proxy와 RDS primary는 같은 보안그룹(mylab-rds-sg)을 공유 중

보안 그룹 인바운드 규칙에 EC2 Task만 허용된 상태인 걸 발견

• EC2 Task → RDS Proxy (EC2 주소 허용 규칙이 있어 통과)
• RDS Proxy → RDS Primary (Proxy 주소 허용 규칙이 없어 차단 발생!)

해결책

보안 그룹 인바운드 규칙에 RDS Proxy자기 자신의 ID를 추가

RDS Proxy의 상태가 Available로 변경된 것을 확인

13주차에는 Spring Boot와 AWS 서비스를 연결하여 사용하는 실습을 많이 했다. 실습 코드는 따로 개인 깃허브에 저장해놓고 복습할 예정이다.

Spring Boot 파일 서비스 — EC2 배포 + IAM Role

01. EC2 + S3 전체 아키텍처

• 로컬 환경에서 개발하고 테스트했다면, 제 AWS 환경으로 배포
• JAR 파일을 직접 EC2에 전송하고, IAM Role을 사용해 S3 접근 권한을 안전하게 관리

[로컬 개발 → EC2 배포 전환]

 ─────────────── (로컬) ──────────────────

 개발자 PC (Windows / Mac)
 ┌──────────────────────────────────────────┐
 │STS → Spring Boot 실행 (localhost:8080)│
 │IAM User 자격증명 (~/.aws/credentials)  │
 └──────────────────────────────────────────┘
 │ HTTPS
 ▼
 AWS S3 버킷

 ─────────────── (EC2 배포) ────────────────

 개발자 PC                    AWS Cloud
 ┌──────────────┐         ┌──────────────────────────────┐
 │ mvn package │         │      EC2 (Ubuntu 24.04)   │
 │ -> app.jar  │   scp   │           t3.micro        │
 │             │ ──────► │      Java 17 + app.jar 실행│
 └──────────────┘         │             :8080         │
                         │                           │
                         │IAM Role (Instance Profile)│
                         │    ↓ 자동 자격증명 획득      │
                         └──────────────┬───────────────┘
                                       │ HTTPS
                                       ▼
                                     AWS S3 버킷
                                  (ap-northeast-2)

로컬 vs EC2 환경 비교

02. IAM User vs IAM Role

로컬 개발과 EC2 배포 환경에서 AWS 인증 방식이 달라짐

[IAM User — 로컬 개발]

 Spring Boot
 │
 ▼
 DefaultCredentialsProvider
 │
 ├── ~/.aws/credentials 파일 발견
 │   aws_access_key_id = AKIA...
 │   aws_secret_access_key = xxxx
 └── 해당 키로 S3 API 호출

 문제점:
 -> 키를 EC2 서버에 복사하면 보안 위험
 -> 키 노출 시 서버를 통해 S3 전체 접근 가능

---
[IAM Role — EC2 배포]

 Spring Boot (EC2에서 실행)
 │
 ▼
 DefaultCredentialsProvider
 │
 ├── ~/.aws/credentials 없음
 │
 ├── EC2 메타데이터 서비스 확인
 │   http://169.254.169.254/latest/meta-data/iam/security-credentials/
 │
 └── IAM Role에서 임시 자격증명 자동 발급
     AccessKeyId / SecretAccessKey / SessionToken
     → 만료 전 자동 갱신

 장점:
 -> 키를 서버에 저장할 필요 없음
 -> 권한을 Role로 중앙 관리
 -> 임시 자격증명 → 유출되어도 만료 시 무효

IAM User vs IAM Role 비교

03. 환경별 설정 분리

• 로컬 개발과 EC2 운영 환경에서 파일 경로, 로그 경로, 캐시 설정 등이 다름
• 하나의 application.properties에서 모두 관리하면 실수로 운영 설정이 로컬에 적용되거나, 로컬 설정이 EC2에 배포되는 문제 발생
• Spring Profile을 사용해 환경별 설정을 분리하면 이를 방지 가능

[프로파일별 설정 파일 구조]

 src/main/resources/
 ├── application.properties          <- 공통 설정 (모든 환경에서 항상 로드)
 ├── application-local.properties    <- 로컬 전용 (local 프로파일 활성화 시)
 └── application-prod.properties     <- EC2 운영 전용 (prod 프로파일 활성화 시)

 [로드 우선순위]
 application-{profile}.properties 값이
 application.properties 값을 덮어씀 (override)

04. Spring Boot Actuator 헬스체크

개념

• Actuator는 운영 중인 Spring Boot 애플리케이션의 상태·메트릭·정보를 HTTP 엔드포인트로 노출하는 공식 모듈
• EC2 배포 후 앱이 정상 동작하는지 확인하거나, ALB의 헬스체크 Target으로 활용

[Actuator 동작 구조]

 Spring Boot 앱 (내부)
 ├── HealthIndicator 자동 집계
 │     ├── DiskSpaceHealthIndicator  : 디스크 여유 공간 확인
 │     ├── PingHealthIndicator       : 앱 자체 응답 확인
 │     └── (DB 연결 시) DataSourceHealthIndicator
 │
 └── /actuator/health 엔드포인트로 결과 노출
           │
           ▼
      { "status": "UP" }   <- HTTP 200 OK
      { "status": "DOWN" } <- HTTP 503 Service Unavailable

 ALB
 └── 주기적으로 /actuator/health 호출
       -> 200 OK  : 인스턴스 정상 -> 트래픽 전달
       -> 그 외   : 인스턴스 비정상 -> 트래픽 제외, 새 인스턴스 기동

Actuator 응답 상태 종류

• 운영 환경에서는 show-details=when-authorized로 설정하여 상세 정보를 인증된 요청에만 노출
• ALB 헬스체크는 /actuator/health 경로만 호출하면 되며, status: UP = HTTP 200 응답으로 정상 판단

05. 무중단 배포 패턴

ALB + ASG Rolling 배포 (다중 EC2)

• ALB(Application Load Balancer)와 ASG(Auto Scaling Group)를 사용하면 EC2를 순차적으로 교체하는 Rolling 배포가 가능
• 인스턴스 하나씩 새 버전으로 교체하면서 전체 서비스 중단 없이 배포

[ALB + ASG Rolling 배포 흐름]

 배포 전:
 ALB -> EC2 #1 (구버전) :8080
     -> EC2 #2 (구버전) :8080

 Rolling 배포 중:
 Step 1: EC2 #1 을 ALB에서 제외 (In-service -> Draining)
          EC2 #1 새 버전으로 교체 후 Actuator 헬스체크 통과
          EC2 #1 ALB에 재등록 (In-service)

 Step 2: EC2 #2 를 ALB에서 제외
          EC2 #2 새 버전으로 교체 후 Actuator 헬스체크 통과
          EC2 #2 ALB에 재등록

 배포 완료:
 ALB -> EC2 #1 (신버전) :8080
     -> EC2 #2 (신버전) :8080

Spring Boot 파일 서비스 — CloudWatch 모니터링

01. CloudWatch 로그 모니터링 개념

• Spring Boot 애플리케이션이 EC2에서 실행될 때, 로그는 기본적으로 EC2 내부 파일에만 기록됨
• AWS CloudWatch Logs는 애플리케이션 로그를 중앙에 수집·저장·검색할 수 있게 해주는 관리형 서비스

[CloudWatch 없을 때 — 로그 확인의 불편함]

 EC2 인스턴스 A EC2 인스턴스 B
 ┌─────────────┐ ┌────────────┐
 │ app.log    │ │   app.log │
 │ (로컬 파일) │ │ (로컬 파일) │
 └─────────────┘ └────────────┘
 ↑ ↑
 SSH 접속 후 확인 SSH 접속 후 확인
 → 인스턴스가 늘어날수록 로그 확인이 어려워짐
 → 인스턴스 종료 시 로그 소실

---
[CloudWatch 사용 후 — 중앙 집중 로그]

 EC2 인스턴스 A EC2 인스턴스 B
 ┌─────────────┐     ┌─────────────┐
 │    app.log │    │     app.log │
 └──────┬──────┘     └──────┬──────┘
        │ CloudWatch Agent  │ CloudWatch Agent
        └────────┬──────────┘
                                 ▼
                                 AWS CloudWatch Logs
                                 └── Log Group: /ec2/s3-file-service
                                 ├── Log Stream: i-0abc123 (인스턴스 A)
                                 └── Log Stream: i-0def456 (인스턴스 B)
                                 ↑
                                 브라우저·CLI에서 통합 조회·검색·알람 설정

Amazon RDS

01. Amazon RDS 핵심 개념

개념

• AWS가 제공하는 완전 관리형(Managed) 관계형 데이터베이스 서비스
• DB 서버 프로비저닝, OS 패치, DB 엔진 설치, 백업, 모니터링 등 운영 부담을 AWS가 대신 처리

[RDS 핵심 구성 요소]

  ┌─────────────────────────────────────────────────┐
  │                  Amazon RDS                 │
  │                                             │
  │  ┌──────────────┐      ┌──────────────────────┐ │
  │  │ DB Instance │      │   Storage (EBS)    │ │
  │  │             │      │                    │ │
  │  │ - DB 엔진    │ ───► │ gp3 / io2 / 자동확장│ │
  │  │ - vCPU/RAM  │      │                    │ │
  │  └──────────────┘      └──────────────────────┘ │
  │                                              │
  │  ┌──────────────┐      ┌──────────────────────┐ │
  │  │  DB Subnet  │      │   Parameter Group  │ │
  │  │  Group      │      │   (DB 엔진 설정값)   │ │
  │  │  (VPC 배치)  │      │                    │ │
  │  └──────────────┘      └──────────────────────┘ │
  └──────────────────────────────────────────────────┘

주요 용어 정리

02. RDS 스토리지

개념

• RDS는 EBS(Elastic Block Store) 기반 스토리지를 사용
• CPU·메모리(DB Instance)와 스토리지를 독립적으로 확장 가능

스토리지 자동 확장 (Storage Auto Scaling)

• 남은 용량이 임계값 이하로 떨어지면 자동으로 스토리지 용량을 증가시키는 기능
• 활성화 시 최대 허용 용량(Maximum Storage Threshold) 을 반드시 설정

[Storage Auto Scaling 동작 원리]

  초기 설정: 100 GB gp3
  최대 허용: 500 GB

  100 GB ──────────────► 자동 확장 조건 충족 ──────────────► 125 GB
  (사용량 90% 초과,                                          (자동 증가)
   5분 이상 지속)
                          ↓ 조건
                   ① 여유 공간이 할당 용량의 10% 미만
                   ② 해당 상태가 5분 이상 지속
                   ③ 마지막 확장 후 6시간 이상 경과

주요 용어 정리

스토리지 타입 선택 기준

03. Multi-AZ vs Read Replica

RDS의 두 가지 핵심 복제 방식

[Multi-AZ — 고가용성(HA) 목적]

  AZ-a (ap-northeast-2a)        AZ-c (ap-northeast-2c)
  ┌──────────────────┐           ┌──────────────────┐
  │  Primary DB    │ ─ 동기     │  Standby DB     │
  │  (읽기·쓰기 모두)│  복제 ──►  │  (대기 상태)      │
  │                │           │  (트래픽 없음)    │
  └──────────────────┘           └──────────────────┘
           │                              │
           └──────── 하나의 Endpoint ─────┘
                  (DNS: mydb.xxx.rds.amazonaws.com)

  Primary 장애 발생 시:
  → DNS가 Standby를 가리키도록 자동 전환 (Failover)
  → RTO: 약 60~120초
  → 애플리케이션 코드 변경 불필요 (같은 Endpoint 사용)

[Read Replica — 읽기 분산(Scale-Out) 목적]

  Primary DB           Read Replica-1       Read Replica-2
  ┌────────────┐           ┌────────────┐       ┌────────────┐
  │ 읽기+쓰기  │ ─비동기─►   │ 읽기 전용  │  ···  │ 읽기 전용  │
  │           │  복제      │           │       │           │
  └────────────┘           └────────────┘       └────────────┘
  (쓰기 엔드포인트)        (읽기 엔드포인트)    (읽기 엔드포인트)

  ※ 최대 5개 생성 가능 (Aurora는 15개)
  ※ 동일 리전 또는 다른 리전(Cross-Region Read Replica) 가능
  ※ Replica는 Primary 장애 시 자동 Failover 대상이 아님
     → 수동으로 Promote(승격) 해야 Primary가 됨

Multi-AZ vs Read Replica 핵심 비교

04. RDS 백업 & 복구

개념

• RDS는 두 가지 방식의 백업을 제공
• 자동 백업(Automated Backup) 과 수동 스냅샷(Manual Snapshot) — 목적과 보존 기간이 다름

[RDS 백업 방식 비교]

  ┌─────────────────────────────────────────────────────────────┐
  │  자동 백업 (Automated Backup)                           │
  │                                                       │
  │  - RDS 생성 시 기본 활성화                               │
  │  - 매일 지정된 백업 윈도우(Backup Window)에 전체 스냅샷 생성│
  │  - 트랜잭션 로그(Transaction Log)를 5분 간격으로 S3 저장   │
  │  - 보존 기간: 1~35일 설정 (기본 7일)                      │
  │  - DB Instance 삭제 시 자동 삭제 (설정에 따라 보존 가능)    │
  │  - PITR(특정 시점 복구) 지원                              │
  ├─────────────────────────────────────────────────────────────┤
  │  수동 스냅샷 (Manual Snapshot)                           │
  │                                                        │
  │  - 사용자가 직접 생성 (콘솔, CLI, API)                    │
  │  - 보존 기간 제한 없음 (명시적으로 삭제할 때까지 유지)        │ 
  │  - DB Instance 삭제해도 스냅샷은 유지됨                    │
  │  - 다른 AWS 계정·리전으로 공유·복사 가능                    │
  │  - PITR 불가 (특정 시점이 아닌 스냅샷 시점으로만 복구)        │
  └──────────────────────────────────────────────────────────────┘

PITR (Point-In-Time Recovery)

자동 백업 + 트랜잭션 로그를 조합해 특정 시각으로 DB를 복구하는 기능 (원하는 시점에 복구)

백업·복구 전략 비교

05. RDS 보안

RDS 보안은 네트워크 격리 → 접근 제어 → 자격증명 관리 → 암호화 4개 레이어로 구성

[RDS 보안 4개 레이어]

  인터넷
    │
    ▼
  ┌─────────────────────────────────────────────────┐
  │  Layer 1. 네트워크 격리                       │
  │  VPC Private Subnet 배치                     │
  │  → 인터넷 게이트웨이(IGW)와 직접 연결 없음       │
  └─────────────────────┬───────────────────────────┘
                        │ (VPC 내부 트래픽만)
                        ▼
  ┌─────────────────────────────────────────────────┐
  │  Layer 2. 접근 제어                          │
  │  Security Group → 허용된 IP/포트만 통과       │
  │  예) EC2 Security Group → RDS 3306 포트만 허용│
  └─────────────────────┬───────────────────────────┘
                        │
                        ▼
  ┌──────────────────────────────────────────────────┐
  │  Layer 3. 자격증명 관리                        │
  │ Secrets Manager → DB 비밀번호 중앙 관리·자동 교체│
  │  IAM DB Authentication → IAM 토큰으로 DB 접속  │
  └─────────────────────┬────────────────────────────┘
                        │
                        ▼
  ┌─────────────────────────────────────────────────┐
  │  Layer 4. 암호화                             │
  │  저장 데이터: KMS 키로 EBS 볼륨 암호화          │
  │  전송 데이터: SSL/TLS로 전송 구간 암호화        │
  └─────────────────────────────────────────────────┘

06. RDS 모니터링

• RDS 모니터링은 3가지 도구를 계층적으로 활용
• 각 도구가 보여주는 관찰 수준(레벨) 이 다름

DB 파라미터 그룹

수정 가능한 파라미터 그룹

• character_set_client
• character_set_server
• collation_server
• time_zone
• long_query_time
• slow_query_log
• max_connections
• require_secure_transport

DynamoDB

01. DynamoDB 핵심 개념 — NoSQL

• AWS의 완전 관리형(Serverless) NoSQL 데이터베이스
• 키-값(Key-Value) 및 문서(Document) 데이터 모델 지원

[RDB vs NoSQL — 언제 무엇을 선택하는가]

  RDB (RDS MySQL/PostgreSQL)          DynamoDB (NoSQL)
  ─────────────────────────────────────────────────────
  정형화된 스키마 (테이블·컬럼 고정)   스키마 유연 (항목마다 속성 다를 수 있음)
  JOIN 지원 → 복잡한 관계형 쿼리       JOIN 없음 → 단순 조회 최적화
  ACID 트랜잭션 (강한 일관성)          기본 최종 일관성 (강한 일관성 옵션 제공)
  수직 확장 (Scale-Up) 중심            수평 확장 (Scale-Out) 자동 무제한
  예측 가능한 쿼리 패턴에 최적          고트래픽·예측 불가 워크로드에 최적
  예) 주문·결제·회원 관리              예) 세션 저장·게임 리더보드·IoT·장바구니

02. DynamoDB 핵심 개념 — Key 설계

• DynamoDB 성능의 핵심은 Key 설계
• 데이터가 어떤 파티션에 분산 저장되는지, 어떤 순서로 정렬되는지 결정

[파티션 키 (Partition Key, PK) 동작 원리]

  Partition Key 값 → 해시 함수 → 저장 파티션 결정

  PK: "user#1001" → 해시 → 파티션 A
  PK: "user#1002" → 해시 → 파티션 C
  PK: "user#1003" → 해시 → 파티션 B

  ※ PK 값이 다양할수록 데이터가 파티션에 골고루 분산됨
  ※ PK 값이 편중되면 특정 파티션에 트래픽 집중 → 핫 파티션(Hot Partition) 문제 발생

키 설계 원칙

[DynamoDB 키 설계 철학]

  RDB 방식:                    DynamoDB 방식:
  ────────────────             ──────────────────────
  1. 엔티티 도출                1. 쿼리 패턴 먼저 나열
  2. 정규화                    2. Access Pattern 문서화
  3. 관계 정의                 3. PK/SK를 쿼리에 맞춰 설계
  4. 쿼리 작성                 4. 하나의 테이블에 모두 담기
     (쿼리는 나중에)              (Single-Table Design)

  ※ RDB처럼 "먼저 만들고 나중에 쿼리한다"가 불가능함
  ※ JOIN이 없으므로 조회에 필요한 모든 데이터를 한 Item에 포함하거나
    같은 PK로 묶어 한 번의 Query로 가져오도록 설계함

03. DynamoDB 용량 모드

DynamoDB 읽기·쓰기 용량을 관리하는 두 가지 모드

[On-Demand Mode — 트래픽 자동 대응]

  요청 발생 → DynamoDB가 자동으로 용량 처리
  → 사용한 만큼만 과금 (RCU/WCU 단위)
  → 트래픽 급증 시 자동 확장 (Throttle 없음)
  → 예측 불가 트래픽·신규 서비스에 적합

  비용: 읽기 $0.25/1M RRU, 쓰기 $1.25/1M WRU (ap-northeast-2)

[Provisioned Mode — 용량 사전 설정]

  읽기/쓰기 용량(RCU, WCU)을 직접 설정
  → 설정된 용량 초과 시 Throttle 발생 (ProvisionedThroughputExceededException)
  → Auto Scaling 설정으로 자동 조정 가능
  → 예측 가능한 안정적 트래픽에 적합 (Reserved Capacity로 비용 절감 가능)

RCU / WCU 계산

[RCU/WCU 계산 예시]

  시나리오: 항목 크기 8KB, 초당 100회 읽기 (강한 일관성)

  RCU = ceil(8KB / 4KB) × 100회 = 2 × 100 = 200 RCU 필요

  시나리오: 항목 크기 3KB, 초당 50회 쓰기

  WCU = ceil(3KB / 1KB) × 50회 = 3 × 50 = 150 WCU 필요

ElastiCache

01. 캐시(Cache)와 ElastiCache 개념

캐시(Cache)

• 자주 사용되는 데이터를 빠른 저장소(메모리)에 임시 저장해 DB 부하를 줄이고 응답 속도를 높이는 기술

Amazon ElastiCache

• Valkey / Redis OSS / Memcached 엔진을 완전 관리형으로 제공하는 AWS 인메모리 캐시 서비스

[캐시 없는 구조 — DB 부하 문제]

  사용자 100명이 동시에 "인기 상품 목록" 요청
        │
        ▼
  애플리케이션 서버
        │ 100번 동일 쿼리 실행
        ▼
  RDS / DynamoDB ← 과부하 발생, 응답 느림, 비용 증가
  (디스크 기반 → 수십 ms 응답)

---
[캐시 적용 후 — DB 부하 해소]

  사용자 100명이 동시에 "인기 상품 목록" 요청
        │
        ▼
  애플리케이션 서버
        │
        ├── ElastiCache 확인 (캐시 HIT) → 즉시 반환 (< 1ms)
        │                                  99번의 DB 쿼리 차단됨
        └── ElastiCache 없음 (캐시 MISS) → DB 조회 → 캐시 저장 → 반환
              (최초 1번만 DB 조회)

02. ElastiCache 운영 모드 — Serverless vs Self-Designed

• ElastiCache는 두 가지 운영 모드를 지원
• 트래픽 예측 가능성과 운영 복잡도 허용 수준에 따라 선택

[Serverless Cache — 자동 확장, 운영 부담 제로]

  사용자 설정: 캐시 이름 입력 + 엔진 선택
                      │
                      ▼
  ElastiCache Serverless가 자동으로:
  ├── 용량 자동 조정 (메모리·CPU·네트워크)
  ├── Multi-AZ 자동 구성
  ├── 패치·업그레이드 자동 적용
  └── 단일 Endpoint 제공

  과금: 저장 데이터(GB-hour) + 처리 요청(ECPU)
  Valkey Serverless 최소: $6/월 (100MB부터)
  → 개발·스타트업·예측 불가 트래픽에 최적

[Self-Designed Cluster — 세밀한 제어 가능]

  사용자가 직접:
  ├── 노드 타입 선택 (cache.r7g.large 등)
  ├── 샤드(Shard) 수 설정
  ├── Replica 수 설정
  └── AZ 배치 설정

  과금: 노드 시간당 과금
  → 예측 가능한 고성능 워크로드, 비용 최적화 가능

03. 캐싱 전략

ElastiCache 적용 시 어떤 패턴으로 캐시를 읽고 쓸지 결정하는 전략

[Cache-Aside (Lazy Loading) — 가장 일반적]

  읽기 요청
      │
      ▼
  ElastiCache 조회
  ├── HIT → 데이터 반환 (DB 조회 없음)
  └── MISS
          │
          ▼
       DB 조회
          │
          ▼
       ElastiCache에 저장 (TTL 설정)
          │
          ▼
       데이터 반환

  장점: DB 부하 최소화, 필요한 데이터만 캐시
  단점: 최초 MISS 시 응답 지연, 캐시-DB 데이터 불일치 가능
  적용: 상품 목록, 사용자 프로필, API 응답 캐시

[Write-Through — 쓰기 시 즉시 캐시 갱신]

  쓰기 요청
      │
      ├──► DB 저장
      └──► ElastiCache 저장 (동시에)

  장점: 캐시 항상 최신 상태 유지
  단점: 쓰기 지연 증가, 캐시 공간 낭비 가능 (읽히지 않는 데이터도 캐시)
  적용: 읽기 빈도 높고 데이터 신선도 중요한 경우

[Write-Behind (Write-Back) — 캐시 먼저, DB는 나중에]

  쓰기 요청
      │
      ▼
  ElastiCache 저장 (즉시 응답)
      │
      ▼ (비동기, 나중에)
  DB 저장

  장점: 매우 빠른 쓰기 응답
  단점: 캐시 장애 시 데이터 손실 위험
  적용: 게임 점수, 좋아요 수 등 손실 허용 가능한 데이터

TTL (Time To Live) 설정

[TTL 설계 원칙]

  TTL 너무 짧음:
  → 캐시 MISS 빈번 → DB 부하 증가 → 캐시 의미 없음

  TTL 너무 길음:
  → 오래된 데이터 제공 → 사용자에게 잘못된 정보 노출

  적정 TTL 기준:
  ├── 거의 변하지 않는 데이터 (카테고리, 설정): 1시간~24시간
  ├── 자주 조회되지만 가끔 변하는 데이터 (상품 상세): 5분~1시간
  ├── 실시간성 중요한 데이터 (재고, 가격): 30초~5분
  └── 세션 데이터: 세션 만료 시간과 동일하게

04. ElastiCache 접속 경로

[왜 로컬 PC에서 직접 접속이 안 되는가]

  ElastiCache(Valkey/Redis)는 DynamoDB와 달리:
  ├── VPC 내부 Private 리소스 (Public Endpoint 없음)
  ├── 6379 포트는 VPC 내부에서만 열림
  └── 인터넷에서 직접 접근 불가 (AWS 보안 설계 원칙)

  따라서 접속 경로는 반드시 VPC 내부 EC2를 경유함:

  ┌────────────────────────────────────────────┐
  │  로컬 PC (Termius / Redis Insight)      │
  └──────────────────┬─────────────────────────┘
                     │ SSH (22) + Port Forwarding (6379)
                     ▼
  ┌────────────────────────────────────────────┐
  │  EC2 Bastion (mylab-bastion)           │
  │  └── valkey-cli (CLI 실습)              │
  └──────────────────┬─────────────────────────┘
                     │ TLS 6379 (VPC 내부 Private 통신)
                     ▼
  ┌────────────────────────────────────────────┐
  │  ElastiCache Valkey Serverless         │
  │  mylab-valkey-cache.serverless.apn2..  │
  └────────────────────────────────────────────┘

01. RDS

• Amazon RDS(Relational Database Service)는 AWS가 데이터베이스 인프라의 운영·관리를 대신 처리하는 완전 관리형(Managed) 관계형 데이터베이스 서비스

02. 엔진

주요 엔진 비교

03. Multi-AZ — 고가용성 구성 3가지 방식

RDS를 여러 가용 영역(AZ)에 걸쳐 배포하여 AZ 장애 시 자동 Failover를 제공하는 고가용성 구성

[Single-AZ — SPOF 존재]

  ap-northeast-2a
  ┌─────────────┐
  │ RDS Primary│ ← 이 AZ 장애 시 전체 서비스 중단
  └─────────────┘

---
[Multi-AZ Instance — 전통적 Active-Standby]

  ap-northeast-2a               ap-northeast-2c
  ┌─────────────┐  동기 복제   ┌──────────────┐
  │  Primary   │ ──────────►  │  Standby    │
  │ (읽기/쓰기) │              │  (대기 전용) │
  └─────────────┘              └──────────────┘
        │
        │ AZ-a 장애 발생 시
        ▼
  DNS Failover (60~120초)
        │
        ▼
  Standby → Primary로 자동 승격

---
[Multi-AZ Cluster — 더 빠른 Failover]

  ap-northeast-2a     ap-northeast-2b     ap-northeast-2c
  ┌───────────┐       ┌───────────┐       ┌───────────┐
  │  Writer  │──────►│  Reader 1 │       │  Reader 2 │
  │(읽기/쓰기)│       │ (읽기 가능)│       │ (읽기 가능)│
  └───────────┘       └───────────┘       └───────────┘
  Writer 장애 시 → Reader 중 하나가 Writer로 승격 (수 초 내)

Multi-AZ 방식 비교

04. 백업 & 복구 — Blue/Green Deployment

Blue/Green Deployment

[Blue/Green Deployment — 무중단 메이저 버전 업그레이드]

  Blue 환경 (현재 프로덕션)        Green 환경 (신규 버전)
  ┌──────────────────┐             ┌──────────────────┐
  │ RDS MySQL 8.0.x │  ──복제──►  │ RDS MySQL 8.4    │
  │ (현재 서비스 중)  │            │ (검증 단계)       │
  └──────────────────┘             └──────────────────┘
           │                                │
           │  검증 완료 후 Switchover 실행    │
           ▼                                ▼
  Blue → Standby 전환            Green → 프로덕션 전환
  (문제 발생 시 수 초 내 롤백 가능)

Spring Boot에서 단일 RDS 연결

01. 개념

• 구축한 RDS에 Spring Boot 애플리케이션이 접속 및 연결 성공 검증
• RDS가 Private Subnet에 있기 때문에 로컬 PC에서 직접 접근 불가

[로컬 PC Spring Boot]
        │
        ↓ localhost:3307
[SSH Tunnel Process]
        │
        ↓ 암호화된 SSH 세션
[Bastion EC2] (Public Subnet)
        │
        ↓ VPC 내부 통신 3306
[RDS] (Private Subnet)

실습

터널링을 이용하여 RDS에 접속하고 Postman을 이용하여 DB 테스트

Read Replica 생성 및 콘솔 확인

01. 개념

• 읽기 트래픽이 증가하면 Primary에 부하가 집중되어 전체 성능이 저하
• Read Replica는 Primary의 복제본으로, SELECT 쿼리를 분산 처리하여 Primary의 쓰기 성능을 보호

[기존 구조]
                   ┌──────────────────┐
   App ─ SELECT/ ─►│ Primary (Writer)│
          INSERT   └──────────────────┘

[Read Replica 추가 후]
                   ┌──────────────────┐
   App ─ INSERT ──►│ Primary (Writer)│──┐
                   └──────────────────┘  │ 비동기 binlog 복제
                                       ▼
                   ┌──────────────────┐
   App ─ SELECT ──►│ Replica (Reader)│
                   └──────────────────┘

Spring Boot Writer/Reader DataSource 분리

01. 개념

• 단일 DataSource로 RDS 연결에 성공, Read Replica 복제 동작을 검증 완료
• 쓰기는 Writer, 읽기는 Reader로 분리

[Spring Boot]
     │
     ├─ @Transactional              → WriterDataSource → Primary
     │  (INSERT/UPDATE/DELETE)
     │
     └─ @Transactional(readOnly=true) → ReaderDataSource → Read Replica
        (SELECT)

02. HikariCP 개념 및 핵심 파라미터

HikariCP란

• Spring Boot 2.x 이상의 기본 JDBC 커넥션 풀. 커넥션을 미리 생성해 풀에 보관하고, 요청 시 대여·반납하는 방식으로 매 요청마다 TCP handshake + MySQL 인증 비용(50~200ms)을 제거

[커넥션 풀 없음]
  HTTP 요청 → 새 커넥션 생성(50~200ms) → 쿼리 → 연결 해제
             ↑ 매번 오버헤드

[HikariCP 풀링]
  App 시작 시 → 커넥션 N개 미리 생성 → Pool 보관
  HTTP 요청 → Pool에서 대여(수 ms) → 쿼리 → Pool 반납
             ↑ 오버헤드 없음

핵심 파라미터

RDS Proxy 도입 + Spring Boot 엔드포인트 전환

• Lambda·ECS Fargate처럼 짧게 생성·소멸되는 컨테이너가 급증하는 환경에서는 여전히 문제
• RDS Proxy는 이 문제를 해결하는 커넥션 풀 중앙 관리 계층

[Proxy 없는 구조]
  ECS Task × 50 (HikariCP ×5)        RDS Primary
  ┌─────────────────────┐             ┌────────────────────┐
  │ 각 태스크 × 5 커넥션│ ──────────►  │ 250개 요청         │
  │ 총 250개 요청      │             │ max_connections 66│
  └─────────────────────┘             │ → 초과 장애        │
                                    └────────────────────┘

[Proxy 도입 구조]
  ECS Task × 50         RDS Proxy              RDS Primary
  ┌────────────┐        ┌────────────────┐    ┌─────────────┐
  │HikariCP ×5│ ──────► │ 연결 풀 관리   │──► │ 실제 연결 30 │
  │ 250 요청   │        │(Multiplexing)│    │ 한도 이내    │
  └────────────┘        └────────────────┘    └─────────────┘
                        ↑ 여러 앱 연결을 소수 DB 연결로 묶음

RDS Proxy 주요 기능

Amazon DynamoDB

01. DynamoDB를 선택하는 기준

• DynamoDB는 키-값(Key-Value) 및 문서(Document) 방식의 완전 관리형 NoSQL 데이터베이스 서비스

[RDB(RDS MySQL) vs NoSQL(DynamoDB) 구조 차이]

  RDB — 정형 스키마, 다중 테이블 JOIN
  ┌──────────┐     JOIN    ┌──────────┐
  │ orders  │  ──────────► │ products │
  │ id  PK  │             │ id  PK   │
  │ user_id │             │ name     │
  │ prod_id │             │ price    │
  └──────────┘             └──────────┘
  → 스키마 변경 시 ALTER TABLE 필요
  → 수평 확장(Scale-Out)이 어려움
  → 복잡한 쿼리와 트랜잭션에 유리

---
  DynamoDB — 유연한 스키마, 단일 테이블 설계
  ┌────────────────────────────────────────────┐
  │                   Orders               │
  │ PK(pk)          SK(sk)      attributes │
  │ USER#u001       ORDER#o001  {상품, 수량}│
  │ USER#u001       ORDER#o002  {상품, 수량}│
  │ PRODUCT#p001    META        {이름, 가격}│
  │ ORDER#o001      STATUS      {CONFIRMED}│
  └────────────────────────────────────────────┘
  → 스키마 변경 없이 속성 추가 가능
  → 수평 확장 자동 처리 (파티션 자동 분산)
  → 단순 조회 패턴, 대규모 트래픽에 유리

선택 기준 비교

02. PK / SK / GSI / LSI / 파티션

DynamoDB의 모든 데이터 모델링은 기본 키(Primary Key) 설계에서 시작

[DynamoDB 기본 키 2가지 유형]

  단순 기본 키 (Simple Primary Key)
  → 파티션 키(PK, Partition Key) 하나만 사용
  → 파티션 키 값이 고유해야 함
  → 예: 사용자 테이블에서 userId가 PK

  복합 기본 키 (Composite Primary Key)
  → 파티션 키(PK) + 정렬 키(SK, Sort Key) 조합
  → PK가 같아도 SK가 다르면 다른 항목으로 저장됨
  → 예: 주문 테이블에서 userId(PK) + orderId(SK)

  PK의 역할 — 파티션 결정
  ┌──────────────────────────────────────────────────┐
  │  PK 값 → 내부 해시 함수 → 저장 파티션 결정        │
  │                                              │
  │  Partition 1    Partition 2    Partition 3   │
  │  [USER#u001]    [USER#u002]    [USER#u003]   │
  │  ORDER#o001     ORDER#o003     ORDER#o005    │
  │  ORDER#o002     ORDER#o004     ORDER#o006    │
  └──────────────────────────────────────────────────┘
  → 같은 PK를 가진 항목들은 같은 파티션에 SK 순서로 정렬 저장됨
  → 핫 파티션(Hot Partition) 방지를 위해 PK 값을 분산시켜야 함

TransactWriteItems - 주문 + 재고 트랜잭션

• 주문 생성과 동시에 재고 차감을 하나의 트랜잭션으로 묶어서 둘 중 하나라도 실패하면 전체 롤백 확인

트랜잭션 비교

[일반 쓰기 - 위험]
  주문 생성 (성공) → 재고 차감 시도 (실패) → 데이터 불일치

[TransactWriteItems - 안전]
  주문 + 재고 차감을 하나의 트랜잭션으로 묶음
  조건 검증 통과 → 둘 다 적용
  조건 검증 실패 → 둘 다 롤백

DynamoDB Streams + Lambda 트리거

• DynamoDB 항목이 변경될 때마다 Lambda가 자동 실행되어 CloudWatch Logs에 이벤트 이력을 기록하는 이벤트 드리븐 파이프라인을 구축

Amazon ElastiCache (Valkey)

01. DB 부하 문제와 인메모리 캐시의 역할

개념

• 웹 서비스에서 동일한 데이터를 DB에서 반복적으로 조회하면 DB 부하가 증가하고 응답 시간이 길어짐

[캐시 없는 구조 — DB 병목 발생]

  사용자 1000명이 동시에 상품 목록 조회 요청
        │
        ▼
  Spring Boot 애플리케이션
        │ 1000번 쿼리 발생
        ▼
  RDS MySQL ← CPU 100%, 응답 지연, 타임아웃 발생

---
[캐시 도입 후 — DB 부하 분산]

  사용자 1000명이 동시에 상품 목록 조회 요청
        │
        ▼
  Spring Boot 애플리케이션
        │
        ├── Cache HIT (900명): ElastiCache Valkey에서 즉시 응답 (< 1ms)
        │
        └── Cache MISS (100명): RDS MySQL 조회 후 캐시 저장
                                 RDS: 100번 쿼리만 처리 → 부하 90% 감소

[성능 차이]

  RDS MySQL 조회:    1ms ~ 수십 ms (디스크 I/O 포함)
  ElastiCache 조회:  수십 μs ~ 1ms (메모리에서 즉시 반환)

02. Serverless vs Self-Designed Cluster

개념

• ElastiCache는 인프라 관리 방식에 따라 두 가지 배포 옵션을 제공
• 신규 서비스에서는 Serverless 방식이 기본 권장 옵션

[Serverless 방식]

  장점:
  ├── 1분 이내 생성 완료
  ├── 용량 자동 조정 (트래픽 증감에 따라 자동 확장/축소)
  ├── 별도의 노드 타입 선택 불필요
  ├── 최소 비용: $6/월 (100MB 데이터 기준)
  └── Multi-AZ HA 자동 적용

  단점:
  ├── 노드 타입 직접 선택 불가
  └── 대규모 고정 트래픽에서는 Self-Designed 대비 비용이 높을 수 있음

[Self-Designed Cluster 방식]

  장점:
  ├── 노드 타입, 노드 수, 복제 그룹 구성을 직접 제어
  ├── 대규모 고정 트래픽에서 Reserved Nodes로 비용 최적화 가능
  └── 클러스터 모드(Cluster Mode) 활성화로 수평 확장 가능

  단점:
  ├── 노드 타입 선택, 클러스터 설계 필요
  └── 용량 부족 시 수동으로 Scale-Out 필요

[선택 기준]

  신규 서비스 / 트래픽 예측 불가     → Serverless 권장
  대규모 안정적 트래픽 / 비용 최적화  → Self-Designed + Reserved Nodes

03. 캐싱 전략

Cache-Aside / Write-Through / Write-Behind / Read-Through

• 캐시를 어떻게 채우고 갱신할지 결정하는 전략
• 서비스의 데이터 특성과 일관성 요구사항에 따라 적합한 전략을 선택

[1. Cache-Aside (Lazy Loading) — 가장 일반적인 패턴]

  읽기 요청
       │
       ▼
  캐시에 데이터 있음? (Cache HIT)
       ├── YES → 캐시에서 즉시 반환
       └── NO  → DB 조회 → 캐시에 저장 → 반환 (Cache MISS)

  특징:
  → 실제 읽히는 데이터만 캐시에 저장됨 (효율적)
  → DB 장애 시에도 캐시로 서비스 일부 유지 가능
  → 최초 요청(Cold Start) 시 Cache MISS 발생

---
[2. Write-Through — 쓰기 시 캐시 동시 갱신]

  쓰기 요청 → DB 저장 AND 캐시 갱신 (동시 수행)

  특징:
  → 캐시가 항상 최신 상태 유지됨
  → 쓰기 작업마다 캐시를 갱신하므로 쓰기 비용 증가
  → 거의 조회되지 않는 데이터도 캐시에 저장됨 (비효율)

---
[3. Write-Behind (Write-Back) — 비동기 DB 저장]

  쓰기 요청 → 캐시 먼저 저장 → 비동기로 나중에 DB에 저장

  특징:
  → 쓰기 응답이 매우 빠름
  → 캐시 장애 시 데이터 유실 위험 (내구성 낮음)
  → 쓰기가 매우 빈번한 서비스(IoT, 게임 점수)에 적합

---
[4. Read-Through — 캐시가 DB 조회를 대행]

  읽기 요청 → 캐시 미스 시 캐시가 직접 DB 조회 후 저장 → 반환

  특징:
  → 애플리케이션 코드에서 DB 직접 조회 로직 불필요
  → Cache-Aside와 유사하나, 캐시 라이브러리가 자동 처리
  → Spring의 @Cacheable 어노테이션이 이 패턴과 유사하게 동작

캐싱 전략 비교

04. SSH 터널링 설정 (로컬 PC → ElastiCache)

• ElastiCache Serverless는 Private Subnet에만 배치되므로 로컬 PC에서 직접 접근 불가
• Bastion EC2를 통한 SSH 터널로 로컬 6379 포트를 ElastiCache로 포워딩

[SSH 터널 구조]

로컬 PC (STS4)
   │
   │  localhost:6379로 접속
   ▼
SSH 터널 (로컬 터미널에서 유지)
   │
   │  Bastion EC2 경유
   ▼
ElastiCache Serverless (Private Subnet)
   mylab-valkey-cache-xxxxxx.serverless.apn2.cache.amazonaws.com:6379

실습 1. Cache-Aside 패턴 + Sorted Set 랭킹

• 전자상거래 상품 조회 API에 ElastiCache Valkey를 도입하여 DB 부하를 줄이고, Sorted Set으로 실시간 조회 랭킹을 구현

실습 2. JWT 인증 + ElastiCache 토큰 저장소

• Spring Security + JWT 기반 인증 API를 구현하고, ElastiCache Valkey를 Refresh Token 저장소와 Access Token 블랙리스트로 활용

전체 구조

[클라이언트]
     │
     │  POST /auth/login
     ▼
[Spring Boot - JWT 인증 서버]
     │
     ├── JwtAuthenticationFilter      모든 요청에서 Access Token 검증
     │     └── TokenStoreService      블랙리스트 조회
     │
     ├── AuthController
     │   ├── POST /auth/register      회원가입
     │   ├── POST /auth/login         Access + Refresh 발급
     │   ├── POST /auth/refresh       토큰 갱신 (Rotation)
     │   └── POST /auth/logout        토큰 무효화
     │
     └── 보호된 API
         └── GET /api/me              인증된 사용자만 접근

[ElastiCache Valkey - 토큰 저장소]
     │
     ├── Refresh Token 저장
     │   키: "refresh:{email}"
     │   값: Refresh Token 문자열
     │   TTL: 7일
     │
     └── Access Token 블랙리스트
         키: "blacklist:{jti}"
         값: "revoked"
         TTL: Access Token 남은 유효 시간

실습 3. Redisson 분산 락 + ElastiCache

• 다중 서버 환경에서 동시 요청이 몰릴 때 발생하는 Race Condition을 Redisson 분산 락으로 해결

Race Condition (경쟁 조건)

[재고 1개 상품에 동시 주문 2건 발생]

  EC2 인스턴스 A                      EC2 인스턴스 B
  ─────────────────────────────────────────────────
  1. SELECT stock = 1 조회             1. SELECT stock = 1 조회
  2. (재고 있음 확인)                   2. (재고 있음 확인)
  3. UPDATE stock = 0                  3. UPDATE stock = 0
  4. 주문 완료 처리                     4. 주문 완료 처리

  → 두 인스턴스 모두 주문 완료
  → 재고가 1개인데 2개 판매 (데이터 정합성 파괴)

분산 락 구성 요소

Watchdog 패턴

[Watchdog 없이 TTL 30초로 락 획득 후 35초 작업 시]

  락 획득 (TTL 30초)
       │
       │── 30초 경과 → TTL 만료 → 락 자동 해제 (조기 해제)
       │── 다른 프로세스 락 획득 가능
       ▼
  35초 시점 작업 완료 → unlock 시도 → 예외 발생

[Watchdog 적용 시 (Redisson lock())]

  락 획득 (TTL 30초) + Watchdog 시작
       │
       │── 10초마다 Watchdog이 TTL을 30초로 갱신
       │── 20초 경과 → TTL 30초로 갱신
       │── 30초 경과 → TTL 30초로 갱신
       ▼
  35초 시점 작업 완료 → unlock → 정상 해제

[프로세스 장애 시]

  Watchdog도 함께 종료 → TTL 갱신 중단 → 30초 후 자동 해제
  → Deadlock 방지

실습 4. Spring Session 클러스터링 + ElastiCache

• 단일 서버 JVM 메모리에 저장되던 HTTP 세션을 ElastiCache Valkey로 외부화하여 다중 인스턴스 환경에서 세션을 공유

Sticky Session vs Clustering

[Sticky Session - 서버 고정 방식]

  사용자 A ─→ ALB (쿠키 기반 고정) ─→ 항상 인스턴스 1로 라우팅
  사용자 B ─→ ALB (쿠키 기반 고정) ─→ 항상 인스턴스 2로 라우팅

  장점: 구현 간단 (ALB 설정만 변경)
  단점: 특정 서버 부하 집중, 서버 장애 시 세션 유실,
        Rolling Update 시 세션 유실, Auto Scaling 부적합

[Session Clustering - ElastiCache 공유 방식]

  사용자 A의 요청
       │
       ▼
  ALB (부하 분산)
  ├──→ 인스턴스 1 ─→ ElastiCache 세션 조회 ─→ Session
  ├──→ 인스턴스 2 ─→ ElastiCache 세션 조회 ─→ Session
  └──→ 인스턴스 3 ─→ ElastiCache 세션 조회 ─→ Session
                         ↑
                    모든 인스턴스가 동일 세션 접근

  장점: 서버 장애 시에도 세션 유지, Auto Scaling 즉시 적용,
        무중단 배포 가능, 확장성 우수
  단점: ElastiCache 의존성, 네트워크 조회 비용

Spring Session 내부 동작

[@EnableRedisHttpSession 적용 시]

   HTTP 요청 (Cookie: JSESSIONID=abc123)
        │
        ▼
   SessionRepositoryFilter (자동 등록, 가장 앞에 위치)
        │
        ├── 쿠키에서 세션 ID 추출
        ├── Redis 조회: HGETALL spring:session:sessions:abc123
        ├── HttpSession으로 래핑
        └── lastAccessedTime 갱신 후 Redis 저장
        │
        ▼
   Spring Security FilterChain → 컨트롤러

[Redis 저장 키 구조 (기본 namespace: spring:session)]

   ① 세션 데이터 (Hash)
   spring:session:sessions:{sessionId}
      sessionAttr:SPRING_SECURITY_CONTEXT   {직렬화된 인증 객체}
      creationTime                           1713254400000
      lastAccessedTime                       1713254460000
      maxInactiveInterval                    1800

   ② 세션 만료 키 (String + TTL)
   spring:session:sessions:expires:{sessionId}
   → TTL 1800 (30분)

   ③ 만료 인덱스 (Set, 주기적 정리용)
   spring:session:expirations:{만료 버킷}

이번 주는 AWS의 고가용성과 S3 스토리지를 스트링 부트와 연결하여 활용하는 것 까지 배웠다.

Route 53

01. DNS

DNS(Domain Name System)는 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환하는 인터넷 전화번호부

DNS 쿼리 전체 흐름

사용자 브라우저: "도메인" 입력
      │
      ▼
① 로컬 캐시 확인
   브라우저 캐시 → OS 캐시 → /etc/hosts 파일
   → 캐시 없으면 다음 단계
      │
      ▼
② DNS Resolver (재귀 조회 시작)
   ISP 제공 또는 8.8.8.8, 1.1.1.1
   클라이언트를 대신해 DNS 조회 수행
      │
      ▼
③ Root DNS 서버 조회
   ".kr을 담당하는 TLD NS 주소 응답"
      │
      ▼
④ TLD DNS 서버 조회 (.kr)
   "mylab.kr을 담당하는 Authoritative NS 응답"
      │
      ▼
⑤ Authoritative DNS 서버 (Route 53)
   "shop.mylab.kr의 IP는 <CloudFront IP>" 응답
      │
      ▼
⑥ DNS Resolver → 클라이언트에 IP 전달
   TTL 시간 동안 캐시 후 전달
      │
      ▼
⑦ 브라우저가 IP로 HTTP/S 요청 전송

02. Route 53

AWS의 완전 관리형 권위 있는 DNS 서비스

Route 53의 4가지 핵심 기능

① 도메인 등록 (Domain Registration)
   .com / .kr 등 도메인 직접 구매·관리.
   가비아 등 외부 등록 기관에서 구매한 도메인도 연동 가능.

② DNS 라우팅 (DNS Routing)
   Hosted Zone에 레코드를 설정하여 도메인 → IP 매핑.

③ 상태 확인 (Health Check)
   엔드포인트 정상 여부를 주기적으로 모니터링.
   장애 감지 시 다른 엔드포인트로 자동 전환.

④ 프라이빗 DNS (Private DNS)
   VPC 내부에서만 해석되는 내부 DNS 이름 관리.

Hosted Zone Route 53에서 하나의 도메인에 대한 DNS 레코드 모음

03. DNS 레코드 타입 정리

CNAME vs Alias

CNAME의 한계: Zone Apex(루트 도메인)에 사용 불가

실습

CloudFront

01. CDN

전 세계 분산된 서버(Edge)에 콘텐츠를 캐싱하여 사용자에게 가장 가까운 위치에서 빠르게 응답하는 분산 콘텐츠 전송 네트워크

[ CDN 없는 경우 ]
한국 사용자 ───────────────────────────────▶ 서울 EC2 (20ms)
미국 사용자 ───────────────── 약 200ms ────▶ 서울 EC2 (Origin 직접 요청)

[ CloudFront 있는 경우 ]
한국 사용자 ──▶ 서울 Edge (캐시 있으면 5ms)
미국 사용자 ──▶ 미국 Edge (캐시 있으면 10ms)
                        Cache Miss 시에만 → 서울 EC2(Origin)에서 가져와 Edge에 저장

02. 핵심 구성요소

03. ACM

AWS에서 SSL/TLS 인증서를 무료로 발급·갱신·관리해주는 서비스

동작 흐름

도메인 소유자
    │
    ▼
ACM에서 인증서 요청
    │
    ├─ DNS 검증 (권장) : Route 53에 CNAME 레코드 자동 추가
    └─ 이메일 검증   : 도메인 등록 이메일로 확인 링크 전송
    │
    ▼
인증서 발급 완료
    │
    ▼
ALB / CloudFront 리스너에 연결
    │
    ▼
HTTPS 트래픽 처리

정적 파일 CloudFront 구성 - 아키텍처

사용자
  │ https://도메인
  ▼
Route 53 (Alias → CloudFront)
  │
  ▼
CloudFront Distribution
  │ SSL/TLS 종료 (ACM 인증서)
  │ HTTP → HTTPS 리다이렉트
  │ Behavior: /* → S3 (캐시 ON)
  ▼
S3 Bucket (비공개 유지)
  ↑ OAC로만 접근 허용. 직접 URL 접근 → 403

정리

내용 요약

① CDN 원리
   전 세계 Edge Location에 콘텐츠 캐싱.
   Cache Hit → Edge에서 즉시 응답. Origin 부하 없음.
   Cache Miss → Origin에서 가져와 Edge에 저장 후 응답.

② CloudFront 구성요소
   Distribution / Origin / Behavior / Cache Policy / OAC.

③ Behavior 핵심
   /api/* → CachingDisabled (동적 API)
   /*     → CachingOptimized (정적 파일)
   더 구체적인 패턴이 우선 적용.
   동적 API에 캐시 실수 적용 시 → 다른 사용자 데이터 노출 가능.

④ OAC (최신 방식)
   S3 버킷 퍼블릭 오픈 없이 CloudFront만 접근 허용.
   Bucket Policy에 CloudFront 서비스 주체 명시.

⑤ ACM + HTTPS
   CloudFront용 인증서는 us-east-1에서 발급.
   DNS 검증으로 자동 갱신.

⑥ Invalidation
   Edge 캐시 강제 삭제. 배포 시 /* 실행.
   CI/CD 파이프라인에서 자동화하는 것이 실무 표준.

실습

전체 구성요소 통합 아키텍처

사용자 브라우저 (https://도메인)
      │
      ▼
① Route 53
   도메인 → Alias → CloudFront
   Failover: Primary(EC2) 장애 시 Secondary(S3 점검 페이지) 자동 전환
      │
      ▼
② CloudFront Distribution
   Edge Location에서 캐시 응답
   ACM 인증서 (us-east-1) → HTTPS 종료
   HTTP → HTTPS 자동 리다이렉트
      │
      ├── Behavior: /*      → S3 (정적, 캐시 ON)
      │         ▼
      │    ③ S3 Bucket (OAC 적용, 퍼블릭 차단)
      │
      └── Behavior: /api/*  → EC2 (동적, 캐시 OFF)
                ▼
┌─────────────────────────────────────────────────────────────────────┐
│  VPC: shop-vpc (10.10.0.0/16)                                       │
│                                                                     │
│  ④ Internet Gateway: shop-igw                                       │
│      │                                                              │
│  AZ: ap-northeast-2a             AZ: ap-northeast-2c                │
│  ┌────────────────────────┐  ┌──────────────────────────────────┐   │
│  │  Public 10.10.1.0/24   │  │  Public 10.10.2.0/24             │   │
│  │  [NAT GW-2a + EIP]     │  │  [NAT GW-2c + EIP]               │   │
│  └────────────────────────┘  └──────────────────────────────────┘   │
│                                                                     │
│  ⑤ NACL — 서브넷 경계 방화벽 (Stateless)                             │  
│                                                                     │
│  ┌────────────────────────┐  ┌──────────────────────────────────┐   │
│  │  Private 10.10.3.0/24  │  │  Private 10.10.4.0/24            │   │
│  │  ⑥ EC2: App (sg-app)   │  │  ⑥ EC2: App (sg-app) [이중화]    │   │
│  └──────────┬─────────────┘  └────────────────┬─────────────────┘   │
│             │ sg-db: 3306                     │                     │
│  ┌──────────▼─────────────────────────────────▼──────────────────┐  │
│  │  Isolated 10.10.5.0/24   /   Isolated 10.10.6.0/24            │  │
│  │  ⑦ RDS MySQL (Primary)       RDS MySQL (Standby)              │  │
│  │     db.internal.mylab.kr → Private Hosted Zone ㅍ             │  │
│  └───────────────────────────────────────────────────────────────┘  │
│                                                                     │
│  ⑧ VPC Flow Logs → CloudWatch (CH03)                                │
└─────────────────────────────────────────────────────────────────────┘

Security Group 체계 :
  sg-alb     : 80/443  ← 0.0.0.0/0
  sg-app     : 8080    ← sg-alb 참조 / SSH 22 ← sg-bastion 참조
  sg-db      : 3306    ← sg-app 참조
  sg-bastion : 22      ← 관리자 IP/32

Route Table 체계 :
  public-rt      → 0.0.0.0/0 → IGW        (AZ-a, AZ-c 공통)
  private-rt-2a  → 0.0.0.0/0 → nat-gw-2a  (AZ-a 전용)
  private-rt-2c  → 0.0.0.0/0 → nat-gw-2c  (AZ-c 전용)
  isolated-db-rt → local만                 (AZ-a, AZ-c 공통)

VPC Peering

• 두 VPC 사이를 AWS 내부 백본 네트워크로 직접 연결하는 기능
• 인터넷을 경유하지 않으므로 트래픽이 외부에 노출되지 않음

[ 인터넷 경유 방식 — Peering 없음 ]

VPC-A (10.10.0.0/16)                   VPC-B (10.20.0.0/16)
  EC2-A ──── 공인 IP ────▶ 인터넷 ────▶ EC2-B
             (보안 위험, 데이터 전송 비용 발생)

[ VPC Peering 사용 ]

VPC-A (10.10.0.0/16)                   VPC-B (10.20.0.0/16)
  EC2-A ◀──────── AWS 내부 백본 ────────▶ EC2-B
                (인터넷 미경유, 사설 IP 통신)

AWS 내부 백본 네트워크

• AWS가 전 세계 리전과 데이터센터를 연결하기 위해 구축한 전용 고속 사설 네트워크
• 공용 인터넷과 물리적으로 분리된 전용선으로 구성됨

VPC Endpoint (PrivateLink)

• Private Subnet의 리소스가 인터넷을 경유하지 않고 AWS 서비스에 직접 접근하는 기능
• NAT Gateway나 Internet Gateway 없이 AWS 내부 네트워크로만 트래픽 처리

[ 기존 방식 — NAT Gateway 경유 ]

Private EC2 ──▶ NAT GW ──▶ Internet ──▶ S3
                 (비용 발생: $0.059/GB)  (인터넷 노출)

[ VPC Endpoint 사용 ]

Private EC2 ──▶ VPC Endpoint ──▶ S3
                (AWS 내부망, 인터넷 미경유, 비용 절감)

Endpoint 유형 비교

01. 고가용성(HA) 핵심 개념

개념

• 장애가 발생해도 서비스가 계속 동작하도록 설계하는 것
• 핵심은 장애를 막는 것이 아니라, 장애를 가정하고 자동으로 복구되도록 설계하는 것

02. RTO / RPO — 복구 목표 지표

장애 대응 설계의 기준이 되는 두 가지 핵심 지표

[ RPO — Recovery Point Objective, 복구 시점 목표 ]

마지막 백업              장애 발생
    │                        │
────┼────────────────────────┼──→ 시간
    │◄─────── RPO ──────────►│
       데이터 손실 허용 최대치

[ RTO — Recovery Time Objective, 복구 시간 목표 ]

            장애 발생                   서비스 복구
                │                           │
────────────────┼───────────────────────────┼──→ 시간
                │◄─────── RTO ─────────────►│
                      서비스 중단 허용 최대치

03. Reliability Pillar — 5가지 설계 원칙

장애를 막는 것이 아니라, 장애를 가정하고 자동 복구되도록 설계하는 것이 핵심

1. 장애 복구 자동화    
── CloudWatch Alarm → Auto Scaling
KPI 임계값 초과 시 자동 교정

2. 복구 절차 테스트    
── RDS Failover 강제 실행
AWS FIS(Fault Injection Simulator)로 Chaos Engineering

3. 수평 확장           
── ALB + ASG Multi-AZ
큰 인스턴스 1개 → 작은 인스턴스 여러 개로 분산

4. 용량 추측 금지      
── Target Tracking Scaling Policy
실측 기반으로 인스턴스 수 자동 조정

5. 자동화로 변경 관리  
── IaC(CloudFormation / Terraform)
수동 콘솔 변경 금지, 코드 기반 변경만 허용

AWS 고가용성(HA) 아키텍처

01. Application Load Balancer (ALB)

Layer 7(HTTP/HTTPS) 에서 동작하는 완전 관리형 로드밸런서

                       인터넷
                         │
              [ALB — 퍼블릭 엔드포인트]
        my-alb-xxx.ap-northeast-2.elb.amazonaws.com
                         │
        ┌────────────────┼────────────────┐
        │  Listener:80   │                │
        ▼                ▼
  [Target Group]   (경로/호스트 기반 추가 라우팅 가능)
  Health Check 통과 인스턴스에만 트래픽 전달
        │
   ┌────┴────┐
   EC2-A     EC2-B
  (AZ-a)   (AZ-b)
  Private   Private
  Subnet    Subnet

ALB 핵심 구성 요소

ALB vs. NLB vs. CLB

02. Auto Scaling Group (ASG)

Launch Template을 기반으로 EC2 인스턴스 수를 자동으로 조절하는 서비스

3가지 스케일링 정책

03. ALB + ASG 연동 흐름

사용자 요청
    │
    ▼
[ALB Listener :80]
    │  헬스체크 통과한 대상에만 트래픽 전달
    ▼
[Target Group: ha-app-tg]
    ├── EC2-A (InService) (o)  8080
    └── EC2-B (InService) (o)  8080
         ↑
         │ ASG가 Target Group에 자동 등록·해제
         │
    [Auto Scaling Group: ha-app-asg]
    ├── Launch Template: ha-app-lt
    ├── Min:2 / Max:6 / Desired:2
    ├── Subnet: Private-2a, Private-2b
    └── Health Check: ELB  ← 중요

AWS Well-Architected Framework

01. WAF란 무엇인가

• AWS가 수천 개 고객 아키텍처 리뷰 경험을 체계화한 모범 사례 프레임워크
• "잘 설계된 시스템인가?"를 일관된 기준으로 평가하고 개선 방향을 제시하는 도구

기존 학습 내용과 WAF 6 Pillars 연결

계정 보안 및 관리
┌────────────────────────┐
│ IAM / MFA / KMS        │ ──→  Security Pillar
│ CloudTrail / Config    │ ──→  Operational Excellence
└────────────────────────┘

컴퓨팅
┌────────────────────────┐
│ EC2 / Auto Scaling     │ ──→  Reliability + Performance Efficiency
│ Lambda / ECS / Fargate │ ──→  Cost Optimization + Performance
│ Graviton (ARM64)       │ ──→  Sustainability
└────────────────────────┘

스토리지
┌────────────────────────┐
│ S3 / EBS / EFS         │ ──→  Reliability + Cost Optimization
│ S3 Lifecycle / IT      │ ──→  Cost Optimization + Sustainability
│ KMS 암호화             │ ──→  Security
└────────────────────────┘

네트워크
┌────────────────────────┐
│ VPC / SG / NACL        │ ──→  Security + Reliability
│ CloudFront / Route 53  │ ──→  Performance Efficiency
│ Multi-AZ 설계          │ ──→  Reliability
└────────────────────────┘

┌────────────────────────┐
│ CloudWatch / Alarm     │ ──→  Operational Excellence
│ ElastiCache            │ ──→  Performance Efficiency
│ Reserved / Spot        │ ──→  Cost Optimization
│ Carbon Footprint Tool  │ ──→  Sustainability
└────────────────────────┘

02. 6개 Pillar 전체 구조

03. 핵심 용어 정의

Security Pillar

01. Security Pillar 7대 설계 원칙

• AWS1(계정 보안 및 관리)에서 학습한 내용을 WAF Security Pillar 관점으로 재구성
• Security는 다른 Pillar와 절대 트레이드오프하지 않는 유일한 영역

1. 강력한 자격증명 기반     
── IAM / MFA / 최소 권한 원칙

2. 추적 가능성 확보         
── CloudTrail / Config / VPC Flow Logs

3. 모든 레이어 보안 적용    
── VPC SG / NACL / WAF / Shield

4. 보안 모범 사례 자동화    
── Config Rules / Security Hub
자동 규정 준수 평가

5. 전송·저장 데이터 보호    
── KMS / TLS / S3 암호화

6. 사람의 데이터 접근 최소화 
── 프로세스 기반 접근, 감사 추적
IAM Role 기반 서비스 간 접근

7. 보안 이벤트 대비        
── GuardDuty / Incident Playbook
위협 자동 탐지 및 대응

02. IAM 최소 권한 및 Access Analyzer

• IAM 정책 평가는 명시적 Deny → SCP Deny → 명시적 Allow 순으로 적용
• 어디에도 명시되지 않은 요청은 암묵적으로 거부됨(묵시적 Deny)

03. KMS + S3 암호화

S3 암호화 옵션 비교 및 KMS CMK(Customer Managed Key) 기반 감사 가능한 암호화 체계 구성

키 유형 비교

Operational Excellence Pillar

01. OE Pillar 5대 설계 원칙

비즈니스 가치를 창출하기 위해 시스템을 운영하고 모니터링하며 지속적으로 개선하는 능력

1. Operations as Code        
── CloudFormation / Terraform
인프라와 운영 절차를 코드로 정의

2. 잦은 소규모 변경          
── CI/CD 파이프라인
큰 배포 대신 작고 자주 배포

3. 운영 절차 지속 개선       
── Runbook / Playbook 정기 업데이트
장애 사후 분석(Blameless Postmortem)

4. 장애 예상                 
── AWS FIS (Fault Injection Simulator)
장애를 미리 시뮬레이션하여 대비

5. 모든 운영 실패에서 학습   
── CloudWatch + CloudTrail 통합 분석
장애를 비난 없이 학습 기회로 전환

02. AWS Config — 리소스 규정 준수

AWS 리소스 구성을 지속적으로 기록하고 규정 준수 여부를 자동 평가

AWS 리소스 변경 발생
    │
    ▼
Config 변경 감지 → Configuration History (S3 저장)
    │
    ▼
Config Rules 평가
    │
    ├── Compliant (규정 준수) → 정상
    └── Non-Compliant (위반) → SNS 알림 → 자동 교정 가능

Reliability Pillar

Reliability Pillar 5대 설계 원칙

• 의도한 기능을 정확히 수행하고 장애에서 빠르게 복구하는 능력
• 장애를 막는 것이 아니라, 장애를 가정하고 설계하는 것이 핵심

1. 장애 복구 자동화      
── CloudWatch Alarm → Auto Scaling
정상 상태 정의 후 자동 교정

2. 복구 절차 테스트      
── RDS Failover 강제 실행
AWS FIS (Fault Injection Simulator) — 고급

3. 수평 확장             
── ALB + ASG Multi-AZ
단일 AZ 장애 → 다른 AZ로 자동 트래픽 분산

4. 용량 추측 금지        
── Target Tracking Scaling Policy
실측 기반으로 인스턴스 수 자동 조정

5. 자동화 관리 변경      
── IaC (CloudFormation / Terraform)
수동 변경 금지, 코드 기반 변경만 허용

Performance Efficiency Pillar

01. PE Pillar 5대 설계 원칙

• 수요 변화와 기술 발전에 맞춰 컴퓨팅 리소스를 효율적으로 사용하는 능력
• 많은 리소스를 쓰는 것이 아니라, 적절한 리소스를 올바른 방식으로 사용하는 것이 핵심

1. 민주화된 고급 기술    
── ElastiCache / CloudFront 등 관리형 서비스 활용
복잡한 기술을 직접 구현하지 않고 즉시 활용

2. 글로벌 배포           
── CloudFront Edge Location (전 세계 400+ 거점)

3. 서버리스 아키텍처     
── Lambda / Fargate
서버 관리 비용 제거 + 자동 스케일 + 사용량 기반 과금

4. 빈번한 실험           
── Compute Optimizer
다양한 인스턴스 타입 테스트 및 권장사항 확인

5. 기계적 동감 (Mechanical Sympathy)        
── 워크로드 특성을 이해하고 그에 맞는 기술 선택
메모리 집약 → r 계열 / CPU 집약 → c 계열

02. Compute Optimizer

머신러닝으로 EC2, RDS, Lambda 사용 패턴을 분석하여 최적의 인스턴스 타입과 크기를 추천

Cost Optimization Pillar

01. CO Pillar 5대 설계 원칙

• 비즈니스 가치를 최대화하면서 불필요한 지출을 제거하는 능력
• 가장 저렴한 것을 쓰는 것이 아니라, 필요한 것만큼만 쓰는 것이 핵심

1. 클라우드 재무 관리    
── 비용을 기술 팀의 책임으로 내재화
태그 전략으로 팀/프로젝트별 비용 추적

2. 소비 모델 적용        
── On-Demand / Reserved / Savings Plans / Spot
워크로드 특성에 맞는 구매 모델 선택

3. 전체 효율성 측정      
── Cost Explorer
사용자당 AWS 비용 등 비즈니스 지표와 연동

4. 무차별적 작업 제거    
── 관리형 서비스 (RDS / ElastiCache / Fargate)
서버 운영 오버헤드 제거

5. 비용 분석 및 귀속     
── 태그 기반 팀/프로젝트별 비용 분류
Cost Explorer 필터로 부서별 청구 가능

02. EC2 구매 모델 비교

할인율 비교

On-Demand    ████████████████  100% (기준)
             언제든 시작/중지, 약정 없음

Reserved 1년 ████████          ~60% (40% 절감)
             1년 약정, 예측 가능한 워크로드

Reserved 3년 ██████            ~40% (60% 절감)
             3년 약정, 장기 안정 워크로드

Savings Plans████████          ~60% (40% 절감)
             인스턴스 타입 무관, 유연한 약정

Spot         ████              최대 10% (90% 절감)
             언제든 회수될 수 있음, 내결함성 필수

로컬 파일 업로드/다운로드(Spring Boot 파일 서비스)

01. 파일 서비스 개념

웹 애플리케이션에서 파일을 처리하는 방법은 크게 세 가지

[파일 저장 방식 비교]

  클라이언트
      │
      ▼ HTTP Multipart Request
  Spring Boot
      │
      ├──► 로컬 디스크    : 서버 내부 경로에 직접 저장
      │                    서버가 죽으면 파일도 사라짐
      │
      ├──► DB (Blob)      : 파일 바이너리를 DB에 저장
      │                    파일 크기 제한, 성능 저하
      │
      └──► 오브젝트 스토리지 : AWS S3 등 외부 스토리지 사용
                              무제한 확장, 고가용성

파일 저장 방식 비교

MultipartFile 처리 흐름

[클라이언트 → Spring Boot 내부 처리 흐름]

  브라우저 (HTML Form)
      │
      │  POST /file-upload
      │  Content-Type: multipart/form-data
      ▼
  DispatcherServlet
      │
      ▼
  MultipartResolver ──► 요청을 파싱하여 MultipartFile 객체 생성
      │
      ▼
  @Controller / @RestController
      │
      │  @RequestPart("file") MultipartFile file
      ▼
  Service Layer
      │
      ├──► file.getOriginalFilename()  : 원본 파일명
      ├──► file.getContentType()       : MIME 타입
      ├──► file.getSize()              : 파일 크기 (bytes)
      └──► file.transferTo(File)       : 디스크에 저장

02. 주요 객체 및 문법

어노테이션

@RequestPart vs @RequestParam

멀티파트 요청에서 파일 또는 데이터를 바인딩할 때 사용

03. 로컬 파일 업로드 구현

Spring MVC에서 파일 업로드는 @RequestPart 또는 @RequestParam으로 MultipartFile을 받아 처리

[업로드 처리 흐름]

  POST /file-upload (multipart/form-data)
          │
          ▼
  FileController.uploadFile()
          │
          ├── 1. 저장 경로 확인 및 생성 (mkdir)
          ├── 2. UUID + 원본파일명 조합
          ├── 3. file.transferTo() 로 디스크 저장
          └── 4. 결과 응답

04. 로컬 파일 다운로드 구현

파일 다운로드는 서버에서 파일을 읽어 HTTP 응답 스트림으로 전달하는 방식

[다운로드 처리 흐름]

  GET /file-download?fileName=xxx
          │
          ▼
  FileController.downloadFile()
          │
          ├── 1. 파일 경로 조합 (savePath + fileName)
          ├── 2. Files.newInputStream() → InputStreamResource 변환
          ├── 3. HttpHeaders 설정
          │       Content-Type: application/octet-stream
          │       Content-Disposition: attachment; filename="원본파일명"
          └── 4. ResponseEntity<Resource> 반환

05. 로컬 파일 삭제 구현

파일 삭제는 File.delete() 또는 Files.deleteIfExists()로 처리

Spring Boot 파일 서비스 AWS S3 연동

01. AWS S3 핵심 개념

• Amazon S3(Simple Storage Service)는 AWS에서 제공하는 오브젝트 스토리지 서비스
• 파일을 버킷(Bucket) 안에 오브젝트(Object) 형태로 저장하며, 각 오브젝트는 키(Key) 로 식별

S3 요청 흐름

[로컬 개발 환경 — IAM User 자격증명 사용]

 Spring Boot (로컬)
 │
 │ ~/.aws/credentials 또는 환경변수로 인증
 ▼
 AWS SDK v2 (S3Client)
 │
 │ HTTPS 요청
 ▼
 AWS S3 서울 리전 (ap-northeast-2)
 └── Bucket: my-app-bucket
 └── s3_data/uuid_file.txt

---
[EC2 배포 환경 — IAM Role 사용]

 EC2 (Spring Boot JAR 실행)
 │
 │ Instance Profile(IAM Role) 자동 인증 → 자격증명 파일 불필요
 ▼
 AWS SDK v2 (S3Client)
 │
 ▼
 AWS S3

02. 주요 객체 및 문법

S3Client

S3 버킷·오브젝트에 대한 모든 동기 API 요청을 처리하는 핵심 클라이언트

// 생성 — 빌더 패턴 사용
S3Client s3Client = S3Client.builder()
 .region(Region.AP_NORTHEAST_2) // 서울 리전 지정
 // .credentialsProvider(...) // 생략 시 DefaultCredentialsProvider 자동 사용
 .build();

// DefaultCredentialsProvider 자동 탐색 순서:
// 1. 환경변수 (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
// 2. ~/.aws/credentials 파일
// 3. EC2 IAM Role (Instance Profile)
// → 로컬과 EC2 모두 코드 변경 없이 동작하는 이유

// 주요 메서드
s3Client.putObject(request, requestBody); // 파일 업로드
s3Client.getObject(request); // 파일 다운로드 (스트림 반환)
s3Client.deleteObject(request); // 파일 삭제
s3Client.listObjectsV2(request); // 버킷 내 오브젝트 목록 조회
s3Client.headObject(request); // 오브젝트 메타데이터만 조회 (파일 존재 확인)
s3Client.copyObject(request); // 오브젝트 복사
s3Client.close(); // 리소스 해제 (Bean으로 관리 시 불필요)

S3Presigner

• Presigned URL을 생성하는 전용 클라이언트
• S3Client와 별도로 존재하며, Spring Cloud AWS를 사용해도 AutoConfiguration 대상이 아니므로 반드시 Bean으로 직접 등록

요청 객체 (Request)

모든 S3 API 호출은 요청 객체를 빌더 패턴으로 생성하여 클라이언트에 전달

• PutObjectRequest : S3에 파일을 업로드할 때 사용하는 요청 객체
• GetObjectRequest : S3에서 파일을 다운로드할 때 사용하는 요청 객체
• DeleteObjectRequest : S3에서 파일을 삭제할 때 사용하는 요청 객체
• ListObjectsV2Request : S3 버킷 내 오브젝트 목록을 조회할 때 사용하는 요청 객체

요청 바디 객체

• RequestBody : putObject() 호출 시 전송할 실제 파일 데이터를 감싸는 래퍼 클래스

응답 객체 (Response)

• ResponseInputStream : s3Client.getObject() 호출 시 반환되는 S3 오브젝트 스트림 응답

03. S3Service 구현

개념

DB 없이 파일 메타데이터를 메모리 Map으로 임시 관리

[파일 처리 흐름 — DB 없이 메모리 Map 사용]

 업로드 요청 (MultipartFile)
 │
 ▼
 S3Service.uploadS3File()
 ├── UUID 생성 → savedFileName
 ├── S3 putObject (버킷/키/스트림)
 └── fileStore Map에 저장
 key : fileNo (1, 2, 3...)
 value : savedFileName (UUID_원본명)

 다운로드 요청 (fileNo)
 │
 ▼
 S3Service.downloadS3File()
 ├── fileStore.get(fileNo) → savedFileName 조회
 └── S3 getObject → ResponseInputStream → Resource

 ️ 메모리 Map은 서버 재시작 시 초기화됨
 → PART 3에서 RDS 연결 후 DB로 전환 예정

04. Presigned URL

• Presigned URL은 S3 버킷에 임시 접근 권한을 부여하는 서명된 URL
• 클라이언트가 AWS 자격증명 없이도 특정 시간 동안 파일을 업로드하거나 다운로드할 수 있음

[Presigned URL 동작 흐름]

 클라이언트 Spring Boot AWS S3
 │ │ │
 │ GET /api/s3/presign │ │
 │ ?fileName=test.jpg │ │
 │ ──────────────────────► │ │
 │ │ S3Presigner로 URL 생성│
 │ │ (서명 포함, 만료시간) │
 │ Presigned URL 반환 │ │
 │ ◄────────────────────── │ │
 │ │ │
 │ PUT [presigned URL] │ │
 │ (파일 직접 전송) │ │
 │ ──────────────────────────────────────────────► │
 │ │ 파일 저장 완료│
 │ ◄────────────────────────────────────────────── │

클라이언트 → S3 직접 업로드 (Spring Boot 서버 경유 없음)
서버 부하 감소, 대용량 파일에 적합
URL 만료 후에는 접근 불가 (최대 7일)

Presigned URL vs 서버 경유 업로드 비교

S3 CORS 설정

개념

• Presigned URL을 사용해 브라우저에서 S3로 직접 업로드할 때, S3 버킷에 CORS 정책이 없으면 브라우저가 요청을 차단

[CORS가 없을 때 — 브라우저 차단]

 브라우저 (localhost:8080)
 │ PUT https://my-bucket.s3.amazonaws.com/...
 │ OPTIONS (Preflight 요청)
 ▼
 AWS S3
 │ 응답: CORS 헤더 없음
 ▼
 브라우저 → 차단! (Cross-Origin Request Blocked)

[CORS 설정 후 — 정상 동작]

 브라우저 (localhost:8080)
 │ OPTIONS (Preflight 요청)
 ▼
 AWS S3
 │ 응답: Access-Control-Allow-Origin: *
 ▼
 브라우저 → 허용
 │ PUT (실제 파일 업로드)
 ▼
 AWS S3 → 저장 완료

01. AWS 계정 구조

• 모든 리소스, 결제, 권한의 최상위 경계(Boundary)
• 내부에는 여러 계층의 자격증명 주체(Identity)가 존재

AWS 계정 관리 비교

• Root User : 최상위 관리자
• IAM : 사용하고자 하는 계정을 만들어서 권한을 부여하고 내부 서비스를 이용할 수 있게 함
• IAM Identity Center : 중앙 집중형 인간 사용자 관리

02. 공동 책임 모델 (Shared Responsibility Model)

• “AWS와 사용자가 보안을 나눠 책임진다”

03. 최소 권한 원칙 (Principle of Least Privilege)

• 모든 IAM 정책 설계의 기본 원칙:
• *"필요한 작업을 수행하기 위한 최소한의 권한만 부여"**

04. 자격증명 유형 비교

[장기 자격증명 — Long-term Credentials]
┌───────────────────────────────────────────────┐
│  IAM User Access Key                          │
│  ├─ Access Key ID:     AKIAIOSFODNN7EXAMPLE   │
│  └─ Secret Access Key: wJalrXUtnFEMI/...      │
│                                               │
│  특징: 만료 없음 → 유출 시 영구 피해            │
│  저장 위치: ~/.aws/credentials (로컬 파일)     │
│  위험: GitHub 실수 커밋 → 즉시 크립토 마이닝    │
└───────────────────────────────────────────────┘

[임시 자격증명 — Temporary Credentials (STS)]
┌───────────────────────────────────────────────┐
│  AWS STS (Security Token Service) 발급        │
│  ├─ Access Key ID                             │
│  ├─ Secret Access Key                         │
│  └─ Session Token  (필수 — 임시 증명)          │
│                                               │
│  특징: TTL 존재 (15분 ~ 36시간)                │
│  사용처: IAM Role, Identity Center, EC2 등    │
│  유출 시: TTL 만료 후 자동 무효화              │
└───────────────────────────────────────────────┘

Root 계정 보안 설정

01. Root 사용자

• AWS 계정을 처음 만들 때 생성되는 유일한 최고 권한 자격증명
• 오직 Root 만 할 수 있는 작업이 존재

[Root User 권한 범위]

         IAM 정책 적용 범위
┌─────────────────────────────────────┐
│                                     │
│   IAM User  ──→  IAM Policy 적용    │
│   IAM Role  ──→  IAM Policy 적용    │
│                                     │
│   Root User ──→  IAM Policy 무시    │ ← 모든 정책 우회
│             ──→  SCP 무시           │ ← 조직 정책도 우회
│             ──→  Permission         │
│                  Boundary 무시      │
└─────────────────────────────────────┘

[Root만 가능한 작업 목록]
- AWS 계정 해지
- IAM 활성화 (최초 1회)
- 결제 정보 / 지원 플랜 변경
- Route 53 도메인 이전
- S3 버킷 정책으로 잠긴 버킷 복구
- GovCloud 활성화

02. MFA 유형 비교

┌─────────────────────────────────────────────────────────┐
│                  MFA 유형 비교                          │
├─────────────────┬───────────────┬───────────────────────┤
│  가상 MFA       │  하드웨어 MFA  │  Passkey / FIDO2      │
│  (Authenticator)│  (YubiKey 등) │  (보안 키 / Passkey)   │
├─────────────────┼───────────────┼───────────────────────┤
│ 스마트폰 앱      │ 물리적 장치   │ 물리 키 or 기기 내장   │
│ Google Auth     │ YubiKey       │ YubiKey (FIDO2)       │
│ MS Authenticator│ RSA Token     │ Touch ID, Face ID     │
│ Authy           │ Gemalto Token │ Windows Hello         │
├─────────────────┼───────────────┼───────────────────────┤
│ TOTP 기반       │ TOTP 기반      │ 공개키 암호화 기반     │
│ 피싱 취약       │ 피싱 취약      │  피싱 저항             │
├─────────────────┼───────────────┼───────────────────────┤
│ 무료            │ 유료 (장비)    │ 무료 (기기 내장) /     │
│                 │               │ 유료 (하드웨어 키)     │
└─────────────────┴───────────────┴───────────────────────┘

CloudShell

# CloudShell
AWS 콘솔 안에 내장된 브라우저 기반 터미널.
AWS CLI, Git, Python, Node.js 등이 사전 설치되어 있고
콘솔 로그인 자격증명을 자동으로 사용

[비용 구조]
CloudShell 쉘 실행          →  무료 
1GB 홈 디렉토리 스토리지    →  무료 
aws iam / aws sts 명령 실행  →  무료  (조회 API는 무료)

CloudShell에서 EC2 생성     →  EC2 비용 발생 
CloudShell에서 S3 버킷 생성 →  S3 스토리지 비용 

# 접근 
[접근 경로]
AWS 콘솔 로그인
  → 상단 네비게이션 바
  → [>_] 아이콘 클릭  (검색창 오른쪽)
  → 브라우저 하단에 터미널 창 열림

# 테스트 명령어
aws sts get-caller-identity
aws --version
aws configure get region

CloudShell은 비활성 상태 20~30분 후 세션이 자동 종료
홈 디렉토리(`~/`)에 저장한 파일은 세션 종료 후에도 유지되지만,
설치한 패키지나 환경 변수는 세션 재시작 시 초기화
긴 스크립트는 반드시 `~/` 경로에 파일로 저장

# Root MFA 상태 점검
# Root Access Key 존재 여부 및 MFA 활성화 여부 확인

# 1단계: 자격증명 보고서 생성 요청
aws iam generate-credential-report

# 2단계: 보고서 다운로드 및 디코딩
aws iam get-credential-report \
  --query 'Content' \
  --output text | base64 --decode > credential-report.csv

# 3단계: Root 계정 행 확인 (첫 번째 데이터 행)
head -2 credential-report.csv

# 확인 항목:
# mfa_active          → true 
# access_key_1_active → false 
# access_key_2_active → false 

결제 알림 & 비용 이상 탐지 설정

[비용 알림 구성 흐름]

AWS Budgets / Cost Anomaly Detection
        ↓ 임계값 초과 감지
    CloudWatch Alarm
        ↓
    SNS Topic
        ↓
  이메일 알림 발송

IAM 사용자 / 역할 / 정책 관리

01. IAM 구성 요소 (User / Group / Role / Policy)

IAM 정책

"누가, 어떤 리소스에, 무엇을 할 수 있는가" 를 정의하는 JSON 문서

• AWS의 모든 권한은 정책으로 제어
• 정책이 없으면 기본적으로 모든 접근은 거부

우선순위: 명시적 Deny > 명시적 Allow > 묵시적 Deny

정책 JSON 문법 구조

{
  "Version": "2012-10-17",       // 정책 언어 버전 — 항상 이 값 고정
  "Statement": [                 // 권한 규칙 배열 — 여러 개 작성 가능
    {
      "Sid": "규칙ID",           // 선택값 — 규칙 식별용 이름
      "Effect": "Allow",         // Allow (허용) 또는 Deny (거부)
      "Principal": "*",          // 누가 — Resource 기반 정책에서만 사용
      "Action": [                // 어떤 작업 — 서비스:작업 형태
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [              // 어떤 리소스 — ARN 형식
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {             // 추가 조건 — 선택값
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-2"
        }
      }
    }
  ]
}

정책 설계 시 주의사항

02. IAM vs IAM Identity Center

IAM Access Analyzer 활성화

• 의도치 않게 외부에 노출된 리소스를 자동으로 탐지

[Access Analyzer가 탐지하는 항목]
- 퍼블릭 접근 허용된 S3 버킷
- 외부 계정에 접근 허용된 IAM Role
- 퍼블릭 접근 허용된 KMS 키
- 퍼블릭 접근 허용된 Lambda 함수
- 외부 노출된 SQS 큐 / SNS 토픽

계정 모니터링 & 실무 보안 설정

01. CloudTrail 개념 및 감사 로그

• AWS 계정에서 발생하는 모든 API 호출을 기록하는 서비스 콘솔 클릭, CLI 명령, SDK 호출 — 모두 이벤트로 남음

[CloudTrail 동작 흐름]

  사용자 / 서비스
       │
       ▼
  API 호출 (Console / CLI / SDK)
       │
       ▼
  AWS CloudTrail ──────────────────▶  S3 버킷 (로그 저장)
       │                                    │
       │                              장기 보관 / 감사
       ▼
  CloudWatch Logs ─────────────────▶  알림 / 대시보드
       │
       ▼
  EventBridge ──────────────────────▶  자동화 (Lambda 등)

02. CloudWatch 보안 알림 설정 — Root 로그인 탐지

• Root 계정 로그인은 비정상 이벤트이므로 즉시 알림

[Root 로그인 탐지 흐름]

CloudTrail 이벤트 (ConsoleLogin by Root)
        ↓
CloudWatch Logs → Metric Filter
        ↓
CloudWatch Alarm (임계값: 1회)
        ↓
SNS Topic → 이메일 알림

클라우드 컴퓨팅

• 인터넷을 통해 서버, 스토리지, 데이터베이스, 네트워킹 등 IT 자원을 필요한 만큼, 사용한 만큼 빌려 쓰는 방식

01. 클라우드 서비스 모델 3가지

02. NIST 클라우드

• NIST (National Institute of Standards and Technology) 는 미국 국립표준기술연구소로, 클라우드 컴퓨팅의 국제 표준 정의 제공

5가지 필수 특성 (Essential Characteristics)

4가지 배포 모델 (Deployment Models)

AWS 글로벌 인프라 & EC2 소개

01. AWS 글로벌 인프라

[AWS 글로벌 인프라 계층 구조]

  전 세계 (Global)
  │
  ├── 리전 (Region) — 지리적 독립 클러스터
  │     예) 서울, 도쿄, 버지니아, 프랑크푸르트
  │
  │     ├── 가용 영역 (AZ, Availability Zone)
  │     │     예) ap-northeast-2a / 2b / 2c / 2d
  │     │     └── 데이터센터 (1개 이상의 물리 건물)
  │     │           └── EC2 / RDS / EBS ...
  │     │
  │     └── 리전 내 글로벌 서비스 (VPC, S3, IAM ...)
  │
  └── 엣지 로케이션 (Edge Location)
        CloudFront CDN 캐시 노드 (400개+)
        → 사용자와 가장 가까운 위치에서 콘텐츠 전달

02. ARN (Amazon Resource Name) 구조

• AWS의 모든 리소스는 고유한 ARN으로 식별

ARN 형식:
arn:partition:service:region:account-id:resource

예시:
arn:aws:ec2:ap-northeast-2:123456789012:instance/i-0abcd1234efgh5678
│   │   │   │              │             │
│   │   │   │              │             └── 리소스 타입/ID
│   │   │   │              └── AWS 계정 ID
│   │   │   └── 리전 (서울)
│   │   └── 서비스 (EC2)
│   └── 파티션 (aws / aws-cn / aws-us-gov)
└── 고정값

03. EC2 (Elastic Compute Cloud)

• AWS의 가상 서버 서비스
• 몇 분 만에 생성하고 언제든 삭제 가능
• 다양한 운영체제(Linux, Windows 등) 선택 가능

[EC2 핵심 구성요소]

  EC2 인스턴스 (가상 서버)
  ├── AMI (Amazon Machine Image)
  │     → 운영체제 + 초기 설정 스냅샷
  │     → 예) Amazon Linux 2023, Ubuntu 24.04
  │
  ├── 인스턴스 타입 (하드웨어 사양)
  │     → 예) t2.micro (1vCPU, 1GB RAM)
  │
  ├── 스토리지 (EBS)
  │     → 예) 8GB gp3 SSD (루트 볼륨)
  │
  ├── 네트워크 (VPC + Subnet)
  │     → 어느 네트워크에 배치할지
  │
  └── 보안 (Security Group + Key Pair)
        → 어떤 포트를 열고, 누가 접근 가능한지

EC2 인스턴스 타입

인스턴스 타입 명명 규칙

m  8  g  .  2xlarge
│  │  │     │
│  │  │     └── 크기: nano < micro < small < medium
│  │  │                    < large < xlarge < 2xlarge ...
│  │  │
│  │  └── 추가 기능 코드
│  │        g = Graviton (ARM)    a = AMD
│  │        i = Intel             d = NVMe SSD 로컬 스토리지
│  │        n = 고성능 네트워크
│  │
│  └── 세대 (숫자가 클수록 최신 — 현재 7~8세대가 최신)
│
└── 패밀리
      m = General Purpose (범용)
      c = Compute Optimized (연산 집중)
      r = Memory Optimized (메모리 집중)
      t = Burstable (버스터블 — 프리 티어)
      p / g = GPU
      i = Storage Optimized

AMI & 키페어 & Security Group

01. AMI (Amazon Machine Image)

• EC2 인스턴스를 만들기 위한 운영체제 + 초기 설정의 스냅샷

[Docker vs AMI 비교]

Docker 이미지                    AMI
─────────────────────────────────────────────
docker pull ubuntu:24.04    ←→   AMI 선택
docker run ubuntu:24.04     ←→   EC2 인스턴스 시작
컨테이너 (실행 중인 이미지)  ←→   EC2 인스턴스
Dockerfile                  ←→   AMI 빌드 스크립트
Docker Hub                  ←→   AWS Marketplace / AMI 카탈로그
─────────────────────────────────────────────

AMI 구성 요소

AMI (ami-xxxxxxxxxxxxxxxxx)
├── 루트 볼륨 스냅샷
│     → OS가 설치된 디스크 이미지 (기본 8~30GB)
│
├── 실행 권한
│     → 퍼블릭 (누구나 사용) / 프라이빗 (내 계정만)
│
├── 블록 디바이스 매핑
│     → /dev/xvda (루트), /dev/xvdb (추가 볼륨)
│
└── 가상화 타입
      → HVM (Hardware Virtual Machine) — 현재 표준

02. 키페어 (Key Pair)

• SSH로 EC2에 접속하기 위한 공개키/개인키 쌍

03. Security Group (보안 그룹)

• EC2 인스턴스의 가상 방화벽

[Security Group 동작 원리]

  인터넷           ┌──────────────┐    EC2 인스턴스
  ────────→        │Security Group│ →  ┌──────────┐
                   │              │    │ 앱 :8080  │
                   │ 인바운드 규칙 │    └──────────┘
                   │ SSH  22      │
                   │ HTTP 80      │
                   │ App  8080    │
                   │ DB   3306    │ ← 차단
                   │              │
                   │ 아웃바운드   │
                   │ 전체         │ ← 기본 전부 허용
                   └──────────────┘

EBS & Elastic IP & 네트워킹 기초

01. EBS (Elastic Block Store)

• EC2에 연결하는 가상 하드디스크
• EC2 인스턴스와 별개로 존재 → 인스턴스 종료 후에도 데이터 유지 (1:1 매핑)

02. Elastic IP (탄력적 IP)

• EC2 인스턴스에 고정 공인 IP를 연결해주는 서비스

! 할당만 하고 연결하지 않으면 요금이 발생 - 사용하지 않을 때는 릴리즈(해제) 필수 !

인스턴스 상태

Stop vs Terminate vs Reboot 비교 | 항목 | Stop | Terminate | Reboot | | --- | --- | --- | --- | | 동작 | 인스턴스 중지 | 인스턴스 삭제 | OS 재시작 | | EBS | 유지 (과금 지속) | 삭제* | 유지 | | 퍼블릭 IP | 반환 (EIP 제외) | 반환 | 유지 (변경 없음) | | 데이터 | RAM 데이터 소실 | 모든 데이터 소실 | 유지 | | 복구 | 재시작 가능 | 복구 불가 | - | | 인스턴스 ID | 유지 | 삭제 | 유지 | | 과금 | 중지 후 없음 | 즉시 없음 | 계속 발생 |

Auto Scaling & ALB

Auto Scaling 개념

[Auto Scaling 동작 원리]

평상시 (CPU 낮음)         트래픽 급증               트래픽 감소
┌───┐ ┌───┐            ┌───┐ ┌───┐ ┌───┐ ┌───┐   ┌───┐ ┌───┐
│EC2│ │EC2│ Scale Out→ │EC2│ │EC2│ │EC2│ │EC2│→  │EC2│ │EC2│
└───┘ └───┘            └───┘ └───┘ └───┘ └───┘   └───┘ └───┘
  Min: 2개               Desired: 4개               Min: 2개

EC2 실습

AWS Lambda

• 서버를 프로비저닝하거나 관리하지 않고 코드를 실행하는 서버리스 컴퓨팅 서비스
• 이벤트가 발생할 때만 코드가 실행됨 → 유휴 시 비용 없음

[EC2 vs Lambda 실행 모델 비교]

EC2 방식
  서버 시작 (항상 실행 중)
      │
      ├── 요청 있을 때  → 처리
      ├── 요청 없을 때  → 대기 (비용 발생)
      └── 트래픽 급증   → 수동 또는 ASG로 확장 (시간 소요)

Lambda 방식
  이벤트 발생 ──▶ 실행 환경 자동 생성 ──▶ 코드 실행 ──▶ 종료
      │                                                    │
      └── 요청 없을 때: 실행 환경 없음 (비용 없음)          │
      └── 트래픽 급증: 수천 개 병렬 자동 실행              ─┘

01. Lambda 핵심 구성 요소

Lambda 함수 구성 요소

  Lambda Function
  ├── 코드 (Handler)
  │     → 진입점 함수: handler(event, context)
  │     → ZIP 파일 업로드 or 컨테이너 이미지
  │
  ├── 런타임 (Runtime)
  │     → Python 3.12 / Node.js 22 / Java 21
  │     → .NET 8 / Go / Ruby 3.3
  │     → 커스텀 런타임 (provided.al2023)
  │
  ├── 트리거 (Trigger / Event Source)
  │     → API Gateway, S3, DynamoDB Streams
  │     → SQS, SNS, EventBridge, CloudWatch Events
  │     → ALB, Kinesis, Cognito ...
  │
  ├── 권한 (IAM Role)
  │     → 실행 역할: CloudWatch 로그 기록, 다른 서비스 접근
  │
  └── 환경 설정
        → 메모리: 128MB ~ 10,240MB
        → 타임아웃: 1초 ~ 900초 (15분)
        → 환경 변수, VPC 설정, 레이어

02. Lambda 호출 방식

[Lambda 호출 방식 3가지]

1. 동기(Synchronous) 호출
   호출자 ──요청──▶ Lambda ──응답──▶ 호출자
   호출자가 응답을 기다림
   예) API Gateway, ALB, SDK 직접 호출
   실패 시: 호출자가 직접 오류 수신

2. 비동기(Asynchronous) 호출
   호출자 ──이벤트──▶ Lambda 내부 큐 ──▶ Lambda
   호출자는 수락 응답(202)만 받고 기다리지 않음
   예) S3 이벤트, SNS, EventBridge
   실패 시: 최대 2회 자동 재시도 → DLQ로 전송 가능

3. 스트림/폴링 기반 호출 (Event Source Mapping)
   Lambda ──polling──▶ SQS / Kinesis / DynamoDB Streams
   Lambda가 능동적으로 데이터 소스를 폴링
   예) SQS 큐 처리, Kinesis 스트림 처리

03. Lambda vs EC2 vs ECS Fargate 선택 기준

AWS 스토리지 개요 및 분류

01. 개념

스토리지의 3가지 계층

• 온프레미스(물리 서버실)에서 쓰던 개념과 동일하지만, AWS에서는 이를 완전 관리형 서비스로 제공

[ 스토리지 3계층 개념도 ]

┌──────────────────────────────────────────────────────────────┐
│                   데이터 저장 방식                            │
├──────────────┬───────────────────┬───────────────────────────┤
│  Block       │  File             │  Object                   │
│  (블록)      │  (파일)           │  (객체)                    │
├──────────────┼───────────────────┼───────────────────────────┤
│  데이터를     │  구조로 저장      │  HTTP API로 접근           │
│  블록으로     │  NFS/SMB 프로토콜 │  무한 확장 가능            │
│  분할 저장    │  으로 접근        │                           │
├──────────────┼───────────────────┼───────────────────────────┤
│  AWS: EBS    │  AWS: EFS, FSx    │  AWS: S3                  │
│ (하드디스크)  │  (공유 네트워크   │  (인터넷 창고)             │
│              │   드라이브)       │                           │
└──────────────┴───────────────────┴───────────────────────────┘

[ AWS 스토리지 서비스 전체 구조 ]

AWS Storage Services
│
├── Object Storage (객체 스토리지)
│   └── Amazon S3
│       ├── General Purpose Bucket  ← 일반 사용 (기본)
│       ├── Directory Bucket        ← 저지연 (Express One Zone)
│       ├── Table Bucket            ← Apache Iceberg 분석 테이블
│       └── Vector Bucket           ← AI/RAG 벡터 저장
│
├── Block Storage (블록 스토리지)
│   └── Amazon EBS (Elastic Block Store)
│       ├── gp3  ← 범용 SSD (현재 기본 추천)
│       ├── io2  ← 고성능 IOPS (DB 전용)
│       ├── st1  ← 처리량 최적화 HDD
│       └── sc1  ← 콜드 HDD (저비용)
│
├── File Storage (파일 스토리지)
│   ├── Amazon EFS (Elastic File System)  ← Linux NFS, 자동 확장
│   └── Amazon FSx
│       ├── FSx for Windows File Server   ← Windows SMB
│       ├── FSx for Lustre                ← HPC/ML 고성능
│       ├── FSx for NetApp ONTAP          ← 엔터프라이즈 마이그레이션
│       └── FSx for OpenZFS               ← ZFS 마이그레이션
│
├── Hybrid/Edge (하이브리드)
│   ├── AWS Storage Gateway               ← 온프레미스 ↔ AWS 연결
│   └── AWS Snow Family                   ← 오프라인 대용량 데이터 이전
│       ├── Snowcone
│       ├── Snowball Edge
│       └── Snowmobile
│
└── Data Protection (데이터 보호)
    ├── AWS Backup                         ← 통합 백업 관리
    └── AWS DataSync                       ← 온라인 데이터 마이그레이션

02. 주요 서비스별 핵심 특성

03. 심화

내구성(Durability) vs 가용성(Availability) 차이

[ 내구성 vs 가용성 ]

내구성 (Durability) = 데이터가 손실되지 않을 확률
  └── S3: 99.999999999% (11 nine)
      = 10,000,000개 객체 저장 시 1년에 0.000001개만 손실될 수 있음

가용성 (Availability) = 서비스에 접근 가능한 시간의 비율
  └── S3 Standard: 99.99%
      = 1년 365일 중 최대 약 52분만 접근 불가
      = 이 시간 동안 "데이터는 있지만 접근이 안 될 수 있음"

핵심: 내구성 ≠ 가용성
  - 내구성: 데이터 자체가 사라지지 않는 것
  - 가용성: 언제든 접근할 수 있는 것

Amazon S3 (Object Storage)

S3의 기본 구조

• 객체(Object) 단위로 데이터를 저장 파일시스템의 폴더/파일 구조와 달리, 버킷(Bucket) 안에 객체(Object) 를 평탄한(flat) 구조로 저장

[ S3 구조 개념도 ]

AWS Account
└── Amazon S3 (리전 전체에 걸쳐 동작)
    │
    ├── Bucket: my-app-bucket-20260101      ← 전 세계 유일한 이름
    │   ├── Object: images/profile.jpg      ← Key + Value + Metadata
    │   ├── Object: logs/2026/03/app.log
    │   └── Object: backups/db-dump.sql
    │
    └── Bucket: my-static-website
        ├── Object: index.html
        └── Object: css/style.css

핵심 개념:
┌──────────────┬────────────────────────────────────────────┐
│ 구성 요소     │ 설명                                       │
├──────────────┼────────────────────────────────────────────┤
│ Bucket       │ 최상위 컨테이너. 전 세계에서 유일한 이름     │
│ Object       │ 저장 단위. 최대 크기: 50TB (2025 이후)      │
│ Key          │ 객체의 고유 식별자 (경로처럼 보이지만 문자열)│
│ Value        │ 실제 데이터 (바이너리)                      │
│ Metadata     │ 객체에 대한 정보 (Content-Type, 태그 등)    │
│ Version ID   │ 버전 관리 활성화 시 각 버전의 ID            │
└──────────────┴────────────────────────────────────────────┘

내부 동작 원리

• S3는 내부적으로 각 객체를 최소 3개 AZ의 물리적으로 분리된 시설에 복제
• Key 기반의 consistent hashing으로 저장 노드를 결정하며, 이것이 S3가 11 nine 내구성을 달성
• 객체 크기가 100MB 이상이면 Multipart Upload를 사용 권장
• 5GB 초과 객체는 반드시 Multipart Upload를 사용

S3 스토리지 클래스

[ S3 스토리지 클래스 — 접근 빈도에 따른 분류 ]

자주 접근 (Frequent Access)
│
├── S3 Standard
│   ├── 용도: 일반적인 웹 앱, 콘텐츠 배포
│   ├── 가용성: 99.99%
│   └── 비용: $0.025/GB/월 (서울)
│
├── S3 Intelligent-Tiering          접근 패턴 불명확
│   ├── 용도: 접근 패턴을 예측하기 어려운 데이터
│   └── 특징: AWS가 자동으로 최적 티어로 이동
│
가끔 접근 (Infrequent Access)
│
├── S3 Standard-IA         최소 보관: 30일
├── S3 One Zone-IA         단일 AZ, 재생성 가능 데이터
│
아카이빙 (Archiving)
│
├── S3 Glacier Instant Retrieval   검색: ms
├── S3 Glacier Flexible Retrieval  검색: 분~12시간
└── S3 Glacier Deep Archive        검색: 12~48시간, $0.002/GB/월

S3 데이터 일관성 보장

중요: S3는 강한 일관성(strong consistency)을 제공하지만 여러 클라이언트가 동시에 같은 객체를 수정하는 "동시성 제어(locking)"는 지원하지 않음. → 동시 수정이 필요하면 DynamoDB + S3 조합을 사용

버킷 생성

파일 업로드

Object Lock 설정

버킷 생성 시에만 활성화 가능! (나중에 변경 불가)

[Object Lock 활성화 버킷 생성]
경로: S3 → [버킷 만들기]

  기본 설정 진행 후 "고급 설정" 섹션에서:
  객체 잠금 → "활성화" 선택
  → "확인했습니다" 체크
  → [버킷 만들기]

[기본 보관 정책 설정]
  버킷 → [속성] 탭
  → 객체 잠금 → [편집]
  → 기본 보관: 활성화
  → 모드 선택:
    거버넌스(Governance) ← 실습용 (권한 있는 사용자 삭제 가능)
    규정 준수(Compliance) ← 실제 규제용 (누구도 삭제 불가!)
  → 기간: 30일
  → [변경 사항 저장]

[개별 객체 Legal Hold 적용]
  객체 클릭 → [객체 잠금] 탭
  → 법적 보존: 활성화
  → [저장]

S3 Storage Lens

경로: S3 콘솔 → 좌측 [Storage Lens] → [대시보드]
      → [대시보드 생성]

설정:
  이름    : storage-lens-main
  홈 리전 : ap-northeast-2
  범위    : 계정 전체 포함 (기본값)

  지표:
    무료 지표: 기본 활성화 (비용 발생 없음)
    고급 지표: 생략 (유료)
  → [대시보드 생성]

24시간 후 데이터 수집되면 확인 가능:
  총 스토리지 / 객체 수 / 버킷별 사용량 분포
  스토리지 클래스별 분포 / 비용 최적화 권장 사항

Amazon EBS (Block Storage)

01. 개념

EBS의 기본 구조

[ EBS 기본 구조 ]

AWS Region: ap-northeast-2 (서울)
│
├── AZ-a (ap-northeast-2a)
│   ├── EC2 Instance (i-0abc123)
│   │   └── [연결됨] EBS Volume (vol-0001)  ← OS 디스크 (8GB, gp3)
│   │   └── [연결됨] EBS Volume (vol-0002)  ← 데이터 디스크 (100GB, gp3)
│   │
│   └── EBS Volume (vol-0003)  ← [미연결, available 상태 → 과금 중!]
│
└── AZ-b (ap-northeast-2b)
    └── EC2 Instance (i-0def456)
        └── vol-0004  ← AZ-a의 볼륨은 여기 연결 불가!

핵심 제약:
- EBS 볼륨은 같은 AZ의 EC2에만 연결 가능
- 기본적으로 EC2 1개에만 연결 (io2 Multi-Attach 예외)
- EC2 종료 시 Root Volume은 기본 삭제, 추가 볼륨은 유지

! EBS는 하나의 EC2만 가능 / EC2는 여러 개의 EBS가 가능

EBS 내부 아키텍처

• EBS는 AWS의 전용 스토리지 네트워크(EBS Network)를 통해 EC2와 연결
• 일반 인스턴스 네트워크와 분리된 전용 대역폭을 사용하므로 네트워크 트래픽과 간섭이 없음
• Nitro 기반 EC2(최신 세대)는 NVMe 인터페이스를 사용하며 더 낮은 지연시간을 제공
• 볼륨은 내부적으로 동일 AZ 내 여러 서버에 복제되어 내구성을 유지

EBS 볼륨 타입

EBS 성능

**[ IOPS vs 처리량 차이 ]**

**IOPS (Input/Output Operations Per Second):**
  = 초당 수행 가능한 I/O 작업 횟수
  = 작은 블록(4KB~16KB) 랜덤 읽기/쓰기에 중요
  = 데이터베이스 트랜잭션에 핵심 지표

**처리량 (Throughput):**
  = 초당 전송 가능한 데이터 양 (MB/s)
  = 큰 블록 순차 읽기/쓰기에 중요
  = 로그 처리, 데이터 분석에 핵심 지표

EBS Multi-Attach

io2 볼륨은 최대 16개의 Nitro EC2에 동시 연결 가능

[ EBS Multi-Attach 아키텍처 ]

일반 EBS:
  EC2-A ──────── EBS Volume ── EC2-B (연결 불가)

Multi-Attach (io2만 지원):
  EC2-A ─┐
  EC2-B ─┼──── io2 EBS Volume (동일 AZ, 최대 16개)
  EC2-C ─┘

사용 사례:
- 고가용성 클러스터 파일시스템 (OCFS2, GFS2)
- Oracle RAC 데이터베이스

주의:
- 클러스터 인식 파일시스템 필수 (ext4/xfs 직접 사용 불가)
- 동시 쓰기 시 애플리케이션 레벨 잠금 필요
- 동일 AZ 내에서만 동작

EC2 인스턴스 스토어 vs EBS 비교

[ Instance Store vs EBS ]

EC2 Instance Store:
  ├── EC2 호스트 물리 서버에 직접 연결된 NVMe 스토리지
  ├── 극히 낮은 지연시간 (물리 연결)
  ├── EC2 중지/종료 시 데이터 영구 삭제 (임시 스토리지)
  └── 사용 사례: 캐시, 임시 처리 파일, 버퍼

EBS:
  ├── 네트워크 연결 스토리지 (약간의 지연)
  ├── EC2 종료 후에도 데이터 유지
  └── 사용 사례: OS 디스크, DB, 영구 데이터

자격증 시험:
  "인스턴스 중지 시 데이터 삭제" → Instance Store
  "영구 보존 필요" → EBS
  "최고 성능 임시 캐시" → Instance Store (NVMe SSD)

# Instance Store vs EBS 데이터 생명주기

Instance Store
EC2 stop -> 삭제
EC2 terminate -> 삭제
EC2 reboot -> 유지
하드웨어 장애 -> 삭제

EBS
EC2 stop -> 유지
EC2 terminate -> 기본값은 삭제, 설정으로 유지
EC2 reboot -> 유지
EC2 Detach -> 유지
다른 EC2 연결  -> 유지

AMI vs EBS 스냅샷 차이

EBS 스냅샷:
  └── 데이터 볼륨만 백업
      복원 → 새 EBS 볼륨 생성 후 EC2에 연결
      용도: DB 데이터, 업로드 파일 등 데이터 보호

EC2 AMI (Amazon Machine Image):
  └── OS + 설정 + 모든 볼륨 전체 백업
      복원 → AMI로 새 EC2 인스턴스를 그대로 복제
      용도: 서버 전체 복구, 동일 서버 여러 대 찍어내기

Amazon EFS & FSx (File Storage)

01. 개념

EFS의 기본 구조

[ EFS 기본 구조 ]

AWS Region: ap-northeast-2 (서울)
│
└── EFS File System (fs-0abc1234)
    │  Regional: 3개 AZ에 데이터 자동 복제
    │
    ├── Mount Target in AZ-a (IP: 10.0.1.x)
    ├── Mount Target in AZ-b (IP: 10.0.2.x)
    └── Mount Target in AZ-c (IP: 10.0.3.x)
         │
         ├── EC2-1 ──NFS v4.1──► /mnt/efs  ← 동시 읽기/쓰기
         ├── EC2-2 ──NFS v4.1──► /mnt/efs
         ├── ECS Task ──────────► /mnt/efs
         └── Lambda ─────────────► /mnt/efs (EFS Lambda 마운트)

EFS 내부 아키텍처

• EFS는 AWS의 분산 파일시스템으로, POSIX 호환 API를 제공
• 데이터는 AZ별 물리 스토리지에 분산 저장되며, 각 AZ의 Mount Target IP를 통해 접근
• NFS v4.1의 parallel NFS(pNFS) 기능을 통해 여러 스토리지 서버에 동시 접근으로 처리량을 극대화
• stunnel을 통한 TLS 암호화 전송은 Mount Helper가 자동으로 처리

EFS 파일시스템 타입 및 구성

[ EFS 구성 옵션 전체 ]

파일시스템 타입:
  Regional (권장): 3+ AZ 복제, 내구성 11 nine
  One Zone: 단일 AZ, ~47% 저렴, 재생성 가능 데이터

성능 모드:
  General Purpose (권장): 낮은 지연, 대부분의 워크로드
  Max I/O (레거시): 높은 동시성, 지연 증가

처리량 모드:
  Elastic (권장): 자동 조절, 최대 10GB/s 읽기, 3GB/s 쓰기
  Bursting: 크기 기반 기본 처리량 + 버스트 크레딧
  Provisioned: 고정 처리량 지정

스토리지 클래스:
  Standard: $0.36/GB/월
  Standard-IA: $0.0272/GB/월 (접근 시 $0.01/GB 추가)
  One Zone: $0.192/GB/월
  One Zone-IA: $0.0133/GB/월

EFS vs EBS 선택

[ 선택 기준 ]

다중 EC2 동시 접근 필요? → EFS
단일 EC2, 고성능 DB?    → EBS io2
단일 EC2, 일반 워크로드? → EBS gp3
Linux NFS, 자동 확장?   → EFS
Windows SMB?            → FSx for Windows
HPC/ML 고성능?          → FSx for Lustre

실무 조합:
EC2 OS/앱           → EBS gp3
공유 업로드 파일     → EFS (또는 S3)
DB 데이터           → EBS gp3/io2
정적 콘텐츠         → S3 + CloudFront

EFS 삭제 순서

순서를 지키지 않으면 오류 발생!

[1단계] EC2에서 마운트 해제
  EC2 터미널: sudo umount /mnt/efs
  /etc/fstab에서 EFS 항목 삭제

[2단계] Mount Target 삭제
  EFS → 파일 시스템 → [네트워크] 탭
  → 각 AZ 마운트 대상 선택 → [삭제]
  → 상태가 사라질 때까지 약 2분 대기

[3단계] EFS 파일 시스템 삭제
  EFS → 파일 시스템 선택 → [삭제]
  → 파일 시스템 ID 입력 → [확인]

[4단계] 보안 그룹 삭제
  EC2 → 보안 그룹 → efs-security-group → [삭제]

통합 — 보안 / 백업 / 비용 관리

보안 레이어 개념

[ AWS 스토리지 보안 5개 레이어 ]

요청(Request)
    │
    ▼
┌────────────────────────────────────┐
│  1. IAM (Identity & Access Mgmt)   │
│  "이 사용자/역할이 허가된 작업인가?" │
└──────────────────┬─────────────────┘
                   ▼
┌────────────────────────────────────┐
│  2. 리소스 정책 (Resource Policy)  │
│  S3 버킷 정책, EFS 파일시스템 정책  │
└──────────────────┬─────────────────┘
                   ▼
┌────────────────────────────────────┐
│  3. 네트워크 제어                  │
│  VPC Endpoint, Security Group, IP  │
└──────────────────┬─────────────────┘
                   ▼
┌────────────────────────────────────┐
│  4. 전송 암호화 (TLS)              │
│  HTTPS, aws:SecureTransport 조건   │
└──────────────────┬─────────────────┘
                   ▼
┌────────────────────────────────────┐
│  5. 저장 암호화 (KMS/SSE)          │
│  SSE-S3, SSE-KMS, EBS 암호화       │
└────────────────────────────────────┘

AWS 인프라 & 네트워크

01. AWS 인프라 계층 구조

AWS 클라우드의 물리적·논리적 구성 단위를 계층으로 이해하는 것이 네트워크 설계의 출발점.

전 세계 AWS 글로벌 인프라
│
├── Region (지역)
│     물리적으로 분리된 지리적 데이터센터 집합.
│     각 Region은 독립적으로 운영되며, 장애가 다른 Region에 전파되지 않음.
│     예) ap-northeast-2 (서울), us-east-1 (버지니아 북부)
│
│     ├── Availability Zone (AZ, 가용 영역)
│     │     하나의 Region 안에 있는 독립적인 데이터센터 클러스터.
│     │     AZ끼리는 물리적으로 수십 km 이상 떨어져 있어
│     │     화재·홍수·전력 장애 등이 동시에 영향을 미치지 않음.
│     │     예) ap-northeast-2a / 2b / 2c / 2d
│     │
│     └── Local Zone (선택적)
│           특정 도시에 컴퓨팅 리소스를 배치해 초저지연 제공.
│           예) 부산, 도쿄, 로스앤젤레스 등.
│
└── Edge Location (엣지 로케이션)
      CloudFront(CDN), Route 53(DNS)의 캐시·응답을 처리하는
      전 세계 550+ 분산 서버 거점.
      Region보다 훨씬 많고, 사용자 가까이에 위치.

02. 온프레미스 네트워크 vs AWS 가상 네트워크

VLAN (Virtual Local Area Network)

• 물리적으로 같은 네트워크 장비에 연결되어 있어도 논리적으로 분리된 네트워크 구간
• AWS에서는 Subnet이 이 역할을 수행

NAT (Network Address Translation)

• 사설 IP 주소를 공인 IP 주소로 변환하는 기술
• Private Subnet의 EC2가 인터넷으로 나갈 때, NAT Gateway가 사설 IP → 공인 IP로 변환해 인터넷 통신을 가능하게 함
• 반대 방향(인터넷 → 사설 IP)은 허용하지 않아 외부 침입을 원천 차단

IaC (Infrastructure as Code)

• 인프라 구성을 코드 파일로 정의하고 버전 관리하는 방식
• 콘솔에서 클릭하는 모든 설정을 코드로 표현해 반복 적용, 팀 공유, 이력 추적이 가능
• 대표 도구: Terraform (HashiCorp), AWS CloudFormation (AWS 네이티브)

03. CIDR 표기법과 IP 주소 설계 원칙

AWS VPC와 Subnet의 IP 범위를 정의할 때 반드시 사용하는 표기법

CIDR 표기 형식: X.X.X.X / prefix

예시: 10.0.0.0/16

10 . 0 . 0 . 0   /   16
└─────────────┘       └──
  네트워크 주소         prefix (앞에서부터 고정되는 비트 수)

→ 앞 16비트 고정 → 나머지 16비트가 호스트 영역
→ 사용 가능한 IP 수 = 2^16 = 65,536개

CIDR (Classless Inter-Domain Routing)

• IP 주소를 클래스(A/B/C) 구분 없이 prefix 길이로 유연하게 범위를 지정하는 방식
• /16, /24, /28 등 숫자가 클수록 범위가 좁아지고 IP 수가 줄어듦

RFC 1918 (사설 IP 대역) 인터넷에서 라우팅되지 않는 내부 전용 IP 대역의 국제 표준 AWS VPC 설계 시 반드시 이 대역 내에서 CIDR을 선택

CIDR prefix별 IP 수 비교

AWS 예약 IP 5개 AWS는 각 서브넷에서 아래 5개 IP를 시스템 용도로 예약하여 사용 불가 예) 서브넷 10.0.1.0/24 기준:

/24 서브넷의 실제 사용 가능 IP = 256 - 5 = 251개.

04. 패킷 흐름

[인터넷 사용자]  예) 브라우저에서 https://shop.mylab.kr 요청
      │
      ▼
[Route 53]          DNS 쿼리 → 도메인을 IP 주소로 변환
      │
      ▼
[CloudFront]        Edge에서 캐시 확인. Cache Miss 시 Origin으로 전달.
      │
      ▼
[Internet Gateway]  VPC의 인터넷 출입문. 공인 IP ↔ 사설 IP 매핑.
      │
      ▼
[Route Table]       패킷의 목적지 판단.
                    0.0.0.0/0 → IGW (외부)
                    10.0.0.0/16 → local (VPC 내부)
      │
      ▼
[Network ACL]       서브넷 경계 방화벽 (Stateless).
                    인바운드 규칙 번호 순서대로 Allow / Deny 판단.
      │
      ▼
[Security Group]    인스턴스 레벨 방화벽 (Stateful).
                    허용된 포트·프로토콜만 통과.
      │
      ▼
[EC2 Instance]      목적지 도달. 애플리케이션이 요청 처리.
      │
      │  (DB 요청 발생 시)
      ▼
[Security Group]    DB용 SG. 앱 서버 SG에서만 허용.
      │
      ▼
[RDS / DB 서버]     인터넷에서 직접 접근 불가. 앱 서버만 접근 가능.

Stateful vs Stateless

Stateful (상태 추적형)

• 연결 상태(Connection State)를 기억, 인바운드 요청을 허용하면 해당 연결의 응답은 자동 허용
• AWS에서는 Security Group이 Stateful 예) 인바운드 80 허용 → 응답(아웃바운드)은 별도 규칙 없이 자동 통과.

Stateless (상태 비추적형)

• 연결 상태를 기억하지 않음, 요청과 응답 모두 별도 규칙 필요
• AWS에서는 Network ACL이 Stateless. 예) 인바운드 80 허용 → 응답 아웃바운드도 반드시 별도 규칙 추가 필요.

VPC 핵심 구성요소

01.VPC (Virtual Private Cloud)

• AWS 클라우드 안에 생성하는 논리적으로 격리된 전용 가상 네트워크
• 모든 AWS 리소스(EC2, RDS, Lambda 등)는 VPC 안에서 동작

VPC 핵심 특성

ENI (Elastic Network Interface)

EC2 인스턴스에 연결되는 가상 네트워크 카드

DNS Hostname / DNS Resolution

DNS Hostname: VPC 내 EC2에 자동으로 DNS 이름 부여 여부 설정 DNS Resolution: VPC 내부에서 AWS 제공 DNS 서버(VPC+2 주소)를 사용할지 여부

02. 서브넷 (Subnet)

VPC CIDR을 용도·역할별로 분할한 하위 네트워크 구간 반드시 하나의 AZ에만 속하며, AZ 간 중복 불가

VPC: 10.10.0.0/16
│
├── [AZ-a]
│   ├── Public  Subnet  10.10.1.0/24  ← 인터넷 직접 연결 가능
│   ├── Private Subnet  10.10.3.0/24  ← NAT 통해 아웃바운드만 가능
│   └── Isolated Subnet 10.10.5.0/24  ← 인터넷 완전 차단 (DB 전용)
│
└── [AZ-c]
    ├── Public  Subnet  10.10.2.0/24
    ├── Private Subnet  10.10.4.0/24
    └── Isolated Subnet 10.10.6.0/24

서브넷 유형 비교

Bastion Host (배스천 호스트)

• Private Subnet 내 리소스에 SSH로 안전하게 접근하기 위한 경유 서버
• Public Subnet에 위치하며, 관리자 IP에서만 SSH 허용.

03. 인터넷 게이트웨이 (Internet Gateway, IGW)

VPC와 인터넷 사이의 양방향 통신 출입문

IGW 동작의 3가지 필수 조건

조건 ①  VPC에 IGW가 연결(Attach)되어 있어야 함
조건 ②  서브넷의 Route Table에 0.0.0.0/0 → IGW 경로가 있어야 함
조건 ③  EC2 인스턴스에 Public IP 또는 Elastic IP가 할당되어 있어야 함

→ 3가지 중 하나라도 누락 시 인터넷 통신 불가.
   "EC2에 접속이 안 될 때" 이 세 가지를 순서대로 확인.

04. 라우트 테이블 (Route Table)

패킷의 목적지 IP를 보고 어디로 보낼지 결정하는 규칙 테이블

서브넷 유형별 Route Table 설계

Public RT (public-2a, public-2c 공통 연결)

Private RT — AZ-a (private-app-2a 연결)

Private RT — AZ-c (private-app-2c 연결)

Isolated RT (isolated-db-2a, isolated-db-2c 공통 연결)

05. NAT Gateway

Private Subnet의 리소스가 인터넷으로 나가는 아웃바운드 통신만 허용하는 관리형 서비스

[Private Subnet의 EC2]
       │  아웃바운드 요청 (예: apt update, S3 패키지 다운로드)
       ▼
[NAT Gateway]  ← 반드시 Public Subnet에 위치. Elastic IP 보유.
       │  사설 IP → 공인 IP(EIP)로 변환 (SNAT)
       ▼
[Internet Gateway] → 인터넷

06. Elastic IP (EIP)

AWS 계정에 고정 할당되는 Public IPv4 주소 EC2를 재시작해도 IP가 변경되지 않음.

VPC 실습

보안 계층 — Security Group & NACL

01. AWS 2중 방화벽 구조 전체 흐름

• AWS VPC는 서브넷 레벨(NACL)과 인스턴스 레벨(Security Group) 2중 방어 구조
• 두 계층이 모두 통과되어야 EC2 인스턴스에 트래픽이 도달

인터넷
  │
  ▼
[Internet Gateway]
  │
  ▼
[Route Table]               ← 목적지 판단. 경로가 없으면 여기서 차단.
  │
  ▼
┌─────────────────────────────────────────────────┐
│  서브넷 경계                                     │
│  ① Network ACL (NACL)                           │
│     → 서브넷 레벨, Stateless                     │
│     → Allow / Deny 모두 가능                     │
│     → 규칙 번호 순서대로 평가, 일치 즉시 적용     │
│  ┌─────────────────────────────────────────┐    │
│  │  인스턴스 경계                           │    │
│  │  ② Security Group (SG)                  │    │
│  │     → ENI(인스턴스) 레벨, Stateful       │    │
│  │     → Allow만 가능 (Deny 불가)           │    │
│  │     → 모든 규칙을 종합 평가              │    │
│  │  [ EC2 Instance ]                       │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

트래픽 인바운드: IGW → RT → NACL 인바운드 → SG 인바운드 → EC2
트래픽 아웃바운드: EC2 → SG 아웃바운드 → NACL 아웃바운드 → IGW

02. Security Group (SG)

EC2 인스턴스(정확히는 ENI)에 적용되는 인스턴스 레벨 가상 방화벽

SG 핵심 특성

03. Network ACL (NACL)

서브넷에 연결되는 서브넷 레벨 방화벽

NACL 핵심 특성

NACL 규칙 번호 평가 방식

인바운드 규칙 예시:

Rule # | Type   | Protocol | Port      | Source        | Action
-------|--------|----------|-----------|---------------|-------
  50   | Custom | TCP      | 80        | 1.2.3.4/32    | DENY    ← 특정 IP 긴급 차단
 100   | HTTP   | TCP      | 80        | 0.0.0.0/0     | ALLOW
 110   | HTTPS  | TCP      | 443       | 0.0.0.0/0     | ALLOW
 120   | SSH    | TCP      | 22        | 관리자IP/32   | ALLOW
 900   | Custom | TCP      | 1024-65535| 0.0.0.0/0     | ALLOW   ← Ephemeral 필수
   *   | All    | All      | All       | 0.0.0.0/0     | DENY    ← 기본 거부

→ 1.2.3.4에서 80 포트: Rule 50 DENY → 즉시 차단. Rule 100 미평가
→ 5.6.7.8에서 80 포트: Rule 50 불일치 → Rule 100 ALLOW → 통과

- 규칙 번호: 낮은 번호 -> 높은 번호 (우선순위결정)
-- 1 ~ 32766 사용 가능
-- 32767(AWS 예약번호이므로 사용 불가능)

-- 1 ~ 99: 긴급 차단 용도
-- 100 ~ 200: 주요허용 규칙
-- 900 ~ 999: 임시 포트 등의 규칙

SG vs NACL 완전 비교표

04. VPC Flow Logs

VPC 내 모든 네트워크 인터페이스(ENI)를 통과하는 IP 트래픽 메타데이터를 기록하는 기능

정리

내용 요약

① 2중 방화벽 구조
   인터넷 → IGW → RT → NACL → SG → EC2
   NACL이 외부 방어선, SG가 내부 방어선.

② Security Group
   인스턴스(ENI) 레벨, Stateful, Allow만.
   SG 간 참조 패턴이 실무 표준.
   아웃바운드 ALL 규칙 없어도 인바운드 허용된 연결의 응답은 자동 통과.

③ Network ACL
   서브넷 레벨, Stateless, Allow+Deny.
   Ephemeral Port(1024~65535) 아웃바운드 허용 필수.
   규칙 번호 낮은 것이 우선. DENY가 ALLOW보다 낮은 번호여야 차단됨.
   NACL 변경 → 기존 연결도 즉시 영향.

④ Stateless 체험 실험 핵심
   "인바운드는 허용했는데 응답이 없다" = NACL 아웃바운드 Ephemeral Port 누락.
   SG는 Stateful이라 이 현상 발생 안 함.

⑤ VPC Flow Logs
   REJECT 로그가 보이면 SG 또는 NACL 규칙 문제.
   ACCEPT인데 연결이 안 된다면 애플리케이션 레벨 문제.

클라우드 아키텍처 및 기획 (프로젝트)

1. 프로젝트 개요

• 주제 : 학습노트 기반 quiz 생성하는 서비스 (서비스명 : Note2Quiz)
• 개발 기간 : 2025.03.31 ~ 2025.04.03 (4일)
• 팀 구성 : 6명 (Frontend 3명, Backend 3명)
• 한 줄 요약 : 사용자가 업로드한 학습 노트를 Google Gemini AI가 분석하여 맞춤형 복습 퀴즈를 자동으로 생성해 주는 서비스
• GitHub : CLD-05/team01_Note2Quiz

2. 기술 스택 (Tech Stack)

이번 프로젝트에서 학습 노트(Note) 관련 핵심 비즈니스 로직 설계와 API 구현을 중점적으로 담당

• 노트 목록 조회 (GET /api/notes)
  • 보안 및 정렬: 로그인한 사용자의 노트만 필터링하여 반환하며, 사용 편의를 위해 최신순 정렬을 적용
  • 맞춤형 DTO 설계: 목록 조회 시 wordCount, preview 등 프론트엔드 메인 화면 구성에 꼭 필요한 데이터만 담아 응답 효율을 높임
• 노트 상세 조회 (GET /api/notes/{noteId})
  • 권한 체크: 특정 노트에 접근 시 해당 노트의 소유주와 로그인 사용자가 일치하는지 검증하는 로직을 추가하여 데이터 보안을 강화
• 노트 삭제 (DELETE /api/notes/{noteId})
  • 연쇄 삭제(CASCADE) 구현: 부모 엔티티(notes) 삭제 시 연관된 quiz_sets와 하위 quizzes 데이터가 함께 정리되도록 설계하여 데이터 무결성을 보장

✅ API 응답 최적화 및 커스텀

• Jackson 어노테이션 활용: @JsonInclude(JsonInclude.Include.NON_NULL)을 도입
• 이를 통해 null 값인 필드는 응답에서 자동으로 제외되도록 처리하여, 네트워크 전송량을 최적화하고 프론트엔드에서 불필요한 데이터를 처리하는 비용을 줄임

백엔드 서버 기초 세팅과정에서 생긴 문제

개인적으로 준비해 보았던 클라우드 아키텍처 설계

클라우드 아키텍처 설계

이번 프로젝트의 핵심 목표 중 하나인 고가용성(High Availability), 보안성(Security), 확장성(Scalability)을 확보하기 위해 AWS의 디자인 패턴을 적용하여 설계한 아키텍처

아키텍처 구조 (Conceptual Diagram)

                                 [ 사용자 (Client) ]
                                         |
                                         v
+---------------------------------------------------------------------------------------+
|               1. DNS & 전용 최적화: Route 53 + CloudFront (Global Edge)                 |
|                   (사용자 요청 수신 및 프론트엔드 정적 리소스 초고속 배포)                    |
+---------------------------------------------------------------------------------------+
                                         |
                                         v
+---------------------------------------------------------------------------------------+
|                    2. 부하 분산: Application Load Balancer (ALB)                       |
|                     (L7 레이어 트래픽 분산 및 가용 영역별 상태 확인)                        |
+---------------------------------------------------------------------------------------+
                                         |
            +------+---------------------+--------------------------------+
            |                            |                                |
    [ 가용 영역 A (AZ-1) ]        [ 가용 영역 B (AZ-2) ]            [ 외부 서비스 연동 ]
|      (Seoul-1a)            |      (Seoul-1c)            |                              |
|                            |                            |                              |
|  +----------------------+  |  +----------------------+  |                              |
|  |  Public Subnet       |  |  |  Public Subnet       |  |                              |
|  |  [ NAT Gateway A ]   |  |  |  [ NAT Gateway B ]   |  |                              |
|  +----------|-----------+  |  +----------|-----------+  |                              |
|             v              |             v              |                              |
|  +----------------------+  |  +----------------------+  |   +-----------------------+  |
|  |  Private Subnet (App)|  |  |  Private Subnet (App)|  |   |  [ Google Cloud ]     |  |
|  |  [ EC2 Instance 1 ]  | <|> |  [ EC2 Instance 2 ]  | <==> |   **Gemini AI API**   |  |
|  |  (Spring Boot API)   |  |  |  (Spring Boot API)   |  |   |   (gemini-2.5-flash)  |  |
|  +----------|-----------+  |  +----------|-----------+  |   +-----------------------+  |
|             v              |             v              |             ^                |
|  +----------------------+  |  +----------------------+  |             |                |
|  |  Private Subnet (DB) |  |  |  Private Subnet (DB) |  |             |                |
|  |  [ RDS MySQL ]       | <==>|  [ RDS Standby ]     |  |             |                |
|  |  (Primary/Write)     |  |  |  (Read Replica)      | <---   AI 생성 데이터 저장        |
|  +----------------------+  |  +----------------------+  |                              |
|                            |                            |                              |
+----------------------------+-----------------------------------------------------------+
                                          |
                                          v
+---------------------------------------------------------------------------------------+
|                3. 미디어 저장소: S3 Bucket (Cross-Region Replication)                   |
|                     (업로드 파일 및 AI 생성 콘텐츠의 내구적 저장)                           |
+---------------------------------------------------------------------------------------+

서비스 선정 이유

설계 과정에서의 아쉬운 점 (Self-Review)

AWS Overview를 통해 학습한 내용을 바탕으로 고가용성 아키텍처를 설계해 보았으나, 짧은 기간 내에 실제 서비스 수준의 정교한 기획을 담아내기에는 지식의 깊이 면에서 아쉬움이 남았습니다.

1. 네트워크 레벨의 디테일 부족: 서브넷 마스크(CIDR) 설정이나 구체적인 라우팅 테이블 구성 등, VPC 내부의 세밀한 네트워크 설계를 기획서에 완벽히 녹여내지 못한 점이 아쉬웠습니다.
2. 시각화 및 표준화 미비: draw.io와 같은 전문 툴을 활용하여 클라우드 표준 다이어그램 형태로 시각화하지 못해 설계의 직관성이 다소 부족했습니다. 추후에는 더 정교한 아키텍처 맵을 작성해 볼 계획입니다.
3. 이론과 실제의 간극: 학습한 디자인 패턴을 이론적으로 배치하는 것에 그치지 않고, 각 리소스 간의 실제 통신 비용이나 성능 병목 지점까지 고려한 깊이 있는 설계에 도전해 보고 싶습니다.

마치며...

이번 미니 프로젝트는 단순히 API를 개발하는 것을 넘어, 프론트엔드와 백엔드를 통합하는 과정에서 고려해야 할 상황이 예상보다 훨씬 많다는 것을 배운 소중한 시간이었습니다.

특히 의사소통이 프로젝트의 성패를 결정짓는다는 것을 뼈저리게 깨달았습니다. 원활한 협업을 위한 명확한 API 명세와 데이터 규격 설계가 얼마나 중요한지 체감할 수 있었습니다.

비록 짧은 기간이었지만 서비스 기획부터 구현, 그리고 클라우드 아키텍처 설계까지 전체 사이클을 직접 완주해 보았다는 점에서 큰 성취감을 느꼈습니다.

• 현상: STS(Spring Tool Suite)에서 Import Maven Projects를 시도했으나, 리스트에 pom.xml은 뜨지만 체크박스가 비활성화되어 선택할 수 없고 Finish 버튼도 작동하지 않는 현상 발생.

2. 원인 분석 (Cause)

원인 1: Windows 경로 길이 제한 (MAX_PATH)

• 폴더 깊이가 너무 깊으면 인덱싱 및 파일 접근 에러가 발생할 수 도 있음

원인 2: 이미 워크스페이스에 동일한 이름의 프로젝트가 존재

• 기존 워크스페이스에 동일한 artifactId를 가진 프로젝트가 이미 등록되어 있을 경우 중복 임포트가 차단됨.

원인 3: 이전 설정 파일과의 충돌

• 이전에 다른 IDE나 환경에서 생성된 .project, .settings 등의 메타데이터가 현재 환경과 충돌할 수 있음.

3. 해결 방법 (Solution)

방법 1: 경로 단순화

• 프로젝트 폴더를 드라이브 루트에 가까운 경로로 이동시켜 경로 길이를 단축.

방법 2: 중복 프로젝트 확인 및 삭제

• Package Explorer에서 이름이 겹치는 프로젝트를 삭제(Delete)하여 충돌 제거

방법 3: .project 및 .settings 파일 정리

• 폴더 내의 .project, .classpath 파일과 .settings 폴더를 삭제하여 설정 정보 초기화

4. 최종 해결 (Action Taken)

"경로 최적화 + 워크스페이스 신규 생성”

• 프로젝트 경로를 단순하게 변경함.
• test 라는 이름의 새로운 워크스페이스(Workspace)를 생성하여 기존의 꼬여있던 메타데이터 간섭을 완전히 차단

5. 회고 (Retrospective)

• 개발 환경에서 프로젝트 경로는 최대한 짧고 간결하게 관리하는 것이 예기치 못한 에러를 방지하는 지름길임을 깨달음
• 원인 파악이 힘들 때는 기존 설정을 고치려 하기보다, 새로운 워크스페이스를 생성하여 클린한 상태에서 재시작하는 것이 훨씬 효율적인 해결책이 될 수 있음을 배움

원인 : STS 프로젝트가 로컬(우분투)에서 MySQL 서버를 실행 중이라 기본 포트인 3306을 점유하고 있었다. 이로 인해 포트 충돌이 발생하여 Docker 컨테이너가 시작되지 못했다.

해결책 1 : 로컬 MySQL 서버 정지

가급적 MySQL 전용 포트(3306)를 그대로 사용하는 것이 관리 면에서 효율적

sudo systemctl stop mysql

해결책 2: 포트번호를 변경하여 실행 (포트 포워딩 변경)

docker run -p 3307:3306 --name mysql-container -e MYSQL_ROOT_PASSWORD=password -d mysql

추가 이슈: 이름 충돌

포트 문제를 해결한 뒤 다시 실행했을 때 에러 발생

원인 : 이전에 실행에 실패한 컨테이너가 이름만 점유한 채 남아 있어 이름 충돌 발생

해결책 : 재실행 필요 (or 기존 컨테이너 삭제하고 다시 생성)

docker rm -f [컨테이너_이름]

성공 화면

bash 명령어를 파일로 저장하여 반복 실행 가능하게 만든 자동화 스크립트 (배포 자동화, 로그 정리, 모니터링 알림 등 DevOps 업무의 핵심 도구)

기본 구조

#!/bin/bash
# 스크립트 설명 주석

# 변수 선언
APP_NAME="myapp"

# 명령어 실행
echo "Starting $APP_NAME"

# 실행 권한 부여 및 실행
chmod +x script.sh
./script.sh
bash script.sh      # 권한 없이 실행 가능

조건문

# if 기본 구조
# 대괄호 안에 공백 필수!
# fi : if문의 끝을 알림
if [ 조건 ]; then
    명령어
elif [ 조건 ]; then
    명령어
else
    명령어
fi    

비교 연산자

반복문

함수

# 함수 선언
function 함수명() {
    명령어
    return 반환값    # 0~255, 생략 시 마지막 명령 종료 코드
}

# 또는
함수명() {
    명령어
}

# 호출
함수명
함수명 인자1 인자2    # 인자 전달 시 함수 내에서 $1, $2로 참조

종료 코드 & 에러 처리

셸 스크립트로 배포 자동화

#!/bin/bash
# deploy.sh — Spring Boot 자동 배포 스크립트
# 사용법: ./deploy.sh [브랜치명]  (기본: main)
set -euo pipefail

# 설정 변수
# 깃허브 레파지토리 루트 경로
REPO_DIR="/home/ubuntu/infra-basic-deploy-lab"
# 앱 루트경로
APP_DIR="/home/ubuntu/infra-basic-deploy-lab/infra-basic-deploy-lab"
# 빌드 결과(아티팩트)
JAR_PATTERN="infra-basic-deploy-lab-*.jar"
# 앱 실행 결과 로그
LOG_FILE="/home/ubuntu/infra-basic-deploy-lab/app.log"
# 배포 과정 결과 로그
DEPLOY_LOG="/home/ubuntu/infra-basic-deploy-lab/deploy.log"
# 인자 없다면 main 브랜치 기준
BRANCH="${1:-main}"
PORT=8080
HEALTH_URL="http://localhost:${PORT}/api/backend"
# 헬스체크 최대 대기(초)
MAX_WAIT=30

# 로그 함수
log() {
    local MSG="[$(date '+%Y-%m-%d %H:%M:%S')] $1"
    echo "$MSG" | tee -a "$DEPLOY_LOG"
}

# 1) Git Pull
pull_latest() {
    log "=== 배포 시작: branch=$BRANCH ==="

    # [힌트] git clone된 루트 폴더(.git)로 이동
    # [힌트] git fetch origin
    # [힌트] $BRANCH 로 checkout
    # [힌트] $BRANCH 를 pull
    # ?
    cd "$REPO_DIR"
    git fetch origin
    git checkout "$BRANCH"
    git pull origin "$BRANCH"

    log "Git pull 완료"
}

# 2) Maven 빌드
build_jar() {
    log "Maven 빌드 시작..."

    # [힌트] $APP_DIR 로 이동 (pom.xml 위치)
    # [힌트] Step 2에서 서버 빌드할 때 쓴 명령어 사용 (테스트 스킵, -q 옵션 추가)
    # ?
    cd "$APP_DIR"
    mvn clean package -DskipTests -q
    log "빌드 완료: $(ls target/$JAR_PATTERN)"
}

# 3) 기존 프로세스 종료
stop_app() {
    local PID
    PID=$(pgrep -f "$JAR_PATTERN" || true)

    # [힌트] $PID 가 비어있지 않으면 (-n) 종료 처리
    #         kill 후 최대 10초 대기하며 프로세스가 사라졌는지 확인
    #         비어있으면 "실행 중인 프로세스 없음" 로그 출력
    # ?
    if [ -n "$PID" ]; then
        log "기존 프로세스 종료: PID=$PID"
        kill "$PID"
        for i in {1..10}; do
            if ! pgrep -f "$JAR_PATTERN" > /dev/null; then
                log "프로세스 종료 확인"
                break
            fi
        done
    else
        log "실행 중인 프로세스 없음"
    fi
}

# 4) 앱 시작
start_app() {
    local JAR
    JAR=$(ls "$APP_DIR"/target/$JAR_PATTERN | head -1)

    # [힌트] $APP_DIR 로 이동
    # [힌트] nohup 으로 $JAR 백그라운드 실행
    #         stdout/stderr 는 $LOG_FILE 로 저장
    # ?
    log "앱 시작: $JAR"
    cd "$APP_DIR"
    nohup java -jar "$JAR" > "$LOG_FILE" 2>&1 &
    log "PID: $!"
}

# 5) 헬스 체크
health_check() {
    log "헬스 체크 대기 중 (최대 ${MAX_WAIT}초)..."

    # [힌트] 1초 간격으로 $MAX_WAIT 회 반복
    #         curl -sf 로 $HEALTH_URL 에 요청
    #         성공하면 "배포 성공" 로그 출력 후 return 0
    #         반복이 끝날 때까지 응답 없으면 아래 return 1 실행
    # ?
    for i in $(seq 1 $MAX_WAIT); do
        if curl -sf "$HEALTH_URL" > /dev/null 2>&1; then
            log "배포 성공: $HEALTH_URL 응답 확인 (${i}초 소요)"
            return 0
        fi
        sleep 1
    done

    log "배포 실패: ${MAX_WAIT}초 내 응답 없음"
    return 1
}

# 메인 실행
pull_latest
build_jar
stop_app
start_app
health_check

log "=== 전체 배포 완료 ==="

Docker : 컨테이너 기술을 기반으로 한 오픈소스 가상화 플랫폼

• 애플리케이션과 그 실행 환경을 컨테이너(Container) 단위로 패키징하여 어디서든 동일하게 실행 가능

• Client
  • 명령어, API로 Host와 통신
    • docker build
    • docker pull
    • docker push
    • docker run
  • 입력한 명령어는 터미널을 통해 docker daemon으로 전송
• Host
  • 환경 및 어플리케이션 실행
  • Daemon, Image, Container, Network, Storage, …
• Registry
  • Image를 관리하고 저장
    • Public Registry : Docker Hub
    • Private Registry : 개인, 기업

기본 동작

# 실행 중인 컨테이너 확인
docker ps

# nginx 컨테이너 실행 (이미지 자동 pull)
docker run -d -p 80:80 nginx

# 실행 중인 컨테이너 확인
docker ps

# 컨테이너 중지
docker stop <컨테이너ID 또는 이름>

# 전체 컨테이너 확인 (중지 포함)
docker ps -a

# Docker 시스템 전체 정보
docker system info

# 컨테이너 로그 확인
docker logs <컨테이너ID>

Docker Image

• 컨테이너 실행에 필요한 읽기 전용(Read-Only) 템플릿
• 소스 코드, 라이브러리, 런타임, 설정 파일 등 애플리케이션 실행에 필요한 모든 것을 포함
• 한 번 빌드된 이미지는 변경 불가(Immutable) — 동일한 환경을 어디서나 재현 가능

이미지 레이어 구조

┌────────────────────────────────┐
│  Container Layer (R/W)         │  ← 컨테이너 실행 시 생성되는 쓰기 레이어
├────────────────────────────────┤
│  COPY index.html (Layer 4)     │  ← Dockerfile 각 명령어가 레이어 생성
├────────────────────────────────┤
│  RUN apt-get install (Layer 3) │
├────────────────────────────────┤
│  RUN apt-get update  (Layer 2) │
├────────────────────────────────┤
│  FROM ubuntu:22.04   (Layer 1) │  ← Base Image
└────────────────────────────────┘

레이어 특징

# 로컬 이미지 목록
docker images
docker image ls

# 이미지 검색 (Docker Hub)
docker search <키워드>

# 이미지 다운로드
docker pull <이미지명>:<태그>
docker pull nginx           # latest 태그 (기본값)
docker pull nginx:1.25
docker pull openjdk:17

# 이미지 상세 정보
docker image inspect <이미지명>

# 이미지 레이어 히스토리
docker history <이미지명>

# 이미지 삭제
docker rmi <이미지명 또는 ID>
docker rmi -f <이미지명>         # 강제 삭제 (실행 중 컨테이너 이미지 포함)

# 전체 이미지 삭제
docker rmi $(docker images -q)
docker rmi -f $(docker images -q)

# 이미지 태그 추가
docker tag <기존이미지> <새이름>:<태그>

# 이미지 tar 파일로 내보내기
docker save -o <파일명>.tar <이미지명>

# tar 파일에서 이미지 불러오기
docker load -i <파일명>.tar

docker image prune — 미사용 이미지 정리

Docker Container

• Docker Image를 실행한 인스턴스 — 실제 프로세스 동작 단위
• 이미지는 불변(Read-Only), 컨테이너는 이미지 위에 쓰기 가능한 레이어를 추가하여 동작

실행

# 기본 실행
docker run <이미지명>

# 주요 옵션
docker run [옵션] <이미지명> [명령어]

-d              # 백그라운드(Detached) 실행
-it             # 대화형 터미널 연결 (-i: 표준입력 유지, -t: TTY 할당)
--name <이름>   # 컨테이너 이름 지정
-p <호스트포트>:<컨테이너포트>   # 포트 매핑
-v <호스트경로>:<컨테이너경로>   # 볼륨/바인드 마운트
--rm            # 컨테이너 종료 시 자동 삭제
--network <네트워크명>           # 네트워크 지정
-e <KEY>=<VALUE>                # 환경변수 설정
--restart <policy>              # 재시작 정책 (no/always/on-failure/unless-stopped)

삭제

# 컨테이너 삭제 (중지 상태여야 함)
docker rm <컨테이너명>

# 강제 삭제 (실행 중이어도)
docker rm -f <컨테이너명>

# 중지된 컨테이너 전체 삭제
docker container prune

# 전체 컨테이너 삭제
docker rm $(docker ps -aq)
docker stop $(docker ps -aq) && docker rm $(docker ps -aq)

docker exec — 컨테이너 내부 명령 실행

Dockerfile

• Docker 이미지를 생성하기 위한 명령어 스크립트 파일
• 확장자 없이 Dockerfile 이라는 이름으로 저장

# FROM — 베이스 이미지 지정 (항상 첫 줄)
FROM ubuntu:22.04
FROM openjdk:17-jdk-slim
FROM nginx:alpine

# RUN — 이미지 빌드 시 실행할 명령어 (새 레이어 생성)
RUN apt-get update && \
    apt-get install -y curl git && \
    rm -rf /var/lib/apt/lists/*

# COPY — 호스트 파일 → 이미지로 복사
COPY index.html /usr/share/nginx/html/index.html
COPY ./target/app.jar /app.jar

# ADD — COPY + URL 다운로드, tar 자동 압축해제 가능
ADD https://example.com/file.tar.gz /tmp/

# WORKDIR — 이후 명령어의 작업 디렉터리 지정 (없으면 자동 생성)
WORKDIR /app

# ENV — 환경변수 설정 (이미지 빌드 + 컨테이너 실행 시 모두 유효)
ENV JAVA_OPTS="-Xmx512m"
ENV APP_PORT=8080

# EXPOSE — 컨테이너가 사용할 포트 명시 (실제 포트 오픈은 docker run -p 로)
EXPOSE 8080

# CMD — 컨테이너 시작 시 기본 실행 명령어 (docker run 인자로 덮어쓰기 가능)
CMD ["nginx", "-g", "daemon off;"]

# ENTRYPOINT — 컨테이너 시작 시 고정 실행 명령어 (덮어쓰기 불가)
ENTRYPOINT ["java", "-jar", "/app.jar"]

# ARG — 빌드 시에만 사용되는 변수 (docker build --build-arg 로 전달)
ARG APP_VERSION=1.0.0

# VOLUME — 마운트 포인트 지정
VOLUME ["/var/log/app"]

# USER — 명령어 실행 사용자 변경 (보안상 root 대신 일반 유저 사용)
USER appuser

CMD vs ENTRYPOINT 비교

docker build (이미지 생성)

# 기본 빌드
docker build -t <이미지명>:<태그> <Dockerfile경로>

# 현재 디렉터리의 Dockerfile로 빌드
docker build -t myapp:1.0 .

# 태그 없으면 latest 자동 부여
docker build -t myapp .

# 빌드 인자 전달
docker build --build-arg APP_VERSION=2.0 -t myapp:2.0 .

# 캐시 사용 안 함 (완전 새로 빌드)
docker build --no-cache -t myapp:1.0 .

# 멀티플랫폼 빌드 (ARM/AMD64 모두 지원)
docker buildx build --platform=linux/amd64,linux/arm64 -t myapp:1.0 .

DockerHub 이미지 Push/Pull

# Docker Hub 로그인
docker login

# 이미지에 Hub 태그 추가
docker tag <로컬이미지명> <DockerHub_ID>/<Repository명>:<태그>
docker tag myapp:1.0 myid/myrepo:1.0

# 이미지 Push
docker push <DockerHub_ID>/<Repository명>:<태그>
docker push myid/myrepo:1.0

# 이미지 Pull
docker pull <DockerHub_ID>/<Repository명>:<태그>

Docker Volume

컨테이너 외부에 데이터를 저장하여 컨테이너 재생성 후에도 데이터를 유지하는 메커니즘

(컨테이너는 삭제되면 내부 데이터가 모두 소멸 - 데이터 영속화가 필요)

방식별 비교

Bind Mount

• 호스트의 특정 디렉터리를 그대로 컨테이너에 마운트
• 양쪽에서 변경사항이 즉시 반영

docker run -v <호스트절대경로>:<컨테이너경로> <이미지명>
# 또는
docker run --mount type=bind,source=<호스트경로>,target=<컨테이너경로> <이미지명>

# 예시
# nginx html 디렉터리를 호스트 로컬 디렉터리로 마운트
docker run --name webserver -d -p 8080:80 \
  -v /home/ubuntu/webroot:/usr/share/nginx/html \
  nginx

# 호스트에서 파일 수정 → 컨테이너에 즉시 반영
echo "<h1>Updated</h1>" > /home/ubuntu/webroot/index.html

Volume

• Docker가 직접 관리하는 스토리지 — 호스트 파일시스템에 종속되지 않음
• 컨테이너 삭제 후에도 데이터 유지, 컨테이너 간 공유 가능

명령어

# Volume 생성
docker volume create <볼륨명>

# Volume 목록 확인
docker volume ls

# Volume 상세 정보
docker volume inspect <볼륨명>

# Volume 실제 데이터 경로 확인
sudo ls /var/lib/docker/volumes/<볼륨명>/_data

# Volume 삭제
docker volume rm <볼륨명>

# 사용하지 않는 Volume 전체 삭제
docker volume prune

컨테이너에 Volume 연결

# -v 옵션으로 Volume 연결
docker run --name mysql-server \
  -v mysql-data:/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=root \
  -d mysql:8.0

# --mount 옵션으로 Volume 연결 (명시적)
docker run --name mysql-server \
  --mount type=volume,source=mysql-data,target=/var/lib/mysql \
  -e MYSQL_ROOT_PASSWORD=root \
  -d mysql:8.0

Docker Network

• 각 컨테이너는 격리된 네트워크 환경에서 독립적인 IP를 가짐
• 서로 다른 컨테이너가 통신하려면 Docker Network를 통해 연결 필요

네트워크 드라이버 종류

명령어

# 네트워크 목록 확인
docker network ls

# 네트워크 상세 정보
docker network inspect <네트워크명>

# 사용자 정의 네트워크 생성
docker network create <네트워크명>
docker network create --driver bridge <네트워크명>

# 실행 시 네트워크 지정
docker run --network <네트워크명> <이미지명>

# 실행 중인 컨테이너에 네트워크 연결
docker network connect <네트워크명> <컨테이너명>

# 컨테이너에서 네트워크 해제
docker network disconnect <네트워크명> <컨테이너명>

# 네트워크 삭제 (연결된 컨테이너 없어야 함)
docker network rm <네트워크명>

# 사용하지 않는 네트워크 전체 삭제
docker network prune

Docker Compose

• 여러 컨테이너를 하나의 YAML 파일(docker-compose.yml)로 정의하고 한 번에 실행·관리하는 도구
• 여러 docker run 명령어를 파일 하나로 통합 → 서비스 기동/중지/재시작 단순화

Compose 파일

사람이 읽고 쓰기 아주 편하게 만들어진 데이터 직렬화(Data Serialization) 양식

문법

# 주석 — # 사용

# key: value 형식
name: myapp
port: 8080

# 들여쓰기 — 2칸 또는 4칸 (탭 사용 금지)
database:
  host: localhost
  port: 3306

# 배열 / 리스트
ports:
  - "8080:8080"
  - "3306:3306"

# boolean
debug: true
production: false

# 멀티라인 (| : 줄바꿈 유지)
command: |
  echo "hello"
  echo "world"

# 멀티라인 (> : 줄바꿈을 공백으로 변환)
description: >
  This is a long
  description text.

.env 파일로 민감 정보 분리

• docker-compose.yml 에 패스워드, 시크릿 키 등을 하드코딩하면 Git에 노출되는 보안 위험
• .env 파일에 민감 정보를 분리하고 Compose에서 변수로 참조

docker-compose.yml 에서 .env 파일 참조

services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    ports:
      - "3306:3306"

  backend:
    build: 
    ports:
      - "${APP_PORT}:8080"

.env 파일 예시

# .env
MYSQL_ROOT_PASSWORD=prod_root_secret
MYSQL_DATABASE=appdb
MYSQL_USER=appuser
MYSQL_PASSWORD=prod_user_secret
APP_PORT=8080

Docker Compose 명령어

# 서비스 시작 (백그라운드)
docker-compose up -d

# Dockerfile 변경사항 반영하여 재빌드 후 시작
docker-compose up --build -d

# 실행 중인 서비스 목록
docker-compose ps

# 서비스 로그 확인
docker-compose logs
docker-compose logs -f backend      # 특정 서비스 실시간 로그

# 서비스 중지
docker-compose stop

# 서비스 시작
docker-compose start

# 서비스 재시작
docker-compose restart

# 서비스 종료 및 컨테이너 삭제 (볼륨은 유지)
docker-compose down

# 서비스 종료 및 볼륨까지 삭제
docker-compose down -v

# 특정 서비스만 실행
docker-compose up -d db

# .env 파일 변수 치환 결과 확인 (실제 실행 전 검증)
docker-compose config

2-Tier (Client / Server) 환경

인터넷이 보급되기 전, 기업들은 폐쇄된 내부 네트워크에서 GUI 클라이언트가 DB 서버에 직접 접속하는 방식으로 업무를 처리

• 대부분의 비즈니스 로직이 클라이언트 측에 존재
• DB는 데이터 저장/조회 역할만 담당

3-Tier 환경

클라이언트와 DB 사이에 애플리케이션 계층을 추가한 구조

N-Tier 환경

3-Tier에서 Application 계층 내부를 역할별로 분리한 구조 목적 : 재사용

[curl / 브라우저]            ← Presentation 계층
       ▼
[backend-server]             ← Application 계층 (Spring Boot)
  @RestController               ┌─ @Controller  (요청/응답)
  @Service                      ├─ @Service     (비즈니스 로직)
  @Repository                   └─ @Repository  (DB 접근)
       ▼
[mysql-server]               ← Database 계층
  (MySQL 8.0)

Docker Compose가 N-Tier를 구현하는 방식

N-tier Application 구성 (Spring Boot + MySQL)

• Docker를 활용하여 Spring Boot 백엔드 서버와 MySQL DB를 컨테이너로 구성하는 실무 아키텍처
• 서비스 간 통신은 사용자 정의 네트워크 + 컨테이너 이름(DNS) 으로 처리

Spring Boot 프로젝트 생성 → 깃허브와 연동 → DB세팅 → Dockerfile 작성 → Docker Compose 구성

! Dockerfile의 경로가 중요함 !

구조

**Case A — 하위 디렉터리에 프로젝트**

**my-project/ ← 작업 루트
├── docker-compose.yml
├── Dockerfile ← 여기 위치
└── backend/ ← 프로젝트**
├── src/
├── pom.xml
└── mvnw

**# Dockerfile**
COPY backend/src ./src
COPY backend/pom.xml .
COPY backend/mvnw .

**# docker-compose.yml**
build:
context: . ← my-project/

**Case B — 프로젝트가 루트 디렉터리

backend/ ← 작업 루트 = 프로젝트**
├── src/
├── pom.xml
├── mvnw
**├── docker-compose.yml
└── Dockerfile ← 여기 위치

# Dockerfile**
COPY src ./src
COPY pom.xml .
COPY mvnw .

**# docker-compose.yml**
build:
context: . ← backend/

클라우드 컴퓨팅

• 인터넷으로 서버, 스토리지, 데이터베이스, 네트워크 등 IT 자원을 필요할 때, 필요한 만큼 사용하는 방식
• 온디맨드(On-Demand), 사용량 기반 과금(Pay-as-you-go), 탄력성(Elasticity)

온프레미스 vs 클라우드

온프레미스 (On-Premises) 서버, 네트워크 장비, 데이터센터를 회사가 직접 소유·운영하는 방식. 하드웨어부터 데이터까지 완전한 통제권 보유

클라우드 (Cloud) AWS·GCP·Azure 등 사업자의 인프라를 빌려 쓰는 방식. 물리 인프라 관리는 사업자가 담

클라우드 컴퓨팅의 5가지 특성

클라우드 서비스 모델 (IaaS / PaaS / SaaS)

클라우드 배포 모델

리전 (Region)

• AWS 데이터센터가 물리적으로 모여 있는 지리적 단위
• 각 리전은 완전히 독립적 — 한 리전 장애가 다른 리전에 영향 없음

가용 영역 (Availability Zone, AZ)

• 리전 내에서 물리적으로 분리된 독립 데이터센터 그룹
• 서로 다른 전력, 냉각, 네트워크 인프라 사용 → 하나의 AZ 장애가 다른 AZ에 전파 안 됨

엣지 로케이션 (Edge Location)

• 사용자와 가장 가까운 위치에서 콘텐츠를 캐싱/제공하는 거점

AWS 책임 공유 모델

┌──────────────────────────────────────────────┐
│              고객 책임                       │
│                                              │
│  데이터 암호화 여부      IAM 사용자/권한 관리  │
│  OS 패치 (EC2)          네트워크/SG 설정      │
│  애플리케이션 보안       S3 버킷 공개 설정     │
│                                              │
├──────────────────────────────────────────────┤
│              AWS 책임                        │
│                                              │
│  물리적 서버/네트워크 장비                    │
│  데이터센터 보안 (출입 통제)                  │
│  하이퍼바이저 (가상화 레이어)                 │
│  리전/AZ 인프라 운영                          │
│                                              │
└──────────────────────────────────────────────┘

서비스 유형별 책임 범위 변화

             고객 책임 많음 ◄─────────────────► AWS 책임 많음

온프레미스    EC2(IaaS)    RDS(관리형DB)    Lambda(서버리스)
──────────────────────────────────────────────────────────
앱            앱           앱               앱
런타임        런타임       런타임           (런타임)
OS            OS           (OS)             (OS)
가상화        (가상화)     (가상화)         (가상화)
서버          (서버)       (서버)           (서버)
──────────────────────────────────────────────────────────
                  ( ) = AWS가 관리

AWS N-tier 아키텍처

인터넷
  │
[Route 53]           ← DNS (도메인 → IP 변환)
  │
[ALB]                ← 로드밸런서 (트래픽 분산 + 헬스체크)
  ├── EC2 (AZ-a)     ← SpringBoot 서버
  └── EC2 (AZ-b)     ← SpringBoot 서버 (다중화)
         │
    [RDS MySQL 8.0]  ← 관리형 DB
    Primary (AZ-a) ↔ Standby (AZ-b)   ← Multi-AZ 자동 Failover

✓ 서버가 죽어도 Auto Scaling이 자동 재생성 ✓ 트래픽 증가 시 EC2 자동 추가 (Auto Scaling) ✓ 퍼블릭 도메인으로 전 세계 접속 ✓ RDS Multi-AZ로 DB 자동 장애 복구 ✓ GitHub Actions로 코드 Push 시 자동 배포

컨테이너 기반 아키텍처

인터넷
  │
[ALB]
  │
[ECS Fargate]        ← 우리 도커 컨테이너를 AWS에서 그대로 실행
  ├── Task (SpringBoot 컨테이너)
  └── Task (SpringBoot 컨테이너)
         │
    [RDS MySQL 8.0]  ← MySQL 컨테이너 → 관리형 DB로 교체

GitHub Actions 자동화:
  코드 Push → 빌드 → Docker 이미지 → ECR → ECS 자동 배포

AWS 클라우드 디자인 패턴

AWS 환경에서 반복적으로 검증된 아키텍처 해법

핵심 설계 원칙

1. 장애 대비 설계 (Design for Failure)
2. 느슨한 결합 (Loose Coupling) : 컴포넌트 간 의존성을 줄여 한 부분 장애가 전체로 전파되지 않게
3. 탄력성 (Elasticity) : 수요에 맞게 자동으로 확장하고 수요가 줄면 자동으로 축소

장애 대비 설계 : SPOF 제거 → 다중화 (Multi-AZ, ALB)
느슨한 결합   : SQS로 서비스 간 비동기 분리
탄력성        : Auto Scaling → 수요에 따라 EC2 자동 조정
                스케일 아웃 = EC2 수 증가 (권장)
                스케일 업   = 더 큰 인스턴스 교체

4. 불변 인프라 (Immutable Infrastructure) : 서버를 수정하지 않고, 새 서버로 교체한다
5. 자동화 우선 (Automate Everything) : 수동 작업은 실수와 시간 낭비의 근원

AWS 서비스 및 기능 이해

N-tier와 연관

[로컬 도커]                    [AWS 서비스]                 [카테고리]
────────────────────────────────────────────────────────────────────
Ubuntu VM                    EC2 ★                        컴퓨팅
Docker                       ECS / EKS ★                  컨테이너
Docker Image Registry        ECR ★                        컨테이너
SpringBoot 컨테이너           EC2 or ECS Task ★            컴퓨팅
MySQL 컨테이너                RDS MySQL ★                  데이터베이스
Redis 컨테이너                ElastiCache ★                데이터베이스
Docker Network               VPC ★                        네트워킹
ufw / iptables               Security Group / NACL ★      네트워킹
포트 포워딩 / Nginx           ELB (ALB) ★                  네트워킹
로컬 파일 마운트(-v)           S3 / EBS / EFS ★             스토리지
사용자 계정 (sudo 설정)        IAM ★                        보안
docker logs                  CloudWatch Logs ★             모니터링
docker stats                 CloudWatch Metrics ★          모니터링

컴퓨팅 서비스

EC2 (Elastic Compute Cloud)
─────────────────────────────────────────────────────
"우분투 VM과 동일한 개념, AWS 클라우드에서"

우리 실습: VirtualBox에 Ubuntu 설치 → SSH 접속
EC2:       AWS 콘솔에서 인스턴스 선택 → SSH 접속
           차이: 클릭 몇 번으로 생성, 안 쓸 때 종료하면 과금 중단

인스턴스 타입 체계:
  예: m5.xlarge
      │ │  └── 크기 (nano/micro/small/medium/large/xlarge/2xlarge...)
      │ └───── 세대 (숫자 클수록 최신, 일반적으로 성능↑ 비용↓)
      └──────── 패밀리

인스턴스 패밀리 (우리 앱에 맞는 타입 선택):
  t (t3, t4g) : 버스트 가능, 저비용 → 개발/테스트, 소규모
  m (m5, m6i) : 범용 균형 → SpringBoot 운영 서버
  c (c5, c6i) : CPU 최적화 → 배치 처리, API 서버 (CPU 집약적)
  r (r5, r6i) : 메모리 최적화 → Redis, 대용량 캐시 서버
  g (g4dn)    : GPU → ML 추론, 영상 처리

AMI (Amazon Machine Image):
  "도커 이미지와 같은 개념 — EC2 인스턴스의 스냅샷/템플릿"

  Amazon Linux 2023 : AWS 최적화 (권장)
  Ubuntu 22.04       : 우리가 익숙한 환경
  Windows Server     : .NET 앱 등

  우리가 만든 환경을 AMI로 저장
  → 동일 환경 인스턴스를 N개 즉시 생성 가능 (Auto Scaling에서 활용

Lambda
─────────────────────────────────────────────────────
"실행할 코드만 올리면 서버는 AWS가 알아서"

특징:
  이벤트 트리거 시에만 실행, 실행 시에만 과금
  최대 실행 시간: 15분
  메모리: 128MB ~ 10GB
  지원 런타임: Java, Python, Node.js, Go, .NET 등

우리 구조에서 활용 예시:
  S3에 파일 업로드 → Lambda 자동 실행
  → 썸네일 생성, 메타데이터 추출
  → RDS에 결과 저장

  SpringBoot 전체를 Lambda로 올리는 건 부적합
  (JVM 콜드 스타트, 15분 제한)

ECS (Elastic Container Service)
─────────────────────────────────────────────────────
"우리 docker-compose를 클라우드에서"

Fargate 방식 (권장):
  EC2 서버 없이 컨테이너만 실행
  → 우리가 만든 SpringBoot Docker 이미지 그대로 올림
  → 서버 관리(패치, 용량 등) 없음
  → 컨테이너 실행 시간만큼만 과금

Task Definition = docker-compose.yml과 유사:
  이미지: [ECR 주소]/my-springboot:latest
  CPU: 0.5 vCPU
  메모리: 1GB
  포트: 8080
  환경변수:
    SPRING_DATASOURCE_URL=jdbc:mysql://[RDS엔드포인트]:3306/mydb

Service:
  원하는 Task 수 유지 (예: 항상 2개)
  ALB와 통합하여 트래픽 분산
  새 이미지 배포 시 롤링 업데이트 자동 처리

스토리지 서비스

S3 (Simple Storage Service)
─────────────────────────────────────────────────────
"파일 저장소 — 용량 제한 없는 클라우드 오브젝트 스토리지"

우리 실습과 연결:
  도커에서 파일을 볼륨(-v)으로 마운트
  → 애플리케이션에서 파일은 S3에 저장 (확장 가능, 내구성 높음)

특징:
  단일 파일 최대 5TB
  내구성: 99.999999999% (11 nine) — 사실상 데이터 손실 없음
  정적 웹사이트 호스팅 가능 (HTML/CSS/JS 직접 서빙)
  버킷(Bucket): S3의 최상위 컨테이너 (이름이 전 세계에서 고유해야 함)

스토리지 클래스 (비용 최적화용):

  Standard        : 자주 접근하는 데이터 (기본)
  Standard-IA     : 가끔 접근 (월 1회 이하) — 저장 비용 낮음
  Glacier Instant : 아카이브, 즉시 조회 가능
  Glacier Flexible: 아카이브, 수분~수시간 조회
  Glacier Deep Archive: 장기 보관 (수 시간 조회) — 최저 비용
  Intelligent-Tiering: 접근 패턴 불명확 시 자동 최적화

수명 주기 정책 (Lifecycle Policy):
  "30일 후 Standard-IA로, 90일 후 Glacier로 자동 이동"
  → S3 비용 자동 최적화

EBS (Elastic Block Store)
─────────────────────────────────────────────────────
"EC2에 연결되는 가상 하드디스크"

우리 실습: docker run -v /data:/data (로컬 디렉터리 마운트)
EBS:       EC2에 마운트하여 블록 디바이스로 사용

특징:
  단일 EC2에만 연결 (일반적으로)
  동일 AZ 내에서만 사용 가능
  EC2 종료 후에도 데이터 유지 (설정에 따라 다름)
  스냅샷으로 백업 가능 → 다른 AZ/리전 복사 가능

EFS (Elastic File System)
─────────────────────────────────────────────────────
"여러 EC2가 동시에 마운트하는 공유 파일시스템 (NFS)"

여러 SpringBoot 서버 인스턴스가 동일한 파일에 접근 필요할 때
  예: 업로드된 파일을 모든 앱 서버에서 읽어야 하는 경우
  (단, 이 패턴보다는 S3에 저장하는 것이 더 일반적)

스토리지 비교 정리

               S3              EBS             EFS
─────────────────────────────────────────────────────────
유형          객체             블록            파일(NFS)
접근 방식     HTTP API         블록 디바이스   NFS 마운트
용량          무제한           최대 64TiB      페타바이트급
멀티 연결     가능(HTTP)       불가(1대)       가능(멀티 EC2)
EC2 필요      불필요           필요            필요
대표 용도     파일 저장/배포    OS 디스크       공유 데이터

네트워킹 서비스

VPC (Virtual Private Cloud)
─────────────────────────────────────────────────────
"우리 도커 네트워크의 AWS 버전"

우리 실습:
  docker network create mynet
  → SpringBoot, MySQL이 같은 네트워크에서 내부 통신
  → -p로 명시한 포트만 외부에 노출

VPC:
  우리만의 격리된 가상 네트워크 (CIDR 예: 10.0.0.0/16)

  Public Subnet  (10.0.1.0/24, 10.0.2.0/24)
    → 인터넷 접근 가능
    → ALB, Bastion Host(관리용 서버) 위치

  Private Subnet (10.0.11.0/24, 10.0.12.0/24)
    → 직접 외부 접근 차단
    → EC2 앱 서버, ECS Task 위치
    → NAT Gateway 통해 아웃바운드만 가능

  DB Subnet      (10.0.21.0/24, 10.0.22.0/24)
    → Private보다 더 격리
    → RDS, ElastiCache 위치

데이터베이스 서비스

RDS (Relational Database Service)
─────────────────────────────────────────────────────
"우리 MySQL 컨테이너의 관리형 버전"

우리 도커:                          RDS:
docker run mysql:8.0                엔진/버전 선택만 하면 됨
  → 우리가 직접 MySQL 운영          → 운영은 AWS가 처리

기능 비교:
  도커 MySQL          RDS MySQL
  ─────────────────────────────────────────────
  백업: 수동           자동 (1~35일 보관)
  패치: 직접           AWS 자동 처리
  HA:   없음           Multi-AZ (자동 Failover)
  모니터링: 직접       CloudWatch 자동 연동
  읽기 분산: 없음      Read Replica (최대 5개)
  스케일업: 직접       콘솔에서 인스턴스 타입 변경

Multi-AZ (고가용성):
  Primary (AZ-a) ← 동기 복제 → Standby (AZ-b)
  Primary 장애 시 → 자동 Failover → Standby가 Primary로
  애플리케이션 엔드포인트는 동일 (DNS가 자동 업데이트)

Read Replica (읽기 성능):
  Primary ← 비동기 복제 → Read Replica 1~5개
  → 읽기 트래픽을 Replica에 분산
  → Primary는 쓰기 전담 → 성능 향상

  Multi-AZ vs Read Replica:
    Multi-AZ = HA(고가용성) 목적, 자동 Failover
    Read Replica = 읽기 성능 향상 목적
    실무: 둘 다 사용 (HA + 성능)

ElastiCache (Redis)
─────────────────────────────────────────────────────
"세션 저장, DB 캐싱 — Redis 완전 관리형"

우리 도커: docker run redis
AWS:       ElastiCache Redis 클러스터 생성
           → 설치, 설정, 백업, 장애 대응 AWS가 처리

SpringBoot 연동 패턴:

1. 세션 저장 (여러 서버 인스턴스에서 세션 공유)
   Spring Session + Redis
   → EC2 A에 로그인 → 세션 Redis에 저장
   → 다음 요청이 EC2 B로 가도 세션 정상 조회

2. DB 캐싱 (자주 조회되는 데이터 캐싱)
   @Cacheable → Redis에 캐싱
   → DB 쿼리 횟수 감소 → RDS 부하 감소 → 응답 속도 향상

보안 & 모니터링 서비스

IAM (Identity and Access Management)
─────────────────────────────────────────────────────
"누가, 무엇에, 어떻게 접근할 수 있는지 정의"

실습:
  sudo 권한 있는 ubuntu 계정으로 모든 것 처리
  → 실무에서는 "모든 권한" 계정 사용은 위험

IAM 구성 요소:
  User    : 개별 계정 (개발자, 운영자)
  Group   : User의 묶음 (Developers, Ops, Admins)
  Role    : 서비스/계정 간 임시 권한 부여
  Policy  : 권한 정의 JSON 문서

최소 권한 원칙 (Least Privilege Principle):
  "필요한 것만 허용, 그 이상은 차단"

  개발자 계정:
    EC2 접근 O, RDS 직접 접근 X

  EC2 앱 서버:
    S3 업로드 O, EC2 관리 X, IAM 콘솔 X
    → IAM Role을 EC2에 부여 (키를 코드에 저장하지 않음)

  GitHub Actions (CI/CD):
    ECR Push O, ECS 배포 O, RDS 삭제 X
    → OIDC 방식으로 임시 토큰 사용 (Access Key 불필요)

! 주의:
  루트 계정 일상 사용 (루트 = 모든 권한, MFA 필수)
  Access Key를 코드/GitHub에 커밋
  EC2에 Access Key 직접 저장 (IAM Role 사용)

CloudWatch
─────────────────────────────────────────────────────
"서버/서비스 상태를 한눈에, 이상 시 자동 알림"

실습:
  docker stats        → 컨테이너 CPU/메모리 실시간 확인
  journalctl -f       → 로그 실시간 확인
  직접 보고 있어야 감지 가능, 이상 징후 놓칠 수 있음

CloudWatch:
  메트릭 (Metrics):
    EC2 CPU 사용률, RDS 연결 수, ALB 요청 수 자동 수집

  로그 (Logs):
    SpringBoot 로그를 CloudWatch Logs로 전송
    → 여러 서버의 로그를 한곳에서 검색/분석

  알람 (Alarms):
    "CPU 70% 초과 3분 지속"
    → SNS → 이메일/Slack 알림 발송
    → Auto Scaling 트리거 → EC2 자동 추가

  대시보드:
    여러 서비스의 메트릭을 하나의 화면에 시각화

실제 알람 시나리오:
  RDS 연결 수가 갑자기 급증
  → CloudWatch Alarm 발생
  → SNS → 개발자 이메일/Slack 알림
  → 개발자가 CloudWatch Logs에서 원인 확인
  → SpringBoot connection pool 설정 수정

AWS 아키텍처 설계

리눅스(Linux)

1991년 Linus Torvalds가 개발한 오픈소스 운영체제 커널

Linux 구성

• 커널 (Kernel) : OS의 핵심. 하드웨어 ↔ 소프트웨어 사이의 인터페이스
• 쉘 (Shell) : 사용자가 입력한 명령어를 커널에 전달하는 인터페이스
• 응용 프로그램 (Application) : 커널 위에서 동작하는 모든 프로그램

주요 셸 종류

echo

문자열 또는 변수 값을 터미널에 출력 (메시지 출력, 변수 확인, 파일 내용 작성)

man / --help

명령어 사용법과 옵션을 확인하는 내장 문서

man : 다른페이지로 넘어가서 보여줌 (상세 문서)

help : 그 페이지에서 보여줌 (빠른 옵션 확인용)

history

이전에 실행한 명령어 목록 확인 및 재실행

단축키

Ctrl + C : 현재 실행 중인 명령어 강제 중단

기타 기본 명령어