ApsaraMQ for Kafka:インスタンスに関するよくある質問

ApsaraMQ for Kafka インスタンスへのインターネット経由でのアクセス

はい。インターネットおよび VPC 接続インスタンスは、インターネットアクセスをサポートしています。

VPC タイプのインスタンスがあり、インターネットアクセスが必要な場合は、[インスタンス詳細] ページで [アップグレード] をクリックし、ネットワークタイプを [インターネットおよび VPC] に変更します。 詳細については、「インスタンスのスペックアップ」をご参照ください。

異なる VPC 内のインスタンスを接続できますか？

はい。Cloud Enterprise Network (CEN) または VPN Gateway を使用して、異なる VPC 間で ApsaraMQ for Kafka インスタンスを接続できます。

CEN は自動ルート配布を使用し、同一または異なる Alibaba Cloud アカウント配下の VPC をサポートします。

VPN Gateway は、VPC 間でルートベースの IPsec 接続を確立します。設定手順については、「2 つの VPC 間で IPsec 接続を確立する」をご参照ください。

異なるゾーンにある ApsaraMQ for Kafka インスタンスへの ECS インスタンスからの接続

はい。Elastic Compute Service (ECS) インスタンスと ApsaraMQ for Kafka インスタンスが同一 VPC 内にあれば、異なるゾーンにあってもプライベートネットワーク経由で通信できます。追加のネットワーク設定は不要です。

接続する前に、以下を確認してください。

• 同一 VPC：ECS インスタンスと ApsaraMQ for Kafka インスタンスの両方が同じ VPC 内にあること

• ホワイトリスト：ECS インスタンスは ApsaraMQ for Kafka インスタンスのホワイトリストに追加されています。詳細については、「ホワイトリストを設定する」をご参照ください。

インスタンスが異なる VPC にある場合は、どちらか一方を再デプロイして、両方が同じ VPC 内に配置されるようにしてください。

ApsaraMQ for Kafka でプロキシアクセスが機能しない理由

Kafka クライアントは、2 段階でブローカーに接続します。

1. クライアントは bootstrap.servers リストを介して接続し、クラスターのメタデータを取得します。

2. クライアントはそのメタデータからブローカーの IP アドレスを使用して、メッセージを送受信します。

プロキシは最初のメタデータリクエストを転送できますが、メタデータにはブローカーの直接の IP アドレスが含まれています。その後、クライアントはメッセージトラフィックのためにこれらの IP に接続しようとし、プロキシを完全にバイパスします。これは設定の問題ではなく、Kafka プロトコルの制限です。

代替方法: オンプレミスデータセンターから ApsaraMQ for Kafka インスタンスにアクセスするには、Express Connect 回線を使用します。これにより、ブローカーの IP アドレスへの専用の物理接続および完全なネットワーク接続が提供されます。詳しくは、「Express Connect 回線経由の接続とは？」をご参照ください。

インスタンスのデプロイに必要な VPC 情報の取得方法

1. VPC コンソールにログインします。

2. 左側のナビゲーションウィンドウで、[vSwitch] をクリックします。

3. [vSwitch] ページで、次の値をメモします。

   • vSwitch ID

   • VPC ID

   • ゾーン

クラシックネットワークでは、172.16.0.0/12 CIDR ブロックを使用する必要がありますか？

いいえ。ただし、172.16.0.0/12 を使用すると、最もシンプルな構成になります。その他の CIDR ブロック オプションについては、「VPC の概要」をご参照ください。

インスタンスエディションの選択方法

ApsaraMQ for Kafka は、非サーバーレスインスタンスとサーバーレスインスタンスを提供しており、それぞれに Standard Edition と Professional Edition があります。

• Standard Edition (高書き込み)：3 レプリカの分散ストレージを備えたクラウドストレージを使用します。書き込みスループットを優先するほとんどのワークロードに最適です。ログコンパクションやパーティション順序付きメッセージが必要な場合を除き、このエディションを使用してください。

