クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

ActiveRecord のパフォーマンス改善に関するgemを作った話

こんにちは。クラウドワークスの八木です。

今回は、ActiveRecord のパフォーマンス改善に関する gem を作ったので、それについて紹介したいと思います。先にオチを書いちゃいますが、この Gem を入れるだけで必ずパフォーマンスよくなるとか、そこまでのものではありません(仮に、そんな銀の弾丸があれば、 Rails 本体にリクエストを出すべきですし....)。特定のケースにおいて改善が期待される、というタイプのものです。

どんなgem

ActiveRecordのpreloadを使う際、アプリケーションの仕様上不必要なSQLのクエリの発行を避けることができるようになる active_record_association_query_economizer という gemです。

github.com

例をあげて説明します。

続きを読む

expect(suusan2go.engineer?).to eq ....

クラウドワークスに入社して2年と半年くらいたった suusan2go です。 そして今月で退職します。「退職エントリーまだー?」とCIOから言われまして、ブログを書くことにしました(正直書きたくなかったw)。

最近は退職エントリーに対する風当たりが強い気がしていて、自分のブログなら「個人の日記やぞ!」と強気になれますが、会社の公式ブログに書くとなると「個人の日記レベル」ともいってられないわけで…結構書くことを躊躇していました。

でも、退職エントリーをみて入社する人もいる*1 ということで、最後の恩返しのつもりで頑張って書きます。お前だれだよって感じだと思いますが、お付き合いください。

クラウドワークスでの思い出

前職では某メーカーのSEとして働いていました。あるあるですが、コードを書いたり設計をしたりする時間よりも、発注管理や他部署との調整などエクセルとにらめっこしてる時間の方が多いという状況でした。でもどうしても自分は手を動かすことがしたくて、業務改善のアプリをRailsで書いてみたり、趣味でサイト制作やってみたりと色々もがいているときに、オファーが出たのがクラウドワークスです。

でもはっきりいって、入社した当時の自分はWEBエンジニアとはいえない、結構微妙なラインだったんじゃないかと思います…(よく採用してくれたなーと思うし、当時の自分は今だったら採用してもらえなさそう)

入社直後、最初のプルリクは数行の簡単なメソッドを1つ足すっていう些細なものだったんですが、自分としては割と感慨深いものがあったので今でも覚えています。自分やっていけるのかなー大丈夫かなーという不安もありつつ、CIが通ることを確認するとか、Rubyらしいコードを議論するとか、ちゃんと開発できてる感が凄く嬉しかった。

その後3ヶ月ほど crowdworks.jp に携わったあと、詳細は割愛しますが新規サイト・サービスの立ち上げに関わり、直近の半年はもう一度 crowdworks.jp の開発に戻って、創業時からのレガシーなコードと戦いつつ、決済回りに手を入れるというアグレッシブな経験を積み、現在にいたります。

クラウドワークスに入社してよかったところ

仕事

とにかくいろんな仕事を任せてもらえました。特に立ち上げ系の仕事を複数経験させてもらえたのは、自分の大きな経験値になりました。少人数のチームでこんな感じのことを一から経験できたのは本当に大きかったです。

  • ビジネス要件をもとに、アプリケーション全体の設計を考える
  • ビジネスチームも含めて開発のプロセスを改善していく
  • アプリケーションだけでなく、エラーモニタリング・ログ、バッチなど含めて運用を考える

社内では、設計や技術に関する勉強会や読書会も盛んでした。入社当初は、「Ruby / Rails Way を意識してコードを書く」というところで精一杯だったのが、最近ではDDDを勉強してみたり、他の言語・フレームワークを触ってみるなどして、設計や実装の幅が広がってきた感覚があります。これも、一緒にDDD本を読んだりする同僚がいたからかなと思います。

また、やりたいと言ったことをやらせてくれる風土がクラウドワークスのエンジニアチームにはあります(もちろん、技術的に・ユーザーに価値があれば…ですけど)。読書会や勉強会以外にも、フロントエンドの改善部があったり、Docker部があったり、ChatOps部があったり、そういった部活動からプロダクションのコードやインフラ、運用が大きく改善されたことも数多くあります。ちなみに自分はフロントエンドの改善部に入っていて、アセットのCDN化や肥大化したJSの分割を進めたりしていました。*2

