1단계: AWS 배포
2단계: https://github.com/woowacourse/jwp-shopping-order/pull/7
장바구니 주문 미션
배포 및 협업을 할 수 있는 미션이었다.
마코, 우가, 우코, 우스 그리고 나까지 합쳐서 5명이 한 팀이 되었다.
배포
이전 미션들과 달리 AWS를 이용해 배포를 해야 했다.
각자 하나의 EC2 인스턴스를 제공받을 수 있었고, 팀 별로 DB를 위한 추가 인스턴스를 제공받았다.
배포 스크립트를 작성하는 경험을 해볼 수 있었다.
배포 스크립트에 시간을 많이 투자하진 않았고, 다음과 같이 간단하게 작성했다.
echo "Start Deploy Script"
REPOSITORY_NAME=/home/ubuntu/jwp-shopping-order
PROJECT_NAME=jwp-shopping-order
echo "Change Directory"
cd $REPOSITORY_NAME
echo "Git Pull"
git pull origin step2
echo "Build"
./gradlew bootJar
echo "Copy, Start Server"
mv ./build/libs/$PROJECT_NAME.jar .
PID=$(pgrep -f $PROJECT_NAME)
if [ -n $PID ]; then
kill -9 $PID
sleep 5
fi
nohup java -Dspring.profiles.active=prod -jar $PROJECT_NAME.jar 1>stdout.txt 2>err.txt &
협업
일단 우스랑 우코가 먼저 잠실로 와줘서 너무 감사했다.
백엔드가 아닌 다른 크루들과 해보는 첫 협업이라 약간 두근거렸다.
예상외로 대화가 잘 되어서, 빠르게 명세를 정할 수 있었다.
부족했던 부분
여러가지 방법에 대한 장단점을 고려해보기
백엔드와 테이블 명세나 쿠폰 구현에 대해서 이야기할 때 장단에 대해 많이 고려하지 못한 것 같다.
조금 더 시간을 많이 들여서 장단점을 고려했다면 더 좋은 결과물이 나오지 않았을까?
앞으로 선택의 순간에서 조금 더 시간을 들여보는 것도 좋을 것 같다.
새로 배운 부분
expose headers
웹 페이지에서 Location 헤더를 받을 수 없는 문제가 있었다.
기본적으로 허용 목록에 존재하는 응답헤더만 반환한다는 것을 모르고 있었다.
이를 expose headers 설정을 통해 해결할 수 있었다.
nginx 설정에 다음과 같이 추가해 주었다.
add_header 'Access-Control-Expose-Headers' 'Location'
읽기 전용 트랜잭션
단순 조회 요청에 대한 성능을 향상시켜준다는 것이라고 간단히만 알고 있었다.
이번에 코멘트가 달려서 조금 더 자세히 공부해 보기로 했다.
Transactional(readOnly = true)를 사용하는 경우 다음과 같이 동작한다.
setReadOnly(true) 설정이 된 Connection으로 연결을 시도를 한다. 이 설정을 하는 경우 DB마다 다르게 동작한다.
- h2의 Connection 구현체는 readOnly 설정을 무시하는 방향으로 구현되어 Transactional 적용되지 않는다.
- MySQL 8.0(InnoDB 사용 시)의 경우 읽기 전용으로 알려진 트랜잭션의 경우 트랜잭션 ID를 설정하지 않기 때문에 조회 속도가 더 빨라진다.
ORM 프레임워크를 사용한다면 prepareTransactionalConnection를 호출한다고 한다.
추가로 현업에서는 고가용성 내결함성 등을 위하여 클러스터를 구성하여 사용하는 경우가 많고, 이 경우 readOnly 설정이 되어있다면 읽기 전용 DB로 질의가 들어가서 부하 분산의 효과가 있다고 한다.
DAO에 @Transactional 적용
DAO에 트랜잭션을 보장해 보는 건 어떻겠냐고 리뷰가 달려서 고민을 많이 했다.
Service 계층에 이미 트랜잭션을 보장해 주고 있기에 필요 없지 않을까 생각했었다.
DAO를 다른 곳에서 사용하더라도 트랜잭션을 보장하기 위해(확장성 고려) @Transactional을 적용하는 것도 괜찮은 것 같다.