'분류 전체보기'에 해당되는 글 563건

web/node.js

node.js에서 multer 사용하여 이미지 업로드 및 텍스트 파일 다루기

Multer는 파일 업로드를 위해서 사용되는 multipart/form-data를 다루기 위한 node.js 미들웨어이다. busyboy를 기반으로 하고 있다.
자세한 내용은 https://github.com/expressjs/multer/blob/master/doc/README-ko.md 이곳에서 참고하면 된다.

그럼 간단하게 multipart/form-data로 올린 이미지 파일과 텍스트파일을 request post로 받아서 처리하는 코드를 만들어보자.

우선 multer를 설치한다.
npm i multer

그리고 이미지 파일을 특정 경로에 저장해놓고 사용할 수 있지만 나는 메모리 스토리지를 사용해서 조작하는 방식으로 진행해보겠다.

multer 라이브러리를 선언하고 memoryStorage를 사용할 수 있도록 추가적으로 선언해준다.

1
2
3
const multer = require('multer');
const storage = multer.memoryStorage();
const upload = multer({ storage });
cs

그리고 router에 미들웨어로 upload.single('productImage')를 넣어서 productImage 필드로 넘어온 값을 버퍼로 가져오도록 한다. array, fields 등등 다른 메소드들도 있으나 나는 이미지가 하나라서 single을 사용했다.

1
2
3
4
5
6
7
8
9
router.post('/test', upload.single('productImg'), async (req, res, next) => {
    try {
      console.log(req.file);
      res.json(req.body);
    } catch (e) {
      next(e);
    }
  });
 
cs

그럼 postman을 통해서 데이터를 보내보자.


전송정보

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
{
"method": "POST",
"url": "/info/test",
"headers": {
"authorization": "Bearer 8c6076013db8af716df89b1b48b90c9b2b0fad6c",
"content-type": "multipart/form-data; boundary=--------------------------820616490467091968093229",
"cache-control": "no-cache",
"postman-token": "217b466f-1f40-402e-b2cd-153426c61cc7",
"user-agent": "PostmanRuntime/7.6.0",
"accept": "*/*",
"host": "127.0.0.1:8081",
"accept-encoding": "gzip, deflate",
"content-length": "97764",
"connection": "keep-alive"
},
"body": {},
"query": {},
"level": "info",
"message": "Access"
}
 
cs

이렇게 전송하고 debug로 전송된 정보를 체크해보면 다음과 같이 출력된다.

이 정보를 이용해서 text 파일들은 파일대로 다루고 이미지 파일은 버퍼를 사용해서 s3에 저장을 하던지 여러가지 동작을 진행할 수 있다.

상품리뷰

구글 애드센스 주소인증 PIN 번호 우편 받기

네이버 블로그를 진행하다가 티스토리로 넘어오게된 이유는 바로 구글 애드센스를 사용하고 싶어서였다. 


물론 수입을 위해서 블로그를 하는건 아니고 공부 내용 정리를 위해서이긴 하지만 그래도 일간 방문자가 500명 가까이 되니 욕심이 조금 생겼다.

애드센스는 $20정도 수입금이 쌓이면 주소로 전송되는 PIN번호를 적어야한다. 그렇지 않으면 수입을 받을 수가 없다.

작년 11월에 인증을 받으라고 해서 주소를 적고 PIN번호를 신청했다. 그러나 오지 않았다.


PIN 번호 우편은 한달?

PIN번호가 오는데 구글 애드센스 안내에 보면 한달정도 걸린다고 했다. 그런데 실질적으로 내가 11월에 신청해도 안오고 1월에 다시신청하고 2월에도 다시 신청했지만 오지 않았다.. 3번이상 다시 재 발송 신청하면 4번째 부터는 민증인증과 같은 다른 수단을 이용해야한다..

그러던 중 11월에 신청했었던 우편이 오늘 도착했다.

무려 4개월정도 걸렸다. 대단하다 ㅋㅋㅋ 인내심을 가져야한다. 한달은 절대 아닌거 같다. PIN 번호를 재발송해도 이전에 신청했던 우편에 있던 번호도 유효하게 사용할 수 있기 때문에 걱정하지 않아도 된다.


