こんにちは。社内でもVDI有識者と呼ばれることが多い鎌田です。 Amazon WorkSpacesのPoolsが出て久しいですが、皆様使いこなされていますか？元々あったWorkSpacesはPersonalとして分類されるようになりました。 この記事では、WorkSpaces Poolsのご紹介と、気を付けるべきポイントについて解説していきます。
Amazon WorkSpacesのPoolsとは
Amazon WorkSpacesのPools最大の特徴は、「接続する（WorkSpacesを使う）ユーザー数より、 準備しておくWorkSpacesの数が少なくて済む」という点です。
例えば、コールセンターのような、出勤している人数はある程度一定の数の人がいるが、使う人は日や時間帯によって異なる」といったケースの時に、Poolsを利用するのが向いています。 また、後述しますが、ユーザー固有の情報を多く持つ必要がないようなケースでも、Poolsの利用が推奨です。 以下の画像でイメージを描いてみましたが、固定のWorkSpacesに割り当たっている訳ではなく、Poolsと呼ばれている中で使うものが割り当てられて使うため、使うWorkSpacesが固定されている訳ではない、という使い方となります。 このため、マネジメントコンソールでも「非永続的（英語ではnon-persistent）」といった表記がなされています。
Personalの場合は、利用する人数分のWorkSpacesが必要なため、その分のコストも必要です。 Poolsの場合は使うユーザー全員分を用意する形にはならないので、使い方によってはPoolsを選択することでコストを抑えることができます。
Amazon WorkSpacesのPoolsで気を付けるべきこと
個人のWorkSpacesが割り当たる訳ではないPoolsでは、特有の設計考慮点が3つほどあります。 それぞれ、見ていきましょう。
容量の設定
WorkSpacesのPoolsはPersonalとは異なり人数分が常に用意されている訳ではないため、どのぐらいの人数分を接続できる状況で準備しておくかがポイントです。 容量とスケーリング、スケーリングポリシー設定で起動する台数の制御が行えるので、設定の際は「同時に使う可能性のある人数」をベースに考えましょう。
最小容量を「同時に使う可能性のある人数」、最大容量を「同時に使う可能性のある人数＋10台」など、同時に使う人数よりやや余裕をもった設定がお勧めです。 使う数次第ですが、概ね10%程度は確保しておくのが良いでしょう。
これは、同時に使う可能性がある人数が100人とした場合でも、シフトの交代のタイミングなどで同時の数が超えるケースはあり、その分を加味しておくのがポイントとなります。
スケーリングポリシー
スケーリングポリシーは、EC2で言うところのAutoScalig設定そのものですが、スケーリングの条件が、poolsに対しての「容量使用率」や「使用可能な台数」で設定する形となっています。
基本的には「容量使用率」での調整がお勧めです。最小や最大の容量を変えた場合でも比率であればこの設定は変更する必要がない、というところが理由です。
この設定については、実際の運用をしながら、調整されることをお勧めしています。 スケーリングが多く発生している状況の場合、最小台数の設定か、追加するインスタンスの数のどちらかが十分ではない可能性があり、当初の利用予定と実際の使用状況とを比較して、当初の予定から設定値を見直し、出来るだけスケーリングが頻繁に発生しない設定値とすることを推奨しています。
時間によって最大台数を上下させたい場合は、「スケジュールされた容量のポリシー」を使うのが良いでしょう。 月曜の朝8:00ぐらいに最大台数を大きくし、金曜の夜22:00ぐらいに最大台数を小さくするなどして、容量のコントロールをするといった運用です。 時間によってある程度台数コントロールをすることが可能な状況が分かっていれば、スケジュールも使いこなしてみてください。
画像は、平日毎朝8:00にスケーリングポリシーが起動するように設定する例となります。
ユーザーが個別の情報を多く持つようなデスクトップ設計としない
WorksSpacesのPoolsでは、ユーザー固有の情報を持つデスクトップとした場合、ログアウトのタイミングでWorkSpacesにアタッチされているVHDファイルにデータを書き込み、その後S3にVHDファイルをアップロードする仕組みで動いています。 また、読み込み時はS3に保存されたVHDファイルを使って、ユーザー固有の情報を読み込みます。
How application settings persistence works - Amazon WorkSpaces
S3からファイルを読み込むという動作がどうしても入ることもあり、ファイルの容量が大きくなればなるほど、読み込み時間が掛かるといったことにも繋がるため、PoolsのWorkSpacesでは、ユーザー固有の情報を出来る限り少なくするため、ユーザーが個別の情報を保持する部分をできる限り減らす設計を推奨しています。 ユーザー固有の情報を多く持つ必要がないケースでPoolsが向いているというのは、このPoolsがユーザー情報を管理する仕組みにも関係しています。
まとめ
- Amazon WorkSpacesのPoolsは、接続する（WorkSpacesを使う）ユーザー数より、準備しておくWorkSpacesの数が少なくて済むのが利点
- 常にユーザー数分が用意されている訳ではない
- 「同時に使う可能性のある人数」をベースに、最大台数の設計を
- ユーザーが固有の情報を出来るだけ持たないデスクトップ設計が推奨
WorkSpacesのPoolsについて、みなさんにご紹介しました。 皆様、良きWorkSpacesライフを！
