RIAとスマホとクラウドと

クラスメソッド株式会社

自己紹介

• クラスメソッド株式会社

– 2004年設立（第8期目）

–従業員数：約40人

–平均年齢：約32歳

• 横田聡

–クラスメソッド代表取締役

– 1977年生34歳・妻子1人

–東京出まれ東京育ち

今日は主にAWSの技術話をします。

RIA(リッチなUI)とクラウドは相性が良い

RIA+クラウドが実現すること

DB

DB

業務B

業務C 業務A

社内システム

DB

DB

WEB サービス WEB

サービス

WEB サービス

社外サービス

DB

File

デスクトップ

モバイル

デバイス

ブラウザ

インタークラウド

クラウド

業務B

業務C 業務A

仮想化

なぜUIとサーバー側を分けるのか？

ユーザーインタフェース

ロジック / データ

・使い勝手に関する要求は増え続ける。 ・増え続けるクライアント端末に対応。 ・画面サイズに合わせた情報量。

・データ構造やロジックの定義には時間が 掛かるが１回固まれば変化が少ない。 ・データ構造が固まれば次は応答スピード。 ・増加するリクエスト数やデータ量に 対して安定的に応答する構造が必要。

ライフサイクルの違いをAPIで吸収 API

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

良いレスポンスのために

• サービスを止めない – EC2(MultiAZ)

– ELB

– AutoScaling

– CloudWatch

– 自動スナップショット

– RDS(MultiAZ)

• ボトルネックを解消する – リクエスト数を減らす

– ディスクアクセスを減らす

– データベースアクセスを減らす

リクエスト数を減らす（１）

• ファイルをまとめる – CSS/JSを1つのファイルにまとめる。 – CSSによる画像スライスで1ファイルにする。

• 適切な場所に配置 – HTMLの上部にCSS、下部にJSを配置する。 – 動的HTML内でCSS/JSを書かない。外に出す。 – JSライブラリを非同期に読み込む。

• 静的ファイルを全てEBS上に置くと。。。 – HTML,CSS,JS,画像,映像,大容量ファイル等は、

S3かCloudFrontに置くことで、EC2へのリクエスト回数が減ります。

– 多くの場合、ELBを併せて使っていると思いますので、ELBへの負荷も減ります。

ELB/EC2を通らない

Instance

Availability Zone

Instance

Availability Zone

Elastic Load

Balancer

Storage Service / Content Delivery

Amazon CloudFront

Amazon Elastic

Block Storage

(EBS)

Amazon Elastic

Block Storage

(EBS)

Amazon Simple

Storage Service

(S3)

リクエスト数を減らす（２）

• S3に静的ファイルを置くときに気をつける – HTML,CSS,JSはgzip圧縮してから置きます。 – 画像はExpires Cache-Control を長めに設定

• S3とCloudFrontどっちに置く？ – S3はストレージサービス。長期保存用。 東京リージョンに置けばそこそこスピードが出るが、高速にデータをダウンロードしたければCloudFront

– アクセス制限を付与したい場合はS3。 認証付きURLならCloudFront/S3

– CloudFrontのエッジロケーションが大阪にもできた。ネットワーク遅延を解消するため効果が大きい。

– CloudFrontはS3 Originのヘッダを引き継ぐため、キャッシュや圧縮が有効であれば引き継ぐ。 コスト面でのメリットが非常に大きい！

S3/CloudFrontを賢く使う

Amazon CloudFront

Edge Location

Edge Location

Amazon Simple

Storage Service

(S3)

Instance

Amazon Elastic

Block Storage

(EBS)

東京

大阪

S3/CloudFrontへの配備

• 手作業はめんどくさい

–キャッシュ設定

– Gzip圧縮

–アップロード

–公開設定

–アクセス制限

• ビルドツールの活用

– Ant

– S3cmd

– S3sync

リクエスト数を減らす（３）

• Webサーバで自動生成されるページのHTMLを修正できない場合

– Apache/nginx等のUrlRewriteを使って304転送

• 全て静的なWebページの場合

– CloudFrontのカスタム Originを設定する。CloudFrontのURLにドメイン名を指定すれば完了。

– DNSレコード情報の反映スピード大事。 Route 53はマストツールです。

– クロスドメイン問題があるので注意が必要。別サーバから動的データを取得する方法を考える。JSONP、マテリアライズドビュー（検索済み）

HTMLを修正できない場合

Amazon CloudFront

Amazon Simple

Storage Service

(S3)

Instance

