WEBVTT

00:00.660 --> 00:01.710
이번 수업에서는 부하

00:01.710 --> 00:04.920
분산 장치의 중요성에 대해 이야기해 보겠습니다

00:04.920 --> 00:06.120
좋아요, 이제 부하

00:06.120 --> 00:08.340
분산 장치 콘텐츠 스위치라고도

00:08.340 --> 00:10.410
하죠 이건 수신 요청을 서버 폼이나

00:10.410 --> 00:11.910
클라우드 인프라 내의

00:11.910 --> 00:15.330
다수의 서버에 배포하는 데 사용됩니다

00:15.330 --> 00:17.370
대규모 웹사이트나 서비스를 운영하는 경우

00:17.370 --> 00:20.040
단일 서버에서 모든 작업을 수행할 수 없습니다.

00:20.040 --> 00:22.680
예를 들어 지금 수십만 명의 학생들이

00:22.680 --> 00:23.513
제 강의를 듣고

00:23.513 --> 00:25.680
제 영상을 보고 있어요

00:25.680 --> 00:29.100
서버 하나로 그 많은 부하를 처리할 순 없어요

00:29.100 --> 00:30.630
그래서 전 세계의 많은

00:30.630 --> 00:32.460
다양한 서버에 배포해야

00:32.460 --> 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:43.230
및 콘텐츠 스위치는 해당 요청을 처리할

00:43.230 --> 00:47.460
수 있도록 다음으로 사용 가능한 서버로 리디렉션합니다.

00:47.460 --> 00:49.590
네 사실 전 세계에 다양한 요청을

00:49.590 --> 00:50.880
처리하는 다양한

00:50.880 --> 00:53.100
서버가 엄청나게 많아요

00:53.100 --> 00:55.230
네 Netflix나 훌루 페이스북,

00:55.230 --> 00:57.480
아마존에서도 정확히 같은 일이 벌어졌죠

00:57.480 --> 00:59.280
하지만 훨씬 더 큰 규모예요

00:59.280 --> 01:01.920
네 네 그렇지 않으면 단일 서버가 부하에

01:01.920 --> 01:03.570
의해 크래시할 테니까요

01:03.570 --> 01:06.263
그리고 스스로 서비스 거부 공격을

01:06.263 --> 01:08.400
겪게 되죠 웹사이트의 인기

01:08.400 --> 01:10.650
때문에요 ,

01:10.650 --> 01:12.510
네 부하 분산기는 본질적으로 교통경찰의

01:12.510 --> 01:13.500
역할을 합니다 여러분의

01:13.500 --> 01:15.120
서버 앞에 앉아서 클라이언트의

01:15.120 --> 01:17.310
요청을 어느 때라도 해당 요청을 충족시킬

01:17.310 --> 01:19.410
수 있는 가장 이용 가능한 서버로 라우팅하는

01:19.410 --> 01:20.970
거죠

01:20.970 --> 01:23.940
사용자한테 응답하는 속도를 극대화하고

01:23.940 --> 01:25.530
사용자 요청을 위한

01:25.530 --> 01:28.170
서버에 기존 용량을 효율적으로

01:28.170 --> 01:30.060
사용합니다

01:30.060 --> 01:32.220
네 네 부하 분산 장치가 중요한 이유는

01:32.220 --> 01:34.230
서비스 공격 거부나 분산 서비스

01:34.230 --> 01:36.750
거부 공격을 방어하기 위한 중요한 것

01:36.750 --> 01:39.270
중 하나이기 때문이죠

01:39.270 --> 01:41.730
서비스 거부 공격이 뭐죠?

01:41.730 --> 01:43.560
글쎄요 서비스 거부는 피해자

01:43.560 --> 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
단일 시스템으로 중단될 수 없습니다.

01:55.230 --> 01:58.230
공격자는 디도스나 분산 서비스

01:58.230 --> 02:00.540
거부 공격을 사용합니다

02:00.540 --> 02:02.490
분산 서비스 거부(Distributed

02:02.490 --> 02:04.920
Denial of Service) 공격에서는 서버를

02:04.920 --> 02:07.200
대상으로 하는 단일 공격자가 아니라 수백 또는 수천 대의

02:07.200 --> 02:10.050
시스템이 동시에 서버에서 해당 공격을 시작하여 강제로 오프라인

02:10.050 --> 02:11.670
상태가 되도록 합니다.

02:11.670 --> 02:14.040
네 2018년 3월 예를 들어 GitHub가

02:14.040 --> 02:16.410
사상 최대의 디도스를 공격했습니다 수만

02:16.410 --> 02:25.620
개의 독특한 끝점이 그 서버를 공격했고 트래픽이 1까지 치솟았죠

