AWS를 통해 1년 안에 100만 달러를 버는 방법

만약 당신이 단기간 부자가 될 계획으로 부자가 될 것이라고 생각하고 이 페이지를 방문했다면, 당신을 실망시켜서 미안합니다. 이 기사에서는 클라우드 비용 청구서를 100만 달러까지 줄이는 방법에 대해 설명합니다. 그렇게 하면 본질적으로 백만 달러의 추가 수익을 창출하게 될 것입니다. 이 수익을 AWS로 부자가 되는 방법에 대한 온라인 강좌를 구매하는 데 사용할 수 있습니다( 여기 강좌 링크 ).

클라우드 비용은 기업의 프로젝트 초기에 간과되거나 설명되지 않는 경우가 많습니다. 2021년 HashiCorp 설문조사에 따르면 2021년에는 거의 40%의 기업이 클라우드 비용에 과다 지출한 것으로 나타났습니다[ 1 ]. 2023년에는 거의 모든 기업(94%)이 클라우드에 돈을 낭비하고 있다고 인정했으며[ 1 ] 클라우드 비용의 최소 30%가 낭비되었습니다[ 2 ]. 2022년에 클라우드 지출은 거의 5,000억 달러에 달했습니다. 따라서 연간 낭비되는 금액은 1,500억 달러에 달합니다!!

이는 수익 손실에 대한 우려일 뿐만 아니라 지속 가능성이 낮은 관행에 대한 우려이기도 합니다. 1,500억 달러의 에너지 낭비!

이러한 조사 결과에는 높은 클라우드 성숙도부터 낮은 클라우드 성숙도까지 대기업뿐만 아니라 소규모 기업도 포함됩니다. 이는 AWS를 지칭하지만 다른 클라우드 제공업체에도 동일한 원칙이 적용될 수 있습니다. 따라서 작업의 일부가 클라우드에 있는 경우 이 문서가 적합합니다.

저는 데이터 엔지니어의 관점에서 말하고 있지만 동일한 학습 내용을 다른 소프트웨어 엔지니어링 실무에도 적용할 수 있습니다.

뛰어 들어 봅시다.

1년에 100만 달러의 클라우드 비용을 지출하려면 무엇이 필요합니까?

이러한 종류의 클라우드 청구서는 일반적으로 수백만 명의 고객을 대상으로 전 세계적으로 운영되는 대규모 기업으로 제한됩니다.

대략적으로 설명하면 Spark ETL 작업을 1년 365일 24x7 시간당 최대 1.5Tb 처리하면 100만 달러의 클라우드 요금이 청구될 수 있습니다. 또 다른 예로는 전 세계 여러 위치에서 하루에 수십억 건의 요청을 받는 애플리케이션이 있을 수 있습니다.

대기업에는 이 정도 규모의 애플리케이션이 수백 개 있으므로 클라우드 제공업체와 수십억 달러 규모의 계약을 맺게 됩니다. 예를 들어, Airbnb는 2019년 말을 기준으로 5년 동안 클라우드 리소스에 12억 달러를 지출하기로 약속했습니다[3 ].

Expedia에서는 최적화 관행을 구현하여 연간 110만 달러에 달하는 데이터 처리 ETL 비용을 연간 100,000달러로 줄였습니다. 무려 91%의 비용 절감이군요!!

모든 회사가 그렇게 큰 규모의 애플리케이션을 보유하고 있는 것은 아니지만 단일 애플리케이션 또는 회사 전체에 대해 클라우드 비용을 90% 절감한다고 상상해 보십시오.

저축을 어떻게 시작하나요?

1단계: 설계 가정에 도전

가장 비싼 애플리케이션 목록을 확인하고 설계 가정에 도전해 보세요 .

• 99.999% 가용성과 밀리초 미만의 대기 시간을 갖는 애플리케이션을 구축하고 있습니까? 현실적으로 사용자는 99% 가용성과 수백 밀리초의 대기 시간으로도 충분할 것입니까?
• 수십억 개의 행이 포함된 데이터 세트를 생성하고 있는데 사용자는 일부 측정값의 집계만 사용합니까?
• 실시간으로 데이터를 랜딩하고 있는데 데이터는 하루에 한 번만 분석되나요?
• 10초마다 캐시를 새로 고치고 있지만 실제로는 며칠에 걸쳐서만 변경됩니까?

이 모든 질문은 가장 중요한 질문인 애플리케이션이 어떻게 사용될 것인가로 돌아갑니다. 그것이 존재하는 데 필요한 비즈니스 가치는 무엇입니까? 주어진 목표를 달성하는 데 애플리케이션이 어떻게 도움이 됩니까?

