Netflix내의 마이크로서비스가 데이터를 처리하는 방법 (Gutenberg)

 마이크로서비스 아키텍처에서는 단일 서비스에서 여러 목적지로 데이터 세트를 전파하는 것이 어려울 수 있다.

여기서 말하는 데이터 세트는 서비스 구성, 배치 작업 결과등의 모든 것을 의미 할 수 있다.

이러한 것들은 시간이 지남에 따라 종종 업데이트되어야 하기도 한다.

예를 들어서 Netflix에서는 수많은 A/B 테스트를 실행하고 있고 이런 테스트는 여러 서비스를 걸쳐서 수행되기에 테스트 담당자는 구성을 즉시 조정할 수 있어야 한다. 그리고 문제 발생시 이전 버전으로 롤백을 해야 한다.

다른 예는 머신 러닝 모델의 결과에 대한 배포이다. 머신 러닝 모델의 결과는 여러 팀에서 사용되지만, 모델을 담당하는 팀이 고가용성 서비스에 대한 관심이 높진 않다. 그리고 데이터 결과에 대한 활동들은 여러 팀이 활동하기에 중앙 집중화하는 것에 대해 가치가 있다고 판단된다.

하지만, 인프라 수준의 지원이 없다면 모든 팀은 성공을 위해 자체 솔루션을 구축하게 된다. 데이터 세트의 크기는 작게는 몇 바이트에서 많게는 몇 기가 바이트까지 다양한데 각 팀에서 이런 솔루션을 구축하는 것보다는 작업자가 빠르게 변경할 수 있도록 Tool을 제공하는 것이 중요하다.

Netflix에서는 Gutenberg라는 데이터 세트 Pub/Sub 시스템을 사용한다.

Gutenberg를 사용하면 특정 버전의 데이터 세트를 전파 할 수 있다. 데이터 세트의 각 버전은 변경이 불가능하며 데이터의 전체 뷰를 나타낸다. 이전 버전의 데이터에는 의존하지 않는다.

Gutenberg를 사용하면 Debugging 및 데이터를 이용한 머신 러닝 모델의 재학습과 같은 사용 사례에 이용될 수 있다.

데이터 모델

Gutenberg의 최상위 구조는 “Topic”이다. Publisher는 Topic에 게시하고 Consumer는 Topic을 기반으로 소비한다. Publisher가 게시하면 새롭게 증가된 “Version”이 생성된다. 각 Version에 대해서는 유지 개수 혹은 유지 기간을 설정할 수 있다.

각 Version에는 Meta data(Key/Value)와 데이터 포인터가 포함되어 있고, 데이터 포인터는 게시한 실제 데이터가 저장된 위치를 가리키는 특수 메타 데이터이다. 현재 Gutenberg는 직접 데이터 포인터와 S3 데이터 포인터를 지원하고 있고 직접 데이터 포인터는 일반적으로 데이터가 작을 때(약 1MB미만)에 사용되며 S3는 데이터가 클 때 백업 저장소로 사용된다.

Gutenberg는 지역, 응용 프로그램, 클러스터등 특정 Consumer 집합에 게시 범위를 지정할 수 있는 기능을 제공한다. 단일 클러스터로 데이터 변경 사항을 카나리아 방식으로 변경하거나, 변경 사항을 점진적으로 Roll-out하거나, 데이터 세트를 제한하여 어플리케이션의 서브 세트만 구독할 수 있도록 지원한다. Publisher는 특정 데이터 버전의 게시 범위를 결정하고 이전에 게시된 버전에 범위를 추가할 수 있다. 다시 말해서 최신 버전의 개념이 범위에 따라 달라진다는 의미이다. 두 응용 프로그램은 Publisher가 만든 범위에 따라 서로 다른 버전의 데이터를 최신 버전으로 바라 볼 수 있다. Gutenberg는 최신 버전으로 전파할 대상을 결정하기 전에 Consumer 어플리케이션과 Publishing된 범위를 일치시킨다.

