riakを利用したパーソナライズ事例

ヤフー株式会社

Confidential :Discussion purpose only

Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved.

2014/6/4

Riak を利用したパーソナライズ事例

仁科朋也 [email protected]

Confidential :Discussion purpose only Copyright (C) 2014 Yahoo Japan Corporation. All Rights Reserved.

P2 自己紹介

• 氏名：仁科朋也

• 入社年月： 2010年4月（新卒）

• 担当業務：レコメンデーションシステム • システム設計、開発、運用

• ストレージ設置、運用

• 配信システム(APIのようなもの)の開発、運用


P3 agenda

• システムについて

• パーソナライズ事例

• システム概要

• 格納しているデータ

• Riak について

• サーバ構成と設定・監視

• クライアント

• 運用事例


P4 agenda








• 運用事例


P5 パーソナライズ事例

スマートフォン・タブレットのY!トップページの『あなたにお勧め』


P6 agenda








• 運用事例


P7 レコメンドシステムについて（はじめに）

社外秘の情報を含むため、詳細説明は省かせて頂き、今回は以下の事項をご紹介します

• レコメンドシステム概要 • ユーザデータ作成フロー


P8 レコメンドシステム（概要）

Y!TOP

Riak

ユーザデータ

コンテンツストレージ

コンテンツデータ

Optimizer (API)


P9 ユーザデータ作成フロー(ユーザの行動)

Y!ニュース

・・・

各サービス

Y!検索


P10 ユーザデータ作成フロー(スコアリング)

Y!ニュース

・・・

ログデータ

Hadoop

ユーザデータ

各サービス

Y!検索

ユーザに紐づく、ワードとそのスコア


P11 ユーザデータ作成フロー（アップロード）

Y!ニュース

・・・

ログデータ

Hadoop

ユーザデータ

Riak

ユーザデータ

各サービス

Y!検索

Uploader


P12 ユーザデータ作成フロー（提供）

Y!ニュース

・・・

ログデータ

Hadoop

ユーザデータ

Riak

ユーザデータ

Optimizer (API)

レコメンドデータ生成ロジック

各サービス

Y!検索

Uploader

Y!TOP


P13 agenda



• レコメンドシステムについて

• 格納しているデータについて



• 運用事例


P14 格納するデータ

• データの中身 • ユーザに対するワードとスコア

• 格納の仕方 • Bucket: ユーザを識別するためのユニークID（13〜256Byte）

• Key: スコアの計算ロジック等の識別子（5〜10Byteくらい）

• Object: ワードとスコアの組（平均2KB）

ロジックA

ロジックB

サッカー(0.894), W杯(0.734)

長友佑都(0.842),香川真司(0.795)

Key Object

-> スコアの計算ロジックによって、複数のパターンがつく


P15 格納するデータ

• Write • 50〜100GBのデータを一日数回

• Read • ピーク時1,200 qps（災害時などのピークは2,000qps越え）

• レスポンス300 ms 以内


P16 agenda








• 運用事例


P17 なぜRiak を選んだか

一言でいうと「運用面が魅力的だった」

• 高い耐障害性

• スケーラビリティが高い


P18 agenda








• 運用事例


P19 サーバ構成・設定等

• サーバ22台 • SAS HDD 300GB*4 • メモリ 48GB • Raid 0 • ファイルシステム xfs

• Riak • バージョン 1.4.0 • Ring size 256 • Back end eleveldb • レプリケーション 3





ディスクI/Oのチューニング


P21 ディスクI/Oのチューニング

個人的にディスクI/O のチューニングが Riak のパフォーマンスの大部分を占めていると思っています。

1. Riak の書き込みバッファの変更 2. Raid 構成の変更 3. ファイルシステムの変更 4. I/Oスケジューラの変更


P22 ディスクI/Oのチューニング

1. Riak の書き込みバッファの変更 - write_buffer_size_min - write_buffer_size_max

2. Raid 構成の変更 - Raid0

3. ファイルシステムの変更 - xfs

4. I/Oスケジューラの変更 - deadline


P23 ディスクI/O

現在はピーク時30%前後と落ち着いているが、 90%前後出ていた時期があった・・・

WriteBuffer の変更とRaid の変更のみ

-> xfs はとても効果的


P25 BackEnd について

• Bitcask • bucket + key が全てメモリ上に乗っている • レイテンシ重視のハッシュ構造

• eleveldb • bucket + key が一部しかメモリに乗らない • ツリー型で保持 • bucket + key が多いときに有利

以下の理由からeleveldb を採用 • 様々なロジックを追加したい • ユーザ数の増加


P26 その他のチューニング

• sysctl • ファイルディスクリプタ

• fs.file-max=65535

• ネットワーク関係 • net.core.wmem_max = 33554432 • net.core.rmem_max = 33554432 • net.ipv4.tcp_max_syn_backlog = 40000 • etc …

• 仮想メモリ • vm.swappiness = 0

• iptables • アクセス制限 • ネットワーク制限


P27 パフォーマンステスト時のリソース

リリース前のパフォーマンステスト時のリソースの使用状況（dstat コマンドにて取得） ※メモリを全て解放した後測定しています


P28 パフォーマンステスト時のリソース

リリース前のパフォーマンステスト時のリソースの使用状況（dstat コマンドにて取得） ※メモリを全て解放した後測定しています


P29 リソースの使用状況

• Disk I/O: 30%前後 • CPU: 10%前後 • メモリ： 60%前後 • ネットワーク： 10Mbps〜20Mbps


P30 監視について

• Riak のプロセスが生きているか • 300ms 以内に返せているか • ディスクI/O • メモリ • ネットワーク帯域


P31 agenda








• 運用事例


P32 クライアントについて

基本的にパフォーマンス重視の使用方法 • （システムの都合上）C++ のクライアントを使用

• パフォーマンスを求めるため、Riak への接続はpb を使用

• read quorum = 1 ３つのレプリケーションからの１つでもレスポンスがあればOK

• 使用したクライアントではタイムアウト制御が出来なかったため、boost::thread を利用して強引にタイムアウト制御を実装


P33 agenda








• 運用事例


P34 運用事例

半年以上運用して以下の対応を行いました。 • サーバの追加 • サーバダウン


P35 サーバの追加

1. 監視設定・sysctl 等の設定変更 2. Riak のインストール 3. Riak へサーバを追加する riak-admin cluster join [email protected]

riak-admin cluster plan riak-admin cluster commit


P36 サーバ投入時の帯域

• 新クラスタ作成後、初めてデータを流したとき • 既存クラスタにサーバを追加したとき ->帯域の使用量が多くなる Transfer-limit でしぼる riak-admin transfer-limit [email protected] <設定値>


P37 サーバダウン

深夜に一台のサーバがハードウェア障害によりダウン -> ダウンした時に接続していたクライアントが一度エラーを出力 <応急対応開始> • 他のサーバから問題なく引かれていることを確認 • アラートの通知を切る <応急対応終了> <翌日出社後> • サーバリプレイスを行う

サーバがダウンしたのは一度だけ


P38 最後に

Riak を使ってみてどうだったか

• 運用面が優れている

• チューニング大事

• 社内に頼れる先輩がいてありがたかった


P39

ご清聴ありがとうございました

riakを利用したパーソナライズ事例

Technology