by shigemk2

当面は技術的なことしか書かない

kibana v5.1.2/v4.6.4

AWS

Kibana 4.6 Release Notes | Kibana User Guide [4.6] | Elastic

5.1.2 Release Notes | Kibana User Guide [5.1] | Elastic

Discover
Improve spy tab performance on Discover #9464
Timepicker
Timepicker now has a collapse button again #9381
Visualize
Using a secondary datetime field no longer triggers an error #9458

Release v5.1.2 · elastic/kibana · GitHub

Release v4.6.4 · elastic/kibana · GitHub

Treasure Data Serviceの機能開発と安定運用の狭間におけるあれこれ #tdtech

Treasure Data
  • 機能開発側のはなし
  • システムアーキテクチャのはなし
  • いまどんなところに注力しているか
  • 信頼性確保

アーキ

  • (API server w/ RoR) * 4 w/ load balancer
  • MySQL(JobQueue)/S3/RiakCS/MySQL(AccountDB)
  • Worker(Ruby+Java)
  • YARN Cluster(Hive/HDFS) / Presto Cluster(presto)
  • ObjectStorage(S3/RiakCS) MetadataDB(PostgreSQL)
  • Log Collector(fluentd)
  • embulk
  • Hosted cevent collector(fluentd)
  • digdag

チーム構成

  • hadoopやってるチーム
  • JSでコンソール書いてるチーム
  • APIサーバーの開発をやっているチーム
  • キューの管理をやっているチーム
  • インフラの管理をやっているチーム
  • 1チーム2-4名 プラス 外部のひと 計6人
  • エンジニア24人 マネージャー3人 その他サポート、セールスなど
  • Scalaのほうが好きな人はScala書いてもらうし、Rubyが好きな人はRubyを書く

SRE

  • ソフトウェアエンジニアとは別のSRE
    • Site Reliability Engineering
    • 信頼性
    • SRE専用のチームはTDにはない
  • ストレージの開発
  • 新機能開発
  • 何割かの時間を信頼性の確保に当てる

Site Reliability Engineering: How Google Runs Production Systems

Site Reliability Engineering: How Google Runs Production Systems

  • 作者: Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy
  • 出版社/メーカー: Oreilly & Associates Inc
  • 発売日: 2016/04/16
  • メディア: ペーパーバック
  • この商品を含むブログを見る

  • 分散システムを安定させる
  • ローンチで失敗しないために設計の段階から考える

  • 信頼性確保のためのしごと

  • Product/Development/CapacityPlanning/Testing ReleaseProcedures/Postmortem RootCauseAnalysis/IncidentResponse/Monitoring

  • JIRA/Github/CircleCI

  • Datadog
  • CircleCI/Github/Chef
  • JIRA/Gyazo
  • PagerDuty/StatusPage/Sentry/Confluence

  • Slack/Datadog/CloudWatch/NewRelic/Pingdom

  • APIに依存しているコンポーネントが多く密結合

  • CircleCIがGreenになったらリリース
  • capacity palnning
    • 予測モデルを作って、先行してノードを作ったりプロビジョニングしたりして、顧客のリソース不足を防ぐ
    • リトライなどを適切な方法で適切な回数行う − datadogは課金がインスタンスごとで、簡単にメトリクスを増やせる
  • アーキを直したければプロダクトを直す必要があるので、チーム間でのコミュニケーションが必要
  • JIRA/Confluenceを利用して、クリアに書く (オープンかつ簡潔に、分かるように書く)
  • US/JP待ちだと時差のオーバーヘッドが発生する
  • 遠隔地
  • LucidChart(Webベース)
  • Numbers(ローカルで動かせる)

  • digdag/prestoそれぞれのチームでdatadogのダッシュボードがある

  • 開発をしながら信頼性確保するためには何をしたらいいかの人材が必要

  • 超エースエンジニアを信頼性確保にかかずらわせるのはよくない

  • metricsを集めて自動化するなどしたい
  • 信頼性確保のためのヒアリングを行う

ActiveRecord issues #tdtech

Treasure Data

ActiveRecord issues #tdtech

  • kamipo
  • activerecordについての話
  • rails issues team

