![見出し画像](https://assets.st-note.com/production/uploads/images/35764629/rectangle_large_type_2_a1f659e450f7a8b66baf2e9a74915497.jpg?width=1200)
【AWS Summit Online】「Amazon EBS 完全に理解した」あなたに贈る Amazon EBS 再入門 :学習メモ
AWS-20:「「Amazon EBS 完全に理解した」あなたに贈る Amazon EBS 再入門」 のセッションを視聴した学習メモです。
(上記リンクの動画は2020/9/30(水)まで視聴可能でした)
チュートリアルをやっていないので、「完全に理解した」レベルにすら達していませんが視聴してみました。
【エンジニア用語解説】
— 伊藤 祐策(パソコンの大先生) (@ito_yusaku) September 20, 2018
「完全に理解した」
製品を利用をするためのチュートリアルを完了できたという意味。
「なにもわからない」
製品が本質的に抱える問題に直面するほど熟知が進んだという意味。
「チョットデキル」
同じ製品を自分でも1から作れるという意味。または開発者本人。
セッションの対象者
• Amazon Elastic Block Store (Amazon EBS) を「完全に理解した」
= チュートリアルは終えたレベルの人
セッションの目的
・ Amazon EBS の全体像の理解を深める
・最近のアップデートを踏まえた現在のベストプラクティスを把握する
・「なにもわからない」と⾔えるようになるための⼀歩を踏み出す
・「チョットデキル」⼈たちに臆せず質問できるようになる
Amazon EBS の概要
・Amazon EC2 にくっつけて使う、永続的なブロックストレージサービス
・API 経由でボリュームを作成・アタッチ・管理できる
・サーバーのローカルストレージではなくネットワーク接続型のストレージ
・1つの EC2 インスタンスに複数のボリュームをアタッチできる
・ブートとデータのボリュームを別々に⽤意することを推奨
Amazon EBS を正しく利⽤するための重要な考慮事項
EBS を適切に選択しても、I/O要求を出すEC2 側が合っていないとストレージを活かせなかったりコストが無駄になったりする。
そのため、EC2 インスタンスの選択も重要になってくる。
-----------------------------------------------
EBS と EC2 の設計指針
・左:トランザクションワークロード向け
・右:スループットワークロード向け
■ タイプの違いで大事なポイント
1. ボリュームあたりの最大IOPS / 最大スループットの上限が違う
2. 料金体系が違う。
特にio1 は容量に加えてプロビジョニングしたIOPSに基づいて課金され
■ バースト
・gp2 では、突発的な負荷に対応できるようバーストパフォーマンスというメカニズムが用意されている。
・常時利用できるわけではない。
バーストバケットの考えに基づいて利用できる時間が決まっている。
バケツに水を貯めておき、必要になったとき使うようなイメージ
・前述したとおり、EC2 インスタンスの選択も重要
・「EBS 最適化 EC2 インスタンス」は現⾏世代のインスタンスはデフォルトで有効になっている
・EBSの性能を最大限に発揮するために、スループットとIOPS の両方を満たすことができる帯域幅を持ったEC2 インスタンスを選ばないといけない。
※ 一時的にIOPS が高いケースは Nitro ベースのEBS 最適化EC2 インスタンスのバーストを検討する
・最初から完璧を目指さなくてOK
必要に応じて以下を調整していけばいい
・ボリュームタイプの変更
・ボリュームサイズの増加
・プロビジョンドIOPS の調整
-----------------------------------------------
データライフサイクル管理
データのバックアップは非常に大事。
スナップショットは増分バックアップ
-----------------------------------------------
データセキュリティ
・AWS Key Management Service (KMS) と連携することでEBS を暗号化できる
・暗号化はサーバーサイド側で行われる。
以下を暗号化できる
・ボリューム内の保存データ
・ボリュームとインスタンスの間で移動されるデータ
・ボリュームから作成されたスナップショット
・それらスナップショットから作成されたボリューム
■ 暗号化のベストプラクティス
AWS KMS で Amazon EBS ⽤に新しい CMK を作成する
・キーローテーションのポリシーを定義
・AWS CloudTrail の証跡を設定
・適切なキーの管理アクセス許可
・適切なキーの使⽤アクセス許可
-----------------------------------------------
監視とコスト最適化
■ 最適な構成を決めるためにベンチマークしたほうがいい
・Amazon EBS の CloudWatch メトリクスで監視
・EC2 インスタンスにエージェントをインストールしてディスクの使⽤率を監視することができる
■ EBS の料金ポイント2つ
1. EBS ボリュームの料⾦
・ストレージを使⽤しているか否かにかかわらず、プロビジョニングされたストレージの合計量に基づいて計算される
2. EBS スナップショットの料⾦
・スナップショットは変更されたブロックだけを保存するため、変更されたブロック分を計算
例:100 GB のデータを保存するボリュームがあるけど、最後のスナップショット以降に5 GB しか変更していない場合
→ 新しいスナップショットには 5 ギガバイト/⽉の料⾦を請求
サービスアップデートのメモ
■ Amazon EBS マルチアタッチ ← New!!
・単⼀のプロビジョンド IOPS ボリュームを同じアベイラビリティーゾーン (AZ) 内にある最⼤ 16 の Nitro インスタンス(※)にアタッチできる
・アプリケーション側で同時書き込み操作を制御する必要があるので要注意
※ 「Nitro インスタンスって何??」って思ったので調べた。
Nitro System 上に構築されたインスタンス。以下が該当するっぽい
引用:「インスタンスタイプ - Amazon Elastic Compute Cloud」
■ 高速スナップショット復元 (FSR) ← New!!
2019年11月に追加された
■ EBS direct APIs ← New!!
⾼速かつ低コストに EBS ボリュームをバックアップできる。
2019年12月に追加された
セッションを視聴した感想
・EBS ボリュームタイプの選択基準は他のセッションでも見たので、よい復習になった。必要になったときにまた確認しようと思った。
・バーストバケットの考え方を理解できてよかった。
・最適なEC2 インスタンス + EBSボリュームを組み合わせる点が難しく感じた。帯域幅を生かせるよう計算するのがつらそう (エンジニアとしてあるまじき発言だけど... )
参考
・「「Amazon EBS 完全に理解した」あなたに贈る Amazon EBS 再入門」
本記事内のスライドはすべて上記から引用させていただきました。