仮想デスクトップ数5.5万超え、CPU使用率数％上昇でお祭り騒ぎ――VDI運用者が「数の暴力」から得た学びとは：リクルート5万人のテレワーク／VDI環境大解剖（2）

リクルートにおけるVDIの導入、運用、コロナ対応、そして今後のICT環境を紹介する連載。今回は、リクルートのVDI運用者が遭遇した2つの大きな問題と、その経験から得た学びなどについて。

[大野靖幸，リクルート]

　リクルートにおけるVDI（Virtual Desktop Infrastructure、仮想デスクトップインフラ）の導入、運用、コロナ対応、そして今後のICT環境を紹介する本連載「リクルート5万人のテレワーク／VDI環境大解剖」。初回は、主に当社のVDI環境の構築〜導入までお話ししました。当然のことですが、社内システムは導入して終わりではありません。導入後、きちんと会社の状況に合わせて運用する必要があり、構築よりも運用の方がより長く、深くプロダクトに関わっていくことになります。

　今回は、運用に関するポイント、また、筆者たちが運用経験を通して学んだことを共有して、皆さんにとって少しでも参考になればと思います。

運用において重視している3つのこと

　身も蓋もないことを言ってしまいますが、「運用」というものをするに当たって「これだけやっておけば十分」という“魔法のつえ”はないと思っています（あれば筆者も欲しい）。VDIもしくはVDI以外も含めて皆さんが常時システムを運用するに当たっては、“当たり前のことを当たり前にやる”ことが一番大事です。

　「なんだ、そんなことか」と思われるかもしれませんが、その“当たり前”について、運用の実体験を通して改めて理解できたこともあるので、本稿を通して何か皆さんのヒントになればと思っています。

　その“当たり前”については、「己を知る」「敵を知る」「それに備える」の3点が非常に重要です。孫氏の兵法のようですが、システム運用は、これに尽きると思います。

己を知る

　一言でいうと、自身が運用しているサービスの状態をきちんと把握することです。特にVDIのような集約環境では、インフラがどのようになっているのかの“AS-IS”の把握が非常に大事です。

　己を知るために、リクルートのVDI環境では、死活監視、パフォーマンス監視、リソース推移状況モニタリングをシステムに対して直接行っています。加えて、利用しているプロダクトのメーカーサポート状況の定期確認、リリースノートなどを通した新規発生バグの確認、提供プロダクトの状況のモニタリングも行っています。

　特にパフォーマンス監視は、集約基盤であるVDIでは非常に重要な要素です。当社ではコスト対効果も考えてCPUはオーバーコミットを採用していること、また仮想デスクトップ数が標準VDIで約4万1500台、セキュアVDIで約1万4900台あることから、1ユーザー当たりの仮想デスクトップ上のCPU使用率が1％上昇するだけで、基盤側の負荷はとてつもなく上昇してしまいます。構築当初はコンサルティングを受け、ブレードサーバ1台当たりCPU観点では190台の仮想デスクトップを賄える想定でサイジングしていましたが、運用開始後に監視したら88台しか賄えないことが分かりました。そのため、構築したVDI基盤にユーザーが移行を完了する前に急きょブレードサーバを追加するなど、ユーザーのパフォーマンスに影響を出さずに難を逃れたこともあります。

　またシステム自体をモニタリングするだけではなく、「現在、何が課題なのか」「課題に対して何をしなくてはならないのか」は常々、情報としてまとめ上げ、ストックすることを心掛けています。

敵を知る

　ここでの“敵”とは、VDIに対してポジティブにもネガティブにも影響を与える環境要因のことです。ビジネスの世界では当たり前ですが、システム運用の場面においても、外部環境と内部環境の2つに大きく分けて環境要因を考えていく必要があると思います。特に社内ITの世界では外部環境よりも、外部環境を受けた内部環境の変化による影響が重要ではないかと感じています。そして言うまでもなく、その環境変化を把握、予測しておくのは、特に技術革新を含めて変化の激しいIT環境では非常に重要なポイントとなります。

