AWS EC2 Batch Group

AWS에서는 EC2 인스턴스를 배치할 때 여러 가지 전략을 통해 인프라를 최적화할 수 있습니다. 특히 대규모 워크로드와 데이터 집약적인 작업을 효율적으로 관리하려면 EC2의 배치 방식을 적절히 설정하는 것이 매우 중요합니다.

IPv4와 EC2의 배치 전략

IPv4는 약 37억 개의 서로 다른 주소를 제공하며, 이를 통해 다양한 네트워크 자원을 할당할 수 있습니다. 그러나 EC2 인스턴스가 배치되는 방식에 따라 네트워크 성능과 안정성에 큰 차이가 생길 수 있기 때문에, AWS에서는 특정 목적에 맞춘 EC2 인스턴스 배치 전략을 제공합니다.

1. Cluster Placement Group

: EC2 인스턴스를 하나의 가용 영역(AZ) 내에서 그룹화하여 배치하는 전략입니다.
이를 통해 인스턴스 간의 네트워크 지연 시간을 최소화하고 높은 네트워크 대역폭을 제공합니다.

특징:

• 모든 EC2 인스턴스가 동일한 가용 영역에 위치하여 지연 시간이 매우 짧고, 최대 10Gbps의 네트워크 대역폭을 지원합니다.

장점 (Pros):

• 네트워크 성능이 뛰어나고, 지연 시간이 적어 데이터 전송이 빠릅니다.
• 고성능 컴퓨팅을 필요로 하는 작업에 적합합니다.

단점 (Cons):

• 동일한 가용 영역 내에 배치되기 때문에, 만약 해당 가용 영역에 장애가 발생하면 모든 인스턴스가 영향을 받습니다.

사용 사례 (Use Case):

• 빅 데이터 처리
• 저지연 애플리케이션

2. Spread Placement Group

각각의 EC2 인스턴스가 다른 물리적 하드웨어에 배치되도록 하는 전략입니다. 따라서 여러 가용 영역에 걸쳐 인스턴스를 배치하여 가용성을 높이고, 하드웨어의 장애에 대한 위험을 최소화할 수 있습니다.

특징:

• 인스턴스가 서로 다른 물리적 하드웨어에 배치되어, 동일한 하드웨어 오류로 인해 여러 인스턴스가 동시에 영향을 받는 일이 줄어듭니다.

장점 (Pros):

• 여러 가용 영역(AZ)에 걸쳐 인스턴스를 배치할 수 있어, 인프라의 가용성을 극대화할 수 있습니다.
• 장애 발생 시 리스크를 최소화합니다.

단점 (Cons):

• AZ당 최대 7개의 인스턴스만 배치할 수 있습니다.

사용 사례 (Use Case):

• 고가용성 필요

3. Partition Placement Group

EC2 인스턴스를 여러 가용 영역에 걸쳐 여러 파티션에 분산하여 배치하는 전략입니다. 각 파티션은 독립된 물리적 하드웨어로 구성되어 있어, 특정 파티션에 장애가 발생하더라도 다른 파티션에 있는 인스턴스는 영향을 받지 않습니다.

특징:

• 하나의 파티션에는 여러 개의 물리적 하드웨어가 포함될 수 있으며, 각 파티션은 독립적으로 장애를 격리합니다. 최대 7개의 가용 영역에 걸쳐 인스턴스를 배치할 수 있습니다.

장점 (Pros):

• 파티션 단위로 장애가 격리되어 있어, 특정 파티션의 장애가 전체 시스템에 영향을 미치지 않습니다.

사용 사례 (Use Case):

• 분산 데이터 처리 시스템: HDFS, Kafka, Cassandra와 같이 분산형 데이터베이스나 데이터 처리 시스템에서 활용됩니다. 이러한 시스템은 데이터를 여러 파티션에 걸쳐 분산시키기 때문에, 장애가 발생해도 다른 파티션에서 데이터를 사용할 수 있어 안정적인 운영이 가능합니다.

EC2 Placement Group 전략 선택 가이드

