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로 지표를 생성하거나 어플리케이션에서 에러가 발생한 로그 경보를 생성시키는 등으로 사용할 수 있다.

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

읽어주셔 감사하다!

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

페이스북 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 기본 교육자료

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 인프라의 설명을 마치겠습니다.

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도 잘추가되고!

웹사이트도 잘열리고!

감사합니다.

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 Certified Solutions Architect – Professional Level Sample Exam Questions 풀이 02

문제는 아래 URL 에서 발췌하였다.

https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf

영문
You are building a website that will retrieve and display highly sensitive information to users.
The amount of traffic the site will receive is known and not expected to fluctuate.
The site will leverage SSL to protect the communication between the clients and the web servers.
Due to the nature of the site you are very concerned about the security of your SSL private key and want to ensure that the key cannot be accidentally or intentionally moved outside your environment.
Additionally, while the data the site will display is stored on an encrypted EBS volume, you are also concerned that the web servers’ logs might contain some sensitive information; therefore, the logs must be stored so that they can only be decrypted by employees of your company.
Which of these architectures meets all of the requirements?

A) Use Elastic Load Balancing to distribute traffic to a set of web servers. To protect the SSL private key, upload the key to the load balancer and configure the load balancer to offload the SSL traffic. Write your web server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.
B) Use Elastic Load Balancing to distribute traffic to a set of web servers. Use TCP load balancing on the load balancer and configure your web servers to retrieve the private key from a private Amazon S3 bucket on boot. Write your web server logs to a private Amazon S3 bucket using Amazon S3 server-side encryption.
C) Use Elastic Load Balancing to distribute traffic to a set of web servers, configure the load balancer to perform TCP load balancing, use an AWS CloudHSM to perform the SSL transactions, and write your web server logs to a private Amazon S3 bucket using Amazon S3 server-side encryption.
D) Use Elastic Load Balancing to distribute traffic to a set of web servers. Configure the load balancer to perform TCP load balancing, use an AWS CloudHSM to perform the SSL transactions, and write your web server logs to an ephemeral volume that has been encrypted using a randomly generated AES key.

이문제는 정말 의견이 분분한 문제이다.

댓글 전쟁에 참전 하고 싶다면 아래 URL을 추천한다.

https://acloud.guru/forums/aws-certified-solutions-architect-professional/discussion/-KVj_o43efIRONfHwq_q/sample_question_4

댓글에 일본판 문제는 답안을 포함하고 있다는 정보를 얻어 일본판을 찾아보았다.

일본어 문제이다.

ユーザーにとって機密性の高い情報を取得して表示するウェブサイトを構築しています。サイトが受信するトラフィックの量 はわかっていて、上下しないと予想されます。このサイトでは、SSL を活用してクライアントとウェブサーバー間の通信を 保護します。サイトの性質のゆえに、SSL プライベートキーのセキュリティについて非常に懸念しており、キーが誤って、または意図的に環境外に移動されることがないようにしたいと思っています。また、サイトで表示されるデータは暗号化され た EBS ボリュームに保存されますが、ウェブサーバーのログに機密情報が含まれることも懸念しているため、自社の従業 員以外には復号化できないようにログを保存する必要があります。すべての要件を満たすのは次のうちどのアーキテクチャです か?
A) Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。SSL プライベートキーを保護 するため、キーをロードバランサーにアップロードして、SSL トラフィックの負荷を軽減するようにロードバランサーを 設定する。ウェブサーバーのログを、ランダムに生成された AES キーを使用して暗号化されているエフェメラルボリュ ームに書き込む。
B) Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。ロードバランサーで TCP ロードバランシング を使用して、起動時にプライベート Amazon S3 バケットからプライベートキーを取得するよ うにウェブサーバーを設定する。Amazon S3 サーバー側の暗号化を使用して、ウェブサーバーのログをプライベー ト Amazon S3 バケットに書き込む。
C) Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。TCP ロードバランシング を実行するようにロードバランサーを設定する。AWS CloudHSM を使用してウェブサー ー上で SSL トランザクションを処理し、Amazon S3 サーバー側の暗号化を使用して、ウェブサーバーのログをプライベート Amazon S3 バ ケットに書き込む。
D) Elastic Load Balancing を使用して、トラフィックを一連のウェブサーバーに分散する。 TCP ロードバランシングを 実行するためにロードバランサーを設定しする。AWS CloudHSM を使用してウェブサーバー上で SSL トランザクションを処理し、ウェブサーバーのログを、ランダムに生成された AES キーを使用して暗号化されているエフェメラルボ リュームに書き込む。

http://media.amazonwebservices.com/jp/certification/AWS_certified_solutions_architect_professional_examsample0701_08_final.pdf

실제로 정답이 하단에 표기되어 있으며, 일본어 판의 답은 D 이다.

구글 번역기
매우 민감한 정보를 검색하여 사용자에게 표시하는 웹 사이트를 구축 중입니다.
사이트에서 수신 할 트래픽의 양은 알려져 있으며 변동하지 않을 것으로 예상됩니다.
이 사이트는 SSL을 활용하여 클라이언트와 웹 서버 간의 통신을 보호합니다.
사이트의 특성상 SSL 개인 키의 보안에 대해 매우 우려하고 있으며 실수로 또는 의도적으로 키를 환경 외부로 이동할 수 없도록합니다.
또한 사이트에 표시 할 데이터는 암호화 된 EBS 볼륨에 저장되지만 웹 서버 로그에는 중요한 정보가 포함될 수 있습니다.
따라서 로그는 회사 직원 만 해독 할 수 있도록 저장해야합니다.
이 중 어느 아키텍처가 모든 요구 사항을 충족합니까?

