마이크로서비스 사용사례 - MSA 의 핵심 아키텍처 컨셉

1. 모노리틱 아키텍처

기업의 소프트웨어 애플리케이션은 많은 비즈니스 요건을 용이하도록 설계되었습니다. 따라서, 하나의 소프트웨어 애플리케이션이 수백 가지의 비즈니스 역량을 제공하고 이러한 역량들이 일반적으로 단일 모노리틱 애플리케이션에 쌓이게 됩니다. 전사적 자원관리 ERP, 고객관계관리 CRM 등의 소프트웨어 시스템들이 좋은 예입니다. 이러한 시스템들은 수백 가지 비즈니스 역량을 갖춘 모노리스입니다. 이러한 소프트웨어 애플리케이션을 배포, 트러블슈팅, 확장, 업그레이드 하는 것은 악몽과도 같은 일입니다.

서비스기반 아키텍처 SOA는 ‘서비스’ 컨셉을 도입함으로써 모노리틱 애플리케이션으로부터 야기되는 문제를 극복하도록 설계되었습니다. 따라서, 소프트웨어 애플리케이션은 SOA와 함께 서비스의 혼합체로 설계됩니다. SOA의 컨셉은 서비스 실행을 모노리스로 제한하지 않으며, 오히려 가장 인기있는 웹 서비스가 소프트웨어 애플리케이션을 모노리스로 실행될 수 있도록 하며, 이는 동일한 런타임에 운영되는 성글게 구성된 웹서비스로 구성되어 있습니다. 모노리틱 소프트웨어 애플리케이션과 비슷하게 이러한 서비스들은 다양한 역량을 축적하여 시간이 지남에 따라 성장하는 경향이 있습니다. 이와 같은 애플리케이션들은 곧 모노리틱 글로브로 성장하며, 이는 평범한 모노리틱 애플리케이션과 전혀 차이가 없습니다.

그림 1은 다양한 서비스로 구성되어 있는 리테일 소프트웨어 애플리케이션입니다. 모든 서비스들은 동일한 모노리틱 런타임(애플리케이션 서버와 같은) 으로 배치됩니다. 따라서 다음과 같이 다양한 모노리틱 애플리케이션의 특징을 보여줍니다. 복잡하고, 단일 유닛으로 설계되고, 개발되고, 실행됩니다. 애플리케이션의 부분적 업데이트와 마찬가지로, 민첩한 개발 및 전달 방법을 실행하기는 어렵습니다.

이러한 접근방법에 약간의 다른 문제도 있습니다. 모노리스는 단일 애플리케이션으로 확장되어야 하며, 충돌하는 리소스 요구사항을 포함하여 확장되기 어렵습니다. (예, 하나의 서비스는 더 많은 CPU를 요구하는 반면 또 다른 서비스는 더 많은 메모리를 요구할 때) 하나의 불안정한 서비스가 애플리케이션 전체를 다운 시킬 수 있으며, 일반적으로 새로운 기술과 프레임워크를 혁신하거나 도입하기 어렵습니다.

이러한 이유들로 마이크로서비스 아키텍처가 개발되었습니다. 마이크로서비스 아키텍처에 대해서 알아 보도록 하겠습니다.

2. 마이크로서비스 아키텍처

마이크로서비스 아키텍처 MSA의 기본은 개별 프로세스에 따라 운영되고, 독립적으로 개발되고 활용되는 일단의 독립적인 소규모 서비스들을 단일 애플리케이션으로 개발하는 것입니다.

MSA의 대부분의 정의들을 보면, 모노리스에서 사용 가능한 서비스들은 일련의 독립된 서비스들로 구분하는데 초점을 맞춘 아키텍처적 컨셉으로 정의합니다. 그러나 마이크로서비스는 모노리스에서 사용 가능한 서비스들을 독립된 서비스들로 단순히 분류하는 것에 그치지 않습니다.

모노리스에서 제공하는 기능들을 보고 애플리케이션에서 요구되는 비즈니스 역량들을 확인할 수 있다고 가정해 봅시다. 즉, 애플리케이션을 유용하게 하기 위해 필요한 것들을 알 수 있게 됩니다. 이러한 비즈니스 역량들은 완전히 독립적이고, 치밀하고, 충분히 갖춰진 (마이크로) 서비스 입니다. 이러한 마이크로서비스는 다른 기술들을 기반으로 실행될 수도 있습니다. 그러나 그렇다고 할지라도 각 서비스는 매우 구체적이고 제한적인 비즈니스 영역을 가지게 됩니다.

이러한 방식으로 위에 소개한 온라인 리테일 시스템 시나리오는 그림 2에 묘사된 MSA로 실현될 수 있습니다. 보다시피, 비즈니스 요구조건을 기반으로, 기존에 모노리스에 존재하던 오리지널 서비스들에 추가된 마이크로서비스가 있습니다. 그렇다면 이는 단순히 서비스를 더욱 복잡한 그라운드위에 분류하는 것 이상임이 명백합니다.

마이크로서비스의 주요 아키텍처 원리를 알아보고, 실제 어떻게 사용되는지 중점적으로 알아보는 것이 중요합니다.

3. 마이크로서비스 디자인하기: 사이즈, 범위, 역량

마이크로서비스라 하면 다음의 둘 중 한가지를 해당됩니다. 자신만의 소프트웨어 애플리케이션을 기초부터 구축 하던지, 기존의 애플리케이션/서비스를 마이크로서비스로 전환하는 것입니다. 어느 쪽이든 간에 마이크로서비스의 규모, 범위, 역량을 적절히 결정하는 것이 중요합니다. MSA를 실제 실행할 때 가장 먼저 부딪히게 될 가장 어려운 일입니다.

이와 관련하여 다음과 같은 실행 상의 우려 및 오해가 있습니다.

