aws – 페이지 2 – 리눅서의 기술술 블로그

서울-도쿄 리전간 레이턴시 줄이기-실패경험담

페이스북 AKUG에서 다음과 같은 포스팅을 봤다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-global-accelerator-supports-ec2-instance-endpoints/?fbclid=IwAR2spSZzdtmHMDVqYwEpZS8W5pEs86t7SMNArZ2fyT81M55QDoDA1dqKuy4

처음엔 아무생각이 없었으나 급 아이디어가 떠올랐다.

EC2 엔드포인트를 지원하면 리전간의 레이턴시를 줄일수 있지 않을까? 그러니까..궁금증은 오픈카톡에서 시작된거였다.

한국과 도쿄리전 간의 레이턴시를 20ms 로 줄일수 있는지가 관건이었다.

AWS Global Accelerator는 TCP/UDP를 지원한다. 그렇다면 OPENVPN을 TCP로 셋팅해서 인스턴스의 앞단에 AWS Global Accelerator 둔다면 과연 빨라질까?

그런 궁금증이었다.

엣지로케이션을 이용하여 라우팅 최적화라고 생각하면 가장 간단하다.

테스트 방식은 총4가지였다

openvpn-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping

openvpn-한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

openvpn-가속기- 한국리전(인스턴스)-vpc 피어링-도쿄리전- 프라이빗 IP 22 port tcping

AWS Global Accelerator 셋팅은 아주 간단하다.

Accelerator 를 생성하고 Listeners ID 를 생성할떄 region 을 지정하고 Endpoint groups 을 인스턴스 ID로 설정하면 status 를 업데이트 한다. ALL healthy 로 보이면 정상적으로 연결된것이다.

생성된 Accelerator 은 총3개의 endpoint 를 가진다. IP 두개와 DNS 하나이다.

그럼 테스트로 넘어간다.

가속기를 쓰지않고 도쿄리전의 인스턴스에 openvpn 으로 연결하여 프라이빗 IP로 22번 포트로 tcping 을 테스트 하였다. 총 100회의 tcping 의 time 을 확인할 계획이다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

C:>tcping.exe -n 100 172.31.26.253 22

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.180ms, Maximum = 81.995ms, Average = 64.100ms

가속기를 사용하지 않은 값으로 icmp 34ms / tcping 64ms 가 나온다.

172.31.26.253에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 34ms, 최대 = 35ms, 평균 = 34ms

Ping statistics for 172.31.26.253:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 43.065ms, Maximum = 78.722ms, Average = 61.323ms

평균 icmp 34ms / tcping 61ms 정도 확인할수 있었다.

tcping은 속도가 늘어지는 감이 있어서 ping 까지 체크해 보았다.

ping 로는 유효한 내용을 확인할수 없었다. openvpn 으로 접속하여 1194포트로 ping 를 확인하므로 실제 전송은 tcp로 이루어진다.

구성에 대해서 간략하게 설명하고 다음테스트를 진행하려고한다.

피어링은 신청하고 수락하는 단계를 거쳐서 허용된다.

피어링으로 끝이 아니라 두개의 VPC에서 라우팅을 설정해줘야 한다.

현재 서울 172.29.0.0/24 -> pcx 도쿄 172.31.0.0/20 -> pcx 로 라우팅 테이블을 설정 하였다. 테스트는 인스턴스 내부에서 ping 으로 확인하면된다.

사실 이때쯤 테스트가 잘못된것을 알았다.

— 172.29.0.110 ping statistics —
22 packets transmitted, 22 received, 0% packet loss, time 21036ms
rtt min/avg/max/mdev = 33.540/33.606/33.679/0.244 ms

vpc 피어링으로 묶은 속도의 평균이 33.5ms 였다.

망내 속도는 두 리전간의 피어링이 제일 빠를거라 생각했기 때문이다.
그래도 포기하지 않고 유효한 데이터를 쌓기위해 테스트를 진행했다.

이즈음 site to site vpn 셋팅이 가물가물 기억이 안나서 좀 이것저것 봤다.

다음 테스트구성은 서울리전 인스턴스에 openvpn으로 연결하고 vpc peering 으로 도쿄 리전과 연결한다. 그리고 ping / tcping 22 번 테스트를 한다.

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 39ms, 최대 = 40ms, 평균 = 39ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.206ms, Maximum = 79.891ms, Average = 60.589ms

Accelerator 를 사용하지 않은 결과로 icmp 39 / tcping 22 60ms 이다.
ICMP는 늘어지는데 TCP는 빨라지는 결과가 나왔다. 뭐지..

그래서 한번더 했다.

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.106ms, Maximum = 85.099ms, Average = 64.571ms

