WEBVTT

00:00.090 --> 00:00.923
네 강사 요즘에는

00:00.923 --> 00:02.880
클라우드 컴퓨팅이 어디서나 찾을 수

00:02.880 --> 00:05.580
있습니다 클라우드 컴퓨팅을 이용하면 훌륭한 장점이

00:05.580 --> 00:07.290
정말 많기 때문이죠

00:07.290 --> 00:09.510
그게 이번 수업에서 집중하게 될 겁니다

00:09.510 --> 00:10.343
클라우드의 다양한

00:10.343 --> 00:12.930
특성에 관해 얘기하면서 말이죠

00:12.930 --> 00:15.160
클라우드 컴퓨팅에 대해 이야기할 때

00:15.160 --> 00:17.670
클라우드 사용을 선택할 때 볼 수 있는 몇 가지

00:17.670 --> 00:19.680
이점이나 특성이 있습니다.

00:19.680 --> 00:23.460
이러한 요소들은 고가용성과 확장성 탄력성 계량된

00:23.460 --> 00:24.750
활용도 공유 리소스와

00:24.750 --> 00:27.540
파일 동기화를 포함합니다

00:27.540 --> 00:29.040
이것들을 살펴보겠습니다.

00:29.040 --> 00:31.350
먼저, 고가용성입니다

00:31.350 --> 00:32.749
고가용성은 클라우드를

00:32.749 --> 00:34.410
사용할 때 서비스가 가동 중지

00:34.410 --> 00:37.800
시간을 거의 경험하지 않는다는 걸 의미합니다

00:37.800 --> 00:39.690
클라우드에서 구축된 서비스는 대부분

00:39.690 --> 00:41.670
신뢰도가 높고 결함에 잘 견디도록 설계되었기

00:41.670 --> 00:43.200
때문입니다

00:43.200 --> 00:45.900
이 말은 고 수준의 가용성을 보장할 수 있다는 거죠

00:45.900 --> 00:47.610
네 이제 사용 가능성에 관해서는

00:47.610 --> 00:50.160
퍼센트의 측면에서 측정합니다 가동

00:50.160 --> 00:53.760
시간의 양과 가동 중지 시간의 양이죠 ?

00:53.760 --> 00:55.920
예를 들어, 네트워크 내부의 황금 표준은 파이브

00:55.920 --> 00:58.860
나인(five nines)으로 알려져 있습니다.

00:58.860 --> 01:02.970
9가 5개면 99를 의미합니다. 999% 가동 시간이나

01:02.970 --> 01:06.390
이용 가능성을 제공합니다

01:06.390 --> 01:09.030
따라서 1년에 5분 15초만

01:09.030 --> 01:11.980
가동 중지할 수 있어요

01:11.980 --> 01:15.090
맞습니다. 1년 365일 전체에

01:15.090 --> 01:18.570
걸쳐 단 5분 15초만.

01:18.570 --> 01:20.400
이제 이를 위해서는 가용성이 높고

01:20.400 --> 01:23.430
신뢰성이 높은 시스템이 필요하다는 의미입니다.

01:23.430 --> 01:25.330
따라서 하나의 웹 사이트가 있다면 실제로는

01:25.330 --> 01:29.123
해당 웹 사이트를 호스팅하는 웹 서버가 두 개 이상 있을 것입니다.

01:29.123 --> 01:30.300
네 하나가 다운돼도 다른

01:30.300 --> 01:32.160
하나가 여전히 부하를 운반해요 그건

01:32.160 --> 01:35.730
최종 사용자는 가동 중지 시간을 경험하지 않는다는 뜻이죠

01:35.730 --> 01:36.690
고가용성에 대해 이야기할

01:36.690 --> 01:38.640
때 이것이 바로 우리가 말하는 것입니다.

01:38.640 --> 01:42.210
예를 들어, 제 웹사이트 디온 트레이닝을 만들 거예요 클라우드 서비스를

