Microsoft Azureはクラウドネイティブに対応できるのか：Computer Weekly導入ガイド
Linuxを中心に構築されてきたクラウドネイティブにAzureは対応できるのか。クラウドネイティブアプリケーションのデプロイに適しているのか。
クラウドへの移行は一つの流れだが、それだけでなく完全なビジネスアジリティーのためにはクラウドネイティブアプリケーションが最善の結果をもたらすという主張がある。しかしクラウドネイティブはLinuxアプリケーションおよびコンテナ技術と関係している。「Microsoft Azure」は、クラウドネイティブのデプロイにどの程度適しているのか。
「クラウドネイティブ」アプリケーションという用語は不明瞭だ。この用語が使われているのは、リフト＆シフト方式で既存のアプリケーションをクラウドに移行させることと、クラウド環境で最適な事業価値を引き出すためにアプリケーションのアーキテクチャを変えることを区別する必要があるためだ。
サプライヤーに対して中立の立場を取るCloud Native Computing Foundation（CNCF）は、その定義の一環としてこう記している。
「クラウドネイティブ技術は、パブリック、プライベートおよびハイブリッドクラウドのような現代の動的な環境において、拡張可能なアプリケーションの開発と運用を行う組織を支援する。このアプローチの実例として、コンテナ、サービスメッシュ、マイクロサービス、イミュータブルインフラストラクチャ、宣言型APIが挙げられる。こうした技術は耐久性が高く、管理がしやすく、観察可能な緩い組み合わせのシステムを実現する。それを確実な自動化と組み合わせれば、技術者は最小限の労力で大きな影響を与える変更を高い頻度で行うことができる」
中核的概念
この定義には、複数の中核的な概念が盛り込まれている。恐らくその最先端に位置するマイクロサービスは、複数のサービスを組み合わせてアプリケーションを構成するというアイデアだ。それぞれのサービスは小さく、管理や更新が簡単にできる。
これには複数のメリットがある。その一つがアジリティーだ。小型のモジュールに手を加えることは、大きくて複雑なコードに手を加えるよりも手軽で、安全性も高い。もう一つは拡張性だ。それぞれのサービスは個別にモニターして拡張できるので、リソースを必要な分だけ正確に追加できる。第三に、それぞれのサービスに耐障害性を組み込むことで、耐性の高いアプリケーションを構築できる。
一方で代償もある。分散型アプリケーションは複雑性も呼び込み、多数のコンポーネントインスタンスを管理する負担も増える。
アプリケーションにとって正しいアーキテクチャの決定は、ビジネスにとっての重要度や予想される負荷といった多数の要素に左右される。幸いなことに現代のクラウドプラットフォームは、仮想マシン（VM）に依存してアプリケーションを直接ホスティングするのではなく、Microsoftの「Azure App Service」やAmazonの「AWS Elastic Beanstalk」のようなアプリケーションサービスを使っている限り、小規模なアプリケーションであっても一定の耐久性と拡張性がほぼ無償で提供される。
では、マイクロサービスはどうデプロイするのか。多くの場合、コンテナがデプロイのための理想的な単位になる。コンテナはVMに比べてはるかに軽量で、比較的うまく分離され、自動化とも相性がいい。コンテナは、開発者が定義してコードで指定する予測可能な環境が提供される。これによって「コードとしてのインフラ」が実現し、さらにはCNCFが言及しているイミュータブルインフラストラクチャも実現する。イミュータブルインフラストラクチャは、入れ替えることはできても変更することはできない。
コンテナ技術はもともとLinuxのために開発されたものだが、Microsoftは「Windows Server 2016」で「Windows Server Container」を導入した。Windows上のコンテナには2つの種類がある。標準的なコンテナ（最大限の効率性）に加え、Hyper-Vコンテナはリソース共有の低下と引き換えに分離性とセキュリティが向上する。
Dockerのおかげで、コンテナは簡単にデプロイできる。「Dockerfile」と呼ばれる設定ファイルの定義に従って、コンテナのインスタンス作成と運用が可能だ。ただし、例えば数百から数千のコンテナインスタンスで構成されるアプリケーションがあり、耐久性と拡張性、リソースの効率的な利用が求められる場合、手作業でコンテナをデプロイするのは問題外だ。コンテナのオーケストレーションツールとマイクロサービスに互いを発見させるためのディスカバリーサービスが必要になる。
そうしたツールは「Kubernetes」「Docker Swarm」「Mesosphere DC/OS」など多数ある。Googleが開発して今はCNCFが管理するオープンソースプロジェクトになったKubernetesは、全てではないにしても、ほとんどのケースで使われている。
予想される通り、大手パブリッククラウドプラットフォームは、コンテナとKubernetesに対する第一級のサポート提供を加速させている。Microsoftも例外ではなく、Azureはコンテナとマイクロサービスを強力にサポートするようになった。
MicrosoftはAzureでクラウドネイティブアプリケーション用の複数のソリューションを提供している。その一つは同社が開発した「Service Fabric」で、もう一つの「Azure Kubernetes Service」（AKS、旧称Azure Container Service）はKubernetesとMesosphere DC/OSに対応している。
もう一つのオプションである「Pivotal Cloud Foundry」は、MicrosoftとPivotalの提携を通じて提供され、LinuxとWindowsアプリケーションをサポートしている。Cloud Foundryは、「Diego」と呼ばれる独自のコンテナオーケストレーションツールからKubernetesへの移行を進めている。従って、これはAzureでマイクロサービスやKubernetesにつながるもう一つのルートだ。
全てのAzureコンテナプラットフォームで一般的に使われているサービスは「Azure Container Registry」（ACR）と呼ばれる。ACRのコンテナイメージは、Kubernetes、Service Fabric、Docker Swarm、DC/OS、Azure App Serviceなどを使ってデプロイできる。ACRは「Docker Registry 2 CLI（Command Line Interface）」をサポートする。
ACRの主要機能「Tasks」は、コードをGitHubリポジトリーに提供したり、他のコンテナが依存しているベースイメージを更新したりするイベントに反応して、自動的にコンテナイメージをビルドできる。
現在プレビュー段階にあるマルチステップタスクは、デプロイ前に行うテストやイメージの検証などのステップを追加できる。
ACRはまた、業界を横断するコンテナイメージのための標準「Open Container Initiative」のプレビューサポートも行っている。
Service FabricもAKSも前途は有望だ。Service FabricはAzureのインフラに深く浸透しており、「Office 365」のディレクトリサービス「Azure Active Directory」や、MicrosoftのNoSQLデータベース「Cosmos DB」を含む他のアプリケーションに使われている。同様にKubernetesは事実上の業界標準となり、その利用は伸びる一方の状況にある。
MicrosoftはService Fabricを「スケーラブルで信頼性に優れたマイクロサービスとコンテナのパッケージ化とデプロイ、管理を簡単に行える分散システムプラットフォーム」と位置付ける。これにはオーケストレーションツール（これもService Fabricと呼ばれる）と、コンテナ対コンテナ発見のためのサービスが含まれる。
マイクロサービスアプリケーションのためのフル管理型サービス「Service Fabric Mesh」は、現在プレビュー段階にある。マイクロサービスプラットフォームはクラスタを使い、その上にコンテナをデプロイする。Service Fabric Meshはクラスタ管理が抽象化でき、ユーザーはリソースとリソースの限度および可用性に関する条件のみを指定すれば済む。Service Fabric MeshはWindowsとLinuxの両方のコンテナに対応する。
Microsoftは2018年9月に行ったIgnite 2018カンファレンスで、Service Fabric Meshの複数の新機能を発表した。これには「Azure Files」（Azureでホスティングするファイルストレージ）をマウントできる機能や「Service Fabric Volume Disk」と呼ぶ耐久性の高いストレージが含まれる。
Kubernetesアプリケーションの管理
Kubernetesの世界において、「Chart（s）」はKubernetesリソースを記述するためのパッケージングフォーマットを指す。「Helm」はChart（s）を使ってKubernetesアプリケーションを管理するパッケージマネジャーだ。Chart（s）を使えばKubernetesアプリケーションのデプロイ、バージョニング、ロールアップが簡単になる。
MicrosoftがIgnite 2018でサポートを表明したHelmリポジトリーは、現在プレビュー段階にある。Helm ChartsはACRに保存できるようになった。
同社はまた、Azureをオンプレミスで使えるようにパッケージ化した「Azure Stack」でもKubernetesに対応すると発表した。
では、もしAzureに決めたとすると、クラウドネイティブアプリケーションはService FabricまたはKubernetesにデプロイすべきなのか。
この判断は、自分のスキルによって決まる場合がある。業界標準のKubernetesに対し、Service FabricはAzure独自のサービスなので、Kubernetesの方がよく理解されている可能性が高い。
アプリケーションモデルももう一つの要因だ。KubernetesはWindowsコンテナをサポートしているかもしれないが、Linux指向であることに変わりはない。JavaとLinux向けに書かれたアプリケーションの方が、「.NET Framework」やWindowsアプリケーションよりもKubernetesにはなじみやすい。
Service Fabricはある意味ではAzureのネイティブプラットフォームだ。Linuxにも対応しているが、必然的にWindows Serverコンテナの方が相性がいい。もしアプリケーションが.NETで開発されていて、多数のAzureサービスを利用しているのであれば、必然的にService Fabricの方が適している。
抽象化による複雑さの解消
Service Fabric Meshはまだ本番環境に対応していない。だが、拡張性が高いマイクロサービスアプリケーションのメリットを維持したまま、管理上の複雑性を抽象化によって解消する試みとして興味深い。ただしKubernetesのコミュニティーも管理と設定にまつわる負担軽減を図る取り組みが進められ、「私のコードを実行するだけ」の理想に近づきつつある。
CNCFエグゼクティブディレクターのダン・コーン氏はComputer Weeklyにこう語っている。「コミュニティーのリーダーに共通するテーマの一つとして、アプリケーションをKubernetesにデプロイする現在の方法（このコンテナを構築し、次にYAML［訳注］を書くという方法）は、大半の開発者が対応すべき正しい抽象化層ではない。だが、より良いものは何かというコンセンサスはない」
訳注：構造化データをシリアライズするためのデータ形式。Kubernetesの設定ファイルにも採用されている。
これはService Fabric Meshの領域であり、Kubernetesが今後も業界標準であり続けても、他のアプローチを使う理由が十分あり得ることを表している。
Copyright © ITmedia, Inc. All Rights Reserved.