유저의 행동 데이터를 추적하고 싶은데, RDS로 적재 및 분석하기에 커다란 사이즈인 경우가 있었다. 이 경우였는데, 정말 많은 데이터를 쌓고 싶었고 분석도 빠르게 하고 싶었다. 그러기 위해서는 RDS가 아닌 다른 형태로 데이터를 저장해야 한다. 일반적으로 CSV형태로

어느 날 갑자기 운영 중인 서버가 멈췄다. 다운 타임은 약 40분 정도 였고, 해당 건으로 많은 CS가 들어왔다. 심각한건 알아차리지 못했다. 변명을 해보자면 일단 휴가 중으로 한국이 아닌 일본에서 여행 중이긴 했다. 조치는 다른 개발자분이 인스턴스를 늘려주었고, 메모

회사에 새로운 서버 기술을 도입해보려고 한다. 사실 이전에도 이것저것 도입해보려 했지만 다른 업무에 치이는 일이 있었고 스스로도 동기부여에 실패하여 도입에 실패한 기술들이 좀 있다(webflux, webflux, webflux)하지만 이번엔 다르다. 2023년 1월이니

IP VPC 세팅을 하다보면 IP를 할당 받고 Subnet을 나눠준다. 그리고 각 Subnet에 CIDR 블록을 설정해준다. 뭔가 IP 재활용을 위해 하나의 IP로 여러 곳에 사용한다는 개념은 알겠는데, 정확히 어떻게 작동하는지는 모르고 사용해 왔다. 이를 이해하려면

이전 글에서 인덱스의 자료구조에 대해 알아보았다. 이번엔 인덱스의 타입에 대해 알아보자. 인덱스는 두 가지의 타입이 있는데, 하나는 Clustered Index, 하나는 Non Clustered Index이다.타입에 따라 인덱스를 설정하기에 좋은 조건과 나쁜 조건이 있

인덱스는 데이터베이스에서 검색 속도를 향상시켜준다. key, value 형태로 정렬되어 책의 목차처럼 빠르게 어떤 정보에 접근할 수 있도록 도와준다.정렬되어 있기 때문에 데이터를 찾을 때 테이블 전체를 풀 스캔 할 필요 없이 정렬된 인덱스에서 원하는 데이터를 찾을 수

사용자들로부터 누적된 데이터들을 분류하고 분류된 데이터를 기준으로 새로운 데이터에 대입하여 분류하는 방법사용자들의 과거 데이터가 미래에도 유지될 것을 전제로 함사람들이 과거에 좋아했던 상품과 비슷한 상품을 좋아한다는 사실을 전제고객의 선호도를 기준으로 기존 상품들과 예

클로저는 mdn 사이트에 따르면 함수와 함수가 선언된 어휘적 환경의 조합이라고 한다. 정의만 봐서는 정말 무슨말인지 이해하기가 어렵다. 실제로 클로저 관련 글을 쓰기 위해 공부하면서도 감은 오는거 같은데, 이게 뭐지? 싶은 느낌이 많이 온다.mdn 사이트를 기본으로 다

서론 자바에서 컬렉션 프레임워크에 대해 설명해달라는 질문을 받았다. 실무를 보며 수없이 사용하는 컬렉션 프레임워크지만 List, Set, Map이 있고 Set은 중복을 허용하지 않는다. List에서 데이터를 찾을 때는 배열의 모든 값을 순회해야 해서 배열의 길이 만큼

서론 데이터베이스에서 원하는 정보를 빠르고 효율적으로 찾기 위해 인덱스를 사용한다. 일반적으로 기본 키를 통해 원하는 데이터를 인덱싱하기도 하고 Unique 인덱스, 혹은 일반적인 인덱스를 사용하기도 한다. 그리고 생성한 인덱스를 기준으로 데이터베이스에 쿼리를 날려

물품을 구매하는 API가 있었다. 물품을 선택하고 구매버튼을 누르면 현재 보유하고 있는 돈이 물품 가격을 넘으면 물품 가격만큼 제하고 물품을 유저에게 준다.여기서 문제가 발생했는데, 구매버튼을 빠르게 두 번 누르면 현재 보유하고 있는 돈이 0원이어도 구매가 되고 보유

해쉬맵에 있는 값을 검색하는 속도는 무조건 배열에서 원소를 찾는 속도보다 빠르다. 근데 왜 빠를까? 그저 어디선가 본 책에 그렇게 적혀있어서 당연하게 생각해왔지만, 위 질문을 받았을 때 깔끔하게 대답할 수 없었다.머릿속으로 먼저 든 생각은 해쉬맵은 key 값이 있어서

서론 개인적으로 변수, 메소드의 네이밍에 굉장히 신경을 쓰는 편이다. 네이밍 하나가 그 변수와 메소드의 모든 것을 나타내줄 수 없다는 것은 알지만, 3일 후 이 코드를 다시 보는 나에게 지금 네이밍 하는데 들어가는 시간과 노력이 정말 소중하게 느껴질 수 도 있기 때문이

Transactional 어노테이션으로 트랜잭션 단위를 묶은 메소드가 있었다. 해당 메소드 내부에는 여러 쿼리문이 있었고, 여러 쿼리문 이전에 어떤 조건이 맞지 않으면 Exception을 띄워서 트랜잭션이 커밋되지 않고 롤백 되기를 의도하여 메소드를 작성했다.예시대략

서론 기존 MyBatis로 작성된 쿼리를 JPA로 옮기던 작업중이었다. MyBatis는 조금 자유롭게 SQL을 사용할 수 있기에 아키텍처를 잘 설계하거나 쿼리 작성에 무게를 두지 않으면 이런저런 쿼리들이 많이 작성되게 되는데 살펴보면 애초에 복잡한 쿼리를 작성할 필

Table: Employee\+-------------+------+| Column Name | Type |\+-------------+------+| id | int || salary | int |\+-------------+------+

한 번에 많은 데이터를 데이터베이스에 저장하려고 할 때 일반적으로 데이터 하나당 insert를 날리는 것보다 값들을 묶어서 batch insert하는 경우가 더 성능이 좋다.여러 데이터를 batch insert하기 위해 List 형태로 데이터를 모아서 saveAll(d

스프링에서 캐싱을 사용할 때 특정한 경우에서 캐싱이 작동하지 않는 경우가 있었다. 문제 발생의 이유에 대해 이해하지 못하거나 날아가는 쿼리를 제대로 확인하지 않고 사용시 성능상 큰 문제가 되거나 db가 뻗어버릴 수 있다. 실제 운영db를 눕혀봤다캐싱이 제대로 되지 않

Profile을 설정하는 이유 로컬, 개발 서버, 배포서버의 각 설정이 모두 다르기 때문에 매 번 설정값을 바꿔주는 작업을 자동화 해줄 수 있다. 개발할 때는 IDE에서 그냥 실행하면 되고 개발하다가 바로 개발 서버 혹은 배포 서버로 옮기는 작업을 간단히 하기 위해

대학을 졸업하고 바로 취직에 성공했다. 처음에는 프론트엔드 개발을 주로 공부했지만 막바지에 백엔드에 대한 생각이 깊어져서 결국에는 백엔드 개발자 진로를 정했다. 지금은 모바일 어플리케이션을 개발하는 작은 회사의 백엔드 개발자로 취직했다. 최초에는 IT 대기업, 유니콘