Elastic Beanstalk 작업자 환경 - AWS Elastic Beanstalk

Elastic Beanstalk 작업자 환경

AWS Elastic Beanstalk 애플리케이션에서 완료하는 데 오래 걸리는 작업 또는 워크플로를 수행할 경우 해당 작업을 전용 작업자 환경에 오프로드할 수 있습니다. 부하가 높은 시간에도 애플리케이션이 계속 응답하도록 하려면 차단 작업을 수행하는 프로세스에서 웹 애플리케이션 프런트 엔드를 분리하는 것이 일반적인 방법입니다.

작업이 오래 실행되면 이미지 또는 비디오 처리, 이메일 보내기, ZIP 아카이브 생성 등과 같은 요청을 완료하는 데 걸리는 시간이 급격하게 증가합니다. 이러한 작업을 1~2초 만에 완료할 수도 있지만, 일반적으로 500밀리초 이내에 완료되는 웹 요청에서는 몇 초만 지연되더라도 긴 시간입니다.

한 가지 방법은 작업자 프로세스를 로컬로 생성하고, 성공 메시지를 반환하고, 작업을 비동기 방식으로 처리하는 것입니다. 이는 인스턴스에서 전송되는 모든 작업을 계속 수행할 수 있는 경우 유효합니다. 하지만 부하가 높아질 경우 인스턴스는 백그라운드 작업을 따라잡지 못하고 우선 순위가 높은 요청에 응답하지 못할 수 있습니다. 개별 사용자가 여러 작업을 생성할 수 있는 경우 부하의 증가가 사용자 증가와 일치하지 않아서 웹 서버 티어를 효과적으로 확장하는 것이 어려울 수 있습니다.

장시간 실행 작업을 로컬로 실행하는 것을 피하려면 프로그래밍 언어에 대한 AWS SDK를 사용하여 해당 작업을 Amazon Simple Queue Service(Amazon SQS) 대기열로 보내고, 별도 인스턴스에서 작업을 수행하는 프로세스를 실행합니다. 그런 다음 용량이 충분한 경우에만 대기열에서 항목을 가져와서 실행하여 부하가 걸리는 것을 방지하도록 이러한 작업자 인스턴스를 설계합니다.

Elastic Beanstalk 작업자 환경에서는 Amazon SQS 대기열을 관리하고 대기열에서 읽는 각 인스턴스에서 데몬 프로세스를 실행하여 이 프로세스를 간소화합니다. 데몬은 대기열에서 항목을 가져올 때 대기열 메시지 내용을 본문에 포함하여 HTTP POST 요청을 포트 80에서 http://localhost/에 로컬로 보냅니다. 애플리케이션에서는 POST에 대한 응답으로 장시간 실행 작업만 수행하면 됩니다. 다른 경로에 게시하거나, 애플리케이션/JSON과 다른 MIME 유형을 사용하거나, 기존 대기열에 연결하거나, 연결(최대 동시 요청), 시간 초과, 재시도 등을 사용자 지정하도록 데몬을 구성할 수 있습니다.


      Elastic Beanstalk 작업자 환경 Amazon SQS 메시지 처리

정기적 작업을 사용하여 cron 일정에 따라 메시지를 대기열에 넣도록 작업자 데몬을 구성할 수도 있습니다. 각 정기적 작업을 서로 다른 경로에 게시할 수 있습니다. 각 작업에 대한 일정과 경로를 정의하는 YAML 파일을 소스 코드에 포함하여 정기적 작업을 활성화합니다.

참고

Windows Server 플랫폼의 .NET에서는 작업자 환경을 지원하지 않습니다.

작업자 환경 SQS 데몬

작업자 환경에서는 Elastic Beanstalk에서 제공되는 데몬 프로세스를 실행합니다. 기능을 추가하고 버그를 수정하기 위해 이 데몬을 정기적으로 업데이트합니다. 최신 버전의 데몬을 가져오려면 최신 플랫폼 버전으로 업데이트하십시오.

작업자 환경의 애플리케이션에서 요청을 수신하여 성공적으로 처리했음을 나타내는 200 OK 응답을 반환할 경우 데몬은 DeleteMessage 호출을 Amazon SQS 대기열에 전송하여 대기열에서 메시지를 삭제합니다. 애플리케이션에서 200 OK 이외의 응답을 반환할 경우 Elastic Beanstalk는 구성된 ErrorVisibilityTimeout 기간이 경과할 때까지 대기한 후 메시지를 대기열에 다시 넣습니다. 응답이 없는 경우 메시지 처리에 다른 시도가 가능하도록 Elastic Beanstalk는 InactivityTimeout 기간이 경과할 때까지 대기한 후 메시지를 대기열에 다시 넣습니다.

참고