늘어지네… 39/ 60 / 64

172.29.0.110에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 40ms, 최대 = 41ms, 평균 = 40ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 46.406ms, Maximum = 78.911ms, Average = 65.489ms

Ping statistics for 172.29.0.110:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 45.652ms, Maximum = 81.980ms, Average = 66.764ms

40 / 65 /66 시간이 지날수록 속도가 느려졌다. 왜지? Accelerator 가 가까운 거리에선 라우팅을 한번 더 들어가게 되는건 아닐까 하는 생각이 들었다.

실제론 엣지를 타게되지만 전송거리가 더 먼건 아닐까…
그런 생각이 들어서 결국 오레곤 리전에 셋팅을 했다. 이젠 근성이다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 136ms, 최대 = 193ms, 평균 = 141ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 145.219ms, Maximum = 283.356ms, Average = 168.073ms

141 / 168 역시 오레곤은 멀다. 그럼 Accelerator 를 사용해 본다.

10.0.0.227에 대한 Ping 통계:
패킷: 보냄 = 10, 받음 = 10, 손실 = 0 (0% 손실),
왕복 시간(밀리초):
최소 = 126ms, 최대 = 127ms, 평균 = 126ms

Ping statistics for 10.0.0.227:22
100 probes sent.
100 successful, 0 failed. (0.00% fail)
Approximate trip times in milli-seconds:
Minimum = 132.458ms, Maximum = 224.706ms, Average = 154.244ms

126 / 154 드디어 Accelerator 를 사용했을때 유효한 결과가 보인다.

한국에서 거리가 먼~오레곤 정도 되어야..속도가 오르는게 확인이 된다.

물론 라우팅이 꼬일대로 꼬인 지역에선 Accelerator가 매우큰 도움이 될것이다.

하지만..여기서 끝내기엔 너무 아쉬웠다. 하.

또 한국리전에 최근에 적용된 기능이 생각났다.

https://aws.amazon.com/ko/about-aws/whats-new/2019/10/aws-client-vpn-now-available-seoul-canada-central-stockholm-northern-california-regions/?fbclid=IwAR3wIXq6EsYCxAV7FN05mDsmVc_mkQH1EzwVF-wUN8EpxTGB1f1zUiZ0_s8

이 테스트는 다음을 기약해야 할것같다..
ㅜㅜ실패의 충격이 크다.

하지만 얻게된 aws의 내부 망에 대한 추측이다.

서울 리전과 도쿄리전은 라우팅이 복잡해서 지연이 있는게 아니라 실제 회선이 지연이 있어서 발생하는 레이턴시다. 그래서 이 레이턴시를 줄이기 위해선 라우팅 최적화나 다른 시도가 필요한게 아니라 회선의 질적인 상향이 필요하다는게 내 결론이다.

오늘의 우승 구성은 ” openvpn-가속기-도쿄리전(인스턴스) -프라이빗 IP 22 port tcping ” 이다.

오늘은 도쿄에 테스트 했으니까 사요나라!

You have a web portal composed of two services. Each service musts scale independently. Both services should be served under the same domain. Which configuration allows this?
A. Use one AWS Classic Load Balancer. Create a redirect in the web server based on users’ source IPs.
B. Use two AWS Application Load Balancer; one for each service. Assign the same CNAME to both.
C. Use one AWS Application Load Balancer. Specify listener rules to route requests to each service.
D. Use two AWS Classic Load Balancers; one for each service. Assign the same CNAME to both.

두 개의 서비스로 구성된 웹 포털이 있습니다. 각 서비스는 독립적으로 확장해야합니다. 두 서비스 모두 동일한 도메인에서 제공되어야합니다. 어떤 구성이 가능합니까?
A. 하나의 AWS Classic Load Balancer를 사용하십시오. 사용자의 소스 IP를 기반으로 웹 서버에서 리디렉션을 만듭니다.
B. 두 개의 AWS Application Load Balancer를 사용하십시오. 각 서비스마다 하나씩. 동일한 CNAME을 둘 다에 지정하십시오.
C. 하나의 AWS Application Load Balancer를 사용하십시오. 요청을 각 서비스로 라우팅 할 리스너 규칙을 지정하십시오.
D. 두 개의 AWS Classic Load Balancer를 사용하십시오. 각 서비스마다 하나씩. 동일한 CNAME을 둘 다에 지정하십시오.

이문제는 하나의 domain 으로 두가지의 서비스가 가능한지 물어보는 서비스이다.

A. 출발지 IP 기반하여 서비스를 분기하는데 같은 IP에선 하나의 서비스만 사용할수 있다. 애초에 문제와 동떨어진 답이다.