• 저지연 네트워크 성능이 필요한 경우: Cluster Placement Group이 적합합니다.
• 고가용성을 우선시하는 경우: Spread Placement Group을 선택해 인프라 가용성을 극대화할 수 있습니다.
• 데이터 분산 시스템을 운영하는 경우: Partition Placement Group이 시스템 안정성을 확보하는 데 효과적입니다.

ENI(Elastic Network Interfaces)

ENI (Elastic Network Interface)란 무엇인가?

ENI(Elastic Network Interface)는 AWS EC2 인스턴스가 네트워크에 연결할 수 있도록 지원하는 논리적 네트워크 컴포넌트입니다. ENI를 사용하여 네트워크 설정을 유연하게 관리하고 인스턴스 간 네트워크를 통해 데이터를 전송할 수 있습니다. 특히, ENI는 특정 가용 영역에 바운드(bound)되며, 하나의 인스턴스에서 다른 인스턴스로 쉽게 이동할 수 있어 장애조치(failover) 및 고가용성 유지에 유용합니다.

ENI의 주요 구성 요소

1. Primary IPv4 및 Secondary IPv4

• 각 ENI는 하나의 Primary IPv4 주소와 하나 이상의 Secondary IPv4 주소를 포함할 수 있습니다.
• 기본 ENI는 EC2 인스턴스에 연결되는 기본 네트워크 인터페이스이며, Primary IPv4 주소는 이 네트워크 인터페이스에 대한 주요 네트워크 식별자 역할을 합니다.

2. Eth1 및 사설 IP 제공

• ENI에는 추가적으로 사설 IP 주소를 포함할 수 있으며, 이는 Eth1 등의 추가 네트워크 인터페이스를 통해 제공합니다.

3. 공용 IPv4 주소 (Public IPv4)

• ENI는 하나의 공용 IPv4 주소를 추가로 연결할 수 있습니다. 이를 통해 인터넷에서 EC2 인스턴스에 접근할 수 있습니다.

4. 보안 그룹 (Security Group)

• ENI는 하나 이상의 보안 그룹을 적용하여 네트워크 트래픽을 제어할 수 있습니다. 이를 통해 외부 접근을 허용하거나 제한할 수 있습니다.

5. MAC 주소 (MAC Address)

• 각 ENI에는 고유한 MAC 주소가 지정되어 있으며, 이는 네트워크에서 ENI를 식별하는 데 사용됩니다.

ENI의 주요 특징과 장점

• 독립적인 ENI 관리
  ENI는 EC2 인스턴스와 독립적으로 관리될 수 있으며, 인스턴스 간의 장애조치를 위해 필요한 경우 다른 인스턴스에 동적으로 연결할 수 있습니다.

• Failover 지원
  만약 EC2 인스턴스에 문제가 발생하거나 네트워크 연결에 장애가 생긴 경우, ENI를 다른 인스턴스에 연결하여 장애조치를 수행할 수 있습니다. 예를 들어, ENI의 Eth1을 다른 인스턴스에 연결하여 사설 IP 주소를 그대로 유지하면서 네트워크 연결을 복구할 수 있습니다.

• 가용 영역 내 바운드 (Availability Zone Bound)
  ENI는 특정 가용 영역에 바운드되므로, 동일한 가용 영역 내에서 인스턴스 간의 연결을 유지하는 데 적합합니다. 이로 인해 지연 시간이 짧고, 고성능 네트워크를 구성할 수 있습니다.

ENI의 활용 사례

1. 멀티 네트워크 인터페이스 구성
   여러 ENI를 한 인스턴스에 추가하여 다양한 서브넷에 연결하거나 보안 그룹을 다르게 설정할 수 있습니다. 예를 들어, 하나의 ENI는 내부 서브넷에 연결하여 DB 서버에 접근하고, 다른 ENI는 외부 서브넷에 연결하여 인터넷에 접근하는 설정을 할 수 있습니다.

2. 장애조치(failover) 설정
   ENI를 다른 인스턴스로 이동시켜 장애 발생 시 빠르게 연결을 복구할 수 있습니다. 이로 인해 네트워크 연결이 필요한 중요한 애플리케이션에 대해 안정성을 높일 수 있습니다.

