sorta kinda...

主にAWS関連ですが、これに限らずいろいろ勉強したことや思ったことを書いていきます。

ユーザの気持ちを考慮した AppStream 2.0 のスケーリング設計は難しいよ

それなりに人生楽しんでます、那須です。

最近 AppStream 2.0 でアプリのストリーミングで遊ぶを検証する機会があったんですが、その時にスケールアウト/インでドハマりしたので共有しますね。 AppStream 2.0 の使い方はドキュメント読めばわかると思うので、ここでは書くつもりがありません(それなりにステップがあるので書くのも大変

 

基本は Auto Scaling です

Auto Scaling って書くと皆さん普段から ELB でポリシー作ってると思うので「まー似たようなもんやしなんとかなるやろ」って思いますよね? ELB と同じと思って実際やってみると頭の中に???がいっぱいでてきます…

 

何が違うのか?

まず AppStream 2.0 のインスタンスがどのように使われるのかを見てみましょう。

docs.aws.amazon.com

フリートの各インスタンスは、一度に 1 人のユーザーのみが使用できるため、フリートのサイズにより、同時にストリームできるユーザーの数が決まります。

なるほど、、フリートのインスタンスが 5 台ならその時に利用できるユーザは 5 人ってことですね。これはつらい(お金が

あと、ユーザがアプリを使い終わってセッション終了した場合の動きが↓こちらです。

docs.aws.amazon.com

ユーザーがセッションを終了すると、AppStream 2.0 では、基盤となるインスタンスを終了し、必要に応じて新しいインスタンスを作成して、フリートの必要なキャパシティーを満たします。AppStream 2.0 によって新しいインスタンスが作成され、他のすべてのインスタンスが使用される前にユーザーが新しいセッションを開始しようとすると、ストリーミングリソースが使用できないというエラーがユーザーに表示されます。ユーザーがセッションを頻繁に開始および停止する場合は、フリートのキャパシティーの増加を検討してください。

どういうことかというと、(変動だと説明がややこしいので)仮にフリートを固定 5 台で運用してるとして、インスタンス 5 台でユーザが 3 人使ってたら、残り 2 台は空いてます。ここまではいいですね?

次に 2 人がセッション終了すると、インスタンスは 10 分程度は 3 台(空き 2 台、利用中 1 台)になります。この 10 分間で 3 人が使おうとすると、早い者勝ちで 2 人は使えますが、最後の 1 人は使えないことになります。10 分程度待つと、新しいインスタンスが起動してくるので、残りの 1 人も使えるようになります。

インスタンスの動きとしては、2 台が Termination 開始してから追加の 2 台を起動します。この起動待ちが 10 分程度の時間の正体です。

ややこしいですね。雑な図で描くとこうなります。

f:id:nasrinjp1:20181119102524p:plain

 

どういうスケーリングポリシーにするのがいいのか?

わかりませんw
答えがあるようでないのですが、今のところはある程度多めの Minimum Capacity に設定しておいて、Scaling Policy Condition に合致したらまた多めにまとめてスケールアウト、ってするのがユーザの立場からするといいのかもしれません。まあそれなりに課金はされますね。 逆にスケールインの場合は少しずつ減らしていくってのがいいかなと思っています。

 

実際にやってみないとわからない

設計でも提案でもなんでもそうですが、実際にやってみないとわからないことって多いですよね? でもクラウドなら簡単に試すことができるので、そんな悩みというか不安も減らすことができますよ! そして、AppStream 2.0 意外と面白いので皆さんも是非何かストリーミングしてみてください。夢が広がりますよー