Github Actions 동작 원리에 대한 이해

Rachel·2024년 8월 9일

Github

목록 보기

1/1

1. Github Actions이란

GitHub Actions는 GitHub에서 제공하는 CI/CD(Continuous Integration/Continuous Delivery) 도구로, 코드의 빌드, 테스트, 배포와 같은 자동화된 작업을 수행할 수 있습니다. 프론트엔드 개발자에게 GitHub Actions는 프로젝트의 지속적인 통합 및 배포 파이프라인을 구성하는 데 매우 유용한 도구입니다. 아래는 GitHub Actions의 동작 원리, 과정, 그리고 프론트엔드 개발자가 알아야 할 주요 개념을 정리한 내용입니다.

2. GitHub Actions의 주요 개념

GitHub Actions는 리포지토리에서 코드 변경이 발생할 때, 특정 작업을 자동으로 수행할 수 있도록 하는 자동화 도구입니다. 워크플로우(Workflow)라고 불리는 일련의 작업들을 정의하고, 이를 트리거(Trigger)에 따라 실행합니다. GitHub Actions는 YAML 파일을 사용해 설정을 정의하며, 이 파일은 .github/workflows/ 디렉터리에 위치합니다.

워크플로우(Workflow): 워크플로우는 자동화된 프로세스의 정의로, 하나 이상의 작업(Job)으로 구성됩니다. 워크플로우는 특정 이벤트에 의해 트리거됩니다. 예를 들어, 코드가 푸시될 때 테스트를 실행하는 워크플로우를 정의할 수 있습니다.
잡(Job): 잡은 여러 스텝(Step)으로 구성된 작업 단위입니다. 각 잡은 독립적으로 실행되며, 병렬 또는 순차적으로 실행할 수 있습니다. 예를 들어, 테스트 잡과 빌드 잡을 병렬로 실행하거나, 빌드가 완료된 후에만 배포 잡이 실행되도록 설정할 수 있습니다.
스텝(Step): 스텝은 잡 내에서 실행되는 개별 명령어 또는 작업입니다. 각 스텝은 스크립트나 액션(Action)으로 정의됩니다.
액션(Action): 액션은 스텝에서 실행되는 재사용 가능한 코드 조각입니다. GitHub 마켓플레이스에서 제공되는 다양한 액션을 사용해 쉽게 작업을 자동화할 수 있습니다. 예를 들어, 코드 스타일 검사를 위한 ESLint 액션을 추가하거나, Docker 이미지를 빌드하는 액션을 추가할 수 있습니다.
런너(Runner): 런너는 워크플로우를 실행하는 환경입니다. GitHub에서 제공하는 호스티드 런너를 사용할 수도 있고, 자체 호스티드 런너를 설정할 수도 있습니다.
이벤트(Event): 이벤트는 워크플로우를 트리거하는 조건입니다. 대표적인 이벤트로는 push, pull_request, issue, schedule 등이 있으며, 특정 브랜치에 코드가 푸시되었을 때, 혹은 특정 시간에 주기적으로 워크플로우를 실행하는 것이 가능합니다.

3. GitHub Actions의 동작 원리

트리거(Event) 감지: 리포지토리에 정의된 특정 이벤트(예: 코드 푸시, PR 생성 등)가 발생하면, GitHub Actions가 워크플로우를 트리거합니다.
워크플로우 실행: 트리거된 워크플로우가 정의된 순서대로 잡(Job)을 실행합니다. 각 잡은 지정된 런너 환경에서 실행됩니다.
잡(Job) 실행: 각 잡은 독립적으로 실행되며, 여러 스텝(Step)으로 구성됩니다. 잡은 병렬로 실행될 수도 있고, 순차적으로 실행될 수도 있습니다.
스텝(Step) 실행: 각 스텝은 명령어 또는 액션을 수행하며, 성공 또는 실패로 완료됩니다. 실패가 발생하면 워크플로우가 중단될 수 있습니다.
결과 보고: 모든 스텝이 실행되면, GitHub Actions는 워크플로우 실행 결과를 요약하여 GitHub의 웹 인터페이스에 표시합니다. 여기서 로그를 확인하거나, 실패한 이유를 분석할 수 있습니다.

