あけましておめでとうございます。
がんもことプロジェクトマネージメントチーム佐竹です。
今年もどうぞよろしくお願い致します。
皆様、今年のお正月はいかがお過ごしだったでしょうか。
私は例年通り京都の実家に帰省しておりました。
1月1日から2日にかけて、かなりの大雪となったのが印象深いです。
この写真は、1月3日午前中の京都市内の写真です。
このように、京都はとても寒かったのですが。
しかし、実家に帰ると猫がいます。
この猫は捨て猫だったのですが、私が拾って実家に預けた経緯があります。
にもかかわらず、久しぶりに帰ると全く持って他人の扱いを受けるため、全然相手をしてくれませんでした。
でも猫だから仕方ないですね…。
そんなわけで、新年一発目からAmazon WorkSpacesのお話いってみましょう。
本日はWorkSpacesの運用に関する情報を3点お伝え致します。
はじめに
本記事の中では、サービスであるAmazon WorkSpacesを「WorkSpaces」と省略して記載しています。
そして、端末(インスタンス)1台を指す「WorkSpace」を「ワークスペース」とカタカナで記載しています。
よろしくお願いします。
では本題です。
週次のメンテナンス時間をどのように運用するか？
WorkSpacesには、週次のメンテナンスタイムが設定されています。
RDSのように「メンテナンスウィンドウ」と呼ばれていることもあるようです。
この時間帯は、現在指定できず、固定で
毎週日曜日の午前0時0分～午前4時0分の間に実行されます。
また、この時間はWorkSpacesが設置されているRegionの現地時間となります。
つまり、例えばですが、アメリカのWorkSpacesと、日本のWorkSpacesでは
メンテナンスされる時間はそれぞれ異なるということです。
なお、上記の内容は、AWS公式サイトではFAQのページに記載がされています。
参考：http://aws.amazon.com/jp/workspaces/faqs/
24時間365日、現場のユーザがWorkSpacesを使いたい場合、
このメンテナンス時間の運用を、運用者側は考えなければなりません。
結論から申しますと、毎週この時間帯は「WorkSpacesを利用できません」として運用することを推奨いたします。
理由ですが、AWSはこのメンテナンス時間において
- 毎週必ずメンテナンスが行われるわけではない
- メンテナンスが行われる以前に、AWSから必ず通知を送ることは明言できない
というスタンスをとっています。
言い換えると「次の日曜日にメンテナンスがされるかどうか」は
常に「されるかもしれないし、されないかもしれない」状況となります。
よって、対象の時間帯は「WorkSpacesを利用できない」として運用することを推奨します。
もし、AWSが「メンテナンス実施の通知を毎週金曜日の0時までに送信する」
というような対応を必ずしてくれるのであれば、それを受けて
「利用できない時間が発生する場合は、事前に利用者に向けて通知します」
とするWorkSpaces管理運用も可能になります。
しかし、AWSはそういう通知を保証してないため、上記の通り
対象の時間帯は「WorkSpacesを利用できない」として運用することを推奨します。
これに関連して、実際に行われた過去のメンテナンスとその通知について、参考情報として記載します。
2014年12月7日(日)のメンテナンス時間である
「午前0時0分～午前4時0分の間」に、弊社管理のスタンダードバンドルのワークスペースにて
それぞれパフォーマンスアップグレードが行われました。 これにより、スタンダードバンドルのワークスペースが1vCPUから2vCPUに、
メモリが3.75GBから4GBにアップグレードされたのですが、
このメンテナンス時にはAWSより各アカウントの登録メールアドレスに事前通知がありました。
また、この通知を受け取った日付は、2014年12月3日(水)でした。
以上が12月7日に実施されたメンテナンスに関連する情報でした。
このように、事前に通知が行われてもいます。
これらに加えて、各ワークスペース内部で行われるWindowsUpdateの設定は、
デフォルトで毎週日曜日の午前2時0分にインストールがされるように設定がされています。
これはWorkSpacesのメンテナンス時間の枠内にありますので、
WindowsUpdateと合わせて、毎週日曜日の午前0時0分～午前4時0分については
利用を控えるように通知された方が良いでしょう。
ちなみにですが、メンテナンス時間に行われるメンテナンスでは、
「Cドライブ及びDドライブのデータが消失するようなことは無い」とのことです。
WorkSpaces Imageのデプロイをどのように運用するか？
WorkSpacesでは、個別のワークスペースをイメージとして取得し、
それをオリジナルバンドルとしてデプロイ(配信/適用)することが可能です。
詳しいやり方は以下の記事をご覧ください。
このImageのデプロイですが、各ワークスペースのRebuild(再構築)を必ず実行します。
Rebuildは、そのワークスペースの元となった対象のBundleから、ワークスペースを再作成する処理ですが、
これによりCドライブのデータはBundleに紐付きのあるImageから再作成され、
Dドライブは「12時間おきに取得される自動バックアップ」から復元されます。
問題はこの「Dドライブが12時間おきに取得される自動バックアップから復元される」点です。
また、2015年1月13日現在、Dドライブのデータは任意に取得することができず、
自動バックアップに任せるしかない状況です。
例えばですが「毎月最終日の24:00にデプロイを実施する」という運用を考えた場合、
※分かりやすくするため24:00としていますが、実際は22:00～24:00など幅を設けた方が良いでしょう
2015年1月であれば、デプロイを実施する日付は1月31日 24:00になります。
このとき、1月31日の12時から24時の間にDドライブに保存されたデータは
「全て消え、Dドライブのバックアップデータから復旧される」可能性があります。
そのため、Dドライブのデータを保証したい場合は
「1月31日の12:00-24:00にDドライブに保存したデータは、
確実に社内のファイルサーバにも保存しておくよう周知徹底」
という運用をされることを推奨します。
もしくは「対象の時間帯ではWorkSpacesを利用しないでください」
というアナウンスでも良いかもしれませんが、利用者の都合もありますので、
このアナウンスは運用上厳しい場合もあるかと考えています。
例では毎月最終日としていますが、毎月の最終日曜日などにすると、
利用しないようにするハードルは少し下がるかもしれませんね。
なお、コストメリットという点から、WorkSpaces Imageの元となる
ワークスペースのメンテナンスは、月末を推奨しております。
例えば1月31日にワークスペースを作成し、その日の24時までに削除した場合
そのワークスペースの月額利用料は0円です。
詳しくは以下の記事をご覧ください。
パスワード再設定の運用についての注意事項
最後は少し細かいネタです。
Windowsでは、パスワードポリシーでパスワードの有効期限を設定できます。
具体的には、90日や30日に設定できます。
（また、これと合わせてパスワードが切れる前に通知する機能も存在します）
これを設定している場合、設定した期間が経過した時点で
「パスワードの有効期限が切れているので変更してください」
という旨のメッセージがログイン画面に表示され、
古いパスワードと新しいパスワードを2回入力する画面が出てきます。
Active Directoryと連携すると、このパスワードの有効期限を
Directoryに属している全ユーザに適用できます。
そのため、WorkSpacesのAD Connectorをご利用される場合、
引き続き上記のポリシー運用を続けたいお客様も多くいらっしゃるかと存じます。
これをWorkSpacesで行った場合、
設定した期間が経過すると、物理のデスクトップ(もしくはリモートデスクトップ)では
「パスワードの有効期限が切れているので変更してください」
という旨のメッセージがログイン画面に表示されるのですが、
WorkSpacesのクライアントでは、この画面が表示されません(2015年1月13日現在)。
WorkSpacesクライアント接続はリモートデスクトップ接続ではなく、PCoIPプロトコルを利用した独自クライアントです。
このクライアントがパスワードの変更機能に対応していないため、
ユーザがログイン時にパスワードを変更することができません。
そしてまた、パスワードの有効期限が切れてしまうと、ユーザ側でパスワードを変更することができないため、
管理者側、つまりADの管理者がパスワードを変更してワークスペースの利用者に通知をする必要があります。
現状のWorkSpacesの仕様では、パスワードの有効期限を設定する運用は今まで通りできないため
何かしら別の運用ルールを考える必要が出てきます。
まとめ
今回の記事では、以下の点について記載致しました。
- 週次のメンテナンス時間では、WorkSpacesを利用しないように運用する
- デプロイ(Rebuild)前にはDドライブデータの取り扱いに注意して運用する
- ユーザ側でWindowsのパスワード再設定ができない点に注意して運用する
WorkSpacesの導入でハードルが高いのは、現場ユーザに向けた運用手法を確立する点だと考えています。
WorkSpacesはフルマネージドのサービスであるため、管理側の機器保守等の負荷は大分減りますが、
フルマネージドということは、イコール「WorkSpacesの仕様に沿った運用」が必要になります。
そして、この記事を読んだ方が、WorkSpacesの運用に関わる仕様を少しでもご理解頂け
WorkSpaces導入後の運用がより具体的に想像できるようになったら幸いと考え記載させて頂きました。
また、もしAmazon WorkSpacesの利用に少しでも興味を覚えられましたら
是非サーバーワークスまでお問い合わせください！
ここまで読んでいただき、ありがとうございました。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
