BioErrorLog Tech Blog

試行錯誤の記録

リソース名に"リソース種名"を含めるべきか | AWS命名規則

含めるべきではない、と感じているので考えを整理します。

はじめに

AWSのリソース命名規則として、リソース名にリソース種名を含めることが多くあるように感じます。

例:

{任意文字列}-vpc # 末尾にリソース種名を置くパターン
iam-role-{任意文字列} # 冒頭にリソース種名を置くパターン

私もそのような命名規則のもと長らくシステムを構築運用していたのですが、この方法はデメリットが多いように感じています。

今回はその考えを整理します。

リソース名に"リソース種名"を含めるべきか

デメリット

リソース名に"リソース種名"を含める場合のデメリット

リソース名実装ロジックの複雑性が増す

リソース名にリソース種名を含める、とする場合、その命名規則が守られていることを保証する仕組みを追加する必要が出てきます。 この実装ロジックの追加は、チームにとって無視できない負担になり得ます。

例えばTerraformなど何かしらのIaCでリソースを書いている場合、prefix/suffixのパターンを強制する変数を用意するなどして、リソース命名が規則に沿うことを自動的に保証しているとします。 仮にprefixとして{sysname}-{env}-を挿入する、と定めたとしましょう ()。 ここにリソース種名を含むようにすると、prefixは{resource_type}-{sysname}-{env}-みたいな感じになります。

この{resource_type}を命名ルールに挿入する実装ロジックの増加は一見すると大したことありませんが、一定規模以上のシステムを長らく運用していると、チームにとってなかなかの負担になります。
(それぞれのリソース種に対応する{resource_type}をどう定義するか、module間でどう共通化するか...etc.)

リソース種名を含めるとする命名規則がそれ自身価値を生まないのであれば、これらの労力も実質的に価値を生みません。


逆に、命名規則を自動保証する仕組みを用意していない場合は、単純に人間の労力による確認が増えるので、これこそチームにとっての負担は増大します。


prefixに{sysname}-{env}-を含める、というのも個人的には不要であると考えています。 (これらはリソース名ではなくTagとして付与する方が使い勝手が良い)

リソース名の文字数上限を圧迫する

AWSのリソース名にはそれぞれ文字数上限があります。 リソースによってはこの文字数上限が結構低く設定されているものもあり、リソース種名に費やす文字数が惜しくなることがあります。

命名規則が成熟してくると自動で挿入される文字数も増えてくるので、ものによっては残された文字数が少ない、という状況に陥ります。 私も、もう少し文字数に余裕があればより自明で分かりやすいリソース名が書けるのに...という経験があります。

リソース種名を命名含める場合は単純にそれだけ文字数を消費し、リソース名の制約が増えます。

リソース種名の略語の決定に時間と労力を消費する

"リソース種名"は、ありのまま定義すれば結構な長さになるものも少なくありません。 上記のようにリソース名には文字数上限があるので、リソース種名の略語を使おう、という機運になるのは自然な圧力です。

この"略語を決める"という営みは、結構な時間と労力を使います。

もちろん不適切な略語になっては意味が伝わりません。 しかし、プルリクがその略語決定の議論を残して長らくmergeされない、というのはチームの生産性に影響します。

メリット

リソース名に"リソース種名"を含める場合のメリット

リソース種をリソース名から判断できる

これはそのまま、リソース種をリソース名から判断できるというのがメリットになるでしょう。


しかし、これはあまり意味がないと感じています。 リソース種をリソース名から判断したい、というケースがほぼ見当たらないからです。

例えば、マネジメントコンソール上でリソースを確認する際は、いま何のリソースを見ているのかはリソース名を確認するまでもなく自明です。

IaCのコード上でも、リソース名以前にリソース種定義があるので、そこからリソース種を判断できます。 (むしろリソース名にリソース種を含むのは、リソース種定義部分とのコード上の重複が起こっている、とも言えます)

ログやリソースtagの集計にクエリを投げる場合も、リソース名から正規表現でリソース種を取得する、みたいな方法を取ることは少ないでしょう。

アーキテクチャ図やドキュメント上ではどうでしょうか。 リソース名にリソース種が含まれていたとしても、読者にとっての情報量が増えることは少ないと私は思います。

まとめ

以上を踏まえ、

  • リソース名にリソース種名を含める場合のデメリットはメリットを上回る
  • -> リソース名にリソース種名を含めるべきではない

と考えています。

おわりに

リソース名にリソース種名を含めるべきか、について考えを整理してみました。

次にリソースを構築する際にまた考慮してみようと思います。

[関連記事]

www.bioerrorlog.work

www.bioerrorlog.work

www.bioerrorlog.work

参考

Terraform Development Guideline. Including Terraform recommended… | by Xin Cheng | Dev Genius

Naming conventions - Terraform Best Practices