Robinjoon’s Develop Blog

전체

Java/Spring

프로젝트

Table

Kotest

Junit 과의 차이

사용법

스프링 부트와의 통합

Exposed란

공식 깃허브의 소개글이다.

Exposed is a lightweight SQL library on top of a JDBC driver for the Kotlin language. Exposed has two flavors of database access: typesafe SQL wrapping DSL and lightweight Data Access Objects (DAO).

With Exposed, you have two options for database access: wrapping DSL and a lightweight DAO. Our official mascot is the cuttlefish, which is well-known for its outstanding mimicry ability that enables it to blend seamlessly into any environment. Similar to our mascot, Exposed can be used to mimic a variety of database engines, which helps you to build applications without dependencies on any specific database engine and to switch between them with very little or no changes.

왜 JPA 냅두고 Exposed를 쓰나?

JPA는 영속성 컨텍스트와 1차 캐시, 변경 감지 등의 기능을 제공해준다. 이는 분명 편리한 기능이긴 하지만, 반드시 필요한 기능은 아니다. 또한, 이런 기능을 제공하기 위해 JPA와 Hibernate의 구조가 크고 복잡해 이해하기 힘들다.

또한, JPA와 코틀린의 궁합이 썩 좋지 않은 것도 문제다. JPA는 말 그대로 자바를 위한 것이기 때문에, 코틀린 환경에서 이를 사용할 때 문제가 발생하기도 한다. 당장 관련 키워드로 검색해 보면 사례가 많이 나온다. 물론, 대부분의 사례는 이미 명확한 해결법이 존재하기 때문에 문제가 되지 않을 수 있다. 그러나 모든 코드를 코틀린으로 작성한다면, 처음부터 코틀린을 위한 프레임워크를 사용하는 것도 합리적이라 생각한다.

DSL 방식 사용법

Exposed를 사용하는 방식은 공식적으로 DAO 방식과 DSL 방식이 있다. DAO 방식은 Spring Data JPA의 Repository와, DSL 방식은 QueryDSL 과 비슷한 사용 방식을 보여준다. 두 사용법 모두 명시적으로 커넥션을 얻고, 트랜잭션을 시작하는 API를 호출해야한다.

현업의 테이블 구조는 토이프로젝트와는 차원이 다르게 복잡하다. 따라서, 복잡한 쿼리가 필요하고, 이는 DSL 방식을 사용하는 압력으로 작용한다. 그래서, DSL 방식의 사용법을 익혀봤다.

DSL 방식으로 Exposed를 사용하기 위해서 필요한 클래스는 2종류다. 하나는 데이터를 담을 대상인 DTO이고, 다른 하나는 테이블을 표현하는 클래스다. 즉, JPA에서는 @Entitiy 어노테이션을 붙인 클래스가 데이터를 담을 대상이면서 테이블을 표현하는 클래스였지만, Exposed의 DSL 방식에서는 두 역할이 분리되어있다.

Exposed - 코틀린 SQL 프레임워크

2024/12/21

Kotlin

작성 완료

분산 트랜잭션

2PC 패턴

준비(prepare)

분산 트랜잭션에 참여하는 각 참여자(멤버 트랜잭션)에게 커밋할 준비가 되었는지 확인하는 단계다. 이 시점에 멤버 트랜잭션이 관여하는 행이나 테이블에 락이 걸린다.

각 멤버 트랜잭션은 커밋할 수 없는 상태인 경우 커밋할 수 없다는 응답(abort)을 코디네이터에게 응답하고, 커밋이 가능한 경우 가능하다는 응답(prepared)을 한다.

중요한 점은 멤버 트랜잭션의 커밋 가능 여부를 응답하는 것이지, 이 시점에 커밋이나 롤백이 진행되지 않는다는 것이다.

커밋(commit)

코디네이터가 모든 참여자에게 응답을 받았다면, 그 결과에 따라 커밋이나 롤백을 결정한다. 멤버 트랜잭션 중 하나라도 abort 응답을 했다면 롤백을 진행한다.

각 멤버 트랜잭션이 동시에 커밋이나 롤백이 되는 것이 아니라 시간 차이가 존재하게 된다. 그리고, 각 멤버 트랜잭션은 그 결과가 결정될 때 까지 락을 보유하고 있다.

한번 분산 트랜잭션의 커밋 여부가 결정된다면, 이는 그 어떤 경우에도 번복되지 않는다. 만약, 각 노드가 응답이 없다면 응답 할 때 까지 재요청을 무한히 수행한다.

단점

각 멤버 트랜잭션이 오랫동안 락을 보유한다. ⇒ 지연 시간이 증가할 수 있다.

NoSQL 등은 2PC 패턴을 지원하지 않는다.

분산 트랜잭션 - 2PC 패턴, Saga 패턴

면접 진행 과정에서 코틀린에 대해 아는 것이 있냐는 질문을 받았다. 코틀린은 전에 다른 기업 사전과제가 코틀린으로 작성해야 했기 때문에 문법을 살짝 공부한 적 있었다. 그 과정에서 느낀 현대적인 언어인 코틀린이 주는 편안함이 있었다고 말했다. 그런데 그 과정에서 코틀린과 자바를 함께 사용하는 환경에서 롬복을 사용하는데 문제가 있다는 글을 봤다는 이야기를 했다. 그리고 그 이유를 물어보셨다. 모르겠다고 하니 자바 컴파일 과정을 살펴보면 이유를 알 수 있을것이라 하셨다. 그래서 이 글을 쓴다.

자바 컴파일 과정과 롬복

자바 컴파일 과정을 한발 더 깊게 들어가면 다음과 같이 설명할 수 있다.

AST(Abstract Syntax Tree, 추상 구문 트리)

컴파일러는 본격적인 컴파일 과정 전에 소스 코드에 문법적으로, 의미적으로 문제가 없는지 확인해야 한다. 그리고 이를 위해 소스 코드를 분해해 트리 형태로 만든다. 이를 AST(Abstract Syntax Tree, 추상 구문 트리)라고 부른다. 왜 이런 자료구조를 만드는지는 컴파일러를 다루는 전문 서적이나 강의를 찾아보는 것이 좋을 듯 하다.

아무튼 핵심은 코드를 컴파일하는 과정에서 AST를 만들고 이를 활용해 실제 실행 가능한 명령어 형태로 바꾸는 것이다. 따라서, AST를 조작한다면 컴파일 과정에서 소스코드에는 없는 명령어를 추가하도록 유도할 수 있다.

어노테이션 프로세서와 롬복

자바에서 어노테이션을 컴파일 타임에 인식해 새로운 파일을 만들 수 있게 하는 공식 API다. javax.annotation.processing 패키지를 통해 제공되고, Processor 인터페이스를 구현하면 되나AbstractProcessor 추상 클래스를 상속하여 구현하는 것이 권장된다. 이 API를 통해 여러가지를 할 수 있다. Java 소스 코드를 생성하도록 할 수 있고, 필요하다면 다른 형태의 파일이 생성되게 할 수 있다.

그럼에도 불구하고, Lombok은 Java 컴파일러 내부에서 사용하는 API를 사용해 이런 제한을 넘어서 AST를 수정하는 방식으로 동작한다.

코틀린과 자바를 같이 쓸 때 컴파일 과정

코틀린과 자바를 같이 사용하는 환경에선 컴파일 과정이 조금 복잡해진다.

왜 코틀린과 자바를 같이 쓸 때 롬복이 문제가 되나?

얼마전 어떤 기업의 면접에서 이들의 차이를 질문받았다. 제대로 대답하지 못한 것 같아서 다시 정리해보았다.

블로킹과 논블로킹, 동기와 비동기 개념은 공통적으로 한 주체가 다른 주체에게 작업의 실행을 넘긴 상황을 구분하는 개념이다.

블로킹과 논블로킹

블로킹은 다른 주체가 작업을 끝낼 때까지 작업을 넘긴 주체가 다른 작업을 진행할 수 없는 것을 말한다.

반대로 논블로킹은 작업을 넘긴 주체가 다른 작업을 진행할 수 있는 것을 말한다.

즉, 블로킹과 논블로킹은 작업을 넘긴 주체가 넘긴 작업 말고 다른 작업을 계속 할 수 있는지 여부로 구분된다.

논블로킹의 경우에도 다른 주체에게 작업을 넘기는 순간에는 다른 작업을 할 수 없다. 하지만 보통 그 시간이 매우 짧아 작업이 끊기지 않은 것과 구분하는 것이 무의미하다.

동기와 비동기

동기는 넘긴 작업의 결과를 기다리는 것을 말하고 비동기는 넘긴 작업의 결과를 기다리지 않는 것을 말한다.

작업을 넘긴 주체가 결과를 기다리는 동안 다른 작업을 하는지 여부는 동기 비동기를 구분하는데 영향을 주지 않는다. 따라서 아래 두 도식은 모두 동기다.

동기 + 블로킹(좌), 동기 + 논블로킹(우)

비동기는 넘긴 작업의 결과를 특별히 기다리지 않는다. 따라서 비동기 작업의 결과를 처리하는 콜백 함수를 미리 지정하는 방식으로 후속 처리를 진행한다. 예를 들어 Java 에서는 CompletableFuture 를 이용해 비동기로 작업을 처리할 수 있다.

성능 테스트

성능이란

도서 실무로 배우는 시스템 성능 최적화에선 성능을 다음과 같이 정의한다.

고객의 특정 업무를 대상으로 운영환경하에서 고객이 수긍할 수 있는 응답시간 내에 처리할 수 있는 거래량

동일한 도서에서 다음과 같은 구절도 나온다.

응답시간은 사용자의 특성과 환경에 따라 요구하는 수준이 다르므로 동일한 응답 시간에 대해 고객마다 만족도는 다르게 나타난다. 이는 모든 시스템과 사용자에게 일률적으로 적용할 수 있는 응답시간의 기준은 없다는 것을 의미한다.

또 다른 도서 전문가가 알려주는 웹 퍼포먼스 튜닝에선 부하 테스트의 계획 단계에서 제시한 개요에는 시나리오가 포함된다. 시나리오의 내용은 다음과 같다.

어떤 부하를 가할지 결정
(어떤 동작을 하는 사용자를 몇 %로 가정하는가)
여러 시나리오를 준비하거나 동시에 병렬로 진행
예 : 로그인 → 달력 표시 → 예약 범위 선택 → 확인 화면 → 예약 실행이라는 동작을 하는 사용자 중 다시 한 번 실행하는 사용자가 5%

위 두 내용을 종합했을 때 서비스 개발자가 테스트해야 할 성능은 서비스 사용자가 서비스를 제대로 사용하기 위해 필요한 응답시간을 만족하면서 처리할 수 있는 거래량이다.

성능의 평가

도서 실무로 배우는 시스템 성능 최적화에선 TPS의 T에 대해 다음과 같이 언급한다.

