すべてのプロダクト
Search
ドキュメントセンター

Tair (Redis® OSS-Compatible):Tair (Redis OSS-compatible) の開発とO&M標準

最終更新日:Dec 03, 2024

Tair (Redis OSS-compatible) は、高性能データベースサービスです。 このトピックでは、より効率的なビジネスシステムを設計し、Tairをより有効に活用するために従うことができるTair (Redis OSS-compatible) の開発およびO&M標準について説明します。 この標準は、長年のO&M経験に基づいてAlibaba Cloudによって開発されており、ビジネスデプロイ、キー設計、SDKの使用、コマンドの使用、およびO&M管理のシナリオに適用されます。

Tairのパフォーマンス境界

図 1. パフォーマンスの境界Tair Redis性能边界

リソースタイプ

説明

コンピューティングリソース

ワイルドカード文字、同時Luaスクリプト、1対多のPub/Subモデル、およびホットキーは、大量のコンピューティングリソースを消費します。 クラスターインスタンスの場合、これらの項目は、リクエストの偏りやデータシャードの使用不足を引き起こす可能性もあります。

ストレージリソース

ストリーミングジョブと大きなキーは、大量のストレージリソースを消費します。 クラスターインスタンスの場合、これらの項目はデータスキューやデータシャードの使用不足を引き起こす可能性もあります。

ネットワークリソース

データベース全体のスキャン (KEYSコマンドの実行) と、大きなキーと値の範囲クエリ (HGETALLコマンドの実行) は、大量のネットワークリソースを消費し、スレッドの輻輳を引き起こすことがよくあります。

重要

Tairの高い同時実行機能は、期待どおりにアクセスパフォーマンスを大幅に向上させませんが、Tairの全体的なパフォーマンスには影響します。 たとえば、Tairに大きな値を格納しても、アクセスパフォーマンスは大幅に向上しません。

クラスターインスタンスの場合、ホットキー、大きなキー、または大きな値も 歪んだストレージまたは歪んだ要求 本番環境では、Tairのパフォーマンスの境界に到達しないようにすることが重要です。

ビジネス展開基準

重要性

Standard

説明

★★★★★

シナリオが 高速キャッシュ または メモリ内データベース

  • 高速キャッシュ: オーバーヘッドを減らし、データが追い出される可能性があるため、キャッシュ内のデータに強く依存しないように、キャッシュのみのシナリオで追加専用ファイル (AOF) の永続性を無効にすることを推奨します。 詳細については、「AOF持続性の無効化」をご参照ください。 たとえば、Tairデータベースが最大ストレージ容量に達すると、データ削除ポリシーがトリガーされ、新しいデータ用のスペースが作成されます。 ビジネスの書き込みワークロードによっては、レイテンシが増加する可能性があります。

    重要

    データフラッシュバック機能を使用するには、AOF永続性を有効にする必要があります。 詳細については、「データフラッシュバックを使用した時点でのデータの復元」をご参照ください。

  • インメモリデータベース: Tair (Enterprise Edition) 永続メモリ最適化インスタンスを選択することを推奨します。 永続的なメモリ最適化インスタンスは、コマンドレベルの永続性を提供します。 さらに、データベースでアラートを設定することで、メモリ使用量を監視できます。 詳細については、「アラート設定」をご参照ください。

★★★★★

Tairインスタンスの近くにビジネスをデプロイします。 たとえば、Tairインスタンスと同じ仮想プライベートクラウド (VPC) にあるElastic Compute Service (ECS) インスタンスにビジネスをデプロイできます。

Tairは高性能データベースサービスです。 ただし、ビジネスサーバーをTairインスタンスから離れた場所にデプロイし、ビジネスサーバーがインターネット経由でインスタンスに接続されている場合、ネットワークの遅延によりTairのパフォーマンスが大幅に低下します。

説明

クロスリージョンデプロイの場合、グローバル分散キャッシュのgeoレプリケーション機能を使用して、geoディザスタリカバリまたはアクティブなgeo冗長性を実装し、ネットワーク遅延を削減し、ビジネス設計を簡素化できます。 詳細については、「Tairのグローバル分散キャッシュの概要」をご参照ください。

★★★★☆

サービスごとにTairインスタンスを作成します。

