WEBVTT

00:00:00.000 --> 00:00:08.520
例えばバージニア州のデータセンターなど一箇所でホスティングしているとします ニューヨークやシカゴの顧客には問題ありませんが東京ロンドンシドニーの人はどうでしょうか

00:00:08.520 --> 00:00:14.160
彼らがサイトにアクセスするたびにリクエストは海や大陸を超えてサーバーまで届かなければ なりません

00:00:14.160 --> 00:00:19.820
画像やページの読み込みAPI呼び出しの旅に同じ長い旅が行われ遅延が積み重なって いきます

00:00:19.820 --> 00:00:26.440
実は調査によるとページの読み込み時間が1秒遅れるだけでもコンバージョンが減り ユーザーは不満を抱いて離脱してしまいます

00:00:26.440 --> 00:00:32.880
しかしサイトが急激に拡散したりボットネットが攻撃を仕掛けてきたらどうなるでしょうか バージニア州にあるあなたの唯一のサーバーはパンクしてしまいます

00:00:32.880 --> 00:00:36.780
動作は遅くなり完全にダウンしてしまうことさえあります 予備の計画もなく立ち往生してしまいます

00:00:36.780 --> 00:00:42.340
東京ロンドンサンパウロなど異なる地域にサイトのコピーを作成すれば可用性の問題は解決できます それは助けになります

00:00:42.340 --> 00:00:46.700
しかし今度は別の問題が発生します どうやって各訪問者を適切な場所に誘導すれば良いのでしょうか

00:00:46.700 --> 00:00:51.880
日本のユーザーが誤って米国のサーバーにアクセスすることは避けたいはずです トラフィックを賢くルーティングする方法が必要です

00:00:51.880 --> 00:00:57.300
そこでアジュールフロントドアの出番です アジュールフロントドアとはグローバルな交通整理を行う景観のようなものです

00:00:57.300 --> 00:01:03.780
アジュールフロントドアを単なる交差点の景観ではなく 世界中の主要な交差点に配置された数千人の景観だと考えてください

00:01:03.780 --> 00:01:11.240
誰かがウェブサイトを訪れる度に最寄りの景観が東京ですねと声をかけます あなたにとって一番早いストアはシンガポールですよそこまで案内しましょうと誘導するのです

00:01:11.240 --> 00:01:18.440
では通常のロードバランサーと何が違うのでしょうか ほとんどのロードバランサーはレイヤー4で動作し ip アドレスやポートを見てトラフィックをルーティングします

00:01:18.440 --> 00:01:25.340
基本的なニーズにはそれで十分ですがアジュールフロントドアはレイヤー7で動作するため HTTP およびhttps トラフィックを理解できます

00:01:25.340 --> 00:01:33.460
入力された url を確認しブラウザのヘッダーをチェックして どのようなコンテンツを求めているかを判断しそれに基づいてスマートなルーティングを行います

00:01:33.460 --> 00:01:40.500
単にこの ip をあのサーバーへと送るのではなく ユーザー api へのリクエストは米国のバックエンドへ

00:01:40.500 --> 00:01:47.860
画像へのリクエストは東京のキャッシュへといった判断が可能です ではその裏側で何がこれを可能にしているのでしょうか

00:01:47.860 --> 00:01:55.840
アジュールフロントドアは世界130以上の都市に210以上のプレゼンスポイントを持つ マイクロソフトのグローバルネットワーク上で動作しています

00:01:55.840 --> 00:02:02.540
各プレゼンスポイントを小さな交通整理ブース つまりあらゆる主要都市にある初期リクエストを迅速に処理するための現地オフィスと考えてください

00:02:02.540 --> 00:02:08.320
ユーザーがサイトにアクセスするとバージニア州にあるオリジンサーバーまで移動するのではなく 最も近いブースに接続されます

00:02:08.320 --> 00:02:12.420
そのブースがリクエストをマイクロソフトのプライベートバックボーン経由でバックエンドに ルーティングします

00:02:12.420 --> 00:02:20.880
パブリックインターネットは予測不可能なためこれが重要になります トラフィックは複数のネットワークを何回も経由する可能性がありその度に遅延やパケット損失が発生する

00:02:20.880 --> 00:02:26.820
恐れがあります 一方マイクロソフトのバックボーンはデータセンターを直接つなぐ高速なプライベートネットワークです

00:02:26.820 --> 00:02:32.640
つまりリクエストが最寄りの拠点に到達すればその後の経路は高速で信頼性の高いハイウェイを通ることになります

