인프라에 얼마나 지출하시나요? 그리고 이것에 대해 어떻게 돈을 절약할 수 있습니까?

프로젝트의 인프라 비용이 얼마인지 궁금하셨을 것입니다. 동시에, 비용 증가는 부하에 비례하지 않는다는 사실도 놀랍습니다. 많은 사업주, 주유소 및 개발자는 자신이 초과 지불하고 있다는 사실을 비밀리에 알고 있습니다. 하지만 정확히 무엇 때문에?

일반적으로 비용 절감은 가장 저렴한 솔루션, AWS 계획을 찾거나 물리적 랙의 경우 하드웨어 구성을 최적화하는 것으로 귀결됩니다. 그뿐만 아니라, 사실 신이 기뻐하는 대로 누구라도 이 일을 하고 있습니다. 만약 스타트업에 대해 이야기하고 있다면 이 사람은 아마도 많은 골칫거리를 갖고 있는 선도적인 개발자일 것입니다. 대규모 사무실에서는 이 문제를 CMO/CTO가 처리하며 때로는 총괄 이사가 수석 회계사와 함께 이 문제에 직접 참여하기도 합니다. 일반적으로 '핵심' 관심사가 충분한 사람들입니다. 그리고 인프라 비용이 오르고 있는 것으로 밝혀졌지만 이를 처리할 시간이 없는 사람들은 이를 처리하고 있습니다.

사무실용 화장지를 구입해야 하는 경우 공급 관리자나 청소 회사의 책임자가 이를 수행합니다. 개발에 관해 이야기하고 있다면 리드와 CTO가 있습니다. 판매 - 모든 것이 명확합니다. 그러나 예전부터 "서버 룸"이 레이드에 약간 더 많은 RAM과 두 ​​개의 하드 드라이브가 있는 일반 타워 시스템이 있는 캐비닛의 이름이었을 때 모든 사람(또는 적어도 많은 사람)은 이 사실을 무시했습니다. 용량 구매도 특별히 교육을 받은 사람이 처리해야 한다는 사실입니다.

아쉽게도 역사적 기억과 경험에 따르면 수십 년 동안 이 작업은 "무작위" 사람들에게 맡겨졌습니다. 즉, 가장 가까운 사람이 질문을 선택했습니다. 그리고 최근에야 FinOps라는 직업이 시장에 모습을 드러내고 구체적인 모습을 갖추기 시작했습니다. 이는 용량 구매 및 사용을 제어하는 ​​임무를 맡은 동일한 특수 교육을 받은 사람입니다. 그리고 궁극적으로 이 분야에서 회사의 비용을 절감합니다.

우리는 비싸고 효과적인 솔루션을 포기하라고 주장하는 것이 아닙니다. 각 기업은 하드웨어 및 클라우드 요금 측면에서 편안한 존재를 위해 필요한 것이 무엇인지 스스로 결정해야 합니다. 그러나 많은 회사의 사용에 대한 후속 모니터링 및 분석 없이 "목록에 따라" 무분별하게 구매하면 백엔드 "자산"의 비효율적 관리로 인해 궁극적으로 매우 심각한 손실을 초래한다는 사실에 주목할 수밖에 없습니다.

FinOps는 누구인가

평판이 좋은 기업이 있는데, 영업사원들이 숨쉬는 어조로 "기업"에 대해 이야기한다고 가정해 보겠습니다. 아마도 "목록에 따르면" XNUMX~XNUMX개의 서버, AWS 및 기타 "사소한 것"을 구입했을 것입니다. 논리적입니다. 대기업에서는 어떤 종류의 움직임이 끊임없이 일어나고 있습니다. 일부 팀은 성장하고 다른 팀은 해체되고 다른 팀은 인접 프로젝트로 이전됩니다. 그리고 이러한 움직임과 "목록 기반" 조달 메커니즘의 조합은 궁극적으로 다음 월간 인프라 청구서를 볼 때 새로운 백발을 낳게 됩니다.

그렇다면 무엇을 해야 할까요? 인내심을 갖고 계속 회색으로 칠하거나, 그 위에 페인트를 칠하거나, 결제 시 수많은 끔찍한 XNUMX이 나타나는 이유를 알아내야 합니까?

