【ITニュース解説】Automating EBS Volume Upsizing on AWS

この解説は、AWS上で稼働するアプリケーションのディスク容量が不足した際に、手動での対応ではなく、システムが自動で検知して拡張する仕組みについて説明する。特に、SAPのような大規模なワークロードではディスク容量の管理が非常に重要であり、コストを最適化しながら安定稼働を維持するために、この自動化ソリューションが有効に機能する。

このシステムの主な目的は、仮想サーバー（EC2インスタンス）に接続されている仮想ハードディスク（EBSボリューム）の空き容量が少なくなったことを検知し、自動的にEBSボリュームのサイズを増やし、さらにその拡張された容量をOSが利用できるようにファイルシステムを拡張することである。これにより、システム管理者による手作業を排除し、サービスを停止することなく、アプリケーションをスムーズに稼働させ続けることができる。

この自動化を実現するために、複数のAWSサービスが連携して動作する。具体的には、EC2インスタンス内のディスク使用率を監視する「Amazon CloudWatch」、その監視結果に基づいて通知を送信する「Amazon SNS」、通知を受け取って処理を実行する「AWS Lambda」、そしてEC2インスタンス上でOSレベルの操作を自動実行する「AWS Systems Manager」が中心的な役割を担う。

まず、監視の基盤を準備することから始める。EC2インスタンスの内部からディスク使用率などの情報を取得するために、「CloudWatchエージェント」というソフトウェアをEC2インスタンスにインストールする。このエージェントをインストールし、設定ウィザードを使って監視対象とするメトリクス（ここではディスクの「使用済み割合（used_percent）」など）を選択することで、EC2インスタンスの内部状況がCloudWatchサービスに定期的に送信されるようになる。CloudWatchのダッシュボードを作成すれば、これらのメトリクスをグラフなどで視覚的に確認できるようになり、現在のディスク使用状況をリアルタイムで把握できる。

次に、この自動拡張システムがEC2インスタンスにアクセスし、OSレベルの操作を実行できるようにするための準備が必要だ。EC2インスタンスがAWS Systems Managerと安全に通信できるように、適切な「IAMロール」をインスタンスに割り当てる。IAMロールは、AWSリソースが他のAWSサービスにアクセスするための許可証のようなもので、「AmazonSSMManagedInstanceCore」というポリシーを持つロールを割り当てることで、Systems Managerがそのインスタンスを管理できるようになる。また、EC2インスタンスがインターネットに直接接続されていないプライベートなネットワークに存在する場合、Systems ManagerなどのAWSサービスと通信するために「VPCエンドポイント」を作成する必要がある。これは、プライベートネットワーク内からAWSサービスへの安全な通信経路を確保する役割を持つ。

これらの準備が整ったら、OSレベルでファイルシステムを拡張する処理を自動化するための「Systems Manager Runbook」を作成する。Runbookとは、Systems Manager上で実行できる一連のコマンドやスクリプトを定義したドキュメントのことである。このRunbookには、EBSボリュームのサイズがAWSレベルで拡張された後に、OSがその新しい容量を認識し、利用できるようにするためのコマンド群を記述する。具体的には、「growpart」コマンドを使ってディスクパーティションのサイズを拡張し、その後「resize2fs」（ext系のファイルシステムの場合）や「xfs_growfs」（XFSファイルシステムの場合）コマンドを使ってファイルシステムそのものを拡張する処理が含まれる。このRunbookは、仮想サーバーの種類（Linuxディストリビューション）やファイルシステムの種類に応じて適切なコマンドを実行するように設計されている。

次に、AWSレベルでEBSボリュームのサイズを拡張し、上記のRunbookを呼び出す役割を担う「AWS Lambda関数」を作成する。Lambdaは、イベントをトリガーとしてコードを実行するサーバーレスなサービスであり、このシステムではCloudWatchアラームからの通知を受けて動作する。Lambda関数には、EBSボリュームの情報を取得し、既存のボリュームサイズに指定した容量（例えば1GB）を追加して、EBSボリュームのサイズを更新するためのAWS API呼び出し（ec2:ModifyVolume）を記述する。ボリュームのサイズ変更後、その変更がEC2インスタンス側で反映されるまで一定時間待機し、その後Systems Managerに対して先ほど作成したRunbookを実行するよう指示する。このLambda関数を実行するためのIAMロールにも、EC2ボリュームの変更、Systems Managerコマンドの送信、CloudWatchへのログ出力に必要な権限を付与する必要がある。

最後に、システム全体のトリガーとなる「CloudWatchアラーム」を設定する。CloudWatchでは、CloudWatchエージェントが収集したディスク使用率のメトリクスに対し、しきい値を設定できる。例えば、ディスク使用率が80%を超過したらアラーム状態になるように設定する。このアラームが「ALARM」状態になった際に、「Amazon SNSトピック」を通じて通知が送信されるように設定する。このSNSトピックは、作成したLambda関数を購読者として登録しておくことで、アラームの通知が直接Lambda関数に渡され、自動拡張処理が開始される。

この自動化システムを実装する上でいくつかの重要な教訓が得られた。まず、EBSボリュームを識別する際には、デバイス名（例：/dev/xvdaや/dev/nvme0n1p1）だけに頼るのではなく、AWSで一意に識別される「VolumeId」を使用することが推奨される。CloudWatchのアラームから直接VolumeIdは取得できないため、Lambda関数内でインスタンス情報からVolumeIdを解決する必要がある。また、システム連携のパターンをシンプルに保つことが重要である。このケースでは「CloudWatchアラーム → SNS → Lambda」という一貫した流れを採用し、各サービスの権限設定もそれに合わせて行う。さらに、自動化されたプロセスでは「安全性」を最優先すべきだ。例えば、どのボリュームを拡張すべきか判断できない場合の「最初のボリュームを拡張する」といった曖昧なフォールバックは避け、意図しないボリュームが拡張されるリスクをなくす。また、処理が重複しないように「冪等性」を考慮し、処理の状況を明確に把握できるようログやアラームを適切に設定することが重要である。これにより、コスト効率を維持しつつ、システムの安定性と信頼性を高める自動ディスク拡張システムが実現できるのだ。