Please act before October 31, 2019 to address an upcoming interruption of your applications using RDS and Aurora database instances.
To protect your communications with RDS database instances, a Certificate Authority (CA) generates time-bound certificates that are checked by your database client software to authenticate any RDS database instance(s) before exchanging information. Following industry best practices, AWS renews the CA and creates new certificates on a routine basis to ensure RDS customer connections are properly protected for years to come. The current CA expires on March 5, 2020, requiring updates to existing RDS database instances with certificates referencing the current CA.
You are receiving this message because you have an Amazon RDS database instance(s) in the AP-NORTHEAST-1, AP-NORTHEAST-2, AP-SOUTHEAST-1, AP-SOUTHEAST-2 Region(s). If your applications connect to those instances using the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol please follow the detailed instructions in the link below to complete your update(s). If not completed, your applications will fail to connect to your DB instances using SSL/TLS after March 5, 2020.
Any new RDS instances created after November 1, 2019 will default to using the new certificates. If you wish to temporarily modify new instances manually to use the old (rds-ca-2015) certificates, you can do so using the AWS console or the AWS CLI. Any instances created prior to November 1, 2019 will have the rds-ca-2015 certificates until you update them to the rds-ca-2019 version.
/* 구분자를 ";" 으(로) 변경 / / linuxer-blog-rds.ctekipxl.ap-northeast-2.rds.amazonaws.com 에 MariaDB (SSH tunnel) 을(를) 통해 연결 중, 사용자 이름 "admin", 암호 사용: Yes… / / SSL 매개 변수를 성공적으로 설정하였습니다. / / Attempt to create plink.exe process, waiting 4s for response … / / / SELECT CONNECTION_ID(); / 연결됨. 스레드-ID: 579 / / 문자 집합: utf8mb4 */
보안을 고려한 설계 Amazon RDS for MySQL, Amazon RDS for MariaDB 및 Amazon RDS for PostgreSQL의 읽기 전용 복제본을 생성할 때, Amazon RDS는 리전 간에 복제하더라도 원본 DB 인스턴스와 읽기 전용 복제본 간에 퍼블릭 키 암호화를 사용하여 안전한 통신 채널을 설정합니다. Amazon RDS는 안전한 채널을 제공하는 데 필요한 모든 AWS 보안 구성(예: 보안 그룹 항목을 추가)을 설정합니다.
퍼블릭키 암호화 부분이 CA를 사용하는건 아닐까하는 궁금증이었는데,
스크린샷을 찍어가며 작업한것은 아니나, CA-2015 에서 생성한 읽기전용복제본의 인증기관을 2015 로 설정하고 마스터는 CA-2019 로 변경시에 퍼블릭키를 이용한 암호화 채널에는 아무 문제가 없었다.
고로 퍼블릭 키는 별도의 퍼블릭키라 결론을 내렸다.
현재 CA-2015 에서 CA-2019로 교체이슈가 뜨겁다.
즉시적용이던 유지관리에 적용이던 얼른적용하자. 사실 RDS에서 SSL 인증을 사용하는것이 아니면 기능상의 문제는 없으나....
이벤트에 의해 강제로 리부팅되고 단절에의해 서비스에 장애가 생기는거 보단 미리하는것이 나을것이라 생각한다.
흔히들 한글도메인을 많이 사용한다. 처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.
route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.
간단하다 모든 네임서버는 한글을 인식할수 없다.
그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.
퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.
그리고 AmazonS3FullAccess 권한을 가진 사용자를 Programmatic access 방식으로 생성한다.
그리고 버킷을 생성한다. AmazonS3FullAccess full acces 권한을 줬는데 이 권한은 업로드 권한만 줘도 무방하다. 하지만 편한 테스트를위해 전체 권한을 부여하였다.
일단 모든 퍼블릭 엑세스 차단을 해제한다. 나머지는 모두 기본설정이다. 위 설정은 편한 설정을 위한 선택이므로 각자 개인의 선택을 요한다.
미리 wp-content/uploads 폴더까지 생성한다. 그리고 cloudfront 를 생성한다.
Restrict Bucket Access -yes Origin Access Identity - Create a New Identity Grant Read Permissions on Bucket - Yes, Update Bucket Policy 위 순서대로 선택하면 s3 버킷 정책이 자동으로 삽입된다.
그리고 cloudfront는 https 로만 통신하기 떄문에 route53에 도메인을 생성하여 붙여주는게 좋다. 도메인을 붙일떈 acm 을 생성하여야 한다. acm은 버지니아 북부에서 생성한 acm만 사용할수 있다.
acm은 route53을 사용하면 버튼 클릭 한번으로 생성 가능하다. 하나의 acm에는 50개의 도메인을 추가할수 있다. 간단하게 linuxer.name *.linuxer.name 을 추가하였다. 여기에 linuxer.com 이나 linuxer.kr namelinuxer.net 등 여러가지의 도메인을 한꺼번에 추가하여 사용할수 있다.
이후 cloudfront 를 생성한다. 이후에 wordpress 플러그인 설정화면으로 진입한다.
엑세스키와 시크릿키를 입력하고 save를 하면 디비에 저장이 된다. 디비에 저장하고 싶지 않을경우에 wp-config.php 파일에 추가를 한다.
그리고 플러그인 Offload Media Lite 으로 진입하여 cname 설정을 진행한다.
OFF 되어있는 버튼을 누르고 설정된 cloudfront 에 설정한 cname 을 입력한다. 이 설정을 마칠쯤이면 cloudfront 가 Deployed 상태로 변경될것이다.
그러면 이제 테스트 게시물을 작성하여 보자.
업로드가 정상적으로 이루어 지게 되면 이미지가 정상적으로 보이게되고 주소복사를 눌렀을떄 해당 페이지가 cdn 페이지로 열리면 정상적으로 upload-s3-cdn 이 구조로 생성이 된것이다.
그리고 s3 로 uploads 디렉토리를 이동하는것은 선택이다.
하지만 그부분도 진행하였다.
#aws configure AWS Access Key ID [None]: AWS Secret Access Key [None]: Default region name [None]:ap-northeast-2
aws configure 명령어를 이용하여 이전에 만든 엑세스 키를 입력하고 리전을 지정한다. 그리고 aws s3 명령어를 이용하여 sync 한다.
이만하면 충분히 web 인스턴스를 죽일수 있을거라 생각된다. 동접자만 확인하면 되는데 쓸데없이 흥분해서 30000번의 테스트를 보냈다.
로드벨런서 요청 갯수다. 그리고 인스턴스 안에서 로그로 리퀘스트 횟수를 확인해보니 약 9000개 정도..
어? 나쁘지 않은데? 싶다. 솔직히 내블로그가 동시접속자 1000명으로 몇번이나 견딜까 싶기도 하고... 하지만 여기서 그칠순 없다. 동접자를 더 늘려보자!
fpm 설정이 무리한 설정이 아니었을까? 사실 20개만 해도 cpu는 100%가까이 근접해 버리는터라 일단 메모리 리미트에 맞춰서 pm.max_spare_servers 설정을 수정하는것이 관건이라 본다. 간당간당하게 버티면서도 인스턴스는 죽지않는. 이과정은 사이트의 다운과 리스타트가 동반되는 아주 귀찮은 과정이다.
그래도 일단 근성을 보여서 테스트를 진행했다.
jmater를 이용하여 부하를 주고 인스턴스가 죽지 않을 만큼 php-fpm 에서 적당히 설정을 조절했다. 이경우 최대 부하시점에서 메모리가 아슬아슬하게 남아있을 경우를 찾아서 최적의 값을 찾아보았고 php-fpm.d/www.conf 를 수정하였다.
top 명령어 로 RES 부분을 보면 하나의 프로세스가 사용하는 메모리 양을 알수있다. 스크린샷에는 52M 정도이므로 프리티어는 1G의 메모리 까지 사용 가능하다. OS 까지 생각하면 대략 750M 정도 사용가능하다 생각하면 되는데 이기준으로 pm.max_spare_servers 를 15로 정했다.
다시 부하를 주었다.
예상 처럼 남은 메모리가 50M 정도밖에 남지않고 잘돌아간다. 물론 이상황에 CPU는 100%다. 이실험을 시작한 이유는 rds에 최대 부하를 주는것이 목적이므로 pm.max_children 를 150 까지 늘렸다. 그리고 테스트를 하였다.
ec2 도 죽지않고 rds도 죽지 않았다. 아니 rds 는 max 커넥션에 걸리는데 cpu나 메모리는 13%....아마 내블로그에서 끌어낼수 있는 한계가 13%인거겠지...또르륵 그렇다면 이쯤작성하다 오기가 발동했다. 부하테스트를 시작한김에 rds 가 죽을때까지 인스턴스를 늘리기로 했다.
Auto Scaling 걸고 트리거 cpu는 60%로 사실 의미없다. 동시 접속 20개만 걸려도 cpu 100%인거.. 그렇지만 rds 를 죽이기로 했으므로 부하를 걸었다.
Auto Scaling 은 차근차든 인스턴스가 생성됬고 총5개까지 생성되었다. 사실 동접자 초당 120명 이면 인스턴스 모두 CPU가 100%다.... 무조건 부하를 주는건 잘못된 테스트 같아서 방법을 수정하였다. 1초당120번 접속 무한반복으로.
죽이기로 했으니 원래 t2.micro 사이즈의 max_connections 은 {DBInstanceClassMemory/12582880} 134다 이걸 10000으로 수정하였다.
rds의 파라미터그룹은 디폴트 파라미터그룹을 수정할수 없다. 따로 생성하여 수정해야 한다.
