웹 맵과 같은 '클래식'아키텍처에 의존하는 서비스의 아키텍처를 선택할 때 RackSpace Cloud Servers 또는 Linode 와 같은보다 전통적인 호스팅 솔루션의 효율성을 과소 평가하지 마십시오 .
결과를 예측하기 어려운 S3 사용 여부,로드 밸런서 사용 여부, 백업 여부, 비용 등은 훨씬 적습니다. 더 중요하게는 이미 익숙한 도구를 사용하십시오.
얼마 전에 같은 일을 겪은 결과 AWS가 아닌 Rackspace에서 웹 맵 서비스를 호스팅하기로 한 결정의 중요한 요소는 다음과 같습니다.
- 클라우드 서버는 EC2 인스턴스보다 탄력적입니다. EC2 인스턴스는 실제로 실패 할 것으로 예상 되며 실패합니다
- EBS 볼륨도 실패하고 (뉴스에는 슬픈 이야기가 많이 있습니다) 일반적으로 I / O가 좋지 않습니다.
- 더 큰 인스턴스를 선택하지 않으면 I / O 경합이 문제가 될 수 있습니다 (특히 타일을 복사하지 않고 EC2에 시드 할 계획 인 경우). MTBtiles 데이터베이스에서도 문제가 될 수 있습니다
- 서버를 재부팅 할 때마다 공개 IP가 변경됩니다. Linode 또는 Rackspace에서는 발생하지 않습니다.
- Linode와 Rackspace는 일일 및 주간 자동 스냅 샷 및 복원을 제공하는 반면 백업 및 복원 전략을 직접 마련해야합니다.
- VPS를 실행하는 호스트에 장애가 발생하면 Rackspace는 인스턴스를 재배치하고 다른 서버에서 다시 시작하여 4 시간 내에 (SLA에 있음) 처리합니다. 휴가 중일 때 일어났습니다. 매우 전문적인 느낌이었습니다. 리노 드는 똑같이해야합니다
- Linode는 99.9 %의 가용성 SLA를 가지고 있으며 초과 프로비저닝하지 않기 때문에 뛰어난 성능을 요구합니다
- Rackspace는 최근 EBS와 같은 볼륨 전략을 제시하여 디스크 공간이 더 이상 문제가되지 않습니다. 이전에는 EC2에서 대용량 인스턴스를 확보하기 위해 많은 디스크 공간이 필요한 경우보다 세밀한 제어로 스토리지, CPU 및 메모리를 프로비저닝 할 수 있습니다.
이것으로 Amazon AWS가 다른 AWS보다 열등하다는 말은 아닙니다. 때로는 전통적인 호스팅 솔루션뿐만 아니라 클라우드 기반 솔루션도 확장 할 수 있다고 말하고 있습니다. 주목할만한 예는 StackExchange 네트워크 자체입니다.
따라서 귀하의 경우 랙 공간에서 큰 인스턴스를 시작한 다음 모든 데이터를 로컬 Postgis 인스턴스에로드합니다. 그런 다음 렌더링 엔진을 구성한 후 캐시를 시드합니다. 큰 인스턴스는 시딩 프로세스를 너무 빨리 완료하여 실행하기에 너무 비싸지 않습니다. S3에서도 fs, MTBtiles에 타일을 저장할 수 있습니다 (btw, CloudFront 를 사용하여 CDN에 S3 데이터를 제공 할 수 있음 ).
시드가 완료된 후 서버를 재부팅하고 그 시점에서 정적 데이터 만 제공하면되므로 작은 (512MB 정도) 인스턴스로 크기를 조정합니다.
이것은 약간의 대답을 얻고 있으므로 여기서 멈출 것입니다. 특정 측면에 대해 자세히 설명하려면 의견을 남기십시오.
면책 조항 : 나는 Rackspace, Linode 또는 내가 인용 한 다른 공급 업체와 제휴하지 않습니다.