4. GitHub Actions의 설정 파일 (YAML)

GitHub Actions는 .github/workflows/ 디렉터리에 위치한 .yaml 파일(혹은 .yml 파일)로 설정됩니다. 다음은 프론트엔드 프로젝트에서 자주 사용하는 GitHub Actions 설정 파일 예시입니다.

name: CI/CD Pipeline

on:
  push:
    branches:
      - main
      - develop
  pull_request:
    branches:
      - main
      - develop

jobs:
  build-and-test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [16.x, 18.x] # 테스트하고자 하는 Node.js 버전들

    steps:
      - name: Check out the code
        uses: actions/checkout@v4

      - name: Set up Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
          cache: "npm" # 캐시 사용

      - name: Install dependencies
        run: npm ci # 의존성 설치

      - name: Run Lint
        run: npm run lint # 린트 작업 수행

      - name: Run Tests
        run: npm test # 유닛 테스트 수행

      - name: Build Project
        run: npm run build # 빌드 수행

#   deploy:
#     runs-on: ubuntu-latest
#     needs: build-and-test  # 빌드 및 테스트가 성공한 경우에만 배포

#     steps:
#       - name: Deploy to Vercel
#         uses: amondnet/vercel-action@v20
#         with:
#           vercel-token: ${{ secrets.VERCEL_TOKEN }}
#           vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
#           vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
#           working-directory: ./

📄 실제 프로젝트시 사용했던 main.yml 파일

name: Slam Talk CI

on:
  workflow_dispatch:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main, develop]

jobs:
  test:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [20.x]

    steps:
      - uses: actions/checkout@v4
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm ci
      - run: npm run lint

브랜치 트리거 설정:
- main, develop 브랜치를 별도로 운영하여 개발과 배포를 관리하기 때문에, 이 두 브랜치에서의 커밋과 PR(Pull Request) 이벤트가 발생할 때마다 자동으로 워크플로우가 실행되도록 설정했습니다.
- push 및 pull_request 트리거를 설정하여, 새로운 코드가 푸시되거나 PR이 생성될 때 자동으로 린트 작업이 수행됩니다. 이를 통해 코드의 품질을 지속적으로 검증할 수 있습니다.
노드 버전 설정:
- 실제 프로젝트에서 사용 중인 Node.js 20.x 버전을 명시하여, 이 버전에서 코드가 정상적으로 동작하는지 확인합니다.
- matrix 전략을 사용하면, 필요에 따라 여러 Node.js 버전에서 코드를 테스트할 수 있습니다. 이 설정에서는 현재 프로젝트에서 사용 중인 Node.js 20.x 버전만 명시되어 있지만, 다른 Node.js 버전(예: 14.x, 16.x 등)에서도 테스트하고 싶은 경우, 해당 버전들을 추가로 명시할 수 있습니다.
CI 작업:
- npm ci 명령어를 사용하여 의존성을 설치합니다. 이 명령어는 package-lock.json 파일에 명시된 정확한 버전의 패키지들을 설치하기 때문에, 개발 환경과 CI 환경 간의 일관성을 유지하는 데 매우 중요합니다.
- npm run lint 명령어를 통해 린트 작업을 수행합니다. 이를 통해 코드가 정해진 스타일 가이드와 규칙을 준수하는지 확인할 수 있습니다. 린트 작업에서 문제가 발견되면, 이를 사전에 수정함으로써 코드 품질을 유지할 수 있습니다.

Github을 통해 Vercel을 연결하면 자동으로 CI/CD 파이프라인을 구성할 수 있습니다.
👉 Vercel에서 자동으로 CI/CD가 되기 때문에 자동 Lint 검사 용도 정도로 Github Actions CI를 활용했습니다.
Jest 테스트 등이 추가되면 좋을 것 같습니다.

