Pillars of Cloud Native - DevOps, Micro Service

JIWON·2025년 6월 11일

cloud

Cloud

목록 보기

6/6

1️⃣ DevOps

🔸 Dev

plan & code
- Git , SVN , JIRA 같은 툴이 많이 사용됨
Build
- Maven , Gradle
Test
- Selenium (파이썬, 웹의 경우), JUnit (Java의 경우)

🔸 Ops

Deploy & Operate
- Docker , Vagrant , Ansible , Terraform , Kubernetes
Monitor
- Nagios , Fluentd

🔸 Agile (애자일 방법론)

2001년부터 시작
소프트웨어 프로젝트를 일련의 선형적 순서로 구성하는 Waterfall 방식의 프로젝트 관리 기법의 단점을 보완하기 위해서 등장
소프트웨어 개발자 그룹이 애자일 소프트웨어 개발에 대한 선언물(The Manifesto for Agile Software Development)을 작성
반복적인 개발 주기와 자기 조직화 팀을 강조하는 일련의 관행
Agile manifesto
- 개인과 개인 간의 상호작용이 프로세스 및 툴보다 우선
- 작동하는 소프트웨어가 포괄적인 문서보다 우선
- 고객과의 협업이 계약 협상보다 우선
- 변화에 대응하는 것이 계획을 따르는 것보다 우선

❓ Waterfall 방법론
요구사항 분석 -> 설계 (개념적|논리적|물리적) -> 구현 -> 테스트 -> 유지보수 -> 운영

폭포수 방법의 문제점:
- 피드백이 없음
- 분석, 설계 - 20%
- 구현 - 10%
- 테스트, 유지보수, 운영 - 70%
큰 프로젝트에서는 폭포수 방법론을 사용하는 것이 맞음

❓ Prototype 방법론

최종 제품을 만들기 전에 시험용 모델(프로토타입)을 먼저 만들어 사용자와 개발자가 반복적으로 의견을 주고받으며 점진적으로 완성도를 높여가는 소프트웨어 개발 방법론

단점 :
- 돈이 너무 많이 듬

🔸 ITIL(IT Infrastruce Library)

1980년대 영국 정부의 CCTA(Central Computer and Telecommunications Agency)에서 IT 인프라 운영의 최고 사례를 모아 발간
2000년대 ITIL V2 부터 IT 인프라 운영관리 de facto로 전세계 IT서비스 기업의 운영 방법론으로 자리 잡음(ITSM)
2019년 ITIL V4 부터 Agile, Lean, DevOps등의 방법론과의 연계성을 강화한 Service Value System 개념으로 전체 체계(Framework) 변화

💠 DevOps

IT 서비스 설계, SW 개발, 릴리즈 및 운영에 이르기까지 전체 서비스 수명주기에 함께 참여하는 IT 서비스 운영 및 개발 엔지니어의 업무 방식

DevOps는 팀이 애플리케이션 개발에서 프로덕션 운영에 이르는 전체 프로세스를 소유하는 방법론
일련의 기술 구현을 넘어 문화와 프로세스의 완전한 변화를 요구
전체 기능이 아닌 작은 구성 요소에서 작업하는 엔지니어 그룹을 요구하여 일반적인 오류 소스인 핸드 오프를 줄임
DevOps는 소프트웨어의 개발(Development)과 운영(Operations)의 합성어로서 소프트웨어 개발자와 정보 기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화
DevOps는 소프트웨어 개발 조직과 운영 조직간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것이 목적
기술이 아닌 철학이며 변경이 아닌 변화

🔸 DevOps Tool Chain

계획(Plan) : 목적을 수행하기 앞서 방법이나 절차 등을 미리 생각하여 계획
코드(Code) : 코드 개발 및 검토, 버전 관리 도구, 코드 병합
빌드(Build) : 지속적인 통합(CI) 도구, 빌드 상태
테스트(Test) : 테스트
패키지(Package) : 애플리케이션 디플로이 이전 단계
릴리스(Release) : 변경 사항 관리, 릴리스 승인, 릴리스 자동화
구성(Operate) : 인프라스트럭처 구성 및 관리, IaC 도구
모니터링(Monitoring) : 애플리케이션 성능 모니터링, 최종 사용자 경험

