Kubernetes 관리 툴 K9s

Kubernetes 클러스터를 효과적으로 관리하는 일은 매우 복잡할 수 있습니다. 그러나 K9s라는 터미널 기반 UI 툴을 사용하면 이러한 복잡성을 크게 줄일 수 있습니다. 이번 블로그 포스트에서는 K9s의 주요 기능과 설치 방법, 사용법에 대해 자세히 알아보겠습니다.

K9s

K9s는 Kubernetes 클러스터와 상호 작용하기 위해 설계된 CLI(명령줄 인터페이스) 도구입니다. 실시간으로 클러스터의 리소스를 관리, 모니터링, 문제 해결할 수 있도록 직관적인 인터페이스를 제공합니다.

주요 기능

• 클러스터 리소스의 실시간 모니터링
• Pod, 서비스, 배포 등을 보기 위한 인터랙티브 UI
• 사용자 정의 레이아웃 및 뷰 지원
• 빠른 탐색과 작업을 위한 단축키
• 고급 필터링 및 검색 기능

 이 기능들을 몇개의 단축키로 쉽게 사용할 수 있습니다.

K9s 설치 방법

먼저 k9s를 설치하기 전에 kubectl이 설치되어있어야 합니다.

kubectl 설치방법은 kubectl - 쿠버네티스 클러스터를 관리해보자! 문서를 참조해주세요

Linux:

curl명령어를 사용해 바이너리 파일 다운로드 합니다.

curl -sS https://github.com/derailed/k9s/releases/latest/download/k9s_Linux_x86_64.tar.gz | tar -xz
sudo mv k9s /usr/local/bin/

macOS:

brew 명령어를 사용해 설치합니다.

brew install k9s

Windows:

방법 1 : Windows용 바이너리를 K9s GitHub releases 페이지에서 다운로드하고 PATH에 추가합니다.

방법 2 : chocolatey를 사용해 설치합니다. 

choco install k9s

K9s 시작하기

설치 후 K9s를 실행하려면 간단히 다음 명령어를 입력합니다:

k9s

이 명령어를 입력하면 K9s 대시보드가 열리고, 여기서 Kubernetes 클러스터에 연결하여 리소스를 관리할 수 있습니다

K9s 사용법

리소스 보기

• 기본 네비게이션: 화살표 키를 사용하여 리소스 유형 간 이동, Enter 키를 눌러 특정 리소스의 자세한 정보를 확인할 수 있습니다.
• Pod 로그 보기: l 또는 :logs
• Pod로 실행: e 또는 :exec
• 포트 포워딩: f 또는 :port-forward

리소스 필터링 및 검색

• 명령 바: :를 사용하여 명령 바에 접근
• 필터 적용: :filter status=Running 등 필터를 적용하여 리소스 좁히기
• 검색: :search my-pod 등으로 이름 또는 라벨로 리소스 검색

리소스 관리

• 리소스 설명: d를 눌러 리소스 설명 확인
• 리소스 편집: e를 눌러 YAML 파일 편집
• 리소스 삭제: d를 눌러 리소스 삭제

고급 기능

뷰 커스터마이징

• :view 명령어를 사용하여 레이아웃을 사용자 정의
• :view save 및 :view load로 커스텀 뷰 저장 및 불러오기

단축키 및 명령어

• ?를 눌러 사용 가능한 모든 단축키 목록 확인
• : 명령 바를 사용하여 K9s 명령어 실행

참고

• K9s 공식 문서
• GitHub - K9s
• DevToolHub K9s 가이드
• Earthly Blog K9s 사용법
• Kubetools 블로그

Kubectl

kubectl은 Kubernetes 클러스터를 cli(Command Line Interface) 방식으로 관리하는 데 쓰는 툴입니다. Kubernetes 클러스터에서 리소스 배포, 서비스 스케일링 조정, 로그 확인 등 다양한 작업을 수행할 수 있습니다.

Kubectl 설치

Windows에서 Kubectl 설치

- Chocolatey로 설치:

choco install kubernetes-cli

- Scoop으로 설치:

scoop install kubectl

- curl로 바이너리 다운로드:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/windows/amd64/kubectl.exe" move kubectl.exe C:\Windows\System32\kubectl.exe

2.2. macOS에서 Kubectl 설치

macOS에서는 Homebrew를 이용해 손쉽게 kubectl을 설치할 수 있습니다.

- Homebrew로 설치:

brew install kubectl

- curl로 바이너리 다운로드:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/kubectl

2.3. Linux에서 Kubectl 설치

Linux에서는 패키지 관리자를 사용하거나, 직접 바이너리를 다운로드하는 방법으로 kubectl을 설치할 수 있습니다.

- APT 패키지 관리자를 이용한 Ubuntu/Debian 설치:

sudo apt-get update sudo apt-get install -y apt-transport-https ca-certificates curl sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo apt-get update sudo apt-get install -y kubectl

- YUM 패키지 관리자를 이용한 CentOS/RHEL 설치:

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg exclude=kube* EOF sudo yum install -y kubectl --disableexcludes=kubernetes

- curl로 바이너리 다운로드:

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" chmod +x kubectl sudo mv kubectl /usr/local/bin/kubectl

설치가 완료된 후 kubectl version --client 명령어를 사용하여 설치가 성공적으로 이루어졌는지 확인합니다.

3. Kubectl 설정 및 기본 사용법

설치가 완료된 후, kubectl을 사용하여 Kubernetes 클러스터에 접근하려면 클러스터의 kubeconfig 파일을 설정해야 합니다. kubeconfig 파일은 kubectl이 어떤 클러스터에 연결할지, 어떤 자격 증명을 사용할지 등을 정의합니다.

Kubeconfig 파일 설정

보통 ~/.kube/config 경로에 위치하며, 다중 클러스터 환경에서는 여러 kubeconfig 파일을 사용할 수 있습니다. 환경 변수 KUBECONFIG를 사용하여 특정 설정 파일을 지정할 수 있습니다.

자세한 설정은 kubeconfig 파일을 사용하여 클러스터 접근 구성하기 문서를 참조해주세요!

$env:KUBECONFIG="C:\Users\your-user\.kube\config"

기본 명령어

클러스터 정보 확인: kubectl cluster-info

현재 컨텍스트 확인: kubectl config current-context

모든 네임스페이스의 리소스 목록 조회: kubectl get all --all-namespaces

리소스 배포: kubectl apply -f deployment.yaml

리소스 삭제: kubectl delete -f deployment.yaml

설치한 kubectl이 작동하지 않을 때 대처

설치 후 kubectl 명령어가 정상적으로 작동하지 않는 경우, PATH 환경 변수를 확인해보세요! 또한, Kubernetes 클러스터와 연결되지 않는다면 kubeconfig 파일이 올바르게 설정되었는지 확인해봐야 합니다.

버전 확인