5. 프론트엔드 개발에서 GitHub Actions의 활용

프론트엔드 개발에서 GitHub Actions는 다음과 같은 작업을 자동화하는 데 유용합니다:

코드 검증:

ESLint 및 Prettier: 코드 스타일을 일정하게 유지하기 위해, GitHub Actions를 통해 ESLint와 Prettier를 자동으로 실행할 수 있습니다. 이를 통해 코드 스타일 위반 사항을 PR(Pull Request)에서 경고로 표시할 수 있습니다.

테스트 자동화:

Jest를 이용한 유닛 테스트: GitHub Actions를 Jest와 통합하여, 코드 푸시 시 자동으로 유닛 테스트를 실행합니다. 테스트가 실패할 경우 배포를 중단하여, 버그가 포함된 코드가 배포되지 않도록 방지할 수 있습니다.

빌드 작업:

Webpack 및 Vite: 프론트엔드 프로젝트의 코드는 배포 전에 빌드 과정이 필요합니다. GitHub Actions에서 Webpack이나 Vite와 같은 번들러를 사용하여 코드를 빌드하고, 그 결과를 검토한 후 배포할 수 있습니다.

배포 자동화:

Vercel 및 Netlify: GitHub Actions에서 빌드가 성공적으로 완료되면, Vercel이나 Netlify와 같은 배포 플랫폼에 자동으로 배포할 수 있습니다. 이 과정에서 GitHub Actions와 배포 플랫폼 간의 인증은 API 키 또는 토큰을 통해 처리됩니다.

동적 환경 변수 설정:

환경 변수 관리: 프론트엔드 프로젝트에서 환경 변수는 중요한 설정 요소입니다. GitHub Actions를 활용하여, 특정 환경에 맞는 환경 변수 파일을 생성하거나 자동으로 환경 변수 설정 파일을 작성할 수 있습니다.

이러한 활용 방법을 통해, 프론트엔드 개발자는 GitHub Actions를 사용하여 코드를 자동으로 검사, 테스트, 빌드, 배포할 수 있으며, 이를 통해 개발 속도와 코드 품질을 크게 향상시킬 수 있습니다.

6. GitHub Actions의 장점

통합된 환경: GitHub 리포지토리와 통합되어 있어, 별도의 CI/CD 도구를 사용하지 않아도 됩니다.
유연성: 다양한 액션과 커스텀 설정을 통해 프로젝트에 맞는 CI/CD 파이프라인을 구성할 수 있습니다.
확장성: 커뮤니티와 GitHub 마켓플레이스에서 제공하는 수많은 액션을 활용해 다양한 작업을 자동화할 수 있습니다.

GitHub Actions를 사용하면 코드가 푸시될 때마다 자동으로 테스트, 빌드, 배포가 이루어지며, 이를 통해 안정적인 배포 파이프라인을 구축할 수 있습니다. YAML 파일을 통해 간단하게 설정할 수 있고, GitHub의 방대한 생태계와 액션을 활용하여 다양한 자동화를 실현할 수 있습니다.

7. Vercel과 GitHub Actions를 활용한 CI/CD 흐름

