목차
1 MSA란 무엇인가
2 모놀리식 아키텍처와 MSA
3 MSA의 주요 특징
4 MSA 전환 사례
5 MSA를 무조건 선택하면 안 되는 이유
6 MSA 이전 방법론
7 소프트웨어 아키텍처 구성 요소
8 ADR
9 서비스 기반 아키텍처
10 이벤트 기반 아키텍처
11 마이크로서비스 아키텍처
12 DDD와 마이크로서비스 설계
13 이벤트 스토밍
14 아키텍처 도식화와 C4 Model
15 Spring Cloud
16 Docker 기본 개념
17 Docker 주요 실습
18 Docker Swarm
19 Kubernetes
20 Kubernetes 주요 오브젝트
21 Ingress와 Service Mesh
22 CI/CD
23 학습 내용 정리
1 MSA란 무엇인가
1) MSA의 의미
(1) MSA
MSA는 Microservices Architecture의 줄임말이다.
하나의 큰 애플리케이션을 여러 개의 작은 서비스로 나누고, 각 서비스가 독립적으로 실행되고 배포될 수 있도록 구성하는 아키텍처이다.
(2) Microservice
마이크로서비스는 하나의 비즈니스 기능을 담당하는 작은 서비스이다.
예를 들어 쇼핑몰이라면 회원 서비스, 주문 서비스, 결제 서비스, 배송 서비스처럼 나눌 수 있다.
(3) 핵심
MSA의 핵심은 큰 시스템을 작게 나누는 것이다.
하지만 단순히 코드를 작게 나누는 것이 아니라, 비즈니스 기능 단위로 나누고 각 서비스가 독립적으로 개발, 배포, 확장될 수 있어야 한다.
2) MSA의 기본 구조
(1) 독립 실행
각 마이크로서비스는 자기 자신의 프로세스에서 실행된다.
하나의 서비스가 죽더라도 전체 시스템이 모두 멈추지 않도록 설계할 수 있다.
(2) 가벼운 통신
서비스들은 HTTP API, 메시지 큐, 이벤트 등을 통해 통신한다.
직접 메소드 호출처럼 강하게 묶이는 방식보다 느슨하게 연결되는 구조를 지향한다.
(3) 독립 배포
각 서비스는 독립적으로 배포할 수 있어야 한다.
주문 서비스만 수정했다면 전체 시스템을 다시 배포하는 것이 아니라 주문 서비스만 배포할 수 있어야 한다.
2 모놀리식 아키텍처와 MSA
1) 모놀리식 아키텍처
(1) 의미
모놀리식 아키텍처는 하나의 애플리케이션 안에 모든 기능이 들어 있는 구조이다.
회원, 주문, 결제, 배송 기능이 하나의 프로젝트와 하나의 배포 단위 안에 들어가는 방식이다.
(2) 장점
서비스 규모가 작을 때는 구조가 단순하고 개발하기 쉽다.
한 프로젝트 안에서 모든 기능을 볼 수 있고, 배포도 하나만 하면 된다.
(3) 단점
시스템이 커지면 코드베이스가 비대해진다.
한 기능의 문제가 전체 장애로 이어질 수 있고, 작은 수정에도 전체 시스템을 다시 배포해야 할 수 있다.
2) MSA
(1) 의미
MSA는 큰 시스템을 작은 서비스들로 나눈 구조이다.
각 서비스는 독립된 기능을 담당하고, 필요한 경우 서로 API나 메시지로 통신한다.
(2) 장점
서비스별로 독립 개발, 독립 배포, 독립 확장이 가능하다.
한 서비스에 장애가 발생해도 전체 시스템으로 장애가 번지는 것을 줄일 수 있다.
(3) 단점
서비스가 많아지면 통신 구조, 배포 구조, 모니터링, 로그 관리, 장애 대응이 복잡해진다.
즉, MSA는 코드를 나누는 것보다 운영 복잡도를 감당하는 것이 더 어렵다.
3 MSA의 주요 특징
1) MSA의 9가지 특징
(1) Componentization via Services
기능을 라이브러리나 모듈이 아니라 서비스 단위로 나눈다.
각 서비스는 독립적인 실행 단위가 된다.
(2) Organized around Business Capabilities
기술 계층이 아니라 비즈니스 기능을 기준으로 서비스를 나눈다.
예를 들어 Controller, Service, DAO 기준으로 나누는 것이 아니라 주문, 결제, 회원 같은 비즈니스 기준으로 나눈다.
(3) Products not Projects
프로젝트를 한 번 만들고 끝내는 것이 아니라, 서비스 자체를 계속 운영하고 발전시키는 제품으로 본다.
(4) Smart endpoints and dumb pipes
서비스 자체가 똑똑하게 비즈니스 로직을 처리하고, 통신 경로는 단순하게 유지한다.
복잡한 중앙 통합 장치에 모든 로직을 몰아넣지 않는다.
(5) Decentralized Governance
모든 서비스가 반드시 같은 기술을 사용할 필요는 없다.
서비스 특성에 따라 다른 언어, 프레임워크, 저장소를 사용할 수 있다.
(6) Decentralized Data Management
하나의 중앙 DB에 모든 서비스가 붙는 것이 아니라, 서비스별로 데이터를 분리해서 관리할 수 있다.
(7) Infrastructure Automation
서비스가 많기 때문에 배포와 운영을 수동으로 처리하기 어렵다.
CI/CD, 컨테이너, 오케스트레이션 같은 자동화가 중요하다.
(8) Design for Failure
분산 시스템에서는 장애가 발생할 수밖에 없다고 보고 설계해야 한다.
일부 서비스 장애가 전체 장애로 확산되지 않도록 해야 한다.
(9) Evolutionary Design
처음부터 완벽한 설계를 고정하는 것이 아니라, 서비스가 성장하면서 점진적으로 개선할 수 있어야 한다.
4 MSA 전환 사례
1) Coupang
(1) 초기 구조
쿠팡은 초기에는 Apache, Tomcat, MySQL 기반의 모놀리식 구조로 운영되었다.
(2) 문제점
고객과 개발자가 급격히 늘어나면서 확장성 문제가 발생했다.
한 컴포넌트의 장애가 전체 장애로 이어지고, 공통 모듈이 비대해지고, 배포와 테스트 비용이 커졌다.
(3) 전환
쿠팡은 2013년부터 MSA 전환을 추진했다.
자체적으로 Java 기반의 Vitamin Framework를 구축했다는 점이 특징이다.
2) 11번가
(1) 기존 구조
11번가는 오랫동안 초대형 모놀리식 시스템을 운영했다.
오래된 소프트웨어 스택, 거대한 공통 모듈, 어려운 개발 환경, 정기 배포의 부담이 있었다.
(2) 문제점
하나의 수정이 전체 장애로 이어질 수 있었고, IDE에 프로젝트를 띄우는 것조차 버거운 상황이었다.
(3) 전환
Netflix Spring Cloud와 Spring Boot 기반의 MSA 구조로 점진적으로 전환했다.
3) 카카오톡 이모티콘 서비스
(1) 기존 문제
이모티콘 서비스, 이모티콘 스튜디오, Admin 서비스들이 각각 모놀리식으로 구성되어 있었다.
오래된 Java와 Play Framework를 사용해 기술 부채가 컸다.
(2) 운영 문제
배포 방식이 서버마다 다르고, 브랜치 관리가 복잡하며, 메인 DB 트래픽이 높아지는 문제가 있었다.
(3) 전환 방향
Kotlin, Spring, Kubernetes, Istio 등을 활용해 MSA 기반 구조로 개선했다.
4) 토스뱅크
(1) 기존 은행 시스템
일반적인 은행 시스템은 채널계와 코어뱅킹으로 나뉜다.
채널계는 MSA 구조를 적용하기 쉬웠지만, 코어뱅킹은 오랫동안 모놀리식 구조로 유지되었다.
(2) 문제점
모놀리식 코어뱅킹은 트랜잭션 처리에는 유리하지만 스케일 아웃이 어렵고, 장애 영향 범위를 제한하기 어렵다.
(3) 전환
토스뱅크는 모바일 특화 MSA 아키텍처로 코어뱅킹을 전환했다.
이를 통해 도메인별 독립 개선과 빠른 기능 배포가 가능해졌다.
5 MSA를 무조건 선택하면 안 되는 이유
1) MSA의 적절한 사용 시점
(1) 작은 서비스에는 모놀리식이 유리할 수 있다
서비스 규모가 작을 때는 모놀리식 구조가 더 단순하고 효율적이다.
스타트업이 MVP를 만들 때 처음부터 MSA를 선택하면 오버엔지니어링이 될 수 있다.
(2) MSA가 필요한 시점
코드베이스가 너무 커져 관리가 어렵거나, 개발자가 많아져 배포 충돌이 잦거나, 특정 기능만 독립 확장해야 할 때 MSA를 고려할 수 있다.
(3) 핵심 판단 기준
MSA는 유행이라서 선택하는 것이 아니다.
서비스 규모, 팀 규모, 배포 빈도, 장애 격리 필요성, 확장성 요구가 분명할 때 선택해야 한다.
2) MSA의 어려움
(1) 서비스 간 통신 복잡도
서비스를 나누면 각 서비스가 네트워크를 통해 통신해야 한다.
네트워크 지연, 장애, 타임아웃, 재시도 같은 문제가 발생한다.
(2) 운영 복잡도 증가
서비스가 많아지면 로그, 모니터링, 배포, 설정 관리, 장애 추적이 어려워진다.
(3) 데이터 관리 복잡도
서비스별 DB를 분리하면 데이터 정합성을 맞추는 방식도 고민해야 한다.
하나의 트랜잭션으로 모든 처리를 끝내기 어려워질 수 있다.
6 MSA 이전 방법론
1) 직접 아키텍처 구축
(1) 의미
기업 내부에서 자체 프레임워크와 도구를 만들어 MSA를 구축하는 방식이다.
(2) 장점
필요한 부분을 원하는 방식으로 수정할 수 있다.
조직에 맞는 맞춤형 구조를 만들 수 있다.
(3) 단점
충분한 인력, 시간, 예산이 필요하다.
이후 유지보수 비용도 계속 발생한다.
2) Netflix Spring Cloud 사용
(1) 의미
Spring Cloud와 Netflix OSS를 활용해 MSA를 구현하는 방식이다.
Eureka, Zuul, Ribbon, Hystrix 같은 구성 요소를 사용할 수 있다.
(2) 장점
Java와 Spring Boot 기반 프로젝트에 적합하다.
사례가 많고 Java 개발자에게 익숙하다.
(3) 단점
Java와 Spring Boot에 종속될 수 있다.
MSA 관련 코드가 소스 레벨에 포함될 수 있다.
3) Kubernetes 사용
(1) 의미
컨테이너와 Kubernetes를 기반으로 서비스를 배포하고 운영하는 방식이다.
(2) 장점
언어에 종속되지 않는다.
Java, Python, Node.js 등 다양한 언어로 작성된 서비스를 함께 운영할 수 있다.
(3) 단점
Kubernetes 자체의 학습 난이도가 높다.
컨테이너, 네트워크, 배포, 운영에 대한 이해가 필요하다.
7 소프트웨어 아키텍처 구성 요소
1) 아키텍처를 구성하는 요소
(1) 아키텍처 특성
시스템이 지원해야 하는 품질 속성이다.
가용성, 신뢰성, 민첩성, 복구성, 확장성, 성능 등이 여기에 해당한다.
(2) 아키텍처 결정
시스템을 구축할 때 지켜야 하는 중요한 규칙이다.
예를 들어 데이터베이스 접근은 특정 계층에서만 허용한다는 결정이 있을 수 있다.
(3) 설계 원칙
시스템을 만들 때 따라야 할 가이드라인이다.
예를 들어 서비스 간 통신은 비동기 메시징을 우선 사용한다는 원칙을 둘 수 있다.
(4) 시스템 구조
어떤 아키텍처 스타일을 적용했는지를 의미한다.
예를 들어 레이어드 아키텍처, 이벤트 기반 아키텍처, 마이크로서비스 아키텍처가 있다.
8 ADR
1) ADR의 의미
(1) ADR
ADR은 Architecture Decision Record의 줄임말이다.
중요한 아키텍처 결정을 문서화하는 방법이다.
(2) 필요한 이유
왜 이런 기술을 선택했는지, 왜 이런 구조로 설계했는지 기록하지 않으면 시간이 지난 뒤 이유를 알기 어렵다.
ADR은 의사결정의 배경과 결과를 남기는 문서이다.
2) ADR의 기본 구조
(1) 제목
어떤 결정을 기록하는지 짧게 작성한다.
(2) 상태
제안됨, 수락됨, 대체됨 같은 상태를 기록한다.
(3) 콘텍스트
왜 이 결정을 해야 했는지 상황을 설명한다.
(4) 결정
어떤 결정을 내렸는지와 그 이유를 작성한다.
(5) 결과
이 결정이 시스템과 팀에 어떤 영향을 주는지 정리한다.
9 서비스 기반 아키텍처
1) 서비스 기반 아키텍처
(1) 의미
서비스 기반 아키텍처는 여러 원격 서비스를 사용하는 대규모 분산 레이어 구조이다.
MSA와 비슷하지만 중앙 공유 데이터베이스를 사용할 수 있다는 점이 다르다.
(2) 특징
UI와 여러 서비스가 분리되어 있고, 서비스들이 공통 DB를 사용할 수 있다.
MSA보다 현실적으로 도입하기 쉬운 경우가 있다.
(3) MSA와의 차이
MSA는 서비스별로 데이터까지 분리하는 방향을 지향한다.
서비스 기반 아키텍처는 중앙 공유 DB를 사용할 수 있어 데이터 분리 강도가 MSA보다 약하다.
10 이벤트 기반 아키텍처
1) 이벤트 기반 아키텍처
(1) 의미
이벤트 기반 아키텍처는 이벤트를 중심으로 시스템이 동작하는 구조이다.
어떤 사건이 발생하면 그 이벤트를 비동기적으로 처리한다.
(2) 장점
확장성이 좋고, 고성능 애플리케이션에 적합하다.
서비스들이 직접 강하게 연결되지 않고 이벤트를 통해 느슨하게 연결될 수 있다.
(3) 주요 구성
시작 이벤트, 이벤트 브로커, 이벤트 프로세서, 처리 이벤트 등이 있다.
중재자 토폴로지와 브로커 토폴로지 같은 구조를 사용할 수 있다.
11 마이크로서비스 아키텍처
1) 마이크로서비스 아키텍처
(1) 핵심 목표
마이크로서비스의 주요 목표는 서비스 간 결합도를 낮추는 것이다.
각 서비스가 독립적으로 개발, 배포, 확장될 수 있도록 만든다.
(2) 데이터 격리
마이크로서비스는 서비스별로 데이터를 분리하는 것이 중요하다.
데이터베이스를 공유하면 서비스 간 의존성이 커질 수 있다.
(3) API Gateway
클라이언트 요청을 여러 서비스로 라우팅하기 위해 API Gateway를 사용할 수 있다.
인증, 인가, SSL, 캐싱, 라우팅 같은 공통 기능을 처리할 수 있다.
12 DDD와 마이크로서비스 설계
1) DDD
(1) 의미
DDD는 Domain Driven Design의 줄임말로 도메인 주도 설계를 의미한다.
비즈니스 도메인을 중심으로 시스템을 설계하는 방법이다.
(2) MSA와의 관계
MSA에서는 서비스를 비즈니스 기능 단위로 나누는 것이 중요하다.
DDD는 어떤 기준으로 서비스를 나눌지 판단하는 데 도움을 준다.
2) 서브도메인
(1) 핵심 서브도메인
기업의 경쟁력을 만드는 핵심 비즈니스 영역이다.
직접 개발하고 집중적으로 관리해야 하는 영역이다.
(2) 지원 서브도메인
비즈니스에 필요하지만 핵심 경쟁력은 아닌 영역이다.
(3) 일반 서브도메인
비즈니스에 특화되지는 않았지만 필요한 영역이다.
기존 제품이나 SaaS를 활용해 대체할 수 있다.
3) 바운디드 컨텍스트
(1) 의미
바운디드 컨텍스트는 하나의 도메인 모델이 적용되는 경계이다.
같은 단어라도 컨텍스트가 다르면 의미가 달라질 수 있다.
(2) 중요한 이유
서비스의 경계를 정할 때 바운디드 컨텍스트를 기준으로 삼을 수 있다.
내부 응집도는 높이고, 외부 의존도는 낮추는 것이 중요하다.
4) 유비쿼터스 언어
(1) 의미
유비쿼터스 언어는 특정 도메인 안에서 모두가 같은 의미로 사용하는 공통 언어이다.
기획자, 개발자, 사용자, 도메인 전문가가 같은 용어를 같은 의미로 사용하도록 돕는다.
(2) 필요한 이유
용어가 다르면 요구사항 이해가 달라질 수 있다.
유비쿼터스 언어를 정리하면 도메인 이해와 커뮤니케이션 오류를 줄일 수 있다.
13 이벤트 스토밍
1) 이벤트 스토밍의 의미
(1) 이벤트 스토밍
이벤트 스토밍은 이벤트를 중심으로 이해관계자들이 모여 도메인을 분석하는 방법이다.
최종 결과는 컨텍스트맵으로 이어질 수 있다.
(2) 목적
시스템에서 어떤 사건이 발생하고, 누가 어떤 명령을 내리고, 어떤 데이터가 바뀌는지 시각적으로 정리한다.
2) 주요 스티커 유형
(1) 도메인 이벤트
이미 발생한 사건이다.
과거시제 동사로 표현한다.
(2) 커맨드
도메인 이벤트를 발생시키는 명령이다.
API 요청과 연결될 수 있다.
(3) 액터
시스템을 사용하는 사람이나 조직의 역할이다.
(4) 애그리게이트
커맨드와 이벤트가 처리하는 데이터이다.
상태가 변경되는 핵심 데이터로 볼 수 있다.
(5) 정책
특정 이벤트가 발생했을 때 어떤 커맨드를 실행할지 나타낸다.
“이 이벤트가 발생하면 이 명령을 수행한다”처럼 표현한다.
(6) 핫스팟
아직 결정되지 않은 질문, 의문, 위험 요소를 표시한다.
14 아키텍처 도식화와 C4 Model
1) 아키텍처 도식화
(1) 필요한 이유
아키텍처는 말로만 설명하면 이해하기 어렵다.
시스템 구조를 그림으로 표현하면 이해관계자와 개발자가 같은 구조를 공유하기 쉽다.
(2) 도구
UML, C4, ArchiMate 같은 표준이 있다.
PlantUML은 텍스트 기반으로 다이어그램을 작성할 수 있는 도구이다.
2) C4 Model
(1) Context
전체 시스템과 외부 사용자, 외부 시스템의 관계를 보여준다.
(2) Container
시스템 내부의 배포 가능한 단위를 보여준다.
웹 애플리케이션, API 서버, 데이터베이스 같은 단위가 컨테이너가 될 수 있다.
(3) Component
컨테이너 내부의 주요 모듈과 역할을 보여준다.
(4) Code
컴포넌트 내부의 클래스 구조를 보여준다.
필요할 때만 상세하게 작성한다.
15 Spring Cloud
1) Spring Cloud의 의미
(1) Spring Cloud
Spring Cloud는 마이크로서비스 아키텍처를 구축하고 관리하기 위한 도구와 프레임워크의 모음이다.
Spring Boot 기반 애플리케이션에 여러 분산 시스템 기능을 추가할 수 있다.
2) 주요 구성 요소
(1) Service Discovery
서비스의 위치를 등록하고 찾는 기능이다.
대표적으로 Eureka가 있다.
(2) API Gateway
클라이언트와 마이크로서비스 사이에서 라우팅, 인증, 로드밸런싱 등을 처리한다.
(3) Circuit Breaker
장애가 발생한 서비스 호출을 격리하여 전체 장애 확산을 막는다.
과거에는 Hystrix를 사용했고, 현재는 Resilience4J를 많이 사용한다.
(4) Configuration Management
여러 서비스의 설정 정보를 중앙에서 관리한다.
(5) Distributed Tracing
여러 서비스를 거치는 요청 흐름을 추적한다.
장애 분석과 성능 최적화에 도움이 된다.
16 Docker 기본 개념
1) Docker
(1) 의미
Docker는 애플리케이션과 실행에 필요한 파일, 라이브러리, 설정을 컨테이너 형태로 패키징하고 실행하는 도구이다.
(2) VM과 차이
VM은 운영체제 전체를 가상화한다.
Docker 컨테이너는 호스트의 커널을 공유하고, 애플리케이션 실행에 필요한 환경만 별도로 가진다.
(3) 장점
VM보다 가볍고 실행이 빠르다.
개발 환경과 운영 환경의 차이를 줄일 수 있다.
2) 컨테이너
(1) 의미
컨테이너는 애플리케이션을 실행하기 위한 격리된 환경이다.
애플리케이션, 라이브러리, 설정 파일을 함께 포함한다.
(2) 이미지
이미지는 컨테이너를 만들기 위한 실행 템플릿이다.
컨테이너는 이미지를 실행한 결과이다.
(3) Dockerfile
Dockerfile은 이미지를 만들기 위한 명령어를 작성한 파일이다.
어떤 베이스 이미지를 사용할지, 어떤 파일을 복사할지, 어떤 명령으로 실행할지를 정의한다.
17 Docker 주요 실습
1) 기본 명령어
(1) docker -v
Docker 버전을 확인한다.
(2) docker run
이미지를 기반으로 컨테이너를 생성하고 실행한다.
(3) docker ps
현재 실행 중인 컨테이너 목록을 확인한다.
(4) docker ps -a
종료된 컨테이너를 포함해 모든 컨테이너를 확인한다.
(5) docker images
로컬에 저장된 이미지 목록을 확인한다.
(6) docker rm
컨테이너를 삭제한다.
(7) docker rmi
이미지를 삭제한다.
2) 웹 서버 실습
(1) 포트 매핑
컨테이너 내부의 80번 포트를 호스트의 80번 포트와 연결했다.
이를 통해 브라우저에서 컨테이너 내부 웹 서버에 접속할 수 있다.
(2) Apache 실행
Ubuntu 컨테이너에 apache2를 설치하고 service apache2 start로 웹 서버를 실행했다.
3) WordPress 실습
(1) MySQL 컨테이너
WordPress에서 사용할 DB로 MySQL 컨테이너를 실행했다.
(2) WordPress 컨테이너
WordPress 컨테이너를 실행하고 MySQL 컨테이너와 연결했다.
(3) Volume 사용
DB 데이터를 컨테이너 내부에만 저장하면 컨테이너 삭제 시 데이터가 사라진다.
Volume을 사용하면 데이터를 호스트나 Docker Volume에 저장해 유지할 수 있다.
4) Docker Network
(1) bridge
기본 네트워크 방식이다.
컨테이너는 브리지 네트워크를 통해 외부와 통신한다.
(2) host
컨테이너가 호스트의 네트워크를 그대로 사용한다.
(3) none
네트워크를 사용하지 않는 컨테이너를 만들 수 있다.
(4) network alias
같은 네트워크 안에서 컨테이너를 별칭으로 접근할 수 있다.
5) Docker Logging
(1) json-file
Docker의 기본 로그 드라이버이다.
컨테이너의 stdout, stderr 로그를 JSON 파일로 저장한다.
(2) syslog
로그를 syslog로 보낼 수 있다.
(3) fluentd
fluentd를 이용해 로그를 수집하고 MongoDB 같은 저장소로 보낼 수 있다.
(4) CloudWatch
AWS 환경에서는 CloudWatch로 컨테이너 로그를 전송할 수 있다.
6) 이미지 관리
(1) docker commit
실행 중인 컨테이너의 상태를 이미지로 저장할 수 있다.
(2) docker tag
이미지에 새로운 이름과 태그를 붙일 수 있다.
(3) docker push
이미지를 Docker Hub나 Private Registry에 업로드할 수 있다.
(4) docker pull
원격 저장소에서 이미지를 내려받을 수 있다.
18 Docker Swarm
1) Docker Swarm
(1) 의미
Docker Swarm은 여러 Docker 서버를 하나의 클러스터처럼 관리하는 오케스트레이션 도구이다.
(2) 필요한 이유
실제 운영 환경에서는 컨테이너를 하나의 서버에서만 실행하기 어렵다.
여러 서버에 컨테이너를 분산 배치하고, 장애 시 복구하고, 서비스를 확장해야 한다.
2) 주요 개념
(1) Manager Node
클러스터를 관리하는 노드이다.
서비스 생성, 스케줄링, 상태 관리를 담당한다.
(2) Worker Node
실제 컨테이너 작업을 실행하는 노드이다.
(3) Service
Swarm에서 실행할 애플리케이션 단위이다.
몇 개의 replica를 실행할지 지정할 수 있다.
(4) Replica
동일한 서비스 인스턴스의 개수이다.
replica를 늘리면 여러 컨테이너가 분산 실행된다.
3) Swarm 실습
(1) 클러스터 생성
manager 노드에서 docker swarm init을 실행해 클러스터를 생성했다.
(2) worker join
worker 노드들은 join token을 사용해 클러스터에 참여했다.
(3) service create
docker service create 명령으로 서비스를 생성했다.
(4) scale
docker service scale 명령으로 서비스 인스턴스 수를 늘리거나 줄였다.
(5) 자가복구
컨테이너 하나를 강제로 삭제해도 Swarm이 원하는 replica 수를 유지하기 위해 새 컨테이너를 다시 생성한다.
19 Kubernetes
1) Kubernetes
(1) 의미
Kubernetes는 컨테이너 오케스트레이션 도구이다.
여러 서버에서 컨테이너를 배포, 확장, 복구, 네트워킹, 서비스 연결까지 관리한다.
(2) 필요한 이유
컨테이너가 많아지면 수동으로 관리하기 어렵다.
어느 서버에 어떤 컨테이너를 배치할지, 장애 시 어떻게 복구할지, 외부 요청을 어떻게 연결할지 자동화가 필요하다.
(3) 시장 표준
여러 오케스트레이션 도구 중 Kubernetes가 사실상 시장 표준으로 사용된다.
2) Kubernetes 구성 요소
(1) kube-apiserver
Kubernetes API를 제공하는 서버이다.
모든 요청은 API Server를 통해 처리된다.
(2) etcd
클러스터 상태와 설정 정보를 저장하는 key-value 저장소이다.
(3) kube-scheduler
새로 생성되는 Pod를 어떤 노드에 배치할지 결정한다.
(4) kube-controller-manager
여러 컨트롤러를 실행하며 클러스터 상태를 원하는 상태로 유지한다.
(5) kubelet
각 노드에서 실행되며, Pod와 컨테이너 상태를 관리한다.
(6) kube-proxy
Service 네트워크와 트래픽 전달을 담당한다.
20 Kubernetes 주요 오브젝트
1) Pod
(1) 의미
Pod는 Kubernetes에서 배포 가능한 가장 작은 실행 단위이다.
하나 이상의 컨테이너를 포함할 수 있다.
2) ReplicaSet
(1) 의미
ReplicaSet은 정해진 수의 Pod가 항상 실행되도록 관리한다.
Pod가 죽으면 새 Pod를 만들어 개수를 유지한다.
3) Deployment
(1) 의미
Deployment는 애플리케이션 배포 단위이다.
내부적으로 ReplicaSet과 Pod를 관리한다.
(2) 사용하는 이유
업데이트, 롤백, 스케일링을 쉽게 수행할 수 있다.
4) Service
(1) 의미
Service는 Pod에 접근하기 위한 고정된 네트워크 진입점이다.
Pod는 생성되고 삭제되면서 IP가 바뀔 수 있기 때문에 Service가 안정적인 접근 경로를 제공한다.
5) Service Type
(1) ClusterIP
클러스터 내부에서만 접근 가능한 Service이다.
(2) NodePort
모든 노드의 특정 포트를 열어 외부에서 접근할 수 있게 한다.
(3) LoadBalancer
클라우드 제공자의 로드밸런서를 사용해 외부 IP를 제공한다.
6) Update와 Rollback
(1) Update
Deployment의 이미지 버전을 바꿔 새로운 버전으로 배포할 수 있다.
(2) Rollback
문제가 생기면 이전 버전으로 되돌릴 수 있다.
7) Scaling
(1) 의미
replicas 수를 조절해 Pod 개수를 늘리거나 줄일 수 있다.
트래픽이 많아지면 늘리고, 적어지면 줄일 수 있다.
21 Ingress와 Service Mesh
1) Ingress
(1) 의미
Ingress는 외부 요청을 경로 기반이나 도메인 기반으로 내부 Service에 전달하기 위한 Kubernetes 객체이다.
(2) 필요한 이유
MSA에서는 /user, /product, /pay 같은 경로를 각각 다른 서비스로 보내야 할 수 있다.
Ingress는 이런 라우팅 규칙을 정의한다.
(3) SSL/TLS 처리
여러 서비스에 각각 인증서를 넣는 대신 Ingress에서 SSL/TLS를 일괄 처리할 수 있다.
2) Ingress Controller
(1) 의미
Ingress는 규칙만 정의한다.
실제로 요청을 받아 라우팅하는 주체는 Ingress Controller이다.
(2) 예시
nginx ingress controller를 사용할 수 있다.
외부 요청은 Ingress Controller를 거쳐 내부 Service로 전달된다.
3) Istio
(1) 의미
Istio는 마이크로서비스 간 통신을 관리하는 서비스 메쉬 플랫폼이다.
(2) Sidecar
Kubernetes에서는 Pod마다 Envoy Proxy를 sidecar로 삽입해 트래픽을 통제할 수 있다.
(3) 기능
Istio는 라우팅, Circuit Breaker, fault injection, 버전별 트래픽 분배, 로그인 사용자 기반 라우팅 같은 기능을 제공한다.
(4) Kiali
Kiali는 Istio 서비스 메쉬의 트래픽 흐름을 시각화해주는 도구이다.
22 CI/CD
1) CI/CD의 의미
(1) CI
CI는 Continuous Integration의 줄임말이다.
여러 개발자의 코드를 자주 통합하고 테스트하는 과정이다.
(2) CD
CD는 Continuous Delivery 또는 Continuous Deployment를 의미한다.
코드가 항상 배포 가능한 상태를 유지하거나, 실제 운영 환경까지 자동 배포되도록 만드는 과정이다.
(3) 핵심
CI/CD는 개발자의 코드가 사용자가 사용할 수 있는 서비스로 전달되는 과정을 자동화하는 것이다.
2) Git 브랜치 전략
(1) Gitflow
master, develop, release, feature, hotfix 브랜치를 사용하는 전략이다.
브랜치가 많아 관리가 복잡할 수 있다.
(2) Trunk-based
main 또는 trunk 브랜치를 중심으로 짧은 주기의 통합을 지향한다.
CI/CD와 잘 맞는다.
(3) Github Flow
main과 feature 브랜치를 중심으로 작업한다.
main에 merge되면 배포로 이어지는 단순한 흐름을 가진다.
3) Github Actions
(1) 의미
Github Actions는 GitHub에서 제공하는 Workflow 자동화 도구이다.
테스트, 빌드, 배포 같은 작업을 자동화할 수 있다.
(2) Workflow
자동화 프로세스의 최상위 단위이다.
.github/workflows 폴더 안에 YAML 파일로 작성한다.
(3) Event
Workflow를 실행시키는 조건이다.
push, pull request, cron, webhook 등이 있다.
(4) Job
Workflow 안에서 실행되는 작업 단위이다.
여러 Job은 병렬 또는 순차적으로 실행될 수 있다.
(5) Step
Job 안에서 실행되는 세부 작업이다.
명령어를 실행하거나 Action을 사용할 수 있다.
(6) Runner
Workflow가 실제로 실행되는 환경이다.
GitHub가 제공하는 runner를 사용할 수도 있고, 직접 runner를 구성할 수도 있다.
4) Spring Boot와 CI/CD
(1) Spring Boot
Spring Boot는 Spring 기반 애플리케이션을 빠르게 시작할 수 있도록 도와주는 프레임워크이다.
내장 Tomcat을 제공하므로 별도의 WAS 설정 없이 실행할 수 있다.
(2) Gradle 빌드
gradlew build를 통해 jar 파일을 만들 수 있다.
결과물은 build/libs 아래에 생성된다.
(3) Docker 이미지 빌드
Dockerfile을 작성해 Spring Boot jar 파일을 컨테이너 이미지로 만들 수 있다.
(4) Kubernetes 배포
Deployment와 Service YAML을 작성해 Kubernetes 클러스터에 배포할 수 있다.
GitHub Actions를 이용하면 빌드부터 배포까지 자동화할 수 있다.
23 학습 내용 정리
1) MSA
(1) MSA는 큰 애플리케이션을 작은 서비스로 나누는 아키텍처이다.
(2) 서비스는 비즈니스 기능 단위로 나누는 것이 중요하다.
(3) 각 서비스는 독립 실행, 독립 배포, 독립 확장이 가능해야 한다.
(4) MSA는 장점도 크지만 운영 복잡도도 크기 때문에 무조건 선택하면 안 된다.
2) MSA 설계
(1) DDD는 마이크로서비스 경계를 나누는 데 도움을 준다.
(2) 바운디드 컨텍스트는 서비스 경계를 정의할 때 중요한 개념이다.
(3) 유비쿼터스 언어는 도메인 안에서 같은 용어를 같은 의미로 사용하게 해준다.
(4) 이벤트 스토밍은 도메인 이벤트를 중심으로 서비스를 도출하는 방법이다.
3) 아키텍처 문서화
(1) ADR은 중요한 아키텍처 결정을 기록하는 문서이다.
(2) C4 Model은 Context, Container, Component, Code 단계로 아키텍처를 표현한다.
(3) PlantUML은 텍스트로 다이어그램을 작성할 수 있는 도구이다.
4) Spring Cloud
(1) Spring Cloud는 Spring Boot 기반 MSA 구축을 도와주는 도구 모음이다.
(2) Eureka는 서비스 등록과 탐색을 담당한다.
(3) Gateway는 요청 라우팅과 인증, 필터링을 담당한다.
(4) Resilience4J는 장애 격리를 위한 Circuit Breaker 기능을 제공한다.
(5) Config는 설정 정보를 중앙에서 관리한다.
5) Docker
(1) Docker는 애플리케이션 실행 환경을 컨테이너로 패키징한다.
(2) 이미지는 컨테이너 실행을 위한 템플릿이다.
(3) 컨테이너는 이미지를 실행한 결과이다.
(4) Volume은 컨테이너 데이터 유지에 필요하다.
(5) Dockerfile은 이미지를 만들기 위한 설계도이다.
6) Docker Swarm
(1) Docker Swarm은 여러 Docker 서버를 클러스터로 관리한다.
(2) manager node와 worker node로 구성된다.
(3) service와 replica를 통해 컨테이너를 분산 실행한다.
(4) 컨테이너가 죽어도 원하는 상태를 유지하기 위해 자가복구한다.
7) Kubernetes
(1) Kubernetes는 컨테이너 오케스트레이션 도구이다.
(2) Pod는 가장 작은 배포 단위이다.
(3) Deployment는 애플리케이션 배포와 업데이트를 관리한다.
(4) Service는 Pod에 안정적으로 접근하기 위한 네트워크 객체이다.
(5) Ingress는 외부 요청을 경로 또는 도메인 기준으로 내부 서비스에 연결한다.
8) CI/CD
(1) CI는 코드를 지속적으로 통합하고 테스트하는 것이다.
(2) CD는 배포 가능한 상태를 유지하거나 배포 자체를 자동화하는 것이다.
(3) GitHub Actions는 Workflow를 통해 빌드, 테스트, 배포를 자동화할 수 있다.
(4) Spring Boot 애플리케이션은 Gradle로 빌드하고, Docker 이미지로 만들고, Kubernetes에 배포할 수 있다.
9) 이틀 동안 배운 점
(1) MSA는 단순히 서비스를 작게 나누는 것이 아니다
서비스를 나누는 기준은 기술 계층이 아니라 비즈니스 도메인이다.
잘못 나누면 오히려 복잡도만 증가할 수 있다.
(2) MSA는 설계와 운영이 함께 필요하다
서비스 분리만으로 MSA가 완성되지 않는다.
서비스 검색, 설정 관리, 장애 격리, 로그, 모니터링, 배포 자동화가 함께 필요하다.
(3) 컨테이너는 MSA 운영의 기본 기술이다
Docker는 애플리케이션 실행 환경을 컨테이너로 통일해준다.
Kubernetes는 여러 컨테이너를 실제 운영 환경에서 관리할 수 있게 해준다.
(4) 아키텍처 결정은 기록해야 한다
어떤 기술을 선택했는지, 왜 그렇게 나누었는지 기록하지 않으면 나중에 유지보수가 어려워진다.
ADR과 C4 Model은 이런 결정을 정리하고 공유하는 데 도움이 된다.
(5) CI/CD는 MSA에서 필수에 가깝다
서비스가 많아질수록 수동 배포는 현실적으로 어렵다.
GitHub Actions 같은 도구를 이용해 빌드, 테스트, 이미지 생성, 배포를 자동화해야 한다.
(6) 앞으로의 학습 방향
이번 특강을 통해 MSA, Docker, Kubernetes, CI/CD가 서로 따로 떨어진 기술이 아니라 하나의 흐름으로 연결된다는 것을 알게 되었다.
앞으로 Spring Boot로 마이크로서비스를 만들고, Docker 이미지로 패키징한 뒤, Kubernetes에 배포하는 과정을 직접 실습해보면 MSA 구조를 더 명확히 이해할 수 있을 것 같다.
'멀티캠퍼스' 카테고리의 다른 글
| [2026.07.07] - TIL 67일차 (JSP 게시판을 Thymeleaf로 전환하기) (0) | 2026.07.07 |
|---|---|
| [2026.07.06] - TIL 66일차 (Spring Boot 게시판 보완과 Thymeleaf 시작) (0) | 2026.07.07 |
| [2026.06.24] - TIL 58일차 개발자를 위한 UI/UX 특강 정리 (0) | 2026.06.25 |
| [2026.06.23] - TIL 57일차(Spring MVC03 게시판 프로젝트 완성) (0) | 2026.06.25 |
| [2026.06.22] - TIL 56일차 Spring MVC 기본 구조 정리 (1) | 2026.06.25 |