00:02:32.640 --> 00:02:39.680
東京ロンドンサンパウロなど世界のどこにいるユーザーでも読み込み時間の短縮 低遅延より優れた体験を実現できます

00:02:39.680 --> 00:02:47.300
そしてこれらすべてが訪問者に意識されることなく自動的に行われます 3層の回復力 afd が稼働し続ける仕組み

00:02:47.300 --> 00:02:53.360
さてこのグローバルな交通整理という考え方は素晴らしいけれど その交通整理役自体がダウンしたらどうなるのかとお考えかもしれません

00:02:53.360 --> 00:02:58.080
アジュールフロントドアがアプリ全体の唯一の入り口であればそれは大きな単一障害点になると思いませんか

00:02:58.080 --> 00:03:03.340
マイクロソフトはその点も考慮しています フロントドアには3層の回復力が組み込まれておりほぼダウンすることはありません

00:03:03.340 --> 00:03:06.840
その仕組みをご説明します 第一層はフロントエンドです

00:03:06.840 --> 00:03:12.880
先ほど触れた210以上の拠点を覚えていますか 各拠点は完全に独立したトラフィックブースです

00:03:12.880 --> 00:03:19.680
これらのポップは世界130以上の都市に配置され マイクロソフトのデータセンターやパートナーのコロケーション施設で稼働しています

00:03:19.680 --> 00:03:25.380
各ポップには複数のサーバーラックがあり その上部にあるエッジコントローラーが内蔵ロードバランサーとして機能します

00:03:25.380 --> 00:03:31.260
ポップ内の一つのサーバーが故障しても エッジコントローラーが同じポップ内の正常なサーバーにトラフィックを再ルーティングします

00:03:31.260 --> 00:03:35.160
もしポップ全体がダウンした場合 エニーキャストIPアドレス指定が機能します

00:03:35.160 --> 00:03:41.540
訪問者のリクエストは次に近いポップへと自動的にルーティングされます 中断も手動操作も必要なく自動的に処理されます

00:03:41.540 --> 00:03:45.400
第2層はフォールバックです ではポップが過負荷になった場合はどうなるでしょうか

00:03:45.400 --> 00:03:48.860
大規模なトラフィック急増があったり 特定の地域のポップが複数同時にダウンしたりする場合です

00:03:48.860 --> 00:03:53.340
残りのポップだけでは負荷を処理しきれないかもしれません そこで登場するのがフォールバック層です

00:03:53.340 --> 00:03:57.920
これは別のポップセットで数百ではなく数十の規模ですが 同じソフトウェアとアーキテクチャで実行されています

00:03:57.920 --> 00:04:01.260
これらはパートナー施設ではなくマイクロソフトのデータセンター内にのみ存在します

00:04:01.260 --> 00:04:05.380
フロントエンドのポップがトラフィックを分散する必要があるとき リクエストはこのフォールバック層へ移行されます

00:04:05.380 --> 00:04:09.640
キャッシュもルーティングもセキュリティもすべて同じです 訪問者が違いに気づくことはありません

00:04:09.640 --> 00:04:12.620
表示がわずかに遅くなる可能性はありますがコンテンツは確実に届きます

00:04:12.620 --> 00:04:14.600
3つ目のレイヤー トラフィックシールドです

00:04:14.600 --> 00:04:19.460
これは監視役です フロントドアネットワーク全体を見守るグローバルな司令塔だと考えてください

00:04:19.460 --> 00:04:23.340
すべてのポップ拠点にわたってトラフィックパターン 負荷レベル正常性を監視します

00:04:23.340 --> 00:04:27.840
特定のポップが過負荷になると検知した場合 単にフォールバック層の作動を待つことはしません

00:04:27.840 --> 00:04:32.640
dnsによるフロントドアエンドポイントの解決方法を更新し 先回りしてトラフィックを振り向けます

00:04:32.640 --> 00:04:37.740
グローバルなエニーキャストipからリージョンipに切り替え クライアントを全く別のポップ群へ移動させることも可能です

00:04:37.740 --> 00:04:40.140
必要であれば大陸をまたいで移動させることさえできます

00:04:40.140 --> 00:04:43.260
このトラフィックシールドこそがフロントドアを魔法のように感じさせる理由です

00:04:43.260 --> 00:04:47.140
裏側で絶えず最適化を行い問題が発生する前にルートを調整しているのです

00:04:47.140 --> 00:04:49.200
ここで一つ触れておくべきことがあります

00:04:49.200 --> 00:04:52.700
2025年10月アジュールフロントドアは大規模な障害に見舞われました