異なるサービスにTairインスタンスを使用しないでください。 たとえば、高速キャッシュサービスとインメモリデータベースサービスの両方にTairインスタンスを使用しないでください。 それ以外の場合、1つのサービスの削除ポリシー、低速クエリ、FLUSHDBコマンドの実行が他のサービスに影響します。

★★★★☆

期限切れのキーを削除する適切な削除ポリシーを設定します。

Tairの期限切れキーのデフォルトの削除ポリシーは volatile-lru 削除ポリシーの詳細については、「Redis Open-Source Editionインスタンスに設定できるパラメーター」をご参照ください。

★★★☆☆

ストレステストのデータと期間を管理します。

Tairはストレステストデータを削除しません。 ビジネスへの影響を防ぐには、ストレステストのデータと期間を自分で管理する必要があります。

主なデザイン基準

重要性

Standard

説明

★★★★★

キー値を適切なサイズに設定します。 キーに格納される値のサイズは10 KB未満にすることを推奨します。

値が大きすぎると、データスキュー、ホットキー、高帯域幅、またはCPU使用率が高くなる可能性があります。 キー値が適切なサイズであることを確認することで、これらの問題を最初から防ぐことができます。

★★★★★

適切な長さの適切なキー名を設定します。

  • キー名:

    • 読み取り可能な文字列をキー名として使用します。 データベース名、テーブル名、フィールド名をキー名に結合する場合は、コロン (:) を使用して区切ることを推奨します。 例: project:user:001

    • ビジネスを説明する能力を損なうことなく、キー名を短くします。 たとえば、usernameuに短縮できます。

    • Redisでは、中括弧 {} はハッシュタグとして認識されます。 この場合、クラスターインスタンスを使用する場合は、キー名に中かっこを正しく使用して防ぐ必要があります。 データスキュー 詳細については、「Redisクラスターの仕様」をご参照ください。

      説明

      クラスターインスタンスの場合、RENAMEなどのコマンドを実行して複数のキーを管理し、ハッシュタグを使用してキーが同じデータシャードに存在するようにしない場合、コマンドを実行できません。

  • 長さ: キー名は128バイト以内、できれば短くすることを推奨します。

★★★★★

サブキーをサポートする複雑なデータ構造の場合、1つのキーに過剰なサブキーを含めることを避ける必要があります。 1つのキーに1,000未満のサブキーを含めることを推奨します。

説明

一般的な複雑なデータ構造には、Hash、Set、Zset、Geo、およびStream、およびexHash、Bloom、およびTairGISなどのTair (Enterprise Edition) に固有の構造が含まれます。

HGETALLなどの特定のコマンドの時間の複雑さは、サブキーの数に直接関係します。 過剰なサブキーは、コマンドの時間複雑性を増加させる。 時間の複雑さがO(N) 以上のコマンドを頻繁に実行すると、低速クエリ、データスキュー、ホットキーなどの問題が発生します。

★★★★☆

シリアル化メソッドを使用して、値を読み取り可能な構造に変換します。

