【CEDEC 2017】Wright Flyer Studiosの不正アクセスによる影響とその対処法…実際にBANシステムを作ってみて苦労した点とは

 
一般社団法人コンピュータエンターテインメント協会（CESA）は、8月30日～9月1日の期間、パシフィコ横浜にて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2017」（CEDEC 2017）を開催した。
 
本稿では、9月1日に実施された講演「クラウドの分析システムを活用したアクセスログにもとづくリアルタイム不正ユーザBANシステム」についてのレポートをお届けしていく。
 
本セッションには、グリー Wright Flyer Studios事業本部 Quality Assurance部 QA Engineerチーム リードエンジニアの藤田貴大氏が登壇。QAエンジニアとして、不正ユーザの状況やクラウド分析システムであるKinesis Analyticsを採用し、使ってみてわかった問題点とその解決方法、アクセスログにもとづく不正ユーザへの対応システムについての話を展開した。
 

▲グリー Wright Flyer Studios事業本部の藤田貴大氏。インフラ整備やWebゲーム開発、QAエンジニアを経て現在はWright Flyer Studiosでネイティブゲームの開発にあたっている。
 

■不正ユーザによりゲームにどんな影響が？
 
『消滅都市2』や『ららマジ』、『武器よさらば』、『アナザーエデン 時空を超える猫』、『ダンまち～メモリア・フレーゼ～』と数多くのタイトルを開発・運営するWright Flyer Studiosには、「Gamelib」と呼ばれるチームがある。これは、内製ゲームの課金基盤で、運営・開発からは独立したチームとなる。そんなGamelibに「急にリソースの消費が激しくなる」というヘルプが入ったという話から今回の講演がスタートした。
 
調査を進めたところ、原因の一部として不正なアクセスが増えていることが発覚する。藤田氏は、同じIPアドレスから大量のアクセスがあったことから、リリース直後のリセマラによるアカウント売却などを目的としたものではないかと推察したという。また、ゲームをしていないであろうAPIアクセスも見られたとのこと。
 


▲青い線の部分が不正なアクセスによるもの。
 
また、不正アクセスが増えた影響としてリソースの消費が激しくなり、対応するまでの1週間でデータ量が10％増加、対応後は2ヶ月で5％の増加に収まったため、普段の10倍ほどのデータ量が一気に消費される異常事態だったことが分かる。
 

 
サーバ負荷が大きくなるので、ユーザのゲーム進行に影響を与えないため、対応としてサーバ台数をピークに合わせなければならないが、不正なアクセスがあるタイミングは図れないため、増減させるのが難しいという悩みがあると藤田氏は明かした。また、課金系のデータは安易に消去できないため、継続的な費用増加に繋がってしまう。


 
そこで、個別やバッチで複数の角度から対応はしたものの、短時間に急遽来たものに対しては対策ができなかったという。今回のセッションでは、この部分への対応を迅速に行うために実施したチャレンジを紹介していく。
 

■リアルタイムに不正ユーザをBANするシステムを作る
 
まず、藤田氏が目標として掲げたのが以下の部分だ。
 

▲課金系だったため既存部分には手を入れずシンプルに保っておきたかったとのこと。不正アクセスを完全に防ぐことは難しいため、不正ユーザの作業効率を悪くする方向で対策を練ったと話した。
 
実装をどうするかという部分では、BANの判断をするために、いくつかのAPIログを付き合わせたかったという。藤田氏は、個々のAPIの異常値で判断をするならLambdaという手段もあったが、今回は複数のAPIを付き合わせたかったためストリーム処理という手法を選択したと語った。
 
ストリーム処理とは、大量に発生するデータを時系列に処理する技術で、詳しくは以下のサイトを参考にしてほしいと紹介した。
 

