Azure Hybrid Day の技術要素を整理する — Azure Arc / Azure Stack HCI を中心に

この記事の内容

  • インフラの基本構成（CPU・ストレージ・ネットワーク）から、オンプレミス／プライベートクラウド／パブリッククラウドの配置モデルまでを俯瞰します
  • プライベートクラウドの3種類（エンタープライズ・ローカル・ホステッド）の違いを整理します
  • ハイブリッドクラウド・マルチクラウド環境が抱える「サイロ化」の課題と、Azure Arc による統合管理の考え方を解説します
  • Azure Arc が管理できる対象範囲（OS・Kubernetes・SQL・VMware 等）を具体的に説明します
  • アプリケーション開発者視点での Azure Arc の価値と、Azure Stack HCI の位置づけについても触れます

はじめに

Microsoft のハイブリッドクラウド関連技術は、Azure Arc、Azure Stack HCI、ハイブリッドクラウド、マルチクラウドなど、扱う要素が非常に多岐にわたります。それぞれの技術がどこに位置づけられるのか、互いにどういう関係にあるのかが見えにくくなりがちです。

本記事では、インフラの基礎からクラウドの配置モデル、そして Azure Arc が目指す世界観まで、全体を俯瞰しながら整理していきます。

インフラの基本構成から始める

まず、どんな IT 基盤にも共通する「インフラの基本」を確認しておきましょう。

インフラとは突き詰めると、以下の3要素から成り立っています。

  • CPU・メモリ（計算リソース）
  • ストレージ（データ保存）
  • ネットワーク（通信）

この3要素は、オンプレミスであってもクラウドであっても、物理サーバーであってもサービスとして利用する形態であっても変わりません。

その上に OS があり、ミドルウェアがあり、アプリケーションが乗ってきます。これは IT 基盤の基本中の基本です。

仮想化とコンテナ

現在では、物理サーバーに直接 OS を入れるケースよりも、ハイパーバイザーを介して**仮想マシン（VM）**を動かす形態がほぼ標準となっています。1台の物理サーバー上で複数の独立した環境を実現できるのが仮想化の大きなメリットです。

さらに近年ではコンテナという形態も広く普及しています。コンテナは OS を共有しつつ、各アプリケーションを独立した環境で動かす仕組みです。仮想マシンと比較すると軽量で、起動が速く、持ち運びやすいという特徴があります。

インフラの形態を大きく分けると、以下の3種類になります。

  1. 物理ハードウェアを直接利用する形態
  2. 仮想マシンを利用する形態
  3. コンテナを利用する形態

どの形態であっても、その上にソリューションやアプリケーションが乗ってくるという構造は変わりません。

配置モデル — どこに置くか

インフラをどこに配置するかという観点では、大きく2つの場所があります。

  • オンプレミス：自分たちが管理する場所に置く
  • クラウド：クラウド事業者のインフラを利用する

さらにクラウドは、プライベートクラウドとパブリッククラウドに分かれます。

プライベートクラウドの3種類

プライベートクラウドといっても、一括りにできない多様な形態があります。インフラの配置場所・リソースの共有モデル・製品やサービスの利用形態・インフラ資産の所有者という観点で分類すると、以下の3種類に整理できます。

種類概要
エンタープライズプライベートクラウド自社で所有・管理するインフラ上に構築。占有環境でコントロールが完全
ローカルクラウドユーザー拠点内またはサービスプロバイダーの拠点に置くが、ユーザーが管理する形態
ホステッドプライベートクラウド（IPC）パブリックな場所にあるが、自分専用として占有できるプライベートクラウド

ホステッドプライベートクラウドの場合、インフラの物理的な場所はサービスプロバイダー側にありますが、リソースは占有して利用できます。これはパブリッククラウドの「共有モデル」とは異なります。

なお、エンタープライズプライベートクラウドの構成においては、**HCI（ハイパーコンバージドインフラストラクチャー）**が中心的な技術となっています。

ハイブリッドクラウドとマルチクラウド

ハイブリッドクラウドとは

ハイブリッドクラウドとは、「複数の配備モデルにまたがった運用の一貫性がある環境」と定義できます。

オンプレミス、プライベートクラウド、パブリッククラウドなど、さまざまな場所やサービスがあるなかで、どこでも同じように運用できる・同じように管理できるというのが重要なポイントです。

場所によって管理の方法が異なると、運用コストが膨大になります。そのため、一貫性のあるプラットフォームを選ぶことが極めて重要です。

