[MSA] 마이크로서비스 마이그레이션

마이크로서비스는 목표가 아닌 선택사항이다.

마이크로서비스보다 더 나은 방안이 있는지를 고려해야 한다.

마이크로서비스를 만들때와 모놀리스 아키텍처를 MSA로 마이그레이션할때 필요한 내용을 알아보자.

1. MSA 선택 이유와 대안

1.1 팀 자율성 향상
 - 마이크로서비스를 도입하면 조직과 업무의 단위가 작아지게 되어 자율적(책임 분배)으로 팀을 형성할 수 있고 이로 인해 효과적인 업무와 협업이 가능
 - 다른 팀의 영향도가 줄어듦
 대안
 -> 마이크로서비스가 아니더라도 자율성(책임 분배)은 가능
 -> 오히려 일부의 소유권을 특정 팀에게 부여하는 것이 좋을 수도 있음

1.2. 시장 출시 시간 단축
 - 다른 변경에 대해 구애받지 않고 바로 배포가 가능
 대안
 -> 프로젝트의 전체 단계를 생각하면 배포만 빠르게 해서 되는 것이 아님(상황에 따라 배포를 한 번에 하는 것이 유리)

1.3. 부하를 다루기 위한 비용 효율적인 확장
 - 서비스 단위로 독립적으로 확장이 가능하여 효율적으로 비용 처리가 가능
 - 서비스별로 컨트롤이 가능하여 트래픽 대처에 용이
 대안
 -> 모놀리스 아키텍처의 구조에 따라 수평 확장이 더 유리한 경우가 있음
1.4. 견고성 향상
 - 문제가 발생하여도 시스템 전체를 중단할 필요 없음
 - 견고성은 네트워크, 장애 대응을 위한 설계가 필수
 대안
 -> 모놀리스 역시 견고성 향성을 시킬 수 있음
 -> 문제 발생 시 전체 시스템을 중단하여 조사하는 것이 더 이득일 수도 있음
1.5. 개발자 수 늘리기
 - 모놀리스의 경우 개발자 수가 늘어나면 오히려 문제가 더 생김(농사꾼이 많다고 벼가 빨리 익지 않는다.)
 - 마이크로서비스로 분할 되어 있으면 개발자 수의 비례하여 효과를 얻을 수 있음
 대안 
 -> 시스템의 규모가 크면 마이크로서비스로 분해 시 인력이 더 필요할 수 있음
1.6. 신기술 수용
 - 언어, 플랫폼에 구애받지 않아 신기술 적용에 유리
 대안
 -> 일부 기술의 수명이 종료될 시 모놀리스가 대응이 더 유리(ex 자바 구버전, 오라클 구버전 등..)
 

2. MSA 마이그레이션을 피해야 할 상황

2.1 불분명한 도메인
 - 경계를 잘못 잡으면 더 많은 비용이 소모됨
 - 다시 모놀리스로 병합하는 사례가 많음 -> 모놀리스 변경 후 도메인 파악->다시 마이크로서비스로 분해
2.2 스타트업
 - 서비스가 완전히 자리잡기 전에는 많은 변경이 일어나는데, 마이크로서비스보다 모놀리스가 대응이 유리함
2.3 고객 설치형 소프트웨어와 관리형 소프트웨어
 - 고객이 마이크로서비스를 직접 운영한다면 교육이 필요함
 - 고객의 기존의 시스템(모니터링)에 연동을 고려
 

3. MSA 마이그레이션에 유용한 방법론

존 코터 박사의 조직 변화를 위한 8단계 구현 방법이 있다.

 

3.1 위기감 조성
 - 성급한 마이크로서비스 전환을 강요로 현재의 시스템의 위기가 있는 듯이 조성해서는 안됨
3.2 혁신 추진체 구성
 - 변화를 추진하는데 필요로 하는 인원을 파악
3.3 비전과 전략 수립
 - 어떠한 목표(비전)와 어떠한 방법(전략)에 대한 합의가 필요
3.4 변화 비전 전달
 - 비전 공유(전달)의 적정선과 신뢰할 만한 변화를 제시
3.5 광범위한 조치를 위한 직원의 자율권 강화
 - 자율권 강화를 점진적으로 실행하여 전사적인 자율권을 강화
3.6 단기적인 성과 창출
 - 단기적인 성과로 탄력과 통찰력을 얻을 가능성이 높음
3.7 이익 통합과 더 많은 변화 추구
 - 향후의 새로운 발전을 위해 꾸준한 기술 학급, 타 부서와의 소통, 시도가 필요
3.8 혁신 문화의 정립
 - 변화를 공유함으로써 새로운 작업을 발견하고, 이를 통해 조직적인 마이크로서비스 지식과 새로운 변화를 찾을 수 있음
 

4. 점진적인 마이그레이션의 중요성

- 마이그레이션 시 분해 규모, 사용언어, 사용 플랫폼 등 변경할 대상의 우선순위를 결정하여 점진적으로 마이그레이션을 진행하는 것이 바람직함
- 실패를 줄이고, 실패의 영향을 적게 받음
- 단기적인 성과를 빠르게 파악

5. MSA 마이그레이션 기법

5.1 도메인 주도 설계

 도메인들을 경계 컨텍스트를 식별하여 명확하게 구분하는 것
1. 작업 범위
 - 기존 모놀리스 시스템을 전부 파악하기는 힘듦
 - 도메인을 충분히 파악하고 지속적으로 파악이 중요
2. 이벤트 스토밍
 - 기술 전문가와 비전문가의 협업으로 도메인을 정의하는 방식
3. 우선순위 지정을 위한 도메인 모델 사용
 - 작업의 난이도를 고려하여 분해할 시각이 필요

5.2 결합된 모델

- 분해 난이도와 이익을 산출하여 우선순위를 결정

6. 고려사항

6.1 변화의 드는 비용

1. 가역적 결정과 비가역적 결정
 - 가역적 결정은 결정을 되돌릴 수 있는 것이고 비가역적은 되돌릴 수 없는 결정
 - 마이크로서비스 마이그레이션에서는 가역적인 결정이 유리
2. 실험을 시도해볼 만한 곳
 - 마이그레이션에 앞서 좋은 설계를 위해 분석을 철저히 하는 것이 좋음

6.2 팀 재구성

1. 변화하는 구조
 - 관련된 기술을 기준으로 조직된 팀에서 서비스 중점의 자율적인 팀으로 변화
2. 만병통치약은 없다
 - 시스템, 조직 등에 따라 MSA가 적합할 수도, 완전히 필요 없을 수도 있음
3. 변화 일으키기
 - 변화해야 할 많은 요소들을 고려해야 함(팀 간의 협의 등)
4. 전문 기술 변경하기
 - 개발자들은 MSA에 맞는 기술 학습 필요