TPS(Trsansaction Per Second)의 T를 고객의 업무 처리 건수가 되는 것이 고객과의 의사소통을 위해서나 업무 시스템을 평가하는 데 적합하다.
그러나, 시스템을 설계하고 분석하는 엔지니어 입장에서는 서버가 인식하는 트랜잭션 또한 시스템을 이해하고 개선 방향을 수립하는데 중요한 의미를 가진다.

요청 사용자 수가 증가하면 서버가 처리 해야할 요청이 많아지므로 응답시간이 점점 늘어난다. 하지만, 시스템 자원의 여유가 많다면 응답시간의 증가 폭 보다 처리하는 요청 수 증가 폭이 더 커서 TPS가 점점 늘어난다. 그러다가 시스템의 CPU의 약 70%정도를 사용하는 시점에서 시스템의 자원이 부분적으로 부족해 TPS는 일정 수치 내외를 유지한다. 최종적으로 CPU의 약 90%정도를 사용하는 지점부터는 시스템의 자원이 부족해 TPS가 떨어지게 된다.

TPS 증가가 멈추는 지점을 임계점이라 한다. 일반적으로 임계점에서의 동시 요청자 수를 늘리는 것을 목표로 하지만, 서비스의 특성에 따라 TPS가 일정하게 유지되는 구간을 늘리는 것을 목표로 하기도 한다.

무중단 배포 환경에서 신규 버전의 배포

배포 환경 가정

10대의 WAS 서버가 있다. 한번의 배포란, 특정 빌드 파일을 10대의 서버에 순차적으로 새 버전을 실행시키는 것을 말한다.

데이터베이스는 하나의 Source DB와 하나의 Replication DB로 이중화 되어있다.

데이터베이스의 스키마 변경은 미리 작업을 해두었다. 즉, 데이터베이스는 언제든 구버전의 기능과 신버전의 기능을 위해 준비되어있다.

배포는 각 WAS에 순차적으로 진행되는 Rolling 방식이다.

배포 도중 언제라도 사용자는 서비스를  사용할 수 있어야 한다.

신규 버전은 구버전에서 제공하지 않던 기능을 제공하는 것이 아니라 내부 구현이 변경된 것이라 프론트엔드 레벨의 변경은 없다. 

첫번째 생각

기존 버전에서 생성한 데이터가 데이터베이스에 있을테니, 신규 버전의 쓰기와 읽기 기능, 기존 버전의 읽기 기능이 포함된 중간 버전을 먼저 배포해야 한다. 그리고 모든 서버에 중간 버전이 배포되면 기존 버전의 읽기 기능이 삭제된 신규 버전을 배포하면 된다.

문제점

5번째 서버에 빌드 파일이 배포되는 시점에, 1 ~ 4번째 서버에는 중간 버전이 배포가 되어있다. 따라서, 그 시점에 사용자의 쓰기 요청이 1 ~ 4번째 서버에서 처리된다면 데이터베이스에는 신규 버전의 형태로 데이터가 쓰인다. 그런데, 동일한 사용자의 조회 요청이 6 ~ 10번째 서버에서 처리된다면 이 서버들에는 아직 신규 버전의 읽기가 불가능하므로 적절한 응답을 보내줄 수 없다.

신규 버전을 배포하기 위해 몇번의 배포가 필요할까?

Redis 보다 HTTP 최적화가 먼저다

더 높은 처리량을 보여주기 위해 별도의 덩치가 큰 기술을 도입하는 경우가 있다. 이는 아마도 덩치 큰 기업들에서 이런 기술을 도입해 자신들이 처한 문제를 해결하는 것을 보았기 때문이다. 그 대표적인 것으로 Redis를 뽑았지만 Redis 말고도 뭐 많다. 하지만, 이런 기술들을 도입하기 전에 기초적인 HTTP 레벨에서의 성능 향상을 꾀하지 않는다면 순서가 잘못된 것이다. 그런 의미에서 이번에 HTTP 레벨에서 성능을 향상시키기 위한 기술들이 무엇이 있는지 알아보았다.

HTTP 성능 최적화

HTTP 압축

Accept-Encoding 헤더를 통해 클라이언트가 수용할 수 있는 압축 알고리즘을 나열한다. 그리고 서버에서 이 알고리즘 중 하나를 선택해서 적용하고 Content-Encoding 헤더를 통해 클라이언트에 알려준다.

대표적인 알고리즘으로 gzip 알고리즘이 있다. 물론 이 알고리즘을 직접 구현할 필요는 없고 서버 프로그램(톰캣, nginx 등)에서 지원하며 이를 설정하면 된다.

압축되는 대상은 응답의 body다.

HTTP 압축이 적용된 요청

Spring Boot를 사용한다면 공식 문서에 나와있는 다음 설정을 통해 간편하게 적용할 수 있다.

Vary 헤더

압축과 직접적으로 관련있는 헤더는 아니지만, 압축을 하게 되면 반드시 설정해야 하는 헤더라 설명을 넣어봤다. 이 헤더는 요청의 URL 이나 메서드가 아닌 다른 헤더가 응답에 영향을 주었다면 이를 명시하는 헤더다. 이는 캐시의 키를 생성할 때 사용된다. 즉, 압축을 하므로 이 헤더에 Accept-Encoding 을 값으로 설정해야 한다.

Content negotiation - HTTP | MDN

In HTTP, content negotiation is the mechanism that is used for serving different representations of a resource to the same URI to help the user agent specify which representation is best suited for the user (for example, which document language, which image format, or which content encoding).

https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation

리소스 최적화

HTTP 성능 높이는 방법들

2024/09/06

네트워크

우테코

작성 완료

자바의 Thread

자바에서 스레드 기술은 태초의 Thread 클래스에서 부터 시작했다. 이후 이를 한 층 더 추상화하고, 스레드 풀을 쉽게 만들게 해주는 API가 추가되고, 스레드를 외부에서 종료시킬 수 있는 API가 추가되었다. 그리고 자바 스레드 기술의 최신 버전이 Virtual Thread다. 막 어려운 개념은 아니고, Process 로 동시성을 처리하다가 버거워서 Thread가 등장한 것 처럼, Thread로 동시성을 처리하기 버거워서 Virtual Thread가 등장한 것이다. 성능 향상을 불러오는 근본적인 이유도 같다.

Platform Thread

기존의 자바 Thread 인스턴스다. 이들은 운영체제가 제공하는 스레드를 살짝 감싸서 구현된다. 또한, 생성될 때부터 종료될 때까지 운영체제가 제공하는 스레드에 종속된다. 따라서 Platform Thread개수는 자바가 동작하는 운영체제의 OS Thread 개수에 제한된다.

운영체제는 스레드에 독립적인 스택 메모리 공간을 주고 그 외에도 여러 자원을 할당한다. 따라서, Platform Thread를 사용하는 것은 자바가 동작하는 운영체제의 제한에 크게 영향을 받는다. 대신, CPU 위주의 작업이던, IO 위주의 작업 모두 적절히 수행할 수 있다.

Virtual Thread

가상 스레드 역시 Thread 클래스의 인스턴스다. 다만, Platform Thread와 다르게 운영체제 스레드에 종속되지 않는다. 물론 실행은 운영체제의 스레드 위에서 실행된다.

운영체제 스레드에 종속되지 않기 때문에 Virtual Thread가 blocking I/O 를 사용하면 그 Virtual Thread만 블로킹 될 뿐, 운영체제 스레드는 블로킹 되지 않고 다른 Virtual Thread를 실행한다. 따라서, 컨텍스트 스위칭 비용이 JVM 레벨에서만 발생한다. 이로 인해 더 높은 처리량을 가질 수 있다.

하지만, CPU 연산 위주의 작업을 할때는 Virtual Thread가 적합하지 않다. Virtual Thread는 blocking I/O 상황에서 발생하는 Context Switching 비용을 줄여 높은 처리량을 가지는 것이지, 작업 실행 속도 자체가 빨라지는 것이 아니다.

Virtual Thread의 실행

Virtual Thread의 간략한 라이프 사이클

Virtual Thread도 결국 운영체제 위에서 동작하기 때문에 운영체제의 스레드가 Virtual Thread를 실행한다. 따라서 Virtual Thread는 런타임에 동적으로 몇개의 Platform Thread에 매핑되어 작업을 수행한다. 이 mapping 되는 것을 마운트라고 부르고, 마운트된 Platform Thread를 Carrier라고 부른다.

Virtual Thread가 I/O 등 블로킹 작업을 요청하면 마운트가 해제된다. 따라서 Thread 스케줄러가 다른 Virtual Thread 를 마운트 하여 실행할 수 있다. 나중에 Virtual Thread의 블로킹 작업이 완료되면 스케줄러에 제출되고 스케줄러가 이를 마운트한다.

Virtual Thread Pinning

생각하게 된 계기

우아한테크코스 교육과정에서 “데벨업”이란 이름의 개발자 취준생 커뮤니티 제작 프로젝트를 진행하고 있다. 프로젝트 진행 과정에서 개발 서버와 운영 서버를 분리하게 되었다. 따라서, 두 서버에 다른 이미지로 만들어진 컨테이너가 동작하게 된다. 만약, 이미지 관리를 하나의 레지스트리에서 한다면, 각 서버에서 어떤 이미지를 pull 받아야 하는지 결정하는 과정이 CD 에 추가되어야 한다. 복잡한 작업이 될것이라 예상되어 개발용 레지스트리와 운영용 레지스트리를 분리하는 방법을 찾게 되었다.

상용 서비스 vs 직접 운영

기본적인 레지스트리인 도커 허브에선 무료 플랜에선 프라이빗 레지스트리를 하나만 제공한다. 또 다른 서비스인 깃허브 패키지 역시 무료 플랜에선 용량과 트래픽 제한이 있다. 다른 상용 서비스들도 여럿 있지만, 프라이빗 레지스트리를 위해선 돈을 지불해야 한다. 반면, 직접 운영하는 경우 서버 임대 비용을 제외하면 별도의 비용이 발생하지 않는다. 따라서, 직접 레지스트리를 운영하는 방법에 대해 학습할 가치가 있다고 판단했다.

구축 과정

최종적으로 구현된 자체 레지스트리 웹페이지

위와 같은 레지스트리 웹페이지를 만든 과정을 소개한다.

레지스트리 컨테이너 띄우기

도커에서 공식적으로 레지스트리 라는 이미지를 제공한다. 이는 도커 레지스트리를 이미지로 만든 것으로 이를 이용해 컨테이너를 띄우면 레지스트리를 사용할 수 있다.

compose.yml

레지스트리에 https 적용하기

도커에서 레지스트리가 https 적용이 되어있지 않은 경우 거부하는 것이 기본 설정이다. 예외 설정을 할 수 있지만, 레지스트리를 따로 운영하는 이유가 보안 때문이므로 앞뒤가 맞지 않는다. 따라서 https 를 적용해야 한다고 생각했다.

