배달의 종족 쭈문

저거 들으며 생각했다. 나라면 어떻게 만들까?

주문을 넣으면, 가게에 설치된 POS기나 단말기로 주문이 전송되 배달의 종족 쭈문 이렇게 울리는 것 같은데...

무책임하게 들리겠지만, 실재 어떻게 만들어져 있는지, 나도 모른다. 다만 Message Queue로 만들었을거란 생각이 들어 한 번 만들어 보려고 한다.

어떻게 만들것인가?

• 앞 시리즈 MQTT로 카톡서버 만들어보자 와 동일한 기술을 사용하겠다.
• 다만 MQ(Message Queue)를 Mosquitto/MQTT -> RabbitMQ/AMQP 로 바꾸어서 해보려 한다.

RabbitMQ 설치, AMQP 설명은 인터넷에 차고 넘치니 최소한으로만 언급하겠다.

알고 있게지만, 복습 겸해서 뇌리에 박아야 할 것.

• 비동기
• RR(Request-Response, Request-Reply) 패턴

엄마와 비동기

사실 비동기가 무엇인지 다 잘 알고 있을 것이다.

다만 여기서 언급하는 이유는 Broker 끼고 RR 패턴으로 구현하다보면, 코딩을 동기식으로 하고 있는 나 자신을 발견하기 때문이다.

디버깅하다 깨닫는다.

아 MQ는 비동기지...

그래서 다시 한 번 짚고 넘어가자는 의미로 글 써본다.

Sync: 엄마가 청소하면 동기다.

1. 아침 준비한다.
2. 설겆이한다.
3. 청소한다.

순서대로 하면 된다. 이건 엄마식 동기 처리 방식이다.

Async: 각자 하고, 엄마한테 보고하면 비동기다.

엄마가 다 큰 자식 방청소하다가 화 났다. 어느 날 자식 새끼들 다 모아 놓고 엄마가 선언한다.

이제부터 각자 방은 스스로 청소하고 엄마한테 다 했다고 보고해라.

어떤 놈이 청소 먼저 끝낼 지 엄마는 모른다.

이게 비동기다.

정정하던 엄마가 어느 날 친구 장례식장 갔다 와서 그런다.

에구...불쌍한 것....오는 건 순서가 있어도, 가는 건 순서가 없다더만...

인생🚶 비동기다.

✅ 다음 글에서는 RR 패턴에 대해 얘기해보겠다.

✅ 이 글은 시리즈 글입니다. 앞에서 부터 차근차근 읽으세요.

개인 소스랑 섞이지 않도록 따로 Github 계정 따서 올린다.😁😁

시리즈

글 : https://velog.io/@mqtt_expert/series/MQTT로-카톡서버-만들어보자 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting

1.MQTT로 카톡서버 만들어보자-인트로

글 : https://velog.io/@mqtt_expert/kakaotalk0

2.MQTT로 카톡서버 만들어보자 - 1/10. Pub/Sub으로 로그인?

글 : https://velog.io/@mqtt_expert/kakaotalk1 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/01

3.MQTT로 카톡서버 만들어보자 - 2/10. 톡을 날려보자

글 : https://velog.io/@mqtt_expert/kakaotalk2 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/02

4.MQTT로 카톡서버 만들어보자 - 3/10. 사용자 상태

글 : https://velog.io/@mqtt_expert/kakaotalk3 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/03

5.MQTT로 카톡서버 만들어보자 - 4/10. 내전화 받았늬?

글 : https://velog.io/@mqtt_expert/kakaotalk4 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/04

6.MQTT로 카톡서버 만들어보자 - 5/10. QoS 번외

글 : https://velog.io/@mqtt_expert/kakaotalk5

7.MQTT로 카톡서버 만들어보자 - 6/10. 입구컷 안 당하기

글 : https://velog.io/@mqtt_expert/kakaotalk6 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/06

8.MQTT로 카톡서버 만들어보자 - 7/10. ACL

글 : https://velog.io/@mqtt_expert/kakaotalk7 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/07

9.MQTT로 카톡서버 만들어보자 - 8/10. IDC에 불이 났어요

글 : https://velog.io/@mqtt_expert/kakaotalk8 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/08

10.MQTT로 카톡서버 만들어보자 - 9/10. server.js 이중화

글 : https://velog.io/@mqtt_expert/kakaotalk9 Github 소스 : https://github.com/MQ-Expert/mqtt_chatting/tree/main/09

11.MQTT로 카톡서버 만들어보자 - 10/10. 서버 쪼개기

글 : https://velog.io/@mqtt_expert/kakaotalk10

우리 아버지, 삼촌 세대는 그랬다러라. 한 방에서 다 잤다구.

세상은 변했다. 1인 가구가 대세다.

이번 글에서는 코딩은 없다.

서비스를 어떻게 구성할 것인가

라는 전략 얘기만 할거다.

토픽별로 프로그램 쪼개기

이것은 한 서버 안에 토픽별로 프로그램을 나누는 것이다. 즉 토픽별 전담 프로그램이 있는 것이다.

34평 아파트에 아버지 방, 누나 방, 내 방, 동생 방 ... 이렇게 있는 거다.

살다보니 내가 투잡을 뛰게 되었다. 그래서 방에 책상을 하나씩 두고 한쪽에서는 A 일을 다른 쪽에서는 B 일을 하게 되었다.

server/login 토픽도 로그인 처리 해주는 Joblogin_proc와 DB에 저장하는 Joblogin_save으로 나눠 처리할 수 있다. 동일 토픽에 대해서 말이다.

토픽별로 서버 쪼개기

이것은 서버별로 쪼개는 거로 토픽별로 전담 서버가 있는 것이다. 즉 위의 전담 프로그램을 서버 당 하나씩 집어 넣는거다.

비유하자면 아버지 집🏠, 누나 집🏠, 내 집🏠 ... 이렇게 쪼개는 거다. 말 그대로 1인 가구.

장.단점

돈만 있다면 전담 서버가 있는게 왔다다. 관리 비용이 더 들어가겠지만.😂😂

이거 두개를 합치면?

topic 별로 전담 서버가 있고 AND 똑 같은 일을 하는 프로그램을 여러개 만드는 거다. 동일한 일을 하기 때문에 앞에서 배웠던 shared subscription을 사용해야 한다. 그래야 Round Robin으로 일을 받아서 처리한다.

우리의 목표는 이거다. 기능별로 서버별로 분리하는 거다.

한걸음 더 나아가

IDC에 장애가 날 경우를 대비해 다음과 같이 이중화할 수 있다.

뱀다리

앞에서 하나의 토픽에 대해 2개로 나누어서 처리할려면 shared scription Group을 분리해야 한다. server/login 토픽을 예로 들면 다음과 같이 Login Proc와 Login Save를 분리해야 한다..

동일 토픽 server/login 에 대해서 각자 처리하는 역할이 다르므로 그룹을 GroupA, GroupB 이렇게 나눠줘야 한다. 물론 GroupA, GroupB는 임으로 지어준 이름이다. GroupLoginProc,GroupLoginSave 이렇게 의미 전달될 수 있도록 맘대로 정해주면 된다.

이걸 위 그림에다가 그리려니 너무 복잡하다. 점심 먹고 할 일 없으면 GroupA, GroupB 도 그려넣고, 앞에서 배운 broker 이중화도 그려 넣어보자. 과제다.

여기까지다. 끝, End, 쫑, 시마이~

실재 서비스는 server.js 가 하는데, server.js가 죽으면 어떡하죠?

