はじめに
こんにちは！ 名古屋に来てひと月半で３キロ増量したＢＦＴ名古屋支店・インフラ女子（？）のやまぐちです。
さて、今回のテーマは「ホスト名の設計」です。
基本的には前例や他のシステムに倣って付けることが多く、本当はこうしたいんだけどな…という意見を反映しにくい設計要素です。変える工数は別に大したことないのですが、変えたところで劇的に何かが良くなるわけでもなく、むしろそんなことに時間をかけるなといわれてしまうように感じて今まで冒険したことはありません。
そんなわけで、私がＳＩで関わってきたシステムで付けることが多かったもホストの命名規則の話と、その付け方の問題と思われる点、それではどうしたらいいのかという流れで進めていこうと思います。
ホスト名を設計する前に
世はクラウド全盛期。実はクラウドのシステムであればそもそもホスト名を設計してつけなくても構わない、むしろ付けない方がクラウドの利用の仕方として適切だ、という考えがあります。
ペットから家畜へ。
名前を付けて大事に大事に家族のように扱い、調子が悪そうだったら何が悪いのかログを見て対処してしたオンプレの機器たち。クラウドではサーバ個別に名前など付けず落ちたら新しいホストが立ち上がってくる、使い捨てのような扱いをすることが推奨されています。
ホストの命名規則を考える前にまず前提として、今設計しようとしているシステムはどんなプラットフォームで作ることを想定しているのか、本当にホスト名を設計する必要があるのかを考えるようにしましょう。
ホスト名の構成
ホスト名は以下のように複数の意味づけされたブロックの組み合わせで構成されます。
ブロックの種類はホスト名から識別すべき内容で構成されます。ブロックの文字数や順番もさまざまですが末尾は基本的にサーバの連番が多いと思います。「連番」ブロックは絶対に増えないであろうサーバやシステムでも２桁からスタートし、システムの規模が大きい場合は００１と３桁になることもあります。
ブロックごとに例を挙げていきます。
1. 環境
複数の環境がある場合に付けることが多い。
- 開発環境 … d, dev（developmentの略）
- 検証環境 … s, stg（stagingの略）
- 本番環境 … p, prd（productionの略）
2. システム名
システム名はプロジェクトで決める略称が入る。通常は２－３文字。
この略称はディレクトリのパスやネットワークのセグメント名、その他名称で使うこともある。
3. サーバ種別
サーバの機能ごとに略称を決めて付けることが多い。
- Webサーバ … web, www
- APサーバ … app
- DBサーバ(PostgreSQL) … dbp, pdb
- DBサーバ(MongoDB) … dbm, mdb
- 運用管理サーバ … unyo（運用の略）, mgt（managementの略）
この「サーバ種別」が時々悩みの種となることがあります。例えば例にあるＤＢサーバ(MongoDB)のレプリカセットの推奨構成は最小３台（プライマリ、セカンダリ、アービター）です。
このうちプライマリとセカンダリは完全なデータのコピーを持つため最後の連番で分ければ問題はなさそうです。
しかしアービター（訳は「仲裁者」）はデータのコピーを保持せず、単にレプリカセットを監視しフェイルオーバーが必要になった場合に新しいプライマリノードの選出をする役割を持ちます。今後セカンダリノードが追加される可能性を考慮するとデータを保持しないサーバが番号の途中に挟まれていると不自然ですね。００とか９９にするのもアリかもしれません。「サーバ種別」で新しい定義を作るか「連番」の意味を一部変える必要が出てきそうです。
もう少し長いホスト名の例も挙げてみます。
サーバとネットワーク機器を明確に分けるために「機器種別」ブロックがある場合があります。ホスト名として長くはなりますがハイフンを入れるとわかりやすくなります（多用はいたずらにホスト名が長くなるので厳禁）。
また「場所」のブロックが入る場合もあります。ネットワーク機器はどこのビルの何階のどこの部屋かという区別を付けることがあります。サーバとネットワーク機器が同じ命名規則である必要はないのでサーバが一か所に設置されているのであればルールを分けてもいいのかもしれません。
私自身が悩む部分と改善案
ここまでホスト名の例を出してきましたが、私はいつも微妙だなーと思いながら既存のルールを変えずにそのままつけてきました。私が微妙だなーと思う部分は以下の通りです。
【悩】短くても長くても結局わかりにくい
ホスト名は１０文字以内くらいが覚えやすいです。例の一つ目は８文字、二つ目は１２文字ですが二つ目は慣れるまで少ししんどそうですね。
かといって短くするとシステム名が１文字、サーバ種別が２文字と減り、１文字しか違わないサーバは並べると区別がつきにくいです。
【悩】不要そうなブロックを外しづらい
例えばシステム名のブロックはなぜあるのでしょうか。もし、同じ命名規則の他システムが同じセグメント内にあるのであればシステム名をホスト名に付けて区別した方がいいように思います。
しかしそうでない場合も既存のシステム、その他のシステムで「システム名」ブロックを付ける習慣が染みついているので、無くすには誰もが納得する正当な理由が必要になります。いらなそうなブロックがあっても最初に書いた通り、変えたところで劇的に何かが良くなるわけでもなく、無くす理由をきちんと整理したり説明したりする時間がもったいない・・・のです。
【悩】適切なブロックの順番がわかりにくい
ホスト名は見るだけで環境や場所、システム、機能を読み取れるように設計するものです。例えば８文字のパターンでＤＢサーバ(PostgreSQL)とＤＢサーバ(MongoDB)を上記の例のホスト名で表すと以下のようになります。
pcmpdb01
pcmmdb01
見にく・・・いですよね・・・？
このルールだと真ん中の１文字だけでサーバが違うことを認識しなければならず、例えば「a」「o」「c」、「g」「q」、「b」「h」などが識別しにくい文字だと接続したサーバを見間違う可能性もでてくると思います。慣れれば文字としてではなく文字の印象として識別できるようになりますが、ホスト名は短期間に高頻度でそのサーバへアクセスする設計・構築のエンジニアではなく長期間にわかって低頻度でそのサーバへアクセスする運用のエンジニアがわかりやすいようにつけた方がいいのではないかと思っています。
【改】順番を入れ替える
それではどうしたらもう少しわかりやすくなるのでしょうか。
サーバにログインしたらもれなく打って確認するコマンド、whoami
その時に最初に表示されるブロックが「サーバ種別」だったらどうでしょうか。
| # | 変更前 | 変更後① |
|---|---|---|
| 1 | pcmdbp01 | pdbpcm01 |
| 2 | pcmdbm01 | mdbpcm01 |
頭から３文字でPostgreSQLなんだ、MongoDBなんだとわかるので印象はだいぶ変わりますね。
ただそうなるとpcm~という後ろの長い共通部分が気になってきます。ホスト名を見た時に開発、検証、本番と接続している環境の区別ができることも大事なので、「環境」ブロックを前に持ってきてかつ「サーバ種別」も目立つようにしてみます。
| # | 変更前 | 変更後① | 変更後② |
|---|---|---|---|
| 1 | pcmdbp01 | pdbpcm01 | p-pdbcm01 |
| 2 | pcmdbm01 | mdbpcm01 | p-mdbcm01 |
| 3 | scmdbm01 | mdbscm01 | s-mdbcm01 |
三番目に検証環境のＤＢサーバ(MongoDB)の場合も載せてみました。環境の後にハイフンを入れることで環境の接続間違いが気づきやすく、ハイフンを挟んでいるのでサーバの機能も目につきやすい気がします。
終わりに
ホスト名の命名規則に明確な答えはありません。構築・運用する人がホスト名から多くの情報を得られたり、接続間違いに気づきやすかったりすることを考えながら設計できていればそれで正解だと思います。
ただそのシステム内だけではなく他のシステムや既存の状態に引っ張られて、もっとこうすればいいのにということをしにくいのは今後も変わらないように感じます。
クラウドに移行するタイミングがあればこれを機にもっとわかりやすいホスト名の命名規則へ少しずつ変わっていくといいですね。
以上、ホスト名の命名規則についてでした～。
