株式会社スタンバイ's job postings
はじめに
こんにちは。Clientグループ所属エンジニアの井上です。
本記事では、広告ログを集計するアーキテクチャの一部を刷新した「広告ログ基盤リアーキテクチャ」について以下の内容を中心に紹介します。
- 新旧広告ログ基盤の概要
- 広告ログ基盤リアーキテクチャの進め方で良かった方針
なお、以下の内容については本記事では特筆せず別の機会に譲ります。
- 詳細な技術選定やその方針
- リアーキテクチャの効果
本記事で紹介する方針の考え方はどのようなシステムに対しても応用できると考えていますので、本記事が読者の皆様にとって少しでも役立つと幸いです。
リアーキテクチャの背景
旧広告ログ基盤の概要
求人検索エンジン「スタンバイ」では、求人情報をご提供いただくお客様が求人広告を管理できます。 求人広告とは、求人情報のうちお客様が広告として設定した求人のことです。 株式会社スタンバイでは、お客様が求人広告を管理するための「広告管理画面」や、そのほか関連するアプリケーションを開発・運用しています。
広告管理画面の機能は、複数のアプリケーションが連携して実現しています。 その代表的な機能は、広告ログの集計結果や請求データを提供するレポート機能です。 広告ログとは、求人広告に対する求職者のさまざまな行動ログのことです。 レポート機能を実現するには、例えば以下のようなアプリケーションが必要になります。
- レポート機能を提供するアプリケーション
- ログデータや請求データを保持するDB
- データを更新するアプリケーション
実際に私たちの広告管理画面の裏側でも広告ログや請求データを集計する仕組みが動いており、これらの仕組みを私たちは「広告ログ基盤」と呼んでいます。
以下の図は、リアーキテクチャ前の広告ログ基盤（旧広告ログ基盤）の簡単なアーキテクチャです。 （実際のアーキテクチャはより複雑ですが、本記事では説明を簡単にするため、最小限の構成で表現しています。）
旧アーキテクチャの特徴と課題
旧広告ログ基盤は歴史的な背景により、主に以下のような特徴がありました。
- 広告ログを集計する経路が3つ存在する（データ基盤、バッチ処理A、バッチ処理B）。
- バッチ処理AとBはそれぞれ異なる種類の広告ログを集計する。
- 3つの経路はそれぞれ異なる技術で実装されている。
- 一部のアプリケーション（データ基盤など）は別グループが管轄している。
- 社内からは、データ基盤とバッチ処理で集計されたデータを利用できる。
- 広告管理画面は、バッチ処理で集計されたデータを利用する。
しかしながら、スタンバイのサービスとしての成長、全社共通の技術選定ガイドラインの更新、人員の増減など、さまざまな変化に伴って旧広告ログ基盤のアーキテクチャの一部が課題として認識されるようになりました。 特に、下記のような状態に起因して開発・運用・保守のコストが高い状態でした。
- 広告ログを集計する経路が複数存在する
- 広告ログデータを2重に管理する（データ基盤、広告ログ基盤）
- バッチ処理AとBに共通の仕様が実装されている
- バッチ処理Bに多機能かつ複雑で重要な仕様が実装されている
- 社内共通の技術選定ガイドラインの更新や人員の増減に伴いドメイン知識やスキル習得が必要
例えば、広告ログ集計の仕様を改善したい要望が発生した際、出力されるデータの整合性を全社として保つためには複数経路の開発が必要になるため開発コストが高い状態でした。 他には、バッチ処理Bには請求業務に使用するような重要な処理が含まれているため、バッチ処理Bに依存している複数のアプリケーション群に特段配慮する必要があり、開発効率・運用性・保守性が低い状態でした。
新広告ログ基盤
広告ログ基盤リアーキテクチャとしては、新旧の広告ログ基盤の並行稼働を前提としつつ、2つのフェーズに分けて進めることにしました。 並行稼働の影響や2つのフェーズに分けた理由については「良かった方針」にて後述しますが、主なコンセプトとしては以下を考えました。
- 広告ログの集計経路の統一
- 広告ログデータの一元管理
コンセプトをもとに、各フェーズのゴールを以下のように定めました。
- フェーズ1：プロジェクト完了時の理想状態（ToBe）の骨格を作る
- バッチ処理Bを廃止すること
- バッチ処理Bが集計していたログデータを更新する、バッチ処理Xをリリースすること
- バッチ処理Bが集計していた請求データを更新する、バッチ処理Yをリリースすること
- フェーズ2：プロジェクト完了時の理想状態（ToBe）を作る
- バッチ処理Aを廃止すること
- バッチ処理Aが集計していたログデータを、バッチ処理Xが集計すること
以下の図は、リアーキテクチャ後の広告ログ基盤（新広告ログ基盤）の簡単なアーキテクチャです。 （「データ基盤」が「新データ基盤」に変わっていることについては、後述します。）
良かった方針
当初、広告ログ基盤リアーキテクチャを進めるにあたって Design Doc などを作成していくうちに、主に以下の理由でこのプロジェクトは長期的な取り組みになると想定されました。
- 一般的に、リアーキテクチャは長期的な取り組みである
- リアーキテクチャに関連するコンポーネント（アプリケーションやDBなど）が多い
- グループ間またはプロジェクト間の連携が必要である
- 請求データを扱うため、リアーキ前後の品質管理が重要である
そのため、長期的な取り組みにおいても方向性を見失わず、着実かつ安全に広告ログ基盤リアーキテクチャを完遂できるように、リアーキテクチャの方針を（紆余曲折しながら）決めました。
以下の3つは、広告ログ基盤リアーキテクチャにおいて特に良かったと感じた方針です。
- 原則として仕様を変えなかったこと
- スコープを限定して段階的にリリースしたこと
- 全体最適を意識してアプローチしたこと
各方針について詳しくご紹介します。
原則として仕様を変えなかったこと
広告ログ基盤リアーキテクチャの前後で原則仕様を変えないことを方針として決めました。 リアーキテクチャを実施する上で、この方針をあえて強調する必要がないと感じる方もいらっしゃるかもしれません。 しかしながら、この方針をあえて強調したことは結果としてとても良かったと感じました。
エンジニアの方であれば共感いただけると思いますが、作業や調査を進めるうちに「もっと効率的に実装できそう」「ついでに修正しよう」といった風に、改善点を発見することがあります。 広告ログ基盤リアーキテクチャも例外ではなく、改善が可能な（改善したくなる）仕様がいくつか存在し、実際に改善を提案する声も上がっていました。
こういった姿勢は課題解決に積極的で良いことだと思いますが、広告ログ基盤リアーキテクチャにおいてはこの姿勢を取ることによるリスクを事前に想定できました。 具体的には以下のようなリスクが考えられました。
- 各対応の意思決定を都度実施することでプロジェクトが長期化する
- リアーキテクチャ前後でデータ品質（正確性、完全性、一貫性などの）検証が複雑化する
広告ログ基盤リアーキテクチャとしては、このようなリスクを事前に理解した上で原則として仕様を変えなかったことで、意思決定の質とスピードが下がらないように工夫しました。 また、新旧の広告ログ基盤を並行稼働したこともあり、データ品質検証の実施しやすさと検証の単純さを維持して進めることができました。
スコープを限定して段階的にリリースしたこと
ここでいうスコープとは、広告ログ基盤リアーキテクチャ対象のコンポーネントを指します。 前述の通り、新旧の広告ログ基盤を並行稼働することを前提として、広告ログ基盤リアーキテクチャ対象のコンポーネントを限定して段階的にリリースすることにしました。 この方針には主に以下の狙いがありました。
- ROIを最大化する。具体的には、広告ログ基盤リアーキテクチャの効果を最大化するコンポーネントから着手する。
- 認知負荷を下げる。具体的には、可能な限り少ないコンポーネントの作業に集中してリアーキテクチャに必要な情報を限定する。
- リソースを集中する。具体的には、可能な限り少ないコンポーネントの作業に開発リソースを集中させて効果的に活用する。
- 影響範囲を限定する。具体的には、リアーキテクチャによって影響を受けるコンポーネントが限定されることでリスク管理をシンプルにし、リリース時の影響範囲を最小限にする。
- 知見を深める。具体的には、複数のフェーズで段階的に進めることで、フェーズごとに知見を活用できる状態を作る。
こちらの方針も狙い通りの効果を得ることができました。 特に、段階的なリリースを不具合なく終えることができたのはこの方針が大きく影響していると感じます。
全体最適を意識してアプローチしたこと
ここでいう全体最適とは、広告ログ基盤リアーキテクチャのスコープを超えた全社としての優先度の話です。 広告ログ基盤リアーキテクチャを進める傍ら、別のプロジェクト「データ基盤リアーキテクチャ」が進行していました。 データ基盤リアーキテクチャとは、アーキテクチャの図に記載している「データ基盤」を「新データ基盤」に移行するプロジェクトです。
各グループの立場としてはお互いにプロジェクトをできるだけ早く進めたいため、当初はプロジェクト間の調整が難航することもありましたが、ステークホルダーと協働して全体最適を意識して進め方を整理しました。 最終的には、新データ基盤のデータパイプラインで広告ログが集計されるアーキテクチャの方針にあわせて、2つのリアーキテクチャを同時に効率良く実現することを意識して「新データ基盤の初期は広告ログを優先的に実装していく」方針としました。
プロジェクト単位の優先度がある中でも Win-Win となるような折衷案で進めたことで、システムと運用として、プロジェクトとしてだけではなく、気持ちの面に対しても良い影響がありました。
まとめ
本記事では、広告ログ基盤リアーキテクチャの概要と良かった進め方の方針について紹介しました。 広告ログ基盤のような多数のアプリケーションで構成されるアーキテクチャを変えることは長期的な取り組みになりますが、着実で安全に取り組むための方針を明確にしその方針を共通認識とすることで、あらゆるリスクを軽減しつつ効率的に開発・運用・保守の課題を改善できました。 本記事の内容が読者の皆様に少しでも役立つと幸いです。ありがとうございました。
スタンバイのプロダクトや組織について詳しく知りたい方は、気軽にご相談ください。www.wantedly.com
#61広告ログ基盤リアーキテクチャと良かった方針のご紹介
