CHAPTER1 Data Stores

Glaicer Vlotlock

Amazon S3 Glacier ボールトロック - Amazon S3 Glacier

Glaicerには

  • Vlotロック
  • Vlotアクセスポリシー

が存在する。VlotとはS3でいうところのバケットであり、バケットに対するアクセスポリシーとバケットそのものに対するロックに2つがサービスとして提供されている。

ボールトロックを使用すると、規制要件およびコンプライアンス要件を適用するのに役立てることができます。

更に

ボールトロックポリシーの例として、ポリシーを削除する前に 1 年間そのアーカイブを保持するように指定されていると仮定します。この条件を導入するには、アーカイブが 1 年経過するまで、ユーザーにそのアーカイブを削除する権限を拒否するボールトロックポリシーを作成します。

とある。

Vlotlockは一度かけてしまうと変更が効かないため、設定後24時間以内にそのポリシーを検証できる猶予が与えられる。この期間をInProgressと呼んでいて、この期間にロックIDを利用してロックを有効化する必要がある。このInProgressの期間に有効化処理を行わなければ、ロックポリシーは破棄され、ロックは行われない。

ロックの有効化処理の方法については下記に記載されている。

ボールトロックの完了 (ロック ID の POST) - Amazon S3 Glacier

EBS Snapshit

Amazon EBS スナップショット - Amazon Elastic Compute Cloud

Snapshotは増分だけなので、安価にバックアップが取れる。 かといって、過去のSnapshotを削除してもそれ以降のバックアップが復元不可能になる事もない。

Amazon EBS スナップショットの削除 - Amazon Elastic Compute Cloud

スナップショットの保存は増分ベースで行われるものの、最新のスナップショットさえあればボリュームを作成できるようにスナップショット削除プロセスは設計されています。

個人的に増分スナップショットの仕組みはすごく画期的だと思う。

ボリュームのスナップショットはLinuxでも出来るようだが、増分スナップショットは出来るのだろうか。

EFS

そもそもEFSは非常に高いIOPSを要求されるような場面、例えば数千のEC2インスタンスやらECSコンテナから並列でアクセスを受けるような場合でも安定したIOを実現するような高パフォーマンスなファイルシステムである。

EFSはオンプレミスとの接続にも対応しているが、ストレージとしてオンプレミスを利用せず直接EFSに保存するような構成は非常に帯域幅の大きい安定したネットワークを要求される。通信は暗号化されないのでオンプレミス↔AWS間の通信の暗号化にはDirectConnectやVPNが必要になる。

実際にはオンプレミスのストレージと内容を同期するDataSyncなどを活用して、オンプレミスのファイルをクラウド環境にアップロードするターゲットとして利用されるようだ。

EFSは基本的に高価なサービスである。EFSはEBSの3倍、S3の20倍高価であることを頭に入れておく。

またEFSはAZがダウンした場合のフェイルオーバーの挙動に注意する必要がある。EFSはManaged Serviceではあるが、MountTragetというエンドポイントはVPCの中に設置する。そのためAZ障害が発生した場合は、エンドポイントも一緒にダウンしてしまう。

【EFS】マウントターゲットはフェイルオーバーしない | DevelopersIO

Amazon EFS ファイルシステムは、一度に 1 つの VPC にのみマウントターゲットを持つことができます。

高可用性の為には、Multi-AZ構成で各AZに配置した個別のMountTargetのうちのいずれかが生き残るようにしなければならない。

StrageGateway

StrageGatewayとは

の総称のこと。 File Gatewayはあまり問題に出てこないので触れておくと、オンプレミスでNFSやSMBで構築されていたファイルシステムを全てAWS上に展開し、S3にデータをマウントするシステム。

そもそもオンプレミスでNFSやSMBのファイルシステムがどのように構築されていたかを知る必要がある。

NASの仕組み

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

FileSystemを提供するにはファイルシステム仲介サーバ(NAS)と各クライアントがNFSまたはSMBのプロトコルで連携する一方で、ファイルシステムサーバ(NAS)側はストレージブロック(HDDとか)に対してiSCSIなどのプロトコルを利用してハードウェアへ直接書き込み制御を行っている。

注意すべきはクライアントが直接ストレージブロックに対する書き込みを行っている訳ではない点である。iSCSIとはSCSIというプロトコルを(IP)パケットまたは(Ethernet)フレームにカプセル化する技術だが、SCSIによる書き込みコマンド自体はファイルシステム仲介サーバ(NAS)が取り持つことになる。

このファイルシステム仲介サーバ(Network Attached Strage≒NASと呼ばれる)に特化したOSもあるようでiSCSIの対応などがうたわれている。

TrueNAS - Wikipedia

ちなみにファイルシステムサーバ(NAS)にWinndowsを利用してWindows固有のファイルシステムの機能を利用することが出来る。これがSMBプロトコルであるが、サーバにLinuxを用いつつWindowsファイルシステム機能を提供するフリーソフトSambaといい(SMBから来ている)オーストラリア人のプログラマによって開発された。

Samba - Wikipedia

FileGtewayとVloumeGateway

FileGatewayとVloumeGatewayの最大の違いは、オンプレミスのNASを残すかどうかにある。

ファイル向け AWS Storage Gateway | AWS

FileGatewayの場合はストレージシステムそのものを全てAWSマイグレーションしてしまうため、クライアントから直接FileGatewayを参照する形になる。 これはつまり、FileGateway自体がクライアントに対してNFS/SMBサービスサーバを提供することになる。

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

一方VloumeGatewayにおけるAWSの役割は、既存のNASサービスに対する補助である(NASとして提供するストレージのバックアップや置換)。 VolumeGatewayは既存のNASを主/VloumeGatewayを従としており、既存のNASに対してiSCASIのクライアントとして機能する。