DB) 분산서비스를 종합하는 마이크로 어플리케이션 DB분할의 필요성

백준우·2022년 7월 6일
1

DB

목록 보기
8/8
post-thumbnail

1. 마이크로 서비스

1.1 마이크로 서비스 아키텍쳐 성공기준

1.2 마이크로 서비스 장점

1.3 마이크로 서비스일시 DB를 반드시 분리해야하는가?

1.4 각 마이크로 서비스 별로 독립적인 DB 구성시 주의사항

1.5 어플리케이션 아키텍처 측면에서 가장 고려해야할 부분


2. 분산 데이터분할(데이터 소유권)설계

2.1 모놀리스 어플리케이션 설계

2.2 데이터동기화


3. 마이크로 서비스로 분산된 DB조회

3.1 서비스간 독립된 DB 사용

3.2 데이터 공유방식

3.3 공통 마이크로서비스 활용

3.4 ReadOnly DB 활용


1. 마이크로 서비스

  • 모놀리식 어플리케이션에서 마이크로서비스 아키텍처로의 전환은 BIG BANG 방식으로 전환하는 TOP DOWN 방식을 여전히 선호하는 것이 국내 프로젝트의 실정이지만, 아키텍처 사상의 변화는 커버넌스 측면은 물론 어플리케이션의 구조적인 변화가 크게 발생하기 때문에 옳바른 전환 방식이라 할 수 없다
  • 리스크를 최소화하며 마이크로서비스로 전환해 나가기위해서는 백엔드 → 데이터베이스(데이터) → 프론트엔드 순으로 점진적인 변화를 가져가는 것이 효과적이다.

1.1 마이크로 서비스 아키텍쳐 성공기준

- RESTful API 적용
- 독립적인 배포가 가능하나 결합도가 낮은 프로젝트
- 클라우드가 적용된 확장성, 가용성이 확보된 프로젝트
- 자동화된 배포 체계가 갖추어진 프로젝트
- DevOps 조직체계를 적용한 프로젝트

1.2 마이크로 서비스의 장점

- 서로다른 서비스들을 각기 다른언어로 개발가능
- 쉬운 Integration과 automatic deployment
- 쉽고 이해하고 수정가능한 코드들=>새로운 인원 발생시 생산성 향상
- 최근 기술을 빠르게 도입 가능합
- 빠른 서비스 시작속도와 빠른 배포
- 기능 추가시 해당 서비스만 수정 및 배포 할 수 있음

TIP) 모놀리스 아키텍처에서 발생되는 문제점
1. 복잡한 코드와 관리의 어려움
2. Bottleneck이 될수 있는 배포
3. 변경에 대한 두려움
4. 부족한 주인의식
5. 연쇄 실패
6. 확장의 어려움 

1.3 마이크로 서비스일시 DB를 반드시 분리해야하는가?

- 초기부터 데이터를 구분할 필요는 없다. 
- 초기는 아케텍쳐 적용을 프로젝트를 시작하는 시점에서 데이터베이스를 분리하는것은 위험도가 높아짐(프로젝트 실패시 부담해야할 리스크가 커짐)
- 장기적 관점을 볼시 점진적 이행이 가능한 형태로 데이터베이스분리는 중요

1.4 각 마이크로서비스 별로 독립적인 데이터베이스를 구성할 경우 주의사항

- 비용 : 데이터베이스의 물리적 노드 증가에 따른 비용 증가. 오픈소스 DB시 구축/운영 인력 증가.
- 성능 : 호출 홉 증가에 따른 성능 저하. 데이터 전송에 따른 성능 저하.
- 인력 : 기술셋 확장에 따른 지원인력 증가.
- 모델링 : 마이크로서비스 인터페이스 모델링, 데이터베이스 모델링(테이블 분할 설계등)

1.5 어플리케이션 아키텍처 측면에서 가장 고려해야 할 부분

어플리케이션 아키텍처 측면에서 가장 고려해야 할 부분은 바로 서비스 간 데이터의 동기화 측면이다. 
- 조인쿼리: 모놀리식 어플리케이션 내 조인쿼리에 대응하기 위한 동기/비동기 처리호출 설계
- 트랜잭션 관리: 분산 트랜잭션 관리를 위한 이벤트 처리설계
- API증가: 데이터 호출 증가에 따른 API설계
TIP) 모놀리식 아키텍쳐 : 마이크로 아키텍쳐의 반대되는 개념으로 전통의 아키텍쳐로 주요 특징으론 내부요소의 의존성이 강함

2. 분산 데이터분할(데이터 소유권) 동기화 설계

2.1 모놀리스 어플리케이션 설계

- 아래 그림은 모놀리스 어플리케이션에서 고객DB를 분리하여 관리하는 예시이며 아래와 같은 문제점이 발생한다.
1) Foreign-key constraints
2) 분산트랜잭션 환경에 따른 데이터 정합성 관리 문제

2.2 데이터동기화

- 데이터베이스가 분할 되었을 경우 데이터 동기화가 필요한 상황들이 발생하게 된다. 
- 회원정보를 관리하기 위함이나 병행운영하는 서비스일 경우