PIN 번호 등록방법

우편은 아주 간단한 모양새로 온다.

손바닥으로 가린곳에 한글 주소가 있고 외국에서 발송된듯한 모양의 우표가 붙어있다.


안을 조심이 뜯어서 열어보면 

아래와 같이 PIN번호가 대문자만하게 적혀있는데 6섯자리를 적으면 된다.

이 6섯자리 숫자를 위해서 내가 4달을 기다렸다. ㅜㅜ


구글 애드센스에 보면 주소 인증영역이 있다. 이곳에 PIN번호를 적고 인증하면 바로 실시간으로 인증된다. 


인증이 끝나고 나서 계좌번호까지 등록하면 끄읕!

이제 글을 많이 올리고 광고 클릭도 많이 유발해서 공부도 하면서 돈도 벌어보자. 유튜브 스타는 못되어도 커비값은 벌어보자 ㅋㅋ



IT 지식/nginx

nginx 정리와 설치 및 기본 설정방법

Ngnix 설명

nginx는 기존 웹서버에서 많은 트래픽을 감당하기 위해서 확정성을 가지고 설계된 비동기 이벤트 드라이븐 방식의 웹서버를 칭한다.


Nginx 설치

nginx를 맥이 있으면 brew를 통해서 간단하게 설치가 가능하다.

1
brew install nginx
cs


Nginx 프로세스

nginx는 하나의 마스터 프로세스와 여러 worker 프로세스를 가진다. 마스터 프로세스의 주요 목적은 read 권한 그리고 성능 측정과 worker 프로세스 관리이다. worker 프로세스는 요청을 처리한다. nginx는 event-based 모델을 사용하고 worker 프로세스 사이에 요청을 효율적으로 분배하기 위해서 os에 의존하는 매커니즘을 사용한다. worker 프로세스에 개수는 설정 파일에서 정의되며 정의된 프로세스 개수와 사용가능한 cpu 코어 숫자에 맞게 자동으로 조정된다.


Nginx 동작 -S

nginx를 동작시키기 위해서는 다음 옵션을 붙여서 진행한다.

1
nginx -s signal
cs


signal의 종류는 다음과 같다.

 종류

설명 

 stop

 빠른 중지

 quip

 graceful stop

##graceful stop은 요청이 중단되었을 때 로드밸런스에게 해당 노드에 요청을 추가적으로 못하게 하고 현재 노드에 작업을 중지시키고 정상적으로 끝내는 것을 말한다.

 reload

 설정 파일 재 로드

 reopen

 로그 파일  재 오픈


quip를 진행하면 현재 요청을 워커 프로세스에게 끝내라고 보낸다. 그럼 해당 워커 프로세스에 새로운 요청을 보내지 않고 워커 프로세스가 진행중이던 작업이 마무리되면 정상적으로 애플리케이션이 꺼진다. 이를 graceful stop이라고 한다.

reload를 진행하면 syntax 체크를 진행하고 성공하게 되면 older worker 프로세스를 중지 시키고 새로운 worker 프로세스를 만들어서 동작 시킨다. 만약 설정이 이상하면 마스터 프로세스는 작업을 롤백하고 예전 설정으로 동작한다. 중지 요청을 받은 workder 프로세스들은 새로운 요청을 받는 것을 멈추고 자신이 하고 있는 동작을 마무리 한다. 이 동작이 완료되면 그때 older worker 프로세스는 죽는다.

Nginx 설정파일

nginx 정책과 그 모듈들에 동작은 /usr/local/nginx/conf, /etc/nginx, /usr/local/etc/nginx 위치중에 존재하는 nginx.conf 파일 내에서 설정한대로 동작한다. (brew로 설치하는 경우 /usr/local/etc/nginx에 위치)

설정 파일 구조.

