カスタマーサクセス部 佐竹です。
本日はエンドユーザー様からよく聞かれる運用上の質問に回答してみたいと思います。
はじめに
AWS における EC2 インスタンスのコスト最適化のために、EBS ボリュームのボリュームタイプを gp2 から gp3 に変更する機会が増えています。また、変更によるコスト最適化効果は、およそ 20% 程度になります。
gp3 への変更によるコスト最適化効果等の詳しい説明は、以下にご紹介しますサーバーワークスエンジニアブログをご参考ください。
Amazon EBS ボリュームを gp2 から gp3 へ切り替えコストを削減する
Amazon EBSのgp2・gp3の比較をもっと簡単に知りたい
gp3 への変更にかかる時間が知りたい背景
まず、EBS ボリュームのボリュームタイプを gp2 から gp3 に変更するには、「Modify（変更）」という機能を利用します。これに関する AWS 公式ドキュメントは以下の通りです。
同様の処理は AWS CLI では aws ec2 modify-volume というコマンドを実行することになります。この「Modify（変更）」処理ですが、瞬間的に完了するわけではありません。
AWS ドキュメントから抜粋すると「通常、完全に使用された 1 TiB ボリュームが新しいパフォーマンス設定に移行するまでには約 6 時間かかります。」とのことです。
よって、gp3 へ正しく切り替わったかどうかを確認したいという場合には、変更が完了するまでその容量に伴い待ち時間が増えてしまいます。
運用上必ず gp3 への変更完了を待つ必要はない
まず重要なのは、基本的には EBS ボリュームが完全に gp3 へ変更されるまで待機して待つ必要はございません。
EBS ボリュームに「Modify（変更）」を実行した場合、そのボリュームのステータスは modifying → optimizing → completed の順に切り替わりますが、optimizing となっている EBS ボリュームは以下に記載されている通り、パフォーマンスが劣化するわけではないためです。
optimizing状態である場合、ボリュームのパフォーマンスはソースとターゲットの設定仕様の中間にあります。過渡的なボリュームのパフォーマンスは、ソースボリュームのパフォーマンスより劣ることはありません。https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/monitoring-volume-modifications.html
さらに以下の注記も同ドキュメントに記載があります。
まれに、一時的な AWS エラーのために
failed状態になる場合があります。これは、ボリュームのヘルスステータスを示すものではなく、ボリュームの変更に失敗したことを単に示しています。この場合は、再度ボリュームの変更を行います。
このように、gp3 への変更を待つ理由は特に見当たらないため、基本的に待機は必要がないと考えられます。
実際に、弊社が本作業を代行する場合でも、このような待機は（例外を除き）実施していない場合がほとんどです。ボリュームへの変更コマンドを実行した後は、翌日等に都度進行状況を確認するために各ボリュームのステータスを閲覧する程度であり、リアルタイムでの待機は人件費を鑑みてもコストパフォーマンスが悪いでしょう。
待機しないとしても変更完了までの目安が知りたい
先の通り、待機は不要と記載しましたが、そうは言っても「おおよその完了時間の目途だけはつけておきたい」というご要望は多く頂きます。特に gp3 への変更手順を検証中のエンドユーザー様からよく耳にするご要望です。
それでは、これら「gp3 への変更までにかかった処理時間を知りたい」または「gp3 への変更がいつ完了したのか知りたい」というご要望にどのように対応が可能でしょうか？
1つの回答として、もしこれらを AWS マネジメントコンソールの操作で対応する場合、都度ボリュームのステータスを目で確認し続ける運用が必要になってしまいます。
また AWS CloudTrail や AWS Config ではこのステータス変更を得ることはできないようです。
そこで今回は「仕組み」を持って対応していきます。さてその具体的な「仕組み」の話ですが、本対応には Amazon EventBridge が有効です。
Amazon EventBridge でボリューム変更の開始と完了をそれぞれ通知する
Amazon EventBridge では、EBS ボリュームのステータス変更をトリガーに通知を行うことが可能です。
本設定方法は先にもご紹介しました以下の AWS 公式ドキュメントに記載がありますが、記載が少々古く CloudWatch Event となっています。
本ブログでは、現在は CloudWatch Event から刷新のされた Amazon EventBridge で実際に設定していきます。
また、本ブログでは SNS トピックの設定については触れておりません。SNS のトピックが必要な場合は以下の手順を実行前に作成をお願いします。
マネジメントコンソールでの実装方法
今回は都合、バージニアリージョン (us-east-1) で実装します。東京リージョンをご利用される場合は、リージョンの選択に注意してください。
Amazon EventBridge ルールの作成
まずは、Amazon EventBridge のコンソールに移動し、左端のメニューから「バス」→「ルール」を選択します。
次に、ルールの画面が表示されたら「ルールを作成」を押下します。
補足すると「イベントバス」の設定は「default」のままで問題ありません。
ルールの詳細を定義
「ルールの詳細を定義」で名前を入力する必要があります。今回は「ModifyVolume-Notification」としました。
他の設定はそのままで次へ進みます。
イベントパターンを構築
イベントソースは「AWS イベントまたは EventBridge パートナーイベント」のまま変更せず、画面を下にスクロールして「作成のメソッド」まで移動します。
「作成のメソッド」では、今回 JSON を利用するため「カスタムパターン (JSON エディタ)」を選択します。
その後、「イベントパターン」に以下の JSON を貼り付けます。
{
"source": ["aws.ec2"],
"detail-type": ["EBS Volume Notification"],
"detail": {
"event": ["modifyVolume"]
}
}
貼り付け終わったら、次へ進みます。
ターゲットを選択
「ターゲットタイプ」を「AWS のサービス」のまま、ターゲットとして SNS トピックを選択します。もし SNS トピックが存在しない場合は新規に作成を行い、リロードボタンを押下してください。
トピックを選択し終えたら、次へ進みます。
タグを設定 - オプション
タグは必要な場合に付与してください。今回は設定せずにそのまま次へ進みます。
レビューと作成
レビュー画面で確認を行います。
問題がなければ画面右下の「ルールの作成」を押下して設定は完了です。
正しく作成が完了していると「Amazon EventBridge > ルール」において、上画像の通り詳細の閲覧が可能です。
動作確認
作成したルールが正しく動作するかどうか、動作確認を行っていきます。
ボリュームの変更
今回は検証のために「vol-05a79e79d4c4f9368」を利用します。現在タイプが「gp2」になっていますので、これを「gp3」へと変更します。
ボリュームの変更画面にてボリュームタイプに「汎用 SSD (gp3)」 を選択した後、画面右下の「変更」で先に進みます。
「vol-05a79e79d4c4f9368 を変更しますか?」と確認画面が表示されますので、「変更」を押下して進みます。
result optimizing の通知
設定変更がリクエストされると「ボリュームのボリュームの変更をリクエスト vol-05a79e79d4c4f9368.」という画面がマネジメントコンソール最上部に表示されます。
これと同時に、SNS トピックに "EBS Volume Notification" の通知が行われます。以下がメールで受け取った JSON を整形したものです。
{
"version": "0",
"id": "5885ed62-e28c-2d27-c7ee-70719cfe449e",
"detail-type": "EBS Volume Notification",
"source": "aws.ec2",
"account": "123456789012",
"time": "2023-02-08T07:31:02Z",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:123456789012:volume/vol-05a79e79d4c4f9368"
],
"detail": {
"result": "optimizing",
"cause": "",
"event": "modifyVolume",
"request-id": "f3c71913-4452-405f-a851-31b442972621"
}
}
なお、AWS Chatbot 連携にも対応していますが、情報がかなり少ないようでした。
詳細な値を受け取りたい場合は、メールでの通知を推奨します。
また、処理の進行中はマネジメントコンソールの「ボリュームの状態」からも状況を確認することができます。
result completed の通知
gp3 への変更処理が完了すると同時に、再度 SNS トピックに "EBS Volume Notification" の通知が行われます。先ほどと同様に、以下にメールで受け取った JSON を整形し掲載します。
{
"version": "0",
"id": "df2940ae-b75d-77e8-88a3-3c892b5bf2de",
"detail-type": "EBS Volume Notification",
"source": "aws.ec2",
"account": "123456789012",
"time": "2023-02-08T07:36:16Z",
"region": "us-east-1",
"resources": [
"arn:aws:ec2:us-east-1:123456789012:volume/vol-05a79e79d4c4f9368"
],
"detail": {
"result": "completed",
"cause": "",
"event": "modifyVolume",
"request-id": "677ff3da-c25f-4f09-bd82-025f768fa16f"
}
}
こちらも、参考まで AWS Chatbot の結果を掲載します。
通知内容の振り返り
今回、通知結果 JSON の時刻は以下の通りでした。分かり易いように、result と time だけを JSON から取り出して比較しています。
| Result Status | time (UTC) |
|---|---|
| optimizing | 2023-02-08T07:31:02Z |
| completed | 2023-02-08T07:36:16Z |
およそ5分程度で処理が完了したようです。また、いつ gp3 への変更処理が完了したかも「time」の値を見ることで明らかです。
これらの通り、Amazon EventBridge と SNS トピックを利用した実際の動作確認は正常に完了しました。
まとめ
今回のブログでは、運用中のエンドユーザー様からしばしばお問い合わせを頂きます「gp3 への変更までにかかった処理時間を知りたい」「gp3 への変更がいつ完了したのか知りたい」というご要望にお応えするために、Amazon EventBridge と SNS トピックを利用して時間を取得する方法について記載しました。
また、ブログ内で比較したように、Amazon EventBridge はネイティブに AWS Chatbot から Slack への直接投稿に対応していますが、掲載される内容を比較したところメールアドレスへの通知が情報量としても推奨されることがわかりました。
なお、今回ご紹介した Amazon EventBridge の「イベントパターン」は、そのリージョンにおける全ての EBS ボリュームを対象とする設定です。もし特定の EBS ボリュームのみに絞り込みたいような場合は、イベントパターンの設定変更で対応が可能です。このあたりは運用に沿って適切に変更してご活用ください。
今回のブログは以上になります。
それでは、またお会いしましょう。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023-2024 Japan AWS Top Engineers/2020-2024 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
