Monolithic / Microservice는 무엇인가?

䷿ 서론

필자는 경제학과를 졸업했고 그 많고 많은 사람들이 갖고 있는 석사학위까지.... 경제학을 조금 더 공부했다. 그리고 난 뒤에 처음에 Monolithic라는 단어를 들었을 때, Monopoly, 즉 독점이라는 것이 연상되었다. 하나라는 의미를 생각했을 때, Monolithic Architecture는 웹을 구성하는 아키텍처가 하나, 즉 서버가 하나라는 의미로 곧바로 다가왔다. 물론 보다 복잡하게 이야기 했을 때 서버가 하나이다 라는 의미는 아닌 것 같았다. 왜냐하면, 여러 개의 서버를 두고 load balancer를 갖고 있다면, 이는 Monolithic가 아닌가? 라는 의문이 들었기 때문이다. 또한 요새 많이 핫한 MSA 즉 Microservice Architecture를 생각했을 때, 단순히 서버를 여러 개 갖고 있다고 하여 MSA는 아닌 것 같았다. 그렇다면 Monolithic Architecture의 정확한 의미가 무엇인가? 아니 그전에 Monolithic와 Microservice 정확히 구분 짓는 기준이 무엇인가?

Monolithic와 Microservice를 구분 짓는 기준: 기능

위 2개를 구분짓는 기준은 바로 기능이다. 어떤 기능? 그것은 바로 서버의 기능이다. 아니 더 정확하게는 해당 어플리케이션이 갖고 있는 서비스 기능이다.

😳 본론

🙋🏻 Monolithic

말 그대로 기능을 하나로 모아놨다는 것이다. 서비스가 갖고 있는 기능을 하나로 모은 아키텍처로 서버 하나로 서비스 내에 존재하는 모든 기능을 수행할 수 있다. 그렇기 때문에 서버가 몇개야? 라는 의미와는 다르다. 엄밀히 이야기 했을 때 Monolithic는 해당 어플리케이션이 갖추어야 할 모든 기능을 하나의 아키텍처 안에서 구동할 수 있도록 만들어 놓은 것으로 작은 서비스 또는 과한 트래픽이 몰리지 않는 서비스의 경우 대부분 Monolithic 방법을 선택하여 서버를 가동시키게 된다. 가장 간단한 방법이기도 하고 무조건적으로 나쁘다고 이야기할 수 없기 때문에, 안좋은 시선으로 바라보지 말자. 대부분의 웹개발 또는 앱 개발자가 RESTful API를 활용하여 서비스를 개발할 때 처음으로 선택하는 방법이기도 하고 Monolithic가 있었기 때문에 Microservice가 나올 수 있었던 것이기도 하다.

그렇다면 이제 필자가 생각했을 때 헷갈리지 말아야 하는 것은 단순히 서버 증설했다라는 그런 이야기는 Microservice를 의미하지 않는다는 것이다.
정리하자면 다음과 같다.

서비스가 갖추어야할 모든 기능을 하나의 서버에 담아서 운영하는 아키텍처

그러면 Microservice에 들어가기 전에 왜 Microservice가 Hot해졌을까? 아니 그전에 MSA는 왜 나온 것일까?

😢 MSA가 유명해진 이유

배달의 민족을 모르는 사람은 없다고 생각한다. MSA가 나온 배경이기 보다는 MSA가 많이 알려졌던 계기가 된 것은 바로 배민의 역할이 가장 컸던 것 같다. 여튼 지금으로부터 5, 6년 전 스토리를 이야기 해보자.

배민도 처음에 php 기반인 Monolithic 서버를 운영하고 있었다. 많은 배달 앱 중에서 당연히 배민의 성장은 엄청났다. J곡선을 타려고 하는 그 순간 배민의 생존에 가장 큰 걸림돌이가 되는 것이 있었으니, 그것이 바로 Architecture이다. 기억하고 있는 사람이 많겠지만 과거의 기억을 상기시켜보자. 혹시 배민이 이벤트를 열었을 때 항상 서버가 터졌었다는 것을 알고 있는가? 당시 배민에서 한번에 수용할 수 있는 트래픽은 그렇게 많지 않았다고 한다.(김영한님의 피셜) 월 주문건수 10만건을 기록했을 시기였기에, php로 만든 서버로도 해당 트래픽을 충분히 감당할 수 있었다고 한다. 하지만, 갑작스럽게 과도한 트래픽이 몰렸을 때는 매번 서버가 터지는 상황이 일어났다고 한다. 따라서 항상 복구중이닭!이라는 View가 보였었다. 그때 배민이 어떤 시기였는지 생각해보면, 스타트업 3, 4년 차였으며, 배달앱 경쟁구도가 나름 심해질 때였다. 필자의 경우 사실 배민보다는 요기요 광고를 더 많이 봤지만, 서비스 경쟁에 있어 배민이 다른 어떤 앱보다 좋은 기능을 갖고 있었던 것을 확실하다. 그렇기 때문에, 한 줄로 요약하자면 해당 경쟁에서 지면, 배민은 이후 고착화된 배달 시장에서 도태될 수 가능성, 즉 위험성을 품고 있었다. 즉 한 기업의 생존과 연관되어 있었다. 그때 배민은 Monolithic 보다는 새로운 도전을 하게 된다. 그것이 바로 Microservice이다.