사용 사례

Gutenberg의 사용 사례는 단일 Publisher에서 여러 Consumer에게 다양한 크기의 데이터를 전파하는 것이다. 데이터는 Consumer에 의해 메모리상에 저장되어 클라이언트 코드에 의해 Access되고 원자적으로 교환되는 “전체 Cache”로 사용된다. 이런 사용 사례는 느슨하게 그룹핑하여 구성할 수 있다.

예를 들어서 Cache 구성, 지원되는 장치 유형 ID, 지원되는 지불 방법 및 A/B 테스트 구성등

Gutenburg는 데이터의 Pub/Sub을 추상화하여 Publisher가 Consumer에게 영향을 주지 않고 응용 어플리케이션을 자유롭게 반족 할 수 있게 도와준다. 경우에 따라 Gutenberg의 관리 UI를 통해 Publishing이 수행되므로 팀에서 Publisher 기능을 전혀 관리하지 않아도 된다.

Gutenberg의 또 다른 사용 사례는 Version이 지정된 데이터 저장소이다. 이것은 과거 데이터를 기반으로 모델을 구축하고 훈련하는 과정을 반복하는 머신 러닝 프로그램에 일반적인 케이스이다. Gutenberg를 사용하여 계산 결과를 별개의 버전의 데이터 세트로 저장하고 전파하고 온라인 Use-case에서는 최신 Version의 데이터 세트를 사용하여 실시간 요청을 처리하고 “오프라인” Use-case에서는 동일한 Topic의 히스토리 데이터를 사용할 수 있다.

이런 점을 보면, 다들 이렇게 생각할 수 있다. 그냥 Kafka나 Pub/Sub 구조의 이벤트 솔루션을 사용하면 되지 않나? 중요한 점은 Gutenberg가 이벤트 시스템으로 설계되지 않았고 데이터 버전 관리 및 전파를 위해서 존재한다는 점이다. 업데이트를 요청하면 현재 많은 버전이 있다고 해도 최신 버전으로만 제공된다. 전통적인 Pub/Sub 구조의 이벤트 시스템은 크기가 작고 순서대로 소비되는 메시지에 적합하다. 그러나 Gutenberg는 데이터 세트에 대한 불변의 전체뷰를 게시하고 사용하도록 설계되었다.

아키텍처

Gutenberg는 gRPC 및 REST API가 포함된 서비스와 gRPC API를 사용하는 Java Client Library로 구성되어 있다.

Client

Gutenberg 클라이언트 라이브러리는 구독 관리, S3 업로드/다운로드, Atlas metric 및 Archaius properties 를 사용하여 작업을 처리한다. 서비스 검색에 Eureka를 사용하여 gRPC를 통해 Gutenberg 서비스와 통신한다.

Publishing

Publisher는 API를 사용하여 문자열, 파일 또는 바이트 배열을 게시한다. 데이터 크기에 따라 데이터가 직접 데이터 포인터로 게시되거나 S3에 업로드 된 후 S3 데이터 포인터로 게시 될 수 있다. 클라이언트는 요청자를 대신하여 Payload를 S3에 업로드하거나 S3에 이미 존재하는 Payload에 대한 메타 데이터만 게시 할 수 있다.

직접 데이터 포인터는 자동으로 복제된다. S3에 게시된 데이터는 기본적으로 게시자가 여러 지역에 업로드 하지만 요청자가 구성 할 수 도 있다.

구독 관리

클라이언트 라이브러리는 Consumer를 위한 구독 관리 기능을 제공한다. 이 기능을 통해 사용자는 특정 Topic에 대한 구독을 작성할 수 있고, 라이브러리는 이를 기반으로 데이터를 검색한다. 구독은 Polling Model로 작동되며 30초마다 서비스에 새 업데이트를 요청하여 마지막으로 전달 받은 버전을 제공한다. 문제 발생시 재시도하는 로직은 기본으로 탑재되어 있다.