00:04:52.700 --> 00:04:54.660
設定変更時に安全検証がスキップされ

00:04:54.660 --> 00:04:59.440
マイクロソフト365、Xbox Liveそして数千もの顧客サイトで広範囲にわたる影響が出ました

00:04:59.440 --> 00:05:01.400
マイクロソフトはそこから学び終えました

00:05:01.400 --> 00:05:04.440
設定パイプラインから非同期処理をすべて排除したのです

00:05:04.440 --> 00:05:07.440
今ではすべてのコードパスがロールアウト中にテストされます

00:05:07.440 --> 00:05:09.900
ロールバック時間は4時間から1時間に短縮され

00:05:09.900 --> 00:05:12.640
2026年3月までには10分を目指しています

00:05:12.640 --> 00:05:16.000
また将来の影響範囲をテナントの1%未満に抑えるため

00:05:16.000 --> 00:05:18.080
マイクロセルセグメンテーションも導入しています

00:05:18.080 --> 00:05:20.440
要するに完璧なシステムなど存在しませんが

00:05:20.440 --> 00:05:23.300
フロントドアの3層アーキテクチャはリージョン障害やトラフィックの急増

00:05:23.300 --> 00:05:25.740
そして設定ミスにも耐えられるよう設計されているのです

00:05:25.740 --> 00:05:28.440
ほとんどのアプリケーションにとってこれで十分すぎるほどです

00:05:28.440 --> 00:05:30.020
極めてミッションクリティカルなシステムであれば

00:05:30.020 --> 00:05:33.420
Azure Traffic Managerをフロントドアの前面に配置して緊急避難経路とすることもできますが

00:05:33.420 --> 00:05:35.400
それについてはまた別の機会に詳しくお話しします

00:05:35.400 --> 00:05:38.480
トラフィックの制御方法、ルーティング、オリジングループについて

00:05:38.480 --> 00:05:42.640
さて、210以上の拠点を持つこのグローバルな交通整理役と3層のバックアップがあるわけですが

00:05:42.640 --> 00:05:45.280
具体的にどうやって各訪問者の転送先を決めているのでしょうか

00:05:45.280 --> 00:05:47.280
そこで登場するのがオリジングループです

00:05:47.280 --> 00:05:50.740
オリジングループとは基本的にバックエンドサーバーの集合体のことです

00:05:50.740 --> 00:05:54.840
店舗のリスト、つまりウェブサイトやアプリが実際に動作している場所だと考えてください

00:05:54.840 --> 00:05:58.240
北米に1台、ヨーロッパに1台、アジアに1台のサーバーを置くこともできます

00:05:58.240 --> 00:06:00.320
これらはすべて同じオリジングループに入ります

00:06:00.320 --> 00:06:03.020
しかしフロントドアはそれらすべてに無差別にトラフィックを送るわけではありません

00:06:03.020 --> 00:06:05.080
常にそれらが稼働中かどうかを確認しています

00:06:05.080 --> 00:06:06.900
それがヘルスプローブです

00:06:06.900 --> 00:06:15.000
数秒ごとに各フロントドアのポップがサイトのルートや専用のヘルスエンドポイント、ヘルスなどといった特定のパスにアクセスしサーバーをピンします

00:06:15.000 --> 00:06:17.980
もしサーバーが応答しなかったりエラーコードを返したりした場合

00:06:17.980 --> 00:06:21.300
フロントドアはそのサーバーを異常と判断しトラフィックの送信を停止します

00:06:21.300 --> 00:06:25.820
店が営業中かどうかを確認してから客を案内する交通整理の警察官のようなものです

00:06:25.820 --> 00:06:30.740
しかし正常なサーバーが複数ある場合どのサーバーに訪問者を送るべきでしょうか

00:06:30.740 --> 00:06:34.960
フロントドアは優先度、レイテンシ、重みの3つの要素で判断します

00:06:34.960 --> 00:06:37.360
これらは特定の順序で連携して機能します

00:06:37.360 --> 00:06:38.800
最初は優先度です

00:06:38.800 --> 00:06:41.900
一方のサーバーをプライマリ、もう一方をバックアップとして指定できます

00:06:41.900 --> 00:06:44.900
プライマリを優先度1、バックアップを優先度2に設定します

00:06:44.900 --> 00:06:47.680
通常の状態では全てのトラフィックはプライマリに送られます

00:06:47.680 --> 00:06:50.420
そのためプライマリがダウンするとトラフィックはバックアップに切り替わります

00:06:50.420 --> 00:06:51.340
シンプルでしょう?

