[Spring] MSA 기반 SNS 서비스 with AWS EKS [설계 / AWS 설정]

'가상 면접 사례로 배우는 대규모 시스템 설계 기초' 책을 읽고 직접 구현하는 SNS 서비스 프로젝트, 이를 진행하며 남기는 기록.

 

🟢 MSA 기반 SNS 서비스 with AWS EKS

가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 읽으며 11장, 뉴스 피드 시스템 설계를 재미있게 읽었다. 이를 직접 구현해 보고 싶다는 욕심이 생겨 MZ 세대에 맞는 SNS 서비스를 구현해 보기로 한다.

 

📃 요구사항

 

Grouping 했을 때 크게 5개의 도메인, 서비스가 필요하다. 

Timeline Server
User Server
Feed Server
Image Server
Notification Server

 

내가 생각하는 주요 설계사항은 아래와 같다.

 

1. 유저의 개념은 팔로워(본인이 팔로우하고 있는 사람)와 팔로잉(본인을 팔로우하고 있는 사람)이 존재한다. 이에 대한 로그인 기능이 필요하며 유저들관의 관계를 기반으로 피드를 조회할 수 있어야 한다.

2. 팔로워들의 피드를 조회하는 기능을 구현할 때 성능에 주의해야 할 필요성을 느껴 Timeline Server 와 Feed Server 를 분리하였고, 이를 MySQL 을 default 로 사용하지만 Redis 와 Kafka 를 통해 성능 개선을 할 계획이다.(피드 생성을 통한 타임라인 정보 캐싱 등)

3. 팔로우를 할 때와 같은 알림 기능은 Spring Batch 를 통해서 구현할 예정이며, 이를 Notificaiton Server 에서 별도로 처리할 것이다.

 

이러한 모든 서비스를 Kubernetes 를 통해 구현할 것이다. Kubernetes 내부에 설치하는 자원과 외부 자원을 분리할 것이며, MySQL(AWS RDS)과 SMTP 서버는 클러스터 외부에 위치, Redis & Kafka 는 내부에 위치하도록 설계했다. 전체적인 설계에 들어가기 전에 Kubernetes(k8s), AWS EKS 와 같은 새롭게 도입하고 학습한 기술에 대해 정리하며 글을 이어 나가 보겠다.

 

⭐️ 쿠버네티스(Kubernetes, k8s)

 

쿠버네티스는 컨테이너화된 애플리케이션의 배포, 관리 및 확장을 예약하고 자동화하기 위한 컨테이너 오케스트레이션 플랫폼이다.

여기서 컨테이너는 앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술이다.

용어	뜻
컨테이너	앱이 구동되는 환경까지 감싸서 실행할 수 있도록 하는 격리 기술
컨테이너 런타임	컨테이너를 다루는 도구
도커	컨테이너를 다루는 도구 중 가장 널리 사용되는 것
쿠버네티스	컨테이너 런타임을 통해 컨테이너를 오케스트레이션 하는 도구
오케스트레이션	여러 서버에 걸친 컨테이너 및 사용하는 환경 설정을 관리하는 행위

 

쿠버네티스와 도커에 대해 헷갈리는 점들, 쿠버네티스의 용어들에 대해 간단히 정리해 보았다. 컨테이너에 대해 쉽게 정리하자면 우리가 구동하려는 애플리케이션을 실행할 수 있는 환경까지 감싸서, 어디서든 쉽게 실행할 수 있도록 해주는 기술이다.

 

이러한 컨테이너를 사용할 때 필요한 도구가 컨테이너 런타임이다. 컨테이너를 쉽게 내려받거나 공유하고 구동할 수 있도록 해주는 도구의 의미이다. 그 중 가장 유명한 것이 도커다. 물론 도커가 사용하는 컨테이너 규격은 표준화되어 있기 때문에 도커가 아닌 다른 컨테이너 런타임들도 도커로 만든 컨테이너를 사용할 수 있다.

 