설정 파일에 입력하는 값들은 두 가지 형태로 입력이 가능하다. simple 디렉티브와 block 디렉티브 두 가지이다. simple은 이름과 파라미터로 구성되어있고 마지막에 ;이 붙는다. block 디렉티브은 simple과 구조가 같지만 끝에 ; 대신 ({ })이 붙는다. block 명령은 내부에 다른 명령들을 포함할 수있다.

events, http 명령은 main context에 위치하고 server, location은 http에 위치한다.


static content
웹 서버에서 중요한 역할중 하나는 image, html pages와 같은 정적 페이지를 전달하는 것이다. 이를 위해서 http 블록 내부에 있는 server와 location 블록을 수정해보자.

일반적으로 설정 파일은 server_name과 listen port로 구분되는 여러 server 블록을 가지고 있다.

1
2
3
4
http {
  server {
  }
}
cs

기본형태는 이렇다.


그럼 이걸 이용해서 static content에 접근할 수 있게 해보자.

아래와 같이 설정하면 /dd로 오는 요청은 무조건 저쪽 static 페이지를 통하게 된다. 

1
2
3
4
location /dd {
    root /Users/we/Documents
    index index.html
  }
cs

만약 호출 uri가 중첩되는 경우가 아래와 같이 발생하면 가장 긴 uri의 매칭을 따르게 된다.

1
2
3
4
5
6
7
8
9
server {
    location / {
        root /data/www;
    }
 
    location /images/ {
        root /data;
    }
}
cs


만약 설정이 정상적으로 동작하지 않을 때는 로그를 확인해봐야 한다. 로그에는 access.log, error.log가 존재한다. 맥 기준으로 log 폴더는 /usr/local/var/log/nginx에 존재한다.


proxy 설정

정적 페이지 연결과 더불어서 proxy로서 역할을 진행할 수 있다. 여러 서버들 사이에서 요청을 분배하는 것을 reverse proxy라고 한다.

proxy설정은 정적 페이지와 동일하게 http 블록 내에 server 블록으로 설정한다.

1
2
3
4
5
6
7
8
9
10
11
12
server {
  listen 80;
  
  location / {
    proxy_pass http://127.0.0.1:8081;
  }
 
  location /dd {
    root /Users/we/Documents/static;
    index index.html;
  }
}
cs

만약 listen을 기재하지 않으면 80으로 기본으로 매핑된다. 만약 아래와 같이 server 바로 밑에 root를 적게되면 server에 기재한 root에서 정적페이지 index.html을 찾고 각 location에 root를 입력해도 무시된다.

1
2
3
4
5
6
7
server {
    listen 8080;
    root /data/up1;
 
    location / {
    }
}
cs


또한 경로 매핑을 정규식으로도 진행할 수 있다. 아래와 같이 설정하면 .gif, .jpg, .png 형태로 들어오는 경우에 매핑 된다.

1
2
3
location ~ \.(gif|jpg|png)$ {
    root /data/images;
}
cs


설정 파일 폴더 구조

  • sites-available : 가상 서버 환경들에 대한 설정 파일들이 위치하는 부분. 가상 서버를 사용하거나 사용하지 않던간에 그에 대한 설정 파일들이 위치하는 곳
  • sites-enabled : sites-available에 있는 가상 서버 파일들중에서 실행시키고 싶은 파일을 symlink로 연결한 폴더. 실제로 이 폴더에 위치한 가상서버 환경 파일들을 읽어서 서버를 세팅한다.
  • nginx.conf : Nginx에 관한 설정파일로 Nginx 설정에 관한 블록들이 작성되어 있으며 이 파일에서 sites-enabled 폴더에 있는 파일들을 가져온다. (include 명령어를 사용).


gzip

gzip은 전달해오는 요청을 압축해서 진행하기 위해서 사용하는 옵션이다. types를 통해서 수용하는 타입도 정의할 수 있다.


apache와 많은 부분이 다르다. 정확하게 어떤 웹 서버가 좋다고 할 수는 없지만 많은 트래픽을 받는 경우에는 nginx를 사용하면 좋을 것 같다.

'IT 지식 > nginx' 카테고리의 다른 글

