django + mysql + AWS 로 쇼핑 정보 가져오는 게시판 만들기 (Daeran.net) (2)

1부에서 계속    1부 보기

django + mysql + AWS 로 쇼핑 정보 가져오는 게시판 만들기 (Daeran.net) (1)

 

6. 구현 결과

 

 

지금까지의 과정까지 구현된 것들은 다음과 같다.

 

 

 

 

대문 페이지에서 Daeran.net에서 올라온 모든 글들 중 최신 순으로 10개를 보여준다.

 

카테고리 별로 색이 들어간 뱃지를 사용해 구분이 용이하게 했다. Bootstrap4을 사용해 페이지를 꾸몄다. 

 

 

 

 

게시판 리스트 페이지에서 크롤러가 db에 저장한 데이터를 보여준다.

 

현재는 루리웹과 뽐뿌, 클리앙에서 가져온 정보를 가져오고 있기 때문에, 카테고리도 이 3가지로 나누어져 있다.

 

그 외에 자유게시판과 공지 게시판도 만들었다.

 

 

 

 

 

게시물 작성 페이지에서는 제목과 내용, 이미지를 첨부할 수 있게 했다.

 

1부에서 언급한 Linebreak 기능을 통해 내용 폼에 적은 내용들은 작성하고 나서도 개행이 적용되어 보인다.

 

내용이나 제목이 없이 작성 버튼을 누르면 경고창과 함께 진행되지 못하게 했다.

 

이미지 파일은 날짜 별로 저장해 AWS S3에 저장된다.

 

 

 

 

최종적으로 완성된 클라우드 아키텍쳐, Elastic beanstalk를 통해 편리하게 배포할 수 있었다.

 

EB를 중심으로 RDS와 S3, Lambda를 연결해 전체 기능들이 모두 클라우드 환경 위에서 동작하게 된다.

 

 

 

7. 후기

 

 

웹을 만든 뒤 작성자는 이 사이트를 유용하게 이용하고 있다. 더 큰 바람이 있다면 이 사이트를 아는 사람이 많아져 

 

나와 같은 고민을 했던 사람들에게 큰 도움을 주고 싶다는 것이다. 사실 SEO에 잘 걸리기 위해 SPA 형식을 취하지 않은 것도 있다.

 

검색 엔진에 걸려야 유입이 잘 될테니까.

 

아쉬운 점이 있다면 핸드폰이나 태블릿같은 작은 화면으로 봤을 때 편리하지 않다는 점이었다.

 

bootstrap같은 반응형 구조를 구현할 수 있는 프레임워크를 사용했음에도 반응형으로 구현하지 않은 탓에 일어난 결과이다.

 

차후에 수정하도록 해야겠다.

 

 

 

 

 

8. 이슈 해결

 

웹 애플리케이션을 배포하고 난 뒤, 두가지 이슈가 발생했다. 

 

첫번째 이슈는 깃허브에 코드를 커밋해서 일어난 이슈이다. 코드를 커밋하면서 AWS Secret 키를 그대로 올려버린 것.

 

때문에 퍼블릭 상태인 내 깃 허브 리포지토리에 시크릿 키가 적나라하게 올라가게 되었다. 

 

이 이슈는 AWS에서 보낸 메일을 통해 발견하게 되었다.

 

AWS에서 보안 이슈가 발견되었다며 메일이 도착했길래 봤더니 깃 허브에 시크릿 키가 올라와 있다며 경고한다는 내용이었다.

 

AWS에 경의를 표하게 되는 순간이었다. 이 메일을 받은 뒤 바로 시크릿 키가 있는 부분을 **처리하고 AWS가 안내한 대로 기존에 사용하던 키를 삭제하고 새 키로 Rotate했다. 

 

자칫하면 누군가가 내 AWS 서비스를 함부로 이용할 수도 있었던 아찔한 사건이었다. 특히 사용할수록 요금이 부과되는 민감한 문제이기 때문에 중요한 이슈였던 셈이다.

 

위는 보안 이슈 발생 당시 AWS에서 경고를 띄운 Event log이다. 이런 식으로 AWS는 문제가 발생할 경우 Event log를 통해 해당 문제를 알려준다.

 

앞으로 코드를 커밋할 때 시크릿 키는 지우고 올려야 함을 유의해야 겠다.

 

두번째 이슈도 AWS에 관련된 것으로 EC2 프리티어 사용량이 끝나 내 Daeran.net의 EC2를 잠시 중지하려고 해서 일어난 문제이다.

 

Elastic beanstalk의 Ec2는 스팟 인스턴스로 중지가 되지 않고 종료(terminate)만 가능하다.

 

이점을 몰랐던 나는 Ec2를 잠시 중지하기 위해 중지 버튼을 눌렀다.

 

Ec2는 중지 상태가 아닌 terminated 상태로 진입해 버렸고, 내가 deploy했던 어플리케이션이 삭제되는 불상사가 일어났다.

 

때문에 새 Ec2에 다시 어플리케이션을 deploy했어야 했다. security group과 load balancer 옵션도 일부 수정해야 했다.

 

만일 내가 Ec2의 EBS를 미리 스냅샷 복사해놨더라면 다시 배치할 필요 없이 저장된 스냅샷을 쓰면 될 일이었다.

 

이 이슈를 해결하고 난 뒤 나는 즉시 해당 EBS의 스냅샷을 찍어놨다. 백업의 중요성을 실감하게 된 순간이었다.

 

 

 

위는 스냅샷을 생성하고 난 뒤의 상태이다. AWS에서는 Ec2의 저장장치로 EBS(Elastic Block Storage)를 제공한다.

 

EBS는 데이터를 영구적으로 보존하지 못한다는 특징이 있기 때문에 불상사가 일어날 때를 대비해서 스냅샷 기능을 이용해야 한다. 

 

원하는 EBS의 스냅샷을 생성하면 해당 EBS의 데이터를 그대로 저장할 수 있다. 

 

스냅샷의 Life Cycle Management를 통해 스냅샷의 자동 생성 및 삭제도 할 수 있기 때문에 유용하게 쓸 수 있다.