Amazon ElastiCache Well-Architected レンズのオペレーショナルエクセレンスの柱 - Amazon ElastiCache
OE 1: ElastiCache クラスターによってトリガーされるアラートやイベントをどのように理解し、対応しますか？OE 2: 既存の ElastiCache クラスターをいつ、どのようにスケーリングしますか？OE 3: ElastiCache クラスターリソースを管理し、クラスターを維持するにはどうすればよいですか up-to-date？OE 4: ElastiCache クラスターへのクライアントの接続をどのように管理しますか？OE 5: ワークロードの ElastiCache コンポーネントをデプロイする方法OE 6: 障害に対してどのように計画し、それを軽減するか。OE 7: Valkey または Redis OSS エンジンイベントをどのようにトラブルシューティングしますか？

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

Amazon ElastiCache Well-Architected レンズのオペレーショナルエクセレンスの柱

運用上の優秀性の柱では、ビジネス価値をもたらし、プロセスと手順の継続的な向上を実現するために、システムを実行およびモニタリングすることに焦点を当てています。主なトピックは、変更の自動化、イベントへの対応、日常業務を管理するための標準の定義です。

OE 1: ElastiCache クラスターによってトリガーされるアラートやイベントをどのように理解し、対応しますか？

質問レベルの紹介: ElastiCache クラスターを操作すると、特定のイベントが発生したときに通知やアラートをオプションで受け取ることができます。デフォルトで ElastiCache、 は、フェイルオーバー、ノード交換、スケーリングオペレーション、スケジュールされたメンテナンスなど、リソースに関連するイベントをログに記録します。各イベントには、日付と時刻、ソース名とソースタイプ、および説明が含まれます。

質問レベルのメリット: クラスターによって生成されたアラートをトリガーするイベントの背後にある根本的な理由を把握し、管理できると、より効果的に運用し、イベントに適切に対応できるようになります。

  • 〔必須〕 ElastiCache コンソールElastiCache で (リージョンを選択した後）、または Amazon コマンドラインインターフェイス (AWS CLI) describe-events コマンドと を使用して、 によって生成されたイベントを確認しますElastiCache API。Amazon Simple Notification Service (Amazon ) を使用して重要なクラスターイベントの通知を送信する ElastiCache ように を設定しますSNS。クラスターSNSで Amazon を使用すると、 ElastiCache イベントに対してプログラムでアクションを実行できます。

    • イベントには、現在のイベントと予定されているイベントの 2 つの大きなカテゴリがあります。現在のイベントのリストには、リソースの作成と削除、スケーリングオペレーション、フェイルオーバー、ノードの再起動、スナップショットの作成、クラスターのパラメータ変更、CA 証明書の更新、障害イベント (クラスタープロビジョニングの失敗 - VPCまたは ENI-、スケーリングの失敗 - ENI、スナップショットの失敗) が含まれます。予定されているイベントのリストには、メンテナンス期間中に交換が予定されているノードとスケジュールが変更されたされたノード交換が含まれます。

    • これらのイベントの中にはすぐに対応する必要がないものもありますが、最初にすべての障害イベントを確認することが重要です。

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache: SnapshotFailed （バルキーまたは Redis OSSのみ）

    • [リソース]:

  • 〔ベスト〕 イベントへの対応を自動化するには、 SNS や Lambda Functions などの AWS 製品やサービスの機能を活用します。ベストプラクティスに従って、小規模で頻繁に、元に戻せる変更をコードとして作成し、時間の経過に伴ってオペレーションを進化させます。Amazon CloudWatch メトリクスを使用してクラスターをモニタリングする必要があります。

    〔リソース]: AWS Lambda、Amazon Route 53、Amazon を使用して、Lambda と を使用するユースケースについて、リードレプリカエンドポイントをモニタリング ElastiCache (Redis OSS) (クラスターモードが無効) SNS しますSNS。

OE 2: 既存の ElastiCache クラスターをいつ、どのようにスケーリングしますか？

質問レベルの紹介: ElastiCache クラスターのサイズを適正化することは、基盤となるワークロードタイプが変更されるたびに評価する必要があるバランスの取れた行為です。目標は、ワークロードに適した規模の環境で運用することです。

質問レベルのメリット: リソースの使用率が高すぎると、レイテンシーが上昇し、全体的なパフォーマンスが低下する可能性があります。一方、十分に活用されていない場合、リソースのオーバープロビジョニングとなり、最適なコストで運用されない可能性があります。環境のサイズを適切に設定することで、パフォーマンス効率とコスト最適化のバランスを取ることができます。リソースの過剰または過少使用率を修正するには、 ElastiCache を 2 つのディメンションにスケールできます。ノード容量を増減することで垂直方向にスケールできます。ノードを追加および削除して、水平方向にスケールすることもできます。

OE 3: ElastiCache クラスターリソースを管理し、クラスターを維持するにはどうすればよいですか up-to-date？

質問レベルの紹介: 大規模に運用する場合は、すべての ElastiCacheリソースを特定および特定できることが重要です。新しいアプリケーション機能をロールアウトするときは、開発、テスト、本番稼働のすべての ElastiCache 環境タイプにわたってクラスターバージョンの対称性を作成する必要があります。リソース属性を使用すると、新しい機能の展開や新しいセキュリティメカニズムの有効化など、運用上の目的に応じて環境を分けることができます。

