정리 블로그

1. Redis 삭제 준비

 -. 불필요한 리소스를 삭제하다보면 Redis를 삭제하는 경우가 생긴다.

Redis의 경우, 일반 AWS 리소스와는 달리 'Stop'이 없다. 오직 'Delete'만 가능할뿐..

리소스 삭제 전 실제 사용되고 있지 않은 리소스인지 검증이 필요하다.

아래와 같은 프로세스로 삭제를 진행하였다.

-. 보안그룹 차단하여, 고립시킨 후 서비스 이상여부를 체크. 최종적으로 Redis에 접근하여 모니터링해본다.

며칠 간 특이사항이 없다면 삭제 수행

2. 삭제를 위한 작업

-. 우선 삭제 진행에 앞서, 내가 사용하고 있는 Redis는 이미 EOS가 지난 Redis였다. (강제 버전 업그레이드 연기..)

따라서, AWS 콘솔을 통한 작업이 불가하였음

(In/Out bound가 아무것도 포함되지 않은 보안그룹으로 변경 시, 위와 같은 에러 발생)

2-1. 특정 서버에 aws cli를 설치

2-2. cli 명령어를 통한 보안그룹 변경(access key 사용)

aws elasticache modify-replication-group --replication-group-id dev-cache --security-group-ids sg-0911cf6ffe

2-3. redis-cli 설치

yum install -y gcc

wget http://download.redis.io/redis-stable.tar.gz && tar xvzf redis-stable.tar.gz && cd redis-stable && make

cp src/redis-cli /usr/bin/

2-4. 모니터링 수행

redis-cli -h [endpoint] -p [port]

3.  참고 사항

-. redis-cli를 수행하는 서버에서 redis 클러스터로 통신이 가능하게 보안그룹이 설정되어있어야 한다.

1. 작업 순서

-. Cluster Version Update → NodeGroup Version Update(노드그룹 업데이트 진행 시, 노드 버전 순차적 업데이트 수행됨)

2. 목적

-. EKS 버전 EOS에 따른 버전 업그레이드(EOS 버전 1.22)

3. 참고 사항

-. 1.22 → 1.25 로 한번에 버전 업데이트는 불가하며, 1.22→ 1.23→ 1.24→ 1.25 순으로 순차 업데이트 진행 필요

-. Cluster&Node Group 버전이 한 단계 업데이트될 때마다 Event, Pod 상태 등 확인 필요

-. Add-on으로 Driver 설치 버전 확인이 필요하고, add-on으로 설치한 게 아니라, helm 등 다른 방식으로 설치한 경우, AWS 콘솔에서 확인이 불가능하며, 삭제 후 add-on으로 설치 혹은 직접 driver 버전 업데이트 등의 프로세스로 작업이 필요함

4. 작업 내용

1. 목적

 -.  A계정의 EC2에서 B계정의 내부 DNS 쿼리가 필요했고, Public DNS로 노출시키고 싶지 않았음(보안 등의 이슈를 위해)

2. 필요한 정보

 a. A 계정 Route53의 Hosted Zone ID
 b. A 계정 IAM 사용자 및 Access Key(일회성)
 c. B 계정 VPC 사용 리전, ID
 d. B 계정 IAM 사용자 및 Access Key(일회성)

3. 진행 방법

-. A 계정에서 Admin 권한(편의상)의 IAM 사용자로 Access key를 발급하고,
Local에서 CLI 환경 준비

-. A 계정의 Route53을 B계정의 리소스가 쿼리할 수 있도록 허용

aws route53 create-vpc-association-authorization --hosted-zone-id <A 계정 Route53의
Hosted zone> --vpc VPCRegion=<B 계정의 VPC 리전>,VPCId=<B 계정의 VPC ID> --profile sun
gtaek.yoo-security

-. B 계정의 IAM Access key로 A 계정 Route53 연결

aws route53 associate-vpc-with-hosted-zone --hosted-zone-id 
<A 계정 Route53의 Hosted zone> --vpc VPCRegion=<B 계정의 VPC 리전>,
VPCId=<B 계정의 VPC ID> --region ap-northeast-2 --profile sungtaek.yoo

4. 완료 확인

 -. 설정대로 진행이 완료되었으면, 설정한 VPC 환경내 인스턴스에서 nslookup 시, 확인 가능

B 계정 서버에서 A 계정 Route53에 등록된 Private 영역 쿼리 가능!!

혹은,

-. A 계정의 Route53 콘솔에서도 확인가능

이렇게까지 사용할 이유는 대부분의 경우, 없으시겠지만 혹시나 필요하신 분이 있을 수 있어 내용을 공유합니다.

1. 목적

인스턴스에서 발생하는 로그(ex. /var/log/message)를 보기좋게 백업하고 확인할 수 있는 방법 중 하나는 LogGroup으로 로그를 전달하는 방법이다.

2. 권한 주기

권한을 주는 방법은 생각나는 건, 두 가지이다.

