아마존 클라우드 AWS Essential 2강 클라우드 컨셉 > AWS 클라우드

 

이번 차 시에서는 여러분들이 저번 차 시에서 배웠던 퀘 아저 컴퓨팅의
이해를 바탕으로 컨셉에 대해서 이해를 하실 수 있습니다.
그리고 클라우드 컨셉 중에서 네 가지의 컨셉 있는데 첫 번째로 확장성과
탄력성을 가진 설계 컨셉을 확인을 하실수가 있습니다.
마지막으로 클라우드 환경에서 다양한 제약사항이 있는데 제약사 1과 그리고
가상 관리자의 대해서 이해를 하실 수가 있습니다.
4 1장 확장성 있는 설계에 대해서 알아보도록 하겠습니다.
클라우드는 확장성에 개념을 가지고 디자인이 되어 있으며 특히 it 자원들
서버 스토리지 가상화돼요.
디자인이 되어 있으며 이런 것들을 바탕으로 이러한 개념 특징을 바탕으로
확장성 있는 서비스 설계를 가능하게 합니다.
여러분들이 어플리케이션을 구성을 하실때 뭐 웹

어디 b 기본적으로 뭐 3t 어 구조로 설계를 하실 수가 있는데요 이
각각의 컴포넌트 별로 여러분들이 확장성 있는 설계를 가져가실 수 있다
라고 볼 수 있습니다.
하지만 이런 것들을 가져가기 위해서 얘들 까네 연관관계가 있을 거고요
병목이 되는 부분이 존재를 할 수가 있습니다.
그래서 여러분들은 서비스 레벨에서 병 목과 획일적인 구성요소들을 확인해서
효율적으로 서비스를 설계를 하셔야 됩니다.
이렇게 효율적으로 서비스를 설계를 하셨을때 클라우드 이점을 충분히
활용하실 수가 있고요
그러다 보면 은 확장성 있는 설계를 가져가실 수가 있습니다.
뭐 간단하게 확장성 있는 어플리케이션의 특징에 대해서 5가지 정도
알아보도록 하겠습니다.
확장성 있는 어플리케이션 이란 뭐 저희가 쉽게 볼수 있는 이런 확장
가능하다 라는 개념이 구요
첫번째로 리 소스 증가에 필요한 성능의 증가
여러분들이 확장성 있으려면 사실은 성능이 필요한 이 확장을 하시는 거구요
그러다 보면 은 필요한 확장에 따라서 리소스의 증가도 필요합니다.
하지만 이 소스 증가가 대 떠 라도 성능이 증가하지 않다면 확장성 있는
구조라고 볼 수가 없구요 그래서 가장 기본적인 이 소스 증가에 필요한
성능 의 증가를 가져오시는 특징을
여러분들이 설계를 하셔야 됩니다. 맴 두번째 회복력 이라고 말씀 드리는건
확장성이 락 일맥상통하는 용어라고 볼 수가 있는데요
회원 0 이라고 했을 때는 이 시스템에 얼마나 탄력적으로 이 써비스
트래픽을 받고 쭈리 고 할 수가 있느냐 이런 거라고 볼 수 있습니다.
그래서 회복력이 라는 것은 확장성과 동일한 개념이 있구요.
그래서 서비스 트래픽이 급속도로 들어왔을 때 이 탄력적으로 서비스 it
자원들 서버 스토리지 네트워크 를 늘리고 줄이고 하는 회복력을 가져야
된다 라고 볼 수 있습니다.
세번째 분산된 시스템의 관리 능력
아까 말씀드렸듯이 여러분들이 스위티 어 왜 마우스 db 의 구조로 설계를
하시더라도 그 집단에서는 분산된 시스템이 까 데이터베이스가 뭐 분산 되서
2대로 만들어질 수가 있고 세대로 만들어질 수도 있고 혹은 와 스가
2대로 만들어질 수도 있고 세대로 만들어질 수가 있는데 이런 시스템 들을
관리할 수 있는 능력 분산된 시스템 들을 관리할 수 있는 능력을 가져
오셨을때 확장성 있는 어플리케이션을 특징을 가질 수 있다라고 볼 수
있습니다.
그다음 효율적 인 운영방법
실제로 확장성을 가져오기 위해서는 여러분들이 모니터링 이라던가 어떤 특정
임계 값을 설정을 하셔야 됩니다.
그렇게 설정을 하기 위해서는 당연히 운영 에서도 효율적으로 해야 되는
거구요
예를 들면 은 서버 에 자원이 있는데 여기 c pou cg 가 케 치솟고
있다
모 90% 로 지속 그 있다 라고 했을 때는 이 cpu 자원이 90% 를
치는거 를 모니터링 하셔야 되구요.
모니터링에 맞춰서 서비스를
회복력을 가질 수 있게끔 확장성이 있게끔 설계를 하셔야 됩니다.
이렇게 모니터링 하거나 관리하는 것들을 효율적으로 여러분이 운영을
하셔야지 확장성 있는 어플리케이션이 특징을 가져 올수가 있습니다.
마지막으로 이제 비용의 효율적 인 관리 서비스가 확장 수 있게 늘어남에
따라서 비용 구조도 같이 늘어날 수밖에 없습니다.
저희가 클라우드의 특성상 사용한 만큼 지불한다.는 구조이기 때문에
여러분들이 자원이 늘어남에 따라서 비용도 같이 증가가 되게 되구요.
하지만 서버가 늘어나는데
7 제로 사용량은 60% 다
라고 했을 때 여기서 서비스 트래픽이 들어오고 사용자들이 서비스의 접근을
하면서 트래픽이 드러나는데 여기에 대해서 이거를 늘릴 거냐 혹은 안 들릴
거냐
당연히 이제 늘려야 되는 게 확장성 있는 설계를 하셔야 되는 거구요
하지만 이 늘리고 난 다음에 이거 를 서비스에 대해서 줄일 때
에 대해서도 관리를 해주셔야 됩니다.
그래야지 비용을 효율적으로 여러분들이 진짜 필요할 때 필요한 만큼 쓸수가
있다라고 보실 수가 있을 것 같습니다.
뭐 간단하게 확장성이 있는 설계를 it 환경에서 는 어떠한 방식으로
가져가는 야 에 대해서 말씀드리도록 하겠습니다.
첫번째로 말씀드리는 것은 여러분들이 흔히 볼 수 있는지 수직적인 확장 에
개념이라고 볼 수 있습니다.
수직적인 확장 이라는 것은 아내에게 서버 가
이코 사기가 에 스펙을 가진 서버라고 봤을 때 트래픽이 들어오고 cpu
cg 가 모 70% 이상 즈 치고 있다 라고 했을 때 우리가 이 시스템
자체를 수직적으로
4 코에 8개가 혹은 더 높은 사이즈로 증가시키는 작업이라고 볼 수가
있습니다. 그럴 기회가 스킬 업 이라고 하는 거구요
그래서 여러분들이 집에 가지고 있는 데스크탑 이라던가 혹은 노트북에서
서버를
그 메모리를 들린다 거나 cpu 를 늘린다고 했을 때 업그레이드를 한다.
고 표현하는 것과 동일한 방식이라고 보시면 됩니다.
당연히 올린 것도 있었고요 여기서 서버에 cpu uc 지온군 네트워크
cg 에 맞춰 스켈 다운도 가능합니다.
뭐 흔히 데스크탑 환경에서는 스킬 다운을 하지는 보통 않지만 서버
환경에서는 스케일 업 다운을 추행을 하게 됩니다.
이렇게 해서 it 자원들을 효과적으로 여러분들이 관리를 하셔야 되는
거구요
그리고 두번째 방법이
스킬 아웃 인과 같은 수평적인 확장 입니다.
스케일 아웃이 라고 했을 때는 병렬적으로 확장을 한다.
서버 가 한대가 있었구요
체 피기 들어와서 cpu 씨가 높아지고 있습니다.
이럴 경우에 아까 전 챕터에서 말씀드렸던 것처럼 스케일 업 을 해서
업그레이드를 하는 구조로 가져가실 수가 있는데 이럴 경우는 여러분들이
서버 르 지 스탑 시키고 자원을 들리고 다시 시작 을 시켜야 되기 때문에
서비스의 다운 타임이 불가피하게 필요합니다.
이럴 경우 사실 서비스 다운타임 이 혹은 그리고 스킬들 계속 업 할 때
마다 이런 구조 그리고 다운 타임을 가져갈 수밖에 없기 때문에 실제로
클라우드 환경 그리고 현재 웹 스케일에 환경에서는 스케일 아웃을 권장을
하고 있습니다.
그래서 병력 쩍 으로 서버 한대 있는것을 세대를 눌려서 300% 에
용량을 확보를 할 수가 있습니다. 300% 의 용량을 확보를 하고 이거에
대해서 이유 cg 가 뭐 효율적으로 쓰이고 있지 않다 라고 했을 때는
스케일이 늘 통해서 또한 데 혹은 두 대로 다시 스케일이 인해서
수평적으로 줄여주는 역할을 수행 을 하셔야 됩니다.
이렇게 하셔야지 여러분들이 이후 해 비용 효율성을 가져올 수가 있습니다.
이번 장에서는 탄력성 에 대한 이해를 알아보도록 하겠습니다.
우선 탄력성 이란 클라우드 의 속성 중에서 가장 대표적인 속성 중에
하나이구요
간단하게 말씀드리면 최소한의 마찰로 리소스를 스켈링 가능하게 하는
특징이다 라고 말씀드릴 수가 있습니다.
최소한의 마찰이 라고 했을 때는 뭐
특히 it 인프라 가 늘어 났을 때 예를 들면 은 오이 서버와 이
서버간의 연동 관계라든가 혹은 뭐 이 웹과 데이터베이스 연동 관계가
밀접하게 연관이 돼 있는데 이런 것들을 최소화 시키면서 이 소스를
스케일링 가능하게 하는 개념이라고
이해하실 수 있습니다. 그래서 여러분들이 서비스를 설계를 할 때 특히
어플리케이션 구조에서 클라우드의 이점을 충분히 활용을 하셔야 되구요.
그 활용을 하는 것 중에서 탄력성 에 대한 개념을 가지고 설계를 하셔야
됩니다.
예를 들어서 여러분들이 웹과 db 와 왔어 를 설계한다. 고 했을 때
서로간의 탄력성을 가질 수 있게끔 나중에 이게 확장이 됐을 때 첫 장에서
말씀드렸던 확장성을 가져갈 수 있게끔 여러분들이 그 서비스에 대한 결합
이라던가 이런 것들을 조금 더 탄력적으로 가져가셔야 된다는 말씀 이구요
그래서 탄력성이 라는 것은 이런 거를 바탕으로 위 소스가 이제 스켈링
된다고 보실 수가 있을 것 같습니다. 그래서 특히 이제 클라우드 환경과
전통적인 환경에서 다른 점은 이런 탄력성이 가장 대표적이라고 볼 수가
있는데 클라우드 환경에서 전 특정의 환경보다 좀 더 다르게 하기 위해서
집 간소화 된 시스템의 설계
아까 말씀드렸던 뭐 서로 간의 연관관계를 조금 더 완화를 시킨다 거나
그리고 프로세스 상으로
기존의 전통적인 방식에서 는 실제 이런 탄력성 홍은 확장성에 대한
프로세스 자체가 없었는데 이런 것들을 클라우드 환경에서 조금 잘 활용할
수가 있도록 프로세스의 상으로 관점의 변화가 필요합니다.
그리고 마지막으로 리 소스 서비스에 맞게 즉각적 눌리고 쪼일 수 있는
클라우드 특성 온 디맨드 1 특성이라고 첫째 찰스 에서 말씀드렸는데요
그럼 온 디맨드 1 특성을 가지고
1 특성을 가지고 프로세스를 자동화 시키고
유틸 ij 션을 높이는 작업을 활용을 하셔야 됩니다.
뭐 간단하게 기존 it 시스템
전통적인 방식에서 탄력적인 지모 탔던 구조에 대해서 설명을 드리도록
하겠습니다.
실제로 사용량 까 여러분들이 서비스를 오픈하고 서비스를 고객들에게
제공하고 고객들이 이 서비스를 활용했을 때 실제로 트래픽의 흐름을 이렇게
우리가 예상하지 못하는 트래픽이 흐름이 나타날 수가 있고요 그리고 우리가
예상을 하지 못하는 트래픽의 따운 이 발생할 수도 있으니까 서비스
트래픽이 낮아질 수 있는 거구요
또 다시 올라갈 수 있는 거고요 이런 것들을 예상을 하기는 매우 어려운
환경인 거구요
이거 에 맞춰서 사실은 it 인프라 자원 도 같이 늘어나는 구조입니다.
그래서 서비스 트래픽이 늘어난다고 가정을 하고 실제로 늘어났을 때 it
자원 역시 서버와 스토리지와 네트워크 장비를 구매해서 it 리소스를 높게
가져가고 요
그 다음에 또 유지를 하다가 또 서비스 트래픽이 드러나는 부분이 발견이
됐을 때 it 인프라 차원이 또 추가적으로 증설이 된다 라고 보시면
됩니다.
허나 이런 구조 일 경우에는 이런 부분
에서는 서비스 트래픽이 실제 저희가 서비스를 제공하는 it 인프라 보다
훨씬 더 많기 때문에
품질의 저하가 발생할 수밖에 없고요 이거는 고객들의 이탈로 발생이 이어질
수가 있습니다.
혹은
인프라 사원이 많을 경우 서비스의 트래픽이 많지 않는 구조에서 저희가
예상하지 못했던 서비스 트래픽의 땅 운
이 발생을 하며 는 it 인프라 자원은 뭐 어쩔 수 없이 유틸 에이전시에
낮아질 수밖에 없습니다.
그러면 이 남는 공간을 사실은 뭐 이걸 가상화를 통해서 뭐 다른 리소스에
할 땅은 하거나 혹은 그렇게 활용을 하기에는 조금 어려운 9종 거구요
전통적인 방식에서는 그래서 용량이 낭비될 수 밖에 없다라고 보실 수
있습니다.
그러면은 지금 클라우드 방식에서는 어떻게 탄력적인 구조로 가져가면서 이런
비용에 대한 절감 혹은 서비스 품질을 안정적으로 가져갈 수 있냐 라고
설명을 드리도록 하겠습니다.
클라우드 환경에서 동일한 서비스 트래픽이 발생합니다.
써비스 트래픽이 늘어나다 가 또 갑자기 또 급속도로 늘어나고 요 이
급속도로 늘어 갖던 트래픽이 또 다운이 될 수가 있구요.
그게 어느 좀 유지가 될 수도 있구요. 이렇게 서비스 트래픽이 저희가
예상하지 못한 형태로 흐를 수밖에 없는데 이런 환경에서 클라우드 같은
경우는
확장성 그리고 탄력성 에 대한 개념을 바탕으로 it 인프라 역시 처음에
설계 됐던 it 인프라 자원 2
이정도 이구요 써비스 트래픽의 맞춰서 같이 드러내는 구조라고 보시면
됩니다.
실제로 써비스 트래픽이 늘어날 고 나서 또 따운 이 될 경우 윈도 rt
리 소스 역시도 skm 아까 말씀드렸던 스케일이 민아 다운을 통해 가지고
it 인프라 자원을 탄력적으로 유지를 할 수 있습니다.
그래서 실제로 이제 이런 써비스 트래픽이 올라가는 부분에서 it 인프라
자원 더 스킬 아웃 혹은 업이 된다 라고 보시면 됩니다.
그래서 클라우드 방식에서 이렇게 탄력적으로 구조를 가져갈 수 있습니다.
4 3장에서는 제약사항 에 대한 극복 방법에 대해서 알아보도록 하겠습니다.
실제로 이제 클라우드 환경에서는 뭐 다양한 인프라 들 그리고 클라우드
시스템에
뭐 커스터마이징이 좀 불과한 부분이 있어서 시스템의 요구 사항들이
클라우드에서 충분히 제공되는지 여러분들이 요구사항을 명확하게 파악을
하셔야 됩니다.
그리고 클라우드 환경에서 충족되지 않는 부분은 또 어떻게 극복해야 되는지
고민을 하셔야 됩니다.
옷 위에서 말씀드린 aws 에서는 이러한 방법들이 해결하기 위해서 다양한
추상화된 서비스들을 제공하고 있구요.
그것을 적극적으로 활용하셔서 여러분들이 재학 사항에 대해서 극복할 필요가
있습니다.
실제로 클라우드 환경에서는 온 프라미스 환경 이라고 말하는 자체 구축된
환경 가 설치한 자체로 설치한 시스템 더해 idc 라고 보통 표현하는
데이터센터에서 구성하는 하드웨어와
혹은 솔루션과 동일하게 활용 하기는 어렵다
클라우드 환경에서는 aws 건 뭐야 저건 구글 표 하드 플랫폼 이건
자신들만의 시스템이 있고 이것을 저희가 가 빌려 쓴 형태이기 때문에
여러분들 환경에서 썼던 하드웨어나 솔루션들을 활용하게 는 어렵다는 것을
충분히 이해하시고
그리고 말씀드렸던 클라우드 환경의 초상화 된 서비스드 를 통해서
여러분들의 서비스를 뭐 충분히 높게 품질을 높게 가져갈 수 있도록 제약을
극복을 해야 된다
이런 관점의 변화가 첫번째로 필요하다 라고 말씀드릴 수 있습니다.
뭐 간단한 예로 데이터베이스 2기 성능을 확보 를 하게 하기 위해서
어떠한 방식을 택해야 되나 라고 했을 때
첫번째 idc 같은 경우 온 프라미스 환경
데이터베이스 서버 장비를 저희가 구매를 하고요 그 구매한 장비에 이끼
성능이 부족하다 라고 했을 때는 메모리를 추가적으로
구매를 하게 됩니다. 구매를 해서 저희가 원하는 사이즈의 스펙 가 예를
들면 저희가 원하는 메모리에 사이즈가 32 2기가 달아 곳에는 32기가
에 맞게 메모리를 추가적으로 계속 구매해서 뭐 뽑으시면 되구요.
이렇게 했을 때 우리가 원하는 이끼 성능을 보장을 할 수 있는 환경입니다.
하지만 클라우드 에서는
저희가 메모리를 추가적으로 구매해서 데이터베이스의 뭐 연동하기 는 매우
어려운 상황이고요
그러다보니 클라우드 환경에서는 다양한 추상화된 서비스를 활용을 하셔야
됩니다.
여기서 제가 간단한 예식을 말씀드리는 것은 제 4 있으라고 하는
인메모리 데이터베이스 혹은 지키 벨로 데이터 저장소에 서비스인데
일에 디스를 활용했을 때는 실제로 gb 의 데이터베이스에
올라온 데이터들을
2 인메모리 데이터베이스 4 4 2 스에서 이쪽 캐시의 예 를 대신해서
올려주기 때문에 실제로 서비스 여러분들 사용자가
서비스의 접근할때 이 메모리의 성능을 에디스 에 있는 인메모리 에 영향을
받게 됩니다.
그럴 경우는 특히 클라우드 환경에서는 데이타베이스 읽기 성능이
티비에서 이걸 메모리를 증설을 통해 가지고 확보를 하는게 아니고 앞단에
이런 추상화된 서비스들을 통해 가지구 서비스 품질을 입지 성능 같은걸
확보를 할 수 있게 됩니다.
이렇게 제약 쌍을 다양한 방식으로 여러분들이 극복할 수 있게끔 추상화된
서비스들이 있구요.
이런 것들을 적극 활용하셔서 재학생 에 대해서 옥을 하실 필요가 있습니다.
4 4장에서는 가상화 시스템 관리자의 대해서 알아보도록 하겠습니다.
실제로 it 자원을 운영을 하는 사람들을 시스템 관리자 혹은 뭐 시스템
s 이라고 불리우는데 실제로 시스템 관리자 역시도 역할에 변화가
필요합니다.
시스템 관리자는 특히 클라우드로 의 변화에 따라서 가상화 시스템 관리자의
역할을 함께 수행을 하셔야 됩니다.
과거의 관리자의 역할 보다는 뭐 가상화 환경에서