코드 푸시(Push): 개발자가 코드의 변경 사항을 GitHub 리포지토리에 푸시합니다.
GitHub Actions 트리거: 코드가 푸시되면 GitHub Actions가 트리거되어 워크플로우가 시작됩니다. 이 단계에서는 코드 빌드, 테스트, 코드 스타일 검사 등의 작업이 이루어집니다.
테스트 및 빌드: GitHub Actions는 설정된 워크플로우에 따라 코드를 빌드하고 테스트합니다. 만약 테스트가 실패하거나 빌드에 문제가 발생하면, 개발자에게 알림이 가며 배포는 중단됩니다.
Vercel 빌드 및 배포 트리거: GitHub Actions의 빌드와 테스트가 성공적으로 완료되면, Vercel이 자동으로 배포를 트리거합니다. Vercel은 다음과 같은 빌드 과정을 통해 프로젝트의 최신 코드를 프로덕션 또는 프리뷰 환경에 배포합니다:
• 빌드 명령어 실행: package.json 파일에 지정된 빌드 명령어(예: npm run build)가 실행되어 프로젝트가 빌드됩니다.
• 코드 최적화: 코드 스플리팅, 트리 쉐이킹, 압축 등의 최적화 작업이 수행됩니다.
• 정적 자산 생성: 빌드된 정적 파일들이 Vercel의 배포 시스템에 의해 준비됩니다.
• 서버리스 함수 배포: 서버리스 함수가 포함된 경우, 개별적으로 배포됩니다.
• 글로벌 CDN 배포: 빌드된 결과물은 Vercel의 글로벌 CDN을 통해 전 세계에 배포됩니다. 이를 통해 사용자들은 가까운 서버에서 콘텐츠를 빠르게 제공받습니다.
프리뷰 환경 제공: Vercel은 모든 PR(Pull Request)에 대해 별도의 프리뷰 환경을 제공합니다. 이를 통해 팀원들은 코드가 실제로 배포되기 전에 변경 사항을 미리 확인할 수 있습니다. 각 PR은 고유한 URL이 부여되며, 이 URL에서 변경 사항을 테스트할 수 있습니다.
프로덕션 배포: 코드 변경 사항이 main 또는 지정된 배포 브랜치에 머지(Merge)되면, Vercel은 자동으로 프로덕션 배포를 진행합니다. 이 과정은 무중단 배포로 이루어져, 사용자는 새로운 버전을 즉시 사용할 수 있게 됩니다.
결과 확인 및 알림: 배포가 완료되면 Vercel 대시보드 또는 GitHub에서 배포 상태를 확인할 수 있습니다. 성공 여부와 배포된 URL을 확인할 수 있으며, 문제가 발생한 경우 빠르게 대응할 수 있습니다.

Vercel은 무중단 배포를 기본으로 하며, 이전 버전의 애플리케이션을 유지하면서 새로운 버전을 배포합니다. 이를 통해 배포 중에도 사용자가 끊김 없이 애플리케이션을 사용할 수 있습니다.

✏️ 용어 정리, 연관된 개념 정리

CI(Continuous Integration)란?

Continuous Integration(CI)은 소프트웨어 개발에서 팀원들이 각자 작업한 코드를 자주 병합(Integration)하여, 자동으로 빌드(Build)와 테스트(Test)를 수행하는 과정을 말합니다. CI의 주요 목표는 코드 병합 시 발생할 수 있는 충돌과 버그를 조기에 발견하고 해결하는 것입니다.

자동화된 빌드 및 테스트: 코드가 리포지토리에 푸시될 때마다 자동으로 빌드와 테스트가 실행됩니다. 이를 통해 새로운 코드가 기존 코드와 잘 통합되는지, 테스트를 통과하는지 확인할 수 있습니다.
지속적인 코드 품질 보장: CI는 코드를 자주 통합하고 테스트함으로써 코드 품질을 지속적으로 유지하고 개선하는 데 도움을 줍니다.
신속한 피드백: 코드에 문제가 있으면 바로 피드백을 제공하여, 개발자들이 신속하게 수정할 수 있도록 합니다.

CD(Continuous Delivery/Continuous Deployment)란

Continuous Delivery(CD)와 Continuous Deployment(CD)는 CI의 다음 단계로, 빌드된 코드가 자동으로 배포(Deployment)되는 과정을 포함합니다.

