Amazon RDS for SQL Server における追加ストレージボリュームによるストレージの改善

本記事は 2026 年 4 月 14 日に公開された “Improving storage with additional storage volumes in Amazon RDS for SQL Server” を翻訳したものです。

Amazon RDS for SQL Server のストレージアーキテクチャを改善したいとお考えなら、追加ストレージボリューム機能がデータベースの容量、パフォーマンス、コストの管理方法を大きく変えることができます。この機能により、複数のボリュームをプロビジョニングすることで Amazon Elastic Block Store (Amazon EBS) の 64 TiB の制限を超えることが可能になります。RDS 上で SQL Server のワークロードが増大すると、64 TiB のストレージ制限がビジネスの成長を制約するアーキテクチャ上の問題を引き起こし、トランザクションログとデータが I/O リソースを奪い合うことでパフォーマンスのボトルネックが生じる可能性があります。Amazon RDS for SQL Server の追加ストレージボリューム機能は、これらの課題を解決します。Amazon RDS for SQL Server を使用して、ルートボリューム以外に追加のストレージボリュームをアタッチでき、各ボリュームに異なるストレージクラスとパフォーマンス特性を設定できます。

この記事では、Amazon RDS for SQL Server の追加ストレージボリューム機能を使用して、これらの一般的な課題に対処する方法を学びます。追加ストレージボリュームの以下の 6 つの主要なユースケースの実装方法を学びます：

64 TiB を超える容量の拡張
動的な一時ストレージの管理
カスタマイズされた IOPS 設定によるパフォーマンスの向上
ストレージクラスの選択によるコスト削減
トランザクションログの分離
マルチテナントストレージの分離の実装

ユースケース

まず、RDS for SQL Server 内で追加ストレージボリュームを追加または変更する方法を紹介したこちらの記事をご確認ください。以下のセクションでは、マルチボリューム機能のユースケースについて説明します。これらのユースケースでは、アプリケーションレベルまたはデータベースエンジンの再設計が必要になる場合があります。データベーススキーマの変更については、記事の後半でスクリプトを提供しています。

ユースケース1 : 書き込み負荷の高いワークロードにおけるログファイルの分離

トランザクションログのパフォーマンスは、データベースのコミットレイテンシーとアプリケーション全体の応答性にとって重要です。以前は、トランザクションログがデータファイルと同じボリュームを共有していたため、読み取りと書き込みの両方の操作に影響を与える I/O の競合が発生する可能性がありました。これは、大規模なテーブルスキャンやインデックスの再構築などのデータファイルの負荷が高い操作が、トランザクションのコミットを遅延させ、ユーザーエクスペリエンスに影響を与える可能性があることを意味します。追加ストレージボリュームを使用すると、以下の方法でトランザクションログをシーケンシャル書き込み操作専用に設計された専用ボリュームに分離できます：

トランザクションログをスループット設定が改善された専用ボリュームに配置する
ログの書き込みパターンに特化した独立した IOPS とスループットを設定する
ログの I/O パフォーマンスをデータファイルの I/O パフォーマンスとは別に監視する

このアプローチは、高トランザクションの Online Transaction Processing (OLTP) システム、Extract, Transform, Load (ETL) ワークロード、およびトランザクションのコミットレイテンシーがユーザーエクスペリエンスに直接影響するアプリケーションに推奨されます。ログに必要なパフォーマンス特性にのみ料金を支払うことで、プライマリデータボリュームのオーバープロビジョニングを回避しながら、書き込みパフォーマンスを向上させることができます。この方法を環境内で実装する方法については、「スクリプト 3: H: ドライブと I: ドライブの特定のファイル場所に新しいデータベースを作成する」をご確認ください。

ユースケース 2: ストレージ容量の拡張

Amazon RDS for SQL Server は、以前はインスタンスあたり最大 64 TiB のストレージ容量をサポートしていました。マルチボリュームサポートの導入により、最大 3 つの追加ボリュームをアタッチでき、すべてのボリュームを合わせて合計 256 TiB までデータベースをスケールできるようになりました。この機能は、増大する履歴データを持つデータウェアハウス、急速に拡大するデータセット、および単一の RDS for SQL Server インスタンスへの複数データベースの統合に特に有用です。また、水平シャーディングの必要性も軽減されます。さらに、以前 RDS for SQL Server の 64 TiB の容量制限に近づいていたデータベースは、ストレージフルのシナリオに遭遇するリスクなく、十分な余裕を持って成長できるようになりました。データを複数のボリュームに分散することで、新しいインスタンスに移行することなく、ワークロードが必要とする合計ストレージ容量を実現できます。

ユースケース 3: 動的な一時ストレージ管理

