개발일지

검색 엔진에 최적화 되어있는 엘라스틱서치를 적용하면서 조금 난항을 겪고 있다

엘라스틱서치 자체 기술스택(ELK)을 사용하는데는 문제가 없는데, 스프링부트에 적용하려니 기존에 implement 했던 스택들과 버전 컨트롤이 힘든 문제도 있고, 최근 들어서 특정 객체가 Deprecated 되면서 spring.io 공식문서나 엘라스틱서치 가이드 정보가 아직 갱신되지 않은 탓에 블로그나 스택오버플로에서도 사용할만한 코드를 못 찾아서 어떻게 할지 고민중이다

사실 Mysql 튜닝이나 인덱싱 작업을 다해놔서 필요성을 느끼지 못하고 있기도 하고, 써야할 곳을 만들려면 따로 DB를 마이그레이션 하거나 해서 프로젝트에 엘라스틱서치 사용처를 만들어야 하는데, 해도 괄목할만한 성능향상은 보일 것 같지 않아서 의욕이 생기지 않는 게 사실이다

그래서 엘라스틱서치 보다는 SSE나 웹소켓으로 커넥션 유지하면서 슬로우 쿼리와 같은 특정 기능 이상이나 메소드 발생 시 이메일이나 SNS로 보내주는 기능을 구현하는 것에 대해 검색해 보고 있음

일단 재미있어 보이는 거 먼저하고 현재로서는 필요성을 덜 느끼는 엘라스틱서치나 조인 방식을 실제로 어떻게 활용하는지 (nested, sortMerge, hashjoin...) 하는 것들의 실제 코드를 찾아보고 적용해볼 생각이다

오늘 배운 것 :

QueryDSL 사용해서 기존 dataJpa 코드 수정

JAXB 사용해보는 중

redis, elastic search를 jpa에 연동할 방법 고민중

느낀 점:

새로운 걸 배워서 적용해보려는데 블로그 별로 사용하는 버전이나 용법이 달라서 직접 공식문서를 보거나

implement 시켜놓고 객체 내부로 들어가서 확인하는 게 더 빠른 듯

아쉬웠던 점:

진행하는 프로젝트 자체가 검색 성능을 향상 시키는 프로젝트라 FullText Scan을 이미 적용했더니 다른 인메모리 DB를 적용할 곳이 마땅치 않다

그래서 굳이 회원 기능을 구현해서 레디스를 써볼 생각임

DB에서 많은 양의 데이터를 핸들링할 때 어떤식으로 테이블을 인덱싱하고 서버 로직을 설계해야 실제로 사용할 수 있는 앱을 만들 수 있을지 고민하고 알아보기 위해서 도서 정보를 1500만건 넘게 로컬 환경의 MySQL에 때려박는 작업을 진행했다

idb 파일이 있었으면 금방 끝났겠지만 그런게 없었기 때문에 필요없는 데이터는 정제도 할겸 API로 받아오거나 csv, excel 파일로 넣을까 고민했는데, API의 경우는 1000만건을 넘는데 각각의 트래픽 제한으로 시간이 너무 오래걸리거나 하는 경우가 많아 제외하고 문서 파일을 받아 직접 넣는 방식으로 진행했다

그냥 노가다라서 딱히 힘든 점은 없었는데 excel column을 읽어들이는 과정에서 null 값 처리는 되는데 이놈이 null값 처리를 잘 했으면 반복문에서 다음으로 넘어간 뒤 나머지를 DB 컬럼에 잘 박아넣어야 하는데 null값 처리했다고 무슨 ACID 원칙이 깨진것마냥 전부 롤백을 때려버려서 null값이 하나라도 있으면 업로드 작업은 성공했다는데 막상 DB에는 안박히는 문제 때문에 조금 골치를 썩힌 것 빼고는 없었다

