ENGINEER BLOG

ENGINEER BLOG

AppStream2.0でデスクトップアプリのブラウザ対応を更に検討してみる

こんにちは。ソリューションC&I本部の大桃です。

「デスクトップアプリをSaaSっぽく提供したい」という欲求を発端に、1年程前にたのしいAppStream2.0 ~デスクトップアプリをブラウザでいじる~という記事を書きました。

前回の記事ではAWS AppStream2.0で弊社のパッケージシステム「出版社システムLEAD」(https://www.techceed-inc.com/solution/lead/)を動かすまでのお話でしたが、今回はもう一歩踏み込んでAppStreamを利用する上で検討すべき事について具体的に記載していきます。

1. 今回の記事を書くことになったきっかけ

以前投稿した、たのしいAppStream2.0 ~デスクトップアプリをブラウザでいじる~の記事をご覧になったAWSご担当者様からなんとコンタクトをいただき、協力してLEADのAppStreamでの展開をより具体的に検討させていただくこととなりました。感謝。

前回の記事では、LEADをAppStreamで配信するにあたり、

  • ログイン後待ち時間が発生する
  • イメージ、フリートの作成に時間がかかる
  • 印刷がしにくい

といった主に3つの課題があることを記載していました。
AWSのご担当者様との打合せでは、これらの課題への対処方法を中心に様々なアドバイスをいただきました。

またその他の課題や、便利な点についての理解も深まったため、今後デスクトップアプリをAppStreamで配信することを検討している方に向け、特に重要になるであろうことについて列挙していきます。

image1

※上記は、ブラウザ上でデスクトップアプリの出版社システムLEADを表示している様子

2. 主な3つの課題

まず、前回の記事で記載した、LEADをAppStreamで配信する場合の課題と対応についてです。

① ログイン後待ち時間が発生するという課題

セッションがない状態、以前のストリーミングセッションがアクティブでない状態でログインすると2分弱の待ち時間が発生します。

image2

※ログインのインスタンスの起動を待っている時の画面

デフォルトではMaximum session 960 minutesでストリーミングセッションを維持できる最大時間が16時間となっているため、これを超えるとセッションが必ず切れます。そのため、毎日アプリの使用を開始するタイミングでおよそ2分の待ち時間が発生してしまい、少々不便です。(2人以上同時にアプリを利用する場合、2人目以降も新規セッションとなるため、2分弱の待ち時間が発生します)
また、Disconnect timeout in minutes が過ぎると以前接続されていたセッションが維持されず、新しいセッションに接続することになりこの待ち時間が発生します。

■ 対応策
オンデマンドフリートインスタンス(利用時間単位で課金)ではなく、常時稼働フリートインスタンス(利用状況に関係なく課金)を利用することで、待ち時間をなくすことが出来ます。
そして以前のセッション維持の時間 Disconnect timeout in minutes を長めに取る事で、ネットワークの問題等で切断してしまったユーザーの再接続時の待ち時間を減らすことが可能だと思われます。
ただ常時稼働の方が費用がかかりますし、セッションを維持している時間はインスタンス使用料がかかるため、費用と利便性のどちらを取るか要検討です。

② イメージ、フリートの作成に時間がかかるという課題

1からAppStreamでLEADを配信しようとした際、インスタンス作成の待ち時間などで、合計2~3時間ほどかかりました。

そのため、アプリの機能追加やバグ修正プログラムを、一斉にユーザー環境へ適用したい場合、インスタンス修正にかなり時間を要してしまいます。

■ 対応策
CLIやLambdaを利用し、ある程度作業を自動化することが可能です。
もしアプリのバージョンアップをユーザーに影響を与えず簡単に、一斉にできるようになれば、開発側・ユーザー側双方にとって大きなメリットになるのではないでしょうか。

③ 印刷しにくいという課題

AppStreamで配信されたアプリからは、ローカルのプリンターへ直接印刷をすることができません。
そのため、アプリ上で一度PDF化したのち、ローカルのプリンターから出力するというひと手間が増えてしまいます。

■ 対応策
ADの設定を連携することで、ローカルのプリンターで直接印刷することも可能です。

しかし、ADを1社1社に設定していくのは考慮すべき点が多くハードルが高い作業です。
特にLEADのように日常的に帳票印刷(納品伝票や請求書)を行うアプリでは、印刷時のひと手間を許容できるかどうか検討する必要があります。

3. その他、デスクトップアプリをAppStreamでSaaS化する際の課題とメリット

先ほど記載した3つの課題に加え、他のいくつかの課題と、またAppStreamを利用することでデスクトップアプリより便利になる点について記載していきます。

課題

コスト

AppStreamを利用する場合、デスクトップアプリにはないコストを想定する必要があります。
例えば、アプリを配信するためのコストやAWS上にDBを保持するためのコストがかかります。

コストを抑えるための方法として、以下のような対応が考えられます。

  • 従量課金のインスタンスを利用し起動時間を減らす運用(月末に一気にデータ入力など)にする
  • リザーブドインスタンスを長期契約することで割引を利用する
  • アプリの維持費が安価になるように変更していく(SQL ServerからMySQLに移行するなど)

ファイルの入出力

ファイルの入出力もローカルと直接連動することができないため、一度S3を介し、データの入出力をする必要があります。

アナログ回線の利用

新出版ネットワークという出版業界のEDIサービスにLEADは対応しております。ただし利用のためにはアナログ回線が必要になるのですが、AppStreamではアナログ回線を用いた通信には対応していません。アナログ回線廃止に伴い、EDIサービスがIP対応されれば対応は可能になると思います。

メリット

クライアント環境の多様化

ブラウザでの利用が可能なため、PC環境に関係なくアプリを利用することが出来ます。
例えば、これまで.NETのバージョンに依存していたアプリや、Windowsのみで動作していたアプリをMacで動かすことが出来ます。
※対応ブラウザ一覧:https://clients.amazonappstream.com/

利用人数

ブラウザでアクセスするだけでアプリを利用でき、また同時使用可能なユーザー数の設定も個別に行えるため、より柔軟にアプリを利用できるようになります。

操作感

クライアントのOSがWindowsの場合、モーダル(Windows Client)でアプリを動かすことができるため、デスクトップアプリと変わらない操作感で利用することが出来ます。

体験版の作成

webでアプリを利用できるため、体験版をwebで公開し気軽にアプリに触れる環境を作ることが出来ます。

例えば、AWSのアカウントがある方は、こちらからサンプルのアプリを動かしてみることが出来ます。

プログラムの修正が一切必要ない

AppStreamでは、デスクトップアプリのプログラムに一切手を加えず、SaaS化しwebで配信することが出来ます。
(少なくともLEADではプログラムの修正は必要ありませんでした)

4. さいごに

弊社の出版社システムLEADは伝票を発行することが大きな目的のひとつであり、ほぼ毎日のように伝票入力・印刷を行っているお客様がほとんどです。紙の印刷に関する制約や業界独自のEDIへの対応が難しかったりと、LEADはAppStreamでの展開には不向きな面があります。
ただし、今後よりペーパーレス化を推進することができれば可能性はぐっと広がります。

実際に使ってみた所感ですが、AppStreamが真価を発揮できるケースとしては「新たなサービスのSaaS展開」や「ソフトウェアのトライアル環境の構築」、「社内のアプリケーションの集中管理」等が適していると感じました。また、仕事や教育現場のリモート化が加速している昨今、自宅にいながら業務や勉強を行うためのツール配信手段としても非常に有効だと思います。

AppStream2.0を用いたアプリケーション配信にご興味がある方は、お気軽にお問合せください。AWS担当者と連携してご相談にのらせていただきます。

また、開発側としてAppStream2.0の利用を検討されている方は、直接AWSの方にコンタクトを取ってみるのも良いと思います。
私は直接AppStreamの技術担当の方とお話しすることで、具体的なユースケースなどをイメージすることが出来ました。(非常に丁寧にアドバイスして頂きました)
※アマゾン ウェブ サービス ジャパンのご担当者様の連絡先:tsshiban@amazon.co.jp

以上です!
最後までお付き合いいただきありがとうございました!