運用チームは、Amazon OpenSearch Service のドメインでアプリケーションログを 90 日間保持しています。ログは日付ごとのインデックスに書き込まれ、当日分は書き込みが続いています。直近 7 日分は運用チームが 1 日に何度も検索しますが、それより古い分は月次の報告と監査の照会でまれに読むだけです。ログは 1 日あたり約 200 GB 届き、保持している総量は 18 TB に達しています。ドメインは 3 つのアベイラビリティーゾーンに配置しています。 最もコスト効率よくこれらの要件を満たすために、ソリューションアーキテクトは何を推奨すべきですか。
書き込みが終わった分だけを安い層へ移し、検索が続く分と転送料の思い込みを切り分ける
日付ごとのインデックスを作成の翌日に UltraWarm へ移し、月次の報告もそこから読ませる。
UltraWarm へ移して保管の単価を下げるという方向は正しく、作成の翌日であれば書き込みは終わっているので移す操作自体は成立します。月次の報告をそこから読ませる運用もできます。
ただし UltraWarm は、めったに検索しないデータを安く置くための層です。作成の翌日に一律で移すと 1 日に何度も検索する直近 7 日分までホットのデータノードから外れ、検索のたびに遅い層を引くことになります。しかも 90 日ぶんが UltraWarm に居続けてより安いコールドストレージへ落とさないため、費用の面でも最安になりません。
ドメインを 1 つのアベイラビリティーゾーンだけの構成に変更し、ゾーン間のデータ転送の料金をなくす。
OpenSearch Service のドメインは配置するアベイラビリティーゾーンの数を選べるため、1 つに変更する操作自体は実在します。
ただしマルチ AZ のドメインではアベイラビリティーゾーン間の転送が課金されないため、削れる費用がありません。何も安くならないまま、ゾーン障害への耐性だけを手放すことになります。
古いインデックスのスナップショットを取得してドメインから削除し、照会のたびに復元する。
インデックスのスナップショットを取得してドメインから削除すれば、データノードが抱える量は確実に減ります。照会があったときに復元すれば内容も失われません。
ただしスナップショットのリポジトリと復元の手順を自分たちで持ち続けることになり、復元先もホットのデータノードなので照会のたびに単価の高い層の容量を使います。安く置いて必要なときだけ読むという同じ狙いは、ドメインの中の階層だけで実現できます。
直近 7 日を過ぎた日付のインデックスを UltraWarm へ、さらに古いものをコールドストレージへ移す。
UltraWarm とコールドストレージは、書き込みが終わったデータを安く保管するための層です。ログを日付ごとにローテーションしているので、7 日を過ぎたインデックスはすでに書き込みが終わっており、この前提を満たしたまま保管の単価を下げられます。
直近 7 日分はホットのデータノードに残るので 1 日に何度も走る検索の速さは変わらず、さらに古い分はコールドストレージへ送って読むときだけ戻せば済みます。これらの階層と Amazon S3 の間の転送も、コールドと UltraWarm の間の移動も課金されません。
UltraWarm を使う構成では、Amazon OpenSearch Service のストレージは 3 段です。
・ホット（データノード） — 書き込みと頻繁な検索を受け持つ層。
・UltraWarm — 書き込みが終わったデータ向けの、安価で大容量の層。検索はそのままできます。
・コールドストレージ — さらにまれにしか読まないデータを置く層。そのままでは検索できず、読むときは UltraWarm へ戻します。
移す条件は 2 つです。下の 2 段は書き込みが終わったデータ向けなので、書き込みが続いているインデックスは移せません。そのうえで頻繁に検索する期間の分はホットに残し、書き込みが終わって検索も減ったものから順に下の層へ送ります。ログは日付ごとにインデックスをローテーションしておくと、この 2 つの条件で切り分けられます。
なおゾーン間の転送も、階層と S3 の間の転送も課金されません。転送料を理由に可用性の構成を縮めるのは、耐性だけを失う判断です。
また OpenSearch 3.3 以降では、OpenSearch Optimized Instances (OI2) のウォーム層に書き込みもできる別の構成（多層ストレージ）も選べますが、この構成にはコールド層がありません。