Data Science Lab

[AWS Aurora] Aurora Global Database를 사용한 Cross-Region 장애조치

l  Version : AWS Aurora

Amazon Aurora Global Database는 여러 AWS 리전에 걸쳐 있고 대기 시간이 짧은 글로벌 읽기를 지원하기 때문에, 전세계 지역에서 실행되는 애플리케이션들은 가까운 리전의 Aurora Global Database에서 서비스를 제공받기 때문에 안정적이며 빠른 서비스를 제공할 수 있다. 또한 Aurora Global Database는 데이터를 마스터링하는 하나의 기본 AWS 리전 및 최대 5개의 읽기 전용 보조 AWS 리전으로 구성되기 때문에, AWS 리전에서 장애 발생시 신속하게 다른 리전으로 복구할 수 있다.  Aurora Global Database는 아래와 같은 장점을 가지고 있다.

l  로컬 대기 시간으로 글로벌 읽기 : 전 세계에 지사를 두고 있는 경우, Aurora Global Database를 사용하여 기본 AWS 리전에서 정보의 주요 소스를 최신 상태로 유지할 수 있다. 다른 리전의 사무실은 로컬 지연 시간을 사용하여 해당 리전의 정보에 액세스할 수 있다.

l  확장 가능한 보조 Aurora DB 클러스터 : AWS 리전에 읽기 전용 인스턴스(Aurora 복제본)를 추가하여 보조 클러스터를 확장할 수 있다. 세컨더리 클러스터는 읽기 전용이므로 단일 Aurora 클러스터에 대하여 일반적인 제한인 15개가 아닌 최대 16개의 읽기 전용 Aurora 복제본 인스턴스를 지원할 수 있다.

l  기본 DB클러스터에서 보조 Aurora DB 클러스터로의 빠른 복제 : Aurora Global Database에서 수행되는 복제는 기본 DB 클러스터의 성능에 거의 영향을 미치지 않는다. DB 인스턴스의 리소스는 애플리케이션 읽기/쓰기 워크로드 처리 전용이다.

l  리전 전체의 운영 중단으로부터 복구 : 보조 클러스터를 사용하면 기존 복제 솔루션보다 적은 데이터 손실(더 낮은 RPO)로 새로운 기본 AWS 리전에서 Aurora Global Database를 보다 신속하게(더 낮은 RTO) 가용 상태로 만들 수 있다.

Aurora Global Database는 한 리전의 기본(Primary) Aurora 클러스터와 다른 리전의 보조(Secondary) Aurora 클러스터로 생성된다. Aurora 글로벌 데이터베이스는 Aurora 전용 스토리지 계층의 전용 인프라를 사용하여 리전 간 복제를 처리한다. 스토리지 계층의 전용 복제 서버가 복제를 처리하므로 시스템 로드 중에도 데이터베이스 성능을 저하시키지 않으면서 향상된 복구 및 가용성 목표를 달성할 수 있다. Aurora Global Database는 물리적 스토리지 수준 복제를 사용하여 동일한 데이터 세트로 기본 데이터베이스의 복제본을 생성하므로 논리적 복제 프로세스에 대한 종속성이 제거된다. 아래 그림은 기본(Primary) 및 보조(Secondary) 리전에 걸쳐 있는 Aurora 클러스터가 있는 Aurora 글로벌 데이터베이스이다.

Aurora Global Database복제과정은 아래와 같다.

1.       Aurora 클러스터의 기본 인스턴스는 Primary 리전의 스토리지 노드, 복제본 인스턴스 및 복제 서버에 병렬로 로그 레코드를 보낸다.

2.       Primary 리전의 복제 서버는 로그 레코드를 Secondary 리전의 복제 에이전트로 스트리밍한다.

3.       복제 에이전트는 Secondary 리전의 스토리지 노드 및 복제본 인스턴스에 병렬로 로그 레코드를 보낸다.

4.       Secondary 리전의 복제 서버는 스토리지 노드에서 로그 레코드를 가져와 동기화 한다.

