progrhyme's tech blog

主にIT関連の技術メモ

Redash Meetup #0に参加した

RedashはOSSのハンディなBIツールとして、ちょくちょく名前を聞いて気になっていましたが、あいにくこれまで触ってみる機会がありませんでした。

そんな折にこちらのハンズオンを見かけたので、行ってみることにしました。

ハンズオンは、@kakakakakkuさんがGitHubに公開して下さっている下の資料に基いて実施しました。

丁寧に作られているので、今回のMeetupに参加していない人でも、こちらに沿って作業すると一通り内容が掴めるだろうと思います。

ハンズオン実施項目

上の資料の目次相当のものを書き下します:

  • Redashをローカルマシン上でセットアップ by Docker Compose
  • データソース設定 : MySQL
  • クエリ作成
  • クエリ結果をグラフ化(Visualize)
    • Counter
    • 円グラフ
    • 棒グラフ
  • ダッシュボードの作成
    • グルーピングについて
  • パラメータ付きクエリの作成
  • フィルタ機能
  • クエリスニペット
  • クエリ結果にHTML埋め込み(色を付ける)
  • クエリ結果にURLを含める / リンク集の作成
  • クエリ結果をダウンロードする
  • クエリをフォークする
  • Slackアラートを設定する

割りとサクサク進んで、やや時間が余ったので、追加で以下のようなこともやりました:

  • 時系列グラフの作成
  • Redash内部のPostgreSQLをデータソースに追加してクエリ作成
  • 一般ユーザの追加
  • 管理画面へのアクセス

Q&A

いくつか運用に関して気になったことなどを講師の方々に聞いてみました。

  • Redashサーバをどうやって立てていますか?
  • 権限管理どうしてますか?
    • Redashのデータソースに対する権限設定はFull AccessかRead Onlyしかない
      • Read Onlyにするとクエリ実行すらできない => あまり実用的ではなさそう
    • データソースにするDBMS側で権限設定している。
    • CLIとか駆使すればデータソースに対して細かい権限設定もできるっぽい。誰かがアドベントカレンダーに書くらしい

その他こぼれ話

  • トラブル事例:
    • ディスク容量の逼迫 ... 大きな結果セットのクエリが投げられ、Redash内部のPostgreSQL側にキャッシュされてディスク容量が逼迫した
      • 対策として、キャッシュのパージ設定を調整することができる
  • Undocumentedな機能が色々ある
    • JSONを返すURLとか、シェルコマンドとかもデータソースに使えるとか

感想

BIツールをあまりハードに使い込んだことはないのですが、Redashは便利な機能が色々揃っていて、セットアップも簡単で良いツールだなと思いました。
権限管理など、大規模に使うには少しつらそうな感もありますが、小〜中規模では問題ないのではないでしょうか。

終わりに

次回開催予定について尋ねてみたところ、1〜2月ごろに#1を行いたいと仰ってました。
また、今回のハンズオン内容の再演も春頃(?)に行われるようです。

講師を務めてくださった@ariarijpさん、@kakakakakkuさん、ありがとうございました!

DockerizeしたCLIを使うことについて

昨今、Dockerを使って開発することが当たり前になっている、という人も増えているのではないか。

その場合、開発に必要なツールがDockerに対応していると楽だ。

それはサーバ製品に限らない。
人によっては、 mysql コマンドやAWS CLIといったクライアントツールもDockerizeされたコンテナイメージを利用しているということもあるだろう。

…で、それは多少のトレードオフはあるものの、概ね便利と云って良さそうだ。

Pros

  • インストールが楽。docker runしたらイメージが落ちて来るので、インストールのために何かする意識がほぼ必要ない。
  • ツールの依存物がコンテナに閉じるので、ローカル環境を汚さないで済む。
  • 環境差異にまつわるトラブルを減らせる。「オレの環境では動くのに」問題を減らせる。

Cons

  • Dockerに関するトラブルがあったときに、仕組みをわかってないとシューティングが難しそう。
  • CLIの起動にオーバーヘッドがかかり、フットプリントが大きくなる(と思う)。気にならないレベルなら良いのでは。
  • ストレージを消費しやすい。

1つ目については、CLIにちゃんと適切な環境変数なりを渡してあげないといけないとか、作業ディレクトリを用意しないといけないとか、そういう注意点はありそう。

2つ目、3つ目については、Alpine LinuxなどミニマルなOSをベースイメージとすることで、ある程度抑えられる。

