デジタルマーケティングをHackするプロダクト開発力。「成果がでる」デジタルマーケティングプラットフォームを支えるビッグデータ処理と基盤の構築事情をお話します！

マーケティングプラットフォームのアーキテクチャー＆サーバレス化を選択しない理由

最後に岡澤さんからインフラについての詳細です。

岡澤 哲也
デジタルマーケティングプロダクト開発部 GlobalAccessMill開発ユニット AWSインフラ担当
SIerとして携帯電話の組み込み開発等を行い、2012年にマクロミルに入社。
好きなAWSサービス：Athena

岡澤さんからはサービス規模の推移からシステムの構成がどのように変化していったかを詳細にお話いただきました。

背景

「2014年のAccessMillサービスリリースから2018年現在まで月間アクセスは5倍まで成長しています。

海外からのアクセスや急激に増加するデータに対応するために Lognos はこの4年で5度のシステム改修が行われています。」

大量アクセス、大規模スパイクに対応するために

「AccessMillの成長により月間100億アクセスを高速かつ正確に捌く必要がありました。

従来はサーバを多数並べることで規模の拡大に対応してきましたが、コスト面に大きな課題がありました。

これらの解決策としてサーバレス化の検証を進めていきました。」

①すべてのアクセスをAPI Gateway + Lambdaで処理する

「検証の前にコストを概算した結果、900万/月以上かかることが判明し、その時点で断念しました。」

②モニタのimpアクセスをAPI Gateway + Lambdaで処理する

「次にビジネス的に重要度の高い、モニタimp(アクセス数少ない)をAPI Gateway + Lambdaで処理し、

重要度の低い、非モニタのimp(アクセス数多い)を従来のwebサーバで処理することを考えました。」

「検証の結果、大量のアクセスを受けたときにAPI Gateway で502エラーが平均0.7％発生しました。

このエラー率はAccessMillでは到底許容することができない上に、モニタ、非モニタの判定でLambda@Edgeを使用していましたが、

スパイク時の秒間1万アクセスを処理することができず、Lambdaは採用できないという判断に至りました。」

この時点でサーバレス化は断念しました。

③Dockerコンテナ + NGINXサーバで処理

「アクセス数の多いimpを通すルートにはClassicLoadBalancerではなくNetworkLoadBalancerを使用することにしました。

というのも、プレウォーミングが不要なのでスパイクアクセスに柔軟に対応できるからです。

Nginxにより性能の底上げが可能であり、ECSを使うことにより管理負荷が低減できると考えています。」

この構成を採用！

コンテナ内の構成：NGINX + uWSGI + Python

構成

NGINX：Webサーバー

uWSGI：WSGIサーバー

Python：impression処理

kinesis-agent：Kinesisへのデータ送信

コンテナ化の検証結果

従来サーバーと比較して、性能は12倍

サーバ台数が80％ダウン

コストも74％ダウン

大幅なパフォーマンスUPとコストカットを実現！

「今後はAWS Fargateなどを用いて、サーバレスではなくサーバ管理レスを目指していきたいです」

懇親会

懇親会では登壇者とも交流や情報交換などで盛り上がりました。

第二回を開催予定ですのでまたのご参加をお待ちしております！