[WebDev] You probably don’t need microservices

 

You probably don’t need microservices

---

마이크로 서비스는 시스템과 구조를 확장하는데에 도움이 되는 훌륭한 방식으로 최근 굉장히 인기있는 아키텍처 스타일이다. 많은 성공한 회사들(넷플릭스, Spotify..)을 포함하여 대부분의 회사들이 이 방식을 사용하거나 사용할 계획을 가지고 있다. 하지만, 몇몇 회사들은 마이크로 서비스가 가져오는 추가 비용을 간과하고 있다.

본격적으로 이야기 하기전에, 저자의 마이크로 서비스 경험을 이야기한다.

How it started - Is it microservices?

2012년 나는 ‘어떻게 하면 수천명의 엔지니어와 천배 더 많은 트랜잭션을 처리하도록 성장시킬 수 있을까’ 라는 도전에 직면했다.

나는 당시 ‘Scalability Rules: 50 Principles for Scaling Web Sites’ 책을 읽고 있었고, 그 책에서 AKF Scale Cube 라는 방식을 보았다.

나는 다른 사람들에게 왜 프로덕션 환경에서 각각 다르게 실행되는 바이너리들이 필요한지 설명하는데에 이 구조를 사용하였다. 검색 모듈의 트래픽 패턴은 장바구니 모듈의 트래픽 패턴과는 완전히 다르다. 이 컴포넌트들은 분리되는 것이 합리적이다. 게다가 이것은 여러 팀들이 각각 독립적이고 자율적으로 일할 수 있게 해준다. 이것은 수천 명의 엔지니어로 회사를 성장시키는 도전을 해결하는데에 도움이 되었다.

So, what’s wrong?

마이크로 서비스는 그 자체로는 문제가 없다! 그리고 모놀리식 아키텍처도 문제가 없다. 그러나 우리 산업은 만병 통치약은 없다는 사실을 잊어버린 듯 하다. 그리고 때로는 해를 끼칠 수 있는 약도 있다.

Ex 1. You get a service, and you get a service, you all get a service

한번은 약 200명의 개발자가 있는 스타트업 엔지니어 두명과 대화를 한 적이 있다. 그 중 한사람이 말하길 그들은 프로덕션 환경에서 복잡한 시스템을 운영하는 마이크로 서비스를 사용하고 있다고 했다. 그 중 가장 큰 과제는 그 마이크로 서비스들이 모두 유지되고 있음을 보장하는 것이라고 하였다. 오래된 의존성, 오래된 런타임 버전, 일부 서비스 내의 지식 부족 등등 환경 속에서도!

그 회사는 개발자보다 더 많은 마이크로 서비스를 운영하고 있다. 클라이언트들에게 많은 기능을 제공하는 제품 중심의 회사에서, 이 모든 마이크로 서비스를 계속해서 따라가는 것은 매우 어렵다.

Ex 2. You change, I change, we all change

낮은 결합도와 높은 응집력을 바로 달성하는 것은 어렵다. 마이크로 서비스 아키텍처에서 이를 제대로 구현하는 것은 더욱 어렵다. 매우 작은 서비스(나노 서비스라고도 불리는)를 사용하면 결합도가 높고 응집력이 낮아지는 상황에 처할 것이다.

이전 회사에서 bounded context에 매우 많은 작은 서비스들이 있어서 어떤 변화에도 여러팀이 함께 작업해야하는 상황이 있었다. 심지어 성능마저 끔찍했다.

💡 bounded context

도메인 주도 설계(DDD: Domain-Driven Design)에서 사용되는 개념으로, 특정 도메인 모델이 유효한 경계를 정의하는 것을 의미한다. 즉, 특정 비즈니스 영역 내에서 용어와 개념의 의미가 명확하게 정의되고 일관되게 사용되는 범위이다. 이는 도메인 내의 논리적 경계를 설정하여 혼란을 줄이고, 각 경계 내에서 모델의 일관성을 유지할 수 있게 한다.

예를 들어, 전자상거래 시스템에서 "주문(Order)"이라는 개념은 여러 컨텍스트에서 다르게 해석될 수 있다. 주문을 생성하고 관리하는 컨텍스트와 주문을 배송하는 컨텍스트는 서로 다른 요구사항과 규칙을 가질 수 있기 때문에 별도의 bounded context로 다루는 것이 좋다.

이 예시는 좋은 예시인데, 그 이유는 팀들이 성능을 향상시키기 위해 모든 정보를 종합하는 또 하나의 서비스를 만들고자 했기 때문이다. 작은 서비스들을 합쳐 더 높은 응집력을 가지려는 아이디어가 단지 “모놀리식처럼 보인다”라는 이유로 나쁘다고 여겨졌다.

Ex3. Everything was fine, until it wasn’t

기술 분야에서 일어나는 대규모 인력 감축으로 인해 더 많은 회사들이 심층적으로 인력을 감축한 후에도 서비스 수가 너무 많다는 이야기를 듣고 있다.

이것은 공장한 예가 아닐 수 있다. 누가 회사들이 40~60%의 인력을 감축할 것이라고 예상했을까? 단순함은 이 업계에서 가장 어려운 것 중 하나이다. 하지만 우리는 가능한 단순하게 유지하되, 너무 단순하지 않아야 한다.

프로덕션 환경에서 단순한 시스템을 가지고 있는 회사는 더 높은 민첩성을 가진다. 그들은 운영 오버헤드를 너무 걱정하지 않고도 비용을 절감하고 인력을 줄일 수 있다.

Ex 4. Let’s start our startup using microservices