앞에서 broker가 죽으면 다른 broker가 받을 수 있도록 했다. 그래 broker는 이제 안심이다.

그런데 server.js가 죽으면 어떡할 건데. 어떡하긴 뭘 어떡해. 이것도 똑 같다.

server.js 도 여러개 띄워야 한다.

아시다시피 nodejs 는 Single Process / Single Thread 다. 죽으면 서비스 끝이다.

담당자는 팀장한테 끌려간다.😓

그래서 예전엔 죽으면 살리고, 또 죽으면 또 살리고 하는 forever.js 같은 모듈을 사용하기도 하였다. 요즈음은 프로세스 매니저라고 해서 pm2 를 사용한다. 보통 CPU 코어 수 만큼 server.js를 띄우고 요청이 들어오면 돌아가면서 처리하도록 하는거다. 유식한 말로 이거 scale out이라 한다.

이거 해보자.

server.js를 2 개 띄워보자.

앞에서 계속 봐 왔던 server.js 이다. 다만 2개를 띄울 거니까, 어떤 프로세스가 반응했는지 보기 위해

    console.log(process.pid, '가 반응하였음.');

를 추가했다.

server.js

const mqtt = require("mqtt");
const server = mqtt.connect("mqtt://localhost");

server.on("connect", () => {
    server.subscribe("server/login");
});

server.on("message", (topic, message) => {
    console.log(process.pid, '가 반응하였음.');
    var data = JSON.parse(message);
    var client_topic = 'clients/' + data.id;
    if (data.pwd === 'pwd') {
        var res = { msg: 'login ok' };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        var res = { msg: 'login fail' };
        server.publish(client_topic, JSON.stringify(res));
    }
});

자 이 상태에서 server.js를 2개 실행해보자. 1번 server.js 실행

$> node server.js

2번 server.js 실행

$> node server.js

여기서 client.js를 실행하면 어떡게 될까?

$> node client.js

client.js 소스는 아래처럼 바뀐게 없다.

client.js

const mqtt = require("mqtt");
const client = mqtt.connect("mqtt://localhost");

const user = { id: 'client1', pwd: 'pwd' };

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/login", JSON.stringify(user));
});

client.on("message", (topic, message) => {
    console.log(message.toString());
    client.end();
});

client.js 실행

$> node client.js

client.js 실행 결과

어이쿠😨😨😨, login ok 메세지가 2번 떨어진다.

아니나 다를까, 1번, 2번 server.js 가 둘 다 반응하였다.😨😨😨

1번 server.js 실행 결과 2번 server.js 실행 결과

뭐 생각해보면 당연한 결과다. 2개의 server.js가 server/login topic에 sub 하고 있으니까 당연히 이렇게 반응한 것인데.

그런데 우리가 원하는 건 이게 아니다. 한 번에 한 서버만 반응해야지. 그래야 로드밸런싱도 되고, 한 놈이 죽어도 다른 놈이 일을 하니까 이중화라고 말할 수 있고...

라운드로빈 방식으로 한 번에 한 놈한테만 일을 시키는 방법은 없을까?

화투판에서 화투는 선이 한 장씩 줘야한다.

Shared subscriptions

방법이 있다. 제목대로 일반 sub을 공유 sub으로 바꾸면 된다. 어떡해 바꾸냐? 방법은 간단하다.

topic 이름을 server/login 에서 $share/GroupA/server/login 로 바꾸면 된다.

server.js

...
server.on("connect", () => {
    server.subscribe("$share/GroupA/server/login");
});
...

GroupA 라고 썼는데, 이것은 그룹핑을 하기 위한 이름으로 이름이 같으면 하나로 묶인다.

client.js 는 그대로 server/login에 pub 하면 된다.

자 그 결과를 보자. 귀찮아서 그림을 하나로 묶었다. 제일 위에 node clinet.js 실행한 결과를 보면 알겠지만, 1번 server.js만 반응하였다. 한번 더 실행하면 2번 server.js가 반응할 것이다.

pm2

server.js를 하나씩 띄우기도 귀찮을뿐만 아니라, 죽었는지 확인하는 것도 그렇고, 죽으면 다시 살리는 것도 번거럽고. 그래서 나온게 pm2다.

라떼엔 forever.js 이런 걸로 짰지.

이러면 연식이 좀 된 개발자라 생각하면 된다.

ecosystem.config.js

module.exports = {
  apps: [{
    name: 'server',
    script: './server.js',
    instances: 'max',
    exec_mode: 'cluster'
  }]
}

instances : 'max' 로 주면 CPU 코어 수만큼 프로세스가 실행된다.

다음은 client.js를 실행한 결과다.

8 Core PC라 8개 프로세스가 떴지만, client.js 에는 하나만 반응하였다.

Cloud1, Cloud2 2개 있다고 하자.

Cloud1에도 GroupA 를 만들고, Cloud2에도 GroupA를 만들어 두면, Cloud1에 문제가 생겨도 서비스에는 지장이 없다.

멋지지 아니한가~

사실 내가 그린 그림보다 아래 나오지만, Roger Light의 이 그림이 이해하는 더 도움이 된다. 한 번에 한 장씩.🎴🎴🎴

Shared subscriptions 은 Roger Light의 https://cedalo.com/blog/mqtt-shared-subscriptions-guide/ 글을 읽어 보기 바란다. 정확한 스펙은 https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901250 를 참고.

어떡하긴 뭘 어떡해

broker를 여러개 만들어 놓아야지.

우리가 집을 내놔도 부동산 한 군데 내놓나? 아니지 않나? 몇 군데 내놓지. 집 구하러 손님이 오면, 일단 자기가 가지고 있는 매물부터 소개해주고, 손님이 맘에 안들어하면 옆 부당산 매물도 보여준다.(수수료가 반띵이라는 말이 있긴한데...)

Broker도 마찬가지다. 앞 1장 읽어 보신 분들은 알겠지만, broker도 부동산처럼 중간에서 연결해주는 역할을 한다.

하나만 있어선 불안하다.

얘가 죽으면...어떡하지

라는 걱정이 드는 것은 당연하다.

우리도 여러군데 부동산에 집을 내놓듯, broker도 여러개 등록할 수 있다.

여러개라고 해서 client가 pub 하면 broker들이 모두 반응하는 것은 아니다. 등록된 순서대로 한 놈만 반응한다. 만약 1번 broker가 반응이 없다면 그 다음 2번 broker가 그 역할을 한다.

완벽한 Active-Standby 구조다.

정말 그렇게 동작하는지 테스트해보자.

VSCode를 4개로 나누어서

먼저 broker를 2 개 만들어 보자.

1번 broker mq_01.conf

per_listener_settings false
listener 1883
allow_anonymous true

log_dest stderr
log_type all

실행

$> mosquitto.exe -c mq_01.conf

2번 broker mq_02.conf

per_listener_settings false
listener 2883
allow_anonymous true

log_dest stderr
log_type all

실행

$> mosquitto.exe -c mq_02.conf

3번 server.js

const mqtt = require("mqtt");

const options = {
    servers: [{
        host: 'localhost',
        port: 1883
    }, {
        host: 'localhost',
        port: 2883
    }]
};

const server = mqtt.connect(options);

server.on("connect", () => {
    server.subscribe("server/login");
});

server.on("message", (topic, message) => {
    var data = JSON.parse(message);
    console.log('server', data);  
    var client_topic = 'clients/' + data.id;
    if (data.pwd === 'pwd') {
        var res = { msg: 'login ok' };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        var res = { msg: 'login fail' };
        server.publish(client_topic, JSON.stringify(res));
    }
});

