전 GitHub CTO, "지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것" (twitter.com/jasoncwarner)

 geeknews에서 가져온 내용. 원본 링크는 아래에 기재.

https://news.hada.io/topic?id=7839


지난 10년간 가장 큰 아키텍처 실수는 풀 마이크로서비스로 전환한 것

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

먼저 정의(Definition) 부터

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

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

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

내가 우려하는 것은

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

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

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


현재 상황은 대부분 인프라는 무시하고 기획부터 시작하는 경우가 많은 듯. 앱이라는게 구체적으로 무엇을 의미하는 지는 약간 불명확한 부분이 있어 다시 확인해 보아야 할 듯 하다. MicroService의 도입 실패는 여기저기서 많이 들려오는 이야기이니 특별한 것은 없지만 그에 대한 고찰내용이 괜찮은 듯.

댓글

이 블로그의 인기 게시물

curl 명령어 옵션

CISCO 2960s 초기화 후 기본 설정

맥북 카라비너 영어/한글/일본어 전환하기