Service Fabric から AKS へのワークロードの移行
多くの組織は、最新のアプリ開発、メンテナンスのベスト プラクティス、クラウドネイティブ アーキテクチャの導入に向けたプッシュの一環として、コンテナー化されたアプリに移行します。 テクノロジは進化し続けているため、組織はパブリック クラウドで利用できる多くのコンテナー化されたアプリ プラットフォームを評価する必要があります。
アプリに万能のソリューションはありませんが、組織では多くの場合、コンテナー化されたアプリケーションにおける要件の多くを、Azure Kubernetes Service (AKS) が満たしているという事実に気が付きます。 AKS は、コントロール プレーンを管理してアプリケーション ワークロードのコア サービスを提供することで、Kubernetes 経由のアプリケーションデプロイを簡略化するマネージド Kubernetes サービスです。 多くの組織では、プライマリ インフラストラクチャ プラットフォームとして AKS を使用し、他のプラットフォームでホストされているワークロードを AKS に移行します。
この記事では、コンテナー化されたアプリを Azure Service Fabric から AKS に移行する方法について説明します。 この記事は、Service Fabric を使い慣れているものの、その特徴と機能は AKS と比較してどうなのかを知りたい、ということを前提にしています。 この記事では、移行中に考慮すべきベスト プラクティスについても説明します。
AKS と Service Fabric の比較
まず、 他の Azure コンピューティング サービスと共に、Azure コンピューティング サービスを確認します。 このセクションでは、移行に関連する注目すべき類似点と相違点について説明します。
Service Fabric と AKS は、どちらもコンテナー オーケストレーターです。 Service Fabric では複数のプログラミング モデルがサポートされますが、AKS ではコンテナーのみがサポートされます。
プログラミング モデル: Service Fabric では、Linux と Windows コンテナー、Reliable Services、Reliable Actors、ASP.NET Core、ゲスト実行可能ファイルなど、サービスの記述や管理の方法が複数サポートされています。
AKS: AKS 上のコンテナーでは、コンテナー ランタイム containerd で実行される Windows および Linux コンテナーを使用したコンテナー化のみがサポートされます。これは自動的に管理されます。
Service Fabric と AKS はどちらも、Azure Pipelines、Azure Monitor、Azure Key Vault、Microsoft Entra ID など、他の Azure サービスとの統合を提供します。
主な相違点
マネージド クラスターではなく、従来の Service Fabric クラスターをデプロイする場合は、Azure Resource Manager テンプレート (ARM テンプレート) または Bicep モジュールの多くのサポート リソースと共にクラスター リソースを明示的に定義する必要があります。 これらのリソースには、クラスター ノードの種類ごとの仮想マシン スケール セット、ネットワーク セキュリティ グループ、ロード バランサーが含まれます。 これらのリソースが正しく構成されていることを確認するのは、ユーザーの責任となります。 これに対し、Service Fabric 管理クラスターのカプセル化モデル は、単一のマネージド クラスター リソースで構成されます。 クラスターの基になるすべてのリソースは抽象化され、Azure によって管理されます。
AKS は、運用オーバーヘッドを Azure にオフロードすることで、Azure でのマネージド Kubernetes クラスターのデプロイを簡略化します。 AKS はホストされた Kubernetes サービスであるため、インフラストラクチャ稼働状況の監視やメンテナンスなどの重要なタスクは、Azure によって処理されます。 Azure は Kubernetes マスター ノードを管理するため、必要なのはエージェント ノードの管理と保守のみです。
Service Fabric から AKS にワークロードを移動するには、コンテナー化されたアプリケーションを自信を持って移行できるように、基になるインフラストラクチャの違いを理解する必要があります。 次の表は、2 つのホスティング プラットフォームの機能と特徴を比較したものです。
| 機能またはコンポーネント | Service Fabric | AKS |
|---|---|---|
| コンテナー化されていないアプリケーション | はい | いいえ |
| Linux コンテナーと Windows コンテナー | はい | はい |
| Azure マネージド コントロール プレーン | いいえ | はい |
| ステートレスとステート フル ワークロード両方のサポート | はい | はい |
| ワーカー ノードの配置 | Virtual Machine Scale Sets (ユーザーによる構成) | Virtual Machine Scale Sets (Azure マネージド) |
| 構成マニフェスト | XML | YAML |
| Azure Monitor の統合 | はい | はい |
| Reliable Services と Reliable Actor パターンのネイティブ サポート | はい | いいえ |
| Reliable Services の WCF ベースの通信スタック | はい | いいえ |
| 永続的ストレージ | Azure Files ボリューム ドライバー | CSI ストレージ クラス、永続ボリューム、永続ボリューム要求を介した、マネージド ディスク、Azure Files、Azure Blob Storage など、さまざまなストレージ システムのサポート |
| ネットワーク モード | Azure Virtual Network の統合 | 複数のネットワーク プラグイン (Azure CNI、kubenet、BYOCNI)、ネットワーク ポリシー (Azure、Calico)、イングレス コントローラー (Application Gateway イングレス コントローラー、NGINX など) のサポート |
| イングレス コントローラー | Service Fabric に組み込まれているリバース プロキシ。 Service Fabric クラスターで実行されるマイクロサービスが、HTTP エンドポイントを持つ他のサービスを検出し、そのサービスと通信するのに役立ちます。 Service Fabric で Traefik を使用することもできます | マネージド NGINX イングレス コントローラー、BYO イングレス オープンソース、プラットフォームで管理されるパブリックまたは内部ロード バランサーを使用する商用コントローラー (NGINX イングレス コントローラー、アプリケーション ゲートウェイイングレス コントローラーなど) |
Note
Service Fabric で Windows コンテナーを使用する場合は、移行を容易にするために AKS で使用することをお勧めします。
移行の手順
一般に、Service Fabric から AKS への移行手順は次のとおりです。
デプロイ アーキテクチャを確立し、AKS クラスターを作成します。 AKS には、クラスター アクセス、ノードとポッドのスケーラビリティ、ネットワーク アクセスと構成などを構成するためのさまざまなオプションが用意されています。 一般的なデプロイ アーキテクチャの詳細については、「 Example アーキテクチャを参照してください。 AKS ベースライン アーキテクチャには、クラスターのデプロイと監視のガイドラインも示されています。 AKS の構築 には、ビジネス要件と技術要件に基づいて AKS クラスターをデプロイするためのクイック スタート テンプレートが用意されています。
Service Fabric アプリケーションを再設計します。 Reliable Services や Reliable Actors などのプログラミング モデルを使用する場合、または他の Service Fabric 固有のコンストラクトを使用する場合は、アプリケーションの再設計が必要になる場合があります。 Reliable Services から移行するときに状態管理を実装するには、 Distributed Application Runtime (Dapr)を使用します。 Kubernetes には、Reliable Actors から移行するための パターンと例 が用意されています。
アプリケーションをコンテナーとしてパッケージ化します。 Visual Studio には、Dockerfile を生成し、アプリケーションをコンテナーとしてパッケージ化するためのオプションが用意されています。 作成したコンテナー イメージを Azure Container Registry にプッシュします。
Service Fabric 構成 XML ファイルを Kubernetes YAML ファイルとして書き換えます。 アプリケーションは、YAML ファイルを使用するか、Helm チャートを使用してパッケージとして AKS にデプロイします。 詳細については、「 アプリケーションとサービス マニフェストを参照してください。
アプリケーションを AKS クラスターにデプロイします。
デプロイ戦略に基づいて AKS クラスターへのトラフィックを移行しアプリケーションの動作、可用性、パフォーマンスを監視します。
サンプル アーキテクチャ
AKS と Azure では、ビジネス ニーズに合わせて環境を柔軟に構成できます。 AKS は、他の Azure サービスと適切に統合されています。 AKS ベースライン アーキテクチャ例を示します。
出発点として、いくつかの主要な Kubernetes の概念を理解し、アーキテクチャの例をいくつか確認します。
Note
Service Fabric から AKS にワークロードを移行する場合は、Service Fabric Reliable Actors を、Dapr アクター の構成要素に置き換えることができます。 Service Fabric Reliable Collections は、Dapr 状態管理の構成要素に置き換えることができます。
Dapr は、マイクロサービス接続を簡略化する API を提供します。 詳細については、「 Dapr への導入」を参照してください。 Dapr を AKS 拡張機能として インストールすることをお勧めします。
アプリケーション マニフェストとサービス マニフェスト
Service Fabric と AKS では、アプリケーション マニフェストとサービス マニフェストのファイルの種類とコンストラクトが異なります。 Service Fabric では、アプリケーションとサービスの定義に XML ファイルが使用されます。 AKS では、Kubernetes オブジェクトの定義に Kubernetes YAML ファイル マニフェストが使用されます。 Service Fabric XML ファイルを Kubernetes YAML ファイルに移行することを特定の目的としたツールはありません。 ただし、次のリソースを確認することで、Kubernetes での YAML ファイルの動作について学習できます。
Kubernetes ドキュメント: Kubernetes オブジェクトについて。
Windows ノード/アプリケーションの AKS ドキュメント: Azure CLI を使用して AKS クラスター上に Windows Server コンテナーを作成する。
Helm を使用すると、パラメーター化された YAML マニフェストを定義し、静的なハードコーディングされた値をプレースホルダーに置き換えることで、ジェネリック テンプレートを作成できます。これは、デプロイ時に指定されたカスタム値に置き換えることができます。 カスタム値を含むテンプレートの出力結果は、Kubernetes の有効なマニフェストとしてレンダリングされます。
Kustomize では、テンプレート不要でアプリケーション構成をカスタマイズする方法が導入されおり、市販アプリケーションの使用が簡素化されます。 Kustomize は、Helm と一緒に使用したり、Helm の代わりに使用したりできます。
Helm と Kustomize の詳細については、次のリソースを参照してください。
- Helm のドキュメント
- Artifact Hub
- Kustomize のドキュメント
- kustomization ファイルの概要
- Kustomize を使用した kubernetes オブジェクトの宣言型管理
ネットワーク
AKS には、基になるネットワークに 2 つのオプションがあります。
独自の Azure 仮想ネットワークを使用して、指定した仮想ネットワークからサブネットに AKS クラスター ノードをプロビジョニングします。
クラスターが使用するすべての Azure リソースを含むノード リソース グループに、AKS リソース プロバイダーが新しい Azure 仮想ネットワークを作成できるようにします。
2 番目のオプションを選択すると、Azure によって仮想ネットワークが管理されます。
Service Fabric には、ネットワーク プラグインの選択肢はありません。AKS を使用する場合は、次のいずれかを選択する必要があります。
kubenet。 kubenet を使用すると、IP アドレスは Azure 仮想ネットワーク サブネットからノードに割り当てられます。 ポッドは、ノードの Azure 仮想ネットワーク サブネットとは論理的に異なるアドレス空間から IP アドレスを受け取ります。 その後、ポッドで Azure 仮想ネットワークのリソースに到達できるように、ネットワーク アドレス変換 (NAT) が構成されます。 トラフィックの送信元 IP アドレスは、ノードのプライマリ IP アドレスに NAT 変換されます。 この方法により、ポッド用にネットワーク空間で予約する必要がある IP アドレス数が大幅に削減されます。
Azure CNI。 Container Networking Interface (CNI)を使用すると、すべてのポッドがサブネットから IP アドレスを取得し、直接アクセスできます。 これらの IP アドレスは、ネットワーク空間全体で一意である必要があり、事前に計画する必要があります。 各ノードには、サポートされるポッドの最大数に対する構成パラメーターがあります。 次に、相当する数の IP アドレスを各ノード用に予約します。 この方法には詳細な計画が必要であり、また多くの場合、アプリケーション需要の拡大に伴い IP アドレスが不足するか、より大きなサブネットでのクラスター再構築が必要になります。 クラスターを作成するとき、または新しいノード プールを作成するときに、ノードにデプロイできるポッドの最大数を構成できます。
Azure CNI オーバーレイ ネットワーク。 Azure CNI オーバーレイを使用する場合、クラスター ノードは Azure Virtual Network サブネットにデプロイされます。 IP アドレスは、ノードをホストする仮想ネットワークのアドレスとは論理的に異なるプライベート CIDR からポッドに割り当てられます。 クラスター内のポッドとノードのトラフィックは、オーバーレイ ネットワークを使用します。 NAT では、ノードの IP アドレスを使用して、クラスターの外部のリソースに到達します。 このソリューションでは、多数の仮想ネットワーク IP アドレスを節約し、クラスターを大規模なサイズにシームレスにスケーリングするのに役立ちます。 さらに、プライベート CIDR を異なる AKS クラスターで再利用できるため、AKS のコンテナー化されたアプリケーションで使用できる IP 空間が拡張されるというメリットもあります。
Azure CNI Powered by Cilium。 Cilium を搭載した Azure CNI は、Azure CNI の堅牢なコントロール プレーンと Cilium のデータ プレーンを組み合わせて、高パフォーマンスのネットワークとセキュリティ強化を実現します。
独自 CNI プラグインの使用。 Kubernetes には、既定のネットワーク インターフェイス システムが提供されていません。 この機能は、 network プラグインによって提供されます。AKS には、サポートされている CNI プラグインがいくつか用意されています。サポートされているプラグインの詳細については、「 AKS でのアプリケーションのNetwork の概念を参照してください。
Windows コンテナーでは現在、Azure CNI プラグインのみがサポートされています。 ネットワーク ポリシーとイングレス コントローラーには、さまざまな選択肢があります。
AKS では、Kubernetes ネットワーク ポリシーを使用し、相互通信できるコンポーネントを制御することにより、サービス内の通信を分離してセキュリティで保護できます。 既定では、Kubernetes クラスター内のすべてのポッドでは制限なしにトラフィックを送受信できます。 セキュリティ向上のため、Azure ネットワーク ポリシーか Calico ネットワーク ポリシーを使用してルールを定義し、マイクロサービス間のトラフィック フローを制御できます。
Azure ネットワーク ポリシー マネージャーを使用する場合は、Azure CNI プラグインを使う必要があります。 Calico ネットワーク ポリシーは、Azure CNI プラグインか kubenet CNI プラグインで使用できます。 Windows ノードに対する Azure ネットワーク ポリシー マネージャーの使用は、Windows Server 2022 でのみサポートされています。 詳細については、AKS のネットワーク ポリシーを使用したポッド間のトラフィックの保護に関する記事を参照してください。 AKS ネットワークについて詳しくは、「AKS におけるネットワーク」をご覧ください。
Kubernetes において、イングレス コントローラーはサービス プロキシとして機能し、サービスと外部間を仲介して、外部トラフィックがサービスにアクセスできるようにします。 通常、サービス プロキシには、TLS 終端、パスベースの要求ルーティング、負荷分散、認証や認可といったセキュリティ機能など、さまざまな機能が用意されています。 イングレス コントローラーは、HTTP および HTTPS 規則に基づいて外部トラフィックを Kubernetes サービスにルーティングするための抽象化と制御の別のレイヤーも提供します。 このレイヤーにより、トラフィック フローとトラフィック管理をよりきめ細かく制御できます。
AKS では、イングレス コントローラーをデプロイ、実行、操作するための複数のオプションがあります。 1 つのオプションとして、アプリケーション ゲートウェイイングレス コントローラーがあります。これにより、TLS 終端、パスベースのルーティング、およびWeb アクセス ファイアウォールとして、Azure アプリlication Gateway をイングレス コントローラーとして使用できます。 もう 1 つのオプションは、 管理された NGINX イングレス コントローラーであり、広く使用されている NGINX イングレス コントローラーに Azure で管理されるオプションを提供します。 Traefik イングレス コントローラー は、Kubernetes のもう 1 つの一般的なイングレス コントローラーです。
これらのイングレス コントローラーには、それぞれ長所と短所があります。 どちらを使用するかを決定するには、アプリケーションと環境の要件を検討します。 アンマネージド イングレス コントローラーをインストールするときに、Helm の最新リリースを使用し、適切な Helm リポジトリにアクセスできることを確認してください。
永続的ストレージ
Service Fabric と AKS の両方に、コンテナー化されたアプリケーションに永続的なストレージを提供するメカニズムがあります。 Service Fabric では、Docker ボリューム プラグインである Azure Files ボリューム ドライバーによって、Linux および Windows コンテナー用の Azure Files ボリュームが提供されます。 これは Service Fabric アプリケーションとしてパッケージ化されており、Service Fabric クラスターにデプロイして、クラスター内にある他の Service Fabric のコンテナー化されたアプリケーションにボリュームを提供できます。 詳しくは、「Service Fabric 用の Azure Files ボリューム ドライバー」をご覧ください。
AKS で実行されるアプリケーションでは、永続的なファイル ストレージ システムにデータを格納して取得することが必要になる場合があります。 AKS は、 Azure マネージド ディスク、 Azure Files、 Blob Storage、 Azure NetApp Storage (ANF)などの Azure Storage サービスと統合されます。 また、コンテナー ストレージ インターフェイス (CSI) ドライバーを介して、 Rook や GlusterFS などの Microsoft 以外のストレージ システムとも統合されます。
CSI は、Kubernetes のコンテナー化されたワークロードに、ブロックおよびファイル ストレージ システムを公開する標準です。 CSI を使用する Microsoft 以外のストレージ プロバイダーは、Kubernetes で新しいストレージ システムを公開したり、Kubernetes のコア コードを変更してリリース サイクルを待たずに既存のストレージ システムを改善したりするために、プラグインの作成、デプロイ、更新を行うことができます。
AKS での CSI ストレージ ドライバーのサポートにより、次の Azure ストレージ サービスをネイティブに使用できます。
Azure ディスク。 Azure ディスクを使用して、Kubernetes DataDisk リソースを作成できます。 ディスクでは、高パフォーマンス SSD によってサポートされる Azure Premium Storage、または Standard HDD または SSD によってサポートされる Azure Standard Storage を使用できます。 ほとんどの運用ワークロードと開発ワークロードでは Premium Storage が使用されます。 Azure Disk は ReadWriteOnce としてマウントされるため、AKS の 1 つのノードでのみ使用できます。 複数のポッドから同時にアクセスする可能性のあるストレージ ボリュームについては、Azure Files を使用します。
これに対し、Service Fabric では、マネージド ディスクを使用するクラスターまたはノードの種類の作成はサポートされますが、宣言型アプローチを使用して接続されたマネージド ディスクを動的に作成するアプリケーションはサポートされません。 詳しくは、「マネージド データ ディスクを使用する Service Fabric クラスター ノードの種類をデプロイする」をご覧ください。
Azure Files。 Azure Files を使用して、Azure Storage アカウントで構成した SMB 3.0 または 3.1 共有をポッドにマウントできます。 Azure Files を使用すると、複数のノードとポッド間でデータを共有できます。 Azure Files では、標準 HDD を備えた Azure Standard Storage または高パフォーマンス SSD を備えた Azure Premium Storage を使用できます。
Service Fabric には、Docker コンテナー用の Azure Files ボリュームを提供する Docker ボリューム プラグインとして Azure Files ボリューム ドライバーが用意されています。 Service Fabric には、Windows クラスター用ドライバーのバージョンが 1 つと、Linux クラスター用ドライバーのバージョンが 1 つ用意されています。
Blob Storage。 Blob Storage を使用して、Blob Storage (またはオブジェクト ストレージ) を、ファイル システムとしてコンテナーかポッドにマウントできます。 Blob Storage を使用すると、ログ ファイル データ、画像、ドキュメント、HPC ワークロードなど、大規模な非構造化データセットで動作するアプリケーションを、AKS クラスターでサポートできます。 Azure Data Lake Storage にデータを取り込む場合は、別の中間ファイル システムを構成せずに、ストレージを直接マウントして AKS で使用できます。 Service Fabric では、宣言モードで Blob Storage をマウントするメカニズムはサポートされていません。
ストレージ オプションについて詳しくは、「AKS におけるストレージ」をご覧ください。
アプリケーションとクラスターの監視
Service Fabric と AKS の両方で、Azure Monitor とそのサービス (Log Analytics など) とのネイティブ統合が提供されています。 監視と診断は、任意のクラウド環境でワークロードを開発、テスト、デプロイするために不可欠です。 監視には、インフラストラクチャとアプリケーションの監視が含まれます。
たとえば、アプリケーションの使われ方、Service Fabric プラットフォームで実行されたアクション、パフォーマンス カウンターを介したリソース使用率、クラスターの全体的な正常性を追跡できます。 この情報を基に、問題を診断して修正し、今後の再発を防ぐことができます。 詳しくは、「Service Fabric での監視と診断」をご覧ください。 コンテナー化されたアプリケーションを Service Fabric クラスターでホストして運用する場合は、コンテナーのイベントとログを表示するコンテナー監視ソリューションを設定する必要があります。
ただし、AKS には Azure Monitor と Container Insights との統合が組み込まれています。これは、クラウドにデプロイされたコンテナー化されたワークロードのパフォーマンスを監視するように設計されています。 Container Insights により、Kubernetes で使用可能なコントローラー、ノード、コンテナーから メトリック API 経由でメモリやプロセッサのメトリックが収集されることで、パフォーマンスが可視化されます。
Kubernetes クラスターからの監視を有効にすると、コンテナー化されたバージョンの Linux 向け Log Analytics エージェントを介して、メトリックとコンテナー ログが自動的に収集されます。 メトリックは Azure Monitor のメトリック データベースに送信されます。 ログ データは Log Analytics ワークスペースに送信されます。 これにより、AKS クラスターとその上で実行されるコンテナー化されたアプリケーションの両方の監視データとテレメトリ データを取得できます。 詳しくは、「Azure Monitor を使用して AKS を監視する」をご覧ください。
Container Insights の代替ソリューションまたはコンパニオン ソリューションとして、Prometheus 用 Azure Monitor マネージド サービスでメトリックを収集するように AKS クラスターを構成できます。 この構成を使用すると、 Prometheus プロジェクトに基づく Prometheus と互換性のある監視ソリューションを使用して、メトリックを大規模に収集および分析できます。 フル マネージド サービスを使用すると、 Prometheus クエリ言語 (PromQL) を使用して、監視対象のインフラストラクチャとワークロードのパフォーマンスを分析できます。 また、基になるインフラストラクチャを操作しなくてもアラートを受け取ることもできます。
Prometheus 用 Azure Monitor マネージド サービスは、Azure Monitor メトリックのコンポーネントです。 これにより、Azure Monitor を使用して、より柔軟にメトリック データの種類の収集と分析ができます。 Prometheus メトリックは、プラットフォームとカスタム メトリックと一部の機能を共有しますが、 PromQL や Grafana などのオープンソース ツールをより適切にサポートするための追加機能があります。
Azure 仮想マシンで実行できる Azure Managed Grafana とセルフホステッド Grafana 両方のデータ ソースとして、Prometheus 用 Azure Monitor マネージド サービスを構成できます。 詳しくは、「管理システム ID を使用して Grafana のデータ ソースとして Prometheus 用 Azure Monitor マネージド サービスを使用する」をご覧ください。
AKS アドオン
Service Fabric から AKS に移行する場合は、アドオンと拡張機能の使用を検討する必要があります。 AKS では、 Kubernetes イベント ドリブン自動スケーリング (KEDA) や GitOps Flux v2 などのアドオンと拡張機能を使用して、クラスターに対してサポートされる追加機能が提供されます。 AKS で一般的に使用されている、オープンソース プロジェクトやサード パーティから提供されている統合も多数用意されています。 AKS サポート ポリシーは、オープン ソースと Microsoft 以外の統合には対応していません。 詳しくは、「AKS のアドオン、拡張機能、およびその他の統合」をご覧ください。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
Ally Ford | プロダクト マネージャー II
Paolo Salvatori | プリンシパル カスタマー エンジニア
ブランドン・スミス |プログラム マネージャー II その他の共同作成者:
Mick Alberts | テクニカル ライター
Ayobami Ayodeji | シニア プログラム マネージャー
Moumita Dey Verma | シニア クラウド ソリューション アーキテクト
フランシスコ・シミー・ナザレ |シニア テクノロジー スペシャリスト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次のステップ
- AKS ニュース: AKS リリース ノート、AKS ロードマップ、Azure 更新プログラム
- Windows コンテナーを使用して既存のアプリケーションをコンテナー化する
- AKS についてよく寄せられる質問