현재 설치된 kubectl의 버전을 확인하여 Kubernetes 클러스터와 호환되는지 점검합니다.

kubectl version --client

참고 자료

• Kubernetes 공식 문서 - 윈도우에서 kubectl 설치
• Chocolatey - 패키지 관리자 설치 가이드
• Scoop - 패키지 관리자 설치 가이드
• Kubernetes 공식 문서 - kubectl 설치 및 설정 가이드

로드 밸런싱(Load Balancing)

로드 밸런싱은 네트워크 트래픽을 여러 서버에 분산시키는 역할을 하는 장치 또는 소프트웨어다.

서버의 부하를 줄이고, 가용성을 높이며, 응답 시간을 개선하는데 도움을 준다.

로드 밸런서의 종류

1. L4 Load Balancer

L4 로드 밸런서는 네트워크 계층에서 작동하며, IP 주소와 포트 정보를 기반으로 트래픽을 분산시켜준다. 그래서 단순하고 빠른 처리가 가능하지만, 패킷의 안쪽 내용까진 볼 수 없기 때문에 트래픽의 내용에 대한 깊은 작업은 제한적이다. 

2. L7 Load Balancer

L7 로드 밸런서는 응용 프로그램 계층에서 작동하며, 패킷의 안쪽 내용까지 보고 로드밸런싱 할 수 있기 때문에 HTTP 헤더, 쿠키, 세션 정보 등을 기반으로 트래픽을 분산시킨다. 그래서 더 복잡하고 세밀한 로드밸런싱 정책을 구현할 수 있지만, 처리에 더 많은 리소스가 필요하다. 즉, L4는 빠르고 자원효율적이지만 L7에 비해서 세심한 작업은 불가능하다.

로드 밸런서 알고리즘

L4와 L7 로드 밸런서는 트래픽을 분산시키는 방법을 결정할 때 알고리즘을 사용한다.

L4 Load Balancer 알고리즘:

1. Round Robin: 각 서버에 순차적으로 연결을 분산시키는 방법이다. 모든 서버가 동일한 처리 능력을 가지고 있을 때 유용하다.
2. Least Connections: 현재 가장 적은 연결을 가진 서버에 새 연결을 할당하는 방법이다. 서버마다 처리 능력이 다를 때 쓰기 좋다.
3. IP Hash: 클라이언트의 IP 주소를 해싱하여 특정 서버에 연결을 할당하는 방법이다. 이 방법은 세션 지속성을 필요로 하는 경우에 좋다.

L7 Load Balancer 알고리즘:

1. URL Hash: 클라이언트의 요청 URL을 해싱하여 특정 서버에 연결을 할당하는 방법이다. 이 방법은 URL 기반의 세션 지속성을 필요로 할 때 효율적이다.
2. HTTP Header: HTTP 헤더의 특정 값(예: 사용자 에이전트, 쿠키 등)을 기반으로 특정 서버에 연결을 할당하는 방법이다.
3. Least Time: 가장 빠른 응답 시간을 가진 서버에 새 연결을 할당하는 방법이다. 이 방법은 서버의 성능과 네트워크 지연 시간을 모두 고려할 때 사용하기 좋다.

더 깊게 알아보고 싶다면, AWS의 로드 밸런싱에 대한 페이지에서 더 자세하고 많은 정보를 알 수 있다.

서브넷 마스크?

서브넷 마스크는 32비트의 숫자로 구성된다. 이 숫자들은 '0'과 '1'로 이루어져 있다.

여기서 '0'의 비트는 호스트 부분을 나타내고, '1'의 비트는 네트워크 부분을 나타내는데, 이를 통해서 서브넷 마스크는 IP 주소를 네트워크 주소와 호스트 주소로 분리시켜준다.

이렇게 IP 주소를 '마스킹'하는 것이기 때문에 '서브넷 마스크' 라고 부른다.

그래서 서브넷이 뭔데?

전 세계에는 수백만 개의 네트워크가 존재하며, 그 규모는 너무나 다양하다.

큰 규모의 네트워크는 관리하기 어렵기 때문에, 이를 작은 조각으로 나누어 관리하는 것이 효율적이다.
그렇게 나뉜 작은 네트워크를 '서브넷' 이라고 한다. 그리고 이러한 과정을 '서브네팅' 이라고 하며, 이를 통해 네트워크 성능을 개선하고 자원을 효율적으로 분배할 수 있다.

서브네팅은 관리의 용이성, 고급 네트워크 보안, 네트워크 트래픽 감소 등 여러 장점을 가지고 있다. 또한, 서브네팅을 통해 인터넷 서비스 업체로부터 추가적인 IP 주소를 받을 필요가 없다. 하지만, 서브네팅을 위해 추가적인 하드웨어가 필요한 경우가 있어, 이로 인한 비용이 발생할 수 있다는 단점도 있다.

서브넷 마스크의 작동 원리

IP 주소는 네트워크 구성요소와 호스트 구성요소로 이뤄져있다. 예를 들어, '192.168.123.132'라는 IP 주소에서 '192.168.123.'는 네트워크를 나타내고, '132'는 네트워크에 연결된 기기를 가리킨다.

IP 주소는 32비트로 구성되고, 이를 십진수 체계로 표현하면 다음과 같다

: '192.168.123.132' = '11000000.10101000.01111011.10000100'.

이 IP 주소의 서브넷 마스크는 네트워크 부분을 반영하며, 다음과 같이 나타낼 수 있다

: '255.255.255.0' = '11111111.11111111.11111111.00000000'.

이 둘을 합치면 다음과 같은 결과를 볼 수 있다

'11000000.10101000.01111011.00000000' (네트워크 주소: '192.168.123.0')
'00000000.00000000.00000000.10000100' (호스트 주소: '000.000.000.132')

여기서 '192.168.123.0'이 서브넷이며, '192.168.123.132'는 대상 주소(서브넷 내 기기)다.

IP 주소 클래스

IP 주소 클래스는 A, B, C로 나뉩니다. 각 클래스마다 기본 서브넷 마스크가 다르며, IP 주소의 첫 세 자리를 확인하여 클래스를 확인할 수 있다.

• 클래스 A: 255.0.0.0의 서브넷 마스크를 이용하며 첫 옥텟(8비트로 구성된 부분)은 0~127로 구성되어 있습니다. 126개의 네트워크를 허용하며 네트워크당 호스트가 거의 1,700만 개에 달한다.
• 클래스 B: 255.255.0.0의 서브넷 마스크를 이용하며 첫 옥텟은 128~191로 구성된다. 클래스 B IP 주소는 중간 규모와 대규모 네트워크에서 이용한다. 클래스 B는 약 1600개의 네트워크를 허용하며 네트워크당 65,000개의 호스트를 허용한다.
• 클래스 C: LAN(Local Area Network)에 이용되며 200만 개의 네트워크를 허용하고 각각 254개의 호스트를 두고 있다. 클래스 C는 255.255.255.0의 서브넷 마스크를 이용하고 첫 옥텟은 192~223으로 구성되어 있다.