물론, 이러한 모든 대답은 프로젝트 초기에 명확하지 않은 경우가 많습니다. 하지만 이것이 바로 디자인이 항상 반복적인 프로세스가 되어야 하는 이유입니다. 즉, 가능한 한 원활하게 변경이 이루어질 수 있도록 해야 합니다. 엔지니어는 진화와 변화를 수용하고 애플리케이션 개발을 영향력에 맞춰 조정해야 합니다.

2단계: 인프라 리소스를 필요에 맞게 미세 조정

두 번째 단계는 애플리케이션에 올바른 리소스를 제공하고 이를 올바른 인프라에 맞게 조정하는 것으로 구성됩니다.

엔지니어는 클라우드 비용이 계산되는 방식을 알고 있어야 합니다. 예를 들어, AWS는 클러스터 가격에 입찰할 수 있는 스팟 인스턴스를 제공합니다. 이는 내결함성이 있고 유연한 애플리케이션이 있는 경우 특히 유용합니다. 가능하다면 이를 사용하십시오. AWS는 비용을 최대 90% 절감한다고 주장합니다 [ 4 ].

해결해야 할 다른 고려 사항은 다음과 같습니다.

• 전 세계적으로 고객에게 서비스를 제공하고 있습니까, 아니면 한 지역에서만 서비스를 제공하고 있습니까? 전 세계에 걸쳐 살기 위해 인프라가 정말로 필요합니까, 아니면 고객 기반에 더 가깝게 설정할 수 있습니까?
• 클러스터 인스턴스를 과도하게 프로비저닝하고 있습니까? 불필요한 비용 없이 최대 부하를 처리할 수 있는 충분한 용량이 있는지 확인하십시오. Auto Scaling을 활용하여 실제 수요에 따라 리소스를 동적으로 조정하여 유휴 리소스에 대한 초과 지불을 방지합니다.
• 데이터와 Spark로 작업하는 경우 Spark 개념과 튜닝을 이해하고 있는지 확인하세요! 그렇지 않다면 다음 리소스 [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ]를 살펴보세요.

3단계: AWS Graviton 인스턴스 사용

AWS Graviton 인스턴스를 활용하는 데에는 단점이 거의 또는 전혀 없습니다. AWS는 가장 비용 효율적인 프로세서를 만드는 데 막대한 투자를 해왔습니다. Intel 기반 프로세서에서 ARM 기반 프로세서로 전환하는 것만으로도 클라우드 지출을 최대 40% 절감할 수 있습니다[ 10 ].

이에 대한 유일한 주의 사항은 애플리케이션이 Graviton이 실행되는 ARM 기반 프로세서와 호환되어야 한다는 것입니다. RDS 또는 OpenSearch와 같은 관리형 서비스를 다루는 경우 전환이 전혀 복잡하지 않습니다. AWS는 기본 OS 및 애플리케이션 호환성을 처리합니다. 자신만의 애플리케이션을 구축하는 경우 사용 중인 언어에 따라 패키지를 다시 컴파일해야 할 수도 있습니다. Java 및 기타 언어는 변경할 필요가 없지만 Python은 약간의 주의가 필요합니다.

4단계: 비용 지출을 모니터링하고 비용 인식에 대한 교육을 실시합니다.

마지막으로 예상치 못한 최고치와 예상치 못한 상황에 대비하여 비용을 계속 모니터링하는 것을 잊지 마십시오. 애플리케이션 0일차 비용은 170일차 비용과 다릅니다. 변경 사항을 계속 추적하고 변경이 발생하는 이유를 이해해야 합니다. s3 스토리지 비용이 누적됩니까 아니면 일회성입니까? 스파이크?

필요한 알림과 운영 가이드북을 설정하세요 !

중요한 것은 비용 할당 태그를 구현하여 부서, 프로젝트 또는 환경별 지출을 추적하는 것입니다. 비용을 추적할 수 없거나 다양한 로그 시스템을 거쳐야 하는 긴 여정이 필요한 데이터 늪을 생성할 위험을 피하세요. 주어진 애플리케이션 비용으로 돌아가는 것은 빠르고 간단해야 합니다.

마지막 생각들

어디서 작업하든 새로운 기능 제공과 현재 기능 최적화의 균형을 맞추는 것은 어렵습니다. 빛의 속도로 새롭고 기발한 기능을 제공해야 한다는 압박감을 느끼지 않은 사람입니다.

그러나 엔지니어와 관리자 모두 현재 프로젝트에 대해 신중하고 사전 예방적인 결정을 내리고 위험과 기회를 효과적으로 관리하는 것이 중요합니다.