エッジコンピューティングの新たなユースケース

簡単に聞こえるかもしれませんが、このデータを取得するために、Web アプリケーションを何度も呼び出さなくてはなりません。ユーザーがアプリにアクセスすると、ジオロケーションマイクロサービスによってアプリの表示内容がフィルタリングされます。こうした呼び出しがレイテンシーを増加させることが課題となっていました。ジオロケーションマイクロサービスによって、ページの読み込みは 500 ミリ秒～2 秒遅くなりました。そのマイクロサービスを Akamai EdgeWorkers に移行したところ、ラウンド・トリップ・タイムを 99% 短縮できたのです。現在、マイクロサービスはジオロケーションデータを 20 ミリ秒で返しています。

EdgeWorkers は、Cookie を介してエッジでジオロケーションデータを挿入します。それを可能にするのはリクエストヘッダーへの地域データの追加です。これにより、2 つの面で無駄を省くことができます。まず、ジオロケーションデータを取得するための最初のラウンドトリップが不要になります。次に、地域に関する付加的な情報を取得するための別のリクエストが不要になります。その結果、アプリケーションの処理効率が高くなります。クラウドの呼び出し回数が減少したため、応答時間が短縮され、クラウドコストも削減されました。この Cookie ベースの例はこちらでご確認いただけます。また、個別にジオロケーションサービスを呼び出しても同様の処理が可能です。

人をどのようにして特定するか：パーソナライズの強化

検索エンジンの最適化は、目に見えにくい技術です。たいていの場合、誤解され、悪者扱いされます。北米で事業を展開するスポーツ用品の小売企業は、SEO とパフォーマンスのバランスをとるのに苦労していました。目標を 2 つ立て、検索エンジンでの成功と、クラウドインフラのコスト削減を目指していました。 

多くの B2C 企業と同様に、その企業もパーソナライズを通じて顧客を引き付け、維持しています。マーケティングキャンペーンを実施する際は、UTM コードを含む個別の URL を使用して追跡と分析を行います。プロモーションメールのリンクをたどったときに「?utm_source=blog&utm_medium=email&utm_campaign=member」という文字列に気づいた方もいるかもしれません。こうした URL コードはマーケティング担当者には有益ですが、キャッシュパフォーマンスの面ではおすすめできません。有効なマーケティング情報を得るためには、すべての URL を別々にする必要があります。一方で、キャッシュパフォーマンスを最適化するためには、一貫性のある URL が求められます。そして、ユーザーの関心を維持するためには、速やかなページ読み込みが不可欠です。 

この問題に対処するため、このお客様は JavaScript 関数を作成してヒット率の向上を図りました。関数が制御するのはキャッシュキーであり、UTM コードは無視します。例えば「www.retailer.com/offers/promo_page?utm_source=blog&utm_medium=email&utm_campaign=member」という URL は「www.retailer.com/offers/promo_page」としてヒットします。これによりキャッシュのヒット率が向上します。その後、関数は UTM コードを再び追加するので、ユーザーのふるまい分析は維持されます。このユースケースの詳細は、こちらのブログ投稿でご確認いただけます。

ピープルベースド・マーケティング・プラットフォームでも同じようなことが起こりました。その企業のプロモーションメールには多くのコンテキスト属性が含まれており、カスタマイズされたコンテンツを配信しています。マーケティングプラットフォームのアーキテクチャでは、異なるクラウド・プロバイダー・プラットフォームに存在するさまざまなマイクロサービスが使用されています。メールの属性が、リクエストをルーティングする場所と返されるコンテンツを決定します。このロジックを Akamai EdgeWorkers に移行した結果、URL はエッジでデコードされ、ルーティングされるようになりました。これに伴い、ユーザーに対する応答性が向上し、コンテンツの配信元に対する余計なリクエストが減ります。

プライバシーの尊重：規制の遵守

