エッジコンピューティングでアクセス集中、パーソナライズ、プライバシー保護の課題を解決

エンジニアの木村です。最近は負荷対策のためのリファクタリングやリアーキテクティングのリードや、データ基盤・ML・検索基盤を担当するチームのマネージャーとしてデータ関連の案件に携わっております。

先週、webinar 形式で行われた Akamai TechWeek 2021 Japan にて、6/16 に「EdgeWorkersの導入について」というテーマで、昨年末にバイマに導入したEdgeWorkersというAkamaiのサービスについて講演しました。本ブログでもその内容を共有したいと思います。

スライドはこちらになります。

エッジコンピューティング導入の背景

導入背景としては、アクセス集中下でもサービス自身のドメインを通じて自らユーザーを追跡し、ファーストパーティデータを収集する必要性という事業課題がありました。

アクセス集中を伴うマーケティング施策への対応

事業課題の1つとして、モバイルへのプッシュ通知と、フラッシュセール施策という、いずれもアクセスの集中を引き起こすマーケティング施策へサービスとして対応していく必要がありました。

まず、モバイルへのプッシュ通知が増加しているのですが、その背景には時代やサービスの成長フェーズの移り変わりがあります。マスマーケティングからOne to Oneマーケティングへと、我々の注力ポイントが変わってきているからです。実際、以前は認知を広げて新規顧客を獲得するためにTVCMによるマスキャンペーンを展開し、当時はアクセス集中といえばTVCMの放映起因がほとんどでした。最近は既存顧客一人一人に対してパーソナライズ した通知を送ってリテンションを図る施策が増えています。モバイルアプリをインストールしているユーザーやLINEのバイマ公式アカウントと連携しているユーザーはサービスへのロイヤリティが高く、通知の開封率も高いので特に一斉に送信するような通知ではTVCM放映以上のアクセス集中が生まれています。

フラッシュセールとは、ブラックフライデーサイバーマンデーなどのセール施策のことです。期間や商品の在庫も限定した形で行われ、また先程のプッシュ通知により開始が通知されるのでアクセスの集中が発生します。毎年性能改善を重ねてはいたのですが、スケールが難しいオンプレのインフラを使っているサービスのところでは対策に限界があったのと、年々増加していくユーザー数に追いつかない状況で、毎年このセールの開始直後はサイトのパフォーマンスが不安定になっていました。

パーソナライズとプライバシー保護の両立

直面していた事業課題の2つ目は、プライバシー保護とパーソナライズの両立です。

パーソナライズ についてですが、最近はレコメンドなどに代表されるパーソナライズ されたUXへの期待が高まっています。北米やイギリスの消費者を対象にした2019年の調査*1では、63%の消費者がサービスの標準としてパーソナライズ を期待しているそうです。また、自分だけの特別なオファーが送られてきたり、サービスとの各接点で一人の同一の顧客として認識されることで一人の個人として扱われていると感じるそうです。したがって、サイトのUXだけでなく、マーケティング施策にもパーソナライズ が求められています。さらに、そういったUX改善やマーケティング施策の効果測定でも、施策による単純なKPIの動きだけでなく、ユーザーを一人一人区別して分析し、どのような属性の顧客に効いているのかといった高い解像度での分析が求められています。

また、ユーザーはパーソナライズ を期待している一方で、プライバシーの保護についての意識も高まっていて、個人データの収集に関して透明性が求められています。それに答えるように、SafariChromeといったメジャーなブラウザでブラウザフィンガープリントやサードパーティクッキー、クライアントサイドクッキーは何らかの制限や規制、あるいは廃止される予定になっています。これにより、ユーザーを追跡する手段としては、サービス自身のドメインを使ってのファーストパーティクッキーだけが残され、そのクッキーを通じて収集されるファーストパーティデータの重要性が増してきています*2

エッジコンピューティングの導入理由

そういった背景から、なぜエッジコンピューティングの導入に至ったのかをお話しします。

CDN導入のための必須要件

背景にあったアクセスの集中に対応するために、それまで画像・js・cssといった静的コンテンツのみで多なっていたCDNでの配信を、Webアプリから返しているHTMLやAPIという動的コンテンツの配信にも導入することになりました。また、これも背景で説明したパーソナライズ やデータ収集の必要性から、CDNを選定するにあたり以下の3つの必須要件を定めました。

  • レスポンスをパーソナライズ可能
  • エッジアクセスデータと自社DWHの連携が可能
  • ファーストパーティCookie操作をエッジへ移行可能

