코딩조각모음

[AWS] EC2 인스턴스 절감형 플랜 및 Aurora Mysql 예약형 인스턴스

blackzapato — Wed, 6 Nov 2024 14:16:47 +0900

EC2 인스턴스 절감형 플랜

EC2 절감형 플랜 구매 요금

월 별 요금 비교

(구매 전) 0.0208 * 24 * 30 = $ 14.98 (소수점 3번째 자리에서 반올림)
(구매 후) 0.0117 * 24 * 30 = $ 8.42 (소수점 3번째 자리에서 반올림)

스토리지 요금을 제외 한 단순 인스턴스 요금 비교시 6.56 USD 차이가 난다.

구매 옵션

시간당 약정 = 사용하는 인스턴스의 Savings Plans 요율 * 인스턴스 개수

(ex. t4g.small Savings Plans 요율 * 사용하는 t4g.small 개수 = 0.0234)

Aurora Mysql 예약형 인스턴스

RDS 예약 인스턴스 요금

월 별 요금 비교

(구매 전) 0.113 * 24 * 30 = $ 81.36
(구매 후) 0.047 * 24 * 30 = $ 33.84

스토리지 및 I/O Request 요금을 제외 한 단순 인스턴스 요금 비교시 47.52 USD 차이가 난다.

예약 옵션

[AWS] 아키텍처 고도화 설계 및 기존 아키텍처와 비교 분석

blackzapato — Sun, 27 Oct 2024 20:19:01 +0900

1. 서론

구축된 기존 AWS 아키텍처와 고도화된 AWS 아키텍처를 비교 분석하여, 각 구성 요소와 특징을 검토하고 기존 아키텍처의 한계점 및 개선된 점을 설명하고자 한다. 이를 통해 AWS 기반 서비스의 성능과 보안, 확장성 등 주요 요소에서 어떠한 변화가 발생하였는지 작성할 것이다.

2. 기존 AWS 아키텍처

2.1 구성 요소 및 특징

기존 아키텍처는 AWS내에 구성된 여러 가지 핵심 서비스로 구성된다.

대표적인 요소로는 다음과 같다

S3 (Simple Storage Service): 정적 컨텐츠를 저장하고 있는 객체 스토리지 서비스

EC2 (Elastic Compute Cloud): 서버 인스턴스 역할을 하는 주요 컴퓨팅 리소스.

Aurora Mysql: RDS(Mysql) 기반의 데이터베이스 서비스.

NAT (Network Address Translation) Gateway: 프라이빗 서브넷의 인스턴스들이 인터넷에 접근할 수 있도록 지원.

이 아키텍처는 퍼블릭 및 프라이빗 서브넷으로 구성된 두 개의 가용영역(AZ)을 기반으로 확장성을 갖춘 형태로 설계되었다.

2.2 한계 및 문제점

기존 아키텍처는 기본적으로 확장성을 고려하였지만, 다음과 같은 문제점이 존재한다.

리소스 최적화 미흡: EC2 인스턴스의 수동 배포와 관리는 비용 효율성이 떨어질 수 있음.

지연 시간 증가: 정적 컨텐츠 및 데이터의 캐싱과 데이터베이스 간의 연결 성능이 제한적일 수 있으며, 이 때문에 지연 발생 가능.

보안 취약점: Private 리소스에 접근하기 위해 WEB EC2 인스턴스가 외부에 노출되어 있어 잠재적인 보안 위협이 존재한다.

고가용성 및 재해 복구: 로드밸러서와 오토스케일을 배치하지 않아 각 서비스의 부하를 해소 할 수 없으며, 단일 가용 영역 내에서만 리소스를 프로비저닝하여 고가용성에 한계가 존재한다.

3. 고도화된 AWS 아키텍처

3.1 구성 요소 및 특징

고도화된 아키텍처는 기존 아키텍처의 한계를 극복하고자 다양한 신규 요소와 향상된 구성을 도입하였다. 주요 구성 요소는 다음과 같다.

Bastion: Private 영역 리소스 접근을 위한 EC2

CloudFront: 정적 콘텐츠의 효율적인 전송을 위한 CDN(Content Delivery Network) 구성.

Auto Scaling Group: 트래픽 변화에 따라 EC2 인스턴스 수 자동 조정.

Elasticache, Redis: 세션 및 데이터베이스 캐싱.

ALB (Application Load Balancer): 웹 애플리케이션 트래픽 분산.

ACM (AWS Certificate Manager): SSL/TLS 인증서 관리를 통한 강화된 보안.

EFS (Elastic File System): 여러 인스턴스 간의 데이터 공유를 지원하는 파일 스토리지.

CI/CD 파이프라인: GitLab과 Jenkins를 통해 지속적인 통합 및 배포 자동화 구현.

Docker: 컨테이너 기반의 애플리케이션 배포로 관리 및 배포의 유연성 향상.

3.2 아키텍처 흐름도

고도화된 아키텍처는 다양한 AWS 서비스를 연계하여 트래픽 처리 및 데이터 관리의 효율성을 크게 향상시켰다. 트래픽 흐름은 다음과 같다.

