MSA (Micro Service Architecture)

MSA(Micro Service Architecture)

• 클라이언트 개발자보다는 서버 개발자가 더 관심을 가지는 내용
• 마이크로 서비스는 최근에 나온 아키텍쳐가 아니고 옛날부터 존재했던 아키텍쳐이다.
• 다만 최신 개발 트렌드로 많이 언급되는 주제이다.
• MSA가 절대적으로 좋은 것이 아니라 자신이 속해 있는 팀과 개발, 배포 방식에 맞는 아키텍쳐를 적용하는 것이 유리하다.
• MSA이전의 아키텍처라고 할 수 있는 가장 기본적인 형태의 아키텍처인 모놀리틱 아키텍처를 먼저 보겠다.

• 모놀리틱 아키텍처

  • 모놀리틱 아키텍처는 최근 서비스 구성의 관점에서보면 단점이 있다.
  • 쉽게 말하자면, 서버 한 대에 DB나 API를 둔 뒤에 서버 한대로 배포를 진행하는 방식이라고 볼 수 있다.
  • 그렇기 때문에 예를 들면 서비스가 약간 크다고 하더라도 회원 API, 게시판 API 등 다양한 API가 모두 서버 한 대 위에 올라가서 구동되는 등 그러한 구조를 보인다.
  • 이와 다르게 마이크로 서비스 아키텍처는 다음과 같다.

• 마이크로 서비스 아키텍처(MSA)

  • 쉽게 말하자면, 서버가 여러대 있는 것이다.
  • 여러 대의 서버에서 서로 각기 다른 API나 특정한 서버 모듈을 제공함으로써 특정한 서버 한 대에 많은 부하가 몰리지 않는 방식이다.
  • 여기서 말하는 서버는, 물리적인 의미의 서버가 될 수도 있겠지만 컨테이너의 개념으로도 이해할 수 있다.
  • 즉 서버 한대에 컨테이너를 여러개 띄워서, 각 컨테이너가 서로 다른 API를 구동시킬 수 있도록 하는 것이다.
  • 이렇게 하면 특정한 컨테이너의 API에 오류가 발생해 다운되었을 때 그 특정한 API 서버만 다운이 되기 때문에 즉시 쉽게 복구할 수 있다.
  • 즉, 서버라는 개념 자체를 컨테이너의 개념으로 바꾸어서 특정한 서버가 망가지거나, 동작하지 않는 경우에는 단순히 컨테이너를 다시 띄우는 방식으로 서비스를 재개할 수 있는 것이다.
  • 다시 말해, 기존의 모놀리틱 서버는 서버에 장애가 발생하는 경우 서버 전체를 재부팅하는 등의 불상사가 발생할 수 있다.
  • 그러나, 서비스를 굉장히 마이크로하게 운영하게 되면 특정한 문제가 발생했을 때 이를 복구하는 것 또한 편해진다.
  • 나아가서 컨테이너를 운영하는 과정에 있어서, 무중단 배포(CI)와 같은 사용자 친화적인 배포 체계 또한 쉽게 갖출 수 있다.
  • 다만 마이크로 서비스 아키텍처가 반드시 유리한 것만은 아니다.
  • 마이크로 서비스 아키텍처는 다소 개발자간 분업 구조가 잘 이루어져 있고, 에자일하며 중앙 집중적이지 않은 팀일 수록 조ㅓㄱ용하기 유리한 편이다.
  • 반면에 서비스 자체가 규모가 작거나 복잡하지 않거나, 팀 규모가 작아서 사실상 소수의 인원이 주요 개발 인력인 경우에는 굳이 MSA를 적용하지 않고 모놀리틱하게 개발을 했을 때 결과가 더 좋을 수 있다.
  • 그래서 모든 서비스에 있어서 마이크로 서비스 아키텍처가 항상 유리하다고 말할 수 없다.
  • 서비스의 구성과 팀의 특성에 따라 적절한 아키텍처를 선택하여 개발 및 배포를 하는 것이 좋은 선택이다.
  • 그래서 실제 최근 중견, 중소, 유니콘 스타트업을 보았을 때에도 상대적으로 MSA를 적용하고 있는 서비스도 증가하고 있다.
  • 대표적으로 배민, 타다 등의 기업에서도 MSA를 이용중이다.
  • 얼마 전까지만 해도 배포 체계를 갖추기 위해서 DevOps를 위한 준비를 오랫동안 했어야 했지만 최근에는 그러한 비용 자체가 많이 절감된 상태이다. 배포 자동화가 많은 팀들에게 열려있다.

• 도커(Docker)

  • 일반적으로 다수의 개발자는 깃을 이용해서 코드를 업로드하고, 다양한 충돌(Conflict)를 조율하면서 프로젝트를 이끌어 나간다.
  • 일반적으로 서버 API 개발자는 자신이 새롭게 개발한 내용을 깃에 커밋(Commit)한다.
  • 그러면 서버 엔지니어는 해당 업데이트가 된 API를 서버에 내려 받아 서버에서 구동할 수 있도록 한다.(Git Pull)
  • 이러한 과정 자체도 분업 구조가 잘 갖추어져 있다면 그렇게 복잡하지는 않겠지만 우리는 더 편하게 개발할 수 있는 환경을 갖추고자 한다.
  • 그래서 특정 서버 API 환경이 있을 때, 이를 즉시 구동시킬 수 있는 서버 자체를 이미지화해서 기록을 해놓는 것이다.
  • 나중에 필요할 때 그 이미지를 컨테이너로 띄워주면서 바로 배포를 진행할 수 있다.
  • 실제로 도커 이미지는 한 번 만들어 놓으면 컨테이너로 띄우는 과정은 굉장히 짧은 시간이 걸린다.
  • 그렇기 때문에 한 번 이미지를 잘 구워 놓으면 실제로 API 개발자가 개발을 마쳤을 때, 이를 배포하는 과정이 간단해지는 것이다.
  • 테스트 또한 매끄럽게 진행될 수 있다.
  • 그래서 그렇게 도커에 젠킨스도 자주 붙인다.

• 젠킨스(Jenkins)

  • 젠킨스는 도커와 마찬가지로 배포 도구 중 하나이다.
  • 어떠한 상황에서 어떠한 방식으로 배포가 진행될 지를 결정하도록 도와주는 도구라고 할 수 있다.
  • 깃 허브에 푸시만 하면 자동으로 배포가 진행될 수 있도록 처리하는 경우가 많다.
  • 다시 말해 젠킨스 서버를 하나 띄워놓게 되면, 이를 깃과 연동하여 깃에 푸시를 하면 주기적으로 웹 훅으로 체크를 하기 때문에 개인 컴퓨터로 개발을 한 뒤, 마스터 브랜치로 푸시를 하게 되면 자동으로 젠킨스 서버에서 이를 감지하여 배포까지 진행하는 것이다.