Go 언어를 Java 관점에서 이해하기 위한 비교 문서

기본 개념 비교

프로젝트 구조 비교

계층 구조 비교

에러 처리 비교

Java (예외 기반)

try {
    result = service.call();
} catch (Exception e) {
    // 에러 처리
}

Go (반환값 기반)

result, err := service.Call()
if err != nil {
    // 에러 처리
    return err
}
// 정상 처리

인터페이스 비교

Java (명시적 implements)

public class MyService implements Service {
    // 메서드 구현
}

Go (덕 타이핑 - 암시적 구현)

// 메서드만 구현하면 자동으로 인터페이스 충족
type PubSub interface {
    Publish(subject string, data []byte) error
    Subscribe(subject string, cb MsgHandler) error
}

// natsConnWrapper는 위 메서드들을 구현했으므로
// 자동으로 PubSub 인터페이스를 충족
type natsConnWrapper struct { ... }
func (n *natsConnWrapper) Publish(...) error { ... }
func (n *natsConnWrapper) Subscribe(...) error { ... }

비동기 처리 비교

Java (Thread)

new Thread(() -> doSomething()).start();

Go (Goroutine)

go doSomething()  // 새 고루틴에서 비동기 실행

고루틴 간 통신 (Channel)

Go의 채널은 Java의 BlockingQueue와 유사하다.

ch := make(chan Message)

// 송신
go func() {
    ch <- message
}()

// 수신
msg := <-ch

미들웨어 vs Filter

Java Servlet Filter

public void doFilter(req, res, chain) {
    // 전처리
    chain.doFilter(req, res);
    // 후처리
}

Go Middleware

func middleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        // 전처리
        next.ServeHTTP(w, r)
        // 후처리
    })
}

컨트롤러 비교

Java Spring Controller

@RestController
@RequestMapping("/api")
public class ApiController {

    @Autowired
    private Service service;

    @PostMapping("/events")
    public ResponseEntity<Response> events(@RequestBody EventDTO dto) {
        // 비즈니스 로직
        return ResponseEntity.ok(result);
    }
}

Go Handler

type Handler struct {
    service Service
}

func (h *Handler) Events(w http.ResponseWriter, r *http.Request) {
    var dto EventDTO
    json.NewDecoder(r.Body).Decode(&dto)

    // 비즈니스 로직

    json.NewEncoder(w).Encode(result)
}

포인터 리시버

Go에서 func (a *App) Run()의 *는 포인터(Pointer)를 의미

Java와 비교

// Java - 클래스 안에 메서드 정의
public class App {
    public void run() {
        this.doSomething();  // this로 자기 자신 참조
    }
}

// Go 메소드 구조

func (m *AuthMiddleware) Handler(next http.Handler) http.Handler
//    └──────┬───────┘  └──┬──┘  └───────┬───────┘ └─────┬─────┘
//        리시버          메소드명        파라미터           반환타입


// Go - 구조체 밖에서 메서드 정의
type App struct {
    config Config
}

func (a *App) Run() {
    a.doSomething()  // a가 Java의 this 역할
}

* 유무의 차이

예시

type Counter struct {
    count int
}

// 값 리시버 - 원본 변경 안 됨
func (c Counter) IncrementWrong() {
    c.count++  // 복사본만 증가, 원본은 그대로
}

// 포인터 리시버 - 원본 변경됨
func (c *Counter) Increment() {
    c.count++  // 원본이 증가
}

Java로 비유하면

// 값 리시버 = 이런 느낌 (실제론 불가능)
void increment(Counter copy) {  // 복사본 전달
    copy.count++;  // 원본 영향 없음
}

// 포인터 리시버 = 일반적인 Java 메서드
void increment() {
    this.count++;  // 원본 수정
}

결론

Go에서 *가 붙은 포인터 리시버를 쓰는 이유:

1. 원본 수정이 필요할 때 (상태 변경)
2. 구조체가 클 때 (복사 비용 절약)

Java에서는 객체가 항상 참조로 전달되므로 이런 구분이 없지만, Go는 명시적으로 지정해야 한다. 대부분의 경우 *를 붙인 포인터 리시버를 사용

x := 10
p := &x   // & : x의 주소를 얻어 p에 저장 (p는 *int)
*p = 20   // * : p가 가리키는 실제 값을 수정

// & 는 주소를 만들기
// * 는 포인터를 선언하거나, 포인터를 따라가 실제 값을 읽고, 쓰기
// 포인터는 필요한 시점에 한 번 따라가서 값 읽기/쓰기를 진행함

// **결과값 + 에러를 같이 반환**하는 이 패턴이 Go 코드 어디서나 보임
// Java의 try-catch 대신 이걸 쓰는 것

func findUser(id int) (User, error) {
    user, err := db.Query(id)
    if err != nil {
        return User{}, err  // 빈 User와 에러 반환
    }
    return user, nil  // 유저와 nil(에러 없음) 반환
}

// 사용할 때
user, err := findUser(123)
if err != nil {
    // 에러 처리
}

타입

bool

string

int  int8  int16  int32  int64
uint uint8 uint16 uint32 uint64 uintptr

byte // alias for uint8

rune // alias for int32
     // represents a Unicode code point

float32 float64

complex64 complex128

Mux

• Spring DispatcherServlet과 비슷한 역할
• @RequestMapping, @GetMapping 같은게 Go에서는 Mux가 하는 일
• URL 보고 알맞은 핸들러(컨트롤러)로 연결해주는 것

Bufio (잘 안쓰겠지만)

Java의 BufferedReader와 개념적으로 유사 — I/O 횟수를 줄이기 위한 버퍼링이 핵심

공통점

비교

// Java
BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
String line = reader.readLine();

// Go
reader := bufio.NewReader(os.Stdin)
line, err := reader.ReadString('\n')  // '\n'까지 읽음

