[회고] 코드스쿼드 이슈트래커 1주차

혼자 진행하는 마지막 프로젝트

코드스쿼드 마지막 프로젝트는 혼자서 진행해 보기로 결정했다..! 그 간 좋은 페어 분들을 만나 협업하는데 큰 충돌 없이 진행되었고, 배우게 된 부분도 많았다. 문제 해결을 위한 소통 과정에서 혼자였으면 전혀 고려하지 못했을 키워드를 떠올려 함께 학습하고 이후 과제에도 더 개선된 방식으로 적용해 볼 수도 있었고, 분업을 통해 담당한 도메인에 더 애정을 가지고 집중할 수 있었고, 막연했던 코드 conflict에 대한 두려움도 사라지게 되었다. 단 개인적인 슬럼프로 컨디션이 좋지 않은 시간이 자주 있었는데 하루의 core time을 계속 함께해야 한다는 부분이 약간은 벅찼던 것 같다. 페어 분들이 배려해 주신 덕에 여러모로 너무 감사했지만 한편으로는 죄송스러운 마음이 커서, 그러한 부담에서 조금은 벗어나고자 마지막은 홀로 진행해 보자는 결심을 내리게 되었다.

 

여태껏 모바일(iOS, Android) 분들과만 협업했었는데 이번에는 드디어 FE분들과 만나게 되었고, 서로 인사를 나눈 후 요구사항 분석을 시작했다. 매번 했던 방식이지만 이번에는 조금 더 요구사항을 세분화하여 이슈로 등록하고 하나씩 해결해나가는 방식을 적극적으로 활용하겠다고 다짐하였다. 마지막 과제를 진행하면서 학습하고 적용해 보고 싶었던 부분은 다음과 같다.

 

• 무중단 배포
• Redis를 활용한 JWT Token 관리
• Querydsl을 활용한 동적 쿼리 작성 & 인덱스를 활용한 쿼리 성능 최적화
• Spring Rest Docs 학습 및 단위 테스트
• 그 외 Docker Compose 활용, Elasticsearch를 활용한 본문검색 등등..

 

마지막 프로젝트인 만큼, 충분히 학습하고 여러 시도를 통해 과제에 녹여내볼 계획이다. 단순히 최신 트렌드의 기술을 적용해보고 "나 이거 쓸 줄 알아" 정도로 끝내지 말고 왜 이 기술을 적용했는지, 기존 기술에 비해서 어떤 부분이 나았는지를 체험하면서 기록해 보고자 한다. 

 

 

---

주요 진행 사항 - 무중단 배포 시도(진행 중)

코드스쿼드 이전 이 책 저 책을 읽어보며 학습하면서 이동욱 님의 "스프링 부트와 AWS로 혼자 구현하는 웹 서비스"로 무중단 배포를 학습해 본 경험이 있었다. 다만 AWS의 세부 기능, Spring Boot에 대해 제대로 학습하지 못한 채 책에 나온 부분을 따라 치기에 급급했고, 내용은 분명 좋았지만 당시에 내 수준에서는 과하지 않았나 싶다. 분명한 건 전체적인 배포의 과정을 대략적으로나마 이해한 현 시점에는 많은 도움을 얻을 수 있었는데, 학습이란 건 필요한 시점에 사용해 보고 적용하는 게 더 오래 기억에 남는다는 것을 다시 한번 느끼게 해준 계기가 되었다.

 

우선 전체적인 배포 과정은 다음과 같다. 직전 프로젝트에서 배포를 담당 해주셨던 Shine이 작성하신 글을 참고한 덕에 큰 어려움 없이 배포를 시도해 볼 수 있었다. 

배포 구성

흐름을 설명하면 다음과 같다.

 

1. Local에서 GitHub 배포 branch로 Push한다.

2. GitHub에 정의해 둔 Action이 실행된다.

3. Action에서 해당 branch에 있는 디렉토리를 대상으로 build를 수행하고 S3로 *.jar를 넘긴다.

4. Action에서 CodeDeploy에게 이후 동작을 요청한다.

5. CodeDeploy는 EC2 내의 CodeDeploy Agent에게 Action에 정의된 동작을 요청한다.

6 & 7. CodeDeploy Agent는 S3에 있는 *.jar을 찾아 EC2로 가져온 후, appspec.yml에 작성된 동작을 수행한다.

 

 

 

다만, 무중단 배포를 위해서는 Spring Boot가 잠시 동안 2개 띄워질 필요가 있었다. 아래는 EC2 내부를 대략적으로 표현한 그림이다.

8081 port Server가 띄워져 있고 NginX의 리버스 프록시를 활용하여 8081로 요청을 보내고 있는 상황에서 코드가 업데이트되어 배포가 발생했다고 가정하자. 무중단을 위해서는 8082에 새로운 Spring Boot를 띄우고 정상 동작 여부를 확인한 후에(health Check) Nginx가 8082로 요청을 proxy해야 클라이언트 입장에서는 무중단 되는 것처럼 느끼게 될 것이다.

 

문제는 이번 과제에 JWT Token 관리를 위해 Redis를 사용한 부분이었다. 우선 Redis를 이용한 이유는 다음과 같다.

• refresh token을 저장하여 토큰 갱신 역할을 담당한다. 메모리에 저장되기 때문에 Disk I/O가 없어 RDB 대비 속도가 빠르다.
• save 시 소멸 시간을 지정할 수 있다. 이를 통해 refresh token 만료 시 자동으로 삭제되므로 개인 정보 관리에 덜 민감할 수 있다. 

 