🔸 DevOps 로의 변화

SOA(Service Oriented Architecture) -> Microservice -> Functional Microservice

Agile Teams -> DevOps Agile Mindset -> Enterprise DecOps

Cloud Infra Automation -> CI/CD -> DevOps Automation

🔸 DevOps 이점

속도 (Agile) - Time to Market, Microservices
신속한 제공 (Delivery) - CI/CD
안정성 (Reliability) - 모니터링 과 로깅
확장 (Scale) - laC(lnfra as code, 코드형 인프라)
협업 강화 (Collaboration) - CLAMS
보안(Security) - Policy as code, 코드형 정책

2️⃣ Microservices

💠 비즈니스 민첩성

Amazon 이나 Netflix, Uber를 비롯해 성공한 Unicorn 기업들의 공통된 특징은 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화된 서비스를 제공한다는 것
자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임없이 서비스를 개선
아마존의 배포속도는 11.6초 정도이고 배포주기는 1초에 1.5번
cloud Infra의 등장으로 가능(참신한 서비스를 가진 스타트업들이 서비스를 빠르게 선보이는데 지대한 영향을 줌)

🔸 Monolithic

하나의 단위로 개발되는 일체식 애플리케이션
보통 3 티어라 불리는 사용자 인터페이스와 데이터베이스 그리고 서버 쪽 애플리케이션의 3개 부분으로 구성
서버 측 애플리케이션이 일체 즉 논리적인 단일체로서 아무리 작은 변화에도 새로운 버전으로 전체를 빌드해서 배포해야 하고 애플리케이션은 단일 프로세스에서 실행되기 때문에 특정기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 하는데 보통 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해서 수평으로 확장
변경이 발생하면 Monolithic 시스템이 단점이 극대화되는데 여러 개의 Monolithic 시스템이 수평으로 확장된 상태이므로 여러 개의 Monolithic 시스템 모두를 전부 다시 빌드하고 배포해야 하고 확장 시 애플리케이션이 병렬로 확장되어 사용량 증가에 대응할 수 있지만 데이터베이스는 통합되어 하나이므로 탄력적으로 대응할 수 없기 때문에 사전에 성능을 감당하기 위해 스케일 업을 통해 용량을 증설해야 함

🔸 Micro Service

서버측이 여러개의 조각으로 구성되어 각 서비스가 별개의 인스턴스로 로딩되는데 여러 서비스 인스턴스가 모여서 하나의 비즈니스 애플리케이션을 구성하고 각기 저장소가 다르므로 업무 단위로 모듈 경계를 명확하게 구분
확장 시에는 특정 기능 별로 독립적으로 확장할 수있고 특정 서비스를 변경할 필요가 있다면 해당 서비스만 빌드해서 배포하면 됨
각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있음

🔸 SOA 와 Microservice

모듈화(modularity) 개념의 발전 흐름
- 구조적(structured) 방법론 : 단순히 기능을 하향식 분해해서 설계해 나감
- 객체지향(object-oriented) 방법론 : 객체 단위로 모듈화하기 위함
- CBD(Component Based Development) : 모듈화의 단위가 기능별로 재사용할 수 있는 좀 더 큰 컴포넌트가 됨
- SOA(Service Oriented Architecture) : 컴포넌트를 모아 비즈니스적으로 의미있고 완결적인 서비스 단위로 모듈화함
CBD와 SOA도 넓게 보면 단위 컴포넌트나 서비스를 구성해서 시스템을 만드는 개념이고 Micro Service 시스템의 구조와 매우 유사
Micro Service 기반으로 시스템을 개발하는 아키텍처 및 개발 방식을 Micro Service 아키텍처(MSA; Microservice Architecture)라고 함
SOA는 이론적인 형태이고
Cloud 의 등장으로 구체화된 것이 MSA

🔸 MSA