Consumption APIs

Gutenberg는 저수준 gRPC API를 Wrapping하여 추가적인 기능을 제공하는 고수준 Client API를 제공한다. 예를 들어서 특정 Topic과 Version에 대한 데이터를 다운로드한다고 할때, Netflix Hollow에 연결된 구성 요소를 광범위하게 사용할 수 있다. 또는 특정 시간에 Topic의 최신 버전을 얻는 방법도 존재한다.

Client 탄력성 및 관찰성

Gutenberg는 Comsuming 서비스를 성공적으로 하도록 설계 되었다. 이를 염두해두고 Client Library는 Gutenberg 서비스와 통신 할 수 없는 경우에 대해 대비하여 구현되었다. HTTP 요청 재시도 횟수가 소진 된 후에 Client는 S3에서 Topic에 대한 fallback cache를 다운로드 하고 이를 기반으로 작동한다. 해당 Cache에는 업데이트를 적용해야 하는지 여부와 Meta 데이터 자체 또는 S3에서 데이터를 가져와야 하는 위치를 결정하는데 필요한 모든 정보가 포함되어 있다. 이를 통해 Client는 서비스를 사용하지 않고 데이터를 Fetch할 수 있다.

Client Library 제공의 이점중 하나는 인프라 전체의 문제 또는 특정 응용 프로그램의 문제를 경고하는데 사용할 수 있는 Metric 제공하는 기능이다. 이런 측정 항목은 Gutenberg에서 게시 및 전파를 모니터링하고 광범위한 문제가 발생했을 경우 이를 경고하는데 사용된다. 또한 일부 클라이언트는 이런 측정 항목을 사용하여 개별 게시 실패 또는 특정 Topic 사용 실패와 같은 오류에 대해서도 알려준다.

Server

Gutenberg 서비스는 gRPC 및 REST End-point를 공개하는 Governator/Tomcat 어플리케이션이다. 지속성을 위해서 글로벌하게 복제된 Cassandra Cluster를 사용아여 모든 지역에 게시 메타 데이터를 전파한다. Consumer 요청을 처리하는 인스턴스는 게시 요청을 처리하는 인스턴스와 별도로 확정된다. 일반적으로 게시 요청보다 Consuming 요청이 약 1000배 더 많기에 Publishing을 Consuming으로 부터 격리시킨다. 그 이유는 갑자기 Publishing이 급증해도 Consuming에 영향을 미치지 않기 위함이고 반대도 마찬가지이다.

Consumer 요청 클러스터의 각 인스턴스는 자체 메모리의 최신 게시에 대한 Cache를 유지 관리하여 몇 초마다 Cassandra에서 새롭게 갱신된다. 이는 트래픽을 Cassandra 클러스터로 전달하지 않고 클라이언트에서 오는 대량의 Polling 요청을 처리하기 위함이다.

여러 지역의 S3 Bucket에 데이터가 게시 된 경우에는 서버는 클라이언트의 위치에 따라 다운로드 할 클라이언트로 다시 보낼 Bucket을 결정한다. 이 경우 가장 가까운 Region에서 Bucket을 클라이언트에 제공하고 Region이 중단 된 경우 클라이언트가 다른 Region으로 fallback되도록 한다.

구독 데이터를 Consumer에게 반환하기 전에 Gutenburg는 데이터에 대한 일관성 검사를 선행한다. 검사가 실패하고 Polling 클라이언트가 일부 데이터를 사용한 경우 서비스는 아무것도 리턴하지 않으므로 사실상 사용 가능한 업데이트가 없음을 의미한다. Polling 클라이언트가 데이터를 사용하지 않은 경우에는 히스토리를 조회하고 일관성 검사를 통해 최신 데이터를 리턴한다. 클라이언트가 새로운 데이터를 Polling할 때 가장 최근에 게시된 버전과 관련된 메타 데이터가 복제된 Cassandra 계층에서 복제 지연이 발생하기 때문이다. 그리고 데이터를 가져올때 실패할 경우를 대비해 서버에서는 일관성 검사를 실행한다.