Amazon SQS 대기열의 속성(메시지 순서, 최소 한 번 제공, 메시지 샘플링)이 작업자 환경에 대한 웹 애플리케이션 설계 방법에 영향을 줄 수 있습니다. 자세한 내용은 Amazon Simple Queue Service 개발자 안내서분산 대기열의 속성 단원을 참조하십시오.

Amazon SQS에서는 구성된 RetentionPeriod보다 더 오래 동안 대기열에 있는 메시지를 자동으로 삭제합니다.

데몬은 다음 HTTP 헤더를 설정합니다.

HTTP 헤더

이름

사용자 에이전트

aws-sqsd

aws-sqsd/1.11

X-Aws-Sqsd-Msgid

메시지 폭풍(새 메시지의 수가 비정상적으로 많은 경우)을 감지하는 데 사용되는 SQS 메시지 ID

X-Aws-Sqsd-Queue

SQS 대기열의 이름.

X-Aws-Sqsd-First-Received-At

메시지를 처음 수신한 UTC 시간(ISO 8601 형식)

X-Aws-Sqsd-Receive-Count

SQS 메시지 수신 수.

X-Aws-Sqsd-Attr-message-attribute-name

처리 중인 메시지에 할당된 사용자 지정 메시지 속성입니다. message-attribute-name은 실제 메시지 속성 이름입니다. 모든 문자열 및 숫자 메시지 속성은 헤더에 추가됩니다. 이진 속성은 삭제되고 헤더에 포함되지 않습니다.

Content-Type

MIME 유형 구성(기본값: application/json)

배달 못한 편지 대기열

Elastic Beanstalk 작업자 환경에서는 Amazon Simple Queue Service(Amazon SQS) 배달 못한 편지 대기열을 지원합니다. 배달 못한 편지 대기열은 어떠한 이유로 다른 (소스) 대기열이 성공적으로 처리할 수 없는 메시지를 대상으로 전송할 수 있는 대기열입니다. 배달 못한 편지 대기열을 사용하는 주요 이점은 성공적으로 처리되지 않은 메시지를 제외하고 격리하는 기능입니다. 그러면 배달 못한 편지 대기열에 전송된 메시지를 분석하여 성공적으로 처리되지 못한 이유를 확인할 수 있습니다.

작업자 환경 티어를 생성할 때 자동 생성된 Amazon SQS 대기열을 지정한 경우 배달 못한 편지 대기열이 작업자 환경에 대해 기본적으로 활성화됩니다. 작업자 환경에 대해 기존 SQS 대기열을 선택한 경우 SQS를 사용하여 배달 못한 편지 대기열을 독립적으로 구성해야 합니다. SQS를 사용하여 배달 못한 편지 대기열을 구성하는 방법에 대한 자세한 내용은 Amazon SQS 배달 못한 편지 대기열 사용 단원을 참조하십시오.

배달 못한 편지 대기열을 비활성화할 수 없습니다. 전달할 수 없는 메시지는 항상 배달 못한 편지 대기열로 전송됩니다. 하지만 MaxRetries 옵션을 최대 유효 값 100으로 설정하여 이 기능을 효과적으로 비활성화할 수 있습니다.

작업자 환경의 Amazon SQS 대기열에 배달 못한 편지 대기열이 구성되어 있지 않은 경우, Amazon SQS는 보존 기간이 만료될 때까지 메시지를 대기열에 보관합니다. 보존 기간 구성에 대한 자세한 내용은 작업자 환경 구성 단원을 참조하십시오.

참고

Elastic Beanstalk MaxRetries 옵션은 SQS MaxReceiveCount 옵션과 같습니다. 작업자 환경에서 자동 생성된 SQS 대기열을 사용하지 않을 경우 SQS의 MaxReceiveCount 옵션을 사용하여 배달 못한 편지 대기열을 효과적으로 비활성화할 수 있습니다. 자세한 내용은 Amazon SQS 배달 못한 편지 대기열 사용 단원을 참조하십시오.

SQS 메시지의 수명 주기에 대한 자세한 내용은 메시지 수명 주기 단원을 참조하십시오.

정기적 작업

정기적으로 작업자 환경의 대기열에 작업을 자동으로 추가하도록 소스 번들의 cron.yaml 파일에서 정기적 작업을 정의할 수 있습니다.

예를 들어, 다음 cron.yaml 파일은 두 개의 주기적 작업을 생성합니다. 첫 번째는 12시간마다 실행되고 두 번째는 UTC 기준 매일 오후 11시에 실행됩니다.

예 cron.yaml

version: 1 cron: - name: "backup-job" url: "/backup" schedule: "0 */12 * * *" - name: "audit" url: "/audit" schedule: "0 23 * * *"