働く環境

クラウドワークスでは週3日までのリモートワーク制度とフレックス制度があります。特にリモートワークの制度は子供が生まれてすぐのときは、本当に有り難かったです。休憩時間を使って仕事の合間に子供をお風呂にいれることができたり、家族揃ってご飯が食べられるというのはとても良いものです*3。 基本的にはリモートワークは週3日までですが、どうしても事情により家を離れられない人はフルリモートで働いていたりしますし、逆にオフィスで働きたい人は普通にオフィスで働いていたりと、かなり柔軟な働き方ができるようになっています。

また副業が認められているので、エンジニアでも何人かはプライベートで別の会社の開発に携わっていたりします。私も一時期やっていましたが、会社では使っていない技術に触れることができたりして、なかなか新鮮でした。

最近ではリモート・副業といった働き方は世間一般にも大分浸透してきた気がしますが、このような働き方ができる会社は実際には意外とまだまだ少ないというのが実態なんじゃないでしょうか。

なんで退職するの

なかなか単純にこれだよ!って説明できなんですが、大きくは2つです。*4

  • 子供が生まれて、自分の人生設計に変化があった
  • 今のクラウドワークスでは積めない経験を積みたくなった

後者は、自分の技術的な幅を広げていきたいという気持ちになったっていうのも含まれています(もちろん、英語とかそれ以外もある)。ただ最近のクラウドワークスは、Ruby / Railsだけの会社ではなくなってきていて、その点はこのタイミングで辞めることに勿体無さを少し感じていたり。

例えば、新規の機能やサービスはScala x DDDで作っていくという方針になり、現在エンジニアの半分くらいはScalaをやっていたりします。gRPCでマイクロサービスや、本格的に機械学習を使った機能開発も始まっていて、技術的に凄く面白そうなことをみんな始めています(既存のコードベースを捨てるわけではないし、これからもRubyRailsは普通に使っていくよ!)。

この辺の技術的な話は、CTOがそのうちブログで詳しく書くって言ってたのでご期待下さい!

最後に

クラウドワークスに入社して2年半たちますが、今は流石に自分のことをエンジニアと言ってもいいよね?!って気持ちになっています。こう思えるような環境とチャンスをくれた会社と会社の偉い方々には本当にありがとうございますと伝えたいです。実績も実力も足りていない中で、可能性に期待してもらい仕事を任せてもらえたから、今があるなーと。

また一緒に働いたエンジニア・デザイナーの皆さん、2年半めっちゃ楽しく仕事ができたのは皆さんのおかげです。遠くに引っ越したりするわけでもないので、また飲みに行きましょう!

www.wantedly.com

*1:http://engineer.crowdworks.jp/entry/2017/08/29/124055

*2:自分がめっちゃ進めたみたいな書き方になっちゃいましたが、自分の貢献はほんの少しですw

*3:このあたりの休憩時間などの勤怠もリモートだからこそしっかり記録していました

*4:詳しく知りたい人はTwitterとかでDMください

Process Improvement with AAR x SMART Goals x Mob Programming

こんにちは、最近プロダクトオーナーにジョブチェンジしてコードを書く機会が減ってきたyo-iidaです。

クラウドワークスでは、開発チームをプロダクトオーナーと数人のエンジニアで構成し、スクラムをベースにしつつ細かいプロセスは各チームでカスタマイズしながら開発を進めています。

今回はそのカスタマイズの事例の1つとして、困難な目標や高い目標を追うため、既存の開発スタイルにとらわれないプロセス改善にチャレンジした話をお送りします。

目次

プロセス改善で新しく試したプラクティス

今回チームで新しく試したプラクティスは、

  • AAR
  • SMART Goals
  • Mob Programming

の3つです。

AARとは

