마이크로서비스 Just Do It!

최근 개발 또는 운영하고 있는 서비스가 여러개의 작은 서비스로 의미 있는 서비스를 제공하고 있는 시스템 구성으로 되어 있습니다. 이를 최근 트렌드에 맞추어 보면 마이크로서비스 아키텍처 기반이라고도 이야기 할 수 있습니다.

최근 스타트업들이야 구성원들이 믿는 방식, 구성원들이 좋아하는 방식으로 진행하기 때문에 그것을 무엇이라 부르던 별로 신경을 쓰지 않겠지만 아직도 많은 큰 기업들은 이런 용어에 민감해 할 것입니다. 그리고 개발자들 중 일부도 이런 용어의 정의나 어떻게 하는 것이 베스트프랙티스인지에 대해 고민을 하기도 할 것 입니다.이런 분들을 위해서 친절하게 이런 글로도 정리되어 있습니다.

http://www.popit.kr/why-microservice/

저도 나이가 먹으니 무언가를 하기도 전에 이것 저것 챙기는 버릇이 생겼는데 새로운 환경에 와보니 지금 같이 빠르게 움직이는 환경에서 그런 걱정은 사치라는 것을 알게 되었습니다. 그런 의미에서 이번글에서는 3개월 남짓 새로운 환경에서 새로운 아키텍처를 접해본 내용을 공유해보려고 합니다. 처음 새로운 조직, 환경을 접하면서 이것저것 질문을 하면서 시스템을 이해하려고 했는데 그 질문으로 정리해보겠습니다.

왜 마이크로서비스아키텍처로 구성하였는가?

여기 대부분의 개발자들은 오랜 기간 동안 기존 운영중인 시스템의 유지보수 업무를 위주로 수행해 왔기 때문에 새로운 기능을 정의하고 자체적으로 만들어본 경험이 있는 개발자가 없다. 그리고 서비스의 기본 기능, 개념 등만 알려주면 다 알아서(?) 개발해주는 그런 형태로 업무를 진행하지 않는다.

이런 상황에서 다소 복잡할 수 있는 그림을 그려주고 설계, 개발까지 진행하기에는 무리라고 판단하여 각 개발자에게 일주일에 하나의 기능(또는 화면)만을 만들게 하였다. 단순히 만드는데 그치는 것이 아니라 배포하여 운영까지 반영되도록 하였다. 이렇게 개발자 한명은 짧은 기간에 하나의 기능을 만들기 때문에 자신이 만들어 내는 기능은 복잡하기 않고, 운영/배포 까지 쉽게 넘어갈 수 있게 되었다. 이런 작은 기능을 모아 전체 기능을 엮는 것을 Product Owner가 수행하였다. 이런 방식으로 진행하면서 결과적으로 설계 능력이 부족한 조직을 이끌고 한달만에 운영 서비스를 배포할 수 있게 되었다.  그렇게 성공 사례를 경험한 이후에는 이 방법으로 계속해서 진행하고 있다.

기능 갯수가 조금만 많아져도 운영, 배포가 복잡하지 않은가?

서비스 운영 및 배포는 클라우드 환경에서 Docker를 이용하여 배포하기 때문에 크게 문제가 되지 않는다. 각 서비스에는 Dockerfile을 기본적으로 구성하게 하여 누구나 쉽게 배포할 수 있도록 하였다. 초기에는 Docker Swarm을 이용하면서 Docker 운영에 대한 기술을 쌓은 후 최근에서는 Kubernetes로 이관하여 현재 운영은 k8s 기반으로 운영되고 있다. 최근 전체 서버의 가상 머신을 새로운 가상머신으로 교체하는 작업을 진행하였는데 각 서비스의 개발자 없이 인프라 운영팀만으로도 서비스 중단 없이 전체 서버를 교체할 수 있었다.

작은 서비스 별로 데이터는 어떻게 관리하나?

각 서비스에서 필요한 데이터는 서비스가 책임을 지는 방식으로 설계하고 운영한다. 마스터 성격에 데이터가 전달되면 해당 데이터를 메인으로 처리하는 서비스가 그것을 처리하고 이를 다시 이벤트 큐에 넣는 것으로 그 서비스의 역할은 다 하는 것이다. 그 이후에 그 데이터가 필요한 서비스들은 이벤트 큐에서 데이터를 가져다 스스로 가공하거나 저장해서 사용할 수 있다. 그외 각 서비스간에 관리하지 않는 데이터가 필요한 경우 API를 이용하여 데이터를 전달 받는다.

데이터의 종류가 많아지고 데이터베이스 구성이 많아지니 하나의 View로 데이터를 볼 수 있는 방법이 필요하기는 하다. 이 부분에서 필자의 도움이 필요하다. 하지만 각 서비스 관점에서는 필요하지는 않다.

서비스를 쪼개는 기준이 있나?

별도의 기준은 없이 그냥 자신이 만들 수 있는 수준까지만 만든다. 어떤 서비스는 하나의 서브 시스템처럼 큰 서비스도 있는 반면 어떤 서비스는 다른 서비스의 API만 엮어서 기능을 구성하는 서비스도 있다. 즉 화면만 있는 서비스도 있다. 만들는 시점에 적당히 토론하고 그 토론에서 결론내고 만들면서 뭉칠지 쪼갤지 다시 정한다.

작게 쪼개보니 어떤 점이 좋은가?