Aurora 스토리지 시스템은 단일 리전 내의 3개 가용 영역에 걸쳐 6개의 데이터 복사본을 자동으로 유지 관리하고 데이터 손실 없이 정상적인 가용 영역에서 데이터베이스 복구를 자동으로 시도하므로 내구성과 가용성이 크게 향상된다. 쓰기 쿼럼은 6개 복사본 중 4개의 승인이 필요하고 읽기 쿼럼은 보호 그룹의 6개 구성원 중 3개이다. 데이터는 최종 사용자에 대한 성능 영향 없이 실시간으로 Aurora를 사용하여 Amazon Simple Storage Service(Amazon S3)에 지속적으로 백업된다.

아래 그림은 기본 리전에서 여러 보조 리전으로 물리적 스토리지 수준 아웃바운드 복제가 있는 Aurora 글로벌 데이터베이스를 나타낸다.

Aurora 글로벌 데이터베이스를 사용하여 각 보조 리전에서 최대 5개의 보조 리전과 최대 16개의 읽기 전용 복제본을 구성할 수 있다. 각 보조 클러스터는 기본 클러스터 및 다른 보조 클러스터와 다른 리전에 있어야 한다.

Aurora 글로벌 데이터베이스를 사용하면 장애조치에 대한 두 가지 접근 방식 중에서 선택할 수 있다.

l  관리형 계획 장애조치 : 기본 DB 클러스터를 Aurora 글로벌 데이터베이스의 보조 리전 중 하나로 재배치 한다. 이 기능을 사용하면 RPO가 0(데이터 손실 없음)이고 다른 변경을 수행하기 전에 보조 DB 클러스터를 기본 클러스터와 동기화한다. 이 자동화된 프로세스의 RTO는 일반적으로 수동 장애조치의 RTO보다 적다.

l  계획되지 않은 수동 장애조치 : 계획되지 않은 중단에서 복구하기 위해 Aurora 글로벌 데이터베이스의 보조 데이터베이스 중 하나로 교차 리전 장애조치를 수동으로 수행할 수 있다. 이 수동 프로세스의 RTO는 계획되지 않은 중단에서 Aurora 글로벌 데이터베이스를 얼마나 빨리 수동으로 복구할 수 있는지에 따라 다르다. RPO는 일반적으로 초 단위로 측정되지만 오류 발생 시 네트워크 전체의 Aurora 스토리지 복제 지연에 따라 다르다.

 Aurora Global Database사용시 수동 장애조치가 어떻게 이루어지는지 살펴보자.

기본 리전에서 Writer 인스턴스에서 읽기 및 쓰기를 수행하고 읽기 전용 복제본에서만 읽기를 수행하는 Aurora 클러스터에 연결된 애플리케이션과 보조 리전에서 읽기 전용 복제본에서 읽기만 수행하는 Aurora 클러스터에 연결된 애플리케이션이 있다. Amazon Route 53 (CNAME 레코드)은 장애조치 및 재구성으로 인해 애플리케이션을 다시 연결하기 위해 수행해야 하는 수동 작업의 양을 최소화하기 위해 Aurora 리더 및 라이터 엔드포인트를 가리키도록 생성된다.

전체 지역의 인프라 또는 서비스를 기본 지역에서 사용할 수 없게 되거나, 잠재적은 성능 저하 또는 격리 문제가 발생할 경우, 보조 클러스터를 기본 클러스터로 승격하도록 수동으로 장애조치를 시작하거나 스크립트를 작성할 수 있다. 장애조치 시 RPO에 의해 수량화된 잠재적 데이터 손실을 이해할 수 있어야 한다.

장애조치가 완료되면 승격된 리전(이전 보조 리전)이 새로운 기본 Aurora 클러스터 역할을 하며 1분 이내에 전체 읽기 및 쓰기 워크로드를 처리할 수 있으므로 애플리케이션 가동 시간에 대한 영향이 최소화된다. 이전 기본 리전의 인프라 또는 서비스를 사용할 수 있게 되거나 리전을 추가하면 계획되지 않은 중단 중에 애플리케이션에서 읽기 워크로드만 가져오는 새로운 보조 Aurora 클러스터 역할을 할 수 있다.

