技術情報 の記事一覧

「ハイブリッドクラウドへの道　～The road to hybrid cloud.～」今回は、Hyper-Vで利用できる「Hyper-Vレプリカ」を、Azure Site Recovery（ASR）を利用してディザスタリカバリ（災害対策）をクラウドと組み合わせて実現する方法をご紹介します。ASRについては以前3回に分けて解説しましたが（ https://www.gmo.jp/report/single/?art_id=215 ）Windows Admin Centerを利用することで複雑な設定を簡略化することができるようになったので、改めて「Azure Site Recovery with Windows Admin Center」して解説してゆきたいと思います。ASRはオンプレミスの仮想マシンのレプリカをAzure上に作成し、随時レプリケーションすることで災害対策を実現しています。それ以外にも、オンプレミスではなかなか制約があり実施できないサーバー機能のテストを、Azure上で一時的に実施する場合や、オンプレミスからAzureへ仮想マシンを移動する手段としても利用することができます。Windows Admin Centerは無料で利用できるサーバー管理ツールで、複数のサーバーやAzure上の仮想マシンを一元管理することができるとてもとても優れたツールです。 Windows Admin Center　のインストール まずは、Windows Admin Centerの利用環境を整えましょう。インストール先はHyper-Vを実行しているサーバー自体でもよいですし、別途管理用に仮想マシンを作成してインストールして、リモートから各サーバーを一元管理するといった構成でもOKです。 インストールするOSによっていくつか事前準備が必要となる場合がります。（ https://docs.microsoft.com/ja-jp/windows-server/manage/windows-admin-center/deploy/prepare-environment ）今回はWindows Server 2019の仮想マシンにインストールしてゆきます。Windows Server自体はドメインに参加していても、単独のワークグループの構成でも構いません。管理対象となるサーバーごとに個別に管理権限を割り当てることが可能です。 こちらから（ https://www.microsoft.com/ja-jp/cloud-platform/windows-admin-center ）インストーラーをダウンロードします。 ダウンロードした“WindowsAdminCenter1910.msi”を実行します。 Windows Admin Centerはブラウザベースの管理ツールなので、SSLで保護された通信が前提となります。すでにサーバーのSSL証明書がある場合はそちらを利用できますが、無い場合でも自己証明書を生成して利用可能です。 こちらの設定でインストールします。 インストールが完了しました。 ブラウザで“https://<コンピューター名>“のURLを開きます。今回のコンピューター名は“AdminCenter”としています。 サーバーの追加 最初の画面ではインストールしたコンピューター自身のみ表示されています。 ASRの対象となるHyper-Vを実行しているサーバーを追加します。「＋追加」をクリックしWindows Serverを追加します。 追加するサーバー名を入力します。 Windows Admin Centerをインストールしたアカウント自体に他のサーバーの管理者権限がある場合は、そのまま追加可能です。管理者権限が無い場合は、別途資格情報を入力するダイアログが表示されるので、適宜設定しておきます。 今回Hyper-Vサーバーは“HV”となります。 対象となるサーバーを追加しました。 Azure Site Recoveryのセットアップ 追加したサーバーのツール一覧から「Azureハイブリッドサービス」を選択します。 Azureとの接続を開始するために「利用を開始するには、Windows Admin Center ゲートウェイを登録してください。」をクリックします。 Azureのサインアップがまだの場合は、「アカウントの作成」をまず行います。Azureのサービスを利用できる場合は、「コピー」をクリックしてコードをコピーします。 コピーすると、「コードを入力します。」がリンクとなるので、クリックします。 コード入力ページが表示されるので、コピーしたコードを入力します。 コードの入力が完了しました。 続いてAzureのアカウントでサインインをします。 サインインが完了しました。 Windows Admin Centerのページに戻ると、「Azure Active Directoryアプリケーション」の接続項目が利用可能となっているので、「新規作成」を選択して「接続」クリックします。 「Azure portal でのアプリのアクセス許可」をクリックしてAzureポータルを表示します。 「に管理者の同意を与えます」をクリックします。 今回はAzure Active Directory名は“WIN1 Works”とう名前となっています。 状態に付与されたことが表示されればOKです。 Windows Admin Centerに戻って、再度「Azureハイブリッドサービス」を選択し、「Azureサービスを探す」をクリックします。 Azureとのハイブリッドクラウドを実現できるサービスがいくつか表示されますので、その中の「Azure Site Recovery」のセットアップをクリックします。 ASRを利用するための設定項目がいくつかありますので、それぞれ入力してゆきます。 ▼リソースグループ→新規作成 ▼Recovery Services コンテナー（レプリカされた仮想マシンの格納領域）→新規作成（コンテナー名を指定します。） ▼位置情報（レプリカされた仮想マシンの配置場所）→東日本 各項目を入力したらセットアップを実行します。「この費用はいくらかかりますか?」をクリックすると詳細な料金体系が表示されます。 オンプレミスとAzure間でのレプリケーションの場合、月額1792円で利用可能です。その他に最初の31日間無料ですが、Azure Storage、ストレージ トランザクション、データ転送について課金が発生する場合があります。 セットアップが完了後、Azureポータルで、リソースグループ内のRecovery Services コンテナーを確認すると、レプリケーションの準備が完了している状態が確認できます。 レプリケートするディスクを指定する場合やレプリケーションの細かい指定を行う場合は、こちらから「レプリケート」を選択することでウィザードに従って設定が可能です。 Hyper-Vを実行しているサーバーを確認してみると、ASRのためのエージェントがインストールされているのが確認できます。 以上でセットアップは完了です。 ここまでの設定内容をAzureポータルから行った場合、かなりの時間と手間を必要としますが、Windows Admin Centerを利用することで、大幅に作業効率がアップします。 レプリケーションの実行 準備が完了したので、オンプレミスのHyper-V上の仮想マシンをAzureへのレプリケーションを実行します。 Windows Admin Centerから行うレプリケーションはあらかじめ用意された設定内容で実施されます。 レプリケーションの細かい指定を行う場合は、AzureポータルのRecovery Services コンテナーからウィザード形式で実施することができます。今回レプリケーションを実施するのはこちらの仮想マシンとなります。Cドライブ50GBのディスクを利用しています。 Cドライブ以外の追加ディスクも同時にレプリケーション可能です。ASRでは第1世代、第2世代どちらの仮想マシンもサポートされています。仮想ハードディスクも容量固定、容量可変のどちらもサポートされています。 Windows Admin Centerから「仮想マシン」を選択します。 Hyper-V上の仮想マシンが表示されます。保護対象の仮想マシンを選択しチェックを入れます。 「詳細」から「VMの保護」を選択します。 「記憶域アカウント」で新規作成を選択後アカウント名を入力して、「VMの保護」をクリックしてレプリケーションを開始します。 Hyper-V上では初期レプリカの送信が開始しています。 VMの保護（レプリケーション）が完了しました。 AzureポータルのRecovery Services コンテナーで、「レプリケートされたアイテム」を確認してみると、仮想マシンがレプリケーションされていることが確認できます。 Hyper-Vからレプリケーションの正常性を確認してみると、きちんと有効になっているのが分かります。 テストフェールオーバーの実行 レプリケーションが完了したので、Hyper-Vレプリカ同様にテストフェールオーバーが実行可能か確認してみましょう。 AzureポータルのRecovery Services コンテナーで、「レプリケートされたアイテム」から該当する仮想マシンを選択します。 テストフェールオーバーが未実施のためアラートが表示されています。 また、レプリケーションされた仮想マシンのネットワークが未設定のためこちらもアラートが表示されています。 左メニューから「コンピューティングとネットワーク」を選択して、「編集」をクリックします。 「ターゲットネットワーク」に事前に作成しておいた仮想ネットワークを指定します。 「ターゲットネットワークインターフェイス」には“プライマリ”を設定して、「保存」をクリックします。 再びレプリケートされたサーバーの概要に戻り、構成の問題がクリアされているのを確認します。 テストフェールオーバーの準備が完了したので、「テストフェールオーバー」をクリックして実行します。 この内容でテストフェールオーバーを実行します。 テストフェールオーバーが完了しました。 仮想マシン一覧を確認してみると、新たに「<仮想マシン名>-test」という名前でフェールオーバーした仮想マシンが作成されているのが確認できます。 テストフェールオーバーが成功したのを確認できたので、「テストフェールオーバーのクリーンアップ」を実行して、仮想マシンを削除しておきます。 以上、Azure Site Recovery with Windows Admin Centerとなります。 Windows Admin CenterはオンプレミスとAzure上の仮想マシンやサービスを一元管理できる優れた機能を提供してくれます。 複雑なAzure上の設定を簡略化して作業効率のアップも期待できます。ハイブリッドクラウドを目指すには無くてはならないツールです。 無料で利用することができますので是非お試しください。

