本連載では第一線のPerlハッカーが回替わりで執筆していきます。今回のハッカーは星野将さんで、テーマは「大規模広告配信でのCPANモジュールの活用」です。
本稿のサンプルコードは、本誌サポートサイト から入手できます。
大規模広告配信の運用
多くのWebサービスは、24時間365日それを提供しながら発展、拡大させていくことを目標に運営されていることでしょう。そのためにエンジニアに課せられる課題は、「 増加するリクエストをすばやくさばきつつ、安定して運用させるためにどうするか」になります。
コンシューマー向けサービスは、多くの顧客にすばやくサービスを提供するという目標を持っています。それらのサービスに広告を配信する配信業者も同じ目標を持っており、広告配信をサービス提供のボトルネックにさせない取り組みをしています。広告配信は単体ではサービスとして成り立たず、広告を表示するメディアがあるからこそであり、メディアとそのエンドユーザーのためにも配信の質と速度を重視します。
今回は、筆者が所属する広告配信サービスfluct を事例として、CPANモジュールの選択方法と、大規模システムでの運用事例について解説します。
広告配信のしくみ
近年の広告配信にはさまざまなプレーヤーが存在しますが、以降を読み進めるために必要なプレーヤーは以下です。
Webメディア
広告枠を提供する
SSP（Supply Side Platform ）
Webメディアに広告配信を行う。Webメディアの収益の最大化を目的とする（fluctはこのポジション）
DSP（Demand Side Platform ）
広告枠の買い付けを行う。広告主の広告効果の最大化を目的とする
広告主
広告出稿を行う
この4者が図1 のようにやりとりを行います。SSPとDSP間で交わされるのがRTB（Real Time Bidding ）と呼ばれる競争入札（オークション）です。1つのSSPが複数のDSPに対してリクエストを投げ、レスポンスを受け取った中から最も高い金額のDSPを選択します。選択したDSPから広告情報を受け取り、それがWebメディアに表示されます。
図1 広告配信のしくみこのやりとりを行うにあたって、WebメディアのWebサイト内にJavaScriptタグを設置しておきます。サイト閲覧時にJavaScriptタグから広告配信サーバにリクエストが投げられ、広告を表示するためのJavaScriptタグがレスポンスとして返されます。
なお、広告が表示された回数をインプレッション数（imp数）と呼びます。
広告配信サーバ
図1で「広告配信サーバ」としていたものは、内部では次の3つのプロセスで成り立っています（図2 ） 。
図2 広告配信サーバ
フロント
JavaScriptからのリクエストを受け付けるエンドポイントとなるPHPプロセス
アドサーバ
フロントからリクエストを受け、案件情報の取得や次のRTBへのリレーを行うPerlプロセス
RTB
アドサーバからのリクエストを受け、DSPとRTB取り引きを行うErlangプロセス
2016年6月時点で、上記のアーキテクチャによって、fluct全体で月間330億のインプレッション数をさばいています。単純平均で秒間1万リクエスト以上となり、ピーク時には秒間2.5万程度のリクエストがあります。
もちろん330億というインプレッション数は最初からではなく、年々積み上がってきたものです。このインプレッション数の増加に対して、ハードウェアや環境まで含めてさまざまな取り組みを行ってきました。以降ではその中でもソフトウェア面、特に広告配信サーバの中心となるアドサーバにおけるPerlの活用を解説します。
＜続きの（2）はこちら 。＞
特集1 イミュータブルデータモデルで始める 業務の複雑さをシンプルに表現！ 特集2 いまはじめるFlutter iOS/Android両対応アプリを開発してみよう 特集3 作って学ぶWeb3 ブロックチェーン、スマートコントラクト、NFT
