기본 콘텐츠로 건너뛰기

클라우드에 대한 잘못된 오해들

클라우드 서비스를 얘기하다보면 오해가 많이 생긴다.
오해의 유형을 들어보면,

- 클라우드 = 웹하드?
- 클라우드 = 가상화?
- 클라우드는 보안이 취약다던데?
- 클라우드에 올린 서비스는 절대 죽지 않는다?
- 클라우드는 비용이 저렴하다?
- 클라우드는 리소스 쉐어드 방식이라 다른사람이 많이 쓰면 내가 손해?

정말 많은 사람들이 잘못 알고 있는 부분인데,
클라우드란 용어의 정의에 대해서 찾아보려 하지 않는다.
보통 처음보는 용어를 어디서 검색하냐고 물으면 십중팔구는 "네이버" 이다.
거의 네이버를 쓰지 않지만
한 번 그들이 왜 잘못생각하는지 그들의 관점에서 보기 위해 네이버에 검색을 해봤다.
.....
광고 뿐이다.
첫 페이지에 클라우드가 무엇인지를 알려주는 내용이 하나도 없다.
그아래 지식인이 보였다.
클라우드에 대한 질문이 많이 보인다.
하나를 클릭해서 봤다.
.......
질문자나 답변자나....
어디선가 어설픈 지식을 가지고 답변을 하고,
그게 진짜인줄 알게된 질문자는 고맙다는 리플을 달고..
광고성 리플이 채택이 되고...
결국 왜 그들이 클라우드에 대해 더 모르게되고 어설픈 확신을 갖게 되는지 알게 됬다.
한국 위키페디아에서는 1965년 미국의 컴퓨터 학자가 "컴퓨팅 환경" 이란 용어를 가지고 시작한 것으로 나와있다.
일본어 위키페디아에는 이런 내용이 있다.

"클라우드 컴퓨팅 이란 용어는 2006년 Google의 CEO인 에릭 슈미트(Eric Emerson Schmidt)의 발언으로 처음 소개되었다"

이런 심플한 내용이 한국어로 된 웹사이트에는 찾아볼 수가 없는 현실이 자칭 세계 제일이라는 한국의 인터넷 환경이란 것이다.
각설하고...
위의 오해를 풀어보자면,
클라우드 란 용어는 처음 제창한 에릭 슈미트의 말을 인용하자면,

"데이터도, 프로그램도 모두 서버군에 놓고 어딘가의 클라우드안에 있으면 그것을 빼서 쓸 수 있으면 되는"

환경을 주면 되는 것이다.
그럼, 클라우드 > 웹하드 라는 것은 알 수 있을 것이다.
클라우드 서비스의 일부중에 웹하드 서비스도 포함되어있고,
보안관제 서비스니 호스팅 서비스니 이러한 모든 서비스들이 포함되어있다고 보면 되는 것이다. 새로운 시스템이나 솔루션을 뜻하는 내용이 아니다.
하지만, 에릭의 말을 사업자의 입장에서 생각하면 어떤 말이 되는 것일까?

"클라우드 라는 곳에 모든 데이터, 프로그램, 서버를 놓아야 하고, 이를 고객이 원할때 빼서 주고, 사용이 끝나면 회수를 하고, 고객이 사용한 것에 대한 비용을 받아야 한다"

여기서 이런 환경을 서비스로 하기 위해서 서비스 사업자의 관점에서 풀어쓴다면

"원하는 때 원하는 만큼만 쓰고 사용한 만큼만 비용을 지불하는 인터넷 환경"

이라고 말할 수 있다. 이 안에 많은 내용이 내포되어 있는데,

원하는 때 원하는 만큼만 사용 (Ondemand Service)
사용한 만큼만 비용을 지불(Metering)
데이터, 프로그램, 서버를 포함한 인터넷 환경(Infra, Platform, Software)

이 세가지가 키워드 인 것이다.
그래서 요즘 언급한 클라우드 라는 서비스를 하는 서비스 업체는 위의 세가지 기능(feature)을 구현하여 서비스를 하는 것이다.
그렇다면 또 다른 오해인 클라우드는 보안이 취약할까?
이렇게 생각하는 사람들의 대부분의 오해의 원인은 다음 내용에서 알 수 있다.

"하나의 서버를 가상화하여 여러 사람들이 사용하기 때문에 하나의 서버가 뚫리면 다른 서버도 쉽게 뚫리므로 보안이 취약할 것이다"

라는 클라우드 = 가상화 라는 방정식을 머릿속에 넣고 생각을 하기 때문이다.
위의 설명에서처럼 클라우드라는 것은 단지 인프라, 플랫폼, 소프트웨어를 제공해주는 방법일 뿐이지 가상화가 되느니 안되느니는 방법론 적인 부분이므로 클라우드가 보안에 취약하다는 말은 정확한 표현이 아닌 것이다.
만약 "가상화 솔루션 자체가 보안에 취약하다" 라는 말을 한다면 이것은 가상화 솔루션업체에 문의할 내용이며, 최근 버전의 대부분의 가상화 솔루션에서는 충분한 보안장치를 가지고 있는 것으로 알고 있다.

"한 서버의 리소스를 같이 쓰기 때문에 다른 사업자가 사용하는 리소스때문에 랙 현상이 생기지 않을까?"

