RAKSUL TechBlog

ラクスルグループのエンジニアが技術トピックを発信するブログです

ラクスル全体の90％のデータチェックを基盤サービスで処理できるようにした話

こんにちは！ラクスル事業本部DTPスクラム所属の堀です。ラクスルには今年の3月に入社しました。

ラクスルではECの本体から入稿データチェックに関する機能を切り出してサービス分割を行っております。DTPスクラムチームでは主に データチェック基盤 に対する開発を行っています。

※データチェック：入稿データを印刷に適した形かチェックし、適した形式にすること

歴史あるプロダクトなのでどうしてもEC本体に残ってしまっているレガシーなコードが存在しています。段階的にサービスへ切り出していく過程のうち、今回はデータチェックの一部機能の移行を紹介します。 規模が大きくなったシステム改修の難しさと学びについて少しでも共有できればと思います。

最初のデータチェック基盤構想についての記事も参考にご覧ください。

背景

ラクスル本体は初期から存在するPHPのコードと新しいRubyのコードがあります。ラクスル本体に残っているPHPで書かれたレガシーな管理画面が「Admin」と呼ばれています。その巨大なコードの保守がつらい、いわゆる技術的負債になってしまっている側面があるので「Admin」を撲滅しよう、ということで、社内ではこの活動を「Admin撲滅」という名前で呼んでいます。

「Admin撲滅」のDTPパートとして、注文管理画面のDTPオペレーターによるデータチェックに関する機能をデータチェック基盤へ連携し、DTPオペレーターの関心事を切り出した話をご紹介します。

データチェック基盤とは

データチェック基盤はラクスルの基盤を作る大型プロジェクトの流れで作られました。現在、ラクスル本体のECやその他のECと接続し、ラクスルのデータチェックを担うサービスとなっています。

元々はラクスル本体のコードにモノリスな機能として存在していましたが、現在はサービス分割され、各サービスからのリクエストを受け付ける基盤となっています。

今回は本体に残ってしまっているオペレーターのチェックの管理機能を、オペレーションを見直しつつ、移行しました。

やったこと

Admin撲滅(DTPパート)前の世界

注文の管理画面を見てデータチェックのオペレーターはデータチェックに関する箇所を判断し、業務を行っていました。

Admin撲滅(DTPパート)後の世界

DTP業務を行うオペレーターはそのデータチェックに関する業務のみが表示される管理画面を利用することができるようになりました。注文情報はこれまで通りEC側の管理画面を利用します。

システム構成

データチェック基盤と各サービスとのやりとりにはRPCを利用しています。 下記は今回のプロジェクトでの連携方法を簡単な図として抜粋したものです。

全体から見ると管理画面に関連した一部のアーキテクチャであるという前提での話になってしまうのですが、 raksul.comのサーバーサイドは主にAdminで使われているSymfony(PHP)と現在コアとなっているRuby on Railsで構成されています。 また、Datacheck基盤のサーバサイドはRuby on Railsで構築されています。

データチェック基盤で定義したProtocol Buffersを元にしてTwirpにてクライアントを生成し、RPCによるServer to ServerのInternalなAPIでECとやり取りをしています。

今後のことも考えて、Server to ServerでのやりとりをPHPからでなく、新しいコードであるRubyからデータチェック基盤にリクエストしてほしかったため、ECのRuby on RailsへラッパーとなるAPI実装しました。現状はデータチェック関連だけ切り出したのでPHPからそのラッパーとなるAPIを叩いてデータチェック基盤とのやりとりをしています。

とはいえ、いずれ完全にレガシーコードがなくなるその日には、管理画面もこのアーキテクチャではなくなるでしょう。

結果どうなったか

  • 巨大なPHPのデータチェックに関するコードを保守しなくてよくなった
  • 商品情報の変更・追加などの保守がやりやすくなった
  • オペレーションの効率化がしやすくなった
    • データチェック基盤に分離されているため、DTPオペレーターのための機能拡張が可能に！
  • オペレーターのための画面がデータチェック基盤に集約され、UIも使いやすくなった
    • 例えばデータチェック待ちの一覧のソートと色分けにより、DTPオペレーターは画面の上から順番にチェックをやっていけばいい世界になった

データチェック基盤の管理画面（データチェック一覧サンプル）

当初はシステム的な拡張性・保守性の側面を目的としていたため、古い管理画面の機能をそのまま移植（いわゆるリプレース）しようとしていました。しかし進めていく中で、そのまま移行するよりそもそもオペレーションを整えてから移行した方が、移行の工数も少ないし、オペレーター的にも嬉しいという気付きがありました。

そのためオペレーションのフロー改善 + システム移行を一緒にやることでDX的な流れになりました。 一例を挙げると、DTPオペレーターが自分で判断する箇所をデータチェック領域に集中させるための工夫があります。どのデータをチェックするべきかオペレーター各自で判断するのではなく、パーソナルにフィルタリングされた一覧を上から順番に拾っていけば良いような状態をシステムで実現しました。

ただし、作り込みすぎないことは意識していて、開発時もそのバランスは常に気をつけていたと思います。

リリース時に気をつけたこと

  • データチェック基盤はラクスル本体以外にもダイレクトメールやポスティング、エンタープライズなど分割された各ECのサービスからリクエストを受け付けるため、既存影響、後方互換性の維持を意識しました。
  • 移行後のシステムに問題が発生するリスクを考慮して、旧管理画面でのデータチェックも行えるようにして進めました。リプレース案件とかだとよくやる手法だと思います。並行稼動ですね。
  • オペレーション業務と調整し、段階的に移行できるようデータチェックの流量を調整しました。
    • オペレーターが行うデータチェックも商品によって難しい・簡単や多い・少ないといった違いがあるので、影響が少ないものからリリースしていきました。

おわりに

サービスごとにチームが別れていると、越境した開発で難しい側面もありますので、チーム間での連携を意識して開発を進めました。私は入社して間もないのでこのプロジェクトに参加できたことで業務ドメインへの解像度が上がりました。

規模が大きくなっていくプロダクトと組織的課題はそれだけでブログの記事が何本か書けそうですね。

「Admin撲滅」もまだ完全移行できていなかったり、DTPパートだけしかできていなかったりと課題は残っているので引き続き改善していきます！ 課題があるからこそ面白みもありますよね。