개시하다

이 기사는 무엇입니까

AWS의 SQS를 잡queue로 하는 일괄 처리 시스템의 구성에 대해 비교 연구를 진행하고 있다.

특히 콘슈머를 주목한다.

용어는 이쪽 슬라이드를 참고하세요.

AWS 배치 프로세스의 모범 사례IO Meetup 05

이 기사를 쓴 이유

SQS를 사용하여 배치 시스템 생성 시도
랜드를 제외하고는 최근(2019년) 모범 사례를 찾지 못했다.

lambda는 용례와 맞지 않는 사람이 많죠?그래서 썼어요

어떤 분이 연구하셨는지.

평소 업무 능력과 조금 차이가 있는 것을 연구하고 있기 때문입니다.
잘못된 일을 썼으니 뚜렷한 개선점이 있을지도 모른다.

욕먹을 수 있다면 기쁠 거야.

기능

서버 측면(API)

ruby/Rails

python

규모가 큰 시스템용으로 프레임워크를 사용한 경험이 거의 없음

Mysql

etc...

인프라(AWS: 예매권을 시작하는 여유 공간을 사용하지 않음)

EC2,RDS,SQS,etc...

생각

관리 서비스 등을 통해 가능한 한 실장, 운용 시간을 줄이기를 희망한다.

과제.

어떤 체계적인 연구를 위해

조사 시 다음과 같은 시스템을 전제로 한다

개요

기존 Rails의 API 시스템(이하 모바일 앱 시스템이라고 함)
python의 일괄 처리(이하:Worker System)는 억지로 추가하지 않기를 원합니다

시스템 구성

인프라 시설

AWS 사전 요구 사항

기존 시스템은 모두 AWS

Worker System의 장애를 MobileApp System에 적용할 수 없음

안정적인 관리 서비스를 통해 시스템 사이를 희소 결합으로 분리

IN: MobileApp System -> Worker System

AWS SQS

OUT: Worker System -> Mobile App System

Cache(Redis)에 데이터를 넣고 교환

처리 내용

워커 시스템 프로세싱

프로세스 중 15분 이상 소요

처리 중 일괄 처리이지만 가능한 한 빨리(몇 초) 완료하고자 하는 처리

가 있음

토론 내용

개요

비교

consumer

consumer
선량하다
pros
cons
lambda
x
* 사건이 많음 * 안심·안전·여러분을 제일 좋아해요 람바다
*상태에 따라 부팅이 느린 응답: 250ms~8000ms*15분 강제 종료
Beanstalk worker(sqsd)+python API Server(flask?)
△
*관리도구 만세
sqsd에서python이post이기 때문에 내부에서 API 서버를 게으르게 합니다
celery
△
*pythhon 완결*액션 실적 풍부(psyhon 업계의 defact 표준화)*에어플로우 성격과 맞아
*셀러리가 너무 커서·디버깅이 힘든 것 같아요*셀러리는 요즘 활발하지 않은 것 같아요.
pyqs
x
*python에서 *celery 문제를 완성하는 것은 발생하기 어렵다 (celery 문제를 해결하기 위해 완성한 프로젝트인 것 같다)
* 메커니즘 호출 비동기식 방법(⇔63;)xxx.delay.yy()를 위한 것이기 때문에 다른 시스템 사이의queue는 다른 것 같다(줄을 서는 데이터는 celery serialized와 유사한 데이터)* 다소 처리하기 어려운 느낌이 무섭다
SQS니까 혼자 쓸까?
△
-
*github 같은 방법으로 비슷한 소스를 찾았는데 베타감이 무서워 *부채 예감
shoryuken
o
*비교적 치밀하다(sidekiq 비교)*일본어 문서/사례가 많고 성숙도 높다https://github.com/phstc/shoryuken/wiki*익숙한 루비로 조작하기 쉽다
*python과 ruby를 서버에 동시에 설치해야 함
sidekiq
△
*익숙한 루비가 많은 날도 안심
*sqs가 아닌 Redis를 사용하는 것이 기본이라 조금 번거롭습니다.

infra

솔직히 선택의 여지가 없다고 생각해요.

선택 방법

1. 적당하면 lambda

2. docker를 사용하면 docker계

입니다.

3. 안심할 수 있는 EC2 or Beanstalk

연구물

Lambda

Docker 관리 시스템

공개 프레젠테이션

ECS

Kubernetes

관리 서버

Fargate

EC2

자체 관리 시스템

Beanstalk

EC2

결실

과제 시스템에서의 결론

infra

EC2

도커에 대한 경험이 얕기 때문에 설치 속도가 우선

앞으로 ECS 등 관리에 가까운 docker 시스템의 축소가 쉬운 시스템 구조로 변경하고 싶다

consumer

shoryuken

프로젝트로서 성숙했지만 의존하는 중간부품과 config가 적고 간단하고 사용하기 쉬운 인상을 준다

worker

python

shouryuken에서 ptyhon 스크립트 시작하기

결실

처리 속도: 현재 문제 없음

SQS에서 작업 시작 후 0.5초 정도pythn script 시작
빠른 처리가 3초 안에 이루어졌으면 좋겠습니다