프로젝트/여행지 오픈 API (32) 썸네일형 리스트형 [Elasticsearch] 시스템 구조 및 flow 정리 시스템 구조 이번 프로젝트의 구조도를 한눈에 정리하자면 다름과 같다. Main 서버에는 FE 서버와 본체 비즈니스 서버, Elasticsearch와 연동되는 API 서버가 존재하고, 핵심 로직을 담당한다. Sub 서버에는 ELK 및 배치 프로그램, MySQL의 저장소 위주로 구성하였다. 이는 Elasticsearch와 배치 프로그램이 상대적으로 RAM 용량을 많이 차지하기 때문에, 부하를 줄일 목적으로 Sub 서버를 구성하였다. 데이터 아키텍쳐 - 스크래핑 데이터 정제 구조도이다. 우리는 배치 프로그램을 통해 스크래핑이 허가된 사이트에서(robot.txt 및 정책 확인) 부하를 주지 않는 선에서 데이터를 수집하였다. 이 과정에서 수집된 html 데이터는 텍스트화하여 1차적으로 MongoDB 클라우드에 저.. [Elasticsearch] 회고 및 리뷰 성과 Spring 서버 연동 및 API 생성 및 인프라 구축 - spring data elasticsearch와 native search query를 사용한 API 서버 구축. - elasticsearch, kibana, logstash를 사용할 수 있는 서버 환경 구축. ES 버전은 7.11.2를 사용하였다. 유사도 비즈니스 로직 구현 1. 입력 검색어에 대한 오탈자 보정 후 유사 검색 결과 반환 및 비즈니스 로직 제공 API 요청 당시 가장 큰 요구사항은 '오탈자'에 대한 올바른 검색 결과를 제공하는 것이었다. 따라서 숙소, 관광지, 음식점의 데이터셋을 분석기와 커스텀 필터를 통해 인덱스에 저장하였다. 이후 ngram과 fuzzy 방식을 융합하여 사용자의 요청에 따라 가장 유사한 검색 결과를 반환할 .. [Logstash] 로그스태시로 로그 뽑아서 저장하기 경로 맞추기 내 스프링부트 컨테이너 내부 경로와 외부 마운팅할 파일 경로를 맞춰줘야 한다. sudo docker exec -it elastic-container /bin/bash 를 통해 접속한 결과 이런 식으로 기본 루트 디렉토리가 /app임을 확인할 수 있다. 이는 당연한데, 도커파일이 다음과 같이 정의되었기 때문이다. 따라서 나는 경로를 /app/log/logfiles.log로 저장하고자 한다. # 기본 이미지로 Java 11을 사용합니다.. FROM openjdk:11-jre-slim # 작업 디렉토리를 설정합니다. WORKDIR /app # 이 폴더를 외부 볼륨 마운팅 하는 폴더로 설정합니다. VOLUME ["/app/logs"] # 호스트 머신에서 JAR 파일을 복사합니다. COPY build.. [LogBack]API 요청 로그 수집하기 개요 API 요청에 따라 springboot에서 로그를 수집하고, 발생하는 로그를 ES의 인덱스에 추가하려고 한다. 전체적인 로직은 다음 포스팅들을 참고하였다. https://prohannah.tistory.com/182 Spring Logging (1) : HTTP Request/Response 로그 남기기 서비스를 운영하면서 서버가 받는 HTTP 요청과 서버가 제공하는 응답을 로그로 남긴다면, 추후 무슨 일이 생겼을 때 추적이 용이하다. 이번 포스팅은 Spring Boot을 사용하여 로그 남기기 시리즈 중 prohannah.tistory.com https://devbksheen.tistory.com/entry/ELK-Filebeat%EB%A1%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%.. [Kibana] Kibana 데이터시각화 구현 https://www.elastic.co/guide/en/kibana/7.11/index-patterns.html Create an index pattern | Kibana Guide [7.11] | Elastic If you don’t set a default time field, you will not be able to use global time filters on your dashboards. This is useful if you have multiple time fields and want to create dashboards that combine visualizations based on different timestamps. www.elastic.co 1. 인덱스 패턴 생성 Stack .. [Elasticsearch] 네트워크 오버헤드 효율 비교 및 개선(쿼리 변경) 개요 기존 프로젝트에서 우리는 오타를 보정하기 위해 검색어와 가장 유사한 검색어들을 차등적으로 리스트의 형태로 제공했다. 이 과정에서 Ngram과 Fuzzy의 분석 결과를 요청하고, 이를 다시 합산하여 가장 스코어가 높은 순서대로 유사하다는 결론을 내렸다. //통합 제목 검색 : 제목 일치 or (Fuzzy + ngram) @GetMapping("/title/aggregate-search") public List searchTitleComprehensive(@RequestParam("title") String title, @RequestParam("maxResults") int maxResults, @RequestParam("fuzziness") int fuzziness, @RequestParam("fu.. [ElasticSearch] 최종 인덱스, 중복 문제와 오탈자 검색의 고민 인덱스 최종 수정 기존에는 필터 유무로 인덱스를 나눴는데. 이는 매우 비효율적인 짓이었다. 그냥 커스텀 분석기를 하나 추가하고, 하나의 인덱스에 적용하면 된다. 특히 match_term 등의 토큰화 과정에서만 2글자 이상 토크나이징 분석기를 사용하면 될 것이다. 그리고 후에 설명할 로직으로 인해 ngram 분석기를 추가하였다. reindex 효율적으로 사용하기 와중에 데이터를 마이그레이션하는 과정에서 reindex가 timeout되는 것을 확인했다. 이는 큰 사이즈의 데이터일 경우 kibana에서 일정 시간 이상 할당한 경우 자체적으로 block하는 것으로 보인다. POST _reindex { "source": { "index": "scrap_wiki_limited_term_length_1109", "s.. [정리]analyzer를 사용한 수집 정보의 유사성 계산 요약 0. 수집 데이터는 기존 데이터와 완벽 매칭되는 것이 아닌 부분 데이터 검색 결과값이다. 1차 개선 : null 배제 후 유의미한 데이터 포집 2차 개선 : 유의미 데이터 중 overview - wiki_title 매칭하여 용어 변수 비교 (동음이의어, 잘못된 설명 제거로 신뢰성 향상) 3차 개선 : attraction_name - wiki_title의 매칭 값을 기존 결과(match_term에) 보정 값으로 추가 (상위 데이터셋 중 임의 데이터 200개 수기 분석 후 보정치 적용) 이를 통해 용어 일치 비율이 20% 이상 되는 값을 신뢰성 있는 데이터로 판단하여 제공하였다. 이를 도식화한다면 다음과 같다. 최초 문제 상황 현재 기본 공공데이터 API의 지명 이름(attraction_name)과, .. 이전 1 2 3 4 다음
