Tair (Redis OSS-compatible) は、パフォーマンス専有型のデータベースサービスです。このトピックでは、より効率的な業務システムを設計し、Tair をより有効に活用するために従うことができる Tair (Redis OSS-compatible) の開発および運用保守の標準について説明します。この標準は、Alibaba Cloud が長年の運用保守経験に基づいて開発したもので、業務デプロイメント、キー設計、SDK の使用、コマンドの使用、運用保守管理といったシナリオに適用されます。
Tair のパフォーマンス境界
図 1. Tair のパフォーマンス境界
リソースタイプ | 説明 |
計算リソース | ワイルドカード文字、同時実行される Lua スクリプト、1 対多の PUBSUB、およびホットキーは、大量の計算リソースを消費します。クラスターインスタンスの場合、これらの項目はリクエストの偏りやデータシャードの非効率な利用を引き起こす可能性もあります。 |
ストレージリソース | ストリーミングジョブと large キーは、大量のストレージリソースを消費します。クラスターインスタンスの場合、これらの項目はデータスキューやデータシャードの非効率な利用を引き起こす可能性もあります。 |
ネットワークリソース | データベース全体のスキャン (KEYS コマンドの実行による) や、large キーと値の範囲クエリ (HGETALL コマンドの実行による) は、大量のネットワークリソースを消費し、しばしばスレッドの輻輳を引き起こします。 重要 Tair の高い同時実行能力は、期待されるほどアクセスパフォーマンスを大幅に向上させるわけではありませんが、Tair の全体的なパフォーマンスに影響を与えます。たとえば、Tair に large 値を格納しても、アクセスパフォーマンスは大幅に向上しません。 |
クラスターインスタンスの場合、ホットキー、large キー、または large 値も、 ストレージの偏りまたはリクエストの偏り を引き起こす可能性があります。本番環境では、Tair のパフォーマンス境界に達しないようにすることが重要です。
業務デプロイメントの標準
重要度 | 標準 | 説明 |
★★★★★ | シナリオが 高速キャッシュ か インメモリデータベース かを判断します。 |
|
★★★★★ | Tair インスタンスの近くに業務をデプロイします。たとえば、Tair インスタンスと同じ VPC にある Elastic Compute Service (ECS) インスタンスに業務をデプロイできます。 | Tair はパフォーマンス専有型のデータベースサービスです。ただし、業務サーバーを Tair インスタンスから遠くにデプロイし、業務サーバーがインターネット経由でインスタンスに接続されている場合、ネットワーク遅延により Tair のパフォーマンスが大幅に低下します。 説明 クロスリージョンデプロイメントの場合、Redis グローバル分散キャッシュのクロスリージョンレプリケーション機能を使用して、ジオディザスタリカバリまたはアクティブ地理的冗長性を実装し、ネットワーク遅延を削減し、業務設計を簡素化できます。詳細については、「Redis グローバル分散キャッシュ」をご参照ください。 |
★★★★☆ | 各サービスに対して Tair インスタンスを作成します。 | 異なるサービスに 1 つの Tair インスタンスを使用しないでください。たとえば、高速キャッシュとインメモリデータベースサービスの両方に 1 つの Tair インスタンスを使用しないでください。そうしないと、あるサービスのエビクションポリシー、スロークエリ、および FLUSHDB コマンドの実行が他のサービスに影響を与えます。 |
★★★★☆ | 期限切れのキーをエビクションするために、適切なエビクションポリシーを設定します。 | Tair の期限切れキーに対するデフォルトのエビクションポリシーは volatile-lru です。エビクションポリシーの詳細については、「Community Edition インスタンスで設定可能なパラメーター」をご参照ください。 |
★★★☆☆ | ストレステストのデータと期間を管理します。 | Tair はストレステストのデータを削除しません。業務への影響を防ぐために、ストレステストのデータと期間を自分で管理する必要があります。 |
キー設計の標準
重要度 | 標準 | 説明 |
★★★★★ | キーの値を適切なサイズに設定します。キーに格納される値のサイズは 10 KB 未満に保つことをお勧めします。 | 値が大きすぎると、データスキュー、ホットキー、高帯域幅、または高い CPU 使用率を引き起こす可能性があります。キーの値が適切なサイズであることを確認することで、これらの問題を最初から防ぐことができます。 |
★★★★★ | 適切な長さの適切なキー名を設定します。 |
|
★★★★★ | サブキーをサポートする複雑なデータ構造の場合、1 つのキーに過剰なサブキーを含めないようにする必要があります。1 つのキーに含めるサブキーは 1,000 未満にすることをお勧めします。 説明 一般的な複雑なデータ構造には、Hash、Set、Zset、Geo、Stream、および Tair (Enterprise Edition) 固有の構造 (exHash、Bloom、TairGIS など) が含まれます。 | HGETALL などの特定のコマンドの時間計算量は、サブキーの数に直接関係します。時間計算量が O(N) 以上のコマンドを頻繁に実行し、キーにサブキーが多すぎる場合、スロークエリ、データスキュー、ホットキーなどの問題が発生します。 |
★★★★☆ | シリアル化メソッドを使用して、値を読み取り可能な構造に変換します。 | プログラミング言語のバイトコードは、言語のバージョンが変更されると変わる可能性があります。Tair インスタンスにネイキッドオブジェクト (Java オブジェクトや C# オブジェクトなど) を格納すると、ソフトウェアスタックのアップグレードが困難になる場合があります。シリアル化メソッドを使用して、値を読み取り可能な構造に変換することをお勧めします。 |
SDK 使用の標準
重要度 | 標準 | 説明 |
★★★★★ | JedisPool または JedisCluster を使用して Tair インスタンスに接続します。 説明 TairJedis クライアントは新しいデータ構造のためのカプセル化クラスを提供するため、Tair (Enterprise Edition) DRAM ベースのインスタンスに接続するには TairJedis クライアントを使用することをお勧めします。詳細については、「クライアントを使用してインスタンスに接続する」をご参照ください。 | 単一の接続を使用すると、接続がタイムアウトした後にクライアントは Tair インスタンスに自動的に再接続できません。JedisPool を使用して Tair インスタンスに接続する方法の詳細については、「クライアントを使用してインスタンスに接続する」、「JedisPool の最適化」、および「JedisCluster」をご参照ください。 |
★★★★☆ | クライアントに適切なフォールトトレランスメカニズムを設計します。 | ネットワークの変動やリソースの高使用率は、Tair で接続タイムアウトやスロークエリを引き起こす可能性があります。これらのリスクを防ぐために、クライアントに適切なフォールトトレランスメカニズムを設計する必要があります。 |
★★★★☆ | クライアントに長い再試行間隔を設定します。 | 再試行間隔が必要以上に短い (200 ミリ秒未満など) 場合、短時間で多くの再試行が発生する可能性があります。これにより、サービスアバランシェが発生する可能性があります。詳細については、「Redis クライアントの再試行メカニズム」をご参照ください。 |
コマンド使用の標準
重要度 | 標準 | 説明 |
★★★★★ | KEYS * コマンドの実行など、範囲クエリは避けてください。代わりに、複数のポイントクエリを使用するか、SCAN コマンドを実行してレイテンシを削減します。 | 範囲クエリは、サービス中断、スロークエリ、または輻輳を引き起こす可能性があります。 |
★★★★★ | 複雑な操作を実行するには、拡張データ構造を使用します。詳細については、「複数のデータモジュールの統合」をご参照ください。Lua スクリプトは使用しないでください。 | Lua スクリプトは大量の計算リソースとメモリリソースを消費し、マルチスレッドアクセラレーションをサポートしていません。過度に複雑または不適切な Lua スクリプトは、リソースの枯渇につながる可能性があります。 |
★★★★☆ | パイプラインを使用して、データの往復レイテンシ (RTT) を削減します。 | サーバーに複数のコマンドを送信したいが、クライアントがサーバーからの各応答に依存しない場合は、パイプラインを使用して一度にコマンドを送信できます。パイプラインを使用する際は、次の点に注意してください:
|
★★★★☆ | Redis コマンドを正しく使用します。 | トランザクションコマンドを使用する際は、次の制限に注意してください:
|
★★★★☆ | 多くのメッセージ配信タスクを実行するために Redis コマンドを使用しないでください。 | Pub/Sub コマンドグループは、データ永続化やデータ信頼性を保証する確認応答メカニズムをサポートしていません。多くのメッセージ配信タスクを実行するために Pub または Sub コマンドを使用しないことをお勧めします。たとえば、これらのコマンドを使用してサイズが 1 KB を超えるメッセージを 100 を超えるサブスクライバークライアントに配信すると、サーバーリソースが枯渇し、サブスクライバークライアントがメッセージを受信できない場合があります。 説明 パフォーマンスとバランスを向上させるために、Tair は Pub および Sub コマンドに最適化されています。クラスターインスタンスでは、プロキシノードがチャンネル名に基づいてコマンドのハッシュ値を計算し、対応するデータノードにコマンドを割り当てます。 |
運用保守管理の標準
重要度 | 標準 | 説明 |
★★★★★ | さまざまなインスタンス管理操作の影響を理解します。 | 設定の変更や再起動は、Tair インスタンスのステータスに影響します。たとえば、インスタンスで一時的な切断が発生する可能性があります。前述の操作を実行する前に、その影響を理解していることを確認してください。詳細については、「インスタンスの状態と影響」をご参照ください。 |
★★★★★ | クライアントのエラー処理能力またはディザスタリカバリロジックを検証します。 | Tair はノードのヘルスステータスを監視できます。インスタンスのマスターノードが利用できなくなった場合、Tair は自動的にマスター/レプリカスイッチオーバーをトリガーします。マスターノードとレプリカノードのロールが切り替わり、インスタンスの高可用性が確保されます。クライアントが一般提供される前に、手動でマスター/レプリカスイッチオーバーをトリガーすることをお勧めします。これにより、クライアントのエラー処理能力またはディザスタリカバリロジックを検証できます。詳細については、「マスターノードからレプリカノードへのワークロードの手動切り替え」をご参照ください。 |
★★★★★ | 時間のかかるコマンドや高リスクコマンドを無効にします。 | 本番環境では、コマンドの乱用が問題を引き起こす可能性があります。たとえば、FLUSHALL コマンドはすべてのデータを削除する可能性があります。KEYS コマンドはネットワーク輻輳を引き起こす可能性があります。サービスの安定性と効率を向上させるために、特定のリスクを最小限に抑えるために特定のコマンドを無効にすることができます。詳細については、「高リスクコマンドを無効にする」をご参照ください。 |
★★★★☆ | 未処理イベントはできるだけ早く処理します。 | ユーザーエクスペリエンスを向上させ、サービスのパフォーマンスと安定性を向上させるために、Alibaba Cloud は特定のサーバーのハードウェアとソフトウェアをアップグレードしたり、ネットワーク設備を交換したりするために、時々未処理イベントを生成します。たとえば、データベースのマイナーバージョンを更新する必要がある場合に未処理イベントが生成されます。Alibaba Cloud からイベント通知を受け取った後、イベントの影響を確認し、業務要件に合わせてイベントのスケジュール時間を変更できます。詳細については、「スケジュールされたイベントの表示と管理」をご参照ください。 |
★★★★☆ | インスタンスの状態をより良く監視するために、コアメトリックにアラートを設定します。 | CPU 使用率、メモリ使用量、帯域幅使用量などのコアメトリックにアラートを設定して、インスタンスの状態をリアルタイムで監視します。詳細については、「アラート設定」をご参照ください。 |
★★★★☆ | Tair が提供する運用保守機能を使用して、インスタンスの状態を定期的に確認したり、リソース使用量の例外をトラブルシューティングしたりします。 |
|
★★★☆☆ | 監査ログ機能を有効にし、監査ログを評価します。 | 監査ログ機能を有効にすると、書き込み操作に関する監査統計が記録されます。Tair では、監査ログのクエリ、オンライン分析、エクスポートも可能です。これらの機能は、Tair インスタンスのセキュリティとパフォーマンスを監視するのに役立ちます。詳細については、「監査ログ」をご参照ください。 重要 監査ログ機能を有効にすると、Tair インスタンスのパフォーマンスが 5% から 15% 低下する可能性があります。実際のパフォーマンス低下は、書き込み操作または監査操作の数によって異なります。業務で Tair インスタンスへの多くの書き込み操作が予想される場合は、トラブルシューティングなどの運用保守操作を実行するときにのみ監査ログ機能を有効にすることをお勧めします。これにより、パフォーマンスの低下を防ぐことができます。 |