inSplace.
날씨, 인원수, 성별에 따라 서울 내 장소를 추천해주는 웹 어플리케이션.
이번 1주일 동안의 진행점.
BackEnd의 API를 모두 구현했다.
BackEnd에 Reverse Proxy를 구현했다.
code-deploy, pipe-line을 이용하여 CI, CD를 구현했다.
스케쥴러를 이용하여 특정 시간마다 날씨 API를 가져와서 업데이트 해주는 기능을 구현했다.
Reverse Proxy를 구현한 이유
Load Balancing: 서버의 부하를 줄이기 위해 사용했다.
SSL: 현재 위치를 가져오려면 HTTPS가 필수적인데 이를 적용하기 위해서는 SSL이 필요했다. 처음에 AWS의 elb SSL을 적용시키려 했지만 SSL이 인증되지 않았다는 오류가 자꾸 떠서 ngnix에 let's encrypt의 SSL을 적용시켰다.
Security: 내부망으로 향하는 모둔 요청을 차단함으로써, 내부망의 신원이나 보안 공격에 대한 추가적인 방어역할을 할 수 있다.
캐싱: ngnix에 정보들을 캐싱하여 보다 빠른 웹을 만들 수 있다.
이번 주 어려웠던 점.
ngnix의 설정이 어려웠다.
Reverse Proxy의 개념과 HTTPS를 잘 알지 못한 상태였기 때문에 얼마나 중요한지도 몰랐고 때문에 적용시켜야하는 이유도 잘 몰랐다.
스케쥴링을 이용한 날씨 API가져와서 데이터 베이스에 저장하기
일정 시간마다 날씨 API를 가져와서 데이터베이스에 넣어주는 작업을 등록해놨는데 일정 횟수동안만 실행되고 나머지는 데이터베이스의 접속이 되지 않았다.
어떻게 해결했는가?
-
elb SSL의 적용이 실패했고 알수없는 에러가 자꾸 뜨자 차선책으로 서버 자체에 ngnix를 사용하여 Reverse Proxy를 두기로 했다. ngnix를 이용하다 보니 더 좋은점이 있었다.
첫째: 무료다.(강점)
둘째: 설정이 간편하다.(certbot을 사용하면 설정이 자동으로 된다)
셋째: 정적파일을 제공하는 것은 서버보다 빠르다. -
스케쥴링에서 일정 횟수가 지나고 데이터베이스에 접속이 되지 않는 현상은 connection관리가 제대로 되지 않았기 때문이다. 코드상에서 pool.getConnection을 사용하여 pool을 가져오고 로직을 처리한 후 pool.release()를 해야하는데 하지 않았고 때문에 한정된 connection을 일정 시간마다 계속 가져오는 현상이 발생했다. 때문에 데이터베이스의 접속이 제한된 것이었다.
-
CI/CD 프로그램 후보로 Jenkins, GitAction, code-deploy가 있었다.
우리는 code-deploy를 사용하여 CI/CD를 구현하였는데 그 이유는 우리의 서버가 ec2고 이에 가장 최적화된것이 같은 AWS에서 만든 code-deploy와 pipe-line이라고 생각했기 때문이다.
