blog

[AWS] RI / SP 정리

tpcable — Wed, 27 Mar 2024 14:21:40 +0900

RI(Reserved Instance)
- RI는 1년 혹는 3년동안 특정 가용영역에 자원을 예약하여 사용하는 것
- EC2와 RDS 모두 적용 가능

SP(Saving PLan)
- RI는 지역, 크기, 인스턴스 패밀리를 정하게되면 변경이 불가능하기에 유연성이 떨어짐
- SP는 인스턴스 패밀리, 크기 등 좀 더 유연
- EC2 계약만 가능하고 RDS는 불가능

SP는 EC2 Instance Saving Plan과 Compute Saving Plan으로 나눠짐
EC2 Inatance Saving Plan
- 지정한 지역내에서만 인스턴스 변경 허용
- 같은 패밀리만 가능, 크기와 운영체제 변경 허용
- EC2 인스턴스에만 적용 가능

Computing Saving Plan
- 여러지역에 걸쳐 적용 가능
- EC2와 Fargate에 적용 가능
- 패밀리, 운영체제 변경에 제한 없음
- 지역 무관

RI 3가지 결제 방식
1) 전체 선결제(All Upfront) 비용을 모두 선결제, 가장 저렴
2) 부분 선결제(Partial Upfront) - 일부 선결제
3) 선결제 없음(No Upfront) - 온디맨드보다 저렴한 가격에 매월 시간당 사용료 지불

*정리

	RI	EC2 Saving Plan	Compute Saving Plan
인스턴스 패밀리	지정	고정	가변
인스턴스 크기	지정	변경가능	변경가능
OS	지정	변경가능	변경가능
지역	1 Region 지정	1 Region 지정	지역 무관
적용 가능 서비스	EC2 / RDS	EC2	EC2 / Fargate

[Azure] Flexible DB에 대해

tpcable — Mon, 26 Feb 2024 10:38:16 +0900

얼마 전 Azure Single DB가 EOL 된다고 하여 Azure Flexible DB로 변경 작업을 진행했다.

[환경]

VNET Injection이 아닌 공용 액세스로 Private Endpoint만 설정이 필요한 상황

[상황]

- WAS에서 DB 커넥션을 Flexible로 변경했는데, WAS에서 DB로 접근이 불가능하였고 IPv6에 대한 DB 접근 권한이 없음의 에러가 확인되었다.

- VM에서 IPv6를 비활성화 해도 동일한 현상이 발생했음.

- WAS 에서 DB Client 로 직접 접속해도 동일한 증상인 것을 확인하여 Azure Platform 통신 방식이 조금 달라서 이런 일이 발생한게 아닌가 싶어 문의를 했다.

답변 받은 내용

"Private endpoint를 통해 접근 시에 ipv6 주소가 확인되는 부분으로 이는 Azure Database for MySQL flexible server의 By Design"

" Vnet injection방식은 Private endpoint와 다른 Connection architecture로 본 Design의 영향을 받지 않아 ipv4로 확인됨을 안내드립니다."

[결론]

결론은 DB 접근 정책에 IPv6도 추가함으로써 해결 될 수 있었는데 by design으로 IPv6 로 통신을 시도한 것을 알게되었다.

비슷한 시나리오: Why is my Azure Web App showing an IPv6 Outbound IP address - Microsoft Q&A

Aurora DB AZ 설정에 따른 비용 관련 내용

tpcable — Tue, 19 Dec 2023 17:38:59 +0900

Aurora DB 생성 시 AZ 갯수에 따라 비용도 달라지는지 고민하다가 확인한 내용

=> AZ 개수에 따른 비용 청구는 동일

https://docs.aws.amazon.com/ko_kr/AmazonRDS/latest/AuroraUserGuide/User_DBInstanceBilling.html

Aurora에 대한 DB 인스턴스 결제 - Amazon Aurora

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

단 RDS Multi-AZ는 subnet group에 단순하게 AZ를 추가하는 것에 대한 청구 개념이 아닌 RDS 인스턴스를 만들거나 수정할 때 선택하는 옵션

Multi-AZ를 선택하면 HA 목적으로 subnet group에 있는 다른 AZ에 failover 용으로 standby 인스턴스를 하나 더 만들게 되는데 이렇게 되면 추가로 비용이 과금됨

- subnet group 에 3개의 AZ 사용, Aurora Cluster 에 1개의 Writer 만 사용

