Medium의 MSA로 전환 이유
(부제: 왜? Medium은 Monolithic에서 MSA로 전환하였는가?)
Medium은 2012년에 Monolithic Node.js 앱으로 시작하였고, 2018년도초에 Microservice Architecture로 전환했다고 합니다. 맹목적으로 MSA로 전환하지 말고 필요에 의해서 전환을 강조하면서도, Medium은 빠르게 서비스를 하기 위해 Microservice Architecture를 선택했다고 합니다. Medium 기술팀은 개발 생산성을 대폭 향상시키고, 제품을 크게 개선하고 새로운 기술을 안전하게 테스트 하면서 잠재력을 보았다고 합니다.
원문출처 : https://medium.engineering/microservice-architecture-at-medium-9c33805eb74f
Microservice Architecture란?
Microservice architecture의 목표는 엔지니어링 팀이 제품을보다 빠르고 안전하며 고품질로 출하 할 수 있도록 돕는 것입니다. 분리 된 서비스를 통해 팀은 시스템의 나머지 부분에 미치는 영향을 최소화하면서 신속하게 반복 할 수 있습니다.
마이크로 서비스 아키텍처에서, 느슨하게 결합(loosely coupled)된 여러 서비스들은 함께 동작합니다. 각 서비스는 단일 목적(single purpose)에 중점을두고, 관련된 행위와 data들을 묶어 높은 응집력(high cohesion)을 가지고 있습니다.
Microservice의 디자인 원칙
- 단일 목적(Single Purpose) : 각 서비스는 하나의 목적에 초점을 맞추고 잘 수행해야합니다.
- 느슨한 결합(Loose Coupling) : 서비스간 서로에 대해 상세히 알필요가 없으며, 하나의 서비스를 변경하면 다른 서비스를 변경할 필요가 없습니다. 서비스 간의 통신은 public service interface를 통해서만 이루어져야합니다.
- 높은 결합력(High Cohesion) : 각 서비스는 모든 관련된 행위와 data를 캡슐화하여 관리합니다. 새로운 기능을 구축해야하는 경우 모든 변경 사항을 하나의 단일 서비스만 수정하도록 해야합니다.
왜 MSA로 변경했는가?
- Node.js 기반의 Monolithic App의 Performance 이슈를 개선해왔지만 비효율적으로 판단
- Monolithic은 긴급하게 수정하기 어렵지만(여러곳의 변화, 잘못된 커밋으로 배포 지연), Microservice는 복잡한 시스템과 분리되어 있어 기능개발에 집중하고 변경사항을 빠르게 생산
- Monolithic App은 여러 작업들을 고려한 리소스 격리 문제와 Scale up하기에 어려움
- Monolithic은 새로운 기술을 시도하기 어렵지만, Microservice는 각 서비스별로 서로 다른 기술 스택으로 구축되어 서로 다른 기술과 통합할 수 있어 최적의 도구를 선택할 수 있음
마이크로 서비스 전략
마이크로 서비스 아키텍처를 채택하는 것은 쉬운 일이 아니며 엔지니어링 생산성을 해칠 수 있습니다. 이 섹션에서는 입양 초기에 도움이 된 7 가지 전략을 공유합니다.
- 명확한 가치를 지닌 새로운 서비스 구축
- 제품 및 공학적인 가치가 없는 경우에는 Monolithic App으로 남기기 - Monolithic의 persistent 저장 방식은 좋지 않음
- 서비스 전반에 걸쳐 data storage를 공유하면 구현 세부사항이 전체시스템에 노축됨
- 이는 loose couple 원칙 위반 - “서비스 구축”및 “실행중인 서비스”분리
- 개발자가 각 서비스의 비즈니스 로직에 집중 할 수 있게
- Medium은 Istio, Envoy, gRPC, Kubernetes 사용 - 철저하고 일관된 모니터링
- 분산시스템으로 인해 관찰이 어렵고, 조각난 데이터를 통해 문제 분류
- DevOps를 통해 일관된 모니터링 필요
- Medium은 DataDog, LightStep 사용 - 새로운 서비스를 처음부터 새로 구축 할 불필요
- 실용적인 접근법으로 생각 필요
- 가령, 기존 기술(Node.js)이 잘 안맞는지, MSA로 다시 구현 비용 - 언젠가는 발생되므로 실패를 예상
- 모든 것이 실패 할것을 예상
- 항상 실패를 예상한 테스트
- 자동 복구 구축 - 첫날부터 “마이크로 서비스 증후군” 피하기
- Microservice가 만병 통치약은 아님
- 빈약하게 모델화 된 Microservice는 이익보다 해가 더 많음
- 너무 많은 언어/기술 선택은 운영 비용을 높임
- 관찰 가능성이 부족하면 성능문제 또는 실패를 분류(식별) 어려움
왜 Monolithic을 중단하고 MSA로 전환했는가?
최근의 기술 혁신으로 인해 MSA를 채택하는 것이 훨씬 쉽워졌습니다. 이것이 Monolithic을 모두 중단해야 하는 뜻은 아닙니다. 신기술로 지원하는 것이 훨씬 더 나아졌지만, MSA는 여전히 높은 수준의 복잡성을 수반합니다. 작은 팀(간한한 Application?)으로 시작하려면 Monolithic App이 더 나은 옵션입니다. 그러나 나중에 시스템과 팀이 성장할 때 MSA로 쉽게 마이그레이션 할 수있도록 Monolithic을 설계 할 필요는 있습니다.
기존 Monolithic App도 web server, backend services, offline event processor를 컴포넌트로 잘 모듈화 시켰습니다. 기존 Monolithic app은 data layer, service layer로 구현하고 data storage를 캡슐화하였습니다.
- Data Layer : data의 CRUD를 처리
- Service layer : data 처리를 위한 상위 수준의 로직을 제어하고, 나머지 시스템에 public API를 제공하며, 다른 서비스들과 data store를 공유하지 않음
Monolithic App은 Microservice를 모델링하는 데 도움을 주며 모든 Microservice를 처음부터 모델링하는 대신 시스템의 가장 중요한 부분에 집중할 수있는 유연성을 제공합니다. data 구현 세부 사항이 숨겨져 있어 MSA를 채택하는데 도움이 되며, 특정 유형의 data 처리를 위한 새로운 service를 만드는 것이 비교적 쉽고 안전하게 됩니다.
결론
Medium 시스템 개발에 Monolithic Node.js 애플리케이션이 수년간 도움이되었지만, 체계적이고 전략적으로 마이크로 서비스 아키텍처를 채택하기 시작했습니다. Medium 기술팀은 개발 생산성을 대폭 향상시키고 제품을 크게 개선하고 새로운 기술을 안전하게 테스트 할 수 있도록 지원함으로써 잠재력을 보았습니다.
- SK주식회사 민현기
- 기술 블로그 : https://medium.com/dtevangelist
