スライド 1

Flex+AWS開発事例
ウェブポ
リプレックス株式会社
岡﨑光隆
([email protected])
リプレックスについて
• プロフィール
– 総勢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ツールキットでもブラウザ間の差異は埋めきれない
ウェブポの構造
Application
Model
Controller
MVC Framework
View
Custom
Component
Window Manager
Flex SDK 3.2.0
Flash Player 10.0
Helper Functions※
Browser
JavaScript Engine
※ブラウザ依存の処理（FlashのアップグレードやMac環境でのホイールマウス対応など）を行うJavaScript関数群
カスタムコンポーネント
• デザイナの意図を反映するため、独自のコンポーネントを多数作成
選択要素の位置を基準にして開く
ドロップダウンボックス
スムーズスクロールするリストビュー
ヘッダ行が
スクロールバー
の上にはみ出る
ぶち抜き見出し
はがき印刷のリアルタイムプレビュー
FlexとFlashの結合
• 高度なアニメーションは、Flash開発者による手付け
– トップ画面全体・点滅するボタン・ナビゲータ
Flex よかったところ
•
習得しやすい
– Java, C++エンジニアがスムーズに開発に入れた
– チーム丸ごとFlex未経験だったが、全く問題なし
•
開発環境が安い
•
描画の自由度が極めて高い
– デザイナーの意図をかなり正確に反映できる
•
描画が軽い
– フレームワークレベルで再描画回数をおさえる仕組みがある
– フレームスキップの発生を前提としたエフェクト関数群
•
公式ヘルプがしっかりしている
Flex開発困ったところ
•
エラーハンドリング機構が不十分
– Uncaught Exceptionの発生をアプリケーションで監視できない※
• バグやメモリ不足など、重大なエラーを拾うことができない
※Flash Player 10.1で改善されるようです。
AWSとの組み合わせについて
ウェブポのサーバ構成
Amazon ELB
ロードバランサー
Amazon EC2 + EBS
認証サーバ
HTTPS
クライアント
ロードバランサー
HTTPS
DB、暗号化など
その他もろもろ
サーバ群
HTTPS
WWWサーバ
Amazon Cloud Front
HTTP
アプリケーションサーバ
クライアント視点では、ただの性能が良いサーバ
（に見えるよう、サーバチームにがんばってもらった）
Amazon EC2
負荷につよい認証サーバ
クライアント
負荷につよいアプリケーションサーバ
負荷につよいWWWサーバ
Amazon Cloud Front
負荷に強くて
転送が高速で
レイテンシの低いキャッシュサーバ
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
index.html
HTTPS
<embed>
Webpo.swf
HTTP
Amazon Cloud Front
セキュリティエラーに…
webpo.jp
index.html
HTTPS
<embed>
Webpo.swf
HTTP
Amazon Cloud Front
ファイル配置の工夫
•
Flexアプリをモジュール分割
–
ローダ
約307KB
–
本体モジュール
約5MB
–
フォントモジュール×3
約2～6MB
•
index.htmlとローダをwebpo.jpから配信
•
本体モジュールをAmazon Cloud Fontから配信
•
ローダからその他のモジュールを読み込む
webpo.jp※
index.html
<embed>
Webpo.swf （ローダ）
HTTPS
ローダがその他のモジュールを読みこむ
HTTP
Amazon Cloud Front
CoreModule.swf
font1.swf
font2.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
2009
8
9
10
11
12
画面デザイン作成
要求分析
画面仕様作成
MVC
Framework
View実装(Flex)
Model, Controller実装(Flex)
サーバ実装(Java)
サイト運用
2010
1
おわりです
今年もウェブポを
よろしくおねがいします

Download Report