1つ目はレスポンスをパーソナライズ可能性、つまりキャッシュするコンテンツをユーザーによって分けたりが可能かどうかです。2つ目はエッジアクセスデータと自社DWHの連携が可能かという点です。それまではオリジンのWebサーバーのログをDWHへ連携することでユーザーのサイト内の行動を分析していたのですが、キャッシュされるコンテンツに関してはオリジン側へログが残らなくなるため、分析のためにエッジのアクセスデータを自社DWHへ連携する必要があります。3つ目ですが、バイマでは未ログインでセッションを張っていないユーザーも追跡可能にするためにファーストパーティcookieを利用していて、これによりUXのパーソナライズやマーケティング施策の効果計測を実現しています。そのCookieの操作処理をエッジへ移行する必要がありました。

ITP2.1 への対応

Cookie操作処理のエッジへ移行する必要性の経緯としては、ITP 2.1 への対応というのがあります。

f:id:enigmo7:20210617143016p:plainf:id:enigmo7:20210617143020p:plainf:id:enigmo7:20210617143027p:plain
Cookieの操作処理の変遷
バイマでは当初、そのCookieの操作をJavaScriptAPIであるDocument.cookieで行っていたのですが、2019年にApple によってブラウザのJavascriptで作成するCookieの有効期限は最大7日に制限するというITP 2.1のSafariへの導入 がアナウンスされました。バイマではiOSSafariのユーザーが大半を占めるので、我々はそれまでブラウザのJavascriptで行っていたCookieの操作をオリジンのアプリケーションサーバー側へ移行し、Set-Cookieヘッダーによりcookieを操作するように修正を行いました。今回のCDNの導入の際は、キャッシュヒット時にもSet-Cookieヘッダを返すことでCookieを操作する必要性がでてきます。したがって、ファーストパーティCookieの操作処理をエッジサーバー側へ移行する必要性がありました。

Akamai EdgeWorkers を採用

いくつかのCDNサービスからAkamaiを選んだ理由としては、上述の必須要件を満たしていたという点がありました。プロパティだけでもかなり柔軟なルール設定が可能で、それだけでもある程度パーソナライズは実現可能でした。また、DataStream 2 というサービスにいよりエッジのアクセスデータをリアルタイムに近い形で、GoogleのBigQuery上で構築している自社のDWHへデータ連携が可能でした。さらに、EdgeWorkersによりCookie操作をエッジサーバー上への移行が可能という点で必須要件を全て満たすことができました。

また、すでにスタティックコンテンツの配信では既に導入実績があったという点も採用への後押しになりました。実は、この3つの必須要件のパーソナライズ、データ連携、エッジコンピューティングの機能については、他の競合CDNサービスも提供されています。ただ我々としては利用に慣れていて信頼のあるAkamaiを使いたかったので、逆にこちらからエッジコンピューティングの機能について問い合わせたところ、EdgeWorkersを提案いただき採用に至りました。

EdgeWorkers の開発・運用

EdgeWorkersでどのように開発をすすめたのかや、実際の運用状況について紹介します。

利用開始は簡単

最初のEdgeWorkersへのとっかかりは簡単でした。すでにAkamaiをお使いの方にはお馴染みのWebコンソール「Control Center」から利用可能です。実装も簡単で、開発者はイベントハンドラのファンクションを実装するだけになります。今回クライアントへのレスポンスするタイミングで呼ばれる onClientResponse を実装しました。Web UI上でコーディング、アクティベートも可能だったので、チュートリアルとしてのHello Worldを動かすところまでは1日で到達できました。

ライブラリも利用可能

利用できるライブラリについてですが、cookie操作やURLのパースなどは標準で組み込まれいているモジュールで十分可能でした。また、rollup.jsというJavaScriptのモジュールバンドラーにより標準組み込みでない、npmリポジトリで公開されているサードパーティ製モジュールもbundle可能でした。1点だけ注意というか、当然ではあるのですが、ブラウザJavaScriptのコードをそのまま移植しようとしても動かなかったです。元々はブラウザJavaScriptCookieを操作していたロジックはあったのですが、書き換える必要はありました。さらに細かいところで言うと、ブラウザだとwindowのオブジェクトにatobやbtoaというbase64エンコーディング・デコーディングをしてくれるfunctionが付いてるんですが、それは使えず、代わりにrollup.jsでbase64エンコーディングを行う3rdパーティモジュールをbundleして呼び出して使っています。

開発時のデバッグ方法

開発時のデバッグ方法ですが、ログ出力をレスポンスヘッダに埋め込んで確認できるenhancend debug headerを利用し、ステージングへアップロード&アクティベートを繰り返しながらのプリントデバッグで切り抜けました。本当はakamaiCLIでローカルにSandboxを構築して利用する方法もあるのですが、その構築が手順通りにやってもうまくいかず、ブラックフライデーが差し迫っていたこともあり、問い合わせる余裕すらなかったので、実環境のステージングでの開発となりました。ただステージングへのアクティベートは毎回許容範囲内の時間で終わってくれるので、このやり方でも開発は可能でした。手順通りにやってうまくいかないという点なのですが、ある程度経験のあるメンバーが二人がトライして、二人ともSandbox構築にハマっていたので、ドキュメントに関しては何らかの改善の余地はありそうです。昨年末の話なので、既に改善されているかもしれないですが、期待とフィードバックの意味も込めて、ここで苦労したエピソードとして紹介させていただきます。

