Amazon Aurora DB - AWS RDS Aurora MySQL(3)

Last Updated on 6월 16, 2021 by 태랑(정현호)


해당 글은 아래 이전 글에서 이어지는 글 입니다.




1. Aurora 파라미터 그룹

이전 포스팅에서 생성한 Amazon Aurora 클러스터의 파라미터를 변경을 진행하도록 하겠습니다. 기본 파라미터 그룹에서는 수정이 불가함으로 사용하면서 파라미터 수정할 경우는 언제든지 있을수 있기 때문에 먼저 파라미터 그룹 생성 및 적용하는 것이 좋습니다.

[참고] 기본 파라미터 그룹에서 파라미터 수정을 하게 되면 아래와 같이 에러가 발생되게 됨으로 별도로 파라미터 그룹의 생성이 필요 합니다.

저장 중 오류: Cannot modify a default parameter group. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 7568ef90-8edd-468f-b348-3fc8797d64ae; Proxy: null)



1-1 파라미터 그룹 생성

파라미터 그룹 -> 파리미터 그룹 생성 을 선택 합니다.




1-2 정보 입력 및 그룹 생성

파라미터 그룹 이름과 설명을 입력 후 하단의 생성을 선택 합니다.  
"유형" 항목에서는 "DB Parameter Group" 과 "DB Cluster Parameter Group" 을 선택 할 수 있으며 설명은 아래에 기술하도록 하겠으며 포스팅에서는 "DB Cluster Parameter Group" 으로  생성하도록 하겠습니다



DB 클러스터 파라미터 그룹 과 DB 파라미터 그룹의 차이는 적용 범위에서 차이가 발생하게 됩니다. 

DB Cluster Parameter Group 은 클러스터내 모든 Aurora DB 인스턴스에 공통적으로 적용되는 파라미터 그룹의 역할을 하게 되며 파라미터의 기본값도 포함되어 있습니다. 

DB Parameter Group 은 클러스터내 각 개별의 Aurora 단일 DB 인스턴스의 파라미터 그룹을 의미 합니다. 특정 인스턴스에만 별도로 파라미터 값을 다르게 설정해야할 필요가 있을 때 DB Parameter Group 을 별도로 생성하여 해당 인스턴스에서 사용하는 형태로 이용할 수 있습니다.


1-3 클러스터 수정

데이터베이스 -> 클러스터 선택 -> 수정 을 선택 합니다.





1-4 파리미터 그룹 선택

추가 구성 -> 데이터베이스 옵션 -> DB 클러스터 파라미터 그룹 항목에서 위에서 생성한 파라미터 그룹을 선택 후 하단의 계속을 선택 합니다.




1-5 변경 적용

수정 사항에 대한 반영 시점을 선택해야 합니다 다음 유지 관리 때 적용 할 것인지, 지금 즉시 적용 할지를 선택 할 수 있으며, 포스팅에서는 즉시 적용 을 선택 하였습니다.




1-6 클러스터 구성 확인 

클러스터 -> 구성 항목에서 보면 아래와 같이 DB 클러스터 파라미터 그룹이 위에서 지정한 파라미터 그룹으로 바로 변경 되어 반영 된 것을 확인 할 수 있습니다.




1-7 파라미터 수정 

포스팅에서는 예시로 max_connections 파라미터를 변경 하도록 하겠습니다. 파라미터 검색 후 파라미터 편집을 선택 합니다.




파라미터 별로 default 값을 다 다르며 max_connections 의 기본 값은 아래의 계산으로 기본값이 산정 됩니다.

GREATEST(
{log(DBInstanceClassMemory/805306368)*45},
{log(DBInstanceClassMemory/8187281408)*1000}
)

Aurora 인스턴스에 접속하여 조회를 해보면 실제 설정된 값을 아래와 같이 확인 할 수 있습니다.

MySQL [mysql]> show variables like '%max_connections%';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| aurora_max_connections_limit | 16000 |
| max_connections              | 45    |
+------------------------------+-------+



