[72일 차] 21.11.04 : DevOps 13

비동기 디커플링

SQS

---

1교시

 

 

비동기 디커플링과 메시지 큐

 

• 인프라(시스템) 관련해서 동기와 비동기의 차이는?

-> 동기는 데이터를 요청하면 데이터 생산자(응답자)에게 바로 간다.

-> 비동기는 이메일을 생각하면 된다. 데이터를 요청하면(이메일을 보내면) 이메일함에 이메일이 들어가고, 응답자가 이메일함을 보고 응답한다.

 

분산 처리 환경에서는 비동기식 처리 방식이 더 좋다.

데이터가 주르륵 들어오면 이메일함(큐)에 주르륵 들어가 있고, 앞에서부터 빼서 처리한다.

 

동기 시스템이라면 요청이 바로 응답자에게 가는데, 요청이 많으면 응답 프로세스에 과부하가 걸린다.

비동기 시스템이라면 요청자->수신자->큐->응답자->큐->수신자->요청자 순서로 흘러간다.

식당에 비유하면 수신자와 응답자는 웨이터와 요리사라고 볼 수 있다. 요청을 전달해준다는 것 외에는 서로에게 영향을 미치지 않고, 기다리지도 않으니 독립적이다.

큐는 왜 있는 것인가?

-> 요리사(응답자)가 주문(요청)을 처리하는 동안, 다른 요청들을 잠시 저장할 공간이 필요하기 때문이다.

 

이런 비동기 방식에서 사용하는 큐의 역할을 해주는 서비스가 SQS(Simple Queue Service)

 

• Message Queue

메시지 큐는 애플리케이션 간 비동기 통신을 위해 사용한다. 비동기 통신이기에 즉각적인 응답을 요구하지는 않는다.

응답자가 중단되었든, 종료되었든, 다른 작업을 하느라 바쁘든 간에 도착해 있는 요청들을 저장할 공간이 필요하다.

그 일시적 저장 공간을 메시지 큐가 제공한다.

---

2교시

 

 

메시지 큐의 장점

2개 이상의 애플리케이션이 서로 연결되어 있지 않고 통신을 할 수 있다.

하나의 앱은 다른 앱의 구현을 알지 못한다(= 둘 사이의 의존성이 없다). 이런 분리를 통해

-> 한 앱의 변경이 다른 앱에 영향을 주지 못한다.

-> 하나의 통제하는 앱을 전반적인 복잡성을 낮추는 여러 개의 작은 앱으로 나눌 수 있다.

-> 유지 보수와 디버깅이 쉽다

-> 크로스플랫폼 앱을 만들 수 있다. 작은 앱은 언어와 스케일에 상관없이 독립적으로 개발될 수 있다.

-> 시스템의 안정성과 성능 향상을 가져올 수 있다.

producer는 consumer가 사용 가능해질 때까지 기다릴 필요 없이 큐에 요청을 추가할 수 있다. consumer는 가능할 때 메시지를 처리하기에 대기 시간의 오버로드가 발생하지 않는다. 메시지 큐는 메시지를 항상 보관하고 있기에 양쪽 앱이 사용 불가능하더라도 데이터 유실 없이 시스템의 고장을 방지할 수 있다.

 

SQS는 전체 시스템이 가지고 있을 큐 서비스를 대체해야 하므로 용량이 크다.

 

 

URI 미리보기 이미지를 만드는 과정 예시

1. 사용자가 URL 제출

2. 서버가 URL에서 콘텐츠를 다운로드하고 이것을 PNG 이미지로 변환

3. 서버가 사용자에게 해당 PNG 반환

이렇게 굴러가던 기존 과정을 비동기식으로 바꾸면

1. 사용자가 URL 제출

2. 서버가 메시지를 임의의 ID와 URL을 포함하고 있는 큐에 입력

3. 서버가 사용자에게 링크를 반환. 링크는 임의의 ID를 포함

4. 백그라운드에서 작업자가 큐에서 메시지를 꺼내고, 콘텐츠를 다운로드하고, 콘텐츠를 PNG로 변환한 후 S3에 업로드

5. 추후 사용자에게 알려준 위치(링크)에서 PNG 다운로드 시도

 

 

터미널에서 받은 파일의 경로로 이동, AWS-CLI 및 사용자 등록 확인

(aws --version과 aws configure 실행)

 

일단 S3 버킷 생성 : aws s3 mb s3://버킷명

정적 웹 사이트 호스팅 설정

-> aws s3 website s3://url2png-jwk --index-document index.html --error-document error.html

 

다음은 콘솔에서. 서비스에서 Simple Queue Service 찾아서 들어가자.

대기열(queue) 생성 > 이름 작성, 나머지는 기본값으로 두고 생성

생성된 대기열의 URL 복사해두기. 이것이 엔드포인트가 될 것이다.