00:06:51.560 --> 00:06:55.520
これは障害発生時以外は1つのリージョンで全てを処理したいアクティブパッシブ構成に最適です

00:06:55.520 --> 00:06:58.020
では両方のサーバーをアクティブにしたい場合はどうでしょうか

00:06:58.020 --> 00:06:59.740
そこで登場するのがレイテンシです

00:06:59.740 --> 00:07:03.340
複数のサーバーの優先度が同じ場合、フロントドアはレイテンシが最も低い

00:07:03.340 --> 00:07:06.520
つまり訪問者の場所から応答が最も早いサーバーにトラフィックを送ります

00:07:06.520 --> 00:07:11.680
ロンドンのユーザーはヨーロッパのサーバーへ、東京のユーザーはアジアのサーバーへルーティングされます

00:07:11.680 --> 00:07:14.940
感度の設定もあり、デフォルトでは50ミリ秒です

00:07:14.940 --> 00:07:19.940
2つのサーバー間の差が50ミリ秒以内であれば、フロントドアはそれらを同等の速度とみなします

00:07:19.940 --> 00:07:23.680
これにより、ほぼ同じ速度のサーバー間での絶え間ない切り替えを防ぎます

00:07:23.680 --> 00:07:26.440
そしてレイテンシが同等の場合に登場するのが重みです

00:07:26.440 --> 00:07:29.300
重みを割り当てて、サーバー間でトラフィックを分割できます

00:07:29.300 --> 00:07:31.780
例えば、アプリの新バージョンをテストしたいとします

00:07:31.780 --> 00:07:35.220
現在のサーバーに重みを90、新しいサーバーに重みを10に設定できます

00:07:35.220 --> 00:07:39.680
これは、訪問者の約10人中9人が旧バージョンへ、1人が新バージョンへ行くことを意味します

00:07:39.680 --> 00:07:45.140
これは段階的なロールアウト、ABテスト、または異なる容量を持つサーバー間の負荷分散に最適です

00:07:45.140 --> 00:07:46.660
ここが重要な点です

00:07:46.660 --> 00:07:48.720
これらすべてが自動的に行われます

00:07:48.720 --> 00:07:52.000
オリジングループを一度設定すれば、あとはフロントドアが処理します

00:07:52.000 --> 00:07:57.080
サーバーを探索し、レイテンシを測定し、優先度を尊重し、重みに基づいてトラフィックを分散します

00:07:57.080 --> 00:08:00.780
そして、これらすべてをリクエストがバックエンドに到達する前のエッジで行います

00:08:05.220 --> 00:08:08.860
エッジにおけるセキュリティ、WAFとその先について

00:08:08.860 --> 00:08:10.840
では、セキュリティについて話しましょう

00:08:10.840 --> 00:08:16.640
フロントドアはマイクロソフトネットワークの最エッジに位置しているため、攻撃がサーバーに到達する前に阻止するのに最適な場所です

00:08:16.640 --> 00:08:19.560
建物の入り口にあるセキュリティチェックポイントと考えてください

00:08:19.560 --> 00:08:22.560
宙に入る人は全員、まずそこを通過しなければなりません

00:08:22.560 --> 00:08:28.460
そのチェックポイントはウェブアプリケーションファイアウォール、つまりWAFと呼ばれ、フロントドアのスタンダードとプレミアムの両方に組み込まれています

00:08:28.460 --> 00:08:31.060
一般的なウェブ攻撃を自動的にブロックします

00:08:31.060 --> 00:08:43.000
SQLインジェクション、攻撃者がホームフィールドに悪意のあるデータベースコマンドを潜り込ませようとするもの、クロスサイトスクリプティング、ページにスクリプトを注入するもの、あるいはDDOS攻撃、トラフィックでサーバーを圧倒しようとするもの、などです

00:08:43.000 --> 00:08:47.180
WAFはこれらすべてをエッジで捕捉し、オリジンに到達する前に遮断します

00:08:47.180 --> 00:08:50.520
自動保護に加え、カスタムルールを作成することも可能です

00:08:50.520 --> 00:08:55.640
例えば、サイトがヨーロッパの顧客専用であれば、他の地域からのトラフィックを完全にブロックできます

00:08:55.640 --> 00:09:00.520
あるいは、特定のIPアドレス範囲から絶えずサイトが調査されていることに気づいた場合、それもブロック可能です

00:09:00.520 --> 00:09:04.880
また、リクエストヘッダー、URLパターン、さらにはユーザーのブラウザに基づいてフィルタリングすることもできます