マルチボリュームサポートの主要な利点の 1 つは、必要に応じてボリュームを追加および削除できることです。以前は、一時的な操作のためにストレージサイズを増やす必要がある場合、デフォルトボリュームを拡張する必要がありました。これは、新しいインスタンスに移行しない限り元に戻せない変更でした。現在は以下のことが可能です：

大規模なバッチ操作用に一時ボリュームをアタッチする
データのインポートや変換に追加スペースを使用する
不要になったストレージボリュームを削除する

このアプローチは、必要なストレージに必要な時だけ料金を支払うため、コストを節約できます。非本番環境は特にこの柔軟性の恩恵を受けます。大規模なデータセットのテスト用にストレージをスケールアップし、テスト完了後すぐに削除できるためです。

ユースケース 4: ストレージ仕様によるパフォーマンスの最適化

ワークロードによってパフォーマンス要件は異なります。マルチボリュームサポートにより、複数のボリュームにわたって異なる IOPS とスループット設定を使用することで、ストレージパフォーマンスをデータアクセスパターンに合わせることができます。例えば、以下のように設定できます：

頻繁にアクセスされるトランザクションデータ用に IOPS を高く設定した高パフォーマンスの gp3 ボリューム
アーカイブやレポートデータ用にベースラインパフォーマンスを備えた標準的な gp3 ボリューム

このきめ細かな制御により、最も重要な部分のパフォーマンスを向上させながら、重要度の低いデータに対するリソースのオーバープロビジョニングを回避できます。

ユースケース 5: ストレージクラスの選択によるコスト最適化

パフォーマンスチューニングに加えて、異なるデータタイプに対して異なるストレージクラスを選択することでコストを最適化できます。Amazon RDS for SQL Server は、gp3 や io2 を含む複数のストレージクラスをサポートしています。戦略的なストレージクラスの割り当てにより、以下のことが可能です：

一貫した高パフォーマンスを必要とする I/O 集約型でミッションクリティカルなデータベースには io2 を使用する
バランスの取れた価格性能比の汎用ワークロードには gp3 を使用する
アクセスパターンの変化に応じてストレージクラス間でデータを移行する

どのストレージクラスが適切かを判断するには、「セルフマネージドデータベースデプロイメントに最適な Amazon EBS ボリュームタイプの選択」をご確認ください。

ストレージコストをデータアクセスパターンに合わせることで、パフォーマンスとコストの両方を改善できます。

ユースケース 6: ストレージ分離によるマルチテナントデータベースの統合

単一インスタンスで複数テナントのデータベースを管理する場合、テナントごとのストレージ消費量とコストを追跡することは従来困難でした。すべてのデータベースが同じボリュームを共有している場合、個々の顧客のストレージ使用量を正確に測定したり、公平なチャージバックモデルを実装したりすることができません。この可視性の欠如は、キャパシティプランニングを複雑にし、どの顧客がストレージの増加を引き起こしているかを特定することを困難にします。追加ストレージボリュームにより、以下のことが可能になるため、マルチテナントアーキテクチャで真のストレージ分離を実現できます：

各主要顧客またはテナントグループに専用ボリュームを割り当てる
ボリュームレベルのメトリクスを通じてテナントごとの正確なストレージ消費量を追跡する
他のテナントに影響を与えることなく、個々のテナントのストレージを独立してスケールする
実際の使用量に基づいた正確なチャージバックモデルを実装する

この機能は、複数の顧客にサービスを提供する Software as a Service (SaaS) アプリケーション、クライアントデータベースをホストするマネージドサービスプロバイダー、および異なるビジネスユニットをサポートするエンタープライズ共有サービスに特に有用です。ストレージコストをテナントの消費量に直接紐づけることで、透明性のある課金を実現し、テナント間のストレージ補助金を排除できます。

データ移行アプローチ

追加ボリュームを設定した後、新しいストレージアーキテクチャを使用するためにデータを移動する必要があります。以下のセクションでは、3 つの一般的な移行シナリオのスクリプトを提供します。

前提条件

開始する前に、以下を確認してください：

RDS インスタンスを管理する権限を持つ AWS アカウント
SQL Server データベース管理の基本的な理解

スクリプト 1: Amazon S3 を使用したボリューム間のデータベース移動

Amazon RDS for SQL Server は、rds_backup_database および rds_restore_database ストアドプロシージャを使用した、Amazon Simple Storage Service (Amazon S3) との間でネイティブバックアップとリストアをサポートしています。S3 からデータベースをリストアする場合、ターゲットデータベース名は RDS インスタンス内で一意である必要があります。同じ名前の既存のデータベースに直接リストアすることはできません。この制約のため、Amazon S3 からリストアされた新しいデータベースは異なる名前を持ち、以前のデータベース名にリネームする必要があります。アプリケーションは短時間の停止を伴って新しいデータベースに切り替える必要があることに注意してください。この方法は、アプリケーションの停止が許容でき、データベース全体を新しいボリュームに移動する必要がある場合に適しています。以前のデータベースは削除またはリネームできます。このデモでは、削除オプションを使用します。