어떤 서비스는 벌써 몇번째 재개발을 하였다. 이유는 다양하지만 주로 첫번째 개발에서는 요구사항도 잘 모르고, 새로운 개발 플랫폼에 대한 이해도도 낮은 상태에서 개발을 진행하고, 이후 테스트 하면서 마구 수정하는 방식으로 개발을 했는데 그러다 보니 코드도 엉망이고 새로운 기능을 붙이기에도 좋지 않아 기회가 있을때마다 새로 개발하였다. 작게 쪼개져 있다 보니 새로 개발하는데 부담이 적고, 재개발 후 배포 시에도 다른 서비스에 영향을 받을 필요가 없다.

어떤 경우에는 비슷한 기능을 두개의 팀이 개발하는 경우도 있다. 각자 필요한 기능 개발하여 사용하면서 나중에 필요하면 하나로 합쳐도 된다. 즉, 다른 팀의 일정을 봐가면서 진행할 필요도 없다.

그러면 어려운 점은?

전체 개발 환경을 구성하기 어렵다. 현재는 개발자의 개발 환경은 스테이징을 바라보고 있다. 내가 만드는 기능이 사용하는 다른 서비스는 개발 환경이 아닌 스테이징 환경을 이용하고 있기 때문에 스테이징의 변화가 있으면 개발환경에도 영향을 받는다.

개발자 한명이 서비스 하나를 개발하는 경우가 많은데 이때 코드 리뷰 등을 보기 어려운 환경이다. 물론 지금까지 코드 리뷰를 해보지 않았기 때문이기도 하지만 아무래도 나와 관련이 없는 서비스에 대해 리뷰를 보는 것은 부담이 되거나 귀찮은 업무이기는 하다.

어떤 개발 플랫폼을 사용하는가?

기존 개발자들의 대부분은 C#, SQLServer 기반에 웹 보다는 Form 중심의 Client/Server 기반이었다. C#에서 제공하는 ORM 등을 사용하기 보다는 Stored Procedure를 만들고 Form에서 이를 호출하여 사용하는 방식이었다. 이런 개발 플랫폼을 오픈 플랫폼으로 바뀌는 것은 쉽지 않은데 초기 전략은 해당 서비스를 만드는 개발자가 가장 잘 하거나, 사용 하고 싶은 플랫폼을 사용한다는 전략이었다. 초기에는 IIS, .Net 기반으로 개발하였는데 최근에는 Go가 가장 많고 일부 Java, Rails 등으로 개발되고 있다.

서버측 개발은 다양한 개발 플랫폼을 사용하고 있는 반면 화면측 개발은 대부분 React를 이용하고 있다. 웹 보다는 모바일 관련 화면 개발이 더 많은데 모바일도 일반 모바일이 아니라 WeChat 내에서 동작하는 화면에 많은데 이를 위해 HTML + Javascript를 이용한 모바일 플랫폼을 구성해야 하는데 React가 이 조합에는 가장 잘 맞는 것으로 몇가지 실제 적용을 통해 검증하여 적용하였다.

이렇게 다양한 플랫폼으로 개발되면 문제는 없는가?

최근의 웹 관련 기술 트렌드가 거의 비슷해지며 시스템 구성도 거의 유사하게 바뀌고 있다. Router 기반으로 Request를 받아서 Controller, Action으로 호출을 전달하고 ORM을 이용하여 데이터베이스와 객체 사이를 핸들링하고 하는 등 개념은 거의 비슷하기 때문에 큰 어려움은 없다. 여러 개발자들이 기존 Stored Procedure 중심의 아키텍처에서 계층화된 아키텍처로 개발을 하고 있다.

이렇게 플랫폼이 다양함으로써 나오는 문제중의 하나가 네이밍 룰에 대한 내용이다. C#의 경우 첫글자 대문자인 Camel 표기를, Go나 자바의 경우 첫글자 소문자인 Camel 표기를, Rails는 Snake 표기를 사용한다. 초기에는 각 플랫폼에 맞게 사용하였는데 일년 정도 지난 지금에 보면 아주 정신없어 보인다. 이 부분에 대해서는 각 서비스의 내부에서는 어떤 것을 사용해도 상관없지만 API에서 사용하는 파라미터, URL, Return Value 등에 대해서는 표준을 정하고 사용하려고 하고 있다.

이런 구성이 될 것이라고 예상하였는가?

누구도 이렇게 운영될 것이라고 예상하지 않았다. 심지어는 개발자들도 중간에 반신반의하면서 개발을 진행하였는데 결론은 다소 어려움이 있기는 하지만 다이나믹하게 기능을 계속 추가하면서 비즈니스 속도에 맞추어 개발을 진행할 수 있는 단계까지 올라오게 되었다. 그때 당시에는 안하는 것보는 하는 것이 한 걸음이라도 더 앞으로 나가는 것이기 때문에 그냥 했던 것이다. 그리고 이 방법밖에 없다고 생각했다.

마치며

필자가 있는 이 조직도 처음에는 아주 큰 기업의 일부로 운영되던 조직이었습니다. 물론 지금도 그렇고요. 하지만 이렇게 환경을 바꾼 이후로는 큰 기업에서는 할 수 없는 많은 일들을 해내고 있습니다. 전략에서 결정된 사항을 빠르게 서비스로 만들어 내고, 심지어는 서비스를 먼저 만들어 내고 전략에서 이를 가져다 사용하는 수준까지 올라오게 되었습니다. 기술에서 내세우고 있는 용어에 갇히기 보다는

• 무엇을 해야 하는가? 에 대한 생각과
• 그것을 하기 위해서는 어떻게 해야 하는가?
• 모르면 알때까지 기다리지 말고 부딪히면서 바꾸어 나가자.
• 소프트웨어에 정답은 없고 실패의 비용이 적기 때문에...

그냥 Just Do It!