EBS 대 인스턴스 스토어의 이점 (및 그 반대) [폐쇄]

Amazon EC2의 인스턴스에 대해 EBS와 인스턴스 스토어의 이점이 무엇인지 확실하지 않습니다. 어쨌든 EBS가 상대적으로 적은 비용 차이로 더 유용합니다 (중지, 시작, 지속 + 더 나은 속도) ...? 또한 아직 비교적 새로운 사람들을 고려할 때 더 많은 사람들이 EBS를 사용할 수 있는지에 대한 기준이 있습니까?

결론은 거의 항상 EBS 지원 인스턴스를 사용해야한다는 것입니다.

이유는 다음과 같습니다

• EBS 지원 인스턴스는 API를 통해 (실수로) 종료 할 수 없도록 설정할 수 있습니다.
• EBS 기반 인스턴스는 사용하지 않을 때 중지하고 가상 PC 일시 중지와 같이 다시 필요할 때 다시 시작할 수 있습니다. 적어도 사용량 패턴으로 인해 수십 GB의 EBS 스토리지에 소비하는 것보다 훨씬 많은 비용이 절약됩니다.
• EBS 지원 인스턴스는 충돌시 인스턴스 스토리지를 잃지 않습니다 (모든 사용자의 요구 사항은 아니지만 복구 속도가 훨씬 빠름)
• EBS 인스턴스 스토리지의 크기를 동적으로 조정할 수 있습니다.
• EBS 인스턴스 스토리지를 새로운 인스턴스로 이전 할 수 있습니다 (실행중인 Amazon의 하드웨어가 비정상적이거나 때때로 중단되는 경우에 유용함)
• S3에서 이미지를 가져올 필요가 없으므로 EBS 지원 인스턴스를 시작하는 것이 더 빠릅니다.
• EBS 지원 인스턴스가 유지 관리를 위해 예약 된 하드웨어 인 경우 인스턴스를 중지하고 시작하면 자동으로 새 하드웨어로 마이그레이션됩니다. 또한 인스턴스를 강제로 중지했다가 다시 시작하여 장애가 발생한 하드웨어에서 EBS 지원 인스턴스를 이동할 수있었습니다 (마일리지는 장애가있는 하드웨어에 따라 다를 수 있음).

저는 Amazon을 많이 사용하고 있으며 기술이 베타 버전에서 나 오자마자 모든 인스턴스를 EBS 지원 스토리지로 전환했습니다. 나는 그 결과에 매우 만족했다.

EBS는 여전히 실패 할 수 있습니다-은 총알이 아닙니다

클라우드 기반 인프라는 언제든지 장애가 발생할 수 있습니다. 이에 따라 인프라를 계획하십시오. EBS 지원 인스턴스는 임시 스토리지 인스턴스와 비교하여 일정 수준의 내구성을 제공하지만 실패 할 수 있습니다. 모든 가용 영역에서 필요에 따라 새 인스턴스를 시작하고 중요한 데이터 (예 : 데이터베이스)를 백업 할 수있는 AMI를 보유하고 예산이 허용하는 경우로드 밸런싱 및 중복성을 위해 여러 인스턴스를 실행하십시오 (이상적으로 여러 가용 영역에서) ).

하지 않을 때

어떤 시점에서는 인스턴스 스토어 인스턴스에서 더 빠른 IO를 달성하는 것이 더 저렴할 수 있습니다. 확실히 사실이었던 시간이있었습니다. 이제 EBS 스토리지에 대한 많은 옵션이 있으며 많은 요구를 충족시킵니다. 옵션과 가격은 기술이 변화함에 따라 끊임없이 진화합니다. 실제로 처분 할 수있는 상당한 양의 인스턴스가있는 경우 (실제로 비즈니스에 큰 영향을 미치지 않음) 비용 대 성능에 대한 계산을 수행하십시오. EBS 지원 인스턴스도 언제든지 죽을 수 있지만 실제로는 EBS의 내구성이 더 뛰어납니다.

