JAWS-UG Summit2012にいってきた (2012-03-03)第二日目 その３
RIAとクラウド (横田氏 classmethod代表取締役）
- 時間がないのでRIAの話はしませんw
- なぜUIとサーバ側をわけるのか？
- UI側：増え続けるクライアント、画面サイズに合わせた情報量
- ライフサイクルの違いをAPIで吸収
- サーバ側：データ構造やロジックの定義には時間がかかるが変化は少ない。応答スピードの対応が必要
- 良いレスポンスのために
- リクエスト数を減らす1
- リクエスト数を減らす２
- S3に静的ファイルを置くとき
- HTML/CSS/JSはgzip圧縮する
- 画像はExpires Cache-Controlを長めに設定
- S3とCloudFrontどっちに置く
- S3はストレージサービス。長期保存用
- 東京リージョンに置けばそこそこスピードが出るが高速にデータをダウンロードしたければCloudFront
- アクセス制限を付与したい場合は、S3
- 認証つきURLならCloudFront/S3
- CloudFrontのエッジロケーションが大阪にもできた
- ネットワーク遅延を解消するため高価が大きい
- CloudFrontはS3 Originヘッダを引き継ぐためキャッシュや圧縮が有効であれば引き継ぐ。コスト面のメリット大きい
- S3/CloudFrontへの配備
- 手作業はめんどくさい
- キャッシュ設定
- Gzip圧縮
- アップロード
- 公開設定
- アクセス制限
- ビルドツールの活用
- ant
- S3Cmd
- S3Sync
- リクエス数を減らす３
- ディスクIOを減らす１
- EC2とEBSはネットワークで接続されている
- インスタンスサイズが大きいと割り当てられるネットワーク帯域が太くなる（SmallよりLargeが太い）
- ネットワーク帯域をたくさん使ってしまうと応答が遅くなる
- EBSはディスクなのでIOが大量に発生すると遅くなる
- ログを大量に出力するとIOが大量発生
- サービス系は常にカイゼンのために本番系でもデバッグログを出力していることもよくある
- ディスクへの書き込みを減らす
- ログはログサーバ（Fluentd等）を利用
- ディスクアクセスを高速化したい場合
- 大きいEC2インスタンスを使う
- RAID0を組む
- ２つのEBSボリュームをマウント
- MdadmでRAID0化
- EBSを使わずにEphemeral Disk を使う（EC２のローカル）
- DBアクセスを減らす2
- とりあえず負荷を減らす
- リードレプリカを用いる
- 検索・更新を分ける
- シャーディングする
-
- DBへの問い合わせ回数を減らす
- キャッシュ機構を使う.ElasticCache
- データベースにRDBMSを使わない
- DynamoDB、SimpleDB
- 操作ログや履歴はファイルへ.S3の利用
- DBへの問い合わせ回数を減らす
