Treasure Data Tech Talk 〜クラウドサービスを支える技術〜に参加してきた

Treasure Data Tech Talk 〜クラウドサービスを支える技術〜に参加してきました。
ただ、正直あまりわかりませんでした。
と言って終わらせてしまうと、各方面に怒られてしまうので、自分なりに調べて書いてみました。

追伸(終わりみたいですね)
あのたごもりさんと懇親会でお話(私は聞いてるだけでしたが)できたのが何より一番嬉しかったです。
たごもりさんとお話できたのを除いても、懇親会が私にとって一番充実してた気がします
(私の知識が足りないだけです。発表は素晴らしかったです)

全体のタイムスケジュールですが、大きなセッションが2つあって、最後にちょい長LTがあったという流れでした。

  • Treasure Dataのデータベースアーキテクチャ 〜 毎秒45万レコードでスケールし続けるスキーマレス・データベース 〜
  • Internals of Presto Service
  • LT

Treasure Dataのデータベースアーキテクチャ 〜 毎秒45万レコードでスケールし続けるスキーマレス・データベース 〜

fluentdでは知らない人はいない古橋さんの発表です。
Treasure dataではデータをどのような構成で処理しているかといったような話です。

(ここはうろ覚えです。間違えてたらすみません)
話は3つあって、

  • アーキテクチャ
  • DBへの保存の話
  • プロセス側の話

アーキテクチャ

まず、入りのデータはとにかくfluentdにデータを入れまくって、そこからアプリケーションに渡すようにしています。
そこから、並列でファイルの処理をするのですが、fluentdにはuniq-idがあるので、それをファイルのindexに紐づけて登録しているそうです。
そこから処理したものはS3とかにアップロードして、それに対するメタデータはPostgreSQLに登録しているそうです。
ただ、小さなレコードを数多く扱っているとスピードとか効率が下がってしまうので、ある程度大きな単位に変換して処理するそうです。
その処理はHadoopで動いているそう。
ただ、最新のデータを読むとかなるとまた処理が遅いので、その場合は小さなレコードの方を読むようにしていて、後から解析するとかの場合は、マージ済み、処理済みのアーカイブストレージから読むとのこと

DBへの保存の話

RDBSとかだと、カラムごとに値の型が決まっているのに対して、treasure dataではスキーマレスに各値ごとに型を持たせるようにしているらしいです。
カラムをアップデートとかするのには大変ですが、とにかく保存するとかだけなので、問題はないとのこと
でもRDBSを使っているので、SQLでは定義しないといけなくて、それは”schema on read”という仕組みを使っているらしいです(詳しい方々から怒られそう)

プロセス側の話

トランザクションの話があって、3つのAPIを使っているそうです。

  • リトライ可能なトランザクションを宣言する
  • インサートする
  • パーティショニングをしている
    (私DB周りがホントに弱いので、パーティショニングという言葉も知らなかったです…。)
    パーティショニングとは、大きなテーブルを小さく分割する方法で、高速に処理をすることができる手法だそうです。
    参考

treasure dataではGiST Indexを使うのが必須で、ここでMySQLと比較した際にその処理スピードが圧倒的に差があるため、PostgreSQLを採用しているそうです。

このセッションの感想

ここまで実はあまりわからなかったのですが、気になっていたのが、頻繁に「リトライ」するということを話されていたのが印象的でした。
データをインポートする際にも失敗したらリトライするし、インポート後にAPIに投げたりする際にもリトライする。
S3にアップロードする前にもリトライすると言っていました。
各ステップ毎にリトライすることを入れているというのが普段の仕事では意識してない部分だなぁと勉強になりました(趣旨とはずれるかもしれないですが)
また、リトライ以外にもDBに保存する際にはきちんとユニーク判別して重複を省いたりとか当たり前かもしれないですが、それをサービスレベルで実現できているのがすごいなと感じました。

internals of presto serice

サイトウさんという方の発表です。
スライドはこちら


この方は昨年treasure dataに入社されて、その前は東大で(ざっくり言うと)データベースの研究をされていたそうです。

話の背景として、これまでHiveというHadoop上で動くデータベースを操作できるプロダクトがあるのですが、それに対してtreasure dataは、Prestoというプロダクトを使っています。
これは、Facebookが超大規模なデータセットに対してインタラクティブに結果を返せるようにと開発されたものらしいです。
参考
クエリの実行とかそういう話ですね。

で、Prestoと比べてMapReduceは、各ステップ(MapステップやReduceステップ)にて、diskIOが発生するため、処理に遅延が発生してしまうという欠点がありました。
それに比べてPrestoはdiskIoがないので処理自体は早いのですが、途中で保存するということをしないため、途中で失敗したら最初から全てやり直しということになります。
treasure dataでは、ここでもリトライが基本なので、リトライで対処しているそうです。

で、話のテーマとしてはこのprestoのデータベースをサービスとして使うためには?という研究的なチャレンジという内容です。

ただ、この先はあまりよくわからずでメモを頼りに。。。
クエリを発行するにもまず、全てのヘッダ情報を読まないといけないからヘッダを読むリクエストを送っていく。これはリクエストキューにためていくという話(???)
と、
S3とかにアップロードするのですが、エラーが多いので、それらに対してもリトライをするそうです。
中には、ファイルはあるんだけど見えていないというエラーもありますが、そこを重複を省くような処理をいれることでリトライしても整合性が保てるそうです。

