Azureリソースの構成とリソースの一覧
<1.概要>
<1.Azure リソースとは>
「Azure リソース」とは、Azureによって管理されている「Azureの実体」を指します。例えば、仮想マシン、仮想ネットワーク、ストレージアカウント等はすべて「Azure リソース」と言います。
Azureの各リソースは「リソースグループ」と呼ばれるライフサイクルとセキュリティに基づいて複数のリソースを単一の「実体」としてまとめて管理できるようにした論理コンストラクトです。
つまりは似たライフサイクルを共有するもの一緒にまとめて作成したリソースを一緒に管理したり、削除して1つのグループにまとめます。
<2.サブスクリプションとは>
「Azure サブスクリプション」とは、リソースグループおよび、グループに含まれているリソースをいいます。
サブスクリプションは、リソースグループとそのリソースをまとめる「論理コントラスト」である点においては、リソースグループと似ている点があります。サブスクリプションは、「Azure Resource Manager」によって使用制御が行われています。
<3.Azure Resource Managerとは>
「Azure Resource Manager」はAzureの「リソース管理サービス」であり、リソースの作成や、更新、削除等を行います。
Azure portalやコマンドラインを使用して仮想マシンな時のリソースを作成する際、直接、提供されているサービスにアクセスしているように見えるが、実際は「Azure Resource Manager」を経由して提供されているサービスに「間接的アクセス」という形を取っています。
<2.リソース管理>
<1.一貫性のある管理レイヤー>
「Azure Resource Manager」が「一貫性のある管理レイヤー」と呼ばれるのは、利用者が、API、Azure提供のツール、SDK等のいずれかから要求をを送信すれば、「Azure Resource Manager」はそれを受信して、要求の認証と承認を行います。承認後は、要求の内容が該当するAzure サービスに要求を送信します。
これらの処理は「API」を介してすべての要求を処理しています。そのため、異なるツールで一貫した結果と機能が得られま。
<2.Azure Resource Managerの利点>
- 1.スクリプトではなく、「宣言型のテンプレート」を使用してインフラストラクチャーを管理しています。
- 2.ソリューションのリソースは個別処理ではなく、グループにしてすべてのリソースを監視、管理、デプロイしています。
- 3.ソリューションを開発のライフサイクル全体で再度デプロイを行い、リソースは必ず一貫した状態でデプロイされます。
- 4.正しい順序でデプロイされるように、リソース間で定義づけがされています。
- 5.ロールベースのアクセス制御が管理プラットフォームに統合されているおかげですべてのサービスを制御できます。
- 6.リソースへのタグ付けでサブスクリプションのリソースを論理的に整理できます。
- 7.同一タグを共有化することでリソースグループを表示することで、組織の課金額を明確にできます。
<3.リソースグループの定義付け>
- 1.リソースグループ内のリソースはすべて「共有のライフサイクル」である必要があります。それらのリソースは一緒にデプロイ削除、更新されます。もし、サーバー等の1つのリソースが別のサイクル上に存在する必要がある場合は、別のグループに属する必要があります。
- 2.各リソースは1つのグループにのみ存在できます。
- 3.グループ外部に位置するリソースの管理はサブスクリプション、管理グループまたはテナントにデプロイされます。
- 4.リソースはいつでもグループに追加・または削除する事が可能です。
- 5.リソースは所属しているグループから別のリソースグループに移動することができます。
- 6.リソースグループでは、別のリージョンに配置したリソースを含めることができます。
- 7.グループの使用で、管理操作のアクセス制御のスコープの設定ができます。
- 8.2つの関連するリソースで同一のライフサイクルが共有されていない場合、他のリソースグループ内のリソースとやり取りができます。
<3.リソースの整合性>
<1.整合性の規範>
「リソースの整合性」はクラウド導入フレームワーグガバナンスモデル中のクラウドガバナンス5つの規範の1つになります。
内容はクラウド運用はリソース構成の一貫性に依存しているため、ガバナンスツールを使用して一家間した方法でリソース構成を成してオンボーディング、トラフト、検出可能性および復旧関連のリスクを管理することが可能です。
そもそも「クラウドガバナンス」とはクラウドプラットフォームの枠を超えた企業ポリシーの自動化と実施の適切レベルに関した意思決定の指針になります。
規範は「リソースの整合性」の他に、「コスト管理」「セキュリティベースライン」「IDベースライン」「デプロイ高速化」の規範が設けられています。
<2.ARMテンプレートの選択>
「ARM」とは「Azure Resource Manager」の頭文字を取った略称になり、Azureの核となるものです。
では、「ARMテンプレート」というのは「宣言型のテンプレート」の事を指しています。テンプレートはJavaScript Object Notation(JSON)ファイルになり、プロジェクトのインフラストラクチャーと構成が定義づけされています。そのため、テンプレートでデプロイしようとしているものを、テンプレートで作成する一連のプログラミングコマンドを記述しなくても記述できる「宣言型の構文」を使用しています。つまりは、デプロイするリソースとそられのリソースのプロパティをテンプレートを使用することで指定しているということです。
<3.ARMテンプレートの長所>
- 1.宣言型の構文
- 2.反復可能結果
- 3.オーケストレーション
- 4.モジュール式のファイル
- 5.Azureリソースの作成
- 6.拡張性
- 7.テスト
- 8.変更のプレビュー
- 9.組み込みの検証
- 10.デプロイの追跡
- 11.コードとしてのポリシー
- 12.デプロイのブループリント
- 13.CI / CDの統合
- 14.エクスポート可能なコード
- 15.作成ツール
テンプレート利用でAzureインフラストラクチャ全体を宣言方式で作成して、デプロイできめため。
同じテンプレートを何度もデプロイして同じリソースの種類を複製という形で作成できます。個別のテンプレートを多く作るのではなく、望ましい状態に提示するテンプレートを1つ作成できます。
相互依存するリソースのデプロイによつて正しい順序で作成がされます。Resource Managerでは可能な箇所でリソースが並列デプロイされます。つまり、直列デプロイに比べて並列デプロイでは短時間でデプロイが完了します。
テンプレートを再利用可能な構成部品に細分化して、デプロイ時にリンクさせられます。
テンプレートの利用で、Azureの新しいサービスや機能をすぐに利用できます。リソースプロバイダーによって新しいリソースが導入されると、即対応してそれらのリソースをデプロイします。
デプロイスクリプトの使用で、デプロイ時にリソースを設定する機能が拡張されます。それにより、スクリプトは、テンプレートに含めたり、外部ソースに拡張してテンプレート内で参照したりもできるようになります。
ARMテンプレートツールキットを使用することで、テンプレートが水使用ガイドラインにしたがって動作しているかテストができます。テストキットはPowerShell Scriptであり、GitHubからダウンロードが可能です。
テンプレートをデプロイする前に「what-if操作」を使用して、変更のプレビューを取得できます。「what-if操作」で、どのリソースが作成、更新、削除されたのかを表示して環境の状態を知ることによって状態管理の必要を省けます。
テンプレートはデプロイする前に一度検証し、合格が出ないことには使用することはできません。
portalでデプロイの履歴を確認して、テンプレートのデプロイ情報の取得ができます。デプロイされたテンプレート、割り振られたパラメーター、その他すべての出力値の確認もできます。また他のコードとしてインフラストラクチャサービスの追跡はできません。
ガバナンス自動化のためのコードフレームワークとしてのポリシーです。
Microsoftが提供するブループリントを活用することで、規制やコンプライアンスの基準を満たすことができます。
テンプレートを継続的にインテグレーションと継続的配置ツールである「CI / CL」に統合することができます。統合によって、「高速かつ信頼性の高いアプリケーションとインフラストラクチャの更新の実行」や「リリースパイプラインの自動化」が行えます。
現在のリソースグループの状態をエクスポートするか、特定のデプロイに使用したテンプレートを表示して既存のグループをテンプレートとして、取得ができます。
テンプレートの作成は「Visual Studio Code」と「テンプレートツール拡張機能」で作成することが可能です。
<4.導入フェーズで活躍するリソース>
- 1.戦略
- 2.プラン
- 3.Ready
- 4.ガバナンス
- 5.管理
- 6.整理
リソース | 説明 |
・クラウド導入家庭トラッカー | ・ビジネスのニーズ基づいてクラウド導入パスを特定します。 |
・戦略と計画のテンプレート | ・クラウド導入の戦略と計画をじっひうするための決定事項を文書化します。 |
リソース | 説明 |
・クラウド導入家庭トラッカー | ・ビジネスのニーズ基づいてクラウド導入パスを特定します。 |
・戦略と計画のテンプレート | ・クラウド導入の戦略と計画をじっひうするための決定事項を文書化します。 |
・クラウド導入計画ジェネレーター | ・導入計画テンプレートを使用して、Azure Boardsにバックログをデプロイしてプロセスを標準化します。 |
リソース | 説明 |
・適合性チェックリスト | ・導入のための移行ランディングゾーンの準備やブループリントのカスタマイズ等の環境の準備を行います。 |
・名前、タグ付けの追跡テンプレート | ・一貫性を確保して、オンボードする時間の短縮を行うために名前・タグ付けの基準に関する決定事項を文書化しておきます。 |
・CAF基盤ブループリント | ・最初のガバナンス基盤となる軽量な実装を利用してガバナンスツールの経験を提供してくれます。 |
・CAF移行ランディングゾーンのブループリント | ・オンプレミス環境からAzureに移行されるワークロードをホストするためのプロビジョニングの準備を行います。 |
・Terraformモジュール | ・TerraformバージョンのCAFランディングゾーン用のオープンソースコードベースです。 |
・Terraformレジストリ | ・フィルター処理されたTerraformで、ランディングゾーンの作成を行うために必要なクラウド導入フレームワークモジュールのすべてが一覧表示されます。 |
リソース | 説明 |
・ガバナンスベンチマーク評価 | ・現在の状態と仕事上の優先順位とのギャップを特定して対処するリソースを取得します。 |
・CAF基盤ブループリント | ・最初のガバナンス基盤となる軽量な実装を利用してガバナンスツールの経験を提供してくれます。 |
・ガバナンスプロセステンプレート | ・ガバナンスの各軌範を適用化するために使用され、ガバナンスプロセスの基本セットを定義します。 |
・コスト管理プロセステンプレート | ・コスト管理に焦点をおいて、組織内のクラウドガバナンスを成熟させられるポリシーステートメントと設計ガイダンスを定義します。 |
・IDプロセステンプレート | ・IDの要件に焦点をおいて、組織内のクラウドガバナンスを成熟させられるポリシーステートメントと設計ガイダンスを定義します。 |
・リソース整合性プロセステンプレート | ・リソースの整合性に焦点をおいて、組織内のクラウドガバナンスを成熟させられるポリシーステートメントと設計ガイダンスを定義します。 |
・デプロイ高速化プロセステンプレート | ・デプロイの高速化に焦点をおいて、組織内のクラウドガバナンスを成熟させられるポリシーステートメントと設計ガイダンスを定義します。 |
・セキュリティベースラインプロセステンプレート | ・セキュリティベースラインに焦点をおいて、組織内のクラウドガバナンスを成熟させられるポリシーステートメントと設計ガイダンスを定義します。 |
リソース | 説明 |
・Microsoft Azure Well Architected Review | ・ワークロード固有のアーキテクチャと操作に関するオプション定義に役立ちます。 |
・ベストプラクティスソースコード | ・デプロイ可能なソースコードを、Azureサーバー管理サービスについてのベストプラクティスとして補完して導入を促進させるものです。 |
・運用管理ブック | ・クラウドの運用管理に関する決定事項を文書化して、ビジネス部門においての会話の促進をすることで、SAL、回復性への投資、運用に関する予算の割り当てに関する整合性の確保につながります。 |
リソース | 説明 |
・チーム間のRACIダイアグラム | ・組織構造の決定を経済的に追跡することで、RACIスプレッドシートテンプレートをダウンロードし、変更します。 |
<4.まとめ>
Azureのリソースをまとめる「リソースグループ」にそしてそれをさらにまとめあげる「Azure サブスクリプション」はまるで「会社の組織図」のような見取り図であるというイメージを持っておくと分かりやすいです。
さらに「ARMテンプレート」を活用することで、誰でも簡単にAzure リソースを利用することができ、なおかつ導入時の時間的コストの削減にも繋がります。