4번 client.js

const mqtt = require("mqtt");

const options = {
    servers: [{
        host: 'localhost',
        port: 1883
    }, {
        host: 'localhost',
        port: 2883
    }]
};

const client = mqtt.connect(options);

const user = { id: 'client1', pwd: 'pwd' };

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/login", JSON.stringify(user));
});

client.on("message", (topic, message) => {
    console.log(message.toString());
    client.end();
});

시나리오는 이렇다.

1. 1번, 2번에 각각 broker를 띄워놓고,
2. 3번 server.js를 실행하면 1번에 붙는다.
3. 4번 client.js를 실행하면 이것도 1번에 붙고, 3번 server.js가 반응한다.
4. 이 상태에서 1번을 Ctrl-C로 죽이면, 3번 server.js가 2번 broker에 붙는다.
5. 4번 client.js를 다시 실행하면, 2번 broker에 연결되어 3번 server.js가 반응한다.

시나리오대로 실행한 동영상이다. PC에서 봐야 눈이 안 아플것이다.

알흠답지 아니한가~

그래서 IDC에 불이 나면?

broker를 서로 다른 cloud 에 두면 IDC에 불이 나도 서비스에는 지장이 없을 것이다.

문 앞에서 민증 깠다고 다 된 건 아니다. 20대는 홀로, 30대는 룸으로~ 선글라스 아저씨가 안내하는 곳으로 가야 한다. 노는 물이 다르다.

pub/sub 도 마찬가지다. server는 server 토픽에 붙고, client는 client 토픽에 붙어야지. client가 server 토픽에 붙으면 안된다. 그랬다가는 다른 사람 대화 내용을 다 들여다 볼 수 있다. 개폭망이다.

저 아저씨 귀에 꽂고 있는 거 뺏긴 것과 같은 거다. 몰래 다 듣고 있다는 뜻이다.

자 그럼 어떡해야 하나?

앞 글 1. Pub/Sub으로 로그인? 에 나와 있는 아래 그림을 보자.

1. sub server/login : server/login으로 들어오는 건 내가 처리할께
2. sub clients/client1 : 결과는 clients/client1 로 주세요
3. pub server/login : server님, 저 login할래요
4. pub clients/client1 : clients/client1 DB에 있는 패스워드랑 다른데...너 누구냐?

즉 server는 server/# 을 subscribe(read)하고, clients/# 에 publish(write)한다. 반대로 client는 clients/# 을 subscribe(read)하고, server/# 에 publish(write)한다.

이게 우리의 룰이다.

client가 server/# 을 subscribe(read) 하면 안된다. 어떻게 해야할까?

즉 누가 어떤 topic에 sub할지 pub할지 정해주는게 필요하다. 자율에 맡기면 X된다. 그래서 나온게 ACL이다.

ACL

ACL(Access Control List)은 프로토콜 영역이 아니다. MQTT 3.1 Spec에서 검색해봐라. 안 나온다.

누가 어디에 붙을 수 있는지 정하는 건 broker 영역이다. 이건 mosquitto conf 에서 찾아야 한다.

위 문서에서 acl로 검색해보면 다음과 같이 나온다.

우리 규칙에 맞게 시키는대로 acl_file을 만들자.

acl

# deny anonymous access
topic deny $SYS/#

user server
topic read server/#
topic write clients/#

user client
topic write server/#
topic read clients/#

일단 $SYS/# topic은 시스템 정보이므로 아무나 접근 못하게 막고,

server는 server/# 을 subscribe(read)하고, clients/# 은 publish(write)한다. client는 clients/# 을 subscribe(read)하고, server/# 에 publish(write)한다.

멋지지 않은가

설정 파일에 acl을 등록하자.

mosquitto.conf

acl_file C:\Program Files\mosquitto\conf.d\acl

백문이불여일테스트

아래 코드는 앞에서 봤던 server.js로, 제대로 된 자격증명(server/pwd)으로 로그인한 거다. 다만 TLS/SSL 들어가면 복잡하니까, 최대한 단순하게 하기 위해 뺐자. 제대로 동작하는지 확인하기 위해 message를 받으면 출력하도록 바꿨다. 개발자가 가장 많이하는 디버깅 아닌가.

1번 server.js

const mqtt = require("mqtt");

const options = {
    port: 1883,
    host: 'stark',
    username: 'server',
    password: 'pwd'
}

const server = mqtt.connect(options);

server.on("connect", () => {
    server.subscribe("server/login");
});

server.on("message", (topic, message) => {
    var data = JSON.parse(message);
    console.log('server', data);
    var client_topic = 'clients/' + data.id;
    if (data.pwd === 'pwd') {
        var res = { msg: 'login ok' };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        var res = { msg: 'login fail' };
        server.publish(client_topic, JSON.stringify(res));
    }
});

아래는 fake 자격증명(client/pwd)으로 클라이언트 중 한 놈이 마치 server인양 server.js 를 실행한거다. 로그인은 통과하겠지만, 진짜 server가 아니다. 제대로 동작하는지 확인하기 위해 message를 받으면 출력하도록 했다.

2번 fake_server.js

const mqtt = require("mqtt");

const options = {
    port: 1883,
    host: 'stark',
    username: 'client',
    password: 'pwd'
}

const server = mqtt.connect(options);

server.on("connect", () => {
    server.subscribe("server/login");
});

server.on("message", (topic, message) => {
    var data = JSON.parse(message);
    console.log('fake_server', data);
    var client_topic = 'clients/' + data.id;
    if (data.pwd === 'pwd') {
        var res = { msg: 'login ok' };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        var res = { msg: 'login fail' };
        server.publish(client_topic, JSON.stringify(res));
    }
});

자 이 상태에서 3번 client.js를 실행하면 어떻게 될까?

$> node client.js

당연히 1번 server.js는 반응하지만, 2번 fake_server.js는 반응하지 않는다.

우쒸! fake_server.js에서 오류라도 떨어져야되는 거 아니예요.

Web 로그인에서도 아이디가 틀렸다, 패스워드가 틀렸다 이렇게 세세하게 안 알려준다. 뭔가를 알려주면 해커는 그것으로 유추하기 때문에, 걍 무응답이 답이다.😁

acl 파일의 server 부분은 다음과 같이 하나 하나 써주는게 보안에 도움이 된다.

acl

# deny anonymous access
topic deny $SYS/#

user server
topic read server/login
topic read server/logout
topic read server/signin
topic read server/signout
topic read server/talk
topic write clients/#

user client
topic write server/login
topic write server/logout
topic write server/signin
topic write server/signout
topic write server/talk
topic read clients/#

보안에는 4단계가 있다(고하더라).

• 네트워크 수준 보안
• 전송 수준 보안
• 애플리케이션 수준 보안
• 페이로드 암호화

일단 영어가 섞여 있으니 용어가 어질어질하다.

아무리 못해도 Web만큼은 해줘야하지 않겠니?

그래서 딱 2개, 2번 TLS/SSL 보안과 3번 자격증명 해보자. 나머지는 이 글 범위를 넘어선다(라고 쓰고 줄행랑💨💨💨).

자격증명 ▶ 민쯩 까봐!

맨 먼저 내가 누군지 확인 안 된 놈은 입구컷이다. 그래야 어장 관리가 되지 안 그러면 broker 거덜난다. mosquitto는 기본적으로 localhost 로 붙을 땐 자격증명 없어도 붙지만, 외부에서 붙을 땐 자격증명이 필요하다. localhost고 뭐고 무조건 내가 누군지 까야 붙을 수 있게 하려면 mosquitto.conf 파일에 다음과 같이 하면 된다.