솔직하게 말하자면, 동일한 AWS 요금에 대해 회사 내 애플리케이션에 대한 승인, 승인 및 직접 지불이 항상 빠른 것은 아닙니다(실제로는 거의 결코). 그리고 정확하게 기업의 끊임없는 움직임으로 인해 동일한 인수 중 일부가 어딘가에서 "분실"될 수 있습니다. 그리고 가만히 서 있는 것도 쉽지 않습니다. 세심한 관리자가 서버실에서 소유자 없는 랙을 발견하면 클라우드 요금의 경우 모든 것이 훨씬 더 슬프게 됩니다. 몇 달 동안 보관할 수 있으며 비용이 지불되지만 동시에 구매한 부서의 누구에게도 더 이상 필요하지 않습니다. 동시에 다음 사무실의 동료들은 머리뿐만 아니라 다른 곳에서도 아직 흰머리가 뽑히기 시작합니다. 그들은 n번째 주 동안 거의 동일한 AWS 요금을 지불할 수 없었습니다. 절실히 필요합니다.

가장 확실한 해결책은 무엇입니까? 그렇습니다. 도움이 필요한 사람들에게 고삐를 넘겨주면 모두가 행복해집니다. 그러나 수평적 의사소통이 항상 잘 확립되는 것은 아닙니다. 그리고 두 번째 부서는 첫 번째 부서의 부에 대해 단순히 알지 못할 수도 있으며, 이 부는 실제로 필요하지 않은 것으로 판명되었습니다.

이것에 대한 책임은 누구에게 있습니까? - 사실 아무도 없어요. 이것이 현재 모든 것이 설정된 방법입니다.
누가 이것으로 고통 받습니까? -그게 회사 전체입니다.
누가 상황을 해결할 수 있습니까? - 예, 예, FinOps입니다.

FinOps는 개발자와 필요한 장비 사이의 계층일 뿐만 아니라 회사에서 구입한 것과 동일한 클라우드 요금 측면에서 그것이 어디에, 무엇을, 얼마나 잘 "있는지" 알 수 있는 사람이나 팀입니다. 실제로 이러한 사람들은 한편으로는 DevOps, 다른 한편으로는 재무 부서와 협력하여 효과적인 중개자이자 가장 중요한 분석가의 역할을 수행해야 합니다.

최적화에 대해 조금

구름. 비교적 저렴하고 매우 편리합니다. 하지만 이 솔루션은 서버 수가 두 자릿수, 세 자릿수에 도달하면 더 이상 저렴해지지 않습니다. 또한 클라우드를 사용하면 이전에는 사용할 수 없었던 점점 더 많은 서비스를 사용할 수 있습니다. 서비스형 데이터베이스(Amazon AWS, Azure Database), 서버리스 애플리케이션(AWS Lambda, Azure Functions) 등이 있습니다. 사용하기 쉽기 때문에 모두 매우 멋집니다. 구매하고 이동하는데 문제가 없습니다. 그러나 회사와 프로젝트가 클라우드에 깊이 빠질수록 CFO의 잠은 더 심해집니다. 그리고 장군이 회색으로 변하는 속도가 빨라집니다.

사실 다양한 클라우드 서비스에 대한 청구서는 항상 매우 혼란스럽습니다. 한 항목에 대해 돈이 무엇인지, 어디로, 어떻게 갔는지에 대한 XNUMX페이지 분량의 설명을 받을 수 있습니다. 물론 이것은 즐겁지만 이해하는 것은 거의 불가능합니다. 또한 이 문제에 대한 우리의 의견은 유일한 의견이 아닙니다. 클라우드 계정을 인간 계정으로 전송하려면 예를 들어 전체 서비스가 있습니다. www.cloudyn.com 또는 www.cloudability.com. 누군가가 청구서를 해독하기 위해 별도의 서비스를 만들려고 애썼다면 문제의 규모는 염색 비용을 넘어섰습니다.

그렇다면 이 상황에서 FinOps는 무엇을 할까요?

• 클라우드 솔루션을 구매한 시기와 규모를 명확하게 이해합니다.
• 이러한 용량이 어떻게 사용되는지 알고 있습니다.
• 특정 단위의 필요에 따라 재분배합니다.
• "그럴 수 있도록" 사지 않습니다.
• 결국에는 돈이 절약됩니다.

좋은 예는 데이터베이스의 콜드 복사본을 클라우드에 저장하는 것입니다. 예를 들어 스토리지를 업데이트할 때 소모되는 공간과 트래픽을 줄이기 위해 보관하시나요? 예, 단일 특정 사례에서는 상황이 저렴한 것처럼 보이지만 나중에 이러한 저렴한 상황이 모두 발생하면 클라우드 서비스에 엄청난 비용이 발생합니다.