01:42.210 --> 01:44.760
이용해 만든 고가용성

01:44.760 --> 01:47.280
셋업이 있습니다

01:47.280 --> 01:50.070
네 그래서 여러분이 어디에서 오느냐에

01:50.070 --> 01:51.060
따라 전 세계에

01:51.060 --> 01:53.160
있는 여러 서버 중 하나로 연결될

01:53.160 --> 01:55.680
거예요 가장 가까운 서버로요

01:55.680 --> 01:57.627
네 이제 서버가 다운되면 자동으로

01:57.627 --> 02:00.300
다른 서버로 릴럿이 돼요 여러분한테서 약간

02:00.300 --> 02:02.490
멀지만 여전히 있는 곳으로요 ,

02:02.490 --> 02:04.980
이렇게 여러분이 원하는 서비스를

02:04.980 --> 02:08.460
얻을 수 있고 고가용성을 보장하는 방법이죠

02:08.460 --> 02:10.590
클라우드의 두 번째 특징은

02:10.590 --> 02:12.480
확장성입니다

02:12.480 --> 02:15.150
이제 확장성에 대해 이야기할 때 이는

02:15.150 --> 02:17.370
선형 속도 또는 선형 속도보다 낮은

02:17.370 --> 02:19.080
속도로 시스템의 사람 수나

02:19.080 --> 02:23.220
사물 수를 늘릴 수 있다는 사실을 의미합니다.

02:23.220 --> 02:24.053
그 말은 100명의

02:24.053 --> 02:26.850
사용자가 제 시스템을 쓴다고 할 때 10달러를

02:26.850 --> 02:28.620
내야 한다는 거죠

02:28.620 --> 02:31.282
음 만약 시스템에 200명의 사용자를 추가한다면

02:31.282 --> 02:35.010
20달러 이하의 비용이 들 것입니다. 그것은 직선적인 배율입니다.

02:35.010 --> 02:37.860
네 이제 이제 기하급수적인

02:37.860 --> 02:40.500
규모가 될 테니 그건

02:40.500 --> 02:43.380
원치 않죠 ? 네

02:43.380 --> 02:45.180
따라서 우리는 클라우드 시스템을 구축하면서

02:45.180 --> 02:47.070
항상 확장성을 추구합니다. 즉, 오늘은

02:47.070 --> 02:49.860
사용자가 10명만 있어도 내일은 100명이 될 수도 있다는

02:49.860 --> 02:51.090
뜻입니다.

02:51.090 --> 02:52.590
그다음 날은 1,000명

02:52.590 --> 02:55.260
그다음 날은 10,000명 그런 식으로요

02:55.260 --> 02:56.093
네 페이스북,

02:56.093 --> 02:58.800
구글 링크드인, 유니 같은 대기업을

02:58.800 --> 03:02.160
보면 수백만 명의 최종 사용자가 매일 플랫폼에

03:02.160 --> 03:04.710
접근하고 있고 클라우드 서비스의

03:04.710 --> 03:07.422
확장성에 기반해 확장할 수 있습니다

03:07.422 --> 03:09.510
로컬 데이터 센터를 설치하기

03:09.510 --> 03:10.710
위해 1만 달러짜리

03:10.710 --> 03:12.990
서버를 살 필요가 없어요 아마존의

03:12.990 --> 03:14.490
기능을 사용하면 되니까요

03:14.490 --> 03:16.650
필요할 때 아마존의 기능을 일부

03:16.650 --> 03:19.560
사용하면 되죠

03:19.560 --> 03:20.970
이제 확장성에 관해서는 두 가지

03:20.970 --> 03:22.650
방법으로 확장할 수 있습니다.

03:22.650 --> 03:25.560
하나는 수직 배율로 확장하는 겁니다

03:25.560 --> 03:27.090
이는 특정 서버나 노드에 더 많은

03:27.090 --> 03:29.010
리소스를 추가하는 것입니다.

03:29.010 --> 03:31.020
예를 들어 두 개의 가상 cpu를 가진

