もりはやメモφ(・ω・ )

ITとか読書感想文とか

トップ > Azure > Azureでコンテナを動かす時の選択肢を調べてみた

Azureでコンテナを動かす時の選択肢を調べてみた

Azure 入門 Container Kubernetes

今年の3月に職場を変え、ここ数ヶ月はAzureを触る日々が続いています。 本記事では「Azureでコンテナを動かす時ってどんな選択肢があるのか？」について、現状AKS(Azure Kubernetes Service)くらいしかイメージができていないため勉強がてらドキュメントを読んでメモします。

読むドキュメントは以下の、Microsoft公式ドキュメントである learn.microsoft.com の記事です。 Azure Container Service をスケールする


＊なお私は基本的に「コンテナ」と表記しますが、ドキュメントからの引用においては「コンテナー」とそのままの表記としています。

まずは日本語でざっと読む

改めてAzure Container Service をスケールするを読み進めます。タイトルだけ読むとわかりづらいですが、ドキュメントの構成的には以下のツリーがあった上でのこのタイトルです。

アプリケーション アーキテクチャの基礎
└─ テクノロジの選択
   └─ コンテナーオプションの選択
      └─ コンテナーのオプション

出てくるのは3つのコンテナサービス

このガイドの対象となる Azure Container Serviceでは下記3つのサービスが紹介されています。

  • Azure Container Apps
  • Azure Kubernetes Service(AKS)
  • Web App for Containers

この時点で以下の疑問が出てきました。

  • たったの3つだけしかないんだっけ？
  • AKSだけ省略読みがあるが、他のサービスも長いから省略したい...

1つめの疑問についてすぐに答えが書かれており、下記のようにリンクが記載されています。

すべての Azure Container Service の全一覧については、「コンテナー サービスの製品カテゴリページ」を参照してください。

少し寄り道して製品カテゴリページを見ると、上記3つのサービスに加えて全部で8個ものコンテナ向けサービスが存在していることがわかります。これは多いですね...

  1. Azure Kubernetes Service(AKS)
  2. Azure Red Hat OpenShift
  3. Azure Container Apps
  4. Azure Functions
  5. Web App for Containers
  6. Azure Container Instances
  7. Azure Service Fabric
  8. Azure Container Registry

各サービスへのリンクを辿りたくなる気持ちを抑えつつ、当初のAzure Container Service をスケールするを読み進めます。

「Azure コンテナー ソリューションのサービス モデルの比較」の節

「サービスモデルに関する考慮事項」の節はさっと読み飛ばすと、いよいよ主題でもある節「Azure コンテナー ソリューションのサービス モデルの比較」があります。

この節では3つのサービスについて概要が紹介されていますので、それらをさらに私なりに要約すると以下と認識しました。

  • AKS
    • Kubernetesだから学習コスト高いよ。以降で紹介するPaaSソリューションの方が簡単だよ。後からAKSに移行することもできるよ。
      • 所感: 最初に紹介している割に学習コストの高さからあまり推されていない印象を受けました
  • Azure Container Apps
    • シンプルで使いやすいよ。サーバレスも普通のコンピュートリソースの両方できるよ。Azure APIで操作できるよ。L7も管理できるよ
      • 所感: 全体的に文からイチオシ感を感じます。AKSとの対比でシンプルだよと伝わってくる
  • Web App for containers
    • Container Appsよりもシンプルだけどその分機能がちょっと物足りないかも
      • 所感: Container Appsとの違いが具体的じゃないことに微妙さを感じる。どう違うのかもうちょい書いて欲しい

「ホスティング モデルに関する考慮事項」の節

この節では各サービスの考慮事項が記載されており、大枠としては以下と認識しました。

  • AKS
    • Kubernetesの機能で複雑だが柔軟な制御が可能
    • Azureのマネージドアドオンと自動アップグレードで運用が楽になるよ
  • Azure Container Apps
    • AKSと異なり、単一のワークロードのために使用するよ
  • Web App for Containers
    • App Serviceの機能で、App Service Planと呼ばれる課金境界にグループするよ
    • 思わず同じグループ（App Service Planのこと？）で複数ワークロードを扱いたくなるが、ノイジーネイバー問題があり推奨しないよ

この節の所感としては、AKS以外は基本的に1ワークロード/ホストで動かすのが良いらしいと理解。

「制御と使いやすさのトレードオフ」の節

難しさと柔軟性について記述があり、要するに「Web App for Containers < Azure Container Apps < AKS」の順に複雑さが増す。

