서론
- MSA 개발을 통해 애자일 문화전파와 조직 변화를 기대했었다.
- MSA는 넷플릭스지 라고 생각했었다. 당연히 이럴것이다 하는 기대를 가지고 시작했다. MSA라면 당연히 ~~는 있어야지 하는 생각과 ~~까지는 없어도 된다 라는 생각을 가진 사람이 있었다.
본론
- 개발팀과 운영팀이 나누어져있는 우리 프로젝트 환경
- 주도적인 의사결정 안됬다 -> DevOps 환경에서 해야
- Polyglot
- 서비스 환경에 대한 최적의 언어, 환경, 기술을 선택하고자 했으나 현실적인 전체 기술역량, 준비가 안되있었다. 그래서 스프링, 자바로 통일
- DDD
- 용어 맞추는 게 중요하다고 생각. 용어가 다른 경우 커뮤니케이션 비용이 올라간다.
- Context Map : 저 서비스, 이 서비스 같은 모델을 쓰는 데 따로 빼서 같이 쓰면 어떨 까? 와 같은 상황에 그려보면 좋다. 그려보면서 고민에 대해 결정할 수 있다.
- ACID를 달성하기 어렵다.
- 분산환경이라서 달성 어렵다.
- 우리는 그래서 RabbitMQ를 활용하기도 했다. 레벨1 보장해준다.
- Config Server
- Cloud 비용이 엄청나게 올라간다.
- 테스트 환경은 로컬로 내렸다.
- 여러가지 인스턴스 올라가면서 비용이 많이 올라갔다.
- 빛은 생각보다 느리다 : Region이 US인 곳 3초 걸렸다.
- 서비스와 UI모델이 다르다.
- 서버 모델얘기 많이 하지만 프론트엔드 모델고민 하지 않는다.
- 서버 / 프론트엔드 모델 컨버팅 어디서 할거냐에 대한 고민 중요한거 같다.
- 다른 서비스 변경에 영향을 받는다.
- Consumer Driven Contract테스트 복잡하고 어려웠다. 커뮤니케이션 비용이 너무 많이 들었다.
- 적절한 취사선택 필요
- 로컬 테스트가 힘들다. 타 서비스를 로컬에 전부 띄우는 것은 힘들기에..
- 테스트 전략을 잘 구성하고 자동화하는 것이 중요하다.
- 데브옵스 역량이 높지 않아, 서비스가 죽어있는 경우가 있다.
- Orchestration vs Choreography
- MSA에서는 오케스트레이션 불가
- 서비스 체이닝 길어지면 디버깅 힘드므로, 응집도 높은 서비스 구성 필요
- 데이터를 제일 잘아는 서비스가 누구야? (Information Expert 패턴)
- 점점 거대해지는 Microservice
- 서비스 분리하는 것이 큰 용기가 필요했다. 계속 한 서비스에 기능 추가되게 됨.
결론
- 서비스 개발자 입장에서 어떻게 해야하나
- 기술 스택은 팀의 성숙도와 보유 기술에 따라 선택
- 아키텍쳐는 진행하면, 필요한 점, 부족한 점들을 캐치해가면서 바꿔가는 것이 좋을 것
- 서비스는 stateless, low coupling, high cohesion
