SlideShare a Scribd company logo
HBase at LINE
~ How to grow our storage together with service ~


   中村 俊介, Shunsuke Nakamura
             (LINE, twitter, facebook: sunsuk7tp)

            NHN Japan Corp.
自己紹介
                            中村 俊介

•   2011.10 旧              Japan新卒入社 (2012.1から             Japan)


    •   LINE server engineer, storage team

•   Master of Science@東工大首藤研

    •   Distributed Processing, Cloud Storage, and NoSQL

        •   MyCassandra [CASSANDRA-2995]: A modular NoSQL with
            Pluggable Storage Engine based on Cassandra

•   はてなインターン/インフラアルバイト
NHN/NAVER
•       NAVER Korea: 検索ポータルサイト   •   NHN = Next Human Network
                                 • NAVER
    •    韓国本社の検索シェア7割
                                 • Hangame
    •    元Samsungの社内ベンチャー        • livedoor
    •    NAVER = Navigate + er   • データホテル
•       NAVER Japan              • NHN ST
    •    Japanは今年で3年目            • JLISTING              韓国本社

                                 • メディエータ              Green Factory

    •    経営統合によりNAVERはサービス
         名、グループ、宗教               • 深紅
    •    LINE、まとめ、画像検索、NDrive
LINE is NHN Japan STAND-ALONE
8.17 5,500万users (日本 2,500万users)
                AppStore Ranking - Top 1
Japan,Taiwan,Thailand,, HongKong, Saudi, Malaysia, Bahrain, Jordan, Qatar,
  Singapore, Indonesia, Kazakhstan, Kuwait, Israel, Macau, Ukraine, UAE,
         Switzerland, Australia,Turkey,Vietnam, Germany, Russian
LINE Roadmap
                         2011.6       iPhone first release

Android first release                  2011.8
                                                  WAP
  I join to LINE team.                2011.10



                         Sticker               VOIP
                    Bots (News, Auto-translation, Public account, Gurin)


PC (Win/Mac), Multi device                           Sticker Shop

                                      LINE Card/Camera/Brush
WP first release           2012.6
                                             Timeline
BB first release          2012.8

                     LINE platform
Target of LINE Storage
start
         1. Performing well (put < 1ms, get < 5ms)
         2. A high scalable, available, and eventually
            consistent storage system built around NoSQL
         3. Geological distribution

future
                                                     Global   Japan
                                                     56.8%    43.2%
LINE Storage and NoSQL
1. Performing well

2. A high scalable, available, and eventually
   consistent storage system

3. Geological distribution
At first,

LINE launched with Redis.
Initial LINE Storage
•      Target: 1M DL within 2011
•      Client-side sharding with a few Redis nodes
•      Redis
      •     Performance: O(1) lookup
      •     Availability: Async snapshot + slave nodes (+ backup MySQL)
      •     Capacity: memory + Virtual Memory
                                                 node
                                                queue
                                      app     dispatcher
                                     server    queue
                             ...                               ...
master

                                                     storage              backup

    slave
August
28~29 2011
Kuwait
Saudi Arabia
Qatar
Bahrain…
1Million over
                                  2011




 • Sharded Redis
  •   Shard coordination: ZKs + Manager Daemons
      (shard allocation using consistent hashing, health check&failover)



             x 3 or 5




               x3
October 13
2011
Hong Kong
However, in fact...
  100M DL within 2012

Billions of Messages/Day...
We had encountered so much problems every day
                in 2011.10...

    Redis is
               NOT easily scalable
               NOT persistent

                      And,

                   easily dies
2. A high scalable, available, and eventually
   consistent storage system built around
                  NoSQL




2011年内1Mユーザーを想定したストレージを、
サービス無停止で2012年内1Bユーザーに対応する
Zuckerberg’s Law of Sharing
                    (2011. July.7)

Y = C * 2 ^ X (Y: sharing data, X: time, C: constance)
  Sharing activity will double each year.
LINEのmessage数/月は
    いくら?
10億x30 = 300億
 messages/month
Data and Scalability
•   constant
    •   DATA: async operation

    •   SCALE: thousands ~ millions per each queue

•   linear
    •   DATA: users’ contact and group
                                            10000000000




    •   SCALE: millions ~ billions           7500000000




•   exponential                              5000000000




    •   DATA: message and message inbox      2500000000



    •   SCALE: tens of billion ~                      0

                                                          constant   linear exponential
Data and Workload
                                     Queue
•       constant
    •     FIFO

    •     read&write fast
                                                      Zipfian curve

•       linear
    •     zipf.

    •     read fast [w3~5 : r95]   Message timeline

•       exponential
    •     latest

    •     write fast [w50 : r50]
Choosing Storage
•   constant: Redis
•   linear, exponential: 選択肢幾つか

    •   HBase
        •  ⃝ workload, NoSQL on DFSで運用しやすい (DFSスペシャリスト++)

        •   × SPOF, Random Readの99%ile性能がやや低い

    •   Cassandra
        •  ⃝ workload, No SPOF (No Coordinator, rack/DC-aware replication)

        •   × Weak consistencyに伴う運用コスト, 実装が複雑 (特にCAS操作)

    •   MongoDB
        •   ⃝ 便利機能 (auto-sharding/failover, various query) → 解析向けで不要

        •   × workload, 帯域やディスクの使い方悪い

    •   MySQL Cluster
        •  ⃝ 使い慣れ (1サービス当たり最大数千台弱運用)

        •   × 最初から分散設計でwrite scalableものを使うべき