A) Elastic Load Balancing을 사용하여 트래픽을 일련의 웹 서버에 분산시킵니다. SSL 개인 키를 보호하려면 키를로드 밸런서에 업로드하고 SSL 트래픽을 오프로드하도록로드 밸런서를 구성하십시오. 무작위로 생성 된 AES 키를 사용하여 암호화 된 임시 볼륨에 웹 서버 로그를 작성하십시오.
B) Elastic Load Balancing을 사용하여 트래픽을 일련의 웹 서버에 배포합니다. 로드 밸런서에서 TCP로드 밸런싱을 사용하고 부팅시 프라이빗 Amazon S3 버킷에서 프라이빗 키를 검색하도록 웹 서버를 구성하십시오. Amazon S3 서버 측 암호화를 사용하여 웹 서버 로그를 프라이빗 Amazon S3 버킷에 씁니다.
C) Elastic Load Balancing을 사용하여 트래픽을 웹 서버 세트에 분배하고,로드 밸런서가 TCP로드 밸런싱을 수행하도록 구성하고, AWS CloudHSM을 사용하여 SSL 트랜잭션을 수행하고, Amazon을 사용하여 웹 서버 로그를 프라이빗 Amazon S3 버킷에 쓰고 S3 서버 측 암호화를 사용합니다.
D) Elastic Load Balancing을 사용하여 트래픽을 일련의 웹 서버에 분산시킵니다. TCP로드 밸런싱을 수행하고 AWS CloudHSM을 사용하여 SSL 트랜잭션을 수행하고 임의로 생성 된 AES 키를 사용하여 암호화 된 임시 볼륨에 웹 서버 로그를 쓰도록로드 밸런서를 구성하십시오.

먼저 이문제의 요점을 정리하자면 로그를 암호화 해야되며 어떤 구성이 로그의 암호화를 충족하는지를 물어보는 문제이다.
일단 소거법으로 보자.
A는 키를 로드벨런서에 업로드 하였으므로 오답. 또한 ssl offloading은 서버와 클라이언트간 암호화는 아니다.
B는 가능한 방법이나 일반적인 방법은 아님.
C 는 cloudHSM 이뭔지 부터 알아야 한다. cloudHSM은 문제에서 요구하는 ssl 통신 구성이 가능하다.

https://docs.aws.amazon.com/ko_kr/cloudhsm/latest/userguide/ssl-offload.html

이미지를 참고하기 바란다.
따라서 C는 현재 아키텍처의 요구사항에 충족한다.
D또한 요구사항에 충족하는데 cloudHSM을 사용하고 임시볼륨에 웹서버 로그를 저장한다.
인스턴스가 재부팅될 경우 데이터가 사라지게 되는데 문제에는 로그의 보관기일이 정해져있거나 로그를 남겨야하는 내용은 없다.
따라서 C/D가 갈리게 된다. 개인적으론 답을 C라고 생각하는데 다른 생각이 있으신 분은 답글을 달아주시기 바란다.

일본판에선 D가 정답이므로 시험에 나오면 D를 선택하는게 좋을것 같다.

영문
You are designing network connectivity for your fat client application. The application is designed for business travelers who must be able to connect to it from their hotel rooms, cafes, public Wi-Fi hotspots, and elsewhere on the Internet. You do not want to publish the application on the Internet. Which network design meets the above requirements while minimizing deployment and operational costs?
A) Implement AWS Direct Connect, and create a private interface to your VPC. Create a public subnet and place your application servers in it.
B) Implement Elastic Load Balancing with an SSL listener that terminates the back-end connection to the application.
C) Configure an IPsec VPN connection, and provide the users with the configuration details. Create a public subnet in your VPC, and place your application servers in it.
D) Configure an SSL VPN solution in a public subnet of your VPC, then install and configure SSL VPN client software on all user computers. Create a private subnet in your VPC and place your application servers in it.

구글 번역기
팻 클라이언트 애플리케이션을위한 네트워크 연결을 설계하고 있습니다. 이 응용 프로그램은 호텔 객실, 카페, 공공 Wi-Fi 핫스팟 및 기타 인터넷에서 연결할 수 있어야하는 비즈니스 여행객을 위해 설계되었습니다. 인터넷에 응용 프로그램을 게시하고 싶지 않습니다. 배포 및 운영 비용을 최소화하면서 위의 요구 사항을 충족하는 네트워크 설계는 무엇입니까?
A) AWS Direct Connect를 구현하고 VPC에 대한 개인 인터페이스를 생성하십시오. 퍼블릭 서브넷을 생성하고 애플리케이션 서버를 그 안에 배치하십시오.
B) 애플리케이션에 대한 백엔드 연결을 종료하는 SSL 리스너를 사용하여 Elastic Load Balancing을 구현합니다.
C) IPsec VPN 연결을 구성하고 사용자에게 구성 세부 정보를 제공하십시오. VPC에 퍼블릭 서브넷을 생성하고 애플리케이션 서버를 퍼블릭 서브넷에 배치하십시오.
D) VPC의 퍼블릭 서브넷에서 SSL VPN 솔루션을 구성한 다음 모든 사용자 컴퓨터에서 SSL VPN 클라이언트 소프트웨어를 설치 및 구성하십시오. VPC에 프라이빗 서브넷을 생성하고 애플리케이션 서버를 배치하십시오.