쿠버네티스는 컨테이너 런타임을 통해 컨테이너를 다루는 도구를 의미한다. 쿠버네티스가 해주는 일은 여러 서버(노드)에 컨테이너를 분산해서 배치하거나, 문제가 생긴 컨테이너를 교체, 컨테이너가 사용할 패스워드나 환경 설정을 관리하고 주입해 주는 일 등을 한다. 이것을 컨테이너 오케스트레이션이라고 한다.

 

⭐️ AWS EKS

 

AWS EKS 는 Amazon Web Services(AWS) 에서 제공하는 완전관리형 컨테이너 오케스트레이션 서비스다. EKS 는 Kubernetes, 즉 쿠버네티스를 기반으로 하며, 사용자는 인프라 관리를 AWS 에 맡기고, 애플리케이션 배포에 집중할 수 있다.

 

💡 AWS EKS 의 주요 장점

완전 관리형 서비스

EKS 는 완전관리형 서비스로서, 쿠버네티스 클러스터를 설정, 운영, 유지 관리하는 복잡한 작업을 AWS 가 대신 수행한다. 이를 통해 개발자는 인프라 걱정없이 애플리케이션에 집중할 수 있다.

 

확장성

EKS 는 AWS 의 다양한 서비스와 연동이 가능하다. 이를 통해 사용자는 애플리케이션의 확장성을 쉽게 관리할 수 있다.

 

💡 AWS EKS 를 사용한 이유

사실 여러 프로젝트를 진행했지만 AWS 를 많이 사용해 보지 않아서 제대로 사용해보고 기술적 성장을 이뤄내고 싶은 것이 제일 큰 이유였다. 그 외에도 많은 트래픽에 대응하기 위한 로드밸런싱과 오토스케일링을 지원할 뿐만 아니라 애플리케이션 배포를 단순화 할 수 있는 쿠버네티스를 사용하기 위해 결정했다.

 

▪️ AWS 와 EKS 를 이용한 쿠버네티스 클러스터 설정

기본적인 개념을 다졌으니 이제 AWS 와 EKS 를 사용하여 쿠버네티스 클러스터 설정을 진행해 보자! CLI 를 사용한 설정 방법도 있으나 눈으로 하나씩 확인하며 진행해야 추후에 해당 개념들을 잘 적용할 수 있을 것이라고 판단!  진행하며 어렵거나 이해가 필요한 부분은 설명하며 진행한다.

 

🔻IAM 계정 생성

IAM(Identity And Management) 계정을 생성하는 이유는 보완과 관리 측면에서 큰 이점이 있기 때문에 생성했다. 

 

 

먼저 루트 계정에 접속해서 IAM 계정을 생성해준다. 콘솔 작업을 진행하기 위해 'AWS Management Console 에 대한 사용자 액세스 권한 제공' 체크박스를 체크해준다.

 

🔻 EKS Cluster Role

 

생성이 완료된 'infra-admin' 계정의 콘솔에 접근하여 Role 을 추가해줘야 한다! IAM > Role > Create Role 을 진행하고 Entity Type 은 AWS Service, Use case 는 EKS-Cluster 를 선택해준다. Policy 에는 자동으로 AmazonEKSClusterPolicy 가 지정된다. 이번 프로젝트에서만 진행할 사항이기에 eks-cluster-role 이라는 이름으로 지정했다.

 

🔻 EKS Node Role

 

추가로 Node 에 대한 역할도 지정해 주어야 한다. 내부에 쓰일 Node, 실제로는 EC2 를 의미하는 가상머신의 형태이다. 위와 동일하게 Entity Type 을 지정하고 Use case에만 EC2 를 선택하면 된다. 여기서 중요한 건 정책이다!

 

AmazonEC2ContainerRegistryReadOnly 에서 ContainerRegistry 는 도커 허브처럼 내가 만든 애플리케이션의 이미지가 올라오고 저장되는 장소인데, 노드들이 실제로 Pod가 실행될 때 이미지를 끌어와야 하기 때문에 ReadOnly 권한을 주었다.

AmazonEKSWorkerNodePolicy 에서 Node, WorkerNode에서 실행되는 애플리케이션이 AWS 리소스와 상호작용할 수 있도록 필요한 권한을 제공하는 정책이다.