=> 한개의 인스턴스 비용 청구

- subnet group 에 2개의 AZ 사용, Aurora Cluster 에 1개의 Writer 와 1개의 reader 사용

=> 두개의 인스턴스 비용을 청구

DB와 동일하게 EKS 클러스터 AZ 서브넷 추가에 따른 비용증가는 발생하지 않는다고한다.

[AWS] RHEL 마스터 이미지 생성 관련...

tpcable — Tue, 12 Dec 2023 16:27:38 +0900

AWS 마켓 플레이스를 통해 RHEL 8.X 버전의 마스터 이미지를 생성하려고 하는데 원하는 설정이 계속 초기화 되는 문제가 있었다.

[문제점]
1. 암호로 로그인 가능하도록 sshd_config를 변경했으나 지속적으로 /etc/ssh/sshd_config 파일의
PasswordAuthentication no 로 설정 되어 로그인 불가

2. /etc/sudoers.d/90-cloud-init-users 파일을 수정했으나 변경되지 않음

대부분의 EC2 AMI는 OS에 cloud-init 서비스를 통해 인스턴스 시작 시 특정설정(네트워킹, 패키지 설치, 사용자 스크립트 실행)을 진행하는 것을 알게 되었다.
기본적으로 수행되는 설정은 /etc/cloud 하위 디렉토리에 위치하고 /etc/sudoers.d/90-cloud-init-users 파일 역시 cloud-init 설정 내용에 따라 인스턴스 최초 생성시 생성되는 파일인 것을 알게되었다.

# cat /etc/cloud/cloud.cfg
users:
- default

disable_root: 1 <----- (A)
ssh_pwauth: 0 <----- (B)

