마이크로서비스의 6가지 베스트 프랙티스
이 글은 제가 NIA [한국지능정보사회진흥원]의 < 디지털서비스 이슈리포트 > 2022년 8월호에 기고한 글입니다. 원본 글 '마이크로서비스의 6가지 베스트 프랙티스'을 이곳 브런치에서도 공유합니다.
1. 왜 마이크로서비스인가?
오늘날의 비즈니스 환경은 전무후무하게 경쟁적이다. 기업의 규모나 업종에 상관없이 디지털 전환의 시대에는 제품이나 서비스의 스피드, 품질, 판매 후 유지 보수 등 모든 면에서 우위를 유지하기 쉽지 않다. 신규 진입자가 시장에 진입하는 것이 그 어느 때보다 쉬워지고, 예전 버전에서 생성된 레거시 자산이 없다는 것이 오히려 경쟁구조에서 우위를 점할 수 있는 환경도 생겨났다.
어떤 산업에 속해 있든 모든 기업은 이상적인 고객 경험을 제공하기 위해 노력한다. 고객은 그 어느 때보다 요구사항을 복잡하게 요청하고 응답이 너무 느린 비즈니스는 쉽게 사용을 포기한다. 모든 기업과 조직은 디지털 혁신이 제공하는 여러 기회를 활용하여, 정의된 비즈니스 가치 단위를 신속하게 혁신하고 훨씬 더 큰 가치를 제공하기 위해 협력하는 소규모, 목표지향의 팀 프레임워크를 사용할 수 있다. 이런 조직을 구성할 수 있게 만들려면 IT가 비즈니스를 지원하는 방식을 변경해야 한다. 재사용 가능한 서비스를 통해 규모를 만들고 해당 서비스의 셀프서비스 소비를 가능하게 하는 것을 의미한다. 빠르고 쉽게 혁신하며, 경쟁이 발생하는 모든 곳에서 효율적으로 대처할 수 있는 비즈니스 능력은 오늘날 전략적 필수 요소이다. 이를 통해 끊임없이 변화하는 시장에서 성공하고 새로운 기술을 사용하여 새로운 상황에서 새로운 고객 경험을 창출할 수 있다.
마이크로서비스 아키텍처는 분리된 서비스를 통해 더 높은 유연성과 개발 용이성을 제공한다. 핵심 비즈니스 기능을 캡슐화하고 정의된 설계 원칙과 목표를 준수하는 마이크로서비스는 기업의 진정한 디지털 자산이고 경쟁력이다. 여러 상황에서 사용하도록 능동적으로 조정할 수 있기 때문에 비즈니스에 즉각적인 가치를 가져올 수 있다. 서비스 사용을 위한 컨텍스트는 비즈니스 프로세스 및 트랜잭션, 고객, 임직원 또는 파트너가 비즈니스를 중심으로 상호 작용하는 형태다.
마이크로서비스 아키텍처는 비즈니스 변경 사항을 민첩하게 처리할 수 있는 방식으로 오늘날 변화하는 비즈니스 요구에 일치한다. 마이크로서비스의 구성으로 비즈니스 프로세스 및 트랜잭션이 자동화된다. 프로세스가 변경되거나 새로운 프로세스가 도입되면 서비스를 새로운 구성으로 재배치하여 대응할 수 있다. 새로운 비즈니스 채널(예: API를 제품화하여 새로운 수익원을 창출하는 구글), 고객과의 새로운 디지털 참여(예: 우버와 구글맵을 통해 고객과 소통하는 스포티파이)와 같이 완전히 새로운 제품 및 서비스의 형태를 취할 수도 있다. 혁신은 이러한 민첩성의 모습을 하고 있다.
이번 글에서는 기존 디지털 자산을 새로운 비즈니스 기능으로 구성하여 혁신을 보여준 마이크로서비스의 디자인 패턴에 따른 6가지 모범사례를 소개하고자 한다.
2. 마이크로서비스의 6가지 베스트 프랙티스
1) 마이크로서비스의 컨테이너화
마이크로서비스의 컨테이너화는 가장 효율적인 모범사례다. 컨테이너를 사용하면 최소한의 프로그램 구성, 라이브러리 및 바이너리를 패키징 할 수 있다. 또한 컨테이너는 커널과 운영 체제를 공유하므로 개별 OS에 필요한 리소스의 필요성이 줄어든다.
컨테이너화가 제공할 수 있는 일반적인 이점은 다음과 같다.
최소한의 리소스로 프로세스 격리
더 작은 메모리 점유
공유 OS로 인해 높은 데이터 일관성
외부 환경의 급격한 변화가 컨테이너에 미치는 영향 없음
최적화된 비용 및 빠른 프로세스 반복
신속한 롤아웃 및 롤백
실제 예: 스포티파이(spotify.com)
스포티파이는 2014년부터 마이크로서비스를 컨테이너화하고 있으나, 2017년이 되어서야 자체 개발한 오케스트레이션 시스템인 헬리오스(Helios)가 200개의 엔지니어링 팀이 반복하는 프로세스 지원에 충분하지 않다는 것을 깨닫게 된다.
스포티파이가 쿠버네티스(Kubernetes)를 선택한 이유는 바로 이 헬리오스의 비효율성 때문이다. 핵심 기술 에서의 문제점을 철저히 조사한 후 환경 통합을 위해 쿠버네티스 API와 확장성 기능을 사용했다.1) 스포티파이는 2019년에 스테이트리스(Stateless) 서비스에 중점을 두고 초당 1천만 개의 요청을 처리하기 위해 150개 이상의 서비스를 쿠버네티스로 전환했다. (그림 1)2)
그림 1 터그보트(Tugboat)와 함께 쿠버네티스로 이전 (출처: 유튜브 채널-구글 클라우드 테크)2) 마이크로 프론트엔드(Micro Frontend)로 기본 UI 기능 향상
마이크로 프론트엔드 아키텍처는 모놀리딕(일체형) 프론트엔드를 더 작은 요소로 분해하는 설계 방법이다. 구조적으로는 마이크로서비스 아키텍처를 따르지만 개별 UI 요소 업그레이드를 가능하게 한다는 점이 다르다. 이 접근 방식을 사용하면 개별 구성요소를 변경하고 빠르게 테스트 및 배포할 수 있다.
또한 이 아키텍처는 네이티브 경험을 만드는 데도 도움이 된다. 예를 들어 API보다 유지 관리가 쉬운 통신을 위해 간단한 브라우저 이벤트를 사용할 수 있다. 마이크로 프론트엔드는 더 빠른 피드백 루프를 활성화하여 CI/CD 파이프라인을 개선하므로, 확장 가능하고 애자일한 프런트엔드를 구축할 수 있다.
실제 예: 페이스북(facebook.com)
2009년 페이스북은 웹사이트의 프론트엔드에 문제가 있었고 로딩 시간을 줄이는 솔루션을 원했다. 기존의 프론트엔드 아키텍처는 반복되는 브라우저 렌더링과 페이지 만들기 루틴에 최적화가 필요했다. 이러한 최적화만이 대기 시간과 응답 시간을 줄이는 유일한 솔루션이었다. 이것이 페이스북이 빅파이프(BigPipe)라는 마이크로 프론트엔드 솔루션을 구축한 이유이다.3) 이를 통해 페이스북은 웹 페이지를 “페이지렛(pagelets)”이라고 하는 더 작은 구성요소로 나눌 수 있었고 웹 페이지 로딩 지연 시간을 개선했다.
그림 2 페이스북의 페이지 로딩 시간 개선 (출처: 페이스북)시간이 지남에 따라 최신 마이크로 프론트엔드 아키텍처는 웹 페이지에서 웹 앱 및 모바일 애플리케이션과 같은 사용 사례도 지원하도록 진화했다.
3) 대기 시간을 줄이기 위한 별도의 마이크로서비스 데이터베이스
마이크로서비스는 느슨하게 결합되어 있지만 공유 데이터베이스가 있는 동일한 데이터 저장소에서 데이터를 검색한다. 이 경우 데이터베이스는 여러 데이터 쿼리 및 대기 시간 문제를 처리해야 한다. 이 상황에 맞는 솔루션은 마이크로서비스를 위한 분산 데이터베이스를 갖는 것으로, 각 서비스에 자체 데이터 저장소가 있는 것이 답이 될 수 있다.
별도의 마이크로서비스 데이터베이스를 사용하면 서비스가 데이터를 캐시에 로컬로 저장할 수 있기에 데이터를 가져오는 시간이 감소한다. 고유한 데이터 저장소는 보안 및 복원력도 향상된다.
실제 예: 트위터(Twitter.com)
트위터는 2012년에 모놀리딕 아키텍처에서 마이크로서비스 아키텍처로 마이그레이션했다.4) 트위터는 레디스(Redis) 및 카산드라(Cassandra)를 비롯한 다양한 서비스를 활용하여 초당 약 600개의 요청을 처리했는데, 플랫폼이 확장됨에 따라 탄력적으로 더 많은 쿼리를 처리할 수 있는 데이터베이스 솔루션이 필요했다. 트위터는 초기에 MySQL을 기반으로 구축했으며 소규모에서 대규모 데이터베이스 인스턴스로 이동했다. 이로 인한 인스턴스 간 데이터 이동에 시간이 많이 소요되었다. 이 문제에 대한 해결책으로 분산 데이터 저장소를 만드는 프레임워크인 기자드(Gizzard)를 도입하고 데이터 저장 솔루션으로 카산드라를 추가했으나 데이터 쿼리를 처리하는 데 도움을 주었을 뿐 대기 시간 문제는 지속되었다. 실시간 환경에서 대기 시간이 짧은 초당 수백만 개의 쿼리 처리가 필요했다.
대기 시간을 개선하고 초당 여러 쿼리를 처리하기 위해 ‘맨해튼(Manhattan)’이라는 사내 분산 데이터베이스를 만들었다.5) 트위터는 무엇보다도 이 분산 시스템을 통해 안정성, 가용성 및 대기 시간을 개선했다.
그림 3 맨해튼 아키텍쳐 (출처: 트위터)4) 독립적인 마이크로서비스로 서비스 자율성 활성화
독립 마이크로서비스는 서비스 격리(service isolation)를 한 단계 더 발전시키는 방식이다. 독립적인 마이크로서비스 방식을 통해 세 가지 형태의 독립성을 얻을 수 있다.
1. 독립 서비스 진화는 필요성에 따라 기능 개발을 격리하는 프로세스이다.
2. 독립적인 테스팅은 서비스 진화에 우선순위를 두고 집중하는 테스트를 수행하는 프로세스인데, 이렇게 하면 서비스 종속성으로 인한 테스트 실패 횟수가 줄어든다.
3. 독립적인 배포는 서비스 업그레이드로 인한 다운타임 가능성을 줄여준다. 특히 앱 배포 중에 주기적 종속성이 있는 경우에 매우 유용하다.
실제 예: 아마존 웹 서비스
2001년 아마존의 개발팀은 모놀리딕 아키텍처로 배포 파이프라인을 유지 관리하는 것이 어렵다는 것을 깨닫고 마이크로서비스 아키텍처로의 이전을 선택했지만 실제 문제는 마이그레이션 이후에 시작된다. 개발팀은 단일 목적을 수행하는 유닛을 가져와 웹 인터페이스로 포장했는데 이것은 매우 효율적인 솔루션이었지만 수많은 단일 목적 기능을 관리하는 데 어려움이 있었다.
그림 4 아마존 웹 서비스의 코드 파이프라인 흐름도(출처: AWS)서비스가 증가함에 따라 배포를 위해 매주 서비스를 통합하는 것은 엄청난 일이 되었고, 개발팀은 분리된 서비스를 기반으로 자동화된 배포 시스템인 ‘아폴로’를 구축한다. 아폴로는 범용 기능은 웹 인터페이스 API를 통해 통신해야 한다는 규칙과 모든 기능이 따라야 하는 분리 규칙을 정의했다.
5) 비동기 통신으로 병렬 처리 지원
서비스 간의 적절한 통신이 없으면 마이크로서비스의 성능이 심각하게 저하될 수 있다. 마이크로 서비스에 널리 사용되는 두 가지 통신 프로토콜이 있다.
동기 통신(Synchronous communication): 마이크로서비스가 리퀘스트 체인을 차단하는 유형의 통신 프로토콜로서 동기식 데이터 교환의 일반적인 예는 HTTP 요청/응답 인터랙션이다. HTTP에서 엔드포인트에 대한 요청이 있을 때 호출자는 응답이 수신될 때까지 인터랙션을 멈춘다. 호출자는 밀리 초 또는 몇 초 안에 응답받을 수 있다. 애플리케이션 대기 시간에 관계없이 호출자는 응답이 수신될 때까지 다음 작업으로 이동할 수 없다. REST는 동기식 마이크로서비스의 대표적인 예이다.
비동기 통신(Asynchronous communication): 이벤트 기반 아키텍처를 따르는 비차단 프로토콜로서 서비스에 대한 요청과 응답이 서로 독립적으로 발생하는 마이크로서비스다. 비동기식 마이크로서비스를 구현하는 일반적인 방법은 카프카(Kafka) 또는 레빗엠큐(RabbitMQ)와 같은 메시지 브로커 기술을 사용하여 서비스 중개자 역할을 하는 것이다. 한쪽의 서비스가 메시지 브로커를 사용하여 다른 서비스에 메시지를 게시하면 요청된 서비스는 자체 시간에 메시지를 수신하고 요청한 서비스는 브로커에 잠겨 있지 않다.
그림 5 마이크로서비스의 동기/비동기 통신 원리비동기식 통신 프로토콜은 사용자 요청을 실행하는 동안 서비스 간의 결합을 줄이기에 마이크로서비스 간의 통신을 위해서 더 발전된 방법이다.
실제 예: 플라이휠 스포츠(Flywheel Sports)
플라이휠 스포츠는 피트니스 커뮤니티를 위한 실시간 방송을 통해 자전거 타기 경험을 향상시킨 온라인 플랫폼 “플라이애니웨어(FlyAnywhere)”를 출시했다. 플라이휠 엔지니어링 팀은 모듈식 접근 방식과 마이크로서비스 아키텍처를 사용하여 플랫폼을 구축했다. 그러나 통신 문제로 인해 네트워크 장애와 시스템 가용성 문제가 발생했고, 문제 해결을 위해 레디스(Redis) 클러스터를 지원하는 내부 라이브러리인 “하이드라(Hydra)”를 구축했다.6) 각 마이크로서비스를 공유 레디스 클러스터에 연결하고 비동기식 통신 pub/sub을 사용하여 프로세스 간 통신을 유지했다.
그림 6 하이드라 아키텍쳐 (출처: 미디엄)또한 하이드라는 서비스 간 통신, 부하 분산 및 라우팅, 구성이 필요 없는 서비스 자체 등록과 같은 기능을 활성화하여 마이크로서비스의 단일 종속성 문제를 완화하고, 실시간 방송을 제공하기 위한 기술 기반을 구축했다.
6) 도메인 주도 디자인 (DDD: Domain Driven Design)
마이크로서비스는 기술이 아닌 비즈니스 기능을 중심으로 하는 도메인 주도 디자인으로 설계되어야 한다. 이 방법을 통해 기능면에서 높은 수준의 일관성을 얻을 수 있고, 느슨하게 결합된 서비스(loosely coupled services)를 제공할 수 있다. 모든 DDD 모델에는 전략 및 전술의 두 단계가 있다. 전략적 단계에서는 설계 아키텍처가 비즈니스 기능을 캡슐화하도록 한다. 전술적 단계에서는 각각 다른 디자인 패턴(예: 엔티티, 애그리게이터, 도메인 서비스)을 사용하여 느슨하게 결합된 도메인 모델을 생성할 수 있다.
실제 예: 사운드 클라우드(SoundCloud.com)
사운드 클라우드의 서비스 아키텍처는 Backend for frontend(BFF) 라는 패턴을 이용했는데, 중복 코드로 인한 복잡성과 우려가 있었다.7) 이런 문제를 해결하고자 DDD 패턴을 사용하고 “부가가치 서비스(VAS: Value Added Services)” 접근 방식으로 개발한다.8)
그림 7 사운드클라우드 VAS 방식 아키텍쳐 (출처: 사운드 클라우드)VAS에는 세 가지 서비스 계층이 있는데, 첫 번째는 API 게이트웨이 역할을 하는 엣지(Edge) 계층이고, 부가 가치 계층은 두 번째 계층으로, 다양한 서비스의 데이터를 처리하여 풍부한 사용자 경험을 제공한다. 마지막으로 도메인의 빌딩 블록을 제공하는 파운데이션이 세 번째 계층이다.
사운드 클라우드는 VAS 접근 방식을 사용하여 릴리스 주기를 줄이고 팀 자율성을 개선했다.
3. 마무리
많은 기업과 조직이 빠르게 변화할 수 있는 속도와 그 용이성은 업계 동향에 대응하고 경쟁 우위를 유지하는 능력을 결정한다. 구성할 수 있는 서비스 형태의 솔루션 로직의 구성을 통해 기업의 디지털 역량은 비즈니스의 속도에 맞춰 실행하고 솔루션 제공 시 민첩한 응답으로 비즈니스 변화를 일치시킬 수 있다.
기업은 시장의 힘에 따라 방향을 빠르게 바꿀 수 있어야 한다. 기업의 디지털 역량은 자산을 새로운 비즈니스 기능으로 구성하여 변화를 촉진할 수 있어야 한다. 그런 디지털 역량만이 혁신적인 고객 경험을 창출할 수 있다.
마이크로서비스 아키텍처는 분리된 서비스를 통해 더 높은 유연성과 개발 용이성이라는 장점을 통해 지속적인 혁신과 민첩성을 위한 기반을 성공적으로 만들어, 변화하는 비즈니스의 요구에 신속하게 대응하기 위한 기업에 필수적이다. 그런 의미에서 위에 소개한 6가지의 모범사례는 좋은 참고자료가 될 것으로 생각한다.
참고문헌
1) CIODive.com, “How Spotify is migrating from an in-house Docker orchestration platform to Kubernetes”, Jun 12,2018
2) Google Cloud Tech Channel in Youtube, “Adopting Kubernetes with Spotify”, Nov 12 2019
3) Facebook, “BigPipe: Pipelining web pages for high performance”, Mar 13 2021
4) Yugabyte, “The Distributed Database Behind Twitter”, Oct 15 2020
5) Twitter, “Manhattan, our real-time, multi-tenant distributed database for Twitter scale”, Apr 02, 2014
6) Medium, “Hydra at RedisConf18”, Jul 13 2018
7) Sayontech, “The Journey into Microservices at SoundCloud”, Sep 7 2021
8) Soundcloud, “Service Architecture at SoundCloud — Part 2: Value-Added Services”, Aug 20 2021
