Google Cloud Memorystore for Redis のベスト プラクティス - 高パフォーマンスで安心なデプロイのヒント

※この投稿は米国時間 2022 年 12 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

手法

高パフォーマンスで安心なデプロイのヒント

Memorystore は、オープンソースのインメモリ データベースである Redis と Memcached をフルマネージドで実装したものです。Memorystore を使えば、簡単に Google Cloud 上にアプリケーションを構築して、オープンソースの Redis と Memcached をベースにしたインメモリ ストアを活用できます。

現在、クラウド上にデプロイされたアプリケーションの多くが、インメモリ データストアを利用しています。ユースケースの例として、キャッシュ、リアルタイム解析、セッション ストア、リーダーボード、キュー、高速なデータ取り込みなどが挙げられます。Redis と Memcached は、ミリ秒未満のレイテンシが求められるようなアプリケーションにおいて、デベロッパーに多く選ばれています。このブログ投稿では、Memorystore for Redis に焦点を当ててお伝えします。

Memorystore for Redis はマネージド サービスですが、アプリケーションの動作やユースケースに応じて、従うべきベスト プラクティスがあります。以下のベスト プラクティスのおすすめは、ご自身のユースケースに最適なエクスペリエンスを提供するために役立ちます。

メモリ設定を最適化するための構成設定と指標

Memorystore for Redis において最も重要な設定の一つが、maxmemory-gb です。この設定は、Redis の maxmemory 設定を構成し、鍵の保管用に確保されるメモリ量を決定します。指定されたメモリの最大量に達したときに、エビクション ポリシーが使用されます。Memorystore for Redis では、maxmemory ポリシーによってエビクション ポリシーが設定されています。デフォルトのポリシーは volatile-lru で、有効期間（TTL）の期限が設定された、最も使用頻度の低い鍵を強制排除します。

ベスト プラクティス:

maxmemory-gb を調整する際には、システムメモリ使用率（SMUR）をモニタリングし、80% 未満を目標にする必要があります。システムメモリ使用率の指標が 80% を超える場合、インスタンスがメモリ不足に陥っていることを示します。対策をしないままメモリ使用量が増え続けると、メモリ不足が原因でインスタンスがクラッシュする恐れがあります。OOM エラーを防ぐには、activedefrag をオンにするか、maxmemory-gb を低くしてシステム使用量のオーバーヘッドを増やすか、インスタントをスケールアップします。詳細は、こちらをご覧ください。

マルチ スレッディングを用いたパフォーマンス向上のために Redis 6 を使用する

Redis 6 の新しい機能の一つに、マルチスレッド I/O の実装があります。Redis の以前のバージョンはシングル スレッドで、I/O と Redis エンジンが単一の vCPU を共有するため、しばしばボトルネックとなる場合がありました。このため、複数の vCPU 構成のメリットが発揮されていませんでした。Memorystore for Redis は、バージョン 6 を実行しているすべてのインスタンスで I/O マルチ スレッディングを有効にしました。これにより、複数の vCPU を使用して I/O を同時に処理できるようになり、インスタンスのスループットが向上しました。マルチ スレッディングのため、CPU 秒数の指標が 1 秒以上にバーストする可能性がありますが、これは集計指標であるため、100% 以上の使用率を示唆していることに留意してください。

Memorystore for Redis は、異なる容量階層を提供します。容量階層は、Redis 6 の単一ノードのパフォーマンスと I/O スレッドの数を決定します。

以下のテーブルは、Redis のバージョンに関連した、それぞれの容量階層と I/O スレッドについて説明したものです。Redis 6 のマルチ スレッディングには、M3 の容量階層以上が必要です。

注: Redis 6 のマルチ スレッディングを使用すると、CPU 使用率が 100% を超えてバーストすることがあります。これは、インスタンスが複数のコアを使用していることを示します。例えば、6 つのスレッドを持つ M4 インスタンスの場合、CPU 使用率は 600% までバーストし、6 つのコアすべてが使用されていることがわかります。

ベスト プラクティス: 

