WEBVTT 00:00.660 --> 00:01.710 講師：このレッスンでは､ 00:01.710 --> 00:04.920 ロードバランサの重要性についてお話します｡ 00:04.920 --> 00:06.120 ロードバランサーは､ 00:06.120 --> 00:15.330 コンテンツスイッチとも呼ばれ､ サーバーフォームやクラウドインフラストラクチャ内の多数のサーバーに受信リクエストを分散するために使用される｡ 00:15.330 --> 00:17.370 大規模なウェブサイトやサービスを運営している場合､ 00:17.370 --> 00:20.040 そのすべてを1台のサーバーで行うことはできません｡ 00:20.040 --> 00:23.513 例えば､ 私のコースを受講し､ 私のビデオを見ている生徒は､ 00:23.513 --> 00:25.680 現時点で数十万人いる｡ 00:25.680 --> 00:29.100 1台のサーバーでこれだけの負荷を処理できるわけがない｡ 00:29.100 --> 00:33.810 そのため､ 世界中のさまざまなサーバーに分散させなければならない｡ 00:33.810 --> 00:36.300 しかし､ 生徒が私のウェブサイトを見たいと思ったとき､ 00:36.300 --> 00:38.340 特定のサーバーを選ぶ必要はない｡ 00:38.340 --> 00:41.070 その代わり､ ディオントレーニングに行くだけだ｡ comのロードバランサーとコンテンツスイッチが､ 00:41.070 --> 00:47.460 そのリクエストを処理できる次の利用可能なサーバーにリダイレクトします｡ 00:47.460 --> 00:49.590 実際､ 私たちは世界中に何台ものサーバーを置き､ 00:49.590 --> 00:53.100 さまざまなリクエストに対応しています｡ 00:53.100 --> 00:57.480 ネットフリックスやフールー､ フェイスブックやアマゾンでもまったく同じことが起こっているが､ 00:57.480 --> 00:59.280 規模ははるかに大きい｡ 00:59.280 --> 01:01.920 こういった大規模なウェブサイトはすべてロードバランサーを使わなければならない｡ 01:01.920 --> 01:10.650 そうでなければ､ 1つのサーバーが負荷でクラッシュするだけで､ ウェブサイトの人気ゆえに自業自得のサービス拒否攻撃を受けてしまうからだ｡ 01:10.650 --> 01:12.510 ロードバランサーは基本的に､ サーバーの前に座り､ 01:12.510 --> 01:13.500 クライアントのリクエストを､ 01:13.500 --> 01:17.310 その時点で最もリクエストに応えられるサーバーにルーティングすることで､ 01:17.310 --> 01:20.970 トラフィックコップの役割を果たす｡ 01:20.970 --> 01:23.940 これにより､ ユーザーへの応答速度が最大化され､ 01:23.940 --> 01:25.530 すべてのユーザー・リクエストに対して､ 01:25.530 --> 01:30.060 サーバーの既存容量をより効率的に使用することができます｡ 01:30.060 --> 01:32.220 ロードバランサーがこれほど重要な理由は､ 01:32.220 --> 01:34.230 サービス拒否攻撃や分散型サービス拒否攻撃を防御するために､ 01:34.230 --> 01:39.270 ロードバランサーが重要な役割を果たすからだ｡ 01:39.270 --> 01:41.730 さて､ サービス拒否攻撃とは何か？ 01:41.730 --> 01:46.410 サービス拒否攻撃は､ 被害者のシステムにサービス要求が殺到し続け､ 01:46.410 --> 01:48.090 システムがメモリ不足に陥り､ 01:48.090 --> 01:51.570 最終的にクラッシュする｡ 01:51.570 --> 01:52.830 しかし､ ほとんどの最新システムは､ 01:52.830 --> 01:55.230 1台のマシンではダウンさせることができない｡ 01:55.230 --> 02:00.540 そのため､ 攻撃者は代わりにDDoS（分散型サービス拒否攻撃）を使用する｡ 02:00.540 --> 02:04.920 分散型サービス拒否攻撃では､ 1人の攻撃者がサーバーを標的にするのではなく､ 02:04.920 --> 02:07.200 何百台､ 何千台ものマシンが同時にサーバーに攻撃を仕掛け､ 02:07.200 --> 02:11.670 サーバーをオフラインに追い込む｡ 02:11.670 --> 02:16.410 例えば2018年3月､ GitHubはこれまでで最大規模のDDoSに見舞われた｡ 02:16.410 --> 02:20.160 何万ものユニークなエンドポイントが協調して攻撃を行い､ 02:20.160 --> 02:22.230 トラフィックの急増を計測したところ､ 02:22.230 --> 02:25.620 1. 毎秒35テラビット｡ 02:25.620 --> 02:28.980 このため､ 5分間だけサイトがオフラインになった｡ 02:28.980 --> 02:30.750 しかし､ 本当の問題は､ どうすればこのような攻撃から生き残り､ 02:30.750 --> 02:35.760 組織のサーバーがダウンするのを防ぐことができるかということだ｡ 02:35.760 --> 02:37.620 まあ､ ベストプラクティスのいくつかについて､ 02:37.620 --> 02:39.330 アマゾンを見ればいい｡ 02:39.330 --> 02:45.630 2020年2月､ アマゾンはこれまでで最大のDDoSに襲われた｡ 02:45.630 --> 02:49.230 そして､ そのサーバーにトラフィックを急増させ､ 02:49.230 --> 02:52.410 2. 毎秒3テラビットの攻撃であったが､ 02:52.410 --> 03:05.880 同社の優れたセキュリティ・アーキテクチャと､ その攻撃を維持するためにリソースをスケールアップする能力により､ GitHubをダウンさせた攻撃よりも70％も大規模な攻撃であったにもかかわらず､ ダウンタイムは発生しなかった｡ 03:05.880 --> 03:07.410 さて､ 彼らが最初に使ったテクニックは､ 03:07.410 --> 03:09.750 ブラックホリングあるいはシンホリングと呼ばれるものだ｡ 03:09.750 --> 03:10.800 これは､ あらゆる攻撃用IPアドレスを特定し､ 03:10.800 --> 03:19.410 そのトラフィックをすべてヌル・インターフェースを通じて存在しないサーバーにルーティングし､ 攻撃を効果的に阻止する技術である｡ 03:19.410 --> 03:23.760 残念なことに､ 攻撃者はいつでも新しいIPに移動して攻撃を再開することができる｡ 03:23.760 --> 03:25.950 そのため､ DDoSを永遠に防ぐことはできないが､ 03:25.950 --> 03:29.640 他の緩和策に取り組むまでの時間を稼ぐことはできる｡ 03:29.640 --> 03:32.070 IPS（侵入防御システム）は､ 03:32.070 --> 03:35.730 サービス拒否攻撃の特定と対応にも使用できる｡ 03:35.730 --> 03:38.520 これはネットワークに対する小規模な攻撃には有効かもしれないが､ 03:38.520 --> 03:45.060 アマゾンが標的にされたような真に大規模な攻撃を処理するには十分な処理能力を持たないだろう｡ 03:45.060 --> 03:46.920 現在､ 最も効果的な方法のひとつは､ 伸縮性のあるクラウドインフラストラクチャを使用することだ｡ 03:46.920 --> 03:54.300 伸縮性のあるクラウドインフラストラクチャは､ 必要に応じてオンデマンドでスケールアップできるため､ 攻撃を乗り切ることができる｡ 03:54.300 --> 03:57.090 しかし､ この戦略の問題点は､ ほとんどのサービス・プロバイダーが､ 03:57.090 --> 04:00.510 あなたが使用している容量とリソースに基づいて課金することだ｡ 04:00.510 --> 04:02.190 つまり､ 規模を拡大すると､ 04:02.190 --> 04:09.390 クラウド・サービス・プロバイダーからより多額の請求書を受け取ることになり､ 04:09.390 --> 04:15.090 投資対効果を得られないことになる｡ 04:15.090 --> 04:18.750 とはいえ､ 少なくともお金を払ってくれる顧客にサービスを提供するためにオンラインに残っていることは間違いない｡ 04:18.750 --> 04:24.213 つまり､ DDoS攻撃が継続するよりも長く持ちこたえる余裕があるかどうかが問題になる｡