[DelFood] 프로젝트 소개

Spring-boot를 이용한 프로젝트를 구상하게 되었습니다!

서버만 구현할 예정이며, 사용한 플랫폼과 기술은 아래와 같습니다.

 

사용 기술 및 환경  : Spring-boot, MyBatis, Redis, MariaDB, Docker, Jenkins

프로젝트 개요

 

‘배달의 민족’을 모티브로 만든 배달 O2O Rest API입니다. 위치 기반 배달 서비스를 제공하며 실시간 라이더 매칭을 제공합니다. 대한민국 도로명 주소 DB를 활용하여 라이더에게 배달하는 건물 좌표와 출입구 위치를 제공합니다.

 

프로젝트 진행 과정

 

프론트 개발에 들어가는 시간을 아껴 서버 공부에 투자하기 위하여 kakao oven을 이용해 프로토타입을 제작하고 기능 요구 사항을 추출하여 설계를 진행하였습니다.

프로젝트는 2인 팀 프로젝트로 진행합니다.

 

Github을 통해 코드를 리뷰하고, 서로에게 피드백을 주고받는 활동을 진행하고 있습니다. Github를 통해 직접 눈으로 보고 하는 리뷰보다 더욱 상세한 리뷰가 가능하고 기록을 남겨 지속적으로 확인할 수 있기 때문입니다. 또한 현재 진행중인 코드의 허술함을 줄여 상호간 코드 품질을 보완할 수 있다는 장점도 있었습니다.

 

기술적인 이슈에 대한 해결 과정은 개인 블로그에 포스팅 하고 있습니다. 성능 향상과 코드 유지보수성을 증가시키는 데에 초점을 맞추고 있습니다. 프로젝트 제작이 완료된다면 Docker 이미지를 제작하여 배포할 계획입니다.

 

Redis를 활용한 세션 데이터 관리

 

해당 프로젝트는 Scalability한 구조를 지향하고 있습니다. 그렇기 때문에 회원 로그인 아이디 정보를 세션에 저장하였을 때 Scale-out 시 세션이 분리되어 일관적인 세션 데이터관리가 어렵다는 문제를 어떻게 해결하는 것이 좋을까 고민하였습니다. 세션 정보를 데이터베이스에 연동하여 관리한다면 여러 서버에서 하나의 세션 저장소를 공유할 수 있을 것이고, 어떤 DBMS를 이용해야 세션 관리가 효율적일지 장단점을 비교해보았습니다.

 

속도 보다는 운영의 효율성을 고려하여 Memcached보다는 Redis를 사용하기로 결정하였습니다. 그 이유는 Redis는 Spring에서 공식적으로 지원하고 있기 때문에 참고할 수 있는 자료가 풍부하고 다양한 Eviction을 지원하여 메모리 관리 및 선택에 정교한 접근법 사용이 가능하다는 장점이 있고, DB 이미지를 Disk에 저장하여 서버 손상시에도 데이터를 복구할 수 있기 때문입니다. Memcachaed는 안정적인 응답 속도와 빠른 저장속도를 가진다는 장점이 있지만 상대적으로 서버 운영에 필요한 기능이 부족했습니다.

 

 

Java 스펙을 활용한 코드 품질 관리

 

Java에 어울리는 코드를 만들기 위하여 꾸준히 코드를 검수하고 있습니다. ‘이펙티브 자바’, ‘자바 성능 튜닝 이야기’ 등의 책을 참고하여 코드 품질 향상에 목표를 설정하였습니다.

 

프로젝트 초기에 예외처리를 하지 않으려고 if-else문을 많이 만든 적이 있습니다. 하지만 예외를 던질 때에는 꼭 예외처리를 해야 한다는 내용을 읽은 후 throw Exception으로 예외 상황을 업데이트 하였고 checked Exception이 되지 않도록 Runtime Exception으로 설정하였습니다. 그 결과 프로젝트에 너무 많이 존재하던 if-else문을 상당 수 제거할 수 있었습니다.

 

HashMap으로 전달해주는 데이터를 Response 객체를 생성하여 명시적으로 관리하도록 변경하였습니다. 정말 필요한 경우가 아니라면 setter를 설정하지 않고, 값을 복사하여 넘겨주어 불변 객체를 만들어 객체 안정성을 고려하였습니다. static final 상수를 사용하여 불필요한 객체 생성을 지양합니다. Java 스펙에 맞는 코드를 제작하기 위해 계속해서 코드를 리팩토링하고 있습니다.

 

 

서버 부하를 고려한 캐시 전략

 

서버에 캐시를 적용한다면 성능적으로 좋을 것이라고 생각하였습니다. DB서버의 부하를 줄일 수 있을 것이고, 서버 내부 로직의 호출 횟수를 줄일 수 있다고 판단하였습니다. 주소 검색 등 동일 조건상 동일 결과값이 나온다면 캐시를 적용하는 것이 좋다고 생각하였습니다. 다중 서버 환경에서 로컬 캐싱을 진행한다면 동일 조건이라도 여러 서버에서 로직이 진행될 수 있습니다. 그렇기 때문에 Redis 서버에 글로벌 캐싱을 적용하였습니다. 캐싱을 적용한 이후 주소검색 로직은 300ms에서 10mx미만으로 응답시간이 감소하였습니다.

 

 

Jenkins를 활용한 CI/CD 적용

 

Github에서 PR이 발생할 때 Jenkins 서버로 hook을 날려 빌드와 테스트를 진행하도록 적용하였습니다. 이를 통해 직접 테스트 코드를 돌려보지 않아도 앱의 신뢰성을 보장받을 수 있도록 할 수 있었습니다.

 

 

 

 

Project Github URL : https://github.com/f-lab-edu/food-delivery

f-lab-edu/food-delivery

 

---

프로젝트 화면 설계 - Kakao Oven

https://ovenapp.io/view/OI44WSGwSZRSMcyiveGcSWGvw38YKizI/bco8b

 

 

 

 

 

---

데이터베이스 스키마 설계 - AQueryTool

Github에서 고화질 캡처 화면을 볼 수 있습니다.

 

프로젝트 시작시 설계했던 스키마(구버전)

 

 

2019-10-27 변경된 스키마(구버전)

주소 테이블을 추가하여 주소를 한 테이블에서 관리하도록 변경

 

2019-11-08 변경된 스키마

쿠폰 Table이 추가되었습니다.

 

 

 

기술 관련 이슈 포스팅

 

1.     Join이 너무 많이 발생하여 성능 저하가 우려되는 테이블을 역정규화

https://deveric.tistory.com/59?category=350852

https://deveric.tistory.com/60?category=350852

 

2.     아이디 중복 체크 시 전달하는 Http Status값은 어떻게 설정해야 할까?

https://deveric.tistory.com/62?category=350852

 

3.     대한민국 주소 정보를 테이블로 만들어 외래키로 관리하기

https://deveric.tistory.com/66?category=350852

 

4.     캐시 저장소로 Redis와 memcached중 어떤 것을 선택하는 것이 좋을까?

https://deveric.tistory.com/65?category=346637

 

5.     주소 데이터의 빠른 검색을 위해 인덱스 설정하기

https://deveric.tistory.com/68

 

6.     반복되는 로그인 체크 로직을 AOP를 적용하여 리펙토링하기

https://deveric.tistory.com/67