마이크로 서비스 아키텍쳐 - MSA

MSA란?

기존의 서비스는 모노리식(Monolithic ) 아키텍쳐였습니다. 하나의 애플리케이션안에 모든 비즈니스 로직이 들어가있는 구조인 것이죠.

이렇게 모든 비즈니스 로직이 하나로 되어있었기 때문에, 모노리식 아키텍쳐는 여러가지 단점을 갖고있었습니다.

• 개발 유연성의 한계
• 요구사항 대처 시간 소요
• 장애 격리 / 신뢰성
• 배포 / 롤백 리스크
• 리소스 낭비

아무래도 하나의 커다란 애플리케이션이다보니 개발하는데에 있어서 부분을 수정하려 해도 반드시 모든 비즈니스 로직을 가져와야 해서 개발 유연성도 떨어지고, 만약 에러가 발생하면 일정 부분의 문제인데도 사이트 전체가 마비된다던지, 배포나 롤백을 할때도 하나의 기능을 배포하고 롤백하기 위해서 모두가 대기해야 하는 일까지 발생했습니다.

이 모든 문제점은 바로 여러 기능이 뭉쳐서 강하게 결합 되었기 떄문에 발생하는 문제들이었죠.

그래서 개발자들은 이 기능들을 쪼개보기로 했습니다.

이것이 바로 마이크로 서비스 아키텍쳐 (Micro Service Architecture) 입니다.

마이크로 서비스 아키텍쳐를 그림으로 나타내면 위의 그림과 같은데요. 하나의 서비스가 아닌 여러개의 마이크로 서비스로 나누어, 심지어는 DB조차 각자의 DB를 갖고있는 것을 확인할 수 있습니다. 이들은 각각의 서비스로 독립되어 있으며, 서로 API를 통해서 통신하며 전체의 서비스가 동작하도록 합니다.

만약 우리가 프로그램을 개발할 때, 로직을 하나의 메인함수에 모두 구현하게 된다면 어떨까요?
유지보수가 어려울 뿐더러, 하나의 기능에서만 문제가 발생해도 프로그램 전체가 다운될 것입니다. 그래서 프로그램을 개발할때도 좋은 프로그램은 최대한 클래스가 분리되어있고 함수가 분리되어있는 프로그램이죠.

그래서 마이크로 서비스 아키텍쳐도 이와 같이 하나의 큰 서비스를 유지보수하고 배포하기 편리 하도록 여러개의 어플리케이션으로 나누어 조금 더 효율적인 개발을 할 수 있도록 한 것입니다.

그렇다면, 마이크로 서비스 아키텍쳐가 기존의 모노리식 아키텍쳐에 비해 어떤 장점들이 있는지 자세하게 알아보겠습니다.

MSA의 장점

• 기존 방식에 비해 새로운 기능 추가 및 업데이트가 간편하다.

모노리식 방식은 소프트웨어의 모든 구성 요소가 한 프로젝트에 합쳐져 있어서 큰 변화에 대응이 어렵고, 새로운 기능 추가 및 업데이트를 할 때마다 프로젝트 전체를 배포하고 업데이트해야해서 어려움이 있었습니다.

하지만 마이크로 서비스 아키텍쳐는 요소들이 나뉘어져 있기때문에, 하나의 서비스만 유지보수하고 업데이트가 가능합니다.

• 하나의 서비스가 문제가 있다면, 하나의 서버에만 장애가 발생한다.

기존의 서비스는 하나의 장애가 전체 서버의 장애을 일으키지만, 마이크로 서비스 아키텍쳐는 해당 기능의 서버에만 장애가 발생하기 때문에 서비스가 비교적 안정합니다.

• 필요한 자원만 Scale-Out할 수있다.

AWS등의 클라우드 서비스를 이용하면 간단하게 서버의 리소스를 늘릴 수 있습니다. 하지만 모노리식의 경우는 모든 프로젝트가 하나이기 때문에, 한 기능에서의 리소스를 증가시키고 싶다면 서버전체의 리소스를 올려야 합니다.

하지만 마이크로 서비스 아키텍쳐는 해당 기능을 담당하는 서버의 리소스만 증가시켜주면 되기 때문에, 조금 더 효율적으로 자원을 사용할 수 있습니다.

