どうも、イオンスマートテクノロジー（通称、AST）CTO室SREチーム所属、あおしょんです！
本日はAEON Advent Calendar 2023とMicrosoft Azure Advent Calendar 2023の9日目の場をお借りしまして弊社のAzureの命名規則について紹介したいと思います。
Cloud Adoption Frameworkのベストプラクティス
その前にまずはCloud Adoption Frameworkの命名規則のベストプラクティスでAzureリソースの名前付けにどの様な定義が推奨されているか覗いてみましょう。
名前付け規則を定義するより引用
ふむふむ、リソース名に下記の情報が含まれていれば良いわけですね…なるほど…
- VM, VNet, AKSなどのリソースの種類
- 何のアプリケーション、ワークロードか
- 実行されている環境
- 実行されているリージョン
- 連番
安心してください。弊社のAzureリソース名も上記の情報は漏れなく全て含まれています。
Azureリソース名、整えます
では弊社のAzure命名規則について紹介を…の前に何かを例にして一つリソース名を考えてみましょう。
ところで、弊社のSREチームのイケイケな人たち@Tocyuki（通称：KASAI Leaderがやる）と@hikkie13（通称：ヒカルしか勝たん）がCloudNative Days Tokyo 2023のスポンサーセッションに登壇することが決まってます。
ふむふむ、なるほど主にAKS (Azure Kubernetes Service) について話すようですね。丁度良いので下記条件でAzureリソース名を考えてみましょうか。
- ステージング環境で実行されていて
- 認証会員基盤というアプリケーション（ないしはワークロード）で
- リソースの種類はAKSで
- 東日本リージョンで実行されていて
- クーポンをばら撒くためのAPIを提供するから～
…整いました！
その心は？…規則なのでありません！
弊社のAzureリソース命名規則
上記のAzureリソース整い例をご覧になってほとんどの方がこう思っているかもしれません。
- 「何かの暗号ですか？」
- 「一目見て全然意味わからん」
- 「完全な初見殺しや…」
弊社でもジョインしたてのイケイケな人たちは同じ様な感想を持っていたみたいです。初めは、ですね。初めは…
命名規則説明
ここから弊社の命名規則の詳細について説明します。
まずリソース名の構成要素は下記の通りとなっています。
Environment(1)SystemID(2)ServiceID(2)RegionCode(2)Context(5)[001-999]
構成要素
| 要素 | 説明 | 長さ |
|---|---|---|
| Environment | デプロイされる環境（検証環境、本番環境など） | 1 |
| SystemID | アプリケーション個別のID | 2 |
| ServiceID | Azureサービスごとに付与するID | 2 |
| RegionCode | デプロイされる地域（東日本リージョンなど） | 2 |
| Context | リソースを特定するための任意の文字列 | 5 |
| 001 - 999 | 連番に付与する。サブスクリプション、リソースグループは対象外。 | 3 |
上記を元に先ほどの整い例
をご説明しますと
- ステージング環境：s
- 認証会員基盤（Auth and Member）：am
- Azure Kubernetes Service：ak
- 東日本リージョン（Japan East）：je
- クーポン（coupon）：coupn
- 最初のリソース：001
となります。
いや…やっぱ分かりにくいし普通にCloud Adoption Frameworkのベストプラクティスに従えばいいんじゃ…とほとんどの方が感じていると思うので次にこの初見殺しの命名規則の二大メリットをお話しますね。
【その一】Azure リソースの名前付け規則と制限事項に抵触しない
まず下記を確認してみましょう。
嘔吐しそうになるほど盛り沢山のAzureリソースの名前付けの規則と制限事項が並んでいますね。で、細かく見ていくと下記のようなことがたま～にあるんです。
- ハイフン（-）が有効な文字に含まれていない
- 英字が大文字に対応していない（小文字のみ）
そして文字列の長さもリソースごとに異なっています。
はい！ここで先ほどの整い例を思い出してみてください！
ハイフン（-）もなければ大文字もねぇ！文字数15で固定じゃい！！
ここまでいくと全てのAzureリソースに対応できると言っても過言ではありません。（対応できないリソースがあったらごめんなさい。）
【その二】文字数固定であること
やはりどのリソースでも文字数が15文字に固定（サブスクリプションなど一部例外あり）されることはCLIでリソースを操作する時のメリットだと思います。
こちらのメリットはクラウドネイティブのイケイケなナウでヤングなエンジニア（偏見ではない）やWindowsインフラ畑の人（偏見ではない）だとあまりピンとこないかもしれません。
私が10年以上前に新卒１年目のピカピカのLinuxインフラエンジニアだった頃は喫煙所によく溜まっていた古豪のLinuxインフラエンジニアおじさん（偏見ではない）とデータセンターで椅子を隣り合わせて一つの端末で二人作業しながらよくこう言われたものです。
「vim, awk, sed, （あとなんか忘れた）使いこなせない奴はインフラエンジニアじゃねぇからよ」
あ、自分ごとですが現在の私は今ではクラウドネイティブのイケイケなナウでヤングなエンジニアなのでawkもsedも全然使いこなせなくなってしまいました。もうインフラエンジニアとしては食べていけないですね。
それでも文字数固定で必ず決まった位置にリソース名の構成要素の情報があると簡単なテキスト処理やTerraformのHCLで条件分岐の処理をする時に便利です。
それでも初見殺しでは…？
ここまでで弊社のAzure命名規則のメリットは充分伝わったかと思います。ですが、いくらメリットを説明しても初見殺しであることには変わりないですよね。
はい！もうそこは諦めてください。慣れるしかないです。
でも安心してください。ほとんどの企業の試用期間の3ヶ月も経てばこの命名規則の虜になっていることでしょう。正に嚙めば嚙むほど味が出るスルメ系命名規則です！
かくいう弊社SREチームのイケイケなリーダーである@Tocyuki（通称：KASAI Leaderがやる）も2023年8月のチームジョイン当初はAzureリソース名を見て明らかにテンションがガタ落ちてしていましたが3ヶ月後の2023年11月頃には「この命名規則はメチャクチャ良く考えられている！」とベタ褒めしていました。ちなみに１つめのメリット「Azure リソースの名前付け規則と制限事項に抵触しない」は@Tocyuki（通称：KASAI Leaderがやる）がベタ褒めした点でもあります。
また、SREチームのイケイケなエースである@hikkie13（通称：ヒカルしか勝たん）も今では断片的な情報をインプットするだけでPCのディスプレイすら見ずともリソース名を口ずさみながらガンガンキータッチしまくっています。正にAST AzureリソースのJukeboxです。（表現が古い）
あとリソース名のContextが5文字なのでなんだか分からない、というところはどうしても付きまとうので弊社ではタグ付けをして詳細情報を補完しています。これは正にCloud Adoption Frameworkに従えば良いです。（未だ弊社では従い切れてない、というか有効活用し切れていないですが…）
ガバナンスを効かせる
このすんばらしい（？）命名規則が考えられた当初はTerraformを活用しきれていなかったこともあり、作業者のHCLコーディング時のタイプミスや命名規則の理解不足で1文字余計に入っていたりとか構成要素の位置が間違っているとか規則から外れたリソースがいくつかデプロイされて再作成、もしくは間違ったリソース名のまま気付かずにサービスのローンチを迎えてしまうこともありました。
ですが、2023年12月現在ではVariablesのvalidationを活用してある程度のパターンの強制をしています。
参考までに一部抜粋した内容を載せて置きます。
variable "env_id" {
description = <<DESC
One-letter of environment ID.
The env_id must specify the following values:
"d" -> "Development"
"t" -> "Test"
"s" -> "Staging"
"p" -> "Production"
"g" -> "General"
"b" -> "Sandbox"
DESC
type = string
validation {
condition = (
var.env_id == "d" ||
var.env_id == "t" ||
var.env_id == "s" ||
var.env_id == "p" ||
var.env_id == "g" ||
var.env_id == "b"
)
error_message = "The env_id value must be 'd', 't', 's', 'p', 'g' or 'b'."
}
}
variable "system_id" {
description = "Two-letter of System-specific ID."
type = string
validation {
condition = (length(var.system_id) == 2)
error_message = "The system_id value must be 2 characters."
}
}
variable "region_code" {
description = "Two-letter of region code. (short location name.)"
type = string
default = "je"
validation {
condition = (length(var.region_code) == 2)
error_message = "The region_code value must be 2 characters."
}
}
また、Module内のTerraformのResourceで上記の変数を活用してリソース名を定義しているので構成要素の位置は固定されています。
resource "azurerm_kubernetes_cluster" "main" {
name = "${var.env_id}${var.system_id}ak${var.region_code}${var.context}001"
なおリソースへのタグ付けはリソース名のContextをModule内のTerraformのResourceで定義しているだけなのでタグ付けの内容を整理してガバナンスを効かせる仕組みを考えていきたいと考えています。 (Backlog)
ちなみに弊社ではTerraform Cloud Businessをライセンス契約しているため、SentinelまたはOPA (Open Policy Agen) といったPolicy as Codeを活用してガバナンスを効かせていきたいと考えています。 (Backlog)
終わりに
以上、弊社のAzure命名規則について語りました。いかがでしたか？人によっては「やっぱ初見殺しはダメだわ…」という感想をお持ちの方もいるかもしれません。…が！ゆくゆくは幣グループの全てのAzureリソースをこのスルメ系命名規則に塗り替えてやるぜ！！！！とは思っていませんが引き続きアプリケーション開発者などが活用しやすいプラットフォーム作りを弊社のイケイケなエンジニアたちと一緒にしていきます。
最期にイオンスマートテクノロジーではエンジニアを絶賛採⽤中です。
Discussion
今更でもアドベントカレンダー見返しておいて良かったと思える記事。