주요 차이점

• Go의 ReadString('\n')은 구분자 문자('\n')를 결과에 포함시킴
• Java의 readLine()은 구분자를 제외하고 반환
• 그래서 Go에서는 읽은 후 strings.TrimSpace(line)으로 개행 문자를 직접 제거해야 함

당시 요청 부서의 상황은

• 깃헙 repository에서 브랜치 관리를 안 하고 있었음
  • 단일 브랜치로 작업했고 개발 테스트용 브랜치의 필요성을 절감하지 못했음
• 배포 툴과 방식에 대해 익숙하지 않아 내가 알아보고 몇 가지 안을 준비해야하는 상황
• Docker와 Elastic Beanstalk를 사용했으면 좋겠다는 정도의 요구사항이 있었음

현황과 부서의 요구사항에 맞춰 설계 작업에 들어갔다.

0. 사전 작업

브랜치 분리 요청

신규 서비스는 백엔드에서 AI 서비스 (ML 작업을 직접 하는 코드인지는 아직 확인이 안 됐다. 나에게 코드를 확인할 권한도 없기도 했고.)를 호출하고, 응답받는 과정이었고 이를 위한 서버도 띄워야 했다. 회사는 개발 테스트용 환경이 별도 구축돼 있었고, 모든 개발자들이 환경별 테스트를 했기 때문에 AI 서비스도 이를 따라야 테스트가 원활했다. 그래서 담당자에게 브랜치 분리의 필요성을 설명하고, 참고를 위해 백엔드에서 관리하는 방법을 설명했다. 실제 코드 관리는 해당 부서에서 해주시겠지만 브랜치 분리의 필요성에 공감해줬고, 환경별 마더브랜치를 알려줘서 깃헙쪽 작업은 정리가 됐다.

배포 방식 선택 요청

두 가지 안을 제안했다. 현재 백엔드, 프론트엔드에서 사용중인 Jenkins를 이용하는 방법과 Github action을 통한 방식을 각각 설명하며 원하는 것을 알려달라고 했다.

Jenkins 배포 방식

• 사내 개발팀 모두 jenkins로 배포 중이기에 회사 내 통일성을 가져갈 수 있음
• 배포 시점과 브랜치 머지 시점을 다르게 가져갈 수 있음 (장점이자 단점)
  • 환경별 마더 브랜치로 머지 후에도 추가 수정 작업 후 배포가 가능
  • 다만 배포를 위한 스텝이 하나 더 있는 것처럼 느낄 수 있음
  • Jenkins를 배포하려면 별도 ip로 접속 후, 로그인을 거쳐 배포하는 과정이 번거로울 수도 있기 때문

Github action 배포 방식

• 환경별 마더 브랜치에 머지하면 그 즉시 배포가 되기 때문에 편리하게 여길 수 있음
• 다만 현 담당자의 퇴사 후, 인수인계가 잘 되지 않으면 배포방식에 대해 유지보수성이 떨어질 수 있다는 우려도 있음

각 방식의 장단을 들은 AI 부서에서는 통일성을 최우선으로 생각해 Jenkins로 배포할 수 있게 작업을 요청했다.

1. 설계

각 단계별 인프라 서비스는 아래처럼 정해졌다.

• 코드 관리 : github
• Docker image build : Jenkins
• Docker image push : AWS ECR
• Docker.aws.json 저장 : AWS S3
• Deploy : AWS Elastic Beanstalk

이에 기반한 배포 플로우는

1) Jenkins에서 빌드할 소스 코드를 Github Repo에서 가져온다 2) 이미지 빌드가 완료되면 AWS ECR에 push 한다 3) S3에 Docker관련 Json 파일을 업로드하고 4) Elastic Beanstalk에 배포를 한다 5) 그 과정에서 beanstalk은 S3에 업로드된 Docker.aws.json 파일을 다운로드 받고 6) 다운받은 파일을 기반으로 배포가 진행된다.

이렇게 설계까지 짜는 것은 어렵지 않았다.

2. 구축

작업은 AWS쪽과 Jenkins 스크립트 작성으로 분리해서 작업했다. AWS는 콘솔에서 필요한 데이터만 입력해주면 끝나지만 Jenkins는 스크립트를 짜야했기 때문.

(1) AWS

1) Elastic Beanstalk

배포 한 번으로 관련 인프라(로드 밸런싱, 오토 스케일링, 어플리케이션 상태 모니터링 등)를 관리해주는 기능이다.

어플리케이션 하나에 두 환경을 구축할 수 있었기에 운영과 개발 테스트 환경, 두 가지를 구성했다. 이런 식으로 버전에 넘버링은 자동으로 채번되고, 생성일자도 모두 로그가 남아서 관리가 다소 용이하다. 캡쳐에는 없지만 소스도 모두 남아있어 배포된 버전의 json 파일도 다운로드가 가능했다.

2) ECR (Elastic Container Registry)

별도의 도커 repo를 구성하는 방법도 있었지만 최소한의 노력과 설정으로 빠르게 구성하기 위해, 그리고 요청 부서의 요구사항으로 ECR을 사용했다. IAM으로 권한 관리하기도 편했다. 운영과 개발 테스트 환경용은 분리했다.

역시 최신 이미지는 자동으로 표기해주고, 푸시 로그도 모두 남기 때문에 히스토리 관리가 편리했다.

3) 로드 밸런서

beanstalk에서 로드 밸런서까지 자동으로 만들어서 연결해주지만, 정책상 도메인 매핑이 필요해 관리 부서에 DNS NAME을 전달했다. AWS 로드밸런서와 연결된 IP주소는 변경될 수 있어서 DNS Name을 이용해서 CNAME 레코드를 생성하라고 권장한다. 다행히 이 작업은 금방 끝났다.

(2) Jenkins

