はじめまして！ アドプラットフォームグループの宮田です。
今年DMMに中途で入社し、新規開発や保守・改善活動に取り組んでいます。
これまで位置情報を使った大規模スマホゲームやVRアプリケーション、ブロックチェーンを使ったゲーム等々を作ってきた社会人５年生です。
今年の目標はK-1のアマチュアの試合出場です。
はじめに
前回記事でご紹介したように、私たちのグループでは「お客様に合わせたパーソナライズドな広告配信ができる基盤をつくる」ことをミッションに活動しています。
今回は、スピート感を重視して広告配信サーバーの開発をするうえで意識してきた「高負荷プロダクト開発の際、抑えておくべき点」をご紹介させていただきます。
要件と開発期間
簡単に言うと、今回は以下３点の要件がありました。
- レスポンス速度を改善(目標20ms)
- 正確な広告効果の測定
- 様々な広告フォーマットでの配信
これらを着手からリリースまで目標3ヶ月という限られた期間で満たしながら、開発を進めていきました。
DMMの広告配信サーバー構成
今回の広告配信サーバー構成図はこちらです。
モダンな技術を使用しつつ、アプリケーション開発に集中できるように、AWSを使用したフルマネージドな構成でアーキテクチャを構築しました。
| 領域 | 言語、サービス |
|---|---|
| バックエンド | Go, Node.js |
| フロント(管理画面) | NuxtJS |
| 広告配信JS | TypeScript |
| インフラ | AWS ECS(Fargate), Step Functions, CloudFront, RDS Aurora, Elastic Cache, lambda, lambda@Edge等 |
| ソース管理 | GitHub Enterprise |
| 監視 | Datadog |
| CI/CD | CircleCI Enterprise |
| その他 | Docker, Terraform |
高負荷プロダクト開発の際、抑えておくべき４つのポイント
高負荷なプロダクトを開発していく際に意識すべきことは山ほどあります。
そのなかから今回は、採用している技術の紹介をも兼ねて４点を紹介したいと思います。
負荷テスト
時間がない状況でこそ重要度が増す工程が、負荷テストだと思っています。
特定エンドポイントに対して一定の負荷をかけ、CPU使用率やレイテンシ等の数値を確認し、スケーリングの調整や実装方法の変更をしていく作業です。
負荷ツールはGo製のVegetaというツールを採用しました。
テスト実施環境が楽に構築でき、操作もコマンドラインで簡単にできます。
今回は複雑なシナリオを用意する必要はなかったですが、簡単に素早く負荷テストを実施できたことで、実装の問題点を早急に発見でき大変重宝しました。
マスターデータ管理
広告配信に必要なマスターデータはRDSで管理されていますが、リクエストの度にDBへのアクセスが発生すると今回の要件であるレイテンシに大きな影響が出てしまいます。
そこで、低レイテンシを実現するために、配信に必要なデータを多層キャッシュさせています。
データは、以下の３層で管理しています。
| 管理媒体 | データ内容 | データ更新方法 |
|---|---|---|
| RDB(Amazon Aurora) | メディアや広告の情報 | 管理画面から操作 |
| KVS(ElastiCache for Redis) | RDBで管理しているデータを、配信ロジックに合わせたスキーマに整形したデータ | StepFunctionで定期的に実行されるバッチ(Go製)で更新 |
| アプリ内メモリ | KVSのデータのキャッシュ | 配信サーバー内で定期的に別スレッドを立て、KVSを読みにいく |
現在はデータ量がそこまで多くないので、アプリ内メモリには全データのキャッシュを載せています(今後増えてくるのでカスタマイズ予定)。
キャッシュ管理用パッケージ等は使わずに、独自でシンプルな実装にしました。
監視
データベースやアプリケーション等の障害は、迅速に検知して適切な対処が必要です。
そのため、監視にはDatadogを行っていて、アラートをSlackに飛ばしています。
Fargateで動かしている各コンテナは、それぞれタスク内でDatadogコンテナをサイドカーで動かして監視。
Elastic Load Balancer, Elastich Cache等でもDatadogの設定を入れて、それぞれの監視をしています。
ログ、分析、実績管理
広告配信サーバーで管理しているログは、大きく分けて３種類あります。
- アプリケーションログ
- アクセスログ
- 実績ログ(imp,cv等)
各ログは広告配信サーバーのサイドカーで動いているFluentdで出力しています。
特に実績ログに関しては管理画面から見やすく表示する必要があるため、適切な処理を加えています。
Kinesis, s3, Athena, Glueを利用して、RDSに整形したデータを溜める。
そのデータを管理画面からLambdaで用意したAPIを通して取得する流れを作りました。
| サービス | 用途 |
|---|---|
| Kinesis firehose | ログのバッファリング |
| Athena | s3からのログ取得 |
| Glue | データ整形パイプライン |
| RDS | 整形された実績データの管理 |
おわりに
限られた期間の開発でも特に抑えるべき点を意識したことで、広告配信サーバーは無事にリリースされ、大きな問題なく運用ができています。
もちろん今回ご紹介させていただいた4点以外にも考慮すべきことはたくさんあります。
今後もアドプラットフォームグループでは最適な手法を意識しながらスピード感のある開発に取り組んでいく予定です。
今回は簡単な技術紹介としての記事でしたが、次回以降はさらに踏み込んだ内容を書いていこうと思います。
ぜひ次回以降の記事もお楽しみに！
アドプラチームでは一緒に働いてくれる仲間を募集しています。
ご興味のある方はぜひ下記募集ページをご確認ください！