nginx 정리와 설치 및 기본 설정방법  (0) 2019.02.15
상품리뷰

13인치 2017년형 맥북 프로 256기가 언박싱!

기존에 사용중이던 맥북에어가 진짜 너무 느려서 도저히 사용할 수준이 아니었다. 확실히 맥북에어는 문서나 간단한 서핑 수준에 적합하다. 하지만 내가 사용하는 수준은 그정도 이상에 사양이 필요하다 보니 현저하게 사용을 하지 않게 되었고 그래서 중고나라에 팔았다.


구매했던 금액 40만원 그대로 40만원에 팔았다. 손해본건 없다. 그냥 본전이다. 그런다음 어떤 노트북을 사야하나 고민했다. 2018년형 모델에서 찾아봤는데 2018년형 모델은 터치바 모델만 존재한다. 회사에서 2017년형 15인치 터치바를 사용중인데 터치바는 진짜 너무 싫다. 이쁘고 사용성이 좋다고 생각할수도 있지만 나는 그냥 물리키가 더 좋다. 그래서 논터치바를 알아봤다. 


논 터치바도 가격이 전혀 저렴하지 않았다. 256기가 논터치바는 기본형이 190만원대였다. ㅋㅋ 가격이 미쳤네 


그래서 교육할인 받고 beats 헤드폰 받고 구매하려 했으나 그래도 가격이 너무 비싸서 오픈마켓을 찾아봤다.


위메프가 디지털 위크 세일을 하면서 카드할인까지 진행하고 있었다. 가격은 162만원이었다. 거의 공홈이랑 30만원 차이었다. 그래도 오픈마켓에서 구매하는게 조금 불안하긴 했지만 그래도 내가 다니는 회사를 믿고 구매했다. ㅋㅋ


박스 마저도 정말 멋져보인다.

비싼 가격이라 그런것 같다. 애플은 박스를 뜯는게 너무 편하다. 칼 없이 종이만 뜯으면 되고 그안에도 충격 방지를 위해 포장이 잘 되어있다.


겉에 박스에도 터치바가 아닌 논치바인것을 확인할 수 있다.

원래는 스페이스 그레이가 아닌 그레이 모델을 살까 했는데 그래도 스페이스 그레이가 이쁜것 같아 구매했다.


맥북은 중고로 구매하거나 누가 쓰던거를 받아보기만 했지 처음 사봤다.

영롱하다. 너무 고급지다 이쁘다 오래쓰자. 


역시 맥은 처음 사면 액정에 보호지가 붙어있고 바로 부팅이 된다.

제품 자체도 엄청 단단해보이고 일반 그램과 삼성 노트북과 비교했을 때 느낌이 완전 고급지다.


구성품은 간단하게 사용설명서, 충전기, usb-c 타입 선이 전부이다.

비싼 가격치고는 들어있는것도 심플하다. 


구성품은 심플하지 않아도 되는데.


받자마자 업데이트를 진행했다. 

어서 켜져서 모든 환경을 세팅하고 싶다.

오늘 맥북프로 받으려고 휴가를 냈다.

휴가를 충분히 낼만한 가치가 있는 기분이다. 아이맥이랑 같이 쓰니 정말 멋지다. synergy를 예전에 블랙 프라이데이 때 아주 저렴하게 사논게 있어서 마우스 키보드 공유하기해서 사용해도 좋고 독립적으로 사용해도 좋을 것 같다.


굿굿 잘 써보자.


web/kafka

[번역] shared message queues와 publish-subscribe 방식에 Custom Group 방식을 더한 Kafka 소개

전통적으로 메시지 모델은 Shared Message Queue, Publish-subscribe로 구분된다. 두 가지 모델 모두 그들만에 pros and cons를 보유하고 있다. 하지만 이 두개의 모두 최초 디자인 제한 때문에 큰 데이터를 다루기에는 부족했다. Apache Kafka는 두 모델 중 publish-subscribe 메시징 모델을 구현한 모델로 부족했던 부분을 수정하고 실시간 분석을 위한 스트리밍 데이터를 처리할 수 있도록 가능해졌다. kafka는 LinkedIn에서 2010년에 방대한 데이터 처리를 위해서 개발되었다. Apache Kafka는 전통적인 메시징 모델이 달성하지 못한 격차를 해소했다. Kafka는 두 모델의 개념을 구현하여 단점을 극복하고 동시에 두 가지 방법론을 모두 통합 할 수있는 유연성을 제공한다.


