서비스 인프라

클라우드 컴퓨팅, 남의 컴퓨터를 빌린다는 것

컴퓨터를 빌리면 어떤 책임이 줄고 어떤 책임이 남을까요? 클라우드의 역사와 작업량의 모양, 비용과 통제의 교환을 살펴봐요.

이 글의 목차컴퓨터가 너무 비싸던 시절5
  1. 컴퓨터가 너무 비싸던 시절
  2. 최고점에 맞춰 사 두는 비용
  3. 무엇을 남에게 맡길 것인가
  4. 부하의 모양이 계약을 정한다
  5. 저는 무엇을 빌렸나

동네에 빵집을 여는 사람이 발전소부터 짓지는 않아요. 전기는 필요한 만큼 쓰고 쓴 만큼 내요. 오븐을 두 대 돌리든 다섯 대 돌리든 알아서 들어오고, 문을 닫은 밤에는 요금도 함께 줄어들어요.

컴퓨터는 오랫동안 발전기 쪽에 가까웠어요. 무언가를 인터넷에 올리려면 그 일을 할 기계를 먼저 사야 했고, 사는 순간 고장과 전기와 냉방과 회선이 전부 제 일이 됐어요. 클라우드 컴퓨팅은 그 관계를 전기 쪽으로 옮겨요. 다만 값이 싸지는 것이 요점은 아니에요. 요점은 무엇이 내 책임에서 빠져나가는지, 그리고 그 대가로 무엇을 내주는지예요.

조달 방식에 따른 운영 책임 경계 직접 구매는 기반 설비까지 운영자가 맡고, 컴퓨트를 빌리면 기계와 시설의 책임이 제공자 쪽으로 이동한다. 개념 도해 조달 방식에 따른 운영 책임 경계 자원 준비와 실행 경로 직접 구매 ① 장비 준비 ② 시설·회선 ③ 프로그램 실행 운영자 책임 컴퓨트 대여 ① 기반 운영 ② 자원 제공 ③ 프로그램·설정 책임 인계 조달 방식별 책임 층 운영자 제공자 직접 구매 컴퓨트 대여 프로그램·설정 기계 교체 전기·냉방 회선·건물 프로그램·설정 기계 교체 전기·냉방 회선·건물 책임 경계 책임 경계 직접 구매는 기반 설비까지 운영자가 맡고, 컴퓨트를 빌리면 기계와 시설의 책임이 제공자 쪽으로 이동한다. SOSHIN · DEV NOTES
빌린다는 것은 값을 나누는 일이 아니라, 무엇이 제 일이고 무엇이 남의 일인지를 다시 긋는 일이에요.

컴퓨터가 너무 비싸던 시절

한때 컴퓨터는 한 사람이 독차지하기에 너무 비싼 물건이었어요. 그래서 한 대를 여러 사람이 아주 짧은 시간씩 번갈아 쓰게 하는 방법이 나왔고, 각자에게는 혼자 쓰는 것처럼 느껴졌어요. 이 방식을 시분할(time-sharing)이라고 불렀어요.

MIT에서 1961년에 시작된 CTSS가 그 초기 사례였고, 인공지능 연구자 John McCarthy가 이 발상을 이끌었어요. 그의 관심은 기술보다 그 앞에 있었어요. 컴퓨터를 살 수 없는 사람도 계산을 쓸 수 있어야 한다는 것이었고, 1963년 MIT에서 이어진 프로젝트는 목표를 전화나 전기처럼 누구나 끌어다 쓰게 하는 것으로 잡았어요. 지금 클라우드라고 부르는 것의 뼈대가 그때 문장으로 나와 있었던 셈이에요.

최고점에 맞춰 사 두는 비용

2006년 8월 Amazon이 EC2 베타를 열었어요. 가상의 컴퓨터를 만들고 필요 없어지면 없애며 켜져 있던 시간만큼만 내요. 발표 글에는 이 서비스가 왜 필요한지 설명하는 문장이 있어요. 어떤 때는 계산이 많이 필요하고 어떤 때는 조금만 필요한데, 가장 많이 쓸 때에 맞춰 하드웨어를 갖추는 것은 결코 경제적이지 않다는 것이에요.

용량 확보 방식에 따른 유휴 구간 최고점에 고정한 용량은 수요가 낮은 시간마다 유휴분을 남기지만, 조정 가능한 용량은 실제 사용량을 따라간다. 개념 도해 용량 확보 방식에 따른 유휴 구간 용량 결정 경로 ① 부하 변화 ② 최고점 기준 ② 사용량 추적 ③ 고정 용량 ③ 조정 용량 시간에 따른 사용량과 확보 용량 사 둔 용량 빌린 용량 실제 사용량 유휴 용량 최고점에 고정 유휴 구간 용량 시간 최고점에 고정한 용량은 수요가 낮은 시간마다 유휴분을 남기지만, 조정 가능한 용량은 실제 사용량을 따라간다. SOSHIN · DEV NOTES
가장 바쁜 날에 맞춰 사 두면 나머지 날의 여유분은 전부 제가 낸 돈이에요.