00:09:04.880 --> 00:09:08.200
WAFにより、誰がアクセスできて誰ができないかを非常に細かく制御できます

00:09:08.200 --> 00:09:10.180
ここで価格レベルが重要になります

00:09:10.180 --> 00:09:14.360
スタンダードでは、何をブロックし何を許可するかを定義するカスタムWAFルールを利用できます

00:09:14.360 --> 00:09:19.360
プレミアムではさらに、マイクロソフトの脅威インテリジェンスを活用したマネージドルールセットが追加されます

00:09:19.360 --> 00:09:24.540
これは、マイクロソフトがネットワーク全体で確認する現実の攻撃パターンに基づき、常に更新されます

00:09:24.540 --> 00:09:30.200
プレミアムにはボット保護も含まれており、自動化されたスクレーパーや認証情報スタッフィングなどのボットを自動的にブロックします

00:09:30.200 --> 00:09:35.800
また、プライベートリンクサポートが追加され、パブリックインターネットではなくプライベートネットワーク接続を介してオリジンに接続できるようになります

00:09:35.800 --> 00:09:39.420
つまり、バックエンドサーバーを外部世界から完全に隠すことができるのです

00:09:39.420 --> 00:09:41.300
フロントドアだけがそれらに到達できます

00:09:41.300 --> 00:09:43.340
これはセキュリティにおいて極めて重要です

00:09:43.340 --> 00:09:45.720
多くの攻撃はフロントドアを狙うわけではありません

00:09:45.720 --> 00:09:47.660
彼らはバックドアを探そうとします

00:09:47.660 --> 00:09:53.800
オリジンサーバーにパブリックIPアドレスがあると、攻撃者は直接調査を行い、すべてのフロントドア保護を回避できてしまいます

00:09:53.800 --> 00:09:59.160
プライベートリンクを使用すれば、オリジンにはパブリックエンドポイントがなく、フロントドア経由でしかアクセスできないため、それは不可能です

00:09:59.160 --> 00:10:02.420
そのため、誰かがサーバーのIPを見つけたとしても、そこに到達することはできません

00:10:02.420 --> 00:10:04.380
その結果、多層防御が実現します

00:10:04.380 --> 00:10:06.480
WAFがアプリケーション層の攻撃をブロックします

00:10:06.480 --> 00:10:08.640
カスタムルールが特定の要件に対応します

00:10:08.640 --> 00:10:10.740
ボット保護が自動化された脅威を阻止します

00:10:10.740 --> 00:10:13.140
そしてプライベートリンクがオリジンを不可視化します

00:10:13.140 --> 00:10:19.820
これらすべてがトラフィックがインフラストラクチャに到達する前のエッジで実行されるため、サーバーは攻撃への対応ではなく、コンテンツの配信に集中できます

00:10:19.820 --> 00:10:21.980
キャッシングで、さらなる高速化を

00:10:21.980 --> 00:10:26.080
ルーティングとセキュリティについて説明してきましたが、フロントドアをさらに役立てる機能がもう一つあります

00:10:26.080 --> 00:10:27.340
それはキャッシングです

00:10:27.340 --> 00:10:28.920
その概念は以下の通りです

00:10:28.920 --> 00:10:31.620
ウェブサイトのコンテンツの多くは、それほど頻繁には変更されません

00:10:31.620 --> 00:10:36.620
画像、CSSファイル、JavaScriptライブラリ、製品写真、場合によってはHTMLページなども含まれます

00:10:36.620 --> 00:10:46.320
すべての訪問者がオリジンサーバーからデータを取得しなければならない場合、サーバーは同じリクエストを何度も処理し、その度にインターネット越しに同じデータを送信することになるため、時間と帯域幅の無駄が生じます

00:10:46.320 --> 00:10:50.580
キャッシュ機能を使えば、静的コンテンツのコピーをエッジのポップ、拠点に保持することで、この問題を解決できます

00:10:50.580 --> 00:10:55.120
次に誰かが同じファイルをリクエストしたとき、ポップはそのファイルをオリジンに問い合わせることなく、即座に配信します

00:10:55.120 --> 00:10:58.280
これは、あらゆる料金所の横に小さな倉庫を置くようなものです

00:10:58.280 --> 00:11:02.520
すべてのお客様を工場へ送り返すのではなく、棚にあるものをそのまま渡すだけです

00:11:02.520 --> 00:11:04.300
パフォーマンスの差は劇的です

00:11:04.300 --> 00:11:08.160
海を越えて往復するのではなく、同じ都市にあるサーバーから応答が返ってきます