02:25.620 --> 02:25.620
초당 35테라비트

02:25.620 --> 02:28.980
이로 인해 사이트가 5분 동안 모두 오프라인 상태가 되었습니다.

02:28.980 --> 02:30.750
하지만 진짜 질문은 어떻게

02:30.750 --> 02:32.670
이런 공격에서 살아남아 우리

02:32.670 --> 02:35.760
서버가 다운되는 걸 막을 수 있느냐는 거죠

02:35.760 --> 02:37.620
글쎄, 우리는 몇 가지 모범 사례를 찾기 위해 Amazon을

02:37.620 --> 02:39.330
살펴보기만 하면 됩니다.

02:39.330 --> 02:41.520
2020년 2월 Amazon은 GitHub보다

02:41.520 --> 02:45.630
훨씬 더 큰 규모의 DDoS 공격을 받았습니다.

02:45.630 --> 02:47.130
그리고 2를 측정하는 트래픽

02:47.130 --> 02:49.230
급증으로 해당 서버를 공격하는 공동

02:49.230 --> 02:52.410
공격이 있었습니다. 초당 3테라비트입니다

02:52.410 --> 02:55.470
하지만 보안 구조가 탄탄하고 공격을 유지하기

02:55.470 --> 02:57.480
위해 자원을 확장할 수 있어서

02:57.480 --> 02:58.950
공격 중에 가동 중지 시간을

02:58.950 --> 03:01.650
겪지 않았습니다 GitHub를 다운시킨

03:01.650 --> 03:05.880
것보다 70%나 컸는데도요

03:05.880 --> 03:07.410
첫 번째 기술은 블랙홀링

03:07.410 --> 03:09.750
혹은 싱크홀링입니다

03:09.750 --> 03:10.800
이 기술은 공격용

03:10.800 --> 03:13.020
ip 주소를 식별하고 널 인터페이스를

03:13.020 --> 03:14.400
통해 존재하지 않는 서버로

03:14.400 --> 03:17.160
트래픽 경로를 지정해 효과적으로 공격을

03:17.160 --> 03:19.410
막는 기술입니다

03:19.410 --> 03:22.050
안타깝게도 공격자는 언제든 다른 ip로 이동해

03:22.050 --> 03:23.760
공격을 재개할 수 있습니다

03:23.760 --> 03:25.950
네 디도스를 영원히 막을 순 없지만

03:25.950 --> 03:27.480
다른 완화 방법을 연구하는

03:27.480 --> 03:29.640
동안 시간을 벌어 줄 거예요

03:29.640 --> 03:32.070
해킹 방지 시스템도 사용할 수 있습니다

03:32.070 --> 03:33.510
네 하지만 시스템은

03:33.510 --> 03:35.730
작동하지 않습니다

03:35.730 --> 03:37.560
네 네트워크에 대한 소규모

03:37.560 --> 03:38.520
공격에는 통할지

03:38.520 --> 03:40.920
몰라도 아마존이 표적이 된 공격

03:40.920 --> 03:42.780
같은 대규모 공격에는 대응할

03:42.780 --> 03:45.060
능력이 부족해요

03:45.060 --> 03:46.920
자 가장 효과적인 방법 중 하나는

03:46.920 --> 03:49.140
탄력적인 클라우드 인프라를 이용하는

03:49.140 --> 03:52.290
겁니다 필요에 따라 규모를 확장할 수 있기 때문이죠 그래야

03:52.290 --> 03:54.300
공격을 피할 수 있습니다 ?

03:54.300 --> 03:55.770
네 이 전략의

03:55.770 --> 03:57.090
문제는 하지만

03:57.090 --> 04:00.510
안 그러면

04:00.510 --> 04:02.190
네 그래서 확장함에 따라 클라우드

04:02.190 --> 04:04.380
서비스 제공자로부터 훨씬 큰 청구서를

04:04.380 --> 04:05.940
받게 되고 이건 우리가 투자

04:05.940 --> 04:07.320
수익을 얻을 수 없는 게

04:07.320 --> 04:09.390
될 수 있어요 그 모든 트래픽이 우리

04:09.390 --> 04:15.090
조직에 어떤 수익도 창출하지 못했으니까요 모두 공격의 일부였어요

04:15.090 --> 04:17.280
그래도 온라인으로 손님을

04:17.280 --> 04:18.750
받잖아요

04:18.750 --> 04:20.400
그래서 디도스 공격이 계속될

04:20.400 --> 04:22.140
수 있는 시간보다 더 오래 버틸

04:22.140 --> 04:24.213
수 있느냐가 문제가 됩니다