데이터를 대략 1630만건 정도 넣어놓고 FullText Scan 방식을 사용하기 위해 인덱싱 하는데 1630만건이나 인덱싱하려니 시간이 기존에 설정해둔 커넥션 리미트 타임을 60초를 가뿐히 넘겨버려서 (500초 넘게 걸렸다) 이상한 더미 인덱싱 파일이 생겨서 안지워져 애먹었다

어차피 디비로퍼 기준으로 설치 되있어서 버퍼 사이즈 설정이 애매했던 지라 오히려 잘됬어 ㅋ 하고 서버용 프로필로 재설정 할겸 재설치 한 뒤 Fulltext 인덱싱 작업들을 완료했다

(기존의 데이터는 idb 파일로 백업해 바로 업로드했다)

전문검색 스캔을 하니 페이저 검색 속도가 어마어마하게 빨라져서 0.005초 미만이 되어버렸기 때문에 사실상 체감할 수 있는 영역을 넘어서 버렸다

검색 옵션을 세분화할 겸 프론트 부분을 설계중인데 SEQ 문법 오류가 터지는데 명령어 부분을 예약어나 ""에 넣어서 줘서 문제인 것 같은데 해결 중이다

오늘 배운 것 :

MySQL FullText Index (전문검색) 적용 및 1630만개의 데이터 검색 최적화 (1초 미만으로 검색 되도록 하기)

DB type과 type별 특성 및 FullText Index의 검색 모드에 따른 장점과 단점, 세팅법

데이터 마이그레이션

Count 집계 방식의 성능 개선에 대한 방법들에 대해 생각

AOP 활용 복습 (스톱워치, 테스트 데이터 끼워넣기 등)

스프링 JPA 어노테이션과 Entity 관계성에 의한 SEQ n+1 문제들 유형별로 확인 중

스프링 기반의 CRUD 최적화에 대한 방법들 및 개념 위주로 공부 중

느낀 점:

뭘 하려고 하든 방법은 항상 산재해 있는데 효율은 제각각이라 직접 해보는 수밖에 없다

하나의 기술 스택을 1부터 100까지 공부를 하고 테스트를 했을 때 비슷한 방향성을 지닌 다른 기술 스택보다 효율이 떨어진다면 결국 쓰이지 않게 될 수도 있다

깔끔하고 통일성 있는 코드를 원한다면 하나의 기술스택으로 나가도 좋지만 성능을 생각한다면 결국 각각의 상황에 맞는 다양한 기술을 채용해야한다

특정한 부분에서는 네이티브 쿼리를 날리고 있는데 왜 여기서는 네이티브 쿼리를 날리고 있고, 사용하던 라이브러리의 어떠한 제약이나 문제점 때문에 네이티브 쿼리를 날리고 있는 지 생각해봐야한다

하나의 기술 스택도 완벽하게 알기란 어렵다. 만든 사람의 공식문서를 통해 장단점을 파악하는 게 가장 합리적임.

아쉬웠던 점:

퍼포먼스 위주로 공부를 하다보니 기능의 바리에이션이 한도 끝도 없이 좁아터짐

화려하고 거창한 거 좋아하는 소비자나 투자자 입장에서는 매력 없는 프로젝트일 듯

(근데 사업 좀 커졌다고 데이터 로딩에 5초 이상 걸리면 본인들도 도주함)

오늘 배운 것 :

남궁성 아저씨 Stream 사용 부분 복습함

POI가 Date 서식을 못읽어오길래 그냥 String으로 받을까 생각 중

(하지만 타협할 수 업서요)

JPA 관계성 형성 중 MappedBy를 통한 관계성 주인 설정과 디폴트값에 의한 ID 테이블 생성 어느 쪽이 어느 상황에 효용성이 생길까 고민해봄

Builder에 의한 영속성 부여 1차캐시 저장에 대해 체인 메소드의 재미와 짧고 깔끔한 코딩에 대해 고민함

