サーバのホスト名に悩んだあの日

はじめに

こんにちは。
突然ですが、みなさまは仕事でサーバに名前を付ける、という営みをされたことはありますでしょうか。私はそれなりのシステムのサーバに名前を付けてきました。某占い師や日本語の怪しい某タレント並にサーバ名の名付けを行ってきた自負があります。

それはともかく、サーバの名前、つまりホスト名を付ける行為というのは意外と悩ましいものです。システムを保有する企業の文化やシステム特性に応じてユニーク(この場合は面白いでなく、重複しない唯一のという意味)であること、名前から役割が読み取れること、が求められます。
ここでは私がこれまでホスト名を付けるにあたって気にしてきた点をお話ししようと思います。難しい技術の話は出てこないのでライトにご覧いただければと思います。今回はオンプレミス的なお悩み記事です。

ホスト名の定義

一口にホスト名といっても、システム開発においては少なくとも以下に分類されます。

• サーバ和名
• ノード名
• ホスト名

サーバ和名

サーバの役割を冠する日本語の名前を指します。厳密には日本語である必要はないですが、そのまま用途が伝わるサーバ名ということです。システムの中に実際組み込まれませんが設計書や、人間がそのサーバを特定して呼称するときに使います。
たとえばWebサーバ、APサーバ、DBサーバ、バッチサーバ、ファイル転送サーバ、ジョブ管理サーバ、システム監視サーバなどです。ひと目で役割がわかりますね。
ですが、これをシステムで使う場合にはとても不便なため、スペースなし英数字のみで構成された別名を付けることになります。なぜ不便なのかといいますと、単純に長いことと、日本語に変換して指定することが面倒だからです。

ノード名

この呼び方って一般的なのか実は自信がないですが、私はホスト名と明確に分けて使います。詳細は後述しますが、ノード名はサーバの英数字だけで呼称するものです。そして以下の特徴を持ちます。

• 1サーバでひとつしか持てない名前

これだけ聞くと意味がわからないというか当たり前と思うかも知れませんが、ホスト名と明確に区別されます。

ホスト名

こちらもノード名と同様、英数字のみで構成されます。またノード名と異なり以下の特徴を持ちます。

• 1サーバで複数持てる名前

こちらもこれだけ聞くと意味不明ですね。ですので加えて以下の特徴も述べましょう。

• ネットワークインタフェース(以降NICと呼称)に付与ができる

これでピンと来た方もいらっしゃると思いますが、複数のNICを持つ場合、その数だけホスト名を付与できます。厳密に言えばTCP/IPにおけるIPアドレスに対応して付与できる、です。よってNICにセカンダリIPアドレスや、仮想IPアドレス(フローティングIPアドレス)にも付与ができます。
ノード名との使い分けは以下の通りです。

• ノード名 - サーバ自体を示す名前
• ホスト名 - IPアドレス(NIC)単位で付与する名前

また、ホスト名は口頭で話す際に、上記すべてを指す広義に言葉として使われることが多いです。この記事では必要に応じてノード名と区別して記述しますが、基本は広義に使われている方の意味で話しているとお考えください。

以下の日経クロステックの記事を読むと、ホスト名とノード名の違いはネットワーク機器などのサーバ以外の機器を含むかという説明になっていますね。興味深いですが、私はこれまで先述した定義で数多のシステムを設計してきました。

ホスト名の何に悩むのか

ミッションクリティカルなシステムを設計していると、高い品質と運用性が求められます。少なくとも以下の要素は切っても切り離せません。

• 重複しないこと
• 意味が通ずること
• 長すぎないこと
• スケーラブルであること
• 文字数(長さ)が揃っていること

重複しないこと

すべてのサーバあるいはIPアドレスで重複しない名前を付けます。これを私たちの業界ではユニークと呼びます。理由はその名前を指定して確実に特定のアドレスに辿り着かせたいためです。ホスト名を指定して接続するとき、どこに行くのか保証されないと困りますよね。

意味が通ずること

これはそのホスト名を見ただけで、所属するサーバ和名が思い浮かぶという意味です。これを確実にやりたいなら、例えばデータベースサーバならdatabese-server或いはdb-serverと名前付けておけばいいです。が、後述する理由によってそうした名前は一般的には付けません。

長すぎないこと

