1. RIAとスマホとクラウドと
クラスメソッド株式会社

2. 自己紹介
• クラスメソッド株式会社
– 2004年設立（第8期目）
– 従業員数：約40人
– 平均年齢：約32歳
• 横田聡
– クラスメソッド代表取締役
– 1977年生34歳・妻子1人
– 東京出まれ東京育ち

3. 今日は主にAWSの技術話をします。
RIA(リッチなUI)とクラウドは相性が良い

4. RIA+クラウドが実現すること
ブラウザ 社内システム
業務B DB
業務A
業務C DB
デスクトップ 社外サービス
WEB
File サービス DB
WEB
サービス WEB
DB サービス DB
モバイル クラウド
業務B
業務A 業務C
仮想化
デバイス インタークラウド

5. なぜUIとサーバー側を分けるのか？
ユーザーイン ・使い勝手に関する要求は増え続ける。
タフェース ・増え続けるクライアント端末に対応。
・画面サイズに合わせた情報量。
ライフサイクルの違いをAPIで吸収
API
・データ構造やロジックの定義には時間が
ロジック 掛かるが１回固まれば変化が少ない。
・データ構造が固まれば次は応答スピード。
/ データ ・増加するリクエスト数やデータ量に
対して安定的に応答する構造が必要。

6. 良いアプリには良いレスポンスが必要です

7. 良いレスポンスのために
• サービスを止めない
– EC2(MultiAZ)
– ELB
– AutoScaling
– CloudWatch
– 自動スナップショット
– RDS(MultiAZ)
• ボトルネックを解消する
– リクエスト数を減らす
– ディスクアクセスを減らす
– データベースアクセスを減らす

8. リクエスト数を減らす（１）
• ファイルをまとめる
– CSS/JSを1つのファイルにまとめる。
– CSSによる画像スライスで1ファイルにする。
• 適切な場所に配置
– HTMLの上部にCSS、下部にJSを配置する。
– 動的HTML内でCSS/JSを書かない。外に出す。
– JSライブラリを非同期に読み込む。
• 静的ファイルを全てEBS上に置くと。。。
– HTML,CSS,JS,画像,映像,大容量ファイル等は、
S3かCloudFrontに置くことで、EC2へのリクエスト
回数が減ります。
– 多くの場合、ELBを併せて使っていると思いますの
で、ELBへの負荷も減ります。

9. ELB/EC2を通らない
Elastic Load
Balancer
Instance Instance
Amazon Elastic
Amazon Elastic Block Storage
Block Storage (EBS)
(EBS)
Availability Zone Availability Zone
Amazon Simple
Amazon CloudFront Storage Service
(S3)
Storage Service / Content Delivery

10. リクエスト数を減らす（２）
• S3に静的ファイルを置くときに気をつける
– HTML,CSS,JSはgzip圧縮してから置きます。
– 画像はExpires Cache-Control を長めに設定
• S3とCloudFrontどっちに置く？
– S3はストレージサービス。長期保存用。
東京リージョンに置けばそこそこスピードが出るが、
高速にデータをダウンロードしたければCloudFront
– アクセス制限を付与したい場合はS3。
認証付きURLならCloudFront/S3
– CloudFrontのエッジロケーションが大阪にもできた。
ネットワーク遅延を解消するため効果が大きい。
– CloudFrontはS3 Originのヘッダを引き継ぐため、
キャッシュや圧縮が有効であれば引き継ぐ。
コスト面でのメリットが非常に大きい！

11. S3/CloudFrontを賢く使う
東京
Edge Location
Amazon Simple
Amazon CloudFront Storage Service Instance
(S3)
Amazon Elastic
Block Storage
(EBS)
Edge Location
大阪

12. S3/CloudFrontへの配備
• 手作業はめんどくさい
– キャッシュ設定
– Gzip圧縮
– アップロード
– 公開設定
– アクセス制限
• ビルドツールの活用
– Ant
– S3cmd
– S3sync

13. リクエスト数を減らす（３）
• Webサーバで自動生成されるページのHTMLを
修正できない場合
– Apache/nginx等のUrlRewriteを使って304転送
• 全て静的なWebページの場合
– CloudFrontのカスタム Originを設定する。
CloudFrontのURLにドメイン名を指定すれば完了。
– DNSレコード情報の反映スピード大事。
Route 53はマストツールです。
– クロスドメイン問題があるので注意が必要。別サー
バから動的データを取得する方法を考える。JSONP、
マテリアライズドビュー（検索済み）

14. HTMLを修正できない場合
東京 Instance
Amazon Elastic
Block Storage
(EBS)
304転送
Amazon Simple
Amazon CloudFront Storage Service
(S3)

15. ディスクアクセスを減らす（１）
• EC2とEBSはネットワークで繋がれています
– インスタンスサイズが大きいと割り当てられるネッ
トワーク帯域が太くなります。
– ネットワーク帯域をたくさん使ってしまうと応答が
遅くなります。
– EBSはディスクですのでIOが大量に発生すると遅く
なります。
• ログを大量に吐き出していませんでしょうか。
– サービス系は常に改善のため本番時にもデバッグロ
グを出し続けていることもしばしば
– ディスクへの書き込みを減らす
– ログはログサーバ(Fluentd等)を経由してS3へ

