Masayan tech blog.

  1. ブログ記事一覧>
  2. Google Cloud Memorystore for Redisのベストプラクティス

Google Cloud Memorystore for Redisのベストプラクティス

公開日

Memorystore for Redis

Memorystore for Redisは、Google Cloudが提供する完全管理型のRedisサービス。このサービスを使用すると、アプリケーションからの高速なデータアクセスを提供するためのインメモリデータストアを簡単にセットアップ、スケール、運用することが可能

ベストプラクティス

メモリ管理を適切に行う

maxmemoryポリシーを指定する

Redisインスタンスのメモリが上限に達した状態で新しい書き込みが発生すると、エラーになる。

エラーを回避するため、インスタンスのmaxmemoryポリシー設定し、Redisがキーのエビクションを行い、ポリシーに基づいて書き込み用にスペースを確保できるようにすることが推奨されている

Memorystore for Redisのデフォルトのmaxmemoryポリシーは volatile-lruとなっており、キーセット全体から、最も長い間使用されていない(LRU)キーを削除する動作となる

※ttyが設定されていないキーは削除対象にならないので注意

Memorystore for Redis v6以上を使う

バージョン6以上を実行しているすべてのインスタンスではI/Oマルチスレッドが有効になり、複数のvCPUを使用してI/Oを同時に処理できるようになり、インスタンスのスループットが向上する

Google Cloudであれば、redisのインスタンスを作成する際にバージョンを選択することが可能。

リードレプリカを使う

プライマリインスタンスに障害が発生した場合はレプリカに自動的にフェイルオーバーします。 リードレプリカはデフォルトでは有効になっていません。

リードレプリカを使用することにより。読み取りスループットが線形に拡張される。プライマリインスタンスがダウンした場合はフェイルオーバーが発生しリードレプリカ用のインスタンスがプライマリとなる。(新しいプライマリが読み取りと書き込みの両方で使用できるようになる)なお、フェイルオーバーには一般的に20〜30秒かかるとされている

RDBスナップショットを作成する

事前定義された間隔でスナップショットを自動的に取得し、必要に応じてそこか復元できるので、データの耐久性を高めることができる

アラートを設定

メモリ、CPUそれぞれCloud Monitoringでしきい値を設定し、しきい値に基づいて問題が発生したときに通知できるようにしておくことが推奨されている。

システムメモリ使用率

システムメモリ使用率が80%のしきい値を超える場合、メモリ不足によりインスタンスがクラッシュする危険性があるため、アラートによる通知を受け取ることができるようにしておく

CPU使用率

90%のCPU使用率のしきい値を維持することが推奨とされている

メインスレッド CPU 秒(redis.googleapis.com/stats/cpu_utilization_main_thread)指標にアラートを設定し、CPU 使用率がプライマリノードで 0.9 秒、各レプリカノードで 0.5 秒を超えないようにすることが推奨されている

モニタリング設定

Cloud Monitoringのcallから確認できる

メンテナンス時間を設定する

Memorystoreはフルマネージドサービスのため、バッチ適用などインスタンスを自動的に適用するが、アプリケーションの使用量のピーク時にメンテナンスが発生することを防ぐため、あらかじめ夜間などに実行されるようにスケジュール設定しておくことが推奨されている

なお、メンテナンスの開始時に、システムメモリ使用率メト​​リックが 50%未満である必要がある点も注意。そのため、インスタンスのトラフィックが少ない時間帯にスケジュールを設定するか、メンテナンス期間中にインスタンスのサイズを一時的にスケールアップする等の対策が必要

メンテナンス通知をオプトインする

インスタンスのメンテナンス更新がスケジュールされる少なくとも 7日前に電子メールでアラートを受けるメンテナンス通知をオプトインする必要がある(デフォルトOFFのため)

設定→通信→Memorystoreの行で、メールボタンを [オン] に切り替える

本番環境の高可用性構成

Memorystore は、Basic層とStandard層の 2 つの層で利用可能。本番環境で利用する際はStandard層を利用することが推奨されている

Basic層

一時キャッシュを備えた単一ノードで構成され、レプリケーションが行われないため、障害が発生するとキャッシュの日付が失われる可能性がある

Standard層

レプリケーションによる高可用性 (HA) と 99.9% の可用性 SLAを提供し、プライマリノードに障害が発生した場合はレプリカに自動的にフェイルオーバーする。障害が発生した場合でも、アプリケーションは重要なキャッシュデータへのより信頼性が高く一貫したアクセスが可能にる。

ただし、フェイルオーバーが発生時は、新たにプライマリとなったレプリカへの接続が確立されるまで、インスタンスは数秒間一時的に利用できなくなる

なお、Standard層では最大 5 つの読み取りレプリカを持つことができる。

まとめ

いかがでしたでしょうか。本記事ではGoogle Cloud Memorystore for Redisのベストプラクティスについて紹介しました。マネージドサービスとはいえ、アプリケーションの要件やユースケースに応じて最低限考慮して設定する必要のある項目も複数ありますので、ぜひ参考にしてみてください