여러개의 작은 서비스 집합으로 개발하는 접근 방법
각 서비스는 개별 프로세스에서 실행되고 HTTP 자원 API같은 가벼운 수단을 사용해서 통신
서비스는 비즈니스 기능 단위로 구성하고 자동화된 배포 방식을 사용
서비스에 대한 중앙 집중적인 관리는 최소화하고 각 서비스는 서로 다른 언어와 데이터 저장 기술을 사용할 수 있음
특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 가리켜 Polyglot 하다라고 표현
CBD나 SOA에서는 애플리케이션은 모듈 별로 분리했지만 저장소는 분리하지 못함

모듈화 방식 강화에 도입된 2가지 개념

API 호출 : 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화하는데 다른 서비스의 저장소에 접근하는 수단
REST API : 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있음

🔸 MicroService를 위한 조건

📌 조직의 변화: 업무 기능 중심 팀

Conway's low(콘웨이 법칙) : 멜빈 콘웨이(Melvin E. Conway)가 정의한 조직 과 조직이 개발한 소프트웨어의 관계를 정의한 법칙으로 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사 소통 구조를 반영하도록 하는 것
예전의 일하는 방식을 보면 하나의 애플리케이션을 만드는 데 UI팀, 서버 개발팀, DB팀과 같은 기술 별로 팀이 나눠져 있고 하나의 애플리케이션을 만드는 데는 세 팀 간의 의사 소통이 필요하기 때문에 시스템도 이러한 의사소통 구조를 그대로 반영하고 이러한 팀 구조에서는 팀 간의 의사결정도 느리고 의사 소통도 어려움
Micro Service를 만드는 팀은 업무 기능 중심의 팀이어야 하는데 업무 기능 중심 팀은 역할 또는 기술 별로 팀이 분리되는 것이 아니라 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것을 의미
업무 기능 중심팀은 다양한 역할로 구성되고 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖추고 있음
이 팀은 같은 공간 같은 시간을 공유하기 때문에 의사 소통도 원활하고 의사 결정도 빠르게 진행될 수 있음
여러 기능들이 모여 있다는 의미에서 다기능 팀이라고도 함
이 팀은 자율적으로 담당 비즈니스에 관련된 서비스를 만들 뿐 아니라 개발 이후에 운영할 책임까지 진다
아마존에서 이러한 팀을 two pizza team 이라고 표현

📌 관리 체계의 변화: 자율적인 분권 거버넌스, 폴리글랏

아마존에서는 다기능 팀이 개발과 운영을 책임진다고 했는데 이러한 조직문화를 가리켜 you built it you run it 이라는 모토로 표현하는데 우리가 만들고 우리가 직접 운영한다라는 의미
중앙의 강력한 거버넌스를 추구하지 않기 때문에 Micro Service로 구성된 조직은 중앙의 강력한 표준이나 절차 준수를 강요하지 않음
빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용 ( -> 속도가 생명)
자신의 서비스 성격에 맞는 최적의 언어와 저장소를 자율적으로 선택
예시 :
- 상품팀은 상품 검색 서비스를 위해서 빠른검색에 특화된 NoSQL인 MongoDB와 Node.js 를 선택
- 계약팀은 계약 서비스를 위해 JAVA와 Oracle, Redis를 선택

📌 개발 생명 주기의 변화: 프로젝트가 아니라 제품 중심

