AWSでサーバーを構築してみる~ストレージの追加編~
はじめに
くーばねてすをやっつけるためにこれまでにLinuxさんと密に仲良くさせていただいたが、新たなステージに上がるためについにAWSさんに会いに行くことにした。AWSさんと仲良くなることでLinuxさんのファイルシステムだけでなく、インターネットの仕組みの理解につながると思い勉強する。今回はその第1歩としてAWSを使ってWordPressでブログシステムを構築しようと思う。
概要
インスタンスの詳細設定、 ストレージの追加
での
■ボリュームタイプ
■デバイス
■スナップショット
■サイズ (GiB)
■ボリュームタイプ
■IOPS
■スループット (MB/秒)
■終了時に削除
■暗号化
をまとめた！
■ストレージの追加設定へ
インスタンスの設定が終わったらストレージの追加設定に入る。
左から順にまとめてみた！
■ボリュームタイプとは
Amazon EBS は EC2 インスタンスの存続期間に左右されない永続的なブロックストレージボリュームのため、インスタンスを後で停止、再起動することができます。一時的なインスタンスストアボリュームは物理的にホストコンピューターにアタッチされています。インスタンスストア上のデータはインスタンスの運用中のみ維持されます。
インスタンスを起動するときは、ルートデバイスボリュームに格納されているイメージを使用してインスタンスがブートされます。
なのでデフォルトでルートにボリュームがついているらしい。
合計30 GBまでのストレージが無料使用枠に含まれるそうだ('_')
■デバイスとは
ボリュームで使用可能なデバイス名。選択した AMI のカーネルのブロックデバイスドライバによっては、デバイスが指定した名前とは異なる名前でアタッチされる可能性があります。Amazon Linux AMI は、名前が変更されたデバイスパスから指定した名前へのシンボリックリンクを作成しますが、その他の AMI では異なる動作をする場合があります。
使用できるデバイス名について
Linux インスタンスでは、準仮想化 (PV) とハードウェア仮想マシン (HVM) の 2 種類の仮想化を使用できます。インスタンスの仮想化タイプは、インスタンスの起動に使用される AMI によって決まります。すべてのインスタンスタイプが HVM AMI をサポートしています。一部の前世代のインスタンスタイプは PV AMI をサポートしています。使用できる推奨のデバイス名はインスタンスの仮想化タイプによって異なるため、必ず AMI の仮想化タイプを確認してください。
だそうだ。なのでインスタンスで使用できるパス名がかぎられているので確認する。
| 仮想化タイプ | 使用可能パス | ルート用に予約済み | EBS ボリュームとして推奨 | インスタンスストアボリューム |
|---|---|---|---|---|
| 準仮想化 | /dev/sd[a-z], /dev/sd[a-z][1-15], /dev/hd[a-z], /dev/hd[a-z][1-15], | /dev/sda1 | /dev/sd[f-p], /dev/sd[f-p][1-6] | /dev/sd[b-e] |
| HVM | /dev/sd[a-z], /dev/xvd[b-c][a-z] | AMIによる違い /dev/sda1 or /dev/xvda | /dev/sd[f-p] * | /dev/sd[b-e], /dev/sd[b-h] (h1.16xlarge), /dev/sd[b-y] (d2.8xlarge), /dev/sd[b-i] (i2.8xlarge) |
準仮想化 (PV)ってなんだ？
以前のAWSではPVはネットワークI/OやディスクI/Oで特別なドライバを使用するため、HVMよりも高性能でした。しかしこれらのドライバが "PV on HVM" として HVM でも使用可能となったため、HVMでもPVと同等あるいはそれ以上の性能が可能となりました。
現行ではとくに理由がない限りより性能のいいハードウェア仮想マシン (HVM)が使用されている。ひと昔前の世代のインスタンスは準仮想化 (PV) であることがあるそうなので気をつけてねってことだそうだ。
インスタンスストアってなんだ？
インスタンスストアは、インスタンス用のブロックレベルの一時ストレージを提供します。このストレージは、ホストコンピュータに物理的にアタッチされたディスク上にあります。インスタンスストアは、頻繁に変更される情報 (バッファ、キャッシュ、スクラッチデータ、その他の一時コンテンツなど) の一時ストレージに最適です。
EC2の一時的なデータが保持され、EC2の停止・終了と共にクリアされるそうだ。
こっちの説明はシンプルでよい↓
このような違いがあるからデバイス名の選択肢が限られるからよろしくね！ってことらしい。
大丈夫、確認したらちゃんとデバイス名選択一覧があって入力しなくても選べるようになってた(^_-)-☆
■スナップショットとは
スナップショットは、S3 に保存された EC2 ボリュームのバックアップです。スナップショットの ID を入力することで、スナップショットに保存されたデータを使用して新しいボリュームを作成できます。 フィールドにテキストを入力して、パブリックスナップショットを検索することもできます。説明は、大文字と小文字が区別されます。
ポイントインタイムスナップショットを作成することで、Amazon EBSボリュームのデータを Amazon S3 にバックアップできます。スナップショットは増分バックアップです。つまり、最後にスナップショットを作成した時点から、ボリューム上で変更のあるブロックだけが保存されます。これにより、スナップショットを作成するのに要する時間が最小限に抑えられ、データを複製しないことで、ストレージコストが節約されます。各スナップショットには、(スナップショットを作成した瞬間から) データを新しい EBS ボリュームに復元するために必要な情報がすべて含まれます。
スナップショットは、ある瞬間のEBSをバックアップすることができるツールだ。
バックアップはS3の中に保存され、短時間でのバックアップ取得ができる。EBSに保存されたインスタンスの復元や、EBSに保存された内容を新しく復元するときに、元のボリュームのレプリカを作成できる。
デフォルトではすでにスナップショットのIDが入っているのでこのままでヨシ！(というかいじれない！)
■サイズ (GiB)とは
ボリュームサイズは、0 または使用されるスナップショットのサイズ以上である必要があります。 プロビジョンド IOPS SSD ボリュームのサイズは、最低 4 GiB 以上である必要があります。
ボリュームのサイズどうする？
このまま８でOK。もし小さかったら後で変更できるから。
■ボリュームタイプとは
汎用 (SSD) ボリュームは、3000 IOPS までのバーストが可能で、1 GiB あたり 3 IOPS の一貫したベースラインで機能します。プロビジョンド IOPS SSD ボリュームは、最大 64000 IOPS まで提供することができ、EBS 最適化インスタンスに最適です。以前はスタンダードボリュームと呼ばれていたマグネティックボリュームは、平均 100 IOPS を提供し、数百 IOPSまでのバーストが可能です。
ボリュームのタイプどうする？ってことらしい。
ボリュームタイプは次の3タイプに分類される。
・ソリッドステートドライブ (SSD)
・ハードディスクドライブ (HDD)
・旧世代 (マグネッティック)
MEMO
〇IOPS...【Input/Output Per Second】 I/O毎秒 アイオプス！
〇I/O...「入力や出力」
〇スループット...通信速度
〇Amazon EBS マルチアタッチ...単一のボリュームを、同じアベイラビリティーゾーンにあるインスタンスに複数アタッチできるサービスのこと。
■■■ソリッドステートドライブ (SSD)
Amazon EBS によって提供される SSD-Backed ボリュームは、次のカテゴリに分類されます。
・汎用 SSD — 価格とパフォーマンスのバランスに優れています。これらのボリュームは、ほとんどのワークロードに推奨されます。
・プロビジョンド IOPS SSD — ミッションクリティカルな低レイテンシーまたは高スループットワークロードに適した、高パフォーマンスを提供します。
| * | 汎用 SSD | プロビジョンド IOPS SSD | プロビジョンド IOPS SSD |
|---|---|---|---|
| ボリュームタイプ名 | gp2 | io2 | io1 |
| ユースケース | ブートボリューム、低レイテンシーにやり取りしたいアプリケーション、開発・テスト環境 | 持続的なIOPSパフォーマンス、またはボリュームあたり 16,000IOPSまたは250MiB/秒以上のスループットを必要とするワークロード、I/O 集約型のデータベースワークロード | 持続的なIOPSパフォーマンス、またはボリュームあたり 16,000IOPSまたは250MiB/秒以上のスループットを必要とするワークロード、I/O 集約型のデータベースワークロード |
| ボリュームサイズ | 1GiB - 16TiB | 4 GiB～16 TiB | 4 GiB～16 TiB |
| ボリュームあたりの最大IOPS(16 KiB I/O) | 16,000 | 64,000 | 64,000 |
| ボリュームあたりの最大スループット | 250 MiB/秒 | 1,000 MiB/秒 | 1,000 MiB/秒 |
| Amazon EBS マルチアタッチ | サポート外 | サポート外 | サポート対象 |
| ↓追加で最近新しくgp3ってのが入ってきたようだ。↓ | |||
| https://dev.classmethod.jp/articles/ebs-gp3/ | |||
| gp2ボリューム | |||
| gp2ボリュームのパフォーマンスにはボリュームサイズが反映される。ボリュームサイズによって、ボリュームのベースラインパフォーマンスレベルや I/O クレジットを取得する速さが決まる。 | |||
| 使いたい用途に対して、gp2ボリュームのパフォーマンスが低い状態だとI/O クレジットが枯渇して動作が不安定になることがある。 | |||
| gp3ボリューム | |||
| 従来のgp2ボリュームに比べて、低価格でベースパフォーマンスが高い。 | |||
| 無料枠で最大パフォーマンスとなる3,000IOPSと125MiB/秒を設定できる。gp2に比べて20%安くなっていて、ベースライン以上のスループットとIOPSが求められる場合のみ追加料金を支払う。 | |||
| プロビジョンド IOPS SSDボリューム | |||
| プロビジョンド IOPS SSDボリュームは、ランダムアクセスにおけるストレージパフォーマンスと特にデータベースワークロードのニーズを満たすように設計されています。gp2ボリュームとは異なり、プロビジョンド IOPS SSDボリュームでは、ボリュームの作成時に一定の IOPS レートを指定できる。 |
■■■ハードディスクドライブ (HDD)
Amazon EBS によって提供される HDD-Backed ボリュームは、次のカテゴリに分類されます。
・スループット最適化 HDD — 高いスループットを必要とするアクセス頻度の高いワークロード向けの低コストの HDD
・Cold HDD — アクセス頻度の低いワークロード向けの最も低コストの HDD 設計
| * | スループット最適化 HDD | Cold HDD |
|---|---|---|
| ボリュームタイプ | st1 | sc1 |
| ユースケース | ビッグデータ,データウェアハウス.ログ処理 | アクセス頻度の低いデータ用のスループット指向ストレージ,低いストレージコストが重視されるシナリオ |
| ボリュームサイズ | 500 GiB～16 TiB | 500 GiB～16 TiB |
| ボリュームあたりの最大 IOPS (1 MiB I/O) | 500 | 250 |
| ボリュームあたりの最大スループット | 500 MiB/秒 | 250 MiB/秒 |
| Amazon EBS マルチアタッチ | サポート外 | サポート外 |
| スループット最適化 HDD (st1) ボリューム | ||
| スループット最適化 HDD (st1) ボリュームは、IOPS ではなくスループットでパフォーマンスを示し、低コストに使用できる。このボリュームタイプは、Amazon EMR、ETL、データウェアハウス、ログ処理など、サイズの大きなシーケンシャルワークロードに適している。 | ||
| スループット最適化 HDD は Cold HDD に似ているが、アクセスが頻繁なデータをサポートするように設計されている。 | ||
| Cold HDD (sc1) ボリューム | ||
| Cold HDDボリュームは、IOPS ではなくスループットでパフォーマンスを示し、低コストに使用できる。Cold HDD は、スループット最適化 HDDよりスループット制限が低く、サイズの大きなコールドデータの連続した通信に適している。データへのアクセス頻度が低く、コストの削減が必要である場合は、低コストなブロックストレージとして使用できます。 |
Cold HDD ボリュームは スループット最適化 HDDボリュームに類似していますが、アクセスの頻度の低いデータをサポートするように設計されています。
■■■旧世代のボリュームタイプ
次の表は、旧世代の EBS ボリュームタイプを示しています。旧世代のボリュームより高いパフォーマンスまたはパフォーマンスの安定性が必要であれば、汎用 SSD (gp2) など現行のボリュームタイプの使用を検討するようお勧めします
| * | マグネティック |
|---|---|
| ボリュームタイプ | standard |
| ユースケース | データへのアクセス頻度が低いワークロード |
| ボリュームサイズ | 1 GiB～1 TiB |
| ボリュームあたりの最大 IOPS (1 MiB I/O) | 40～200 |
| ボリュームあたりの最大スループット | 40～90 MiB/秒 |
| インスタンスあたりの最大 IOPS | 80,000 |
| インスタンスあたりの最大スループット | 1,750 MB/秒 |
| マグネティック ボリューム | |
| マグネティックボリュームはデータに順次アクセスするアクセス方式をとる場合や、小さなボリュームサイズで低コストのストレージが必要となる場合に使用する。IOPS、スループット能力は低い。マグネティック は、旧世代のボリュームタイプなのであまりおすすめしない。 |
今回は新しくてより料金の安いgp3ボリュームを使用してみようと思う。
■IOPSとは
ボリュームがサポート可能な 1 秒間あたりの I/O 操作回数の指定値です。プロビジョンド IOPS (SSD) ボリュームでは、io1 については 1 GiB あたり 50 IOPS まで、io2 については 1 GiB あたり 500 IOPS まで処理できます。汎用 (SSD) ボリュームの場合、ベースラインパフォーマンスは 1 GiB あたり 3 IOPS で、最小値は 100 IOPSで最大値は 16000 IOPS です。1000 GiB 未満の汎用 (SSD) ボリュームでは、最大で 3000 IOPS までバースト可能です。
１秒あたりでできる入力と出力の回数のことらしい。
ボリュームのGiBによって計算で決まるが、プロビジョンド IOPS SSDボリュームに限ってはボリュームの作成時に一定の IOPS レートを指定できる。
また、gp3ボリュームの場合も、無料枠で最大パフォーマンスとなる3,000IOPSと125MiB/秒を設定できるので3,000IOPSと設定する。無料枠！
■スループット (MB/秒)
スループットはボリュームがサポートする Streaming Optimized volumes: ST1 and SC1 に指定されています。
gp3ボリュームの場合、無料枠で最大パフォーマンスとなる3,000IOPSと125MiB/秒を設定できるので125MiB/秒と設定する。無料枠！
■終了時に削除
EBS ボリュームは、EC2 インスタンスの運用状況から独立した永続性を持ちます。ただし、関連付けられたインスタンスが終了されたときに EBS ボリュームが自動的に削除されるように選択することができます。
インスタンス終了時にEBSも一緒に削除するか？ってことらしい。
うーん、今回は残しておこう。
■暗号化
アカウント設定では、作成できるのは暗号化された EBS ボリュームだけです。暗号化に使用されるキーは事前に入力されています。別のキーで暗号化するには、ドロップダウンから選択するか、フルキーの ARN を入力します。
EBS 暗号化の仕組み
EC2 インスタンスのブートボリュームとデータボリュームの両方を暗号化できます。暗号化された EBS ボリュームを作成し、サポートされるインスタンスタイプにアタッチする場合、以下のタイプのデータが暗号化されます。
・ボリューム内の保存データ
・ボリュームとインスタンスの間で移動されるすべてのデータ
・ボリュームから作成されたすべてのスナップショット
・それらのスナップショットから作成されたすべてのボリューム
EBSはAWS KMS と連携してEBS ボリュームを暗号化、復号し、暗号化は、すべての EBS ボリュームタイプでサポートされる。
※AWS Key Management Service (AWS KMS) は、データの暗号化に使用される暗号化キー、カスタマーマスターキーの作成と管理を容易にするマネージド型サービス
暗号化サービス使うか？ってことを聞いているらしい。('_')
ボリューム内のデータが暗号化されるからといって、リモートログイン後にファイルアクセスするには復号しなければならないかというとそうではありません。暗号化と復号は透過的に処理されるため、リモート接続後は復号するためのコマンドや処理は必要ありません。 EBSボリュームの暗号化 = AWSデータセンターに設置されている物理サーバのストレージの暗号化 といえます。AWSデータセンターからストレージが万が一盗まれたり、データセンターに侵入して直接サーバにログインされた場合に備えた対策といえます。なので、万が一サーバにSSHなどでリモートから侵入された場合、EBSボリュームが暗号化されたとしてもデータは抜き取ることができてしまいます。
AMI、EBSスナップショット作成
暗号化されたEBSボリュームを含んだAMIを作成し、AWSアカウント間で共有する際は注意が必要です。
AMI作成(正確にはEBSスナップショットの暗号化)時に暗号化するキーを指定する必要があります。見落としがちなのが、デフォルトの暗号化キー(aws/ebs)だと他のAWSアカウントにEBSスナップショットを共有できないため、カスタムで作成したKMS暗号化キーを指定する必要があることです。
暗号化されたEBSスナップショットを含んだAMIは他のAWSアカウントと共有できません。他AWSアカウントに移したい場合は、EBSスナップショットをぞれぞれ共有・コピーし、コピー先のAWSアカウント上でEBSスナップショットからAMIを作る必要があります。
あとEC2インスタンスの起動時のは暗号化されたEBSボリュームがアタッチされているEC2インスタンスを起動する際に、KMSの権限が必要になる。権限が不足していると起動してもすぐに停止状態になってしまうので注意が必要だそうだ。
テストだし複雑さが増すので今回はいらない(^_-)-☆
まとめ
長くなっちゃった(>_<)
Discussion