Aug 1, 2018
[뉴비의 GCP 입문기-1] 클라우드가 뭐임?
안녕하세요. kuu입니다.
오늘은 클라우드가 뭔지에 대해 공부해보려고 합니다.
정말 이렇게까지 모르다니?! 멍청이인가?! 싶을 정도로 아주 기초 중의 기초 내용을 다룰 예정입니다.
제목 그대로 클라우드가 뭔지 이해해보는 이야기를 적어보겠습니다.
- 별로 전문적이지 않게 가볍게 작성될 예정이라 주의해주세요.
- 스스로의 이해를 위해 작성되었습니다.
클라우드가 뭔지 알아보기전에 앞서 서버의 개념부터 짚어보겠습니다.
저에게 서버라는건
클라이언트에서 REST API로 Request를 날리고 기다렸다가 Response를 받아,
데이터를 파싱해서 적절하게 잘 사용한다. 정도로 알고 있는 얄팍한 지식의 소유자입니다.
그렇다면 정말 서버란 무엇인가?
에 대한 정의는 [여기] 를 읽어보는 걸로 퉁쳐도 될 것 같습니다.
즉, 서비스를 요청하는 클라이언트와 클라이언트의 요청을 처리하는 서버와의 협동작업을 통해서 사용자가 원하는 결과를 얻는 처리방식이 클라이언트-서버 시스템이다.
어..?
말이 좀 뭔가 숨차게 읽어지지만, 차근차근 읽어보니 그냥 제가 알고 있던 기초지식과 비슷하긴 합니다.
그럼 클라-서버간의 사용법은 이미 알고 있는데,
여기서 생겨난 궁금증.
그럼 서버는 어떤 모양으로 생겼을까.
다시 구글에 이미지 검색을 해보면 [여기]에 보이는 바와 같이 생긴 친구들입니다.
서버실이 있던 회사를 다녀본적이 없어서 실제로 구글 이미지에 나오는 저런 서버를 실제로 본 적은 없었습니다.
그렇다면 서버실이 없던 전 회사들은 어떻게 서버를 사용하고 있었을까요?🧐
그렇게 멀지않은 과거엔 회사들은 내부에 서버실을 두고 운영하고 관리하는 형태를 취하고 있었다고 합니다.
그런데 이렇게 내부에서 운영하는 경우 여러가지의 단점이 존재하는데
- 소음이 발생하고,
- 그러면 안되겠지만 만의 하나 누군가 잘못건들게 되면 서버가 죽을 수도 있고,
- 건물 정전으로 인한 서버 다운될 수도 있으며,
- 서버의 온도를 위해 에어컨 항시 가동하여야 한다고 합니다.
- 뭐 그 외의 기타등등 손이 많이 가기도 한다고 합니다.
가만히 들어보면 가장 무서운 부분은,
누구나 서버에 물리적 접근이 가능하고, 갑자기 정전이 발생한다는 부분으로 보이네요.
물론 서버실을 아무나 출입하진 않겠지만, 에어컨이 풀가동이라면 더운날씨에 더위를 피하러 몰래 들어가 실수로 서버 선이라도 잘못 건들여 문제가 발생할 여지가 있을 것 같습니다.
정전 역시 생각보다 흔하게 발생하는 일이라, 대비할 수 없다면 갑자기 모든 서비스가 중지될 수도 있겠네요.
(정전이 주말에 간혹 발생하는데, 이러면 주말 날벼락이 될 수 있겠네요)
그리고 이 모든 관리하는 인력+전력 등의 비용이 엄청날 것 같습니다.
그래서 나온게 IDC: Internet Data Center 가 있습니다.
“우리가 서버를 보관해 줄테니, 빌려서 써.
대여료만 내.”
서버를 보관할수 있는 공간과 네트워크 패키지를 묶어서 판매합니다.
이걸 CoLocation 이라고 합니다.
정전과 자연재해에 대한 피해를 최소화 할 수 있고,
전문가들이 관리하고 있어서 믿을 수 있는 것 같습니다.
그런데 문제가 하나 발견되었습니다.
IDC 에서 공간/서버 대여해주는 서버의 스펙이 생각보다 비싸고 높네요.
빌려서 쓰는건 좋은데, 큰 서비스를 하는 회사가 아닌 이상 오버스펙일 것 같이 보입니다.
하지만 대여를 하긴 해야합니다.
그래서 이 니즈를 위해 또 쪼개서 재임대하는 업체도 나타났습니다.
이걸 호스팅 업체라고 하네요.
IDC 에서 서버를 잔뜩 빌려서, 이걸 다시 쪼개서 조금씩 나누어 판매한다고 합니다.
자, 그래서 이걸 월 단위로 약정을 걸고 서버를 싸게 임대할 수 있게 되었습니다.
…..?
근데 싸지않아요. 바로 위에 싸다고 말했지만 사실 싸지 않네요.
(최저가도 월 10만원씩 나가네요)
회사가 대기업이거나 서비스가 안정되어있다면 괜찮지만,
아직 시작한지 얼마 안되거나 트래픽이 들쑥날쑥한 경우는 뭔가 사용료가 비싸게 느껴집니다.
원래 돈이 많은 회사이거나, 항상 꾸준한 트래픽이 유지되는 경우 상관없는데
일주일에 한두번 올라가는 트래픽때문에 이렇게 매달 같은 금액을 내고 사용하는건 왜인지 낭비같이 느껴집니다.
그래서 여기서 클라우드 서비스가 짜잔하고 나타났습니다.
사실 저는 IDC 와 클라우드의 대한 차이를 인지하기까지 약 일년동안 꾸준히 다른 점을 물어보고 설명을 들어오며 겨우 깨우쳤습니다. (제가 순전히 이해력이 떨어져서)
애초에 제가 서버를 다뤄본적이 없어서, 클라우드 서비스와의 차이를 비교하고 싶어도 비교할 데이터가 없었기 때문인데요.
드디어 이번에 저 위의 내용을 차근차근 들으며 깨달을 수 있었습니다.
IDC 에서는 월 단위로 판매/임대를 해주는 방식을 취하고 있습니다.
IDC 사이트들을 보면 반년 혹은 1년단위로 계약을 하고 있네요.
하지만 반년 안에 서비스를 접을 수도 있고,
혹은 일시적으로 서비스가 대흥해서 큰 규모로 커질 수도 있다가 다시 줄어들 수도 있는데
위약금을 생각하면 선뜻 구매하기가 두렵습니다.
이때 아마존에서 AWS: Amazon Web Service Cloud를 내놓습니다.
당시 정말 획기적인 게 아닐 수가 없는데
무려!
이용료가!
(이당시)한시간 단위로 청구가 된다는 것입니다!
심지어 트래픽이 적게 나오는 시간대엔 적은 사용만큼 적은 이용료를 내고,
트랙픽이 많이 나오는 경우 자동으로 서버가 늘어나 늘어난 만큼의 이용료가 결산됩니다.
이 모든게 (당시) 시간단위로 계산이 됩니다.
이렇게 큰 서버를 대여해서 트래픽이 적은 시간대에 놀게 만들 필요가 없어지고,
트래픽이 적었던 노는 시간대의 아까운 서버 비용이 발생하지 않게 됩니다.
아마존이 왜 이런 클라우드 서비스를 만들었는지는 이야기가 길어지니 패스하겠습니다.
그냥 아마존에 위의 단점들의 이유로 필요한거 만들어서, 만든김에 이것도 파는 건가봅니다, 정도로 생각하고 넘어가겠습니다.
위의 이야기와 같이 클라우드 서비스의 핵심은 On-Demand Service라고 합니다.
사실 이게 제일 이해하기 어려웠던 부분 중 하나였습니다.
On-demand Service를 한국어로 알기쉽게 말하면 주문형 서비스라고 합니다.
주문형 서비스란 무엇일까요?
한국어만으로도 아리송하네요.
이해하기 쉽게 이야기로 풀어보겠습니다.
CASE 1.
멍씨는 작은 서비스를 운영중에 있습니다. 소소하게 DAU가 100정도 나오는 정말 작은 서비스이지요.
멍씨는 서버를 3대정도를 빌려, 리소스를 저장할 서버와 DB를 저장할 서버를 반년 동안 빡세게 개발하여 만들어낸 서비스입니다.
그러던 한 어느날 이었습니다.
엄청난 인기의 한류 연예인 꿩씨가 멍씨가 만든 서비스를 재미있게 쓰고 있다며 소셜에서 공개했습니다.
멍씨는 이번 기회에 큰 대박 한번 치겠구나 하고 기뻐하고 있었습니다.
하지만 즐거움도 잠시, 저렴한 서버를 대여해서 쓰고 있던 멍씨의 서비스가 접속이 불가능해져버렸습니다.
트래픽이 일시적으로 몰려서 결국 서버가 사망하고 만 것이지요.
멍씨는 물들어올때 노저어야하는데, 하며 발을 동동거리며 자신의 호스팅 업체에 연락을 해봅니다.
하지만 호스팅업체에선 견적서를 뽑아주고 입금을 하여야한다며 너무나 느긋한 태도로 대응을 할 뿐입니다.
그리고 당장은 트래픽만 리셋해줄 뿐이지, 서버를 늘리는 것은 셋팅부터 새로 시작해서 시간이 오래걸리게 됩니다.
어찌되었던 멍씨는 밤새 3일동안 작업하여 서버 셋팅을 완료하여 원활한 서비스를 할 수 있게 되었습니다.
하지만 한달이 지나자 꿩씨의 홍보효과는 단물이 빠져 다시 DAU 100의 상태로 돌아가버리고 말았습니다.
멍씨에게 남은건 잠깐의 부흥의 감격과 앞으로 쓸데 없이 유지해야할 오버스펙의 육개월짜리 비싼 서버 비용입니다.
CASE 2.
작디 작은 서비스를 시작하는 냥씨. DAU가 이제막 30을 넘긴 변방의 신규 서비스입니다.
냥씨는 최근 핫하다는 클라우드 서비스를 사용하여 세달 남짓 걸려 서비스를 만들었습니다. Storage, Computer Engine 등 클라우드에서 제공하는 서비스를 사용하여 최소한의 리소스를 들였습니다.
그러던 한 어느날 냥씨가 자고 일어나니, 서비스의 트래픽이 급증하여있고 DAU가 3만을 찍었습니다.
몇 개의 오류가 발생하였지만 크리티컬하진 않았고, 서비스도 여전히 원활하게 돌아가고 있었습니다.
무슨 일인가 하여 보니, 한류 연예인 꿩씨가 소셜에서 냥씨의 서비스를 재밌게 하고 있다며 소개했다고 합니다.
냥씨는 Auto Scaling을 적용시켜 트래픽이 급증할 때 알아서 서버가 늘어날 수 있도록 셋팅을 해두었던 것이었습니다.
한 달 뒤 홍보의 단물이 빠졌지만, 냥씨는 늘어난 만큼의 사용료를 지불하고 다시 원래대로의 스케일 만큼의 서비스를 운영중에 있습니다.
일부러 극단적인 예를 들어보았습니다.
위의 이야기에서 차이점이 보이실지 모르겠습니다.
큰 차이가 몇가지가 있습니다.
짚어볼게요.
- 내가 굳이 1부터 100까지 개발하지 않아도 된다.
- 트래픽이 급증할 때 별다른 노력없이 버튼 하나로 서버를 자동으로 늘리고 줄일 수 있다.
- 금액에 대한 리스크를 줄일 수 있다.
클라우드 서비스는 해당 클라우드 서비스를 운영하는 회사에서 버튼 몇개로 쉽고 편리하고 빠르게 기능을 사용할 수 있게 합니다.
예를 들어 이미지 서버가 여러개인 상황에서 저장, 수정, 삭제 등의 경우 직접 개발하기 어려우나, 클라우드의 Storage나 S3은 편리하게 알아서 내부에서 처리해준다는 것입니다.
개발 시간을 매우 줄여주는 좋은 장점입니다.
2의 경우는 정말 놀라웠는데요. 아마 트래픽이 주간 요일에 따라 들쑥날쑥인 경우 장점이 될 수 있을 것입니다.
별다른 작업을 하지 않고, 서버가 모자르면 늘리겠다하고 버튼 몇 번만 눌러 셋팅을 해두면 끝입니다.
그럼 적게 쓰는 시간대엔 요금이 적게 책정이 되고, 트래픽이 몰리는 순간 서버를 일시적으로 늘려 요금이 다시 산정됩니다.
단순히 서버를 대여하는 것에 그치지 않고, 그 외의 제공하는 기능/서비스들이 존재하고 있습니다.
아마 이게 클라우드 서비스의 가장 큰 장점이 되지 않을까 저는 생각이 드네요.
실제로 저의 최종 목표는 클라우드 서비스들을 사용하여 설정만으로 코딩을 최소화하여 서비스를 만드는게 제작입니다.
여기까지가 클라우드가 무엇인가에 대해 공부해보는 시간을 가졌습니다.
혹시 잘못된 정보가 있다면 코멘트 부탁드립니다:)
빠진 내용 몇가지.
AWS는 현재 초단위로 서비스 이용료를 계산합니다.
GCP도 역시 초단위 이용료 측정 방식을 하고 있습니다.
-
만약 내가 도쿄 리전을 사용하고 있는데, 극단적인 예로 일본이 큰 피해를 입어 도쿄 리전을 더이상 쓸 수 없을 때
내가 옵션으로 설정만 해두었다면 가까운 다른 지역의 리전에 접속하여 문제없이 계속 사용할 수 있습니다.
Q & A
Q. CGP vs AWS 가격 누가 비싼가요
A. 구글이 전세계에 구글 망을 깔아 사용하기 때문에 조금 더 저렴합니다.
Q. IDC에 보니 클라우드 호스팅이란게 있네요. 클라우드 서비스랑 뭐가 다르죠?
A. 파는 방식은 같습니다. 근데 서비스가 없네요. 그리고 시간 요금계산이 아닌 월 약정입니다.
Q. 랜섬웨어가 내가 사용하는 서비스에 감염이 되면, GCP/AWS 전체에 감염이 될 수 있나요?
A. Storage/S3의 경우는 감염이 안됩니다. 실행하는 곳이 아니기 때문이죠. 컴퓨터 엔진이나 EC2의 경우는 감염이 될 수 있습니다. 물론 내 서버에만 감염이 되고, 연결된 모든 “나의" 서버엔 감염이 됩니다. 다른 사람의 서버엔 감염이 되지 않습니다.
샌드박스 형태이기 때문입니다.
좀 더 멍청한 질문은 있었지만, 본문에 잘 녹여내었습니다:)