AmazonEKS_CNI_Policy 는 EKS 클러스터에서 사용하는 CNI(Container Network Interface) 플러그인에 필요한 권한을 제공한다. EKS 는 기본적으로 AWS VPC CNI 플러그인을 사용하여 Pod 네트워킹을 관리한다. 

 

🔻AWS Cli 설정

 

 

위와 같은 과정을 통해 Access Key 를 발급받는다. 여기서 받는 Key 는 다시 조회가 안되기 때문에 따로 저장해 두는 것을 권장한다. 

 

Mac OS에 AWS Cli 설정하기

 

나는 Mac 환경에서 진행하기 때문에 위의 블로그를 참조해서 진행했다. 

 

$ aws configure
AWS Access Key ID [None]: "ACCESS_KEY"
AWS Secret Access Key [None]: "SECRET_ACCESS_KEY"
Default region name [None]: ap-northeast-2
Default output format [None]:

 

발급받은 KEY 를 차례대로 넣어주고 region name 도 자신의 환경에 맞게 설정해주면 된다. 

 

🔻 EKS Cluster 생성

 

EKS > 클러스터 > 생성한 클러스터 > 노드 그룹 > 노드 그룹 추가 를 선택한다. 실제로 Pod 들을 띄워주고 Workload 들을 실행시켜줄 컴퓨팅 자원을 추가해주는 과정이다. 노드 IAM 역할에는 위에서 생성한 EKS Node Role 을 선택해주면 된다. 

 

 

많은 자원을 필요로 하지 않는 개인 프로젝트이기에 기본인 t3.medium 을 선택해줬다. 

 

 

노드에도 스케일링이 가능하다. 위와 같은 이유로 기본 값을 줬지만 추후에 여러가지 테스트를 통해 적절한 자원의 사용양인지 판단하고 이를 조정하는 과정을 거칠 것이다! 네트워크 설정은 사용했던 Subnet 을 지정해줬다.

 

여기까지 클러스터와 노드들을 생성하는 과정이었다! 이제 여기까지 만든 클러스터에 kubectl 을 통해서 접속하는 설정을 진행할 것인데 이는 간단하게 터미널을 통해서 진행한다. 여기서 kubectl 이란 쿠버네티스 클러스터를 관리하기 위한 CLI 이다. 

 

$ aws eks update-kubeconfig --region [region-name] --name [cluster-name]

 

이 명령어를 통해 kubectl 명령어가 바라보고 있는 클러스터를 해당 클러스터로 변경할 수 있다. 이 명령어는 클러스터가 지워지는 것이 아니라 컨텍스트가 변경되는 것이다. 

 

▪️ AWS EFS 를 이용한 StorageClass 정의

쿠버네티스 클러스터에서 스토리지를 사용하는 방법은 여러가지이며, 특히 이렇게 클라우드 환경에서 쿠버네티스 클러스터를 만들어서 사용하는 경우에는 클라우드 환경 자체에서 제공해주는 스토리지 서비스가 여러개가 있기 때문에 해당 서비스들을 플러그인 형태로 클러스터에 추가해주고, 해당 스토리지 서비스를 사용하는 스토리지 클래스를 만들어서 프로비저닝해서 사용하는 방법들을 사용하곤 한다. 나는 Pod 에서 이미지를 저장하기 위해 스토리지를 사용할 예정이다. 해당 Pod가 어떤 노드에서 뜰지 모르고 추후에 배포될 때마다 노드를 옮겨다닐 수 있기 때문에 EBS 보다는 EFS 선호하게 되었으며, EFS 는 가용영역과 상관없이 attach 될 수 있는 스토리지 서비스기 때문에 더 적합하다고 판단했다.

 

🔻 IAM 권한 추가

클러스터에 대한 인증 절차를 추가해주는 작업을 먼저 해주어야 한다. IAM > Access Management > Identity providers 를 선택한다. 한국어로 번역하면 자격 증명 공급자라고 하는데 여기서 공급자 추가를 선택! OpenID Connect 를 선택한 후, 방금 만든 클러스터의 OpenID Connect 공급자 URL 을 공급자 URL 에 입력해 주면 된다. 그리고 Audience(대상)에는 sts.amazonaws.com 을 입력!

 