기존에 스크립트를 짜 본 적은 없었기 때문에 찾아가며 짜야했다. 주된 예시는 파이프라인이 많았다. Freestyle project로 만들까 잠시 고민도 했지만, 파이프라인 형식이 전체 플로우를 알고 싶어하는 해당 부서의 요구사항에도 잘 맞다 생각했다. 또 처음 해 본 작업이라 실패나는 구간을 확인하기 편리하기 때문에 최종적으로 파이프라인 방식으로 설정했다.

과정은 총 3가지로 구성했다. 깃헙에서 코드 가져오기 -> 도커 이미지 빌드하기, 빌드한 이미지 ECR에 푸시하기 -> Elastic beanstalk에 배포하기

각 스텝별로 참고할만한 자료는 많았었기 때문에 차근차근 작성했고, 오탈자에 유의하며 작성을 완료했다.

3.문제 상황 발생

스크립트도 완료했고, AWS쪽 작업도 잘 돼 있는데 자꾸 젠킨스 instance에서 Docker image build 할 때 실패가 났다. 원인을 못 찾아서 한참을 헤맸다.

첫번째 의심 : 스크립트 오류

처음 스크립트를 짜보다 보니, 스크립트 내 오류가 있는 건 아닌가 싶었다. ChatGPT에게도 물어보고, 구글 내 검색을 해보며 문법 오류를 다시 점검했으나 이상 없었다.

두 번째 의심 : 젠킨스 EC2의 권한 문제

AWS에 떠 있는 젠킨스 서버가 github에서 코드를 복사해오지 못하는 것 아닌가, 혹은 이미지 빌드 후 ECR에 push할 때 권한의 문제가 있는 것은 아닌가 의심했다. 하지만 AWS IAM에서 FullAccess 권한을 줬고, github에서도 정상적으로 복사해 오는 것을 젠킨스 서버 내에서 확인할 수 있었다.

세 번째 의심 : docker image 오타

스크립트와 다른 파일 내 오타가 있어서 이미지명 불일치가 실패 원인일까 의심돼 모든 파일과 스크립트를 다시 훑어보고, cmd+f 로 확인했으나 역시 이 때문도 아니었다.

결국 원인은...

정말 한참을 헤매다가 젠킨스 EC2 서버에 들어가서 다시 확인했더니 서버 내에 docker 설치가 안 돼 있었다. 그러니 docker 관련 명령어가 안 먹혔던 것이다. 해당 인스턴스 내 docker가 설치 돼 있다고 착각했던 이유는, 과거 devOps의 흔적인 듯 하나 빈 docker 디렉토리가 있었기 때문이었다.

docker --version

이라도 한번만 쳐봤으면 빨리 알았을텐데 짐작만으로 작업했던 것이 느린 이슈 해결의 원인이었던 것이다.

4.작업 종료

중간에 docker 설치 체크가 안 되면서 아쉽게 시간을 허비했지만, 최종 예정 일정보다 3일 일찍 구축을 완료했다. 이후 배포부터 서비스 호출까지 모두 이슈없이 됐고, 운영 환경 배포일에도 정상 작동되는 것 확인했다. 현재까지 서버 이슈 없이 정상 작동 잘 되는 중이다.

5.마무리하며

이번 작업은 처음 해보는 작업이 많아, 검색과 약간의 공부가 필수적이었다. 그리고 짐작으로 다음 스텝을 진행한다는 것이 얼마나 돌아가는 길인지도 깨달았다. 어떠한 작업을 할 떄, 짐작과 추측만으로 작업하지 말고 꼭 확인하는 절차를 거칠 필요성을 체감한 프로젝트였다.

• 메시지 대량 발송 시, 발송 내역에 대한 세부 조회 및 조회 건에 대한 엑셀 다운로드 성능 개선
• 기준 : 메시지 발송 건수 약 6만 5천 건
• 성과
  • 발송 내역 상세 조회 속도 4900% 개선 (100초 -> 2초)
  • 상세 조회 내역 엑셀 다운로드 속도 2100% 개선 (155초 -> 7초)
  • 속도 측정 방법 : 해당 로직 전,후에 System.currentTimeMillis()를 삽입한 뒤 산출

// 개선 전
INFO i.c.g.a.a.m.MassMessageFacade@findMessageHistoryDetailsExcel(130) - 메세지 로그 조회 소요시간 : 100.337초
INFO i.c.g.a.a.m.MassMessageFacade@findMessageHistoryDetailsExcel(135) - 엑셀 파싱 작업 소요시간 : 154.885초

// 개선 후
INFO i.c.g.a.a.m.MassMessageFacade@findMessageHistoryDetailsExcel(130) - 메세지 로그 조회 소요시간 : 1.504초
INFO i.c.g.a.a.m.MassMessageFacade@findMessageHistoryDetailsExcel(136) - 엑셀 파싱 작업 소요시간 : 6.817초

성능 저하 원인

• 상세 내역 조회
  • 발송 상태에 대한 code와 description이 별도 테이블에 정의 돼 있음
  • 발송 상태에 대한 description을 내려주기 위해, 발송 건마다 이 테이블에 select 쿼리를 날림
  • 즉, 메시지 6만 5천 건을 조회한다면 6만 5천번 select 쿼리를 날리고 있는 상황
• 메시지 발송 내역 상세 조회 엑셀 다운로드
  • 엑셀 파일 생성용 공통 Util이 존재했고, As-is는 이 util을 사용 중
  • 공통 Util은 쿼리해온 결과를 Map<String, Object>에 파일명, head, body를 각각 담아서 row별로 출력하는 방식
  • 각 cell에 적힐 데이터들은 모두 String으로 변환
  • 쿼리 결과를 두 번 변환하다보니(Map에 담고, 다시 꺼내서 엑셀로 출력) 대량 건을 작업할 때는 부적합
    