次にJavaの話をしていて(全くわからなかった)、sun.misc.Unsafeという危ないコードの話でした。
なんか、CとかC+のようにヒープメモリに直接アクセスできるらしい。
ただし、defaultの方が良いプログラミングで、毎回チェックをしていて安全になっているため、その辺りも考慮にいれてスピードを上げながら実装しているそうです(レベルたけーって思いました笑)
Rubyでいうメタプログラミングにちょっと近い話なのかな?って思いました。

あと、もうひとつ細かい工夫をされていて、Javaでのwhich文を普通に使うと遅い(らしい)
のでlookup tableというのを作るそうです。
これを使うことでキャッシュされるので、処理が早くなるとのこと。

で、データベースをサービスとして提供する課題の話
今後のデータベースの活用について議論する場所があるらしく、その場でクラウドデータサービスの発展を予測したそうです。
SQL自体にはできることは少ないけど、むしろその制約があることがサービスとして提供できるには良いという話をされていました(いい話なんですが、ちゃんとわかってないです泣)

(あまり覚えてないので箇条書き)気になるメモがあって、

  • スピードを求めるには、細かくデータを分割したほうが並列性が上がるので良いが、その分お金が多くかかってしまうので、サービスとしてどうなの?っていう話
    https://twitter.com/frsyuki/status/575609786152054785
  • なんかインターン生にやってもらったうち、クエリのタイプを見分けるというのを形態素解析を使ってやったことがあるそうです

LT

YARNについて


タイトルは「HDP2 & YARNの運用で抑えておくべきポイント」となっていますが、スライドを作成している段階でYARNの話しかしてないということで、私の中でYARNについてとなっています。
ただ、これについてはホントにわからなかったです。
調べても全く意味がわからなかったです。ごめんなさい :bow:(←使えないけど) 割愛させていただきます m( )m
参考?

Datadog & Hotdogの話

資料はこちら


Datadogとはいわゆる監視ツールで、cactiみたいなものです(アイコンが可愛いです)
で、treasure dataでは、pagerdutyというサービスがインスタンスとかに異常があった際に通知をしてくれるそうです(TDとかDDとかPDとか紛らわしいねん!って話をしてました笑)
ただ、その通知がきてからWebコンソールとかでポチポチインスタンスIDを探したりするのってめんどくさいよねっていうので、そういう検索を補助してくれるのがHotdogだそうです。
なんか便利そうなので、今度使ってみたいなと思いました!!

Mobile SDK


Mobile SDKは、スマホアプリからのtreasure dataへデータを送るものです。
これまではスマホアプリから直接データを送る手段がなかったそうです。
ここにもリトライ機能はついています。
あと、サーバなしで直接treasure dataにデータを送れるそうです。

サポートエンジニアの日常

treasure dataのサポートについての話でした。


サポートはメールからチャット、実はチケットまで幅広く対応しているそうです。
で、それらの管理自体はdeskというsalesforceに買収されたサービスを利用しているそうです。
受けた質問をslackとかにも流れるようにしていて、社内の人ならどんな質問がきたかを把握できるようにしているそうです。
また、質問をしたユーザの情報もPreactというツールを使って解析していて、どの程度ログインするとか、何回質問したとかを管理しているそうです。

質問がくるタイミングは、夕方くらいが多く、1週間には最大80件ほども対応するそうです。
サポートチームは2人しかいないということだから、本当にすごいなと思いました。

サポート内容もちゃんとしていて、基本的にtreasure dataを使っていたら、全ての回答には答えるそうです。
また、クエリが遅いとかいう質問に対しても効率の良いクエリを回答したりなど、その丁寧さぶりは素晴らしいなと思いました。

トレジャーデータとfluentd

あのたごもりさんのお話!


fluentdを知っている人は会場のほとんどで、実際に使っているよという人は半分くらいだった。
また、おもしろいなと思ったのがtreasure dataのなかでもfluentdを使ってログ解析をしているそうです。
一般的なフロントからバックエンドまでっていうのが、トレジャーデータではフロントで、その更に裏側があって、その範囲をバックエンドと呼んでいるそうです(懇親会で話した内容かも)
そして、社内にOSSチームがあり、現在3名で開発を進めているとのこと。
embulkにも触れていて、これもOSSなので、近いうちに開発を進めるそうです。
発表の中で、たごもりさんが「パートタイム」とおっしゃっていたのですが、懇親会で聞いたところ、実際は結構フリーな感じで働いていて、午前中はhadoopと格闘して、午後からはfluentdの開発をしようみたいな感じらしいです。

懇親会

懇親会では、最初会社の人とお話をしていたのですが、途中からなひさんが来てお話させていただきました。
(正直後から知ったのですが、Rubyコミッタの人で、今思い返すと震えが止まりません…!)

  • BigQueryと、EMRとかいろいろあるけど、結局何がいいのか
    BigQueryだと、後からスキーマの変更とかするのが手間がかかるのと、1回のクエリでの料金がわかりにくい。
    ただ、バッチ処理で定期的に実行するだとか、スキーマの構造が変わらないで1日数回のクエリ実行とかならオススメ
    スキーマが完全に決まってて数TBの情報量を扱うとかならRedshiftもオススメ
    スキーマの構造が変わるとかなら断然treasure dataが良いとのこと。あとで型を指定できる。

最後に

ホントにわからないことだらけ(そもそもちょっと分野も専門的だった気がしなくもないですが)だったので、まずは基本から固めて、あぁいう勉強会の懇親会とかで質問バンバンできるようなエンジニアになりたいです。
でも刺激になりました!
やっぱり著名人に会うとやる気が出ますね!!

あと、会場提供していただいたフリークアウトさん、イベントの支援をしていただいたdotsさんにこの場で感謝の言葉を。
ありがとうございました。(ピザおいしかったです)