Microservices & Containers Mechanics

1. Overview

마이크로서비스 및 컨테이너 메커니즘(Microservices & Containers Mechanics, MCM)은 한 덩어리로 뭉쳐진 거대한 시스템(Monolith)을 작고 독립적인 서비스들의 군단으로 분해하고, 이를 컨테이너(Container)라는 표준화된 상자에 담아 전 세계 어디서든 똑같이 실행되게 만드는 클라우드 시대의 표준 아키텍처를 다룹니다.

과거에는 수백만 줄의 코드가 얽힌 탓에 버튼 색깔 하나를 바꾸려 해도 전체 서버를 재부팅해야 했습니다. 학습자는 넷플릭스나 우버처럼 시스템을 비즈니스 도메인(DDD) 단위로 쪼개어 각 팀이 독립적으로 배포할 수 있는 마이크로서비스(MSA)의 설계 철학을 배웁니다. 나아가 도커(Docker)의 프로세스 격리 마법과, 수천 개의 컨테이너가 죽고 살아나는 것을 지휘하는 쿠버네티스(Kubernetes) 오케스트레이션을 통해 거대 분산 시스템의 통제력을 확보합니다.

2. Scope & Boundaries

In-Scope

• 마이크로서비스 아키텍처(MSA): 바운디드 컨텍스트(Bounded Context), API Gateway 패턴, 백엔드 포 프론트엔드(BFF).
• 컨테이너 가상화(Docker): 리눅스 Namespace와 cgroup을 이용한 프로세스 격리, Copy-on-Write 기반의 이미지 레이어 아키텍처.
• 분산 데이터 관리: Database per Service 원칙, 사가(Saga) 패턴과 보상 트랜잭션, 이벤트 소싱(Event Sourcing).
• 오케스트레이션과 서비스 메쉬(Service Mesh): 쿠버네티스(Kubernetes)의 선언적(Declarative) 상태 관리, 팟(Pod), 디플로이먼트(Deployment), 사이드카(Sidecar) 패턴, Istio 기반 통신 통제.

Out-of-Scope

• 쿠버네티스의 노드 하드웨어 구성 및 CNI 플러그인 개발: 쿠버네티스 자체의 네트워크 드라이버 레벨 해킹이나 퍼블릭 클라우드 벤더(AWS EKS 등)의 권한 관리 $\rightarrow$ 07-07. Cloud-Native Evolution 영역으로 위임.
• 각 마이크로서비스 내부의 언어별 프레임워크 최적화: Spring Boot나 NestJS의 코드 튜닝 $\rightarrow$ 05-01. OOP & Language Paradigms 영역으로 위임.

Boundaries

• MCM vs. FAP (07-01): FAP가 '단일 애플리케이션 내부에 폴더와 인터페이스를 어떻게 나눌 것인가(헥사고날 등)'를 다룬다면, MCM은 '물리적으로 분리된 여러 개의 서버 프로세스(컨테이너) 간에 네트워크(HTTP/gRPC)로 어떻게 소통할 것인가'를 다룹니다. 단일 애플리케이션 안에서 모듈화(FAP)를 못 하는 팀은 마이크로서비스(MCM)를 도입하면 분산된 쓰레기(Distributed Big Ball of Mud)를 만들게 됩니다.

3. Counterexample

