Trace Id is missing

政府・公共機関向け Microsoft Azure > 6. Microsoft Azure の紹介

Microsoft Azure の紹介

サービスの全体感やリージョンや可用性ゾーンに関する概念、コンプライアンス、SLA の考え方等について
画像:屋外の倉庫のイメージ

イントロダクション

Microsoft Azure は、Microsoft が提供する IaaS および PaaS のサービス群を提供するパブリック クラウド サービスです。

2010 年 2 月に「Windows Azure」の名称のもと正式リリースされ、その後 2014 年 3 月には「Microsoft Azure」としてブランド名が変更されました。このブランド名の変更は、Windows プラットフォームのみならず、オープンソースソフトウェアのエコシステムにもコミット、サポートしていくことを示唆しています。そのため現在の Microsoft Azure では、OS、DB、アプリケーションプラットフォームなどの各分野でオープンソースソフトウェアを含めた多彩なテクノロジーをサポートしています。

また、サービス開始当初は PaaS 領域を中心としたサービスの展開から進めており、PaaS 由来のクラウド サービスという特徴もあります。現在では、PaaS および IaaS サービス合わせて数百以上のサービスを提供しています。

Microsoft Azure が提供するサービス概要

Microsoft Azure が提供するサービスについて俯瞰すると、以下のような領域でのサービスが提供されています。 より詳細なサービス一覧につきましては、「Azure サービス一覧」をご参照ください。

画像:Paas と IaaS の図

IaaS:

IaaS としてご利用いただける多様な「仮想マシン」「ディスク」「ストレージ」およびネットワークサービスが提供されています。仮想マシンにおいては、多様なワークロードや利用形態に対応するため、多くのインスタンス・サイズのバリエーションを備えており、それぞれが用途別にシリーズとしてタイプ分けされて提供されています。例えば、高いメモリ対 CPU 比を提供するシリーズや GPU を備えたシリーズ、HPC (*1) 用途のシリーズなどがあります。

ネットワークの観点では、仮想ネットワーク「VNet」に加え、IPsec VPN 接続をサポートする「VPN Gateway」、オンプレミス環境との閉域接続をサポートする「ExpressRoute」、L4 負荷分散サービス「Azure Load Balancer」、L7 負荷分散やWAF (*2) 機能を提供する「Azure Front Door」 や 「Application Gateway」等、多彩なネットワークサービスが提供されています。

IaaS 領域も継続的なサービス拡充が進められており、最近では DaaS (*3) 環境を提供する「Azure Virtual Desktop」や、オンプレミスで運用されている VMware 環境をクラウド上で実現する「Azure VMware Solution」、Azure のサービスと機能をオンプレミスやエッジ環境に拡張する「Azure Stack」等の広範なソリューションを展開しています。


*1 High Performance Computing
*2 Web Application Firewall
*3 Desktop as a Service

PaaS:

Microsoft Azure では、Web、データベース、分析、AI、IoT など多岐にわたる分野の PaaS を展開し、現在も継続的に機能強化やラインアップの拡充が行われています。

代表的なサービスとしては、Web システム向けの「App Service」があります。フルマネージドな Web アプリケーションの実行環境で C#、Java、PHP、Python、Node.js をはじめとした多種多様な言語をサポートしています。小規模な Web サイトからグローバルにスケーリングされた Web アプリケーションまで、多様なアプリケーションニーズに対応するプランを提供しています。また、Web アプリケーションを構築する上で重要なトラフィック負荷分散や WAF の機能は、上述の Azure Front Door や  Application Gateway と組み合わせることで構成が可能です。

そのほか、WEB API やシステム ワークフロー処理で頻繁に利用されているサーバレスサービスコンピューティングサービスである「Azure Functions」、システム ワークフローで利用される「Azure Logic Apps」、コンテナー運用をする際に利用いただけるサービスとしては「Azure Kubernetes Service (AKS)」や「Azure Service Fabric」、また、AKS をベースに KEDA (Kubernetes Event-Driven Autoscaling) と DAPR (Distributed Application Runtime) を組み合わせて、マイクロサービスの迅速な構築に特化した「Azure Container Apps」、HPC スケジューラーの PaaS である「Azure Batch」など、多様なコンテナ向け PaaS が用意されています。