プログラミング言語のバイトコードは、言語のバージョンが変更されたときに変更され得る。 裸のオブジェクト (JavaオブジェクトやC# オブジェクトなど) をTairインスタンスに格納すると、ソフトウェアスタックのアップグレードが難しい場合があります。 値を読み取り可能な構造に変換するには、シリアル化メソッドを使用することを推奨します。

SDKの使用基準

重要性

Standard

説明

★★★★★

JedisPoolまたはJedisClusterを使用してTairインスタンスに接続します。

説明

TairJedisクライアントは新しいデータ構造のカプセル化クラスを提供するため、TairJedisクライアントを使用してTair (Enterprise Edition) DRAMベースのインスタンスに接続することを推奨します。 詳細については、「クライアントを使用したTair (Redis OSS-compatible)インスタンスへの接続」をご参照ください。

単一の接続を使用する場合、接続がタイムアウトした後、クライアントは自動的にTairインスタンスに再接続できません。 JedisPoolを使用してTairインスタンスに接続する方法の詳細については、「クライアントを使用してTair (Redis OSS-compatible)インスタンスに接続する」、「JedisPool最適化」、「JedisCluster」をご参照ください。

★★★★☆

クライアントに適切なフォールトトレランスメカニズムを設計します。

ネットワークの変動やリソースの使用量が多いと、Tairで接続タイムアウトやクエリが遅くなる可能性があります。 これらのリスクを防ぐには、クライアントに適切なフォールトトレランスメカニズムを設計する必要があります。

★★★★☆

クライアントの再試行間隔を長く設定します。

リトライ間隔が200ミリ秒より短いなど、必要な間隔より短い場合、短時間で多数回のリトライが発生する可能性があります。 これにより、サービス雪崩が発生する可能性があります。 詳細については、「Redisクライアントの再試行メカニズム」をご参照ください。

コマンド使用基準

重要性

Standard

説明

★★★★★

KEYS * コマンドを実行して実行されるような範囲クエリは避けてください。 代わりに、複数のポイントクエリを使用するか、SCANコマンドを実行してレイテンシを削減します。

範囲クエリは、サービスの中断、低速クエリ、または輻輳を引き起こす可能性があります。

★★★★★

拡張データ構造を使用して複雑な操作を実行します。 詳細については、「複数のデータモジュールの統合」をご参照ください。 Luaスクリプトを使用しないでください。

Luaスクリプトは大量のコンピューティングリソースとメモリリソースを消費し、マルチスレッド高速化をサポートしません。 過度に複雑または不適切なLuaスクリプトは、リソースの枯渇につながる可能性があります。

★★★★☆

パイプラインを使用して、データパケットの往復時間 (RTT) を短縮します。

複数のコマンドをサーバーに送信し、クライアントがサーバーからの各応答に依存しない場合は、パイプラインを使用して一度にコマンドを送信できます。 パイプラインを使用する場合は、次の項目に注意してください。

  • パイプラインを使用するクライアントは、サーバーにのみ接続します。 パイプライン操作を通常の操作から分離するために、専用の接続を確立することを推奨します。

  • 各パイプラインは、適切な数のコマンドを含む必要がある。 各パイプラインを使用して100以下のコマンドを送信することを推奨します。

★★★★☆

トランザクションコマンドを使用します。 詳細については、「Redis Open-Source Editionでサポートされているコマンド」をご参照ください。

トランザクションコマンドを使用する場合は、次の制限事項に注意してください。

  • リレーショナルデータベースのトランザクションとは異なり、Redisのトランザクションはロールバックできません。

  • クラスターインスタンスでトランザクションコマンドを実行する場合は、ハッシュタグを使用して、管理するキーが同じハッシュスロットに割り当てられるようにします。 また、ハッシュタグが引き起こす可能性のある歪んだストレージを防ぐ必要があります。

  • トランザクションコマンドをLuaスクリプトにカプセル化しないでください。これらのコマンドのコンパイルと読み込みは大量のコンピューティングリソースを消費するためです。

★★★★☆

Pub/Subコマンドグループを使用して大量のメッセージ配布タスクを実行しないでください。 詳細については、「Redis Open-Source Editionでサポートされているコマンド」をご参照ください。

Pub/Subコマンドグループは、データの信頼性を確保するためのデータ永続性または確認応答メカニズムをサポートしていません。 多数のメッセージ配布タスクを実行するために、PubコマンドまたはSubコマンドを使用しないことを推奨します。 たとえば、これらのコマンドを使用して、サイズが1 KBを超えるメッセージを100を超えるサブスクライバークライアントに配布すると、サーバーリソースが使い果たされ、サブスクライバークライアントがメッセージを受信できなくなる可能性があります。

説明

パフォーマンスとバランスを改善するために、TairはPubコマンドとSubコマンドに最適化されています。 クラスターインスタンスでは、プロキシノードはチャネル名に基づいてコマンドのハッシュ値を計算し、対応するデータノードにコマンドを割り当てます。

O&Mマネジメント基準

重要性

Standard

説明

★★★★★

さまざまなインスタンス管理操作の影響を理解します。

設定の変更または再起動は、Tairインスタンスのステータスに影響します。 例えば、一時的な接続がインスタンス上で発生することがある。 上記の操作を実行する前に、影響を理解していることを確認してください。 詳細については、「インスタンスの状態と影響」をご参照ください。

★★★★★

クライアントのエラー処理機能またはディザスタリカバリロジックを確認します。

Tairはノードのヘルスステータスを監視できます。 インスタンスのマスターノードが使用できなくなると、Tairは自動的にマスター /レプリカの切り替えをトリガーします。 インスタンスの高可用性を確保するために、マスターノードとレプリカノードのロールが切り替えられます。 クライアントが一般的に利用可能になる前に、マスターレプリカの切り替えを手動でトリガーすることをお勧めします。 これにより、クライアントのエラー処理機能またはディザスタリカバリロジックの検証に役立ちます。 詳細については、「マスターノードからレプリカノードへのワークロードの手動切り替え」をご参照ください。

★★★★★

時間のかかるコマンドやリスクの高いコマンドを無効にします。

本番環境では、コマンドの悪用が問題を引き起こす可能性があります。 たとえば、FLUSHALLコマンドはすべてのデータを削除できます。 KEYSコマンドは、ネットワーク輻輳を引き起こす可能性がある。 サービスの安定性と効率を向上させるために、特定のコマンドを無効にしてリスクを最小限に抑えることができます。 詳細については、「高リスクコマンドの無効化」をご参照ください。

★★★★☆

できるだけ早い機会に保留中のイベントを処理します。

ユーザーエクスペリエンスを向上させ、サービスのパフォーマンスと安定性を向上させるために、Alibaba Cloudは特定のサーバーのハードウェアとソフトウェアをアップグレードしたり、ネットワーク機能を置き換えたりする保留イベントを生成することがあります。 たとえば、データベースのマイナーバージョンを更新する必要がある場合に、保留イベントが生成されます。 Alibaba Cloudからイベント通知を受け取った後、イベントの影響を確認し、ビジネス要件を満たすようにイベントの予定時刻を変更できます。 詳細については、「スケジュールされたイベントの表示と管理」をご参照ください。

★★★★☆

コアメトリックのアラートを設定して、インスタンスのステータスをより適切に監視します。

CPU使用率、メモリ使用率、帯域幅使用率などのコアメトリックのアラートを設定して、インスタンスのステータスをリアルタイムで監視します。 詳細については、「アラート設定」をご参照ください。

★★★★☆

Tairが提供するO&M機能を使用して、インスタンスのステータスを確認したり、リソース使用の例外を定期的にトラブルシューティングしたりします。

  • スロークエリログを使用してタイムアウトの問題を解決する: スロークエリログは、スロークエリとクエリ要求を送信するクライアントのIPアドレスを見つけるのに役立ちます。 低速クエリログは、タイムアウトの問題に対処するための信頼できる基盤を提供します。

  • パフォーマンスモニタリングデータの表示: Tairはさまざまなパフォーマンスメトリックをサポートしています。 これらのメトリクスを使用すると、Tairインスタンスのステータスに関する洞察を得ることができ、できるだけ早い機会に問題をトラブルシューティングできます。

  • 診断レポートの作成: 診断レポートは、パフォーマンスレベル、スキューされたリクエスト、スロークエリログなど、Tairインスタンスのステータスを評価するのに役立ちます。 診断レポートは、Tairインスタンスの例外を特定するのにも役立ちます。

  • オフラインキー分析機能の使用: オフラインキー分析機能を使用して、Tairインスタンス内の大きなキーを識別できます。 大きなキーのメモリ使用量、配布、およびTTLについても学ぶことができます。

  • リアルタイムキー統計機能の使用: リアルタイムキー統計機能は、Tairインスタンスのホットキーを識別し、データベースをさらに最適化するのに役立ちます。

★★★☆☆

監査ログ機能を有効にし、監査ログを評価します。

監査ログ機能を有効にすると、書き込み操作に関する監査統計が記録されます。 Tairを使用すると、監査ログのクエリ、分析、およびエクスポートもできます。 これらの機能は、Tairインスタンスのセキュリティとパフォーマンスを監視するのに役立ちます。 詳細については、「監査ログ機能の有効化」をご参照ください。

重要

監査ログ機能を有効にすると、Tairインスタンスのパフォーマンスが5% から15% に低下する場合があります。 実際のパフォーマンス低下は、書き込み操作または監査操作の数によって異なります。 ビジネスでTairインスタンスで多数の書き込み操作が行われる場合は、トラブルシューティングなどのO&M操作を実行するときにのみ監査ログ機能を有効にすることを推奨します。 これにより、パフォーマンスの低下を防ぐことができます。