HBase
•   数百TBを格納可能

•   大量データに対してwrite scalable, 効率的なrandom access

•   Semi-structured model (< MongoDB, Redis)
•   RDBMSの高級機能はもたない (TX, joins)

•   Strong consistency per a row and columnfamily
•   NoSQL constructed on DFS
    •   レプリカ管理不要 / Region移動が楽

•   Multi-partition allocation per RS
    •   ad hocなload balancing
LINE Storage (2012.3)
                        iPhone                      Android                   WAP              x 25    Million


                                   Thrift API / Authentication / Renderer


                   app. server (nginx)          app. server (nginx)     app. server (nginx)

                     Redis Queue                  Redis Queue             Redis Queue          x 100    nodes
async operation
failed operation
                      dispatcher                   dispatcher               dispatcher


                             Sharded Redis clusters (message, contact, group)                  x 400    nodes



                     Contact HBase              Message HBase
                                                                        Backup MySQL
                                         HDFS           x 100   nodes           x2   nodes    backup operation
LINE Storage (2012.7)
                      phone (iPhone/Android/WP/blackberry/WAP)              PC (win/mac)          x 50    Million


                                   Thrift API / Authentication / Renderer


                   app. server (nginx)         app. server (nginx)         app. server (nginx)

                     Redis Queue                  Redis Queue                  Redis Queue        x 200    nodes
async operation
failed operation
                      dispatcher                  dispatcher                   dispatcher


                             Sharded Redis clusters (message, contact, group)                     x 600    nodes



                    Msg HBase01          Primary HBase           Msg HBase02
                                                                                    Backup
                                                                                    MySQL
                            HDFS01                           HDFS02                 x2   nodes   backup operation


                                                          x 200    nodes
2012.3 → 2012.7
•   ユーザー数2倍、インフラ2倍

    •   まだHBaseにとってCasual Data

•   Message HBaseはdual cluster

    •   message TTLに応じて切り替え (TTL: 2week → 3week)

    •   HDFS DNはHBase用のM/Rとしても利用

•   Sharded-Redisがまだ基本プライマリ (400→600)

    •   messageはHBaseにもget

    •   他はmodelのみをbackup
LINE Data on HBase
•   LINE data                                 userId          User Model
    •   MODEL:      <key> → <model>                           email   phone

    •   INDEX:      <key>    <property in model>

                                                                      INDEX
        •   User: <userId> → <User obj>, <userId>   <phone>


•   各modelを1つのrowで表現

    •   HBaseのconsistency: 1つのrow, columnFamily単位でstrong consistencyを保証

    •   contactなどの複数modelをもつものはqualifier (column)を利用

    •   レンジクエリが必要なDataは一つのrowにまとめる (e.g. message Inbox)

        •   Cons.) column数に対してリニアにlatency大 → delete, search filter with timestamp
timestamp, version
•   Column level timestamp
    •   modelのtimestampでindexを構築

    •   API実行timestampでasync, failure handling

    •   Search filterとしても利用 (Cons. TTLの利用不可)

•   Multiple versioning
    •   複数emailのbinding (e.g. Google account password history)

    •   CSの為のdata trace
Primary key for LINE
 •     Long Type keyを元に生成: e.g. userId, messageId

 •     simple ^ random for single lookup
       •   range queryのためのlocalityの考慮不要

       •   prefix(key) + key

       •   prefix(key): ALPHABETS[key%26] + key%1000

 •     o.a.h.hbase.util.RegionSplitter.SplitAlgorithmを実装

       •   prefixでRegion splitting

a HRegion                 2600
                          2626
                                        2756
                                        2782   b      2601
                                                             c   2602
                                                                        d   z
                          2652          2808

a000       a250    a500          a750          b000
Data stored in HBase
                         • User, Contact, Group
                          •   linear scale

                          •   mutable



• Message, Inbox
 •   exponential scale

 •   immutable
Message, Inbox
           performance, availability重視




• Sharded-Redisとのhybrid構成
• 片方から読み書きできればOK (< quorum)
• failed queryはJVM Heap,Redisにqueuing&retry
 •   immutable&idempotent query: 整合性, 重複の問題なし
User, Contact
           performanceよりconsistency重視



• Sharded-Redisがまだprimary
 •   scalabilityの問題はない

 •   mutableなので整合性重要


• RedisからHBaseへ移行 (途中)
 •   Model Objectのみbackup
RedisからHBaseへ移行
1. modelのbackup

  •   Redisにsync、HBaseにasync write (Java Future, Redis queuing)

2. M/Rを使ってSharded-Redisからfull migration

3. modelを元にindex/inverted index building (eventual) ←イマココ

      •   Batch Operation: w/ M/R, model table full-scan using
          TableMapper
      •   Incremental Operation: Diff logging and sequential indexing or
          Percolator, HBase Coprocessor
4. access path切り替え, Redis cache化
HBaseに置き換えたら
  幸せになれた?
ある意味ではYES

• Scalability Issuesが解決
 • 今年いっぱいまでは
 • 広域分散 → 3rd issue (To be continue...)
Failure Decreased?
ABSOLUTELY NOT!
HBaseを8ヶ月運用してみた印象

