GCP記事チェックVol.001
たくさんでるGCP関連の記事。
少しでも読もうというモチベーションで書きます。
自分用メモなので直接ドキュメントを読むことをおすすめします。
- メモリ設定を最適化するための設定とメトリクス
- マルチスレッドによるパフォーマンス向上のためにRedis 6を使用
- メンテナンスウィンドウを設定する
- キャッシュデータが重要な場合、Memorystoreの高可用性を構成する
- Redisコマンドとアンチパターンを避けるために
- クライアント接続ロジックへの指数関数的バックオフの実装
- アラート／モニタリングの設定
メモリ設定を最適化するための設定とメトリクス
- Memorystore for Redisで最も重要な設定の1つがmaxmemory-gb
- Redisのmaxmemory設定を構成し、キーストレージ用に予約されるメモリ量を決定
- 指定されたメモリの最大量に達すると、Evictionポリシーが使用される
- Evictionポリシーは、Memorystore for Redisでmaxmemoryポリシーにより設定される
- デフォルトのポリシーはvolatile-lruで、TTL (time to live)の有効期限が設定された、最も使用頻度の低いキーを退避させる
Best practice:
- maxmemory-gbをチューニングする際、システムメモリ使用率を80% 未満を目標に監視
- システムメモリ使用率が80%を超えた場合、これはインスタンスがメモリプレッシャー下にある
- 対処せず、メモリ使用量が増え続けると、メモリ不足によるインスタンスのクラッシュの危険性がある
- OOMエラーを防ぐには
- activedefragをオンにする
- maxmemory-gbを下げてシステム使用のオーバーヘッドを増やす
- インスタンスをスケールアップする
マルチスレッドによるパフォーマンス向上のためにRedis 6を使用
- Redis 6の新機能の1つに、マルチスレッドI/Oの実装ある
- これまでのRedisはシングルスレッドで、I/OとRedisエンジンが1つのvCPUを共有するため、場合によってはボトルネックになる可能性があった
- 複数のvCPUを構成した場合のメリットが発揮されない
- Memorystore for Redisは、バージョン6を実行しているすべてのインスタンスでI/Oマルチスレッドを有効にし、複数のvCPUを使用してI/Oを同時に処理するこ
- インスタンスのスループットを向上させることができる
Best practice:
- マルチスレッドの利点を活用するために、新しく作成されたインスタンスはすべてRedis 6でデプロイする
- パフォーマンスとスループットが重要なインスタンスの場合は、M3層以上のインスタンスをデプロイする
- 既存のMemorystore for Redisインスタンスをアップグレードする
- アップグレードを試みる前にテストを行う
メンテナンスウィンドウを設定する
- Memorystore for Redisでは、メンテナンスウィンドウを定義することができる
- 特定の曜日に1時間だけメンテナンスを実行する時間枠
- メンテナンスウィンドウを設定することで、メンテナンスが発生するタイミングを予測することができる
- メンテナンスウィンドウがインスタンスに設定されていない場合、メンテナンスはいつでも、どの日でも実行される可能性がある
- アプリケーションの使用量が多い時間帯にメンテナンスが発生する可能性がある
Best practice:
- インスタンスのメンテナンスウィンドウを設定し、ピーク時にメンテナンスが発生しないようにし、使用量の少ない時間帯にのみメンテナンスが発生するようにする
- インスタンスにメンテナンスの更新が予定される少なくとも7日前に、メールで警告を受けるようにメンテナンス通知をオプトインする
- メンテナンスの開始時に、システムメモリ使用率メトリクスが50%未満であることを確認する
- インスタンスのトラフィックが低い時間帯にスケジューリングするか、メンテナンスウィンドウの間にインスタンスサイズを一時的にスケールアップすることで実現可能
- 最も影響の少ないStandard Tierを検討
- Basic Tierのインスタンスは、最大5分間続く可能性のあるメンテナンス中に利用できなくなる
キャッシュデータが重要な場合、Memorystoreの高可用性を構成する
- MemorystoreはBasic tierとStandard tierの2つの層で提供されてる
- Basic tierは、エフェメラルキャッシュを持つ単一ノードで構成され、レプリケーションはない
- ベーシック層に障害が発生した場合、バックアップやレプリケーションがないため、キャッシュの日付が失われる可能性ある
- Standard Tierは、レプリケーションによる高可用性(HA)と99.9%の可用性SLAを提供し、プライマリノードが故障した場合は自動的にレプリカにフェイルオーバーする
- 高可用性(HA)機能により、障害が発生した場合でも、重要なキャッシュデータにより高い信頼性と一貫性をもってアクセスが可能
- フェイルオーバーが行われ、プライマリになったレプリカへの接続が確立されるまでの数秒間、インスタンスは一時的に使用できない
- Memorystore for Redis Standard Tierは、高可用性とスケールのために最大5つのリードレプリカを持つことができる
- リードレプリカはデフォルトでは有効になっていない
- 有効にすると、高可用性に加えて、読み取りワークロードのスケールが可能になり、すべてのレプリカノードにクエリを分散させる単一の読み取りエンドポイントを提供する
Best practice:
- キャッシュのフルフラッシュを許容できないアプリケーションには、Standard Tier
- RDBスナップショットを活用することで、さらなるデータ耐久性を実現
Redisコマンドとアンチパターンを避けるために
KEYSコマンドの使用 - KEYSコマンドを使用すると、大規模なデータベースで使用した場合、インスタンスのパフォーマンスに大きな影響を与える可能性ある
Best practice:
- 実稼働環境でのKEYSコマンドの使用を避ける
- KEYSコマンドを使用する代わりに、SCANコマンドを使用
未束縛の結果を返すコマンドを避ける - LRANGE、HGETALL、ZRANGE などの特定のコマンドは、非常に大量のキーとデータを返すことがあり、サーバーの性能に悪影響を及ぼします。
Best practice:
- サポートコマンドでデータ構造のサイズを確認し、サイズが大きすぎないことを確認する
高可用性またはRDBスナップショットを使用しない永続層としてのRedis - 高可用性または定期的なRDBスナップショットが設定されていない場合、インスタンス障害時にメモリストアRedisデータは失われます。
Best practice:
- 重要なデータやアプリケーションがMemorystore for Redisのある程度の永続性に依存している場合、Standard TierとRDB Snapshotsを使用して高可用性を使用
クライアント接続ロジックへの指数関数的バックオフの実装
- Exponential backoffは標準的なエラー処理方法
- 失敗したリクエストを、増加しつつもランダムな遅延で再試行する とによって動作
- 遅延の一時的な増加の結果、ユーザーがリフレッシュを押したり、 受信したリクエストのバックログが多いために、大量のリクエストが発生する シナリオを緩和するのに有用
- ランダム化は、再試行戦略の重要なコンポーネント
- 再試行のたびに時間が増えますが、同時に再試行の大きな波が発生しないように、ランダムな変動も必要
- ランダムな変動は、通常1-1000ミリ秒の間になります。-
- リトライ戦略は、リトライが32秒または64秒以上待たされ、最終的に失敗しないように、最大バックオフを含める必要ある
Best practice: - リトライロジックを開発する際に、少しランダムだがバックオフを増加させること
アラート／モニタリングの設定
