クラウドの決定を数字で行う

목표

클라우드를 개념으로만 배우면 결정할 때 쓸 수가 없습니다. 이 실습은 결정에 필요한 것을 숫자로 구합니다.

• 리전을 어디에 둘지 → 거리에서 나오는 물리 한계
• 관리형을 쓸지 → 사람 시간을 넣은 비교
• 무엇을 내가 지킬지 → 공동 책임의 경계

시작

cp -r /opt/lab/cloudbasics/* .
python3 latency.py 11000 --real 180
python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

파일

파일	하는 일
latency.py	거리 → 최소 왕복 시간
tco.py	사람 시간을 넣은 비용 비교
incidents.txt	사고 10개. 여기를 채웁니다

단계

1. 물리 한계 → 01-physics.txt
2. 리전 선택 → 02-region.md
3. AZ 와 리전 → 03-az.md
4. 공동 책임 → incidents.txt
5. TCO → 05-tco.txt
6. 손익분기 → 06-breakeven.md
7. 클라우드가 답이 아닐 때 → 07-notcloud.md
8. 정리 → 08-notes.md

참고

거리와 요율은 대략치입니다. 중요한 것은 자릿수입니다 — 1ms 와 100ms 는 같은 종류의 수가 아닙니다.

돈으로 못 줄이는 것

서울↔버지니아(약 11,000km)의 최소 왕복 시간을 구해 01-physics.txt 에 남기세요. 실제 측정치는 대략 180ms 입니다 — 차이도 함께 적습니다.

python3 latency.py 11000 --real 180

빛은 진공에서 300,000km/s 지만 광섬유 안에서는 약 200,000km/s 입니다(굴절률 1.5).

110ms 는 물리 한계입니다. 인스턴스를 키우거나 돈을 더 써도 못 줄입니다. 클라우드에서 유일하게 '살 수 없는 것' 이고, 그래서 아키텍처로 풀어야 합니다.

그래서 리전을 어디에 두나

사용자가 대부분 한국에 있는 서비스의 리전을 어디에 둘지 02-region.md 에 적고, 숫자로 근거를 대세요.

1단계 숫자를 쓰세요. 서울 리전이면 사용자까지 몇 ms, 버지니아면 몇 ms 입니까?

그리고 왕복이 몇 번 일어나는지 생각해 보세요. 페이지 하나에 API 를 5번 부르면 왕복도 5번입니다. 110ms × 5 = 550ms 이고, 이건 아무것도 안 한 시간입니다.

AZ 는 왜 나눠져 있나

AZ 간 지연과 리전 간 지연의 자릿수를 비교해 03-az.md 에 적고, 왜 AZ 를 나눠서 쓰는지 설명하세요.

AZ 는 같은 도시권의 다른 건물입니다 — 거리가 수십 km 라 왕복이 1ms 안팎입니다. 리전 간은 수십~수백 ms 입니다.

같은 값에 다른 것을 삽니다. AZ 를 나누면 건물 하나가 죽어도 살아남는데 지연은 거의 안 늘어납니다. 리전을 나누면 도시가 죽어도 살아남지만 지연이 백 배가 됩니다.

누가 무엇을 지키나

incidents.txt 의 10개 사고 각각에 cloud 또는 me 를 적어 채우세요. 형식은 번호|사고|답 입니다.

판단 기준 하나 — 내가 설정할 수 있는 것은 내 책임입니다.

버킷 공개 설정도, IAM 키 관리도, OS 업데이트도 내가 합니다. 하이퍼바이저 패치와 물리 출입 통제는 내가 손댈 수 없으니 사업자 책임입니다.

헷갈리는 것 둘 — AZ 전원 장애는 사업자 책임이지만 거기에만 배포한 것은 내 책임입니다. 관리형 DB 의 마이너 패치는 사업자가 합니다.

관리형이 비싼가

직접 운영과 관리형의 한 달 비용을 사람 시간을 넣어 비교하고 05-tco.txt 에 남기세요.

python3 tco.py --self 400 --managed 900 --hours 20 --rate 60

인프라 요금만 보면 관리형이 두 배 넘게 비싸 보입니다. 사람 시간 20시간을 넣으면 관리형이 월 700$ 쌉니다.

사람 시간은 장부에 안 잡혀서 자꾸 0으로 취급됩니다. 그리고 그 시간은 대개 밤에, 사고가 났을 때 듭니다.

손익분기를 찾는다

직접 운영이 더 싸지려면 월 몇 시간 미만이어야 하는지 구하고, 그게 현실적인지 06-breakeven.md 에 적으세요.

tco.py 가 손익분기를 알려 줍니다. 위 조건이면 8.3시간입니다.

한 달에 8시간 — 백업 확인, 패치, 모니터링, 용량 점검, 그리고 한 번의 장애 대응까지 해서요. 현실적입니까?

그리고 그 시간을 쓰는 사람이 다른 일을 못 한다는 비용도 있습니다(기회비용). 장부에는 안 나옵니다.

클라우드가 답이 아닐 때

클라우드가 더 비싸거나 부적절한 경우를 두 가지 이상 찾아 07-notcloud.md 에 적으세요. 각각 왜인지도 함께.

생각해 볼 것 — 부하가 일정하고 예측 가능하며 3년 이상 쓸 대량 컴퓨트, 데이터를 대량으로 내보내야 하는 워크로드(이그레스 요금), 데이터 소재지 규제, 특수 하드웨어.

"클라우드는 싸다" 가 아니라 "클라우드는 유연하다" 입니다. 유연성이 필요 없으면 그 값을 낼 이유도 없습니다.

정리한다

08-notes.md 에 세 줄 이상. 돈으로 못 사는 것, 공동 책임의 판단 기준, 관리형 비용을 볼 때 빠뜨리기 쉬운 것.

본문에 지연, 설정, 사람 이 들어가야 합니다.