Greenfield 프로젝트는 놀랍다. 이것은 창의적인 예술가가 그리기 시작한 빈 캔버스와 같다. 이 상황에서 예술가는 다채로운 그림을 그리기로 한다. 예술가는 Ruby, Golang, Java와 같은 주요 색상을 선택했고, 그것을 Postgresql, Elasticsearch, Cassandra 등과 섞었다.

이 그림, 만약 그들이 시간을 내서 완성할 수만 있다면 피카소가 될 수 있었다.

항상 나쁜것은 아니다. 실제로 jet.com은 마이크로 서비스를 사용했고, 월마트에 좋은 결과를 냈다. 나는 단지 우리가 엔지니어로서 비판적인 사고를 갖고 무엇이 가장 좋을지 선택해야한다고 말하고 싶다.

Ok, but why?

이 글을 읽는 일부 사람들은 “이것은 기술 이슈야”라고 생각할 수 있다. 하지만 아니다. 처음 두 예시의 사람들을 나는 안다. 그들은 매우 똑똑하고 훌륭한 엔지니어다. 다른 예시에 나온 사람들도 분명히 똑똑할 것이다.

 

 

Scott Hanner의 이 트위터에서 좋은 이유를 제시했다. 우리는 마이크로 서비스들을 internalized(내면화) 했다. 아마 이것이 많은 팀들이 마이크로서비스를 채택하는 이유일 것이다. 이러한 사고방식은 우리의 뇌에 깊숙히 자리잡고 있다.

제로 이자율 정책(ZIRP)도 아마 그 원인 중 하나일 수 있다.

💡 Zero Interest Rate Policy

제로 이자율 정책(Zero Interest Rate Policy, ZIRP)은 중앙은행이 기준 금리를 0%로 설정하고 유지하는 정책을 의미한다. 이 정책은 경제를 활성화하고 금융 시장을 안정화시키는 데 사용된다.

이 비유에서 "ZIRP"는 기술 분야에서 마이크로서비스의 대중화가 쉽게 이루어지고, 기업들이 더 많은 프로그래머를 고용하고자 하는 경향과 연관지어 사용된다. 즉, 기술 산업에서의 마이크로서비스 열풍이 마치 경제에 대한 제로 이자율 정책과 같이 효과적인 프로그래머 고용 프로그램으로 작용했다는 의미를 담고 있다.

제로 이자율 정책 시대에는 마이크로서비스의 숨겨진 비용에 대해 더 많은 인식이 될 것으로 예상한다. 관리자들은 문제에 대한 좋은 해결책이더라도 마이크로서비스를 채택하기를 더욱 꺼려할 것이다.

You still have time

위의 예시 중 어떤 것이라도 당신과 관련이 있더라도, 걱정하지 마라. 소프트웨어의 좋은 점은 거의 항상 바꿀 수 있다는 것이다. 당신이 이것을 ‘문제’라고 보고 있다면, ‘기회’라고 바꿔서 생각해보아라.

서비스의 수가 능력을 혁신 시키는데에 영향을 주고 있다고 생각하는가? 회사가 운영 오버헤드를 줄일 수 있는 전략을 수립해라. 신뢰성을 완화할 수도 있고, 아니면 시스템 아키텍처를 단순화하는 데 투자하여 더 많은 혁신 능력을 높일 수 있다.

예시 2의 팀은 그렇게 했다. 그들은 비용 절감과 더 나은 고객 경험에 집중하는 ‘서비스 통합’ 전략을 제시했다. 이에 이해 관계자들은 매우 만족했다.

창업을 계획하고 있는가? 만약 너가 회사를 창업하고 마이크로 서비스를 생각하고 있다면, 왜 마이크로 서비스를 사용해야하는지, 다른 대안을 고려하고 있는지에 대해 설명하는 설계 문서를 작성해보아라. 이는 생각을 정리하고 마이크로 서비스가 정말 너의 회사에 적합한 구조인지 명확하게 이해할 수 있도록 도와줄 것이다.

마이크로 서비스는 훌륭하지만, 시스템과 조식에 복잡성을 더한다. 작업 방식이 변경되고, 구조는 점점 더 복잡해지며, 모놀리식에서 마이크로 서비스로의 이전은 시간이 걸릴 것이다. 마이크로 서비스에 급하게 이동하기 전에 잠시 뒤로 물러서서 기다려보아라. 그리고 생각해봐라 마이크로 서비스가 어떻게 도움이 되며 어떻게 해를 끼칠지..

 

Dear Developers,

나는 시간에 견고한 소프트웨어를 구축하는 오래 지속 가능한 산업을 원한다. 기술을 ‘목적’이 아니라 ‘수단’으로 사용하여 실용적인 결정을 내리는 산업을 원한다.

 

💡 Sometimes microservices are great… but you probably don’t need microservices.

---

Opinion

여기에서 말하는 예시들을 모두 공감한다. 특히 1번은 실제 개발 환경에서도 많이 느끼고 경험하고 있다. 하지만 다른 아키텍처(모놀리식 등)가 마이크로 서비스보다 더욱 많은 장점을 가지고 있는가? 운영하는 서비스에 적절한가? 에 대해서는 부정적이다. 

예시 4와 트위터 글에서도 잘 표현이 된 것 같지만, 이 저자가 말하고자 하는 것은 습관적으로 마이크로 서비스를 채택하는 것을 지적하고 싶은 것으로 보인다. 실제로 만드려는 서비스에 어떤 아키텍처가 적합할 것인가에 대한 고민없이 항상 마이크로 서비스를 채택해왔다. 이를 좀더 비판적인 사고로 바라보고 '선택'해야만 한다. 

🌟개발에서 당연한 것은 없다! 항상 서비스에 어떤것이 적합할지 분석하고, 고민하며, 선택하는 개발자가 되자.🌟