3. 애플리케이션의 가용성 확장
   ENI는 고가용성 및 고성능이 요구되는 애플리케이션에 필수적입니다. 인스턴스를 종료하거나 교체할 때 ENI를 그대로 유지하여 네트워크 구성 변경 없이 애플리케이션을 이동할 수 있습니다.

ENI는 AWS 인프라의 유연성과 안정성을 높이는 중요한 컴포넌트로서, 네트워크 인터페이스를 효과적으로 관리하고자 할 때 유용한 도구입니다. 네트워크 설계 시 ENI를 적절하게 활용하면 높은 가용성과 안정성을 유지하면서 효율적인 클라우드 인프라를 구축할 수 있습니다.

EC2 Hibernate 기능

EC2 인스턴스는 일반적으로 Stop과 Terminate 두 가지 상태로 전환될 수 있습니다.

1. Stop: EBS 볼륨의 데이터가 유지됩니다.
2. Terminate: EBS 볼륨을 포함하여 모든 데이터가 삭제됩니다.

하지만 EC2 Hibernate 기능을 사용하면 인스턴스의 메모리 상태를 유지하면서 인스턴스를 중단할 수 있어, 작업을 이어서 빠르게 재개할 수 있습니다.

EC2 Hibernate의 특징

Stop 및 Hibernate 차이

• Stop: 인스턴스를 중지하고 EBS 볼륨의 데이터는 유지되지만, 인스턴스의 RAM 상태는 유지되지 않습니다.
• Hibernate: 인스턴스를 중지하면서 RAM 상태를 유지하여 메모리에 로드된 애플리케이션 및 데이터 상태를 보존합니다.

Hibernate가 작동하는 방식

• RAM 상태가 루트 EBS 볼륨에 파일 형태로 기록됩니다.
• 인스턴스 재시작 시 메모리 상태가 복원되므로 부팅이 빠릅니다.
• 루트 EBS 볼륨은 보안상 암호화되어야 합니다.

인스턴스 부팅 속도

• Hibernate는 OS를 완전히 재부팅하지 않고 메모리 상태를 그대로 복구하기 때문에 인스턴스 부팅 속도가 훨씬 빨라집니다.

Hibernate의 주요 사용 사례

• 장기 실행 작업
  RAM에 저장된 애플리케이션 상태를 유지해야 하는 작업, 특히 자주 초기화하는 데 시간이 걸리는 서비스에 유용합니다.
• 복잡한 초기화 과정이 필요한 애플리케이션
  캐시나 대규모 데이터 로딩 등 초기화에 오랜 시간이 걸리는 애플리케이션에 적합합니다.
• 최대 Hibernate 유지 기간
  인스턴스의 Hibernate 상태는 최대 60일까지 유지 가능합니다.

EC2 Hibernate 기능은 메모리 상태를 보존하면서 중단할 수 있는 유용한 기능으로, 초기화가 오래 걸리는 작업이나 장기 실행 작업에 적합한 솔루션입니다.

EBS Volume

EBS(Elastic Block Store)는 AWS에서 EC2 인스턴스에 연결할 수 있는 네트워크 기반 블록 스토리지입니다. 물리적으로 연결되어 있지 않지만, 네트워크를 통해 EC2와 연결되며 USB 드라이브처럼 데이터를 저장하고 이동할 수 있는 장치입니다. EBS는 인스턴스가 종료된 후에도 데이터를 유지할 수 있어 중요한 데이터를 안전하게 보관할 수 있습니다.

EBS Volume의 주요 특징

• 네트워크 기반 스토리지
  EBS는 물리적 디스크가 아닌 네트워크 드라이브로, 네트워크를 통해 EC2 인스턴스와 연결됩니다.
• 데이터 지속성
  인스턴스가 종료된 후에도 데이터를 지속적으로 보관할 수 있어 데이터를 안전하게 유지할 수 있습니다.
• 단일 연결
  하나의 EBS는 하나의 EC2 인스턴스에만 마운트할 수 있습니다. 여러 인스턴스가 동시에 액세스할 수 없으므로, 특정 가용 영역 내에서만 사용 가능합니다.
• 가용 영역 제한
  EBS 볼륨은 생성된 가용 영역(AZ) 내에서만 사용할 수 있습니다. 예를 들어, us-east-1a에서 생성된 볼륨은 us-east-1b에서 사용할 수 없습니다.
