내 인스턴스를 마이크로 인스턴스에서 작은 인스턴스로 이동하고 싶지만 마이크로 인스턴스 AMI를 기반으로 새 AMI를 시작하려고 하면 64비트 인스턴스에 대한 옵션만 제공됩니다.
내 초기 ami는 우분투 10.04 이미지를 기반으로 합니다.
64비트와 32비트 인스턴스 간 이동은 불가능합니까?
로드 밸런서를 사용하여 32비트 인스턴스와 64비트 인스턴스를 함께 작동시킬 수 있습니까?
나는 엄청난 양의 데이터를 업로드할 웹사이트/웹앱을 가지고 있습니다. 65GB의 이미지로 시작하여 최대 100GB 이상의 이미지로 이동할 예정입니다.
어떤 인스턴스 유형이 이에 가장 적합한지 잘 모르겠습니다. 로드가 높을 때 인스턴스 수를 늘리기 위해 로드 밸런서와 Auto Scaling을 사용하려고 했습니다.
또한 로드 밸런서를 사용할 때 AMI 인스턴스 중 하나가 기본 이미지가 되고 나머지는 복제본 역할을 합니까?
답변1
이미지가 생성된 것과 동일한 아키텍처(32비트 또는 64비트)에서만 이미지를 시작할 수 있습니다. 마이크로 인스턴스는 32비트 또는 64비트일 수 있지만 생성할 때 64비트 이미지를 사용한 경우에는 그 이미지를 사용해야 합니다. 예산이 이를 수용할 수 있다면 '소형' 인스턴스 대신 '대형' 인스턴스를 사용할 수 있습니다.
다양한 유형의 인스턴스를 로드 밸런싱하는 것이 전적으로 가능합니다(Amazon의 ELB 또는 HAProxy, Squid, varnish 등의 다른 인스턴스 사용).
가장 큰 문제는 그 양의 데이터를 어디에 저장할 계획인지인 것 같습니다. 동일한 콘텐츠를 제공하고 업로드되는 여러 인스턴스를 계획하는 경우 다음이 필요합니다.공유 저장공간. GlusterFS와 같은 것을 사용하여 인스턴스 간에 데이터를 공유하거나 웹 인스턴스 NFS가 마운트되는 '스토리지 서버'를 가질 수 있습니다.
자동 크기 조정이 작동하는 방식은 '마스터' 이미지의 AMI ID인 '시작 이미지'를 설정하는 것입니다. 그런 다음 트리거(예: 로드가 너무 높음)에 대한 응답으로 이 이미지를 부팅합니다. 이것이 개념적으로 무엇을 의미하는지 생각하는 것이 중요합니다. 이는 부팅된 각 인스턴스가 원본 이미지를 기반으로 하며 새 데이터나 업데이트된 구성 등을 갖지 않는다는 것을 의미합니다.
요약하자면, 둘 이상의 웹 서버를 사용하려면 일종의 공유 저장소가 필요합니다. 종종 이것은 데이터베이스(Amazon의 RDS 서비스에 있을 수 있음)이지만 데이터가 아니라 저장해야 하는 큰 '파일'이 있으므로 분산 스토리지나 스토리지 서버가 필요한 것처럼 들립니다.
답변2
에 따르면Amazon EC2 인스턴스 설명 페이지, 마이크로 인스턴스는 32비트와 64비트에서 사용할 수 있는 반면, 소형 인스턴스 유형은 32비트에서만 사용할 수 있습니다 . 이것이 Small 인스턴스 유형에서 초기 64비트 AMI를 시작할 수 없었던 이유 입니다 .
- 업데이트: AWS는 그동안64비트 유비쿼터스즉, 모든 인스턴스 유형을 64비트 이미지와 함께 사용할 수 있습니다.병렬(32비트 및 64비트) AMI를 유지하지 않고도 수직적으로(더 크고 작은 인스턴스로) 더 쉽게 확장할 수 있습니다.(보다EC2 업데이트: 새로운 중형 인스턴스, 64비트 유비쿼터스, SSH 클라이언트자세한 내용은).
로드 밸런서 문제와 관련하여 이는 사용 패턴에 따라 크게 달라집니다. 32비트 및 64비트 인스턴스 유형 모두 로드 밸런서 뒤에서 아무런 문제 없이 함께 작동할 수 있습니다. 그러나 하나의 인스턴스 유형을 고수하는 것이 좋습니다. 일반적으로 이미지 처리나 그와 유사한 작업을 수행하지 않고 업로드만 수행하는 경우 주요 관심사는 I/O 및 메모리가 되어야 한다고 생각합니다. 간단히 시도해 보고 웹 앱에 필요한 최소한의 설정을 사용하고 두 인스턴스 유형 모두에 대해 몇 가지 로드 테스트를 수행하는 것이 좋습니다.