かっこ株式会社の導入事例: Google App Engine で動作する SaaS 型不正検知サービス

オンラインショッピングが一般化し、オンラインストアを運営するビジネスでは、増加するトラフィックの処理はもちろんのこと、セキュリティ面でも、お客様が安心して買い物ができる場所となるように取り組まれているエンジニアの皆さんも多いのではないでしょうか。

Google でも、昨年発表した PCI DSS の認定取得をはじめ、安心してオンライン決済の仕組みを構築できるプラットフォームとして、様々な取り組みを継続して進めています。しかし、このような情報セキュリティの文脈ではカバーできない種類のトラブルもまたオンラインストアでは発生します。

例えば、クレジットカードの不正利用によるチャージバック、アフィリエイト目的などでの受取拒否の代引き注文。不正なのかどうかの判断が難しい上に、不正であればオンラインストアにとっての収益阻害要因にもなります。

かっこ株式会社の SaaS 型不正検知サービスである O-PLUX は、このようなトラブルへのソリューションの１つです。O-PLUX は統計解析によって過去の不正取引の手口や傾向と類似しているかをリアルタイムに分析・検知する審査サービスとして SaaS 型で提供されています。利用している全ての会社からのデータを分析し、常に最新の不正手段に対応でき、利用企業全体でネガティブな取引の情報（詐欺/未回収/クレームなど）を共有できます。

Google App Engine を使い Google Cloud Platform で動作する O-PLUX について、かっこ株式会社の企画開発ディビジョンのマネージャーである亀山 誠さん（写真左）、同部署でリードエンジニアの石川 雄介さん（写真右）にお話をお聞きしました。

かっこ株式会社について、そしてお二人の会社での役割について教えてください。

亀山さん: 私は創業メンバーの 1 人なのですが、元々創業メンバーは同じ会社で、インターネット関連の決済代行サービス事業者で働いていました。クライアント企業の代わりに債権を引きとり、回収、請求代行をしてその分手数料を貰うというビジネスモデルで、不良の債権かどうかを審査しなければならない。そのため過去の不良取引の傾向から新規取引の不良可能性を予測する、という統計的なアプローチを採用していたのですが、この考え方をより広範に適用できると考え、かっこ株式会社を創業し、インターネット広告関連等の不正検知のコンサルティング事業を始めました。

その中で、インターネットにある不正の多くは共通したロジックで解決可能だということがわかってきて、そのロジックをもとに SaaS 事業として O-PLUX をはじめました。また、統計の解析の技術を使ってマーケティングにも転用できるということで、そのコンサルティングやサービス化検討もしています。

石川さん: 亀山は開発部門の総責任者。私はインフラを担当し、アプリケーションでエラーが発生した場合のエラーの原因調査や、システム上手作業で行わなければならないツールの実行や、データ投入を実施するチームのリーダーをしています。Google への問い合わせも私がしています。

現在 O-PLUX を利用している会社はどのような企業で、何社くらい利用しているのですか？ また、競合企業があるなら教えてください。

亀山さん: 大手 EC サイトを含め、2000 サイトくらいで利用されています。国内でトータルの不正検知というサービスをやっているところはないですね。海外企業でよく比較対象になるのは、FraudNet を提供している The 41st Parameter 社や、ReD Shield を提供している ReD 社があります。

EC が拡大し続けている中でこその、課題解決のためのサービスということですね。大まかにどのようにサービスをお客様に提供しているのかお聞かせください。

亀山さん: Web API と管理画面というかたちで提供しています。API については、まずお客様の EC サイトで注文が入ります、そのエンドユーザーが、コンビニ後払いやクレジットカードを選択し、注文となった際に、その注文の情報と Javascript 経由で取得したブラウザの情報を送信してもらい、その情報から過去の傾向や統計解析した検知モデル、それに外部データを用いて、その決済の未回収のリスクを算出し、危ないかどうかのレスポンスを返すものです。審査は数秒程度で、クレジットカードの与信審査と同じくらいです。そこで、OK, NG 白黒つくものもありますが、お客様のポリシーによって、グレーゾーンを設けることができ、グレーゾーンの注文は、管理画面でお客様の担当者の方に白黒つけてもらう、というような仕組みになっています。