00:11:08.160 --> 00:11:10.500
数秒ではなく、数ミリ秒で完了します

00:11:10.500 --> 00:11:15.720
また、オリジンサーバーは処理するリクエスト数が減るため負担が軽減され、実際に処理が必要な動的コンテンツに集中できるようになります

00:11:15.720 --> 00:11:18.240
ただし、すべてが自動的にキャッシュされるわけではありません

00:11:18.240 --> 00:11:21.520
何がキャッシュされるか、どのくらいの期間キャッシュするかは自分で制御できます

00:11:21.520 --> 00:11:30.620
フロントドアは、オリジンからのMAXエイジやSマキサージといった標準的なキャッシュ制御ヘッダーを尊重しますが、必要に応じてキャッシュルールを直接設定し、オリジンのヘッダーを上書きすることも可能です

00:11:30.620 --> 00:11:35.840
コンテンツを更新した際は、キャッシュをパージ、削除、して、古いコピーを破棄し、新しいものを取得するようフロントドアに指示できます

00:11:35.840 --> 00:11:40.620
これは、製品の発売や価格変更など、新しいバージョンをすぐに反映させる必要がある場合に重要です

00:11:40.620 --> 00:11:41.760
ここがポイントです

00:11:41.760 --> 00:11:44.260
フロントドアは静的コンテンツ専用ではありません

00:11:44.260 --> 00:11:55.160
APIやパーソナライズされたページショッピングカートといった動的コンテンツであっても、リクエストが最寄りのポップに到達した後は、公共のインターネットではなくマイクロソフトの専用バックボーンを通ってオリジンへ送られるため、配信が高速化されます

00:11:55.160 --> 00:11:58.880
その専用バックボーンは、オープンなウェブよりも高速で信頼性が高いのです

00:11:58.880 --> 00:12:01.660
そのため、キャッシュされないリクエストでさえもスピードアップします

00:12:01.660 --> 00:12:04.980
これが、フロントドアと従来のCDNとの決定的な違いの一つです

00:12:04.980 --> 00:12:08.200
従来のCDNは静的コンテンツをキャッシュするだけで、それ以上のことはほとんど行いません

00:12:08.200 --> 00:12:11.100
フロントドアは静的コンテンツをキャッシュし、それ以外すべてを加速させます

00:12:11.100 --> 00:12:13.020
これぞまさに一石二鳥のサービスです

00:12:13.020 --> 00:12:15.020
料金プラン、どれを選ぶべきでしょうか?

00:12:15.120 --> 00:12:17.620
さて、最も重要な質問である、お金、の話をしましょう

00:12:17.620 --> 00:12:19.460
実際、これにはいくらかかるのでしょうか?

00:12:19.540 --> 00:12:21.260
また、どのプランを選ぶべきなのでしょうか?

00:12:21.360 --> 00:12:23.900
数字の話に入る前に、なぜこれが重要なのかを説明します

00:12:23.900 --> 00:12:28.760
選択するプランは価格だけでなく、アプリケーションを保護するためのセキュリティ機能にも影響します

00:12:28.760 --> 00:12:31.300
ご存知の通り、フロントドアには3つのバージョンがあります

00:12:31.300 --> 00:12:33.020
クラシックは古いバージョンです

00:12:33.020 --> 00:12:36.300
現在も機能しますが、マイクロソフトは新規プロジェクトでの使用を推奨していません

00:12:36.300 --> 00:12:38.260
クラシックは廃止の方向に向かっています

00:12:38.260 --> 00:12:42.640
2025年以降は新規リソースの作成ができなくなり、2027年には完全にリタイアとなります

00:12:42.640 --> 00:12:46.120
そのため、新しく始めるのであれば、スタンダードかプレミアムを検討することになります

00:12:46.120 --> 00:12:48.180
最もシンプルな内訳は以下の通りです

00:12:48.180 --> 00:12:50.980
スタンダードの基本料金は月額35ドルです

00:12:50.980 --> 00:12:53.360
プレミアムは月額330ドルです

00:12:53.360 --> 00:12:56.000
大きな差ですが、ここからが面白いところです

00:12:56.000 --> 00:12:59.720
ギガバイトあたりのデータ転送料金は、両方のティアで同一です

00:12:59.720 --> 00:13:04.800
北米と欧州では、最初の10テラバイトまで、送信トラフィックは1ギガバイトあたり約8.25セントです

00:13:04.800 --> 00:13:07.620
エッジからオリジンへの転送は、1ギガバイトあたり約2セントです

