SpringBoot & React AWS 배포 테스트 3) EC2 Instance 생성 후 설정

NYoun 2024. 8. 2. 19:45

2024. 8. 2. 19:45

정리 목적

이번에 AWS에 배포 테스트를 하며 UI가 변경된 부분도 좀 있었고 이전에는 도메인 구매 후 접근 테스트만 해본 반면 이번에는 여러 환경을 설정하고 처리했기 때문에 이전 정리 내용을 지우고 새로 다시 정리.

처리 환경 정리

Project

BackEnd - Spring Boot 3
FrontEnd - React
빌드 방식 - 통합빌드

AWS

EC2 t2.micro
- ubuntu 22.0.4
Application Load Balancer
AWS Certificate Manager(ACM)
Route53
S3
RDS(MySQL)
ElastiCache(Redis)

CI / CD

Jenkins
Git Webhook

WebServer

Nginx

Domain Register

Gabia

정리 순서

S3 Bucket 생성 후 Local에서 테스트
RDS MySQL Database Instance 생성 후 Local Workbench와 연결 테스트 및 프로젝트 연결 테스트
EC2 Instance 생성 후 설정
1. swap 메모리 설정
2. JDK 17 설치
3. nvm 설치 및 node 21.7.1 설치
4. Nginx 설치 및 설정
5. Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리
6. ElasiCache Redis OSS Cache 생성 및 Redis 설치
Gabia 도메인 구매 후 Route53, ACM 처리
Load Balancer 대상 그룹 생성 및 ALB 생성 후 대상 그룹 설정
A레코드 생성 및 도메인 접근 테스트
git clone을 통해 사전 테스트 이후 Jenkins Job 설정과 Build 테스트
Git Webhook 연동 및 테스트

EC2 Instance 생성

AWS에서 EC2 페이지에 접근한다.

인스턴스 탭으로 이동하면 오른쪽 상단에 인스턴스 시작 버튼이 존재하니 클릭!

아래와 같은 페이지가 출력된다.

이름은 EC2 Instance 이름이다.

애플리케이션 및 OS 이미지는 ubuntu 22.04를 사용했기 때문에 Ubuntu를 선택하고 22.04를 선택했다.

아마 ubuntu 선택하고 나면 24년 7월 기준 24.04 가 기본 설정일텐데 22.04로 바꾸게 되면 하단의 이미지처럼 안내창이 뜰 것이다.

그냥 설정 중에 일부가 변경될 것이라는 안내이기 때문에 변경 확인 눌러주면 된다.

인스턴스 유형은 프로젝트가 크지 않기 때문에 t2.micro를 선택한다.

프리티어 계정이라면 micro를 사용해야 요금이 발생하지 않는다.

만료되었더라도 nano는 너무 작고 Micro가 그래도 싸니까 선택!

다음은 키페어를 생성한다.

이미 키페어가 존재한다면 해당 키페어를 선택할 수 있을 것이고 없다면 새 키페어 생성을 눌러 생성해준다.

새 키 페어 생성을 누르면 아래와 같은 창이 뜬다.

키페어의 이름을 입력하고 유형은 RSA 그대로 유지.

파일형식은 .pem으로 선택한다. ppk는 예전에 못봤는데 window 환경이라면 Putty를 통해 접근할 때는 ppk를 사용해야 될지는 알아봐야함..... 전에는 윈도우에서 Putty로 접근해도 pem 쓰긴했는데..

mac 환경이라 .pem으로 선택!

키페어 생성을 해준다.

생성하고 나면 키페어 탭에서 생성한 키페어가 들어가있을 것이기 때문에 선택해준다.

다음은 네트워크 설정이다.

방화벽(보안그룹)에서는 기존 보안그룹을 선택하고 RDS 생성 전 만들어두었던 보안그룹을 선택해준다.

스토리지 구성은 무조건 최대치 30!!

기본 설정인 8GB로 했다가 한참 모자라서 다시 생성했슴다..

딱 EC2 생성해서 git에서 프로젝트 clone 받고 서버 실행만 할거라면 8GB도 괜찮을지 모르겠지만 이것저것 설치하고 뭐하고 하면 한참 모자라기도 해서 30이 좋다.

