Container-Based Architecture

Container-Based Architecture

컨테이너 기반 아키텍처는 호스트 OS 위에서 컨테이너 런타임 (예: Docker) 을 통해 애플리케이션, 라이브러리, 설정 파일을 하나의 단위로 사용자 공간 (User Space) 에 격리하여 실행한다. 이 방식은 VM 대비 오버헤드가 작고, CI/CD 와 연계하기 용이해 개발→테스트→배포까지 일관된 환경을 보장한다. 또한 Kubernetes 같은 오케스트레이션 플랫폼으로 확장성, 셀프 힐링, 로드밸런싱 등을 지원하여 클라우드 네이티브 아키텍처 핵심으로 자리 잡았다.

핵심 개념

컨테이너 기반 아키텍처는 애플리케이션과 실행 환경을 컨테이너 단위로 패키징하여 운영체제 수준에서 격리된 환경에서 독립적으로 실행하는 클라우드 네이티브 아키텍처 스타일이다.

기본 개념

컨테이너 (Container)

• 애플리케이션과 모든 종속성을 포함한 경량의 실행 가능한 패키지
• 운영체제 수준의 가상화를 통해 격리된 실행 환경 제공
• 호스트 OS 커널을 공유하면서도 프로세스와 파일시스템 격리 보장

컨테이너 이미지 (Container Image)

• 컨테이너 실행에 필요한 모든 구성 요소를 포함한 불변의 템플릿
• 계층화된 파일시스템으로 구성되어 효율적인 저장과 배포 지원
• 버전 관리와 재사용성을 통한 일관된 배포 환경 제공

컨테이너 오케스트레이션 (Container Orchestration)

• 다수의 컨테이너를 자동으로 배포, 관리, 확장하는 시스템
• 서비스 디스커버리, 로드 밸런싱, 자동 복구 기능 제공
• Kubernetes (쿠버네티스), Docker Swarm 등이 대표적인 도구

마이크로서비스 아키텍처 (Microservices Architecture)

• 애플리케이션을 작은 독립적인 서비스들로 분해하는 설계 패턴
• 각 서비스가 별도의 컨테이너에서 실행되어 독립적인 배포와 확장 가능
• 서비스 간 API 통신을 통한 느슨한 결합 구조

실무 구현을 위한 연관성

DevOps 및 CI/CD 연관성:

• 컨테이너는 “Build Once, Run Anywhere” 원칙으로 개발과 운영 환경 통합
• 자동화된 빌드, 테스트, 배포 파이프라인의 핵심 구성 요소
• Infrastructure as Code (IaC) 구현을 통한 환경 일관성 보장

클라우드 네이티브 연관성:

• 클라우드 환경의 탄력성과 확장성을 최대한 활용
• 12-Factor App 원칙과 완벽하게 부합하는 설계 패턴
• 멀티클라우드 및 하이브리드 클라우드 환경에서의 이식성 제공

보안 및 규정 준수 연관성:

• 컨테이너 이미지 스캔을 통한 취약점 사전 탐지
• 네트워크 정책과 RBAC (Role-Based Access Control) 를 통한 접근 제어
• 규정 준수를 위한 감사 로그와 모니터링 시스템 통합

배경

Container-Based Architecture 는 전통적인 가상화 기술의 한계를 극복하기 위해 등장했다.
2013 년 Docker 의 출현으로 컨테이너 기술이 대중화되면서, 애플리케이션 배포와 관리 방식에 혁신을 가져왔다. Google 의 내부 시스템인 Borg 에서 영감을 받은 Kubernetes 가 2014 년 오픈소스로 공개되면서 컨테이너 오케스트레이션 생태계가 본격적으로 형성되었다.

목적 및 필요성

주요 목적:

• 애플리케이션의 이식성 향상 및 환경 간 일관성 보장
• 리소스 효율성 증대 및 빠른 시작 시간 달성
• 마이크로서비스 아키텍처 구현을 위한 기반 제공
• 개발과 운영 간의 격차 해소 (DevOps 문화 지원)

필요성:

• 클라우드 환경에서의 확장성과 민첩성 요구 증가
• 레거시 시스템의 현대화 필요성
• 지속적 배포와 자동화된 운영 요구
• 멀티클라우드 전략 수립의 필요성

주요 기능 및 역할

핵심 기능:

1. 애플리케이션 패키징: 코드, 런타임, 라이브러리, 설정을 하나의 단위로 묶음
2. 환경 격리: 프로세스, 네트워크, 파일시스템 수준의 격리 제공
3. 자동 확장: 트래픽과 리소스 사용량에 따른 동적 스케일링
4. 서비스 디스커버리: 동적으로 변하는 서비스 위치 자동 탐지
5. 로드 밸런싱: 다수의 컨테이너 인스턴스 간 트래픽 분산

