WEBVTT

00:00.120 --> 00:01.770
네 알겠습니다 일단 조직이 클라우드를

00:01.770 --> 00:04.200
사용하는 게 맞는 솔루션이라고 판단하면 현장에서

00:04.200 --> 00:06.350
호스트할 것인지 타사로부터 호스트형

00:06.350 --> 00:10.530
솔루션으로 계약할 것인지 결정합니다 ?????

00:10.530 --> 00:12.360
현장에서 솔루션을 호스팅할

00:12.360 --> 00:15.030
때 이건 온-프레미스라고 불립니다

00:15.030 --> 00:16.890
보안 측면에서 온-프레미스

00:16.890 --> 00:20.160
솔루션을 사용하는 건 좋지만 비용이 많이

00:20.160 --> 00:21.660
듭니다 팀 전체가 그

00:21.660 --> 00:24.480
솔루션을 지원해야 해요

00:24.480 --> 00:26.730
네 이제 이제 조직의 클라우드

00:26.730 --> 00:29.220
솔루션을 운영하기 위해 모든

00:29.220 --> 00:31.650
하드웨어와 소프트웨어 인력을

00:31.650 --> 00:34.260
확보해야 한다는 뜻이죠

00:34.260 --> 00:36.210
네 이 외에도 모든 장비를

00:36.210 --> 00:38.100
보관할 수 있는 데이터 센터

00:38.100 --> 00:39.480
시설이 필요합니다

00:39.480 --> 00:42.180
적절한 공간과 전력, 냉각이 가능해야

00:42.180 --> 00:43.950
하죠

00:43.950 --> 00:46.447
이러한 이유로 많은 기업들이 호스트형 솔루션을

00:46.447 --> 00:48.480
사용하기로 결정합니다

00:48.480 --> 00:49.531
호스트 환경에 있기

00:49.531 --> 00:52.110
때문입니다 타사 서비스 공급자는 클라우드 솔루션을

00:52.110 --> 00:53.040
관리하기 위해 필요한

00:53.040 --> 00:56.280
모든 하드웨어와 설비를 제공할 것입니다

00:56.280 --> 00:57.240
이것은 종종 다중

00:57.240 --> 01:00.360
테넌트 환경에서 이루어집니다 여러 조직이 자신들의

01:00.360 --> 01:01.920
클라우드 솔루션을 단일

01:01.920 --> 01:04.860
타사 공급자의 시설에 호스팅하는 거죠

01:04.860 --> 01:07.080
예를 들어 아마존과 Microsoft,

01:07.080 --> 01:08.929
Google은 기업이 활용할 수

01:08.929 --> 01:11.250
있는 호스트형 솔루션을 제공합니다

01:11.250 --> 01:15.240
아마존 웹 서비스, 즉 aws의 예를 들어보죠

01:15.240 --> 01:17.200
멀티포인트 솔루션은 같은

01:17.200 --> 01:18.902
물리적 시설에 있는 동일한

01:18.902 --> 01:21.821
물리적 하드웨어를 활용해 다수의 다양한

01:21.821 --> 01:24.210
조직을 지원합니다

01:24.210 --> 01:26.340
물론 논리적 분리입니다 호스트

01:26.340 --> 01:28.646
플랫폼 내의 다른 조직에 노출되지

01:28.646 --> 01:31.740
않고 데이터를 안전하게 지키기 위해서죠

01:31.740 --> 01:33.810
하지만 만약 당신이 엄격한 기밀을

01:33.810 --> 01:35.610
유지하고 싶은 정보를 가지고

01:35.610 --> 01:38.520
있다면 서버에 대한 물리적, 논리적 접근을 컨트롤할

01:38.520 --> 01:40.200
수 있는 온-프레미스 솔루션을

01:40.200 --> 01:42.750
사용하는 것이 좋습니다.

01:42.750 --> 01:45.690
다중 테넌트 솔루션을 사용할 경우 조직의

01:45.690 --> 01:48.390
잔여 데이터가 다른 테넌트에게 노출될

01:48.390 --> 01:51.216
수 있습니다 서버 탄력성이 위아래로 확장돼

01:51.216 --> 01:54.600
서버 용량에 대한 프로비전과 비프로비전 하니까요

