RIAとスマホとクラウドとクラスメソッド株式会社
自己紹介• クラスメソッド株式会社 – 2004年設立(第8期目) – 従業員数:約40人 – 平均年齢:約32歳• 横田聡 – クラスメソッド代表取締役 – 1977年生34歳・妻子1人 – 東京出まれ東京育ち
今日は主にAWSの技術話をします。RIA(リッチなUI)とクラウドは相性が良い
RIA+クラウドが実現すること   ブラウザ      社内システム                        業務B          DB              業務A                        業務C     ...
なぜUIとサーバー側を分けるのか?ユーザーイン   ・使い勝手に関する要求は増え続ける。 タフェース   ・増え続けるクライアント端末に対応。         ・画面サイズに合わせた情報量。          ライフサイクルの違いをAPIで吸収...
良いアプリには良いレスポンスが必要です
良いレスポンスのために• サービスを止めない –   EC2(MultiAZ) –   ELB –   AutoScaling –   CloudWatch –   自動スナップショット –   RDS(MultiAZ)• ボトルネックを解消す...
リクエスト数を減らす(1)• ファイルをまとめる – CSS/JSを1つのファイルにまとめる。 – CSSによる画像スライスで1ファイルにする。• 適切な場所に配置 – HTMLの上部にCSS、下部にJSを配置する。 – 動的HTML内でCSS...
ELB/EC2を通らない                                                         Elastic Load                                         ...
リクエスト数を減らす(2)• S3に静的ファイルを置くときに気をつける – HTML,CSS,JSはgzip圧縮してから置きます。 – 画像はExpires Cache-Control を長めに設定• S3とCloudFrontどっちに置く? ...
S3/CloudFrontを賢く使う東京     Edge Location                                         Amazon Simple                     Amazon Cl...
S3/CloudFrontへの配備• 手作業はめんどくさい – キャッシュ設定 – Gzip圧縮 – アップロード – 公開設定 – アクセス制限• ビルドツールの活用 – Ant – S3cmd – S3sync
リクエスト数を減らす(3)• Webサーバで自動生成されるページのHTMLを  修正できない場合 – Apache/nginx等のUrlRewriteを使って304転送• 全て静的なWebページの場合 – CloudFrontのカスタム Ori...
HTMLを修正できない場合 東京                               Instance                                             Amazon Elastic        ...
ディスクアクセスを減らす(1)• EC2とEBSはネットワークで繋がれています – インスタンスサイズが大きいと割り当てられるネッ   トワーク帯域が太くなります。 – ネットワーク帯域をたくさん使ってしまうと応答が   遅くなります。 – E...
ディスクアクセスを減らす(2)• ディスクアクセスを高速化したい場合 – 大きいEC2インスタンスを使う – RAID0を組む   • 2つのEBSボリュームをマウント   • MdadmでRAID0化• EBSを使わずにEphemeral D...
データベースアクセスを減らす(1)• とりあえず負荷を減らす方法 – リードレプリカを用いる  • 検索と更新を分ける – シャーディングを用いる – RDSのインスタンスタイプを上げる  • SmallからLargeとか• 増え続けるアクセス...
データベースは何を管理するか?• データベースに何でも入れてしまう傾向 –   マスタデータ –   関係データ –   トランザクション –   更新履歴 –   操作ログ –   一時データ –   セッション –   メタデータ –   ...
ボトルネックは明らか                             ユーザからの                            アクセスに対して          Instance                       ...
ボトルネックを解消                                                                                Amazon SimpleAmazon SimpleDB     ...
SPOF(単一障害点)の無いAWSサービス群• サービスそのものが高可用性 –   DynamoDB / SimpleDB –   S3 / CloudFront –   SQS / SES / SWF / SNS –   EMR –   IA...
データベースアクセスを減らす(2)• データベースへの問い合わせ回数を減らす – キャッシュ機構を使う  • ElastiCache – データベース(RDBMS)を使わない  • DynamoDB – 複雑な問合せが必要な場合にはやっぱり  ...
ElastiCacheを使う                                                             Elastic Load                                   ...
DynamoDB/SimpleDB を使う                                            Elastic Load                                             ...
DynamoDBの特徴•   IOPS指定•   APIアクセス•   一貫性指定、Atomic カウンタ•   高可用性・耐障害性    – 同期レプリケーション• 条件付きアップデート• 専門家いらず• メンテナンスいらず• チューニングいらず
こんな症状に良く効きます• チケット予約・座席予約 – 同時に複数のユーザが参照して更新• 数量限定の商品販売 – カウンターが減っていく/増えていく• ソーシャルゲームのステータス(HP/MP) – 頻繁に値が変更される協力プレイ• HTTP...
適材適所にデータを保存• データベースへの負荷を減らす –   マスタデータ ⇒ RDS –   関係データ ⇒ RDS –   トランザクション ⇒ RDS/DynamoDB –   更新履歴 ⇒ RDS/S3 –   操作ログ ⇒ S3 –...
まとめ  RIAとスマホの話が無い(汗)
まとめ• データサイズを小さくする• 通信回数を少なくする• 読み込むタイミングを計る• できるだけキャッシュする• S3/CloudFrontでコンテンツ配信する• ELB/EC2へのアクセス数を減らす• ディスクへのアクセス数を減らす• デ...
Upcoming SlideShare
Loading in …5
×

