はじめに

エキサイト株式会社バックエンドエンジニアの山縣（@zsp2088dev）です。

エキサイトホールディングス Advent Calendar 2022の14日目を担当します✍️

3ヶ月前に、私の携わるサービスの一部をAzure VMからAzure Container Appsに移行しました。詳細については、以下の記事をご参照ください。

tech.excite.co.jp

Container Appsの移行から3ヶ月経過した現在では、バッチサーバを除く、ほぼすべてのアプリケーションがContainer Apps上で稼働しています。本記事では、Container Appsに切り替えたことでできるようになったこと、今後の取り組みについて紹介します。 Container Appsの導入を検討している方がいましたら、参考にしていただけると幸いです。

はじめに
できるようになったこと
今後やりたいこと
- GitHub Actionsのキャッシュの導入
- 適切なスケーリングルールの適用
おわりに
採用アナウンス

できるようになったこと

Container Appsに切り替えたことで、できるようになったことについてまとめます。

Log Analyticsを使用して、ログの調査ができるようになった
GitHub Actionsでデプロイできるようになった
テスト / ステージ環境の料金を抑えることができた

Log Analyticsを使用して、ログの調査ができるようになった

これまでのVM環境では、nginxのログをVM環境のストレージに置いていました。ログの分析をするときは、SSHを使用して接続し、awkコマンドやgrepコマンドを駆使して、必要なデータを抽出していました。

Container Appsでは、ログをLog Analyticsワークスペースに格納することができます。これにより、KQLを記述することで必要なデータを抽出することができるようになりました。例えば、Log Analyticsで下記のクエリーを実行することでステータスコードが200以外のログを取得することができます。

ContainerAppConsoleLogs_CL
| where RevisionName_s == "sample-app--123456"
| where ContainerName_s == "sample-app-nginx"
| where Log_s !contains " 200 "
| order by _timestamp_d asc

さらに、Log AnalyticsにはCSVファイルのエクスポート機能があります。より高度なログの分析では、CSVファイルをエクスポートして、手元でデータ加工してログの分析をすることができるようになりました。

基本的にはよいことが多いですが、考慮しなくてはならない点も増えました。 VM環境のときは、VM環境内のストレージにログファイルを置いており、ログローテートによって古いログファイルの削除を行っていました。そのため、ストレージの逼迫や料金をあまり気にすることはありませんでした。

Log Analyticsワークスペースは、初期設定で30日間データ保持できるように設定されており、その使用量に応じて課金される仕組みになっています。そのため、アクセス数の多いサービスで、Log Analyticsワークスペースにすべてのログを格納している場合、料金が跳ね上がってしまうことが想定されます。料金を抑えたいのであれば、必要なログだけをLog Analyticsワークスペースに格納する必要があります。

learn.microsoft.com

GitHub Actionsでデプロイできるようになった

VM環境のときは、アプリケーションごとにデプロイ方法が異なり、「このアプリケーションではどのデプロイ方法だった...?」と考えてしまうことも多かったです。

この問題を解決するために、コンテナ化のタイミングで、すべてGitHub Actionsを使用してデプロイできるように整備しました。個々の処理はDockerfileに記述していますが、大まかには以下に従ってデプロイを行っています。

コンテナイメージをビルドする
ビルドしたイメージを、Azure Container Registryにプッシュする
プッシュしたイメージを、Container Appsに反映する

デプロイ方法が統一されたことで、素早くデプロイできるようになり、良い開発体験に繋がったと考えています。

テスト / ステージ環境の料金を抑えることができた

Container Appsでは、以下の条件をすべて満たすことでアイドル状態と判定される仕様になっています。アイドル状態では、アクティブ状態と比較してかなり料金を抑えることができます。

レプリカが、現在アイドル料金の対象となっているリビジョンで実行されている。レプリカ内のすべてのコンテナーが開始され、実行されている。レプリカが HTTP 要求を処理していない。レプリカが使用しているのが 0.01 vCPU コア未満。レプリカが受信しているネットワークトラフィックが、1 秒あたり 1,000 バイト未満。

learn.microsoft.com

azure.microsoft.com

また、非アクティブ状態やレプリカ数が0の状態では課金されることはありません。そのため、テスト / ステージ環境など必要に応じて稼働するアプリケーションについては、料金を抑えることが可能になります。

実際、あまり使用しないテスト環境の使用料金が、1ヶ月で1000円を下回るなど、かなり安価に利用できています。

今後やりたいこと

VM環境からContainer Appsに移行したことで、より開発しやすい環境になったと感じています。その一方で、まだ取り組めていない箇所がいくつかあるため、併せて紹介します。

GitHub Actionsのキャッシュの導入

ビルド時間が長いサービスでは、ビルドからデプロイまでに7分ほどの時間がかかってしまっています。パッケージのインストールなど、前回のビルドと同じパッケージを使用する場合はキャッシュから取り出すなどして、ワークフローの実行時間を減らしたいと考えています。

適切なスケーリングルールの適用

現状ではスケーリングルールを、CPU使用率をトリガーにスケールアウトするように設定しています。 Container Appsでは、リクエスト数やメモリ使用率などをトリガーにスケールアウトすることができます。アプリケーションによっては、CPU使用率をトリガーにするよりも、よいトリガー条件があると考えているため、検証してみたいと考えています。