Amazon Elastic

Block Storage

(EBS)

東京

304転送

ディスクアクセスを減らす（１）

• EC2とEBSはネットワークで繋がれています – インスタンスサイズが大きいと割り当てられるネットワーク帯域が太くなります。

– ネットワーク帯域をたくさん使ってしまうと応答が遅くなります。

– EBSはディスクですのでIOが大量に発生すると遅くなります。

• ログを大量に吐き出していませんでしょうか。 – サービス系は常に改善のため本番時にもデバッグログを出し続けていることもしばしば

– ディスクへの書き込みを減らす

– ログはログサーバ(Fluentd等)を経由してS3へ

ディスクアクセスを減らす（２）

• ディスクアクセスを高速化したい場合 –大きいEC2インスタンスを使う

– RAID0を組む • 2つのEBSボリュームをマウント

• MdadmでRAID0化

• EBSを使わずにEphemeral Diskを使う – EC2インスタンスの再起動でデータは消えるがネットワークを介さないので高速

– EC2インスタンスを分散処理用に使って、一時データを保存しておきたい場合に有効

–ランダムリード/ライトならEBSが良い。

– EMRでも使われている。

データベースアクセスを減らす（１）

• とりあえず負荷を減らす方法

–リードレプリカを用いる

• 検索と更新を分ける

–シャーディングを用いる

– RDSのインスタンスタイプを上げる

• SmallからLargeとか

• 増え続けるアクセスに対して 根本的な解決にはならない。

データベースは何を管理するか？

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

DBは ボトルネック

ボトルネックは明らか

Instance

Amazon Relational

Database Service

(RDS)

全ての負荷がDBに 掛ってくる

ユーザからの アクセスに対して

ボトルネックを解消

Instance

Amazon Relational

Database Service

(RDS)

Amazon Simple

Storage Service

(S3)

Amazon CloudFront

Amazon

ElastiCache

Amazon SimpleDB

Amazon DynamoDB

Amazon Elastic

Block Storage

(EBS)

Amazon Simple

Workflow Service

(SWF)

Amazon Simple

Queue Service (SQS)

SPOF（単一障害点）の無いAWSサービス群

• サービスそのものが高可用性 – DynamoDB / SimpleDB – S3 / CloudFront – SQS / SES / SWF / SNS – EMR – IAM – CloudWatch – Route 53 – ELB / AutoScaling

• MultiAZ指定/多重化で高可用性 – RDS – EC2 / VPC – ElastiCache – DirectConnect

データベースアクセスを減らす（２）

• データベースへの問い合わせ回数を減らす

–キャッシュ機構を使う

• ElastiCache

–データベース(RDBMS)を使わない

• DynamoDB

–複雑な問合せが必要な場合にはやっぱり

• RDS

–操作ログや履歴は後で加工する

• S3

–カラムが動的なメタデータ

• SimpleDB

ElastiCacheを使う

Instance

ElastiCache

Cache Node

ElastiCache

Cache Node

Cluster

Availability Zone

Amazon Relational

Database Service

(RDS)

Instance

ElastiCache

Cache Node

ElastiCache

Cache Node

Cluster

Availability Zone

Elastic Load

Balancer

DynamoDB/SimpleDB を使う

Instance

Availability Zone

Amazon Relational

Database Service

(RDS)

Instance

Availability Zone

Elastic Load

Balancer

Amazon DynamoDB

Database Service

Amazon SimpleDB

DynamoDBの特徴

• IOPS指定

• APIアクセス

• 一貫性指定、Atomic カウンタ

• 高可用性・耐障害性 – 同期レプリケーション

• 条件付きアップデート

• 専門家いらず

• メンテナンスいらず

• チューニングいらず

こんな症状に良く効きます

• チケット予約・座席予約

–同時に複数のユーザが参照して更新

• 数量限定の商品販売

–カウンターが減っていく/増えていく

• ソーシャルゲームのステータス(HP/MP)

–頻繁に値が変更される協力プレイ

• HTTPセッション管理

–消えたら困る一時データ

適材適所にデータを保存

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

まとめ

RIAとスマホの話が無い（汗）

まとめ

• データサイズを小さくする

• 通信回数を少なくする

• 読み込むタイミングを計る

• できるだけキャッシュする

• S3/CloudFrontでコンテンツ配信する

• ELB/EC2へのアクセス数を減らす

• ディスクへのアクセス数を減らす

• データベースへのアクセス数を減らす

• SPOFの無いAWSサービス群を活用