Megasite Infrastructure Strategy 2010
日時:2010/03/10 10:00 to 12:20
会場:東京ミッドタウンホール(東京都港区赤坂9-7-2)
URL:http://www.computerworld.jp/event/mis/2010/
URL:http://www.computerworld.jp/topics/datac/176489.html
- 10：00 M-1 開幕記念講演 楽天のビジネスを支えるITインフラの現在、そして未来
- グループ紹介
- システム規模
- 帯域 20Gbps
- サーバ 数千台
- ファイルストレージ 500TB
- DB 25TB SAN
- 専任エンジニア 100名
- インフラの変遷
- いわゆる Web--App--DB/NASの3層構造
- (1) WebとApp/DBを分割、WebはLVSで負荷分散
- (2) DBからNASを分割
- (3) AppとDBを分割、Appは開発言語を選べるようになった
- (4) SANを導入
- ストレージの信頼性が向上
- DBとSANを分割
- (5) スレーブ(参照専用)DBを導入
- 信頼性、高可用性が向上
- SSDを導入
- 分割したらそれぞれのスケールアウトが可能になった
- バックアップ
- 1世代目NAS,SAN、2世代目ストレージ、3世代目テープ
- IDC間でバックアップを持ち合う
- トラフィック対応
- (1) 画像が増えた→NASやWebに負担増加→アプライアンスのキャッシュサーバを導入
- (2) キャッシュサーバの負担増加→キャッシュサーバに親子関係を導入
- (3) 親子キャッシュサーバで負担増加→親子キャッシュサーバにCAPPを導入
- (4) これでも負担増加→CDNを導入(Akamai) Akamaiはコストに見合う
- セキュリティ
- アクセス監視
- トラブル発生時、一次受けはベンダー、二次受けは自社
- CSIRT設立
- クラウドの利用
- 3年前から検証
- 検証→新規サービスや開発環境に導入→主要サービスを移行→PrrC
- 仮想化はXenを利用、最近はXenServer
- Quad Coreを2基、1コアに1仮想OS
- 旧サーバを集約(CPU利用率10%が多い)
- 工期短縮…月に数百をインストールしていたのがイメージをコピーするだけ
- OSとハードウェアの分離(相性問題の解消)
- フリーのLinux(CentOS?)
- サーバを減らすのもラクになった
- KVS…ROMA
- Ruby製
- オープンソース
- 分散、P2Pで連携
- 閲覧履歴で利用(PCとモバイルでデータを共用)…他の利用シーンは言えない
- 分散データ処理…Hadoop
- 現役引退のサーバを利用
- 商品レコメンドや広告集計をバッチ処理…数日かかっていたのが数時間に
- ファイル分散…MogileFS
- Perlで実装
- トラッカーとバランサを物理サーバに同居
- 画像共有サーバで利用
- プライベートクラウドの構築を目指す
- 10：50 M-2 特別講演 お客様はあなたの会社のWebサイトに満足していますか？
- 配布資料あり
- 資料のまま
- IDC内や一般クライアントに相当する所に端末を置いて、それぞれから顧客のサーバへ死活監視や速度計測を行うサービスの紹介
- 11：40 M-3 特別講演 はてなのサービスを支えるシステム
- 資料 http://www.slideshare.net/stanaka/performance-and-scalability-of-web-service
- これそのものではないが、これの焼き直し
- エンタープライズとウェブサービスの違い
- 信頼性、トランザクション
- ウェブサービスの特徴
- 低コスト、高効率
- 信頼性100%を目指さない
- スケーラビリティ、応答性を重視
- 機動性
- クラウドと自前
- クラウドは…
- スケーラビリティ向上
- サーバ仕様画一化
- ロードバランサの不充実
- 時々止まる
- はてな規模では自前→将来はハイブリット？
- 自前インフラだと…
- ボトルネックのコントロールができる
- 柔軟なハード構成をとれる
- 要望への柔軟な対応がとれる
- はてなの規模
- ユーザ 150万
- ユニークユーザ 2000万
- トラフィック 800Mbps
- サーバ 600台、仮想化して1300台
- はてぶ
- エントリ 2000万
- ブックマーク 6000万
- ユニークユーザ 500万
- サーバの台数 5台
- memcached、squid、リバースプロキシ利用
- はてなのサーバ
- 標準 Quad4コア、メモリ8GB
- DBサーバだと4コア2基、メモリ32GB
- 分間数千リクエストをさばく
- レイヤ毎のスケーラビリティ
- App
- 構成を同一→ロードバランスすれば容易にスケールアウト
- DB,ファイルサーバ
- readは容易→スケールアウト
- writeは難しい→スケールアップ
- 負荷の把握
- 管理ツールは自前
- 負荷の可視化
- 1日1回はチェック
- OSの動作原理を理解
- パフォーマンスの監視
- ウェブ各ページのレスポンスを可視化→グラフで推移
- 曜日で変わる
- 目標に達しているかチェック
- 冗長性
- 24時間、365日は難しい
- SPOFの除去が現実的
- Appサーバ
- ロードバランサ(LVS)導入
- DB
- マスタ、スレーブを導入
- マスタ…マルチマスタ(相互にレプリケーション)、切り換え時のずれは手動で修正
- スレーブ…台数を増やす
- ストレージ
- MogileFS
- キャパ 50TB、ファイル数3億
- トレードオフ
- 安定性←→資源効率
- 安定性←→速度
- システムの不安定要因
- 負荷増大
- 機能追加、データ量増大→自律制御(PS上がるとkill、処理時間が長いSQLをkill)→処理時間の長いSQL実行は別サーバ
- 能力低下
- ハードウェア故障→能力の7割に抑える
- 処理効率向上
- 仮想化
- Xenを利用
- IPMI代替としてハイパーバイザ、Dom0がDomUを監視、不具合が発生したら丸ごと再起動
- monitで監視
- CPUが空いていれば、仮想サーバはWeb
- I/Oが空いていれば、仮想サーバはDB
- メモリが空いていれば、仮想サーバはキャッシュサーバ
- 中央ストレージは未使用
- 仮想化のメリット…物理、OSの分離
- 仮想化を前提にしたハードウェア→自作サーバ
- ネットワーク…小規模なら考えなくて良い
- PCルータ…1Gbps(実際300Kbps)
- 500ホスト…サブネットの限界(ARPテーブルの限界)
- IDCの限界…IDCを分割
- ネットワーク仮想化…3層構造に更改中
- 太平洋越しのアクセス
- CDNを導入
- Amazon Cloud Frontを導入(コスト的にこちらにした)
0 件のコメント:
コメントを投稿