Browsing Tag

Amazon Web Service

AWS

[AWS] 수명 주기 관리자를 활용한 스냅샷 백업 (Lifecycle Manager)

안녕하세요. ManVSCloud 김수현입니다.

오늘은 오랜만에 AWS에 관련된 포스팅을 작성해보려 하는데
수명 주기 관리자를 이용하여 스냅샷을 관리하는 방법을 알아보도록 하겠습니다.


수명 주기 관리자 (LIFECYCLE MANAGER)

수명 주기 관리자를 이용하면 Snapshot이나 AMI를 생성하고 이를 원하는 기간을 설정하여 보유 및 삭제 할 수 있습니다. 또한 교차 계정 복사를 이용하여 다른 AWS 계정으로 정기적인 공유가 가능하며 교차 리전 복사를 통해 DR 구성도 쉽게 설정할 수 있습니다.

설정 방법은 간단합니다. [EC]-[Elastic Block Store]에서 “수명주기 관리자”를 찾을 수 있습니다.

“수명 주기 정책 생성” 시 아래와 같이 화면이 나타납니다.

여기서 원하는 정책 유형을 선택해주면 되는데 오늘은 EBS 스냅샷 정책으로 진행하였습니다.

대상 리소스 유형은 볼륨과 인스턴스 유형으로 나뉘어 선택할 수 있습니다.
“볼륨”은 개별 볼륨의 스냅샷을 생성하고 “인스턴스”는 인스턴스에 연결된 모든 볼륨을 스냅샷 생성을 진행합니다.

스냅샷 정책에서는 볼륨, 스냅샷을 선택할 수 있으나 AMI의 경우 당연히 인스턴스만 대상으로 지정할 수 있습니다.
우선 저는 인스턴스 단위 선택하였습니다.

간단하게 정책에 대한 설명을 기입해주고 IAM 역할을 선택하는 곳입니다.
기본적으로 기본 역할을 선택할 경우 모든 필수 권한으로 자동 생성이 되나 IAM을 직접 생성하여 특정 사용자에 대해서 권한을 줄 수 있으며 이후 스냅샷 볼륨이 암호화되는 경우 KMS 키를 사용할 권한을 주어야합니다.

위 첨부된 사진에서는 크게 참고할 것이 없습니다.
정책 상태는 생성하는 이 정책을 활성화 할 것인가, 비활성화 할 것인가 선택하는 것이며
파라미터 부분에서 [루트 볼륨 제외]를 선택할 경우 루트 볼륨은 제외하고 스냅샷이 생성됩니다.

이제 가장 중요한 생성 주기를 지정하는 “일정 세부 정보”란입니다.

빈도는 일별, 주별, 월별, 연별로도 가능하며 cron을 이용하여 사용자 지정 표현이 가능합니다.
보존 유형은 개수와 경과 시간으로 설정할 수도 있습니다.

참고로 이런 질문이 있었습니다.
“저는 30분마다 스냅샷을 생성하고 싶은데 불가능한 가요?”

일별로 매 (1,2,3,4,6,8,12,24) 시간마다 설정이 있는데 이는 다 이유가 있습니다…
cron 표현식을 이용하여 30분마다 스냅샷을 생성하도록 설정해두면 아래와 같이 에러가 발생합니다.

“허용되는 최소 예약 빈도는 1시간입니다.” 라고 알려줍니다.
수명 주기 관리자는 1시간 단위로만 가능합니다.

또한 수명 주기 관리자를 써보시면 알겠지만 이게 UTC 09:00에 시작하라고 설정을 해둬도
09:00 시간에 딱 맞춰서 실행되지 않습니다.

UTC 09:00 ~ 09:59 사이에 랜덤으로 실행됩니다.

설정 이후 태그를 지정해줍니다.

정책 생성 마지막에 빠른 스냅샷 복원, 교차 리전 복사, 교차 계정 공유도 선택할 수 있습니다.
오늘은 교차 리전 복사까지만 한 번 해보도록 하겠습니다.