레지스트리에 https를 적용하는 방법도 있다. 하지만, 추후 웹 UI 도 붙일 것이고 이 곳에도 https 를 적용해야 하는 것이 자명했다. 따라서 https 적용하는 것을 분리하여 nginx를 추가하고 리버스 프록시와 https 를 적용하는 것이 나을 것이라 판단했다. 아래는 이에 따라 변경된 compose.yml 이다.

compose.yml

도커 레지스트리 직접 운영하기

2024/08/18

Docker

보안

운영

작성 완료

Spring Data JPA 쓰니까 쿼리가 이상해졌어!

아니 이걸 왜 다 따로 불러와?

Spring Data JPA 를 이용해 사용자의 예약 목록을 조회하는 페이지에 접근했더니 다음과 같은 쿼리들이 발생했다.(스압 주의)

발생한 SQL

자신의 예약 정보를 조회하기 위해서는 그저 예약, 회원, 예약 시간, 테마 테이블을 모두 join 해서 한번에 쿼리를 작성하면 된다. 비록 쿼리가 복잡해지긴 하겠지만, 저 많은 쿼리를 다 따로 데이터베이스에 전송하면서 생기는 오버헤드보다는 아마 나을 것이다.

fetch type

JPA 에서는 @ManyToOne 과 같이 연관관계를 설정하는 어노테이션에 fetch 옵션을 제공해준다. 이 옵션은 FetchType.LAZY 와 FetchType.EAGER 중 하나로 설정할 수 있다.

LAZY 옵션은 연관 데이터가 실제로 필요한 시점에 조회해와라! 라는 옵션이고, EAGER 옵션은 연관관계를 무조건 조회해와라! 라는 옵션이다. LAZY 옵션은 연관관계의 id 값만 조회해오고, 실제로 연관 데이터가 필요할 때 이 id를 이용해 select 쿼리를 이용해 데이터를 조회한다. 반면, EAGER 옵션은 어차피 모든 연관 데이터를 조회할 것이기 때문에 처음부터 모든 데이터를 조회해온다.

이 옵션은 EntityManager.find 를 호출할 때 적용된다.

Spring Data JPA 너는 참 재밌는 친구구나!

JPA에서는 보다 객체에 가까운 형태의 언어인 JPQL 을 지원한다. JPQL은 연관관계를 이용하여 쿼리를 표현하기 때문에 SQL보다 훨씬 깔끔하고 읽기 좋다. 이를 통해 보다 쉽게 쿼리를 작성하고, JPA 의 구현체가 이 JPQL 을 적절히 번역하여 SQL 로 실행시킨다. JPQL 명령어중 fetch join 이 있는데, 이를 사용하여 쿼리를 작성하면 모든 연관 데이터가 한번에 조회된다.

Query Method

JPQL은 기존의 SQL에 비해 편리하지만 여전히 쿼리를 작성해야 한다. Spring Data JPA에서는 이를 한층 더 편하게 사용할 수 있도록 Query Method 라는 기능을 제공한다. 적절한 규칙을 지켜서 메서드 이름을 정한다면, 그 규칙에 따라 생성된 JPQL이 실행되는 구조다.

@Query

Wait, You Want Me to Delete All My Code? 

During Woowahan Tech Course Level 2, Mission 3, I encountered a requirement to modify existing code that used JdbcTemplate to utilize Spring Data JPA instead. And in the mission briefing, Coach Brown said this:

Unfortunately, you’ll need to delete your existing JdbcTemplate code!

Would You Only Be Happy if You Take It All?

How Can I Change My Code the Least?

The easiest solution is to just overhaul it.

I understood that it would be wise to address issues at their root, as leaving them unresolved might cause bigger problems down the line. I was stubborn, didn’t heed Gugu's advice, spent a day trying to work around it, and ended up overhauling it anyway. I wasted both time and failed to reach my goal. Now, halfway through Level 2, I stand at a similar crossroads.

Humans may repeat their mistakes, but without taking chances, there’s no growth. This time, I’m determined to achieve substantial gains with minimal changes.

Can’t I Just Add extends JpaRepository<Domain, Long>?

Initially, I thought I could simply add extends JpaRepository<Reservation, Long> and be done.

If I simply add extends JpaRepository<Reservation, Long> to the interface, it would look like this:

Let’s Easily Swap JdbcTemplate with JPA

아니 내 코드 다 지우라고? 

우테코 레벨 2 3번째 미션을 수행하면서 기존의 JdbcTemplate을 사용한 코드를 Spring Data JPA를 이용하도록 수정하라는 요구사항을 만났다. 그리고 미션을 소개하는 시간에 코치 브라운이 이렇게 말했다.

아쉽지만 기존에 있던 JdbcTemplate 코드는 지우세요!

꼭 그렇게 다 가져가야만 속이 후련하십니까? ㅠㅠㅠㅠ

어떻게 하면 내 코드를 최대한 덜 바꿀까?

레벨 1때도 비슷한 고민을 했다. 그때는 지금의 코드에 어떤 문제가 있었지만, 코드를 최대한 조금 수정하고 문제를 해결하고 싶어했다. 당시에 코치 구구와 이야기 했었는데 구구는 이런식으로 말했다.

지금 엎는게 제일 쉬운 방법이에요.

나중에 지금 덮어둔 문제가 큰 문제가 될 수 있으니 미리 싹을 뽑아놓는 것이 좋다는 취지로 이해했다. 그리고 결국 구구의 말을 듣지 않고 고집부리다가 하루를 날리고 결국 엎었다. 시간도 날리고 목표도 이루지 못한 것이었다. 시간은 흘러 레벨 2의 절반이 지나간 지금, 다시 선택의 갈림길 앞에 섰다.

인간은 같은 실수를 반복한다지만, 시도를 하지 않으면 발전도 없을 것이다. 이번에는 반드시 적은 수정으로 큰 이득을 얻어보고 싶었다.

그냥 extends JpaRepository<Domain, Long> 붙이면 안되나?

처음에는 단순히 extends JpaRepository<Reservation, Long>만 붙이면 되는줄 알았다.

만약 단순히 인터페이스 뒤에 extends JpaRepository<Reservation, Long> 를 붙여준다면,

JdbcTemplate 를 JPA로 손쉽게 갈아껴보자

처음 요청을 처리하는 곳은 DispatcherServlet 이다

HTTP 요청을 택배로 비유한다면 DispatcherServlet 는 물류센터에 비유할 수 있다. “(특별한 요청을 위해)보내다”라는 의미의 Dispatch 라는 단어가 붙은 대로 DispatcherServlet은 HTTP 요청을 처리하는 담당 클래스(= 핸들러)에게 HTTP 요청을 보내는 역할을 한다. Spring MVC 는 HttpServlet 을 이용해 클라이언트의 요청을 처리해 응답한다. DispatcherServlet은 Spring이 HttpServlet 을 구현한 구현체다.

DispatcherServlet이 처리해야 하는 작업들

우리가 @Controller 혹은 @RestController 어노테이션을 이용해 만든 컨트롤러에게 HTTP 요청의 처리를 위임해야 한다. 이를 위해선 다음 작업들이 수행되어야 한다.

어떤 컨트롤러 객체를 사용해야 하는지 결정

어떤 메서드를 사용해야 하는지 결정

메서드를 호출하기 위한 매개변수 생성

메서드의 반환값을 HTTP 응답에 적절히 표현

어떤 컨트롤러 객체를 사용해야 하는지 결정 : HandlerMapping

컨트롤러의 인스턴스는 Spring이 시작되면서 복잡한 과정을 통해 생성되어 Spring 컨테이너 내부에서 관리된다.

즉, 컨트롤러 객체는 이미 존재한다.

이 많은 컨트롤러 객체 중 어떤 컨트롤러 객체를 사용해야 하는지 결정하는 것이 HandlerMapping 이다.

HandlerMapping 은 인터페이스로 Spring과 Spring Boot 내부에 여러 구현체가 있다.

Spring Web MVC 동작 구조 - 대체 내 컨트롤러를 어떻게 실행할까?

의존

어떤 요소 A가 동작하기 위해서 다른 요소 B가 필요하다면, A가 B를 의존한다.

Ladder가 동작하기 위해서는 List<Line> 이 필요하다. 즉, Laddder는 List와 Line을 의존한다.

정말 간단하게 자바에서 import 하는 모든 것을 의존한다고 보면 된다. 단, 그게 전부는 아니다.

이하의 글에서 A 를 의존을 하는 쪽, B를 의존 대상 이라 표현한다.

주입

주입의 사전적 의미는 다음과 같다.

어떤 물체 안에 액체나 기체 따위를 집어넣음.
- 네이버 국어사전

어떤 대상의 외부에서, 내부로 무언가를 집어 넣는 것!

의존성 주입

의존을 하는 것이 의존 대상이 되는 것을 직접 만들지 않고, 외부에서 의존 대상을 집어 넣는 것!

조금 더 쉬운 이해를 위해 코드로 살펴 보자

개요

sealed 키워드에 대해 이해하기 위해서는 자바에서 인터페이스와 추상 클래스, 구체 클래스를 이용한 상속 구조를 이해하고 있어야 한다. 이 포스트는 독자가 이를 이미 이해하고 있다고 가정하고 작성했다.

Java 15에 Preview 로 추가되어 Java 17에 정식 기능으로 포함된 상위 클래스(혹은 인터페이스)에서 자신을 상속(구현)하는 클래스(인터페이스)를 제한하는 기능이다.

도입 배경

인터페이스, 추상 클래스, 구체 클래스를 이용한 견고한 코드

java-ladder

woowacourse

사다리 게임 미션의 요구사항 중 사다리에 대한 제약 조건이 있다.

•

사다리 타기가 정상적으로 동작하려면 라인이 겹치지 않도록 해야 한다.

사다리가 랜덤으로 생성되는 것이 타당하지만, 랜덤은 테스트하기 어렵기 때문에 랜덤으로 결정되는 부분을 외부에서 주입할 수 있도록 하는 것이 테스트에 유리하다. 아래는 이를 위한 인터페이스다.

List.of(true) = |-----| , List.of(true,flase,true) = |-----| |-----| 이런 라인과 대응된다.

랜덤으로 Boolean을 집어넣는 구현체를 다음과 같이 작성할 수 있다.

테스트 코드에서는 랜덤이 아니라 지정할 수 있도록 코드를 구현할 것이다. 그런데, 지금 구조에서는 이런 테스트 구현체가 fixInvalidBridges 와 비슷하게 true가 연속해서 나오지 않도록 강제할 수 없다.

sealed , non-sealed

2024/03/16

Java

우테코

작성 완료

아래 글에서 타입, 클래스, 역할, 책임 등의 용어는 객체지향의 사실과 오해 라는 도서를 참고하자.

객체를 어떻게 분류할 수 있을까?

타입(혹은 클래스)가 역할이 동일한 객체를 모은 집합이라면, DTO, VO의 개념은 여러 타입에 부여된 역할이 얼마나 비슷한지에 따른 분류다.

어떤 객체가 DTO 인가? 라는 질문은 그 객체가 속한 타입이 DTO 라는 분류에 속하는가? 라는 질문을 간단히 표현한 것이다.

