13:30-14:10
- Redis
- HBase
- LOG aggregation * ミドルレベルの開発に集中
-
サーバへの記憶領域が必要
- 非同期メッセージ
- マルチデバイス, PCへの対応
-
low latency
-
0-downtime
- ストレージレベルでのフェイルオーバー
- redis
- キャッシュ・キュー
- Master-Slaveをshardとして持つ
-
HBase
- NoSQL統計、ビックデータ
- 書き込み性能が早い
- HLogへの書き込みのみ同期的とすることで高速化する
-
Line Data
- Message, Message Box Operation
- どういった操作を行ったか。同期するために使う
- 数百TB
- Redis + HBase
- User Social graph
- ユーザーテーブルにしても数億テーブル
- ソーシャルグラフにするとその数百倍
- ランダムアクセスの性能が必要
- Redis + HBase
- stats
- 統計、ログデータを管理
- 10PB程度
- 必要に応じてインデキシング
- Hbase +HDFS
- Message, Message Box Operation
-
Tune up Redis , HBase
- Redisはシングルスレッド
- ノード障害と遅いレスポンスを早く検知する
- cluster-managerデーモン、通知をズーキーパーで
- 他のストレージにリクエストをリダイレクトし、アプリケーションサーバをブロックしない
- Redis Luaを採用。IOのオーバーヘッドを削減。同じキーに軽量なトランザクションを持つ。
-
LINE Redis cluster status
- 30 cluster, 4775 shards, 48TB memory use
-
Redis monitoring toolを自前で用意している
- 個別のShard自体の頁もある。Masterへの昇格も行える
-
HBaseのチューニング
- zookeeper <=> regionserver
- API Server <=> regionserver
- HLogsが増えると線形でrecovery timeがかかる
- regionの書き込み頻度を揃える
- 分散ログsplitting, replayを使う
- データのローカリティを保つ
- HBaseのMajor compactionを使うと解決できる
-
Dual HBase cluster
- 単一・複数のサーバー障害に耐える
- HBase、クライアントのバグに耐える
- ヒューマンエラーに耐える
- クライアントレベルで2つのノードに書いている
- HBase 0.90を採用
- かなり古い
- 1.0は検証段階
- Dockerを用いてローカルに開発環境に簡単に作る
- Table Schemaの設計
- アクセス単位で1つのTable, Rowに収める
- HBaseのタイムスタンプを活用
- 非同期、リトライが常にあるため同じタイムスタンプを使う
- HBaseのScan, Filterを使用する
- 複数のkeyvalueを取得するときは1回のRPCで効率良く取れるようにする
- HBaseのカウンターを利用しない
- ディスクベースのストレージなので、カウンターはとても遅い(Redisの100倍程度)
- カウンターはRedisを利用する
-
メッセージカラムの設計例
- 未読数の計算をカウントではなく、最新のメッセージIDと最新の既読メッセージIDの差から計算
- 運用で起こった問題に対応
-
clusterのセットアップにはchefを利用
-
障害対応
- 統計クラスタは自動化。サービスクラスタは半自動化。
-
HBaseのスケールアウト
- ユーザが増える度にHBaseを起動
- DataCenterの物理キャパシティが悪化
-
ioDriveの導入
- ディスク障害が1日数回から数週間に1度へ
- サーバーの台数を1/2に削減
-
サービス用
- 15 cluster, 1300 iodrive, node 1PB
-
統計用
- 1 cluster 1-6 TB satax12 per node 10PB user
-
0.90 -> 1.0以上に上げる
- recovery timeを改善できる
-
offheap cacheをサポート
- サーバ台数を減らせる
-
clusterレベルのmigrationが必要
-
互換性がない部分がある