JAWS Summit Satoshi Yokota

1,971 views
1,879 views

Published on

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,971
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
20
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

JAWS Summit Satoshi Yokota

  1. 1. RIAとスマホとクラウドとクラスメソッド株式会社
  2. 2. 自己紹介• クラスメソッド株式会社 – 2004年設立(第8期目) – 従業員数:約40人 – 平均年齢:約32歳• 横田聡 – クラスメソッド代表取締役 – 1977年生34歳・妻子1人 – 東京出まれ東京育ち
  3. 3. 今日は主にAWSの技術話をします。RIA(リッチなUI)とクラウドは相性が良い
  4. 4. RIA+クラウドが実現すること ブラウザ 社内システム 業務B DB 業務A 業務C DB デスクトップ 社外サービス WEB File サービス DB WEB サービス WEB DB サービス DB モバイル クラウド 業務B 業務A 業務C 仮想化 デバイス インタークラウド
  5. 5. なぜUIとサーバー側を分けるのか?ユーザーイン ・使い勝手に関する要求は増え続ける。 タフェース ・増え続けるクライアント端末に対応。 ・画面サイズに合わせた情報量。 ライフサイクルの違いをAPIで吸収API ・データ構造やロジックの定義には時間が ロジック 掛かるが1回固まれば変化が少ない。 ・データ構造が固まれば次は応答スピード。 / データ ・増加するリクエスト数やデータ量に 対して安定的に応答する構造が必要。
  6. 6. 良いアプリには良いレスポンスが必要です
  7. 7. 良いレスポンスのために• サービスを止めない – EC2(MultiAZ) – ELB – AutoScaling – CloudWatch – 自動スナップショット – RDS(MultiAZ)• ボトルネックを解消する – リクエスト数を減らす – ディスクアクセスを減らす – データベースアクセスを減らす
  8. 8. リクエスト数を減らす(1)• ファイルをまとめる – CSS/JSを1つのファイルにまとめる。 – CSSによる画像スライスで1ファイルにする。• 適切な場所に配置 – HTMLの上部にCSS、下部にJSを配置する。 – 動的HTML内でCSS/JSを書かない。外に出す。 – JSライブラリを非同期に読み込む。• 静的ファイルを全てEBS上に置くと。。。 – HTML,CSS,JS,画像,映像,大容量ファイル等は、 S3かCloudFrontに置くことで、EC2へのリクエスト 回数が減ります。 – 多くの場合、ELBを併せて使っていると思いますの で、ELBへの負荷も減ります。
  9. 9. ELB/EC2を通らない Elastic Load Balancer Instance Instance Amazon ElasticAmazon Elastic Block StorageBlock Storage (EBS) (EBS) Availability Zone Availability Zone Amazon Simple Amazon CloudFront Storage Service (S3) Storage Service / Content Delivery
  10. 10. リクエスト数を減らす(2)• S3に静的ファイルを置くときに気をつける – HTML,CSS,JSはgzip圧縮してから置きます。 – 画像はExpires Cache-Control を長めに設定• S3とCloudFrontどっちに置く? – S3はストレージサービス。長期保存用。 東京リージョンに置けばそこそこスピードが出るが、 高速にデータをダウンロードしたければCloudFront – アクセス制限を付与したい場合はS3。 認証付きURLならCloudFront/S3 – CloudFrontのエッジロケーションが大阪にもできた。 ネットワーク遅延を解消するため効果が大きい。 – CloudFrontはS3 Originのヘッダを引き継ぐため、 キャッシュや圧縮が有効であれば引き継ぐ。 コスト面でのメリットが非常に大きい!
  11. 11. S3/CloudFrontを賢く使う東京 Edge Location Amazon Simple Amazon CloudFront Storage Service Instance (S3) Amazon Elastic Block Storage (EBS) Edge Location大阪
  12. 12. S3/CloudFrontへの配備• 手作業はめんどくさい – キャッシュ設定 – Gzip圧縮 – アップロード – 公開設定 – アクセス制限• ビルドツールの活用 – Ant – S3cmd – S3sync
  13. 13. リクエスト数を減らす(3)• Webサーバで自動生成されるページのHTMLを 修正できない場合 – Apache/nginx等のUrlRewriteを使って304転送• 全て静的なWebページの場合 – CloudFrontのカスタム Originを設定する。 CloudFrontのURLにドメイン名を指定すれば完了。 – DNSレコード情報の反映スピード大事。 Route 53はマストツールです。 – クロスドメイン問題があるので注意が必要。別サー バから動的データを取得する方法を考える。JSONP、 マテリアライズドビュー(検索済み)
  14. 14. HTMLを修正できない場合 東京 Instance Amazon Elastic Block Storage (EBS) 304転送 Amazon Simple Amazon CloudFront Storage Service (S3)
  15. 15. ディスクアクセスを減らす(1)• EC2とEBSはネットワークで繋がれています – インスタンスサイズが大きいと割り当てられるネッ トワーク帯域が太くなります。 – ネットワーク帯域をたくさん使ってしまうと応答が 遅くなります。 – EBSはディスクですのでIOが大量に発生すると遅く なります。• ログを大量に吐き出していませんでしょうか。 – サービス系は常に改善のため本番時にもデバッグロ グを出し続けていることもしばしば – ディスクへの書き込みを減らす – ログはログサーバ(Fluentd等)を経由してS3へ
  16. 16. ディスクアクセスを減らす(2)• ディスクアクセスを高速化したい場合 – 大きいEC2インスタンスを使う – RAID0を組む • 2つのEBSボリュームをマウント • MdadmでRAID0化• EBSを使わずにEphemeral Diskを使う – EC2インスタンスの再起動でデータは消えるが ネットワークを介さないので高速 – EC2インスタンスを分散処理用に使って、一時 データを保存しておきたい場合に有効 – ランダムリード/ライトならEBSが良い。 – EMRでも使われている。
  17. 17. データベースアクセスを減らす(1)• とりあえず負荷を減らす方法 – リードレプリカを用いる • 検索と更新を分ける – シャーディングを用いる – RDSのインスタンスタイプを上げる • SmallからLargeとか• 増え続けるアクセスに対して 根本的な解決にはならない。
  18. 18. データベースは何を管理するか?• データベースに何でも入れてしまう傾向 – マスタデータ – 関係データ – トランザクション – 更新履歴 – 操作ログ – 一時データ – セッション – メタデータ – キャッシュ DBは – ビジネスステータス ボトルネック – バイナリデータ(画像、音声)
  19. 19. ボトルネックは明らか ユーザからの アクセスに対して Instance 全ての負荷がDBに 掛ってくる Amazon Relational Database Service (RDS)
  20. 20. ボトルネックを解消 Amazon SimpleAmazon SimpleDB Storage Service (S3) InstanceAmazon 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. 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. 22. データベースアクセスを減らす(2)• データベースへの問い合わせ回数を減らす – キャッシュ機構を使う • ElastiCache – データベース(RDBMS)を使わない • DynamoDB – 複雑な問合せが必要な場合にはやっぱり • RDS – 操作ログや履歴は後で加工する • S3 – カラムが動的なメタデータ • SimpleDB
  23. 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. 24. DynamoDB/SimpleDB を使う Elastic Load Balancer Instance Instance Amazon Relational Database Service Availability Zone (RDS) Availability Zone Amazon DynamoDB Amazon SimpleDB Database Service
  25. 25. DynamoDBの特徴• IOPS指定• APIアクセス• 一貫性指定、Atomic カウンタ• 高可用性・耐障害性 – 同期レプリケーション• 条件付きアップデート• 専門家いらず• メンテナンスいらず• チューニングいらず
  26. 26. こんな症状に良く効きます• チケット予約・座席予約 – 同時に複数のユーザが参照して更新• 数量限定の商品販売 – カウンターが減っていく/増えていく• ソーシャルゲームのステータス(HP/MP) – 頻繁に値が変更される協力プレイ• HTTPセッション管理 – 消えたら困る一時データ
  27. 27. 適材適所にデータを保存• データベースへの負荷を減らす – マスタデータ ⇒ RDS – 関係データ ⇒ RDS – トランザクション ⇒ RDS/DynamoDB – 更新履歴 ⇒ RDS/S3 – 操作ログ ⇒ S3 – 一時データ ⇒ DynamoDB – セッション ⇒ DynamoDB – メタデータ ⇒ SimpleDB – キャッシュ ⇒ ElastiCache – ビジネスステータス ⇒ SQS/SWF – バイナリデータ(画像、音声) ⇒ CloudFront
  28. 28. まとめ RIAとスマホの話が無い(汗)
  29. 29. まとめ• データサイズを小さくする• 通信回数を少なくする• 読み込むタイミングを計る• できるだけキャッシュする• S3/CloudFrontでコンテンツ配信する• ELB/EC2へのアクセス数を減らす• ディスクへのアクセス数を減らす• データベースへのアクセス数を減らす• SPOFの無いAWSサービス群を活用

×