• 코드 라인/팀 사이즈는 형편없는 매트릭스입니다. 서비스의 실행을 위한 코드 라인 혹은 마이크로서비스의 팀 사이즈의 수에 따라 마이크로서비스의 사이즈를 결정해야 한다는 것에는 여러 논의가 있습니다. (예. 피자 두판의 법칙⁴ (two-pizza team) ) 그러나 더 적은 코드와 피자 두판의 법칙으로 MSA 원리에 위반되는 서비스를 개발할 수 있기 때문에 이는 매우 비실용적이며 형편없는 매트릭스로 간주됩니다.
• ‘마이크로’는 오해의 소지가 있는 용어입니다. 대부분의 개발자들은 서비스를 가능한 소규모로 만들기 위해 노력해야 한다고 오해하는 경우가 많습니다. 이는 잘못된 해석입니다.
• SOA/웹서비스 서비스는 종종 다양한 단위로 실행됩니다. 적은 역량을 가진 서비스도 있고 수많은 서비스를 가진 서비스도 있습니다. 웹서비스를 구축하거나 이를 마이크로서비스로 리브랜딩 한다고 MSA가 가진 장점을 가질 수는 없습니다.

그렇다면 MSA에서 서비스를 어떻게 적절하게 설계해야 할까요?

3.1 마이크로서비스 설계 가이드라인

• 단일책임원칙 (Single Responsibility Principle, SRP): 마이크로서비스의 비즈니스 영역을 제한적이고 집중적으로 설정해야 서비스 개발 및 전달의 민첩성을 달성하는데 도움이 됩니다.
• 설계 단계에서 마이크로서비스의 영역을 설정해야 하며, 이를 비즈니스 역량과 일치시켜야 합니다. (도메인 주도 설계 (Domain-Driven-Design) 에서 바운디드 컨텍스트 (bounded context)로 부름).
• 마이크로서비스 설계 시 서비스의 개발과 실행이 민첩하고 독립적으로 이루어 질 수 있도록 해야 합니다. 서비스를 더욱 작게 만드는 것이 아닌, 마이크로서비스의 영역에 집중해야 합니다.
• 초기에는 비교적 광범위한 서비스 영역으로 시작하는 것도 좋습니다. 그런 후 시간이 지남에 따라 (비즈니스 요구사항에 따라) 더욱 작은 규모로 리팩터링 할 수 있습니다.

리테일 사용 사례를 보시면, 모노리스의 기능을 4개의 다른 마이크로서비스 인 ‘인벤토리’, ‘어카운팅’, ‘배송’, ‘스토어’로 구분한 것을 보실 수 있습니다. 제한적이지만 집중된 비즈니스 영역으로 구성되어, 각자 완전히 독립되어 있고, 개발과 실행에 있어 민첩성이 있습니다.

4. 마이크로서비스의 메시지 기능

모노리틱 애플리케이션에서 각기 다른 프로세서/구성요소의 비즈니스 역량은 함수 호출 혹은 언어 수준의 메서드 호출을 사용하여 호출합니다. SOA에서 이러한 기능은 훨씬 더 느슨하게 연결된 웹 서비스 수준의 메시지 기능으로 이전되었고, HTTP와 JMS와 같은 각기 다른 프로토콜 위의 SOAP에 주로 기반을 두고 있습니다.

4.1 동기화된 메시지 기능 -REST, gRPC, GraphQL, Thrift

MSA에서 동기화된 메시지 전송 기능은 (클라이언트는 서비스로부터 신속한 응답을 기대하고, 기다립니다.) 리소스에 기반한 HTTP 리퀘스트(요청)-리스폰스(응답)로 단순 메시지 전송 스타일로 실행됨을 증명한REST (Representation State Transfer)를 만장일치로 사용합니다.

gRPC 역시 RESTful 서비스의 대안책이자 인터-프로세스 커뮤니케이션 기술로 꽤 인기가 많아졌습니다. 로컬 함수 호출을 하는 것만큼 쉽게 분산된 이종 애플리케이션을 연결, 호출, 운영, 디버그 할 수 있도록 해 줍니다. REST와는 달리, 인터페이스 정의 언어 (Interface Definition Language, IDL)를 기반으로 gRPC의 프로토콜 버퍼를 사용하여 서비스 계약를 완전히 정의할 수 있으며, 원하는 프로그래밍 언어 (Go, Java, Node 등)를 위한 서비스 및 클라이언트를 생성할 수 있습니다.

GraphQL 역시 고정적인 서비스 계약을 가질 수 없는 경우에 꽤 많이 사용되고 있습니다. GraphQL은 API를 위한 질의 언어이자, 기존의 데이터로 질의에 답하기 위한 러닝 타임입니다. 일반적인 클라이언트-서버 커뮤니케이션과는 다르며, 기초 수준에서부터 클라이언트가 원하는 데이터를 결정하고, 어떠한 방식으로, 어떠한 형식으로 제시될 지 결정할 수 있도록 합니다.

Thrift (쓰리프트) 는 REST/HTTP 동기화 메시지 기능의 대안으로 사용됩니다. (마이크로서비스의 인터페이스 정의를 정의할 수 있는 경우 사용됩니다.)

동기화 요청-응답 스타일 메시지가 대부분 인터렉티브하고 외향적 API와 같이 리얼 타임 프로세싱을 원하는 서비스 및 클라이언트에 더욱 적합합니다.

4.2 비동기화 메시지 – Kafka, NATS, AMQP, STOMP, MQTT

서비스 간 메시지 기능은 이벤트 주도 메시지 기능을 기반으로 할 수 있습니다. 클라이언트는 이벤트 기반 비동기화 메시지 기능에 즉각적인 응답을 기대하지 않거나, 아예 응답을 기대하지 않습니다. 이러한 시나리오를 위해 마이크로서비스는 NATS, Kafka, AMQP, STOMP, MQTT와 같은 메시지 프로토콜을 사용할 수 있습니다. 일반적인 메시지 프로토콜과는 달리, Kafka와 NATS는 단순하고 (dumb) 분산된 메시지 인프라를 제공하는데 이는 마이크로서비스 구축에 더욱 적합합니다. 따라서 생산자와 소비자는 모든 비즈니스 로직을 가지지만, 브로커는 아무런 비즈니스 로직을 가지지 않게 됩니다.

4.3 메시지 포맷 – JSON, XML, Thrist, ProtoBuf, Avro

마이크로서비스에 가장 적합한 메시지 포맷을 정하는 일도 또 다른 중요 요소입니다. 전통적인 방식의 모노리틱 애플리케이션은 복잡한 이진수 포맷을 사용하는 반면, SOA – 그리고 웹기반 애플리케이션은 복잡한 메시지 포맷 (SOAP) 및 스키마 (XSD)를 기반한 텍스트 메시지를 사용합니다. 애플리케이션을 기반으로 한 대부분의 마이크로서비스는 HTTP REST API를 기반으로 한 JSON, XML과 같이 단순한 텍스트 기반 메시지 포맷을 사용합니다. 이진수 메시지 포맷이 필요한 경우 (텍스트 메시지가 장황할 경우), 마이크로서비스는 이진수 쓰리프트, ProtoBuf 혹은 Avro와 같은 이진수 메시지 포맷을 사용할 수 있습니다.

4.4 서비스 계약 – 서비스 인터페이스 정의 – 오픈 API/스웨거, gRPC IDL, GraphQR 스키마, 쓰리프트 IDL

비즈니스 역량을 서비스로 실행하는 경우, 서비스 계약을 정의하고 발행할 필요가 있습니다. 전통적인 모노리틱 애플리케이션에서 우리는 애플리케이션의 비즈니스 역량을 정의하는 기능을 거의 찾아볼 수 없습니다. SOA/웹 서비스 세상에서는 WSDL을 서비스 계약을 정의하는데 사용합니다. 그러나 WSDL은 REST를 일등시민으로 취급하지 않기 때문에 마이크로서비스 계약 정의를 위한 이상적인 솔루션은 아닙니다.

REST 아키텍처 스타일 위에 마이크로서비스를 구축하기 때문에 마이크로서비스 계약을 정의하기 위해서 동일한 REST API 정의 기술을 사용할 수 있습니다. 따라서 마이크로서비스는 서비스 계약을 정의하기 위해 스웨거나 RAML과 같은 표준 REST API 정의 언어를 사용합니다.

HTTP/REST에 기반하지 않는 마이크로서비스의 실행을 위해 예를 들어, gRPC 및 쓰리프트의 실행을 위해 프로토콜 레벨 IDL을 사용할 수 있습니다. GraphQL의 경우, 클라이언트가 GraphQL-기반 API를 요청하기 위해 사용될 수 있는 GraphQL스키마를 사용하여 서비스 스키마를 정의할 수 있습니다.

5. 분산 데이터 관리

모노리틱 아키텍처에서 애플리케이션은 다양한 역량을 실행하기 위해 단일 중심 데이터 베이스에 데이터를 저장합니다.

MSA에서 비즈니스 역량들은 다수의 마이크로서비스에 분산되어 있습니다. 따라서 동일한 집중화 된 데이터 베이스를 사용한다면, 서비스 간 느슨한 커플링을 보장하기 어렵습니다. (예를 들어, 데이터 베이스 스키마가 한 마이크로서비스에서 변경될 경우, 다른 서비스들이 고장 날 수 있습니다. ) 따라서 각각의 마이크로서비스는 자신만의 데이터 베이스를 보유해야 합니다.

MSA에서 분산된 데이터 베이스 관리에 있어서 중요한 사항은 다음과 같습니다.

• 각각의 마이크로서비스는 제공하는 비즈니스 기능을 실행하기 위해 필요한 데이터를 유지하기 위해 자신의 전용 데이터 베이스를 가질 수 있습니다.
• 하나의 마이크로서비스는 자신의 전용 데이터 베이스에만 엑세스가 가능하며, 타 마이크로서비스의 데이터 베이스에는 엑세스 할 수 없습니다.
• 어떤 비즈니스 상황의 경우, 단일 트랜잭션을 위해 다수의 데이터 베이스를 업데이트 해야 할 수도 있습니다. 이러한 상황에서, 타 마이크로서비스의 데이터 베이스는 자신의 서비스 API를 통해서만 업데이트해야 합니다. (데이터 베이스에 직접 엑세스는 허용되지 않습니다.)

분산된 데이터 관리를 통해 완전히 분산분리된(Decoupled)된 마이크로서비스의 구축 및 이질적 데이터 관리 기술의 선택이 자유롭도록 합니다. (SQL 혹은 NoSQL 및 각 서비스를 위한 상이한 데이터 베이스 관리 시스템). 다수의 마이크로서비스에 걸쳐 동기화된 메시지 기능이 필요한 경우, 다수의 기술을 사용할 수 있습니다. 이는 하나의 서비스API를 통해 요구되는 데이터 베이스를 업데이트 하기 위해 해당 서비스가 다수의 서비스를 호출하는 경우 서비스 구성을 구축하는 것을 포함합니다. 또한 각기 다른 서비스들의 데이터를 전달하고, 데이터의 다양한 실체를 형성하기 위해 서비스 간 이벤트-기반 메시지 기능을 사용할 수 있습니다. 마이크로서비스에서 데이터 관리와 관련 CQRS (Command Query Responsibility Segregation)와 같은 관련 패턴들이 있습니다. 본 저서에서 마이크로서비스 데이터 관리 기술 및 패턴에 대한 더욱 자세한 정보를 확인하 실 수 있습니다.

6. 거버넌스

IT 문맥에서 ‘거버넌스’는 기업이 기업의 목표를 달성하기 위해 IT를 효과적이고 효율적으로 활용할 수 있도록 하는 프로세스로 정의됩니다. SOA 거버넌스는 재사용 가능한 서비스의 개발에 대한 가이드라인을 제시하고, 서비스가 어떻게 설계되고 개발되어야 하는지, 이러한 서비스들이 시간이 경과함에 따라 어떻게 변경되는지 보여줍니다. 서비스 제공자와 사용자 사이의 합의를 도출하고, 사용자가 기대할 수 있는 바와 제공자들이 제공할 의무가 있는 것들에 대해서 알려 줍니다. 일반적으로 사용되는 두 종류의 SOA 거버넌스가 있습니다.

• 설계-시간 거버넌스 – 서비스 구축, 설계 서비스 정책 실행 정의 및 관리
• 런타임 거버넌스 – 서비스 실행 시 정책을 집행하는 능력