Data Resilient

Pinning

어플리케이션의 개발 환경에서는 배포가 잘못되거나 배포를 Rollback하는 정책이 필요하다. 데이터 중심의 아키텍처는 시간이 지남에 따라서 변경되는 데이터에 의해 작동되기에 이 부분은 매우 까다롭다.

Guternberg에서는 문제가 발생하면 마지막 안정버전의 데이터로 Rollback할 수 있는 방법이 필요하다. 이를 제공하기 위해서 Gutenberg는 Topic을 특정 버전에 고정하는 기능을 제공한다.

Pin은 최신 버전의 데이터를 무시하고 클라이언트가 해당 버전으로 Update하도록 도와준다.

따라서 관리자가 마지막의 안정버전을 모르더라도 빠르게 처리할 수 있다.

Incremental Rollout

새로운 코드를 배포할때는 카나리아 혹은 점진적으로 Rollout하는 방식으로 수행한다.

Gutenberg가 제공하는 기능중에 SPinnaker 파이프라인을 통해 데이터 게시를 Rollout라는 것을 제공한다. 특정 Topic의 경우 사용자는 자신이 게시 할 범위에 지연 시간을 구성하게 된다. 그리고 해당 Topic에 게시하게 되면 파이프 라인이 시작되어 동일한 데이터 버전이 각 범위에 점차적으로 게시되게 된다. 사용자는 파이프라인과 상호 작용할 수 있다.

Scale

Gutenberg는 지난 3년간 Netflix에서 사용되고 있고, 수만 가지의 Topic을 Production에 저장하고 있다. 이 중에 약 1/4이 지난 6개월 동안 한번 이상은 Publishing되었다. Topic은 1분에 수십번에서 몇달간 한번까지 다양하게 게시되었으며, 평균적으로 약 12시간 간격으로 초당 약 1~2번의 게시가 가능하다.

24시간 동안 적어도 한개의 Topic에 가입된 노드의 수는 6자리 미만이고, 이 노드중 하나가 구독하는 최대 Topic수는 200개이다.

향후 작업 계획

Polyglot 지원 (현재는 Java만 지원하지만, Node.js 및 Python을 지원할 계획을 가지고 있다.)

암호화 지원 (민감한 데이터의 경우 암호화 및 암호 해독 기능을 제공하여 사용 될 수 있도록 준비중이다.)

Topic 정리 (Topic을 게시하거나 사용하지 않는 사람이 있어도 명시적으로 삭제하지 않는한 Topic이 계속 유지되기에 Elasticsearch에서 색인화 작업을 거쳐서 Topic을 정리하는 시스템을 구축할 계획)

References:

• https://medium.com/netflix-techblog/how-netflix-microservices-tackle-dataset-pub-sub-4a068adcc9a

Read More

 마이크로 서비스(MSA) 전환시 알아야 할 것

어떤 서비스를 만들때에 Monolithic으로 만들어야 할지? Monolithic으로 만들고 Microservices로 구성해야 할지? 아니면 처음부터 Microservices로 구성해야 하는지에 대한 고민이 생긴다.

Microservices는 최근 급속히 발전하는 많은 기업이 소프트웨어 아키텍처로 이동할 것을 고려하고 있다.

Microservices 또는 Serverless로의 이동은 잘 만들면 금융, 소매, 마케팅, 데이터 분석 및 기타 여러 산업에서 효율성을 가져 올 수 있다.

위 그래프는 2017년에 도입되었거나 2018년도에 도입해야 하는 최우선 기술들을 표현한 그래프이다.

제품이나 서비스가 잘못 설계되었을 경우, Microservices를 적용한다고 하여 품질이 향상되지는 않는다. (그 이유는 똥을 분리해봐야 똥이기 때문이다.)

마이크로서비스를 적용해야 하는 경우

