お仕事

【AWS】SAA資格取得のための学習用備忘録(ストレージサービス)

 

メモ

以前取得したAWSの資格「クラウドプラクティショナー」に続き「ソリューションアーキテクトアソシエイト(SAA-C03)」取得を目指して勉強中!

いつも何か勉強するときは基本的に書きながら覚えるのでここでアウトプットします。

有益な情報かどうかは不明(笑)

 

スポンサーリンク

AWSのストレージサービス

 

IoTやビッグデータ、機械学習などIT技術の革新に伴い、データ量の増加やデータの取り扱い方法の多様化が進んでいる。

それに応じて、ストレージにも様々な種類が登場している。

データの利用目的、要件に応じて適切なストレージを選択できることもソリューションアーキテクトとして重要なスキルになるため、各サービスの特徴と違いをしっかりと理解する。

 

ストレージサービスの分類とストレージのタイプ

 

AWSが提供するストレージサービスは以下の5つ。

・EBS

・EFS

・S3

・S3 Glacier

・AWS Strage Gateway

ドキュメントの分類ではAWS Snowballもストレージサービスに分類されている。

Snowballはペタバイトを超えるような大容量のデータをAWSへ移行したり、AWSから持ち出したりする時に使用するデータ転送サービス。

Webサービスではなく、ハードディスクアプライアンスとデータ転送用のクライアントツールが提供されている。

これ以外にもファイルサーバーのサービスとしてAmazon FSxがある。

ストレージサービスは一般的に次の3つのタイプに分類できる。

・ブロックストレージ:データを物理的なディスクにブロック単位で管理するストレージ。DBや仮想サーバーのイメージ保存領域のように、頻繁に更新されたり高速なアクセスが必要とされる用途で使われる。AWSストレージサービスのうち、EBSがブロックストレージのサービス

・ファイルストレージ:ブロックストレージ上にファイルシステムを構成して、データをファイル単位で管理するストレージ。複数のクライアントからネットワーク経由でファイルにアクセスするといったデータ共有のために使われたり、過去データをまとめて保存したりといった用途で使われる。AWSストレージサービスのうち、EFSがファイルストレージのサービス

・オブジェクトストレージ:ファイルに任意のメタデータを追加してオブジェクトとして管理するストレージ。ファイルの内容をストレージ内で直接操作することはできず、作成済みのデータに対するHTTP(S)経由の登録・削除・参照といった操作が可能。更新頻度の少ないデータや大容量のマルチメディアコンテンツを保存する用途で使われる。AWSストレージのうち、S3とS3 Glacierがオブジェクトストレージのサービス

 

オブジェクトストレージはクラウドの進展と共に注目されている比較的新しいストレージサービス。

アプリケーションからの利用を想定したREST APIを提供しているサービスが多く、サーバーレスアーキテクチャの構成要素としても重要な役割を担う。

AWSのオブジェクトストレージサービスであるS3も、AWSの中核を担うサービスとして位置付けられており、AWSの様々なサービスのバックエンドとしても利用されている。

★AWSでは、EBS、EFS、S3、S3 Glacier、Storage Gatewayという5つのストレージサービスが提供されている。このうちEBSはブロックストレージ、EFSはファイルストレージ、S3とS3 Glacierはオブジェクトストレージ

 

EBS

 

EBSは、AWSが提供するブロックストレージサービス。

EC2のOS領域として利用したり、追加ボリュームとして複数のEC2にアタッチすることもできる。

RDSのデータ保存用にも使用する。

EBSは基本的にはEC2に1対1に対応するサービスであるため、複数のEC2インスタンスから同時にアタッチするといった使い方はできなかった。

EBSマルチアタッチ機能により複数のEC2からの同時アタッチもできるようになったが、制約も多く限定的な用途にとどまる。

また、EBSは作成時にAZを指定するため、指定したAZに作成されたEC2インスタンスからのみアタッチ可能。

異なるAZのEC2インスタンスにアタッチしたい場合は、EBSにスナップショットを取得して、スナップショットから指定のAZでEBSボリュームを作成することでアタッチ可能になる。

★EBSはブロックストレージサービスで、EC2のOS領域、EC2の追加ボリューム、RDSのデータ保存領域などに使用する

 

EBSのボリュームタイプ

 

EBSのボリュームタイプはSSDタイプで2種類、HDDタイプで2種類の計4つ。

・汎用SSD(gp2)

・プロビジョンドIOPS(io1)

・スループット最適化HDD(st1)

・Cold HDD(sc1)

旧世代のマグネティックと呼ばれるHDDのストレージタイプもあるが、新規で作成するときはマグネティックタイプは使わずに、現行のボリュームタイプから最適なものを選ぶようにする。

また、各タイプの性能を最大限に発揮するためには、EBSへのアクセス最適化が可能なEC2インスタンスの利用がおすすめ。

 

汎用SSD(gp2)

 

「汎用」という名前が示す通り、EBSの中で最も一般的な、SSDをベースとしたボリュームタイプ。

EC2 インスタンスを作成する際のデフォルトボリュームタイプとしても利用されている。

性能の指標としてIOPS(1秒あたりに処理できるI/Oアクセスの数)を用い,3IOPS/GB(最低100IOPS)から最大16,000IOPS/ボリュームまで、容量に応じたベースライン性能がある。

このベースライン性能はEBS利用時間の99%で満たされるように設計されている。

また、1TB未満のボリュームには、一時的なIOPSの上昇に対応できるようにバースト機能が用意されており、容量に応じて一定期間3,000IOPSまで性能を向上させることができる。

