클라우드 서비스 개발

Public Cloud  : AWS, GCP, Azure 등 퍼블릭 사업자 인프라 활용
               → 비용 효율, 빠른 확장

Private Cloud : 기업 전용 클라우드 (온프레미스 또는 전용 호스팅)
               → 높은 보안, 높은 초기 비용

Hybrid Cloud  : Public + Private 혼합
               → 민감 데이터는 Private, 탄력적 부하는 Public

Multi Cloud   : 여러 퍼블릭 클라우드 동시 활용
               → 벤더 종속 방지, 서비스별 최적 클라우드 선택

물리 서버
└── Hypervisor (VMware, KVM, Hyper-V)
    ├── VM 1 — Ubuntu + App A
    ├── VM 2 — CentOS + App B
    └── VM 3 — Windows + App C

VM vs Container

VM                          Container
├── Guest OS 포함           ├── Guest OS 없음 (호스트 OS 공유)
├── GB 단위 이미지           ├── MB 단위 이미지
├── 부팅에 수십 초           ├── 부팅에 수 초 이내
└── 강한 격리, 무거움         └── 가볍고 빠른 배포에 적합

FROM openjdk:17-jdk-slim

WORKDIR /app

COPY target/my-app.jar app.jar

EXPOSE 8080

ENTRYPOINT ["java", "-jar", "app.jar"]

# 이미지 빌드
docker build -t my-app:1.0 .

# 컨테이너 실행
docker run -d -p 8080:80 --name my-container my-app:1.0

# 실행 중인 컨테이너 확인
docker ps

# 로그 확인
docker logs my-container

Control Plane
├── API Server        : 모든 요청의 진입점
├── Scheduler         : Pod를 어느 노드에 배치할지 결정
├── etcd              : 클러스터 상태 저장 (분산 KV 스토어)
└── Controller Manager: 원하는 상태 지속 유지

Worker Node
├── kubelet           : 노드 에이전트, Pod 실행 관리
├── kube-proxy        : 네트워크 규칙 관리
└── Container Runtime : Docker, containerd

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.0
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

99%     → 연간 약 87시간 다운타임 허용
99.9%   → 연간 약 8.7시간   ("Three Nines")
99.99%  → 연간 약 52분      ("Four Nines")
99.999% → 연간 약 5분       ("Five Nines") ← 금융/의료급

        [사용자]
           │
      [Load Balancer]  ← 이중화
      ┌────┴────┐
  [App 1]   [App 2]    ← 다중 인스턴스
      └────┬────┘
     [DB Primary]
           └── [DB Replica]  ← 복제본

Scale Out : 인스턴스 수 증가 (트래픽 급증 시)
Scale In  : 인스턴스 수 감소 (트래픽 감소 시)
Scale Up  : 인스턴스 사양 향상 (CPU, RAM 증가)
Scale Down: 인스턴스 사양 축소

CLOSED (정상 운영)
  → 오류율이 임계치 초과하면
OPEN (요청 차단)    ← 모든 요청 즉시 실패 처리
  → 일정 시간 후 테스트 요청 허용
HALF-OPEN
  → 성공 시 CLOSED 복귀
  → 실패 시 OPEN 유지

모놀리식 (Monolithic)              마이크로서비스 (MSA)

┌──────────────────┐              ┌────────┐  ┌────────┐
│  사용자 관리      │              │  User  │  │ Order  │
│  주문 처리        │    →         │  Svc   │  │  Svc   │
│  결제             │              └────────┘  └────────┘
│  알림             │              ┌────────┐  ┌────────┐
└──────────────────┘              │  Pay   │  │ Notify │
                                  │  Svc   │  │  Svc   │
                                  └────────┘  └────────┘

클라이언트
    │
[API Gateway]
├── 인증 / 인가
├── 요청 라우팅
├── Rate Limiting
├── 로드밸런싱
└── 로깅 / 모니터링
    │
    ├── User Service
    ├── Order Service
    └── Payment Service

[주문 서비스] → "주문 완료" 이벤트 발행
                      │
                [Kafka / RabbitMQ]
                      │
       ┌──────────────┼──────────────┐
  [결제 서비스]  [재고 서비스]   [알림 서비스]

코드 Push
    │
[소스 저장소 — GitHub / GitLab]
    │
[CI: 빌드 & 검증]
├── 빌드 (Maven, Gradle)
├── 단위 테스트
├── 정적 분석 (SonarQube)
└── Docker 이미지 빌드 & 레지스트리 Push
    │