팻 클라이언트
https://ko.wikipedia.org/wiki/팻_클라이언트

많은 기능을 제공하는 어플리케이션을 인터넷에 게시하지 않고 배포하고 싶다.
이건 vpn이다. 그리고 배포및 운영비용 최소화. 그럼 vpn 을 사용하여 비용 최적화를 해보자

A는 DC를 사용한다 비용최적화에서 오답.
B는 인터넷에 연결되어야 한다. 오답.
C는 IPSec VPN을 사용한다. aws IPSec VPN은
http:// https://docs.aws.amazon.com/ko_kr/vpn/latest/s2svpn/VPC_VPN.html
ipsec vpn으로 vpn 장비가 필요하다. 비용도 든다. 그래서 오답
D는 비용 효율적이며, 문제의 조건에 충족한다. 정답이다.

따라서 D가 정답이다.

영문
Your company hosts an on-premises legacy engineering application with 900GB of data shared via a central file server. The engineering data consists of thousands of individual files ranging in size from megabytes to multiple gigabytes. Engineers typically modify 5-10 percent of the files a day. Your CTO would like to migrate this application to AWS, but only if the application can be migrated over the weekend to minimize user downtime. You calculate that it will take a minimum of 48 hours to transfer 900GB of data using your company’s existing 45-Mbps Internet connection. After replicating the application’s environment in AWS, which option will allow you to move the application’s data to AWS without losing any data and within the given timeframe?
A) Copy the data to Amazon S3 using multiple threads and multi-part upload for large files over the weekend, and work in parallel with your developers to reconfigure the replicated application environment to leverage Amazon S3 to serve the engineering files.
B) Sync the application data to Amazon S3 starting a week before the migration, on Friday morning perform a final sync, and copy the entire data set to your AWS file server after the sync completes.
C) Copy the application data to a 1-TB USB drive on Friday and immediately send overnight, with Saturday delivery, the USB drive to AWS Import/Export to be imported as an EBS volume, mount the resulting EBS volume to your AWS file server on Sunday.
D) Leverage the AWS Storage Gateway to create a Gateway-Stored volume. On Friday copy the application data to the Storage Gateway volume. After the data has been copied, perform a snapshot of the volume and restore the volume as an EBS volume to be attached to your AWS file server on Sunday.

구글 번역본
회사는 중앙 파일 서버를 통해 900GB의 데이터를 공유하는 온-프레미스 레거시 엔지니어링 응용 프로그램을 호스팅합니다. 엔지니어링 데이터는 메가 바이트에서 수기가 바이트에 이르는 수천 개의 개별 파일로 구성됩니다. 엔지니어는 일반적으로 하루에 5-10 %의 파일을 수정합니다. CTO는이 애플리케이션을 AWS로 마이그레이션하려고하지만 주말 동안 애플리케이션을 마이그레이션하여 사용자 중단 시간을 최소화 할 수있는 경우에만 해당합니다. 회사의 기존 45Mbps 인터넷 연결을 사용하여 900GB의 데이터를 전송하는 데 최소 48 시간이 소요될 것으로 계산합니다. AWS에서 애플리케이션 환경을 복제 한 후 데이터 손실없이 주어진 기간 내에 애플리케이션 데이터를 AWS로 이동할 수있는 옵션은 무엇입니까?
A) 주말 동안 대용량 파일에 대해 다중 스레드 및 다중 부분 업로드를 사용하여 데이터를 Amazon S3에 복사하고 개발자와 병행하여 Amazon S3를 활용하여 엔지니어링 파일을 제공하도록 복제 된 애플리케이션 환경을 재구성합니다.
B) 마이그레이션 1 주일 전부터 금요일 아침에 최종 동기화를 수행하고 동기화가 완료된 후 전체 데이터 세트를 AWS 파일 서버에 복사하여 애플리케이션 데이터를 Amazon S3에 동기화합니다.
C) 금요일에 애플리케이션 데이터를 1TB USB 드라이브에 복사하고 토요일 배달을 통해 USB 드라이브를 AWS Import / Export로 전송하여 EBS 볼륨으로 가져 오면 결과 EBS 볼륨을 AWS 파일 서버에 마운트합니다. 일요일에.
D) AWS Storage Gateway를 활용하여 게이트웨이 저장 볼륨을 생성합니다. 금요일에 애플리케이션 데이터를 Storage Gateway 볼륨에 복사하십시오. 데이터를 복사 한 후 볼륨의 스냅 샷을 수행하고 일요일에 AWS 파일 서버에 연결할 EBS 볼륨으로 볼륨을 복원하십시오.

이문제는 굉장히 기분이 나쁜 유형의 문제이다. 하지만 마이그레이션 문제로 단골문제인거 같다.

먼저 900G를 aws로 마이그레이션 하는것이다. 45mbps로 이동시간은 2일이다.