https://sqs.ap-northeast-2.amazonaws.com/562664808209/url2png

---

3~5교시

 

 

터미널에서 npm install -g npm-check-updates 실행해서 업데이트하고

ncu -u로 버전 확인 후 npm install 실행해서 업데이트 및 패키지 설치

 

https://dog-developers.tistory.com/183

[PowerShell] 이 시스템에서 스크립트를 실행할 수 없으므로 파일을 로드할 수 없습니다. 자세한 내

자꾸 ncu-u 실행하는데 권한 문제가 떠서 뭔가 해서 찾아봤다.

 

그리고 node index.js https://aws.amazon.com 실행해서 큐 쿼리를 넣어야 하는데...여기서 자꾸 에러가 뜬다.

없는 큐라고 한다. 왜 자꾸 이러지?

-> 순서 문제였다.

npm install로 패키지 설치하기 전에 index.js/config 파일에 있는 정보를 미리 수정해야 한다. 패키지를 설치하는 동시에 리전 정보가 들어가나 보다.

 

어쨌건 수정 후 패키지 설치하고 node index.js https://aws.amazon.com 실행

-> 실행해서 나온 URL 복사해두기

http://url2png-jwk.s3-website-ap-northeast-2.amazonaws.com/854e55b6-7147-4743-96ad-67ad43a0fd09.png

 

aws sqs get-queue-attributes --queue-url [큐 URL] --attribute-name ApproximateNumberOfMessages

-> 내가 보낸 큐의 숫자가 나온다.

 

node worker.js 실행

-> 이 경우에 발생하는 primordials is not defined 에러는 버전 문제.

-> gulp를 버전 4로 업드레이드하거나, Node.js를 11 이하로 다운그레이드 하던가.

 

생산자 환경 작업

package.json 수정 내용

{

   "dependencies": {

      "aws-sdk": "2.1021.0",

      "node-uuid": "^1.4.8",

      "webshot": "0.18.0"

   },

   "scripts": {

      "preinstall": "npx npm-force-resolutions"

   },

   "resolutions": {

      "graceful-fs": "4.2.3"

   },

   "private": true

}

 

생산자 환경 작업이 끝나면

작업자 환경 작업

 

강사님은 이렇게 해서 하셨다는데... 나는 해도 안되더라.

그냥 npm install node@11.15.0 실행해서 다운그레이드 했다.

 

다 성공하고 node worker.js를 실행하면

이런 식으로 뜬다.

 

이러고 S3 버킷을 보면 이미지 파일들이 저장되어 있다.

 

4번 전송했으니 4개 있다.

 

해당 파일의 URL로 들어가 보면 이미지가 뜬다.

 

 

 

 

 

 

 

 

 

---

6교시

 

 

어제 했던 동기식 디커플링 인프라는 사용량을 트리거로 오토 스케일링 그룹에 알림을 보내는 것이었다.

 

사용자끼리 북마크를 공유할 수 있는 소셜 북마크 서비스를 이용하는 상황.

이때 링크된 웹 사이트의 미리보기가 중요한 기능이라고 가정.

하지만 대부분의 사용자가 서비스에 새로운 북마크를 추가하는 저녁 시간에는 URL을 PNG로 변환하는 속도가 느려진다.

이러면 고객은 미리보기가 즉시 표시되지 않아 불만이 생긴다.

운영 측은 저녁에 급증하는 부하를 처리하고자 오토 스케일링을 사용하고 싶을 것이다.

그렇게 하려면 북마크 등록과 미리 보기 생성 작업을 분리해야 한다.

 

• 북마크 만들기 작업 

-> 새로운 북마크의 고유 ID와 URL을 담은 메시지가 SQS로 전달된다.

-> Node.js 애플리케이션을 수행 중인 EC2 인스턴스에서 SQS 큐를 polling

-> Node.js 애플리케이션이 URL을 읽어서 스크린숏 생성

-> 스크린숏을 S3 버킷에 업로드하고, 객체 키를 고유 ID로 설정

-> 사용자는 이 고유 ID로 웹사이트의 스크린샷을 S3에서 직접 다운로드

---

7~8교시

 

 

메시지 생산자 -> SQS -> 지표를 CloudWatch에 전송

SQS는 받은 메시지를 Auto Scaling Group으로 전달

CloudWatch는 지표 트리거를 감지, Auto Scaling Group으로 알람 전달 -> 오토 스케일링 그룹은 EC2 장비 확장

(SQS에 처리되지 않은 메시지를 지표로 삼는다)

 

 

어쨌거나 스택을 모두 배포 후, 부하를 위해 업데이트

 

SQS가 메시지를 처리하지 못하는 문제 발생

---

6교시(15:45~16:00) 실습 설명 다시 듣기

7교시(16:45) IAM 부분 설명 다시 듣기