• HBaseは火山
 •   毎日小爆発

 •   蓄積してたまに大爆発

 •   火山のふもとでの安全な暮らし
爆発
•   断続的なネットワーク障害によるRS退役

•   H/W障害によるDN性能悪化・検知の遅延

•   get (get, increment, checkAndPut, checkAndDelete)性能劣化、
    それに伴う全体性能低下

•   (major) compactionによる性能劣化

•   データ不整合

•   SPOF絡みの問題はまだ起こってない
HBaseのAvailability

• SPOF or 死ぬとdowntimeが発生する箇
 所が幾つか

 1. HDFSのNameNode

 2. HBaseのRegionServer, DataNode
1. HDFS NameNode (NN)


• HA Framework for HDFS NN (HDFS-1623)
 •   Backup NN (0.21)

 •   Avatar NN (Facebook)

 •   HA NN using Linux HA

 •   Active/passive configuration deploying two NN (cloudera)
HA NN using Linux-HA



• DRBD+heartbeatで冗長化
 •   DRBD: disk mirroring (RAID1-like)

 •   heartbeat: network monitoring

 •   pacemaker: resource management (failover logicの登録)
2. RegionServer, DataNode
•   HBase自体がレプリカをもたない

•   failoverされるまでdowntime発生

•   複数コンポーネントで構成されているので、
    故障検知から全体合意まで、それぞれの通信区間でtimeoutを待た
    なければいけない
downtime対策
•   HBase自身がreplicaを持たないのでRS死亡時のdowntimeが必ず発生

    •   distributed HLog splitting (>=cdh3u3)
    •   timeout&retry
        •   ほとんどHClient         RS間のtimeout時間

            •    timeout調整 (retryごと, operationごと)

        •   RS     ZK間は短いとnetworkが不安定なときにRSが排除されやすい

•   同じkeyを持つregionを同じRSに配置 → 障害の限定化

•   LINEのHBase accessは基本的にasync

•   Cluster replication
HBase cluster replication
•   Cluster Replication: master push方式

    •   (MySQLのようなbinary logging mechanism), 馬本8.8章参照

    •   非同期でWAL (HLog)をslave clusterにpush

        •   各RSごとにSynchronous Call

        •   syncされていないWAL ListをZKが管理




• 検証しつつも、
• 独自実装 or 他の手段も考慮中
multi-DC間のreplication向けではない
HDFS tuning for HBase


• Shortcut a local client reads to a Datanodes
  files directly > 0.23.1, 0.22.1, 1.0.0 (HDFS-2246)
• Rack-aware Replica Placement              (HADOOP-692)
削除問題
•   削除が少し低速

    •   論理削除なのでgetほどではないが、putの2倍かかる

    •   例) 1万件のコンタクトをもつユーザー退会処理

        •   カラム多すぎでクライアント側でtimeout → queuing + iterative delete

    •   例) TTLが過ぎたmessage削除

        •   cold dataに対するRandom I/Oが発生し、serviceに影響

        •   → dual cluster, full-truncate or TTL利用

    •   例) スパマー対応

        •   compactionされるまでのget性能 (大量のskip処理)への影響

        •   → column単位ではなく、row単位の削除に
Compaction対策


•   Bigtable: I/O最適化と削除の為に定期的なCompaction処理が必要

•   RSごとにQueuingされ同時に1 HRegionずつCompactionが実行される

•   Compaction実行中にCPU利用率が上がるので、タイミング注意

    •   タイミング: periodic, StoreFile数, ユーザー実行

    •   peak-time時に連続して発生しないよう、
        off-peakにcompactionとregion splitting
Balancing, Splitting, and Compaction
•   Region balancing

    •   自動balancer (request数ベースのbalancing)はOFF

    •   serviceのoff-peak時にbalancing

    •   異なるtableの同一keyは同じserverに割当→障害を限定

    •   問題のあるRegion専用のserver: prison RS

•   Region splittingとcompactionのスケジューリング

    •   自動splitもなるべく避ける      (hbase.hregion.max.filesizeで自動split)


    •   連続的なmajor compactionを避ける

    •   immutable storageはperiodic compactionをOFF
HBase Tools
•   Client:
    •   HBaseTemplate: HBase Wrapper like spring’s RedisTemplate
    •   MirroringHTable: 複数HBase cluster対応

•   運用監視:

    •   auto splitting: off-peak時のregion split

    •   auto HRegion balancer: metricsを元にoff-peak balancing

    •   Region snapshot&restore: META Tableをdaily dump、RS死亡時の復元

    •   Data Migration:
        •     Migrator with M/R (Redis → HBase)
        •     H2H copy tool with M/R: table copy (HBase → HBase)
    •   metrics collecting via JMX
•   Index Builder and Inconsistent Fixer with M/R, incremental implementation (coprocessor)
今後の課題
•   HBase上の<key, model>を中心にindexやRedis上にcacheを構築

•   停電・地震対策 (rack/dc-awareness)

    •   HBase cluster replication

    •   Cassandraをgeological distributed storage for HLogとして利用


•   今以上のスケーラビリティ (数 - 数十億ユーザー)

    •   HBaseはnetwork-boundで1クラスタ数百台弱が限界

    •   Multi-clusterで凌ぐかCassandraを使うか
HBase at LINE

More Related Content

What's hot

インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
Akihiro Kuwano
 
