LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

Traefikとは何か

Traefikとは、DockerやKubernetesなどのインフラを継続的に検査し、どのサービスがどのリクエストを処理するかを自動的に見つけ出すクラウドネイティブなリバースプロキシ／ロードバランサーを指します^*1。設定ファイルを固定的に書き込むのではなく、稼働中のコンテナやクラスターの状態そのものを設定の入力源として扱う点が特徴です。

Traefikはシステムに代わってリクエストを受け取り、どのコンポーネントが処理すべきかを識別し、そのサービスへ適切に転送する役割を担います^*1。この検知はリアルタイムで継続されるため、コンテナの再起動やスケールアウトが発生してもプロキシ側の設定を手動で書き直す必要がありません。

Traefikとは、リバースプロキシ・ロードバランサーの機能を核に、サービスディスカバリとルーティングから段階的にAPI管理やAPIゲートウェイ機能まで拡張できるアプリケーションプロキシである、と公式ドキュメントは位置づけています^*1。中小規模の単一サーバー構成から、複数クラウドをまたぐハイブリッド環境まで、同じ設計思想で運用できる点が採用の起点になります。

エントリポイント・ルーター・サービスの仕組み

Traefikはエントリポイント（EntryPoints）、ルーター（Routers）、サービス（Services）、ミドルウェア（Middlewares）という4つの概念を基本単位として構成されます^*2。この構造を理解すると、動的に生成される設定の中身を追いやすくなります。

エントリポイントは、Traefikへのネットワーク上の入り口であり、どのポートでパケットを受け取り、TCPかUDPのどちらで待ち受けるかを定義します^*2。ルーターは受信したリクエストをルールに基づいて解析し、条件が一致した場合に設定済みのミドルウェアを経由させてから適切なサービスへ転送する役割を担います^*2。

サービスは、実際にリクエストを処理するバックエンドへどう到達するかを設定する部分です^*2。1つのコンテナ・アプリケーションを指す場合もあれば、複数のインスタンスに振り分けるロードバランシング対象を指す場合もあります。

ミドルウェアで実現する認証・制限・リダイレクト

ミドルウェアとは、ルーターに付随してリクエストやレスポンスをバックエンドに送る前に加工する仕組みです^*2。ルールが一致した場合にのみ効果を発揮し、宣言した順序どおりに適用されます^*2。

認証系ではBasicAuth（Basic認証の付与）・DigestAuth（ダイジェスト認証）・ForwardAuth（認証処理を外部サービスへ委譲）が用意されています^*3。アクセス制御ではIPAllowList（許可するクライアントIPの制限）が使えます^*3。

負荷対策としてはRateLimit（呼び出し頻度の制限）とInFlightReq（同時接続数の制限）があり、エラー時にはRetry（自動再試行）を組み合わせられます^*3。リダイレクトはRedirectScheme（スキームに基づく転送、HTTPからHTTPSへの強制など）とRedirectRegex（正規表現による転送）で実装します^*3。これらは1つのルーターに対して複数を鎖状につなぐチェーン構成が可能なため、認証・制限・リダイレクトを組み合わせた入口の制御を1か所に集約できます。

サービスディスカバリでラベルからルーティングを自動化

サービスディスカバリの核となるのがプロバイダー（Providers）です。Traefikは動的設定をプロバイダーから取得し、オーケストレーターやサービスレジストリ、あるいは設定ファイルそのものがプロバイダーとして機能します^*4。静的設定は起動時にプロバイダーへの接続とエントリポイントを定義するだけの役割で、実際のルーティングを決めるのは動的設定側です^*4。動的設定はリクエストの中断なしにホットリロードされる点が要になります^*4。

Dockerプロバイダーでは、コンテナに付与したラベルを監視することでルーティング設定を自動的に取得します^*5。exposedByDefaultをfalseに設定すると、traefik.enable=trueラベルを持たないコンテナは無視され、明示的に有効化したコンテナだけが公開対象になります^*5。ラベル未指定時に適用する既定ルールはdefaultRuleで定義でき、Goのテンプレート構文を使って柔軟に変更できます^*5。

例えば「traefik.http.routers.my-container.rule=Host(`example.com`)」というラベルをdocker-compose.ymlに1行加えるだけで、そのコンテナへのルーティングルールが動的設定に反映されます^*5。公開ポートが単一であれば自動選択され、複数ある場合は最小のポート番号が使われます^*5。設定ファイルを介さずにコンテナ側の宣言だけでルーティングを増減できるため、サービスの追加・撤去が頻繁な環境ほど運用負荷の差が大きくなります。

Let’s Encrypt連携による証明書自動化

TraefikはcertificatesResolversという設定セクションでACME（Automatic Certificate Management Environment）を用いた証明書の取得・更新を担います^*6。メールアドレスや証明書の保存先ストレージなどを指定するだけで、Let’s Encryptとの通信から証明書の適用までを一連の流れとして扱えます。

証明書の有効期限は自動で追跡され、既定では90日間の証明書について失効30日前から更新処理が始まります^*6。証明書の有効期間そのものが異なる認証局を使う場合はcertificatesDurationオプションで期間を調整できます^*6。