A 회선이 느리므로 병목이 발생한다. 멀티파트 업로드가 소용이 없다. 오답이다.
B 파일의 변경이 많이 발생하지 않으므로 가능한 방법이다.
C의 경우 굉장히 긴가민가 했다. AWS Import/Export Disk는 일부리전에서 사용가능하긴 하나 인터넷을 사용하지 않음으로 병목도 없고
도착시부터 업로드가 시작되어 정상적으로 작업이 진행될것이라 생각했지만 usb 메모리의 속도는 그보다 떨어진다. 그래서 정해진 시간에 마이그레이션이 불가능하다는 결론에 도달했다.
그 결론에 도달한 이유는 ‘데이터 로드 시간은 기본적으로 디바이스 속도에 의해 좌우’ 아래 URL을 참고하기 바란다.
https://aws.amazon.com/ko/snowball/disk/faqs/
D AWS Storage Gateway는 네트워크를 이용하므로 동일하게 병목이 발생한다 따라서 오답이다.

그래서 위 문제의 정답은 B다.

AWS Certified Solutions Architect – Professional Level Sample Exam Questions 풀이 01

문제는 아래 URL 에서 발췌하였다.

https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf

번역은 google 번역기이며 알아보기 어려운 부분을 조금 수정하였다.
실제 수정한것은 3번문제 조금이며 대부분 구글번역기를 의지하였다.

이번 글에선 3번문제 까지 풀이하였으니 참고바란다.

오역은..구글신님께 확인하시길 바란다.

틀린문제나 오역 오타 테클 환영하오니 이상한부분이 있다면 언제든 댓글달아 주시라!

1번 문제다.

원문
Your company’s on-premises content management system has the following architecture:
– Application Tier – Java code on a JBoss application server
– Database Tier – Oracle database regularly backed up to Amazon Simple Storage Service (S3) using the Oracle RMAN backup utility
– Static Content – stored on a 512GB gateway stored Storage Gateway volume attached to the application server via the iSCSI interface
Which AWS based disaster recovery strategy will give you the best RTO?
Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server.
Deploy the Oracle database on RDS. Deploy the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon Glacier. Generate an EBS volume of static content from the Storage Gateway and attach it to the JBoss EC2 server. (Glacier does help to give best RTO)
Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content by attaching an AWS Storage Gateway running on Amazon EC2 as an iSCSI volume to the JBoss EC2 server. (No need to attach the Storage Gateway as an iSCSI volume can just create a EBS volume)
Deploy the Oracle database and the JBoss app server on EC2. Restore the RMAN Oracle backups from Amazon S3. Restore the static content from an AWS Storage Gateway-VTL running on Amazon EC2 (VTL is Virtual Tape library and doesn’t fit the RTO)

번역본
회사의 온-프레미스 콘텐츠 관리 시스템에는 다음과 같은 아키텍처가 있습니다.
– 응용 프로그램 계층 – JBoss 응용 프로그램 서버의 Java 코드
– 데이터베이스 계층 – Oracle RMAN 백업 유틸리티를 사용하여 정기적으로 Amazon Simple Storage Service (S3)에 백업 된 Oracle 데이터베이스
– 정적 컨텐츠 – iSCSI 인터페이스를 통해 애플리케이션 서버에 연결된 스토리지 게이트웨이 볼륨이 512GB 게이트웨이에 저장
최고의 RTO를 제공하는 AWS 기반 재해 복구 전략은 무엇입니까?
A) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. 스토리지 게이트웨이에서 정적 컨텐츠의 EBS 볼륨을 생성하여 JBoss EC2 서버에 연결하십시오.
B) RDS에 Oracle 데이터베이스를 배포하십시오. EC2에 JBoss 앱 서버를 배포하십시오. Amazon Glacier에서 RMAN Oracle 백업을 복원하십시오. 스토리지 게이트웨이에서 정적 컨텐츠의 EBS 볼륨을 생성하여 JBoss EC2 서버에 연결하십시오.
C) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. Amazon EC2에서 실행중인 AWS Storage Gateway를 iSCSI 볼륨으로 JBoss EC2 서버에 연결하여 정적 컨텐츠를 복원하십시오. iSCSI 볼륨이 EBS 볼륨을 생성 할 수 있으므로 스토리지 게이트웨이를 연결할 필요가 없습니다.
D) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. Amazon EC2에서 실행되는 AWS Storage Gateway-VTL에서 정적 컨텐츠를 복원합니다.

이 문제를 알기 위해선 먼저 알아야할것들이 있다. 이 문제의 주제가 무엇인지 문제를 읽으면 바로 알아야한다. 주제는 재해복구이다.
그럼 두번째로 알아야할것은 문제에서 요구하는 기준이 무엇인가 이다. ‘최고의 RTO(recovery time objective)’이다.

https://zetawiki.com/wiki/%EB%B3%B5%EA%B5%AC%EC%8B%9C%EC%A0%90%EB%AA%A9%ED%91%9C_RPO,_%EB%B3%B5%EA%B5%AC%EC%8B%9C%EA%B0%84%EB%AA%A9%ED%91%9C_RTO

그럼 보기에서 제일빨리 aws로 복구할수 있는 방법을 찾으면 된다.

참 쉽죠?

방법을 찾기전에 구성을 먼저 뜯어보자.

jboss를 aws에 구축한다면 역시 ec2외엔 답이없다.
데이터 베이스는 Oracle RMAN으로 s3로 백업을 한다고 하는데 이건 볼륨 백업이 아니라 데이터베이스 파일 단위의 백업이다.