그럼 이제 오른쪽의 인스턴스 시작 버튼을 누르면 인스턴스 생성이 시작된다.

완전히 완료되기까지는 시간이 쪼금 걸리니 기다려줬다가 상태가 실행중으로 변경되고 상태 검사에 검사 통과가 뜬다면 모두 마무리 된 것이므로 정상적으로 생성되어 실행되고 있다고 볼 수 있다.

탄력적 IP 생성 및 EC2 Instance에 연결

그럼 이제 다음으로 탄력적 IP를 생성하고 연결해준다.

생성 전에 유의사항으로 탄력적 IP는 인스턴스에 연결하지 않는 경우 요금이 발생하므로 바로바로 연결해주도록 해야하고 인스턴스를 삭제한다면 탄력적 IP도 바로바로 삭제하는게 좋다.

왼쪽 탭에서 네트워크 및 보안 -> 탄력적 IP로 이동한 뒤 오른쪽 상단의 탄력적 IP 주소 할당 클릭!

따로 설정하거나 작성해야 하는 부분은 없기 때문에 캡쳐는 따로 하지 않았다.

태그 작성이 있긴한데 선택사항이므로 태그가 필요하다면 작성 후 할당 버튼을 클릭해 생성해주면 된다.

리스트에 탄력적 IP가 추가된 것을 볼 수 있을 것이고, 해당 IP에서 마우스 오른쪽 버튼을 클릭해 탄력적 IP 주소 연결을 선택한다.

그럼 아래 이미지와 같은 창으로 이동하게 될건데 인스턴스 선택을 누르면 생성한 인스턴스가 나올 것이다.

해당 인스턴스를 선택해주고 프라이빗 IP 주소를 누르면 알아서 선택한 EC2 인스턴스의 프라이빗 IP가 나오니 선택해준다.

그리고 연결 버튼 클릭!

EC2에 접속

접속 환경은 mac 기준입니다.

window는 putty를 통한 접근이 가능할텐데 예전에 정리해둔게 있긴 하지만 바뀌었을 수도 있긴 합니다.

이전에 정리해둔 내용은 아래 링크에서 확인.

https://myyoun.tistory.com/156

mac에서는 터미널을 열고 아래 명령어를 통해 EC2에 접속할 수 있다.

ssh -i .pem파일 경로/000.pem ubuntu@EC2 public IP주소

EC2 public IP 주소는 EC2에서 해당 인스턴스를 선택해보면 하단에 나오는 정보를 통해 확인할 수 있다.

위 링크에도 정리해뒀는데 ubuntu가 아닌 다른 환경은 ubuntu 대신 다른 명령어가 들어간다.

배포를 위한 EC2 기본 설정 및 설치

처리할 내용들은 아래와 같다.

swap 메모리 설정
JDK 17 설치
nvm 설치 및 node 21.7.1 설치
Nginx 설치 및 설정
Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리
ElastiCache Redis OSS 캐시 생성 및 Redis 설치

1. swap 메모리 설정

swap이 뭔지 먼저 이해해야 한다.

swap이란 Linux 기반 운영체제에서 가상 메모리로 작동하는 저장장치의 전용 공간이다.

시스템의 사용 가능한 메모리가 부족할 때 물리적 RAM을 보충하는데 사용된다.

swap 공간을 통해 운영체제는 자주 사용되지 않는 데이터를 RAM에서 swap 영역으로 이동시켜 더 중요하거나 자주 사용되는 데이터를 위해 RAM 공간을 확보할 수 있다.

swap 공간은 linux 커널 메모리 관리 하위 시스템에서 제어하는 디스크 영역이다.

커널은 메모리에 비활성 페이지를 보관하여 시스템 RAM을 보완하기 위해 swap 공간을 사용한다.

시스템의 가상 메모리에는 결합된 시스템 RAM과 swap 공간이 포함된다.

swap 영역이 디스크에 상주하기 때문에 swap은 RAM에 비해 속도가 느리다.

swap 공간은 시스템 RAM을 늘리는데 사용되지만 Work Load에 비해 RAM이 부족한 경우 swap 공간을 지속 가능한 해결책으로 간주해서는 안되며, 물리적 메모리를 늘리는 것이 좋다.

