楽天インターネットスケーラブルコンピューティング；丸山先生レクチャーシリーズ2010第3回＠楽天

楽天インターネットスケーラブルコンピューティング楽天株式会社　開発部　吉岡弘隆｜ April 23, 2010

目次
本日はこんなお話をさせていただきます。
楽天のグループご紹介
システム規模
サービスインフラの変遷
仮想化関連技術の活用
今後の課題

自己紹介
開発部、 ACT 課アーキテクト G 、技術理事よしおかひろたか
2009 年 8 月入社
カーネル読書会の主宰者、 DEBUG HACKS 共著 ISBN978-4-87311-404-0
twitter @hyoshiok http:// d.hatena.ne.jp/hyoshiok

楽天グループのご紹介

会社紹介（１３年目）楽天株式会社／楽天グループ・ 1997 年創業（ 13 年目）・従業員数（ 2008 年 12 月末現在）単体： 2,081 人連結： 4,874 人・拠点　東京、札幌、仙台、横浜、埼玉、新潟、名古屋、京都、大阪、神戸、広島、松山、福岡、鹿児島、沖縄ニューヨーク、ボストン、シカゴ、サンフランシスコ、ルクセンブルク、ロンドン、台湾、上海、ソウル、グアム

ブランド力の向上楽天市場は国内 Web ブランド指数にて 1 位を獲得。他サービスもランク上位に！＊：日経 BP コンサルティング調べ――「 Web ブランド調査 2010―I 」（ 2009 年 10 月実施）

ブランド力の向上チームも上位に！！

国内グループ流通総額推移遂に 1 兆 1,000 億円を突破

楽天会員の増加楽天会員は 4,700 万人を突破

2008 年：台湾、海外配送
台湾版「楽天市場」オープン
国内商品の海外配送サービスも拡充
2009 年：タイ
TARAD.com と提携による EC 事業展開
2010 年：中国
「百度（バイドゥ）」との合弁会社設立を発表
ＥＣ事業の国際展開日本だけでなく海外の事業者・消費者を Empowerment 最終的にはボーダレス・ショッピングモールを目指す

システム規模

トラフィックピークトラフィックは上昇の一方。年間トレンドでは年末商戦がピーク。

システム機器現在ではネットワーク機器が数千台、サーバ機器はその数倍。データセンタ集約

コンテンツ容量 NAS 静的コンテンツや画像・プログラムなどが置かれる、ファイルサーバの総容量は５００Ｔｂｙｔｅ以上。

データベース容量データベースにはＳＡＮを利用し。２５Ｔｂｙｔｅを超えるデータを格納。 DB SAN

インフラエンジニアの体制
■ 業務種別
・サーバエンジニア
・データベースエンジニア
・ネットワークエンジニア
・ストレージエンジア
・データセンタエンジニア
・セキュリティエンジニア
１００名以上の専任エンジニアにより、設計・構築から運用までを自社で実施。絶賛募集中！

システムインフラ構成 Web App DB ＳＡＮ NAS 現在は一般的な web アプリケーション構成（いわゆる三層モデル）

創業期（ 1997 年）
最初は 13 店舗のみでした・・・

最初は１台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み内蔵ディスク

現在では
店舗数：約 31,000 店
商品数：約 5 , 140 万点
日本最大のインターネットのショッピングモール

裏側
巨大なリレーショナルデータベース
多くの機能が API 化されている
システムの依存関係はかなり複雑化している

楽天市場のシステム 64 インスタンス買い物かご店舗ページ店舗編集受注処理オークション商品登録各種 API 商品ページ共同購入 100 以上のドメイン約 900 インスタンスプレゼントケータイ・・・ WebLogic Server SunFire25K

買い物かご処理量
2008 年 12 月現在
月間購入件数　　　約 900 万件
ピークタイムの購入件数 1000 件 / 分以上

最初は１台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み内蔵ディスク

機能分割＆負荷分散アクセス増加にともない、フロントの Web サーバとバックエンドを機能分割内蔵ディスク Web App DB ファイル共有

機能分割：Webサーバ分割機能分割して負荷分散できる構成に変更。ロードバランサによりスケールアウトデータ分割によるスケールアップ Web App/DB ＋ファイル共有

機能分割：NAS導入ＤＢサーバがもっていたファイル共有機能を切り離してＮＡＳを導入。 Web App/DB ＋ファイル共有 App/DB NAS

機能分割：Appサーバ App サーバ分割してビジネスロジックによる負荷を DB から切り離し。 DB Web NAS App

信頼性向上：SAN導入ＳＡＮの導入により、ストレージ部分の信頼性の向上と性能向上を実施 DB SAN

負荷分散：スレーブDB導入参照専用のスレーブＤＢを導入して、負荷分散と耐障害性を同時に向上。 App マスタ DB スレーブ DB ＳＡＮ

