2016-07-14

メモなぜDigdagのワークフロー定義はYAMLなのか #tdtech

Diddag = ワークフローオートメーションシステム
- 複数のタスクを管理するためのシステム
- あらゆる手作業の自動化
- バッチデータ解析の自動化
- ジョインジョイン→メール送信などを手作業ではなく自動化
- メールアドレス一覧の取得、対象の絞り込み→テンプレートから本文を生成
- CircleCIと似たようなシステム？

似たようなプロダクト

Makefile
Jenkins
Rundeck
Airflow

などなど

ワークフローの定義方法による分類

プログラミング言語型

Luigi
Airflow

Pythonのワークフロー管理タスクとタスクの依存関係
メリット何でもかける
デメリット書くのも管理するのもめんどくさい

GUI型

Rundeck
メリットシンプルで誰でも作れる
デメリットバージョン管理がしんどい

定義ファイル + スクリプト型

Azkaban

https://azkaban.github.io/

GUI + スクリプト

メリットバージョン管理が簡単
メリット定型的な処理は簡単
デメリット複雑な処理を書こうと思うと半ザツに生る

Digdugは？？

定義ファイル + スクリプト型 + 俺達のYAML

バージョン管理が簡単
開発しやすい
それと、独自のYAML

普通のYAML

利点

読みやすい
書きやすい
プログラムでパースしやすい
エディタの公文

欠点

includeできない
変数の埋め込みできない
DSLかけない

Digdagは上記の欠点を すべて克服した

includeできる、変数の埋め込みができる、DSLかける
requireが使えて、外部スクリプトと変数のやりとりができる

DigdagのYAML

includeできること
変数を埋め込めること
dockerを呼び出せる

YAMLパーサの実装

DocumentStart DocumentEndなど

+ step1:
  array: [a,b,c]
  !include : abc.yml

Scalar値に注目すること
- 一個一個のScalar値にTagをつけて解決すること
- 正規表現によるマッチでTagを決定する
Tag + Scalar = Node
includeと:の間にスペースがないと、エラーになる
YAMLをパースして、オブジェクトを構築する
対応する値が指すパスを読み込んでマージすること
DigdagはJavaで動いている
- と、JavaScriptで評価

なぜYAMLか

それなりに読みやすい/書きやすい
別候補 SimpleJSON プログラミングでパースしやすくするために、独自フォーマットは避けたい

なぜYAMLか

Digdagはグラフ構造の実行エンジンではない
- Dagの木構造
- テキストでグラフ構造を記述するのは結構無理がある
- グラフ構造は人間が理解するのは難しい
- ので、木構造としてまとめたほうが読みやすい。わかりやすい

GUI

実装中

YAMLのなかでソースコードを呼び出せるならそれは脆弱性になりうるのでは

ちゃんと防御してる
副作用のない処理しか実装できない

!includeについて

!include: だとエラーになるのはつらいかも

2016-07-14

メモ PerfectQueueはいかにパーフェクトか、あるいはRubyとMySQLでジョブキューを作る試みについて #tdtech

勉強会 Treasure Data

PerfectQueue
- パーフェクトな分散キュー
worker scheduler consoleapiのやりとりで分散キュー
ジョブキューとは
- first in frist out
At-least-once semantics
- 最大1回実行
- ジョブキューにRDBMSを使うべきか使うべきなのでは
At-most-once
queueのテーブル構造 id timeout data created_at
- created_atは完了したかどうかにしか使わないので。。。
dataへはJSONを入れること
タスクの取得はSQLでもできる
実行中は定期的にハートビート
- 途中で落ちたらやり直し
完了したらcreated_at = NULLを入れる(っていうアーキはどうなの？という良心の呵責)
- 一定期間物理削除しない
完了済みタスクで、retention_timeを過ぎたら物理削除
書く操作については、
Submit INSERTするだけ
Acquire 排他処理すぐデッドロックされてしまうジョブキューを作るときは気をつけよう MySQLの気持ちになりながらクエリを書くこと
- FOR UPDATEを避ける
- LOCK TABLES →全体をロックされるとパフォーマンスがやばい
- get_lockがいちばん
- と思うのですが、デッドロックされる
- deleteとコンフリクトすること
  - 注意してクエリを書かないとデッドロックになる