[참고자료]

l  Amazon Aurora Global Database  : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html

l  Cross-Region disaster recovery using Amazon Aurora Global Database for Amazon Aurora PostgreSQL : https://aws.amazon.com/blogs/database/cross-region-disaster-recovery-using-amazon-aurora-global-database-for-amazon-aurora-postgresql/

2022-07-24 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Global Database, Cross-Region Replication, 오로라 글로벌 데이터베이스, 글로벌 장애조치

[AWS Aurora] Aurora 스토리지 특징 요약

l  Version : AWS Aurora

Amazon Aurora 스토리지는 SSD(Solid State Drive)를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장된다. 클러스터 볼륨은 동일한 AWS 리전에 속한 세 가용 영역의 데이터 사본으로 구성되어 있다.

l  Aurora Storage Engine : https://sungwookkang.com/1488

가용 영역에서 데이터는 자동으로 복제되기 때문에 디스크 결함으로 인한 데이터 손실 가능성을 최소화 한다. 또한 클러스터 볼륨을 구성하는 디스크 볼륨에서 장애를 자동으로 감지한다. 예를 들어 볼륨 세그먼트에 결함이 발생하면 Aurora가 즉시 해당 세그먼트를 복구한다. Aurora가 디스크 세그먼트를 복구할 때는 동일한 클러스터 볼륨을 구성하는 나머지 디스크 볼륨의 데이터를 사용하기 때문에 복구 세그먼트의 데이터도 이용 가능하다. 결과적으로 Aurora는 데이터 손실을 방지할 뿐만 아니라 특정 시점으로 복구 기능을 사용해 디스크 결함을 복구할 필요성도 줄어든다. 복제 양은 클러스터의 DB 인스턴스 수와 관계없다.

Aurora 클러스터 볼륨에는 모든 사용자 데이터, 스키마, 객체, 내부 메타데이터(시스템 테이블, 바이너리 로그 등)가 포함되어 있다. Aurora 공유 스토리지 아키텍처는 데이터를 클러스터의 DB 인스턴스와 독립적으로 만든다. 즉 DB 인스턴스를 추가할 때 새 복사본을 만들지 않으므로 빠르게 추가가 가능하다. 대신에 DB 인스턴스는 이미 모든 데이터를 포함하는 공유 볼륨에 연결된다. 클러스터에서 기본 데이터를 제거하지 않고 클러스터에서 DB 인스턴스를 제거할 수 있다. 전체 클러스터를 삭제하는 경우에만 Aurora가 데이터를 제거한다.

데이터베이스의 용량이 늘어날수록 Aurora 클러스터 볼륨도 자동 확장된다. Aurora 클러스터 볼륨의 최대 크기는 DB 엔진 버전에 따라 128TiB 또는 64TiB까지 확장될 수 있지만 요금은 사용한 공간에 대해서만 청구된다. Aurora 데이터가 제거되면 해당 데이터에 할당된 공간을 재사용 하게 된다. 데이터 제거의 예로는 테이블 삭제 또는 자르기 등이 있다. 이렇게 스토리지 사용량이 자동으로 줄어들면 스토리지 요금을 최소화 할 수 있다. 하지만 이미 할당된 공간이 축소된 것은 아니다.  Aurora MySQL 2.09.0 및 1.23.0, Aurora PostgreSQL 3.3.0 및 2.6.0 부터는 테이블이나 데이터베이스를 삭제하는 등의 방법으로 Aurora 데이터가 제거되면 비슷한 양만큼 할당된 전체 공간이 감소한다.

여기서 주의할 점은 임시테이블의 데이터는 로컬 DB 인스턴스에 저장되며 최대 크기는 사용하는 인스턴스 클래스에 따라 다르다.

