1.はじめに
10月に入り、大分涼しくなって参りました。秋は高気圧と低気圧が周期的に訪れ、台風なども頻繁に発生するため非常に体調を崩しやすい時期です。皆様におかれましても、十分にご自愛ください。
さて、新型コロナウイルスCOVID-19の影響で、私たちの仕事の在り方が、半ば強制感を伴いながら大きく変容しています。
その影響もあり、特に最近ではリモートワークを効率的かつセキュアに運用したいというニーズから、Amazon Web Service(以下、AWS)が提供するAmazon WorkSpacesやMicrosoft Azureが提供するWindows Virtual Desktop(以下、WVD)など、DaaSと呼ばれる仮想デスクトップなどで開発・運用ワークロードを構築したいというご相談を受けることも多くなっています。
私の所属しているRPA事業部では、以前からRPA稼働環境としてWorkSpacesなどを活用する事例も多かったのですが、withコロナとも呼ばれる時代の働き方の中で、柔軟性や迅速性に優れるクラウド・コンピューティングがより身近になってきていることを肌で感じつつあります。
AWS EC2やAzure Virtual Machineを代表とする仮想マシンをはじめ、前述のDaaSやAzure Web AppsのようなPaaSのように、クラウドの提供するサービスは高いアジリティ(機動性)が要求される現状のビジネスニーズに即した形で、以前にも増して活用の幅が大きくなることが予想されます。
一方で、クラウドが活用されればされるほど、クラウド上のリソースをどのように管理・認証していくか、という問題が付きまといます。仮想マシンやAmazon WorkSpacesの台数や利用者が増えれば、それらの仮想デスクトップをどのようにセキュアかつ効率的に管理していくかが重要になってきます。
その点、Microsoft社の提供する「Active Directory(以下、AD)」を使用し、IDや認証・認可を管理していく企業は非常に多いため、クラウドリソースを管理していく上でも非常に重要な位置づけを担います。(ご承知のように、Windows環境のDaaSはAD連携がセオリーです)
しかしながら、これまで私がお手伝いさせていただいたクラウド移行のプロジェクトなどにおいても、ADに関する設計はその重要性の割に後回しにされやすく、かつナレッジがあまりないように感じます。
そこで今回はAWSとAzureのサービスを例に、既存のオンプレミス環境からのクラウド移行シナリオにおけるADデザインパターンについて考えてみましょう。
2.AWSでの構成
AWSでADを使用するにはいくつかのパターンがあります。
- AWS Active Directory Connectorでオンプレミスのドメインコントローラーを参照する
- AWS上にEC2でドメインコントローラーを構築する
- AWSのフルマネージドサービスであるAWS Directory Service for Microsoft Active Directory (AWS Managed AD)を利用し、新フォレストをAWS上に構築する
※AWS Simple ADについてはターゲットが5000名以下のユーザー数で信頼関係を構築できない等
機能的な制約が大きく、今回移行を前提としたシナリオのスコープからは除外しています
以下、簡単ですが構成図とポイントを紹介していきます。
a. AWS Active Directory Connectorでオンプレミスのドメインコントローラーを参照する
このパターンでは、既存のドメインコントローラー(以下、DC)をVPN等で直接AWS上のリソースから参照します。
EC2で構築したWindows ServerなどであればVPNさえあればこれだけでドメイン参加が可能ですが、AutoScalingやWorkSpacesなどをドメイン参加させる要件がある場合は、AD Connectorによってサインイン要求をオンプレミスDCに転送する必要があります。(EC2だけをドメイン参加させる場合は、AD Connectorは必須ではありません。）
b.仮想マシン(EC2)でDCを構築する
このパターンでは、オンプレミスのDCとは別途EC2でWindows Serverを構築し、ドメインコントローラーとしての役割を追加します。aのパターンとは異なり各環境にDCが存在するため、ネットワーク障害時にもそれぞれの環境への影響は最低限で済み、LDAPや認証にかかるトラフィックも分散され、レイテンシも改善すると思われます。
c. AWS Directory Service for Microsoft Active Directory (AWS Managed AD)を活用する
こちらはAWSのマネージドサービスであるAWS Managed ADを活用したパターンです。AWS Managed ADはWindows Server 2012 R2をベースに稼働するドメインコントローラーのマネージドサービスとなります。
フルマネージドサービスであるため可用性確保のための冗長構成設計やバックアップ、パッチ適用など管理は全てAWS側の責任となります。また、bのパターンと同様のメリットを享受しつつ、仮想マシンで構築するよりもコスト面では有利となるケースが多いと思われます(DCとなる仮想マシンを冗長化した場合等)。
この構成だとオンプレミスの既存フォレストとは別にAWS上に新規のフォレストができることとなる点がaやbと大きく異なります。
3.Azureでの構成
AzureにおいてAD設計をするうえでも、基本的にはAWSと同様、a～cのパターンが基本となります。
ただし、Azureの場合、サブスクリプションを作成した際に必ずできるAzure Active Directory(以下、AAD)とオンプレのAD DSのマネージドサービスであるAzure Active Directory Domain Services(以下、AADDS)という類似の2つのサービスがあり、それぞれの役割をよく理解することが肝要です。
極々単純化して違いを説明した場合、以下の様になるでしょう。
・AAD…Windows365(Office365)やAzurePotalなどを含めたID管理
・AADDS…ドメインやグループポリシー、LDAPや認証などの基本的なDCの機能を提供
とくに注意すべき点はAADで、オンプレミスのActive Directoryとは技術的に別物と評価してもよいと思われます。AADは従来のActive Directoryをクラウド基盤を前提として再構築したサービスですので、既存ADの完全代替とはならない点要注意です。
以下、AWSと同様に構成図とポイントを紹介していきます。
a.オンプレミスDCを参照する
既存のDCをVPN等で直接参照するパターンです。
ポイントとしては、AWSのようにADConnectorのようなゲートウェイがなくてもVPNやExpress Routeなどで通信が可能であれば、仮想マシンスケールセット(VMSS)やWVDなどに対しドメイン参加が可能です。
-
b. Azure仮想マシンでDCを構築する
オンプレミスのDCとは別途Azure仮想マシンでWindows Serverを構築し、ドメインコントローラーとしての役割を追加するパターンです。
c. Azure AD DSを活用する
こちらはAzureのマネージドのドメインサービスである、Azure Active Directory Domain Servicesを活用した例です。
AADDSはオンプレミスのDCと直接レプリケーションはできず、AADからの一方向連携となる点がAWSとは大きく異なります。
4.各構成のメリットと考慮すべき点
さて、これまでAWS、Azureそれぞれのサービスを例としたADのデザインパターンをご紹介しました。a～cはAWS/Azureで仕様上の相違はもちろんあるのですが、構成上のメリットや考慮すべき点についてはAWS/Azureで大きく変わりません。
以下、メリットとデメリットを表で表してみました。
5.ベストプラクティス
さて、ここまでADのAWS/Azureにおける構成例を挙げてきましたが、どの構成を採るのが最善でしょうか。
この点、複数のデザインパターンの中からベストな構成を一律決めるのは難しいと言えます。どの様な構成をベストとするかは、既存のADの利用方法を詳細に分析したうえでフィット&ギャップを洗い出した上で、DRや可用性など個別の要件を勘案する必要があるためです。
そもそもクラウドを活用するのはオンプレの拡張ではなく、新技術などのサンドボックス的に使用する場合や、クラウドネイティブなワークロードのみを対象としたクラウドに閉じたシナリオなども考えられ、その場合は「ドメイン参加が必須か？」という点から改めて評価する必要があるでしょう。
上述のような点を鑑みる必要があるにせよ、私個人の意見としてお勧めしたいのはオンプレ・クラウドそれぞれにDCの機能を配置形でのc.マネージドサービスの活用です。このような構成とすることで、管理負荷を最大限減らしながら、大規模ネットワーク障害等でオンプレ・クラウド間の通信を喪失したとしてもアプリやユーザーに与える影響は最小限で済みます。
マネージドサービスをうまく活用することこそがクラウド利用の最適化に近づくと私は考えています。それにより、リソースや運用管理に係るコストを削減しながらビジネスのアジリティを高め、本来的な価値創出に主眼を置いたITリソース活用が可能です。
ただし、既存AD運用でマネージドサービスでは実現できない要件がある場合は、クラウド上に仮想マシンでDCを構築するパターンを初期時点では採用しつつ、各所調整をしながらマネージドサービス化を見据える必要があります。
6．終わりに
さて、今回はオンプレミスからの移行をテーマにADのデザインパターンを挙げさせていただきました。
AD以外でも各サービスで何を使っていくか(仮想マシンでサーバーをホストするか、PaaSを使うか等)検討を進める際、やはりクラウドネイティブな形に再構築するのが最もクラウドの利用価値が高いと言えます。
しかしながらオンプレミスの資産をマネージドサービスに載せ替えていくためには、対象リソースの有識者の力を借りながら要件を詳細化し、ロードマップとしていつ、どのように移行を検討していくかを具体化する必要があります。ADは特に機能や用途が多岐に渡り専門的な知識も必要であるため、現状把握に時間がかかるかもしれません。
要件によってはパターンaからb、cへと順にリプラットフォームを重ねながら移行していくことも検討する必要があるでしょう。
リホストにとどまらず、リプラットフォーム・リアーキテクチャを伴うクラウドへの移行は容易ではありません。BTCではAWS/Azureをはじめ多くのクラウドプラットフォームにおけるクラウド開発・移行で多くの実績や事例があります。もし、クラウド移行の検討でお困りのことがありましたら是非お声がけください。
【関連コラム】