03:31.020 --> 03:32.970
클라우드 기반 서버를 사용한다면

03:32.970 --> 03:35.730
가상 cpu를 4개로 늘릴 수 있습니다

03:35.730 --> 03:37.170
이게 확장하는 겁니다

03:37.170 --> 03:38.610
더 많은 프로세서, 더 많은

03:38.610 --> 03:41.040
ram, 더 많은 스토리지, 더 많은 대역폭 등

03:41.040 --> 03:43.110
더 많은 리소스를 추가하게 됩니다.

03:43.110 --> 03:45.120
스케일 아웃도 가능합니다

03:45.120 --> 03:47.100
수평 배율이라고 하죠

03:47.100 --> 03:49.440
여기서는 여전히 더 작은 머신을 사용하지만

03:49.440 --> 03:50.280
로드 밸런서 뒤에서

03:50.280 --> 03:53.400
동시에 작동하는 머신을 더 많이 사용합니다.

03:53.400 --> 03:55.080
서버 하나로 부하를

03:55.080 --> 03:57.316
다 처리하는 대신 cpu와

03:57.316 --> 04:00.180
메모리를 늘려 상향 조정하는 대신

04:00.180 --> 04:02.520
서버 하나를 둘로 늘리거나

04:02.520 --> 04:05.970
둘에서 넷으로 또는 여덟으로요 부하 분산

04:05.970 --> 04:07.170
장치 뒤에 서버를

04:07.170 --> 04:09.840
추가해 추가 트래픽을 처리하는

04:09.840 --> 04:11.940
거죠

04:11.940 --> 04:13.710
이제 이는 빠른 탄력성(Rapid Elasticity)으로

04:13.710 --> 04:15.864
알려진 세 번째 영역으로 이동합니다.

04:15.864 --> 04:18.960
자 이제 빠른 탄력성에 관해 얘기할 땐 아주 빠르게

04:18.960 --> 04:20.160
확장하거나 축소할

04:20.160 --> 04:22.731
수 있다는 걸 의미합니다

04:22.731 --> 04:25.454
네 이게 가능해진 건 아마존, 구글, 그리고

04:25.454 --> 04:28.110
물리 서버에 많은 가상 컴퓨터와 자동화와

04:28.110 --> 04:29.970
오케스트레이션을 이용하기

04:29.970 --> 04:32.220
때문입니다 Microsoft를

04:32.220 --> 04:35.040
비롯한 여러 기업이 요구되는 대로 서비스를

04:35.040 --> 04:38.104
제공해 줍니다

04:38.104 --> 04:41.040
그래서 탄성이 아주 빨라지죠

04:41.040 --> 04:43.200
이렇게 생각합니다 빠른 탄력성이라는

04:43.200 --> 04:46.290
용어 혹은 일반적으로 수요 변화에 실시간으로

04:46.290 --> 04:48.785
대처하는 시스템의 능력이라고 생각하세요

04:48.785 --> 04:50.370
안 그러면

04:50.370 --> 04:51.410
디온트래닝에 있는 제 웹사이트를

04:51.410 --> 04:54.780
이용한 예로 돌아가보죠 com.com.

04:54.780 --> 04:56.490
지금 제 웹사이트를 확인하면 학생들이

04:56.490 --> 04:58.770
1,000명 정도 로그인 되어 있고 5분

04:58.770 --> 05:00.330
후에 확인해 보면 10,000명이

05:00.330 --> 05:03.774
로그인 되어 있습니다 제 시스템은 추가적인 클라우드 자원을

05:03.774 --> 05:07.230
돌리고 새로운 사용자들의 로드를 추가적인 서비스로 푸시하도록

05:07.230 --> 05:10.230
설계되어 있습니다 ,

05:10.230 --> 05:12.810
이것이 바로 빠른 탄력성입니다

05:12.810 --> 05:14.580
네 일반적으로 클라우드에서