http://blog.steveklabnik.com/posts/2012-07-05-how-can-i-contribute-to-ruby-on-rails-

  • Railsに2016年一番コミットした人なので、お前勝手にやれって言われた
  • Rails 5.0→5.1(Edge Rails)
  • Railsにコミットすごくしてる

  • Railsは3.2のこと − executeしないといけない

  • 綺麗なDSLを書いたら必要な情報が消えてしまう

  • SQL手書きしないとまともに書けない
  • schema dumperが使い物にならない
  • 余裕で直せるのに直せる人がいない

  • 困っている人がいる問題が直るのではなく直す気のある人がいる問題が直る

  • 直すしかない

  • 5.0を自分が使って不便じゃないようにする

  • MySQL対応直した

  • MySQLからいろいろな機能が出ているのにRailsが全く対応していない

  • custom primary key対応
  • テーブルオプション対応
  • date time round problem(保存すると時間がroundされる)対応
  • ストアドプロシージャがろくずっぽ使えない
  • プリペアドステートメントがろくずっぽ使えない
  • ONLY_FULL_GROUP_BY対応
  • sql_mode = amipo TRADITIONAL(厳格なSQL MODEで動かせる)

  • 200コミットくらい

  • MySQLとUnicodeの問題

  • 欧米では全然問題にならないユニコード

  • 寿司ビール問題 ハハパパ問題

    • 他のDBで起きない問題がMySQLでは普通に起こる

  • utf8mb4_general_ui

  • utf8mb4_unicode_ci
  • utf8mb4_unicode_520_ci

  • utf8mb4_bin(オールOK)

  • 欧米の人に分かるように説明するために理論武装

  • collating weight問題

  • MySQL 8.0.1 Release Notesが出ると日本人が死ぬ

  • active recordを直しても問題は終わらない

  • コアには入れづらいやつ
    • create with
    • retryable_find_or_create_by
    • find_or_create_byのcreateがUNIQUE制約に引っかかったらfindしなおす
  • いろいろ直している
    • 5.0には入らなかった
      • クエリのORDER BYが削られてCOUNT飛ばされてスロークエリになる問題を直した
      • 「ORマッパーでクエリを書き換えてほしくない派」
      • masterにはマージされた

Future

  • 実装は出しているのであとは入るかどうか

  • prepared statement

    • SQLモジュールをキーにしてキャッシュしている

  • has_manyを170倍早くする (3から4で100倍遅くなった)

まとめ

  • ActiveRecordの困っているところをひたすら直した
  • 直さないと直らない
    • 困っているって声を挙げても開発者は何もしてくれないことが多い
    • 直す気のあるひとがいる問題が直る

メモ Stable large scale Presto cluster #tdtech

Treasure Data

Presto In TD

  • TD API
  • BI Tool HTTP

から、クエリを投げる。

  • prestobase proxy
  • node schedular(presto)
  • resource group

Prestobase proxy

  • JDBC/ODBCはいけていない

  • リプレイスするためのPrestobase Proxy

  • HTTP接続するときにPrestoが使える

  • Scalaで書かれている

  • Finagle(RPC proxy)がコア
  • Dockerコンテナ上で動いている
  • Airframe
  • VCR 軽量テストフレームワーク

Finagle

  • 実績がある
  • クライアント/サーバのインターフェイスが透過的に使える
  • サービス提供側からするとドライバからもPresto側からも嬉しい
  • プロトコルは問われない

  • 詳細な使い方はドキュメントを見ること

  • Presto Clientで投げる

  • DIしたかったがScalaでは良いツールがなかった
    • なかったのでAirframeを作った

  • オブジェクトの実装をbindする
  • bindを呼び出すことでinjectされたオブジェクトが取れる
  • オブジェクトの管理はsessionで行われている
  • 良いこと オブジェクトのbindのときにScalaの型安全が保証されること、見た目が良いこと

VCR testing framework

  • PrestoのテストをCIをやるとコンテナのメモリが足りなくて死ぬから軽量なのが欲しかった
  • filter handler
  • client→(prestobase+requestvcr)→sqlite
  • CI上ではリプレイするだけなのでPrestoは建てなくても大丈夫
  • Prestobase Proxyもいずれオープンソース化する