01:54.600 --> 01:56.465
공유 리소스를 모두와 함께

01:56.465 --> 01:58.500
이용하니까요 ,

01:58.500 --> 02:00.600
여러분이 호스팅 공급자를 사용하기로 결정했다면

02:00.600 --> 02:02.880
그들의 인증과 권한 부여 메커니즘을 이해하는

02:02.880 --> 02:04.662
건 정말 중요합니다 여러분의 요구

02:04.662 --> 02:06.330
사항을 충족시키기 위해 적절한 보호를

02:06.330 --> 02:08.580
받도록 하기 위해서요

02:08.580 --> 02:10.920
그리고 또 여분과 결함 내구성 조치에

02:10.920 --> 02:12.486
대해서도 알아봐야 합니다

02:12.486 --> 02:15.510
그래야 요구 수준에 부합하니까요

02:15.510 --> 02:18.630
호스트된 공급자의 또 다른 걱정은 위치입니다

02:18.630 --> 02:20.305
데이터는 정확히 어디에

02:20.305 --> 02:21.630
저장되나요?

02:21.630 --> 02:22.980
그 장소에 근거해서 어떤

02:22.980 --> 02:25.920
법이 조직과 데이터에 영향을 미칠까요?

02:25.920 --> 02:27.270
네 조직의 hosted

02:27.270 --> 02:28.855
서비스 공급자를 선택할

02:28.855 --> 02:31.170
때 이해해야 할 것들이에요.

02:31.170 --> 02:32.430
이제 온-프레미스 혹은

02:32.430 --> 02:35.105
호스트 서비스 공급자를 사용할 것인지 말 것인지 결정을

02:35.105 --> 02:37.050
내렸는데요 마지막 결정은 어떤 유형의

02:37.050 --> 02:39.870
서비스를 구매하기를 원하는지로 회전합니다

02:39.870 --> 02:42.240
이제 세 가지 클라우드 서비스 모델에서 선택할

02:42.240 --> 02:43.260
수 있습니다.

02:43.260 --> 02:44.760
서비스로서의 소프트웨어,

02:44.760 --> 02:47.790
SaaS 서비스로서의 플랫폼, PaaS 서비스로서의

02:47.790 --> 02:50.490
인프라 IaaS로서의 인프라입니다

02:50.490 --> 02:52.350
네 이제 서비스로서의 소프트웨어

02:52.350 --> 02:54.022
내에서는 서비스 제공자는 조직에

02:54.022 --> 02:56.100
완전한 솔루션을 줍니다 ? 네

02:56.100 --> 02:58.290
하드웨어도 포함합니다 네트워킹

02:58.290 --> 03:00.870
저장소 서버 및 가상화 또한 운영 체제 미들웨어

03:00.870 --> 03:03.720
런타임 데이터 프로세싱 및 최종 사용자에게

03:03.720 --> 03:05.850
서비스가 전달되기 위해 필요한 응용

03:05.850 --> 03:07.020
프로그램 또는 소프트웨어

03:07.020 --> 03:09.420
등이죠 거나요

03:09.420 --> 03:12.780
예를 들어 여러분 조직이 Microsoft에서 Office

03:12.780 --> 03:16.290
365를 사용하거나 Docs, Google 워크스페이스에서

03:16.290 --> 03:18.990
시트를 사용한다면 서비스 솔루션으로서 소프트웨어로

03:18.990 --> 03:21.105
간주되고 사용자가 자신의 이메일, 문서

03:21.105 --> 03:23.160
스프레드시트 등에 직접적으로 접속하게

03:23.160 --> 03:26.280
해줍니다 웹 브라우저에서요

03:26.280 --> 03:27.380
서비스 소프트웨어의 또

03:27.380 --> 03:30.900
다른 좋은 예는 터보택스와 QuickBooks Online입니다

03:30.900 --> 03:33.185
세금 정리와 회계 소프트웨어를 제공해

03:33.185 --> 03:36.016
웹 브라우저만으로 온라인에 접속할 수 있습니다

03:36.016 --> 03:38.490
여러분을 대신해 모든 소프트웨어와 하드웨어

03:38.490 --> 03:41.520
데이터 저장소 요구 사항을 처리할 겁니다

