MSA(Microservices Architecture) 개념 및 장단점 정리

MSA(Microservices Architecture) 개념을 알기에 앞서

모놀리식(Monolithic) 아키텍처를 이해해둘 필요가 있는데

 

모놀리식 아키텍처란 한 프로젝트 안에

모든게 다 들어있는 형식을 말하는데

 

지금 위 프로젝트도 모놀리식이고

실제 업무시에도 대부분의 프로젝트가

모놀리식으로 되어있는 걸 쉽게 확인할 수 있다

 

반면 MSA는 여러 프로젝트(서비스)를 만든 뒤

그 프로젝트들을 연결해서 사용하는 형태를 말하는데

말로만 들으면 감이 잘 안올테니 예제를 하나 보자면

 

위 스크린샷은 네이버 접속 시 화면인데

검색 창 하단에

메일, 카페, 블로그, 지식IN 쇼핑, 페이 티비 뉴스 등등이 보인다

 

여기서 메일, 카페, 블로그 등등이

네이버라는 하나의 프로젝트 안에 들어있는 게 아니라

 

메일 프로젝트, 카페 프로젝트, 블로그 프로젝트가

다 따로 존재하고

각각의 프로젝트들을 API와 MQ 등으로 연결한다

API가 뭔말?

Message Queue(MQ) 개념정리

근데 이런 생각이 자연스럽게 들게 된다

뭣하러 그렇게 연결하지?

하나에 다 넣어도 되지 않나?

 

여기서 자연스럽게 MSA를 사용하는 이유가 나오는데

사람이 많이 이용하고 금전이 많이 움직이는 서비스일 수록

서버가 잠깐만 멈춰도 큰일이 난다

 

가령 네이버의 이메일 쪽에 뭘 추가하려고

네이버 전체를 1~2시간 내린다고 생각을 해 보자

 

네이버를 동시에 이용하는 사람이 수십만명인데

네이버 잠깐 멈추면 1~2시간 동안 얼마나 큰 손해를 보겠나

 

여기에 검수 제대로 안하고 파일 올려가지고

에러라도 나서 서버가 수 시간 멈춘다 치면

걷잡을 수 없을 정도로 많은 돈이 날아가는 거다

(이거 몇번 반복하면 해고다)

 

모놀리식이라면 필사즉생의 각오로

서버를 내렸다 올려야 하겠지만

MSA는 각 파트별로 프로젝트가 나눠져 있기 때문에

이메일의 기능을 바꾼다 치면

이메일 서버만 내렸다가 다시 올려주면 된다

 

이런 과정에서 어딘가가 잘못되서 에러가 발생해

이메일을 제대로 사용하지 못한다고 한들

문제는 이메일 서버에만 있기 때문에 이메일을 못 쓰는거지

웹툰을 본다던가 혹은 뉴스를 보는데에는 아무 문제가 없다

 

애초에 프로젝트 자체가 다르기 때문에..

 

이것 외에도 MSA의 장점은 다음과 같은데

 

1. 독립적으로 배포 가능하고 개발자의 자율성 증가

모놀리식의 경우에는 서버를 내린 후

변경사항을 한번에 적용하기 때문에

내가 A 부분을 다 개발했는데

다른 사람이 B 부분을 개발하지 못했다면

다른 사람들이 모두 완성할 때까지 그냥 놀고 있으면 된다

 

반면 MSA의 경우에는

파트별로 다 프로젝트가 따로 돌아가기 때문에

남이 만들건 말건 언제든지 내가 만든 내용을 적용시킬 수 있으니

전체 일정과는 별개로 내 파트를 계속 개발 가능하다

 

2. 장애나는 서비스 격리를 통한 서버 재기동 시간 단축

모놀리식의 경우에는 A-Z 까지의 기능 중

A 하나만 고장이 나도

모든 기능이 한 서버에 연결되어 있어서

전체 서버를 내렸다가 다시 올려야 한다

 

서비스가 커지면 커질수록 뭔가를 바꾸려면

결국 서버를 내려야 하기 때문에

서비스의 변화 자체가 매우 느려진다

 

