Amazon Web Services ブログ

AWS Compute Optimizer での Amazon EBS ボリュームの自動最適化のご紹介

本日より、AWS Compute Optimizer は Amazon Elastic Block Store (EBS) ボリュームの最適化方法を効率化する新しい自動化機能を導入します。最適化作業に貴重なエンジニアリング時間を費やす代わりに、Compute Optimizer のデータに基づくレコメンデーションに従って、アタッチされていないボリュームの継続的なクリーンアップとボリュームタイプのアップグレードを行う自動化ルールを作成できるようになりました。これにより、チームは最も重要な業務に集中できるようになります。

レコメンデーションの確認と適用

自動化ルールを設定する前に、アクションを個別にテストしてレコメンデーションの内容をよく理解しておきましょう。新しい「推奨アクション (Recommended actions)」ページには、AWS Compute Optimizer を通じて直接実施できる最適化の機会が一覧表示されます。実施したいアクションを選択してクリックするだけで適用できます。利用可能な最適化アクションは 2 つあります:

  • アタッチされていない Amazon EBS ボリュームのスナップショット作成と削除: EC2 インスタンスに 32 日以上アタッチされていないボリュームに推奨されます。Compute Optimizer はボリュームを削除する前にスナップショットを作成します。このレコメンデーション基準の詳細については、リソースごとのアイドル状態の基準をご参照ください。
  • Amazon EBS ボリュームタイプのアップグレード: gp2 から gp3 へ、io1 から io2 へのアップグレードを推奨します。新世代のボリュームタイプへのアップグレードは、従来のタイプと比べて低価格で優れた IOPS とスループット性能を提供するため、より優れたパフォーマンスとコスト効率を実現できます。

ボリューム ID をクリックすると、レコメンデーションの詳細を確認できます。AWS リージョンやリソースタグでフィルタリングして、最適化したいフリートの特定のセグメントを対象にできます。レコメンデーションを確認した後、適用したいアクションを選択し、次のページで確認して実装を開始します(図 1 を参照)。この手動のアプローチは、一回限りのクリーンアップ作業や、各アクションの確認が必要な場合の最適化プロセスの学習に最適です。

図 1: レコメンデーションの確認と適用

自動化ルールによる最適化の効率化

推奨アクションの内容を把握したら、自動化ルール (automation rules) を使用してリソース全体に実装を展開できます。Compute Optimizer は、ルールの基準に一致するたびに、定期的なスケジュールでレコメンデーションを適用します。

1 つの自動化ルールでグローバルに対応できるため、AWS リージョンごとに個別のルールを作成してデプロイする必要はありません。管理アカウントまたは委任管理者は、複数のアカウントにまたがる組織全体のルールを設定でき、一方でメンバーアカウントは特定のニーズに応じてルールを追加する柔軟性を維持できます (図 2 を参照)。

図 2: 組織用の自動化ルールの作成

特定の要件に合わせて自動化ルールを素早く設定できます。特定の地域を対象とするリージョン、本番環境と開発環境のワークロードを区別するためのリソースタグ (Resource tags)、中断のない最適化アクションをフィルタリングするための「restart needed」フラグなどの条件を指定できます。

条件を設定した後、一致する推奨アクションをプレビューして対象の選択を検証できます。条件に一致する現在の推奨アクションと、ルール条件を検証するためのすべてのアクションおよび推定月間節約額の概要を確認できます。

図 3: 自動化ルールの作成

ルールを日次、週次、または月次で実行するように設定すると、Compute Optimizer はその条件に照らして新しいレコメンデーションを継続的に評価します。これにより、新たに特定された “アタッチされていないボリューム” は自動的にスナップショットが作成されて削除され、古い世代のボリュームタイプはルールに従って自動的にアップグレードされます。手動での介入は必要ありません。

図 4: 定期的なスケジュールの設定

自動化イベントの監視

新しいダッシュボードでは、すべての自動化の状況を把握でき、ステータスと実行月ごとのイベント数と推定月間節約額の概要が表示されます。時間の経過に伴う自動化の進捗状況を追跡でき、必要に応じて最適化戦略を改善するのに役立ちます。

