[AWS][24/365 장애 없는 서비스 환경]을 위한 캐밋의 로드맵

 

가자!

 

중앙대학교 관심사 기반 커뮤니티 '캐밋' 서버를 구축함에 있어서 두 가지에 대해 정리할 것이다.

1. 그동안 불편했던 점
2. 24/365 서비스를 위한 개선방향

---

[ 현재 상황 ]

서버 : AWS EC2 1대 (도메인 : cameet.site/)

DB : sqlite ( 특이점 : django 내장 DB)

 

[ 문제가 뭐야? ]

① 로컬에서 작업하던 코드를 배포서버에 맞게 수정 후 올리고 난 후 문제 발생

→ 배포 환경에서는 기능이 작동하지만, 새로운 기능을 만들거나 기존의 코드를 수정해야 하는 상황에 있어서 로컬 환경에서 테스트가 성립하지 않았다. (ex - 소셜 로그인 base_url 설정 상이, 로컬 db와 배포서버 갖고 있는 db값이 다름)

→ 매번 1. 로컬에서 코드를 작성하고, 2. 배포서버에 반영 후, 3. 실서버에서 테스트를 해야 했음.

→ 실제 사용자들이 사용하는 서버에서 테스트를 하는 건 말이 안 됨.

② 로컬에서의 DB와 배포서버에서의 DB가 다름

API 명세서를 통한 프론트 쪽에서의 수정 요청을 받고 수정을 하는 상황 (프론트 개발자분들은 배포서버를 기반으로 개발하는 상황),

→ 소셜로그인 후 발급되는 토큰은 로컬 서버에 등록이 되어있지 않아 특정 상황(사실 거의 대부분)을 테스트하는데 어려움이 있었음.

→내장 DB라 접근이 안됨.

③ 로컬에서 잘 돌아가던 기능(ex-소셜 로그인)이 배포서버에서는 작동이 잘 되지 않았음

에러 해결기.. ↓

https://supersett-diary.tistory.com/243?category=1075832 

[프로젝트][에러][uWSGI] 클라이언트 연결 닫음 [해결]

---

[ 이렇게 해결할 거야 ]

서버 : AWS EC2 2대 - 1. 실서버(cameet.site/) , 2. 개발서버(서브도메인 : dev.cameet.site/)

DB : AWS RDS(mysql) ( 특이점 : 2개의 서버가 db를 공유함 )

 

이번에 주변 현업에 있는 친구들, 선배들 붙잡고 해결방안에 대해 물어보고 공부하며,

백엔드 개발자로서 고려해야 할 프로젝트의 전체적인 구조에 대해서 싸악 훑는 아주 값진 시간을 보냈다..

■ EC2 (Elastic Compute Cloud)

: 2대 운용 예정 (실제 사용자들이 서비스를 이용하는 서버, 개발을 위한 서버)

→ 아직 캐밋이란 서비스가 크진 않지만, 실제 런칭중인 서비스들과 비슷하게 운영해보기 위해 2대를 선택했다. 그러기 위한 추가적인 RDS와 ELB 세팅이 필요했다.

■ S3 (Simple Storage Service)

: 사용자들이 업로드한 프로필 사진을 저장할 저장소

■ RDS - MYSQL (Relational Database Service)

: 실서버와 개발서버가 분리되어있지만 db값을 공유하기 위해서, RDS 서버를 구축했고, 기존에 내장 db였던 sqlite에서 mysql로 db를 분리 후 연동했다.

■ ELB (Elastic Load Balancer)

: 캐밋으로 들어올 다양한 인바운드 트래픽을 목적에 맞게 분산시켜주는 역할을 해줄 것이다. 

→ 서버 상단에서 추가적인 하드웨어 장치가 로드밸런싱 작업을 해준다.