_AWS-BlackBelt-EBS_updated

Transcription

1 AWS Black Belt Online Seminar Amazon Elastic Block Store(EBS) 2017/12/7 Updated アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト 林正 1

2 紹介 林正 ( こばやしまさと ) インダストリソリューション部 部 / シニアソリューションアーキテクト 主に 企業のお客様を担当し いわゆる社内 IT のみならず BtoC システムも含め幅広い分野でお客様をご 援 好きな AWS のサービス : 2

3 内容についての注意点 本資料では 2017 年 12 7 時点のサービス内容および価格についてご説明しています 最新の情報は AWS 公式ウェブサイト ( にてご確認ください 資料作成には 分注意しておりますが 資料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます 価格は税抜表記となっています 本居住者のお客様がサービスを使 する場合 別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided. 3

4 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 4

5 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 5

6 New features(2015 年 10 ~2016 年 8 ) 起動ボリュームの暗号化をサポート HDD ベースでビッグデータのユースケースに最適化されたボリュームタイプを発表 スループット最適化 HDD (st1) コールド HDD (sc1) ブログポスト st1 6

7 新ボリュームタイプ (st1/sc1) の特徴 HDDベースの新たなEBSボリュームタイプ ü スループット最適化 HDD(st1) とコールドHDD(sc1) シーケンシャルアクセスに最適化 ü 1MB 単位で読み書きを実 IOPSはSSD 型と 較して低い ü DWHやETL, ログ分析等ビッグデータのワークロードでの利 に最適 IOPSではなくスループットで性能上限を規定 バースト可能 EBS 最安のボリュームタイプ ü 確保した容量に対してのみ課 するシンプルな体系 ü st1:gbあたり $0.054/ sc1:gbあたり $0.03/ 7 ボリュームタイプ名の英語表記は Throughput Optimized HDD(st1) と Cold HDD(sc1) です コストはリリース時点での東京リージョンにおける価格です

8 New features(2016 年 8 ~11 ) プロビジョンド IOPS の GB/IOPS の上限が 1:30 から 1:50 に変更 Snapshot ストレージの値下げ 汎 SSD ボリュームのバーストクレジットの残 が CloudWatch で確認可能に 残 はパーセンテージで表現される (0%~100%) EBS 8

9 New features(2017 年 2 ) 稼働中の EBS をオンラインのまま ダウンタイムなく変更する事を可能にするエラスティックボリューム機能をリリース 現 世代のインスタンス ボリュームタイプについて以下の変更が可能に 容量の拡張 パーティションやファイルシステムの拡張は OS 側で実施する必要がある ボリュームタイプの変更 IOPS 値の変更 (PIOPS ボリュームのみ ) ブログポスト EBS PIOPS 1,000 きく! 速く! 安く! EBS PIOPS 20,000 9 変更処理は通常数秒で完了し 新構成が利 可能になる この時点で新構成での費 が発 する 最適化処理は別途バックグラウンドで実 され 容量や変更内容にもよるが最 24 時間が 般的

10 New features(2017 年 5 ) EBS Snapshot がコスト配分タグをサポートしたことにより コスト集計ができるようになった 2 ステップで利 可能に 1. EBS Snapshot にタグを付与する ü タグのキーは共通でよいが 値は集計したいグループ毎に異なるものを設定するとよい 2. 設定したタグによるコスト集計を有効化する ü 請求ダッシュボード の コスト配分タグ で設定したタグキーを有効化する EBS PIOPS 20,000 10

11 New features(2017 年 12 ) プロビジョンド IOPS(SSD) ボリュームの性能上限を改善 1 ボリュームでさらに 性能を発揮可能に IOPS : 最 32,000IOPS( 従来 20,000IOPS) スループット :500MB/s( 従来 320MB/s) PIOPS 20,000 PIOPS 32,000 11

12 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 12

13 Amazon Elastic Block Store(EBS) EC2 インスタンスにアタッチして使 するブロックレベルのストレージサービス OS やアプリケーション データの置き場所など様々な 途で利 される Snapshot 機能による S3 へのバックアップや ディスクの暗号化機能を提供 % の可 性を備えるように設計されている EC2 EBS 13 製品紹介ページ :

14 特徴 容量は 1GB 単位で指定できる 最 容量は 16TB(Magnetic は 1TB まで ) アベイラビリティゾーン (AZ) 毎に独 しているため 同 AZ のインスタンスからのみ利 可能 Snapshot から任意の AZ に復元できる EC2 インスタンスに複数の EBS を接続することはできるが EBS を複数のインスタンスで共有することはできない 14

15 基本的なアーキテクチャ ボリュームのデータは AZ 内で複数の HW にレプリケートされており 般的にはさらなる冗 化は不要 実体はネットワーク接続型ストレージだが ユーザはネットワークを意識する必要はない セキュリティグループによる通信制御の対象外 全ポートを閉じても EBS は利 できる 15

16 EBS のボリュームタイプ ユースケースに応じて性能やコストが異なる 5 種類のボリュームタイプから選択できる 汎 SSD(General Purpose(SSD)) プロビジョンド IOPS(SSD) スループット最適化 HDD コールド HDD マグネティック (Magnetic) ボリュームタイプの変更や容量の拡張はオンラインで実 できる 容量拡張時 パーティションやファイルシステムの拡張は別途作業が必要 16

17 EBS のボリュームタイプの整理 (SSD タイプ ) ボリュームタイプ 汎 SSD(gp2) - General Purpose SSD プロビジョンド IOPS(io1) - Provisioned IOPS(SSD) ユースケース システムブートボリューム 仮想デスクトップ 中規模のデータベース 開発環境や検証環境 汎 SSD では処理しきれない い IO 性能を要求するアプリケーション 10,000IOPS や 160MB/s を超える性能を要するワークロード 規模なデータベース ボリュームサイズ 1GB から 16TB まで 4GB から 16TB まで IOPS 1GB あたり 3IOPS のベースラインパフォーマンス ベースラインパフォーマンスが 3,000IOPS 以下の場合 3,000IOPS までバーストが可能 最低 100IOPS 最 10,000IOPS スループット 最低 128MB/ 秒 (170GB 以下 ) から最 160MB/ 秒 (214GB 以上 ) まで 必要なIOPS 値を指定可能 容量 (GB) あたり50IOPSを指定できる 最 32,000IOPS 最 500MB/ 秒 (2000IOPS 以上のとき ) 1IOPSあたり256KB/sを利 可能 17

18 EBS のボリュームタイプの整理 (HDD タイプ ) ボリュームタイプ スループット最適化 HDD(st1) - Throughput Optimized HDD コールド HDD(sc1) - ColdHDD ユースケース EMR ログデータ保管 データウェアハウス バックアップ 規模なETL 処理 アーカイブ 規模なログ分析 起動ボリュームには利 できない 起動ボリュームには利 できないボリュームサイズ 500GBから16TBまで 500GBから16TBまで IOPS 最 500IOPS 最 250IOPS スループット ベース値 :1TBあたり40MB/s バースト値 :1TBあたり250MB/s バーストクレジット上限 :1TB/1TB 最 500MB/s ベース値 :1TBあたり12MB/s バースト値 :1TBあたり80MB/s バーストクレジット上限 :1TB/1TB 最 250MB/s 18

19 EBS のボリュームタイプの整理 ( 旧世代 ) ボリュームタイプ マグネティック (Magnetic) ユースケース アクセス頻度の低いデータ コストを最重要視する場合 ボリュームサイズ 1GB から 1TB まで IOPS 平均 100IOPS 数百 IOPS までバースト可能 スループット 40MB/ 秒から 90MB/ 秒 19

20 インスタンスストアと EBS インスタンスタイプに応じて 追加コスト無しで揮発性のインスタンスストアが利 できる 実体は EC2 の物理ホストのローカルディスク Stop/Start により仮想マシンが別ホストに移動するとデータが消去される アプリケーションが利 する 時的なデータの置き場所や 分散ファイルシステムのストレージとして活 する EBS は永続化ストレージなので OS の領域や DB のデータなど永続化が必要なデータの置き場所としては EBS を利 する 20

21 EBS とインスタンスストアの利 ケース EC2 Windows C: D: E: システムデータ EBS データファイル EBS 時データ Instance Store OS ブートディスク としての利 データ格納ディスク としての利 データ計算 など 時的な利 21

22 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 22

23 EBS のボリュームタイプの整理 (SSD タイプ ) ボリュームタイプ 汎 SSD(gp2) - General Purpose SSD プロビジョンド IOPS(io1) - Provisioned IOPS(SSD) ユースケース システムブートボリューム 仮想デスクトップ 中規模のデータベース 開発環境や検証環境 汎 SSD では処理しきれない い IO 性能を要求するアプリケーション 10,000IOPS や 160MB/s を超える性能を要するワークロード 規模なデータベース ボリュームサイズ 1GB から 16TB まで 4GB から 16TB まで IOPS 1GB あたり 3IOPS のベースラインパフォーマンス ベースラインパフォーマンスが 3,000IOPS 以下の場合 3,000IOPS までバーストが可能 最低 100IOPS 最 10,000IOPS スループット 最低 128MB/ 秒 (170GB 以下 ) から最 160MB/ 秒 (214GB 以上 ) まで 必要なIOPS 値を指定可能 容量 (GB) あたり50IOPSを指定できる 最 32,000IOPS 最 500MB/ 秒 (2000IOPS 以上のとき ) 1IOPSあたり256KB/sを利 可能 23

24 汎 SSD gp2 デフォルトのボリュームタイプで費 対効果が い 時的に I/O 性能を 3,000IOPS まで引き上げるバースト機能を備える 仕様 容量 : 1GB から 16TB まで 1GB 単位で指定可能 IOPS: ベースパフォーマンスは最 100IOPS 最 10,000IOPS 容量に応じて 3IOPS/GB の 率で変化する 容量が 1,000GB 未満の場合は 定時間 3,000IOPS まで性能を引き上げるバーストを利 できる スループット : 128MB/ 秒 (170GB 以下 ) から 160MB/ 秒 (214GB 以上 ) 24

25 汎 SSD 容量と IOPS ベースパフォーマンス バーストパフォーマンス IOPS 1,000GB 以下の容量では 3,000IOPS へのバーストを利 可能 3,334GB で 10,000IOPS に到達し 以後 16TB まで同じ性能を維持する 33.4GB 未満では 100IOPS がベースパフォーマンス 容量 (GB) 25

26 汎 SSD 容量とスループット スループット 214GB に到達すると 160MB/ 秒となり以後固定 スループット (MB/ 秒 ) 170GB 以下の容量では常時 128MB/ 秒 170GB-214GB では容量増に合わせて帯域がのびる 容量 (GB) 26

27 汎 SSD バースト時のパフォーマンス IOPS 汎用 SSD ボリュームのパフォーマンス仕様 (I/O 負荷継続時 ボリュームサイズ毎 ) ベースパフォーマンスを超える I/O が要求されると 定時間バーストが発 し 3,000IOPS を発揮する バースト利 中は I/O Credit を消費し 残 がなくなるとベースパフォーマンスに戻る 分 実際に発 した I/O がベースパフォーマンスを下回ると その差額が I/O Credit として貯 される 27

28 汎 SSD のバーストバケットモデル 流 量 : 3IOPS/GB 540 万 I/O クレジットまで蓄積できるバーストバケットがボリュームごとに存在する ボリューム作成直後は満タン状態でスタート バケットへの流 量 ( ベースパフォーマンス ) は 1GB あたり 3IOPS となる 流出量すなわち実 IOPS がこれを下回ると バケットの残 が増えていく 蓄積上限 : 5,400,000 I/O クレジット ( 固定 ) バケットにクレジットが残っていれば 流 量を超えて実 IOPS を 3,000IOPS まで引き上げるバーストが利 できる バケットのクレジットが枯渇すると 新たに流 するクレジット分 (= ベースパフォーマンス分 ) のパフォーマンスのみが利 できることになる 流出量 : Max 10,000IOPS (1000GB 以下では 3,000IOPS) 容量が 1,000GB を超えると流 量と流出量の値が 致するので バーストの概念がなくなり常時 定の性能となる 28

29 IOPS 汎 SSD バーストの継続時間 初期状態で I/O Credit 残高は 5,400,000 再び高負荷が発生すると I/O Credit の残高に応じてバースト I/O Credit 残高 I/O Credit が残っている間はバースト 3000IOPS 出る 残高が 0 になると I/O 性能もベースパフォーマンスに戻る ベースパフォーマンス (gp2 500GB 時 ) バースト中は I/O Credit の残高を取り崩す形となる 残高が 0 になるとバーストは終了 I/O 負荷がベースパフォーマンスを下回ると Credit が貯金される 分 29

30 バーストクレジットの残 を確認する CloudWatch を利 してバーストバケットの残 を確認することが可能に ボリューム毎のメトリクスの BurstBalance で利 できる 残 はクレジットの実数ではなく 上限値の (540 万 I/O クレジット ) に対するパーセンテージで表現される 多くの場合はバーストクレジットの枯渇は発 しないが 負荷処理時に枯渇が られる場合は対策を検討するとよい ボリュームサイズを きくする プロビジョンド IOPS に変更する 30

31 プロビジョンド IOPS(SSD) io1 最もパフォーマンスの いタイプ 1 年間のうち 99.9% の時間について 指定した IOPS 値の ±10% の範囲の性能を発揮する 仕様 容量 : 4GB から 16TB まで 1GB 単位で指定可能 IOPS: 1GB あたり 50IOPS を上限として希望する IOPS 値を指定する最 32,000IOPS まで (32,000IOPS 指定時は最低 640GB が必要 ) スループット : 最 500MB/ 秒 (2000IOPS 以上時 I/O size=256kb) CloudWatch の詳細モニタリング機能がデフォルトで ON 31

32 PIOPS と汎 SSD の IOPS カウント 256KB ブロックアクセスまで 1IOPS とカウントする 256KB を超える場合は複数回の 256KB ブロックアクセスを ったものとしてカウントされる 例 1:8KB アクセスの 1 回は I/O 命令を 1 回発 したものとみなす 例 2:512KB アクセスを 1 回 うと I/O 命令を 2 回発 したとみなす 例 3:4MB アクセスを 1 回 うと I/O 命令を 16 回発 したとみなす ラージブロックアクセスを うと低 IOPS 値でもスループットを稼げるが EBS や EC2 側のスループット上限に注意 32

33 EBS のボリュームタイプの整理 (HDD タイプ ) ボリュームタイプ スループット最適化 HDD(st1) - Throughput Optimized HDD コールド HDD(sc1) - ColdHDD ユースケース EMR ログデータ保管 データウェアハウス バックアップ 規模なETL 処理 アーカイブ 規模なログ分析 起動ボリュームには利 できない 起動ボリュームには利 できないボリュームサイズ 500GBから16TBまで 500GBから16TBまで IOPS 最 500IOPS 最 250IOPS スループット ベース値 :1TBあたり40MB/s バースト値 :1TBあたり250MB/s バーストクレジット上限 :1TB/1TB 最 500MB/s ベース値 :1TBあたり12MB/s バースト値 :1TBあたり80MB/s バーストクレジット上限 :1TB/1TB 最 250MB/s 33

34 スループット最適化 HDD st1 シーケンシャルアクセス時に い性能を発揮するタイプ いスループットを要求するビッグデータ処理に最適 仕様 容量 : 500GB から 16TB まで 1GB 単位で指定可能 IOPS: 最 500IOPS スループット : 容量 1TB あたり 40MB/s がベースパフォーマンス 1TB あたり 250MB/s まで性能を引き上げるバーストが利 可能スループットの上限値は 500MB/s となる 34 snapshot の取得中はバーストが発 せず ベースパフォーマンスとなる

35 コールド HDD sc1 スループット最適化 HDD と同様のユースケースで 性能が不要な場合に ログやバックアップのアーカイブ先としても 仕様 容量 : 500GB から 16TB まで 1GB 単位で指定可能 IOPS: 最 250IOPS スループット : 容量 1TB あたり 12MB/s がベースパフォーマンス 1TB あたり 80MB/s まで性能を引き上げるバーストが利 可能スループットの上限値は 250MB/s となる 35 snapshot の取得中はバーストが発 せず ベースパフォーマンスとなる

36 st1/sc1 のバーストバケットモデル 流 量 : (st1)40mb/ 秒 /TB (sc1)12mb/ 秒 /TB ボリューム容量 1TB あたりにつき 1TB まで蓄積できるバーストバケットが存在する 流 量 ( ベースパフォーマンス ) はボリュームタイプによって異なる ü ü st1: 1TB あたり 40MB/ 秒 最 500MB/ 秒 sc1: 1TB あたり 12MB/ 秒 最 192MB/ 秒 蓄積上限 : (st1/sc1)1tb/tb 流出量 : (st1)250mb/ 秒 /TB,Max500MB/ 秒 (sc1)80mb/ 秒 /TB,Max250MB/ 秒 流出量 ( バースト時性能 ) もボリュームタイプに依存 st1:1tb あたり 250MB/ 秒 最 500MB/ 秒 sc1:1tb あたり 80MB/ 秒 最 250MB/ 秒 st1 で 12,800GB(12.5TB) 以上確保すると常時 500MB/ 秒となりバーストの概念がなくなる Snapshot 作成中はバーストが発 せずベースパフォーマンスとなる 36

37 st1/sc1 の容量とスループットの関係 スループット (MB/s) 容量 (TB) 37

38 パラメータチューニング (1) スループットで読み込みが主体となるワークロードにおいては 性能を最 限引き出すために先読み (Read Ahead) のサイズを 1MB に設定することを推奨 1. 現状の設定を確認する $ sudo blockdev --report /dev/(device) 2. Read ahead の値を変更する $ sudo blockdev --setra 2048 /dev/(device) 3. 設定変更結果を確認する $ sudo blockdev --report /dev/(device) 38

39 パラメータチューニング (2) Linux Kernel のバージョン 4.2 以上を利 している場合は 先の設定に加えて xen_blkfront.max の値を 256 に設定することを推奨 この値はカーネルモジュールパラメータとして指定を う Amazon Linux の場合は下記の 順で設定変更が可能 1. /boot/grub/menu.lst を vi で開く $ sudo vi /boot/grub/menu.lst 2. kernel を以下の通り追記して OS を再起動変更前 ) kernel /boot/vmlinuz amzn1.x86_64 root=label=/ console=ttys0 変更後 ) kernel /boot/vmlinuz amzn1.x86_64 root=label=/ console=ttys0 xen_blkfront.max=256 39