今回は、Azure上で仮想デスクトップサービスを提供可能にするWindows VirtualDesktop(WVD)の構築方法を解説します。少数の仮想デスクトップであれば、その都度仮想マシンを作成してユーザーに割り当てれば利用可能ですが、数十人以上の利用者を想定した場合では仮想マシンの作成や提供方法、サービスの管理方法など統一したシステムが必要となります。WVDはこれらを解決するための仮想デスクトップサービスとなります。オンプレミススでは実際の物理サーバーとクラウド上のサーバーを運用しつつ、クライアントマシンは全てAzure上の仮想デスクトップで提供といったハイブリッド化へのヒントとなります。今回紹介するのは、WVDを実際に動かしてみたいといった、最低限の評価ができるいたってシンプルな構成を最短で作成する方法となります。以下、Microsoft公式のWindows Virtual Desktop のドキュメントhttps://docs.microsoft.com/ja-jp/azure/virtual-desktop を参考に解説しています。 Windows Virtual Desktopの構成 WVDを構築するにはいくつかのモデルがありますが、今回はすべてをAzure上で完結するシンプルな方法で構築してゆきます。ドメインコントローラーの代わりに、Azure Active Directory Domain Service(AADDS)を利用しています。オンプレミスとのドメインと同期を取る場合は、前回までに紹介しました、「Azure AD Connect」（第4回参照　リンク挿入）を利用したアカウントの同期や、Azure VPNゲートウェイを利用した接続構成（第5回参照　リンク挿入）によるドメイン環境のハイブリッド化が必要となります。 WVDの構築は、以下の手順で行います。 1 AAADDSと管理者アカウントの設定2 仮想ネットワークの設定3 ユーザー作成4 Widows Virtual Desktop テナントの作成5 サービスプリンシパルとロールの割り当て6 ホストプールの作成7 リモートデスクトップで接続確認 それではさっそく進めてゆきましょう！ 1.AADDSと管理者アカウントの設定 WVDの仮想デスクトップはドメインアカウントで接続することになります。すでに運用中のActive Directoryのドメインアカウントも利用可能ですが、今回はAzure上で全て完結することになるので、Azure Active Directory Domain Service(AADDS)を利用しています。 AADDSの構築については「Azure Active Directory Domain Services の基本操作（ https://www.gmo.jp/report/single/?art_id=243 ）」ですでに紹介済みですので、WVD構築に関する部分にフォーカスして紹介します。 Azureにサインインした直後の既定のAzure Active Directoryを使ってAADDSを構築してゆきます。 WVD構築時に地域は統一しておく必要があります。今回は”東日本”を選択します。 既定の設定で仮想ネットークを作成します。 既定のままで次へ。 こちらも既定のままで次へ。 作成を実行します。 しばらく時間がかかりますが、“実行中”となればAADDSの構築完了です。 AADDSが完成したら、Azure Active Directoryのアカウントとパスワードのハッシュ同期を行うために、既存の管理者アカウントのパスワードリセットを行います。この管理者アカウントはAADのグローバル管理者のロール（役割）が割り当てられている必要があります。 一度管理者アカウントをサインアウトして、サインインし直します。ここでパスワードの更新となるので、新しいパスワードを設定することで、ハッシュの生成が有効となります。 2.仮想ネットワークの設定 WVDで仮想デスクトップを提供する仮想マシンが接続するための仮想ネットワークを設定します。AADDSの構築ですでに仮想ネットワークは作成されていて、仮想ネットワークのアドレス空間は”10.0.0.0/16”と広めに変更してあります。ここにホストプール（仮想マシン用の確保領域）専用のサブネットを追加します。 ホストプール用に10.0.2.0/24のサブネットを作成します。 “hostpool-subnet”このサブネットを後程利用します。 3.ユーザー作成 WVDでホストプールを作成する時に使用する専用アカウントを作成します。（管理者アカウントではエラーとなるため）AADで「新しいユーザー」を選択します。 “[email protected]”というアカウント名で作成します。 こちらのアカウントも同様にパスワードのリセットを実行してハッシュ同期を有効にしておきます。 管理者アカウントと同様に一度サインアウトして、サインインし直します。 もう一つ、リモートデスクトップ接続用のアカウントも作成しておきます。このアカウントでユーザーはリモートデスクトップが利用可能となります。 同様にパスワード更新を行います。 4.Widows Virtual Desktop テナントの作成 WVDテナント（Widows Virtual Desktopのサービス）を作成してゆきます。いくつか前準備が必要となるのでそれぞれ手順を追って解説します。 4-1.アクセス権の割り当て WVDはAADに対して様々な操作を行うため、アクセス許可をWVD自体に与える必要があります。ブラウザで「Windows Virtual Desktop サーバーアプリに対する管理者の同意フロー」 https://login.microsoftonline.com/common/adminconsent?client_id=5a0aa725-4958-4b0c-80a9-34562e23f3b7&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FRDWeb%2FConsentCallback を開き管理者アカウントでサインインし、「承認」を選択します。 こちらで完了です。 次に、こちらもブラウザで「Windows Virtual Desktopクライアントアプリに対する管理者の同意フローhttps://login.microsoftonline.com/common/adminconsent?client_id=fa4345a4-a730-4230-84a8-7d9651b86739&redirect_uri=https%3A%2F%2Frdweb.wvd.microsoft.com%2FRDWeb%2FConsentCallback を開き管理者アカウントでサインインし、「承認」を選択します。 こちらで完了です。 4-2.TenantCreator のロール割り当て WVDのホストプールを作成する際に必要となるロールを専用アカウントに割り当てます。Azureポータルに戻り、すべてのサービスから「エンタープライズアプリケーション」を検索し、選択します。 「Windows Virtual Desktop」を選択します。 「1.ユーザーとグループの割り当て」を選択します。 「ユーザーの追加」を選択して、先ほど作成したホストプールを作成する時に使用する専用アカウント[email protected]にTenantCreatorのロールを割り当てます。 4-3.テナントID (ディレクトリ ID)の取得 テナントIDはディレクトリIDとも呼ばれています。要するにAzure Active Directoryを識別するために割り当てられたID番号となります。Azureポータルから、AADを選択して「概要」を表示します。後程使いますので「テナントID」の値を取得しておきます。 4-4.サブスクリプションIDの取得 Azureポータルから、「サブスクリプション」を選択します。サブスクリプションIDが確認できます。こちらも後程使いますので取得しておきます。 4-5.テナントを作成する WVDのテナント作成はPowerShellで行う必要があります。PowerShellの実行はお使いのPCから可能です。まずは、PowerShell用のWindows Virtual Desktopモジュールをインストールします。 RDSアカウントを追加します。サインイン画面が表示されるので、AADの管理者アカウントadmin@[email protected]でサインインします。 テナントを作成します。：AADの名前と同じにしています。今回はwin1works.onmicrosoft.comの　“win1works” の部分がテナント名になります。：先ほど取得したテナントID (ディレクトリ ID)です。：先ほど取得したサブスクリプションIDです。実行すると、再びサインイン画面が表示されるので、AADの管理者アカウントadmin@[email protected]でサインインします。 例）New-RdsTenant -Name win1works -AadTenantId 00000000-1111-2222-3333-444444444444 -AzureSubscriptionId 55555555-6666-7777-8888-999999999999 5.サービスプリンシパルとロールの割り当て WVDでは管理者に代わって特定の用途に使用するためのリソースとして、管理タスクを実行する場合などはサービスプリンシパルが代行します。サービスプリンシパルを作成してゆきます。まずは、PowerShell用のAzureADモジュールをインストールします。 サービスプリンシパルを作成します。 サービスプリンシパルがWVDにサインインできるようにロールの割り当てを行います。 6.ホストプールの作成 ホストプールは仮想デスクトップの提供元となる仮想マシン用の確保領域になります。 Azureポータルから「リソースの作成」-「新規」で“Windows Virtual Desktop”を検索して「Windows Virtual Desktop - Provision a host pool」を選択します。 「Windows Virtual Desktop - Provision a host pool」から「作成」を選択します。 リソースグループ：必ず「新規作成」を選択します。リージョン：AADのネットワークの「地域」と同じ場所を選択します。例）東日本 Default desktop users：あらかじめリモートデスクトップ接続が可能となるユーザーアカウントを入力します。各アカウントは「,(カンマ)」区切りで複数入力可能です。ホストプール作成後PowerShellで追加可能です。例）[email protected],[email protected] 仮想デスクトップを提供する仮想マシンのサイズ（スペック）と台数を設定します。Virtual machine name prefix は仮想マシンに名前付けルーツで、名前の先頭に共通の文字が入ります。 仮想マシンの設定で、利用するOSの種類やディスクのタイプなど選択します。ここでのポイントは以下となります。AD domain jyoin UPN：AADの管理者アカウントではなく、先ほど作成した専用のアカウント（[email protected]）を指定します。 ▼Virtual network：　AADDS構築時に作成した仮想ネットワークを　選択します。（aadds-vnet） ▼vmSubnet：　ホストプール用に作成したサブネットを選択します。（hostpool-subnet(10.0.2.0/24)） ▼Windows Virtual Desktop tenant group：　既定の「Default Tenant Group」です。 ▼Windows Virtual Desktop tenant name：　先ほどテナント作成時に指定した名前を指定します。　AADの名前と同じにしています。　今回はwin1works.onmicrosoft.comの　“win1works” の　部分がテナント名になります。 ▼UPN：AADの管理者アカウントになります。（[email protected]） 「作成」を選択します。 ホストプールの作成が完了しました。 7.リモートデスクトップで接続確認 ここまでで、ようやくWindows Virtual Desktop の準備が整いました。実際にリモートデスクトップ接続で確認しみましょう。WVDのポータルサイト（ https://rdweb.wvd.microsoft.com/webclient/ ）にサインインします。先ほど作成した接続用アカウント[email protected]を使用します。 ホストプールを選択します。リモートデスクトップ接続のローカルリソースアクセスを設定します。 接続中です。 ユーザー名とパスワードを入力します。 接続成功です！ WVDのポータルサイト経由の場合、ブラウザの中でリモートデスクトップを利用することが可能です。 以上が、Windows Virtual Desktopを最低限の評価ができるシンプルな構成を最短で作成する方法となります。いかがでしょうか？一番シンプルな構成とは言え、PowerShellでのみしか設定できない箇所や、それぞれの名前が意味している機能や役割の理解のしづらさ、難しさなど、正直なところまだまだブラッシュアップが必要と感じました。ですが、リモートワークの重要性が再認識されている昨今、小規模から大規模まで幅広いユーザー層に仮想デスクトップのサービスを提供できるzure純正のサービスは非常に魅力的です。シンプルかつ分かりやすく、管理や構築が可能となることを期待しています。Windows Virtual Desktop　は将来的にはハイブリッドクラウドには欠かせないサービスとなりそうです。