Continuous Delivery(CD): CI 후, 빌드된 코드를 프로덕션 환경에 배포하기 전에, 수동 승인이 필요한 경우를 말합니다. 개발자나 관리자에게 배포 승인 요청이 가며, 승인이 완료되면 코드가 프로덕션 환경에 배포됩니다.
Continuous Deployment(CD): CI 후, 빌드된 코드가 자동으로 프로덕션 환경에 배포되는 것을 말합니다. 수동 승인 없이 자동으로 배포되며, 이로 인해 신속하게 새로운 기능이나 수정사항이 배포됩니다.

두 개념은 “CD”로 불리지만, Continuous Delivery와 Continuous Deployment의 차이점은 수동 승인이 있는지 여부입니다.

CI/CD 파이프라인 정리

CI 파이프라인

코드를 푸시하거나 Pull Request가 생성될 때, 자동으로 빌드하고 테스트를 수행합니다.
코드 품질을 보장하기 위해 테스트가 실패할 경우 알림을 보내고 배포를 중단합니다.

CD 파이프라인

CI가 성공적으로 완료되면, 코드 변경 사항을 스테이징 환경이나 프로덕션 환경에 자동으로 배포할 수 있습니다.
GitHub Actions 내에서 배포 스크립트를 작성하여, AWS, Azure, Vercel, Netlify 등 다양한 배포 플랫폼에 배포할 수 있습니다.

파이프라인이란?

파이프라인(Pipeline)은 소프트웨어 개발 및 배포 과정에서 일련의 작업이 자동으로 순차적으로 또는 병렬로 수행되는 흐름을 말합니다. 이 개념은 특히 CI/CD(Continuous Integration/Continuous Deployment)에서 많이 사용됩니다. 파이프라인은 코드의 변경 사항이 소스 코드 저장소에 반영된 후, 빌드, 테스트, 배포와 같은 단계들이 자동으로 실행되도록 구성합니다.

파이프라인의 주요 단계

코드 통합 (Integration):
- 개발자가 작성한 코드가 저장소에 커밋되면 파이프라인이 시작됩니다.
- 이 단계에서는 여러 개발자가 작업한 코드가 함께 통합됩니다.
빌드 (Build):
- 코드가 컴파일되거나 패키징됩니다.
- 의존성 관리, 코드를 바이너리 형태로 변환 등의 작업이 이루어집니다.
- 빌드 과정에서 오류가 발생하면 파이프라인이 중단되고, 문제가 보고됩니다.
테스트 (Test):
- 빌드된 코드가 사전 정의된 테스트 케이스를 통해 검증됩니다.
- 유닛 테스트, 통합 테스트, E2E 테스트 등 다양한 테스트가 이 단계에서 수행됩니다.
- 테스트에 실패하면 파이프라인이 중단되고, 문제가 보고됩니다.
배포 (Deploy):
- 테스트가 성공적으로 완료되면, 코드가 스테이징 또는 프로덕션 환경에 배포됩니다.
- 이 단계에서 애플리케이션이 사용자에게 제공될 준비를 마칩니다.
- 무중단 배포(Zero-downtime deployment)도 가능하며, 새로운 버전이 배포되면서도 이전 버전이 사용자의 서비스에 영향을 미치지 않도록 할 수 있습니다.
모니터링 및 피드백 (Monitoring and Feedback):
- 배포된 애플리케이션의 상태를 모니터링하고, 문제가 발생하면 피드백을 제공하는 단계입니다.
- 성능 모니터링, 오류 추적, 사용자 피드백 수집 등이 포함될 수 있습니다.

파이프라인의 장점

자동화: 사람이 개입하지 않고, 코드 변경부터 배포까지의 과정을 자동으로 수행할 수 있어 효율적이고 오류를 줄일 수 있습니다.
일관성: 동일한 작업을 항상 동일한 방법으로 수행하여 결과의 일관성을 보장합니다.
빠른 피드백: 코드 변경 사항이 문제를 일으킬 경우, 즉시 피드백을 제공하여 빠르게 수정할 수 있습니다.
개발 속도 향상: 개발자들은 코드 변경 후 수동으로 빌드나 배포를 할 필요 없이, 빠르게 다음 작업에 집중할 수 있습니다.