ベースライン性能やバースト機能を使ってもシステムで必要なIOPSを満たすことができない場合は、プロビジョンドIOPSタイプの利用を検討する。

また、2020年12月に、gp3という新タイプも出ている。

 

プロビジョンドIOPS SSD(io1)

 

プロビジョンドIOPSはEBSの中で最も高性能な、SSDをベースとしたボリュームタイプ。

RDSやEC2インスタンスでDBサーバーを構築する場合など、高いIOPS性能が求められる際に利用する。

io1は最大50IOPS/GB、もしくは最大64,000IOPS/ボリュームまで、容量に応じたベースライン性能がある。

このベースライン性能はEBS利用時間の99.9%で満たされるように設計されている。

また、スループットもボリュームあたり最大1,000MB/秒まで出るようになっており、IOPS負荷の高いユースケースと、高いスループットが必要なユースケースの両方に適したストレージタイプ。

 

スループット最適化HDD(st1)

 

スループット最適化はHDDをベースとしたスループット重視のボリュームタイプ。

ログデータに対する処理やバッチ処理のインプット用ファイルなど、大容量ファイルを高速に読み取るようなユースケースに適している。

スループット(MB/秒)を性能指標として用いており、1TBあたり40MB/秒、最大スループットはボリュームあたり500MB/秒のベースライン性能がある。

このベースライン性能はEBS利用時間の99%で満たされるように設計されている。

 

Cold HDD(sc1)

 

Cold HDDは4つのストレージタイプの中でストレージとしての性能はそれほど高くないが、最も低コストなボリュームタイプ。

利用頻度があまりなく、アクセス時の性能もそれほど求められないデータをシーケンシャルにアクセスするようなユースケースやアーカイブ領域の用途に適している。

1TBあたり12MB/秒、ボリュームあたり最大250MB /秒のベースライン性能がある。

 

ベースライン性能とバースト性能

 

プロビジョンドIOPS以外のストレージタイプには、ストレージの容量に応じたベースライン性能がある。

これらストレージタイプには、ベースライン性能とは異なり、処理量の一時的な増加に対応可能なバースト性能という指標もある。

バースト性能はあくまで一時的な処理量の増加への対応に使われることを想定したものと理解しておき、バースト性能に頼ったサイジングはしないようにする。

★バースト性能は処理量の一時的な増加に対応する能力を示すものなので、これに頼ったサイジングはすべきではない

 

EBSの拡張・変更

 

EBSには用途に応じた対応がある。

一度作成したEBSに対してどういった変更が可能かを解説。

変更はマグネティック(旧世代)タイプを除いて、基本的には全てオンラインで実施可能。

※EBSボリュームに対して変更作業を行った場合、同一のEBSボリュームへの変更作業は6時間以上開けるひつようがある

※現行世代以外のEC2インスタンスタイプで使用中のEBSボリュームに対する変更作業では、インスタンスの停止やEBSのデタッチが必要になる場合がある

 

容量拡張

 

全てのタイプのEBSは1ボリュームあたりの最大容量が16TB。

ディスク容量が不足したら必要に応じてサイズを何度でも拡張できる。

オンラインで使用中のEBSボリュームを拡張した後は、EC2インスタンス上でOSに応じたファイルシステムの拡張作業(Linuxであればresize2fsやxfs_growfsなど)を別途実施して、OS側でも認識できるようにする。

※拡張はできるが縮小はできない。一時的なデータ容量の増加などの要件に対しては、ボリュームの拡張ではなく、新規EBSを作成してEC2インスタンスにアタッチし、不要になったらデタッチしてEBSごと削除するといった方法を検討する

 

ボリュームタイプの変更

 

前述の4つの現行世代タイプ間でのタイプ変更が可能。

gp2タイプで作成したがIOPSが不足することがわかったためio1タイプに変更したい、といった要件に対応できる。

また、io1タイプで指定したIOPSが足りない場合に追加のプロビジョニングを実施することも可能。

※プロビジョンドIOPSタイプで指定したIOPS値については、増減のどちらの変更も可能

※IOPSの変更には最大24時間以上かかる場合がある。変更期間中はボリュームのステータスが「Modifying」になっている。ステータスが「Complete」になれば完了

 

EBSの可用性・耐久性

 

EBSは内部的にAZ内の複数の物理ディスクに複製が行われており、AWS内で物理的な故障が発生した場合でも利用者が意識することはほとんどない。

SLA(Service Level Agreement)は月あたりの利用可能時間が99.99%と設定されている。

また、EBSにはスナップショット機能もあるため、定期的にバックアップを取得することで必要な時点の状態に戻すことが可能。

データのリストアは、スナップショットから新規EBSボリュームを作成し、EC2インスタンスにアタッチすることで実現できる。

EBSは一般のハードディスクに比べて信頼性は高いが、壊れないわけではない。

スナップショットでバックアップをとる運用設計の検討が必要。

 

EBSのセキュリティ

 

EBSには、ストレージ自体を暗号化するオプションがある。

暗号化オプションを有効にすると、ボリュームが暗号化されるだけではなく、暗号化されたボリュームから取得したスナップショットも暗号化される。

暗号化処理はEC2インスタンスが稼働するホストで実施されるため、EBS間をまたぐデータ通信時のデータも暗号化された状態となる。

すでに作成済みのEBSボリュームを暗号化したい場合は、以下の手順を踏む。

1.EBSボリュームのスナップショットを取得

2.スナップショットを暗号化

3.暗号化されたスナップショットから新規EBSボリュームを作成