서브넷 마스크를 찾는 방법

 서브넷 마스크를 찾는 방법은 운영 체제에 따라 다르다.
 아래는 MacOS, Windows, iOS, Android 운영체제에서 서브넷 마스크를 찾는 방법이다.

• MacOS: 시스템 환경설정 > 네트워크로 이동하세요. 네트워크를 선택하시고 고급을 클릭하세요. TCP/IP 탭을 클릭하시면 서브넷 마스크와 함께 IP 주소를 확인할 수 있습니다.
• Windows: 제어판 > 네트워크 및 인터넷으로 이동하세요. 네트워크 이름을 선택한 후 세부사항을 클릭합니다. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• iOS: 설정 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 확인하시고 ‘i’ 아이콘을 클릭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.
• Android: 설정 > 연결 > Wi-Fi로 이동하세요. 현재 연결된 네트워크를 탭하세요. 여기서 다른 네트워크 세부사항과 함께 서브넷 마스크를 확인할 수 있습니다.

일정 및 작업 관리

 이번프로젝트에서는 팀장으로서 팀이 프로젝트를 성공적으로 마무리 할 수 있도록 어떤 순서로 작업을 하고, 인원배분은 또 어떻게 해야할지에 대해서 많은 고민을 했다.

공동 작업

 여러명이서 함께하는 팀 프로젝트인 만큼 작업내용을 구체화해서 작업시간과 인원을 배분하면 좋겠다고 생각했고, 이렇게 구체화한 작업들을 관리하기 위해서 칸반보드를 사용해서 현재 프로젝트의 진행상황이 어떤지, 작업 중에 어떤 문제를 마주쳤고 어떻게 해결했는지 확실하게 남기고자 했다.

 팀 규칙, 주제 선정, 시스템 설계 작성 등 프로젝트 진행에 대해 전체적인 방향성 해결해야할 문제에는 팀원 모두가 함께 머리를 맞대 최대한 빠르게 합리적인 결론을 도출하고자했다. 그리고 아래처럼 토의의 내용과 결과를 issue 탭에 기록해 issue 탭에 기록한 내용을 바탕으로 프로젝트의 다음단계를 진행했다.

 실제 구현파트의 작업분배는 팀원들 각각의 강점을 고려해서 분배했고, 나는 POC로서 각 일정들이 제시간에 마무리 될 수 있도록 각 파트를 오가며 작업상황을 체크하고 작업을 도와서 최대한 빨리 작업을 마무리할 수 있게끔 하는 역할을 맡았다.

이땐 알지 못했다..ㅠ 작업파트를 정하지 않았다는 것이 얼마나 많은 노동을 의미하는지...

파트 분배 작업

 각자 파트를 나눠 작업해야하는 구간에서는 각 파트의 진행사항을 확인하고, 작업을 도왔다. 그래서 프론트 부분의 로직과 인프라, 백엔드 부분의 로직과 인프라 작업 모두에 참여했다.

 그리고 진행상황을 최대한 쉽게 파악하기 위해 각 파트에서 해야할 일의 프로세스를 정해서 체크리스트로 만들었다.

물론 작업 중에 이슈를 마주쳤을 때 아래처럼 해당 이슈에 대한 기록도 남겨 내가 어떤문제를 마주했고 어떻게 해결했는지 팀원들도 알 수 있도록 했다.

오류에 대한 해결방법을 보고싶다면 아래 게시글을 확인해주면 된다.

2023.06.20 - [DevOps] - [DevOps] 최종 프로젝트 회고 - 구현(클라우드 리소스)

API Gateway 생성

먼저 API Gateway를 생성해준다.

Rest API는 VPC내부의 Private ALB와는 연결할 수 없기 때문에 HTTP API로 생성해줘야한다.

그리고 통합 생성 및 구성은 지금 당장은 넘겨도 된다. API Gateway를 생성하고 나서 구성해도 늦지않다.

경로 구성도, 스테이지 구성도 건드리지 않고 넘긴다.

모든 과정을 거친 후 생성시켜준다.

그리고 VPC 링크를 만들어줘야한다. 그래야 API Gateway가 VPC의 보호를 받고 있는 내부의 ALB에 접근할 수 있다.

VPC링크 생성은 쉽다. API Gateway가 접속할 VPC를 선택해주고 이름만 입력해주면 된다. 물론 VPC를 선택하고나서 어떤 서브넷에 연결시킬 것인지, 보안그룹은 어떻게 설정할지는 ALB를 고려해서 잘 선택해줘야한다.

그리고나서 만들어둔 HTTP API로 가서 라우트 탭으로 들어가서 알맞은 메서드와 리소스를 생성해주면된다.

리소스와 메서드를 생성했다면 이제 ALB와 연결할 차례다. Integration탭으로 가서 원하는 메서드를 선택해 통합을 생성해준다.

 통합 유형에는 VPC에 있는 리소스와 연결하는 프라이빗 리소스를 선택해주고,

 수동으로 선택 ==> ALB/NLB를 골라주나서 내가 연결하길 원하는 로드 밸런서를 선택해준다.

 뭐..리스너도 설정할 수 있고 고급 설정에서 호출할 메서드랑 타임아웃같은 옵션도 정할 수 있는데 그건 알잘딱하게 선택해주면 된다. 그리고 캡처화면에는 없지만 맨 아래 VPC링크를 선택하는 것도 잊으면 안된다.

그럼 아마 이렇게 생성이 돼있을 거다. 이제 끝났다. 배포 스테이지 탭으로 가서 링크로 들어가면 ALB가 잘 열릴 것이다.

Terraform을 사용해서 이번 프로젝트에서 구축해야하는 AWS 리소스들을 코드로 관리할 수 있게끔 했다. 

이번에는 프로젝트를 진행하면서 작성한 Terraform을 사용해서 어떻게 IaC 구현을 했는지 대한 기록을 남겨두려고 한다.

Terraform Backend 구성하기

 테라폼 백엔드를 사용해서 tfstate 파일을 깃허브 레포지토리로부터 분리해 외부로 현재 인프라가 어떻게 구성되었는지에 대한 정보가 노출되지 않도록 했다. s3만 사용할 수도 있지만, 다이나모 DB를 사용해서 locking까지 할 수 있도록 했다.

먼저 따로 만들어둔 테라폼 백엔드 작업용 디렉토리에서 tfstate파일을 저장할 저장소를 terraform을 사용해서 생성한다.

참고 : https://devops-james.tistory.com/123

저장소 생성 코드

#terraformbackendresource.tf

provider "aws" {
  region = "ap-northeast-2"
}

resource "aws_s3_bucket" "mys3bucket" {
  bucket = "Devops-Final-tfstate"
}

