Elastic Beanstalk와 수동 설정 비교

Elastic Beanstalk와 수동 설정 비교

마이크로서비스를 배포하는 방법은 다양하며 각 방법은 서로 다른 수준의 제어, 단순성 및 확장성을 제공합니다. 한 가지 접근 방식은 엘라스틱 콩나무배포, 확장, 관리를 단순화하는 완전 관리형 서비스입니다. 또 다른 옵션은 인프라를 완전히 제어할 수 있지만 더 많은 설정과 유지 관리가 필요한 수동 배포입니다.

이 기사에서는 두 가지 접근 방식에 대해 논의하고 각 접근 방식의 장단점을 탐색하여 귀하의 애플리케이션에 가장 적합한 접근 방식을 결정하는 데 도움을 드릴 것입니다.

Elastic Beanstalk 배포

Elastic Beanstalk는 인프라 관리의 대부분을 추상화하는 AWS의 PaaS(Platform-as-a-Service) 제품입니다. 애플리케이션의 배포, 확장, 모니터링 및 관리를 자동으로 처리합니다.

장점

  1. 단순화된 관리: Elastic Beanstalk는 리소스(EC2, RDS, 로드 밸런싱 등) 프로비저닝을 자동으로 처리합니다. 이를 통해 운영 오버헤드를 크게 줄일 수 있습니다.
  2. 자동 확장: 트래픽을 기준으로 애플리케이션을 자동으로 확장하므로 다양한 워크로드를 더 쉽게 처리할 수 있습니다.
  3. 통합 모니터링 및 로깅: Amazon CloudWatch 및 Elastic Load Balancing을 기본적으로 지원하므로 최소한의 구성으로 애플리케이션 상태와 성능을 추적할 수 있습니다.
  4. 빠른 배포: Docker 지원을 통해 기본 인프라에 대해 크게 걱정하지 않고 Dockerized 애플리케이션을 빠르게 배포할 수 있습니다.
  5. 환경관리: Beanstalk를 사용하면 최소한의 설정으로 다양한 환경(예: 개발, 스테이징, 프로덕션)을 쉽게 관리할 수 있습니다.

단점

  1. 유연성이 떨어짐: Elastic Beanstalk는 기본 인프라에 대한 제어의 상당 부분을 추상화합니다. 매우 구체적인 구성이 필요한 경우 제한적일 수 있습니다.
  2. 자원 제약: 크기 조정은 자동이지만 기본 EC2 인스턴스가 특정 애플리케이션 요구 사항(예: 특정 인스턴스 유형)에 항상 최적의 구성이 아닐 수도 있습니다.
  3. 학습 곡선: 모든 것을 수동으로 설정하는 것보다 쉽지만 AWS 서비스에 익숙하지 않은 경우 학습 곡선이 여전히 있을 수 있습니다.

로드 밸런서 및 Auto-Scaling 그룹과 함께 EC2 인스턴스를 사용한 수동 배포

이 접근 방식에는 EC2 인스턴스 수동 프로비저닝, 로드 밸런서(ELB 또는 ALB) 설정, Auto Scaling 그룹 구성을 통해 애플리케이션의 확장 및 가용성을 관리하는 작업이 포함됩니다.

장점

  1. 모든 권한: 인스턴스 유형, 네트워킹, 로드 밸런싱 설정을 포함한 인프라를 완벽하게 제어할 수 있습니다.
  2. 맞춤화: 필요에 따라 시스템을 정확하게 구성하여 애플리케이션의 요구 사항을 정확하게 충족할 수 있습니다.
  3. 특정 요구에 최적화됨: 특정 성능이나 보안 요구 사항이 있는 경우 EC2 인스턴스, 네트워킹 구성 및 자동 크기 조정 규칙을 세부적으로 조정할 수 있습니다.
  4. 유연성: Elastic Beanstalk 환경의 제약을 받지 않고 원하는 도구나 프레임워크를 모두 사용할 수 있습니다.
  5. 비용 관리: 특정 요구 사항과 사용 패턴에 따라 EC2 인스턴스와 로드 밸런싱 비용을 최적화할 수 있습니다.

단점

  1. 복잡한 설정: EC2 인스턴스 설정, 로드 밸런서 구성, Auto Scaling 그룹 생성에는 더 많은 수동 작업과 세부 사항에 대한 주의가 필요합니다. 확장, 장애 조치, 상태 확인을 직접 처리해야 합니다.
  2. 추가 유지 관리: EC2 인스턴스의 패치, 모니터링, 상태 확인을 관리해야 합니다. Beanstalk는 이 대부분의 작업을 수행합니다.
  3. 스케일링 관리: 자동 크기 조정이 가능하지만 구성 및 미세 조정이 복잡할 수 있습니다. 특히 다양한 트래픽 패턴에 대해 크기 조정 정책을 조정해야 하는 경우에는 더욱 그렇습니다.