DR(Disaster Recovery)을 위해 이 교차 리전 복사를 이용하여 백업을 하시는 분들이 있습니다.
이 역시 방법이 크게 어렵지 않습니다.

대상 리전을 선택해주고 생성 후 언제 만료되게 할 것인가에 대해 설정해주면 끝!

다만 스냅샷 복사본 암호화 활성화를 하게 될 경우 이제 암호화 키에 대한 권한을 고려해봐야할 것입니다.


Personal Comments

지금까지 수명 주기 관리자 사용법에 대해서 간단하게 알아보았습니다.

위에서 언급했듯 수명 주기 관리자는 1시간 단위로만 가능한데 이를 30분 단위로하는 방법은 전혀 없는 것일까요?

그렇지는 않습니다. Lambda를 이용한다면 충분히 가능합니다.
Lambda를 이용하는 방법이 아닌 또 다른 방법이 있으시다면 공유 부탁드립니다.

긴 글 읽어주셔서 감사합니다.

AWS

[AWS] RDS Log Generation (General, slow query, audit logs)

안녕하세요. ManVSCloud 김수현입니다.

오늘은 오랜만에 AWS에 대한 포스팅입니다.
최근 ISMS-P를 준비가 필요하여 RDS에서 로그를 남기는 방법에 대한 질문을 받은 적이 있어 이를 블로그로도 공유하고자 올립니다.


RDS Log

RDS 생성 또는 수정시 체크할 수 있는 로그 내보내기 옵션입니다.
생각보다 이 기능이 로그를 생성하는 옵션인 것으로 아시는 분들이 있었습니다.
위 내보내기를 전부 체크하여도 에러 로그만 생성되고 나머지 로그가 생성이 되지 않는 것을 확인할 수 있습니다. (에러 로그는 Default가 생성이라 따로 설정하지 않아도 생성됩니다.)

이 기능은 말 그대로 로그를 CloudWatch Logs로 게시할 수 있도록 내보내는 옵션이며
로그를 생성하는 옵션은 따로 존재합니다.

일반 로그와 느린 쿼리 로그를 생성하기 위해서는 아래 첨부된 이미지와 같이 파라미터 그룹 수정이 필요합니다.

일반 로그는 general_log를 검색하면 나오고 슬로우 쿼리는 slow_query_log라고 검색하면 나옵니다.

두 값을 1로 변경 해줍시다. (1로 설정해야 로그가 생성됩니다.)

현재 운영중인 RDS 인스턴스의 파라미터 그룹이 default 파라미터로 설정되어 있다면 사용자 지정 파라미터 그룹을 생성하여 파라미터 수정 및 파라미터 그룹 수정을 진행합니다.
(RDS 인스턴스 [수정]을 이용하여 파라미터 그룹을 변경할 수 있습니다.)

여기서 중요한 점은 또 Down Time의 여부겠죠.
파라미터 그룹을 변경하게 될 경우 또는 파라미터 값을 수정하게 될 경우 재부팅이 필요하여 Down Time이 발생하게 될까요?

정답은 아래와 같습니다.

그렇다면 동적 파라미터와 정적 파라미터를 어떻게 구분하느냐?

파라미터 그룹 내에 파라미터들을 보면 [적용 유형]이 있습니다.
Dynamic이 동적 파라미터, Static이 정적 파라미터로 수정이 필요한 파라미터를 검색하여
해당하는 파라미터의 값이 수정될 경우 재부팅이 필요한가?를 알 수 있으니 이를 확인하여 적절한 시간에 작업을 진행할 수 있습니다.


RDS Audit Log

파라미터 그룹까지 설정하였습니다. 하지만 파라미터 그룹에서 감사 로그는 찾을 수 없습니다. 그 이유로 감사 로그는 파라미터 그룹이 아닌 옵션 그룹에서 설정이 필요하기 때문입니다.

옵션 그룹에서 감사 로그를 설정 해주려면 default 옵션 그룹에서 새로 생성한 옵션 그룹으로 변경이 필요합니다.

