KIM_TABLE_NEXT

Scanner vs BufferedReader

Mon, 26 Aug 2024 02:55:39 GMT

오랜만에 알고리즘 문제를 다시 풀기 시작하면서 플랫폼을 변경하였다. (프로그래머스 -> 백준)

변경하게 되면서 문제의 입력값을 직접 처리해야하는 과정이 추가되었다.

프로그래머스(따로 입력처리를 하지 않아도됨)

백준(깔-끔)

그렇게 되면서 이에 대해 알아본 결과 주로 두가지 방법으로 입력값을 받는것 같다.

Scanner

Scanner 클래스는 입력받은 데이터(바이트)를 다양한 타입으로 변환하여 반환하는 클래스이다. 간단하게 기본형과 String 타입을 정규표현식을 사용해 파싱(parse)할 수 있다.

Scanner의 특징

java.util 패키지에 속한다. (java.util.Scanner) 공백(띄어쓰기) 및 개행(줄 바꿈)을 기준으로 읽는다.(' ', '\t', '\r', '\n' 등)

원하는 타입으로 읽을 수 있다.
버퍼의 사이즈가 1024byte(1KB) 이다.
UnChecked(Runtime) Exception으로 별도로 예외 처리를 명시할 필요가 없다.
Thread unsafe 성질을 지니기에 멀티스레드 환경에서 문제가 발생할 수 있다.
데이터를 입력받을 경우 즉시 사용자에게 전송되며 입력받을 때마다 전송되어야 하기에 많은 시간이 소요된다.

Scanner 예시

import java.util.Scanner;
...
Scanner sc = new Scanner(System.in);
String st = sc.nextLine();

위와 같이 System.in을 통해 Scanner 객체를 생성한다.

### System.in이란?
>사용자로부터 입력을 받기 위한 입력 스트림이다.
Scanner 클래스뿐 아니라 다른 입력 클래스들도 System.in을 통해 사용자 입력을 받아야 한다.

# BufferedReader
>데이터를 한번에 읽어와 버퍼에 보관한 후 버퍼에서 데이터를 읽어오는 방식으로 동작하는 클래스이다. 즉 사용자가 입력한 문자 스트림을 읽는 것(read) 라고 한다.

## 여기서 버퍼(buffer)란?
>데이터를 한 곳에서 다른 한 곳으로 전송하는 동안 일시적으로 해당 데이터를 보관하는 임시 메모리 영역이다. 주로 입출력 속도 향상을 위해 버퍼를 사용한다.
자바에서는 버퍼를 BufferedReader와 BufferedWriter라는 클래스를 제공하여 다룰 수 있다.

## BufferedReader의 특징
>- java.io 패키지에 속한다. (import java.io.BufferedReader)
- 데이터를 파싱하지 않고 String으로만 읽고 가져온다.
- 버퍼의 사이즈가 8192byte(8KB)이다.
- Checked Exception으로 반드시 예외 처리를 명시해야한다.(I/O Exception을 throw하거나 try/catch 해야한다.)
- Thread safe 성질을 지니기에 멀티스레드 환경에서도 안전하다.
- 버퍼가 가득차거나 개행문자가 나타나면 버퍼의 내용을 한번에 프로그램으로 전달하기에 Scanner보다 소요되는 시간을 절약할 수 있다.

