Amazon FSx for OpenZFS ボリューム周りの使用をまとめて検証してみた
はじめに
みなさんこんにちは、クラウド事業本部コンサルティング部の浅野です。
Amazon FSx for OpenZFSでは、1つのファイルシステム内に複数のボリュームを作成できます。ボリュームを使うと、ファイルシステム内のストレージプールを論理的に分割して、マウントパス毎にストレージ容量クォータ（上限設定）やストレージ容量予約、圧縮タイプ、NFS exportsによるアクセス制御などを用途ごとに設定できるようになります。1つのファイルシステム上で複数のアプリケーションやチームのデータを分離して管理したい場合にはこれらを考慮して設計する必要があります。
本記事では、ボリュームの追加・削除操作を実際に行いながら、ストレージ容量クォータと容量予約サイズの設定動作や親子ボリュームの挙動をまとめて検証していきます。
ストレージ容量クォータとストレージ容量予約について
Amazon FSx OpenZFSでは、ファイルシステム全体のストレージ容量が以下のようなイメージで共有プールとして存在し、各ボリュームでは容量をそのプール内の空き容量から消費する構成になっています。
ストレージ容量クォータについて
各ボリュームはそのボリューム自身で使用できる最大容量の上限を「ストレージ容量クォータ」として設定することができ、以下の特徴があります。
- クォータを超えて書き込もうとするとエラーになる
- ユーザーやグループ単位で使用できるストレージ容量の制限を設定可能
- 設定すると使用最大容量が制限されるだけで、最低容量は確保されない（他のボリュームと共有プールを奪い合う）
-1を設定するとクォータなしに設定可能（ファイルシステム容量まで使える）- 子ボリュームは親のクォータを超えられない
- 子ボリュームの使用量は親のクォータ消費にカウントされる
例: vol1にストレージ容量クォータとして「10GiB」を設定した場合
ストレージ容量予約について
また、各ボリュームは共有プールの空き容量からそのボリューム専用に容量を予約することが可能で、予約した容量は他のボリュームから使用できません。
- 予約した容量は、そのボリュームが使っていなくても他のボリュームから使えない
- アプリケーションが「最低でもこの容量が必要」という場合に使う
0または-1を設定すると容量予約設定なし
例: vol1にストレージ容量予約として「10GiB」を設定した場合
ボリューム毎の容量クォータと容量予約についてまとめ
| 設定 | 挙動 |
|---|---|
| クォータのみ | 上限は決まるが、容量は保証されない（早い者勝ち） |
| 予約のみ | 最低容量は確保されるが、上限なし |
| 両方設定 | 最低容量を確保しつつ、上限も制限可能 |
| どちらもなし | 制限なし、プール全体を使える（早い者勝ち） |
構成
今回はボリュームに関する操作の検証用として以下の簡易構成でシステムを構築しました。
上記構成のネットワーク構成、EC2インスタンスの用意、FSxファイルシステムの準備までをCDKスタックにて用意しました。
CDKスタック
import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as fsx from 'aws-cdk-lib/aws-fsx';
import * as iam from 'aws-cdk-lib/aws-iam';
/**
* FSx for OpenZFS ボリューム追加・削除検証用スタック
*/
export class DemoFsxOpenzfsVolumeStack extends cdk.Stack {
constructor(scope: Construct, id: string, props?: cdk.StackProps) {
super(scope, id, props);
// VPC
const vpc = new ec2.Vpc(this, 'Vpc', {
maxAzs: 1,
natGateways: 0,
subnetConfiguration: [
{
cidrMask: 24,
name: 'Public',
subnetType: ec2.SubnetType.PUBLIC,
},
],
});
// EC2用セキュリティグループ
const ec2Sg = new ec2.SecurityGroup(this, 'Ec2Sg', {
vpc,
description: 'Security group for EC2 instance',
allowAllOutbound: true,
});
// FSx用セキュリティグループ
const fsxSg = new ec2.SecurityGroup(this, 'FsxSg', {
vpc,
description: 'Security group for FSx for OpenZFS',
allowAllOutbound: true,
});
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(2049), 'NFS Server');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcp(111), 'NFS RPC');
fsxSg.addIngressRule(ec2Sg, ec2.Port.tcpRange(20001, 20003), 'NFS Mount');
// FSx for OpenZFS ファイルシステム
const fileSystem = new fsx.CfnFileSystem(this, 'FileSystem', {
fileSystemType: 'OPENZFS',
subnetIds: [vpc.publicSubnets[0].subnetId],
securityGroupIds: [fsxSg.securityGroupId],
storageCapacity: 64,
openZfsConfiguration: {
deploymentType: 'SINGLE_AZ_1',
throughputCapacity: 64,
rootVolumeConfiguration: {
dataCompressionType: 'ZSTD',
nfsExports: [
{
clientConfigurations: [
{
clients: '*',
options: ['rw', 'crossmnt', 'no_root_squash'],
},
],
},
],
},
},
});
// EC2用IAMロール (SSM用)
const ec2Role = new iam.Role(this, 'Ec2Role', {
assumedBy: new iam.ServicePrincipal('ec2.amazonaws.com'),
managedPolicies: [
iam.ManagedPolicy.fromAwsManagedPolicyName('AmazonSSMManagedInstanceCore'),
],
});
// EC2インスタンス
const instance = new ec2.Instance(this, 'Instance', {
vpc,
vpcSubnets: {
subnetType: ec2.SubnetType.PUBLIC,
},
instanceType: ec2.InstanceType.of(ec2.InstanceClass.T3, ec2.InstanceSize.MICRO),
machineImage: ec2.MachineImage.latestAmazonLinux2023({
cpuType: ec2.AmazonLinuxCpuType.X86_64,
}),
securityGroup: ec2Sg,
role: ec2Role,
});
}
}
やってみた
それでは上記のCDKスタックをデプロイした状態で以下の確認項目を確認しながら実際に検証してみます。
| 確認項目 | |
|---|---|
| 1 | ボリューム追加とストレージ容量予約 |
| 2 | アクセスとストレージ容量クォータ制限 |
| 3 | 子ボリューム作成 |
| 4 | ボリューム更新 |
| 5 | ボリューム削除 |
CDKをデプロイした直後の状況は以下のようにファイルシステムが作成され、ルートボリュームのみ存在する状況です。
ファイルシステムのDNS名をコピーしておきます。
それでは、EC2内にSSM接続して「/fsx」フォルダにファイルシステムのルートボリュームをマウントします。
sudo mkdir -p /fsx
sudo mount -t nfs -o nfsvers=4.1 <上記でコピーしたFileSystemDnsName>:/fsx /fsx
# 確認
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 0 64G 0% /fsx
上記作業にてローカルフォルダの「/fsx」にFSx for OpenZFSの「/fsx」ボリュームをマウントしました。
1. ボリューム追加とストレージ容量予約
「vol1」として、ストレージ容量クォータ「10GiB」、ストレージ容量予約「5GiB」のボリュームを以下のCLIコマンドで作成します。
ルートボリュームのIDを使用する必要があるので適宜確認してください。
ROOT_VOLUME_ID=<RootVolumeId>
aws fsx create-volume \
--name vol1 \
--volume-type OPENZFS \
--open-zfs-configuration '{
"ParentVolumeId": "'$ROOT_VOLUME_ID'",
"StorageCapacityQuotaGiB": 10,
"StorageCapacityReservationGiB": 5,
"NfsExports": [{
"ClientConfigurations": [{
"Clients": "*",
"Options": ["rw", "crossmnt", "no_root_squash"]
}]
}]
}'
{
"Volume": {
"FileSystemId": "fs-03a3a1fd4776f6245",
"Lifecycle": "PENDING",
"Name": "vol1",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:************:volume/fs-03a3a1fd4776f6245/fsvol-07035eb0cd173bb05",
"VolumeId": "fsvol-07035eb0cd173bb05",
"VolumeType": "OPENZFS",
"OpenZFSConfiguration": {
"ParentVolumeId": "fsvol-0802cd11f4b6f9178",
"VolumePath": "/fsx/vol1",
"StorageCapacityReservationGiB": 5,
"StorageCapacityQuotaGiB": 10,
"RecordSizeKiB": 128,
"DataCompressionType": "NONE",
"CopyTagsToSnapshots": false,
"ReadOnly": false,
"NfsExports": [
{
"ClientConfigurations": [
{
"Clients": "*",
"Options": [
"rw",
"crossmnt",
"no_root_squash"
]
}
]
}
],
"UserAndGroupQuotas": [
{
"Type": "USER",
"Id": 0,
"StorageCapacityQuotaGiB": 0
},
{
"Type": "GROUP",
"Id": 0,
"StorageCapacityQuotaGiB": 0
}
]
}
}
}
コンソール上でも「vol1」が追加されていることが確認できました。
ここでストレージ容量予約として「5GiB」を設定したので、ルートボリュームがマウントされているEC2内に戻って使用可能な空き容量を以下のコマンドで確認してみます。
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx 59G 0 59G 0% /fsx
先ほどは「64GiB」でしたが、追加のボリューム「vol1」に容量予約サイズとして「5GiB」を指定しているため全体の空き容量が「59GiB」に減少したことが確認できました。
2. アクセスとストレージ容量クォータ制限
EC2内に接続し直し、先ほど追加した「vol1」ボリュームにアクセスできるか確認します。その後適当なファイルを書き込みしてみましょう
ls -la /fsx/vol1/
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 12 05:11 .
drwxrwxrwx. 3 root root 3 Jan 12 05:11 ..
以下のコマンドを実行して追加したボリューム「vol1」に適当なファイルを追加してみます。
# テキストファイル作成
echo "Test data for vol1" | sudo tee /fsx/vol1/test.txt
# 出力
est data for vol1
# 100MiBのダミーファイル作成
sudo dd if=/dev/zero of=/fsx/vol1/testfile bs=1M count=100
# 出力
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.321425 s, 326 MB/s
ls -la /fsx/vol1
# 出力
total 102422
drwxrwxrwx. 2 root root 4 Jan 12 05:24 .
drwxrwxrwx. 3 root root 3 Jan 12 05:11 ..
-rw-r--r--. 1 root root 19 Jan 12 05:24 test.txt
-rw-r--r--. 1 root root 104857600 Jan 12 05:24 testfile
上記にようにファイルの書き込みが可能なことが確認できました。
続いて、ストレージ容量クォータ制限の確認として設定している「10GiB」を超える書き込み(11GiB)でエラーが出ることを以下のコマンドで確認します。
sudo dd if=/dev/zero of=/fsx/vol1/large_file bs=1M count=11000
# 出力
dd: error writing '/fsx/vol1/large_file': Disk quota exceeded
10226+0 records in
10225+0 records out
10721689600 bytes (11 GB, 10 GiB) copied, 83.2349 s, 129 MB/s
上記のようにDisk quota exceededエラーが発生しファイルの書き込みに失敗したことが確認できました。
ただし、全くファイルが作成されないわけではなく、ファイル容量いっぱいまではファイルが作成されてしまうことに注意です。
df -h /fsx/vol1
# 出力 -
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx/vol1 11G 11G 0 100% /fsx/vol1
ls -la /fsx/vol1
# 出力
total 10494239
drwxrwxrwx. 2 root root 5 Jan 12 05:28 .
drwxrwxrwx. 3 root root 3 Jan 12 05:11 ..
-rw-r--r--. 1 root root 10641997824 Jan 12 05:29 large_file
-rw-r--r--. 1 root root 19 Jan 12 05:24 test.txt
-rw-r--r--. 1 root root 104857600 Jan 12 05:24 testfile
このようにlarge_fileが作成可能な容量にて作成されています。後の検証のためrm large_fileにて削除しておき、ボリュームを以下の状態に戻しておきました。
df -h /fsx/vol1
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx/vol1 10G 100M 10G 1% /fsx/vol1
sh-5.2$
3. 子ボリューム作成
ボリュームは階層構造を持つことができます。作成時にParentVolumeIdに親ボリュームのIDを指定することで、そのボリュームを親として子のボリュームを作成できます。子ボリュームは特徴として以下の制約を親ボリュームから継承します。
- 親のストレージ容量クォータを超えて使用できない
- 子ボリュームの使用量は親のクォータ消費にカウントされる
子ボリュームでも独自にストレージ容量クォータ、ストレージ容量予約サイズが指定可能ですが、親ボリュームの値を超えて設定するとどうなるか検証してみます。
- 親の容量クォータ（10GiB）を超える容量クォータ（15GiB）を設定して子ボリューム「vol1-child-test1」を作成を試みる
VOL1_ID=$(aws fsx describe-volumes \
--filters Name=file-system-id,Values=$FS_ID \
--query 'Volumes[?Name==`vol1`].VolumeId' \
--output text)
aws fsx create-volume \
--name vol1-child-test1 \
--volume-type OPENZFS \
--open-zfs-configuration '{
"ParentVolumeId": "'$VOL1_ID'",
"StorageCapacityQuotaGiB": 15,
"StorageCapacityReservationGiB": -1,
"NfsExports": [{
"ClientConfigurations": [{
"Clients": "*",
"Options": ["rw", "crossmnt", "no_root_squash"]
}]
}]
}'
An error occurred (BadRequest) when calling the CreateVolume operation: StorageCapacityQuotaGiB cannot be greater than the StorageCapacityQuotaGiB of the parent volume
親ボリュームのクォータサイズを超えて、子ボリュームのクォータサイズを指定するなと怒られました。
- 親の容量予約サイズ（5GiB）を超える容量予約サイズ（10GiB）で子ボリューム「vol1-child-test2」の作成を試みる
aws fsx create-volume \
--name vol1-child-test2 \
--volume-type OPENZFS \
--open-zfs-configuration '{
"ParentVolumeId": "'$VOL1_ID'",
"StorageCapacityQuotaGiB": -1,
"StorageCapacityReservationGiB": 10,
"NfsExports": [{
"ClientConfigurations": [{
"Clients": "*",
"Options": ["rw", "crossmnt", "no_root_squash"]
}]
}]
}'
An error occurred (BadRequest) when calling the CreateVolume operation: StorageCapacityReservationGiB cannot be greater than or equal to the parent volume's StorageCapacityQuotaGiB
こちらも同じように親ボリュームのストレージ予約容量を超えて、子ボリュームのストレージ予約容量は指定できませんでした。予想通りの結果ですね。
それではストレージ容量クォータとストレージ容量予約を指定せずに正常な子ボリュームである「vol1-child」を以下のコマンドで作成します。
aws fsx create-volume \
--name vol1-child \
--volume-type OPENZFS \
--open-zfs-configuration '{
"ParentVolumeId": "'$VOL1_ID'",
"StorageCapacityQuotaGiB": -1,
"StorageCapacityReservationGiB": -1,
"NfsExports": [{
"ClientConfigurations": [{
"Clients": "*",
"Options": ["rw", "crossmnt", "no_root_squash"]
}]
}]
}'
{
"Volume": {
"FileSystemId": "fs-03a3a1fd4776f6245",
"Lifecycle": "PENDING",
"Name": "vol1-child",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:************:volume/fs-03a3a1fd4776f6245/fsvol-09e6345275f0f4e0f",
"VolumeId": "fsvol-09e6345275f0f4e0f",
"VolumeType": "OPENZFS",
"OpenZFSConfiguration": {
"ParentVolumeId": "fsvol-07035eb0cd173bb05",
"VolumePath": "/fsx/vol1/vol1-child",
"RecordSizeKiB": 128,
"DataCompressionType": "NONE",
"CopyTagsToSnapshots": false,
"ReadOnly": false,
"NfsExports": [
{
"ClientConfigurations": [
{
"Clients": "*",
"Options": [
"rw",
"crossmnt",
"no_root_squash"
]
}
]
}
],
"UserAndGroupQuotas": [
{
"Type": "USER",
"Id": 0,
"StorageCapacityQuotaGiB": 0
},
{
"Type": "GROUP",
"Id": 0,
"StorageCapacityQuotaGiB": 0
}
]
}
}
}
コンソールでは以下のように子ボリュームの作成が確認できました。
それではEC2内から子ボリューム「vol1-child」にアクセスできることを確認します。
ls -la /fsx/vol1/vol1-child/
# 出力
total 1
drwxrwxrwx. 2 root root 2 Jan 12 06:05 .
drwxrwxrwx. 3 root root 5 Jan 12 06:05 ..
子ボリュームの使用量が親のクォータ消費にカウントされることを確認します。
# 子ボリュームに書き込み
sudo dd if=/dev/zero of=/fsx/vol1/vol1-child/testfile bs=1M count=500
# 出力
500+0 records in
500+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 4.5439 s, 115 MB/s
以下のように/fsx/vol1/vol1-childにファイルを追加すると/fsx/vol1全体の使用量が増えていることが確認できました。
# vol1全体の使用量が増えていることを確認
df -h /fsx/vol1
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx/vol1 9.6G 100M 9.5G 2% /fsx/vol1
最後に、子ボリュームにはストレージ容量クォータを設定していませんが、親ボリュームのストレージ容量クォータ（10GiB）を超える書き込みでエラーになることを確認します。
# 15GB相当サイズのファイルを作成してみる
sudo dd if=/dev/zero of=/fsx/vol1/vol1-child/large_file bs=1M count=15000
Add: error writing '/fsx/vol1/vol1-child/large_file': Disk quota exceeded
9751+0 records in
9750+0 records out
10223616000 bytes (10 GB, 9.5 GiB) copied, 105.454 s, 96.9 MB/s
このように子ボリュームでも親ボリュームのクォータサイズ(10GiB)を超えてファイルを書き込めないことが確認できました。
4. ボリューム更新
ボリュームのストレージ容量クォータや容量予約サイズは後から変更可能です。
検証として「vol1」のストレージ容量クォータを「10GiB→20GiB」へ、ストレージ容量予約を「5GiB→10GiB」に変更してみました。
aws fsx update-volume \
--volume-id $VOL1_ID \
--open-zfs-configuration '{
"StorageCapacityQuotaGiB": 20,
"StorageCapacityReservationGiB": 10
}'
{
"Volume": {
"CreationTime": "2026-01-12T14:11:24.370000+09:00",
"FileSystemId": "fs-03a3a1fd4776f6245",
"Lifecycle": "AVAILABLE",
"Name": "vol1",
"ResourceARN": "arn:aws:fsx:ap-northeast-1:************:volume/fs-03a3a1fd4776f6245/fsvol-07035eb0cd173bb05",
"VolumeId": "fsvol-07035eb0cd173bb05",
"VolumeType": "OPENZFS",
"AdministrativeActions": [
{
"AdministrativeActionType": "VOLUME_UPDATE",
"RequestTime": "2026-01-12T15:18:42.163000+09:00",
"Status": "PENDING",
"TargetVolumeValues": {
"OpenZFSConfiguration": {
"StorageCapacityReservationGiB": 10,
"StorageCapacityQuotaGiB": 20
}
}
}
],
"OpenZFSConfiguration": {
"ParentVolumeId": "fsvol-0802cd11f4b6f9178",
"VolumePath": "/fsx/vol1",
"StorageCapacityReservationGiB": 5,
"StorageCapacityQuotaGiB": 10,
"RecordSizeKiB": 128,
"DataCompressionType": "NONE",
"CopyTagsToSnapshots": false,
"ReadOnly": false,
"NfsExports": [
{
"ClientConfigurations": [
{
"Clients": "*",
"Options": [
"rw",
"crossmnt",
"no_root_squash"
]
}
]
}
],
"UserAndGroupQuotas": [
{
"Type": "USER",
"Id": 0,
"StorageCapacityQuotaGiB": 0
},
{
"Type": "GROUP",
"Id": 0,
"StorageCapacityQuotaGiB": 0
}
]
}
}
}
コンソールにて以下のように更新されていることが確認できました。
クォータ増加により、以前より多くのデータが書き込めることを確認します。
df -h /fsx/vol1
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx/vol1 20G 100M 20G 1% /fsx/vol1
sudo dd if=/dev/zero of=/fsx/vol1/testfile2 bs=1M count=15000
15000+0 records in
15000+0 records out
15728640000 bytes (16 GB, 15 GiB) copied, 152.434 s, 103 MB/s
上記にように、エラーなしで15GiBファイルを格納することができました。
5. ボリューム削除
最後にボリューム削除時の挙動について確認してみます。削除には以下の仕様があります。
- ルートボリュームは削除できない
- 削除するとそのボリュームに紐づく全データ、全スナップショットも削除される
- ボリューム削除によるダウンタイムはなし
では、子ボリュームが存在する親ボリュームを削除しようとするとどうなるのでしょうか？
親ボリュームである「vol1」を以下のコマンドで削除してみます。
aws fsx delete-volume --volume-id $VOL1_ID
An error occurred (BadRequest) when calling the DeleteVolume operation: The volume with VolumeId: fsvol-07035eb0cd173bb05 has child volumes. To delete the volume recursively, DELETE_CHILD_VOLUMES_AND_SNAPSHOTS must be set.
上記にように、先に親ボリュームに紐づいている子ボリュームを先に削除するか、DELETE_CHILD_VOLUMES_AND_SNAPSHOTSオプションをつけて一緒に削除するように設定してください。というエラーが出ました。先ほどのコマンドにオプションをつけて子ボリュームとスナップショットも一緒に削除してみます。
親ボリュームと子ボリュームとスナップショットも一緒に削除するコマンドを実行
aws fsx delete-volume \
--volume-id $VOL1_ID \
--open-zfs-configuration '{
"Options": ["DELETE_CHILD_VOLUMES_AND_SNAPSHOTS"]
}'
{
"VolumeId": "fsvol-07035eb0cd173bb05",
"Lifecycle": "DELETING"
}
コンソールからボリュームが削除されていることを確認
以下のようにEC2から「vol1」,「vol1-child」が見えなくなったことも確認できました。
ls -la /fsx/vol1/
# 出力
ls: cannot access '/fsx/vol1': No such file or directory
最後に削除後のルートボリュームの状況を再確認してみるとファイルシステム作成段階に戻っていることが確認できました。
df -h /fsx
# 出力
Filesystem Size Used Avail Use% Mounted on
fs-03a3a1fd4776f6245.fsx.ap-northeast-1.amazonaws.com:/fsx 64G 0 64G 0% /fsx
最後に
本記事では、Amazon FSx for OpenZFSのボリューム追加・削除操作を実際に行いながら、ストレージ容量クォータと容量予約サイズの設定動作や親子ボリュームの挙動を検証しました。
検証した内容は以下のとおりです。
- ボリューム追加時のストレージ容量予約により、共有プールから専用の容量が確保されることを確認
- ストレージ容量クォータを超える書き込みで
Disk quota exceededエラーが発生することを確認 - 子ボリュームは親ボリュームのクォータ・予約サイズを超えて設定できないことを確認
- 子ボリュームの使用量が親ボリュームのクォータ消費としてカウントされることを確認
- ボリュームの更新でクォータや予約サイズを後から変更できることを確認
- 親ボリューム削除時は子ボリュームを先に削除するか、
DELETE_CHILD_VOLUMES_AND_SNAPSHOTSオプションが必要なことを確認
FSx for OpenZFSのボリューム機能を活用することで、1つのファイルシステム上で複数のアプリケーションやチームのデータを論理的に分離しつつ、それぞれの用途に応じた容量制限を柔軟に設定できます。特にストレージ容量クォータと容量予約を組み合わせることで、「最低限必要な容量を確保しつつ、使いすぎも防止する」といった運用が可能になります。
この記事がどなたかの参考になれば幸いです。今回は以上です。
