이번 글에서는 개인 프로젝트 진행하면서 CI 구축을 해보고 그 방법과 경험을 작성하려고 한다.

 

우선 AWS 서버가 준비가 된 게 없어서 CD는 나중에 구축할 예정이다.

 


 

GitHub Actions란?

GitHub Actions는 github에서 제공하는 서비스로 빌드, 테스트, 배포까지 CI/CD 자동화를 편리하게 해 준다.

 

 


 

GitHub Actions로 CI 구축하기

우선 내 프로젝트가 이미 깃헙 레포지토리에 올라가 있다는 가정하에 작성하겠다.

 

1. 워크플로우(workflow) 작성

워크플로우란 레포지토리에 사용자가 지정한 이벤트(푸시, 풀, 등...)가 레포지토리에서 발생할 시 트리거되어 동작하는 자동화 프로세스이다.

 

워크플로우는 깃헙에서 제공하는 템플릿이 많으니 굳이 머리 아프게 경로,파일 생성하고 할 필요가 없다.

레포지토리에서 상단 메뉴를 보면 'Actions'라는 메뉴가 보일 거다.

 

 

 

Actions 탭을 눌러보면 여러 가지 템플릿을 보여주는데. 레포지토리에 올라온 프로젝트의 소스를 보고 추천 템플릿을 제공한다.

나는 프로젝트를 Maven을 이용하여 빌드했기 때문에 'Java with Maven'을 선택해 주었다.

 

 

추천 탬플릿들
내가 선택한 템플릿

 

 

 

 

# This workflow will build a Java project with Maven, and cache/restore any dependencies to improve the workflow execution time
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-maven

# This workflow uses actions that are not certified by GitHub.
# They are provided by a third-party and are governed by
# separate terms of service, privacy policy, and support
# documentation.

name: Java CI with Maven

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
    - name: Build with Maven
      run: mvn -B package --file pom.xml

    # Optional: Uploads the full dependency graph to GitHub to improve the quality of Dependabot alerts this repository can receive
    - name: Update dependency graph
      uses: advanced-security/maven-dependency-submission-action@571e99aab1055c2e71a1e2309b9691de18d6b7d6

 

기본으로 생성된 템플릿(maven.yml)은 이렇다.

 


 

위에서부터 하나하나 설명을 하겠다. 

 

1. 이벤트 트리거 설정

on은 무슨 이벤트가 발생했을 때 워크플로우가 트리거 되어 동작할 건지 지정하는 것이다.

나는 master 브랜치에 내 프로젝트를 올려놨으니 master 브랜치에 push나 pull 이벤트가 발생할 경우 동작할 거라 명시했다.

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

 

 

2. 작업 단계 설정

jobs는 여러 스태프로 구성되고 사용자가 지정한 순서대로 동작한다.

 

runs-on은 jobs가 내 워크플로우가 깃헙 Actions에서 제공하는 VM 중 어떤 운영체제를 사용하여 실행되는지 명시하는 것이다.

빌드 환경이 중요한 것이 아니라면 ubuntu-latest를 써도 상관없다.

 

steps는 앞으로 실행될 단계들을 나타낸다.

jobs:
  build:

    runs-on: ubuntu-latest

    steps:

 

 

3.  자바 설치 및 Maven 캐싱

 - uses: actions/checkout@v4

  • @v4는 깃헙 Actions 4 버전 사용한다는 의미이고
  • actions/checkout은 현재 저장소의 코드를 클론 해오는 역할이다.

 

uses : actions/setup-java 액션을 통해 Java 11 환경 구성

with:

  • java-version : '11' 자바 버전은 11을 쓸 것이고
  • distribution : 'temurin' 테무린은 이클립스 재단이 관리하는 오픈 소스 Java SE 빌드이다.  테무린 외에 다른 Java 빌드는 zulu, corretto 등이 있는데 테무린으로 해도 문제는 없다.
  • cache: maven으로 .m2/repository 캐시 적용 (다음 빌드 속도 향상용)

 

    - uses: actions/checkout@v4
    
    - name: Set up JDK 11
      uses: actions/setup-java@v4
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: maven

 

4. 테스트 설정

빌드 전에 간단한 테스트도 진행할 것이다.

run : mvn test  JUnit 등의 단위 테스트를 실행

실패 시 workflow 전체가 실패 처리된다.

굳이 테스트가 필요 없다면 제외하면 된다.

 

    - name: Run tests
      run: mvn test

 

 

4. Maven 빌드 수행

run : mvn -B: batch 모드 (CI에 적합, 불필요한 입력 제거)

package: 프로젝트를 .war 또는 .jar로 패키징함 - 추후 설정 예정

기본적으로 target/ 폴더에 결과물이 생성된다.

 

    - name: Build with Maven
      run: mvn -B package --file pom.xml

 

5. 빌드 결과물 업로드