참고

https://easyitwanner.tistory.com/149

[Linux 명령어] swap이란? (+ swap 관련 명령어)

SWAP 스왑은 Linux 기반 운영 체제에서 가상 메모리로 작동하는 저장 장치(예: HHD, SSD, 가상 저장 장치)의 전용 공간이다. 시스템의 사용 가능한 메모리가 부족할 때 물리적 RAM(Random Access Memory)을 보

easyitwanner.tistory.com

아주아주 간단하고 단순하게 정리하면 t2.micro의 램은 1GB 밖에 안돼서 이걸 확장하고자 swap을 사용한다.

확장이라는게 정말 RAM의 공간이 늘어나는 것은 아니고 자주 사용하지 않는 것을 swap 영역으로 빼고 새로운 프로세스가 RAM에 할당되도록 하는 것!

swap 영역을 설정한 이유는 Jenkins 때문이다.

기본 설치만 하고 Jenkins 잘 연결 됐나~ 테스트 했더니 메모리 부족으로 인해 서버가 멈추는 상황이 발생했고, 그로 인해 swap 영역을 설정해봤더니 이정도로 가능했다.

만약! swap 영역을 설정했는데도 서버가 멈춘다면 인스턴스 유형을 t2.micro가 아닌 상위 성능의 유형을 선택해야 한다.

swap 공간의 크기는 권장사항이 어느정도 설정되어있다. 무조건 따라야 하는 정도의 사항은 아니라고 하지만 어느정도는 맞춰주는 것이 좋다고 생각한다.

이 권장 사항에 대해서는 위 링크에서 잘 정리해주셨다.

그럼 이제 설정 시작!

권장 사항에 따라 swap 공간의 크기를 RAM의 2배로 설정한다.

t2.micro는 1GB의 메모리를 갖기 때문에 2GB로 설정해준다.

sudo dd if=/dev/zero of=/swapfile bs=128MB count=16

dd 명령어를 통해 root File System에 swap file을 생성하게 된다.

bs의 경우 블록의 크기를 의미하고 count는 블록의 수를 의미한다.

그래서 128 * 16으로 2048MB를 설정하게 된다.

이때 지정한 블록 크기는 인스턴스에서 사용가능한 메모리보다 작아야 한다.

그렇지 않다면 memory exhausted 오류가 발생한다.

다음으로 swap file에 대해 읽기 및 쓰기 권한을 수정하고 Linux swap 영역을 설정한다.

이후 swap 공간에 swap file을 추가해 swap file을 즉시 사용할 수 있도록 만들어준다.

sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 모두 성공했는지 확인
sudo swapon -s

swapon -s 명령어를 입력했을 때 Filename에 /swapfile이 나와야 한다.

이제 /etc/fastb 파일을 편집해 부팅 시 swap file이 활성화 되도록 해준다.

아래 명령어로 fstab 파일을 열어주고

/swapfile swap swap defaults 0 0 을 가장 마지막 줄에 추가해준 뒤 저장하고 종료하면 된다.

sudo vi /etc/fstab

그리고 아래처럼 free -h 를 입력했을 때 이미지와 같이 swap total이 2.0Gi가 되었다면 성공이다!

2. JDK17 설치

프로젝트 환경과 일치하는 JDK 17을 설치한다.

어려운 것은 없기 때문에 짧게 정리.

sudo apt-get update
sudo apt-get install openjdk-17-jdk

# openjdk version "17.0.11" 이런식으로 출력되어야 한다. 설치기간에따라 조금 차이는 있을 수 있다.
java -version

# 환경변수 설정
sudo vi /etc/profile

# /etc/profile 최하단에 아래 코드를 추가한 뒤 저장한다.
export JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar

#EC2 Instance reboot
sudo reboot now

#적용 확인
echo $JAVA_HOME
echo $PATH
echo $CLASSPATH

혹시 apt-get update 명령어를 수행했을 때 Some index files failed to download. They have been ignored, or old ones used instead. 라는 오류가 발생한다면 보안그룹의 아웃바운드 규칙을 확인한다.