• 민첩하고 손쉬운 배포 및 업데이트

기존 방식은 프로젝트가 하나로 되어있기 때문에, 배포와 업데이트를 할 때 항상 모든 파일 전체를 배포하고 업데이트 합니다. 이것은 개발자 입장에서 굉장히 리스크가 있는 방식입니다.

하지만 마이크로 서비스 아키텍쳐는 Blue-Green 배포 방식을 사용합니다. 이 배포방식은 Blue와 Green 두개의 인스턴스를 만들어놓고, 예를 들어 Green에서 현재 버젼의 서비스가 동작하고 있다면, Blue에 먼저 새로운 버젼의 서비스를 올려 테스트 해봅니다. 만약 Blue의 새로운 버젼의 서비스가 잘 동작한다면, Green으로 오던 트래픽을 Blue로 옮겨주는 것입니다. 이렇게 한다면 만약에 새로운 버젼에서 오류가 발생한다 해도, 바로 원래의 Green으로 트래픽을 옮겨주면 서비스가 정상적으로 동작하게 될 것입니다.

기존방식과 달리 롤백이 가능하기 때문에, 배포에서 발생가능한 위험을 최소화 할 수 있습니다.

이렇게 마이크로 서비스는 다양한 장점을 갖고있습니다. 하지만 모든 방법들이 그렇듯, 한가지의 방법이 압도적으로 좋아서 무조건 이 방법만을 사용하면 되는 것은 아닙니다.

그렇다면 MSA는 어떤 상황에서 적용해야하고, 적용했을 때 어떤점에 주의해야 할까요?

MSA를 적용하기 전

먼저, 빠르고 잦은 배포가 필요하며, 성능에 어느정도 민감한 서비스인지 생각해봐야합니다.

아무래도 MSA는 여러가지의 서비스로 이루어져있기 때문에, 서비스간의 통신이 잦아집니다. 하나의 서비스가 작동할 때보다는 여러개의 서비스가 통신해야 하기 때문에 퍼포먼스가 감소할 수 밖에 없게 됩니다. 그래서 성능에 매우 민감한 서비스라면, MSA를 적용하기 전에 충분히 고려해보아야 합니다.

또, 트랜잭션 유지가 어렵기 때문에, 이에 각별히 신경써야 합니다.

기존에는 하나의 단일 DB를 사용하기 때문에 DB가 기본적으로 제공하는 트랜잭션 기능, 커밋 롤백등을 사용해 데이터를 안정적으로 관리할 수 있었지만, MSA는 DB가 분산되어 있기 때문에 단일 DB의 트랜잭션으로는 이를 해결할 수 없습니다.

마지막으로, 서비스가 많기 때문에 반드시 배포와 릴리즈를 자동화 해야합니다.

만약 자동화 되지 않은 상태로 배포와 릴리즈를 한다면, 하나하나의 서비스들을 일일히 수작업으로 배포하고 릴리즈 해주어야 하는데, 이는 몹시 비효율적입니다.

마무리하며…

이처럼 마이크로 서비스 아키텍쳐는 많은 장점을 갖고있음과 동시에 고려해보아야할 여러가지 사항을 갖고있습니다. 그리고 아직 여러곳에서 적용하기 시작한지 얼마 되지않았기 때문에 레퍼런스도 부족하고, 이러한 경험이 있는 사람들이 잘 없기 때문에 바로 적용하기에는 쉽지 않은 방식입니다.

심지어 MSA로 전환하는 것은 개발의 기술을 바꾸는 것을 넘어 일하는 방식이 아예 바뀌는 큰 변화입니다. 따라서 손바닥 뒤집듯이 오늘부터 MSA 방식으로 가자! 할 수는 없는거죠.

하지만 그럼에도 요즘 대부분의 기업들이 MSA 방식을 점차 적용하는 것은, 분명히 MSA가 가진 장점이 현재의 비즈니스를 더 나은 방식으로 바꿔준다는 증거일 것입니다.

아마도 앞으로 더욱 더 모든 기업들이 점차 MSA 방식을 채택할 가능성이 커보이니, 원하는 기업에 가고싶다면 적어도 이러한 방식이 어떠한 장점과 단점이 있는지는 알아 두는 것이 좋을 것 같습니다.

자료출처

네이버 클라우드 플랫폼 유튜브