그리고 mosquitto 2.0 이상에서는 localhost가 아닌 다른 곳에서도 붙게 하려면 listener를 정의해야 한다. 보안 때문에 강화된 거란다.

mosquitto.conf

listener 1883
allow_anonymous false

그 다음 입장자 명단을 만들고, 해킹을 대비해 암호화 한다. password

server:pwd
client:pwd

이 파일은 mosquitto_passwd 프로그램으로 다음의 명령으로 암호화하라.

$> mosquitto_passwd.exe password

그러면 파일이 아래와 같이 변하는 기적을 맛볼 것이다.

password

server:$7$101$p4wSJs3pD1lwGE2X$HeddQkc56jh2ZehHeCe/W+dq3EgynumOmMdYTkw8hdu8rKXbOjWPfYiqmM/wmTh3oIyu6fcVyH4w84E/SRIMjw==
client:$7$101$QZizFrfQBO53ZAcq$J6GR7oh5UqeK3UGOVy7EpG0Sf7TIJObl6pkRTyjA8j4xy3jdbS0kJEjOSt7IQ6K5tsqpgwHkmubbxKf0gg97/w==

broker(mosquitto) 설정

password 파일을 만들었으면 준비는 다 된거다. 이 파일을 mosquitto.conf 파일에 추가하고 함 껏다 켜준다.

mosquitto.conf

listener 1883
allow_anonymous false
password_file C:\Program Files\mosquitto\conf.d\password

이제 우리는 정문에 기도를 세워 둔거다. 기본 어장 관리는 된다고 보면 된다.

server.js, client.js 설정

client 입장에서는, 이제 물관리하는 이 아저씨를 통과해야 한다.

당연히 민증 까야지.

server.js

const options = {
    host: 'stark',
    port: 1883,
    username: 'server',
    password: 'pwd'
}
const client = mqtt.connect(options);

server도 borker 입장에서는 client다.

client.js

const options = {
    host: 'stark',
    port: 1883,
    username: 'client',
    password: 'pwd'
}
const client = mqtt.connect(options);

'stark'가 뭐냐구? hosts 파일에 등록한 mosquitto 서버 이름이다.

C:\Windows\System32\drivers\etc\hosts

192.168.219.101 stark

이름이 왜 stark 냐구? mosquitto example 에 있는 이름 그대로 썼다.

TLS/SSL 암호화

네트웍 중간에 김선생이 청진기 대고 있으면 어떡할건가?

다음은 wireshark으로 패킷 캡쳐한 것이다. 암호화하지 않았을 경우 server/login 으로 넘긴 데이터가 다 보인다. 뜨악😱이다.

이 상태로 플젝 끝했다가는 개폭망이라 봐도 무방하다.

김선생 못 알아보게 만들어야 한다. 다음은 TLS로 암호화한 것이다. 뚫어져라봐도 당췌 뭐가 오고 간 것인지 추측도 하기 어렵지 아니한가 우하하하. 심지어 topic명도 알아 볼 수 없다.

이거 해보자 했는데, 이미 한 분들 많더라.😂 인증서 만드는 것은 이 글을 따라하면 된다. 다만 nodejs 관련 설정은 다음과 같이 하면 된다.

server.js

const fs = require('fs')
const path = require('path')
const KEY = fs.readFileSync(path.join(__dirname, '/tls/server.key'))
const CERT = fs.readFileSync(path.join(__dirname, '/tls/server.crt'))
const TRUSTED_CA_LIST = fs.readFileSync(path.join(__dirname, '/tls/ca.crt'))

const options = {
    port: 1883,
    host: 'stark',
    username: 'server',
    password: 'pwd',
    key: KEY,
    cert: CERT,
    rejectUnauthorized: true,
    ca: TRUSTED_CA_LIST,
    protocol: 'mqtts'
}

const server = mqtt.connect(options);

client.js

const fs = require('fs')
const path = require('path')
const KEY = fs.readFileSync(path.join(__dirname, '/tls/client.key'))
const CERT = fs.readFileSync(path.join(__dirname, '/tls/client.crt'))
const TRUSTED_CA_LIST = fs.readFileSync(path.join(__dirname, '/tls/ca.crt'))

const options = {
    port: 1883,
    host: 'stark',
    username: 'client',
    password: 'pwd',
    key: KEY,
    cert: CERT,
    rejectUnauthorized: true,
    ca: TRUSTED_CA_LIST,
    protocol: 'mqtts'
}

const server = mqtt.connect(options);

사실 보안을 다룰 때 '완벽' 이란 없다. 외부 침투를 아무리 완벽하게 막았다고 하더라도, 대부분 구멍은 내부자에게 있다. 스노든 아저씨를 봐라.

따라서 자격증명 파일, 인증서 파일은 은밀한 곳에 따로 보관하자. 적어도 production 환경이라도...🙏🙏🙏

MQTT 코딩할 때 가장 많이 고민되는게 있다. 보내는 놈의 QoS 랑, 받는 놈의 QoS.

나는 QoS=1로 보내고, 받는 놈이 QoS=2로 받으면 확실하지 않을까?

이거에 대한 썰을 풀고자 한다.

자, 자 각설하고 우리야 client와 server 라고 하지만, broker 입장에서는 둘 다 client 아니겠나.

다음을 생각해보자. client와 server 가 서로 다른 QoS를 사용할 때 QoS는 어느 쪽을 따를까?

세상에 당신이 최초로 고민한 문제는 없다. 구글신한테 물어봐라.

사수한테 물어보면 위와 같은 대꾸를 듣는다. 사수님의 말이 맞다. 당연히 이것도 테스트한 사람이 있다.

Roger Light 가 만든 다음 시나리오 표를 보자. 앞에 2개는 설정(setting)이고, 뒤 2개는 결과다.

1번은 받는 놈이 아무리 QoS를 1, 2로 하더라도 보내는 QoS가 0 이면 받는 QoS도 0 이라는 거다. 2,3번도 같은 맥락으로 이해할 수 있다.

즉 아무리 내가 보낼 때 높은 QoS로 보내도, 받는 쪽이 어떻게 받도록 설정하느냐에 따라 달라진다는 거다.

유식한 말로 QoS Downgrade 현상이라고 한다.

따라서 4번과 같이 보내는 QoS와 받는 QoS를 맞추는 것이 정신 건강에 이롭다.

QoS별 속도 차이

QoS가 높아질수록 신뢰도는 높아지지만 속도는 느려질 것같다는 느낌적 느낌은 받는데....

그렇다 이건 느낌이다. 숫자가 아니다.

회의 시간에 느낌만 이야기 하면 초급 취급 받는다. 숫자를 제시해야 한다. QoS별로 초당 몇 개의 Packet을 보낼 수 있는지에 대한 다음 벤치마킹 데이터를 보자.

보내는 건 별 차이가 없는데, 받는 건 드라마틱한 차이가 보인다. 솔직히 이 자료보고 나도 놀랐다. 생각보다 QoS=1이 QoS=2보다 안 빠르네 😰 이거 보니 괜히 QoS=0 으로 프로그램 고치고 싶어진다😝

해보고 잘되면 목에 힘주고 아무한테도 알려주지 말고 연봉협상💰 때 넌지시 얘기하라.

말을 하는데, 상대가 '응', '응' 하며 추임새를 넣어주면 말하는 사람도 신이 난다.

