비내리는사막

AWS Aurora Failover시 설정과 관련하여 이슈사항 및 참고사항에 대하여 공유드립니다.

프로젝트를 진행하시다 보면 AWS Aurora를 이용하여 진행하는 사이트도 있을텐데 Database Failover 테스트시

WAS단에서 Connection들이 정상적으로 Failover 되지 않는 현상이 있습니다.(Write불가, Read만 가능)

위의 문제로 이슈가 발생했고 해결한 내용에 대하여 공유드립니다.

-       테스트 장비

Aurora Master DB 1대, Read-Replica 1대

Connection 수 : Min(50), Max(50)

-       테스트 상황

1.     Master -> Read-replica로 Failover

2.     Read-replica(1번 작업진행 후) -> Master로 Failover

위의 2가지 시나리오대로 진행 후 WAS에서 정상적으로 Application 동작여부 체크

-       이슈 사항

- DB는 정상적으로 Failover 되었음에도 Application에서는 Read-replica 쪽 디비를 바라보고 있음.

해결방안

1.     AWS Aurora는 Mysql JDBC를 사용하면 안되고, 반드시 Maria JDBC를 사용할것을 권장드립니다.

JAVA설치 후 .JAR 파일을 추가시 JAVA/lib 폴더 밑에 Mysql JDBC파일과 Maria JDBC파일이 같이 존재하면 LIB 파일간의 충돌이 일어날 가능성이 많음

JDBC_DIRVER설정을 Maria로 선언 하여도 2개가 존재하면 driver간의 충돌이 일어나는 현상이 있습니다.

2.     JVM의 TTL값을 60부터 그이상으로 설정하기를 권장드립니다.(Default : 10)

WAS엔진 종류에 따라서 NETWORKADDRESS_CACHE_TTL의 작동 방식이 다릅니다.

Tomcat의 경우 설정시간에 따라 성공시 Cache를 하지만, 그 외 엔진들은 설정시간마다 Cache를 진행하는 방식인듯 합니다.

어떠한 엔진이 1회 Cache를 하고 매번 Cache를 하는지는 Test해보진 않았지만 위 2가지 방식으로 동작합니다.

Amazone의 공식 매뉴얼 : https://docs.aws.amazon.com/ko_kr/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html

결론

           Aurora가 Failover될떄 클러스터엔드포인트에 맵핑된 IP변환이 시간과 TTL에 설정된 시간이 맞지 않아서 발생하는 문제인듯 합니다.

           AWS매뉴얼에도 보면 TTL값을 60초 미만으로 설정하라고 되어 있지만 40부터 설정을 바꿔가며 테스트 해봤는데 60초가 적당한 듯 합니다.

EC2 의 CENTOS 의 경우 8G 정도의 Root 볼륨이 할당됩니다. 약간 작아 20G로 resize2fs 시켜 사용중이었는데 6.7 버전부터 resizefs /dev/xvda1 을 하면 

라는 메세지가 발생합니다.

이를 해결하기 위해 아래의 방법을 실행합니다.

 이는 시작 섹터를 변경하여  이전 파티션을 삭제하고 동일한 파티션 번호를 새로 생성하게 하는 것입니다. 잘못될 경우 부팅에 실패할 수 있으므로, 사용 중인 시스템에서는 백업이 필수라 여겨집니다. 

위의 내용은 제가 직접 실행한 내용이고, 아래에 설명을 따라했습니다. 가급적이면 원본 사이트에가서 참조하시기 바랍니다.

To expand on JD's self-accepted answer, here's exactly what to do:

df -h #print the name of your boot partition

lsblk #show info on all your block devices

You'll see from that output what the name of the disk is of your root partition. For example, you probably see something like this:  xvde 202:64 0 32G 0 disk └─xvde1 202:65 0 8G 0 part /

Our goal is to make xvde1 use the whole available space from xvde. Here's how your resize your partition:

fdisk /dev/xvda (the disk name, not your partition) This enters into the fdisk utility.

1. u #Change the display to sectors
2. p #Print info
3. d #Delete the partition
4. n #New partition
5. p #Primary partition
6. 1 #Partition number
7. 2048 #First sector
8. Press Enter to accept the default
9. p #Print info
10. a #Toggle the bootable flag
11. 1 #Select partition 1
12. w #Write table to disk and exit

Now, reboot your instance: reboot

After it comes back do:

resize2fs /dev/xvde1 (the name of your partition, not the block device)

And finally verify the new disk size: df -h

1 출처는 여기

http://stackoverflow.com/questions/26770655/ec2-storage-attached-at-sda-is-dev-xvde1-cannot-resize

