Microservice의 등장 배경 (3)

글을 시작하기 앞서 마이크로서비스와 관련된 흥미로운 이야기 하나를 소개하고자 함.

 

아마존의 성공에 있어 가장 중요한 사건으로 평가 받는 제프베조스의 사내 메일

아마존 CEO인 Jeff Bezos가 전사 전체 직원들에게 보낸 메일

1. 모든 팀은 서비스 인터페이스를 통해 데이터 기능을 공개해야 한다.
2. 팀은 이러한 인터페이스를 통해서만 통신을 해야 한다.
3. 인터페이스가 아닌 방식은 앞으로 지원하지 않는다. 직접 연결, 백도어 등의 방식을 사용하면 안 됨.
4. 각 서비스에 사용되는 기술은 중요하지 않다. 어떤 프로토콜이든 상관하지 않는다.
5. 모든 서비스 인터페이스는 반드시 외부에 공개가 될 준비가 되어야 한다. 예외는 없다.
6. 누구든 이를 지키지 않으면 해고된다

위 메일에서 나열된 5가지의 항목은 모두 현재의 AWS는 물론이고 국내에 있는 대다수의 IT 회사들도 사용하고 있는 API 공개 방식임.
20년 전 클라우드 서비스, 마이크로서비스라는 개념이 나타나기 전부터 테크 팀들에게 회사가 가지고 있는 리소스들을 사용하는 방법을 정의 내렸음. 그리고 이 방식은 현재 마이크로서비스 아키텍처에서도 서비스 간 리소스들을 사용하는 방식으로 사용 되어지고 있음.

 

이렇듯 마이크로서비스 아키텍처의 중요성은 이미 오래 전부터 대두되었으며 현재 많은 기업들이 기존에 개발된 시스템을 과감히 버리고 마이크로서비스 아키텍처로 전환하는 추세임. 새로 개발되는 시스템들은 말할 것도 없이 MSA를 채택하고 있음. 이번엔 이 이유를 기존 IT 시스템 아키텍처인 모놀리스 방식의 아키텍처와 비교하며 알아보도록 함.

Monolithic vs Microservices

현재 많은 기업들이 기존의 아키텍처를 버리고 마이크로서비스 아키텍처로 시스템을 구성하는 추세임. 마이크로서비스 아키텍처는 기존의 모놀리식 아키텍처와는 다른 구조로 되어 있으며, 이러한 구조에서 오는 장점 때문에 이러한 추세를 형성하고 있음. 그렇다면 기존의 모놀리식 아키텍처에서는 무엇이 문제가 되었으며, 마이크로서비스 아키텍처는 어떻게 모놀리식 아키텍처보다 좋은지 살펴보겠음.

모놀리스(Monolith) 방식의 특징

모놀리스 방식이란 마치 소프트웨어를 하나의 거대한 건축물 처럼 하나의 덩어리 형태로 개발하는 방식을 말함. 과거에는 시대적인 특성에 의해 모놀리스 방식으로 소프트웨어를 개발하는 것이 대세였음. 이러한 모놀리식 아키텍처에 대한 특징을 알아봄.

• 모든 서비스가 하나의 코드베이스에 모두 포함되어 개발됨.
• 데이터베이스를 처리하는 서비스, 화면을 처리하는 서비스가 모두 포함되어 패키징되는 애플리케이션 형태로 관리가 되어짐.
• 여러 서비스가 하나의 데이터베이스를 공유하여 사용함.
• 하나의 커다란 건축물과 같음.

문제점

• 시스템의 일부만 수정하더라도 전체 시스템을 다시 패키징되고 배포해야하는 단점이 있음.
• 하나의 덩어리로 완성된 시스템은 지속적인 수정을 통해 점점 복잡해지고 거대해 짐. 이로 인해 유지보수에 드는 비용이 점점 증가하게 됨.
• 최초 시스템 스펙이 정해진 이후로는 바꾸기 힘듬.

위와 같은 특성으로 인해 기존 IT 시스템 아키텍처는 시간이 지날수록 새로운 변경사항을 적용하기 힘들어지며 갈수록 복잡해지는 로직과 시스템의 덩치가 비대해짐 등의 요인에 의해 시스템을 유지하고 관리하는데 드는 비용이 기하급수적으로 증가하게 되는 문제가 발생함.

마이크로서비스 아키텍처의 특징

이전 글에서 소개했던 IT 시스템의 시대적 흐름에 의해 클라우드 서비스의 등장, 네트워크 속도의 발전, 하드웨어 성능의 발전 등의 요소가 갖춰지며 기존의 모놀리스 방식의 아키텍처의 문제점을 해결할 수 있는 대안으로 마이크로서비스 아키텍처가 혜성과 같이 나타남. 이렇게 나타난 마이크로서비스 아키텍처는 빠르게 기존 시스템을 갈아치우기 시작했으며 지금은 한국의 많은 회사들이 채택하고 있을 정도로 대세로 자리 잡게 됨. 이번엔 이러한 마이크로서비스 아키텍처의 특징을 살펴봄.

 

sam Newman이 정의한 MSA의 특성

Small autonomous services that work together
함께 작동하는 작은 규모의 서비스들의 묶음
- sam Newman