정적 컨텐츠는 iSCSI로 연결된 스토리지 게이트웨이 512GB다 이것은 스토리지게이트웨이에서 볼륨게이트웨이 그리고 용량 언급이 있었으므로 저장볼륨 방식이다.
저장볼륨 방식으로 사용중이면 스냅샷을 생성해서 EBS볼륨을 생성하여 ec2에 연결하는 작업이 가능하다.

https://docs.aws.amazon.com/ko_kr/storagegateway/latest/userguide/StorageGatewayConcepts.html

정리하자면, aws 로 재해복구시에 최적의 RTO를 가지게 하려면 JBoss를 ec2로 만들고 oracle의 백업본이 있는 s3에서 백업을 복구하고 스토리지 게이트웨이 스냅샷에서 EBS 볼륨을 생성하여 EC2에 연결하면 된다.

정리한 내용에 최대한 부합하는 답변을 골라보자.

A) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. 스토리지 게이트웨이에서 정적 컨텐츠의 EBS 볼륨을 생성하여 JBoss EC2 서버에 연결하십시오.

위 에서 서술한 내용과 흡사하다 지연될 만한 부분은 없다.

B) RDS에 Oracle 데이터베이스를 배포하십시오. EC2에 JBoss 앱 서버를 배포하십시오. Amazon Glacier에서 RMAN Oracle 백업을 복원하십시오. 스토리지 게이트웨이에서 정적 컨텐츠의 EBS 볼륨을 생성하여 JBoss EC2 서버에 연결하십시오.

Glacier에서 백업을 복원하므로 최고의 RTO는 어렵다. 그래서 B는 틀렸다.

C) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. Amazon EC2에서 실행중인 AWS Storage Gateway를 iSCSI 볼륨으로 JBoss EC2 서버에 연결하여 정적 컨텐츠를 복원하십시오.

ISCSI 볼륨을 ec2에 연결해야 하므로 틀렸다 EBS볼륨을 생성하여 연결하는것이 훨씬 빠르다. 그래서 C 도 틀렸다.

D) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. Amazon EC2에서 실행되는 AWS Storage Gateway-VTL에서 정적 컨텐츠를 복원합니다.

AWS Storage Gateway-VTL은 가상 테이프 라이브러리다.
VTL은 테이프 드라이브 단위로 제공되기때문에 문제에서 제공한 512GB 볼륨이 제공되지 않는다. 그래서 D도 틀렸다.

그래서 A가 정답이다.

A) EC2에 Oracle 데이터베이스 및 JBoss 앱 서버를 배포하십시오. Amazon S3에서 RMAN Oracle 백업을 복원하십시오. 스토리지 게이트웨이에서 정적 컨텐츠의 EBS 볼륨을 생성하여 JBoss EC2 서버에 연결하십시오.

2번 문제다.

원문
An ERP application is deployed across multiple AZs in a single region. In the event of failure, the Recovery Time Objective (RTO) must be less than 3 hours, and the Recovery Point Objective (RPO) must be 15 minutes. The customer realizes that data corruption occurred roughly 1.5 hours ago. What DR strategy could be used to achieve this RTO and RPO in the event of this kind of failure?

A) Take 15-minute DB backups stored in Amazon Glacier, with transaction logs stored in Amazon S3 every 5 minutes.
B) Use synchronous database master-slave replication between two Availability Zones.
C) Take hourly DB backups to Amazon S3, with transaction logs stored in S3 every 5 minutes.
D) Take hourly DB backups to an Amazon EC2 instance store volume, with transaction logs stored in Amazon S3 every 5 minutes.

번역본
ERP 애플리케이션은 단일 지역의 여러 AZ에 배포됩니다. 장애가 발생한 경우 RTO (Recovery Time Objective)는 3 시간 미만이어야하고 RPO (Recovery Point Objective)는 15 분이어야합니다. 고객은 약 1.5 시간 전에 데이터 손상이 발생했음을 알고 있습니다. 이러한 종류의 장애 발생시이 RTO 및 RPO를 달성하기 위해 어떤 재해복구 전략을 사용할 수 있습니까?

A) Amazon Glacier에 저장된 15 분 DB 백업을 5 분마다 Amazon S3에 저장된 트랜잭션 로그와 함께 수행하십시오.
B) 두 가용 영역간에 동기식 데이터베이스 마스터-슬레이브 복제를 사용하십시오.
C) 5 분마다 S3에 트랜잭션 로그가 저장된 Amazon S3에 시간별 DB 백업을 수행합니다.
D) Amazon S3에 5 분마다 저장된 트랜잭션 로그를 사용하여 Amazon EC2 인스턴스 스토어 볼륨에 매시간 DB 백업을 수행합니다.

1번 문제와 동일하게 재해복구관련 주제이다. 여기서 주목이야할 단어는 RTO / RPO 다
장애 발생 시점 부터 복구 완료 시점까지 걸리는 시간을 RTO 라고하며 RPO는 데이터를 손실했을떄 감내할수 있는 시간을 RPO라고 한다.

https://zetawiki.com/wiki/%EB%B3%B5%EA%B5%AC%EC%8B%9C%EC%A0%90%EB%AA%A9%ED%91%9C_RPO,_%EB%B3%B5%EA%B5%AC%EC%8B%9C%EA%B0%84%EB%AA%A9%ED%91%9C_RTO

