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 홍콩/바레인 리전 활성화

홍콩 / 바레인 리전이 리전 리스트엔 있으나 들어가면 활성화 하라고 뜬다.
이전에는 리전 선택버튼이 비활성화로 되어있었다.

여기에서 홍콩이나 바레인 을 선택하면 아래와 같은 페이지가 뜬다.

계속을 눌러서 활성화로 가는것도 가능하다. 그게 아니라면 내계정으로 이동후에

저기 빨간부분에서 활성화 누르면 된다.

…..

원랜 선택이 비활성화 였는데 메뉴가 좀바뀌었다..

뻘쭈미..태그안쓰고 포스팅해야징…

ssm 과 user 디렉토리 퍼미션의 상관 관계

고객사에서 ubuntu user 에 777 퍼미션을 부여해 버렸다.

chmod -R 777 /home

home 디렉토리 하단으로 모든 퍼미션이 777이 부여되었고 ubuntu계정까지 777 권한이라 KEY를 사용하여 로그인을 할수 없는 상태가 되어버렸다.

이경우에 할수있는 방법은 SSM session manager로 접속할수 있다면 간단하게 해결되었을 문제이나 신규로 생성된 인스턴스인터라 SSM을 사용하고 있지 않았다.

이경우엔 다른인스턴스에 /home 파티션만 떼서 붙여서 권한을 복구한다음에 정상화 할수 있었다.

session manager 는 권한과 상관없이 동작하는지 확인하고 싶었다.

세션 매니저로 접속

root 15229 1.0 1.5 543752 15912 ? Sl 10:30 0:00 _ /usr/bin/ssm-session-worker root-0f7a9e1a4bbc90b i-052ebb4feade551
ssm-user 15242 0.0 0.3 124264 3280 pts/0 Ss 10:30 0:00 _ sh

쉘에서 확인시에 세션을 연결하면 위와같이 확인이된다.

유저 접속 확인

root@ip-10-0-0-12 home]# w
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

root@ip-10-0-0-12 home]# last
reboot system boot 4.14.133-113.112 Wed Aug 28 12:43 – 10:34 (21:50)

session manager 는 w나 last에서 확인할수 없다. 로그인 내역은 aws console 에서 확인해야 하고 실제로 인스턴스 내에서 확인하려면 messages 로그에서 확인해야 한다.

Aug 29 11:33:49 ip-10-0-0-12 amazon-ssm-agent: 2019-08-29 11:33:49 INFO [MessageGatewayService] [EngineProcessor] [OutOfProcExecuter] [root-0aa231b76382aca8c] channel: root-0aa231b76382aca8c not found, creatinga new file channel…

Aug 29 11:33:49 ip-10-0-0-12 amazon-ssm-agent: 2019-08-29 11:33:49 INFO [MessageGatewayService] [EngineProcessor] [OutOfProcExecuter] [root-0aa231b76382aca8c] inter process communication started

ssm 세션 생성시에 발생하는 로그다.

이제 ssm user 에 777 부여후에 정상적으로 로그인 되는지 확인해 보겠다.

root@ip-10-0-0-12 home]# chmod 777 -R ssm-user

root@ip-10-0-0-12 home]# ls -al
drwxrwxrwx 2 ssm-user ssm-user 83 Aug 20 22:27 ssm-user

root@ip-10-0-0-12 ssm-user]# ls -al
-rwxrwxrwx 1 ssm-user ssm-user 265 Aug 28 13:26 .bash_history
-rwxrwxrwx 1 ssm-user ssm-user 18 Jul 28 2018 .bash_logout
-rwxrwxrwx 1 ssm-user ssm-user 193 Jul 28 2018 .bash_profile
-rwxrwxrwx 1 ssm-user ssm-user 231 Jul 28 2018 .bashrc

정상적으로 연결되는것을 확인할 수 있었다.