위의 똥 그림 때문이라도 이글을 읽는 당신은 마이크로서비스에 대해서 이해를 해야 한다.

Microservices 제품은 API를 통해 상호 작용하는 형태의 분리된 구성으로 소프트웨어를 설계하는 아키텍처에 대한 방법이다.

• 기능을 분리하는 동안, 여전히 일부 중복되는 기능과 코드가 존재한다.
• 주요 기능을 수행하는 것 이외에, 마이크로서비스는 API를 통해 다른 모듈과의 연결을 지원한다.
• 마이크로서비스는 개별적으로 개발이 될 수 있지만, 상호 의존성에 대한 부분이 존재하고 이는 출시 전에 테스트가 심도있게 되어야 한다. 특정 마이크로서비스의 일부 기능은 다른 마이크로서비스에서 사용할 수 있기에 특정 서비스가 업데이트되면 다른 서비스에 영향을 줄 수 있기 때문이다.

기술적으로 분리를 하더라도 마이크로 서비스는 여전히 상호간 의존하기 때문에, 이 의존성을 낮추기 위해서는 몇가지 기능을 복제해야 하는 상황이 발생할 수 있다.

이런 상황에 대한 부분은 아래와 같다.

• 제품의 일부가 개별적으로 재부팅 할 수 있어야 하며, 이는 복원력을 향상 시킬 수 있다.
• 많은 기능이 의무적인 상호 작용의 수를 줄이기 위해서 분리 되거나 하여 개발의 복잡성을 줄일 수 있어야 한다.
• 새로운 기능의 시장 출시 시간을 단축할 수 있어야 한다.

개발시에 위와 관련된 고민 사항들도 있지만, 운영의 복잡성도 상당하다는 점을 알고 있어야 한다.

즉, 기존의 Monolithic을 분할하게되면 운영의 복잡성을 증가한다는 것을 인지해야 한다.

그리고, 해당 기업의 IT부서가 이러한 시스템을 설계, 구현 및 유지 관리 할 수 있는 전문 지식을 가지고 있어야 한다.

만약, 이런 부분들이 고려되어 있지 않다면 마이크로서비스를 전환하는 것이 불행한 작업이 될 것이다.

Read More

마이크로 서비스(MSA)에서 분산 트랜잭션

 

위의 경우는 체크 아웃 요청에 대해 데이터베이스에서 트랜잭션이 생성된다. 각 비즈니스 단계에 대해서 데이터베이스에서 보장한다. ACID(Atomicity, Consistency, Isolation, Durability)로 알려져 있다.

아래는 마이크로 서비스에서의 커머스 시스템이다.

모놀리틱은 데이터베이스에 의존하여 트랜잭션을 처리하지만, 마이크로 서비스의 경우 데이터베이스에 의존할 수가 없다. 그 이유는 각 서비스마다 별도의 데이터베이스를 가지고 있기 때문이다.

마이크로 서비스에서 트랜잭션에 대한 문제

마이크로 서비스 아키텍처가 나온 후, 데이터베이스의 ACID 특성을 사용할 수 가 없다. 특정 로직을 처리하기 위해서는 여러 마이크로 서비스(여러 데이터베이스)에 걸쳐 있게 된다.

Atomic 트랜잭션을 어떻게 유지 할 것인가?

Atomic 트랜잭션은 모든 단계 중에 하나를 완료하는 것을 의미한다. 완료 되지 않은 작업(Inventory Microservice)에 대해서는 어떻게 롤백을 해야 하는지 고민이 되는 부분이다.

동시 요청에 대한 처리

Order 서비스가 완료된 후 Inventory 서비스의 정보를 보여줘야 하는데, Order가 완료 된 후 Inventory에 업데이트를 해야 하는지? 이렇게 되면 개발하는 개발자는 본인이 개발해야 할 부분외에 많은 것을 고민해야 하는 상황에 직면하게 된다.

가능한 해결책들

Two-Phase Commit

처리 방법을 준비 단계와 커밋 단계를 가지고 처리하는 기법이다.

