proposal for the system platform
Download as key, pdf1 like8,306 views
http://tech.dclog.jp/2012/02/blog-post_27.html のための資料
![appendix∼計算メモ∼
【計算式】
【参考数字】
■写真アップロード数 ・Read
xxxxxを例に取ってみる [1ページビューの平均容量]×[ページビュー]
http://xxxxx/
ユーザーx００万で毎秒xx＝１時間xx 2011年x月x日 [1ページビューの平均容量]＝xxxKB×x＝xxxKBと仮定
[ページビュー]=xxxKPV/日
■ページビュー
xxxxxxx=xxxk PV/day ・Write
[hogehoge]×[fugafuga]×[mogamogamoga]×[ユーザー数]
【仮定】
・ユーザー数10万で1年間続いた場合 ■基本データ
・xxxx -In Traffic(day)
・xxxx xxx×xxxx枚=xxxxx＝xxxGB
・1日でたまるデータ容量＝2,160,000Kb＝約2GB
-Out Traffic(day)
xxx×xxxxPV=XxxGB
-Page View
【Write】 xxxK
・画像投稿・変更・削除
■S3コスト
・コメント投稿 1か月の増加容量＝xxGB
・xxx 12か月でxxxGB。
は、差分扱いにして、計算には入れない。 平均xxxGB
あと、静的画像やHTML、CSS等のテキストも全部誤差扱いする。
※最後に1割程度のレンジを持たせてそれを静的コンテンツの誤差とする。 -request
[PV]×6（最大xxなので平均値で計算）
=xxxK×6=xxxK
【Read】
・画像ページ ■EC2コスト
Large2インスタンス
■RDSコスト
【データ】
1pv=5query
メインページに1ページ12枚 1query=r:0.5k w:1k
xxxxxxxxxxxxxxxxxx query = 5query×xK
r=0.5K×5query×xK＝xxx.5k
w=1k×5query×300K
■Route53
xxxxK hit
16](https://image.slidesharecdn.com/proposalforaws2-120226094323-phpapp02/85/proposal-for-the-system-platform-16-320.jpg)
More Related Content
Viewers also liked (16)
proposal for the system platform
- 1. proposal for the system platform 1
- 3. システム構成の設計ポイント • 安定性 • 繋がらないサービスにユーザーはこない。安定した運営が行えるか？ • 継続性 • その選択肢は継続して利用可能か？ • 柔軟性 • サービスが急激に成長しようとしたとき、スピーディーなインフラ増 強が行えるか？ • その逆のケースにおいても、スピーディーな縮退が行えるか？ • コスト • 許容範囲におさまるか 3
- 4. ハウジング&レンタル運用から学んだこと • 安定性、継続性 • 特に問題ない。 • 柔軟性 • 調達には1週間∼2週間のリードタイムが必要。 • レンタルというスキーム上、選択できるインフラ機材は限られる • xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx • コスト • 比較対象がないため、相対的なコストパフォーマンスは不明。 • ただし、上述のとおり、レンタルというスキーム上、選択しうるイン フラ機材は限られるため、過剰な調達になりがちな傾向にある。 4
- 5. システム構成の選択肢 • ハウジング • これまでのノウハウがそのまま利用できる。 • VPS (Virtual private server) • 仮想化技術により、ハード単位ではなく、仮想OS単位での契約がで きる。 • ハウジングの運用ノウハウがかなり流用できる。 • 非常に安価。基本的に月額固定課金(1,000∼10,000/月程度) • ただし、拡張性に乏しい。小規模向け。今回は除外する。 • クラウド • VPSと同じく仮想化インフラ。VPSよりさらに柔軟なインスタンス単 位で契約をする。従量課金が基本。 5
- 6. VPSとクラウドの違いのイメージ ハードウェア リソースの塊 ハードウェアを仮想化記述で 連結し、１つの巨大リソース を作る。 １つのハードウェアを仮想化技術 そのリソースを切り出し、こ で分割し、この単位で貸し出す の単位で貸し出す。 6
- 7. xxxxの特徴 • XXXXXXも視野に入れたサービス • XXXXXXXXXXXXXX • XXメインのトラフィックがヘビーなサービス • アクセスにストレスがないようにしなければならない • XXデータをキッチリ保持しつつコストをケアする必要がある • xxxのため、成長が期待できる ある程度、成長することを前提におき、かつ、流行らな かったときに過剰投資とならないインフラが好ましい。そ の可能性をもった選択肢が「クラウド」 7
- 8. クラウドの選択肢 • AWS（Amazon Web Service） 2006/8∼ • Amazonが運営するクラウドコンピューティングのフロンティア • 使用言語、ミドルウェアを選ばない • AZURE 2010/1∼ • Microsoftが運営。 • Windowsプラットフォームが前提になっている。 • Google APP Engine 2008/4∼ • Googleが運営。 • 言語がJavaかPythonと限られている。 • その他国内クラウド • xxxxxが頑張っているが、価格・技術面で上記3社と比較するとxxxx • 現状ではほぼAWS一択 8
- 9. クラウドを選択することのリスク • 安定性 • 継続性 • コスト 9
- 10. AWSを選択することのリスク∼安定性∼ • AWS障害事例 • 2011/4/21 一部で12時間にわたりシステムが動作しない不具合が発生（ http:// aws.amazon.com/jp/messages/65648/） • ただし、データ消失の事例はなし • 位置づけとしてはデータセンター障害と同等と考えられる • 個別の障害事例 • インスタンスのフリーズ事例が散見される。 • 現状のハウジング運用でもサーバのフリーズはよくある。 • ネットワーク系の障害事例は見当たらなかった 安定性については、ハウジングと特に変わりないと判断。クラウドにおいて も、ハウジングと同様に障害を前提とした設計をするだけ。 10
- 11. AWSを選択することのリスク∼継続性∼ • Amazonで実際に使われているシステムであるため、 AWSの継続性＝Amazonの事業継続性とも言える • 海外のスタートアップサービスはAWSの利用が多い • Instagram • Foursquare • Quora • etc.. • 国内事例も増加中 • 株式会社gumi • http://aws.amazon.com/jp/solutions/case-studies/gumi/ • 株式会社Cookpad • http://enterprisezine.jp/article/detail/3039 • http://aws.amazon.com/jp/solutions/case-studies-jp/ 11
- 12. AWSを選択することのリスク∼コスト∼ • 従量課金であるためコスト見積もりが難しい • インスタンスの起動時間 • トラフィック • ストレージI/Oなど • 青天井 • 管理コンソールが完備されているので、ほぼリアルタイムに近い形で 利用状況は確認できる • ドル建て（為替リスク） 12
- 13. AWSを選択することのリスク∼コスト∼ • 課金シミュレーション • ユーザー数 xx万人（で1年間） • ページビュー（xxxxxxxから計算） xx万PV／day • 画像のアップロード数(xxxのアップロード数から計算） • xxx／day • xxxxxxx 13
- 14. AWSを選択することのリスク∼コスト∼ • xxx$（76円換算で約xx万） ／ month • Webサーバ相当 xxx$ • DBサーバ相当 xxx$ • ストレージサーバ相当 xxx$ • ネットワーク機器相当 xx$ • 回線代相当 xxxx$ ※集計作業などに必要なインフラ費用は対象外 http://calculator.s3.amazonaws.com/calc5.html?key=xxxxxxxxxxxxxxxxxxxxxxx&lng=ja_JP 14
- 15. appendix∼クラウドのいいところ∼ この状態をカスタマイズし、保存しておくこと ができる。 この保存したものを、複製・起動することがで きるため、例えばWEBサーバの増強などは数分 で可能。 リソースの塊 また、すべての操作はAPIが用意されているた め、自動化が可能。そのため、単純な増強に関 して言えば、ほとんど人的リソースがかからな い。 15
- 16. appendix∼計算メモ∼ 【計算式】 【参考数字】 ■写真アップロード数 ・Read xxxxxを例に取ってみる [1ページビューの平均容量]×[ページビュー] http://xxxxx/ ユーザーx００万で毎秒xx＝１時間xx 2011年x月x日 [1ページビューの平均容量]＝xxxKB×x＝xxxKBと仮定 [ページビュー]=xxxKPV/日 ■ページビュー xxxxxxx=xxxk PV/day ・Write [hogehoge]×[fugafuga]×[mogamogamoga]×[ユーザー数] 【仮定】 ・ユーザー数10万で1年間続いた場合 ■基本データ ・xxxx -In Traffic(day) ・xxxx xxx×xxxx枚=xxxxx＝xxxGB ・1日でたまるデータ容量＝2,160,000Kb＝約2GB -Out Traffic(day) xxx×xxxxPV=XxxGB -Page View 【Write】 xxxK ・画像投稿・変更・削除 ■S3コスト ・コメント投稿 1か月の増加容量＝xxGB ・xxx 12か月でxxxGB。 は、差分扱いにして、計算には入れない。 平均xxxGB あと、静的画像やHTML、CSS等のテキストも全部誤差扱いする。 ※最後に1割程度のレンジを持たせてそれを静的コンテンツの誤差とする。 -request [PV]×6（最大xxなので平均値で計算） =xxxK×6=xxxK 【Read】 ・画像ページ ■EC2コスト Large2インスタンス ■RDSコスト 【データ】 1pv=5query メインページに1ページ12枚 1query=r:0.5k w:1k xxxxxxxxxxxxxxxxxx query = 5query×xK r=0.5K×5query×xK＝xxx.5k w=1k×5query×300K ■Route53 xxxxK hit 16