• 무료 등급
  AWS 무료 등급에서는 매달 30GB까지의 GP2 또는 GP3 SSD 스토리지를 무료로 사용할 수 있습니다.

EBS Volume 관리 및 사용

• EC2 간 이동 가능
  EBS 볼륨은 EC2 인스턴스에서 분리(detach) 후, 다른 인스턴스에 빠르게 연결(attach)할 수 있습니다.
• 스냅샷을 통한 복사 및 이동
  EBS 볼륨은 스냅샷 기능을 통해 다른 리전에 복사할 수 있어 데이터 백업 및 이동이 용이합니다.
• 삭제 설정 (Delete on Termination)
  EBS 볼륨은 Delete on Termination 옵션을 통해, 인스턴스 종료 시 볼륨을 자동으로 삭제할지 여부를 설정할 수 있습니다.

EBS Volume은 EC2 인스턴스에 유연하게 연결하고 관리할 수 있는 스토리지 옵션으로, 다양한 환경에서 중요한 데이터 저장에 적합합니다.

EBS Snapshots

EBS Snapshot은 EBS 볼륨의 특정 시점에 대한 백업을 생성하여 데이터를 안전하게 보관할 수 있는 기능입니다. 스냅샷은 AWS 내에서 데이터 백업, 복원, 이동을 효율적으로 지원합니다.

EBS Snapshot의 주요 특징

• 시점 백업
  EBS Snapshot은 볼륨의 특정 시점에 대한 백업을 생성하며, 이는 이후 데이터 복구 시 유용합니다.
• EBS 볼륨 분리 없이 스냅샷 생성 가능
  스냅샷 생성 시 EBS 볼륨을 반드시 분리할 필요는 없지만, 데이터 일관성을 위해 분리한 상태에서 스냅샷을 생성하는 것이 권장됩니다.

EBS Snapshot 관리 옵션

• EBS Snapshot Archive
  스냅샷을 아카이브로 옮겨 보관할 수 있습니다. 이를 통해 저장 비용을 75% 절감할 수 있으며, 데이터를 복원하는 데는 약 24~72시간이 소요됩니다.
• EBS Snapshot Recycle Bin
  실수로 스냅샷을 삭제하는 경우 복구할 수 있도록 Recycle Bin 기능을 제공합니다. 삭제된 스냅샷은 1일~1년 동안 보관할 수 있습니다.
• FSR (Fast Snapshot Restore)
  빠른 스냅샷 복구(FSR)를 통해 대규모 EBS 볼륨이나 ECS 인스턴스를 빠르게 복원할 수 있습니다. 이 기능은 비용이 많이 들지만, 빠른 복구가 필요한 상황에서 유용합니다.

AMI Overview

Amazon Machine Image (AMI)는 EC2 인스턴스를 생성하기 위해 필요한 구성 요소들을 포함한 템플릿으로, AWS에서 EC2 인스턴스를 커스터마이즈하여 저장해 둔 이미지입니다. AMI를 사용하면 운영체제, 소프트웨어, 설정 등을 미리 포함시킬 수 있어 빠른 부팅 및 구성 시간이 가능합니다.

AMI의 주요 특징

• EC2 인스턴스 커스터마이제이션
  AMI는 특정 EC2 인스턴스의 소프트웨어, 설정, 운영체제, 모니터링 등을 포함하여 인스턴스를 원하는 환경으로 커스터마이징할 수 있습니다.
• 빠른 부팅 및 설정 시간
  필요한 소프트웨어가 미리 패키징되어 있어 인스턴스를 더 빠르게 부팅하고 바로 사용할 수 있습니다.
• 리전별 AMI
  AMI는 특정 리전에서만 사용 가능하므로, 다른 리전에서 사용하려면 AMI를 복사해야 합니다.

EC2 인스턴스 생성 시 사용 가능한 AMI 종류

1. Public AMI
   AWS에서 제공하는 기본 AMI로, 공용으로 사용 가능한 운영체제 및 기본 소프트웨어를 포함합니다.