첫째, EC2에 Role을 추가하기. 내가 진행하려는 것은 인스턴스에서 LogGroup으로 로그를 전송하는 것이기 때문에 인스턴스에서 진행하는 것으로 설명 진행.

둘째, 액세스키 생성 후 인스턴스에서 configure 설정하여, LogGroup으로 로그를 전송하는 방법.

3. awslogs 설치

설치는 yum을 통해 진행하면 되므로 간단하다.

yum install -y awslogs

3. conf 파일 설정 변경해주기

첫째. 

/etc/awslogs/awscli.conf

파일의 설정을 변경해준다.

변경은 region 을 변경해주면 끝. 리전은 내가 사용하는 리전으로 변경해주면 됨.

둘째.

/etc/awslogs/awslog.conf

이 설정에서는 약간의 커스터마이징(?)이라 해야하나. 어쨋거나 할 수 있다.

이번 테스트에서는 time_zone을 LOCAL로 추가했고, 인스턴스내 어떤 파일을 보낼 것인지를 설정하는 부분.

아래에서는 'file'을 보면 /var/log/messages 파일을 보내게 되어있다.

log_group_name은 로그그룹에 미리 생성해준 LogGroup 이름을 입력해주면 된다.

log_stream_name은 로그그룹에 어떤 이름으로 파일을 남기는지에 대한 부분이고, 인스턴스id와 인스턴스의ip를 표시하게 하였다.

** 빠뜨리면 안되는 것이, awslogs 서비스를 실행시켜야한다.

service awslogs start

4. 결과물

설정을 완료하고, 서비스도 정상적으로 실행시키면 위와 같은 형식으로 로그 확인이 가능하다.

1. 목적

인스턴스에 EBS 볼륨이 많이 연결 되어있는 경우, 볼륨크기 조정과 같이 특정 디스크를 수정하고자 하는 EBS가 무엇인지 알아보기 힘들다. 볼륨의 크기(GB)가 다른 경우에는 EBS 볼륨 크기로 찾아볼 수 있으나, 동일한 볼륨크기가 여러개인 경우에는 더 알아보기 힘들다.

2. 찾을 수 없는 볼륨(EBS ID)

'df -hT' 명령어를 입력해도 알 수 없음.

'lsblk' 명령어를 통해서도 알 수 없음

fstab에서도 알 수 없음

'fdisk -l' 명령어로도 확인 불가

3. 어떻게 확인할 수 있나?

우선 어떤 디스크를 확인할 것인지 알아볼 것.

위 캡처를 기준으로 nvme1n1 볼륨이 어떤 EBS인지 확인해보고자 한다면,

아래 명령어를 입력한다.

sudo /sbin/ebsnvme-id /dev/nvme1n1

자, 이렇게 'vol'로 시작 하는 볼륨의 ID가 나온다.

그럼, 콘솔에서 어떤 볼륨인지를 확인하면 된다.

1. Route53의 가중치 기반 라우팅 적용

 -. 가중치 기반 라우팅(Weighted Routing Policy) 적용은 각 서버를 물리적으로 다른 호스트에서 운영할 경우에 적용할 수 있습니다. 예를들어 'IDC를 사용하고 있는 상황에서 클라우드에 서버를 신규로 생성하였고, 완전 클라우드로 이전하기에는 리스크가 있다고 판단하는 경우'(?)도 있을 수 있을거고..혹은 '클라우드에만 서버를 올려서 사용하기 불안하여, IDC와 혼합하여 사용하겠다' 등의 상황이 있겠지만..

해당 라우팅 정책은 각자 목적에 맞게 사용하시면 되겠습니다..

2. Weighted Routing Policy 적용하기

 -. 해당 정책을 적용하기 위해서는 레코드 타입이 모두 A 타입으로 생성이 필요합니다.(CNAME과 섞어서 사용해보려하였으나, 레코드를 생성하는 부분에서 에러가 발생하여 생성되지 않음 확인)

레코드 설정은 아래와 같이 진행해주면 됩니다.

->Routing Policy는 Weighted 로 설정.

->Record ID는 고유한 이름으로 설정하도록 하며, 이름 태그로 생각하면 됩니다.(설정하지 않으면 생성이 안됨)

Weight는 두 개의 레코드 비율을 다르게 줄 수 있습니다. 화면에 보이는지 모르겠으나, 0-255까지 숫자를 입력할 수 있으며, 1번 레코드에 10, 2번 레코드에 20을 넣으면 1:2 비중으로 인입됩니다.(0을 넣으면 해당 서버로는 인입이 없음)

3. 테스트 결과

 -. curl을 이용하여 총 10번의 테스트를 진행해보았을 때, 신기하게 5번 5번의 횟수로 각 서버에 연결되었습니다. 저의 경우, Weight를 각 10으로 설정해주었고, 직접 테스트해보시면 4번 6번의 결과정도가 출력될 수도 있습니다.