이제 Role 을 추가해준다. 웹 자격 증명을 선택하고 위에서 만든 자격 증명 공급자와 Audience 을 그대로 선택! AmazonEFSCSIDriverPolicy 를 선택해서 EFS 에 대한 권한 부여하고 생성까지 완료해준다. 여기서 추가로 해줘야 할 작업들이 있다.

 

생성한 Role 에 들어가서 신뢰 정책 편집을 선택해 준다. 이 작업은 쿠버네티스 서비스 어카운트에 접근할 수 있는 설정을 하는 과정이다.

 

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Effect": "Allow",
			"Principal": {
				"Federated": "arn:aws:iam::905418310587:oidc-provider/oidc.eks.ap-northeast-2.amazonaws.com/id/00000000"
			},
			"Action": "sts:AssumeRoleWithWebIdentity",
			"Condition": {
				"StringLike": {
					"oidc.eks.ap-northeast-2.amazonaws.com/id/00000000:aud": "sts.amazonaws.com",
					"oidc.eks.ap-northeast-2.amazonaws.com/id/00000000:sub": "system:serviceaccount:kube-system:efs-csi-*"
				}
			}
		}
	]
}

 

Conditiond에서 "oidc.eks.ap-northeast-2.amazonaws.com/id/OOOOOOOO:aud": "sts.amazonaws.com"로 시작하는 한 줄 복사해서 붙여넣은 다음에 "oidc.eks.ap-northeast-2.amazonaws.com/id/OOOOOOOO:sub": "system:serviceaccount:kube-system:efs-csi-*"와 같은 형태로 변경한다. Condition의 StringEquals를 StringLike으로 변경 후 저장!

 

🔻 방화벽 설정

이제는 쿠버네티스 클러스터와 EFS 스토리지 서비스 네트워크에 통신을 위해 방화벽 설정을 해주어야 한다!

 

보안 그룹에 접속하여 Inbound rules 에 규칙을 추가해준다. NFS 포트인 2049 를 열어주고 쿠버네티스 클러스터 default 소스를 지정해준다. 

 

🔻 CSI 플러그인 설치

다시 생성한 클러스터로 돌아가 Add-ons(추가기능) 을 선택하고 Get more add-ons(추가 기능 가져오기) 를 선택한 후, Amazon EFS CSI Driver 를 선택하여 설치하는데 위에서 AmazonEFSCSIDriverPolicy 에 대한 Role 을 지정하여 설치하면 된다.

 

이제 EFS 를 생성해준다. 크게 복잡할 것이 없이 EKS 를 생성할 때 사용한 vpc 를 선택하기만 하면 바로 생성이 된다. 이제 AWS 에서 해줄 작업은 모두 끝났다! 이제 클러스터에서 EFS 를 이용해서 프로비저닝 할 때, 해당 파일 시스템을 통해서 프로비저닝이 될 수 있게 내부에 디렉토리를 만들고 파일들을 저장할 수 있게 스토리지 클래스를 생성해 주어야 한다. 해당 작업을 진행하기 앞서, 프로비저닝과 관련된 개념들에 대해 정리하고 넘어가자!

 

✅ 프로비저닝이란 ?
쿠버네티스에서 프로비저닝은 일반적으로 저장소와 관련하여 특정 애플리케이션이나 서비스의 요구 사항을 충족시키기 위해 필요한 저장소 자원을 할당하고 구성하는 과정을 의미한다. 쿠버네티스에선 두 가지 유형의 프로비저닝이 있다.

정적 프로비저닝(Static Provisioning) 정적 프로비저닝에서는 클러스터 관리자가 수동으로 Persistent Volume(PV)을 생성하며, 해당 PV의 용량, 액세스 모드 및 저장소 유형과 같은 하위 저장소의 세부 정보를 지정한다. 이러한 PV는 사용자가 생성하는 Persistent Volume Claim(PVC)에서 요청될 수 있다. 사용자가 PVC를 생성하면 쿠버네티스는 해당 PVC의 요구 사항과 일치하는 사용 가능한 PV에 바인딩한다.

