Ch6. ストレージ

ストレージサービスは大きく3つに分類できる。

  • ブロックストレージ】データを物理的なディスクブロックに保存するサービス。データベースの保存領域はここに該当する。この3つの中で最もパフォーマンスの高いストレージである。
  • 【ファイルストレージ】ファイルシステムにデータを保存するサービス。SharePointDropBoxのようなもの。
  • 【オブジェクトストレージ】ファイルにメタデータを付与して管理するサービス。ファイルに対する直接の操作(削除・追加)は出来ず、HTTPリクエストなどサービスが提供する手段でファイルを管理する。

EBS

AWSが提供する【ブロックストレージ】サービス。

Ch4. コンピューティングの章でも述べたが、EC2のOS保存領域として使われる。基本的にEC2と1対1で紐付くものなので、同じEBSに複数のEC2インスタンスからアクセスすることは難しい*1

また、EC2とEBSのAZが離れるような設計も基本的にはサポートされていない(AZのスナップショットをEC2インスタンスと同じAZにコピーすることで対応することは一応可能)。 ハードウェアのタイプに応じて4種類用意されている。

  • 【汎用SSD】EC2インスタンスのデフォルトEBS。IOPSと呼ばれる書き込み性能に応じて様々なバリエーションが用意されている。また、一時的なパフォーマンス向上を図ったバースト機能などが実装されている(ただしバースト機能に頼った設計はご法度)。
  • 【プロビジョンドIOPS SSD最も高性能なEBS。RDSやEC2でデータベースをホストする場合に利用される。任意のIOPSの値に設定が可能。
  • スループット最適化HDD】大量のファイルを高速に読み取りたい場合、例えばバッチ処理のための大量のデータを格納しておくことなどに利用できる。
  • 【Cold HDD】最も安価なEBS。アーカイブなどの保存に利用できる。

EBSの拡張・タイプの変更・バックアップはかなり柔軟に実施することが出来る。ただし、一度作業を実施すると次の作業までに6時間のインターバルを設ける必要がある。

拡張

容量の拡張が可能である。但し縮小は出来ない。OSには記憶領域の容量が拡張した旨を認識させる設定が別途必要である(勝手に容量拡張は認識してくれない)。

タイプ変更

IOPSが不足している場合でも過剰な場合でも変更可能。プロビジョンドIOPSを利用した場合、IOPSの値だけを変更してプロビジョニングすることも可能(変更には24時間以上かかる場合があるらしい)。

バックアップ

EBSはマネージドサービスなので、AWSが勝手にバックアップを取ってくれる。ハードウェア故障が発生しても自動的にバックアップが作動するため、ユーザーは障害を意識することなく作業出来る。 とはいえ、マネージドサービスだからバックアップを取らなくて良いわけではない。EBSのスナップショットを作成するオプションがあるので、利用を検討する。

EBSは(ラップトップのSSDなどと同じく)EBSそのものの暗号化が可能である。既に作成してしまったEBSを直接暗号化することは出来ないが、スナップショットを利用して、スナップショットまるごと暗号化してから新規のEBSを作成することも可能になっている。

EFS

【容量無制限】のファイルストレージ。EBSと大きく異なり、複数のEC2インスタンスから同時アクセスが可能である。 一般的なファイルストレージシステムプロトコルに沿っているので利用にあたって、特に作業は必要ない。

Network File System - Wikipedia

EFSにファイルを作成すると、自動的に3か所以上のAZに同時に保存される。各AZにはマウントターゲットと呼ばれるEFSへのインターフェースが作成される。

最もこれを利用者側が意識することはほとんどなく、全てのAZに存在する全てのEC2から同じターゲットポイント(接続FQDNとも呼ぶ)を通して接続されるため、利用者は一つにファイルシステムに対する操作をしているのと同じになる。

EFS側は接続FQDNを呼んだEC2と同じAZにあるマウントターゲットを自動で判別し、それを介してストレージに対する操作を行うため、I/Oのレイテンシーが低くなるよう設計されている。

パフォーマンスモード

数百台~数千台のEC2から同時にアクセスを受けるようなファイルシステムを構築する場合、最大IOパフォーマンスモードというモードが選択できる(ただし各ファイル操作のレイテンシが少し大きくなる)。

それ以外の場合は汎用パフォーマンスモードで問題ない。

どちらを利用するか判断するために、EC2からのIOがどの程度になっているかPercentIOLimitというメトリクスで確認できる。このパフォーマンスモードは最初にEFSを作成するときに決定し、後から変更できないので決定には慎重を要する。

スループットモード

通常のEFS利用の範囲では「バーストスループットモード」が選択される。

このモードでは一定以上のスループット(ベースラインスループットよ呼ぶ)が要求されるようになると、12時間毎に付与されるバーストクレジットを消費しながら一時的に高パフォーマンスなIOを実現してくれる。

スポット的に高パフォーマンスが要求されるような状況では、このモードで問題ない。

バーストクレジットの消費状況はCloudWatchのBurstCreditBalanceというメトリクスを参考にする。このクレジットを毎回使い切ってしまうような状況では次の「プロビジョニングスループットモード」を選択しよう。