어떤 역할을 하는 객체가 DTO 일까?

DTO는 데이터 전달 객체다

DTO 는 Data Transfer Object 의 약자다. 직역하면 데이터 전달 객체이다. 즉, 데이터를 전달하는 역할을 가진 객체를 DTO 라고 부른다.

DTO 는 데이터를 전달하는 역할을 가진 객체를 말한다.

데이터를 전달하는 역할을 수행하기만 하면 그것을 DTO라고 부를 수 있다. 즉, 도메인 로직이 구현된 객체를 데이터의 전달에 사용했다면, 그 객체는 DTO라고 할 수 있다.

레이어의 경계를 넘어갈 때 사용하는 것이 DTO다?

누군가는 MVC 패턴, 레이어드 아키텍처 등의 여러 패턴에서 정의한 영역 간의 데이터를 주고 받을 때 사용하는 것이 DTO 라고 말하기도 한다. 이는 DTO의 정의를 편협한 시각에서 내린 것이다.

아키텍처는 나도 만들 수 있다. 따라서 영역이라는 것도 내가 내맘대로 정의할 수 있다.

DTO가 가지면 좋은 특성

하지만, DTO로 분류된 객체가 데이터를 효과적으로 전달하기 위해 가지면 좋은 특징은 분명히 있다.

HTTP 1.1의 문제점

HoL Blocking

HTTP 는 TCP 위에서 구현된다. TCP는 신뢰성 있는 연결을 보장하는 프로토콜이다. 따라서, 연결과 해제 과정에서 확인 절차를 위해 많은 네트워크 통신이 발생한다. 즉, 한번의 TCP 연결에서 많은 데이터를 주고 받아야 TCP 연결과 해제 비용을 아낄 수 있다.

HTTP/1.1 은 HTTP 1.0이 한번의 TCP 연결에서 한번의 HTTP 요청과 응답만 처리하는 것을 개선하기 위해 파이프 라인 (큐)를 사용해 여러 HTTP 요청을 순차적으로 전송하고, 이에 대한 응답 역시 순차적으로 받을 수 있게 했다.

Head of Line Blocking = “맨 앞 차는 뭐하는거야?!”

HTTP/1.1에서는 여러개의 HTTP 요청을 하나의 TCP 연결에서 보낼 수 있지만, 요청 된 순서대로 그 응답을 받아 처리해야 하는 제약이 있다. 따라서, 먼저 보낸 HTTP 요청이 어떤 이유로 인해 처리하는데 오래 걸리면, 뒤의 요청이 이를 기다려야 한다.

이를 타계하기 위해 비교적 크기가 큰 이미지들을 하나로 붙인 이미지를 요청하고, 브라우저에서 스크립트 코드나 CSS를 이용해 잘라서 사용하는 등 별의 별 방법을 동원해 사용했다.

실제 네이버에 접속하면 가져오는 이미지

HTTP/2

HTTP/2의 목표

HTTP/2 는 처리량의 증가와 하위 호환을 목표로 했다.

HTTP/2는 앞서 설명한 HTTP/1.1의 문제점을 해결해, 더 짧은 시간에 더 많은 요청을 처리할 수 있어야 하면서도, 사용 편의성을 위해 제공되는 기능이나 핵심 개념(예: HTTP 메서드, 상태 코드, URI, 헤더 필드)은 변경되지 않아야 했다.

이런 목표를 달성하기 위해 HTTP 2는 새로운 레이어를 도입했다. 바이너리 프레이밍 레이어가 바로 그것이다.

바이너리 프레이밍 레이어

[네트워크] HTTP/2 - 새로운 구조

2024/03/02

작성 완료

등장 배경

자바 코드는 쓸데 없이 장황하다! ⇒ 바꿔 보자!

자바에서 좌표 평면 상의 위치를 표현하기 위한 클래스인 Point 클래스를 작성한다고 해보자. 당연히 내부에 x 와 y 좌표를 나타내는 필드 변수가 있을 것이다. 또한, 올바른 동등 비교를 위해서는 equals와 hashCode도 재정의해야 한다. 그리고 단순히 좌표 값들을 전달하는 용도로 Point를 사용한다면 getter도 정의해야 한다. 따라서, 아래와 같은 코드가 작성된다.

이런 코드에는 몇가지 문제가 있다.

개발자가 이들을 재정의 하는 것을 까먹을 수 있다.

IDE 를 이용해 이런 반복적인 코드를 쉽게 생성할 수 있지만, 그것이 Point 가 단순한 값의 전달 용 클래스 인 것을 알기 쉽게 해주지 않는다.

이런 문제를 “간결한 코드”로 해결 하기 위해 Record가 추가되었다.

Record를 사용해야 하는 경우

Record 는 단순한 값의 집합을 표현하는 클래스를 작성하는데 사용하는 것이 좋다.

문법

예를 들어 앞선 Point 클래스를 Record로 변경한다면 다음과 같은 코드로 작성할 수 있다.

한 것

페어 프로그래밍

두명이 짝을 지어, 하나의 컴퓨터를 이용해 한명(드라이버)은 코드를 직접 작성하면서 자신의 의도를 설명하고, 다른 한명(네비게이터)은 드라이버의 코드와 의도에 의문을 제시하며 함께 프로그래밍을 하는 방법.

알게 된 것

getter에 대하여

객체 지향 프로그래밍에서는 객체의 공개된 행동(메서드)을 통한 객체 사이의 의사소통으로 프로그램을 전개한다. 따라서, 객체 내부의 상태를 그대로 공개하는 getter는 객체지향 프로그래밍에서 지양한다.

그런데, 정말 getter는 무조건 피해야하는 걸까?

이번 미션에서는 자동차가 이동했다면, 실제로 이동했는지 확인해야 할 필요가 있었다. 하지만, 자동차의 위치를 getter로 가져오지 않으면서 이를 확인하고 싶었다. 이를 위해 나는 equals() 를 재정의 하였고, 다음과 같은 테스트 코드를 작성했다.

그리고 이에 대해 다음과 같은 리뷰를 받았다.

여러 경로를 통해 얻은 getter를 지양해야 하는 이유는 크게 두가지로 정리할 수 있었다.

객체의 내부 상태를 노출한다. ⇒ 다른 객체의 내부 상태에 의존하는 코드를 작성할 수 있다.

객체를 이상한 상태로 만들 가능성이 있다. ⇒ 참조형 데이터의 특성상 객체의 내부 상태를 외부에서 변경하게 될 수 있다.

버스트

프로세스의 실행은 CPU에 의해 명령어가 실행되는 것과, 입출력장치를 통한 작업을 기다리는 것을 반복하는 것이다. 이때, CPU에 의해 명령어가 실행되는 동안의 시간을 CPU 버스트라고 하고, 입출력 작업을 수행하는 동안의 시간을 IO 버스트라고 한다.

일반적으로 CPU 버스트는 매우 짧다. 아래 그래프는 일반적인 프로세스의 실행부터 종료까지 발생한 CPU 버스트의 빈도를 나타낸 그래프다. 물론, 프로세스마다 이런 그래프는 다 다르게 나타난다. 연산이 위주인 프로세스는 더 긴 CPU 버스트를 보일 것이다. 어쨋든 이런 분포는 스케줄링 알고리즘을 선택하는데 중요한 기준이 된다.

스케줄링 알고리즘 기초

스케줄링은 아래 4가지 상황에서 발생한다.

실행중인 프로세스가 실행 상태에서 대기 상태로 전환될 때. (입출력 발생, 자식 프로세스 종료 대기 등)

프로세스가 실행 상태에서 준비 완료 상태로 전환될 때. (인터럽트 발생)

프로세스가 대기 상태에서 준비 완료 상태로 전환될 때. (입출력 종료)

실행중인 프로세스가 종료될 때.

1번과 2번 상황에선 스케줄링이 무조건 발생한다. 그런데, 2번과 3번 상황의 경우 현재 실행중인 프로세스를 그대로 수행할 수 있는 상황이기 때문에 스케줄링이 발생하지 않아도 된다.

선점 스케줄링

2번과 3번 상황 중 적어도 어느 하나의 상황이 발생했을 때 스케줄링이 일어나는 알고리즘.

선점 스케줄링은 결국, 현재 실행중인 프로세스를 강제로 일시중지하고 다른 프로세스를 실행하는 것이다. 따라서 여러 프로세스가 공유하는 자원을 일시중지 대상인 프로세스가 접근하고 있다면 공유자원에 대한 프로세스간의 동기화문제를 해결해야 한다. 가령 일시 중지 대상의 프로세스가 공유 자원에 쓰기 작업을 하는 도중에 일시중지되고, 다른 프로세스가 이를 읽게 된다면 잘못된 상태의 공유 자원을 읽게 될 수 있다. 같은 이치로 모든 프로세스가 공유하는 커널영역의 어떤 변경을 유발하는 시스템 콜을 수행중인 프로세스를 일시중지하게 되면 문제가 발생할 수 있다. 따라서, 선점 스케줄링을 지원하려면 운영체제는 이런 문제가 발생하지 않도록 신경써야 한다.

[OS] CPU 스케줄링

2024/01/26

작성 완료

쓰레드

프로세스보다 작은 실행 흐름의 최소 단위이다. CPU의 기본 단위라 할 수 있다. 모든 프로세스는 최소 한개의 쓰레드를 가진다.

프로그램이 점점 복잡한 작업을 수행하게 되면서, 논리적으로 하나의 프로그램에 속한 작업들을 동시에 수행할 필요가 있게 되었다. 예를 들면 웹 서버의 경우 동시에 여러 사용자의 요청을 처리해야 하므로 각 사용자의 요청을 처리하는 작업을 동시에 수행해야 한다. 이를 위해 요청이 들어올 때 마다 새로운 프로세스를 만들어서 이를 수행하게 할 수 있다. 하지만, 프로세스를 새로 생성하는 것은 비용이 큰 일이고, 이렇게 생성된 프로세스가 수행하는 일이 기존에 있던 프로세스와 거의 같기 때문에 생성 비용, 컨텍스트 스위칭 비용이 크게 낭비되는 것이다.

이 외에도 여러 작업이 동시에 수행되면서, 서로 데이터를 공유해야 하는 상황이 발생하면, 앞선 포스트에서 정리한 방법들을 이용해 프로세스간 통신을 해야 하는데, 이 역시 비용이 크다.

이런 이유로 “프로세스 내부에 더욱 작은 작업의 흐름” 이라는 개념이 필요해졌다. 그것이 쓰레드다. 쓰레드는 별도의 실행 흐름을 가지기 때문에 별도의 레지스터와 스택 영역, 프로그램 카운터를 가지지만, 코드영역, 자료영역, 힙 영역은 프로세스 레벨에서 공유한다.

쓰레드의 개념이 등장하게 되면서, 결국 앞선 포스트에서 이야기한 스케줄의 대상이 프로세스가 아니라 쓰레드가 된다.