변경 할 파라미터 값을 입력 후 "변경 사항 저장" 을 선택 합니다 포스팅에서는 1000 으로 변경을 하였습니다.




그리고 바로 조회하면 적용 유형이 dynamic 이기 때문에 접속 해제 없이 해당 세션에서 바로 적용 받은 것을 확인 할 수 있습니다.

MySQL [mysql]> show variables like '%max_connections%';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| aurora_max_connections_limit | 16000 |
| max_connections              | 45    |
+------------------------------+-------+
2 rows in set (0.008 sec)


--파라미터 적용 후 조회
MySQL [mysql]> show variables like '%max_connections%';
+------------------------------+-------+
| Variable_name                | Value |
+------------------------------+-------+
| aurora_max_connections_limit | 16000 |
| max_connections              | 1000  |
+------------------------------+-------+
2 rows in set (0.001 sec)





2. 읽기 전용 복제본

현재 구성한 Amazon Aurora Cluster DB 는 클러스터 내 1개의 기본 인스턴스(마스터) 만 존재하는 상태 입니다. 기존이 클러스터로 구성되며 인스턴스 레벨의 멀티 AZ가 지원되지 않기 때문에 읽기 복제본 인스턴스를 사용한 문제시 장애복구 및 다운타임을 줄이게 됩니다.

그래서 온프레미스의 MySQL 이나 RDS MySQL 도 Replica 인스턴스가 필요하지만  Amazon Aurora 의 경우도 거의 필수적으로 읽기 복제본 인스턴스를 같이 구성할 필요가 있습니다.

[참고] 운영 방침과 비지니스의 특성에 따라 달라질 수 있으며, Dev(개발계)나 QA 나 TEST 단계의 DB 의 경우 비용 적인 과 다운 타임에 대한 부분이 비교적 자유롭기 때문에 문제시 재기동을 하거나 자동 백업된 snapshot 을 통해 재생성을 할 목적으로 읽기 복제본 인스턴스 없이 클러스터내 단일 인스턴스(기본,마스터) 로만 구성해서 사용할 수 있습니다.


2-1 Aurora 의 복제 방식 차이

Amazon Aurora 는 온프레미스의 MySQL 또는 RDS MySQL 과는 다른 형태로 복제가 수행되게 됩니다.

관련 된 상세 내용은 이전 포스팅을 참조하시면 됩니다
Amazon Aurora DB - AWS RDS Aurora MySQL(1)



DB 인스턴스의 데이터를 관리하는 클러스터 볼륨 으로 구성되어 있습니다. Aurora 클러스터 볼륨은 다중 가용 영역(AZ) 아우르는 스토리지 볼륨으로, 각 가용 영역(AZ) 에는 DB 클러스터 데이터의 사본이 있습니다. 3개의 가용 영역에 거쳐 AZ 당 2개씩, 총 6개 스토리지 노드의 복제를 저장하여 고가용성 제공 하게 됩니다.

일반 MySQL의 네트워크를 통해서 Binlog 내용을 전송 및 재수행하여 복제 동기화하는 것과 달리 Aurora DB 는 공유 스토리지 기능을 통해서 읽기 복제본(Read Replica) 과 복제 및 동기화가 구현하고 있으며 그에 따라 복제 부하가 적으며 부하의 복제의 Gap이 매우 작으며, Aurora 읽기 복제본 인스턴스를 추가 시 별도의 복제 복사본이 만들지 않고 빠르게 인스턴스를 추가 할수 있습니다.

더 자세한 내용은 이전 포스팅을 참조하시면 됩니다
Amazon Aurora DB - AWS RDS Aurora MySQL(1)



2-1 읽기 추가

읽기 복제본은 아래 순서와 유사하게 진행하시면 됩니다.

데이터베이스 -> 클러스터 선택 -> 작업 -> 읽기 추가 순으로 선택을 합니다.



[참고] 복제본 생성은 Replica 또는 Slave 의 구성이 아닌 영문 Clone 을 의미하며, 수행하게 되면 기존의 데이터베이스의 모든 데이터 와 Writer DB 인스턴스가 포함된 새로운 클러스터가   복제 생성되는 기능 입니다.