Finish
Delete
- 削除のタイミングでもGET_LOCK
- すべてのワーカーを同時に起動するとしばらくのあいだ削除クエリが飛ばない
  - →削除待ちタスクが増えてスループットが低下するので、乱数分散してDELETEクエリを実行する
- 削除待ちタスクと取得待ちタスクの存在する領域を分ける
  - 削除クエリのデッドロック対策が不要になること
  - 安定した速度でタスク処理が実行された
突然発生したネットワーク遅延
- スループットが3倍悪化する
- →データ構造を変える
- テーブル queueに、カラム ownerを追加する
- select & markからmark & selectへ 性能が2.5倍へ
- read lockとwrite lock
- FOR UPDATE
MySQLの気持ちになって、どういうロックが使われているかを考えながら実装するとデッドロックになりづらい

まとめ

ジョブキューは重要だけど難しい
ロック絡みのSQLを書くときはMySQLの気持ちになって書くこと
ベンチマーク用にサンドボックスはひつよう

質疑

MySQLをジョブキューのインフラとして選んだこと
- Amazonでサポートされているから
- 自分であんまりメンテをしたくなかったから
- ジョブキューを自前実装する必要性→Hiveの実行をジョブキューで制御したかった他のライブラリではやりたいことが実現できなかった

2016-07-14

メモバルクロードの信頼性を上げるための戦い #tdtech

勉強会 Treasure Data

Embulkとは

Embulkのプラグインの話
TDでEmbulkをつかう話
OSSとして出しているプラグラブルなバルクロードツール
- Fluentdのバッチ版と言われる
- TDはOSSと一緒のバージョンを使っている
cavのgzipをMySQLにアップロードする、といった用途とか
GUIも使える
Import側はCUI(td connector)
EmbulkについてはWebDBPressのNo.92とか、Qiitaとか、ドキュメントとか
- もう少しデベロッパードキュメントがほしい

プラグイン

リトライ確認
実装はJavaでもJRubyでも可
- Java 高パフォーマンスエンタープライズ向けのサービスだとJavaSDKしかない
  - Java8未対応
  - TDのHadoop古く、Java7までしか対応してない
- JRuby 書きやすいネットワーク関係
- ので、両方知っておくといいかも
無限リトライを避けるような実装すること
- ConfigExecution
- DataExecution
外部サービスとの比較
- AWS S3
  - パスを渡せばよいからかんたん
- Azure Blob Storage
  - なぞの文字列を追加したあとごにょごにょしないといけなくてしんどい
- Google Cloud Storage
  - 0x0aしてからbase64エンコード→しんどい
- わからなかったらSOに聞くといいかも
ユニットテスト
- カバレージは80％を超えていることが条件
- ただしEmbulkのテストコードを書くのは結構しんどい
TDのアーキを自分で書いてみて、どう動いているのかわかった

TD API/Bulkload API

Guest Previewはある程度インタラクティブ
データ量が多いデータのコンフィグが数千行
プラグインの作りがしょっぱいとうまく回らないのでログとテストはちゃんと実装するようにする
でかいデータはプラグインのリトライが動いていないと実行時に大変
バルクアップロードが失敗したらリトライするようにすること

結合テスト

単体テストよりは実装は難しくないが、テストの数が多い
- guessちゃんと動く??
- スケジューリングは期待通り動いてる??
- CIがよく落ちるタイムアウト/50x/API limit

実装したい

API endpointは不十分な
- 認証を確認してからジョブの確認ができる方がUIが上がるのでそのようにしたい

インフラ

Chef
- サーバを建てるのにそれなりの時間がかかる
- コンテナ化仮想化を駆使したい
Datadog
PagerDuty

2016-07-14

memo 3 Months Into Treasure Data #tdtech

勉強会 Treasure Data

日本語でセッション…

TDに入る前

spotifyで働いていて、バックエンドの開発をやっていた
dockerとかインフラとか
CSの中でいちばん興味のあるのは分散システムとかパフォーマンスのところ