B. 두개의 ALB를 사용하고 같은 CNAME 을 사용한다. DNS 라운드로빈으로 서비스되게 된다. 정상적인 서비스는 아니다.

C. 하나의 ALB를 사용하고 리스너 규칙을 이용하여 라우팅한다. 정답이다.

D. 두개의 CLB, B와 같이 DNS 라운드 로빈으로 작동하여 정상적인 서비스가 아니다.

그렇다면 여기에서 어떻게 하나의 리스너가 서비스 별로 분기가 가능한지 확인해 보자

리스너 규칙을 확인해 보면 현재 80->443으로 리디렉션 하고 443 리스너는 linuxer-blog-wg 로 전달한다.

https: 443 리스너의 규칙 보기를 누르면 다음과 같다.

그냥 단일로 전달하는 구성이다. 나는 여기서 같은 도메인으로 셋팅후에 /test /test2 로 조건 분기를 하려고 한다. 설정은 다음과 같다.

host는 admin.linuxer.name 이다. 이후 리디렉션으로 각각의 다른 게시물로 연결된다.

https://linuxer.name/test

https://linuxer.name/test2

두개의 경로로 접근해보면 에러페이지로 접근된다. admin 호스트가 명확하지 않기 때문이다.

https://admin.linuxer.name/test

https://admin.linuxer.name/test2

두개의 페이지는 정상적으로 8월과 9월의 게시물로 정상적으로 리디렉션이된다.

경로가 너무길거나 한글은 적용이 정상적으로 되지 않으므로 유의해야한다.

위테스트 URL은 이해를 돕기위해 ALB 리스너 규칙에 남겨놓은 상태이므로 리디렉션이 정상적으로 되는것을 확인해 보시라.

빼먹은 부분이 있는데 리스너 규칙을 이용한 타겟그룹으로 전달을 설정한것을 보여주지 않은것으로 보인다.

위와같이 리디렉션을 전달대상으로 수정하면된다. 대상그룹으로 라우팅시에 확장이 가능한 구성을 사용할수 있다.

이질문은 우리 동료직원들/ 한섭님 등등이 궁금해 했던 이야기 이므로

포스팅 기회를 주신것에대해 감사를 드린다.

AWS 기본 교육자료

aws 를 설명하기 전에 먼저 클라우드란? 무엇인지 부터 알아야합니다.

일반적으로 가상화를 이용하여 노드를 관리하는 기술을 클라우드라고 지칭합니다.

클라우드는 퍼블릭 클라우드 / 프라이빗 클라우드로 나뉘는데 AWS는 퍼블릭 클라우드를 지양하는 플랫폼입니다.

AWS에 대해서 알기위해선 먼저 기본적인 용어에 익숙해 져야 합니다.

이 기본적인 용어를 설명할것입니다.

on-premise / off- premise 입니다.

일반적으로 하드웨어 기반의 가상화가 아닌 IDC에 종속적인 레거시 인프라를 온프레미스라고 칭합니다. 당연히 반대의 클라우드환경은 오프프레미스라고 하겠죠.

클라우드에서 가장 많이 쓰이는 단어는 On-Demand 입니다. 언제나 사용할수 있는 정도로 이해 하면 될것 같습니다.

간단하게 AWS체로 말하자면

“온프레미스에선 리소스를 온디맨드 하게 쓸수 없잖아요?”

등과 같이 말할 수 있습니다.

오늘은 간단하게 AWS 의 기본 인프라를 소개하려합니다.

기본 인프라 라고 함은 보통 vpc / ec2 / ebs / elb /eip / RDS 등을 뜻 합니다.

등으로 표현합니다. aws.ver2 아이콘으로 간단하게 서비스를 나열해 보았습니다.

AWS VPC 안에 인스턴스(서버)를 생성하고 ELB(L4)로 로드벨런싱을 합니다.

EBS는 블럭스토리지로 파일시스템을 생성하여 데이터를 저장하고 스토리지의 타입에 따라 성능과 비용을 조절가능합니다.

퍼블릭 서브넷에 속해있는 인스턴스는 EIP를 가집니다.

인스턴스에 접근을 제어할수 있는 방법은

보안그룹 포트별 제어할수 있으며,

NACL로 IP list 에 대한 컨트롤이 가능합니다.

일반적으로 인스턴스가 퍼블릭에 노출되는경우는 없으며 퍼블릭에 노출되는 인프라는 ELB입니다. 프라이빗 서브넷에서

web-rds 는 통신을 합니다. 일반적으로 web/rds 는 2 tier 라고 칭합니다.

2tier 구성도는 위와 같습니다.

여기에 ELB-WEB-ELB-WAS-RDS 구성으로 변경된다면 3tier 구성이 됩니다.