バックアップ：世代管理 Phase1 Phase2 Phase3 世代に応じたバックアップ方法の選択ＳＡＮ Backup ストレージ Tape 装置 DB ＋ SAN NAS

バックアップ：サイト間バックアップデータセンタ間での相互バックアップデータセンタ A データセンタＢ DB ＋ SAN 、 NAS BackUp 外部倉庫 BackUp Tape Tape

トラフィック対応画像トラフィックの増大により、今度は Web/NAS がボトルネックに。 Web NAS

トラフィック対応：キャッシュサーバキャッシュサーバを導入して負荷軽減 Web NAS Cache

トラフィック対応：多段キャッシュキャッシュを親子構成にして多段化 Web 親 Cache 小 Cache

トラフィック対応：CARP導入ＣＡＲＰの導入により、キャッシュ効率を最適化 Web 小 Cache 親 Cache CARP

トラフィック対応： CDN導入 CDN を導入して負荷と設備投資を抑制 CDN Web 小 Cache 親 Cache CARP

トラフィック対応： CDN導入コストが下がって、レスポンスが向上。海外でのサービス品質も向上。台湾でのレスポンス

楽天市場のシステム 64 インスタンス買い物かご店舗ページ店舗編集受注処理オークション商品登録各種 API 商品ページ共同購入 100 以上のドメイン約 900 インスタンスプレゼントケータイ・・・ WebLogic Server SunFire25K

楽天システムの特性
管理指標 KPI(Key Performance Index)
流通総額一兆円
転換率、ドロップ率、併売率などの流通貢献
PV 、会員獲得、グループ間連携
コスト / 流通総額 1% 以下
性能改善、コストパフォーマンス
稼働率 99.95%
再構築、冗長化

さまざまな要望に対して
短いものは１週間、長くても 3 ヶ月くらいのプロジェクトを組んで実施
ブランチ分岐とマージの計画を立てたり、依存関係に注意しながら
それを 200 人くらいでこなしている

運用
障害対応訓練などを定期的に行っている
トラブル時の初動、体制構築は俊敏
リリースは計画的に
手順作成、ダブルチェック、リハーサル

定期メンテナンス風景

セキュリティ： Rakuten-CERT SS 担当システムセキュリティグループ楽天 CSIRT セキュリティチーム（各グループのセキュリティ担当） SS 担当 SS 担当 SS 担当 SS 担当社内に CSIRT を設立。日本 CSIRT 協議会へも加盟し、関係団体との連携を強化しています。 JPCERT/CC 他の CSIRT IPA

仮想化関連技術の利用

サーバ仮想化：目的
ハードウェアコストの削減
データセンタコストの削減
エネルギー削減（グリーン IT ）
構築スケジュールの短縮
運用管理工数削減
設定変更時の作業影響・調整工数削減
主にコスト抑制を期待して３年前から検証を開始。（ XenServer ）

サーバ仮想化：導入経緯３年前から検証を開始し、段階を踏んで順次導入。２００８２００７２００９２０１０技術比較・機能検証開発環境や新規サービスへ展開主要サービスを移行プライベートクラウドへ

サーバ仮想化：おさらい従来システム（ハードウェアとＯＳは１対１）仮想化システム（同一ハードウェアに異なるＯＳを複数搭載可能）ハードウェア OS （ CPU 25% ）アプリケーション OS （ CPU 25% ）アプリケーション OS （ CPU 50% ）アプリケーション XenServer ハードウェアアプリケーションアプリケーション OS ベースに Xen/ ＸｅｎＳｅｒｖｅｒを採用

サーバ仮想化：現状調査使用率１０％まずは、特定サービスを対象にサンプル調査。意外と可動率が低いものも多かった。

サーバ仮想化：サーバ集約 CPU 使用率の低いサーバを、仮想化を利用して集約新型機旧世代機

サーバ仮想化：相互影響排除ハードウェア OS （ CPU 25% ）アプリケーション OS （ CPU 25% ）アプリケーション OS （ CPU 50% ）アプリケーション XenServer 仮想化システムリソースや設定を個別に管理可能ハードウェアアプリケーションアプリケーション従来システム相乗りは可能だが同一リソースを利用 OS 高負荷！高負荷！影響影響影響負荷や設定変更による相互影響を排除

サーバ仮想化：構築期間短縮従来仮想化サーバ構築にかかる工数と期間を大幅に短縮環境コピーパラメータ設定機器調達設置・配線設置・配線インストールパラメータ設定

サーバ仮想化：マイグレーション対応 XenServer OS XenServer OS ハードウェアハードウェアハードウェアの違いを仮想化ソフトが吸収するため、移行が簡単

サーバ仮想化：振り返りサーバ集約以上に効果を感じたのは、
ハードを切り離せたことでフリーの linux が使いやすい
HW 仕様変更による OS との相性問題
OS バージョンアップによる HW との相性問題
から開放
サーバ構築が簡単
１サービスの負荷に他が引きずられない
サーバを増やすのが簡単。同時に減らすのも簡単。