• Professional Edition (高書き込み / 高読み取り)：クラウドストレージとローカル記憶域の両方をサポートします。ログコンパクションやパーティション順序付きメッセージが必要な場合は、ローカル記憶域を選択してください。

• サーバーレス：ディスクのプロビジョニングは不要です。ストレージは 1 日から 365 日まで設定可能な保存期間で自動的にスケーリングします。保存期間を 365 日を超えて延長するには、チケットを送信してください。

サイジングガイドライン

課金詳細については、「インスタンスエディションのサブスクリプションまたは従量課金ルール」をご参照ください。

インスタンスのリリース方法

サブスクリプションインスタンス: ApsaraMQ for Kafka コンソールから [実行中] 状態のインスタンスを解約します。「インスタンスのライフサイクルを管理する」をご参照ください。

従量課金インスタンス: ApsaraMQ for Kafka コンソールから、[実行中] 状態のインスタンスを停止します。詳しくは、「インスタンスのライフサイクルを管理する」をご参照ください。

期限切れインスタンスの復元方法

サブスクリプションインスタンス

期限切れの原因：インスタンスの登録が解除されたか、サブスクリプションが更新されなかった場合。

有効期限切れ後7日以内に、ApsaraMQ for Kafka コンソールからインスタンスを更新してください。更新後、インスタンスステータスは [実行中] に変化します。この期間内に更新されなかった場合、インスタンスは自動的にリリースされ、復元できません。詳細については、「インスタンスの更新」をご参照ください。

従量課金インスタンス

期限切れの原因：インスタンスが停止されたか、Alibaba Cloud アカウントに支払い遅延がある場合。

• インスタンスが停止している場合は、コンソールで再度有効にします。詳細については、「インスタンスのライフサイクルを管理する」をご参照ください。

• 支払い遅延がある場合は、アカウントにチャージしてください。

インスタンスのリージョンを変更できない理由

インスタンスのリージョンは物理リソースに紐づけられており、デプロイ後に変更することはできません。別のリージョンに移動するには、現在のインスタンスをリリースし、新しいインスタンスを購入してください。

サポートされている Apache Kafka クライアントのバージョン

ApsaraMQ for Kafka は、バージョン 0.11 から 3.x までのオープンソース Apache Kafka クライアントをサポートしています。クライアントのバージョンを、[インスタンス詳細] ページに表示される ApsaraMQ for Kafka インスタンスのメジャーバージョンに合わせてください。

遅延メッセージのサポート

いいえ。ApsaraMQ for Kafka は、オープンソースの Apache Kafka と同様に、遅延メッセージをサポートしていません。

データ圧縮のサポート

はい。ApsaraMQ for Kafka ブローカーは、圧縮されたデータの送受信が可能です。圧縮パラメーターはクライアント側で設定してください。

ブローカーのアップグレード中に発生すること

アップグレード中 (通常、合計 5～15 分) には、次のことが予想されます。

• ローリング再起動：ブローカーは 1 つずつ再起動します。サービスは中断されませんが、各ブローカーの再起動後 5 分以内に消費されたメッセージは、一部のパーティションで順序が乱れる可能性があります。サーバーレスの ApsaraMQ for Kafka および ApsaraMQ for Confluent インスタンスは、アップグレード中に Apache Kafka のセマンティクスに完全に準拠します。

• 短時間の中断：再起動中のブローカーに接続しているクライアントは切断される可能性があります。自動再接続をサポートするクライアントは、介入なしで回復します。

• 不均一なトラフィック分散：アップグレード中に、パーティション間でメッセージトラフィックが一時的に不均衡になる可能性があります。

• IP 変更の可能性：ブローカーの IP アドレスが変更される可能性があります。ハードコーディングされた IP アドレスではなく、常にドメイン名を使用して接続してください。

複数のインスタンスをお持ちの場合は、まずテストクラスターをアップグレードし、結果を確認してから本番環境をアップグレードしてください。