マルチクラウドとは

マルチクラウドとは、複数のベンダーやプロバイダーが提供するクラウドを利用することを指します。たとえば Azure をメインとして使いながら、特定の用途で AWS や GCP も利用するケースが該当します。

また、Azure Stack HCI と Red Hat OpenShift が同じ環境に存在するケースも、広義のマルチクラウドの見方ができます。

現実はどうなるか

実際の IT 環境では、以下のような理由でマルチクラウド・ハイブリッドクラウドになっていきます。

  • パブリッククラウドには置けないシステムがある
  • ソフトウェアライセンスのハイブリッド特典を活かして Azure を選択する
  • 特定の AI エンジンや SaaS を利用するために別のクラウドを利用する

ほっておくと、データベースは A クラウド、AI は B クラウド、という形で分散してしまいます。これが「サイロ化」と呼ばれる問題であり、管理コストの増大につながります。

Azure Arc — すべてを一元管理する

こうした複雑なマルチクラウド・ハイブリッドクラウド環境をどう管理するかという答えが、Azure Arc です。

Azure Arc の考え方は明快です。

すべてのものを Azure に接続し、Azure から一元管理する

AWS 上のシステムも、GCP 上のシステムも、自社のエンタープライズプライベートクラウドも、ホステッドプライベートクラウドも——すべてを Azure に接続して、Azure の管理サービスを使って統合管理することを目指しています。

Azure には OS のモニタリング・ポリシー管理・セキュリティ管理など、管理のためのサービスが豊富に揃っています。Azure Arc はその「つなぎ役」となり、Azure 上にないシステムであっても Azure の管理下に置くことができます。

Azure Arc が管理できる対象

Azure Arc が管理できる対象は、OS 層から順に拡大してきています。

OS レベル

まず基盤となるのは OS の管理です。

対--象WLOiiSnn:duoxw（s各デSィeスrトvリeビrューション）

OS を押さえることで、事実上大多数の環境をカバーできるようになります。

SQL Server

Windows Server の中に含まれるケースもありますが、SQL Server は独立した対象として特別に扱われています。データベースの中身まで含めた管理が Azure から行えます。

Kubernetes（コンテナオーケストレーション）

Kubernetes（k8s）エンジンを管理下に置けるようになっています。Kubernetes に接続することで、その上で動くコンテナを管理できるようになり、ほぼすべてのワークロードをカバーできます。

VMware（仮想基盤）

Azure Stack HCI 以外の仮想基盤として、市場シェアの高い VMware vSphere にも対応しています。仮想基盤レイヤーからまとめて管理できるようになっています。

Azure Arc の接続の仕組み

Azure Arc で管理対象に接続する際、管理対象の環境の中にエージェントが動作します。

  • Windows Server / Linux を管理する場合 → エージェントがインストールされる
  • Kubernetes を管理する場合 → 管理用のコンテナがクラスター上で動作する
  • Azure Stack HCI を管理する場合 → VM が1つ作成され、その中にエージェントが動作する

このエージェントが Azure と通信することで、管理が実現されています。

Azure のサービスをどこでも実行する

Azure Arc の役割は「接続して管理する」だけではありません。管理下に置いた Kubernetes クラスター上で、Azure のサービスそのものを実行することも可能です。

具体的には、以下のような Azure サービスがコンテナとして動作できるようになっています。

  • App Service
  • Functions
  • Logic Apps
  • API Management
  • Event Grid

さらにデータサービスとして、以下も対応済みです。

  • Azure SQL Managed Instance
  • PostgreSQL Hyperscale

これらは Azure 上だけでなく、Azure Arc で管理下に置いた任意の Kubernetes クラスター上でも実行できます。つまり、オンプレミスのクラスターであっても、他社クラウド上のクラスターであっても、Azure のサービスが動かせるということです。

Azure Stack HCI の位置づけ

Azure Stack HCI は、Azure Arc の「クラウドコントロールプレーンから全体を管理する」という文脈とは、少し異なる立ち位置にあります。

Azure Stack HCI はコントロールプレーンを自分自身が持っています。管理者は Azure Stack HCI に直接接続して管理します。

最大の特徴は、インターネット接続がない環境でも利用できる点です。インターネットに繋がらないような閉じた環境でも、Azure と同じやり方でインフラを運用できます。

A---zu完エイr全ッンeにジタ独コーS立ンネtしピッaたュトcネー接kッテ続トィ不Hワン要CーグのIク用環環の境の境小で主で型のなの筐プ用ク体ラ途ラへイ:ウのベド展ー型開ト運ク用ラウド構築

