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

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

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でマイクロサービスや、本格的に機械学習を使った機能開発も始まっていて、技術的に凄く面白そうなことをみんな始めています(既存のコードベースを捨てるわけではないし、これからもRubyやRailsは普通に使っていくよ!)。

この辺の技術的な話は、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とは
  • プロセス改善の歴史
    • モブプロ導入期
    • バーンダウンできない期
    • プランニングボリュームアップ期
    • 夕会地獄期
    • AAR祭り期
    • ミーティングダイエット期
    • 開発チームとプロダクトオーナーのコミュニケーション改善期
    • いいかんじに施策リリースできるようになった期
  • まとめ
  • 改善プラクティス集
    • 全体の流れ
      • プレ・プランニング
      • プランニング
    • HackMD
    • キッチンタイマー
    • git-now
    • 割り込みタスクで離脱
    • ホワイトボード
  • 最後に

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

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

  • AAR
  • SMART Goals
  • Mob Programming

の3つです。

続きを読む

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

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

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

f:id:minamijoyo:20171002184919p:plain

はじめに

クラウドワークスでは日々のデータ分析にAWSのRedshiftを利用しています。 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の監視のために作りましたが、データソースとしてはもう少し汎用的にPostgreSQLやMySQLでも使えるようにしてあります。 実装は個人的な趣味でGo言語です。

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

続きを読む

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

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

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

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

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

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.