## BufferedReader 예시
>```java
import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.io.IOException;
...
public static void main(String[] args) throws IOException {
  BufferReader br = new BufferedReader(InputStreamReader(System.in));
  String st = br.readLine();
  int a = Integer.parseInt(br.readLine());
  int b = Integer.parseInt(st);
}

위와 같이 BufferedReader는 매개변수로 InputStreamReader를 사용하여 객체를 생성한다. 또한 패키지의 경우 java.io 하위의 BufferedReader, InputStreamReader 와 예외처리를 위한 IOException 를 사용하며 모두 간단히 java.io.* 로 모두 포함할 수 있다.

InputStreamReader 란?

문자 기반의 보조 스트림으로써 바이트 기반 스트림을 문자 기반 스트림으로 연결시켜 주는 역할을 한다.

Scanner Vs BufferedReader

Scanner는 BufferedReader보다 타입에 구애받지 않는다.

BufferedReader는 String 형식으로만 읽고 저장하기에 형변환을 위한 추가적인 코드 작성이 불가피한 반면에 Scanner는 원하는 타입으로 읽고 파싱할 수 있다. Scanner의 경우 int, long, short, float, double의 경우 nextInt(),nextLong(),nextShort(),nextFloat(), nextDouble()과 같은 함수들을 사용할 수 있다. 그런데 BufferedReader는 readLine() 함수만을 사용한다.

BufferedReader는 Scanner보다 효율적인 메모리 용량을 가진다.

BufferedReader의 버퍼 메모리가 8KB로 Scanner의 버퍼 메모리 1KB보다 크기에 많은 입력이 있을 경우 더 효율적이다. 다만, BufferedReader의 경우 일단 큰 메모리를 잡아먹게 된다.

BufferedReader는 Scanner보다 안전하다.

Scanner는 Thread-unsafe 하기에 멀티스레드 환경에서 안전하지 않지만 BufferedReader는 안전하다. 스레드 간 Scanner는 공유할 수 없지만 BufferedReader는 공유할 수 있다.- 동기화를 지원하는 BufferedReader는 싱글스레드인 Scanner보다 약간 느린데, Scanner의 경우 정규식을 사용하여 입력을 받으므로 BufferedReader가 문자열을 더욱 빠르게 입력받을 수 있다.

BufferedReader가 Scanner보다 실행 속도가 빠르다.

백준에서 작성된 입력속도 비교표를 확인해보면 BufferedReader는 0.68585초, Scanner는 4.8448초가 소요되며 둘의 시간차이가 생각보다 크다. 왜 빠를까? 여기선 CPU를 고려해야 하는데 문자가 입력될 때마다 CPU가 하나하나 입출력을 하는 것보다 버퍼에 어느정도 쌓아두고 가득차거나 개행이 일어날 때마다 입출력을 처리하는 것이 훨씬 효율적이다.

결론

찾아보며 느낀점은 Scanner가 BufferedReader에 비해 조금 더 편리하지만, 메모리와 시간을 더 많이 잡아먹는다는 느낌을 받았다. 최적화를 위해서 BufferedReader를 사용하는쪽으로 해야겠다.

Project - 최종프로젝트 회고(+앞으로의 계획)

Tue, 04 Jun 2024 16:21:11 GMT

프로젝트 소개

>>프로젝트 소개 링크<< 다른 프로젝트들과 다르게 최종프로젝트인 만큼 노션에 아주 예쁘게 프로젝트 소개를 정리하였다.

수상내역

내부 투표에서 무려 50%가 넘는 득표율로 우수 프로젝트 상을 받게되었다. 사실 예상도 못했는데,매우 기분이 좋았다. 상품으로 스프링 로고 키캡을 받았다. 나중에 취업하게되면 회사에서 사용하려고 고이 모셔두고 있다!

회고

최종프로젝트가 끝이났다. 참 많은영역에 대해 도전하였고, 처음 목표였던,
후회없는 프로젝트 하기
성공한것 같다.
사실 프로젝트가 끝난지 한달가량 지났다. 공백기 동안 졸업문제를 해결하고자 TOPCIT 시험을 응시하였고, 결과는 6월 17일에 나온다. 그리고 토익스피킹 시험도 응시하였다. 결과는 6월 7일에 나온다.
두 시험 결과가 졸업 요건에 충족했으면 한다. 그리고 이제는 7월중에 있는 정보처리기사 시험을 준비하려고 한다.
부트캠프에서 실무 역량을 키웠다. 이제는 지식을 조금 쌓아보고싶어서 정보처리기사 시험을 준비하면서 코딩테스트, 면접등 준비해보려고 한다!!

Spring - 테스트코드 심화편 (Mock, Stub)

Tue, 23 Apr 2024 06:29:02 GMT

TIL

최종프로젝트 28일차, 이제 슬슬 마무리 단계에 돌입했다.

테스트 코드 작성을 맡으면서 만난 문제와 해결을 하여서 기록하려고 한다.

@Mock 객체와 가설(Stub) 세우기

Mock 객체는 가짜로 등록되는 객체이기 때문에 해당 객체를 이용하여 하는 모든것에 대해 미리 결과를 정의해줘야한다.
위 코드에서도 60번째 줄에 categoryRepository.save가 TEST_CATEGORY1을 반환할 것이다라고 미리 정의해줬다.
- any()는 "어떤게 들어오던" 같은 의미이며, 조금 더 세분화 하여 anyString(), anyList()등등 형식을 지정할 수 있다.
가설을 세워 줬다면, 테스트 하려는 부분을 실행하고, verify와 assertEquals등으로 검증한다.
- 위의 코드에서는 verify를 통해 categoryRepository에 save가 1번일어났는지 검사하고,
- 결과값과 요청값을 비교하였다.
테스트코드의 전반적인 구성인 이렇게 된다. (가설설정 -> 테스트 -> 검증)

가설(Stub) 세우면서 만난 문제들

테스트코드의 전반적인 구성을 알아보았고, 다음은 구성중 하나인 가설을 설정하는 부분에서 만난 문제들이다.

전반적으로 새롭게 알게된 중요한 점은 이거였다.
가설 설정에는 가설 순서도 영향을 미친다.

UnnecessaryStubbingException

가설을 세웠지만 사용하지 않는 가설일 경우 발생하는 에러이다.
처음에는 가설을 Mock 객체가 채워주지 못하는 부분을 설정해주는 것이라고만 생각했는데, 생각보다 빡세게 적용되었다. (기본 설정이 strict stubbing)
해결 방법으로는 두가지가 있다.
- 1. 사용하지 않는 가설을 제거한다.
- 1. Loose stubbing으로 변경한다. (lenient)

Loose Stubbing (lenient)

63번째 코드처럼 Mockito.lenient.when(가설 상황).thenReturn(반환값)처럼 코드를 작성하면, 가설이 필요하면 사용하고, 필요없다면 그냥 넘어간다. (Loose stubbing)

RedisTemplate NullPointerException

테스트를 하려는 입찰 관련 코드에는 RedisTemplate.opsForValue().get()을 통해 값을 가져오는 부분이 있다.
그래서 이 부분도 가설을 설정해주었는데, 에러가 발생했다.
NullPointerException이 발생하였다. 원인은 RedisTemplate.opsForValue().get()을 하기 위해서는 RedisTemplate.opsForValue()값이 있어야 하는데 이부분이 Null이어서 발생했다.
그래서 위 코드처럼 RedisTemplate.opsForValue()값을 가설로 세워주어 해결했다고 생각했는데, 테스트를 시행할때마다 전부 통과하거나, 일부만 통과하는 증상이 생겼다.
전혀 이해가 되지 않는 상황이어서 원인이 뭘까 정말 많은 시행착오를 겪었다..
- 모두 동일한 가설에서 결과비교만 다르게 구현해놓았는데 일부만 통과했었다. (심지어 매번 통과하는 테스트가 달라짐)
찾아낸 원인이 확실하진 않지만, 전에 블로그를 찾아보다가 GitActions의 Redis 설정에 대해 찾아보고 적용해놓은 적이 있었는데, 이를 제거했더니 해결되었다. Embedded-redis 블로그
gradle에서 embedded-redis를 제거했더니 해결되었다. 아무래도 이게 원인이 아니었을까..
개인적으로 코딩을 시작한 이후 가장 이해가 되지 않는 오류였다.

테스트 결과

구현한 28개의 테스트 모두 통과하는것을 확인하며 매우 희열을 느꼈다.
테스트 결과를 보기 좋게 묶는 방법도 찾아보고 적용하였다.
@TestClassOrder(ClassOrderer.OrderAnnotation.class)를 통해 @Nested클래스들의 순서를 적용하고,
@Nested클래스에는 @TestMethodOrder(MethodOrderer.OrderAnnotation.class)를 통해 테스트들의 순서를 적용해주었다.
한가지 아쉬운점은 @Nested클래스에 @DisplayName을 통해 숫자도 같이 작성했는데, 숫자는 적용이 되지 않는다고 한다.
GithubActions를 통해 CI를 하기위해 test.yml도 작성해주었다.
성공적으로 테스트가 완료되었는데, 한가지 아쉬운점이 있었다.
Task: test에 테스트 몇개 중 몇개가 통과했는지가 나오지 않았다. (실패하면 몇개중 몇개 실패했는지는 나옴)

그래서 인터넷을 찾아본 결과 테스트 결과를 출력하는 방법을 찾아서 적용해보았다.

tasks.named('test'){
  useJUnitPlatform()
  testLogging {
      afterSuite { testDescriptor, testResult ->
          if (testDescriptor.parent == null) {
              println "Results: ${testResult.resultType} (${testResult.testCount} tests, ${testResult.successfulTestCount} successes, ${testResult.failedTestCount} failures, ${testResult.skippedTestCount} skipped)"
          }
      }
  }
}

build.gradle에 해당 코드를 추가하면 끝이다!
테스트 결과와 몇개의 테스트중 몇개를 통과했는지 잘 나온다!

오늘의 회고

테스트 코드를 작성하면서 프로젝트 전반적인 모든 코드들에 대해 이해할 수 있어서 좋은 경험이었다. 다만 작성하면서 든 생각은 코드를 먼저 구현하고 테스트 코드를 구현하다보니 이미 구현된 코드에 테스트코드를 맞추는 느낌이 조금 들었다. TDD(테스트코드 기반 개발방법)도 기회가 된다면 시도 해보는것도 좋을 것 같다. 진짜 지금 생각해도 NullPointerException문제는 정말 이해가 되지 않는다.. 어떻게 빌드할때마다 결과가 다르게 나올 수 있었을까 일단은 기존 Redis와 Embedded-Redis간의 충돌로 그렇지 않았을까 라는 결론을 내렸다. 이제 테스트 코드 작성도 끝났고, 배포와 발표만 남은 상황이다. 끝까지 최선을 다해야겠다!

Spring - @ModelAttribute, Paging 캐싱

Tue, 16 Apr 2024 12:04:21 GMT

TIL

최종프로젝트 21일차, 중간발표도 있었고 많은게 지나갔다.

프로젝트를 진행하면서 몇가지 문제와 해결을 하여서 기록하려고 한다.

Controller 청소하기

Paging을 구현하면서 인자로 받을게 많아졌다. 페이지번호, 사이즈, 정렬기준, 정렬방향 + 검색어, 카테고리, 상태

그렇다 보니 Controller의 함수가 상당히 지저분해졌다.
이런느낌이었다.. 위 사진에 @RequestBody로 검색어, 카테고리, 상태를 받는 상황이었다.
다른 웹서비스를 참고해보았는데, 검색어, 카테고리, 상태등 검색옵션또한 URL에 포함하여 요청을 보내는것을 확인했다.
이런 느낌으로 @RequestParam이 7개가 되는 상황이 발생하였다.
이대로는 너무 지저분한것 같아서 방법을 찾다가 @ModelAttribute를 알게 되었다.

@ModelAttribute

@ModelAttribute는 클라이언트로부터 일반 HTTP 요청 파라미터나 multipart/form-data 형태의 파라미터를 받아 객체로 사용하고 싶을 때 이용된다.

@ModelAttribute는 "가장 적절한" 생성자를 찾아 객체를 생성 및 초기화한다.
객체 생성 및 초기화 > Data Binding > Validation 순서로 진행된다.
- Data Binding은 getter/setter가 존재하는 변수에 한해서 이루어진다.
@ModelAttribute를 사용해서 이렇게 깔끔해졌다.
- 제목, 카테고리, 상태는 SearchRequest를 통해 받고, 나머지는 Pageable을 통해 받았다.

이미지 업로드

프로젝트에 이미지를 업로드 하는 부분도 있는데, 과연 이미지는 Controller에서 어떻게 받아야할까 찾아보았다.

MultipartFile로 받으면 된다!

Paging 캐싱 처리하기

지난번 글에서 캐싱처리에서 직렬화, 역직렬화가 무엇인지 다루었다.

Paging을 캐싱처리하던도중 오류가 발생하였는데, 찾아보니 PageImpl이 기본생성자를 갖고있지 않아서 직렬화가 불가능해서 발생한 오류인것으로 파악했다.
그래서 PageIm 를 상속받는 RestPage 를 만들었다. 만들면서 직렬화도 가능하게 생성자도 만들어주었다.

오늘의 회고

중간 발표가 끝났다. 발표를 굉장히 잘했다고 칭찬받아서 기분이 매우 좋다. 특히, 프로젝트 아키텍처에 대해서 극찬을 받아서 매우매우 기분이 좋다. 이제 남은건 유저테스트와 최종발표인데, 생각보다 시간이 참 빠른것 같다. 남은 기간도 최선을 다해서 성공적은 프로젝트가 되도록 노력해야겠다.

Spring - 간편결제 API(TossPayments) 적용하기

Tue, 09 Apr 2024 12:01:48 GMT

TIL

TossPayments 적용하기

최종프로젝트 15일차, 오늘은 경매가 끝나고 수행되는 결제 시스템을 구현하였다.

결제 API로 TossPayments를 적용하였다.

TossPayments 결제 흐름도

1. Client는 Toss에게 결제 요청을 한다.
- 결제 요청에는 clientKey, orderId(주문번호), amount(가격)등을 포함한다.
- 결제 요청은 URL을 통해 이루어지지 않고, Toss의 결제 SDK를 통해 이루어진다.
1. Toss는 결제 요청에 대한 인가코드(paymentKey)와 orderId, amount등을 Client에게 반환한다.
1. Client는 Toss에게 반환받은 paymentKey, orderId, amount를 서버에 전달한다.
1. 서버는 Client에게 받은 paymentKey, orderId, amount를 통해 Toss에게 결제 승인 요청을 한다.
1. Toss는 서버에게 결제 승인 정보(TossPayment) 반환한다.
1. 서버는 Toss에게 반환받은 결제 승인 정보를 DB에 저장하고, Client에게 반환해준다.
결제과정의 전체적인 흐름은 이와 같다. 이제 단계별로 코드로 구현해보자.

1. Client의 결제 요청, Toss의 인가코드 반환

프론트엔드에 대한 지식은 많이 부족하지만, 최종프로젝트의 프론트엔드가 React로 구성되기에, React기준으로 설명하려고 한다.

🖥️ SDK 준비 및 요청

#설치 커맨드
npm install @tosspayments/payment-sdk --save

설치가 완료되었다면 컴포넌트에 아래와 같이 import를 해주고, loadTossPayments()를 통해 UI 및 결체요청을 진행하면된다.

import { loadTossPayments } from "@tosspayments/payment-sdk";
>
//페이호출 메소드
const handlePayment = (subject) => {
const random = new Date().getTime() + Math.random(); //난수생성
const randomId = btoa(random); //난수를 btoa(base64)로 인코딩한 orderID
>
if (subject === "카드") { //간편결제 함수 실행
  loadTossPayments(client_id).then(tossPayments => {
    tossPayments.requestPayment(subject, {
      amount: reserv.amount, //주문가격
      orderId: `${randomId}`, //문자열 처리를 위한 ``사용
      orderName: orderName(), //결제 이름(여러건일 경우 복수처리)
      customerName: '테스트', //판매자, 판매처 이름
      successUrl: process.env.REACT_APP_TOSS_SUCCESS,
      failUrl: process.env.REACT_APP_TOSS_FAIL,
    })
  });
}
}

🖥️ RedirectUrl

https://{ORIGIN}/success?paymentKey={PAYMENT_KEY}&orderId={ORDER_ID}&amount={AMOUNT}

해당 코드로 결제요청을 하면, Toss API에서 paymentKey, orderId, amount를 포함하여 RedirectUrl의 파라미터로 전달해준다. 이때 해당 정보를 포함하는 객체를 생성하여 Spring 서버로 요청을하는 것이다.

2. 서버의 결제 승인 요청, Toss의 결제 승인 정보 반환

서버는 Client로 부터 받은 paymentKey, orderId, amount를 통해 Toss에게 결제 승인 요청을 한다.

curl --request POST \
  --url https://api.tosspayments.com/v1/payments/confirm \
  --header 'Authorization: Basic dGVzdF9za196WExrS0V5cE5BcldtbzUwblgzbG1lYXhZRzVSOg==' \
  --header 'Content-Type: application/json' \
  --data '{"paymentKey":"5zJ4xY7m0kODnyRpQWGrN2xqGlNvLrKwv1M9ENjbeoPaZdL6","orderId":"a4CWyWY5m89PNh7xJwhk1","amount":15000}'

나는 다음과 같이 구현하였다.
Toss에게 결제 승인 요청을 하고, 반환받은 결제 승인 정보를 TossPayment 객체에 저장하여 기존 결제 테이블을 업데이트 하고, 업데이트 된 결제 정보를 반환해주도록 구현하였다.

Toss가 반환해주는 결제 승인 정보의 예시는 다음과 같다. (엄청나게 많다)

{
"mId": "tosspayments",
"lastTransactionKey": "9C62B18EEF0DE3EB7F4422EB6D14BC6E",
"paymentKey": "5EnNZRJGvaBX7zk2yd8ydw26XvwXkLrx9POLqKQjmAw4b0e1",
"orderId": "MC4wODU4ODQwMzg4NDk0",
"orderName": "토스 티셔츠 외 2건",
"taxExemptionAmount": 0,
"status": "DONE",
"requestedAt": "2024-02-13T12:17:57+09:00",
"approvedAt": "2024-02-13T12:18:14+09:00",
"useEscrow": false,
"cultureExpense": false,
"card": {
  "issuerCode": "71",
  "acquirerCode": "71",
  "number": "12345678****000*",
  "installmentPlanMonths": 0,
  "isInterestFree": false,
  "interestPayer": null,
  "approveNo": "00000000",
  "useCardPoint": false,
  "cardType": "신용",
  "ownerType": "개인",
  "acquireStatus": "READY",
  "receiptUrl": "https://dashboard.tosspayments.com/receipt/redirection?transactionId=tviva20240213121757MvuS8&ref=PX",
  "amount": 1000
},
"virtualAccount": null,
"transfer": null,
"mobilePhone": null,
"giftCertificate": null,
"cashReceipt": null,
"cashReceipts": null,
"discount": null,
"cancels": null,
"secret": null,
"type": "NORMAL",
"easyPay": {
  "provider": "토스페이",
  "amount": 0,
  "discountAmount": 0
},
"easyPayAmount": 0,
"easyPayDiscountAmount": 0,
"country": "KR",
"failure": null,
"isPartialCancelable": true,
"receipt": {
  "url": "https://dashboard.tosspayments.com/receipt/redirection?transactionId=tviva20240213121757MvuS8&ref=PX"
},
"checkout": {
  "url": "https://api.tosspayments.com/v1/payments/5EnNZRJGvaBX7zk2yd8ydw26XvwXkLrx9POLqKQjmAw4b0e1/checkout"
},
"currency": "KRW",
"totalAmount": 1000,
"balanceAmount": 1000,
"suppliedAmount": 909,
"vat": 91,
"taxFreeAmount": 0,
"method": "카드",
"version": "2022-11-16"
}

Toss payments API 프론트없이 테스트하기

테스트중 발생한 문제 (프론트의 부재)

이제 API 잘 작동하는지 테스트를 해봐야 한다.

다행히도 토스 payments에서 API 테스트 기능을 제공했다. API 테스트
그런데 한가지 문제에 직면했다.
아무리 찾아봐도 paymentKey를 생성하는 테스트가 없었다.
한마디로 Client와 Toss간의 테스트가 없었다.
사실 서버측에서 결제 승인 요청을 보내는 테스트는 토스에서 지원해주는 API테스트 툴을 사용하지 않고, 내가 구현한 코드가 잘 작동하는지 테스트해야 했다.
내가 구현한 코드를 테스트하는건 Client가 서버에 요청하듯 Postman을 통해 테스트하면 되는데, 문제는 테스트에 필요한 인가코드(paymentKey)를 생성 할 수 없다는 것이다.
Client가 Toss에 요청을 보낼때 SDK로만 작동하기에, 프론트를 모르는 나에게는 끔찍한 소식이었다.

테스트 툴을 통한 인가코드 만들기

토스 payments 개발자 센터에 샌드박스라는 것이 있었다. 토스 payments 개발자 센터 샌드박스
웹에서 결제 API를 쉽게 설명하기 위해서 존재하는 예시를 보여주는 기능이었다.
오고가는 네트워크 요청을 뜯어보면 인가코드를 건질 수 있지 않을까 해서 시도해보았다.
성공했다! 결제 요청이 끝나고 logs에서 Toss가 Client에게 반환해주는 내용을 건질 수 있었다!
다행히 프론트엔드를 구현하지 않고 테스트 할 수 있는 방법을 찾아서 다행이다.

참고자료

토스 payments 개발자 센터

[프로젝트] 간편결제 API(TossPayments)

오늘의 회고

오늘은 토스 결제 API를 적용하고, 테스트 해보았다. 개발자를 위한 실제로 결제가 되지는 않는 API였지만, 결제가 완료되면 핸드폰으로 알림까지 오는걸 보고 놀랐다. 결제 API를 간단하게 적용하도록 토스에서 지원해줘서 어렵지 않게 적용할 수 있었던것 같다. 외부 API를 적용하는것이 굉장히 재미있었다!

Spring - QueryDSL(+Paging, OrderSpecifier)

Fri, 05 Apr 2024 15:13:00 GMT

TIL

QueryDSL로 Paging, 정렬 구현하기

최종프로젝트 11일차, 어제는 QueryDSL을 통해 동적쿼리로 상품의 검색을 구현했다면, 오늘은 QueryDSL을 통한 페이징과 정렬을 구현했다.

이전에 구현했던 상품 검색 쿼리에 페이징과 정렬을 추가하고자 한다.
페이징 요소는 페이지, 사이즈, 정렬할 기준, 오름차순/내림차순이 있다.
- 정렬할 요소에는 입찰자수(bitCount), 현재가격(highestPrice), 조회수(viewCount)가 있다.
- 이전의 구현했던 상품 검색에 상태값이 추가되었다.
그리고 메인페이지에서 접속한 시간대에 추천 게시물을 노출해주는 API를 추가하였다.

구현한 코드

.offset을 통해 몇번째 페이지를 반환할지 결정하고,
.limit를 통해 한 페이지에 몇개의 상품을 반환할지 결정한다.
.orderBy를 통해 정렬을 진행한다.

Pageable

option(정렬할 기준)과 direction(오름차순/내림차순)으로 Sort객체를 만들고,
페이지와 사이즈와 Sort객체로 위 함수에서 사용되는 Pageable을 만든다.
사실상 정렬과 페이징에 필요한 모든것을 포함하고있다.

OrderSpecifier

얼핏 봐서는 Pageable이 정렬과 페이징에 필요한 모든것을 포함하고 있기에 바로 페이징과 정렬을 할 수 있을것같지만, 정렬을 하기위해서는 한번 더 가공이 필요하다.

pageable에서 direction 과 정렬할 기준(여기서는 property)로 OrderSpecifier를 만든다.
- 정렬할 기준이 없거나 설계하지 않은 값인겨우는 조회수로 정렬하도록 구현하였다.
이후 OrderSpecifier와 .orderBy()를 사용하여 정렬을 수행한다.

구현을 하며 발생한 문제

로직을 성공적으로 구현을 했다고 생각했는데, 문제가 발생했다.

입력한 오름차순/내림차순 값과 상관없이, 항상 내림차순으로 정렬을 하는 문제였다.
- 처음에는 Paging과 정렬을 처음 구현해보기에 정렬과 페이징로직에 문제가 있는줄알고 한참을 헤맸다.
- GPT에게도 물어봤지만, 답을 찾지 못했다.
- 열심히 디버깅을 하던중에 한가지 실마리를 찾았다.
isASC 필드에 true/false 어떠한 값을 입력하던 false로 저장되는것을 발견했다.
- 그렇다, isASC 필드에 계속하여 false가 저장되어서 오름차순의 반대, 즉, 내림차순으로만 정렬이 이루어 진것이었다.

왜 값이 들어가지 않았을까? (JSON 바인딩)

그렇다면 왜 제대로된 값이 들어가지 않았을까?

부트캠프의 튜터님께 여쭤보았고, 원인과 해답을 얻었다.
바로 필드명인 isASC가 문제였다.
요청값인 JSON값을 바인딩하여 optionRequest객체를 생성하는데, is라는 접두사 때문에 바인딩이 이루어 지지 않은것이었다.
정말 생각치도 못한 원인이었어서 굉장히 신선하면서도 화가났다. 그래도 로직이 틀리지 않았다는것에 행복했다.

오늘의 회고

QueryDSL이라는걸 처음 시도할때만해도, JPA에서 함수 이름만 잘 구성해주면 알아서 해주는데, 왜 굳이 QueryDSL을 사용하지? 했었는데, 한번 써보니까 훨씬 내가 원하는 방향으로 만들 수 있어서 굉장히 마음에 든다 오늘 QueryDSL에 대해 찾아보다가 보았던 유튜브 영상이다. 평소에 유튜브 알고리즘에 많이 나와서 즐겨보던 유튜버의 강의인줄 알았는데, 유튜버가 아니라 배달의 민족 개발자셨다.. 굉장히 당황을 많이했다. 영상에서 기억에 남는건 ORM 과 QueryDSL을 적재적소에 활용하자는 말이 기억에 남는다. 그리고 이분의 말중에 인상깊었던 말을 인용하면서 오늘 글을 마치도록 하겠다. 기억보다는, 기록으로. [우아콘2020] 수십억건에서 QUERYDSL 사용하기

Spring - JPQL VS QueryDSL(+ BooleanExpression)

Thu, 04 Apr 2024 02:40:21 GMT

TIL

JPQL VS QueryDSL

최종프로젝트 10일차, 내가 맡은 상품쪽 로직을 작성하다가 Query문을 수정할 상황이 발생했다.

기존 상품 검색 로직

    public List searchItem(String itemName) {
        List itemList = itemRepository.findAll();
        List itemResponseList = new ArrayList<>();

    for (Item item : itemList) {
        if (item.getName().contains(itemName)) {
            itemResponseList.add(new ItemResponse(item));
        }
    }

    return itemResponseList;
}

- 기존의 상품 검색 로직이다.
  - **DB에 존재하는 모든 상품을 불러오고**
  - 그 목록에서 **검색어가 포함된 상품만을 반환해주고 있다.**
- 검색어와 상관없이 검색을 수행할때 항상 모든 상품을 불러오는것이 **굉장히 비효율적으로 보였다.** 
- DB에 접근하여 Query문을 통해 검색어를 포함한 상품만을 불러오고 싶었다.
  +추가로 **검색어로 시작하는 상품만을 불러오고 싶었다. (구글 검색창 처럼)**
  ![](https://velog.velcdn.com/images/kim_table_next/post/aaf517c3-d615-4aec-aa7d-2d4145ef1d09/image.png)
- 방법을 찾아보던중, JPQL과 QueryDSL을 찾게되었다.

### JPQL
>- JPQL은 JPA의 일부로 **Query를 Table이 아닌 객체(=엔티티) 기준으로 작성**하는 객체지향 쿼리 언어라고 정의할 수 있다.
- JPQL은 **객체를 기준으로 모든 것이 움직이기 때문에** 개발할 때, Table에 매핑되는 객체가 반드시 존재해야 하며 당연하게도 검색할 때도 Table이 아닌 객체를 대상으로 검색해야 한다.


- JPQL의 특징
  - SQL을 추상화한 JPA의 객체지향 쿼리
  - Table이 아닌 Entity 객체를 대상으로 개발
  - Entity와 속성은 대소문자 구분 (PERSON <> person)
  - 별칭(alias) 사용 필수
  

- JPQL을 실제로 구현하는 방식에는 크게 두 가지 방식이 있다. 
>- 1. EntityManager
```java
@Autowired
EntityManager em;
TypedQuery tq = em.createQuery("select p from Person p where p.FirstName = :firstName and p.LastName = :lastName", Person.class);
tq.setParameter("firstName", "tablenext");
tq.setParameter("lastName", "kim"); >
List personList = tq.getResultList();