2. Custom AMI
   사용자가 직접 커스터마이징하여 만든 AMI로, 자주 사용하는 환경을 설정하여 저장하고 필요할 때 빠르게 인스턴스를 생성할 수 있습니다.
3. AWS Marketplace AMI
   AWS Marketplace에서 제공하는 상용 소프트웨어와 함께 제공되는 AMI로, 서드파티 소프트웨어나 미리 구성된 환경을 사용할 수 있습니다.

AMI 생성 프로세스

1. EC2 인스턴스 시작
   AMI로 저장할 EC2 인스턴스를 시작하고 필요한 소프트웨어와 설정을 구성합니다.
2. 인스턴스 중지
   AMI 생성 시 데이터를 안전하게 보관하기 위해 인스턴스를 중지합니다.
3. AMI 생성
   중지된 인스턴스를 기반으로 AMI를 생성합니다. 이후 이 AMI를 통해 동일한 설정을 가진 인스턴스를 추가로 생성할 수 있습니다.
4. AMI에서 EC2 인스턴스 시작
   생성된 AMI를 사용하여 동일한 구성을 가진 EC2 인스턴스를 원하는 만큼 시작할 수 있습니다.

AMI는 일관된 환경을 빠르게 배포하고 유지할 수 있는 편리한 도구로, 개발 및 운영 환경의 효율성을 크게 높입니다.

EC2 Instance Store

EC2 Instance Store는 높은 성능의 하드웨어 디스크가 필요한 경우 사용하는 EC2의 임시 스토리지 옵션입니다. EBS와 달리 인스턴스가 중지되면 저장된 데이터가 모두 사라지지만, 빠른 I/O 성능을 제공하므로 고성능이 요구되는 임시 데이터 저장에 적합합니다.

EC2 Instance Store의 주요 특징

• 고성능 하드웨어 디스크
  EBS의 성능이 제한적일 때 EC2 Instance Store를 사용하여 높은 I/O 성능을 필요로 하는 애플리케이션에서 성능을 최적화할 수 있습니다.
• 임시 데이터 저장
  EC2 Instance Store는 임시 데이터를 저장하기에 적합하며, 인스턴스가 중지되면 데이터가 삭제됩니다.
• 사용 사례
  • 버퍼: 대량의 데이터를 처리하기 전 임시로 저장하는 버퍼 역할
  • 캐시(Cache): 데이터베이스나 애플리케이션의 빠른 응답을 위한 캐시
  • 스크래치 데이터(Scratch Data): 분석 작업을 위한 임시 데이터 저장소
  • 임시 콘텐츠(Temporary Content): 장기 보관이 필요 없는 데이터 저장

EC2 Instance Store는 높은 성능을 필요로 하는 임시 데이터 저장에 유용하지만, 중지 시 데이터가 삭제되므로 중요한 데이터는 EBS와 같은 영구 스토리지에 저장하는 것이 좋습니다.

EBS Volume Types

AWS EBS는 다양한 워크로드 요구 사항에 맞춰 6가지 유형의 볼륨을 제공합니다. 각 볼륨 타입은 크기(Size), 처리량(Throughput), IOPS (초당 입출력 작업)에 따라 성능이 결정됩니다. 적합한 볼륨 타입을 선택하여 비용과 성능을 최적화할 수 있습니다.

1. gp2 / gp3 (SSD) - General Purpose SSD

• 설명: 다양한 워크로드에 가격과 성능의 균형을 제공하는 범용 SSD 볼륨
• 특징: gp3는 gp2 대비 더 높은 IOPS와 처리량을 제공하며, gp3는 고정된 가격으로 성능을 조정할 수 있습니다.
• 용도: 범용 워크로드 (예: 개발 및 테스트 환경)

2. io1 / io2 Block Express (SSD) - Provisioned IOPS SSD

• 설명: 미션 크리티컬 작업을 위한 고성능 SSD 볼륨으로, 매우 낮은 지연시간과 높은 처리량을 제공합니다.
• 특징: 초당 수천 IOPS까지 제공하며, io2 Block Express는 최대 수백만 IOPS로 확장 가능
• 용도: 중요한 데이터베이스 및 실시간 애플리케이션 (예: 대규모 트랜잭션 처리)

3. st1 (HDD) - Throughput Optimized HDD