새로 생성한 옵션 그룹에서 위와 같이 MARIADB_AUDIT_PLUGIN 옵션을 추가하여 설정할 수 있습니다. 크게 사용하실만한 옵션에 대해서만 간단하게 설명하자면 다음과 같습니다.

  • SERVER_AUDIT_FILE_ROTATE_SIZE : 로그 파일 용량 크기를 제한합니다. (1–1000000000)
    최대 1GB까지 설정 가능하며 Default 값은 1000000 입니다.
  • SERVER_AUDIT_FILE_ROTATIONS : 로그 파일의 로테이션 수를 설정합니다. (0-100)
    최대 100개의 파일까지 생성가능하며 Default값은 9입니다.
  • SERVER_AUDIT_EVENTS : 특정 이벤트 유형으로 제한하여 로그를 남깁니다.
    이를 설정하지 않을 경우 모든 이벤트 유형을 남기게 됩니다.
    Default 값은 CONNECT, QUERY 입니다.
  • SERVER_AUDIT_INCL_USERS : SERVER_AUDIT_EXCL_USERS보다 우선 순위가 높으며 기록할 사용자를 추가합니다. 또한 값이 없을 경우 로깅에 모든 사용자를 로깅합니다.(SERVER_AUDIT_INCL_USERS 값에 admin을 추가하고 SERVER_AUDIT_EXCL_USERS 값이 비어있다면 admin 계정에 대한 로그만 남깁니다.)
  • SERVER_AUDIT_EXCL_USERS : 값에 사용자를 추가할 경우 해당 사용자를 로그에 기록이 남지않습니다. (로그 예외 처리 계정 추가라고 보면 이해가 쉽습니다.)
    값이 없을 경우 로깅에 예외 처리할 사용자가 없다라는 의미가 됩니다.
  • SERVER_AUDIT_QUERY_LOG_LIMIT : 쿼리 문자열 길이를 제한합니다. (0–2147483647)
    Default값은 1024입니다.

옵션 변경 및 옵션 그룹 변경이 완료되었다면 RDS 로그에서 아래 이미지와 같이 Audit.log가 생성되는 것을 확인할 수 있습니다.

Cloudwatch logs로 내보내기 설정을 하게될 경우 CloudWatch 로그 이벤트에서도 로그를 자세히 확인할 수 있습니다.
DB에서 show databases 및 show tables를 입력해보았는데 Audit 로그에 그대로 남았습니다.


Aurora DB, Using advanced auditing

Aurora MySQL에서는 RDS MySQL과 다르게 고급 감사를 사용할 수 있습니다.
설정 방법은 크게 어렵지 않아 어떠한 고급 감사 기능이 있는지 링크만 남겨두도록 하겠습니다.


Personal Comments

오늘은 오랜만에 AWS의 RDS 로그 생성 방법에 대해 알아보았습니다.

아무래도 감사 로그를 남기는 부분은 ISMS-P를 준비하실 때 필요한 부분이니 이 부분은 어느정도 도움이 되시리라 생각합니다.

긴 글 읽어주셔서 감사합니다.

AWS

Cloudwatch 경보 생성 + SNS 알림

안녕하세요. ManVSCloud 입니다.

Cloudwatch는 기본적이지만 매우 중요한 모니터링 서비스 입니다.
각 AWS 서비스의 리소스에 대한 로그를 지표화 하여 모니터링 할 수 있습니다.

예시로 Application Load Balancer의 헬스체크가 되지않을 때 알림을 받을 수 있도록
경보를 생성할 것인데 정말 “아… 이게 다 였어?” 싶을 정도로 매우 간단합니다.

-. 경보 생성

-. [ApplicationELB] -> [AppELB별, AZ별, TG별 지표] -> 지표 이름 : UnHealthyHostCount

-. 1보다 크거나 같으면 알림이 경보가 발생

-. 알림을 수신할 이메일 엔드포인트는 알림을 받을 메일을 쓰면 됩니다.
이후 등록한 메일로 들어가 인증을 해주어야합니다.

-. 경보 이름을 정해주고 생성을 해줍시다.

-. 정상적으로 경보가 등록된 것을 확인할 수 있습니다.

