クラウド二刀流エンジニア*1という言葉もあるくらい、複数のクラウド知識を持ったエンジニアの存在が求められています。
マルチクラウドでワークロードを構築する場合はもちろん、AWS単独での実装でも「他のクラウドと比べて何が違うのか」を判断・説明する際にマルチクラウドの知識が必要になります。
これまでAWSを中心に触れてきた私がAzure Fundamentalsを取得した際の勉強法と、AWSとの比較をしながら各サービスの概要をまとめていきます。
準備期間と結果
準備期間は2022年9月17日～9月24日とちょうど1週間でした。
結果は940点で合格することが出来ました！
既存のAWS知識をAzureに広げることができたので、勉強量はあまり必要ありませんでした。
合格までの勉強法
オフィシャルにはMicrosoft Virtual Training Daysの「Azureの基礎」という2日間の研修や、Microsoft LearnのAZ-900ラーニングパスを受講するのが推奨です。 特に前者は研修後にAzure Fundamentalsの無料受験チケットがもらえるので受講すべきだと思いますが、今回はUdemyを中心使ってみました。
１．（Udemy）Microsoft Azure Fundamentals in a Weekend
Udemyのこちらの講義です。 1つが約5分くらいの動画でComputeやStorageなどの各サービスを紹介したり、ポータル画面で操作して実演してくれます。 インドの方が英語で講義しており日本語字幕はないので、言語で拒否感がある人もいるかもしれません。 内容自体は簡易にまとめられていて、分かり易かったです。
２．（Udemy）Microsoft Azure Funfamentals模擬問題集
Udemyのこちらの問題集です。 実試験でもこの問題集と類似問題が数問出てきたので、繰り返し解けばこの問題集だけでも合格は出来ちゃうと思います。 ですが、合格が目的ではなくAzureに対する正しい理解が目的なので、できれば1つ目の講義やポータル画面で実際に操作して理解を深められると良いと思います。
今回学んだこと
やはりAWSの知識をベースにすると理解がしやすかったので、ここからはAWSのアーキテクチャやサービスと比較しながらAzure Fundamentalsの範囲を整理します。
Azureのアーキテクチャ
まず、Azureの物理インフラストラクチャについてです。
上から下に行くにつれて粒度が小さくなっていきます。
特徴的な用語はジオ（Geography）とリージョンペアです。
ジオは複数リージョンを地域でグルーピングしたものです。
ほとんどがJapan、United Statesのように国と同義ですが、Europe（アイルランドリージョンとオランダリージョン）のように複数国が1つのジオになっているところもあります。
リージョンペアはリージョン障害時にフェールオーバーするリージョンの組み合わせです。
東日本リージョンと西日本リージョンはペアになっています。
AWSでも暗黙的に「東京リージョンと大阪リージョンはペアだろう」と認識していると思うので、日本においてはあまりAzure固有の概念という感じはしないですね。
Azureグローバルインフラストラクチャというかっこいいページが用意されているので、遊び半分で触ってみるとイメージアップできるかもしれません。
次に、Azureの管理インフラストラクチャについてです。
ここがFundamentalsのスコープで最もAWSと概念が異なる部分だと思います。
下位の階層から辿っていきます。 リソースはAWS、Azureともに仮想サーバやDBなどを指すので割愛します。
リソースグループは名前の通りリソースをグループ化したものです。 Azureにおいてはリソースグループとリソースは1：Nの関係で、必ずリソースはいずれかのリソースグループに属します。 リソースグループを削除すると配下のリソースをまとめて削除できたり、リソースグループ単位でアクセス制御できたりします。 AWSにもリソースグループ（Resource Groups）がありますがタグ情報などで緩くグルーピングする機能であり、Azureと違って必ずしもリソースはリソースグループに属する必要はありません。
サブスクリプションは請求単位を管理するグルーピングです。 単一Azureアカウントでも、サブスクリプション単位で複数の請求書を発行できます。 AWSは原則AWSアカウント単位での請求となるので、Azureでは柔軟な請求運用を実現できますね。
最上位の管理グループはサブスクリプションの親になる概念で、この粒度でセキュリティポリシーやアクセス管理を適用できます。管理グループはネストすることができ、複雑な構成を組めます（下図参照）。 AWS Organizatonsの組織単位（OU）に近い概念だと思いますが、これを単一Azureアカウント内で実装できるのがすごいですね。 AWSは一定規模を超えるとマルチアカウント運用が前提ですが、Azureは単一アカウントで大きな規模のワークロードを管理できそうです。
（出典）Azureの管理インフラストラクチャについて説明する
Computing
AzureのComputingサービスは、ほぼ対応するサービスがAWSにもあります。
AWSエンジニアにとっては下記対応表を見れば各サービスの概要がイメージできると思いますが、Virtual Machine可用性セットについて補足します。
可用性セット（Availability Set）は、下図にあるように同一データセンタ内で異なるラック・ストレージ・スイッチに仮想マシンを分散配置する機能です。 ラック等の障害から保護するために利用します。 Azureは当初AZ（Availability Zone）という概念がなく、2017年9月に提供開始された後発の機能だそうです。 それまではこの可用性セットで高可用性を担保していたようです。
（出典）Azure Resiliency Infographic
電源やスイッチを共有するラック単位のグルーピングである「障害ドメイン」という概念があり、1個の可用性セットにつき1～3個で構成されます。
Virtual Machine（以下VM）が複数の障害ドメインに分散して配置されることで、とある障害ドメインでハード障害が起きても可用性が担保されます。
Azureのメンテナンスタイミングが同一となるサーバ単位のグルーピングである「更新ドメイン」という概念もあり、こちらは1個の可用性セットにつき1～20個で構成されます。
こちらも複数の更新ドメインに分散して配置することで、Azureのメンテナンスが実行されても可用性を担保できます。
ちなみに、AWSにも2017年*2からスプレッドプレイスメントグループというEC2インスタンスの別のHWに配置制御できる機能がありますが、2008年*3からマルチAZが利用可能であったため、あまり積極的にプレイスメントグループを使って可用性を高めることはしていない印象です。
Networking
ネットワークに関するサービス比較は下記表の通りです。
これもおおむねAWSに対応するサービスがありますが、サブネットやNSGによる通信制御にやや特徴があるので補足します。
AWSではサブネットはAZを跨げません。
一方、AzureではAZを跨いだサブネットが作れます。サブネットの数を減らすことが出来るので構成がシンプルになりますね。
またAWSではサブネット全体に対する通信制御はNACL、NIC（AWSだとENI）に対する通信制御はセキュリティグループと分かれていますが、Azureはどちらもネットワークセキュリティグループ（NSG）で管理します。
NSGはステートフルなので戻り通信のポートを明示的に開ける必要が無く、許可ルール/拒否ルールともに定義可能です。
Storage
ストレージサービスにも対応するAWSサービスがあるのですが、Azureの場合はBlock、File、Object、Queue、Tableの5種をAzure Storageというプラットフォームで統括しています。
さらにBlockストレージであるAzure Disk Storage以外は、ストレージアカウントを通じてアクセスする点がAWSと異なります。
ストレージアカウントごとにリージョン・リソースグループの他、「ストレージアカウントの種類」「冗長性」などを選びます。
ストレージアカウントの種類：ストレージの性能を選択します。Standardは汎用型、Premiumは低遅延なストレージです。
冗長性：ストレージ内のデータをどの程度冗長に保存するかを選択します。
ローカル冗長ストレージ（LRS）は、同一データセンタに3回コピーして保存。
ゾーン冗長ストレージ（ZRS）は、3つのAZにコピーして保存。
ジオ冗長ストレージ（GRS）は、リージョンペアのセカンダリリージョンにもLRSで保存。
ジオゾーン冗長ストレージ（GZRS）は、セカンダリリージョンにもZRSで保存。
Database
AWSとほぼ同等機能となるので特記することはありません。
強いて言えばAzureにはマネージドなOracleデータベースが無いのと、Cosmos DBがDynamoDB、Neptune、DocumentDBなど複数DBを兼ねていることでしょうか。
（補足）2022年7月に「Oracle Database Service for Azure」が発表されました*4。これはOCI（Oracle Cloud Infrastructure）上に構築したOracle databaseに対して低遅延なプライベート通信を通じて、あたかもAzure上に構築したDBのようにアクセスできるというサービスです。選択肢は増えましたが、実際にAzure上でマネージドなOracleデータベースが実装されるのはまだ先のようです。
Security and Identity
認証・認可の中心となるサービスはAzure Active Directory（Azure AD）です。
AWSにおけるIAMのようにロールベースでクラウド上の権限管理を担います。
オンプレミスでADを触れたことがある、ADで認証するPC・システムを使ったことがある人は多いのではないでしょうか。 ただし同じ「AD」でもAzure ADとADはアーキテクチャが異なります。
Azure ADは、フラット構造でユーザ管理しており、OAuth・OIDC・SAMLなどのプロトコルベースです。
ADは、OUという階層構造でユーザ管理しており、Kerberos・LDAP・NTLMなどのプロトコルベースです。
では従来のADのようにLDAPで認証するアプリを実装するときはどうすればよいでしょうか。 AWSでは「AWS Directory Service」、Azureでは「Azure AD Domain Service」です。 ということで、無印のAzure ADとAzure AD Domain Serviceは別サービスですので混同しないようにしましょう。
DevOps
あまり特記すべきサービスは無いですが、かんばんやバックログ管理のサービスであるAzure Boardsがあるのが面白いですね。
AWSだと該当するサービスがないのでBacklogのような外部サービスを使うことになると思います。
その他
これまでのコアサービスと比べて、その他のサービスはAWSとAzureで対応させるのが難しいですが、概ね下記表の通りになると思います。
まとめ
Azureのサービスのほとんどが何らかのAWSサービスと対応付けられるので、一度AWSサービス名に翻訳すると理解しやすかったです。 とはいえ、FundamentalsレベルではAzureならではの特徴を抑えきれないので、まだまだクラウド二刀流エンジニアには遠いなと感じます。 AWSだけでなく、引き続きAzureの学習も深めていこうと思います。