・外部環境

　コロナ禍のような外部環境の急激な変化は、自社でのコントロールが難しい部分です。こうした外部環境の変化を受けて内部環境も大きく変わるので、アンテナを高く張って外部環境の変化をいち早く把握して、そこからどのような影響が考えられるかを常に考え続けることが必要です。

・内部環境

　こちらは自社の環境要因です。当社で特に重要だったのは、ユーザー数や「業務上での仮想デスクトップの使われ方がどのように変動していくのか」を知ることです。構築当初、当社における標準VDIは3万台、セキュアVDIは1万5000台でした。ところが運用を開始してみると、VDI数は増加を続け、ピーク時では実割当数として標準VDIで約4万4600台、セキュアVDIで約1万5600台までVDIを準備する必要がありました。しかし、後述の通り、備えていたので、仮想デスクトップの在庫不足でユーザーにVDIを払い出せない事態は回避してきました。

　また集約環境では、利用形態によってリソースの変動が大きくなることから、各ユーザーの動向も気になるところですが、ここを把握するのは難易度が高いのが実情であり、内部環境の把握には現在でも課題が残ります。

　とはいえ、方策がないわけではありません。未来を完全に予測するのは難しいことですが、過去のトレンドを参考にしたり、システムを使うビジネスサイドの動向を把握したりしておくなど、できることをしておくことが必要だと思います。

それに備える

　状況を把握できれば、後は備えるだけです。例えば、増強やバージョンアップが必要と判断したならば、実施規模から必要な期間を算出して「いつ頃からどのくらいのコストをかけて実施するのか」「当初の対象のみではなく、周辺機器の互換性上の問題がないかどうか」を洗い出して“計画をきちんと立てる”ことが重要です。“見えた己”＋“理解した敵”から“行うことを導き出す”のです。

　また障害対応などの計画を立てても対応できない事案には、“誰が”“何を行うのか”を事前に定義しておくことが重要です。それによって、いざというときに皆が迷わずに迅速に対応できます。もちろん何が起こるか分からないので完璧に定義するのは難しいことですが、障害が起きたときに“誰が”“何を行うか”ガイドラインとして準備しておくことはできます。それがあるだけでも動きが大きく変わるので、まずはそこから定義していくのがいいでしょう。

大規模故の2つの問題事例と学び

　リリースに向けて、いろいろと試行錯誤したことは前回記事に記載されていましたが、リリース完了後の運用フェーズに入ってからも、やはりいろいろあります。リリースはゴールではなく、これから始まる運用という長い戦いのスタート地点でした。ただ、その対応を通していろいろと学びがあったので、幾つかの例を紹介します。

　大規模であるが故に発生した顕著な例として、「ARP問題」「CPU高騰問題」の2つを紹介します。

ARP問題――受信数がコアスイッチの許容範囲を超えて顔面蒼白

　もともと筆者はネットワークエンジニアとして10数年の経歴を積んでいたものの、ARP（Address Resolution Protocol）に悩まされる経験は初めてでした。

　突如「死活監視が落ちまくってます！　大量に機器障害が発生している模様です」との連絡があったときは、正直なところ顔面が蒼白（そうはく）となりました。筆者も一ユーザーの立場だったので、即座に自身のVDIで業務ができるかどうかを確認しました。自分は問題なかったので、全てのVDIに影響があるわけではないと分かり少しだけ安心しましたが、すぐにユーザーからのコール状況を確認しなければなりません。

　すると、運用チームのリーダーが執務室内（400人くらいが就業しているオフィス）で、突然大きな声で「VDIがちゃんと動かない人はいませんか〜。動きがおかしい人は挙手してください」と叫びながら執務室内を走り回り、挙手した人の状況を確認し始めました。これは「機転が利いているな」と正直感心しました。その場でユーザーの状況を把握して、確認する。当たり前ですが早く、正確に業務影響を理解できるのです。

