DevOpsとは 開発～公開までの作業（ビルド、テスト、デプロイ）を迅速に行うことができるAzureのサービスです。 手動でのリリースの場合、 作業時間がかかる テスト漏れ リリースミス というデメリットがありますが、DevOpsを使用することで迅速に、頻繁に、確実に行える仕組みを構築することができます。 Azure DevOpsの特色 リリース作業に必要なサービスが揃っている ビルド、テスト、資産管理、チケット管理まで一括して行える。 GUIでの操作性に優れている GUIリリース作業フローを作成できる。 AWSのサービスと比べ構築しやすい。 利用コストが安い 5人までのプロジェクトであれば無料。 他サービスと連携できる GitHubなどの他のサービスと連携できる Azure DevOpsの主な機能 Overview プロジェクトの概要を表示します。 Aure Boards JIRAやTrelloのようなタスク管理が行え、バグトラッキングとして修正資産と紐づけることができます。 Azure Repos Gitホスティング ソース管理が行えます。 Azure Pipelines 継続的インテグレーション（CI）/継続的デリバリー（CD）処理をGUIを利用して、YAML形式で設定が可能。 連携次第で、GitHubやその他のリポジトリサービスも利用可能。 ビルドツール Ant .Net Gradle Mavenも利用可能です。 Azure Test Plans 手動の探索的テストの管理ができるサービスです。 https://news.mynavi.jp/article/zeroazure-30/ Azure Artifacts パッケージ リポジトリ 成果物を格納することができるサービスです。 例えば、リリース作業時のテスト結果のエビデンスを格納することもできる。 a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A1CfX"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/789749/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/J6100281917861.jpg?1696410860000"}});

Azure Functionsにおけるコールドスタート コールドスタートとは 関数アプリケーションを起動する際に、起動中の関数アプリケーションを一度停止して、 ランタイムなどを初期化してから起動を行なうこと。 コールドスタートの場合の、Functionsが実行されるまでの大まかなフローは下記のようになっている、 容量のあるサーバーに関数アプリケーションを割り当てる Functionsランタイムをそのサーバーで起動する 関数アプリケーションのコードを実行する コードの実行に対するオーバーヘッドに当たる1、2の実行には時間がかかる。 そのため、毎回ゼロから開始するのではなく、Functionsランタイムが稼働するように事前構成されたアイドルワーカーが常に存在している。 これを活用することで、コールドスタート時間を大幅に改善できる。 コールドスタートとウォームスタート プールから事前構成されたサーバーを関数アプリに割り当る。 2.　サーバを関数アプリ用に専門化 ※ 割り当てられたサーバにAzure Filesコンテンツをマウント ※ 関数アプリ固有のアプリ設定を適用 関数ランタイムをリセット ※ ランタイムは関数アプリ内の関数のfunction.jsonファイルから拡張機能を読み込む ※ ソースコードを言語プロバイダーによってメモリに読み込まれる 関数アプリのコードを実行 コールドスタートの場合は、1～4の準備作業が行われてからコードが実行される。 一度コードを実行すると暫くの間はリソースが保持されるため、1～4の準備作業でコードをすぐに実行することができる。(ウォームスタート) 非アクティブ状態が約20分間続いた後、リソースの割り当てが解除される。 その後、次の呼び出しはコールドスタートとなる。 長期間のコールドスタートを回避する ※ 2.0ランタイムで実行されている言語はプレビュー版であり、完全に最適化されていないことにも注意 軽量なコードを書く コードが起動する前に発生する必要がある作業の量を最小限に抑え、大量のCPUを消費するコードを避ける。 ファイルサイズ、ファイル数を減らす 関数アプリ内に依存関係ファイルなどのファイルが大量にある場合、 Azure FilesからのI / O操作の時間が増加し、メモリにロードするために必要な時間が長くなるため、コールドスタートが長くなる。 また、ファイル数が増えるとAzure Filesが処理する必要のあるファイルの数も増えるため、速度が低下する。 できるだけ多くの処理を非同期にする 重い同期呼び出しがコードの完了をブロックしている場合、関数はうまく機能しない。 コールドスタートを完​​全に回避する App Serviceプランで関数を実行すると、VMで発生することを制御できるため、これらの問題が緩和される。 参考 https://azure.microsoft.com/ja-jp/blog/understanding-serverless-cold-start/ a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A1CfX"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/789749/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/J6100281917861.jpg?1696410860000"}}); a8adscript('body').