기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였기 때문에 필요한 기술을 사용하는 인력들이 한시적으로 모여 장기간의 프로젝트를 통해 개발을 완료하고 나면 이를 운영 조직에 넘기는 방식으로 진행되어서 개발 조직과 운영조직이 분리되어 있음
초기에 모든 일정을 계획했는데 요구사항 정의를 통해 개발할 기능을 나열하고 이에대한 설계를 진행하고 설계가 완료되면 개발이 진행되고 각 단계는 완료 데드라인이 있어서 그 일정을 완료함으로써 최종 기능을 제공하기 때문에 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못함
Micro Service 팀의 개발은 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발 뿐 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 하기 때문에 소프트웨어를 완성해야 할 기능들의 집합으로 보는 것이 아니라 비즈니스를 제공하는 제품(product)으로 바라보고 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어를 개발
소프트웨어를 개발하는 방식 측면에서 프로젝트 형태의 폭포수 모델 또는 빅뱅 방식으로 진행하는 것이 아니라 점진 반복적인 모델 제품 중심의 애자일(agile) 개발 방식을 채용하는데 이 방식은 약 2〜3주 단위의 스프린트(Sprint)를 통해 소프트웨어를 개발 및 배포해서 바로 피드백을 받아 소프트웨어에 반영할 수 있게 해주기 때문에 소프트웨어를 한시적 프로젝트를 통해 고객의 고정된 요건을 받아 기능이 만족되면 제공및 전달하는 개념으로 보지 않고 요건의 변화에 따라 지속적으로 개선되고 발전시킬 제품으로 바라봄

📌 개발 환경의 변화: 인프라 자동화

배포해야할 서비스가 여러개이므로 수동으로 배포하는 방식은 바람직하지 않고 자동화된 배포 방식을 사용
코드만 작성하고 업로드를 하면 컴파일, 유닛 테스트, 기능 테스트, 통합테스트, 인수테스트, 성능테스트 및 배포가 자동으로 이루어지도록 한다
빌드/배포 파이프라인
소스코드 작성 및 수정 -> 컴파일 -> 빌드 -> 개발환경 배포 -> staging 환경 배포 -> 운영 환경 배포
- staging 환경 : 운영환경과 거의 동일한 환경을 만들어 놓고 운영 환경으로 이전하기 전에 Security, 성능, 장애 등의 비기능적 부분을 검증하는 환경
빌드/배포 파이프라인 프로세스는 도구를 통해 자동화해야 하는데 최근에는 배포환경이 Micro Service 개수에 따라 급격하게 늘어나기 때문에 이를 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식인 Infrastructure as Code 가 각광받음
인프라 구성을 코드로 하게 되면 수 많은 하드웨어 리소스 설정을 동일하게 통제할 수 있으며 적절한 설정을 쉽게 복제하고 누구한테나 공유할 수 있게 되어서 인프라를 매우 효율적으로 관리할 수 있음

📌 저장소의 변화: 통합 저장소가 아니라 분권 데이터 관리

Monolithic 시스템을 살펴보면 단일 통합 데이터베이스를 사용
단일 데이터베이스를 유지하는 방식은 과거 스토리지 가격 및 네트워크 속도에 따른 데이터의 안정성과 효율성을 추구한 결과로 데이터를 잘 정리하는 정규화가 반드시 추구해야 할 가치였지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커져서 데이터를 억지로 꾸깃꾸깃 뭉쳐서 작은 공간에 넣을 필요가 없음
Micro Service는 폴리글랏 저장소 접근법을 선택하며 서비스 별로 데이터베이스를 갖도록 설계하는데 각 저장소가 서비스 별로 분산돼 있어야 하며 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 한다는 의미
이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요한데 여기서 반드시 등장하는 문제가 있는데 바로 각 Micro Service의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제
데이터 일관성 처리를 위해서는 보통 2단계 커밋(two-phase commit) 같은 분산 트랜잭션 기법을 사용하는데 각각 다른 서비스를 하나의 트랜잭션으로 묶다 보면 각 서비스의 독립성도 침해되고 NoSQL 저장소처럼 2단계 커밋을 지원하지 않는 경우도 있기 때문에 Micro Service는 데이터 일관성 문제를 해결하기 위해 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조하는데 이를 가리켜 결과적 일관성(Eventual Consistency)이라는 개념으로 표현하기도 하는데 간단히 말해 두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태지만 결국에는 두 데이터가 같아진다는 개념
예시 :
주문서비스와 배송서비스가 있고 저장소가 분리되어 있는 경우
주문이 발생하면 반드시 배송 처리가 되어야 하는 비즈니스
- 두 업무를 2단계 커밋과 같은 분산 트랜잭션 기법을 사용해서 하나로 묶으면 배송 서비스가 실패 했을 때 트랜잭션에 포함된 주문서비스도 함께 Rollback 되도록 처리해서 데이터의 일관성을 맞출 수는 있지만 하나의 데이터베이스가 2단계 커밋을 지원하지 않으면 이렇게 하기가 불가능
- 분산 트랜잭션으로 묶으면 두 서비스가 강하게 결합되어 있어 서비스를 분리한 효과를 누리기 힘들 것

