🌏

【Maps APIの裏側】パフォーマンス最適化~AWS re:Invent 2022 セッション紹介~

2022/12/19に公開

AWS

この記事はMapbox Advent Calendar 2022の記事です。

筆者はMapboxの広告配信プラットフォームを作っているインフラ&データエンジニアです。普段はCDKでAWS上でインフラを構築したり、EKS上にデータ提供APIを作ったりしています。

概要

2022/11/29~12/2にUSのLas Vegasで開催されたAWS re:Invent 2022に参加してきました。

弊社のDirector of Maps APIsのBlake Tompsonが'Optimizing performance with CloudFront: Every millisecond matters'というタイトルで発表したので、その内容について紹介します。

AWSのCloudFrontを活用したMaps APIのパフォーマンス最適化の話になります。

Optimizing performance with CloudFront

前段:4つの柱

パフォーマンスを向上させるためには4つの柱があります。MapboxのMaps APIはこれらの柱に基づいて、パフォーマンスの最適化を行っています。

可用性(Availability)
最適化(Performance)
エッジコンピューティングの利用(Edge compute)
効果的なモニタリング(Effective monitoring)

1.キャッシュの利用

CloudFrontは、静的コンテンツのキャッシュはもちろん、動的コンテンツのキャッシュも可能です。ただし、一歩間違えると古いコンテンツをユーザーに提供してしまう恐れがありますので注意が必要です。必要な時にOriginから最新のコンテンツを取得し、そうでないときはキャッシュを利用するように、Cache Policyを設定します。

具体的には、HTTP Headerに含まれている国や郵便番号やある特定のcookieを利用して、キャッシュを利用するかしないかを定義しています。

キャッシュポリシーを正しく設定することで、MapboxのMaps APIへのリクエストの40%はキャッシュで処理することに成功しています。（正確には、HTTPステータスコードの304を返却し、Clientはダウンロード済みのデータを利用する。）
詳細はAWSのドキュメント（ポリシーの使用）をご参照下さい。

2.Origin Shieldの使用

Mapboxのユーザーは複数リージョンに分散しています。通常では、リージョン間ではキャッシュは共有されません。そのため、同じ内容のリクエストが複数のリージョンから送られてきた場合、Originに複数リクエストが転送されます。それを防ぐために、Origin Shieldを利用しています。

Origin Shiled未使用	Origin Shiled使用

Origin Shieldを利用すると、全リージョンのリクエストがOrigin ShieldのCloudFrontを通過するようになるため、Originにはリクエストが1回しか送信されないようになります。Origin Shiledの詳細については、AWSのドキュメント（Amazon CloudFront Origin Shield の使用）をご参照下さい。

3.TLS 1.3の利用

TLS1.2ではTLSハンドシェイクを完了するために2回のラウンドトリップが必要でしたが、TLS1.3では1回のみです。そのため、TLS1.3ではTLS1.2と比較して高速です。また、TLS 1.3ではTLS1.2において安全性が低いとされた旧式の機能を削除しているため、よりセキュアです。

4.Brotliでの圧縮

CloudFrontを使用して特定のタイプのファイルを自動的に圧縮し、その圧縮オブジェクトを供給できます。ビューワーがGzipとBrotliの両方をサポートしている場合、CloudFrontではBrotliが優先されます。なお、BrotliはGoogle が開発したオープンソースの圧縮アルゴリズムです。

Mapboxでは、この機能を用いて8%のBandwidthの削減に成功しています。通常のWebアプリケーションの場合は、より大幅な改善が期待できます。（Mapboxは元々Binaryのファイルを利用しているのため、圧縮率が小さい）
詳細はAWSのドキュメント（CloudFront 圧縮の仕組み）をご参照下さい。