[MicroService] 비지니스 민첩성 2장

◆ Micro Service

▶ 모노리스와 Micro Service

● 모노리스

    →  모노리스는 하나의 단위로 개발되는 일체식 애플리케이션

    →  보통 3티어라 불리는 사용자 인터페이스와 데이터베이스 그리고 서버 쪽 애플리케이션의 3개 부분으로 구성

    →  서버 측 애플리케이션이 일체 즉 논리적인 단일체로서 아무리 작은 변화에도 새로운 버전으로 전체를 빌드해서 배포해야 하고 일체식 애플리케이션은 단일 프로세스에서 실행되기 때문에 확장이 필요할 경우 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장해야 하는데 보통 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해 수평으로 확장

    →  이런 상황에서 변경이 발생하면 모노리스 시스템의 단점이 극대화되는데 여러 개의 모노리스가 수평으로 확장된 상태이므로 여러 개의 모노리스 시스템 모두를 전부 다시 빌드하고 배포해야 하고 확장 시 애플리케이션이 병렬로 확장되어 사용량 증가에 대응할 수 있지만 데이터베이스는 통합되어 하나이므로 탄력적으로 대응할 수 없기 때문에 사전에 성능을 감당하기 위해 스케일 업을 통해 용량을 증설해야 함

● Micro Service

    → Micro Service는 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩되는데 여러 서비스 인스턴스가 모여 하나의 비즈니스 애플리케이션을 구성하고 각기 저장소가 다르므로 업무 단위로 모듈 경계를 명확하게 구분

    → 확장 시에는 특정 기능별로 독립적으로 확장할 수 있고 특정 서비스를 변경할 필요가 있다면 해당 서비스만 빌드해서 배포하면 됨

    → 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있음

 

▶ SOA 와 Micro Service

● 소프트웨어 공학에서 말하는 모듈화(modularity) 개념의 발전 흐름을 보면 단순히 기능을 하향식 분해해서 설계해 나가는 구조적(structured) 방법론부터 시작해 객체 단위로 모듈화하기 위한 객체지향(object-oriented) 방법론, 모듈화의 단위가 기능별로 재사용할 수 있는 좀 더 큰 컴포넌트가 되는 CBD(Component Based Development), 그리고 컴포넌트를 모아 비즈니스적으로 의미있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)로 이어지는 발전 과정을 거침

● CBD와 SOA도 넓게 보면 단위 컴포넌트나 서비스를 구성해서 시스템을 만드는 개념이고 Micro Service 시스템의 구조와 매우 유사

● 보통 Micro Service 기반으로 시스템을 개발하는 아키텍처 및 개발 방식을 Micro Service 아키텍처(MSA; Microservice Architecture) 함

● 넓게 보면 여러 개의 응집된 비즈니스 서비스의 집합으로 시스템을 개발한다는 점에서 SOA와 MSA는 개념적으로는 큰 차이가 없지만 SOA는 구체적이지 않고 이론적이며 실제 비즈니스 성공 사례가 많지 않았지만 MSA는 클라우드 인프라 기술의 발전과 접목되어 아마존 과 넷플릭스에 의해 구체화되고 비즈니스 성공 사례로 널리 공유된 바 있는데 이상적이었지만 성공을 증명하지 못했던 SOA가 클라우드 인프라의 등장으로 하드웨어를 유연하게 다룰 수 있게 되면서 비로소 실현되어 성공적으로 증명된 시스템 구조가 MSA

●  아마존과 넷플릭스로 일컬어지는 인터넷 유니콘의 성공 과정을 계속 지켜본 마틴 파울러는 2014년에 이러한 여러 성공 사례의 특징을 뽑아 Micro Service를 다음과 같이 정의

    → Micro Service는 여러 개의 작은 서비스 집합으로 개발하는 접근 방법

    → 각 서비스는 개별 프로세스에서 실행되고 HTTP 자원 API 같은 가벼운 수단을 사용해서 통신

    → 서비스는 비즈니스 기능 단위로 구성되고 자동화된 배포 방식을 이용하여 독립적으로 배포

    → 서비스에 대한 중앙 집중적인 관리는 최소화하고 각 서비스는 서로 다른 언어와 데이터, 저장 기술을 사용할 수 있음

● 마틴 파울러가 정의한 Micro Service 개념을 표현한 개념도

    → 각 서비스와 저장소는 다른 서비스 및 저장소와 격리돼 있으며, API를 통해서만 느슨하게 연계되기 때문에 독립적으로 확장 가능하고 하나의 서비스만 독립적으로 배포 가능하고 다른 서비스와 연계된 API에 영향을 주지 않는다면 내부의 언어나 저장소는 자율적으로 선택할 수 있음

    → 한 서비스에는 자바와 오라클을 다른 서비스에는 Node.js와 마리아DB(MariaDB)를 선택한 것을 볼 수 있음

