こんにちわ、毎日雨でマジで調子が狂いますよね。。。。 オルターブースのこじまです。 せっかくの夏休みでも雨続き、さらに緊急事態宣言と全く外に出ない生活をしている息子君たちも可哀そうな感じ。 まあ、僕はと言えば基本元気ですｗ
今回はAzureを運用するときに考えてほしいガバナンスについて、Azureのサービス視点で書きます。
Azureガバナンス？
実はAzureには正式なガバナンス対応サービスがあります。
このAzureガバナンスは複数の管理サービスから成り立つもので、既にGAされているものもあります。 Azureガバナンスは大きく5つのサービスで構成されてます。
- Azure Management Groups
- Azure Policy
- Azure Blueprints（Preview）
- Azure Resource Graph（Preview）
- Cost Management
知ってるよってサービスもありますが、マニアックなやつもありますよね。 で、このガバナンスを構成するサービスなんですが闇雲に導入しても設定するパラメータやカスタマイズなどどのようにすればいいかわからなくなります。 なのでまず最初にCAF（Cloud Adoption Framework）で提供されている各種テンプレートを使って規範を作っていきます。
CAFベースのガバナンス規範を作る
手っ取り早い話がテンプレートを使って規範を作っていきます。
- 名前付けおよびタグ付け規則の追跡テンプレート
- ガバナンス 規範 テンプレート
- Cost Management 規範テンプレート
- デプロイ高速化規範テンプレート
- ID ベースライン規範テンプレート
- リソースの整合性規範テンプレート
- セキュリティ ベースライン規範テンプレート
結構な量なんですがここら辺はシステム設計だと思えば良いんじゃないかと。
全体の構成を考える
以前にも書きましたがAzureランディングゾーンの設計が全体の構成になります。
AzureランディングゾーンはAzure内リソースのスケール、セキュリティ、ガバナンス、ネットワーク、そしてID を考慮して設計されたマルチサブスクリプションの構成になります。 この構成を現在の組織構造を反映した形、例えば部署ごとにサブスクリプションを管理しているという状態であれば階層型のマルチサブスクリプション環境で適用できるように落とし込みます。 実はこの階層型のマルチサブスクリプション環境の運用こそがAzureガバナンスそのものになります。
組織構造を反映させる設計についてはこちらが参考になりますので紹介しておきます。
いきなり壮大なガバナンス体制を作るのは危険です。まだクラウド組織が成熟していない状態で壮大なガバナンス設計をしても使いこなせません。 そこで上記リンクの標準的なガバナンス設計を参考にガバナンスMVPを作ります。
Azure Management Groups
階層型のマルチサブスクリプション環境を実装する場合、RBACを一つ一つサブスクリプションに設定するのは大変手間です。 そこで利用するのがこのAzure Management Groupsです。
Azure Management Groupsを設定することにより階層化した管理グループを作成することができます。 この管理グループにはRBACおよびAzure Policyを設定することができ、配下の子管理グループやサブスクリプション、各種Azureリソースに継承させることができます。 ちなみにPolicyとRBACがよくわからないって人はざっくり、Policy＝制限、RBAC＝許可、って覚えておいて下さい。
Azure Blueprints
Azure Management Groupsで階層構造作っていくと、だんだんとその階層が深く、広くなりポリシー設定が非常に複雑になってしまいます。 そこでAzure Blueprintsでポリシー、RBAC、ARMテンプレートをパッケージしテンプレート化し適用していきます。
これめっちゃ便利なんで是非使ってみてください。 ちなみにまだPreviewです。
Azure Policy
Azure Policyも非常に深い趣があるサービスなのですが、詳しいことはまた今度ということでざっくり何やるサービスなのかを書いていきます。
- 拒否ポリシーを設定することで、ガードレールを設置し、将来の構成が組織や外部の標準や規制に確実に準拠するようにすることができます。
- GitHubおよびAzure DevOpsとのネイティブ統合を活用して、デプロイワークフローでポリシーをコードとして管理し、ポリシーコンプライアンスの評価を明らかにすることができます。ビルドのリリース時の承認プロセスの数を削減して開発者の俊敏性を高め、コンプライアンス違反の理由を説明できます。
- 修復の自動化構成エラーを1つずつ処理するのではなく、一括修復を使用してリソースをコンプライアンスに準拠した状態にすることができます。
特にCI/CDへ組み込んでデプロイ時に検査できるのは非常に優秀かなと思います。 以前これが出来なかったときに色々やらかしたんで。（ドライランできないとやらかす）
Azure Resource Graph
これ、あまり知っている人がいない印象なんですけど、まだまだかなと。現在Preview提供中です。 Azure Resource GraphはAzure Resource Managerの拡張サービスという位置づけです。
具体的にいうと特定サブスクリプション内のリソースをクエリを発行して検索できるサービスです。
Azure Resource Managerでのクエリサポートは以下です。
Resource Manager では現在、基本的なリソース フィールドに対するクエリがサポートされています。具体的には、リソース名、ID、種類、リソース グループ、サブスクリプション、および場所です。 Resource Manager には、一度に 1 つのリソースについて詳細なプロパティを得るために個別のリソース プロバイダーを呼び出す機能も用意されています。
一方Azure Resource Graphでのクエリサポートは以下のようになっています。
各リソース プロバイダーへの個別の呼び出しを行う必要なく、リソース プロバイダーから返されるプロパティにアクセスする。 リソースに加えられた変更の過去 14 日間分の履歴を表示して、どのプロパティがいつ変更されたかを確認する。 (プレビュー)
要はビジュアル化できるよって話ですね。
Cost Management
まあ、これは使っている人も多くいるのでリンクするだけ省略しておきます。
ただ、意外と知られていないのはAWSとかも管理できるんですよってことですね。 Azureだけじゃなく他社のコストも管理できるのでマルチクラウドやっている人は重宝すると思いますね。
ガバナンスを正しく使うために
ガバナンスやセキュリティ、運用管理など巷には様々なツール、サービスがありますよね。 僕は敢えてこれを言いたいのですが、まずは目の前にあるツールを使ってみて、そこから増分拡張していけばいいんじゃないかと。 なので、基本方針としては、
Azureの標準機能で、適切で、コスト効率の高い状態を維持する。
だと思っています！
正しく実行すれば、将来的に不要なコストと労力を回避できるし、そもそもAzure内で適切設定していれば簡単なわけで是非使ってみてください。
