Q. 한 주간 카프카에 대해서 아래와 같이 탐구하고 프로젝트에 적용해 보았습니다.
이러한 방법이 올바른 접근인지 피드백을 받고 싶습니다.
[Spring][258] 웹 서비스 카프카 적용 주간 정리
A. 멘토님답변정리!
접근 O, 더 심도있게 다룰 필요 O
Q. 아키텍처 구성과 관련된 질문 메인서버와 트래픽서버의 구분 이 방식에 대한 의견?
A. 멘토님답변정리!
아키텍처의 구성
메인,트래픽 서버를 나누는것보다는 도메인을 기준으로 나누는것이 확장, 유지보수적으로 유리 할 수 있다. → 추후 메인과 트래픽서버의 모호함이 발생하게 되므로
→ 마이크로 아키텍처의 방향으로 하려면 도메인, 데이터를 우선 기준으로 서버를 독립화 시키는 방향이 좋다. → Consumer group을 각각 → Topic은 1개로 연결
Q. Elasticsearch의 도서 데이터를 넣기 위해서 Logstash를 설치하여 설정 파일을 통해 MySQL DB의 도서 데이터를 전달해보고있습니다.
우선 이러한 방법이 올바른 접근 방법인지 알고 싶습니다.
대량 데이터는 아래처럼 나누어서 로드하는게 맞는지? 아니면 JVM의 메모리를 증가시키는지?
처음엔 별도의 설정 없이 710만건의 도서를 한번에 메모리에 올리고 전달하는 설정을 했고 JVM Heap의 OutOfMemory 문제가 나타났습니다.
따라서 jdbc_paging_enabled 옵션을 추가하여 50000건씩 로드하는 과정으로 나누니 메모리 문제는 나타나지 않았습니다.
설정파일의 주기에 대한 이해도 부족)
하지만 710만건을 다 로드하는데 다시 0부터 로드하고 있습니다.
→ 수가 데이터 카테고리로 테스트해보니 계속 로드하는것이 동일하게 나타났고, 무엇인지 생각해보니 설정 파일의 schedule => "* * * * *" # Query주기 설정에 따른것이고,
계속해서 그래서 매 분마다 SELECT * FROM book_category 쿼리를 실행하여 데이터를 가져오고 Elasticsearch로 전송하고 있는 것인것 같습니다. Logstash가 계속해서 데이터를 가져오고 Elasticsearch에 전송하는 동작을 수행하는것으로 정리.
그럼 계속 도서는 50000건씩 710만을 모두 돌면 계속해서 데이터를 가져오기 위한 동작인것이고, 이해가 됩니다.
그럼 주기가 길면 어떤 문제가 발생하는지 알고싶습니다. 그 사이 업데이트, 삭제 등 없어진 데이터가 있으면 아직 로드되지 않은 상태에서 검색의 오류가 나타날지 등..
A. 멘토님답변정리!
서버를 처음 띄울때 select * from… 이 맞을 수 있어도
서버가 유지되는 상황에서는 update에 대한 것만 불러올수 있는것을 확인해보기.
우선 데이터를 넣어두고,
변화된 데이터만 넣는것으로 구축해야 할 것 같다.
Q. Elasticsearch를 구성한다면 아키텍쳐가 보통 어떤방식으로 구성되는지 궁금했었습니다.
EC2 로컬에 설치하는것으로 생각했었는데 그럼 RDS에 MySQL을 실행하는것 처럼 Elasticsearch만의 별도의 서버를 구성하고 외부접속하듯이 접근해야 하는것으로 잘못 파악했었습니다.
서비스 시 로드밸런서로 인해 검색 요청이 Elasticsearch가 설치되지 않은 서버쪽으로 요청이 간다면 문제가 발생할것 같고, 똑같은 Elasticsearch를 설치해둔다면 그 두개는 각각 별도의 서버기 때문에 일관성은 어떻게 유지할지 궁금했었습니다.
좀더 찾아보니 Elasticsearch 자체가 설치하면서 노드로 구분되고 노드들끼리 연결된 집합들은 클러스터라는 단위로 서로 연결되는것으로 보여집니다.
따라서 Elasticsearch 노드(서버)간 클러스터(집합)을 구성하면 그 안에서는 자동적으로 분산하고 공유하는것 처럼 느껴지는데 맞게 이해하고 있는것인지 궁금합니다.
노드란?
클러스터란??
결론적으로 Elasticsearch 아키텍처의 특징
노드추가하기
A. 멘토님답변정리!
A. 멘토님답변정리!
→ Elasticsearch와 비교하기 위해서는 Full Text 인덱싱에 대한 MySQL 에서의 테스트가 필요하다. → Ela VS Full Text 의 차이를 비교하는것이 핵심
페이징에서 가장 속도에 문제가 있었던 도서 전체 count 부분을 캐싱을 활용하고자 했음
1.
카운트 쿼리 자체를 캐싱하는것도 의미가 있다.
2.
첫페이지나, 특정 키워드의 첫페이지, 또는 그 검색 결과를 캐싱해두면 좋다.
3.
서비스에서 유도한경우( ex 카테고리 처럼, 정해진것 결과가 같은것을 캐싱하면 좋다)
4.
사용 주기와 데이터 업데이트 주기를 서로 고려해서 설계해야 한다.