KafkaとPulsar
KafkaとPulsarKafkaとPulsar
KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較
Yoshiyasu SAEKI
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろう
Shingo Omura
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
NTT DATA OSS Professional Services
 
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
NGINX, Inc.
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
Yahoo!デベロッパーネットワーク
 
DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所
hdais
 
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
Yutuki r
 
YJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組みYJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組み
Yahoo!デベロッパーネットワーク
 
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
虎の穴 開発室
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
NTT DATA OSS Professional Services
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
Masahiko Sawada
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
Yuki Morishita
 
ScyllaDBユーザー勉強会 #1
ScyllaDBユーザー勉強会 #1ScyllaDBユーザー勉強会 #1
ScyllaDBユーザー勉強会 #1
Changhwan Lee
 
中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング
勲 國府田
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
NTT DATA Technology & Innovation
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
Kumazaki Hiroki
 
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門Akihiro Kuwano
 

What's hot (20)

インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)インフラエンジニアってなんでしたっけ(仮)
インフラエンジニアってなんでしたっけ(仮)
 
KafkaとPulsar
KafkaとPulsarKafkaとPulsar
KafkaとPulsar
 
KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較KafkaとAWS Kinesisの比較
KafkaとAWS Kinesisの比較
 
分散システムの限界について知ろう
分散システムの限界について知ろう分散システムの限界について知ろう
分散システムの限界について知ろう
 
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
Apache Kafkaって本当に大丈夫?~故障検証のオーバービューと興味深い挙動の紹介~
 
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
講演資料: コスト最適なプライベートCDNを「NGINX」で実現するWeb最適化セミナー
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開ヤフー社内でやってるMySQLチューニングセミナー大公開
ヤフー社内でやってるMySQLチューニングセミナー大公開
 
DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所DNSキャッシュサーバ チューニングの勘所
DNSキャッシュサーバ チューニングの勘所
 
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
 
Cassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sqlCassandraとh baseの比較して入門するno sql
Cassandraとh baseの比較して入門するno sql
 
YJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組みYJTC18 A-1 データセンタネットワークの取り組み
YJTC18 A-1 データセンタネットワークの取り組み
 
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
Supabase Edge Functions と Netlify Edge Functions を使ってみる – 機能とその比較 –
 
Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?Apache Hadoopの未来 3系になって何が変わるのか?
Apache Hadoopの未来 3系になって何が変わるのか?
 
アーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーションアーキテクチャから理解するPostgreSQLのレプリケーション
アーキテクチャから理解するPostgreSQLのレプリケーション
 
Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編Cassandraのしくみ データの読み書き編
Cassandraのしくみ データの読み書き編
 
ScyllaDBユーザー勉強会 #1
ScyllaDBユーザー勉強会 #1ScyllaDBユーザー勉強会 #1
ScyllaDBユーザー勉強会 #1
 
中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング中小規模サービスのApacheチューニング
中小規模サービスのApacheチューニング
 
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
乗っ取れコンテナ!!開発者から見たコンテナセキュリティの考え方(CloudNative Days Tokyo 2021 発表資料)
 
分散システムについて語らせてくれ
分散システムについて語らせてくれ分散システムについて語らせてくれ
分散システムについて語らせてくれ
 
インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門インフラエンジニアのためのcassandra入門
インフラエンジニアのためのcassandra入門
 

Similar to HBase at LINE

分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~
分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~
分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~Masahito Zembutsu
 
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production DeploymentsGuide to Cassandra for Production Deployments
Guide to Cassandra for Production Deployments
smdkk
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR Technologies Japan
 
AWSのNoSQL入門
AWSのNoSQL入門AWSのNoSQL入門
AWSのNoSQL入門
Akihiro Kuwano
 
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
MapR Technologies Japan
 
OpenStack 向けネットワーク入門
OpenStack 向けネットワーク入門OpenStack 向けネットワーク入門
OpenStack 向けネットワーク入門
Dell TechCenter Japan
 
Re invent 2017 データベースサービス総復習!
Re invent 2017 データベースサービス総復習!Re invent 2017 データベースサービス総復習!
Re invent 2017 データベースサービス総復習!
Satoru Ishikawa
 
Cloudian update (Japanese:日本語)
Cloudian update (Japanese:日本語)Cloudian update (Japanese:日本語)
Cloudian update (Japanese:日本語)
CLOUDIAN KK
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
じゅん なかざ
 
Orb dlt technical_overview(特許情報なし)
Orb dlt technical_overview(特許情報なし)Orb dlt technical_overview(特許情報なし)
Orb dlt technical_overview(特許情報なし)
Wataru Fukatsu
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会
Dai Utsui
 
20111130 10 aws-meister-emr_long-public
20111130 10 aws-meister-emr_long-public20111130 10 aws-meister-emr_long-public
20111130 10 aws-meister-emr_long-public
Amazon Web Services Japan
 
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
Amazon Web Services Japan
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)Insight Technology, Inc.
 
NetScaler Basic
NetScaler BasicNetScaler Basic
NetScaler Basic
Kimihiko Kitase
 
InfoTalk springbreak_2012
InfoTalk  springbreak_2012InfoTalk  springbreak_2012
InfoTalk springbreak_2012Hiroshi Bunya
 
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219
Cloudera Japan
 