Aurora는 전원이 꺼진 데이터베이스를 가동하거나 결함 발생 이후 다시 시작할 때 버퍼 풀 캐시를 워밍한다. 즉 Aurora가 인메모리 페이지 캐시에 저장된 기존 공통 쿼리 페이지를 이용해 버퍼풀을 미리 로드한다. 이 경우 웜업을 우회할 수 있기 때문에 성능이 향상되는 이점이 있다. Aurora 페이지 캐시는 데이터베이스가 아닌 별도 프로세스로 관리되기 때문에 데이터베이스와 상관없이 유지된다.  자세한 내용은 아래 링크를 참고 한다.

l  InnoDB Cache warming : https://sungwookkang.com/1486

[참고자료]

l  Amazon Aurora 스토리지 및 안정성 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.StorageReliability.html

l  InnoDB Cache warming : https://sungwookkang.com/1486

l  Aurora Storage Engine : https://sungwookkang.com/1488

2022-07-11 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Storage, 오로라 스토리지

[AWS Aurora] Aurora DB 클러스터 엔드포인트 연결 종류 4가지

l  Version : AWS Aurora

Amazon Aurora DB Cluster는 하나 이상의 DB 인스턴스와 이 DB 인스턴스의 데이터를 관리하는 클러스터 볼륨으로 구성된다. Aurora 클러스터 볼륨은 다중 가용 영역을 아우르는 가상 데이터베이스 스토리지 볼륨으로 각 가용 영역에는 DB 클러스터 데이터의 사본이 있다.

l  기본 DB 인스턴스 : 읽기 및 쓰기 작업을 지원하고 클러스터 볼륨의 모든 데이터 수정을 실행한다. Aurora DB 클러스터마다 기본 DB 인스턴스가 하나씩 있다.

l  Aurora 복제본 : 기본 DB 인스턴스와 동일한 스토리지 볼륨에 연결되며 읽기 작업만 지원한다. 각 Aurora DB 클러스터는 기본 DB 인스턴스에 대해 최대 15개 까지의 Aurora 복제본을 구성할 수 있다. Aurora DB 기본 인스턴스를 사용할 수 없는 경우 자동으로 Aurora 복제본으로 자동 장애조치 한다.

 Amazon Aurora는 일반적으로 단일 인스턴스 대신에 DB 인스턴스 클러스터와 관련된다. 각 연결은 특정 DB 인스턴스에서 처리한다. Aurora 클러스터에 연결하면 지정한 호스트 이름과 포트가 엔드포인트(endpoint)라는 중간 핸들러를 가리킨다. Aurora는 엔드포인트 메커니즘을 사용하여 연결을 추상화 한다. 따라서 일부 DB 인스턴스를 사용할 수 없을 때 모든 호스트 이름을 하드코딩 하거나, 연결을 다시 라우팅하고 로드 밸런싱을 하기 위한 자체 로직을 작성할 필요가 없다.

Aurora 엔드포인트 유형에는 클러스터 엔드포인트, 리더 엔드포인트, 사용자 지정 엔드포인트, 인스턴스 엔드포인트로 네 가지 종류가 있다. 각 엔드포인트에 대한 특징을 살펴보자.

[클러스터 엔드포인트 (Cluster endpoint)]

Aurora DB 클러스터의 클러스터 엔드포인트(또는 Writer endpoint)는 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결된다. DDL 문 등의 쓰기 작업을 수행할 수 있는 유일한 엔드포인트 이다. 각 Aurora DB클러스터에는 클러스터 엔드포인트 하나와 기본 DB 인스턴스 하나가 있다. 삽입, 업데이트, 삭제 및 DDL 변경을 비롯하여 DB의 모든 쓰기 작업에 대해 클러스터 엔드포인트를 사용한다. 또한 읽기 작업에도 클러스터 엔드포인트를 사용할 수 있다. 클러스터 엔드포인트는 장애조치를 지원한다. 아래는 Aurora MySQL DB 클러스터의 엔드포인트를 나타낸 예제이다.