아웃바운드 규칙이 모든 트래픽을 허용하고 있지 않다면 오류가 발생한다.

아웃바운드 규칙을 허용하는 것 만으로 문제를 해결했지만 그렇지 않은 경우도 있다고 해 그 방법들도 정리한다.

가장 먼저 DNS가 제대로 잡히지 않아 발생하는 경우가 있다고 한다.

이런경우 /etc/resolvl.conf에서 nameserver를 8.8.8.8로 수정해준다.

다음 방법은 /etc/apt/sources.list를 수정하는 방법이다.

오류를 검색했을 때 가장 많이 나오는 해결 방안이다.

기본 구조는 리전.ec2.archive.ubuntu.com/ubuntu/jammy main restricted ~~~ 이런 구조일 것이다.

이게 몇줄에 걸쳐서 조금씩 차이가 있는 구조로 작성되어 있을 텐데 이 주소를 모두 수정해주면 된다.

일단 수정할 값의 선택지는 몇개를 확인할 수 있었다.

ftp.daumkakao.com/ubuntu
ftp.daum.net/ubuntu
kr.archive.ubuntu.com/ubuntu

이 세개의 주소를 하나씩 넣어보면서 확인해야 할 것 같다.

이 오류가 발생하는 이유에 대해 보통 서버측 오류일 가능성이 크다고 많이들 판단하시는 것 같다.

그럼 이걸 하나하나 바꾸기는 어려우니 vim 명령어를 통해 한번에 수정해준다.

/etc/apt/sources.list 에 vim으로 접근하고 하단에 아래와 같은 명령어를 입력하면 한번에 바꿔줄 수 있다.

예시는 3번 주소로 바꾸는 예시다.

:%s /archive.ubuntu.com/ubuntu /kr.archive.ubuntu.com/ubuntu

근데 뭐가됐던 일단 아웃바운드가 열려있어야 한다!!!!

3. nvm 설치 및 node 21.7.1 설치

다음은 React 환경과 동일한 node 21.7.1 버전을 설치한다.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.4/install.sh | bash

source ~/.bashrc

nvm install 21.7.1

# 21.7.1을 사용하겠다는 명령어
nvm use 21.7.1

# 21.7.1을 default 버전으로 설정
nvm alias default 21.7.1

# node 버전 확인
node -v

이것도 딱히 정리할 내용은 없어서 패스!

4. Nginx 설치

Nginx의 설치는 아래 명령어로 처리한다.

그리고 알아서 실행된다고 하지만 확실하게 명령어를 통해 실행시켰다.

sudo apt-get install nginx

sudo service nginx start

Nginx 설정 파일을 생성하고 적용해야 한다.

Nginx 설치 이후 /etc/nginx/sites-available에 접근하면 default라는 파일이 존재한다.

이 파일을 수정하는 케이스도 봤지만 파일을 만들어서 처리하는 경우가 더 많이 보였기 때문에 해당 방법으로 처리했다.

새로운 파일로 test.conf라는 파일을 만들어주고 이 파일을 sites-enabled에 심볼릭 링크를 만들어 이 설정파일을 통해 처리하도록 하는 과정이다.

예시로 도메인은 nvaer.com이라고 가정했고, EC2 public IP는 11.111.111.111로 가정했다.

만약 이 포스팅들을 처음부터 보고 있다면 도메인은 없을테니 public IP만 알고 있으면 된다.

cd /etc/nginx/sites-available

# 이 명령어를 수행했을 때 default가 존재해야 한다.
ls -al

# test.conf 파일을 생성한다. 이름은 상관없고 .conf로만 만들어주면 된다.
sudo vi test.conf