マルチ スレッディングの恩恵を享受するために、Redis 6 で新しく作成されたすべてのインスタンスをデプロイすることをおすすめしています。パフォーマンスとスループットが重要であるインスタンスの場合、M3 階層以上のインスタンスでデプロイするとよいでしょう。また、既存の Memorystore for Redis インスタンスをアップグレードすることも推奨しています。Redis は API の後方互換性を保つことを目的としているため、このアップグレードは通常簡単で安全ですが、試みる前に適切なテストを行っておくことをおすすめします。

Redis 6 のマルチ スレッディングに加えて、リードレプリカをインスタンスに追加することにより、パフォーマンスが大幅に向上します。リードレプリカを追加するごとに、リード スループットの合計が直線的にスケーリングされ、最大 5 台のリードレプリカがサポートされます。

Memorystore for Redis のリードレプリカと Redis バージョン 6 について詳しくは、こちらをご覧ください。

スムーズなオペレーションのためのメンテナンスの時間枠の構成

Memorystore は、インスタンスを自動的に更新します。こうしたアップデートは、インスタンスのセキュリティ、パフォーマンス、高可用性を維持するために必要不可欠です。また、フルマネージド サービスの多くの利点の一つでもあります。

Memorystore for Redis では、メンテナンスの時間枠を定義できます。これは、特定の曜日に 1 時間だけメンテナンスを行う時間枠のことです。メンテナンスの時間枠を構成することで、メンテナンスが発生するタイミングを予測することができます。メンテナンスの時間枠がインスタンスに構成されていない場合、メンテナンスはいつでも、どの日でも実行されます。つまり、アプリケーションの使用量が多い時間帯にもメンテナンスが発生する可能性があるということです。

ベスト プラクティス:

以下の Memorystore for Redis のメンテナンスの時間枠のベスト プラクティスで、メンテナンスの影響を軽減、最小化して、最高のメンテナンス エクスペリエンスを得ることをおすすめします。

• インスタンスのメンテナンスの時間枠を設定することで、アクティビティのピーク時ではなく、日曜の早朝などの使用量の少ない時間帯にメンテナンスを実施できます。

• インスタンスのメンテナンス更新がスケジュールされる少なくとも 7 日前にメールでアラートを受け取るためには、メンテナンスの通知にオプトインする必要があります。

• メンテナンスの開始時に、システムメモリ使用率指標が 50% 未満であることを確認します。これを行うには、インスタンスのトラフィックが少ない時間にスケジュールを設定するか、メンテナンスの時間枠内にインスタンス サイズを一時的にスケールアップします。

• 最も影響の少ない スタンダード ティアをご検討ください。メンテナンス中は、ベーシック ティアのインスタンスが利用できなくなります（最大 5 分間）。

メンテナンスの時間枠の設定や詳細については、こちらのドキュメントをご覧ください。

キャッシュ データが重要である場合の Memorystore の高可用性の構成

Memorystore は、ベーシック ティアとスタンダード ティアの 2 つの階層で利用できます。ベーシック ティアは、エフェメラル キャッシュがあり、レプリケーションを持たない単一ノードで構成されています。ベーシック ティアの障害では、バックアップやレプリケーションがないため、キャッシュの日付が失われる可能性があります。スタンダード ティアは、レプリケーションによる高可用性（HA）と 99.9% の可用性 SLA を提供し、プライマリ ノードに障害が発生した場合は自動的にレプリカにフェイルオーバーします。この HA 機能により、障害が発生した場合でも、アプリケーションは重要なキャッシュ データにより確実かつ一貫してアクセスできるようになります。フェイルオーバーが行われ、プライマリになったレプリカとの接続が確立されるまでの数秒間、インスタンスは一時的に利用不可能になります。

Memorystore for Redis のスタンダード ティアは、高可用性とスケーリングのため、最大 5 つの読み取りレプリカを利用できます。リードレプリカは、デフォルトでは有効にはなっていません。有効にすると、高可用性に加えて、読み取りワークロードのスケーリングが可能になり、すべてのレプリカノードにクエリを分散させる単一の読み取りエンドポイントを提供します。

ベスト プラクティス:

キャッシュの完全なフラッシュを許容できないアプリケーションの場合、スタンダード ティアが、推奨されるデプロイ階層となります。RDB スナップショットを活用することで、さらなるデータ耐久性が実現します。

