EBS(Elastic Block Store)
インスタンスの実行中に取り付けられるネットワークドライブ(物理ドライブではない)
ネットワーク経由で通信するため、SATAやIDEのような物理ドライブ接続と比較すると若干遅いらしい
EC2インスタンスから切り離して、別のインスタンスに素早く接続することができる
インスタンスのデータを保存(永続化)させることができる
内部的に冗長化されており、更なる冗長化は原則不要(EBS作成時点で、ルートボリュームのスナップショットが自動作成)
1つEBSはの1つのインスタンスにのみマウントできる(例外:io1 / io2はEBSマルチアタッチに対応:条件厳しい)
1つのインスタンスに対して複数のEBSボリュームをアタッチすることはできる
デフォルトでは、AZ内にロックされる(別AZのインスタンスにEBSボリュームを持ち運びはできない)
別のAZに持ち運びをするときには、EBS Snapshot スナップショットを作る必要がある
プロビジョニングされた容量(GB単位の容量、速度IOPS(In/Out Per Second))を持つ
プロビジョニングされたすべての容量に対して課金が発生する(データが空っぽでも全額かかる)
少し時間はかかるが、後から容量を増やすこともできる
EBSボリュームは、必ずしもインスタンスにアタッチしなくても良い
後からアタッチした場合は、EBSインスタンスをマウントするための操作(コマンド)の必要がある
EC2インスタンスを終了したときに、アタッチしているEBSボリュームを同時に終了することもできる
例えるなら「ネットワークでつながるUSBメモリ」
30GBまでは無料利用枠で使える
EBSボリュームタイプ(6つ)
IOPS(I/O Ops Per Sec.):同じ時間に何回データを読み書きできるか
スループット:同じ時間にどれだけの量を読み書きできるか
gp2 / gp3(SSD)多様なワークロードに対応する、価格と性能のバランスが取れた汎用SSD
コストパフォーマンスに優れたストレージ、低レイテンシ
システムブートボリューム、仮想テスクトップ、開発・テスト環境
最小1GiBから最大16TiBまで
・gp3:ベースライン 3,000IOPS、スループット125MiB/s
最大 16,000IOPS、1,000MiB/sまでそれぞれ個別に向上させることが可能
・gp2:IOPSはボリュームサイズ連動で、1GBあたり3IOPS向上。つまり5,334GBで最大 16,000IOPSに到達。
io1 / io2(SSD)ミッションクリティカルな低レイテンシまたは高スループットのワークロードに対応する最高性能のSSD
16,000IOPS以上を必要とするアプリを使うときはこちら
・io1 / io2(スループット4GiB~16TiB)
最大PIOPS:Nitro EC2インスタンスは64,000IOPS、その他は32,000IOPS
ボリュームサイズに依存せずにPIOPSを向上させることが可能
io2は耐久性が高く、GiBあたりのIOPSが高い(io1と同価格)AWSでは「高性能だが同価格/安い」が良くある
・io2 Block Express(スループット4GiB~64TiB)
サブミリ秒のレイテンシー
最大PIOPS:256,000 IOPS:GiB比は1,000:1
・EBSマルチアタッチ対応
同じAZ内の複数のEC2インスタンスに同じEBSボリュームをアタッチ
各インスタンスは、ボリュームに対する完全な読み取りと書き込みの権限を持つ
クラスタ対応のファイルシステムを使用する必要がある(Linuxのxfs, ex4、WindowsのNTFS, FAT32は不適)
st1(HDD)比較的低コストのHDDボリューム 頻繁にアクセスされるスループット重視のワークロード向け
ビッグデータ、データウェアハウス、ログ処理
最大 500IOPS スループット500MiB/s
sc1(HDD)最も低コストのHDDボリューム アクセス頻度の低いワークロード向け
最大 250IOPS スループット250MiB/s
EBSボリュームの特性:サイズ、スループット、IOPS(I/O Ops Per Sec.)
随時更新されるので、常にAWSのドキュメントを参照すること!
ブートボリュームとして使用できるのはSSDのみ!
EBS RAIDオプション
OSが対応していればRAIDでミラーリングが可能
基本はRAID0とRAID1しか推奨されていない
RAID0:複数のEBSに分散して書き込む(手軽にサイズが増えるが、1台のディスクが故障すると全滅する)
RAID1:複数のEBSにミラーリングする(NW負荷が2倍に増えるが、1台のディスクが故障してもひとまず動く)
AMI(Amazon Machine Image)
EC2インスタンスのカスタマイズ
ソフトウェアや設定、OS、モニタリングなどを追加できる
事前に各種ソフトウェアが設定済みなので、起動・設定の時間が短くなる
AMIはリージョンごとに作成され、リージョンまたぎのコピーも可能
EC2インスタンスを起動する方法
パブリックAMI:AWS提供
自身で作ったAMI:自身で作成・メンテナンス可能
AWSマーケットプレイスAMI:他人が作成したAMI(無償・有償)もあるし、自作AMIを販売することも可能
AMI作成のプロセス
EC2インスタンスを起動して、カスタマイズ
インスタンスを停止(データ一貫性のため)
AMIの作成 同時にEBSスナップショットも作成される
作成したAMIでEC2インスタンスを起動(別AZで使うこともできる)
停止済み(・終了済み)インスタンスから、ユーザデータを取得
それを新規インスタンス作成時のユーザデータに貼り付ける
EFS(Elastic File System)
複数のEC2でマウント可能なマネージドNFS(ネットワークファイルシステム)
複数のAZにあるEC2に対応
デフォルトで自動バックアップ
高可用性、高スケーラビリティ、高価(gp2の3倍)、従量課金(pay per use)
使用例:コンテンツ管理、ウェブホスティング、データ共有、WordPress
一般的なNFS v4.1 プロトコルを使用
EFSへのアクセス制御にはセキュリティグループを使用する
LinuxベースのAMIに対応(Windowsは不可)
ファイル内容はKMSを利用して暗号化される(コンソールから作成時はデフォルト有効)
POSIX(UNIX系OSのAPI標準プロトコル)に準拠
ディスク容量は自動的に拡張され、使用した分だけの支払いとなる(これがElasticたる所以か)
スケーラビリティ
数千のFGSクライアントの同時接続(スループット10GB+/s)
自動的にペタバイト規模のネットワークファイルシステムに成長
パフォーマンスモード(EFS作成時に設定)
汎用:レイテンシーに影響を受けやすいユースケース(Webサーバー、CMSなど)
最大I/O:高レイテンシ、高スループット、高並列(ビッグデータ、メディア処理)
スループットモード
拡張:さまざまなパフォーマンス要件があるワークロードのために、より高い柔軟性とスループットレベルを提供
伸縮自在(推奨):I/O が予測できないワークロードに使用
プロビジョニング済み:ストレージサイズに拘らずスループットを個別設定できる 例)1TBに対し1GiB/s)
バースト:スループットはストレージサイズに応じてスケール 1TB=50MiB/s+最大100MiB/sのバースト
ストレージ階層
標準:頻繁にアクセスするファイル用
頻繁でないアクセス(EFS-IA):低性能、低価格 ※ IA(Infrequent Access)
ライフサイクル管理機能:30日後に低頻度アクセス(IA)に移動、【拡張】90日後にアーカイブに移動
EFSの作成
デフォルト
★1つのEFSを2台のEC2インスタンスにアタッチし、ファイルを共有・読み書きし合うテスト★
EFSをEC2インスタンスにアタッチ
まずツールを各インスタンスに amazon-efs-utils package をインストール
Manually installing the Amazon EFS client
Installing the Amazon EFS client on Amazon EC2 Linux instances
To install the amazon-efs-utils package from the AMI package repository on Amazon EC2 Linux instances
Generic Highlighting
EnlighterJS Syntax Highlighter
SSHか何かでEC2にログインしてインストール
EFSマウントヘルパーを使ってアタッチ
「efs」というマウントポイントが必要らしいので、efsディレクトリを先に作成する
Generic Highlighting
EnlighterJS Syntax Highlighter
EFSにアタッチしたセキュリティグループ側でポートが遮断されているので、アクセスを許容してあげる
ポイント
タイプ・・・タイプ「NFS」を選択 ※Network File System
ソース・・・EC2側にアタッチしたセキュリティグループを選択
EFSマウントヘルパーだとうまくいかない・・
てか、「DNS経由でマウント」で失敗しているような(何らかのDNSサーバ連携設定が必要とか?)
…ということでIP経由でNFSクライアントを使ってマウント
なんかできたっぽい・・?
片方のインスタンスでファイルを作成し、他のインスタンスから見えるか実験
(同じEFSをアタッチできているなら、他EC2からもファイルが見られるはず)
おぉ~・・・見れた!EFSが共有できているね!以上!
EC2インスタンスストア
EBSボリュームはネットワークドライブの為、性能は良いが限界がある
高性能なハードウェア接続のディスクが必要な時は、EC2インスタンスストア(ローカル接続)を使おう
より高いI/Oパフォーマンス
エフェメラル(停止時に内容が失われる)
バッファ/キャッシュ/生成データ/一時コンテンツに適している
ハードウェア故障によりデータが失われるリスクがある
バックアップ・複製は利用者の責任
EBS vs EFS vs インスタンスストア それぞれの特徴
EBS(Elastic Block Store)
EBSボリューム
・1度に1つのインスタンスにしかマウントできない
(例外:io1 / io2はEBSマルチアタッチに対応:条件厳しい)
・AZレベルでロック
・gp2:ディスクサイズが大きくなるとIOPSが増える
※gp=General Purpose(一般的用途)
・io1:独立してIOPSを増やすことができる
EBSボリュームをAZ間で移行するには
・スナップショットを撮る
・スナップショットを別のAZに復元する
・EBSのバックアップはIOを使用するため、アプリが大量のトラフィックを処理中などは実行しないことを推奨
EC2インスタンスが終了した時、インスタンスのルートEBSボリュームはデフォルトで削除される(無効にもできる)
EFS(Elastic File System)
・AZまたぎで100台以上のインスタンスをマウント
・EFSでサイトのファイルを共有(WordPress)
・Linuxインスタンス(POSIX)のみ
・EBSよりも高価
・低頻度アクセス(EFS-IA)を活用してコスト削減が可能
EC2インスタンスストア
高性能なハードウェア接続のディスク(ローカル接続)
より高いI/Oパフォーマンス
エフェメラル(停止時に内容が失われる)
バッファ/キャッシュ/生成データ/一時コンテンツに適している
ハードウェア故障によりデータが失われるリスクがある
バックアップ・複製は利用者の責任