• TOP
  • Tips
  • 自社サービスで Azure App Service から Azure Kubernetes Service に移行した話 vol.1

自社サービスで Azure App Service から Azure Kubernetes Service に移行した話 vol.1

akiyamak

こんにちは。 Azure Cloud Solution Architect の秋山です。 今回は弊社の Mamoru Biz で k8s に移行した話について書きます。

思ったよりも長くなりそうなので以下のように記事を分けます。

  • Vol.1 App Service から AKS へ移行の決断 <- 本記事
  • Vol.2 AKS(k8s) 移行の下準備
  • Vol.3 AKS(k8s) 移行

App Service

移行した話の前に、 Mamoru Biz チームと App Service の関係について書きます。

Microsoft の App Service は簡単に Web アプリを公開できる、スタートアップに適したサービスです。 Mamoru Biz を始めた頃はまさにスタートアップで、私が受託ビジネス くらまね の片手間に短時間でインフラ構築をする必要があり、経験のある App Service を導入しました。

当時は Docker 版が日本リージョンで利用可能になって間もないころだったと記憶してます。 ちょうど この記事 を書いた頃ですね。

Mamoru Biz の開発メンバーは、アプリケーションエンジニアはほぼ専任、インフラエンジニアは他の業務(主に受託ビジネス)と兼任というチーム体制でした。 インフラ構築はインフラエンジニアが主導していましたが、実際のところ App Service をただ使うだけであればそれほど難しくありません。

Web サーバーを立ち上げたい、というときにはアプリケーションエンジニアがインフラ環境を構築するようになっていきました。 (品質面から Dev/Staging/Production の Staging/Production はインフラエンジニアが構築していました)

移行の背景

アーキテクチャ

Mamoru Biz は iOS/Android アプリ + Web アプリでお客様にサービスしています。 Web アプリの部分を App Service が担うわけですが、徐々に App Service にはまらないケースが出てくるようになりました。 その1つはジョブ実行です。

App Service (for Container) では、デプロイする Docker コンテナが http リクエストに応答する必要があります。 (参考: Your container must respond to an HTTP ping.)

ジョブ実行には Web サーバーは不要ですが、Docker 実行環境として当時は他にいい方法がなかったために、App Service 上でジョブを動かしていました。 App Service では Web サーバーが必要なので、supervisor を使って Web サーバーとジョブの両方を動かす、というものです。 Docker コンテナ視点で見ると、コンテナが App Service に特化した作りになってしまい、あまりよい状況ではありませんでした。

後に Container Instances がリリースされましたが、コンテナのライフサイクルを管理するために Logic App のような別のサービスで制御が必要となり、少し煩雑でした。

こういった App Service がはまらないケースでのインフラ構築が冗長と感じるようになっていきました。

開発者の成長

Colorkrew では チャレンジを通じて成長すること を大事にしています。

開発者が習熟していくうちに、Mamoru Biz で主に使っていた PHP/Laravel 以外を使って素早く実装したい、という要望が出てくるようになりました。 具体的には Go の並列処理を使いたい、というものです。 開発者がより多くのことにチャレンジできる場を作ることは重要ですし、もちろんそれによって開発コストを下げられるのであれば言うことはありません。

前述したとおり、兼任であるインフラエンジニアが使える時間は少ないため、アプリケーションエンジニアが自律的にコンテナを追加できることはチームにプラスに働きます。 コンテナを追加するためのコストを小さくすることで、全体のコストを下げたい、という考えが湧き上がってくるようになりました。

受託ビジネスでの引き合い

受託ビジネスである くらまね において、 Kubernetes の引き合い は徐々に増えつつあります。 自社の SaaS サービスに k8s の技術を入れることで、ナレッジが共有され、エンジニアが両方のビジネスを行き来しやすくなることが期待できます。

まとめ

ここまでに上げた技術、文化、ビジネスなどを総合的に判断して、k8s 移行に踏み切ることにしました。

言うまでもないことですが、App Service と Azure Kubernetes Service はどちらもよいサービスですし、要件に合わせて使い分けが必要です。 Mamoru Biz ではサービスの初期を App Service で素早く始め、拡大に合わせて AKS に移行した、というのがストーリーです。

ここまでで長くなりましたので、続きは別の記事で書きます。