그럼 문제에선 장애 발생시 3시간안에 복구 유실되는 데이터는 15분. 풀어서 쓰자면 서비스는 3시간내에 다시 정상화 되어야 하며, 데이터의 백업로테이션은 최대 15분이다.

문항을 살펴 보자

A) Amazon Glacier에 저장된 15 분 DB 백업을 5 분마다 Amazon S3에 저장된 트랜잭션 로그와 함께 수행하십시오.

Glacier 는 RTO 충족할수 없다. 그래서 틀렸다.
https://aws.amazon.com/ko/glacier/

B) B) 두 가용 영역간에 동기식 데이터베이스 마스터-슬레이브 복제를 사용하십시오.

동기식 복제는 백업이 아니며 장애또한 동기되므로 틀렸다.

C) 5 분마다 S3에 트랜잭션 로그가 저장된 Amazon S3에 시간별 DB 백업을 수행합니다.

5분마다 트랜잭션로그는 RPO에 충족하며 시간마다 DB백업은 RTO를 충족한다.

D) Amazon S3에 5 분마다 저장된 트랜잭션 로그를 사용하여 Amazon EC2 인스턴스 스토어 볼륨에 매시간 DB 백업을 수행합니다.

인스턴스 스토어는 인스턴스가 종료될시에 데이터를 유실하므로 백업의 좋은 방법이 아니다.

따라서 정답은 C다.

3번 문제다.

원문
The Marketing Director in your company asked you to create a mobile app that lets users post sightings of good deeds known as random acts of kindness in 80-character summaries. You decided to write the application in JavaScript so that it would run on the broadest range of phones, browsers, and tablets. Your application should provide access to Amazon DynamoDB to store the good deed summaries. Initial testing of a prototype shows that there aren’t large spikes in usage. Which option provides the most costeffective and scalable architecture for this application?

A) Provide the JavaScript client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) on an EC2 instance to provide signed credentials mapped to an Amazon Identity and Access Management (IAM) user allowing DynamoDB puts and S3 gets. You serve your mobile application out of an S3 bucket enabled as a web site. Your client updates DynamoDB.
B) Register the application with a Web Identity Provider like Amazon, Google, or Facebook, create an IAM role for that provider, and set up permissions for the IAM role to allow S3 gets and DynamoDB puts. You serve your mobile application out of an S3 bucket enabled as a web site. Your client updates DynamoDB.
C) Provide the JavaScript client with temporary credentials from the Security Token Service using a Token Vending Machine (TVM) to provide signed credentials mapped to an IAM user allowing DynamoDB puts. You serve your mobile application out of Apache EC2 instances that are load-balanced and autoscaled. Your EC2 instances are configured with an IAM role that allows DynamoDB puts. Your server updates DynamoDB.
D) Register the JavaScript application with a Web Identity Provider like Amazon, Google, or Facebook, create an IAM role for that provider, and set up permissions for the IAM role to allow DynamoDB puts. You serve your mobile application out of Apache EC2 instances that are load-balanced and autoscaled. Your EC2 instances are configured with an IAM role that allows DynamoDB puts. Your server updates DynamoDB.

번역본
회사의 마케팅 디렉터는 사용자가 임의의 친절한 행동으로 알려진 선의의 목격을 80자 요약을 게시 할 수있는 모바일 앱을 만들도록 요청했습니다. 광범위한 전화, 브라우저 및 태블릿에서 실행될 수 있도록 JavaScript로 응용 프로그램을 작성하기로 결정했습니다. 애플리케이션은 ’80자 요약’을 저장하기 위해 Amazon DynamoDB에 대한 액세스를 제공해야합니다. 프로토 타입을 처음 테스트 한 결과 사용량이 크게 증가하지 않은 것으로 나타났습니다. 이 응용 프로그램에 가장 비용 효율적이고 확장 가능한 아키텍처를 제공하는 옵션은 무엇입니까?

A) EC2 인스턴스에서 TVM (Token Vending Machine)을 사용하여 Security Token Service의 임시 자격 증명을 JavaScript 클라이언트에 제공하여 DynamoDB 넣기 및 S3 가져 오기를 허용하는 IAM (Amazon Identity and Access Management) 사용자에 매핑 된 서명 된 자격 증명을 제공합니다. 웹 사이트로 활성화 된 S3 버킷에서 모바일 애플리케이션을 제공합니다. 클라이언트가 DynamoDB를 업데이트합니다.
B) Amazon, Google 또는 Facebook과 같은 Web Identity Provider에 애플리케이션을 등록하고 해당 제공자에 대한 IAM 역할을 생성하고 S3 가져 오기 및 DynamoDB 넣기를 허용하는 IAM 역할에 대한 권한을 설정하십시오. 웹 사이트로 활성화 된 S3 버킷에서 모바일 애플리케이션을 제공합니다. 클라이언트가 DynamoDB를 업데이트합니다.
C) TVM (Token Vending Machine)을 사용하여 Security Token Service의 임시 자격 증명을 JavaScript 클라이언트에 제공하여 DynamoDB가 넣을 수있는 IAM 사용자에게 매핑 된 서명 된 자격 증명을 제공합니다. 로드 밸런싱되고 자동 확장되는 Apache EC2 인스턴스에서 모바일 애플리케이션을 제공합니다. EC2 인스턴스는 DynamoDB 풋을 허용하는 IAM 역할로 구성됩니다. 서버가 DynamoDB를 업데이트합니다.
D) Amazon, Google 또는 Facebook과 같은 Web Identity Provider에 JavaScript 애플리케이션을 등록하고 해당 제공자에 대한 IAM 역할을 생성하고 DynamoDB Put을 허용하는 IAM 역할에 대한 권한을 설정하십시오. 로드 밸런싱되고 자동 확장되는 Apache EC2 인스턴스에서 모바일 애플리케이션을 제공합니다. EC2 인스턴스는 DynamoDB 풋을 허용하는 IAM 역할로 구성됩니다. 서버가 DynamoDB를 업데이트합니다.