AWS re:Invent2017で見た AWSの強さとは
AWS re:Invent2017で見た AWSの強さとは AWS re:Invent2017で見た AWSの強さとは
AWS re:Invent2017で見た AWSの強さとは
NTT Communications Technology Development
 
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティSaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
Kuniyasu Suzaki
 
Datastax Enterpriseをはじめよう
Datastax EnterpriseをはじめようDatastax Enterpriseをはじめよう
Datastax Enterpriseをはじめよう
Yuki Morishita
 

Similar to HBase at LINE (20)

分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~
分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~
分散KVSをサービス化してみた ~Okuyama(KVS)もFusion-IO(ioDrive)もあるんだよ~
 
Guide to Cassandra for Production Deployments
Guide to Cassandra for Production DeploymentsGuide to Cassandra for Production Deployments
Guide to Cassandra for Production Deployments
 
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
MapR アーキテクチャ概要 - MapR CTO Meetup 2013/11/12
 
AWSのNoSQL入門
AWSのNoSQL入門AWSのNoSQL入門
AWSのNoSQL入門
 
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
事例から見るNoSQLの使い方 - db tech showcase Tokyo 2015 2015/06/11
 
OpenStack 向けネットワーク入門
OpenStack 向けネットワーク入門OpenStack 向けネットワーク入門
OpenStack 向けネットワーク入門
 
Re invent 2017 データベースサービス総復習!
Re invent 2017 データベースサービス総復習!Re invent 2017 データベースサービス総復習!
Re invent 2017 データベースサービス総復習!
 
Cloudian update (Japanese:日本語)
Cloudian update (Japanese:日本語)Cloudian update (Japanese:日本語)
Cloudian update (Japanese:日本語)
 
PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門PHP開発者のためのNoSQL入門
PHP開発者のためのNoSQL入門
 
Orb dlt technical_overview(特許情報なし)
Orb dlt technical_overview(特許情報なし)Orb dlt technical_overview(特許情報なし)
Orb dlt technical_overview(特許情報なし)
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会
 
20111130 10 aws-meister-emr_long-public
20111130 10 aws-meister-emr_long-public20111130 10 aws-meister-emr_long-public
20111130 10 aws-meister-emr_long-public
 
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
20210127 AWS Black Belt Online Seminar Amazon Redshift 運用管理
 
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
[INSIGHT OUT 2011] A12 ひとつのデータベース技術では生き残れない part1 カラムナーデータベース(Shinkubo)
 
NetScaler Basic
NetScaler BasicNetScaler Basic
NetScaler Basic
 
InfoTalk springbreak_2012
InfoTalk  springbreak_2012InfoTalk  springbreak_2012
InfoTalk springbreak_2012
 
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219
 
AWS re:Invent2017で見た AWSの強さとは
AWS re:Invent2017で見た AWSの強さとは AWS re:Invent2017で見た AWSの強さとは
AWS re:Invent2017で見た AWSの強さとは
 
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティSaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
SaaS/クラウドコンピューティングでのオープンソース活用とセキュリティ
 
Datastax Enterpriseをはじめよう
Datastax EnterpriseをはじめようDatastax Enterpriseをはじめよう
Datastax Enterpriseをはじめよう
 

More from Shun Nakamura

MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
Shun Nakamura
 
シリコンバレーに行ってきた!
シリコンバレーに行ってきた!シリコンバレーに行ってきた!
シリコンバレーに行ってきた!
Shun Nakamura
 
MyCassandra (Full English Version)
MyCassandra (Full English Version)MyCassandra (Full English Version)
MyCassandra (Full English Version)
Shun Nakamura
 
第17回Cassandra勉強会: MyCassandra
第17回Cassandra勉強会: MyCassandra第17回Cassandra勉強会: MyCassandra
第17回Cassandra勉強会: MyCassandra
Shun Nakamura
 
MyCassandra
MyCassandraMyCassandra
MyCassandra
Shun Nakamura
 
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
Shun Nakamura
 
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
Shun Nakamura
 
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
Shun Nakamura
 
Cassandra勉強会
Cassandra勉強会Cassandra勉強会
Cassandra勉強会
Shun Nakamura
 
ComSys WIP
ComSys WIPComSys WIP
ComSys WIP
Shun Nakamura
 

More from Shun Nakamura (10)

MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
MyCassandra: A Cloud Storage Supporting both Read Heavy and Write Heavy Workl...
 
シリコンバレーに行ってきた!
シリコンバレーに行ってきた!シリコンバレーに行ってきた!
シリコンバレーに行ってきた!
 
MyCassandra (Full English Version)
MyCassandra (Full English Version)MyCassandra (Full English Version)
MyCassandra (Full English Version)
 
第17回Cassandra勉強会: MyCassandra
第17回Cassandra勉強会: MyCassandra第17回Cassandra勉強会: MyCassandra
第17回Cassandra勉強会: MyCassandra
 
MyCassandra
MyCassandraMyCassandra
MyCassandra
 
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
読み出し性能と書き込み性能を両立させるクラウドストレージ (SACSIS2011-A6-1)
 
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
読み出し性能と書き込み性能を両立させるクラウドストレージ (OS-117-24)
 
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
読み出し性能と書き込み性能を選択可能なクラウドストレージ (DEIM2011-C3-3)
 
Cassandra勉強会
Cassandra勉強会Cassandra勉強会
Cassandra勉強会
 
ComSys WIP
ComSys WIPComSys WIP
ComSys WIP
 