연관된 모든 마이크로서비스에서 커밋을 준비하고 트랜잭션을 처리할 준비가 되었다고 코디네이터에게 통지를 해야 한다.

커밋 또는 롤백을 코디네이터에 의해 모든 마이크로 서비스에 전달된다.

아래는 성공 시나리오이다.

Transaction Coordinator는 글로벌 트랜잭션을 시작한다.

Order 서비스를 호출하고 OK를 받으면 Invventory 서비스를 호출한다.

즉, 모든 트랜잭션에 대한 부분을 Transaction Coordinator가 관여하게 된다.

아래는 실패 시나리오이다.

트랜잭션이 엮여 있는 서비스중에 하나라도 실패가 발생하게 되면, Transaction Coordinator는 롤백 프로세스를 수행한다.

Two-Phase commit의 장점은 아래와 같다.

• 두 단계 커밋이기에 속도가 느리다.
• Transaction Coordinator에 대한 의존성이 증가한다.
• 교착 생태가 발생 할 수 있다.

SAGA pattern

각 마이크로 서비스는 데이터를 업데이트 할 때마다 이벤트를 개시한다. 다른 서비스는 이벤트를 구독하고, 이벤트가 수신되면 데이터를 업데이트 하는 방식이다.

각 마이크로 서비스는 이벤트 버스를 통해 상호 통신하게 된다.

Choreographer에 의해 트랜잭션 이벤트를 생성하고 각 서비스에서는 이벤트를 수신하여 업무를 처리하는 방식이다.

Inventory 서비스가 실패하게 되면, Choreographer에 실패 이벤트를 전달하고 Choreographer는 Order서비스에 삭제 이벤트를 생성한다.

이 방식의 장점은 아래와 같다.

• 순서가 보장되지 않는다. (비동기 방식)
• 마이크로 서비스가 많을 수록 디버깅 및 유지 보수가 어려워진다.

결론

가장 좋은 대안은 분산 트랜잭션을 없애는 것이다.

위의 대안이 불가하다면, 아래의 마틴파울러가 얘기한 내용을 고려해 볼 수 있다.

단일체로 시작하고 점차 마이크로서비스로 분리하는 것.

하나의 결과에 대해 두개 이상의 시스템에 데이터를 갱신할 필요가 있을 때, Two-Phase commit 보다는 SAGA pattern이 조금더 바람직한 방법이다.

그 이유는 Two-phase commit은 확장이 어렵기 때문이다.

References:

• https://medium.com/@sohan_ganapathy/handling-transactions-in-the-microservice-world-c77b275813e0

Read More

마이크로 서비스(MSA)를 사용하지 않는 경우

본 글은 찰스 페발의 블로그의 글을 번역한 것이다.

굳이 마이크로 서비스가 필요하지 않는 상황에서도 “마법의 키워드”와 같이 마이크로 서비스를 꼭! 해야 한다는 상황에서 정말 그래야 하는지 고민해 볼 필요가 있다.

마이크로 서비스란?

마이크로 서비스에는 많은 정의가 있다. 일반적으로는 아래와 같이 요약된다.

• 마이크로 서비스는 구성 요소 설계 및 배치 아키텍처에 적용 되는 패턴이다.
• 서비스를 작게 유지하고 기능별로 그룹화 한다.
• 관심사를 분리하여 구현한다.
• 서로 자율적으로 분리되어 있어야 한다.
• 독립적 배포 및 버전을 조정하여 확장할 수 있어야 한다.

마이크로 서비스 패턴의 일반적인 구현은 다음과 같다.

주요 문제는 적용 가능한 패턴의 폭이 상당히 넓다는 것이다. 그렇기 때문에 마이크로 서비스를 선택하는 것이 최상의 옵션이 아닐 수 있다는 관점을 보려 한다.

마이크로 서비스를 구현하는 데에 있어서 절충점이 존재한다.

마이크로 서비스의 과제

