「AWS Black Belt Tech Webinar 2014 – Amazon AppStream」レポート
こんにちは、虎塚です。
先週水曜のAWS Black Belt Tech Webinarを聴講しましたので、レポートします。今回のテーマは、AppStreamで、講師はアマゾンデータサービスジャパンの榎並さんです。
※すでに公式のWebinar資料が公開されていますので、お時間のある方はそちらをご覧いただければと思います。
- Webinar資料: AWS Black Belt Techシリーズ Amazon AppStream
AppStreamは、1年ほど前にリリースされたAWSのサービスですね。
Amazon AppStreamとは
- Amazon AppStream
- アプリケーション処理をクラウドで実行し、クライアント端末に入出力をストリーミングできるサービス。
Amazon AppStreamのメリット
- 1. デバイスの制約を排除
- 重い処理をクラウドで行うので、エンドユーザのハードウェアが制約にならない。シンクライアントから利用可能
- 2. アプリケーション開発時間の短縮
- コード開発を一度すれば、複数デバイスにアプリケーションを展開できる
- 3. 即時のアプリケーション利用
- ファイルのダウンロードやインストールが不要で、ユーザが即座にアプリケーションを利用開始できる
- クライアントアプリケーションのサイズは5MB程度
- 4. シンプルなアプリケーション更新
- 最新バージョンをクラウドに展開するので、すべてのユーザが最新バージョンを利用できる
- 5. セキュリティの向上
- アプリケーションがクライアントにダウンロードされないので、重要なビジネスロジックはクラウドで守られる（ゲームのチート対策のようなことが必要ない）
- 認証サービスと統合できるので、利用ユーザをを制限できる
- 6. オートスケール
- サーバの拡張性は、AppStreamのオートスケールで担保
- 運用保守をする人がサーバ台数を考慮しなくてよい。アプリケーションの管理に注力できる
ユースケース
AppStreamがどのようなところで使えるか、すでに使われているかについて、代表的なユースケースを3つ紹介する。
ユースケース #1 CAD/3D/シミュレーション
ハイエンドPCでなく通常のPCで、CADや3Dシミュレーションなどのリッチなアプリケーションを実行できる。
仮想サーバにはg2インスタンスを使う。クラウド上のGPUで計算処理を行い、ストリームとして配信される。
このユースケースには、日産様から応援のコメントもあるとのこと。
ユースケース #2 ゲーム
通常、大きなファイルサイズのゲームはダウンロードが完了してから開始できるが、ダウンロード中にユーザが退屈したり離脱したりしてしまう。ダウンロード中の離脱を防ぐ仕組みとして、AppStreamを使う。
EVE Online様の事例では、大きなゲームをダウンロードしている間に、ゲームで使うアバターをAppStreamで配信して設定できるようにした。ダウンロードが完了すると、そのアバターを使ってゲームを開始できる。
また、ゲームはクラウド上で実行されて、クライアントにダウンロードされない。そのため、海賊版を作成されるリスクを抑えられる。
ハードウェアの制約なくクリエイティブなゲームを提供できるので、ゲームの作り手にとってもうれしい。
ユースケース #3 ライフサイエンス
スキャン撮影、画像解析、外科手術シミュレーションなどの重いグラフィックス処理に利用する。
クラウド上でレンダリングしてストリーム配信を行うため、病院や大学で利用されているPC以外のポータブルデバイスで、画像やシミュレーションを見たいというユースケースにも対応できる。
システム概要
AppStreamシステム概要
AppStreamの中には、大きく2つのコンポーネントがある。
- AppStreamサービス: ストリーミングを実行する（プロキシの役割）
- AppStreamホスト（EC2）: 計算処理やレンダリングを実行する
Amazon AppStream構成要素
構成要素は次の5つ。
- ストリーミングアプリケーション: お客様が配信したいアプリケーション
- クライアントアプリケーション: ビューワー（スマフォ、タブレット、PCなどの上で実行される）
- 認証サービス
- AppStreamホスト: 利用するEC2はg2.2xlarge. 15GBのメモリと8vCPUでグラフィック処理に特化できる
- AppStreamサービス: 提供リージョンは、us-eastと東京（2014年10月23日時点）
ストリーミングアプリケーション＆クライアントアプリケーションの前提条件
- クライアントアプリケーション対応OS
- Android, iOS, Chrome browser, MacOS, Windows等の指定バージョン以降
- 参照: Service Requirements - Amazon AppStream
- ストリーミングアプリケーション
- Windows Server 2008 R2 64bit
- クライアントネットワーク
- 必要な帯域は実行するアプリケーションに依存するが、3Mbpsのインターネット接続があることが理想
Amazon AppStream STXプロトコル
高解像度のSTreaming eXperienceという意味。Amazonのプロプライエタリなプロトコルで、次のような特徴を持つ。
- サーバからユーザへ、H.264エンコードの動画と音声をUDPで転送する
- ユーザからサーバへ、入力をTCPで転送する
- クライアントのネットワーク状況を計測して最適な配信を行う
クライアント側アプリでプロトコルを意識せずに使えるように、AmazonからSDKが提供されている。
使用するポートは次の3個。
- STX Service: Port 80
- STX TCP for input: port 5900
- STX UDP for media: ports 9070-9080
対応可能なクライアントインプット
- キーボード、マウス、タッチ（タブレットなど）
- ゲームコントローラー
- Raw user input（加速度計、カメラなど）
- クライアントメッセージ
認証サービス
AppStreamのアプリケーションを実行できる人を認証するサービスのこと。認証サービス自体は、AppStreamのサービスの中には含まれず、外部の認証サービスを統合して利用することを想定している。
統合の実装については、サンプルのソースコードやCloudFormationテンプレートがある。DynamoDBに格納されたユーザ情報を参照して認証し、AppStreamに接続するサンプルがある。
シーケンス
ざっくり次のような流れになる。
- クライアントから認証サービスにアクセスし、認証を行う（例: IDとパスワード）
- 認証サービスからAppStreamサービスのAPIを実行する
- AppStreamホストのインスタンスを確認し、セッションを作成する
- 空いているホストをクライアントに返す（＝クライアントが、アサインされたAppStreamホストをAppStreamサービスから受け取る）ことで、セッションを開始する
- クライアントとホストがダイレクトにやり取りし、ストリーミングを開始する
現在の仕様では、1つのコネクションでAppStreamホストが1台起動し、その上でAppStreamアプリが実行される。
ストリーミングアプリケーション開発
スタンドアローンモード
SDKを使ってストリーミングアプリケーションを実装した後、スタンドアローンモードでデバッグできる。認証サービスとAppStreamサービスを経由せずに、直接AppStreamホストと通信し、アプリケーションの挙動を確認できる。
- 利用方法
- 参照: Option 2: Preview Your Application on Amazon AppStream Standalone Mode - Amazon AppStream
- 注意1: マニュアルではRDPを利用しているが、VNCを利用する（TinyVPNなど）
- 注意2: サンプルアプリケーションが自動起動するが、手動で終了して、自分のアプリケーションをインストールして起動する
ストリーミングアプリケーションの実装
- Amazon AppStream SDKをストリーミングアプリケーションに組み込み、クライアントアプリケーションとの入出力ストリームを実現する
- ストリーミングアプリケーションは、ハンドラを通してクライアントアプリケーションからの入力処理をする
- 7個のインタフェース（後述）を実装することで、配信やキャプチャができる
（参考）Amazon AppStream SDK オブジェクト
- XStxServerLibrary
- サーバライブラリの最上位レベルのオブジェクト。XStxServerManagerオブジェクトを作成するのに利用する
- XStxServerManager
- クライアントセッションを管理し、アプリケーションにイベントを送信する。XStxServerのハンドルを返す
- XStxServer
- クライアントにコンテンツをストリーミングする/クライアントからユーザ入力を受け取る
（参考）Amazon AppStream SDK インタフェース
- XStxIAutioSource
- アプリケーションから音声フレームを取得する（XStxServerから呼び出される）
- XStxIInputMapping
- クライアントから返されたユーザ入力のフォーマットを、アプリケーションで使用できるフォーマットにマッピングする
- XStxIInputSink
- XStxServerオブジェクトからユーザーデータを受け取る
- XStxIRawInputSink
- XStxServerオブジェクトからユーザーデータ（raw data）をバイトストリームで受け取る
- XStxIServerListener
- クライアントとの接続確立/切断時に、XStxServerからイベントメッセージを受け取る
- XStxIServerManagerListener
- AppStreamがクライアントセッションを作成/終了した時に、XStxServerManagerからイベントメッセージを受け取る
- XStxIVideoSource
- アプリケーションから動画フレームを取得する（XStxServerから呼び出される）
（入出力をバッファリングするモードとそのまま出すモードがある）
ストリーミングアプリケーションの設計上の注意
ストリーミングアプリケーションは特殊なので、他のクライアントアプリケーションとの違いに注意する。考えるべきポイントがいくつかある。
- 常時ネットワーク接続
- アプリケーションは常時ネットワーク接続を必要とするため、ネットワークが利用できない場合について考慮する
- レイテンシ管理
- アプリケーションをAppStreamからストリーミングすると、ローカルで実行する場合と比べてレイテンシがかかる。AppStream自体のオーバーヘッドはわずかだが、変動しがちなネットワークのレイテンシを考慮する
- 永続的ストレージ
- 特に大事。1回終了するとAppStreamホストのインスタンスはterminateされて、データが失われる。たとえば、ゲーム内のステート情報がインスタンスにあるとなくなるので、永続的なストレージに書き込む必要がある
- 動画出力、音声出力、ユーザー入力のリダイレクト
- ストリーミングをするには、SDKに用意されたライブラリに出力をリダイレクトし、ライブラリからイベントをリスンするインターフェイスを実装する
- ハイブリッドアプリケーション
- AppStreamからアプリケーション全体をストリーミングするか、デバイス上で一部の処理を実行するか、ハイブリッドにするかを考慮する。たとえば、ゲームの場合、基本的な文字アニメーションはデバイスで描画し、重いグラフィックはストリーミングするなど
ストリーミングアプリケーションのテスト
前述のスタンドアローンモードでテストを実施する。Remote tools for Visual Studioで、ストリーミングアプリケーションをデバッグできる。
- 詳細: Debug Your Streaming Application in Amazon AppStream Standalone Mode - Amazon AppStream
- 参考: デバイスのリモート ツールのセットアップ
ストリーミングアプリケーションのビルド
ストリーミングアプリケーションをAppStreamにインストールするという作業を自動で行うため、サイレントインストーラ（*.exe）を実装する必要がある。*.msi, *.bat, *.zipファイルは使用できないことに注意する。
クライアントアプリケーション開発
ビューワ側の開発について説明する。
クライアントアプリケーションの設計上の注意
- アプリケーションとクライアントの解像度が異なる場合がある
- ビットマップをピクセル単位で編集するような高精度な入力が必要な場合、考慮が必要
- 複数の入力イベントがある場合の挙動について、仕様を考慮すること
- さまざまなインプット方法に対応するか、1種類のインプットしか許容しないか
クライアントOSごとのビルド
開発者ガイドを参照する。
- Android 用クライアントの作成 - Amazon AppStream
- iOS 用クライアントをビルドする - Amazon AppStream
- OS X 用クライアントの作成 - Amazon AppStream
- Windows 用クライアントをビルドする - Amazon AppStream
コーデックとオープンソースライセンス
AppStreamでは、H.264/AVCフォーマットと、Opus音声フォーマットを利用している。クライアントアプリにH.264/AVCデコーダを含める必要があるが、デコーダのライセンスにアプリケーション配布側の責任で準拠するよう注意する。
デプロイと管理
ストリーミングアプリケーションのデプロイ
スタンドアロンモードでテストした後、ストリーミングアプリケーションをManagement Consoleからデプロイできる。
- サイレントインストーラをS3に格納する
- 署名付きURLを取得する
- AppStreamのManagement Consoleからアプリケーションをデプロイする
接続確認
デプロイ後、アプリケーションへのActiveなセッション数と、接続可能なセッション数を、Management Consoleから確認できる。
アプリケーションのログ
ストリーミングアプリケションのログを取得し、S3に格納できる。
/AppStream///yyyy-mm-dd/.zip
- デフォルトで出力されるログ
- ローンチログ
- ダンプファイル（Minidump files）
- 標準エラー出力
- 標準出力
- メトリックス: アプリケーション実行時のCPU, メモリ, Disk, GPUの使用状況メトリックス
サービス上限緩和
デフォルトで同時10セッションが上限だが、上限緩和申請できる。ただし、上限値によっては、2週間から10週間かかる可能性がある。
コスト
東京リージョンで、1時間のストリーミングにつき$1.20かかる。リザーブドストリーミングセッションもある。
参考資料
Q＆A
このあたりから音声がちょっと途切れがちで、よく聞き取れませんでした。間違っていたらご指摘ください。
- Q: 対応クライアントでChromeCastの対応予定はありますか？
- A: 今のところロードマップにはないが、要望に応じて対応するかもしれません。ミラーキャストでディスプレイを表示できるので、Androidクライアントで何とかできるかも。
- Q: 3DSなどの端末にもアプリ提供できるの？
- A: 今のところできません。
- Q: セッション追加の都度起動するけど待たされないの？
- A: 初回起動時だけかかるかもしれません。
- Q: ポート番号を変更できるようになると嬉しいです。
- A: 現時点ではムリです。
- Q: データの転送料等はかかるんですか？
- A: はい。$1.20は、AppStreamだけの値段です。
- Q: ビットストリームの変動にクライアントアプリケーション側で対応する必要があるんでしょうか？
- A: その必要はありません。ただ、ネットワークの帯域やフレームレートは気にしてください。
感想
AppStreamは、実態を全然把握していないサービスだったので、個人的にとても参考になりました。
AWS上で重い処理をセキュアに行い、クライアントアプリケーションではストリームを受け取るだけというのは、クラウドならではのやり方で面白いですね。業種によってさまざまなアイデアが生まれて、使い道が広がりそうなサービスです。
デバッグ用のスタンドアローンモードがあらかじめ用意されている点が良いですね。将来使う時に備えて、ポイントを押さえておこうと思います。
それでは、また。
