深夜2時の緊急事態：なぜレガシーDHCPは失敗するのか
火曜日の深夜2時。私の電話が鳴り響きます。モニタリングダッシュボードでは、第2データセンターの650台の本番サーバーが赤く点滅しています。原因は？長年使い続けてきた isc-dhcp-server がついに限界に達したのです。「問題なく動いている」と信じて6年間使い続けてきましたが、300MBのリースファイルが破損してしまいました。サービスが巨大なテキストデータベースを解析しようと苦戦している間、ネットワーク全体が4分間も停止し続けました。まさに惨事でした。
これが、老朽化したインフラを管理する厳しい現実です。ISC DHCPは何十年もの間コミュニティに貢献してきましたが、モノリシックで巨大な存在です。ネイティブAPIがなく、設定を少し変更するたびにサービスを完全に再起動する必要があります。ISCは2022年末に公式にソフトウェアを引退させたため、使い続けることはセキュリティリスクとなります。だからこそ、私たちは Kea DHCP へ移行しました。Keaはモジュール化されており、高速で、Infrastructure as Code（コードとしてのインフラ）が当たり前の世界に向けて設計されています。
Keaへの移行は、単なる近代化ではありません。深夜にあなたを困らせない、プログラマブルで堅廊なネットワークを構築することなのです。
クイックスタート：5分でKeaをデプロイする
まずは応急処置をしましょう。現在のサーバーが故障している場合は、以下の手順に従ってUbuntuまたはDebianで基本的なKeaインスタンスを起動してください。Keaはモジュール式であり、DHCPロジックを管理エージェントから分離しています。
1. モジュールパッケージのインストール
旧来のオールインワン型サーバーとは異なり、Keaは機能を特定のパッケージに分割しています。標準的なIPv4セットアップでは、サーバーエンジンとControl Agentが必要です。
sudo apt update
sudo apt install kea-dhcp4-server kea-ctrl-agent -y2. 基本状態の確認
サービスがアクティブかどうかを確認します。最初はエラーが表示されるかもしれません。これは通常、物理ネットワークインターフェースがまだ指定されていないために発生します。
systemctl status kea-dhcp4-server
systemctl status kea-ctrl-agent3. ハードウェアの特定
KeaがクライアントからのDISCOVERパケットを待機するネットワークインターフェースの正確な名前を確認します。
ip link showディープダイブ：モダンなエンジンの設定
dhcpd.conf の古くて使いにくい波括弧構文は、JSONに置き換わります。設定ファイルは /etc/kea/ にあります。この形式は、AnsibleやTerraformを使用して設定を生成するDevOpsチームにとって理想的です。
kea-dhcp4.conf の構造
/etc/kea/kea-dhcp4.conf を開きます。私は通常、見通しを良くするためにデフォルトのコメントを削除します。以下は、標準的な192.168.10.0/24サブネット用の本番環境対応テンプレートです。
{
"Dhcp4": {
"interfaces-config": {
"interfaces": [ "eth0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/kea-leases4.csv",
"lfc-interval": 3600
},
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"subnet4": [
{
"subnet": "192.168.10.0/24",
"pools": [ { "pool": "192.168.10.50 - 192.168.10.150" } ],
"option-data": [
{
"name": "routers",
"data": "192.168.10.1"
},
{
"name": "domain-name-servers",
"data": "8.8.8.8, 1.1.1.1"
}
]
}
]
}
}パフォーマンスに関する重要な注意点
- インターフェース： インターフェース名は明示的に指定する必要があります。
"*"を使うのは安易な方法ですが、マルチホームサーバーではトラブルの原因になることが多いです。 - リースデータベース： ここでは簡単にするために
memfileを使用しました。75,000以上の同時リースを管理する場合は、mysqlまたはpostgresqlのバックエンドに切り替えてください。 - LFC（リースファイルクリーンアップ）：
lfc-intervalは非常に重要です。これは定期的にリースファイルを圧縮します。これにより、私が深夜に経験した障害の原因であるファイルの破損を防ぐことができます。
高度な使い方：Control Agentのパワー
以前は、静的予約を1つ追加するだけでDHCPサービス全体を再起動する必要がありました。そのたびにアクティブなパケットがドロップされ、ユーザーを困らせていました。Keaは Control Agent を使用することで、このダウンタイムを解消します。
REST APIブリッジの構築
kea-ctrl-agent はゲートウェイとして機能します。HTTPリクエストを受け取り、Unixソケットを介してコマンドをDHCPエンジンに渡します。これにより、ネットワークがウェブサービスのように扱えるようになります。
APIを有効にするには、/etc/kea/kea-ctrl-agent.conf を編集します：
{
"Control-agent": {
"http-host": "127.0.0.1",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/kea4-ctrl-socket"
}
}
}
}curl を使ってサーバーの状態を確認したり、設定をリロードしたりできるようになりました。もう systemctl restart は必要ありません。
curl -X POST -H "Content-Type: application/json" -d '{ "command": "list-commands", "service": [ "dhcp4" ] }' http://127.0.0.1:8000/Hookライブラリによる拡張
Keaは「Hooks（フック）」と呼ばれるプラグインアーキテクチャを採用しています。外部のIPAMと連携させたり、新しいデバイスが接続されたときにスクリプトを実行したりする必要がありますか？共有ライブラリ（.so ファイル）をロードするだけで可能です。これは、ISC DHCPの古い「on commit」シェルスクリプトよりも大幅に高速です。
スムーズな移行のための実践的ヒント
isc-dhcp-server からKeaへの移行を、面倒な手作業にしてはいけません。移行中に正気を保つための実用的なヒントを紹介します。
1. 壊れる前に構文を確認する
Keaは構文に厳格です。JSONにカンマが1つ欠けているだけで、サービスは停止します。変更を適用する前に、必ず組み込みの設定確認ツールを実行してください：
kea-dhcp4 -t /etc/kea/kea-dhcp4.conf2. 静的予約を整理する
ホストの予約はサブネットブロック内に記述します。数百件の予約がある場合は、メインファイルを煩雑にしないようにしましょう。<?include "hosts.json" ?> ディレクティブを使用して、別のファイルから読み込ませます。
"reservations": [
{
"hw-address": "00:50:56:b4:12:af",
"ip-address": "192.168.10.20",
"hostname": "db-server-01"
}
]3. デフォルトの静音設定をやめる
標準のロギングは、複雑な問題をトラブルシューティングするには不十分なことが多いです。severity を INFO または DEBUG に設定してください。これらのログを Grafana Loki にパイプして、「DHCP NAK」の嵐がチケット化される前に察知することをお勧めします。
4. 高可用性（HA）の活用
Keaは「ロードバランシング」や「ホットスタンバイ」モード用のネイティブ高可用性（HA）フックをサポートしています。サーバー間でリース情報を直接同期します。ほとんどの標準的な構成では、複雑なデータベースレプリケーションは不要です。
プレーンテキストファイルを好む場合、Keaへの移行には学習コストがかかります。しかし、その安定性と自動化のしやすさは他に類を見ません。一度稼働してしまえば、深夜のリースファイル破損パニックは遠い過去の記憶になるでしょう。