一方、常にベースラインスループットを超えるようなパフォーマンスが求められる場合は、プロビジョニングスループットモードを選択する。任意のスループット値を設定することが出来る(増減どちらも可能)。

(ファイルの大きさは小さくとも)頻繁なアクセスがある場合・大量のインスタンスからのアクセスがある場合はこちらを選択する。

プロビジョニングスループットモードは例えばWebアプリケーションの配信用コンテンツ(大量アクセスが考えられる)などで利用される。

S3

S3の利用用途として、通常のファイル保存の他に対木のようなものが考えられる。

  • EBSのスナップショットの保存
  • AutoScalingによって終了したインスタンスが吐いたログ

S3は「バケット」「オブジェクト」「メタデータ」の3つの構成要素によって成り立っている。バケット名はAWS内で一意である必要がある。

S3に保存するとオブジェクトは複数のAZのみならず、各AZの複数の物理記憶媒体に保存される。そのため、マルチAZ構成で運用していた場合最も近いAZのストレージからアクセスできる。ただし、各ストレージ間の同期は結果整合性方式と呼ばれるBestEffrot型になるため、アクセスAZ間で結果が異なる可能性はある。

S3はオブジェクトを取り出す頻度に応じて5つのサービスに分かれている。

ストレージクラス - Amazon S3 |AWS

  • S3標準
  • S3標準(低頻度アクセス)
  • S3 1Zone
  • S3 Intelligent Tiering
  • S3 Glacier
  • S3 Glacier Deep Archive

例えば【S3 Intelligent Tireing】はオブジェクトのアクセス頻度を考慮して(30日間アクセスがない)【S3標準】と【S3標準(低頻度アクセス)】間の移動を自動化してくれる。

【S3 Glacier Archive】や【S3 Glacier Deep Archive】は直接のファイル保存は出来ず、【S3】で管理されているオブジェクトを、より安価だがデータの取り出しに時間のかかるストレージに移動する。これらのストレージに保存した場合、アクセスには数分から数時間かかる。

ライフサイクル管理

S3に保存されるオブジェクトには「ライフサイクル管理」というものが設定できる。前述の【S3 Intelligent Tiering】もその一つでこれは「(一定の時間が過ぎたらストレージクラスを変更するという)移行アクション」である。

一方、一定期間アクセスの無かったオブジェクトを消去することを「有効期限アクション」と呼ぶ。(【S3標準(低頻度アクセス)】のように読み出しに対するコストがかかるものもあるが)基本的にS3は保存容量に対する重量課金制なので、これでコストの削減が出来る。

バージョニング管理

オブジェクトに対するバージョニングが可能だが、差分管理ではなくスナップショットを保存するだけなので使用容量が大幅に増える。

Webサイトホスティング

GithubPagesのような静的サイトのホストティングが可能になる。 保存したオブジェクトをホスティング対象に指定すると、FQDNが払い出されるのでそれを使ってアクセスできる。

ただしFQDNはランダムな値でしかないため、独自ドメインを利用したい場合はRoute53にドメインを登録してDNS設定してやる必要がある。 バケット名をアクセスしたいドメイン名に設定し、Route53にそのドメイン名をCNAMEとして設定してやることで、DNSにS3のバケットホスティング対象に指定できる。

署名付きURL

アクセスしたいオブジェクトに対して、期限付きのURLを発行できる。 発行したURLさえ知っていいれば、だれからもアクセス出来てしまう点に注意する。

データ暗号化

オブジェクトの暗号化はサーバー側で実施することも、クライアント側で実施することも出来る。 クライアント側で実施したい場合、AWS SDKを利用して暗号化する。オブジェクトのメタデータに復号に関する情報が記載されるため、クライアント側で再度復号を行う。

S3のその他の機能

S3にはその他にも様々な機能がある。教科書に載っている内容でもセキュリティに関する部分は省略している。 他のAZのS3にオブジェクトを転送する際に、必要な帯域幅を確保してくれる【S3 Transfer Acceleration】やS3のバケットから必要なオブジェクトを素早く洗い出すSQL方式のクエリーサービスである【S3 Select】などが提供されている。

S3 Glacier

前述したようにS3 GlacierもS3に統合されているものの、以前は別のサービスだったこともあってか多少用語が異なる。また、取り出しにや、格納コンテンツの確認には莫大な時間がかかるため、使い勝手も大幅に異なる。

S3のバケットに当たる保存領域をGlaicerではボールドと呼ぶ。またオブジェクトのことをアーカイブと呼ぶ。S3ではオブジェクトに名前を付与できたが、GlaicerにはランダムなIDが勝手に付与される。

Glaicerでは各ボールドんい保存されたアーカイブの情報を1日1回リストアップして提供する。このジョブをインベントリという。またデータの取り出しや、手動でのアーカイブの検索に対してもジョブを実行して必要な情報を取得する。

データの取り出しジョブは3種類に分かれており、【高速】【標準】【バルク】に分類されているが、【高速】がもっとも費用が高く【バルク】であれば最も安い。