4.EC2インスタンスにアタッチしているEBSボリュームを入れ替え

既存のブートボリュームを暗号化する場合は、スナップショットではなくAMIを取得して、AMIコピー時に暗号化を実施したのち、コピーされたAMIからEC2インスタンスを作成することで暗号化が可能。

 

Amazon EBSマルチアタッチ

 

2020年2月にAmazon EBSマルチアタッチという機能が登場した。

制約が多いものの、今まで実現できなかった複数のインスタンスから同一のEBSをアタッチできるという機能。

EBSマルチアタッチは、同一のAZのインスタンスからのみアタッチ可能で、別AZからはアタッチできない。

また、プロビジョンドIOPS SSD(io1)ボリュームのみ利用可能。

OSの持つ標準ファイルシステムはサポートしていないため、書き込みの排他制御を利用者自身で検討する必要がある。

それ以外の制約もまだまだあり、使い所は限定されるが、機能として追加されているため把握しておく。

 

スポンサーリンク

EFS

 

EFSは、容量無制限で複数のEC2インスタンスから同時にアクセスが可能なファイルストレージサービス。

クライアントからEFSへの接続は、一般的なNFSプロトコルをサポートしているため、NFSクライアントさえあれば特別なツールをインストールしたり設定したりする必要はない。

 amazon-efs-utilsツールを使うと、EFSへのマウントに関する推奨オプションが含まれていたり、ファイルシステムにトラブルが発生した場合のトラブルシューティングに役立つログを記録できたりするため、EFSへ接続するクライアントには導入がおすすめ。

EFSには多種多様なユースケースに対応できるよう、パフォーマンスモードやスループットモードといったモードが用意されている。

間違ったモードを選択すると思っていた性能が出ないといった不具合が起こるため、システムに最適なモードを選択できるようにする必要がある。

★EFSは、容量無制限で複数のEC2インスタンスから同時にアクセスが可能なファイルストレージサービス。システムに最適なモードを選択して使う必要がある

 

EFSの構成要素

 

EFSは以下の3つの要素から構成されている。

・ファイルシステム

・マウントターゲット

・セキュリティグループ

 

EFSは、ファイルが作成されると自動的に3ヶ所以上のAZに保存される分散ファイルシステムを構成する。

作成したファイルシステムにアクセスするために、AZごとにサブネットを指定してマウントターゲットを作成する。

マウントターゲットを作成すると、ターゲットポイント(接続FQDN)が1つと各AZのマウントターゲット用IPアドレスが発行される。

EC2からは1つのFQDNでアクセスするが、内部的には自動的に接続元のEC2インスタンスと同一AZのマウントターゲットIPアドレスが返却されるため、レイテンシーを低くするように設計されている。

また、マウントターゲットにはセキュリティグループを指定でき、EC2からEFSへの通信要件を定義して、不要なアクセスを制限できる。

 

EFSのパフォーマンスモード

 

EFSには、汎用パフォーマンスモードと最大I/Oパフォーマンスモードの2つのパフォーマンスモードがある。

ほとんどの場合は、汎用パフォーマンスモードを使えば問題ない。

ただし、数百〜数千台といったクライアントから同時にEFSへアクセスがあるようなユースケース(例えば、ビッグデータ解析アプリケーションによる並列処理に使うデータをEFSに置く場合)にも耐えられるように、最大I/Oパフォーマンスモードを選択した場合、スループットを最大化する代わりに各ファイル操作のレイテンシーが汎用パフォーマンスモードよりも少し高くなる。

どちらのモードを選択するのが良いかを見分ける指標として、CloudWatchのPercentIOLimitというメトリクスが参考になる。

汎用パフォーマンスモードを選択してシステムのユースケースに似たアクセスパターンで性能テストを実施し、PercentIOLimitがどのように遷移するかを確認する。

性能テスト実施中にPercentIOLimitが長時間高い状態(80~100%)である場合は、最大I/Oパフォーマンスモードに変更した方が良い場合がある。

パフォーマンスモードはファイルシステムを一度作成すると変更できないため、本番導入前に入念にテストを実施してどちらを利用するか検討する。

★パフォーマンスモードは後から変更できないため、導入前によく検討しなければならない。CloudWatchのPercentIOLimitメトリクスが参考になる

 

EFSのスループットモード

 

EFSにはパフォーマンスモードとは別に2つのスループットモードが用意されている。

「バーストスループットモード」と「プロビジョニングスループットモード」。

バーストスループットモード:このモードには、EFSに保存されているデータ容量に応じてベースラインとなるスループットが設定されている。一時的なスループットの上昇にも耐えられるようなバースト機能を持ったモード。ベースラインのスループットは1GBあたり50KB/秒で、保存されているデータ量に応じてスループットと期間が設定される。最低バーストスループットは100MB/秒。1TBを超えると、毎日12時間、ストレージの1TBあたり100MB/秒までバーストできるバーストクレジットが貯まるように設計されている。

プロビジョニングスループットモード:バーストスループットモードで設定されているベースラインスループットを大幅に上回るスループットが必要な場合や、一時的なバースト時にバーストスループットで定められている最大スループットよりも高い性能が必要な場合に、任意のスループット値を指定することができるモード。容量によらず最大1GB/秒までのスループットを指定できる。それ以上のスループットが必要な場合は制限の緩和申請が可能。このモードは、Web配信用のコンテンツやアプリケーション用のデータといった、データサイズはそれほど大きくないものの頻繁にアクセスしたり大量のインスタンスからの同時アクセスを受けるようなデータをEFSに配置する場合に最適。

