🎬 서론
현재 활동중인 한국대학생IT경영학회(KUSITMS)에서는 12월 7일(토)에 제 2회 전시회를 진행한다.
전시회는 각 팀에서 열심히 만들어 낸 프로덕트를 외부에 공개하는 첫 자리로,
29기에 이어서 이번에도 감사하게 아산나눔재단의 지원을 받아 진행할 수 있게 되었다.
나는 전시회를 기획 및 운영하는 전시 TF 팀에서 기획총괄팀을 맡아서 커뮤니케이션 & 후원사 및 기업 부스 컨택 등을 진행했고, 전시회 홍보 및 아카이빙 목적의 전시 웹사이트 제작을 백엔드 파트로 참여했다!
웹사이트 개발 및 전시회에 대한 회고는 추후 글을 따로 적어보려고 한다!
🚨 문제 발생
그럼 이 글은 왜 적게 되었는지..에 대해서 이제 말해보려고 한다.
밋업 프로젝트와 다른 서비스들도 개발을 하고 있기에, 전시 웹사이트 제작에 많은 시간을 쏟을 수는 없었다.
때문에 약 3일 정도를 집중해서 API 개발 및 배포를 끝낼 수 있었고 큰 문제가 없어 11월 25일 (월)에 1차 배포를 성공적으로 진행했다!
API 연동을 한 방명록과 People 섹션도 문제 없이 나오는 것을 확인했다.
그렇게 이제 밋업 프로젝트 개발 마감이 얼마 남지 않아 집중하고 있던 도중..
큐시즘 회장단 톡방에서 아래와 같은 카톡을 받았다.
하필 이때는 밋업 프로젝트 개발 마감 1시간 전이었고...집에 가던 중이어서 바로 확인도 할 수가 없었다 🤯🤯
우선은 집에 도착해 무사히 개발 코드 제출을 완료하고, 천천히 문제가 무엇인지 파악해보기 시작했다.
🤔 대체 왜..?
임시적인 문제 해결
단기적인 프로젝트이고 비용을 아끼기 위해서 GCP의 3달 무료 크레딧을 사용하여 DB 구축 및 배포를 진행했다. 그래서 Cloud SQL이라는 서비스를 통해서 DB를 만들어서 사용중인 상태이다.
하지만 확인해 보니 내가 만들어두었던 인스턴스 내의 DB 자체가 삭제되어있었다..❗️❗️
사실 배포를 하기 이전에도 이러한 일이 있었다.
개발 초기에는 매일 같이 DB가 스스로 삭제가 되었는데..처음에는 대수롭지 않게 생각을 했다가 문제가 반복되자 다른 프로젝트와 설정값이 다른 게 있는지 비교를 했었다.
인스턴스 사용자를 따로 만들지 않았다는 점이 그 차이였고, 이를 추가해준 후로 지금까지는 문제가 발생하지 않았다. 하지만 근본적인 문제를 해결한 것이 아니었고...배포까지 한 지금 이 시점에서는 무조건 문제를 찾아내야했다.
너무 부족한 정보
하지만 아무리 구글링을 하고 GPT와 대화를 해 보아도 나와 같은 문제를 겪은 사람들을 찾을 수가 없었다.
사이드 프로젝트로 만들어 운영중인 OneTime 서비스 역시 아직까지는 GCP 무료 크레딧을 사용하고 있는데, 여기서는 그러한 문제가 한 번도 발생하지 않아 더욱 미칠 노릇이었다 😇
지금까지 GCP를 사용해서 4번의 프로젝트를 진행했었는데, 이번에만 문제가 발생하니 정말 원인을 찾기가 어려웠다.
https://hyun083.tistory.com/14
그러던 중 동일한 문제가 발생한다는 위 글을 겨우 찾아서 볼 수 있었다.
하지만 여기서는 랜섬웨어에 의한 문제였고, 내 DB에서 로그를 살펴본 결과 이러한 부분은 찾을 수 없어서 다른 방법으로 해결해야겠다고 생각이 들었다.
✅ 문제 해결
로그를 보자
위의 글을 읽은 후로, 로그를 샅샅이 찾아봐야겠다라는 생각이 들었다.
GCP 콘솔에 들어간 후, 하단 MySQL 오류 로그 보기에 들어갔다.
들어가서 에러 로그들을 하나씩 파악하며 어떤 문제들이 있었는지 확인해보았다.
그러던 중, 위와 같은 에러 로그가 반복됨을 볼 수 있었다.
이전에 DB가 매일 같이 사라질 때에도 동일한 로그가 남아있던 것을 보아,
이 부분이 문제다라는 확신을 하게 되었다.
블로그 서칭
[Warning] [MY-010909] [Server] /usr/sbin/mysqld: Forcing close of thread 9 user: 'root'.위의 로그를 기반으로 구글링을 다시 하기 시작했다.
그 결과 아래 3개의 글을 찾아볼 수 있었다.
가장 최신 글이 2017년이다...찾기 정말 쉽지 않았다 🥲
세 글 모두 문제의 원인과 해결방법은 동일했다.
Forcing close of thread
MySQL 서버가 클라이언트 연결을 강제로 종료하면서 발생한 로그이며, 여러 이유가 있을 수 있다.
여기서는 DNS 역질의로 인해 MySQL 연결 확인 과정에서 지연이 발생한 것이 문제이다.
DNS 역질의(reverse DNS lookup)
클라이언트가 MySQL에 연결할 때, 서버는 클라이언트의 IP 주소를 호스트 이름으로 변환하려고 시도한다.
만약 DNS 서버가 느리거나 응답하지 않을 경우, MySQL의 연결 관리가 지연되면서 시스템이 불안정해질 수 있다.
이러한 장애가 반복되니, GCP Cloud SQL 인스턴스 측에서 문제의 DB와 사용자를 아예 제거해버린 것으로 예측된다.
해결 시도1 : 설정 추가
이는 엄밀히 말하면 MySQL의 문제는 아니고, DNS 서버의 불안정성 때문이라고 한다.
때문에 my.cnf 파일에 설정을 하나 추가하며 문제를 해결할 수 있다.
Cloud SQL에서 my.cnf 파일을 설정하기 위해서는 위의 데이터베이스 플래그를 지정해주면 된다. 이는 인스턴스 수정 -> 아래로 스크롤 하면 찾을 수 있다.
그런데...
위와 같이 플래그에서 skip_name_resolve를 찾으려 했으나 나오지가 않았다 🤣
그래서 찾아보니 Cloud SQL에서는 기본적으로 skip_name_resolve 설정이 되어 있다고 한다. 실제로 확인을 해 보니 설정이 ON으로 되어 있는 것도 확인할 수가 있었다.
결국 이렇게 문제는 다시 미궁 속으로 빠지게 되었다..👻
해결 시도2 : 허용 네트워크 지정
https://blog.naver.com/paradox1573/40126432937
그러다가 위의 무려 2011년 글에서.. hosts에 hostname과 IP를 넣어주어 해결했다는 것을 볼 수 있었다.
나는 hosts 파일에 추가하지는 않았고, 아래와 같이 허용 네트워크와 사용자의 호스트를 각각 지정해주었다. 기존에는 모든 네트워크에서 허용되어있었기 때문에...이 부분에서 보안 문제가 발생했을 수 있을 것 같다 🥲
기존에 모든 IP에서 접속할 수 있던 kusitms이라는 사용자를 제거하고,
지정된 IP에서만 접근 가능한 사용자들을 각각 만들어주었다.
이렇게만 하면 외부 접근이 불가하기에, 위와 같이 허용 IP들을 추가해주어서 접근할 수 있도록 해주었다.
최종적으로 각 환경에서 환경변수들을 수정해주면서 마무리하였다.
다행히 지금까지는 문제가 없는 것 같다...또 언제 문제가 발생할지 모르기 때문에 수시로 로그를 확인하며 상태를 점검해야할 것 같다 😂
(제발)
💡 느낀 점 & 배운 점
-
보안 공부가 필요하다고 느끼는 시점이었는데 이렇게 문제가 발생하니 더더욱 그렇게 느껴진다. 이번 일을 계기로 보안과 네트워크에 더욱 많은 관심과 학습을 진행해야겠다.
-
글을 찾기가 매우 어려웠지만.. 그래도 몇 개 있는 글들로 인해서 나름 문제를 해결해 볼 수 있었다. 기본적으로는 나를 위해서 기록하는 것이지만, 이렇게 다른 개발자들에게도 큰 도움을 줄 수 있는 것 같다. 앞으로도 트러블 슈팅을 한 후에는 그냥 넘어가지 말고 꼭 기록하는 습관을 가져야겠다!
