Amazon S3 path-style 廃止予定 – それから先の話 –

先週(4/30)、私たちは非常に静かな（実際には静かすぎる）発表を行いました。S3 バケット内のオブジェクトのアドレスを指定するために使用される、パスベースのアクセスモデルについて、ゆっくりとそして慎重に廃止するという計画です。私はこのブログ記事を書くために、状況をよりよく理解すべく、S3チームと話し合うことに時間を費やしました。私が学んだことは以下です…

S3 は、2006年の始めにサービスが開始されました。S3 における Jeff Bezosの考える元々の仕様は、非常に簡素なものでした。彼はインターネットにおける malloc （C言語プログラムにおけるキーメモリ割り当て関数）に相当するようなものを望んでいました。その出発点から、S3 は何兆ものオブジェクトを格納し、毎秒数百万のリクエストを処理するところまでに成長しました。 13年間にわたり、S3 には多くの新しいストレージオプション、機能、およびセキュリティ制御が追加されました。

Old vs. New
S3は現在、2種類のアドレスモデルを提供しています。path-style と virtual-hosted styleです。一つずつ見てみましょう。まず、path-style モデルでは、次のように見えます（グローバルなS3エンドポイントです）:

https://s3.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg
https://s3.amazonaws.com/jsb-public/classic_amazon_door_desk.png

もしくは、次のような形です（リージョナルなS3エンドポイントです）:

https://s3-us-east-2.amazonaws.com/jbarr-public/images/ritchie_and_thompson_pdp11.jpeg
https://s3-us-east-2.amazonaws.com/jsb-public/classic_amazon_door_desk.png

この例では、jbarr-public と jsb-public がバケット名であり、/images/ritchie_and_thompson_pdp11.jpeg と /jsb-public/classic_amazon_door_desk.png がオブジェクトキーとなります。

仮に、オブジェクトが別々の AWS アカウントによって所有されたり、異なる S3 バケット（また場合によっては異なる AWS リージョン）にあったとしても、どちらも同じ DNS サブドメイン s3.amazonaws.com にあります。次に、対応する virtual-hosted style の参照方法を見てみましょう（これらは「新しい」と思われるかもしれませんが、少なくとも2010 年以降に存在しています）:

https://jbarr-public.s3.amazonaws.com/images/ritchie_and_thompson_pdp11.jpeg
https://jsb-public.s3.amazonaws.com/classic_amazon_door_desk.png

これらの URL は同じオブジェクトを参照しますが、オブジェクトは別々の DNS サブドメインにあります (それぞれ jbarr-public.s3.amazonaws.com と jsb-public.s3.amazonaws.com)。これらの違いは微妙ですが、非常に重要です。一般に、URL を使用してオブジェクトを参照する場合、DNS の名前解決を使用してサブドメイン名を IP アドレスにマッピングします。path-style のモデルでは、サブドメインは常に s3.amazonaws.com またはリージョナルなエンドポイント1つとなる一方で、virtual-hosted style ではサブドメインはバケットに対して固有です。この追加されたもう一つのエンドポイントの特定方法は、S3 における多くの改善への扉を開くための重要な鍵です。

Out with the Old
先週(4/30)お知らせした、元の廃止予定に関していただいたフィードバックに応じて、重要な変更を行っています。概要としては次のとおりです:

元のプラン — path-style モデルのサポートは、2020 年 9 月 30 日に終了します。

改訂プラン — path-style モデルのサポートは、2020 年 9 月 30 日以前に作成されたバケットに対しては引き続き行われます。その日付以降に作成されたバケットについては、virtual-hosted モデルを使用して参照する必要があります。

私たちは、次の2つの理由から、virtual-hosted の参照方法に移行しています:

第一に、まず数十億のバケットが多数のリージョンに作成されることを予測し、すべての受け入れ側リクエストについて複数のエンドポイントのセットをコンパクトにし、直接ルーティングすることで時間の経過とともにその重みを下げています。現在の集中型モデルでは、DNS 解決、スケーリング、セキュリティ管理、トラフィック管理（DDoS 保護を含む）は、より困難になってきています。virtual-hosted モデルは、問題が発生した場合の影響範囲（内部的には「Blast Radius」と呼びます）を小さくできます。これにより、可用性とパフォーマンスの向上に役立ちます。

第二に、S3 チームは、現在進行形で多くの強力な機能を実装しており、その多くは、virtual-hosted style のサブドメインの利用に依存しています。このモデルに移行しておくことで、新機能が発表されるとすぐに、それらの機能の恩恵を受けることができます。たとえば、最も古いセキュリティ暗号とバージョンの一部を廃止する予定です（詳細はまた）。virtual-hosted の参照方法を使用していただけると、この廃止プロセスが（あなたと私たちのために）より簡単でスムーズになるのです。

In With the New
virtual-hosted の参照方法を使用する場合に可能になる機能の一例としては、各バケットのセキュリティ設定（暗号と暗号バージョンを含む）の制御を強化することを検討しています。 皆さまのご自分のアイデアがある場合は、お気軽に連絡ください。

Moving Ahead
私たちの計画について知っておくべきことがいくつかあります:

path-style の参照方法の特定 — S3 アクセスログ（Host Headerフィールドに着眼します）と AWS CloudTrail データイベント（requestParameters エントリの host 要素に着眼します）を利用して、path-style のリクエストを行うアプリケーションを特定できます。

プログラムによるアクセス — アプリケーションが AWS SDK の1つを使用して S3 にアクセスする場合は、SDK が最新であることを確認していただければ、他に何も行う必要はありません。 SDK は、バケット名に1つ以上の「.」文字が含まれている場合を除き、S3 へのアクセスには、virtual-hosted の参照方法を既に使用しています。

ドット「.」付きバケット名 —「.」文字を含むバケット名は、ウェブサイトホスティングやその他のユースケースで有益です。しかし、TLS および SSL 証明書にはいくつかの既知の問題があります。これらのバケットに対して、virtual-hosted の参照方法をサポートできる方法がないか、現在懸命に取り組んでおります。2020年9月30日より前には、詳細を共有する予定です。

ルーティング不可能な名前 — URL のパスを構成する要素で有効な一部の文字は、ドメイン名の一部としては有効ではないものがあります。また、パスでは大文字と小文字が区別されますが、ドメイン名とサブドメイン名では区別されません。 昨年(2018年)以降、新しく作成するバケット名に対しては、より厳格なルールを適用しています。 バケット内にルーティング不可能な名前のデータがあり、virtual-hosted のリクエスト方式に切り替えたい場合は、新しい S3 バッチオペレーション機能を使用したデータ移動を検討いただけます。それでも、もしこれが実行可能なオプションでない場合は、AWS 開発者サポートにお問い合わせください。

ドキュメント — S3 ドキュメントを更新する予定であり、すべての開発者に virtual-hosted のリクエストを利用するようなアプリケーション構築を誘導する方向です。Virtual Hosting of Buckets のドキュメントは良い出発点となります。

We’re Here to Help
S3 チームは、一部のお客様と協力して移行を支援しており、さらに多くのお客様と協力する準備が整いつつあります。

私たちの目標は、この廃止予定をスムーズかつ平穏無事に進めることであり、発生しうるコストを可能な限り最小限に抑えるためのお手伝いしたいと考えています。ご質問、課題、懸念がある場合は、お気軽にお問い合わせください。

– Jeff;

追伸 – その他のリソースの詳細については、お待ちください。

（翻訳は SA 焼尾が担当しました。原文はこちらです。）