예를 들어, GitHub Actions에서 파이프라인을 설정하면 다음과 같은 흐름으로 작업이 진행될 수 있습니다:

코드가 푸시되면 파이프라인이 시작됩니다.
npm ci 명령어로 의존성을 설치하고, 빌드가 시작됩니다.
빌드된 코드에 대해 테스트를 수행합니다.
테스트가 성공하면 코드가 배포됩니다.
배포된 애플리케이션의 상태를 모니터링합니다.

이와 같은 파이프라인을 통해 개발부터 배포까지의 과정을 자동화하여 더 빠르고 안정적인 소프트웨어 제공이 가능합니다.

⭐️ 빌드 결과물이 뭘까요?

빌드 결과물(Build Artifacts)은 CI/CD 파이프라인에서 코드가 빌드된 후 생성되는 산출물입니다. 빌드 결과물은 일반적으로 애플리케이션의 배포 가능한 형태로, 다음과 같은 형태일 수 있습니다:

압축 파일 (ZIP, TAR): 여러 파일이 하나의 패키지로 압축된 형태. 이 파일은 배포될 서버로 전송된 후, 압축이 풀려 실행됩니다.
번들 파일 (JavaScript, CSS 등): Webpack, Vite와 같은 번들러에 의해 생성된 최적화된 자바스크립트와 CSS 파일들이 번들로 묶여 배포됩니다.
Docker 이미지: 애플리케이션과 필요한 모든 종속성을 포함한 컨테이너 이미지. 이 이미지는 Docker Registry에 푸시되고, 이후 배포 시 사용됩니다.
애플리케이션 바이너리: 빌드된 실행 파일이나 라이브러리 파일들이 배포에 사용됩니다. 예를 들어, Java 애플리케이션의 경우 JAR 파일이 될 수 있습니다.

이러한 빌드 결과물은 CI/CD 파이프라인에서 생성된 후, 다음 단계로 배포되거나, 저장소에 보관되어 배포 시 사용됩니다.

CDN이란?

CDN(Content Delivery Network)은 인터넷 사용자들에게 콘텐츠를 빠르고 효율적으로 전달하기 위해 사용되는 분산된 서버 시스템입니다. CDN은 다음과 같은 주요 기능을 수행합니다:

콘텐츠 캐싱: CDN은 웹사이트의 정적 콘텐츠(이미지, HTML, CSS, JavaScript 파일 등)를 캐싱하여 저장합니다. 이를 통해 동일한 콘텐츠 요청이 있을 때마다 원본 서버에 접근할 필요 없이, 가장 가까운 CDN 서버에서 콘텐츠를 제공할 수 있습니다.
글로벌 분산: CDN은 전 세계에 분산된 서버 네트워크를 통해 콘텐츠를 전달합니다. 사용자는 자신의 위치에서 가장 가까운 CDN 서버에 접속하여 빠르게 콘텐츠를 받을 수 있습니다.
로드 밸런싱: CDN은 트래픽 부하를 여러 서버에 분산시켜 서버 과부하를 방지하고, 웹사이트의 가용성과 성능을 향상시킵니다.
보안 강화: CDN은 DDoS 공격 방어, SSL 인증서 관리, 방화벽 설정 등을 통해 웹사이트의 보안을 강화합니다.

정리

Vercel은 프로젝트의 코드가 변경될 때마다 자동으로 빌드 과정을 수행하고, 이를 최적화된 형태로 준비하여 글로벌 CDN에 배포합니다.
글로벌 CDN은 Vercel의 기본 기능으로, 전 세계 사용자에게 빠르고 안정적으로 콘텐츠를 제공하는 역할을 합니다.
CDN(Content Delivery Network)은 콘텐츠를 효율적으로 제공하기 위해 전 세계에 분산된 서버 네트워크로, 사용자 경험을 개선하고 웹사이트 성능을 향상시킵니다.

