こんにちは😺
カスタマーサクセス部の山本です。

AWS Summit Tokyo 2024 に行ってきました。
普段は富士五湖の近くに住んでいるため、久々に現地で同業の AWS エンジニアの方たちとお話することができ、有意義な時間になりました。
セッションのスピーカーの方に直接話しかけることができる場所もあり、家で動画を見るよりも、発表内容への理解が非常に深まりました。
同じような興味を持っている人がいることを確認でき、モチベーションも上がりました。
張り切って 1 日目に 9 セッションも受講して、帰り道に頭が熱くなっていて、夜は良く寝れました。
参加の目的は以下でした。

支援中の顧客に提供できる技術情報を持ち帰ること
今後の提案に向けて、知らない領域の技術に触れて知識の幅を広げること

結果的にどちらも達成でき、充実した２日間になりました。

印象に残ったセッションの中から、印象に残った内容をピックアップして記事に書き起こしていきます。
本記事では１日目のセッションについて書いていきます。

参考：２日目のレポートです。
- AWS Summit Tokyo 2024 レポート２日目セッション：Amazon Aurora の技術とイノベーションDeep dive（前半） - サーバーワークスエンジニアブログ
- AWS Summit Tokyo 2024 レポート２日目セッション：Amazon Aurora の技術とイノベーションDeep dive（後半） - サーバーワークスエンジニアブログ

参加したのは、Level 300 〜 400 の上級・エキスパートセッションが中心となります。
参考：レベルについての説明
ある程度 AWS のサービスに精通している人向けのセッションになります。
入門系の資料をお探しの場合は、サービス別資料にあります。
たとえば検索欄に "S3" と入力し検索すると、「Amazon Simple Storage Service (S3)」という資料が見つかると思います。このように、サービスの正式名称を表題に記した資料が、概要を網羅的に説明しています。入門系の資料としてご参照してみてください。

例：

Youtube で見るほうが音声でしか聞けない情報があるため、お勧めです。入門系の資料を見て、ある程度実際にサービスを触ると、個人差はあるものの、Level 300 〜 400 のセッションが理解できると思います。

AWS Summit Tokyo 2024 のセッションは 7/5 までオンデマンド配信中のようです。登録してログインすると見ることができます。
aws.amazon.com

目次
Dive deep on Amazon S3 （Level 300 : 中級者向け）by アマゾンウェブサービスジャパン合同会社
- 「インデックス ( key / value )の理解」
  - apple , banana , melon のプレフィックスがある場合、ない場合の比較
  - インデックスに関する公式ドキュメントでの記載
- 「インデックス ( key / value )の理解」以外の部分に関するメモです。
  - ストレージクラス「Amazon S3 Express One Zone」
まとめ
余談

Dive deep on Amazon S3 （Level 300 : 中級者向け）by アマゾンウェブサービスジャパン合同会社

スピーカーは S3 の Black Belt でもおなじみの、焼尾徹さん（シニアストレージスペシャリストソリューションアーキテクト）です。
本セッションの動画等が Youtbe などにアップロードされた際には、本記事にも URL を掲載する予定です。

PDF の資料は出してくれたみたいです。@ 6/26
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-01_Storage_AWS_Summit_JP_2024.pdf

7/5 までオンデマンド配信中の URL です。※登録（無料）とログインが必要です。
japansummit.awslivestream.com

S3 のパフォーマンスを最大化することと、比較的新しいストレージクラスの「Express One Zone IA」について説明をしていました。
re:Invent 2023 のセッション、「AWS re:Invent 2023 - Dive deep on Amazon S3 (STG314)」の日本語版と言ったところでしょうか。

参考：
www.youtube.com

Dive deep on Amazon S3

現在 S3 は全世界で、350兆オブジェクトを格納しているとのことでした。1 秒あたり 1 億以上のオブジェクトを格納しているそうです。

「インデックス ( key / value )の理解」

この部分が印象に残ったので、具体的に取り上げます。
例として、S3 バケットを１つ作成し、バケットの中に apple , banana , melon のフォルダーを作成したとします。
このフォルダーを「プレフィックス」と呼びます。

AWS CLI を使って、aws s3 ls <バケット名> と実行すると、PRE と表示します。プレフィックスのことでしょう。

プレフィックス apple の中には、年月日（YYYY/MM/DD）のプレフィックスがそれぞれあり、最後にapple.txt というオブジェクトがあります。

AWS CLI を使って、aws s3 ls <バケット名>/apple/YYYY/MM/DD/ と実行すると、apple.txt オブジェクトを表示します。

同様に、banana.txt や melon.txt もそれぞれのプレフィックスに存在します。

apple.txt、banana.txt、melon.txt それぞれには以下のプレフィックスがあると言えます。

apple/YYYY/MM/DD/
banana/YYYY/MM/DD/
melon/YYYY/MM/DD/

S3 への読み書きの性能は、このプレフィックス毎に決まっています。

`apple` , `banana` , `melon` のプレフィックスがある場合、ない場合の比較

例として、バケットの中に apple , banana , melon のフォルダーを作成しないで、日付フォルダのみ作成したとしましょう。
この場合、プレフィックスは、YYYY/MM/DD/ の１つになります。
下の例では、すべて 2024/06/24/ の同じプレフィックスになります。

では、比較してみましょう。
左側に、apple , banana , melon のプレフィックスがある場合は以下になります。

apple.txt のプレフィックス
- apple/2024/06/24/
banana.txt のプレフィックス
- banana/2024/06/24/
melon.txt のプレフィックス
- melon/2024/06/24/