「AAR」とは「After Action Review」の略称で簡単に言うとふりかえりのフォーマットです。やることは次の4つです。

  1. われわれは何をやろうとしたのか?
  2. 実際に行動しようとした結果、どんなことが起きたのか?
  3. なぜそうなったのか?
  4. この失敗を踏まえ、次に何をするべきか?

これをミーティングが終わった後や、その日の開発が終わった後にチームメンバーで話し合います。

ポイントはできるだけ事実を多く書き出すことと、それを解決するアクションがその課題を解決できるアクションになっているかにフォーカスして考えることです。あいまいさが入り込みにくいフォーマットなのでしっかりやるとかなり疲れますが、従来やっていたKPTに比べて少ない準備と短い時間で実施でき具体的な改善案が出やすいメリットがあると考えています。

qiita.com

SMART Goalsとは

「SMART Goals」とは達成できる可能性が高い目標を立てるためのフォーマットです。

SMARTはそれぞれ以下の頭文字となっています。

  • Specific(明確で)
  • Measurable(計測可能で)
  • Attainable(達成可能で)
  • Relevant(適切で)
  • Time-bound (期限がある)

前述のAARと組み合わせて次のアクションを決めるときにこの観点を満たしているかチェックすることで質の高いアクションを設定することができます。

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き

 

Mob Programmingとは

「Mob Programming(略してモブプロ)」とは、複数人で一つの開発をすすめる手法で、一人がドライバーとなりコードを書き、その他はナビゲーターとしてドライバーをサポートします。これを一定の間隔でローテーションし、開発をすすめていきます。

モブプロは、メンバー全員が一つのことに集中して開発を進めるためプルリクエストによるレビューが不要になり手戻りがなくなることや、メンバーのスキルや知見を共有しながら進められることが大きなメリットです。
そしてなによりやっていて楽しさを実感できる開発の進め方です。

www.infoq.com

現状クラウドワークスでは複数のチームで実践しており、徐々に広がってきている状況です。

ちなみに本記事の執筆もモブで進めています。

プロセス改善の歴史

次に、AAR、SMART Goals、モブプロという3つのプラクティスを実際に普段の開発で運用した時に、どんな課題があり、それをどのように解決してきたかを時系列で振り返ってみたいと思います。

モブプロ導入期

課題: チームメンバーの知識がばらばらでチーム感がない
解決: モブプロで知識のフラット化

当初、我々のチームは組織改編により2チームが合流しお互いの知識や経験がバラバラの状態から始まりました。 一方のチームはペアプロを日常的に行なっているチームで、もう一方のチームは各個人が個別に開発を進めお互いにレビューし合う進め方をしていました。

今後新しいチームでの開発をどう進めていくか検討していく中で、一番最初はペアプロを採用する話がありましたが、全員の知識や経験をフラットにできるモブプロが良さそうと判断して、試験的に採用することにしました。 世間的にもアジャイル開発手法の中にモブプロの話が浮上していたことも、後押ししました。

f:id:yo-iida:20171016095714p:plain:w600
ある日のオフィスでのモブプロ

f:id:yo-iida:20171016095750p:plain:w600
7/24のテレワーク・デイではコーワキングスペースを借りてモブプロをしました。

バーンダウンできない期

課題: 実装中に手戻りが発生してバーンダウンしない
解決: 実装前に技術的なリスクを細かく洗い出し、日々振り返ることで改善フィードバックを生む

クラウドワークスでは基本の開発スタイルはスクラムでスプリント単位で開発しています。 開発のメトリクスとしてはバーンダウンチャートを採用していましたが、モブプロにする前からなかなかフルバーンダウンできないという課題は抱えており、モブプロにしても特に大きな改善傾向はなく、バーンダウンの乖離が大きいスプリントが増えてしまうという課題に直面していました。

原因を考えた所、

  1. プランニングで技術的課題が全然見えておらず、実装時に手戻りが発生ケースが多い
  2. バーンダウンしていなくてもそれを開発プロセスの改善にフィードバックできていない

という原因があることがわかってきました。 モブプロでは実装に入ってからの細かい設計などはみんなで考えることができるので確かに手戻りは少ないですが、実装に入る前に見抜けていなかった技術的課題はモブプロではどうすることもできず、当初見積もりをオーバーして作業が発生することが多々ありました。

