ALB「証明書100問題」からの脱却：Caddy on Kubernetesによるスケーラブルな独自ドメイン基盤の構築 by 無双

■ 発表カテゴリ
・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）
ホームページ作成サービスなどで提供される「独自ドメイン提供」機能。当サービスではお客様の増加に伴い、ALBのSSL証明書上限が成長を妨げる「証明書100問題」に突き当たりました。
本セッションでは、このスケーラビリティ課題に対し、CaddyとKubernetesを用いて証明書管理を自動化する新アーキテクチャへ移行した事例をお話しします。技術選定のリアルな過程に加え、複雑な顧客向け案内を単一のAレコード設定に統一し、運用トイルを劇的に削減した方法を共有します。AWSのサービス上限と向き合い、事業の成長を支えるアーキテクチャを模索するSREや開発者へ、私たちの試行錯誤から得られた実践的な知見を提供します。

■ 発表の詳細（1000字程度）

1. はじめに：SaaSの成長を阻んだ「証明書100問題」
   私達が開発するSaaSでは、お客様が独自のドメインを設定できる機能を提供しています。当初、AWS ALBを用いてこの機能を実現していましたが、サービスの成長に伴い「1ALBあたり100個まで」というSSL証明書の上限がスケーラビリティのボトルネックとなりました。これが「証明書100問題」です。
   また、旧来の証明書発行プロセスでは、お客様に2種類のDNSレコード登録を依頼するか、DNS権限を委譲いただくという2つの複雑な運用パターンが存在し、サポート部門とお客様双方の大きな負担（トイル）となっていました。

2. アーキテクチャによる解決と意思決定プロセス
   この問題を解決するため、私達はALBの前段に証明書管理をオフロードするプロキシ層を設ける決断をしました。
   最終的に採用した以下の新アーキテクチャについて、その詳細と意思決定の背景を解説します。

外部NLB(EIP) → Caddy(k8s) → 内部NLB → ALB → App

なぜこのような選択をしたのか。これらのリアルな思考プロセスを共有します。

3. インパクト：トイル撲滅と顧客体験の向上
   新アーキテクチャへの移行は、単なる技術課題の解決に留まりませんでした。
   フロントのNLBに固定IPを割り当てたことで、お客様への案内は「Aレコードを登録するだけ」という単一のシンプルなものに統一されました。これにより、サポート部門の運用トイルは劇的に削減され、お客様は自身のタイミングで自由にDNSを管理できるようになりました。
   本発表では、この技術的改善が、いかにしてビジネス価値と顧客満足度の向上に直結したかを、具体的な事例を交えてお話しします。

■ 対象聴衆とその人たちが得られるもの
対象聴衆

• SaaSのバックエンドやプラットフォームを開発・運用するSRE、ソフトウェアエンジニア
• AWS上でマルチテナントサービスを構築しているアーキテクト
• 技術的な制約に対し、アーキテクチャの工夫で立ち向かっているエンジニア

得られるもの

• AWSにおける、大量の独自ドメインを扱うための実践的なアーキテクチャパターン
• CaddyとKubernetesを活用した証明書管理の自動化ノウハウと注意点
• 技術的改善を、運用トイル削減と顧客体験向上というビジネス価値に繋げるための考え方

■ なぜこのトピックについて話したいのか（モチベーション）
私たちが直面した「証明書100問題」は、AWSの特定サービスが持つ上限が事業のスケールを阻害する典型的な一例です。ユーザーに独自ドメインを提供するSaaSはもちろんのこと、AWS上でマルチテナントサービスを開発する多くのエンジニアが、たとえそれが証明書でなくとも、何らかの「上限問題」に直面する可能性があります。私たちの失敗談や試行錯誤の過程を含めたリアルな経験を共有することで、同じようなスケーラビリティ課題に悩むコミュニティの仲間たちの助けとなり、議論のきっかけになればと強く願っています。