Azure Administrator対策「Azure AppService」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 AppService スロットスワップ スロット FQDN形式の命名で生成されるAppServiceの実行環境。 スロットスワップ スロット間でスロット内のアプリケーションや、コンテンツを入れ替えること。 スワップ後もスロットのドメイン名は同じまま。 検証スロットで検証後、本番スロットと検証スロットをスワップすると、 アプリケーションのURLはそのまま、中身を変更することが可能 スワップのメリット アプリをデプロイする際のダウンタイムがなくなる スロットにスワップ前の運用アプリが残るため、切り戻しが用意 ※ 利用できるスロット数は、App Service プラン レベルごとに異なる ※ スロットは追加料金なしで利用可能 参考 AZ-104模擬試験 a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A1CfX"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/789749/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/J6100281917861.jpg?1696410860000"}}); a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A2FzR"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/721208/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/F0100169654961.jpg?1663322311000"}});

Azure Administrator対策「IDの管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 Azure Active Directory Azureクラウド上で組織内のユーザアカウントの管理、認証を行うサービス。 Azure AD デバイス ID Azureクラウドにアクセスできるデバイスを設定することが可能。 [Azure Active Directory] > [デバイス] から設定が行える。 https://docs.microsoft.com/ja-jp/azure/active-directory/devices/ 「Azure AD 参加 : Azure AD Join」 以下のような機能を提供するAzure上にアカウント管理サービス。 クラウドと、オンプレミスのデバイス間の双方向のシングルサインオン MDM(モバイルデバイス管理)機能 ※ この設定はWindows10にのみ対応 https://jpazureid.github.io/blog/azure-active-directory/azure-ad-join-vs-azure-ad-device-registration/ デバイス設定の構成 以下の設定項目をもつ。 [ユーザーはデバイスをAzure ADに参加させることができます] デバイスを「Azure AD 参加」に登録させることができるユーザーを選択する。　※ 既定値は [すべて(All)]で全ユーザがデバイスの登録が作業が可能 [Azure AD 参加済みデバイスの追加のローカル管理者] デバイスに対するローカル管理者権限が付与されるユーザーを選択する。 ここに追加されたユーザーは、Azure ADの"デバイス管理者"ロールが追加される。 [ユーザーはデバイスをAzure ADに登録できます] ユーザーがデバイスをAzure ADに登録できるかどうかを設定する。 ※ Allか、Noneの2択 [デバイスを参加させるには Multi-factor Auth が必要] デバイスが「Azure AD に参加」するときに、 ユーザーが追加の認証要素の提供を求められるようにする設定。 ※ デフォルトは「No」

Azure Administrator対策「サブスクリプションおよびリソースを管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 サブスクリプション Azure でリソースをプロビジョニングするために使用される論理コンテナーまた、Azureにおける課金の単位。 仮想マシン(VM)やデータベースなどのすべてのリソースの詳細が保持される。 月単位で課金され、請求期間の終了後10日以内に自動的に請求される。 サブスクリプションは以下のような単位で設定することができる。 環境による分割 : 商用、開発、テストなどの個別の環境を設定する必要がある場合 組織構造による分割 : 部門、チーム、またはプロジェクト別に課金を整理する必要がある場合 サブスクリプションの制限 サブスクリプションにはいくつかの制限がある。 ※ 例 サブスクリプションごとの Express Route 回線の最大数は 10。 制限されている値を超えて利用をする場合、Azureポータルからサポートチケットを開いてクォータ(割当て量)の増加を依頼する必要がある。 https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/management/azure-subscription-service-limits タグ タグはリソース、リソースグループ、サブスクリプションを割り当てることで、 それぞれを分類して整理する機能。 タグはタグ名とタグの値からなるキーバリュー形式で設定を行う。 ※ 例 : タグ名「Environment」、タグの値「Production」 主な制約事項 タグ名は大文字と小文字を区別されない ※ リソースプロバイダーは、タグ名に指定した大文字小文字を保持する場合がある タグの値は大文字と小文字が区別される リソースグループおよびサブスクリプションに適用されたタグはリソースに継承されない ※「Azureポリシー」でタグの設定が必要 タグ名は512文字に、タグ値は256文字に制限 ※ ストレージアカウントの場合、タグ名は128文字に制限され、タグ値は256文字に制限 タグ名は、以下の記号を含めることができない ：<、>、%、& https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/tag-resources タグごとのコストを表示 Azure portalから[コストの管理と請求] > [コスト管理] > [コスト分析]を指定。