Recently uploaded

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
Toru Tamaki
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
harmonylab
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
chiefujita1
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
t m
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
CRI Japan, Inc.
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
tazaki1
 
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
嶋 是一 (Yoshikazu SHIMA)
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
Takayuki Nakayama
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
Matsushita Laboratory
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
Osaka University
 

Recently uploaded (10)

論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
論文紹介:Deep Learning-Based Human Pose Estimation: A Survey
 
Generating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language ModelsGenerating Automatic Feedback on UI Mockups with Large Language Models
Generating Automatic Feedback on UI Mockups with Large Language Models
 
This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.This is the company presentation material of RIZAP Technologies, Inc.
This is the company presentation material of RIZAP Technologies, Inc.
 
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
遺伝的アルゴリズムと知識蒸留による大規模言語モデル(LLM)の学習とハイパーパラメータ最適化
 
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアルLoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
LoRaWAN 4チャンネル電流センサー・コンバーター CS01-LB 日本語マニュアル
 
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライドHumanoid Virtual Athletics Challenge2024 技術講習会 スライド
Humanoid Virtual Athletics Challenge2024 技術講習会 スライド
 
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
「進化するアプリ イマ×ミライ ~生成AIアプリへ続く道と新時代のアプリとは~」Interop24Tokyo APPS JAPAN B1-01講演
 
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援しますキンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
キンドリル ネットワークアセスメントサービスご紹介 今のネットワーク環境は大丈夫? 調査〜対策までご支援します
 
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
ReonHata_便利の副作用に気づかせるための発想支援手法の評価---行為の増減の提示による気づきへの影響---
 
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
生成AIがもたらすコンテンツ経済圏の新時代  The New Era of Content Economy Brought by Generative AI
 