03:41.520 --> 03:42.600
네 가끔은 여러분만의

03:42.600 --> 03:44.760
특정 서비스 욕구를 충족시키기 위해 사용자

03:44.760 --> 03:47.850
지정 응용 프로그램이나 소프트웨어를 만들어야 할 겁니다

03:47.850 --> 03:50.370
이 경우 하드웨어를 받으려면 서비스

03:50.370 --> 03:51.630
제공자만 있으면

03:51.630 --> 03:53.430
됩니다 네트워킹 저장소

03:53.430 --> 03:55.170
서버와 가상화 운영 체제

03:55.170 --> 03:56.640
미들웨어 런타임 응용

03:56.640 --> 03:58.920
프로그램이요

03:58.920 --> 04:01.232
하지만 서비스 솔루션으로서의 소프트웨어와

04:01.232 --> 04:02.670
달리 여러분은 실제 응용 프로그램

04:02.670 --> 04:04.800
코드를 만들고 클라이언트와 서버 간의

04:04.800 --> 04:06.300
데이터 프로세싱을 처리하는

04:06.300 --> 04:08.315
책임을 져야 하죠

04:08.315 --> 04:10.260
네 이제 플랫폼을 서비스로

04:10.260 --> 04:11.280
이용하면 클라우드

04:11.280 --> 04:13.890
이용의 장점을 얻게 됩니다 공유 리소스

04:13.890 --> 04:17.820
계량된 활용 급격한 탄력성 고가용성과 파일 동기화를

04:17.820 --> 04:19.410
포함하죠

04:19.410 --> 04:21.377
하지만 여러분의 비즈니스에

04:21.377 --> 04:24.690
맞게 개발을 사용자 정의할 수도 있습니다

04:24.690 --> 04:25.770
이 모델에서는

04:25.770 --> 04:28.230
타사 벤더는 특정 서비스가 운용되는

04:28.230 --> 04:29.063
데 필요한 하드웨어와

04:29.063 --> 04:32.910
운영 체제 소프트웨어를 제공하지만 최종 사용자에

04:32.910 --> 04:34.710
가까운 코드나 응용 프로그램은

04:34.710 --> 04:37.830
주지 않습니다

04:37.830 --> 04:38.790
예를 들어 여러분의

04:38.790 --> 04:41.115
회사가 새로운 웹 응용 프로그램을 개발한다면

04:41.115 --> 04:43.500
타사 클라우드 제공자가 제공하는 개발 플랫폼을

04:43.500 --> 04:45.510
가질 수도 있습니다

04:45.510 --> 04:48.225
제 회사에서 일합니다 디온 트레이닝 이걸 촬영하면서요

04:48.225 --> 04:49.740
사실 저희는 근본적인 학습

04:49.740 --> 04:51.870
관리 시스템을 개발하는 과정에 있습니다

04:51.870 --> 04:54.295
하지만 모든 하드웨어 네트워킹이나 저장소,

04:54.295 --> 04:59.220
운영 체제 계층은 다루고 싶지 않습니다 맞아요,

04:59.220 --> 05:01.595
아마존 웹 서비스를 통한 솔루션으로

05:01.595 --> 05:05.850
플랫폼을 택했습니다 기술 스택의 데이터베이스 하향에

05:05.850 --> 05:08.370
있는 모든 걸 처리하기 때문이죠 저희

05:08.370 --> 05:10.290
팀과 저는 최종 사용자와

05:10.290 --> 05:12.094
학생들이 교류하고 수업을

05:12.094 --> 05:18.240
듣는 동안 데이터를 처리하는 소프트웨어 코드만 책임집니다

05:18.240 --> 05:20.070
네 이건 서비스로서의 플랫폼입니다

05:20.070 --> 05:22.680
Amazon에서 서버를 제공하거든요

05:22.680 --> 05:24.300
운영 체제 구성 데이터베이스도요

05:24.300 --> 05:25.830
거기에 우리가 원하는 건

05:25.830 --> 05:27.657
뭐든 더할 수 있죠 최종 사용자,

05:27.657 --> 05:30.065
즉 학생에게 최종 응용 프로그램이나 소프트웨어를

05:30.065 --> 05:33.661
제공하기 위해서요

05:33.661 --> 05:35.970
네 우리가 다룰 마지막 클라우드 서비스