• 설명: 대용량 데이터를 빈번하게 처리하는 작업을 위한 저비용 HDD 볼륨
• 특징: 처리량이 중요한 워크로드에 최적화되어 있으며, 대규모 연속 데이터 읽기/쓰기에 적합
• 용도: 빅 데이터, 로그 처리

4. sc1 (HDD) - Cold HDD

• 설명: 자주 액세스하지 않는 데이터에 대한 가장 저렴한 HDD 볼륨
• 특징: 비용 효율적인 볼륨으로, 크기와 성능이 제한적이지만 비용이 가장 낮습니다.
• 용도: 백업, 아카이브

EBS 볼륨 특성

• 부팅 볼륨: gp2, gp3, io1, io2 Block Express 볼륨만 부팅 볼륨으로 사용할 수 있습니다.
• 성능 특성: 각 볼륨 타입은 크기, 처리량, IOPS에 따라 성능이 달라지므로 워크로드에 적합한 볼륨 타입을 선택하는 것이 중요합니다.

Tip: 볼륨 선택에 어려움이 있으면 AWS 공식 문서를 참고하는 것이 좋습니다.

EBS Multi -Attach - io 1|io 2 family

EBS Multi-Attach는 동일한 EBS 볼륨을 여러 EC2 인스턴스에 동시에 연결할 수 있는 기능으로, 고가용성과 고성능이 요구되는 클러스터형 애플리케이션에 유용합니다. 이를 통해 EC2 인스턴스가 공유된 데이터에 대해 동시 읽기 및 쓰기 권한을 가질 수 있습니다.

EBS Multi-Attach의 주요 특징

• 동시 읽기 및 쓰기 권한
  여러 EC2 인스턴스가 동일한 EBS 볼륨에 대해 완전한 읽기 및 쓰기 권한을 가지며, 고성능의 볼륨에 대해 액세스할 수 있습니다.
• 최대 연결 가능 인스턴스
  하나의 EBS 볼륨을 최대 16개의 EC2 인스턴스에 연결할 수 있습니다.
• 파일 시스템 제한
  EBS Multi-Attach는 특정 파일 시스템에서만 작동합니다. XFS나 EXT4 파일 시스템에서는 지원되지 않으며, 애플리케이션이 동시에 발생하는 쓰기 작업을 직접 관리해야 합니다.

EBS Multi-Attach 사용 사례

• 고가용성 애플리케이션
  클러스터형 리눅스 애플리케이션에서 고가용성을 높이기 위해 여러 인스턴스가 동일한 데이터를 액세스할 수 있도록 설정합니다.
• 동시 쓰기 작업을 처리하는 애플리케이션
  EBS Multi-Attach는 여러 애플리케이션이 동시에 데이터를 읽고 쓸 수 있지만, 각 애플리케이션이 동시 쓰기 작업을 관리할 수 있어야 합니다.

EBS Encryption

EBS Encryption은 EBS 볼륨의 데이터를 보호하기 위해 데이터를 암호화하는 기능입니다. 암호화된 EBS 볼륨은 데이터 보안을 강화하며, 암호화된 상태에서도 성능에 미치는 영향이 최소화됩니다.

EBS Encryption의 주요 특징

• 데이터 암호화 (Data at Rest)
EBS 볼륨에 저장된 모든 데이터는 저장 중 암호화됩니다. 볼륨에 저장된 데이터는 AWS의 KMS(Key Management Service)에서 제공하는 키를 사용하여 암호화됩니다.
• 전송 중 데이터 암호화 (Data in Transit)
EC2 인스턴스와 EBS 볼륨 간에 전송되는 데이터도 암호화되어 전송됩니다.
• 스냅샷 암호화
암호화된 EBS 볼륨의 모든 스냅샷도 자동으로 암호화되며, 스냅샷을 통해 생성된 새로운 볼륨 역시 암호화 상태를 유지합니다.
• 성능 영향 최소화
EBS 암호화는 지연 시간에 거의 영향을 주지 않으므로, 높은 성능을 유지하면서 데이터를 안전하게 보호할 수 있습니다.

기존 EBS 볼륨 암호화 (Encryption of Unencrypted EBS Volume)