執行役員 VP of Engineering 兼技術部長の @hsbt です。週末に少しずつ進めていたゼノブレイド ディフィニティブ エディションをやっとクリアしました。今回は、6/24 に開催した GMO ペパボ EC テックカンファレンスの開催レポートをお届けします。 EC テックカンファレンスの開催について GMO インターネットグループが昨年より開催している GMO Developer Night のイベントの一つとして開催しました。GMO Developer Night は渋谷フクラスにて、継続的に開催予定でしたが COVID-19 の拡大の影響によりリアルイベントとしては中止になり、EC テックカンファレンスも当初は 3 月頃の開催予定が白紙となりました。 今回、GMO Developer Night がオンラインとして開催が再開したため、EC テックカンファレンスもオンラインバージョンとして開催しました。GMO ペパボの EC 事業部がサービス運営しているカラーミーショップでは、新たにリリースしたアプリストア、サービスの可用性の向上、2018 年の情報流出のインシデント以降に体制を改めたセキュリティ対策、デザインやカスタマーリレーションの体制など、毎日幅広く技術・デザインの領域への取り組みを行なっています。今回開催した EC テックカンファレンスではカラーミーショップの毎日の取り組みを紹介する場として、「普段やっていること・考えていること」を中心にコンテンツを用意しました。 発表内容の紹介 カンファレンスの様子は YouTube Live を録画したものが公開されていますが、このエントリではEC事業部チーフテクニカルリードの@kenchanが各セッションの内容を簡単に紹介します。 ポストコロナの商売を支える、カラーミーショップのアーキテクチャのこれから 発表資料: ポストコロナの商売を支えるカラーミーショップのアーキテクチャのこれから / The new architecture of COLORME SHOP in the Post-COVID-19 world - Speaker Deck 最初のセッションでは、私@kenchanがサーバサイドとインフラのアーキテクチャについて現在取り組んでいる課題を紹介しました。 昨今の状況においては、ネットショップの重要性が以前とは比べ物にならないほど高いものになっています。その状況においてもお客様に選ばれるシステムであり続けるためには、システム全体の可用性を今まで以上に向上させなければいけないと考えています。そのために、データベースの耐障害性・可用性の向上、サブシステム単位でのスケーラビリティの向上、そして特定の箇所で発生した障害を広く波及させないためのアーキテクチャの検討を進めています。 大量購入を支える決済トランザクション設計 発表資料: 大量購入を支える 決済トランザクション設計 / EC Payment Transaction Architecture - Speaker Deck 2 番目のセッションでは、EC 事業部テクニカルリードの@tsuchikazuが決済処理を設計するにあたり考慮すべきポイントと、カラーミーショップでの実装を紹介しました。 まず、決済処理のトランザクション設計をするにあたり必要な観点として、CAP 定理と BASE 特性という 2 つを提示しました。そして、それらを踏まえてカラーミーショップで実施している工夫として、トランザクションを細かく分離すること、補償トランザクション、データ突合の 3 つを紹介しました。 インターネット上でサービスを提供する際には、何らかの形で決済処理を設計、実装する必要があることから、Zoom 上での質問も、Twitter 上の反応も盛り上がっていました。 カラーミーショップカートの Angular 事情 発表資料: カラーミーショップカートの Angular 事情 / Angular circumstances of colorme-cart - Speaker Deck 3 番目のセッションは、@ku00_より、AngularJS から Angular へのバージョンアップの取り組みの発表でした。 カラーミーショップの新しいショッピングカートは AngularJS で実装されています。AngularJS はバージョン 2 から Angular をという名称になり、大きな変更が加えられました。今までは AngularJS のまま機能追加を行っていましたが、Angular のより便利な機能を使えなかったり、AngularJS の EOL が近づいてきたこともあり、チームでバージョンアップに取り組んでいます。定期的な勉強会を開くことでチームの技術力の向上を図りながら、Angular の機能を理解するために小さなアプリケーションを開発することで、移行後にもスムーズに機能開発ができるように工夫しています。 カラーミーのデザインについて 発表資料: GMOペパボ ECテックカンファレンス デザイナー登壇資料 - Speaker Deck 4 番目のセッションは、カラーミーショップのシニアデザイナーである@chocolatinaがカラーミーショップのそれぞれのチームにおけるデザイナーの取り組みを紹介しました。 カラーミーショップでは、ユーザーの登録から、そのユーザが私達のサービスを使いながら事業を成長させるところまで、トータルで支援できるようにチームを編成しています。その各フェーズにおいて、デザイナーに求められる役割はスキルは変わってきます。印刷物のビジュアルデザインから、プロダクトのUIデザイン、ユーザテストやインタビューまで、幅広い領域をデザイナーの皆さんがカバーしています。 カラーミーショップと ngx_mruby 2020 発表資料: カラーミーショップと ngx_mruby 2020 - Speaker Deck 休憩後、5 番目のセッションでは@yano3から、カラーミーショップにおける ngx_mruby の活用事例の紹介でした。 カラーミーショップアプリストアで提供されているカラーミーWPオプションは、ショップドメインと同じドメインで WordPress を公開することができます。この機能を実装するにあたり、より汎用的な仕組みとするためのルーティングの部分と、セキュリティ対策の 2 点において ngx_mruby を利用しています。 受注増でも変わらずショップ運営できる、利用者に寄り添い未来に備えるカラーミーショップについて 発表資料: 利用者に寄り添い未来に備えるカラーミーショップ - Speaker Deck 6 番目のセッションでは、サブマネージャの@nyanyamiが CRE チームの取り組みとその実績を紹介しました。 カラーミーショップの CRE(Customer Reliability Engineering)チームでは、ユーザーの課題解決のための技術的な調査や機能開発を行っています。CRE チームを結成しその目的を明確にしたことで、問い合わせ完了までの日数を大幅に改善しました。さらに、提供している機能の中でもよく使われている、重要な機能の改善に力をかけられるように、使われていない機能をユーザーの不利益にならないように工夫しながらクローズしています。 WAF を安全に導入するために取り組んだこと 発表資料: WAFを安全に導入するために取り組んだこと - Speaker Deck 7 番目のセッションでは、@takapi86がカラーミーショップにおける Web Application Firewall(以降 WAF)の導入プロセスを紹介しました。 既に動作しているウェブアプリケーションに対する WAF の導入は、誤検知を如何に減らすかがポイントになります。また、導入後の機能追加に追従して WAF のルールをメンテナンスしていくことも重要です。カラーミーショップへの導入時には、検知ログの収集の仕組みを構築し、除外ルールをコードで管理することで、これらの課題を解決しました。 デザインもドメインも違うサイト上でのプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 発表資料: デザインもドメインも違うサイト上のプレビュー機能をフロントエンドのみで実現したらユーザーもエンジニアもハッピーになった話 / How to preview on cross domain - Speaker Deck 最後のセッションは、@MITLicenseからのプレビュー機能の実装における工夫の紹介でした。 カラーミーショップアプリストアでは、ユーザーが閲覧する「アプリストア」と、開発者がアプリストアに表示する情報を登録する「ディベロッパーサイト」を別のアプリ、ドメインで運用しています。そのため、開発者がアプリストア上でどのように表示されるかを確認するために、ディベロッパーサイト上でプレビューを実装する必要がありました。この問題に対して、利便性とセキュリティの両面から検討を行い、window.postMessageと iframe を利用した方式で実装しました。 ZoomウェビナーでのQA 事前に登録してくださった方にはZoomウェビナーのURLをお送りしており、当日はQA機能を使って質問を受け付けていました。本記事の最後に、そこで寄せられた質問とその回答を紹介します。 また、ハッシュタグ#GMOdev で寄せられた質問にもいくつか答えておりますのでこちらもご覧ください。 Q1. 分離環境についてすでにコンテナ環境の導入が進められているということでしたが、クラスタの分離というのは kubernetes 上でのクラスタの分離ということでしょうか？ 現時点では、あくまでも論理的に分割しようというところまでで、技術的にそれをどうやって実現するかについては、まさに今検討しているところです。 Q2. 決済部分でAPIを使われるのですか。 購入ボタンを押して完了画面を表示するまでの間の決済トランザクションのタイミングで、決済代行会社へのリクエストをしています。 Q3. リトライが可能かつ、多重決済をおこさないために行っている具体的な工夫をぜひ知りたいです。いくつかチェックポイントを持った段階的なトランザクションのようですが、ロールバック不可能なタイミングなどはあるのでしょうか？また、リカバリーが困難な失敗したとき（ロックをロールバックすると危険な状態担った時）に、カスタマサポートへうまくエスカレーションする工夫はされていますか？ リトライが可能かつ、多重決済をおこさないために行っている具体的な工夫をぜひ知りたいです。 そのトランザクション用に、一意のIDを予め発行して、そのIDで決済APIを実行することにしています。仮に2度決済APIを実行したとしても、IDが重複してエラーになる。という形で、多重決済は防げています。 いくつかチェックポイントを持った段階的なトランザクションのようですが、ロールバック不可能なタイミングなどはあるのでしょうか？ いつでもロールバックは可能で、ある程度進んだら、もう戻らない。という形にしています。ロールバック不可能という意味だと、ロールバックのタイミングで障害が起きている場合があって、そのときはリトライでカバーという形です。 また、リカバリーが困難な失敗したとき（ロックをロールバックすると危険な状態担った時）に、カスタマサポートへうまくエスカレーションする工夫はされていますか？ リカバリに失敗した場合は、slackに全部流れるようになっていまして、大量に失敗した場合など異常事態が発生したら、弊社のエスカレのフローによって、CSへもエスカレーションするようになっています（エスカレもslack上で全部やっていきます） Q4. 「ユーザーの操作ログ」みたいなリプレイをするためのログはとられていますか？ 購入者の操作についてだと、APIへのアクセスログで操作の流れはわかる場合があります。しかし、操作を再現することを目的としたログは取得していません。ただし、社内向けの環境や、別途特定のブラウザに対してデバッグが必要な場合など、本番環境に影響を与えないように操作ログを取得する場合はあります。 Q5. そもそもAngularを採用した理由を聞きたいです。 カート開発当初にAngularJSを採用した理由について回答します。 プロジェクト開始当初（2014年10月頃）はBackbone.jsのような一世代前のライブラリか、その時の話題になっているAngularJSかの選択肢がありました。ReactやVue.jSはそもそも選択肢になかったので、カート画面の主な機能であるフォームのデータバインディングに最も適したフレームワークという点からAngularJSを選択しました。 Q6. iframeをつかったプレビューについて、iframe name + form target ではなく、postMessageをつかった理由はなにかありますか？また、Origin以外にトークン的なものをなげたりはしていますか？最後に、画像などは都度実際に保存していますか？それは保存時に正式な場所に移動したりしていますか？ iframeをつかったプレビューについて、iframe name + form target ではなく、postMessageをつかった理由はなにかありますか？ ご提案していただいた実装が候補に上がらなかった理由の一つとして、アプリストアは Vue.js (Nuxt) のアプリケーションなので、 form target による実装では POST のメッセージを受け取るために別途バックエンド側に何か用意するといった実装が必要になります。これはフロントエンドのみで実装が完結できる postMessage と比べると実装や再描画のコストが高くなってしまうため、もし候補に上がっていたとしても最終的には postMessage を選択することになったと思います。 Origin以外にトークン的なものをなげたりはしていますか？ 入力されている情報をサーバー側に送ることがなく、基本的に発表中にあった満たしたいセキュリティ要件は origin の検証のみで達成できることから、トークンなどの検証は特に行っていません。​ 画像などは都度実際に保存していますか？それは保存時に正式な場所に移動したりしていますか？ 保存を行っていない段階では画像ファイルは Data URI scheme を使ってやりとりをしており、ご指摘の通り申請情報を保存した時にサーバーへアップロードが行われます。 おわりに このエントリのはじめに、「普段やっていること・考えていること」をコンテンツとして集めたという話がありましたが、その狙い通りのカンファレンスとなったのではないかと考えています。カラーミーショップを日々開発・運用している人たちが、どのような課題に、どうやって取り組んでいるのかを感じ取っていただけたでしょうか。 また、もし皆さんの身近な課題解決に役に立つ発表があったようでしたら、適用してみた結果を私達にもフィードバックしていただけたらとても嬉しく思います。 オンラインでのイベントは今年からはじめた新たな取り組みのため、リアルイベントとは異なりイベント後に「この話の詳細ですが〜」と個別にお話をする機会がなく伝えきれない部分や、逆にオンラインだからこそわかりやすい面、例えばスライドが見やすい、などメリット・デメリットの両方があります。Zoom では QA やアンケートなどの機能があるため、これらを活用するなどして、視聴者との一体感をできるだけ醸成して行きたいと思います。 GMOペパボでは、新しい仲間を募集しています 募集中の職種や、詳しい社内の環境や制度に関しては以下をご覧ください。 GMOペパボ株式会社 採用サイト