반면 MSA의 경우에는 장애나는 서비스만 서버를 내린 뒤

문제를 고치고 다시 올려주면 되기 때문에

서비스 전체가 멈추는 일이 없어지고

뭔가 에러가 나도 그 부분만 막아버리면 되기에

서비스 자체를 안정적으로 계속 사용할 수 있게 된다

 

3. 팀별 코드 이해도 증가 및 유지보수 난이도 저하

모놀리식의 경우에는 뭐 에러 하나 발생하면

디버그를 타고 프로젝트 전체를 쑤시고 다녀야 하는데

MSA의 경우에는 API만 문제가 없으면

본인들 프로젝트만 확인하면 되기에

유지보수 난이도가 확 떨어지고

 

다른 프로젝트들과는 API를 이용해 통신하기 때문에

내 코드만 이해하면 되서

전체 코드를 더 쉽게 이해할 수 있다

 

여기까지 장점을 보면 MSA가 최곤데 모놀리식 왜쓰지?

이런 생각이 들겠지만

하지만 MSA라고 좋기만 한 게 아니니

MSA의 단점은 다음과 같다

 

1. 유지보수 난이도 증가

아까 유지보수 난이도 내려간다 해놓고

또 올라간다는건 뭐지? 지금 장난?

이런 생각이 들 수 있겠지만

MSA는 모놀리식과는 다른 방향으로

 유지보수의 난이도가 올라가는데

 

일단 각 부분이 다른 프로젝트기 때문에

디버그를 하려고 해도 뭐만하면 다른 프로젝트로 넘어가는데

난 그 프로젝트가 있지도 않으니 넘어간 이후에는

타 부서에 물어봐서 해결해야 하는 수준이 된다

 

뭐 하나 고치려다가 프로세스가 다른 프로젝트로 넘어간 뒤

이상한 값을 가지고 돌아왔다면

이제 사방을 돌아다니며 물어보는 처지가 되는거다

 

그리고 API를 이용해 통신하기 때문에

내 파트만 확인하는 단위 테스트는 금방 끝나지만

다른 파트까지 왔다갔다 하는 통합 테스트의 경우에는

모놀리식보다 훨씬 오랜 시간과 노동이 들어간다

 

2. API 관리의 중요성 증가

MSA는 API를 이용해 각 서비스들을 연결해 주는데

문제는 API를 변경할 경우

수십~수백개의 프로젝트들과 호환이 되는지 확인해 줘야하고

호환이 안되면 바로 대참사가 벌어지는 거다

 

애초에 한 서비스가 고장나도

전체 서비스에는 문제가 없도록 하려고 만든게 MSA인데

그걸 연결해주는 API에서 에러가 발생하면 전체 서비스가 마비된다

 

3. 모놀리식보다 더 비싼 비용이 듬

모놀리식의 경우에는 모든 기능이 한 프로젝트 안에 들어있으니

변경도 서버 하나만 내렸다 올리면 되는데

이게 단점일 수도 있겠지만

 

대기업의 시스템이라고 해도 많아봤자

몇백~몇천명이 사용하는데 이러면 변경 내용이 적을 경우

 

점심시간에 서버 잠깐 내렸다가 올리거나

퇴근 시간 이후에 잠깐 내렸다가 올리면 된다

내리는 동안은 어쩌구? 싶겠지만

애초에 그렇게 많은 사람이 사용하지 않기 때문에

잠깐 내렸다가 올린다고 큰일이 나지는 않는다

 

서버가 잠깐 멈춰도 엄청난 손실이 발생하는게 아니라거나

혹은 자주 업데이트가 필요하지 않은 서비스라면

굳이 손 많이 가는 MSA를 사용할 필요 없이

모놀리식이 훨씬 경제적이다

 

정리해보자면 MSA는 엄청나게 많은 트래픽이 발생하거나

혹은 많은 돈이 움직이는 서비스,

지속적으로 개발을 하는 서비스에서 주로 사용하게 되는데

자주 보게되는 예제는 포털 사이트, 쇼핑몰 등이 해당한다

 

그 외에는 MSA보다는 모놀리식이 더 유용한 방식이 되겠다