40 設計上のパフォーマンス特性 st1/sc1 は HDD の特性を活かし いスループットを低コストに実現することに最適化されている ü 般に HDD はシーケンシャルアクセスは 速だが さいデータへのランダムアクセスではヘッドの移動がオーバーヘッドとなるためパフォーマンスが出ない st1/sc1 で さいデータブロックへのアクセスを った場合 シーケンシャルなら可能な限り I/O 命令がマージされ効率的だが ランダムな場合は 効率 ü ( 例 ) 連続した 10 個の 128KB ブロックへのアクセスではクレジットの消費は 2MB となる ü ( 例 )16KB ブロックにランダムで 10 回アクセスすると クレジットは 10MB 消費される さいデータへのランダムアクセスになりがちなトランザクショナルな処理やデータベース ファイルサーバ等への利 は 推奨 40

41 st1/sc1 の使いどころ Doʼs Doʼs 新ボリュームタイプ (st1/sc1) は安定したスループットを低コストで得られるよう設計されているので ETL DWH ログ処理 EMR などのシーケンシャルアクセス 途で利 する Throughput Optimized(st1) はディスクを 速 (250MB/s 以上 ) にスキャンする 途や 次のバッチ処理などでボリュームをフルスキャンする 途に適している Cold(sc1) はアクセス頻度が低いデータで 250MB/s 以下のスキャン速度でよいものを低コストに保管することができるので st1 までのパフォーマンスは不要な場合に選択する 41