開発時の参考リソース

開発時に参考にしたリソースとしては、ユーザーガイドもあるのですが、他にもGitHubのリポジトリにexampleが公開されていて、先行事例があまりない段階での利用だったので、開発時にはそれが大変助かりました。ブログにも参考になりそうな記事があります。ユースケースの紹介もありますし、Github ActionsでCICDを実現するような事例も載っていて、デベロッパーフレンドリーにできてるなと思いました。

本番運用してみて

実際に本番運用してみている状況についてですが、実行時間的なパフォーマンスは非常に良いです。エッジでなにか処理を行っていてもUX上はなにもレイテンシを感じないレベルを維持できています。

f:id:enigmo7:20210617153422p:plain
EdgeWorkersの実行時間の推移

ただし、本番環境でのトラブルシューティング時のログ調査に課題があるなと感じました。原因調査のため、ログ出力の解析をするためにログ取得をしようとすると、Log Delivery Serviceを使うのですが、実際に手元にログが届くのが次の日になるので、トラブルシューティングのサイクルを回すのが非常に時間を要する状態でした。EdgeWorkersをFaaS (Function As A Service) として見たときに、競合としてはAWSのLambdaやGCPのCloud Functionがそれに当たると思うのですが、これらの場合はリアルタイムに近い形でWebUI上で本番のログをtailしたり、検索、分析できたりします。当然Akamaiそういった機能はあるのだろうと、期待していたところもありましたが、そういた機能は未提供となっているところは残念なポイントでした。今後提供されることを期待したいと思います。

EdgeWorkersの今後の活用と期待

私たちのEdgeWorkersの今後の活用案や、EdgeWorkers自体に対してどのような進化を期待しているかというお話しをしたいと思います。

EdgeWorkersの今後の活用案

今後の活用案としては、これまではキャッシュすることでオリジン側の負荷をオフロードするだけでしたが、EdgeWorkersによりオリジンのロジック自体をエッジへマイグレーションしてよりアグレッシブなオフロードが可能となったと思うので、今回はCookie操作の処理だけでしたが、分散処理可能なものはEdgeWorkersへ移行してよりオリジン側の負荷を減らすことが考えられます。また、これまでオリジン側の負荷の制約で諦めていたサイトUXのパーソナライズ施策がたくさんあります。工夫次第ではEdgeWorkersを使うことで実現できそうなものもありそうです。

EdgeWorkersへの今後の期待

最後に、EdgeWorkersへの今後の期待としては、運用のところでも述べた競合並みの監視・ログ管理ツールの提供です。また、監視として使えるものとしてEdgeWorkers Report APIが提供されていて、各種メトリクスを取得できるのですが、自社の監視ツールに手動で設定する必要があります。最近は我々も導入しているDataDogやNew Relicといった3rd パーティの監視SaaSがあるので、SaaS側にEdgeWorkersのインテグレーションを用意してもらって簡単にメトリクスやログを収集し、常時監視できたらありがたいと思いました。率直に言って、現状のレポーティングの機能だけですと、Cookieの操作のようなライトな使い方が限界かなという印象です。これら監視・ログのサポートが揃えば、ある程度複雑な処理を書いても本番運用に耐えると思うので、今後の活用案のところで書いたような、マイクロサービス をエッジ上で構築するぐらいのヘビーな活用も目指せると思いました。

また、データ連携の強化も期待したいです。EdgeKVという、Key Valueストアとして使えるストレージの機能があるのですが、そこのデータがエッジ上にあるままでは活用は限定的なものになってしまうと思いました。そこのデータも自社のDWHなどに取り込み、他のデータと紐づけての活用が可能になれば理想的です。

まとめ

私たちは、アクセス集中による負荷の軽減・パーソナライズ・プライバシーの保護というお互いにトレードオフの関係にある課題を解決する必要がありました。エッジコンピューティングの導入により、それらをどれも犠牲にすることなくクリアすることができました。EdgeWorkersには、ドキュメントの整備や運用面ではまだ課題はあるもの、それらが改善されれば開発者体験としてはさらに向上し、よりディープな活用へと踏み出すことができると期待しています。

最後に、私たちは今回紹介したようなUXの向上やプライバシー保護についての課題など、純粋にユーザー目線でサービスの課題解決に日々取り組んでおります。CDNを始めクラウドサービスや、最新テクノロジーを駆使して世界を変える流れを作るサービスを提供する仕事に興味のある方は、下のリンクからご応募お待ちしております。

株式会社エニグモ 正社員の求人一覧

hrmos.co