最近、自分でも勉強がてらAWS CLI*1やAnsible*2をDockerizeしてみたけど、まだちゃんと使ってみてないので、特に上の1つ目の点にはハマりそうだなと思っている。

参考

『サイトリライアビリティエンジニアリング』を通読した

8月に邦訳本が発行されたGoogleの『SRE サイトリライアビリティエンジニアリング』を通読しました。

…といっても、今のところいくつかの章はスキップしてしまっているのですが、凡その全容は掴めたかな、というところです。

10月の終わり頃から読み始めましたが、すごく分厚くて(500p超)読むのに時間が掛かりました。
各章は10〜20ページぐらいの記事のような形になっているので、空き時間に章単位で読み進めていくとよさそうです。

全体的な感想

前職でサーバインフラに関わる仕事をしていたこともあり、わかりみの深い話が多かったです。
うんうんと頷くこともあれば、Googleのシステムに感動したり、目から鱗が落ちることも度々ありました。

本書は、サイトの信頼性を維持し、かつ、サービスの変更の速度を落とさないためにGoogleが実践している様々な取り組みや、Googleのシステム/アーキテクチャを解説しています。
技術的な内容はGoogleのシステム・インフラを前提としているものの、大規模システムに留まらない有益な示唆に富んでいると思います。

そういった技術的な各論も非常に面白いのですが、よりメタな概念として、本書から得られる学びの中で、以下の3つはキーポイントだと云えるでしょう:

  • SLOを定めること(3, 4章)
  • トイルの撲滅(5章)
  • ポストモーテムを書くこと(15章)

SLOについて

SLOについては、「クライアントのバックエンドサービスに対する過剰な信頼と依存を避けるために、わざとバックエンドサービスを計画的に停止している」(4章のコラム「Chubbyのグローバルな計画的サービスの停止」を参照)というのは、衝撃的な内容でした。
話としては理解できたものの、プロダクション環境で動いているバックエンドサービスを、そういう目的でわざと止めることが自分にできるかは未知数です。

ポストモーテムについて

この語は私にとって初見でした。
本書においては、「インシデント(なんらかのトラブルやサービス障害)の経緯を記録し、振り返りやその後の改善施策、教訓とともにまとめるドキュメント」と云えましょうか。
付録Dにポストモーテムの例も載っています。

15章では、Google内でのポストモーテムに対する考え方や、ポストモーテムを活用するいくつかの取り組みが紹介されています。
ポストモーテムを広い範囲に共有し、誰もがそこから学べるようにするというやり方は素晴らしいなと思いました。

むすびに

本書の中では、「こんな風にできたらいいな」と理想論に感じるような内容も無いではなかったです。
とはいえ、すぐにできることもありそうだし、目標を定める上でのベンチマークとして参考にすることもできそうだと思いました。

例えば、「SLOを定めましょう」「SLOを達成できているか計測しましょう」「これはトイルなので、工数削減のために機械化します」「障害をチケットに書いて後で振り返れるようにしましょう」とかは、当たり前のこととしてやっていけばいいなと思いました。

冒頭に書いたように、まだいくつか未読の章があるので、そちらも追って読んでしまおうと思います。

GoogleサイトでWiki用のシンプルなテンプレートを作った

こんにちは、Googleサイト愛用者の id:progrhyme です。
紆余曲折を経て、はてなブログに帰って来ました!*1

はじめに

さて、ブログ記事にするまでもない雑なメモをGoogleサイトに書くことにしたのは、およそ1年前のことでした。*2

それ以前にもGoogleサイトでサイトを作ったことは何度かありましたが、これをきっかけにGoogleサイトを頻繁に更新するようになりました。
その後も、非公開のサイトや、最近アカウントを作り直したこともあって、いくつかGoogleサイトを作る機会がありました。

…で、Googleサイトを作るときに毎回テーマを選んで、フォントサイズなどスタイルを調整していましたが、それが面倒になったので、今回テンプレート化しておくことにしました。

なお、コードは1行も書いていません。

作成したテンプレート

https://sites.google.com/site/progrhymewikitemplate/

こちら↑になります。
テンプレートにも書いていますが、補足も兼ねて何をやったか書いておきます。

  • ベースにした基本テーマは「シンプル」というもの。
  • フォントサイズを全体的に一段階ずつ大きめに。
    • デフォルトは地の文が10pxで、少々見づらく感じます。
  • 「目次付き」テンプレートを用意 ... 右サイドバーにページ目次を表示
  • 少し見た目を調整
    • CC0ライセンスの幾何模様っぽい背景画像を設置
    • タイトルヘッダを黒に