42 st1/sc1 の使いどころ Donʼts Donʼts トランザクション処理やランダム I/O を多数発 する処理 起動ボリュームには向いていない ü 汎 SSD(gp2) やプロビジョンド IOPS(io1) の利 を推奨 起動ボリュームなど 容量で低コストを追求する場合はマグネティックの利 を考えてもよい st1/sc1 は起動ボリュームには 対応 常に いスループットを得るために D2 インスタンスを利 している場合は 現状のままとすることが良いケースが多い 42

43 EBS のボリュームタイプの整理 ( 旧世代 ) ボリュームタイプ マグネティック (Magnetic) ユースケース アクセス頻度の低いデータ コストを最重要視する場合 ボリュームサイズ 1GB から 1TB まで IOPS 平均 100IOPS 数百 IOPS までバースト可能 スループット 40MB/ 秒から 90MB/ 秒 43

44 マグネティック - Magnetic 最も古くから存在する磁気ディスクタイプ 汎 SSD の登場以前は Standard という名称でデフォルトのボリュームタイプだった 必要に応じて引き続き利 可能 仕様 容量 : 1GB から 1TB まで 1GB 単位で指定可能 IOPS: 平均 100IOPS となる設計で最 数百 IOPS へバーストできる場合がある スループット : 40MB/ 秒 ~90MB/ 秒 唯 I/O リクエスト回数による課 がある 44