역할:

• 개발 생산성 향상을 위한 일관된 개발 환경 제공
• 운영 효율성 증대를 위한 자동화된 배포 및 관리
• 비즈니스 연속성 보장을 위한 고가용성 시스템 구현

특징

1. 경량성: VM 대비 낮은 오버헤드와 빠른 시작 시간
2. 이식성: 다양한 환경에서 동일한 실행 보장
3. 확장성: 수평적 확장과 자동 스케일링 지원
4. 격리성: 애플리케이션 간 간섭 없는 독립적 실행
5. 버전 관리: 이미지 태깅을 통한 체계적 버전 관리
6. 불변성: 배포 후 변경 불가능한 이미지 구조

핵심 원칙

12-Factor App 원칙 준수:

1. Codebase: 버전 관리되는 단일 코드베이스
2. Dependencies: 명시적 종속성 선언
3. Config: 환경별 설정 외부화
4. Backing Services: 연결된 리소스로 취급
5. Build, Release, Run: 단계별 명확한 분리
6. Processes: 무상태 프로세스 실행
7. Port Binding: 포트 바인딩을 통한 서비스 노출
8. Concurrency: 프로세스 모델을 통한 확장
9. Disposability: 빠른 시작과 우아한 종료
10. Dev/Prod Parity: 개발과 운영 환경 일치
11. Logs: 로그를 이벤트 스트림으로 처리
12. Admin Processes: 관리 작업을 일회성 프로세스로 실행

주요 원리

graph TB
    A[Application Code] --> B[Container Image]
    B --> C[Container Runtime]
    C --> D[Container Orchestrator]
    D --> E[Distributed System]
    
    F[Registry] --> B
    G[Configuration] --> C
    H[Monitoring] --> E
    I[Storage] --> C
    J[Networking] --> D

개발자가 이미지를 빌드하고 저장소에 업로드, 런타임 및 오케스트레이션 플랫폼이 이미지를 받아 컨테이너를 관리·실행한다.

컨테이너화 원리:

1. 단일 책임 원칙: 하나의 컨테이너는 하나의 애플리케이션 구성 요소만 실행
2. 이미지 불변성: 빌드된 이미지는 변경되지 않으며 새 버전으로 대체
3. 런타임 제약: 리소스 사용량 제한을 통한 시스템 안정성 보장
4. 생명주기 관리: 컨테이너의 시작, 실행, 중지, 재시작 자동화

작동 원리 및 방식

sequenceDiagram
    participant Dev as Developer
    participant Registry as Container Registry
    participant Orchestrator as Orchestrator
    participant Node as Worker Node
    participant App as Application
    
    Dev->>Registry: Push Container Image
    Orchestrator->>Registry: Pull Image
    Orchestrator->>Node: Schedule Container
    Node->>App: Start Container
    App->>Orchestrator: Health Check
    Orchestrator->>Node: Monitor & Scale

작동 과정:

1. 이미지 빌드: 소스 코드와 종속성을 컨테이너 이미지로 패키징
2. 레지스트리 저장: 빌드된 이미지를 컨테이너 레지스트리에 저장
3. 배포 요청: 오케스트레이터에 배포 명세서 제출
4. 스케줄링: 가용한 노드에 컨테이너 배치 결정
5. 실행: 선택된 노드에서 컨테이너 인스턴스 시작
6. 모니터링: 컨테이너 상태 감시 및 자동 복구
7. 확장/축소: 트래픽과 리소스 사용량에 따른 동적 조정

구조 및 아키텍처

전체 아키텍처 구조

graph TB
    subgraph "Application Layer"
        A1[Microservice A]
        A2[Microservice B]
        A3[Microservice C]
    end
    
    subgraph "Container Layer"
        C1[Container A]
        C2[Container B]
        C3[Container C]
    end
    
    subgraph "Orchestration Layer"
        O1[Scheduler]
        O2[Service Discovery]
        O3[Load Balancer]
        O4[Health Monitor]
    end
    
    subgraph "Infrastructure Layer"
        I1[Node 1]
        I2[Node 2]
        I3[Node 3]
    end
    
    A1 --> C1
    A2 --> C2
    A3 --> C3
    
    C1 --> O1
    C2 --> O2
    C3 --> O3
    
    O1 --> I1
    O2 --> I2
    O3 --> I3

구성요소

장점

단점과 문제점 그리고 해결방안

단점

문제점

도전 과제

분류 기준에 따른 종류 및 유형

실무 사용 예시

활용 사례

사례 1: 넷플릭스의 마이크로서비스 아키텍처

시스템 구성:

graph TB
    subgraph "Frontend Layer"
        UI[Web/Mobile UI]
        API[API Gateway]
    end
    
    subgraph "Microservices Layer"
        US[User Service]
        CS[Content Service]
        RS[Recommendation Service]
        PS[Payment Service]
        VS[Video Service]
    end
    
    subgraph "Container Platform"
        K8S[Kubernetes Cluster]
        LB[Load Balancer]
        SM[Service Mesh]
    end
    
    subgraph "Infrastructure Layer"
        AWS[AWS Cloud]
        CDN[Content Delivery Network]
        DB[(Databases)]
    end
    
    UI --> API
    API --> US
    API --> CS
    API --> RS
    API --> PS
    API --> VS
    
    US --> K8S
    CS --> K8S
    RS --> K8S
    PS --> K8S
    VS --> K8S
    
    K8S --> AWS
    K8S --> CDN
    K8S --> DB

Workflow:

1. 사용자 요청: 클라이언트에서 API Gateway 로 요청 전송
2. 서비스 라우팅: API Gateway 가 적절한 마이크로서비스로 요청 라우팅
3. 컨테이너 실행: Kubernetes 가 필요한 컨테이너 인스턴스 스케줄링
4. 서비스 간 통신: 서비스 메시를 통한 안전한 마이크로서비스 간 통신
5. 데이터 처리: 각 마이크로서비스가 독립적으로 데이터 처리
6. 응답 반환: 처리된 결과를 API Gateway 를 통해 클라이언트로 반환

Container-Based Architecture 의 역할:

• 독립적 배포: 각 마이크로서비스를 독립적으로 개발, 테스트, 배포
• 자동 확장: 트래픽 패턴에 따른 서비스별 동적 스케일링
• 장애 격리: 하나의 서비스 장애가 전체 시스템에 미치는 영향 최소화
• 빠른 복구: 컨테이너 기반 자동 복구 메커니즘

Container-Based Architecture 유무에 따른 차이점:

• 적용 전 (모놀리식 아키텍처):
  • 전체 애플리케이션 단일 배포로 인한 배포 리스크 증가
  • 특정 기능 장애 시 전체 서비스 영향
  • 기술 스택 변경의 어려움
  • 팀 간 의존성으로 인한 개발 속도 저하
• 적용 후 (Container-Based Architecture):
  • 서비스별 독립적 배포로 배포 리스크 분산
  • 장애 격리를 통한 서비스 안정성 향상
  • 서비스별 최적화된 기술 스택 선택 가능
  • 팀 자율성 증대로 개발 속도 향상

사례 2: Netflix 사용자 요청 스케일 대응

구성: 앱 컨테이너 + Sidecar 로 TLS + 모니터링 + Config 관리

워크플로: CI/CD 통해 이미지 빌드 → Canary 배포 → Prometheus 로 모니터링 → 자동 롤아웃

차이점: 기존 VM 기반은 느린 롤아웃, 오버헤드 큼 → 컨테이너는 배포 자동화, 자원 효율↑

graph LR
  CI/CD --> Registry
  Registry --> K8s
  K8s --> AppPod[App + Sidecar]
  AppPod --> Istio[Service Mesh]
  AppPod --> Prometheus
  Istio --> Grafana

구현 예시

다음은 넷플릭스와 유사한 마이크로서비스 아키텍처를 Container-Based Architecture 로 구현한 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

# user_service.py - 사용자 서비스 컨테이너
from flask import Flask, jsonify, request
import logging
import os

app = Flask(__name__)

# 컨테이너 환경변수에서 설정 읽기
DATABASE_URL = os.getenv('DATABASE_URL', 'postgresql://localhost/users')
SERVICE_PORT = int(os.getenv('SERVICE_PORT', 5000))

# 로깅 설정 (컨테이너 환경에서 표준출력으로 로그 출력)
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

@app.route('/health', methods=['GET'])
def health_check():
    """
    컨테이너 상태 확인을 위한 헬스체크 엔드포인트
    Kubernetes 등 오케스트레이터에서 활용
    """
    return jsonify({"status": "healthy", "service": "user-service"}), 200

@app.route('/users/<user_id>', methods=['GET'])
def get_user(user_id):
    """
    사용자 정보 조회 서비스
    마이크로서비스 아키텍처에서 독립적으로 동작
    """
    try:
        # 실제 구현에서는 데이터베이스 연동 로직
        user_data = {
            "user_id": user_id,
            "name": "John Doe",
            "subscription": "premium",
            "region": "US"
        }
        
        logger.info(f"User {user_id} data retrieved successfully")
        return jsonify(user_data), 200
        
    except Exception as e:
        logger.error(f"Error retrieving user {user_id}: {str(e)}")
        return jsonify({"error": "Internal server error"}), 500