O-PLUX の構築をはじめたとき、はじめから Google Cloud Platform を使うことを決めていたんですか？

亀山さん: 元々 Google App Engine が出たころにさわったことがあったんです。

石川さん: 元々 1 人で作っていたんですよね。

亀山さん: そう、1 人だったので、ハードウェア壊れただとかそういうことに対処することは実質不可能で、IaaS サービスを使うにしても、OS とかミドルウェアだとか見なければならないことが多く、1人では無理で、アプリケーションだけに集中するために PaaS サービスである GAE を選びました。Heroku だとか他の候補もあったのですが、さわったことがあるという親しみもあったし、オートスケールするという仕組みも当初からあったことから選んだ、という経緯もあります。

最初は亀山さん 1 人ということですが、今開発にかかわっている方はどれくらいいるのですか？

石川さん: 正社員としては 9 人で、それ以外にも学生インターンやアルバイト、協力会社の方々など、20人以上のエンジニアが携わっています。

開発は、どのような開発プロセスで進めているのですか？ そのとき利用しているツールについても教えてください。
石川さん：Scrum ですね。チケット駆動で進めていて、Redmine でチケットをあげてもらい、できることから実施していく、という感じです。

亀山さん: リリースの頻度は短めで、だいたい週に1回、多いときで 2 回くらい、最低 2 週に 1 回はリリースしています。プログラミング言語は Java で、Eclipse や Git だとか使っています。

石川さん: 開発のやりとりは Slack を使っています。今後 チャットの中で全ての開発フローが完結するようにやっていきたいですね。他には、国外とのやりとりは Skype。ドキュメントや日報は Qiita Team に書いています。

亀山さん: 新しいプロジェクトでは、Play framework だとかを使っているので、その情報であるとか、App Engine に関することについては、Qiita で外部に公開しているメンバーもいます。

App Engine はどのような形で使われていますか？

亀山さん: お客様からのリクエストを受けるフロントエンドのインスタンスが 100、多いときに 200 くらい起動しています。フロントエンド インスタンスでメインのアプリケーションが実行されていて、Dedicated Memcache にマスターデータとかを置いて、データを使い処理することろで使い、スループットを高めるために、後からでもいいような処理、データ書き込みの処理は多少のタイムラグがあっても構わないので、リアルタイムでなくても良いものは TaskQueue になげています。

Datastore は、当然データの保存、トランザクションのデータ、マスターデータなど全て Datastore に入れているという状況ですね。ほんとにシンプルに使っています。他にはメール用に Mail API、それにバックエンドのインスタンスとして、バッチ処理だとかを動かしているインスタンスがあり、そこで App Engine Cron Service を使ってます。

App Engine 以外に使っている Google Cloud Platform のサービスを教えて下さい。それをどう使っているのかも。

亀山さん: 今使っているのは、App Engine、Google Cloud Storage、それに BigQuery を少し使っていますね。サーバサイドのアプリケーションは全て App Engine で作っています。Cloud Storage については、お客様からデータをアップロードしてもらったりとか、逆にダウンロードしてもらえるストレージとして使っています。App Engine は 2012 年の 6 月からずっと使っていて、昔はインスタンス数も少なかったのですが、今はかなり増えています。

石川さん: 私は、2014 年の 2 月に参加したのですが、その頃とくらべてもお客様の数が拡大して、使うインスタンスも増えていますね。

Google Cloud Platform 以外に使われているサービスは何かありますか？

石川さん: 統計環境は Redshift を使っています。従来の RDB に慣れているコンサル・エンジニアが多いので。ユーザー部門がレポーティングする部分では Tableau を使ってますね。統計部門のアナリストは Redshift に直接アクセスしてデータを取得し、R 言語だとかを使って作業しています。

これまで Google Cloud Platform、特に App Engine を使っていただいてきた中で、率直にどういう感想をお持ちですか。

