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

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

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

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

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

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

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

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

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

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

      • ElastiCache:AddCacheNodeFailed

      • ElastiCache:CacheClusterProvisioningFailed

      • ElastiCache:CacheClusterScalingFailed

      • ElastiCache:CacheNodesRebooted

      • ElastiCache:SnapshotFailed (Valkey または Redis OSS のみ）

    • [リソース]:

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

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

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

質問レベルの紹介: ElastiCache クラスターの適切なサイズ設定はバランスを図る作業であるため、基盤となるワークロードタイプに変更があるたびに評価する必要があります。目標は、ワークロードに適した規模の環境で運用することです。

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

OE 3: ElastiCache クラスターリソースを管理し、クラスターを最新の状態に保つ方法とは。

質問レベルの紹介:大規模に運用する場合、すべての 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 秒に設定されていることを確認します (一部のクライアントでは通常の「なし」のデフォルト設定)。

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

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

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

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

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

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

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

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

OE 5: ワークロード用に ElastiCache コンポーネントをどのようにデプロイするか。

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

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

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

  • [必須] ElastiCache で利用できるデプロイオプションを理解し、可能な限りこれらの手順を自動化します。自動化の可能な手段には、CloudFormation、 AWS CLI/SDK、APIs。

    [リソース]:

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

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

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

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

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

質問レベルの紹介: オペレーショナルエクセレンスには障害の予測が含まれ、定期的に「事前」演習を実施して潜在的な障害の原因を特定し、障害の排除や軽減を図ります。ElastiCache には、テスト目的でノード障害イベントをシミュレートできるフェイルオーバー API が用意されています。

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

[必須] 開発/テストアカウントで定期的にフェイルオーバーテストを実行します。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 OSS 用の ElastiCache バージョン 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 エンジンログで重要な情報をクエリすることを検討します。

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

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

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