Elastic Beanstalk 배포 단계

Elastic Beanstalk 환경 설정 및 구성

Elastic Beanstalk는 확장 및 로드 밸런싱을 포함한 대부분의 인프라를 자동으로 처리합니다. Dockerized 애플리케이션을 Elastic Beanstalk에 배포하는 방법은 다음과 같습니다.

1단계: AWS CLI 설치

AWS CLI를 설치하고 AWS 자격 증명으로 구성합니다.

2단계: 애플리케이션용 Dockerfile 생성

백엔드(Spring Boot Maven) 및 프런트엔드(React) 앱 모두에 대한 dockerfile을 만듭니다.

Dockerfile ~을 위한 스프링 부트:

FROM openjdk:11-jre-slim
COPY target/my-spring-app.jar /app/my-spring-app.jar
ENTRYPOINT ["java", "-jar", "/app/my-spring-app.jar"]

Dockerfile ~을 위한 반응하다:

FROM node:16-alpine
WORKDIR /app
COPY package.json /app/package.json
RUN npm install
COPY . /app
RUN npm run build
CMD ["npm", "start"]

3단계: Elastic Beanstalk 환경 초기화

애플리케이션 디렉터리에서 Elastic Beanstalk CLI(eb) 환경을 초기화하려면 다음을 수행합니다.

eb cli
eb init -p docker my-app

그러면 Elastic Beanstalk로 애플리케이션이 구성되고 AWS 계정에 연결됩니다.

4단계: Elastic Beanstalk 환경 생성 및 구성

새 환경 만들기(예: 웹 환경):

eb cli
eb create my-app-env

Elastic Beanstalk는 EC2 인스턴스, 로드 밸런서, Auto Scaling과 같은 필수 리소스를 자동으로 생성합니다.

5단계: Docker화된 애플리케이션 배포

애플리케이션을 배포합니다.

이 명령은 Docker 이미지를 Elastic Beanstalk에 업로드하고 배포합니다.

6단계: URL 노출

환경이 배포되면 Elastic Beanstalk는 공개 URL(예: my-app-env.us-east-1.elasticbeanstalk.com).

Elastic Beanstalk URL

이 URL을 통해 애플리케이션에 액세스할 수 있으며 Elastic Beanstalk는 라우팅 및 크기 조정을 자동으로 관리합니다.

7단계: 인스턴스 구성 설정

인스턴스 유형, 확장, 상태 확인과 같은 설정을 구성합니다.

  • AWS 콘솔에서 다음으로 이동합니다. 엘라스틱 콩나무 > 환경 > 구성.
  • 설정 그리고 최대 애플리케이션의 로드를 기준으로 인스턴스 수를 계산합니다.
  • 인스턴스 유형을 선택합니다(예: t2.micro, t2.small).
  • 상태 확인을 위한 URL 경로를 정의합니다(예: /health 스프링 부트의 경우).

로드 밸런서 및 Auto Scaling 그룹이 있는 EC2 인스턴스

1단계: EC2 인스턴스 시작

EC2 인스턴스 시작

  1. 로 이동 EC2 대시보드 AWS에서.
  2. 선택하다 인스턴스 시작 AMI(예: Amazon Linux 2 또는 Ubuntu)를 선택합니다.
  3. 인스턴스 세부정보를 구성하고 보안 그룹 허용하려면:
    • SSH(액세스용 포트 22).
    • HTTP(웹 트래픽용 포트 80).
    • HTTPS(암호화된 트래픽의 경우 포트 443).

EC2에 Docker를 설치합니다.

bash
sudo yum update -y
sudo amazon-linux-extras install docker
sudo service docker start
sudo usermod -a -G docker ec2-user

2단계: 로드 밸런서 및 대상 그룹 생성

대상 그룹 생성

  1. 이동 EC2 > 대상 그룹 그리고 클릭 대상 그룹 생성.
  2. 선택하다 사례 대상 유형으로 프로토콜을 다음과 같이 설정합니다. HTTP (포트 80) 대상 그룹에 대한 것입니다.
  3. 설정 상태 확인 경로 (예: /health) 애플리케이션의 상태를 확인합니다.
  4. EC2 인스턴스를 대상 그룹에 등록합니다.