각 트랜잭션을 분리하고 Queue 매커니즘을 이용하는 방법

주문 서비스가 주문 처리 트랜잭션을 수행
- 주문 이벤트를 발행
- 주문 이벤트가 메시지 큐로 전송
- 배송 서비스가 주문 이벤트를 인식
배송서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행
배송 처리 트랜잭션 중 오류로 트랜잭션을 실패
- 배송처리 실패 이벤트를 발행
- 배송처리 실패이벤트가 메시지 큐로 전송
- 주문 서비스가 배송처리 실패 이벤트를 인식
주문 서비스는 주문 취소(보상트랜잭션)을 수행

📌 위기 대응 방식의 변화: 실패를 고려한 설계

버너 보겔스(Werner Vogels)는 소프트웨어는 모두 실패한다 라고말한 바 있는데 시스템은 언제든 실패할 수 있으며 실패해서 더는 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 한다는 의미로 이러한 성격을 내결함성(fault tolerance) 이라 함
예전의 시스템 아키텍처는 무결함이나 실패 무결성을 추구했는데 시스템이 다운되지 않고 중단되지 않기 위해서는 완벽을 추구해야 하며 강건해야 했지만 버너 보겔스의 말처럼 어떤 시스템도 실패하지 않을 수 없는데 실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이라는 것인데 이를 위해서는 다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 함
이러한 예로 서킷 브레이커(circuit breaker) 패턴을 들 수 있는데 이 패턴은 회로 차단기처럼 각 서비스를 모니터링하고 있다가 한 서비스가 다운되거나 실패하면 이를 호출하는 서비스의 연계를 차단하고 적절하게 대응하는 것을 의미
넷플릭스에서는 카오스 몽키(chaos monkey)라는 장애를 일부러 발생시키는 도구를
만들어 이러한 탄력적인 아키텍처가 제대로 동작하는지 점검

💠 MSA의 이해

🔸 리액티브 선언

: 현대 애플리케이션이 갖춰야 할 바람직한 속성들

응답성(Responsive) : 사용자에게 신뢰성 있는 응답을 빠르고 적절하게 제공하는 것, 가치에 해당하는 부분에 유지보수성과 확장성을 추가하기도 한다
탄력성(Resilient) : 장애가 발생하거나 부분적으로 고장나더라도 시스템 전체가 고장나지 않고 빠르게 복구하는 능력
유연성(Elastic) : 시스템의 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미하며 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력
메시지 기반(Message Driven) : 비동기 메시지 전달을 통해 위치 투명성(사용자는 실제 처리가 되는 위치를 몰라도 됨), 느슨한 결합(하나의 서비스가 다른 서비스와 연계는 하지만 하나의 서비스의 중단이 다른 서비스에게 영향을 주지 않도록 결합하는 것), 논블로킹 통신(비동기적으로 통신)을 지향하는 것

🔸 강 결합에서 느슨한 결합의 아키텍처로 변환