기존의 암호화되지 않은 EBS 볼륨을 암호화하려면 다음과 같은 단계를 수행합니다:

1.	EBS 볼륨의 스냅샷 생성

암호화하려는 EBS 볼륨의 스냅샷을 생성합니다.
2. 스냅샷 암호화
생성된 스냅샷을 복사하면서 암호화 옵션을 활성화하여 스냅샷을 암호화합니다.
3. 암호화된 볼륨 생성
암호화된 스냅샷을 사용하여 새 EBS 볼륨을 생성합니다. 이 볼륨은 암호화된 상태로 생성됩니다.
4. 암호화된 볼륨 연결
생성된 암호화된 볼륨을 기존 인스턴스에 연결하여 사용할 수 있습니다.

EBS Encryption은 데이터를 안전하게 보호할 수 있는 강력한 보안 옵션으로, KMS와 연계하여 데이터의 암호화를 효과적으로 관리할 수 있습니다.

Amazon EFS (Elastic File System)

Amazon EFS는 AWS에서 관리하는 네트워크 파일 시스템(NFS)으로, 다수의 EC2 인스턴스에서 동시에 마운트하여 사용할 수 있는 고가용성과 확장성을 제공하는 스토리지 솔루션입니다. 주로 콘텐츠 관리, 웹 서버, 데이터 공유, WordPress와 같은 애플리케이션에 사용되며, Linux 기반 AMI에서만 호환됩니다.

Amazon EFS 주요 특징

• 고가용성 및 확장성
EFS는 여러 가용 영역(AZ)에 걸쳐 작동하며, 성능이 자동으로 확장되어 동시 사용자가 많아질수록 자동으로 확장됩니다. 비용은 사용량에 따라 지불됩니다.
• Encryption at Rest
EFS는 KMS(Key Management Service)를 사용하여 데이터를 암호화합니다.
• POSIX 호환 파일 시스템
표준 파일 API를 지원하는 POSIX 파일 시스템으로, 여러 EC2 인스턴스가 파일 시스템을 쉽게 공유할 수 있습니다.

EFS 성능 모드

1. 성능 모드 (Performance Mode)
   • General Purpose (기본): 지연 시간이 중요한 워크로드에 적합
   • Max I/O: 높은 지연 시간이 허용되지만 높은 처리량과 병렬 작업이 필요한 경우에 적합
2. 처리량 모드 (Throughput Mode)
   • Bursting: 기본 제공되는 처리량 (1TB당 50MiB/s)과 최대 100MiB/s까지 버스트 가능
   • Provisioned: 스토리지 크기와 상관없이 지정된 처리량 설정 가능
   • Elastic: 워크로드에 따라 처리량이 자동으로 조정되며, 최대 3GiB/s 읽기 및 1GiB/s 쓰기 지원

EFS 스토리지 티어

• Standard: 자주 액세스하는 파일을 위한 기본 스토리지
• Infrequent Access: 덜 자주 접근하는 파일을 위한 비용 효율적인 스토리지
• Archive: 장기 보관 파일을 위한 최저 비용 스토리지
• 라이프사이클 관리: 파일을 일정 기간 이후에 더 저렴한 스토리지 티어로 자동 이동할 수 있도록 설정 가능

EFS와 EBS 비교

Amazon EFS는 확장성이 뛰어나고 여러 인스턴스에서 동시에 사용할 수 있는 네트워크 파일 시스템으로, 주로 파일 공유와 웹 콘텐츠에 적합하며, AWS 내 다양한 스토리지 옵션과 비교하여 각기 다른 요구 사항에 맞게 선택할 수 있습니다.

문제9

기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있습니다. 어떤 방법을 추천할 수 있을까요?

• EBS **gp2** 드라이브 사용
• EBS io1 드라이브 사용
• EC2 인스턴스 스토어 사용
• EBS io2 Block Express 드라이브 사용
• EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실이라는 문제가 있습니다 (문제 없이 다시 시작할 수 있음). 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 메커니즘을 설정하여 대기 복사본을 가질 수 있다는 것입니다. 또 다른 솔루션은 데이터에 대한 백업 메커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있습니다. 이 사용 사례에서는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 합니다.