• 분산 모노리스의 저주 (Distributed Monolith): 모놀리스 서버를 5개의 마이크로서비스로 쪼개놓고, 데이터베이스는 기존의 거대한 Oracle DB 1개를 다 같이 공유(Shared DB)하는 구성. 5번 서비스가 테이블 락(Table Lock)을 걸어버리면 나머지 1~4번 서비스가 전부 정지해 버립니다. 진정한 MSA는 코드뿐만 아니라 **데이터베이스의 물리적 스키마(Database per Service)**까지 완벽히 찢어내어, 한 서비스의 데이터 스토리지 마비가 다른 서비스로 전파되지 않게 격리(Bulkhead)하는 것입니다.
• 동기 호출의 연쇄 붕괴 (Cascading Failure): A 서비스 $\rightarrow$ B 서비스 $\rightarrow$ C 서비스 순으로 HTTP GET 요청을 동기식으로만 짜놓은 아키텍처. C 서비스가 응답하지 않으면 B 서비스의 스레드가 고갈되고, 결국 A 서비스까지 연쇄적으로 다운됩니다. MSA 환경에서는 네트워크 홉(Hop)이 늘어나는 만큼 실패율이 기하급수적으로 증가하므로, 서킷 브레이커(Circuit Breaker)나 이벤트 기반 비동기 처리(Pub/Sub) 없이는 시스템이 버틸 수 없는 물리적 현실을 부정한 행위입니다.

4. Prerequisites

• 기초 및 아키텍처 패턴 (Basic): 강하게 결합된 코드를 분리하는 설계 원칙(의존성 역전 등)을 알아야 MSA로 쪼갤 수 있습니다. (07-01. FAP)
• 운영체제 및 병렬성 메커니즘 (Recommended): 컨테이너 가상화(Docker)의 실체를 이해하려면 OS 커널의 네임스페이스와 프로세스 격리 개념이 필요합니다. (03-03. Virtualization Physics)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 도커 컨테이너와 레이어 아키텍처 (Container Physics)

• Why to Learn: 가상머신(VM)처럼 무겁게 OS 전체를 띄우지 않고, 1초 만에 격리된 프로세스를 띄워 올리는 마이크로서비스 배포의 핵심 도구를 장착하기 위함입니다.
• What to Learn:
  • Concepts: 가상머신(Hypervisor) vs 컨테이너(OS-level Virtualization), 이미지(Image)와 컨테이너(Container)의 차이.
  • Skills: 리눅스 Namespace(격리)와 cgroups(자원 통제) 원리, UnionFS와 Copy-on-Write(CoW) 방식의 이미지 레이어 메커니즘, Dockerfile 최적화.
  • Tools: Docker 엔진.
  • Trade-offs: 호스트 OS 커널을 공유하므로 VM 대비 성능 오버헤드가 0에 가깝지만, 커널 취약점이 뚫리면 모든 컨테이너가 해킹당하는 보안 리스크.
• How to Learn:
  • 1단계: OS에 직접 Node.js를 깔아 실행하는 것과, Docker 안에서 실행하는 프로세스가 호스트 OS의 ps -ef 명령에서 어떻게(PID가 다르게) 보이는지 관찰하여 "컨테이너는 그저 격리된 프로세스일 뿐"이라는 본질을 꿰뚫습니다.
  • 2단계: Dockerfile에서 안 바뀌는 의존성 설치(npm install)를 위로 올리고, 매번 바뀌는 소스 코드 복사(COPY . .)를 아래로 내려 이미지 빌드 시 캐시(Cache)가 터지지 않게 만드는 레이어 최적화 물리를 증명합니다.
• Implement: 1GB짜리 무거운 Node.js 앱 이미지를 Multi-stage Build 기법을 활용해 실행에 필요한 파일만 남긴 50MB짜리 경량 이미지(Alpine 기반)로 압축해 내는 최적화 튜닝 리포트.

Recommended

Core Topic 02: 마이크로서비스 분할 원칙과 게이트웨이 (MSA Decomposition & API Gateway)