repository interface

public interface PersonRepository extends JpaRepository{
>
    /*    변수 바인딩 시, ?시퀀스 사용하는 경우 */
   @Query("select p from Person p where p.firstName = ?1 and p.lastName = ?2")
   Person findPerson(String firstName, String lastName);
>  
   /*    변수 바인딩 시, :이름 사용하는 경우 */
   @Query("select p from Person p where p.firstName = :firstName and p.lastName = :lastName")
   Person findPerson2(@Param("firstName") String firstName, @Param("lastName") String lastName);
}

두 가지 방식은 구현 방식에 있어서 차이점이 명확하지만, 공통점이자 문제점으로 쿼리를 String 형태로 작성하고 있다.
JPQL의 문제점을 정리하면 다음과 같다.
- JPQL의 쿼리는 문자열(=String) 형태이기 때문에 개발자 의존적 형태
- Compile 단계에서 Type-Check가 불가능
- RunTime 단계에서 오류 발견 가능 (장애 risk 상승)
QueryDSL
- 위의 JPQL의 문제점을 보완하기 위해 나온 것이 QueryDSL이다.
QueryDSL은 정적 타입을 이용해서 SQL, JPQL을 코드로 작성할 수 있도록 도와주는 오픈소스 빌더 API이다.
QueryDSL을 사용하는 목적은 뚜렷하다.
- 기존 방식(Mybatis, JPQL, etc..)은 모두 문자열(=String) 형태로 쿼리가 작성되었고 이로 인해 Compile 단계에서 Type-Check 불가했다.
- 이러한 risk를 줄이기 위해 QueryDSL이 등장했고 이를 통해 Compile 단계에서 Type-check가 가능해진 것이다.
QueryDSL을 사용하는 방법은 다음과 같다.
QueryDSL은 모든 쿼리에 대한 내용이 함수 형태로 제공된다.
그렇기 때문에 오류가 존재할 시, Compile 단계에서 바로 확인 가능하며 이에 따른 후속 조치가 가능하기 때문에 그만큼 risk가 줄어들게 되는 것이다.
QueryDSL의 특징
- 문자가 아닌 코드로 작성
- Compile 단계에서 문법 오류를 확인 가능
- 코드 자동 완성 기능 활용 가능
- 동적 쿼리 구현 가능

Boolean Expression

QueryDSL을 통해 검색을 구현하면서, 고민이 생겼다.

검색을 하는 방법으로 이름검색과 카테고리 검색이 있는데,
둘중 하나만 입력해도 작동이 되도록 구현하고 싶었다.
- 처음에는, 이름을 통한 검색과 카테고리를 통한 검색 API를 분리해야 하나 고민해보았고, API를 통합하되, 케이스를 나누어서 Query문을 3가지로 작성해야되나 고민해보았다.
- 고민해보면서 알게된게 바로 Boolean Expression이다.
- Boolean Expression은 다음과 같다.
- 코드를 보면 단순한 조건에 따라 반환을 해주는것으로 보이지만,
BooleanExpression은 null 반환 시 자동으로 조건절에서 제거 된다.*

QueryDSL의 Like, Contains

위의 코드를 보면 qItem.name.like(itemname + "%") 처럼 like문을 리턴해주고있다.

like문은 한마디로 정리하자면 Java의 equals와 비슷하다.
- like(str)은 쿼리가 나갈 때 str자체가 나가기 때문에 정확하게 일치해야한다.
- 이를 통해 %연산을 선택할 수 있다. (itemname+"%"의 경우 itemname으로 시작하는 문자열)
나는 구글의 검색창처럼 itemname으로 시작하는 상품을 조회하고자 하여 itemname+"%"로 구성하였다.
Contains는 Java의 contains와 유사하다.
- contains(str)은 쿼리가 나갈 때 %str%가 나간다.

오늘의 회고

프로젝트의 일일회고를 작성할 시간이 없을때가 있어서 그날그날 발생한 일에 대해 글을 적는것은 힘들것으로 보인다. 매일매일 그날의 일을 기록하기 보단, 내용을 기록하는것에 초점을 두려고 한다. 어제는 하루종일 ECS를 통한 서비스 배포와 CI/CD를 적용해보려고 시도했는데, 모르는 개념들이 매우 많아서(VPC, Nat 게이트웨이, 서브넷, 라우팅테이블, 등등..) 결국 배포에 실패했다. 나중에 이에 대해서도 공부해보고, 왜 실패하였는가, 그리고 성공해보려고 한다. 아직은 AWS친구들이 익숙치 않은것 같다.

Git - CI/CD (Github Actions)

Tue, 02 Apr 2024 13:50:38 GMT

TIL

최종 프로젝트 8일차

최종프로젝트 8일차, 오늘은 Docker와 Github Action을 이용한 CI/CD 구축에 대해서 공부했다.

CI/CD란 무엇일까

흔히, CI/CD는 DevOps 엔지니어의 핵심 업무라고 한다.

도대체 CI/CD가 무엇이길래 핵심 업무일까?

CI (Continuous Integration)

CI는 Continuous Integration 즉, 지속적인 통합이라는 의미이다. 지속적인 통합이란, 어플리케이션의 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합히는 것을 의미한다. (가능하다면 하루에 여러번까지)
현재는 기능 추가 시마다 commit을 통해 repository에 업데이트를 하는데, 개발자가 다수일 경우, repository에 수많은 commit이 쌓이게 된다.
기능별로 빌드/테스트/병합을 하려면 상당히 번거로울 것이다. 이런 상황에서, 자동화된 빌드&테스트는 원천 소스코드의 충돌 등을 방어하는 장점을 제공한다.
CI의 핵심 목표는,버그를 신속하게 찾아 해결하고, 소프트웨어의 품질을 개선하고,

새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있다.

CD (Continuous Delivery & Continuous Deployment)

CD는 Continuous Delivery 혹은 Continuous Depolyment 두 용어 모두의 축약어이다.
해석하자면, 지속적인 서비스 제공 혹은 지속적인 배포 라는 의미이다.
Continuous Delivery는 공유 레포지토리로 자동으로 Release 하는 것이고,
Continuous Deployment는 Production 레벨까지 자동으로 deploy 하는 것을 의미한다. CI가 새로운 소스코드의 빌드, 테스트, 병합까지를 의미하였는데, CD는 개발자의 변경 사항이 레포지토리를 넘어, 고객의 프로덕션(Production) 환경까지 릴리즈 되는 것을 의미한다.

Github Actions

CI/CD의 기능을 알아보았다. 구현만 된다면, 개발단계를 굉장히 편리하게 해주는 기능이다.

그렇다면 어떻게 CI/CD를 구축할 수 있을까? 이번 글은 Github Action을 통해 구축해보았다.
GitHub Actions는 GitHub 플랫폼에서 제공하는 자동화 및 지속적 통합/지속적 배포(CI/CD) 서비스이다.
Github Actions의 구성 요소는 Workflow, Event, Jobs, Actions가 있다.
Workflow
- 한개 이상의 job을 실행할 수 있는 자동화된 작업
- yaml 파일로 저장되며 event에 의해 실행 된다.
Event
- workflow 실행을 발동시키는 특정한 활동
- push event, pull request event, issue event 등이 있다.
Jobs
- 한가지 러너안에서 실행되는 여러가지 step들의 모음
- 각각의 step들은 일종의 shell script 처럼 실행된다.
- Step들은 순서에 따라 실행되며 Step 끼리 데이터들을 공유할 수 있다.
- Job은 다른 Job에 의존관계를 가질 수 있으며, 병렬 실행도 가능하다.
Actions
- 복잡하고 자주 반복되는 작업을 정의한 커스텀 어플리케이션
- workflow 파일 안에서 자주 반복되는 코드를 미리 정의해 코드의 양을 줄일 수 있다.

Github Actions 적용하기

Github Actions를 사용하기 위해서는 프로젝트 폴더의 .github/workflows/디렉토리에 yaml 파일을 작성해주면 된다.

yaml 파일의 구조는 다음과 같다.

name: Deploy
>
on:
workflow_dispatch:
push:
  branches:
    - main
>
jobs:
deploy:
  runs-on: ubuntu-latest
  steps:
    - name: Checkout
      uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v2
      with:
        java-version: '17'
        distribution: 'adopt'
    - name: Grant execute permission for gradlew
      run: chmod +x ./gradlew
    - name: gradlew bootJar
      run: ./gradlew bootJar
    - name: copy jar to server
      uses: appleboy/scp-action@master
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ec2-user
        key: ${{ secrets.SSH_KEY }}
        port: 22
        source: "./build/libs/*.jar"
        target: "~"
        strip_components: 2
>
    - name: SSH Commands
      uses: appleboy/ssh-action@v0.1.6
      with:
        host: ${{ secrets.SSH_HOST }}
        username: ec2-user
        key: ${{ secrets.SSH_KEY }}
        port: 22
        script_stop: true
        script: |
          kill -9 $(ps -ef | grep java | head -n 1 | awk '{print $2}')
          nohup java -jar *.jar