가볍게 적용해보는거라 Embedded Redis를 사용했으며 아래와 같이 기본 port를 6379로 지정하였다. 문제는 여기서 발생했다.

@Configuration
public class EmbeddedRedisConfig {

    @Value("${spring.redis.port}") // 6379로 설정
    private int redisPort;

    private RedisServer redisServer;

    @PostConstruct
    public void redisServer() {
        redisServer = new RedisServer(redisPort);
        redisServer.start();
    }

    @PreDestroy
    public void stopRedis() {
        if (redisServer != null && redisServer.isActive()) {
            redisServer.stop();
        }
    }
}

 

이때 한쪽 Spring Boot가 종료되지 않은 상태로 새로운 프로세스가 실행되면 동일한 6379 Port로 Redis가 띄워지게 되므로 충돌이 발생하게 된다. 직관적으로 생각해 보면 Token 관리는 WAS의 메모리가 아닌 별도의 공간에서 되어야 WAS 끼리 이를 공유하여 로그인을 유지할 수 있는 건데, 기초적인 부분부터 놓쳤던 것 같다..😂

 

해결할 수 있는 방법은 다음과 같다.

 

1) 생성 시 가능한 port를 조회해서 할당한다. 우아한 테크코스 깃-들다 프로젝트 참고

 

2) EC2에 Redis Server 설치 또는 AWS Elasticache 사용

Redis를 가장 잘 활용할 근본적인 방법이지 않을까 싶다. Spring Boot와 life cycle을 함께 가져가지 않기 때문에 무중단 배포에 영향을 받지 않게 된다.

 

Embedded Redis를 학습 차원에서 적용해 보았기 때문에 2번 방법을 선택하기로 결정하였으며, 우선 포트 충돌을 해결하고자 단일 배포로 결정하였다. Redis Server가 구축되면 다시 무중단 배포로 전략을 수정할 계획이다.

 

---

배운 점

• 앞서 포트 문제로 인해 새롭게 배포된 서버가 띄워지지 않는 원인을 찾는 과정에서, 먼저 띄워진 서버를 kill 하고 나서도 Embedded Redis가 중단되지 않는 현상이 발생했다. 여기에서 매번 kill -9 pid로 프로세스를 중단하고 있었는데 이때 EmbeddedRedis의 @PreDestroy가 정상적으로 호출되지 않아 중단되지 않는 것으로 보였다. kill -15로 WAS를 중단하니 정상적으로 Redis가 중단되게 되었다. 항상 안전하게 종료하는 습관을 기르자.

   @PreDestroy
    public void stopRedis() {
        if (redisServer != null && redisServer.isActive()) {
            redisServer.stop();
        }
    }

• JWT Refresh Token을 굉장히 생소한 개념으로 생각하여 적용하지 않고 있었지만, 단순하게 Access Token보다 유효기간이 더 긴 토큰이라 생각하니 조금은 명료해진 것 같다.

 

---

아쉬운 점 & 고칠 점

 

1) 나태함을 경계하자

 

꽤 오랫동안 슬럼프에 빠져있는데 이제는 좀 나 자신을 위해서 빠져나와야겠다는 생각이 든다. 정신이 건강하지 못하니 자꾸 잡생각만 들게 되고 덩달아 몸도 좋아지지 않는 것 같다. 다음주는 갓생 살아보자!!ㅎㅎ

 

2) 무분별한 기술 습득을 피하자

 

인프런 강의가 나오면 사놓고 안 보고, 좋은 책 소개 글이 올라오면 사놓고 안 보고 있다. 원인을 생각해보니 이전에 강의를 연달아 보고나서 다 이해했다고 생각한 내용들이 막상 적용이 필요한 시점에 전혀 기억이 나지 않다 보니 나도 모르게 새로운 지식 습득에 지쳐 거부하게 된 게 아닐까 싶었다. 반면에 정말 필요했을 때 공부했던 내용은 스펀지처럼 잘 흡수가 됨을 느꼈는데, 이처럼 내 수준을 알고 현 시점에 필요한 걸 찾아서 공부하는 습관을 들여야겠다. 마음 급하게 먹지 말자.

 

3) 다른 공부 방식을 고민하고 적용해보자

 

인터넷 강의를 보면 코드 하나하나, 강사님의 디테일한 내용 하나하나 노션에 정리하는 편이다. 나름 잘 이해해고 넘어갔다고 생각했음에도 다시 보면 정말 까마득한 느낌이 든다. 그렇다고 반복해서 2~3번 보기에는 강의 내용도 너무 방대했다. 이 부분에서 고민이 되게 많았는데 제인님이 공유해주신 컨텐츠 기적의 독서 메모법을 보고 약간 힌트를 얻게 되었다. 강의의 요점이라고 생각되는 부분은 요약이다. 독서 메모에 대한 내용이지만 이를 인터넷 강의에 다음처럼 적용해 볼 수 있다고 생각했다. 

• 챕터별로 학습한다. 강의마다 한 주제를 다루게 될 텐데, 중간중간 잠시 강의를 멈추고 중요하다고 생각하는 키워드를 작성한다.
• 강의가 끝난 후 키워드를 기반으로 최대한 내용 요약을 시도한다. 작성한 예시 코드도 중요한 부분만 남긴다.