[MSA] MSA 전환 과정

MSA 전환_과정

 

단기적인 성과를 빠르게 창출하기

 

1. MSA 전환이라는 의사 결정을 이끌어냈다면 이제는 MSA 구조 안에서 작지만 빠른 성공을 만들어내야 합니다.

• MSA 전환의 장점을 팀과 구성원들에게 증명하는 시간이 필요합니다.
• MSA 가치를 빠르게 증멸할수록 향후 MSA 전환에 필요한 여러가지 지원을 충분히 받을 가능성 커집니다.

2. 요구사항이 복잡하지 않으면서도 유저에게 필요한 신규 기능을 찾고, 그 기능부터 신규 서비스로 빠르게 구현

• 기존 로직에 대한 전환은 유저와 시스템 기준에서는 변하는 것이 없기 때문에, 기존에 없는 신규 기능을 먼저 개발하는 것이 좋습니다.
• 복잡하지 않은 요구사항으로 새롭게 만드는 서비스이기 때문에 빠른 개발과 런칭이 가능합니다.

3. 새롭게 구현된 신규 프로젝트는 추후 동료들이 이를 참고하여 개발할 것이기 때문에, 설계와 구현 측면에서 높은 수준으로 개발하는 것이 좋습니다.

 

 

점진적으로 전환하기

 

1. Monolithic 에 존재하는 기능들을 MSA 의 도메인으로 점진적으로 전환하는 방식을 추천

• 빅뱅 방식으로 한 번에 전환하는 것은 위험부담이 크고 속도도 느립니다.
• 주요 도메인의 주요 기능부터 점진적으로 이관하면 전환이 완료될 때마다 성과 측정이 가능하고 속도도 빠릅니다.
• 점진적으로 전환하는 것이 전환 과정에 참여하는 구성원들에게도 부담을 적게 줄 수 있습니다.

2. 스트랭글러 패턴(Strangler Pattern)을 활용

• 시스템 구조를 변경할 때 기존 시스템과 신규 시스템에 유입되는 트래픽을 조절하면서 점진적으로 신규 시스템 쪽으로의 트래픽을 늘려가는 과정을 스트랭글러 패턴이라고 합니다. 기존 시스템과 신규 시스템에 전달할 트래픽을 조절할 장치가 필요합니다. 이는 서비스 앞단의 proxy 가 될 수도 있고, 서비스 내부의 라우팅 로직이 될 수도 있습니다.
• 기존 시스템을 유지한 상태에서 전환을 위한 신규 시스템을 점진적으로 구현합니다. 이 후 외부 트래픽을 분산하여 기존 시스템과 신규 시스템에 전달합니다.
• 기존 시스템과 신규 시스템이 완전히 동일하게 동작함을 확인하면, 서서히 신규 시스템으로 전달되는 트래픽을 늘려갑니다.
• 전환 과정에서 이슈가 발견된다면 그 즉시 외부 트랙픽을 기존 시스템으로 돌리고, 발견된 이슈는 수정하여 다시 배포합니다.

3. 기존의 Monolithic 서비스에 대한 리펙토링을 충분히 하면 MSA 전환 과정에서도 영향을 미칩니다.

• 사용하지 않는 로직이나 도메인을 정리하면 MSA 전환 과정에서도 고려할 부분이 줄어드는 장점이 있습니다.

4. 처음부터 데이터베이스 분리를 고려하지 않아도 됩니다.(shared database)

• 온전한 MSA 전환에서는 각 서비스마다 각자의 데이터베이스를 가지는 것이 맞습니다. 하지만 점진적인 방식으로 전환을 진행할 때의 장점을 생각한다면, 우선 코드를 분리한 후 데이터베이스를 분리하는 방식이 좋을 수 있습니다.
• 한번 코드를 분리하게 되면 해당 코드가 사용하는 데이터가 무엇인지 확인할 수 있고 이를 기반으로 추후 데이터베이스 분리 작업도 수월하게 진행할 수 있습니다.

 

데이터베이스 분리

 

1. 진정한 MSA 를 완성하려면 각 도메인 서비스마다 자체 데이터베이스를 가져야 합니다.

• 하나의 DB를 여러 도메인 서비스가 함께 사용하는 구조를 유지한다면(shared database), 해당 DB 가 다운되거나 성능 상의 이슈가 발생할 때 관련 서비스 모두가 영향을 받는 문제가 발생하게 됩니다.(SPOF)

2. 모든 서비스가 함께 사용하는 기존 DB 에서 특정 도메인을 위한 일부 DB 분리 시 절차

 

1) 새로운 DB 로 대상 데이터를 일괄로 복제합니다.

• 기존 DB 와 신규 DB 를 바라보는 배치 로직을 구현합니다.
• 해당 배치는 양쪽 DB 를 보면서 createdAt, updateAt 과 같은 시간을 기준으로 지속적인 데이터 동기화를 수행하도록 합니다.
• 기존 DB 에서 데이터가 추가되거나 변경될 때, 신규 DB 에도 데이터 변경분이 반영되도록 합니다.

2) 기존 DB 와 신규 DB 양쪽에 데이터를 write 하도록 도메인 서비스를 개발 후 배포합니다.(dual-write)