target/ 디렉터리에 있는 .war 파일을 깃헙 Actions Artifcat로 업로드

    - name: Upload WAR artifact
      uses: actions/upload-artifact@v4
      with:
        name: my-artifact
        path: target/*.war

 

 

 

최종 결과물 

name: myProject - CI with Maven

on:
  push:
    branches: [ "master" ]
  pull_request:
    branches: [ "master" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 11
      uses: actions/setup-java@v4
      with:
        java-version: '11'
        distribution: 'temurin'
        cache: maven
        
    # Testing    
    - name: Run tests
      run: mvn test
      
    # Building
    - name: Build with Maven
      run: mvn -B package --file pom.xml

    # Upload war file
    - name: Upload WAR artifact
      uses: actions/upload-artifact@v4
      with:
        name: my-artifact
        path: target/*.war

 

 


 

 

워크플로우 작성이 끝났다면 내 레포지토리에 test.text 파일과 같은 임시 파일을 만들어서 push 해보면 잘 동작하는지 확인할 수 있다. 

 

빌드 성공할 경우 V 초록색 아이콘이 보일 것이고 실패할 경우 X 빨간색 아이콘이 보일 것이다.

 

 

실패한 빌드를 클릭하여 들어가 보면 왜 실패했는지 오류 로그가 싹 나오니 오류 내역을 보고 하나하나 해결하면 결국 성공할 것이다.

 

성공한 빌드를 클릭하면 Artifacts라는 항목이 아래에 보일 것이다.

Artifact 위치

 

아티팩트 옆에 다운로드 아이콘을 누르면 빌드된 war 파일을 받을 수 있다.

 

 


 

 

이것으로 GitHub Actions를 이용한 CI 구축 방법에 대해 적어봤다. 나중에 시간이 나면 AWS EC2에 CD까지 구축하는 방법에 대해 작성해 보겠다.

블로그 이미지

Ahan

책, 영화, 게임! 인생의 활력 요소가 되는 취미들을 하자!

,

최근 AWS에 대해서 공부 중이며 내가 공부한 여러가지 디자인 패턴에 대해서 작성할려고 한다.

 

이번 글에서는 다소 복잡한 웹사이트의 예로 AWS를 사용한 기업 웹사이트 구축 패턴에 대해 공부한걸 작성해 보겠다.

 

 


기업 웹사이트 개요 :

  1. 공개 웹사이트로 사용자는 거래처, 잠재거 고객, 입사지원자 등이다.
  2. 정적 콘텐츠 중심이다. (CSS, HTML, 이미지 파일 등)
  3. 서버를 다중화하여 장애에 대비한다.
  4. 부하가 높아지면 서버를 추가할 수 있게 구성한다.
  5. 장애 서버의 교체, 추가는 수동으로 조작한다.
  6. 응답시간과 비용을 고려하여 구성한다.

 

인프라 핵심 :

  1. 웹 서버 다중화 : 이벤트 사이트를 구동시킬 최적의 리전을 선택한다.
  2. DB 서버 다중화 : 소규모 웹서버에 맞는 EC2 인스턴스를 설정한다.
  3. CDN과 객체 저장소를 사용한 정적 콘텐츠 전송 : 웹 서버로의 접속을 줄여 운용 비용을 절감한다.
CDN(Content Delivery Network, 콘텐츠 전송 네트워크)은 지리적인 제약 없이 전 세계 사용자에게 빠르고 안전하게 컨텐츠를 전송할 수 있는 기술을 의미한다. 단순하게 얘기하자면 이미지 파일같은 용량이 큰 컨텐츠는 요청이 들어올때마다 서버에서 다운로드 받는것보다. 사용자의 위치에서 가까운 서버에서 캐싱된 컨텐츠를 가져와 빠르고 저렴하게 서비스를 제공해주는 것이다. AWS에서는 Cloudfront 서비스를 통해 제공 받을 수 있다.

기업 웹사이트 구성도

 

이전 패턴(이벤트 사이트)과 똑같이 서버를 구성하는 가장 기본적인 서비스는 가상 서버인 EC2(Amazon Elastic Computer Cloud)와 가상 스토리지 볼륨인 EBS(Amazon Elastic Block Store)로 구성한다.

 

웹서버는 로드 밸런서를 사용하여 다중으로 구성한다. 로드밸런서 기능을 제공하는 AWS 서비스는 ELB(Elastic Load Balancing)이다.

 

DB 서버는 RDB의 관리형 서비스인 RDS(Amazon Relational Database Service)로 구성한다. RDS는 이미 세팅이 완료된 RDBMS환경을 제공하는 서비스이며 설정만으로도 다중화가 가능핟.

 

정적 컨텐츠 전송에 이용하는 CDN 서비스는 위에서 잠깐 얘기한 클라우드프론트(Clouldfront)이고, 객체 저장소 서비스는 S3(Amazon Simple Storage Service)이다. CDN을 사용하면 전세계에 배치된 서버를 통해 웹 접속을 캐시하거나 분배할 수 있고, 또한 응답 속도를 높이거나 웹서버로의 접속을 줄여주어 비용 절감에 도움이 된다. S3 저장소는 객체 단위로 데이터를 다루는 스토리지로서 REST API를 사용하여 데이터의 입출력을 수행한다.

 

ELB를 이용하여 웹 서버 다중화

다중화를 위해서는 웹 서버를 여러 대를 구축해야한다.

이벤트 사이트에서 EC2 인스턴스를 구성하는 방법과 동일한 방법으로 인스턴스를 작성하고, 웹 서버 환경 구축하고, OS 환경을 셋업하고, 필요한 SW를 설치하는 것을 여러번 반복해도 되지만 이것은 시간이 오래 걸린다.

 

이를 해결하기 위해 있는것이 AMI(Amazon Machine Images)이다. 완성된 인스턴스의 이미지를 저장하는 방식으로 AMI를 만들고, 이 AMI를 이용하여 동일한 구성의 EC2 인스턴스를 여러개 만들 수 있다.

 

필요한 수의 웹 서버를 만든 후에는 ELB와 연계한 다중화 구성을 한다. ELB를 웹 트래픽의 입구로 사용하여 트래픽이 복수의 웹 서버에 분산되어 부하를 줄이도록 구성한다. 

 

ELB에 의한 부하 분산 설정(EC2 - ELB - 인터넷 연결 설정)은 다음과 같이 설정한다 :

우선 인터넷 접속 엔드포인트를 ELB로 지정한다. ELB는 IP 주소가 아닌 CNAME(대체 도메인명)을 지정하여 접속.

ELB의 IP 주소는 고정이 아니라 계속 변하기 때문이다. DNS 서버인 Route53을 이용하여 ELB의 CNAME과 사용할 도메인 이름을 연결한다. 이러한 설정에 의해 사용자는 도메인 이름을 통해 ELB에 접속할 수 있게 된다.

 

다음은 ELB와 웹 서버의 EC2 인스턴스를 연결시킨다. ELB 작성 페이지에 웹 서버를 선택하는 항목을 찾아서 이미 만들어진 웹 서버를 선택한다. 이것으로 ELB를 활용한 부하 분산 설정이 끝이다.

 

 

- ELB 설정 시 유의 사항

 

ELB 설정할 때 주의해야 할 다섯 가지 

 

1. ELB용과 웹 서버용으로 각각 다른 보안 그룹을 마련한다.

- ELB는 인터넷 어디에서라도 HTTP/HTTPS 접속을 허용하도록 설정되어 있다. 반면에 웹서버는 ELB로 부터 HTTP 요청만을 받아들이도록 트래픽 소스를 ELB가 속한 보안그룹으로 한정되어야 한다.

EC2 인스턴스 보안 그룹 인바운드 설정
타입 프로토콜 포트 범위 소스
HTTP TCP 80 10.0.0.24/24 (ELB 보안 그룹)

 

ELB 보안 그룹 인바운드 설정
타입 프로토콜 포트범위 소스
HTTP TCP 80 0.0.0.0/0
HTTPS TCP 443 0.0.0.0/0

 

ELB 리스너 설정
로드밸런서 프로토콜 로드밸런서 포트 인스턴스 프로토콜 인스턴스 포트
HTTP 80 HTTP 80
HTTPS 443 HTTP 80

 

2. 세션 유지 기능의 유무 확인

- 최근 웹사이트는 세션 유지 기능을 이용해 복잡한 기능을 지닌 애플리케이션을 제공하는 경우가 있다. 그때 세션 정보를 웹 서버 간에 공유하는 구조를 마련하지 않으면 동일한 클라이언트 접속을 항상 같은 웹 서버에 유지시켜야만 한다. ELB는 ELB 자신이 작성하는 쿠키 저보를 바탕으로 동일한 서버로 접속을 유지시키는 세션 유지 기능을 제공한다. AWS 콘솔에서 설정할 수 있으므로 필요에 따라 사용해야한다.

 

3. HTTPS 처리

- HTTPS 통신은 클라이언트와 서버 간의 통신을 암호화 한다. ELB는 SSL 터미네이션이라고 하는 SSL 인증서 확인 및 암복호화 처리 기능을 제공한다. ELB 리스너 설정에서 로드밸런스 프로토콜을 HTTPS로 인스턴스의 프로토콜을 HTTP로 하면 자동적으로 적용된다. 웹 서버별로 SSL 인증서를 관리할 필요가 없어질 뿐만 아니라, SSL 복호화 처리에 걸리는 부하가 줄어들어 EC2 비용을 줄일 수 있다.

 

4. 헬스 체크

- 웹 서버가 정상적으로 동작하는지 감시하는 기능을 헬스 체크라 한다. 기본 설정에서는 간격이 30초, 타임 아웃이 5초, 비정상 상한치가 2회이다. 웹 서버에 장애가 발생하면 40초에서 70초 만에 감지하여 해당 서버를 분리한다. 너무 짧게 설정하면 웹 서버의 부하가 높아져 응담이 저하되는 상태를 고장으로 오판하여 서버가 분리되어 버린다. 반대로 너무 길면 오류가 발생하는 웹 서버에 요청 배분을 계속하게 된다. 기본 설정으로도 충분하지만 성능 시험이나 운영 시 검출 오작동이 발생한다면 수치를 조정하면 된다.

 

5. 타임아웃 설정

- 응답시간에 따른 타임아웃 설정을 한다. 웹 서버에 분산시킨 후 일정시간 응답이 없으면 ELB는 웹 서버와의 접속을 절단하고, 클라이언트에 HTTP 504를 반환한다. 타임 아웃 시간은 접속 설정의 타임아웃으로 설정하며, 초기 설정 값은 60초이다. DB 처리 등으로 시간이 오래 걸리더라도 결과를 반환하고 싶다면 시간을 길게 설정한다.

 

RDS를 이용하여 DB 서버 다중화

AWS에서 RDB를 구성하는 방법은 크게 두 가지이다. 

EC2인스턴스에 RDBMS를 설치하는 방법과, 관리형 서비스인 아마존 RDS를 이용하는 방법이다.

전자는 OS와 RDBMS를 자유롭게 선택하고 설정할 수 있는 반면, OS와 DB환경을 사용자가 직접 관리하지 않으면 안 된다. 후자는 패치 적용과 백업이 자동화되어 있기 때문에 운영의 번거로움이 줄어든다.

이용 목적에 맞는 방법을 선택하면 된다.

 

이번에는 RDS 이용을 전제로 한다. AWS에서 제공하는 RDS 엔징으로는 오라클, SQL Server, MySQL, PostgreSQL, Aurora등 다양한 엔진이 존재한다. 어떤 RDS를 사용해도 문제는 없지만, 예시로 MySQL를 사용한다. MySQL은 웹 애플리케이션과 함꼐 사용되는 경우가 많아 찾아 볼 수 있는 기술 정보가 많다.

 

DB 서버의 다중화는 'Active-Standby(활성-대기' 구성을 선택했다. DB 서버는 데이터의 일관성을 유지하고자 실행 서버를 시스템 안에서 하나로 구성하는 것이 일반적이다. RDS의 멀티-AZ 기능을 사용하면 활성 DB 서버(마스터)의 데이터를 대기 서버(스탠바이)에 동기화하는 복제 중복 구성을 쉽게 구축할 수 있다.

 

멀티-AZ 기능을 사용한 RDS 설정 방법은 다음과 같다.

 

 

매니지먼트 콘솔의 RDS 설정 화면에서 DB 서브넷 그룹을 작성한다. DB 서브넷은 두 가용 영역(AZ)에 각각 서브넷을 만들고 이것을 그룹화해서 만든다 (위의 그림처럼) . 두 AZ를 사용해 서브넷을 만드는 이유는 하나의 AZ가 예상치 못한 재해로 멈추더라도 또 다른 AZ에 설치된 서브넷에 서버가 계속 동작하도록 하기 위함이다.

 

다음은 RDS for MySQL의 인스턴스를 작성한다. 이때 멀티-AZ를 이용하는 옵션을 선택하고 방금 만든 DB 서브넷 그룹을 지정한다. 

 

이것으로 마스터와 스탠바이 2대 구성의 DB 서버(RDS 인스턴스)가 만들어 졌다. 마스터유저가 자동으로 생성되므로 이를 통해서 애플리케이션 사용자를 만들거나 객체, 그리고 데이터를 관리할 수 있다. 마스터와 스탠바이가 복제되어 있기 때문에 마스터에 장애가 발생해도 데이터는 손실되지 않으나, 2대의 RDS 인스턴스가 동시에 작동하기 때문에 2배의 비용이 발생한다.

 

마스터 DB 서버에 장애가 발생하면 스탠바이가 마스터로 승격되고 기존 마스터 서버가 사용하던 서브넷에 스탠바이 서버가 새롭게 만들어진다. 이러한 일련의 작업은 자동으로 이루어지기 때문에 별도의 작업은 필요 없으나, DB 접속은 장애 복구 이후 자동으로 연결되도록 사전에 설정해주어야 한다.

 

- RDS 사용 시 유의 사항

RDS 사용시 유의사항에 대해 적어본다.

 

첫 번째로 적절한 스냅샷을 생성해야 한다. RDS는 자동 백업과 수동 스냅샷 백업 방법을 지원한다. 자동 백업은 간편하지만 데이터 보존 기간에 제한이 있다. 기본 설정값은 1일, 최대로 35일이다. 시스템에 대한 백업을 영구적으로 저정하려면 스냅샷이 더 적합하다.

 

두 번째는 AWS에 의한 정기정검이다. RDS는 몇 달에 한 번꼴로 마이너 버전업이 자동으로 실행되어, 약 30분간 정지된다. 옵션으로 마이너 버전 자동 업그레이드를 비활성화하면 마이너 버전업은 수행이 되지 않는다. 하지만 취약점 대응 등에 위한 강제 업그레이드가 이루어지는 경우도 있으니 주의하자. 

 

마지막으로 멀티-AZ를 이용하면 데이터 갱신 처리에 드는 시간이 길어진다. 마스터에 업데이트한 데이터를 스탠바이에 동기화시키는 처리가 끝날 때까지 마스터는 다음의 처리를 실시할 수 없다. 이용 환경이나 처리내용에 따라 다르지만 대체로 20~50% 정도 업데이트 처리 시간이 길어진다.  

 

정적 콘텐츠를 낮은 비용으로 배포하기

방문자가 많은 시스템에서는 이미지와 동영상, 자바스크립트, HTML, CSS 등의 정적 콘텐츠 제공에 많은 비용이 들게 된다. 대량의 트래픽을 처리하려면 고성능 웹 서버가 여러 대 필요하게 되는데, 이렇게 되면 EC2에서 다운로드 통신량이 늘어나서 비용이 증가된다. 이때 정적 콘텐츠 전달 비용을 줄이려면 클라우드프론트와 S3를 사용하면 된다.

 

클라우드프론트는 위에서 말한거처럼 AWS에서 제공하는 CDN이다. 사용자가 요청한 콘텐츠가 캐싱되어 있으면 웹 서버와 DB 서버에 접속하지 않으므로 서버의 부하를 낮춰 비용을 절감할 수 있다. 

 

클라우드프론트뿐만 아니라 정적 콘텐츠를 S3에 두는 방법을 함께 사용하면 더욱 웹 서버의 부하를 줄일 수 있다. S3에 파일을 저정하면 파일 단위로 접속용 URL이 생성된다. 이것을 이용해 정적 콘텐츠 저장소로 사용한다. S3 요금 체계는 EC2 보다 낮게 설정되어 있기 때문에 정적 콘텐츠를 S3에 배치하는 것이 좋다.

 

자세한 설정 방법은 아래의 블로그를 참조하면 좋다.

 

https://bigco-growth-diary.tistory.com/6

 

CloudFront와 S3 연결

안녕하세요 :) 오늘은 CloudFront와 S3 버킷을 연동하는 실습을 진행하겠습니다. [순서] 1. S3 생성 2. CloudFront 배포 3. S3권한 설정 4. 완료 1.S3 생성 우선 CloudFront와 연동시킬 S3버킷을 생성해 줍니다. 객

bigco-growth-diary.tistory.com

 

 

기업 웹사이트에 적합한 인스턴스 설계

기업 웹사이트에 적합한 인스턴스는 다음과 같은 요구사항이 있다.

1. 안정적인 응답

2. 몇 년 단위로 장기 이용

 

요구사항 1에 대응하려면 성능이 안정된 EC2 인스턴스와 EBS 볼륨을 선택해야 한다. 

요구사항 2에 대응하려면 장기 이용을 약정하여 할인받을 수 있는 EC2 인스턴스가 적합하다.

 

성능의 안정성과 관련해서는 스토리지 I/O 대역폭에 주의해야한다. EC2 인스턴스와 EBS 볼륨 사이는 다른 사용자와 공유하는 네트워크로 연결되어 있다. 트래픽이 대역폭의 한계치에 이르게 되면 스토리지에서 데이터를 읽는 데 시간이 걸리고 응답도 불안정해진다. 다양한 네트워크 대역폭이 있지만, 운용 초기에는 성능이 낮은 인스턴스를 설정하고, 부족하면 서능이 높은 인스턴스 타입으로 변경하여 이용하면 좋다.

 

또한 안정을 중시하는 경우에는 다음의 두 가지 옵션의 사용을 고려해보면 좋다. 첫 번째는 EC2 인스턴스의 옵션인 'EBS 최적 인스턴스'이다. 이 옵션을 사용하면 EC2 인스턴스에서 EBs 볼륨까지 네트워크 대역폭을 보장받을 수 있다. 인스턴스 타입에 따라 이 옵션의 지원 여부가 달라진다. 

 

EBS 최적 인스턴스

 

또 한 가지 옵션은 '프로비저닝된 IOPS'이다. 프로비저닝된 IOPS를 사용하는 경우, 안정적으로 1만 IOPS이상의 I/O를 보장 받을 수 있다. 

2023년 이후에 생성된 모든 io2볼륨은 프로비저닝된 IOPS를 제공한다. 

https://docs.aws.amazon.com/ko_kr/ebs/latest/userguide/provisioned-iops.html

 

Amazon EBS 프로비저닝된 IOPS SSD 볼륨 - Amazon EBS

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

docs.aws.amazon.com

 

성능을 안전시키려면 EBS 최적화를 이용하면 되고, 피크 시 성능을 높이려면 EBS 최적화와 프로비저닝된 IOPS를 모두 사용하면 된다.

 

요구사항 2에 대응하려면 장기 이용에 따른 할인 혜택을 받기 위해 예약 인스턴스(RI) 사용을 검토하면 된다. EC2 인스턴스 과금 체계 중에서 사용한 만큼 비용을 지불하는 온디맨드 인스턴스가 기본적으로 선택이 된다. 예약 인스턴스는 1년 또는 3년의 기간을 정하여 사용을 예약하면 된다. 

 

https://velog.io/@c17an/%EC%98%88%EC%95%BD-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EC%99%80-%EC%8A%A4%ED%8C%9F-%EC%9D%B8%EC%8A%A4%ED%84%B4%EC%8A%A4%EB%A1%9C-EC2-%EB%B9%84%EC%9A%A9-%EC%A0%88%EA%B0%90%ED%95%98%EA%B8%B0

 

예약 인스턴스와 스팟 인스턴스로 EC2 비용 절감하기

경우에 따라 EC2 인스턴스를 보다 저렴하게 사용할 수 있는 방법들을 소개합니다.

velog.io

 

 

예약 인스턴스는 취소할 수 없으므로, 이용률이 낮아지면 온디맨드와 비교하여 오히려 비싸지게 되니. 잘 고려해서 선택해야한다.

 

 

 

블로그 이미지

Ahan

책, 영화, 게임! 인생의 활력 요소가 되는 취미들을 하자!

,

최근 AWS에 대해서 공부 중이며 내가 공부한 여러가지 디자인 패턴에 대해서 작성할려고 한다.

 

이번 글에서는 사용자 수가 많지 않고 짧은 기간만 서비스하는 이벤트 사이트 패턴에 대해서 써 보겠다.

 

이벤트 사이트는 일반 소비자를 대상으로 일시적으로 운용할 소규모 웹 서버를 설계하는 걸 목표로 한다.

 


이벤트 사이트(소규모 웹 서버) 개요 :

  1. 1개월 한정으로 이용한다.
  2. 사이트의 사용자는 개인 사용자로서 인터넷으로 접속한다.
  3. 접속자 수는 많지 않아 고사양 서버는 필요 없다.
  4. 웹 서버로 LAMP(Linux, Apache, PHP, MySQL) 환경을 사용한다. (다른 환경도 가능하다.)
  5. 비용을 우선하며 다중화나 백업은 고려하지 않는다. (일회성)

 

인프라 핵심 :

  1. 리전 선택 : 이벤트 사이트를 구동시킬 최적의 리전을 선택한다.
  2. EC2 인스턴스 설정 : 소규모 웹서버에 맞는 EC2 인스턴스를 설정한다.
  3. 도메인을 통한 접속 : 고정 IP 주소로 접속한다. (CNAME을 설정해 도메인 이름으로도 가능하게 한다.)
  4. 네트워크 구성 : 인터넷 접속을 위한 간단한 네트워크 구성을 설정한다.
  5. OS 환경 설정 :  아마존 리눅스에서 LAMP 환경을 설정한다.

 

이벤트 사이트 구성도

 

서버를 구성하는 가장 기본적인 서비스는 가상 서버인 EC2(Amazon Elastic Computer Cloud)와 가상 스토리지 볼륨인 EBS(Amazon Elastic Block Store)로 구성한다.

 

네트워크에 필요한 서비스는 VPC(Virtual Private Cloud)와 같은 기본 서비스에 포함되어 있다. 예시로 VPC의 내부에 가상 라우터를 설치할 수 있고, Route53(Amazon Route 53)을 사용하면 도메인(호스트명)으로 DNS 기능도 제공할 수 있다.

 

리전 선택 및 네트워크 구성

- 리전에 따른 응답 속도와 비용차이

 

서비스 구축 시 가장 먼저 해야 하는 것은 바로 서버가 위치할 리전을 선택하는 것이다.

 

응답 속도는 AWS 데이터 센터와 일반 사용자가 지리적으로 가까울수록 빠르며 멀수록 느려진다.

국내에 거주하는 사용자를 대상으로 하는 이벤트 사이트의 경우 응답 속도를 빠르게 하고 싶다면 서울 리전을 선택하면 된다.

 

비용은 리전에 따라 다르게 책정된다. 예시로 EC2 타입 중 하나인 t2.micro의 경우

서울 리전의 온디맨드 비용이 시간당 0.0162 달러, 미국 서부 리전은 0.0156 달러로 차이가 나며 데이터 전송 요금도 차이가 난다.

응답 속도보다 비용이 중요하다면 더욱 싼 리전을 찾아보면 된다.

 

 

 

서비스를 시작하고 나면 리전 변경에 손이 많이 가기 때문에 신중해야한다.

 

- 네트워크 구성 

 

리전을 정했으면 VPC와 서브넷을 구성하는 가상 네트워크를 작성한다.

VPC는 논리적으로 격리된 사용자 전용 네트워크 구역을 의미한다. 복수의 가용 영역(AZ, Availability Zones)에 걸친 형태로 VPC 하나를 작성할 수 있다.

하지만 복수의 리전에 걸쳐서 작성할 수 없으니 주의한다.

 

 서브넷은 VPC를 논리적으로 분리한 서브네트워크로 AWS 환경 내의 네트워크 최소 단위이다.

서브넷은 단일 AZ 안에서만 작성된다. 

 

VPC, AZ, 그리고 서브넷의 관계

 

 

서브넷을 나누는 방법은 온프레미스 환경과 다른게 거의 없다. 논리적인 네트워크를 설게해서 AWS의 서브넷 구성에 대입시키면 된다. 예를 들어 인터넷으로 HTTP 수신이 가능한 웹 서버와, 웹 서버로부터 데이터베이스 접속만 허가하는 데이터베이스 서버는 필터링 정책이 다르기 때문에 서브넷을 분리해야 한다.

 

 

EC2 인스턴스 작성하기

VPC와 서브넷 설정을 완료하고 나서 이벤트 사이트의 웹 서버가 되는 EC2 인스턴스를 작성해야한다.

LAMP로 구성하기로 했으니 EC2 이미지중 Amazon Linux  AMI를 사용한다. 가상화 타입으로는 완전가상화인 HVM과 반가상화인 PV가 있는데, 보통은 HVM을 선택한다. (HVM 성능이 더 좋다)

 

인스턴스 유형은 서버 규모에 해당하며, CPU, 메모리, 스토리지, 네트워크 성능의 조합을 할 수 있다. 

하지만 메모리만 늘린다든지 세세한 사용자 정의는 할 수 없다.

 

그러므로 목적에 가장 가까운 인스턴스 유형을 선택해야 하는데, 작은 LAMP 환경이라면 OS에 약 1GB, MySQL 등의 미들웨어에 1GB정도만 있으면 된다.

 

인스턴스 유형 예시

 

네트워크 및 셧다운 동작 설정 주의 사항

인스턴스 유형을 정했다면 다음은 EC2 인스턴스 설정을 해야한다.

주요 포인트만 몇가지 적겠다.

 

네트워크는 VPC를 선택한다. (기본으로 설정된다)

퍼블릭 IP 주소를 자동할당은 비활성화 해준다. 활성화하면 동적 퍼블릭 IP 주소가 부여되면 EC2 인스턴스가 다시 시작할 때마다 자동으로 변경됨으로 IP주소나 DNS를 다시 지정해주어야만 한다. 

 

EC2 인스턴스를 정지하는 경우의 종료동작 설정도 해줘야한다. 셧다운 동작에는 중지(Stop)와 종료(Terminate)가 있다.

중지를 선택하면, 셧다운 시에 OS가 정지되며 OS 이미지가 보존되고 재시작하면 같은 상태로 시작한다.

종료를 선택하면 OS 정지와 동시에 EC2 인스턴스가 삭제된다. 고급설정에 종료동작을 설정할 수 있으니 확인해 준다.

 

 보안그룹 설정

EC2 설정의 마지막 단계는 보안 그룹 설정이다.

보안 그룹은 OS레벨에서 네트워크 통신 필터링 룰을 정하는 것으로 허가할 프로토콜을 설정한다.

 

보안그룹 Source의 초기 설정 값이 Anywhere(0.0.0.0/0) 되어 있는데. 이는 모든 IP 주소로부터의 SSH 접속을 허가한다는 의미이다. SSH의 Source값을 집 또는 회사의 퍼블릭 IP 로 설정한다.

 

이벤트 사이트의 웹 서버는 사용자로부터 HTTP/HTTPS 접속을 허가할 필요가 있다.

이때는 어떤 IP에서든 접속 할 수 있게 0.0.0.0/0으로 설정한다. 

 

Type Protocol Port Range Source
SSH TCP 22 집 또는 회사의 퍼블릭 IP
HTTP TCP 80 0.0.0.0/0
HTTPS TCP 443 0.0.0.0/0

 

 

예시

 

고정 IP와 호스트명 설정

EC2 인스턴스를 생성했지만, 아직은 인터넷으로 EC2에 접속할 수 없다.

인터넷으로 접속하려면 고정된 퍼블릭 IP주소와 FQDN(호스트명)이 있어야 한다.

고정 퍼블릭 IP 주소를 AWS에서는 EIP(Elastic IP)라고 부른다.

 

EIP를 포함한 서비스 설정 변경과 추가는 매니지먼트 콘솔에서 한다. EIP 설정은 콘솔을 통해 EC2 서비스로 들어가 '네트워크 및 보안 > 탄력적 IP > 탄력적 IP 주소 할당' 을 클릭하여 설정한다.

자세한건 아래의 블로그를 참조하면 되겠다.

 

https://any-ting.tistory.com/71

 

[AWS] 고정 아이피(Elastic IP) 생성 및 설정

- 개요 안녕하세요. 이번 시간에는 AWS Elastic IP(탄력적 아이피)에 대해 알아보겠습니다. 탄력적 아이피는 EC2 인스턴스에 고정 아이피를 설정할 때 사용됩니다. EC2 인스턴스를 상태가 중지 상태에

any-ting.tistory.com

 

 

고정 IP를 할당 받았다면 도메인을 설정할 차례이다.

AWS는 Route53이라는 DNS 서비스를 제공한다. 

도메인 취득 방법은 아래의 블로그를 참조하면 된다.

 

https://any-ting.tistory.com/84

 

[AWS] Route53 도메인 구매(등록)

- 개요 안녕하세요. 이번 시간에는 AWS 도메인을 구매하는 방법에 대해 알아보겠습니다. 기본적으로 AWS 계정이 필요합니다. (이 글을 보시는 분들은 있으시겠죠? :>) 도메인 DNS에 대해서는 따로 설

any-ting.tistory.com

 

이후 Route53과 EC2 연결은 아래의 블로그 글을 참고하면 된다.

https://dogfoottech.tistory.com/257

 

[AWS] 도메인과 서버(EC2) 연결하기

서비스를 배포하기 위해서는 도메인이 필수입니다 도메인을 통해 IP로는 나타낼 수 없는 자신의 서비스에 대한 아이덴티티를 도메인을 통해 나타내는 것은 물론 사용자들도 편하게 서비스에 접

dogfoottech.tistory.com

 

 

VPC 설정으로 인터넷 접속 설정

인터넷에 접속하려면 한가지 더 설정을 해야한다. AWS에서는 VPC 이용이 필수이다.

VPC는 AWS 데이터 센터 내부에 마련된 가상의 폐쇄 네트워크이며 외부와 통신할 수 있도록 설정해야 한다.

이벤트 사이트는 기본 설정에서 두 군데만 수정하면 된다.

 

첫 번째는 VPC와 DNS 관련 설정이다. VPC 설정 화면에서 DNS 관련 설정을 켜준다.

 

 

두 번쨰는 라우팅 설정이다. 라우팅 테이블에 인터넷 게이트웨이가 설정되어 있지 않으면 인터넷 접속이 불가능하다. VPC 설정화면에서 라우팅 테이블에서 0.0.0.0/0과 igw로 시작하는 인터넷 게이트가 없다면 생성해준다.

 

이 블로그 글을 보면 도움이 될 것이다.

 

https://velog.io/@chchaeun/AWS-%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C-%EA%B5%AC%EC%B6%95-2-VPC-%EA%B5%AC%EC%B6%95%EC%84%9C%EB%B8%8C%EB%84%B7-%EB%9D%BC%EC%9A%B0%ED%8C%85-%ED%85%8C%EC%9D%B4%EB%B8%94-%EC%9D%B8%ED%84%B0%EB%84%B7-%EA%B2%8C%EC%9D%B4%ED%8A%B8%EC%9B%A8%EC%9D%B4

 

AWS 클라우드 구축 (2) - VPC 구축(서브넷, 라우팅 테이블, 인터넷 게이트웨이)

2021. 07. 25 Post PROJECT 가상의 고객사 시스템 구축과 운영 SI AWS 클라우드 환경 구성 쿠버네티스 기반 EKS 환경 구성, 웹서비스 구축 SM 로그 수집을 위한 EFK Stack 구축 CloudWatch 알람을 Slack

velog.io

 

 

OS 환경 설정

이 블로그 글을 참고하면 될거 같다.

https://strong-ming.tistory.com/3

 

AWS 패턴 구축(1.LAMP 환경 구축/리소스 유연하게 변경하기)

AWS-SAP 공부와 실습을 같이 하면 좋을 것 같아서 '배워서 바로 쓰는 14가지 AWS 구축 패턴' 책을 통해 14가지 패턴을 구축하고자 한다. 패턴1_웹 시스템_이벤트 사이트 1.개요 - 1개월 한정 - 사이트 사

strong-ming.tistory.com

 

 


 

 

마지막으로 이벤트 사이트의 사용기간이 끝났으면

 

EC2 인스턴스를 종료하여 삭제처리 해주어야 추가 비용이 청구되지 않는다.

 

EIP는 EC2와 연결되어 있을 때만 과금이 된다.

 

Route 53dms 존 단위로 월정액이 과금되니 사용하지 않는다면 삭제할 필요가 있다.

 

VPC는 유지 자체는 비용이 들지 않으니 제거할 필요 없다.

 

 

 

블로그 이미지

Ahan

책, 영화, 게임! 인생의 활력 요소가 되는 취미들을 하자!

,

 

네트워크 가상화(Network Virtualization)는 물리적인 네트워크 자원을 논리적으로 분리하고 추상화하여,
여러 개의 가상 네트워크를 하나의 물리 네트워크 위에 생성하고 운영할 수 있게 하는 기술입니다.

 

 

간단히 말해서:

  • 물리적인 네트워크 장비(스위치, 라우터 등)를 직접 다루지 않고,
  • 소프트웨어적으로 여러 개의 가상 네트워크 환경을 만들어
  • 각기 다른 용도로 독립적이고 유연하게 사용할 수 있게 해줍니다.

주요 특징:

  • 유연성: 네트워크 구성 변경이 쉬움
  • 보안성: 서로 격리된 가상 네트워크 제공
  • 비용 절감: 물리 장비 최소화
  • 자동화: 클라우드 환경에서 자주 사용됨 (예: AWS VPC, VMware NSX 등)

 

1. 사례

클라우드 환경 (AWS, Azure, GCP 등)

  • AWS VPC (Virtual Private Cloud): 사용자가 가상 네트워크를 직접 설계하고 라우팅, 방화벽 등을 설정 가능.
  • Azure Virtual Network, Google Cloud VPC도 유사하게 작동.
  • 서로 다른 사용자나 서비스가 완전히 분리된 네트워크 환경을 가질 수 있음.

데이터센터 내 네트워크 분리

  • 기업 내부 데이터센터에서 부서별로 가상 네트워크를 생성해 트래픽을 분리하고, 보안 영역을 나눔.
  • 예: 개발팀, 보안팀, 운영팀 각각의 가상 네트워크 운영.

가상 데스크탑 인프라 (VDI)

  • 여러 사용자가 동일한 서버를 사용하지만, 네트워크적으로는 서로 완전히 분리된 환경에서 동작.
  • VMware Horizon, Citrix Virtual Apps & Desktops 등.

2. 대표적인 기술 종류

VLAN (Virtual LAN)

  • 가장 오래된 가상화 기술 중 하나.
  • 같은 스위치 내에서도 포트를 그룹 지어 네트워크를 논리적으로 분리함.

VXLAN (Virtual Extensible LAN)

  • VLAN의 확장판으로, 대규모 클라우드 환경에 적합.
  • 기존 VLAN의 한계를 극복해, 최대 1,600만 개 이상의 네트워크를 지원.

SDN (Software-Defined Networking)

  • 네트워크를 소프트웨어적으로 제어할 수 있게 해주는 아키텍처.
  • OpenFlow 같은 프로토콜을 통해 중앙에서 네트워크 장비를 제어.
  • 컨트롤 플레인데이터 플레인을 분리.

NFV (Network Functions Virtualization)

  • 방화벽, 로드 밸런서, 라우터 등 전통적인 네트워크 장비의 기능을 소프트웨어로 가상화.
  • 클라우드 또는 범용 서버에서 네트워크 기능을 제공함.

Overlay 네트워크

  • 기존 물리 네트워크 위에 소프트웨어로 별도의 네트워크를 구성.
  • VXLAN, GRE, GENEVE 같은 터널링 기술 사용.
  • 컨테이너 환경(Docker, Kubernetes 등)에서도 많이 쓰임.

 

                      네트워크 가상화 개념 도식

 

┌────────────────────────────────────────────┐
│                                    물리적 네트워크 인프라                                       │
│                            (서버, 라우터, 스위치 등 실제 장비)                             │
└────────────────────────────────────────────┘
                                                       │
                      ┌────────────┼────────────┐
                      │                               │                                │
                      ▼                              ▼                             ▼
    ┌────────────┐┌────────────┐┌────────────┐
    │ 가상 네트워크 1     ││ 가상 네트워크 2    ││ 가상 네트워크 3     │
    │ (예: 개발망)            ││ (예: 운영망)           ││ (예: 보안망)           │
    └────────────┘└────────────┘└────────────┘
                          │                             │                              │
                           각각 독립된 라우팅, 보안 정책, 주소 체계

설명:

  • 물리 네트워크: 실제 하드웨어 기반의 네트워크 인프라.
  • 가상 네트워크: 논리적으로 분리된 네트워크 그룹들. 실제로는 같은 물리 장비를 쓰지만, 서로 완전히 독립적으로 동작함.
  • 각각의 가상 네트워크는 **다른 팀이나 목적(보안, 테스트 등)**을 위해 나눌 수 있음.

 

블로그 이미지

Ahan

책, 영화, 게임! 인생의 활력 요소가 되는 취미들을 하자!

,