【ITニュース解説】Configuring domain networking for scalable container services.

コンテナ化されたサービスを大規模に展開する上で、ドメインを使ったネットワーク設定は非常に重要になる。この記事では、その理由と具体的な設定方法について解説する。

まず、コンテナのネットワークに関する基礎知識を確認する。コンテナは一時的なもので、IPアドレスが動的に変わることが多い。そこで、KubernetesやDocker Swarmといったコンテナオーケストレーションツールが、コンテナのライフサイクルを管理し、内部DNS機能を提供する。これにより、コンテナはIPアドレスではなく、database-serviceやapi-serviceのような名前で互いを認識し、通信できるようになる。

コンテナオーケストレーション環境における内部DNSは、サービス間の通信を支える基盤となる。Kubernetesではkube-dnsやCoreDNS、Docker Swarmでは組み込みのDNSリゾルバーが使われる。サービスを定義すると、オーケストレーションツールはその名前と関連するPodやコンテナを内部DNSに登録する。たとえば、PHPアプリケーションがMySQLデータベースに接続する場合、データベースのIPアドレスを知らなくても、mysql-serviceのような名前で接続できる。これにより、データベースのPodが再起動してIPアドレスが変わっても、アプリケーションは同じ名前で接続を維持できる。

内部DNSはクラスタ内での通信を扱うが、外部からのアクセスには外部ドメインネットワークが必要になる。クラウドプロバイダーが提供するロードバランサー（AWSのApplication Load Balancer、Google CloudのCloud Load Balancer、AzureのApplication Gatewayなど）は、外部ユーザーがアクセスできる安定したIPアドレスまたはホスト名を提供する。ロードバランサーは、受信トラフィックをコンテナ化されたサービスの複数のインスタンスに分散し、高可用性とスケーラビリティを確保する。

Kubernetesでは、HTTP/HTTPSトラフィックのためにIngressコントローラー（NGINX Ingress、Traefik、AWS ALB Ingress Controllerなど）がリバースプロキシとして機能する。Ingressコントローラーは、ドメイン名とURLパスに基づいて、外部トラフィックを適切な内部サービスにルーティングする。例えば、api.yourdomain.comはAPIサービスに、frontend.yourdomain.comはユーザーインターフェースにルーティングできる。IngressコントローラーはTLS終端も処理し、アプリケーションコンテナからSSL暗号化の負荷を軽減する。

サービスをドメイン名で解決できるようにするには、パブリックDNSプロバイダーを通じて外部DNSレコードを管理する必要がある。信頼性の高いDNSサービス（AWS Route 53、Cloudflare、Google Cloud DNSなど）を使用し、Aレコードを作成してドメイン名（api.yourcompany.comなど）をロードバランサーまたはIngressコントローラーのパブリックIPアドレスに直接マッピングする。ロードバランサーがホスト名を提供する場合は、CNAMEレコードを使用してドメインをそのホスト名にポイントする。DNSレコードのTTL（Time-To-Live）値を適切に設定する。短いTTLはDNS変更の迅速な伝播を可能にし、デプロイメントやインシデント対応に役立つ。長いTTLはDNSクエリの負荷を軽減するが、更新が遅れる。

すべてのサービスがパブリックにアクセス可能である必要はない。データベース、内部API、管理ツールなどは、プライベートに保つべき場合が多い。クラウドプロバイダーは、プライベートDNSソリューション（AWS Route 53 Private Hosted Zones、Azure Private DNS Zones、Google Cloud DNSプライベートゾーンなど）を提供している。これらのゾーンを使用すると、Virtual Private Cloud（VPC）またはVirtual Network内でのみ解決可能なカスタムドメイン名を定義できる。プライベートDNSを使用することで、内部サービスをインターネットに公開せずに、database.internal.company.comのようなフレンドリーなドメイン名でアドレス指定できる。これにより、セキュリティが強化され、他の内部アプリケーションの構成が簡素化される。VPC内のコンテナは、VPCのデフォルトDNSリゾルバーを介してこれらの名前を解決できる。

ドメインネットワークは、セキュリティ体制においても重要な役割を果たす。TLS証明書を使用して、すべての外部トラフィックにHTTPSを実装する。IngressコントローラーがTLS終端を処理するか、ロードバランサーを構成して処理できるようにする。重要なサービス間の通信にはmTLSを検討する。ネットワークポリシー（Kubernetes）またはセキュリティグループ（クラウドプロバイダー）を利用して、サービス間のトラフィックを制限する。この「最小特権」アプローチにより、承認されたサービスのみが相互に通信でき、侵害が発生した場合の影響範囲を制限する。クラウドドメインネットワークのファイアウォールルールを構成して、ロードバランサーとコンテナホストへの必要なインバウンドおよびアウトバウンドトラフィックのみを許可する。

サービス、ドメイン、DNSレコードに明確な命名規則を確立する。一貫性により混乱が軽減される。digやnslookupなどのツールを使用して、さまざまなポイントからDNS解決を定期的にチェックし、レコードが正しく伝播されていることを確認する。TerraformやCloudFormationなどのInfrastructure as Codeツールを使用して、すべてのDNSレコードとネットワーク構成を管理する。これにより、バージョン管理、監査可能性、および一貫したデプロイメントが保証される。サービスメッシュは高度なトラフィック管理を提供するが、最初は基本的なロードバランシングとIngressから始める。詳細なトラフィックルーティングや高度な可観測性などの機能が複雑になった場合にのみ、サービスメッシュを導入する。サービスの移行またはIPアドレスの変更を計画する場合は、移行中のダウンタイムを最小限に抑えるために、関連するDNSレコードのTTLを一時的に短縮する。ドメイン戦略、内部サービス名、および外部DNSレコードの明確なドキュメントを維持する。

効果的なドメインネットワークの構成は、スケーラブルなコンテナサービスにとって不可欠である。オーケストレーターの内部DNSを活用して、堅牢なサービス間通信を実現する。外部ロードバランサーとIngressコントローラーを使用して、ドメイン名でアプリケーションを公開する。外部DNSレコードを注意深く管理し、安全な内部専用サービスにはプライベートDNSゾーンを使用する。TLS暗号化を強制し、ネットワークポリシーでトラフィックを制限することにより、セキュリティを優先する。