4月に開催し好評だった、在宅ワークが楽しすぎてもはや会社に行きたくなくなってしまったエンジニア・デザイナーの話」の続編を開催いたしました。タイトルは直球で「続」在宅ワークが楽しすぎてもはや会社に行きたくなくなってしまったエンジニア・デザイナーの話と題し、全都道府県での緊急事態宣言解除が行われた直後となる５月27日に開催いたしました。イベント告知ページhttps://developers.gmo.jp/619/ セッションレポート 前回と同様に５分間のLTを各スピーカーから発表した後に質疑応答をそれぞれはさみ、最後は登壇者全員で視聴者からの質問に答える座談会形式でお届けしました。今回はフロントエンドやWebデザイン寄りのスピーカーが多いイベントとなりました。 オープニング風景 LT①「クリエイティブチームのリモート事情」　GMOインターネット　近岡 トップバッターは新卒４年のWebデザイナーがトーク。１月末から在宅勤務をスタートし、4ヶ月ほどフルリモートで働いているデザイナーチームのリモートワーク事情やその苦労、また新しい働き方による変化をデザイナーならではの視点で紹介してくれました。 LT②「在宅ワークでも活躍中！Adobe XD運用事例」　GMOインターネット　黒田 GMOインターネットでは2018年から各種プロダクトでのデザイン制作にAdobe XDを本格導入しています。FigmaやSketchなどのプロトタイピングツールも利用実績はありますが、メインツールとして使われているXDでの運用事例をはじめ、Tipsなどをトークしてくれました。 LT③「ペパボのバーチャルオフィスをclusterで作った話」　GMOペパボ　一瀬 VR空間で集まることができるバーチャルSNSの「cluster」で自社オフィスを作った話、そしてバーチャルオフィスが出来たことによって、リモートワークで働くメンバーたちにどのような行動変化が起きたのかLTを通して紹介いただきました。 本LTやバーチャルオフィスの体験方法については本人のブログ記事で紹介されています。ご興味ある方はぜひご一読ください。https://link.medium.com/1JYxHARPB7 LT④「長期在宅でもできるインプット方法とモチベーションの上げ方」　GMOインターネット　久我 長期のフルリモート生活を強いられる中で勉強会などのインプットを増やす機会が減ってしまう課題に対し、どのような工夫を行っているか、また結果としてモチベーション低下などの課題についての取り組みなどをクリエイティブチーム全体から集めたアンケートなど定量的な結果をレポートすることでデザイナーの「いま」を紹介するLTでした。 LT⑤「リモートワークと web 技術でグルーヴ感を作り出す最高の方法」　GMOペパボ　柳生 リモートワークを続ける中でも「ペパボらしさ」を醸成する一つのツールとして映像VJアプリをReactで開発した話でした。Reactと自社製作したビジュアルアセットのsvgを組み合わせ、ブラウザ上でキーボード操作にあわせ動画生成を行えるものです。 GMOペパボのアイコンであるペパポン（ https://pepabo.com/company/vision/ ）をモチーフにしたSVG素材をReact Context APIで映像、音声がミックスされ下記のようなが新しい映像が生まれていました。 運営裏話 今回のオンラインイベントでは実地開催の勉強会ではよく見かける「休憩」を入れたのですが、オンライン配信という特性を活かして、休憩時間中にCMを流しました。「まじめにベンチャー。まじめにギーク。」シリーズのCM動画を過去に３作品を制作していたのですが、今回のイベントで初公開のCMを配信公開したのが運営ウラ話の一つです。◆◆新WebCM 「"在宅でも"まじめにベンチャー。まじめにギーク。」◆◆https://www.youtube.com/watch?v=2EFXwt4Hodc 在宅新CM 内製クリエイティブをテーマにストーリー展開しています さいごに GMOインターネットグループでは5月25日にwithコロナ時代における「新しいビジネス様式 byGMO」を発表しました。これは在宅勤務を継続しながら出社勤務を再開、感染防止と経済・企業活動を両立することを目指すものです。具体的には以前から準備を進めていた在宅勤務・テレワークを恒常的なものとするテレワーク制度を稼働させ、最終的にグループ全体の40%が常時在宅勤務となることを見込んでいます。 [参考]：当社プレスリリースhttps://www.gmo.jp/news/article/6797/　 テレワークは推進されますが、変わらず開発者向けの有益な情報をお届けしてまいります。直近では今夜にGMOあおぞらネット銀行、そして来週7/2はアドテクをテーマにイベント開催いたします。 ------------------------------------------------------------------------◆GMO Developers Night #11：6/26(金)18:30～https://gmo.connpass.com/event/179944/ ◆GMO Developers Night #12：7/2(木)19:00～https://gmo-ap.connpass.com/event/179349/------------------------------------------------------------------------ 引き続きGMO Developers Nightにご期待ください。