예전의 아키텍처의 구성 요소들을 각 기업이나 특정 벤더의 제품에 전적으로 의존해서 구축하거나 수정이 필요한 부분만 별도로 직접 개발하는 경우가 많았기 때문에 특정 벤더 솔루션이나 프레임워크가 변경될 경우 그것에 의존하는 애플리케이션의 많은 부분들을 변경해야 할 정도로 강결합 되어 있었음
특정 벤더 중심의 아키텍처는 검증된 유명 제품군을 사용한다는 점에서 품질이 보장된다고 할 수 있는 반면 특정 벤더에 의존한다는 점에서 특정 기술에 Lock In 되어 쉽게 변경하거나 확장하지 못한다는 단점이 있다
최근에는 이러한 분위기를 바꿔 하나의 벤더에 의존하거나 직접 구축할 필요가 적어지는데 cloud 환경 하에서 사용되는 오픈소스 또는 오픈소스를 기반으로 한 상용제품들이 이전의 유명 벤더의 제품군만큼이나 품질이 높아지고 다양한 기능을 지원하면서 서로 다른 오픈 소스제품 간에도 충분한 호환성을 제공하기 때문
레이어 별로 다른 오픈 소스를 사용
- 애플리케이션 개발 : Spring, Jenkins, sonarqube
  오케스트레이션 : 쿠버네티스
  런타임 : 도커
  프로비저닝 : 테라폼
  IaaS : AWS의 ES2

🔸 MSA 구성요소 및 MSA 패턴

📌 인프라 구성요소

Public Cloud, Bear Metal, Private Cloud 환경
- 아키텍트가 할 일은 기존의 물리적인 메탈 장비를 구매해서 구축하느냐 아니면 가상화 환경을 선택해서 이용하느냐 그리고 가상화 환경을 사용한다면 Cloud 사업자가 서비스로 제공하는 퍼블릭 IaaS, PaaS를 선택할 지 또는 직접 구매하거나 기존에 보유한 베어 메타 서버에 Private PaaS를 구축할 지를 고민
VM과 컨테이너
- VM은 하이퍼바이저라는 소프트웨어를 이용해 하나의 시스템에서 여러 개의 운영체제를 사용하는 기술인 반면 컨테이너는 하이퍼바이저 없이 컨테이너 엔진을 사용해 가상의 격리된 공간을 생성
- 하이퍼바이저는 게스트 운영체제의 명령을 호스트 운영체제의 명령으로 바꾸기 위한 오버헤드가 발생
- 차이점은 게스트 OS의 유무인데 게스트 OS를 사용하는 가상머신에서는 운영체제 패치 설치나 관련 라이브러리 설치 같은 오버헤드가 지속적으로 발생하기 때문에 Micro Service 같은 작은 서비스를 패키지하고 배포하기에는 컨테이너 환경이 더 적합
- 가장 대표적인 컨테이너 기술로는 라이브러리나 실행파일을 여러 개의 레이어 이미지로 추가하거나 변경할 수 있는 도커가 가장 유명하고 가장 많이 사용됨
- 도커 컨테이너는 레이어 단위의 이미지를 포개는 방식으로 구성되며 밑에서 부터 애플리케이션 구동을 위한 기반 이미지, 운영체제, 런타임, 애플리케이션이 이미지로 정의
- 도커 컨테이너의 이점
  - 이식성 : 어떠한 호스트 커널이나 플랫폼 버전에 상관없이 도커만 실행할 수 있으면 사용 가능하며 동일하게 동작
  - 신속성 : 크기가 작고 가볍기 때문에 빠르게 배포 가능하며 문제 발생 시 수정할 필요 없이 새로 기동하면 됨
  - 재사용성 : 동일한 환경을 재사용해서 쉽게 설정 가능하기 때문에 개발, 테스트, 스테이징, 프로덕트 환경을 동일한 환경으로 구축하기가 쉬움
컨테이너 오케스트레이션
- 컨테이너를 관리하기 위한 기술
- 컨테이너가 많아지면 그에 따라 컨테이너의 자동 배치 및 복제, 장애 복구, 확장 및 축소, 컨테이너 간 통신, 로드 밸런싱 등의 컨테이너 관리를 위한 기능이 필요한데 이러한 기술을 컨테이너 오케스트레이션이라 함
- 컨테이너 오케스트레이션 도구로는 Docker Swarm, Apache Mesos 등이 있으며 최근에는 구글이 자사의 도커 컨테이너 관리 노하우를 CNCF 재단에 제공해서 공개한 Kubernetes(k8s)가 많이 사용됨
- 쿠버네티스나 AWS같은 플랫폼 사업자에게 제공하는 대부분의 PaaS UI는 시각적인 대시보드를 제공하는데 이곳에서 컨테이너 배포 단위에 해당하는 Pod, Deployment, ReplicaSet 등의 정보를 확인할 수 있음
- 쿠버네티스가 제공해주는 기능
  - 자동화된 자원 배정: 각 컨테이너가 필요로 하는 CPU 와 메모리를 쿠버네티스에 요청하면 컨테이너를 노드에 맞춰 자동으로 배치
  - 셀프 치유: 컨테이너의 이상 유무를 점검해서 실패한 경우 자동으로 교체하고 재스케줄링
  - 수평 확장: CPU 및 메모리 사용량이 일정량을 초과하면 자동으로 확장