Shared Message Queues
Shared Message Queues 메시지 큐는 producer에서 single consumer에게 스트리밍 데이터를 전송할 수 있다. 큐에 저장된 메시지는 한번만 읽기가 가능하고 하나의 consumer만 읽을 수 있다. subscribers는 메시지를 큐의 끝에서 메시지를 읽어서 가지고 온다. Queueing 시스템은 성공적으로 읽혀진 메시지를 큐에서 제거한다.

약점
한번 읽고 지워지는 SharedMessage Queue는 같은 도메인에 속해 있고 event-driving programming을 하는 명령어와 같은 메시지에서 적합하다. 만약 많은 consumer들이 shared queue에 접근을 하게 된다면 해당 컨슈머들은 logical domain이 같아야 하고 같은 기능을 수행해야 한다. 그렇기 때무에 shared queue는 single domain 소비로 제한된다.

Publish-Subscribe System
publish-subscribe모델은 여러 publisher가 발행이 가능하고 여러 subscriber가 구독이 가능하게 설계되어 있다. 그래서 모든 메시지는 토픽을 구독하는 모든 subscriber들에게 전송이 가능하도록 되어있다.

약점
subscriber로부터 publisher의 logical 결합이 loosely-coupled 되어 있지만 scale은 한정적이다. 각각의 subscriber는 모든 파티션으로 부터 메시지를 접근하기 위해서는 모든 파티션을 접근해야한다. 그러므로 전통적인 pub-sub 모델은 작은 네트워크에서 동작하도록 되어있다.

또한 subscriber와 publisher에 디커플링이 메시지의 신뢰도를 낮추는 영향을 준다. 모든 메시지가 모든 subscriber들에게 전송되기 때문에 메시지가 다른 subscirber에게 전송되는 경우 subscriber들 사이에 sync를 맞추는게 실질적으로 어렵다.


그럼 어떻게 Kafka는 두 모델을 결합했을까?
kafka는 shared message queue 시스템과 pub-sub 모델의 장점을 가지고 만들어졌다. 그 성공은 두개의 컨셉을 기준으로 만들어졌다.
  • consumer group 사용
  • broker들로 부터 메시지 리텐션

consumer가 그룹에 소속되고 topic을 구독할 때 오직 하나의 consumer만 그룹내에서 토픽의 메시지를 읽는다. 그리고 메시지는 broker 내부 토픽에서 사라지지 않고 보유되는데 이는 shared message queue 시스템과 다른점이다.

여러 consumer group은 같은 토픽에서 값을 읽을 수 있으며, 또한 서로 다른 logical application domain에서 다른 시간데에서도 읽을 수 있다. 그러므로 kafka는 같은 consumer group에 속한 consumer들의 높은 확정성을 제공하고 동시에 독립적인 애플리케이션들이 동작할 수 있는 이점이 있다.

Consumer Group
consumer group은 kafka가 message queue와 pub-sub 모델들의 이점을을 가질 수 있도록하는 유연성을 제공한다. 같은 그룹에 속한 consumer들은 group id를 공유한다. 이 consumer들은 토픽의 파티션을 공장하게 나눈다. 이 각각의 파티션들은 오직 그룹내에 하나의 consumer에서만 소비된다.

kafka Consumer Groups
만약 같은 그룹에 모든 consumer가 들어있으면 kafka 모델은 전통적인 message queue처럼 동작한다. 왜냐면 각각의 메시지가 하나의 consumer에게만 발행되는 부분이 같기 때문이다. 각각의 파티션은 거의 그룹내에 하나의 consumer와 연결된다.