그렇기 때문에 조금씩 서버의 생김새를 변경하려고 하는 조짐을 보이기 시작했다. 배민은 기존에 있었던 On Premise 방식의 서버 운영을 중단하고 Cloud로 변경하게 된다. 또한 php에서 Java기반의 Spring으로 서버 프레임 워크도 바꾸게 된다.

그리고 본론으로 돌아와서 Microservice가 유명해진 계기는 외국에서는 NetFlix, 한국에서는 배민이라는 회사가 기업의 생존과 직결된 문제를 해결하기 위해 노력했고, 그 결과 Microservice의 성공적인 이전과 그로 인해 서비스 경쟁에서 우위를 자치했기 때문이다.

🤔 그래서 마이크로서비스가 도대제 뭔데?

Microservice Architecture는 말 그대로 서버를 서비스의 기능별로 분리 시켜 세분화 한 것을 의미한다. 그럼 얼마나 분리시켜야 MSA인가? 그런 기준은 없는 것으로 안다. 완벽한 MSA는 사람의 시각에 따라 다르게 볼 수 있기 때문에, 기준은 애매하다. 하지만, 확실한 것은 하나의 서버에 모든 기능이 수록되어 있으면 MSA는 아니다.

🤔 Microservice

보다 더 정확한 사전적인 정의는 다음과 같다.

단일 프로그램을 각 컴포넌트로 나누어 작은 서비스의 조합으로 구성하는 방법.

이때 각각의 서비스는 독립된 서비스이기 때문에, 하나의 서버가 터지거나 닫힌다고 해도 나머지 기능은 모두 유지된다. 서로의 의존성을 삭제시킨 것이다. 그렇기 때문에 특정 기능에 트래픽이 몰린다면, 해당 기능을 갖는 서버를 확장시키면, 끝난다.

또한 데이터를 저장할 때 하나의 DB로 중앙 집중적인 경향이 아닌 서비스 별로의 별도의 데이터 베이스를 사용한다. 그렇기 때문에 Monolithic는 하나의 DB에 과도한 트래픽이 몰려 DB가 터지는 경우가 생기는데, MSA는 이러한 리스크를 많이 줄일 수 있도록 한다. 하지만 MSA에서 문제가 발생할 수 있는 것은 A 기능을 당담하는 서버에서 B 기능을 담당하는 서버에서 관리하는 DB에 대해 API요청이 많아진다면, 성능상 문제가 발생할 수도 있고 트랜잭션으로 묶을 수 없는 문제가 발생하기도 한다.

무엇보다 일단 만들기가 어렵다. 아키텍처 구조를 처음부터 다시 손봐야하기 때문이다. 그리고 자칫 모놀릭스보다 속도가 저하될 가능성도 내포되어 있으며, 서버 내부적인 프로세스가 훨씬 더 복잡하게 변하게 된다. 그 이유는 MSA의 경우 내부 프로세스가 아닌 서버 API를 통해 각각의 서버가 통신하기 때문에, 통신을 하기 위해 데이터 값을 변환시켜줄 때 overhead가 발생하게 된다.

overhead : 간접적으로 원인으로 발생하는 지연시간

📝 결론

최근 백엔드 직군 채용 요구사항을 보면, MSA를 경험한 분이라는 키워드가 자주 등장한다. 그만큼 많은 기업에서 MSA 방식의 아키텍처를 도입하려는 움직임을 보이고 있다는 것인데, 결론적으로 이야기하자면, 무조건적으로 MSA로 서버를 구성해야 한다는 의미는 아니다. 해당 기업에 필요한 기술인지, 왜 MSA로 변경해야 하는지? 면밀히 조사한 이후에 접근해야 한다. 그리고 만약에 개발자를 희망하고 있다면, 개인적인 생각으로 MSA 방식은 꼭 공부해볼 것을 추천한다. 나는 백엔드 개발자는 아니다. 현재 Frontend나 안드로이드 직군에 관심이 생겨 공부를 지속하고 있으나, 해당 아키텍처 내용을 알고있는 것과 아닌 것은 개발 프로세스를 이해하는 데 있어 큰 도움이 될 것으로 생각한다.