gcp VPC 및 network 미션

1.Pub pri.db네트워크 만들고 2.elb설정해오기 .서버는 private만 존재 3.nat도 만들고 서버에서 인터넷접속 확인하기까지.

가 일단 나는 목표인데 청개구리 속성상 미션대로 진행할리가 없다 나는..

먼저 구글은 bastion host 가 대부분의 구성도에서 빠져있다. 외부IP가 없는 상태로 pri 에 속한 네트웤에도 gcp console로 접속을 할수 있는것. 어떤 원리도 작동되는것인지 먼저 파봐야 겠다.

외부IP는 없는상태이다. 방화벽에서 22번만 any 로 열어준 상태로

ssh 가 붙는다. ????? ssh가 맞는지 확인해본다.

다른 세션을 이용하거나 에이전트 방식일줄 알았으나 아니다. 외부의 접속을 받는 상태인거다. 이상태라면 aws 식으로 말하자면 igw 에 연결되어있는 퍼블릭상태에서 퍼블릭IP만 없는 요상한 상태인것으로 정확한 의미에서 망분리가 아닌것이다.

그렇다면 일단 정확한 망분리를 진행해 보기로 하였다.

외부로 핑이 간다. 그렇다는건 인터넷으로 연결된 라우팅을 가지고 있다는것!

그렇지만 Private google access 를 껏다 키며 테스트를 진행해 보았으나 결과는 같았다.

[hoceneco@instance-1 ~]$ ping google.comPING google.com (74.125.124.113) 56(84) bytes of data.

ping 이 외부의 IP를 정상적으로 가져온다. 그럼 인터널 DNS가 존재하는 걸까?

internal dns 가 존재하는걸 확인했다. 내부 DNS 가 응답하므로 IP만 가져오는것이다. 그렇지만 이게 완벽하게 Private subnet인지는 알수없다.

$ last
hoceneco pts/1 35.235.240.242 Fri Nov 29 11:47 still logged in
hoceneco pts/0 35.235.240.240 Fri Nov 29 11:39 still logged in
reboot system boot 4.18.0-80.11.2.e Fri Nov 29 11:26 still running

외부에서 접근 IP가 찍히기 때문. 고민이 많이되었다. Private subnet 이여야 DB를 생성할수 있는 기반이 생기는것인데 구글에선 인스턴스가 에이전트로 통신하는 방식이 아닌 ssh 를 사용하기떄문에 nat를 사용하여 인스턴스 까지 도달한다 생각하므로 일반적인 망분리의 기준에서 매우 벗어나는 것이다.

https://cloud.google.com/vpc/docs/private-google-access?hl=ko

링크를 보면

비공개 Google 액세스

비공개 Google 액세스를 사용하면 비공개 IP 주소만 있는 GCP 인스턴스가 네트워크의 방화벽 규칙에 따라 Google API 및 서비스의 공개 IP 주소에 액세스할 수 있습니다.

비공개 Google 액세스 및 VPC 서브넷

비공개 Google 액세스 기능은 Google 공개 API로 송신되는 트래픽이 확인되면 이를 가로채 Google 내부로 라우팅합니다. 비공개 Google 액세스 서브넷에 있는 VM과 Google API 간의 트래픽은 항상 Google 네트워크 내에서 유지됩니다.

그렇다. 자동 내부라우팅 기능일 뿐이었다.

오 그럼 db통신을 공개 API로 진행하면 내부라우팅으로 자동으로 전환해준다는것. 결국 실제 Private subnet의 사용은 아닌것이다.

이글은 스터디 이전에 작성되었고 스터디 이후 어느정도 생각이 정리되었다.

생각을 정리하기 위해서 테스트한 내용이다.

External IP 가 없는 인스턴스와 External IP 이 부여된 인스턴스 두가지를 생성하였다.

Internal IP만 존재하는 인스턴스는 외부와 통신할수 없다. 신기하게 console SSH로는 붙는다. AWS 의 구체화된 망구성과는 다르게 GCP의 망분리 구성은 구체적인 부분이 있지만 AWS와는 다른 개념이었다.

