본문 바로가기

Backend/Node.js

 (32)
CLI program 주절주절 프롤로그) 팀에서 담당하는 서버 중 이미지 서버가 현재는 요청받은 원본 이미지에 대해 JPEG + WEBP 이미지를 생성해서 업로드하고 있는데 WEBP 가 뒤늦게 추가된 스펙이다보니 옛날 이미지들에 대해선 WEBP 가 생성되어있지 않은 이슈가 있었고, 몇 건 되지 않는 이미지이다보니 JPEG 이미지 주소를 입력받으면 WEBP 로 만들어서 업로드해주는 CLI 가 있으면 쓸 수 있을 것 같다는 요청이 있어 NodeJS 로 작업해본 CLI 프로그램을 간단히 올려봅니다. 개발자에겐 cli 는 아주 익숙하리라 생각되구요. NodeJS 진영에서도 이미 리액트나, NestJS 등을 사용해본 개발자라면 create-react-app 또는 nest-cli 등을 통해 CLI 를 사용해본 경험이 있을겁니다. 이번에..
ZeroMQ 의 다양한 패턴 이전 포스팅에서 ZeroMQ 을 간략히 보면서, 그 중에서도 pub/sub 패턴을 사용해 간단한 단방향 메시징에 대해 알아봤습니다. ZeroMQ 는 pub/sub 패턴 외에도 push/pull 과 request/reply 등 일반적인 메시징 패턴도 지원하는데 이번 포스팅에선 이 패턴들에 대해 살펴보고자 합니다. - PUSH/PULL 이 패턴은 파이프라인 패턴으로도 불리며, AMQP 포스팅에서 이미 적긴 했지만 환풍기 또는 경쟁 소비자 패턴과 유사합니다. 파이프라인 이라는 처리 형식은 Node.JS 개발자라면 더 익숙할 것 같습니다. 이름 그대로 PUSH 소켓은 메시지를 전송하기 위한 소켓이고, PULL 소켓은 수신용 소켓이며, PUSH 에서 PULL 방향으로 단방향 통신이 이루어집니다. 이는 reque..
Use AMQP (w/ RabbitMQ) 계속해서 메시징 관련해 이번 포스팅에선 AMQP 에 대해 좀 보려고 합니다. ZeroMQ 나 Redis 의 pub/sub 등의 메시징 시스템을 간단하게 사용하는 것으로도 충분히 그 장점을 느낄 수 있지만, 이러한 시스템들은 단순한만큼 신뢰성은 약간 떨어진다고 할 수 있습니다. 물론 그런 상황이니까 사용하는 것도 있지만요. 메시징 시스템에선 신뢰성을 설명할 때 QoS(Quality of Service) 의 레벨을 들곤 합니다. 그 레벨은 아래와 같습니다. QoS0 최대 한 번. 가장 간단하며 메시지가 지속되지도 않고 전달되는 것을 확인하지도 않습니다. 따라서 이 경우엔 메시지가 손실될 수 있습니다. QoS1 최소 한 번. 메시지가 적어도 한번은 수신되도록 보장합니다. 메시지를 받았을 경우 클라이언트는 무조..
Use ZeroMQ 이전 포스팅들에서 메시징에 대해 계속 적고 있다보니, ZeroMQ (ØMQ) 에 대해 짧게 어떤 물건인지 보려고 합니다. ZeroMQ 공식 문서에 적혀있는 내용을 그대로 가져와보자면, ZeroMQ 는 고성능의 비동기 메세징 라이브러리이고, 분산 어플리케이션 또는 동시성 어플리케이션에서 사용하는 것에 초점이 맞춰져있습니다. 메세지 큐를 제공하긴 하지만, 다른 메세지 지향 미들웨어와 달리 전용 메세지 브로커 없이 ZeroMQ 시스템을 사용할 수 있습니다. ZeroMQ 는 TCP, in-process, inter-process, multicast, WebSocket 등의 다양한 전송 방식을 통해 pub/sub, request/reply, client/server 등의 일반적인 메세징 패턴을 지원합니다. 프로..
Messaging System 이전 포스팅에서 MSA 를 얘기할 때 잠깐 적기도 했던 내용이지만 분산 어플리케이션을 구성하는데에 메세지를 사용해 시스템 전체에 데이터나 이벤트를 전파하는 것은 주요합니다. 경우에 따라 직접 구현하기도하고, 클라우트 서비스의 도움을 받기도 하고, 간단하게 redis 등을 사용하기도 합니다. 메세징 시스템을 구축할 때 고려할 부분은 아래와 같은 포인트가 있습니다. 통신의 방향 메세지 목적 및 타이밍 p2p 방식 또는 브로커를 통한 메세지 전달 - 통신의 방향 통신의 방향은 단방향과 양방향이 있고 쉬운건 단방향이겠지만 양방향이 훨씬 인기가 많고 많이 쓰이는 것 같습니다. 채팅 프로그램같은걸 구현할 때 많이 사용하는 WebSocket 이 단방향 통신의 예시로 볼 수 있습니다. 양방향 통신은 멀리갈 것도 없이..
MSA Node.JS 에서 중요한 패턴이라고 한다면 너무 많은 일을 하는 커다란 어플리케이션을 작성하지 말라는 것입니다. 사실 뭐 이건 이제 Node.JS 에만 국한된 이야기는 아닐거라고 생각하긴 합니다만.. 이전의 포스팅에서 사용했던 그림을 재탕했습니다. 대규모 어플리케이션을 작성하는 대신 위 그림에서 Y축인 서비스 및 기능으로 분해하여 별도의 작은 어플리케이션으로 나눠서 운영하는 것이 그 방식입니다. 모놀리틱 아키텍쳐에 정반대되는 개념이며, Micro Service Architecture(MSA) 패턴으로 볼 수 있습니다. 물론 무조건 모든 어플리케이션을 MSA 로 만드는 것은 그리 적절한 방법은 아닐 수 있습니다. MSA 설계시엔 우리가 소프트웨어 이론에서 늘상 얘기하는 높은 응집도, 낮은 결합도, 복잡성..
peer-to-peer load balancing Node.JS 카테고리에서 다루기에 적절한 내용은 아닌 듯 합니다만.. 피어 투 피어 로드 밸런싱이 어떤것인지에 대해서만 간단하게 남겨보려고 합니다. 일반적으로 어플리케이션 서버에서는 이런 로드밸런싱을 고려한적은 없었던 듯 합니다. 대체로 많이 사용하는건 역방향 프록시(reverse prorxy)를 통한 로드밸런싱이고, 쉽게 사용할 수 있는 nginx 또는 클라우드 서비스를 사용한다면 AWS 의 ALB 나 CLB 등이 있을 것 같습니다. 위와 같은 역방향 프록시의 사용은 외부로부터 네트워크 인프라의 복잡성을 숨길 수 있고, 외부에서 사용할 수 있는 유일한 엔트리 포인트를 제공합니다. 하지만 만약 내부에서만 사용해야 하는 경우엔 피어 투 피어 로드밸런싱이 강점을 가질 수 있습니다. 만약 A 에서 B 로 요..
Node.JS 어플리케이션 확장 현대의 개발 세계에선 다들 너무나도 잘 알고 있을 듯한 어플리케이션을 확장하는 방법에 대해 기록하는 차원에서 남겨둘까 합니다. Node.JS 는 I/O 작업에 특화되어 있는 만큼 수많은 짧은 요청을 처리하는데 장점이 있고 운영하는 서버의 스펙은 크게 신경쓰지 않을 정도로 좋아졌다고 하지만, 기본적으로 단일 스레드에서 처리하는 양에 한계는 분명히 있습니다. 이러한 환경에서 Node.JS 서버의 처리량을 향상시키려면 멀티 프로세스와 멀티 머신 확장입니다. 물론 이렇게 사용했을 때 따러오는 이점은 처리량 뿐만이 아니라, 장애가 발생했을 때에 대한 고가용성도 얻을 수 있습니다. 어플리케이션을 확장하는데에 있어 각 프로세스 또는 머신으로 부하가 분산되는데, 이 부분에 대해 스케일 큐브라는 모델에선 세 가지 측면에..

티스토리툴바