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