第2回NHNテクノロジーカンファレンスに行ってきた #nhntech

tech 技術

↓に参加したので、そのメモと感想。
http://blog.livedoor.jp/techblog/archives/67621715.html
togetter：
第2回NHNテクノロジーカンファレンス #nhntech まとめ - Togetter
各セッションの動画：

nhnjptech
- YouTube

「HTML5 Animation in Mobile Web Games」 NHN Korea 沈さん

ちょこちょことメモはとったんですが、分野が違いすぎて上手くまとめきれないので省略。
セッション中に紹介されたノウハウを結集してCollieというanimation libraryをオープンソース化されたそうです。ライセンスはLGPL2.1。
http://jindo.dev.naver.com/collie/

「日々進化するhadoopの今」 NTTデータ濱野さん

  • NTTデータのHadoopへの取り組みに関して
    • NTTデータでは27,8人でhadoopのシステム構築に取り組んでいる。
    • ちょっと前の話だけど、経産省に出したレポートが結構話題になった。
      • ここには当時蓄積していたノウハウの半分くらいのことを書いている
  • hadoopのおさらい
    • hadoopの処理の概要とかよくある勘違いとか。
    • 急速に発展するエコシステムがhadoopの魅力の一つ。
    • ディストリビューション(主にCDH)も成長中。
  • バージョンに関して
    • 本体の開発が活発に進んではいるが、バージョンが、、、
    • 大きく二系統
      • 1.0系(従来の0.20)と2.0系
      • CDH4は2.0系のhadoopを採用している。CDH4は斬新なので、手堅くやりたい人はCDH3をオススメ。
  • Name NodeのHA(=High Avalability:冗長)化
    • HadoopではNamenodeがSPOFとなる。
    • DRDBと連携した冗長化などの回避策がある。
      • ##この話は知らなくて？？？となりましたが、"drdb hadoop"でググるといっぱい出てきました。
    • CDH4.0ではNFSをベースとした構成
  • HDFS Federation
    • HDFSにボリュームの概念をつけられるようになる。
    • １個のクラスタを中でグループ分けして使いたいという要望が結構あるが、それを容易に実現するための一つの技術要素となりえる。
  • YARN (=Yet Another Application Resource Negotiator)
    • 最初はMapReduce2.0という名前だったけど、MapReduce以外の分散並列処理ものっけられるようにしようというビジョンなのに、その名前どうなの？ということで、名前が変わった。
    • MapReduceのアーキテクチャの見直しのきっかけは、Yahoo等でHadoopを作っている人達が、現状では4000ノード以上にスケールさせることができないと言いだしたこと。
      • それって必要？というのも無くはないが、、
      • NTT Dataでも1000台以上のクラスタの運用経験はある。

「HBase at LINE」 NHN 中村さん @sunsuk7tp

  • LINEのRoad Mapに関して
    • 次はゲームとかにいくんでしょうが、(中村さん的には)どうでもいい。自分はストレージにしか興味ないんで。
  • LINEで利用しているストーレジに関して
    • 最初はパフォーマンス重視
      • Redisのみ
      • 100万ユーザを突破した頃に、RedisのShardingを入れた。
    • 現在はスケーラビリティ重視
      • ユーザがさらに増えてくると、Redisのみでは色々と問題がでてきた。
      • スケーラビリティ、永続性、そしてよく落ちる、、、
      • NoSQLの導入の必要があり、HBaseを導入することにした。
    • 将来的には１箇所集中ではなく、geological distributionを意識した構成にしたい。
      • cassandraを入れるつもり！
  • Zackerberg's Law of Sharing
  • data scalability
    • constant：一定量
      • async oeration？？ (ここは触れられなかった気がします & 何のデータかはよく分からず。)
    • linear：直線的に増加するデータ
      • LINEではユーザデータや、ユーザグループのデータ
    • exponential：指数関数的に増加するデータ
      • LINEではメッセージデータ
  • data workload
    • linearデータはRead/Writeの割合とでReadが95%以上を占める。
    • exponentialなデータはWrite/Readが半々ぐらい。
    • ##dataの"workload"というのが、どういう概念なのかが自分には分からず、、とりあえずググってみたらこういうのが出てきました。

