エンジニアの木村です。最近は負荷対策のためのリファクタリング やリアーキテクティングのリードや、データ基盤・ML・検索基盤を担当するチームのマネージャーとしてデータ関連の案件に携わっております。
先週、webinar 形式で行われた Akamai TechWeek 2021 Japan にて、6/16 に「EdgeWorkersの導入について」というテーマで、昨年末にバイマに導入したEdgeWorkersというAkamai のサービスについて講演しました。本ブログでもその内容を共有したいと思います。
スライドはこちらになります。
エッジコンピューティング導入の背景
導入背景としては、アクセス集中下でもサービス自身のドメイン を通じて自らユーザーを追跡し、ファーストパーティデータを収集する必要性という事業課題がありました。
アクセス集中を伴うマーケティング 施策への対応
事業課題の１つとして、モバイルへのプッシュ通知と、フラッシュセール施策という、いずれもアクセスの集中を引き起こすマーケティング 施策へサービスとして対応していく必要がありました。
まず、モバイルへのプッシュ通知が増加しているのですが、その背景には時代やサービスの成長フェーズの移り変わりがあります。マスマーケティング からOne to Oneマーケティング へと、我々の注力ポイントが変わってきているからです。実際、以前は認知を広げて新規顧客を獲得するためにTVCMによるマスキャンペーンを展開し、当時はアクセス集中といえばTVCMの放映起因がほとんどでした。最近は既存顧客一人一人に対してパーソナライズ した通知を送ってリテンションを図る施策が増えています。モバイルアプリをインストールしているユーザーやLINEのバイマ公式アカウントと連携しているユーザーはサービスへのロイヤリティが高く、通知の開封 率も高いので特に一斉に送信するような通知ではTVCM放映以上のアクセス集中が生まれています。
フラッシュセールとは、ブラックフライデー ・サイバーマンデー などのセール施策のことです。期間や商品の在庫も限定した形で行われ、また先程のプッシュ通知により開始が通知されるのでアクセスの集中が発生します。毎年性能改善を重ねてはいたのですが、スケールが難しいオンプレのインフラを使っているサービスのところでは対策に限界があったのと、年々増加していくユーザー数に追いつかない状況で、毎年このセールの開始直後はサイトのパフォーマンスが不安定になっていました。
パーソナライズとプライバシー保護の両立
直面していた事業課題の２つ目は、プライバシー保護とパーソナライズの両立です。
パーソナライズ についてですが、最近はレコメンドなどに代表されるパーソナライズ されたUXへの期待が高まっています。北米やイギリスの消費者を対象にした2019年の調査*1 では、63%の消費者がサービスの標準としてパーソナライズ を期待しているそうです。また、自分だけの特別なオファーが送られてきたり、サービスとの各接点で一人の同一の顧客として認識されることで一人の個人として扱われていると感じるそうです。したがって、サイトのUXだけでなく、マーケティング 施策にもパーソナライズ が求められています。さらに、そういったUX改善やマーケティング 施策の効果測定でも、施策による単純なKPIの動きだけでなく、ユーザーを一人一人区別して分析し、どのような属性の顧客に効いているのかといった高い解像度での分析が求められています。
また、ユーザーはパーソナライズ を期待している一方で、プライバシーの保護についての意識も高まっていて、個人データの収集に関して透明性が求められています。それに答えるように、Safari やChrome といったメジャーなブラウザでブラウザフィンガープリントやサードパーティ クッキー、クライアントサイドクッキーは何らかの制限や規制、あるいは廃止される予定になっています。これにより、ユーザーを追跡する手段としては、サービス自身のドメイン を使ってのファーストパーティクッキーだけが残され、そのクッキーを通じて収集されるファーストパーティデータの重要性が増してきています*2 。
エッジコンピューティングの導入理由
そういった背景から、なぜエッジコンピューティングの導入に至ったのかをお話しします。
CDN 導入のための必須要件背景にあったアクセスの集中に対応するために、それまで画像・js・css といった静的コンテンツのみで多なっていたCDN での配信を、Webアプリから返しているHTMLやAPI という動的コンテンツの配信にも導入することになりました。また、これも背景で説明したパーソナライズ やデータ収集の必要性から、CDN を選定するにあたり以下の３つの必須要件を定めました。
レスポンスをパーソナライズ可能
エッジアクセスデータと自社DWHの連携が可能
ファーストパーティCookie 操作をエッジへ移行可能
１つ目はレスポンスをパーソナライズ可能性、つまりキャッシュするコンテンツをユーザーによって分けたりが可能かどうかです。２つ目はエッジアクセスデータと自社DWHの連携が可能かという点です。それまではオリジンのWebサーバーのログをDWHへ連携することでユーザーのサイト内の行動を分析していたのですが、キャッシュされるコンテンツに関してはオリジン側へログが残らなくなるため、分析のためにエッジのアクセスデータを自社DWHへ連携する必要があります。３つ目ですが、バイマでは未ログインでセッションを張っていないユーザーも追跡可能にするためにファーストパーティcookie を利用していて、これによりUXのパーソナライズやマーケティング 施策の効果計測を実現しています。そのCookie の操作処理をエッジへ移行する必要がありました。
ITP2.1 への対応
Cookie 操作処理のエッジへ移行する必要性の経緯としては、ITP 2.1 への対応というのがあります。
Cookie の操作処理の変遷Cookie の操作をJavaScript のAPI であるDocument.cookie で行っていたのですが、2019年にApple によってブラウザのJavascript で作成するCookie の有効期限は最大7日に制限するというITP 2.1のSafari への導入 がアナウンスされました。バイマではiOS のSafari のユーザーが大半を占めるので、我々はそれまでブラウザのJavascript で行っていたCookie の操作をオリジンのアプリケーションサーバ ー側へ移行し、Set-Cookie ヘッダーによりcookie を操作するように修正を行いました。今回のCDN の導入の際は、キャッシュヒット時にもSet-Cookie ヘッダを返すことでCookie を操作する必要性がでてきます。したがって、ファーストパーティCookie の操作処理をエッジサーバー側へ移行する必要性がありました。
Akamai EdgeWorkers を採用いくつかのCDN サービスからAkamai を選んだ理由としては、上述の必須要件を満たしていたという点がありました。プロパティだけでもかなり柔軟なルール設定が可能で、それだけでもある程度パーソナライズは実現可能でした。また、DataStream 2 というサービスにいよりエッジのアクセスデータをリアルタイムに近い形で、Google のBigQuery上で構築している自社のDWHへデータ連携が可能でした。さらに、EdgeWorkersによりCookie 操作をエッジサーバー上への移行が可能という点で必須要件を全て満たすことができました。
また、すでにスタティックコンテンツの配信では既に導入実績があったという点も採用への後押しになりました。実は、この３つの必須要件のパーソナライズ、データ連携、エッジコンピューティングの機能については、他の競合CDN サービスも提供されています。ただ我々としては利用に慣れていて信頼のあるAkamai を使いたかったので、逆にこちらからエッジコンピューティングの機能について問い合わせたところ、EdgeWorkersを提案いただき採用に至りました。
EdgeWorkers の開発・運用
EdgeWorkersでどのように開発をすすめたのかや、実際の運用状況について紹介します。
利用開始は簡単
最初のEdgeWorkersへのとっかかりは簡単でした。すでにAkamai をお使いの方にはお馴染みのWebコンソール「Control Center」から利用可能です。実装も簡単で、開発者はイベントハンドラ のファンクションを実装するだけになります。今回クライアントへのレスポンスするタイミングで呼ばれる onClientResponse を実装しました。Web UI上でコーディング、アクティベートも可能だったので、チュートリアル としてのHello World を動かすところまでは1日で到達できました。
ライブラリも利用可能
利用できるライブラリについてですが、cookie 操作やURLのパースなどは標準で組み込まれいているモジュールで十分可能でした。また、rollup.jsというJavaScript のモジュールバンドラーにより標準組み込みでない、npmリポジトリ で公開されているサードパーティ 製モジュールもbundle可能でした。１点だけ注意というか、当然ではあるのですが、ブラウザJavaScript のコードをそのまま移植しようとしても動かなかったです。元々はブラウザJavaScript でCookie を操作していたロジックはあったのですが、書き換える必要はありました。さらに細かいところで言うと、ブラウザだとwindowのオブジェクトにatobやbtoaというbase64 エンコーディング ・デコーディングをしてくれるfunctionが付いてるんですが、それは使えず、代わりにrollup.jsでbase64 エンコーディング を行う3rdパーティモジュールをbundleして呼び出して使っています。
開発時のデバッグ 方法ですが、ログ出力をレスポンスヘッダに埋め込んで確認できるenhancend debug headerを利用し、ステージングへアップロード＆アクティベートを繰り返しながらのプリントデバッグ で切り抜けました。本当はakamai のCLI でローカルにSandboxを構築して利用する方法もあるのですが、その構築が手順通りにやってもうまくいかず、ブラックフライデー が差し迫っていたこともあり、問い合わせる余裕すらなかったので、実環境のステージングでの開発となりました。ただステージングへのアクティベートは毎回許容範囲内の時間で終わってくれるので、このやり方でも開発は可能でした。手順通りにやってうまくいかないという点なのですが、ある程度経験のあるメンバーが二人がトライして、二人ともSandbox構築にハマっていたので、ドキュメントに関しては何らかの改善の余地はありそうです。昨年末の話なので、既に改善されているかもしれないですが、期待とフィードバックの意味も込めて、ここで苦労したエピソードとして紹介させていただきます。
開発時の参考リソース
開発時に参考にしたリソースとしては、ユーザーガイド もあるのですが、他にもGitHubのリポジトリ にexampleが公開されていて、先行事例があまりない段階での利用だったので、開発時にはそれが大変助かりました。ブログ にも参考になりそうな記事があります。ユースケース の紹介もありますし、Github ActionsでCICDを実現するような事例も載っていて、デベロッパ ーフレンドリーにできてるなと思いました。
本番運用してみて
実際に本番運用してみている状況についてですが、実行時間的なパフォーマンスは非常に良いです。エッジでなにか処理を行っていてもUX上はなにもレイテンシを感じないレベルを維持できています。
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
