Azure Container Appsの回復性を検証してみた

1. はじめに
2. このブログのゴール
3. 前提条件
4. 全体概要
5. コンテナ作成
6. イメージを作成しACRへのpush
7. ACAでリビジョンを作成
8. 動作確認
9. 回復性（レジリエンシー）の設定
10. 検証
- 10-1. 500エラーで再試行とサーキットブレーカーを確認
- 10-2. 400エラーで再試行とサーキットブレーカーを確認
おわりに

1. はじめに

こんにちは。ACS事業部の本田です。
最近Azure Container Appsを利用する機会が多く、プレビュー機能である回復性について調べてみました。
実際に、再試行の動きを見てみましたので、まとめてみます。

2. このブログのゴール

再試行を実際に起こして、どのような動作をしているのかを検証してみたいと思います。

3. 前提条件

下記においては、本ブログではほとんど触れておりません。
また、2025年2月時点での情報であり現時点ではプレビューの機能となります。

DockerFileやdockerコマンドに関する基本的な知識と環境準備
Azure Container Appsの構築
Azure Container Registryの構築

4. 全体概要

各ステータスコードを返す設定を行った、Nginxコンテナを作成します。
作成したコンテナを、ACAで動作させ任意のhttpステータスコードを発生させたいと思います。
次の順番で記載を行います。

コンテナの作成
ACRへPush
ACAで動作確認
回復性を動作させてみた

5. コンテナ作成

Docker Fileを作成し、コンテナを作成していこうと思います。

次のディレクトリ構成で作業を行います。

Dockerfile
nginx
  L default.conf

Dockerfileの準備を行います。
nginxのイメージを使い、confファイルを入れ替えています。

FROM nginx:latest

# nginxの設定を行う
ADD ./nginx/default.conf /etc/nginx/conf.d/default.conf

RUN echo "start nginx"

nginxのdefault.confを作成します。
各種ステータスを返すようにしています。もし試したいステータスがあればこちらに追加します。

server {
  listen 80 default_server;
  server_name _;

  location = /400 {
    return 400;
  }

  location = /401 {
    return 401;
  }

  location = /409 {
    return 409;
  }

  location = /500 {
    return 500;
  }

  location = /501 {
    return 501;
  }

  location / {
    root   /usr/share/nginx/html;
    index  index.html index.htm;
  }

}

6. イメージを作成しACRへのpush

今回、ACAへのイメージ展開をACRを用いて行いますので、ACRへイメージのpushを行います。
また同時に、ACAがACRのイメージを読みに行けるように、設定を行っておきます。

$ docker build . --tag [ACR]/nginx/Resiliency --no-cache
$ docker login [ACR]
$ docker image push [ACR]/nginx/Resiliency

7. ACAでリビジョンを作成

ACRにPushしたイメージを利用して、新しくリビジョンの作成を実施します。
レプリカの最小数は1と設定をします。

8. 動作確認

アプリケーションURLにアクセスを行い、「Welcom to nginx!」が表示されるのを確認します。

URL: https://xxxxxxxxxxxxxxxxxxxxx.japaneast.azurecontainerapps.io/

500エラーが発生させることが出来ているかを確認します。

URL: https://xxxxxxxxxxxxxxxxxxxxx.japaneast.azurecontainerapps.io/500

9. 回復性（レジリエンシー）の設定

Azure Portalから設定を行います。
今回は、下記のように設定を行っておりますので、参考にされてください。

10. 検証

次の動作となることを想定して、実施します。

「エラー:5xx」によって、500系エラーが発生した際には再試行が実施される
「エラー: 再試行4xx」によって、400系エラーが発生した際には再試行が実施される。
5xx、4xxで再試行が実施されると、連続エラー5回でサーキットブレーカーが発動する。
サーキットブレーカーによって、除外率100%としているためレプリカ1の場合だと、応答できるコンテナがなくなる。

10-1. 500エラーで再試行とサーキットブレーカーを確認

ブラウザー上でアクセスし、ログストリームでログを確認すると、連続エラー5回でログが停止しています。
サーキットブレーカーが動作したためと考えられます。

10-2. 400エラーで再試行とサーキットブレーカーを確認

同様に400エラーを発生させます。
予想に反して再試行されません。

確認を行ってみると「エラー: 再試行可能4xx」のチェックで対応出来るのは、409だけとのことです。
409で実施を行うと、再試行は発生しましたが、今度はサーキットブレーカーが動作していません。

サーキットブレーカーを確認すると「5xx」しか対応していないようです。

おわりに

Azure Container Appsの動作検証を実施してみましたが、いかがでしたでしょうか？
簡単にまとめると、以下になるかと思います。

「5xx」に関しては、チェックを付けるだけで対応できる。
「4xx」を再試行させたい場合は、「再試行可能4xx」だけでは足りず、「特定の状態コード」にて対応を行う必要がある。
サーキットブレーカーは現時点では、5xxにしか対応していない。

本ブログは以上になります。ここまでお読みいただきありがとうございました。

私の所属するACS事業部では、開発者ポータルBackstage、Azure AI Serviceなどを活用し、Platform Engineering＋AIの推進・内製化のご支援をしております。

www.ap-com.co.jp www.ap-com.co.jp www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！
我々の事業部のCultureDeckはこちらです。

www.ap-com.co.jp 今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。 www.ap-com.co.jp

本記事の投稿者: 本田

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。