これを解決するために、

  • プランニングで施策に関連するコードをフロントエンドからバックエンドまで追いながらタスクを洗い出し、1デプロイごとにバーンダウンチャートを作りデプロイ日をカレンダーに登録する
  • 夕会でバーンダウンチャートを確認し、遅れている場合はバーンダウンさせるためのSMARTなアクションを夕会が終わるまでに決める

というアクションを出しました。

「1デプロイごとにバーンダウンチャートを作りデプロイ日をカレンダーに登録する」というのは一見やりすぎのように見えますが、一度コストがかかっても細部までしっかり把握しにいきどれだけ見積もり精度をあげられるのかを試すという方針をとりました。

プランニングボリュームアップ期

課題: 技術的なリスクの見積もりに時間がかかる
解決: 空のテストやインターフェースを先に定義しタスクを網羅的にコメントで残す

もともとプランニングではストーリーごとにプランニングポーカーでポイント見積もりをしていました。

前述のアクションを反映した結果、ポイント見積もりをやめて、プランニングでコードを追いながらタスクの洗い出し、デプロイ日を設定するようにしました。

タスクをコメントで実際のコードに残していき、必要な箇所にはクラスやインターフェースを書いていく方針にしていました。

しかし、精度を上げようとするあまり、プランニングに掛ける時間が増大し、ひどいときは、「ここまで書いたらもう実装もかけるでしょ」という勢いでプランニングが終わったら実装がほぼ終わっているということもありました…。

これでは何をやっているのかわからない、、ということで、落とし所として、チーム独自のTODOコメントを用意し、プランニング時にブランチを切ったのち、実装が必要な箇所にTODOコメントを残し、それをコミットするまでをプランニングとしました。この作業もモブプロで行い、全員の認識を一致させます。このときにホワイトボードにも全体像を書いていき、リリースまで残しておくようにしました。

その結果、実装に入ってからはそのTODOをすべて潰せばリリースできるという状態を作ることができました。

夕会地獄期

課題: 日々のふりかえりが機能していない
解決: AARとSMART Goalsでその日のうちに具体的で明確なアクションを起こす

これまで夕会はバーンダウンチャートと残タスクを確認し、共有事項や翌日の予定の確認を行う内容となっていました。
バーンダウンチャートを確認といいつつ、見るだけで終わっていたので遅れている場合のアクションが何も出ない状態でした。

これを前述のアクションを反映するために、AARというふりかえりフォーマットで1日をふりかえることにしました。ふりかえりといえばスプリントの終わりにKPTなどでふりかえることが多いと思いますが、1日単位で記憶がフレッシュなうちに具体的なアクションが出るやり方に変えました。

その結果、1日の開発内容や課題点をすべてふりかえったためそれまで5分で終わっていた夕会が1時間かかるようになりました。
これもやりすぎ感がありますしタイムボックスを守っていないのですが、対応があいまいになっている課題を完全に消化しにいくという方針で試してみた形です。
初期段階は課題が非常に多かったので時間もかなりかかることがありましたが、回数をこなすにつれてあいまいになっていた大きな課題は徐々に解消され、コンパクトに終わるようになりました。

AARで出た改善アクションで事前に検討しておいたほうがよいものはプランニングチートシートに反映するなど、継続的な改善が機能するようになりました。

AAR祭り期

課題: なんでもAARで時間がとられる
解決: 改善点はチートシートに落とし込み

AARのふりかえりフォーマットに慣れてくると、今度はチームのミーティングが終わった後にはなんでもかんでもAARをやる癖がついてしまい、

「我々は何をやろうとしたのか?」
「どうしてそうなったのか?」

ということを常にチームメンバーが意識するようになりました。

しかし、AARはそれなりに時間がとられるので主要なミーティングではすべてチートシートを用意することで同じAARを繰り返さないようにしました。

プランニングでは技術的な観点でタスクを洗い出しますが、実装に入ってから施策のKPIの測定方法が明確に定まっていないことが発覚するといった問題が起きたこともあり、プランニングの前にプレ・プランニングを行い施策のあいまいなところを洗い出すチートシートなどもできました。