質問レベルのメリット: 開発環境、テスト環境、本番環境を分離することが、運用上のベストプラクティスです。また、環境全体のクラスターとノードに、十分に理解され文書化されたプロセスを使用して最新のソフトウェアパッチを適用することもベストプラクティスです。ネイティブ ElastiCache 機能を活用することで、エンジニアリングチームは ElastiCache メンテナンスではなく、ビジネス目標の達成に集中できます。

  • 〔ベスト〕 利用可能な最新バージョンのエンジンで を実行し、セルフサービスの更新が利用可能になったらすぐに適用します。 は、クラスターの指定されたメンテナンスウィンドウ中に基盤となるインフラストラクチャ ElastiCache を自動的に更新します。ただし、クラスターで実行されているノードは、セルフサービスの更新によって更新されます。これらの更新には、セキュリティパッチとマイナーソフトウェアの更新の 2 種類があります。パッチの種類の違いと適用時期について必ず理解しておいてください。

    [リソース]:

  • 〔ベスト〕 タグを使用して ElastiCache リソースを整理します。タグは個々のノードではなくレプリケーショングループに使用します。リソースをクエリするときに表示するタグを設定したり、タグを使用して検索を実行したり、フィルターを適用できます。共通のタグセットを共有するリソースのコレクションを簡単に作成および管理するには、リソースグループを使用する必要があります。

    [リソース]:

OE 4: ElastiCache クラスターへのクライアントの接続をどのように管理しますか？

質問レベルの紹介: 大規模に運用する場合は、クライアントが ElastiCache クラスターと接続してアプリケーションの運用面 (レスポンスタイムなど) を管理する方法を理解する必要があります。

質問レベルのメリット: 最適な接続メカニズムを選択することで、タイムアウトなどの接続エラーによってアプリケーションが切断されることがなくなります。

  • [必須] 読み取りオペレーションを書き込みオペレーションから分離し、レプリカノードに接続して読み取りオペレーションを実行します。ただし、書き込みを読み取りから分離すると、Valkey レプリケーションと Redis OSSレプリケーションの非同期性のために、キーを書き込んだ直後にキーを読み取る機能が失われることに注意してください。WAIT コマンドを活用して、実際のデータの安全性を向上させ、レプリカがクライアントに応答する前に書き込みを強制的に承認するように、全体的なパフォーマンスコストで行うことができます。リードオペレーションにレプリカノードを使用することは、クラスターモードの ElastiCache リーダーエンドポイントを無効にして ElastiCache (Redis OSS) クライアントライブラリで設定できます。クラスターモードを有効にするには、 ElastiCache (Redis OSS) READONLY コマンドを使用します。（ ElastiCache Redis OSS) クライアントライブラリの多くでは、 ElastiCache (Redis OSS) READONLYはデフォルトで、または設定を介して実装されます。

    [リソース]:

  • [必須] 接続プーリングを使用します。TCP 接続を確立すると、クライアント側とサーバー側CPUの両方で時間がかかり、プーリングによりTCP接続を再利用できます。

    接続オーバーヘッドを減らすには、接続プーリングを使用する必要があります。接続のプールがあれば、アプリケーションは接続を「自由に」再利用および解放でき、接続を確立するコストを回避できます。 ElastiCache (Redis OSS) クライアントライブラリ (サポートされている場合) を介して接続プーリングを実装し、アプリケーション環境で使用できるフレームワークを使用して、またはゼロから構築できます。

  • [最良] クライアントのソケットタイムアウトが少なくとも 1 秒に設定されていることを確認します (一部のクライアントでは通常の「なし」のデフォルト設定)。

    • タイムアウト値の設定が低すぎると、サーバー負荷が高いときにタイムアウトする可能性があります。設定が高すぎると、アプリケーションが接続の問題を検出するのに長時間かかる可能性があります。

    • クライアントアプリケーションに接続プーリングを実装して、新しい接続の量を制御します。これにより、接続の開閉に必要なレイテンシーとCPU使用率が軽減され、クラスターで TLS が有効になっている場合はTLSハンドシェイクが実行されます。

    〔リソース]: 可用性を高めるために ElastiCache (Redis OSS) を設定する

  • [良い] パイプラインを使用すると (ユースケースで可能な場合)、パフォーマンスを大幅に向上させることができます。

    • パイプラインを使用すると、アプリケーションクライアントとクラスター間のラウンドトリップ時間 (RTT) を短縮でき、クライアントが前のレスポンスをまだ読み取っていない場合でも、新しいリクエストを処理できます。

    • パイプラインを使用すると、応答/ack を待たずに複数のコマンドをサーバーに送信できます。パイプラインの欠点は、最終的にすべてのレスポンスを一括取得したときに、エラーが発生しても、そのエラーを最後までキャッチできない可能性があることです。

    • 不正なリクエストを省略したエラーが返されたときに、リクエストを再試行するメソッドを実装します。

    [リソース]: パイプライン