그렇다면, 마이크로서비스 문맥에서 거버넌스가 의미하는 바는 무엇일까요? 마이크로서비스 거버넌스를 완전히 분산된 프로세스로 포지셔닝하는 것에 대한 논의가 있지만, 마이크로서비스 아키텍처의 여러 면을 자세히 들여다보면, 마이크로서비스 거버넌스에는 집중화 된 면과 분산화 된 면이 모두 존재한다는 사실이 분명해 집니다. MSA에서는 거버넌스의 다양한 면을 볼 수 있습니다:

• 개발 및 수명주기 관리
• 서비스 레지스트리 및 검색
• 관측가능성
• 서비스 및 API 관리

개발 수명주기 관리와 관련하여, 마이크로서비스는 다양한 기술과 플랫폼을 가진 완전히 독립되고 분리된 서비스로 구축됩니다. 따라서, 서비스의 설계 및 개발을 위한 공통된 기준을 제시할 필요가 없습니다. 마이크로서비스의 분산화 된 거버넌스 역량은 다음과 같이 요약할 수 있습니다.

• 마이크로서비스는 서비스의 설계 및 실행과 관련된 사항을 스스로 결정할 수 있습니다.
• MSA는 공통/재사용 가능한 서비스들의 공유를 용이하게 합니다.
• 쓰로팅, 모니터링, 공통 보안요건, 서비스 검색 등과 같은 런타임 거버넌스의 다양한 측면들은 각 마이크로서비스 수준에서 실행되지 않습니다. 오히려, 각각의 구성요소 SLAs에서 실현됩니다. (종종, API-게이트웨이 수준)

서비스 레지스트리와 디스커버리는 다소 중앙화 된 프로세스로써, 중앙 저장소에 서비스 메타데이터를 기록할 수 있습니다. 비슷하게도, 관측가능성 역시 중앙화 된 프로세스로써 서비스 매트릭스를 발행할 수 있고, 서비스 전반에 걸쳐 중앙화 된 모드로 운영되는 도구와 관련된 데이터를 기록하고 추적합니다. 관리 서비스 혹은 관리 API로 노출하는 경우, 선택된 일단의 서비스들은 API 관리 기술을 사용할 수 있습니다. API 관리기능 역시 MSA의 중앙화 된 구성요소로써 실행됩니다. 다음 부분에서는 거버넌스의 모든 면에 대해서 자세히 다룰 것입니다.

7. 서비스 레지스트리 및 서비스 디스커버리

MSA에서 다루어야 할 마이크로서비스의 수는 꽤 많습니다. 마이크로서비스의 성격상 개발 및 실행이 매우 빠르고 민첩하게 이루어 지므로, 로케이션이 매우 역동적으로 변경됩니다. 따라서, 런타임 동안 마이크로서비스의 로케이션을 찾아야 합니다. 이를 위해 서비스 레지스트리를 사용합니다.

7.1 서비스 레지스트리

서비스 레지스트리는 마이크로서비스 인스턴스들의 메타데이터를 보유합니다. (이는 실제 로케이션, 호스트 포트 등을 포함합니다.) 마이크로서비스의 인스턴스들은 스타트업 시 등록되며, 셧 다운 시 등록 해제됩니다. 사용자는 서비스 레지스트리를 통해 사용 가능한 마이크로서비스와 이러한 서비스들의 로케이션을 찾을 수 있습니다.

7.2 서비스 디스커버리

사용 가능한 마이크로서비스와 해당 서비스의 로케이션을 확인하기 위해 서비스 검색 메커니즘을 보유할 필요가 있습니다. 두 가지의 서비스 디스커버리 메커니즘이 있습니다. 클라이언트 사이드 디스커버리와 서버 사이드 디스커버리입니다. 이 두가지 서비스 디스커버리 메커니즘에 대해서 더욱 자세히 알아보도록 하겠습니다:

7.2.1 클라이언트 사이드 디스커버리

이와 같은 접근 방법에서, 클라이언트 혹은 API 게이트웨이는 서비스 레지스트리에 요청하여 서비스 인스턴스의 로케이션을 확보합니다.

클라이언트 혹은 API 게이트웨이는 서비스 레지스트리 구성요소를 호출함으로써 서비스 디스커버리 로직을 실행해야 합니다.

7.2.2 서버 사이드 디스커버리

이러한 접근방법에서 클라이언트 혹은 API 게이트웨이는 잘 알려진 로케이션에서 운영되는 구성요소(로드 밸런서)에 요청을 보냅니다. 이러한 구성요소는 서비스 레지스트리를 호출하고, 요청한 마이크로서비스의 로케이션을 확인합니다.

마이크로서비스는 서버 사이드 디스커버리 을 위해Kubernetes 와 같은 실행 솔루션을 사용할 수 있습니다.

Kubernetes는 빌트-인 서비스 레지스트리와 디스커버리 역량을 제공 하며, 논리명을 사용해 서비스를 호출할 수 있도록 하며, Kubernetes는 논리명을 실제 IP와 포트로 풀어줍니다.

8. 배포

MSA에 있어서 마이크로서비스의 배포는 중요한 역할을 하며, 다음과 같은 중요한 요건을 필요로 합니다:

• 다른 마이크로서비스와 독립적으로 배포/배포 취소할 수 있는 능력
• 각 마이크로서비스 수준에서 확장할 수 있는 능력 (한 서비스는 다른 서비스들 보다 더 많은 트래픽을 가질 수 있음)
• 마이크로서비스의 신속한 배포능력
• 마이크로서비스의 장애가 다른 서비스에 어떠한 영향도 미치지 않아야 함

도커 (Docker, 리눅스 환경에서 개발자 및 시스템 어드민이 자립적 애플리케이션 컨테이너를 배포할 수 있는 오픈소스 엔진)는 마이크로서비스를 배포할 수 있는 훌륭한 방식을 제공하는 한편 위의 요건을 충족합니다. 이와 관련된 중요 단계는 다음과 같습니다.

