Interview

月間数千億のリクエストを処理する
アドテクのサーバーサイド

インターネット産業の変化にあわせて様々な事業を提供している当社では、多様な技術領域において若手エンジニアが日々活躍しています。FEATUReSでは彼らの活躍を連載形式でご紹介します。

第1回目はアドテクノロジー分野におけるサービス開発を行うアドテクスタジオでサーバーサイドを担当する黒崎優太です。

入社4年目にして、国内トップシェアのスマートフォンゲーム向け広告配信プラットフォーム「Dynalyst(ダイナリスト)」の、毎秒何十万件を越えるトラフィックをさばき、将来性を見越した堅牢なシステム構築を行っている黒崎。

拡大し続けるインターネット広告の配信基盤を支える技術。それを担う若手エンジニアの挑戦をご覧ください。

Profile

  • 黒崎 優太 (クロサキ ユウタ)
    2015年に新卒で入社以来、リターゲティングDSPである「Dynalyst」の開発を担当。Scalaで広告の入札, 配信, 計測, 集計, 管理画面まわりの開発とAWSを中心としたインフラまわりの設計、構築、運用をしている。2018年 サイバーエージェント社員総会において最優秀ベストエンジニア賞。

    学生時代からサーバーやインフラの運用に興味を持ち独自で技術を習得。当時から「情報科学若手の会」に参加し、2018年からは代表幹事に就任。

月間数千億のトラフィックを受けるための
アーキテクチャ

ーーインターネット広告の配信プラットフォームにはどのくらいのリクエストが集まっているのでしょうか。

黒崎:私は2015年に新卒入社してからインターネット広告の入札や配信といったアドテクノロジーのバックエンドエンジニアリングを担当しています。

「Dynalyst」はユーザーごとに最適化した広告を日本、アメリカを含む7カ国で配信しています。全体的には国内のトラフィックが多く、リクエスト数は秒間だと何十万、月間だと数千億以上になります。

ただし月間数千億という数字は「Dynalyst」の処理能力の上限ではありません。海外の取引がさらに増えた場合はこの数字を遥かに上回るトラフィックが予想されますが、現在の「Dynalyst」は、事業と市場の拡大を見越して、そのトラフィックに耐えうる設計をしています。

ーー月間数千億のトラフィックとはどのくらいの規模なのでしょうか。

黒崎:例えば通常のWebメディアやアプリでは自サイトへのアクセスだけを処理できれば良いのですが、広告配信プラットフォームは多数のメディアやアプリのトラフィック全てを受けているイメージです。

現在の数字は国内のトラフィックがメインですが、サイバーエージェントのインターネット広告がさらに国外へ拡大したり、広告のクリエイティビティが高まるなどして、配信先が増えれば入札も増え、トラフィックがさらに増える可能性もあります。広告市場の海外展開を想定してアーキテクチャを考えるのもサーバーサイドエンジニアの醍醐味です。

ーーアーキテクチャを考える際、何を重視していますか?

黒崎:アドテクノロジーのアーキテクチャに最も必要なのは、どんな環境下でも安定して運用できるシステムの信頼性です。現在の利用状況にあわせるのはもちろん、初期段階から事業や市場拡大を見越して設計するのが大切で、特にスケーラビリティを重視しています。

ただし、いくら事前に想定しても問題は出てくるので、まず予算内でベストソリューションを目指した手堅い設計を行った上で、細かくチューニングしていくという考え方で対応しています。

ーー「Dynalyst」は事業拡大に耐えうるアーキテクチャを初期段階から実現していましたか?

黒崎:一時期は事業の成長に対して、システムパフォーマンスが追いつかなかった時期がありました。具体的には、顧客広告主が増えるにつれ配信可能な広告が増えたため、想定を超える広告配信量になり、トラフィックが増大したためです。想定していた以上にビジネス規模が大きくなったのです。

アーキテクチャはその都度、必要な形に修正していましたし、想定を上回る規模のリクエストもスケールアウトすることで対処可能と考えていましたが、別に見落としていた箇所があり、それがボトルネックになっていました。

この処理能力が伸び悩んでいた時期は辛かったです。例えばデータベースキャッシュのネットワーク帯域やCPU使用率、サーバーのコンテキストスイッチ等、1つボトルネックを潰すと次に別のどこかでボトルネックが露見するという事が延々と繰り返され、本当に大変でした。

ーースケーラビリティを考える時に何を重視すれば良いのでしょうか。

黒崎:最終的には低レイヤーの知見が問われるとは思いますが、「AWS(Amazon Web Service)」などのクラウドを使うのであれば、まずはベストプラクティスに則った手堅い設計をし、その上でパフォーマンスチューニングや、ネットワーク帯域でのボトルネック改善にとりくむのが良いと思います。

例えば、オートスケールできないアーキテクチャをたまに見かけますが、スケールしない理由は、何かしら手作業が発生しているからです。サーバ2台構成で2倍の性能が必要になった場合は手動でサーバーを2台増やせば対応できますが、これが100台構成であった場合、手動ですぐに対応するのは現実的ではありません。