# test.conf의 내용
server {
    listen 80; # IPv4
    listen [::]:80; # IPv6
    
    # 도메인 연결이 안되었다면 임시로 EC2 public IP를 적는다. 도메인 연결후 수정하면 됨.
    server_name naver.com
    
    # 배포할 프로젝트의 메인 경로로 설정. 만약 localhost:8080/main이 메인 경로라면 / 가 아닌 /main으로.
    location / {
        proxy_pass http://11.111.111.111:8080; #EC2 public IP와 프로젝트 서버 포트 작성
        proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_set_header X-Forwarded-Proto $scheme;
    }
    
    # ALB 대상그룹 Health check에 활용
    # 원래라면 상단의 메인 경로를 통해 체크되는데 뭘해도 저 경로로 잡히지가 않아서 불가피하게 추가
    # 메인 경로로 health check가 되지 않는다면 아래 코드를 작성.
    location /health {
        return 200 'healthy';
        add_header Content-Type text/plain;
    }
}

# sites-enabled에 심볼릭 링크 생성
sudo ln -s /etc/nginx/sites-available/test.conf /etc/nginx/sites-enabled

# site-enabled에 default가 존재한다면 default만 적용되기 때문에 제거해준다.
# 제거하더라도 site-available에는 존재하기 때문에 백업을 따로 할 필요는 없다.
# 주의 해야할 사항은 site-enabled에 존재하는 default만 제거해야 한다.
sudo rm default

# nginx 재구동
sudo service nginx reload
# or
sudo service nginx restart
# or
sudo systemctl restart nginx

여기에 추후 추가되는 사항도 있다.

만약 ACM을 통해서 인증서를 받지 않는 경우에는 80포트 아래에 443 포트도 추가해줘야 하고 그렇게 되면 인증서 정보가 꼭 들어가줘야 한다.

테스트는 ACM을 통해 인증서를 발급 받았기 때문에 위 내용으로 처리가 가능하지만 그렇지 않은 경우는 아래와 같이 작성해준다.

# test.conf
server {
	listen 80; # IPv4
	listen [::]:80; #IPv6
	listen 443; # https 포트 추가.
	listen [::]:443;
	
	server_name naver.com # 도메인명 혹은 public IP
	
    # 인증서 설정 추가
	ssl_certificate /certificate 경로/certificate.crt;
	ssl_certificate_key /cerficiate key 경로/private.key;
	
	location / {
		proxy_pass http://11.111.111.111:8080; # public IP
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_set_header X-Forwarded-Proto $scheme;
	}
	
	# AWS 대상그룹 Health check를 위해 필요
	location /health {
		return 200 'healthy';
		add_header Content-Type text/plain;
	}
}

443 포트까지 설정했는데 인증서 정보가 없다면 오류가 발생한다.

가장 아래에 /health는 이후 ALB 대상 그룹 생성의 health check에 사용되는데 원래는 그냥 기본 메인 경로를 통해 체크가 되었었는데 뭘 해도 안되길래 추가해서 200을 반환하도록 처리했더니 정상적으로 동작했다.

처음부터 추가할 필요는 없고 만약 대상 그룹에서 health check가 되지 않는다면 그때 작성해서 시도해보는 것도 좋을듯!

5. Jenkins 설치 및 빌드 Job 설정을 제외한 나머지 처리

Jenkins 설치와 페이지 접근, Jenkins의 계정 생성까지 정리.

Jenkins도 이전과 설치 방법이 좀 바뀌엇다.

# Jenkins 공개키 다운로드 및 저장
curl -fsSL https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key | sudo tee \ /usr/share/keyrings/jenkins-keyring.asc > /dev/null

# Jenkins Repository 추가
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \ 
https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
/etc/apt/sources.list.d/jenkins.list > /dev/null

# 패키지 목록 업데이트 후 Jenkins 설치
sudo apt update
sudo apt install jenkins

# 상태 확인
sudo systemctl status jenkins

# 초기 비밀번호 ( 따로 메모 )
sudo cat /var/lib/jenkins/secrets/initialAdminPassword

# 포트 변경전 권한 수정
sudo chmod 777 /usr/lib/systemd/system/jenkins.service
# 포트 번호 원하는 번호로 수정 후 저장
sudo vi /usr/lib/systemd/system/jenkins.service
# 꼭 권한을 다시 원래대로 수정한다
sudo chmod 444 /usr/lib/systemd/system/jenkins.service

# jenkins 재시작
sudo systemctl daemon-reload
sudo serivce jenkins restart


# 만약 그래도 변경되지 않았다면 아래 파일에서도 포트 변경 후 재시작
sudo vi /etc/default/jenkins

