[AWS]Amazon S3とは(ストレージの種類,REST,ストレージクラス,アーキテクチャ)
Amazon S3(Amazon Simple Storage Service)
クラウド上にデータファイルを保存できる、クラウドストレージサービス。
大規模なデータの保存や配信に適している。
- 長期保存が可能なため、バックアップ用途に最適
- 動画・画像配信、ソフトウェアアップデートファイルの配信に利用
1回のファイル転送におけるレイテンシやスループットは突出していない。
レイテンシ・スループットの意味
レイテンシ(Latency)
データを送信してから、最初のレスポンスが返ってくるまでの時間(遅延時間)
- ウェブページをクリックしてから、最初のレスポンスが来るまでの時間
- オンラインゲームでボタンを押してからキャラクターが動くまでの遅延(ラグ)
スループット(Throughput)
一定時間内に処理できるデータ量のこと(転送速度)
👉つまり、「1回のファイル転送のレスポンスの速度、データ処理の速度がすごい速いわけではない」ということ。
ストレージの種類
AWSのストレージサービスは、大きく分けて 「オブジェクトストレージ」「ブロックストレージ」「ファイルストレージ」 の3種類がある。
1. オブジェクトストレージ
①データを「オブジェクト」単位で管理するストレージ
Amazon S3は「オブジェクトストレージ」に分類される。
②各データは、メタデータ(ファイル情報)を持たせて管理する
メタデータとは?
メタデータ(Metadata)とは、「データを説明するデータ」のこと。
一般的なファイルだと、「作成者・更新日・サイズ」といったデータがメタデータ。(HTTPレスポンスのヘッダー情報として使われる)
S3のメタデータは、上記の一般的なメタデータのほかに、カスタムメタデータ(ユーザーが設定可能なメタデータ)がある。
これらのメタデータは、ファイル管理とHTTP/HTTPSアクセスのために使われる。
ファイルの読み書きは、HTTP/HTTPSを使ってアクセスする
- Amazon S3は、ファイルを取得・アップロードするためにHTTP/HTTPSを使用する。
- S3のオブジェクト(ファイル)は「URL形式」でアクセスできるが、単なるWebページではなく、REST APIで操作する仕組み。
RESTとは?
REST(Representational State Transfer)
Webシステムの設計原則・アーキテクチャスタイルのこと。
📌 RESTの原則(6つの制約)
制約 | 意味 |
---|---|
①クライアント-サーバー(Client-Server) | クライアントとサーバーを分離して設計する |
②ステートレス(Stateless) | 各リクエストは独立しており、サーバーは状態を持たない |
③キャッシュ可能(Cacheable) | クライアントがキャッシュできる仕組みを持つ |
④統一インターフェース(Uniform Interface) | 一貫したデータアクセス方法を持つ(URL + HTTPメソッド) |
⑤階層構造(Layered System) | サーバーの内部構造を隠し、システムを階層化できる |
⑥コードオンデマンド(Code on Demand, 任意) | 必要に応じてクライアントにコードを送信し実行できる |
👉 「RESTとは、HTTPを活用したシンプルで統一された設計ルール」!
① クライアント-サーバー(Client-Server)
クライアント(利用者)とサーバー(データ提供者)を明確に分離する設計
サーバーはデータや処理を提供し、クライアントはUI(ユーザーインターフェース)を担当する
📌 具体例
- クライアント → Webブラウザ、モバイルアプリ
- サーバー → APIサーバー(データを提供する)
- クライアントは GET /users を送信し、サーバーはユーザー情報を返す
📌 メリット
- UIとデータ処理を分けることで、独立した開発・変更が可能
- クライアントが変わっても(PC・スマホ・タブレット)、APIは同じものを使える
② ステートレス(Stateless)
「サーバーはクライアントの状態を保持しない」設計
各リクエストは、それ単体で処理が完結する(セッションを持たない)
📌 NGな例(ステートフル)
1. クライアント: "ログインしました(セッション開始)"
2. クライアント: "このデータをください"(セッション情報を元に処理)
3. サーバー: "はい、あなたのデータはこちら"(サーバーがユーザーの状態を記憶)
👉 この場合、サーバーがユーザーの「状態(ログイン情報)」を記憶しているため、「ステートフル(状態あり)」
📌 RESTfulな例(ステートレス)
1. クライアント: "このデータをください(トークンを付与)"
2. サーバー: "OK、あなたのデータはこちら"(リクエスト単体で認証を完結)
👉 各リクエストに必要な情報(認証情報など)を含めることで、「サーバー側の状態管理が不要」になる
📌 メリット
- スケーラビリティ(サーバーの負荷分散)がしやすい
- セッション管理が不要なので、サーバーの実装がシンプルになる
👉 「各リクエストは、単体で完結し、サーバーが状態を持たない」設計!
③ キャッシュ可能(Cacheable)
クライアントがデータをキャッシュ(保存)できる設計を採用する
不要な通信を減らし、効率的にデータを取得する
📌 キャッシュの仕組み
- HTTPヘッダー
Cache-Control: max-age=3600
(1時間キャッシュを保持) - クライアントが同じリクエストをすると、サーバーではなくキャッシュからデータを取得
📌 メリット
- パフォーマンス向上(サーバー負荷を軽減)
- ネットワーク負荷の削減(通信コストを抑える)
👉 「クライアントは、同じリクエストに対するデータをキャッシュできる」設計!
④ 統一インターフェース(Uniform Interface)
すべてのリソース(データ)は、一貫した方法でアクセスできる設計
REST APIでは、リソース(データ)を「URL + HTTPメソッド」で表現する
📌 RESTfulな設計の例
操作 | HTTPメソッド | エンドポイント(URL) |
---|---|---|
データ取得 | GET |
/users/123 (ユーザーID 123の情報を取得) |
データ作成 | POST |
/users (新しいユーザーを作成) |
データ更新 | PUT |
/users/123 (ユーザーID 123の情報を更新) |
データ削除 | DELETE |
/users/123 (ユーザーID 123を削除) |
📌 メリット
- APIの設計が統一され、理解しやすい
- どのリソースに対しても同じルールでアクセスできる
👉 「APIのインターフェース(使い方)が統一され、一貫性を持つ」設計!
⑤ 階層構造(Layered System)
システムを階層化し、サーバー内部の詳細を隠す
クライアントは直接データベースにアクセスせず、APIサーバーを経由する
📌 階層構造の例
ユーザー → フロントエンド(React, Vue) → APIサーバー(REST API) → データベース(MySQL)
👉 フロントエンド(UI)からは、APIサーバーを通じてデータを取得するため、データベースの構造を知らなくても操作できる
📌 メリット
- セキュリティ向上(データベースを直接公開しない)
- システムの柔軟性(バックエンドの変更がフロントに影響しにくい)
👉 「サーバー内部を階層化し、直接依存しない設計!」
⑥ コードオンデマンド(Code on Demand, 任意)
必要に応じて、サーバーからクライアントにコードを送信して実行できる(省略可)
例えば、JavaScriptを動的にロードして、ブラウザで処理を実行する
📌 例
- APIが、動的にJavaScriptを返して、クライアントで処理を実行
- Webページで新しいスクリプトをダウンロードして、アプリの動作を変更
👉 この制約は「必須ではなく、オプション」
レイテンシは高めだが、大容量のデータ保存に向いている
2. ブロックストレージ
データをブロックと呼ばれる小さな単位に分割して管理するストレージ方法。
各ブロックにはユニーク(一意)なアドレスが割り振られていて、必要なデータを高速で読み書きする。
- データは固定のサイズのブロックに分割されて、それぞれ独立している
- OSがブロックの管理を行い、ファイルシステムを適用することでファイル単位の操作が可能になる
- 物理ディスクや高速ネットワーク経由で直接OSに接続するため、データの読み書きが高速(低レイテンシ・遅延が少ない)
- 必要に応じて容量を拡張できる・サーバに直接アクセスできるので、柔軟に設計・拡張できる
EBS(Amazon Elastic Block Store)
EBSは、AWSで提供されるブロックストレージサービス。EC2インスタンスに接続して使用できる。
- 永続的なストレージ
EC2インスタンスが停止・削除されても、データが保持される - スナップショット機能
EBSをバックアップし、別のリージョンやインスタンスで復元できる - SSD・HDDの選択が可能
3. ファイルストレージ
ファイルストレージは、NFS(Network File System)やSMB(Server Message Block)などのファイル共有プロトコルを利用して、データを「ファイル」として管理するストレージ方式。
ユーザーやアプリケーションは、ディレクトリ構造を通じて操作する。
- データはファイルとして管理する、階層構造(フォルダ)を持つ
- OSやアプリケーションからは、ローカルディスクのように見える
- 複数のデバイスやサーバと共有できる
- NFS(主にLinux環境向け)やSMB(主にWindows環境向け)などのプロトコルを使用して、ネットワーク経由でアクセスできる
- ネットワーク超しにファイルをやり取りするので、ブロックストレージよりもレイテンシが高い(遅延する)
用途
- ファイル共有サーバー
社内ファイルの共有・チーム間のデータ管理 - Webサービス
画像・動画などのコンテンツをサーバー間で共有する際に適用 - データ分析・機械学習
NFS(Network File System)
NFS(ネットワークファイルシステム)は、LinuxやUnix系OSで主に使用されるファイル共有プロトコル。
ネットワーク上の複数のコンピュータが、リモートのストレージをローカルディスクのようにマウントして使用できる。
- 主にLinux/Unix環境で利用(Windowsでも設定すれば使用可能)
- ネットワーク越しにファイルを共有(異なるマシンから同じデータにアクセス可能)
- クライアント・サーバーモデル(ファイルを提供する「NFSサーバー」と、アクセスする「NFSクライアント」に分かれる)
- ステートレス設計(サーバーが接続情報を保持しないため、耐障害性が高い)
主な用途
- Linuxサーバー間のファイル共有
- 仮想マシンやDockerのストレージ共有
- 企業内での大規模なファイルストレージの構築 に使用できる
SMB(Server Message Block)
主にWindows環境で使用されるファイル共有プロトコル。
Windowsの「ネットワークドライブ」としてよく使われ、社内ネットワークでファイルを共有する際に広く利用されている。
- 主にWindows環境で利用(MacやLinuxでも設定すれば使用可能)
- ファイルやプリンタの共有が可能(Windowsの「共有フォルダ」機能で使われる)
- アクセス制御が強力(Active Directoryと連携して、ユーザーごとの権限管理が可能)
- ステートフル設計(接続情報を保持するため、NFSより細かい制御が可能)
主な用途
- Windowsネットワーク内のファイル共有(例:会社のファイルサーバー)
- WindowsとMac間でのファイル共有(Macは「smb://」で接続可能)
- プリンタやデバイスの共有
EFS(Amazon Elastic File System)
Amazon EFSは、AWS(Amazon Web Services)が提供するNFSベースのファイルストレージサービス。
- データ管理方法は、ファイル単位。ファイル構造。
- ネットワーク経由で接続。レイテンシは高め。
- 容量が自動的に増減し、柔軟に対応可能。
- 複数のインスタンスで共有は可能
S3の基本用語
用語 | 意味 |
---|---|
バケット(Bucket) | オブジェクト(ファイル)を保存するためのコンテナ。バケット名はグローバルで一意。 |
オブジェクト(Object) | S3に保存されるファイル本体。1つのバケットに無制限に格納可能。最大5TBまで。 |
キー(Key) | オブジェクトを識別するための一意の名前(ファイルパスのようなもの)。 |
メタデータ(Metadata) | オブジェクトに付加される属性情報。システム定義とユーザー定義の2種類がある。 |
ストレージクラス
S3のオブジェクトは利用用途に応じて、ストレージクラス(種類)を選択できる。
主要なストレージクラスの比較
ストレージクラス | 性能 | ストレージ料金 | データの取り出し | 主な用途 |
---|---|---|---|---|
S3標準(Standard) | 最も高い | 高価 | 無料 | 頻繁にアクセスするデータ |
S3 低頻度アクセス(IA) | 「標準」と同じ | 「標準」より安価 | 有料 | たまにアクセスするデータ |
S3 Intelligent-Tiering | 自動調整 | 選択中のクラス料金が適用 | 無料(モニタリング料金あり) | アクセス頻度が変動するデータ |
S3 1ゾーン低頻度アクセス(1Z-IA) | 「標準」と同じ(ただし1つのAZのみ) | 低頻度アクセスよりさらに安価 | 有料 | 冗長性が不要なデータ |
S3 Glacier | 低速(数時間〜数日) | 最も安価 | 非常に時間がかかる | バックアップ・アーカイブ |
Glacierとは?
Amazon S3 Glacier(グレイシャー) は、長期保存向けの低コストなストレージサービス 。
データをすぐに使う必要はないが、安全に長期間保管したい場合に適している。
特徴
✅ 超低コスト(通常のS3ストレージより安い)
✅ アーカイブ用(バックアップや法的保管データ向け)
✅ データ取得に時間がかかる(通常数分~数時間)
用途
- バックアップやアーカイブデータの保存(例:企業の過去データ)
- 法的証拠の長期保存(例:医療・金融業界)
- あまりアクセスしないデータのコスト削減
S3のアーキテクチャ
S3は、エンドユーザーが触れることのない複雑な分散アーキテクチャを持っている。
これにより、高い可用性・耐久性・スケーラビリティが実現できる。
S3のデータ処理の流れ
-
エンドユーザーがS3にリクエストを送信
- ユーザーは、オブジェクトを操作するためにPUT(アップロード)、GET(ダウンロード)、DELETE(削除)などのリクエストを発行。
- このリクエストはインターネットを経由してAWSリージョン内のS3へ送られる。
-
ロードバランサ(エンドポイント)に到達
- S3には「エンドポイント」と呼ばれるロードバランサがあり、ここでリクエストを受け付ける。
- エンドポイントは、S3 APIのリクエストを最適なサーバーに振り分ける役割を持つ。
「ロードバランサ」「エンドポイント」の意味
1. ロードバランサ(Load Balancer)とは?
ロードバランサとは、複数のサーバーにリクエスト(アクセス)を均等に分散するシステムのこと。
リクエストを分散させ、処理が集中してサーバーがダウンすることを防ぐ。
💡 S3におけるロードバランサの役割
S3では、ユーザーがデータをアップロード(PUT)やダウンロード(GET)すると、S3のロードバランサがリクエストを適切なAPIサーバーに振り分ける。
→ これにより、S3は大量のアクセスを高速に処理できる。
✅ ロードバランサのイメージ
(ユーザー)
↓
[ ロードバランサ ] ← 負荷を分散
↙︎ ↓ ↘︎
[ サーバー1 ] [ サーバー2 ] [ サーバー3 ]
2. エンドポイント(Endpoint)とは?
エンドポイントは、特定のサービスにアクセスするための「入口(URLやIPアドレス)」のこと。
💡 S3におけるエンドポイントの役割
- ユーザーがS3のデータにアクセスするとき、S3の**エンドポイント(URL)**を使ってリクエストを送信する。
- そのエンドポイントはS3のロードバランサになっており、適切なAPIサーバーへリクエストを振り分ける。
✅ S3のエンドポイント例
https://s3.amazonaws.com
https://my-bucket.s3.us-west-1.amazonaws.com
→ これらのURLが「エンドポイント」となり、ユーザーのリクエストを受け付ける。
💡 エンドポイントの種類
AWSでは、サービスごとに異なるエンドポイントが用意されている。
例えば、S3のエンドポイントはリージョンごとに異なる。
リージョン | S3のエンドポイント |
---|---|
東京リージョン | https://s3.ap-northeast-1.amazonaws.com |
バージニアリージョン | https://s3.us-east-1.amazonaws.com |
-
APIサーバーがリクエストを処理
- ロードバランサがリクエストを適切なAPIサーバーに転送。
- APIサーバーは、リクエストの種類に応じて処理を実行。
-
データの保存・管理(ストレージシステムへのアクセス)
-
APIサーバーは2種類のストレージにアクセスする。
ストレージ 役割 メタデータストレージ オブジェクトの名前、キー、バケット情報などの管理 BLOBストレージ ファイル本体(バイナリデータ)を保存 BLOBストレージとは?
BLOB(Binary Large Object)ストレージとは、画像・動画・音声・文書・バックアップデータなどの「バイナリデータ」を格納するためのストレージ
BLOB = Binary Large Object(バイナリ大容量オブジェクト)
-
-
処理結果をエンドユーザーに返す
- APIサーバーが処理を完了し、リクエストの結果(成功・失敗など)をエンドユーザーに返す。
S3アーキテクチャの主要コンポーネント
コンポーネント | 役割 |
---|---|
エンドユーザー | PUT/GET/DELETEなどのリクエストを発行 |
エンドポイント(ロードバランサ) | ユーザーのリクエストをAPIサーバーに振り分ける |
APIサーバー | ユーザーのリクエストを処理し、ストレージへアクセス |
メタデータストレージ | オブジェクトの管理情報(キー、バケット、所有者など)を保存 |
BLOBストレージ | ファイル本体(データ)を保存 |
S3のアーキテクチャの特徴
✅ 高い耐障害性
- データは複数のAZ(アベイラビリティゾーン)に分散して保存されるため、1つのデータセンターが故障しても影響を受けにくい。
✅ スケーラビリティ
- ロードバランサを活用した分散処理により、大量のリクエストがあっても安定して処理できる。
- S3のデータは、ストレージの容量が事実上無制限で増やせる。
✅ パフォーマンス最適化
- S3エンドポイントがユーザーの近くのリージョンで処理するため、リクエストの遅延を最小限に抑えられる。
Amazon S3のファイル操作一覧
操作 | 説明 | 主な特徴 |
---|---|---|
GET | オブジェクトをダウンロード | ファイルの一部だけダウンロード可能 |
PUT | オブジェクトをアップロード | 最大5GB(5GB以上はマルチパートアップロードで最大5TB) |
LIST | バケット内のオブジェクト一覧を取得 | 1回で最大1,000オブジェクト取得、プレフィックスで絞り込み可 |
COPY | オブジェクトを複製 | S3内でのコピー。異なるリージョン間コピーは帯域料金発生 |
DELETE | オブジェクトを削除 | 複数オブジェクトをまとめて削除可 |
HEAD | オブジェクトのメタデータ取得 | ファイル本体を取得せずに情報のみ取得 |
RESTORE | Glacierからオブジェクトを復元 | 復元後、GETやSELECTが可能 |
SELECT | SQLクエリでデータを抽出 | CSV、JSON、Parquet形式のデータから直接抽出 |
S3も長すぎる…!ひとまずここで今日は終わらせて、明日続きやる!
Discussion