現場に聞いたAWS活用事例 第6回

リアルタイムなデータ分析と施策創出のためにDB移行を決断

レプリカラグ解消とコスト削減が大きかったFlipdeskでのAurora導入

レプリカラグの解消で精度の高い施策に結びつけたい

　AuroraはMySQL互換のマネージドデータベースサービス。re:Invent 2014に発表され、オンプレDBをクラウドに移行する切り札として、鳴り物入りで登場したサービスだ。「通常は（マネージドサービスの）RDSを辞めたら、EC2インスタンスを立ててMySQLを自前で載せるのですが、やはりマネージドではないサービスは使いたくないなと思っていました。スケールするというメリットが魅力的。オペレーション含めたデータストアのコストも、1/10までは行かないけど、1/5くらいはいくかなと」（石井氏）ということで、MySQLとの互換性もあり、次世代アーキテクチャへの移行も考えて、Auroraは第一の選択肢に挙がったという。

　一方、生内氏は1つのリクエストを返す際の処理の中にも、軽いものと重いものが混在しているFlipdeskの特性を考えて、Auroraへの移行は妥当だったと語る。「Flipdeskは、ユーザーのトラッキングデータを元に施策を打つ仕掛けになっていますが、トラッキングデータも1年前からのものか、1週間前からのものかで、データハンドリングの負荷が大きく異なります。しかし、MySQLではレプリカラグが頻発していたため、構造上差分を埋めるのは難しかったんです」という。

「MySQLではレプリカラグが頻発していたため、構造上差分を埋めるのは難しかったんです」（生内氏）

　その点、Auroraはデータストアに分散ストレージを用いたアーキテクチャを採用しており、レプリカのタイムラグが構造上ほぼ起きないため、精度の高い施策に結びつけたいという生内氏の思いに答えられそうだった。生内氏は、「レプリカラグのようなデータ反映の遅延がほとんどないというAuroraの特徴がとても大きかった。多少コストが増しても、メリットが大きいと思いました。取得したデータをすぐに使い、リアルタイムに施策を打てるというのは、僕らのツールそのものの価値でもあるので」と語る。

「ブラックボックス」なAuroraと向き合った4ヶ月

　2014年に発表されたAuroraも、いよいよ2015年10月に東京リージョンで開始され、Socketでも検証を開始した。とはいえ、Auroraの構造は基本的にブラックボックスで、動作や性能が読めなかったという。いくつか事例はあるとはいえ、ほとんどは海外発で、発表資料以上のことはほとんどない状態だった。そのため、検証には4ヶ月をかけたという。

　前半の2ヶ月はMySQLとの互換性を調べるロジック面でのテストを実施。当初はストアドプロシージャが動かなかったが、Auroraのバージョンアップで解消。ソースも見られないし、やはりブラックボックスなところはあったが、いくつか試すことで、クセは見えてきたという。「たとえば、Auroraの場合はmasterにあたるwriterが再起動すると、readerがランダムにwriterに昇格します。アプリケーションから見ると気にすることはないのですが、データベースのオペレーション上はMySQLとちょっと動作が異なります」と石井氏は語る。ちなみに、現在はwriterに昇格するreaderが指定できるようになっているという。

　後半の2ヶ月はおもに負荷テスト。移行チームに新たにジョインしたエンジニアがMySQLのデータをAuroraに書き込む移行用のスクリプトを作り、MySQLに戻れる状態を確保した後、実施したという。最後の方では本番データも利用したが、結果として高いパフォーマンスが得られたという。「分散ストレージのため、インデックスを張ってある特定のデータをテーブルに抽出するまではものすごく速いと思います。インデックスが張ってあれば、無限にスケールするのではと思うくらい速いです」と石井氏は語る。

　しかも、Auroraインスタンス内に位置する永続的キャッシュの効果も高いようだ。石井氏は、「僕が見た限り、Auroraは分散ストレージで共有しているキャッシュがインテリジェントに作られているか、もしくはリソース自体が豊富に用意されているため、いったんキャッシュに入ってしまうときわめて高速。一方で、データを全部持ってきて、最初に集計をかけるような場合はちょっと時間がかかる印象があります。MySQLも似たような傾向はあるんですけど、Auroraの方が顕著」と分析する。

　また、分散ストレージもユーザーの利用負荷にあわせてダイナミックにアサインされているのではないかと推測されるという。いずれにせよ、既存のエンタープライズ向けデータベースと異なり、クラウド事業者でないと難しいスケーラブルなアーキテクチャとなっているのは確かで、スケーラビリティを求めるWebサービス事業者にとってのメリットは大きいという。

コストはざっくり半分！レプリカラグがなくなり、精度は大幅向上

　互換性や負荷の点でも問題なかったため、2016年2月に移行チームの3人は3日間くらい泊まり込んで、一気に移行作業を実施した。サービス停止はなく、オンラインでMySQLからAuroraに移った。「昨年発表されたData Migration Serviceが日本で使えるようになった日にちょうど移行したんです。オペレーションしながら、アイコンが増えたのを見てショックを受けました。あと1ヶ月早ければと思いました（笑）」と石井氏は語る。とはいえ、アクセス権限なども基本的にはMySQLを踏襲できるので、商用データベースに移行するよりも容易だったという。

　Amazon Auroraの導入効果の面で大きかったのは、生内氏が狙っていたデータの精度面だ。「フェッチしたときの返ってくるデータの精度をアプリケーション側で担保する必要がなくなった。だから、精度面ではたぶん100倍くらいよくなってる」と生内氏は語る。

　「DynamoDBと同じくRDBインターフェイスを提供しているだけで、中身的にはバルクだなと感じることはあります。とはいえ、商用データベースも逃れられないレプリケーションの罠に対して、今までは自前でKVSをはさむといった施策が必要だった。Auroraはそこらへんをわりとうまくやってくれているので、レプリカラグが抑えられているし、ラグによる影響を抑える制御を自前で実装する必要がないだけでもかなりありがたい」（生内氏）。

　コスト面の効果算出はなかなか難しいが、「おおざっぱにパフォーマンスは2倍くらいになったのでは」というのが二人の一致した見解。これについてはデータストアの利用コスト削減のみならず、マネージドサービスであるが故の運用負荷の軽減、さらに移行の労力まで含めた手堅い数字で、これくらいだという。「Auroraが直接寄与したというより、サービスの向上や機能強化に当てられる時間を得られたところが大きかったですね」（石井氏）。

「サービスの向上や機能強化に当てられる時間を得られたところが大きかったですね」（石井氏）

　Flipdeskの次の方向性は、ECサイト以外への拡大だ。「Webの接客ということで、今まではECサイトを対象に機能強化を図ってきましたが、今後は人材や金融、不動産など1つ1つの商材が高めで、コンバージョン効果が高いサイトに向けた機能を拡充していきたい」と生内氏は語る。

■関連サイト

• Flipdesk
• Amazon Aurora