name
- workflow의 name을 정의
- 선택사항이며 깃허브 저장소의 깃허브 액션 탭에서 workflow의 이름을 보여준다.
on
- 해당 workflow를 실행시키는 이벤트를 정의
- 위 코드에서는 main브랜치에 push 이벤트가 발생했을 때 workflow가 실행되도록 정의
jobs
- job의 이름을 정의(위 코드에서는 deploy)
- runs-on : 어떤 호스트에서 실행될지 정의 - ubuntu 가상 머신에서 실행 되도록 정의
Steps
- uses: actions/checkout@v3 - 해당 레포지토리를 pull 받고 이동하는 action 대부분의 workflow에서 사용
- uses: actions/setup-java@v2 - java를 설치하는 action으로 가상머신안에는 대부분의 프로그래밍 언어가 설치되어 있지 않기 때문에 프로젝트 실행에 필요한 언어들을 action을 통해 다운
- run: ./gradlew bootJar - run 키워드를 통해 러너가 실행되는 서버에서 명령어를 실행 (위 코드에서는 gradlew 권한 변경과 jar 파일 생성)

Github Actions를 통한 CI/CD 적용

CI를 적용한 모습이다.
Pull Request시 Github Actions를 통해 자동으로 테스트를 수행한다!
CD가 적용된 모습이다.
상세정보를 확인해보면 AWS의 콘솔에서 빌드되는것도 확인할 수 있다!
적용을 하면, 이벤트가 발생할때마다 Actions 탭에서 자동으로 yml에 적힌 내용을 수행하는데, 이것으로 상당히 많은 부분을 자동화 할 수 있었다! (테스트, 배포 등등)

오늘의 회고

오늘은 Github Actions를 사용하여 CI/CD를 구현해 보았다. AWS에 서버를 배포해본 경험이 없었어서 모든게 새로웠는데, 게다가 이것을 자동으로 해주는게 너무 신기했다. CI/CD를 구축하기 위해 yml파일을 작성하는 수고가 들지만, 나중을 생각하면 무조건 구축하는것이 이득인 CI/CD였다. 최종 프로젝트에도 CI/CD를 적용하여 PR시 자동으로 테스트와 배포를 해주는것을 추가해봐야겠다.

Spring - 캐시(Cache), 직렬화(Serialization)

Thu, 28 Mar 2024 17:29:38 GMT

TIL

최종프로젝트 3일차

최종프로젝트 3일차. 오늘은 내가 담당한 상품 도메인에 조회속도를 향상시키고자 캐시를 적용하였다.

지난 게시글에서 Redis를 이용한 캐싱에 대해 잠깐 다뤘었는데, 이번에는 직접 적용하면서 겪은 내용과 함께 조금 더 자세하게 다뤄보려고 한다.

캐싱이란?

일반적으로 모든 데이터는 DB에 저장이 되고, CRUD를 수행할때 DB를 거쳐서 수행하게 된다. 이것이 일반적인 구조이지만, DB에는 치명적인 단점이 있다. DB는 HDD라는점. HDD의 특성상 SSD보다 느리기에, 속도적인 단점이 있다. 메모리의 속도와 용량은 반비례하는법

이를 보완하기위해 등장한것이 바로 캐싱이다.
- 사실, SSD로 DB를 구성하는것이 제일 좋겠지만, 그렇게되면 가격이 엄청나게 비쌀것이다.
그래서 캐싱이 등장했다.*
캐싱은 원본 데이터와는 별개로 자주 쓰이는 데이터(Hot Data)들을 복사해둘 캐시 공간을 마련한다. 캐시 공간은 상수 시간 등 낮은 시간 복잡도로 접근 가능한 곳 즉, 접근 시간이 원본 데이터에 접근하는 속도보다 훨씬 빠르게 접근 가능한 곳을 주로 사용한다.

캐시 작동 방식

데이터를 달라는 요청이 들어오면, 원본 데이터가 담긴 곳에 접근하기 전에 먼저 캐시 내부부터 찾는다.

1. 캐시에 원하는 데이터가 없거나(Cache), 너무 오래되어 최신성을 잃었으면(Expiration) 그때서야 원본 데이터가 있는 곳에 접근하여 데이터를 가져온다. 이때 데이터를 가져오면서 캐시에도 해당 데이터를 복사하거나 혹은 갱신한다.
1. 캐시에 원하는 데이터가 있으면 원본 데이터가 있는 공간에 접근하지 않고 캐시에서 바로 해당 데이터를 제공한다. (Cache hit)
1. 캐시 공간은 작으므로, 공간이 모자라게 되면 안 쓰는 데이터부터 삭제하여 공간을 확보한다.

캐싱 전략

캐싱전략은 크게 Look aside Cache와 Write Back 2가지 방식이 있다. 또한 Write에는 Cache 데이터 저장 여부에 따라 Write-Around, Write-Through 2가지가 있다.

1. Look aside Cache(Lazy Loading)

Lazy Loading의 장점은, Cache에 데이터가 저장되어 있다면,
DB에 접근하는 대신 Cache에서 호출함으로써 부하를 줄일 수 있다.* Redis가 다운되더라도 바로 장애로 이어지지 않고 DB에서 데이터를 가지고 올 수 있다.

2. Write Back

Write Back은, 쓰기가 굉장히 빈번할 때 사용한다.
DB(Disk)에 바로 저장하지 않고 Cache에 먼저 저장한다.* 그리고 특정 시점에 Cache 데이터를 DB에 저장한다. DB에 바로바로 저장하는 방식에 비해 DB부하가 줄어든다. 지금 진행하는 최종 프로젝트도 경매 시스템이기에 쓰기가 굉장히 빈번하여 나쁘지 않아보인다. Write하는 방법에도 Write-Around, Write-Through 방식이 있다.
1. Write-Around
- Write-Around는 Cache를 거치지 않고 무조건 DB에 저장을 한다.
- 그리고 조회 시, cache miss의 경우에만 DB에서 데이터를 가지고 와서 조회한다.
- DB에 발생한 변화가 조회에는 적용이 안될 수 있다. 아마도 특수한 상황에서 쓸 수 있을것 같다.
2. Write-Through
- Write-Through는 DB에 데이터를 저장할 때, Cache에도 같이 저장하는 것이다.
- 장점으로 Cache는 항상 최신의 데이터를 가지고 있지만,
- 저장을 2번 한다는 점*이라는 단점이 존재한다.
Redis
- 이전에 동시성 제어 게시글에서 언급됬던 Redis가 캐싱을 해준다. 사실 동시성 제어도 Redis가 싱글쓰레드인 점을 이용하여 하나씩 DB에 넘겨주는것.
- Redis의 경우 Memcached와는 달리 다양한 컬렉션(Collection)을 사용한다.
- Redis의 컬렉션은 원자성(Atomic)을 보장하기 때문에 자원 경쟁을 피할 수 있어
- 트랜잭션 경합의 영향을 덜 받는다.*
- Redis의 자료구조는 다음과 같다.

Redis를 이용한 캐싱 적용

Spring에서 다음과 같은 어노테이션으로 캐싱을 적용할 수 있다.

1. @Cacheable(캐시 채우기)

@Cacheable(value = "캐시 이름", key = "키")라고 생각하면 된다. (Redis는 key-value로 데이터가 이루어져 있다.)
뒷 부분의 cacheManager는 어떤 cacheManager를 사용할 지 명시해준다. (별도로 지정하지 않으면 default로 설정된 cacheManager를 사용하게 된다.)
마지막으로 unless = "#result == null"은 null값은 저장하지 않겠다는 의미이다.
- 해당 코드는 searchRequest라는 DTO를 통해 key를 구성하는데, DTO를 key로 넣기위해서는
@ToString 어노테이션을 붙여주면 된다.
그러면 이런식으로 저장이 된다.

2. @CacheEvict(캐시 제거)

@CacheEvict(value = "삭제할 캐시 이름", allEntries = true(모든걸 지우겠다는 뜻))
해당 코드는 상품이 생성될때마다 캐시를 제거하도록 구현하였다.(캐시에 생성되는 상품이 없기에)

3. @CachePut(캐시 업데이트)

@CachePut 어노테이션을 사용하면 캐시를 업데이트 할 수 있다.
하지만 내가 @CacheEvict를 사용한 이유는, 검색어 기반으로 key가 만들어지기에
선택적으로 업데이트 하기보단 삭제 후 조회 시 캐시 저장으로 최신화를 구현하였다.*

4. @Caching(캐시 그룹화)

@Caching 어노테이션을 사용하면 같은 종류의 캐시 메서드를 여러개 그룹화 할 수 있다.

직렬화 & 역직렬화

Redis를 사용하면서 문제를 하나 마주했다.

조회를 처음 할때는 조회가 되었는데, 그 다음부터는 조회가 되지 않았다.
이러한 문제가 왜 발생했나 찾아보다가, 직렬화/역직렬화가 이유였음을 깨닫고 찾아보았다.

직렬화(Serialization)와 역직렬화(Deserialization)

직렬화 : 객체들의 데이터를 연속적인 데이터(스트림)로 변형하여 전송 가능한 형태로 만드는 것

역직렬화 : 직렬화된 데이터를 다시 객체의 형태로 만드는 것
객체 데이터를 통신하기 쉬운 포멧(Byte,CSV,Json..) 형태로 만들어주는 작업을 직렬화라고 볼 수 있고, 역으로, 포멧(Byte,CSV,Json..) 형태에서 객체로 변환하는 과정을 역직렬화라고 할 수 있겠다.

왜 직렬화/역직렬화가 필요할까?

자바에는 원시타입(Primitive Type)이 byte,short,int,long,float,double,boolean,char 총 8가지가 있다. 그리고 그 외 객체들은 주소값을 갖는 참조형 타입이다.
원시타입은 stack에서 값 그 자체로 갖고있다 외부로 데이터를 전달할때, 값을 일정한 형식의 raw byte 형태로 변경하여 전달할 수 있다.
하지만 객체의 경우 실제로 Heap 영역에 존재하고 스택에서는 Heap 영역에 존재하는 객체의 주소(메모리 주소)를 갖고 있다.
- 프로그램이 종료되거나 객체가 쓸모없다고 판단되면 Heap 영역에 있던 데이터는 제거된다. 따라서 본인 메모리에서도 데이터가 사라진다.
- 따라서 이 주소값의 데이터(실체)를 Primitive 한 값 형식 데이터로 변환하는 작업을 거친 후, 전달해야한다.
왜 Redis 캐시를 사용하는데 전송이 필요할까?
- 둘다 같은 PC에서 작동중이지만, Redis와 Spring서버는 엄연히 다른 서버이다. 따라서 데이터에대한 작업을 위해 직렬화/역직렬화가 필요한것이다!
- 그렇다면 직렬화/역직렬화를 어떻게 구현할까?
JdkSerializationRedisSerializer
- JdkSerializationRedisSerializer 는 Default로 적용되는 Serializer로 기본 자바 직렬화 방식을 사용한다.
자바에서는 Serializable 인터페이스만 구현하면 별도의 작업 없이 사용가능하다. 하지만 여러가지 단점이 있다.
- SerialVersionUID 설정을 하지 않으면 클래스의 기본 해시값을 SerialVersionUID 로 사용한다. 따라서 클래스 구조가 조금이라도 변경시 SerialVersionUID 가 달라서 역직렬화에 실패할 수 있다.
- 만약 개발자가 주의를 가지고 SerialVersionUID 를 설정한다고 하여도, 클래스 내부 필드 타입이 변경되면 역시 역직렬화가 실패할 수 있다.
- 기본적으로 타입에 대한 정보 등 클래스 메타 정보들을 가지고 있기 때문에 직렬화시 용량이 비대해진다.

GenericJackson2JsonRedisSerializer

GenericJackon2JsonSerializer 는 Class Type 을 지정할 필요 없이 자동으로 객체를 Json 형식으로 직렬화해주는 장점이 있다. 하지만 직렬화된 데이터가 Class Type 을 포함한다는 단점이 있다.

Jackson2JsonRedisSerializer

Jackson2JsonRedisSerializer 은 @class 필드를 포함하지 않고 Json 으로 저장해준다. 하지만 항상 Class Type 정보를 Serializer 에 함께 지정해주어야한다. 이는 앞서 살펴보았던 GenericJackson2JsonRedisSerializer와 반대 특징을 가진다.

StringRedisSerializer

결론부터 말하자면 StringRedisSerialier 를 직렬화 구현체로 선택하는 것이 가장 단점을 최소화할 수 있는 방법이다.

StringRedisSerializer 는 String 값을 그대로 저장하는 Serializer 이다. 그렇기에 Json 타입으로 별도로 변환하는 과정이 필요하지만,
앞서 살펴본 직렬화 구현체들의 단점을 보완할 수 있다.*

조회가 한번만 되었던 문제의 이유와 해결

조회가 한번만 되었던 이유를 알게 되었다.
1. 처음 조회를 할때는 DB에서 조회를 하여 조회가 가능했지만,
2. 두번째 조회부터는 캐시에서 값을 가져와야하는데, 이부분이 되지 않았던 것이다.
왜 안되었을까 생각해보았고, 결과를 찾았다.
역직렬화를 하기위해서 다시 객체를 생성해야하는데, 생성자가 구현되어있지 않았기 때문이다.
@AllArgsConstructor 어노테이션을 추가하여 해결하였다.

캐싱 부하 테스트

25개의 상품을 만들고, 1000명의 유저가 각각 10번씩 조회와 수정하는 상황을 테스트 해보았다.

캐싱을 적용하지않았을때(조회만 했을경우)

캐싱을 적용했을때(조회만 했을경우)

약 30%정도 실행시간이 단축되었다.

캐싱을 적용하지않았을때(조회+수정)

캐싱을 적용했을때(조회만 했을경우)

약 50%정도 실행시간이 단축되었다.

오늘의 회고