MySQL을 예전에 Developer Default 설정으로 설치했었는데 동적 메모리가 1000만건 이상의 데이터 컬럼을 허용해줄지 궁금해서 만지작 거려봄

느낀 점:

책 읽을 시간 줘

Stream 복습하긴 했는데 경제적인 측면에서 봤을 때 리소스는 서버 리소스가 더 싸게 먹히지만

어차피 퍼포먼스 적인 측면은 대부분 한방 SEQ 날리는 게 더 낫기 때문에 복습하면서도 코쓱 함 

아쉬웠던 점:

책 천천히 여유롭게 정독하고 싶음

지난 주는 공식문서의 Start Guide를 참고해 웹소켓 채팅을 구현하는데 중점을 뒀다

https://spring.io/guides/gs/messaging-stomp-websocket/

여기를 참고해 받아오는 메세지에 JWT 액세스 토큰을 멤버변수로 첨가해

접속한 유저가 로그인한 유저인지 판별해 토큰을 JWTS로 디코딩해서 payload에서 해당 유저의 닉네임을 뽑아내

메세지를 Response 하는 시간에 맞춰 LocalDateTime을 줌으로써

실시간 채팅을 구현하는 작업을 했는데 나름 재밌었다

다음에 하게되면 WebRTC를 구현해 볼 생각인데 언제가 될지 모르겠지만 재밌는 작업이 될 것 같다

조금 아쉬운 점이라면 HttpServlet를 extends해서 Request에 AccessToken을 cookie로 실어보내는 방식으로 진행할 수도 있었을텐데, 아직 프론트와의 협업이 익숙하지 않다거나 배우지 않았다는 문제로 익숙한 방식을 사용해 채팅 메세지가 날아 갈 때마다 매번 토큰을 함께 실어나르는 부분이 영 탐탁치 않았다

애초에 채팅룸 입장(POST) 시 한번 쿠키에 구워서 보내고 프론트에서 쿠키에서 꺼내거나 로컬스토리지에 저장해 지속적으로 실시간 채팅룸에 뿌리는 방식이 효율적으로 보였지만, 무리한 부탁이 될 수 있는 일을 하기는 어려웠다

차라리 서버에서 매 요청시마다 토큰을 분해해 메세지 작성 시간과 함께 메세지 및 유저 정보를 보내주는 게 협업하는 분들에게 프로젝트를 유지할 수 있는 난이도로 스트레스를 받지않고 넘어갈 수 있다는 생각이 들었다

그러다보니 물론 구현력도 중요하긴 하나 Perfomance적인 측면에서 스프링을 사용할 때 어떻게 더 빠르게, 더 정확하고 안전하게 코딩을 할 수 있을까 하는 생각이 미치고 있다

언제까지고 꼴랑 데이터 수십 수백개짜리 작업만을 해서는 현업에서 유저들을 대상으로 사용되는 서비스의 작업을 맡을 수는 없다고 생각했기 때문이다. 당연한 얘기지만 역지사지로 생각해서 내가 시니어 개발자라고 가정해도 이런 신입한테는 일을 맡기지 않겠다

회사가 유지되려면 상품에 상업성이 있어야하고 상업성은 필연적으로 빅데이터를 생산해내니, 스타트업만 전전하거나 프리랜서로 용역만 하다 살다 죽을 게 아니라면, 빅데이터를 핸들링하는 기술이 기술자로써의 효용적 가치를 생산해낸다는 생각이 들었다

그래서- 엘라스틱 서치 보고 있다

레디스 사용법도 대충 알았고, 토큰 등 휘발성 데이터를 다루는 데에는 인메모리 방식의 레디스를 부분적으로 도입하는 게 더 퍼포먼스 측면에서 나은 방향이라는 것도 깨달았다

성능에 중점을 두고 생각을 이어가다 보니 필수 불가결한 AOP로 StopWatch 등의 어노테이션을 커스텀해서 사용하는 방식들도 자연스럽게 습득하고 있다