여러 consumer group가 존재할 때 데이터 소비 모델은 전형적인 pub-sub 모델을 따른다. 메시지는 모든 consumer group에게 전송된다.

만약 하나의 consumer만 들어있는 그룹이 있으면 그 consumer가 모든 파티션을 담당한다.

이상적으로 topic의 파티션 수와 consumer group에 consumer 수가 맞으면 최적으로 효율을 가진다. 만약 consumer가 파티션보다 많으면 consumer들이 idle상태에 빠지게 되므로 자원 낭비가 발생된다. 만약 partition이 consumer보다 많은 경우 consumer들은 여러 파티션에서 값을 있는데 이는 각 파티션에서 읽는 값이 서로 순서가 맞지 않게 읽게 되기 때문에 문제의 소지가 있다. kafka는 파티션 사이에서 메시지의 순서를 보장하지 않는다. 그러므로 kafka는 오직 하나의 consumer가 하나의 파티션의 내용을 구독할 때만 순서가 보장된다. 메시지는 또한 processing중에 그룹화된 키를 통해서 정렬될 수 있다.

kafka는 offset commit과 form을 사용하여 브로커에서 구독 그룹으로 메시지가 전송되었느지 보증한다. 파티션은 consumer그룹내에 오직 하나 또는 하나 이상의 관계를 consumer와 맺을 수 있기 때문에 메시지 중복을 피하기 위해서 한번에 그룹내에서 한번에 하나의 그룹에게만 메시지를 전송한다.

Reblancing
consumer그룹이 scales up & down을 하기 때문에 동작중인 consumer들은 파티선을 그 들 사이에서 쪼갠다. Reblancing은 consumer와 broker의 충돌 또는 topic이나 partition 추가로 인해 파티션과 consumer의 소유권이 변경되면서 진행된다. 이 매커니즘을 이용하여 안전하게 시스템으로 부터 consumer의 추가와 제거가 가능하다.
-> 요약하면 consumer에 문제가 발생하면 다른 consumer가 파티션의 메시지를 받는다 이런 것 같다.

kafka가 시작되면서 브로커는 consumer의 RegisterConsumer 요청을 수신한 consumer group의 하위 집합에 대한 코디네이터로 표시되고 소유해야할 파티션 목록이 포함된 RegisterConsumer Response를 반환한다. 또한 코디네이터는 컨슈머가 살아있거나 죽었는지 체크하고 결함을 찾기위해 동작을 시작한다. 또한 세션이 끊어지기 전에 consumer가 코디네이터 브로커에게 heartbeat 신호 전송에 실패하면 코디네이터는 해당 consumer를 dead로 표시하고 rebalance를 실행한다. 세션 타임아웃 시간은 session.timeout.ms 속성에서 설정할 수 있다. 예를들어 그룹 A의 C2가 실패 했으면 C1그리고 C3가 짧게 자기들의 파티션에서의 메시지 소비를 정지하고 파티션들은 C1과 C2에 대해서 reassian된다. C2 consumer는 잃게 되지만 rebalancing 프로세스가 실행되고 파티션이 그룹내에 다른 consumer들에게 재 할당된다. GroupB는 Group A의 이런 현상이 전혀 영향을 주지 않는다.

결론
shared message queue는 메시지 프로세스내에서 scale을 허용한다 하지만 싱글 도메인에서만 사용이 가능하다. pub-sub 모델은 consumer들에게 브로드캐스팅을 지원하지만 scale이 제한된다. kafka는 shared message queue에서 scale을 가져왔고 pub-sub 아키텍쳐를 consumer gorup를 구현함으로써 단점을 보안하여 재 구현하여 가져왔다. consumer group를 구현함으로써 scale과 멀티 도메인을 사용할 수 있게 되었다. 그리고 kafka에 rebalacing을 통해서 그룹내에서 문제 발생시 문제를 해결할 수 있다.

원문
https://blog.cloudera.com/blog/2018/05/scalability-of-kafka-messaging-using-consumer-groups/




푸터바

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

  • Today : 36
  • Yesterday : 651
  • Total : 55,511