OSS を使用する場合、ビジネスデータの変更に基づいてストレージタイプを適切に計画し、サブスクリプションと従量課金戦略を利用することで、コストを効果的に削減できます。
使用上の注意
バケット容量の増加が予想どおりか確認する
バケットにデータを保存する場合、ストレージ容量とストレージタイプに基づいてストレージ料金が請求されます。
より詳細なコスト情報が必要な場合は、アカウントレベルで OSS の使用状況を定期的に確認し、CSV 使用状況の詳細をエクスポートし、現在のアカウントのバケットごとのストレージ容量データを表示して、ストレージ容量の増加が予想どおりか判断できます。具体的な手順については、「アカウントレベルでの使用状況のクエリ」をご参照ください。
ストレージ容量の増加が異常な場合は、ACL を非公開に変更する、またはバケットポリシーを構成するなどの方法を検討して、他のユーザーによる OSS リソースに対する不正な操作を防止できます。たとえば、予期しない多くのオブジェクトがアップロードされてストレージ容量が急増したり、オブジェクトへの悪意のあるアクセスによって外部ネットワークトラフィックコストが高くなったりするのを防ぎます。詳細については、「アカウントパスワードの漏洩による不正アクセスのリスクを軽減する」をご参照ください。
バケット所有者のインターネット経由のアウトバウンドトラフィックとデータ取得容量のコストを削減する
バケット所有者が他のユーザーにインターネット経由でバケット内のデータへのアクセスを承認し、リクエスト元にインターネット経由のアウトバウンドトラフィックと低頻度アクセスデータの読み取り容量料金を支払ってもらいたいとします。この場合、バケット所有者は [リクエスト元支払い] モードを有効にできます。具体的な操作については、「リクエスト元支払いモードを有効にする」をご参照ください。
送信データ転送プランは、リクエスト元支払いモードが有効になった後、リクエスト元がインターネット経由で OSS からクライアントにデータをダウンロードするときに発生するインターネット経由のアウトバウンドトラフィック料金を相殺するために使用することはできません。このモードでは、アウトバウンドトラフィック料金は実際の使用状況に基づいてのみ請求されます。
ライフサイクルルールを構成する
OSS コストをより効果的に管理および削減するには、ライフサイクル管理ポリシーを最大限に活用してコスト効率を最大化することをお勧めします。
データアクセス頻度と応答時間に基づいてストレージタイプを変換する
データセットへのアクセス頻度の低下、または即時データ取得の要件の低下が確認された場合は、データアクセス性能に影響を与えることなく、データのストレージタイプをより費用対効果の高いストレージタイプに自動的に転送するように、データのライフサイクルルールを適切に設定できます。
選択の基準 | シナリオの説明 | データアクセス頻度 |
標準 | 頻繁な低レイテンシアクセスが必要なホットデータの場合。 | ファイルあたり月に 1 回以上 |
IA | アクセス頻度は低いものの、即時取得が必要なウォームデータの場合。 | ファイルあたり月に 1 回未満 |
アーカイブ | 長期間保存する必要があり、アクセスされる可能性は極めて低いが、アクセスされた場合は迅速に取得する必要があるコールドデータに適しています。復元時間は約 1 分です。 長期間の保存が必要で、アクセスされる可能性はほぼゼロだが、アクセスされた場合は迅速な取得が必要なコールドデータに適しています。通常、1 分以内に復元されます。 | ファイルあたり 90 日に 1 回未満 |
データストレージタイプをアーカイブストレージに設定し、アーカイブオブジェクトのリアルタイムアクセスを有効にしていない場合、データをリアルタイムでアクセスすることはできず、アクセスする前にデータを復元する必要があります。
プレフィックスまたはタグを使用してオブジェクトをフィルタリングすることにより、さまざまなデータ特性と使用頻度に基づいて、特定のデータのライフサイクルルールを構成できます。アクセス頻度の低いコールドデータの場合は、より費用対効果の高いアーカイブストレージに自動的に移行できます。アクセス頻度の高いホットデータの場合は、読み取り速度を上げるために標準ストレージタイプに保存できます。これは、ストレージコストの最適化に役立つだけでなく、データアクセス効率も向上させます。
ストレージコストの計算方法とニーズに基づいて最適なストレージタイプを選択する方法をより深く理解するために、以下の例を参考にしてください。
オブジェクトの以前のバージョンをクリーンアップする
バケットのバージョニングを有効にすると、バケットで上書きまたは削除されたオブジェクトは以前のバージョンとして保存されます。バケットに多くの履歴バージョンが蓄積されている場合は、ライフサイクルルールを組み合わせて不要な履歴バージョンを削除することで、ストレージコストを削減できます。
提案
指定日数に達したオブジェクトを自動的に削除するようにライフサイクルルールを構成することをお勧めします。
上記の構成例では、OSS は最終変更時刻から 200 日以上経過したオブジェクトの以前のバージョンを自動的に削除します。具体的な手順については、「最終変更時刻に基づくライフサイクルルール」をご参照ください。
期限切れのフラグメントをクリーンアップすることでストレージコストを削減する
マルチパートアップロード後に CompleteMultipartUpload 操作を呼び出さない場合、これらのパートは長期間バケットに保存され、ストレージ容量を占有し、ストレージ料金が発生します。
提案
指定日数後または指定日にフラグメントを自動的に削除するようにライフサイクルルールを構成することをお勧めします。
上記の構成例では、OSS は 2 日以上前に生成されたフラグメントを自動的に削除します。具体的な手順については、「最終変更時刻に基づくライフサイクルルール」をご参照ください。