Skip to content

Trouble Shooting

김형진 edited this page Feb 11, 2022 · 27 revisions

1. 이미지 파일 처리 문제

개발 초기에는 애플리케이션 서버인 EC2에 이미지 파일을 저장 후 해당 경로를 DB에 저장했다.
그 결과, 이미지 파일은 용량이 커서 서버에 부담이 되었고 불필요한 Auto Scaling 또는 Load Balancing 작업을 야기했다.
그래서 이미지 파일 저장을 위한 별도의 서버를 구성하기로 하였고, 파일 저장에 최적화된 AWS S3 버킷에 저장하였다.
그 후, 기존 사진이 S3 서버에 남아있어 불필요하게 용량을 차지하는 문제를 인지하였다.
이를 해결하기 위해 업로드 시 S3의 기존 파일을 삭제하여 불필요한 이미지를 최소화하였다.

자료) 이미지 삭제 로직

이미지 삭제 로직



2. 보안적인 부분에 대한 이슈 및 해결

실전프로젝트를 진행하면서 서버 보안에 대해서 많은 고민을 하였습니다.
그 중 브라우저에 대한 보안과 내부서버의 접근에 대한 두 가지의 보안문제를 해결하기 위해 노력했습니다.
HTTP 프로토콜은 서버에서 브라우저로 데이터를 전송할 때 데이터가 암호화되지 않아 데이터를 쉽게 도난당할 수 있는 보안적인 이슈가 있을 것이라 생각했습니다.
또한 내부 어플리케이션 서버 정보가 외부에 노출될 수도 있을 문제에 대해서도 생각했습니다.
첫번째로 AWS ELB를 활용해서 HTTPS 적용하여 데이터의 보안 문제를 해결하였습니다.
두번째로 Nginx로 리버스 프록시 서버를 둠으로 내부 서버 접근에 대한 보안에 안정성을 높혔습니다.

자료) nginx.conf 설정

Nginx img3



3. 악의적인 외부 트래픽 차단

rate limiting을 사용하는 이유는 다음과 같습니다.

• Security : 동일 ip에 대한 반복적인 incoming connection을 제한해 brute force attack과 같은 공격을 방지 할 수 있습니다.
• Shaping : server에 접근가능한 user를 restrict해 service의 priority를 관리할 수 있습니다.
• Reliability : traffic spike를 방지해 server를 more reliable하게 관리할 수 있습니다.

nginx에서 지원하는 limit_req 모듈을 사용하면, 동일한 IP 에서 과도한 요청이 유입될 때, 이를 제한할 수 있다.
요청에 대하여 관리할 수 있는데 우리가 100r/s 로 rate를 설정했다고 치면 1초에 100개 요청만 받는다는 말입니다.
만약 test를 위해서 1000개의 요청을 날렸다고 하면 제일 먼저 온 100개 요청 외에 다른 900개의 요청은 503 에러코드와 함께 즉시 reject 됩니다.
우리는 429 code를 적용하였습니다. 429 error code : Too Many Requests

그리고 rate limiting에 burst를 적용하였습니다.
burst를 적용하면, rate limiting을 초과하는 connection을 즉시 reject하지 않고 wait하게 만들 수 있습니다.
예를 들어 위사진, 아래 사진과 같이 burst 5를 정의하면, 100r/s를 초과하는 나머지 5 connection은 즉시 reject 되지 않고 해당 connection이 수행될 수 있을때까지 대기하게 됩니다.

limit_req_zone $binary_remote_addr zone=name:10m rate=100r/s;(10m : 160,000 ip주소 저장가능, 100r/s : 초당 100 request)

nginx limit req

참고 :
https://findstar.pe.kr/2018/06/24/nginx-rate-limiting/
https://minholee93.tistory.com/entry/Nginx-Rate-Limiting
https://semode.tistory.com/220
https://bactoria.github.io/2020/01/19/Nginx%EC%9D%98-limit_req-%EB%AA%A8%EB%93%88-%EC%82%AC%EC%9A%A9%EA%B8%B0/

일차적으로 인증된 사용자 (토큰을 발급받은 사용자) 만 API를 사용할 수 있게 필터를 두더라도, 인증된 사용자가 과도한 API 사용을 하게 되면 API 서버에 무리가 갈 수 있다.
따라서 일정 시간 내에 API를 사용할 수 있는 횟수를 제한하여 서버의 트래픽을 줄이는 것이 좋다.
그래서 우리는 nginx limit_req에 추가적으로 express에 요청되는 콜의 숫자를 제한하고자 한다.
Express용 기본 속도 제한 미들웨어인 express-rate-limit을 사용한다.
우리는 1초에 15회로 제한하였다.
추후 nginx limit_req와 맞추면 좋을 것으로 생각된다.
expressratelimit


참고:
https://www.npmjs.com/package/express-rate-limit
https://lab.cliel.com/entry/nodejs-express-rate-limitDOS%EA%B3%B5%EA%B2%A9-%EB%B0%A9%EC%96%B4%ED%95%98%EA%B8%B0
https://velog.io/@new_wisdom/Node.js-13-API-%EC%82%AC%EC%9A%A9%EB%9F%89-%EC%A0%9C%ED%95%9C-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0
https://lgphone.tistory.com/98