Amazon ElastiCache Well-Architected レンズコスト最適化の柱 - Amazon ElastiCache
COST 1: リソースに関連するコストをどのように特定して追跡しますか ElastiCache？ 作成したリソースをユーザーが作成、管理、廃棄できるようにするメカニズムをどのように開発しますか。COST 2: ElastiCache リソースに関連するコストを最適化するために、継続的モニタリングツールをどのように使用しますか？COST 3: データ階層化をサポートするインスタンスタイプを使用する必要がありますか？ データ階層化のメリットは何か。データ階層化インスタンスを使用すべきでないのはどのような場合か。

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

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

コスト最適化の柱は、不必要なコストを回避することに焦点を当てています。主なトピックには、資金の用途の把握と管理、最適なノードタイプの選択 (ワークロードのニーズに基づくデータ階層化をサポートするインスタンスの使用)、適切な数のリソースタイプ (リードレプリカの数)、経時的な支出の分析、浪費することなくビジネスニーズを満たすためのスケーリングなどがあります。

COST 1: リソースに関連するコストをどのように特定して追跡しますか ElastiCache？ 作成したリソースをユーザーが作成、管理、廃棄できるようにするメカニズムをどのように開発しますか。

質問レベルの紹介: コストメトリクスを把握するには、ソフトウェアエンジニアリング、データ管理、製品所有者、財務、リーダーシップなど、複数のチームの参加とコラボレーションが必要です。主なコスト要因を特定するには、すべての関係者がサービスの利用管理手段とコスト管理のトレードオフを把握する必要があり、多くの場合、それがコスト最適化の取り組みの成功と失敗を大きく左右します。開発から本番稼働、廃止まで作成されたリソースを追跡するためのプロセスとツールを確実に準備しておくと、 に関連するコストを管理するのに役立ちますElastiCache。

質問レベルの利点: ワークロードに関連するすべてのコストを継続的に追跡するには、 をコンポーネントの 1 つ ElastiCache として含むアーキテクチャを深く理解する必要があります。さらに、使用状況を収集して予算と比較するためのコスト管理計画を立てておく必要があります。

  • 〔必須] クラウドセンターオブエクセレンス () を設立憲章の 1 つでインスティテュートし、組織のElastiCache 使用状況に関するメトリクスを定義、追跡、および実行します。CCoEと 関数CCoEが存在する場合は、 に関連するコストを読み取って追跡する方法を理解している必要があります ElastiCache。リソースが作成されたら、IAMロールとポリシーを使用して、特定のチームやグループのみがリソースをインスタンス化できることを検証します。これにより、コストがビジネスの成果と結びつき、コストの観点から明確な説明責任が確立されます。

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

      1. 使用されるノードの種類とその属性: 標準インスタンスとメモリ最適化インスタンス、オンデマンドインスタンスとリザーブドインスタンス、リージョンとアベイラビリティゾーン

      2. 環境の種類: 無料、開発、テスト、本番

      3. バックアップストレージと保存戦略

      4. リージョン内およびリージョン間のデータ転送

      5. Amazon Outposts で実行されているインスタンス

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

    [リソース]:

  • [必須] コスト配分タグを使用すると、コストを低レベルの粒度で追跡できます。 AWS コスト管理を使用して、 AWS コストと使用量を経時的に視覚化、理解、管理します。

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

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

    [リソース]:

  • 〔最良] 組織全体に到達するメトリクスに ElastiCache コストを関連付けます。

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

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

    [リソース]:

  • 〔良い] up-to-dateを使用するワークロード全体のメトリクスとコストに関するアーキテクチャと運用上の可視性を維持します ElastiCache。

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

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

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

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

    5. 可視性、説明責任、優先順位付け、リソースに対するエグゼクティブサポートは、 の効果的なコスト管理戦略を立てる上で不可欠です ElastiCache。

COST 2: ElastiCache リソースに関連するコストを最適化するために、継続的モニタリングツールをどのように使用しますか？

質問レベルの紹介: ElastiCache コストとアプリケーションのパフォーマンスメトリクスの適切なバランスを図る必要があります。Amazon CloudWatch は、 ElastiCache リソースがニーズに対して過剰または十分に活用されていないかどうかを評価するのに役立つ主要な運用メトリクスを可視化します。コスト最適化の観点からは、オーバープロビジョニングのタイミングを理解し、運用、可用性、耐障害性、パフォーマンスのニーズを維持しながら、リソースのサイズ ElastiCacheを変更するための適切なメカニズムを開発できる必要があります。

質問レベルのメリット: 理想的な状態では、ワークロードの運用上のニーズを満たすのに十分なリソースをプロビジョニングでき、コストが最適ではない状態につながる可能性のある、十分に活用されていないリソースがないことです。オーバーサイズの ElastiCache リソースを長期間にわたって特定し、操作しないようにする必要があります。

  • 〔必須] CloudWatch を使用してElastiCache クラスターをモニタリングし、これらのメトリクスが AWS Cost Explorer ダッシュボードにどのように関連しているかを分析します。

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

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

    [リソース]:

  • [必須] バックアップ戦略とコストへの影響を理解し、文書化します。

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

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

    [リソース]:

  • [最良] 十分に理解され、文書化されているワークロードのコストを管理するための計画的な戦略として、インスタンスにリザーブドノードを使用します。リザーブドノードには、ノードタイプと予約の期間 (1 年または 3 年) に応じて、前払い料金が請求されます。この料金は、オンデマンドノードで発生する 1 時間あたりの使用料金よりもはるかに安くなります。

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

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

COST 3: データ階層化をサポートするインスタンスタイプを使用する必要がありますか？ データ階層化のメリットは何か。データ階層化インスタンスを使用すべきでないのはどのような場合か。

質問レベルの紹介: 適切なインスタンスタイプを選択すると、パフォーマンスやサービスレベルだけでなく、財務面にも影響が及びます。インスタンスタイプにはそれぞれ異なるコストがかかります。そのため、メモリ内のすべてのストレージニーズに対応できる大規模なインスタンスタイプを 1 つまたはいくつか選択するのは、自然な判断かもしれません。ただし、プロジェクトが成熟するにつれて、この選択はコストに大きな影響を与える可能性があります。正しいインスタンスタイプが選択されていることを確認するには、 ElastiCache オブジェクトのアイドル時間を定期的に調べる必要があります。

質問レベルのメリット: さまざまなインスタンスタイプが現在および将来のコストにどのように影響するかを明確に理解しておく必要があります。ワークロードのわずかな変化や定期的な変更によってコストが不均等に変化してはいけません。ワークロードが許せば、データ階層化をサポートするインスタンスタイプのほうが、利用可能なストレージあたりの価格が向上します。インスタンスごとに使用可能なSSDストレージデータ階層化インスタンスにより、インスタンスあたりの総データ容量が大幅に増加します。

  • [必須] データ階層化インスタンスの制限を理解する

    1. ElastiCache (Redis OSS) クラスターでのみ使用できます。

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

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

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

    [リソース]:

  • [必須] データベースの何パーセントがワークロードから定期的にアクセスされているかを把握します。

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

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

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

  • [必須] 特定のワークロードでは、データ階層化インスタンスはオプションではないことを理解しておきます。

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

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

    [リソース]:

  • [最良] リザーブドインスタンスタイプはデータ階層化をサポートします。これにより、インスタンスあたりのデータストレージ量の面で、コストが最小化されることが保証されます。

    1. データ階層化以外のインスタンスを使用して ElastiCache クラスターを操作する必要がある場合があります。これは、要件をよりよく理解するまでです。

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

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

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

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

    [リソース]: