はじめに

5月ぐらいから業務でAzureを触り始めたので、せっかくならと思い資格を取ることにしました。
前回に「AZ-900」を受験して合格したので今回は「AZ-104: Azure Administrator Associate」を受験しました。
難易度は、中級程度？やや高め？ぐらいだと思います。Azureの主要なサービスの基本概念、デプロイ、管理、監視について幅広く求められます。

ただの備忘録ですが、Az-104を受ける人の情報源になればと思います。

2021/09/11 に無事一発合格しました
オススメはUdemyで過去問をやることに限ります！(英語の問題ですが、、Azureって日本語の教材少なすぎる、、)
実技があるみたいなうわさがありますが、私が受けたときはなかったです

出題範囲

分野	割合
Azure アイデンティティおよびガバナンスの管理	15-20%
ストレージの作成と管理	15-20%
Azure 計算資源の展開と管理	20-25%
仮想ネットワークの構成と管理	25-30%
Azure 資源の監視とバックアップ	10-15%

個人的に、「Azure Backup」、「Azure Import/Export」、「Azure File Sync」、「Network Watcher」、「App Service プラン」あたりが良く出題されているように感じました(問題集より)

【ユーザーに権限付与する方法】

(1) RBAC (Role-based Access Control) : ロールを通してユーザーのアクセス許可を制御
(2) PIM (Privileged Identity Management)

セキュリティプリンシパルへのロールの割り当てを永続ではなく期限付きにできる
PIMを使用するならAzureAD側で設定し、永続ロール割り当てはリソース側で行う
PIMは、P2ライセンスで使用可能、サイバー攻撃対策の1つ
ユーザーがロールをアクティブ化する際に上司の承認を要求したり、MFAを要求したりできる

【ロールの割り当て】

①セキュリティプリンシパル→誰に対して (ユーザー/グループ/サービスプリンシパル/マネージドID)
②ロール定義→ どのようなアクセス権を
③スコープ→どのリソースを対象に (管理グループ/サブスクリプション/リソースグループ/リソース)

ロール名	Read	Create/Delete/Update	アクセス管理
所有者(Owner)	o	o	o
共同作成者(Contributor)	o	o	x
閲覧者(Reader)	o	x	x

Contributorロールでは、Azure RBACでロールを割り当てることはできない→Ownerロールを割り当てる
VM Contributor ロール : VMを管理できるが、VMへのアクセスや接続されているVNetやストレージアカウントへのアクセスはできない
traffic analytics : Owner, contributor, reader, network contributor
2つのテナント間で同期はできない (ただし、ゲストユーザーとしては招待できる)
Azure AD テナントを単体で取得することはできない(Azureサブスクリプションやoffice365にサインアップした際に取得)
User administrator + Global administrator →ユーザーの追加・削除できる
新しいテナントを作成したユーザーのみそのテナントに追加され、グローバル管理者となる(ほかの人は新しいテナントにアクセスできない)

【タグ】

リソース/RGは、MAX50個のタグをもてる
RGに通用されたタグはリソースには継承されない
ただし、PolicyをRGに適用すればタグはリソースにも適用される
Policyを適用してタグを割り当てても、すでに存在してるものには意味なし
Policyは更新や作成されたタイミングで適用(移動されてきたリソースも意味なし？)

【ストレージサービス】

ストレージアカウント

Azureストレージサービスの管理単位
各ストレージサービスに対し、一意の名前空間を割り当て
コストを下げたければ、アクセス層も考慮(hot→cool)
4つのストレージがある

(1) BLOBストレージ : オブジェクトストレージ
(2) Azure Files : SMB3.0でのファイル共有
(3) Tableストレージ : NoSQL
(4) Queueストレージ : メッセージング機能

*BLOBストレージには３種類ある
①ブロックBLOB : ドキュメント、メディア、BUに適した
②追加BLOB : ログ
③ページBLOB(Disk) : ランダムアクセスをサポート(VHDファイルはこれ)

エンドポイント
https://<ストレージアカウント名>.blob.core.windows.net/
https://<ストレージアカウント名>.file.core.windows.net/
https://<ストレージアカウント名>.queue.core.windows.net/
https://<ストレージアカウント名>.table.core.windows.net/

アカウント(基本的にストレージアカウントは汎用V2でok)

(1) Blobストレージアカウント

ブロックBLOBと追加BLOBに特化したストレージアカウント(その他は使えない)
クール、ホット、アーカイブのアクセス層を選択できる
現在、汎用v2で同様のアクセス階層の制御が可能のため、Blobストレージアカウントを使用する場は無くなってきた

(2) 汎用v2ストレージ (汎用v1 ＋Blobみたいな感じ)

Blob, Files, Queue, table, Disk用のアカウント(基本的このストレージアカウントを推奨)
料金体系もBlobストレージと同等
ZRS対応しているのは汎用V2のみ

【レプリケーション】

(1) LRS(Local Redundant Storage):ローカル冗長ストレージ

１つのDC(データセンター)にデータのコピーが３つ作成 (1リージョン3レプリカ)
DC全体が利用できなくなったら、データ利用不可
SLA : 11ナイン

(2)ZRS:ゾーン冗長化ストレージ

リージョン内のDCに非同期でレプリケート
3データセンターに１つずつ複製させる(１つのリージョン内)

(3)GRS(Geographically Redundant Storage):地理冗長ストレージ

ローカルコピーの３つ(同じデータセンター内)に加え、別のリージョンにさらにコピーが３つ(同じデータセンター内)保持される
プライマリゾーンで障害が発生すると、セカンダリリージョンにフェールオーバーして業務が継続可能
２リージョン、６レプリカ

(4)RA-GRS: 読み取りアクセス地理冗長ストレージ

GRSに加えて、セカンダリリージョンにあるデータへの読み取りアクセスができる
プライマリが利用できない状態になったとき、セカンダリからデータを読み取る

(5) GZRS : Geoゾーン冗長ストレージ

３つのデータセンターにそれぞれ複製され、セカンダリリージョンのある１つのデータセンターに3つ分レプリケーション

(6) RA-GZRS : 読み取りアクセスgeoゾーン冗長ストレージ

ZRS+GRSの機能を提供

【Azure File Sync】

まず、Azure Filesとは？

フルマネージドのファイル共有サービス
コンテナを永続的に置くところとして使われる

使い方① : サーバーレスのAzureファイル共有をマウント
使い方② : Azure File Syncを使用してAzureファイル共有をwindowsサーバに同期

Azure File Sync

オンプレミスのファイルサーバーで管理しているファイルをAzure Filesに同期するサービス
SMB, NFS, FTPSなどのプロトコルを使用しオンプレミスのサーバーへアクセス
Azure Fileサービスでは、容量に対する課金に加えてアクセス量による課金がある

手順
(1) ストレージアカウントの作成
(2) ストレージアカウントの「ファイル共有」にファルダ作成
(3)サーバにAzure File Sync Agent をインストール

Agentをインストールすると認証が求められるので、先ほどAzure ファイル共有を作成したアカウントでサインイン
(Azure Subscription, RG, Storage sync Serviceを選択)
登録済みサーバーにあればOK

(4) 「リソースの作成」 → 「Azure File Sync」を選択し、「＋同期グループ」を選択

ここでクラウドエンドポイントは選択する
「Azureファイル共有」では作成したAzure ファイル共有を選択→これがクラウドエンドポイント
同期グループでは１つのクラウドエンドポイントと複数のサーバーエンドポイントを設定

(5) 「同期グループ」→「サーバーエンドポイントの追加」

サーバの同期させるフォルダ「登録済みサーバー」から選択
登録されたサーバーをプルダウンから選択し、サーバの同期させるフォルダへのパスを入力

メモ

Azure File Syncでは同期サーバーからの変更は即時エージェントにより同期されますが、Azure Filesからの変更は24時間に1回しか同期されない
ストレージアカウントはAzure File Syncと同じリージョン

同期グループ(Sync Group) : 同期するクラウドエンドポイントとサーバーエンドポイントの紐づけ
クラウドエンドポイント : 同期をとる際のクラウド側の同期先パス
サービスエンドポイント: 同期をとる際のサーバ側の同期先パス

【Azure Import/Export】

物理ディスクから、Azure blob StorageとAzure Filesに大量のデータをインポートできる
汎用v2のストレージアカウント推奨
ジョブごとの利用可能な最大ディスクドライブは10台
Import/ExportにSLAはなく、ベストエフォート対応
windowsシステムでBitLockerを有効にする必要がある

サービス	対応ストレージ
Import	Blob, File
Export	Blob

WAImportExportツール : ドライブの準備および修復用のツール
dataset.csv : コピーするディレクトリの一覧またはファイルの一覧を含むcsvファイ
driveset.csv : マップされるディスクの一覧を含むcsvファイル

①Azure Import手順 (Blob or Files)

(1) サーバー(windows)に外付けハードディスクをとりつけ、waimportexport.exeでデータをディスクドライブにコピー(データはBitLockerで暗号化される)
(2) Azure Portalで、インポートジョブを作成(ドライブのジャーナルファイルをupload)
(3) 外付けディスクをAzureのデータセンターに発送
(4) Azure Portalからインポートジョブを更新
(5) ディスクドライブが返送される

②Azure Export (Blobからのみ)

【Desired State Configuration (DSC)】

構成管理ツール
ps1ファイルに「こうあってほしい状態」を記述しておき、それを実行することで書かれている通りの状態に構成
Azure Automation State Configuration サービスへのVMのブートストラップ
使用例としては、ARMテンプレートとDSCを組み合わせて、テンプレートのデプロイ時にAzureVMにDSC extentionをインストールしDSC用のスクリプトを実行してos設定を自動するなど

構成を特定の状態に保持続けるための仕組み

あるべき状態を定義
定義に基づいて設定を変更
定期的に設定をチェックし正しい状態を維持

Azure Automation State Configuration使用

(1) 構成ファイル(XXX.ps1)をAzure Automation State Configuration にupload
(2) 構成をノードの構成としてコンパイルする (Set-AzAUtomationDSCCompilationJob)
(3) 管理されるVMを登録する
(4) コンパイル済みのノード構成を管理対象ノードに割り当て
(5) 管理対象ノードの準拠状態を確認する

【Azure Container Networking Interface (CNI)】

Azure VNetからnodeとPodにIPを割り当てる
すべてのPodがサブネットからIPアドレスを取得し直接アクセスできる
すべてのAzure VNet に存在するために他のAzureやオンプレミスのリソースにルーティングできる
すべてのIPアドレスがVNetから割り当てられるので、十分な数のIPを提供できるサブネットが必要
AKSまわり

【Azure Kubernetes Service (AKS)】

AKS自体の利用やk8sクラスターには料金がかからないということ
k8sのノードの利用に対してだけ課金を行う
簡略化されており、自動アップグレード、スケーリング、自己修復などを簡単に操作なしに利用することできる
マスターはAKSによって管理されるが、ノードは自分で管理する必要あり
コンテナランタイム: AKSではDockerでなくMobyを使用
[$az aks get-credentials] : ~/.kube/config の取得

#[CLI]クラスタの作成
$ az aks create -n クラスタ名 -g RG -l リージョン --kuberbetes-version 1.7.7 --generate-ssh-keys

#[PowerShell]Create or update a k8s cluster
$ Set-AzAks XXX

#クラスタの証明書取得
$ az aks get-credentials -n クラスタ名 -g RG

#コンテナをAKSにデプロイ
$ az acr build --image XXX --registry XXX --file Dockerfile

#autoscale パターン①
$ kubectl autoscale deployment azure-vote-front --cpu-percent=50 --min=3 --max=10

#autoscale パターン② (マニフェスト利用)
$ kubectl apply -f XXX.yaml

【ロードバランサ】

Basic LBとStandard LBがある
Basic LBは、SLAなし、バックエンドプールは単一の可用性セット or VMSS
Standard LBは、SLA(99.99)で、バックエンドプールに単一のVMもOK

バックエンドプール

VM, VMSSを追加できる(Standard LBの場合)
- Public IPを持っているか
- Public IPなしで同じ仮想ネットワーク上にあれば

*VMにPublic IPアドレスが付与されている時は、候補としてVMが表示されないため、Public IPはデタッチする必要あり

LBがバックエンドプールで管理しているのは、VMではなくNICのIP構成

スティッキーセッション(セッションアフィニティ)

ユーザーのセッションを特定のターゲットにバインドするように設定
ユーザーのセッション中のすべてのリクエストが同じターゲットに送信される
クライアントに連続したエクスペリエンスを提供するために状態情報を維持するサーバーに役立つ
使用するにはクライアントがcookieをサポートする必要がある

高可用性(HA)ポート

負荷分散規則の一種
stanrdardで対応、Basicでは使用不可
内部standard Load Balancerのすべてのポートに到着するすべてのフローの負荷分散を簡単に行う方法を提供

Direct Server Return(DSR)

LBの機能のひとつ
クライアントからLB経由でアクセスすれば応答も、サーバ→LB→クライアントとLBを経由する
DSRを使うとLBを経由せずサーバ→クライアントに直接応答がいく
LBの負荷分散規則の設定のところで選択できる
LB側での処理が必要なくなりシステム全体としてスループット向上

Floating IP

クラスタリング構成の複数のサーバがあるときに、クライアント側にサーバが切り替わったことを意識させないように、クラスタ内で共有してもつ仮想IPのこと

インバウンドNATルール

接続時のポート番号が一般的なポート番号を使わなくて済むため、ポート番号を知らないとアクセスできない状態になる
接続時のポート番号をサーバーごとに分けるので、目的のサーバーに必ず到達することができる
LBでPort番号を変換 = インバウンドNAT ex) 5000→22

【ARM template と DSC を用いた構成管理】

ARM

リソースを作成・更新・削除する管理サービス
PF or API的な立ち回りをしてくれるのですべての異なるツールに一貫性をもたせることができる

ARM Template

デプロイしたいAzureのリソース、その設定値などをJSON形式で書いておく設計図みたいなもの
同じ環境を繰り返し作りたいときに便利
パスワードとかは、Azure Key Vaultへ

sample.json


{
   "$schema":
   "contentVersion":
   "parameters":{},
   "variables":[],
   "outputs":[],
}

①ARMテンプレートでイメージからVMをデプロイ
②Blobストレージにおいてあるzipファイルをダウンロード (XXX.ps1とDSCモジュールをzip化しておく)
③デプロイされたVMで先程のファイル(ex:setup.ps1)が実行され、OSの設定が行われる

ARM template デプロイ

$ az deployment group create -g NameGroup --template-file template.json

or Portalから「テンプレート」で検索、[＋追加] → [展開]

Automation DSC
システムの構成・制御・デプロイを行う宣言型のPFであるPowerShell DSCとAzure Automationの機能によって、リソースの幅広い範囲の一貫したデプロイ・監視・更新ができる

LCM(Local Configuration Manager)
→ノードの状態の取得・必要な状態との比較、構成の実現をする
→ApplyOnly, ApplyAndMonitor, ApplyAndAutoConnect

【Azure Automation】

Azure Portal上のサービスでPowershellスクリプトを定期実行するためのサービス
Powershellでできることはすべて自動化
タスクがユーザーの操作を必要としないときやタスクが繰り返し行われるとき使用すべき

できること

VMを作成し、異なるAzure環境にコピー
VMをBUし、シャットダウン
Azure webサイトの環境設定をリモートで更新
VMの自動停止と自動起動 (業務で使用料抑えられる)

Automation アカウント

Azure ADに作成されるAutomationリソースのサービスプリンシパル(システム用のアカウント)
RunbookスクリプトでAzureリソースを管理するためにはAzure AD認証が必要

【azcopy】

AzcopyではBlobとFileをサポート

ストレージ	認証方式
Blob	Azure AD, SAS
File	SAS

$ azcopy copy LOCAL-FILE-PATH https://az104data.blob.core.windows.net/public --recursive #ソースデータをコピー先の場所にコピーする
$ azcopy make 'https://mystorageaccount.blob.core.windows.net/XXXX' #コンテナー or ファイル共有を作成
$ azcopy sync #元の場所を同期先の場所にレプリケートする

SAS(Shared Access Signature) トークン

基本的に、IP制限、トークンの有効期限、ファイルやデータ書き込み、読み取り等の制限が可能
コンテナへのアクセス許可、特定のファイルへのアクセス許可など細かくアクセス制御することができる

【Firewall】

動作箇所 : ネットワーク境界(インターネットor VNet とVNetの境界)
対象レイヤー: L3/L4＋L7
FQDNによるフィルター処理
SNAT,DNAT使用可能 →FWではVMにパブリックIPが割り当てられていない場合でも、SNATやDNATの機能によってFWのPublicIPを利用することでVMとインターネットとの間で通信できる
有料
サブネットは、AzureFirewallSubnetという名前に必ずする
AzureFirewallSubnetは、プレフィックス25以下
FWを経由させるにはルートテーブルを使用

【Network Security Group : NSG】

[既定の受信] : VNet & LBからのトラフィックのみokay
[既定の送信] : インターネット& VNetへのトラフィックのみokay
VMのインバウンドとアウトバウンドトラフィックをフィルタリングできる
NSGがないと全てのインバウンドとアウトバウンドのアクセス許可される
Network WatcherのNSGフローログ機能を使用して、NSGを通過するネットワークトラフィックをログに記録することができる

【Application Security Groups: ASG】

NSG : 宛先と送信先を指定する際、IPアドレスとセグメントの指定をする。同じサブネットに複数の用途をもつVMが共存している場合、IPアドレスをNSGに直接記載
ASG : NIC単位でグループ化して、グループ単位で送信/受信を定義することできる
個別にNSGを設定しなくても、細かく制御することが可能になる

【Network Watcher】

Azure Vnet内のリソースの監視・診断・メトリックの表示・ログの有効化/無効化を行うツール
既定で有効

(1)IP Flow Verify(ネットワーク診断)

NICとsubnetに適用したNSGの通信可否をシミュレーションできる
送信元及び宛先IPv4アドレス、ポート、プロトコル(TCP/UDP)、トラフィックの方向(受信または送信)を指定し接続テストを行う
アクセスを拒否される時は、NSGに問題がある

(2)接続モニター(監視)

サーバ間(VM間)での通信可否とRTTを継続的に測定し続ける→一回だけなら、「接続のトラブルシューティング」
VMとIPアドレス間のネットワーク接続を監視する (死活監視)
定期的な間隔で通信を監視し、VMとエンドポイントの間の到達性・レイテンシー・ネットワークトポロジー変更通知
エンドツーエンドの接続監視
ソースに指定するVMにはNetwok Monitorエージェントがインストールされている
アラートの作成もできる

(3) ネットワークパフォーマンスモニター (監視)

ネットワークパフォーマンスを監視
OMSエージェント間でネットワークの接続性やExpressRouteの性能監視をする機能を備えている

(4)NSGフローログ(ログ)

NSGを介して送受信するIPトラフィックの情報をストレージアカウントに格納する

(5) 接続のトラブルシューティング(ネットワーク診断)

接続モニターの一回バージョン
VM→VM TCP接続確認できる、到達の可否、接続時の待機時間
Azure上のVMから宛先を指定して実行すると、VMにログインをしなくてもネットワークの接続性を確認できる
到達できなかった時の接続障害
→ Memory, GuestFirewall, DNSResolution, NetworkSecurityRule, UserDefinedRoute

(6) VPNのトラブルシューティング

VPNゲートウェイと接続の正常性を診断するツール
診断結果はストレージアカウントに保存される
診断がサポートされているGWはルートベースのGWのみ

(7) 使用量＋クォータ

サブスクリプションで使用しているネットワーク関連リソースの使用状況とクォータを確認できる
大規模な構成になってくるとパブリックIPが頭打ちになんてことがあるので確認できる
クォータ引き上げの依頼もこの画面からサポートリクエストを上げられる
通信しているホストごとや、利用されているアプリケーションごとの分析も自動で行われる
これをもとにNSGルール更新すれば、good.

(8) トラフィック分析

Log Analyticsを利用したトラフィック分析が可能
トラフィックを可視化し、悪意のある攻撃の規模や傾向を推測するのに役立つ

【VNet間を繋ぐ】

(i) サイト間(IPsec)

(1) gatewayサブネット作成
(2) local gateway作成
(3) VPN gateway作成
(4) VPN 接続

(ii) Vnet間

(1)VNet作成
(2)VNetGWの作成 (接続先となるVNetでも同様にGW作成)
(3)接続

Local Network Gatewayのアドレス空間は自動的に作成され、設定される

GWの種類 : (1) VPN(IPSec) (2) Expressroute(専用線)

(iii) VNetピアリング

Azureの仮想ネットワーク同士を、Azureのバックボーンを使用して接続する機能
複数の仮想ネットワーク同士をGWなしで簡単に接続できる
Azure Portalで [仮想ネットワーク]を選択し、[ピアリング]→ [+追加]で設定可能
[GW転送を許可する]→ 自身のVNet内のVPNゲートウェイの転送を許可
[リモートゲートウェイの使用] → デフォルトルートとしてピアリング先のVPNゲートウェイを利用
両方のVnetでピアリングの状態が「接続済み」になればOK
VNetが他のVNetとピアリングしている場合、VNetのアドレス空間にアドレス範囲を追加した利、アドレス範囲を削除したりすることはできない

【Azureとオンプレミスの接続】

(i) 【Expressroute】

回線事業者が提供する専用線を使用した通信 (安心・安全・高品質)
対応するには、ExpressRouteに対応している回線事業者との契約が必要
ExpressRoute回線に接続できるVNetの数 : 既定 10
ExpressRouteを介してAzureのサービスを利用するためには、サービスに応じたピアリングを構成する必要がある
ルータ間で冗長化されており、単一障害時にも通信を継続
PaaS、SaaSでも利用できる

(ii) 【サイト間接続】

Vnet側に
　　　- ①仮想ネットワーク
　　　- ②Local Network GW
　　　- ③仮想ネットワークGW**を作成
「接続」を設定

Local Network Gateway

オンプレミス拠点の情報を設定するリソース
例) Public IP, オンプレのアドレス空間など

(iii)【ポイント対サイトVPN接続 (クライアントPC ⇆ Azure)】

クライアント端末から直接Azure上のVPN gatewayに対してVPN接続を行うサービス
Point2siteをVPN接続→証明書を使用して認証
ルートベースでないとダメ (ポリシーベース✖︎)

手順
①VNet作成
②ルート証明書＆クライアント証明書の作成
③仮想ネットワークゲートウェイ作成
→ゲートウェイサブネットと呼ばれる専用のサブネット作成 (/27, /28ぐらいがおすすめ)

P2S構成で (1)アドレスプール (2)トンネルの種類 (3) 認証の種類 (4) ルート証明書を設定 (Azure側)
クライアント証明書は、ルート証明書に紐づくように作成、形式は.pfx
アドレスプール＝VNetのアドレス空間、オンプレと被らないように
この方法は、固定IPもルータなどのVPNデバイスもいらない
テレワークとかに向いてる、複数のクライアントからのネットワーク接続とかいうパターンも

【VPN】

種類
①Route-based: 動的 / IKEv2 (基本的にこっち)

接続するIPによって別のIPsecトンネルを利用する
ポリシーベースより柔軟性に優れているから基本的にはこちらを使用

②Policy-based : 静的 / IKEv1 (1拠点しか接続できない)

1つのIPSecトンネル上で、暗号化通信を行うIPアドレスを静的に指定
実用的ではない
Basicでのみ使用可能

VPN Protocol : SSTP, OpenVPN, IKEv2
証明方式 : 証明書、RADIUS, AzureAD認証
SKU(Route-based) : Basic,VpnGW1, VpnGW2, VpnGw3

【App Service plan】

複数のアプリを入れる箱みたいなもの＝ VMととらえてよい
新しくwebアプリを作成するときには必ずApp Service プランを選択 or 新たに作成する必要あり
課金はApp Serviceには一切かからず、このApp Serviceプランにかかる
いつでもハードウェアのプランを変更することができる
App ServiceプランがFree, Basicの場合はコンピューティングリソースは他のユーザーと共有になるため、クォータ制限がある
本番環境では、コンピューティングリソースがユーザー専用となるStandardプラン以上を推奨

App Service Environment

App Serviceプランには、１つだけ特殊なisolatedというプランがある
App Service Environmentで利用するためのApp Serviceプラン
App Serviceをユーザー独自のVNetにデプロイし専用環境でアプリケーション実行を可能にする

賢い使い方

高いSLAが必要な場合は、アプリは単独・少数のアプリを入れたApp Service Planに分離する
Health Checkを有効にする
リージョンごとに同じアプリをデプロイして、Traffic ManagerやAzure Front Door等でリスク分散する

スロット

standard以上が必要
同じ名前の別アプリみたいなもの(Production, Staging, dev)
スロットスワッピング : 仮想IPスワップを実現するようなサービスで主にFQDN以外の要素を切り替えることができる (StagingとProduction環境をURLはそのまま、中身だけを変える)
デフォルトだと、運用スロット(production slot)がひとつのみ
デプロイ後にサーバー上でのビルド処理が走るようなケースでは、少なからずダウンタイムが発生→デプロイスロットを使う
複数のデプロイメントスロットを有効にするにはアプリがStandard, Premium, Isolatedのいずれかでないとダメ(errorならscale up the App Service Planをする)

kudo

App Serviceにデプロイしたり簡易診断するのに重宝する便利な機能
kudoは１つの独立したウェブアプリなので、デプロイしたりkudoセッションを使うとアプリ本体とkudoアプリの２つが計算資源を共有した状態となる

【App Service】

OSやミドルウェアのインストール、管理が不要であり、ビルド済みのアプリケーションをgitやsftpなどでApp Serviceにデプロイするだけでアプリを公開できる
web Apps, Mobile Apps, Logic Apps, API Appsの総称
セキュリティや負荷分散、自動スケーリングなどはサービスとして提供されているため、独自に実装することはなく、設定を変更するだけで柔軟に環境を構築できる

【Azure Private Link】

オンプレミスからAzure PaaSへプライベート接続できる
Azure PaaSは、基本インターネット経由でアクセス(PaaS上で機密情報をもつならダメ)
Azure PaaSのFWがあるが、結局はインターネットを経由するのでよくない
Private Linkは、ExpressrouteやVPN GW経由でPaaSに接続できる ←サービスエンドポイントとの違い

流れ
①オンプレ→ private endpoint
②private endpoint → private link
③private link → 各PaaS

【サービスエンドポイント】

VNet内の特定のネットワーク範囲から直接PaaSにアクセスする仕組みを持っている
Azureのバックボーンを利用した直接接続を行うことで、インターネットへのアクセス制限を行いながら安全な接続
Public IP が不必要になる

【Recovery Services】

以下の2つを利用するにはRecovery Service コンテナー (Recovery Service Vault)の作成が必要

バックアップデータを格納する入れ物
ストレージエンティティみたいなもの
IaaS VMやAzure SQLデータベースなどの様々なAzureサービスのBUデータが格納される
blobをバックアップできない、Fileのみ

*Recovery Services Vaultを削除する前に *
(1) バックアップ停止
(2) 登録済みのストレージアカウントがすべて削除されていることを確認
(3) 削除

(1) Azure Backup

基本は、Azure VMを丸ごとバックアップ。複数ディスクがあってもすべて取得
Azure Backupによって、VM上で実行されているAzure VMエージェントに、バックアップ拡張機能がインストールされる
agentを導入することで、フォルダ/ファイル単位にバックアップ可能
バックアップスケジューラーを設定することで、定期的な取得が可能
オンプレミスのデータもAzureにバックアップ可能(MARSエージェントを用いて、Linuxはサポートなし)
リストアは別VMとして復元
他のリージョンは復元できない
Recovery Service Vaultでカスタム定義されたバックアップポリシーを使用している。保存されているデータを消したいならバックアップポリシーを変更
コンテナが消せないなら、そのコンテナはバックアップデータを受信するように設定されている
Azure Backupを使用すると、バックアップされたデータはコンテナに格納される
既定では、Recovery Services コンテナーではGRSが使用される
データ転送でコストはかからない
シャットダウン or オフラインになっているVMのバックアップもサポートしている

[Agentによるバックアップと復元]

エージェント : Microsoft Azure Recovery Services(MARS) エージェント
エージェントをインストールして、フォルダ/ファイル単位にバックアップする
バックアップ先のAzure Backupは別リージョンでも可能
バックアップ取得元サーバーは、Azure VMだけでなくオンプレミスも可能
windowsのみ

[VMのバックアップ手法としてスナップショットも選択肢としてある]

MarketPlaceから"snapshot"を選択
スナップショットはディスク単位の取得になるため、複数ディスクをアタッチしたVMでは整合性に注意

バックアップ手順

1. Recovery Services コンテナーを作成
2. 「概要」の「＋バックアップ」をクリック(ワークロード、何をバックアップするか選択)
3. バックアップポリシーを作成し、バックアップする仮想マシンを選択→「バックアップの有効化」をクリック
4. スケジューラーはスケジュールされた時刻にバックアップをトリガーする (ジョブの一部としてスナップショット作成)
5. 「バックアップアイテム」→ 「Azure Virtual Machine」の順にクリックし、「今すぐバックアップ」を選択でOK
*バックアップのデータの流れ、[VM]→ [snapshot]→ [バックアップデータ]

リカバリ手順

1. 「バックアップアイテム」→ 「Azure Virtual Machine」
2. 「VMの復元」をクリック
3. リカバリ対象の復元ポイントを選択して「OK」をクリック
4. 復元の構成を入力し、「復元」をクリック

(2) Azure Site Recovery (2020/01にサポート終了)→ Azure Migrate

オンプレの物理サーバーやVMのディザスタリカバリとして、災害時はAzure上でサーバを速やかに復旧できる仕組み

(1)ASRを有効にすると、VMのバックアップが自動で開始される。ディスクへの書き込みは、すぐにソースロケーションのキャッシュストレージアカウントに転送される

(2)ASRはキャッシュ内のデータを処理し、レプリカのマネージドデジスクに送信

(3)データが処理された後、復旧ポイントとなるスナップショットが作成

(4) フェールオーバを開始すると、ターゲットロケーションにVMが作成される。フェールオーバーには、任意の復旧ポイントを使用できる

機能
①レプリケーション : 物理サーバやVMのディスクを丸ごとAzureに同期
②フェールオーバー : Azureに同期されたディスクを使ってAzure上にVMを作成する

【Azure Monitor】

Application Insightsで、アプリケーションと関連する問題の検出と診断
仮想マシンとAKSのインフラレベルの問題を関連付け
メトリックの監視と視覚化 (Azureダッシュボード、ワークブック)
ログのクエリと分析(Azure Monitor Logs)
アラートとアクションのセットアップ
メトリックとログは、Azure Monitorで使用する２つの基本的なデータ
ログデータは、Log Analytics workspaceに格納される。アクティビティログは90日間

*ログの保存先は、「Azure Active Directory」→ 「監査ログ」→「データ設定のエクスポート」で選択可能

Azure Subscriptionのlog

Service Health: アプリとリソースが依存するサブスクリプション内のAzureサービスの正常性の情報を提供
Activity Log : サービスの正常性レコードとAzureリソースに対して行われた構成の変更に関するレコード

Azureが出力するログとメトリック

(1)Activity Logs

リソースに対して外部から実行された書き込み操作で、いつ誰が行ったかを記録するもの
Azureの基盤側のログ

(2)Diagnostic Logs(診断ログ)

各リソースが出力するログ

(3)Metrics

各リソースが出力する数値的に計測された値, CPU使用率とか

アラートルール : 監視対象リソース、監視条件、通知方法(アクショングループをattach)

アクショングループ : どの宛先の電子メールに送信するか、どのfunctionを呼び出すかなどの通知方法を定義
- 詳細(e-mail,SMS, 音声,Azure Function, Logic Apps, webhook, Automation Runbook)

【Log Analytics → Azure Monitor Logs】

ログ収集＆分析基盤 as a Service
保存するところは、Log Analyticsワークスペース
ログデータを収集・検索・分析機能を提供するPF
対象コンピュータにagentをインストールするだけ (VMは登録時に自動でインストールされている)
監視サービスではない
ログの長期保存には向いていない

【VM】

VMのサイズ変更→停止の必要あり(ダウンタウンを引き起こす)

移動

VMのVNet間移動は、一度VMのみ削除し、残ったdisk,VHDファイルから新たにVMへアタッチ
同じVNet内のサブネット移動であればNICのIP設定変更によって可能なためハードルは低い

Azure Resource Mover

リージョン間でAzureリソースを移動する機能
リソースの移動でなくコピーなので、移動前のリソースはそのまま残っているため自分で削除する必要あり

データディスク追加

データディスクは1つあたり1TBまで利用でき、それ以外の容量を使いたい時は複数のデータディスクをアタッチする
作成したらOS側でディスクの追加をする
(sshでVMに入り、新しいディスクをマウントする作業をする)

【管理グループ】

サブスクリプションに対する権限管理を、サブスクリプションの所有者よりも上のレイヤでガバナンスを効かせたいケース
1つのディレクトリで複数のサブスクリプションの管理/運用の効率化
階層は６階層まで(ルート管理グループとサブスクリプションは含めず)
MAX10,00個まで管理グループ作成できる
ルート管理グループ= Azure ADのIDが一緒

【Azure AD】

Azure Subscriptionが信頼するAzure ADテナントは１つ
Azure ADテナント(既定)と Azure AD テナント(追加)の一括管理はできない。一つずつ管理

Azure ADテナント削除

組織を削除するグローバル管理者1人を除き、すべてのユーザーが削除されている
Azure ADと連携指定いるアプリケーションがないこと
組織に関連づけられているマイクロソフトのオンラインサービスのサブスクリプションがないこと

Active Directory Domain Services (ADDS)

オンプレミス上のIDと認証やコンピュータの管理、GPO、信頼などの主要な機能を提供する企業用のLDAPサーバー

Azure Active Directory Domain Services (Azure ADDS)

オンプレミス環境のAD DSのドメイン参加、GPO、LDAP、kerberos認証などのADDSにある主要機能をクラウド上にて利用すること

【Azure AD Identity Protection】

Microsoft データセンターに蓄積された膨大なデータをもとに、ユーザーの普段と異なる怪しいサインインや侵害されたアカウントを自動で検出しそのリスクを調査
検出したリスクを機械学習を通して、3段階で評価する(リスクレベル)
すべてのユーザーに対してP2ライセンス必要

3つの既定ポリシー
①ユーザーリスクポリシー

侵害されたアカウントをリアルタイムで修正
怪しい行動をするアカウントを検出し、そのユーザーからのアカウントをブロック

②サインインリスクポリシー

怪しいサインインをリアルタイムで防止
怪しいユーザーに対して多要素認証を要求し、ユーザーが応じられなければそのアカウントをブロック
このポリシーを実行するには、対象となるすべてのユーザーが多要素認証を事前に登録しなくてはならない

③MFA登録ポリシー

多要素認証を登録していない脆弱なユーザーアカウントを検出し、Azure MFAの２要素目の登録をユーザーに強制させる

④カスタム条件付きアクセスポリシー

これらのポリシーを有効にすると、怪しいサインインに対して強制的に多要素認証を要求したり、多要素認証が登録されていない脆弱なアカウントに対して強制的に多要素認証を登録させたり、怪しいユーザーアクションに対してアクセスをブロックさせたり、パスワードを強制変更させたりして、Azure ADのIDを動的に、リアルタイムに保護

条件つきアクセス

Azure ADへの認証に対して、制限対象に該当するユーザーを許可・拒否することができる機能
MFAの設定 [Azure AD]-[条件付きアクセス]-[アクセス制御]-[許可]-[MFA]

【Azure Policy】

評価を実行し、準拠されていないリソースをスキャン
デプロイのプロパティに注目して制限する
組織が利用するためのポリシー
ex) ストレージアカウントSKU, リソース種類、場所、VMのSKU

RBAC→ユーザー操作に焦点

Azure Policyを割り当てられるスコープ

(1) 管理グループ
(2) サブスクリプション
(3) RG

ユースケース

