기존의도 : apache 는 동기+멀티스레드, NgingX는 비동기+ 싱글스레드 이므로 NodeJS와 시너지가 좋다고 판단해 선정
회의결과 : 소규모 사용자용 어플리케이션에 오버스펙으로 판단되어 삭제
2. 모니터링서버- NodeJS(ExpressJS)
기존의도 : 팀원 공통으로 Java를 사용 가능해 스프링으로 구현하려했으나 server push 구현에서 폴링(xhr) 이 아닌 webSocket을 사용하기로 결정해 socket.IO를 지원하는 NodeJS로 선정
회의결과 : Nodejs 관련 ref가 많아 버그관련 안정적이고 추후 로그인 관련해 passportjs와 같이 미들웨어가 풍부함.특히 websocket를 socket.IO로 제공하며 socketIO에서 세션을 expressjs와 연동해 사용 할 수 있는장점이 있으므로 NodeJS 선정 유지
3. 메세지큐 - Redis(pub/sub)
기존의도 : 다른 메세지큐와 다르게 수신자 모두에게 메시지를 전달하는 redis의 pub/sub이 현재 어플리케이션에 알맞음, redis는 메세지큐를 지나가는 데이터를 저장하지 않는대신 빠른 성능을 보여주어 단순 알림을 전달하는 현재 어플리케이션에 적합하다고 판단돼 선정 유지
회의결과 : 선정 적합하므로 유지, stream 관련 조사, 폴링이 아닌 푸쉬이므로 유실된 신호에대한 대처고려
4. 크론 수행서버의 cron 로그파일 감시 exe 프로그램 - NodeJS로 개발
기존의도 : Nodejs의 fs.watchFile 가 성능이 좋고 구현이 간단함.로그가 남겨질 때마다 파일IO/ 네트워크IO가 발생해야하는 watchFile 작업에 비동기 방식으로 작업을 처리하는게 적합하기에 java or C++이 아닌 NodeJS 선정
회의결과 : 로그가 syslog로 남겨질 경우 고려 필요. 개발자가 지정한 명령어를 크론에 삽입하는경우로 프로그램을 개발하는 경우 watchFile 안해도 됨 고려 필요. ex) 크론에 특정 명령어를 포함시키면 syslog에 남긴 로그를 읽어 모니터링으로 제공
5. 로그 저장 DB-MongoDB
기존의도 :크론 로그 파일을 정제해 MongoDB로 저장.
[1]. 로그파일을 직접 사용하는것은 [파일 vs DB의 장단점] 에서 단점이 뚜렷하기에 사용하지 않고 몽고디비로 데이터를 사용
[2]. [중요] 몽고디비를 사용하지않고 메세지큐로 로그 및 필요한 내용을 전달해도되지만 메세지큐로 전달시 pub/sub 구조이기 때문에 특정 모니터링 서버가 필요하지도 않은 데이터를 전송해야 하므로 비효율적임
[3]. 로그성 데이터의 저장은 수많은 로그를 DB에 저장해야함
로그는 복잡한 관계형(Join) 작업이 필요 없음 -> RDB 안써도됨
로그는 많은양을 빠르게 저장해야됨-> ACID를 지원하지 않는 몽고디비가 RDB보다 100배 성능 좋음
로그는 많은양을 빠르게 저장해야됨-> 추후 DB의 scale out을 고려해야 하므로 auto sharding를 지원하는 몽고디비가 로그용 디비에 적합
Replica Set을 지원하기에 안정적
OS별로(센토스, 우분투) 크론 로그는 제공하는 정보가 다양 할 수 있음-> 몽고디비의 유연한 스키마 활용
In GitLab by @gm2202983 on May 18, 2021, 17:09
개요
회의 사항
상세 내용
1. 로드벨런서-NginX
기존의도 : apache 는 동기+멀티스레드, NgingX는 비동기+ 싱글스레드 이므로 NodeJS와 시너지가 좋다고 판단해 선정
회의결과 : 소규모 사용자용 어플리케이션에 오버스펙으로 판단되어 삭제
2. 모니터링서버- NodeJS(ExpressJS)
기존의도 : 팀원 공통으로 Java를 사용 가능해 스프링으로 구현하려했으나 server push 구현에서 폴링(xhr) 이 아닌 webSocket을 사용하기로 결정해 socket.IO를 지원하는 NodeJS로 선정
회의결과 : Nodejs 관련 ref가 많아 버그관련 안정적이고 추후 로그인 관련해 passportjs와 같이 미들웨어가 풍부함.특히 websocket를 socket.IO로 제공하며 socketIO에서 세션을 expressjs와 연동해 사용 할 수 있는장점이 있으므로 NodeJS 선정 유지
3. 메세지큐 - Redis(pub/sub)
기존의도 : 다른 메세지큐와 다르게 수신자 모두에게 메시지를 전달하는 redis의 pub/sub이 현재 어플리케이션에 알맞음, redis는 메세지큐를 지나가는 데이터를 저장하지 않는대신 빠른 성능을 보여주어 단순 알림을 전달하는 현재 어플리케이션에 적합하다고 판단돼 선정 유지
회의결과 : 선정 적합하므로 유지, stream 관련 조사, 폴링이 아닌 푸쉬이므로 유실된 신호에대한 대처고려
4. 크론 수행서버의 cron 로그파일 감시 exe 프로그램 - NodeJS로 개발
기존의도 : Nodejs의 fs.watchFile 가 성능이 좋고 구현이 간단함.로그가 남겨질 때마다 파일IO/ 네트워크IO가 발생해야하는 watchFile 작업에 비동기 방식으로 작업을 처리하는게 적합하기에 java or C++이 아닌 NodeJS 선정
회의결과 : 로그가 syslog로 남겨질 경우 고려 필요. 개발자가 지정한 명령어를 크론에 삽입하는경우로 프로그램을 개발하는 경우 watchFile 안해도 됨 고려 필요. ex) 크론에 특정 명령어를 포함시키면 syslog에 남긴 로그를 읽어 모니터링으로 제공
5. 로그 저장 DB-MongoDB
기존의도 :크론 로그 파일을 정제해 MongoDB로 저장.
[1]. 로그파일을 직접 사용하는것은 [파일 vs DB의 장단점] 에서 단점이 뚜렷하기에 사용하지 않고 몽고디비로 데이터를 사용
[2]. [중요] 몽고디비를 사용하지않고 메세지큐로 로그 및 필요한 내용을 전달해도되지만 메세지큐로 전달시 pub/sub 구조이기 때문에 특정 모니터링 서버가 필요하지도 않은 데이터를 전송해야 하므로 비효율적임
[3]. 로그성 데이터의 저장은 수많은 로그를 DB에 저장해야함
로그는 복잡한 관계형(Join) 작업이 필요 없음 -> RDB 안써도됨
로그는 많은양을 빠르게 저장해야됨-> ACID를 지원하지 않는 몽고디비가 RDB보다 100배 성능 좋음
로그는 많은양을 빠르게 저장해야됨-> 추후 DB의 scale out을 고려해야 하므로 auto sharding를 지원하는 몽고디비가 로그용 디비에 적합
Replica Set을 지원하기에 안정적
OS별로(센토스, 우분투) 크론 로그는 제공하는 정보가 다양 할 수 있음-> 몽고디비의 유연한 스키마 활용
회의결과 : 로그는 로그용 DB로 선정을 고려, 메타정보용 DB도 고려 필요
기타 선정사항
5-25일까지 수행 목표