장애조치 메커니즘에서 새 DB 인스턴스가 클러스터의 읽기/쓰기 기본 인스턴스가 되도록 승격하면 클러스터 엔드포인트가 가리키는 물리적 IP 주소가 변경된다. 어떤 형식의 연결 풀링이나 기타 멀티플렉싱을 사용하는 경우, 캐싱된 DNS 정보의 TTL(Time To Live)을 플러시 하거나 줄이도록 준비한다. 이렇게 하면 사용할 수 없게 되었거나 장애 조치 후 이제 읽기 전용인 DB 인스턴스에 읽기/쓰기 연결 설정을 시도하지 않아도 된다.

[리더 엔드포인트 (Reader endpoint)]

Aurora DB 클러스터의 리더 엔드포인트는 DB 클러스터에 대한 읽기 전용 연결시 로드 밸런싱을 지원한다. 읽기 작업에 대한 요청을 복제본에서 처리하기 때문에 기본 인스턴스에 대한 오버헤드를 줄일 수 있다. 또한 클러스터의 Aurora 복제본 수에 비례하여 동시에 SELECT 쿼리를 처리할 수 있도록 용량을 확장할 수 있다. 각 Aurora DB 클러스터에는 리더 엔드포인트가 1개씩 있다. 클러스터에 하나 이상의 Aurora 복제본이 포함된 경우 리더 엔드포인트는 Aurora 복제본 사이의 각 연결 요청을 로드 밸런싱 한다. 이 경우 해당 세션의 SELECT 와 같은 읽기만 실행할 수 있다. 클러스터에 기본 인스턴스만 있고 Aurora 복제본이 없는 경우 리더 엔드포인트는 기본 인스턴스에 연결한다. 이 경우 엔드포인트를 통해 쓰기 작업을 수행할 수 있다. 아래는 Aurora MySQL DB 클러스터의 리더 엔드포인트를 나타낸 예제이다.

RDS Proxy를 통해서도 Aurora 클러스터용 추가 읽기 전용 엔드포인트를 생성할 수 있다. 이러한 엔드포인트는 Aurora 리더 엔드포인트와 동일한 종류의 로드밸랜싱을 수행한다.

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

[사용자 지정 엔드포인트 (Customer endpoint)]

Aurora 클러스터의 사용자 지정 엔드포인트는 선택한 DB 인스턴스 집합을 나타낸다. 엔드포인트에 연결하면 Aurora가 로드 밸런싱을 수행하고 그룹에서 연결을 처리할 인스턴스 중 하나를 선택한다. 이 엔드포인트가 참조하는 인스턴스를 정의하고, 이 엔드포인트가 어떤 목적으로 사용되는지 결정한다. 사용자 지정 엔드포인트는 클러스터를 생성할 때 자동으로 생성되지 않으며, 프로비저닝된 각 Aurora 클러스터에 대해 최대 5개의 사용자 지정 엔드포인트를 만들 수 있다. Aurora Serverless 클러스터에는 사용자 지정 엔드포인트를 사용할 수 없다.

사용자 지정 엔드포인트는 DB 인스턴스의 읽기 전용 기능 또는 읽기/쓰기 기능 이외의 다른 조건을 기반으로 로드 밸런싱된 데이터베이스 연결을 제공한다. 예를 들어 특정 AWS 인스턴스 클래스 또는 특정 DB 파라메터 그룹을 사용하는 인스턴스에 연결할 사용자 지정 엔드포인트를 정의할 수 있다. 또는 보고서 생성 등과 같은 일회성 쿼리 같은 것을 저용량의 내부 서버로 보내고, 고용량 인스턴스로는 프로덕션 트래픽을 보낼 수 있다.

