마이크로서비스 아키텍처가 주목받기 이전부터 기업 환경에서는 중복되는 프로세스나 업무들을 하나의 서비스 단위로 개발하여 각 서비스는 호출 가능한 상태로 개발하자는 노력이 계속되어 왔다. 이는 서비스의 생성과 활용을 높여서 비즈니스 환경 변화와 업무 변화에 민첩하게 대응할 수 있는 아키텍처를 갖추기 위함이다(박성훈 2018)

(출처 : 컨테이너 인프라 환경 구축을 위한 쿠버네티스)

코드에 기능 하나를 추가하기 위해서 코드 베이스 전체를 뒤적거리며 일일히 수정하는 경험. 모두들 이런 경험을 해보신 적 있으시지 않으신가요? 비즈니스 환경 변화와 업무 변화에 민첩하게 대응하는 것은 서비스 업계에선 매우 중요한 부분일 것입니다. 하지만 코드베이스가 점점 쌓여 갈수록 작은 변화 하나에도 엄청난 노력을 요하게 됩니다.

위의 예시는 아래 그림에서 우리가 소위 모놀리식 이라 부르는 아키텍처에서 정말 빈번하게 일어나는 일 입니다. 비즈니스 요구의 변화는 여전히 많은 곳에서 쓰고 있을 워터폴(Waterfall) 개발 프로세스의 관점에선 지옥 그 자체라고 표현할 수 있겠습니다.

(출처 : NHN Cloud)

우리는 지금, 항상 그래왔듯, 빠르게 변화하는 IT 세상에 몸을 맡기고 있습니다. 현재 쪽에 위치한 네 가지 개념 Cloud, DevOps, Microservices, Containers 중 몇은 이전 아티클에서 간략히 소개하거나 설명드렸습니다만, 이번 게시글에서는 Microservice를 자세하게 설명드리고자 합니다.

마이크로서비스 아키텍쳐

마이크로서비스(microservice)는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처 (SOA) 스타일의 일종인 소프트웨어 개발 기법이다

SOA

마이크로서비스 아키텍처를 소개할 때 비슷한 개념때문에 빠짐 없이 등장하는 친구가 하나 있습니다. 바로 SOA입니다. SOA는 1970년대 개념이 언급되었고, 가트너에서 1996년 처음으로 SOA를 소개 하였으며, 2003년 이후 웹 서비스가 구체화되면서 함께 부각 되었습니다. SOAP라는 XML기반의 경량화 된 HTTP 기반 통신 프로토콜을 사용하였고 엔터프라이즈 서비스 버스(ESB)라는 패턴을 사용하여 중앙화된 구성 요소와 백엔드 시스템을 통합한 다음 이를 서비스 인터페이스의 형태로 제공합니다. 따라서 개발자는 기능을 다시 만드는 대신에 기존 기능을 재사용할 수 있습니다.

미국의 유명 소프트웨어 개발자 Martin Fowler는 SOA를 "ServiceOrientedAmbiguity"라고 불렀습니다.

I've heard people say the nice thing about SOA is that it separates data from process, that it combines data and process, that it uses web standards, that it's independent of web standards, that it's asynchronous, that it's synchronous, that the synchronicity doesn't matter.…

서비스 지향 아키텍처(Service-Oriented Architecture, SOA)는 서로 독립적인 기능을 가진 여러 서비스들을 연결하여 하나의 소프트웨어 시스템을 구축하는 아키텍처 스타일입니다. SOA는 서비스의 재사용성, 유연성, 상호운용성, 중앙 집중화된 프레임워크의 부재 등 다양한 장점을 제공합니다. 하지만, 서비스 간의 통신으로 인한 지연 시간, 느슨한 결합을 유지하기 어려운 경우 등의 문제점도 있습니다. (위의 그림에서 수평적으로 길게 늘어진 사각형들이 느슨한 결합을 위협 합니다.)