こういった取り組みの結果ミーティングの質が大幅に向上しました。

ミーティングダイエット期

課題: ミーティングにかける時間が長い
解決: 改善が定着したミーティングは時間の削減

ミーティングの質は改善してきましたがまだ掛けている時間が長いということで、改善サイクルが定着したミーティングを減らす検討を行いました。

プランニングやグルーミングはチートシートの充実によりフィードバック自体が少なくなったので、それらのミーティングごとにAARを行うことはなくなりました。
また、夕会後のAARでは、一度にその日の開発内容をたくさんふりかえるのが大変だったため、開発の区切りがついたタイミングで都度ふりかえるようにしました。
そうすると記憶が新鮮な状態で改善アクションがだせるのでAARの質も上がり、開発の進め方がさらに改善されました。

開発チームとプロダクトオーナーのコミュニケーション改善期

課題: ミーティングごとのコンテキストスイッチつらい
解決: チームは一つのことに集中し別の話題のミーティングをいれない

開発チームとしてはミーティングに掛ける時間は減り、開発に集中できるようになりましたが、ここで新たな問題に気が付きました。

開発中にプロダクトオーナーから次の施策のミーティングを挟み込むと、集中している分コンテキストスイッチの負担が大きいことがわかってきました。

この問題に対しては、思い切って開発チームには今やっている開発に集中してもらい、終盤になるまで次の施策について開発チームとの検討を進めることはしないようにしました。

いいかんじに施策リリースできるようになった期

ここまでの改善を経て、一度にやる開発は1施策という単位に変えたため、スプリントやバーンダウンチャートという概念もなくすことにしました。

もともとスクラムの見積もりというのは、プロダクトバックログのユーザーストーリーに対して相対的なポイントを見積もることでそのスプリントで実施する対象を決める というやり方です。しかし、我々の場合プロダクトバックログにいくつもストーリーが積んであるわけではなく、都度都度実施する施策をユーザーの反応をみて練りながら進めるスタイルだったので、 その施策がいつリリースできてどれくらいの数字の伸びを見込んでいるかの精度を高める ことが重要でした。

そのため、プロダクトオーナーとして施策がいかに詰められているかを追求することと、開発チームとしていかに技術的リスクを排除して手戻りを少なくすることに注力した結果、「教科書通りの進め方から外れてみる」という選択をしました。
安易に自分たちのやり方で進めるのにはリスクがありますが、ふりかえりが機能していたので失敗で終わってしまうことはありませんでした。

結果的に、以前のような技術的課題の見落としによる手戻りに悩まされることがなくなり、自分たちの改善によって施策が予定通りリリースできるようになり、施策としても効果が見え始めたのでチーム全体としてパフォーマンスが上がっている手応えを感じることができました。

まとめ

長々とプロセス改善でやってきたことを振り返ってみましたが、何が一番重要だったのか一言でいえば、

「ふりかえりを機能させること」

に尽きると思います。

初歩的なことに聞こえますが、質の高いふりかえりを実現するのは気力と胆力を伴う作業であり、継続してしっかりふりかえっていくことは非常に難しいことだと改めて思います。

今回モブプロという新しい手法を試しましたが、これを上手く定着させることができたのは短いサイクルでのふりかえりをきちんと実施できたことが大きいです。 ふりかえりの重要性はモブプロに限らず通常のスクラム開発でも同じなので、個人的にはこれまでやっていた開発もわりといい加減だったんだなぁという反省がありました。

ということでモブプロを導入する過程と、その中で気づいたふりかえりの重要性について気付かされたというお話でした。

改善プラクティス集

最後にモブプロやAAR等を効率よく実施するために役に立ったプラクティスを紹介します。

全体の流れ

f:id:yo-iida:20171023104313p:plain:w600

プレ・プランニング

施策内容をチームに共有し以下の点をチェックします。

