お初です。三浦と申します。
アラサーです。
お仕事は出版社システムLEADの開発チームのマネジメントをやっております。
LEADとは
導入実績300社以上！出版業界の商習慣に合わせた、出版社様向けの販売管理システムです。
詳細機能に関してはこちら。
サブスクリプション提供の通常版の他、安価な機能限定版としてBasic版を用意しております。
ご興味ある方は弊社営業までお気軽にお問合せください！
〜〜以上、CM〜〜
LEADのプラットフォーム
LEADはDBサーバとクライアントのアプリケーションで構成される、所謂「クライアントサーバシステム」です。DBを端末にインストールしてしまえばオフラインでも利用可能だったりとメリットもあるのですが、最近では手軽に利用開始できるSaaS型で提供しているサービスが増えてますよね。
? ＜もっと手軽に出版社のみなさんに使ってもらいたいなー！
? ＜SaaSみたいな感じで提供できないかなー！
? ＜でも作り直すなんて大変だしなー。。
社内でぼやき散らしていたところ、Amazon AppStream 2.0というサービスを紹介いただき、なんだか面白そうなのでとりあえずやってみることにしました。
前置きが長くなりましたが、今回の本題は「デスクトップアプリケーションをブラウザで動かすお話」です。
それでは、ここからは実際にトライしてくれたヤングメンにバトンタッチしたいと思います。
Amazon AppStream 2.0とは
はじめまして。川畑です。
こんにちは！大桃です。
今回の記事ではAppStreamを使ってLEAD(windowsのデスクトップアプリケーション)をブラウザで動かしてみよう！それを配信してみよう！という検証です。（AWS未経験のプログラマーによる検証です。）
そもそもAppStreamって何かしら？というと、AppStreamの公式では以下の様に説明されています。
Amazon AppStream 2.0 は、どこからでも即座にデスクトップアプリケーションにアクセスすることができる、フルマネージド型のアプリケーションストリーミングサービスです。AppStream 2.0 は、アプリケーションをホストして実行するために必要な AWS リソースを管理します。また、自動的にスケーリングし、ユーザーにオンデマンドでアクセスを提供します。
つまり、デスクトップアプリを簡単にSaaSっぽく配信できる便利なサービスのようですね。それではAppStreamでLEADを配信してみたいと思います！
検証の流れ
- サーバーの構成
- 設定手順解説
- 動かしてみた！
- 課題
1. サーバーの構成
※今回の調査に当たり、20170906 AWS BlackBelt AppStream2の資料をかなり参考にさせて頂きました。
LEADはDBとデスクトップアプリケーションで構成されています。
今回はアプリケーションを配信するAppStreamとは別にEC2でインスタンスを用意してDBサーバを立てています。
2. 設定手順解説
配信までの手順フローは以下のイメージです。
※ログイン後東京リージョンであることを確認してからインスタンスを作成しましょう。
なぜか途中までシドニーリージョンで作成していた我々からの助言です。
1. EC2の設定
EC2にSQL Server2016をインストールし、時刻を日本時間に合わせました。
2. イメージビルダー
イメージビルダー・・・配信するアプリの元ネタを用意する環境。
LEADのデスクトップアプリをイメージビルダー上にインストールします。
・EC2上に構築したDBサーバーへの接続定義を変更
通常はSQL Serverのインスタンス名で接続しておりますが、今回は少し異なります。
App Stream上のアプリケーションとEC2上のDBサーバで通信ができるよう、EC2のセキュリティグループでTCP1433（MS SQLの規定ポート）の許可設定をしているのですが、これはSQL Serverが規定のインスタンスの場合。名前付きインスタンスの場合には動的ポートが使用されます。
設定で変更は可能ですが、とりあえず今回の検証目的とは関係ないのでSQL Serverのインスタンス名を指定せず、TCP1433で接続することにしました。
・日本語化→ 画面表示を日本語化し、EC2と同様に時刻を日本時間に合わせました。
3. イメージの設定
イメージ・・・イメージビルダーで作成した配信アプリのスナップショット。
Image Registryに作成したイメージができていることを確認。
4. フリートの設定
フリート・・・配信するイメージを実行するインスタンス。
基本的にはデフォルト値のまま、作成しました。別途選択した項目のみ記します。
Step 1: Provide Fleet Details
Step 2: Choose an Image
Step 3: Configure Fleet
- Choose instance type
- Fleet Type details
オンデマンドか常時稼働かを選択。本検証ではオンデマンドを選択。
Step 4: Configure Network
Step 5: Review
5. スタックの設定
スタック・・・指定したフリート、ユーザーアクセスポリシー、ストレージ設定で構成されるユーザー向け環境。
Step 1: Stack Details
Step 2: Enable Storage
Step 3: User Settings
Step 4: Review
スタック作成後、USER POOLよりユーザーを登録します。
3. 動かしてみた！
アサインされたユーザーのもとにメールが飛んできます。
URLからAppStreamにアクセス。
ログインすると、現在アサインされているスタックが一覧で表示されます。
※川畑は絶賛検証途中のため、複数のスタックが表示されています。
スタックをクリックすると、スタックに含まれているイメージの一覧が表示されます。
イメージ作成におよそ2分ほど掛かります。待ちます。
LEADが表示され、ログインできることが確認できました！！
画面での確認以外にも、CloudWatchからメトリクスを確認できます。
4. 課題
実際配信をしてみてわかった、大きな課題は以下の通りです。
・印刷しにくい
AppStreamの画面から直接ファイルを印刷することはできません。
一旦PDF化を挟む必要があるため、少し手間です。
ActiveDirectoryを設定することで直接印刷することもできるようですが、
不特定多数の出版社向けに配信することを想定すると、すべての環境にADを設定していくのはあまり現実的でないです。
・ログイン後待ち時間が発生する
今回用意した環境の場合、ログインに最大2分程度の待ち時間が発生してしまいます。
※サーバースペックを向上させたり、より軽いアプリの配信であれば時間短縮できるかもです。
・イメージ、フリートの作成に時間がかかる
イメージ、フリート、スタックともに作成はとても簡単かつ直感的ですが、
それぞれの工程で待ち時間が発生してしまいます(計1~2時間)。度重なるPending
配信するアプリの仕様変更などで大量のイメージ、フリートを修正したい場合は少し面倒かもしれません。
その他にも、同時使用可能ユーザー数に応じて、適切なキャパシティの設定を考慮しなければならないことや、それに伴うセキュリティ問題など、お客様向けにアプリケーションを配信するためにはいくつか課題があることが分かりました。
別途調査が必要な項目も多く、実業務ですぐ使えるレベルを達成するには、もう少し調査や対応が必要ですね。
さいごに
いくつか課題は残りますが、当初の目的であるデスクトップアプリケーションをブラウザ配信することができました！スケーリングも比較的容易にできると学べたことは大きな収穫です。
また、デスクトップアプリケーションがブラウザで配信可能となることで、新規のお客様でもトライアルやデモをすぐに試すことが出来る点はAppStreamのメリットな気がしました。
また、社外のお客様向けよりも、社内アプリケーションの配信用途の方が活用シーンが多いかもしれません。
今回の検証を通し、プログラマーもインフラ構築について知識を深めていく必要性を実感しました。「目的」と「手段」を混同してはいけませんが、「やりたい」を実現するための手段の情報収集・トライアルはこれからも積極的に実施していきたいと思います。
以上です！
少々無理やりではありますが、この辺で終わりにしようと思います。
最後までお付き合いいただきありがとうございました！