설치는 위 과정을 따라가기만 하면 무리없이 처리된다.

상태 확인 명령어를 수행했을 때 active가 정상적으로 나와야 하고 초기비밀번호의 경우 Jenkins 페이지 접근했을 때 필요하므로 저장해두도록 한다.

Jenkins 설치 이후에는 8080이 기본 포트로 설정되는데 프로젝트에서 8080 포트를 사용하기 때문에 9095 포트로 변경해줄 필요가 있어 포트 번호를 수정해준다.

마지막 재시작까지 수행하고 나면 EC2 public IP:jenkinsport 를 통해 페이지에 접근할 수 있다.

그럼 가장 먼저 비밀번호를 입력하라고 하는데 중간에 조회했던 초기 비밀번호를 붙여넣기 해준다.

그럼 이제 아래와 같은 페이지가 나오게 되는데 설정에 따라 다르겠지만 Install suggested plugins를 선택해 기본 플러그인들을 설치하도록 한다.

플러그인 설치가 완료된 이후에는 아래처럼 계정 생성 페이지가 나오는데 스킵해도 되지만 계정을 생성해줬다.

그럼 아래처럼 접근 URL이 나온다.

보통 접근한 URL이 그대로 나오기 때문에 딱히 건드릴 필요는 없을 것 같다.

이후 Jenkins 메인 페이지에서 Jenkins 관리 탭으로 이동한다.

System Configuration의 Plugins 로 이동.

Available plugins 탭으로 이동해 설치할 플러그인들을 설치해야 한다.

설치할 플러그인은 아래와 같다.

Post build task
NodeJS
GitHub Integration

플러그인을 하나 설치할때마다 재부팅 선택지가 있는데 이건 따로 언급되는 것을 본적이 없다.

그래도 그냥 있는 기능이니까 재부팅을 해줬다.

Post build task는 빌드를 처리할 때 사용할 것이고, NodeJS는 React 빌드를 위해 설치했다.

GitHub Integration은 git webhook 연동에 사용된다.

모든 플러그인을 설치했다면 Node에 대해 설정해줘야 할 것이 있다.

다시 Jenkins 관리 탭으로 이동해 이번에는 System Configuration의 Tools로 이동한다.

그리고 하단으로 쭉 내려보면 NodeJS Installiations가 존재한다.

이미지는 이미 설정해둔 상태라 그렇지만 Add NodeJS라는 버튼이 빨간 박스 위치에 있을 것.클릭!!

EC2 인스턴스에 설치한 것과 동일한 21.7.1 버전을 사용하도록 하는 과정이다.

Install automatically를 체크해 자동으로 설치하도록 한다.

다 처리했다면 Apply 누른뒤 Save!

그럼 이제 Jenkins에서 빌드를 제외한 기본적인 설정은 끝이다.

6. ElastiCache Redis OSS 캐시 생성 및 Redis 설치

EC2에 Redis를 설치하기 전 ElastiCache에서 Redis OSS 캐시를 생성한다.

AWS에서 ElastiCache로 접근하고 리소스 하위에 있는 Redis OSS 캐시 탭으로 이동해 Redis OSS 캐시 생성 버튼을 클릭한다.

아래 이미지처럼 배포 옵션에서는 자체 캐시 설계를 선택하고 생성 방법은 클러스터 캐시로 선택한다.

클러스터 모드는 비활성화를 선택한다.

테스트이기 때문에 굳이 사용할 것 같지 않은데다가 활성화 하면 추가적인 요금도 발생한다.

클러스터 정보에는 이름을 작성해주면 된다.

위치 탭에서는 위치에 대해 AWS 클라우드를 선택하고 클러스터 설정에서 포트는 기본값 그대로 유지했다.

위치 탭의 다중 AZ는 이미지와 다르게 활성화된 상태일텐데 클러스터 설정 하단의 복제본 개수를 0으로 바꿔주면 비활성화 된다.

이것도 테스트에 필요하진 않아서 0으로 수정했다.

노드 유형의 경우 24년 7월 기준으로 기본 값이 cache.r7g.large로 되어있다.

