「AWS Black Belt Tech Webinar 2014 – Amazon AppStream」レポート

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、虎塚です。

先週水曜のAWS Black Belt Tech Webinarを聴講しましたので、レポートします。今回のテーマは、AppStreamで、講師はアマゾンデータサービスジャパンの榎並さんです。

※すでに公式のWebinar資料が公開されていますので、お時間のある方はそちらをご覧いただければと思います。

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つ。

  1. ストリーミングアプリケーション: お客様が配信したいアプリケーション
  2. クライアントアプリケーション: ビューワー(スマフォ、タブレット、PCなどの上で実行される)
  3. 認証サービス
  4. AppStreamホスト: 利用するEC2はg2.2xlarge. 15GBのメモリと8vCPUでグラフィック処理に特化できる
  5. 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で、ストリーミングアプリケーションをデバッグできる。

ストリーミングアプリケーションのビルド

ストリーミングアプリケーションをAppStreamにインストールするという作業を自動で行うため、サイレントインストーラ(*.exe)を実装する必要がある。*.msi, *.bat, *.zipファイルは使用できないことに注意する。

クライアントアプリケーション開発

ビューワ側の開発について説明する。

クライアントアプリケーションの設計上の注意

アプリケーションとクライアントの解像度が異なる場合がある
ビットマップをピクセル単位で編集するような高精度な入力が必要な場合、考慮が必要
複数の入力イベントがある場合の挙動について、仕様を考慮すること
さまざまなインプット方法に対応するか、1種類のインプットしか許容しないか

クライアントOSごとのビルド

開発者ガイドを参照する。

コーデックとオープンソースライセンス

AppStreamでは、H.264/AVCフォーマットと、Opus音声フォーマットを利用している。クライアントアプリにH.264/AVCデコーダを含める必要があるが、デコーダのライセンスにアプリケーション配布側の責任で準拠するよう注意する。

デプロイと管理

ストリーミングアプリケーションのデプロイ

スタンドアロンモードでテストした後、ストリーミングアプリケーションをManagement Consoleからデプロイできる。

  1. サイレントインストーラをS3に格納する
  2. 署名付きURLを取得する
  3. 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上で重い処理をセキュアに行い、クライアントアプリケーションではストリームを受け取るだけというのは、クラウドならではのやり方で面白いですね。業種によってさまざまなアイデアが生まれて、使い道が広がりそうなサービスです。

デバッグ用のスタンドアローンモードがあらかじめ用意されている点が良いですね。将来使う時に備えて、ポイントを押さえておこうと思います。

それでは、また。