flex+aws開発事例 ウェブポfxug.net/archives/study_mtg_100/fxug-webpo.pdf•...
TRANSCRIPT
リプレックスについて• プロフィール
– 総勢12名の小さなベンチャー（開発者9名）– 2006年設立– オフィスは原宿
• 商品– Ripplex アドレス帳 (配布終了)– Ripplex SecuTect™– ウェブポ
• HP– http://www.ripplex.com/
自己紹介• 所属
– リプレックス株式会社 はがき事業部
• 職歴– 研究職（ソフトウェア工学）– 組み込みエンジニア
• LSIベースのHTTPサーバ開発(VHDL,C++,Java)– ソフトウェアエンジニア
• Ripplexアドレス帳(C++,Java)• ウェブポ(AS3,Java)
• 趣味– プログラミング
ウェブポとは• 年賀状印刷のECサイト
– 年賀状の作成・印刷・投函、全てをサポート– 2009年10月ローンチ
利用技術
ウェブポの特徴• 注文から決済までFlashで完結
– ECサイトとしては非常に珍しい
• 完全ウィザード形式– 全画面横スクロールで決済まで完了（世界初？）– 総画面点数は約200（ダイアログ含む）
• Flexアプリケーションとして実装– Flex Builder 3 + Flex SDK 3.2.0– MXMLは使っていません
• アプリケーション定義のMXMLを除く
• ちょっとだけFlashを使用– ボタンなど一部のアニメーション表現にFlashを使用
Flexを選んだ理由• 要求を満たせる開発環境が、Flexしかなかった
– MacでもWinでも動作– インストール不要– ローカルアプリ並みの使いやすさ
• フォント選択可能• 写真貼付可能• 印刷内容のリアルタイムプレビュー
– 洗練された外観
• GWTやJavaScriptは…– 画面描画が遅すぎる
• HTML Canvas, HTML5の普及はまだ先の話– ブラウザ個別対応がつらい
• 先進的なGUIツールキットでもブラウザ間の差異は埋めきれない
View
ウェブポの構造
Flash Player 10.0
Flex SDK 3.2.0
Model Controller
MVC Framework Window ManagerCustom Component
Browser
Application
Helper Functions※
JavaScript Engine
※ブラウザ依存の処理（FlashのアップグレードやMac環境でのホイールマウス対応など）を行うJavaScript関数群
カスタムコンポーネント• デザイナの意図を反映するため、独自のコンポーネントを多数作成
選択要素の位置を基準にして開くドロップダウンボックス
ヘッダ行がスクロールバーの上にはみ出る
ぶち抜き見出し
スムーズスクロールするリストビュー
はがき印刷のリアルタイムプレビュー
FlexとFlashの結合• 高度なアニメーションは、Flash開発者による手付け
– トップ画面全体・点滅するボタン・ナビゲータ
Flex よかったところ• 習得しやすい
– Java, C++エンジニアがスムーズに開発に入れた
– チーム丸ごとFlex未経験だったが、全く問題なし
• 開発環境が安い
• 描画の自由度が極めて高い
– デザイナーの意図をかなり正確に反映できる
• 描画が軽い
– フレームワークレベルで再描画回数をおさえる仕組みがある
– フレームスキップの発生を前提としたエフェクト関数群
• 公式ヘルプがしっかりしている
Flex開発 困ったところ• エラーハンドリング機構が不十分
– Uncaught Exceptionの発生をアプリケーションで監視できない※
• バグやメモリ不足など、重大なエラーを拾うことができない
※Flash Player 10.1で改善されるようです。
AWSとの組み合わせについて
ウェブポのサーバ構成
アプリケーションサーバ
WWWサーバ
ロードバランサー
ロードバランサー
認証サーバ
DB、暗号化などその他もろもろ
サーバ群
Amazon Cloud Front
Amazon EC2 + EBSAmazon ELB
クライアントHTTPS
HTTPS
HTTPS
HTTP
クライアント視点では、ただの性能が良いサーバ（に見えるよう、サーバチームにがんばってもらった）
負荷につよいアプリケーションサーバ
負荷につよいWWWサーバ
負荷につよい認証サーバ
Amazon Cloud Front
Amazon EC2
クライアント
負荷に強くて転送が高速でレイテンシの低いキャッシュサーバ
AWS採択の理由• スケールアウトに適している
– アクセス集中時、すぐにサーバを増やせる
• 安定している
• 初期コストが低い– サーバ購入の初期コスト不要
• 体積ゼロ– 置き場所の悩みなし
• 消費電力ゼロ– 電源の悩みなし
Flex開発者から見たAWS• ごく普通のレンタルサーバ
– Flexアプリ側に特殊な作り込みは不要
• 若干慣れの必要なポイントはあり– ドキュメント類が英語– 独自の管理インタフェース
• 通信レイテンシ・回線速度に注意– ロケーションは基本的に国外– CloudFrontとの組み合わせが有効
通信レイテンシ・速度対策• EC2上にFlexアプリをデプロイすると、アプリの起動（ロード）が遅い
– ウェブポは米国東海岸のサーバを使用
– アクセスレイテンシが長め
• 100～200ms
– 回線速度が遅め
• EC2,S3から配信すると下り80～200KB/s程度
• 対策：Amazon Cloud FrontからFlexアプリを配信
– 日本国内にサーバがあるので遅延が少ない
– 回線速度も下り2.0～3.0MB/sぐらいで安定
Amazon CloudFrontの利用• ウェブポで困ったこと
– Amazon CloudFront は HTTPSに非対応
– ウェブポは HTTPS アクセスが前提
• 図のような構成でうまくいきそうだが…
webpo.jp
Amazon Cloud Front
index.html
Webpo.swfHTTP
<embed>
HTTPS
セキュリティエラーに…webpo.jp
Amazon Cloud Front
index.html
Webpo.swf
HTTPS
HTTP
<embed>
ファイル配置の工夫• Flexアプリをモジュール分割
– ローダ 約307KB
– 本体モジュール 約5MB
– フォントモジュール×3 約2～6MB
• index.htmlとローダをwebpo.jpから配信
• 本体モジュールをAmazon Cloud Fontから配信
• ローダからその他のモジュールを読み込む
webpo.jp※
Amazon Cloud Front
index.html
CoreModule.swf
HTTPS
HTTP
Webpo.swf （ローダ）
<embed>
ローダがその他のモジュールを読みこむ
font1.swffont2.swf
font3.swf
※ピーク時期のwebpo.jpサーバは3台構成。そのうち1台は国内DSに配備。index.htmlの配信レイテンシも下げるため。
CloudFront利用時のデプロイ(1)• ファイルのアップロード先はAmazon s3
– CloudFrontはs3上のコンテンツをキャッシュして配信
– GUIでのアップロードやACL設定はかなり手間
• CloudFrontのキャッシュ更新は1日1回
– S3上のファイルを更新しても、CloudFrontへの反映まで最長1日かかる
– 即時更新したいファイルは、ファイル名にリビジョンを混ぜるなどの工夫
デプロイ作業が非常にめんどくさい
CloudFront利用時のデプロイ(2)• ウェブポでは、シェルスクリプトで自動ビルド＆デプロイ
– シェルは sh– swfのビルドは mxmlc– html-template → htmlコンパイルはsedで文字列置換– EC2へのファイル転送は scp– CloudFront/S3へのファイル転送は s3cmd
• Windows環境からのデプロイはCygwinを利用
AWSを使ってみて• AWSのここがよい
– 気軽に使い始められる– 高いスケーラビリティ
• レイテンシと転送速度がネック– もしEC2が日本国内でサービス開始したら最強では…
• Flex＋AWSの組み合わせは相性が良い– Flexアプリ側の頑張りで、通信量は大幅に減らせる
• ウェブポはFlex+AWSがぴったりフィット– ユーザー作業のほとんどがローカル処理– 通信タイミングはごくわずか
• 起動・写真アップロード・決済・保存
開発スケジュール４ 5 6 7 8 9 10 11 12
要求分析
画面デザイン作成
View実装(Flex)
Model, Controller実装(Flex)
サーバ実装(Java)
12009 2010
画面仕様作成
サイト運用MVC Framework
おわりです
今年もウェブポをよろしくおねがいします