Why? 클라우드, 클라우드인 이유, 제공되는 기능들

예를 들면 명절에 철도 예매 서비스, 연말 정산 서비스 등 몇몇개 서비스는 플랙서블한 컴퓨팅 자원이 필요한 것들이다. 현재 어떤 서버 구조로 서비스 하고 있는지 보안사항이여서 알 수는 없겠지만, 매우 적합 할 것으로 보인다.

때로는 게임업체에서도 우리나라 게임이라면 시간대별 게임서버 댓수를 달리 함으로써 효율적인 서버 관리를 할 수도 있다. 아무래도 새벽 2-6시까지는 게임하는 사람들이 상식적으로는 적을 것이다. 낮시간에도 적을 수 있다. 하지만 휴일이나 주말에는 늘어날 수 있다. 이러한 때에 맞춰서 서버를 유연하게 관리한다면 비용적인 측면에서 좋고, 프로모션 같은 것을 진행했을때 갑자기 늘어나는 트래픽을 대응할 수 있을 것이다. 클라우드 이용 시 모델에는 퍼블릭 클라우드가 있고, 프라이빗 클라우드가 있다. 퍼블릭은 클라우드에 서버를 구축하고, 인터넷 망을 통해서 개인 또는 기업을 상대로 서비스 하는 형태이다. 프라이빗 클라우드가 있는데, 이는 클라우드에 서버를 두고 내부 인터넷, 서버로 이용하는 형태이다.

서버 사용 용량이 늘어났을 때 유연하게 대처 할 수 있다는 것이 치명적인 장점이면서 물리적 서버 관리를 하지 않아도 된다는 점에서도 큰 장점이다. 전문 인력이 있어야 하고, 하드웨어 실패에 대해서 치밀하게 대응을 해야 한다. 클라우드의 경우 이 부분에 대해서 관리를 해주기에 관리 요소가 적어진다.

초기 보용이 저렴하다는 측면도 있다. 아무래도 서버를 구축하려면 초기에 비용이 많이 든다. 그리고 초기에 얼마만큼의 트래픽이 들어올지도 정확한 예측이 어렵다. 이런 부분에 대해서 비용을 줄이고, 급증하는 용량 처리를 위한 리스크를 줄일 수 있다는 점등의 장점이 있다.

클라우드에서 제공하는 편리한 기능들이 있다.
기본적으로 서버를 제공한다. 서버는 운영체제가 설치되고, 각종 서버도 추가로 설치할 수 있다. 이미 설치가 된 서버를 이용할 수도 있고, 운영체제만 설치된 서버를 선택하고 사용자가 설치할 수도 있다. 서버 선택의 기본적인 항목은 CPU, 메모리, 디스크이다. 컴퓨터의 기본 구성이기도 하다. CPU 성능이 얼마나 좋은가, 메모리가 얼마나 큰지, 디스크는 용량이 어떠한지 디스크 방식은 메모리기반인지 등으로 구분하여 등급을 나누고 비용을 책정한다.

아마존에서의 서버 관리라는 것은 우리가 Gmail이나 네이버와 같은 웹 기반의 메일을 받았다가 삭제 하는 수준으로 매우 간단하다. 생성시에는 운영체제, CPU, 메모리, 디스크를 선택한다. 이것도 위자드 형태로 단계적으로 선택을 하고 결정을 하면 5분 이내에 생성이 된다. 생성된 것을 변경해야 하면 제한된 범위내에서는 변경이 가능하다.

운영체제를 바꾸려면 새로 만들어야 할 수 있다. 하지만 용량 정도는 바로 변경이 가능하다. 그리고 Scale-up과 같은 스케일이 전체적으로 확장하는 것도 메뉴 내에서 가능하다. CPU도 올리고, 메모리도 올리고 전체적으로 좋은 사양으로 업그레이드 하는 것이다. Scale-out도 매우 용이한데, 인스턴스를 복제해서 추가를 하면 바로 동일한 서버가 하나 만들어진다. 그대로 복사했기에 Configuration까지 동일하다. 이 컴퓨터를 바로 ELB에 연결하면 여러대의 컴퓨터를 확장 시킬 수 있다. 오토스케일링이라는 기능도 있다. 서버의 스케일을 늘리고 줄이는 것도 자동화 할 수 있다. 서버를 몇분만에 늘리고 줄일 수 있다는 것도 감사한 일인데, 이를 특정 조건을 주고, 자동으로도 할 수가 있다. 트래픽이 늘어서 서버의 용량이 어느정도 차면 서버를 늘리는 것이다. 자동적으로 늘렸다가 트래픽이 다시 줄어들거나 CPU가 내려가면 다시 줄인다. 특정 시간대에 트래픽이 몰리거나 특정 요일에 많다거나 계절에 따른 서버의 변동이 심한 경우는 이러한 오토스케일링을 적용하는 것도 좋을 수 있다.

