Lobiチームの長田です。 今回はLobiチームで使用しているRedashとRundeckというツールについて紹介します。
Redash
Redashとは
Redashはデータベースにクエリを発行するためのダッシュボードです。 複数種類のデータベースに対応しており、それらに対して
- クエリ発行
- クエリ結果を保存
- クエリ結果を可視化
することができます。 その場でクエリ発行する他に、間隔を指定して定期実行することもできます。
ブラウザからクエリを定義して、
グラフとして表示したり。
何に使ってるの？
LobiではアクセスログをAmazon Redshiftに取り込み、解析を行っています。 定常的に観察するべき項目については専用の解析処理と結果を保存する仕組みを用意しているのですが、 単発で数字が必要になる場合がたびたび発生します。 このような場合に毎回Redshiftにアクセスできるエンジニアが手を動かすのは依頼する側もされる側も面倒です。
Redashを導入した結果、Web UIから安全にRedshiftにアクセスすることができるようになりました。 もちろんSQLの知識は必要ですが、ターミナルでの操作を覚える必要はありません。 データベースに直接アクセスするわけではないのでデータベースのアカウント情報を共有する必要もありません。 クエリの結果を保存することができ、定期的に実行するよう設定できるため、 「この前出してもらったあの数字、今はどうなってる？」という問に対して、 「このページ見てください」で済むようになりました。
Tips
調査用のデータベースを用意する
クエリを実行することには変わりないので専用のデータベースを用意するのが安全です。 Lobiの場合、MySQLについては専用のslave用意しそちらを参照しています。 このslaveはmysqldumpでバックアップをつくる際にも利用しています。 Redshiftはそれ自体が調査用に用意されたものなのでひとつのデータベースだけで運用しています。
データの蓄積はできない
Redashでできるのはひとつのクエリの結果を保存・グラフ化することだけで、 過去に実行したクエリの結果を保存したりそれらを組み合わせて可視化したりすることはできません。 対象期間すべてを対象にしてひとつのクエリで集計を行うこともできますが、 集計に時間がかかりますし元データをいつまでも集計可能な状態にしておかなければなりません。 Redashで集計するのは直近のデータに絞り、過去に遡って値を知る必要がある場合は別の方法を選択するべきでしょう。
クエリの同時実行数・最大実行時間制限
安全にクエリ発行できるとはいえ、何も気にせず全レコード走査されてしまうと他の調査用クエリが詰まってしまいます。 Redashを使用するユーザーにSQLの知識をつけてもらうのはもちろんですが、 うっかりとんでもないクエリを発行してしまう可能性はゼロではありません。
RedshiftにはWorkload Management (WLM)の機能があり ユーザーグループ毎にクエリの同時実行数や最大実行時間を制限することができます。 これを利用してRedashから接続するユーザーをredashというユーザーグループに所属させ、 このグループのユーザーは同時実行数を2、最大実行時間を1時間に制限しています。
アクセスログとユーザーデータの突き合わせ
アクセスログに記録されたユーザーIDと、別のデータベースに保存されているユーザー情報を突き合わせて集計を行いたい場合があります。 例えば「昨日サインアップしたユーザーのアクティブ率は？」のような問いに答える場合、 ユーザーデータが保存されているデータベースからサインアップした日時を取り出し、 それを条件にアクセスログに記録されているユーザーIDを絞り込む必要があります。
LobiではMySQLのテーブルをRedshiftに取り込むことで、Redshift上で集計処理が完了するようにしています。 MySQL上のレコードをフォーマットしてgzip圧縮しAmazon S3にアップロード、それをRedshiftからCOPYコマンドでロードしています。 S3からのデータロードについてはAWS公式のドキュメント がありますのでそちらを参照して下さい。
また、先日Redash上で複数データソースをマージ できるようになったのでそちらを使うという手もあります。 ただし、マージ処理はRedash上で行われるため大量のレコードをマージしようとすると その分転送量がかかりますし、Redashホストのマシンパワーも必要になるため注意が必要です。
Rundeck
Rundeckとは
Rundeckは予め設定されたジョブを実行するためのアプリケーションです。 手動で実行を開始する他、crontabのように定期的に自動実行することもできます。 また、ジョブの実行履歴を実行結果・実行者とともに保存することもできます。
何に使ってるの？
LobiではRundeckをデプロイ操作の実行に利用しています。 以前記事にしたとおりデプロイにはstretcherを使用しているのですが、 stretcherを起動するためには先の記事に課題として書いているとおり、
- デプロイサーバーにsshログイン
- S3にtarballとmanifestをアップロード
- consul eventを発火
という操作を行わなければなりませんでした。 もちろん各処理はスクリプト化され毎回定形の操作を行えばいいようにはなっていたのですが、 本番環境に日常的にsshログインするという状況にはリスクがあります。 特にLobiの開発チームの場合サーバーサイドエンジニアであれば誰でもデプロイしてよいということになっているため、 その回数は多いときで日に十数回に上ります。 デプロイ回数とデプロイできるメンバーを限定するという選択もありますが、 結局sshログインして操作するのでは操作ミスによる事故発生を防ぐことはできません。
これらの問題を解決するためRundeckが導入されました。
RundeckにはWeb UIが用意されているためsshログインする必要はありません。 もともとはデプロイできるのはサーバーサイドエンジニアだけでしたが、 いまではHTML・JavaScriptを担当するフロントエンドエンジニアもデプロイできるようになりました。 (もちろんテスト環境で充分にテストした上で、です。これはサーバーサイドエンジニアも変わりません)
また、デプロイ以外にもイレギュラーなサーバー追加操作なども Rundeckのジョブとして登録して定形化し操作記録が残るようにしています。
Tips
Rundeckにログインするためのアカウント
RundeckはPAMに対応しているため Rundeckが動作しているホストにアカウントがあり、 設定ファイルにログイン可能アカウントとしてリストアップされていればRundeckにログインすることができます。 サーバーサイドエンジニアは元々アカウントを持っているため新規にアカウントを管理する必要はありませんでした。 フロントエンドエンジニアもsshアカウントが必要ということになりますが、 こちらもテスト環境等にsshログインするために権限を絞ったアカウントが存在していたため、 余計なアカウント管理の手間はかかっていません。
Googleカレンダーにデプロイ履歴を記録
Rundeckでジョブを実行するとRundeck上に記録が残ります。 が、時系列順にリスト表示されるだけなのでいまひとつ視認性に欠けます。 Lobiではジョブ実行時にGoogleカレンダーに予定を追加することで いつ誰が何をデプロイしたのかが視覚的に把握しやすくしています。
件名には作業者の名前とデプロイの内容を、 予定の開始時刻と終了時刻にはデプロイのためのジョブ実行開始・終了時刻をそれぞれ設定しています。
Googleカレンダーへの予定追加はgocalを使用しています。
https://github.com/takyoshi/gocal
内製ツールではありますがプロジェクトに特化したものではないので一般公開しています。 Go製でバイナリファイルと設定ファイルを配置すればコマンドラインからGoogleカレンダーの予定を記録・一覧できます。 カレンダーの処理を手軽に自動化したい場合にご利用下さい。
デプロイの頻度
先のGoogleカレンダーのスクリーンショットを見てもらえば分かる通り、Lobiではデプロイの回数が非常に多いです。 変更は少しずつ本番に反映するべき、という方針に沿った結果です。 少しずつ変更を加えていけば不具合があった場合の原因追求が用意になりますし、 影響範囲が少なければデプロイ後の動作確認も確実に行なえます。
定期実行処理
Rundeckには定期的にジョブを実行する機能もありますが、Lobiではこの機能は利用していません。 定期実行処理については既にcrontabで管理されているためです。 Rundeckに移行することもできますが、その場合RundeckがSPOFになってしまうため充分な検討と対策が必要です。
おわり
次回はLobiチームのコードレビュー体制について紹介します。