해결 방법

• 상세 내역 조회
  • 발송 상태에 대한 정의 테이블은 DML이 드문 테이블이며 데이터가 많지 않음
  • 따라서, 발송 상태 코드에 맞는 description을 찾기 전 모든 값을 가져와(findAll()) Java단에서 일치하는 값을 찾아서 매칭
  • 그 결과 100초 -> 2초로 개선
• 메시지 발송 내역 상세 조회 엑셀 다운로드
  • 공통 Util이 아닌, 쿼리해온 결과를 for-each 문을 사용해 바로 찍어주는 방식으로 변경
  • 그 결과 155초 -> 7초로 개선
  • 단, 해당 건처럼 대용량 데이터를 엑셀로 변환하는 경우를 제외하고는 엑셀 공통 Util을 쓰는 것이 바람직함

• AWS RDS 엔진버전이 2.10.3 지원 중단
• 2.11 버전으로 자동 업그레이드 가능하나, 운영 서버의 다운타임 우려
• 다운타임은 불가피 하므로, 이 기회에 MySQL 8.x 버전으로 업그레이드 진행 결정

작업대상

: 클라우드게이트 RDS, 셀러게이트 RDS 전체 -> 지원중단 관련 공고

사전 준비

1) 업그레이드 테스트

• 테스트를 위한 DB 세팅

  1. 기존 DB 스냅샷을 뜬다
  2. 그 스냅샷으로 test용 DB를 띄운다
  3. test용 DB를 버전 업그레이드 해본다
  4. 이슈가 있다면 모두 수정 및 이슈 해결 한다
  5. 모든 이슈가 해결되면 본 DB를 업그레이드 진행한다

• 환경별 테스트 순서

  • develop DB에서 1차 테스트
  • 실 운영 DB의 스탭샷으로 2차 테스트 진행

실서버 DB 스냅샷 테스트

• 작업 방식은 크게 두 가지
• 블루/그린 배포 방식 : down time을 최소화 하면서 RDS를 교체하는 방식
• 인플레이스 방식 : 기존 RDS를 바로 버전 업 하는 방식. 작업하는 동안 서비스 운영 불가
• AWS 에서는 블루그린 배포 방식을 권장하기에 두 방식 모두 테스트 해보기로 함

실서버 DB 테스트 작업 계획

• 운영 DB 스냅샷을 두 개 복원한 뒤, 하나는 블루그린 테스트용 다른 하나는 인플레이스용으로 세팅

• 각 버전의 공통 체크 리스트

  1. 파라미터 그룹 값들 확인하기
  2. api 연결 체크
  3. 버전 업 총 소요 시간 체크

• 블루/그린 버전일 때 추가 체크

  • 블루 -> 그린으로 전환될 때 엔드포인트도 변경되는지 확인

테스트 결과

• 블루그린 배포 방식

  • 총 6시간 소요
  • 기존 SQL mode 설정값 때문에 버전업이 원활하지 않은 이슈가 있었으나 해결
  • 엔드포인트 변함 없음
    

• 인플레이스 배포 방식

  • 파라미터 그룹 값 : 기존과 동일하게 세팅 및 확인 완료
  • api 연결 체크 : 로컬에서 직접 접근으로 확인 완료
  • 버전 업 총 소요 시간 : 21분 소요 (16:57 ~ 17:18)
  
  #### 테스트 중 만난 이슈

• 1. 파라미터 그룹에서 charset 설정을 안 해준 때에 데이터가 ?로 저장*

• 파라미터그룹이 default 일 때 저장된 값

-> 파라미터 그룹 내, charset 설정을 모두 진행 후 테스트했더니 정상 노출 돼었다.

2. 셀러게이트 RDS 업그레이드 시, upgrade-precheck 실패로 업그레이드 실패 이슈

• 이 역시 파라미터 그룹의 차이 때문에 발생한 이슈
  • pre-check를 통과한 RDS와의 차이는 sql_mode가 지정 값이 없느냐, TRADITIONAL로 세팅돼 있냐 차이였음
  • 최종적으로는 sql_mode에 지정값을 없애고 진행해 정상 작동함
• AWS에서 메이저 업그레이드할 때 precheck를 해주는데 에러 발생 시, 로그를 확인할 수 있음
  • Warning은 업그레이드 가능하지만, Error가 발생하면 업그레이드가 불가
  • 당시 에러 로그는 아래와 같았음

    {
      "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
      "title": "Check for inconsistency related to special characters in stored procedures.",
      "status": "ERROR",
      "description": "Invalid default value for 'modified'"
    }

• 해결 방법을 찾기 위한 여정
  1. 첫 번째 검색 키워드 : procedure

     - ‘호환되지 않아 사전에 주의해야할 부분’ 중에 프로시저에 대한 설명이 있었음
     - `SHOW PROCEDURE STATUS;` 실행 후 확인해봤으나 직접 설정한 프로시저는 없었음
     - 설정하지도 않은 부분에서 에러가 날 수 없기 때문에 이 부분은 아닐 것이라 생각하고 다음 키워드 진행<br>

   2. 두번째 검색 키워드 : `character, character set`
        - ‘호환되지 않아 사전에 주의해야할 부분’ 중에 character set에 대한 설명 또한 있었음
        - 역시 확인해봤으나 설정에 걸리는 부분이 없음

• 결론

  1. 함부로 DB 설정을 바꾸면 안되지만 시니어들과 상의 후, sql_mode를 껐음

     - DB 세팅의 base로 삼는 클라우드게이트에는 sql_mode가 설정돼 있지 않다는 점
     - TRADITIONAL로 세팅한 히스토리 및 사유를 아는 사람이 없다는 점
     - 버전 업그레이드 진행이 최우선 과제라는 점

     위 세 가지 주된 이유로 설정을 껐음

     2. 다만 현재까지 sql_mode와 로그 상 에러 메시지의 상관 관계를 몰라서 미해결 과제로 남겨두고 있다는 부분이 아쉬움

