(배포 후기 2) 우리 잘못이 아니야

지난 1화에 이은 AWS 배포하며 겪은 두번째 고난 일기를 시작한다..

지난번에는 환경변수 때문에 애먹었던 후기였는데 오늘은 추가적으로 몇가지 더 공유하고자한다.

---

data.sql의 배신(사실 아님)

로컬로 개발할 때, 애플리케이션 테스트를 위한 데이터가 필요한데, 이때 data.sql에 작성해두면 스프링 애플리케이션 시작시 자동으로 해당 쿼리들이 실행 된다.

JPA 의 DDL auto를 create로 설정해두었기 때문에, 애플리케이션 실행 시점에 테이블이 모두 새로 생성되고 그 이후에 데이터가 추가된다.

나같은 경우에는 초기 데이터 삽입 시나리오를 두가지로 나누어 놨었다.

1. 초기에 Student 를 제외한 데이터를 추가 (data.sql)

2. Student를 제외한 나머지 데이터를 기반으로 새로운 Student 객체들을 생성하는 스프링빈 등록 (TestDataInit.java)

package register.register;

import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import lombok.RequiredArgsConstructor;
import org.springframework.boot.context.event.ApplicationReadyEvent;
import org.springframework.context.event.EventListener;
import org.springframework.security.crypto.password.PasswordEncoder;
import org.springframework.stereotype.Component;
import org.springframework.transaction.annotation.Transactional;

@Component
@RequiredArgsConstructor
public class TestDataInit {

    @PersistenceContext
    private final EntityManager em;

    private final PasswordEncoder passwordEncoder;

    @EventListener(ApplicationReadyEvent.class)
    @Transactional
    public void initStudent() {
        String sql = """
                INSERT INTO student 
                  (student_number, student_name, password, role, max_credit, current_credit, major_id) 
                VALUES 
                  (:studentNumber, :studentName, :password, :role, :maxCredit, :currentCredit, :majorId)
                """;

        for (int i = 1; i <= 100; i++) {
            //noinspection JpaQueryApiInspection
            em.createNativeQuery(sql)
                    .setParameter("studentNumber", String.format("student%03d", i))
                    .setParameter("studentName", String.format("학생%03d", i))
                    .setParameter("password", encryptPassword("1234"))          // 테스트용
                    .setParameter("role", "STUDENT")       // ENUM 저장 방식이 STRING이면 그대로
                    .setParameter("maxCredit", 18)
                    .setParameter("currentCredit", 0)
                    .setParameter("majorId", 1L)              // major_id
                    .executeUpdate();

            // 대량 삽입시 주기적으로 flush/clear (선택)
            if (i % 50 == 0) {
                em.flush();
                em.clear();
            }
        }

    }

    private String encryptPassword(String password) {
        return passwordEncoder.encode(password);
    }
}

코드는 이런식으로 구현해놨다.

이렇게 구현해놨기 때문에 문제가 발생했다.

 

문제 상황

기존에 구현방식을 보자.

1. 초기에 Student 를 제외한 데이터를 추가 (data.sql)

2. Student를 제외한 나머지 데이터를 기반으로 새로운 Student 객체들을 생성하는 스프링빈 등록 (TestDataInit.java)

문제가 보이는가?? 사실 이거만 봐서 안보임 ㅎㅎㅈㅅ

내가 gitignore에 신경을 좀 많이 쓰는 성격이라, .sql 파일을 gitingnore에 등록 해두었던게 문제였다.

즉, 커밋시 sql 파일을 커밋이 되지 않으므로, 깃헙 레포를 기준으로 자동으로 도커 이미징시 해당 쿼리가 실행 되지 않았던 문제였다.

 

즉, 그렇게 때문에 애플리케이션 빌드시 TestDataInit.java 파일이 실행되려고 하는데 필요조건인 data.sql이 없었기 때문에 문제가 발생했던 것이다.

이것조차 자동화 해주는 툴이 있던데, 나는 일단 구현 및 배포에 목말랐던 개발자이다보니, 그냥 DB 툴로 RDS에 내가 직접 쿼리를 넣고 실행하니 정상 작동 되었다. (API 도 정상 작동 됨)

이러고 처음 배포에 성공해봐서 너무 행복한 마음과 함께 꿈나라로 향했다.

---

믿었던 도커의 배신 (실화임)

외부 API는 믿으면 안된다.

근데 나는 배(포)린이다 보니, 도커를 믿었다. 그리고 믿는 도끼에 발등을 찍혔다.

처참한 그날의 흔적들

어제까지 되던 코드 및 배포가 갑자기 다음날 바로 되지 않았었다.

Github actions 로그를 보자.

도커파일의 jdk를 찾을 수 없다는 오류가 나타났는데, 아니 어제까지 잘 받아 사용하던 jdk를 이렇게 한번에 없앤다고?

먼저 재미나이의 답변을 보자.

이미지를 찾을 수 없다는 얘기는 맞다. 하지만 jdk 이름 바꾸라는건 개소리다.

여기서 느꼈다.... AI는 아직 완전하지 않다는 것을.

AI의 구라를 판별하기 위해 우리는 끝없이 공부해야한다.

 

아무튼, 예전에도 노션을 쓸 때, 이런 경험을 한적이 있어서 노션측에 문의한적이 있었다. 그때 문의 내역을 잠시 보면..

대충 503 에러랑 같이 사진이 업로드 되지 않았었는데, 노션의 놀라운점은 노션 개발팀 의 CS 반응 속도가 레전드로 빨라서 감탄했던 기억이 난다.

그리고 이때 이런 대규모 애플리케이션들은 반드시 개인의 상태 페이지가 있음을 알게 되었고, 노션측 사진 업로드 서비스에 장애가 발생했음을 알게 되었다.

버그 내용을 첨부한 이메일을 기반으로 거의 20분 내로 에러가 잡혔던 것 같다.

아무튼, 본론으로 돌아와서 이번에도 느낌이 싸해서 이건 내 잘못이 아니라 도커측 오류일수도 있겠다 싶어 도커 허브를 접속하려고 했는데 역시나 도커 허브에 접속이 이루어지지 않았다.

역시나 뭔가 에러가 터졌었다... 저때는 캡쳐 못했는데 도커 허브 API에 문제가 발생하여 내 배포 과정에서도 문제가 발생했던 것이었다.

도커 허브를 타지 않는 다른 JDK로 시도 했고, 그 결과 정상적으로 배포가 이루어졌다.

 

외부 API를 사용할때는 언제나 내 잘못만은 아니라는 무한한 가능성을 열어두고 개발 및 배포를 하도록 하자.