どちらのスループットモードを選択すれば良いかを見分ける指標として、CloudWatchのBurstCreditBalanceというメトリクスが参考になる。

クレジットバランスを全て使い切ってしまったり、常に減少傾向にある場合はプロビジョニングスループットモードを選択する。

スループットモードはEFS運用中にも変更できる。

プロビジョニングスループットで指定するスループット値は増減どちらも可能。

スループットモードの変更、およびプロビジョニングスループットモードでのスループット値の削減は、前回の作業から24時間以上間隔を開ける必要がある。

★スループットモードの選択には、CloudWatchのBurstCreditBalanceメトリクスが参考になる

 

S3

 

S3は非常に優れた耐久性を持つ、容量無制限のオブジェクトストレージサービス。

ファイルストレージとの違いとしては、ディレクトリ構造を持たないフラットな構成であることや、ユーザーが独自にデータに対して情報(メタデータ)を付与できることが挙げられる。

S3の各オブジェクトには、RESTやSOAPといったHTTPをベースとしたWeb APIを使ってアクセスする。

利用者がデータを保存するために利用するだけでなく、EBSスナップショットの保存場所として使われるなど、AWSのバックエンドサービスにも使われていて、AWSの中でも非常に重要なサービスと位置付けられている。

柔軟性に優れたサービスであるため、アイデア次第で使い方は無限に考えられるが、主なユースケースは以下の通り。

・データバックアップ

・ビッグデータ解析用などのデータレイク

・ETLの中間ファイル保存

・Auto Scaling構成されたEC2インスタンスやコンテナからのログ転送先

・静的コンテンツのホスティング

・簡易的なKey-Value型のデータベース

 

「大量・大容量」「長期保存したい」「なくなると困る」といったデータを扱う場合には、まずはS3が使えないかを検討するところからスタートする。

★S3は、非常に優れた耐久性を持つ、容量無制限のオブジェクトストレージサービスで、様々な用途に利用できる

 

S3の構成要素

 

S3は次の3つの要素から構成される。

バケット:オブジェクトを保存するための領域。バケット名はアカウントやリージョンに関係なくAWS内で一意にする必要がある

オブジェクト:S3に格納されるデータそのもの。各オブジェクトにはキー(オブジェクト名)が付与され、「バケット名+キー名+バージョンID」で必ず一意になるURLが作成される。このURLをWeb APIなどで指定してオブジェクトを操作する。バケット内に格納できるオブジェクト数に制限はないが、1つのオブジェクトサイズは最大5TBまで

メタデータ:オブジェクトを管理するための情報。オブジェクトの作成日時やサイズなどのシステム定義メタデータだけではなく、アプリケーションで必要な情報をユーザー定義メタデータとして保持することができる

 

S3の耐久性と整合性

 

S3に保存されたデータは、複数のAZ、さらにはAZ内の複数の物理的ストレージに複製される。

これにより高い耐久性が維持できる。

データの複製方式として、S3は結果整合性方式を採用している。

そのため、データの保存後、複製が完全に終わるまでの間にデータを参照すると、参照先によっては保存前の状態が表示されることもあり、この点には注意が必要。

 

ストレージクラス

 

S3には高い耐久性があるが、その中にも用途に応じて5つのランク(ストレージクラス)分けがされている。

なお、次の各項の耐久性と可用性は設計上の性能で、可用性にはSLAが設定されている。

S3標準:デフォルトのストレージクラス。低レイテンシーと高スループットを兼ね備えた、S3の性能が最も発揮されるクラス

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.9%

S3標準-低頻度アクセス:S3に比べて格納コストが安価なストレージクラス。参照頻度が低いデータ向けに設定されたクラスであるため、データへのアクセスは随時可能だが、データの読み出し容量に対する従量課金が行われる。高速なアクセスが必要なものの、それほど頻繁にはアクセスしない、といったデータを保存するときに最適なクラス

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.9%

S3 1ゾーン-IA:単一のAZのみでデータを複製するストレージクラス。高い耐久性を発揮するが、AZ単位で障害が発生した場合にデータの復元ができない可能性がある。それ以外はS3標準-低頻度アクセスと同等のサービス仕様。耐久性はイレブンナインだが、1つのAZ内の耐久性のため、保存しているAZでデータ消失を伴う障害が発生した場合、データは失われる

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.5%

S3 intelligent-Tiering:参照頻度の高低を明確に決めることができないデータを扱う場合に有効なストレージクラス。S3標準とS3標準-低頻度アクセスの2層構成となっており、30日以上参照されなかったデータは自動的にS3標準-低頻度アクセスに移動される。ライフサイクル管理を自動化できる反面、頻繁に移動が発生する場合はコスト高になることもある。

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.9%

S3 Glacier:ほとんど参照されないアーカイブ目的のデータを保存するストレージクラス。オブジェクト新規作成時のこのクラスを選択することはできない。S3 Glacier以外のストレージクラスを選択して、ライフサイクル管理機能を使ってこのストレージクラスを指定することで利用可能になる。S3 Glacierクラスに保存されたデータにアクセスする場合は、事前にアクセスをリクエストする必要があり、アクセスできるようになるまでは数時間かかる。オブジェクトはS3 Glacierに保存されるが、引き続きS3で管理するオブジェクトであり、S3 Glacierを介して直接アクセスすることはできない。データの取り出しには、数分から標準で3~5時間かかる。バルク取り出しによる大量のデータ取得の場合は、5~12時間かかる。

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.9%