まとめると、大したことはしてないのですが、個人的にはこれで十分です。
次からWikiを作るときは、これを使うつもりです。

終わりに

Markdown Hereというブラウザ拡張機能を使うと、GoogleサイトのページをMarkdownで作成できるようになります。
個人的には、技術メモなどをGoogleサイトに書くのはかなりオススメです。

主には自分用に作ったテンプレートですが、よさげに見えたならば、自由にご利用下さい。

もし使ってみて、「こんな機能もつけてほしい」などの要望がありましたら、この記事のコメントやSNSなどでお知らせ頂ければ、対応するかもしれません。
Googleサイトでふだん使っていない機能も多いので、自分では思いつかないようなニーズもありそうです。

それでは、Enjoy!

関連記事(過去ブログより)

脚注

*1:BloggerWordpressと試して、最終的にはてなブログにしました。経緯的なものはざっくりここにメモしています。はてなブログ最高。

*2:雑なメモをいくつか Google サイトに移してみた - weblog of key_amb

Workflow Engines Meetup #1 に行ってきた

初めまして、というべきでしょうか。
@progrhymeとしての初の技術ブログ投稿になります。*1

今日は田町で開催されたWorkflow Engines Meetup #1に参加してきました。

目次

発表タイトル・資料一覧

※まだ全部上がってないので、捕捉したら更新します。

(1) Digdagの特徴とQuick Start / @frsyuki

(2) Jenkins 2.0 Pipeline & Blue Ocean / @hico_horiuchi

(3) Luigiを使っている話 / @bwtakacy

(4) Azkaban in my use case / @wyukawa

(5) Airflowの紹介 / @sekikn39

聴講メモ

Digdagの特徴とQuick Start @frsyuki

今回はアメリカ西海岸からのリモート発表。

  • Workflow Engine とは
    • あらゆる作業の自動化
  • 要求される機能
    • 依存関係の定義
    • 過去分の一括やり直し
    • エラー処理
      • レジューム
    • 状態監視
      • 実行時間長いときに通知
      • 可視化
    • 開発支援
      • WFのバージョン管理
  • 世にあるWF Products
    • OSS, 商用ともたくさんある
  • WF定義方法による分類
    • プログラミング言語
      • Luigi, AirFlow
      • 何でも書ける。自由度高い
      • バージョン管理が簡単
      • コード理解が必要
      • WF全体の俯瞰がしづらい
    • GUI
      • Rundeck
      • シンプル
      • 誰でも開発・管理できる
      • 複雑なループ処理がつらい
      • バージョン管理が難しい
      • 別環境に同じWFをデプロイするのが難しい
    • 定義ファイル + スクリプト
      • Azkaban
  • digdag
    • iconかわいい
    • 定義ファイル+オペレータ+グループ化
      • タスクのグループ化
    • それなりに書きやすく、読みやすい
    • 複雑な処理ならスクリプトを書ける
    • DSLの理解が必要
  • タスクのグループ化
    • 1つに見せかける
    • グループ化されたタスク内で、子タスクを実行
    • 何がよいか?
      • WFグラフが単純になる
  • デモ
    • + でタスク
    • x> オペレータ
      • td> … TD
      • echo>, sh>, etc.
    • 失敗
      • taskが1個失敗
        • state が保存される => resumeできた
    • TDとの連携
      • サーバでWF管理ができる
      • 管理画面付き
        • digdag push
        • WF管理
        • job管理
          • ログ
  • 色んなオペレータ
    • s3_wait>, redshift>
      • s3にファイルができたらredshiftにコピー、とか
    • emr>, pg>, mail>
    • pluginで追加できる
  • Loops & Parameters
  • ドキュメントのリンク
  • Q/A
    • 今後の展望は?
      • GUIでWF編集を便利にしたい
      • pluginをかんたんに追加できるようにしたい
        • Rubygemsにupされたものを簡単に追加できたり、とか

