하루 1mm 개발 노트 하루 1mm 개발 노트

누군가 Node.js의 강점을 물어보면 마치 조건반사처럼 구글의 V8엔진을 이용하며 이벤트루프를 통한 non-blocking I/O 라고 번개처럼 대답을 합니다. 하지만 아래와같이 스스로에게 물어봤을때 만족스럽지 못한 답변을하는 나를 발견하고 다시 이벤트루프에대해 공부하고 짧고 간략하게 정리를 해봅니다. 1. 이벤트 루프가 무엇인가? 2. 이벤트 루프는 어디서 동작하는것인가? 3. 이벤트 루프가 어떻게 동작하는것인가? 4. Node.js에서 이벤트처리(event-driven)가 이뤄지는 구조가 머리속에 떠오르지 않는다. 등등 저처럼 Node.js를 이용하여 개발은 하는데 위와 비슷한 갈증이 느껴지시는 분들에게 도움이 되었으면 좋겠습니다. 좀더 깊고 자세한 설명 https://sjh836.tistory.c..

30분마다 넘어오는 크롤링 데이터를 가공하여 웹서비스를 제공하는 프로젝트에 들어가게 되었습니다. 저는 다음과 같은 고민을 하였습니다. 1. 하루에 수십 번씩 쏟아지는 많은 양의 데이터를 어떻게 전달할 것인가? 2. 병목 현상으로 처리 실패 및 데이터 유실이 발생하지 않을까? 그 고민 중 kafka를 알게 되었고 아래와 같은 이유로 kafka를 선택하게 되었습니다. 벤치마크를 통한 성능의 우위. 메시지의 순서가 보장이 필요 없음. 다른 MQ들과는 달리 읽어도 메시지가 사라지지 않아 데이터 유실이 걱정 없음. 또한 사라지지 않기 때문에 추후 다른 서비스에서 분석을 위해 메시지를 같이 수신할 수 있음. 때문에 kafka의 도입을 계획하며 kafka를 맛보면 정리한 글입니다. 이 글은 아래와 같은 순서로 진행이..

하나의 서비스를 위해서 EC2 인스턴스를 생각보다 많이 만들게 되는 것을 경험하였습니다. 개발 스테이지, 테스트 스테이지, 프로덕션 스테이지를 나누게 되며 예를 들어 redis인스턴스와 웹서버 인스턴스만 구성하여도 총 6개의 인스턴스가 생기됩니다. 또한 고가용성을 위해 redis를 cluster로 구축한다면 더 늘어나겠죠. 프로덕션이 아닌 개발 및 테스트 스테이지의 모든 인스턴스가 24시간 돌아간다면 한 달 뒤 요금 청구서를 보면 가슴이 아플 수도 있습니다. 적용을 안 하셨더라도 괜찮습니다. 저 또한 기능 개발이 급하다는 핑계(?)로 미루다가 청구서를 보고 도입을 하고 그 과정을 공유합니다. 여러분들도 이 글을 보시고 적용하셔서 도움이 되신다면 좋겠습니다. 이 글은 아래와 같은 스텝으로 진행이 됩니다. ..