フルマネージドなデータベース サービスは、リレーショナル データベースと非リレーショナル データベースのサービスに分類ができます。リレーショナル データベースは特に種類豊富に取り揃えており、「Azure SQL Database」に加えて、「PostgreSQL」や「MySQL」などの OSS データベースも PaaS として提供しています。非リレーショナル データベースとしては「Azure Cosmos DB」などを提供しています。また、分析、データ基盤としてご利用いただける「Azure Synapse Analytics」や Apache Hadoop、Spark 実行環境である「HDInsight」などはデータウェアハウス環境とビッグデータ分析環境を統合した形で提供しています。

AI サービスの観点においても、多くの PaaS が提供されています。機械学習モデル構築からデプロイまでサポートする「Azure Machine Learning」に加え、プレビルドの学習モデルを備えた「Azure Applied AI Services」や「Azure Cognitive Services」は、意思決定支援、言語、音声、視覚の領域における AI サービスをすぐにご利用いただくことが可能です。

ID / Security:

Azureリソースへのアクセス権限を管理するロールベースアクセスコントロール (RBAC) の要となる機能として「Azure AD」が統合的なアクセス管理サービスを提供しています。Azure AD はゼロトラストセキュリティを実現する IDaaS (*4) 基盤として、ユーザーに対する多要素認証や条件付きアクセス、特権 ID 管理などの機能を「Premium (Premium1 および 2)」として提供しています。また、外部ユーザーの認証機能を提供する「Azure AD B2C」といったサービスも提供されています。

Security as a Service として、1st Party のクラウド・セキュリティサービスが充実している点も Azure の特徴です。Azure 上に展開するリソースのセキュリティ ポリシー管理や脆弱性防御など包括的なクラウド セキュリティ管理サービスとして、「Microsoft Defender for Cloud」が提供されています。クラウドセキュリティの動態管理機能 (CSPM (*5) ) としてコンプライアンス評価や Policy の強制、セキュリティ スコア管理などの機能を提供し、またクラウド ワークロード保護 (CWPP (*6) ) の観点では脅威検知や脆弱性の管理などのサービスが提供されています。

Microsoft は世界中で発生する膨大な脅威インテリジェンス情報を保有しており、この脅威情報や対策情報を Azure のセキュリティ サービスにフィードバックしています。例えば、クラウド SIEM (*7) サービスである「Microsoft Sentinel」では、クラウドネイティブな SOC 運用をサポートするため、Azure や Microsoft 365 のみならず、その他 SaaS やネットワーク機器等の多様なプラットフォームから収集されるログに基づく脅威検知、調査、対処といった一連の機能を提供しています。


*4 IDentity as a Service
*5 Cloud Security Posture Management
*6 Cloud Workload Protection Platform
*7 Security Information Event Management

Management:

Microsoft Azure 上の各種リソースの運用・管理等の観点からも多様なサービスが提供されています。

Azure Backup」は、仮想マシンなどのリソースのバックアップを取得・管理するサービスです。バックアップデータの可用性を維持するため 3 種類 (ローカル冗長、ゾーン冗長、地理冗長) のレプリケーション方法を提供しています。また、「Azure Site Recovery」では、本番環境から別リージョンへのレプリケーション機能を提供しています。当機能により本番環境などで障害が発生した場合は、周辺の特定リージョンへフェール オーバーすることができ、ビジネス継続性を提供します。

リソースのモニタリングやログ管理の統合運用サービスとしては、「Azure Monitor」を提供しています。仮想マシンやアプリケーションからのメトリックやログを収集し、正常性の監視や統合的なログ管理が利用可能となります。Azure Monitor が収集した多くの Azure リソースのデータは、Azure Portal からダッシュボードとして俯瞰的に参照することも可能ですし、REST API による参照も可能です。