05:14.580 --> 05:16.470
작업할 때 시스템을 제대로 설계했다면

05:16.470 --> 05:18.949
탄력성을 빠르게 갖추고 빠르게 확장할

05:18.949 --> 05:21.150
수 있어요 그리고 마찬가지로 수요가

05:21.150 --> 05:24.750
줄어들면 여분의 서버를 재빨리 제거하고 다시 줄일 수

05:24.750 --> 05:27.120
있죠 ?

05:27.120 --> 05:28.680
그렇게 해야 하는 이유는 추가적인

05:28.680 --> 05:31.166
서버가 돈을 더 들게 되는데 그걸 가질 만한 사용자가

05:31.166 --> 05:33.390
충분하지 않다면 그에 대한 비용을 지불해야

05:33.390 --> 05:34.500
하기 때문이죠 이것을

05:34.500 --> 05:37.410
배포해서 서비스 제공자에게 주면 다른 사람에게 서비스를

05:37.410 --> 05:40.140
빌려줄 수 있습니다.

05:40.140 --> 05:42.750
대신, 온프레미스 모델을 수행하는 경우 오늘 학생 수가

05:42.750 --> 05:45.000
1,000명이라고 가정해 보겠습니다.

05:45.000 --> 05:48.150
천 명이 되려면 웹 서버가 세 개는 필요하겠어요

05:48.150 --> 05:49.830
하지만 1만 명의 학생에게 가면

05:49.830 --> 05:51.956
15개의 웹 서버가 더 필요할 겁니다

05:51.956 --> 05:55.080
그러려면 서버를 15개 더 사야 해요

05:55.080 --> 05:55.950
나는 그것들을 쌓아야 할 것입니다.

05:55.950 --> 05:57.270
소프트웨어를 설치하고

05:57.270 --> 05:58.440
구성도 해야 해요

05:58.440 --> 05:59.580
이 모든 작업에는 시간이

05:59.580 --> 06:02.222
걸리므로 해당 수요를 충족시키기 위해 규모를 확장할

06:02.222 --> 06:04.980
수 있는 탄력성 조치가 그리 빠르지 않습니다.

06:04.980 --> 06:07.860
아주 느리게 성장하는 비즈니스 모델도 괜찮아요

06:07.860 --> 06:10.200
하지만 아주 빠른 콘텐츠를 다루거나

06:10.200 --> 06:12.171
소셜 미디어 플랫폼을 사용한다면

06:12.171 --> 06:14.370
여러분의 작품이 입소문이 나서 다들

06:14.370 --> 06:16.920
웹사이트로 가서 범람하기 시작해요 확장을

06:16.920 --> 06:19.950
신속히 할 능력이 없다면 입소문 사건으로 발생하는

06:19.950 --> 06:22.052
트래픽을 포착할 능력을 놓치게 될

06:22.052 --> 06:23.880
겁니다

06:23.880 --> 06:25.620
그래서 여러분은 신속하고 탄력적인 방식으로

06:25.620 --> 06:27.360
콘텐츠를 구축할 수 있기를 원하며, 이것이

06:27.360 --> 06:29.700
바로 클라우드를 통해 가능해진 것입니다.

06:29.700 --> 06:32.910
네 번째는 계량된 활용입니다

06:32.910 --> 06:33.810
이제 좀 전에 했던

06:33.810 --> 06:36.510
빠른 탄력성에 대한 얘기로 돌아가죠

06:36.510 --> 06:38.686
네 자 계량된 활용에 대해 이야기 할

06:38.686 --> 06:40.170
때는 사용당 유료 서비스에

06:40.170 --> 06:43.800
대해 이야기하는 것입니다. ? ? 네, 맞습니다.

06:43.800 --> 06:46.650
네 데이터베이스와 같은 계량 서비스를

06:46.650 --> 06:47.730
사용할 때 사용자

06:47.730 --> 06:49.170
수나 연결 수 저장된 데이터

06:49.170 --> 06:52.050
수에 따라 청구될 수 있습니다

