登壇者：Shunsuke.N氏
以下、メモと所感。
【メモ】
■LINE Storage
ユーザー同士の非同期なメッセージをやりとりするため、サーバーにメッセージを保存している
マルチデバイスを対象としているため、それに耐えられるストレージが必要
ストレージに求められるもの
・Low latency
・0-downtime フェールオーバーとフォールトトレランス
RedisとHBaseを適材適所で利用している
Redisの利用開始当初、クラスタリング機能がなかったのでシャーディングして使っていた
HBaseは書き込み速度が速い
Redisのデータを冗長化してHBaseにも保存している
■Avaliability enhancement
Redisはシングルスレッドだが、それでもLINEのサービスをまかなえるくらい速い
Redisだけで30クラスタ、4775shards, 48TBmemoryを利用
RedisでLuaを使っている
・Hbaseのチューニング1
zooKeeperとRegionServerのデフォルトタイムアウトは60秒だが、それを短くしている
APIServerとRegionServerとのタイムアウトも短くしている
フルGCでクラストから外されないようなぎりぎりのタイムアウト調整
・HBaseのチューニング2
リージョンの書き込み頻度を揃える
・Dual Hbase clusters
HBaseの冗長化
滅びのコマンドが実行されても大丈夫なように冗長化されてる
RedisとHBaseの両方にリクエストを投げて、早く返ってきたほうを使う
■LINE's Hbase environment
Hbase は古いバージョンなので、最新のソースから反映している
開発環境はDocker
HBaseへのアクセスは全て非同期処理
HBaseのタイムスタンプを活用する
HBaseのカウンターを使わない。悪い場合はRedisの100倍遅い
timestampにシーケンスを使うべきではない
月ごとにテーブルを作って、運用で切り替えることをしていた
■Hbase 拡張
スケールアウトだけでは追いつかない
DCにサーバーが入りきらない、ディスクが頻繁に死ぬ
→ スケールアップに切り替え
■今後のチャレンジ
HBaseを0.9.0から1.0以上にバージョンアップする
【所感】
LINEのストレージの話。Redisだけで48TBものメモリを使っているという途方もない数値。
毎日100億ものメッセージを処理するためにここまでの規模が必要なんですねえ。
規模は増えてるのに、HBaseのエンジニアは増えないと登壇者の方がぼやいてました（苦笑）
