【AWSタグ戦略】タグKeyの命名規則は何がベストなのか？奥深い世界
1. 本稿の概要
◆ 背景とゴール
AWSのタグは誰でも利用できる一方でルールを定義しないとタグの氾濫やブレが生じて正確な管理・集計が面倒になる。したがってプロジェクトや統括管理者はメンバーに対してAWS全体の統一的な命名規則の遵守を徹底させる必要がある。命名規則は複数のパターンから選択する必要があり、必ずしも全ての関係者が満足できる絶対の正解は無い場合もある。本稿ではそれぞれの規則や基準を踏まえてどう選択するのがよいか検討する。
◆ Keywords
AWS、タグ、タグキー、タグ戦略、命名規則、キャメルケース、ケバブケース、スネークケース、ベストプラクティス
2. タグとは（一般論）
◆ AWSにおけるタグ
まず最初にタグはどう使うのか、という人はAWSのドキュメントとしてタグのリファレンスが存在するのでそちらで基本的なベストプラクティスや制限事項を確認しよう。
タグをつける側がとくに認識しなければならないのは以下のポイントである。
- Key:Value形式で各種リソースにメタデータとして付与可能
- 利用可能文字：日本語含む UTF-8 対応の文字、数字、スペースと_ . : / = + - @
- 大文字・小文字を厳格に区別
- タグに応じて分類やフィルタリング、アクションのターゲット指定などが可能
◆ タグ戦略
タグの使い方がわかったところで、プロジェクトのリーダーや管理者はタグに関するルールを設けることがベストプラクティスとなる。タグのリファレンスでも触れているのが「タグ戦略」を決定し、すべてのリソースに一貫して実装する、ということだ。例えばたとえば、Costcenter、costcenter、CostCenter はそれぞれ別モノとして扱われる。
ルールがない場合、「コストセンターのタグつけておいてね！」と言われてどういう記法が選択されるかはメンバーによっても変わってしまう。またバラバラのタグ付けでは管理時に表記ブレのタグのリストが出てきたり集計モレが発生たりして、せっかくのタグ管理の効果も不十分になってしまう。よって、チームやサービスを横断した整合性・一貫性のあるタグ付けが求められる。
3. 命名規則のパターン例
◆ プログラミング言語で使われる命名規則
それでは、実際にタグ戦略の策定でブレの少ない命名規則を考える際に、どのようなルールのパターンがあるのか考える。一般的にプログラミング言語の変数・関数宣言などでは以下のような命名規則が存在する。
| No. | 命名パターン | 概要 | 実例 |
|---|---|---|---|
| 1 | アッパーキャメルケース パスカルケース |
頭文字全大文字 単語直接続 |
CostCenter |
| 2 | ローワーキャメルケース (単に)キャメルケース |
先頭文字小文字他頭大文字 単語直接続 |
costCenter |
| 3 | チェインケース ケバブケース |
全小文字 単語ハイフン接続 |
cost-center |
| 4 | スネークケース | 全小文字 単語アンスコ接続 |
cost_center |
| 5 | スクリーミングスネークケース アッパースネークケース |
全大文字 単語アンスコ接続 |
COST_CENTER |
◆ その他、想定されうる命名規則
以下は一般にプログラミングなどでも使われないが、単純に定義できる区切り文字などパターンを示す。挙げればきりがないので数例を示す。
| No. | 命名パターン | 概要 | 実例 |
|---|---|---|---|
| 6 | (全小文字) | 全小文字 単語直接接続 |
costcenter |
| 7 | (全大文字) | 全大文字 単語直接接続 |
COSTCENTER |
| 8 | (先頭大文字) | 先頭大文字 単語直接接続 |
Costcenter |
| 9 | (英文風?スペース区切り) | 先頭大文字 単語スペース接続 |
Cost center |
| 10 | (ARN風?コロン区切り) | 先頭小文字 単語コロン接続 |
cost::center |
4. 命名規則パターンへの考察
◆ タグKey命名規則決定の評価基準
前述の命名規則パターンを踏まえ、実際の運用時にあるトピックだとどう
本稿で述べる●●性などはこの記事内に限り筆者が勝手に定義・解釈したものなので世間一般のそれと異なる場合があるので注意されたし。
■ 評価基準トピック
- 記述性
- 可読性
- 可搬性
- 整合性
- AWSとしてのベストプラクティスや実例
■ 記述性
記述性は書きやすさ、つまりタグを付与する記述者が記述ルールを間違えずに妥当なタグKey名を付けやすいかどうかを考える。
大文字と小文字の両者を混在して使うルールの場合、記述者はどこで大文字を使うか判断が必要になる。また、例えば"Ipv6NatGateway"など省略文字や連結して意味を持っている文字が連なるとなおさら判断が必要になったり、従来大文字だった個所を小文字にするため違和感を感じる場合がある。一方で強制的に小文字に統一している場合はそうした判断は不要となる。また、大文字で統一したルールは入力時に手間がかかるし、グローバル定数等をイメージさせるため除外したほうがよさそうある。
よって、様々なバックグラウンドのメンバーに統一的にルールを間違えずに記述させる場合チェインケースかスネークケースに優位性がある。
■ 可読性
可読性は読みやすさ、つまりそのタグを参照する人が理解・認識するのに労力を使うかどうかを考える。可読性については各種ケースで一般のプログラミング言語で言われる事項が当てはまると思われる。区切り記号を使わず単語を直接つなげる場合2~3単語程度なら問題ないが、それ以上になると見づらくなってくる。また、スペースで区切る場合も存在するのかしないのか読み取りづらい場合があり不適切である。
明確な区切り文字としてアンスコやハイフンがある場合、従来大文字の省略語などを小文字でも認識しやすい。よって、こちらもチェインケースやスネークケースの可読性が高いと言えるだろう。
一方、アンチパターンとして命名規則を設けず前述の表1~2,6~9のようなタグが氾濫している場合、管理やプログラミング処理の煩雑度が高いのが容易に想像できる。
■ 可搬性
可搬性はタグキーを外部でプログラミング処理する場合などにそのキー指定する場合などを考える。例えばCLIやBotoでAWSの情報をローカルに吸い取ってローカルでプログラム/スクリプト処理したい場合などを想定する。通常はその使用するプログラミング言語でそれぞれ主要な命名規則が存在する。
AWS CLIはPythonを利用しているため、Pythonコードでの処理が相性がいいといえる。Pythonはスネークケースで記述されるのが一般的のため、タグKeyもスネークケースだと可読性の維持やスムーズなコーディングができると思われる。
ハイフンを使う規則はハイフンが減算子として扱われる場合があり、選択する言語によっては注意が必要となる場合がある。
ただし、可搬性については利用ケースにもよるし最近の言語ではそこまで重要視する項目ではないと感じるので参考レベル。
■ EC2系 Nameタグとの整合性
EC2インスタンスやELBなど一部のサービスではリソースネームと「Name」タグのValueが同じものとして扱われている。つまり、NameタグのValue値がそのままリソースネームとしてコンソールなどに表示される。
ここで注意しなければいけないのはタグKeyの先頭が大文字の「Name」として設定され、「name」にタグを設定してもコンソール上には表示されない。よって、整合性をとるには先頭文字を大文字にする命名規則か、あるいはNameタグは特別なモノという運用にする必要がる。（Nameタグを使わずリソースネームを表示させないのはあまり現実的ではないと思っている。）また、EC2インスタンスなどではほぼ強制的にリソースネームを付けさせられ、それがName Keyになってしまうため、Nameを使う前提で考えれば先頭文字が大文字のほうが統一感は出せる。
ちなみに他のリソースではタグではないメタデータとしてリソースネームを持つサービスもある。
■ S3バケットとの整合性
S3のバケットネームはグローバルで一意のURIとなる必要があり、アンスコが使えないため区切り文字としてハイフンが使われる傾向がある。こちらと統一したいという意思が強い場合はタグの区切り文字としてハイフンを使うことになる。ただし、S3のバケットネームはどちらかというとAWSリソースネームと統一した命名規則が多い。理由としてはEC2インスタンスやS3バケットのネーム上にチーム名や役割名を乗せるという運用がある程度メジャーかつ分かりやすいからである。そうしたリソースネーム側の命名規則が別個定義されている場合、あくまでメタデータのタグKeyはまた別の命名規則と考える方が自然である。
■ cloudformationとの整合性
Cloudformationなど自動化ツールではリソース生成時にタグを自動付与する場合がある。例えば、以下のようなタグがある。(リソースタグ)
- aws:cloudformation:logical-id
- aws:cloudformation:stack-id
- aws:cloudformation:stack-name
これらは予約されたプレフィックスaws::を使ったタグで強制的にこの形式で付与される。見ての通り小文字で統一されているため、EC2の項で書いたNameタグと反している。AWS内でも記述の統一ができていないのである。
このため頭文字を大文字にするアッパーキャメルケースなどを採用する場合は、cloudformationは使わないから無視・自動で付与されるタグは例外とする、といった運用としなければならない。
◆ AWSとしてのベストプラクティスや実例
実はAWSのドキュメントにもタグ名に関するベストプラクティスという項目が存在する。この中ではチェインケースを採用している。cloudformationとも一貫性を持ち、記述の解釈のブレを減らすことができるようだ。
AWS側の意向として今後タグをチェインケースで統一していくのであれば、ユーザ側もチェインケースが有力な候補になる。本当にAWSが命名規則のベストプラクティスとして統一してくれるのかは分からない。真っ先にEC2のNameタグを直してくれれば何の文句もないのだが・・・EC2ともなれば影響度もでかいのだろう。
補足というかもはや雑学だが、さらにAWSドキュメントとしてローワーキャメルのタグ、例えば「createdBy」なども存在する(AWS cost allocation tags)。やはり大文字を使ったり自分が親しんだ言語の記法を自然に感じる層が一定数いることは否定できないだろう。（それはだからこそガバナンスで強制力を効かせる必要がある、ということでもあるが。）
これらの策定された時系列は不明だが、本当に今後は統一の方向に動いてほしい。
◆ 結論
特にこだわりがなければAWSに乗っ取ってチェインケースを採用するのがよいだろう。ただし、現状ではNameタグなど無視できない例外も存在するのでその点はサポートする必要がある。
また、もちろんプロジェクトや環境次第なとこもあるので既にNameタグや他の頭文字が大文字の一単語でタグ付けが浸透しているという場合もあると思われる。そうした場合アッパーキャメルケースなどにに寄せるといった運用もあるだろう。
大事なのはきちんと統一ルールを決定することと、管理のためのメタデータであるタグにメンバーの負荷をどれほどかけるかを勘案して方針を策定することである。
5. 他の内容
◆ タグValueの命名規則
本稿としてはいったんタグKeyの命名規則にとどめる。まずKeyを統一的に設定できるようにすることでタグ設定の運用が開始でき、次のタグを利用した管理やアクションに進むことができる。
タグ戦略としてはタグvalueにも規則をかける場合がある。例えば、Keyをdateとし、valueに年月日を入れる際にvalue値の指定をyyyymmddとするのか、欧米式の並びにするのか、ハイフンを入れるか、日本語文字を許すか等々。そちらはまた別の話なので本稿の対象外とする。
Discussion