【関連サイト】
The world beyond batch: Streaming 101

 
そして、実装も数多くある中から今回はKinesis Analyticsを採用。GamelibそのものがAWSで稼働していたことや、サーバ構築・スケーリング・障害対応といった点で管理負荷を上げたくないという理由があったと藤田氏は説明した。
 


▲こちらは全体構成。「入力」「処理」「出力」の流れも以下で細かく解説した。
 
●入力

 
●処理

▲データの振り分けを行った理由については後ほど紹介するとのこと。
 
●出力

 
さらに藤田氏は、ここで苦労した点として下記の4つを挙げた。
 
【苦労した点】
①ローカルで実行できない

 
②クエリを更新すると結果が2重に出てくる


▲ここで、更新時は2系統立ち上げてLambdaで切り替えることで結果が重複する事態を回避した、と先ほど処理の段階で振り分けを行った理由を説明した。
 
③周辺環境が整っていない

 
④SQLだけどRDBと違う

 
複数のAPIログを突き合わせたかったのでJOINしたかったが「入力は発生順に来ない」「ウインドウという概念が難しかった」「集計関数が難しかった」という難題があり、今回、最も悩ましかった点だったと藤田氏は話す。ここからは、思い通りの結果を出すため、それらの問題にどのように対応していったかが明かされた。
 
●入力は発生順に来ない

▲次の問題でもあるウインドウについて、時間をかけて理解を深めることで解決した。
 
●ウインドウという概念が難しかった

▲時間を区切る方法は、主に、区間がオーバーラップしない「タンブリングウインドウ」と、オーバーラップしながらスライドしていく「スライディングウインドウ」の2種類がある。
 


▲今回のケースでは「スライディングウインドウ」を使用。
 

▲実際にJOINしてみたところ、「結果が毎回違う」「JOIN範囲が不定」という問題が発生。
 

▲そこで登場したのが、「10秒前まで」「5列前まで」というように処理が実行されたときに遡るデータの範囲を指定する「OVER句」だ。
 
これを使って、’0’ SECONDのコマンドを入れてみる。
 


 
ストリームにデータが入るたびに処理は発生しているが、「’0’ SECOND」のコマンドは一切データを遡らないので、処理のトリガーになったデータのみを見ることになる。つまり、処理範囲が上図の赤枠の部分のみになるので、JOINができず結果は何も出てこないというわけだ。
 
そこで、ストリーム1側のコマンドを「’10’ SECOND」にする。
 

 
これで、処理が発生したとき、ストリーム1は10秒前までのデータを使うことになる。すると、処理タイミングごとに以下のような結果となる。
 



 
次は、ストリーム2のみ同じように10秒前までのデータを使用するように設定してみる。
 


※写真ではStream1のID:10,A1が赤字となっているが、正しくはStream1のID:10,A:3が選択される。
 
最後に、ストリーム1・2ともに’10’ SECONDを入れてみると出力は以下のようになる。
 


▲トリガーとなったレコードが絡まないJOINは出力されないため、重複せず4つのみ出力される。
 
藤田氏は、いろいろ試して自分なりの理解を深めたところ、ログが順番通りに来ない状況でも意図した結果を出せるようになったとまとめた。
 

 
●集計関数が難しかった
 
集計関数にもOVER句を付けることができる。しかし、処理のたびに結果が出てしまうため、ある期間の最小値のみを求めることはできないかと悩んだが、こちらについては実現できなかったとのことだ。




ただし、ある機関で最初の1つだけを出力すれば重複レコードについては排除できると解説した。
 

 
こうして、Kinesis AnalyticsのSQLの動きを理解し、意図したユーザアカウントを、数分以内に抽出することが可能となった。現在も複数のゲームで運用されているとのことだ。なお、藤田氏は既にチームを離れ引き継ぎも行っており、現在も呼び出されることがないとの発言から、安定して運用されている様子が伺えた。
 
最後に藤田氏は、本セッションを以下のようにまとめて講演の締めとした。
 

 
 


■関連サイト
​

CEDEC2017