로드 밸런서(ALB) 생성

  1. 이동 EC2 > 로드 밸런서 그리고 클릭 로드 밸런서 생성.
  2. 선택하다 애플리케이션 로드 밸런서(ALB) HTTP/HTTPS 트래픽을 처리하기 위한 것입니다.
  3. 설정 청취자 HTTP(포트 80) 및 HTTPS(포트 443)의 경우. HTTPS의 경우 SSL 인증서를 사용해야 합니다(나중에 Route 53 및 AWS Certificate Manager를 사용하여 구성).
  4. 적절한 것을 선택하세요 보안 그룹 포트 80 및 443에서 인바운드 트래픽을 허용합니다.
  5. 대상 그룹을 로드 밸런서에 연결합니다.

3단계: Auto Scaling 그룹 설정

  1. 이동 EC2 > Auto Scaling 그룹 > Auto Scaling 그룹 생성.
  2. 확장하려는 EC2 인스턴스를 선택하고 이를 로드 밸런서의 대상 그룹에 연결합니다.
  3. 조정을 위한 최소 및 최대 인스턴스를 설정하고 트래픽 급증을 처리하도록 조정 정책을 구성합니다.

4단계: 보안 그룹 구성

EC2 인스턴스용 보안 그룹

  • 열려 있는 SSH(포트 22) 관리 액세스를 위해.
  • 열려 있는 HTTP(포트 80) 공개 웹 액세스용.
  • 열려 있는 HTTPS(포트 443) SSL을 사용하는 경우 보안 트래픽을 위해.

로드 밸런서를 위한 보안 그룹

  • HTTP(포트 80) 및 HTTPS(포트 443) 인바운드를 허용합니다.
  • EC2 인스턴스에 대한 아웃바운드 연결을 허용합니다.

5단계: EC2 인스턴스에서 포트 80 열기

기본적으로 HTTP 트래픽에 대해 포트 80을 엽니다. 보안 그룹 AWS의 설정.

에서 보안 그룹 구성, 추가 인바운드 규칙:

  • 유형: HTTP
  • 포트 범위: 80
  • 소스: 0.0.0.0/0(모든 트래픽 허용) 또는 특정 IP.

6단계: HTTPS 트래픽 전달(포트 443)

Route 53 및 SSL 사용

  1. 이동 AWS 인증서 관리자(ACM) 도메인에 대한 SSL 인증서를 요청하세요.
  2. 인증서가 발급되면 다음으로 이동하세요. EC2 > 로드 밸런서 SSL 인증서를 포트 수신기에 연결합니다. 443.
  3. ~ 안에 53번 국도만들기 레코드 세트 귀하의 도메인이 다음을 가리키는 경우 장백의.

루트 53 설정

  • A 레코드 만들기 이는 Load Balancer의 DNS 이름을 가리킵니다.
  • 라우팅 정책(예: 단순 라우팅)을 설정합니다.
  • 도메인이 ALB에 올바르게 매핑되었는지 확인하세요.

SSL용 ALB 리스너 설정

  • 추가 경청자 포트 443의 HTTPS용.
  • ACM의 SSL 인증서를 사용하고 SSL 연결을 종료하도록 로드 밸런서를 구성합니다(즉, ALB에서 HTTPS 트래픽을 해독하고 HTTP 트래픽을 EC2로 전달).

7단계: EC2 인스턴스에 Docker 컨테이너 배포

1. EC2 인스턴스에 SSH로 접속하고 Amazon에서 Docker 이미지를 가져옵니다. ECR (탄력적 컨테이너 레지스트리).

bash
docker pull .dkr.ecr..amazonaws.com/my-spring-app:latest
docker pull .dkr.ecr..amazonaws.com/my-react-app:latest

2. EC2 인스턴스에서 컨테이너를 실행합니다.

bash
docker run -d -p 8080:8080 my-spring-app
docker run -d -p 80:80 my-react-app

8단계: 모니터링 및 확장

다음을 통해 애플리케이션을 모니터링하세요. 클라우드워치 지표(예: CPU 사용량, 메모리 사용량)를 확인하고 Auto Scaling 그룹에 대한 조정 정책을 조정하여 애플리케이션이 로드에 따라 자동으로 조정되도록 합니다.

요약

Elastic Beanstalk는 애플리케이션에 대한 로드 밸런서, 대상 그룹, 보안 그룹, IAM 역할 및 Auto Scaling 생성을 자동으로 처리합니다. 인프라 관리와 관련된 많은 복잡성을 추상화하여 기본 서비스에 대한 걱정 없이 애플리케이션을 보다 쉽게 ​​배포할 수 있습니다. 그러나 인프라에 대한 추가 제어가 필요한 경우 AWS Management Console, CLI 또는 구성 파일을 통해 이러한 구성을 사용자 지정할 수 있는 옵션이 있습니다.

출처 참조

Post Comment

당신은 놓쳤을 수도 있습니다