• 마이크로서비스를 (도커) 컨테이너 이미지로 패키징
• 각 서비스 인스턴스를 컨테이너로 배포
• 컨테이너 인스턴스의 수에 따라 확장
• 도커 컨테이너 사용 시 마이크로서비스의 구축, 배포 및 개시가 더욱 빨라 짐 (일반 VM보다 훨씬 빠름)

Kubernetes 는 리눅스 컨테이너 클러스터를 단일 시스템으로 관리 용이하게 함으로써 도커의 역량을 확장 시켜주며, 이와 더불어, 다수의 호스트에서 도커 컨테이너를 관리 및 운용하고, 컨테이너의 공동 로케이션, 서비스 디스커버리, 재생관리의 기능을 제공합니다. 이와 같이 대부분의 기능들이 마이크로서비스 맥락에서도 중요합니다. 따라서 마이크로서비스 배포를 위해 Kubernetes (도커를 기반으로 한) 활용하는 것은 매우 강력한 접근법이고, 특히 대규모 마이크로서비스 배포에 있어서 강력합니다.

표 8은 마이크로서비스가 리테일 애플리케이션에서 어떻게 배포되는지 보여줍니다. 각각의 마이크로서비스 인스턴스는 컨테이너로 배포되며, 호스트당 두 개의 컨테이너가 배포됩니다.

9. 보안

마이크로서비스의 보안은 실제 상황에서 사용시 공통적으로 요구되는 요건입니다. 마이크로서비스 보안에 대해서 본격적으로 알아보기 전에 모노리틱 애플리케이션 수준에서 보통 어떻게 보안을 실행하는지 간략히 알아보도록 하겠습니다.

• 모노리틱 애플리케이션에서, 보안은 ‘호출자가 누구인지’, ‘호출자가 할 수 있는 것은 무엇인지’, ‘정보를 어떻게 전달할지’를 찾는 것입니다.
• 이는 주로 공통의 보안 구성요소에서 실행되며, 요청 처리 과정 중 시작 단계에 해당합니다. 해당 구성요소는 기저의 사용자 저장소를 사용하여 요청된 정보를 제공합니다.

그렇다면, 이러한 패턴을 MSA로 직접 해석할 수 있을까요? 그렇습니다. 그러나 요구되는 정보를 회수하기 위해 중앙화 되고 / 공유된 사용자 저장소와 의사 소통할 수 있는 각 마이크로서비스 수준에서 실행되는 보안 구성요소가 요구됩니다. 이는 이와 같은 마이크로서비스 보안 문제를 해결하기 위한 매우 따분한 접근법입니다.

대신에 더 나은 솔루션을 찾기 위해서 OAuth 2.0 및 OpenID Connect (OIDC)와 같은 더 널리 사용되는 API-보안 표준을 사용할 수 있습니다. 이에 대해서 더욱 자세히 알아보기 이전에 각 표준의 목적에 대해서 요약해 보고 어떻게 사용할 수 있는지 사용법에 대해서 알아보도록 하겠습니다.

• OAuth 2.5은 접근위임 프로토콜입니다. 클라이언트는 인증 서버로 인증하고, Opaque Token을 얻는데 이는 ‘접근 토큰’으로 알려져 있습니다. 접근 토큰은 사용자 혹은 클라이언트에 대한 정보가 없습니다. 사용자 정보에 대한 레퍼런스만 가지고 있으며, 인증 서버를 통해 검색할 수 있습니다. 따라서 ‘바이-레퍼런스 토큰’으로도 알려져 있으며, 공공 네트워크 혹은 인터넷에서도 사용이 안전합니다.
• OIDC는 OAuth 2.0과 마찬가지로 행동합니다. 그러나 접근 토큰에 더하여 인증 서버는 사용자에 대한 정보를 담고 있는 ID 토큰을 발행합니다. 이는 종종 인증 서버에 의해 서명된 JSON Web Token (JWT)에 의해 실행됩니다. 인증 서버와 클라이언트 사이에 신뢰를 가질 수 있게 합니다. JWT는 사용자의 정보를 포함하고, 인터넷 네트워크 외의 사용이 안전하지 않기 때문에, 따라서 ‘바이-밸류 토큰’으로 알려져 있습니다.

이제, 리테일 상황에서 마이크로서비스를 활용하기 위해 이러한 표준들을 어떻게 사용할 수 있는지 알아보겠습니다.

표 9에서 볼 수 있듯이 마이크로서비스 보안을 실행하기 위해서는 다음의 주요 단계를 거쳐야 합니다.

• 인증은 OAuth 2.0과 OIDC 서버 (인증 서버)에 맡깁니다. 데이터 사용권이 있다면 마이크로서비스에 성공적으로 접근 가능합니다.
• 모든 클라이언트 요청에 단일 엔트리 포인트가 존재하는 경우, API 게이트 웨이 스타일을 사용하십시오.
• 클라이언트는 인증 서버에 연결하여 접근 토큰 (바이-레퍼런스 토큰)을 획득합니다. 그런 후 요청사항과 함께 API 게이트 웨이에 대한 접근 토큰을 전송합니다.
• 게이트 웨이에서의 토큰 해석 – API 게이트웨이는 접근 토큰을 추출하여 JWT를 회수하기 위해 인증 서버에 전송합니다. (밸류-토큰)
• 게이트 웨이는 마이크로서비스 레이어에 대한 요청과 함께 JWT를 전달합니다.
• JWT는 사용자 세션과 기타 데이터를 저장하는데 도움이 되는 필요한 정보는 포함하고 있습니다. 각 서비스는 하나의 JWT를 이해하여, 아이덴티티 메커니즘을 분배하며, 시스템 전반에 아이덴티티를 전달합니다.
• 각 마이크로서비스 레이어에서 JWT를 처리하는 구성요소를 가질 수 있으며 이는 굉장히 사소한 실행입니다.

10. 장애를 위한 설계

모노리틱 설계와 비교해 볼 때 MSA는 분산된 서비스를 도입하기 때문에, 각 서비스 수준에서 장애 발생 확률이 증가합니다. 사실 이러한 기술들은 MSA와 함께 발명된 것이 아니며, 소프트웨어 애플리케이션 개발 공간에 오래 동안 존재해 왔습니다. (MSA는 이러한 컨셉의 중요성 만을 강조할 뿐입니다. )서

