# 19 – ストレージのコスト効率を高めるために SAP データの使用を最適化する
**SAP データの使用をどのように最適化すれば、ストレージおよびメモリ関連のコストを最小限に抑えられるでしょうか。** コストを考慮してデータベースストレージ、バックアップ、および補助ファイルシステムを設計し、ロケーション、保持、ハウスキーピング戦略を評価します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/design-principle-19.html)
# ベストプラクティス 19.1 – アクセスおよび保持の要件を理解する
データにどのようにアクセスしているか、データをどのように保持しているかを理解します。アクティブなデータ、ドキュメント管理システム、バックアップを考慮に入れます。
**提案 19.1.1 – SAP システムにある異なるタイプのビジネスデータを分類する**
異なるタイプのデータとデータへのアクセス頻度 (データの温度) をビジネスの視点から分類すれば、SAP システムのデータをアーカイブまたはオフロードする機会を特定し、コストを最適化することができます。
以下は、SAP システムで一般的なデータタイプです。
+ リファレンス — 値が頻繁には変化しないデータ (都市、国、換算レートなど)
+ SAP マスターデータ — 値がほとんど変化しないデータ (SAP カスタマーマスター、製品など)
+ 監査 — 監査目的で保管されるデータ (変更ログなど)
+ 取引 — 日常業務の中で作成されるデータ (販売伝票など)
+ 分析 — 分析や意思決定のために作成されるデータ (月次売上レポートなど)
データの温度を次のように分類します。
+ ホット — 頻繁にアクセスするデータ
+ ウォーム — あまり頻繁にアクセスしないデータ
+ コールド — たまにしかアクセスしないデータ
保持の要件を次のように分類します。
+ 災害対策 (DR) 目的で保持する
+ 参照目的で保持する
+ コンプライアンスまたは監査目的で保持する
# ベストプラクティス 19.2 – 定期的なハウスキーピングを通じて不要なデータを削除する
定期的にハウスキーピングと再編成を行ってデータベースのサイズや他のファイルシステムの使用を最小限に抑えれば、データのフットプリントが小さくなり、コストが削減できます。
**提案 19.2.1 – SAP 技術テーブルのサイジングを確認し、定期的にハウスキーピングを実施する**
SAP は、技術テーブルのデータ管理について包括的なガイダンスを提供しています。これらのテーブルの成長を特定し、それに対処すれば、ストレージとコンピューティングのコストを削減できます。これは、特にデータベースのサイズとメモリの要件が直接的に関連している SAP HANA インスタンスに当てはまります。
+ SAP Note: [2388483 - How-To: Data Management for Technical Tables (ハウツー: 技術テーブルのデータ管理)](https://launchpad.support.sap.com/#/notes/2388483) [SAP ポータルへのアクセス権が必要]
参照されている「最大のテーブル」の SQL ステートメントを使用して同等のテーブルサイズ、特に Basis テーブルとしてマークされているテーブルのサイズを調べます。確立された SAP カスタマーによくある例は、完了した SAP ワークフロー項目の多くが削除可能またはアーカイブ可能であるケースです。移行の前にハウスキーピングを実施することは、タイムラインやパフォーマンスの改善にもつながります。SAP HANA を使用している場合は、‘/SDF/HDB\$1SIZING’ でクリーンアップの詳細と予想ディスク要件が取得できます。
**提案 19.2.2 – ログ、トレース、インターフェイスファイル、バックアップの自動または定期クリーンアップを通じてファイルシステムの成長を制御する**
ストレージコストは使用状況によって増減するため、障害分析に不要でありながらコストの増加を助長しているファイルのコピーやバックアップをなくし、基礎の使用料を最適化する必要があります。
+ SAP Note: [2399996 - How-To: Configuring automatic SAP HANA Cleanup with SAP HANACleaner (ハウツー: SAP HANACleaner を使って SAP HANA 自動クリーンアップを設定する)](https://launchpad.support.sap.com/#/notes/2399996) [SAP ポータルへのアクセス権が必要]
# ベストプラクティス 19.3 – 圧縮、再編成、再利用戦略を使用する
SAP がサポートしているデータベースには、スペースを再利用するためのメカニズムが備わっています。メモリまたは EBS ボリュームの拡張に関連するコストの増加を最小限に抑えるため、これらのメカニズムを定期メンテナンス作業に含める必要があります。
**提案 19.3.1 – データ圧縮を使用する**
圧縮は、SAP HANA のデフォルト特性の 1 つです。他のデータベースで圧縮を使用するには追加のライセンスが必要な場合がありますが、コスト面とパフォーマンス面でメリットがあるため、検討すべき手段です。以下のドキュメントは、各種データベースのための出発点ですが、追加情報を記載した SAP およびデータベースドキュメントに言及しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-19-3.html)
**提案 19.3.2 – データベースの再編成操作と再利用操作を使用する**
自然な使用やアーカイブおよびクリーンアップ処理によってデータベース内に生じた未使用のスペースは、再編成または再利用操作を行わないと実際の節約につながらない場合があります。定期的にスペースを再利用すれば、全体的な成長を抑え、ストレージまたはメモリを追加する必要性を減らすことができます。以下のドキュメントは、各種データベースのための出発点ですが、SAP およびデータベースドキュメントに言及しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/sap-lens/best-practice-19-3.html)
# ベストプラクティス 19.4 – バックアップ戦略に改善の余地がないか確認する
AWS で SAP を実行する場合は、バックアップおよび保持のアプローチを評価して、ロケーション、保持、復旧に関連するコストを最適化する必要があります。
**提案 19.4.1 – バックアップのロケーションを評価する**
Amazon S3 は、低コストで耐久性が高く、ストレージクラスのオプションが用意されているため、SAP システムのバックアップに適した長期ストレージソリューションです。Amazon EBS ボリューム上のデータを Amazon S3 にコピーするには、特定時点のスナップショット、統合データベースツール、または direct API コールを使用します。
スナップショットは、 *増分* バックアップです。つまり、最後にスナップショットを作成した後で変更されたデバイス上のブロックのみが保存されます。データが重複しないため、作成にかかる時間が短く、ストレージコストが節約できます。
データベースのバックアップソリューションは、データベースの状態を把握して一貫性を維持する必要があります。AWS では、Amazon S3 と直接統合できる SAP HANA バックアップソリューション (AWS Backint for SAP HANA) を追加コストなしで提供しています。SAP 対応の他のデータベースについては、データベースベンダーまたはサードパーティーが Amazon S3 へのバックアップをサポートするバックアップツールを提供しています。
+ SAP ドキュメント: [Featured backup solutions (注目のバックアップソリューション)](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=backup)
特別な要件またはステージングエリアについては、まず Amazon EBS にバックアップしなければならない場合があります。そのようなユースケースでは、低コストの HDD ボリュームである `ST1` ボリュームタイプを使用すると、バックアップに適したスループットおよびパフォーマンス特性が得られます。また、 `ST1` の使用により、SAP データベースをディスクにバックアップする必要がある場合のストレージコストを抑えることができます。
+ AWS ドキュメント: [Amazon EBS ボリュームのタイプ](https://aws.amazon.com/ebs/features/#Amazon_EBS_volume_types)
バックアップに Amazon EFS を使用する場合は、EFS-Infrequent Access を検討してください。このストレージクラスでは、日常的にアクセスする必要のないファイルのストレージコストが削減できます。Amazon EFS One Zone-Infrequent Access は、データが 1 つのアベイラビリティーゾーンにのみ存在するため、バックアップには推奨されません。
**提案 19.4.2 – 標準バックアップの保持ポリシーを確認し、実施する**
コストを制御するためには、ビジネス要件に沿った保持ポリシーを実施する必要があります。Amazon S3 は、1 GB あたりのコスト、最短ストレージ期間の変更、(該当する場合は) 取得料金といった特性を備えた、異なるユースケース用の広範なストレージクラスを提供しています。バックアップの保持およびアクセス要件を理解することで、要件を満たすストレージクラスはどれかが特定しやすくなります。
S3 Lifecycle ポリシーを使用すれば、アプリケーションに変更を加えることなく自動的に別のストレージクラスに移転できます。例えば保持期間の短いバックアップであれば、最小ストレージ期間料金および取得料金が設定されている S3-IA や S3 Glacier よりも、S3 Standard の方が適しているでしょう。監査目的の月次バックアップのように保持期間の長いバックアップには、期間の長さに応じて S3-IA または S3 Glacier が適しています。
+ AWS ドキュメント: [Amazon S3 のストレージクラス](https://aws.amazon.com/s3/storage-classes)
+ AWS サービス: [Amazon Data Lifecycle Manager](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/snapshot-lifecycle.html)
+ AWS ドキュメント: [Amazon EFS ライフサイクルの管理](https://docs.aws.amazon.com/efs/latest/ug/lifecycle-management-efs.html)
+ AWS サービス: [AWS Backup](https://aws.amazon.com/backup)
**提案 19.4.3 – アドホックバックアップの戦略を作成する**
システムまたは関連ファイルシステムのアドホックバックアップが必要な場合があります。アドホックバックアップは、変更の前、または特定の時点におけるシステムの状態を示すものとして作成します。アドホックバックアップは、標準の保持期間とは合わない可能性があるため、削除を含めたストレージの使用およびライフサイクルポリシーがバックアップの個々の要件にとって最もコスト効率の良いものとなるように、個別のスケジュールまたはプロセスを使う必要があります。
**提案 19.4.4 – バックアップのセットアップを復旧アプローチに照らし合わせてみる**
バックアップは、システムを過去のある時点の状態に戻し、障害シナリオから守るために使用します。バックアップストレージを堅牢に、しかし過剰にならない程度に使用して高いコスト効率を維持するには、復旧アプローチを見直す必要があります。古い、より詳細なバックアップについて、当然のように課されていた要件を検証してみましょう。これらの古いバックアップが、復旧の際に必要となるかどうかを特定します。
例えば、データベースとファイルシステム両方のバックアップを使用するのは、有効な戦略です。しかし、復旧の主要なメカニズムがデータベース復元ツールの使用である場合は、一部のボリュームのスナップショットバックアップについて保持期間を短縮したり削除したりすることで、コストを最適化できます。
+ AWS ドキュメント: [Amazon EBS スナップショット](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html)
+ AWS ドキュメント: [AWS Trusted Advisor ベストプラクティスチェックリスト](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/best-practice-checklist/)
# ベストプラクティス 19.5 – ライブデータの階層化オプションを検討する
SAP HANA を使った場合のコンピューティングコストは、主に必要なメモリの量によって決まります。そのため、データのオフロードおよび階層化オプションを使用すれば、コンピューティングコストを削減できます。他のデータベースにも階層化オプションはありますが、ここでは特に取り上げません。利用可能なオプションを理解するには、データベースプロバイダーにご相談ください。
**提案 19.5.1 – SAP HANA OLAP ベースのワークロードについて動的階層化、拡張ノード、ニアラインストレージ (NLS) を評価する**
SAP HANA 動的階層化は、SAP HANA データベースでの履歴データの管理を可能にするオプションのアドオンです。動的階層化の目的は、頻繁にはアクセスされないデータの管理用に SAP HANA メモリに (SAP HANA のインメモリストアとは対照的な) ディスク中心の列指向ストアを加えることです。動的階層化は、ネイティブの SAP HANA ユースケースのみに使用でき、Business Warehouse (BW) on HANA や BW/4 HANA ユースケースには使用できません。
SAP HANA 拡張ノードは、ウォームデータの保存専用にセットアップされ、予約された特殊目的の SAP HANA ワーカーノードです。SAP HANA 拡張ノードを使うと、SAP ビジネスウェアハウス (BW) またはネイティブの SAP HANA 分析ユースケースのためのウォームデータが保存できます。SAP HANA 拡張ノードに保存できるデータの総量は、拡張ノードの合計メモリの 1 倍から 2 倍です。
SAP BW ニアラインストレージ (NLS) と SAP IQ を使うと、BW on HANA または BW/4 HANA データベースの外にコールドデータを保存できます。NLS が HANA データベースのコールドデータを SAP IQ Server 上のストレージに移動させます。
+ AWS ドキュメント: [SAP Data Tiering (SAP データ階層化)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**提案 19.5.2 – OLTP ベースのワークロードについて Data Aging と SAP HANA Native Storage Extension (NSE) を評価する**
Data Aging は、アクセス頻度の低いデータをディスク領域に保存することで SAP HANA メモリに空き容量を作ります。
+ AWS ドキュメント: [SAP Data Tiering (SAP データ階層化)](https://docs.aws.amazon.com/sap/latest/sap-hana/sap-data-tiering.html)
**提案 19.5.3 – 大量の分析データへのデータレイクの使用を検討する**
SAP および SAP 以外のデータを分析する場合、S3 ベースのデータレイクをコスト効率の良いデータストレージオプションとして使用できます。
+ SAP on AWS ブログ: [Building data lakes with SAP on AWS (SAP on AWS を使ったデータレイクの構築)](https://aws.amazon.com/blogs/awsforsap/building-data-lakes-with-sap-on-aws/)
# ベストプラクティス 19.6 – アーカイブおよびオフロードオプションを評価する
アクセス頻度の低いデータをアーカイブするオプション、またはラージオブジェクトをニアラインストレージにオフロードするオプションを検討して、インフラストラクチャおよびバックアップのコストを削減しましょう。
**提案 19.6.1 – アクセス頻度の低いデータで構成されたラージテーブルのアーカイブを実施する**
特に SAP HANA データベースでは、アーカイブ戦略を通じてデータベースの成長を管理するとコスト上のメリットがあります。
+ SAP ドキュメント: [Data Archiving (データアーカイブ)](https://help.sap.com/viewer/6c8d90ed795242279e9103a8acad9cbe/LATEST)
**提案 19.6.2 – Amazon S3 を宛先として使えるアーカイブツールを評価する**
Amazon S3 は、可用性と耐久性の高い設計で、コスト効率の良い広範なストレージクラスを提供します。そのため、総保有コスト (TCO) を最小限に抑えた SAP アーカイブデータの保存に最適です。
+ AWS ドキュメント: [Amazon S3 のストレージクラス](https://aws.amazon.com/s3/storage-classes)
+ SAP ドキュメント: [SAP Certified Archiving Solutions (SAP 認定アーカイブソリューション)](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?filters=v:296)
**提案 19.6.3 – ラージオブジェクトにデータ管理システムを使用する**
請求書や画像などのラージオブジェクトについて、オフロードしてデータを SAP データベースの外で管理する場合のオプションとコストメリットを理解しましょう。データへのアクセスに関するビジネス要件、実装の手間、継続的な管理の複雑さを検討します。
ラージオブジェクトはデータベースのサイズを大きくし、リソースおよびバックアップのコストを増やします。データ管理システムのオプションが、低コストのストレージソリューションを提供する可能性があります。
+ SAP ドキュメント: [SAP Document Management (SAP ドキュメント管理)](https://help.sap.com/viewer/0f3e26f224d9419688b3d25d7c2e46fe/LATEST/en-US/4af6e75227db9972e10000000a4450e5.html)
+ SAP ドキュメント: [Search for Certified ILM Solutions (認定 ILM ソリューションを見つける)](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?search=BC-ILM)