AWS의 망구성은 계층적이고 구체적인데 GCP의 망구성은 단순하다.

다른 표현이 딱히 있는거 같지 않다. External IP의 유무로 public / private 을 나눈다. 글로벌 인프라로 VPC를 생성하고 리전에 subnet이 종속된다. subnet 하단에 az가 나눠지게 된다. AWS의 역할별 subnet은 만들순 있으나 GCP에선 의미가 없는것이다.

테스트를 위해서 Internal IP만 가진 인스턴스를 로드벨런서에 연결했다.

인스턴스는 instance-group1 에 묶여서 로드벨런서에 연결했다.

로드벨런서의 구성은 차차 언급하기로하고 NAT가 없는 상태의 인스턴스이지만 로드벨런서의 요청에는 착실히 응답하였다. 만족스럽다.

만족스러운 이유는 따로있다. GCP는 private 인스턴스 임에도 불구하고 ssh 접속으로 작업이 가능하고, 로드벨런서 또한 잘되니까 보안도 챙기는데 작업도 편한 그런느낌이다.

정상적인 네트워크의 테스트를 위해서 Cloud NAT 또한 넣어서 진행했다.

NAT 생성은 단순하다.

NAT name / VPC / Region / Nat route / IP 옵션만 지정해주면 바로 생성이된다.

로드벨런서는 먼저 세가지로 분류가 되는데 선행되어야 하는 작업이 있다.
인스턴스 그룹을 생성해야한다. 인스턴스 그룹은 managed / unmanaged 로 나뉜다.

빠른 관리형이냐 아니냐로 생각하면 편하다.

https://cloud.google.com/compute/docs/instance-groups/?hl=ko

링크를 참조하자.

인스턴스 그룹을 만들었으면 LB를 생성할수 있는데 backend / frontend / Host and path rules 을 설정하면 로드벨런서를 생성할수 있다. AWS 서비스에 매칭해서 보면

backend는 대상그룹 frontend 는 리스너 Host and path rules 은 규칙이라 생각하면 된다.

AWS와는 제일큰 다른점은 오토스케일링이 인스턴스 그룹에서 굉장히 직관적인 방식으로 지원한다는 점이다. 또한 로드벨런서의 엔드포인트가 애니캐스트로 IP가 1개만 나온다. 다른 로드벨런서처럼 zone apex에 대한 고민을 하지 않아도 된다는 것이 굉장한 장점이다.

로드벨런서가 CDN을 지원하는건 좀 충격이었다.

일단 gcp는 vpc 그리고 인스턴스 개개별이 공개와 비공개로 설정되어 따로 망에 대한 설정이 필요없는 점. 그리고 로드벨런서의 애니캐스트가 장점인것을 알게되었다.

정리해야지 하고 생각하다가 오늘에서야 정리하지만 유익한 스터디였다.

aws cloud practitioner 후기

11월 25일 12시쯤 시험의 필요성이 생겨서 27일 2시30분 시험으로 예약했다.

saa – sap 시험의 경험이 있고 기본적인 aws 에 대한 경험이 있기 때문에 시험에 대한 걱정은 없었다.

대략적인 개념을 정리했다.

민첩성 탄력성 리전 가용영역 엣지 로케이션 쉴드 waf tco 책임공유모델 마켓플레이스 고객책임 RDS EC2 통합빌링 조직 s3 서포트 플랜 cloudfront

문제에서 봤던 내용을 정리해봤다.

practitioner 자격증은 깊은 지식을 요구하지 않으나 비슷한 유형의 다른 답안을 요구하는 문제들이 많았다.

예를 들면 ddos 를 막는 문제를 냈다면 기본적으로 쉴드가 ddos 를 막지만 waf의 경우에도 ddos 를 막는 방법이 있으므로 문제가 의미하는 바를 정확하게 알아야 한다.

ex) 해당 활동이 DDoS 공격임을 확인할 경우 직접 AWS WAF 규칙을 생성하여 공격을 완화할 수 있습니다

따라서 문제가 의미하는 바를 정확이 파악하는 능력이 있어야 쉽게 풀수 있을거라 생각한다.

