【Cacco Tech blog #2】～不正注文検知サービス「O-PLUX」の開発の歴史と今後～

こんにちは、かっこ株式会社（以下、かっこ）取締役CPOの岡田です。

前回はかっこのエンジニア組織について触れましたが、当社の最初のプロダクトである不正注文検知サービス「O-PLUX」の歴史を中心に技術領域の概要に触れていきたいと思います。

～不正注文検知サービス「O-PLUX」の歴史～

不正注文検知サービス「O-PLUX」の誕生

　O-PLUXは、当社売上の7割を占めるプロダクトですです。
かっこを創業した際に、最初から不正注文検知サービス「O-PLUX」の構想があったわけではありません。最初のプロダクトである不正注文検知サービス「O-PLUX」は、創業後に行ったECにおける不正対策のコンサルティング業務がきっかけで誕生しました。

　不正対策のコンサルティングを行う中で、EC事業者は不正対策のための運用負荷が高く、審査の仕組みをシステム化したらニーズがあるのではないか、というアイデアがあり、プロダクト化の計画進めました。また、そのタイミングで決済システムのコンサルティングを行っていたお客様に不正注文検知のシステムの提案をしたところ、提案が受け入れられたことから、O-PLUXの開発を進め、2012年6月にローンチ。
　O-PLUXの開発においては、当時のエンジニアはJava言語経験者が多かったことから、言語は自然の流れでJavaを採用し、また、少ないエンジニアチームでゼロから開発する必要があったため、インフラのことを気にする余裕がなく、クラウドサービス側に任せたいという考えから、Google App Engine（以下、GAE）を採用しました。

不正注文検知サービス「O-PLUX」の拡大と障壁

　O-PLUXのローンチから順調に利用企業や利用トランザクションが拡大していきましたが、2014年ごろから徐々に以下のような課題が顕在化してきました。

• 初期ローンチ時に突貫で作ったソースがスパゲッティ状態でメンテナンスがし難くなってきた
• トランザクションの拡大に伴って、GAEの利用料金の増加が目立ってきた
• GAEはインフラをGoogleに任せられるメリットが大きかったが、一方で自分たちでチューニング等ができる余地が少なかった
• O-PLUXで導入する審査ルールの設定の自由度が少なく、多岐に渡る不正への対策を行うことが難しくなってきた

　上記の課題に対応するには、O-PLUXのアプリケーションの作りを根本から変えることが必要と判断しました。それと同時に、社内のエンジニア体制も整ってきたこともあり、インフラもAWSに切り替えることに。
　2014年からAWS化の検討を開始したのですが、当時はまだサーバーレスアーキテクチャは主流では無く、EC2 + RDS（MySQL）の構成としました。

言語は引き続きJavaとし、バックエンドのフレームワークとしてPlay Frameworkを、フロントエンドはBackbone.jsを採用しました。

　データベースをMySQLとしたのは、O-PLUXのデータの特性として審査データの更新処理が多く発生するため、更新に強い仕組みとする必要があった為です。
また、データウェアハウスとして、Amazon Redshiftを採用。

　やはり、データが命とも言えるプロダクトであり、エンジニア以外のオペレーションチームのメンバーもRedshiftに頻繁にアクセスしてデータ抽出・分析を行える環境を提供しています。

　AWS化にあたっては、決して順調では無く、2015年10月にAWS版O-PLUXが完成したものの、以下のような課題・トラブルが絶え間なく続き、計画通りに進まず、会社としても大きな課題となっていました。

• 性能が想定よりも出ない
• GAE版O-PLUXでできていたルールが、AWS版で利用できない
• GAE版からのデータ移行に不備が散見された
• AWS化したがサーバーコストが大きく下がらない
• 上記のような課題にエンジニアが疲弊してしまう

　その後、一つ一つの課題に対して、根気よく対処していくことで、性能向上し、安定性も増し、順次GAE版からの移行を行うことができました。

　安定稼働した後は、以下の取り組みにより運用の自動化やリスク低減を行い、プロダクト価値向上のための開発をし易い環境にすることを行いました。

• 手を付ける機能から積極的にリファクタリング対応を実施
• 定期的なマスターデータ投入の自動化対応
• デプロイ作業の自動化
• 機能追加時のマイクロサービス化検討とサーバーレスアーキテクチャ（LambdaやECS）の積極的な採用

今後の不正注文検知サービス「O-PLUX」の方向性

　上記のような取り組みにより、検知精度向上のための機能追加や周辺機能の追加を行うことが可能となりましたが、一方でサーバーレス化を加速させ、今後の拡大に伴ってサーバーコストの増加を抑制したい、機能拡張を容易にしたい、Java以外の言語も採用したい等からアーキテクチャの刷新を2019年から検討開始し、2021年9月にリニューアル版O-PLUXが完成。
　社内ではGAE版を「O-PLUX V1」、最初のAWS版を「O-PLUX V2」、リニューアル版を「O-PLUX V3」と呼び、現在はO-PLUX V2とV3を並行稼働させながら、V3版での加盟店導入拡大を行っています。

　「O-PLUX V3」ではECS＋Aurora（MySQL）の構成を採用しています。
　検討当初はかなり多くの機能を分散させた構成とし、データベースとしてDynamoDBも採用していたのですが、性能面での課題や更新順序の整合性などの要件を整理し、小さなPoCを重ねた結果ECS＋Aurora（MySQL）の構成に落ち着きました。

　言語としてはKotlinをバックエンドの言語として採用し、Micronauteフレームワークを採用しました。フロントエンドはvue.jsを採用しています。

　新しいアーキテクチャ環境下での運用が本格的に開始したばかりなので、まだまだこれから課題なども出てくると想定していますが、エンジニアチームで一眼となってプロダクト価値向上のために開発・運用を進めていきたいと考えています。

少しでも、当社のエンジニアリングにご興味をお持ちの方は、ぜひ一度お話ししましょう！

エンジニアの方は下記より面談をお申し込みください！