06:52.050 --> 06:53.910
기본적으로 사용되는 서비스의

06:53.910 --> 06:56.910
실제 사용량에 기반하여 충전되는 것입니다

06:56.910 --> 06:59.262
이 작업을 2차 단위로 분 단위

06:59.262 --> 07:03.480
시간 단위, 일 단위 심지어는 월 단위로 합니다

07:03.480 --> 07:05.211
예를 들어, 저는 많은 백엔드

07:05.211 --> 07:08.153
자동화 및 기능에 AWS Lambda를 사용하고

07:08.153 --> 07:11.010
있으며 사용량에 따라 비용을 청구합니다.

07:11.010 --> 07:13.290
이제 내가 요청하는 백만 건마다 20센트가

07:13.290 --> 07:14.760
청구됩니다.

07:14.760 --> 07:16.200
이는 자동화를 완료하는

07:16.200 --> 07:17.880
매우 효율적인 방법입니다.

07:17.880 --> 07:20.092
비용이 매우 저렴하기 때문입니다.

07:20.092 --> 07:22.620
수백만 개의 요청을 할 수 있고

07:22.620 --> 07:24.960
비용은 몇 달러밖에 안 들죠 그게

07:24.960 --> 07:27.090
계량 서비스입니다

07:27.090 --> 07:28.334
네 이제 여러분이 보시게

07:28.334 --> 07:30.120
될 또 다른 건 가끔 계량된 서비스와

07:30.120 --> 07:33.000
측정된 서비스의 차이를 보시게 될 겁니다

07:33.000 --> 07:35.640
측정된 서비스 또는 측정된 서비스에 관해 이야기할

07:35.640 --> 07:37.470
때 실제로는 동일한 것에 대해 이야기하고

07:37.470 --> 07:38.700
있으며 이는 소비를 기준으로

07:38.700 --> 07:41.160
비용을 지불하는 능력입니다.

07:41.160 --> 07:42.840
그러나 여기에는 차이점이 있습니다.

07:42.840 --> 07:44.850
측정된 서비스를 사용하는 경우

07:44.850 --> 07:46.073
수행한 작업의 실제

07:46.073 --> 07:49.380
사용량을 기준으로 비용을 지불하게 됩니다.

07:49.380 --> 07:50.213
따라서 집의 수도

07:50.213 --> 07:52.500
요금이나 전기 요금에 대해 생각한다면.

07:52.500 --> 07:53.880
네 호스를 틀고 이번

07:53.880 --> 07:55.650
달에 수영장에 물을 채우면

07:55.650 --> 07:56.730
물을 훨씬 많이

07:56.730 --> 07:59.670
썼으니 수도세를 훨씬 더 내야 해요

07:59.670 --> 08:02.314
반대로 측정된 서비스를 다룰 때는

08:02.314 --> 08:04.950
휴대폰 요금제에 가깝습니다

08:04.950 --> 08:08.160
대부분의 경우 휴대폰 사용에 매달 일정량의 사용료를

08:08.160 --> 08:10.740
내야 합니다 문자 메시지 개수나 분량

08:10.740 --> 08:14.100
또는 데이터 사용이 허용되는 양이죠

08:14.100 --> 08:15.390
그리고 해당 한도에 도달하면

08:15.390 --> 08:17.790
서비스를 중단하고 다시 지불할 때까지 더 이상 서비스를

08:17.790 --> 08:19.440
제공하지 않습니다.

08:19.440 --> 08:21.300
네 그래서 계산된 서비스를 생각할

08:21.300 --> 08:23.310
때 선불로 일정량을 지불하고 있다고

08:23.310 --> 08:25.920
생각해 보세요 그걸 사용하든 안 하든 그 금액은

08:25.920 --> 08:27.660
이미 지불한 겁니다

08:27.660 --> 08:28.493
그러나 계량형 서비스를

08:28.493 --> 08:30.420
다룰 때는 사용한 정확한 금액에 대해 비용을 지불하게