기본적인 aws 인프라의 설명을 마치겠습니다.

ALB sticky session 에 대한 고찰.

aws 에선 고가용성을 위한 로드벨런서를 지원한다.

로드벨런서의 이야기다.

오늘 3티어 구성에서 세션이 널뛰는 증상이 있었다. 그 이야기를 하기전에 먼저 설명부터 하겠다.

ELB 라는 이름으로 ALB/NLB/CLB로 불린다.

Application Load Balancer, Network Load Balancer, Classic Load Balancer 이다.

오늘 이야기할 로드벨런서는 ALB인데 그중에도 sticky session 이다.

한글 콘솔에서는 고정 세션이라 불린다. 고정세션은 라운드 로빈으로 작동하는 로드벨런서에 세션을 고정해서 사용자의 경험을 지속할수 있도록 도와주는 역할을 한다.

먼저 옵션을 설정하는 방법부터 보자

로드벨런서>대상그룹> 속성편집 을 누른다.

그럼 아래와 같은 창이뜨고 활성화를 누르면 고정세션의 시간을 활성화 할수 있다.

활성화 한 화면은 다음과 같다.

sticky session 이 정상적으로 붙은지 확인하는 방법은 아래와 같다.

아직 sticky session 설정을 추가하지 않은상태다.

sticky session 세션은 cookie로 생성이된다.

Application Load Balancer는 로드 밸런서가 생성한 쿠키만 지원합니다. 쿠키의 이름은 AWSALB입니다. 이러한 쿠키의 콘텐츠는 교체 키를 사용하여 암호화됩니다. 로드 밸런서가 생성한 쿠키는 해독하거나 변경할 수 없습니다.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-target-groups.html#sticky-sessions

3tier로 구성하면 AWSALB 쿠키가 2개가 붙는다.

AWSALB fnCHt1XmAslF4YJP1DdrFja2gFlp58fwxawbSD63gMsYHbSY6ZvL47TP9JyNb1LAqNBb1mt3J0xTVTQrbyFV3KVQmFayhf0C+FIcsOoXDpadKRTlRxNiL2jaijXf N/A N/A N/A 131
JSESSIONID BA145F75466D30D122F5BF83873E0C13 N/A N/A N/A 45
_ga GA1.3.549999545.1568632026 N/A N/A N/A 32
Response Cookies 357
AWSALB 7/4O7AyBPsXTcT9Y3AEE+B3ueRztLwkdTz9TwF/bJ191ItEAMN1HoOk1xsVtWsOjbmuZb68s5gs+6xM2oowR3JgexIIVYIUPWwFkkOWliy3FkwsmeMzQmXsKAkV0 / 2019-10-28T10:50:30.000Z 179
AWSALB UUu3Vbr3MNNBSaaby5Z1dduf11BTf0148wbnE+20aF9Ak+QQWv0ZFGlsBsUZTOWRB9k99mVsAzr0PMgLAiciFD5mJW2FLmNn3ojwbh/EEQFdL5qe6NZCkAFKuLOz / 2019-10-28T10:50:30.000Z 178

alb-web-alb-was-rds 구성이면 쿠키가 좀붙는데 was 가 tomcat 라면

awsalb 쿠키 2개와 jsessoinid 라는 쿠키까지 붙는다.

여기서 awsalb 쿠키는 response 한 alb쿠키를 request 에 재활용한다.

awsalb 쿠키는 지속적으로 변한다. 하지만 sticky session 에의해서 jsessionid값은 연결된 was의 고유값을 지니며 jsessionid 가 변경되면 세션이 초기화 되서 재 매칭이 된다.

이걸 왜포스팅하냐면 sticky 가 정상적으로 붙는데 세션이 was1/2로 붙는 증상이 발생해서 확인하는 방법을 포스팅한거다..

아디오스!

RDS CA 인증서 2015 -> 2019 변경

메일을 받았다.

Hello,

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.

We encourage you to test these steps within a development or staging environment before implementing them in your production environments. Beginning today, you can start testing and updating your existing RDS database instances. For detailed instructions, please visit: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL-certificate-rotation.html

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.

If you have questions or issues, please contact AWS Support at: https://aws.amazon.com/support

Sincerely,
Amazon Web Services

rds의 ca 인증서가 2015에서 2019로 변경되었다. 간단한 테스트를 진행할거고 변경을 진행할것이다.

먼저 진행할 테스트는 ca-2015 인증기관과 중간 인증서로 접속하기다. 처음엔 글로벌 CA를 이용할거라 생각했는데 아니었다. 리전마다 중간인증서로 명명된 CA인증서를 사용해야 한다.

접속 정보는 이미 모두 적용된 세션에 SSL CA 만 추가해서 접속한다

