Skip to content

Microservices

마이크로 서비스의 상세 분야

마이크로서비스(microservice)는 애플리케이션을 느슨히 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍처에서 서비스들은 섬세(fine-grained)하고 프로토콜은 가벼운 편이다. 애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선시키고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄련적으로 만들어 준다. 규모가 작은 자율적인 팀들이 팀별 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 한다. 또, 지속적인 리팩터링을 통해 개개의 서비스 아키텍처가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 전개(디플로이)를 가능케 한다.

MSA 전환시 고려할 사항

"Monolith > apps > services > microservices"

  • 첫째, 이건 규칙은 아니고 내 생각이 그렇다는 것. 대규모 분산 시스템을 구축해 본 사람은 실제로 그대로 작동하지 않으며, 적응해야 한다는 것을 알고 있음
  • 둘째, 단계가 중요함
    • 5-50인 회사라면 그냥 Monolith로 가세요
    • 1만명 회사라면, 위의 모든 것들을 다 가지고 있을 것. 근데 예전과 달라진 생각들을 얘기해보자면..

먼저 정의(Definition) 부터

  • monolith - xyz.com
  • apps - abc.xyz.com
  • services - 앱/모노리스를 지원, 핵심 인프라, 핵심 컴플라이언스 기능, 앱팀에서 작성하지 않을 수 있음(인프라에서 유지관리)
  • microserivces - 몇백라인의 코드, 대부분 일회성, 라이브러리 또는 SDK 일수/있어야(could/should) 함

Why ? : 기본적으로 "Speed & Risk" 때문

  • 전체 개발팀이 하나의 빅앱(전체 사이트가 Rails앱 이라고 생각해 볼 것)에서 개발하는게 더 쉬움
  • 성장하면 필수로 가지게 될 분산시스템은, 자체적으로 위험한 수백개의 마이크로서비스 없이도 이미 추론하기가 어려움
  • 완전히 마이크로로 간다면, 무분별한 확장을 처리하기 위해 새로운 개념을 도입해야 함
  • 맞춤형(Bespoke) 인프라 서비스 또는 마이크로서비스는 부채의 극단적 개념임. 코드도 부채이지만 서비스가 그것의 극단적인 버전. 이게 뭘 의미하는지 생각해 볼 것. 레버리지 포인트가 되게 할 것
  • 분산 시스템 엔지니어들은 중복되는걸 싫어하기 때문에 뭔가가 여러데서 이뤄진다면 "이걸 빼내서 마이크로 서비스를 만들자" 라고 생각함
  • 이론적으로는 이게 맞고, 일이십개 까지 되는 것은 괜찮음. 하지만 수십개가 넘어가거나 대규모 회사를 넘어서 사용된다면 기술 문제가 아니라 조직의 문제가 됨
  • 내가 이야기 하는 것이 잘못된 이분법 처럼 느껴지긴 하지만, 실제로 마이크로서비스에 대해서는 기술적인 도전들이 있고, 더 많은 조직적인 문제도 있음

내가 우려하는 것은

  • (특이하게 IT출신 CEO가 이끌지 않는 한) 인프라는 항상 우선순위에서 밀려남(get the short end of priority stick)
  • 서비스가 너무 많으면 일반적으로 소유권 문제 및 경계 문제가 생김
  • 수많은 마이크로서비스를 처리하기 위해 더 많은 도구를 도입함
  • 가장 중요한 것은 라이브러리나 SDK가 되었어야할 각 마이크로서비스들이 프로덕션에 위험을 초래함

일반적으로 내가 추천하는 것은

  • 가능하면 최대한 오래 Monolith를 유지
  • 서비스는 인프라에 필요한 것에서 시작하고, 앱 개발쪽에서 시작하지 말 것
  • Mono를 쪼개야 한다면, 작은 서비스들이 아닌 큰 앱들로 분해할 것
  • 각 새로운 앱은 회사내의 가상 벽이라고 생각할 것
  • 가능하다면 마이크로서비스 대신 라이브러리를 선호

See also

Favorite site

References

  1. Monolithic_to_Microservices_Architecture_with_Patterns_and_Best_Practices.pdf ↩