동적 프로비저닝(Dynamic Provisioning) 동적 프로비저닝에서는 PVC 요청에 대한 PV를 자동으로 생성하는 과정을 자동화한다. 클러스터 관리자는 PV 생성을 위한 템플릿인 StorageClass를 정의한다. 각 StorageClass는 PV를 생성하는 책임이 있는 프로비저너(Provisioner)를 지정한다. 사용자가 특정 StorageClass를 참조하는 PVC를 생성하면 프로비저너는 PVC의 요구 사항과 일치하는 PV를 자동으로 생성하여 클러스터 관리자의 수동 개입을 없애준다.

✅ Pod
Pod는 쿠버네티스에서 가장 작은 배포 단위로, 애플리케이션의 컨테이너들을 그룹화하는 논리적인 단위이다. 

✅ PV(Persistent Volume)
PV 는 쿠버네티스 클러스터에서 사용할 수 있는 실제 스토리지 자원을 나타낸다. 이는 클러스터 관리자가 클러스터에 설정한 스토리지로, NFS, AWS EBS, GCE Persistent Disk 등 다양한 스토리지 백엔드를 지원한다. PV 는 클러스터 리소스 중 하나로 간주되며, 특정 Pod 에 할당되기 위해 준비된다. 한번 생성되면 여러 파드에 걸쳐서 지속적으로 데이터를 저장할 수 있는 저장소를 제공한다.

✅ PVC(Persistent Volume Claim)
PVC 는 사용자(애플리케이션) 가 특정 크기와 접근 모드를 가진 스토리지를 요청할 때 사용하는 리소스다. 사용자가 직접 PV 를 생성하거나 관리하지 않고, 필요한 스토리지를 선언하는 방법이다. PVC 가 생성되면 쿠버넽티스는 PVC 와 일치하는 PV 를 찾아서 바인딩한다. 이로 인해 Pod 는 PVC 를 통해 스토리지에 접근할 수 있다. PVC 와 PV 는 일대일로 연결되며, PVC 가 삭제되면 PV 도 함께 반환되거나 삭제될 수 있다.

PV 와 PVC 의 간단한 흐름을 정리하면 아래와 같다.
1. 관리자가 클러스터에 PV 를 설정한다.
2. 사용자는 애플리케이션 배포 시 필요한 스토리지를 요청하기 위해 PVC 를 생성한다.
3. 쿠버네티스는 PVC 와 일치하는 PV 를 찾아서 연결(바인딩)한다.
4. 애플리케이션(Pod) 은 PVC 를 통해 PV 에 접근하여 데이터를 읽거나 쓸 수 있다.

 

스토리지 클래스 작성, efs-sc.yml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name : efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-000000000000
  directoryPerms: "700"

 

 

 

작성한 스토리지 클래스 리소스다. storageClass 는 쿠버네티스에서 스토리지 리소스를 동적으로 프로비저닝 하기 위한 리소스 유형이다. 스토리지 클래스를 사용하여 애플리케이션의 요구 사항에 따라 적절한 스토리지 리소스를 자동으로 생성할 수 있다.

 

provisioner 는 스토리지 프로비저닝을 담당하는 플러그인의 이름을 지정한다. efs.csi.aws.com 은 AWS EFS 를 위한 CSI(Container Storage Interface) 드라이버를 지정해준다!

 

provisioningMode 은 EFS 파일 시스템의 프로비저닝 모드를 지정한다. 여기서 efs-ap 는 "EFS Access Point" 를 사용하여 프로비저닝할 것을 나타낸다. EFS Access Point 는 EFS 파일 시스템에 대한 특정 경로와 권한을 지정할 수 있는 기능이다. EFS 를 사용하기 때문에 이 값은 사실상 고정이다.

 

fileSystemId 는 EFS 의 파일 시스템 ID 를 기재해주면 된다. 

 

