前書き
こんにちは！
ambrでRobloxクリエイターかつサーバーサイドエンジニアをしているhoshino（Facebook）です。
本記事では、LuaとAWSを使って、Windows用アプリの大量実行する方法について解説します。
ちょっとでも気になった方はぜひご覧いただけますと幸いですm(_ _)m
本題: Lua + AWSによるWindows用アプリの大量実行
前提と動機
弊社では、バーチャル体験プラットフォーム「xambr」を運営しています。
従来xambrでは、安定して同一空間に接続できる人数は50人程度でした。
ここでの同一空間とは、ユーザーの動きが完全に同期される空間、の意です。
従来のxambrでは、同種の空間に50人以上がアクセスした場合、同じ見た目の別の空間が生成されるようになっていました。
（インスタンスが別、という表現が適切かもしれません。）
しかし、この50人という人数は決して多い人数ではなく、オンライン即売会やバーチャルライブなどの様々なイベントに対応するためには、もっと多くの人数を同一空間（1つのインスタンス）に集める必要がありました。
結果として改修は成功し、xambrは同一空間に500人が接続できるプラットフォームとなりました。
安定した500人接続を保証するためには、サーバーへの負荷テストの実施が必要です。
通常、負荷テストでは実際のクライアントアプリは用いずに、Apache JMeter™やDFrameなどを用いてサーバーに負荷をかけることが多いかと思います。
ambrでも、DFrameを用いた負荷テストも実施し、多人数接続に耐えうるデータの取得は完了していました。
しかし、同一空間への500人接続はambrにとっても初の試みです。
可能であれば、より本番に近い形でのテストを行いたいという気持ちが開発チーム全体にありました。
そして、Lua + AWSによるWindows用アプリの大量実行によるテストが実施されることになりました。
実現方法
この節では具体的な実現方法について述べます。
何が必要か？
テスト要件を精査する中で、Windows用アプリの自動大量実行には少なくとも以下の仕組みが必要なことがわかりました。
- 起動後、人間の操作なしに動く仕組み
- 同時に起動するための仕組み
- xambrの動作環境を満たす大量のWindowsマシン
1については、UnityアプリをLuaで自動実行する手法はある程度確立しており、xambrの開発用クライアントアプリにも既に実装済みでした。
そのため、Luaスクリプトの簡単な改修で用意できました。
本記事では、あまり情報のない2と3を中心に解説したいと思います。
2. 同時に起動するため仕組み
同時に起動するに当たり、採用したのはタスクスケジューラでした。
タスクスケジューラは、Windows/Windows Serverに標準で組み込まれているRPAツールです。
- 特定のアプリを特定の日時に起動
- .batファイルを実行の対象に取れること
が採用の決め手になりました。
3. xambrが要求する推奨スペックを満たす大量のWindowsマシン
xambrはメタバースアプリのため、動作環境に求めるスペックは決して低くはありません。PC向けクライアントアプリはWindowsにのみ対応している、という制約もあり、大量のWindowsを用意する必要がありました。
- 大量に必要
- 要求スペックを満たす
- 各種設定を済ませた後、そのインスタンスを複製したい
- Windowsのライセンス料は時間単位課金がいい
上記要件を満たすには、パブリッククラウドを使うのが最適でした。
xambr自体もAWS上に構築しているため、Amazon EC2のGPU系インスタンス「Amazon EC2 G4 インスタンス」を使うことで解決しました。
ざっくりと具体的な手順を述べておくと、以下のように大量のWindowsマシンを用意しました。
- ベースとなるEC2インスタンスを用意して各種設定を済ませる
- 対象となるアプリの配置やタスクスケジューラの設定など
- ベースとなるEC2インスタンスを下にAMIを作成する
- この際、Sysprepの作業を忘れずに！
- 公式ドキュメントなどが参考になるかと思います。
- 作成したAMIを複製
残った課題と注意点
上述の自動化によって、円滑に実クライアントアプリでのテストを行うことができました。
一方、以下が課題として残りました。
課題：ログイン
開発用xambrクライアントアプリを起動するには、Windowsにログインした状態である必要がありました。これはタスクスケジューラではなく、弊社アプリに起因する事象です。そのため、各Windows端末に手動でRDPで接続しログインする作業が発生しました。
幸い、一端末に一アプリの構成ではなかったので気合いでなんとかしましたが、これ以上の台数をテストする際にはここも自動化が必要です。
注意点：金額
それなりのスペックのマシンをたくさん用意するので、一般的な負荷テストよりも金額が膨らみます。
本記事を参考にテストの実施を検討される際は、必ず金額を試算してから実行してください。
後書き
ここまで読んでいただきありがとうございます！
改めて見てみると、今回の大量実行の実現には、それほど目新しい技術は使われていません。
LuaによるUnityアプリの自動実行も、タスクスケジューラも、Sysprepも、令和の時代においてはAmazon EC2も枯れた技術といっていいでしょう。
今回うまくいった理由は、これらを適切に組み合わせることができたからかと思います。
領域が微妙に異なるこれらの技術を組み合わせることができたのは、開発チームの、チームとしての力だなと思いました。
そんなambrの開発チームが作る今後のプロダクトにもご期待ください！
Discussion