트위터 처럼 문자 제한이 있는 앱이고, JavaScript로 만들어져 있으며 여러 플랫폼에서 사용 가능하고 DynamoDB에 액세스 해야하며 확장성을 지녀야하며 비용 효율적인 아키텍쳐를 선택하면 된다.
사실 주목할점은 확장성과 비용효율이다.

A) EC2 인스턴스에서 TVM (Token Vending Machine)을 사용하여 Security Token Service의 임시 자격 증명을 JavaScript 클라이언트에 제공하여 DynamoDB 넣기 및 S3 가져 오기를 허용하는 IAM (Amazon Identity and Access Management) 사용자에 매핑 된 서명 된 자격 증명을 제공합니다. 웹 사이트로 활성화 된 S3 버킷에서 모바일 애플리케이션을 제공합니다. 클라이언트가 DynamoDB를 업데이트합니다.

EC2 를 사용하므로 확장성을 가지기 어렵다. 확장성에 대한 다른언급이 없으므로 단일인스턴스로 간주한다.

B) Amazon, Google 또는 Facebook과 같은 Web Identity Provider에 애플리케이션을 등록하고 해당 제공자에 대한 IAM 역할을 생성하고 S3 가져 오기 및 DynamoDB 넣기를 허용하는 IAM 역할에 대한 권한을 설정하십시오. 웹 사이트로 활성화 된 S3 버킷에서 모바일 애플리케이션을 제공합니다. 클라이언트가 DynamoDB를 업데이트합니다.

s3 정적 호스팅으로 웹을 호스팅하기에 확장성을 지니는 구성이며, 따로 ec2를 사용거나 하지않기에 비용 효율적이다.

C) TVM (Token Vending Machine)을 사용하여 Security Token Service의 임시 자격 증명을 JavaScript 클라이언트에 제공하여 DynamoDB가 넣을 수있는 IAM 사용자에게 매핑 된 서명 된 자격 증명을 제공합니다. 로드 밸런싱되고 자동 확장되는 Apache EC2 인스턴스에서 모바일 애플리케이션을 제공합니다. EC2 인스턴스는 DynamoDB 풋을 허용하는 IAM 역할로 구성됩니다. 서버가 DynamoDB를 업데이트합니다.
로드벨런싱을 사용하여 확장성을 지니나 비용효율적이지 못하다.

D) Amazon, Google 또는 Facebook과 같은 Web Identity Provider에 JavaScript 애플리케이션을 등록하고 해당 제공자에 대한 IAM 역할을 생성하고 DynamoDB Put을 허용하는 IAM 역할에 대한 권한을 설정하십시오. 로드 밸런싱되고 자동 확장되는 Apache EC2 인스턴스에서 모바일 애플리케이션을 제공합니다. EC2 인스턴스는 DynamoDB 풋을 허용하는 IAM 역할로 구성됩니다. 서버가 DynamoDB를 업데이트합니다.
C와 같은 이유이다. 로드벨런싱을 사용하여 확장성을 지니나 비용효율적이지 못하다.

따라서 정답은 B이다.

aws cloud watch 여러대의 인스턴스에 대한 하나의 경보 생성.ver2

cloudwatch 경보생성 입니다.

여러대의 인스턴스를 하나로 묶어서 경보생성할때 사용하는 방법입니다.

경보 생성을 누릅니다.

지표 선택을 눌러서 지표를 확인합니다.이번에 경보를 생성할 지표는 “CPUUtilization”입니다.

검색하여 체크 후에 ‘그래프로 표시된 지표’ 를 누릅니다.
표시된 지표는 9개 까지 체크하여 추가할수 있습니다.

제한사항으로

 수학표현식을 추가합니다.
수학 표현식은 상황에 따라 잘 사용하기로 바랍니다.https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/using-metric-math.html
이번에는 CPU사용량이 1대라도 70% 를 넘을 경우 경보를 생성할 것이므로 사용한 표현식은 MAX(METRICS()) 입니다.

전체를 체크할 경우 아래와 같이 지표선택 버튼이 활성화 되지 않습니다.

사용할 수학 표현식 하나만 체크해야 생성이 가능합니다.

위와같이 지표를 생성후에 경보생성은 SNS 를 사용해야 하므로 SNS 사용법은 각자 확인해보시기 바랍니다. 

즐거운 하루되세요~

cloud watch monitoring script

WEB console
iam 추가와 watch 지표가 생성 되는 확인만 하면 된다.

필요한 권한
cloudwatch:PutMetricData
cloudwatch:GetMetricStatistics
cloudwatch:ListMetrics
ec2:DescribeTags