# Enable versioning so you can see the full revision history of your state files
resource "aws_s3_bucket_versioning" "mys3bucket_versioning" {
  bucket = aws_s3_bucket.mys3bucket.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_dynamodb_table" "mydynamodbtable" {
  name         = "terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

output "s3_bucket_arn" {
  value       = aws_s3_bucket.mys3bucket.arn
  description = "[S3버킷의 ARN을 입력하세요]"
}

output "dynamodb_table_name" {
  value       = aws_dynamodb_table.mydynamodbtable.name
  description = "[다이나모 DB 테이블 이름 적어주세요]"

그리고 원격 백엔드를 둘 경우에는 먼저 둘 곳인 S3 저장소가 생성된 이후에 다시 terraform init을 해서 Terraform Backend를 적용시켜줘야한다.

Terraform Backend 적용 코드

terraform {
  backend "s3" {
    bucket = "Devops-Final-tfstate"
    key    = "TF-backend/terraform.tfstate"
    region = "ap-northeast-2"
    dynamodb_table = "terraform-locks"
  }
}

그리고 terraform init을 하면 아래처럼 테라폼 백엔드가 적용되는 것을 볼 수 있다.

terraform init
Initializing the backend...
Do you want to copy existing state to the new backend?
  Pre-existing state was found while migrating the previous "local" backend to the
  newly configured "s3" backend. No existing state was found in the newly
  configured "s3" backend. Do you want to copy this state to the new "s3"
  backend? Enter "yes" to copy and "no" to start with an empty state.

Terraform 코드를 사용한 리소스 생성.

VPC.tf

VPC.tf 에서 서브넷과 인터넷 게이트웨이, 보안 그룹, 라우팅 테이블 구성을 해준다. 그리고 VPC내부에서 보호되고있는 컴퓨팅 유닛이 VPC외부의 AWS리소스와 상호작용 할 수 있도록 VPC 엔드 포인트도 만들어줬다.

소스코드 더보기

resource "aws_vpc" "my-vpc" {
    cidr_block = "10.0.0.0/16"
    enable_dns_support   = true
    enable_dns_hostnames = true
    tags       = {
        Name = "Terraform VPC"
    }
}

# create subnet
resource "aws_subnet" "PublicSubnet01" {
  vpc_id = aws_vpc.my-vpc.id
  cidr_block = "10.0.1.0/24"
  availability_zone = "ap-northeast-2a"
  map_public_ip_on_launch = true

  tags = {
    Name = "my-public-subnet01"
  }
}

resource "aws_subnet" "PublicSubnet02" {
  vpc_id = aws_vpc.my-vpc.id
  cidr_block = "10.0.2.0/24"
  availability_zone = "ap-northeast-2c"
  map_public_ip_on_launch = true

  tags = {
    Name = "my-public-subnet02"
  }
}
resource "aws_subnet" "PrivateSubnet01" {
  vpc_id = aws_vpc.my-vpc.id
  cidr_block = "10.0.3.0/24"
  availability_zone = "ap-northeast-2a"
  
  tags = {
    Name = "my-private-subnet01"
  }
}
resource "aws_subnet" "PrivateSubnet02" {
  vpc_id = aws_vpc.my-vpc.id
  cidr_block = "10.0.4.0/24"
  availability_zone = "ap-northeast-2c"
  
  tags = {
    Name = "my-private-subnet02"
  }
}

# 인터넷 게이트웨이 ( 외부 인터넷에 연결하기 위함 )
resource "aws_internet_gateway" "my-IGW" {
  vpc_id = aws_vpc.my-vpc.id
}

# 라우팅 테이블
## 1. 퍼블릭 라우팅 테이블 정의
resource "aws_route_table" "my-public-route" {
  vpc_id = aws_vpc.my-vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.my-IGW.id
  }
}

## 퍼블릭 라우팅 테이블 연결
resource "aws_route_table_association" "my-public-RT-Assoication01" {
  subnet_id = aws_subnet.PublicSubnet01.id
  route_table_id = aws_route_table.my-public-route.id
}
resource "aws_route_table_association" "my-public-RT-Assoication02" {
  subnet_id = aws_subnet.PublicSubnet02.id
  route_table_id = aws_route_table.my-public-route.id
}

## 보안 그룹
resource "aws_security_group" "my-SG" {
  vpc_id = aws_vpc.my-vpc.id
  name = "my SG"
  description = "my SG"
  tags = {
    Name = "my SG"
  }
}

## 보안 그룹 규칙
resource "aws_security_group_rule" "my-ingress-rule-22" {
  type              = "ingress"
  from_port         = 22
  to_port           = 22
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "my-ingress-rule-80" {
  type              = "ingress"
  from_port         = 80
  to_port           = 80
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "my-ingress-rule-443" {
  type              = "ingress"
  from_port         = 443
  to_port           = 443
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "my-ingress-rule-3000" {
  type              = "ingress"
  from_port         = 3000
  to_port           = 3000
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "my-ingress-rule-3306" {
  type              = "ingress"
  from_port         = 3306
  to_port           = 3306
  protocol          = "tcp"
  cidr_blocks       = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id

  lifecycle {
    create_before_destroy = true
  }
}

resource "aws_security_group_rule" "my-egress-rule" {
  type = "egress"
  from_port = 0
  to_port = 0
  protocol = "-1"
  cidr_blocks = ["0.0.0.0/0"]
  security_group_id = aws_security_group.my-SG.id
  lifecycle {
    create_before_destroy = true
  }
}

# vpc내부의 컴퓨팅 유닛이 다이나모 DB에 연결할 수 있도록 하기위해 vpc 엔드포인트 생성.
resource "aws_vpc_endpoint" "my-vpc-endpoint" {
  vpc_id              = aws_vpc.my-vpc.id
  service_name        = "com.amazonaws.ap-northeast-2.dynamodb"
  vpc_endpoint_type   = "Gateway"
}

resource "aws_vpc_endpoint_route_table_association" "my_vpc_endpoint_rt_association" {
  vpc_endpoint_id = aws_vpc_endpoint.my-vpc-endpoint.id
  route_table_id  = aws_route_table.my-public-route.id
}

alb.tf

인터넷과 연결되지 않고 VPC 내부의 컴퓨팅 유닛으로 Load Balancing을 수행하는 ALB를 만들어줬다.

소스코드 더보기

resource "aws_alb" "my_alb" {
  name = "Taskmanagement-ALB2"
  internal = true
  load_balancer_type = "application"
  security_groups = [aws_security_group.my-SG.id]
  subnets = [aws_subnet.PrivateSubnet01.id, aws_subnet.PrivateSubnet02.id]
  enable_cross_zone_load_balancing = true
}

# 80포트를 리슨하고
resource "aws_lb_listener" "lb_listener" {
  load_balancer_arn = aws_alb.my_alb.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.my-target-group.arn
  }
}

# 3000포트를 타겟한다.
resource "aws_lb_target_group" "my-target-group" {
  name     = "Taskmanagement-TG2"
  port     = 3000
  protocol = "HTTP"
  vpc_id   = aws_vpc.my-vpc.id

  target_type = "ip"

  health_check {
  enabled             = true          # 헬스 체크 활성화
  interval            = 30            # 헬스 체크 간격(초)
  path                = "/"           # 헬스 체크에 사용할 경로
  protocol            = "HTTP"        # 사용할 프로토콜
  timeout             = 5             # 각 헬스 체크에 대한 타임아웃(초)
  healthy_threshold   = 3             # 건강한 상태로 판단하기 전에 연속적으로 통과해야 하는 헬스 체크 수
  unhealthy_threshold = 3             # 건강하지 않은 상태로 판단하기 전에 연속적으로 실패해야 하는 헬스 체크 수
  matcher             = "200-299"     # 헬스 체크 응답에 대한 HTTP 상태 코드
  }
}

apigateway.tf

APIGateway는 VPC 내부의 private ALB와 연결돼야하기 때문에 HTTP API로 생성했다.

api 설계에 맞춰서 구현된 alb와 lambda의 엔드포인트로 넘어가는 요청 메서드들을 설정해줬다. 

그리고 private ALB에 연결할 수 있도록 VPC Link를 만들어줬다.

코드보기

module "apigateway" {
  source  = "terraform-aws-modules/apigateway-v2/aws"
  version = "2.2.2"

  create_api_domain_name = false

  name          = "Task-management API-tf"
  description   = "Task-management API created by terraform"
  protocol_type = "HTTP"

#cors 설정. 테스트를 위해서 모든 헤더와 메서드, 송신자를 허용한다.
  cors_configuration = {
    allow_headers = ["*"]
    allow_methods = ["*"]
    allow_origins = ["*"]
  }

  default_route_settings = {
    data_trace_enabled       = true
    detailed_metrics_enabled = true
    logging_level            = "INFO"
    throttling_burst_limit   = 5000
    throttling_rate_limit    = 10000
  }

  integrations = {
    "POST /user" = {
      lambda_arn             = "[람다 ARN을 입력하세요]"
      payload_format_version = "1.0"
      timeout_milliseconds   = 12000
    }

    "GET /" = {
      connection_type    = "VPC_LINK"
      vpc_link           = "my-vpc-Link"
      integration_uri    = "[로드밸런서의 리스너 ARN을 입력하세요]"
      integration_type   = "HTTP_PROXY"
      integration_method = "GET"
    }

    "POST /" = {
      connection_type    = "VPC_LINK"
      vpc_link           = "my-vpc-Link"
      integration_uri    = "[로드밸런서의 리스너 ARN을 입력하세요]"
      integration_type   = "HTTP_PROXY"
      integration_method = "POST"
    }

    "PUT /{Task_id}" = {
      connection_type    = "VPC_LINK"
      vpc_link           = "my-vpc-Link"
      integration_uri    = "[로드밸런서의 리스너 ARN을 입력하세요]"
      integration_type   = "HTTP_PROXY"
      integration_method = "PUT"
    }

    "DELETE /{Task_id}" = {
      connection_type    = "VPC_LINK"
      vpc_link           = "my-vpc-Link"
      integration_uri    = "[로드밸런서의 리스너 ARN을 입력하세요]"
      integration_type   = "HTTP_PROXY"
      integration_method = "DELETE"
    }
  }

#VPC에 의해서 외부로부터 보호받고있는 ALB에 연결하기 위해서 
  vpc_links = {
    my-vpc-Link = {
      name               = "Task-VPC-Link-tf"
      security_group_ids = ["서브넷 아이디 입력하세요"] # 내가 연결하고싶은 vpc의 서브넷에 연결한다.
      subnet_ids         = ["서브넷 아이디 입력하세요", "서브넷 아이디 입력하세요"]
    }
  }

아키텍처는 이미 앞서 설계 부분에서 소개를 했기 때문에 구현과정 중 트러블 슈팅에 대한 내용을 위주로 작성했다.

트러블 슈팅에 대한 내용을 말하기 전에, 우리 아키텍처가 더 나아지기 위해서 어떤 작업을 하면 좋을지 생각해봤다.

아키텍처 발전 방안 1. Private Subnet과 Nat Gateway를 활용한 보안성 향상

 현재 구현한 아키텍처에는 ECS가 Public Subnet 에 위치하도록 구성이 되어 있는데, 이 부분이 보안 부분에 취약 할 수 있다는 우려가 있어 아래의 아마존 공식 문서를 참고해 지금의 이미지처럼 아키텍처를 보완했다.

 ECS 와 DB서버를 Private Subnet에 위치하게 두고 NAT Gateway를 Public Subnet으로 분리하여 ALB를 통한 ECS와의 통신은 유지하면서 클러스터 내부의 IP주소 노출위험을 제거했다. 

참고자료 : https://docs.aws.amazon.com/ko_kr/vpc/latest/userguide/vpc-nat-gateway.html

Issue .1) ECR 레포지토리 이미지 Task 생성 실패

작성한 백엔드 코드를 테스트 해보기 위해 ECR에 이미지 푸쉬 후 콘솔에서 테스트를 해보려 했으나 클러스터에 Task가 생성되지 않는 문제가 발생 했다.

• Fargate에서는 정상적으로 돌아가는 서비스가 EC2로 생성하면 지속된 에러가 괴롭혔다.
• 확인 해본 결과 생성된 EC2가 서비스에 등록되지 않아 발생한 문제인 것을 확인했다.

• 용량 공급자 전략으로 클러스터 기본 옵션을 사용 했고 이것이 문제인 것을 확인 했다.

Issue .2) 생성된 EC2 클러스터에 등록 불가.

시작 유형으로 직접 클러스터 생성 시 만들어지는 EC2를 등록하려 했으나 클러스터에 EC2가 잡히지 않았다.

• 생성된 EC2에 퍼블릭 IP주소 할당이 안 되어 클러스터에 노출이 안 되는 것을 확인 했다.

• VPC 옵션 중 퍼블릭 IPv4 주소 자동 할당을 활성화 시켜주니 EC2에 퍼블릭 IPv4 주소가 할당 되고 클러스터에 EC2가 잡혔다.

• 정상적으로 EC2가 활성화 되었다.

• 당시 생성 했던 EC2 유형.

• 등록된 인프라 컨테이너

Issue. 3) Task 생성 실패

EC2 컨테이너는 등록을 했지만 이번엔 Task가 생성이 되지 않았다.

• 에러 로그에서 생성된 EC2의 메모리의 크기가 컨테이너보다 작아서 발생 된 문제 라는 것을 확인했고 t3.nano 에서 m6i.large로 바꿨더니 정상적으로 Task가 생성 되었다.

Issue .4) Service 배포 실패

정상적으로 Task 생성에는 성공 했지만 서비스 배포에는 실패 했다.

• health check 에 unhealthy가 떴고, 원인이 타겟 그룹과 ALB 의 포트 매핑이 잘못되어 원활하게 포트를 못 잡고 있던 것을 확인했다.

• ALB (80) - Listener(80) - Target Group (3000) - 컨테이너 (3000) 으로 매핑을 시켜 포트를 다시 잡아줬다.

• 보안그룹의 불필요한 포트들도 다시 정리 해주었다.

슈팅 성공

• Healthy와 status code 200의 반환과 ALB 주소로 접속이 성공했다.

Issue .5) 배포된 이미지의 DynamoDB 엑세스 불가

 ECS 클러스터로 이미지 배포에는 성공했지만 배포된 컨테이너가 다이나모 DB에 제대로 아이템을 넣지 못하는 문제가 발생했다.

 ECR에 배포된 이미지가 정상임에도 실제 배포 환경에서 제대로 작동하지 않는 문제는 권한 문제가 원인일 수도 있다고 생각해 Task의 실행 역할을 확인해 DynamoDB에 엑세스권한이 없다는 것을 확인하고 다음 이미지와 같이 정책을 추가해줬다.

 하지만, 권한을 부여해줬음에도 제대로 작동하지 않는 것을 확인했고, 다른 원인이 있을 것이라고 생각해 알아봤다. 