S3 Glacier Deep Archive:S3 Glacier同様にアーカイブ用途のストレージクラス。S3 Glacierよりもさらにアクセス頻度が少ないデータを想定し、データの取得にもさらに時間がかかるようになっている。データの取り出しは標準で12時間以内、バルク取り出しによる大量のデータ取得の場合は、12~48時間かかる。しかし、GBあたりのストレージ単価はさらに低く、S3 Glacierに比べて最大75%安価

・耐久性:99.999999999%(イレブンナイン)

・可用性:99.9%

 

ライフサイクル管理

 

S3に保存されたオブジェクトはその利用頻度に応じてライフサイクルを定義することができる。

ライフサイクル設定では、次のどちらかを選択できる。

移行アクション:データの利用頻度に応じてストレージクラスを変更するアクション。例えば、オブジェクト作成当初はアクセス頻度が高いが、一定期間経過すると利用頻度や重要度が低くなり、最後にはアーカイブとして保存しておく、といったライフサイクルに応じて最適なストレージクラスへ移行することができる

有効期限アクション:指定された期限を越えたオブジェクトをS3から削除するアクション。利用期間が決まっているオブジェクトや一時的に作成されたオブジェクトなどを定期的に整理することができる。S3は容量無制限のストレージサービスではあるが、保存容量に応じて従量課金されるため、不要なデータを定期的に削除することでコスト削減が図れる

 

バージョニング機能

 

バージョニング機能を有効にすると、1つのオブジェクトに対して複数のバージョンを管理することができる。

バージョニングはバケット単位で有効/無効を指定できる。

バージョニングされたオブジェクトは差分管理されるのではなく、新・旧オブジェクトの両方が保存され、バージョンIDで区別される。

そのため、両バージョン分の保存容量が必要になる。

 

Webサイトホスティング機能

 

S3では、静的なコンテンツに限って、Webサイトとしてホスティングする環境を作成できる。

静的コンテンツのリリースは通常のS3の利用と同様に、S3バケットへ保存することで行える。

Ruby、Python、PHP、Perlなど、サーバーサイドの動的なコンテンツに関してはS3をWebホスティングとして利用することができない。

動的なコンテンツのWebホスティングを行うには、EC2で独自にWebサーバーを作成するなどの方法がある。

 

独自ドメインでS3 Webサイトホスティングする場合の注意点

 

S3のWebサイトホスティングを設定すると自動的にドメイン(FQDN)が作成される。

そのサイトに独自ドメインでアクセスしたい場合は、Route53などのDNSにCNAME情報を設定する。

この際、バケット名とドメイン名を一致させる必要がある。

S3の前段にCloudFrontを配置する場合は、バケット名とドメイン名を合わせる必要はない。

 

S3のアクセス管理

 

S3のアクセス管理にはバケットポリシー、ACL、IAMが使える。

バケットポリシーはバケット単位でアクセスを制御する。

そのバケットに保存されるオブジェクトすすべてに適用されるため、バケットの用途に応じた全体的なアクセス制御をする時に有効。

ACLはオブジェクト単位で公開/非公開を制御する場合に使用する。

IAMでの制御は、ユーザー単位でS3のリソースを制御する場合に使用する。

バケットポリシーのIAMユーザー制御は、IAMユーザーの名称と一致したバケットのみを利用させるといった少し特殊なユースケースに適用可能な制御方法であるため、IAMユーザーに対する制限を行う場合はIAMのポリシーを利用する。

★S3のアクセス管理にはバケットポリシー、ACL、IAMを用いる。IAMユーザーに対する制限はバケットポリシーでも可能ではあるが、IAMのポリシーを使った方が良い

 

署名付きURL

 

署名付きURLは、アクセスを許可したいオブジェクトに対して期限を指定してURLを発行する機能。

バケットやオブジェクトのアクセス制御を変更することなく特定のオブジェクトに一時的にアクセスを許可したい場合に非常に有効。

なお、この機能はユーザー制御ではないため、署名付きURLを知っていれば期間中は誰でもアクセスできる。

その点には注意が必要。

★署名付きURLは、特定のオブジェクトへのアクセス許可を一時的に与える。この期間中、URLを知っていれば当該オブジェクトには誰もがアクセスできる。この点に注意すべき

 

データ暗号化

 

S3に保存するデータは暗号化ができる。

暗号化の方式は、サーバー側での暗号化とクライアント側での暗号化の2種類から選択できる。

サーバー側での暗号化では、データがストレージに書き込まれる時に暗号化され、読み出す時に複合される。

クライアント側での暗号化では、AWS SDKを使ってS3に送信する前にデータが暗号化される。

複合時は、クライアント側で暗号化されたデータのメタデータからどのキーで複合するのかが判別され、それに基づいてオブジェクトが複合される。

 

S3のブロックパブリックアクセス機能とS3 Access Analyzer

 

AWSはセキュリティへのプライオリティが極めて高く、そのために様々な機能が備わっている。

しかし、正しい設定がなされていないために事故が起こっているのも事実。

その事故の1つに、意図せぬS3バケットの外部公開(パブリックアクセス)による情報漏洩がある。

その対策として、2018年11月に登場した機能が、S3のブロックパブリックアクセス機能。

この機能は、新規・任意のACLおよびバケットポリシーの4段階でパブリックアクセスを禁止する設定ができる。

さらに、新規のバケット作成はデフォルトでパブリックアクセスをブロックするようになっている。

ブロックパブリックアクセス以外にも、S3 Access AnalyzerでS3バケットの監視、保護ができ変わってきている。

ブロックパブリックアクセス機能を有効にするとともに、その挙動を確認する。

 