インスタンスのアップグレードに時間がかかる理由

一般的な原因は 3 つあります。

1. インフラストラクチャリソースの不足：アップグレードには追加の ECS インスタンスとクラウドディスクが必要です。これらのリソースがご利用のリージョンまたはゾーンで利用できない場合、容量が補充されるまでアップグレードは一時停止します。

2. 同時アップグレード：プラットフォーム全体で複数のアップグレードタスクが共有インフラストラクチャを競合するため、個々のアップグレードが遅くなります。

3. 蓄積されたバージョンギャップ：インスタンスが長期間アップグレードされていない場合、複数の更新が順次実行される必要があります。

アップグレードに時間がかかるのを防ぐには、複数のバージョンを蓄積させるのではなく、定期的にバージョンアップグレードを適用してください。

古いメッセージが削除されるタイミング

ApsaraMQ for Kafka は、ディスク容量不足によるサーバーの問題を防ぐために、ディスク使用率に基づいて異なるクリーンアップポリシーを適用します。

クラウドストレージ Topic を持つ非サーバーレスインスタンス

ローカル記憶域 Topic を持つ非サーバーレスインスタンス

サーバーレスインスタンス

設定された TTL に基づいてメッセージが削除されます。

関連ドキュメント：

• 期限切れのメッセージが削除されない理由

• ディスク容量を追加するには、「インスタンス構成のスペックアップ」をご参照ください。

保存期間を過ぎても期限切れのメッセージが表示される理由

一般的な理由は 2 つあります。

1. メッセージセグメントが 1 GB に達していない。メッセージは最大 1 GB のセグメントに保存されます。システムは個々のメッセージではなく、セグメント全体を削除します。セグメントが 1 GB に達していない場合、その中のメッセージは保存期間を超えても保持されます。

2. ディスク使用率が 75% 未満で、毎日のクリーンアップがまだ実行されていない。ディスク使用率が 75% 未満の場合、期限切れのメッセージは毎日 04:00 に削除されます。そのスケジュールされたクリーンアップが実行されるまで、期限切れのメッセージはクエリ可能なままです。

[作成日時] 列のタイムスタンプがクエリ時間とずれる理由

[メッセージクエリ] ページで時刻を指定してメッセージをクエリすると、[作成日時] の値が指定した時刻と大幅にずれたり、null として表示されたりすることがあります。

タイムスタンプのずれ：クエリ時間がパーティション内の最も古いメッセージより前、または最も新しいメッセージより後である場合。コンシューマオフセットがリセットされ、表示されるタイムスタンプは最新のオフセット周辺に集中します。

null タイムスタンプ：クライアントのバージョンがメッセージの時間属性をサポートしていない場合。クライアントをバージョン 0.10.2 以降に更新してください。バージョン 2.4.0 を推奨します。

ApsaraMQ for Kafka ブローカーが正常に動作していることを確認する方法

インスタンスをデプロイした後 (ステータス：[実行中])、コンソールからテストメッセージを送信して、ブローカーが機能していることを確認します。