AWS 설정의 99 %가 재활용 가능합니다. 따라서 인스턴스를 종료해도 아무런 문제가 없습니다. 아무것도 손실되지 않습니다. 예를 들어 내 응용 프로그램은 SVN의 인스턴스에 자동으로 배포되며 로그는 중앙 syslog 서버에 기록됩니다.

인스턴스 스토리지의 유일한 이점은 비용 절감입니다. 그렇지 않으면 EBS 지원 인스턴스가 승리합니다. 에릭은 모든 장점을 언급했습니다.

[2012-07-16] 오늘이 답변을 많이 다르게 표현하겠습니다.

지난 1 년 동안 EBS 지원 인스턴스에 대한 경험이 없었습니다. AWS의 마지막 중단 시간도 EBS를 거의 망쳤습니다.

RDS와 같은 서비스는 어떤 종류의 EBS도 사용하며 대부분의 경우 작동하는 것 같습니다. 우리가 스스로 관리하는 경우, 가능한 경우 EBS를 제거했습니다.

데이터베이스 클러스터를 다시 철 (= 실제 하드웨어)로 옮긴 확장을 제거합니다. 인프라에 남아있는 유일한 부분은 여러 EBS 볼륨을 소프트웨어 RAID에 스트라이핑하고 하루에 두 번 백업하는 DB 서버입니다. 백업간에 손실되는 것은 무엇이든 함께 살 수 있습니다.

EBS는 본질적으로 네트워크 볼륨 (원격에서 서버에 연결된 볼륨)이기 때문에 다소 결함이있는 기술입니다. 본질적으로 무제한 영구 저장 장치는 API 호출 이기 때문에 놀라운 작업 입니다. 그러나 I / O 성능이 중요한 시나리오에는 적합하지 않습니다.

또한 네트워크 스토리지의 작동 방식 외에도 모든 네트워크가 EC2 인스턴스에서 공유됩니다. 실제 호스트 시스템의 네트워크 인터페이스가 그 위에서 실행되는 여러 VM (= EC2 인스턴스)간에 공유되므로 인스턴스 (예 : t1.micro, m1.small)가 작을수록 더 나빠집니다.

인스턴스가 클수록 더 좋습니다 . 더 나은 여기에 이유 내 에서 의미 합니다.

지속성이 필요할 때 항상 사람들에게 S3와 같은 것을 사용하여 인스턴스를 중앙 집중화하도록 조언합니다. S3는 매우 안정적인 서비스입니다. 그런 다음 새 서버를 부팅 할 수있는 시점으로 인스턴스 설정을 자동화하면 자동으로 준비됩니다. 따라서 인스턴스보다 더 긴 네트워크 스토리지가 필요하지 않습니다.

결국 EBS 지원 인스턴스에는 아무런 이점이 없습니다. 오히려 부트 스트랩에 1 분을 더한 다음 잠재적 SPOF로 실행하십시오.

우리는 인스턴스 스토어를 좋아합니다. 이를 통해 인스턴스를 완전히 재활용 할 수있게되었으며, 주어진 AMI에서 서버를 처음부터 새로 작성하는 프로세스를 쉽게 자동화 할 수 있습니다. 또한 AMI를 쉽게 교체 할 수 있습니다. 또한 EBS에는 여전히 성능 문제가 있습니다.

에릭은 거의 그것을 못 박았다. 우리 ( Bitnami )는 널리 사용되는 애플리케이션 및 개발 프레임 워크 (PHP, Joomla, Drupal, 아이디어를 얻음)를위한 인기있는 무료 AMI 공급 업체입니다. EBS 지원 AMI가 S3 지원보다 훨씬 인기가 있다고 말할 수 있습니다. 일반적으로 s3 백업 인스턴스는 분산 된 시간 제한 작업 (예 : 대규모 데이터 처리)에 사용되어 한 시스템에 장애가 발생하면 다른 시스템이 단순히 가동되는 것으로 생각합니다. EBS 지원 AMIS는 로컬로 상태를 유지하고 충돌시 데이터를 사용할 수 있어야하는 웹 또는 데이터베이스 서버와 같은 '전통적인'서버 작업에 사용되는 경향이 있습니다.