- [ ] その施策、目的と手段合ってる?
- [ ] 受け入れ基準を明確にする(絶対実装するライン、プランニング結果や実装途中でやらない判断ができるライン)
- [ ] KPIの計測方法が明確になっている
- [ ] 技術検証が必要か?(パフォーマンス懸念、新技術利用、構造的なリファクタリングなど)
- [ ] UIデザインをレビューは必要か?
- [ ] ユビキタス言語を決める(日本語)
- [ ] そのストーリー、見積り可能になってる?
- [ ] プランニング前までにやっておくことのSMARTなアクションを決める(必要か?で必要なとき)
  - [ ] 検証で明らかにするべきことをリスト化し各検証にかける時間を決めてカレンダー登録する

プランニング

モブプロで以下の点をチェックします。(カードと呼んでいるものはTrelloのカードです)

- [ ] カードのタイトルに関連する施策がわかるユビキタス言語を含める (2分)
- [ ] 少なくとも「モデル / UI / ユーザー導線」の3フェーズにリリースをわけている (それぞれdevelopブランチから派生可能であること) (15分)
- [ ] 大まかな流れ、関連するモデルをホワイトボードに書いて全体像を見えるようにする(15分)
- [ ] Pull Requestを作ってカードにアタッチする (1分)
- [ ] プランニング時に確認した項目があればQiita:Teamに記録する
- [ ] 実装すべきインターフェース(クラス・メソッド)のYARDと実装の補助となるチーム名_TODOコメントを記載する (コードの追加・削除をしない) / 併せて RSpecの1行contextと空のitを書いておく 。テストがない場合、空ファイルを必ず作る。 (1時間15分)
- [ ] Elasticsearchのフィールド追加を伴う場合はそのフィールドへの同期がいつ行われるかを確認する
- [ ] チーム名_TODO をもとに全体の流れがあってるか図を使って確認(10分)
- [ ] 施策をやる前にリファクタが必要か(リファクタは別ぷるりにする)
- [ ] チーム名_TODOのコミットをまとめる
- [ ] チーム名_TODOをTrelloへタスク化する git grep --line-number チーム名_TODO | pbcopy (15分)

HackMD

リアルタイム共同編集できるMarkdownノート

モブプロでその日の開発内容をナビゲーターが記録していくという使い方をしています。朝会アジェンダなどもここに記載していて、1日が終わるとQiita:Teamのほうに転記してチーム開発日報として残しています。

f:id:yo-iida:20171016102442p:plain:w600
AARの記録。楽しく開発するには遊び心も大事。

キッチンタイマー

モブプロ関連の記事ではMobsterがオススメされていることが多いですが、我々は物理的なキッチンタイマーを使っています。 Mobsterは一つのマシンを使い回す前提のツールになっていますが、我々の場合はマシンは各自のマシンを使い、ディスプレイだけつなぎ変えるやり方にしているためキッチンタイマーが使いやすいです。

git-now

モブプロやペアプロでは交代の際にcommit & pushが必要になるため、開発がある程度まとまるまではgit-nowを使って即座に交代ができるようにしています。

ひと段落したところでgit nowで積んだコミットをrebase等でまとめる方針としています。

参考: Git nowではじめるCommit駆動開発 - Qiita

割り込みタスクで離脱

開発をしているとアラートが飛んだり、サポートから問い合わせがあったりどうしても開発を中断して対応しないといけない割り込みタスクが発生します。

このような場合でも開発をストップさせないために、依頼がきた場合はその場でランダムでモブプロから抜けて対応する人を決め、最低限ペアプロで開発を進められる状態を保つということをしていました。

※割り込みタスク自体もモブプロでやるという選択肢もありますが、事業観点では開発を止めないことを優先しています。

ホワイトボード

ディスプレイの後ろにホワイトボードを用意して開発中は開発しているものの全体像を可視化するようにしています。

これをやることで実装で迷わなくなり、議論の効率化もできます。

