꼼개의 개발자취

개요저번 글에서 스카우터를 활용하여 API의 성능을 측정할 수 있는 Summary 기능을 소개했었다.https://code-killer.tistory.com/190해당 기능을 이용하여 slow 쿼리를 발견하였는데, 아래와 같았다.select * from temp t where t.col is null단순한 구문이라, 인덱스을 활용하여 쿼리 성능을 높이려고 했다.근데, 문득 null 값을 허용하는 컬럼도 인덱스 성능의 효과가 있을까? 라는 의문이 들어, 관련 내용을 찾아보고, 실험도 직접 해봤다.먼저 DB 환경에 따라 달라진다.오라클오라클은 인덱스에 null 값을 저장하지 않는다고 한다.즉 아래와 같은 null을 이용한 쿼리에 인덱스를 타지 않고, Full Scan을 진행한다.select * from te..

개요 프로젝트를 진행하면서, 직렬화 된 객체를 매개변수로 받는 메서드를 만들었다. public void putData(String key, Serializable data) { data.put(key, data); } 해당 메서드를 사용하는데, List 타입으로 직렬화 변수를 넣으면 컴파일 에러가 발생하였고, ArrayList 타입을 넣었을 때는 정상적으로 동작한다. // 정상동작 ArrayList newData = new ArrayList(); newData.putData(key, newData); // Type 컴파일 에러 발생 List newData = new ArrayList(); newData.putData(key, newData); 선언은 다르지만 어쨋든 new ArrayList()을 할당 했..

개요 로그 수집 용도로 ELK를 사용하고 있었는데, 원래 보안 용도로 클라이언트에서 서버를 거쳐 로그를 수집하고 있었다. 로그 양이 많아지니, 서버의 부하가 몰려 성능 이슈가 발생할 수도 있었다. 방지를 위해, 클라에서 ELK로 바로 쏘도록 구조를 변경할 필요성을 느꼈고, VIP와 L4을 추가하도록 하였다. 원래 Elasticsearch는 자체 로드밸런싱 기능이 있어서, 1개의 머신으로 보내도 로드밸런싱을 하지만, 트래픽 양이 많을 때도, 제대로 작동할 지 몰라, 앞단에 로드밸런스를 놓기로 하였다. 문제 사내에서 ELK 구조는 머신 6대를 클러스터로 구성하여 사용하고 있다. 또한, 사용하는 L4 방식이 proxy 방식이다. 아래는 elasticsearch.yml의 일부 내용이다. bootstrap.mem..