-- Switch to master database for administrative operations
use master
Go

-- Create a new test database for S3 backup/restore demonstration
create database test_of_s3
Go

-- Create a native backup of the database and store it in S3
EXEC msdb.dbo.rds_backup_database
@source_db_name='test_of_s3',
@s3_arn_to_backup_to='arn:aws:s3:::amzn-s3-demo-bucket/test_of_s3.bak';

-- Restore database from S3 backup to specific volumes (H: for data, I: for log)
EXEC msdb.dbo.rds_restore_database
@restore_db_name='test_of_s3_restore_bucket_ok',
@s3_arn_to_restore_from='arn:aws:s3:::amzn-s3-demo-bucket/test_of_s3.bak',
@data_file_volume='H:',
@log_file_volume='I:';

-- Query to show physical file locations for databases matching 'test_of%' pattern
SELECT db_name(database_id) as DatabaseName, name, type_desc, physical_name FROM sys.master_files where name like 'test_of%';

DatabaseName	type_desc	physical_name
test_of_s3	ROWS	D:\rdsdbdata\DATA\test_of_s3.mdf
test_of_s3	LOG	D:\rdsdbdata\DATA\test_of_s3_log.ldf
test_of_s3_restore_bucket_ok	ROWS	H:\rdsdbdata\DATA\test_of_s3.mdf
test_of_s3_restore_bucket_ok	LOG	I:\rdsdbdata\DATA\test_of_s3.log.ldf

元のデータベースを削除するには、以下を実行します：

EXECUTE msdb.dbo.rds_drop_database N'test_of_s3'

新しくリストアしたデータベースをリネームするには、以下を実行します：

EXEC rdsadmin.dbo.rds_modify_db_name N'test_of_s3_restore_bucket_ok', N'test_of_s3'
GO

このアプローチは、高トラフィックのデータベースをより高パフォーマンスのボリュームに移動するなど、データベース全体を別のボリュームに再配置する場合に推奨されます。

スクリプト 2: クラスター化インデックスを使用したボリューム間のテーブル移動

この方法はオンラインで実行できますが、インデックスをアクティブに使用しているクエリに影響を与えます。このオプションを選択する場合は、業務時間外に実行することをお勧めします。

-- Switch to master database for creating new demo database
use master
Go

-- Create a new database for demonstrating index-based table movement
create database demo_sql
Go
Use demo_sql
Go

-- Create a test table
CREATE TABLE Test2 ( ID INT IDENTITY(1,1) PRIMARY KEY, RandomText VARCHAR(8000), RandomNumber INT, RandomDate DATETIME );

-- Insert approximately 100MB of random test data (13,000 rows)
DECLARE @i INT = 0;
WHILE @i < 13000
BEGIN
INSERT INTO Test2 (RandomText, RandomNumber, RandomDate) VALUES (
REPLICATE(CAST(NEWID() AS VARCHAR(36)), 220),
ABS(CHECKSUM(NEWID())),
DATEADD(DAY, ABS(CHECKSUM(NEWID())) % 3650, '2020-01-01')
);
SET @i = @i + 1;
END;

-- Drop the primary key constraint from Test2 table to remove clustered index
DECLARE @TableName NVARCHAR(128) = 'Test2'
DECLARE @SQL NVARCHAR(MAX) = ' '
SELECT @SQL = @SQL + 'ALTER TABLE [' + @TableName + '] DROP CONSTRAINT [' + kc.name + '];'
FROM sys.key_constraints kc
WHERE kc.parent_object_id = OBJECT_ID(@TableName)
AND kc.type = 'PK'
IF @SQL != ' '
EXEC sp_executesql @SQL

-- Add a new filegroup to the database for archive data
use demo_sql
Go
ALTER DATABASE demo_sql
ADD FILEGROUP ArchiveFileGroupdemo_sql;

-- Add a physical file to the new filegroup on H: drive
ALTER DATABASE demo_sql
ADD FILE (
NAME = 'Archive_Data',
FILENAME = 'H:\rdsdbdata\data\demo_sql_Data.ndf',
SIZE = 1GB,
FILEGROWTH = 100MB
) TO FILEGROUP ArchiveFileGroupdemo_sql;

-- Create a clustered index on the new filegroup to move table data
USE demo_sql
GO
CREATE UNIQUE CLUSTERED INDEX test_CID ON Test2(ID) ON ArchiveFileGroupdemo_sql

