DSを活用する4.各構成のメリットと考慮すべき点5.ベストプラクティス6.終わりに1.はじめに10月に入り、大分涼しくなって参りました。秋は高気圧と低気圧が周期的に訪れ、台風なども頻繁に発生するため非常に体調を崩しやすい時期です。皆様におかれましても、十分にご自愛ください。新型コロナウイルスCOVID-19の影響で、私たちの仕事の在り方が、半ば強制感を伴いながら大きく変容しています。Desktop(以下、WVD)など、DaaSと呼ばれる仮想デスクトップなどで開発・運用ワークロードを構築したいというご相談を受けることも多くなっています。...私の所属しているRPA事業部では、以前からRPA稼働環境としてWorkSpacesなどを活用する事例も多かったのですが、withコロナとも呼ばれる時代の働き方の中で、柔軟性や迅速性に優れるクラウド・コンピューティングがより身近になってきていることを肌で感じつつあります。AppsのようなPaaSのように、クラウドの提供するサービスは高いアジリティ(機動性)が要求される現状のビジネスニーズに即した形で、以前にも増して活用の幅が大きくなることが予想されます。一方で、クラウドが活用されればされるほど、クラウド上のリソースをどのように管理・認証していくか、という問題が付きまといます。WorkSpacesの台数や利用者が増えれば、それらの仮想デスクトップをどのようにセキュアかつ効率的に管理していくかが重要になってきます。Directory(以下、AD)」を使用し、IDや認証・認可を管理していく企業は非常に多いため、クラウドリソースを管理していく上でも非常に重要な位置づけを担います。(ご承知のように、Windows環境のDaaSはAD連携がセオリーです)しかしながら、これまで私がお手伝いさせていただいたクラウド移行のプロジェクトなどにおいても、ADに関する設計はその重要性の割に後回しにされやすく、かつナレッジがあまりないように感じます。そこで今回はAWSとAzureのサービスを例に、既存のオンプレミス環境からのクラウド移行シナリオにおけるADデザインパターンについて考えてみましょう。2.AWSでの構成AWSでADを使用するにはいくつかのパターンがあります。機能的な制約が大きく、今回移行を前提としたシナリオのスコープからは除外しています以下、簡単ですが構成図とポイントを紹介していきます。Connectorでオンプレミスのドメインコントローラーを参照するこのパターンでは、既存のドメインコントローラー(以下、DC)をVPN等で直接AWS上のリソースから参照します。Connectorによってサインイン要求をオンプレミスDCに転送する必要があります。Connectorは必須ではありません。Serverを構築し、ドメインコントローラーとしての役割を追加します。aのパターンとは異なり各環境にDCが存在するため、ネットワーク障害時にもそれぞれの環境への影響は最低限で済み、LDAPや認証にかかるトラフィックも分散され、レイテンシも改善すると思われます。ADを活用したパターンです。R2をベースに稼働するドメインコントローラーのマネージドサービスとなります。フルマネージドサービスであるため可用性確保のための冗長構成設計やバックアップ、パッチ適用など管理は全てAWS側の責任となります。bのパターンと同様のメリットを享受しつつ、仮想マシンで構築するよりもコスト面では有利となるケースが多いと思われます(DCとなる仮想マシンを冗長化した場合等)。この構成だとオンプレミスの既存フォレストとは別にAWS上に新規のフォレストができることとなる点がaやbと大きく異なります。マネージドサービスであるが故、ユーザー側で管理できる範囲に制限があります。現状の使い方次第では要件を満たせない可能性も十分に考えられるため慎重な評価が必要です。3.Azureでの構成AzureにおいてAD設計をするうえでも、基本的にはAWSと同様、a~cのパターンが基本となります。Services(以下、AADDS)という類似の2つのサービスがあり、それぞれの役割をよく理解することが肝要です。比較)極々単純化して違いを説明した場合、以下の様になるでしょう。Directoryとは技術的に別物と評価してもよいと思われます。Directoryをクラウド基盤を前提として再構築したサービスですので、既存ADの完全代替とはならない点要注意です。以下、AWSと同様に構成図とポイントを紹介していきます。a.オンプレミスDCを参照する既存のDCをVPN等で直接参照するパターンです。Routeなどで通信が可能であれば、仮想マシンスケールセット(VMSS)やWVDなどに対しドメイン参加が可能です。Serverを構築し、ドメインコントローラーとしての役割を追加するパターンです。Servicesを活用した例です。AADDSはオンプレミスのDCと直接レプリケーションはできず、AADからの一方向連携となる点がAWSとは大きく異なります。それ以外の、新フォレストとしてデプロイすることになる点や、マネージドサービスであるが故の制約がある点などは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をはじめ多くのクラウドプラットフォームにおけるクラウド開発・移行で多くの実績や事例があります。クラウド移行の検討でお困りのことがありましたら是非お声がけください。ご連絡・ご相談や本コラムの内容を更に詳しく知りたい方はこちらからお問い合わせください。...最新情報をお届けします!RPAに関する最新コラムやイベント情報をメールで配信中です。