45 EBS 最適化インスタンス (EBS-Optimized) EBS 最適化なし EC2 w/o EBS Optimized EBS 最適化あり EC2 with EBS Optimized EBS Network EBS Network EBS 最適化を有効にすることで独 した帯域を確保し I/O 性能の安定化に繋がる きいインスタンスタイプほど使える帯域が広い (*) 特別な意図が無ければ基本的に有効に設定することが望ましい 最近のインスタンスタイプ (m4,c4,d2) ではデフォルトでオンになっている 45 (*) インスタンス毎の帯域幅はこちらを参照ください

46 事前ウォーミング (Pre-Warming) 46 Snapshot から復元したボリュームに限り 各データブロックへの初回アクセス時 S3 からのデータ取得が発 するため I/O 命令のレイテンシが増加することがある 全領域からの読み込み処理の実 による事前ウォーミング (Pre- Warming) を うことで Snapshot から復元したボリュームに対する初回アクセス時のペナルティを回避できる 実運 時は事前ウォーミングが不可能なケースもあるため 運 要件から判断して実 可能であれば取り込む程度で OK 例 )Auto Scaling で起動したインスタンス 詳細情報 :

47 EBS のパフォーマンスを律速する要素 EBS のパフォーマンスは 3 つの要素で律速されるので システム全体としてのボトルネックを把握することが重要 1. EC2 インスタンス側のスループット 2. EBS が処理できる I/O 命令の回数 (IOPS) 3. 各 EBS ボリュームのスループット 2EBS 体が処理できる I/O 命令の量 1EC2 インスタンス側のスループット上限 Data EBS 3EBS ボリューム単体としてのスループット上限 EC2 EBS Data 47

