プライベートクラウド検討者のための Azure Stack入門

【第39回】「Build 2020」で発表されたAzure Stack Hubの最新情報（Part 1）

前回、久しぶりにAzure Stackファミリーの進化について解説しました。エッジの重要性が増している今、「オンプレミスの基盤＝これまで通りの仮想化基盤」という認識では時代の流れに乗り遅れる可能性があることを読み取っていただけたのであれば嬉しく思います。

さて、今回から2回に分け、米マイクロソフトが5月19日～20日（米国時間）、オンライン開催したイベント「Build 2020」で発表された「Azure Stack Hub」の最新情報をお伝えします。

Azure Stack HubをAzureから管理する新機能「Fleet Management」

数年前にAzure Stack Hubが登場した際、そのインパクトの強さから多くのユーザーの関心を集めました。これまでにないソリューションであったために期待値はさまざまで、筆者も「Azureから管理できるんですよね？」と聞かれたことは数えきれないくらいありました。

しかし、本連載をご覧いただいている方はご存じの通り、Azure Stack Hubのコンセプトは違います。簡単におさらいすると、Azure Stack Hubは、Azureから管理される側にいるのではなく、Azureと同じポータルを持ち、APIもコマンドも互換性を持つなど、「Azureと一貫性を持つクラウドの仕組み」を「Azureではないところでも動かせる」ことを重要視していたわけです（下図参照）。

とは言え、「Azureからの管理」は引き続きユーザーからの要望の多い機能でもありました。そこで今回発表されたのが、Azure Stack HubをAzureから管理する新機能「Fleet Management」（プライベートプレビュー）です。これにより、Azure Stack HubやAzure Stack Edgeなどオンプレミスに配置するサーバソリューションをAzureのポータルから管理できるようになります。

Kubernetesへの対応強化

「Kubernetes」は、オンプレミス≠仮想化基盤であることを示す特徴的なものの1つです。本稿ではクラウドネイティブやコンテナオーケストレーションの重要性についての解説は控えますが、今やKubernetesはクラウドネイティブなアプリケーションプラットフォームのデファクトスタンダードになりつつあると言ってもよいでしょう。Azure Stack Hubも時代の流れに対応すべく、Kubernetes対応を進めています。

まずはAzure Stack Hubの構造から見ておきましょう。Azure Stack Hubは、HCIをベースにSDNやポータル、Azureの管理基盤「Azure Resource Manager(ARM)」が動き、IaaSやマーケットプレースなどのサービスを提供します。もし、ここでKubernetesを動かしたいと思ったらどうするか？

Azureでは、KubernetesをARM対応にするための「AKS Engine」をGitHub上で開発しています。これをAzureに統合してサービスを提供しているのが「AKS(Azure Kubernetes Service)」であり、さらにAzure Stack Hubでも動くようにしたものが「AKS Engine on Azure Stack Hub」となります。GitHubからそのまま展開することもできますし、Azure Stack Hubマーケットプレースのテンプレートから展開することも可能です。

ここに加わる今回の新しい発表は、大きく2つあります。1つは、これまでプレビュー扱いだった以下の2つの機能のGA(General Availability：正式なサービス提供開始)です。

• Windows Containerサポート
• Azure CNIサポート

日本では、Windows Server上で動くアプリケーションのコンテナ化が進んでいるとは言い難い状況ではあるものの、Windows Serverで開発を続けつつクラウドネイティブな運用に変えていきたいという要望はあり、Azure Stack Hubが正式サポートを開始したというわけです。

また、Azure CNIサポートについても、仮想化基盤のエンジニアの方向けに簡単に解説しておきましょう。AzureやAzure Stack HubはクラウドSDNが動作しているため、利用者がネットワークを自由に作って仮想マシンを配置したり、ネットワークを制御したりすることができます。ただ、仮想マシン(Kubernetesノード)の上で動くコンテナは、何もしなければ仮想マシンのなかで動く仮想スイッチを経由してNATで通信をすることになります。それが、Azure CNIをサポートすることでコンテナがSDN上で直接動作するようなイメージになるわけです。

実際には、Kubernetesには「ポッド」と呼ばれる仕組みがあるので、ポッドとSDNが直接連携をします。詳しく知りたい方は、Azureのサイトにある記事「Azure Kubernetesサービス(AKS)でAzure CNIネットワークを構成する」をご覧いただくとわかりやすいでしょう。

さらに、以下の2つの機能についてプライベートプレビューの発表もありました。

• AKSネイティブサービス提供(リソースプロバイダーを提供)
• Azure Container Registryの提供

現在Azure Stack Hubでは、AKS Engine(テンプレートを含む)を使ってKubernetes環境を構築しますが、この作業はあくまでもテナント側が実施することになっています。要は、Azure Stack Hubの標準機能として管理者がポータルに組み込んだものを使えるわけではなく、Azure Stack Hubの利用者が自らの意志で展開をする必要があるわけです。「決められたサービスを使うより自由度が増す」という声もあるのですが、既にAzureのAKSをお使いの方にとっては1つ手間が増えるように見えるでしょう。今回、Azure Stack HubにAKSを組み込むためのリソースプロバイダーが提供されたことで、Azure Stack Hubのポータルと管理基盤にKubernetesを完全統合できるようになります。

また、これだけKubernetesやコンテナが重要になってくると、クラウドネイティブはパブリックなクラウドだけでなくプライベートクラウド上での利用も増えていくでしょう。そうなると、コンテナの展開元となるリポジトリもオンプレミスに欲しくなるのは当然の流れです。

こうしたことから、今回、Azure Container Registryのプライベートプレビューも発表されました。社内にクラウドライクなコンテナレジストリが存在することで、オンプレミスにおけるクラウドネイティブ推進の懸念を1つ払拭できるのではないかと思います。

*　*　*

さて、今回は、Build 2020で発表されたAzure Stack Hubの最新情報を整理してお伝えしました。本当は1回で収めるつもりだったのですが、ボリュームが多かったため、次回も引き続きAzure Stack Hubの情報をお伝えします。お楽しみに!