문제는 60문제로 90분의 시간이 주어진다. 시험은 한글로 진행했다.

나는 15분정도 걸려서 시험을 완료했다.

11문제 정도가 복수의 답을 요구했으며 정확히 알지 않을경우 시험을 탈락시키겠다는 의도가 분명해 보였다.

시험은 합격했으며 커트라인인 700 점에서 훌쩍넘은 기록이었다.

즐거운 자격증 공부였다.

cloudwatch log 매트릭 경보 생성 – log monitoring

오늘의 주제는 인스턴스에서 발생하는 로그를 cloudwatch 로 전송하여 사용하는 법을 포스팅 할거다.

먼저 역할에 정책부터 생성해 보자. 사용하는 정책은 아래와 같다.

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“logs:CreateLogGroup”,
“logs:CreateLogStream”,
“logs:PutLogEvents”,
“logs:DescribeLogStreams”
],
“Resource”: [
“arn:aws:logs:*:*:*”
]
}
]
}

역할을 인스턴스에 부여하고 인스턴스 내부에서 패키지를 설치해야 한다.

나는 이미 이전에 테스트로 설치해 뒀다.

설치로그이다.

Nov 18 17:17:19 Installed: aws-cli-plugin-cloudwatch-logs-1.4.4-1.amzn2.0.1.noarch
Nov 18 17:17:20 Installed: awslogs-1.1.4-3.amzn2.noarch

실제 설치방법은 yum install 이나 wget 으로 받아 실행하는 방법이 있다.

# yum install awslogs -y

or

# curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O
# python ./awslogs-agent-setup.py –region ap-northeast-2

리전지정 옵션을 넣어주는게 좋다 그렇지 않으면 따로 지정해야 한다.

# vi /etc/awslogs/awscli.conf
[plugins]
cwlogs = cwlogs
[default]
region = ap-northeast-2

그리고 cloudwatch 로 전송할 로그를 지정한다.

# vi /etc/awslogs/awslogs.conf
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

테스트를 위해 /var/log/messages 를 cloudwatch 로 전송하는 로그이다.

log_stream_name = test
initial_position = end_of_file
log_group_name = linuxer-blog-WG

세개의 옵션이 중요하다. end_of_file 은 뒤부터 추가되는 로그를 watch 로 전송한다.

amazon linux 2 는 systemctl 명령어로 서비스를 시작한다

# systemctl restart awslogsd

설정대로 로그가 올라 오는게 보인다.

중요한 부분은 이벤트 만료시점을 지정해서 로그로 전송된 용량이 과하게 쌓이지 않도록 해야한다.

로그 그룹을 체크하면 지표 필터 생성 버튼이 활성화 되고 지표를 생성한다.

지표는 대충 만들어 볼까한다.

HealthCheck 라는 이름으로 패턴을 설정했다. 보면 샘플로그에서 일치하는 패턴이 보인다. 그리고 지표를 할당한다.

지표생성은 커스텀 매트릭으로 비용이 발생할수 있으니 조심하도록 하자.

생성된 지표를 확인하면 위와같다. 그럼 지표를 확인해보자.

커스텀메트릭이 정상적으로 만들어진걸 확인할수 있다.

그래프도 잘생성 됬는지 보면 잘 올라오는게 보인다. 그럼 실제 로그가 발생해서 그래프가 생성됬는지 확인해보자.

로그가 올라와서 매트릭이 생성된것을 확인할수 있다. 그럼이제 경보를 생성해 보자.

뭔가 훅지나간거 같겠지만 빠진부분은 sns 설정 뿐이다. SNS는 주제를 만들고 구독을 생성하고 구독으로 watch 에서 sns를 추가하면 된다.

경보생성하는 방법은 따로 자세하게 설명하겠다. 블로깅이 시리즈 물이 될 기미가 보인다.

그래프처럼 임계치를 지나서 경보상태로 변경됬다가 정상으로 업데이트가 되는 과정이 보인다 정상적으로 지표로 경보가 작동하는것 까지 확인 되었다.

오늘의 목표인 로그전송으로 지표생성 후 경보 생성까지 완료되었다.

이케이스는 tomcat log로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.

