저는 기존의 물리적 데이터 센터를 AWS(애플리케이션 서버 6개와 복제된 MySQL 서버 2개)로 이전하는 데 드는 비용을 평가하려는 고독한 IT 담당자입니다. Amazon이 제공하는 비용 계산기는 대역폭 요구 사항과 3가지 크기로 제공되는 서버 인스턴스를 기반으로 합니다. 우리에게 필요한 대역폭이 무엇인지는 알고 있지만 특정 하드웨어/로드와 일치하는 EC2 서비스 인스턴스 크기가 무엇인지 파악하는 데 어려움을 겪고 있습니다. 부하는 일정에 따라 크게 달라지므로 피크 시간대에는 적어도 하나의 "주문형" 인스턴스를 구상합니다. 물리적 설정을 해당(로드 최적화된) AWS 설정에 매핑하는 데 어떤 도구/전략을 사용할 수 있습니까?
답변1
개인적으로 제공되는 비용 계산기가 나에게 부적절하다는 것을 알았습니다. 현재 3개의 m1.small, 2개의 m1.large, 1개의 m1.xlarge 및 1개의 c1.xlarge 서버 인스턴스로 구성된 배포가 있습니다. 우리는 전통적인 데이터 센터에서 3개의 물리적 서버 구축을 시작한 지 9개월이 조금 넘었습니다.
결정하기 가장 쉬운 계산 부분은 시간당 인스턴스 비용입니다. 나는 가격 체계로 인해 대부분의 S3 비용이 사소하다는 것을 알았습니다. EBS 볼륨과 스냅샷은 실제로 S3 비용보다 더 높으며 계산하기가 매우 쉽습니다. 하지만 실제 사용량이 원래 예상한 것보다 높기 때문에 I/O 요청을 과대평가하는 것이 좋습니다.
대역폭은 까다롭고 서버 인스턴스 자체가 부족하여 고려해야 할 두 번째로 큰 비용이 될 가능성이 높습니다. 대역폭 사용 패턴에 대한 아이디어가 있다고 생각했지만 AWS에서의 실제 사용량을 보면 이러한 초기 추정이 잘못된 것으로 나타났습니다. 명심해야 할 몇 가지 사항은 공용 인바운드 및 아웃바운드 대역폭뿐만 아니라 지역 간 대역폭도 있다는 것입니다. 동일한 지역에서 실행되는 인스턴스가 있지만 다른 가용성 영역(AZ)에 있는 경우 대역폭에 대한 요금이 부과됩니다. 이는 특정 AZ에서 수행되는 EBS 볼륨을 고려할 때도 중요합니다. 실제로 인스턴스 자체 간의 통신으로 인해 지역 간 대역폭이 공용 대역폭 사용량보다 높은 것을 확인했습니다.
나는 예산 목적으로 추정치를 제공하려고 할 때 대부분의 계산을 수행하는 나만의 스프레드시트를 만들었습니다. 저는 현재 새 예산에 대한 수정된 업데이트를 얻기 위해 스프레드시트를 살펴보는 중입니다. 그러나 이번에는 Amazon에서 제공하는 사용 내역 중 일부를 활용하여 더 나은 추정치를 제공할 수 있습니다.
최선의 추측 노력이었던 인스턴스 맵은 무엇입니까? 주요 목적인 서버의 CPU 및 메모리 사용량을 기준으로 일치를 시도할 수 있습니다. 우리는 실제로 물리적 서버보다 AWS로 인프라를 더 많이 분할하여 다양한 부분의 요구 사항을 더 잘 충족하고 추가 확장성을 허용할 수 있었습니다.