• 하나의 서비스를 이루는 기능들을 각각으로 세분화하여 개발하여 배포, 운영이 이루어짐.
• 하나의 애플리케이션에 장애가 발생하여도 다른 애플리케이션에 미치는 영향을 최소화할 수 있음.
• 하나의 애플리케이션의 지속적인 수정, 배포가 자유로워짐.
• 각각의 비즈니스를 중심으로 나뉘어서 개발되어야 함.
• 독립적으로 배포되어야 하며 이 과정은 모두 자동화 되어야 함.
• 서로다른 중앙 집중식 관리가 되어야 하며, 각기 다른 언어와, 각기 다른 데이터 저장소를 가질 수 있음.
• 통일되지 않고 각기 다른 스펙으로 개발된 애플리케이션은 서로 데이터를 통신하기 위한 API를 통해서 상호 작용을 할 수 있어야 함. (HTTP/HTTPS)

두 가지 방식 비교

위 특징을 가진 마이크로서비스가 어떻게 모놀리스 방식의 시스템 아키텍처의 문제점을 해결했는지 서술해봄.

 

다양한 언어와 기술들을 유연하게 가져갈 수 있는 Polyglot한 특징

모놀리스 방식의 아키텍처는 전체 서비스가 하나의 패키지된 애플리케이션의 형태로 운용됨. 그렇기 때문에 최초로 시스템 스펙이 정해지면 이를 바꾸거나 추가하거나 수정하는데에 비용이 많이 들게 됨. 하지만 마이크로서비스는 작은 단위로 쪼개진 서비스들이 각각 독립된 형태로 개발되며 배포, 운영이 되기 때문에 자바로 개발이 되든 파이썬으로 개발되던 자바스크립트로 개발이 되던 상관없이 각자 서로 네트워크를 이용한 프로토콜로 통신하기 때문에 프로토콜만 맞출 수 있다면 기술적인 스펙은 모두 독립적으로 가져갈 수 있는 것임. 이렇게 작은 단위로 개발된 마이크로서비스들은 또 새로운 기술을 도입하거나 빼거나 심지어 다시 개발한다거나 하는 등의 작업이 원활해지는 것임.

 

빠른 배포 프로세스

모놀리스 방식의 아키텍처는 시간이 가면 갈수록 그 크기가 비대해지는 문제점이 있었음. 이게 왜 문제가 되냐면 일례로 내가 아는 개발자가 맡아 운영하고 있는 시스템은 뭐 하나만 수정하고 테스트하려고 해도 빌드만 40분이 넘게 걸리는 상상도 하기 힘든 거대한 시스템인데, 그만큼 복잡하기도 하고 시간도 많이 걸리기에 매 개발, 테스트, 배포에 비용을 많이 잡아먹게 되는 것임. 마이크로서비스는 각각 비즈니스 중심으로 서비스를 나뉘어 작은 단위의 부분만 개발, 테스트, 배포하기 때문에 모놀리스 방식의 시스템에 비해 상대적으로 빠른 발전이 가능하게 되는 것임.

이로 인해 마이크로서비스 아키텍처로 구성된 시스템은 고객의 피드백과 새로운 요구사항, 비즈니스의 환경 변화에 빠르게 대응할 수 있게 됨. 이를 통해 유저 중심의 가치가 높은 시스템에 빠르게 근접할 수 있게 되는 것임.

 

쉬운 장애 대응

모놀리스 방식의 시스템은 장애발생에 매우 취약한 문제점이 있음. 하나의 덩어리로 패키징되어 배포된 시스템은 새로운 코드가 문제를 발생시켰을 경우 전체 시스템을 다운시키고 수정하고 재배포해야 하는 문제점이 있음. 마이크로서비스는 특정 서비스에 문제가 발생하면 다른 서비스들은 그대로 두고 문제가 되는 서비스만 떼어내 수정하고 재배포하면 되기 때문에 장애에 대응하기가 모놀리스 방식의 시스템에 비해 훨씬 수월함.

 

유연한 스케일링

모놀리스 방식의 IT 시스템은 그 자체가 하나의 덩어리 이기 때문에 특정 서비스에 트래픽이 증가한다 하여도 그 부분에 대해서만 스케일링을 할 수 없음. 스케일링을 한다면 거대한 서버를 또 복사하여 분산 처리하거나, 거대한 서버의 물리적인 스펙을 올릴 수 밖에 없음. 특정 부분의 트래픽을 감당하기 위해 전체적으로 상당한 비용을 낭비하게 되는 것임.

마이크로서비스는 비즈니스 중심으로 작은 단위로 나뉘어 졌음. 그러므로 특정 서비스에 트래픽이 몰리게 되면 해당 서비스에 대한 스케일링만 진행하면 되기 때문에 무분별한리소스 낭비 없이 효율적으로 스케일링이 가능하게 됨.

모놀리스 vs 클라이언트-서버 vs 마이크로서비스 비교

---

이처럼 마이크로서비스는 기존의 모놀리스 방식의 IT 시스템 구조로 개발된 시스템을 과감히 버리고 재개발하게 만들 정도로 큰 이점을 가지고 있음을 살펴봤음. 이렇게만 살펴보면 마냥 마이크로서비스 아키텍처가 좋기만 할 것 같지만 그렇진 않음. 마이크로서비스 아키텍처를 완성하기 위해서 요구되는 조건들의 난이도가 높은 편에 속해 준비를 갖추지 않고 대세만 쫓다간 가랑이가 찢어지기 일수임. 또한 마이크로서비스가 모든 IT 시스템에 적합한 것은 아님.

 

다음 글에서는 마이크로서비스를 구성하기 전 고민해봐야 할 조건들과 특성들 그리고 마이크로서비스의 구조를 살펴보도록 하겠음.

참조

- Microservices vs Monolithic Architecture - RevDeBug

- Micro Frontends - netgrif

---

이전글

2023.11.29 - [Article] - Microservice의 등장 배경 (2)

Microservice의 등장 배경 (2)