● 이처럼 특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식 을 가리켜 폴리글랏(Polyglot)하다 라고 표현

● 클라우드 등의 가상 인프라가 지닌 유연성이 이를 가능하도록 지원

● 폴리글랏 저장소 같은 특성을 통해 CBD/SOA가 추구했지만 미흡했던 모듈화를 비로소 실현할 수 있었던 MSA와 CBD/SOA와의 차이를 발견할 수 있음

● CBD/SOA의 접근법에서는 애플리케이션은 모듈 별로 분리했으나 데이터 저장소까지는 분리하지 못함(여러 애플리케이션이 하나의 저장소를 통합해서 공유)

● 데이터의 강한 결합으로 애플리케이션도 독립적으로 사용하기가 힘들었지만 MSA에서는 SOA에는 없었던 다음의 두 가지 개념으로 모듈화 방식을 강화했고 이를 진정으로 실현

    → 서비스 별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화하는데 다른 서비스의 저장소에 접근하는 수단은 API밖에 없음

    → REST API 같은 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있음

---

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

● 콘웨이 법칙(Conway’s law)은 멜빈 콘웨이(Melvin E. Conway)가 정의한 조직 과 조직이 개발한 소프트웨어의 관계를 정의한 법칙으로 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영하는 것

● 예전의 일하는 방식을 보면 하나의 애플리케이션을 만드는 데 UI팀, 서버 개발팀, DB팀과 같은 기술 별로 팀이 나눠져 있고 하나의 애플리케이션을 만드는 데는 세 팀 간의 의사 소통이 필요하기 때문에 시스템도 이러한 의사소통 구조를 그대로 반영하고 이러한 팀 구조에서는 팀 간의 의사결정도 느리고 의사 소통도 어려움

● Micro Service를 만드는 팀은 업무 기능 중심의 팀 이어야 하는데 업무 기능 중심 팀은 역할 또는 기술 별로 팀이 분리되는 것이 아니라 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것을 의미

● 업무 기능 중심 팀은 다양한 역할(기획자, 디자이너, Front End 개발자, 벡엔 드 개발자. 설계자, 테스터 등)로 구성되고, 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모 든 단계의 역할을 모두 갖추고 있음

● 이 팀은 같은 공간, 같은 시간을 공유하기 때문에 의사 소통도 원활하고 의사 결정도 빠르게 진행될 수 있음

● 이 팀을 여러 기능들이 모여 있다는 의미에서 다기능 팀(Cross-Functional Team)이라고도 함

● 이 팀은 자율적으로 담당 비즈니스에 관련된 서비스를 만들뿐 만 아니라 개발 이후에 운영할 책임까지 짐

● 아마존에서는 이런 팀을 two pizza team 이라고 표현하는데 이는 피자 두 판으로 서로 빈번히 의사소통하며 함께 식사할 수 있는 정도의 팀원 수를 의미하며 한 팀에 다양한 역할을 수행하는 사람들이 모여 있으며 개발과 운영을 동시에 수행하는 팀

● 이러한 팀은 Micro Service를 만드는 데 필요한 기능과 기술을 팀 내부에 모두 가지고 있으므로 다른 Micro Service 팀과는 협력할 일이 적을 수밖에 없기 때문에 콘웨이 법칙에 의해  이 팀이 만든 Micro Service도 다른 팀이 만든 Micro Service와는 느슨하게 연계

---

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

● 아마존에서는 다기능 팀이 개발과 운영을 책임진다고 했는데 이러한 조직문화를 가리켜 you built it, you run it 이라는 모토로 표현하는데 우리가 만들고 우리가 직접 운영한다 라는 의미

● Micro Service를 만드는 조직은 중앙의 강력한 거버넌스를 추구하지 않기 때문에 Micro Service팀으로 구성된 조직은 중앙의 강력한 표준이나 절차 준수를 강요하지 않음

● 각 Micro Service팀은 빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용

● 현실 세계에 비유하자면 작은 정부나 지방 자치 제도와 유사

● 각 Micro Service팀이 자신의 서비스 성격에 맞는 최적의 언어와 저장소를 자율적으로 선택

● 상품팀은 상품 검색 서비스를 위해 빠른 검색에 특화된 NoSQL인 몽고디비(MongoDB)와 Node.js를 선택했고 계약팀은 계약 서비스를 위해 자바 언어와 오라클, 레디스(Redis)를 선택하는데 각 서비스 팀이 팀에 맞는 개발 언어 및 저장소를 선택하는 것을 각각 폴리글랏 프로그래밍, 폴리글랏 저장소라고 함

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

