💰 Cost-efficient Cloud Management (클라우드 비용 관리와 규모 산정)

1. 왜 비용 관리가 중요한가?

클라우드는 Pay-as-you-go(쓴 만큼 지불) 모델이라는 장점이 있지만, 관리가 소홀하면 예상을 뛰어넘는 과도한 비용(Bill Shock)이 발생할 수 있습니다.

흔히 발생하는 비용 문제 4가지

1. 좀비 리소스 (Zombie Resources): 사용하지 않는데 켜져 있는 VM, 미사용 스토리지, DB 등.
2. 과도한 할당 (Over-provisioning): 트래픽은 적은데 고성능(비싼) 자원을 할당하는 경우.
3. AI 워크로드 관리 실패: LLM 사용 시 긴 프롬프트나 고가 모델 사용으로 인한 토큰 비용 급증.
4. 추적 어려움: 어떤 팀이 얼마나 썼는지 파악 불가능 (Tagging 미비 등).

---

2. FinOps (Financial Operations)

단순히 돈을 아끼는 것이 아니라, 재무(Finance)와 개발/운영(DevOps)을 결합하여 클라우드 가치를 최대화하는 문화이자 운영 모델입니다.

💡 핵심 원칙: "클라우드 비용에 대한 책임은 모두가 함께 진다."

• 협업 (Collaboration): 개발팀, 운영팀, 재무팀이 실시간으로 협력.
• 가시성 (Visibility): 비용 데이터를 실시간으로 시각화하고 공유.
• 책임 (Accountability): 각 팀이 자신들이 사용하는 리소스 비용을 책임짐.

---

3. 규모 산정 (Sizing) & 용량 계획 (Capacity Planning)

과거 온프레미스 환경과 클라우드 환경에서의 접근 방식 차이를 이해해야 합니다.

Hardware Sizing (하드웨어 규모 산정)

• 정의: 시스템 구축 시 필요한 CPU, 메모리, 디스크 등의 사양을 미리 결정하는 작업.
• 과거(On-Premise): 장비 도입 시점에 최대 트래픽(Peak)을 예상하여 넉넉하게 산정해야 했음. (한 번 사면 바꾸기 힘듦)
• 현재(Cloud): 초기에는 적절히 산정하고, 운영하면서 맞추는 Right Sizing이 중요.

Right Sizing (적정 규모 산정)

• 개념: 워크로드 요구사항에 딱 맞는 리소스 크기를 찾아 비용을 최적화하는 과정.
• 장점: 비용 절감, 성능 최적화.
• 과제: 너무 작게 줄이면 성능 저하(Under-provisioning) 위험이 있음 → 모니터링 필수.

Capacity Planning (용량 계획)

• 미래의 수요를 예측하고 이에 맞춰 IT 자원을 계획하는 지속적인 활동.
• 검증 방법: 부하 테스트(Load Testing), 스트레스 테스트(Stress Testing)를 통해 산정된 규모가 적절한지 검증.

---

4. Azure 비용 관리 도구

Microsoft Azure에서 제공하는 3대 비용 관리 도구입니다.

도구	용도	특징
Azure Pricing Calculator	사전 예측	리소스 생성 전, 예상 견적을 뽑아볼 때 사용 (기획 단계).
Azure Advisor	최적화 추천	현재 사용 중인 리소스를 분석하여 "이거 안 쓰니까 끄세요" 혹은 "예약 인스턴스로 바꾸세요" 같은 조언 제공.
Azure Cost Management	사후 분석 & 모니터링	실제 발생한 비용을 분석, 예산 설정, 경고 알람 발송.

---

5. [심화] 정보시스템 하드웨어 규모산정 지침 (TTA 표준)

공공기관이나 대규모 SI 프로젝트에서 하드웨어 도입 시 적용하는 표준 산정 방식입니다. (PDF 2 참조)

1) CPU 산정

• 기준: TPC-C (tpmC) 또는 SPECjbb (max-jOPS) 벤치마크 점수 활용.
• 산정 공식 요소:
  • 기본 부하: 동시 사용자 수 × 사용자당 트래픽.
  • 보정치: 피크타임 부하, 애플리케이션 복잡도, 인터페이스 부하, 클러스터링 여부, 시스템 여유율(버퍼).
  • 핵심: OLTP(DB) 서버와 WEB/WAS 서버의 산정 기준이 다름.

2) 메모리(RAM) 산정

• 공식: (OS 커널 및 시스템 영역) + (사용자당 필요 메모리 × 동시 사용자 수) + (버퍼 캐시)
• 메모리는 부족하면 스와핑(Swapping)이 발생하여 성능이 급격히 저하되므로 CPU보다 넉넉하게 산정하는 경향이 있음.

3) 디스크 & 스토리지 산정

• 디스크: OS 영역, 응용 프로그램 영역, 데이터 영역(실제 DB 크기), 백업 영역, RAID 여유율 등을 고려.
• 스토리지 성능: IOPS(Input/Output Operations Per Second) 기준으로 산정. (SPC-1 벤치마크 참조)

---

📝 강의 노트 & 인사이트

과거 vs 현재의 업무 방식

• 과거 (No Cloud):
  • 온라인 쇼핑몰 기획 시, '하드웨어 비용 산정'이 기획서의 핵심이자 가장 어려운 부분.
  • 예측 실패 시 장비를 추가 구매하거나(예산 초과), 서버가 다운되는(매출 손실) 리스크가 컸음.
• 현재 (Cloud):
  • 초기 비용 산정 부담이 줄어듦. (일단 작게 시작 -> 스케일 아웃).
  • 대신 운영 비용(OpEx) 관리가 핵심 역량이 됨.

운영의 고충

• 보안/인프라 운영 업무는 밤낮, 주말이 없는 경우가 많음 (장애 발생 시 즉시 대응).
• 클라우드의 관리형 서비스(Managed Service)와 자동화 도구를 잘 활용하면 이러한 '노가다'성 업무를 줄이고 워라밸을 개선할 수 있음.

스타트업 팁

• Microsoft for Startups Founders Hub: 스타트업의 경우 신청 시 Azure 크레딧을 지원받을 수 있어 초기 비용 부담을 덜 수 있음.