00:13:07.620 --> 00:13:09.280
どちらも同じ料金体系です

00:13:09.280 --> 00:13:11.940
では、追加の300ドルで何が得られるのでしょうか

00:13:11.940 --> 00:13:12.600
機能です

00:13:12.600 --> 00:13:16.880
プレミアムには、マイクロソフトの脅威インテリジェンスを活用した管理対象ワフルールが追加されます

00:13:16.880 --> 00:13:20.440
このルールは、実際の攻撃パターンに基づいて自動的に更新されます

00:13:20.440 --> 00:13:26.520
さらに、ボット保護、パブリックインターネットからオリジンを隠すプライベートリンクサポート、そして詳細なセキュリティ分析も利用できます

00:13:26.520 --> 00:13:31.700
スタンダードでは、グローバル負荷分散、キャッシュ、動的アクセラレーション、カスタムワフルールが提供されます

00:13:31.700 --> 00:13:34.720
IP範囲、国、またはリクエストパターンをブロックできます

00:13:34.720 --> 00:13:37.680
ただし、管理対象ルールセットやプライベートリンクは利用できません

00:13:37.680 --> 00:13:39.320
リクエスト料金も異なります

00:13:39.320 --> 00:13:43.180
スタンダードは、最初の2億5000万リクエストまで、1万リクエストあたり約9セントです

00:13:43.180 --> 00:13:45.500
プレミアムは、1万リクエストあたり約15セントです

00:13:45.500 --> 00:13:47.140
大規模になると、その差は大きくなります

00:13:47.140 --> 00:13:48.740
では、どのように選べば良いのでしょうか

00:13:48.740 --> 00:13:50.220
私の経験則をお伝えします

00:13:50.220 --> 00:13:55.280
一般的なウェブサイトやAPIを運営しており、グローバルなパフォーマンスと基本的なセキュリティが必要な場合は、スタンダードから始めましょう

00:13:55.280 --> 00:14:00.140
月額35ドルの基本料金は手頃で、カスタムワフルールで一般的な脅威のほとんどに対応できます

00:14:00.140 --> 00:14:03.320
セキュリティニーズが高まれば、後からいつでもアップグレードできます

00:14:03.320 --> 00:14:10.580
規制の厳しい業界、ヘルスケア、金融、政府など、や、機密性の高い顧客データを扱う場合は、追加コストを払ってでもプレミアムを選ぶ価値があります

00:14:10.580 --> 00:14:14.440
管理対象ワフルールは、自分ではブロックを思いつかないような脅威も補足してくれます

00:14:14.440 --> 00:14:19.380
プライベートリンクはオリジンを不可視に保ち、ボット保護はスタンダードでは防げない自動攻撃を阻止します

00:14:19.380 --> 00:14:25.560
最後に、静的コンテンツの配信のみで、ルーティングやセキュリティ機能が不要な場合は、従来のCDNの型が安上がりかもしれません

00:14:25.560 --> 00:14:30.960
マイクロソフトのAzure CDNは現在も利用可能で、純粋な静的配信であれば、多くの場合コスト効率が高くなります

00:14:30.960 --> 00:14:38.100
しかし、ルーティング、セキュリティ、キャッシュ、アクセラレーションを必要とするほとんどの実際のアプリケーションでは、フロントドアスタンダードが最適な選択肢です

00:14:38.100 --> 00:14:41.000
これらをすべて統合した、実際の例を見てみましょう

00:14:41.000 --> 00:14:45.240
すべての要素がどのように機能するかを理解していただくために、実際のシナリオで説明します

00:14:45.240 --> 00:14:47.680
あなたがeコマースサイトを運営していると想像してください

00:14:47.680 --> 00:14:50.500
北米、欧州、アジアの3つのリージョンにサーバーがあります

00:14:50.500 --> 00:14:53.860
顧客は日本、ブラジル、南アフリカなど世界中にいます

00:14:53.860 --> 00:14:58.080
フロントドアがない場合、東京の顧客は米国のサーバーに直接接続することになります

00:14:58.080 --> 00:15:01.760
画像、製品ページチェックアウトのリクエストのすべてが、太平洋を横断しなければなりません

00:15:01.760 --> 00:15:02.920
それでは遅すぎます

00:15:02.920 --> 00:15:05.900
そして、米国のサーバーがダウンすれば、その顧客にはエラーが表示されるだけです

00:15:05.900 --> 00:15:07.540
ここで、フロントドアを追加しましょう

00:15:07.540 --> 00:15:09.460
東京の顧客があなたのサイトを開きます

