요즘 다들 클라우드로 서비스를 해야 한다고 하는 분들이 참 많은듯 합니다.

그리고 이런 클라우드의 서비스들을 나타내는 약자들이 있습니다

 - IaaS(Infrastructure as a Service)

 - PaaS(Platform as a Service)

 - SaaS(Software as a Service)

 - DaaS(Desktop as a Service)

오늘은 위 클라우드 서비스를 언급하기 보다는 클라우드와 밀접한 관련이 있는 MSA에 대해서 언급하고자 합니다.

MSA가 무엇이냐하면... MicroService Architecture 라고 합니다.

네이버 용어사전을 보면

"대규모 소프트웨어 개발에 적용하기 위한 것으로 단독으로 실행 가능하고 독립적으로 배치될 수 있는 작은 단위(모듈)로 기능을 분해하여 서비스 하는 아키텍처. 작은 단위로 기능을 분할할 때 수평 방향의 계층별 절단이 아니라, 수직 방향의 기능별로 절단한다. 절단된 독립적인 작은 모듈을 마이크로서비스라 한다. 각 마이크로서비스는 공유나 프로세스 간 통신이 없이도 독립적으로 실행되며 운영 관리된다. 마이크로서비스 간 연결은 응용 프로그래밍 인터페이스(API : Application Programming Service)를 이용한다. 마이크로서비스는 자원 표현이나 데이터 관리 등에 있어서 기능적으로 완전해야 한다.

마이크로서비스 아키텍처는 레고 블록을 조립하여 원하는 모양으로 만드는 것에 비유할 수 있다. 마이크로서비스 아키텍처 사용으로 개발자들이 클라우드 망을 통해 공유하고 협업하여 자유롭게 소프트웨어를 개발할 수 있으며, 개발 및 유지보수에 드는 시간과 비용이 절감할 수 있다. 단일 서비스로 개발하는 기존 모놀리식(monolithic) 방식과는 반대되며, 서비스 지향 아키텍처(SOA : Service-Oriented Architecture) 방식보다 더 세분화되어 있다.

"

어렵죠.. ^^ 용어들은 너무나 어려운듯 합니다.

간단하게 풀어보면 기존의 시스템 단위로 구성되어 있는 것을 서비스 단위 또는 기능단위로 구분하여 구성한다는 것입니다. 그래서 마이크로라는 단어가 붙어 있고 그것으로 시스템 구축을 하기 때문에 아키텍처라고 언급하게 됩니다. (이미지 참조)

<Monolithic 방식과 MSA 방식 비교>

그런데 왜 갑자기 MSA를 언급하냐하면 Cloud의 언급에 있어서 빠질 수 없는 요소이기 때문입니다.

우리가 흔히 말하는 시스템 구성은 이렇습니다.

IDC에 서버를 구축하고 그 서버에 DB/WEB/WAS를 구축하고 사용하고자 하는 시스템(HR, 재무, 총무 등)을 구축하는 것이 일반적입니다. 이런 방식을 monolithic 방식이라고 부릅니다. 하나에 다 있는 구조죠. 사실 IDC 형태의 구조에서는 나쁘지 않은 방식입니다. 이것이 문제가 되지 않는다는 것이죠.

■ Monolithic + Cloud

문제는 Cloud와 접목했을때 비효율적 측면이 증가하게 됩니다. Cloud는 기본적으로 사용량 기준으로 비용이 책정되므로 Cloud 기반 서비스를 구축할 경우는 최적화된 구조가 필요하게 됩니다. 일부에서는 monolithic 방식으로 구축된 것을 IaaS로 전환시키기도 하지만 이것은 안하느니만 못하는 결과를 가져올 수 있습니다.

일단 기본적으로 monolithic에 의해 구매되는 H/W는 일반 기업들은 감가상각 4년을 돌리며 해당 비용을 처리합니다. 즉 4년뒤는 비용이 들어가지 않게 되는것이죠. 그런데 Cloud는 그런게 없습니다. 장기간 사용한다고 저렴해지는 것도 아니기 때문에 사용자 입장에서는 과연 이것이 저렴한지 알수 없게됩니다. 사실 시뮬레이션을 해보면 더 비싼 경우도 존재합니다.

monolithic은 기본적으로 큰 덩어리로 시스템이 구축되어 있어서 사용하지 않는 서비스가 있어도 그것을 삭제한다고 해서 기본적인 스펙이 변하지 않는 구조 입니다. 그래서 효율화를 한다고 해도 한계가 존재하는 것이죠. monolithic방식에서는 이게 큰 문제가 되지 않습니다. 어차피 나간 돈이고 효율화를 한다고 해도 비용이 줄지 않기 때문이죠.

■ MSA + Cloud

하지만 MSA 방식으로 구성이 된 경우에는 Cloud에 맞게 최적화를 시킬 수 있습니다. 즉 서비스 단위로 기능을 구분하여 관리하고 사용하지 않는 기능 또는 일부 기능의 축소를 통해 효율화가 가능하다는 점입니다. 또한 확장도 자주 사용하는 기능 중심으로 하면 monolithic에 비해서 H/W의 비용도 절감할 수 있습니다.

또한 개선을 위해서는 monolithic의 경우 대규모 투자가 수반되어야 하지만 MSA의 경우는 해당 기능단위로 접근하므로 잘사용하는 것 중심으로 개선을 하여 효율적인 IT 운영관리가 가능하게 됩니다.

■ MSA 도입의 고려사항

여기까지 읽으신 셨다면 정말 MSA가 좋아보이죠.

하지만 단점도 명확하게 존재합니다. MSA로 만든다는 것은 기능단위의 시스템들이 많아진다는 것이고 결과적으로 인터페이스의 수가 늘어나는 부분이 있습니다. 오류가 발생하면 찾기 어려울 수 있다는 것이죠.

또한 디버깅도 힘들 수 있습니다.  단위가 쪼개져 있으므로 인해서 monolithic에서의 개발 및 운영측면에서는 관리하는 시스템이 늘어난것처럼 인식되고 실제 서버단위 개발의 어려움도 있을 수 있습니다.

하지만 이런 단점에도 불구하고 MSA로 가려고 하는 글로벌 기업들이 많은 이유는 바로 언제든지 쉽게 변경이 가능하고 클라우드환경을 적극적으로 활용할 수 있다는 점이 아닐까 합니다. 또한 관리적 입장에서 본다면 효율적 운영을 통해서 monolithic방식보다 비용적 측면에서 효과를 기대할 수도 있기 때문입니다.

MSA를 하기 위해서는 가장 중요한 것은 바로 서비스 구성을 설계하는 사람이 아닐까 합니다. 너무 많이 쪼개도 문제고 그렇다고 넓은 범위로 구성하면 기존과 차이가 없기 때문입니다. 관리의 기준과 운영의 효율성의 중간적 관점의 시도가 가장 중요하지 않을까 합니다.