key로 연결되는 계정은 권한으로 인해 접속불가 상태에 빠질수 있지만
session manager 는 인스턴스가 클라이언트가 되어 동작하는 방식이라 user 디렉토리 권한과는 상관없이 정상적으로 접근이 가능한것을 알수있다.

사실 조금 쓸데없는 테스트이긴 하나 도움이 되면 좋겠다!

아디오스!

aws ec2 instance 상태이상 확인

갑자기 블로그가 안열렸다. 따로 모니터링을 설정한건 아니라서 다운된지 몰랐다. 먼저 aws console 에서 인스턴스의 상태를 확인해 보기로 했다.

상태검사를 통과 하지못한 인스턴스가 확인된다. 이럴땐 ec2 상태검사 탭을 확인한다.

서버가 죽은지 벌써10시간째. 모니터링을 설정해 놨어야 했는데 불찰이 느껴진다. 일 단 트러블 슈팅을 시작한다.

첫번째로 로그인을 진행해 본다. ssm 세션매니저를 통해서 접속해본다.

응. 안돼. 돌아가
접속할수 없다.

그럼 차선책으로 인스턴스의 스크린샷을 확인해 본다.

인스턴스 설정에서 시스템로그 가져오기는 dmesg 를 보여준다 그래서 이경우에 필요가 없다. 인스턴스가 행이 아니라 리부팅중 멈추거나 인스턴스 부팅 장애의 경우에는 시스템 로그가져오기로 봐야한다.

메모리…메ㅗㅁㅣㄹ…………!!!!!!!!!!!!!!

프리티어라 죽었다.

재시작은 안되고 인스턴스를 중지한다. 재시작이 안될경우 중지/시작을 해야한다.

EIP 가 연결되지 않은 인스턴스의 경우엔 IP가 변경된다 EIP를 붙여서 사용하자

중지중이다.
중지중에 모니터링 그래프를 확인해 본다.

며칠전 포스팅했던 cloudwatch 를 이용한 메모리와 하드디스크 체크이다.
메모리가 훅 날라간게 보인다.

리부팅 완료하고 인스턴스의 상태가 정상으로 변경되었다. 그렇다면 정확한 이유를 알아야한다.

messages 로그에서 확인한 내용이다 스왑도 없고 메모리도 없어서 죽었다.
사실 프리티어라 swap 이 없다. 이후에 파일스왑으로 2G정도 만들어줄계획이다.

Aug 27 21:19:51 ip-10-0-0-12 kernel: active_anon:214310 inactive_anon:7454 isolated_anon:0#012 active_file:326 inactive_file:360 isolated_file:0#012 unevictable:0 dirty:0 writeback:0 unstable:0#012 slab_reclaimable:3331 slab_unreclaimable:5159#012 mapped:7669 shmem:7487 pagetables:3235 bounce:0#012 free:12190 free_pcp:180 free_cma:0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 active_anon:857240kB inactive_anon:29816kB active_file:1304kB inactive_file:1440kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:30676kB dirty:0kB writeback:0kB shmem:29948kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA free:4464kB min:736kB low:920kB high:1104kB active_anon:11168kB inactive_anon:44kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15904kB mlocked:0kB kernel_stack:0kB pagetables:32kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kBAug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 932 932 932
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32 free:44296kB min:44316kB low:55392kB high:66468kB active_anon:846072kB inactive_anon:29772kB active_file:1304kB inactive_file:1440kB unevictable:0kB writepending:0kB present:1032192kB managed:991428kB mlocked:0kB kernel_stack:6352kB pagetables:12908kB bounce:0kB free_pcp:720kB local_pcp:720kB free_cma:0kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: lowmem_reserve[]: 0 0 0 0
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA: 84kB (UME) 88kB (UME) 1116kB (UE) 932kB (UE) 964kB (UME) 4128kB (UE) 5256kB (UME) 1512kB (E) 11024kB (E) 02048kB 04096kB = 4464kBAug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 DMA32: 10224kB (UE) 4008kB (UE) 24116kB (UME) 13832kB (UME) 14364kB (UME) 61128kB (UE) 12256kB (ME) 13512kB (UE) 21024kB (UM) 02048kB 04096kB = 44296kB
Aug 27 21:19:51 ip-10-0-0-12 kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB

그럼 왜 스왑도 메모리도 없었을까? 웹서버 이므로 웹로그를 확인해 보았다.

어제 급하게 포스팅하느라 업로드한 파일들을 재대로 처리못하고 죽은거다.

아놔~~~~~~~~~~~~

이후로 모니터링 체크하나 만들어서 알럿하도록 설정하는 포스팅을 작성하겠다.

좋은하루 되시라!

사이트는 잘열리는것을 확인할수 있었다!

호텔 델루나 뱃지 없으니 만든다!

장만월 사장의 호텔 델루나에 취업하고 싶은 찰나 완결이 다와가고 있어서 죽어서 취업할 순 없으니…..마음만이라도 델루나에서 함께하고 싶은 마음에 급하게 모델링을 시작했다.

일단 뚝딱 모델링을 끝내고 첫번째 프린트를 시작했다.

사이즈가 좀 작았다. 2cm 에 높이 1.3 얇게 테스트를 해봤는데 생각보다 깔끔하게 나오긴 했으나.. 원한 느낌은 아니었다. 출력시간 6분

갑자기 결론을 내서 미안하다.

3D 프린터가 고장나서 급하게 고치고 뽑느라 결과물만 있다.

가로세로 2.5cm 높이 2mm로 뽑았다. 0.12mm 노즐로 뽑아서 결이 고르지 못하다.

하지만 첫 완성 작인거 같아 포스팅을 한다.

mysql innodb extra backup 스크립트

#엑스트라 백업 설치
rpm -Uhv https://www.percona.com/redir/downloads/percona-release/redhat/percona-release-0.1-4.noarch.rpm

#yum 으로 설치
yum install xtrabackup

#디렉토리 확인
ll /backup
ll /backup/full_backup
ll /backup/incre_backup

#디렉토리 생성
mkdir /backup
mkdir /backup/full_backup
mkdir /backup/incre_backup

#crontab 에 설정
* */1 * * * root /root/bin/mysql_innodb_backup.sh


crontab 와 db_full_backup_time 은 중요합니다.스크립스트는 crontab 실행될때 백업이 되며, db_full_backup_time이 아닐경우 차등백업을 실행합니다.


따라서 1시간마다 백업을하며 db_full_backup_time이 있을경우에 full 백업을 합니다.

아래의 스크립트에서 03 15을 변수로 줄경우 배열로 받아서 참일경우 full 백업 거짓일경우 차등백업을 진행합니다.따라서 새벽 3시 오후3시에 백업을 진행 합니다. 

!/bin/bash

DB Backup

BAK_DIR=/backup;
TODAY=$(date +%Y%m%d –date ’12 hours ago’)

TODAY=$(date +%Y%m%d)

RMTODAY=$(date +%Y%m%d –date ’10 days ago’)

Delete DB File

rm -rf $BAK_DIR/full_backup/$RMTODAY*
rm -rf $BAK_DIR/incre_backup/$RMTODAY*

Backup Time

db_full_backup_time=(“03 15”)

Now Time & Time Check

TOTIME=$(date +%H)

TOTIME=$(date +%H)

echo $TOTIME
in_array() {
local needle array value
needle=”${1}”; shift; array=(“${@}”)
for value in ${array[@]}; do [ “${value}” == “${needle}” ] && echo “true” && return; done
echo “false”
}

db_full_backup_check=in_array $TOTIME ${db_full_backup_time[@]}