자세하게 만들고 싶었는데 흐름만 구성한거 같아 좀 찜찜한 부분은 차차 보강하겠다.

읽어주셔 감사하다!

AWS ALB 규칙 설정-2

오픈카톡에서 받은 질문이다.

질문을 다시정리하자면

linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com <- 허용하지 않음.

이름: linuxer-blog-alb-1657105302.ap-northeast-2.elb.amazonaws.com
Addresses: 13.125.124.26
15.164.132.46

13.125.124.26 <- 허용하지 않음
15.164.132.46 <- 허용하지 않음
test.linuxer.name <-허용하지 않음

linuxer.name <- 허용
www.linuxer.name <-허용
리눅서.com <-허용

iptables 마냥 deny 정책 위에 allow 를 올려준다 생각하면 간단하다 그럼 여기에서 필요한건 ALB limit 인것 같다. 왜냐? 룰이 많아 질수도 있으니까.

https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/application/load-balancer-limits.html

여러번 공개된 리스너 규칙이다.
80->443으로 연결하고 443리스너는 linuxer-blog-wg 로 전달.. tg인데 왜 wg로 했는지는 아직도 의문이다..생성하면서 졸았나…

규칙을 보면 지난번에 alb 규칙 포스팅에서 셋팅한 그대로다. 그럼 이걸 수정해 줄거다.

route53 에선 따로 전환안해도 먹어서 그냥 입력해봤는데 안먹는다. 퓨니코드로 변환해서 넣자

이제 그럼 https://test.linuxer.com 으로 들어가보자. 503 error 이 그대를 맞이할것이다.

그럼 원하지 않는 문자열이나 쿼리를 503으로 띄우고 싶다면?

먼저

내 IP를 확인했다.

소스 IP로 /wp-admin 을 blackhole 처리를 하고 특정 IP 하나만 열어 주었다.

https://linuxer.name/wp-admin.php

접속해 보시라. 503 error 가 반길것이다.

사실 요즘 admin 페이지로 유입이 있어서 wp-admin 막는거로.. 오늘 fail2ban 포스팅을 하려고 계획했는데 실패했다.

alb에서 막아버려서…

블로깅을 할수있도록 포스팅거리를 주신 이주호님께 감사를 드린다.

좋은하루 되시라!

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

페이스북 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 ” 이다.

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

AWS ALB 규칙 설정

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 등을 뜻 합니다.

VPC
EC@
EBS
ELB
EIP

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

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

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

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

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

security group

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



Network access control list

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

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

RDS

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 인증을 사용하는것이 아니면 기능상의 문제는 없으나….

이벤트에 의해 강제로 리부팅되고 단절에의해 서비스에 장애가 생기는거 보단 미리하는것이 나을것이라 생각한다.

한섭님의 좋은 궁금증이었다.

한섭님께 감사를 드린다!

centos8 rdate의 행방

지금까지 rdate로 시간동기화를 강제로 맞췄다.

ntp를 써도 됬지만 centos5에서 적응한 방식이라 레거시에서 벗어날수 없었다.

ansible 테스트중에 알게됬다.

rdate 가 설치되지 않았다.

TASK [rdate] *
fatal: [13.125.94.121]: FAILED! => {“changed”: false, “failures”: [“rdate 일치하는 패키지 없음”], “msg”: “Failed to install some of the specified packages”, “rc”: 1, “results”: []}
…ignoring

centos8 은 4점대 커널이다. centos7은 3점대고.

이커널 차이에서 오는 가장 큰차이점은 ntp 가 기본이냐, chronyd가 기본이냐다.

centos8 부턴 chronyd 기본지원이므로 이전과 같이 불편하게 설정하지 않아도 될것같다.

[root@ip-172-31-45-50] ~# uname -a
Linux ip-172-31-45-50.ap-northeast-2.compute.internal 4.18.0-80.7.1.el8_0.x86_64 #1 SMP Sat Aug 3 15:14:00 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@ip-172-31-45-50] ~# rpm -qa | grep chronyd
[root@ip-172-31-45-50] ~# rpm -qa | grep chrony
chrony-3.3-3.el8.x86_64