組織が展開するリソースの種類を指定する
組織が展開できる仮想マシンSKUのセットを指定する
必要なタグとその値を適用する

*ポリシー定義が少ない場合でも、イニシアティブ定義をするのがおすすめ
*イニシアティブ定義を定義したら、RGなどに割り当てる

ポリシーを設定したら「コンプライアンス」ブレードを使用して、準拠していないイニシアティブ、準拠していないポリシー、準拠していないリソースを確認する

【Blueprint】

Azure Policyを再利用・再配布可能な形で定義。別サブスクリプションに簡単に適応できる
Blueprintの中にRBAC, イニシアティブがあり、イニシアティブの中にPolicyがあるイメージ

【VMの可用性】

可用性セット(Availability Set)

同一データセンター内の別のサーバーラックに配置された仮想マシンを配置する設定のこと
物理サーバーや電源装置、ネットワークスイッチなどラック内で障害が発生しても別ラックに配置された仮想マシンに切り替えることでシステム停止を防ぐ
複数のVMを同じ可用性セットに作成→予期しないメンテナンスなどに対応できる
料金はかからない
SLA : 99.95%
システムの商用を考えているのなら必須
VMを作る時は、可用性セットを最初に作ってからそのグループ内にVMを作る
事前に作成しておいて、LBに関連づけする
必ず同一のDC内で構成される必要あり
同じ役割を持つサーバ群を可用性セットでグループ化する (ex: webサーバ２台の可用性セット)

①障害ドメイン(Fault Domain)

def:2, Max:3(1から選択可能)
電源とネットワークスイッチが独立したVMのグループ
障害ドメイン「２」は、「同じ可用性セット内の仮想マシンは少なくとも２台の物理ホストに分けることを保証する」
障害ドメインを2つにすると、同じ可用性セットに2つのVMを立てた時に2つの障害ドメインに自動的に振り分ける
同様に更新ドメインを5つにするとこの可用性セットにVMを作成するたびに、その5つのどれかに自動的に振り分けられる

②更新ドメイン(Update Domain)

def:5, Max:20(1から選択可能)
同時に起動されるVMのグループ

安定稼働が必要なVMは、可用性セットに作成
VMを可用性セットに追加できるのはVM作成時のみ
設定変更は、可用性セット内のすべてのVMを停止する必要あり

可用性ゾーン(AZ)

データセンターそのものの障害によるシステム停止を防ぐ(DC障害対策)
同じリージョンの中で３つのDC(1,2,3)に分散させるイメージ
SLA : 99.99%
LBを冗長構成するためStandard Load Balancerの費用がかかることがある

仮想マシンスケールセット(VMSS)

仮想マシンを「必要なときに」「必要なぶんだけ」「自動で」リソースの調達できる
インスタンス数の最小・最大、スケールイン・スケールアウトの条件を決めれる
同一イメージのVMをグループ化して、作成・管理・負荷分散する
LB or AGWの作成も統合され自動で実行される
スケールセットには自動スケーリングが組み込まれている

Upgrade policy & Upgrade mode

manual : 手動
automatic : 自動的にOSとかのupgradeがなる
rolling : セットアップした間隔でバッチでupgrade

オーケストレーション : 仮想マシンをスケールセットで管理する方法を選択

(1)均一

仮想マシンモデルを定義すると、そのモデルに基づいてAzureによって同一のインスタンスが生成
同一インスタンスの大規模なステートレスワークロード用に最適化されている

(2)フレキシブル

任意の構成の仮想マシンを手動で作成してスケールセットに追加
同一または複数の仮想マシンの種類を使用して、大規模に高可用性を実現

近接通信配置グループ(Proximity Placement Group)

低遅延が求められる場合に有効
VM間のネットワークパフォーマンスを最大化することが目的
VM作成時に選択できる
可用性セット、可用性ゾーン、VMSSと併用可能
起動時に物理的に近接する場所に配置される

【Azure ADのデバイス管理】

Azure AD 参加: 組織の所有しているwindows 10デバイスを対象にしている構成
Azure AD 登録: スマートフォンなどの個人所有のデバイスを対象にしている構成
Intune
- マイクロソフトは、モバイルデバイス管理およびモバイルアプリケーション管理のSaaSアプリケーションを提供
- Intuneにデバイスを登録すると、登録されたデバイスに対してIntuneがさまざまなポリシーを提供できる
- P1ライセンスを持っていると、ユーザーが個別にIntuneにデバイスを登録しなくても、Azure ADテナントに参加/登録したデバイスをAzure ADテナントからIntuneに自動登録できる

【Azure AD Connect】

Active Directory ドメインサービス(ADDS)とAzure Active Directory間でユーザー情報を同期し、認証基盤を統合
「Azure AD Connectのダウンロード」をクリックして、ダウンロードしオンプレのAD上でダウンロードしたファイルを実行

【SSPR】

SSPR

Azure AD Freeでは使えない
オンプレミスのADと同期している場合、SSPRを行うにはP1, P2ライセンス
user admin role X, global OK
Mobile app notification, mobile app code, email, mobile phone, office phone, security questions

そのほか (わからなかったことのメモです)

VMをVMSSに追加するとRGはどこでもよく、リージョンだけ同じにする必要あり
デバイスが追加できない時は、[Device Setting blade]のデバイスの設定の最大を確認する
Azure Data Lake Storage G2
- 大量のログなどを容量を気にすることなく、とりあえず生のまま安価に高機能なストレージに突っ込むことができる
- 複数の分析基盤と接続もできるので便利
直接peeringされたVNetにアクセスできるがVNetのPeeringやネットワークのトポロジに変更があった時、VPNクライアントを再度インストールする
Blue-Green Deployment : LBの接続先を直接切り替えるなどして新しい本番環境をリリースする運用方法
webAppとAppServicePlanは同じリージョンにある必要あり
peering statusが "Disconnected"の時は、両方のVNetからPeeringを削除してから再作成する必要あり
VMの名前解決
→同じVNet内のVMは、Azureで提供される名前解決により、相互にホスト名で名前解決できる
→異なるVNetは名前解決できない
→独自にDNSサーバーを設定する、Azure DNSプライベートゾーンを使用
Azure Performance Diagnostics Extension → windowsやLinuxのVMに影響を与える可能性のあるパフォーマンス問題のトラブルシューティングを支援

