"냠" 아 이제는 "마이무라" 유저 160명 돌파 그치만 서버가..

- 대학생 스타트업 동아리에서 만든 어플리케이션 냠의 회원 가입자수가 168명을 찍었다.

2월 18일 회원가입자 수 200명을 넘었다 ~

3월 5일 회원 가입자 수  280 명이다

 

물론 DAU 를 정의 하지 않고는 의미 가 없는 숫 자라고 할 수는 있지만, 작년 겨울에 시작한 개발이 실제 사용자가 다운로드 받을 수 있다라는 정도의 레벨이 올랐다는것이 감회가 새롭다.

 

----------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------------------------

 

다들 너무 고맙다

 

 

지금은 새학기 시작이며 새내기 분들의 유입이 거의 절대적으로 높은 시기 이기 때문에 이러한 증가 폭이 언제까지 유지가 될지는 모르겠지만 난 언제나 마케팅 기획 팀을 믿겠다.

 

추가로 설명을 하자고 하면,  스타트업 동아리 팀의 앱이고 벡엔드 개발자이자 데브옵스는 나 한명이며 기술 욕심은 항상 나지만 공부할 시간과 기능을 구현할시간 코드, 시스템 , 다른 팀의 작업 방식 모든 설계를 고민하는시간 항상 시간과 사투를 벌이고 있다.

 

감상은 여기 까지 하고 지난 24시간 동안 있었던 일을 말한다.

크게 보면 다음 3가지가 있다.

 

1. 프로세스 전부 죽음

 

2. 재시동후 1시간 뒤 프로세스 중지

 

3. 웹사이트 빌드에서 오는 두려움

 

1.프로세스자 전부 죽은 경우에 대하여

 

AWS 인스턴스를 보면 사용자가 보험용으로 인스턴스 스냅샷를 만드는 기능이 있다. 이는 도커의 이미지와 같이 이후의 인스턴스를 추가로 할당받을때 스냅샷을 불러와 저장한 시점의 환경을 그대로 재시동 할 수 있다 라고 한다.

 

이 이야기를 왜 할까 , 지난 1월 앱을 처음으로 출시 하기 직전 실수로 인스턴스를 종료 하는(Teminate 이라 하면 안 눌렀을) 일이 발생했던것을 기억하여 이전과 같은 일을 막고자 유저수가 20명에서 순식간에 100명이 넘어갈때

AWS 인스턴스 스냅샷을 저장했다. 저장하고 직후 , 앱 팀원의 전화로 서버를 확인하니 당시 pm2 list 에 보여야 할 프로세스 3개중 단 1개도 보이지가 않았다.    확인 직후 바로 다시 서버를 올리고 로그를 보면서 원인을 파악 하고자 했다.

 

(위의 상황에 대하여 원인을 파악 할겸 따로 검색들과 더불어 추가 적으로 직접 실험을 해봐야 할 듯한데 시간적 금전적인 비용이 부담이 되는 건 사실이다..현식적인 문제의 직면).

 

AWS 인스턴스 스냅샷을 만들었을때 문제가 발생했다고 파악하는 이유는 다음과 같다.

 

1. 트래픽이 몰리지는 않았다 - 로그기록을 보면 개발중에 사용했던 트랙픽 정도의 호출기록들이 존재한다.

 

2. 이전에는 pm2 를 사용하여 서버를 싱행을 하면 pm2 save 를 묻는 질문이 없었는데 pm2 save 커맨드를 추천하기 시작했다,, 그것도 갑자기

 

3. 이전 몽고디비를 서버프로세스를 실행하는 컴퓨터와 함깨 설치하고 운영했을때와는 다르게 인스턴스는 정상적으로 접속이 되고 각종 커맨드가 작동을 하니 메모리적인 측면에서 오류가 발생한것 같지는 않는다.

 

4. df -h 로 서버가 실행되고 있는 저장 공간은 50 프로 넘게 남은 것을 확인했다.

 

5. 사용하는 aws  는 t2 미디엄 30GB 이며,  nginx 와 웹사이트 next.js 프로세스 1개 , 운영중인 서버 1개, 개발 서버 1개가 실행 중이었다. -> cpu 코어 에 맞는 프로세스수인 것으로 알았지만 다시 조사해야겠다.

 

- Nginx 의 오류 인지도 확인을 해봐야할듯 하다 , 프로세스가 전부 죽는 케이스를 한번 경험을 한 직후 하나의 컴퓨터의 여러 포트를 열고 nginx 를 활용한 프록시를 설정하는것이 완벽한것은 아니라는걸 느꼈다.

 

2.재시동후 1시간 뒤 프로세스 중지

- 프로세스가 전부 죽은 직후 운영을 위하여 재빠르게 다시 운영중인 앱에 맞는 서버 1개만 올렸지만

이도 갑자기 중지가 되었다.

pm2 list 를 보면 pid 는 살아있었던것이 1번에서 경험한 모든 프로세스가 죽은 상황과는 달랐다.

 

 

3. 웹사이트 빌드에서 오는 두려움

연달아 2번의 서버가 죽는 경험을 통해 하나의 인스턴스에서 서버 프로세스가 동작중일때 , 추가 적으로 next.js 를 빌드하고 배포 하는것이

얼만큼의 메모리나 cpu 에 용량을 차지하는지 모르니 배포를 하기가 꺼려졌고.

 

지금은 추가 적인 t2 small 인스턴스를 할당을 받아  두개의 인스턴를 하나의 vpc 에 넣고 프라이빗 ip를 통해 nginx 로 리다이렉션을 하는 방식을 구축하고 있다.

 

 

 

 

결론 : 모르면 맞는다 + cs 지식이 탄탄 해야한다.