쓰레드의 장점

응답성 : 프로그램이 수행하는 작업들을 여러 쓰레드로 나누게 되므로, 사용자 응답성이 증가한다. 모바일 어플리케이션에서 서버와 통신하는 동안 다른 쓰레드가 화면을 랜더링할 수 있다.

자원 공유 : 앞선 포스트에서 다룬 공유 메모리 설정 같은 것이 없어도, 쓰레드사이에는 메모리를 공유하므로 자원 공유가 쉽다.

경제성 : 쓰레드는 프로세스 레벨에서 다른 쓰레드와 자원을 공유하기 때문에, 새로운 쓰레드를 생성하고, 컨텍스트 스위칭을 하는 비용이 프로세스의 그것보다 적다.

다중 처리기에서 이익 : 하나의 프로그램이 하나의 프로세스로 동작한다면, CPU가 여러개 있어도 하나의 CPU에서만 실행되므로 아무 장점을 누릴 수 없다. 하지만, 쓰레드는 서로 다른 CPU에서 실행될 수 있으므로 병렬성이 향상된다.

쓰레드 컨트롤 블록(TCB)

프로세스의 메타 정보를 PCB 라는 형태로 표현하는 것 처럼, 쓰레드 역시 그 메타 데이터를 TCB라는 형태로 메모리에 저장해야 한다.

PCB가 TCB의 리스트를 가리키고 있는 구조가 된다.

[OS] 쓰레드

2024/01/26

작성 완료

프로세스

메인 메모리에 적재되어 실행중인 프로그램이다.

여러 종류의 디스크에 저장된 프로그램 파일들은 CPU를 이용해 연산을 수행해야 하고, 각종 입출력장치와 데이터를 주고 받으며 동작해야 한다. 그런데, CPU의 동작 속도에 비해 디스크의 동작 속도가 느리기 때문에 CPU가 디스크에 저장되어있는 프로그램 코드를 직접 읽는 것은 아주 비효율적이다. 따라서, 비교적 용량이 작지만, 디스크에 비해 훨씬 동작 속도가 빠른 저장장치를 “메인 메모리” 라는 이름으로 중간에 두어 사용한다. 처음에 메모리에 프로그램의 코드와 기타 데이터를 미리 옮겨두고, CPU는 메인 메모리에서 코드를 읽어 CPU가 덜 낭비되게 된다.

메모리 구조

프로세스의 실행 코드와 각종 데이터는 메모리에 저장된다. 운영체제는 프로세스에 할당할 메모리를 적절한 용도로 구분하는 것이 유용할 것이다. 그렇게 운영체제는 메모리를 다음과 같은 구조로 할당한다.

•

스택 : 함수의 매개변수 및 지역변수, 함수 종료 후 복귀 주소 등 임시로 데이터를 저장하는 영역이다.

•

힙 : 프로세스 실행 도중에 할당되는 메모리 영역으로, 이 곳의 주소를 스택에서 참조하는 형태로 사용된다.

•

데이터 : 전역변수, 정적 변수가 저장된다.

•

텍스트 : 프로세스가 실행해야 하는 명령어가 저장되는 영역이다. 

PCB(프로세스 컨트롤 블록)

프로세스의 메타데이터를 표현한 자료구조다.

PCB에는 프로세스의 상태, 프로세스의 식별자, 프로세스가 사용하는 입출력장치 목록, 프로그램 카운터(다음에 실행할 명령어의 주소), cpu 레지스터 정보 등 운영체제가 프로세스의 실행을 위해 필요로 하는 정보를 포함한다.

이런 정보들은 당연히 메인 메모리에 저장되며, 아주 중요한 정보이므로 사용자 영역이 아니라 커널 영역에 저장한다.

[OS] 프로세스

2024/01/21

작성 완료

매직값 반환하기

매직값이란, 함수의 반환 타입에 부합하면서 특별한 의미가 부여된 값을 말한다.

예를 들어, 회원의 나이를 반환하는 함수 getAge()에서 회원의 나이가 등록되지 않은 경우 -1을 반환하는 경우가 매직값을 이용한 경우다.

매직값은 위험하다

매직값은 결국 그 함수의 내부 코드를 분석하거나, 관련 문서를 읽어야만 그 의미를 알고 그 함수를 호출하는 코드에서 이를 적절히 처리할 수 있다. 그렇지 않은 경우 문제가 생길 수 있고, 그 문제를 찾기조차 힘들 것이다.

아래 코드는 회원의 통계를 담당하는 클래스에서, 회원의 평균 나이를 계산하는 코드다.

논리적으로 오류를 찾을 수 없다. 하지만, Member.getAge()에서 매직값을 사용한 것 때문에 문제가 생긴다.

회원의 나이가 등록되지 않았다면 -1을 반환하기 때문에, 회원의 나이의 합을 구할때 문제가 생긴다.

게다가 이는 테스트코드로 확인하기 쉽지 않다. 애초에 이 코드를 작성한 개발자는 회원의 나이가 없을 경우를 생각조차 하지 못했다. 따라서, 회원의 나이가 등록되지 않은 경우를 테스트하는 것을 생각하지 못했을 것이기 때문이다.

매직값을 사용하는 것 보단 후술할 null을 반환하는 것이 좋다.

Null 혹은 Optional 반환하기

이런 코드는 java의 컬렉션 API에서 쉽게 찾을 수 있다. 아래는 Queue 인터페이스의 일부다.

도메인과 엔티티

도메인

소프트웨어가 동작하는 영역을 말한다. 즉, 소프트웨어를 통해 해결해야 하는 문제 영역이 도메인이다.

예를 들어 ATM에 탑재되어있는 소프트웨어의 도메인은 계좌, 은행, 카드 등이라고 할 수 있다.

Chat GPT와 함께 하는 도메인 영역이란?

도메인 로직

도메인 영역에서 해결해야 하는 구체적인 문제를 해결하기 위한 논리. 당연히 프로그램의 소스 코드와 마크업 코드로 구현된다.

은행의 예시를 들면, “송금을 하기 위해서는 송금할 금액보다 계좌의 잔액이 많거나 같아야 하고, 송금을 하는 계좌에서 잔액이 줄어들고 그만큼 송금 대상이 되는 계좌의 잔액이 증가해야 한다. 이 일련의 과정은 부분적으로 완료될 수 없고 모두 성공하거나 실패해야 한다.” 라는 논리가 도메인 로직의 일부가 될 것이다. 이를 코드로 표현하면 대충 아래와 같을 것이다.

엔티티

관계형 데이터베이스의 엔티티를 자바의 클래스로 표현했을 때, 그 클래스를 엔티티 클래스라고 하고, 그 인스턴스를 엔티티라 한다.

즉, 아래와 같이 JPA를 사용하는 상황에서 엔티티는 다음과 같이 생겼다. 아래 코드를 명확히 이해할 필요는 없다. 중요한 것은 아래 코드는 관계형 데이터베이스의 엔티티를 추상화한 자바 클래스라는 것이다.

도메인 로직을 엔티티에서 분리하는 것이 더 좋은 설계인가?

테스트 코드

테스트 코드 관련 용어 정리

실제 코드

실제로 서비스 제공을 위해 작성된 코드로 테스트 대상이 되는 코드다.

테스트 코드

실제 코드를 테스트하기 위해 실제 코드의 구성 요소를 참조해 함수를 호출하는 등의 동작을 하는 코드다.

일반적으로 실제 코드가 작성된 파일과 이를 테스트하는 코드가 작성된 파일은 일대 일 대응한다. 예를 들어 실제 코드를 Ball.lang에 작성했다면 테스트코드는 BallTest.lang에 작성 하는 것이 일반적이다.

테스트 케이스

각 테스트 코드에서 테스트 해야 할 시나리오를 구현한 것이다. 일반적으로 하나의 함수로 작성된다.

아주 단순한 테스트 코드가 아니라면, 기본적으로 3가지 단계를 가진다.

준비 : 테스트를 위한 인스턴스를 생성하거나, 의존성을 설정하는 단계.

실행 : 테스트를 위해 실제 코드의 함수를 호출하는 단계.

단언 : 실행 단계에서 실행한 결과가 원하는 대로 반환되었는지 확인하는 단계.

GitHub Actions?

깃허브에서 제공하는 자동화 도구다. 깃허브를 사용하는 거의 모든 행동을 트리거로 하여, 특정 작업을 자동으로 수행 할 수 있도록 해준다.

활용 예시

예를 들어, 특정 레포지토리의 특정 브랜치에 커밋이 되면, 이를 빌드하고, 테스트를 수행한 뒤 자동으로 서버에 배포하는 작업을 할 수 있다.

좀 더 복잡한 예시로는, Pull Request가 발생하면, 이를 빌드하고 테스트를 수행한 뒤, 빌드나 테스트가 실패하면 pr에 이에 대한 comment를 추가하고, Pull Request를 닫은 뒤, 이를 외부 메신저를 통해 개발자에게 알림을 보내 줄 수 있다.

장점

깃허브제어를 아주 쉽게 할 수 있다.

문서가 잘 되어있다.

수많은 오픈 소스를 활용해 쉽게 원하는 작업을 수행할 수 있다.

단점

사용량 제한이 있다.

다른 CI CD 도구에 비해 느리다.

GitHub Actions의 구조

하나의 저장소에 대한 여러개의 WorkFlow가 존재할 수 있다. 각각의 WorkFlow 는 여러개의 독립된 Job으로 구성된다. 각각의 Job은 여러개의 Step으로 구성된다.

Github Actions 제대로 써보기

scope 함수 : 별도의 메서드 생성 없이, 람다식을 메서드 본문으로 사용할 수 있도록 하는 것

https://sup2is.github.io/2022/06/17/kotlin-scope-function.html

? : null 가능 여부

var : 값 변경 가능. 단, 타입은 변경 불가

val : final 과 같이 초기값 설정 이후 값 변경 불가

const https://kimch3617.tistory.com/entry/Kotlin에서-val-와-const-val-의-차이

[Kotlin] kotlin data class 이해하기

이번 포스팅에서는! Kotlin에서 중요하고도 많이 쓰이는 Data class에 대해서 알아보도록 하겠습니다.

https://medium.com/kenneth-android/kotlin-kotlin-data-class-이해하기-7d7f51885075

[Kotlin] 🤚🏻 lateinit vs lazy, 정확히 아세요?

조금이라도 헷갈린다면 들어오세요!

https://velog.io/@haero_kim/Kotlin-lateinit-vs-lazy-정확히-아세요

코틀린 기본 문법 요약 정리 강좌 - [kotlin/cheat sheet]

코틀린의 기본문법을 치트형식의 예제코드와 설명을 포함한 깔끔하게 요약정리한 문법정리입니다. 코틀린 기본 문법 kotlin 기본 문법을 간략하게 파악 해보기 위한 요약 정리 입니다. kotlin 문법의 모든 내용을 다루지는 않지만 간략하게 훝어 보는 용도로 포스팅합니다. 변수 변수 선언 val name:String =