업그레이드 진행 (3/26(일) 오전 1:00)

작업 순서

1. 기존 서버들 binlog_format mixed로 변경, 재부팅
2. 블루그린 생성
3. 그린(버전업)을 prod로 스위칭
4. 기존 버전 삭제
   

작업 결과

• 현재까지 특별한 이슈 없이, 정상 작동해 프로젝트 종료

관련 내용

MySQL5.7 -> 8.0의 차이점은?

버그 발생 상황

• 쿼리에서 distinct, paging 작업을 하던 것을 java 단에서 처리하려고 수정

• 쿼리에서 데이터를 가져온 뒤, stream().distinct()까지만 진행된 채로 배포

  @Transactional(readOnly = true)
  public Page<Response> getHistories(List<Long> brandIds, String startDate, String endDate, PageRequest pageRequest) {
        List<MassMessageType> messageTypes = MassMessageType.getMassMessageTypeList(channelName);
        LocalDateTime startTime = DateUtils.convertKstToUtcStartLocalDateTime(startDate);
        LocalDateTime endTime = DateUtils.convertKstToUtcEndLocalDateTime(endDate);
  
        if (startTime.isAfter(endTime)) {
            throw BaseException.of(ApiErrorCode.BAD_REQUEST);
        }
  
        List<Response> histories = historyRepository.findHistory(brandIds, startTime, endTime, pageRequest)
                .stream()
                .distinct()
                .collect(Collectors.toList());
  
        Long count = historyRepository.findCountHistories(brandIds, startTime, endTime)
                .orElse(0L);
        return new PageImpl<>(histories, pageRequest, count);
    }

해결 방법을 찾던 중 내가 만난 이슈

• java단에서 페이징 처리를 추가하면 되는 것으로 판단
• distinct().limit(pageRequest.getPageSize()) 까지만 추가함
• 그러고 return new PageImpl<>(histories, pageRequest, count) 로 넘김

• 그랬더니 total Elements가 달라졌다!!

// 위는 생략
List<Response> histories = historyRepository.findHistory(brandIds, startTime, endTime, pageRequest)
                .stream()
                .distinct()
                .limit(pageRequest.getPageSize()) //여기만 추가
                .collect(Collectors.toList());

        Long count = historyRepository.findCountHistories(brandIds, startTime, endTime)
                .orElse(0L);

         // histories.size() = 15, count = 23
        return new PageImpl<>(histories, pageRequest, count);
        // return 되는 결과 값은 total Elements = 30으로 나왔다!!
    }

무엇이 total Elements를 부풀렸나?

내가 잘못한 것은 크게 두 가지였다.

1) PageRequest를 넘길 때 잘못 넘겼다.

• 포스트맨으로 디버깅하며, param 설정을 잘못 했다.
  • 1 page를 확인하려면 -1 처리해서 0으로 PageSize()를 세팅해줬어야 했다.
  • param을 1로 보냈으면 2 페이지를 조회하겠다는 뜻이 됐다.

    2) stream에서 skip(pageRequest.getOffSet())을 빼먹었다.

• 페이징 처리의 필수값인 skip()을 뺀 채로 stream이 돌다 보니, total 산출하는 로직에서 기대값과 다르게 나왔다.

skip()과 limit()

• skip() : 지정한 갯수만큼 '건너 뛰겠다'.
• limit() : 지정한 갯수만큼만 받겠다. 즉, 페이징할 때는 skip()은 이번 페이지에서 보여주기 위해 앞에서 몇 개를 건너뛸 것인지를 나타내고 limit()은 한 페이지에 표기할 데이터 개수를 뜻한다.

그래서 내가 작성했던 값과 코드의 의미는..

2 페이지(page = 1)에 표기될 값을 알고 싶지만 건너뛸 데이터는 없음. 처음부터 15개로 보여줘.

-> 그렇게 뽑힌 데이터가 total을 산출할 때 아래 로직을 타게 된다.

// content.size() = 15, total = 23
public PageImpl(List<T> content, Pageable pageable, long total) {

        super(content, pageable);

        this.total = pageable.toOptional().filter(it -> !content.isEmpty())//
                //            15 x 1 + 15 > 23 (true)
                .filter(it -> it.getOffset() + it.getPageSize() > total)// 
                //            15 + 15 = 30
                .map(it -> it.getOffset() + content.size())//
                .orElse(total);
    }// this.total = 30

이래서 total Elements가 자꾸 30이 나왔던 것이다!

해결방법

위의 무엇이 부풀렸는지를 고치면 해결 방법이 된다!

1) param 값을 내가 원하는 페이지에 -1 해준다 (1페이지 조회 = 0, 2페이지 조회 = 1 ...) 2) skip()을 추가해준다!

그래서 최종 수정한 값은..

// 코드 일부 생략
    List<Response> histories = historyRepository.findHistory(brandIds, startTime, endTime)
                    .stream()
                    .distinct()
                    .skip(pageRequest.getOffset())
                    .limit(pageRequest.getPageSize())
                    .collect(Collectors.toList());

    Long count = historyRepository.findCountHistories(brandIds, startTime, endTime)
                .orElse(0L);

    return new PageImpl<>(histories, pageRequest, count);
}

total이 왜! 뻥튀기 되는지 몰랐는데 드디어 이유를 알게 되서 속이 시원했다ㅎㅎ 그리고 이 기회에 total 산출하는 식을 좀 더 들여다 봐서 재밌었다.

기존 문제 상황

• 주차별 조회 ( = 주간 조회)를 했을 때의 표기에 대한 정확한 기준이 없었다.
• 기준이 없다보니 조회 방식에 따라 결과값이 다른, 즉 데이터 정합성의 문제가 있었다.