1. T 아카데미 동영상 강좌

https://www.youtube.com/channel/UCtV98yyffjUORQRGTuLHomw

2. T 아카데미 강좌 수강 (무료)

https://tacademy.sktechx.com/live/player/onlineLectureDetail.action

3. AWS 공인 솔루션스 아키텍트 - 어소시에이트 수험 가이드

https://github.com/serithemage/AWSCertifiedSolutionsArchitectUnofficialStudyGuide

4. 생활코딩 AWS 강좌

https://opentutorials.org/course/608/3002

5. 아마존 웹 서비스를 다루는 기술 - 온라인 원고 공개

http://pyrasis.com/aws.html

6. 아마존에서 소개 하는 AWS 공부방법

https://aws.amazon.com/ko/blogs/korea/how-to-learn-aws-cloud-books/

번외1. 코딩 교육

http://tryhelloworld.co.kr/

교육을 들으면서 실습 해볼 수 있는 환경 제공

AWS 정도현님 블로그

http://blog.creation.net/channy-cloud-clinic-ep11

RDS 서비스 메뉴에서 Parameters Groups 메뉴로 이동

현재 MySQL 인스턴스에 적용된 Parameters Group을 편집한다.

항목 중 log_bin_trust_function_creators 라는 친구가 있는데 이걸 0에서 1로 올려준다.

그리고 저장하고 해당 Parameter Group이 적용되면, 유저가 만든 데이터베이스에 대해서는 super 권한을 행사할 수 있다.

1. 변경 할 Image 생성. 

- Snapshot에서 이미지를 생성해도 되나 아래 화면은 EC2 Instance에소 바로 이미지 생성 하는 화면

- 유의사항 : No reboot 선택해야 시스템 reboot 없이 진행 

- DB와 같이 실시간 데이터나 데이터 무결성이 중요한 시스템은 변경 된 데이터에 대해 달라질 수 있음

2. [EC2] => [Auto Scaling] => [Launch Configurations] => 기존 Launch configuration을 선택 후 오른쪽 마우스 클릭 => [Copy launch configurain] 

3. 1번에서 생성 한 Image 선택

[My AMIs] => [Created Image Select] => [Next]

4. Instance Type 지정

5. 이름 지정

6. 변경 된 Launch Configuration 적용

[EC2] => [Auto Scaling] => [Auto Scaling Group] => [변경 할  AG 선택] => [Edit] 

7. Launch Configuration 항목을 눌러 Copy한 AG로 변경.

2016년 1월 7일자로 AWS의 12번째 Region인 한국의 Seoul Region이 오픈 되었다.

도입을 검토 하던 많은 기업과 사용자들에게 반가운 소식이 아닐까 싶은데,

기존에 일본에서 도쿄리전에서 사용하고 있던 사용자들은 마이그레이션에 대한 고민을 하지 않을 수 없을 듯 싶다.

사실 마이그레이션이라 함은 쉬운작업이 아니다. 

서비스 운영중에 옴긴다는 것은 많은 것을 고려 해야만 하고 신중해야 하는 작업일 것이다.

아직 서울 리전은 서비스에 오픈되어 있더라도 안되는 내용들이 조금씩 보이고 있다,

CloudFront 에서 ELB 검색이 되질 않는다던지..

Code 3총사들과 같은 서비스는 아직 오픈이 되어있지 않는다는 등.

그래서 일단 신중하라고 얘기하고 싶다. 

바로 서비스를 이전하기 보다는 테스트 먼저 선행 되어야 하며,그리고 이전을 위해서는 직접 하기 보단, 전문 업체에 의뢰하는 것이 좋다

혹여 이 글을 보는 분들 중에 당장 마이그레이션을 검토 중이라면 천천히 이동하는 것을 권고하고 싶다.

아마존에서 제공하는 마이그레이션 백서 (한글판)

RegionMigration_0401013.pdf

https://d0.awsstatic.com/whitepapers/International/ko/RegionMigration_0401013.pdf

아마존에서 핵심 서비스 중 하나인 RDS 사용하다 보면 가장 처음 문제가 되는 것 중 하나가

시간이 대한 부분이었다.

RDS는 미국시간을 기준으로 구성 되어 있기 때문에 DB 시간이 달라서 문제가 생기는데 보통 파라메타 수정하고

값을 참조 하는 형태로 처리를 하고 있었습니다만, 이번 업데이트로 인해서 해결 되었다.

https://aws.amazon.com/releasenotes/5321431004571119

AWS 국가코드 

http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html