Azure — 基礎から設計・運用へ

前提: AWS導入章。同じ学習ポータルをAzureで設計する。

1. 管理階層とIDを先に理解する

Azureでは、Microsoft Entra IDのテナントと、サブスクリプション・リソースグループ・リソースの関係を理解する。 テナントはID管理の境界。サブスクリプションは課金やリソース管理の単位で、リソースグループは関連リソースを管理するまとまり。 管理グループを使うと複数サブスクリプションに統制を適用できる。 これらをAWSアカウント一つに対応付けると、ID・課金・管理の違いを見失う。

Azure Resource Managerがリソースのデプロイ・管理を担い、Azure RBACでスコープを指定して操作権限を割り当てる。 同じ環境で一緒に管理するアプリ資源をリソースグループへまとめ、担当者の操作範囲を設計する。Resource Managerの概要

アプリにはマネージドIDを利用する構成を候補にし、対応サービスへの認証情報をコードに埋め込まない。 リソース作成などの管理操作と、Blob内容の読取などのデータ操作は必要な権限が異なる。 「Contributorだからあらゆるデータを読める」とは考えず、対象サービスのデータ権限を確認する。

課題: 開発用サブスクリプション、ポータル用リソースグループ、運用担当、アプリのマネージドIDを図にする。 権限表には主体・ロール・スコープ・用途を書く。利用者のアプリログインも別の線で描く。

2. VNet・サブネット・公開範囲

VNetはリージョン内の仮想ネットワーク。サブネットはAWSのように一つのAZへ固定する単位ではない。VNetと可用性ゾーン NSGで通信を制御し、経路、サービスのネットワーク統合、公開アクセス設定を合わせて読む。 Private Endpointは対象サービスへのプライベート接続で用いるが、名前解決も含めて構成する必要がある。

利用者 → Entra IDによる認証 → HTTPS入口 → アプリ実行基盤
                                            ├→ 進捗DB
                                            └→ Blob Storage
                     アプリのマネージドID ─→ 必要なデータ権限

VNet内にVMを置く構成と、App ServiceなどからVNetへ接続する構成は同じ手順ではない。 入口の制御と、アプリからDBへの出口の制御を分けて描く。 AZ対応やゾーン冗長の設定はサービスとリージョンごとに確認する。Azureの可用性ゾーン

3. 実行基盤を選ぶ

ポータルではApp ServiceまたはContainer Appsを候補にし、必要な実行形式とネットワーク要件から選ぶ。 マネージドサービスでも、プランによって可用性・ネットワーク機能・費用が変わるため、名前だけで要件充足を判断しない。

4. データと運用

教材はBlob Storage、進捗はAzure SQL DatabaseやAzure Database for PostgreSQLを候補にする。 SQLの方言、既存アプリとの互換性、バックアップと復元、認証方式からDBを選ぶ。 Cosmos DBは分散データベースの候補だが、API、パーティション、整合性、リクエストの課金を理解してから採用する。

Azure Monitorで稼働を観測し、Log Analyticsでログを調査し、Application Insightsでアプリの振る舞いを追う。 Activity Logによる管理操作の記録と、アプリ・データアクセスのログは用途を分ける。 Key Vaultで秘密情報や鍵の管理、Azure Policyで構成の統制、Cost Managementで費用の把握を検討する。

可用性設計は、実行基盤のゾーン対応、DBの冗長化、ストレージの冗長方式、IDと入口の依存関係まで確認する。 復旧訓練では別の復元先を使い、アプリの接続先と権限を変更して読取・更新を確認する。

5. 設計演習

次の成果物を作る。実環境へのデプロイはまだ行わない。

1. 管理階層と通信経路を別々に描く。
2. 実行基盤一つ、RDB一つ、教材保存先を選ぶ。
3. アプリ用IDに必要なデータ権限を一覧にする。
4. 外部公開の設定、プライベート接続、DNSの確認箇所を書く。
5. ログイン失敗、DB接続失敗、教材取得失敗をどの情報で切り分けるか決める。

解答例: 開発用の管理単位にApp Service、PostgreSQL、Blob Storageを配置する。 Entra IDで利用者を認証し、アプリのマネージドIDへ必要なデータ権限を割り当てる。 DBへのネットワーク接続とDNSを設計し、利用するプランの機能を確認する。 アプリログ、依存先の失敗、管理操作の変更履歴を照合できるようにする。 可用性要件はこのサービス名の選択だけでは保証されないので、配置・冗長化・復旧条件を設計メモに追記する。

理解度チェック

次: Google Cloud