48 1. EC2 インスタンス側のスループットを改善する まず EBS 最適化 (EBS-Optimized) を有効にする インスタンスタイプによって決まる EBS スループットの上限値に到達していないかを確認する CloudWatch の Volume Read/Write Bytes の合計値 OS で EBS ボリュームへの総流量を確認 (iostat や perfmon など ) 上限に到達している場合はインスタンスタイプを きくすることでスループットを改善する 増速! 48 EC2 EBS EC2 EBS Data Data

49 2. EBS 側の I/O 処理性能を改善する EBS 側の実績 IOPS を確認する CloudWatchのVolume Read/Write Opsを参照 OSでEBSへのI/O 命令回数を確認 (iostatやperfmonなど) 上限に到達していればボリュームの変更を検討 タイプを変更 ( マグネティック 汎 SSD, 汎 SSD PIOPS) スペックを変更 ( 汎 SSD: 容量を増加, PIOPS:IOPS 値を増加 ) 増速! EC2 Data EBS Magnetic EC2 Data EBS PIOPS 49

50 3. EBS 側のスループットを改善する 個々の EBS ボリュームのスループットを確認する CloudWatch の Volume Read/Write Bytes を参照 OS で EBS ボリュームへの総流量を確認 (iostat や perfmon など ) 上限に到達していればボリュームの変更を検討 タイプを変更 ( 汎 SSD PIOPS, PIOPS スループット最適化 ) 汎 SSD や PIOPS からスループット最適化 HDD, コールド HDD に変更する場合はアクセスパターンに注意 増速! EC2 Data EBS 汎 SSD EC2 Data EBS PIOPS 50