policy 생성

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Sid”: “VisualEditor0”,
“Effect”: “Allow”,
“Action”: [
“cloudwatch:PutMetricData”,
“ec2:DescribeTags”,
“cloudwatch:GetMetricStatistics”,
“cloudwatch:ListMetrics”
],
“Resource”: “*”
}
]
}

생성한 정책을 user를 생성하여 부여

Shell 작업

로그인

스크립트를 실행하고 설치하는데 필요한 패키지를 설치한다.

sudo yum install -y perl-Switch perl-DateTime perl-Sys-Syslog perl-LWP-Protocol-https perl-Digest-SHA.x86_64 unzip
cd ~

cloud watch monitering script download

curl https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.2.zip -O

압축해제 및 스크립트 테스트할 경로로 이동

unzip CloudWatchMonitoringScripts-1.2.2.zip && \
rm CloudWatchMonitoringScripts-1.2.2.zip && \
cd aws-scripts-mon

awscreds.conf 생성 및 입력

cp awscreds.template awscreds.conf

vi awscreds.conf
AWSAccessKeyId=
AWSSecretKey=

테스트 명령어 watch 로 전송하지 않음

./mon-put-instance-data.pl –mem-util –verify –verbose

MemoryUtilization: 20.5104909003152 (Percent)
Using AWS credentials file <./awscreds.conf>
Endpoint: https://monitoring.ap-northeast-2.amazonaws.com
Payload: {“MetricData”:[{“Timestamp”:156646131,”Dimensions”:[{“Value”:”i-0baaeb0265″,”Name”:”InstanceId”}],”Value”:20.5104909003152,”Unit”:”Percent”,”MetricName”:”MemoryUtilization”}],”Namespace”:”System/Linux”,”__type”:”com.amazonaws.cloudwatch.v2010_08_01#PutMetricDataInput”}

정상 응답확인

crontab 등록
vi /etc/crontab
#disk metric
*/5 * * * * root /root/aws-scripts-mon/mon-put-instance-data.pl –mem-used-incl-cache-buff –mem-util –disk-space-util –disk-path=/ -disk-path=/home –from-cron

disk-path 는 여러개가 들어가도 상관없다.

systemctl restart crond

설치과정이 정상이라면 아래와같이 linux 시스템으로 지표가 생긴다.

이로서 모니터링 지표 생성까지 포스팅을 마쳤다.

경보생성은 다른 포스팅이 많으니 생략한다.

aws solution architect professional C01 후기

후기는 적어보고 싶었다.

7월 4일 1차시험 7월 31일 2차시험을 봤다.

2차시험에 합격했으며 점수는 아슬아슬하게 761점이었다.

aws solution architect associate 자격증은 17년 11월에 취득했다. 이후로 aws 관련 실무를 했지만 대부분 SE 관련 서버 업무였고 SA 업무를 보게된건 19년 초 부터 이다.

SA pro 자격증은 계속 따고 싶었으나, 결심이 부족했다. 그러다 하루에 한시간씩 공부를 했다. 5월 초부터 1시간씩 매일 공부를 했으니 거의 두달가량을 매일 공부했다고 보면된다.

본격적인 공부는 6월 말경부터 시작했다 그 동안의 공부를 기반으로 제일먼저 풀이한건 예제문제 였다.

https://d1.awsstatic.com/Train%20%26%20Cert/docs/AWS_certified_solutions_architect_professional_examsample.pdf

예제 문제에 나오는 유형을 보고 나온서비스의 FnQ를 모두 보았다,

그리고 모의고사를 두번 봤다. 4만5천원 가량..내10만원..
이건 굉장히 도움이 많이됬다.

그리고 1차시험을 보기전엔 udemy 에서 나온 sap 2019 C01이라고 나온 문제들 3과목정도 봤고 비용은 10-15만원 정도 들었다. 도움이 전혀안된건 아니지만 그렇다고 해서 많은 도움이 된건 아니었다. 이유는 C01 유형이 아니라 C00유형 문제들이었다.

그래서 덤프나 유사유형 문제들이 없는것을 알고는 전략을 수정해서 https://www.aws.training/LearningLibrary
트레이닝을 먼저 다보고 aws 관련 영상을 봤다.

aws korea youtube 에서 거의 대부분의 세션을 봤다.
이것도 어느정도 도움이 됬다.

여기까지 공부하고
https://aws.amazon.com/ko/architecture/?awsf.quickstart-architecture-page-filter=highlight%23new
아키텍처 센터를 한번봤다.

그리고 자격증 백서도 좀봤다
https://github.com/serithemage/AWSCertifiedSolutionsArchitectUnofficialStudyGuide

시험을 앞두고서는 하루에 12시간 정도 공부를해서 4일정도 준비를 했다.
끊임없이 읽고 이해하려는 과정을 거쳤다.

중점적으로 본건 마이그레이션과 장애복구 부분이었다.
코스트 쪽은 주로하는 업무에 기반해서 일반구성도 마찬가지.

시나리오로 시작하는 질문이 대다수 이며 단순기능을 물어보는 질문은 없으니 참고하도록 하자.

sap 자격증을 따고난 소감을 한마디로


” 엄청좋다.”

궁금한 것은 언제든 댓글로 남겨 놓으며 답변해 드리겠다.

즐거운 공부되시라!