그런데 내 말엔 신경도 안 쓰고 지 할 일만 하는 놈도 있다. '늬 내 말 듣고 있니?' 라고 답답해서 중간에 물으면 '야...다 듣고 있어!' 이러면 짜증 제대로다.

이번 글에서는 내가 talk을 날렸을 때, 상대편 대응 방식에 따라 어떻게 톡 프로그램을 코딩해야 하는 지 알아보자.

즉 대꾸하는 분과 대꾸없는 놈, 두 케이스에 대해서...

pub/sub 통신에서는 보내는 사람과 받는 사람, 즉 종단간의 연결 보다는 중간에 있는 broker 와의 대화에 집중한다. broker와의 통화 품질을 QoS라고 하는데, 여기에는 다음 3가지가 있다.

QoS

이건 client인 나와 broker인 너와의 관계다. pub하는 client와 sub하는 server와 관계는 제 3자인 broker가 끼여드는데, 이것도 여기에 기초한다.

다음은 QoS 별 응답 프로토콜이다. 자세한 내용은 참고를 클릭하면 되는데.... 슬프게도 영어다😭😭😭

지면도 남고 하니 하나씩 알아보자.

Qos Level 0

쏘고 잊으세요.

이거 딱 그거다. 월요일 아침에 하는 교장 선생님 훈화 연식 들통나는 건가 😜 자기 말만 하고 땡이다

그림 보면 알겠지만, 쏘기만 한다. Broker도 마찬가지다. Subscriber한테 쏘기만 한다.

요 걸 3자 관계로 그려보면 다음과 같다.

Publisher는 Broker한테 쏘고 Broker도 Subscriber한테 쏘기만 할 뿐 받았는지 관심이 없다. 말 그대로 쏘고 잊는다. 메세지 저장 이딴 것 없다.

따라서 ㅈㄹ 빠르다.

소스로는 _{ qos: 0} _ 만 추가하면 된다.

const mqtt = require("mqtt");
const client = mqtt.connect("mqtt://localhost");

const user = { id: 'client1', pwd: 'pwd' };

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/payload", 'hi', { qos: 0 }, (err, res) => {
        if (err) console.log('err', err);
        else console.dir(res);

        client.end();
    });
});

요걸 실행해보면

callback 함수 res 가 undefined다.

이 딴 걸 어디에다 쓰냐고? 다 필요하니까 만들어 둔 것이다. 온,습도 센서가 온,습도를 pub한다고 했을 때, 받는 쪽 입장에서는 최신 데이터가 젤 중요하다. 이럴 땐 QoS 0 이 딱이다. 중간 것 몇 개 잃어 버려도 개안타~

Qos Level 1

최소 한 번은 보내라.

이건 매번 확인하는 거다. 내 말 들었는지. '응', '응' 하는 맞장구가 없으면 한 말 또 하는거다.

Publisher는 Broker한테 쏘고 Broker는 Subscriber한테 쏘고 PUBACK을 돌려준다. PUBACK을 실패하면 Broker는 저장해두었던 걸 한 번 더 보낼 수 있다.

QoS 0 보다는 아니지만, 나름 빠른데, 1번 이상 Subscriber가 받을 수 있다.

QoS 만 0에서 1로 바꾼 소스다.

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/payload", 'hi', { qos: 1 }, (err, res) => {
        if (err) console.log('err', err);
        else console.dir(res);

        client.end();
    });
});

요걸 실행해보면

res.cmd 에 'publish', 그리고 broker가 따 준 messageId가 들어왔다.

중복 문제만 없다면 요거이 딱인데...😅

QoS Level 2

딱 한 번만 보내라.

요건 빼도 박도 못하게 도장 꽉꽉 찍어두는거다.

딱 한번만 보내고/받기 위해서는 Broker가 중간에서 보낸 놈과 받는 놈을 잡고 서로 주고 받은 걸 확인 시켜주는 작업을 한다. 그러다 보니 확인하는 프로토콜(PUBREC,PUBREL,PUBCOMP)이 많고, 당연히 통신도 느려진다. Broker도 할 일이 많다보니 부하도 많이 걸리고, 그림 보면 알겠지만 Publisher, Subscriber 도 뭔가 복잡하고 바쁘다.

Qos 를 2로 바꾼 소스다.

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/payload", 'hi', { qos: 2 }, (err, res) => {
        if (err) console.log('err', err);
        else console.dir(res);

        client.end();
    });
});

이를 실행하면

res.cmd 에 'pubrel', 그리고 broker가 따 준 messageId가 들어왔다.

요거이 우리가 원하는 바이긴 한데, 느리다는 단점이 있다.

QoS 2와 같이 중복없이 가는데, 빠른 방법은 없을까?

QoS = 1과 중복 방지

받았다는 걸 확인할 수 있는 PUBACK은 받지만, 중복을 피하고 싶다. 즉 QoS = 2의 효과를 원하지만, 속도가 느린 건 원치 않는다. 이건데...

세상에 공짜가 있나 Broker 부하를 줄이려면 누군가 그 부하를 져야할텐데

누가 그 부담을 질 것인가?

Database <- 얘 밖에 없다.

어떻게?

Insert 대신 Upsert로

쫑날 수도 있으니, Upsert로 ... Upsert하려면 PK가 있어야 하는데.

아 그러면 client에서 talk을 쏠 때 unique한 talk_id를 만들어서 쏘면 되지 않을까?

talk_id를 unique하게 만드는 방법은 Date.now() 를 쓰던 UUID를 쓰던 방법은 많을 것이다. 그래도 쫑이 걱정된다면 prefix를 줘서 나미 따듯 쫑 안 나게 비켜가게 해야지. 이는 각자 개발 짬에 따라 코딩하시라.

client.js 수정

const { v4: uuidv4 } = require('uuid');

...

rl.on('line', function (line) {
    if (line === 'exit') rl.close();

    const talk = { data: { talk_id: uuidv4(), from: user_id, room: 'room1', msg: line } };
    client.publish("server/talk", JSON.stringify(talk));

    rl.prompt()
});

