Azure 上での Azure.com の運用 パート 1: 設計の原則とベスト プラクティス

2020年6月24日 に投稿済み

Senior Software Engineer

Azure は、世界中のクリエイティブな人々の手に、強力なクラウド コンピューティング ツールを届けます。Web サイトがそのブランドの看板となる場合、自分たちが構築しているものを使用するべきですし、それは当然良いものであるべきです。同様に、それは 99.99% の複合 SLA を提供しているべきです。

それが、Azure.com での私たちの仕事です。マイクロソフトが次の素晴らしいアイデアを実現するよう人々を鼓舞するためのプラットフォームです。Azure.com は、毎日何百万人もの人々にコンテンツを提供しています。ほぼあらゆる国の人に到達し、27 の言語でローカライズされています。このすべてを、この Web サイトが推進しているまさにそのツール上で動作しつつ、行っています。

Azure.com を開発する上で、私たちは自分たちが推奨していることを実践しています。私たちは、お客様に採用するようお勧めしている基本原則と、持続可能なソフトウェア エンジニアリング (英語) (SSE) の原則に従っています。このブログ記事も、それが説明しているインフラストラクチャ上でホストされているのです。

2 つのパートで構成されるシリーズのパート 1 では、Azure.com の Web ページの舞台裏に着目し、主なブランド Web サイトを世界規模で運用することについての私たちの方針について説明します。そして、世界的な規模での、セキュリティ、回復性、スケーラビリティ、可用性、環境持続可能性、およびコスト効率の高い運用のための私たちの設計アプローチとベスト プラクティスを紹介します。

Azure.com 上でサポートされる製品、機能、およびデモ

コンテンツ プラットフォームとして、Azure.com は S&P 500 企業から独立系ソフトウェア ベンダー、政府機関から小規模企業にいたるまで、ビジネスおよび技術関係者にサービスを提供しています。コンテンツがあらゆる人に届くようにするために、私たちは Web Content Accessibility Guidelines (WCAG) に準拠しています。また、持続可能なソフトウェア エンジニアリングの原則を採用して、責任を持ってグローバル スケールを実現し、二酸化炭素排出量を削減 (英語) するよう努めています。

Azure.com は、製品と機能の説明のような、静的コンテンツをサポートしています。しかし本当に面白いのは、読者が詳細をカスタマイズできるインタラクティブなコンポーネントです。たとえば、61 のリージョン (現在も拡大中) にまたがってサービスの可用性を示す リージョン別の利用可能な製品のページや、Azure の変更についてお知らせする Azure の更新情報ページ、および検索ボックスなどがあります。

Azure の価格ページでは、複数の市場にまたがる 200 以上のサービスに対する最新の価格情報を提供し、サインインしているユーザーが対象となる割引も考慮に入れられます。また、すべてのサービス向けの包括的な料金計算ツールも構築しました。購入を検討しているお客様は、24 の通貨で複雑なコストの見積もりを計算して、共有することができます。

マーケティング チャネルとして、Azure.com はデモもホストしています。たとえば、Azure Cognitive Services のメリットを紹介するブラウザー内のインタラクティブなデモを作成し、ストーリーテリングのためのストリーミング メディアをサポートしています。また、27 の言語と 12 のリージョンで、クラウド移行による節減を見積もるための総保有コスト (TCO) 計算ツールも提供しました。

さらに、Azure.com が 99.99% の複合 SLA を満たしていることも付け加えなければいけません。

Azure 料金計算ツール

料金計算ツール: すべての Azure 製品とサービスのためのインタラクティブなコスト見積ツール。

Azure.com の歴史

Azure サービスの数が増加するにつれて、私たちの Web サイトも拡大しており、常に Azure 上で実行されています。Azure.com は常時進行中の作業ではありますが、開発の歴史には以下のようないくつかのマイルストーンがあります。

  • 2013 年: Azure.com は人気のあるオープン ソースの Umbraco CMS 上でスタートしました。コンピューティング、データ サービス、アプリ サービス、およびネットワークの 4 つのカテゴリに分けて、7 つの Azure サービスのマーケティングを行っていました。
  • 2015 年: Azure.com は Azure 上でホストされるカスタムの ASP.NET MVC (Model-View-Controller) アプリケーションに移行しました。4 つのカテゴリにまたがる 16 の Azure サービスをサポートするようになりました。
  • 2020 年: Azure.com はより多くのカテゴリのコンテンツをサポートするよう拡大を続けています。現在、Azure サービスと機能を含む 200 以上の Azure オファリングについて説明しています。

 

Azure.com のサポートされる製品とサービスのタイムライン。

Azure.com のタイムライン: 毎年より多くの優れた Azure 製品とサービスをサポートしている。

Azure.com を支える設計原則

Azure.com の強固なアーキテクチャの基盤を構築するために、私たちは優れた Azure アーキテクチャの中核をなす柱に従っています。その柱とは、セキュリティ、パフォーマンス、可用性、および効率性を支える設計原則です。Azure.com がスムーズに動作し、ビジネス目標を満たすことができるのは、この設計原則があってこそです。

優れた Azure アーキテクチャの中核的な柱

設計原則: Azure.com は Azure アーキテクチャのベスト プラクティスの原則に従う。

Microsoft Azure Well-Architected Framework を使用して優れたソリューションを構築する方法についてのクラスを受講できます。

