■ 이걸 하는 이유

담당 제품 중 분할 서버가 축소 가능한 상태가 아니기 때문에 향후 이용 사용자의 증가에 대응해야 한다.

분명히 proxy와 웹은 축소할 수 있는 상태입니다!

■ CDP는 원래

AWS 클라우드 디자인 모델(CDP)

시스템 아키텍처를 설계할 때의 문제점과 해결 방법을 정리한 기술 노하우

로고도 있어요!　

자세한 사이트는 여기.입니다. 잘 설명하겠습니다

■ CDP는 원래

이해하기 어려워요. 어쨌든 그렇습니다.

■ CDP는 원래

다음은 "Multi-Server 모드"라고 합니다.

한쪽의 실례가 고장나도 시스템 전체가 작동할 수 있다

■ CDP는 원래

다음은 DB Replication 모드라고 합니다.

한쪽 DB에 장애가 발생해도 데이터 손실 방지

여기까지 잘 아시잖아요.

다음은 배치 CDP에 대한 설명입니다.

여기 질문이 하나 있어요.

배치 처리 규모의 구조 설치 경험이 있는 사람?

그럼

■ 어떤 CDP가 있는지

보고 공부했어요!

[AWS Summit 2012] 클라우드 디자인 모델 #5CDP 배치

■ 어떤 CDP가 있는지

아래 내용을 배웠습니다!

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

AWS에서 작업 워커를 구성하는 최고의 실천 ~ SQS의 볼륨 | Developers.IO

AWS에서 작업 워커를 구성하는 최고의 실천 ~ Brian의 볼륨 | Developers.IO

AWS에서 작업 워커의 모범 사례인 Beanstalk Worker tier의 볼륨을 구성합니다.IO

■ 어떤 CDP가 있는지

요약 CDP

① SQS에 처리 대상의 메시지를 보내고 이 메시지를 받은 워커에서 처리

② 우선 처리할 대기열을 만들고 처리하지만 기본적으로QueueChain과 동일

③ CloudWatch의 한도값은 처리 실례의 수를 증가하거나 감소하지만 이외에 QueChain과 거의 같다

④ JobObserver 모드의 일정 버전

①QueueChain
②Priority Queue
③JobObserver
④Scheduled Autoscaling

어떤 CDP의 도입이 적절한지 연구했다

■ 대략적인 사양 『 이전 』

Jenkins에서 정기적으로 작업을 수행하여 일괄 처리 서버(EC2)에 SSH 로그인

SSH 이전의 EC2에서 케이스 명령 실행 중 $\color {blue} {rm 매개 변수에 따라 다른 처리에서 각각 $

A처리+B처리=1000처리2분마다시작...

$\color{red}{rm ※ 문제점}달러

하나의 실례에서만 상술한 조작을 실행하기 때문에 처리의 수량은 응용의 수량이 증가함에 따라 증가하고 머리가 맞았다

■ 대략적인 방법<다음>

Jenkins에서 정기적으로 작업을 수행하여 일괄 처리 서버(EC2)에 SSH 로그인

SSH 이전 EC2에서 케이스 명령 실행 중 $\color{blue} {rm 처리 대상 파라미터가 있는 SQS 메시지} 달러

를 대기열에 발송

여러 실례에서 정보를 얻기 위한 작업 프로그램을 시작하여 $\color{blue} {rm의 SQS 메시지 형식으로 $

를 쟁탈합니다

작업 프로그램에서 케이스 명령으로 메시지 내의 매개 변수를 시작하는 일괄 처리

결론

QueueChain 모드 도입

하지만 그리 간단하지는 않다

중복 처리 방지 메커니즘 필요

이렇게 하는 거예요.

■ 잠금장치 〃 이전 반복 실행

셸 명령을 통해 실행 중 로컬에서 잠금 파일을 저장하여 중복 실행을 피합니다.

하나의 실례에서 집행하기 위해 이렇게 하면 된다

■ 잠금장치 〃 다음 반복 실행

반복되지 않도록 일괄 처리 서버에서 일반적으로 액세스할 수 있는 Elastic Cache(Redis)에 잠금 저장

발송(send)과 수신(receive)에 저장된 키를 분리하여 일괄 처리가 시작될 때 검사 & 등록이 존재합니다.

종료 시 존재 검사와 삭제를 실행합니다.

■ 사용하는 도구

작업자 실행 도구

Supervisor

데이터 유지 기구의 중복 잠금 방지

Redis

■ 부합하는 부분과 개선점

특별히 맞는 곳이 없음

Elastic Beanstalk의 Worker tier를 이용한 구현

이점

AutoScoling도 자동으로 설정되어 갑작스러운 부하 증가에 대응

단점

현재의 CI, 개발 프로세스에서 수정된 원본 발표 등에 대응할 수 없기 때문에 영향의 범위가 매우 크다.

젠킨스에 의존하지 않는 상태에서 정기적으로 집행하기를 희망한다.

현재 제인킨스가 죽으면 곤란하기 때문에 제인킨스의 사활감시+뉴리릭에서 SQS를 감시하고 있다.

정식 운용 시 작업자가 SQS의 소식을 받지 않고 처리하지 않는 상태가 발생한다

원인 조사와 대응이 필요하다.

■ 참조 사이트

[AWS Summit 2012] 클라우드 디자인 모델 #5CDP 배치

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

AWS에서 작업 워커를 구성하는 최고의 실천 ~ SQS의 볼륨 | Developers.IO

AWS에서 작업 워커를 구성하는 최고의 실천 ~ Brian의 볼륨 | Developers.IO

AWS에서 작업 워커의 모범 사례인 Beanstalk Worker tier의 볼륨을 구성합니다.IO

AWS(Amazon Web Service)에서 일괄 처리를 시작하는 방법에 대한 조사 - 웹 엔지니어의 개발 기록

(하이퍼노트) Elastic Beanstalk에 대한 워커 Tier(cron 같은 일을 해보자) - 소병의 매일 XP 정진

프로세스 모니터링 - ITmedia 엔터프라이즈

AWS 마작 CDP: Job Observer 모드 | Kataoka's Blog

들어주셔서 감사합니다.