HBase at LINE

  • 1. HBase at LINE ~ How to grow our storage together with service ~ 中村 俊介, Shunsuke Nakamura (LINE, twitter, facebook: sunsuk7tp) NHN Japan Corp.
  • 2. 自己紹介 中村 俊介 • 2011.10 旧 Japan新卒入社 (2012.1から Japan) • LINE server engineer, storage team • Master of Science@東工大首藤研 • Distributed Processing, Cloud Storage, and NoSQL • MyCassandra [CASSANDRA-2995]: A modular NoSQL with Pluggable Storage Engine based on Cassandra • はてなインターン/インフラアルバイト
  • 3. NHN/NAVER • NAVER Korea: 検索ポータルサイト • NHN = Next Human Network • NAVER • 韓国本社の検索シェア7割 • Hangame • 元Samsungの社内ベンチャー • livedoor • NAVER = Navigate + er • データホテル • NAVER Japan • NHN ST • Japanは今年で3年目 • JLISTING 韓国本社 • メディエータ Green Factory • 経営統合によりNAVERはサービス 名、グループ、宗教 • 深紅 • LINE、まとめ、画像検索、NDrive
  • 4. LINE is NHN Japan STAND-ALONE
  • 5. 8.17 5,500万users (日本 2,500万users) AppStore Ranking - Top 1 Japan,Taiwan,Thailand,, HongKong, Saudi, Malaysia, Bahrain, Jordan, Qatar, Singapore, Indonesia, Kazakhstan, Kuwait, Israel, Macau, Ukraine, UAE, Switzerland, Australia,Turkey,Vietnam, Germany, Russian
  • 6. LINE Roadmap 2011.6 iPhone first release Android first release 2011.8 WAP I join to LINE team. 2011.10 Sticker VOIP Bots (News, Auto-translation, Public account, Gurin) PC (Win/Mac), Multi device Sticker Shop LINE Card/Camera/Brush WP first release 2012.6 Timeline BB first release 2012.8 LINE platform
  • 7. Target of LINE Storage start 1. Performing well (put < 1ms, get < 5ms) 2. A high scalable, available, and eventually consistent storage system built around NoSQL 3. Geological distribution future Global Japan 56.8% 43.2%
  • 8. LINE Storage and NoSQL 1. Performing well 2. A high scalable, available, and eventually consistent storage system 3. Geological distribution
  • 10. Initial LINE Storage • Target: 1M DL within 2011 • Client-side sharding with a few Redis nodes • Redis • Performance: O(1) lookup • Availability: Async snapshot + slave nodes (+ backup MySQL) • Capacity: memory + Virtual Memory node queue app dispatcher server queue ... ... master storage backup slave
  • 12. 1Million over 2011 • Sharded Redis • Shard coordination: ZKs + Manager Daemons (shard allocation using consistent hashing, health check&failover) x 3 or 5 x3
  • 14. However, in fact... 100M DL within 2012 Billions of Messages/Day...
  • 15. We had encountered so much problems every day in 2011.10... Redis is NOT easily scalable NOT persistent And, easily dies
  • 16. 2. A high scalable, available, and eventually consistent storage system built around NoSQL 2011年内1Mユーザーを想定したストレージを、 サービス無停止で2012年内1Bユーザーに対応する
  • 17. Zuckerberg’s Law of Sharing (2011. July.7) Y = C * 2 ^ X (Y: sharing data, X: time, C: constance) Sharing activity will double each year.
  • 18. LINEのmessage数/月は いくら?
  • 19. 10億x30 = 300億 messages/month
  • 20. Data and Scalability • constant • DATA: async operation • SCALE: thousands ~ millions per each queue • linear • DATA: users’ contact and group 10000000000 • SCALE: millions ~ billions 7500000000 • exponential 5000000000 • DATA: message and message inbox 2500000000 • SCALE: tens of billion ~ 0 constant linear exponential
  • 21. Data and Workload Queue • constant • FIFO • read&write fast Zipfian curve • linear • zipf. • read fast [w3~5 : r95] Message timeline • exponential • latest • write fast [w50 : r50]
  • 22. Choosing Storage • constant: Redis • linear, exponential: 選択肢幾つか • HBase • ⃝ workload, NoSQL on DFSで運用しやすい (DFSスペシャリスト++) • × SPOF, Random Readの99%ile性能がやや低い • Cassandra • ⃝ workload, No SPOF (No Coordinator, rack/DC-aware replication) • × Weak consistencyに伴う運用コスト, 実装が複雑 (特にCAS操作) • MongoDB • ⃝ 便利機能 (auto-sharding/failover, various query) → 解析向けで不要 • × workload, 帯域やディスクの使い方悪い • MySQL Cluster • ⃝ 使い慣れ (1サービス当たり最大数千台弱運用) • × 最初から分散設計でwrite scalableものを使うべき
  • 23. HBase • 数百TBを格納可能 • 大量データに対してwrite scalable, 効率的なrandom access • Semi-structured model (< MongoDB, Redis) • RDBMSの高級機能はもたない (TX, joins) • Strong consistency per a row and columnfamily • NoSQL constructed on DFS • レプリカ管理不要 / Region移動が楽 • Multi-partition allocation per RS • ad hocなload balancing
  • 24. LINE Storage (2012.3) iPhone Android WAP x 25 Million Thrift API / Authentication / Renderer app. server (nginx) app. server (nginx) app. server (nginx) Redis Queue Redis Queue Redis Queue x 100 nodes async operation failed operation dispatcher dispatcher dispatcher Sharded Redis clusters (message, contact, group) x 400 nodes Contact HBase Message HBase Backup MySQL HDFS x 100 nodes x2 nodes backup operation
  • 25. LINE Storage (2012.7) phone (iPhone/Android/WP/blackberry/WAP) PC (win/mac) x 50 Million Thrift API / Authentication / Renderer app. server (nginx) app. server (nginx) app. server (nginx) Redis Queue Redis Queue Redis Queue x 200 nodes async operation failed operation dispatcher dispatcher dispatcher Sharded Redis clusters (message, contact, group) x 600 nodes Msg HBase01 Primary HBase Msg HBase02 Backup MySQL HDFS01 HDFS02 x2 nodes backup operation x 200 nodes
  • 26. 2012.3 → 2012.7 • ユーザー数2倍、インフラ2倍 • まだHBaseにとってCasual Data • Message HBaseはdual cluster • message TTLに応じて切り替え (TTL: 2week → 3week) • HDFS DNはHBase用のM/Rとしても利用 • Sharded-Redisがまだ基本プライマリ (400→600) • messageはHBaseにもget • 他はmodelのみをbackup
  • 27. LINE Data on HBase • LINE data userId User Model • MODEL: <key> → <model> email phone • INDEX: <key> <property in model> INDEX • User: <userId> → <User obj>, <userId> <phone> • 各modelを1つのrowで表現 • HBaseのconsistency: 1つのrow, columnFamily単位でstrong consistencyを保証 • contactなどの複数modelをもつものはqualifier (column)を利用 • レンジクエリが必要なDataは一つのrowにまとめる (e.g. message Inbox) • Cons.) column数に対してリニアにlatency大 → delete, search filter with timestamp
  • 28. timestamp, version • Column level timestamp • modelのtimestampでindexを構築 • API実行timestampでasync, failure handling • Search filterとしても利用 (Cons. TTLの利用不可) • Multiple versioning • 複数emailのbinding (e.g. Google account password history) • CSの為のdata trace
  • 29. Primary key for LINE • Long Type keyを元に生成: e.g. userId, messageId • simple ^ random for single lookup • range queryのためのlocalityの考慮不要 • prefix(key) + key • prefix(key): ALPHABETS[key%26] + key%1000 • o.a.h.hbase.util.RegionSplitter.SplitAlgorithmを実装 • prefixでRegion splitting a HRegion 2600 2626 2756 2782 b 2601 c 2602 d z 2652 2808 a000 a250 a500 a750 b000
  • 30. Data stored in HBase • User, Contact, Group • linear scale • mutable • Message, Inbox • exponential scale • immutable
  • 31. Message, Inbox performance, availability重視 • Sharded-Redisとのhybrid構成 • 片方から読み書きできればOK (< quorum) • failed queryはJVM Heap,Redisにqueuing&retry • immutable&idempotent query: 整合性, 重複の問題なし
  • 32. User, Contact performanceよりconsistency重視 • Sharded-Redisがまだprimary • scalabilityの問題はない • mutableなので整合性重要 • RedisからHBaseへ移行 (途中) • Model Objectのみbackup
  • 33. RedisからHBaseへ移行 1. modelのbackup • Redisにsync、HBaseにasync write (Java Future, Redis queuing) 2. M/Rを使ってSharded-Redisからfull migration 3. modelを元にindex/inverted index building (eventual) ←イマココ • Batch Operation: w/ M/R, model table full-scan using TableMapper • Incremental Operation: Diff logging and sequential indexing or Percolator, HBase Coprocessor 4. access path切り替え, Redis cache化
  • 35. ある意味ではYES • Scalability Issuesが解決 • 今年いっぱいまでは • 広域分散 → 3rd issue (To be continue...)
  • 38. HBaseを8ヶ月運用してみた印象 • HBaseは火山 • 毎日小爆発 • 蓄積してたまに大爆発 • 火山のふもとでの安全な暮らし
  • 39. 爆発 • 断続的なネットワーク障害によるRS退役 • H/W障害によるDN性能悪化・検知の遅延 • get (get, increment, checkAndPut, checkAndDelete)性能劣化、 それに伴う全体性能低下 • (major) compactionによる性能劣化 • データ不整合 • SPOF絡みの問題はまだ起こってない
  • 40. HBaseのAvailability • SPOF or 死ぬとdowntimeが発生する箇 所が幾つか 1. HDFSのNameNode 2. HBaseのRegionServer, DataNode
  • 41. 1. HDFS NameNode (NN) • HA Framework for HDFS NN (HDFS-1623) • Backup NN (0.21) • Avatar NN (Facebook) • HA NN using Linux HA • Active/passive configuration deploying two NN (cloudera)
  • 42. HA NN using Linux-HA • DRBD+heartbeatで冗長化 • DRBD: disk mirroring (RAID1-like) • heartbeat: network monitoring • pacemaker: resource management (failover logicの登録)
  • 43. 2. RegionServer, DataNode • HBase自体がレプリカをもたない • failoverされるまでdowntime発生 • 複数コンポーネントで構成されているので、 故障検知から全体合意まで、それぞれの通信区間でtimeoutを待た なければいけない
  • 44. downtime対策 • HBase自身がreplicaを持たないのでRS死亡時のdowntimeが必ず発生 • distributed HLog splitting (>=cdh3u3) • timeout&retry • ほとんどHClient RS間のtimeout時間 • timeout調整 (retryごと, operationごと) • RS ZK間は短いとnetworkが不安定なときにRSが排除されやすい • 同じkeyを持つregionを同じRSに配置 → 障害の限定化 • LINEのHBase accessは基本的にasync • Cluster replication
  • 45. HBase cluster replication • Cluster Replication: master push方式 • (MySQLのようなbinary logging mechanism), 馬本8.8章参照 • 非同期でWAL (HLog)をslave clusterにpush • 各RSごとにSynchronous Call • syncされていないWAL ListをZKが管理 • 検証しつつも、 • 独自実装 or 他の手段も考慮中 multi-DC間のreplication向けではない
  • 46. HDFS tuning for HBase • Shortcut a local client reads to a Datanodes files directly > 0.23.1, 0.22.1, 1.0.0 (HDFS-2246) • Rack-aware Replica Placement (HADOOP-692)
  • 47. 削除問題 • 削除が少し低速 • 論理削除なのでgetほどではないが、putの2倍かかる • 例) 1万件のコンタクトをもつユーザー退会処理 • カラム多すぎでクライアント側でtimeout → queuing + iterative delete • 例) TTLが過ぎたmessage削除 • cold dataに対するRandom I/Oが発生し、serviceに影響 • → dual cluster, full-truncate or TTL利用 • 例) スパマー対応 • compactionされるまでのget性能 (大量のskip処理)への影響 • → column単位ではなく、row単位の削除に
  • 48. Compaction対策 • Bigtable: I/O最適化と削除の為に定期的なCompaction処理が必要 • RSごとにQueuingされ同時に1 HRegionずつCompactionが実行される • Compaction実行中にCPU利用率が上がるので、タイミング注意 • タイミング: periodic, StoreFile数, ユーザー実行 • peak-time時に連続して発生しないよう、 off-peakにcompactionとregion splitting
  • 49. Balancing, Splitting, and Compaction • Region balancing • 自動balancer (request数ベースのbalancing)はOFF • serviceのoff-peak時にbalancing • 異なるtableの同一keyは同じserverに割当→障害を限定 • 問題のあるRegion専用のserver: prison RS • Region splittingとcompactionのスケジューリング • 自動splitもなるべく避ける (hbase.hregion.max.filesizeで自動split) • 連続的なmajor compactionを避ける • immutable storageはperiodic compactionをOFF
  • 50. HBase Tools • Client: • HBaseTemplate: HBase Wrapper like spring’s RedisTemplate • MirroringHTable: 複数HBase cluster対応 • 運用監視: • auto splitting: off-peak時のregion split • auto HRegion balancer: metricsを元にoff-peak balancing • Region snapshot&restore: META Tableをdaily dump、RS死亡時の復元 • Data Migration: • Migrator with M/R (Redis → HBase) • H2H copy tool with M/R: table copy (HBase → HBase) • metrics collecting via JMX • Index Builder and Inconsistent Fixer with M/R, incremental implementation (coprocessor)
  • 51. 今後の課題 • HBase上の<key, model>を中心にindexやRedis上にcacheを構築 • 停電・地震対策 (rack/dc-awareness) • HBase cluster replication • Cassandraをgeological distributed storage for HLogとして利用 • 今以上のスケーラビリティ (数 - 数十億ユーザー) • HBaseはnetwork-boundで1クラスタ数百台弱が限界 • Multi-clusterで凌ぐかCassandraを使うか