안녕하세요. 저는 Azure Cloud Solution Architect의 아키야마입니다. 이번에는 마모루 비즈니스에서 k8s로의 마이그레이션에 대해 글을 쓸 예정입니다.
생각보다 길어질 것 같아 기사를 다음과 같이 나누겠습니다.
- Vol.1 App Service에서 AKS App Service로의 이전 결정 <- 本記事
- Vol.2 AKS(k8s) 移行の下準備
- Vol.3 AKS(k8s) 移行
App Service
移行した話の前に、 Mamoru Biz チームと App Service の関係について書きます。
Microsoft の 은 스타트업에 적합한 서비스로, 웹 앱을 쉽게 게시할 수 있게 해줍니다. 제가 마모루 비즈니스를 시작했을 때 저는 스타트업에 불과했고, 계약 사업을 하면서 짧은 기간 내에 인프라를 구축해야 했기 때문에, 경험이 있는 앱 서비스를 도입했습니다.
그때는 도커 버전이 일본 지역에서만 제공되고 있었던 것으로 기억합니다. 이 글을 쓴 시기와 비슷합니다.
마모루 비즈의 개발팀은 거의 전적으로 애플리케이션 엔지니어로 전념했고, 인프라 엔지니어들은 주로 계약 업무를 병행하고 있었다. 인프라는 인프라 엔지니어들이 이끌었지만, 실제로는 앱 서비스만 사용해도 그리 어렵지 않았다.
웹 서버를 출시하려고 할 때, 애플리케이션 엔지니어들이 인프라 환경을 구축하기 시작했습니다. (품질 측면에서 보면, 개발/스테이징/프로덕션 스테이징/프로덕션은 인프라 엔지니어들이 구축했습니다.)
전환의 배경
건축
마모루 비즈는 iOS/Android 앱 + 웹 앱을 통해 고객에게 서비스를 제공합니다. 앱 서비스는 웹 앱 부분을 담당하지만, 점차 앱 서비스가 사용되지 않는 경우도 있습니다. 그 중 하나가 작업 실행입니다.
App Service(컨테이너용)는 배포한 Docker 컨테이너가 HTTP 요청에 응답하도록 요구합니다. (참고: 컨테이너가 HTTP 핑에 응답해야 합니다.)
작업을 실행하는 데 웹 서버가 필요하지는 않지만, 당시 Docker 실행 환경으로 실행할 수 있는 다른 좋은 방법이 없어서 App Service에서 작업을 실행할 다른 좋은 방법이 없었습니다. App Service는 웹 서버가 필요하기 때문에, 슈퍼바이저를 통해 웹 서버와 작업 모두를 실행할 수 있습니다. Docker 컨테이너 관점에서 보면, 컨테이너는 App Service를 위해 특별히 설계되었는데, 이는 그리 좋은 상황이 아닙니다.
이후 컨테이너 인스턴스가 출시되었지만, 컨테이너의 생명주기를 관리하기 위해 Logic App과 같은 별도의 서비스의 제어가 필요해 다소 번거로웠습니다.

앱 서비스가 맞지 않는 경우에 인프라를 구축하는 것은 중복된다고 느끼기 시작했습니다.
개발자 성장
Colorkrew는 도전을 통해 성장하는 것을 중요하게 생각합니다.
개발자들이 점점 숙련되면서, 주로 마모루 비즈니스에서 사용되던 PHP/라라벨 이외의 다른 것을 빠르게 구현하고 싶어 했습니다. 구체적으로는 Go 병렬 처리를 원했습니다. 개발자들이 더 많은 도전을 받아들일 수 있는 공간을 만드는 것이 중요하며, 물론 개발 비용을 줄일 수 있다면 할 말이 없습니다.
앞서 언급했듯이, 인프라 엔지니어 역시 해당 직책에 있는 이들은 사용할 시간이 적기 때문에, 애플리케이션 엔지니어가 자율적으로 컨테이너를 추가할 수 있다는 점은 팀에 큰 장점입니다. 컨테이너 추가 비용을 줄임으로써 전체 비용을 낮추고자 하는 아이디어입니다.
계약 사업에서의 문의
계약 사업에서는 쿠버네티스 문의가 점차 증가하고 있습니다. k8s 기술을 SaaS 서비스에 통합함으로써 지식을 공유하고 엔지니어들이 두 사업을 오가며 더 쉽게 이용할 수 있도록 할 수 있습니다.
결론
지금까지 나열된 기술, 문화, 비즈니스 등을 종합적으로 평가한 후, 우리는 K8S로 전환하기로 결정했습니다.
말할 필요도 없이, App Service와 Azure Kubernetes Service는 모두 좋은 서비스이며, 여러분의 요구에 맞게 사용해야 합니다. 이야기는 Mamoru Biz가 App Service로 빠르게 시작해 AKS가 성장함에 따라 AKS로 이전했다는 것입니다.
지금까지 시간이 꽤 걸려서 다른 글에서 다룰 예정입니다.