[PART4] 클라우드/데브옵스 - TERMS 09

[ TERMS 09 ]  마이크로서비스

마이크로 서비스를 설명하는 이미지(출처 : https://www.simform.com/blog/how-does-microservices-architecture-work/)

1. 마이크로서비스(Microservice)의 정의

 앱은 수많은 기능들의 집합이다. 이 기능들을 작은 서비스 단위로 분리한 것이 마이크로서비스이다. 마이크로서비스는 독립적으로 배치될 수 있고 단독 실행이 가능하다. 마이크로서비스마다 개발 언어가 달라도 상관없고, 데이터 베이스도 각각 자체적으로 보유하고 관리한다. 각 마이크로서비스는 REST API같은 인터페이스로 느슨하게 결합된다. 마이크로서비스 덕분에 앱의 배포 주기가 빨라졌다.

 

2. 마이크로서비스는 어디서 접하게 될까?

 배달의 민족, 넷플릭스 등의 IT 서비스를 이용하고 있다면 이미 마이크로 서비스를 접하고 있는 것이다. 이 IT 서비스는 서버가 다운되어도 몇 시간씩 전체 서비스를 이용하지 못하는 문제가 발생하지 않는다. 마이크로 서비스 아키텍처는 특정 마이크로서비스가 중단되어도 전체가 중단되지 않게 설계되어 있다.

 

3. 마이크로서비스 알아보기

>  등장 배경

 인터넷 기반의 서비스를 제공하는 회사들은 비즈니스 요구에 신속하게 부응해야 하는 과제를 항시 갖고 있었다. 만약 신속한 변화를 추구하지 못한다면 기존 고객들은 다른 회사들로 넘어가기 때문이다. 기존의 소프트웨어는 모놀리식으로 설계 및 개발 되었다. 모놀리식 아키텍처는 개발이 간단하고 앱의 변경 및 테스트, 배포, 확장이 쉽다는 장점이 존재하지만 서비스가 다양해질수록 장점이 단점으로 변해간다.

 아마존은 이러한 문제에 대하여 일찍이 인지하고 클라우드 플랫폼을 해답으로 잡아 필수적인 기능을 다음과 같이 정리했다.

• 앱은 서로 다른 서비스로 분할된다.
• 각 서비스는 웹 사이트의 일부를 제공한다. 예를 들어 검색을 위한 서비스가 있고, 추천을 위한 서비스가 있다. 결국 개별 서비스는 UI에서 함께 제공된다.
• 항상 하나의 팀이 하나의 서비스에 대한 책임을 갖는다. 팀은 서비스 운영뿐만 아니라 새로운 서비스 개발도 담당한다. "만들고 운영하라!"
• 클라우드 플랫폼, 예를 들어 가상 머신들은 모든 서비스에 대한 공통 기반으로 작동한다. 이외에 다른 표준은 없다. 이에 대한 결과로, 각 팀은 기술의 선택이 매우 자유롭다.

 

>  개념

모노폴리와 마이크로서비스를 비교하는 이미지 (출처 : https://icepanel.medium.com/monolithic-vs-microservices-architectures-e71c75b252d1)

 

마이크로서비스 아키텍쳐의 개념은 모놀리식과 비교해서 보면 이해하기 쉽다. 모놀리식은 N-tier 구조의 일체식으로 앱을 설계한다. 일반적으로 사용되는 구조로 클라이언트, 서버, 데이터베이스가 일체식으로 설계된 것이다. 하나의 통합된 패키지로 개발, 테스트, 배포되는 방식이다 보니 표준화된 관리에 이점이 있지만 작은 변화에도 새로운 버전을 전체 빌드해야 하며, 필요한 특정 기능만 확장(Scale-out)할 수 없고, 전체 앱을 동시에 확장해야 한다. 또한 어느 부분에 문제가 발생하면 전체 시스템의 서비스가 중단되는 문제도 존재한다.

모노폴리 구조를 설명하는 이미지(출처 : https://www.geeksforgeeks.org/what-is-a-modular-monolith/)

 

 마이크로서비스 아키텍처는 전체 앱을 작은  서비스 단위(마이크로서비스)로 분할한다. 분할된 서비스는 확고한 모듈 경계를 가지며, 특정 기능별로 독립적인 배포 및 확장이 가능하고, 서로 다른 언어로 개발되는 것도 허용된다.

 마이크로서비스 팀이 단기간에 제품을 개발하고 피드백을 받기 위해서는 개발 지원 환경의 자동화(빌드, 테스트, 배포, 모니터링 등)가 반드시 갖춰져야 한다. 인프라의 자동화로 개발과 운영을 동시에 수행하므로 마이크로서비스 아키텍처와 데브옵스 개발 환경은 바늘과 실의 관계와 같다.

 마틴 파울러는 마이크로서비스에 대해 "여러 개의 작은 서비스 집합으로 개발하는 접근 방법이다. 각 서비스는 개별 프로세스에서 실행되고, HTTP 자원 API 같은 가벼운 수단을 사용하여 통신한다. 서비스는 비즈니스 기능 단위로 구성되고 자동화된 배포 방식을 이용하여 독립적으로 배포된다. 서비스들에 대한 중앙 집중적인 관리는 최소화하고 각 서비스는 서로 다른 언어와 데이터, 저장 기술을 사용할 수 있다."라고 정의했다.

 

>  특징

GOTO 2014에서 마틴 파울러는 마이크로서비스의 특징을 다음과 같이 정리했다.

• 서비스를 통한 컴포넌트화(Componentization via services) : 마치 레고 조각처럼 교체 가능한 부품처럼 서비스를 모듈화한다. 부품처럼 존재하는 서비스를 REST API 같은 인터페이스로 연결해서 전체 애플리케이션을 완성하는 것이다.
• 비즈니스 역량 기반 팀 (Organized around business capabilities)：역할 또는 기술별로 팀이 존재(개발팀, 운영팀 등)하는 것이 아니라 업무 중심으로 다양한 역량을 가진 사람(기획자, 디자이너, 프런트엔드 개발자, 백엔드 개발자, 설계자, 테스터 등)들이 팀을 이루어 서비스를 만드는 것을 의미한다. 빠른 커뮤니케이션이 강점이며, 다기능 팀으로서 서비스를 만드는 모든 기술을 갖고 있다.
• 프로젝트가 아니라 제품(Products not Projects)：프로젝트에서는 개발과 운영이 별개의 개념이다. 필요한 기술의 인력들이  모여 프로젝트를 통해 개발을 하고, 이를 운영 조직에 넘긴다. 반면 마이크로서비스 팀의 개발은 운영을 포함한 소프트웨어의 전체 라이프 사이클을 책임져야 합니다. 따라서 빨리 개발한 뒤에 반응을 보고 개선하는 애자일 개발 방식으로 진행한다. 
• 똑똑한 끝 지점 단순한 파이프(Smart endpoints and dumb pipes)： 각각의 서비스는 응집도 높게 존재하고, 서비스 간 연결(결합도)은 느슨해야 한다는 것을 의미한다. 서비스 도메인 로직은 그 자체로 똑똑한 기능 처리를 하고, 서비스 간 연결은 REST API와 같은 인터페이스로 단순하게 한다.
• 분권 데이터 관리 (Decentralized Data Management)： 마이크로서비스의 데이터 관리는 서비스별로 데이터베이스를 갖도록 설계한다. 따라서 서비스가 독립적으로 존재합니다. 하지만 다른 서비스의 저장소를 쿼리문으로 직접 호출할 수 없고 API를 통해서만 접근하기 때문에 데이터 일관성 문제가 발생합니다. 그래서 두 서비스의 데이터가 일시적으로 불일치하더라도 ‘결과적 일관성 (Eventual Consistency)’을 갖도록 한다.
• 분권 거버넌스(Decentralized Governance)： 마이크로서비스 팀으로 구성된 조직은 중앙에 강력한 표준이나 절차의 준수를 강요하지 않는다. 각 마이크로서비스 팀은 빠르게 제품을 만드는 것을 목적으로 스스로 효율적인 방법론과 도구, 기술을 찾아 적용합니다. 따라서 서비스별로 목적과 용도에 맞는 다양한 기술과 언어의 활용이 가능하다.
• 인프라 자동화(Infrastructure Automation)： 마이크로서비스가 바늘이라면 데브옵스가• 실처럼 따라오는 이유이다. 클라우드 인프라 내에서 이루어지는 코드형 인프라(IaC), 지속적인 통합(CI), 지속적인 배포(CD) 등 데브옵스 환경은 팀에게 인프라 자동화를 제공하여 개발과 운영을 빠르고 손쉽게 합니다.
• 실패를 위한 설계(Design for failure)： 마이크로서비스는 독립적인 서비스로 존재하기 때문에 해당 서비스의 중단(실패)이 전체 앱의 중단으로 이어지지 않는다. 각각의 서비스를 모니터링하고 있다가 하나의 서비스가 다운되면 이를 호출하는 서비스의 연계를 차단한다. 이러한 설계는 서비스가 긴급 장애 상황에 빠르고 유연하게 대응할 수 있도록 한다.
• 진화하는 디자인(Evolutionaiy Design)： 마이크로서비스는 호환성을 중시하는 모듈 방식 설계로서의 이점을 가지고 있다. 이러한 특징은 기존 모놀리식 시스템에서 마이크로서비스 시스템으로의 진화의 가능성을 제공한다. 또한 마이크로서비스 시스템 내에서 각 마이크로서비스가 비즈니스 요구에 맞추어 변화를 가능하게 한다.

 

>  장점

• 인프라 자동화 덕분에 크고 복잡한 앱을 지속적으로 통합/배포(CI/CD) 할 수 있다.
• 서비스를 통한 컴포넌트화, 비즈니스 역량 기반 팀, 분권 거버넌스 덕분에 서비스 규모가 작아 관리하기 쉽다. 
• 서비스를 통한 컴포넌트화, 분권 데이터 관리 덕분에 서비스를 독립적으로 배포, 확장할 수 있습니다.
• 비즈니스 역량 기반 팀, 분권 거버넌스 덕분에 팀이 자율적으로 움직입니다.
• 똑똑한 끝 지점 단순한 파이프, 분권 데이터 관리, 실패를 위한 설계 덕분에 결함 격리가 잘된다.
• 비즈니스 역량 기반 팀, 프로젝트가아니라 제품, 진화하는 디자인 덕분에 새로운 기술을 실험하고 도입하기 쉽습니다.

 

>  단점

• 분산 시스템은 너무 복잡해서 개발, 테스트, 배포가 어렵습니다. 지속적 통합 및 배포가 마이크로서비스의 큰 강점인데 역설적이게도 개발, 테스트 배포가 어렵다. 서비스는 작은 단위로 독립적으로 존재하고 있기 때문에 지속적 통합 및 배포에 유리하지만, 전체 시스템 관점에서는 서비스가 많아질수록 복잡도가 증가하기 때문이다.
• 여러 서비스에 걸친 기능을 배포할 때 잘 조정해야 한다. 데이터베이스도 서비스 단위로 분할되어 있기 때문에 협력하고 있는 서비스들 사이에서 일어 나는 트랜잭션의 일관성 문제가 발생할 수 있습니다.
• 딱 맞는 서비스를 찾기가 쉽지 않다. 설계 시 서비스를 어떤 기준으로 분할할 것인지는 매우 중요한 문제이다. 비즈니스 특성에 맞지 않는 분할은 시스템 전체를 다시 설계해야 한다.
• 마이크로서비스 아키텍처 도입 시점을 결정하기 어렵다. 상황에 따라 모놀리식이 더 효과적일 수 있다.

 

4. 마이크로서비스를 사용하는 이유

 IT 서비스 회사의 경우 전체 서비스가 중단되면 그 시간에 비례해 막대한 손실을 입는다. 따라서 어떠한 경우에도 서비스가 중단되지 않기 위해서 마이크로서비스를 적용하고 있다.

 과거 넷플릭스의 데이터 센터에서 서버 다운 사고가 있었다. 해당 사건 이후 마이크로서비스 운영 방식을 적용했다. 그 후로 특정 서비스가 중단되더라도 전체 서비스의 중단으로 이어지지 않고 빠른 복구도 가능해졌다.

 페이스북에서 개발한 다크 론칭(Dark Launching)은 전체 서비스를 릴리스하기 전에 선택된 특정 사용자에게 먼저 새로운 기능을 배포하여 점진적으로 서비스를 배포하는 프로세스이다. 페이스북은 여러 배포 파이프라인을 만들고 특정 파이프라인에만 새로운 기능을 배포하여 지속적으로 모니터링한 뒤 사용자의 피드백을 수집하고 버그를 제거하여 안정화되면 그 외 파이프라인을 통해 다른 사용자들에게 점진적으로 배포한다. 이는 마이크로서비스의 성공 사례라 볼 수 있다.

 

5. 마이크로서비스 더 알아보기

>  함께 알아 두면 좋은 용어

• 클라우드
• DDD (Domain-Driven Design)
• 데브옵스
• 도커
• ELK
• 쿠버네티스
• Polyglot
• SAGA pattern

>  혼동하기 쉬운 용어

• CBD
• SOA