05:35.970 --> 05:37.830
모델은 iaaS로 알려진 겁니다

05:37.830 --> 05:40.110
서비스로서의 인프라죠

05:40.110 --> 05:42.150
자 서비스로서의 인프라는 필요할

05:42.150 --> 05:44.678
때 서버나 부하 분산 장치 저장소 영역 네트워크

05:44.678 --> 05:48.690
구성 요소 같은 it 리소스를 프로비전하는 방법입니다

05:48.690 --> 05:50.065
인프라를 이용할 수

05:50.065 --> 05:52.620
있습니다 추가 자원 동적 할당의 장점을

05:52.620 --> 05:55.590
얻게 될 텐데요 탄력성이라고 하죠

05:55.590 --> 05:56.970
하지만 하드웨어를 직접

05:56.970 --> 05:58.680
구입하고 운영하는 장기적인

05:58.680 --> 06:01.302
책임감을 감당하지 않아도 되죠

06:01.302 --> 06:02.610
예를 들어 여러분 회사의

06:02.610 --> 06:05.013
웹사이트를 호스트하기 위해 새 클라우드

06:05.013 --> 06:07.380
기반 웹 서버를 계약할 수도 있습니다

06:07.380 --> 06:10.620
아마존 웹 서비스나 aws를 이용한다면 이것을 ec2라고

06:10.620 --> 06:12.360
부를 것입니다 탄성 있는 클라우드

06:12.360 --> 06:14.460
컴퓨팅입니다 ec2 인스턴스를

06:14.460 --> 06:15.870
위해 알맞은 양의 리소스를

06:15.870 --> 06:18.420
선택할 수 있습니다 ?

06:18.420 --> 06:19.800
예를 들어 4개의 cpu와

06:19.800 --> 06:22.170
16기가바이트 메모리 500기가바이트

06:22.170 --> 06:24.900
스토리지를 원한다고 해보죠

06:24.900 --> 06:27.750
그러면 aws가 그 하드웨어 리소스를 사용자에게

06:27.750 --> 06:28.710
할당해 운영 체제,

06:28.710 --> 06:30.510
중간웨어 그리고 그 리소스에

06:30.510 --> 06:33.090
런타임을 설치할 수 있죠

06:33.090 --> 06:36.840
하지만 가끔은 그 경계선이 좀 흐려질 수 있어요

06:36.840 --> 06:38.512
네 공식 교과서와 문서에

06:38.512 --> 06:42.090
따르면 서비스로서의 인프라는 하드웨어에 초점을

06:42.090 --> 06:44.880
맞춥니다 가상 컴퓨터와 하드웨어의 저장소

06:44.880 --> 06:48.030
네트워킹 부분을 포함해서요

06:48.030 --> 06:49.380
그렇습니다 그래서 하지만

06:49.380 --> 06:52.290
아마존 같은 공급자 대부분은 Microsoft Azure와

06:52.290 --> 06:55.680
구글 클라우드는 컴퓨팅 인스턴스에 설치하고 싶은 운영 체제를

06:55.680 --> 06:57.780
선택하게 해줍니다 여러분이 원하는 리소스를

06:57.780 --> 07:01.530
선택할 때요 그럼 자원을 할당해줍니다

07:01.530 --> 07:02.490
가령. 아마존의

07:02.490 --> 07:05.730
EC2 인스턴스는 예를 들어 이건 여러분의 필요를

07:05.730 --> 07:08.790
완전히 충족시키기 위해 커스터마이징 될 준비가

07:08.790 --> 07:11.061
된 기본 Linux 운영 체제를 포함하고

07:11.061 --> 07:14.370
있습니다 안 됩니다,

07:14.370 --> 07:16.470
네 이 얘길 하는 이유는 대부분

07:16.470 --> 07:18.570
하드웨어인 걸 다룰 때 운영 체제가

07:18.570 --> 07:20.850
설치돼 있으니까요 시험의 서비스로

07:20.850 --> 07:24.243
그걸 생각하지 않을 거예요

07:24.243 --> 07:27.060
대신 서비스로서 인프라를 선택할

07:27.060 --> 07:28.004
수 있어요