OE 5: ワークロードの ElastiCache コンポーネントをデプロイする方法

質問レベルの紹介: ElastiCache 環境は、 AWS コンソールを介して手動でデプロイすることも、APIs、CLIツールキットなどを介してプログラムでデプロイすることもできます。オペレーショナルエクセレンスのベストプラクティスでは、可能な限りコードを使用してデプロイメントを自動化することを推奨しています。さらに、 ElastiCache クラスターはワークロードによって分離することも、コスト最適化のために組み合わせることもできます。

質問レベルの利点: ElastiCache 環境に最適なデプロイメカニズムを選択すると、時間の経過とともにオペレーションエクセレンスが向上します。ヒューマンエラーを最小限に抑え、再現性、柔軟性、イベントへの応答時間を向上させるため、可能な限りコードとしてオペレーションを実行することをお勧めします。

ワークロードの分離要件を理解することで、ワークロードごとに専用 ElastiCache 環境を用意するか、複数のワークロードを単一のクラスターに結合するか、その組み合わせを選択できます。トレードオフを理解することは、オペレーショナルエクセレンスとコスト最適化のバランスをとるのに役立ちます。

  • 〔必須〕 で使用できるデプロイオプションを理解し ElastiCache、可能な限りこれらの手順を自動化します。自動化の可能な方法には CloudFormation、、 AWS CLI/SDK、および が含まれますAPIs。

    [リソース]:

  • [必須] すべてのワークロードについて、必要なクラスター分離のレベルを決定します。

    • [最良]: 高度な分離 — ワークロードとクラスターの 1:1 のマッピング。ワークロードごとに、 ElastiCache リソースへのアクセス、サイジング、スケーリング、管理をきめ細かく制御できます。

    • [さらに良い]: 中程度の分離 — 目的別に分離されている、複数のワークロード (例えば、キャッシュワークロード専用のクラスターとメッセージング専用のクラスタ) で共有されている可能性がある M: 1。

    • [良い]: 低度な分離 — 汎用タイプ、完全共有型の M:1。共有アクセスが許容されるワークロードに推奨されます。

OE 6: 障害に対してどのように計画し、それを軽減するか。

質問レベルの紹介: Operational Excellence には、潜在的な障害の原因を特定して、障害の発生源を特定するための定期的な「死前の」演習を実施することによる障害の予測が含まれます。 は、テスト目的で、シミュレートされたノード障害イベントAPIを許可するフェイルオーバー ElastiCache を提供します。

質問レベルのメリット: 障害シナリオを事前にテストすることで、それらがワークロードにどのように影響するかを知ることができます。これにより、対応手順とその有効性を安全にテストできるだけでなく、チームはその実行に慣れておくことができます。

〔必須〕 開発/テストアカウントで定期的にフェイルオーバーテストを実行します。 TestFailover

OE 7: Valkey または Redis OSS エンジンイベントをどのようにトラブルシューティングしますか？

質問レベルの紹介: Operational Excellence では、サービスレベルとエンジンレベルの情報の両方を調査して、クラスターのヘルスとステータスを分析する機能が必要です。 ElastiCache は、Amazon CloudWatch と Amazon Kinesis Data Firehose の両方に Valkey または Redis OSS エンジンログを出力できます。

質問レベルの利点: ElastiCache クラスターで Valkey または Redis OSS エンジンログを有効にすると、クラスターのヘルスとパフォーマンスに影響を与えるイベントに関するインサイトが得られます。Valkey または Redis OSS エンジンログは、 ElastiCache イベントメカニズムを介して利用できないエンジンから直接データを提供します。 ElastiCache イベント (前述の OE-1 を参照) とエンジンログの両方を注意深く観察することで、ElastiCache サービスの観点からもエンジンの観点からも、トラブルシューティング時にイベントの順序を決定できます。

  • 〔必須〕 Redis OSS エンジンログ記録機能が有効になっていることを確認します。この機能は ( ElastiCache Redis OSS) 6.2 以降で使用できます。これは、クラスターの作成中に実行することも、作成後にクラスターを変更することによって実行することもできます。

    • Amazon CloudWatch Logs または Amazon Kinesis Data Firehose が Redis OSS エンジンログの適切なターゲットであるかどうかを判断します。

    • ログを保持するには、 CloudWatch または Kinesis Data Firehose のいずれかで適切なターゲットログを選択します。クラスターが複数ある場合は、クラスターごとに異なるターゲットログを使用することを検討します。これにより、トラブルシューティング時にデータを分離しやすくなります。

    [リソース]:

  • 〔最適〕 Amazon CloudWatch Logs を使用する場合は、Amazon CloudWatch Logs Insights を活用して、重要な情報を Valkey または Redis OSS エンジンログにクエリすることを検討してください。

    例えば、次のようなWARNING LogLevel 「」のイベントを返す Valkey または Redis OSS エンジンログを含む CloudWatch Log グループに対してクエリを作成します。

    fields @timestamp, LogLevel, Message
| sort @timestamp desc
| filter LogLevel = "WARNING"

    〔リソース]: CloudWatch Logs Insights を使用したログデータの分析