亀山さん: サービス立ち上げの時はなくてはならなかった。なかったらここまで広がっていないと思いますね。それか僕が過労で倒れていたか（笑）

なによりサーバがメンテナンスフリーで、アプリケーションに専念できるというは大きかったですね。ミドルウェア、RDB、OS といったところのチューニングを考える必要ないですし、それにスケールする、負荷にあわせてスケール仕組みって自分で作ったら相当大変だと思いますし、メンテナンスも大変だと思います。アプリケーションを動作させておけば、あとは負荷が増えようがなんとかしてくれる、そこは安心できる、その満足度は高いですね。

石川さん: なかったら会社もなかったかもしれないですね。ただ不正検知というサービスをやってるので、信頼性というところは求められています。多くの企業に導入していくなかで、少しでも処理が遅くなることは、センシティブな問題となり得ます。これからさらに導入企業を増やしていくなかで、我々もアプリケーションを改善していく必要がありますが、Google Cloud Platform にもさらなる速度向上と安定性を求めています。

Google Cloud Platform を今後こういう形で使いたい、と考えていることはありますか？

亀山さん: Google Container Engine には興味があります。製品に使うのはまだ先だと思いますが、社内の統計分析環境の新しいツールを作るとか、社内の新しいビジネスに使ったり、SaaS 事業でもマーケティング系の新しいサービスを作っていきたいと思っているので、そういうプラットフォームの候補として検討すると思います。

石川さん: 先ほど Redshift 使っていると言いましたが、以前 Google Cloud Platform のイベントで、データが大量になるほど BigQuery の方がさくさく動くというのを聞いて、今後データが増えてきたら BigQuery の利用を検討したいと思います。また、現在 App Engine を使っていますが、開発メンバーも増えてきているので、Compute Engine に移行する、実際そういう調査をやっているのですが、何かあってお客さんに説明しなければならないときに詳しくログ調査をしたりできるようにしたりだとか、普通のサーバとして使う場面が必要になってきたと思っています。

それで Compute Engine にすることで、Fluentd でログ回収し、BigQuery に繋いだりだとか、Tableau とも BigQuery は繋がるようなので、もっと速くお客様にデータを見せられるようにしたい。今は 1 日 1 度のタイミングなので、見れるのが前日のデータだけになってしまう。そこにもリアルタイム性を出していけるかと思っています。

亀山さん: Manged VM 含め段階的に考えていきたいですね。

O-PLUX を含め SaaS 事業の今後について教えてください。

石川さん: 調査レポートを出したりしているのですが、それらをプロダクト化していくようなことも含めて、いろいろなデータを扱っている会社なので、不正検知だけにとどまらず、世の中のためになるような、気を引くようなサービスが出せるんじゃないかと考えています。

不正検知も手口がどんどん進化していますし、EC も一般の人が自由に出品したりという時代になって、求められているニーズがどんどん高くなっているという実感があります。使っているお客様の要望もどんどん厳しくなっているという空気を感じていますね。

亀山さん: 成長とともにプレッシャーも増大している感じですね。注文フローのところに直接繋がっているという、ミッションクリティカルなところで使ってもらっているので。その分僕らも Google のサポートの方に要望を出しますが（笑）。

最後にスタートアップとして成長してきた経験から、他のスタートアップの方に Google Cloud Platform を勧めるとしたらどういうところですか？

亀山さん: App Engine を使ってきたので App Engine の話になりますが、負荷が高くなったときや、セキュリティ面を Google にまかせて、アプリケーションに特化できる。自分たちのビジネスロジックに特化できるという部分は凄くお勧めできます。

スタートアップにとって、アプリケーションをいかに使ってもらえるかというところが大きいと思うのですが、そこはコンサルティングをやってきたというところが大きかったのですか。

亀山さん: そうですね。そういった意味でコンサルティングの実績があったこと、最初に大手の会社が新事業を立ち上げるときに、ちょうど出会えたということは良かったです。スケジュールも決められて作るのは大変でしたし、求められるのも高かったですが（笑）


- Posted by Google Cloud Platform Japan Team

■ Google Cloud Platform のその他の導入事例はこちらから