팀 피클에서는 인공지능을 사용한 프로젝트를 생각중이에요.
많은 관심 부탁드릴게요 :)

MSA로 Discord 봇 구축하기 - 로드밸런싱 보러가기

MSA를 적용해야겠다! 결심한게 인공지능 프로젝트를 고려하면서 였어요. 이왕 MSA를 적용하는 김에 로드밸런싱을 디스코드 봇 서버에 적용시키는 방법도 익혀서 봇의 사용률에 맞춰 스케일 업을 하면 좋겠다고 생각했어요.

저희 팀도 초창기에는 어쩔 수 없이(?) 여러대의 서버를 써서 로드 밸런싱을 했었어요. (관련된 글도 준비중이에요 😄)

그리고 원래 상태로 돌아왔다가 알 수 없는 이유로 인해서 메시지 응답이 느려지게 되자, 현재도 여러개의 서버에 분리해서 서버를 운영하고 있어요.

일단 제일 중요하게 생각해야 했던게 “가용성” 이었어요. 서버가 재해로 인해서 꺼지더라도 서비스는 계속 돌아가야 한다는게 저희의 생각이었죠. 지금까지 서비스를 운영해오면서 다양한 재해 상황, 예기치 못한 상황들이 있었어요. 가장 많이 발생하는 이슈가 서버의 저장공간이 없어서 봇도 같이 죽는 것이었어요. 봇 뿐만아니라 DB도 같은 서버에서 운영중이기에 결국 같이 돌연사(?)를 했죠 😢
저번 포스트에서 중요하게 다룬 문제가 업데이트를 할 때 downtime이 발생하는 것이었어요. 이 문제도 가용성과 관련이 있죠.

그럼 가용성을 올리기 위해서는 어떻게 해야할까요?
로드 밸런싱을 사용하면 어떨까요?
그렇게 한다면 재해 상황이 생기더라도 남은 서버들이 동작을 이어 나가면 좋을 것이고, 업데이트 할 때도 downtime을 막을 수 있겠네요!

그럼 이제 디스코드에도 로드 밸런싱을 적용해야 하는데 로드 밸런싱을 적용한다는게 만만치 않았어요.
디스코드 봇의 구조 때문인데요, 디스코드 봇의 구조는 이렇게 돼요.

[그림 1]

유저가 디스코드에 메시지를 보내면 디스코드 서버는 봇 서버에게 메시지가 왔다는 이벤트를 보내고, 다시 봇 서버가 디스코드에 메시지를 보내면 디스코드 서버는 유저에게 메시지가 왔다는 이벤트를 보내는 방식이에요.

이때 길드 수(서버 수)가 점점 늘어나서 일정수가 되면 서버 하나로는 버틸 수가 없는 상태가 돼요. 이를 디스코드에서는 sharding이라고 불러요. 그러면 [그림 2]처럼 봇 서버가 여러개가 돼요.

[그림 2]

사실 봇 서버가 여러개가 되는건 아니고, 하나의 서버에서 돌아가지만 실행할 때 여러개의 샤드가 한 프로그램에서 작동해요.

어? 그러면 가용성을 늘리기 위해서는 이런 서버 수를 늘리면 되겠네요??
그럼 한번 늘려볼까요?

[그림 3]

짠! 같은 기능을 하는 서버를 세대로 늘렸어요. (방금 설명했다시피 모든 샤드는 같은 서버에서 돌아간다고 가정할게요)

엇 그런데 이렇게 되면 메시지 전송한 결과는 봇 서버0, 1, 2 모두에게 전달 되겠네요? 그러면 유저는 !도움 명령어를 한번 입력했을 뿐인데 세개의 서버가 너도나도 그 메시지에 응답하고자 할거에요.

분명 가용성이 늘어난 것은 맞는데 이렇게 되면 안 되겠죠?

앞서 웹서버를 가지고 무중단 배포를 할 때 중간에 로드 밸런서를 두었던 것처럼 디스코드 봇으로도 그렇게 하면 될거에요.

[그림 4]

메시지 수신용 봇 서버가 따로 존재하고 명령어 봇 서버를 따로따로 배치하면 아주 쉽게 해결이 될 것 같네요! 그리고 명령어 봇 서버들을 이제 클라우드 기술과 엮어서 가용성을 더 높일 수 있을 것 같아요.

[그림 5]

아주 짧은 실행시간으로 실행되는 명령어라면 FaaS인 AWS Lambda를 사용하고, 조금 실행에 시간이 걸리는 경우라면 Amazon EC2를 사용할 수 있을 것 같네요.

그리고 이렇게 서비스들을 쪼개놓으면 대시보드를 만들었을 때 봇 서비스에 보다 쉽게 접근 가능할 것 같아요.

[그림 6]

하지만 여기에는 고려하지 못한 상황들이 몇가지 있답니다. 다음 글에서 그 이야기를 한번 풀어볼게요!


CraftyDragon678's profile
CraftyDragon678
보안과 인공지능에 관심이 많은 개발자입니다.