GDPR、CCPA、APPI およびその他のユーザープライバシーに関する法律によって、コンプライアンスへの取り組みが脚光を浴びています。世界中の企業が、コンプライアンスへの取り組みを強化し、罰則を回避しようとしています。あるグローバルなメディア測定・分析会社は、ユーザーコンテンツを管理する必要がありました。最初の課題は、同社パブリッシャー部門のユーザーの同意データを追跡することでした。

その企業が採用していたのは、ユーザーの同意の送信および確認で業界標準となっている、Interactive Advertising Bureau（IAB）の Transparency and Consent Framework（TCF 2.0）でした。アクティビティを追跡するために、ユーザーの同意を追跡するマイクロサービスを設計しました。Akamai EdgeWorkers によって、同社はエッジネイティブのマイクロサービスを構築できました。ユーザーがトラッキングに同意すると、ステートトラッキングの Cookie がセッションに追加されます。これにより、同社はユーザー体験をパーソナライズすることができます。ユーザーが同意しない場合、Cookie は破棄され、ユーザーには一般的な体験が提供されます。このブログ投稿では、詳細情報に加えてソースコードへのリンクもご紹介しています。

世界中を飛び回る：乗り継ぎ便はいつ出発？

飛行機に乗るときに、こんな経験をしたことはありませんか？フライトの予定時刻を確認します。航空会社のアプリをダウンロードして、通知を受け取ります。フライトトラッカーや空港の Web サイトで念のためチェックします。空港に到着したら、スクリーンでフライトと搭乗ゲートの情報を確認します。搭乗ゲートに着いたら、端末で最新情報を確認します。すると、それまでとは異なる情報が表示されていることが、ままあります。

航空会社は、重要なデータの送信と同期に関して多くの課題を抱えています。インターネットとネットワークの速度に常に一定というわけではないため、リアルタイムのデータ調整は困難です。フライト状況に関する情報が矛盾していると、乗客は混乱し、カスタマーサービスに多くの労力を割かなくてはなりません。より正確でタイムリーな情報を配信できれば、顧客満足度は向上し、コストも削減できます。

Akamai は、この問題の解決について世界規模のある航空会社から相談を受けました。通常の Web アプリケーションではデータ同期の課題を解決できないことは明らかでした。同期するアプリケーションが多すぎるからです。また、Web アプリケーションは、スケジュールに従って（またはイベントに応じて）情報をリクエストして、最新の状態を維持します。例えば、スマートフォンのメールクライアントの設定を思い浮かべてください。メッセージ配信の設定にはプル型とプッシュ型があります。プル型は、スマートフォンのアプリに対して、メールサーバーに最新情報をリクエストするように指示します。プッシュ型は、メールサーバーに対して、ユーザーに情報を送信するように指示します。どれくらいの頻度で新しいメールを受信したいかに応じて、プッシュまたはプルのタイミングを設定します。フライト情報で問題となるのは、アプリケーションの数です。モバイルアプリ、空港のスクリーン、Web サイト、搭乗ゲートの端末は、それぞれ異なる間隔で、プル型の情報更新を行います。そのため、フライトの遅延もアプリケーションごとに異なるタイミングで表示されます。 

この航空会社は、グローバルなフライト情報を同期するために Akamai Edge Cloud を採用しました。Edge Cloud で使用されるのは、Message Queuing Telemetry Transport（MQTT）であり、HTTP のような Web アプリケーションではありません。MQTT によって、パブリッシャーとサブスクライバーの通信が可能になります。その結果、3 つの主要なメリットが得られます。

1. メッセージのサイズが小さくなり、より高速で信頼性の高い配信が可能になります。
2. 情報は既知のサブスクライバーにのみ送信されるため、安全性が高まります。
3. フライト情報を表示するすべてのデバイスが、同時に情報を受信します。

Edge Cloud は、信頼性の高い自動メッセージ配信と通知をリアルタイムに実現します。詳細については、Edge Cloud に関するこのブログ投稿をご覧ください。

また、コードの例をさらにお探しの方のために、すぐに利用できる GitHub リポジトリでさまざまなユースケースを公開しています。