セキュリティと回復性の柱

あらゆるクラウド アプリケーションがそうであるように、Azure.com ではすべての層においてセキュリティを必要とします。これは、ネットワークからアプリケーション、Web ページ、およびバックエンドの依存関係まで、あらゆるものが開放型システム間相互接続 (OSI) モデルの対象となることを意味します。これが、私たちのセキュリティに対する多層防御アプローチです。

回復性とは、お客様のコンピューティング リソースを飽和させ、不要なスケールアウトやコスト超過を生じさせる可能性のある悪意のある攻撃、攻撃者、またはボットから防御する能力です。回復性は、障害を回避するための機能ではなく、ダウンタイムやデータ損失を回避する方法で障害に対処するための機能です。

回復性の 1 つのメトリックは、目標復旧時間 (RTO) で、サービス停止の発生後にアプリケーションをオフラインにすることができる許容時間です。私たちの場合、それは 30 分未満です。障害モード分析 (FMA) は、回復性の別の評価方法で、障害に備えて計画することと実地演習を実施することが含まれます。私たちはこれらの手法の両方を使用して、Azure.com の回復性を評価しています。

優れた拡張性と高可用性

すべてのクラウド アプリケーションでは、ピーク負荷を処理するための拡張性を必要とします。Azure.com の場合、ピークは大きなイベントやマーケティング キャンペーン時に発生します。負荷にかかわらず、Azure.com では 24 時間体制の運用をサポートするための高可用性を必要とします。私たちは、ビジネスの継続性をサポートし、予期しない停止、過負荷のリソース、またはアップストリームの依存関係によって生じる障害から保護を提供するプラットフォームを信頼しています。

代表的な例として、私たちは Azure.com で対応する最大規模の年次イベントである Microsoft Build (英語)Microsoft Ignite (英語) の期間中の需要の大幅な急増に対処するために、Azure の拡張性に依存しています。何万人ものイベントの参加者が新しく発表された Azure の製品とサービスについて知ろうと Azure.com に殺到すると、1 秒あたりの要求数 (RPS) は 20 ~ 30% 跳ね上がります。

その規模にかかわらず、Azure プラットフォームはマイクロソフトやその他の企業が顧客にプレミアム コンテンツを提供することを可能にする、信頼性の高い、持続可能な運用を提供します。

コスト効率の高いハイパフォーマンスが設計の基本原則

マイクロソフトのお客様はしばしば、コストを節約するためにクラウドベースのシステムに移行したいと言われます。それは Azure.com においても同じで、コスト効率の高いプロビジョニングが、設計の基本原則です。Azure.com には、便利なコスト計算ツールがあり、オンプレミスで実行するコストと Azure 上で実行するコストを比較することができます。

効率性とは、活用されていないリソースを追跡および最適化して、動的なスケーリングを使用して季節的なトラフィックの需要をサポートする手段を擁していることを意味します。この原則は、すべての作業項目の管理から始まり、ソース コード リポジトリの使用、継続的な統合 (CI) と継続的なデプロイ (CD) の実装にいたる、ソフトウェア開発ライフサイクル (SDLC) のすべての層に適用されます。コスト効率性は、複数の環境でリソースをプロビジョニングおよびホストし、デジタル資産のインベントリを維持する方法にまで及びます。

しかし、コスト意識が高いことは、スピードを犠牲にするということではありません。最高のパフォーマンスには、最小限のネットワーク待機時間、高速のサーバー応答時間、そして一貫性のあるページ読み込みとレンダリング時間が必要です。Azure.com のパフォーマンスは、常にユーザー エクスペリエンスに焦点を当てているため、ネットワーク ルーティングを最適化し、往復時間 (RTT) を最小限に抑えることを徹底しています。

ゼロ ダウンタイムによる運用

大規模な Web アプリケーションにとって、アップタイムは重要です。私たちは、ゼロ ダウンタイムを目指しています。つまり、サービスのダウンタイムがまったく生じないということです。これは非常に高い目標ですが、ユーザーが構築とデプロイのサイクルの影響を受けないようにする CI/CD のプラクティスを使用することで、実現可能です。

たとえば、コードの更新をプッシュする場合、私たちはサイトのダウンタイム、要求の失敗、および Azure.com ユーザーに対する悪影響が生じないようにすることを目指します。私たちの CI/CD パイプラインは、Azure DevOps に基づいており、毎日滞りなく何百ものビルドと複数のデプロイを実稼働サーバーに送り出します。

私たちが使用するもう 1 つのサービス レベル インジケーター (SLI) は、平均修復時間 (MTTR) です。このメトリックの値は低いほど適切です。MTTR SLI を最小限に抑えるには、ボトルネックまたはクラッシュしているプロセスを特定し、修復するための DevOps ツールが必要です。

次のステップ

Azure.com における経験から、これらの設計原則とベスト プラクティスに従うことで、アプリケーションの回復性の向上、コストの削減、セキュリティの強化、拡張性の確保が実現できると言えます。

お客様の Azure アーキテクチャの作業についてレビューするには、アーキテクチャの評価 (英語) を実施してください。

Azure.com を構成する Azure サービスの詳細については、このブログの記事である Azure 上での Azure.com の運用 パート 2: テクノロジとアーキテクチャを参照してください