• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
楽天インターネットスケーラブルコンピューティング;丸山先生レクチャーシリーズ2010第3回@楽天
 

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

on

  • 3,771 views

楽天のインフラのシステム規模、変遷、仮想化関連技術、今後の課題についての発表です。

楽天のインフラのシステム規模、変遷、仮想化関連技術、今後の課題についての発表です。

Statistics

Views

Total Views
3,771
Views on SlideShare
3,353
Embed Views
418

Actions

Likes
6
Downloads
2
Comments
0

6 Embeds 418

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

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 裏側では、同じスキーマを持った巨大なデータベース郡があったり、 会員情報やポイントや各種機能などかなりの数の API が用意されています。 他にも大量のバッチが動いていたり、アプリケーション間の依存関係がかなり複雑化してきています。
  • 市場系の J2EE のシステムですが、 100 以上のドメイン上に約 900 近いインスタンスが動いています。 ドメインというのはアプリケーションの管理単位のことです。商用アプリケーションサーバなどで出てくる概念です。 裏の DB は Informix が 64 インスタンスが動いていまして、 一部のシステムでは OracleDatabase や MySQL にも繋がっております。 こうやってみるとキレイに見えますが、実際はかなり入り組んでいます。 このデータベースは全て同じスキーマを持っていまして、店舗 A は 1 番目、店舗 B は 2 番目、などのように 店舗単位で割り振られております。 ほぼ全てのアプリケーションが 64 個の DB にコネクションプールをもっていて、店舗 A がきたから 1 番目のコネクションを取る、みたいな動作を行っています。
  • 一呼吸 – お買い物マラソンの解説 楽天市場では、弊社ではお買い物マラソン、という半年に1度のイベントが開催されるのですが このようなシステムで処理している量ですが、昨年の12月だけで月間900万件の受注、 お買い物マラソンのピークタイムの購入件数は、一分あたり1000件を超えています。
  • 市場系の J2EE のシステムですが、 100 以上のドメイン上に約 900 近いインスタンスが動いています。 ドメインというのはアプリケーションの管理単位のことです。商用アプリケーションサーバなどで出てくる概念です。 裏の DB は Informix が 64 インスタンスが動いていまして、 一部のシステムでは OracleDatabase や MySQL にも繋がっております。 こうやってみるとキレイに見えますが、実際はかなり入り組んでいます。 このデータベースは全て同じスキーマを持っていまして、店舗 A は 1 番目、店舗 B は 2 番目、などのように 店舗単位で割り振られております。 ほぼ全てのアプリケーションが 64 個の DB にコネクションプールをもっていて、店舗 A がきたから 1 番目のコネクションを取る、みたいな動作を行っています。
  • それらの要望は、各種指標に基づいて実施すべきかどうか判断されていきます。 最初の方で申しました、流通総額という指標があり、それに繋がる案件かどうか、で決められていきます。 一番の目標は「流通」であり、他のサイトで追いかけているの PV や会員数とは若干性質が異なる、ということを言葉でいう - コスト / 流通総額1%以下っていうのは流通が 100 億円だったらシステムの総コストは人件費含めて 1 億円以下にしましょうねという意味
  • #使用許可とって無い ここは会議のための部屋であり、業務を行う部屋ではない メンテナンスでは各自PCをこの部屋に運んで行う

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

  • 楽天インターネットスケーラブル コンピューティング 楽天株式会社 開発部 吉岡弘隆| April 23, 2010
  • 目次
    • 本日はこんなお話をさせていただきます。
      • 楽天のグループご紹介
      • システム規模
      • サービスインフラの変遷
      • 仮想化関連技術の活用
      • 今後の課題
  • 自己紹介
    • 開発部、 ACT 課アーキテクト G 、技術理事 よしおかひろたか
    • 2009 年 8 月入社
    • カーネル読書会の主宰者、 DEBUG HACKS 共著 ISBN978-4-87311-404-0
    • twitter @hyoshiok http:// d.hatena.ne.jp/hyoshiok
  • 楽天グループのご紹介
  • 会社紹介(13年目) 楽天株式会社/楽天グループ ・ 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 年:中国
      • 「百度(バイドゥ)」との合弁会社設立を発表
    EC事業の国際展開 日本だけでなく海外の事業者・消費者を Empowerment 最終的にはボーダレス・ショッピングモールを目指す
  • システム規模
  • トラフィック ピークトラフィックは上昇の一方。 年間トレンドでは年末商戦がピーク。
  • システム機器 現在ではネットワーク機器が数千台、サーバ機器はその数倍。 データセンタ集約
  • コンテンツ容量 NAS 静的コンテンツや画像・プログラムなどが置かれる、 ファイルサーバの総容量は500Tbyte以上。
  • データベース容量 データベースにはSANを利用し。 25Tbyteを超えるデータを格納。 DB SAN
  • インフラエンジニアの体制
    • ■ 業務種別
      • ・ サーバエンジニア
      • ・ データベースエンジニア
      • ・ ネットワークエンジニア
      • ・ ストレージエンジア
      • ・ データセンタエンジニア
      • ・ セキュリティエンジニア
    100名以上の専任エンジニアにより、設計・構築から 運用までを自社で実施。 絶賛募集中!
  • サービスインフラの変遷
  • システムインフラ構成 Web App DB SAN NAS 現在は一般的な web アプリケーション構成 (いわゆる三層モデル)
  • 創業期( 1997 年)
    • 最初は 13 店舗のみでした・・・
  • 最初は1台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み 内蔵 ディスク
  • 現在では
      • 店舗数:約 31,000 店
      • 商品数:約 5 , 140 万点
    日本最大のインターネットのショッピングモール
    • 裏側
      • 巨大なリレーショナルデータベース
      • 多くの機能が API 化されている
      • システムの依存関係はかなり複雑化している
  • 楽天市場のシステム 64 インスタンス 買い物かご 店舗ページ 店舗編集 受注処理 オークション 商品登録 各種 API 商品ページ 共同購入 100 以上のドメイン 約 900 インスタンス プレゼント ケータイ ・・・ WebLogic Server SunFire25K
  • 買い物かご処理量
    • 2008 年 12 月現在
    • 月間購入件数     約 900 万件
    • ピークタイムの購入件数 1000 件 / 分 以上
  • 最初は1台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み 内蔵 ディスク
  • 機能分割&負荷分散 アクセス増加にともない、 フロントの Web サーバと バックエンドを機能分割 内蔵 ディスク Web App DB ファイル 共有
  • 機能分割:Webサーバ分割 機能分割して負荷分散できる構成に変更。 ロードバランサによりスケールアウト データ分割によるスケールアップ Web App/DB +ファイル共有
  • 機能分割:NAS導入 DBサーバがもっていたファイル共有機能を切り離して NASを導入。 Web App/DB +ファイル共有 App/DB NAS
  • 機能分割:Appサーバ App サーバ分割してビジネスロジックによる負荷を DB から切り離し。 DB Web NAS App
  • 信頼性向上:SAN導入 SANの導入により、ストレージ部分の信頼性の向上と 性能向上を実施 DB SAN
  • 負荷分散:スレーブDB導入 参照専用のスレーブDBを導入して、負荷分散と耐障害性を同時に向上。 App マスタ DB スレーブ DB SAN
  • バックアップ:世代管理 Phase1 Phase2 Phase3 世代に応じたバックアップ方法の選択 SAN Backup ストレージ Tape 装置 DB + SAN NAS
  • バックアップ:サイト間バックアップ データセンタ間での相互バックアップ データセンタ A データセンタB DB + SAN 、 NAS BackUp 外部倉庫 BackUp Tape Tape
  • トラフィック対応 画像トラフィックの増大により、今度は Web/NAS がボトルネックに。 Web NAS
  • トラフィック対応:キャッシュサーバ キャッシュサーバを導入して負荷軽減 Web NAS Cache
  • トラフィック対応:多段キャッシュ キャッシュを親子構成にして多段化 Web 親 Cache 小 Cache
  • トラフィック対応:CARP導入 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%
        • 再構築、冗長化
  • さまざまな要望に対して
    • 短いものは1週間、長くても 3 ヶ月くらいのプロジェクトを組んで実施
    • ブランチ分岐とマージの計画を立てたり、依存関係に注意しながら
    • それを 200 人くらいでこなしている
  • 運用
    • 障害対応訓練などを定期的に行っている
    • トラブル時の初動、体制構築は俊敏
    • リリースは計画的に
    • 手順作成、ダブルチェック、リハーサル
  • 定期メンテナンス風景
  • セキュリティ: Rakuten-CERT SS 担当 システムセキュリティグループ 楽天 CSIRT セキュリティチーム(各グループのセキュリティ担当) SS 担当 SS 担当 SS 担当 SS 担当 社内に CSIRT を設立。日本 CSIRT 協議会へも加盟し、関係団体との連携を強化しています。 JPCERT/CC 他の CSIRT IPA
  • 仮想化関連技術の利用
  • サーバ仮想化:目的
    • ハードウェアコストの削減
    • データセンタコストの削減
    • エネルギー削減(グリーン IT )
    • 構築スケジュールの短縮
    • 運用管理工数削減
    • 設定変更時の作業影響・調整工数削減
    主にコスト抑制を期待して3年前から検証を開始。 ( XenServer )
  • サーバ仮想化:導入経緯 3年前から検証を開始し、段階を踏んで順次導入。 2008 2007 2009 2010 技術比較・ 機能検証 開発環境や新規 サービスへ展開 主要サービスを 移行 プライベート クラウドへ
  • サーバ仮想化:おさらい 従来システム (ハードウェアとOSは1対1) 仮想化システム (同一ハードウェアに異なるOSを複数搭載可能) ハードウェア OS ( CPU 25% ) アプリケーション OS ( CPU 25% ) アプリケーション OS ( CPU 50% ) アプリケーション XenServer ハードウェア アプリケーション アプリケーション OS ベースに Xen/ XenServerを採用
  • サーバ仮想化:現状調査 使用率10% まずは、特定サービスを対象にサンプル調査。 意外と可動率が低いものも多かった。
  • サーバ仮想化:サーバ集約 CPU 使用率の低いサーバを、仮想化を利用して集約 新型機 旧世代機
  • サーバ仮想化:相互影響排除 ハードウェア OS ( CPU 25% ) アプリケーション OS ( CPU 25% ) アプリケーション OS ( CPU 50% ) アプリケーション XenServer 仮想化システム リソースや設定を個別に管理可能 ハードウェア アプリケーション アプリケーション 従来システム 相乗りは可能だが同一リソースを利用 OS 高負荷! 高負荷! 影響 影響 影響 負荷や設定変更による相互影響を排除
  • サーバ仮想化:構築期間短縮 従来 仮想化 サーバ構築にかかる工数と期間を大幅に短縮 環境 コピー パラメータ 設定 機器調達 設置・配線 設置・配線 インストール パラメータ 設定
  • サーバ仮想化:マイグレーション対応 XenServer OS XenServer OS ハードウェア ハードウェア ハードウェアの違いを仮想化ソフトが吸収するため、 移行が簡単
  • サーバ仮想化:振り返り サーバ集約以上に効果を感じたのは、
    • ハードを切り離せたことで フリーの linux が使いやすい
      • HW 仕様変更による OS との相性問題
      • OS バージョンアップによる HW との相性問題
      • から開放
    • サーバ 構築が簡単
    • 1サービスの負荷に他が 引きずられない
    • サーバを増やすのが簡単。同時に 減らすのも簡単 。
  • その他の技術の利用
  • ROMA
    • Rakuten On-Memory Architecture
    • 共有データを 複数のマシンのメモリに分散 して保存し、高速に読み書き
    • 開発言語に Ruby を使用して開発。
    • スケールアウトが容易 で、 耐障害性 が高い。
    • オープンソース ・ソフトウエアとして公開。
    独自開発した分散キー・バリュー型データストア (KVS)
  • ROMA:基本的な動き Web 「キー」と「値」のペアのシンプルなデータベースで 「高速アクセスが可能」
  • ROMA:特徴 自動切り離し 障害発生 複数サーバを1つのデータベースにみたて、 「障害耐性」 が高い構成を 「低コスト」 に実現。 ホットスケール A B C B A A C C
  • ROMA:導入例 【 PC 】 【閲覧履歴】 楽天 ID で データを共有 トラベルや市場の閲覧履歴など複数サービスで活用 【モバイル】
  • ROMA ( KVS )とRDBの比較 ROMA :機能比較 ○ ○ 1.アクセス速度 × ○ 2.負荷分散化コスト ○ × 3.複雑な検索や集計 △ ROMA (KVS) 4.データ「品質」確保 ○ RDB
  • 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 数の抑制 )
  • 今後の課題
  • 今後の課題
    • インターネットスケーラブルコンピューティング
      • 多量なコモディティサーバーによる高い可用性を持ち、スケーラブルなコンピューティングスタイル
        • データーセンター
        • 運用
        • コスト
        • 素早い開発
  • 今後の課題
    • クラウドという言葉も無い時代から拡張を続けてきて、複雑化している。
      • レガシーシステムのモダン化
    • スケーラビリティ
      • ユーザー数、店舗数、トランザクションの急増
    • 運用
      • 運用による価値の創造
  • まとめ
    • 本日はこんなお話をさせていただきました
      • 楽天のグループご紹介
      • システム規模
      • サービスインフラの変遷
      • 仮想化関連技術の活用
      • 今後の課題
  •  
  •