なんでTD

cloud is eating the world
- 2011時点のspotifyのインフラはオンプレミスだった
- 2016時点では積極的にGCPへ行こうし始めていた(全部Googleに任せよう)
クラウド化

TDに入ってどうしたのか

Digdagの開発
- インテグレーションテストとか
- web ui
- more operators
- alerts & notifications
TD
- bugfix SDK

具体例: Presto PlazmaDB Meatadata Cache

TDにテーブルがなかった??
メタデータには入ったけどprestoには伝わらず……
prestoのメタデータキャッシュにデータが残っていた

Hard CS Problems

cache invalidatoin, naming thinsとか

Future Digdag Work

いろいろ多いのでTDはエンジニアを募集しています

2016-07-14

メモ Treasure Dataを支える人々 #tdtech

勉強会 Treasure Data

技術的な話が多いので人にフォーカスしたはなしを
分散系とかPrestoとかを担当

TDエンジニアの一日

朝が早くない
出社時間はまちまちだけど、slackとかあるので、そんなに苦ではない
ソースコードはGitHub→ステータスの管理はJIRA(GitHubのIssueは使いづらい)

開発

IDCFcloud + circleci + AWS + JIRA + GitHub → Slack

デプロイ

インスタンスはIDCF cloud or AWS
- 構成管理はChefのレシピを使っている
- インスタンスを誤って消したときはすぐに知らせてくれる

調査

すべてのインスタンスにtd-agentがはいっている
モニタリングツールはdatadog
TreasureData

対応

PagerDutyで電話をかける
- カリフォルニアからかかってきてる
statuspage.ioでステータス確認
サーバに入らないといけない場合はduoをつかって二段階認証でサーバログインする

まとめ

YAML/MySQLハッカーだけじゃない
Treasure Dataはクラウドサービスを使いこなす人にも支えられている

2016-07-14

メモ PlazmaDB/PlazmaGC #tdtech

勉強会 Treasure Data

PlazmaDBの各種ゴミ集め
PlazmaDBについては良い資料があるので詳細はそちらをみる
- MessagePack
- 分析用DB
  - インデックスは時間軸
- トランザクション
- 暗号化サポート
- 時間軸のメタデータ
- データの中身はS3 or RiackCS
PlazmaDB
- 1秒間に110万行のimport
- 310Kのデータセット
- 23兆のレコード
- メタデータへのアクセス 700 tps
- メタデータ 300GB

PlazmaGC

Storage Usages
Bulk Import
Query
Insret into / overwrite
Streaming import→realtime files→partition files→deleted partitions→deleted
- いらないデータは削除用キューへ移動させてクリーナーがデータを消去する
- realtime files 1時間ごとにマニュアルでタイムスタンプ付きのテーブルを作っている
- 古いテーブルを少しずつ消していかないといけない
- メタデータはPostgresSQLを使っているオートバキュームが間に合わないとストレージの使用量が減らない問題
- 古いインデックスと新しいインデックスのスワップ
- インデックスの作りなおしに8時間ほどかかるのでDBのおもりのするのはしんどい
Query
- realtime iflesからpartition filesへの移動に伴い、細かいパーティションが多くなる
- partitionの作り直しで対策
- 効率的にデータを削除するためにデーモンやマニュアルオペレーションをやっている

イット [DVD]

出版社/メーカー: ワーナー・ホーム・ビデオ
発売日: 2010/04/21
メディア: DVD
クリック: 5回
この商品を含むブログ (10件) を見る

2016-07-14

メモ The Real of Treasure Data Engineering Team #tdtech

勉強会 Treasure Data

シリコンバレーの会社で6割がた日本人
どういうふうにチームを回しているのか
VP of engineering vs CTO
- CTOはスーパーマン??
- コードをかけて、マネジメントできて、最新の情報にキャッチして…
- ってそんなことはない。
- エンジニアのマネジメントとしてのVP of engineering
日本にVP of engineeringっていう役職も言葉もない

なんで入ったの

テレコミュニケーションズで、CSはやってない
シスコにいた
QAエンジニアとQAマネージャー

英語を書き留める練習