[CD: 자동 배포]
├── 개발 환경 자동 배포
├── 스테이징 환경 배포 (승인 후)
└── 프로덕션 환경 배포 (승인 후)

name: CI/CD Pipeline

on:
  push:
    branches: [main]

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'

    - name: Build & Test
      run: ./gradlew build test

    - name: Build Docker Image
      run: docker build -t my-app:${{ github.sha }} .

    - name: Push to Registry
      run: |
        docker tag my-app:${{ github.sha }} registry.example.com/my-app:latest
        docker push registry.example.com/my-app:latest

    - name: Deploy to Kubernetes
      run: |
        kubectl set image deployment/my-app \
          my-app=registry.example.com/my-app:latest

┌───────────┬───────────┬───────────┐
│  Metrics  │   Logs    │  Traces   │
│  (지표)   │  (로그)   │  (추적)   │
├───────────┼───────────┼───────────┤
│ CPU, 메모리│ 애플리케이션│ 요청이 여러│
│ 응답시간  │ 이벤트 기록 │ 서비스를  │
│ 처리량 등 │            │ 거치는 경로│
├───────────┼───────────┼───────────┤
│Prometheus │ ELK Stack │  Jaeger   │
│ Grafana   │  Datadog  │  Zipkin   │
└───────────┴───────────┴───────────┘

SLI (Service Level Indicator) : 실제 측정 지표
├── 가용성   : 성공 요청 수 / 전체 요청 수
├── 지연시간 : 요청~응답 소요 시간 (p50, p95, p99)
└── 처리량   : 초당 처리 요청 수 (TPS, RPS)

SLO (Service Level Objective) : 내부 목표 수준
└── 예: "99.9% 요청이 200ms 이내 응답"

SLA (Service Level Agreement) : 고객과의 계약
└── SLO 미달 시 패널티/환불 조항 포함

User   : 개별 사람 계정
Group  : User들의 집합 → 그룹 단위 정책 적용
Role   : 서비스/인스턴스에 부여하는 권한 묶음
Policy : 특정 리소스에 대한 허용/거부 규칙 문서

[Internet]
     │
[Internet Gateway]
     │
┌─── VPC ─────────────────────────┐
│  Public Subnet                  │
│  ├── Load Balancer              │
│  └── Bastion Host               │
│                                 │
│  Private Subnet                 │
│  ├── Application Server         │
│  └── Database                   │
│                                 │
│  Security Group (방화벽)          │
│  ├── Inbound : 80, 443만 허용   │
│  └── Outbound: 제한적 허용       │
└─────────────────────────────────┘

코드 작성 → SAST (정적 코드 분석)
빌드      → SCA  (오픈소스 취약점 스캔)
배포 전   → DAST (동적 취약점 테스트)
운영 중   → RASP (실시간 공격 탐지)

I.   Codebase        : 하나의 코드베이스, 여러 배포 환경
II.  Dependencies    : 의존성 명시적 선언 (pom.xml, package.json)
III. Config          : 설정은 환경 변수로 분리 (.env, ConfigMap)
IV.  Backing Services: DB, 캐시 등을 교체 가능한 리소스로 취급
V.   Build/Release   : 빌드-릴리즈-실행 단계 엄격히 분리
VI.  Processes       : 무상태(Stateless) 프로세스로 실행
VII. Port Binding    : 포트 바인딩으로 서비스 노출
VIII.Concurrency     : 프로세스 모델로 수평 확장
IX.  Disposability   : 빠른 시작, 안전한 종료 (Graceful Shutdown)
X.   Dev/Prod Parity : 개발-스테이징-프로덕션 환경 최대한 동일하게
XI.  Logs            : 로그를 이벤트 스트림으로 처리
XII. Admin Processes : 관리 작업을 일회성 프로세스로 실행

기능적 요구사항 (Functional Requirements)
└── "무엇을" 해야 하는가 — 기능 명세

비기능적 요구사항 (Non-Functional Requirements)
├── 성능    : 응답시간 목표, TPS
├── 가용성  : SLA 목표 수준
├── 확장성  : 트래픽 증가 대응 방법
├── 보안    : 인증/인가, 데이터 암호화
├── 유지보수 : 코드 가독성, 테스트 커버리지
└── 비용    : 인프라 비용 최적화 전략