S3のその他の機能

 

S3には、まだまだたくさんの機能がある。

代表的なのはS3 SelectとTransfer Accelaration。

S3 Selectは、SQL文を利用してS3オブジェクトのコンテンツをフィルタリングし、必要なデータのみを取得する機能。

必要なデータのみを取得できるため、転送するデータ量を削減できる。

これにより、コストと時間の短縮を図れる。

Transfer Accelarationは、遠隔地のS3へのデータ転送をサポートする機能。

例えば、日本から海外のリージョンのS3に転送する場合、回線の十分な帯域と安定性がないと転送に時間がかかる。

S3 Transfer AccelarationはCloudFrontのエッジロケーションを活用し、ユーザーは最寄りのエッジロケーションに転送し、後はAWSの大容量かつ安定したバックボーン回線を利用して転送することができる。

最古のサービスの1つであるS3についても、毎年のように機能拡張がなされている。

アーキテクチャ設計に関わるような機能については、必ず把握して理解しておくようにする。

 

スポンサーリンク

S3 Glacier

 

S3 Glacierは、S3と同様にイレブンナインの耐久性を持ちながら、さらに容量あたりの費用を抑えたアーカイブストレージサービス。

S3 Glacierにデータを保存するとデータの取り出しに時間がかかる。

また、S3のように保存するデータに対して名称を付けることはできず、自動採番されたアーカイブIDで管理することになる。

これらのことからS3 Glacierは、オンプレミス環境での磁気テープにように、長期間保存し、アクセス頻度が低く、取り出しにある程度時間がかかってもかまわないデータを保存するユースケースに適している。

S3 Glacierへのデータ保存は、APIによる操作かS3のライフサイクル管理機能によって行う。

もともとGlacierは、S3とは別の独立したサービスだったが、S3と統合して利用されることが多く、Amazon S3 Glacierと名前を変え、S3のストレージクラスの1つと位置付けられるようになった。

★S3 Glacierは、イレブンナインの耐久性を持ちながら、容量あたりの費用を抑えたアーカイブストレージサービス。長期保存が求められる、アクセス頻度の低い、取り出しにある程度時間がかかってもかまわないデータの保存に適している。

 

S3 Glacierの構成要素

 

S3 Glacierは次の4つの要素から構成される。

基本的な構造はS3と同じ。

・ボールト:アーカイブを保存するための領域。S3のバケットに相当する。ボールト名はリージョン及びアカウント内であれば良いため、他のアカウントで利用されていても使用できる

・アーカイブ:S3 Glacierに格納されるデータ自身。S3のオブジェクトに相当する。各アーカイブには一意のアーカイブIDとオプションの説明が割り当てられる。アーカイブIDには138バイトのランダムな文字列が自動的に付与される。利用者が指定することはできない

・インベントリ:各ボールトに保存されているアーカイブの情報(サイズ、作成日、アップロード時に指定されたアーカイブの説明など)を収集する。およそ1日1回の頻度で更新されるため、最新の情報が反映されるまでにはタイムラグがある。リアルタイムで状況を確認したい場合は、マネジメントコンソールで確認するか、ListVaults APIを実行する

・ジョブ:アーカイブやインベントリに対して検索をかけたり、データをダウンロードするといった要求に対して処理を実行し、処理の状況を管理する

 

データの取り出しオプション

 

S3 Glacierにアーカイブしたデータを閲覧するには、データの取り出しリクエストを出す。

取り出しリクエストを出してから実際に取り出せるようになるまでの待ち時間に応じて、高速、標準、バルクの3種類のリクエストオプションがある。

待ち時間が短いほど、取り出しやリクエストにかかる費用が高くなる。

次の日に見られれば十分だといった場合には、「バルク」オプションを利用すると良い

 

S3 Glacier Select

 

通常、S3 Glacierに保存したデータを参照するには、対象アーカイブの読み出しリクエストを出して一定期間待つ必要がある。

S3 Glacier Selectは、アーカイブデータに対してSQLを実行して、条件に合ったデータを抽出する機能。

対象のアーカイブデータは非圧縮のCSV形式でなければならないなどの条件はあるが、特定のデータだけをアーカイブから簡単に取り出すことができる。

 

データ暗号化

 

S3 Glacierにデータを保存する時にはSSLを使ったデータ転送が行われる。

また、S3 Glacierに保存されるデータは標準で暗号化が行われる。

独自の暗号化方式でデータを暗号化したい場合は、S3 Glacierに保存する前にデータを暗号化する。

 

削除防止機能(ボールトロック)

 

コンプライアンス上の理由により、アーカイブしたデータの変更・削除をできなくするという要件が出てくる場合がある。

その場合の実現方法の1つとしては、S3のバケットポリシーやIAMの権限で実施できる人を制限する方法が考えられる。

もう1つの方法として、S3 Glacierの削除禁止機能(ボールトロック)を利用して、AWSの機能を使って削除できなくするという方法もある。

ボールトロックは、S3 Glacier APIを通じてボールトロックポリシーを対象とするボールト(アーカイブ格納のためのコンテナ)に要求することから始まる。

ボールトロックポリシーは、例えば5年経過するまで、ユーザーにアーカイブを削除する権限を拒否するといった内容。

ポリシーがボールトと関連づけられるとボールトロックがInProgressの状態になりロックIDが返される。

ユーザーがこのロックIDを使ってボールトロックの開始を要求するとロック処理が完了し、この後の変更・削除ができなくなる。

またInProgress状態のまま24時間放置していると、自動的にロック処理は中断する。

 