그렇기 때문에 SOA는 어떻게 보면 철지난 유행처럼 표현되곤 합니다. 하지만 반대로 MSA는 다릅니다. 넷플릭스는 마이크로서비스 아키텍쳐의 가장 좋은 적용 성공 사례라고들 합니다. 국내에서도 최근 PAYCO 쇼핑, 삼성전자, 삼성SDS, 쿠팡, 배달의 민족와 같은 수많은 거대 기업들이 MSA화 된 시스템을 구축하기 시작했습니다. 자세한 구현 사례로 11번가의 케이스를 엿볼 수 있습니다.

(마치 코로나 바이러스를 보는 듯 하지만, 아마존과 넷플릭스의 마이크로서비스들을 연결시켜 놓은 그림입니다.)

MSA와 SOA가 비슷하다면 왜 이리 극명한 온도차를 보이는 걸까요? 우선, MSA와 SOA 모두 비즈니스 문제를 서비스로 분해하는 개념을 중심으로 합니다. 허나 SOA 는 모듈의 의존성은 줄이되 모듈 내에서 공유할 수 있는건 최대한 공유하는 정책을 사용하고, MSA 는 가능한 공유하지 않고 모듈들이 독립적으로 운용될 수 있도록 아키텍처를 디자인 합니다.

응집도 vs 결합도

기존 서비스 지향 아키텍처(SOA)는 서비스 자체가 아닌 서비스 버스에 비즈니스 로직이 점점 더 추가되므로 서비스에 응집력이 부족한 경우가 많습니다. 응집도라는 단어가 몹시 추상적일 수 있겠지만 아래 그림과 함께 살펴보면 이해에 도움이 될 수 있겠습니다.

응집도(cohesion)는 마이크로서비스를 쪼갤지, 그룹화 할지를 구분할 수 있는 방법 중 하나 입니다. 응집도가 클수록 결합도(coupling)가 낮아집니다. 다시 말해 결합도는 낮을 수록 응집도는 높을 수록 이상적인 모듈화이라고 할 수 있겠습니다. SOA의 그림을 살펴봅시다. 한 눈에 보아도 공통 영역이 아주 넓게 형성되어 있음을 확인할 수 있습니다. MSA는 서비스가 공유되기보다 독립적으로 실행되는 것을 지향합니다. 모놀리식(통짜)으로 구성된 서비스를 도메인 별로 잘게 잘게 쪼게 하나의 독립적인 로직을 수행할 수 있게 됩니다. 그렇다고 서비스를 무조건 작은 단위-예를들면 CRUB 수준으로 쪼개어, 운영 조차 하기 힘들 정도가 되어선 안됩니다. 서비스를 나누되 결제, 예약, 정산 등과 같이 적절한 경계를 만들어야 합니다.

위대한 모놀리식

마이크로서비스 아키텍쳐가 유행이라면 왠지 모르게, 모놀리식 아키텍쳐가 마치 또 다른 철지난 유행이되야 할 것만 같은 느낌을 줍니다만, 이에 반하는 의견을 피력하는 사람도 분명 존재 합니다. MSA 구현에도 역시 몇몇 단점이 존재합니다. 특히 무수히 많아진 장애 가능 지점에 관한 부분이 대표적입니다.

MSA 구성 원칙

만약 MSA가 괜찮아보이고, MSA로 비즈니스 서비스를 구축하기로 결심했다면, MSA 구현에 필요한 다섯가지의 핵심 원칙을 마음에 새겨야 합니다.

• Autonomy (자율성) : 서비스는 느슨하게 결합 해야 하고 독립적으로 배포 가능 해야 합니다.

• Resilience (회복력) : 서비스를 무수히 쪼개다보면 장애 가능 지점이 증가하게 됩니다. 장애가 생겼을 때 서킷브레이커나 타임아웃등을 적용하여 적절하게 에러를 처리해야 합니다.

• Transparency(투명성) : 장애 지점을 재빠르게 찾아내기 위해서는, 전체 서비스 구조를 명확하게 파악할 수 있어야 합니다.

• Automation(자동화) : 서비스를 일일히 수동으로 테스트하고 배포하는 일은 불가능에 가깝습니다. DevOps 시스템을 구축해야 합니다.