내가 언급하지 않은 한 가지 측면은 실행 중에 EBS 지원 인스턴스의 스냅 샷을 생성하여 인프라를 매우 비용 효율적으로 백업 할 수 있다는 사실입니다 (스냅 샷은 블록 기반 및 증분).

나는 나의 마지막 직책에서 Eric과 똑같은 경험을했습니다. 이제는 새 직장에서 마지막 작업에서 수행 한 것과 동일한 프로세스를 수행하고 있습니다 .EBS 백업 인스턴스에 대한 모든 AMI를 다시 빌드하고 32 비트 시스템 (저렴한)이지만 32에서 동일한 AMI를 사용할 수는 없습니다. 64 기계).

EBS 백업 인스턴스는 Amazon AutoScaling API 를 사용할 수있을 정도로 빠르게 시작 되므로 CloudWatch 지표를 사용하여 추가 인스턴스의 시작을 트리거하고이를 ELB (Elastic Load Balancer)에 등록하고 언제 종료 할 수 있습니다 더 이상 필요하지 않습니다.

이러한 종류의 동적 자동 확장은 AWS의 모든 것입니다. IT 인프라의 실제 절감 효과를 누릴 수있는 곳입니다. 이전 s3 "InstanceStore"지원 인스턴스를 사용하여 자동 확장을 수행하는 것은 거의 불가능합니다.

EC2를 직접 사용하기 시작했기 때문에 전문가는 아니지만 Amazon 자체 문서 는 다음과 같이 말합니다.

임시 데이터에는 로컬 인스턴스 스토어를 사용하고 내구성이 더 높은 데이터에는 Amazon EBS 볼륨을 사용하거나 Amazon S3에 데이터를 백업하는 것이 좋습니다.

강조합니다.

웹 호스팅보다 더 많은 데이터 분석을 수행 하므로 웹 사이트의 경우만큼 지속성이 중요하지 않습니다. 아마존 자체의 차별화를 감안할 때 EBS가 모든 사람에게 적합하다고 가정하지는 않습니다.

두 가지를 모두 사용한 후에 다시 무게를 측정하려고 노력할 것입니다.

EBS는 VM의 가상 디스크와 같습니다.

• EBS가 지원하는 내구성있는 인스턴스를 자유롭게 시작하고 중지 할 수 있습니다 (비용 절감)
• 특정 시점에 스냅 샷을 작성하여 특정 시점 백업을 얻을 수 있습니다.
• EBS 스냅 샷에서 AMI를 생성 할 수 있으므로 EBS 볼륨이 새로운 시스템의 템플릿이됩니다.

인스턴스 스토리지는 다음과 같습니다.

• 로컬이므로 일반적으로 더 빠름
• 네트워크에 연결되지 않은 일반적인 경우 EBS I / O는 네트워크 대역폭을 희생합니다 (별도의 EBS 대역폭을 가진 EBS 최적화 인스턴스 제외)
• 초당 I / O IOPS가 제한되어 있습니다. 프로비저닝 된 I / O조차도 수천 IOPS에서 극대화
• 깨지기 쉬운. 인스턴스가 중지 되 자마자 인스턴스 스토리지의 모든 내용이 손실됩니다.

각각을 사용하는 위치는 다음과 같습니다.

• 백업 OS 파티션 및 영구 스토리지 (DB 데이터, 중요 로그, 애플리케이션 구성)에 EBS 사용
• In-process 데이터, 중요하지 않은 로그 및 임시 애플리케이션 상태에 인스턴스 스토리지를 사용하십시오. 예 : 외부 정렬 저장소, 임시 파일 등
• 인스턴스 스토리지는 인스턴스 간 복제 (NoSQL DB, 분산 큐 / 메시지 시스템 및 복제가 포함 된 DB)가있을 때 성능에 중요한 데이터에도 사용될 수 있습니다.
• 시스템간에 공유 된 데이터 : 입력 데이터 세트 및 처리 된 결과 또는 각 시스템에서 라우트 될 때 사용되는 정적 데이터에 S3을 사용하십시오.
• 사전 베이킹 된 시작 가능한 서버에 AMI 사용