Glacierに保存されるようなデータはコンプライアンス上【削除できないこと】という要件が科せられることがある。これはボールド丸ごと削除禁止の設定を行う【ボールドロック】という機能で実現できる。

Storage Gateway

オンプレミスのストレージとここまで学習してきた各AWSのサービスを連携させる仕組み。 クラウドのアプリケーションに対してストレージを提供するだけではなく、オンプレミス環境のアプリケーションに対してもクラウドのストレージを提供する、という観点が異なる。

  • オンプレミスをキャッシュサーバとして利用しつつ、全てのデータの保管(プライマリサーバ)をAWSのマネージドサービスで行う
  • 全てのデータの保管(プライマリサーバ)をオンプレミスで行いつつ、キャッシュサーバとしての役割をAWSのマネージドサービスで行う

の2種類に大別される。

ファイルゲートウェイ

S3のストレージの保存先としてオンプレミスのサーバを利用するイメージ。

オンプレミスサーバにアップロードされたオブジェクトはS3のオブジェクトとして、S3のAPIを介して操作が出来る。ほぼリアルタイムでS3に反映されるが、当然S3の操作対象はオンプレミスサーバになるのでレイテンシが発生する。 ファイル向け AWS Storage Gateway | AWS

ボリュームゲートウェイ

オンプレミス環境のアプリケーション対して、クラウドのストレージを提供している。今まで見えてきたマネージドサービスのほとんどが、クラウド環境のアプリケーションに対するサービスであることを考えると少し異質な存在である。

ボリュームゲートウェイ – AWS Storage Gateway | AWS

この場合、オンプレミス側の環境にiSCSI(アイスカジー)というシステムが必要になる。

今までEFSで見たようなNFS(Network File Strage)との違いは「パフォーマンス」の一言にまとめられるが、もう少し説明すると「iSCASIのストレージに対して読み取り・書き込みする際は、OS側がそれに対応して「AAAホストのXXXXというブロックに書き込む」という制御まで担っている。iSCASIのストレージは低レイヤの命令を実行するため、パフォーマンスが期待できる。

一方、NFSNFSのホスト自体がファイルシステムを構築する。 NFSをストレージとして利用しているホストは、「ccc.txtを更新する」という制御だけを行い、残りの書き込み制御はNFSホスト側で行う。またNFSストレージをホストしているOS自体が複数のファイルの同時アクセスに対応するため、利用者側はコンカレンシーを気にする必要がない。

iSCSI(アイスカジー)とは : 富士通

【図解】初心者にも分かる iSCSI の仕組み ~FCやNAS(NFS)との違いやメリット,デメリット~ | SEの道標

キャッシュ型ボリュームディスク

オンプレミス側に頻繁に利用されるデータをキャッシュ(キャッシュボリュームと呼ぶ)として保存しつつ、必要なデータ全体を保存するサーバとして(プライマリストレージと呼ぶ)S3を利用している。オンプレミス側にはキャッシュボリュームの他にもS3に対して、定期的にオンプレミスのデータに対してデータを移転するアップロードバッファ(サーバ)が必要になる。

キャッシュ上に存在しないデータはS3から取得してくる必要があるため、パフォーマンスの懸念がある場合は使用できない。

保存型ボリュームディスク

オンプレミスのサーバに存在するデータのスナップショットを定期的にS3に転送するサービス。キャッシュ型ボリュームディスクと異なり、必要なデータの全量をオンプレミスで保管するため、パフォーマンスも懸念はない。

S3に転送されたスナップショットのデータは、EBSのスナップショットに変換することが出来EC2から参照出来る。

テープゲートウェイ

オンプレミス側でテープとして保存されているデータをS3やS3 Glacierに保存するサービス。

FSx

ここにきてEFSとは異なるファイルストレージサービスについて述べる。

FSx for Windows

FSx for WindowsWindows Server上に展開されたファイルサーバをマネージドサービスとして提供するもの。豊富な機能を備えたWindowsファイルシステムの特徴をそのまま利用することが出来る。

EFSはLinuxのリモートストレージで一般的に利用されているNFSプロトコルに沿っているため、こうしたWindows固有の機能には対応していない*2

マネージドサービスなのでWindows Update等も勝手にやってくれる。

FSx for Luster

Luster自体はスーパーコンピューター等で用いる高性能なファイルストレージ。

Lustre (ファイルシステム) - Wikipedia

FSxとしてのLusterは自身に保存されるオブジェクトをS3のオブジェクトとして関連付けつつ、そのS3のオブジェクトをキャッシュすることで、高パフォーマンスなファイルI/Oを実現している。

*1:EBSマルチアタッチというサービスによって可能になったものの、インスタンスで起動しているOSは同じ記憶媒体を2つのインスタンスで併用するような機能は想定されていない。そのため、EBSの排他制御をユーザが検討する必要があるわけで、非常に利用が困難。

*2:WindowsNFSプロトコルのリモートストレージを利用できない、という意味ではない点に注意。Windows固有のシステムが利用できないだけ