51 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 51

52 Snapshot EBS のバックアップ機能 リストア時は新しいボリュームを作成する形となる EBS Snapshot のデータはバックエンドで S3 に保管されるため S3 のインタフェースから直接参照できない 2 世代 以降は増分データを保存する増分バックアップとなる (1 世代 を削除しても復元は可能 ) Snapshot Snapshot 作成時にブロックレベルで圧縮して保管するため 圧縮後の容量に対して課 が われる EBS 52

53 Snapshot によるバックアップ EC2 EBS Snapshot 作成 定期的に EBS の Snapshot を作成することによりバックアップを取得する Snapshot 作成時はデータ整合性を保つため静 点を設ける事を推奨 ソフトウェアの機能 ( 例 :RDBMS のバックアップモード ) ファイルシステムの機能 ( 例 :Linux の xfs_freeze) バックアップソフトウェアの機能 ( アプリケーションの停 ) ( ファイルシステムのアンマウント ) 保存期間や世代数は無制限 世代管理が必要な場合は AWS CLI や API 等で 動化する 53

54 Snapshot からのリストア EC2 Snapshot から新規 EBS を作成し EC2 インスタンスにアタッチされていたものと置き換える Detach EBS Attach EBS 古い EBS は不要であれば削除する 障害分析等の 的で他のインスタンスにアタッチしても OK Snapshot から EBS を作成 EBS を別 AZ に移動したい場合や 容量変更 ボリュームタイプ変更も Snapshot 経由で う 54

