JVM内で使いまわす。
Trello
タスク管理ツール。結構リアルタイムで更新しあえる。
メモ The Real of Treasure Data Engineering Team #tdtech
- シリコンバレーの会社で6割がた日本人
どういうふうにチームを回しているのか
VP of engineering vs CTO
- CTOはスーパーマン??
- コードをかけて、マネジメントできて、最新の情報にキャッチして…
- ってそんなことはない。
- エンジニアのマネジメントとしてのVP of engineering
日本にVP of engineeringっていう役職も言葉もない
なんで入ったの
- テレコミュニケーションズで、CSはやってない
- シスコにいた
- QAエンジニアとQAマネージャー
英語を書き留める練習
メモ PlazmaDB/PlazmaGC #tdtech
- 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の作り直しで対策
- 効率的にデータを削除するためにデーモンやマニュアルオペレーションをやっている
- 出版社/メーカー: ワーナー・ホーム・ビデオ
- 発売日: 2010/04/21
- メディア: DVD
- クリック: 5回
- この商品を含むブログ (10件) を見る
メモ Treasure Dataを支える人々 #tdtech
- 技術的な話が多いので人にフォーカスしたはなしを
- 分散系とか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はクラウドサービスを使いこなす人にも支えられている
memo 3 Months Into Treasure Data #tdtech
- 日本語でセッション…
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はエンジニアを募集しています
メモ バルクロードの信頼性を上げるための戦い #tdtech
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 書きやすい ネットワーク関係
- ので、両方知っておくといいかも
- Java 高パフォーマンス エンタープライズ向けのサービスだとJavaSDKしかない
- 無限リトライを避けるような実装すること
- ConfigExecution
- DataExecution
- 外部サービスとの比較
- AWS S3
- パスを渡せばよいからかんたん
- Azure Blob Storage
- なぞの文字列を追加したあとごにょごにょしないといけなくてしんどい
- Google Cloud Storage
- 0x0aしてからbase64エンコード→しんどい
- わからなかったらSOに聞くといいかも
- AWS S3
- ユニットテスト
- カバレージは80%を超えていることが条件
- ただしEmbulkのテストコードを書くのは結構しんどい
- TDのアーキを自分で書いてみて、どう動いているのかわかった
TD API/Bulkload API
- Guest Previewはある程度インタラクティブ
- データ量が多い データのコンフィグが数千行
- プラグインの作りがしょっぱいとうまく回らないのでログとテストはちゃんと実装するようにする
- でかいデータはプラグインのリトライが動いていないと実行時に大変
- バルクアップロードが失敗したらリトライするようにすること
結合テスト
- 単体テストよりは実装は難しくないが、テストの数が多い
- guessちゃんと動く??
- スケジューリングは期待通り動いてる??
- CIがよく落ちる タイムアウト/50x/API limit
実装したい
- API endpointは不十分な
- 認証を確認してからジョブの確認ができる方がUIが上がるのでそのようにしたい
インフラ
- Chef
- サーバを建てるのにそれなりの時間がかかる
- コンテナ化仮想化を駆使したい
- Datadog
- PagerDuty
メモ PerfectQueueはいかにパーフェクトか、あるいはRubyとMySQLでジョブキューを作る試みについて #tdtech
- 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の実行をジョブキューで制御したかった 他のライブラリではやりたいことが実現できなかった
メモ なぜDigdagのワークフロー定義はYAMLなのか #tdtech
- Diddag = ワークフローオートメーションシステム
- 複数のタスクを管理するためのシステム
- あらゆる手作業の自動化
- バッチデータ解析の自動化
- ジョインジョイン→メール送信などを手作業ではなく自動化
- メールアドレス一覧の取得、対象の絞り込み→テンプレートから本文を生成
- CircleCIと似たようなシステム?
似たようなプロダクト
- Makefile
- Jenkins
- Rundeck
- Airflow
などなど
ワークフローの定義方法による分類
プログラミング言語型
- Luigi
- Airflow
Pythonのワークフロー管理 タスクとタスクの依存関係
メリット 何でもかける
- デメリット 書くのも管理するのもめんどくさい
GUI型
Rundeck
メリット シンプルで誰でも作れる
- デメリット バージョン管理がしんどい
定義ファイル + スクリプト型
- Azkaban
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: だとエラーになるのはつらいかも
ペットか家畜かという話
イミュータブルインフラストラクチャーの文脈で、特にクラウドにおいては、サーバを育てるよりあかんかったらすぐ捨てて、また増やす勇気と施策がひつよう。
Macでスクリーンセーバーをすぐに
「設定」→「スクリーンセーバー」→「ホットキー」→で、左上か左下に「スクリーンセーバーを開始する」って設定して、マウスポインタを設定したとこに移動すると、スクリーンセーバーが発動する。
Ubuntu バージョン確認
$ cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=16.04 DISTRIB_CODENAME=xenial DISTRIB_DESCRIPTION="Ubuntu 16.04 LTS"
/etc/lsb-release
ちなみにFedoraとかCentOSとかのRedHat系は/etc/redhat-release
Terminalの比較メモ
- gnome-terminal
- 画面分割はできない
- 背景画像も買えられないっぽい
- コピペできる
- tmux
- 画面分割できる
- 背景画像は変更できない
- コピペしづらい。すごく
- terminator
- 画面分割はできる
- 背景画像は変更できるけど、うまいぐあいに背景画像を暗くするには設定の変更がひつよう
- コピペできる
- guake-terminal
- 画面分割できない
- 背景画像は変更できる