if [ “$db_full_backup_check” == “true” ]; then
# full backup
/bin/nice -n 10 /usr/bin/ionice -c2 -n 7 /usr/bin/innobackupex –defaults-file=/etc/my.cnf \
–user=root –password=’1234′ –slave-info –no-timestamp \
–compress $BAK_DIR/full_backup/$TODAY
else
# hot backup
/bin/nice -n 10 /usr/bin/ionice -c2 -n 7 /usr/bin/innobackupex –defaults-file=/etc/my.cnf \
–user=root –password=’1234′ –no-timestamp –compress –incremental \
–incremental-basedir=$BAK_DIR/full_backup/$TODAY $BAK_DIR/incre_backup/$TODAY/$TOTIME
fi

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 사용법은 각자 확인해보시기 바랍니다. 

즐거운 하루되세요~

이상한 주제의 글

필자는 의식의 흐름에 따라서 글을 쓰는것을 아주 잘하는 편이다.

오늘은 주제를 추전받았는데 이상한 주제로 글을쓰라는 추천을 받아서 포스팅을 작성하게 되었다.

이상한 주제라고 하면 결국 치과이야기가 적당할것 같다.

교정 3년차의 프로페셔널 교정러다.

교정이 거의 마무리단계이며 교정과정을 먼저 설명해 보겠다.

일단 엑스레이를 찍어서 견적을 받는다. 300만원으로 견적을 받아서 교정을 시작했다. 교정을 하게 된 이유는 간단하게.. 작은어금니와 어금니 사이에 치아가 삼각꼴을 이루며 덧니로 나게되었다. 이유는 여러가지겠지만 하관이 작아서 치아가 한줄에 다못들어간게 이유라면 이유다.

이 작은송곳니를 뽑았다. 교정시작한 첫날에 뽑았는데 너무 행복했다 덧니사이에 끼는 음식물을 더이상 빼지 않아도 된다는 사실이 너무좋았다.

좋은것은 좋은것이고 너무아팠다.

치아와 모발은 소중한것이니 필자처럼 막뽑지 않는것을 추천한다.

그리고 철길을 깔았다.

1달에 한번씩 치과를 갔다. 치아를 고른 열로 sort 하고 규격에 맞지않는 치아는 뽑았다. 그 규격에 맞지않는 치아가 첫째 작은 어금니이다.

첫 교정하는날 1개 그리고 8개월차쯤에 2개 21개월 차에 1개를 뽑았다.

위아래 작은어금니를 뽑았다 이말이다. 그때부턴가 없어져버린 치아처럼 본인도 위아래가 없어진거 같다.

그렇게 4개의 치아를
root@입안# rm -rf “작은송곳니”
하고 각각 치아마다 철길로 연결되서 가지런하게 배열되었다.

고통의 나날들로 다른사람이 교정한다고 하면 꼭 하라고 할거다. 왜냐고? 나만 아플순 없으니까. 진짜 개아프거든.. 밥먹을때마다 입안이 철사에 찢기고 장치에 베이고..헐고 피가나는건 예사일이다. 느긋하고 성격고치고 싶은 사람은 꼭 교정을 해라 성격베리고 예민해지니까.

말이샛는데 교정은 끝나는게 아니라 유지하는거다.

철길을 뺀다고 교정이 끝나는게 아니라 치아뒷편에 교정을 유지해주는 철사를 평생 붙이고 있어야하고 교정을 유지해주는 유지장치를 일정 기간마다 껴야한다.

아주 귀찮은 일이란 말이다.

그렇기에 추천한다.

필자는 미용상의 이유로 교정을 했다.

거짓말 같겠지만 진짜다.

교정을 하고나니 얼굴 라인이 달라졌다 웃는 모습도 가지런해졌다.

자신감과 신기함에 거울보면서 치아점검을 자주한다.

황니인지라 신경쓰여서 워터픽과 음파칫솔을 애용하는데 이것의 리뷰는 나중에 하고 이상한 주제의 블로깅을 마친다.

cloud watch monitering 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 자격증을 따고난 소감을 한마디로


” 엄청좋다.”

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

즐거운 공부되시라!