Azure Administrator対策「ストレージの作成と管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 仮想ハードディスク (VHD) の使用例 オペレーティングシステムストレージ。 オペレーティング システムが格納される。 最大容量は 2,048 ギガバイト (GB) 。 一時ストレージ 各 VM には、ページ ファイルおよびスワップ ファイルに使用される一時 VHD。 Windows VM では既定で D: のラベルが付けられる。 データストレージ 再起動後も保持する必要があるファイル、データベース、およびその他のデータを格納。 最大容量は4,095 GB。 Azure では、Azureストレージアカウントに VHD がページ BLOB として格納される。 次の表は、各種ストレージ アカウントと、それぞれのストレージ アカウントで使用できるオブジェクトを示す。 ストレージアカウントのタイプ ストレージアカウントには以下の種類がある。 種類 該当サービス パフォーマンスレベル アクセス層 レプリケーション 汎用 v2 BLOB ファイル キュー テーブル ディスク Data Lake Gen2 Standard Premium ホット クール アーカイブ LRS GRS RA-GRS ZRS GZRS (プレビュー) RA-GZRS (プレビュー) 汎用 v1 BLOB ファイル キュー テーブル ディスク Standard Premium 該当なし LRS GRS RA-GRS BlockBlobStorage BLOB (ブロック BLOB と追加 BLOB のみ) Premium 該当なし LRS ZRS FileStorage ファイル Premium 該当なし LRS ZRS BlobStorage BLOB (ブロック BLOB と追加 BLOB のみ) Standard ホット クール アーカイブ LRS GRS RA-GRS 専用タイプ（ Block blob, FileStorage に比べ、汎用タイプの方がレプリケーションのオプションが豊富

Azure Administrator対策「仮想ネットワークの設定と管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 ウェルノウンポート 以下のポートに関連する問題が試験で問われるケースがあるため、各ポートの用途を理解しておく必要がある。 プロトコル ポート 備考 HTTP 80 Webアプリケーションに接続する場合などに利用 HTTPS 443 Webアプリケーションに接続する場合などに利用 SSH 22 仮想マシンへのSSH接続時に使用 DNS 53 DNSサーバへの接続に利用 SMB 445 ファイル共有をマウントする場合に使用 RDP 3389 仮想マシンへのリモートデスクトップ接続時に使用 SQL over TCP 1443 RDBへの接続時に利用 仮想ネットワークの制限事項 仮想ネットワークと異なるリージョンおよびサブスクリプションに属するリソースに、仮想ネットワークを割り当てることはできない。 例えば、仮想ネットワークと異なるリージョンに属するVMやNSGを、仮想ネットワーク上に割り当てることはできない。 ただし、異なるサブスクリプションおよびリージョンに存在する仮想ネットワークに接続することはできる。 https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-vnet-plan-design-arm#regions https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-networks-faq#can-a-vnet-span-regions 仮想ネットワークピアリング(VNet ピアリング) Azure上の異なる仮想ネットワーク間を接続させる機能。 ピアリングされた仮想ネットワークは、見かけ上1つのネットワークとして機能する。 グローバルVNetピアリング 異なるリージョンに属する仮想ネットワークの間の仮想ネットワークピアリングのこと。 主な利用条件・制限事項など ピアリング接続の可否に関する制限事項 異なるリージョンの間の仮想ネットワークはピアリング可能