https://kimchanjung.github.io/programming/2020/05/06/kotlin-basic-syntax-summary/

코틀린 문법

2024/01/02

키워드 정리중

Join

Inner Join

조인 조건을 만족하는 경우만 조회한다.

Outer Join

조인 조건을 만족하지 않는 행도, 없는 컬럼을 NULL로 표시한다. 예를 들어 아래와 같이 두 테이블이 있는 경우

동시성 문제

여러 스레드가 동시에 실행될 때 발생하는 문제. 교착 상태, 데드락이 대표적이다.

교착 상태란 여러 스레드가 같은 공유 자원에 동시에 접근해 각 스레드가 공유 자원의 무결성이 깨지는 상황을 의미한다.

데드락이란, 여러 스레드가 서로를 블로킹해 스레드가 영원히 실행되지 않는 상황을 의미한다.

이런 문제를 해결하기 위해서는 공유 자원에 접근하는 코드(= 임계 영역)에 접근 가능한 스레드를 제한하는 방법을 사용한다.

synchronized

이 키워드가 붙은 메서드나 블록을 모니터를 사용해 동시에 하나의 스레드만 접근할 수 있도록 한다.

위와 같이 메서드에 synchronized 키워드가 붙은 경우 이 메서드는 동시에 하나의 스레드에서만 실행될 수 있고, 다른 스레드는 그 동안 블로킹된다. 따라서 다음 결과 처럼 하나의 스레드에 대해 lock 보유와 반환이 번갈아가며 등장한다.

동시성 제어가 없는 경우

단점

특정 스레드 입장에서, 해당 스레드가 락을 보유하고있는지 아닌지 코드로 알 수 없다.

약 1년전 공부하다가 도저히 이해가 안가던 부분을 이제는 이해할 수 있게 되어 포스팅을 이어 작성한다.

Java 8 : Future 의 Stream 버전, CompletableFuture 

java 1.5에서의 멀티 쓰레드 프로그래밍 다시 보기

java 1.5에서는 Executor, ExecutorService, ScheduledExecutorService, Executors, Future, Callable 을 이용해 보다 더 추상화된 방법으로 멀티 쓰레드 프로그래밍을 할 수 있다.

Future는 비동기 요청의 응답을 추상화한 인터페이스다! 비동기 요청의 응답이 완료여부 조회, 비동기 요청의 취소, 비동기 요청의 응답 조회 기능이 정의되어 있다.

이를 사용하기 위해서는 ExecutorService 를 사용해야 한다. 즉, Java 1.5 에서 추가된 새로운 멀티 쓰레드 프로그래밍은 다음과 같은 방법으로 수행된다.

이들의 사용 방식은 다음과 같다.

Executors 를 이용해 적절한 ExecutorService 구현체 인스턴스를 가져온다.

Callable 혹은 Runnable 의 구현체를 ExecutorService 의 각종 메서드의 매개변수로 사용하여 Future 인스턴스를 얻는다.

비동기로 실행한 작업의 결과가 필요할 경우 Future 의 인스턴스의 get()을 이용해 결과를 얻는다.

문제점

Future.get() 은 블로킹 방식으로 동작한다. 따라서, 해당 작업이 오랜 시간 걸리는 경우, 이를 기다리는 동안 다른 작업을 할 수 없다. 논 블로킹 방식으로 동작할 수 있는 것이 있다면, 미리 콜백 함수를 등록하고 비동기 작업이 완료된 경우 이를 알아서 수행하도록 하면 더 좋을 것이다.

작업을 Future 외부에서 종료시킬 방법이 없다.

@Service

@Repository

Spring 의 @Controller , @Service, @Repository 차이

2023/12/06

Spring

깃허브 레퍼지토리 웹 훅 설정

젠킨스 플러그인 설치

젠킨스 job 설정

디스코드 연동

[CI/CD] Jenkins Trigger 정보 Discord로 보내기

