仮想デスクトップ数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使用率数パーセント上昇でお祭り騒ぎ