https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/vpc-endpoints-dynamodb.html

 원인을 찾아보던 중 아마존 공식 문서에서 관련된 내용을 찾을 수 있었다.

 해당 문서는 vpc엔드포인트를 통해 VPC내부의 ec2가 외부의 Dynamodb 와 상호작용할 수 있도록 설정하는 법에 대해서 설명한 문서인데, 문서에서 안내해준대로 VPC 엔드 포인트를 통해 DynamoDB에 엑세스할 수 있도록 설정했더니 문제없이 아래처럼 EC2가 DynamoDB에 아이템을 집어넣는 것을 확인할 수 있었다.

Issue .6) 도메인 트래픽 API Gateway 접근 거부

 API Gateway의 CORS 설정에서 도메인 트래픽에 포함된 header를 거부하도록 설정해둬서 POSTMAN으로 접속시에는 원활하게 작동하는 API가 도메인을 웹브라우저로 접속하면 접속이 되지않는 현상을 발견했다.

 웹브라우저가 요청에서 어떤 header가 포함되어 요청 메시지를 보내는지 확인하고, CORS에서 해당 헤더에 대한 허가 정책을 설정해주니 API Gateway가 잘 작동하는 모습을 확인할 수 있었다.

리소스 구현을 진행하며 느낀 점

 아키텍처 컨셉을 증명하는 작업. 즉, 클라우드 리소스들을 만드는 작업을 진행하면서 이 클라우드 리소스에서 작업을 할때 어떤 점을 신경써줘야하는가에 대해서 감을 잡을 수 있었다.

 물론 AWS 클라우드 서비스의 종류는 아주아주 다양하고, 각 서비스들에 대해서 이해를 잘 하고있어야 제대로 사용할 수 있기 때문에 배우면 배워갈 수록 내가 점점 더 작아져보이는 듯한 기분이 든다..ㅎ

 그래도 하나하나씩 배우다보면 언젠가는 클라우드 서비스들을 자유롭게 엮어서 강력한 아키텍처를 구성할 수 있는 참된 엔지니어가 될 수 있을거라고 믿어 의심하지 않는다.

 그거 의심할 시간에 한번이라도 더 리소스들이 어떻게 작동하는지 파악해야하니까 말이다