여기서 갈리는 것은 부하의 모양이에요. 클라우드가 늘 싸지는 것도 아니고 늘 비싸지는 것도 아니라서, 판단은 클라우드냐 아니냐가 아니라 이 작업이 어느 모양이냐에서 시작해요.

무엇을 남에게 맡길 것인가

클라우드마다 맡아 주는 범위가 달라요. 가상 컴퓨터를 빌리면 하드웨어는 제공자가 관리하지만 운영체제와 앱의 패치는 여전히 제 몫일 수 있어요. 관리형 데이터베이스라면 그 일부를 더 맡길 수 있죠. 완성된 서비스를 써도 계정 권한과 데이터 사용 방식은 남아요. 기능 이름보다 누가 무엇을 고치고 복구하는지로 비교하면 책임이 더 잘 보여요.

빌려주는 곳도 한 군데가 아니에요. Amazon Web Services, Google Cloud, Microsoft Azure, Oracle Cloud Infrastructure처럼 이름은 여럿이지만 파는 것은 대체로 같아요. 계산할 힘, 데이터를 둘 자리, 그 둘을 잇는 통로예요. 그래서 제공자를 고르는 일은 기술을 고르는 일이라기보다 값과 지역과 손에 익은 도구를 고르는 일에 가까워요.

부하의 모양이 계약을 정한다

모양이 정해지면 유리한 계약 형태가 따라 나와요. 어긋나게 고르면 그 차이는 성능이 아니라 매달 청구서로 돌아오고, 청구서는 한참 뒤에야 온다는 것이 이 판단을 미루기 쉽게 만들어요.

이 작업의 모양값이 유리한 쪽반대로 고르면
하루 종일 비슷하게 돈다미리 확보하거나 약정한다시간당 값이 쉬는 시간까지 계속 쌓인다
평소 놀다가 가끔 크게 튄다필요할 때만 빌린다최고점에 맞춘 여유분이 나머지 시간의 지출이 된다
짧고 드물게 돈다요청 단위로 값을 낸다켜 두는 값이 실제로 쓴 양보다 커진다

여기에 축이 하나 더 있어요. 밖으로 나가는 데이터에 매기는 값은 클라우드 요금에서 예측이 가장 어려운 축이고, 옮기고 싶어도 못 옮기는 상황을 만들기도 해요. 어느 쪽을 고르든 이 항목의 조건은 따로 확인하는 편이 나아요.

기간이 끝저도 남는 몫을 상시 무료라고 부르는데 제공자마다 범위가 꽤 달라요. Oracle은 그 목록을 공개해 두었어요. 다만 이런 수치는 제공자 사정에 따라 바뀌므로, 실제로 정할 때는 그때 문서를 다시 여는 편이 나아요.

저는 무엇을 빌렸나

제가 만드는 작은 앱을 만들면서 이 질문을 처음으로 진지하게 받았어요. AI가 글을 지어 주는 앱이라 계산이 필요한데 그 계산의 모양이 하나가 아니었어요. 앱을 열어 두고 데이터를 보관하는 일은 하루 종일 쉬지 않는 상시 부하이고, AI가 문장을 만드는 일은 특별한 장비가 잠깐씩 강하게 필요한 순간 부하예요. 성격이 다른 둘을 한 곳에 몰아넣으면 한쪽에 맞춘 선택이 다른 쪽에 낭비가 되므로 나눠서 서로 다른 제공자에 두었어요.

상시 부하 쪽을 Oracle Cloud Infrastructure로 정한 데에는 두 가지가 있었어요. 하나는 거리예요. 제공자가 데이터센터를 모아 둔 지역 단위를 리전(region)이라고 부르는데, 2020년 5월 춘천에 리전이 열려 있었어요. 국내에서 쓰는 앱이니 신호가 바다를 건너지 않는 편이 나아요. 다른 하나는 앞에서 본 상시 무료 등급이에요. 매달 주어지는 몫이 작은 서버 하나를 조용히 켜 두기에는 넉넉해서, 사람이 아직 몇 없는 서비스에 고정비부터 얹지 않아도 됐어요.

돌아보면 그때 정한 것은 서버를 어디에 둘까가 아니라 이 작업이 상시인가 순간인가였어요. 클라우드에서 값을 아끼는 방법은 대체로 싼 곳을 찾는 일이 아니라 이 질문을 먼저 하는 일이었어요.

소신을 상징하는 까마귀 목판화 일러스트
작성자소신 · Soshin

웹과 서버를 만들고, 개발하며 배운 것들을 글로 남깁니다.

좌우로 움직여 보세요