사용한 인증서는 RDS 에선 CA-2015 그리고 SSL CA인증서는 아마존에서 제공하는 중간인증서를 사용하였다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2015-ap-northeast-2.pem

위 인증서를 받아서 접속을 하였다.

/* 구분자를 “;” 으(로) 변경 / / 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 */

정상적으로 접근이 가능한것을 확인하였다.

인증서 다운로드 리스트는 아래의 링크이다.

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html

그럼 이제 테스트할것은 RDS CA-2015 을 CA-2019 로변경하고 rds-ca-2015-ap-northeast-2.pem 인증서로 접근해 볼것이다. 인증기관을 변경하는 방법은 다음과 같다.

수정을 누르고~ 스크롤을 내린다.

인증기관 부분을 2015 -> 2019로 변경한다.

변경하면 위와같은 노티가 발생한다. 새인증서를 받아서 사용하라는 메시지 이다.

2분가량의 다운 타임이 발생하고 이테스트를 진행하는 이유는 다음 글귀 때문이다.

aws docs 에서 본 글귀인데

이 루트 인증서는 신뢰할 수 있는 루트 개체이므로 대부분의 경우에 작동하지만 애플리케이션에서 인증서 체인을 수락하지 않는 경우 실패할 수 있습니다.

대부분의 경우에 작동한다. 물론 2015-2019 인증서가 교차로 작동할거라 생각하진 않으나 혹시나 하는 생각에 진행해 본다.

tmi로

유지관리 기간 설정은 같은 페이지에서 할 수 있다. 즉시 적용을 하지 않을 계획이라면 알아두자. 필자는 즉시적용을 했다.

재부팅이 이어지고 완료가 되면 접속테스트를 진행한다.

CA-2019 인지라 rds-ca-2015-ap-northeast-2.pem 인증서론 접근이 안된다.

이후 사용한 인증서는 아래의 링크이다. 접속이 잘된다.

https://s3.amazonaws.com/rds-downloads/rds-ca-2019-ap-northeast-2.pem

HeidiSQL 프로그램으로 SSL을 사용한 접근을 하는 테스트를 진행해 보았다.

이테스트를 진행한 이유는 사실 목적은 읽기전용복제본에 있었다.

CA인증서가 변경되면서 master – slave 사이의 통신채널에도 문제가 있을까? 하는 질문을 받았기 떄문이다.

https://aws.amazon.com/ko/rds/details/read-replicas/

보안을 고려한 설계
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 에서 한글 도메인 사용법. 부제 – 장난으로 리눅서.com 구매한 이야기

흔히들 한글도메인을 많이 사용한다.
처음 한글도메인을 사용하시는분들이 겪게 되는 이야기다.

route53에서 한글 도메인 구입은되는데 hosted zone 생성은 안된다고 한다.

간단하다 모든 네임서버는 한글을 인식할수 없다.

그런데 우리는 한글도메인을 사용한다. 사용할때 필요한것이 퓨니코드다.

퓨니코드(Punycode)는 유니코드 문자열을 호스트 이름에서 허용된 문자만으로 인코딩하는 방법으로, RFC 3492에 기술되어 있다. 퓨니코드는 유니코드가 지원하는 모든 언어로 국제화 도메인을 쓸 수 있게 한 IDNA의 일부로, 변환은 전적으로 웹 브라우저와 같은 클라이언트에서 이루어진다.

뭐그렇단다.

그래서 퓨니코드로 인코딩된 문자열로 hosted zone 을 생성하면 사용할수 있다.

갑자기 든 의문이다. 퓨니코드 서브도메인은 생성이 가능할까?

도전해 본다.

https://후이즈검색.한국/idnconv/index.jsp

에서 변환가능하다.

리눅서.linuxer.name 를 변환하면 xn--pd1b38litg.linuxer.name 가 된다.

퓨니코드로 변환된 서브도메인으로 접속시에 잘된다.

결론. 한글서브도메인 route53에서 사용가능하다. 그럼 혹시 com 도메인도 퓨니코드로 변환해서 등록이 가능하지 않을까?

xn--pd1b38litg.com 으로 검색이 되고 구매까지 이어진다.

크래딧으로는 도메인을 구매할수 없다.

등록대기중 뜨고.

결제도 되구..
엥? 진짜? 리눅스.com 생성되는거야??????????????????????

리얼리? 농담인데;;;;;;;;;;;;

자동으로 hosted zone 도 생성됬고…….돌이킬수 없게 됬다.

나는 장난으로 리눅서.com을 가지게 되었다…

1년시한부로..

당연히 될건 알았는데 사고나니 좀 웃기기도 하고 그렇다.

리눅서.com 출격합니다.