Jenkins 2.0 Pipeline & Blue Ocean @hico_horiuchi

  • 自己紹介
    • NTT Communications
    • ベアメタルクラウドの開発
    • JenkinsとAnsibleによるデプロイの自動化
  • Jenkins
    • 2011年に Hudsonからフォーク
    • ジョブ: shell script, groovy
    • 元々の目的: 開発ルーチンの自動化
  • Jenkinsおじさんの必要性
    • ジョブ生成が属人化する
    • 依存関係が複雑化
    • plugin何が入っているか不明
    • バージョンアップすると動かない
  • Pipeline と Blue Ocean
    • Pipeline Plugin
      • DSLで定義できる
      • 条件分岐、例外処理、並列実行
      • Jenkinsfile
      • branchごとに自動でジョブを作ってくれる
    • Pipeline Syntax
      • stage: ビルド、テスト、ワークフローの段階
      • step: 具体的な処理
    • 条件分岐と例外処理
      • master branch だったらデプロイ
  • Blue Ocean Plugin
    • UXをおしゃれに
    • Pipeline の手順や状態を可視化
    • ダッシュボード
    • まだβ。活発に機能追加されている
    • Design Language で統一性のある UI
    • デモ画面
      • WF見やすい
  • デモ
    • 環境
      • ansible で docker コンテナ起動
      • Pipeline でデプロイ WF を実装
    • リトライ
    • Pipeline エディタ
      • WFをいじれる
        • 実行させるJenkinsのエージェントとか選べる
        • shell script も書ける
      • Jenkinsfileに吐き出せる
  • Jenkinsの使いどころ
    • テスト
    • デプロイ
    • 死活監視・外形監視とアラートの通知
  • Jenkins 2.0に移行したい
    • Multijob => Pipeline
    • Job Builder => Jenkinsfile
      • テンプレート展開の嵐
  • Q/A
    • Pipelineはresumeできる? => できない。全部やり直しになる、と。
    • Pipeline使うときBlue Ocean必須?
      • 必須ではないが、使わないとUIはだいぶ残念な感じになる。

Luigiを使っている話 @bwtakacy

  • 自己紹介
    • 前職: SIer
      • 青いゾウや黄色いゾウと戯れていた
  • データ分析基盤でのLUIGI
  • リクルートマーケティングパートナーズ
    • ゼクシィ
    • 赤すぐ
    • ★スタディサプリ … 小・中、高校生向けに動画提供
      • 学習支援サービス
      • 月額980円〜
  • スタディサプリ・システム構成
  • LUIGI
    • embulk … 50+ のテーブルを連携
    • Hive / Presto によるデータ集約・集計
      • 30+ の Hiveクエリ
    • Jenkins で LUIGI をキック
    • TD Workflow (Digdag) で 10+ の Prestoクエリ
  • LUIGIの基礎
    • 複数のバッチ処理を組み合わせたジョブ制御
    • 処理の依存関係、スケジューリング
    • 処理のアトミック性担保
      • エラー時のやり直し
    • 全て Python で記述
    • プラットフォーム非依存
    • Spotifyが開発したものがOSS
    • LUIGIの名前の由来は「世界で2番めに有名な緑の配管工」
  • LUIGIの範囲じゃない
    • リアルタイム処理、長期間継続実行する処理
    • 分散実行はサポートしてない
    • 処理のスケジュール起動やトリガ起動はできない
    • スケーラビリティは追求してない
  • 用語
    • task
    • target
      • taskの正常終了を示す情報
    • parameter
  • 簡単な例
    • examples/foo.py
      • runメソッド … taskにさせる処理
      • reuiqres … 前提にしているタスク
  • スタディサプリでの使用例
    • TDへのクエリ発行はTDがluigi_tdモジュールを用意しているのでそれを使っている
  • インストール
    • pip install luigi
    • WF実行
      • --local-scheduler
        • コマンド実行ごとにスケジューラが起動
  • デモ
    • luigi --module foo examples.Foo --workers 3
      • --workers 並列数
  • 困ったこととか
    • taskの実行時間が知りたい
      • PROCESSING_TIMEイベント
        • ビルトイン・イベントとそれに対するコールバックを登録できる仕組み
        • FAILUREイベント
        • PROCESSINGイベント
          • mixin作ってやってる
    • 並列実行とコマンド戻り値
      • デフォルトでは失敗しても戻り値 0
      • retcode で設定できる
      • LUIGI.CFG
        • luigiコマンド実行時に読み込まれる
    • RETCODEをバイパスしたWFができてしまう
      • スクリプト内に if __name__ == '__main__' とかのブロックで luigi.run() すると駄目
    • 並列実行すると戻り値がおかしくなる
  • まとめ
    • シンプルなWFを記述するには重い
    • digdagに移行中
    • 管理画面は大したことない