図 5: 自動化イベントの概要

同じダッシュボードで各自動化イベントの詳細を掘り下げることができます。各最適化のステータスを追跡し、各自動化の詳細なステップ履歴を確認し、財務的な影響を数値化できます。

図 6: 各自動化イベントの詳細の取得

安全性を最優先に

運用上の信頼性を提供しリスクを最小限に抑えるため、この機能には安全メカニズムが組み込まれています。自動化システムは、アクションを実行する前にリソースの適格性を確認するチェックを行い、指定した条件に一致するボリュームのみを対象とします。また、Compute Optimizer で実行された自動化アクションを元に戻すこともできます。例えば、削除の前に自動的にスナップショットが作成されるため、データは完全に復元可能な状態が維持され、新しいボリュームとして復元できます。これらの多層的な安全対策が連携して機能することで、大規模な自動化に必要な運用上の信頼性を提供します。

アクションを元に戻す必要がある場合は、「自動化イベント (Automation events)」ページから実行できます。ボリュームの削除の場合、AWS Compute Optimizer は作成されたスナップショットからデータを新しい Amazon EBS ボリューム (新しいボリューム ID を持つ) に復元します。ボリュームタイプのアップグレードの場合、Compute Optimizer は新しいボリューム変更を開始して以前の設定にボリュームタイプを変更することで、アクションを元に戻します。

図 7: 必要に応じて変更をロールバックする

始めるためのヒント

すでに Compute Optimizer をご利用の場合は、コンソールの新しい「自動化 (Automation)」セクションに移動し、アカウントの自動化機能を有効にしてください。オプトインすると、AWS が必要なサービスリンクロールを自動的に作成します。管理アカウントから組織を管理している場合は、メンバーアカウントもオプトインできます。これにより、複数のアカウントにまたがって適用される組織全体のルールを作成できます。Compute Optimizer を初めて使用する場合は、コンソールで数回クリックするか API からでサービスを有効にできます。

最初の自動化ルールは小規模に始めて、戦略的に規模を拡大してください。まずは非本番環境を対象にして、自動化プロセスへの確信を深めていきましょう。特定のアカウントを選択するか、「Environment: Development」や「Environment: Test」などのリソースタグに基づいてフィルタリングすることで、開発環境やテスト環境でアタッチされていない Amazon EBS ボリュームのクリーンアップに焦点を当てたルールを作成してください。

自動化の動作に慣れ、期待される結果を確認できたら、ルールの対象をステージング環境に、そして最終的に本番環境のワークロードへと徐々に拡大してください。また、日次の自動化に移行する前に、まずは週次または月次のスケジュールから始めることもできます。このアプローチにより、条件を微調整しながら運用に関する確信を深めることができ、フリート全体に展開する際には、自動化ルールが十分にテストされ、組織のビジネス要件に沿った状態になります。

まとめ

AWS Compute Optimizer の新しい自動化機能を最適化のツールボックスに加えることで、チームがお客様のためのイノベーションにより多くの時間を費やしながら、継続的なコスト削減とパフォーマンスの向上を追求できます。

開発環境のクリーンアップであれ、最新世代のテクノロジーの活用であれ、自動化ルールは最適化プロセスを効率化するためのスケーラビリティ、一貫性、運用上の安全性を提供します。非本番環境のワークロードから始めて、段階的な拡大を通じて確信を深め、戦略的に規模を拡大することで、AWS インフラストラクチャ全体で継続的なコスト削減とパフォーマンスの向上を実現できます。

AWS Compute Optimizer コンソールにアクセスし、新しい「自動化 (Automation)」セクションを確認して使用を開始してください。詳細については、AWS Compute Optimizer ユーザーガイドのドキュメントをご参照ください。

Jimmy Yang

Jimmy Yang

Jimmy Yang はシニアプロダクトマネージャーで、お客様のクラウド投資を最大限に活用できるよう支援することに注力しています。コスト管理における課題についてお客様と対話し、それらを解決するための新しい製品体験を構築することを楽しみにしています。

翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文はこちらです。