「ハイブリッドクラウドへの道　～The road to hybrid cloud.～」今回は、オンプレミスとクラウドをVPN接続する方法を紹介します。オンプレミスとAzure上の仮想マシンが仮想ネットワークを介してセキュアな環境で直接通信できるようになります。 1：Azure VPNゲートウェイ 3つの構成 AzureのVPNゲートウェイを利用した接続構成には大きく３つの種類があります。 1－1.サイト間接続（S2S） オンプレミスとAzureを繋ぐ場合や、Azureと他のクラウドサービスを接続する場合の構成。オンプレミスと複数のAzureサイトを接続することも可能です。この場合はAzure側からオンプレミスにVPN接続を行います。 1－2.ポイント対サイト接続（P2S） 1台のPCとAzureをVPNで接続する構成です。この場合はPC側からAzureに対して接続を行います。リモートワークや、個人利用の環境から接続する場合に利用します。接続するPCは複数同時に接続が可能です。 1ー3.仮想ネットワーク間接続（VNet2VNet） Azure上の異なる地域（リージョン）間を接続する場合や、異なるサブスクリプション同士を接続する場合など、Azureの仮想ネットワーク同士を接続する構成です。VPNゲートウェイを利用しない「VNetピアリング」という接続方法もあります。 これらの接続構成は組み合わせて利用することも可能です。P2S接続と S2S接続は、同じVPN ゲートウェイを使って接続可能ですし、複数のサブネットを使い分けていくつかのVPNゲートウェイを配置することも可能です。※この他にも専用回線を利用した「ExpressRoute」接続という構成もありますが、今回は省略します。仮想ネットワーク ゲートウェイ作成時に、そのゲートウェイのSKU（Stock Keeping Unitの略）＝スペックを指定することになります。それぞれの接続構成やSKUにより、利用料金が異なり、構成ごとの時間単位の利用料金と、データの転送容量による従量課金の合計となります。 参考：Azure VPN Gateway について（ https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways ） 2：VPNゲートウェイ サイト間接続の作成 ◆全体構成とゴール実際にAzureとオンプレミスをVPNゲートウェイを使って接続する方法を紹介します。今回オンプレミス側はRRAS(Routing and Remote Access Service)をインストールした仮想マシンをゲートウェイとして、その配下に1台仮想マシンを接続しています。Azure上に仮想マシンを作成し、VPN接続で、オンプレミス側からAzure上の仮想マシンにローカルネットワークを介してリモートデスクトップ接続するところまでをゴールとします。 この構成ではRRASサーバーに固定のパブリックIPが必要となるため、VPNサービスなどを利用してオンプレミス環境を想定しています。社内ネットワークのゲートウェイに専用ルーターを配置している場合は、パブリックIPを保持しているルーター側にVPN接続機能（VPNホストサーバー）が必要となります。 ◆作成手順サイト間接続（S2S）の作成の手順は以下となります。1. [Azure] 仮想ネットワークを作成2. [Azure] 仮想ネットワークゲートウェイを作成 ＝ VPNゲートウェイの作成3. [Azure] ローカルネットワークゲートウェイを作成4. [オンプレミス]　RRASの構成5. [Azure]　接続の作成6. [オンプレミス]　Pingとリモートデスクトップで接続確認 2ー1.[Azure] 仮想ネットワークを作成 Azure上でのローカルネットワークとなる、仮想ネットワークを作成します。Azureポータルにログインし、「すべてのサービス」-「仮想ネットワーク」-「作成」を選択します。 仮想ネットワークが作成されました。 2ー2. [Azure] 仮想ネットワークゲートウェイを作成 ＝ VPNゲートウェイの作成 仮想ネットワークゲートウェイを作成します。こちらが今回のポイントとなるVPNゲートウェイとなります。「すべてのサービス」-「仮想ネットワークゲートウェイ」-「作成」を選択します。 先ほど作成した仮想ネットワークを指定します。※参照： https://docs.microsoft.com/ja-jp/azure/vpn-gateway/vpn-gateway-about-vpngateways 仮想ネットワークゲートウェイ ＝ VPNゲートウェイが作成されました。 2ー3. [Azure] ローカルネットワークゲートウェイを作成 オンプレミスへの接続情報となるローカルネットワークゲートウェイを作成します。 ローカルネットワークゲートウェイが作成されました。 2ー4. [オンプレミス]　RRASの構成 オンプレミスを想定して、VPSを利用して固定のパブリックIPアドレスを割り当てた仮想マシンにRRASをインストールします。RRASのVPNサーバーの機能を利用して、Azureから接続します。このサーバーがオンプレミス側のゲートウェイとなります。社内ネットワークの場合はパブリックIPを割り当てたルーターに該当しますので、ルーターでVPNホストサーバーの機能を有効にします。仮想マシンに「リモートアクセス」の役割をインストールします。 「DirectAccessおよびVPN(RAS)」を選択します。 役割がインストールされたら、サーバー名を右クリックし、「ルーティングとリモートアクセスの構成と有効化」を選択しウィザードを起動します。 「アドレス範囲の割り当て」では接続してきたVPNクライアント＝Azure VPN ゲートウェイ　に割り当てるIPアドレスの範囲を指定します。 Windows ServerでActive Directory ドメインを構成している場合など、DNSやDHCPの構成がすでにある場合は後でセットアップするを選択しておきます。 RADIUSサーバーを使用しないを選択します。 ウィザードが完了すると、RRASサーバーとしての機能が有効になります。Azureからの接続を受け入れるための設定を追加してゆきます。「ネットワークインターフェイス」を右クリックして、「新しいデマンドダイヤルインターフェイス」を選択します。 インターフェイスの名前を”fromAzure”とします。 「接続の種類」では「仮想プライベートネットワーク(VPN)を使って接続する」を選択します。 「VPNの種類」は「IKEｖ2」を選択します。 「接続先のアドレス」には、Azureで仮想ネットワークゲートウェイを作成したときに取得したパブリックアドレスを指定します。 「プロトコルとセキュリティ」では「このインターフェイス上のIPパケットの経路を選定する」を選択します。 リモートネットワークの静的ルートを追加します。Azureで仮想ネットワーク作成時に指定した、アドレス範囲を指定します。 リモートネットワークの静的ルートが追加されました。 「ダイヤルアウトのアカウント情報」は未入力でもOKです。 ウィザードでネットワークインターフェイスが作成されたら、プロパティーを開いてウィザードではできなかった項目を設定してゆきます。 「オプション」-「接続の種類」を「固定接続」とします。 「セキュリティ」-「認証に事前共有キーを使う」に任意のキー文字列を入力します。このキー文字列は後程Azure側にも設定することになります。 RRASの設定は以上となります 2ー5. [Azure]　接続の作成 Azureポータルに戻り、VPN接続のための設定を行います。作成した仮想ネットワークゲートウェイを選択し、「接続」をクリックします。 接続が作成されました。作成と同時にVPN接続を開始します。「状態」が接続済みとなっていれば成功です。 接続をクリックして詳細を表示しています。「状態」は接続済みとなっています。 RRAS側も接続状態が“接続”となっています。 2ー6. [オンプレミス]　Pingとリモートデスクトップで接続確認 実際に接続を確認するために、Azure上に仮想マシンを作成します。作成時のポイントとしては「仮想ネットワーク」にVPNゲートウェイ用に作成した仮想ネットワークを指定する部分となります。 オンプレミス側の仮想マシン（192.168.0.2）から、Azure上の仮想マシン（10.0.1.4）にリモートデスクトップ接続を行っています。Pingも双方問題なく通っているのが確認できました。 成功です！ オンプレミスとAzureがVPNで接続されました！ 以上、Azure VPNゲートウェイを利用したサイト間接続 with RRASの紹介です。 これで、オンプレミスとAzureが一つのネットワークで繋がることになるので、オンプレミスのActive DirectoryにAzure上の仮想マシンがドメイン参加、その反対の構成も可能となります。また、オンプレミスはそのままに、リモートワークの拠点としてAzureを利用したり、マルチクラウド構築など、VPNゲートウェイの利用方法は様々に広がります。VPNゲートウェイを利用することでハイブリッドクラウドはより簡単に構築することができるようになります。

「続」在宅ワークが楽しすぎてもはや会社に行きたくなくなってしまったエンジニア・デザイナーの話」にご参加いただいた皆さま、ありがとうございました！（イベント告知ページ： https://gmo.connpass.com/event/175752/ ）おかげさまでzoomウェビナー、YouTube合わせて約400名超の方々にご覧いただきました。今回はZoomウェビナーのライブ配信にて行いましたアンケート結果を大公開いたします！気になっていたけど、あまり知らないみんなの在宅事情や自粛期間中の過ごし方について伺いました。 Ｑ1：5月27日時点、在宅ワークをしていますか？ 74％の参加者のみなさまが「在宅勤務をしている」という結果！4月2日に実施した在宅企画の第1弾( https://gmo.connpass.com/event/170561/ )で同じ質問をした際に「在宅勤務をしている」と回答した割合は89％でしたのでややパーセンテージとしては下がっているようでした。ちょうど実施週の月曜日、5月25日(月)に緊急事態宣言が解除になりました。世の中の動きも少し動きがあったタイミングであったということも関係しているかもしれませんが、それでもまだ在宅ワークをしている方が多くいらっしゃったということがわかりました。当社も、緊急事態宣言解除に伴い今後の働き方の方針が決定いたしました。プレスリリース： https://www.gmo.jp/news/article/6797/在宅継続の方も、出勤される方も引き続き感染予防に努めながらがんばりましょう！ 5月27日時点在宅勤務実施状況 Ｑ2：在宅ワークになり快適に過ごすための備品やアイテムを購入しましたか？ 結果は、在宅ワークを機に約7割を超える方が何かしらのアイテムを購入したという結果に・・！ デブレルチームの中には作業環境をこんな感じに整えているチームメンバーもおりますよ～！日に日にグレードアップしているそうです。 デブレルメンバーの作業デスク Ｑ3：具体的に購入したものは何ですか？ 意外と多かったのは、デスクor椅子！！何かしらを購入したと回答した方のうち、約4割の方がデスクもしくは椅子を購入されているという結果に！！ 合わない高さのデスクやダイニングチェアでの長時間の作業は腰痛・肩こりが悪化しますからね・・・とても大事ですね！！！ 業務関連以外のアイテムでは、今夏に向けてエアコンの効きをよくするためにサーキュレーターを購入したというトークも出ていました！ 一日の大半を過ごす環境なので、ある程度快適に過ごすためのアイテムや備品への投資はみなさんされているようですね！！ Ｑ4：オンライン飲み会を実施したことがありますか？ 結果は・・・7割オンライン飲み会経験あり！かなり多くの方がオンライン飲み会実施されていますね。 登壇者同士のトークの中では、オンライン飲みの頻度の話も出ていました。2週に1回程度、毎週やっているなど頻度はそれぞれでしたが、1日に3コミュニティのはしごするという人も！ Ｑ5：平均コミュニケーションの時間はどのくらいですか？ 最多は1～2時間という結果でしたが、並んで3～4時間も多かったですね！10％以下ですが、5時間以上という人も中にはいらっしゃいました！共通して抜け時が難しい・・・というのは総意なようでした。「終電がない」という代わりに「充電がない」という抜け文句を使ってるよ～という情報交換もありましたよ！笑安心してコミュニケーションを取ることができるようになるまではもう少し時間がかかりそうなのでもうしばらくオンラインでうまく交流を図っていけるといいですね！！ Q6：自粛期間中の余暇の楽しみはありますか？ 9割以上、ほとんどの参加者の方が何かしらの余暇の楽しみがあるという結果に！ Ｑ7：余暇の楽しみを具体的に教えてください！ 映画動画鑑賞やゲーム/漫画などに次いで、エンジニアの方の参加も多かったこともあり「自主開発」に投票いただいた方も多くいらっしゃいました！自粛生活も好きなこと・楽しいことを見つけながらみなさん過ごされていたようでした！！ さいごに 実は知りたい！みんなの在宅事情アンケート結果、いかがでしたでしょうか？きっとみんなも同じだろうな・・・と思いつつ、なかなか踏み込んで聞く機会のない内容をみなさんとシェアできてとても楽しいイベントとなりました！！ご参加いただきアンケートにご協力いただきましたみなさま、ありがとうございました。 緊急事態宣言は解除になりましたが、まだまだ予断を許さない状況が続いておりますね。GMO Developers Nightはしばらくオンラインでの開催を予定しております。 引き続きGMOインターネットグループをどうぞよろしくお願いいたします。