● 기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였기 때문에 필요한 기술을 사용하는 인력들이 한시적으로 모여 장기간의 프로젝트를 통해 개발을 완료하고 나면 이를 운영 조직에 넘기는 방식으로 진행되어서 개발 조직 과 운영 조직이 분리돼 있음

● 초기에 모든 일정을 계획했는데 요구사항 정의를 통해 개발할 기능을 나열하고 이에 대한 설계를 진행하며 설계가 완료돼야 개발이 진행되고 각 단계는 완료 데드라인이 있어 그 일정을 완료함으로써 최종 기능을 제공하기 때문에 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못함

● Micro Service 팀의 개발은 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발뿐만 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 하기 때문에 소프트웨어를 완성해야 할 기능들의 집합으로 보는 것이 아니라 비즈니스를 제공하는 제품(product)으로 바라보고 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어를 개발

● 소프트웨어를 개발하는 방식 측면에서 프로젝트 형태의 폭포수 모델 또는 빅뱅 방식 으로 진행하는 것이 아니라 점진 반복적인 모델 제품 중심의 애자일(agile) 개발 방식을 채용

● 이 같은 방식은 약 2〜3주 단위의 스프린트(Sprint)를 통해 소프트웨어를 개발 및 배포해서 바로 피드백을 받아 소프트웨어에 반영할 수 있게 해주기 때문에 소프트웨어를 한시적 프로젝트를 통해 고객의 고정된 요건을 받아 기능이 만족되면 제공 및 전달하는 개념으로 보지 않고 요건의 변화에 따라 지속적으로 개선되고 발전시킬 제품으로 바라봄

●  Micro Service는 계속 피드백을 받아 지속적으로 변화, 개선되고 향상되는 존재

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

● Micro Service는 독립적으로 배포

● 모노리스처럼 한 덩어리로 배포한다면 수동으로 배포하는 방식도 크게 문제가 없겠지만 Micro Service처럼 여러 개로 쪼개진 상태에서는 수동으로 배포하는 방식은 바람직하지 않기 때문에 여러 개의 Micro Service를 빠르게 배포하기 위한 방법이 필

● Micro Service가 화려하게 등장한 이유는 클라우드라는 가상 인프라 발전에 기인

● 전체 소프트웨어를 구현하는 과정은 개발 환경을 준비하는 과정, 실제로 소프트웨어를 개발하는 과정, 개발 완료된 소프트웨어를 빌드, 테스트, 배포하는 개발 지원 과정으로 구분

● 첫 단계인 개발 환경 준비 과정에 개발 환경으로 클라우드 인프라를 활용하면 쉽고 빠르게 개발 환경을 준비할 수 있어서 팀의 개발 속도가 높아지는데 개발 지원 과정의 속도를 높이는 가장 좋은 방법은 자동화

● 개발 지원 환경을 자동화하는 데는 소스 코드를 빌드하는 도구 와 빌드와 동시에 테스트하는 도구, 가상화된 인프라에 배포하는 도구가 모두 필요

● Micro Service팀이 단기간에 제품을 빨리 개발하고 피드백을 받기 위해서는 이러한 개발 지원 환경의 자동화가 반드시 갖춰져야 함

● 이 같은 환경은 개발과 운영을 동시에 수행하는 데브옵스(DevOps)를 궁극적으로 가능하게 하므로 데브옵스 개발 환경이라 속칭하기도 하며 이러한 개발 환경, 개발 지원 환경을 자동화하는 것을 모두 통틀어 인프라 자동화라고 하기도 하는데 인프라 자동화는 Micro Service 개발 과정의 필수 조건

● 배포 파이프라인의 자동화

    → 빌드/배포 파이프라인은 일반적으로 소스 코드 빌드 - 개발 환경 배포 - 스테이징(Staging) 환경 배포 - 운영 환경 배포로 구성

    → 빌드/배포 파이프라인 프로세스는 도구를 통해 자동화해야 하는데 최근에는 배포 환경이 Micro Service 개수에 따라 급격하게 늘어나기 때문에 이를 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 빙식인 Infrastructure as Code가 각광받고 있음

    → Infrastructure as Code란 코드를 이용해 인프라 구성부터 애플리케이션 빌드, 배포를 정의하는 것을 의미하는데 이렇게 되면 수많은 하드웨어 리소스 설정을 동일하게 통제할 수 있으며 상황에 따른 검증되고 적절한 설정을 쉽게 복제하고 누구한테나 공유할 수 있게 돼서 인프라를 매우 효율적으로 관리할 수 있음

---

▶ 저장소의 변화: 통합 저장소가 아닌 분권 데이터 관리

● 모노리스 시스템을 살펴보면 단일 통합 데이터베이스를 사용

