[JPA] MSA 분리를 하면서 고려해봐야 할 사항들

최근에 부쩍 모놀리틱 아키텍쳐에서 MSA 기반의 아키텍쳐로 마이그레이션하는 기업들을 자주 볼 수 있습니다. 이 때, 가장 중요한 것은 RDBMS를 사용하느냐 NoSQL 계열의 DBMS를 사용하느냐에 따라 이런 기준을 크게 구분할 수 있습니다. 

그래서 이번 글에서는 MSA로 넘어가기 위해 어떤 과정들을 고민해보고, JPA를 사용하는 입장에서 어떻게 시도해봄직만 한지 구분을 지어보려고 합니다.

제 기준으로 위에서 얘기한 바와 같이 크게 2가지 부류로 나뉩니다.

• RDBMS(MySQL, Oracle, MSSQL, PostgreSQL 등)
• NoSQL(Redis, Cassandra, MongoDB 등)

여기서는 개발 환경이나 프레임워크, 언어에 따라 그 종류도 다양해질 수 있습니다. Java or Kotlin 계열에서는 JPA 혹은 QueryDSL, MyBatis와 같은 RDBMS SQL Connector를 주로 합니다. 관계형으로 이루어진 이러한 환경에서는 도메인이 서로간 의존성을 가질 수 있는 관계형으로 구성이 되어 있기 때문에 MSA를 구성하기가 상대적으로 NoSQL보다는 어렵습니다. 왜냐면 NoSQL에서는 엔티티 객체간 관계를 짓지 않기에 분리해서 개발을 해도 문제가 발생하지 않습니다. 하지만 JPA를 사용했을 때는 이야기가 달라집니다.

많은 회사에서는 DDD(도메인 주도 개발방법론)을 채택하여 사용하고 있습니다. 기본적으로 RDBMS를 사용했을 때 만들어지는 JPA 엔티티 간에는 부모 자식 관계라던지 조인 관계가 성립이 됩니다. A 테이블에서는 숫자값으로 사용하고 있던 것을 B 테이블에서는 아이디 값으로 사용할 수도 있습니다. 그렇기 때문에 도메인을 분리하고자 한다면 A, B는 다른 개발 환경의 코드에서 작성되더라도 함께 만들어져야 하는 구조입니다. 

기본적으로 NoSQL은 서버를 자유롭게 늘릴 수 있는 Scale Out과 수직(부모자식 관계), 수평(컬럼 추가 삭제)과 관계없이 자유롭게 늘릴 수 있는 형태로 구성되어 있기 때문에 확실히 MSA를 구성하기에 탁월한 데이터베이스 모델임에는 틀림이 없습니다. 그럼 여기서 RDBMS를 사용할 때 어떤 관점으로 MSA를 구성할 것인지 고려해봐야 한다는 문제가 다시 등장합니다. 

 

1. 최근에 추가될 연관성이 적은 엔티티부터 시도해보기

가장 확실한 것은 이미 만들어진 엔티티 모델을 전부 마이그레이션 하는 것보다, 새로운 기능이나 서비스에 추가되어야 하는 엔티티 클래스들을 먼저 추가하는 것입니다. 이들은 상위 데이터가 없어도 크게 문제가 없는 선에서 가능합니다. 

예를 들어 1번 서버에서 사용하던 엔티티와 API 명세가 아래와 같다고 가정합니다.

• A, B 엔티티가 존재하고, B는 A에 ManyToOne의 관계로 연결되어 있음 (즉, A:B=1:N)
• A는 최상위 부모 엔티티 객체임
• A, B를 연결하는 '조회 API' 및 '입력 API' 1개씩 존재함

 

이 때, C 엔티티를 추가하여 2번 서버에서 새롭게 도메인 분리를 하려고 하면 다음과 같은 방법이 있습니다.

1. 2번 서버에 올라갈 데이터에는 C 엔티티만 생성, 1번 서버에 B를 조회하는 API 생성
2. 2번 서버에 올라갈 데이터에는 B와 C엔티티를 모두 생성 (API 레벨도 생성)
3. 2번 서버에 A, B, C 모든 엔티티를 생성

1의 내용을 사용하여 개발을 진행한다면 네트워크 전송이 2번 진행되기 때문에 추천되지 않고, 2번의 경우 1번의 호출이 진행되지만 A 엔티티의 무결성을 보장할 수 없기 때문에 추천하는 방법이 아닙니다. 즉, 최적의 방법은 3번의 케이스로 수행되어야 하고, 손이 다소 가더라도 A~C의 데이터를 추가하고 1번 서버에서 A 엔티티를 참조하고 있는 코드를 삭제해주어야 합니다. 이렇게 진행하는 이유는 A, B 엔티티 클래스는 기존 서버에 존재하더라도 사용할 수 없는 코드가 되기 때문입니다. 

 

2. 혹은 아예 연관성이 없는 엔티티를 먼저 분리하기

때로는 연관관계나 의존성이 없는 메시지 전용의 엔티티, 테이블의 개수가 크지 않지만 조만간 크기가 증가할 수도 있는 엔티티를 먼저 분리하는 것이 좋습니다. 장애가 발생하더라도 전체 시스템에 무리나 영향을 주지 않는 클래스를 먼저 분리해두고, MSA가 이루어졌을 때 해당 도메인으로 분리를 하는 방법도 좋은 방법입니다. 

