アクセス集中への対応とパーソナライズ要求の両立目指し、Cookie処理をエッジにオフロード

「BUYMA」で「Akamai EdgeWorkers」早期採用、エニグモが語る評価

2021年06月21日 07時00分更新

文● 大塚昭彦／TECH.ASCII.jp

「3つの必須要件」を満たすAkamaiを採用、EdgeWorkersも導入決定

　アクセス集中への対応として、BUYMAではこれまでのように静的コンテンツ（画像、JavaScript、CSSなど）だけでなく、HTMLやAPIといった動的コンテンツについてもCDNを介して配信することにした。ただし、サービスのパーソナライズやプライバシー保護対策も実現する必要があるため、利用するCDNサービスには「3つの必須要件」が定められた。

　「1つめは『レスポンスがパーソナライズ可能』であること。2つめは『エッジアクセスデータと自社DWHの連携が可能』であること。これまではオリジンのログをDWHに連携することでユーザーのサイト内行動を捕捉していたが、（CDN環境下で）同じことを維持するためにはエッジのアクセスデータをDWHに連携できなければならない」

CDNの適用範囲を動的コンテンツにも拡大するうえで掲げた「3つの必須要件」

　そして3つめの必須要件が「ファーストパーティCookie操作をエッジへ移行可能」というものだ。BUYMAではこれまで、ファーストパーティCookieを使ってサイト流入元、訪問日時、長期トラッキング用のIDといったデータを保存して、UXのパーソナライズやマーケティング効果測定を実現してきた。この「BUYMAにとってパーソナライズの要」（木村氏）となっている仕組みも、エッジに移行できる必要があった。

　「BUYMAでは当初、そうしたCookie操作をJavaScriptのAPI（Document.cookie）で行っていた。だが2019年、アップルがiOS/macOSでITP 2.1仕様のSafariブラウザを導入し、JavaScriptで作成するCookieの有効期限が最大7日に制限された。そこでわれわれは、Cookie操作をオリジンのアプリケーション側に移し、Set-CookieヘッダでCookieを操作するように変更した。（この仕組みを維持するため）今回のCDN導入においては、キャッシュヒット時にはエッジサーバーからCookieを操作する必要性が出てきた」

BUYMAにおけるCookie処理の変遷。ブラウザでのプライバシー保護対策に対応するため処理をサーバーサイドに移していたが、今回はその処理をエッジでもできるようにした

　こうした3つの必須要件を満たすCDNサービスを検討し、最終的には以前から静的コンテンツ配信に利用してきたAkamaiを採用することに決めた。そして、エッジでのCookie操作については、EdgeWorkersで実装することとなった。

　「実は、競合のCDNサービスでも3つの要件を満たすものはあった。ただしわれわれとしては、すでに静的コンテンツ配信で利用しており、実績もあるAkamaiを使いたかった。そこで、Akamaiに『こういうエッジコンピューティングの機能はないか』と問い合わせたところ、EdgeWorkersを紹介してくれた。これで採用に至ったというのが実際のところ」

木村氏が挙げた、BUYMAにおけるAkamai（CDN＋EdgeWorkers）の採用理由

「とっかかりは非常に簡単」な開発、本番運用では改善点も指摘

　EdgeWorkersは、ユーザーがJavaScriptで開発したロジック（ファンクション）をエッジサーバー上で実行してくれる、サーバーレス型のエッジコンピューティングサービスだ。

　ロジックの開発について、木村氏は「EdgeWorkersへの最初のとっかかりは非常に簡単だった」と評価する。AkamaiのWebコンソールである「Akamai Control Center」から利用できること、開発者はイベントハンドラのファンクションを実装するだけでよいこと、Cookie操作やURLのパースについてはライブラリが標準で用意されており、さらにサードパーティモジュールをバンドルすることもできることなど、を説明した。

　「注意点としては、ブラウザJavaScriptのコードはそのままでは動かないこと。当然と言えば当然だが、やはり書き換える必要があった。たとえばBase64エンコード／デコードについては、ブラウザコードのファンクションが使えないため、サードパーティモジュールを呼び出して処理している」

　開発時のデバッグ方法については、ログ出力をレスポンスヘッダに埋め込んで確認できる「enhanced debug headers」機能を利用しつつ、ステージング環境へのアップロードとアクティベートを繰り返しながらプリントデバッグを行った。Akamaiではローカルサンドボックスを提供しているが、それがうまく使えず、ブラックフライデーが差し迫っていて問い合わせる時間もなかったため、今回はそういう手段をとったと説明する。

　本番運用における評価として、まず「実行時間的なパフォーマンスは非常に良い」と語った。「UX上ではレイテンシを感じさせないレベル」でエッジ処理ができているという。

　その一方で、本番環境におけるトラブルシューティング時には「ログ調査に課題がある」と指摘した。現状ではログ取得に「Log Delivery Service」を使う必要があったが、データが届くのが次の日などになってしまうため、トラブルシューティングに時間を要する状態だった。他社のFaaSではリアルタイムに近いかたちで、Webからログが検索、分析できるので、「今後はそうした機能が提供されることを期待したい」と語る。

「本番環境での平均実行時間は0.24ミリ秒で、UXに影響を与えない処理時間」（木村氏）。一方で、現状ではログ取得に時間がかかる点が課題だと指摘した

「エッジへのオフロードをよりアグレッシブに進めたい」

　EdgeWorkersの今後の活用案として、木村氏は、エッジへの負荷のオフロードを「よりアグレッシブに（積極的に）」進めていきたいと話した。

　「これまで、オリジン側の負荷をオフロードする方法としてキャッシュだけを用いてきたが、EdgeWorkersによってオリジンのロジック自体をエッジへマイグレーションして、よりアグレッシブなオフロードが可能になった。今回のCookie操作に限らず、分散処理可能なものはEdgeWorkersに移行して、よりオリジン側の負荷を減らしたい」

　もうひとつ、これまでオリジン側の負荷が制約となって諦めていたパーソナライズ施策も、EdgeWorkersを使えば「工夫次第で実現できそうなものもある」と語り、BUYMAのパーソナライズ機能をさらに拡張していきたいと抱負を語った。

　一方で、EdgeWorkersで今後さらなる改善を期待する点については、「開発者体験のさらなる向上」を挙げた。具体的には、前述したログ監視／管理ツールの提供のほか、サードパーティの監視SaaSとのAPI連携機能、分散キーバリューストア「Akamai EdgeKV」の自社DWHへの連携などだという。

　「現状の機能では、Cookie操作のようなライトな使い方が限界かなという印象もある。（上述したような）これらの機能が揃うことで、ある程度複雑な処理も書けるようになり、マイクロサービスをエッジ上で構築するようなディープな活用もできるのではないかと考えている。ぜひ、こうした機能強化に取り組んでいただきたい」