오늘은 Redis를 이용한 캐싱 적용을 하면서, 우연치 않게 문제를 만나서 해결하는 과정에서 상당한 수확을 얻은것 같다. 문제의 원인을 파악하기 위해 개념적으로 접근하였고, 개념을 공부하다 보니 문제의 해결법까지 도달했다. 또 성장한것 같아서 기분이 좋다. 그리고 사실 수정할때마다 캐시를 삭제하기에, 캐싱을 적용해도 성능이 그렇게 다르지 않을것이라 예상했는데, 이정도로 성능이 다르게 나올지는 몰랐다. 캐싱이 DB에 비해서 비용이 굉장히 비싼데, 값어치를 톡톡히 하는것 같다. 내일은 개인적인 사정으로 프로젝트에 참여하지 못하게 되었다. 참여하지 못하는 만큼, 주말을 통해 꾸준히 성장해보려고 한다.

AWS EC2(Elastic Compute Cloud)

Wed, 27 Mar 2024 14:13:05 GMT

TIL

AWS EC2(Elastic Compute Cloud)란?

아마존 웹 서비스(AWS)에서 제공하는 클라우드 컴퓨팅 서비스이다.

한마디로 서버용 컴퓨터를 원격으로 빌리는 것이다.
이름이 Elastic(탄력있는)인 이유는 성능과 용량을 자유롭게 설정할 수 있고, 사용한 만큼 비용을 지불하기 때문이다.
이름이 EC2인 이유는 Elastic Compute Cloud 뒤에 C가 2개있어서 그런것이 아닐까 하는 생각이다.

EC2를 사용하는 이유

사실 서버를 구동하는건 일반 컴퓨터에서도 충분히 가능하다. (다들 마인크래프트 서버를 열어본 경험이 있을것이다)

그렇다면 EC2의 장점은 무엇일까
1. 물리 서버를 도입하는 과정보다 훨씬 간편하고 빠르다.
1. 서버라는게 트래픽이 얼마나 올지 모르기때문에 갑자기 트래픽이 몰릴경우 추가로 장비를 구입해야 하는데, EC2는 클릭 몇 번으로 서버를 증설할 수 있다.
1. 그리고 반대의 상황으로 장비를 빵빵하게 구비해놓았는데 트래픽이 적다면? 엄청난 비용손해. 하지만 EC2는 클릭 몇번으로 서버를 증감하여 비용절감을 할 수 있다.

EC2 인스턴스

보통 EC2로 서버를 구축하면 EC2 인스턴스라는 단어를 자주 볼 수 있다.

EC2 인스턴스를 생성한다는 것은 AMI을 토대로 운영체제, CPU, RAM 혹은 런타임 등이 구성된 컴퓨터를 빌리는 것이다. 한마디로 EC2 인스턴스 생성 = 서버컴퓨터 빌리기

AMI(Amazon Machine Image)

