Micro Service Architecture
마이크로서비스 처럼.
유사하게 분산 서버로서 구성 후 느낀 점은 아래와 같다.
개인적인 생각이며, 훌륭한 구성원들이라면 문제 없겠지만, 그게 아닌 어설프게 시도하려 할 때는 한번 쯤 읽어보셨으면 좋겠다.
(꽤 오래전에 작성했었는데, 내용이 어디갔지 ?_?)
23.01.02
마이크로서비스의 규모는?
- 개발자가 다룰 수 있을 만한 크기
- 성능(대기시간)이나 데이터 일관성을 저해하지 않을 정도의 규모(다른 마이크로서비스에 저장된 데이터와 SQL 저장된 데이터와 외래키를 맺는 것은 더 이상 당연한 것이 아니다.)
MSA를 하려면 우선 조직이 꽤 커야 한다고 생각한다.
나누는 건 팀 내 사람별로 나누는 것 보다 각 팀 별로 나눠서 바운더리를 가져가는게 맞다고 생각한다.
그 이유는 아래와 같다.
첫째로, 서버 통신 방법이 어렵다. (장애 처리 및 복구 로직 등을 다루기 까다롭다.)
http를 할 것인가 Message Queue를 할 것인가, 또 뭐 Message Queue를 사용한다면, Qos 레벨 몇까지 생각해볼 것인가 등을 선택하는 것도 어렵고, 또 연관된 서버들 중에서 오류가 났을 때 어떻게 빨리 장애복구 할 것인가를 구성하는 것도 꽤 어려움이 있다.
둘째로, 러닝커브가 증가 됨.
각 구성원들간 맡고 있는 도메인별로 서버를 나누게 되면 위에서 말했던 것처럼 다양한 언어로 서버를 개발 할 수 있는데, 이런 기술 같은게 정리되지 않은체 섞이게 되면 러닝 커브가 증가되고, 담당자 외에 다른 사람이 맡아서 처리할 때도 난감해 진다. 그리고 위에서 말했던 것 처럼 서버간 메시지 통신 방법을 정했던 것도 마찬가지로 증가되는 요소 중 하나 일 수 있다. (왜냐면 1가지만 쓰지 않을 수 있기 때문에)
셋째로, 관리 포인트 증가.
분산된 서버를 모니터링 할 때나, 장애 사항을 파악 할 때, 이런 것도 역시 관리 포인트가 증가가 된다. (물론 스타트업이라 구성원도 적고 기술부채도 상당한데 일정이 없으니 알고 있는 여러 시스템을 구축하지 못한체 진행되어서 그럴 수 있지만) 서버간 로깅이나 장애 추적하는 것도 상당히 버거워 진다.
따라서, 알려진(?) 쿠팡같은 곳이 팀 단위로 나뉘어져 있다면 가장 알맞는 형태일 거 라고 느끼게 되었고, 큰 단위로 나뉘는게 아니라면 MSA 보다는 모놀리틱한 구조가 더 적합하다고 생각했다.
언제나 그렇듯, 설레발 주도 개발로 겪는 시행 착오는 물론 나에게 경험치를 주지만, 서비스를 성공적으로 이루는 값진 경험 외에 오류로 밤을 지새우며 해결 방법을 고민하는 시간에 더 나의 열정을 쏟게 만든다.
이런 것에 주의해야 한다.