builderscon tokyo 2018 に行ったらコードを書く元気が出た気がする
あのセッションを聞いたから、とかは特に思い当たるものはないんだけど、 builderscon tokyo 2018 に行って以降、コードを書く元気が出てきた。というか復活したという感じがある。
最近はコードを書く時間というのは減っていたんだけど、なんというか、builderscon の雰囲気というか、「みんないろいろやってんなー」という感じに触発されたのかもしれない。
行ってよかった。
Mackerel UG × IDCFクラウド UG Meetup で半飛び込み LT してきました
9/11(火) に開催された「Mackerel UG × IDCFクラウド UG Meetup」に参加してきました。
タイトルに「半飛び込み」と書いてあるのは、当日に登壇枠を融通いただいたためです（songmu さん調整ありがとうございました！
せっかく参加するならなんか発表したいなと思い、LT で OSS を使って監視システムを自作してみるという話をしました。
構想はイベント前日、デモ環境と資料は当日に用意したので少し焦りましたが、LT っぽい話に仕上がったんじゃないかなと我ながら思っています。
以前から多分それっぽく簡単に作れるなと想像はしていたのですが、実際デモをするために作った環境はだいたい1時間半ぐらいで構築できました。
Mackerel の話も IDCF クラウドの話も含んでいない LT だったので、イベントの趣旨に対してちょっと変わった発表ではあったと思うけど、登壇後「面白かった」という反応もいただいたので、楽しい時間を過ごす中のひとネタになっていたらうれしい。
デモ環境で主に使った OSS は以下の3つ。
これは知らなかった人が多そうな印象を受けました。Load Average などの値を SQL で取得できるという面白いツールです。
Fluentd | Open Source Data Collector | Unified Logging Layer
説明不要だと思いますので割愛。 osquery が出力した JSON を MySQL に流し込むのに使いました。
メトリクスの可視化、通知にはもちろん Redash を使いました。
急遽 LT 枠を調整いただいた運営のみなさま、会場でいろいろお話させていただいたみなさま。ありがとうございました！
Redash Meetup 3.0.0 で発表した「Hidden gems in Redash」の補足説明
先日のイベントで話した内容について、スライドを公開したものの、英語で書いてしまったせいで誤解を生んでしまうことがあったようなので、改めて日本語でも解説しておきます。
発表資料
タイトルについて
「Hidden gems in Redash」。Redash の中にある見つかりにくい機能を「Hidden gems」と例えたつもりだったのですが、ここからわかりにくかったなと反省しているところです。
Ruby の gem の話と混同してしまったかたも、もしかしたらいたのかもしれません。
Query Results Data Source
これについては、去年書いた記事があるので、そちらを見ていただくのが良いと思います。
上記の記事でもふれていますが、現時点でクエリパラメータを使ったクエリを使うことはできないという制約があり、それについては現在議論中です。
ReQL query language - Feature Requests - Redash Discourse
Python Data Source
Redash 3.0.0 以前から使用できるので、Redash を長く使っているかたには馴染みがある機能の一つでもあると思います。
スライド中で紹介した記事は以下です。
re:dash Python datasource join example · GitHub
国内での活用事例もいくつか見つかりますので、興味があれば探してみてください。
Url Data Source
このあたりから知られにくい機能の話になってきます。
Url データソースは HTTP エンドポイントをデータソースとして扱える機能です。
エンドポイントの仕様としては以下のようなものがあります。
上記の仕様を満たしていれば、ミドルウェアや言語に制約はないので、Web 開発に慣れているエンジニアが多いチームであれば導入を検討しやすい機能だと言えます。
発表中でも紹介しましたが、JX通信社さんでの事例が最近公開されていたので、この記事でUrl データソースを知った方もいらっしゃるかと思います。
Script Data Source
この機能はサーバー上に配置されているスクリプトや実行ファイルをデータソースとして扱える機能です。
スクリプトが標準出力に Redash 形式の JSON を出力することが満たされていれば、Url データソース同様にどんな言語で書くこともでき、発表時は Python と Bash で実装した例をご紹介しました。
ただし、この機能は任意のスクリプトを実行することができるという点で、導入を検討する際は、使用できるユーザーを制限するなどの権限管理などには注意しましょう。
Extending Redash
最後に紹介したのは、Redash のクエリランナーを自作するという話を紹介しました。
クエリランナーの挙動をある程度把握することができれば、独自のクエリランナーを作成し、Redash 上で動作させることができるようになっています。
クエリランナーの自作については、以前書いた記事があるので、そちらを参考にしてください。
また、発表の中で紹介した、Redash 開発者の Arik が後悔している記事もあわせて紹介しておきます。
Creating a new query runner (data source) in Redash - Development - Redash Discourse
外部 API を使用する、CSV や Excel のファイルを S3 や Google ドライブから取得して表示するなど、クエリランナーを自作できると、Redash 活用の幅を広げることができると思います。
発表のまとめ
Redash を高度に活用するためのいくつかの機能を紹介しました。
Redash は 多くのデータソースに対応しながらも、Url データソースやクエリランナーの自作など、開発者が拡張できる余地があります。
ただし、無理にこれらの機能を使おうとしなくても、よく使われる既存のデータソース(MySQL や PostgreSQL, BigQuery など)だけでほとんどの問題を解決できるはずです。
あくまで、既存のデータソースでは解決できない問題に出会った場合に利用を検討する程度に、今回の発表の内容を捉えていただくと良いと思います。
With great power comes great responsibility
この記事のまとめ
当日お話した内容を思い返しつつ、解説記事を書いてみました。
正直、無理に英語で書くこともなかったかなとは思うものの、英語で書こうとすると回りくどい言い回しができなくなるため、メッセージがシンプルにできるのかなという感想を抱きました。
英語で書いた理由は、単にチャレンジしたかったというものの他に、海外の Redash ユーザーにも読んでもらえたらいいなと思ったというのがあります。
実際読んでもらえているかはわかりませんが、それはスライドの View 数や Star 数でも見ながら想像してみようと思います。
Redash Meetup 3.0.0 を開催しました
タイトルのとおりですが、7/9に Redash Meetup 3.0.0 を開催しました。
今回は LT 枠を削って10分の登壇枠を2つ用意し、約1時間半で4本の登壇をみっちり詰め込んだイベントになりました。
発表内容振り返り
Redash の API 活用事例 / 株式会社ココラブル 井上さん
Redash API 活用事例について、具体例を交えて発表されていました。
API を使用するシーンとして各社で利用されているであろう、Slack 通知や Google スプレッドシートへの自動書き出しだけでなく、API と Git を組み合わせたクエリのバージョン管理についても発表されていました。
発表の中でいくつかライブラリやツールを紹介していましたが、そのうちのいくつかは私が GitHub で公開しているものだったりします。
よろしければチェックしてみてください。
みんなが Redash を 気持ちよく使うやり方を 考える / コネヒト株式会社 金城さん
前回、コネヒトの永井さんに Redash の導入について登壇していただきましたが、今回は導入後の話を中心に発表していただきました。
登壇をお願いするきっかけとなったクエリ乱立問題へたち向かう話や、今起きている問題を「データ活用のステージ」に照らし合わせて、解決のアプローチを考えるという話は、データ分析や分析基盤構築に関わるエンジニアにとって、共感のある話だったのではないかと思います。
発表の中でも触れられていたハンズオン資料ですが、今回も受付を手伝ってくれた id:kakku22 が作ったもので、実はこの資料きっかけで Redash Meetup 立ち上げたという小話があります。
まだ試したことがないかたは、ぜひ資料を見ていただき、ついでに Star もつけていただけると良いかと思います。
Hidden gems in Redash / 株式会社ユニトーン 有田 (ariarijp)
他の登壇者様が現場感のある Redash の事例についてお話いただけることがわかっていたので、そのなかで私はちょっと変わった発表をしたいと思っていました。
今回のテーマは「Redash の高度な活用」として、様々な（一部はデフォルトでオフになっている）データソースの紹介や、Redash のクエリランナーを自作するといった話を思う存分お話させていただきました。
もちろん、ただのネタ発表ではなく Redash の開発者フレンドリーなところがみなさんに伝わったのではないかと思います。
イベント後の懇親会でもポジティブな感想をいただけたので、それなりにお楽しみいただけたのかなと思っています。
Redash運用に付きまとう課題とその解決方法 / 株式会社エウレカ 大久保さん
エウレカにおける Redash 導入のきっかけや、導入後に発生したいくつもの課題を3つのフェーズに分けてご紹介いただきました。
「クエリ乱立」、「不正確クエリによる意思決定のミス」、「権限管理」などの Redash を運用するエンジニアにとって定番の課題だけでなく、
「キューづまりとの戦い」、「BigQuery の課金額上昇」、「便利だけど大変なことも多い定期実行」などについても、エウレカさんの事業成長のなかで日々起こったであろう課題について、事細かにお話いただきました。
現在は Tableau も併用されているとのことで、Redash 導入によってデータ活用が進んだ先に、どのように分析環境や基盤を広げていくか。という点でも参考になるお話だったかと思います。
こちらの発表については、早速エウレカさんのエンジニアブログでも記事にされていますので、そちらもぜひ読んでみてください。
また、エウレカさんには DataManagement Engineer というポジションがあるようです。今回の発表や資料を見て興味をもたれた方は、素敵なオフィスに遊びにいってみるのもよいと思います。
懇親会
今回は Redash Meetup 初の懇親会も開催されました。会場だけでなく飲み物やピザを提供してくださった エウレカ様、本当にありがとうございました！
懇親会中、ふらふらと歩きながらいろいろな方とお話したのですが、Redash の導入・活用事例、悩みなど「これこそ Redash Meetup の懇親会だ！」と思うような会話が飛び交っていて、主催者としても大変うれしい気持ちになりました。
Twitter のトレンド入り
参加者数が過去最多であったり、ゲスト用のWiFiが快適に利用できたこともあるのか、Twitter への投稿が過去最多だったように思います。
一時はトレンド(おそらく東京エリア)にも入っていたようです（運営に手一杯でリアルタイムでは見られませんでした
トレンド入りした！！ #redashmeetup pic.twitter.com/DkGCuYkOlr
— masa (@smdmts) 2018年7月9日
自分が運営するイベントがトレンド入りするようなことは想像もしていなかったので、これには驚くばかりでした。
まとめ
今回はエウレカ様の会場をお借りしたり、募集枠が前回の倍以上だったり、懇親会ありだったりと多くのチャレンジや変化があったイベントになりました。
開催前はいろいろと不安を感じていたのですが、登壇者の皆様、参加者の皆様、会場設営から懇親会までお付き合いいただいたエウレカの皆様のおかげで、楽しくまじめに Redash の情報交換ができた会になったと思います。
「次回のイベントはいつですか？」という嬉しい質問もいただいていたのですが、現時点で次回の日程は決めていません。
しかし、Redash のバージョンを追い抜くまではやろうと思っているので、4.0.0 は実施する予定です。
次回については決まり次第お伝えさせていただきますので、ご興味があれば私の Twitter や connpass の Redash Meetup グループをチェックしてみてください。
以上、Redash Meetup 3.0.0 の開催レポートでした。
楽しかった！！！！！
Redash の複数台構成化その3(worker を別インスタンスにする)
以下の記事の続きです。
前置き
前の記事の手順を実行し、Redash と PostgreSQL、Redis をそれぞれ別インスタンスで動作させる環境ができていることを前提とします。
worker を別インスタンスにする
worker のインスタンスをセットアップする
worker インスタンスは server インスタンスと同様、Redash の Ubuntu 用 bootstrap スクリプトで Redash を導入した状態になっているものとし、PostgreSQL、Redis インスタンスにそれぞれ接続できるようになっていることを前提とします
- プライベート IP 192.168.33.11
Redash のバージョンについて
worker を別インスタンス化するには、server と同じバージョンの Redash をインストールする必要があります。
初期構築時に server と worker を分ける場合はそれほど問題にならないと思いますが、ある程度一台構成で Redash を稼働させた状態から複数台にする場合は、最新バージョンとの差異が問題になることもあります。
その場合、既存環境を最新にアップグレードしてから複数台構成にするなどの対応が必要となりますが、この記事ではアップグレード手順などについては割愛します。
不要なサービスを停止する
nginx, PosgreSQL, Redis は使用しないので、以下のコマンドで停止し、自動起動も無効にします。
$ sudo systemctl stop postgresql && sudo systemctl disable postgresql $ sudo systemctl stop redis && sudo systemctl disable redis $ sudo systemctl stop nginx && sudo systemctl disable nginx
Redash の設定を変更する
server インスタンスと同様に、worker インスタンスの /opt/redash/.env の REDASH_REDIS_URL と REDASH_DATABASE_URL を以下のように変更します。
export REDASH_REDIS_URL=redis://192.168.33.101:6379/0 export REDASH_DATABASE_URL="postgresql://redash:redash@192.168.33.100/redash"
supervisor の設定を変更する
最後に、supervisor の設定を変更します。
worker インスタンスでは、server を起動する必要がないので、 /etc/supervisor/conf.d/redash.conf の redash_server の設定の中の autostart と autorestart をそれぞれ false にします。
[program:redash_server] command=/opt/redash/current/bin/run gunicorn -b 127.0.0.1:5000 --name redash -w 4 --max-requests 1000 redash.wsgi:app directory=/opt/redash/current process_name=redash_server user=redash numprocs=1 autostart=false autorestart=false
/etc/supervisor/conf.d/redash.conf を変更したら、Redash と supervisor の設定を適用するため、supervisord を再起動します。
$ sudo systemctl restart supervisor
再起動を完了したら、 ps コマンドなどで Redash 関連のプロセスが Celery のみ起動されていることを確認しましょう。
これで worker の設定は完了です。
server のインスタンスの設定を変更する
worker インスタンスで Celery が動作するようになったので、server インスタンスでは Celery を動作させないようにします。
/etc/supervisor/conf.d/redash.conf の redash_celery と redash_celery_scheduled の設定の中の autostart と autorestart をそれぞれ false にします。 、
[program:redash_celery] command=/opt/redash/current/bin/run celery worker --app=redash.worker --beat -c2 -Qqueries,celery --maxtasksperchild=10 -Ofair directory=/opt/redash/current process_name=redash_celery user=redash numprocs=1 autostart=false autorestart=false [program:redash_celery_scheduled] command=/opt/redash/current/bin/run celery worker --app=redash.worker -c2 -Qscheduled_queries --maxtasksperchild=10 -Ofair directory=/opt/redash/current process_name=redash_celery_scheduled user=redash numprocs=1 autostart=false autorestart=false
/etc/supervisor/conf.d/redash.conf を変更したら、設定を適用するため、supervisord を再起動します。
再起動を完了したら、 ps コマンドなどで Celery のプロセスが起動されていないことを確認しましょう。
動作確認
ここまでの設定が完了したら、 Redash の画面上でクエリを実行してみます。
クエリが実行できれば、worker の別インスタンス化は完了です。
まとめ
Redash の worker プロセスを別インスタンスで実行する方法を紹介しました。
Redash のミドルウェア構成を把握することができればそれほど難しくない対応ですが、大規模なデータを扱いたい場合や、クエリのキューがつまりがちな環境では、今回紹介したような方法で worker を別インスタンス化することで問題を解消できることがあると思います。
しかし、サーバ管理の手間は増えるため、ひとつのインスタンスに全部のせ担っている標準的な構成でスケールアップやミドルウェアや Redash のチューニングに限界を感じた場合の選択肢の一つ。として考えるぐらいが個人的には良いと思います。
次回は、この記事から少し派生した設定として、 redash_celery_scheduled のプロセスをさらに別インスタンスで起動し、詰まりがちなスケジュール実行をスケールアウトする方法を試してみる予定です。