이렇게 큰게 필요없기도 하고 이것도 유형 선택에 따라 요금이 달라지기 때문에 프리티어에 해당하는 t3.micro를 선택했다.

연결 탭에서는 새 서브넷 그룹 생성을 선택하고 서브넷명을 작성해준다.

그리고 서브넷 선택됨 탭의 관리 버튼을 눌러 자신의 리전에 해당하는 서브넷을 선택해주면 되는데 여러개를 선택할 수 있다.

가용영역 배치는 따로 건드릴 것은 없어서 그대로 두고 다음 버튼을 클릭!

다음 페이지인 고급 설정에서는 보안 그룹만 선택해주고 나머지는 건드리지 않았다.

보안 그룹 역시 기존에 생성한 모든 환경에 대해 열어준 그 보안 그룹을 선택했다.

여기서 다시 한번 생각해보면 왜 보안그룹을 하나로 처리하지 말아야 하는지 알 수 있다.

열어줘야 하는 인바운드 규칙은 6379 포트 하난데 하나의 보안그룹을 사용하면 괜히 Redis cache에 80, 443, 8080 등등 규칙이 들어가 있게 된다.

뭐.. 일단은 테스트니까~

하단의 다음 버튼을 누르면 생성이 완료되고 이제 EC2에서 Redis를 설치한다.

sudo apt-get update

# build-essential과 wget 설치
sudo apt-get install build-essential wget

# Redis의 최신 버전을 포함하는 tar.gz 다운로드
wget http://download.redis.io/redis-stable.tar.gz

# 다운로드 받은 파일 조작
tar xvzf redis-stable.tar.gz

cd redis-stable
make distclean
make

# redis 접속
# -h 이후에는 ElasticCache 엔드 포인트를 적는다. com 뒤에 포트는 ' : '가 아닌 -p로 수정해준다.
src/redis-cli -c -h RedisOSS 캐시 기본 엔드포인트 -p 6379

여기서는 조금 생소했던 tar xvzf ~~~ 코드에 대해 조금 정리를 한다.

tar는 tar 아카이브 조작을 위한 유틸리티이다.

xvzf는 각각 의미가 있는데 아래와 같은 의미를 갖는다.

x - 파일 추출
v - 자세한 모드(추출 과정을 보여준다)
z - gzip 압축 해제
f - 파일 지정

make distclean도 정리.

make는 Makefile을 읽고 소프트웨어를 빌드하는 명령어다.

distclean은 모든 빌드 아티팩트와 설정 파일을 제거하여 소스트리를 초기 상태로 되돌리는 make 타겟이다.

주로 이전 필드의 잔여물을 제거하기 위해 사용한다.

이후 make 명령어는 Makefile에 정의된대로 소스코드를 빌드한다. 여기서는 Redis 서버와 클라이언트 프로그램이 컴파일 된다.

그럼 이제 마지막 라인에 작성된 명령어를 통해 redis에 접속할 수 있다.

이때 명령어 입력 위치는 redis-stable이다.

명령어를 입력할 때 엔드포인트는 포트를 제외한 com 까지만 작성해주면 된다.

Redis 접속 이후 정상 동작하는지 명령어를 통해 체크하면 된다

프로젝트의 application.yml에서도 redis 관련 정보 host에 엔드포인트를 작성하면 되는데 접속 명령어때와 마찬가지로 com 까지만 작성해주면 된다!

'Web > AWS' 카테고리의 다른 글

SpringBoot & React AWS 배포 테스트 5) Load Balancer 대상 그룹 생성 및 ALB 생성 후 대상 그룹 설정 (0)	2024.08.03
SpringBoot & React AWS 배포 테스트 4) Gabia 도메인 구매 후 Route53, ACM 처리 (0)	2024.08.03
SpringBoot & React AWS 배포 테스트 2) RDS MySQL Database Instance 생성 후 Local Workbench와 연결 테스트 및 프로젝트 연결 테스트 (0)	2024.08.02
SpringBoot & React AWS 배포 테스트 1)S3 Bucket 로컬 테스트 (0)	2024.08.02
S3 이미지 파일 처리 (0)	2024.08.01

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

공부하는블로그