CI/CD 파이프라인 구현 - Git Action workflow .yaml파일 작성

ECS 이미지 배포 yaml 코드

name: Deploy to Amazon ECS

on:
  push:
    branches: [ "dev" ]
    paths: 
      - 'Task/**' 

env:
  AWS_REGION: [region]
  ECR_REPOSITORY: [ECR Repository name]
  ECR_BACKUP_REPOSITORY: [ECR Repository name]
  ECS_SERVICE:[ECS Service name]
  ECS_CLUSTER: [ECS Cluster name]
  CONTAINER_NAME: [ECS Container name]

permissions:
  contents: read

jobs:
  deploy:
    name: Deploy
    runs-on: ubuntu-latest
    env:
     working-directory: "./Task"  
  

    steps:
    - name: Checkout
      uses: actions/checkout@v3

# AWS 인증하기
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ env.AWS_REGION }}

# ECR에 로그인하기
    - name: Login to Amazon ECR
      id: login-ecr
      uses: aws-actions/amazon-ecr-login@v1

#각 빌드된 이미지들에게 고유한 태그(github.sha값)를 달아 ECR에 푸시
    - name: Build, Unique tag, and push image to Amazon ECR
      id: build-unique-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: ${{ github.sha }}
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build -t $ECR_REGISTRY/$ECR_BACKUP_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_BACKUP_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_BACKUP_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
      working-directory: ${{ env.working-directory }}
      
#latest 태그를 달아 ECR에 푸시한다. 푸시되는 레포지토리는 각각 다르다.
    - name: Build, latest tag, and push image to Amazon ECR
      id: build-image
      env:
        ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
        IMAGE_TAG: latest
      run: |
        # Build a docker container and
        # push it to ECR so that it can
        # be deployed to ECS.
        docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
        docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG
        echo "image=$ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG" >> $GITHUB_OUTPUT
      working-directory: ${{ env.working-directory }}

#가장 최근에 사용한 task정의 파일을 사용할 수 있도록 가져온다.
    - name: Retrieve most recent ECS task definition JSON file
      id: retrieve-task-def
      run: |
        aws ecs describe-task-definition --task-definition [task-definition family name] --query taskDefinition > task-definition.json
        cat task-definition.json
        echo "::set-output name=task-def-file::task-definition.json"

# $GITHUB_OUTPUT
# ECS 태스크 정의에 푸시한 ECR이미지 id를 집어넣는다.
    - name: Fill in the new image ID in the Amazon ECS task definition
      id: task-def
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ steps.retrieve-task-def.outputs.task-def-file }}
        container-name: ${{ env.CONTAINER_NAME }}
        image: ${{ steps.build-image.outputs.image }}

# ECS 태스크 정의를 배포한다.
    - name: Deploy Amazon ECS task definition
      uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

이미지를 푸시할 ECR 이미지를 2개로 나눈 이유

 우린 ECR에 이미지를 푸시한 후 배포할 때, latest태그가 붙어있는 이미지를 배포하는 것으로 aws.json의 태스크 정의 파일을 작성했다.

 그런데 ECR 레포지토리에 푸시된 이미지를 보니 가장 최근에 배포된 latest태그가 붙어있는 이미지를 제외하고 나머지 이미지들은 태그가 붙어있지 않고있다는 것을 확인해 각 배포되는 이미지에 Unique한 값을 가진 태그를 붙여 서로 구별이 가능하고 만약의 경우에 태그를 지정해서 이미지 작업을 할 수 있도록 했다.