이 it 자원이 가상화가 되어 온 디맨드 할게 뭐 확장성 있게 탄력적으로
서비스 화학 되기 때문에 기존의 서버 만 운영했던 시스템엔지니어
스토리지만 운영했던 엔진 요 네토 만 운명 했던 엔지니어는 클라우드
환경에서는 이런 다양한 컴포넌트에 대해서 이해를 하고 다양한 부분에
대해서 관심과 노력이 필요합니다.
그래서 최적의 비즈니스를 이끌어 낼 수 있도록 it 시스템 관리자가
비즈니스 와 협업해 서
높은 품질의 서비스를 구성을 해야 되는 거구요
그래서 시스템 관리자는 기술 레벨로 의 확장이 좀 필요합니다.
클라우드를 활용을 하기 위해서 이런 서버 스토리지 네트워크 뿐만이 아니고
앞에서 말씀드렸던 모레 디스 라던가 혹은 추상화된 서비스
추상화는 서비스를 적극 활용하셔서 서비스의 기능을 제안을 한다.거나 혹은
적극적으로 서비스 를 제어하고 관리할 수 있도록 서비스 시스템 관리자인
역할이 변화가 필요합니다.
간단하게 그림으로 말씀드렸을 때 이렇게 표현이 될 수 있을 것 같습니다.
꼭 제가 웃 데이터베이스를 운영하는
gba 다 라고 했을 때
실제로 기본적으로 idc 같은 경우 아까 옴 프라미스 환경
로컬 환경이라고 많이 불리우는 idc 환경에서는
데이터베이스 어드민 들이 하는 이제 업무 롤 자체가 기본적으로 tv 설치
운영
그 다음에 규칙적인 db 관리 작업 규칙적인 db 관리 작업 이라고 했을
때는 뭐 백업 이라던가
패치
그 다음에 이중화 구성
실제로 서비스의 직결이 되지는 않지만 이 데이터베이스를 효율적으로 운영을
한 다음에 서비스의 품질을 높일 수 있도록 관리를 하는 역할을 말씀
드리는 겁니다
그래서 내 이런 데이터베이스 관리자 역할 자체가 시체로 클라라 들어왔을
때는 당연히 이제 기본적으로 하던 db 설치 운영
그리고 규칙적인 db 관리 작업
아까 말씀드렸던 백업이 나 패치를 당연히 수행해 하셔야 되는 거고요
그리고 클라우드 환경이다 보니 여기 데이터베이스가
가상화가 되어서
저희 인스턴스 라고 표현했는데
가상화 인스턴스화 돼서 데이터베이스가 서비스가 되게 됩니다.
그러면 이 인스턴스에 대한 또 관리도 필요하다는 겁니다
데이터베이스 인스턴스 를 이 이미지를 관리를 하고 이미지의 예를 들면 은
뭐 마인 스켈 이라던가
포스트 그래 같은 이제
데이터베이스가 설치가 되는 거구요 이런 것들을 관리하고 운영할 수 있게끔
이런 데이터베이스 인스턴스 이미지도 관리를 하셔야 됩니다.
그리고 아까 말씀드렸던 얘기겠지만
크 나도 환경에서는 다양한 시스템 들이 분산 되서 존재를 하게 되구요.
그래서 데이터베이스 역시도 분산이 되게 됩니다.
실제로 클라우드 환경에서 데이터 베이스가 저희가 모유 아이스박스 등
이렇게 한나라 보이겠지만 뒤에는 또 슬레이 후에 데이터베이스가
필요하다 환경에서 존재를 하게 되구요. 이런 것들을 효율적으로 운영을 하기
위해서 여러분들이 이제 관리 2
를 할 때 분산 데이터베이스에 개념을 가지고 관리를 하셔야 됩니다.
이렇게 기본적으로 만 봤을 때도 데이터베이스 관리자로 봤을 때 기존의
하지 않아도 상관 없었던 이미 작업 데이터베이스 서버에 대한 이미지 관리
그 다음에 db 지금 물리적인 db 가 아닌 가상화의 있는 데이타베이스
다보니 분산 데이터베이스에 대한 관리 이렇게 추가적으로 역할이 더
필요하게 됩니다.
그래서 이런 필요한 부분을 여러분들 시스템 엔지니어들이 두려워하지 마시고
적극적으로 아까 보여드렸던 추상화된 서비스 라던가 다양한 개념들을
이해하시고
클라우드를 적극 활용 하셨을때 여러분들 서비스 비즈니스의 노 보다 높은
품질을 발휘 하실 수 있습니다.
4 지금까지 클라우드 컨셉에 대해서 살펴보았습니다.
첫번째로 클라우드 컨셉 중에서 확장성과 탄력성을 가진 설계를 하셔야 된다
라고 말씀드렸습니다.
클라우드는 it 인프라 스트럭처 서버나 스토리지 는 네트워크가 확장성
있게 설계가 돼 있으며 이런 확장성과 탄력성을 가진 컨셉을 바탕으로
여러분들이 유연한 서비스 설계를 하실 수 있도록 지원하고 있습니다.
특히 어플리케이션 딴 에서 이런 클라우드 구조를 충분히 적용할 수 있도록
개념을 습득을 하시고 이해를 하신 다음에 설계를 하셨을 때 높은 품질의
서비스를 설계 하실 수 있습니다.
두번째로 재학생 에 대한 극복
모든 시스템은 요구사항이 있기 마련이고 요 그럼 요구사항을 클라우드
환경에서는 어떻게 풀어나갈지 그리고 클라우드 환경에서는 이 요구 사항을
충족하지 안투 조카는 서비스가 있는지 혹은 충족되지 않다면 어떻게 극복할
건지 의 고민이 필요합니다.
그리고 마지막으로 가상화 시스템 관리자
기존의 시스템에 엔진 여 시스템 관리자는 클라우드로 의 기술 레벨이
확장이 필요하며 특히 추상화된 이 소스를 제어하고 관리하고 그리고
비즈니스와 비즈니스 로직을
적극적으로 파악할 수 있는 역량이 필요합니다.
이렇게 클라우드 컨셉에 대해서 다양한 부분이 있다는 것을 알아보았습니다.