Opt Technologies Magazine

オプトテクノロジーズ 公式Webマガジン

ADPLANでのAWS活用事例

f:id:opttechnologies2015:20170515200535p:plain

こんにちは! オプトテクノロジーズ エンジニアの雨宮です。主にインフラをやっています。 オプトでは様々なプロダクトのインフラ構築に AWS を利用しています。 先日、ADPLAN が AWS の事例紹介に掲載されましたが、この記事ではインフラ視点から AWS をどのように使っているか紹介します。

ADPLAN とは

ADPLAN とはオプトが 2000 年から提供している、導入社数国内最大級の広告効果測定ツールです。

システム構成

まずは ADPLAN 全体のシステム構成ですが、こんな感じになっています。

f:id:opttechnologies2015:20170519145844p:plain

処理の流れとしては以下のようになっています。

  1. 計測サーバでデータを収集 (上の図の①)
  2. EMR でデータを集計 (上の図の②)
  3. コンソールから集計結果を確認 (上の図の③)

サーバのロール説明

ここからは各処理を行なうサーバのロールごとに見ていきます。

計測サーバでデータ収集

広告を表示したりクリックしたりしたオーディエンスの行動を収集するためのサーバサイドアプリで、収集したデータは S3 と DynamoDB に保存します。 トラフィックの増減に対応するため AutoScaling を組んでいます。 ただ ELB はスパイクのような急激なトラフィック増加に対応できないため、事前にアクセス増加が予測できる場合は ELB pre-warming と AutoScalingGroup の Scheduled Action を設定しています。 また高い可用性が求められるため、バックエンドインスタンスは Multi-AZ 構成にしています (ここで計測ロストが発生すると、クリックやコンバージョンの数値が正しく集計できないため広告効果測定ツールとして致命的)。 さらに CloudFormation のスタック更新時のリスクを避けるため、スタックを 2 つに分け、万が一問題が起きてもすべての計測サーバが同時にダウンすることがないようにしています。

EMR でデータを集計

計測サーバが収集したデータを元にレポートデータを作成するバッチ群です。 S3 から Redshift にデータをコピーし、SQL で集計した結果を Redshift に格納します。 大量のデータを高速で処理するため、EMR 上で Apache Spark を実行しています。 EMR は必要な性能に応じてコアノードインスタンスを動的にスケーリングできるのがいいところです。 また EMR 上で Spark を実行すると Spark Jobs などの監視がブラウザ上からできます。 さらに Ganglia を導入し、クラスタのパフォーマンス監視もできるようにしています。

コンソールから集計結果を確認

広告主や代理店の担当者がレポート結果を確認するために利用するウェブアプリです。 計測サーバと同様、AutoScaling + Multi-AZ 構成にして冗長性と可用性を確保しています。 集計バッチで作成したレポートを表示したり Redshift にクエリを投げ様々な分析ができるのですが、今後 ADPLAN 導入アカウントが増えていくと、パフォーマンスに懸念があるため BigQuery と併用するように改修をすすめています。

その他

計測サーバ、コンソールで使用する証明書の発行は ACM を利用してますが、ELB などへのデプロイが簡単で、面倒な更新の手間もかからないのがいいですね。

Infrastructure as Code

ADPLAN では EC2, RDS, Elasticache, Redshift, DynamoDB, S3, EMR など様々なマネージドサービスを使っていますが、これらはすべて CloudFormation で構築しています。 以前は CloudFormation のスタックテンプレートを JSON で直接書いていたのですが、さすがに生の JSON を読み書きするのはつらみしかなかったので、今は kumogata を使用しています。 kumogata は複数のインスタンスバケットの構築をイテレーションで書けたり、プロダクション/ステージング環境を同じ DSL から構築できるのがメリットですね。

作成した EC2 インスタンスには用途に合せて必要なミドルウェアのインストールやアプリをデプロイするのですが、これらは Ansible で行なっています。 Ansible は環境ごとに差異があると playbook が複雑化していきます。 以前はインフラコストの削減のため、サーバのロールの分け方などをプロダクション/ステージング環境で変えていましたが、メンテナンスコストの増大とステージング環境で動作確認できないなどの問題により、最近はプロダクション/ステージング環境を同じ構成にするようにしてます。

また単にインフラ構成をコード化するだけでなく、Ansible が正しく適用されるかどうか Serverspec でチェックし、github に変更を push するたびに CircleCI 上で自動実行されるようになっています。

今後の課題

デプロイの高速化と安全性向上は以前から課題として挙がっており、CodeDeploy は導入検証したいと思っています。 また、多くのバッチを cron 実行しているので、AWS Batch も使ってみたいです。ジョブの優先順位や他のジョブの実行結果への依存などが設定できるのがよさそうです (東京リージョンに早く来て欲しいです)。

まとめ

AWS はやはりマネージドサービスの豊富さが使いやすさに繋がっているのではないでしょうか。 CloudFormation でインフラ構成をコード管理できるのもクラウドならではの利点だと思います (ただし生 JSON はやめた方がいい)。

最後に、もうすぐ開催される AWS Summit Tokyo 2017弊社 CTO が登壇します。 オプトテクノロジーズに興味があるという方はぜひセッションに足を運んでもらえるとうれしいです。

またオプトテクノロジーズではクラウドを利用した Infrastructure as Code なインフラ構築・運用に興味のあるエンジニアを募集しています。 興味のある方は こちら からご連絡下さい。