하나의 마이크로서비스는 네트워크의 문제 혹은 가용한 기본 리소스가 없어 장애가 발생할 수 있습니다. 사용 불가한 혹은 응답 없는 마이크로서비스로 마이크로서비스 기반 애플리케이션 전체를 다운 시켜서는 안됩니다. 따라서 마이크로서비스는 장애 허용성을 가져야 하며, 가능한 경우 회복할 수 있어야 합니다. 또한 클라이언트는 이를 적절하게 해결할 수 있어야 합니다.

또한 서비스는 언제든 장애가 발생할 수 있으므로, 장애를 빠르게 감지 (실시간 모니터링)할 수 있는 것이 중요하고, 가능한 경우 자동 복원 할 수 있도록 하는 것이 중요합니다.

마이크로서비스 맥락에서 에러를 처리하기 위해 일반적으로 사용되는 다양한 패턴들이 있습니다.

10.1 서킷 브레이커

마이크로서비스에 외부 호출을 하는 경우, 각 호출에 장애 모니터 컴포넌트를 설정합니다. 장애가 특정 분기점에 도달하게 되면, 해당 컴포넌트는 서비스의 추가 호출을 정지합니다. (서킷 트립). 오픈 스테이트에서 일정 수준의 요청 수가 발생하는 경우 (환경을 설정할 수 있습니다), 서킷을 다시 클로즈 스테이트로 변경합니다.

이 패턴은 불필요한 리소스 사용을 피하고, 타임아웃으로 인한 딜레이 요청을 하는데 매우 유용합니다. 또한 시스템 모니터링 능력을 제공합니다. (액티브 오픈 서킷 스테이트 기반)

10.2 벌크헤드

마이크로서비스 애플리케이션은 다수의 마이크로서비스를 구성한다는 가정 하에, 마이크로서비스 기반 애플리케이션의 부분 장애가 나머지 부분에 영향을 미치지 않아야 합니다. 벌크 헤드 패턴은 애플리케이션의 다른 부분을 고립시키는 것으로써, 애플리케이션의 한 부분에 서비스 장애는 다른 서비스에 영향을 미치지 않습니다.

10.3 타임아웃

타임아웃 패턴은 마이크로서비스로부터의 응답이 오지 않을 것으로 예상될 때 이를 기다리는 것을 중지하도록 합니다. 여기에 기다리기 원하는 만큼의 시간 간격을 설정할 수 있습니다.

위에 논의한 패턴은 마이크로서비스 간 커뮤니케이션에 일반적으로 사용됩니다. 대부분의 패턴들은 다른 프로그래밍 언어를 위한 라이브러리 (예. Hystrix)에서 사용 가능하며, 개발하는 서비스에서 이러한 패턴을 재사용할 수 있습니다.

11. 서비스/프로세스 간 커뮤니케이션

MSA에서 소프트웨어 애플리케이션은 일단의 독립된 서비스로써 구축됩니다. 따라서, 비즈니스 활용 사례를 실현하기 위해, 다양한 마이크로서비스/프로세스 간 커뮤니케이션 구조를 구축해야 합니다. 따라서, 마이크로서비스 간 인터-서비스/프로세스 커뮤니케이션이 중요합니다.

itself. SOA 실행에 있어서 서비스 간 내부 커뮤니케이션은 엔터프라이즈 서비스 버스(EBS)로 알려진 센트럴 런타임에 의해 촉진되며, 대부분의 비즈니스 로직은 중간 레이어에 존재합니다. (메시지 라우팅, 변경, 서비스 오케스트레이션) 그러나 MSA은 센트럴 메시지 버스/ESB를 제거하고 서비스와 클라이언트 (‘스마트 엔드 포인트’라 함)에 ‘스마트함 (smartness)’ 혹은 비즈니스 로직을 이동시킵니다. 따라서 여타 서비스 및 시스템을 호출하기 위해 필요한 비즈니스 로직 및 네트워크 커뮤니케이션 로직은 마이크로서비스 자체의 일부분으로써 실행됩니다.

마이크로서비스 상호작용 및 통합은 두개의 메인 통합 스타일을 기반으로 구축될 것 입니다.: 액티브 컴포지션, 리액션 컴포지션.

11.1 액티브 컴포지션

마이크로서비스 실행을 자세히 들여다보면 표 10에서와 같이 다양한 종류의 서비스를 확인 할 수 있습니다.

대부분은 비즈니스 로직으로 구성되어 있으며, 네트워크 커뮤니케이션 로직은 적거나 거의 없는 촘촘하고 독립적인 서비스가 있습니다. (외부 서비스 종속 없음) 이러한 서비스들은 아토믹/코어 서비스로 분류할 수 있습니다.

아토믹/코어 마이크로서비스는 매우 촘촘히 조직되어 있어 비즈니스 기능성에 따라 직접적으로 매핑이 불가능한 경우가 종종 있습니다. 따라서 특정 비즈니스 기능은 다수의 아토믹/코어 서비스의 구성이 요구될 것입니다. 하나의 마이크로서비스는 동기화 요청-응답 메시지 스타일로 다수의 다운스트림 서비스를 호출하여 복합 서비스를 만들 수 있습니다. 이러한 서비스를 액티브 컴포지션으로 부릅니다. 이러한 서비스들은 복합 혹은 통합 서비스로 명명되며 라우팅, 변경, 오케스트레이션, 복원력 및 안정성 패턴과 같은 SOA에서 가지고 있는 ESB 기능의 특정 부분이 실행됩니다.

이러한 비즈니스 기능은 매니지드 관리 API로 사용자에게 노출되며, 선택된 일단의 복합 서비스 혹은 아토믹 서비스의 일부분이 API 서비스/에지 서비스를 활용하는 API로 노출될 것입니다. 이러한 서비스는 특별한 종류의 복합 서비스로 API버저닝, API 보안 패턴, 쓰로틀링, 유료화 API 컴포지션 생성와 같은 기본 라우팅 역량을 적용합니다.

11.2 리액티브 컴포지션

