Discord bot 만들기(3)의 문제점이 무엇인지 드디어 발견했다..
단순히 서버가 작동할 때 안쪽의 변수가 선언되지 않는다는 것(혹은 선언되어도 따로 저장소를 만들지 않았기 때문에, 메모리의 휘발성으로 인해 정보가 날라가는듯..)이었다. 그러니까 정보를 안전하게, 그리고 정확하게 저장하는 방법은 결국 저장소를 하나 만들어야 한다는 것이다..
따라서 현재로는 2가지 선택지가 존재한다(존재했다).
이 문제를 알게 된 이후 처음 생각한 방법은 자체적으로 폴더를 만들어서 제어를 하는 것이다. 이 경우 정말 이전 글에서 생각한대로 만들 수가 있지만, 되게 여러가지 문제가 존재하기 때문에 pass.(아래 조금 정리해본다.)
결과적으로 현재 사용하게 되는 가장 효율적인 방법은 DB를 사용하는 것이더라..(dbless는 추후 도전해봐야겠다..)
사실 사용하는 사람이 많지 않으면 큰 문제가 되지는 않을 것이다..
하지만 사용하는 사람이 충분히 많아졌다 가정해본다면 결과적으로 서버 하나가 자체적으로 처리해야 하는 작업들이 많아지기 때문에 API가 제대로 들어가지 않거나 충돌하는 등의 여러 문제가 발생할 가능성이 높다.
구체적으로 겪어보지는 않아서 자세하게 쓰지는 못하겠지만, 조언을 들었던 것을 통해 정리해보았을 때 다음과 같은 문제가 생길 것이라 예측해본다.
과도할 수 있는 응답 대기시간.
- 대부분의 작업을 코루틴으로 넘겨서 처리하기는 하지만 이는 대기시간을 넘기기 위한 수단일 뿐이고, 자체적으로 구상했던 서버에 정보를 저장하는 것은 결과적으로 스레드 선에서 해결이 되야 할 수 밖에 없지 싶다.. (구상 방식은 indexing
을 이용한 처리방식을 이었고, 때문에 각 index
를 확인하는 작업이 필요하다.) 이미 코루틴으로 실행된 작업이야 공부한 바에 따르면 문제가 생길 여지는 적을 것 같지만(서버가 터지지 않는이상..?..), 사용자가 많아졌을 때, 각 사용자의 알람이 있는지에 대한 index
확인이 상당히 문제가 될 것이다.
--> 예전에 겪었던 문제로부터 알게되었던 사실을 생각해보면, 디스코드봇 API의 경우 메인스레드에 10초단위의 대기시간에 따라 console에 경고를 날리고, 60초가 넘어갈 경우 어딘가에 있는 토큰이 만료가 되던데, 이거를 생각해보면 사용자가 충분히 많아져서 한가지 명령에 대해 60초 이상의 대기시간이 생길 경우 try-except
구문조차도 작동하지 않고, 결과적으로 사용자의 명령이 씹히게 되는 문제점이 발생할 것이다.
트랜잭션의 ACID중 Isolation에 대한 문제 혹은 lock에 대한 문제.(좀 더 공부해야 할 필요성이 느껴진다..)
사실 DB를 만들고, 제어/관리하는 것을 업으로 삼고 싶다면 자체 저장소를 만들어보는 것은 매우 좋은 방법일 것이다. 물론 좋은 경험이긴 하지만, 내 꿈과는 거리가 좀 떨어져있다는 것이 아쉬울 따름이다..(하루가 48시간이었으면 좋겠다.)
end