마이크로 서비스 아키텍처로 개발하기

안녕하세요, Platform Architecture팀 안재우 매니저입니다.

지난 3월에 오픈테크넷 서밋에서, 그리고 4월에 사내 기술 세미나에서 발표한 ‘마이크로 서비스 아키텍처로 개발하기’라는 주제를 발표하였습니다.

최근 많이 언급되고 있는 마이크로 서비스 아키텍처(MSA)는 기능을 서비스 단위로 분할한다는 오래된 개념을 다시 한번 재조명한 것으로, 10여년 전에 등장했던 SOA에서 얘기했던 것과 기본적인 목표는 별반 다르지 않습니다. 다만 SOA가 ESB라는 제품과 이를 공급하던 벤더 기반으로 전개되었던 것에 비해, MSA는 글로벌 서비스 업체들이 자신들의 서비스를 확장하는 과정에서 자연스럽게 진화화게 된 결과물이며, 다양한 기술의 출현이나 Agile의 확산으로 인한 개발 문화의 변경, 클라우드 환경 등 다양한 요인들이 작용하고 있습니다.

MSA로 개발을 하기 위해서는 Monolithic 구조에 비해 마이크로 서비스 아키텍처가 가지는 특성과 장단점을 명확하게 이해할 필요가 있습니다. 뭔가 요즘 자주 언급되는 트렌드인 듯 해서 무작정 도입하기 보다는 이 구조가 우리에게 적합하고 어떠한 장점이 있는지에 대한 충분한 검토가 필요합니다. 그렇지 않고 무작정 도입을 했다가는 SOA 시절에 겪었던 실패를 다시 한번 겪게 될 지도 모릅니다.

저희 팀은 SK플래닛에서 API 관리 플랫폼(API Management Platform)을 담당하고 있으며, SK플래닛의 기술 자산들을 관리하고 이를 내부 및 외부에 API나 SDK 형태로 서비스하기 위한 API Gateway 및 개발자센터를 운영하고 있기도 합니다. 그런데, 이 시스템들을 하나씩 개편해나가기 시작하면서, 아키텍처적인 변화의 방향뿐만 아니라 앞으로 조직 내에서 개발 문화를 어떻게 변화시켜나갈 것인가를 고민하게 되었습니다. 이러한 고민과 MSA가 채택되기 까지의 과정은 다음에서 보시면 되겠습니다.

MSA를 적용하게 된 첫 시도는 아래 동영상에서도 잠깐 나오겠지만 @mos(atmos.skplanet.com)라고 불리는 사내 개발자센터입니다. 참고로 사내 시스템이므로 외부에서 접속을 시도하셔도 연결이 되지 않습니다.
SK 플래닛 개발자는 이 곳에서 자신의 조직에서 개발하는 Product를 추가하고, Product가 제공하는 API의 Spec과 SDK를 관리할 수 있으며, 해당 Product를 사용하기 위한 Subscription 절차를 설정할 수 있습니다. 또한 회사 내에 Product들을 살펴보고, 해당 Product 들이 제공하는 API나 SDK를 확인하고 사용 신청을 하거나 바로 API를 테스트해볼 수도 있습니다.

그런데, 최초에 이를 추진할 때도 그렇고, 오픈을 한 이후에도 많이 들은 얘기 중 하나가 굳이 이 시스템을 MSA로 구현해야 하는 이유가 있는가라는 질문이었습니다. 특히 각 Micro-Service의 독립성을 유지하기 위해 VM당 1개의 Micro-Service를 배치하게 되면서 결과적으로 수십 개의 VM을 사용하고 있는 점에 깜짝 놀라는 분도 계시더군요.

사실 저희도 VM을 이렇게 다량 사용하는 것을 원하지 않았습니다. MSA에서도 최선의 형태이자 저희가 원하기도 한 형태는 Micro-Service 1개를 컨테이너 1개로 대응시키는 것입니다만, 안타깝게도 아직 저희 회사 내에는 컨테이너 환경이 상용에는 구축되어 있지 않습니다. 그렇기에 현재 시점에 가능한 것은 Micro-Service 1개를 VM 1개에 대응시키는 선택을 할 수 밖에 없었습니다. VM을 큰 걸로 몇 개 둘 것이냐, 작은 걸로 수십 개를 둘 것이냐라는 질문에서, 관리적 이슈의 문제가 없다면 MSA에서는 후자가 더 선호됩니다. (AWS와 같은 public 클라우드에서도 후자가 오히려 더 비용이 저렴한 경우가 많습니다.) 물론 독립성과 리소스 운영의 효율성 문제 간에는 적절한 고려가 필요합니다. Micro-Service의 격리를 위해 각각의 VM을 별도로 사용하는 것은 분명 리소스 효율성은 떨어집니다. 그 때문에 저희 팀에서는 Docker 기반의 컨테이너 인프라를 사내에 구축하기 위한 프로젝트를 같이 진행하고 있으며, 이 환경이 구축되는 대로 컨테이너당 Micro-Service 1개를 배치하는 형태로 전환할 예정입니다.

저희 역시 당장 필요한 시스템을 구축하는 것까지만 생각했다면, 굳이 MSA를 선택하지 않았을지도 모릅니다. 그러나 만들었다가 몇 년 뒤에 갈아 엎어야 하는 시스템을 만들기보다는 당장 고생스럽더라도 끊임없이 진화-발전해나갈 수 있는 시스템을 만들어보고, 시행 착오에서 나오는 경험과 기반 시스템들을 공유해보고 싶었습니다. 최소한 팀 내부에서라도 그 과정에서 얻어진 것들은 이후 프로젝트를 추진하는데 있어서도 공유 및 재활용이 이루어지고 있습니다. 무엇보다도 MSA가 가지는 기술적인 의미보다는, MSA의 배경이 되는 개발 문화의 구축에 더 초점을 두고 싶습니다.

얘기가 길었는데, 자세한 내용은 아래의 슬라이드와 동영상을 참고하시면 되겠습니다. 시간적인 제약 상 자세한 얘기는 모두 다 하지 못하였지만, 전체적인 내용을 이해하시는 데는 별 어려움이 없으시리라 생각됩니다. 더 궁금하신 내용은 덧글이나 메일로… 🙂 부탁 드립니다.

감사합니다!

안재우 Platform Architecture팀

‘입 개발보다는 손 코딩’, ‘코드를 잘 짜면 그림도 문서도 필요 없다’, ‘Dog Fooding은 당연히 해야 하는 것’, ‘시스템은 오픈하면 끝나는 것이 아니라 오픈하고 나서가 시작이다’, ‘API가 없는 시스템은 죽은(또는 곧 죽을) 시스템’, ‘만드는 개발자도 좋아하지 않는 시스템은 사용자를 절대 만족시킬 수 없다’는 고집을 피우며, 아키텍트 행세를 하고 있는 퇴물 개발자.

공유하기