콘솔 등에서 어질어질할 정도로 날려대는 select, delete, insert 등의 1+n 문제도 어떻게하면 batch insert 등의 batchSize 설정을 통해 한방 쿼리로 만들어 로딩시간을 줄일까 실험해보고 있고, HikariCP로 쓰레드풀 설정도 깔짝여보고, mySQL 등의 RDBMS에서 JDBC 규격에 따라 이루어지는 체번 방식을 변경함으로써 얻어지는 퍼포먼스적인 측면을 테스트해 보고 있다

(체번을 위해 쿼리를 두번 날리게 되므로 ID를 pooled-lo optimizer generator 방식으로 미리 만들거나 그런 짓을 해보고 있음)

결과적으로  Jpql이나 QueryDSL 방향 쪽으로 나아가고 있긴한데 아마 JDBC까지 원시적으로 SEQ 날리는 방향까지 원점회귀 하듯 파고들어갈 것 같다

(여윽시 튜닝의 끝은 바닐라지)

암튼 귀여운 똘똘이 보고가셈

어헝 기여어

오늘 배운 것 :

POI 사용

액셀 파일 읽어와서 view에 뿌리기

액셀 파일 읽어와서 DB에 넣기

HikariCP 사용해서 DB transaction 쓰레드 풀 설정하기

jdbc.batch_size + rewriteBatchedStatements = true 사용 통해 한방 쿼리 만들기 위한 성능 개선

mySQL SequenceGenerator 채번 방식과 JDBC 제한 문제로

pooled optimizer 이용해서 Data Jpa saveAll 메소드 성능 개선

느낀 점:

더... 더 빠르게 해...줘

아쉬웠던 점:

좀 더 좀 더 빠르게 조금만 더 아니 많이 더 훨씬 빠르게

웹 개발에서 백엔드로써 Spring Boot를 써서 기본적인 CRUD API를 설계하고 작성하며 리액트를 하시는 프론트분들과 함께 미니 프로젝트를 진행했다

초기에 대강 예상을 한 것처럼 Http 통신 방법이나 보안적인 측면에서 지식의 부재가 발목을 잡긴 했는데 구글링을 하고 부딪쳐 보면서 시간만 갈아넣으면 어느정도 해결이 가능한 문제들이었고, 오히려 사람간의 작업 속도의 차이라고 해야할까, 실력의 편차라고 해야하나 작업 능률을 떨어뜨리는 부분은 그런 쪽에서 많이 발생하는 것 같다

라는 말은 솔직히 따지자면 프로젝트 진행 상태를 미시적으로 판단했을 뿐이고, 장기적인 관점에서 생각해보면 결국 실력의 편차는 거의 없다고 생각하고, 누구나 같은 프레임워크 위에서 노는만큼 시간이 지나면 상향 평준화 될 것이기에 무엇을 만들어내고 어떻게 만들어 낼지 고민하는 자세와 노오-력의 차이가 중요하다고 생각한다

개발을 하는데 있어 서로에게 재미와 흥미를 느끼게 해줄 수 있고 적극적으로 나아갈 수 있도록 동기를 부여해줄 수 있는 동료가 가장 훌륭하고 좋은 파트너라고 생각한다. 실력은 부차적인 문제로 협업으로 해결할 수 있는 문제는 시간을 투자하면 혼자서도 얼마든지 해낼 수 있다

그런 면에서 미래를 보며 투자했을 때 가장 도움이 되지 않는 동료는 자신의 감정을 다스릴 줄 모르고, 소통 능력이 부족한 파트너가 아닐까 하는 생각도 든다

어떤 것을 진행하고자 하는데 재미가 있으면 열정이 생기고 열정은 강한 전염성을 지니고 구성원들과 프로젝트를 올바른 방향으로 이끌 수 있다고 믿는다

다른 개발자의 흥미를 돋굴 수 있는 즐거운 개발자가 되자