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 と を使用するユースケースでは、Lambda、Amazon Route 53、Amazon を使用してリードレプリカエンドポイントをモニタリング ElastiCache （クラスターモードが無効) 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 クライアントライブラリで設定できます。クラスターモードが有効になっている場合は、 READONLY コマンドを使用します。クライアント ElastiCache ライブラリの多くでは、 READONLYはデフォルトで実装されるか、設定によって実装されます。

    [リソース]:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 〔必須〕 使用可能なデプロイオプションを理解し ElastiCache、可能な限りこれらの手順を自動化します。自動化の考えられる手段には、 CloudFormation、 AWS CLI/SDK、 などがありますAPIs。

    [リソース]:

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

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

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

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

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

質問レベルの紹介: 運用上の優秀性には、障害の潜在的な原因を特定して、障害の予測が含まれます。テスト目的で、ノード障害イベントをシミュレートAPIできるフェイルオーバー ElastiCache を提供します。

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

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

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

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

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

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

    • 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 ロググループに対してクエリを作成します。

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

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