2-2 인스턴스 식별자 및 크기 지정

읽기 복제본을 추가 하기 위해서 몇 가지 항목을 입력 하고 선택 해야 합니다. 먼저 DB 인스턴스 식별자를 입력해야 합니다 포스팅에서는 기본 인스턴스에 맞춰서 식별자를 지정하였습니다.

DB 인스턴스의 크기도 클러스터내 인스턴스 별로 각각 설정이 가능합니다. 




2-3 연결 설정

연결 항목에서는 퍼블릭 엑세스 가능 여부 와 가용 영역(AZ) 를 선택 할수 있으며 포트는 변경이 불가능 합니다. 

추가 구성에서 "장애 조치 우선 순위" 를 지정해야 하며 이전에 기본 인스턴스(마스터) 에서는 티어-0 을 선택하였기 때문에 이번에 생성하는 읽기 복제본은 더 후 순위인 티어-1 를 지정하도록 하겠습니다 (아래에서 설명 추가)




[참고] 장애 조치 우선 순위는 기본 인스턴스(마스터)의 장애시 다수의 읽기 복제본 중에서 기본 인스턴스로 승격 시킬 인스턴스에 대한 우선 순위를 지정하는 옵션 입니다. 우선 순위가 가장 높은 복제본(티어 0으로 시작)을 새로운 기본 인스턴스로 승격시킵니다. 포스팅에서는 기본인스턴스를 가장 높은 우선 순위(티어 0)로 설정하고 진행하였습니다.


2-4 모니터링 및 유지관리

포스팅에서는 Enhanced 모니터링 을 활성화 하였으며, 별도로 업그레이드 등을 테스트 하기 위해서 유지 관리에서 "마이너 버전 자동 업그레이드 사용" 기능을 비활성화(uncheck) 하였습니다.
설정이 마무리가 되었다면 하단의 "Add reader" 를 클릭 합니다.




2-5 생성 완료

생성이 시작 하고 나면 아래와 같이 역할이 읽기 인 두번째 인스턴스를 확인할 수 있으며, 상태는 처음에는 생성 중 으로 확인되게 됩니다.




생성이 완료 되면 아래와 같이 상태에 사용 가능 으로 확인이 되게 됩니다.




2-6 접속

읽기 인스턴스에 접속 하는 방법은 크게 2가지 입니다.
Cluster Reader endpoint url 를 통해서 접속하거나 인스턴스의 개별 endpoint 로 접속 입니다.


• 클러스터 엔드포인트

아래 이미지와 같이 클러스터 선택 -> 연결 및 보안 항목에서 엔드포인트 정보를 확인 할 수 있습니다. 유형 항목에 써있는 것처럼 1개는 쓰기 가능한 기본 인스턴스로 접속하는 엔드포인트이며, 하나는 읽기 전용 복제본 인스턴스에만 접속이 가능한 엔드포인트이고 읽기 인스턴스의 엔드포인트에는 주소 중간에 "ro" 가 명시적으로 기재되어 있습니다.




• 인스턴스 엔드포인트

인스턴스 별로도 각각 개별 엔드포인트 접속 주소는 할당되어 있습니다. 인스턴스 선택 후 연결 & 보안 탭에서 엔드포인트 정보를 확인 할 수 있습니다.




위와 같이 생성한 읽기 인스턴스에 접속 할 수 있으며 서비스 용도의 애플리케이션에서는 ro 가 붙은 클러스터 읽기 엔드포인트 를 통해 접속해야 합니다. 물론 쓰기 인스턴스로 접속을 위해서도 클러스터 쓰기 엔드포인트 로 접속을 해야 합니다.

그래야 장애나 기타 문제가 발생하여 페일오버 되어 읽기 인스턴스가 기본 인스턴스로 승격이 되었을 경우 접속 주소의 변경 없이 그대로 사용할 수 있습니다.