16. ディスクアクセスを減らす（２）
• ディスクアクセスを高速化したい場合
– 大きいEC2インスタンスを使う
– RAID0を組む
• 2つのEBSボリュームをマウント
• MdadmでRAID0化
• EBSを使わずにEphemeral Diskを使う
– EC2インスタンスの再起動でデータは消えるが
ネットワークを介さないので高速
– EC2インスタンスを分散処理用に使って、一時
データを保存しておきたい場合に有効
– ランダムリード/ライトならEBSが良い。
– EMRでも使われている。

17. データベースアクセスを減らす（１）
• とりあえず負荷を減らす方法
– リードレプリカを用いる
• 検索と更新を分ける
– シャーディングを用いる
– RDSのインスタンスタイプを上げる
• SmallからLargeとか
• 増え続けるアクセスに対して
根本的な解決にはならない。

18. データベースは何を管理するか？
• データベースに何でも入れてしまう傾向
– マスタデータ
– 関係データ
– トランザクション
– 更新履歴
– 操作ログ
– 一時データ
– セッション
– メタデータ
– キャッシュ DBは
– ビジネスステータス ボトルネック
– バイナリデータ（画像、音声）

19. ボトルネックは明らか
ユーザからの
アクセスに対して
Instance
全ての負荷がDBに
掛ってくる
Amazon Relational
Database Service
(RDS)

20. ボトルネックを解消
Amazon Simple
Amazon SimpleDB
Storage Service
(S3)
Instance
Amazon DynamoDB
Amazon CloudFront
Amazon Elastic
Amazon Block Storage
ElastiCache Amazon Simple (EBS)
Queue Service (SQS)
Amazon Simple
Workflow Service Amazon Relational
(SWF) Database Service
(RDS)

21. SPOF（単一障害点）の無いAWSサービス群
• サービスそのものが高可用性
– DynamoDB / SimpleDB
– S3 / CloudFront
– SQS / SES / SWF / SNS
– EMR
– IAM
– CloudWatch
– Route 53
– ELB / AutoScaling
• MultiAZ指定/多重化で高可用性
– RDS
– EC2 / VPC
– ElastiCache
– DirectConnect

22. データベースアクセスを減らす（２）
• データベースへの問い合わせ回数を減らす
– キャッシュ機構を使う
• ElastiCache
– データベース(RDBMS)を使わない
• DynamoDB
– 複雑な問合せが必要な場合にはやっぱり
• RDS
– 操作ログや履歴は後で加工する
• S3
– カラムが動的なメタデータ
• SimpleDB

23. ElastiCacheを使う
Elastic Load
Balancer
Instance Instance
Amazon Relational
ElastiCache ElastiCache ElastiCache ElastiCache
Database Service
Cache Node Cache Node Cache Node Cache Node
(RDS)
Cluster Cluster
Availability Zone Availability Zone

24. DynamoDB/SimpleDB を使う
Elastic Load
Balancer
Instance Instance
Amazon Relational
Database Service
Availability Zone (RDS) Availability Zone
Amazon DynamoDB Amazon SimpleDB
Database Service

25. DynamoDBの特徴
• IOPS指定
• APIアクセス
• 一貫性指定、Atomic カウンタ
• 高可用性・耐障害性
– 同期レプリケーション
• 条件付きアップデート
• 専門家いらず
• メンテナンスいらず
• チューニングいらず

26. こんな症状に良く効きます
• チケット予約・座席予約
– 同時に複数のユーザが参照して更新
• 数量限定の商品販売
– カウンターが減っていく/増えていく
• ソーシャルゲームのステータス(HP/MP)
– 頻繁に値が変更される協力プレイ
• HTTPセッション管理
– 消えたら困る一時データ

27. 適材適所にデータを保存
• データベースへの負荷を減らす
– マスタデータ ⇒ RDS
– 関係データ ⇒ RDS
– トランザクション ⇒ RDS/DynamoDB
– 更新履歴 ⇒ RDS/S3
– 操作ログ ⇒ S3
– 一時データ ⇒ DynamoDB
– セッション ⇒ DynamoDB
– メタデータ ⇒ SimpleDB
– キャッシュ ⇒ ElastiCache
– ビジネスステータス ⇒ SQS/SWF
– バイナリデータ（画像、音声） ⇒ CloudFront

28. まとめ
RIAとスマホの話が無い（汗）

29. まとめ
• データサイズを小さくする
• 通信回数を少なくする
• 読み込むタイミングを計る
• できるだけキャッシュする
• S3/CloudFrontでコンテンツ配信する
• ELB/EC2へのアクセス数を減らす
• ディスクへのアクセス数を減らす
• データベースへのアクセス数を減らす
• SPOFの無いAWSサービス群を活用