Sidekiq에서 ECS 프로그램으로 가져오기

메일을 보내는 것과 재처리를 분리해서 실행하면 비동기 작업을 사용하려고 할 때가 있습니다.
레일에 액티브 잡(ActiveJob)이라는 작업 관리 API가 준비돼 있어 이를 사용하지 않는 방법은 없다.
Rails Guide임무를 수행하다에 나와 있는 것처럼 공식 환경에서는 일부 대기 백엔드를 사용해야 합니다.
제품 환경에서 작업의 대기열에 로그인하고 실행할 때, 대기열의 백엔드를 미리 준비해야 합니다.구체적으로 Rails가 사용해야 할 제3자의 줄 서기 라이브러리를 확인해야 한다.Rails가 직접 제공하는 것은 스토리지에 작업을 저장하는 간접 대기열 시스템뿐입니다.프로세스가 충돌하거나 컴퓨터가 재설정되면 기본 비동기 백엔드 동작은 주요 작업을 잃어버릴 수 있습니다.만약 응용 프로그램이 소규모나 임무가 중요하지 않은 임무라면 상관없지만, 많은 제품에서 영구적인 백엔드를 선택해야 한다.
그곳에서 작업 관리에 편리한 것은 Sidekiq이다.

그러나 실제 가져오면 Gem뿐만 아니라 개발 환경을 준비해야 하는 docker-compose[1]도 CI가 작업할 수 있는 테스트가 필요하다.
이 밖에 정식 공연에서의 집행 환경도 준비해야 한다.
Sidekiq를 사용하지 않은 자신에게 할 일이 너무 많고 힘들기 때문에 다음은 남을 도울 수 있는 일의 총결산을 써야 한다.
내용은 다음과 같다.

Sidekiq의 기초 지식

개발 환경의 준비

CI 설정(CodeBuild)

ECS(제본/공식 환경)의 Sidekiq 용기 추출

Elasticache

Sidekiq의 기본 사항

Sidekiq에서 작업을 Worker라고 합니다.ActiveJob에서는 워크맨이라고 불리기 때문에 처음에는 혼란스러웠다.
다음 그림에서 보듯이 app의 용기와sidekiq의 용기는redis를 통해enqueue,dequeue를 진행한다.컨테이너에서 작업을 수행합니다.

개발 환경 준비

용기

version: "3.7"
services:
 redis:
   image: redis:6
   ports:
     - 6379:6379
   volumes:
     - ./redis/redis.conf:/usr/local/etc/redis/redis.conf
   command: redis-server /usr/local/etc/redis/redis.conf
   sysctls:
     - net.core.somaxconn=512

등록 퀘스트는 Redis가 필요합니다.
redis 설정 파일을 용기에 복사합니다.
redis.conf는 다음과 같습니다.

# The filename where to dump the DB
dbfilename dump.rdb

컨테이너를 가동할 때 다음과 같은 오류에 대응하는 조치다.

Redis::CommandError (MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.)

리디스 데이터를 포장하는 데 사용할 파일을 지정하면 취소됩니다.
command에서 Redis-server를 시작할 때 이 설정 파일을 참조하십시오.
또한sysctls에서 somaxconn을 512로 설정합니다.이것은 아래의 오류에 대한 대응이다.

# WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

Redis 소개의 글은 다음과 같다.
TCP 백그라운드 로그(수신 가능한 TCP 세션 수)의 OS 기본값은 128이지만 기본값은 Redis로 511이므로 OS의 백그라운드 로그가 확장됩니다.
somaxconnn은 socket max connections의 줄임말로 Redis의 기본 지정치보다 낮다는 욕을 먹는 것 같습니다.

컨테이너

version: "3.7"
services:
　redis: # 省略

  sidekiq:
   depends_on:
   - db
   - redis
   build:
     context: .
     target: test
     dockerfile: ./dockerfiles/Dockerfile
   command: bundle exec sidekiq -C config/sidekiq.yml
   environment:
     REDIS_URL_SIDEKIQ: redis://redis:6379/5/sidekiq
     DB_HOST: hoge
     DB_NAME: hoge
     RAILS_ENV: development