클라이언트 요청이 AWS CloudFront를 통해 전달되며, 정적 콘텐츠는 S3에서 제공되고, 동적 콘텐츠는 ALB를 통해 EC2 인스턴스로 전달된다.

EC2 인스턴스는 Docker 컨테이너를 사용하여 애플리케이션을 실행하며, 파일 스토리지는 EFS를 사용하여 공유된다.

데이터베이스는 Aurora Mysql이 제공하며, 캐싱 계층은 Elasticache를 사용하여 응답 시간을 단축시킨다.

CI/CD 파이프라인을 통해 GitLab에서 코드가 Jenkins로 배포되어 자동화된 빌드와 배포가 이루어진다.

3.3 기존 아키텍처 대비 개선된 점

컨테이너 기반 배포: Docker를 통해 EC2 인스턴스의 관리 및 배포를 효율적으로 진행할 수 있어 개발 환경과 운영 환경의 일관성을 보장.

데이터 관리 향상: EFS 도입으로 여러 인스턴스 간의 데이터 공유가 원활해지고, CloudFront로 인한 정적 콘텐츠 전달 속도 향상 및 Elasticache를 통해 데이터 접근 속도가 개선되었다.

보안 강화: ACM을 통한 SSL 인증서 관리와 CloudFront, Bastion 서버로 인해 연결 보안성이 보장되고, CI/CD 자동화를 통해 코드 품질과 배포 안정성이 향상되었다.

비용 절감 및 확장성: Auto Scaling과 Load Balancer를 통해 트래픽에 유연하게 대응할 수 있어 리소스 최적화로 인한 비용 절감도 가능하다.

4. 결론

기존 아키텍처와 고도화된 아키텍처를 비교하여 개선된 부분을 분석하였다. 고도화된 AWS 아키텍처는 성능, 보안, 관리 용이성 측면에서 더욱 강화되었으며, 특히 CI/CD 파이프라인과 컨테이너 기술 도입으로 더욱 편한 개발환경을 지원할 수 있는 구조를 갖추게 되었다. 향후 지속적인 모니터링과 최적화를 통해 비용절감을 할 수 있을 것으로 기대된다.

[AWS] 서버 구축 EC2(WEB, WAS) - Nginx, Tomcat 연동

blackzapato — Tue, 8 Oct 2024 09:23:51 +0900

서버 구축 순서

연동 전 살펴봐야 할 것

# Tomcat 상태 확인
ps -ef | grep tomcat

# Nginx 상태 확인
sudo systemctl status nginx

WEB, WAS가 위치한 EC2에서 위의 명령어로 상태를 체크한다.

모두 정상 실행되는 경우 연동을 진행한다.

Tomcat 기본 페이지만을 띄워주게 할 경우 Tomcat에서의 설정은 따로 필요 없다.

이 글에서는 Tomcat을 따로 설정하진 않고, Nginx만 설정하도록 한다.

Nginx 설정을 하기 전 설정 파일 목록을 살펴보자.

# 설치한 Nginx의 설정 파일 목록
ll /etc/nginx

그럼 여러 가지 파일들이 보이는데

우리가 주목해야 할 파일들은 아래 4가지다.

conf.d
default.d
nginx.conf
nginx.conf.default

이 중, nginx.conf 파일은 Nginx의 핵심 파일인데 nginx.conf 파일 안에