acm도 잘추가되고!

웹사이트도 잘열리고!

감사합니다.

wordpress s3 cloudfront 적용하기

줄곳 고민하던 s3-uploads / cdn-cloudfront 를 적용하였다.

먼저 wordpress 의 여러 플러그인중에 대중적이며 복잡하지 않은 방식을 채택하였다.

사용한 플러그인은 두가지이다.

Amazon Web Services / WP Offload Media

두개의 플러그인을 설치한다.

그리고 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 버킷 정책이 자동으로 삽입된다.

{
“Version”: “2008-10-17”,
“Id”: “PolicyForCloudFrontPrivateContent”,
“Statement”: [
{
“Sid”: “1”,
“Effect”: “Allow”,
“Principal”: {
“AWS”: “arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E2BE1SUSFLL”
},
“Action”: “s3:GetObject”,
“Resource”: “arn:aws:s3:::linuxer-wp1/*”
}
]
}

그리고 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 한다.

#aws s3 sync wp-content/uploads/ s3://linuxer-wp/설정한 경로

이전에 업로드된 파일때문에 위와같은 작업을 진행하는것이므로 새로생성하는 wordpress 의 경우엔 하지않아도 괜찮다.

이후로 업로드되는 파일은 s3로 업로드되고 view 는 cloudfront 에서 진행될 것이다.

오늘의 포스트 주제를 주신 전산직 님께 감사드린다!

좋은하루 되시라!

aws free tier 한계까지 써보기.

galera 테스트를 진행하면서 블로그의 max connection을 테스트 할수 있었다.
한계는 명확했다.

50…!

50…!!!!!!!!!!

50!!!!!!!!!!!!!!!!

t2.micro 사이즈 의 rds 의 max_connections는 134 인데 50까지 밖에 안된다는건 역시 web의 문제일 확률이 크다.

php-fpm에서 문제를 확인할수 있었는데 바로 알게된 이유는 apache의 제한은 그보다 크게 설정되어있기 때문이다.

#cat /etc/php-fpm.d/www.conf | grep pm.max_children
pm.max_children = 50 => 150
#systemctl restart php-fpm

php-fpm 에서 사용할수 있는 자식프로세스 개수를 150개로 변경하였다.

이만하면 충분히 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 까지 늘렸다. 그리고 테스트를 하였다.

/etc/php-fpm.d/www.conf
pm.max_children = 150
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 15

fpm 을 재시작하여 적용후에 rds의 모니터링을 확인했다.

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의 파라미터그룹은 디폴트 파라미터그룹을 수정할수 없다. 따로 생성하여 수정해야 한다.

Auto Scaling 으로 추가된 인스턴스다.

내블로그로 rds를 죽이는건 실패했다……아마 인스턴스 사이즈를 늘려서 메모리와 cpu를 더많이 사용한다면 죽일수 있었을거라 생각한다.

다음기회엔 꼭죽이리라..

블로그를 더 많은 게시물과 자료로 꽉꽉체워서 죽여야겠다.

일단………결국 가쉽성의 글이되어 버렸다.
결론을 내지못해 아쉽지만 fpm 최적화가 누군가에겐 도움이 될거라 생각한다.

좋은하루 되시라!

aws에서 MariaDB galega Cluster 사용하기 ver.2

지난 포스팅에 이어서 맺음하는 포스팅이다.
계획은 일주일 이었으나 이주 가까이 galera를 사용하였다.

이주동안 사용량이나 봇들의 동태 이것저것 모니터링을 했지만..
부하가 없었다.. 그래서 부하테스트는 직접하기로 마음을 먹었다!

먼저 비용부터 보자.

Cost Explorer 에서 일별 서비스별로 본 그래프이다.
여기서 중요한건 EC2 비용인데 0.47$ 정도다. t3.nano 3대 하루 비용인데 1달정도 하면 14.1$ 정도 나온다. 정말 얼마 안나온다. 깜짝놀랄정도.

그렇다면 성능을 확인해 볼까?

구성을 나열하자면 NLB-mariaDB-cluster(t3.nano 3ea) 간단한 구성이다.

지금 이 블로그로 테스트를 진행하여 보았다.

부하테스트 툴은 jmate를 사용하였다.

1초동안 100명의 USER가 접속을 시도하고 30초간 유지이다.

총 3000번의 접근을 하게된다.

http://linuxer.name 으로 http request 를 하도록 설정하였다.

web인스턴스의 CPU / memory 지표이다.
실제로는 보이는 지표의 2배정도 된다고 보면된다. 5분 평균이라 실제 부하보다 낮은 값으로 보인다. 실제 cpu 부하는 100%라고 보면 된다. 23:45이 galera 00:15 rds다.

나중에 생각해보니 왜 rds 의 그래프가 더 낮을까 의문이 들었는데 rds max connection 때문에 정상적으로 부하가 제한된것 같다. 이런.. 라고 생각했는데 아니었다..그냥 웹서버 php-fpm 제한이었다 ㅠㅠ

galera 인스턴스다. 그래프의 평균치라 마찬가지다. 두배정도의 부하가 발생했다고 생각하면 된다. 합쳐서 11%정도의 부하가 발생했다. 그래프에서 안보이는데 A/C의 부하가 동일하게 나타났다.

RDS로 옮긴후에 테스트진행하였다. 13%정도의 부하가 발생하였다. 이때

rds max connection은 꽉찬 상태였다. 이결과로만 보면 내 블로그는 max 커넥션을 더늘려도 괜찮은 거로 보인다. 사용자원에 비해 기본값 max connection 이 낮은 편이라는 결론이 난다.

각설하고 일단 단순비교시에 galera와 rds 의 성능차는 거의 없어 보인다.

비용차이는 NLB 비용이 cost explorer에서 추가되지 않아서 확인할수 없었다.
그런데 free tire 에서는 NLB가 포함되지 않는데 이상하게 청구되지 않고 있다…땀삐질 너무 쓰는게 없어서 그런가..

현재 galera에서 RDS로 전환한 상태이고 마지막 테스트 까지 진행하였다.

추가테스트를 한다면 web서버의 처리량을 늘리고 최대사용자를 테스트하는 방식으로 가야 할것으로 보인다.

이 테스트는 다른것보다 galera가 어느정도 사용가능한 수준이라는 것을 알게 된 과정이었다.

다음에 기회가 된다면 좀더 딥한 성능테스트를 진행해보겠다.

좋은하루되시라!

aws 에서 MariaDB galera cluster 설치하기!

오늘은 실험적인 포스팅을 하려고 한다.
mariadb galera다.

사실 aws에 galera를 셋팅하는것은…RDS때문에 아이러니한 선택일수 있으나,
온프레미스에서 쉽사리 셋팅하기 어려운 구성인 galera를 테스트 해보기로 하였다.

사실 이글을 쓰는 지금은 이미..블로그가 galera 위에서 돌고있다.

준비물을 챙겨보자.

galera의 구성에는 multi-AZ를 위한 여러개의 서브넷이 필요하다.

한국리전의 A/B/C zone 을 모두 사용한다.

그리고 인스턴스를 생성한다.

인스턴스는 t3.nano를 활용하였다. 사용자가 많지 않아서 nano로 버틸수 있을거라 생각했다.

이과정에서 인스턴스만 5번이상을 만들었다 지웠다를 반복했는데 그이유는 B영역 때문이었다. 처음엔 t2.nano를 사용하려했으나 B영역에서 not support 발생으로 평소 사용해보고 싶었던 t3a 계열을 사용해 보려고 했으나, 마찬가지로 not support상태.. 결국 돌아서 t3.nano를 사용하게 되었다.

사용한 ami는 amazon linux 2 다.

인스턴스 생성후 보안 그룹은 따로 galera-sg를 생성하여 galera 인스턴스 끼리는 통신이 되도록 설정하고 웹서버 내부 IP로 3306만 열어 주었다.

인스턴스 셋팅할때는 EIP를 붙이고 작업하였다.

galera 셋팅은 아래와 같다.

#vi /etc/yum.repos.d/mariadb.repo

아래내용 삽입
설치할 mariadb 는 10.4 버전이다.

#MariaDB 10.4 CentOS repository list – created 2019-09-10 11:12 UTC
#http://downloads.mariadb.org/mariadb/repositories/
[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

:wq 후에 정상적으로 repo를 생성했다면 아래 설치명령어가 정상적으로 작동한다.

#yum install MariaDB-server MariaDB-client

정상적으로 설치가 되면 아래 패키지가 설치된다. yum.log에서 확인했다.

Sep 10 11:37:04 Installed: perl-Data-Dumper-2.145-3.amzn2.0.2.x86_64
Sep 10 11:37:04 Installed: MariaDB-common-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:05 Installed: MariaDB-compat-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:05 Installed: boost-program-options-1.53.0-27.amzn2.0.3.x86_64
Sep 10 11:37:06 Installed: galera-4-26.4.2-1.rhel7.el7.centos.x86_64
Sep 10 11:37:06 Installed: perl-Compress-Raw-Bzip2-2.061-3.amzn2.0.2.x86_64
Sep 10 11:37:06 Installed: ncurses-compat-libs-6.0-8.20170212.amzn2.1.2.x86_64
Sep 10 11:37:08 Installed: MariaDB-client-10.4.7-1.el7.centos.x86_64
Sep 10 11:37:08 Installed: perl-Net-Daemon-0.48-5.amzn2.noarch
Sep 10 11:37:08 Installed: 1:perl-Compress-Raw-Zlib-2.061-4.amzn2.0.2.x86_64
Sep 10 11:37:08 Installed: perl-IO-Compress-2.061-2.amzn2.noarch
Sep 10 11:37:08 Installed: perl-PlRPC-0.2020-14.amzn2.noarch
Sep 10 11:37:08 Installed: perl-DBI-1.627-4.amzn2.0.2.x86_64
Sep 10 11:37:25 Installed: MariaDB-server-10.4.7-1.el7.centos.x86_64

설치가 완료되면 클러스터 설정을 한다.

#vi /etc/my.cnf.d/server.cnf

간단하게 테스트하기 위해 아래내용을 붙여 넣어도 좋다.

[mysql]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
bind-address=0.0.0.0
user=mysql
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW
log-error=/var/log/mysqld.logdatadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
bind-address=0.0.0.0
user=mysql
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=128M
binlog_format=ROW
log-error=/var/log/mysqld.log

같은파일 하단에 [galera] 탭에 아래 내용을 설정한다.

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so
wsrep_node_name=’galera1′
wsrep_node_address=”10.0.4.27″
wsrep_cluster_name=’linuxer-galera’
wsrep_cluster_address=”gcomm://10.0.4.9,10.0.4.27,10.0.4.43″
wsrep_provider_options=”gcache.size=300M; gcache.page_size=300M”
wsrep_slave_threads=4
wsrep_sst_method=rsync

여기서 수정할 내용은
wsrep_node_name=’galera1′
wsrep_node_address=”10.0.4.27″
wsrep_cluster_address=”gcomm://10.0.4.9,10.0.4.27,10.0.4.43″
이 세부분이다. node name 은 노드를 분류할 이름으로 나는 galera1/2/3으로 넣었다.
address 는 IP 인스턴스 각각 내부 IP를 넣어주고 클러스터 address는 클러스터 node address 를 나열한다.

여기까지 완료됬다면 galera 기본설정은 완료이다.

새로 만드는 클러스터일경우

#galera_new_cluster

명령어를 쳐주자. 이미 사용중이던 db를 클러스터로 만든다면 각각 mysql data를 클론뜨거나 dump 하여 데이터의 무결성을 검증할수 있도록 만들어준다음 클러스터로 엮어야한다.

이후 NLB를 추가하여

사용한 A/B/C 영역을 넣어주었고, 대상그룹에 galera cluster 를 넣어주었다.

상태가 healthy로 정상적으로 상태검사를 통과하는것을 확인할수 있었다.

이부분에서 확인할수 있었는데 상태검사를 통과하기 위해선 galera 보안그룹에 NLB가 위치한 subnet의 포트에 대해서 인바운드를 허용해 주어야지만 상태검사가 정상적으로 이루어 지는것을 확인하였다.

나는 이후에 NLB end point 로 rds 에서 db를 dump 하여 부어넣었다.

#mysqldump -h linuxer-blog-rds.com -u user -p DB > /home/linuxer-blog-db.sql

덤프후에 galrera cluster 로 접근하여 grant 권한을 웹서버에 맞춰서 설정해 주었다.

mysql>GRANT ALL PRIVILEGES ON db.* TO user@webserver_internal_ip IDENTIFIED BY ‘password’;

이후에 웹서버에서 밀어 넣었다.

mysql -h linuxer-galera-nlb.com -u user -p < /home/linuxer-blog-db.sql
Enter password:

정상적으로 데이터를 복구하였고 이후에 디비커넥션을 수정하여 rds 에서 galera로 접속되도록 설정하였다.

rds t2.micro

mariadb galera

평균 0.20s 정도 불러오는 속도 차이가 난다.

일주일간 galera cluster를 유지할 생각이다.

galera cost

rds cost

9$정도의 차이이며 아직 file over 테스트는 진행하지 않았다.
multi-AZ활성화 시에 rds 비용이 추가되는것을 생각하면 큰비용은 아니라 생각되지만..기본적으로 multi-AZ로 구성되는 galera의 경우엔 어떤것이 좋다 나쁘다는 아직 결정할수 있느 근거가 부족하였다.

일주일간의 시험테스트와 트러블슈팅 튜닝을 진행하면서 추가 포스팅을 진행하겠다. 읽어 주셔서 감사하다!

포스팅이 슬슬 마르기 시작한 이 시험에 흥미로운 주제를 만들어 주신 바다진주님께 감사를 드린다!

카테고리: aws