app와 같은 Docker file을 사용하여build를 진행했습니다.
다단계 구축이기 때문에 직접 사용하면 RAILSENV를 사용하여 Production이 되는 컨테이너.
이러한 상황target: test을 방지하기 위해 우리는 테스트 단계의 컨테이너 이미지를 임시로 사용했다.
command는 파일 지정을 설정한 후 시작합니다. config/sidekiq.yml은 기본 파일 경로이기 때문에 쓰지 않아도 읽을 수 있습니다.나는 설정 파일이 있다는 것을 명시하기 위해 특별히 썼다.
redis의 연결 대상을 환경 변수로 지정합니다.docker-compose는 서비스 이름으로 네트워크 작업을 지정할 수 있기 때문redis://.
또한sidekiq용기에서 DB로부터 작업과 관련된 데이터를 얻거나 DB에 기록된 작업이 있다고 판단해 DB의 연결 정보를 전달했다.
sidekiq.다음은 yml입니다.queues에 메일을 추가하지 않으면 메일을 보내지 않습니다. 주의하십시오.

---
:queues:
 - default
 - mailers

공식 설정 예는 여기.에 있다.

CI 설정(CodeBuild)

build:
  commands:
    - docker-compose -f docker-compose.yaml build
    # redisを起動する
    - docker-compose -f docker-compose.yaml up -d db redis
    - docker-compose -f docker-compose.yaml -f run app bundle exec rspec

작업 테스트를 위해 CI를 설정해야 합니다.
buildspec에서 테스트를 실행하기 전에 Redis를 시작해야 합니다.
또한gemmock_redis처럼위선적인KVS를 사용하는 것도 한 방법이다.

ECS에 대한 Sidekiq 컨테이너 디버깅

app와nginx의 용기는 같은 ECS 작업이지만 이 작업은sidekiq 용기를 추가하지 않았습니다.
원본 코드는 같은 Giithub 창고에서 관리하기 때문에 응용과 동시에 sidekiq 컴퓨터를 디버깅할 수 있는 것이 장점이다.단, 앱 용기가 시작되지 않으면 작업이 멈추기 때문에sidekiq 용기가 함께 멈춥니다.
만약 다른 작업으로 이 문제를 피할 수 있다면,sidekiq 용기만 증가하거나 줄이는 것도 매우 간단합니다.그리고 작업에만 필요한 계산 자원에 맞추어 CPU와 메모리를 설정할 수 있기 때문에 서버 자원의 사용도 효율적이다.
Docker의 이미지는 앱과 같다.ECS에 대한 디버깅은hako를 사용했기 때문에hako가 정의한 jsonneet 파일에서 디버깅할 때bundle exec sidekiq -C config/sidekiq.yml 명령을 덮어썼습니다.

  app: {
    image: '[aws-account-id].dkr.ecr.ap-northeast-1.amazonaws.com/[repo-name]',
    tag: 'latest',
    command: [
      "bundle",
      "exec",
      "sidekiq",
      "-C",
      "config/sidekiq.yml"
    ],
    cpu: '256',
    memory: '512',
  },

Elasticache

Sidekiq 컨테이너가 시작될 때 다음 Warning이 나타납니다.
WARNING: Your Redis instance will evict Sidekiq data under heavy load.
The 'noeviction' maxmemory policy is recommended (current policy: 'volatile-lru').
이것은 Redis의 메모리가 넘칠 때의 행동에 대한 설정입니다.redis의 일본어 문서에 각종 전략의 행위가 쓰여 있다.
사용된 Redis 서버의 Cache Parameter Group Family는 Redis5입니다.0으로 설정합니다.
기본 maxmemory policy는volu입니다.
CloudFormation에서 다음을 지정하여 maxmemory policy를 변경했습니다.Properties의 가치에는 Properties도 지정되어 있습니다.

Resources:
  ParameterGroup:
    Type: AWS::ElastiCache::ParameterGroup
    Properties:
      Properties: {
        "maxmemory-policy" : !Ref MaxMemoryPolicy
      }

워닝에 대응하는 설정이 바뀌었지만 실제 활용에서는 리디스 서버의 메모리 상황을 감시하기만 하면 그렇게 신경 쓸 필요가 없다.
이상은 Sidekiq에서 정식 환경으로 가져온 디자인입니다.
하코와 같은 ECS 개발 도구는 사용하지 않는 경우도 많다고 생각하므로 적절히 교체해 참고하시기 바랍니다.
각주
로컬 서버도 실행할 수 있지만 디버깅을 할 때 컨테이너로 이동하면 컨테이너를 준비하는 것이 좋다↩︎