その他の技術の利用

ROMA
Rakuten On-Memory Architecture
共有データを複数のマシンのメモリに分散して保存し、高速に読み書き
開発言語に Ruby を使用して開発。
スケールアウトが容易で、耐障害性が高い。
オープンソース・ソフトウエアとして公開。
独自開発した分散キー・バリュー型データストア (KVS)

ROMA：基本的な動き Web 「キー」と「値」のペアのシンプルなデータベースで「高速アクセスが可能」

ROMA：特徴自動切り離し障害発生複数サーバを１つのデータベースにみたて、「障害耐性」が高い構成を「低コスト」に実現。ホットスケール A B C B A A C C

ROMA：導入例【 PC 】【閲覧履歴】楽天 ID でデータを共有トラベルや市場の閲覧履歴など複数サービスで活用【モバイル】

ROMA （ KVS ）とＲＤＢの比較 ROMA ：機能比較 ○ ○ １．アクセス速度 × ○ ２．負荷分散化コスト ○ × ３．複雑な検索や集計 △ ROMA (KVS) ４．データ「品質」確保 ○ ＲＤＢ

hadoop
Google が開発した MapReduce をベースに Java で実装されたオープンソース・ソフトウエア。
分散データ処理を容易に開発可能にするフレームワークで、大規模なデータの解析処理に特化。
Google が検索 index の作成に利用している技術と同等。
分散処理を意識せずにプログラムを作成でき、生産性が高い。
オープンソースの分散データ処理技術

hadoop ：基本的な動きコモディティサーバを複数台ならべて構築 Master slave データ結果データデータデータデータデータデータデータデータデータデータデータデータ

hadoop ：導入例大量データを扱うバッチ処理などで活用し、数日かかっていた処理が数時間に改善。【商品レコメンド】数千万商品 × 数千万ユーザーから「お勧めの商品」をリストアップ【広告集計】大量の広告配信ログを解析して、データ分析やレポート作成

MogileFS
perl で実装された分散ファイルシステム。
複数のファイルサーバを複数と意識せずに利用可能。
アプリケーション層で動くので導入もわりと簡単。
サーバ追加で簡単に拡張。基本的には無停止で追加。
ファイルをサーバ間で自動コピーして冗長化。
オープンソースの分散ファイルシステム

MogileFS ：基本的な動き StrageNode DB PC サーバをベースに安価なファイルシステムを構築 Tracker/Perbal Web A B C B A A C C

MogileFS ：導入例画像共有サービスなどのファイルサーバとして活用。導入コストを大幅に低減。

ARIA (WEB-shaped file storage system)
WEB オンライン処理に特化した分散ファイルストレージ
メディアストレージ
写真
動画（携帯 , スマートフォンで録画 )
Office ファイル
2009/12 ～鋭意開発中・・・楽天技術研究所 (RIT)
リリース未定
コア開発者 1 名、開発者 3 名 ( 計 4 名 )
名称の由来
Cloud File Storage
-> AirFS （クラウドとは、 " 空気 " のような存在であるべき )
-> "Air == Aria" ( 伊： aria, 英： air, aria, 仏： air )
ARIA

ARIA (WEB-shaped file storage system) の特徴
特徴
分散
スケーラブル
スケールアウト
高い耐障害性
常に書き込み可能
数 MB ～数十 MB のファイルを高速に READ/WRITE
概要
分散アルゴリズム
Consistent Hashing ( 担当ノード決定）
Vector Clocks 　　 ( バージョニング）
Merkle Trees 　　（同期処理 )
Storage Engine
インデックス ( メモリ、ファイルで管理 )
複数ファイルを 1 ファイルに束ねて管理 (disk シーク回数 ,inode 数の抑制 )

今後の課題

今後の課題
インターネットスケーラブルコンピューティング
多量なコモディティサーバーによる高い可用性を持ち、スケーラブルなコンピューティングスタイル
データーセンター
運用
コスト
素早い開発

今後の課題
クラウドという言葉も無い時代から拡張を続けてきて、複雑化している。
レガシーシステムのモダン化
スケーラビリティ
ユーザー数、店舗数、トランザクションの急増
運用
運用による価値の創造

まとめ
本日はこんなお話をさせていただきました
楽天のグループご紹介
システム規模
仮想化関連技術の活用
今後の課題

http://d.hatena.ne.jp	279
https://jujo00obo2o234ungd3t8qjfcjrs3o6k-a-sites-opensocial.googleusercontent.com	36
http://www.slideshare.net	18
http://paper.li	7
http://webcache.googleusercontent.com	2
http://a0.twimg.com	1

楽天インターネットスケーラブルコンピューティング；丸山先生レクチャーシリーズ2010第3回＠楽天

by Hiro Yoshioka on Apr 22, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 343

Statistics

楽天インターネットスケーラブルコンピューティング；丸山先生レクチャーシリーズ2010第3回＠楽天 — Presentation Transcript