-- Query to show tables and their filegroup locations and you will see the table has been moved to the new file group
SELECT
SCHEMA_NAME(t.schema_id) AS SchemaName,
t.name AS TableName,
CASE
WHEN i.name IS NULL THEN 'HEAP (No Clustered Index)'
ELSE i.name
END AS IndexName,
CASE
WHEN i.type = 0 THEN 'Heap'
WHEN i.type = 1 THEN 'Clustered'
ELSE 'Other'
END AS IndexType,
COALESCE(fg.name, 'N/A') AS FileGroupName
FROM sys.tables t
LEFT JOIN sys.indexes i ON t.object_id = i.object_id AND i.type IN (0, 1) -- Heap or Clustered
LEFT JOIN sys.filegroups fg ON i.data_space_id = fg.data_space_id
WHERE t.is_ms_shipped = 0 -- User tables only
ORDER BY SchemaName, TableName;

スクリプト 3: H: ドライブと I: ドライブの特定のファイル場所に新しいデータベースを作成する

以下の T-SQL ステートメントは、個別の EBS ボリュームにまたがる明示的なファイル配置で新しいデータベースを作成します。データファイル (.mdf) を H: ドライブに、トランザクションログファイル (.ldf) を I: ドライブに配置します。この構成により、データとログの操作を独立したストレージボリュームに分離することで I/O パフォーマンスを向上させることができます。

CREATE DATABASE database_sql
ON (
NAME = 'database_sql_Data',
FILENAME = 'H:\rdsdbdata\data\database_sql.mdf',
SIZE = 100MB,
FILEGROWTH = 10MB
)
LOG ON (
NAME = 'database_sql_Log',
FILENAME = 'I:\rdsdbdata\data\database_sql_Log.ldf',
SIZE = 10MB,
FILEGROWTH = 10%
)

スクリプト 4: ボリューム間でのパーティションテーブルの移動

テーブルパーティショニングを使用しているデータベースでは、アクセスパターンに基づいてパーティションをボリューム間に分散できます。これにより、最近のパーティションを高パフォーマンスストレージに保持しながら、古いパーティションをコスト効率の良いボリュームに移動できます。このアプローチは大規模なテーブルに適しており、影響を最小限に抑えるために本番時間外にこれらの操作を実行することをお勧めします。

CREATE DATABASE Database_Amazon
GO

USE Database_Amazon
GO

ALTER DATABASE Database_Amazon
ADD FILEGROUP ArchiveFileGroup
GO

ALTER DATABASE Database_Amazon
ADD FILE (
  NAME = 'Archive_Data',
  FILENAME = 'H:\rdsdbdata\data\Archive_Data.ndf',
  SIZE = 1GB,
  FILEGROWTH = 100MB
) TO FILEGROUP ArchiveFileGroup
GO

CREATE PARTITION FUNCTION DatePartitionFunction (datetime2)
AS RANGE RIGHT FOR VALUES ('2024-01-01', '2025-01-01')
GO

CREATE PARTITION SCHEME DatePartitionScheme
AS PARTITION DatePartitionFunction
TO ([PRIMARY], [PRIMARY], ArchiveFileGroup)
GO

CREATE TABLE Orders (
  OrderDate datetime2 NOT NULL,
  OrderID int IDENTITY(1,1),
  CustomerID int,
  Amount decimal(10,2)
) ON DatePartitionScheme(OrderDate)
GO

INSERT INTO Orders (OrderDate, CustomerID, Amount) VALUES
('2023-06-15', 101, 100.00),
('2024-06-15', 102, 200.00),
('2025-06-15', 103, 300.00)
GO

SELECT
  p.partition_number,
  fg.name AS filegroup_name,
  p.rows AS row_count,
  rv.value AS boundary_value
FROM sys.partitions p
JOIN sys.allocation_units au ON p.partition_id = au.container_id
JOIN sys.filegroups fg ON au.data_space_id = fg.data_space_id
LEFT JOIN sys.partition_range_values rv ON p.partition_number = rv.boundary_id + 1
WHERE p.object_id = OBJECT_ID('Orders')
ORDER BY p.partition_number;

クリーンアップ

この記事に従ってテストリソースを作成した場合、継続的なストレージ料金を避けるために不要なボリュームを削除することを忘れないでください。

RDS コンソールまたは AWS Command Line Interface (AWS CLI) を通じてボリュームを削除できます。
RDS コンソール、AWS CLI、または RDS API を通じて RDS DB インスタンスを削除できます。

結論

この記事では、Amazon RDS for SQL Server の追加ストレージボリュームを使用して、ストレージ容量の拡張、一時ストレージの動的管理、パフォーマンスの向上、コストの削減を行う方法を学びました。異なる仕様を持つ複数のボリュームにデータを戦略的に分散することで、より柔軟でコスト効率の高いデータベースインフラストラクチャを構築できます。

Amazon RDS for SQL Server のストレージオプションの詳細については、Amazon RDS ドキュメントをご覧ください。データベース改善戦略の詳細については、Database Blog をご覧ください。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

Amazon Web Services ブログ