f:id:yo-iida:20171016102507p:plain:w400
太陽フレアが話題になったときに生まれた謎キャラクター。楽しく開発するには(ry

最後に

クラウドソーシングのクラウドワークス では、モブプロなど新しいプロセス改善に積極的にチャレンジできるエンジニアを募集しています。

www.wantedly.com

定期的にSQLを実行した結果をDatadogに送信するcyqldogというツールを作った

日々Datadogのダッシュボードを眺めながらニヤニヤしている @minamijoyo です。

定期的にSQLを実行した結果をDatadog送信するcyqldogというツールを作ったので紹介します。

f:id:minamijoyo:20171002184919p:plain

はじめに

クラウドワークスでは日々のデータ分析にAWSRedshiftを利用しています。 Redshiftはサービスの主要なKPI集計から、ちょっとしたアドホックな分析まで、 利用者はエンジニアだけにとどまらず、プロダクトオーナーやマーケティングのメンバーも含め広く利用されており、 ひとたびシステム障害などでRedshiftが利用できないと業務に大きな影響が出ます。

そんなRedshiftを安定稼働させるためには、日々の監視が大切です。 AWSで監視といえば、まずはCloudWatchが思い浮かびますが、RedshiftのCPU使用率やディスク使用率などの基本的なメトリクスであれば取得できるもの、 ちょっと複雑なこと、例えばユーザごとのクエリ実行時間やキューの滞留数などを取得しようとすると、Redshiftのシステムビューにクエリを投げる必要があります。

クラウドワークスではインフラレイヤの監視ツールとしてDatadogを使っているので、 Redshiftのシステムビューに定期的にクエリを投げて、Datadogにメトリクスを投げつけられると幸せになれそうだなぁと思ったのがこのツールを作り始めたきっかけです。

ちなみにDatadogの公式インテグレーションにRedshiftがありますが、これはCloudWatchのRedshift関連のメトリクスを取得できるもので、システムビューまでは見てくれません。

また、RedshiftのSQLのインターフェースはPostgreSQL風なので、DatadogのPostgreSQLインテグレーションが使えそうな気がしましたが、RedshiftのシステムビューはPostgreSQLとは異なるので、Redshiftのメトリクスを取得するのにはそのままでは使えなさそうでした。

雑なシェルスクリプトを書いてもよかったのですが、監視対象のクエリが増える度にスクリプトをメンテするのやだなーというのと、 Redshiftにあんまり監視自体で負荷をかけないように、重いクエリと軽いクエリで監視間隔をコントロールしたいなぁと思って、 設定ファイルにSQLと監視間隔を書けばいいかんじにDatadogにメトリクスを送信してくれるcyqldogというツールを作ってみました。

github.com

元々Redshiftの監視のために作りましたが、データソースとしてはもう少し汎用的にPostgreSQLMySQLでも使えるようにしてあります。 実装は個人的な趣味でGo言語です。

というわけで、cyqldogの使い方を簡単に紹介します。本稿執筆時点のcyqldogのバージョンはv0.1.3です。最新情報については上記リポジトリのREADMEを参照して下さい。

続きを読む

KARTEを導入した結果、エンジニアがバナー設置しなくなった話

はじめまして、高校野球好き新卒エンジニアの太田(@yutoota)です。今年の夏の甲子園では、地方大会から応援していた埼玉の花咲徳栄高校が優勝して感極まりました。ちなみに母校でもなんでもありません。

唐突ですが、エンジニアの皆さんは新サービス・新機能のリリースの度にその流入を増やすことを目的とした施策(バナーの設置等)の実装を何度も行っていたりしませんか? クラウドワークスではこれらの施策の実装を主にエンジニアが行っています。軽微な変更であれば施策担当者(非エンジニア)が実装しますが、少なくともリリース作業はエンジニアが行う必要があります。

こういった実装は難易度としては低いものの、レビューやデプロイを伴うので一瞬で実装完了することができず、何度も積極的に変更できないことが悩みだったりします。非エンジニアにとっても、わざわざエンジニアに対応依頼する必要があり、「試してみたい細かな修正があるけど忙しそうだから後で依頼しよう・・・」といったケースも多いかと思います。

そんなクラウドワークスでは1ヶ月程前にKARTEという「Web接客ツール」を導入したことで、これらの問題を解決することができました。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.