날짜와 시간을 다루는 부분이 의외로(?) 까다롭다는 얘길 들어서 도전해보고 싶었다. 자원해서 수정 작업에 들어갔다.

요구사항

• ISO 8601에 따라, N월 1일이 목요일보다 이전 요일에 있으면 그 주는 N월의 1주차 이다.

  • 위 이미지에서 22주차는 6월 1주차이다. (5월 5주차가 아니다)

• 하지만 대한민국의 달력은 주로 일요일부터 시작한다는 점에 따라, 한 주의 시작 요일은 일요일 이다.

  • ISO 8601은 월요일부터 시작이지만, 우리는 일요일을 시작 요일로 본다.

즉, 일요일부터 한 주를 시작하지만 특정 월의 첫 주를 결정짓는 것은 1일이 일 ~ 목 중에 있는지 여부이다.

+) ISO 8601과 월요일 시작의 차이

ISO 8601 국제 표준법

• 주수는 목요일을 카운트 해서 기술한다.
• 한 주의 시작 요일은 월요일이다.
• 월요일 ~ 일요일까지 중에서 1일이 목요일보다 이전 요일 (월 ~ 목)에 있으면, 한 주의 과반 이상이 N월에 속하기 때문에 N월 첫번째 주로 본다.
  • 즉, 6월 1일이 목요일이면 한 주 중 총 4일(목,금,토,일)이 6월이므로 6월의 1주차로 보는 것

미국식 표기법

• 한 주의 시작은 일요일이다.
• 첫 째주로 보기 위해서는 최소 하루만 있어도 된다.
  • 월보다는 Year로 바꿔서 생각하면 쉽다.
  • 2023년 1월 1일이 무슨 요일에 있던, 그 주는 2023년 1월 1주차로 카운트 한다.

해결 방법

description

• 주차별 조회할 때, WeekFields를 우리 기준에 맞게 재정의 했다.

  case WEEKLY:
    LocalDateTime dateTime = getWeekStartDay(dateDescription);
    // 한 주의 시작일을 일요일로 설정
    // 1일이 일 ~ 목요일 일 때 1일이 포함된 월의 첫 주로 설정하기 위해 최소 필요한 일수는 3일로 설정함
    TemporalField weekOfMonth = WeekFields.of(DayOfWeek.SUNDAY, 3).weekOfMonth();
  
    LocalDateTime thursday = dateTime.plusDays(4);
    int dayOfMonth = thursday.getDayOfMonth();
    int year = thursday.getYear();
    formatter = DateTimeFormatter.ofPattern("MM월 ");
    String thursdayMonth = thursday.format(formatter);
  
    int week;
    if(dayOfMonth < 6) {
        week = 1;
    } else {
        week = thursday.get(weekOfMonth);
    }
  
    return new StringBuilder().append(year)
        .append("년 ")
        .append(thursdayMonth)
        .append(week)
        .append("주차")
        .toString();

+) 참고로 ISO 8601은 WeekFields.of(DayOfWeek.MONDAY, 4) 이고 미국식은 WeekFields.of(DayOfWeek.SUNDAY, 1)이었다.

startDate, endDate 추출

• 프론트에서는 해당 연도의 주차를 String으로 넘기는 중이었다. (ex. 202322)
• 주차에서 startDate와 endDate를 아래 메소드를 통해서 뽑아 냈다.

  // KST 시작일자 뽑기
  public static LocalDateTime getWeekStartDay(String yyyyuu) {
    int year = Integer.parseInt(yyyyuu.substring(0,4));
    // 그 해의 몇 일째인지 (2023년 56일째 || 2023년 300일째)
    int day = Integer.parseInt(yyyyuu.substring(4)) == 0 ? 1 : Integer.parseInt(yyyyuu.substring(4)) * 7;
    LocalDate ld = LocalDate.ofYearDay(year, day);
    // 월요일 == 1, 일요일 == 7
    int turn = ld.getDayOfWeek().getValue() == 7 ? 0 : ld.getDayOfWeek().getValue();
    // DayofWeek는 월요일이 한 주의 시작이므로 뒤집어 줌(일요일을 시작일이 되게)
    return ld.minusDays(turn).atTime(0,0,0);
  }
  

// KST 종료일자 뽑기 public static LocalDateTime getWeekEndDay(String yyyyuu) { int year = Integer.parseInt(yyyyuu.substring(0,4)); int day = Integer.parseInt(yyyyuu.substring(4)) == 0 ? 1 : Integer.parseInt(yyyyuu.substring(4)) * 7; LocalDate ld = LocalDate.ofYearDay(year, day); int turn = ld.getDayOfWeek().getValue() == 7 ? 0 : ld.getDayOfWeek().getValue(); // 종료일자는 토요일이 되도록 뽑아야 하므로 plus 해줌 return ld.plusDays(6-turn).atTime(23,59, 59); }

* 202322 (2023년 22주차)를 startDate Param으로 받았을 때
    - LocalDate ld = 2023-05-29 (월)
    -> `ld.minusDays(1).atTime(0,0,0) == 2023 05 28 00:00:00`


* 202322 (2023년 22주차)를 endDate Param으로 받았을 때
    - LocalDate ld = 2023-05-29 (월)
    -> `ld.plusDate(6-1).atTime(23,59,59) == 2023 06 03 23:59:59`


## 또 다른 이슈, Elastic Search
우리는 ES에서 조회해오고, 네트워크 이슈 등으로 ES 조회 실패할 때만 DB에서 쿼리하도록 돼 있다.
ES에서 조회할 때 시작일/종료일에 맞게 결과가 안 나오는 상태였다.

Date histogram aggregation이 `Calendar intervals week (1w)로 설정`돼 있었고,
`ES는 별도 설정이 없다면 월요일이 한 주의 시작`이었기 때문에 start,endDate는 의미가 없었다.