おそらくだがAKSとAzure Container Appsの間には大きな壁があるはず。

「大まかな指針」の節

シンプルだと機能開発に重点が置かれるが柔軟性は減る。高可用性が必要でスキルがあるなら制御が柔軟で難しいサービスが適しているかも、と認識。

要はバランスと読める。

なお自社のケースではKubernetesスキルを持つ人材（CKA相当以上）が二桁は在籍しているためAKSを選択するのは十分有りとの印象。（ポジショントークと言えるかもしれないが）

「すべてのワークロード共通の考慮事項」の節

以下の4点に関して表形式で概要の説明がある。一読しておくことで解像度が上がったので助かった。

  • ネットワークに関する考慮事項
    • AKSはとても柔軟
      • ネットワークポリシーなどが使えるからだと認識
    • Azure Container AppsではAzureのネットワーク機能が使える
      • VNETとかSubnetとかのことだろうか？
    • Web App for Containersについてはコメントがない
      • VNETすら使えない？Container Appsとの違いがもう少し書いてあると助かるのだが...
  • セキュリティに関する考慮事項
    • どのサービスもAzure Key VaultやEntra IDとの連携ができるよ
  • 操作上の考慮事項
    • AKSは柔軟だがな運用作業が必要だよ
    • Container AppsとWeb App for ContainersはスケーラビリティをAzureが担うよ、AKSと違ってね
  • 信頼性に関する考慮事項
    • AKSでは正常性プローブやノードプールやコントロールプレーンなどそれぞれ考慮が必要だよ
    • AKS以外の2つはAzure Resource Manager APIでやるよ

ざっと読んでもAKSが大変だという雰囲気が滲んでいると感じた。

以下の本節の最後の文はFunctionsとかVM系のサービスが適切なケースを想定しているのかもしれないが、ちょっと投げっぱなし感があり微妙と感じた。

上記の考慮事項を確認しても、最適なサービスが見つからない場合があります。 それは完全に正常です。

「トレードオフの評価」の節

改めて「要はバランス」についてトレードオフの観点でまとまっている節。

  • リソースの観点: 「チーム間での共同作業、人、予算、時間」の考慮
  • 特定のワークロードの要求: 例で「AKSのネットワークポリシーによるコンポーネント間の通信拒否（遮断）」

「まとめ」の節

以下の要点がまとめられている

  • ここまで書いてきた内容をもとに適切なバランスを見つけよう
  • 関連するすべてのワークロードチームでこのガイドを読もう
  • 実際に試して理論だけじゃなく経験に基づいてサービスを選択しよう

英語で読み直してみる

日本語でざっと読んだ後は、Webページ左下の言語設定を「English (United States)」に変更して冒頭から斜め読みをします。

これはオリジナルが英語であるため一次情報に触れておきたい点と、ちょいちょい微妙な日本語翻訳を読んでもやもやした理解度を、英語で読み直すことでより正確に認識したいためです。

英語で読み直したことでのいくつかの気づきポイントをあげておきます。

  • 当たり前だが日本語と同じ内容が記載されている
  • "multiple workloads"に対して"single-workload"と'-'の違いがあるらしい
    • ただ別のところでは"single workload"と表現している、コンテキストによるもの？
  • "Azure container services"と複数形のおかげでサービス名称と混同しなくて済むので良い
    • 文脈で単数系としてもちょいちょい出てくるが
  • "App Service plan"が" App Service プラン"より固有名詞として認識しやすかった
    • 中途半端なカタカナ混入が認知負荷を上げている気がする
  • "既定で拒否するネットワーク制御"より"deny-by-default network control"の方が頭に入る
    • おそらく過去のNW機器などの経験が"deny"や"default"の単語を処理しやすいのと'-'による意味の強調が印象に残りやすいためと想定

まとめ

以上、Azure Container Service をスケールするを読んでみたメモでした。AKS、Azure Container Apps、Web App for Containersの3つの主要サービスについて、それぞれの特徴や使用場面の違いが大まかに理解できました。AKSの柔軟性と複雑さ、Container Appsのバランスの取れた機能、Web App for Containersのシンプルさという特徴が印象的でした。

ガイド内にもある通り”論理よりも経験（意訳するなら検証とすべきかも）”をベースとしてサービス選択をしろとあるため、業務で直接関わってこなかったAKS以外の2サービスについては実際に手を動かして検証する必要があります。なお手を動かすことに関しては良い機会が別にあるため、そちらでチャレンジ予定です。

以下の引用文で締めておきます。

try the service and decide based on experience rather than theory.