07:28.004 --> 07:30.690
이제 서비스 레벨로서 플랫폼으로 갑니다

07:30.690 --> 07:31.730
미들웨어 전부와

07:31.730 --> 07:34.170
런타임도 포함해야 해요

07:34.170 --> 07:36.420
데이터베이스 기능과 Apache나

07:36.420 --> 07:38.370
NGINX 같은 웹 서버도 포함합니다

07:38.370 --> 07:40.703
다른 서버 소프트웨어와 미들웨어도요

07:40.703 --> 07:43.980
그런 서비스를 제공하려면 필요하죠

07:43.980 --> 07:46.260
이제 시험을 보죠 서비스로서의 인프라나

07:46.260 --> 07:47.490
서비스로서의 소프트웨어일

07:47.490 --> 07:49.830
땐 꽤 명확하지만 서비스로서의 플랫폼은

07:49.830 --> 07:53.340
좀 까다로울 수 있어요

07:53.340 --> 07:55.830
시험에 사용해야 할 힌트를

07:55.830 --> 07:57.503
약간 드릴게요

07:57.503 --> 08:00.540
네 서비스로서의 인프라 그 이상을 본다면 플랫폼을

08:00.540 --> 08:03.030
서비스로서의 해답으로 선택하는 게

08:03.030 --> 08:04.920
좋을 겁니다 ,

08:04.920 --> 08:08.100
네 플랫폼을 서비스로 선택하겠죠 스펙트럼의

08:08.100 --> 08:10.800
양 끝이 있으니까요 서비스로서 인프라가

08:10.800 --> 08:14.580
왼쪽에 있고 서비스로서 소프트웨어가 오른쪽에

08:14.580 --> 08:17.010
있고 서비스로서 플랫폼은 중간

08:17.010 --> 08:20.400
어디쯤이에요 ?

08:20.400 --> 08:22.980
네 그래서 요약하자면 서비스로서의 인프라

08:22.980 --> 08:25.380
서버 실행에 필요한 모든 걸 제공한다는

08:25.380 --> 08:26.580
걸 기억하세요

08:26.580 --> 08:28.652
여기에 포함됩니다 전원 공간

08:28.652 --> 08:31.560
냉각, 네트워크 방화벽 물리적 서버,

08:31.560 --> 08:33.377
가상화 계층과 운영 체제도

08:33.377 --> 08:34.817
포함됩니다

08:34.817 --> 08:37.380
자 이제 서비스로서의 플랫폼을 운영체제에

08:37.380 --> 08:39.300
추가할 겁니다 인프라 소프트웨어라고

08:39.300 --> 08:41.730
부르고 싶네요 ,

08:41.730 --> 08:43.673
이 인프라 소프트웨어는 미들웨어와

08:43.673 --> 08:45.600
런타임 환경이죠

08:45.600 --> 08:47.070
그 말은 Apache 웹 서버

08:47.070 --> 08:50.040
같은 것에 관해 얘기하고 있다는 거죠 MySQL 데이터베이스

08:50.040 --> 08:52.122
프로그래밍 언어 같은 거요

08:52.122 --> 08:54.510
네 이제 서비스로서의 소프트웨어를

08:54.510 --> 08:56.988
다룰 때는 호스트 응용 프로그램을

08:56.988 --> 08:59.160
다루는데 인프라나 플랫폼 부분

08:59.160 --> 09:01.530
위에 추가된 것들이죠 ?

09:01.530 --> 09:04.620
네 그래서 서비스용 소프트웨어는 서비스용

09:04.620 --> 09:06.420
플랫폼이나 서비스용 인프라보다

09:06.420 --> 09:09.240
엔드 유저에 훨씬 가깝습니다

09:09.240 --> 09:12.000
네 그래서 it 전문가로서 조직에 어떤

09:12.000 --> 09:13.530
유형의 서비스가 적합한지

09:13.530 --> 09:14.967
결정하는 건 정말 중요합니다

09:14.967 --> 09:17.790
요구 사항에 근거해서요

09:17.790 --> 09:19.260
이번 수업에서 다룬 내용이었어요

09:19.260 --> 09:20.910
서비스로서의 소프트웨어 서비스로서의

09:20.910 --> 09:23.660
플랫폼 서비스로서의 인프라를 다뤘죠
