イオンスマートテクノロジー（通称、AST）CTO室SREチーム所属、あおしょんです。
Azureを利用している方はリソースグループって何？とはならないと思いますがどういう単位でリソースグループを分ける？と一度は悩んだことがあるかと思います。
本記事ではASTはリソースグループをこうやって分けてるよ、という話をします。
５文字で分ける（←ここ重要じゃない）
以前、弊社のAzureリソースの命名規則について記事を書きました。 リソースグループ（Resource Group）だとServiceIDはrgとしているので例えば
- ステージング環境：s
- 認証会員基盤（Auth and Member）：am
- リソースグループ：rg
- 東日本リージョン（Japan East）：je
- WebHook：webhk
samrgjewebhkとなります。
サブスクリプションは環境かつアプリケーションごと、リージョンはほぼ同一で固定（ほぼ東日本リージョン）なのでリソースグループはContextの５文字で分けるというちょっぴり分かりづらい名前になります。
では肝心のリソースグループの分け方がどうなっているのかを説明します。
共通とサブシステム（機能）ごとに分ける
見出しだけだとちょっと何言っているか分かりませんがざっくりこんな感じです。
- 共通で利用するリソースのグループ
- VNet, IPグループ, ルートテーブルなどあるシステムが共通で利用するリソースのグループ
- そのシステムをスクラップすることになった時削除出来るようにしておく
- Contextは共通という意味合いで
commo（n）
- サブシステム単位のリソースのグループ
- VM, AKS, MySQLなどアプリケーションをデプロイするリソースのグループ
- あるシステム全体でグループ化するのではなくサブシステム（機能）単位でグループ化
- サブシステムの単位に明確な決まりはないが既存サブシステムと明らかにアーキテクチャが異なる場合に新規のサブシステムをビルドする。例えば既存のAKSクラスターにPodを追加するだけで良いなら既存サブシステムのリソースを必要に応じて増強するだけだがAzure Functionsとか使ってサーバーレスにしたい！といった要望（浅はかな表現ですみません。決してこの様なザックリした要望ではないです。）があれば新規にリソースグループをビルドしている。
- Contextは５文字という制限において作成者のセンスで決まる。例えば、WebHookは
webhk、モバイルアシスタント（Mobile Assistant）はmbastとしている。（左記の例は私のセンスなのですがいかがでしょうか…？ﾁﾗｯ）
次に何故このように分けているのかをイオンピープル歴５年以上（←ここ重要）の私が個人の主観で語ります。
スクラップ＆ビルド
先ほどから「スクラップ」と「ビルド」という単語を用いて匂わせてきました。弊グループではよく「スクラップ＆ビルド」という手法を活用しているとかなんとか。（詳しくは知らんけど）
上記とは全く関係ないですが弊社は「イオングループの全てのビジネスをテクノロジーの力で進化させる」ミッションを持っています。そして「スーパーマーケットから、クレジットまで、国内外に展開する200社以上の事業の成長を、テクノロジーで加速させます。」ので色々な方面から沢山の企画が持ち上がり、色々な沢山の機能追加が発生します。単純に追加した機能が全て成長、拡大すれば良いのですが中には一時的な機能であったり採算が取れずに寿命を迎える機能もあるのが事実です。
Azureを管理するSREチームとしては「この機能のAzureリソース要らなくなった。お金もったいないから消しておいてね。」と言われた時にすぐスクラップ出来るようにサブシステム単位でリソースグループを分けています。そしてまたどこかで新たな機能がビルドされます。
システムX（サブスクリプションX）
├─ 機能a（リソースグループa）
├─ 機能b（リソースグループb）⇒ スクラップ（リソースグループごと削除）
└─ 機能c（リソースグループc）⇒ ビルド
また、弊社はTerraform Cloudを導入しておりWorkspaceはリソースグループ単位としているのでTerraform Cloudのポータル画面からdestroyすれば良い形になっています。
金こそはすべて
実際のところ一番の目的は金です。これは弊社がイオングループの機能会社であることに関連します。既にSREチームの複数メンバーが外部発信・登壇で紹介している通り弊社はあらゆるシステムをグループ内の事業会社へ提供しています。 これらのシステムは事業会社からの利用料徴収で成り立っています。各事業会社への請求額の計算ロジックは詳しく知らないので割愛しますが簡単な一例としてこの機能は事業会社A,Bも利用しているからそのAzureランニングコストの○割は事業会社Aに、○割は事業会社Bに按分して請求するということになります。
システムX（サブスクリプションX）
├─ 機能a（リソースグループa）⇒ 事業会社A,B でコスト按分
├─ 機能b（リソースグループb）⇒ 事業会社C,D でコスト按分
└─ 機能c（リソースグループc）⇒ 事業会社A,B,D でコスト按分
もちろんAzureランニングコストの整理にはAzureコスト分析を利用しています。 少しでもAzureコスト分析を利用した方には分かりますがスコープは
- 管理グループ
- サブスクリプション
- リソースグループ
- サブスクリプション
で絞っていくことができます。
もちろんリソースのタグに機能名を付与してフィルタリングをすることも出来ますがスコープだけで絞れた方が楽です。なるべくAzureランニングコストの整理は楽に出来るようにしたいですね。
結局はその会社次第！（まとめ）
今回は弊社のAzureリソースグループの分け方について紹介しました。当然、この分け方が全ての会社における最適解であるということは全くなく大事なのはその会社の文化、組織、ビジネスモデルを把握した上で設計することが大事です。実は弊社は最初から今回のようになっていたわけではなく１年以上経ってから「こうしたらいいんじゃないか…？」と考えて設計しました。正直、最初は１サブスクリプションに対して１リソースグループでした（笑）自身が所属する会社を知りながら徐々に良い感じにしていけばいいんじゃないかな、と思います。
本記事がAzureリソースグループの分け方を考える際の一助となれば幸いです。
Discussion