GMO Developers Night #05「みなさんの在宅ワーク」アンケート結果報告イベント開催レポート(https://developers.gmo.jp/2846/)については別途公開させていただきましたが、今回やイベント中に行われたアマギフチャレンジ企画の投票結果をご紹介したいと思います。テーマは、zoomウェビナーからご参加いただいた皆さまにご回答いただいた、在宅ワークに関するアンケート「みなさんの在宅ワーク」です。 在宅ワークしていますか？ 「在宅ワークしている」方が８９%とかなり高い数値となりました。今回イベントにご参加いただいた皆さまの属性を見てみると、６割の方がエンジニアということでしたので、この点は在宅ワーク率が高くなっていた要因だったかもしれませんね。当社はコロナウイルスの感染を避けるため、１月２７日から在宅ワークに入りました（プレスリリース：https://www.gmo.jp/news/article/6641/ ）が、他社さんでも在宅ワークが導入される企業も増えてきているようです。 在宅ワーク実施率 在宅ワークをする前と後のイメージ 「在宅ワークをする前（BEFORE）」は良いイメージが８８%、悪いイメージが１２%だったのに対し、「在宅ワークをする後（AFTER）」は良いイメージが８２%、悪いイメージが１８%と、圧倒的に良いイメージの方が多いですが、在宅ワークをする前と後で回答いただいた方のうち２割弱の方がイメージに変化があったようです。 当社は在宅１１週目をむかえ、私も始めた当初はストレスもありましたが、パートナー（社員）同士で協力し働きやすい環境を作る工夫をしたこともあり、今はだいぶ慣れて改善されてきました。今回のGMO Developers Nightで登壇者がお話ししたものが皆さまの参考になると嬉しいです。 ※在宅ワークをすでにしている方の回答のみ抽出して統計を出しています。 在宅ワークとオフィスどちらが集中できる？ ６割の方が「在宅の方が集中できる」と回答しました。私も仕事をする中で一人で作業するものは誰にも声をかけられずに作業できて集中できるなと感じています。その分、”自分でしっかりマインドコントロールしないとだらけてしまい集中できない”　”通勤時間や移動がない分切り替えにくい”　”作業環境が整っていない事によるストレス”という点で、オフィスの方が集中できる方もいらっしゃったのかなと思いました。 ※在宅ワークをすでにしている方の回答のみ抽出して統計を出しています。 プライベートの変化 「運動不足になった」という回答が一番多い結果となりました。先日、緊急事態宣言も発令されて外への外出が減ったことや、スポーツジムへ行くことを避けていらっしゃる方も多いのかなと思います。また、在宅ワークになったことで通勤の移動もなくなり、ミーティングのために会議室へ移動する・・というちょっとした運動もなくなったりなどが要因のようです。 その他にも、通勤時間がなくなった分「自由時間が増えた」「睡眠時間が増えた」という方が６割前後でした。ひとつ前の質問では「在宅ワークの方が集中できる」と答えた方が６割でしたが、プライベートに関する問いでは意外にも「残業時間が減った」と答えた方は３割でした。在宅ワークになったことで業務が増えたり、帰宅するという行動がない分、仕事をしていらっしゃる方や前と勤務時間が特に変わらないという方もいるのかもしれませんね。「浪費が減った」と答えた方も３割でした。外に出て消費するという機会は減ってしまったかもしれませんが、Amazonなどネットショップのセールでついつい買ってしまった、家での生活を充実させるためにもおうちグッズを買った、という方も多いのではないでしょうか。 ※在宅ワークをすでにしている方の回答のみ抽出して統計を出しています。 さいごに アンケートにご協力いただいた皆さま、どうもありがとうございました。新型コロナウイルス感染症の1日も早い収束と、皆さまの在宅ワークがより充実されることを心より願っております。引き続きGMO Developers Nightをよろしくお願いします。またのご参加お待ちしております！

昨今の状況を鑑み、WFH（Work from Home）でアウトプットしていくためのナレッジ共有の場を提供できないかと皆で話し合い、オンラインでのイベント開催を決定しました。4/2(木)に行った「GMO Developers Night Online　在宅ワークが楽しすぎてもはや会社に行きたくなくなってしまったエンジニア・デザイナーの話」のイベントをレポートします！イベント告知ページhttps://gmo.connpass.com/event/170561当日のTwieetrハッシュタグ #GMOdevhttps://twitter.com/hashtag/GMOdev はじめに GMOインターネットグループでは2020年1月26日（日）から新型コロナウイルスの感染拡大に備え在宅勤務体制へ移行を発表し、今日まで活動を行っております。 ■参考[プレスリリース] https://www.gmo.jp/news/article/6641[ブログ] https://www.kumagai.com/?eid=8260※GMOインターネットグループ代表 熊谷のブログ「4000人を在宅勤務にした判断について」 ローソンさん協賛ありがとうございました 今回のイベントではローソンさんに協賛いただき、参加者の皆様にLチキクーポンを事前配布。当日は #おうち飲み会 のハッシュタグでSNS上でも盛り上がりました。ローソンさんありがとうございました！ トークセッション ５分間のLT（LightningTalk）を5人のスピーカーから発表した後に質疑応答をそれぞれはさみ、最後は登壇者全員で視聴者からの質問に答える座談会形式で行いました。 【LT①】在宅ワーク開始から今日までを開発者視点でご紹介本イベントの導入編として当社グループが実施している新型コロナウイルス対策 （ https://www.gmo.jp/coronavirus/ ） の裏側の一部や導入している技術情報についてご紹介をしました。ちなみにスピーカーである私の背景はZoomのバーチャル背景機能で、当社の社内風景を背景にしています。 GMOインターネット　稲守 【LT②】リモートあるある言いたい GMOメディアのデザイナー達を対象にリモートワークでの気づきを集計し発表いただきました。２ヶ月超のリモートワークでのコミュニケーション課題をどう解決していくかなど意見が出ました。 GMOメディア　 出井 【LT③】在宅ワークを技術で楽しみ、毎晩テラスハウスを見て、毎週キャンプへ行くたった一つの方法 全員がリモートワークになり、VPNサーバの負荷が増えるなかスムーズに在宅にシフトできました。どのように課題解決していたのかをご紹介。詳しくは下記ブログを参照ください。https://ten-snapon.com/archives/2306 GMOペパボ　山下 【LT④】インフラチームの在宅ワークな日々 GMOメディアインフラチームの在宅ワークにおける全社向け対応と、より良いリモート環境を目指したチーム内での取り組みをLT。リモートにおいても工夫次第で出社時とかわらない効率ができると提案いただきました。 GMOメディア　渡部 【LT⑤】在宅勤務開始から2ヶ月でやったこと ゼロトラストネットワークの概略から始まり、ペパボにおいてその考え方に基づき如何にやってきたのかと紹介。「セキュリティを高める方が生産効率は上がる」は至言だったかと思います。 GMOペパボ　柴田 【座談会セッション】 成瀬、柴田、渡部、山下、出井、稲守 座談会トークの中では様々な質問を参加の皆さんからいただき、時間内に答えられなかった設問もありました。いくつかこちらのブログで回答させていただきます。 Q. 社内でのライトなコミュニケーションが意外と重要だということに気づき、在宅ワークではその小さいけど大事なコミュニケーションを今後どのようにとっていきますか？A. 自由参加型のオンラインランチや飲み会、朝活会（ラジオ体操が毎朝流れるチャネルがある）などがあったります。 Q. コロナ騒動が終息したら、各社の在宅制度がどうなるのか（そのまま定着するのか、元に戻るのか）気になります。A. 以前からリモートワークを月２くらいで行っていました。まだ今後のことなので明言は出来ませんがリモートワークは増えていくと考えています。 Q. スクラムのツールは何使ってますか？A. （出井）AtlassianのJira　　（稲守）PJによってTrelloやAsana、MSのPlannerなども利用したり、試した　　　　　　　　りしています。 Q. 外付モニター利用していますか？A. 登壇者のほとんどが利用しています。LTでの中でご紹介したデスク環境は下記です。 さいごに 蛇足ですが視聴者数は12月に開催したGMO Developers Nightを余裕で超える人数となり驚きました。GMO Developers Night 開催レポートhttps://hoscon.gmo.jp/blog/2483/新型コロナウイルス感染症の1日も早い収束を心より願っております。リアルで会うことは難しいですが、我々には解決の手段を生み出していく知恵やノウハウ、そして技術があります。Keep Distanceを意識しながら今後も「まじめにベンチャー、まじめにギーク」をお届けしていきたいと考えています。引き続きGMO Developers Nightにご期待ください。