1. 마이크로 서비스는 올바르게 설계 하기가 어렵다.

2. 기술적 복잡성이 포함되어 있다.

• API 수가 증가한다.
• Network bottleneck이 증가한다.
• 여러 서비스간 트랜잭션 관리가 어렵다.
• 분산 환경에서의 디버깅은 어렵다.

비즈니스 기능외에 기술적으로 고려해야 할 항목들이다.

3. 조직이 변경되어야 한다.

Conway의 법칙에 따라 Front/back end 개발자, 데이터 플랫폼 엔지니어, QA, 제품 관리자 및 운영팀이 단일팀으로 혼합되어 있다.

아래의 그림에서는 각 팀간 업무 우선순위가 다르기에 팀 간 종속성이 서로 충돌되거나 업무 지연이 발생할 것이다.

4. 마이크로 서비스의 개념 및 설계에 대한 경험과 이해가 부족한 경우

우리는 대부분 새로운 것을 배우는 것을 좋아하지만, 이런 상황은 실수에 대한 시간과 에너지가 필요하다.

5. 성숙되지 않은 스킬을 적용

일반적으로 사람들은 자신이 아는 것으로 대체하려는 습성이 있다. 자신이 알거나 가장 짧은 길을 가면서 복잡성을 피할 것이다.

성숙되지 않은 기술로 도배하면 각 구성요소간 연관된 부분, 복잡성을 이해하기도 어려울 것이다.

운영 및 디버깅의 복잡성으로 인해 효율성이 저하될 가능성도 있다.

하고 싶은 말

구축하려는 서비스에 명확한 도메인이 있고, 각 영역별 혼합된 형태의 팀을 구성할 수 있고, 팀내의 구성원이 기술에 대해 자신감이 있거나 경험이 있을 경우에는 마이크로 서비스로 갈 수 있는 가능성이 높다고 생각한다.

그렇지 않은 경우에는 역효과를 낳을 수 있다는 점을 명심해야 한다. K8S와 같은 컨테이너 플랫폼은 마이크로 서비스 아키텍처 혹은 마이크로 서비스 아키텍처 없이도 사용이 가능하다.

마이크로 서비스는 복잡한 분산 시스템 환경에서는 확실히 적합한 옵션이다. 하지만, 이것이 유일한 것은 아니기에 앞서서 언급한 것들을 고려하여 합리적인 선택을 해야 한다.

Read More

마이크로 서비스(MSA)의 경계

마이크로 서비스를 사용하면 이점을 얻을 수 있지만, 경험에 비추어보면 몇 가지 문제가 있었다.

영향을 최소화 할 수 있도록 도출된 문제를 인식하는 것이 중요하기에 여기에 몇 가지 적는다.

문제 중 하나는 마이크로 서비스의 경계를 잡는 일이다. 이것은 가장 어려운 작업이다.

마이크로 서비스 범위 설정

각각의 마이크로 서비스가 단일 책임의 원칙을 수용하는 구조라면 이 글을 쓸일이 없었을 것이다.

커머스 플랫폼에서 결제를 담당하는 서비스를 생각해보자.

처음에는 두 가지의 지불 방법 (카드와 바우처)만 존재했고, 이 두가지 방법이 동일한 서비스에서 구현되었다고 가정한다. 여기에 계좌 이체, Paypal등 다른 결제 방식이 추가된다고 하면 어떻게 해야 하는가?

미래의 요구 사항을 미리 알면 설계 시 혹은 경계 설정시 보다 현명한 결정을 내리겠지만, 현실은 그렇지 않다. 따라서 현재의 정보를 바탕으로 결제를 담당하는 서비스를 단일로 하기로 결정 했다고 가정해보자.

요구 사항 변경

시간이 지나서 Paypal 및 Apple Pay로 결제를 하기 위한 새로운 요구사항이 생겼다. 기존 서비스에서 이런 새로운 결제 방식을 구현 하면 서비스가 커지게 되고 의도치 않게 “많은 책임” 이 생기게 된다.