• Why to Learn: 무작정 서비스를 잘게 쪼갰다가 서비스끼리 통신하느라 응답 시간이 10배 느려지는 참사를 막고, 합리적인 경계(Boundary)를 긋기 위해서입니다.
• What to Learn:
  • Concepts: 도메인 주도 설계(DDD)의 바운디드 컨텍스트(Bounded Context), 강응집 저결합.
  • Skills: API Gateway 패턴(라우팅, 인증, Rate Limiting 통합), BFF(Backend For Frontend) 패턴, Database per Service 원칙.
  • Tools: Nginx, Spring Cloud Gateway, Kong.
  • Trade-offs: UI 개발팀이 백엔드의 복잡한 분산 구조를 몰라도 게이트웨이 하나만 찌르면 되는 편리함 vs 모든 트래픽이 게이트웨이를 거쳐가므로 게이트웨이가 병목(SPOF)이 될 수 있는 아키텍처 리스크.
• How to Learn:
  • 1단계: '쇼핑몰 모놀리스' 코드에서 "상품 정보"와 "재고 수량"이 하나의 DB 테이블에 엮여 있을 때, 이를 '카탈로그 서비스'와 '창고 서비스'로 찢어내며 생기는 JOIN 불가 문제를 식별합니다.
  • 2단계: 클라이언트(모바일 앱)가 이 두 정보를 렌더링하기 위해 API를 2번 호출해야 하는 문제를 해결하고자, 중간에 API Gateway(또는 BFF)를 두어 서버 사이드에서 데이터를 조합(Aggregation)해 내려주는 구조를 도식화합니다.
• Implement: '주문', '회원', '상품' 3개의 도커 컨테이너를 띄우고 앞단에 Nginx API Gateway를 배치하여, 클라이언트가 /api/users로 요청하면 회원 컨테이너로, /api/orders로 요청하면 주문 컨테이너로 라우팅하는 네트워크 명세서 작성.

Practical

Core Topic 03: 쿠버네티스 오케스트레이션 기초 (Kubernetes Orchestration)

• Why to Learn: 100대의 서버에 수동으로 docker run을 입력하다가 미쳐버리지 않도록, 구글이 만든 인공지능 같은 클러스터 지휘자(Orchestrator)를 고용하기 위함입니다.
• What to Learn:
  • Concepts: 선언적(Declarative) 인프라, Control Plane과 Worker Node 아키텍처.
  • Skills: Pod(가장 작은 배포 단위), ReplicaSet/Deployment(개수 유지 및 롤링 배포), Service(고정 IP 및 로드 밸런싱), Ingress(외부 라우팅).
  • Tools: Kubernetes (kubectl, minikube).
  • Trade-offs: "서버 3대 유지해 줘"라고 야믈(YAML) 파일로 선언만 하면 알아서 죽은 서버를 살려내는 극강의 자가 복구력 vs K8s 생태계 자체를 학습하고 클러스터를 유지 보수하는 데 드는 살인적인 엔지니어링 오버헤드.
• How to Learn:
  • 1단계: 3개의 Pod(웹 서버)를 띄워두고 그중 하나의 컨테이너를 강제로 kill 했을 때, 쿠버네티스의 Control Loop가 "현재 2개 $\neq$ 기대 3개" 상태를 감지하고 즉시 새 Pod을 스케줄링하여 3개를 맞추는 자가 치유(Self-healing) 물리를 시연합니다.
  • 2단계: Pod의 IP는 생성/삭제 시마다 계속 변하므로 통신이 불가능함을 인지하고, 이를 묶어주는 고정된 가상 IP이자 내부 로드 밸런서인 'Service(ClusterIP)' 오브젝트의 네트워크 흐름을 추적합니다.
• Implement: 단순한 방명록 애플리케이션(Frontend + Redis DB)을 K8s Deployment와 Service YAML로 작성하여 Minikube 환경에 배포하고, kubectl scale 명령어로 프론트엔드를 5대로 늘렸을 때 부하가 분산되는 과정을 기록한 워크플로우.

Advanced

Core Topic 04: 서비스 메쉬와 분산 트랜잭션 (Service Mesh & Saga Pattern)