本項は、Azure サービスのごく一部のご紹介となります。クラウドサービスでは日々サービスの拡充や機能強化が図られています。新機能やサービスのリリース情報は「Azure の更新情報」からご参照ください。

Azure のネットワーク網

Microsoft は、Microsoft Azure をはじめとするクラウドサービスを支えるデータセンター間を結ぶ世界最大規模のバックボーン ネットワークを所有・運営しています。グローバルに構築された自社保有の光ファイバーケーブルや海底ケーブルは、約 165,000 マイル (265,540 km) を超える距離にわたってデータセンターとお客様をつないでいます。その基盤となるのが、Microsoft のグローバル ネットワーク (WAN) です。世界各地に配置された 60 超の  Azure リージョン (後述) と膨大なエッジ ノード網全体にわたってマイクロソフトのデータセンターをつなぎ、可用性、キャパシティ、柔軟性を提供することで多様な需要に対応しています。 

画像:Azure のネットワーク網イメージ

グローバルに配置されたエッジノードを経由してお客様のトラフィックがこのグローバル ネットワークに入った瞬間から、データは最適なルートを通ってほぼ光速で移動します。これらのエッジ ノードは、175 を超える場所で、何千もの接続を介して、4,000 を超えるインターネット パートナー (ピア) に相互接続されています。例えば、ロンドンのユーザーが東京のサービスにアクセスする場合、インターネット トラフィックはロンドンのエッジのいずれかに送信され、フランスを経由して Microsoft WAN に送信され、ヨーロッパとインドの間のインド洋横断経路を通過し、サービスがホストされている日本に到達します。

マイクロソフトのクラウドおよびオンライン サービスの劇的な成長を促進しつつ、一貫した高水準のサービス レベルを維持するためには、都市部、地上、海底の各経路でファイバーの容量と多様性への莫大な投資が不可欠です。 このグローバル ネットワークに最近加わった例として、米ニューヨークとダブリン (アイルランド) を結ぶ AEC や、東京 とポートランド (米オレゴン州) を結ぶ New Cross Pacific (NCP) があります。常に最適なパフォーマンスを保証するために、ネットワークへの大規模な投資と共に 20 年の経験を重ねることで、Microsoft が提供するクラウドサービスの相互接続性が築かれています。

Azure リージョンと可用性ゾーン

Azure リージョンと可用性ゾーン

Micrsoft Azure は、世界に存在する多数のデータセンターで稼働しています。 これらのデータセンターは、「Azure 地域 (Geography)」と呼ばれる地域単位でグループ化されており、データ所在地とコンプライアンスの境界を保持しています。

各 Azure 地域 (以下 geo) は、複数の「リージョン」から構成されています。これらの geo・リージョン構成により、アプリケーションの構築場所を選択する際の柔軟性を提供しています。例えば、日本については「日本」という geo にカテゴライズされ、「東日本リージョン」と「西日本リージョン」から構成されています。

2021 年時点でリージョンは世界 60 超 (*8) に展開されており、今後も順次拡張が計画されています。各リージョンは、冗長性と可用性を確保するために複数のデータセンターから構成されています。このようなデータセンター設計により、可用性を考慮したアーキテクチャ設計や、ガイドライン、コンプライアンスなど各種の目的に合わせて利用することができます。


*8 近日提供予定リージョンおよび米国 Azure Government 含めた場合は 70 超のリージョン規模となります。

リージョンペア

同じ geo 内 (米国、ヨーロッパ、アジア、日本など) のリージョン間の組み合わせを「リージョンペア」と呼びます。例えば日本では、「東日本リージョン」と「西日本リージョン」がリージョンペアとなります。リージョンペアを使用したリソース (VM バックアップやストレージ冗長など) のレプリケーションなどにより、広域災害などを考慮したビジネス継続性やディザスターリカバリー要件への対応が可能となります。

画像:geo データ配置境界とリージョンペアの図

