Azure VMからAzure Container Appsに移行しました

はじめに

エキサイト株式会社 バックエンドエンジニアの山縣（@zsp2088dev）です。 先日、私の携わるサービスでAzureのVM環境からAzure Container Appsに移行しました。

本記事では、Container Appsに切り替えた経緯やContainer Appsのことについて紹介します。 Container Appsの導入を検討している方や、VM環境を脱却しようとしている方の参考になる記事です。

移行前の構成

移行前の構成をざっくりと表すと次のとおりです。 nginxでロードバランシングを行っており、1つのVM環境に複数のアプリケーションが載っています。

現状の課題点

現状のVM環境にはいくつかの課題点がありました。

  1. アプリケーションがコンテナ化されていない
  2. デプロイサーバーにSSHで入り、シェルを実行してデプロイしている
  3. 1つのVM環境に複数のアプリケーションが載っているためスケールするのが大変
  4. VM環境がコード管理されていない

簡単にまとめると、「開発と運用がつらい環境」にありました。 「これらをそろそろ対策しないとまずいのでは？」と考えていた時期に、Container Appsが一般提供されたことを知りました。 Container Appsのドキュメントを読んで試してみたところ、上記の課題点を大きな手間をかけずに解消できることがわかりました。

課題解決のためにやったこと

Container Appsに切り替える上で、上記の課題点を解消するために下記の4つを行いました。

  1. アプリケーションをコンテナ化する
  2. GitHub Actionsを使用してデプロイする
  3. スケーリングルールを設定する
  4. 環境をコード化する

アプリケーションをコンテナ化する

簡単に環境構築を行い、開発しやすい環境を作ることは重要です。 まずは、既存のデプロイコマンドが記述されたシェルファイルから必要な箇所を抽出し、それをDockerfileに落とし込みました。

ローカルでの動作確認後は、手動でAzure Container Registry（ACR）にプッシュして、Container Appsで問題なく動作することを確認しました。

GitHub Actionsを使用してデプロイする

コードに変更があってVM環境にデプロイするたびにデプロイサーバーに入るのはとても面倒でした。 そこで、既存のデプロイ方法をやめて、GitHub Actionsを使用したデプロイ方法に変更することに決めました。 これについては社内でも知見があったため、比較的スムーズに移行することができました。

私たちのチームでは、workflow_dispatchを使用して、手動デプロイするようにしています。 これにより、GitHub上から、ブランチやGitタグを指定して[Run workflow]ボタンをクリックすることで、デプロイできるようになります。

実際にワークフローに組み込んでいるのは以下のとおりです。

  1. コンテナイメージをビルドする
  2. ビルドしたイメージを、ACRにプッシュする
  3. プッシュしたイメージを、Container Appsに反映する

スケーリングルールを設定する

既存のVM環境では、負荷の上昇により自動でスケールすることができません。 また、1つのVM環境に複数のアプリケーションが載っているため、1つのアプリケーションの負荷が上昇したときは、同一のVM環境にあるアプリケーション全てに影響が出てしまっていました。 アプリケーションに手を加えない場合、VM環境の性能を上げるか、VM環境を新たに増やすかの2択であるため、コストも多くかかってしまいます。

Container Appsでは、CPU使用率やメモリ使用率、リクエスト数などをトリガーに水平スケーリングすることができます。 いくつかスケーリングの条件を選ぶことができますが、まずはCPU使用率をトリガーにスケールすることにしました。 これについては、運用していく上で適切なスケーリング条件を選択できればと考えています。

docs.microsoft.com

環境をコード化する

Container Appsでは、環境を作成したり更新したりするのにYAMLファイルを指定することができます。 そのため、以前はできなかった環境のコード管理が、Container Appsに移行することでできるようになりました。

次のように、azコマンドを使用してYAMLファイルを指定することで、環境の作成や更新ができるようになります。

$ az containerapp update \
  --name sample-container \
  --resource-group sample \
  --yaml config.yml

YAMLファイルの詳細については、下記リンクを参照してください。 docs.microsoft.com

Container Appsの構成

下記図が現在運用しているContainer Appsの構成図です。 nginxコンテナで、IP制限やbotのリクエストの処理、静的コンテンツの返却を行っています。 業務ロジックの処理は、アプリケーションコンテナで行っています。

Container Appsでは、1つのリビジョンに複数のコンテナを動作させることができます。 ドキュメントに「コンテナーが密結合されている特定の事例でのみ使用する必要があります。」と書かれており、 本システムはアプリケーションコンテナと密結合しているため、この構成にしています。

docs.microsoft.com

Container Appsの料金体系

今回移行したシステムは、比較的負荷が少ないため、下記の構成にしました。

  • nginx: 0.25vCPU / 0.5GiB
  • App: 0.5vCPU / 1GiB
  • スケーリング: min: 2 / max: 10

これにより、負荷に応じて柔軟なスケーリングができるようになりました。

1ヶ月の間、下記の構成でスケールアウトせずに2台構成で動作した場合、おおよそ16000円になることが想定されています。 ただし、為替相場の変動やLog Analyticsの料金などで上下することはありそうです。

料金体系の詳細については、下記リンクを参照してください。 azure.microsoft.com

VM → Container Appsの切り替え

当日は、インフラメンバーと開発メンバーで協力しながら、VM環境からContainer Appsの切り替えを行いました。 本システムのドメインは、AWSのRoute53で管理されているため、加重ルーティングを使用した段階的な切り替えを行うことができました。

最初は、10%だけContainer Appsにリクエストを流し、徐々に30%, 50%, 100%とリクエストを増やしていくようにしました。 ダウンタイムなしで切り替えることができ、なんらかの問題が発生した場合でも素早く対応することができる体制にしていました。

切り替わっていく様子

おわりに

既存のVM環境から、Container Appsに無事移行することができました。 現在携わっているサービスでは、まだまだVM環境で動作しているアプリケーションがほとんどです。 そのため、完全に移行できるまではVM環境の料金とContainer Appsの料金がかかるため、二重に料金がかかってしまいます。 ここで得た知見を生かして他のシステムの移行も進めていきます。

採用アナウンス

エキサイトではフロントエンジニア、バックエンドエンジニア、アプリエンジニアを随時募集しています。 また、長期インターンも歓迎しています。

カジュアル面談からもOKです。少しでもご興味がございましたら、お気軽にご連絡頂ければ幸いです。

▼ 募集職種一覧 ▼ recruit.jobcan.jp