directoryPerms 700은 소유자에게만 읽기,쓰기,실행 권한을 부여하고, 그룹과 다른 사용자에게는 권한을 부여하지 않는다. 이 설정은 EFS Access Point 를 통해 프로비저닝된 디렉토리에 적용된다.

 

$ kubectl apply -f efs-sc.yml

 

 

 

스토리지 클래스를 모두 작성했으면 위의 명령어로 적용하기만 하면 된다. 

$ kubectl get sc
NAME     PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc   efs.csi.aws.com         Delete          Immediate              false                  XXd

 

kubectl get sc 명령어를 통해 스토리지 클래스가 정상적으로 생성됨을 확인할 수 있다 !

 

▪️ ECR 구성 및 MySQL / Redis / Kafka 설치

MySQL(RDS)

이제 추가적인 인프라 설정만 해주면 된다 ! MySQL은 클러스터 외부에 RDS 로 배치하고 Redis 와 Kafka 는 클러스터 내부에 Pod 형태로 띄워서 진행할 것이다. RDS 에 대한 생성은 많은 자료가 있기에 따로 이 글에 첨부하진 않는다! 주의할 사항은 EKS 클러스터와 데이터베이스를 연결하기 위해 Security Group > Inbound rules 에서 3306 포트와 EKS 의 Security Group 을 선택해 연결해 주어야 한다는 점이다.

 

Redis & Kafka

하나하나 구성해서 설치하는 방법도 있지만 그렇게 구성하는 것은 복잡하고 시간이 많이 걸리는 것으로 알고 있다. 그렇기에 이번 프로젝트에서는 helm 을 통해서 패키지 형태로 설치해 볼 것이다! 설치 과정에 대한 설명들은 모두 주석으로 대체한다!

 

Namespace 생성

// 리소스를 그룹화하기 위해 네임스페이스를 생성
$ kubectl create namespace infra
namespace/infra created

 

 

Redis 설치 with helm

helm -n infra install redis oci://registry-1.docker.io/bitnamicharts/redis \
--set architecture=standalone \
--set auth.enabled=false \
--set master.persistence.enabled=false

helm -n infra install redis:
	install redis: redis라는 이름으로 Helm 차트를 설치한다. 이 이름은 설치된 릴리스의 이름으로 사용된다.
oci://registry-1.docker.io/bitnamicharts/redis:
	Redis의 Helm 차트가 저장된 OCI(OCI-compliant) 레지스트리 URL이다. 
	여기서는 Docker Hub에 저장된 Bitnami의 Redis 차트를 사용한다.
--set architecture=standalone:
	이 옵션은 Redis 설치를 단일 인스턴스(standalone) 모드로 설정한다. 
	Redis는 기본적으로 복제(replication) 또는 클러스터 모드에서 실행될 수 있는데, 
	이 설정은 복제나 클러스터가 아닌 단일 인스턴스만 실행되도록 한다.
--set auth.enabled=false:
	Redis의 인증 기능을 비활성화한다. 기본적으로 Redis는 비밀번호 인증을 사용하여 보안을 강화할 수 있지만, 
	이 옵션을 false로 설정하면 인증이 비활성화된다.
--set master.persistence.enabled=false:
	Redis 마스터의 영구 스토리지(Persistence)를 비활성화한다. 
	이 설정을 false로 설정하면 Redis 마스터 인스턴스가 데이터를 디스크에 저장하지 않으며, 
	재시작 시 데이터가 유지되지 않는다.

 

 

 

Kafka 설치 with helm

helm -n infra install kafka oci://registry-1.docker.io/bitnamicharts/kafka \
--set controller.replicaCount=3 \
--set sasl.client.passwords=[password] \
--set controller.persistence.enabled=false \
--set broker.persistence.enabled=false

helm -n infra install kafka:
	install kafka: kafka라는 이름으로 Helm 차트를 설치한다. 이 이름은 설치된 릴리스의 이름으로 사용된다.
oci://registry-1.docker.io/bitnamicharts/kafka:
	Apache Kafka의 Helm 차트가 저장된 OCI(OCI-compliant) 레지스트리 URL다. 
	여기서는 Docker Hub에 저장된 Bitnami의 Kafka 차트를 사용한다.
