Amazon ElastiCache Well-Architected レンズのコスト最適化の柱

CCoE は、次のようなカテゴリデータにおける主要な ElastiCache の使用状況について、定期的に (毎月) 更新されるコストメトリクスを特定、定義、公開する必要があります。

CCoE は、組織内のソフトウェアエンジニアリング、データ管理、製品チーム、財務チーム、リーダーシップチームからの非独占的な代表者による部門横断チームで構成されています。

タグを使用してリソースを整理し、コスト配分タグを使用して AWS コストを詳細レベルで追跡します。コスト配分タグを有効にすると、 はコスト配分タグ AWS を使用してコスト配分レポートのリソースコストを整理し、 AWS コストの分類と追跡を容易にします。 AWS は、 AWS 生成されたタグとユーザー定義タグの 2 種類のコスト配分タグを提供します。 は、生成されたタグ AWS を定義、作成、適用 AWS し、ユーザー定義タグを定義、作成、適用します。Cost Management またはコスト配分レポートで使用するには、事前に両方のタイプのタグを別々にアクティブ化しておく必要があります。

コスト配分タグを使用して、独自のコスト構造を反映するように AWS 請求書を整理します。Amazon ElastiCache でリソースにコスト配分タグを追加する場合、リソースのタグ値に基づいて請求書の費用をグループ化してコストを追跡できます。さらに細かくコストを追跡するには、タグを組み合わせる必要があります。

ビジネスメトリクスだけでなく、レイテンシーなどの運用メトリクスも検討してください。ビジネスモデルのどの概念がロールに関係なく理解できるでしょうか。メトリクスは、組織内のできるだけ多くのロールが理解できる必要があります。

例 - 同時提供ユーザー数、オペレーションとユーザーごとの最大レイテンシーと平均レイテンシー、ユーザーエンゲージメントスコア、週あたりのユーザー戻り率、ユーザーあたりのセッション時間、離脱率、キャッシュヒットレート、追跡しているキー

ソリューションエコシステム全体を理解すると、ElastiCache はクライアントから API Gateway、Redshift、QuickSight まで、レポートツール ( など) のテクノロジーセットに含まれる AWS サービスのフルエコシステムの一部になる傾向があります。

クライアント、接続、セキュリティ、インメモリオペレーション、ストレージ、リソース自動化、データアクセス、管理など、ソリューションのコンポーネントをアーキテクチャ図にマッピングします。各レイヤーはソリューション全体につながり、独自のニーズや機能を備えているため、全体的なコストの管理に追加したり、役立てることができます。

図には、コンピューティング、ネットワーク、ストレージ、ライフサイクルポリシー、メトリクス収集のほか、アプリケーションの運用上および機能上の ElastiCache 要素の使用を含める必要があります。

ワークロードの要件は時間の経過とともに変化する可能性が高いため、ワークロードコスト管理を積極的に進めるためには、基礎となるコンポーネントと主要な機能目標についての理解を引き続き維持し、文書化することが不可欠です。

ElastiCache の効果的なコスト管理戦略を立てるには、可視性、説明責任、優先順位付け、リソースに対するリーダーシップのサポートが不可欠です。

ElastiCache では、ホストレベルのメトリクス（たとえば、CPU 使用率など）とキャッシュエンジンソフトウェアに固有のメトリクス（たとえば、キャッシュの取得やキャッシュの損失など）の両方が提供されます。これらのメトリクスは 60 秒間隔で各キャッシュノードに対して測定およびパブリッシュされます。

ElastiCache のパフォーマンスメトリクス (CPUUtilization、 EngineUtilization、SwapUsage、CurrConnections、Evictions) から、スケールアップ/ダウン (より大きな/小さなキャッシュノードタイプを使用) またはスケールイン/アウト (シャードの増加/減少) する必要性を示すことがあります。スケーリングに関する意思決定のコストへの影響を理解するには、追加コストと、アプリケーションパフォーマンスのしきい値を満たすために必要な最小および最大時間を推定するプレイブックマトリクスを作成します。

ElastiCache では、バックアップは耐久性に優れたストレージを提供する Amazon S3 に保存されます。障害からの復旧能力に関連するコストへの影響を理解する必要があります。

保存制限を過ぎたバックアップファイルを削除する自動バックアップを有効にします。

リザーブドインスタンスの要件を推定するのに十分なデータを収集するまで、オンデマンドノードを使用して ElastiCache クラスターを運用する必要がある場合があります。ニーズを満たすために必要なリソースを計画して文書化し、インスタンスタイプ (オンデマンドとリザーブド) で予想コストを比較します。

利用可能な新しいキャッシュノードタイプを定期的に評価し、コストと運用メトリクスの観点から、インスタンスフリートを新しいキャッシュノードタイプに移行することが理にかなっているかどうかを評価します。

ElastiCache for Valkey または Redis OSS クラスターでのみ使用できます。

データ階層化をサポートしているインスタンスタイプは限られています。

Redis OSS 以降の ElastiCache バージョン 6.2 のみがサポートされています

大きなアイテムは SSD にスワップアウトされません。128 MiB を超えるオブジェクトはメモリに保持されます。

データ階層化インスタンスは、データセット全体のごく一部にアクセスすることが多いものの、残りのデータへの高速アクセスが必要なワークロードに最適です。つまり、ホットデータとウォームデータの比率は約 20:80 です。

オブジェクトのアイドル時間をクラスターレベルで追跡する機能を開発します。

優れた選択肢としては、500 GB を超えるデータを扱う大規模な実装を行うことです。

使用頻度の低いオブジェクトはローカル SSD にスワップアウトされるため、アクセス時に多少のパフォーマンスコストが発生します。アプリケーションが応答時間に敏感な場合は、ワークロードへの影響をテストしてください。

主にサイズが 128 MiB を超える大きなオブジェクトを格納するキャッシュには適していません。

要件を十分に理解するまで、非データ階層化インスタンスを使用して ElastiCache クラスターを運用する必要がある場合があります。

ElastiCache クラスターのデータ使用パターンを分析します。

オブジェクトのアイドル時間を定期的に収集する自動ジョブを作成します。

オブジェクトの大部分 (約 80%) がワークロードに適していると思われる期間アイドル状態になっていることに気付いた場合は、その結果を文書化し、データ階層化をサポートするインスタンスにクラスターを移行することを提案します。

利用可能な新しいキャッシュノードタイプを定期的に評価し、コストと運用メトリクスの観点から、インスタンスフリートを新しいキャッシュノードタイプに移行することが理にかなっているかどうかを評価します。