こんにちは、エンジニアの泉田です。ラクスルでは先日8/30から9/3にかけてHack Weekを実施しました。Hack Weekはラクスルで開催している年1回、約1週間のハッカソンです。今年は4回目となり、日本、ベトナム、インドのオフィスのエンジニアから、サマーインターンの学生まで含めて、総勢約120名での過去最大人数での開催となりました。詳しくはこちらの記事 もご覧ください。
今回はインターン生中心のチームにレポートをまとめていただきましたので、そちらをシェアさせていただきます。Hack Week 1週間では、プロジェクト全体の一部のみでしたが、是非今後とも追加開発を進めていきたいと思っています！！
Hack Week レポート(ID基盤開発チーム)
全体の特徴
また、社内ハッカソンの形式なので、最終日の発表会で他のチームの発表（これも業務改善やDX改善, ビジネス案など）が見られて、社内の雰囲気も感じることができました。
オンラインインターン
今回のインターンはすべてオンラインで実施されました。 Slack、Google Meet、VS Code Live Share等のオンラインツールを活用し、オフライン開催と遜色ないインターンになったと思います。
開発の特徴
チームごとに開発の特徴は異なりますが、私たちのチームでは、6人(インターン4+メンター2)のチームが開発領域ごとに3人ずつのグループに分かれ、モブプロ・ペアプロでスピーディに開発を進めました。インターン生2人のペアプロにメンターが6時間近く密着して指導していただけたので、とても密度の高い1週間でした。
ハッカソンという形式ですが、実運用されているリポジトリに触れられて、既存のアプリケーションとの結合が経験できる点はとても貴重でした。そして、開発したアプリケーションもこの場限りのアプリケーションではなく、今後も使われるのが期待できるのが刺激的でした。
社員さんとの関わり
ハッカソンといえどインターンなので、会社の雰囲気やラクスルで実際に働いている社員さんのお話を聞く機会はインターン生としてもぜひ欲しいところです。しかし、今回はオンラインでの開催なので会社で直接お話を聞くことはできません。インターンの中盤に新卒の方とランチする時間(任意参加)を用意していただき、貴重なお話ができました。インターン生からのかなり直球な質問に対して、しっかりと回答いただけて会社についての解像度が上がりました。
今回実装したアプリケーションについて
背景
現在ラクスルは、最も長く運用しているメインの印刷ECサービスであるraksul.comの他、ノベルティ、ダイレクトメール、見積もりサービスなど毎年新しいサービスをリリースしながら、複数のECサイトを運用しています。raksul.comはECとしての機能開発を頻繁に行っている他、複数サービスを横断したラクスルユーザーとしての認証まわりも扱っています。
この一つ目の課題として、raksul.comでのEC機能のリリース等で何か障害がありサービスがダウンした時に、他のnovelty.raksul.comやestimate.raksul.comなどのユーザー認証もエラーとなり、使えなくなるリスクがあります。
また二つ目に、それぞれのECサイトの注文は各サイトのフォームにて管理をしているのですが、複数サイトを横断した同じラクスルアカウントの注文管理画面がないため、社内オペレータが、あるユーザーの注文情報を横断で調べる時に、手間がかかるという課題があります。
アプローチ
上記の課題を解決するため、アカウント情報（ユーザー情報とその注文情報）を管理できる、アカウント基盤を構築することにしました。そのまず第一歩として、このHack Weekの一週間では、ユーザー情報を Raksul のDBからAccount DBへ移行のための同期処理と、アカウント管理画面の実装を行いました。Accountのアプリケーション作成にはRuby on Rails、スキーマ定義には Protocol Buffers、同期にはApach Kafkaを使いました。移行期間中はRaksul DBからAccount DBへと、それぞれが並行で更新される状態になりますが、最終的にはAccount DBのみを直接更新することを想定しています。
アカウント管理画面は以下のようなイメージです。まだ未完成ですが同期したデータを確認できるところまで開発が終わりました。
開発を通しての学び
開発を通して知ったこと
- 開発は終始ペアプロで行いました。ペアプロはナビゲーターがドライバーのコーディング画面を見ながら指示する方式で、1人で手を止める時間が減る分、速度・密度が高くなります。ペアプロをやる前はn人分の1のスピードになるかと思っていましたが、予想以上に開発がスムーズに進み、追いつくので必死なくらい高速でした。また、一見ナビゲーターが手持ち無沙汰になりそうですが、実際にはドライバーより考えることが多く、ナビゲーターも多くの経験値を得られる内容でした。モブプロ・ペアプロの面白い点として、自分以外の人のコードの書き方を注意深く見るため、新しい気づきが多いところがとても新鮮でした。ただ、何よりペアプロは集中力を使うので、気づくと数時間熱中し続けてヘトヘトになっているということが初日はありました。そのため、ポモドーロテクニックを入れるなど、生産性を高める方法を工夫しながらやっていきました。
- メンバーによってgitの使い方が異なることが分かりました。一人はターミナルでgit、また一人はVS CodeのGUIでgit、VS Code内のターミナルでgit、tig ...と様々で、gitの活用方法を色々見ることができて楽しく、学びにもなりました。
技術的なこと
- メインの技術
- Ruby on Rails
- 現在Raksulのバックエンド開発メインのフレームワークです。
- Protocol Buffers
- schema定義用の記述形式。Raksulではよく複数アプリケーションのRPC型定義に利用しています。
- Kafka
- システム間のデータの受け渡し時に、データを一時的に保存する働きをする、メッセージキュー。
- Ruby on Rails
- スキーマ設計時の工夫
- DBのカラム名：既存のRaksul DBのユーザーテーブルは10年近くも前に定義されたものであり、意味を読み解くことが難しいカラム名もありました。今回のAccount DBは可能な限り理解しやすいカラム名にするなど工夫をしました。例: c_name を company_name, rtime を registered_at など
- 型の再定義：カラム名と同様、新Account DBではより管理しやすいようにテーブルやprotocol bufffersの型を定義しなおしたものも多々あります。Protoの定義は、Raksul DB から Account DBへこれらを受け取り側にとって扱いやすく、変更に強いデータの形式になるよう工夫しました。結果的に、string にすることが多かったです。
- TriggerとStored Procedureのmigrationファイルでの設定
- Raksul DB は二つのアプリケーション(PHPからRailsへとリビルド途中)から更新されているため、新Account DBへのユーザー情報の同期を漏れなく行えるようテーブルへの更新をトリガーに行えるように設計しました。
- Stored Procedureにより、Queueテーブルに更新対象のuser id を保存し、後続のデーモン Task で Kafka へとproduce します。既存データベースの制約により、Railsのmigrationでは素直に記載できない箇所はSQLでmigrationを書く必要がありました。また、これらの反映とロールバックを繰り返し行えるような記載など、考えることは多かったです。
- Kafka へのProduce のためのTaskの作成
- KafkaへのProduce には、ユーザーテーブルの更新に伴いトリガー経由で作成したデータ（Queueテーブル）を Rails のTaskから参照して行うように実装しました。
- 元のDBから、カラムの選定やデータの整形をする必要があり、自動でRailsのModelからProtoでの形式に変換するようにしました。
- テスト
- RSpec
- テストを書いた経験があるインターンメンバーは少なく、テスト項目の切り出しから苦労しました。
- テストコードが、テスト内容を説明する文章になるところは、理にかなっていて面白かったです。
- FactoryBot
- テスト用にあらかじめテスト用データを設定できるGem。複数ユーザーのテストデータをFakerと合わせて作成しました。
- Faker
- いい感じのテストデータの値をRandomに生成してくれるGem。
- RSpec
まとめ
メンターの方々がずっとmeetで見ていてくださったので、技術的にわからないところをすぐに聞ける雰囲気が形成されていたところがとても良かっです。感想として、最初の3日間でメンバーがそれぞれ蓄えた知識を4日目で爆発させて、5人全員でLiveShareでフォームやシードデータ作成など、爆速で同時に開発が進むところは壮観でした。また、最終日には全チームの様々な成果発表を見られたのも面白く、最後のオンライン懇親会含めてとても楽しむことができました。