라는 불안함을 가지고 있을 것이다.
당연히 호스팅도 저렴한 버전은 쉐어드 방식이라 누군가 웹하드 서비스를 이용하는등의 대량 트래픽을 날리면 주변 서비스는 영향을 받게 되어있다. 그래서 Dedicated Hosting으로 하지 않는가?
클라우드 서비스 역시 "가상화(Virtualization)" 서비스만을 얘기하는 것이 아니므로 vZone등의 Dedicated Resource Service가 있는 것이다. 이런 서비스를 적절히 사용하게 된다면 위의 불안함은 바로 사라지는 것이다. 클라우드 서비스에 대해 깊이있게 보았다면 위의 불안함은 바로 사라졌을 것이다.

"클라우드는 비용이 저렴하다?"
이것은 단언할 수 있다.
하지만 여기엔 조건이 붙는다.

일반적인 서비스의 평균 리소스 사용량이 20%미만인 대부분의 서비스는 당연히 클라우드 서비스로 비용을 절감할 수 있다.
스마트폰 게임등과 같은 네트워크를 별로 사용하지 않는 서비스의 경우 퍼블릭 클라우드 서비스를 이용하면 기본 네트워크 비용만으로도 충분히 커버하기 때문에 비용이 오히려 저렴해진다. 스마트폰 게임은 대부분 웹서버와의 통신을 하기 때문에 URL과 리턴값정도로 끝나기 때문이다.(일부 웹베이스로 이미지 캐싱등이 필요한 서비스도 있긴하지만..)
MMORPG등 다수의 서버를 사용하는 경우 인증서버 또는 서버 리소스 사용량이 적은 서버들을 가상화 또는 클라우드 서비스를 이용하게 하면 비용이 절감된다. 네트워킹은 VPC등 가상 프라이빗 네트워크를 구성할 수 있도록 서비스를 제공하고 있는 클라우드 서비스 업체나 물리 서버까지 같이 관리해주는 서비스가 있기 때문에 잘만 활용하면 비용을 많이 줄일 수 있다.
많은 클라우드 인프라 이용자들이 또 잘못 알고 있는 것이
"클라우드에 인프라 서비스를 이용하고 있으면 하드웨어가 죽어도 자동으로 다른 곳으로 이전된다."

라고 알고 있는 케이스가 많다.
클라우드는 위에서도 말했지만, 서비스의 형태로 IT관련 전반의 리소스를 쉽게 제공할 수 있는 것이지 자동으로 복제되거나 하는 것은 서비스 회사의 기능일 뿐이다.(게다가 이런 기능은 이중화와 똑같은 기능이므로 이중화에 해당하는 이용요금이 발생하는 것은 당연할 것이다.)


"AWS도 센터가 벼락맞아 서비스가 단절 되기도 하는데 IDC 직접 계약이나 다를바 없지 않아?"
라고 말하는 사람이 있다.
클라우드 서비스에 대해서 반 만 이해한 사람인 것이다.
세상에는 많은 클라우드 서비스가 있고, 이들 중에는 물리적으로 센터를 여러개 가지고 있는 서비스가 있다.
이들이 고객에게 주는 매리트는

"물리적으로 나누어져 있기 때문에 물리적인 이중화로 서버를 구성하면 그동안 센터 하나만 쓰는 서비스 사업자들보다 안전할 수 있다"

인 것이지, 센터 하나만 쓰면 당연히 센터에 문제가 생기면 어쩔 수 없는 것이 아닌가?
그렇다고 두 군데 계약을 하기에는 회선, 상면 비용이 두 배로 늘게 되고,
관리 포인트도 두 배가 된다. 서버가 죽으면 멀리 있는 센터에 직접 뛰어가서 교체해야하는 것이 맞을까?
이런 다양한 부분을 해결해주는 것이 바로 클라우드 서비스인 것이다.
클라우드 서비스를 이용하거나 제공하는 사람들 모두 클라우드의 장단점을 정확히 이해하고 사용하여 오해가 없어야 생각지도 못한 장애에 대해서 책임을 묻는 일이 없을 것이다.

마지막으로 클라우드 서비스를 이용한다는 것은,
"인프라 관리 솔루션을 이용한다"

는 접근으로 가야 맞을 것이다.
vCenter, SystemCenter, XenCenter, AWS등등이 그러하듯이,
가능한 고객이 가지고 있는 대부분의 자원을 보다 편하게 관리하고 사용할 수 있는 툴을 제공하는데 그 목적을 하고 있다.
인프라만을 생각하여 접근한다면 큰 매리트가 없지만,
인프라 관리자의 관리포인트의 축소 및 관리 시간 절감, 대응 시간 절감효과까지 종합한 서비스로서의 "클라우드 서비스"를 바라본다면 상상이상의 비용절감 효과를 보일 수 있다.

댓글

  1. 좋은 내용 감사합니다. ㅎㅎ
    확실히 딱 와닿는 내용이네요..
    그동안에 잘못된 내용들과 오해가 싹 풀리고
    이해가 딱 되네요. 감사합니다.
    (마지막 사진때문은 아닙니다..ㅎㅎ)

    답글삭제

댓글 쓰기

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...