各可用性ゾーンは、独立した電源、冷却手段、ネットワーク インフラストラクチャを備えた 1 つまたは複数のデータセンターで構成されており、ゾーン間のネットワークもラウンドトリップ 2 ミリ秒未満の高パフォーマンスネットワークにより接続されています。これにより、仮に 1 つのゾーンに問題が発生した場合においても、残りの 2 つのゾーンによってシステムの高可用性をサポートするような設計が可能です。Microsoft Azure では、各サービスの「可用性ゾーン対応」を進めており、2021 年中には基本的サービスおよびメインストリームの Azure サービスが対応する予定です。また、今後新規に構築されるリージョンについては、原則可用性ゾーン対応するなど、継続的な投資が行われる予定です。

Our commitment to expand Azure Availability Zones to more regions | Azure Blog and Updates | Microsoft Azure (英文)

Microsoft Azure 各種コンプライアンス

Microsoft Azure は、グローバル、業界別、国別など約 90 以上の「コンプライアンス認証」を取得しています。これは世界各国でクラウドサービスを提供する上で、その地域や業界固有のコンプライアンス要件に対する包括的な対応が、事業活動における重要な礎であるとの認識に基づいています。

日本におきましても日本セキュリティ監査協会「CS ゴールドマーク」の取得をはじめとし、パートナー企業との連携による「金融情報システムセンター  (FISC) 安全対策基準」への対応や、「医療機関向けセキュリティリファレンス」など我が国固有のセキュリティ認証制度やガイドラインへの準拠にも対応しています。

画像:セキュリティ企画一覧

2021 年 6 月に、Microsoft Azure のみならず Microsoft Office 365、Dynamics 365 を含め「政府情報システムのためのセキュリティ評価制度 (ISMAP)」への登録が完了しております。

図:ISMAP紹介スライド

SLA

Microsoft Azure では、パブリッククラウド事業を展開するにあたり各サービスに対する SLA (Service Level Agreement) を定義しています。

SLA では、サービスのアップタイムの保証とダウンタイムに対するクレジットの返還ポリシーが定められています。通常、SLA はサービスのアップタイムのパーセンテージで示されており、一般的に 99.9% から 99.99% の範囲で定義がされています。また、SLA のパーセンテージやその適用前提は、そのサービスの重要性や運用実績などを踏まえて、定期的に見直し(改善)が図られています。例えば、Azure AD premium サービスについては、2021 年 4 月に 99.9% から 99.99% へ大きく見直しが実施されました。加えて、重要なポイントとして SLA は契約上の品質指標であるという点も挙げられます。Microsoft Azure サービスとして、より高い品質を目指した運用や改善を日々行っており、実稼働率としては SLA 上の数値よりも高い目標を持ってサービス運用しています。各サービスの SLA については「Azure サービスの SLA 概要」をご参照ください。

サービスによっては、SLA に構成上の前提事項などがある点もポイントとなります。例えば、仮想マシンの SLA は、選択するマネージドディスクの種別により 95% ~ 99.9% と SLA が変動します。さらに、選択する可用性の構成により 99.95% ~ 99.99% といったより高い SLA を担保することが可能になります。すなわち、クラウドアーキテクチャの可用性を考慮する上では、各サービスの SLA とその前提構成要件を認識しながら、検討することがポイントとなります。

システムの可用性の検討では、そのシステムが支える事業やシステム特性から求められる可用性要件と目標 SLA をサポートするクラウドアーキテクチャの実現可能性、さらにはコストの両軸から検討を進めることが重要となります。以下の Microsoft Learn のコースでは、SLA に関する詳しい解説や目標稼働率とサービスの設計の考え方に関する学習コンテンツが提供されています。クラウドサービスをご検討頂く際の参考情報として是非ご活用ください。

サービス レベル アグリーメント (SLA) とサービス ライフサイクルを調べて適切な Azure サービスを選択する (AZ-900) - Learn | Microsoft Docs

更新プログラムとメンテナンスの考え方