사용자 지정 엔드포인트와 연결된 모든 DB인스턴스로 연결이 이동할 수 있기 때문에 해당 그룹내의 모든 DB 인스턴스가 일부 유사한 특성을 공유하는지 확인하는 것이 좋다. 그렇게 하면 성능, 메모리 용량 등이 해당 엔드포인트에 연결하는 모든 사람에게 일관되도록 보장할 수 있다. 이 기능은 모든 Aurora 복제본을 동일한 클러스터에 유지하는 것이 적절하지 않은 특수한 종류의 워크로드가 있는 고급 사용자를 위한 것으로 사용자 지정 엔드포인트를 통해 각 연결에 사용되는 DB 인스턴스를 예측할 수 있다. 사용자 지정 엔드포인트를 사용할 경우 일반적으로 해당 클러스터에 리더 엔드포인트를 사용하지 않는다. 아래는 Aurora MySQL DB 클러스터의 사용자 지정 엔드포인트를 나타낸 예제이다.

사용지 지정 엔드포인트의 이름은 최대 63글자 까지 가능하다. 사용자 지정 엔드포인트 이름에는 클러스터 이름이 포함되지 않기 때문에, 클러스터 이름을 바꿀 경우 엔드포인트 이름을 변경할 필요가 없다. 동일한 리전에 있는 둘 이상의 클러스터에 동일한 사용자 지정 엔드포인트 이름을 재사용할 수 없다. 각 사용자 지정 엔드포인트에 특정 리전 내의 사용자 ID가 소유한 클러스터 전체에서 고유한 이름을 부여한다. 장애 조치 또는 승격으로 인해 DB 인스턴스가 기본 인스턴스와 Aurora 복제본 간에 역할을 변경해도 Aurora는 정적 목록 또는 제외 목록에 지정된 DB 인스턴스를 변경하지 않는다. 예를 들어 READER 유형의 사용자 지정 엔드포인트에는 Aurora 복제본 이었다가 이후 기본 인스턴스로 승격된 DB 인스턴스가 포함될 수 있다. 사용자 지정 엔드포인트 유형 (READER, WRITER 또는 ANY)에 따라 해당 엔드포인트를 통해 수행할 수 있는 작업의 종류가 결정된다. Aurora 복제본을 사용할 수 없게 된 경우에도 사용자 지정 엔드포인트와는 연결된 상태로 유지된다. 예를 들어 이상이 있거나, 중지되었거나, 재부팅 되더라도 사용자 지정 엔드포인트의 일부로 유지된다. 그러나 클러스터가 다시 사용할 수 있게 될 때까지 기존 엔드포인트를 통해 연결할 수 없다.

[인스턴스 엔드포인트 (Instnace  endpoint)]

인스턴스 엔드포인트는 Aurora 클러스터에 있는 특정 DB 인스턴스에 연결된다. DB 클러스터의 DB 인스턴스에는 각각 고유한 인스턴스 엔드포인트가 있다. 그러므로 DB 클러스터의 현재 기본 DB 인스턴스에 대해 인스턴스 엔드포인트 하나가 있고, DB 클러스터의 각 Aurora 복제본마다 인스턴스 엔드포인트 하나가 있다.  클러스터 엔드포인트 또는 리더 엔드포인트의 사용이 부적합한 시나리오에서 인스턴스 엔드포인트가 DB 클러스터에 대한 연결을 직접 제어한다. 예를 들어 어플리케이션에서 워크로드 유형에 따라 더욱 세분화된 로드 밸런싱이 필요할 경우 각 애플리케이션 속성에 따라 각기 다른 Aurora 복제본에 연결한 후 읽기 워크로드를 분산 시킬 수 있다. 아래는 Aurora MySQL DB 클러스터의 DB 인스턴스 엔드포인트 예제이다.

고가용성이 중요한 클러스터의 경우 라이터 엔드포인트를 읽기/쓰기 또는 범용 연결에 사용하고 리더 엔드포인트를 읽기 전용 연결에 사용한다. 라이터 및 리더 엔드포인트는 인스턴스 엔드포인트보다 DB 인스턴스 장애조치를 더 잘 관리한다. 인스턴스 엔드포인트와 달리 라이터 및 리더 엔드포인트는 클러스터의 DB 인스턴스를 사용할 수 없게 되면 연결된 DB 인스턴스를 자동으로 변경한다. 인스턴스 엔드포인트 연결을 관리하는 자체 애플리케이션 로직을 설계하는 경우, DB 인스턴스의 결과 집합을 수동으로 또는 프로그래밍 방식으로 가져올 수 있다. 그런 다음 장애 조치 이후 인스턴스 클래스를 확인하고 해당 인스턴스 엔드포인트에 연결하면 된다.