CloudWatch 경보를 이용한 SNS 알림 설정은 어렵지않습니다.
이런 저런 경보를 다양하게 등록해보시기 바랍니다.

간단한 글이었지만 AWS를 처음 시작하시는 분들에게 많은 도움이 되길바라며,
읽어주셔서 감사합니다.

AWS

Application Load Balancer(ALB) Admin 페이지 접근 제한

안녕하세요? ManVSCloud 김수현입니다.

오늘은 wordpress 블로그의 admin 페이지를 ALB에서 제한하였습니다.

admin 페이지를 제외한 https://manvscloud.com 의 나머지 경로는
모두 이용할 수 있도록 해야합니다.

admin 페이지로 이동하려면 도메인 뒤에 /wp-admin이 있어야합니다.

설정해둔 ALB에서 경로가 /wp-admin 으로 접근하게되면
모두 Blackhole로 가도록 하였습니다.

하지만 /admin을 한 결과는 생각했던 것과 조금 달랐습니다.

manvscloud.com/admin은막혀서 503으로 빠졌지만
manvscloud.com/admin/index.php 는 막히지않고 admin 페이지로 접속이 되는 것이었습니다?!

그래서 저는 ALB 규칙을 다음과 같이 주었습니다.

/wp-admin 과 /wp-admin/*을 주어 /wp-admin 디렉토리 하단의 모든 파일을
Blackhole로 가도록 하였습니다.

여기까지 설정을 하게되면 이제 모든 admin 페이지 접속은 막히게 됩니다.

하지만 관리자인 저는 접속이 가능해야합니다.
그래서 아래와 같은 추가 규칙을 추가해주었습니다.

2가지 조건을 줍니다.
소스 IP는 제가 접속하는 IP 이며, 경로는 admin 페이지로 가는 경로입니다.

해석하면 “만약 소스 IP 111.111.49.147/32가 /wp-admin 또는 /wp-admin/* 경로로 접근하면
ManVSCloud-TargetGroup으로 전달하라” 가 됩니다.

이 규칙은 admin 경로 Blackhole 전달 규칙보다 상단에 있어야합니다.

이제 admin 페이지는 제 IP에서만 접속이 가능하며 다른 곳에서
admin 페이지를 접근 하는 것은 불가능합니다.

읽어주셔서 감사합니다.

Certificate

2020 Certification

※ 2020 Certification

◈ AWS Solutions Architect – Associate (SAA)

Issue Date : 2020-02-20


◈ NAVER Cloud Platform Certified Associate (NCA)
Issue Date : 2020-07-01


◈ Microsoft Azure Solutions Architect – Expert
Issue Date : 2020-07-11


▶ AZ-300 Microsoft Azure Architect Technologies 
(Issue Date : 2020-05-19)


▶ AZ-301 Microsoft Azure Architect Design 
(Issue Date : 2020-07-11)


◈ AWS Cloud Practitioner (CLF)
Issue Date : 2020-07-26


◈ AWS Database – Specialty (DBS)
Issue Date : 2020-08-23

◈ AWS Data Analytics – Specialty (DAS) 
2020 예정

◈ Certified Kubernetes Administrator (CKA)
2020 예정

◈ AWS Solutions Architect – Professional (SAP) 
2020 예정

AWS

AWS Database – Specialty(DBS-C01) 합격 후기

안녕하세요? ManVSCloud (김수현)입니다.

2020-08-23 15:00 DBS-C01 시험을 보고 왔습니다.
AWS DBS-C01 첫 번째 후기가 되어 영광입니다.

시험 준비는 7월 28일부터 시작했습니다.
첫 주는 FAQ 정독을 하는 시간을 가졌는데 제가 FAQ 정독 시간을 가진 것은
이번 시험에 아주 큰 도움이 되었습니다.

FAQ는 DBS 시험에 필요한 기본적인 부분을 다 채워줍니다. 
물론 FAQ가 시험의 전부는 아니지만, FAQ를 한 번 정도 읽고 시험을 본다면 
시험의 난이도가 상당히 내려갈 것입니다.

▶ AWS DataBase
https://aws.amazon.com/ko/products/databases/

AWS Database – Specialty(DBS-C01)에서 가장 중요한 포인트였다고 생각되는
DMS FAQ도 링크로 아래에 남깁니다.
다른 건 몰라도 DMS는 꼭 짚고 넘어가시길 바랍니다.

▶ AWS DMS FAQ
https://aws.amazon.com/ko/dms/faqs/

DBS는 AWS의 데이터베이스 스페셜 자격증인데 뭐랄까… 
데이터베이스 아키텍처 자격증이라고 하는 것이 조금 더 알맞을 것 같습니다. 
Solutions Architect Associate(SAA)를 이미 경험하였다면 시험을 도전하시는 데
조금 더 쉽게 다가갈 수 있을 것입니다.


도메인별 시험 비중은 다음과 같습니다.

**도메인 1: 워크로드별 데이터베이스 설계**
1.1 특정 유형의 데이터 및 워크로드에 알맞은 데이터베이스 서비스 선택
1.2 재해 복구 및 고가용성을 위한 전략 결정
1.3 성능, 규정 준수 및 확장성을 목표로 데이터베이스 솔루션 설계
1.4 데이터베이스 솔루션의 비용 비교

**도메인 2: 배포 및 마이그레이션**
2.1 데이터베이스 솔루션 배포 자동화
2.2 데이터 준비 및 마이그레이션 전략 결정
2.3 데이터 마이그레이션 실행 및 검증

**도메인 3: 관리 및 운영**
3.1 유지 관리 작업 및 프로세스 결정
3.2 백업 및 복원 전략 결정
3.3 데이터베이스 솔루션의 운영 환경 관리

**도메인 4: 모니터링 및 문제 해결**
4.1 모니터링 및 경고 전략 결정
4.2 일반적인 데이터베이스 문제 해결
4.3 데이터베이스 성능 최적화

**도메인 5: 데이터베이스 보안**
5.1 보관 및 전송 중 데이터 암호화
5.2 감사 솔루션 평가
5.3 액세스 제어 및 인증 메커니즘 결정
5.4 데이터베이스 솔루션의 잠재적인 보안 취약성 인식


위 도메인에 해당되는 [사례 연구]들을 참고하면 작은 도움이 될 수 있습니다.

[사례 연구]는 시나리오별 트러블 슈팅 및 아키텍처에 잘 다루고 있기때문에 
전부 다 보는 것까지는 아니라도 심심할 때 봐두면 생각보다 도움이 될 것입니다.

샘플 문제와 연습 시험 후 1. 문제 패턴 파악, 2. DBS가 요구하는 것 파악, 3. 오답 노트 
시험을 준비할 때 큰 도움이 됩니다.

FAQ를 정독하여도 시험 문제에 대한 패턴과 요구하는 것을 알지 못하면 당황할 수 있습니다.

샘플 문제와 연습 시험을 본 뒤 “아 대충 기능별로 이런 것들을 묻겠구나” 정도는
알고 가시는 것이 좋습니다. 


저같은 경우 이번 시험 준비를 하면서 시험 준비 기간이 너무 길었다라고 느껴졌습니다.
솔찍히 시험 날짜를 조금 더 앞당겨 보고싶었습니다.
약 3~4주씩이나 준비할만큼 난이도가 높은 시험은 아니었습니다.

결론 : AWS Database – Specialty(DBS-C01) 시험은 아키텍처에 대한 기본적인 개념 + FAQ 1회 
정독이면 DBS 시험은 큰 문제없이 합격할 수 있을 것으로 생각됩니다.
(샘플 문제 + 연습 시험 후 1. 문제 패턴 파악, 2. DBS가 요구하는 것 파악, 3. 오답 노트는 필수)


이상 지금까지 AWS Database – Specialty(DBS-C01) 최초 시험 후기였습니다.

감사합니다.

마지막으로 저 스스로 시험을 볼 수 있도록 능력을 끌어올려주신 리눅서님께 감사의 인사올립니다.

linuxer.name