AMI는 소프트웨어의 구성이 기재된 탬플릿이다. AMI(Amazon Machine Image)
![](https://velog.velcdn.com/images/kim_table_next/post/1f5445fb-4c49-4672-a02c-3702f42b4f68/image.png)

AMI를 토대로 원하는 운영체제, 런타임, RAM, 용량, CPU등이 이미 세팅된 EC2 인스턴스를 생성할 수 있다. 한마디로 주문서 같은 셈.
사용 할 수 있는 대표적인 OS
- Amazon Linux2
- CentOS
- Red Hat Enterprise Linux
- Windows Server
- Ubuntu

EC2 인스턴스 유형

다시 EC2 인스턴스 이야기로 돌아가서, EC2 인스턴스의 유형을 알아보도록 하겠다.

EC2 인스턴스에는 굉장히 많은 종류가 있다.(699개나 있다)
이름의 구조가 심상치 않은데, 의미는 다음과 같다.
t4g.large를 예로 들자면 이런 의미이다.
- 타입 : t
- 세대 : 4세대
- 추가기능 : d
- 인스턴스 크기 : large
그렇다면 타입마다 다른점은 뭘까?
타입은 크게 범용, 컴퓨팅 최적화, 메모리 최적화, 저장 최적화로 나뉘고, 또 세부적으로 더 나뉜다.
범용
- M : 범용(vCPU 1개 / 4GB 메모리)
- A : ARM 기반
- T : 버스트가 가능한 CPU
- Mac : macOS
컴퓨팅 최적화
- C : 컴퓨팅 최적화
- F : FPGA용
- G : GPU용
- INF : 머신러닝용
메모리 최적화
- R : 초대형 메모리용
- X : 랜덤 엑세스 메모리용
- P : 프리미엄 GPU용
- Z : 고주파수용
저장 최적화
- H : HDD용(최대 16TB)
- I : NVMe용
- D : 고밀도 스토리지용(48TB)
이와같이 굉장히 많은 타입이 있다.
서버의 특성마다 특화된 타입으로 EC2 인스턴스를 구성하는게 중요할 것으로 보인다.

EC2 인스턴스 요금유형

EC2는 타입도 여러가지인데, 요금유형도 여러가지다.~~(과연 인스턴스 경우의 수가 몇일까)~~

온 디맨드 인스턴스 (On Demand Instance) : 필요할 때 바로 생성해서 사용할 수 있는 방식.
3가지 방식 중 요금이 가장 비싸다*(원래 피시방도 후불요금이 더 비싼것 처럼)
- 공유 인스턴스(Shared tenancy) : 하나의 물리적인 서버에 여러 개의 EC2인스턴스가 실행 → 다른 인스턴스가 서버 자원을 많이 소모한다면 현재 인스턴스의 성능에 영향이 있을 수 있다
- 전용 인스턴스(Dedicated tenacy) : 하나의 물리적인 서버에 하나의 EC2인스턴스가 실행 → 서버 내 다른 인스턴스가 없으므로 영향 X, 공유 인스턴스 방식보다 비싸다
스팟 인스턴스(Spot Instance) : 경매 방식의 인스턴스. 인스턴스의 스펙을 설정하고 원하는 가격을 입력하여 입찰하면 높게 입찰한 사람한테 인스턴스가 할당된다. 해당 스펙의 인스턴스를 다른 사람이 더 높은 가격으로 입찰했다면 내가 가지고 있는 인스턴스는 종료된다 (세상은 냉정한법)
예약 인스턴스 (Reserved Instacne) : 일정한 예약금을 선불로 내면 인스턴스를 1년 또는 3년동안 예약할 수 있으며 시간당 요금이 대폭 할인된다. 온 디맨드 인스턴스와 마찬가지로 공유 인스턴스, 전용인스턴스로 나뉜다
- Light 사용률 예약 인스턴스 : 모든 예약 인스턴스 중에서 선결제 금액이 가장 저렴하다. 사용시간이 많지 않을 때 유용하다 → 몇 달만 사용하는 개발 및 테스트와 단기 프로젝트에 적합
- Medium 사용률 예약 인스턴스 : Light보다 선결제 금액은 비싸지만 시간당 요금이 저렴하다. → 거의 항상 실행하지만 사용량에 약간의 변화가 있을 때 유용!
- Heavy 사용률 예약 인스턴스 : Medium보다 선결제 금액은 비싸지만 모든 예약 인스턴스 중에서 시간당 요금이 가장 저렴하다. → 24시간 상시 가동되어야하는 출시된 제품에 유리!

인스턴스 수명 주기(과정)

AMI로부터 실행이 되고나서 종료될 때까지 EC2가 거치는 과정을 말한다

Amazon EC2 인스턴스는 시작한 순간부터 종료될 때까지 다양한 상태로 전환된다
- 1. pending state
- 제일 처음 AMI가 실행이 되면 준비 상태를 말한다.
- EC2를 가동하기 위해서 가상머신, ENI, EBS 등이 준비되는 과정이다.
- 2. running state
- 실제로 EC2를 사용할수 있는 상태를 말한다.
- running 상태에서 할수 있는 것 3가지가 있는데 다음과 같다.
- 2-1. 중지
- 인스턴스를 잠깐 멈춰두는 것
- 중지 중에는 인스턴트 요금 미청구
- 단 EBS 요금, 다른 구성 요소(Elastic IP 등)은 청구
- 중지 후 재 시작 할때 퍼블릭 IP가 변경됨 (프라이빗IP는 변경X, 해결하려면 탄력적 IP 사용)
- EBS를 사용하는 인스턴스만 중지 가능
- 2-2. 재부팅
- 인스턴스를 다시 시작 하는 것
- 중지하고 다시 시작과는 달리, 재부팅 시 퍼블릭IP 변동 X
- 최대 절전모드
- 메모리 내용을 보존해서 재 시작시 중단지점에서 시작할 수 있는 정지모드
- 어떤 프로그램을 실행시켰을 때 데이터를 하드디스크에서만 가져오는 것이 아니라 메모리에 올려놓는 것
- 컴퓨터/노트북의 최대 절전 모드와 같은 원리라고 보면 된다. 우리가 만일 프로그램을 이용하다 만일 프로그램이 켜 상태를 유지하면서 잠시 노트북을 꺼야한다면 최대 절전을 한다. 그리고 다시 노트북을 켰을때 아예 OS 재부팅되는게 아니라, 프로그램이 이어서 돌아가게 된다.
- 3. shutting-down state
- 인스턴스 종료 중
- 설정에 따라 EBS도 같이 종료 시킬 수도 있고 EBS는 남기고 인스턴스만 종료 할 수 있다.
- 4. terminated state
- 완전히 종료, 인스턴스가 영구적으로 삭제된다
- 인스턴스 미사용시 중지시켜두기만 해도 많은 비용 절감 할수 있다.
EBS(Elastic Block Store)
- 인스턴스 생명 주기에서 EBS가 많이 언급되었는데, EBS는 뭘까?
- EBS란 EC2 인스턴스에 장착하여 사용할 수 있는 가상 저장 장치이다.
- 일반적인 하드디스크나 SSD처럼 인식되기에, 원하는 크기와 성능을 설정할 수 있다.
Block은 블록 장치로, ** Unix/Linux 계열 OS에서 일정한 크기(Block)단위로 읽고 쓰는 저장 장치를 부르는 말이다.**

오늘의 회고

AWS 친구들(EC2, Lambda, S3, RDS, DynamoDB, ElastiCache)중에 처음으로 EC2에 대해 공부해봤는데 생각보다 이렇게 분량이 많을줄 몰랐다. 그래도 알고 쓰는것과 모르고 쓰는것은 엄청난 차이니까 차근차근 공부해봐야겠다. 하루하루 성장하는거같아서 기분이 좋다.

Spring - 도커(Docker)

Tue, 26 Mar 2024 14:23:25 GMT

TIL

도커(Docker)란?

도커(Docker) : 리눅스 컨테이너에 리눅스 어플리케이션을 프로세스 격리기술을 사용하여 더 쉽게 컨테이너로 실행하고 관리할 수 있게 해주는 오픈소스 프로젝트이다.

도커 엔진(Docker Engine)* : 컨테이너를 생성하고 관리하는 주체로서 이 자체로도 컨테이너를 제어할 수 있고 다양한 기능을 제공하는 도커의 프로젝트이다.

도커 컨테이너(Docker Container)

컨테이너(Container)는 어플리케이션을 다른 환경에서 빠르고 안정적으로 실행 할 수 있도록 코드 + 모든 종속성을 패키징하는 표준 소프트웨어 단위이다.

도커 컨테이너 이미지(Docker Container Image)는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정 등 어플리케이션을 실행하는 데 필요한 모든 것을 포함하는 경량의 독립 실행형 소프트웨어 패키지이다. [Docker 래퍼런스]

가상머신(Virtual Machine) VS 도커 컨테이너(Docker Container)

도커 컨테이너는 어플리케이션을 다른 환경에서 실행할 수 있도록 해주는것이라고 생각한다. 그런데, 우리가 평소에 다른 환경을 구동하기위해 가상머신을 이용할때가 있는데,

왜 도커를 사용할까?

도커 컨테이너를 사용하는 이유

컨테이너는 기본 운영체제 커널을 동일한 시스템의 다른 컨테이너와 공유하는 격리된 환경에서 어플리케이션을 실행하는 방법이다. (위에서 설명한 프로세스 격리기술)
종속성, 필요한 라이브러리 및 바이너리와 함께 어플리케이션을 컨테이너 이미지라고 하는 독립된 패키지로 패키지화하여 여러 컴퓨팅 환경에 쉽게 배포할 수 있다.
가상머신과는 다르게, 하이퍼바이저 위에서 여러 개의 게스트 OS를 싱행하는 대신, 호스트 OS 커널을 사용하여 격리된 여러 개의 컨테이너를 실행한다.
게스트 OS가 아닌 호스트 OS에 컨테이너형 가상화 소프트웨어를 설치하기때문에,
기존 가상화에 비해 더 가볍고 효율적이다. (컨테이너의 장점)*
설치 같은 번거로움을 줄이고, 성능도 좋아진다!

도커 컨테이너 만드는법

1. docker build 명령어를 통해서 Docker File을 Docker Image로 만든다.
1. docker run 명령어를 통해서 Docker Image를 Docker Container로 만든다.

오늘의 회고

로컬에서만 개발하다가 최종 프로젝트에 오면서 배포에 대한 기술이 필요해짐에 따라 배포에 관련된 기술들을 익힐 필요가 생겼다.. (S3, ELB, Docker, 메세지큐 등등..) 처음 접해보는 기술이라 프로젝트를 진행하는데에 차질이 없도록 하루에 1개씩이라도 기술을 찾아보며 익혀야겠다

[Project] Spring - 심화프로젝트(SCV)

Mon, 25 Mar 2024 01:42:20 GMT

📄 개요

프로젝트 이름 : SCV (Sparta Coding Virtual workspace)
프로젝트 제작기간 : 2024.03.18 ~ 2024.03.25
프로젝트 설명 : 여러 사용자들이 프로젝트를 관리하고, 팀원들과 협력하여 작업을 효율적으로 할당하고 처리하는데 도움을 주는 협업 플랫폼

⚙개발환경

👩🏼‍🤝‍👩🏼멤버 구성

김상엽 - 카드, 댓글 도메인
전석배 - 보드 도메인
이종원 - 컬럼 도메인
방세훈 - 유저 도메인

📐 와이어 프레임

🗂️ ERD (Entity Relationship Diagram)

📜API

프로젝트 회고

이번 프로젝트는 이전 프로젝트들과 다르게 Redis를 적용시켜보았는데, 기존 DB를 통한 구동속도도 나름 빠르다고 생각했는데, Redis는 넘사벽이었다. Redis를 이용해 캐싱처리를 하니 수행시간이 10배가 빨라졌다.

Redis를 이용한 캐싱과 분산락을 적용했다는 점이 이번 프로젝트의 차별점이다!

이제 내일부터 최종프로젝트가 시작되는데 어떤 주제를 할지 아직 감이 잡히지 않는다. 그래도 여정의 끝이 보이는것 같아 기분이 좋다.

Spring - 동시성 제어 테스트 코드 작성하기(Redisson, H2)

Thu, 21 Mar 2024 13:46:38 GMT

TIL

동시성 제어 테스트(Redisson을 통한 분산 락)

    @Transactional
    public CardStatusResponse updateCard(Long cardId, CardUpdateRequest cardUpdateRequest, User user) {
        Card card = getCardById(cardId);

    if(!user.getId().equals(card.getOwner().getId()))
        throw new IllegalArgumentException("해당 카드를 수정할 권한이 없습니다.");

    RLock lock = redissonClient.getFairLock("card:" + cardId);
    try{
        if(lock.tryLock(10, 60, TimeUnit.SECONDS)){
            try{
                card.update(cardUpdateRequest);
            } finally {
                lock.unlock();
            }
        }
        else{
            throw new IllegalArgumentException("다른 유저가 이미 수정중입니다.");
        }
    } catch (InterruptedException e){
        Thread.currentThread().interrupt();
    }
    return new CardStatusResponse(201, "OK", card.getId());
}

- `Redisson`을 사용하여 카드 업데이트 함수에 `분산락`을 적용하였다.

## 테스트 코드
>```java
    @Test
    public void updateCardConcurrencyTest() throws InterruptedException{
        User user = new User(1L);
        int numberOfThreads = 10;
        // 쓰레드 생성
        ExecutorService executorService = Executors.newFixedThreadPool(numberOfThreads);
        // 주어진 수 만큼 이벤트를 기다림
        CountDownLatch latch = new CountDownLatch(numberOfThreads);
>
        for (int i = 1; i <= numberOfThreads; i++) {
            // 각 쓰레드에서 사용할 요청 생성
            CardUpdateRequest cardUpdateRequest = new CardUpdateRequest(1L, "Update Name " + i,
                "Update Description " + i, "Update Color " + i, "startDate", "endDate");
>
            int finalI = i;
            executorService.submit(() -> {
                try {
                    System.out.println(finalI + "번째 쓰레드 접근 시작");
                    cardService.updateCard(1L, cardUpdateRequest, user);
                } finally {
                    latch.countDown();
                    System.out.println(finalI + "번째 쓰레드 접근 종료");
                }
            });
        }
>
        latch.await(); // 모든 쓰레드의 작업이 완료될 때까지 대기
        executorService.shutdown();
    }

10개의 쓰레드에서 동시에 카드를 수정하도록 테스트 코드를 구현하였다.

테스트 결과

쓰레드들이 순차적으로 접근하면서 테스트가 잘 수행되었다.
하지만 문제가 있다.
테스트가 끝나면 DB에 테스트 결과가 남아버린다.
그래서 매번 테스트를 다시 진행할때 마다 Drop Table을 했었다.

H2 Database

H2 Database는 자바로 작성된 관계형 데이터베이스 관리 시스템이다.

특징으로는 In-Memory 데이터베이스이기 때문에 실행할때마다 초기화된다!

H2 in Memory DB

H2의 적용법은 간단하다.

application.properties에 연결해주고, 의존성 추가만 해주면 끝이다!
평소에는 MySQL로 작동하지만 테스트를 진행할때는 H2로 작동하게 하려고 한다.
테스트용 환경을 따로 구축하기 위해서는 test 디렉토리에 application.properties를 따로 만들어주면 test할때만 적용된다!

테스트 코드에 H2 적용하기

테스트용 application.properties만 만들어주면 적용은 끝이다!

테스트 결과(H2 적용후)

테스트는 이전과 동일하게 동작하지만 MySQL이 아닌 H2로 동작하기에 DB에 아무것도 남지 않는다.

오늘의 회고

사실 분산락을 통해 동시성 제어하는 기능을 구현하였지만 이번 프로젝트에는 딱히 동시성을 제어할 부분이 없었다. 그래도 이제는 할줄 안다는것에 의미를 두려고 한다!

Spring - 동시성 제어 실험(Lock, Redis)

Wed, 20 Mar 2024 11:27:19 GMT

TIL

동시성 제어

오늘은 동시성 제어에 도전해 보았다. 여태까지 구현했던 코드들은 로컬서버에서 나 혼자 구동하기 때문에 딱히 동시성에 대해 생각해보지 않았다. 하지만 최종프로젝트가 다가오면서, 동시성 제어에 도전해보았다.

설정한 상황(선착순 쿠폰 100개 이벤트)

Counter 라는 entity에 쿠폰 개수(count)가 100으로 가정하고, 쿠폰을 수령하면 count를 1 감소시키는 로직을 구현하였다.

1. 동시성 고려 X (기존에 구현한 방식)

    @Transactional
    public void decreaseCount() {
        Counter counter = counterRepository.findById(1L).orElseThrow();
        counter.setCount(counter.getCount() - 1);
        counterRepository.save(counter);
    }

- `Counter`를 DB에서 불러와서
- `count`의 값을 1 감소시키고
- 다시 DB에 `Counter`를 저장했다.

### 1-1. 테스트 결과 (기존에 구현한 방식)
>```java
    @Test @DisplayName("RDBMS를 사용했을 시 동시성 문제가 발생")
    void concurrencyTest() {
        System.out.println("\n\n\n\n[concurrencyTest]");
        IntStream.range(0, 100).parallel().forEach(i -> counterService.decreaseCount());
        counterService.printCount();
    }

decreaseCount()를 반복해서 100번 수행한다면 당연히 count는 100번 감소하여 0이 될 것이다.
하지만 병렬로 100번을 동시에 수행한다면 과연 count는 0이 될까?
동시성 문제로 인해서 0이 아닌 83이 나오는걸 확인할 수 있다.
감소된 count가 저장되기전에 다른곳에서 조회를 해서 문제가 발생하는 것으로 보인다.

2. 동시성 고려 시도 1(객체를 여러개 만들고 삭제하기)

1번에서 실패한 상황을 조금 바꿔보았다.

이번에는 Counter객체를 5개 만들고
count값이 100인 Counter를 DB에서 불러와서
삭제하고 "내꺼!"를 출력하도록 구현해보았다.
삭제로 한 이유는 삭제를 시도할때 이미 삭제가 되었다면 Exception이 발생해서 출력이 안될것이라고 예상했기 때문이다.

2-1. 테스트 결과 (객체를 여러개 만들고 삭제하기)

나는 분명 쿠폰을 5개만 준비했지만.. 8명이 받아갔다.
심지어 실패했을때 출력하도록한 "까비!" 또한 하나도 출력되지 않았다.
예상이 빗나간 이유를 검색해 보니, JPA에서는 삭제할 Entity가 없어도 Exception을 발생시키지 않는다고 한다. 만약 발생시키고 싶다면 삭제 함수를 오버라이딩해서 예외를 발생하도록 추가해야 한다고 한다!

3. 동시성 고려 시도 2 (Lock)

이번에는 Lock을 통해 동시성 문제를 해결해보았다.

    public void decreaseCountUsingLock() {
        RLock lock = redissonClient.getFairLock(LOCK_KEY);
        try {
            boolean isLocked = lock.tryLock(10, 60, TimeUnit.SECONDS);
            if (isLocked) {
                try {
                    Counter counter = counterRepository.findById(1L).orElseThrow();
                    counter.setCount(counter.getCount() - 1);
                    counterRepository.save(counter);
                } finally {
                    lock.unlock();
                }
            }
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

간단히 설명하자면 10초동안 락이 풀릴때까지 기다리고,
60초가 지나면 락이 자동으로 풀리게 설정하였다.
물론 함수가 끝나면 바로 락이 풀린다.

3-1. 테스트 결과 (Lock)

Lock을 걸어서 100개의 시도가 순서대로 처리되어서 성공적으로 쿠폰이 0개 남았음을 확인할 수 있었다!

4. 동시성 고려 시도 3 (Redis)

앞의 Lock을 활용할때도 Redis를 사용하였지만,

이번에는 Redis가 싱글쓰레드라는 특징을 활용하여 동시성을 제어해보겠다.

  public void decrementCounter() {
      ValueOperations ops = stringRedisTemplate.opsForValue();
      ops.decrement("counter");
  }

4-1. 테스트 결과 (Redis)

Redis가 싱글쓰레드라는 특징을 갖고있어서, 100개의 시도가 순서대로 처리되어서 성공적으로 쿠폰이 0개남았다!

오늘의 회고

여태까지 동시성 문제에 대해 고려하지 않았었다. 왜냐면 여태까지 진행했던 프로젝트들은 모두 로컬 서버에서 혼자 돌렸기때문에 내가 한명인 이상 동시성 문제가 발생할 수 없고, 정말 천문학적인 트래픽이 아니라면 동시에 처리될 확률이 엄청나게 낮기 때문이다. 그런데 생각해보면 평소에 배달대행앱을 자주 사용하는데, 이러한 선착순 이벤트를 구현한다면 동시성 문제를 반드시 해결해야한다는 생각이 들어서 오늘 실험을 해보았다.

실험을 하면서 가장 충격받은점은, JPA는 삭제에 실패해도 예외를 발생시키지 않는다는 점이다.

평소에 굉장히 편리해서 아주 좋아했던 내 친구 JPA였는데, 이러한 허점이 있다는 사실을 처음 알았다.

오늘 사용했던 Redis에 대해서는 사실 많이 아는것이 없다..(오늘 처음봤다) 추후에 Redis와 친해진 뒤에, Redis에 대한 정리글을 올릴 예정이다!

[프로그래머스] - 정수 삼각형(Bottom-up)

Mon, 18 Mar 2024 09:30:33 GMT

정수 삼각형

문제 설명

위와 같은 삼각형의 꼭대기에서 바닥까지 이어지는 경로 중, 거쳐간 숫자의 합이 가장 큰 경우를 찾아보려고 합니다. 아래 칸으로 이동할 때는 대각선 방향으로 한 칸 오른쪽 또는 왼쪽으로만 이동 가능합니다. 예를 들어 3에서는 그 아래칸의 8 또는 1로만 이동이 가능합니다.

삼각형의 정보가 담긴 배열 triangle이 매개변수로 주어질 때, 거쳐간 숫자의 최댓값을 return 하도록 solution 함수를 완성하세요.

해결한 로직

class Solution {
    public int solution(int[][] triangle) {
        int answer = 0;
        int stage = triangle.length-2;
        int index = 0;
        for(int i=stage; i>-1; i--)
            for(int j = 0; j=triangle[i+1][j+1])
                    triangle[i][j] += triangle[i+1][j];
                else
                    triangle[i][j] += triangle[i+1][j+1];
            }
                return triangle[0][0];
    }
}

- 처음에는 방향이 잡히지 않아 모든 경우의 수를 고려하는 로직을 구현하려고 하였는데,
**재귀함수를 짜면서 이건 잘못된 길이 분명함을 깨달았다. 
(최악의 경우 2^500개의 경우의 수가 나온다)**


- 그래서 어떻게 해야할까 고민하다가 삼각형의 밑에서 부터 경우의 수를 줄이며 올라가는 방식을 생각해냈다.
![](https://velog.velcdn.com/images/kim_table_next/post/37a76a7f-b8e7-4150-806f-3139b6a2c834/image.png)
- 해결을 하고 찾아보니 문제 해결법 중, Bottom-up 방식이 바로 이러한 방식이라고 한다.

## Bottom-up 방식
>- 우리말로 `상향식`이라고도 한다. 가장 작은 문제들부터 답을 찾아 가면서 마지막에는 전체 문제의 답을 구하는 방식이다.
- 보통 반복문을 이용해 구현하게 된다. 재귀 호출을 하지 않으므로 시간과 메모리의 사용량이 상대적으로 적다는 이점이 있다.
![](https://velog.velcdn.com/images/kim_table_next/post/fd5edcae-a923-423a-b5c4-ca98a079a75a/image.png)

# 오늘의 회고
오늘은 심화프로젝트 설계와 알고리즘 문제(정수 삼각형)를 풀었다
풀다가 정말 기발한 아이디어라고 생각해서 신났는데,
찾아봤더니 유명한 알고리즘 문제풀이법 중 하나라고 해서 조금 실망했다.
그래도 2^500가지의 경우의 수를 보지않는 효율적인 로직을 생각해내서 뿌듯하다.

[프로그래머스] - 귤 고르기(Collections.reverse)

Fri, 15 Mar 2024 02:24:56 GMT

귤 고르기

문제 설명 경화는 과수원에서 귤을 수확했습니다. 경화는 수확한 귤 중 k개를 골라 상자 하나에 담아 판매하려고 합니다. 그런데 수확한 귤의 크기가 일정하지 않아 보기에 좋지 않다고 생각한 경화는 귤을 크기별로 분류했을 때 서로 다른 종류의 수를 최소화하고 싶습니다.

예를 들어, 경화가 수확한 귤 8개의 크기가 [1, 3, 2, 5, 4, 5, 2, 3] 이라고 합시다. 경화가 귤 6개를 판매하고 싶다면, 크기가 1, 4인 귤을 제외한 여섯 개의 귤을 상자에 담으면, 귤의 크기의 종류가 2, 3, 5로 총 3가지가 되며 이때가 서로 다른 종류가 최소일 때입니다.

경화가 한 상자에 담으려는 귤의 개수 k와 귤의 크기를 담은 배열 tangerine이 매개변수로 주어집니다. 경화가 귤 k개를 고를 때 크기가 서로 다른 종류의 수의 최솟값을 return 하도록 solution 함수를 작성해주세요.

해결한 로직

import java.util.*;
>
class Solution {
    public int solution(int k, int[] tangerine) {
        int answer = 0;
        Map map = new HashMap<>();
        >
        for(int orange : tangerine){
            if(map!=null&&map.containsKey(orange))
                map.put(orange, map.get(orange)+1);
            else
                map.put(orange, 1);
        }
        >
        Set keySet = map.keySet();
        List size = new ArrayList<>();
        for(int key : keySet)
            size.add(map.get(key));
        >
        Collections.sort(size);
        Collections.reverse(size);
        for(int s : size){
            if(k>s){
                k = k-s;
                answer++;
            }
            else if(k<=s){
                answer++;
                break;
            }
        }
       >     
        return answer;
    }
}

Map에 귤의 <사이즈, 개수>를 저장하고, 개수가 많은 사이즈의 귤 부터 채우는 방식을 생각했다.
그런데 그러려면 귤 리스트를 내림차순으로 정렬해야한다.
Comparator를 오버라이딩해서 구현해야 하나 생각했다가, Collections.sort를 통해 오름차순으로 정렬하고, 리스트를 뒤집는 방법을 생각했다.
Collections.reverse를 사용하면 리스트를 뒤집을 수 있다.

오늘의 회고

평소에 구현할때는 잘 안쓰는 기능들이지만, 알고리즘 문제에서는 아주 쏠쏠한 녀석들이 참 많다. 많이 풀면서 이 녀석들과 친해져야겠다.

[프로그래머스] - 시소 짝꿍(Double, Long)

Thu, 14 Mar 2024 03:10:53 GMT

시소 짝궁

문제 설명 어느 공원 놀이터에는 시소가 하나 설치되어 있습니다. 이 시소는 중심으로부터 2(m), 3(m), 4(m) 거리의 지점에 좌석이 하나씩 있습니다. 이 시소를 두 명이 마주 보고 탄다고 할 때, 시소가 평형인 상태에서 각각에 의해 시소에 걸리는 토크의 크기가 서로 상쇄되어 완전한 균형을 이룰 수 있다면 그 두 사람을 시소 짝꿍이라고 합니다. 즉, 탑승한 사람의 무게와 시소 축과 좌석 간의 거리의 곱이 양쪽 다 같다면 시소 짝꿍이라고 할 수 있습니다. 사람들의 몸무게 목록 weights이 주어질 때, 시소 짝꿍이 몇 쌍 존재하는지 구하여 return 하도록 solution 함수를 완성해주세요.

오버플로우 문제(Long으로 해결)

import java.util.*;

class Solution { public long solution(int[] weights) { long answer = 0; Map weightMap = new HashMap(); for(int weight : weights){ Long weight_long = Long.valueOf(weight); if(weightMap.containsKey(weight_long)) weightMap.put(weight_long, weightMap.get(weight_long)+1); else weightMap.put(weight_long,1); } > for(Long weight_long : weightMap.keySet()){ if(weightMap.containsKey(weight_long)) // 1 : 1 nC2 answer+= weightMap.get(weight_long)(weightMap.get(weight_long)-1)/2; >
if(weightMap.containsKey(weight_long2/3)) // 2m : 3m answer+= weightMap.get(weight_long)weightMap.get(weight_long2/3); > if(weightMap.containsKey(weight_long/2)) // 2m : 4m answer+= weightMap.get(weight_long)weightMap.get(weight_long/2); > if(weightMap.containsKey(weight_long3/4)) // 3m : 4m answer+= weightMap.get(weight_long)weightMap.get(weight_long3/4);

    }
    >
    return answer;
}

}

- 짝꿍 쌍을 구하는 과정에서 `answer`는 `long`형 이기에 문제가 없다고 판단하였는데,
**`Long += Integer * Integer` 의 형태였어서 오버플로우 문제가 있었다.**
- 무게를 저장하는 `Map`을 ``에서 ``으로 변경하여 해결하였다.
>
```java
        Map weightMap = new HashMap(); //으로 변경
        for(int weight : weights){
            Long weight_long = Long.valueOf(weight);
            if(weightMap.containsKey(weight_long))
                weightMap.put(weight_long, weightMap.get(weight_long)+1);
            else
                weightMap.put(weight_long,1L);
        }

아마도 테스트 12~15에서 오버플로우가 발생했나보다

소수점 문제(Double로 해결)

하지만 여전히 테스트 4~11은 통과하지 못하고있다.

로직에 어떤 문제가 있나 고민(1시간정도 고민했다)해본 결과 나눗셈을 하는 과정에서 소수점을 고려하지 않는 문제점이 있었다.

무게를 저장하는 Map을 에서 으로 변경하여 해결하였다.

      Map weightMap = new HashMap();
      for(int weight : weights){
          Double weight_long = Double.valueOf(weight);
          if(weightMap.containsKey(weight_long))
              weightMap.put(weight_long, weightMap.get(weight_long)+1);
          else
              weightMap.put(weight_long,1L);
      }

오늘의 회고

이번 문제는 학창시절에 경우의 수 문제 푸는거를 떠올려서 경우의 수 문제를 풀듯이 접근하였다. 그런데 자료구조형을 선택하는 과정에서 소수점과 오버플로우를 고려하지 못해서 시간이 좀 걸렸다. 돌이켜 생각해보면 오버플로우와 소수점문제가 발생한다는 사실을 생각하지 못해서 발생한 문제였다.

알고리즘 문제를 많이 풀면서 경험을 많이 쌓아야 겠다.

[프로그래머스] - 디펜스 게임 (PriorityQueue)

Wed, 13 Mar 2024 02:22:52 GMT

디펜스 게임

문제 설명 준호는 요즘 디펜스 게임에 푹 빠져 있습니다. 디펜스 게임은 준호가 보유한 병사 n명으로 연속되는 적의 공격을 순서대로 막는 게임입니다. 디펜스 게임은 다음과 같은 규칙으로 진행됩니다.

준호는 처음에 병사 n명을 가지고 있습니다. 매 라운드마다 enemy[i]마리의 적이 등장합니다. 남은 병사 중 enemy[i]명 만큼 소모하여 enemy[i]마리의 적을 막을 수 있습니다. 예를 들어 남은 병사가 7명이고, 적의 수가 2마리인 경우, 현재 라운드를 막으면 7 - 2 = 5명의 병사가 남습니다. 남은 병사의 수보다 현재 라운드의 적의 수가 더 많으면 게임이 종료됩니다. 게임에는 무적권이라는 스킬이 있으며, 무적권을 사용하면 병사의 소모없이 한 라운드의 공격을 막을 수 있습니다. 무적권은 최대 k번 사용할 수 있습니다. 준호는 무적권을 적절한 시기에 사용하여 최대한 많은 라운드를 진행하고 싶습니다.

준호가 처음 가지고 있는 병사의 수 n, 사용 가능한 무적권의 횟수 k, 매 라운드마다 공격해오는 적의 수가 순서대로 담긴 정수 배열 enemy가 매개변수로 주어집니다. 준호가 몇 라운드까지 막을 수 있는지 return 하도록 solution 함수를 완성해주세요.

시도했던 로직

import java.util.*;
>
class Solution {
    public int solution(int n, int k, int[] enemy) { 
        int answer = 0;
        int[] skip = new int[k];
        if(k>enemy.length)
            return enemy.length;
        for(int i=0; i1)
        Arrays.sort(skip);
        for(int i=k; i1&&enemy[i]>skip[1])
                    Arrays.sort(skip);
            }
            else if(n >= enemy[i]){
                n = n - enemy[i];
                answer++;
            }
            else if(n



배열에 무적권을 사용한 라운드의 병사 수를 기록하고, 배열의 최소값을 활용하여 최적의 경우의 수를 찾도록 구현하였는데, 최소값을 찾는 과정에서 배열을 정렬하게되는데, 이 때문에 시간초과가 발생하였다. 그래서 배열 정렬을 최소화 하도록 코드를 계속 수정해도 시간초과는 막을 수 없었다.


해결한 로직(PriorityQueue으로 해결)


배열로 구현하는 것 보다 시간이 빠른 방법을 찾아보고,
Priority Queue(우선 순위 큐)를 사용하는 방법을 알게 되었다.


import java.util.*;
>
class Solution {
    public int solution(int n, int k, int[] enemy) {
        int answer = enemy.length;
        Queue pq = new PriorityQueue<>(Collections.reverseOrder());
>
        int my = n;
        int card = k;
        for (int i = 0; i < enemy.length; i++) {
            my -= enemy[i];
            pq.add(enemy[i]);
>
            if (my < 0) {
                if (card > 0 && !pq.isEmpty()) {
                    my += pq.poll();
                    card--;
                } else {
                    answer = i;
                    break;
                }
            }
        }
>
        return answer;
    }
}

PriorityQueue란 우선순위 큐로써 일반적인 큐의 구조 FIFO(First In First Out)를 가지면서, 데이터가 들어온 순서대로 데이터가 나가는 것이 아닌 우선순위를 먼저 결정하고 그 우선순위가 높은 데이터가 먼저 나가는 자료구조이다.
데이터가 들어가면서 정렬이 동시에 되는 형태이기 때문에 기존의 배열을 정렬하는 로직보다 훨씬 시간이 빠르다.


오늘의 회고
물론, 알고리즘 문제를 많이 풀진 않았지만, 여태까지는 시간복잡도에 걸려본 경험이 없었는데,
이 문제를 풀면서 느꼈다.
알고리즘 문제를 많이 풀면서 경험을 쌓고, 다양한 자료구조형들에 익숙해 져야겠다.



Spring - ORM의 성장 과정
Fri, 08 Mar 2024 11:27:00 GMT

TIL
릴레이션(관계형 데이터베이스)를 객체로 매핑 하려는 이유


객체 지향 프로그래밍의 장점을 활용할 수 있음



이를 통해, 비즈니스 로직 구현 및 테스트 구현이 편리함
각종 디자인 패턴 사용하여 성능 개선 가능
코드 재사용

그러나 생각처럼 쉽지않다.. 여러가지 문제가 발생한다
왜냐하면 **객체와 RDB의 특성이 너무 다르다.**



ORM 이 해결해야하는 문제점 과 해결책
1. 상속의 문제


객체 : 객체간에 멤버변수나 상속관계를 맺을 수 있다.



RDB : 테이블들은 상속관계가 없고 모두 독립적으로 존재한다.

해결방법 : 매핑정보에 상속정보를 넣어준다. (@OneToMany, @ManyToOne)*

2. 관계 문제


객체 : 참조를 통해 관계를 가지며 방향을 가진다. (다대다 관계도 있음)



RDB : 외래키(FK)를 설정하여 Join 으로 조회시에만 참조가 가능하다. (즉, 다대다는 매핑 테이블 필요)

해결방법 : 매핑정보에 방향정보를 넣어준다. (@JoinColumn, @MappedBy)*

3. 탐색 문제


객체 : 참조를 통해 다른 객체로 순차적 탐색이 가능하며 콜렉션도 순회한다.



RDB : 탐색시 참조하는 만큼 추가 쿼리나, Join 이 발생하여 비효율적이다.

해결방법 : 매핑/조회 정보로 참조탐색 시점을 관리한다.(@FetchType, fetchJoin())*

4. 밀도 문제


객체 : 멤버 객체크기가 매우 클 수 있다.



RDB : 기본 데이터 타입만 존재한다.

해결방법 : 크기가 큰 멤버 객체는 테이블을 분리하여 상속으로 처리한다. (@embedded)*

5. 식별성 문제


객체 : 객체의 hashCode 또는 정의한 equals() 메소드를 통해 식별



RDB : PK 로만 식별

해결방법 : PK 를 객체 Id로 설정하고 EntityManager는 해당 값으로 객체를 식별하여 관리 한다.(@Id,@GeneratedValue )*

대신, ORM 이 얻은 최적화 방법




1차 캐시, 2차 캐시를 사용하여 최적화를 했다.
캐싱 기능은 객체지향 프로그래밍이 가진 가장 큰 장점이다.

1차 캐시


영속성 컨텍스트 내부에는 엔티티를 보관하는 저장소가 있는데 이를 1차 캐시라고 한다.



일반적으로 트랜잭션을 시작하고 종료할 때까지만 1차 캐시가 유효하다.
1차 캐시는 한 트랜잭션 계속해서 원본 객체를 넘겨준다.

2차 캐시


애플리케이션 범위의 캐시로, 공유 캐시라고도 하며, 애플리케이션을 종료할 때 까지 캐시가 유지된다.



2차 캐시는 캐시 한 객체 원본을 넘겨주지 않고 복사본을 만들어서 넘겨준다.
복사본을 주는 이유는 여러 트랜잭션에서 동일한 원본객체를 수정하는일이 없도록 하기 위해서이다.
Entity에 @Cacheable 적용 후, yml파일에 설정을 추가해주면 사용할 수 있다.# application.yml
>
spring.jpa.properties.hibernate.cache.use_second_level_cache: true
# 2차 캐시 활성화합니다.
>
spring.jpa.properties.hibernate.cache.region.factory_class: XXX
# 2차 캐시를 처리할 클래스를 지정합니다.
>
spring.jpa.properties.hibernate.generate_statistics: true
# 하이버네이트가 여러 통계정보를 출력하게 해주는데 캐시 적용 여부를 확인할 수 있습니다.

sharedCache.mode 설정을 통해서도 가능하다# appplication.yml
>
spring.jpa.properties.javax.persistence.sharedCache.mode: ENABLE_SELECTIVE

cache mode 종류



ALL
모든 엔티티를 캐시합니다.



NONE
캐시를 사용하지 않습니다.


ENABLE_SELECTIVE
Cacheable(true)로 설정된 엔티티만 캐시를 적용합니다.


DISABLE_SELECTIVE
모든 엔티티를 캐시하는데 Cacheable(false)만 캐시하지 습니다.


UNSPECIFIED
JPA 구현체가 정의한 설정을 따릅니다





오늘의 회고
오늘은 ORM이 등장하면서 어떠한 문제가 있었고, 이를 어떻게 해결했는지를 알아보았다.
공부하다 보니 평소에 JPA에서 쓰고있던 어노테이션들이 이러한 이유로 사용된다는걸 알아서 신기했다.
공부하면 할 수록 느낀점은 관계형 데이터베이스를 객체처럼 쓸 수 있게 해주는 JPA가 정말 편리한거 같다.



Spring - ORM의 탄생 배경 (JDBC, Query Mapper)
Thu, 07 Mar 2024 10:18:48 GMT

TIL
JDBC(Java Database Connectivity)


문장 그대로 Java 앱과 DB 를 연결시켜주기 위해 만들어진 기술이다.



그렇기 때문에 JPA 도 이 기술을 사용하여 구현되어 있다. 
JDBC Driver 는 여러타입의 DB 와 연결할 수 있는 기능을 제공한다.

JDBC Driver Manager 는 런타임 시점에
  -Connection(연결) 을 생성하여 쿼리를 요청할 수 있는 상태를 만들어주고
  -Statement(상태) 를 생성하여 쿼리를 요청하게 해주고
  -ResultSet(결과셋) 을 생성해 쿼리 결과를 받아올 수 있게 해준다.
꼭 사용후에는 각각 close() 를 호출해서 자원 해제를 시켜줘야 한다 (자원 관리)


> - JDBC를 통해서 INSERT와 SELECT를 해보았다 **(JPA를 사용했을때 보다 상당히 귀찮다)**
```java
public class JDBCTest {
>
@Test
@DisplayName("JDBC DB 연결 실습")
void jdbcTest() throws SQLException {
// given
>
String url = "jdbc:postgresql://localhost:5432/messenger";
String username = "tablenext";
String password = "pass";
>
// when
try (Connection connection = DriverManager.getConnection(url, username, password)) {
try {
  String creatSql = "CREATE TABLE ACCOUNT (id SERIAL PRIMARY KEY, username varchar(255), password varchar(255))";
  try (PreparedStatement statement = connection.prepareStatement(creatSql)) {
    statement.execute();
  }
} catch (SQLException e) {
  if (e.getMessage().equals("ERROR: relation \"account\" already exists")) {
    System.out.println("ACCOUNT 테이블이 이미 존재합니다.");
  } else {
    throw new RuntimeException();
  }
}
}
>
// then
  // DB 확인
}
>
@Test
@DisplayName("JDBC 삽입/조회 실습")
void jdbcInsertSelectTest() throws SQLException {
// given
String url = "jdbc:postgresql://localhost:5432/messenger";
String username = "tablenext";
String password = "pass";
>
// when
try (Connection connection = DriverManager.getConnection(url, username, password)) {
System.out.println("Connection created: " + connection);
>
String insertSql = "INSERT INTO ACCOUNT (id, username, password) VALUES ((SELECT coalesce(MAX(ID), 0) + 1 FROM ACCOUNT A), 'user1', 'pass1')";
try (PreparedStatement statement = connection.prepareStatement(insertSql)) {
  statement.execute();
}
>
// then
String selectSql = "SELECT * FROM ACCOUNT";
try (PreparedStatement statement = connection.prepareStatement(selectSql)) {
  var rs = statement.executeQuery();
  while (rs.next()) {
    System.out.printf("%d, %s, %s", rs.getInt("id"), rs.getString("username"),
        rs.getString("password"));
  }
}
}
}
>
@Test
@DisplayName("JDBC DAO 삽입/조회 실습")
void jdbcDAOInsertSelectTest() throws SQLException {
// given
AccountDAO accountDAO = new AccountDAO();
>
// when
var id = accountDAO.insertAccount(new AccountVO("new user", "new password"));
>
// then
var account = accountDAO.selectAccount(id);
assert account.getUsername().equals("new user");
}
}
```





JDBC의 문제점, QueryMapper의 등장


JDBC 로 직접 SQL을 작성했을때의 문제
SQL 쿼리 요청시 중복 코드 발생
DB별 예외에 대한 구분 없이 Checked Exception (SQL Exception) 처리
Connection, Statement 등.. 자원 관리를 따로 해줘야함
안해주면 메모리 꽉차서 서버가 죽음







이 문제 해결을 위해 처음으로 Persistence Framework 등장
Persistence Framework 는 2가지가 있다.
SQL Mapper : JDBC Template, MyBatis 👈 요게 먼저나옴
ORM : JPA, Hibernate




SQL Mapper (QueryMapper)
SQL ↔ Object
SQL 문과 객체(Object)의 필드를 매핑하여 데이터를 객채화



JDBC Template


SQL Mapper 첫번째 주자로 JDBCTemplate 탄생
쿼리 수행 결과와 객채 필드 매핑
RowMapper 로 응답필드 매핑코드 재사용
Connection, Statement, ResultSet 반복적 처리 대신 해줌
But, 결과값을 객체 인스턴스에 매핑하는데 여전히 많은 코드가 필요함





@JdbcTest // Jdbc Slice Test
@AutoConfigureTestDatabase(replace = Replace.NONE) // 테스트용 DB 쓰지 않도록
@Rollback(value = false) // Transactional 에 있는 테스트 변경은 기본적으론 롤백 하도록 되어있다.
public class JDBCTemplateTest {
>
  @Autowired
  private JdbcTemplate jdbcTemplate;
>
  @Test
  @DisplayName("SQL Mapper - JDBC Template 실습")
  void sqlMapper_JDBCTemplateTest() {
    // given
    var accountTemplateDAO = new AccountTemplateDAO(jdbcTemplate);
>
    // when
    var id = accountTemplateDAO.insertAccount(new AccountVO("new user2", "new password2"));
>
    // then
    var account = accountTemplateDAO.selectAccount(id);
    assert account.getUsername().equals("new user2");
  }
}


AccountTemplateDAO (Data Access Object)


package me.whitebear.jpastudy.jdbc.template;
>
import me.whitebear.jpastudy.jdbc.vo.AccountVO;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.jdbc.support.GeneratedKeyHolder;
import org.springframework.jdbc.support.KeyHolder;
import org.springframework.stereotype.Repository;
>
@Repository // Java 패키지에 있었다면 JdbcTemplate 생성자 주입받음
public class AccountTemplateDAO {
>
  private final JdbcTemplate jdbcTemplate;
>
  public AccountTemplateDAO(JdbcTemplate jdbcTemplate) {
    this.jdbcTemplate = jdbcTemplate;
  }
>
  //SQL 관련 명령어
  private final String ACCOUNT_INSERT = "INSERT INTO account(ID, USERNAME, PASSWORD) "
      + "VALUES((SELECT coalesce(MAX(ID), 0) + 1 FROM ACCOUNT A), ?, ?)";
  // coalesce 은 Postgresql 용 IFNULL
  private final String ACCOUNT_GET = "SELECT * FROM account WHERE ID = ?";
>
  //CRUD 기능의 메소드 구현
  //계정 등록
  public Integer insertAccount(AccountVO vo) {
    // 기본 코드 (응답값은 생성된 갯수)
    // return jdbcTemplate.update(ACCOUNT_INSERT, vo.getUsername(), vo.getPassword());
>
    // id 값을 받아오기 위한 코드
    KeyHolder keyHolder = new GeneratedKeyHolder();
>
    jdbcTemplate.update(connection -> {
      var ps = connection
          .prepareStatement(ACCOUNT_INSERT, new String[]{"id"});
      ps.setString(1, vo.getUsername());
      ps.setString(2, vo.getPassword());
      return ps;
    }, keyHolder);
>
    return (Integer) keyHolder.getKey();
  }
>
  //계정 조회
  public AccountVO selectAccount(Integer id) {
    return jdbcTemplate.queryForObject(ACCOUNT_GET, new AccountRowMapper(), id);
  }
>
}
MyBatis


SQL Mapper 두번째 주자로 MyBatis 탄생
반복적인 JDBC 프로그래밍을 단순화
SQL 쿼리들을 XML 파일에 작성하여 코드와 SQL 을 분리!
But, 결국 SQL을 직접 작성하는것은 피곤하다…(DB 기능에 종속적)
But, 테이블마다 비슷한 CRUD 반복, DB타입 및 테이블에 종속적이다.





@SpringBootTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.NONE)
@Import(DBConfiguration.class)
public class MyBatisTest {
>
  // Mapper 클래스를 받으려면 mapper.xml 빌드 해야하고, 그러려면 main 으로 옮겨서 해야함...
  @Autowired
  AccountMapper accountMapper;
>
  @Autowired
  AccountMapperV2 accountMapperV2;
>
  @Test
  @DisplayName("SQL Mapper - MyBatis 실습")
  void sqlMapper_MyBatisTest() {
    // given
>
    // when
    accountMapper.insertAccount(new AccountMyBatisVO("new user3", "new password3"));
    var account = accountMapper.selectAccount(1);
>
    // then
    assert !account.getUsername().isEmpty();
  }
>
  @Test
  @DisplayName("SQL Mapper - MyBatis V2 실습")
  void sqlMapper_MyBatisV2Test() {
    // given
>
    // when
    accountMapperV2.insertAccount(new AccountMyBatisVO("new user4", "new password4"));
    var account = accountMapperV2.selectAccount(1);
>
    // then
    assert !account.getUsername().isEmpty();
  }
}


AccountMapper.xml




>


>
  
>
  
    INSERT INTO account(username, password)
    VALUES (#{username}, #{password});
  
>

QueryMapper 문제점, ORM의 탄생


QueryMapper 의 DB의존성 및 중복 쿼리 문제점



ORM 은 DB의 주도권을 뺏어왔다고 표현해도 과언이 아니다.
ORM 은 DAO 또는 Mapper 를 통해서 조작하는것이 아니라 테이블을 아예 하나의 객체(Object)와 대응시켜 버린다.
말이 쉽지…. 객체지향(Object) 을 관계형 데이터베이스(Relation) 에 매핑(Mapping) 한다는건 정말 많은 난관이 있다.


오늘의 회고
JDBC, JDBC Template, MyBatis를 통해 평소에 JPA를 사용하여 했던 DB실습을 해보았는데,
하면 할 수 록 JPA가 굉장히 편하다는걸 느꼈다.
하지만 JPA를 사용하지 않는 기업들이 많기에..
쓰는법을 익히는 김에 등장 배경도 알아보았다.
(꼭 JPA를 사용하는 기업에 취업해야지)

ALL	모든 엔티티를 캐시합니다.
NONE	캐시를 사용하지 않습니다.
ENABLE_SELECTIVE	Cacheable(true)로 설정된 엔티티만 캐시를 적용합니다.
DISABLE_SELECTIVE	모든 엔티티를 캐시하는데 Cacheable(false)만 캐시하지 습니다.
UNSPECIFIED	JPA 구현체가 정의한 설정을 따릅니다

KIM_TABLE_NEXT

Scanner vs BufferedReader

프로그래머스(따로 입력처리를 하지 않아도됨)

백준(깔-끔)

Scanner

Scanner의 특징

Scanner 예시

InputStreamReader 란?

Scanner Vs BufferedReader

Scanner는 BufferedReader보다 타입에 구애받지 않는다.

BufferedReader는 Scanner보다 효율적인 메모리 용량을 가진다.

BufferedReader는 Scanner보다 안전하다.

BufferedReader가 Scanner보다 실행 속도가 빠르다.

결론

Project - 최종프로젝트 회고(+앞으로의 계획)

프로젝트 소개

수상내역

회고

Spring - 테스트코드 심화편 (Mock, Stub)

TIL

@Mock 객체와 가설(Stub) 세우기

가설(Stub) 세우면서 만난 문제들

가설 설정에는 가설 순서도 영향을 미친다.

UnnecessaryStubbingException

Loose Stubbing (lenient)

RedisTemplate NullPointerException

테스트 결과

오늘의 회고

Spring - @ModelAttribute, Paging 캐싱

TIL

Controller 청소하기

@ModelAttribute

이미지 업로드

Paging 캐싱 처리하기

오늘의 회고

Spring - 간편결제 API(TossPayments) 적용하기

TIL

TossPayments 적용하기

TossPayments 결제 흐름도

1. Client의 결제 요청, Toss의 인가코드 반환

2. 서버의 결제 승인 요청, Toss의 결제 승인 정보 반환

Toss payments API 프론트없이 테스트하기

테스트중 발생한 문제 (프론트의 부재)

테스트 툴을 통한 인가코드 만들기

참고자료

오늘의 회고

Spring - QueryDSL(+Paging, OrderSpecifier)

TIL

QueryDSL로 Paging, 정렬 구현하기

구현한 코드

Pageable

OrderSpecifier

구현을 하며 발생한 문제

왜 값이 들어가지 않았을까? (JSON 바인딩)

추천 게시물 보여주기

오늘의 회고

Spring - JPQL VS QueryDSL(+ BooleanExpression)

TIL

JPQL VS QueryDSL

기존 상품 검색 로직

QueryDSL

Boolean Expression

QueryDSL의 Like, Contains

오늘의 회고

Git - CI/CD (Github Actions)

TIL

최종 프로젝트 8일차

CI/CD란 무엇일까

CI (Continuous Integration)

CI의 핵심 목표는,버그를 신속하게 찾아 해결하고, 소프트웨어의 품질을 개선하고,

새로운 업데이트의 검증 및 릴리즈의 시간을 단축시키는 것에 있다.

CD (Continuous Delivery & Continuous Deployment)

Github Actions

Github Actions 적용하기

Github Actions를 통한 CI/CD 적용

오늘의 회고

Spring - 캐시(Cache), 직렬화(Serialization)

TIL

최종프로젝트 3일차

캐싱이란?