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

3,183 views

Published on

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

Published in: Technology
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,183
On SlideShare
0
From Embeds
0
Number of Embeds
422
Actions
Shares
0
Downloads
2
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • 裏側では、同じスキーマを持った巨大なデータベース郡があったり、 会員情報やポイントや各種機能などかなりの数の 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回@楽天

    1. 1. 楽天インターネットスケーラブル コンピューティング 楽天株式会社 開発部 吉岡弘隆| April 23, 2010
    2. 2. 目次 <ul><li>本日はこんなお話をさせていただきます。 </li></ul><ul><ul><li>楽天のグループご紹介 </li></ul></ul><ul><ul><li>システム規模 </li></ul></ul><ul><ul><li>サービスインフラの変遷 </li></ul></ul><ul><ul><li>仮想化関連技術の活用 </li></ul></ul><ul><ul><li>今後の課題 </li></ul></ul>
    3. 3. 自己紹介 <ul><li>開発部、 ACT 課アーキテクト G 、技術理事 よしおかひろたか </li></ul><ul><li>2009 年 8 月入社 </li></ul><ul><li>カーネル読書会の主宰者、 DEBUG HACKS 共著 ISBN978-4-87311-404-0 </li></ul><ul><li>twitter @hyoshiok http:// d.hatena.ne.jp/hyoshiok </li></ul>
    4. 4. 楽天グループのご紹介
    5. 5. 会社紹介(13年目) 楽天株式会社/楽天グループ ・ 1997 年創業( 13 年目) ・従業員数 ( 2008 年 12 月末現在 ) 単体: 2,081 人 連結: 4,874 人 ・拠点  東京、札幌、仙台、横浜、埼玉、新潟、名古屋、京都、大阪、神戸、広島、松山、福岡、鹿児島、沖縄 ニューヨーク、ボストン、シカゴ、サンフラン シスコ、ルクセンブルク、ロンドン、台湾、上海、ソウル、グアム
    6. 6. ブランド力の向上 楽天市場は国内 Web ブランド指数にて 1 位を獲得。 他サービスもランク上位に! *:日経 BP コンサルティング調べ――「 Web ブランド調査 2010―I 」( 2009 年 10 月実施)
    7. 7. ブランド力の向上 チームも上位に!!
    8. 8. 国内グループ流通総額推移 遂に 1 兆 1,000 億円を突破
    9. 9. 楽天会員の増加 楽天会員は 4,700 万人を突破
    10. 10. <ul><li>2008 年:台湾、海外配送 </li></ul><ul><ul><li>台湾版「楽天市場」オープン </li></ul></ul><ul><ul><li>国内商品の海外配送サービスも拡充 </li></ul></ul><ul><li>2009 年:タイ </li></ul><ul><ul><li>TARAD.com と提携による EC 事業展開 </li></ul></ul><ul><li>2010 年:中国 </li></ul><ul><ul><li>「百度(バイドゥ)」との合弁会社設立を発表 </li></ul></ul>EC事業の国際展開 日本だけでなく海外の事業者・消費者を Empowerment 最終的にはボーダレス・ショッピングモールを目指す
    11. 11. システム規模
    12. 12. トラフィック ピークトラフィックは上昇の一方。 年間トレンドでは年末商戦がピーク。
    13. 13. システム機器 現在ではネットワーク機器が数千台、サーバ機器はその数倍。 データセンタ集約
    14. 14. コンテンツ容量 NAS 静的コンテンツや画像・プログラムなどが置かれる、 ファイルサーバの総容量は500Tbyte以上。
    15. 15. データベース容量 データベースにはSANを利用し。 25Tbyteを超えるデータを格納。 DB SAN
    16. 16. インフラエンジニアの体制 <ul><li>■ 業務種別 </li></ul><ul><ul><li>・ サーバエンジニア </li></ul></ul><ul><ul><li>・ データベースエンジニア </li></ul></ul><ul><ul><li>・ ネットワークエンジニア </li></ul></ul><ul><ul><li>・ ストレージエンジア </li></ul></ul><ul><ul><li>・ データセンタエンジニア </li></ul></ul><ul><ul><li>・ セキュリティエンジニア </li></ul></ul>100名以上の専任エンジニアにより、設計・構築から 運用までを自社で実施。 絶賛募集中!
    17. 17. サービスインフラの変遷
    18. 18. システムインフラ構成 Web App DB SAN NAS 現在は一般的な web アプリケーション構成 (いわゆる三層モデル)
    19. 19. 創業期( 1997 年) <ul><li>最初は 13 店舗のみでした・・・ </li></ul>
    20. 20. 最初は1台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み 内蔵 ディスク
    21. 21. 現在では <ul><ul><li>店舗数:約 31,000 店 </li></ul></ul><ul><ul><li>商品数:約 5 , 140 万点 </li></ul></ul>日本最大のインターネットのショッピングモール
    22. 22. <ul><li>裏側 </li></ul><ul><ul><li>巨大なリレーショナルデータベース </li></ul></ul><ul><ul><li>多くの機能が API 化されている </li></ul></ul><ul><ul><li>システムの依存関係はかなり複雑化している </li></ul></ul>
    23. 23. 楽天市場のシステム 64 インスタンス 買い物かご 店舗ページ 店舗編集 受注処理 オークション 商品登録 各種 API 商品ページ 共同購入 100 以上のドメイン 約 900 インスタンス プレゼント ケータイ ・・・ WebLogic Server SunFire25K
    24. 24. 買い物かご処理量 <ul><li>2008 年 12 月現在 </li></ul><ul><li>月間購入件数     約 900 万件 </li></ul><ul><li>ピークタイムの購入件数 1000 件 / 分 以上 </li></ul>
    25. 25. 最初は1台のサーバから Web App DB 全ての機能を 1 台のサーバに詰め込み 内蔵 ディスク
    26. 26. 機能分割&負荷分散 アクセス増加にともない、 フロントの Web サーバと バックエンドを機能分割 内蔵 ディスク Web App DB ファイル 共有
    27. 27. 機能分割:Webサーバ分割 機能分割して負荷分散できる構成に変更。 ロードバランサによりスケールアウト データ分割によるスケールアップ Web App/DB +ファイル共有
    28. 28. 機能分割:NAS導入 DBサーバがもっていたファイル共有機能を切り離して NASを導入。 Web App/DB +ファイル共有 App/DB NAS
    29. 29. 機能分割:Appサーバ App サーバ分割してビジネスロジックによる負荷を DB から切り離し。 DB Web NAS App
    30. 30. 信頼性向上:SAN導入 SANの導入により、ストレージ部分の信頼性の向上と 性能向上を実施 DB SAN
    31. 31. 負荷分散:スレーブDB導入 参照専用のスレーブDBを導入して、負荷分散と耐障害性を同時に向上。 App マスタ DB スレーブ DB SAN
    32. 32. バックアップ:世代管理 Phase1 Phase2 Phase3 世代に応じたバックアップ方法の選択 SAN Backup ストレージ Tape 装置 DB + SAN NAS
    33. 33. バックアップ:サイト間バックアップ データセンタ間での相互バックアップ データセンタ A データセンタB DB + SAN 、 NAS BackUp 外部倉庫 BackUp Tape Tape
    34. 34. トラフィック対応 画像トラフィックの増大により、今度は Web/NAS がボトルネックに。 Web NAS
    35. 35. トラフィック対応:キャッシュサーバ キャッシュサーバを導入して負荷軽減 Web NAS Cache
    36. 36. トラフィック対応:多段キャッシュ キャッシュを親子構成にして多段化 Web 親 Cache 小 Cache
    37. 37. トラフィック対応:CARP導入 CARPの導入により、キャッシュ効率を最適化 Web 小 Cache 親 Cache CARP
    38. 38. トラフィック対応: CDN導入 CDN を導入して負荷と設備投資を抑制 CDN Web 小 Cache 親 Cache CARP
    39. 39. トラフィック対応: CDN導入 コストが下がって、レスポンスが向上。 海外でのサービス品質も向上。 台湾でのレスポンス
    40. 40. 楽天市場のシステム 64 インスタンス 買い物かご 店舗ページ 店舗編集 受注処理 オークション 商品登録 各種 API 商品ページ 共同購入 100 以上のドメイン 約 900 インスタンス プレゼント ケータイ ・・・ WebLogic Server SunFire25K
    41. 41. 楽天システムの特性 <ul><li>管理指標 KPI(Key Performance Index) </li></ul><ul><ul><li>流通総額一兆円 </li></ul></ul><ul><ul><ul><li>転換率、ドロップ率、併売率などの流通貢献 </li></ul></ul></ul><ul><ul><ul><li>PV 、会員獲得、グループ間連携 </li></ul></ul></ul><ul><ul><li>コスト / 流通総額 1% 以下 </li></ul></ul><ul><ul><ul><li>性能改善、コストパフォーマンス </li></ul></ul></ul><ul><ul><li>稼働率 99.95% </li></ul></ul><ul><ul><ul><li>再構築、冗長化 </li></ul></ul></ul>
    42. 42. さまざまな要望に対して <ul><li>短いものは1週間、長くても 3 ヶ月くらいのプロジェクトを組んで実施 </li></ul><ul><li>ブランチ分岐とマージの計画を立てたり、依存関係に注意しながら </li></ul><ul><li>それを 200 人くらいでこなしている </li></ul>
    43. 43. 運用 <ul><li>障害対応訓練などを定期的に行っている </li></ul><ul><li>トラブル時の初動、体制構築は俊敏 </li></ul><ul><li>リリースは計画的に </li></ul><ul><li>手順作成、ダブルチェック、リハーサル </li></ul>
    44. 44. 定期メンテナンス風景
    45. 45. セキュリティ: Rakuten-CERT SS 担当 システムセキュリティグループ 楽天 CSIRT セキュリティチーム(各グループのセキュリティ担当) SS 担当 SS 担当 SS 担当 SS 担当 社内に CSIRT を設立。日本 CSIRT 協議会へも加盟し、関係団体との連携を強化しています。 JPCERT/CC 他の CSIRT IPA
    46. 46. 仮想化関連技術の利用
    47. 47. サーバ仮想化:目的 <ul><li>ハードウェアコストの削減 </li></ul><ul><li>データセンタコストの削減 </li></ul><ul><li>エネルギー削減(グリーン IT ) </li></ul><ul><li>構築スケジュールの短縮 </li></ul><ul><li>運用管理工数削減 </li></ul><ul><li>設定変更時の作業影響・調整工数削減 </li></ul>主にコスト抑制を期待して3年前から検証を開始。 ( XenServer )
    48. 48. サーバ仮想化:導入経緯 3年前から検証を開始し、段階を踏んで順次導入。 2008 2007 2009 2010 技術比較・ 機能検証 開発環境や新規 サービスへ展開 主要サービスを 移行 プライベート クラウドへ
    49. 49. サーバ仮想化:おさらい 従来システム (ハードウェアとOSは1対1) 仮想化システム (同一ハードウェアに異なるOSを複数搭載可能) ハードウェア OS ( CPU 25% ) アプリケーション OS ( CPU 25% ) アプリケーション OS ( CPU 50% ) アプリケーション XenServer ハードウェア アプリケーション アプリケーション OS ベースに Xen/ XenServerを採用
    50. 50. サーバ仮想化:現状調査 使用率10% まずは、特定サービスを対象にサンプル調査。 意外と可動率が低いものも多かった。
    51. 51. サーバ仮想化:サーバ集約 CPU 使用率の低いサーバを、仮想化を利用して集約 新型機 旧世代機
    52. 52. サーバ仮想化:相互影響排除 ハードウェア OS ( CPU 25% ) アプリケーション OS ( CPU 25% ) アプリケーション OS ( CPU 50% ) アプリケーション XenServer 仮想化システム リソースや設定を個別に管理可能 ハードウェア アプリケーション アプリケーション 従来システム 相乗りは可能だが同一リソースを利用 OS 高負荷! 高負荷! 影響 影響 影響 負荷や設定変更による相互影響を排除
    53. 53. サーバ仮想化:構築期間短縮 従来 仮想化 サーバ構築にかかる工数と期間を大幅に短縮 環境 コピー パラメータ 設定 機器調達 設置・配線 設置・配線 インストール パラメータ 設定
    54. 54. サーバ仮想化:マイグレーション対応 XenServer OS XenServer OS ハードウェア ハードウェア ハードウェアの違いを仮想化ソフトが吸収するため、 移行が簡単
    55. 55. サーバ仮想化:振り返り サーバ集約以上に効果を感じたのは、 <ul><li>ハードを切り離せたことで フリーの linux が使いやすい </li></ul><ul><ul><li>HW 仕様変更による OS との相性問題 </li></ul></ul><ul><ul><li>OS バージョンアップによる HW との相性問題 </li></ul></ul><ul><ul><li>から開放 </li></ul></ul><ul><li>サーバ 構築が簡単 </li></ul><ul><li>1サービスの負荷に他が 引きずられない </li></ul><ul><li>サーバを増やすのが簡単。同時に 減らすのも簡単 。 </li></ul>
    56. 56. その他の技術の利用
    57. 57. ROMA <ul><li>Rakuten On-Memory Architecture </li></ul><ul><li>共有データを 複数のマシンのメモリに分散 して保存し、高速に読み書き </li></ul><ul><li>開発言語に Ruby を使用して開発。 </li></ul><ul><li>スケールアウトが容易 で、 耐障害性 が高い。 </li></ul><ul><li>オープンソース ・ソフトウエアとして公開。 </li></ul>独自開発した分散キー・バリュー型データストア (KVS)
    58. 58. ROMA:基本的な動き Web 「キー」と「値」のペアのシンプルなデータベースで 「高速アクセスが可能」
    59. 59. ROMA:特徴 自動切り離し 障害発生 複数サーバを1つのデータベースにみたて、 「障害耐性」 が高い構成を 「低コスト」 に実現。 ホットスケール A B C B A A C C
    60. 60. ROMA:導入例 【 PC 】 【閲覧履歴】 楽天 ID で データを共有 トラベルや市場の閲覧履歴など複数サービスで活用 【モバイル】
    61. 61. ROMA ( KVS )とRDBの比較 ROMA :機能比較 ○ ○ 1.アクセス速度 × ○ 2.負荷分散化コスト ○ × 3.複雑な検索や集計 △ ROMA (KVS) 4.データ「品質」確保 ○ RDB
    62. 62. hadoop <ul><li>Google が開発した MapReduce をベースに Java で実装されたオープンソース・ソフトウエア。 </li></ul><ul><li>分散データ処理を容易に開発可能にするフレームワークで、 大規模なデータの解析処理 に特化。 </li></ul><ul><li>Google が検索 index の作成に利用している技術と同等。 </li></ul><ul><li>分散処理を意識せずにプログラムを作成でき、生産性が高い。 </li></ul>オープンソースの分散データ処理技術
    63. 63. hadoop :基本的な動き コモディティサーバを複数台ならべて構築 Master slave データ 結果 データ データ データ データ データ データ データ データ データ データ データ データ
    64. 64. hadoop :導入例 大量データを扱うバッチ処理などで活用し、数日かかっていた処理が数時間に改善。 【商品レコメンド】 数千万商品 × 数千万ユーザーから 「お勧めの商品」をリストアップ 【広告集計】 大量の広告配信ログを解析して、 データ分析やレポート作成
    65. 65. MogileFS <ul><li>perl で実装された 分散ファイルシステム 。 </li></ul><ul><li>複数のファイルサーバを複数と意識せず に利用可能。 </li></ul><ul><li>アプリケーション層で動くので 導入もわりと簡単 。 </li></ul><ul><li>サーバ追加で簡単に拡張。基本的には無停止で追加。 </li></ul><ul><li>ファイルをサーバ間で 自動コピーして冗長化 。 </li></ul>オープンソースの分散ファイルシステム
    66. 66. MogileFS :基本的な動き StrageNode DB PC サーバをベースに安価なファイルシステムを構築 Tracker/Perbal Web A B C B A A C C
    67. 67. MogileFS :導入例 画像共有サービスなどのファイルサーバとして活用。 導入コストを大幅に低減。
    68. 69. ARIA (WEB-shaped file storage system) <ul><li>WEB オンライン処理に特化した分散ファイルストレージ </li></ul><ul><ul><li>メディアストレージ </li></ul></ul><ul><ul><ul><li>写真 </li></ul></ul></ul><ul><ul><ul><li>動画(携帯 , スマートフォンで録画 ) </li></ul></ul></ul><ul><ul><ul><li>Office ファイル </li></ul></ul></ul><ul><li>2009/12 ~ 鋭意開発中・・・楽天技術研究所 (RIT) </li></ul><ul><ul><li>リリース未定 </li></ul></ul><ul><ul><li>コア開発者 1 名、開発者 3 名 ( 計 4 名 ) </li></ul></ul><ul><li>名称の由来 </li></ul><ul><ul><li>Cloud File Storage </li></ul></ul><ul><ul><li>-> AirFS (クラウドとは、 &quot; 空気 &quot; のような存在であるべき ) </li></ul></ul><ul><ul><li>-> &quot;Air == Aria&quot; ( 伊: aria, 英: air, aria, 仏: air ) </li></ul></ul><ul><ul><li>ARIA </li></ul></ul>
    69. 70. ARIA (WEB-shaped file storage system) の特徴 <ul><li>特徴 </li></ul><ul><ul><li>分散 </li></ul></ul><ul><ul><li>スケーラブル </li></ul></ul><ul><ul><ul><li>スケールアウト </li></ul></ul></ul><ul><ul><ul><li>高い耐障害性 </li></ul></ul></ul><ul><ul><li>常に書き込み可能 </li></ul></ul><ul><ul><li>数 MB ~数十 MB のファイルを高速に READ/WRITE </li></ul></ul><ul><li>概要 </li></ul><ul><ul><li>分散アルゴリズム </li></ul></ul><ul><ul><ul><li>Consistent Hashing ( 担当ノード決定) </li></ul></ul></ul><ul><ul><ul><li>Vector Clocks    ( バージョニング) </li></ul></ul></ul><ul><ul><ul><li>Merkle Trees    (同期処理 ) </li></ul></ul></ul><ul><ul><li>Storage Engine </li></ul></ul><ul><ul><ul><li>インデックス ( メモリ、ファイルで管理 ) </li></ul></ul></ul><ul><ul><ul><li>複数ファイルを 1 ファイルに束ねて管理 (disk シーク回数 ,inode 数の抑制 ) </li></ul></ul></ul>
    70. 71. 今後の課題
    71. 72. 今後の課題 <ul><li>インターネットスケーラブルコンピューティング </li></ul><ul><ul><li>多量なコモディティサーバーによる高い可用性を持ち、スケーラブルなコンピューティングスタイル </li></ul></ul><ul><ul><ul><li>データーセンター </li></ul></ul></ul><ul><ul><ul><li>運用 </li></ul></ul></ul><ul><ul><ul><li>コスト </li></ul></ul></ul><ul><ul><ul><li>素早い開発 </li></ul></ul></ul>
    72. 73. 今後の課題 <ul><li>クラウドという言葉も無い時代から拡張を続けてきて、複雑化している。 </li></ul><ul><ul><li>レガシーシステムのモダン化 </li></ul></ul><ul><li>スケーラビリティ </li></ul><ul><ul><li>ユーザー数、店舗数、トランザクションの急増 </li></ul></ul><ul><li>運用 </li></ul><ul><ul><li>運用による価値の創造 </li></ul></ul>
    73. 74. まとめ <ul><li>本日はこんなお話をさせていただきました </li></ul><ul><ul><li>楽天のグループご紹介 </li></ul></ul><ul><ul><li>システム規模 </li></ul></ul><ul><ul><li>サービスインフラの変遷 </li></ul></ul><ul><ul><li>仮想化関連技術の活用 </li></ul></ul><ul><ul><li>今後の課題 </li></ul></ul>

    ×