55 バックアップと静 点 Snapshot の作成を指 しレスポンスが返ってきたら その時点のデータのバックアップが開始されている レスポンスが返ってきた時点で I/O を再開して良いので 静 点を維持するのは短時間で済む EBS への I/O 停 EBS への I/O 再開 通常運 静 点を維持 通常運 時間 この時点のデータがバックアップされる Snapshot 作成指 作成指 レスポンス Snapshot 作成処理 ( バックグラウンド ) Snapshot 作成完了 55

56 Snapshot の増分バックアップ 1 世代 の Snapshot は EBS に書き込まれた実データをすべてバックアップするが 2 世代 以降は増分バックアップとなる 1 世代 みかん メロ EBS snapshot みかんメロ 56

57 Snapshot の増分バックアップ 1 世代 の Snapshot は EBS に書き込まれた実データをすべてバックアップするが 2 世代 以降は増分バックアップとなる 1 世代 2 世代 EBS みりん メロン snapshot みかんメロ り ン 57

58 Snapshot の増分バックアップ 1 世代 の Snapshot は EBS に書き込まれた実データをすべてバックアップするが 2 世代 以降は増分バックアップとなる 1 世代 EBS 2 世代 EBS みりん メロン snapshot 変化のないデータは以前のものを参照する みかんメロ り ン 58

59 Snapshot の削除 Snapshot の削除を うと 当該 Snapshot でしか利 していないデータのみが削除される仕組みとなっている 1 世代 EBS 2 世代 みかんメロ り ン 2 世代 から参照されていないデータのみを削除 59

60 Snapshot の削除 Snapshot の削除を うと 当該 Snapshot でしか利 していないデータのみが削除される仕組みとなっている 2 世代 みんメロりン 60

61 Snapshot の削除 2 世代 で必要なデータはすべて保持されているので 1 世代 を削除しても 2 世代 から直接リストアをすることが可能 2 世代 EBS みりん メロン みんメロ り ン ボリューム作成 61

62 リージョン間コピー リージョン間での Snapshot コピーをサポート コピーを指 しておけば 同期で処理が われるため バックアップデータを他リージョンに転送しておけば DR を実現できる EC2 EBS Snapshot EBS リージョン間コピー Internet EBS Snapshot EC2 EBS 転送済み Snapshot から EBS を作成し EC2 にアタッチ リージョン A リージョン B 62

63 データボリュームの暗号化 EBS ボリュームの作成時に暗号化を指定すると AES-256 による暗号化処理が われる ボリュームの利 法は従来通り 暗号化が有効であったとしても 特に意識する必要はない Snapshot も暗号化される 暗号化 / 復号化の処理はハードウェア機能を使って実施するため パフォーマンスへの影響は極めて さい 暗号化キーは AWS Key Management Service で管理 63 AWS Key Management Service:

64 暗号化の有効 無効化 ボリューム作成後に暗号化を施したい場合は Snapshot 経由で暗号化を有効にできる 1. Snapshot を取得する 2. 暗号化を有効にして Snapshot をコピー 3. コピーされた Snapshot からボリュームを作成 4. 新ボリュームをインスタンスにアタッチ 暗号化の解除を う場合は新規ボリュームを作成して OS 側でデータコピーを う Linux: rsync コマンドなど Windows: robocopy コマンドなど EBS copy EC2 EBS EBS EBS 64

65 暗号化を利 できるインスタンスタイプ 2017 年 2 15 時点では 以下のインスタンスタイプでのみボリュームの暗号化を利 できる 汎 : 全ての m3 全ての m4 全ての t2 コンピューティング最適化 : 全ての c3 全ての c4 メモリ最適化 : 全ての x1 全ての r4 全ての r3 cr1.8xlarge ストレージ最適化 : 全ての i2 全ての d2 速コンピューティング : 全ての g2 全ての p2 最新情報はこちらを参照 65