Reader Endpoint 로 접속해보면 정상적으로 접속되는 것을 확인 할 수 있습니다.

user$ mysql -u admin -p -h myaurora.cluster-ro-xx.rds.amazonaws.com
Enter password: 

Server version: 5.7.12 MySQL Community Server (GPL)

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> use mysql;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A




3. 장애 조치(페일오버)

Amazon Aurora DB는 기본적으로 생성 시 쓰기 가능한 기본 인스턴스를 포함한 클러스터가 생성되게 됩니다. 의미대로 장애의 발생이나 계획된 작업(PM) 에 따른 인스턴스의 가용성 보장의 기능이 있음을 의미 합니다.

장애 조치 라는 기능으로 읽기 인스턴스를 쓰기 가능한 기본 인스턴스로 승격을 할 수 있습니다. 특정한 문제로 쓰기 인스턴스가 재기동을 계속적으로 시도하고 페일오버가 진행되지 않을 경우(실제로 격은 사례) 운영자가 개입하여 페일오버를 진행할 수 있습니다. 그외 계획된 또는 의도하는 바가 있어서 읽기 인스턴스를 승격이 필요할 수 있습니다. 

이럴 경우 장애 조치 기능을 통해서 fail-over 를 할 수 있습니다.


3-1 장애 조치 우선 순위

장애 조치 수행시 특정 인스턴스를 기본 인스턴스(마스터) 로 하는것에 대해서 웹 콘솔 메뉴상에서는 존재 하지 않습니다. 설정한 장애 조치 우선 순위 에 따라서 다수의 읽기 인스턴스 중에서 가장 우선 순위가 높은 인스턴스가 기본 인스턴스로 승격되게 됩니다.

아래 이미지 와 같이 현재 포스팅에서는 쓰기 가능 기본 인스턴스는 순위가 0 으로 설정 되어 있습니다




위에서 생성한 읽기 인스턴스는 우선 순위 1(티어-1) 로 되어 있습니다



이렇게 인스턴스 별로 설정된 우선 순위를 확인 할 수 있습니다.


3-2 작업 실행

개별 인스턴스 선택 -> 작업 -> 장애 조치 순으로 선택을 합니다.




3-3 장애 조치 실행

이전 단계에서 작업 -> 장애 조치 메뉴를 선택하면 아래와 같이 장애 조치 수행 여부를 확인 하게 되며, 하단의 "장애 조치" 를 선택하면 fail-over 가 진행되게 됩니다.




3-4 장애 조치 완료

장애 조치가 수행되게 되면 아래와 같이 클러스터의 상태가 "Failing-over" 로 바뀌게 됩니다.




완료가 되면 읽기 역할 이었던 instance-2 가 쓰기 역할로 변경된 것을 확인 할 수 있습니다.




3-5 장애 조치 우선 순위 변경

3-5-1 수정 메뉴 선택

장애 조치 우선 순위의 변경은 수정 메뉴를 통해서 변경 할 수 있습니다.
인스턴스 선택 -> 수정 메뉴를 선택 합니다.




3-5-2 우선 순위 변경

추가 구성 항목에서 "장애 조치 우선 순위" 를 원하는 순위로 선택 후 하단의 "계속" 버튼을 클릭 합니다.




3-5-2 DB 인스턴스 수정

수정 사항에 대해서 적용 시점을 선택 하면 되며 포스팅에서는 즉시 적용 을 선택 하였습니다. 선택이 완료 되었다면 하단의 "DB 인스턴스 수정" 을 클릭 하여 수정을 마무리 합니다.




3-5-2 인스턴스 수정 완료

수정이 적용되면 상태가 아래와 같이 "수정 중" 으로 변경 되게 됩니다.




적용이 완료 되면 인스턴스 -> 구성 항목에서 변경된 우선 순위를 확인 할 수 있습니다.




추가 적인 내용은 다음 포스팅에서 이어서 다루도록 하겠습니다.



다음 이어지는 글 




연관된 다른 글

 

 

 

 

 




답글 남기기