さらに詳しくは、Memorystore の高可用性と階層のドキュメントをご覧ください。

Redis のコマンドとアンチパターンを回避する

インスタンスにベストなパフォーマンスとセキュリティを確保し、費用を最適化するためには、Redis のこうしたコマンドとアンチパターンを回避する必要があります。

• KEYS コマンドを使用する - KEYS コマンドを使用すると、大規模なデータベースを使用した場合に、インスタンスのパフォーマンスに重大な影響を及ぼす可能性があります。
  
  ベスト プラクティスは、本番環境での KEYS コマンドの使用を避け、十分に注意することです。KEYS コマンドの代替手段として、SCAN コマンドを使用します。

• 制限なしの結果を返すコマンドを避ける - LRANGE、HGETALL、ZRANGE といったようなコマンドは、サーバーのパフォーマンスに悪影響を及ぼしうる、非常に大きな鍵やデータを返すことがあります。
  
  ベスト プラクティスは、サポート コマンドを使用してデータ構造のサイズをチェックし、サイズが大きくなりすぎないようにすることです。

• 高可用性または RDB スナップショットを使用しない永続層としての Redis - Memorystore Redis のデータは、高可用性または定期的な RDB スナップショットで構成されていない場合、インスタンス障害時に失われます。
  
  ベスト プラクティスは、重要なデータである場合、またはアプリケーションが Memorystore for Redis のあるレベルの永続性に依存している場合に、スタンダード ティアおよび RDB スナップショットで高可用性を使用することです。  

クライアント接続ロジックへの指数バックオフの実装

指数バックオフは、標準的なエラー処理方法です。これは、失敗したリクエストを再試行し、ランダム化された遅延を増加させることで機能します。また、一時的なレイテンシの増加により、ユーザーが更新ボタンを押したり、受信リクエストのバックログが発生したりして、大量のリクエストが発生するシナリオを軽減するのに役立ちます。

ランダム化は、再試行戦略の主要なコンポーネントです。再試行のたびに時間は増加しますが、同時に大量の再試行が発生しないよう、ランダムな変動も必要です。ランダムな変動は通常、1 から 1000 ミリ秒の間で推移します。

再試行の待ち時間が 32 秒または 64 秒以上になって、最終的に失敗するようなことがないように、再試行戦略には最大バックオフを含める必要があります。

ベスト プラクティス:

ベスト プラクティスは、わずかにランダムではあるがバックオフが増加する再試行ロジックを開発することです。最終的にはタイムアウトし、アラート メカニズムでアプリケーション チームに通知する必要があります。なお、Redis クライアントによっては、すでになんらかの形で実装されている場合があります。

アラート / モニタリングを構成する

モニタリングとアラートは、Google Cloud の重要な機能です。モニタリングによって、特定の指標を長期間観察し、アーキテクチャの健全性を評価できます。また、特定の問題をリアルタイムに、あるいは過去に遡ってトラブルシューティングする際にも役に立ちます。アラートは、設定したしきい値に基づき、問題が起きたときに通知します。

SMUR や稼働時間といったような以下の主な指標に、アラートを設定することをおすすめしています。これらのアラートは、アプリケーションのパターンに応じてカスタマイズする必要があります。問題をあぶり出し、かつ誤った警告を最小限に抑えるようにするためです。

モニタリングする主な指標

アプリケーションを Memorystore for Redis 上に安心してデプロイ

Memorystore は、フルマネージドで、高可用性、高パフォーマンスを誇る、スケーラブルで安全な Redis のサービスです。Memorystore for Redis を使用すれば、Redis ソフトウェアの複雑な管理から解放されます。このドキュメントでは、デプロイを高速化し、Memorystore for Redis 上で安心してアプリケーションを実行するためのベスト プラクティスと機能を紹介します。これらの推奨事項により、ご自身のアプリケーションとユーザーに、最高レベルのパフォーマンスと信頼性を提供できます。  

今すぐ Memorystore for Redis を始めましょう。リードレプリカ、高可用性、メンテナンスについても詳しく知ることができます。