　その場で、何人も挙手するメンバーが出てきたので「全社的にも業務に影響が出ているに違いない」と体感しました。幸いなことに挙手した人のVDIを確認したところ、「かくつく」「動作が重い」など全く業務ができないわけではなかったのが不幸中の幸いでした。

　この障害を解析した結果、VDIのネットワーク構成がコアスイッチに集約されたフラットな構成だったので、ARPの受信数がコアスイッチの許容範囲を超えて、ARPのDropが発生。結果、ICMP（Internet Control Message Protocol）や業務トラフィックにもDropが発生する事象でした。

　その場では、暫定的にコアスイッチでのARP許容数をチューニングして回避したものの、この障害によってネットワーク構成の問題が露呈したので、その後2年をかけて基盤ネットワーク構成を変更したことがありました。

　後から考えてみると、実はその前に障害の兆候となる事象が起こっていたのです。以前から死活監視のPing落ちが少しずつ出てきているのは検知されていました。しかし毎回すぐに復旧しており、調査しても原因不明でした。すぐに正常に戻っていることから、それ以上深く調査しなかったのは大いに反省すべき点でした。

CPU高騰問題――仮想デスクトップ数5万5000超えだとCPU使用率数パーセント上昇でお祭り騒ぎ

　VDIに入れているAP（アプリケーション）の自動更新が発生。その結果、利用しているブラウザとの組み合わせによって、CPUが1VDI当たりで数パーセント上昇する事象が発生しました。数パーセントくらいではたいしたことがないように見えるかもしれませんが、前述の通り、集約環境においては非常に恐ろしい状況を招くのです（「数の暴力」と呼んで筆者たちは恐れています）。

　当社のような台数規模となると、その1台当たりのわずかな上昇が一気に基盤全体のCPU使用率を押し上げ、結果的に使用率100％まで跳ね上がることになりました。当然ですが、各ユーザーのVDIも正常には動きません。多数のユーザーの画面が固まって全くVDIが動かない状況に陥りました。

　高騰しているプロセスを特定し、原因が分かったものの、原因となっているAPが重要な製品なので、おいそれと停止できなかったので、その製品の主管部署と共同でAP停止による影響調査、対応策を立てながら、【1】APを一時停止し、【2】ユーザーに特定のブラウザの利用を停止するようにアナウンスして、【3】VDIを再起動すると一時的にCPU使用率が下がることが分かったので、毎晩のように運用メンバーでVDIを強制再起動しました。

　本当にお祭り騒ぎでした。

　最終的には被疑APが改修されたので、そのパッチを適用しCPU使用率を正常に戻すことができました。

　VDI運用部門、AP運用部門、全社への広報部門、ビジネス部門のキーパーソンとコミュニケーションをとる部門、デスクトップOSに知見がある部門など、多岐にわたる部署を巻き込んで、全社総力戦の状態で対応しました。

2つの問題から得た学び

　これらの経験から非常に重要だと学んだのは下記2点です。

• 規模が大きくなればなるほど、通常考慮しなくてもよさそうなことも深く考えておかないと、大きな問題を生む
• いざというときに社内関連部署を巻き込める状況を常日頃から作っておく

　ネットワークを取り扱っている方なら、ARP処理能力は製品カタログなどで見る機会があり分かると思いますが、ネットワーク機器は性能が良いので、ARP処理能力自体を問題にすることは少ないでしょう。また数パーセントのCPU使用率上昇についても、その程度なら影響はあまりないだろうと思う人が大半だと思います。

　ただVDIのような大規模集約環境では、これらの要素が大きな影響を与えることになるのです。これは筆者を含めた運用メンバーは経験しているからこそ理解できますが、一般ユーザーにはなかなかぴんとこない点です。時折、他案件の担当者から「検証の結果数パーセント程度のCPU使用率上昇なので、問題はありません」と報告を受けることがありますが、その数パーセントが生む最終的な影響について、皆で認識をそろえていく重要性を感じます。

メーカーの皆さんとの共同作業