Azure Administrator対策「仮想マシン(VM)の展開と管理」 はじめに AZ-103「Azure Administrator」対策として、Microsoft Learnなどを要約したものを記載。 VM作成の考慮事項 ネットワークの作成 VMに割り当てる仮想ネットワーク(VNet)を指定する。 同じネットワークに属するVMと他のAzureサービスの間では、相互アクセスが可能。 仮想ネットワークは一度設定した後から変更することは困難なので、VMを導入する前にトポロジーを考慮する必要がある。 VNet を他の VNet に接続する場合は、重複しないアドレス範囲を選択する必要がある。 サブネットの作成 作成した仮想ネットワークアドレス空間から、管理しやすいようにサブネットを作成する。 ※　例 ・10.1.0.0/16 ⇒ VMサブネット ・10.2.0.0/16 ⇒ バックエンドサービス用サブネット ・10.3.0.0/16 ⇒ SQL Server VM用サブネット ※ 各サブネットの先頭から 4 個のアドレスと最後のアドレスは、Azure側で予約されているので、利用できない セキュリティの設定 既定では、サブネット間にセキュリティ境界がないため、各サブネットのサービスは互いに通信可能。 ネットワーク セキュリティ グループ (NSG) を設定して、 サブネット間にネットワークフィルタを設定可能。 VMの名称 Windows VM には最大 15 文字、Linux VM には最大 64 文字の名前を指定することができる。 わかりやすく一貫性のある名前を選択する必要がある。 良い慣例としては、以下のような内容を含ませる。 要素 例 備考 環境 dev、prod リソースの環境名 場所 uw (米国西部)、ue (米国東部) リソースが稼働するリージョンなど 番号 01、02 ナンバリング 製品 Or サービス名 service リソースがサポートする製品、アプリケーションなど ロール sql、web、messaging リソースのロール VMを起動させる場所 場所の選択に関しては、それ以外に次の 2 点を考慮する。

AZ-900対策「Azure コンピューティングサービス」 はじめに AZ-900「Azure Fundamentals」対策として、Microsoft Learnなどを要約したものを記載。 コンピューティング Azure Virtual Machines Azure Windows または Linux 仮想マシン (VM)を提供する。 Azure Virtual Machine Scale Sets 設定したタイミングで仮想マシンをスケールアウトできるサービス。 CPU使用率が設定した値以上になった際に、仮想マシンを増加させるといった設定が可能。 Azure Kubernetes Service 複数のVM間の、コンテナの統合管理をするサービス。 コンテナ間のネットワーク管理や、負荷分散が可能。 Azure Service Fabric 分散システムプラットフォーム。 Fabricは編み物の意味で、ITにおいては、 リソースを小さな単位で多数配置し、必要に応じてリソースを切り出しシステムを構成する技術のことを示す。 Azure Batch AzureBatchでは任意のプログラムを並列実行できるサービス。 Azure Container Instances サーバーまたは VMを使用せずに、 Azureでコンテナーを起動することができるサービス。 Azure Functions プログラムを実行するサーバを用意せずに、任意のプログラムを実行することができるサービス 参考 AZ-900模擬試験 a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A1CfX"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/789749/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/J6100281917861.jpg?1696410860000"}}); a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A2FzR"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/721208/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/F0100169654961.jpg?1663322311000"}});

AZ-900対策「Azure アーキテクチャとサービスの保証」 本記事では、AZ-900「Azure Fundamentals」対策として、Microsoft Learnの内容を要約したものを記載する。 Azure アーキテクチャとサービスの保証 リージョン 少なくとも1 つのデータ センターが配置されている拠点のこと。 各リージョンは、地球上の地理的境界や、コンプライアンスにより分割される。 日本には西日本、東日本の2つのリージョンがある。 特殊なリージョン 米国政府用リージョン US DoD 中部、US Gov バージニア、US Gov アイオワなどにあるリージョン。 米国の政府機関専用にネットワークを物理的および論理的に分離している。 これらのデータセンターは選別された米国国民によって運用されている。 得意なパートナーシップリージョン “中国東部”、“中国北部” などのリージョン。 Microsoft はこれらのデータセンターの直接管理はしない。 これらのリージョンは、Microsoftと21Vianet間の特異なパートナーシップを通じて利用できる。 可用性ゾーン(アベイラビリティゾーン) Azure リージョン内の一つまたは、複数のデータセンターのこと。 それぞれの可用性ゾーンは、以下のような分離境界と呼ばれる物理的な境界で分けられる。 電源 冷却手段 ネットワーク 停電などで1 つの可用性ゾーンがダウンしても、他の可用性ゾーンは停電の影響を受けない。 可用性ゾーンは、高速なプライベート光ファイバー ネットワークを介して接続される。 サポート範囲 可用性ゾーンがサポートされているのは一部のリージョンのみ。 次のリージョンには、回復性を確保するために最低 3 つのゾーンが別個に存在している。 ※ アジア地域は東南アジアリージョンのみサポート 米国中部 米国東部 2 米国西部 2 西ヨーロッパ フランス中部 北ヨーロッパ 東南アジア リージョン ペア 同じ地域内 (米国、ヨーロッパ、アジアなど) の少なくとも 300 マイル離れている別のリージョン間で、 リソースのレプリケーションを行うこと。 ※ Azure のリージョンのペアの例