mount_default_fields: [~, ~, 'auto', 'defaults,nofail,x-systemd.requires=cloud-init.service', '0', '2']
resize_rootfs_tmp: /dev
ssh_deletekeys: 1
ssh_genkeytypes: ['rsa', 'ecdsa', 'ed25519']
syslog_fix_perms: ~
disable_vmware_customization: false
.
.
.
system_info:
default_user:
\tname: cloud-user
\tlock_passwd: true <----- (C)
\tgecos: Cloud User
\tgroups: [adm, systemd-journal]
\tsudo: [\"ALL=(ALL) NOPASSWD:ALL\"] <---- (D)
\tshell: /bin/bash
distro: rhel
paths:
\tcloud_dir: /var/lib/cloud
\ttemplates_dir: /etc/cloud/templates
ssh_svcname: sshd

- disable_root no로 되어 있으면 cloud-init 은 시작시 SSH 데몬 설정파일 에서 PermitRootLogin 설정을 no로 변경하게 되어 SSH를 통한 root 로그인을 막음, root 계정을 통한 로그인을 허용하려면 disable_root: 0으로 변경

- ssh_pwauth 설정 값이 0일 경우 SSH 데몬 설정중 PasswordAuthentication을 no로 변경하게되어 암호 인증을 불가능하게함 허용 할경우 ssh_pwauth: 1로 변경

- lock_passwd 설정은 기본사용자의 암호를 잠금 처리 할지 여부를 정의 RHEL8의 경우 기본사용자는 ec2-user
아래와 같은 설정 때문에 ec2-user 가 계속 생성됨
# cat /etc/cloud/cloud.cfg.d/00-rhel-default-user.cfg
system_info:
default_user:
name: ec2-user

참고자료

cloud-init - SSH - Authorized Keys - https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=disable_root#authorized-keys
cloud-init - Set Passwords - https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
cloud-init - Users and Groups - https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=disable_root#users-and-groups

[Docker] CMD / ENTRYPOINT 차이

tpcable — Tue, 17 Oct 2023 19:08:30 +0900

둘 다 컨테이너 시작시 실행할 명령어를 지정하는 명령어

[테스트]

1. ENRTYPOINT 컨테이너 빌드

# Dockerfile

FROM ubuntu:latest

ENTRYPOINT ["echo", "entrypoing_test"]

docker build -t entry .

docker run entry

entrypoing_test # 결과값

2. CMD 컨테이너 빌드

# Dockerfile

FROM ubuntu:latest

CMD ["echo", "cmd_test"]

docker build -t . cmd

docker run cmd

cmd_test # 결과값

3. 비교

ENTRYPOINT

ENTRYTEST 뒤에 추가로 입력한 echo entrytest2 가 붙어서 실행

CMD

기존값 cmd_test 대신 cmdtest2 출력

[정리]

CMD: 컨테이너 실행시 시작되는 명령어지만 변경 가능

ENTRYPOING: 항상 실행해야 하는 명령어를 사용할 때

[AWS] NLB 와 타겟 그룹 대상의 VPC가 다를 때 설정 방법

tpcable — Mon, 21 Nov 2022 10:30:44 +0900

1. 1단계에서 VPC는 NLB가 위치할 VPC 선택

2. 네트워크: 다른 프라이빗 IP 주소 선택, 가용 영역 모두 선택

이후 IP수동으로 입력

[AWS] Aurora MySQL 용량 확인

tpcable — Mon, 21 Nov 2022 10:23:29 +0900

기본적으로 데이터베이스 엔진이 설치된 Computing 노드와 데이터가 저장되는 Storage 노드로 나눠진 구조
Storage 노드의 경우 모든 노드(Writer, Reader) 가 공유하는 여러 영역에 걸쳐서 복제본을 가지는 클러스터 볼륨 구조

대규모 테이블 Drop이나 Truncate 등이 발생하면 Shrink 되어 사이즈가 Dynamic 하게 조정됨

Aurora MySQL은 관리형 RDB로 클러스터 볼륨은 데이터베이스의 데이터 용량이 늘어나면 자동으로 확장된다.
Aurora MySQL 호환 버전에 1.23.0 및 2.90.0, 3.01.0 이상에서는 최대 128TiB까지 확장 가능

Cloud Watch를 통한 볼륨 확인
- 클러스터 볼륨에 사용할 수 있는 나머지 공간이며 바이트 단위로 측정, 클러스터 데이터가 늘어나면 AuroraVolumeBytesLeftTotal 값이 감소
이 값은 클러스터가 용량 제한에 가까워지고 있는지 확인

1. CloudWatch 콘솔
2. 지표 - 모든지표 - RDS
3. DBClusterIdentifier 선택
4. AuroraVolumeBytesLeftTotal 검색

RDS 콘솔에서 VolumeByteUsed 확인

- VolumeByteUsed는 Aurora MySQL DB 클러스터에서 사용하는 용량, 클러스터 데이터가 증가하면 VolumeBytesUsed 값이 증가
1. RDS - 인스턴스 선택
2. 모니터링 선택
3. Volume Bytes Used로 확인

[AWS] RDS 내용 정리(Parameter Group, Cluster)

tpcable — Wed, 16 Nov 2022 10:09:05 +0900

1. RDS Default Parameter group 변경 방법
- default parameter group은 클러스터 혹은 DB인스턴스를 구성할 때 기본 설정으로 구성된 파라미터(기본값)
만약 파라미터 그룹 내 파라미터를 변경하려면 신규 파라미터 그룹을 생성하고 해당 파라미터 그룹에서 값을 변경 필요

[파리미터 그룹 변경 순서]
1) 새로운 사용자 지정 파라미터 그룹 생성
2) 새로운 사용자 지정 파라미터 그룹에서 변경하고자 하는 파라미터 변경
3) DB인스턴스 수정 선택 - 새로 생성한 파라미터 그룹 지정
4) 인스턴스 재기동

2. 클러스터 파라미터 그룹, DB파라미터 그룹 차이점
- 클러스터 파라미터: 클러스터내 모든 인스턴스에 적용되는 공통적인 파라미터 값을 정의
- DB파라미터: DB 인스턴스 별로 다르게 설정하고자 하는 파라미터가 있을 경우 설정

예를 들면 time_zone과 같은 파라미터의 경우 클러스터내 인스턴스들은 같은 값을 가져야 하므로 클러스터 인스턴스에만 존재
innodb_buffer_pool_size와 같은 파라미터는 클러스터 파라미터그룹과 DB 파라미터 그룹 둘 다 존재 이럴경우 DB 파라미터가 우선순위

3. RDS에 있는 클러스터의 의미
- 별도의 묶는 개념이 아님.
- Aurora 클러스터를 먼저 생성한 후 Writer 인스턴스를 처음 생성 가능하며, 그 이후 Reader 인스턴스를 추가할 수 있음.
- 라이터 인스턴스와 읽기 인스턴스의 묶음을 클러스터라고 표현

[K8S] 쿠버네티스 정리

tpcable — Mon, 17 Oct 2022 23:01:57 +0900

