ProDHCP機能追加：後方互換性は大切！

先日、ProDHCPをお使いいただいているお客さんから要望をいただき、機能追加をしてみました。ProDHCPは基本的にはISCのDHCPサーバに似た動きに作ってありますが、いくつか独自拡張機能を実装しています。表面的なところでは、今日追加した機能も含めて、

・可能な限り同一MACアドレスに対して異なるIPアドレスを割り当てる動作の指定
・空きアドレスを検索する際の検索方向の指定
・空きアドレスを検索する際に検索開始位置のランダム化の指定
・ICMPによる重複チェックのON/OFF

こんな感じです。細かい機能と思われるかも知れませんが、実際に運用している側としてはこれらの機能があるかどうかで、サービスの仕組みを実現できるかどうかが変わってしまうくらい重要な場合もあるのです。自分たちでソースを全て作っていますので、対応もかなり迅速にできますし、サポートも深いところまでできます。

他にも、商用での運用をターゲットに、性能や厳密性、安全性などを工夫してあります。

基本的に、汎用的な機能であればカスタム版とはせず、メインバージョンにどんどん機能追加を行い、サポート対象にしていく方針です。また、機能拡張を行う場合でも、基本的には運用を止めずに入れ替えていけるように考えています。実際の入れ替え手順としては、新しいプログラムに置き換え、必要に応じて設定ファイルを編集し、HUPシグナルを与えるだけです。貸し出し中の情報などは全て引き継がれ、瞬時に新しいもので運用が始まります。

実は新しい機能を追加するときに気をつけなければならないのがこの「後方互換性」です。開発側としては新しい機能にあわせてデータ構造を変えたりしたいところなのですが、運用側としては入れ替え時にサービスを停止したり、不整合が起きることは避けなければなりません。理想的には全く運用を止めずに入れ替えたいのですが、少なくともサービスに影響しないくらいのスピードで入れ替えられないと、入れ替え自体に許可が出ないことが多いのです。

プログラム本体ももちろんですが、設定ファイルにも後方互換性は重要です。入れ替えてプログラムを再起動したら立ち上がらなかったり、あるいは立ち上がっても動きが変わってしまうようでは困るのです。特に設定項目が増えた場合には、無指定で旧バージョンと同じ動きとしておくのが鉄則です。

実は今日追加した機能も、本当はデータ構造を少しいじればもっと良い対応もできたのですが、後方互換性を優先しました。

プログラミングでは共通のライブラリを構築して、使い回すケースが良くありますが、ライブラリも後方互換性が大切です。それが無理であればプログラムごとに専用のライブラリとして管理する方が安全です。もっとも怖いのが、ライブラリの仕様が変わったのにビルドができてしまうケースです。コンパイラがエラーとなってビルドが途中で止まれば気がつきますが、警告が出ているくらいだと見落とします。ビルドできたように見えて、動かしてみると動きが違うというのが一番怖いのです。

たかが機能追加ですが、エンジニアは運用も想定しながら開発しますので、実は結構気を使っているのです。