코딩은 내일부터

Kotlin을 배우기 위해 다음 미션을 포크하고 자동차 게임을 구현해 보았습니다. https://github.com/ingpyo/kotlin-racingcar GitHub - ingpyo/kotlin-racingcar Contribute to ingpyo/kotlin-racingcar development by creating an account on GitHub. github.com Kotlin이 뭐예요? Kotlin은 JetBrains에서 개발한 언어이다. 당시 java가 불편한 점이 많고 업데이트 주기가 너무 느려서 JetBrains팀에서 자체적으로 개발을 하였다. 또한 Kotlin이 이렇게 관심을 받고 있는 이유 중에 하나는 멀티 플랫폼 언어라는 것이다. 위에 사진과 같이 코틀린의 코드를 짜 놓으..

개발을 하면서 Redis라는 키워드를 많이 들었다. In-memory~, 단일 스레드 등등 빠르고 캐싱할 때 많이 사용하는 저장소로만 알고 있어서 더 자세히 Redis의 대해서 알아보겠다. Redis가 뭔가요? Redis는 Key-value형식의 저장이다. 쉽게 말해 거대한 맵(Map)데이터 저장소라고 생각하면 좋다. 또한 NoSQL의 종류로 고정되지 않은 테이블 스키마를 가질 수 있고, RDBMS에 비해 훨씬 더 대용량의 데이터를 저장할 수 있다. 왜 Redis가 빠른가요? Redis는 In-Memory데이터 저장소기 때문에 디스크 기반 DB에 비해 매우 빠른 성능을 제공한다. 위에 사진에서 나와있듯이 HDD는 1~10ms, RAM은 120ns로 RAM이 압도적으로 빠르다는 걸 알 수 있다. In-Me..

프로젝트를 진행하면서 외부 API를 다루는 경우가 많았다. 2023.09.14 - [우아한 테크 코스(우테코)/우테코 공부] - 파사드 패턴으로 외부 API와 DB 트랜잭션 범위 분리하기 파사드 패턴으로 외부 API와 DB 트랜잭션 범위 분리하기 DB 커넥션은 개수가 제한적이므로 단위 프로그램이 커넥션을 소유하는 시간이 길어질수록 사용 가능한 커넥션의 개수는 줄어든다. 따라서 하나의 작업이(트랜잭션이 필요 없는 로직이 붙어있는 jeoninpyo726.tistory.com 위와 같이 외부 API와 비즈니스 로직을 분리하였는데 외부 API가 장애가 났을 때 전체 로직이 피해받는 부분은 똑같았다. 그래서 Resilience4j라는 장애에 강한 시스템을 만드는데 도와주는 라이브러리를 공부해보았다. Resilie..

HikariCP란 데이터베이스 커넥션 풀 프레임워크는 대표적으로 Apache Commons DBCP, Tomcat DBCP, HikariCP 등이 있다. HikariCP는 스프링부트에 기본으로 내장되어 있는 JDBC 데이터베이스 커넥션 풀링 프레임워크이다. 스프링부트는 HikariCP를 사용할 수 있는 상황에서는 항상 HikariCP를 선택한다. 이러한 HikariCP는 커넥션을 하기 전에 미리 커넥션 풀(pool)에 커낵션을 저장해두고 필요할 때마다 재사용하는데 커낵션을 맺는 과정이 비용이 크다. 그래서 이러한 커넥션 풀의 size를 적절하게 설정하는게 불필요한 리소스를 줄이고 성능향상을 기대할 수 있다. 테스트 시나리오 시나리오는 다음과 같다. 카테고리 조회 마크다운 글 올리기 카테고리에서 글 목록 ..

문제의 상황 동글 서비스는 글, 카테고리를 저장할 때 동시성을 AOP를 사용해서 제어해주고있었다. AOP를 구현할 당시에는 동글 서비스가 서버 2대 이상 띄우는 시기가 먼 미랜줄 알고 서버가 2대 이상인 환경을 별로 신경 안 쓰고 있었다. 하지만.... 이번 6차 데모데이의 요구사항 중에 무중단 배포가 있어 무중단 배포를 학습하고 구현하는 도중 다음과 같이 서버가 동시에 2대 실행되고 있는 순간이 있다는 거를 확인하였다. AOP로 동시성을 제어하는 로직이 사용할 수 없어 다른 제어방법을 생각해야 했다. 구글에 분산락을 검색해 보면 Redis를 사용하는 방법 등등 여러 방법이 나오는데 이러한 기술을 사용하면 인프라 구축하는 비용 + 기술 학습 비용 이 들어가기 때문에 프로젝트 초기부터 사용해오고 있는 My..

전쟁을 시작하기 전 처음 동글 프로젝트의 테스트코드의 개수는 104개, 커버리지는 50%였다. 기능구현 하는데 집중해서 테스트코드가 빈약한 상태이다.(사실 핑계 아닌 핑계..) 그래서 이번 추석연휴가 길어 테스트코드 커버리지를 올릴 생각이다. 위에 이응준님 처럼 커버리지 100%는 아니지만 80%까지를 목표를 시작했다. 그리고 동글의 자신감을 되찾아줄 예정이다! 어떻게 테스트를 작성할 것인가? 레이어를 독립적으로 테스트하기 위해 슬라이스 테스트 방식으로 진행했다. 쉽게 말해 controller, service, repository 계층 각각을 단위테스트 한다고 생각하면 된다. Repository Layer Test 먼저 Reositroy 테스트는 @DataJpaTest를 사용해서 Repositroy 테스..

이번 포스팅에서 커버링 인덱스와 N+1문제를 Fetch Join을 사용해서 개선한 과정을 작성해 보겠다!! 1. 글의 내용 가져오는 쿼리 성능 개선 프로젝트를 진행하면서 성능 최적화를 위해 “지연 로딩”(Lazy Loading)전략을 사용해서 DB의 데이터를 가져왔다. 위에 writing 도메인을 보면 writing이라는 엔티티 안에 필드로 Blocks를 가지고 있다. 왜냐하면 위 사진과 같이 글 내부에 형태(h1, h2,… 리스트 등등)가 여러 개로 구성될 수 있기 때문이다. (파란색 블록이 1개의 블록을 나타낸다.) 즉, 하나의 글 안에 여러 개의 블록을 가지고 있는 1:N관계로 DB에 저장하고 있고, 블록마다 저장되는 형태도 다름으로 다음과 같이 여러 형태가 있고 Block으로 추상화를 적용하였다...

배경 상황 동글 프로젝트는 드래그 앤 드롭으로 글과 카테고리의 순서를 바꿀 수 있다. 그래서 글 과 카테고리의 순서구현을 LinkedList로 구현해서 각각의 테이블에는 next를 바라보고 있다. (각각의 글의 순서를 1,2,3 이런 식으로 저장하고 있으면 하나의 글의 순서가 변경될 때 나머지 글의 순서를 모두 변경해야 하는 문제가 있어 LinkedList로 구현하였다.) 이러한 상황에서 ngrinder로 부하테스트를 하던 중 위와 같이 순서가 마지막(next가 null)인 글이 여러 개 생성되는 것이다.. 그래서 글의 가져올 때 마지막글이 여러 개가 select 돼서 오류가 발생해서 사용자가 이러한 문제를 겪었을 때 DB에 직접 지워주지 않는 이상 그 사용자는 글을 못 가져오는 버그가 발생한다. 문제의..