夏の Speee、内定者アルバイト (インターン) の振り返り

エンジニア インターンシップ

Speee 17卒内定者のやまどりです。夏休みを利用して 1 ヶ月間 Speee でアルバイトしました。入社までの期間を使って実務環境で鍛えさせてくれるとは粋です。

www.speee.jp

やったこと

  • リスティング広告のクローラを作った
    • 自社広告順位や競合広告の分析のために使用される
  • メンテナがいない既存の Java + Akka 製のクローラを Ruby でリプレイス
  • 4 つの出稿媒体に対して設定した数千個のキーワードを一日一回検索にかける
  • 夜 9 時にクロールを開始して朝 6 時までに終えるようにしたい

チーム

  • メインの開発は自分 1 人
  • レビュワーエンジニア 3 人
  • ディレクター 1 人

2 人のエンジニアの方に細かくツッコミ (レビュー) を入れてもらいながら開発していました。主な要件は既存ツールと同じだったため、ディレクターの方と関わることは少なかったものの、仕様や目的について不明点があれば随時聞きに行っていました。

技術選定

紆余曲折あったものの最終的に以下でまとまりました。

振り返り

Good / Keep

  • 既存のクローラでクロールできていなかったところが、正しくクロールできるようになった
  • DB 設計に工数を割くこと
  • Faraday

Problem

  • 思ったより本番環境のメモリ容量が小さく、アルバイト期間終了までに指定のハードウェアでクローラが動かなかった

Try

  • 本番環境の要件を事前に調べる
  • 技術選定時にプロファイラを使う
  • リプレイス案件のときは KPI を設定して、既存のツールからの改善具合を計る

詳しく

[Good / Keep] DB 設計に工数を割くこと

https://gyazo.com/3645df4f7e564a485b2272ab1c4006dd

1 ヶ月間のうち 8 営業日を DB 設計に費やしました。きっちり議論した甲斐があり、その後は設計を修正せずとも開発を進められました。DB 設計がアプリケーションの地盤を固めてくれるということを実感しました。

早くコード書き始めたいのに 1 ヶ月のうち 1 週間も issue で議論し続けていて、開発が進まない (ように見えた) ので本当に大丈夫か? という焦りもありましたが、やっておいてよかった作業でした。おかげでその後は設計を修正せずとも開発を進められました。

設計 issue が完了し喜んでいる図

https://gyazo.com/306b5c526edadffbfcf66dba7d142084

[Good / Keep] Faraday

検索結果ページの取得・パースの実装に Faraday を使いました。また Faraday に切り替えるついで、コードを綺麗にリファクタリングしました。アルバイト期間終了 3 日前になって既存のコードを捨ててリファクタリングするのは勇気がいりましたが、綺麗なコードを残してから帰ることができたのは良かったと思います。

プルリクコメントでこう言ってもらえたのが嬉しかったです。

https://gyazo.com/588446ee220867c6bf4e7c4df02cb81f

Faraday は、リクエスト・レスポンスの間にミドルウェアを差し込み、それぞれの処理をフックできます。これを利用して、広告をパースして結果 (Hash) をレスポンスボディとして書き換えるミドルウェアを作りました。ミドルウェアによって、「リクエスト→レスポンス→HTMLパース→広告データ」の変換処理を綺麗にワンストップで実装できました。

また、Faraday は HTTP クライアントのバックエンドに共通のインタフェースを持っていて、アダプタとしてバックエンドを差し替えることが出来ます。なので、例えば「Net::HTTP じゃパフォーマンスでないから Typhoues に乗り換えたい」となったとき、リクエスト・レスポンス周りをほとんど書き換えることなく、別のバックエンドに乗り換えることができます。今回は、本番環境のメモリが少なかったので、必要に応じてバックエンドを切り替えてチューニングできる Faraday を選びました。

github.com

[Problem] 思ったより本番環境のメモリ容量が小さく、アルバイト期間終了までに指定のハードウェアでクローラが動かなかった

社内ツールなので僕の手を離れたあとも開発が続けられるわけですが、これが今回のアルバイトで一番の心残りです。

メモリ使用量を削減するために、Capybara → Mechanize → Faraday + Nokogiri と何度も技術選定を変えており、そのたびに発生するコードの書き直しやプロファイルに時間がかかりました。

[Try] 本番環境の要件を事前に調べる、技術選定時にプロファイラを使う

確証もないのにちゃんと動くと思い込んで、本番環境を考慮した技術選定を行わなかったのが原因だと思います。本番環境のメモリ容量を事前に調べ、それを基準に技術選定をしていれば技術選定にここまで右往左往することはなかった気がします。

[Try] リプレイス案件のときは KPI を設定して、既存のツールからの改善具合を計る

今回は、リプレイスにあたって具体的な目標値を設定出来ていませんでした。クロールの速度やメモリ消費量などの目標を設定できていれば、それを考慮に入れた早めの施策を実行できただろうし、単なるリプレイス以上の価値を出すことができたように思います。目標を設定していれば、例えば「既存クローラの性能がxxで、新しいクローラの性能がyyだから 2 倍の高速化を実現した」ということを言えたのになと。

まとめ

学んだこと

  • DB 設計に工数をかけしっかり固めることで、後の開発がスムーズになる
  • 本番環境を考慮に入れて技術選定をすること、確証なく動くだろうと思わないこと
  • レビューは励みになる
  • Faraday

感想

初めてやることが多く、とてもワクワクする開発で、多くの経験値を増やすことができました。処理時間短縮のために Sidekiq で並列にクロール処理させたり、検索エンジンに負荷をかけないようにリクエストを投げたり、DB 設計に一週間かけたり… とどれも初めての経験でした。開発中は細かくレビューを頂くことができ、経験値不足の自分にとって大変有益でした。レビューがあったからここまで何とかやってこれたと思うし、思う存分暴れ自走させてもらうことができて楽しかったです。

Speee の方々へ: 1 ヶ月間ありがとうございました。入社後またよろしくお願いします!

あとは研究だ。