지난 1편에 이은 2편의 글이다.
먼저 Monolithic System에 대해 좀 더 알아보고, MSA의 장단점, 오해 등에 알아보자.
Monolithic System - 종류
앞선 1편의 글을 본 사람이면 대~강이라도 Monolithic 시스템이 어떤 것인지 알 것이다.
이러한 Monolithic 시스템은 여러 타입이 존재한다.
Single Monolithic System
가장 일반적인 형태의 Monolithic System이다.
하나의 코드 베이스를 유지하기 때문에 '큰 진흙 공' 이라고도 불린다.
Modular Monolithic System
각 기능별로 모듈화 되어 있는 형태이다.
그렇기 때문에 MSA의 좋은 대안이 될 수 있다.
아래에서 알아보겠지만, Monolithic의 가장 큰 문제는 "기능 간 결합도"와 "코드 수정 시 영향도"이다.
만약 Modular Monolithic 시스템을 적용하여 이러한 결합도를 잘 다루면,
유지보수성이 높은 시스템을 개발할 수 있다.
그러나 배포와 확장에 대한 이슈는 여전히 존재하며,
타 기능의 데이터에 직접 접근할 때도 있기 때문에 데이터에 대한 이슈도 존재한다.
그래서 Modular Monolithic 시스템의 장점을 잘 취하려면 모듈 간의 결합도를 자주 관리해주어야 한다.
Distributed Monolithic System
말 그대로 각 기능이 분산된 Monolithic 시스템이다.
하지만 그렇게 기능을 쪼갰다고 MSA라고 부를 수 없다.
Distributed Monolithic 시스템은 쪼개진 기능들이 매우 강하게 결합되어 있는 형태이다.
그래서 기능이 분리되어 있음에도, 배포가 필요할 때면 모든 기능이 항상 같이 배포된다.
결국, Monolithic의 큰 단점인 영향도와 결합도가 모두 존재하며,
네트워크로 통신함으로 발생하는 성능 저하와 관리가 어려운 분산 시스템의 단점까지 존재한다.
그래서 기존 Monolithic 시스템을 MSA로 전환한다거나 새로운 시스템을 MSA로 개발할 때,
가장 경계해야 하는 유형이다.
그래서 기존 시스템을 MSA로 전환할 때에는 먼저 기존 시스템의 결합도를 낮추고 개선한 뒤,
MSA를 도입하는 2-step으로 진행한다.
Monolithic System - 장단점
장점
그럼 그러한 Monolithic 시스템은 무조건 안 좋은 것일까?
답은 아니다.
먼저 MSA에 비해 상대적으로 운영이 용이하다.
하나의 코드 베이스를 유지하기 때문에 코드 관리도 쉽고,
서버의 수도 적기 때문에 장애 관리, 로그 관리, 모니터링 등도 상대적으로 용이하다.
또한 API 등의 네트워크를 통해 Interface를 호출하는 MSA와는 다르게,
내부 메소드 호출을 하기 때문에 성능 또한 빠르다.
마지막으로 트랜잭션 관리가 용이하다.
이것이 현재 MSA에서 가장 문제가 되는 부분 중 하나인데,
현재 Monolithic의 트랜잭션 관리 수준으로 MSA에 적용할 수 있는 방법이 없다고 한다.
단점
그럼에도 단점은 역시 존재한다.
앞서 본 쇼핑몰의 예에서 볼 수 있듯이, 기능들 간의 결합도가 일반적으로 높다.
그래서 A라는 기능에서 B라는 테이블에 직접 접근하기도 한다.
그리고 하나의 코드 베이스를 유지하다 보니,
누군가가 어떤 기능을 변경했을 때 다른 기능에 어떤 영향을 주는지 파악이 어렵다.
즉, 코드끼리 의존하게 되며, 코드뿐만 아니라 데이터들도 서로 의존하게 된다.
또한 굉장히 작은 수정을 해도 전체 시스템을 빌드하고 배포를 해야 하고,
코드 베이스가 커지면 빌드/배포 시간도 어마어마 해진다.
만약 그러한 과정에서 하나의 버그가 생기면, 전체 시스템이 실패할 가능성도 굉장히 높다.
위 같은 이슈들을 해결하기 위해 서버의 수를 늘리려고 해도(Scale-Out),
전체 시스템을 확장해야 하는 비효율적인 부분이 있다.
(하나의 서버의 성능을 엄청 올려버리는 수직적인 성능 향상의 Scale-Up과는 다르게 Scale-Out은 서버의 수를 증가하는 수평적인 성능 향상)
Monolithic 시스템에서 Scale-Out을 하려면,
현재 유지 중인 서버들과 연결되어 있는 기능들을 다 해제하고 새로운 서버에 재할당하는 등 귀찮은 작업이 존재한다.
결과적으로, 코드가 운영 환경에 민첩하게 배포되기 어렵다.
MSA - 장단점
MSA를 적용하면 위와 같은 Monolithic 시스템의 문제를 해결할 수 있다.
즉, MSA의 장단점은 Monolithic 시스템의 장단점과 서로 반대되어 작성하지 않아도 알 수 있지만,
그래도 MSA에 관한 글이니 장점만 알아보자.
장점
MSA를 적용하면 위와 같은 Monolithic 시스템의 문제를 해결할 수 있다.
MSA는 각각 최소한의 기능을 하는 독립적인 서비스들로 구성되어 있기 때문에
작은 서비스 단위로, 탄력적이고 선택적인 확장을 할 수도 있다.
예를 들면,
특정 웹 사이트에서 A라는 기능이 사람들이 몰린다고 하면 그 기능 부분만 Scale-Out 하는 방법을 사용할 수 있다.
확장뿐만 아니라, 서비스 단위로 자율적인 배포도 가능하다.
내가 맡고 있는 B라는 기능을 좀 수정해서 배포하고 싶으면, B 기능만 배포하면 되는 것이다.
그로 인해 실험적이고 혁신적인 시도를 두려움과 시간 낭비 없이 할 수 있다.
또한 각각의 기능은 서로 독립되어 있기 때문에, 일부 기능에 장애가 발생해도 시스템 전체 장애로 이어지지 않는다.
만약 C라는 기능에 장애가 발생해도, 그와 유사한 기능을 하는 D라는 기능이 작동하게 하여 대체 가능성의 여지도 생긴다.
이러한 이유 때문에 각 서비스는 독립적으로 개발되고 느슨하게 결합되어 있다.
위처럼 Monolithic 시스템의 단점을 커버하는 것 외에도, Polyglot Architecture을 지원하게 된다.
Polyglot이란 "여러 언어를 사용하는"이란 뜻인데,
말 그대로 MSA에서 각 기능을 구현할 때 서로 다른 언어와 다른 DB, 다른 서버를 사용할 수 있다는 것이다.
그로 인해 기술 부채의 경감 효과도 발생한다.
결과적으로, 빠르게 변화하는 비즈니스 환경에 민첩하게 대응이 가능하게 된다.
Monolithic에 대한 오해
이렇게 읽고 나면 Monolithic에 대해 안 좋은 생각이 든다.
'Monolithic은 Legacy인가?'
'Monolithic은 피해야 할 Anti-Pattern인가?'
'Monolithic은 모든 상황에서 MSA로 분할되어야 하나?'
하지만 절대 아니다.
Monolithic System이든 MSA든 하나의 Architecture 패턴일 뿐이다.
앞서 보았던 Monolithic 시스템의 장점도 충분히 많은 것처럼,
Monolithic 시스템도 많은 상황에서 충분히 좋은 역할을 한다.
왜 지금 MSA인가?
그럼에도 불구하고, 왜 지금 MSA가 이렇게 인기가 좋을까?
비즈니스와 기술, 두 측면에서 바라볼 수 있다.
비즈니스적인 측면
시간이 흐를수록 비즈니스 환경은 점점 빠르게 급변한다.
또한 점점 더 많은 비즈니스들이 IT 기술에 의존하는 케이스가 많다.
우리 주위만 보더라도 배달의 민족 같은 경우,
연말 같은 대목에는 사람이 엄청 몰려서 서버가 터져 몇 시간 동안 배달을 못 시키는 경우도 볼 수 있다.
넷플릭스나 유튜브도 코로나 때문에 사람들이 많이 접속해서
강제로 화질을 낮추거나 하는 등의 조치를 취한 것을 볼 수 있었다.
그렇기 때문에 밀접한 IT 기술의 진보 없이는 비즈니스의 빠른 변화에 대처할 수 없고,
그러한 IT 기술을 발전시켜 나가기 위해서는 MSA는 딱 들어맞는 아키텍처다.
기술적인 측면
Cloud, NoSQL, Docker, Kubernetes 등 이름만 들어도 '어! 저거!' 하는 것들이 있다.
기존 시스템에서는 이러한 신기술을 공부하고 실제 서비스에 적용해보기가 굉장히 어렵다.
애초에 장애 대응하느라 공부할 시간도 많이 없을뿐더러,
서로 기능들이 얽혀 있는 거대한 레거시 코드에 신기술을 적용하기에는 수많은 에러를 발생시킬 것이기 뻔하기 때문이다.
그런 관점에서,
MSA는 독립적인 기능들로 이루어져 있고, 각 기능은 다양한 기술들로 개발될 수 있다.
Netflix가 만든 Netflix OSS처럼, MSA에 관한 Best Practice가 점점 쌓여가고 있으므로
그러한 발자취를 따라가 보며 성공적인 MSA로의 전환을 맞이할 수 있을 것이다.
Conclusion
MSA란 '하나의 Application을 다수의 독립적인 Service로 구성하는 Architecture Style'이다.
MSA를 통해 Monolithic System에서 발생되는 문제점들을 해결할 수 있으며,
현재 Amazon, Netflix와 같은 Service Company가 기술의 발전을 주도하고 있다.
국내도 2018년 이후부터 많은 사례들이 발표되고 있다.
MSA에 대해 공부하며 굉장히 흥미가 많이 갔다.
DB나 서버 등이 많이 필요해서 사이드 프로젝트로 구현해보기에는 무리가 있을 것 같지만,
'이러한 아키텍처도 있구나' 하는 지식을 얻은 것만으로도 만족한다.
끝!