• 도메인 서비스에서 데이터 변경 작업을 진행할 때, 양쪽 DB 에 모두 반영되도록 로직을 개발합니다.
• 이는 이후의 모든 트래픽을 신규 DB 로 온전히 처리하기 위한 사전 작업입니다.
• 배포 후 기존 DB 와  신규 DB 에 쌓이는 데이터를 비교하면서 전체 로직의 정합성을 체크할 수도 있습니다.

3) 신규 DB 에 쌓이는 데이터 정합성에 문제가 없다면, 도메인 서비스의 트래픽 처리는 신규 DB 에서 이루어지게끔 로직을 변경 배포합니다.

• 신규 DB에서 모든 트래픽을 처리하는 과정에서 이슈가 없다면 기존 DB 는 일정 시점 후에는 제거할 수 있게 됩니다.
• 이슈가 발견된다면 기존 DB 에서 트래픽을 처리하도록 빠르게 롤백하거나 유입되는 트래픽을 전환하면 됩니다.

 

현실적인 리팩토링

 

1. 기존 코드에서 외부 동작의 변경 없이 내부의 코드 구조를 개선하는 작업을 리팩토링이라고 합니다.

• 해당 시스템을 이용하는 외부에서는 리팩토링의 전과 후의 차이를 인식할 수 없어야 합니다.

2. 리팩토링 과정에서 필수적으로 필요한 것은 리팩토링 전과 후의 동작이 동일함을 보장하는 테스트 코드입니다.

 

3. 오래된 Monolithic 기반의 코드일수록 잘 작성되고 활용 가능한 테스트 코드가 없거나 많이 부족한 것이 현실입니다.

• 테스트 코드의 작성을 위해서는 해당 기능에 대한 input, output, process 등을 정확히 파악해야 합니다. 그렇기 때문에 해당 서비스에 대한 상세한 로그 확보가 필수입니다.

 

운영 환경에서 테스트하기

 

1. 운영 환경과 거의 동일한 테스트 환경을 구축하는 것은 Monolithic 에서도 쉽지 않지만 MSA 환경에서는 더더욱 어려운 과제입니다.

• 운영 환경과 완전히 동일한 테스트 환경을 만들어내는 것은 거의 불가능할 수도 있습니다.

2. 신규 feature 에 대한 기본적인 테스트를 완료했다면 곧바로 운영 환경에서 테스트를 진행하는 것도 좋은 방법입니다.

• 운영 환경에 배포했을 때 어떤 효과가 있는지 확인하는 유일한 방법은 운영 환경에서 테스트를 진행하는 것입니다. 다만 이것이 가능하려면 병렬 배포와 메트릭 기반의 모니터링, 트래픽 라우팅, 빠른 롤백 등이 가능하여야 합니다.

3. 운영 환경에서 신규 feature 를 테스트할 때에는 내부 구성원만 사용 가능하도록 하는 것도 방법입니다.

 

 

* 서버간 통신 메커니즘 정의

 

1.  MSA 는 네트워크로 연결된 서비스 간의 통신을 기반으로 운영되는 분산 아키텍쳐입니다. 

• 서비스 간의 통신 메커니즘에 대한 정의와 적용은 중요한 의사결정중의 하나입니다.
• MSA 의 컨셉을 생각한다면 서비스 내부의 기술과 구현보다는 서비스 간의 통신 구간에 좀 더 신경을 써야합니다.

2. 통신 메커니즘은 크게 동기식 요청 응답 방식과 비동기식 이벤트 방식으로 구분됩니다.

• 동기식 요청 응답 방식은 클라이언트가 서버에게 요청을 보내고 응답을 기다리는 패턴입니다.
• 비동기식 이벤트 방식은 이벤트 브로커를 통해 메세지를 비동기적으로 전달하는 패턴입니다.

3. 메시지 포맷으로 구분한다면 텍스트 기반의 포맷과 바이너리 기반의 포맷으로 나눌수도 있습니다.

• JSON 이나 XML 같은 텍스트 기반의 포맷
• gRPC 와 같이 통신 속도가 매우 빠른 바이너리 기반의 포맷

4. 통신 매커니즘과 메시지 포맷에 따라 각각의 장단점이 존재하는데 서비스에 따른 요구사항에 따라 각기 다른 선택이 가능합니다.

• HTTP API (Rest API)
  • 장점 - 단순하고 개발자들에게 익숙합니다.
  • 단점 - 요청과 응답이 동기식이기 때문에 API 호출 과정에서 양쪽 서버가 모두 실행 중이어야 합니다.
• gRPC
  • 장점 - 바이너리 기반의 메시지 포맷을 가지기 때문에 HTTP API 에 비해 통신 속도가 매우 빠릅니다. 프로토콜 버퍼를 통한 통신 과정에서의 데이터 타입을 명확하게 정의할 수 있습니다.
  • 단점 - 웹 브라우저와 같은 외부 클라이언트에서의 gRPC 사용은 충분히 지원되지 않고 있습니다. 학습 비용이 있습니다.
• 브로커 기반의 비동기 메시징
  • 장점 - 메시지 브로커에 메시지를 읽고 전달하기만 하면 되므로 서버 간의 정확한 위치를 알 필요가 없습니다. 메시지 브로커가 존재하기 때문에 메시지 처리에 대한 버퍼링이 가능합니다.
  • 단점 - 메시지 브로커에 대한 운영 경험이 필요합니다. 메시지 브로커가 다운되면 관련 서비스 전체에 장애가 발생합니다.