長すぎないといっても具体的には何文字よ、となりますが、私がこの仕事を始めた時代、およそ20年前、ホスト名に使える文字数(長さ)は最大8文字でした。例えば当時の商用UNIXなどは9文字以上のホスト名を付けても無視されました。
その名残から、未だにできることならホスト名は8文字以下にしたいという生きる化石みたいなエンジニアがまだ静かに棲息しています。私のことです。

スケーラブルであること

これの意味するところは、システムが拡張された際にサーバが増えるというところにあります。そうしたときにユニークさや区別のつく名前が維持されるかを指します。何より重要なことは、命名規則に矛盾が無いことです。
例えば先に例として挙げたデータベースサーバをdb-serverと名付けます。もう一台データベースサーバが増えたときにあなたはどのような名付けをするでしょうか。そのままdatabase-server2と付けても良いですが、以下の通り格好がつかない構成になりますよね。

• database-server
• database-server2

そのため事前に、サーバ名に付ける識別子というものを考えます。詳細は後述しますが、それは先の例で挙げた格好の悪さを解決する連番という識別子だったり、サブシステムを表す識別子だったりを指します。ただ、そうした識別子が増えるとサーバ名に必要な文字数が大きく増えてしまいます。

文字数が揃っていること

これは美しさが理由というのもありますが、管理性と、識別の容易さが理由として挙げられます。ホスト名を一覧などで並べた際に文字数が統一されていると、形で何のサーバなのかすぐに判断できるようになります。ターミナルなどで利用される等幅(とうはば)フォントで表示すると整然と並んで美しいです。

# 良い例
apserver01
btserver15
dbserver04

# 悪い例
apserver1
batchserver15
databaseserver4

まあ、意味は伝わりづらくないですが、これが何十台、何百台となってくると文字を打つのも、ぱっと把握するのも、億劫になっていきます。

誰が名付けの親になるか

さて、ここまででホスト名を付けるというのはなかなか面倒そうだな、というのが伝わったのではないでしょうか。

プロジェクトにはいろいろなエンジニアがいます。まず大きく、以下に分類されます。

• アプリケーションエンジニア
• インフラエンジニア

ホスト名の命名の営みは、アプリケーションエンジニアに余程のこだわりの方がいない限りはインフラエンジニアが行います。
そして、そのインフラエンジニアも更に分類されます。異論はあるでしょうが、大きく以下でしょうか。

• サーバエンジニア
• クラウドエンジニア
• データベースエンジニア
• ネットワークエンジニア
• セキュリティエンジニア

ホスト名の命名に関わるのはサーバエンジニアか、ネットワークエンジニアです。どちらかにホスト名を臆すことなく付与できる誰かがいればその人が担います。私の場合はただの恐いもの知らずでそれをやっていただけですが。

ホスト名を構成するもの

先述したとおり、ホスト名はひと目見て役割がわかること、システムの変化に堪えうること、長すぎないことが求められるため、識別子を与えようということになりました。よく使われるのは以下です。

1. システム名識別子
2. ロケーション識別子
3. 環境識別子
4. サーバ種別および機器種別識別子
5. 物理/仮想識別子 ※物理IPアドレスか、仮想IPアドレスか
6. 連番
7. セグメント或いは用途を表す識別子

1文字ずつ付与しても既に7文字必要じゃん、しかもそれぞれの識別子が1文字だと意味不明じゃん、と思った方は鋭いです。
そうです。識別子で必要な意味を沢山付与したいのに、文字数が沢山使えないというのが悩みになります。
そこで私たちが取れる戦略は以下が主になります。

• 省略する
• 別のテーブルで管理する
• 桁数制限を付ける
• 複数識別子を1つの識別子にマージする

省略する

名前を意味が通じる程度に略すことを指します。例えば、データベースサーバなら「db」、アプリケーションサーバなら「ap」、L2スイッチなら「l2」などです。ただ、文字数が短すぎると、文字種を使い切ってしまう可能性があります。そもそももともとの言葉が長いと略しすぎると、意味が伝わらないこともあります。

別のテーブルで管理する

システム名などでよく使われます。例えば「aa」は決済システムの意味、などを別の管理テーブル表などで管理しておきます。システム名であれば、1システムでつかう文字列は1種になるため、サブシステムを含めてもそれほど多くはならないため案外別テーブル管理でも使い勝手が悪くならないというメリットがあります。以下が例です。

