마이크로서비스 아키텍처(MSA) 도전과제들

12 September 2017 · 3 minutes read

마이크로서비스의 도전과제

마이크로서비스 아키텍처 도입시 마주하게 되는 도전과제들을 정리한다.

마이크로서비스의 경계 정의하기

가장 먼저, 애플리케이션의 논리적 도메인 모델과 그와 관련된 데이터에 집중해야 한다. 컨텍스트에 따라, 비슷한 용어로 보이는 엔티티가 서로 다른 의미를 가질 수 있다. 이러한 부분을 주의깊게 분석하면 경계를 나눌 수 있다.

여러 마이크로서비스의 데이터 조회하기

API Gateway

심플하게 여러 마이크로서비스의 데이터 집계 서비스로 조회한다. 그러나 시스템의 pain point가 될 수 있고 마이크로서비스의 자율성 원칙을 깨뜨릴 수 있다. (각 마이크로서비스가 강하게 결합될 수 있다는 것이다) 이를 피하려면 시스템의 버티컬한 영역으로, 혹은 비즈니스 영역 단위로 여러개의 세밀한fined-grained API Gateway 서비스로 구성한다.

CQRS with query/reads tables:

구체화된 뷰 패턴으로 구현할 수 있는데, 미리 읽기 전용 테이블에 비정규화된 데이터를 저장해두고 조회하는 방식이다. 쿼리 테이블과 클라이언트 애플리케이션의 화면과 일대일 대응을 함으로써 복잡한 SQL join (여기에서는 여러 마이크로서비스의 조회) 을 처리하지 않고 데이터 조회를 할 수 있다. 물론 이 방식은 최종 일관성eventual consistency을 반드시 받아들여야만 하는 점, 추가적인 개발이 필요한 점이 있다. 그러나 높은 확장성과 성능에 대한 요구사항을 충분히 충족하므로 고려해볼 수 있다.

Cold data in central databases

실시간 데이터가 필요 없는 복잡한 리포트나 쿼리의 경우, 마이크로서비스에서 트랜잭션에 사용하는 hot data를 cold data로 추출함으로써 접근할 수 있다. cold data는 일반적으로 빅데이터 기반의 중앙 저장소를 뜻하는데, 이를 적용하는 곳이 실시간 데이터가 필요 없는 경우가 맞는지 주의해야 한다.

위의 모든 방법에도 애플리케이션이 여러 마이크로서비스에 걸친 지속적인 집계 정보가 필요한 쿼리가 필요하다면, 마이크로서비스간 통합이 필요한 문제일 수 있다.

여러 마이크로서비스간 일관성 유지하기

서로 다른 마이크로서비스 간 데이터 CUD가 필요한 경우, 직접 데이터베이스에 접근할 수 없으므로 서비스를 통해 이루어져야 한다. 이런 경우 이벤트 기반의 메시지와 같이 비동기 통신이 필요하다. CAP 이론에 명시된것 처럼, ACID의 강한 일관성과 가용성 사이에서 하나를 선택해야 한다. 대부분의 마이크로서비스 기반 시나리오는 강한 일관성 대신 가용성과 높은 확장성을 요구한다. 하지만 최종, 혹은 약한 일관성을 계속 유지하는 기술을 통해 강한 일관성을 유지할 수 있다. 이것이 대부분의 마이크로서비스 기반 아키텍처가 접근하는 방식이다.

ACID 스타일이나 2단계 커밋 트랜잭션이 마이크로서비스 원칙을 위배하지는 않지만, 더 좋은 방법은 최종 일관성을 유지하는 것이다. 이는 이벤트 기반 통신과 게시-구독 시스템을 통해 해결할 수 있다.

여러 마이크로서비스 경계간 통신 설계하기

단순히 통신에 어떤 프로토콜 (HTTP, REST, AMQP, …) 을 사용할지 정하는게 경계간 통신을 나타내지 않는다. 대신 마이크로서비스를 어떤 스타일로, 어떻게 결합할지가 중요하다. 이런 결합 단계에 따라 장애가 발생했을 때 시스템에 영향을 미치는 정도가 아주 크게 달라질 수 있다.

예를 들어, A 라는 마이크로서비스의 HTTP API 호출시 다른 B, C, D API를 호출한다고 하면 이는 HTTP 호출 체인을 만들게 된다. 이는 다음과 같은 문제를 발생 시킬 수 있다:

따라서 마이크로서비스간 통신을 HTTP 호출 체인을 통해 처리한다면, 프로세스간 HTTP 기반으로 통신하는 모놀리틱 애플리케이션이라고 할 수 있다. 그렇기 때문에 마이크로서비스의 자율성autonomous과 탄력성resiliency을 높이려면 이러한 마이크로서비스간 요청/응답의 호출 체인을 최소한으로 사용해야 한다.

비동기 메시징이나 이벤트 기반의 통신, 혹은 HTTP 폴링과 같은 최초 HTTP 요청/응답 사이클과 독립적인 비동기 방식을 사용하는 것이 좋다.

참고자료

Updated 26 December 2019