Azkaban in my use case @wyukawa

  • Azkaban
    • LinkedInで作られた => hadoop job 依存関係を解決するため
    • Job
      • モダンじゃないJava(raw servlet, velocity, …)
  • 構成
    • mysql
    • web server
    • executor server
  • シンプルなジョブ管理
    • 依存関係
    • リトライ
    • Scheduling
    • Web UI
      • SPOF
    • Log
      • 12週間は表示される
    • カレンダー
      • 祝日の登録できない
    • メール通知のみ
      • 最近 HTTP Job Callback できた
    • No binary
      • ソースを自分でビルドしないといけない
    • not so active
    • ML 事実上機能してない
  • Job File
    • Javaのプロパティ形式
  • 用語
    • project
    • job
  • Scheduling
  • Failure Options
    • # difference when ccc failed
    • Finish Current Running
    • Cancel All
    • Finish All Possible
      • 依存関係ないジョブは継続実行する
      • ★これがデフォルトで有るべきだが、そうなってないので全部指定している
  • Re-run when failed
    • 失敗したやつだけ再実行は簡単
  • concurrent execution options
    • skip execution … 多重同時実行しない
    • run concurrently … する
    • pipeline … 使ってないのでよくわからない
  • Q/A
  • Use case
    • hadoop job の管理
    • Azkaban API
      • wyukawa/eboshi 作った
      • スケジュール情報を GHE にコミット
    • job file 作るのつらい
      • 生成ツール作った
  • python batch example
  • Job management overview
    • git push
      • git pull generate job file
    • Jenkins - upload job
  • これまで
    • 120 のflow作った
      • だいたいdailyバッチ
    • azkaban in batch server
    • backfill / 過去分のやり直し
      • azkaban自身にこの機能はないが、工夫してやっている:
        • azkaban flow を template 化して
        • from to の日付を渡して実行
    • SLA 使ってないが使うかもしれないので PR している
  • 所感
    • シンプル
    • 使いやすい
    • Web UI 便利
    • API 便利
    • 別のものに置き換える理由はない
  • ozaさん(?)からのコメント:

Airflowの紹介 @sekikn39

  • 自己紹介
    • SIer
    • apache hadoop, spark システム構築・運用。サポート、研修サービス
    • Apache Yetus コミッタ
  • Airflow に興味を持った背景
    • いくつかの案件で WFE として Apache Oozie を使用
    • oozie の制約・好きでないところ
      • WF を XML で定義するため、可読性・柔軟性に欠ける
      • 任意の DAG を作れない
      • Web UI が古い
      • => それ Airflow でできるのでは
  • 概要・機能紹介
    • users
    • 2016/3 に Apache プロダクトになった
    • luigi 同様、pip で入る
    • 概念
      • DAG … ジョブの実行順序・依存関係を記したグラフ
      • Operator … タスクの雛形
      • Task
      • Task Instance … 特定のジョブで実行されたやつ
    • デモ画面
    • Operator
      • コマンド発行:
        • BashOperator, Docker, SimpleHttp, Python
      • SQL発行:
      • データ転送
        • HiveToDruidTransfer, HiveToMySqlTransfer, …
    • その他
      • Connection: 接続情報を管理
      • Pool: タスクの並列数を管理
      • SLA: 一定時間内に成功しなかったtaskを管理者にメール通知
  • デモ
    • Web UI
      • DAG 閲覧
    • job 実行
      • fail
    • executor 指定できる
  • 要望
    • 不足機能
      • HA構成のサポート
      • DAGの登録・更新・削除をWeb UIから実施したい
      • TZ UTC以外のサポート
      • Web UI から WF の任意の場所でジョブを再開等
  • Airflow Meetup Tokyo?
    • PMC chairに会ったら、東京でもやったらと提案をもらった。

雑感

  • Digdag段々機能が充実してきているのを感じた。
  • Jenkins, Blue Oceanはまだβだが、Pipeline Pluginと組み合わせて使いたい。
  • Luigiは、つらみを感じた。
  • Airflow, UIきれい。

終わりに

第2回も有るっぽいので、楽しみ。 @sonots 氏の Trigrav や @joker 氏の Rukawa の話が聞けるかも。


*1:最近ハンドルを変えました。前は id:key_amb でした。以前の技術ブログは、weblog of key_amb