00:15:09.460 --> 00:15:12.440
ブラウザは最寄りのAzure拠点、仮に東京としましょう、に接続します

00:15:12.440 --> 00:15:15.680
その拠点は3台のサーバーの健全性をチェックし、すべて正常であることを確認します

00:15:15.680 --> 00:15:16.860
遅延を測定します

00:15:16.860 --> 00:15:21.460
アジアのサーバーが最も早く応答するため、マイクロソフトの専用バックボーン経由でリクエストをそこにルーティングします

00:15:21.460 --> 00:15:23.900
ページは3秒ではなく1秒未満で読み込まれます

00:15:23.900 --> 00:15:27.240
では、フラッシュセールの最中にアジアのサーバーが過負荷になったと想像してください

00:15:27.240 --> 00:15:30.040
フロントドアのヘルスプローブが遅延の増大を検知します

00:15:30.040 --> 00:15:33.880
次に最適な選択肢であるヨーロッパのサーバーへトラフィックを移行し始めます

00:15:33.880 --> 00:15:36.400
顧客は依然として高速な体験を得られます

00:15:36.400 --> 00:15:40.200
アジアのサーバーほどではないかもしれませんが、米国まで行くよりは高速です

00:15:40.200 --> 00:15:43.680
テールオーバーは誰も設定を触ることなく自動的に行われます

00:15:43.680 --> 00:15:45.740
その間、WAFはエッジで稼働しています

00:15:45.740 --> 00:15:49.220
決済フォームを調査するBotnetからのSQLインジェクション攻撃をブロックします

00:15:49.220 --> 00:15:51.900
基地の悪意あるIP範囲からのトラフィックをブロックします

00:15:51.900 --> 00:15:55.320
また、製品カタログをスクレーピングしているIPからのリクエストをレート制限します

00:15:55.320 --> 00:15:58.000
これらの攻撃は一度もオリジンサーバーに到達することはありません

00:15:58.000 --> 00:16:00.380
バックエンドチームは攻撃があったことさえ知りません

00:16:00.380 --> 00:16:05.980
そして静的コンテンツ、製品画像、CSSファイル、JavaScriptライブラリは東京の拠点にキャッシュされます

00:16:05.980 --> 00:16:08.760
最初の訪問者はそれらをアジアのオリジンから読み込みます

00:16:08.760 --> 00:16:11.940
2番目の訪問者はエッジキャッシュから瞬時に取得します

00:16:11.940 --> 00:16:17.320
リピーターは必要なものがすべて近くのエッジ拠点にあるため、ほぼ瞬時に読み込みます

00:16:17.320 --> 00:16:21.480
高速ルーティング、自動フェールオーバー、エッジセキュリティ、コンテンツキャッシュ

00:16:21.480 --> 00:16:23.400
これらすべてがシームレスに連携します

00:16:23.400 --> 00:16:25.220
顧客はそれが存在することさえ知りません

00:16:25.220 --> 00:16:27.500
彼らに見えるのは高速で信頼性の高いサイトだけです

00:16:27.500 --> 00:16:29.080
覚えておくべきポイントはこれです

00:16:29.080 --> 00:16:35.260
Azureフロントドアは世界的な交通整理役としてユーザーを最速のサーバーへ導き、エッジでコンテンツをキャッシュし、攻撃が届く前にブロックします

00:16:35.260 --> 00:16:40.160
3層の回復力に基づいて構築されているため、たとえ1つのリージョンがダウンしてもサイトは稼働し続けます

00:16:40.160 --> 00:16:45.540
ほとんどのプロジェクトにおいて、月額わずか35ドルのスタンダードプランがパフォーマンスとコストのバランスに優れています

00:16:45.540 --> 00:16:49.260
高度なセキュリティやプライベートリンクが必要な場合は、プレミアムへアップグレードしてください

00:16:49.260 --> 00:16:52.080
単一のオリジンで小さく始め、そこから拡大していけます

00:16:52.080 --> 00:16:54.040
フロントドアはあなたと共に成長します

00:16:54.040 --> 00:16:58.000
ウェブアプリのユーザーが複数の地域に分散しているなら、今すぐフロントドアプロファイルをセットアップしましょう

00:16:58.000 --> 00:17:01.580
サーバーが1台だけでも、グローバルな高速化とセキュリティの恩恵を受けられます

00:17:01.580 --> 00:17:06.280
お気に入りのポッドキャストプラットフォームで登録し、クラウドの旅を始めたばかりの誰かにシェアしてください