@app.route('/users', methods=['POST'])
def create_user():
    """
    새 사용자 생성 서비스
    컨테이너 간 독립적인 데이터 처리
    """
    try:
        user_data = request.get_json()
        
        # 사용자 데이터 검증 및 생성 로직
        new_user = {
            "user_id": "12345",
            "name": user_data.get('name'),
            "email": user_data.get('email'),
            "created_at": "2024-01-01T00:00:00Z"
        }
        
        logger.info(f"New user created: {new_user['user_id']}")
        return jsonify(new_user), 201
        
    except Exception as e:
        logger.error(f"Error creating user: {str(e)}")
        return jsonify({"error": "Bad request"}), 400

if __name__ == '__main__':
    # 컨테이너 환경에서 실행 (0.0.0.0으로 바인딩하여 외부 접근 허용)
    app.run(host='0.0.0.0', port=SERVICE_PORT, debug=False)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

# kubernetes-deployment.yaml - Kubernetes 배포 설정
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
  labels:
    app: user-service
    version: v1
spec:
  replicas: 3  # 고가용성을 위한 다중 인스턴스
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
        version: v1
    spec:
      containers:
      - name: user-service
        image: user-service:1.0.0  # 컨테이너 이미지
        ports:
        - containerPort: 5000
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: database-credentials
              key: url
        - name: SERVICE_PORT
          value: "5000"
        
        # 리소스 제한으로 컨테이너 안정성 보장
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 200m
            memory: 256Mi
        
        # 헬스체크 설정으로 컨테이너 상태 모니터링
        livenessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 30
          periodSeconds: 10
        
        readinessProbe:
          httpGet:
            path: /health
            port: 5000
          initialDelaySeconds: 5
          periodSeconds: 5

---
# 서비스 노출을 위한 Service 리소스
apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5000
  type: ClusterIP  # 클러스터 내부 통신

---
# 수평 자동 확장 설정
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: user-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: user-service
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# Dockerfile - 컨테이너 이미지 빌드 설정
# 멀티스테이지 빌드로 최적화된 이미지 생성
FROM python:3.9-slim as builder

# 의존성 설치를 위한 임시 패키지
RUN apt-get update && apt-get install -y \
    gcc \
    && rm -rf /var/lib/apt/lists/*

# Python 의존성 설치
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# 실행 단계 - 최소화된 이미지
FROM python:3.9-slim

# 보안을 위한 비특권 사용자 생성
RUN groupadd -g 1000 appuser && \
    useradd -r -u 1000 -g appuser appuser

# 애플리케이션 디렉토리 생성
WORKDIR /app

# 빌더 스테이지에서 의존성 복사
COPY --from=builder /root/.local /home/appuser/.local
COPY --chown=appuser:appuser . /app

# 비특권 사용자로 실행
USER appuser

# PATH 환경변수 설정
ENV PATH=/home/appuser/.local/bin:$PATH

# 헬스체크 설정
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:5000/health || exit 1

# 컨테이너 실행 명령
EXPOSE 5000
CMD ["python", "user_service.py"]

이 구현 예시는 Container-Based Architecture 의 핵심 특징들을 보여준다:

1. 컨테이너화: 애플리케이션과 종속성을 단일 이미지로 패키징
2. 마이크로서비스: 독립적으로 배포 가능한 서비스 단위 구성
3. 오케스트레이션: Kubernetes 를 통한 자동화된 배포와 관리
4. 확장성: HPA 를 통한 자동 스케일링
5. 관찰성: 헬스체크와 로깅을 통한 모니터링
6. 보안: 비특권 사용자와 리소스 제한을 통한 보안 강화

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

• 보안: 자동 스캔 도구 (Trivy), Rootless 실행, RBAC + OPA 정책 강화
• 배포: GitOps 기반 선언적 배포 + Canary 또는 Blue-Green 전략
• 모니터링: Prometheus + Fluentd + OpenTelemetry 통합 구성
• 리소스 관리: 정책 기반 오토스케일링 (HPA), 비용 시각화 도구 활용
• 가시성: APM + 분산 추적 기반 병목 진단 체계 구축

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

반드시 학습해야할 내용

용어 정리

참고 및 출처

컨테이너 설계 원칙 및 아키텍처 가이드

• Kubernetes 공식 문서 - Principles of Container App Design
• Google Cloud - Container Architecture Guide
• AWS - Container Architecture Patterns
• Microsoft Azure - Architecture Center
• Red Hat - Container Architecture Best Practices

기술 표준 및 생태계 자료

• CNCF Cloud Native Landscape
• Aqua Security - Containerized Architecture
• Container Security Best Practices - Wiz

아키텍처 및 시스템 디자인 이해 자료

• Docker 공식 문서 - Docker Swarm and Architecture
• Spacelift - Docker Architecture Overview
• GeeksforGeeks - Containerization Architecture in System Design

리눅스 커널 기반 기술 (컨테이너 격리의 핵심)

• Linux Namespaces - Wikipedia
• Cgroups - Wikipedia