クラウドにおける共同責任」にてご紹介の通り、オンプレミス環境では、物理環境からアプリケーション層までお客様管理によるメンテナンスが保守の一環として実施されています。例えば、サーバーやディスクの物理層から仮想化基盤、OS、ミドルウェア等のそれぞれの層におけるメンテナンスが該当します。パブリッククラウドの IaaS および PaaS においては、クラウドサービス事業者が管理する領域があり、これら領域においては、一定の品質やセキュリティを担保するため、クラウドサービス事業者によるメンテナンスが実行されています。また、そのメンテナンスも計画的に実行されるメンテナンスから、緊急対応として突発的に適用されるメンテナンスなどがあります。

お客様リソースへのメンテナンス影響を極力軽減することを目指し、Microsoft Azure としてライブマイグレーション等のメンテナンス技術の高度化を推進しています。以下の Blog ではその取り組みについてご紹介しています。

影響がゼロまたは影響の少ないメンテナンス テクノロジの進化の変遷 | Azure のブログと更新プログラム | Microsoft Azure

また、メンテナンスの取り組みは IaaS の仮想マシンや PaaS のサービスにより異なるため、代表的な例を以下にご紹介します。

IaaS: 仮想マシン(VM)の例

仮想マシンに対する更新においては、その影響を最小とすべく努めていますが、その更新については大きく2種類のメンテナンス対応が図られます。

  • 再起動を必要としないメンテナンス

    ライブマイグレーションを含めた、再起動を必要としないメンテナンスでは、VMのメモリを保持しながらメンテナンス適用します。これにより一定時間の一時停止が発生しますが、その時間は10秒未満(ライブマイグレーションのケースでは5秒未満)です。この仕組みは、一部を除く主力となる仮想マシン・シリーズで実装されており、継続的に一時停止期間を短縮するためのメモリ保持メンテナンスの改善に取り組んでいます。なお、可用性セット等の構成により仮想マシンへのメンテナンス適用を分散することが可能です。可用性セットの考え方については、「Microsoft Azure の可用性と災害対策」でご紹介しています。

  • 再起動を必要とするメンテナンス

    稀に計画メンテナンスにより仮想マシンの再起動が必要となる場合があります。このようなケースでは事前にメンテナンス通知が送付されます。計画メンテナンスでは、「セルフサービス」と「予定メンテナンス」の2種類のフェーズがあります。セルフサービスでは、事前の通知において、都合に応じてお客様自身でメンテナンスを開始できる仕組みとなり、約 35 日間の時間枠の中でメンテナンス適用を行います。一方、可用性セットなど冗長構成を採用している場合には、セルフサービスではなく自動適用の予定メンテナンスを推奨しています。

PaaS: Azure App Service の例

PaaS のアプリケーション実行サービスである App Service の場合、基本的にメンテナンス通知は行われません。アップグレードやパッチは、アプリが動作している 仮想マシン / 物理サーバーとは別の 仮想マシン / 物理サーバーで実施され、更新が終わった 仮想マシン / 物理サーバーにアプリが移動された後、標準装備のフロントエンド LB (L7) で自動切換えされますので、ダウンタイムが発生しない前提となります。但し、利用しているインスタンス数が少ない場合、更新が掛かったインスタンスでは、アプリのコールドスタートとなる為、一時的なスループット低下が見られる場合があります。また、セッションステートなどをインスタンス内に保持していた場合、それは破棄される為、Azure Cache for Redis など、外部に保持するデザインにすることを推奨しています。

PaaS: Azure SQL Database の例

事前のメンテナンス通知」については、既定でない「メンテナンス期間」を使用するように構成した場合に行われます。

メンテナンスはアクセス中のインスタンス(プラマリ レプリカ)とは別のインスタンス / 物理サーバーに対して実施され、その後、メンテナンス済みのインスタンスがプライマリ レプリカに昇格します。接続断の期間は 1 秒程度で、クエリとして待たされる時間は数秒程度である為、アプリのリトライ実装により、ダウンタイム ゼロでの運用が可能です。

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。