1. Topic の作成

   1. ApsaraMQ for Kafka コンソールにログインします。

   2. [概要] ページの [リソース配布] セクションで、インスタンスが存在するリージョンを選択します。

      重要

      ECS インスタンスと同じリージョンに Topic を作成してください。Topic はリージョンをまたいで使用することはできません。

   3. [インスタンス] ページで、インスタンス名をクリックします。

   4. 左側のナビゲーションウィンドウで、[Topics] をクリックします。

   5. [Topic の作成] をクリックし、次のパラメーターを設定します。| パラメーター | 説明 | 例 | |-----------|-------------|---------| | Topic 名 | Topic の名前 | demo | | 説明 | Topic の説明 | demo test | | パーティション数 | パーティションの数 | 12 | | ストレージエンジン | [クラウドストレージ] (3 レプリカ分散、低レイテンシー、高信頼性) または [ローカル記憶域] (ISR アルゴリズム、3 レプリカ分散)。Standard (高書き込み) インスタンスは [クラウドストレージ] のみをサポートします。| [クラウドストレージ] | | メッセージタイプ | [通常メッセージ] (クラウドストレージのデフォルト) または [パーティション順序付きメッセージ] (ローカル記憶域のデフォルト)。通常メッセージはブローカーに障害が発生すると順序が失われる可能性があります。パーティション順序付きメッセージは順序を維持しますが、回復中に一部のパーティションが遅延する可能性があります。| [通常メッセージ] | | ログクリーンアップポリシー | Professional Edition インスタンスの [ローカル記憶域] でのみ利用可能です。[削除] は保存期間に基づいてメッセージを保持し、使用率が 85% を超えると最も古いメッセージをパージします。[コンパクション] はキーごとに最新の値のみを保持し、Kafka Connect および Confluent Schema Registry で使用されます。| [コンパクション] | | タグ | Topic にアタッチするタグ | demo |

2. メッセージの送信

   1. [Topics] ページで、Topic 名をクリックします。[Topic 詳細] ページの右上隅にある [メッセージ送信] をクリックします。

   2. [メッセージの送受信を開始] パネルで、送信方法を選択します。

      • コンソール：[メッセージキー] (例：demo) と [メッセージ本文] (例：{"key": "test"}) を入力します。オプションで [指定したパーティションに送信] を有効にし、[パーティション ID] (例：0) を入力します。

      • Docker：パネルに表示される Docker コマンドを実行して、メッセージを送受信します。

      • SDK：ご利用の言語またはフレームワークの SDK を選択し、指示に従ってメッセージを送受信します。

3. パーティションステータスの表示 [Topics] ページで、Topic 名をクリックします。[Topic 詳細] ページの [パーティションステータス] タブをクリックします。

   パラメーター	説明
   パーティション ID	パーティションの識別子
   最小オフセット	パーティション内の最も早いオフセット
   最大オフセット	パーティション内の最新のオフセット
   メッセージ	パーティション内のメッセージ数
   最終更新日時	最新メッセージのタイムスタンプ

4. オフセットによるメッセージのクエリ

   1. ApsaraMQ for Kafka コンソールにログインします。

   2. [概要] ページの [リソース配布] セクションで、インスタンスのリージョンを選択します。

   3. [インスタンス] ページで、インスタンス名をクリックします。

   4. 左側のナビゲーションウィンドウで、[メッセージクエリ] をクリックします。

   5. [検索方法] ドロップダウンリストから [オフセットで検索] を選択します。

   6. Topic を選択し、パーティションを選択し、オフセット値を入力して [検索] をクリックします。指定された値以上のオフセットを持つメッセージが返されます。たとえば、パーティション 5 とオフセット 5 を選択すると、パーティション 5 のオフセット 5 以降のすべてのメッセージが返されます。

   パラメーター	説明
   パーティション	メッセージが取得されたパーティション
   オフセット	メッセージのオフセット
   キー	メッセージキー (文字列として表示)
   値	メッセージ本文 (文字列として表示)
   作成日時	メッセージが送信されたときのタイムスタンプです。これは、クライアントが記録したタイムスタンプか、ProducerRecord のタイムスタンプフィールドで指定された値です。1970/x/x のタイムスタンプは、フィールドが 0 または無効な値に設定されたことを示します。バージョン 0.9 以前のクライアントでは、このフィールドを設定できません。
   操作	[キーのダウンロード] または [値のダウンロード]。メッセージごとに最大 1 KB のコンテンツが表示されます。完全なコンテンツを表示するには、メッセージをダウンロードしてください。ダウンロードは一度に 10 MB に制限されています。

ステップ 2 から 4 を複数回繰り返します。すべてのステップが成功した場合、ブローカーは期待どおりに動作しています。