젠킨스 마스터 COUPANG www.coupang.com "이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다." 🗂 목차 ⚠️ 아래 목차 중 몇몇개의 링크가 걸리지 않는 문제로 글 맨 하단에 다음 글로 이동할 수 있게 해 두었습니다. ✅ [CI/CD] Jenkins와 Gitea 연동 ✅ [CI/CD] Jenkins Trigger 정보 Discord로 보내기 ✅ [CI/CD] 정적 코드 분석 툴 SonarQube와 Jenkins 연동 ✅ [CI/CD] SonarQube를 통해 Code Convention 적용 ✅ [DevOps] JAVA Gradle JaCoCo (Code coverage) 설정하기 ✅ [DevOps] JAVA Gradle JaCoCo (Code cove..

https://junyharang.tistory.com/386

젠킨스 시작하기

2023/12/02

팀 프로젝트

CI/CD

키워드 정리중

단순히 1개의 원소만 다루는 경우

List 자료구조의 구현 방식에는 각 요소를 포인터와 같은 방법으로 이어 구현하는 LinkedList와 배열을 이용하는 ArrayList가 있다. 각 구현 방식에 따라 다음과 같은 특성을 가진다고 알려져있다.

그런데, ArrayList의 경우 배열의 크기를 고려해야 한다. ArrayList가 사용하는 배열이 가득 찬 경우 배열을 다시 생성하고, 기존의 배열의 원소를 모두 새로운 배열로 옮겨야 한다. 이것이 고려되어야 하는 상황 즉, n개의 원소를 비어있는 리스트에 순차적으로 삽입하는 상황에서, 시간 복잡도를 다시 생각해 볼 필요가 있다.

n개의 원소를 순차적으로 다루는 경우

LinkedList의 경우, n개의 원소를 리스트의 마지막에 순차적으로 추가하는 경우 시간복잡도가 O(n)이다. 각 삽입에서 이미 마지막 원소의 주소를 알고 있기 때문.

ArrayList의 경우, n개의 원소를 리스트에 추가하는 과정에서 배열을 재할당하는 과정이 없다면 O(n)이지만, 재할당하는 과정이 있다면 O(n)이 아닐 수 있다.

 재할당을 고정 크기 만큼 하는 경우

배열이 가득 찬 경우, 기존 배열의 크기에 고정된 값 R 만큼 늘린 배열을 할당하는 방식이다.

시간 복잡도

최초 배열의 크기를 A 라 하면 재할당하는 횟수 T 는 다음과 같다.

T = ⌈\frac{n-A}{R}⌉

⌈ ⌉ 기호는 올림을 의미한다.

최초 재 할당 시 A개의 원소가 이동한다. 이후 할당 할 때 마다 이전의 재 할당에서 이동한 원소의 개수보다 R개 더 많은 원소가 이동한다. 따라서, 총 이동 횟수는 초항이 A이고, 등차가 R인 등차수열의 T번째 원소까지의 합 만큼 수행된다. 등차수열의 합 공식을 적용하면,

[자료구조] 배열로 구현된 리스트의 순차 탐색

2023/11/22

Java

작성 완료

기존 모듈의 문제점

속도가 느리다

데이터 수집 속도의 중요성

데이터의 갱신이 실제 서비스에 반영되는데 걸리는 시간은 서비스의 품질을 의미한다.

편의점 할인 행사 품목은 하루에 한번 자정에 변경된다. 따라서, 매일 자정에 해당 정보를 수집해야 우리 서비스가 제대로된 할인 정보를 수집할 수 있다. 데이터의 원천이 우리 서비스가 아니기 때문에, 이를 수집하는데 시간 차이가 발생하게 된다. 서비스의 품질을 올리기 위해서는 이 시간 차이를 최대한 작게 하는 것이 중요하다.

기존 모듈의 동작 속도

개선 전 모듈의 동작 속도 : 총 30분이 걸린다.

기존 모듈이 동작을 완료할 때 까지 30분이 걸렸다.

서비스가 제대로 동작하지 않는 상황이 30분이상 지속될 가능성을 의미한다.

모듈의 동작 환경에 필요한 것이 많다

아래 코드는 기존 모듈의 python 코드의 일부분이다.

기존 모듈이 크롤링하는 웹 페이지들은 모두 동적생성된 웹 페이지다. 즉, 뼈대가 되는 HTML, CSS, JS 파일을 서버에서 불러온 뒤, 실제 데이터는 별도의 HTTP 통신을 통해 가져와 DOM을 수정하는 형태로 제공되는 웹 페이지다. 따라서, 단순한 정적 크롤링으로 데이터를 수집할 수 없다.

보통 이런 웹사이트를 크롤링할 때는 브라우저의 드라이버를 사용해 사람이 브라우저를 사용하는 행동을 모방하여 데이터를 수집한다. 쉽게 말해, 클릭 매크로의 기능이 정적 크롤링에 추가된 방식이다.

[프로젝트] 편킹 데이터 수집 모듈 성능 개선기

2023/11/02

팀 프로젝트

작성 완료

[프로젝트]편킹 추천 알고리즘 설계 과정

이전 포스트에서 편의점 할인행사 모아보기 서비스인 편킹에서 추천 알고리즘을 어떻게 설계했는지 작성했다. 오늘은 이때 사용하는 데이터들을 DB에 저장하면서 MariaDB의 JSON 타입을 사용한 것에 대한 기록을 할 것이다.

MariaDB JSON 타입

JSON Data Type

Compatibility data type that is an alias for LONGTEXT.

https://mariadb.com/kb/en/json-data-type/

공식 문서를 보면, MariaDB에서 JSON 은 LONGTEXT의 이명이다. 즉, 아래 두 쿼리는 동일한 테이블을 생성한다.

따라서 두 경우 모두 아래와 같은 INSERT 쿼리를 통해 데이터를 저장할 수 있다.

의도 그대로 JSON형태의 데이터만 저장하고 싶다면 아래 쿼리 처럼 별도의 제약 조건을 부여해야 한다.

사실, 이러한 것 보다는 MariaDB에서 JSON 을 활용하기 쉽도록 제공하는 함수들을 사용하는 것이 MariaDB 에서 JSON을 사용하는 핵심이라 할 수 있다. 이러한 함수들은 공식 문서에서 확인할 수 있다.

JSON Functions

https://mariadb.com/kb/en/json-functions/

어떤 데이터가 JSON 타입을 사용하기 적합할까?

우리 서비스에 JSON 타입을 적용한 부분

[프로젝트] MariaDB JSON 타입 사용기

2023/10/18

팀 프로젝트

작성 완료

mariadb에서 로그 확인 ⇒ enum 이 이상한 문자열로 바뀌어 전달되는 것 확인

⇒ jpa 메서드에서 enum 말고 그냥 String 넘겨주게 하고, 매개변수로 enum.name() 넘김

@Query(native = true) 에서만 발생하는 오류인 듯?

Invalid utf8mb4 character string: 'ACED00’ 해결

2023/10/16

Spring

키워드 정리중

개인화된 추천목록 제공을 위한 정보

편의점 할인 행사 정보를 모아보여주는 우리 서비스에는 개인화된 추천 목록을 제공한다. 이를 위해서는 사용자 행동 추적 정보, 상품의 특성 정보 를 저장해야 한다.

•

사용자 행동 추적 정보 : 우리가 누군가에게 맛있는 음식을 소개하려면, 상대의 음식 취향을 알아야 한다. 이런 취향은 상대방이 어떤 음식을 좋아하는지 직접 말하거나, 어떤 음식을 주로 먹는지 관찰하여 알아낸다. 우리 서비스도 마찬가지로, 사용자에게 개인화된 추천 목록을 제공하기 위해서는 사용자가 서비스를 사용하는 행동을 추적하고 이를 저장할 필요가 있다.

•

상품의 특성 정보 : 우리가 누군가에게 맛있는 음식을 소개하려면, 음식의 맛이나 향, 성분과 같은 정보를 알아야 한다. 우리 서비스도 마찬가지로, 사용자에게 개인화된 추천 목록을 제공하기 위해서는 상품의 특성을 추출하고 이를 저장할 필요가 있다.

사용자 행동 추적 정보

서비스에서 추적할 수 있으며 의미가 있는 정보는 서비스마다 조금씩 다를 것이다. 우리 서비스에서는 검색기록, 상품 정보 조회 기록, 리뷰 작성 및 조회 기록이 유의미하다 판단했다. 이 중에서 우선 우리 서비스에서는 리뷰 조회와 작성 기록을 이용해 보기로 했다. 서비스의 UX 설계상 리뷰를 조회하는 시점과 상품의 정보를 확인하는 시점이 일치하기 때문이다.

앱 화면 - 상품 정보 조회 페이지

리뷰 조회나 작성 기록에 어떤 데이터가 포함될지 생각해봐야 한다. 우선, 어떤 상품에 대한 리뷰인지 알아야 한다. 또한, 상품의 할인 정보는 변경될 수 있으므로, 할인의 종류 역시 저장해야 한다. 마지막으로, 언제 접근했는지 그 시간을 알아야 한다. 이를 정리하면 다음과 같은 JSON으로 표현할 수 있다.

이때, 할인 정보를 저장하는 테이블과 상품 정보를 저장하는 테이블은 외래키로 관계를 맺고 있으므로, 실제로는 할인 정보의 PK 만 저장하면 된다. 다시 정리하면 다음과 같은 JSON으로 표현할 수 있다.

상품의 특성 정보

상품의 특성 정보에 어떤 데이터가 포함되어야 하는지 역시 서비스마다 다르다. 이를 결정하기 위해선, 우선 보유하고 있는 데이터를 파악해야 한다. 서비스 구축을 위해 우리가 수집한 상품&할인 정보는 다음과 같다.

상품 이름

[프로젝트]편킹 추천 알고리즘 설계 과정

2023/10/08

팀 프로젝트

작성 완료

시스템 요구사항

생각의 흐름

인증 토큰? JWT? 세션?

그림 1. 기본적인 인증 구조

처음 생각한 인증 구조는 위와 같았다. REST API로 로그인을 하면 일종의 인증 토큰이 발급되고 이를 인증이 필요한 API 요청을 할 때마다 헤더에 실어 보내는 구조다. 일반적인 상황이라면 JWT 를 사용하면 간단하지만, 이 조건을 충족하려면 인증 정보를 어떤 방식으로든 서버에 저장해야 했다. 그래야 기존의 인증 토큰으로 인증을 시도할 때 거부할 수 있기 때문이다. 이를 위한 가장 간단한 방법은 전통적인 세션을 사용하는 방식이다.

그런데, 두 API서버가 WAS 단위로 분리되어있기 때문에 같은 세션을 사용하기 위해서는 추가 설정이 필요하다.

분산 환경에서 세션 문제 해결하는 방법

여러 서버가 같은 세션을 가져야 하는 상황이 분산 환경에서 많이 발생할 것이라 생각하여 분산 환경에서 세션 문제를 어떻게 처리하는지 알아보았다.

분산 환경에서 위와 같은 세션 문제를 해결하기 위한 방법으로 Sticky Session 과 Session Clustering 을 들 수 있다. 전자의 경우 세션아이디를 이용해 로드밸런싱을 하는 것으로, 모든 요청이 하나의 서버로 전달되는 것을 보장하기 때문에 분산 서버들끼리 같은 세션을 공유할 필요가 없다. 후자의 경우 세션 정보를 공유하는 방식으로 세션을 생성할 때 분산 서버들에 모두 동일한 세션을 생성하거나, 하나의 공통된 세션 저장소를 공유하는 방식이다. 우리가 해결해야 하는 상황과 비슷한 것이 Session Clustering 이다. 자세히 알아볼 필요가 있었다.

Session Clustering

기본적으로 여러 서버가 같은 세션을 공유하는 가장 간단한 방법은 중앙화된 세션 저장소를 만들고 모든 서버가 이 중앙 세션 저장소에 접근하여 세션 정보를 확인하는 것이다. 이 방법은 모든 트래픽이 결국 중앙의 세션 저장소에 집중되므로 세션 저장소의 부하가 문제가 될 수 있다.

다른 방법으로는 각각의 서버가 독립된 세션 저장소를 가지되, 세션 정보의 추가, 변경, 삭제가 발생하였을때 일종의 이벤트가 발생하게 하고 각각의 서버(혹은 세션 저장소)가 이 이벤트를 처리해 반영하는 방법이 있다. 부하가 분산된다는 장점이 있겠지만 당연히 구현이 쉽지 않을 것이다.

서비스 초기에 트래픽이 많을리 없으니 일단 중앙의 세션 저장소를 두는 방식을 선택했다.

Redis 를 이용한 인증 시스템 구축

System Requirements

Authentication information is generated by the REST API server.

The same authentication information must be usable by both the REST API server and WebSocket server for user authentication.

A user can only be logged in on one device per client platform supported by the system.

Thought Process

Authentication Token? JWT? Session?

Figure 1. Basic Authentication Architecture

In the diagram above:

•

The yellow box represents the client application.

•

The red box represents the authentication token.

•

Arrow 1 indicates a login request.

•

Arrow 2 represents the response containing authentication information.

•

Arrow 3 signifies a subscription.

•

Arrow 4 denotes an API request that requires authentication.

Building an Authentication System Using Redis

추상 클래스와 인터페이스는 모두 다형성을 구현할 때 사용하기 적절하다. 그런데 두개가 따로 있는데는 분명히 이유가 있을 터, 두가지의 특징을 알아보고 언제 어떤 것을 사용할지 정리해 보았다.

정리하게 된 배경 스토리

프로젝트에서 Let’s Encrypt 인증서가 자동 갱신되지 않는 현상이 있었습니다. 이를 해결하기 위한 공부 과정에서 알게된 내용들을 두개의 포스트로 나누어 정리하게 되었습니다. 이 포스트는 이중 첫번째 포스트로 인증서가 무엇인지, Let’s Encrypt와 작동 원리를 다룹니다.

인증서란?

인증서는 공개키와 공개키의 소유자를 연결해주는 전자문서로, 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장하기 위해 사용한다.

인증서는 개인이 발급받아 개인의 신원을 식별하기 위해서도 사용한다. 과거에 인터넷 뱅킹을 이용하기 위해 사용하던 공인인증서가 바로 그것이다.

인증서의 작동 원리를 이해하기 위해서는 공개키 기반 구조(PKI,Public Key Infrastructure)와 전자서명 기술을 이해해야 한다. 전자서명 기술은 비대칭 암호화와 (암호학적)해시를 이해해야 한다.

공개키 기반 구조(PKI,Public Key Infrastructure)

메시지의 암호화 및 전자 서명을 제공하는 복합적인 보안 시스템 환경을 말한다.

현실에는 개인의 신원을 파악하기 위해 사용되는 신분증과, 신분증을 발급하고 유효성을 검증해주는 주민센터등의 관청이 있다.

인증서도 신분증과 마찬가지로 인증서를 발급하고, 인증서를 검증해주는 기관이 필요하다. 이런 기관을 CA 라고 한다. 한단계 더 나아가서 CA 는 어떻게 신뢰할 수 있을까?

계층형 CA

CA는 계층구조를 가진다. 하위의 CA는 상위의 CA가 인증해주고, 상위의 CA는 더 상위의 CA가 인증해주는 방식이다.

이런 계층 구조는 재귀함수 처럼 끝도 없이 이어질 수는 없는 노릇이니 최상위의 CA 즉, RootCA라는 개념이 필요하다. RootCA 는 자기 자신이 스스로를 인증한다. 이게 대체 무슨 소린가 싶겠지만, RootCA 를 보증하는 기관은 보통 각 국가의 정부다.

전자서명

인증서와 Let’s Encrypt 1편

쿼리가 이상해요

지금 진행하고 있는 프로젝트에서, JPA 를 도입했다. 기존의 JdbcTemplate 기반의 코드들을 다 지워버리고 JPA를 이용해 좀 더 객체지향적인 코드를 작성할 수 있었다. 어느정도 기능 구현을 완료하고 기능이 잘 동작함을 테스트 하던 도중 이상한 문제를 만났다. 바로 쿼리가 엄청나게 많이 발생하는 현상이었다.

나는 그저 엔티티 하나만 조회했는데, SQL이 이렇게나 많이 필요하다고?

이번 프로젝트에서 사용하는 핵심적인 엔티티 클래스들을 다이어그램 으로 표현하면 이렇다.

정리하면

Certification 은 Goal 을 필드로 가지고, Goal 은 Certification 의 List를 필드로 가진다. ManyTimeGoalCertDate 클래스는 Goal 의 자식클래스인 ManyTimeGoal 을 필드로 가지고, ManyTimeGoal 클래스는 ManyTimeGoalCertDate 의 List를 필드로 가진다.

이 상태에서 findAll() 메서드를 통해 전체 Goal 을 조회한 뒤 내부 값을 출력하는 코드를 수행하면

실행되는 쿼리

총 5개의 쿼리가 실행되는 것을 볼 수 있다. 이 때 조회된 Goal 객체는 단 2개이다. 조회되는 Goal 객체가 12개가 되면 21개의 쿼리가 실행되었고, 42개가 되면 66개의 쿼리가 실행되었다. 즉, 조회되는 객체의 개수가 늘어날 수록 그에 비례하여 실행되는 쿼리의 개수가 따라서 늘어났다.

N+1 문제

이렇게 복잡한 연관관계를 맺고 있는 엔티티들을 조회할 때, 부모 엔티티의 개수에 비례해 SQL 쿼리가 발생하는 현상을 N+1 문제라고 한다.

N+1 문제는 지연로딩,즉시로딩 두 상황에서 모두 발생한다.

N+1 문제 해결법

목록 조회

목록 조회의 뜻

이 글에서 목록 조회란 아래 사진처럼 어떤 일정한 형태의 데이터로 이루어진 목록을 서버로부터 불러오는 것을 말한다.

목록 조회

항목조회

이 글에서 항목 조회란 목록을 구성하는 최소단위의 데이터를 서버에서 불러오는 것을 말한다. 예컨데, 아래 사진은 위 목록 조회 사진에서 각 항목을 클릭했을때 보여지는 화면이다. 이때 항목조회가 이루어진다.

항목 조회

목록 조회와 항목조회를 하는 방법

목록조회 결과 화면에서 항목조회 화면으로 넘어가는 것을 구현하는 방법은 크게 2가지를 생각할 수 있다.

목록조회시 한번에 항목들의 세부정보를 서버에서 불러오는 방법

이 방법은 네트워크로 요청이 단 한번만 보내진다는 장점이 있다. 대신, 목록을 조회한 이후 시간이 지날수록 각 항목의 상세 데이터가 실제 서버 내의 데이터와 일치하지 않을 가능성이 높아진다.

목록 조회시에는 최소한의 정보만 조회해오고, 각 항목 조회시 세부정보를 서버에서 불러오는 방법

이 방법은 네트워크 요청이 목록 조회시 한번, 상세 데이터 조회시 한번 이루어진다. 따라서, 각 항목을 모두 조회한다면 네트워크 요청 횟수는 n+1 번이 된다. 대신, 목록 데이터를 조회한 이후 시간이 지나도 상세 데이터는 언제나 서버내 데이터와 일치한다.

두 방식은 데이터의 신선도와 네트워크 부하를 맞바꾼 방식일까?

얼핏 보면 두 방식은 데이터의 신선도와 네트워크 부하를 맞바꾼 그런 관계인듯 싶다. 하지만, 여기에 함정이 있다.

Logging 작업을 정리한 계기

지금 진행하고 있는 골키퍼 버전2 프로젝트를 개발하면서 구글 로그인 기능을 처음 구현했다. 처음 하는 거다보니 예상하지 못한 오류들이 많이 발생했고, 브레이크 포인트를 걸면서 확인해가기에는 오류가 너무 많았다. 그래서 Logging 작업을 철저히 해놓고 다시 오류를 고쳐나가기로 했다.

오류가 났는지 정확히 확인하기 위해서는 http 요청, 비즈니스 로직을 타면서 호출되는 Spring Bean, http 응답 정보를 기록해야 한다고 판단했다.

Logging 이란?

본론에 들어가기 전에, Logging이 뭔지부터 정의하고 넘어가보자. 요즘 핫한 ai 에게 Logging 이 뭐냐고 물어보면 이렇게 대답해준다.

Logging is the process of recording events or information in a computer system for the purpose of analysis, tracking, and debugging. It allows developers to monitor the behavior of their software, understand and diagnose issues, and gain insights into how it's being used. Logs can also be used for auditing, performance analysis, and security purposes.
-Chat GPT

한국말로 번역하면, “컴퓨터 시스템에서 발생하는 각종 이벤트나 정보들을 기록하는 작업으로 분석, 추적, 디버깅을 그 목적으로 한다.” 라고 번역할 수 있다.

Spring Boot 에서 Logging

Spring Boot, 정확히는 implementation 'org.springframework.boot:spring-boot-starter-web' 을 적용한 Spring MVC 웹 시스템에서 로그를 남길때 사용할 만한 기술들은 4가지 정도가 있다.

Filter

자바로 웹 개발을 할 때 사용되는 원천기술인 Servlet 스택에 포함된 요소이다. Servlet 컨테이너가 요청을 올바른 Servlet에 전달해 주기 전에, Filter를 거치게 된다. 그림으로 표현하면, 이런 식이다.

Spring Boot에서 Filter 의 동작 위치

즉, Spring 컨테이너와 무관한 내용들(http 요청)을 로그로 남기기에 적당한 위치라고 볼 수 있다.

Interceptor

Spring MVC Framework 에서 제공하는 기술로, 컨트롤러 실행 전후에 특정 작업을 추가할 수 있도록 하는 구성 요소이다. 다수의 컨트롤러에 대해 동일한 기능을 적용해야 할 때 사용할 수 있는 것이다. 그림으로 표현하면

Spring Boot REST API System Logging

2023/01/31

Spring

인덱스란?

DB의 테이블의 동작속도를 향상시키기 위해 DBMS 내부에서 사용하는 자료구조. 책의 목차나 색인과 같은 역할을 한다.

인덱스 이미지 출처 : https://mangkyu.tistory.com/96

테이블의 각 row 들은 별도로 정렬되어있지 않고 아무렇게나 삽입되어 있다. 따라서, 테이블에 특정 행을 조회하는 경우 테이블 전체를 탐색하는 FULL-SCAN 이 발생하게 된다.

테이블의 특정 컬럼에 인덱스를 생성하면, 인덱스 테이블이 생성되는데, 이 인덱스 테이블은 key-value 형태를 가진다. 이때 key 는 인덱스를 설정한 컬럼의 데이터가 되고, value 는 원본 테이블의 각 row 를 가리키는 pointer 가 된다. 중요한 점은, 인덱스 테이블은 정렬되어있다는 점이다. 따라서, 인덱스를 사용하면 FULL-SCAN 이 발생하지 않고 인덱스를 이용해 빠르게 검색할 수 있게 됩니다.

인덱스를 사용할때의 장점

•

검색이 빨라진다.

인덱스를 사용할 때의 단점

•

용량이 증가한다.

•

잘못된 인덱스 사용은 오히려 성능의 감소를 불러오게 된다.

인덱스를 설정할때 고려해야 할 점

쿼리를 더 효율적으로 작성할 방법은 없는지 생각한다.

해당 테이블이 조회가 자주 발생하고, 변경은 적게 발생하는 테이블인지 확인 한다.

Cardinality 가 높은 컬럼에 인덱스를 걸어준다.

DBMS 가 인덱스를 구현할 때 사용하는 자료구조

[데이터베이스] DB 인덱스

2022/12/22

동기와 비동기

https://evan-moon.github.io/2019/09/19/sync-async-blocking-non-blocking/

https://deveric.tistory.com/99

https://inpa.tistory.com/entry/-동기비동기-블로킹논블로킹-개념-정리

처리해야 할 작업들이 여러개 있을때 이들을 바라보는 서로 다른 두가지 관점

작업의 실행 흐름처리가 어떤지에 따른 관점

한 작업이 다른 작업을 시작시킬 때, 다른 작업의 완료를 기다리거나, 기다리지 않더라도 다른 작업의 완료 여부를 지속적으로 확인하는지 여부가 관심사. 한 작업이 다른 작업을 시작하고나서 자신의 작업을 지속하여 수행하는지 여부는 관계없다.

동기(Synchronous)

작업 A 가 작업 B를 호출 한 후 그 작업의 완료후 리턴을 기다리거나, 바로 리턴을 받더라도 B가 미완료 상태인 경우 B의 작업 완료 여부를 A가 스스로 계속 확인 하는 경우 A와 B 는 동기이다. = A와 B는 동기적으로 수행된다.

특징

작업의 완료 순서가 항상 일정하다(멱등). = 작업이 일정한 순서를 가지고 진행된다.

특정 시점에 동작중인 작업이 끝나는 동시에 다른 작업이 수행된다.

비동기(Asynchronous)

[네트워크] 동기&비동기, 블로킹&논블로킹

2022/12/01

정의

API(Application Programming Interface) 는 프로그램과 프로그램 사이의 통신을 위한 인터페이스이다.

함수, 메서드 등의 이름으로 불리는 소프트웨어 구성 요소의 정의 를 말한다. 구현과는 상관 없이, 어떻게 사용하는지( = 사양) 정의만 되어있으면 된다. 실제로 구현되어 있으면 라이브러리라고 한다.

웹 API

웹 환경에서 사용되는 API 를 말한다. 즉, 하나의 웹서비스가 다른 웹서비스에 요청을 보내고 응답을 받기 위한 명세를 말한다.

웹 상에서 어떤 요청을 보내면 어떤 응답을 받을지 정해놓은 것을 말한다.

RESTFull API = REST API

REST(Representational State Transfer) : 규칙들의 집합.

HTTP 를 이용한 프로토콜로 REST 조건들을 모두 만족하는 API 를 의미한다.

REST 조건

•

클라이언트, 서버 및 리소스로 구성되었으며 요청이 HTTP를 통해 관리되는 클라이언트-서버 아키텍처

•

스테이트리스(stateless) 클라이언트-서버 커뮤니케이션: 요청 간에 클라이언트 정보가 저장되지 않으며, 각 요청이 분리되어 있고 서로 연결되어 있지 않음

•

클라이언트-서버 상호 작용을 간소화하는 캐시 가능 데이터

•

자체 표현 구조 : REST API 메시지만으로 어떤 작업을 하는 API 인지 쉽게 알 수 있는 구조

[네트워크] API

2022/11/23

JWT

JSON Web Token 의 약자. RFC 7519 표준으로 정의되어 있는 전자 서명된 URL-safe 한 JSON 이다.

⇒ 웹 환경에서 사용자 인증을 위한 토큰

⇒ HTTP 는 무상태, 각각의 요청-응답 쌍이 독립적이므로, 사용자의 인증을 위해서는 별도의 정보 유지 수단이 필요하다.

⇒ 그 “정보 유지 수단” 의 한 종류로서 Token 이 있고 그 중 한 종류가 JWT 이다.

구조

Header

JWT를 어떻게 검증하는지에 대한 정보가 포함되어있다. 암호화 알고리즘과 토큰의 타입이 포함되어있다.

Payload

•

토큰에 담고자 하는 정보를 넣는 부분이다.

•

JSON 의 각 key-value 를 claim(클레임) 이라 부른다.

•

claim 에는 3가지 종류가 있다.

[네트워크] JWT

2022/11/23

오늘 인턴 면접에서 질문으로 Callable 과 Thread 사이의 차이점을 말해보라고 질문을 받았다. Callable 은 사실 생전 처음 들어보는거라 당연히 전혀 대답을 하지 못했다. 떨어지면 이거때문이겠지.. 여튼 새로운 공부거리를 던져주었으니, 공부해야겠다는 생각에 이렇게 면접 끝나자마자 찾아보고 있다.

Java 1.0 : Thread 와 Runnable

Thread 클래스 사용법

자바에서 새 쓰레드를 생성하려면 Thread 클래스를 사용한다. 이 클래스로 새 쓰레드를 생성하는 방법에는 크게 2가지가 있다.

Runnable 을 사용하는 방법

Thread 의 하위 클래스를 생성하는 방법

이 두가지 방법중 첫번째 방법이 더 선호된다. 더 확장성이 좋기 때문이다.

Runnable 을 사용하는 방법이 확장성이 더 좋은 이유

Thread 클래스 내부 동작 원리

Thread 클래스의 인스턴스를 생성하고, start() 메서드를 실행시키면 내부적으로 다음 순서대로 메서드가 실행되고 실제 쓰레드가 생성된다.

start() 메서드 실행

start0() 네이티브 메서드 실행 > 이 시점에 실제 쓰레드가 생성된다. 내부에서 run() 메서드를 실행시킨다.