66 起動ボリュームの暗号化 起動ボリュームの暗号化もサポート ただし暗号化を有効にする 順が異なり AMI のコピー機能を利 する 1. 稼働中のインスタンスから AMI を作成する パブリックで追加料 が不要な AMI も利 可能 2. コンソールやや CLI 等で AMI コピーを実 その際に Snapshot の暗号化を有効に設定する 3. コピーされた AMI からインスタンスを起動する 66

67 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 67

68 EBS のコスト コストの要素 汎 SSD(gp2) プロビジョンド IOPS(io1) スループット最適化 HDD(st1) コールド HDD(sc1) マグネティック 容量 $0.12/GB/ $0.142/GB/ $0.054/GB/ $0.03/GB/ $0.08/GB/ 指定 IOPS 値 ( 対象外 ) $0.074/IOPS/ ( 対象外 ) ( 対象外 ) ( 対象外 ) I/Oリクエスト数 ( 対象外 ) ( 対象外 ) ( 対象外 ) ( 対象外 ) $0.08/100 万 IO リクエスト Snapshot の容量 $0.05/GB/ $0.05/GB/ $0.05/GB/ $0.05/GB/ $0.05/GB/ Snapshot を取得すると対象ボリュームの実データのみを圧縮して保存する 課 対象は 実データの圧縮後の容量 となるため ボリュームの確保容量に対して費 がかかるわけではない点に注意 年 6 2 現在の東京リージョンにおける価格です

69 ボリュームのコスト例 (1 ドル =110 円換算 ) 1TB の汎 SSD を 1 ヶ 間利 した場合 容量分 : = 約 ドル ( 約 13,500 円 ) 1TB の PIOPS を 5000IOPS で 1 ヶ 間利 した場合 容量分 : = 約 145.4ドル ( 約 16,000 円 ) IOPS 分 : =370ドル( 約 40,700 円 ) 合計 : 約 516ドル ( 約 56,900 円 ) 1TB のマグネティックを 8KB 単位で に 1TB アクセスした場合 容量分 : = 約 81.9ドル ( 約 9,000 円 ) IOリクエスト分 :0.08 約 134 ( )= 約 10.7ドル ( 約 1,200 円 ) 合計 : 約 92.6ドル ( 約 10,200 円 ) 69 読み書きブロック数 =1TB/8KB= ( 約 1 億 3 千 4 百万リクエスト )

70 ボリュームのコスト例 (1 ドル =110 円換算 ) 4TB のスループット最適化 HDD を 1 ヶ 間利 した場合 容量分 : = 約 ドル ( 約 24,300 円 ) 8TB のコールド HDD を 1 ヶ 間利 した場合 容量分 : = 約 ドル ( 約 27,000 円 ) 50% 使 済みの汎 SSD1TB のボリュームから Snapshot を作成し 1 ヶ 間にわたり保持した場合 ( 圧縮率は 25% と仮定 ) Snapshot 実容量 : =125GB 容量分 : =6.25 ドル ( 約 690 円 ) 70

71 アジェンダ Whatʼs new? Amazon Elastic Block Store(EBS) 概要 ボリュームタイプとパフォーマンス Snapshotと暗号化 料 まとめ 71

72 まとめ EBS はバックアップや暗号化の機能を備えたセキュアに利 できる永続化ストレージ 多彩なボリュームタイプからパフォーマンスやコストに応じて最適なものを選択して利 可能 後から変更することもできる HDD のボリュームタイプはシーケンシャルアクセスに最適 アクセスパターンが読めない場合は汎 SSD を利 する いパフォーマンスが必要な場合は EBS ボリュームだけでなく EC2 側のスループットにも注意 72

73 参考資料 Amazon Elastic Block Store(EBS) ドキュメント :EBS の概要 ドキュメント :EBS 最適化インスタンス config.html ドキュメント :EBS API およびコマンド概要 ドキュメント :EC2 インスタンスストア html 73

74 Webinar 資料の配置場所 AWS クラウドサービス活 資料集 74

75 公式 Twitter/Facebook AWS 検索 もしくは 最新技術情報 イベント情報 お役 ち情報 お得なキャンペーン情報などを 々更新しています! 75