따라서 새로운 요구 사항은 결제 방식에 따라 다른 서비스로 결제할 수 있도록 책임을 분할하기로 결정을 하게 된다.

Paypal과 Apple Pay를 사용하는 결제는 별도의 서비스로 구현되지만 이미 결제를 구현한 기존 서비스는 어떻게 되는지 고민이 필요하다.

Paypal과 Apple Pay를 결제 방식에 따라 단일 책임을 정의했기에 기존 서비스는 위에서 결정된 접근 방식과 맞지 않게 된다.

결과적으로 기존 서비스를 새로운 서비스로 분할이 되어야 한다.

Monolithic 어플리케이션에서는 위의 예시가 비교적으로 간단한 코드 리팩토링에 해당되지만, 마이크로 서비스 아키텍처에서는 새로운 서비스를 옮겨져야 한다. (새로운 코드 저장소, 새로운 빌드 파이프라인, 환경 구성 등)

마이크로 서비스 이름 짓기

서비스의 범위가 변경되면 이름도 변경되어야 한다. 위의 예에서 원래 서비스의 이름이 “Payment”라고 가정하면, 결제 방식이 새롭게 정의되었기에 기존 이름은 더 이상 사용하기가 애매해진다.

“Paypal” 및 “Apple Pay”라는 서비스가 있는 공간에서 기존 이름인 “Payment”는 무엇을 의미하는지 고민을 하게 된다.

마이크로 서비스 경계에 대한 접근법

끊임없이 변화하는 환경에서 불가피하게 일부 서비스의 책임은 시간이 지남에 따라 재정의 될 필요가 있다. 마이크로 서비스의 크기에 대한 규칙으로 재정의 하긴 애매하다. 최적의 솔루션이 없다면 경험에 기반한 접근 방식이 최선의 방법일 수 있다.

1. 서비스의 일부가 자주 변경되면 서비스를 두 가지로 나눌 수 있다는 신호
2. 특정 테스트가 필요하거나 테스트 시간이 오래 걸리는 서비스는 다른 서비스를 방해하지 않도록 자체 서비스로 만드는 것이 좋다.
3. 데이터 베이스 또는 Queue와 같은 외부 리소스에 접근하는 코드도 서비스에 캡슐화 해야 한다. 서비스를 시작한 다음 외부와 전혀 관련이 없는 일부 기능을 사용하기 위해 외부 리소스를 사용하여 로컬 환경을 구성하지 않아도 되기 때문이다.

하나의 사례를 보자.

Eurostar라는 회사는 25년 동안 런던과 다른 유럽간 열차 티겟을 판매해오는 회사이다. 약 3년전에 그들은 Monolithic을 마이크로 서비스 아키텍처로 변경하기 위해 “검색”, “체크아웃”과 같은 새로운 서비스를 개발했다.

새로운 마이크로 서비스가 개발된 직 후, Eurostar는 기차표를 판매하는 비즈니스외에 여행사가 되고, 호텔 숙박 및 패키지 상품을 판매하기로 전략적으로 결정을 하게 된다. “호텔 검색”, “호텔 체크아웃”등의 새로운 서비스가 만들어졌다.

기존 기차표를 판매하던 “검색”, “체크아웃”등의 서비스의 이름이 적절하다고 생각되지는 않는다.

결국 비즈니스가 변하는 시기에 서비스를 다시 검토하고 리팩토링을 해야 할 시점이 오게 된다는 것을 인지해야 한다.

즉, 비즈니스가 변경되는 상황에서는 처음 수립한 마이크로 서비스의 경계가 적절하지 않기에, 상황 발생시 기존 서비스에 대해서도 리팩토링을 염두해야 한다는 것이다.

따라서, 마이크로 서비스 경계 설정시 그 당시의 정보를 기준으로 설정하고 이후 비즈니스 상황이 변경되면 리팩토링에 대한 접근법을 지녀야 한다.

Read More