조직은 시스템(반드시 정보 시스템이라기보다는 더 넓은 의미의 시스템)을 설계할 때 필연적으로 그 조직의 의사소통 구조와 일치하도록 만든다.
- 콘웨이의 법칙
컴파일러 제작에 4개의 그룹이 참여한다면 4단계 컴파일러를 얻게 될 것이다.
- 에릭 S. 레이먼드 "The New Hacker's Dictionary" 중에서
코로나19 사태로 온라인으로 인프라 스터디를 하면서 읽은 책이다. 원서는 Building Microservices: Designing Fine-Grained Systems인데 2015년 나온 책이다. 읽으면서는 약간 코드로 인프라 관리하기를 읽을 때와 비슷한 느낌을 받았다. 특정 기술을 다루지 않고 개념을 위주로 다루다 보니 깊게 들어가지 못하고 실용적이기보다는 원론적인 얘기를 많이 하고 있다.
자율적인 수명 주기를 가지면서도 함께 협업하는 수많은 작은 부품으로 구성된 응집력 있는 시스템이 되어야 한다.
도메인에서 경계가 있는 콘텍스트들을 발견했다면 공유되고 감춰진 모델을 이용하여 그것들을 여러분 코드 내에서 모듈로 모델링 하라. 이들 모듈의 경계는 마이크로서비스의 훌륭한 후보다.
오케스트레이션 방식은 오케스트라 지휘자처럼 프로세스를 안내하고 구동하는 하나의 중앙 두뇌에 의존한다. 코레오그래피 방식은 발레 무용수들이 자신의 역할을 알고 주변의 다른 무용수에 반응하는 것처럼 시스템 각 부분에 작업 내용을 알리고 세부 사항을 수행하게 된다.
특정 기술이나 프레임워크를 다루는 것보다 어렵다고 생각하긴 하는데 개발, 테스트, 모니터링 등 모노리식 시스템과 마이크로서비스 시스템이 완전히 다른 것도 아니고 뭔가 설명을 하려면 모노리식에 대한 이해도 필요하고 마이크로서비스에 대한 이해도 필요하기 때문에 모든 걸 다 설명할 수는 없고 설명하다 보면 이미 알고 있는 내용일 가능성도 있고 원론적인 얘기라 적게 다가올 수도 있다고 생각한다.
그런 면에서 혼자 읽었으면 가볍게 수긍하면서 넘어갔을 텐데 그룹 스터디로 한 덕에 각자 환경에서 마이크로서비스나 개발에 대한 고민이나 어려움을 들을 수 있었고 더 많이 생각해 보게 되었다.
마이크로서비스의 원칙
- 비즈니스 개념에 따른 모델
- 자동화 문화의 적용
- 내부 세부 구현의 은폐
- 모든 것을 분권화
- 독립적인 배포
- 장애 격리
- 매우 식별 가능
CI는 빠르고 신속한 변경을 위한 핵심적인 실천 사항이므로 CI 없이는 마이크로서비스를 향한 여정이 고통스러울 것이다.
CI에 관해 정말로 이해하고 있는지 테스트하기 위해 제즈 험블(Jez Humble)의 3가지 질문을 자주 사용한다.
1. 하루에 한번씩 메인 브랜치에 체크인하는가?
2. 변경을 확인할 테스트 집합이 있는가?
3. 빌드가 깨졌을 때 팀이 그것을 최우선으로 해결하는가?
때로는 자동화된 기능 테스트를 더 추가하는 것보다 릴리스를 보수하는 데 같은 노력을 쏟는 것이 훨씬 더 유익할 수 있다. 웹 운영 분야에서 평균 무고장 시간mean time between failure(MTBF) 과 평균 수리 시간mean time to repair(MTTR) 사이에 최적화에 대한 균형으로 언급된다.
책을 안 좋게 얘기한 것 같은데 꼭 그런 건 아니다. 서비스를 어떻게 나누고 보통을 모노리식 시스템을 먼저 겪기에 여기서 어떻게 개선해 나가면서 배포, 테스팅, 모니터링, 보안 등을 신경 써야 하는지가 잘 나와 있고 다양한 예시를 통해 가능한 방법을 보여주고 있어서 지금 마이크로서비스를 설계를 고민하고 있다면 접근 방법을 정리하는 데 도움이 될 것으로 보인다. 실제로 마이크로서비스는 모노리식보다 훨씬 더 많은 고민이 필요하고 안정화하는 데도 노력이 많이 필요하다고 생각한다.
더 느슨히 결합된 조직일수록 모듈화가 더 잘되어 있으며 결합도가 낮은 시스템을 만들어낸 반면, 더 강력히 결합된 조직의 소프트웨어는 모듈화가 덜 되어있다는 것을 발견했다.
변경을 조율하는 비용이 증가하면 '조율 및 의사소통 비용을 낮출 방법을 찾거나 아니면 아예 변경하지 않는' 두 가지 현상 중 하나가 발생한다. 후자가 바로 결국 거대하고 유지보수하기 어려운 코드베이스가 되는 방식이다.
마이크로서비스 중 하나가 다운되었을 때 전체 웹 페이지를 이용할 수 없게 된다면 우리는 틀림없이 오직 한 서비스만 사용하는 시스템보다 회복력이 떨어지는 시스템을 만든 것이다.
제프 딘은 WSDM 2009 컨퍼런스에서 발표한 "대규모 정보 수집 시스템 구축에 대한 도전"에서 10배 성장까지 고려해서 설계하고 100배 성장 전까지 재작성을 계획해야 한다고 강조했다.
나 같은 경우는 조직에 대한 얘기가 더 많이 와닿았다. 마이크로서비스를 만드는 큰 이유 중에 하나는 다른 조직 혹은 팀과의 커뮤니케이션을 줄이면서 협업을 하고자 하기 때문이라고 생각하기 때문에 이러한 부분을 설명한 10장 "콘웨이의 법칙과 시스템 설계"은 흥미로웠다. 어떻게 보면 조직과 시스템이 커지면서 계속 빠른 개발, 배포를 유지하면서 개선하려면 마이크로서비스를 설계하면서 현재 조직의 구성과 변화에 대해서도 같이 고민해야 하는 것 같다.
한번에 모든 것을 바꾸려는 빅뱅 접근법을 취할 필요는 없고, 이 과정을 천천히 조금씩 진행되는 것으로 인식해야 한다.
우선 모놀리식으로 시작하고 안정화되면 분해하라.
마지막으로 일단 모놀리식을 먼저 시작하고 점진적으로 개선하라는 부분은 원래도 동의하던 부분이라서 맘에 들었고 마이크로서비스 책임에도 저 부분을 강조하는 점이 좋았다.
Comments