include /etc/nginx/default.d/*.conf;

위처럼 지정되어 있어 분명 쓰임새가 있어 보이긴 하는데, 막상 default.d 디렉터리를 열어보면 아무것도 없다.

사실, default.d과 conf.default는 개발자의 목적에 따라 커스텀이 가능한 파일이다. (default가 붙은 다른 파일 전부 해당)

왜 이렇게 만들어 놓았을까?
ex) 서버 설정이 길어져서 nginx.conf가 너무 시인성이 떨어진다면 default 파일이나 디렉터리에 설정을 분할해서 유연성 있게 관리할 수도 있다.

결론은 default가 붙은 파일들은 아무 필요가 없다.

~~괜히, Nginx를 처음 다뤄보는 입문자가 더 헷갈리게 해 놓은 것 같다. (심지어 네이밍도 default...)~~

추천할 만한 Nginx 설정 관리 2가지

1. 다수의 WAS 연동을 위한 symlink를 활용하는 설정 (nginx.conf 안에 include해서 사용)

nginx.conf
Nginx 주 설정 파일
conf.d
nginx.conf가 너무 길어져 분할해서 관리하고 싶을 경우 사용
sites-available
가용할 수 있는 was 설정을 모아두는 디렉터리
sites-enabled
available에서 모아둔 설정들을 symlink로 enabled 폴더에 걸어두어 Nginx에서 서비스하는 디렉터리

2. 소수의 WAS 연동

nginx.conf
Nginx 주 설정 파일
conf.d
Nginx에서 서비스할 was 연동 설정들을 모아두는 디렉터리

나는 사내 Test용 서버이기 때문에 2번째 설정으로 택해 연동을 진행하려 한다.

# conf.d 디렉토리 안에 새로운 conf 파일을 만들어 준다.
sudo vi /etc/nginx/conf.d/tomcat.conf

Nginx 연동 설정

server {
        listen 80;
        server_name localhost;

        location / {
                proxy_pass http://<EC2 Private ip>:<Tomcat 포트>;
                # ex) proxy_pass http://10.0.1.187:8080/;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}

위 내용을 붙여 넣기 후

ESC > ':qw' > 엔터로 빠져나오자

# Nginx 재기동 명령어
sudo systemctl restart nginx

이후 nginx에 접속하듯이 접속했는데 tomcat 기본 페이지가 나오면 모든 작업이 완료된다.

기타 옵션

  location/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version  1.1;
    proxy_cache_bypass  $http_upgrade;

    proxy_set_header Upgrade           $http_upgrade;
    proxy_set_header Connection        "upgrade";
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host  $host;
    proxy_set_header X-Forwarded-Port  $server_port;
  }

proxy_http_version 1.1
프록시를 위한 HTTP 프로토콜 버전을 정의합니다. 기본적으로 1.0으로 설정됩니다. 웹 소켓 및 활성 연결을 유지하려면 버전 1.1을 사용해야 합니다.
proxy_cache_bypass $http_upgrade
캐시에서 응답을 가져오지 않을 조건을 설정합니다.
Upgrade $http_upgrade 및 Connection "upgrade"
응용프로그램이 웹 소켓을 사용하는 경우 헤더 필드가 필요합니다.
Host $host
다음 우선순위의 $host 변수에는 요청 라인의 호스트 이름 또는 호스트 요청 헤더 필드의 호스트 이름 또는 요청과 일치하는 서버 이름이 포함됩니다.
X-Real-IP $remote_addr
실제 방문자 원격 IP 주소를 프록시 서버로 전달합니다.
X-Forwarded-For $proxy_add_x_forwarded_for
클라이언트가 프록시 처리한 모든 서버의 IP 주소를 포함하는 목록입니다.
X-Forwarded-Proto $scheme
HTTPS 서버 블록 내에서 사용할 경우 프록시 서버의 각 HTTP 응답이 HTTPS로 다시 작성됩니다.
X-Forwarded-Host $host
클라이언트가 요청한 원래 호스트를 정의합니다.
X-Forwarded-Port $server_port
클라이언트가 요청한 원래 포트를 정의합니다

[AWS] 서버 환경 구축 EC2, S3, Aurora Mysql 설정 - 3 (Aurora Mysql)

blackzapato — Mon, 7 Oct 2024 20:37:42 +0900

서버 환경 구축 순서

RDS란

보통은 우리가 DB를 사용할 때는 서버에 직접 설치된 DB를 사용하는데,

RDS는 이미 설치된 DB서버를 제공해 주는 역할을 한다.

다만, 그 서버에 접속할 수는 없고 DB 자체만 서비스로 제공하게 받게 된다.

장점은 서버에 DB를 직접 설치할 경우 둘 다 관리해야 되는

반면 RDS를 사용하게 되면 DB만 관리하면 되기 때문에 관리적인 측면에서 공수를 아낄 수 있다.

하지만 서버 설정을 바꿔주면서 DB를 좀 더 세세하게 다루고 싶을 때는 RDS를 사용하는 게 단점이 될 수 있다.

Aurora에 대해서

AWS에서는 mysql과 postgre를 이미 제공하고 있는데, 여기에 추가로 Aurora라고 하는 DB를 제공한다.

이는 mysql과 흡사한데 내부적인 엔진 개선을 통해 mysql보다 5배 빠르고, postgre보다는 20배 빠르다고 한다.

(대신 가격이 살짝 비쌉니다.)

시작에 앞서

RDS를 생성하는 이 부분은 내가 선택한 RDS생성 옵션을 뒤에 적을 내용의 흐름이 끊기지 않게만 간단히 적고

필요한 부분만 캡처와 함께 설명을 덧붙이고 넘어가려 한다.
모두가 생성하고 싶은 유형은 각기 다를 거라 생각해 불 필요한 부분인 것 같다.

또, RDS 생성 전 몇 가지 사전에 등록을 해줘야 한다.

아래 내용을 먼저 생성 한 뒤 RDS를 생성해보자.

DB 서브넷 그룹 생성
보안 그룹
파라미터 그룹 2개 생성(DB 클러스터, DB)

DB 서브넷 그룹 생성

RDS 대시보드 > 왼쪽 메뉴 서브넷 그룹 > 'DB 서브넷 그룹 생성' 클릭

가용 영역: 위의 Private Subnet이 속한 가용영역을 선택한다.

서브넷: RDS를 위치시킬 곳을 정하면 된다. 단, private Subnet으로 설정해 주자.

나의 경우 미리 사전에 생성해 둔,
Private Subnet(my-private-db-subnet-2a, my-private-db-subnet-2b) 2개를 선택해 줬다.
서브넷을 선택할 땐 이름이 안 보이니 서브넷을 만들 때 지정해 둔 CIDR값을 보고 판별하면 편하다.

보안 그룹 생성

EC2 대시보드 > 보안그룹 > '보안 그룹 생성' 클릭

인바운드 규칙은 Aurora DB에 접속 허용할 IP를 지정해 주면 된다.

나의 경우 외부에서는 web-server를 통해, 내부에서는 was-server가 db를 이용할 것이기 때문에

인스턴스 2개의 private ip로 인바운드 규칙을 생성해 주었다.

DB 클러스터 파라미터 그룹 생성

RDS 대시보드 > 왼쪽 메뉴 파라미터 그룹 > '파라미터 그룹 생성' 클릭

생성 한 뒤 상세 페이지에 들어가 우측 상단 '편집' 클릭

하위 총 3개의 카테고리를 수정해야 한다.

character => utf8mb4
time_zone => Asia/Seoul
collation => utf8mb4_general_ci

character 변경

time_zone 변경

collation 변경

위 모두 수정 후 각각 '변경 사항 저장' 클릭

DB 파라미터 그룹 생성

RDS 대시보드 > 왼쪽 메뉴 파라미터 그룹 > '파라미터 그룹 생성' 클릭

DB 파라미터 그룹은 따로 설정해줄 것이 없다.

RDS 생성

RDS 대시보드 > '데이터베이스 생성' 클릭

데이터베이스 생성 방식 선택: 표준 생성
엔진 유형: Aurora MySQL
엔진 버전: Aurora MySQL 3.05.2 (compatible with MySQL 8.0.32)
템플릿: 개발/테스트
설정: (아래 캡처 참조)
클러스터 스토리지: Aurora Standard
인스턴스 구성: 버스터블 클래스 (db.t4g.medium)
가용성 및 내구성: Aurora 복제본 생성하지 않음
연결: (아래 캡처 참조)
모니터링: off
추가 구성: (아래 캡처 참조)
(나머지는 기본값)

설정

DB 클러스터 식별자: my-db-cluster-1

자격 증명 관리: 자체관리

마스터 사용자 이름: admin

마스터 암호: 원하는 암호로 설정

연결

미리 생성해 둔 VPC, 서브넷 그룹, VPC 보안 그룹을 선택한다.

가용 영역은 RDS를 생성하려 미리 만들어둔 프라이빗 서브넷이 위치한 AZ를 선택한다.

추가 구성

초기 데이터베이스 이름은 입력해 두면 db 인스턴스가 생길 때 sys같은 스키마를 생성해준다.

DB 클러스터 파라미터 그룹, DB 파라미터 그룹은 위에서 미리 생성해 둔 것을 사용하자.

그 외는 전부 기본값으로 둔다.

'데이터베이스 생성' 클릭!

생성이 완료되었으면 이제 연결 테스트를 해보자!

WAS 서버와 연결 확인

was에 접속해서 아래 명령어를 실행해 보자.

curl -v <rds 엔드포인트>:3306

위처럼 Connected 되었다면 연결 성공 된 것이다.

외부(local)에서의 연결 확인

DBeaver 기준

Main탭에서 Server Host는 RDS 엔트포인트를 입력하고

username, password는 rds 생성할 때 기입한 것을 똑같이 입력하면 된다.

SSH탭에서 Host/IP는 web-server의 퍼블릭 IP를 입력하고

User Name과 password는 web-server의 사용자 정보를 넣어주자

ec2-user는 EC2 초기 생성 당시 디폴트 사용자라 있겠지만

비밀번호는 추가로 설정해줘야 한다.

이로서 서버 환경 구축은 모두 완료되었다.

이제 다음글에서 Nginx, Tomcat, Java를 EC2에 설치해보고 연동해 보자.

[AWS] 서버 구축 EC2(WEB, WAS) - Nginx, Tomcat, Java 설치 및 연동

참고 사이트

https://cholol.tistory.com/538

[AWS] 서버 구축 EC2(WAS) - Java, Tomcat 설치

blackzapato — Mon, 7 Oct 2024 15:21:50 +0900

서버 구축 순서

EC2 Server 환경

Amazon Machine Image(AMI)

Amazon Linux 2023 AMI

아키텍처

64비트(Arm)

Java 설치

# root 사용자 권한을 얻는다.
sudo -s

# 설치 가능한 java 목록을 가져온다.
yum list | grep java

명령어를 실행하면 설치 가능한 java 목록이 수두룩하게 나오지만 아래와 같이 생긴 버전 중 선택해서 설치해 주면 된다.

내가 17버전을 선택한 이유는 추후 jenkins나 sonarqube를 설치할 때의 java 버전도 고려해야 하기 때문이다
(현재 기준 sonarqube의 경우 java 17버전만을 지원한다.)

java-17-amazon-corretto.aarch64
- 기본적인 Java 런타임 환경 (JRE)입니다. Java 애플리케이션을 실행할 수 있지만, 컴파일러 및 개발 도구는 포함되지 않습니다.
- 사용 예: 단순히 Java 애플리케이션을 실행하기만 할 때.
java-17-amazon-corretto-devel.aarch64
- Java 개발 도구 (JDK)를 포함합니다. Java 프로그램을 개발하고 컴파일해야 한다면 이 패키지를 선택해야 합니다.
- 사용 예: Java 애플리케이션을 개발하고 컴파일할 때. javac와 같은 컴파일러가 필요하다면 이 패키지를 선택.
java-17-amazon-corretto-headless.aarch64
- GUI 기능이 없는 경량화된 JRE입니다. 서버 환경에서 자주 사용되며, 그래픽 관련 라이브러리가 필요 없을 때 사용합니다.
- 사용 예: GUI가 필요 없는 서버 애플리케이션을 실행할 때.
java-17-amazon-corretto-javadoc.aarch64
- JavaDoc 문서를 포함한 패키지입니다. Java 코드에 대한 API 문서를 생성할 수 있습니다.
- 사용 예: Java 소스 코드에 대한 API 문서를 생성하거나 문서를 참고해야 할 때.
java-17-amazon-corretto-jmods.aarch64
- 모듈 시스템을 위한 JMOD 파일을 포함한 패키지입니다. Java 9 이상에서 사용할 수 있으며, 모듈화 된 애플리케이션을 개발할 때 필요할 수 있습니다.
- 사용 예: Java 모듈 시스템을 사용하여 Java 애플리케이션을 구성할 때.

Java 애플리케이션 실행만이 목적이라면 java-17-amazon-corretto.aarch64 또는 java-17-amazon-corretto-headless.aarch64를 선택
Java 개발을 해야 한다면 java-17-amazon-corretto-devel.aarch64를 선택하는 것이 좋습니다.

# 앞으로 서버를 어떻게 사용할지 잘 모르겠다면, JDK를 설치하는게 나을것 같다.
yum -y install java-17-amazon-corretto-devel.aarch64

# 설치한 java 버전 확인
java -version

# profile을 열어 환경변수를 등록
vi /etc/profile

# profile가 열렸으면 아래 내용 파일 맨 밑에 추가
export JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto-devel.aarch64
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=$JAVA_HOME/jre/lib:$JAVA_HOME/lib/tools.jar

# 변경한 환경변수를 적용
source /etc/profile

# 변경한 환경변수를 쉘에서 출력
echo $JAVA_HOME

사용하고 있는 java 버전이 많은데 특정 java 버전을 default로 한번에 지정, 관리하고 싶다면

alternatives 명령어를 통해 설정 할 수 있다.

# 사용가능한 자바목록에 Java Version 추가
alternatives --install <link> <name> <path> <priority>

# Default Java로 설정 변경
alternatives --config <name>

# 자바목록에서 Java Version 삭제
alternatives --remove <name> <path>

Tomcat 설치

아래 홈페이지에 접속해보자.

Tomcat 홈페이지

위에서 설치한 Java 버전이

설치하고자 하는 Tomcat 버전의 Supported Java Versions 안에 속해 있다면

설치하고자 하는 Tomcat 버전의 tar.gz에서 오른쪽 클릭으로 링크 주소 복사를 해주자.

# root 사용자의 권한이 아니라면 실행 후 아래 내용 진행
sudo -s

################################################################

# Tomcat을 설치하려는 디렉토리 생성
mkdir /apps/WAS

# 생성한 폴더 이동
cd /apps/WAS

################################################################

# 위에서 링크 주소 복사한것을 wget 뒤에 붙여넣기 후 실행
wget https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.30/bin/apache-tomcat-10.1.30.tar.gz

# 다운받은 압축파일 해제
tar -zxvf apache-tomcat-10.1.30.tar.gz

# 다운받은 압축파일 삭제시 실행
rm -rf apache-tomcat-10.1.30.tar.gz

################################################################

# Tomcat 실행
apache-tomcat-10.1.30/bin/startup.sh

# Tomcat 중지
apache-tomcat-10.1.30/bin/shutdown.sh

# Tomcat 상태 확인
ps -ef | grep tomcat

Tomcat을 실행하기 전 EC2의 보안그룹에 접속할 수 있는 ip를 미리 허용해 두자. (Tomcat 기본 포트는 8080)

[AWS] 서버 구축 EC2(WEB) - Nginx 설치

blackzapato — Mon, 7 Oct 2024 15:20:59 +0900

서버 구축 순서

EC2 Server 환경

Amazon Machine Image(AMI)

Amazon Linux 2023 AMI

아키텍처

64비트(Arm)

Nginx 설치

# root 사용자의 권한을 얻어준다.
sudo -s

#  yum을 최신상태로 update 시켜준다.
yum update -y

# yum repository에 nginx를 다운받을 수 있는 repository를 등록 해준다.
vi /etc/yum.repos.d/nginx.repo

위의 명령어를 통해 새로운 파일이 생성된다.

nginx.repo

[nginx]
name=nginx repo
baseurl= http://nginx.org/packages/centos/7/$basearch/
gpgcheck=0
enabled=1

새로 생성한 파일에 위의 내용 붙여 넣기 후

ESC > ':qw ' 입력 > 엔터로 빠져나온다.

# 새로 등록한 nginx repository에 상태를 체크한다.
yum info nginx

위 사진과 비슷한 내용이 나온다면 repository에 성공적으로 등록된 것이다.

# nginx를 설치 한다.
yum install nginx -y

# 설치한 nginx의 버전을 확인 한다.
nginx -v

# nginx 시작
systemctl start nginx

# nginx 종료
systemctl stop nginx

# nginx 상태 확인
systemctl status nginx

Nginx를 실행하기 전 EC2의 보안그룹에 접속할 수 있는 ip를 미리 허용해 두자. (Nginx의 기본 포트는 80)

[AWS] 서버 환경 구축 EC2, S3, Aurora Mysql 설정 - 2 (S3)

blackzapato — Mon, 7 Oct 2024 15:19:00 +0900

서버 환경 구축 순서

S3 구축 전체적인 흐름

버킷 생성
버킷 정책 수정
S3연결할 EC2에 역할 배정
EC2에서 S3 연결 확인

S3 버킷 생성

S3 대시보드 > '버킷 만들기' 클릭

버킷이름은 원하는 대로 입력한다.

위와 같이 세팅 후 나머지 설정은 전부 기본값 놔두고 '버킷 만들기'

버킷 정책 수정

생성된 버킷 상세 페이지 '권한' 탭 클릭 > '버킷 정책'의 '편집' 클릭 > '정책 편집기' 클릭

위와 같이 값을 채워 넣자.

Actions: GetObject, PutObject
ARN: 버킷 상세 페이지 '속성'탭 Amazon 리소스 이름(ARN)의 값을 넣어주는데 값 뒤에 /*를 꼭 넣어주자
ex) arn:aws:s3:::s3-bucket-1/*

Add Statement > Step 3: Generate Policy 하단에 'Generate Policy' 클릭

위처럼 팝업이 생성되는데 안에 내용 전부 복사 후 버킷 정책안에 붙여 넣고

'변경 사항 저장'을 눌러 완료한다.

만약 IAM으로 생성한 역할 또는 사용자로 지정된 EC2나 애플리케이션으로 S3 접근 시
IAM으로 설정한 정책이 1순위, S3 정책이 2순위로 적용된다.
IAM으로 연결되지 않은 사용자가 S3 접근시 S3정책이 1순위로 설정되게 된다.
디폴트 정책이라고 생각하면 된다.

S3연결할 EC2에 역할 배정

EC2 대시보드 > 연결할 EC2 선택 > 우측 상단 '작업' > '보안' > 'IAM 역할 수정' 클릭

새탭으로 페이지가 생성되는데 '새 IAM 역할 생성' 클릭 > 우측 상단 '역할 생성' 클릭

역할 생성 1단계

역할 생성 2단계

역할 생성 3단계

위처럼 3단계에 걸쳐 세팅 후 '역할 생성' 한다.

그 후, 다시 EC2 IAM 역할 수정화면으로 돌아와 새로고침을 하면 생성한 역할이 셀렉트박스에 값으로 추가되는데

위처럼 선택한 후 'IAM 역할 업데이트'를 하면 EC2의 IAM 역할이 배정된다.

EC2에서 S3 연결 확인

# S3 bucket의 object list를 조회
aws s3 ls <S3버킷이름>

그 후 test.txt를 만들어 준 후, s3에 업로드해보았다.

# 파일 생성
vim test.txt

# 생성한 파일 S3에 올리기
aws s3 cp ./test.txt s3://<S3버킷이름>

# 반대로 다운받는 명령어
aws s3 cp s3://<S3버킷이름>/test.txt ./

위의 명령어가 모두 동작되면 연동은 완료된 것이다.

참고 사이트

https://kimjingo.tistory.com/209

[AWS] 서버 환경 구축 EC2, S3, Aurora Mysql 설정 - 1 (EC2)

blackzapato — Mon, 7 Oct 2024 15:15:10 +0900

서버 환경 구축 순서

시작에 앞서

인스턴스를 생성하는 이 부분은 뒤에 적을 내용의 흐름이 끊기지 않게만 간단히 적고,

필요한 부분만 캡처와 함께 설명을 덧붙여 넘어가려 한다.

모두가 생성하고 싶은 AMI, 아키텍처, 인스턴스 유형이 각기 다를 거라 생각해 불 필요한 부분인 것 같다.

(테스트용도로만 구성하고 싶으신 분들은 프리티어가 붙은 유형만을 선택해 진행하면 될 것 같다.)

EC2 대시보드 > '인스턴스 시작' 클릭

WEB Server EC2 생성

이름 및 태그 : web-server
애플리케이션 및 OS 이미지(Amazon Machine Image) : Amazon Linux 2023 AMI
아키텍처 : 64(Arm)
인스턴스 유형 : t4g.small
키 페어(로그인) : 없음
네트워크 설정 : (아래 캡처 참조)
스토리지 구성 : 50 GiB gp3
(나머지는 기본값)

나의 경우 Public 환경인 WEB Server EC2의 키 페어 설정을 안 했지만 보안상 키페어를 발급하는걸 추천한다.

네트워크 설정에서 '편집' 클릭

네트워크 설정은 위처럼 세팅한다.

VPC : EC2가 위치해야 할 미리 생성해 둔 VPC
서브넷 : EC2가 위치해야 할 Public subnet
보안그룹 이름 : Public-sg-1
설명: web-server security group

인프라 구축 단계라 유형에서 모든 트래픽 소스 유형은 내 IP를 선택했지만
실제로 사용할 때는 꼭 필요한 프로토콜이나 IP대역을 설정해서 사용해야 한다.

만약, aws console에서만 접속 하고 싶다면 13.209.1.56/29를 ssh 프로토콜로 허용해놓자.
참고사이트

'인스턴스 시작' 클릭

WEB Server EC2 정상 확인

인스턴스가 생성되고 인스턴스 상태가 '실행 중'으로 변경되면

우측 상단 '연결' 클릭 > 'EC2 인스턴스 연결'탭에서 '연결' 클릭

# 외부 인터넷 연결(네이버) 되는지 확인 명령어
curl -v naver.com

위처럼 로그가 나온다면 정상적으로 생성이 완료되었다.

또, 한 가지 더 설정해줘야 할 것이 남았다.

EC2를 생성할 때 이미 퍼블릭 IP를 할당받았지만 이 IP는 고정된 IP가 아니다.

그래서 우리는 탄력적 IP를 이용해서 고정된 IP를 EC2에게 할당해야 한다.

탄력적 IP 할당

왼쪽 메뉴 > 네트워크 및 보안 > 탄력적 IP

해당 메뉴에 들어왔으면 오른쪽 상단에 '탄력적 IP 할당' 클릭

다른 설정 필요 없이 '할당' 클릭

생성된 탄력적 IP 주소를 선택 한 뒤,

오른쪽 상단 '작업' 클릭 -> '탄력적 IP 주소 연결' 클릭

생성한 web-server 인스턴스와 프라이빗 IP 주소를 선택하고 '연결'을 클릭한다.

적용되어 있는 탄력적 IP 주소는 인스턴스 세부정보에서 확인할 수 있다.

WEB Server는 이제 모든 구성이 완료되었다.

이제 WAS Server를 구성해 보자

EC2 대시보드 > '인스턴스 시작' 클릭

WAS Server EC2 생성

이름 및 태그 : was-server
애플리케이션 및 OS 이미지(Amazon Machine Image) : Amazon Linux 2023 AMI
아키텍처 : 64(Arm)
인스턴스 유형 : t4g.small
키 페어(로그인) : (아래 캡처 참조)
네트워크 설정 : (아래 캡처 참조)
스토리지 구성 : 50 GiB gp3
(나머지는 기본값)

키 페어(로그인)

'새 키 페어 생성' 클릭

키 페어 이름 : my-vpc-keypair

'키 페어 생성' 클릭하면

자동적으로 키페어가 생성되어 다운받아지며 키 페어 셀렉트 박스에 자동으로 생성된 값이 선택된다.

다운받아진 키페어 파일은 잘 관리하자 재발급 받을 수 없어 분실되면

새로운 키페어를 생성해서 대체해야 한다.

네트워크 설정에서 '편집' 클릭

네트워크 설정은 위처럼 세팅한다.

VPC : EC2가 위치해야 할 미리 생성해 둔 VPC
서브넷 : EC2가 위치해야 할 Private subnet
보안그룹 이름 : Private-sg-1
설명: was-server security group

인프라 구축 단계라 유형에서 모든 트래픽을 받을 수 있게 선택했지만
실제로 사용할 때는 꼭 필요한 프로토콜이나 IP대역을 설정해서 사용해야 한다.

'인스턴스 시작' 클릭

WAS Server EC2 정상 확인

인스턴스가 생성되고 인스턴스 상태가 '실행 중'으로 변경된 것을 확인하면

'web-server' 인스턴스를 선택 > 우측 상단 '연결' 클릭 > 'EC2 인스턴스 연결'탭에서 '연결' 클릭한다.

우린 분명 was-server인스턴스를 생성했지만

private subnet 공간에 생성해 놓아서 다이렉트로 접속은 못한다.

그래서 우린 web-server를 통해 우회적으로 접속할 것이다.

보통은 bastion, jump server라는 것들을 사용해서 우회적으로 접속하지만
이 글에 aws 아키텍처는 사내 테스트용으로 설계되어 통제된 환경에서 사용하려다 보니
보안적으로는 특별히 신경을 안 써도 되기 때문에 이 부분이 빠져있다.

# root 권한을 얻어오자.
sudo -s

# 키페어 파일을 생성
nano my-vpc-keypair.pem

was-server를 생성할 때 다운로드하였던 키페어를 메모장으로 열어 내용을 모두 복사해서

위의 명령어로 생성된 파일에 붙여 넣자.

이후, 'ctrl' + 'x' > 엔터로 빠져나오자.

# 생성된 파일이 현재 티렉터리 위치해 있는지 확인해보고 기억해두자.
pwd
# 접속한뒤 티렉터리 위치 변경을 안했다면 아마 home/ec2-user/일 것이다.

# 파일 권한 변경
chmod 400 my-vpc-keypair.pem

# RSA 방식으로 my-vpc-keypair.pem을 이용해서 
# ec2-user라는 username과 <was-server private ip>로 ssh 프로토콜을 통해 접속한다는 의미이다.
ssh -i "my-vpc-keypair.pem" ec2-user@<was-server private ip>

접속 중 fingerprint 얘기가 나오면 yes를 선택해 주자.

위처럼 ip가 바뀌었다면 정상적으로 was-server에 접속이 완료된 것이다.

was-server NAT 게이트웨이 정상 연결 확인

# 외부 인터넷 연결(네이버) 되는지 확인 명령어
curl -v naver.com

위처럼 로그가 나온다면 정상적으로 NAT 게이트웨이와 EC2가 위치되어 있는

Private Subnet도 연결이 성공되었다는 의미이다.

추가 EC2 환경 수정

1번의 경우
한번 등록해둔 pem 키페어를 계속 고정으로 사용하기 때문에
긴 명령어를 계속 사용하기도 귀찮은 것을 해결하기 위해 설정한다.

2번의 경우
예를 들어 EC2에 설치되어 있는 Tomcat이나 Jenkins에서 서버 시간을 가져와 로그를 찍어주는 스크립트가 있다면
한국 시간대와 맞지 않는 시간을 찍어 줄 것이기 때문에 설정한다.

[AWS] 인프라 구축 [VPC / Subnet / Routing / IGW / NAT] - 5 (NAT)

blackzapato — Sun, 6 Oct 2024 12:48:22 +0900

인프라 구축 순서

NAT Gateway

Private Subnet에 위치한 EC2 인스턴스가 외부로 데이터를 내보내거나 가져오고 싶을 때
외부로 단방향 통신(내부 -> 외부 방향)을 원할 때 사용하는 서비스이다.

참조 (NAT 게이트웨이)

VPC 대시보드 > NAT 게이트웨이 > 우측 상단 'NAT 게이트웨이 생성' 클릭

NAT 게이트웨이 생성

이름 입력, Public Subnet(my-public-subnet) 선택, '탄력적 IP 할당' 클릭 후 할당 되면

'NAT 게이트웨이 생성' 클릭

이제 NAT 게이트웨이는 생성이 완료 되었다!

외부 인터넷을 연결하고자 하는 서브넷과 연동되어 있는 라우팅 테이블에 연결해 주자

VPC 대시보드 > 라우팅 테이블 > Private Subnet(my-private-subnet-rt) > 하단 '라우팅' 탭 > '라우팅 편집' 클릭

라우팅 편집

Private Subnet과 연동되어 있는 라우팅 테이블(my-private-subnet-rt)에 위와 같이 생성해 두었던 NAT를 선택한 후

'변경 사항 저장' 클릭

이로써 모든 인프라 구축은 완료되었다.

이제 다음글에서 EC2, S3, Aurora Mysql을 이용해 서버 환경을 구축해 보자

[AWS] 서버 환경 구축 EC2, S3, Aurora Mysql 설정

[AWS] 인프라 구축 [VPC / Subnet / Routing / IGW / NAT] - 4 (IGW)

blackzapato — Sun, 6 Oct 2024 12:47:50 +0900

인프라 구축 순서

IGW(Internet Gateway)을 세팅하는 이유

폐쇄망이었던 VPC를 외부와 연동할 수 있게 길을 내주는 작업이다.

VPC 대시보드 > 인터넷 게이트웨이 > '인터넷 게이트웨이 생성' 클릭

인터넷 게이트웨이 생성

생성할 인터넷 게이트웨이 이름 입력 후

'인터넷 게이트웨이 생성' 클릭하면 생성된 후 상세 페이지로 이동되는데

이때, 오른쪽 상단 '작업'에서 'VPC에 연결' 클릭 (페이지 빠져나간 뒤 목록에서 해줘도 됨)

VPC에 연결

연결할 VPC를 선택 후

'인터넷 게이트웨이 연결' 클릭

이제, VPC와 인터넷 게이트웨이가 연결되었다

하지만 여기서 끝이 아니다.

VPC와는 연동이 되었지만 인터넷과 통신을 할 public subnet에 IGW를 연결해줘야 한다.

라우팅 테이블 메뉴 > Public Subnet(my-public-subnet-rt) 선택 > 우측 상단 '작업' > '라우팅 편집'

라우팅 편집

Public Subnet과 연동 되어있는 라우팅 테이블(my-public-subnet-rt)에 위와 같이 미리 생성해 두었던 IGW를 선택한 후

'변경 사항 저장' 클릭