「ハイブリッドクラウドへの道 ～The road to hybrid cloud.～ Vol.4」では、ハイブリッドクラウドで重要なポイントとなるオンプレミスとAzureとのアカウント同期です。元々利用しているオンプレミスのアカウントを自動的にAzure Active Directory（AAD）と同期できる「Azure AD Connect」というツールが提供されています。AADとアカウントの同期ができれば、その情報を利用してAzure Active Directory Domain Service（AADDS）ともアカウント情報を共有して利用可能となります。今回はこのAzure AD Connectを使って実際にアカウントを同期する方法を解説します。 Azure AD Connect利用の事前準備と注意事項①　ドメイン名 Azure AD Connectを利用して、オンプレミスとAADのアカウント同期を行う前に、事前準備や利用環境の構成で注意すべき点があります。 ハイブリッドクラウドを目指すのであれば、オンプレミスの資格情報を利用して、そのままOffice365やAzureの各種サービスを利用（シングルサインオン）できることが望ましいです。各種サービスを利用するごとに、わざわざサインインし直したり、複数のアカウントやパスワードを管理するのでは作業効率が悪くなります。 オンプレミスでは特に制限なくドメイン名を決めることができました。例えば、“ad.local”などです。オンプレミスの運用上はこれで問題はなかったのですが、AADを利用する場合、インターネットを介してクラウド上のサービスにログインするために、ドメイン名にはインターネット上で有効なドメイン名（.net .com .co.jp など）であることが必要となります。 もし、新規にこれからオンプレミスのActive Directoryを構築して、AADとアカウントの同期をするのであれば、DNS参照が可能なドメイン名にするべきです。すでにオンプレミスを運用していて、ドメイン名がインターネット上で有効でない名前の場合（DNS参照できない場合）は、以下のいずれかの設定を行う必要があります。 1.VPN Gateway接続の作成Azure上の仮想マシンをオンプレミスと同様のドメイン名でActive Directoryに参加させて管理するのであれば、VPN Gateway 接続をAzure上に作成し、オンプレミスから直接Azure上の仮想ネットワークに接続できるようにします。この場合は、オンプレミスのプライベートネットワークの延長としてAzureの仮想マシンもドメイン参加し、管理が可能となります。一方、Azureの各種サービスをシングルサインオンで利用する場合には利用が制限されることになります。（VPN Gateway接続の作成方法については次回以降解説予定） 2.ユーザープリンシパル名の変更ユーザープリンシパル名（UPN）はActive Directory上でアカウントを認識するための名前付けルールです。オンプレミスのActive Directoryでは”[email protected]”のように表記されます。AADでは”.local”などインターネット上で参照できないドメイン名は推奨されておらず、実際Azure AD Connectを利用する場合に、”.local”のようなドメイン名ではアカウントの同期ができません。オンプレミスで“ad.local”というドメイン名をすでに利用している場合は、ドメイン名を変更するか、代わりのUPNサフィックスを追加して、インターネットで参照できるドメイン名を指定することになります。 ドメイン名の変更はActive Directoryではサポートされているものの、すでに運用しているオンプレミス環境で実施するには失敗した場合のリスクが高いため（ログインができなくなるなど）お勧めしません。UPNの変更方法として、代わりのUPNサフィックスの追加方法を紹介します。 オンプレミス環境で、ドメインコントローラーのスタートメニューから「Active Directory ドメインと信頼関係」を起動します。左メニューから「Active Directory ドメインと信頼関係」を右クリックして「プロパティー」を選択します。 「UPNサフィックス」で「代わりのUPNサフィックス」にAADで利用するのと同じドメイン名（後で設定）を指定します。このドメイン名はインターネット上で有効なドメイン名（DNS参照可能）を指定します。 代わりのUPNサフィックスを追加した場合、今回の例のようにこれまで”[email protected]”でログインしていたユーザーは、”[email protected]”というUPNでログインすることになります。Azure AD Connectでアカウントの同期後は、”[email protected]”でオンプレミスのPCにログインして、そのままシングルサインオンで各種クラウドサービスを利用できるようになります。 新しいUPNサフィックスの指定方法は以下の通りです。 ドメインコントローラーのスタートメニューから「Active Directoryユーザーとコンピューター」を起動します。ユーザーを新しく作成する場合は、ユーザーログイン名で追加したサフィックスが選択できるようになっています。 既存ユーザーの場合はユーザーのプロパティーで「アカウント」-「ユーザーログオン名」で追加したサフィックスが選択できるようになっています。 3.Azure Active Directoryのユーザー名にメールアドレスを利用するオンプレミスのActive Directoryユーザーのプロパティーにメールアドレスが指定されていれば、Azure AD ConnectでADDとのアカウントの同期時にメールアドレスをアカウント名として利用することが可能です。システムの都合上、オンプレミス上でUPNサフィックスを変更できない場合や、UNPサフィックス変更作業を避けたい場合などはこちらをお勧めします。 後ほど紹介しますが、Azure AD Connectではアカウント名としてメールアドレスを指定することができます。 Azure AD Connect利用の事前準備と注意事項②　グローバル管理者の設定 Azure AD Connectの設定はウィザード形式で進めていきます。その中で、ADDに対してアカウントを追加したり、各種設定を行うために、AADの最高権限であるグローバル管理者のロールを持ったアカウントを指定する必要があります。事前に特定のアカウントにグローバル管理者のロールを割り当てておきましょう。 Azureポータルにログインして、アカウントを新しく作成するか、既存のアカウントを選択します。 ユーザーの「割り当てられたロール」を選択します。「割り当ての追加」を選択し、ロールの一覧から「グローバル管理者」を追加しておきます。 Azure AD Connect利用の事前準備と注意事項③　カスタムドメイン名の追加 AADに任意のドメインでログインできるように、ドメイン名を登録しておきます。このドメイン名はインターネットで参照できるドメインで、DNS参照できるものが必要です。お名前.comなどでドメインを取得しておきましょう。 カスタムドメインをAzureに登録します。Azureポータルにログインして「Azure Active Directory」-「カスタムドメイン名」を選択します。「カスタムドメインの追加」をクリックして追加します。 “未確認”となっているドメイン名をクリックするとDNSに登録する情報が表示されます。 AADで利用できるようにDNSにTXTレコードを登録します。Windows ServerのDNSサーバーを利用する場合にはこのようになります。 カスタムドメインが“確認済み”となっていれば、DNSの参照ができるようになっています。 Azure AD Connect利用の事前準備と注意事項④　同期についての注意点 Azure AD Connectはオンプレミスのアカウント情報をAADと同期することができるツールです。初回は既存アカウントとパスワードの同期を行います。以後は、既定では30分間隔でアカウント情報の変更をAADに反映します。 注意すべき点として、Azure AD Connectによる同期は常にオンプレミス→AADへの一方通行の同期となることです。Azure AD Connectを利用してハイブリッドクラウド環境を維持するためには、パスワードの変更やユーザーアカウントの追加削除などを常にオンプレミス側から行う必要があります。また、不用意にテストアカウントなどをオンプレミス側で作成利用していると、意図せずAADにも同期されてしまうので注意が必要です。 Azure AD Connectでアカウント情報を同期①　Azure AD Connectのダウンロード 事前準備が完了したところで、Azure AD Connectを使ってアカウントの同期までを紹介します。 まずはAzure AD Connectをダウンロードしましょう。Azureポータルにログインして、「Azure Active Directory」-「Azure AD Connect」を選択します。「Azure AD Connectのダウンロード」のリンクがあるのでクリックしてダウンロードを実行します。 ダウンロードしたファイルを実行してインストールウィザードを起動します。ライセンス条項にチェックを入れて続行します。 Azure AD Connectでアカウント情報を同期②　「簡単設定」を使ったAzure AD Connectのインストール 事前準備でオンプレミスのUPNを変更して同期を行う場合は、このまま「簡単設定を使う」を選択します。 AADのアカウント名をメールアドレスとする場合は、「カスタマイズ」を選択します。まずは、簡単設定のウィザードから紹介します。 事前準備で設定したAADのグローバル管理者のアカウント情報を入力します。 オンプレミスのドメイン管理者の情報を入力します。 事前準備で代わりのUPNサフィックスを登録して、DNSのTXTレコードが完了していれば、確認済みのドメインとして表示されます。元々オンプレミスで使っていたドメイン名は検証済みとはなりませんが、問題ありません。“一部のUPNサフィックスが確認済みドメインに一致していなくても続行する”にチェックを入れて次に進みます。 以上の設定でインストールを実行します。 インストールが完了するとすぐに同期処理が実行されます。 Azure AD Connectでアカウント情報を同期③　「カスタマイズ」を使ったAzure AD Connectのインストール 事前準備でAADのアカウント名をメールアドレスとした場合は、Azure AD Connectのインストールでカスタマイズを選択します。 既定の設定でそのまま進みます。 「パスワードハッシュの同期」を選択します。 事前準備で設定したAADのグローバル管理者のアカウント情報を入力します。 オンプレミスのドメイン管理者の情報を指定します。「ディレクトリの追加」をクリックします。 「既存のADアカウントを使用」を選択してもうまくいかないため、「新しいADアカウントを作成」を選択して、既存のドメイン管理者情報を入力すると次に進めます。 このような表示になればオンプレミスのディレクトリ接続は成功です。 ここがポイントとなります。「Azure ADユーザー名として使用するオンプレミスの属性を選択」で“mail”を選択します。事前準備で同期するアカウントのメール情報が入力されていれば、アカウント名としてAADに作成されます。“一部のUPNサフィックスが確認済みドメインに一致していなくても続行する”にチェックを入れて次に進みます。 いくつかウィザード画面がありますが、解説不要な部分は省略します。インストールが完了するとすぐに同期処理が実行されます。 Azure AD Connectでアカウント情報を同期④　Azure AD Connectの同期確認 しばらく時間をおいてAzureポータルで確認すると、同期処理が完了したことが分かります。 オンプレミスで作成したユーザーがこちらです。 Azureポータルでユーザーを確認すると、アカウントが同期されているのが確認できました。 以上がAzure AD Connectを使ったオンプレミスとAzure Active Directory とのアカウント同期方法の紹介です。アカウントの同期が完了すれば、オンプレミスのユーザーはそのままAADのユーザーとして認証されるので、Office365やAzureの各種サービスをそのまま利用することができるようになります。ハイブリッドクラウドを目指す上で重要ポイントとなる部分です。ようやく、ハイブリッドクラウドへの第一歩が踏み出せたというところでしょうか。次回以降も引き続き、ハイブリッドクラウドへの道を進むべく色々と紹介していきます。