name은 각 작업에 대해 고유해야 합니다. URL은 POST 요청을 전송하는 작업을 트리거하는 경로입니다. schedule은 작업이 실행되는 시간을 결정하는 CRON 표현식입니다.

작업이 실행되면 데몬은 작업을 수행해야 함을 나타내는 헤더와 함께 메시지를 환경의 SQS 대기열에 게시합니다. 환경의 인스턴스에서 메시지를 선택하고 작업을 처리할 수 있습니다.

참고

작업자 환경을 기존 SQS 대기열로 구성하고 Amazon SQS FIFO 대기열을 선택하면 주기적 작업이 지원되지 않습니다.

Elastic Beanstalk에서는 리더 선정을 사용하여 작업자 환경에서 정기적 작업이 대기 중인 인스턴스를 결정합니다. 각 인스턴스는 Amazon DynamoDB 테이블에 기록하여 리더가 되려고 시도합니다. 시도를 성공한 첫 번째 인스턴스가 리더가 되며 리더 상태를 유지하려면 테이블에 계속해서 기록해야 합니다. 리더가 종료되면 다른 인스턴스가 그 자리를 빠르게 차지합니다.

정기적 작업의 경우 작업자 데몬은 다음과 같은 추가 헤더를 설정합니다.

HTTP 헤더

이름

X-Aws-Sqsd-Taskname

정기적 작업에서 수행할 작업의 이름입니다.

X-Aws-Sqsd-Scheduled-At

정기적 작업이 예약된 시간

X-Aws-Sqsd-Sender-Id

메시지를 보낸 사람의 AWS 계정 번호

작업자 환경 티어에서 Auto Scaling에 Amazon CloudWatch 사용

Amazon EC2 Auto Scaling과 CloudWatch는 작업자 환경에서 실행 중인 인스턴스의 CPU 사용률을 함께 모니터링합니다. CPU 용량에 대한 자동 조정 제한을 구성하는 방법에 따라 Auto Scaling 그룹이 Amazon SQS 대기열에서 메시지 처리량을 적절히 관리하기 위해 실행하는 인스턴스 수가 결정됩니다. 각 EC2 인스턴스는 CPU 사용량 측정치를 CloudWatch에 게시합니다. Amazon EC2 Auto Scaling은 CloudWatch에서 작업자 환경의 모든 인스턴스에 대한 평균 CPU 사용량을 검색합니다. CPU 용량에 따라 추가하거나 종료할 인스턴스 수, 상한 임계값 및 하한 임계값을 구성합니다. Amazon EC2 Auto Scaling에서 CPU 용량에 대해 지정된 상위 임계 값에 도달한 것을 감지하면 Elastic Beanstalk는 작업자 환경에서 새 인스턴스를 생성합니다. CPU 부하가 임계값 아래로 다시 떨어지면 인스턴스가 삭제됩니다.

참고

인스턴스를 종료할 때 처리되지 않은 메시지는 아직 실행 중인 인스턴스의 다른 데몬에서 처리할 수 있도록 대기열에 반환됩니다.

필요한 경우 Elastic Beanstalk 콘솔, CLI 또는 옵션 파일을 사용하여 다른 CloudWatch 경보를 설정할 수도 있습니다. 자세한 내용은 Amazon CloudWatch에서 Elastic Beanstalk 사용단계 조정 정책으로 Auto Scaling 그룹 생성을 참조하십시오.

작업자 환경 구성

[환경 관리 콘솔]의 [구성] 페이지에서 [작업자] 범주를 편집하여 작업자 환경의 구성을 관리할 수 있습니다.


        Elastic Beanstalk 콘솔의 작업자 수정 구성 페이지
참고

작업자 대기열 메시지를 게시하기 위한 URL 경로를 구성할 수 있지만 IP 포트를 구성할 수는 없습니다. Elastic Beanstalk는 작업자 대기열 메시지를 항상 포트 80에서 게시합니다. 작업자 환경 애플리케이션이나 그 프록시는 포트 80에서 수신해야 합니다.

작업자 데몬을 구성하려면

  1. Elastic Beanstalk 콘솔을 연 다음 [Regions] 목록에서 AWS 리전을 선택합니다.

  2. 탐색 창에서 환경을 선택한 다음 목록에서 환경의 이름을 선택합니다.

    참고

    환경이 많은 경우 검색 창을 사용하여 환경 목록을 필터링합니다.

  3. 탐색 창에서 구성을 선택합니다.

  4. [작업자] 구성 범주에서 [편집]을 선택합니다.

[ Modify worker] 구성 페이지에는 다음과 같은 옵션이 있습니다.