Bastion

VMでPublic IPから直接、シームレスにRDPとSSHで接続
VMはパブリックIP, agentなどはいらない
TLSを介してAzure Portalから直接VMへSSHする

スナップショット : VMのすべてのディスクの特定の時点のバックアップ

UPN(User Principal Name)

インターネット上のサービスで使われるログイン名
UPNはActive DirectoryではユーザーのIDを指す
Active Directoryにおけるユーザー名の表記法の１つで、登録ユーザーのアカウント名のあとに所属ドメイン名を「@」を挟んで連結したもの

idfixツール

Active Directoryの問題解決
オンプレミスでIDオブジェクトとその属性の検出と修復を実行するために使用

NSGはRegion間を移動できない。同じリージョンでしか使えない
SMBプロトコル : port 445
Azureがドメイン名を確認、どのタイプのDNSレコードを作成するか？→ TXT, MX
VMを単にVNET間で移動はできない
→ diskを残したまま、VM1を削除し、別のVNetで新たにVMを作成してディスクをアタッチする
リソースはサブスクリプション間で移動できる
RGを削除する前にやること
(1)ロックを削除
(2)Recovery Service Vault からのVMのBU停止
Recovery Services Vaultを削除前に最初にやること→ 各バックアップ項目のバックアップを停止

マネージドID

Azure ADの認証をサポートするサービスに対してAzureリソース自身で認証を行うことができるAzure ADで管理されるID
マネージドIDを利用すると、Azureリソース自身が認証されるため、コード等から認証情報を排除できる

Azure Backup report

(1) Log Analytics ワークスペース作成 (デフォが30日間保存)
(2) コンテナの診断結果を構成 (send to Log Analytics　を有効化)
(3) Recovery Services valutの「overview」→ 「Backup Reports」で開く
*storage accountとLog Analytics ワークスペースは同じリージョンでないとだめ

puppet

サーバー構成管理ツールの１つ
各サーバーにエージェントをインストール
現状だと各サーバーにエージェント入れるのは比較的容易、SI案件だとハードル高い(Ansibleとはエージェント不要)

カスタムスクリプト拡張

自動的にAzureストレージからスクリプトとファイルをダウンロードし、仮想マシンでPowerShellスクリプトを実行できる

カスタムオペレーター

VMの起動、停止、再起動の許可

Microsoft.Compute/VirtualMachines/start/action
Microsoft.Compute/VirtualMachines/deallocate/action
Microsoft.Compute/VirtualMachines/restart/action
Microsoft.Compute/VirtualMachines/*/read

「Azrue AD」 → 「ユーザー」→「ユーザー設定」→「外部コラボレーション設定」
ゲストのアクセス許可を制限する
管理者とゲスト招待元ロールのユーザーは招待ができる
メンバーは招待できる
ゲストは招待できる
ゲストの電子メールワンタイムパスワードを有効にする

コラボレーションの制限

招待を任意のドメインに送信することを許可
指定したドメインの招待を拒否
指定したドメインに対してのみ招待を許可

kubectl : 主に水平方向にスケールするために使用

プロビジョニング : 必要に応じてネットワークやコンピュータの設備などのリソースを提供できるよう予測し準備しておくこと

プライマリドメイン

プライマリドメイン名 : "XXX.onmicrosoft,com" (組織を作成すると)
プラマリドメインは、新しいユーザーを作成した時にそのユーザーの既定のドメインになる
プライマリドメインを変更するには、カスタムドメインの追加をする
サブドメインを追加する場合は、最初にルートドメインを追加して確認
Azure ADで指定したドメインを使えるようにするにはDNSレコードを作成し、ドメインを所有しているという確認を完了させる

プライベートDNS設定

インターネットではなく、独自のネットワーク内で名前解決を行うためのDNS
VNet内で名前解決する

cloud-init

Linux VMを初期起動時にカスタマイズするために広く使用されている手法
パッケージをインストールしてファイルを書き込んだり、ユーザーとセキュリティを構成したりできる
VM or VMSSを構成するために使用

Azure Storage Explorer : あらゆる場所からクラウドストレージを管理するツール

Log Analytics ワークスペースは、location & サブスクリプションは Recovery Service Vaultが存在するところから独立
UsageLocation : 全ユーザーに対して更新できる
traffic analytics → readerでもOK
Azure DNS → CLIを使用したtゾーンファイルのimport/export をサポート

wookbook

[Azure Active Directory]→ [wookbook]
Azure ADサインログの情報を収集して視覚化

Effective Route :

ネットワークのルーティングを確認するための方法
ルートテーブルから見れる
ストレージアカウントは、レプリケーションタイプの変更できる

Azure Data Box : ハードディスクに大量のデータを保存し、オンプレミスからクラウドへ物理配送

Azure Advisor : 取得されたメトリック、ログデータをもとにベストプラクティスに従うような推奨事項を自動生成

AssignableScopes : 割り当てにロールを使用できるスコープを指定。定義できる管理グループは1つのみ

ロック

Delete : add/modifyはできる
Read : 何もできない(readはできる)

グループ

種類	説明
①Security Group	一般的、一度に全てのメンバーに一連の権限を与える。Azure ADの管理者が必要。Azureのリソースへのアクセス権など管理
②Microsoft 365 Group	メンバーが共有の受信トレイ、カレンダー、ファイルにアクセスすることでコラボレーション機会を提供。ユーザーと管理者の両方で利用できる。Office365などのSaaSアプリケーションのアクセスを管理する

Log Analytics ワークスペースは、Recovery Service Vaultからは、location & サブスクリプションは独立
Azure Filesにアクセス (REST, SMB ) : SAS Tokenは対応していない
Performance Diagnostics エージェント : VMの高度な監視機能、windows/Linuxで利用可能
VMのCPUパフォーマンス問題 → VMのsize変更 (スケールアップ)
NVA(Network Virtual Appliance) : ネットワークの機能やサービスが含まれたVM (Marketplaceから)

参考文献

参考書

速習Azure Administrator
ひと目でわかる、Azure Active Directory

Azure Administrator Associate (AZ-104) 対策まとめ