本記事は Microsoft Learn の「Azure Container Instances の構成」というモジュールをまとめたものである。
コンテナーと仮想マシンを比較する
仮想マシンはハードウェアを仮想化し、物理サーバー上で複数のOSを独立して動かせる仕組み。コンテナーはその次の段階で、OS自体を仮想化し、1つのOS上で複数のアプリを分離して動かせる。仮想マシン内のコンテナーも、物理サーバー上の仮想マシンと同じように動作する。
コンテナーと仮想マシンの違いについて知っておくべきこと
観点 | コンテナー | 仮想マシン |
---|---|---|
分離 | 軽量な分離、セキュリティ境界は弱い | 完全分離、強力なセキュリティ境界 |
OS | ユーザーモードのみ実行、必要最小限で軽量 | カーネル含む完全なOSを実行、リソース消費大 |
デプロイ | DockerやKubernetesで迅速に展開可能 | Hyper-VやPowerShellで展開、やや重い |
永続ストレージ | Azure DiskやAzure Filesを利用 | VHDやSMB共有を利用 |
フォールトトレランス | 障害時にオーケストレーターがコンテナーを即再作成 | 障害時にフェールオーバー、OSは再起動が必要 |
コンテナーを使う場合に考慮すべきこと
- 柔軟性とスピード: コンテナーを使うと、アプリの開発と共有が柔軟かつ高速になる
- テスト: コンテナー化により、環境構成を簡略化してテストが容易になる
- デプロイ: コンテナーを使うと、アプリのデプロイが効率的かつ迅速になる
- ワークロード密度: コンテナーは高い密度でワークロードを実行でき、リソース利用率を向上させる
Azure Container Instances を確認する
コンテナーはクラウドアプリのパッケージ化やデプロイに広く使われるようになっている。Azure にはクラウドネイティブやコンテナーアプリを展開するための複数の方法があるが、その中で Azure Container Instances (ACI) は、仮想マシンの管理や複雑なサービスを使わずに、最速かつ最も簡単にコンテナーを実行できる仕組み。ACI は分離されたコンテナー環境で動作し、幅広いシナリオに対応できる。
コンテナーイメージについて
コンテナーはコンテナーイメージから作られる。イメージはアプリを動かすのに必要な要素をすべて含んだ軽量な実行パッケージ。
含まれるものは以下の通り:
- コード: アプリ本体のソースコード
- ランタイム: アプリを動かすための実行環境
- システムツール: 必要なユーティリティ類
- システムライブラリ: アプリが利用する共有ライブラリ
- 設定: アプリ固有の構成パラメータ
コンテナーイメージを作ると、どの環境でも同じように動くポータブルな単位になる。実行時には、そのイメージから作られたインスタンスがコンテナーとして動作する。
次の図は、Azure Container Instances を使ってビルドした Web サーバーコンテナーを示している。 コンテナーは仮想ネットワーク内の仮想マシン上で動作しいる。
Azure Container Instances について知っておくべきこと
- 短い起動時間: 数秒で起動、VM の管理不要
- パブリック接続: IP アドレスや FQDN でインターネット公開可能
- カスタムサイズ: リソース需要に応じて動的スケーリング
- 永続ストレージ: Azure Files を直接マウント可能
- OS対応: Linux と Windows の両方に対応、グループ作成時に指定
- 共同スケジュール: 複数コンテナーをまとめて配置しリソース共有可能
- 仮想ネットワーク: Azure VNet に統合してデプロイ可能
コンテナーグループを実装する
Azure Container Instances の最上位リソースはコンテナーグループ。コンテナーグループは同じホスト上で動くコンテナーの集まりで、ライフサイクルやリソース、ネットワーク、ストレージを共有する。
コンテナーグループについて知っておくべきこと
-
コンテナーグループとポッド: Kubernetes のポッドに似ており、複数コンテナーをまとめてリソースやライフサイクルを共有可能
-
リソース割り当て: グループ内の全コンテナーの要求を合計して CPU、メモリ、GPU などを割り当て
-
デプロイ方法:
- ARM テンプレート: Azure サービスと組み合わせる場合に推奨
- YAML ファイル: コンテナーインスタンスのみの場合に簡潔で推奨
-
ネットワーク: 外部に面した IP、ポート、FQDN を共有
-
外部アクセス: 外部クライアントは IP とポートを通してコンテナーにアクセス可能
-
ポートマッピング制限: グループ内でポートの名前空間を共有するため、個別マッピングは不可
-
削除時: コンテナーグループ削除で IP と FQDN は解放される
構成の例
- コンテナーグループは 1 台のホストでスケジュールされ、DNS 名ラベルを持つ
- 1 つのパブリック IP アドレスと 1 つのポートを公開
- コンテナー A はポート 80 でリッスン、コンテナー B はポート 1433 でリッスン
- 2 つの Azure Files ファイル共有をボリュームとして持ち、各コンテナーが 1 つずつマウント
コンテナーグループを使う場合に考慮すべきこと
マルチコンテナーグループは、1つの機能を複数のコンテナーに分ける場合に便利で、異なるチームがイメージを配布でき、コンテナーごとにリソース要件を設定可能。
- Web アプリの更新: 1つのコンテナーでアプリ提供、別のコンテナーで最新コンテンツをソース管理からプル
- ログデータ収集: アプリコンテナーがログ・メトリックを出力、ログコンテナーが収集して長期ストレージに保存
- アプリ監視: 監視コンテナーが定期的にアプリにリクエストを送り応答を確認、問題時にアラート生成
- フロントエンドとバックエンド: フロントエンドコンテナーが Web 提供、バックエンドコンテナーがデータ取得サービスを実行
Azure Container Apps を確認する
チームは Azure でクラウドネイティブやコンテナーアプリを構築・デプロイする多くの選択肢を持つ。Azure Container Apps の適したユースケースや他の Azure コンテナーオプションとの比較を理解し、開発者視点で Azure Container Instances の特徴を把握することが重要。
Azure Container Apps について知っておくべきこと
Azure Container Apps はサーバーレスで、コンテナーアプリを実行する際にインフラ管理を最小化しコストを削減。サーバーリソースや安全性が自動で提供され、サーバー設定やオーケストレーション、デプロイ作業の負担を減らせる。
一般的な用途には以下が挙げられる。
- API エンドポイントの提供: アプリケーションの機能を外部から呼び出せるようにする
- バックグラウンド処理の実行: 定期的または非同期の作業を処理
- イベント駆動型処理: 特定のイベントに応じて自動で処理を開始
- マイクロサービスの運用: 小さなサービス単位でアプリを分割して実行
Azure Container Apps 上に構築されたアプリケーションは、次の特性に基づいて動的にスケーリングできる。
- HTTP トラフィック
- イベント駆動型処理
- CPU またはメモリの負荷
- 任意の KEDA でサポートされているスケーラー
Azure Container Apps を使用する際の考慮事項
Azure Container Apps は、コンテナーをベースにサーバーレスのマイクロサービスやジョブを構築できるプラットフォーム。Kubernetes スタイルのアプリを簡単に作れる一方、Kubernetes API への直接アクセスは不要で、フルマネージドで運用できる。
特徴:
- 汎用コンテナー最適化: 複数マイクロサービスにまたがるアプリ向け
- オープンソース技術活用: Kubernetes、Dapr、KEDA、envoy など
- Kubernetes スタイルのサポート: サービス検出やトラフィック分割対応
- 自動スケーリング: トラフィックやイベントに応じたスケーリング、ゼロスケーリングも可能
- ジョブ実行: オンデマンド、スケジュール済み、イベント駆動型ジョブ対応
- フルマネージド体験: Kubernetes API への直接アクセス不要、ベストプラクティスに沿った運用
- 利用メリット: コンテナー マイクロサービスの構築を簡単に開始可能
コンテナー管理ソリューションを比較する
Azure Container Apps (ACA) と Azure Kubernetes Service (AKS) の比較をシンプルにまとめると以下の通り。
機能 | Azure Container Apps (ACA) | Azure Kubernetes Service (AKS) |
---|---|---|
概要 | サーバーレス コンテナプラットフォーム。基盤インフラを抽象化し、マイクロサービスのデプロイ・管理を簡単化 | マネージド Kubernetes クラスター。複雑なアプリ向けにオーケストレーションと運用を簡略化 |
展開 | PaaS 的な簡単デプロイと管理 | Kubernetes 環境向けに細かい制御やカスタマイズが可能 |
管理 | 簡素化された PaaS 体験。AKS を基盤に構築 | Kubernetes 環境を詳細に制御。専門知識を持つチーム向け |
スケーラビリティ | HTTP ベースの自動スケーリングやイベント駆動型スケーリング対応 | 水平ポッド自動スケーリングとクラスター自動スケーリング対応 |
使用例 | マイクロサービス・サーバーレスアプリの迅速なスケーリングと簡易管理 | 複雑で長時間実行されるアプリ。完全な Kubernetes 機能と Azure サービス統合が必要 |
統合 | Azure Logic Apps、Functions、Event Grid と連携しイベント駆動型アプリ向け | Azure Policy、Azure Monitor、Azure Defender for Kubernetes などでセキュリティとガバナンスを強化 |
演習: コンテナー インスタンスを実装する
あなたの組織では、ウェブアプリケーションがオンプレミスのデータセンター内の仮想マシンで稼働している。組織はすべてのアプリケーションをクラウドに移行したいが、多数のサーバーを管理することは避けたい。そのため、Azure Container Instances と Docker の利用を検討することにした。
アーキテクチャ図
Docker イメージを使った ACI のデプロイ
- Azure ポータルにサインイン - https://portal.azure.com
- Azure ポータルで「Container instances」を検索して選択し、Container instances ブレードで + Create をクリック
- Create container instance ブレードの Basics タブで以下の設定を指定(その他はデフォルトのまま)
- Next: Networking をクリックし、以下の設定を指定(その他はデフォルトのまま)
- Next: Monitoring をクリックし、Enable container instance logs のチェックを外す
- Next: Advanced をクリックし、設定を確認(変更は不要)
- Review + Create をクリックし、検証が成功したことを確認してから Create を選択
ACIのデプロイのテストと検証
- デプロイ完了後、Go to resource リンクを選択
- コンテナー インスタンスの Overview ブレードで、Status が Running と表示されていることを確認
- コンテナー インスタンスの FQDN の値をコピーし、新しいブラウザタブで該当 URL にアクセス
- Welcome to Azure Container Instance ページが表示されることを確認。ページを数回リロードしてログを生成し、ブラウザタブを閉じる
- コンテナー インスタンス ブレードの Settings セクションで Containers をクリックし、次に Logs をクリック
- ブラウザでアプリを表示した際に生成された HTTP GET リクエストのログエントリが表示されることを確認