はじめに
この記事は、Microsoft Azure Tech Advent Calendar 2020 の 13 日目の記事です。
本日は Azure 内のサーバーだけでなく、オンプレミスや他のパブリック クラウド上で動作する各種サーバーの管理について記載いたします。具体的には、Azure Arc というサービスについてご紹介いたしますが、このサービスが登場した背景などを含めて記載したので、少々大作になってしまいました。そのため、目次を以下に記載いたしましたので、ご興味のある部分まで読み飛ばしていただければと思います。
- Azure Arc が登場した背景
- Azure Arc の概要
- 複数のプラットフォームで動作するサーバーを Azure リソースのように管理
- Azure のセキュリティ サービスをどこでも利用
- Azure データ サービスを Azure 外でも利用
- まとめ
それでは、はじめにの章も長くなってしまう前に、ここらへんで本文にまいります。
Azure Arc が登場した背景
もはや言わずもがなではありますが、昨今 Azure、AWS、GCP をはじめとしたパブリック クラウド サービスの発展が目覚ましく、新規サーバー構築時のプラットフォームとしてパブリック クラウドを第一選択肢とする方も多いと思います。クラウド サービスを利用するメリットはさまざまですが、例えばサーバー (クラウド用語で言うといわゆる IaaS VM) の利用を考えた場合、従量課金制という価格形態によって "使った分だけ" の費用が必要となり、コスト パフォーマンスが良いこと、あらかじめハードウェアを用意する必要がなく、VM のサイズ変更をすることで常に最新のハードウェアが使えるようになることなどが挙げられるかと思います。
一方で、新規サーバーの構築時にはパブリック クラウドを選ぶ場合でも、既存サーバーは引き続きオンプレミスのデータセンター内で稼働しているという状況も当然存在します。また、パブリック クラウドを利用する場合でも、Azure、AWS、GCP などの各種パブリック クラウド サービスにはそれぞれのメリットがありますので、システムの要件や特性に応じて複数のパブリック クラウドを利用するシナリオもあります。
このようなハイブリッド クラウド/マルチ クラウド構成は非常に一般的ですが、ここで問題となるのがサーバーの管理です。すべてのサーバーが同じプラットフォーム上で動作をする場合、例えばすべてのサーバーが Azure 上で動作をしている場合には Azure ポータルで一括した管理が可能です。しかし、複数の環境でサーバーが動作する場合、管理用のポータルが複数に渡るなど、管理が煩雑になります。(サーバーの台数が増えれば増えるだけ、より煩雑になるかと思います)
これらの課題は、Azure Arc というサービスを利用することで、すべてとは言えませんがある程度は解決が可能になります。まだ一部機能が GA (一般リリース) したてのサービスで、本日は概要について記載します。「あーこんなことができるんだ」程度にみなさまの頭に残り、実際に煩雑なサーバー管理に悩まれたときに、「そういえばそんなサービスあったな」という具合にふとした瞬間に思い出していただける一助になりましたら幸いです。
Azure Arc の概要
「Azure のサービスと管理をどのインフラストラクチャでも利用できる」というコンセプトの基に発表されたサービスで、以下のようなシナリオで利用できます。
- 複数のプラットフォームで動作するサーバーを Azure リソースのように管理
- Azure のセキュリティ サービスをどこでも利用
- Azure データ サービスを Azure 外でも利用
本当はもう少しシナリオがありますが、今回は個人的に Azure Arc のコンセプトに最も沿っているのではないかと思う上記 3 つについてご紹介します。
1. 複数のプラットフォームで動作するサーバーを Azure リソースのように管理
ひとくくりに管理と言ってもさまざまな作業を意味しますが、Azure Arc では以下のような管理が可能です。
- Azure 以外で動作するサーバーのメトリック データの確認
- Azure Policy を利用したコンプライアンス評価
- 更新プログラムの適用スケジュールなどの管理
- インベントリ情報の一括確認
これらの機能の中で、ひとつめとふたつめに記載したメトリック データの確認、およびコンプライアンス評価についてご紹介をいたします。その他の機能である更新プログラムの管理やインベントリ情報の確認については、Azure Automation というサービスの利用を Azure 外のリソースでも可能とすることで実現した機能であり、それぞれ Docs に詳細がありますので、こちらをご紹介させていただきます。
Azure Automation Update Management の概要 | Microsoft Docs
Azure Automation の変更履歴とインベントリの概要 | Microsoft Docs
Azure 以外で動作するサーバーのメトリック データの確認
各サーバーのメトリック データは、サーバーの稼働状況や負荷などを確認するために非常に重要です。例えば、CPU 使用率やメモリー使用量などのメトリック データを監視し、リソースが枯渇しそうなときにはサーバー台数を増やす (スケール アウト) ことでサービス停止を抑止するといった対応は一般的かと思います。
しかし、サーバーが複数のプラットフォームで動作している場合、例えば Azure、AWS、GCP のすべてでサーバーが動作をしている場合、各サービスそれぞれのポータル/コンソール画面でログの確認やアラート設定などが必要です。また、Zabbix などの監視用サーバーを構築することでメトリック データを一括監視できるようにはなると思いますが、監視サーバーの構築や保守などが必要になるという課題が生じます。
Azure Arc にサーバーを登録すると、Azure における監視サービスである Azure Monitor がすべてのサーバーで利用可能となります。具体的には、Azure Monitor for VMs という機能を利用することで、個別のサーバー、もしくは複数のサーバーのメトリック データが確認可能です。
今回は、AWS の EC2 (Elastic Compute Cloud)、GCP の GCE (Google Compute Engine)、オンプレミス環境のサーバーを Azure Arc に登録した結果を示してみます。Azure Arc にサーバーを登録すると、それぞれのサーバーが以下の通り Azure ポータルから確認できるようになります。
そして、Azure Monitor for VMs を有効化すると、以下のように各サーバーのメトリック情報も Azure ポータルから確認できるようになります。
また、Log Analytics と組み合わせることで、リソースの使用量が設定した閾値を超えた場合にアラート メールを送付するといった対応も可能です。詳細についてはこちらをご参照ください。
Azure Policy を利用したコンプライアンス評価
エンタープライズの場面では、各サーバーがしっかりとコンプライアンスに準拠し、情報漏洩などを未然に防ぐことが非常に重要です。Azure では、Azure Policy というサービスにより、サブスクリプションやリソース グループ、個々のサーバーなどの単位でポリシー定義と呼ばれるルール セットを割り当て、各サーバーが社内のコンプライアンス要件に準拠しているかの確認や、コンプライアンス要件をサーバーに強制するといった対応が可能です。Azure Arc にサーバーを登録することで、Azure Policy を利用したコンプライアンス評価が、プラットフォームに依存せず可能となります。
Azure Arc に登録された Azure 以外のプラットフォームで動作するサーバーでは、こちらに記載されているポリシー定義が利用可能です。例えば、Windows Server におけるパスワード期間の設定などを評価するポリシー定義なども存在し、準拠していない場合には以下のように Azure ポータル上に警告が表示されます。
2. Azure のセキュリティ サービスをどこでも利用
Azure Security Center では、Endpoint Protection、セキュリティ イシューが発生した際のアラート発報、脆弱性評価など、さまざまなセキュリティ関連の機能を提供しております。Azure Arc に登録されたサーバーも、このような Azure のセキュリティ サービスを利用することが可能となり、上述したコンプライアンス評価と併せて利用することで、企業資産の保護に繋がります。
なお、Azure Security Center で提供されるセキュリティ関連の機能は多岐にわたります。すべての機能を解説するとそれだけで超大作になりますので、今回はこの記事がマルチ クラウド環境の管理に焦点を当てていることを鑑み、セキュリティ リスクとなりえる設定事項の評価機能 (セキュリティの推奨事項) についてご紹介いたします。その他の機能についてはこちらをご参照ください。
セキュリティ リスクとなりえる設定事項の評価機能は、例えば RDP 用の 3389 ポートに通信可能なクライアント IP アドレスが制御されていない、Endpoint Protection が有効化されていないなどのリスクを自動検知し、推奨設定を案内する機能です。今までは Azure リソースに対する評価が可能でしたが、Azure Arc と本機能を併用することで、AWS や GCP のリソースについても、以下の通り評価が可能となります。
なお、AWS や GCP のリソースに対する評価を行う場合、それぞれのアカウントを Azure と連携する必要がありますので、以下のドキュメントをご参照ください。
Azure Security Center への AWS アカウントの接続 | Microsoft Docs
Azure Security Center への GCP アカウントの接続 | Microsoft Docs
3. Azure データ サービスを Azure 外でも利用
Azure Arc には、データ系サービスに関する機能として以下の 2 つがあります。
- さまざまなプラットフォームで動作する SQL Server を Azure ポータルで管理
- さまざまなプラットフォーム上に Azure の Managed Database サービスをデプロイ
前者は上述したサーバー管理機能の拡張機能のような立ち位置で、プラットフォームや OS によらず、さまざまな環境で動作する SQL Server をまとめて管理する機能です。つまり、SQL Server 自体はあらかじめインストールの必要があり、またプレビュー段階である現時点においては、SQL Server のメンテナンスはユーザーにて実施する必要があります。
一方、今回ご紹介する後者の機能は、Azure の PaaS サービスとして提供されている SQL Database Managed Instance、および Azure Database for PostgreSQL (Hyperscale) をオンプレミス、AWS、GCP など、さまざまなプラットフォーム上にデプロイする機能です。より厳密には、こちらに記載されているさまざまな環境で動作する Kubernetes クラスターに、SQL Database Managed Instance、および Azure Database for PostgreSQL をデプロイする機能です。ポイントは、Azure 上でこれらのサービスを利用する場合と同様に自動的に更新が行われる点にあり、ユーザーはメンテナンス コストをかけることなく、常に最新の状態で SQL Database Managed Instance や Azure Database for PostgreSQL が利用可能となります。Azure の PaaS サービスをさまざまなプラットフォームで利用できるという点が、「Azure サービスをどのインフラストラクチャでも利用できる」という Azure Arc のコンセプトに沿っていると感じています。
デプロイ手順の詳細などは割愛しますが、この機能は Kubernetes クラスターを作成し、Data Controller というリソースをデプロイすることで、SQL Database Managed Instance、もしくは Azure Database for PostgreSQL が利用可能となります。下記は GCP の GKE (Google Kubernetes Engine) を利用した例となりますが、デプロイが完了すると、Kubernetes クラスターの指定した Namespace 内にさまざまな Pod がデプロイされることが確認できます。(赤枠で囲っていますが、Managed Instance も Pod として動作いたします)
また、Kubernetes クラスター上で動作をいたしますので、CPU 使用率などは既定で利用可能な Grafana、および Kibana で確認できます。
現状、プレビュー機能のため、以下のような動作制限などがありますが、個人的には今後の発展が楽しみな機能です。
接続モードと要件 - Azure Arc | Microsoft Docs
Azure Arc 対応データ サービス - リリース ノート - Azure Arc | Microsoft Docs
まとめ
今回の投稿では、管理に焦点を当てて Azure Arc をご紹介させていただきました。現時点ではまだサーバー管理機能のみが一般リリースされた状況であり、他の機能はすべてプレビューではありますが、本日ご紹介した機能以外にもさまざまな用途に利用できるサービスです。今後ますますハイブリッド クラウド/マルチ クラウド化が進むかと思いますが、そんな環境を管理する方々にぜひ利用いただきたいです！