障害対応もそうです。サーバーは壊れるのが当たり前の構成にしておかないとすぐにサービスが止まってしまう。サーバーの前段にはロードバランサーがあって、故障を検知したら自動的にサービスアウトして代わりのサーバーが自動的にサービスインするようにできていればサーバの故障に関しては対応する必要はありません。何百台・何千台規模で運用すると自動化された運用によって救われる場面が数多くあると思います。

ーー「Dynalyst」ではサーバーサイドエンジニアは、インフラも担当すると聞きました。インフラを構築する際に重視しているポイントはなんですか?

黒崎:「Dynalyst」は事業の規模の割にエンジニアが多いわけではないので、専業のインフラエンジニアがいません。ですのでサーバーサイドエンジニアがインフラも担当していて、海外のリージョンも含めて素早く対応できるようパブリッククラウドをフル活用しています。

パブリッククラウドの利点は、一つ一つのコンポーネントをマネージドサービスを使って効率的に自動化できることです。Dynalystの環境は、AWSのEC2、ECS、Lambda、S3、Aurora、DynamoDB、Elasticache、Redshift、CloudFront、Route53、CloudWatch、MediaConvert、Athena、EMR、Kinesis、SQS、SNS、SES等、便利なコンポーネントをいろいろ組み合わせています。

ーー新しい技術はどの程度プロダクトに導入していますか?

黒崎:「AWS」の新機能であれば、リリースされた次の週に試してみるというのはよくあります。例としては、動画広告に対応するための動画変換基盤を自分たちで作ろうとしていたのですが、タイミングよくAWSのre:InventでMediaConvertという機能が発表されたので即座に検証し、すぐに本番導入したことがあります。

リリースされたばかりだとトラブルの解決方法がわからないことがありますが、「AWS」のソリューションアーキテクトの方と密に連携し、解決をします。また、新しい機能をベータ版から使わせてもらい、使い勝手をフィードバックすることもあります。

エンジニアやビジネスといった職種の垣根は不要。
すべては広告主の広告効果向上のため。

ーー新卒で入社して3年経ちましたが、仕事を通じて志向の幅が広がったことはありますか?

黒崎:入社当初、僕は「エンジニアは、おおよその仕様が決まったものを作るのが仕事である」と想像していたのですが、「Dynalyst」の場合、今後とりたいシェアや伸ばしたいマーケットなど、商品設計の部分にもかなりエンジニアが関わっています。というのもエンジニアと、ビジネス担当者では、最終的なゴールや考えているものは一緒だけれど、何を起点にアプローチするかが違うので、そこから新たな商品設計や顧客提案ができる場合があるからです。

例えば、エンジニアはどんなデータがプロダクトに蓄積されているか知っていて、それにあわせた配信やアプローチする層が見える場合があります。さらに広告主とのデータ連携や開発をどうするかをできるだけ面倒にならない方法で実現するかを考えます。

他にも提案した内容を動かす直前にコストの問題で中止にならないよう、実現可能性についてもセットで提案します。

このようにエンジニアも広告主の立場に立って課題を解決したり、アプローチする広告を考えビジネス職の人と一緒に提案するほうが、広告主にとってもうれしいのではないかと思っています。

ーーエンジニアとビジネスの人が一緒にアプローチを考えるというチーム体制はいつから始められたんでしょうか。

黒崎:僕がチームの入った時は開発をはじめて1年半ぐらいでしたが、すでにそうなっていました。自分は今まで技術しかやってこなかったので、ものだけ作れればいいと思っていましたが、やはり作ったものが事業として売上に貢献しないと意味がないですし、広告主に喜んでもらえたほうが自身のモチベーションも上がります。商品設計やビジネス領域にまで興味を持つようになったのは入社2年目頃からです。

業界内で急にトレンドが変わったり、ゲーム系では年末年始にゲームをする人が増えるのにあわせて広告主の予算の使い方がかなり変わったりしますが、エンジニアがビジネス職と一緒に商品の事を考えることで、システムだけ作っているとわからない、様々な要因を知ることができ、開発の速さに活きてきていると思います。

ーーサーバー運用というとトラフィックやリクエストの量やどう処理するかだけに目が行きがちですが、その背景に何があるかまで知るのが大事だということでしょうか。

黒崎:そのとおりです。トラフィック量などは1回さばけるものを作れば、技術トレンドに移り変わりがあったとしても、構成や設計を保つことでパフォーマンスは出せます。

けれどもビジネスでは、競合や他社から他にいい製品が出てきたり、動画広告のような新しい広告の出し方が出てきたりすると、同じことだけやっているとどんどん売上げが下がる場合があります。特にメディアゲームは移り変わりが大きい分、エンジニアがビジネスの流れやトレンドを気にしていくことができれば、よりうまく運用できるのではと思っています。

Page Top