- 쿠버네티스는 애플리케이션으로 구현 가능한 일부 Micro Service 운영/관리 패턴을 자체적으로 내장하고 있기 때문에 최근에는 AWS, Azure, Google Cloud 등 자체적인 컨테이너 기반의 PaaS 서비스를 제공하는 CSP 사업자들도 별도로 쿠버네티스 기반의 컨테이너 서비스를 제공
그 밖의 다양한 Cloud 인프라 서비스
- 애플리케이션 형태를 MSA 가 아닌 Monolithic 시스템으로 구성하기 위해서는 가상 머신 Cloud 제품군인 AWS의 EC2, Azure VM 을 사용할 수도 있고 MSA 시스템으로 가더라도 AWS의 Elastic Beanstalk, Elastic Container Service, Azure 의 Web App,Google의 App Engine 등의 PaaS를 고려할 수 있음
서비스 유형별 대표적인 Cloud 서비스
- IaaS
- CaaS
- PaaS

📌 플랫폼 패턴

개발 지원환경 : 데브옵스 환경
- Micro Service를 빌드하고 테스트한 뒤 배포할 수 있게 도와주는 개발 지원 환경
- 개발 및 운영을 병행할 수 있는 조직 또는 그 문화를 일컫는 용어
- 개발과 운영을 병행 가능하게끔 높은 품질로 소프트웨어를 빠르게 개발하도록 지원하는 빌드, 테스트, 배포를 위한 자동화 환경
- 자동화된 빌드나 배포 작업을 보통 CI/CD라고 하며 여기서 CI는 지속적인 통합(Continuous Integration)을 가리키는데 원래 지속적 통합은 애자일 방법 론 중 켄트 백이 만든 XP(eXtreame Programming)의 주요 Practice로 시작되었으며 오랜 시간이 걸리는 빌드를 자동화해서 개발 생산성이나 소스 코드 품질이 높아진다는 경험에서 출발
- 수동 빌드 및 배포 과정
  
  개발팀에서 소스코드를 작성하거나 수정해서 소스코드 저장소(형상관리)에 push를 하면 형상관리도구 CI/CD(대표적으로 Jenkins) 도구에 pull을 하도록 해서 자동으로 통합하고 테스트하고 리포트로 남기고(CI) 실행환경에 자동으로 배포(CD, 개발환경, 테스트 환경, 스테이징 환경, 운영환경 모두 포함)
- 빌드/배포 파이프라인은 통합 및 배포까지 이어지는 일련의 프로세스를 하나로 연계해서 자동화하고 시각화된 절차로 구축하는 것인데 어떤 단계를 거치고 어떤 도구로 그 단계를 구성할 지를 결정해야 함
  - 레포지토리 -> 빌드 및 유닛 테스트 -> 정적 분석 -> 통합테스트 -> 배포
API Gateway 패턴
- 여러 클라이언트가 여러 개의 서버 서비스를 각각 호출하게 되면 매우 복잡한 호출 관계가 만들어질 것인데 이러한 복잡성을 통제하기 위한 방법이 필요
- 그 중에 하나가 API Gateway
- 단일 진입점을 만드는 방식
CQRS 패턴
- 읽기와 쓰기 작업을 분리

3️⃣ Containers

4️⃣ Continuous Delivery(CI/CD)

JIWON

이전 포스트