SAA学習-EC2-EBSボリューム
今回のテーマ:EBSボリューム
概要
EBSはEC2インスタンスと共に利用されるブロックストレージで、インスタンス上のワークロードなどに利用されます。
また、EC2インスタンスへのディスク拡張時に活用するケースが多いです。
EBSの種類
EBSの種類として以下のものが挙げられます。
種別名 | 概要 |
---|---|
ブロックストレージ | ・EC2にアタッチし活用するディスクサービス ・ブロック形式でデータを保存 ・高速・広帯域幅 ・例:EBS、インスタンスストア |
オブジェクトストレージ | ・安価かつ高い耐久性をもつオンラインストレージ オブジェクト形式でデータを保存 ・デフォルトで複数AZに冗長化される ・例:S3、Glacier |
ファイルストレージ | ・複数のEC2インスタンスから同時にアタッチ可能な共有ストレージ ・ファイル形式でデータを保存 ・EFS |
EC2が利用できるEBS
EC2インスタンスが利用できるEBSは以下のものが挙げられます。
種別名 | 概要 |
---|---|
インスタンスストア | ・ホストコンピュータに内蔵されたディスクでEC2と不可分のブロックレベルの物理ストレージ ・EC2の一時的なデータが保持され、EC2の停止・終了と共にデータがクリアされる ・無料 |
Elastic Block Store | ・ネットワークで接続されたブロックレベルのストレージでEC2とは独立管理 ・EC2を終了してもEBSデータは保持可能 ・SnapshotをS3に保持可能 ・別途EBS料金が必要 |
EBSの基本的な仕様
EBSの基本的な使用は以下のものになります。
- OSやアプリケーション、データの置き場所などで様々な用途で利用
- 実態はネットワーク接続型ストレージ
- 99.999%の可溶性
- サイズは1GB~16TB
- サイズと利用期間で課金
EBSの特徴
EBSの特徴として以下のものが挙げられます。
- ボリュームデータはAZ内で複数のHWにレプリケートされており、冗長化不要
- セキュリティグループによる通信制御の対象外
- データは永続的に保存
- AZをまたいで接続は不可。同じインスタンスに付け替え可能
- 2019年からプロビジョンドIOPSのみ複数インスタンスで共有は可能
EBSのボリュームタイプ
EBSのボリュームタイプは、ユースケースに応じて性能やコストの異なる4つのタイプを選択します。
なお、1種類は基本利用しないため割愛します。
種別名 | ユースケース | サイズ |
---|---|---|
汎用SSD | ・仮想デスクトップ ・低レイテンシーを要求するアプリ ・小~中規模のデータベース ・開発環境 |
1GB~16TB |
プロビジョンドIOPS | ・高いI/O性能に依存するNoSQLやアプリ ・10,000IOPSや160MB/s超のワークロードや大規模DB ・Nitroシステム、AmazonEC2インスタンス、EBS最適化インスタンスタイプで高速化 |
4GB~16TB |
- HDD
種別名 | ユースケース | サイズ |
---|---|---|
スループット最適化HDD | ・ビックデータ処理 ・DWH ・大規模なETL処理やログ分析 ルートボリュームには利用不可 |
500GB~16TB |
コールドHDD | ・ログデータなどアクセス頻度が低いデータ ・バックアップやアーカイブ ・ルートボリュームには利用不可 |
500GB~16TB |
スナップショットの特徴
EBSのバックアップはスナップショットを利用します。
- スナップショットでバックアップ
- スナップショットからEBSを復元する際は別AZにも可能
- スナップショットはS3に保存される
- スナップショットの2世代目以降は増分データを保存する増分バックアップ(1世代目を削除しても復元は可能)
- スナップショット作成時にブロックレベルで圧縮し、保管するため圧縮後の容量に応じて課金
- スナップショット作成時でもEBSは利用可能
スナップショットの管理
スナップショットの作成時は静止点が推奨ですが、いつでも実行可能でEBS操作に影響を与えません。
また、DLMにより取得期間を設定可能です。
なお、スナップショットを静止点での取得推奨である理由は以下のものが挙げられます。
- ソフトウェアの機能を利用
- ファイルシステムの機能を利用
- バックアップソフトウェアの機能を利用
- アプリケーションの停止
- ファイルシステムのアンマウント
- 保持期間や世代数は無制限
- 世代管理が必要な場合、AWS CLIやAPIなどで自動化する
- DLMを利用しスナップショット取得をスケジューリング可能
スナップショットの共有
スナップショットを共有し利用する用途は以下のものが挙げられます。
- スナップショットはリージョン間を跨いで利用可能
- 権限を変更することで、他のアカウントに移譲することが可能
スナップショットとAMI
AMIはOS設定イメージであり、Snapshotはストレージのバックアップとなります。
実際の手順
- マネージドコンソール-EC2-Elastic Block Store-ボリュームを選択し、ボリュームの作成をクリック
- ボリュームのタイプ、サイズ、AZを選択し、ボリュームの作成をクリック
- 作成されたボリュームを確認する(availableが存在中で、in-useが利用中のステータスとなります。)
- EC2へ追加ディスクを付与する場合、付与するボリュームを選択し、アクション-ボリュームのアタッチをクリック
今回のテーマは以上です。
SAA学習-EC2-AMIの活用
今回のテーマ:AMIの活用
概要
AMIイメージ
AMIイメージの要点として以下のものになります。
AMIイメージの共有
AMIイメージを共有する用途としては以下のものが挙げられます。
- 同一リージョン内で使用可能(多リージョンへはそのまま使用は不可)
- AMIをコピーし他リージョンで起動(概略図は下記になります)
AMIの利用
AMIを利用する項目やその際の概要については以下のものが挙げられます。
項目 | 利用概要 |
---|---|
OSの選択 | ・利用したいサーバーのOSを選択し、AMIを利用 ・利用していたサーバーを復元する際にAMIを利用 |
EC2のバックアップ | ・既存のEC2インスタンスからAMIを作成 ・EC2インスタンスをバックアップし構成情報を保存する。EBSボリュームのスナップショットも含む |
ゴールデンイメージ | ・最適なEC2インスタンス構成を反映したAMIイメージ |
AMIの共有 | ・AMIを共有するユーザーのAWSアカウント番号を指定し、他アカウントに共有可能 |
リージョンの移動 | ・AMIはリージョン内でのみ利用可能 ・別リージョンにコピーすることは可能で、コピー先のAMIは別AMIとなる |
- EC2 Image Builderを利用しAMIの変更管理を自動的にパイプライン対応
実際の手順(AMIの作成)
- インスタンスの起動時の選択で、マイAMI(自作のAMI)、AWSMarketplace(3rdparty)、コミュニティAMI(OSに合わせて実施)
マイAMIを作成するためにいったんキャンセルをします。
WEBサーバーのインスタンスを選択します。
すべて削除していたので、簡単に作成する方法は以下の記事を参照ください。サクサク操作すれば5分でインスタンスが作れます。
過去記事: in-housese.hatenablog.com該当するインスタンスを選択し、アクション-イメージとテンプレート-イメージを作成をクリック
- イメージ名を記載し、イメージの作成をクリック
- マネージドコンソール-EC2-イメージ-AMIの順に選択し、作成したAMIを確認する(スタータスがavailableになったら利用可能になります。)
- 利用可能な状態となったら、該当するAMIを選択し、起動をクリック
コマンド
sudo yum list installed | grep httpd
結果:
eneric-logos-httpd.noarch 18.0.0-4.amzn2 @amzn2-core httpd.x86_64 2.4.46-1.amzn2 @amzn2-core httpd-filesystem.noarch 2.4.46-1.amzn2 @amzn2-core httpd-tools.x86_64 2.4.46-1.amzn2 @amzn2-core
- 無事にインストールされていることを確認。(htmlファイルの作成をしてない状態で起動しているので、確認はここまで)
実際の手順(AMIのコピー)
- マネージドコンソール-EC2-イメージ-AMIの順に選択
- コピーしたいAMIを選択後、アクション-AMIのコピーをクリック
- コピー先のリージョンを選択し、AMIのコピーをクリック(名前や説明は任意で更新)
cf)2021年4月から大阪リージョンを選択できるため、今回は大阪リージョンを指定
- AMIをコピーした先のリージョンへ移動し、AMIがコピーされているか確認
- 作成後は先程と同じ動作確認を実施する。(今回は省略します。)
注意点としてはリージョンを変えるためキーペアやSGは新規で設定する必要があります。
また、課金されないようにAMIのコピー先のリージョンにて概要するAMIの登録を解除しておきます。
- 該当するAMIを選択したら、アクション-登録解除をクリック
- 確認ダイアログが表示されたら、次へをクリック
- 登録中のAMIが存在しないことを確認
実際の手順(AMIの共有)
IAMのクロスアカウントの検証で使用したアカウントと今回は共有します。
クロスアカウント作成については以下の記事を参照ください。(共有先のアカウントIDを控えるため使用)
過去記事: in-housese.hatenablog.com
- マネージドコンソール-EC2-イメージ-AMIの順に選択する
- 共有したいAMIを選択し、アクセス許可タグを選択後、編集をクリック
- 共有先のAWSアカウント番号を入力し、アクセス許可の追加をクリック後、保存をクリック
- 別のアカウントに切り替わったことを確認
- AMIの設定画面より、マイAMIを選択し共有ファイルを選択がふえていることを確認
以降は通常のインスタンスの作成をする作業となります。
実際の手順(EC2 Imange Builder)
- マネージドコンソール-EC2-イメージ-AMIの順に選択し、EC2 Image Builderをクリック
- イメージパイプラインを作成するをクリック
- パイプライン名を記入する。
cf)拡張メタデータ:Imageの追加を収集し運用管理で活用するため有効化のままになります。
管理先は、AWS StstemsManagerにて管理します。
- ビルドスケジュールで更新する頻度や方式を指定し、次へをクリック
- レシピについては新しいレシピを作成するを選択
- イメージタイプはAMIを選択
- 一般は名前、版数管理、説明を記載
- ソースイメージで対象のイメージなどを選択(今回は任意で作成AMIを指定するためカスタムAMIIDを選択)
今回はWEBサーバーなのでapacheを検索し指定
- ビルド後の出力するAMIは指定しない。
- ストレージサイズの更新も変更せず、確認後、次へをクリック
- インストラクチャ設定はデフォルトの設定オプションを指定し、次へをクリック
- ディスビュージョン設定はデフォルトの設定オプションを指定し、次へをクリック
- 設定を確認し、パイプラインを作成するをクリック
- パイプラインよりイメージを手動で作成する場合、イメージパイプライン-作成したパイプラインを選択後、アクション-パイプラインを実行するをクリック
- イメージに実行された結果が存在することを確認
今回のテーマは以上です。
cf)失敗談:
- マーケットプレースよりAMIを起動する際、m5インスタンスから変更忘れたのがこちら
SAA学習-EC2-Savings Pansの利用/RIの購入/専用ホストの利用/キャパシティ予約の利用
今回のテーマ:Savings Pansの利用/リザーブドインスタンスの購入/専用ホストの利用/キャパシティ予約の利用
Savings Pansの利用
- 1年または3年分の利用量を予約することにより、AWSの使用料金を下げる仕組み
- リザーブドインスタンスはEC2自身の利用予約であり、1時間あたりの利用量(キャパシティの予約)
- EC2以外の購入をすることが可能(FargateやLambda )
実際の手順
- マネージメントコンソール-EC-インスタンス-Savings Plansを選択し、Purchase Savings Plansをクリック
- AWSコスト管理の画面に遷移後、Savings Panaを購入クリック
- Saving Planタイプの選択、購入コミットメント(時間単位の費用と支払い方法)、開始日時を選択
- 選択したサンプル
- 購入の概要で費用を確認し、カートに追加をクリック
- カートの中身を確認する。(注文書の送信をクリックすると購入することになります。)
- 誤って購入しないようにするため、カートに入っているSavings Plansを選択し、カートから削除をクリック
- カート内にSavings Plansが存在しないことを確認
リザーブドインスタンスの購入概要
実際の手順
- 購入するタイプを指定します。
- OS、HW占有するか否か、形式(固定で購入するか途中でスケールアップするか)、ファミリ、期間、支払い方法を記載後検索をクリック
- 検索結果の仕様を確認し、カートに入れるをクリック後、カートを見るをクリック
- 注文する中身を確認(すべて注文をクリックすると購入することになります。)
- 購入した後は該当するインスタンスを起動が必要
専用ホストの概要
- HWを占有し購入する形態
- 社内のセキュリティポリシーなどの規約で制限がある際は活用(ただし割高)
実際の手順
- マネージメントコンソール-EC-インスタンス-専用ホストを選択し、専用ホストの割り当てをクリック
- 専用ホストの設定で必要な設定を行う。(Name tag、インスタンスファミリーやタイプ、数量など)
- Tagの内容を確認(割り当てをクリックすると購入することになるため今回はキャンセルします。)
キャパシティ予約の概要
- オンデマンドインスタンスに対し使用するリソースの予約
- EC2をたくさん起動する際にEC2の起動が失敗する場合があり、リソースを確保するため(Auto-Scalingなど)
実際の手順
- マネージメントコンソール-EC-インスタンス-キャパシティ予約を選択し、キャパシティ予約の割り当てをクリック
- 予約の詳細で開始時間などを指定し作成をクリック
- 確認ダイアログが表示される(確認をクリックするとキャパシティが予約されインスタンスが勝手に起動します。)
- 間違ってキャパシティの予約をした場合、予約したキャパシティを選択し、予約のキャンセルクリック
- 確認ダイアログで予約のキャンセルをクリック
今回のテーマは以上です。
cf)仕事のコラム
専用ホストはに関する知識がなく昔質問があった際に返答できなかったため、
知識を得ることは大切だと振り返りの実感になります。
SAA学習-EC2-スポットリクエストの設定
今回のテーマ:スポットリクエストの設定
概要
- オンデマンド価格より低価で利用できるEC2インスタンス
- 永続的に固定化をするインスタンスではなくリソース使用量などで拡張を要する際に活用するインスタンス
- スポットフリート(起動するインスタンスの数などを定義)を指定しまとめて起動
- AWS側で作成したインスタンスを強制削除する仕様
実際の手順①:EC2からスポットリスクエスト
※設定するスコープで必要な個所のみ抜粋します。
- AMIは使用するOSを選択(今回もAmazon Linux2)
- ファミリーは使用するインスタンスタイプを選択(今回も無料枠のt2.micro)
- 購入のオプションのスポットインスタンスのリクエストにチェックする。
永続的リクエストはファミリーで使用できるタイプが制限されt2シリーズは使用できないため未チェック
- ストレージは使用するHDDサイズおよびタイプを指定(今回もデフォルトの値)
- タグはNameキーを設定
- セキュリティグループはシステムへのアクセスコントロール範囲を指定(今回はSSHのみ)
- 設定の確認後、キーペアを設定指定しインスタンスの作成
実際の手順②スポットリクエストから作成(ワークロードのバランシング)
- ユースケースに合わせてニーズを指定。(今回はワークロードのロードバランシング)
- インスタンスの設定。(ネットワークのみ更新)
- 必要な容量を設定。(システムとして使用するリソースの維持方法や最大コスト指定)
- その他のリクエストはデフォルトでフリートの強度が十分であることを確認し、作成をクリック
cf)インスタンスを削除したの場合、スポットリクエストに永続的なインスタンスを定義していたら、自動でインスタンスが作成されます。
実際の手順②スポットリクエストから作成(定義された期間のワークロード)
夜間バッチ処理を行う場合一時的に複数台かつ指定された時間帯のみ実行させる場合に採用
- ユースケースに合わせてニーズを指定(今回は定義された期間のワークロード)
- インスタンスの設定で起動する項目を選択
- 追加設定はSGを指定。パブリックサブネットの場合はパブリックIPの有効化を選択
- 必要な容量を指定し、作成をクリック
- 作成するリクエスト条件が上限に達した場合は以下のように作成時でエラーがでます。この場合はしばらく時間が経過してから、再度実行します。(コストを0.05USドルとしたからだと判断してます。)
今回のテーマは以上です。
SAA学習-EC2-起動テンプレートの設定
今回のテーマ:起動テンプレート
概要
起動テンプレートを使用する概要としては以下のものが挙げられます。
- 作成したインスタンス自身をテンプレート化する仕組み
- 一度作成するまでの設定項目数は多い
- 作成したテンプレートのバージョン管理ができるためメンテナンス性に優れる
実際の作業
- マネージメントコンソール-EC2-インスタンス-テンプレートの起動を選択し、起動テンプレートを作成をクリック
- 以下は実際の設定となり、設定終了後、起動テンプレートを作成をクリック
起動テンプレート名と説明
- 名称は任意として、他の設定はデフォルトで設定
起動テンプレートのコンテンツ
- ネットワークの設定は櫃はデフォルト(固有SGはネットワークインターフェースで付与)
- ストレージは必要なボリュームを選択
- リソースタグは任意
- ネットワークインターフェースは必要なNICとAZの配置先を指定
- 高度な詳細はユーザーデータなどの実装を追加
- 作成されたテンプレートが作成されたことを確認
- 起動したいテンプレートを選択し、アクション-テンプレートからインスタンスを起動をクリック
- 作成したテンプレートの設定を確認し、テンプレートからインスタンスを起動をクリック
- インスタンスの起動を確認
マネージドサービスで標準的なサーバ準備し複数作成や提供する場合、
このサービスは活用しやすいかと思います。
今回のテーマは以上です。
SAA学習-EC2-ユーザーデータの活用
今回のテーマ:ユーザーデータの活用
ユーザーデータ
EC2起動時にユーザーデータへスクリプトを設定し、Linuxの初期設定を自動で実装する。
実行するコマンドの概要説明
コマンド | 活用内容 |
---|---|
sed -i 's/^HOSTNAME=[a-zA-Z0-9.-]*$/HOSTNAME=web-sv/g' /etc/sysconfig/network | ホスト名を変更する。 |
hostname 'web-sv' | |
cp /usr/share/zoneinfo/Japan /etc/localtime | 日本の時間帯をコピー変更 |
sed -i 's | ^ZONE=[a-zA-Z0-9.-\"]*$|ZONE="Asia/Tokyo"|g' /etc/sysconfig/clock | サーバーの時間帯を日本時間へ変更 |
echo "LANG=ja_JP.UTF-8" > /etc/sysconfig/i18n | 言語設定をja_JP.UTF-8に設定 |
sudo yum update -y | ソフトウェアの更新状態を確認する |
sudo yum install httpd -y | サーバーにApacheをインストールする |
- 投入するシェルスクリプト
#!/bin/bash # サーバーの設定変更 sed -i 's/^HOSTNAME=[a-zA-Z0-9\.\-]*$/HOSTNAME=web-sv/g' /etc/sysconfig/network hostname 'web-sv' cp /usr/share/zoneinfo/Japan /etc/localtime sed -i 's|^ZONE=[a-zA-Z0-9\.\-\"]*$|ZONE="Asia/Tokyo"|g' /etc/sysconfig/clock echo "LANG=ja_JP.UTF-8" > /etc/sysconfig/i18n # アパッチのインストール sudo yum update -y sudo yum install httpd -y
実装
- マネージメントコンソール-EC2-インスタンスの起動の順に選択し、インタンスの起動をクリック
- AMIはLinuxのAMIを選択し、選択をクリック
- ファミリアーは無料枠のt2.microを選択し、次のステップ:インスタンスの詳細の設定をクリック
今回のポイントはこちらの設定になります。
- ネットワークは作成済みのVPCを選択
- サブネットはパブリックサブネットを1aを選択
- 高度な設定の「ユーザーデータ」にて投入するシェルスクリプトの内容を使用する。
設定を終えたら、次のステップ:ストレージの追加をクリック
ディスクサイズはそのまま8GBでよいので変更なしで、次のステップ:タグの追加をクリック
- タグ名はNameを付与して、値はホスト名と同じ値とし、次のステップ:セキュリティグループの設定をクリック
- セキュリティグループは前回のハンズオンのwebサーバ系のセキュリティグループを選択し、確認と作成をクリック
- 設定値を確認したら、起動をクリックしキーペアを設定後、インスタンスの起動をクリック
- インスタンスの起動を確認
確認
- ターミナルを起動して、インスタンスへログイン
- ホスト名とhttpdがインストールされているか以下のコマンドを実施
コマンド:
uname -n ; yum list installed | grep httpd
実行結果:
[ec2-user@web-sv ~]$ uname -n ; yum list installed | grep httpd web-sv generic-logos-httpd.noarch 18.0.0-4.amzn2 @amzn2-core httpd.x86_64 2.4.46-1.amzn2 @amzn2-core httpd-filesystem.noarch 2.4.46-1.amzn2 @amzn2-core httpd-tools.x86_64 2.4.46-1.amzn2 @amzn2-core [ec2-user@web-sv ~]$
期待値通りの設定を確認できたので問題なしと判断になります。
今回のテーマは以上です。