온라인 저지 사이트 클라우드 비용 결제 방법

auto Scaling으로 대응하는 것에 대한 절차 알려주시면 감사하겠습니다

결제가 가장 간단한 방식을 사용하고 싶은데요...크레딧을 충전해서 사용하는 방법도 있을까요? 있다면 절차를 알려주면 감사하겠습니다.

온라인 저지 서비스의 비용 최적화를 위한 Savings Plans 활용에 대해 안내드리겠습니다.

Savings Plans 유형 선택: Compute Savings Plans는 EC2, Fargate, Lambda 등 다양한 컴퓨팅 서비스에 적용 가능하며 인스턴스 패밀리나 리전 변경에 유연합니다. EC2 Instance Savings Plans는 특정 인스턴스 패밀리와 리전에 한정되지만 더 높은 할인율을 제공합니다. 교육용 서비스처럼 향후 아키텍처 변경 가능성이 있다면 Compute Savings Plans가 더 적합할 수 있습니다.

약정 기간 선택: 1년 약정과 3년 약정 중 선택 시, 3년 약정이 더 높은 할인율을 제공하지만 장기 커밋먼트가 필요합니다. 교육 서비스의 경우 학생 수나 커리큘럼 변화를 고려하여 1년 약정으로 시작하는 것이 안전할 수 있습니다.

시간당 약정 금액 산정: Savings Plans의 시간당 약정 금액(commitment)은 0.001에서 1백만 사이의 값으로 설정할 수 있으며, 소수점 이하 5자리까지 지정 가능합니다. 기본 사용량을 파악하여 안정적으로 유지되는 최소 사용량에 대해서만 약정하는 것이 좋습니다.

구매 범위 권장사항: 트래픽 변동이 큰 환경에서는 최소 사용량(평상시 동시 접속자 50명 기준)에 대해서만 Savings Plans를 적용하고, 피크 시간대 추가 용량은 온디맨드나 Auto Scaling으로 대응하는 하이브리드 접근이 적절합니다. 이렇게 하면 약정 미사용으로 인한 손실을 최소화할 수 있습니다.

구매 전 확인 지표: Cost Explorer를 통해 Savings Plans 구매 분석을 수행할 수 있습니다. 분석 시 다음을 고려하세요:

• 계정 범위(단일 계정 또는 통합 결제 계정)
• 분석 유형(최대 절감액, 맞춤 약정, 목표 평균 커버리지)
• 과거 사용 패턴 분석을 위한 lookback 기간
• 목표 커버리지 비율

Cost Explorer의 Savings Plans 권장사항 기능을 활용하면 과거 사용 데이터를 기반으로 최적의 약정 금액을 추천받을 수 있습니다.

추가 고려사항:

• 결제 옵션은 선불 없음(NO_UPFRONT), 부분 선불(PARTIAL_UPFRONT), 전액 선불(ALL_UPFRONT) 중 선택 가능하며, 선불 비율이 높을수록 할인율이 증가합니다
• 시험 기간 등 예측 가능한 피크에는 예약 인스턴스나 Savings Plans 추가 구매보다는 Auto Scaling으로 대응하는 것이 비용 효율적입니다
• 초기에는 보수적으로 약정하고, 3-6개월 사용 패턴 분석 후 추가 구매를 고려하는 것을 권장합니다
  Sources
  BillScenarioCommitmentModificationAction (AWS SDK for Java - 2.42.38)
  AddSavingsPlanAction (AWS SDK for Java - 2.42.38)
  start_commitment_purchase_analysis - Boto3 1.43.22 documentation

안녕하세요.

EC2 인스턴스 유형과 크기를 선정하는 것은 단순히 사용자의 규모로 판단할 수 없습니다. 워크로드가 인스턴스의 리스스를 사용하는 것에 의존성이 있기 때문입니다. 따라서, 현재 운영하고 계신 워크로드를 가장 엔트리급인 T 시리즈의 인스턴스 패밀리로 먼저 운영해 보시고, 워크로드의 상태에 따라 일반적인 워크로드면 M, CPU를 더 많이 쓴다면 C, Memory를 더 많이 쓴다면 R 시리즈 등으로 바꿔보면서 지표를 수집해 보셔야 합니다.

Auto scaling 을 사용하는 것은 너무나 적절합니다. 이는 가용을 확보하고 필요한 만큼 인스턴스를 쓰는 데 가장 좋은 방법이기 때문입니다. ASG를 설정하려면, 인스턴스가 바로 확장될 수 있도록 배포 소스를 포함한 AMI 이미지를 배포 파이프라인과 통합하여 만들어 두는 작업과, 스케일 아웃이 될 경우 인스턴스 내 백업 할 필요가 있는 데이터를 미리 처리할 수 있는 로직이 있거나 해당 과정이 불필요하게 워크로드가 디자인 되어야 합니다. 그렇지 못한 경우 Elastic Beanstalk 서비스를 이용하는 것을 고려해 보시기 바랍니다. ASG와 ALB 등 설정을 통합하여 쉽게 적용할 수 있습니다.

Savings plan 의 경우 알고 계시듯이 1년 또는 3년 내내 동작하는 인스턴스에 대한 약정 할인이 필요하신 경우 고려할 수 있으나, 지금과 같이 자동적으로 인스턴스 수량을 조정하는 단계에서는 과도할 수 있습니다. 그 보다는 위에 설명드린 Elastic Beanstalk 의 ASG 설정 중 Spot instance 비율을 높여서 일시적인 확장은 spot instance 로 대비하는 것이 훨씬 저렴하게 조정할 수 있을 것이라 생각합니다. Spot instance 는 매우 저렴하기에 설정하실 때 좀 더 높은 사양을 포함한 다양한 인스턴스 타입을 설정하셔야 가용 확보에 유리합니다.

위에 설명드렸듯이 인스턴스 사양을 결정하는 방법론은 워크로드의 리소스 사용 특성에 달려있기에 시스템 지표(주로 CPU/Memory/Network 사용량)를 살펴보시고 적절한 인스턴스 크기를 바꿔가면서 테스트 해 보시는 것이 최선입니다.