제가 생각해본 연관성이 크게 없을 것 같은 엔티티는 아래처럼 구성됩니다.

• 메시지 큐에 적재되어 구독형으로 입력 및 수정되는 엔티티
• 장애 로그 엔티티
• 배포 및 버전과 관련된 엔티티
• 서버 환경과 연결된 엔티티 (컨테이너 정보, 헬스 체크)
• 보일러플레이트 코드, Enum으로 관리가 가능한 엔티티

하지만 이는 독자적인 판단으로 진행하는 것보다는 우선적으로 CI를 같이 진행하고 있는 서버 개발자들과 같이 상의해본 후에 분리를 하는 것이 추천하는 방법입니다.

 

3. 인증과 관련된 엔티티를 분리하기 

인증 방법은 크게 세션과 토큰으로 나뉘게 됩니다. 여기서 토큰을 사용하는 것은 토큰 자체 내에 만료 시간이 부여되기 때문에 문제가 없습니다. 하지만 세션을 사용하게 된다면, 사용자 유효시간 저장소의 관리 서버에서 진행하기 때문에 서버가 중단되게 된다면 세션이 증발할 수도 있습니다. (즉, On Memory에 세션을 저장하는 경우를 말합니다. 보통의 경우 사용자 세션은 Redis와 같은 NoSQL 기반 캐시 메모리에 따로 관리를 하게 되어, 세션을 분리하는 것이 통상적입니다.)

인증의 이후에는 사용자 데이터를 핸들링하는 경우가 많이 없습니다. 가장 중요한 사용자 키값의 경우도 보통 세션 ID로 조회된 세션 값 또는 토큰 내에 관리합니다. 그래서 보통의 경우 MSA를 설계하고자 하기 전에 모놀리틱 아키텍처를 사용할 때에도 인증 서버를 기본적으로 구분하고 개발하는 경우가 많습니다.

 

4. 결제와 같은 안정성이 필수로 되는 엔티티를 분리하기

결제 모듈에 장애가 발생하게 되면, 사용자는 금액이 나감에도 불구하고 데이터가 쌓이지 않아 관리하는 차원에서 확인이 어려운 불상사가 발생할 수 있습니다. 물론, 로그를 확인해보면 유추가 가능한 부분이지만 실제로 관리자들은 개발자와는 달리 로그에 접근조차 하기 어렵기 때문에 엄연히 개발자의 책임이라고 볼 수 있습니다. 

그래서 결제 모듈은 상시 안정적이어야 하고, 문제가 발생해서 데이터 누락이 발생하면 안되는 엔티티입니다. 그래서 결제의 경우 입력이 가능한 Post 요청의 API 서버를 별도로 운영하고, 결제 취소도 모두 PostMapping 으로 이루어져 있게 됩니다. 서버 개발자의 경우 DBA가 존재하는 경우 운영 서버의 결제 데이터를 확인하지 못하도록 권한 분리를 진행하는 회사도 있습니다. 즉, 결제 데이터는 정말 값진 데이터라는 의미를 시사하는 바입니다. 

 

5. 계속 도메인을 분리해보는 경험으로 점진적으로 분리하기

이제 적으면 2단계, 많으면 4단계까지 도메인 분리까지 경험을 진행하고 난 뒤에는 어느 정도의 노하우가 생기게 됩니다. 처음부터 크게 목표를 잡고 모든 것을 동시에 진행하는 것은 사실 상 리스크가 크고 불가능한 경우가 많기 때문에 점진적으로 기존의 코드에서 분리가 가능한 부분을 먼저 파악하고, 그것들을 실행에 옮기면서 MSA 체계와 가깝게 분리를 하는 것이 중요합니다. 

응집도와 결합도, 그리고 단일 책임의 원칙인 SRP에 대해서도 MSA 분리를 할 때 자주 나오는 상황이기 때문에 알고 넘어가면 좋은 부분들도 아래에 적어두려 합니다.

• 응집도(Cohesion) : 같이 수정되는 기능들끼리 얼마나 잘 그룹화 되어있는지
• 결합도(Coupling) : 특정 기능을 수정하는데 같이 수정되는 기능들이 얼마나 되는지
• 단일 책임의 원칙 (SRP) : 클래스는 오직 하나의 책임만 가져야 한다는 원칙
• CQRS(Command and Query Responsibility Segregation) : 명령과 쿼리의 역할을 구분한다는 규칙, 즉 CUD(Command)와 R(Query)의 책임을 분리한다는 것
• 이벤트 소싱 : 애플리케이션 내의 모든 액티비티를 이벤트로 전환하여 이벤트 스트림을 별도의 데이터베이스에 저장하는 방식

 

결국 MSA로 이관을 하더라도 중요한 것은 안정성을 확보하여 서비스가 안정적으로 운영되는 것이라고 생각합니다. 험난한 과정이지만 성공 후에는 대공사가 마무리되는 듯한 기분을 느낄 수 있어 뿌듯할 것입니다 ☺️