server.js 수정

    mysql_conn.sql(UPSERT_TALK, [json.data.talk_id, json.data.from, json.data.room, json.data.msg, json.data.talk_id], function(err, results, fields) {
      room.forEach(client => {
          if (talk.data.from === client) return false;
          let client_topic = 'clients/' + client + '/talk';
          server.publish(client_topic, message);
      });
    }

이건 번외지만 SQL 이 다음과 같이 바뀔 것이다.

Before

INSERT INTO talk_table (from, room, msg)
VALUES (#{from}, #{room}, #{msg});

After

INSERT INTO talk_table (id, from, room, msg)
VALUES (#{talk_id}, #{from}, #{room}, #{msg}) ON DUPLICATE KEY
UPDATE id = #{talk_id};

장군께서는

나의 죽음을 적에게 알리지마라

라고 하셨지만, client는 자신의 죽음을 server 에게 알려야 한다. 이것을 LWT(Last will and testament) 라고 하며 고급지게 유언 이라 한다. 우리는 죽을 때 말(言)을 남기는데, 서양은 윌(Will)을 남기나 보다.

죽었니? 살았니?

장군의 죽음을 왜군이 알아선 안되지만, server는 client 상태를 알아야 한다. 왜? server가 talk을 보낼 때(전파할 때) 이 톡을 받는 주체는 client의 mqtt_connect이다. client의 mqtt_connect이 살아 있는지, 아니면 죽었는지에 따라 pub할지 push할지 결정하기 때문이다.

client의 mqtt_connect가 죽었는지, 살았는지 알려면 어떡해해야할까? will이 그 답이다. client의 mqtt_connect 가 죽으면 boker가 client의 will을 보낼 것이다. server는 이 will을 수신하고 있다가, 어느 client가 죽었는지? 살았는지 판단하면 된다.

mqtt_connect 생사 여부와 별개로 앱에서 앱 Noti 띄우는 건 또 다른 로직이다. client 앱에서는 mqtt_connect 가 살아 있고, foreground 상태이며, 현재 message와 동일 room 에 있다면 앱 Noti에 등록하지 않고 톡방에만 쏘면 된다. 그 이외에는 Noti에 띄워야 한다. 앱 개발자라면 이 말을 이해할 것이다.

어떻게 나의 죽음을 알릴 것인가?

lwt의 기본 개념은 이렇다. 죽기 전 lwt(유언)을 써 놓고, 내가 죽으면 내 죽음에 관심있는 자(여기선 server겠지)에게 뿌리라고 borker에게 부탁하는거다. 즉 client가 mqtt 연결할 때 lwt를 함께 등록하는 거다. nodejs mqtt에서는 다음과 같다.

클라이언트에 추가되는 코드

client에 추가하는 코드는 단순한다. 접속할 때 나의 will을 등록하면 된다. 요렇게 해 놓으면 connection이 끊어지면 broker(브로커라기보단 변호사네😏) 가 나의 죽음에 관심있는(sub하고 있는) 이들한테 이를 뿌려준다.

const user_id = process.argv[2]; //'client1';

const client = mqtt.connect({
    host: 'localhost',
    will: {
        topic: 'server/die',
        payload: JSON.stringify({ data: { id: user_id } })
    }
});

내 죽음에 관심 있는 자들이 여럿 있겠지만 😂, server가 가장 관심이 있을 것이다. 왜냐하면 이를 DB에 저장하고 pub할지 push할지 결정해야 하기 때문이다. 따라서 서버 토픽인 server/die로 이름 짓자.

서버에 추가되는 코드

이제 서버가 server/die topic도 sub하도록 추가하면 된다.

server.on("connect", () => {
    server.subscribe(["server/login", "server/talk", "server/die"]);
});

그 다음 server/die가 들어왔을 때 처리하는 함수만 짜 넣으면 끝.

server.on("message", (topic, message) => {
    console.log('received: ', topic, JSON.parse(message));
    if (topic.endsWith('/login')) process_login(message);
    else if (topic.endsWith('/talk')) process_talk(message);
    else if (topic.endsWith('/die')) process_die(message);
});

...

function process_die(message) {
    let json = JSON.parse(message);
    mysql_conn.sql(UPDATE_USER_STATE, [json.data.id,'inactive'], function(err, results, fields) {
    ...
    }
}

서버가 있어 너무 행복😁하지 아니한가?

다른 상태는?

active는 따로 로직을 뺄 필요도 없다. active는 로그인 시 active로 DB에 Update하도록 추가하면 된다. uninstall은 앱 삭제 이벤트 받아 Update하면 된다.

• talk은 pub이다.
• 읽고 쓰기는 DB다.

엄마는 여자고, 아빠는 남자다

만큼 쉽지 아니한가😁😁😁

Talk Talk Talk

자,자, 이제 톡을 날려보자. 사실 톡하는 건, socket.io와 별 반 다를 게 없다.

• client가 server/login으로 로그인하고, server/talk으로 talkjson을 날린다.
• 이 talkjson 안에는 어떤 room 에다가 어떤 내용으로 날렸는지 다 들어 있다.
• server는 talk을 받으면, 받아볼 다른 client들한테 차례차례 전달한다.

여기서 핵심은 이 모든 것을 server 를 통해서 한다는 것이다. broker로 이를 구현하려면 개발 인생😵 말린다.

먼저 뭘 짤건지 설명해보자.

그래야 코딩 이해가 쉽다.

다음은 client1 과 client2 가 room1 에서 대화하는 내용이다.

client1 실행 캡쳐

client1 이란 이름은 아래처럼 command line 변수로 받는다.

$> node client.js client1

2번째 라인이 자기가 날린 톡이고, 3번째 라인이 client2로 부터 받은 톡이다.

client2 실행 캡쳐

$> node client.js client2

이건 설명 안해도 이해가 되죠잉😏😏😏

server 실행 캡쳐

대충 돌아가는 걸 봤으니, 코드로 이를 확인해보자. 코드부터 들이 밀면 울렁증 느끼더라.

토발즈 형님도 말씀하셨다. 이빨 그만 좀 털어라~

서버님에게 추가된 Code

server/login로 로그인 요청 들어오면 process_login function 불러주고, server/talk로 톡 요청 들어오면 process_talk function 호출하면 끝.

야호🚀 프로그램 개쉽네.

server.js

const mqtt = require("mqtt");
const server = mqtt.connect("mqtt://localhost");
const rooms = { 'room1': ['client1', 'client2', 'client3'] };

server.on("connect", () => {
    server.subscribe(["server/login", "server/talk"]);
});

// login인지, talk인지 구분
server.on("message", (topic, message) => {
    console.log('received: ', topic, JSON.parse(message));
    if (topic.endsWith('/login')) process_login(message);
    else if (topic.endsWith('/talk')) process_talk(message);
});

// login 처리
function process_login(message) {
    let json = JSON.parse(message);
    let client_topic = 'clients/' + json.data.id + '/login';
    if (json.data.pwd === 'pwd') {
        let res = { data: { msg: 'login ok' } };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        let res = { error: { code: 404, msg: 'pwd mismatch' } };
        server.publish(client_topic, JSON.stringify(res));
    }
}

// talk 처리
function process_talk(message) {
    let talk = JSON.parse(message);
    let room = rooms[talk.data.room];
    room.forEach(client => {
        if (talk.data.from === client) return false;
        let client_topic = 'clients/' + client + '/talk';
        server.publish(client_topic, message);
    });
}

앗! 잠깐, velog 운영자님 코드블럭 문법 강조 기능 좀 넣어줘요. Code Reading 힘들어요. 쓰는 나도 보기 힘든데😥😥😥

요로코롬 나오게...

클라이언트에 코드 추가

유튜버 생각해보자. 자신만의 채널이 있다.

클라이언트도 자신만의 채널이 있어야 한다. 서버와 비밀스럽게 통신할 채널.

자 내 아이디는 client1 이라 해보자. 그러면 내 채널은 clients/client1/# 이 되는 거다. 이렇게 해야 client2가 client1의 내용을 볼 수 없지 않겠는가.

물론 실 서비스에서 cleint1 같이 쉽게 추측 가능한 이름 쓰면 안된다. UUID 이런 거 써야 한다. 프로젝트에서 그냥 client1 이렇게 따라하면 폭망💣이다.

하는 일은 서버랑 똑 같다.

clients/client/login로 로그인 응답이 들어오면 process_login function 불러주고, clients/client/talk로 톡 응답이 들어오면 process_talk function 호출하면 끝이다.

다만 마치 톡 앱처럼 보이려고(고민 많이했다) 사용자 입력을 받는 readline 추가했다.

client.js

const mqtt = require("mqtt");
const client = mqtt.connect("mqtt://localhost");
const readline = require("readline");

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout,
    prompt: '',
});

const user_id = process.argv[2]; //'client1';
const user = { data: { id: user_id, pwd: 'pwd' } };

client.on("connect", () => {
    client.subscribe(['clients/' + user_id + '/login', 'clients/' + user_id + '/talk']);
    client.publish("server/login", JSON.stringify(user));
});

// login인지, talk인지 구분
client.on("message", (topic, message) => {
    if (topic.endsWith('/login')) process_login(message);
    else if (topic.endsWith('/talk')) process_talk(message);
});

// login 처리
function process_login(message) {
    let res = JSON.parse(message);
    if (!!res.data) rl.prompt();
    else if (!!res.error) client.end();
}

// talk 처리
function process_talk(message) {
    let talk = JSON.parse(message);
    console.log(`${talk.data.from} : ${talk.data.msg}.`);
}

// 화면에서 메세지 받아 톡을 보낸다.
rl.on('line', function (line) {
    if (line === 'exit') rl.close();

    const talk = { data: { from: user_id, room: 'room1', msg: line } };
    client.publish("server/talk", JSON.stringify(talk));

    rl.prompt()
});

// 화면에서 'exit' 라고 입력하면 끝낸다.
rl.on('close', function () {
    if (!!client) client.end();
    process.exit();
});

login 기록📋을 남겨라

분명 첨에 쌍둥이 아기들이 말했다. 2개는 외우라고. 읽고, 쓰기는 DB라고.

기록을 남기고, 사용자 정보를 읽어오고, room 에는 누가 누가 있는지 알려면 DB를 함 갔다 와야 한다. DB를 갔다오는 건 당연히 server가 할일이다. 그리고 DB와 뭔 일을 하려면, callback 으로 짜던지 async 로 코딩해야 한다는 건 코린이들도 다 아는 사실. 대충 아래처럼 해주면 되겠다.

server.js의 process_login 일부

    if (json.data.pwd === 'pwd') {
        mysql_conn.sql(INSERT_USER_LOGIN, [json.data.id], function(err, results, fields) {
          let res = { data: { msg: 'login ok' } };
          server.publish(client_topic, JSON.stringify(res));
        }
    } else {

talk 기록📋도 남겨라

talk 기록도 마찬가지다. DB에 저장하는 코드를 넣으면 된다. room에 누가 있는지, DB에 노크해서 문 열고 보면 된다. 그리고 한 명씩 차례로 톡을 보내면 된다. 괜히 짬도 안되면서 남의 room 열었다가 기도한테 개맞는 수도 있다. 누구는 이러겠지. rooms/room1 처럼 만들어서 거기다 쏘면 안되냐구... 된다...

Just Do it 🚀🚀🚀

방이 없는 상태에서 개톡 날릴 때, 방 이름 생성하기 위해 pub 하고, 클라이언트는 그거 sub 하는 거 해봤다. 쉽지 않더라😂 그래서 일관성 있게 전부 이렇게 했다.

방 이름도 room1 이렇게 하면 client 이름처럼 폭망💣한다.

어쨌든 여기서 핵심은 room 이 아니라 room 안에 있는 client에게 직접 talk을 날리는 거다.

요걸 코드로 짜보면 다음과 같다.

server.js의 process_talk 일부

    mysql_conn.sql(INSERT_TALK, [json.data.from, json.data.room, json.data.msg], function(err, results, fields) {
      room.forEach(client => {
          if (talk.data.from === client) return false;
          let client_topic = 'clients/' + client + '/talk';
          server.publish(client_topic, message);
      });
    }

보낸 놈한테는 아래처럼 안 보내는 게 낫다.

if (talk.data.from === client) return false;

client가 talk을 pub 하고 puback이 안오면 아래처럼 안갔어요! 다시보낼깝쇼? 빨간 거 달아주면 되겠다.

talk 받을 놈이 어디 갔다면?

요게 요게 문제다. 핸드폰을 켜 놓긴 했는데, 뒷주머니🚶나 가방👜에 둔 상태라던지, 톡은 안 보고 틱톡 보고 있다던지, 백번 양보해서, 우리 앱을 보고는 있는데, 다른 방에서 열심히 톡하고 있을 때 말이다. 보통 이럴 때 app push 날린다.

push server 구축 이런거, 여러분 실력이라면 껌인줄 안다. 하지만 네카라쿠배 다니는 분들한테 양보하고 Android는 그냥 FCM 쓰는 걸로 하자.

FCM 보내려면 FCM token이 필요하다. 앱 개발자님에게 음료수 사주면서 조신하게 물어보면 알려줄끼다. 안 알려주면 FCM Message 보내는 법을 참고하라.

정리

정리 이런거 해줘야 뭔가 수미일관되게 글을 썼다 이런 삘😍 받는다. 첨에 말했다. talk 하고, 읽고 쓰기... 딱 2개 해봤다.

웹서비스 로그인은 전형적인 방식이 있다. POST로

{
  id:"hong_gil_dong",
  pw:"password1234",
  ...
}

을 날리면 서버가 DB에서 비번 맞춰보고 맞으면 로그인 아니면 우리집에 왜 왔니? 하면 된다.

그런데 이건 웹 프로그램 짤 때고... Pub/Sub Broker 세상에서는 어떻게 하지?😒😒

Broker 세상은 그렇게 돌아가는게 아녀

다 아는 얘기 한번 해보자. Broker 방식은 복덕방하고 똑같다. 방구하러 온 사람이 떡방 할배에게 말한다.

여기 현대빌라 203혼데요, 저희 이번에 나가서 집 내놔요. 방 3개고 재작년에 지은 신축이예요. 전번은 010-1234-5678이고, 제가 일을 해서 집은 저녁 7시 이후 보여줄 수 있어요.

집 내 놓는다는 말이다. 유식하게 이를 pub 이라 한다.

2인 가족이 살건데요. 채광 좋고, 단독 전세 나오면 연락해주세요.

집 구하니, 연락 달라는 말이다. 유식하게 sub이라 한다.

떡방 할배가 장부 뒤져 그런 집이 있으면 이분한테 연락한다. 즉 pub 날리는거다.

어, 할배가 sub도 받고, pub도 날리고 혼자 다하네.☎☎

이제 pub/sub이 방향의 문제임을 눈치챘을 것이다. sub한 놈한테 pub하는거다.

pub 받을려면 sub해 놔야한다. 같은 말이다.😁😁

자 이제 로그인 문제로 돌아와보자. 위 그림은 login 요청하고, login 응답하는거다.

Broker는 둘만 있는 세상이 아니다. Broker 한테 로그인 처리 해달라고 하면 화낸다. 웹서버 방식이 아니라, 쉽지 않다.

오똑케하면 이 문제를 해결할 것인가?

물론 Broker 자체에 로그인 기능이 있지만, 그건 떡방 할배 사무실 이름이랑 전번이다. 우리가 원하는 건, DB에 있는 사용자 정보에 접근해서 거기랑 맞춰보는거다.

Client/Server 방식은 쉽지 ㅎ

떡방 아저씨 입장에선 모두가 client다. 집을 구하는 사람도 client고, 집을 내놓는 사람도 cleint다. 왜? 둘 다 돈을 주니까...😁😁😁 왓어 원더플 월더 다.

Broker 세상에는 client만 있고, server 는 없다.

다들 돈 낸는 client라고 일은 안하고, 다리 꼬고 앉아 있다. 누가 로그인 처리할 것인가? 방법이 없을까?

있다. client 중 한 놈을 패서 server로 만들자.

그냥 그 client 이름을 server라 붙이면 된다. 인자부터 니가 server 해👊👊👊

진실의 방을 다녀오고 나면 다음과 같이 고분고분해진다.

1. sub server/login : server/login으로 들어오는 건 내가 처리할께😢
2. pub server/login : server님, 저 login할래요😄

됐다. borker로 server/client 만들었다. 사실 한 놈 뚜까 패서 server 시켰다.😁😁😁😁😁😁

이제 server가 비번 맞춰보고 login 해줄지 말지 응답하면 된다. 자, 이제 User는 login 응답만 받으면 된다. 엥. 근데 응답 콜은 어떻게 받지?

맛집 앞에서 줄만 잘 선다고 끝 아니다. 아무리 기다려도 안 부를 수 있다.

뒤에 온 놈이 먼저 들어가는 더러운 꼴 볼 수 있단 말이다. 대기책자📝에 이름이랑 전번 써놔야 여친한테 사랑💏받는다.

Broker 세상도 마찬가지다. 응답 콜 받겠다고 미리 등록(sub)해야 한다.

1. sub server/login : server/login으로 들어오는 건 내가 처리할께
2. sub clients/client1 : 결과는 clients/client1 로 주세요
3. pub server/login : server님, 저 login할래요
4. pub clients/client1 : clients/client1 DB에 있는 패스워드랑 다른데...너 누구냐?

Broker는 왼손으로 요청 받아서, 오른손으로 전달해주는 역할을 한다. 내용에는 관심없다. 거의 예수님, 부처님 수준이다. 다만 어떤 놈이 어떤 것 받아 본다고 했더라(sub) 하는 놓은 노트📝 한권 들고 있다.

누가 뭘 구독하고 있는지?

또 있다. sub하는 놈들이 여럿일 수 있으니

누가 지금 연결되어 있는지

주기적으로 체크✅도 한다. 변심하고 딴 맛집 간 놈 없는지...

어떤 놈은 가면 간다 말을 하기도 한다. 이걸 유식하게 LWT라 한다. 나중에 나온다.

글 쓰는 이가 그냥 설렁설렁 대충 주절거리는 것 같지만, 나름 깊은 뜻이 쪼금 있다.

여기까지 온다고 고생들 했다. 이제 코드로 함 만들어 보자. 그래도 명색이 프로_글래머💪인데.

client.js

const mqtt = require("mqtt");
const client = mqtt.connect("mqtt://localhost");

const user = { id: 'client1', pwd: 'pwd' };

client.on("connect", () => {
    client.subscribe("clients/client1");
    client.publish("server/login", JSON.stringify(user));
});

client.on("message", (topic, message) => {
    console.log(message.toString());
    client.end();
});

예외 처리 왜 안하냐구?

할 줄 몰라서 안한다고 생각하면, 당신은 천재다. 그런 거는 나중에 돈 받고 만들 때 하면 된다. 괜히 Code Reading만 어렵더라.

server.js

const mqtt = require("mqtt");
const server = mqtt.connect("mqtt://localhost");

server.on("connect", () => {
    server.subscribe("server/login");
});

server.on("message", (topic, message) => {
    let data = JSON.parse(message);
    let client_topic = 'clients/' + data.id;
    if (data.pwd === 'pwd') {
        let res = { msg: 'login ok' };
        server.publish(client_topic, JSON.stringify(res));
    } else {
        let res = { msg: 'login fail' };
        server.publish(client_topic, JSON.stringify(res));
    }
});

떡방이라고 했다가 혼났다. 부동산중계인

"MQTT" 로 구글링해보면 끝도 없이 나온다.

사실 끝은 있더라...😂

대부분 "MQTT는 무엇인가", "MQTT 작동원리", "MQTT 패킷 구조" 등 기초적인 원리를 설명하는 글이다. 예제도 MQTT 사이트에 있는 IoT 관련 내용으로 pub/sub 한번 해보는 내용이다.

그 글들을 무시하려는 것이 아니라, 이걸로 서비스를 만들려고 하면 좀 애매하다는거다. 그 막막함 나도 안다. 그래서 이 글을 연재하기로 마음먹었다.

나는 오래전부터 카카오톡 같은 채팅서버를 만들고 싶었다.

왜? 채팅이야말로, 모바일 앱의 기본 중 기본이라 생각했다.

자네는 뭘 개발하나? "네, 저는 웹 서비스 개발합니다" 그러면 게시판 정도는 눈 감고도 짜겠구만.

그렇다. 나에게 채팅 기능은 웹 개발자의 게시판이라 보면 된다.

처음에는 socket.io 로 만들었지만, 사이트에서 주는 예제를 넘어서기가 쉽지 않았다. 그리고 socket.io는 websocket이기에 최초 연결 시 무겁기도 하고, 스마트 폰에서 실행하기에는 많은 리소스를 사용한다. 심지어 먹통이 되기도 한다.

... 그래서 포기했다. 아니 "socket.io는 웹채팅에 양보하자" 라는 말로 정신승리했다. ...

그러다가 MQTT를 알게 되었다. MQTT는 IoT를 위해 만들어진 것이기에 채팅서버용 프로토콜로는 딱이라는 생각을 했다. 지하철이나 버스를 타고 이동 중, 하나의 AP에서 다음 AP로 넘어갈 때 연결성도 좋았다.

오호 이것 괜찮은데....

... 하지만 "늑대 피하려다 호랭이 만난다"는 속담처럼 이것도 쉽지 않았다. ...

그 호랭이를 어떻게 물리쳤는지(아니 구워 삶았는지)에 대한 글이다.

Mosquitto는 웹 서비스가 아니다.

우리가 익히 아는 Client/Server, 웹 서비스 이런게 아니다. 예를 들어 채팅하기 위해 로그인하다고 해보자.

Broker한데 _"로그인 처리 해줘"_하면 안된다.

얘는 말 그대로 중계자이다. 오른손을 받아 왼손으로 넘겨주는 놈이다. 여기서 첫번째 장애를 만났다.

... 로그인 처리해 줄 놈을 어떻게 만들지? ...

서비스가 대박나서, 사용자가 몰리면?

... 이런 문제는 그 때가서 돈 세면서 생각하면 된다. ...

채팅 사용자가 몇 명 안될 때는 큰 문제가 되지 않는다. 하지만 사용자가 엄청 많아졌을 때, 또는 특정 시간 때에 사용자가 몰리면 어떻게 할 것인가?

나의 메세지는 나만 봐야 하는데...

채널에 구독하기만 하면 다 볼 수 있는 환경에서, 내 메세지는 나에게만 전송되어야 한다.

안 그러면 쪽팔린다. 평생 들을 욕을 하루에 다 들을 수도 있다.

전송된 메세지는 저장해놔야지, 나중에 딴소리 안하지.

물론 만들어 달라는 분(돈 주는 사람일 가능성이 높으니까)의 고견에 따라 달라질 수 있다.

1번고객: 야...우리는 메세지를 DB에 저장할 필요 없어. 2번고객: 우리는 회사 서버에 저장해줘. 압색들어오면 싹 지워버리게. 3번고객: 뭐 중요한 것도 없고, 우린 그냥 클라우드 DB에 저장해줘.

돈🤑 주시는 분들은 보통 반말을 많이 사용하더라. ㅠㅠ

위의 경험을 공유해보려고 한다.

다음 정도는 알고 있어야 얻어 걸리는 것이 있을 것이다.

• MQTT를 아는 사람
• Node.js를 아는 사람
• MySQL을 아는 사람

기초적인 것은 여기 velog.io에도 많이 있으니, 여기선 다루지 않겠다.

tl;dr 댓글에 설치법 이런 것 물어보지 마시고...나도 구글링 함ㅠㅠ