1. proposal for the system platform
1

2. 本書の目的
• 新規Webサービスである”xxxx“のシステム構成
を決定するにあたり、xxxxxxの各調査内容の
報告および、見解を提示することを目的として
います。
2

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