--set controller.replicaCount=3:
	Kafka 컨트롤러의 복제본 수를 3개로 설정한다. 
	이 설정은 고가용성(High Availability)을 위해 컨트롤러의 여러 복제본을 실행할 수 있도록 한다.
--set sasl.client.passwords=[password]:
	SASL(Simple Authentication and Security Layer) 인증에 사용할 클라이언트 패스워드를 설정한다. 
	이 패스워드는 Kafka 클라이언트가 Kafka 브로커에 접근할 때 인증에 사용된다.
--set controller.persistence.enabled=false:
	Kafka 컨트롤러의 영구 스토리지(Persistence)를 비활성화한다. 
	이 설정은 Kafka 컨트롤러의 데이터를 디스크에 저장하지 않도록 하며, 재시작 시 데이터가 유지되지 않는다. 
--set broker.persistence.enabled=false:
	Kafka 브로커의 영구 스토리지(Persistence)를 비활성화한다. 
	이 설정도 마찬가지로, Kafka 브로커의 데이터를 디스크에 저장하지 않도록 하며, 
	재시작 시 데이터가 유지되지 않는다.

 

infra 네임스페이스에 생성된 파드 조회

$ kubectl -n infra get pods
NAME                 READY   STATUS    RESTARTS   AGE
kafka-controller-0   1/1     Running   0          28s
kafka-controller-1   1/1     Running   0          28s
kafka-controller-2   1/1     Running   0          28s
redis-master-0       1/1     Running   0          4m56s

 

이렇게 해서 Redis 와 Kafka 설치까지 마쳤다. 이 두개는 서비스의 형태로 접근이 가능한데 클라우드 외부에 설치한 RDS 는 엔드포인트로 자바에서 바로 접근이 가능하지만, 실제로 엔드포인트가 바뀐다거나 구성이 바뀌는 경우를 대비하여 별도의 External Name Service 를 생성해서 접근하는 것이 더 좋은 방안이라고 생각했다. 이에 대한 설정이 담긴 yml 파일을 작성한다. 

 

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: infra
spec:
  type: ExternalName
  externalName: [RDS EndPoint]

 

type 은 ExternalName 을 기재하고 externalName 에는 RDS 의 실제 엔드포인트를 기재한다.  위와 동일하게 apply 를 통해 적용하면 

 

$ kubectl -n infra get services
NAME                        TYPE       		
kafka                       ClusterIP      		
kafka-controller-headless   ClusterIP          
mysql                       ExternalName     
redis-headless              ClusterIP           
redis-master                ClusterIP

 

이렇게 mysql 서비스도 ExternalName 형태로 활성화된 것을 확인할 수 있다. 

 

Amazon ECR(Elastic Container Registry)

이제 애플리케이션 개발하면서 사용할 MySQL, Redis, Kafka 설치는 모두 완료했고, 마지막으로 애플리케이션을 개발하며 생성한 이미지들을 푸시하고 EKS 클러스터에서 해당 이미지들을 받아올 이미지 저장소를 만들어 주어야 한다. 이미지 저장소는 AWS 에서 제공하는 ECR 을 사용하여 구성해 보자. 도커 허브를 사용해도 되지만 EKS 에서 쉽게 가져다 쓸 수 있다는 이점이 있기에 사용하기로 결정했다! 

 

 

ECR > Private registry > Repositories 에 접속해서 Create repository(레포지토리) 를 선택. MSA 의 구조로 서비스를 개발할 것이기 때문에 각 도메인 별로 이미지를 구성할 것이다. 그렇기에 총 6개의 레포지토리를 생성해 주었다.

 

이렇게 프로젝트의 기본적인 세팅이 모두 끝났다! 기본적인 세팅이지만 AWS 를 깊게 다뤄보지 않은 나에게는 너무나도 험난한 길이었다. 험난했던 것 만큼이나 보람찬 프로젝트이기에 이 모든 과정을 작성하고 공유할 예정이다.. 다음 내용도 늦지 않게 공유할 수 있기를  ⭐️