「ハイブリッドクラウドへの道 ～The road to hybrid cloud.～ Vol.3」では、ハイブリッドクラウドの実現方法の1つとして、Azure上にオンプレミスと同様にActive Directoryを構築してみます。オンプレミスと同様にAzure上に仮想マシンを作成し、ドメインコントローラーとしてActive Directoryを構築することは可能ですが、目指すはハイブリッドクラウドです。今回はAzureのクラウドサービスの1つ、「Azure Active Directory Domain Services（AADDS）」を利用した構築方法を紹介します。AADDSはWindows Server Active Directory（WSAD）と完全な互換性があり、マネージドドメインサービス（ドメイン参加、グループポリシー、LDAP、Kerberos認証、NTLM認証など）が提供されます。AADDSを利用することで、ドメインコントローラーとしての仮想マシンの管理やリソースの確保など運用コストの削減が期待できます。 Azure Active Directory Domain Servicesの作成 Azureポータルにログインします。「リソースの作成」から「ID」-「Azure Active Directory Domain Services」の作成を選択します。 基本情報を入力します。「DNSドメイン名」はActive Directory内だけで利用する名前ですが、できれば取得済みドメインのサブドメインが好ましいようです。”.local”は推奨されていません。 この情報で確定してドメインを作成します。 再度確認。 作成完了までしばらく待たされます。 Azure Active Directory Domain Servicesの作成 Azureポータルにログインします。「リソースの作成」から「ID」-「Azure Active Directory Domain Services」の作成を選択します。 基本情報を入力します。「DNSドメイン名」はActive Directory内だけで利用する名前ですが、できれば取得済みドメインのサブドメインが好ましいようです。”.local”は推奨されていません。 この情報で確定してドメインを作成します。 再度確認。 作成完了までしばらく待たされます。 30分ほどでようやくデプロイ完了です。「リソースに移動」から作成されたドメインを見てみましょう。 「マネージドドメインをプロビジョニング中です」とあります。AADDSのデプロイは完了しているようですが、まだドメインの作成が完了していないようです。 さらに待ちます。 実行中となったらすべて完了です。続いて「仮想ネットワークのDNSサーバー設定の更新」を行うため「構成」ボタンをクリックします。 AADDSのDNSサーバーが構成されました。 その他「必要な構成手順」として「Azure AD Domain Services パスワード ハッシュ同期の有効化」という項目があります。AADDSではユーザー管理はAzure Active Directory（AAD）のユーザー情報を参照しています。AADDSではNTLM認証とKerberos認証によってユーザーを認証しているので、AADのユーザーがAADDSを利用する場合は、これの認証に適した形式にパスワードをハッシュする必要があります。 AADでユーザーを新規に作成した場合は、AADDSのリソースを利用する時に一度パスワード変更を行うことで、パスワードがハッシュされます。オンプレミスのActive Directoryとアカウントの同期を行う場合にはAzure AD Connectを利用してパスワードハッシュが同期されます。 仮想ネットワーク　サブネットワークの追加 次に、仮想ネットワークのサブネットを追加します。AADDSでドメインを構築すると仮想ネットワークが自動的に作成され1つのサブネットが割り当てられますが、Azure上の仮想マシンがドメインに参加するための仮想ネットワークは、これとは別のサブネットの範囲を作成して利用することが推奨されています。 左メニューより「プロパティ」を選択し「仮想ネットワーク/サブネットで使用可能　aadds-vnet/aadds-subnet」を選択します。 左メニューから「アドレス空間」を選択します。新しいアドレス空間（IPアドレスの範囲）を追加して「保存」をクリックします。 左メニューから「サブネット」を選択します。右メニューのサブネットの追加情報を入力します。今回名前を“domain-subnet”として、「アドレス範囲」には先ほど作成したアドレス空間”10.0.1.0/24”を指定します。 「OK」ボタンをクリックして作成します。 ドメイン参加用のサブネットが作成されました。 Azure上の仮想マシンでAzure Active Directory Domain Servicesのドメインに参加する AADDSの構築が完了したので、さっそく仮想マシンを作成してドメインに参加してみましょう。Azure上で仮想マシンを作成します。ここで注意すべきは、AADDSの仮想ネットワークの地域と、仮想マシンの地域を同じにしておくことです。同じ地域であれば仮想ネットワーク内でそのまま通信が可能なので、ドメイン参加が簡単にできるようになります。 AADDSと同じ地域を指定する 仮想マシンの作成する地域と、AADDSの地域が同じであれば、サブネットに先ほど作成したドメイン参加用のサブネットが選択できます。こちらを選択します。 仮想マシン作成後、IP情報を確認してみると、作成したサブネットの10.0.1.4のIPアドレスが割り当てられているのが確認できます。 次に、ドメイン参加をするためのアカウントを作成します。AADDSはAADのユーザーを参照しているので、Azureポータルから「ID」-「ユーザー」-「新しいユーザー」を選択します。今回は“domainadmin”という名前のユーザーを作成しました。 次に、グループを割り当てます。作成したユーザーを指定して「グループ」を選択します。 「メンバーシップの追加」から“AAS DC Administrator”を選択します。AADDSでは“Domain Admins”というグループの代わりにこちらが管理者グループとなります。 ここまでで、AADにユーザーが追加されたことになります。 先ほども述べたように、AADのユーザーがAADDSのドメインを利用する場合は、パスワードのハッシュを行う必要があります。これはパスワードをリセットすることで実行されますので、一度パスワードのリセットを実行しておきます。リセットを実行すると一時パスワードが発行されるので、一度このパスワードを使ってAzureポータルにログインしておきます。 一時パスワードを使ってAzureポータルにログインしてパスワードの更新を行います。これでパスワードのハッシュが完了します。 先ほど作成した仮想マシンでAADDSのドメインに参加します。Azureで作成した仮想マシンは英語版となっているので、日本語化（後日紹介予定）をしておきます。 先ほど作成した仮想マシンでAADDSのドメインに参加します。Azureで作成した仮想マシンは英語版となっているので、日本語化（後日紹介予定）をしておきます。 AADDSのドメインに参加できました！一度再起動しておきます。 リモートデスクトップ接続をするには 仮想マシンにローカルアカウントでログイン（リモートデスクトップ接続）してユーザー情報を見てみると、Administratorsグループに“AD\AAD DC Administrators”と“AD\Domain Admins”というグループが追加されています。 作成したユーザーでリモートデスクトップ接続を行う場合は、これらのグループが追加されていても、ローカルのAdministrators（もしくはRemote Desktop Users）にユーザーを登録する必要があります。AADDS上で管理者グループの“AAD DC Administrators”グループに入っているユーザーであっても、仮想マシンのローカルAdministratorsグループに登録する必要があります。 仮想マシンのローカルAdministratorsにユーザーを登録したら、リモートデスクトップ接続をしてみましょう。接続時のユーザー名は“ドメイン名\ユーザー名”となります。 AADDSのアカウントでリモートデスクトップ接続をしてユーザー情報を確認できました。 ここまでできればオンプレミスのActive Directoryのドメインと同様に、Azure上のユーザー管理やPC管理を行うことが可能です。 Azure Active Directory Domain Services 利用料金 最後にAzure Active Directory Domain Services の利用料金です。 いくつかプランがありますが、最小の同時認証3,000、認証オブジェクト最大25,000までのStandardプランで16.8円／時間となっています。 以上がAzure Active Directory Domain Services の基本操作です。オンプレミスと同様Active DirectoryがAzureのサービスを利用することでも構築可能なことが理解できたと思います。 Azure側の準備がとりあえず整ったところで、次回はオンプレミスとAzure上のアカウント同期について紹介します。