08:30.420 --> 08:31.253
됩니다.

08:31.253 --> 08:33.480
이게 클라우드를 사용하는 장점 중 하나인데요

08:33.480 --> 08:35.527
대부분의 것이 계량된 기준으로 이뤄집니다

08:35.527 --> 08:37.883
사용량에 대한 돈만 지불하면 되죠

08:37.883 --> 08:41.160
다음으로 얘기할 것은 공유 리소스입니다

08:41.160 --> 08:43.740
자 이제 공유 리소스에 대해 얘기할 땐 비용을

08:43.740 --> 08:46.530
최소화할 수 있는 기능에 대해 얘기할 겁니다 우리

08:46.530 --> 08:48.330
가상 컴퓨터를 다른 사람의 서버에

08:48.330 --> 08:50.220
놓을 수 있으니까요

08:50.220 --> 08:51.930
아마존, Azure,

08:51.930 --> 08:54.238
구글 클라우드에서 저희가 사용하는

08:54.238 --> 08:56.022
서버들을 보면 그게 1만

08:56.022 --> 08:58.980
2만 3만 달러는 해요

08:58.980 --> 09:00.151
따라서 WordPress

09:00.151 --> 09:02.640
블로그를 호스팅하기 위해 그 중 하나를 구입해야 하는 경우 실제로는

09:02.640 --> 09:04.680
모든 용량을 사용하지 않는 것입니다. 왜냐하면 독자가

09:04.680 --> 09:06.420
몇 백 명만 있으면 그렇게 많은 로드를 사용하지

09:06.420 --> 09:08.100
않을 것이기 때문입니다.

09:08.100 --> 09:10.020
네 그래서 대신에 아주 비싼

09:10.020 --> 09:12.660
서버를 가져다가 작은 조각으로 잘라

09:12.660 --> 09:14.550
가상 머신에 제공하는 것이

09:14.550 --> 09:16.158
훨씬 더 말이 됩니다 다른

09:16.158 --> 09:18.450
사용자들에게 주는 거죠

09:18.450 --> 09:20.816
네 서버 하나에 워드프레스를 50,

09:20.816 --> 09:24.480
100개 호스트할 수 있어요 하나의 호스팅이 아니라요

09:24.480 --> 09:26.760
이것이 바로 공유 자원을 활용하는 아이디어입니다.

09:26.760 --> 09:28.330
네 공유 리소스라고 하면 클라우드

09:28.330 --> 09:30.697
공급자의 데이터 센터를 구성하기 위해 모든

09:30.697 --> 09:33.150
하드웨어를 합치는 것입니다

09:33.150 --> 09:35.215
그렇게 하면 개인이 전념하는

09:35.215 --> 09:37.987
게 아니라 모두 급격한 탄력성에 기반해

09:37.987 --> 09:41.220
사용할 수 있어요 왜냐하면 바라건대 바라건대

09:41.220 --> 09:42.690
여러분 회사에도 낮은

09:42.690 --> 09:44.970
수요가 있을 수 있고 그 반대도

09:44.970 --> 09:48.090
있을 수 있으니까요 ,

09:48.090 --> 09:50.280
그래서 각 회사에 전용 하드웨어

09:50.280 --> 09:51.480
리소스를 갖는 대신에

09:51.480 --> 09:54.009
리소스를 공유할 수 있습니다

09:54.009 --> 09:55.500
그리고 클라우드의

09:55.500 --> 09:58.710
마지막 특징은 파일 동기화 기능입니다.

09:58.710 --> 10:01.103
이제 클라우드 기반 리소스를 사용할 때의

10:01.103 --> 10:02.760
가장 큰 장점은 무언가를 한

10:02.760 --> 10:04.649
곳에 두었다가 구성 방법에 따라

10:04.649 --> 10:07.500
다른 위치로 퍼뜨릴 수 있다는 것입니다.

