2022.12.26 리마스터 코강유틸 사이트 개발회고

Spring Boot, Vue를 사용해서 Node.js로 만들었던 사이트를 리팩토링하였다.

그냥 백엔드, 프론트 기능 프로젝트 두개로 돌아가는 사이트까지 생각했었는데 내가 가지고 있는 자원을 전부 알차게 써보고 싶었고 Nginx, Mysql, Docker 독학해서 서비스에 적용해 보았다.

 

과거에는 서버가 응답이 없으면 AWS자체 기능으로 재부팅 후 crontab 명령어로 살리는 식으로 만들었지만

도커를 사용하니 메모리 문제에 의한 AWS서버문제는 발생하지 않을거라 믿는다.(?)

도커 컨테이너 하나가 다운된다 하더라도 restart할 것이고 서버에 문제가 생기는 경우는 없겠지?

 

사람들에게 실제로 배포하니 일반 프로젝트와는 다른점이 많았다.

생각치도 못한 부분에서 문제가 발생했고 한가지 문제를 제외하면 전부 해결된 것으로 보인다.

 

개발하면서 동시에 겪은 문제와 해결방법들은 공책에 끄적여놨는데 여유가 생기면 블로그에 잘 정리해두고 싶다.

메모리가 더 필요해서 Swap 생성, 서버내의 UTF-8 문제, amd64 와 arm64의 호환성 문제 등

기능 개발이 끝난 후 실제로 배포하는 과정에서 겪은 문제들이 훨씬 까다롭게 다가왔었다.

이러한 경험들을 잘 기억해두고 더 나은 프로젝트를 할 수 있게 되고싶다.

 

 

아직 해결하지 못한 문제

메이플 코어강화 매커니즘에 따라 사용할 코어 수가 클수록 필요한 연산량이 기하급수적으로 높아진다.

캡틴, 카데나 같은 경우 다른 직업에 비해서 복잡도는 거의 100배는 더 많은 시간이 걸릴 것으로 예상한다.

이미 많은 코어가 필요하다는 것을 알고 엄청나게 많이 소지한 상태로 7~8코어 칸을 요청하니 백엔드 내에서 처리하게 만들어도 메모리 문제가 발생할 것으로 생각한다. 

조합, DFS방법과 해쉬맵 방식을 사용해서 불필요한 연산을 줄였다고 생각했고 깊이가 8아래로는 내려가지 않기 때문에 메모리부족이 일어나지 않을거라 생각했는데 가뿐하게 사이트가 죽는 것을보고 확실히 개선할 필요가 있어보였다.

 

지금 생각해둔 방법은 재귀를 사용해서 DFS를 구현하는게 아닌 연산량은 있어도 특정 변수들만 선언하고 재활용하는 식으로 메모리를 적게쓰는 방법으로 바꿔야 한다. 그리고 중첩 수 뿐만 아니라 불필요한 스킬 사용횟수까지 카운트하여 조건을 충족할 수 있는지 판단할 수 있을 거라 생각했다. (주말의 내가 잘 만들어 줄 것이다 ^^b)

---