左側にプレフィックスがない場合は以下になります。すべて 2024/06/24/ の同じプレフィックスになります。

apple.txt のプレフィックス
- 2024/06/24/
banana.txt のプレフィックス
- 2024/06/24/
melon.txt のプレフィックス
- 2024/06/24/

左側にapple , banana , melon のプレフィックスを付与しておく場合には、apple.txt、banana.txt、melon.txt それぞれのファイルごとに、毎秒 3,500 回の書き込み、または 5,500 回の読み取りを達成できます。
逆に、左側にapple , banana , melon のプレフィックスを付与しない場合には、apple.txt、banana.txt、melon.txtで合わせて、毎秒 3,500 回の書き込み、または 5,500 回の読み取りを達成できます。

特に、YYYY/MM/DD のようなプレフィックスにしていて、当日にのみデータを書き込む・読み込むといった設計にしていると、一つのプレフィックスに負荷が集中することになります。
また、プレフィックスごとの毎秒 3,500 回の書き込み、または 5,500 回の読み取り性能に到達するまでに、段階的なオートスケールが必要な点にも注意がいるようです。
PUT や GET のパフォーマンスを求められる場合、プレフィックスを工夫することで、パフォーマンスの向上が期待できます。

インデックスに関する公式ドキュメントでの記載

Amazon S3 のストレージに対してアップロードおよび取得を行う際に、アプリケーションはリクエストのパフォーマンスとして 1 秒あたり数千のトランザクションを容易に達成できます。Amazon S3 は、高いリクエストレートに自動的にスケールされます。例えば、アプリケーションは、パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。バケット内のプレフィックスの数に制限はありません。並列化を使用することによって、読み取りまたは書き込みのパフォーマンスを向上させることができます。例えば、Amazon S3 バケットに 10 個のプレフィックスを作成して読み取りを並列化すると、読み取りパフォーマンスを 1 秒あたり 55,000 回の読み取りリクエストにスケールできます。同様に、複数のプレフィックスに書き込むことで、書き込みオペレーションをスケールできます。読み取りオペレーションと書き込みオペレーションの両方の場合、スケーリングは瞬時にではなく段階的に行われます。Amazon S3 が新たに高くなったリクエストレートに合わせてスケーリングしている間に、503 (Slow Down) エラーが表示される場合があります。

参考：設計パターンのベストプラクティス: Amazon S3 のパフォーマンスの最適化

「インデックス ( key / value )の理解」以外の部分に関するメモです。

S3 のマルチパートアップロード機能について、最新の AWS CLI / SDK を使用していれば、ユーザーが意識しなくても実行されている。
S3 バケットへのリクエストは、DNS の複数値回答 (マルチバリュー) を利用して、複数のサーバーに分散させている。上と同様に、最新の AWS CLI / SDK を使用していれば、ユーザーが意識しなくても実行されている。
Mountpoint for Amazon S3 は、S3 を「マウント」しているわけではない。背後で REST API を実行し、マウントしているように見せている。Amazon S3 は REST API で動作させるのが一番効率的。
S3 のプレフィックスに深度はない。プレフィックスがわかっていれば、どのオブジェクトにも平等に到達できる。
99.999999999 % の耐久性を担保する仕組み
- S3 バケットへのリクエスト時には、クライアント側とサーバー側で、エンドツーエンドで整合性チェックをしている。チェックサムのチェックサムも見る。
- S3 に保存されたデータの定期的なチェックも行っている。
- データは常に冗長化されたデバイスに格納される。通常のストレージクラスでは、複数のアベイラビリティゾーンにある複数のデバイスに書き込み、正常終了したタイミングでステータスコード 200 を返す。複数のアベイラビリティゾーンにある複数のデバイスへの書き込み料金は不要（APIリクエスト料金に内包）。
S3 バケットのオブジェクトを誤って削除させない仕組み
- S3 バージョニング
- レプリケーション
- Object Rock
- AWS Backup

ストレージクラス「Amazon S3 Express One Zone」

ストレージクラス「Amazon S3 Express One Zone」では、１つのアベイラビリティゾーンにある複数のデバイスに書き込む。アベイラビリティゾーンに障害があると、データが失われる恐れがある。99.999999999 % の耐久性は担保している。１つのアベイラビリティゾーンにのみ書き込むため、書き込みが終了するまでの時間が短い。レイテンシーの低さが求められる場合に適するストレージクラス。機械学習など、大量データを低いレイテンシーで使うシーンに適する。生成 AI のモデル作成時に GPU や CPU を効率よく使用するために、IO ネックを解消する必要があり、このストレージクラスが生きる。
ストレージクラス「Amazon S3 Express One Zone」では、バケットへのセッションを維持できる。オブジェクトごとに認証認可が不要である。
ストレージクラス「Amazon S3 Express One Zone」では、プレフィックスごとにスケールするのではなく、初めからスケールされている。

公式ドキュメント：docs.aws.amazon.com

まとめ

S3 のインデックス ( key / value )を適切に付与することで、パフォーマンスを上げることができます。パフォーマンスが重要な場合には考慮すると良いでしょう。
最新の AWS CLI / SDK を使用することで、リクエストを分散し、効率的にオブジェクトを処理できます。
AWS Backup を利用して、誤って削除した時にもデータを戻すことができます。
ストレージクラス「Amazon S3 Express One Zone」は GPU / CPU を効率的に使用するためのストレージクラスです。

非常に有意義なセッションでした！