Azure Stack HCI 上に VM を立て、それを Azure Arc に接続することも当然可能です。閉じた環境でありながら、Azure Arc の世界観と連携させることができます。

なお、Azure Stack HCI は Hyper-V とは別物です。Microsoft としては、仮想基盤は HCI に集約してほしいという意図があるとみられ、Hyper-V 単体は Azure Arc の直接管理対象に含まれていない状況です。

クラウドコントロールプレーンという考え方

複雑化したハイブリッド・マルチクラウド環境を管理するためには、**クラウドコントロールプレーン（Cloud Control Plane）**という概念が必要になります。

どこかにある多様なリソースを「1つの場所から全部管理する」という考え方です。Azure Arc はこのコントロールプレーンとしての役割を担います。

重要なのは、管理の場所を統一することです。

  • ある環境はローカルで直接管理
  • 別の環境は Azure から管理

というように管理経路が分散してしまうと、一元化のメリットが失われます。Azure Arc を採用するならば、すべてを Azure 経由で管理するという方針で統一することが理想的です。

ただし現実的な移行期においては、Windows Admin Center のようなオンプレミス向けツールとの併用も考慮されています。Windows Admin Center 自体も Azure のサービスとして提供されており、オンプレから Azure へのサービス利用へとつなげることができます。

アプリケーション開発者にとっての意味

インフラ管理者だけでなく、アプリケーション開発者にとっても Azure Arc の世界観は大きな意味を持ちます。

開発者が望むのは、「一度書いたコードがどこでも動く」ことです。インフラによってコードを書き換える必要があったり、環境ごとに条件分岐が増えるのは好ましくありません。

この考え方はかつてから繰り返されてきたものです。

  • OS による抽象化 → 「どのハードウェアでも動く」
  • Java の JVM による抽象化 → 「Write once, run anywhere」
  • コンテナによる抽象化 → 「どの環境でも同じコンテナが動く」

Kubernetes が動いている環境であれば、どこで動かしても同じアプリケーションが動きます。そして Azure Arc で管理下に置いた Kubernetes クラスター上では、Azure のサービスも実行できます。

Azu┌││││└r──e───A---─A─z─r─uAオ他─c─rzン社──euプク─の─rレラ─ど世─Aeミウ─こ界─rスド─で観─c上の上─も（─kの─同開─管8k─じ発─理s8─よ者─下クs─う視─のラク─に点↓─任スラ─動）─意タス─く:一─のータ─度─環ー─書─境─い─│─た─│─コ──ー──ド─│────────────────│─┐┘

Azure にコミットしてアプリケーションを書いておけば、そのアプリケーションはオンプレミスでも、他社クラウドでも、Azure Arc が展開されているあらゆる場所で動かせます。これが Azure Arc の目指す世界観です。

まとめ

本記事では、Azure Hybrid に関連する技術要素を基礎から整理しました。ポイントをまとめると以下のとおりです。

  • インフラの本質はどの形態でも CPU・ストレージ・ネットワークの3要素であり、その上に OS・ミドルウェア・アプリケーションが乗る
  • 配置モデルはオンプレミス・プライベートクラウド（エンタープライズ・ローカル・ホステッド）・パブリッククラウドに分類できる
  • ハイブリッドクラウドとは配備モデルをまたいだ運用一貫性であり、マルチクラウドとは複数ベンダーのクラウドを利用することを指す
  • Azure Arc はすべての環境を Azure に接続し、Azure の管理サービスで統合管理するための仕組みである
  • Azure Arc の管理対象は OS → SQL → Kubernetes → VMware と広がっており、ほぼすべてのレイヤーをカバーしつつある
  • Azure Arc 管理下の環境では Azure のサービスそのもの（App Service、Functions、Azure SQL など）を実行することもできる
  • Azure Stack HCI はインターネット非接続環境向けのプライベートクラウド基盤として独自の価値を持ち、Azure Arc とも連携できる
  • 将来のマルチクラウド・ハイブリッドクラウド環境を見据え、今から Azure をクラウドコントロールプレーンとして採用するという設計方針を持つことが重要

Azure の管理サービス群は現在も進化を続けており、将来的にはさらに広い範囲の環境を Azure から一元管理できるようになることが見込まれます。今のうちにこの全体像を理解し、設計方針を定めておくことが、今後の IT 基盤の複雑化に備える上で有効です。