대부분의 사람들은 상태 저장 상태이므로 EBS 지원 인스턴스를 사용하도록 선택합니다. 내부에서 실행 및 설치 한 모든 항목이 중지 / 중지 또는 인스턴스 실패 후에도 유지되므로 더 안전합니다.

인스턴스 스토어는 상태 비 저장 상태이므로 인스턴스 장애 상황 발생시 모든 데이터가 포함 된 데이터를 잃어 버립니다. 그러나 인스턴스 볼륨이 VM이 실행중인 물리적 서버에 연결되어 있기 때문에 무료이며 빠릅니다.

이 모든 것을 처음 접하고 실수로 여기에 착륙 한 경우

현재 빠른 시작 섹션의 모든 AMI는 EBS로 백업됩니다.

또한 공식 문서 에는 EBS 와 인스턴스 스토어의 차이점에 대한 좋은 설명이 있습니다.

이 이미지는 거의 요약합니다

여러 인스턴스를 실행하고 예기치 않은 요금 방지를 우선으로 AWS 인스턴스의 예약 된 서비스를 할당하는 경우 인스턴스 스토어를 사용하지 않는 것이 좋습니다 .

EBS 볼륨의 문서 와 j2d3 및 Siddharth Sharma 의 답변 에 설명 된대로 인스턴스 스토어는 원하는 기간 동안 실행될 수 있지만 중지 할 수는 없습니다 . 자동 시작 / 중지 또는 인스턴스 복구로 서비스를 스케줄 할 수 없음을 의미합니다 .

또한 이러한 종류의 체계의 경우 필요한 모든 리소스가 계속 실행 되도록 설계된 EBS Backed on Elastic Beanstalk 를 사용하면 이점이 없습니다 . 항상 중지 한 모든 서비스를 자동으로 다시 시작합니다. 검토 나머지는 모두 사용에 대한 총 비용에서, VPC , EBS 와 ELB를 추가하는 것이 EC2 고전 의 EC2-VPC 와 ELB는 에 달리 최선의 선택 대부분이다 EC2 - 클래식 , 중지 된 인스턴스가 유지 관련 탄성은 IP 주소EBS 볼륨이 자동으로 저장 됩니다.

결론적으로 , 질문의 주요 부분을 취하는 것은 :

EBS는 상대적으로 적은 비용 차이로 더 유용합니다 (중지, 시작, 지속 + 더 빠른 속도).

대답은 예 이지만 인스턴스가 EBS 기반 인 경우 중지 할 수 있습니다. 귀하의 계정에 남아 있으며 청구되지 않습니다 . 볼륨 만 청구 되지만 EBS는 매시간 청구됩니다 . 사용 가능한 모든 유형 중에서 EBS 볼륨 크기 를 조정할 수있는 유연성이 있다고 생각할 수도 있습니다 .

Eric 이 이미 제시 한 이점 외에, 비용 측면에서 S3는 EBS보다 저렴할 수도 있고 그렇지 않을 수도 있음을 알고 있어야합니다 . 동일한 유형의 플랫폼과 애플리케이션 아키텍처 내에서 두 가지 유형의 인스턴스를 항상 계속 실행하면 비용의 차이가 적다는 데 동의합니다 .

시나리오는 저렴한 비용으로 서비스의 응용 프로그램이 실행 그러나 경우, 처리되지 않은 모든 작업을 끌어 와 역할 그들이 받는 VPC / EBS 비아 파이프 라인 또는 람다 짧은 시간 기준 말에서 <하루 1 시간, 할 수없는 때를 instance-store를 사용하면 다른 이야기가 될 것입니다.