• Why to Learn: 수십 개의 서비스가 얽힌 MSA의 지옥도 속에서, 트래픽을 정밀 통제하고 찢어진 데이터베이스 간의 롤백(Rollback) 불가능 문제를 해결하는 궁극의 분산 제어술을 익히기 위해서입니다.
• What to Learn:
  • Concepts: 사이드카 패턴(Sidecar Pattern), 서비스 메쉬(Service Mesh), 분산 트랜잭션(Distributed Transaction).
  • Skills: Istio를 활용한 트래픽 섀도잉(Traffic Shadowing)/카나리 배포 제어, Saga 패턴(Choreography vs Orchestration), 보상 트랜잭션(Compensating Transaction) 설계.
  • Tools: Istio, Envoy 프록시, 메시지 큐(RabbitMQ).
  • Trade-offs: 개발자가 통신 재시도나 mTLS 암호화 코드를 안 짜도 인프라(Istio)가 다 해주는 극도의 투명성 vs 모든 네트워크 홉(Hop)마다 사이드카 프록시를 거쳐야 하므로 발생하는 레이턴시 지연과 메모리 팽창(Bloat).
• How to Learn:
  • 1단계: '결제는 성공했는데 재고 차감에 실패한 상황'을 가정합니다. RDBMS의 ROLLBACK이 먹히지 않는 독립된 DB 환경이므로, 결제 서비스 측으로 "결제 취소 이벤트"를 비동기로 쏘아 논리적으로 돈을 환불하는 사가(Saga) 보상 트랜잭션 역학을 스케치합니다.
  • 2단계: 쿠버네티스에 배포된 애플리케이션 Pod 안에, 내가 만든 앱 컨테이너 옆에 'Envoy 프록시(사이드카)' 컨테이너가 몰래 끼어들어, 앱 밖으로 나가는 모든 트래픽을 가로채어 모니터링하고 라우팅을 조작하는 서비스 메쉬의 패킷 흐름을 분석합니다.
• Implement: 2개의 마이크로서비스 간 통신에 Istio 서비스 메쉬를 적용하여, 코드 수정 단 1줄 없이 HTTP 통신을 mTLS(상호 인증 암호화)로 자동 격상시키고 특정 서비스 호출 시 고의로 50%의 500 에러(Fault Injection)를 발생시켜 시스템 회복성을 테스트하는 매니페스트.

7. Terminology

8. References

Primary References

• [P2] SWEBOK v4.0 - Software Construction (Component-based) — Systematic decomposition.
• [P5] SFIA - System Architecture / Development — Professional skills management.

Secondary References

• [Building Microservices] Sam Newman — Foundational MSA patterns.
• [Microservices Patterns] Chris Richardson — Implementation strategies (Saga, CQRS).

Industry References

• [CNCF Landscape] — Container ecosystem standards.
• [The Kubernetes Book] Nigel Poulton — Practical orchestration.

9. Final Checklist

Primary Checklist

• 하나의 거대 모놀리스를 마이크로서비스로 분할할 때, 데이터베이스의 '외래키 제약'이 물리적으로 어떻게 대체되어야 하는지 설명할 수 있는가? (P2)
• Dockerfile 작성 시 왜 이미지 레이어 순서가 캐시 효율과 전송 속도에 물리적 영향을 미치는지 이해하는가? (P2)

Secondary Checklist

• 분산 시스템 환경에서 '서킷 브레이커'가 장애 전파(Cascading Failure)를 어떻게 물리적으로 차단하는지 입증 가능한가?
• 네트워크 홉(Hop)이 늘어남에 따라 발생하는 지연(Latency) 오버헤드를 측정하고, 비즈니스 허용 범위를 계산하는가?

Industry Checklist

• Kubernetes 환경에서 '자동 복구(Self-healing)'가 이루어지는 동안 트래픽 유입이 어떻게 차단되고 재개되는지 알고 있는가? (CNCF)
• 서비스 메쉬(Service Mesh)를 통해 암호화(mTLS)와 관측성을 애플리케이션 코드 수정 없이 확보하는 방법을 논할 수 있는가?