또는 또 다른 상황: 최대 부하에 빠지지 않기 위해 AWS 또는 Azure에서 예비 용량을 구입했습니다. 이것이 최적의 솔루션이라고 확신할 수 있습니까? 결국 이러한 인스턴스가 80% 유휴 상태라면 Amazon에 돈을 기부하는 것입니다. 또한 이러한 경우 동일한 AWS와 Azure에는 버스트 가능한 인스턴스가 있습니다. 도구를 사용하여 최대 로드 문제를 해결할 수 있다면 유휴 서버가 필요한 이유는 무엇입니까? 또는 온프레미스 인스턴스 대신 예약을 선택해야 합니다. 예약은 훨씬 저렴하고 할인도 제공합니다.

그런데 할인에 대해서

우리가 처음에 말했듯이 조달은 누구에게나 자주 수행됩니다. 마지막 것을 찾은 다음 어떻게 든 스스로 수행합니다. 대부분의 경우 이미 바쁜 사람들은 "극단적"이되어 결과적으로 사람이 빠르고 능숙하지만 완전히 독립적으로 구매할 제품과 수량을 결정하는 상황에 직면합니다.

하지만 클라우드 서비스의 영업사원과 소통할 때 용량 도매 구매에 있어서는 더 유리한 조건을 얻을 수 있습니다. 조용하고 일방적으로 등록하면 자동차에서 그러한 할인을받을 수 없다는 것이 분명하지만 실제 영업 관리자와 이야기를 나눈 후에는 지칠 수 있습니다. 아니면 현재 할인 중인 품목이 무엇인지 알려줄 수도 있습니다. 그것은 또한 유용할 수 있습니다.

동시에 AWS나 Azure에서는 빛이 쐐기처럼 수렴되지 않았다는 점을 기억해야 합니다. 물론 자신만의 서버룸을 구성하는 데는 의문의 여지가 없습니다. 하지만 거대 기업이 제공하는 이 두 가지 고전적인 솔루션에 대한 대안이 있습니다.

예를 들어, Google은 기업에 Firebase 플랫폼을 제공하여 동일한 모바일 프로젝트를 턴키 방식으로 호스팅할 수 있으며 이를 위해서는 신속한 확장이 필요할 수 있습니다. 본 솔루션을 예로 들면 스토리지, 실시간 데이터베이스, 호스팅, 클라우드 데이터 동기화 등을 한 곳에서 이용할 수 있습니다.

반면에 모놀리식 프로젝트가 아니라 전체성에 대해 이야기하는 경우 중앙 집중식 솔루션이 항상 유익한 것은 아닙니다. 프로젝트가 오래 지속되고, 자체 개발 이력이 있고, 저장에 필요한 데이터 양이 충분하다면, 좀 더 세분화된 배치를 고려해 볼 가치가 있습니다.

클라우드 서비스 비용을 최적화할 때 비즈니스에 중요한 애플리케이션의 경우 회사에 중단 없는 수익을 제공할 더 강력한 요금제를 구입할 수 있다는 사실을 갑자기 깨닫게 될 수 있습니다. 동시에 개발의 "레거시", 오래된 아카이브, 데이터베이스 등을 값비싼 클라우드에 저장하는 것이 해결책입니다. 결국 이러한 데이터의 경우 추가 기능이 없는 일반 HDD와 중간 전력 하드웨어를 갖춘 표준 데이터 센터가 매우 적합합니다.

여기서도 “이 소란은 그럴 가치가 없다”고 생각할 수도 있지만, 이 출판물의 전체 문제는 다양한 단계에서 책임 있는 사람들이 작은 일을 무시하고 더 편리하고 빠른 일을 한다는 사실에 기초하고 있습니다. 결국 몇 년 후에는 매우 끔찍한 기록이 탄생하게 됩니다.

결과는 어떻습니까?

일반적으로 클라우드는 훌륭하며 모든 규모의 비즈니스에서 많은 문제를 해결합니다. 그러나 이러한 현상의 새로움은 우리에게 아직 소비와 경영의 문화가 없다는 것을 의미한다. FinOps는 클라우드 성능을 보다 효과적으로 활용하는 데 도움이 되는 조직적 수단입니다. 가장 중요한 것은 이 입장을 총살대와 유사하게 바꾸지 않는 것입니다. 그 임무는 부주의한 개발자를 붙잡아 가동 중지 시간에 대해 "꾸짖는" 것입니다.

개발자는 회사 돈을 세지 말고 개발해야 합니다. 따라서 FinOps는 구매 프로세스와 클라우드 용량을 폐기하거나 다른 팀으로 이전하는 프로세스를 모든 당사자에게 간단하고 즐거운 이벤트로 만들어야 합니다.

출처 : habr.com