액티브 컴포지션 스타일로는 복합 서비스가 완전히 자율적으로 운영될 수 없습니다. 이러한 서비스는 API 혹은 외부 지향 서비스와 상호작용하기에는 좋으나 대부분 마이크로서비스 기반 애플리케이션의 내부 비즈니스 로직은 서비스가 비동기 이벤트-기반 커뮤니케이션을 통해 실행할 수 있습니다. 이와 같은 인터-서비스 커뮤니케이션 구축 스타일은 리액티브 컴포지션이라고 합니다. 표 11에서 볼 수 있듯이, 마이크로서비스는 ‘덤 파이프’의 역할을 하는 중앙 혹은 분산 이벤트 버스/브로커를 사용할 수 있고, 모든 스마트는 프로듀서 마이크로서비스와 사용자 마이크로서비스에 존재합니다.

이벤트 버스는 Kafka, AMQP, NATS.io.와 같은 기술들을 통해 실행됩니다. 유스 케이스에 따라 이벤트 버스를 지원하는 인-메모리 혹은 지속 레이어를 선택할 수 있습니다.

11.3 하이브리드 컴포지션

대부분의 마이크로서비스 실행 애플리케이션에서 액티브 컴포지션과 리액티브 컴포지션 모델을 혼합하여 사용합니다. 표 12에서도 볼 수 있듯이 상호작용 서비스 및 외부 지향 서비스의 경우 액티브 스타일로, 다른 전달 보장을 요구하는 내부 서비스 커뮤니케이션의 경우 리액티브 스타일로 실행할 수 있습니다.

API레이어는 컴포지션 레이어 위에 앉혀지며, 다른 외부 및 모노리틱 서브시스템은 컴포지션 레이어를 통해 통합될 수 있습니다.

11.4 API 관리

마이크로서비스는 게이트 웨이를 통해 노출될 수 있고, 모든 API 관리 기술은 해당 레이어에 적용될 수 있습니다. 보안, 쓰로틀링, 캐싱, 유료화, 모니터링 같은 모든 기타 요건들의 경우 게이트웨이 레이어에서 실행되어야 합니다. API 게이트웨이 레이어는 다수의 게이트웨이 인스턴스들로 분리되는 경우가 많은 반면 (API당 할당되는 마이크로 게이트웨이) API 관리 컴포넌트는 중앙에 남아 있습니다. API 게이트웨이 레이어에 놓을 비즈니스 로직을 최소화하는 것이 중요합니다.

12. 서비스 메쉬

서비스 간 커뮤니케이션 관련 기능을 기초부터 실행하는 것은 악몽 같은 일입니다. 비즈니스 로직에 집중하는 대신에, 서비스 간 커뮤니케이션 기능을 구축하는데 많은 시간을 사용해야 할 것입니다. 다른 언어에 따라 동일한 노력을 배로 기울여야 하기 때문에 마이크로서비스 구축을 위해 다양한 기술을 사용하는 것은 더욱 최악입니다. (예, 서킷 브레이커와 같은 경우, Java, Node, Python에서 실행해야 합니다.)

대부분의 인터-서비스 커뮤니케이션 요건이 모든 마이크로서비스 실행 간 꽤 일반적이기 때문에 이러한 테스트를 각기 다른 계층에 오프로딩하도록 하여, 서비스 코드를 독립적으로 유지할 수 있도록 합니다. 이러한 경우 서비스 메쉬가 사용되는 것입니다.

서비스 메쉬는 인터-서비스 커뮤니케이션 인프라입니다. 하나의 마이크로서비스가 다른 마이크로서비스와 직접 통신 하지 않는다는 것을 의미합니다. 모든 서비스 간 커뮤니케이션은 서비스 메쉬 (혹은 사이드카 프록시)라고 불리는 소프트웨어 컴포넌트 상에서 이루어 집니다. 서비스 메쉬는 복원성 및 서비스 검색과 같은 네트워크 기능을 위한 빌트인 서포트를 제공합니다. 따라서 서비스 개발자는 비즈니스 로직에 더욱 집중할 수 있고, 네트워크 커뮤니케이션 관련된 대부분의 작업은 서비스 메쉬가 대신할 수 있습니다. 예를 들어 마이크로서비스가 다른 서비스를 호출할 때 서킷 브레이킹에 대하여 더 이상 걱정하지 않아도 됩니다. 이미 서비스 메쉬의 일부분이기 때문입니다. 서비스 메쉬는 언어에 구애받지 않습니다. 메쉬 프록시 커뮤니케이션에 서비스를 제공하는 마이크로서비스는 HTTP.1/2/x 및 gPRC와 같은 표준 프로토콜 위에 항상 존재하기 때문에 어떤 기술을 사용해서 마이크로서비스를 작성해도 해당 서비스 메쉬를 통해 잘 작동 됩니다.

다음은 서비스 메쉬가 제공하는 주요 기능들입니다.

• 인터서비스 커뮤니케이션을 위한 회복성: 서킷 브레이킹, 재시도 및 타임아웃, 장애 인젝션, 장애 처리, 로드 밸런싱, 시스템 대체작동
• 서비스 디스커버리: 서비스 레지스트리를 통해 서비스 엔드포인트 검색
• 라우팅: 프리미티브 라우팅 역량, 서비스의 비즈니스 기능관련 라우팅 로직 없음
• 관측가능성: 매트릭스, 모니터링, 분산 로깅, 분산 트레이싱
• 보안: 전송수준보안 및 키 관리
• 접근 통제: 단순 블랙리스트 및 화이트리스트 기반 접근 통제
• 배포: 컨테이너를 위한 네이티브 서포트, 도커 및 쿠버네티스
• 인터서비스 커뮤니케이션 프로토콜: HTTP1.1, HTTP2, gRPC

서비스 메쉬는 서비스 비즈니스 로직으로부터 완전히 독립적이라는 것을 이해하는 것이 중요합니다. 네트워크 관념으로 이해할 수 있습니다. 자신의 서비스 비즈니스 기능 실행은 자신의 책임입니다. 따라서 분산 ESB가 절대 아닙니다. (이 주제에 대한 자세한 사항은 [1] 및 [2] 참조)