In computing, the workload is the amount of processing that the computer has been given to do at a given time.

  • Storageの選択に関して
    • constantなデータはRedisでよい。
    • linear、exponentialなデータは選択肢がいくつか
    • HBase, Cassandra, MongoDB, MySQL Clusterなど
    • HBase
      • ○：workload的にはOK、社内にDFSのスペシャリストがいる & 実際、導入にあたって色々協力してもらった。
      • ×：SPOFがある、Random Readに弱い
    • cassandra
      • ○：workload的にはOK、SPOFが無い。
      • ×：Consistencyに難あり。
    • Mongo
      • 柔軟なqueryなど、NoSQL製品同士の比較では色んなプラス要素はあるが、解析向けという所で今回の用途と関係なし。
    • MYSQL Cluster
      • ○：慣れてる。
      • ×：最初から分散に適したストレージを使うべき。(と社内のMySQLの人にも言われた)
  • LINEのストレージ構成
    • フロントはRedisでHBaseに逃がして永続化させている。
    • ３月から７月の間にユーザ数もノード数も倍になったが、まだHBaseにとってはcasualなデータ量。
    • ##indexの話とかはちょっとついていけませんでした。。
  • LINEのHBaseに格納されているデータ
    • Message,inbox
      • 指数関数的に増えている。
      • immutable(後から変更されない。)
      • performance, avalavilityが重要
      • フロントRedisとのhybrid構成。
    • User データ
      • mutableなので整合性が大事
      • 現在、RedisからHBaseに移行中。
  • HBaseに変更して幸せになれたか？
    • ある意味ではYES
    • HBaseでスケーラビリティの問題は解決した。
    • 障害は全然減らね。。HBaseは火山。。
      • 毎日、小爆発
      • 時々、大爆発！
  • HBaseのAvalabilityに関して
    • NameNodeは冗長化している。
    • 複数のコンポーネントで構成されているので、障害検知に時間がかかる。それぞれの通信間でのタイムアウトの合算。
    • compactionはオフピークの時間に定期的に実行している。
    • ##資料を見直してみると濃ゆいことが書いてますが、この辺は結構さらっといった印象。(時間の関係？細かく説明されても理解はできなかったでしょうが、、)

No SQL製品の比較、データの性質(scalabilityとworkload)の話などはすごく勉強になったし、理論の話だけでなく、それをどう運用しているかというやや泥臭い話まで、聞き応え十分なセッションでした。
大ヒットしたwebサービスはどっかの段階でパフォーマンス等の問題を引き起こしたりするような気がしますが、LINEからはそういう話が聞こえてこず、むしろ、どんどんとサービスを成長させていけるのは、こういう人がいるからなんだろうな〜と。


「OSSで支えられるライブドアの巨大ログ集計」 NHN @tagomoris さん

  • なぜ自分たちで作るのか？
    • Google analystics使わないの？
    • 数字の理由が説明可能でなければならない。
    • 再現性。データさえあれば、追試可能でなければならない。
  • コンポーネント分離
    • コンポーネント分離の徹底。
      • 依存関係を小さくし、ミドルウェアのアップデートに追随できるように。
    • OSSの利用により、ブラックボックスの部分をなくす。
      • 自分で調べられる、手を入れられる。
  • 規模の拡大とデプロイ
    • ２種類の拡大
      • 量の拡大。
      • バリエーションの拡大。
    • スケールするというのは、この両方に対応できる必要がある。
    • 変更なしでバリエーション増に対応できる設定セット
      • 例外はほんとに限定的な適用にする。livedoorではアクセスの桁が違うlivedoor blogがそういう扱い。
    • 汎用の公開ソフトウェアを可能な限り、そのまま使う。
  • コンセプトのいいOSS
    • ここまで説明したきたことの実現にあたってはコンセプトのいいOSSが必要。
    • それがHiveとFluentd！
      • 今日の発表と過去の資料を見てもらえば、自分の言いたいことが分かってもらえるはず。

ツールの作り方というか、考え方の所は凄く参考になった。自作ツールでいうと、Cyber AgentがHiveベースのツール作りましたみたいのを色んな所で見聞きした覚えがありますが、その１個か２個上のレイヤーからの話だったかなという印象。ただ、個人的には前日のログをscpとかで転送して集計するのと比べて、ログのリアルタイム集計ってのがどれくらいおいしいのかということ自体があんまりピンときていないので、いつか、その辺の事例というか効果につながった話が聞けるといいな〜と贅沢なことを思ったりしました。
そして、hiveのロゴが話題になってました(=disられてた)が、昨日乗った東京ディズニーランドのプーさんのハニーハントに似たようなのがいて、ちょっとビックリ。著作権だとか商標だとか意匠だとかは大丈夫なのかな？(笑)

http://nomiblog.blog22.fc2.com/blog-entry-604.html


「Hadoop and the data scientist.」 Treasure data @doryokujin さん

  • ツール自分で作るの？
    • @tagomoris さんみたいな人がいるならいいけど。
  • Why Hive is good?
    • SQP style query language 学習コストが低い。
    • jdbc/odbcなど既存の資産を使いやすい。
  • Monitoring Tool
    • Metric Insights
      • 時系列の沢山のグラフ
      • 複雑なこと(ドリルダウンとか)はできないけど、今、どんな状況なのかは一目で把握できる。
      • 異常検知やアノテーション(キャンペーン表示とか)はサポートしている。
  • BI
    • インタラクティブな操作で、様々な軸での解析を可能にする。
    • プラス、様々な形式でのアウトプット。表形式、棒グラフ、線グラフ、、、

自分たちでツール作るべきか、既存ツールを使うべきかの議論は尽きない所？かと思いますが、会社毎に見ている数字というのは既にあると思うので、そのコンテキストを既存ツール上で置き換えることと、自作ツールで表現するのと、どっちが早く対応できるかのケースバイケースなのかなと思ったり、そもそもツール自体がOSS化されていってその垣根自体がなくなるのかなと思ったり。とりあえず、cubeの概念はキャッチアップが必要だな〜。そして、Treasure Dataの話が無いまま終わったぞ！？と思ってそのままつぶやいたら、月曜に公式アカウントから@で返信いただきました。



主催者の皆様、後援者の皆様、ありがとうございました！