　VDIの全社導入は当社にとって初めての試みであり、正直なところチャレンジングだったことは間違いありません。それ故、リスクを下げるために世界的にシェアが大きく、業界でも有名なメーカーのプロダクトを採用しましたが、いざカットオーバーすると、やはりいろいろな製品バグが大量に発生しました。思わず「こんなにもあるのか」と言いたくなるくらいでした。詳細は書き切れませんが、ブラックアウトの発生、PSOD（Purple Screen of Death）の発生、管理サーバにログインできない、マウスポインタが正しく動かないなど枚挙にいとまがないほどでした。

　その中には、実は仮想化製品提供メーカー起因ではないものもあったのですが、毎週、トラブル解析について進捗（しんちょく）状況のミーティングをして、相互の調査状況を確認しながら対応するなど、メーカーの皆さんにも真摯（しんし）に向き合って対応していただきました（とても感謝しています）。

　そこに加え、ユーザーから「Skype」での通話品質が悪いという話も挙がってきました。再現試験（時間帯別）をしたり、検証環境を利用しながら被疑箇所を絞り込んだりしたところ、「PCoIP（PC over IP）プロキシで利用している機器が悪いのではない」というところまで切り分けることができました（さらっと書きましたが、いろいろな要素が絡んでいるので、被疑箇所を絞り込むためだけでも非常に時間がかかりました）。

　メーカーの皆さんとさらに調査したところ「内部のCPU処理におけるロジック上、特定通信が一部のコアに集中してしまったため発生する事象」ということが判明しました。当然、このような処理はこちら側では把握が難しい問題だったので、原因究明にはメーカーの皆さんの支援が必須でした。

　特にチャレンジングな場合は、メーカーの皆さんとのリレーションシップをきちんと確立して、相互に協力しながら「いかに最短経路で正常化させるか」を考えることが非常に大事と断言できます。これは一朝一夕でできるものではないので、システムの構築時期から、きちんとリレーションシップを確立することを念頭に置いてコミュニケーションをとっておくとよいと思います。

チーミング、組織設計

　運用開始当初は日々、機能領域ごとに分かれたチームで運用に当たっていました。ところが前述の通り、障害が非常に多く出てくると、正直なところ一つ一つの障害対応に手いっぱいになることは否めませんでした。その結果、定期的にやってくるバージョンアップ作業や、先の計画の立案が全くできず、取りあえず目の前の課題をつぶして、他を先送っていたような状況でした。当然、バージョンアップなど先送りできないときはやってくるので、負のスパイラルです。

　そこで筆者の所属する部門では、障害対応が中心のチームと、バージョンアップと増強のチームに分割しました。同じ機能領域に詳しい人がそれぞれのチームに必要となるというデメリットは発生しますが、迅速に障害に対応しなくてはならないし、EOSL（End of Service Life）に向けたバージョンアップと増強を期限までに完了させる必要があったので、両立するためには体制変更が必要でした。幸いにも狙い通り、無事に両立して運用を続けることが可能となりました。

　現在は状況が落ちついてきていることから、再度機能別のチームに戻すことも視野に入れて、組織設計を考えたいと思っています。

　運用している中でいろいろな変化を起こすことは、当然、各所との衝突につながることもありますが、それを恐れることなく、変化する状況に応じて体制も柔軟に変えていくことも選択肢に入れるべきだと考えます。もちろんシステムだけではなく“人”の感情や意識にも直結するところではありますが、ぜひ皆さんも心に留めていただきたいと思います。

　次回以降は、本稿でも少し触れているコロナ禍におけるVDI運用について詳しく紹介します。

筆者紹介

大野靖幸（オオノヤスユキ）

株式会社リクルート 横断機能担当 ICT統括室 インフラソリューションユニット インフラソリューション部 インフラソリューション4G グループマネージャー

SIerで提案、構築を経験した後、2016年リクルートテクノロジーズに入社。リクルートグループ全社VDI運用部隊のグループマネージャーとして業務に参画。

現在は、既存基盤の特性や運用ノウハウを生かしながら、次世代のPC環境の検討を推進。