그리고 task.json파일에는 aws리소스의 주소같은 크리티컬한 정보들이 담겨있기 때문에 민감한 정보들의 노출을 최소화하기 위해서 가장 최근에 사용했던 task.json파일을 사용해서 인프라를 배포하도록 코드를 작성했다.

Lambda 이미지 배포 yaml 코드

name: Deploy to Auth Lambda

on:
  push:
    branches: [ "dev" ]
    paths: 
      - 'Auth/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
     working-directory: "./Auth"  
    steps:
    - name: Checkout
      uses: actions/checkout@v3  # 최신 소스 코드를 체크아웃합니다.

    - name: Set up Node.js
      uses: actions/setup-node@v2
      with:
        node-version: 14  # 사용할 Node.js 버전을 지정합니다.

    - name: Install dependencies
      run: npm ci  # 필요한 의존성을 설치합니다.

    - name: Package Function
      run: zip -r function.zip *  # 필요한 파일들을 압축합니다.
      working-directory: ${{ env.working-directory }}
    
    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}  # AWS_ACCESS_KEY_ID를 GitHub Secrets에서 가져옵니다.
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}  # AWS_SECRET_ACCESS_KEY를 GitHub Secrets에서 가져옵니다.
        aws-region: ap-northeast-2  # AWS region을 지정합니다.

    - name: Deploy to Lambda
      run: aws lambda update-function-code --function-name <람다 함수 이름> --zip-file fileb://function.zip  # Lambda 함수 이름
      working-directory: ${{ env.working-directory }}

S3 정적웹사이트 배포 yaml 코드

name: workflow for S3 Deploy

on:
  push:
    branches: [ "dev" ]
    paths: 
      - 'Front/**' 

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  S3_BUCKET_NAME: ${{ secrets.S3_BUCKET_NAME }}
  S3_BUCKET_REGION: [region]
      
jobs:
  run:
    runs-on: ubuntu-latest
    env:
     working-directory: "./Front"  
    
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ env.AWS_ACCESS_KEY_ID }}  # AWS_ACCESS_KEY_ID를 GitHub Secrets에서 가져옵니다.
          aws-secret-access-key: ${{ env.AWS_SECRET_ACCESS_KEY }}  # AWS_SECRET_ACCESS_KEY를 GitHub Secrets에서 가져옵니다.
          aws-region: ${{ env.S3_BUCKET_REGION }}  # AWS region을 지정합니다.

      - name: Deploy to S3
        run: |
          aws s3 sync ./ s3://${{ env.S3_BUCKET_NAME }}/
        working-directory: ${{ env.working-directory }}  # 정적 웹 페이지 파일이 위치한 디렉토리를 지정합니다.

 CI/CD 파이프라인을 만들면서 개발을 하면서 실제 리소스에서도 잘 돌아가는지 테스트하기 위한 dev브랜치와 진짜 서비스 제공을 위해서 배포하기 위한 버전 코드가 올라가는 main브랜치로 구분해서 CI/CD를 구현하려고 했습니다.
 dev브랜치 CI/CD가 배포하는 리소스와 main 브랜치 CI/CD가 배포하는 리소스를 구분해서 배포할 수 있다면 확실하게 개발과 프로덕션 파트를 분리할 수 있을 것이라고 생각한다.

CI/CD 파이프라인 구현을 진행하며

 CI/CD파이프라인 구현을 진행하면서 단순히 깃헙에 올라온 코드를 클라우드 리소스 상에 배포하는 것 뿐만 아니라, 개발 - 프로덕션의 단계를 구분해서 배포를 하기위해서는 어떻게 하는 것이 좋을까 제대로 고민해볼 수 있었던 시간이었다.

 그리고 한번은 이상한 코드가 dev브랜치의 Front디렉토리 안으로 push되어 배포까지 진행돼버려서 Route53도메인으로 접속했을 때 요상한 화면이 출력된 적이 있는데, 만일 production와 dev의 구분없이 단일 브랜치로 레포지토리 구성을 했다면 production단계에서 앞서 말한 것 같은 끔찍한 일이 생겼을 것이다.

 그래서 dev - production을 구분해서 작업하는 것이 굉장히 중요하다는 것을 느꼈고, 어떻게 하면 잘 구분해서 사용할 수 있을지 앞으로도 더 고민해봐야할 숙제다.

리소스 아키텍처

리소스 아키텍처 설명

1. 먼저 사용자는 Route53에서 배포된 도메인을 웹브라우저를 통해 접속한다. Route53이 사용자로부터 요청을 받으면, Route53은 CloudFront에서 캐싱한 S3의 정적웹페이지를 사용자에게 보여준다.

2. API GateWay는 정적 웹페이지로부터 오는 트래픽을 메서드와 도메인 엔드 포인트 별로 분류해 로그인 요청 데이터는 인증 계층 Lambda로 보내고, 작업관리 요청 데이터는 VPC 경계의 ALB로 보낸다.

   이로써 ALB는 외부에 노출되지 않습니다. 반응 트래픽은 API Gateway를 통해 원래의 클라이언트로

  반환된다. 

3. ALB(Application Load Balancer)의 주소는 외부에 노출되지 않고, API Gateway로부터 들어오는 요청을 현재 가동중인 ECS 서비스에 속한 EC2 컨테이너들로 보낸다. 응답 트래픽은 API Gateway를 통해 원래의 클라이언트로 반환된다. 

4. 작업 관리를 위한 CRUD 트래픽은 ECS에 배포된 컨테이너의 EC2와 주고 받는다. 사용자가 작업 관리 페이지에서 생성, 읽기, 업데이트, 삭제 (CRUD) 작업을 요청할 때, 이러한 요청은 ECS (Elastic Container Service)에서 실행되는 컨테이너로 전송된다.

5. Aurora와 통신하며, 저장된 작업 데이터를 사용해 작업 관리 페이지에서 들어오는 요청을 처리한다. ECS의 각 인스턴스는 Amazon Aurora 데이터베이스와 연결되어 있으며, 사용자의 요청에 따라 데이터베이스에서 정보를 추출하거나 업데이트한다.

6. ECS 인스턴스는 Amazon CloudWatch를 사용하여 ECS 인스턴스의 성능과 사용량을 실시간으로 모니터링 할 수 있다. 이를 통해 서비스의 건강 상태를 실시간으로 추적하고 필요한 경우 적절한 조치(ex. ASG 인스턴스 조절)를 취할 수 있도록 해준다.

7. Log DynamoDB는 사용자 요청에 따른 로그를 저장한다, Aurora에서 CRUD 작업이 처리될 때마다, 사용자의 모든 요청에 대한 작업관리 로그 데이터는 DynamoDB에 저장된다. 이를 통해 작업에 어떤 변동사항이 있는지 등에 대한 유용한 정보를 제공한다.

