楽天テクノロジーカンファレンス 2008にいってきました
1000人以上のエンジニア、全国各地に開発拠点をもっている
楽天のテクノロジーカンファレンスにいってきました。
分散並列処理フレームワークfaily,P2PオンメモリストレージROMAが
2009年にOpenSource化されるとのことでした。
楽天ウェブサービス
楽天ダイナミックアド
- 楽天版アドセンス
- 記事の内容にマッチした楽天の商品を出す
- 楽天経済圏
- APIを使ったアプリが入り込める
- マッシュアップブームおちちている
- ALL 35,000ID
- Active 5,000ID
- Webサービス経由の流通金額は7.24%
- 3,500万request/day
- ItemSearch,GenreSearch,ItemcodeSearchが人気
- 事例
- ダイナミックアド
- PV1000万/day
- URLベース 180万/day
- domainベース 2万/day
- API専門開発チームあり
- http://webservice.rakuten.co.jp/blog/
- 8人チーム
- 若手４人、シニア３人、新人１人
- エンジニアのみのチーム
- 担当
- webservice
- アフィリエイと
- ダイナミックアド
- 環境
- プロジェクトの立ち上がり
- 基本的にはエンジニアからボトムアップ
- 開発-リリース
- 1プロジェクト数日ー2ヶ月
- 企画、コーディング、リリースまでエンジニアが
- 日次コードレビュー
- 仕事のアウトプット、レビュー、相談事
- ユーザからのフィードバック
- 情報共有
- 朝会
- 今後
会員サービスの外部提供
-
- 会員 4000万人強
- 楽天市場のECエンジン
- 楽天スーパーポイント
ユーザ機能
- 決済STEP
- 購入履歴確認
システム特長
今後
- デジタルコンテンツ以外にも物販
- 案件毎に開発だと 導入の敷居が高い
- ライブラリの公開
レコメンド＆パーソナライゼーション
技術研究所の紹介
- MoreThanWeb
一般的なレコメンドの話
楽天のレコメンド
大規模データへの挑戦
- アルゴリズムを改良
- 形態素解析
- 大規模マシンパワー
- Hadoop
- k-means,ログ解析とかを実施
- Hadoop上の機械学習
- 今後はROMA fealyで
- 4800万会員に2500万商品レコメンデーション
- Hadoop
fairy
fairy特長
- Scailable
- マシンを追加するだけでよい
- プログラマフレンドリ
- リーズナブル/パフォーマンス
fairy使い方
- input.filter.filter.output
- filter interface
- ワードカウントの例
require 'fairy' fairy = Fairy::Fairy.new fairy =fairy.input("data/wc-input") fmap do |i,o| i.each do |e| ... e.push ret end end fsuffle =fmap.group_by{|w| w} freduce = fshuffle.smap(...) freduce.output("data/wc-out")
- 併売データの作成
- あるアイテムがほかのアイテムが同じ人になっている確率
- 現状
- 基本的なI/F filterはOK
- 課題
- 大規模検証
- チューニング
ROMA
背景
- 大量データを格納
- 大量トラフィックにも高速アクセス
- Webコンテンツの特長
- 数百KB程度のデータをPUT/GET
- 高負荷状況でも高速アクセス
- 対障害性
- Webコンテンツの特長
特長
- 複数マシンから構成されるオンメモリストレージ
- P2P
- Ruby
- データへの高速アクセス
- 複数マシンに搭載されているメモリをネットワーク越しに高速アクセス
- AppAPIを利用してROMAへアクセス
- 開発者に分散を意識させない
require 'RClient' rc = ROMA::Client.new roma = rc.open
- データを分散配置
- データを集中化させない
- ボトルネックの回避
- データを集中化させない
- 対障害性
- 同じデータの複製を複数マシンで保持
- 動的にマシンを追加
アーキテクチャ
- P2Pモデルで自立的にノードの状態を管理
- 環状(ConsistentHashing)
- 各ノードは独自に
- ノードの探索はクライアント側
- データ検索のためにノードをホップしない
- 多重化
- クライアントからデータをputされた場合 自分の左右のノードにデータをPUT
- 冗長度は３
- 左右にコピーされるまで クライアントは待つ
- 欠点
- クライアントから直接PUTされるノードがボトルネックになる
- クライアントからデータをputされた場合 自分の左右のノードにデータをPUT
- 動的ノード追加
- ROMAプロセスを立ち上げたら、ハッシュ値を計算し、それをbroadcast
- 早いもの勝ちで新規ノードを取り合う
- ノードに参加したら左右のノードからコピ
- データ領域
- P:自分画担当しているデータ格納領域
- LS:左のノードのコピー
- RS:右のノードのコピー
- コピーがおわったらROMA全体に参加したことを通知
- ROMAプロセスを立ち上げたら、ハッシュ値を計算し、それをbroadcast
楽天グローバルインフラ
- サーバー台数
- APP,Web,DB4000台
- トラフィック
- 12Gps
- 商品画像トラフィックは多い
- データセンターの場所
- 秘密
- データセンター自体も楽天独自運営
- データ量
- コンテンツ量
- ファイルサーバは300Tbyte以上
- HDD 2000個
- DB
- 20Tbyte
- DBサーバがSANにつないで実データはSANに格納
- コンテンツ量
- どこまで内製？
- サーバエンジニア
- データベースエンジニア
- ネットワークエンジニア
- ストレージエンジニア
- データセンターエンジニア
- セキュリティエンジニア
- 合計１００名以上インフラエンジニア！
- インフラ技術の取り組み例
- Webサーバ配下は3+n台
- スイッチが故障しても2/3
- DBサーバ
- SANを導入してクラスタ化
- OracleRAC
- SlaveDB
- 監視してだめだったらアプリケーションが参照先を変更する
- Webサーバ配下は3+n台
- マルチホーム
- AS番号とIP管理質事業者の資格を
- セキュリティ
- 仮想化技術
- 一部本番で導入
- 検証中
- 製品リスクの分散
- マルチベンダー
- 以前製品の仕様変更によりOSがインストールできないことがあった
国際展開
UNIX的なアレ：gihyo.jp出張所：連載｜gihyo.jp … 技術評論社
台湾展開
- Rakuten樂天市場購物網 - 日本必買網路購物網站｜網購平台推薦
- バックエンドシステムは日本と違う
- 文字コード等
設計思想
- 他国展開のベース
- 多言語対応
- CoreSystem
- どこの国でも共通
- LocalSystem
- 各国毎に用意する部分
- Core/Localは試行錯誤
ネットワーク
- 重いとき20秒くらいかかる
- 日本と台湾間でパケットロスが発生！！
- mod_defalate,expire
- 1/15にパフォーマンス向上
ファイルサーバ
- ECは商品画像等細かいファイルがたくさん
- ビジネスの規模でスケール
- 保管方法
- 共有ストレージに頼らない
- 独自分散ファイルシステム
- Webサーバそれぞれにファイルを保存
- masterサーバが落ちてもサービスは落ちない
- どのサーバにどの画像があるのかはProxyサーバｄ管理
- Appからは抽象化レイヤーで管理する
- JavaObjectにて扱える
- Dir構造,etc...
- 設定ファイルで分散
- 自動同期
- masterにファイルをアップロード
- リリースバージョンファイルも同時にアップロード
- Webサーバはmasterサーバをpolling
- 更新があったらファイルとリリースバージョンを取得
- Webサーバではリリースバージョンではない複数バージョンを持っている
- ロールバックが簡単
- masterにファイルをアップロード
リンクシェアのサーバ構築方法
なぜサーバが増えるか
- 開発のためにdev環境
- HAのため
- 災害回避のため多地域
手順
結果
CPU稼動率は７、８割に向上