Node Scheudlar

  • 分散のクエリ
  • ユースケースが増えすぎる問題
  • クエリ
    • ステージと呼ばれる集まり
    • 分散ワーカーにばらまくタスク(やることは一緒だが取ってくるデータは違う)
    • タスクが増えるほど処理効率があがる
    • ステージはフローで、ステージ1が終わらないとステージ2が進まない
  • この処理(フロー)を制御するのがnode schedular
  • 既存のNode Schedularはランダムに仕事を適当に割り振ってしまうので、忙しいワーカーにさらに割りふられることがある
  • メモリを考慮したNode Schedularを開発
  • e.g. memory pool
  • 重たいタスクを使う
  • メモリープールを意識したスケジューラ

Resource Group

  • 0.147のPrestoから導入

  • general group
  • adhoc group

  • root group

  • 最大いくつキューがあるか

  • どのくらいのメモリが使えるか

  • 子供の値は親の値から流用できる

  • maxqueued

  • maxrunning
  • softmemorylimit
  • softcpulimit
  • hardcpulimit

https://prestodb.io/docs/current/admin/resource-groups.html

  • 投げられたクエリは1つ1つのリソースグループに属する
  • リソースグループセレクター
  • e.g. sourceにadhocが含まれていたらadhocグループに紐付ける
  • resource group di
    • Guice injectionを使ったDI
  • resource groupの挙動を変えたいときは以下のクラスのメソッドを呼び出す
    • ResourceGroupConfigurationManager#configure
    • ResourceGroupSelector#match
  • SelectionContext − Authenticated
    • User
    • Source
    • Query Priority
  • 認証情報
  • Currently available as default
  • GuiceからDIで挙動を変更することができる

まとめ

  • Prestobase Proxy
  • 分散システムのコードをいじるのは大変なので、VCRやAirframeを使ってコードの修正をしやすくした
  • タスクの量が増えてきたので、リソース管理を効率的に行うためのスケジューラを作った(experimental)

質疑

  • メトリクスとしてはメモリープールを使うっていうのはやっている
  • タスクのジョブはリトライされる

メモ DigdagによるRedshift + EMRの自動制御とデータ分析アプリケーションの開発 #tdtech

Treasure Data

digdag

github.com

(途中参加)

  • ワークフローエンジン

  • Aをやって、Bをやって、でもBが失敗したらCをやる、というのを、コードを書かないで制御する

  • サーバー

  • どこの環境でも動くこと
  • ワークフローが手元でも動く
  • ステップを足す→ローカルで実行する

  • サーバーでアプローチすればサーバーで動く

  • Luigi

    • 上から下へワークフローを動かす
  • digdag
    • digdag ネスト出来るようにした
    • グループを作れる
  • ある別のシステムがファイルをアップロードする→アップロードできたらコピーする

  • パラメータは一部ビルトイン

  • tdのクエリを実行する

  • redshiftのクエリを実行する
  • big query
  • td for each

  • ポスグレ

  • メール

などなど…

  • slackへ通知も出来る

  • ローカルで実行する→デプロイする

  • サーバAで実行する→サーバBでも実行できるようにする

  • 特定のプログラミング言語を特定のバージョンで特定の環境のなかでやりたい

    • dockerオプション
    • ubuntu:16.04 と書けば、ubuntu16.04のなかでrubyを実行したり出来る
  • loopが出来る

  • プラス単位で書く

  • load_data

  • load_users
  • load_items

デモ

  • アイテムを買った人に対してその場所でのおすすめアイテムをレコメンデーションする

  • TDからデータを集める

  • 処理は並列で行う
  • 集めたデータをS3に置く
  • Amazon EMRでSparkを実行する
    • 新しいクラスター名をつくり、、アプリケーションを投入して実行し、クラスターを閉じる
    • javaで書いたsparkアプリケーション
    • td-spark
      • sparkのデータをtreasureで参照する
  • redshift→elastic searchで全文検索する
  • 前回の処理が成功したら特定のジョブをスキップすることも出来る

workflow steps

  • よくあるワークフローは複雑
  • これらをグループ化して、実行順序を制御する

web ui

  • タスクの進捗、ログ、成功失敗を確認することが出来る

  • 登録はまだ無理

  • エラー通知は可能

  • YAML

  • パラメータを利用して、過去分を再実行することが出来る

  • digdag ui/digdagはまだ発展途上であること