Microsoft Azureでは、サービスのハイブリッド/マルチクラウド化にKubernetesを利用している。今回は連載の最終回として、なぜKubernetesを使うのか、どのように使っているのかを具体的に説明する。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
第3回では、Kubernetesの管理を主題として、Azure Arcの提供機能や内部構造を具体的に解説しました。要点は4つです。
最終回の今回は、Azure Arc Enabled Servicesを解説します。機能の羅列は他に任せ、本質に迫ろうと思います。「サービスを名乗るためには何が必要か」「なぜKubernetesが必要なのか」を考えると、Azure Arc Enabled Servicesの価値や狙いが見えてきます。
第3回で触れた通り、Azure Arc Enabled Servicesは「Kubernetesを前提とし」「その拡張機能としてAzureのマネージドサービスを動かす」という構造をとります。
守りを固めるガードレール系の拡張機能は、第3回で紹介しました。今回はデータ、アプリサービス系機能にフォーカスします。現在、以下の拡張機能が提供されています。
ところで、いきなりAzure Arc拡張機能の存在を否定するようですが、クラウドでのデータ、アプリサービス系機能の利用経験に乏しい段階であれば、まずは各クラウドが提供するマネージドサービスの活用をお勧めします。理由は、それぞれのクラウドに最適化されているから、だけではありません。
Azure Arc拡張機能の導入や維持が楽だとしても、マネージドサービスには及びません。何より、使い手、つまりアプリケーション開発者やデータ分析者にとって価値があるかが先に議論されるべきです。標準化を急ぐと、その議論を抜きにして「複数のクラウドで動くから」という消極的な理由で選定してしまいがちです。しかし、使い手の立場では、価値を実感できていない、かつ所属する組織で手の内に入れている人がいないものを採用したくはないでしょう。
よって、Microsoft Azureのマネージドサービスを手の内に入れて推進する人がいる、または使い手の「Azureのこのサービスを他のクラウドやオンプレミスでも使いたい」というニーズが生まれてから、これらの拡張機能を検討するとよいでしょう。
Azure Arc Enabled Servicesにおいて、Microsoftは「ソフトウェア提供者」の立場をとります。Azureのマネージドサービスが定義しているSLA(Service Level Agreement)は、Azure Arc Enabled Servicesにはありません。なぜなら、サービスレベルはサービスの土台になる基盤と、その運用に大きく依存するからです。Azure Arcにおいて基盤を運用するのは、Microsoftではなくユーザーです。
とはいえ、ソフトウェアを提供するだけなら、「サービス」を名乗るべきではありません。従来のソフトウェアとは異なる導入と維持の体験をユーザーへ提供してはじめて、サービスと呼べる資格が得られます。
Azureのマネージドサービスでは、以下のような管理作業が内部で行われています。
多くの作業内容はイメージできると思いますが、スケジューリングのみ補足します。ここで言うスケジューリングとは、制約や条件をもとに、ソフトウェアの配置を決定することです。「ソフトウェアのCPUやメモリ要件を満たす空きがある仮想マシン(VM)へ配置する」「VM障害に備えて同じ役割のソフトウェアは同じVMに配置しない」などが代表例です。
Azureではこれらの作業をソフトウェアで自動化しています。人間が手作業で対応できるリソースやイベントの数を、はるかに超えているからです。つまり、これらの作業を自動化するソフトウェアが、サービスを支える実体と言っていいでしょう。Azure Arc Enabled Servicesの拡張機能がサービスを名乗るためには、同様の機能を提供すべきです。
Azureの作業を自動化するソフトウェアは、Azureのさまざまなリソース管理機能(プロバイダー)やサービスが持つAPIを前提に作られています。Azureのマネージドサービスを管理するだけであれば、それで十分です。ですが、Azure Arc拡張機能を他クラウドやオンプレミスに展開するのであれば、それぞれの環境に同様のAPIが必要です。他クラウドやオンプレミス向けの管理ソフトウェアは、Azureと生まれも育ちも違います。従って、Azureと同様のAPIがあることを前提にはできません。また、あったとしても、それぞれの環境向けに作られたAPIへ個別に対応し、変化に追従していくのは困難です。
そこでAzure Arc Enabled Servicesは、各クラウドやオンプレミスの違いを吸収するレイヤーとしてKubernetesを採用した、というわけです。これで、違いの吸収は、それぞれの環境のKubernetesマネージドサービスやディストリビューションに任せることができます。
では拡張機能の実装例を見てみましょう。Azure Arc Enabled SQL MIをKubernetesに導入すると、図2のように機能が配置されます。
NodeとはKubernetesがソフトウェア(コンテナ)を配置するサーバで、一般的にはVMです。そして、Node内にPodという単位でコンテナを配置します。Podには1つ以上のコンテナが含まれます。図2のNode内にある四角形は、Podを表しています。
その中で核となるのが、Azure Arc Data Controllerです。Azure Arc Data ControllerはAzureと連携し、先述したスケジューリング、スケーリングなどのさまざまな管理作業を行うソフトウェアです。SQL MIだけでなく、PostgreSQL Hyperscaleなど他のデータサービスも管理できます。
Data Controllerは、Kubernetesのオペレーターパターンに基づくソフトウェアです。Kubernetesの標準機能とカスタムリソースを活用し、データサービスの導入と維持作業を自動化します。
オペレーターパターン
(https://kubernetes.io/ja/docs/concepts/extend-kubernetes/operator/)
Data Controllerに合わせ、ログ、メトリクス関連のPodも導入されます。ところで、Azure ArcのデータサービスとAzureとの連携には「直接接続」「間接接続」という2つのモードがあり、求める連携レベルに応じて選択できます。直接接続を選択すると、ログやメトリクスをAzure Monitorに集約できます。接続モードを説明する公式ドキュメントは、Data Controllerが自動化している管理作業も整理しています。Data Controllerが何をしてくれるのかを確認する際の参考にしてください。
接続モードと要件
(https://docs.microsoft.com/ja-jp/azure/azure-arc/data/connectivity)
なお、データサービスのようにアプリケーションが大きく依存するサービスには、可用性を向上する仕組みが求められます。Azure Arc Enabled SQL MIの可用性向上オプションは2つあります。1つはKubernetesの持つPodの回復機能の活用、もう1つはAlways On可用性グループです。
高可用性を備えた Azure Arc 対応 SQL Managed Instance
(https://docs.microsoft.com/ja-jp/azure/azure-arc/data/managed-instance-high-availability)
既定ではKubernetesの持つ回復機能を使い、検知と回復をKubernetesが行います。例えば、Podが誤って削除された場合、Kubernetesは必要なPodが存在しないことを検知し、Podを再作成します。利点はシンプルであることと、必要リソースが少なく済むことです。ただし、Podを再作成している間はサービスが止まるという懸念があります。
一方、再作成ではなく、あらかじめPodを作成、待機させておき、素早く回復したいという場合には、複数Podで構成するAlways On可用性グループを選択できます。セカンダリをリードレプリカとして利用できる、また、アップデートなどのメンテナンス影響を緩和できる、などの利点もあります。
ところで、図2は筆者がSQL MIをAlways On可用性グループに配備した実際の例ですが、何か気づきませんか? そう、Node障害時にサービスが停止しないよう、複数あるSQL MI Podは、同じNodeに配置されません。これは、KubernetesスケジューラーのAnti Affinity設定を利用しています。他にも、CPUやメモリなどのリソース割り当て状況に応じたスケジューリング、永続データの扱いに適したPod管理(StatefulSet)など、Kubernetesの機能を大いに活用しています。同等の仕組みを各クラウドやオンプレミス向けに個別に開発し維持するのは、現実的ではありません。
なお、Azure Arc Enabled SQL MIはGA(General Availability、一般提供)されていますが、Always On可用性グループは現在プレビュー中のオプションです。Azure Arcの拡張機能は進化の激しいKubernetesを前提にしていることもあり、「プレビュー期間を長くとる」「インパクトの大きなオプションは提供サイクルを別にする」などのリリース管理が行われています。したがって、導入を判断する際には、拡張機能だけでなく、オプションの提供状態も合わせて確認することをお勧めします。
今回はAzure Arc Enabled Servicesを解説しました。要点を以下にまとめます。
さて、今回をもって本連載は終わります。ハイブリッド/マルチクラウドの管理、活用は標準化、トップダウンの視点から語られることが多い印象です。それに対し、Azure Arcは利用者の自主性を尊重するアプローチであることが、連載を通じて伝わったのであれば幸いです。読者の皆さまが多様な環境を使いこなすための道具や知識として、Azure Arcやそのコンセプトが役立つことを願っています。
Copyright © ITmedia, Inc. All Rights Reserved.