[Delivery] 프로젝트 구조

Delivery 프로젝트는 대용량 서비스를 대비한 구조로 만들어 보려고 노력을 했다.

하지만 웹 개발자를 위한 대규모 서비스를 지탱하는 기술이란 책을 최근에 읽어보면서 Delivery 구조는 부족함이 많았다. 그래도 일단 지금까지 구성한 내용을 설명하고 부족한 것 같은 부분도 써보겠다.

 

 

▶Application Server

Spring boot + tomcat 환경으로 scale out 방식으로 분산처리가 가능하도록 했다. 

 

▶Nginx

웹서버로 로드밸런싱을 위해 도입했다. 

아파치도 고려를 해보았으나 아파치는 요청마다 자식 프로세스를 생성함으로 리소스를 많이 먹는다.

Nginx는 싱글 스레드로 event driven 방식으로 저렴한 비용으로 비동기 작업을 수행한다.

 

▶Jenkins

Jenkins로 CI/CD 환경을 구축했다. 특히 Scale out 방식으로 Application Server를 구성하였기에 배포할 때 서버마다 접근해서 배포한다는 것은 어려운 일이다.

develop 브랜치가 Commit이 되면 github는 webhooks로 Jenkins한테 알린다.

그럼 Jenkins는 테스트와 빌드를 작업한 후 ssh통신으로 배포 서버에 새로운 빌드된 애플리케이션을 배포하고 실행한다.

 

▶Redis

Redis를 3가지 용도로 사용했다.

1. 장바구니 저장

2. 로그인 session 정보를 Redis에 저장.

3. cache

 

scale out 환경에 따른 session 관리하는 법은 sticky, cluster, storage로 3가지로 알고 있다. 이중에 storage session 방식을 구현해본 것으로 session을 관리하는 Redis 서버를 별도로 두었다.

또한 Redis를 Cache로 사용함으로써 I/O 작업을 줄이고자 했다.

 

▶Firebase

1. Firestore : 실시간으로 주문에 대한 상태를 저장한다.

               : ex) 주문 요청, 주문 승인, 배달 중, 배달 완료

2. Storage : 메뉴의 이미지를 저장하는 용도로 사용했다.

 

▶MariaDB

RDBMS로 Mariadb를 사용했다.

 

---

보안할 점

대규모 서비스에서 가장 부하가 많이 일어나는 곳은 CPU 바운스 한 Application Server 쪽이 아닌 DB 쪽이다.

DB는 Disk로부터 I/O 작업이 일어나기 때문이다. 하지만 Delivery의 구조는 Application Server만 처리를 분산시킨 구조이다.

 

▶Master-Slave

대규모 서비스를 지탱하는 기술이란 책을 보면서 DB 1개는 Master, 3개는 Slave로 총 4개의 DB 서버로 분산시킨다고 했다. 그 이유는 1개의 slave 중 하나의 서버가 고장 났을 경우 2대의 slave 서버가 남는데 하나는 새로운 서버에 데이터를 복사용으로 잠시 중단을 해도, 1개의 slave 서버가 있기 때문에 무중단 에러 처리가 가능하기 때문이다. 

 

▶검색 엔진

DB 쿼리만으로 대용량 데이터 처리가 역부족인 경우, 책에선 검색엔진을 만들어 처리하는 법이 나온다. 그중 역 인덱스라는 개념이 나오는데.. 지금으로선 나의 역량으론 검색엔진을 만들어 보는 것은 큰 시간이 소요될 것 같다..