8. EventBridge에서 설정한 규칙에 따라 Log DynamoDB의 로그가 필터링된다. Amazon EventBridge는 Log DynamoDB에 저장된 로그 데이터를 필터링하고 분석하는 역할을 합니다. 설정된 규칙에 따라 특정 이벤트에 대한 알림을 Lambda로 보내다.

9. Lambda를 통해 SES 자격증명 생성으로 보안 인증된 이메일에 로그 기록을 전송한다. 필터링된 로그 데이터는 Lambda 함수를 사용하여 사용자의 이메일로 전송된다. 이를 통해 사용자는 중요한 이벤트에 대한 알림을 즉시 받을 수 있다.

그리고 Git Action은 GitHub 레포지토리에 push된 코드들을 자동으로 각 코드들이 배포되어야할 리소스로 배포한다.  CRUD이미지는 ECS 컨테이너로, 로그인요청처리와 로그이벤트코드는 각각의 람다 함수로, 프론트 웹페이지 코드는 s3 버킷으로 배포되도록 CI/CD 파이프라인을 구성할 계획이다.

리소스 아키텍처 구상 중 토의

Issue #1

API Gateway vs Load Balancer - 리소스 아키텍처 부분에서 최대한 고가용성을 확보하기 위해 다양한 기능을 제공하는데 특화된 API Gateway 보다는, 안정적인 트래픽 분산을 시킬 수 있어 서비스 제공을 안정적으로 유지하는데에 특화된 Load Balancer를 사용하는 것에 대한 논의

• Load Balancer는 트래픽 분산에 특화되어 있고, 단순성을 생각했을 때 관리가 용이하며, 비용에서도 API Gateway와 거의 차이가 없기 때문에 Load Balancer를 사용하기로 결정하였다.

Issue #2

RDS 가용성 - Multi-AZ 기능을 사용해서 이중화 DB를 구성하여 만일 기존 DB 인스턴스에 중단이 발생했을 때, 자동으로 다른 가용 영역에 있는 복제본으로 스위칭시켜 서비스를 계속 제공할 수 있도록 하는 것에 대한 논의

• RDS는 다중 AZ 배포와 자동 백업, 복구 등의 기능이 보장되고, 다중 AZ를 사용하면 트래픽을 오프로드하고 성능을 향상시키는 데에 도움이 될 것이라고 생각해 RDS 이중화를 사용하려했다
• 물론, Aurora는 메인 DB를 Read, Write 할 수 있고 Sub DB들도 Read권한이 있어 트래픽이 분산될 뿐만 아니라 리소스의 낭비도 RDS에 비해 적기 때문에, RDS의 사용량에 따른 비용과 Aurora 비용을 비교하여 사용할 수 있다.  하지만, 프로젝트에서 사용할 수 있는 예산 문제로, Aurora 사용이 어려울 것 같아 RDS로 사용하게 되었다.

Issue #3

DynamoDB 활용 - 이벤트 로그 저장소 DB는 작업 변경 로그 메시지를 저장하는 것이 목적이기 때문에 매번 상황에 따라 형식과 내용이 바뀐다. 따라서 로그 메시지를 유동적으로 저장하기 위해 속성의 변경과 추가가 자유로운 DynamoDB를 사용하는 것이 어떨까? DynamoDB는 데이터가 key-value 형태로 저장되기 때문에 read 속도도 빨라 접속이 많이 발생해도 견딜 수 있다.

• DynamoDB는 성능과 편의성에서도 용이하고, 구현할 아키텍처는 적은 양의 로그 데이터를 처리하기 때문에 처리 속도가 빠른 DynamoDB가 효과적이다. 또한 DynamoDB는 AWS Lambda와 같은 이벤트 기반 처리 시스템과 잘 통합되어 실시간 로그 분석과 같은 복잡한 로그 처리 작업 또한 쉽게 구현할 수 있게 해준다.

Issue #4

SNS + SQS vs Eventbridge - 기존에 사용해보아서 익숙한 SNS를 사용할지, 새로 접하지만 필터링 기능이 있어 이벤트 관리가 용이한 Eventbrige를 사용할지에 대한 논의

• 필터링 기능을 이용해 편리하게 로그를 원하는 방식으로 필터링하고 로그의 형식에 따라 원하는 이벤트를 발생시킬 수 있는 Eventbridge를 사용하기로 결정했다.
• WAS => Dynamo => Lambda => Eventbridge => Rule => SES : 작업 CRUD에 대한 로그를 전부 Dynamo에 쌓을 예정이기 때문에 이 플로우 사용하기로 결정했다.
• 참고자료 : https://aws.amazon.com/ko/blogs/compute/choosing-between-messaging-services-for-serverless-applications/

Issue #5

ASG (EC2) vs Fargate - Fargate도 서버리스로 구동이 되고, 리소스 사용률이 높을수록 비용 방면에서 효율이 좋지만, ASG를 이용할 시, 인프라 관리가 어렵고 운영이 복잡할 수 있다.

• ECS의 컨테이너를 구동할 때 사용하는 컴퓨팅 유닛으로 EC2를 사용하는 것이 리소스 사용률이 낮을 경우에는 Fargate가 EC2보다 평균적으로 비용이 13~18% 정도 비싸고, Cloudwatch를 통해서 리소스 예약률을 90% 이상 높게 유지하도록 auto scaling을 하도록 만들면 더 비용 절감을 할 수 있다. 따라서 EC2를 이용하기로 결정했다.
• 참고자료 : https://youtu.be/-3YgdBpCN60

• 리소스를 구현하고 아키텍처 컨셉이 끝난 뒤에 Fargate가 초소형 테스팅 환경에서는 EC2보다 더 우월하다는 내용을 담은 AWS공식 문서를 발견했다.... 이것을 보면 Fargate로 아키텍처를 정했어도 괜찮았을 것 같다....
• https://containersonaws.com/introduction/ec2-or-aws-fargate/

리소스 아키텍처 설계를 진행하며..

 요구사항을 충족하기 위해서 요구사항의 기능을 만족시키기 위해 어떤 리소스를 사용하는 것이 좋을지 팀원들과 많은 토의를 했다.

 물론 기존에 알고있던 지식만으로 어떤 리소스를 사용할지 결정한다는 것은 너무나 오만한 발상이기 때문에, 한 리소스를 사용하기로 정하더라도 사용하는 확실한 근거를 만들기 위해서 자료를 조사하고 팀원들과 토의하는 과정을 거치려고 노력했다.

 그 결과 스스로도 리소스들이 그냥 해당기능을 구현할 수 있기 때문에 사용하는 것이 아니라, "이러이러한 특성이 있기 때문에 어떠한 장점이 있어서 해당 기능을 구현할 때 이 리소스를 사용했다" 라고 어느정도는 말할 수 있게 되었다고 생각해 뿌듯했다.