대표적으로 로드밸런스나 스토리지가 있다.
로드밸런스는 기존에 L4, L7과 같은 스위치를 말한다. 스위치는 트래픽을 나눠주는 역할을 한다. 나눠주는 목적은 서버를 여러대 두고 부하 분산을 하기 위함이다. 동일한 내용의 서버를 여러대를 두고 비슷한 용량으로 처리하기 위해서는 스위치가 필요한데 이가 바로 로드밸런스이다. 아마존에서는 이 로드 밸런스도 가상화하여 제공한다. 우리는 로직적으로만 로드밸런스를 생성하고 그 뒤에 트래픽을 배분하려는 서버들만 연결해주면 된다. 아마존 로드밸런스 같은 경우는 인증서도 설치가 가능하다. 인증서 설치를 하여 https 프로토콜의 보안레벨 레이어 서비스도 가능하다.

그리고 S3와 같은 스토리지 서비스가 있다.
S3는 첫글자가 S로 시작되는 단어 3개의 약자이다. Simple Storage Service. 간단하게 저장 공간을 제공한다. 파일 같은 것을 올려놓을 수 있다. 이미지 파일이나 데이터 파일 모두 저장 가능하다. 저장한 곳에서 바로 접근 경로로 공유할 수도 있다. 스토리지 서비스는 기존에는 서버를 구입하고 서버에 디스크에 파일들을 두고 이를 접근하기 위해서 웹서버나 FTP 서버와 같은 서비스로 접근을 했어야 했다. 파일에 대해서 서비스를 할 때 이런 번거로움 없이 S3를 이용하면 파일을 바로 업로드 가능하고, 공유나 서비스가 용이하게 가능합니다.

아마존에는 내부 DNS서비스도 있다.
Route53 이라고 한다. 1차 DNS에 도메인을 등록을 하고, 등록한 DNS 서비스 내에서 Name Server 정보를 넣을 때 아마존의 Route 53내에 서버 정보를 넣으면 된다. 도메인을 등록하고 도메인 관리를 하는 곳에서 Route 53을 가리키게 됨으로써 일종의 위임을 받게 된다. Route 53에서만 추가/변경해도 도메인이 관리가 된다.

클라우드 컴퓨팅의 장점 중 하나는 장애에 대한 대처이다.
기본적으로 이중화 개념으로 아키텍쳐 구조를 설계할 수 있다. 물론 이는 기존 서버에도 구성을 할 수가 있다. 아마존 클라우드의 경우 ZONE이라는 개념이 있어서 그 지역이 또는 건물이 붕괴가 되는 수준의 자연재해가 났을 시를 대비하여 가까운 다른 지역에 이중화된 다른 서버를 위치하게 된다. 그런데, 하드웨어 실패와 같은 경우가 발생했을 때가 기존 방식으로는 대응이 어려운 부분이다. 이를 위해서 하드웨어를 여벌로 준비해 놓을 수도 있다. 하지만 이것은 매우 재정이 여유로운 경우는 그럴 수 있지만, 그렇지 않은 경우는 이렇게 스페어 타이어와 같은 서버 준비 가능할리 만무하다. 그렇지만 장애라는 것이 시스템 문제가 언제 찾아올지는 아무로 모르는 것이다.

클라우드 컴퓨터를 이용할 경우는 이러한 장애에 대해서 매우 유연하게 대처할 수 있다. 특히 기존 서버와 동일한 환경을 동일한 설정과 데이터를 준비해놓는다는 것은 극히 힘든 일이지만, 클라우드 컴퓨팅 세계에서는 쉽게 가능하다. 아마존의 경우 미리 AMI라는 것을 통해서 서버를 백업 해둔다. 그러면 언제든 이 AMI를 기준으로 서버를 띄울 수가 있다.

책처럼 전체를 보기를 원하시면 아래 링크를 클릭하시고 북마크 하셔서 보시면 편리합니다. 

https://wikidocs.net/22360