### 해결 해야할 이슈 
* 지정한 startDate, endDate에 맞게 주 단위의 데이터를 조회해오기
* 한 주의 시작은 일요일이고, 종료 요일은 토요일일 것

### 해결 방법
* `offSet : -1d` 를 주니 해결됐다.
출처 : https://discuss.elastic.co/t/how-to-make-weekday-start-on-sunday-in-date-histogram-aggregation/85621

다만 offSet은 주차별 조회할 때만 적용돼야 하기 때문에 아래처럼 분기문을 태웠다.
```java
private String getOffSetData(StatisticsDateType dateType) {
    // ES 조회 시, 일요일을 주의 시작점으로 잡기 위해 설정
    if(StatisticsDateType.WEEKLY.equals(dateType)) {
        return DateHistogramInterval.days(-1).toString();
    } else {
        return "0";
    }
}

offSet을 적용하기 전에 calendar intervals 를 fixed intervals로 변경해보기도 하고, 주 단위를 -7d로 검색하도록 해보기도 했으나 방법이 아니었다. +) fixed intervals 관련 공식 문서 : https://www.elastic.co/guide/en/elasticsearch/reference/7.15/search-aggregations-bucket-datehistogram-aggregation.html#fixed_intervals

ES에서 Date histogram aggregation 포함 aggregation 쪽도 공부해볼 부분이 많은 곳이라 기회가 된다면 포스팅 해보려고 한다.

배포가 나간 뒤..

2022년 12월 마지막 주로도 검색해보고, 과거 일자로 조회 해보고 다양하게 조회해봐도 이슈 없이 현재까지 정상 조회 돼서 뿌듯했다.

날짜, 특히 주차별 조회 이슈를 해결하면서 공식 문서들을 뒤져보고 공부한 게 든든한 자산이 될 것 같다.

하지만 뜻대로 되지 않아 의외로 시간을 많이 쏟았고 원인은 다음 세 가지였다.

1. yml 혹은 properties에 작성된 값을 어떻게 바인딩해야 할 지 몰랐음
2. 각 설정 단계에 대한 이해 부족
3. 구글의 보안 관련 정책 변경

실질적으로 세팅하는 방법은 다른 포스팅에 적어두려고 한다. 이번엔 시간을 많이 쓴 원인과 알게된 것들을 정리하고자 한다.

1. yml 혹은 properties의 바인딩

가장 근본적인 원인이었다. application.properties에 smtp 관련 값을 추가해두고 바인딩이 안 되는 것을 모른 채 테스트를 진행했다.

우선 yaml과 properties는 다음과 같은 차이점이 있다.

properties

• key-value 구조

yaml

• 계층적 구조
• prefix 중복 제거 가능

어떤 형식을 쓸 것인지는 취향 차이인 것 같다.

작성된 데이터 바인딩 방법

부끄럽게도 아래 이미지처럼 세팅해두면 자동으로(?) MailProperties에 바인딩되는 줄 알았다...!

모든 과정을 디버깅 찍어가면서 확인하다가 알게된 것이 저렇게만 둔다고 알아서 주입되는 것이 아니라는 점이었다.

방법은 아래와 같다.

1) @Value

@Getter
@Setter
@Component
public final class MailProperties {

    // SMTP 서버
    @Value("${spring.mail.host}")
    private String host;

    // 계정
    @Value("${spring.mail.username}")
    private String username;

}

이렇게 필드값마다 어노테이션을 달아주고, Placeholder나 SpEL을 명시해주는 방식이다. 다만, 객체가 생성된 후에 주입이 되기 때문에 객체 생성자가 실행되는 시점에선 @Value 값이 null이 되므로 주의할 필요가 있다.

2) @ConfigurationProperties

@Getter
@Setter
@Configuration
@ConfigurationProperties("mail")
public final class MailProperties {

    // SMTP 서버
    private String host;

    // 계정
    private String username;

    //smtp
    private Properties properties;

    @Getter
    @Setter
    public static class Properties {
        private Smtp smtp;

        @Getter
        @Setter
        public static class Smtp {
            private boolean auth;

        }

    }

}

이런 방식으로 정의한다. prefix를 적어줘야하며, inner class를 사용하게 되는 경우 이름을 똑같이 일치 시켜야 한다. 또, setter를 반드시 정의해줘야 한다. @Value보다 간결하고, inner class 사용 시 좀 더 간편하다는 장점이 있다.

3) @ConstructorBinding

spring boot 2.2부터는 @ConfigurationProperties가 달린 클래스를 변경 불가능하도록 @ConstructorBinding을 쓸 수 있게 됐다. 그래서 final 필드에 대해 값을 주입해준다.

@Getter
@RequiredArgsConstructor
@ConfigurationProperties("mail")
public final class MailProperties {

    // SMTP 서버
    private final String host;

    // 계정
    private final String username;

    //smtp
    private final Properties properties;

    @Getter
    @RequiredArgsConstructor
    public static final class Properties {
        private final Smtp smtp;

        @Getter
        @RequiredArgsConstructor
        public static final class Smtp {
            private final boolean auth;

        }

    }

}

이 방식은 MailProperties 클래스에 직접적으로 bean을 만들어주지 않는다. 따라서 @EnableConfigurartionProperties를 이용해서 클래스 타입을 명시해줘야한다.

프로젝트에는 @Value 방식을 썼다.

1) 대규모 프로젝트가 아니기에 yml 파일이 여러 개 생성되지 않는다는 점 2) 메일 관련 설정을 MailProperties 외에 다른 클래스에서 산발적으로 호출하지 않는다는 점 3) 세팅에 좀 더 많은 시간을 쓸 수 없었다는 점

을 이유로 그렇게 사용했다.

프로젝트 마무리 시점에 시간적 여유가 된다면 @Value 외에 다른 방식으로 바인딩하게 변경해보고 싶다.

+) 3번 시간 이슈에 대해 좀 더 설명하자면 @ConfigurationProperties를 쓰려고 설정했지만 주입이 안 됐다. @EnableConfigurartionProperties 도 달아줬으나 안 돼 해결하고 싶었다. 하지만 혼자하는 프로젝트가 아니어서 다른 팀원들이 merge를 기다리고 있는 상황이라 우선 @Value로 마무리 지었다.

2. 각 설정 단계에 대한 이해 부족

참고한 블로그 글들, 회사 소스들 모두 방식은 각자에 맞게 했지만 원리는 동일했다. 하지만 각 단계별로 왜 이렇게 세팅 하는지를 이해하지 못하고 베끼다보니 원인 파악도 느렸다.

결국 각 단계별로 필요한 설정 순서는 아래와 같다.

1) .yml 혹은 .properties에 필요한 설정 값을 넣어준다 2) MailProperties에 값을 매핑해준다 3) MailConfig에 javaMailService 메소드를 @Bean 등록 해준다 3-1) javaMailService 메소드 내 JavaMailSender 객체를 생성하고, 설정값을 set해준다 3-2) Properties 객체에 smtp.auth, starttls 등도 put 해준다 3-3) javaMailSender에 session도 세팅해준다 4) password 보안 때문에 Authenticator를 상속받아 MailAuthenticator를 만들어준다 5) PasswordAuthentication 객체를 재정의 해준다

각 순서에 대해 전체적인 그림을 그리고, 현재 어떤 단계에 있는지를 생각하면서 코드를 작성했으면 문제가 발생하는 위치를 빠르게 잡을 수 있지 않았을까 싶다.

3. 구글 정책 변경

대다수의 블로그를 보면, 메일 발송이 안되면 '보안수준이 낮은 앱의 액세스 허용'을 해주라고 나온다. 하지만 구글 정책상 이 허용값 설정 자체가 불가능하게 바뀌었다.

그러다가 발견한 stackOverflow 글. 친절하게 캡쳐를 첨부해 설명해줘서 이해하고 해결했다.

링크 : https://stackoverflow.com/questions/72930539/javax-mail-authenticationfailedexception-535-5-7-8-username-and-password-not-ac

작업을 해보며..

회고 아닌 회고글이 됐지만 이번 작업으로 느낀 점이 많았다.

첫째는 이미 선배 개발자들이 세팅해둔 회사 소스를 눈으로 보는 것보다 내가 직접 설정하면서 겪어야 부족한 부분을 뼈저리게 느낀다는 것이다. 두 번째는 기본기를 확실하게 다져야 하고, 구멍이 숭숭 나 있다는 것이었다.

이렇게 느끼기 위해서 사이드 프로젝트를 시작했는데 역시나 하길 잘 했다. 앞으로 배우고 느낄 게 많아서 행복하다.

필요했던 케이스

- paging 조회 시, 클라이언트가 설정한 정렬 조건 대로 내려줘야 했다.
- 정렬 조건은 가입일 (id가 순서를 보장하지 않는 케이스), 이름 (국영숫), 나이 등의 오름 || 내림차순

OrderSpecifier란?

• 공식 문서 : http://querydsl.com/static/querydsl/4.0.7/apidocs/com/querydsl/core/types/OrderSpecifier.html
• Querydsl 에서 동적 sorting을 위해 필요한 클래스

활용 예제

    private OrderSpecifier getOrderCondition(AccountsSortType accountsSortType,  
      boolean ascending, QAccounts accounts) {  
       switch (accountsSortType) {  
          case JOIN_DATE:  
             return ascending ? accounts.joinDate.asc(): accounts.joinDate.desc();  
          case NAME:  
             return ascending ? accounts.name.asc() : accounts.name.desc();  
          case LAST_LOGIN:  
             return ascending ? accounts.lastLoginDate.asc()  
                   : accounts.lastLoginDate.desc();  
          default:  
             return null;  
       }  
}

• 케이스별로 sorting을 진행할 수 있게 구현함

5.7 버전에 비해 개선된 점

1. IO 바운드 읽기 전용 -> 내림차순 인덱스를 지원하면서 읽기 성능에서 크게 개선됨

2. 읽기, 쓰기의 개선(update No key)

3. 이중 쓰기 버퍼, IO 바인딩 읽기 쓰기

8.0 버전의 변경 사항

• 기본 인증 플러그인으로 'caching_sha2_password' 사용
  • sha256_password 사용 불가
• 자체 파티셔닝 핸들러 제공

호환되지 않아 사전에 점검해야할 부분

• 사용되지 않는 데이터 형식이나 함수를 사용하는 테이블이 없어야 함

• orphan ~.frm파일이 없어야 함

• 기본 파티셔닝 지원이 없는 스토리지 엔진을 사용하는 분할된 테이블이 없어야 함

• 255자 또는 1020바이트 길이를 초과하는 개별 ENUM 또는 SET 열 요소가 있는 테이블이나 저장 프로시저가 없어야 함

• MySQL 8.0.13 이상으로 업그레이드하기 전에 공유 InnoDB 테이블스페이스에 있는 테이블 파티션이 없어야 함

• ASC 절에 사용하는 DESC 또는 GROUP BY 한정자를 사용하는 MySQL 8.0.12 이하의 쿼리 및 저장 프로그램 정의가 없어야 함

• 64자를 초과하는 외래 키 제약 조건 이름이 없어야 함

• utf8mb3 -> utf8mb4 charset을 사용하도록 변환 필요

출처 (MySQL 공식 문서)

• 5.7 버전에 비해 개선된 점
• 8.0의 변경 사항
• MySQL 8.0의 새 기능