• Alignment(정렬) : 서비스와 팀을 구성하는 데 가장 중요한 요소는 비즈니스 컨셉입니다.

  MSA기반 개발 환경에는 역 콘웨이의 법칙이 적용 되어야 합니다. 콘웨이의 법칙이란 시스템 구조는 설계하는 조직의 커뮤니케이션 구조와 닮는다는 내용입니다. 따라서 이 법칙을 역으로 이용해서 마이크로서비스 시스템 구조에 따라 조직 구조가 변경되도록 설계해야 합니다. 이렇게 하면 개발 팀과 서비스를 느슨하게 결합시킬 수 있습니다.

MSA 패턴

또한 MSA에는 다양한 패턴들이 존재합니다. 아래의 패턴들에 대해 알고 있는 것은 효과적인 설계를 위해선 매우 중요한 부분입니다.

• Communication Patterns
  • Synchronous (RESTful, gRPC, GraphQL, WebSocket)
  • Asynchronous Messaging (AMQP, Kafka, NATS)
• Connectivity and Composition Patterns
  • Service Mesh
  • Service Choreography
  • Saga
• Data Management Patterns
  • DB (RDB, NoSQL)
  • Data Management
  • Data Scaling (Sharding, CQRS)
• Event-Driven Architecture Patterns
  • Event-Delivery
  • State Management
  • Orchestration
• Stream-Processing Patterns
  • Streaming Data Processing
  • Scaling and Performance Optimization
  • Reliability
• API Management and Consumption Patterns
  • API Gateway

위의 패턴들에 대해 더 자세하게 알고 싶다면 다음의 책을 추천합니다.

Design Patterns for Cloud Native Applications (O’Reilly Media, Inc., 2021. 314 p. ISBN: 978-1-492-09071-7.)

여기까지 마이크로서비스 아키텍처(MSA)에 대한 개념과 SOA와의 차이점, MSA의 장단점, MSA 구현에 필요한 핵심 원리, 그리고 다양한 MSA 패턴들에 대해 다루어 보았습니다. 이 정도면 마이크로서비스 아키텍쳐에 대한 간략한 소개가 된 것 같습니다.

쿠버네티스는 ...?

하지만 중요한 것은 쿠버네티스가 MSA 환경에서 어떤 역할을 하는지 입니다. 저번 아티클의 가장 마지막 질문을 기억하실 지 모르겠습니다.

“컨테이너를 그렇게 많이 구동 시킬 필요가 있나? 데이터베이스든 운영체제든 아무리 많이 필요하다고 해도 손가락으로 셀 수 있을 정도 아닐까?”

이에 대한 답을 내려보자면, 모놀리식을 고수하는 개발팀은 굳이 그럴 필요는 없겠습니다. 그러나 MSA 개발팀이라면 필수불가결할 듯 합니다. (인정하지 못하시겠다면, 다시 한 번 보고 옵시다) MSA의 서비스 하나 하나 (각각 Endpoint를 가지는, 예를 들어 서버)들은 결국 깡통 서버가 되든지, VM이 되든지, Container로 올리던지 해야할 테니까요. (이 중 무엇을 사용하는 게 가장 편한 길일까요?)

결국 쿠버네티스는 마이크로서비스 환경에서 서비스의 배포, 확장 및 관리를 담당하는 컨테이너 오케스트레이션 도구입니다. 이를 통해 개발자들은 더욱 빠르게 안정적인 서비스를 제공할 수 있으며, 유지보수 및 확장성도 용이해집니다. 즉, 쿠버네티스는 마이크로서비스 아키텍처에서 필수적인 도구 중 하나입니다.

자, 저희는 아주 먼 길을 돌고 돌아온 끝에 쿠버네티스에 대해 얼추 감을 잡은 것 같습니다. 다음 아티클은 Kubernetes의 자세한 구조와 구성요소에 대한 글이 될 것 같습니다.

• 참고자료
  • Microservices in Action (ISBN 978161729445)
  • https://dzone.com/articles/service-oriented-architecture-a-dead-simple-explan
  • https://wiki.webnori.com/display/devbegin/SOA+VS+MSA
  • https://always-kimkim.tistory.com/entry/SOA와-MSA의-차이점