13. 트랜잭션

마이크로서비스에서 트랜잭션 서포트는 무엇일까요? 사실 여러 마이크로서비스에 분산된 트랜잭션을 지원하는 것은 복잡한 일입니다. 마이크로서비스 아키텍처 서비스 간 트랜잭션 없는 조화를 촉진할 수 있습니다.

즉 하나의 서비스가 완전히 독립 적이며 단일 책임 원칙에 기반하고 있다는 의미입니다. 따라서 대부분의 상황에서 트랜잭션은 마이크로서비스의 영역에만 적용 가능합니다. (즉, 다수의 마이크로서비스에 적용 불가능합니다.)

그러나 다수의 서비스에 분산된 트랜잭션이 요구되는 경우, 무슨 수를 써서라도 2단계 실행(2PC)을 피해야 합니다. 이러한 패턴은 SAGA 패턴을 도입해야 실현할 수 있으며, [1] 이는 각 마이크로서비스 체계에서 ‘보상 운영’ 을 활용합니다. 중요한 것은 하나의 마이크로서비스는 단일 책임 원칙에 기반하고 있으며, 하나의 마이크로서비스가 주어진 작업을 실행하지 못할 경우, 이를 마이크로서비스 전체의 장애로 간주한다는 것입니다. 그렇다면 모든 기타 (업스트림) 작업들은 이러한 마이크로서비스 각각의 보상 작업을 호출함으로써 무효화 할 수 있습니다. 마이크로서비스 간 트랜잭션 구축을 위한 SAGA 패턴 실현에 대한 더욱 자세한 내용은 [1]을 참고하시기 바랍니다.

14. WS02를 활용해 MSA 실현하기

MSA의 다양한 면을 실행하기 위해 WS02의 클라우드 네이티브와 100% 오픈 소스 기술을 활용할 수 있습니다.

마이크로서비스를 구축하기 위해 WS02에 의해 구동되는 Ballerina 프로그래밍 언어를 사용할 수 있습니다. 발레리나는 클라우드 네이티브 프로그래밍 언어로, 분산 애플리케이션 개발작업을 단순화하도록 설계되었습니다. 네트워크 상호작용, 네트워크 타입, 리질리언트 인터-서비스 커뮤니케이션, 데이터 통합, 관측가능성 및 클라우드 네이티브 에코시스템과의 통합에 대한 추상을 제공합니다. 따라서 발레리나는 다수의 마이크로서비스 (코어 서비스)의 컴포지션 (액티브 혹은 리액션)을 생성하는 서비스를 개발하기에 이상적입니다.

또한 WSO2 Micro Integrator 를 사용할 수 있는데, 직관적 그래픽 개발도구를 기반으로 하는 액티브 혹은 리액티브 컴포지션 패턴을 사용하거나 컨피규레이션 언어 (DSL)을 사용하여 마이크로서비스를 통합하도록 하는 클라우드 네이티브 런타임입니다. WS02 Micro Integrator는 성능이 입증된, 역전의 WSO2 Enterprise Integrator/WSO2 ESB 의 한 변형입니다. 따라서 통합 서비스 구축을 위해서 본인의 취향에 따라 Ballerina 혹은 Micro Integrator를 선택할 수 있습니다. (표 13) 또한 기존의 모노리틱 시스템과의 통합을 위해 센트럴 WS02 Enterprise Integrator를 사용할 수도 있습니다.

API 서비스 레이어 WS02 API Manager와 함께 실행 가능하며 WS02 Identity Server는 API 트래픽 보안을 위한 아이덴티티 제공자 혹은 주요 관리자로써 사용될 수 있습니다. 모든 WS02기술은 Docker, Kubernetes, Istio 서비스 메시와 같은 배포 기술 및 Prometheus, Grafana, Zipkin, Jaeger와 같은 관측가능성 도구와 함께 매끄럽게 통합합니다.

15. 결론

MSA를 어떻게 현대 기업의 IT 환경에 사용할 지 결정할 때 다음의 주요 사항들을 명심해야 합니다.

• 마이크로서비스는 만병통치약이 아닙니다. 기업의 모든 IT 니즈를 충족할 수 없기 때문에 기존의 아키텍처와 함께 사용해야 합니다.
• 컨테이너와 컨테이너 오케스트레이션 (Kubernetes) 을 추가로 사용한다면 , SOA를 꽤 적절하게 사용할 수 있습니다.
• 대부분의 기업은 자신의 IT시스템 전체를 마이크로서비스로 변환할 수 없을 것입니다. 대신에 MSA의 장점을 활용할 수 있는 비즈니스 활용 사례에 마이크로서비스를 사용할 것입니다.
• 기업통합은 절대 사라지지 않습니다. 서비스 통합에 있어 중심 통합 레이어는 없을 수 있지만, 통합 요건은 사라지지 않습니다. 오히려 모든 마이크로서비스 수준에서 실행 중에 있습니다. 모노리틱 서브시스템은 센트럴 버스/ESB의 형태로의 통합을 여전히 요합니다. 따라서 두 아키텍처 스타일의 하이브리드 혹은 공존이 더욱 실용적입니다.
• 모든 비즈니스 역량은 API 관리 기술을 활용하여 API로 노출시켜야 합니다.
• 비즈니스 로직이 아닌, 서비스 매쉬 레이어에 네트워크 커뮤니케이션 관련 복잡성을 어느 정도 분산할 수 있습니다.
• 기술 선택을 다변화하고 최상의 소프트웨어를 사용한 기술을 선택하는 것이 마이크로서비스 구축에 있어 중요합니다.

16. 참고자료

• [1] Microservices for the Enterprise
• [2] Application Integration for Microservices Architectures: A Service Mesh Is Not an ESB
• [3] https://martinfowler.com/articles/microservices.htm
• [4] 팀원 수나 회의에 참가하는 사람 수가 피자 두 판으로 식사를 마칠 수 있는 규모 이상이 되어서는 안 된다는 법칙을 가리켜 '피자 두 판의 법칙’(two-pizza team) 이라 한다. 아마존 창립자 제프 베조스의 팀 운용 전략.