コラム

CTC教育サービス・ホーム　＞　コラム　＞　グーグルのクラウドを支えるテクノロジー　＞　第63回　仮想デスクトップシステムのGCP移行プロジェクト（パート2）

グーグルのクラウドを支えるテクノロジー

CTC 教育サービス

[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes

第63回　仮想デスクトップシステムのGCP移行プロジェクト（パート2） (中井悦司) 2019年7月

はじめに

　前回に引き続き、2019年に公開されたエッセイ「From Corp to Cloud: Google's Virtual Desktops」を元にして、Google社内の仮想デスクトップ移行プロジェクトを紹介します。今回は、仮想デスクトップ環境の要件や移行プロセスなど、具体的なプロジェクトの内容について説明します。

仮想デスクトップシステムの要件

　このプロジェクトでは、仮想デスクトップシステムの設計にあたり、次の4つを主要な要件として定義しました。

(1) 社内ネットワーク上にある物理ワークステーションと同じ方法で、開発環境などにアクセスできる。
(2) 仮想デスクトップ用のインスタンスは、既存のインベントリー管理システムで管理される。
(3) ログイン認証、パッケージアップデート、操作ログ管理などのセキュリティ機構を実装。
(4) 規定の範囲内において、ユーザーの指定する構成で仮想デスクトップを作成可能。

　(1)については、前回の記事で説明したように、「BeyondCorp」の認証システムを利用します。そして、(2)〜(4)の要件を満たすために、仮想デスクトップの利用者は、GCPのコンソールから直接に仮想マシンインスタンスを起動するのではなく、専用のポータルシステムから仮想デスクトップ環境をリクエストするという仕組みを採用しました。ユーザーが必要な項目を入力してリクエストを登録すると、仮想マシンインスタンスの作成やインベントリーへの登録など、一連の作業がワークフローとして実施されます。
　仮想マシンインスタンスで使用するOSは、Debianをカスタマイズした独自のLinuxが社内標準として使用されています。これは、物理ワークステーションと共通のもので、(2)(3)に必要となる、パッケージの自動アップデートやログ管理などの仕組みがあらかじめ実装されています。冒頭のエッセイによると、GCP上で利用するにあたって変更が必要になったのは、社内ネットワークにアクセスするためのDNS設定だけだったそうです。

20,000ユーザーの移行作業

　このプロジェクトでは、約20,000ユーザー分の仮想デスクトップ環境を移行する必要がありましたが、想定外のトラブルの発生を低減するため、Alpha、Beta、GAの3つのフェーズに分けて移行を進めました。Alphaでは約100ユーザー、Betaでは約1,000ユーザーの移行を試験的に行い、まずは、どのような問題が発生するかを確認しました。さらに、この2つのフェーズでは、次のようなデータを収集して、GCPに移行する効果を測定しました。

(1) サポートチームに対するサポートリクエストの発生数
(2) 仮想デスクトップ環境の利用に影響する問題の発生数
(3) 仮想デスクトップへのログイン数
(4) ユーザーからのフィードバックとアンケート結果

　まず、(1)については、95%もの減少が見られたそうです。これは、パブリッククラウドサービスであるGCPを利用することで、インフラ環境に対するサポートが不要になったことが主な要因としてあげられています。(2)については、当初は、想定外の問題が多数発生したものの、それぞれの問題点を解決していくことで、最終的には、GCP移行前の20%程度に低減することができました。(4)については、GAフェーズに向けての機能改善や機能拡張の参考資料として利用したそうです。
　最後のGAフェーズで、残りの全ユーザーを移行するにあたり、一番大きな課題になったのは、ユーザーディスクの移行です。既存の仮想デスクトップ環境には、ユーザーが個人的にファイルを保存するためのディスク領域があり、そこに保存されたファイルを新規のデスクトップ環境に移行する必要がありました。技術的には、Cloud Storageを経由してファイルをコピーするだけの作業で、それほど難しいものではありませんが、大量のユーザーに対してこの処理を行うと、ネットワーク帯域の問題などにより、コピーにかかる時間が長くなる恐れがあります。
　この問題に対処するために、移行プロジェクトチームは、仮想デスクトップの作成リクエストメニューの中に「ユーザーディスクの移行を希望する」という項目を追加しました。さらに、ユーザーディスクを移行する場合は、「仮想デスクトップが用意できるまでに24時間以上かかる場合がある」という点を明示的に記載したのです。その上で、既存環境のユーザーディスクの使用量が少ないユーザー（つまり、必要なファイルは自分でコピーするから、ユーザーディスクの移行は不要と考えるであろうユーザー）から、優先的に環境移行をお願いするメールを送信しました。この作戦は、予想通りにうまく行き、多くのユーザーは、ユーザーディスクの移行は不要という選択をしました。結果的に、コピーするデータ量を1.8PBほど減らすことができたそうです。

次回予告

　今回は、2019年に公開されたエッセイ「From Corp to Cloud: Google's Virtual Desktops」を元にして、Google社内の仮想デスクトップ移行プロジェクトについて、仮想デスクトップシステムの要件、そして、実際の移行作業を紹介しました。ユーザーディスク移行の負荷を減らすために、移行する際のデメリットをあえてユーザーに提示するというのは、すこし面白いアイデアかもしれません。筆者の場合、移行前の仮想デスクトップのユーザーディスクには、GitHubリポジトリのクローンなどが大量に保存されていました。これらは、新規環境で、再度、リポジトリからクローンすればよいものなので、ユーザーディスクの移行は不要という選択をしました。
　次回は、Googleのインフラ技術の1つ、サーチエンジンのロードバランシング処理に関する話題をお届けしたいと思います。

Disclaimer：この記事は個人的なものです｡ここで述べられていることは私の個人的な意見に基づくものであり、私の雇用者には関係はありません｡