Storage Gateway

 

Strage Gatewayは、オンプレミスにあるデータをクラウドへ連携するための受け口を提供するサービス。

Strage Gatewayを使って連携されたデータの保存先には、S3やS3 Glacierといった、耐久性が高く低コストなストレージが利用される。

また、Strage GatewayのキャッシュストレージとしてEBSが使われる。

このように、Strage Gatewayはサービスとして独自のストレージを持っているわけではない。

様々なストレージを組み合わせて、オンプレミスとAWS間のデータ連携を容易にするためのインターフェイスを提供するサービスだと考えられる。

オンプレミスとのハイブリッド環境であり、参照頻度が高いデータはオンプレミスの高速ストレージに保存し、参照頻度が低いデータやバックアップデータはStrage Gatewayを利用してクラウドに保管するといった使い分けもできる。

そのため、利用目的を明確にすることで、大容量のデータを効率的に管理できる。

Strage GatewayはVMwareやHyper-Vの仮想アプライアンスとしてイメージが提供されており、オンプレミス環境に該当のハイパーバイザーがすでに存在する場合は簡単に導入できる。

また、EC2インスタンスのStrage Gateway用AMIも用意されているため、AWS上にゲートウェイを配置する構成も可能。

★Strage Gatewayは、オンプレミスにあるデータをクラウドへ連携するためのインターフェイスを提供するサービス。独自のストレージを持たず、S3、S3 Glacier、EBSなどを利用する

 

Strage Gatewayのタイプ

 

Strage Gatewayには、ファイルゲートウェイ、ボリュームゲートウェイ、テープゲートウェイの3種類のゲートウェイタイプが用意されている。

ボリュームゲートウェイには、さらにキャッシュ型ボリュームと保管型ボリュームの2つのボリューム管理方法がある。

データの参照頻度や実データの配置場所の違いなどの要件によって最適なゲートウェイを選択する。

 

ファイルゲートウェイ

 

S3をクライアントサーバーからNFSマウントして、あたかもファイルシステムのように扱うことができるタイプのゲートウェイ。

作成されたファイルは非同期ではあるが、ほぼリアルタイムでS3にアップロードされる。

アップロードされたファイルは1ファイルごとにS3のオブジェクトとして扱われるため、保存されたデータにS3のAPIを利用してアクセスすることも可能。

注意点として、データの書き込みや読み込みの速度がローカルディスクに比べて遅いことが挙げられる。

保管後のデータに対してS3のWeb APIでアクセスするようなユースケースでは有用なゲートウェイタイプ。

もし、単純なNFSサーバーとしてのユースケースであれば、EFSなどの別サービスを検討する。

 

ボリュームゲートウェイ

 

データをS3に保存することはファイルゲートウェイと同じだが、各ファイルをオブジェクトとして管理するのではなく、S3のデータ保存領域全体を1つのボリュームとして管理する。

そのため、S3に保存されたデータにS3のAPIを利用してアクセスすることはできない。

クライアントサーバーからこのタイプのゲートウェイへの接続方式はNFSではなく、iSCSI接続になる。

ボリュームはスナップショットを取得することができるため、スナップショットからEBSを作成し、EC2にアタッチすることで、スナップショットを取得した時点までのデータにアクセスできるようになる。

 

キャッシュ型ボリューム:頻繁に利用するデータはStrage Gateway内のキャッシュディスク(オンプレミス)に保存して高速にアクセスすることを可能とし、すべてのデータを保存するストレージ(プライマリストレージ)としてS3を利用するタイプのボリュームゲートウェイ。データ量が増えたとしてもローカルディスクを拡張する必要がなく、効率的に大容量データを管理できる。キャッシュ上に存在しないデータにアクセスする場合はS3から取得する必要があるため、データ読み込みの速度がシステム上問題になる場合には適さない。キャッシュ型ボリュームゲートウェイでは、キャッシュボリュームとアップロードバッファボリュームにストレージを使用する。オンプレミスの場合は仮想アプライアンスが実行される環境にあるストレージを利用し、AWSにStrage Gatewayを構成する場合にはEBSを利用する。キャッシュボリュームは頻繁に使用するデータに対して高速にアクセスするためのもので、アップロードバッファボリュームはS3にアップロードするデータを一時的に保管するためのもの。

 

保管型ボリューム:すべてのデータを保存するストレージ(プライマリストレージ)としてローカルストレージを利用し、データを定期的にスナップショット形式でS3へ転送するタイプのボリュームゲートウェイ。S3へ転送されたスナップショットはEBSとしてリストア可能なため、必要に応じてEC2インスタンスにアタッチすることでデータを参照することができる。全てのデータがローカルストレージに保存されるため、データへのアクセス速度はStrage Gateway導入によって変化することはない。オンプレミスのデータを定期的にクラウドへバックアップする用途に適している。

 

テープゲートウェイ

 

テープデバイスの代替としてS3やS3 Glacierにデータをバックアップするタイプのゲートウェイ。

物理のテープカートリッジを入れ替えたり遠隔地にオフサイト保存するといったことをする必要がなくなる。

サードパーティ製のバックアップアプリケーションと組み合わせることができるため、すでにバックアップにテープデバイスを利用している場合は、比較的簡単にStrage Gatewayへ移行が可能。

 

Strage Gatewayのセキュリティ

 

Strage Gatewayのセキュリティ要素には次の3つがある。

CHAP認証:クライアントからStrage GatewayにiSCSIで接続する際に、CHAP認証を設定することができる。CHAP認証を設定することで、不正なクライアントからのなりすましを防止でき、また、通信の盗聴といった脅威に対するリスクを軽減できる。