● 단일 데이터베이스를 유지하는 방식은 과거 스토리지 가격 및 네트워크 속도에 따른 데이터의 안정성과 효율성을 추구한 결과로 데이터를 잘 정리하는 정규화가 반드시 추구해야 할 가치였지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커져서 데이터를 억지로 꾸깃꾸깃 뭉쳐서 작은 공간에 넣을 필요가 없음

● Micro Service는 폴리글랏 저장소(polyglot persistence) 접근법을 선택하며 서비스 별로 데이터베이스를 갖도록 설계하는데 각 저장소가 서비스 별로 분산돼 있어야 하며 다른 서비스의 저장소를 직접 호출할 수가 없고 API를 통해서만 접근해야 한다는 의미

● 이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요한데 여기서 반드시 등장하는 문제가 있는데 바로 각 Micro Service의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제

● 데이터 일관성 처리를 위해서는 보통 2단계 커밋(two-phase commit) 같은 분산 트랜잭션 기법을 사용하는데 각각 다른 서비스를 하나의 트랜잭션으로 묶다 보면 각 서비스의 독립성도 침해되고 NoSQL 저장소처럼 2단계 커밋을 지원하지 않는 경우도 있기 때문에 Micro Service는 데이터 일관성 문제를 해결하기 위해 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조하는데 이를 가리켜 결과적 일관성(Eventual Consistency)이라는 개념으로 표현하기도 하는데 간단 히 말해 두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태지만 결국에는 두 데이터가 같아진다는 개념

● 여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 각각 수행하고 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성을 맞추는 개념

● 주문 서비스와 배송 서비스가 있고 각 저장소가 분리돼 있음

● 주문이 발생하면 반드시 배송 처리가 돼야 하는 비즈니스가 있다고 생각해 보면 두 업무를 2단계 커밋 과 같은 분산 트랜잭션 기법을 사용해 하나로 묶으면 배송 서비스가 실패했을 때 트랜잭션에 포함되는 주문 서비스도 함께 롤백(rollback) 처리해서 데이터의 일관성을 맞출 수 있을 것이지만 하나의 데이터 저장소가 2단계 커밋을 지원하지 않는 저장소라면 이렇게 하기가 불가능할 것

● 분산 트랜잭션으로 묶는다면 두 서비스가 강하게 결합돼 있어 서비스를 분리한 효과를 누리기 힘들 것

●  Micro Service가 추구하는 다른 방법은 각 트랜잭션을 분리하고 큐(queue) 메커니즘을 이용해 보상 트랜잭션을 활용하는 방법

    → 주문 서비스가 주문 처리 트랜잭션을 수행

        ≫ 동시에 주문 이벤트를 발행

        ≫ 주문 이벤트가 메시지 큐로 전송

        ≫ 배송 서비스가 주문 이벤트를 인식

    → 배송 서비스가 주문 처리에 맞는 배송 처리 트랜잭션을 수행(비즈니스 일관성 만족)

    → 배송 처리 트랜잭션 중 오류로 트랜잭션을 실패

        ≫ 배송 처리 실패 이벤트를 발행

        ≫ 배송 처리 실패 이벤트가 메시지 큐로 전송

        ≫ 주문 서비스가 배송 처리 실패 이벤트를 인식

    → 주문 서비스는 주문 취소(보상 트랜잭션)를 수행 (비즈니스 일관성 만족)

 

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

● 아마존의 부사장인 버너 보겔스(Werner Vogels)는 소프트웨어는 모두 실패한다 라고 말한 바 있는데 시스템은 언제든 실패할 수 있으며 실패해서 더는 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 한다는 의미로 이러한 성격을 내결함성(fault tolerance)이라 함

● 예전의 시스템 아키텍처는 무결함이나 실패 무결성을 추구했는데 시스템이 다운되지 않고 중단되지 않기 위해서는 완벽을 추구해야 하며 강건해야 했지만 버너 보겔스의 말처럼 어떤 시스템도 실패하지 않을 수 없는데 실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이라는 것인데 이를 위해서는 다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 함

● 이러한 예로 서킷 브레이커(circuit breaker) 패턴을 들 수 있는데 이 패턴은 회로 차단기처럼 각 서비스를 모니터링하고 있다가 한 서비스가 다운되거나 실패하면 이를 호출하는 서비스의 연계를 차단하고 적절하게 대응하는 것을 의미하는데 이러한 설계는 서비스가 긴급 장애 상황에 빠르고 유연하고 탄력 적으로 대응할 수 있게 함

● 넷플릭스에서는 카오스 몽키(chaos monkey)라는 장애를 일부러 발생시키는 도구를 만들어 이러한 탄력적인 아키텍처가 제대로 동작하는지 점검