【ITニュース解説】Three Layers Deep: Getting Confluent Schema Registry to Authenticate with MSK Serverless on EKS

このニュース記事は、Confluent Schema RegistryをAmazon EKS上にデプロイし、Amazon MSK Serverlessに接続しようとする際に遭遇する、認証に関する複雑な問題を深く掘り下げ、その解決策を解説したものだ。Schema Registry、EKS、MSK Serverlessという三つの異なる技術要素が連携する際、それぞれが持つ独自の「お作法」や設定の前提が衝突し、一筋縄ではいかない認証の問題が発生する。記事では、これら三つの技術の衝突を「三つのレイヤー」として捉え、それぞれのレイヤーで何が起こり、どのように解決したかを具体的に説明している。

まず、設定の全体像としては、EKSのバージョン1.31（Fargateマネージドノードグループを使用）、MSK Serverless（us-east-1リージョン）、Confluent Schema RegistryのDockerイメージバージョン7.5.0を基盤とし、IAMロールとKubernetesのサービスアカウントを連携させるIRSA (IAM Roles for Service Accounts) を使ってMSKのIAM認証を行う構成である。認証には、SASL/OAUTHBEARERという方式で、特別なJavaライブラリ（aws-msk-iam-auth-2.3.2-all.jar）を使用する必要がある。これら単体では問題ないものの、組み合わせると複雑な問題が起きるのがこの状況の難しい点であった。

第一のレイヤーで発生した問題は、KubernetesによるSchema Registryの設定への「毒入り」だ。症状としては、Schema RegistryのPodが起動直後にクラッシュし、ログには「SCHEMA_REGISTRY_PORTが有効なポート番号に設定されていない」というエラーが表示される。根本原因は、Kubernetesが同じ名前空間内の各サービスに対して、自動的にサービスディスカバリ用の環境変数を注入することにある。もし「schema-registry」という名前のサービスが存在すると、KubernetesはSCHEMA_REGISTRY_PORT=tcp://10.100.200.50:8081のような環境変数をPodに注入してしまう。Confluentの起動スクリプトは、SCHEMA_REGISTRY_というプレフィックスを持つすべての環境変数をSchema Registryの設定ファイルにマッピングする。その結果、port=tcp://10.100.200.50:8081という、ポート番号としては無効な値が設定されてしまい、Schema Registryがクラッシュするのだ。この問題の解決策は、Podの仕様（spec）にenableServiceLinks: falseを追加することであった。これにより、Kubernetesはサービスディスカバリによる環境変数の注入をスキップし、Schema Registryの起動が正常に行われるようになる。この設定は、KafkaブローカーのPodなど、Confluentの他のイメージでも同様に必要となる場合が多い。

第二のレイヤーでの問題は、MSK IAM認証に必要なJavaライブラリがJava仮想マシン（JVM）に認識されないことであった。症状としては、Schema Registryは起動するものの、すぐにMSK Serverlessへの接続に失敗する。エラーメッセージはSSLハンドシェイクの失敗を示したり、MSK Serverlessが要求するSASL/OAUTHBEARER認証ではなく、PLAINTEXT/SSL認証をサイレントに再試行してしまう場合もある。根本原因は、MSK ServerlessがIAM認証（SASL/OAUTHBEARER）のみをサポートしているにもかかわらず、Confluentの標準Dockerイメージには認証に必要なaws-msk-iam-auth.jarが含まれていないことだ。さらに、このJARファイルをコンテナに配置し、CLASSPATH環境変数で指定しても、Confluentの起動スクリプトがJavaコマンドを直接呼び出し、独自のクラスパス設定を行うため、設定したCLASSPATHが無視されてしまうという問題があった。この解決策は、ベースとなるConfluent Dockerイメージにカスタムの変更を加えることである。具体的には、カスタムDockerイメージを作成し、必要なaws-msk-iam-auth.jarファイルを、Confluentのスクリプトが自動的にJVMクラスパスに追加する特定のディレクトリ（/usr/share/java/schema-registry/）に直接追加する。これにより、JARファイルが適切に読み込まれる。その後、Schema Registryの環境変数で、ブートストラップサーバー、セキュリティプロトコル（SASL_SSL）、SASLメカニズム（AWS_MSK_IAM）、JAAS設定、そしてSASLクライアントコールバックハンドラクラス（software.amazon.msk.auth.iam.IAMClientCallbackHandler）を正確に設定する必要がある。

第三のレイヤーでの問題は、Schema Registryの起動前に行われるプリフライトチェックが失敗することであった。症状としては、Podが起動し、JARファイルのロードも成功するものの、数分間ハングアップした後、接続エラーで失敗するか、Confluentのensureスクリプトから不明瞭なエラーが出力される。根本原因は、Confluent Dockerイメージに含まれる/etc/confluent/docker/ensureというプリフライトスクリプトが、Schema Registry本体の起動前にKafkaへの接続性を検証しようとすることだ。EKS環境では、IRSAによるIAM認証情報が、このensureスクリプトが実行される時点ではまだ完全に利用可能になっていない場合がある。あるいは、ensureスクリプトがIAM認証コールバックハンドラを正しく認識できないコードパスを使用している可能性も考えられる。この問題の解決策は、KubernetesのConfigMapとボリュームマウント機能を使って、このensureスクリプトを「何もしない」スクリプトで上書きすることであった。具体的には、ConfigMapに空のbashスクリプトを定義し、それをPodの/etc/confluent/docker/ensureパスにマウントする。これにより、プリフライトチェックがスキップされ、Schema Registry本体が起動してから、適切なリトライロジックでMSK Serverlessへの接続を試みることができるようになる。これは安全性の損失には繋がらない。なぜなら、Schema Registry自体が起動後に接続をリトライする機能を持っているため、事前に厳密なチェックができなかったとしても、最終的には接続が確立されるからである。

これらの三つのレイヤーの問題を解決することで、Confluent Schema RegistryはEKS上で正常に起動し、MSK Serverlessに対してIRSAとIAM認証を使って安全に接続できるようになった。記事の作者は、カスタムDockerイメージの作成方法や、KubernetesのDeploymentマニフェストの最終的な形も示しており、これらの解決策がどのように統合されるかを示している。

今回の問題がなぜ見つけにくかったのかという点にも言及している。第一のレイヤーでは、エラーメッセージはポート番号の不正を指摘するだけで、Kubernetesのサービスディスカバリが原因であることには触れない。第二のレイヤーでは、CLASSPATH環境変数が機能するはずだと誰もが考えるが、Confluentがそれを無視するという仕様は文書化されていないため、発見が難しい。第三のレイヤーでは、ensureスクリプトの失敗が単なる接続エラーのように見えるため、IRSA認証情報がまだ準備できていないという根本原因が隠されてしまう。

このような事例から得られる教訓は、サードパーティのコンテナイメージ、マネージドクラウドサービス、そしてコンテナオーケストレーターという異なる技術スタックを組み合わせる際には、それぞれが持つ独自の「暗黙の前提」や「お作法」が衝突し、予想外の問題が発生しやすいということだ。エラーメッセージはしばしば表面的な現象しか示さず、根本原因を特定するには、各技術の内部動作を深く理解し、それぞれのレイヤーで何が起こっているのかを一つずつ丁寧に解き明かしていくデバッグプロセスが必要となる。この経験は、複雑なシステム連携を構築するシステムエンジニアにとって、非常に貴重な知見となるだろう。