4. Simple Rounting Policy로 A레코드를 2개해볼까?

 -. Simple Routing으로 입력되는지 테스트를 해보고자 하였으나...아쉽게도 해당 라우팅 정책으로는 1개 이상이 추가되지 않았습니다.

위와 같이 라우팅 정책이 'Weighted'로 설정되지 않고, 'Simple' 정책으로는 동일한 레코드네임이 입력되지 않습니다.

Simple Policy로 동일한 레코드네임 두 개를 입력했을 때, 발생.

1. Invalidation 수행 목적

-. 해당 작업을 수행하는 목적은 캐싱 시간이 길게 설정되어있는 경우, 원본(Origin)에서 데이터를 변경하게 되더라도 CF 는 변경 전 값을 계속 캐싱하게 됩니다. TTL 시간동안 Origin 값을 가져오지 않아 변경된 데이터가 출력되지 않습니다.
따라서, 수동으로 CF에 원본 값을 재배포하고자 하는 경우 사용하게 됩니다.

2. Invalidation 수행 방법

1) AWS 콘솔에서 CloudFront 서비스로 이동 후 사용중인 Distributions 선택

2) 특정 Distribution 선택 후 Invalidation 선택

3) Create Invalidation 선택하여, Object path 입력

특정 경로에 대한 Invalidation이 적용되며, 'Create invalidation'을 누르는 즉시 적용됩니다. 해당 작업이 완료되기 전까지는 기존 값을 캐싱합니다.

1. AWS QuickSight란?

-. Quick Sight를 사용하는 이유는 BI(Business Intelligence) 대시보드를 활용하기 위함

-. 많은 데이터를 활용하고자 함(시각화 가능)

-. 장점

: 코드나 SQL로 분석하는 것 보다, 시각화로 빠른 인사이트에 도달

: 분석에 대한 자동 확장 및 서버리스

: AWS 서비스와 연결 사용 가능

: API 지원

• Kibana와 결합하여, 대시보드를 추가 이용 가능(WAF BLOCK율 등)
• 서버리스이며, Cloud Native.
• 다양한 데이터로부터 시각화 가능
• 데이터는 SPICE라는 인메모리 엔진에 올려서 분석
• N.Virginia에서는 Forcast 기능이 지원됨(다른 리전은 사용가능한지 확인해보지 않았으나, 서울 리전은 해당 기능이 없는 것으로 확인)

: 나의 AWS VPC와 연결이 가능(피어링 형식으로 진행되는 것 같으나, 정확하진 않음)하여, 내 AWS 리소스를 연결할 수 있음!!

생성 시, 보안그룹 ID도 필요함!

실제 해당 데이터는 2021년 12월까지만 있던 데이터지만, 'Forecast' 기능을 활용하면 해당 그래프와 같이 예측 데이터가 출력됩니다.

2. QuickSight Account

AWS 콘솔에 로그인해서 QuickSight를 사용하더라도, QuickSight용 Account를 만들어야한다.

Enterprise 요금은 위와 같으며, Standard도 별도로 있음.

Standard 계정을 생성 후 추후 Enterprise 요금으로 변경은 가능하지만, Enterprise에서 Standard로 변경은 불가능하기 때문에, 신중히 고려해보고 올릴 것.

3. 다양한 Dataset Import 가능

Dataset은 위와 같이 다양한 데이터를 활용하여 사용 가능합니다.

저는 csv 파일을 활용하였으며, 'Upload a file'을 통해 dataset을 Import 시켰습니다.

4. Import한 데이터 값을 가시적으로 확인 가능

위 그래프 생성 후 좌측 패널에 Insights를 선택하면, 수치로 바로 확인 가능한 리스트들 확인 가능.

해당 수치 중 필요한 수치를 추가하여, 대시보드로 만들 수 있음.

또한 'Fields list'(Import한 데이터 필드값)을 조합하여, 아래와 같이 테이블을 만들 수도 있음.

5. 대시보드 활용하기

위와 같이 차트그래프, 도넛 그래프, 특정 데이터값, 테이블 생성 등 필요한 자료들을 대시보드화하여, 해당 대시보드를 타인에게 공유 가능.

위와 같이 Manage User에 추가하여, 사용 가능함.

6. Report로 활용하기

QuickSight 대시보드를 다 만들었다면 Report 기능을 활용할 수 있음.

위와 같이 스케줄을 사용할 수 있으며, 메일 내용으로 대시보드 화면이 입력됨.(대시보드가 너무 크게 나와, 보기 불편)

Include PDF attachment를 활성화하여, 메일 첨부파일에 PDF 파일을 넣을 수 있고, 대시보드 크기와 동일하므로 보기 메일내용에 포함된 화면보다 보기 가독성이 좋음!

해당 대시보드를 확인할 수 없는 인원도 위와 같이 수신자 리스트에 추가하여 테스트가 가능합니다.

*** 비교할만한 유사한 서비스(AWS 서비스는 아님) : 태블로(Tableau)