[참고자료]

l  Amazon Aurora DB 클러스터 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html

l  Amazon Aurora 연결관리 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Endpoints.html

l  Amazon RDS Proxy 엔드포인트 : https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/rds-proxy-endpoints.html#rds-proxy-endpoints-reader

2022-07-10 / Sungwook Kang / http://sungwookkang.com

AWS, Aurora, Aurora Connection Management, Aurora 클러스터 연결, 오로라 클러스터 연결, 오로라 엔드포인트, Aurora endpoint

[AWS EBS] EBS 다중 연결을 사용하여 여러 인스턴스 연결

l  Version : AWS EBS

AWS EC2에는 여러 개의 EBS 볼륨 스토리지를 연결하여 데이터를 쓸 수 있다. 그렇다면 반대로 하나의 EBS 볼륨에 여러 개의 EC2 인스턴스를 연결할 수는 없을까? 결로부터 말하자면 가능하다.

Amazon EBS 다중 연결을 사용하면 단일 프로비저닝된 IOPS SSD(io1, io2) 볼륨을 동일한 가용 영역에 있는 여러 인스턴스에 연결할 수 있다. 볼륨이 연결된 각 인스턴스는 공유된 볼륨에 대한 전체 읽기 및 쓰기 권한을 가진다. 다중 연결을 사용하면 동시 쓰기 작업을 관리하는 클러스터링 된 Linux 애플리케이션에서 더 쉽게 더 높은 애플리케이션 가용성을 얻을 수 있다. 다중 연결 지원 볼륨은 다른 Amazon EBS 볼륨을 관리하는 것과 거의 동일한 방식으로 관리할 수 있으며 새 연결을 만들 때  기능을 활성화 해야 한다.

하지만 다중 연결에 대한 일부 제약사항이 있다.

l  다중 연결 지원 볼륨은 최대 16개의 Nitro 시스템 기반 Linux에 연결할 수 있다.

l  다중 연결 지원 볼륨은 Windows에서도 사용은 가능하지만 인스턴스 간에 공유되는 볼륨의 데이터를 인식하지 못해 데이터 불일치가 발생할 수 있다.

l  XFS 및 EXT4 와 같은 표준 파일 시스템은 EC2 인스턴스와 같은 여러 서버에서 동시에 액세스 하도록 설계되지 않았다. 따라서 표준 파일 시스템에서 다중 연결을 사용하면 데이터가 손상될 가능성이 있기 때문에 프로덕션의 안정성을 보장할 수 없다.

l  다중 연결 지원 볼륨은 I/O 차단 기능을 제공하지 않아 일관성을 유지하기 위해 공유된 스토리지 환경에서 쓰기 액세스를 제어 해야한다. 애플리케이션은 데이터 일관성 유지하기 위해 연결된 인스턴스에 쓰기 순서를 제공해야 한다.

l  다중 연결 지원 볼륨은 부팅 볼륨으로 만들 수 없다.

l  다중 연결 지원 볼륨은 인스턴스당 하나의 블록 디바이스 매핑에 연결할 수 있다.

l  인스턴스 시작중에는 Amazon EC2 콘솔 또는 RunInstnace API를 사용하여 다중 연결을 활성화 할 수 없다.

l  Amazon EBS 인프라 계층에 문제가 있는 다중 연결 지원 볼륨은 연결된 모든 인스턴스에서 사용할 수 없다.

l  Amazon EC2 또는 네트워킹에 문제가 있는 경우 연결된 일부만 영향을 받을 수 있다.

[참고자료]

l  https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/ebs-volumes-multi.html

2022-06-17 / Sungwook Kang / http://sungwookkang.com

AWS, EBS, 다중 연결 지원 볼륨, EC2