서비스: 외부에서 쿠버네티스 클러스터를 외부에 노출 시키기 위한 컴포넌트

1. NodePort

- 사용자가 워커 노드의 특정 포트로 요청

- 모든 요청을 노트포트 서비스로 전달

- 노드포트 서비스는 Pod에 전달

(Node Port를 통해 Node를 접속해 pod를 찾아감. pod에 직접 연결하는 것은 아님)

nodeport.yaml

apiVersion: v1

kind: Service

metadata:

name: k8s-svc

spec:

selector:

app: deploy-pod

ports:

- name: http

protocol: TCP

port: 80

targetPort: 80

nodePort: 30000

type: NodePort

yaml파일이 아닌 아래와 같이 expose 가능

kubectl expose deploy [object name] --type=NodePort --name=[name] --port=[port]

2. Ingress

- NodePort를 통해 노드포트 서비스로 접속(노드포트 서비스를 인그레스 컨트롤러로 구성)

- 인그레스 컨트롤러는 사용자의 접속 경로에 따라 적합한 클러스터 IP로 경로 제공

- 클러스터 IP 서비스는 Pod로 연결해줌

3. HPA

- 부하를 확인

: kubectl top pods

- HPA가 자원을 요청할 때 메트릭 서버를 통해 계측값을 전달 받음 메트릭 서버 필요

[AWS] EKS 생성

tpcable — Sat, 20 Aug 2022 16:43:39 +0900

IAM 생성

IAM에 관리자 권한을 할당해 관리 EC2에서 EKS관리

Policy 연결

Access key 저장

관리 EC2에 AWS 계정등록

aws configure

# 정상 로그인 확인
aws sts get-caller-identity

[EKS 구성]

eksctl create cluster \\
--name eks-test \\
--region ap-northeast-2 \\
--with-oidc \\
--ssh-access \\
--ssh-public-key awskey \\ # node 에 접속 할 key
--nodes 3 \\
--node-type t3.medium \\
--node-volume-size=20 \\ # node local disk size 20GB
--managed

kubectl get node

kubectl run webserver --image=nginx:1.14 --port=80
kubectl get pod -o wide

Private EC2가 아니기에 Public IP가 할당 되어 있음. 생성 시 이미지를 지정하지 않았기에 AWS Linux 가 설치 되어있음

모든 Pod 삭제

kubectl delete pod --all

Cluster 삭제

eksctl delete cluster --name [EKSCLUSTERNAME]

[관리 EC2에 설치]

EC2에 AWS CLI 설치

sudo apt-get install -y unzip
curl "<https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip>" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

2. EC2에 eks ctl 설치_EKS설치 / 운영 Tool

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/eksctl.html

eksctl 설치 또는 업데이트 - Amazon EKS

GitTag 버전은 0.105.0 이상이어야 합니다. 그렇지 않은 경우 터미널 출력에서 설치 또는 업그레이드 오류가 있는지 확인하거나, 1단계의 주소를 https://github.com/weaveworks/eksctl/releases/download/v0.105.0/eksct

docs.aws.amazon.com

curl --silent --location "<https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$>(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv /tmp/eksctl /usr/local/bin
eksctl version

3. EC2에 Kubectl 설치

curl -o kubectl <https://s3.us-west-2.amazonaws.com/amazon-eks/1.22.6/2022-03-09/bin/linux/amd64/kubectl>
chmod +x ./kubectl
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
kubectl version --short --client

kubectl 설치 또는 업데이트 - Amazon EKS

Amazon EKS 클러스터 제어 영역과 마이너 버전이 하나 다른 kubectl 버전을 사용해야 합니다. 예를 들어 1.21 kubectl 클라이언트는 Kubernetes 1.20, 1.21, 1.22 클러스터와 함께 작동합니다.

docs.aws.amazon.com

[EKS 관리서버 환경 설정]

1. IAM 생성

- IAM에 관리자 권한을 할당해 관리 EC2에서 EKS관리

2. Policy 연결

3. Access key 저장

4. 관리 EC2에 AWS 계정등록

[EKS 구성]

eksctl create cluster \\
--name eks-test \\
--region ap-northeast-2 \\
--with-oidc \\
--ssh-access \\
--ssh-public-key awskey \\ # node 에 접속 할 key
--nodes 3 \\
--node-type t3.medium \\
--node-volume-size=20 \\ # node local disk size 20GB
--managed