2.2.1 데이터 동기화 패턴

1) 양방향 쓰기

  • 양쪽에 동일한 CUD가 발생하기때문에 적합성 유지가 간편하지만 네트워크 비용이 2배로 발생한다.
  • DB별 성능차로 인한 타이밍 이슈를 해소하기 위해 R(Read)의 경우 양쪽 DB 중 한쪽을 선택하는 것이 좋다. 나머지 DB는 장애 시 FailOver 용도로 활용할 수 있도록 Read 권한을 제어한다.

2) 단일 DB쓰기 방식

  • 단방향 쓰기는 양쪽 DB간 데이터 동기화를 위한 별도의 수단이 필요함
  • 일반적으러 가장 선호하는 방삭
  • 단방향 쓰기를 통해 높은 트랙잭션 실패에 유연히 대처가 가능함

3) FullMesh 방식

  • Read/Write를 모놀리스와 마이크로서비스가 모두 데이터에 액세스하는 방식이다.
  • 이 패턴이 작동하려면 모놀리스와 마이크로서비스 모두 데이터베이스 전체에서 적절한 동기화를 보장해야 한다.
  • 둘 중 하나가 잘못되면 문제가 발생할 수 있다.

3. 마이크로 서비스로 분산된 DB조회

  • 마이크로 서비스를 위해서는 DB를 분리할 필요성에 대해 언급하였다. 이번엔 DB를 분리한뒤 조회를 하는 방식에 대해 설명하겠다.
  • 테이블 설계는 데이터를 정의하는 측면에서 어플리케이션과 인터페이스가 정의된 후 가장 후순으로 진행하게 된다.

3.1 서비스간 독립된 DB 사용

  • 각 서비스가 소유한 자체 DB를사용하는 방식
  • 데이터베이스를 분할하는부분은 힘들지만 대부분의 고객이 원하는 방식
  • 신규 서비스에 적합한 설계 방식

3.2 데이터 공유방식

  • 완전 분리가 아닌 서비스당 2개 이상의 DB에 접근하는 방식을 택할 수 도 있다.
  • 그중 서로다른 독립적 DB를 가지고 있을시 View를 활용하여 결합도를 낮출 수 있다.
  • 위 그림은 타 서비스의 DB에 직접 조회하는 방식이다. 이경우 서비스간 결합도가 높아지는 문제점이 발생할 수 있다.
  • 만약 고객DB의 변경사항이 생기면 타 서비스의 변경된 데이터또한 동기화를 해야할 필요성이 있다.
  • 위 그림처럼 타 서비스가 고객DB에 직접 커넥션 하는게 아닌 고객DB의 View를 바라보도록 한다.
  • 이를 통해 View가 유지되면 고객DB의 변경이 자유로울 수 있으며 불필요한 데이터를 은닉할 수 있다.
  • 그림을 보면 고객DB 내의 PW,Account Num을 타서비스로부터 보호 할 수 있으며 데이터 변경에 자유성이 있는것을 확인 할 수 있다.
  • View 단점으로는 View가 Schema가 분리되더라도 동일한 데이터베이스내에 존재해야한다는 점이다. 즉, 타서비스의 결합도는 낮출 수 있지만 여전히 같은 DB내에서 발생한다는 점이 있다.

3.3 공통 마이크로서비스 활용

  • 각기 다른 서비스의 DB를 운용하면서 공유하는것도 좋은 방법이지만 이를 구현하는건 어려움이 따른다.
  • 그에따라 하나의 공통 서비스를 생성하고 이를 통해 일괄적으로 관리하는 방법이 있다.
  • 위 그림처럼 3가지 서비스가 각각 하나의 DB에 저장되고 상호 공유되어야 하는 데이터를 공통서비스 내 공통DB에 저장한다
  • 공통서비스는 Front 서비스에게 공통 데이터를 직접 액세서 할 수 있도록 엔드포인트를 제공하고, 마이크로서비스 간에는 공통 데이터 또는 공유 데이터를 조회할 수 있는 API를 제공한다.
  • 고객/계좌/이체(호출자) 서비스는 DB에 직접 액세스 하지 않고 API를 호출하여 결과를 전달 받는 방식으로 구현한다.

3.4 ReadOnly DB 활용

  • ReadOnlyDB라는 별도의 DB를 만들어 데이터를 조회만 가능토록 하는것이다.
  • 계좌 서비스는 고객서비스에 필요한 데이터가 있어서 API를 호출한다. 이때 고객DB에 변경된 데이터는 ReadOnlyDB에 복제되며 ReadOnlyDB에 접근하여 데이터를 조회 할 수 있다.
  • 하지만 ReadOnlyDB를 운영하면서 변경된 데이터 복제는 타이밍 이슈가 발생 할 수 있다.

참고

향후 계획

  • 마이크로서비스의 물리적/논리적분리에 대해 학습할 예정
  • 분리된 데이터베이스의 Schema는 어떻게 적용하는지(CASCADE 유무) 학습할 예정
  • 분산된 서비스의 트랜잭션을 관리법 적용
profile
이게 되네?

0개의 댓글