Moebius Architecture - Phase 2

안녕하세요.

Phase 1을 작성하고 나서 4개월이 지나서야 다시 Moebius project 관련 글을 작성하게 됐습니다. ^^;

이번에 다룰 내용은 프로젝트를 확장해나가면서 구체적으로 어떻게 컴포넌트들을 분리했는지에 대한 것들입니다.

그리고 Monolithic Architecture와 흔히 사용하고 있는 MSA, 즉 Microservice Architecture에 대해서도 간략하게 다뤄보도록 하겠습니다.

---

 

지난 Phase 1에서 구성했던 Architecture에서, 한 컴포넌트에서 너무 많은 역할을 담당하고 있어서 문제가 될 수 있다는 점을 지적했었다.

그래서 단일 컴포넌트를 다중 컴포넌트로 우선순위에 따라 분리를 해나가야 하는데, Phase 2에서는 가장 변화가 많은 부분을 별도 컴포넌트로 분리하기로 결정했다.

그렇게 결정한 이유는 역시 가용성과 확장성을 더 키우기 위해서이고, 그중에서도 Phase 2의 분리는 확장성에 무게가 더 실려있다.

 

변화가 많은 부분은 다른 표현으로 말하자면, 변화가 쉬운 부분이라고도 이야기할 수 있다.

즉 변화가 많은 컴포넌트라면 그만큼 변화가 쉬워야 한다는 얘기가 된다.

 

프로젝트 내에서 가장 바뀌기 쉬운 (요구사항이 자주 바뀌는) 컴포넌트는 다름 아닌 사용자와 맞닿는 UI였고, 이를 Frontend 컴포넌트로 별도로 분리해서 아래와 같은 구조가 되었다.

Moebius Architecture Phase 2

참고로 Phase 1의 Diagram과 차이는 단 2가지밖에 없다.

1. Frontend 컴포넌트 추가
2. Component를 구성하는 Instance count, cluster 정보(MongoDB) 추가

정확히는 사실 하나 더 있다. 눈썰미가 좋은 사람이라면 이미 알았을 수도 있지만, 기존 App에 있던 UI를 위한 Thymeleaf에 대한 의존성이 사라졌다. 부수적으로 얻은 효과이기도 한데, 각 컴포넌트가 담당하는 역할이 작아지면서 동시에 명료해진 셈이다. 이로써 Frontend에서 서비스의 UI를 담당하게 되고, UI를 위한 framework나 library를 보다 더 과감하게 사용할 수 있게 됐다. 당연히 App에서는 더 이상 UI를 신경 쓰지 않아도 된다.

 

---

 

궁극적으로 이렇게 컴포넌트를 분리하기 시작한다는 것은, 초기 Monolithic Architecture에서 Microservices Architecture로 변화해가는 것을 의미한다. 두 Architectures에 대해서는 다음의 Diagram으로 간단하게 설명이 된다.

Monolithic Vs. Microservices

먼저 어떤 서비스를 제공하기 위한 컴포넌트를 구성하게 되는데, 기본적으로 3가지(View, Service, Persistence) Layers로 잡고, Database와 연동되는 구조가 일반적이다.

 

Monolithic Architecture는 Monolithic이라는 사전적 의미 그대로, 구성하고자 하는 비즈니스나 플랫폼의 규모와 상관없이 하나의 통합된 구조로, 하나의 컴포넌트로 구성하는 방식이다. 즉 컴포넌트 하나가 모든 서비스를 담당하는 개념이다.

 

Monolithic Architecture가 갖는 장점은 무엇일까? 우선 제공하고자 하는 서비스를 잘게 나눠놓지 않았기 때문에 개발 및 배포가 상대적으로 Microservices Architecture보다는 쉬운 편이다. 그리고 단일 컴포넌트이기 때문에 Microservices에서 발생할 수 있는 네트워크 지연 및 비용 문제, 보안 문제 등이 덜하다고 할 수 있다. 처음 Phase 1에서 채용했던 Architecture는 Monolithic Architecture라고 할 수 있다.

 

Microservices Architecture는 서비스를 구성할 때 보다 더 작은 컴포넌트들로 분리하여 조합하는 형태로 구성하는 Architecture라고 할 수 있다. 이렇게 구성하게 되면 각 서비스들마다 Database를 가질 수 있게 되고, 각 서비스가 독립된 형태이기 때문에 개발 및 배포도 독립적으로 이뤄지게 된다. Diagram상에서는 서비스마다 View도 별도로 구성되어 있는 형태로 나타냈지만, 때에 따라서는 통합된 View 하나만 활용하고, Service 및 Persistence Layers만 개별적으로 구성하는 구조도 가능하다.

 

그러면 Microservices Architecture가 갖는 장점은 무엇일까? 간단하게 표현하면, Monolithic Architecture가 갖는 단점들이 모두 장점이 된다. Phase 1에서 이야기한 SRP를 혹시 기억하는가? Microservices를 통해서 단일 서비스가 책임지는 역할이 상대적으로 작기 때문에 SRP를 충실하게 따르는 Architecture를 구성할 수 있다. 당연히 이를 통해 SPOF도 회피할 수 있기 때문에 가용성을 높일 수 있고, 위에서 언급한대로 독립된 컴포넌트를 조합하는 구조기 때문에, 필요한 컴포넌트에 리소스를 더 투입하거나 변경해서 배포하는 것이 쉬워서 확장성도 상대적으로 좋다. 결론적으로 Phase 2에서 다른 컴포넌트를 추가하면서 역할을 분리한 이 구조가 바로 Microservices Architecture라고 할 수 있다.

---

이렇게 Phase 2에서는 어떻게 컴포넌트를 분리, 확장했는지 살펴봤고 더 나아가 Phase 1,2에서 적용된 Architectures인 Monolithic, Microservices Architecture에 대해 알아봤습니다. 그런데 사람들이 크게 오해하는 것이 하나 있습니다. 바로 Microservices Architecture가 항상 Monolithic Architecture보다 좋다고 생각하는 것입니다.

 

이에 대해 저는 매우 위험한 생각이라고 감히 이야기할 수 있을 것 같습니다. 이와 관련되어 소프트웨어 공학에서 불변의 진리라고 생각하는 격언이 있습니다.

 

No Silver Bullet.

- Fred Brooks

 

직역하면 은탄환은 없다는 뜻인데, 이는 모든 걸 요구사항을 만족하는 이상적인 개념은 존재하지 않다는 뜻입니다. 우리가 흔히 마주치게 되는 알고리즘이나 자료구조를 다루다 보면 그 의미가 뭔지 한 번에 와 닿으시리라 생각합니다.

 

결론적으로 두 Architecture가 서로 상보적인 역할을 하기 때문에, 상황에 맞게 선택해서 써야 하고 정말 필요하다면 둘을 조합해서도 써야 알맞다는 이야기를 하고 싶었습니다. 실제로 두 Architecture를 섞어서 쓰는 경우들도 심심치 않게 보기 때문입니다.

 

다음 글에는 좀 더 많은 컴포넌트로 나눠진 구조인 Phase 3를 공유하고, 마찬가지로 추가된 컴포넌트와 연관된 Software Architecture들을 다뤄보도록 하겠습니다.

 

기나긴 글 읽어주셔서 감사합니다.