チャレンジ方式は3種類あります。HTTP-01チャレンジはポート80でLet’s Encryptと通信し、HTTPSへのリダイレクトとの併用も可能です^*6。TLS-ALPN-01チャレンジはポート443での通信が必要になります^*6。DNS-01チャレンジはDNSレコードのプロビジョニングによる認証方式で、ワイルドカード証明書を取得できる方式はこのDNS-01チャレンジに限られ、Legoライブラリを介して複数のDNSプロバイダーに対応します^*6。

なお、Kubernetes環境でTraefikを複数インスタンス構成にする場合、チャレンジリクエストを常に同じインスタンスで受け取れる保証がないため、複数インスタンス展開は推奨されていません^*6。この場合はcert-manager等の外部ツールで証明書管理を切り離す構成が案内されています^*6。

Nginx等の静的設定型プロキシとの違い

Nginxのような静的設定型のプロキシは、設定ファイルを書き換えてからプロセスをリロードする運用が前提になります。サービスの追加や証明書の更新のたびに、設定ファイルの編集と反映作業を人手または別途のスクリプトで行う必要があります。

Traefikの動的設定は、稼働中のコンテナやKubernetesリソースの状態を継続的に監視し、リクエストを中断せずにホットリロードする点が異なります^*4。ルーティングルールの変更源がラベルやリソースの宣言に一本化されるため、プロキシ側の設定ファイルを直接編集する機会そのものが減ります。

Kubernetes Ingress Controllerとしての利用

Traefikとは、Kubernetes環境ではIngress Controllerとしても稼働できるリバースプロキシです。KubernetesのIngress providerはIngress仕様をサポートすることでクラスターサービスへのアクセスを管理します^*7。設定はproviders.kubernetesIngressを有効化するだけで開始できます^*7。

このproviderはIngressリソースに関するイベントを監視し、そこから対応する動的設定（ルーター・サービスなど）を導出します^*7。Ingressマニフェストを適用すれば、Traefik側の設定ファイルを直接編集せずにルーティングが反映される仕組みです。

1点、実装上の制約として押さえておきたいのは、spec.rules.http.paths.backend.resourceを使ったバックエンドリソースの参照が非サポートであり、代わりにspec.rules.http.paths.backend.serviceを使う必要がある点です^*7。既存のIngressマニフェストを他のIngress Controllerから移行する際は、この記法差分の確認が要ります。

構築を外注するか内製するかの判断軸

Traefikとは、覚える概念の数自体は少ないものの、実運用ではエントリポイント・ルーター・ミドルウェアの組み合わせ設計、証明書チャレンジ方式の選定、Kubernetes連携時の記法差分など、初期構築で判断が必要な項目が重なります。内製で行うにはコンテナオーケストレーションの知識・TLS証明書運用の知識・Kubernetesマニフェストの知識をあわせて持つ担当者が求められます。

証明書のチャレンジ方式を誤って選定すると、ワイルドカード証明書が必要な構成でHTTP-01チャレンジを選んでしまい、後からDNS-01チャレンジへの切り替えとDNSプロバイダー連携の追加設定が発生するといった手戻りが生じます^*6。ミドルウェアの適用順序を取り違えると、認証を経ずにバックエンドへ到達できる抜け道が残る可能性もあり、設計段階での検証が欠かせません。

専門パートナーに依頼する場合は、エントリポイント・ルーター・サービス・ミドルウェアの設計とKubernetes Ingress連携の構成を、稼働中の環境に合わせて一括で組み立てられる点が内製との違いになります。自社で完結させる場合は、上記の知識を持つ人員の確保と、証明書更新・ルーティング変更を継続的に検証する運用体制の両方を用意する必要があります。

LASSICでは、コンテナ基盤・Kubernetes基盤の保守運用を元請として受託する体制の中で、Traefikを含むリバースプロキシ／Ingress基盤の構築を支援しています^*8。要件整理からルーティング設計、証明書運用の設計までを一貫して担当できる体制を整えています。

まとめ：Traefikはエントリポイント・ルーター・サービス・ミドルウェアという4つの概念でリクエストを制御し、コンテナラベルやKubernetesリソースの宣言からルーティングを動的に生成するリバースプロキシです。本稿で整理した要点を3つに集約すると、第一に、Nginx等の静的設定型プロキシとは異なりリクエストを中断せずにホットリロードされる点が中心的な違いです。第二に、Let’s Encrypt連携による証明書の自動取得・更新は運用負荷を左右する重要な設計対象です。第三に、Kubernetes Ingress Controllerとして使う際は記法上の制約を踏まえた構築が求められます。これらを踏まえ、内製に必要な知識と工数を見積もった上で、外部パートナーへの依頼も選択肢として検討するのが現実的な進め方です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Traefik Labs「Traefik Proxy Documentation」
2. *2　出典：Traefik Labs「Concepts」
3. *3　出典：Traefik Labs「HTTP Middlewares Overview」
4. *4　出典：Traefik Labs「Configuration Overview」
5. *5　出典：Traefik Labs「Docker Provider」
6. *6　出典：Traefik Labs「ACME (Let’s Encrypt) Certificate Resolvers」
7. *7　出典：Traefik Labs「Kubernetes Ingress Provider」
8. *8　出典：LASSIC株式会社「LASSIC株式会社 コーポレートサイト」

Tweet