10:07.500 --> 10:09.420
예를 들어 저희 회사는 파일

10:09.420 --> 10:11.428
동기화에 많이 의존합니다

10:11.428 --> 10:14.249
직원 대부분이 원격 근무자거든요 사무실뿐

10:14.249 --> 10:17.640
아니라 전 세계에서 일하죠

10:17.640 --> 10:18.473
그래서 제가 지금 여기

10:18.473 --> 10:20.100
사무실에 앉아 이것을 녹음하고 있는

10:20.100 --> 10:22.830
동안, 제가 말하는 동안 여러분이 화면에 보고 있는 다양한 것들을

10:22.830 --> 10:24.690
만들 수 있도록 그래픽 디자이너에게 이 파일을

10:24.690 --> 10:27.060
넘겨줄 방법이 필요합니다. .

10:27.060 --> 10:28.260
그걸 다른 나라로 보낼

10:28.260 --> 10:31.320
거예요 제 비디오 편집기가 있는 곳으로요

10:31.320 --> 10:33.060
네 작업이 끝나면 제 사무실로

10:33.060 --> 10:34.410
다시 보내 품질 보증 검사를

10:34.410 --> 10:36.870
하는 거죠 그런 다음 다른 나라로 보내

10:36.870 --> 10:39.300
여러분이 보게 될 최종 사이트에 업로드하는

10:39.300 --> 10:41.040
겁니다

10:41.040 --> 10:43.779
그러니 이 비디오 한 편이 지금

10:43.779 --> 10:46.680
보시는 최종 결과물을 위해 너덧

10:46.680 --> 10:49.470
군데를 거쳐 간 겁니다

10:49.470 --> 10:50.303
네 파일 동기화의

10:50.303 --> 10:52.950
아이디어입니다 이걸 녹화할 때 클라우드 기반

10:52.950 --> 10:55.129
파일 서버에 녹화하거든요 , 제 팀의

10:55.129 --> 10:57.780
모두가 그 파일에 액세스할 수 있습니다 팀원들의

10:57.780 --> 11:00.360
모든 장치와 전 세계 모든 서버에 동기화된

11:00.360 --> 11:03.030
복사본이 있으니까요 그래서 액세스해 필요한

11:03.030 --> 11:05.430
작업을 할 수 있죠

11:05.430 --> 11:06.630
그렇게 하는 동안

11:06.630 --> 11:08.190
그 사람들 컴퓨터에 앉아만

11:08.190 --> 11:11.070
있는 게 아니라 우리 클라우드 서버 전체에

11:11.070 --> 11:13.710
걸쳐 동기화할 겁니다 레코딩과 게시

11:13.710 --> 11:15.510
사이의 모든 다른 사람들은

11:15.510 --> 11:16.920
아주 능률적인 방식으로

11:16.920 --> 11:20.730
모든 서버에 걸쳐 발생해야 합니다

11:20.730 --> 11:22.200
비즈니스 관점에서 클라우드를

11:22.200 --> 11:24.420
만들면 가장 큰 이점은 사무실에

11:24.420 --> 11:26.970
서버가 없다는 거죠

11:26.970 --> 11:28.201
이제는 보호되고,

11:28.201 --> 11:31.650
가용성이 높으며, 확장 가능하고, 높거나 낮은 수요

11:31.650 --> 11:32.980
기간의 수요에 탄력적으로

11:32.980 --> 11:34.617
대응할 수 있는 데이터 센터의

11:34.617 --> 11:37.740
클라우드에 있습니다.

11:37.740 --> 11:39.015
사용량만 지불하면

11:39.015 --> 11:41.177
됩니다 모르는 사람과도 자원을

11:41.177 --> 11:42.537
공유할 수 있죠 같은

11:42.537 --> 11:45.480
물리적 서버에 있으니까요

11:45.480 --> 11:46.820
네 네 크게

11:46.820 --> 11:49.110
이전을 했는지도

11:49.110 --> 11:53.740
이런 것들이고요