• aa - 決済システム
• ab - 勘定システム
• ac - 帳票システム

ただし、サーバ種などで別管理にするとその種類が多すぎるため、学習コストが発生します。サーバ種など1つのシステムで何種類も使うものを別テーブルに置き換える、つまり一見して何の意味かわからない文字列に置き換えるのは、システム設計をした本人や長く案件に関わっている人はともかく、後から運用を引き継ぐ人や、障害対応などで支援に来た人が何のサーバなのか把握してもらうことに手間を与えます。そのため私はシステム内で何種類も利用されるサーバ種などで使うのは明確なアンチパターンと断言します。

桁数制限を付ける

先述したとおり、ホスト名がむやみに長いと閲覧性・管理性が落ちます。何より、ホスト名をコマンドなどで指定する際に毎回たくさんの文字を打つ必要があり、それも生産性に影響を与えます。可能であればホスト名は8文字付近にしたいです。

複数識別子を1つの識別子にマージする

例えば、ロケーション識別子と環境識別子を混ぜる等です。以下に例を挙げましょう。

ロケーション識別子と環境識別子を分けない場合:

• tmaaaps01 ※tがtokyo、mが現用環境、aaがシステム識別子、apsがAPサーバの意
• obaaaps01 ※oがosaka、mがバックアップ環境、aaがシステム識別子、apsがAPサーバの意

ロケーション識別子と環境識別子をマージした場合:

• aaaap001 ※tokyoでかつ現用環境をaに置き換えた
• caaap001 ※osakaでかつバックアップ環境をcに置き換えた

上記の通り、1文字分文字が減らせました。別テーブルで管理する、と組み合わせて使います。

実践

私が過去に作った具体的なホスト命名規則を以下に挙げましょう。

- ロケーション/環境識別子 [1文字] ※別テーブルで管理
- システム識別子 [2文字] ※別テーブルで管理
- 機器種別識別子 [3文字] ※別テーブルで管理するが、わかりやすい名前
- 連番 [2文字] ※仮想IPアドレスは二桁目が5から開始
-------- ここまでノード名/ホスト名共通 --------
- セグメント識別子 [2文字] ※ホスト名のみ付与

以下の観点で上記の構成としています。

• ノード名は8文字、ホスト名は10文字に収まること
• 必要な情報量を備えていること
• 一目見て一番把握したい機器種別は多めに文字を取って、略しても意味が伝わること

識別子の順番は好みがあるでしょうが、個人的なルールとしては規模の大きいものを指すものほど頭に持ってきています。

特記事項

大文字と小文字について

大文字と小文字は区別されません。これは元々ファイル名やフォルダ名などで大文字と小文字の区別が出来ないWindowsもそうですが、ファイル名やディレクトリ名で大文字小文字が区別されるUNIXやLinuxについても、ことホスト名にはこの(区別されないという)原則に当てはまります。これは DNS (Domain Name Server) で使用されるドメイン名が同様の仕様だからと推察されます。

他にも最初の文字に数字を使ってはいけない、アンダスコアは無視されるというルールがあります。

紛らわしい文字について

システムによっては以下の文字は紛らわしいため忌避されることもあります。私が関わったシステムでは利用するフォントで区別できるよう工夫しています。

区別のつきづらい文字の例

• O と 0
• 1 と l と I
• 2 と Z
• 5 と S
• 6 と b と G
• 9 と g と q

qiitaでもコード表示すると区別のつきやすいよいフォントになりますね。

# 区別がつきづらい文字の例
- O と 0
- 1 と I と l
- 2 と Z
- 5 と S
- 6 と b と G
- 9 と q と g

ドメイン名について

ホスト名とドメイン名は明確に区別されます。が、サーバごとの命名規則は基本的にホスト名と変わらないです。よって、以下の形態を取ります。

• <ホスト名>.<ドメイン名>

例えば以下のようになります。

• omaadb01.local

ドメイン名は FQDN (Fully Qualified Domain Name) であることが期待されるため、ホスト名とドメイン名の間に「.(ドット)」を置きます。FQDNについては以下が詳しいです。

さいごに

いかがでしょうか。システム開発をするインフラエンジニアが意外とよく悩むネタとして記事にしてみました。
インフラエンジニアのお仕事の一端を感じていただいたり、既にインフラエンジニアをやってますという方にこういう悩みってあるよねと共感いだけたら幸いです。

以上