Convert queue

[aereeeee]

web

(기존코드 참고)
DropInput, DropZone -> upload 훅 만들수 있을듯

const formData = createFormData({ file });
const {
  status,
  slideUrls,
  fileUrl,
  slideRatioList,
} = await uploadFile(channelId, formData);

uploadFile()

  const response = await post({
    url: `${CONVERT_API}/${channelId}`,
    body: data,
  });
  const {
    status,
    slideUrls,
    fileUrl,
    slideRatioList,
  } = await response.json();

converter

(기존코드 참고)

1. auth
   • 사용자 인증이 실패하면 401에러를 응답한다.
2. save
   • 요청이 들어오면 pdf파일을 temp폴더에 write한다.
3. queue
   • 요청을 하나의 job으로 생성한다.
   • job을 큐에 넣어 관리한다.
4. convert
   • 이미지 컨버팅 작업을 진행한다.
   • 컨버팅이 완료되면 다음 작업을 큐에서 꺼내 시작한다.
5. upload
   • 컨버팅 완료된 작업을 오브젝트 스토리지에 upload한다.
6. remove
   • 업로드 완료된 파일을 temp폴더에서 unlink하여 제거한다.
7. response
   • 오브젝트 스토리지에 업로드된 이미지url을 클라이언트에 응답한다.

---

OS단에서 동작하는 gm어플리케이션은 openMP기술을 이용하여 이미지 프로세싱 요청에 대해 사용가능한 모든 CPU자원을 최대로 사용하는 멀티스레드 방식으로 동작합니다. 따라서 한번에 많은 요청이 들어오면 서버가 CPU부하를 견디지 못하고 다운되었던 것입니다.

10mb 한장의 pdf 파일을 컨버팅하는데 loadAverage로 약 0.2를 기록하였으나, 이미지 장수가 늘어남에 따라 1/10 용량임에도 불구하고 loadAverage가 급격하게 치솟았습니다.

용량이 큰 파일 한장 처리(하나의 프로세스가 최대의 스레드 관리) <<<< 한번에 여러장 처리(모든 프로세스가 최대의 스레드를 사용하려고 하는걸까) -> n개의 요청에 대한 응답시간이 n * m

사실 activeLimit이 cpu가용량에 따라 바뀌어야하는데 이건 파일 장수일 때 의미가 있는 것을 지금 깨달은듯..? 지금은 1로 고정되어잇고, 즉 요청 한개씩만 들어가게 했다는것 -> 장수 엄청 많은 pdf넘겼을때 뻑난 이유

최선

• 한번에 서버 가용치의 장수를 컨버팅하기 -> 계산/예측 힘들다 checkCPU, checkMem 만들었지만..
• 어쨌든 서버 한대로 안된다
• 뭔가 gm에 옵션이 있을듯 한데 한번에 몇장 동시에 처리하도록 하는것..

개선

• 스케일아웃하여 들어오는 요청을 하나씩 배분하기, s3 동적 스케일아웃 서비스 이용.. -> 커넥션 중단 시 clear 필요
• 서버 대수 고정되어있다면... 한장씩 쪼개서 배분/ 합쳐서 주기 -> 이 경우는 카프카 필요할듯 -> 커넥션 중단 시 ?
• 장수 많은 파일에 대해서 커넥션 타임아웃에 대한 대책 필요

---

결론: pdf파일을 한 장씩 쪼개서 큐에 넣고 -> 여러 서버에 배분하여 처리 -> 완료된 이미지 사용

• 카프카 : aws msk

  • https://docs.aws.amazon.com/msk/latest/developerguide/what-is-msk.html
  • https://blog.voidmainvoid.net/299
  • +간편, 모니터링도 붙일 수 있음
  • -비쌈

• rabbitMQ

  • https://www.sipmann.com/microservices_nodejs_express_rabbitmq_part_2.html#.Xu8Gw2ozZ24
  • 웹인터페이스제공
  • 시스템 간단