애자일은 작은 범위에서 시작합니다.
그렇게 하는 가장 중요한 이유는 적은 자원으로 학습, 검증, 개선 후 반복 실행 사이클을 돌기 위함 입니다.
단계별 전략이 필요 할 것이고, 단계별 실행 전략을 세워야 합니다.
또한 우리는 언제든 실행을 철회하거나 결정을 철회하고 더 나은 선택을 할 수 있음을 명심해야 합니다.
단계
- 전환 결정 단계
- 이 단계에서는 MSA로 전환할지 결정하고, 구성원간 합의와 설득이 필요한 단계입니다.
- 왜 해야하는지 근거를 찾아야 합니다. 근거는 대게 현재 격고 있는 어려움일 입니다.
- 학습 단계
- 이 단계에서는 MSA에 대한 지식을 쌓는 단계입니다.
- MSA를 적용할 수 있는지, 적용이 가능한지, 적용이 가능한지 등을 확인합니다.
- 실행을 주도 할 사람과 뒷받침 할 사람이 필요합니다.
- 리더의 강력한 의지와 구성원간 협의가 잘 될수록 실행이 쉬울 것입니다.
- 우리는 기존에 하던 업무가 있을 때문에 어떠한 비율로 리소스를 분배 할지 의사 결정이 필요합니다.
- 실험 단계
- 이 단계에서는 MSA를 적용해 보는 단계입니다.
- 작지만 의미 있는 프로젝트를 선택해야 합니다.
- 이 단계에서는 MSA 에 대한 학습 지식과 실제 실행 단계의 차이를 발견해야 합니다.
- 이러한 지식은 구성원에 전파되어야 합니다.
- 계획 수립 맟 실행 단계
- 2,3번을 반복해서 실행한 후 MSA 전환으로 결정했으면 본격적인 실행 계획을 수립해야 합니다.
- 실행에 필요한 인력과 비용을 계산하여 예산을 확보해야 합니다.
- 실행 단계에서는 학습과 실험이 매번 반복 될 수 있습니다.
탐침
탐침은 복잡하거나 불확실한 문제에 대해서 빠르게 작은 실험이나 작업을 수행하여 지식을 습득하는 것입니다.
경험
개인적으로 뭐든 직접 해봐야 이해가 잘 되어 MSA 전환을 위해 약간 규모가 있는 프로젝트를 진행하며
현재 프로젝트에서 서비스를 분리 했을 때 어떠한 제약 사항이 문제가 되는지 확인 하고 싶었습니다.
또한, 이 프로젝트의 데이터를 MSA에서 쉽게 마이그레이션 할 수 있는 것이 목표였습니다.
1.
아예 서비스를 독립적으로 만들고 싶었으나 독립적으로 만들기로 했을 때 기존에 사용하던 API 체계에서 신규 API 를 만들고,
현재 체계에 맞는 인증 시스템도 구현해야 했습니다.
그러나 시간을 고려 했을 때 이러한 사항까지 구현하는 것은 설계에 드는 시간 대비 결과가 아까웠습니다.
그래서 Django 앱만 새로 분리하기로 했습니다.
2.
Django 앱을 분리 하고 가장 먼저 결정해야 하는 것은 모델간 참조(FK), API 호출 문제입니다.
MSA 라면 API 호출을 하고, PK 와 FK 는 주고 받을 지언정 관리에 신경은 쓰지 않아도 됩니다.
그러나 앱만 분리했기 때문에 같은 서비스 내에서 API 사용해서 하는건 아무리 학습을 위한 것이라지만
눈가리고 아웅이 도를 넘어서 선택 할 수 없었습니다.
그래서 다음 결정 사항은 중간 테이블을 어디에 위치 시킬지, 참조 방향은 어떻게 할지 였습니다.
- 결론
- MSA 로 전환하면 DB 에서 Join 해서 처리 하는 것도 API 호출 조합으로 해야 하니 복잡해짐
- 조회 API 호출은 가급적 짧게 끝내야 하기 때문에 전체 반환은 하지 않아야 함
- 앱 분리만 하는 것을 통해 배운건 있지만 MSA 전환과는 전혀 다름
- 변경이 어려워지는건 DB, python 코드에서 참조 관계가 메쉬 형태로 되어서 어려운 것
이를 극복하기 위해서는 계층적 형태의 참조가 발생하도록 해야 함 - ETL 파이프라인을 통해 읽기전용, 특수 목적용 데이터 필요성을 느낌