データ暗号化:Strage GatewayではAWS KMS を使ってデータの暗号化が可能。暗号化されるタイミングはデータが保管されるときであるため、S3に保存されるタイミングで暗号化される。また、暗号化されたボリュームから取得したスナップショットも同じキーで暗号化されている。

通信の暗号化:オンプレミス環境からStrage Gatewayを経由してS3にデータを転送する際にはHTTPSが使用されるため、通信時のデータ内容は暗号化される。

 

FSx

 

ストレージ種別

 

ストレージには用途・形態ごとに、いくつかの種別がある。

代表的なのが、ブロックストレージ・ファイルストレージ・オブジェクトストレージ。

 

ブロックストレージ

 

ブロックストレージは、記録領域をボリュームという単位に分割し、ブロックという単位で呼び出すストレージ。

ハードディスクはブロックストレージの物理的な実装。

ハードディスクの場合は物理的な単位に制約されるが、クラウドのブロックストレージは、バックエンドのストレージを論理的にまとめて必要なサイズを自由に使うことができる。

ブロックレイヤーは、人間が直接扱うというより、OSが管理するような低レイヤーのストレージになる。

 

ファイルストレージ

 

ファイルストレージは、データをファイルとフォルダ(ディレクトリ)といった階層的な構造で管理する。

こちらはいわゆるファイルサーバーのようなイメージ。

ユーザーは、ストレージ上のデータを個々のファイル単位で扱う。

WindowsやLinuxなどのOSを介して扱っているのがファイルストレージであり、それをネットワーク越しに利用できるようにしているのがNAS。

 

オブジェクトストレージ

 

オブジェクトストレージは、データをオブジェクトという単位で扱うストレージ。

データをファイルという単位で扱うファイルストレージと似ているが、オブジェクトストレージではオブジェクトを一意に識別するIDと、それを管理するメタデータで構成されている。

ファイルストレージのように階層的な構造ではなく、フラットな構造で管理されているために拡張性が高いというメリットがある。

データへのアクセスは、一般的にはREST APIを通じて行われる。

他の2つのストレージに比べて、アプリケーション的な側面の強いストレージとなる。

 

FSx

 

Fsxはフルマネージドなファイルストレージ。

Windows向けでビジネスアプリケーションなどで利用されるAmazon FSx for Windowsファイルサーバーと、ハイパフォーマンスコンピューティング向けのAmazon FSx for Lustreの2種類のストレージがある。

 

Amazon FSx for Windowsファイルサーバー

 

Amazon FSx for Windowsファイルサーバーは、名前の通りWindows用のサービスで、フルマネージドなWindowsのファイルサーバーとして使える。

Windowsサーバー上に構築されているので、Windowsで利用できるユーザークォータ、エンドユーザーファイルの復元、Microsoft Active Directory(AD)統合などの幅広い機能が利用可能。

Amazon FSx for Windowsファイルサーバーは単一のサブネットにエンドポイントとなるENIを配置し、そのエンドポイントにはSMBプロトコルを介してアクセス可能。

ENIにはセキュリティグループを適用できるので、それを利用してネットワーク的な制限を加えることができる。

またフルマネージドサービスということもあり、Windowsアップデートや各種パッチ当てなどのメンテナンスはAWS側で行われる。

また、ストレージサイズやスループットなどの指定・変更が可能。

 

Amazon FSx for Lustre

 

Amazon FSx for Lustreはフルマネージドな分散ファイルシステムで、S3とシームレスに統合できる。

Lustreはfor Windowsより特徴的なアーキテクチャを持つ。

Lustreはファイルシステム作成時にS3のバケットと関連づけする。

そしてS3上のファイルをインデックスし、あたかも自前のファイルのように見せる。

初回アクセス時はS3から取得するため遅いが、2回目以降はキャッシュしているため高速。

高速なデータアクセスが必要なハイパフォーマンスコンピューティングで使用され、機械学習やビッグデータ処理などに使われる。

ENIを利用したエンドポイントを作るといった点や、フルマネージサービスという点ではfor Windowsと同じ。

LustreはLinux用のサービスで、利用の際は専用のクライアントソフトをインストールする必要がある。

インストール後は通常のNASのようにマウントして利用できる。

 

まとめ

 

ストレージサービス

・AWSでは、EBS、EFS、S3、S3 Glacier、Storage Gatewayという5つのストレージサービスが提供されている。このうちEBSはブロックストレージ、EFSはファイルストレージ、S3とS3 Glacierはオブジェクトストレージ

・EBSはブロックストレージサービスで、EC2のOS領域、EC2の追加ボリューム、RDSのデータ保存領域などに使用する

・EFSは、容量無制限で複数のEC2インスタンスから同時にアクセス可能なファイルストレージサービス。システムに最適なモードを選択して使う必要がある。

・S3は、非常に優れた耐久性を持つ、容量無制限のオブジェクトストレージサービスで、様々な用途に利用できる

・S3 Glacierは、イレブンナインの耐久性を持ちながら、容量あたりの費用を抑えたアーカイブストレージサービス。長期保存が求められる、アクセス頻度の低い、取り出しにある程度時間がかかってもかまわないデータの保存に適している

・Storage Gatewayは、オンプレミスにあるデータをクラウドへ連携するためのインターフェイスを提供するサービス。独自のストレージを持たず、S3、S3 Glacier、EBSなどを利用する





-お仕事

© 2024 ポンサラの逆襲