[대기열] 섹션:

  • 작업자 대기열 – 데몬이 읽을 Amazon SQS 대기열을 지정합니다. 대기열이 있는 경우 기존 대기열을 선택할 수 있습니다. 자동 생성된 대기열을 선택한 경우 Elastic Beanstalk에서 새 Amazon SQS 대기열과 해당 작업자 대기열 URL을 생성합니다.

    참고

    자동 생성 대기열을 선택하면 Elastic Beanstalk가 생성하는 대기열이 표준 Amazon SQS 대기열입니다. 기존 대기열을 선택하면 표준 또는 FIFO Amazon SQS 대기열을 제공할 수 있습니다. FIFO 대기열을 제공하면 정기적인 작업이 지원되지 않습니다.

  • 작업자 대기열 URL – 기존 작업자 대기열을 선택한 경우 이 설정은 해당 Amazon SQS 대기열에 연결된 URL을 표시합니다.

[메시지] 섹션:

  • HTTP 경로 – Amazon SQS 대기열에서 데이터를 수신할 애플리케이션에 대한 상대 경로를 지정합니다. 데이터가 HTTP POST 메시지의 메시지 본문에 삽입됩니다. 기본값은 /입니다.

  • MIME 유형 – HTTP POST 메시지에 사용되는 MIME 유형을 나타냅니다. 기본 값은 application/json입니다. 하지만 고유한 MIME 유형을 생성한 다음 지정할 수 있으므로 모든 값은 유효합니다.

  • HTTP 연결 – 데몬이 Amazon EC2 인스턴스 내의 애플리케이션에 생성할 수 있는 최대 동시 연결 수를 지정합니다. 기본값은 50입니다. 1 ~ 100을 지정할 수 있습니다.

  • 제한 시간 초과 – 처리를 위해 Amazon SQS 대기열에서 수신되는 메시지를 잠그는 시간(초)을 나타냅니다. 구성된 시간이 경과한 이후에는 다른 데몬에서 읽을 수 있도록 메시지가 대기열에 다시 표시됩니다. 애플리케이션에서 메시지를 처리하는 데 필요하다고 생각하는 것보다 더 긴 값을 선택하십시오. 최댓값은 43200초입니다.

  • 제한 시간 초과 오류 – 명시적인 오류로 인해 처리 시도가 실패한 이후에 Elastic Beanstalk에서 메시지를 Amazon SQS 대기열로 반환할 때까지 경과하는 시간(초)을 나타냅니다. 0 ~ 43200초를 지정할 수 있습니다.

고급 옵션 섹션에서:

  • 최대 재시도 횟수 – Elastic Beanstalk에서 메시지를 배달 못한 편지 대기열로 이동하기 전에 Amazon SQS 대기열로 해당 메시지 전송을 시도하는 최대 횟수를 지정합니다. 기본 값은 10입니다. 1 ~ 100을 지정할 수 있습니다.

    참고

    작업자 환경의 Amazon SQS 대기열에 배달 못한 편지 대기열이 구성되어 있지 않은 경우에는 최대 재시도 횟수 옵션이 적용되지 않습니다. 이 경우, Amazon SQS에서는 대기열에 메시지를 보존하고 보존 기간 옵션에 지정된 기간이 만료될 때까지 메시지를 처리합니다.

  • 연결 제한 시간 – 애플리케이션에 연결하기 위해 대기하는 시간(초)을 나타냅니다. 기본 값은 5입니다. 1 ~ 60초를 지정할 수 있습니다.

  • 비활성 제한 시간 – 기존 애플리케이션 연결에 대한 응답을 대기하는 시간(초)을 나타냅니다. 기본 값은 180입니다. 1 ~ 36000초를 지정할 수 있습니다.

  • 보존 기간 – 메시지가 유효하고 능동적으로 처리되는 시간(초)을 나타냅니다. 기본 값은 345600입니다. 60 ~ 1209600초를 지정할 수 있습니다.

기존 Amazon SQS 대기열을 사용할 경우 작업자 환경을 생성할 때 구성한 설정이 Amazon SQS에서 직접 구성한 설정과 충돌할 수 있습니다. 예를 들어, Amazon SQS에서 설정한 MessageRetentionPeriod 값보다 더 큰 RetentionPeriod 값을 사용하여 작업자 환경을 구성한 경우 Amazon SQS에서는 이 값이 MessageRetentionPeriod를 초과할 경우 메시지를 삭제합니다.

반대로 작업자 환경 설정에서 구성한 RetentionPeriod 값이 Amazon SQS에서 설정한 MessageRetentionPeriod 값보다 작은 경우 Amazon SQS에서 메시지를 삭제할 수 있기 전에 데몬이 메시지를 삭제합니다. VisibilityTimeout의 경우 작업자 환경 설정에서 데몬에 대해 구성한 값이 Amazon SQS VisibilityTimeout 설정보다 우선합니다. Elastic Beanstalk 설정을 Amazon SQS 설정과 비교하여 메시지가 적절히 삭제되는지 확인합니다.