서버리스 함수란?

서버리스 함수는 서버 관리에 신경 쓰지 않고, 코드 작성에만 집중할 수 있는 클라우드 컴퓨팅 모델입니다. 개발자는 특정 이벤트가 발생했을 때 실행되는 개별 함수로 코드를 작성하고, 클라우드 제공자(AWS Lambda, Google Cloud Functions, Vercel Serverless Functions 등)가 이 함수를 자동으로 실행하며, 인프라 관리와 확장성을 처리합니다.

자동 확장: 요청이 증가하면 클라우드 제공자가 자동으로 더 많은 인스턴스를 생성하여 트래픽을 처리합니다.
과금 모델: 실행된 함수에 대해서만 과금되며, 함수가 실행되지 않으면 비용이 발생하지 않습니다.
실행 환경: 서버리스 함수는 특정 이벤트(HTTP 요청, 데이터베이스 트리거 등)에 의해 호출되며, 짧은 시간 동안 실행됩니다.

서버리스 모델을 사용하면 인프라 관리 없이도 코드의 배포와 실행을 효율적으로 처리할 수 있습니다.

Next.js 환경에서는 API Routes를 사용하여 app/api 또는 pages/api 디렉토리에 서버리스 함수를 정의할 수 있습니다.

로드 밸런싱이란?

로드 밸런싱은 네트워크나 애플리케이션 트래픽을 여러 서버(또는 인스턴스)로 분산시켜, 서버의 부하를 고르게 분배하는 기술입니다. 이를 통해 하나의 서버에 과도한 요청이 몰리는 것을 방지하고, 시스템의 성능과 안정성을 높일 수 있습니다.

트래픽 분산: 로드 밸런서는 클라이언트 요청을 여러 서버로 분배하여, 특정 서버에 과부하가 걸리지 않도록 합니다.
가용성 향상: 서버 중 하나가 장애를 일으키더라도, 로드 밸런서는 다른 서버로 트래픽을 전환해 서비스를 지속적으로 제공할 수 있습니다.
확장성: 로드 밸런싱을 통해 시스템이 수평적으로 확장될 수 있으며, 트래픽 증가에 대응하기 위해 서버를 쉽게 추가할 수 있습니다.

로드 밸런싱은 웹 애플리케이션의 성능 최적화와 가용성을 높이기 위해 중요한 역할을 합니다.

DDos 공격이란?

DDoS(Distracted Denial of Service) 공격은 대규모의 트래픽을 특정 서버나 네트워크에 집중적으로 전송하여, 정상적인 서비스가 불가능하게 만드는 사이버 공격입니다. DDoS 공격은 일반적으로 분산된 여러 컴퓨터(봇넷)가 동시에 공격을 수행해, 타겟 서버의 자원을 고갈시킵니다.

목적: 서비스 방해 또는 중단을 목적으로, 서버의 CPU, 메모리, 네트워크 대역폭 등을 과부하 상태로 만들어 서비스를 제공하지 못하게 합니다.
공격 방법: 공격자는 악성 소프트웨어를 통해 수천, 수만 대의 컴퓨터를 감염시켜 하나의 거대한 봇넷을 형성한 후, 특정 서버에 대량의 요청을 보내 DDoS 공격을 수행합니다.
대응 방법: 로드 밸런싱, 웹 애플리케이션 방화벽(WAF), DDoS 보호 서비스(AWS Shield, Cloudflare 등)를 통해 DDoS 공격을 완화하거나 방어할 수 있습니다.

DDoS 공격은 서비스 가용성을 저해하고, 비즈니스에 심각한 영향을 미칠 수 있기 때문에 적절한 보안 대책이 필요합니다.

추가하면 좋은 부분이나 잘못된 점이 있다면 댓글 남겨주세요. 감사합니다 :)

Rachel

기존 블로그: https://hi-rachel.tistory.com