Project [TEAM258]

# of Posts

100

1 more property

Gallery

백엔드 챌린지에 대한 회고

백엔드 입장에서 프론트엔드에 대한 회고

기타 느낀점

[Spring][258] 프로젝트 완료 후기 회고, 배운점과 아쉬운점

Elasticsearch는 또한 내부적으로 왜 안정적이며, 어떤 알고리즘, 자료구조 등등이기 때문에 빠른것이 보장되는지에 대한 이해도 추가 필요

Elasticsearch가 내부적으로 안정적이며 빠른 이유는 여러 가지가 있습니다.

먼저, Elasticsearch는 Apache Lucene을 기반으로 만들어졌습니다. Lucene은 검색 엔진에 사용되는 강력한 오픈 소스 라이브러리로, 텍스트 인덱싱과 검색에 특화돼 있습니다.

Elasticsearch는 대량의 데이터를 효율적으로 처리하기 위해 여러 가지 알고리즘과 자료구조를 사용합니다. 그 중 하나는 역색인화라는 개념입니다. 역색인화는는 단어가 어느 문서에 나타나는지를 기록해 두어 검색 속도를 향상시키는 데 도움이 됩니다.

Elasticsearch는 분산 시스템으로 설계돼 있어서 여러 노드에 데이터를 분산 저장하고 병렬 처리를 가능하게 합니다. 이렇게 함으로써 데이터 검색 및 분석 작업을 효율적으로 처리할 수 있습니다.

Elasticsearch는 실시간 검색을 지원하고 있어서 데이터가 업데이트되더라도 거의 실시간으로 검색 결과를 반영할 수 있습니다. 이는 대규모의 데이터셋에서도 높은 성능을 제공하는 데 기여하고 있습니다.

엘라스틱 서치의 검색이 빠른 이유?

Elasticsearch는 Lucene 인덱스 를 기반으로 한 검색 엔진입니다.

Lucene은 Apache 소프트웨어 재단에서 개발한 텍스트 검색 라이브러리로, 역색인화를 포함한 다양한 검색 기능을 제공합니다.

엘라스틱 서치는 Lucene을 기반으로 만들어졌기 때문에 Lucene의 강력한 역색인화 기능을 활용하여 대용량의 데이터를 효율적으로 검색할 수 있습니다.

결국, 엘라스틱 서치는 사용자에게 더 편리하고 확장 가능한 인터페이스를 제공하면서 Lucene의 강력한 검색 엔진을 내부적으로 활용하고 있어.

Lucene 의 특징?

Lucene은 텍스트를 단어 또는 토큰 단위로 분석하여 색인화합니다.

[Spring][258] Elasticsearch의 Lucene 인덱싱

질문이 나올만한 부분은 본격적으로 아키텍처 기술도입배경부터 시작된다.

전체적인 요청의 흐름? 전체적으로 클라이언트의 HTTP 요청이 어떻게 처리되는지 알려주세요.

•

기본 흐름

그 흐름에서 카프카는 어떤 역할을 하나요?

•

기본적으로 저희는 메인서버와, 이벤트만을 위한 독립적인 서버가 별도로 존재합니다.

•

서버가 나뉘어졌고 그 중개 역할로 카프카가 데이터를 전달하는 역할입니다.(메시지큐)

동시성 제어가 필요한 이유는 무엇인가요?

트랜잭션, 갱신실패, 데드락

검색 성능을 개선 시킬수 있는 다른방안? 알고리즘과 자료구조랑 관련있는것? 한번 해본것 , 안해본것

[Spring][258] ✅ 예상 질의 응답 목록 - 프로젝트에 대하여 발표흐름에 따른 분류

JPQL 쿼리로 직접 검색 방식 정하기

아래 쿼리를 @Query 어노테이션을 통해서 작성하여 검색의 방식을 변경 할 수 있다. 기존 직접 내부 로직을 구성하는 방식과 다르게, 마치 JPQL을 사용하는것 처럼 쿼리문을 작성 할 수 있다. 그럼 마찬가지로 쿼리문이 컴파일 단계에서 검사되지 않는 단점이 있을 것으로 보여진다.

QueryDSL로 구현해보기

build.gradle 의존성 추가

QueryDSL 플러그인 및 태스크 설정

ElasticBookRepository를 상속받은 ElasticBookSearchRepositoryImpl.java 구현체에서 다음처럼 구현한다. Q객체를 통해서 쿼리팩토리를 통해 쿼리를 메소드형태로 작성하게 된다. 이러면 컴파일 단계에서 개발자의 오류를 찾을 수 있다.

아래는 JPQL로 직접 쿼리를 보낼 때의 각 검색 API이다.

1. 검색API Template

2. 검색 파라메터

[Spring][258] Elasticsearch APIs

[2:22] ELB 설명하실 때 https를 언급하셨는데, 발표자료에도 그 내용이 반영되어 있으면 좋을 것 같습니다. 그리고 main server와 event server의 spring architecture를 모두 보여줄 필요는 없고, application server로 정의한 뒤에 해당 server의 스펙을 하나만 보여주고 main server와 event server가 application server 구조로 되어있다고 보여주면 더 깔끔할 것 같습니다.

발표자료 수정

대본 수정

영상 멘트 수정

[2:58] mysql DB로 부터 도서 데이터가 동기화된다는 표현보다는, logstash가 전처리한 도서 데이터가 elasticsearch에 저장되고, 이 데이터가 mysql에 동기화되고 있다라고 표현하는게 맞을 것 같습니다.

발표자료 수정 없음

대본 수정

영상 멘트 수정

[3:15] ELK stack에 대한 이야기는 이미 앞에서 같이 구축되어 있다는 내용으로도 충분하므로 굳이 안하셔도 됩니다. 오히려 스택을 구성하는 각 요소(elasticsearch, logstash, kibana)에 대해 간단하게 설명해주시는게 더 좋을 것 같습니다.

발표자료 수정 없음

대본 수정 ELK설명은 10초는되니까 우선 전체 수정하고 남는시간보고 파악

ELK Stack은 데이터를 색인화하고 저장하는 ElasticSearch와, 데이터를 수집하고 가공하는 Logstash, 마지막으로 이 데이터를 분석하고 시각화하는 Kibana로 구성됩니다.

영상 멘트 수정

[Spring][258] 발표 피드백 수정[완료]

Spring Boot

Spring Security

JWT

Swagger

Spring Data JPA

Querydsl

Elasticsearch

MySQL

Kafka

Redis

AWS 인프라

[Spring][258] ✅ 예상 질의 응답 목록 - 기술스택과 관련된 것들

1. 검색 기능 업그레이드

•

기존 페이징 버전(v3)

•

슬라이스 방식의 버전(v4)

•

무한 스크롤 기능(is1)

•

엘라스틱 서치 기능(el1)

2. 프론트엔드 네비게이션 변경

•

로그인 상태에 따른 UI 변경

•

사용자의 역할(Role)에 따른 메뉴 표시 변경

기존 모든 코드에 Model을 통해 권한을 전달하는 건 비효율적 -> AOP를 이용해서 전체를 한꺼번에 처리하는 것을 시도

[Spring][258] 프로젝트 마무리 작업

인용

강용영익유헌

•

질의응답 의견결정 관련내용 모두정리

•

API 명세서 표 정리, 스웨거는 결과인 것이므로 표와는 다르다. 이것은 미루었던 일일뿐.

유헌(주말작업 팀장 확인완료)

프론트엔드 부분 추가 수정 필요사항

•

프론트엔드 메인페이지를 로그인 페이지로 시작하고 로그인 이후 도서 검색 페이지를 기본으로 이동하도록 구성

•

프론트엔드 검색부분을 드롭다운으로 단계적 구성 필요한가? 아니면 최종본만 연결할까

•

프론트엔드 네비게이션의 변화필요

[Spring][258] [중요공지] 프로젝트 마무리단계 현재 필요한 작업 업무분담입니다.[완료]

Q. 검색 성능이 점진적으로 개선되지 않고 한번에 올랐습니다.

A. 점진적으로 개선되거나 그런 테스트 결과를 원했겠지만, 그렇지 않을 수도 있습니다. 실제로 그렇기도합니다. 오히려 성능이 나쁠때도 있습니다. 하지만 중요한건 그 테스트 자료들의 그렇다고해서 필요 없는것이 아닙니다. 오히려 그런 모습을 연출하려고 조작되면안되고 그대로 나타나는것이 맞습니다. 그래서 지금 결과가 맞는것입니다.

Q. 향후 프로젝트에서 어떤 부분을 중점으로 진행하면 좋을 까요?

A. FTI와 Elasticsearch를 도입한 부분에서 풀텍스트인덱스의 편차가 발생했던 부분을 더 깊게 파보았으면 좋았을것 같습니다. 물론 프로젝트 끝나고도 계속해서 찾아볼 필요가 있습니다. MySQL의 풀텍인덱스에 대해서 알고리즘이나 자료구조까지 확장해보고 더해서 디폴트 엔진인 InnoDB에 대해서까지 그 차이를 발생시키는것이 무엇인지 알아보기까지.. 그 편차의 원인, 무엇이 그렇게 만들었는지 찾아가는 과정을 계속해서 공부해보시는게 도움 될 수 있습니다. 그게 그 부분에 대해서 다른 어느 개발자보다 잘 아는, 왜 이런 현상이 나타나는지 아는 개발자가 되는 깊은 공부 방법입니다. 특히 이런 깊은 공부를 할때는 공식문서를 참고하는것이 가장 좋습니다. 가장 명확한 근거이기 때문입니다.

멘토님의 충고 공통적으로 기술 스택들에 대해서 근거를 잘 정리해오고 있지만 또한 계속해서 보다 더 정리하는 것이 중요합니다. 그 이유는 이는 곧 기술을 선택 또는 판단하는 능력이고, 그 기술을 선택한 것이 맞다는 근거를 만드는 능력. 이게 실무에서 실제로 이루어지기 때문입니다. 프로젝트 끝에 안주하면 안됩니다. 개발공부 시작입니다. 마무리 될 수 있는 부분은 마무리해야겠지만, 앞으로 더해야할것이 많고, 스트레스 관리와 번아웃을 조절해야 합니다.

[Spring][258] [5주차 멘토링] 질문내용 정리와 답변 + 조언

기획

이 영상은 발표영상이아니다. 소개영상이라 생각해야한다.

발표영상보다 까다롭다. 연출이 필요하다.

제한 시간 2분

초 간단한 영상을 연출해야한다.

핵심적인 내용 딱 2개를 설명해내야 한다.

서비스를 보여주면서 핵심기술을 표현해야한다.

심화내용은 최대한 절제해서 비전문가 마저도 궁금증? 뭘했을까를 도출해내야 한다.

개발자가 근무하면서 개발말고 힘든 일 세가지 | 개발자에게 필요한 능력

개발자가 회사에서 업무를 볼 때 가장 힘들어하는 세 가지가 무엇일까요? 저는 이런 것들이 너무 힘들더라고요. 물론 개발능력이 제일 필요한 것이기는 하지만 이런 것들도 너무너무 필요한 능력인 것 같습니다. #개발자경험담 #예쁘게만들어주세요 🎶BGM 브금대통령 - Kids' Room https://www.youtube.com/watch?v=e4w3WzWeFbg

https://youtu.be/kGD4xH_p_Yg?si=UAdR_VGjWTm0z6nl

[Spring][258] 간단소개 영상 구상[완료]

영상은 피티 흐름에 적절한 내용들을 간결하고 충분하게 설명되도록 구성

씽크는 기본

피티 디자인 콘티

프리미어를 활용한 편집

엔지를 최소화해야한다 시간적 세이브가 필요하다

[Spring][258] 발표 영상&PPT 구성[완료]

프로젝트 기획 배경 설명 (30초)

•

해당 프로젝트를 어떠한 배경과 당위성으로 기획하게 되었는지 설명해주세요.

•

“현실에서 어떠한 문제를 발견하여 어떤 기술을 활용하면 이 문제를 해결할 수 있을 것 같았다.”

시연 영상 재생 (1분)

•

서비스의 핵심이 되는 기능만 시연해 주세요. 즉, 회원가입, 로그인 과정 등은 생략해도 됩니다.

•

서비스 시연에는 변수가 많습니다. 가능한 녹화 영상을 활용하여 발표를 진행해주세요. 

아키텍처 설명 및 기술 도입 배경 (2분)

•

서비스가 어떤 구조를 갖고 있는지, 주요 기능을 구현하기 위해 어떤 기술을 썼는지 설명하는 시간입니다.

•

아키텍쳐 및 도입한 기술을 설명하실 때는 반드시 의사결정 과정을 설명해 주세요.

스프링부트- MySQL 데이터베이스를 기반으로 하고있습니다. DB는 AWS RDS 환경으로 구축되어 있습니다. 추가적으로 카프카 레디스는 동시성 제어를 위하여 있습니다.

엘라스틱서치는 검색 엔진 기능 역할을 위해 별도 EC2 서버에 Logstash와 KIbana와 함께 구축되어 있습니다. MySQL로부터 도서 데이터를 동기화 하고 있습니다.

[Spring][258] 발표 대본 흐름 구상[완료]

초안

저희 프로젝트의 CI/CD와 소프트웨어 아키텍처를 설명드리겠습니다. 저희조는 CI/CD를 Github Action과 AWS의 S3, Codedeploy를 이용해서 구현하였습니다. 저희 GitHub에서 main 브랜치로 pull request를 보내면 GitHub Action을 이용해서 AWS의 S3와 Codedeploy를 통해 AWS EC2 서버로 배포되는 구조입니다. 그럼 이제 저희가 왜 GIthub Action으로 CI/CD를 구성하였는지 말씀드리겠습니다. 저희는 초기 Jenkins와 GitHub Action 사이에서 고민을 하였습니다. Jenkins는 별도의 서버를 준비하고 유지보수해야 하는 비용과 노력이 필요하며, AWS CI/CD에 특화된 도구들과의 통합을 위해 추가적인 플러그인이나 설정이 요구됩니다. Jenkins가 강력한 커스터마이징을 제공하지만, GitHub Actions는 AWS와의 통합 및 관리 측면에서 더 간편하고 효율적인 솔루션을 제공합니다. 또한 GitHub Action을 사용하면 GitHub 리포지토리와의 긴밀한 통합으로 이벤트 기반 워크플로를 쉽게 설정할 수 있고 코드 소스와 CI/CD 파이프라인이 동일한 장소에서 관리되므로 개발자는 별도의 CI 도구로 전환할 필요 없이 편리하게 작업할 수 있기에 선택하였습니다.

그럼 이제 저희 소프트웨어 아키텍처에 대하여 설명하겠습니다. 클라이언트가 요청을 할시 우선 ELB ( ALB )에서 클라이언트가 https 프로토콜을 사용 하는지 살펴보고 http면 https 통신을 하도록 상태코드 301을 통해 리디렉션을 합니다. 클라이언트가 HTTPS 프로토콜을 사용하면 Main Server로 전달해 줍니다. 여기서 클라이언트가 여럿이면 요청을 나누어서 한 서버에서 모든 요청을 처리하지 않게 분배해줍니다. 그 후 Main 서버에서는 클라이언트가 요청한 서비스가 마이크로서비스 아키텍처 구조를 적용한 책 나눔 서비스인지 여부를 파악합니다. 책나눔 서비스는 짧은 시간 대규모의 트래픽이 예상되는 서비스이기에 마이크로서비스 아키텍처 구조를 적용하였습니다. 만약 책나눔 서비스가 아니라면 메인서버에서 자체적으로 처리합니다. 그리고 책나눔 서비스인 경우에는 프로듀서를 통해 카프카로 클라이언트의 요청 데이터를 보내고 이벤트 서버에서는 컨슈머로 요청 데이터를 받은 이후 레디스의 분산락을 통해 동시성 제어를 하며 비즈니스 로직을 처리한 결과를 다시 프로듀서를 통해 카프카 서버로 보냅니다. 메인서비스에서는 컨슈머를 통해 보낸 요청에 해당하는 이벤트 서버의 결과를 비동기적으로 처리하여 클라이언트에게 전달해줍니다. 1차 수정 및 정리

프로젝트의 CI/CD 및 소프트웨어 아키텍처에 대해 안내해 드리겠습니다. 저희 팀은 Github Action, AWS의 S3, 그리고 Codedeploy를 활용하여 CI/CD를 구성했습니다. 이를 통해, Github의 main 브랜치로 pull request가 이루어지면 자동으로 AWS EC2 서버로 코드가 배포되는 시스템을 갖추었습니다.

CI/CD 시스템 선택에 있어, 저희는 Jenkins와 GitHub Action 중 고민 끝에 후자를 선택했습니다. Jenkins는 강력한 맞춤 설정이 가능하지만 별도의 서버 유지 및 AWS와의 통합을 위한 추가 작업이 필요한 반면, GitHub Action은 AWS와의 통합이 용이하고 관리가 더 간단하여 개발자가 더 쉽게 작업할 수 있는 장점이 있습니다.

다음으로 저희 소프트웨어 아키텍처를 설명하겠습니다. 클라이언트의 요청이 들어오면 ELB(ALB)가 이를 받아서 HTTP 프로토콜을 사용하는지 확인하고, 필요한 경우 HTTPS로 리디렉션합니다. 안전한 HTTPS 프로토콜을 사용할 경우 요청은 메인 서버로 전달되며, 이 서버는 요청을 적절히 분산하여 처리합니다. 특히 대규모 트래픽을 처리해야 하는 책 나눔 서비스 같은 경우, 마이크로서비스 아키텍처를 적용하여 요청을 처리합니다. 이는 카프카를 통해 이벤트 기반으로 데이터를 처리하고, 레디스의 분산 락을 활용해 동시성을 제어함으로써 효율적인 서비스를 제공합니다. 마지막으로, 메인 서비스는 이벤트 서버의 결과를 비동기적으로 받아 클라이언트에게 전달합니다.

[Spring][258] CI/CD 및 소프트 웨어 아키텍처 동작 흐름 정리

작업 진행 전

작업 결과

이벤트의 시작과 종료 시간 앞에는 부트스트랩의 아이콘을 사용하여 시각적인 표현을 강화했습니다.
시작 시간에는 '재생 아이콘', 종료 시간에는 '정지 아이콘'을 추가하여 시각적으로 구분이 쉽도록 디자인했습니다.

각 시간 값은 배경색이 적용된 박스 내에 표시하여 가독성을 향상시켰습니다.
이렇게 스타일링된 요소들은 Thymeleaf 템플릿 엔진을 사용해 서버 사이드에서 처리된 날짜와 시간 데이터를 동적으로 표시하게 됩니다.
이러한 스타일링을 적용하기 위해서는 부트스트랩 아이콘 스타일시트를 HTML 문서의 <head> 부분에 포함시켜야 합니다.
th:text 속성을 이용해 서버 사이드에서 전달된 날짜와 시간 데이터를 HTML 요소에 삽입하며 Thymeleaf의 날짜 포맷 기능을 사용하여 날짜와 시간을 'YYYY년 MM월 DD일 HH시 MM분' 형태로 보여줄 수 있습니다.

작업 코드

[Spring][258] 프론트 디자인 작업 _ 책나눔 이벤트 페이지

EC2 Kibana의 외부 접속 환경 설정

Kibana는 Elasticsearch의 데이터를 관제하고 각종 분석도구를 제공합니다. 시각화를 담당하는 HTML + Javascript 엔진이라 볼 수 있습니다.

하지만 EC2에서 구축한 경우 해당 서비스에 접속하기 위해서는 외부 사용자 또는 관리자가 EC2서버의 5601포트에 접근 할 수 있어야 하는데 대부분의 DB는 기본적으로 Localhost를 통한 접근만을 허용하고 있습니다. 따라서 외부 접속에 대한 커넥션을 열어주어야 합니다.

Kibana의 설정 파일은 EC2의 다음과 같은 경로에 위치합니다. vi에디터를 통해 CLI환경에서 파일을 수정합니다.

server.host 부분이 기본적으로 localhost로 되어있으며, 이것 조차 주석처리되어 default가 localhost임을 알려주고 있습니다. 해당 부분에 외부 접근을 허용 할 수 있도록 0.0.0.0을 입력해줍니다.

Kibana의 기본 포트는 5601포트입니다.

:wq 를 통해 저장하고 서버를 재시작해줍니다.

EC2의 인바운드 규칙 설정

외부 접근은 허용했지만 EC2 컴퓨터 자체의 포트 접근을 허용해야 합니다. 이는 AWS EC2의 인바운드 규칙 부분에서 대상 포트를 추가하여 접근 권한을 열 수 있습니다.

현재는 기본 설정인 22 SSH-SFPT 포트와 이전 Elasticsearch의 환경 구축을 통해 추가된 9200 Elasticsearch의 포트만 설정되어 있는것을 볼 수 있습니다.

[Spring][258] AWS EC2 Elastic Stack의 Kibana 외부 접속 환경 설정

1차 Code 정리 [ resource ( JS, CSS, Templates ) ]

•

자원 파일(자바스크립트, CSS, 템플릿)을 체계화합니다.

2차 정리 [ Security Filter 및 domain 일부 불필요 컨트롤러 ]

•

보안 필터 제거 및 도메인에서 불필요한 컨트롤러를 제거합니다.

3차 정리 [ 불필요 서비스 및 레파지스터리 정리 ]

•

사용하지 않는 서비스와 저장소(repository)를 정리합니다.

[Spring][258] EventApply 서버 코드 리팩토링 및 불필요 브랜치 제거 작업

AWS EC2의 Ubuntu환경에서 Elasticsearch를 설치를 완료한 상태에서는 EC2입장에서의 localhost:9200으로만 Elasticsearch에 접근 할 수 있습니다. 본래 EC2 자체를 생성하고 Elastic stack을 설치한 이유는 해당 인스턴스 자체를 Elasticsearch 전용 서버로 사용하기 위함이기 때문에 스프링부트 프로젝트가 실행되는 EC2와 RDS로 구축된 MySQL에서 해당 서버에 외부접속을 통해서 접근 할 수 있어야 합니다.

Elasticsearch 서비스 시작 및 포트확인

우선 Elasticsearch는 기본적으로 9200포트를 사용하며, 기본 설정에서 현재 로컬 서버(EC2)에서만 통신이 가능하도록 지정되어 있습니다.

elasticsearch의 대부분의 설정은 elasticsearch.yml라는 파일에서 관리하고 있습니다. 해당 파일을 열어 일부분 수정하여 외부 주소로 접근 할 수 있도록 하고자 합니다.

해당 파일을 열어보면 path를 제외한 모든 부분이 주석처리된 상태가 기본입니다.

•

기존 network.host 부분은 다음과 같이 # network.host: 192.168.0.1  주석처리되어있을 것이며, 이곳에 network.host: 0.0.0.0 을 작성합니다.

•

cluster.initial_master_nodes 부분도 주석처리 되어있을 것이며, 이곳에 주석을 해제하여 활성화 시켜줍니다.

vi 에디터를 :wq로 저장하고 나와서 Elasticsearch 서비스를 재시작해줍니다

재시작 후 netstat로 확인해 보도록 하겠습니다.

[Spring][258] AWS EC2 Elasticsearch 외부 접속 환경 설정

로컬(나의 컴퓨터)의 외부접속 환경 만들어서 테스트하기

MySQL의 도서데이터는 book 테이블에 존재하고 709만 개의 대용량데이터로 이동 성공 및 실패를 떠나 AWS에 큰 비용을 초래할 수 있기 때문에 충분한 테스트를 진행하고 있는 과정입니다. 따라서 비교적 데이터양이 적은 book_category로 테스트를 우선 진행하고자 합니다.

Elasticsearch, Logstash, Kibana는 다른 컴퓨터(EC2 인스턴스)에 있으며 특히 Logstash는 내 컴퓨터의 MySQL에 접근해야 합니다. 따라서 내 컴퓨터의 MySQL의 외부 접속을 가능하도록 해야 합니다.

이는 AWS RDS에 MySQL을 구축해둔 프로젝트의 방향과 비슷하게 localhost가 아닌 특정 주소를 통해서 데이터를 받아 올 수 있는지에 대한 원격 접근을 테스트하기 위함입니다.

나의 로컬 컴퓨터의 콘솔에서 MySQL의 설정 파일을 찾아야 합니다. 우선 my.cnf 또는 my.ini라는 파일을 찾아야 합니다. 저의 경우 Homebrew를 통해 MySQL을 설치 했기 때문에 /usr/local/etc/ 라는 경로에서 찾을 수 있습니다.

해당 파일을 vi 에디터를 통해 열어보면 MySQL server 설정 정보가 나타나있습니다. 기본 설정은 localhost로 작동하도록 되어 있습니다.

bind-address = 127.0.0.1 부분을 bind-address = 0.0.0.0으로 변경해줍니다.

이제 mysql 서버를 재시작해줍니다.

현재 계정들은 localhost에 대한 접근 권한을 가진 유저들밖에 없습니다.

root으로 MySQL에 접속해서 %로 표기된 모든 호스트로부터 접근 권한을 가진 유저를 만들어봅니다.

[Spring][258] AWS EC2에 구현된 Elasticsearch 에 내 외부(RDS) MySQL 데이터 전달 테스트 및 EC2 스케일업

테스트 기준

MySQL Workbench 8.0을 사용하고 검색 키워드는 “황토집 짓기”를 사용한다.

변수는 ngram_token_size = 2, innodb_ft_min_token_size = 1을 설정하여 인덱싱한다.

인덱싱 기법은 구분자 기법, N gram 기법을, 검색 방식은 아래 세 명령어를 사용한다.

예상 결과

구분자 기법 : keyword를 구분자로 분류하여 저장, 검색 시에는 입력값이 저장된 값과 정확히 동일한 데이터를 출력

N-Gram 기법 : 2글자씩 분류하여 저장, 검색 시 입력값을 2글자씩 분류하여 저장한 값과 일치하는 데이터를 출력

•

CASE1. SELECT * FROM book WHERE MATCH(book_name) AGAINST('황토집 짓기');

구분자 기법의 경우 황토집, 짓기가 띄어쓰기로 정확히 구분된 데이터가 출력될 것으로 예상

N-Gram 기법의 경우 황토, 토집, 집짓, 짓기가 포함된 결과가 모두 출력될 것으로 예상

•

CASE2. SELECT * FROM book WHERE MATCH(book_name) AGAINST('황토집 짓기' IN boolean mode);

[Spring][258] FULLTEXT index 설정 및 검색 명령어 간 결과 테스트

AWS EC2에 Elasticsearch 설치하기

Elasticsearch 전용 EC2 인스턴스 생성합니다. 구글링을 통해 기본적으로 프리티어에서 사용되는 t1.micro로는 문제가 발생하는 것을 확인했고, t2.medium(2core CPU / 4GB RAM)을 최초 구성하는 것이 안정적인 테스트가 될 것으로 판단되었습니다.

인스턴스에 접속

기본적으로 AWS 서비스의 키페어를 생성하고 로컬에 다운 받는 과정은 생략했습니다. 결과적으로 {keyname}.pem 이라는 확장자의 사용자 키를 로컬에 받을 수 있고 이것을 통해서 EC2를 접속할 수 있는 권한을 얻게 됩니다. FTP 접속에서도 필요한 인증 방법입니다.

AWS 콘솔에서 간단히 브라우저에서도 콘솔로 EC2 내부에 접근 할 수도 있습니다. SSH 클라이언트에서 제공해주는 CLI 명령어를 통해서 로컬 터미널을 통해 EC2로 접근했습니다.

Elasticsearch 설치를 위한 JDK 설치

EC2 인스턴스를 초기 생성했으니 패키지매니저를 업데이트 합니다.

Elasticsearch에는 JDK가 필요합니다. 우선 Java부터 설치합니다. 프로젝트에서는 JDK17버전을 사용하고 있으므로 openjdk-17 버전을 설치해줍니다.

정상적으로 JDK가 설치 완료되면 버전을 확인해서 설치 상태를 확인합니다.

[Spring][258] AWS EC2 ubuntu 환경의 Elasticsearch 구축

마이크로 서비스 아키텍처의 필요성

책나눔 서비스는 대규모 트래픽을 효율적으로 처리할 수 있는 시스템 구조가 필수적이었습니다. 이에 따라 기존의 모놀리식 구조에서 마이크로서비스 아키텍처로 전환하며, 이 과정에서 카프카를 도입하기로 결정했습니다. 카프카는 대용량 데이터를 여러 컨슈머가 병렬로 처리할 수 있게 해주어, 트래픽이 급증하는 상황에서도 메시지의 유실 없이 높은 처리량을 유지할 수 있습니다. 또한 각 마이크로서비스가 독립적으로 확장될 수 있도록 지원함으로써, 서비스의 확장성과 안정성을 보장하고, 시스템 전체의 부하 분산을 가능하게 합니다. 이러한 이유로 카프카는 고가용성이 요구되는 대용량 트래픽 환경에 매우 적합한 선택이라고 판단했습니다.

기존 서버의 모놀리식 아키텍처 흐름도

카프카란?

카프카는 실시간 데이터 피드를 관리하기 위한 오픈 소스 스트리밍 플랫폼입니다. 분산 스트리밍 플랫폼으로서, 카프카는 높은 처리량, 내결함성, 확장성 및 실시간 처리 기능을 제공하며, 대규모 데이터 파이프라인을 구축하는 데 주로 사용됩니다.

카프카의 기본 개념과 주요 특징

토픽
카프카에서 데이터 스트림은 토픽으로 구분되며, 이는 메시지를 특정 카테고리로 분류하는 데 사용됩니다.

프로듀서
데이터를 생성하고 카프카 시스템에 전송하는 역할을 합니다.
프로듀서는 특정 토픽으로 메시지를 발행합니다.

[Spring][258] 카프카를 통한 서비스 아키텍처 구조 개선

레디스 분산 락이란?

레디스(Redis) 분산 락은 여러 컴퓨터 또는 프로세스 간에 자원의 동시 접근을 제어하기 위한 메커니즘입니다. 분산 시스템에서 여러 노드가 동일한 자원에 접근하려 할 때, 일관성과 순서를 유지하면서 동시성 문제를 해결하는 데 쓰입니다.

레디스 분산 락의 필요성

•

동시성 관리: 복수의 인스턴스가 동일한 데이터를 동시에 수정하려 할 때, 데이터 불일치를 방지합니다.

•

일관성 유지: 분산 시스템 내에서 데이터의 일관성을 유지하며, 작업의 순서를 보장합니다.

•

데드락 방지: 데드락을 감지하고 해결하는 메커니즘을 제공합니다.

레디스 분산 락의 작동 원리 ( Redisson )

락 회득: Redisson은 Lua 스크핍트를 사용하여 락을 획득합니다. 이 스크립트는 락키가 존재하지 않는 경우에만 락 키를 생성하고, 이 키에 대한 유효 시간 (TTL)을 설정합니다.
이로 인해 서버나 애플리케이션에 문제가 발생하여 락을 해제하지 못하는 경우에도 설정된 유효 시간 이후에 자동으로 락이 해제됩니다.

레디스 키의 유효기간: 락을 회득 시 레디스 키에 유효기간을 설정하여 락 획득자가 특정 시간 안에 작업을 완료하지 못하면 락이 자동으로 해제되도록 합니다. 
이를 통해 데드락을 방지합니다.

락 재진입: Redisson은 동일한 락을 여러번 회득 할 수 있는 재진입 가능한 락을 지원합니다.
Lua 스크립트는 락을 요청하는 쓰레드나 인스턴스가 이미 락을 보유하고 있는지를 확인하고 만약 락을 가지고 있다면 락 획득 요청을 허용하여 재진입을 가능하게 합니다.

[Spring][258] 레디스 분산락을 이용한 동시성 문제 대응

Kafka를 시도하는 이유

현재 진행 중인 프로젝트의 서비스는 대용량 트래픽을 받는 서비스입니다.

확장성이 중요한 경우

탄력성과 고가용성이 중요한 경우

즉 저희 서비스의 확장성과 안정성, 서버 과부하 방지, 동시성 문제를 성능 저하하는 락없이 해결하기 위해 카프카를 시도하였습니다.

KafKa의 동작 흐름

프론트엔드에서 요청: 사용자의 액션에 의해 프론트엔드에서 백엔드로 HTTP 요청이 전송됩니다.

Kafka 컨트롤러: Spring Boot 어플리케이션 내의 컨트롤러가 HTTP 요청을 받아 처리합니다.

Kafka 프로듀서: 컨트롤러는 Kafka 프로듀서를 통해 메시지를 Kafka 서버의 특정 토픽으로 전송합니다.

[Spring][258] 카프카 도입으로 구조적으로 동시성 문제에 대응

[Spring][258] 소프트웨어 아키텍처 및 CI/CD 가독성 올린 구조로 수정

MySQL DB의 데이터와 Elasticsearch 데이터는 동기화로 일관성을 유지해야 한다.

기존 MVP 기능으로 도서의 정보를 변경하는 부분들이 있습니다. 특히 Elasticsearch와 연결된 도서 목록에서 사용자는 도서 대출, 도서 대출 예약을 진행 할 수 있습니다.

사용자가 도서 대출을 진행하면 도서의 대출 가능 여부를 알 수 있는 Status 컬럼은 POSSIBLE에서 IMPOSSIBLE로 변경됩니다. 해당 기능은 HTML의 Ajax HTTP 요청을 통해 MySQL DB에 있는 대상 book_id의 도서의 상태를 즉시 변경하지만, Elasticsearch는 MySQL의 DB를 Logstash로 가져와서 인덱싱하기 때문에 이 과정에서 새로 목록을 불러와야 할 필요성이 있습니다.

Logstash의 데이터 변경 추적 설정 필요성

기존 Logstash를 통해 MySQL의 DB를 전달하여 색인하는 부분입니다. 709만개의 도서 데이터를 한번에 읽어오는 과정에서 JVM의 메모리 부족 현상이 발생하여 200만개씩 메모리에 로드하고 Elasticsearch로 전달하도록 구성되어있습니다.

하지만 이 부분에서 설정의 문제점이 있습니다.

•

최초 실행 1회 이후로 데이터를 전달하고 해당 소스는 종료됨

•

MySQL DB의 변경사항이 생기면 수동으로 해당 파일을 다시 실행시켜 주어야 업데이트가 됨

•

다시 한번 200만개씩 총 709만개를 돌면서 업데이트가 아닌 모든 정보를 덮어쓰는 형태

최초의 전체 709만개 도서 데이터 전달은 기본적으로 실행되어야 하는데 지속적으로 어떤 도서의 정보 업데이트에 대한 별도 동기화 처리가 필요했습니다.

Logstash의 tracking_column을 이용한 변경 추적

Logstash와 JDBC를 사용해 RDBMS와 Elasticsearch의 동기화를 유지하는 방법

Elasticsearch가 기존 관계형 데이터베이스(RDBMS)와 더불어 검색 솔루션으로 배포될 때, 두 데이터 저장소 간에 데이터 동기화를 유지하는 것이 중요합니다. Logstash JDBC 입력 플러그인을 이용해 손쉽게 데이터를 동기화하는 방법을 알아보세요.

https://www.elastic.co/kr/blog/how-to-keep-elasticsearch-synchronized-with-a-relational-database-using-logstash

공식 문서에 따라서 tracking_column을 통해서 특정 컬럼의 값이 변경되는 것을 추적할 수 있고, Elasticsearch에 변동된 행만을 업데이트 할 수 있는 방안이 있었습니다.

[Spring][258] MySQL→Logstash→Elasticsearch 의 동기화 처리에서 발생하는 문제

현재 프로젝트에서 책 대출, 책 나눔 신청 2가지 기능에서 동시성 오류가 발생합니다.

1. 책 대출 신청

사용자는 아래와 같이 책을 검색하고 대출 버튼을 눌러 책을 대출할 수 있습니다.

여러명이 동시에 같은 책에 대한 대출 버튼을 누르는 경우 아래와 같이 여러 건의 책 대출 데이터가 생기는 동시성 문제가 발생합니다.

2. 책 나눔 신청

사용자는 아래와 같이 책 나눔 이벤트에서 책 옆의 apply 버튼을 눌러 책 나눔 신청을 할 수 있습니다.

[Spring][258] 현재 프로젝트 내에서 동시성 문제

발생 가능한 여러가지 문제

[Spring][258] 웹 서비스 동시성 제어

1. 개요

동시성 문제를 해결하기 위한 다양한 방법들을 모두 적용해보며 JMeter로 테스트를 하고 최종적으로 결정한 방법을 선택한 과정을 정리하였습니다.

2. 동시성 해결 성능 테스트

책 나눔 신청에 대한 동시성 오류를 해결하기 위해 아래의 4가지 방법을 사용하였습니다.

뮤텍스

낙관적락

비관적락

@Transactional(isolation = Isolation.SERIALIZABLE)

4가지 방법 모두 동시성 오류가 성공적으로 해결이 되었고, 이에 대한 성능 테스트를 진행하였습니다.

테스트는 로컬에서 진행하였으며, Jmeter로 100개의 쓰레드에서 요청을 0.1초 안에 보내는 방식으로 여러 번 측정하여 평균값을 구하였습니다. 테스트 결과는 아래와 같습니다.

[Spring][258] 데이터베이스 및 애플리케이션 레벨에서의 동시성 문제 대응

지속적인 통합(CI)과 지속적인 배포(CD) 란?

개발 환경에서 지속적인 통합(CI)과 지속적인 배포(CD)는 코드의 품질을 유지하면서 빠르고 안정적인 배포를 가능하게 하는 핵심 요소들입니다.

지속적인 통합 (CI)

•

*지속적인 통합 (Continuous Integration, CI)**은 개발 팀이 자주 코드 변경사항을 중앙 리포지토리에 통합하는 프로세스를 말한다. 이러한 접근 방식의 주요 이점은 다음과 같습니다.

•

버그 감소: 자주 코드를 통합함으로써 발생할 수 있는 문제를 조기에 발견하고 해결할 수 있다.

•

비용 절감: 버그를 조기에 발견함으로써, 문제 해결에 드는 비용을 줄일 수 있습니다.

•

시간 절약: 개발자들은 시스템이나 애플리케이션의 더 나은 구조에 집중할 수 있으며, 코드 통합에 드는 시간을 절약할 수 있습니다.

지속적인 배포 (CD)

•

*지속적인 배포 (Continuous Delivery, CD)**는 CI 프로세스를 확장하여, 새로운 변경사항을 사용자에게 빠르고 안정적으로 제공하는 방법을 포함한다. 지속적인 배포의 핵심 요소들은 아래와 같습니다.

•

자동화된 테스트: 코드가 통합된 후 자동화된 테스트 스위트를 실행하여 버그 및 회귀를 식별합니다.

[Spring][258] CI/CD GitHub Action을 선택한 이유

책 나눔 서비스

책나눔 서비스는 사용자가 지정된 기간 내에 접속하여 원하는 도서를 요청하고 먼저 신청한 사용자가 해당 책을 수령할 수 있는 서비스입니다. 이 서비스는 짧은 시간 내에 많은 사용자가 동시에 도서를 신청하는 방식으로 운영되므로 상당한 양의 트래픽이 발생할 것으로 예상됩니다. 그렇기 때문에, 트래픽의 증가에 유연하게 대응할 수 있도록 서비스 확장성을 고려해야 합니다. 이에 따라, 기존 단일 구조의 모놀리식 아키텍처보다는, 필요에 따라 쉽게 확장할 수 있는 마이크로서비스 아키텍처로 전환하려고 합니다.

[Spring][258] 프로젝트 내 마이크로서비스 아키텍처 적용

마이크로 서비스 아키텍처란?

마이크로서비스 아키텍처는 소프트웨어 개발에서 사용되는 설계 접근 방식 중 하나입니다. 이 아키텍처는 큰 규모의 애플리케이션을 작고 독립적으로 실행 가능한 서비스들의 모음으로 분할합니다. 각 서비스는 특정 비즈니스 기능을 담당하고, 서로 독립적으로 개발, 배포, 운영될 수 있습니다.

마이크로서비스 아키텍처의 주요 특징

분산 구조: 애플리케이션의 기능이 작고 독립적인 서비스로 나뉘어져 있으며, 각각 독립적으로 개발 및 배포될 수 있습니다.

서비스 지향: 각 기능은 서비스로서 개별적으로 기능하며, API를 통해 서로 통신합니다.

수평적 확장: 시스템을 확장하기 위해 개별 서비스를 복제하거나 분산하여 시스템의 부하를 분산시키는 수평적 확장이 가능합니다.

복잡성의 분산: 시스템의 복잡성이 각 서비스로 분산되어 있어, 관리 및 업데이트가 유연합니다.

장애의 격리: 하나의 서비스에 문제가 발생하더라도, 다른 서비스는 영향을 받지 않거나 최소화되는 장애 격리 특성을 가집니다.

프로젝트 내의 마이크로서비스 아키텍처 적용의 필요성

프로젝트에서는 대규모 트래픽을 처리하는 책나눔 서비스에 직면하여 효율적인 관리와 확장성을 위해 책나눔 서비스에 마이크로서비스 아키텍처 적용이 필요하다고 생각합니다. 이는 책나눔 서비스의 확장성과 유연성을 크게 향상시켜서 독립적으로 확장할 수 있게 하며, 시스템 전체의 안정성을 강화합니다. 특히 트래픽이 많은 책 나눔 서비스를 개별적으로 리소스를 조정하여 전반적인 서비스의 탄력성을 보장할 수 있습니다. 이러한 접근은 저희 프로젝트의 지속가능한 확장과 향후 시장의 변화에 유연하게 대처할 수 있기에 책나눔 서비스에 대한 마이크로서비스 아키텍처가 필요한 것으로 보입니다.

[Spring][258] 마이크로서비스 아키텍처

문제 상황 및 원인

구분자 기법의 FULLTEXT indexing은 keyword를 자동으로 규칙에 맞춰 분류해 준다. 그러나 검색 시에는 생성된 keyword가 정확히 일치한 데이터만 출력해 준다. 그렇기에 like 구문을 사용한 데이터와 구분자 기법의 FULLTEXT index를 활용한 데이터는 서로 다른 결과값을 출력한다.

해결 방법

MySQL FULLTEXT indexing 기법에는 N-gram 기법이 있다. 구분자 기법과는 다르게 모든 데이터를 N글자씩 분리하여 keyword로 생성하는 방법이다.

분리되는 글자 수는 ngram_token_size 변수명으로 관리되고 있고 변경하려면 my.ini에 동일하게 값을 넣어 수정할 수 있으나 기본값이 2이기에 따로 수정하지 않았다.

기존 명령어 뒤에 ngram parser를 활용하도록 코드를 작성하는 것으로 생성할 수 있다.

그러나 ngram 기법도 완전한 해결책은 될 수 없다. 3글자 이상의 키워드를 검색하게 될 경우, 키워드의 일부분이 포함된 모든 결과가 도출된다. 예를 들어 스프링 을 검색하게 된다면 스프 가 들어간 데이터들과 프링이 들어간 데이터들이 모두 출력되어 스프링이 검색은 되는데 정확도가 떨어진다.

[Spring][258] keyword 검색 시 keyword를 포함한 일부 데이터가 검색되지 않는 문제

MySQL에서 지원하는 FULLTEXT 명령어는 기본적으로 구분자 기법을 사용하고 있기에 단순한 명령어만으로도 인덱싱이 가능하다.

위 명령어를 입력하면 자동으로 해당 테이블의 해당 컬럼을 기준으로 index를 생성한다.

다만 시간이 오래 걸릴 경우 workbench에서는 timeout이 일어나기에 명령 프롬프트에서 mysql에 접근해 명령어를 입력해 주어야 했다.

FULLTEXT index를 활용한 검색은 LIKE절을 사용하지 않는다. MATCH ~ AGAINST라는 FULLTEXT index를 위한 검색 명령어가 따로 존재한다.

위 명령어를 통해 FULLTEXT index 검색을 활성화할 수 있다.

explain() 명령어에 위 명령어를 넣어 실행하면 fulltext index를 사용하고 있음을 볼 수 있다.

Like 구분을 사용했을 때보다 훨씬 빠른 응답을 보여주고 있다.

그러나 like 구문을 사용했을 때와는 다르게 동일한 검색어에도 다른 결과값이 나오고 있는데, 이는 구분자 기법으로 생성된 keyword가 정확히 “스프링”으로 분리되지 않았다면 이 방법으로는 찾을 수 없게 되어 일부 데이터가 감지되지 않은 것이다.

[Spring][258] 구분자 기법을 활용한 FULLTEXT indexing

문제 상황

기본 설정으로 FULLTEXT indexing을 하게 되면 3글자 이상의 단어들만 검색이 가능하며, 2글자 이하의 단어는 검색이 되지 않는다.

문제 원인

기본적으로 MySQL은 Storage engine으로 innodb라는 것을 사용한다.

%programdata%\MySQL\MySQL Server 8.0\my.ini 파일을 보면 아래와 같은 설정이 되어 있음을 알 수 있다.

위 현상이 발생하는 이유는 이 innoDB와 연관이 있다.

sql의 변수 중 innodb_ft_min_token_size 라는 값이 있는데, FULLTEXT indexing 시에 해당 변수의 값보다 작은 크기의 글자들은 인덱스화하지 않고 버리게 된다. 해당 변수의 기본 설정값은 3이기에 3글자 이상의 단어들만 인덱스에 사용하고 2글자 이하의 단어들은 모두 버리게 된다.

예를들면 ‘자바 스프링’ 이라는 단어를 구분자(” “)를 기준으로 분리하면 ‘자바’와 ‘스프링’이 남는데, 자바는 두 글자 단어이므로 버리고 스프링은 세 글자 단어이기에 저장하게 된다. 이로 인해서 스프링으로 검색하면 ‘자바 스프링’ 결과를 얻을 수 있지만, 자바로 검색하면 결과를 얻을 수 없게 된다.

해결 방법

그렇다면 해결 방법은 간단하다. innodb_ft_min_token_size 값을 수정하면 된다. MySQL의 변수 변경은 SET을 통해 수정할 수 있다.

[Spring][258] 구분자 기법의 FULLTEXT index가 2자 이하의 단어를 검색할 수 없는 문제

FULLTEXT index

FULLTEXT 인덱스는 문자열 데이터에 대해 전문 검색 기능을 제공하는 인덱스 유형이다. 이를 사용하면 특정 단어 또는 구문이 포함된 문장을 빠르게 찾을 수 있다. FULLTEXT 인덱스는 전체 문장을 토큰으로 분해하여 효과적으로 검색을 수행할 수 있도록 만들어 준다.

FULLTEXT index에는 두 가지 기법이 있다.

구분자(Stopword) 기법

•

공백, 탭, 문장기호, 또는 사용자 정의 문자열을 구분자로 등록

•

구분자 기법은 이렇게 생성한 구분자를 이용하여 내용을 분리, 키워드를 분석하고 결과 단어를 인덱스로 생성해 두고 검색에 이용하는 방법

•

MySQL에는 기본적으로 지정된 구분자가 있으며, 이를 비활성화할 수 있음.

N-그램(N-Gram) 기법

•

컬럼의 내용을 무조건적으로 N자씩 잘라서 인덱싱하는 방법

•

구분자 기법보다 알고리즘이 복잡하고 크기가 큼

•

다양한 언어에 대한 하나의 규칙을 적용하거나 키워드 일부 검색이 불가능한 구분자 기법을 보완할 수 있음

•

N은 인덱싱할 키워드의 최소 글자 수를 의미하고, 일반적으로 2의 크기를 가짐.

[Spring][258] FULLTEXT indexing

1. 접속 환경 설정

build.gradle 의존성 추가

application.properties 연결 주소 입력

ElasticsearchConfig.java를 통한 Elasticsearch 실제 커넥션

application.properties에서 직접 연결 할 수도 있지만 모듈화시켜서 구조를 살펴보고자 했습니다.

2. 3 Layered 아키텍처와 Elasticsearch 연결

ElasticsearchBook.java JPA엔티티와의 충돌을 막기 위한 전용 엔티티 생성

기존 Book.java 엔티티에 @Document 어노테이션을 사용하면 JPA와 Elasticsearch가 동시에 해당 엔티티에 접근하게 되면서 충돌 문제가 발생했었습니다. 여러 참고자료를 찾아본 결과 ~Application.java 메인 이닛 클래스에서 @Enable.. 어노테이션을 통해서 각각 스캔 대상을 분리 시킬 수도 있지만, 우선 간략한 테스트 과정을 위해서 우선 별도의 엔티티를 생성하는 것으로 대체했습니다.

•

@Document어노테이션으로 인덱스명(RDBMS의 테이블명과 비슷)을 입력하면 의 인덱스와 맵핑됩니다.

•

@Field어노테이션으로 각 필드(RDBMS의 컬럼과 비슷) 타입, 이름을 지정하게 됩니다.

•

Elasticsearch는 소문자로만 구성하라는 주의사항이 있었고 이름에 스네이크 컨벤션을 유지했습니다.

[Spring][258] 프로젝트에서 3 Layered Architecture와 Elasticsearch 연결 테스트

문제 원인

문제의 원인은 SSH 키 파일(Team258_RedisServer.pem)의 권한이 너무 개방적으로 설정되어 있어서 발생한 걸로 추정 됩니다. 이 파일은 사용자 본인만이 접근할 수 있도록 제한되어야 합니다.

문제 해결

키 파일의 속성 변경

•

Team258_RedisServer.pem 파일을 마우스 오른쪽 버튼으로 클릭하고 '속성'을 선택합니다.

•

'보안' 탭으로 이동합니다.

고급 보안 설정 접근

[Spring][258] 트러블 슈팅 : SSH 권한 부족 GUI 기반 문제 해결

분산락 이란 동시성 문제를 해결하기 위한 방법 중 하나로 같은 자원에 접근할 시 락을 제공하여 접근이 완료되면 락을 해제하여 다음 순번에게 넘어가는 방식이다.

분산락을 사용하는 이유는 분산된 서버 및 분산된 DB환경에서도 동시성 이슈를 해결하기 위함이다.

분산락을 Redis로 구현하는 방법에는 lettuce, redisson 라이브러리가 있는데 lettuce방식은 스핀락(락을획득하지 못할 경우 계속 요청) 방식으로 redis에 부하가 갈 수 있어 redisson을 사용하여 구현해보았다.

RedissonConfig를 작성하여 Bean에 등록하고

BookApplyDonationService에 아래와 같이 구현하였다.

잘 구현은 되나 bookApplyDonation2 를 추가로 생성하여 만드는 찝찝함이 있는데 이에 대한 내용은 별도 트러블슈팅 문서에 정리하겠다.

[Spring][258] redisson 분산 락 구현

여러 방법으로 동시성 문제를 해결한 방법들에 대해서 성능 테스트를 진행하였다.

Jmeter로 100개의 쓰레드에서 0.1초로 요청하였음

Jmeter 첫번째 테스트 시 매우 큰(느린) 값이 나오는 이슈가 있어 평균값에서 제외하고 2,3번쨰 시행의 평균값을 냈다.

[Spring][258] 동시성 해결 성능 테스트

Redis 분산락 구현 ( AWS Server )

설치 환경

•

AWS EC2 Ubuntu

•

c5.xlarge

Redis EC2에 설치

Redis 설정 파일 변경

[Spring][258] AWS EC2 Redis 분산락 구현

버전 호환 확인 필요

버전간의 제공되는 클래스, 삭제된 기능 등 레퍼런스간의 차이가 유독 심해서 기능 구현에서 참고 자료를 활용하지 못하는 경우가 많았다.

Spring Data Elasticsearch - Reference Documentation

https://docs.spring.io/spring-data/elasticsearch/docs/current/reference/html/#preface.versions

많은 예제에서 사용하고 있는 RestHighLevelClient의 사용 불가 문제

spring-data-elasticsearch:5.1.3 버전에서 RestHighLevelClient을 사용 할 수 없었습니다. RestHighLevelClient는 Elasticsearch를 RESTful API를 통해 효과적으로 사용할 수 있도록 하는 Elasticsearch Java 클라이언트 라이브러리 중 하나입니다. 이 라이브러리는 Elasticsearch의 REST API와 상호 작용하여 데이터를 쿼리하고 색인화하며, 기타 Elasticsearch 작업을 수행하는 데 사용됩니다. 이를 통해 객체 지향적이고 사용하기 편리한 인터페이스를 제공합니다.

하지만 5.0버전 이후로는 해당 클래스를 사용 할 수 없게되었습니다. 5.X버전 이후의 유사 클래스를 찾고자 했으나

다양한 예제를 참고하여 아래와 같은 4.2.2 버전을 주입하여 RestHighLevelClient를 사용 할 수 있었습니다.

build.gradle에서 의존성주입 시

implementation 'org.springframework.data:spring-data-elasticsearch로 하는 경우 
자동으로 관련 라이브러리 버전에 따라 설치하게 되는데 버전의 문제가 있었다. 버전을 아래처럼 직접 기입하여 원하는 버전을 주입 할 수 있도록 했다.

다른것보다, 특정 기능을 구현하는데 있어 의존성 버전별로 기능이 삭제되는 경우가 있어 새로운, 또는 과거의 구현 방법을 어느 정도 찾아 볼 수 있어야 하는 것을 느꼈습니다. 우선 이 프로젝트에서는 RestHighLevelClient 를 사용한 구현법을 익혀보는데 집중해보고자 합니다.

Elasticsearch Java API Client [7.17] | Elastic

메인 서버 스캐일 업

•

기존 인스턴스 t1.micro에서 c5.large로 변경

•

IOPS 3000

이벤트 적용 서버 스캐일 업

•

기존 인스턴스 t1.micro에서 c5.xlarge로 변경

•

IOPS 3000

Redis 서버 스캐일 업

[Spring][258] 서버 스케일 업: AWS EC2 인스턴스 업그레이드 및 성능 향상

1. 문제

처음에 bookApplyService.java 에서 redisson으로 분산락을 구현한 코드는 아래와 같다

위와 같이 작성 시 기존 10개정도 발생하는 동시성 문제가 2~3개로 줄어들었으나,

2~3개의 동시성 문제가 발생되는 문제가 있었다.

2. 원인

위에서 작성한 코드의 일부이다.

@Transactional로 만들어진 트랜잭션이 닫히는 시점은 메소드가 끝나는 시점인데,

락을 해제하는 부분은 메소드가 끝나는 시점 이전이다.

따라서 락을 해제하고 메소드가 끝나는 시점 사이에 트랜잭션이 닫히지 않아서 동시성 이슈가 일부(1~2개) 발생하게 된다.

3. 해결

처음엔 클래스 내에서 추가 메소드를 작성하여 아래와 같이 로직 부분만 @Transactional을 걸어주었으나,

@Transactional 이 붙지 않은 메소드에서 같은 클래스 내 @Transactional 이 붙은 메소드를 실행하면 @Transactional이 적용되지 않는다고 한다.

[Spring][258] redisson 분산 락 구현 문제

Q. 한 주간 카프카에 대해서 아래와 같이 탐구하고 프로젝트에 적용해 보았습니다. 이러한 방법이 올바른 접근인지 피드백을 받고 싶습니다. [Spring][258] 웹 서비스 카프카 적용 주간 정리

A. 멘토님답변정리! 접근 O, 더 심도있게 다룰 필요 O

A. 멘토님답변정리! 아키텍처의 구성 메인,트래픽 서버를 나누는것보다는 도메인을 기준으로 나누는것이 확장, 유지보수적으로 유리 할 수 있다. → 추후 메인과 트래픽서버의 모호함이 발생하게 되므로

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 노드(서버)간 클러스터(집합)을 구성하면 그 안에서는 자동적으로 분산하고 공유하는것 처럼 느껴지는데 맞게 이해하고 있는것인지 궁금합니다.

A. 멘토님답변정리!

A. 멘토님답변정리! → Elasticsearch와 비교하기 위해서는 Full Text 인덱싱에 대한 MySQL 에서의 테스트가 필요하다. → Ela VS Full Text 의 차이를 비교하는것이 핵심 페이징에서 가장 속도에 문제가 있었던 도서 전체 count 부분을 캐싱을 활용하고자 했음

[Spring][258] [4주차 멘토링] 질문내용 정리와 답변

[Spring][258] Jmeter을 통한 대용량 트래픽 발생 성능 테스트

1. 문제

현재 진행하는 프로젝트에서 여러명이 동시에 1개의 책에 대해서 대출을 신청할 때 동시성 오류 발생

JMeter을 이용하여 100명이 동시에 1개의 책을 대출신청하도록 설정하였다.

Book과 BookRent는 일대일 관계이나, 10개의 bookRent가 생성된 모습이다.

2. 원인

책을 대출하는 로직은 아래와 같다.

대출을 하면 book의 status가 IMPOSSIBLE이 된다.

IMPOSSIBLE이 되면 book을 대출할 수 없는데, IMPOSSIBLE 상태가 되기 전 다수의 요청이 들어가서 여러개의 BookRent가 만들어지는 것으로 추정된다.

3. 해결

1. 비관적 락 사용

Book을 조회할 때 비관적 락을 사용하여 동시성 이슈를 해결하였다. READ는 가능하도록 PESSIMISTIC_READ로 설정함

[Spring][258] BookRent 동시성 문제 해결

이번주 동안 카프카를 진행한 내용

초기

Kafka를 시도하는 이유

→ kafka를 사용하면 데이터 베이스나 애플리케이션에 락을 걸지 않고 전송 속도를 제어해서 동시성 문제가 발생하지 않는 속도로 순차적으로 전달한다면 락보다 속도가 빠를것입니다.

→ 서비스가 계속 성장하고 더 많은 트래픽을 처리해야 할 경우, Kafka는 쉽게 확장할 수 있는 구조를 가지고 있어 미래의 성장에 대비할 수 있습니다.

→ Kafka는 분산 시스템으로 설계되어 있어 노드 하나가 실패하더라도 서비스의 가용성을 유지할 수 있습니다.

즉 저희 서비스의 확장성과 안정성, 서버 과부하 방지, 동시성 문제를 성능 저하하는 락없이 해결하기 위해 카프카가 필요합니다.

일반서비스와 대용량 서비스를 카프카를 통해 분리해서 처리하는 측면에서도 필요합니다.

[Spring][258] 웹 서비스 카프카 적용 주간 정리

대량의 도서 데이터 준비

약 710만건의 도서 데이터가 CSV파일로 정리되어있습니다. 문화데이터 포털의 도서 정보 데이터를 활용하고 있습니다.

이전 MySQL을 활용했던 기본 검색 기준에서도 동일한 데이터를 MySQL의 LOAD FILE을 통해서 입력해서 사용했었기 때문에 동일한 데이터를 Elasticsearch에 넣어서 검색 성능의 차이를 살펴보고자합니다.

Elasticsearch에 데이터를 넣는 방법

기본적으로 Elasticsearch에 직접 데이터를 넣는 방법과 Logstash를 활용하는 방법이 있습니다. 우선 직접 데이터를 넣는 방법으로 간단한 테스트부터 진행해보고자 합니다.

Elasticsearch에 데이터를 직접 넣기

준비된 데이터를 Elasticsearch에 직접 넣기 위해서는 각 데이터를 JSON 형식으로 변환하고 적절한 인덱스에 색인해야 합니다.

MySQL로 넣을때 엔티티 이름과의 통일을 위해서 원본 csv의 파일의 내용을 변환하여 저장했습니다. 카테고리 또한 분류법을 단순화시킨 DB 기준으로 원본의 카테고리 번호를 변환했었습니다.

통일성을 주기 위해서 MySQL의 "컬럼(column)" 개념과 유사한 역할을 하는 것이 Elasticsearch에서의 "필드(field)"입니다. 따라서 필드의 이름을 Entity 기준으로 변경, 카테고리 또한 DB를 기준으로 연산되어 필드값으로 들어 갈 수 있도록 데이터 전처리 스크립트인 아래 쉘 스크립트를 수정했습니다.

위 스크립트를 convert.sh라는 파일로 작성합니다. CLI환경에서는 nano 또는 vi 에디터를 사용 할 수 있습니다. GUI환경이 제공된다면 단순하게 메모장 또는 IDE들을 활용해서 해당 스크립트 파일을 작성해두면 됩니다.

[Spring][258] Elasticsearch 검색 성능 개선 05(X) - 대량 데이터 넣기 실패과정과 데이터 재가공을 통한 문제 해결

Elasticsearch 설치 이후, Logstash와 Kibana 설치 이유

Elasticsearch를 단순 DB로 보고 데이터를 넣어보고자 했으나, 궁극적으로 Elasticsearch를 사용하는 목적에 큰 영향을 주는 부분이 아니라고 판단되었습니다. Logstash를 사용하여 다양한 데이터 소스에서 데이터를 수집하고 Elasticsearch에 전송하는 것은 일반적인 방법이므로 곧바로 적용해보기로 결정했습니다.

또한 Kibana라는 분석 툴에서 어떤것들을 확인 할 수 있는지 확인하고자 이 또한 설치하면서 ELK 스택을 모두 설치해보는 기본 환경 구축을 진행하고자 합니다.

Logstash, Kibana 설치

Elasticsearch 설치 과정은 아래 링크

[Spring][258] Elasticsearch 검색 성능 개선 03 - Elasticsearch 설치와 테스트 실행 및 설치과정 사소한 트러블슈팅

Elasticsearch와 동일한 문제가 발생해서 곧바로 패키지 설치 정보를 수정해주었다.

Elasticsearch, Logstash, Kibana를 설치하고 모두 실행시켜줍니다.

[Spring][258] Elasticsearch 검색 성능 개선 04 Logstash, Kibana 추가 설치 ELK stack 구성

MySQL - Logstash - Elasticsearch의 연결을 하는 이유?

간단히 mysql의 데이터를 사용해서 elasticsearch에서 검색을 하기위해서는 elasticsearch DB에 데이터를 담아야합니다. 이를위한 도구로서 Logstash를 사용하게 됩니다.

Logstash을 사용하여 MySQL과 Elasticsearch 간의 데이터 전송을 쉽게 설정할 수 있습니다. Logstash은 다양한 데이터 소스에서 데이터를 수집하고 처리하여 다른 저장소로 전송하는 역할을 합니다.

해당 과정은 Elasticsearch, Logstash, Kibana인 ELK 스택을 설치한 이후로 진행되는 과정입니다. 아래 링크를 통해 설치와 실행 상태를 확인후 진행해야 합니다.

설치와 관련된 링크 참고

우선 Logstash를 통해 Elasticsearch에 데이터가 전달되어야 한다.

Logstash를 통한 Elasticsearch 데이터 전달 설정 절차

Logstash 설치: 먼저 Logstash을 설치합니다.

Logstash 설정 파일 작성: Logstash은 설정 파일을 통해 입력(Input), 필터(Filter), 출력(Output)을 정의합니다. MySQL과 Elasticsearch 간의 연결 정보를 설정합니다.

Logstash 실행: 작성한 Logstash 설정 파일을 사용하여 Logstash을 실행합니다.

Logstash 설정 파일 위치 확인

Logstash의 설정 파일은 설치된 디렉토리에 위치한다. 로컬에 설치했으므로,

/usr/local/Cellar/logstash-full/7.17.4/libexec/config 이 경로에 conf파일을 생성해준다.

Logstash 설정 파일 작성

[Spring][258] Elasticsearch 검색 성능 개선 05 MySQL→Logstash-Elasticsearch 연결 설정, Heap Space 부족 트러블 슈팅

ELK Stack이란?

우선 ELK Stack이 무엇인지부터 정리하려합니다.

ELK는 위 그림과 같이, 데이터 인덱싱 및 저장 기능을 담당하는 ElasticSearch, 데이터 수집 기능을 하는 Logstash, 이를 분석 및 시각화하는 도구인 Kibana의 앞글자만 딴 단어입니다.

Logstash

•

오픈소스 서버측 데이터 처리 파이프라인으로, 다양한 소스에서 동시에 데이터를 수집하고 변환하여 stash 보관소로 보낸다.

•

수집할 로그를 선정해서, 지정된 대상 서버(ElasticSearch)에 인덱싱하여 전송하는 역할을 담당하는 소프트웨어

ElasticSearch

•

ElasticSearch는 Lucene 기반으로 개발한 분산 검색엔진으로, Logstash를 통해 수신된 데이터를 저장소에 저장하는 역할을 담당

•

데이터를 중심부에 저장하여 예상되는 항목을 검색하고 예상치 못한 항목을 밝혀낼 수 있다.

•

정형, 비정형, 위치정보, 메트릭 등 원하는 방법으로 다양한 유형의 검색을 수행하고 결합할 수 있다.

Kibana

•

데이터를 시각적으로 탐색하고 실시간으로 분석 할 수 있다.

•

시각화를 담당하는 HTML + Javascript 엔진이라고 보면 된다.

(추가)Beats

[Spring][258] Elasticsearch 설치 이후, Logstash와 Kibana 설치 ELK Stack 환경 구축

문제 상황

•

CodeDeploy를 사용하여 소프트웨어 배포 중에 예상치 못한 문제가 발생했습니다.

•

문제의 원인은 appspec.yml 파일의 ApplicationStart 섹션에서 확인되었습니다.

문제 원인 파악

•

ApplicationStart 섹션에서 호출된 sh 파일이 정상적으로 생성되지 않았기 때문에 문제가 발생 하였습니다.
이로 인해 배포 프로세스가 실패하였습니다.

해결 방법

appspec.yml 파일을 수정하여 sh 파일이 올바르게 생성되고 호출될 수 있도록 했습니다.

[Spring][258] 트러블 슈팅 : CodeDeploy 배포 중 발생한 sh 파일 생성 오류 해결 사례

Elasticsearch는 무엇인지?

•

Elasticsearch는 검색 및 분석을 위한 오픈 소스 분산 검색 엔진입니다.

•

JSON 형식의 문서를 저장하고, 강력한 검색 및 분석 기능을 제공합니다.

•

분산 환경에서 운영되며, 대용량 데이터를 효율적으로 색인화하고 검색할 수 있습니다.

Elasticsearch를 이해 하기 위한 주요 키워드

•

노드 : 노드는 간단하게 말하면 Elasticsearch가 설치된 각 서버를 의미합니다. 

•

클러스터 : 클러스트는 간단하게 말하면 여러 노드의 집합체라고 볼 수 있습니다. 이들이 함께 작동해서 데이터를 효율적으로 관리하고 검색할 수 있는 환경이 제공됩니다.

•

샤드 : 샤드는 간단히 데이터의 조각이라고 생각하면 됍니다. Elasticsearch는 대용량의 데이터를 처리할 수 있도록 데이터를 여러 파티션으로 나눠서 저장하는데, 이 작은 조각을 샤드라고 부릅니다.

엘라스틱 서치를 왜 이 프로젝트에서 적용하려 하는지?

•

프로젝트에서 Elasticsearch를 도입하는 주된 이유는 검색성능의 개선입니다.

•

MySQL로부터 가져온 도서 데이터를 Elasticsearch에 적재하면, 특히 텍스트 기반의 검색과 분석이 필요한 경우에 강력한 선택지가 될 수 있습니다. 

•

Elasticsearch는 분산 구조로 설계되어 있어, 대용량 데이터셋에 대한 높은 성능을 제공합니다.

기존 MySQL과의 차이점?

[Spring][258] Elasticsearch란?

문제 상황

웹 서비스 구성

카프카 서버를 사용하는 서비스에서 메인 서버와 트래픽 서버가 각각 2개씩 존재합니다. 메인 서버에서는 프로듀서를 통해 메시지를 보내고, 트래픽 서버에서는 컨슈머를 사용해 메시지를 받아 비즈니스 로직을 처리한 후 다시 프로듀서로 결과를 보냅니다. 메인 서버에서는 비동기 처리로 결과를 받아 클라이언트에게 뷰를 반환합니다.

서버와 토픽의 파티션을 확장한 후에 메시지 처리에 문제가 발생했습니다. 메인 서버1에서 트래픽 서버1로 데이터를 보냈을 때, 결과를 메인 서버1 쪽으로 전달하지 못하는 문제를 파악했습니다.

문제 원인

모든 메인 서버와 트래픽 서버의 컨슈머가 같은 컨슈머 그룹에 속해 있었기 때문에, 파티션 할당이 제대로 이루어지지 않았습니다. 카프카는 컨슈머 그룹 내에서 라운드 로빈 방식으로 파티션을 할당하는데, 이 때 메시지의 키와 파티션 할당 로직이 올바르게 설정되지 않아 잘못된 컨슈머에게 메시지가 전달되는 문제가 발생했습니다.

해결

각 메인 서버의 컨슈머가 서로 다른 컨슈머 그룹에 속하도록 설정을 변경했습니다. 메인 서버1의 컨슈머는 "main-server-apply-consumer-group"에, 메인 서버2의 컨슈머는 "main-server-apply-consumer-group2"에 속하도록 설정을 변경함으로써 각 서버의 컨슈머가 올바른 파티션에 할당되어 메시지를 정확히 처리할 수 있게 되었습니다. 또한 메시지 키와 파티션 할당 로직을 검토하여 올바르게 설정함으로써 앞으로 이러한 문제가 재발하지 않도록 예방했습니다.

[Spring][258] 트러블 슈팅 : 카프카 컨슈머 그룹 설정 오류로 인한 메시지 처리 문제

Elasticsearch를 활용한 성능개선을 위해서 진행해 볼 순서를 정리해보았다.

Elasticsearch 설치

도서 데이터를 Elasticsearch에 넣고 JMeter로 테스트해보기

MySQL과 Elasticsearch의 성능 차이점 비교하기

Beats 를 추가해보고 JMeter로 테스트해보기

이전과 차이점 비교하기

Logstash 추가해보고 JMeter로 테스트해보기

이전과 차이점 비교하기

Kibana 추가해보기

JMeter 결과와 Kibana 대쉬보드의 차이점, Kibana가 제공해주는 것들 정리해보기

10.

위 ELKB 스택을 로컬이 아닌 Docker에 구현해보기

11.

환경 구성 방법의 차이를 확인해보기

[Spring][258] Elasticsearch 검색 성능 개선 02 - Elasticsearch 활용해보기 순서 정리

Apache Kafka는 대용량의 실시간 데이터 스트림 처리를 위한 분산 메시징 시스템입니다. Kafka를 통해 서버 간 비동기 통신을 구현하고, 대량의 데이터를 빠르고 안정적으로 처리할 수 있습니다.

Kafka 메시지 처리의 기본 흐름

메시지 생성 및 전송
프로듀서는 메시지를 생성하고 이를 Kafka 토픽의 특정 파티션에 전송합니다.
메시지는 correlationId 같은 식별 정보를 포함하고 있어, 나중에 처리 결과를 정확히 매칭할 수 있습니다.

메시지 저장
Kafka 서버는 받은 메시지를 파티션에 저장합니다.

메시지 소비
컨슈머는 컨슈머 그룹 ID를 설정하여 Kafka 서버에 연결하고 메시지를 소비합니다.
Kafka는 이 ID를 기반으로 각 컨슈머에게 파티션을 할당합니다.

비즈니스 로직 처리
컨슈머는 받은 메시지를 바탕으로 필요한 비즈니스 로직을 처리합니다.

결과 전송
처리 결과는 새로운 메시지로 생성되어 결과 토픽에 전송됩니다.
이 메시지에는 원래 메시지와 동일한 correlationId가 포함됩니다.

결과 소비 및 처리
결과를 처리하는 컨슈머는 결과 토픽에서 메시지를 소비하고, correlationId를 확인하여 관련된 결과만을 처리합니다.

[Spring][258] Kafka에서의 효율적인 메시지 처리: 컨슈머 그룹 ID의 활용

Elasticsearch 로컬 Homebrew를 통한 설치 명령어

Elasticsearch를 사용해보기 위해 로컬 환경에 설치부터 진행합니다. MacOS도 윈도우와 마찬가지로 간단히 tar.gz를 다운로드를 받아서 설치해도 되지만 현재 로컬의 JDK부터 MySQL까지 Homebrew를 통한 CLI 환경에 설치해왔기 때문에 통일성있는 관리를 위하여 brew로 설치하고자 합니다.

Homebrew를 통한 설치 문제 발생과 문제해결

Homebrew를 통한 간편히 설치를 진행하고자 했으나,

Error: elastic/tap/elasticsearch-full: Calling plist_options is disabled! Use service.require_root instead. 라는 오류가 발생했으며, Elasticsearch를 받아오지 못하는 상황이 계속되었습니다.

구글링을 통해서 이와 같은 문제를 겪고 있는 많은 사용자들이 있었고 동일한 오류 코드가 나타나고 있었습니다. Github 커뮤니티에 Issue의 동일 문제 관련된 게시글을 살펴보던 중, 일부 유저가 Elasticsearch 패키지 설치 정보 파일인 elasticsearch-full.rb 파일 내부의 코드를 수정하여 성공한 것을 찾을 수 있었습니다.

패키지 설치 정보 파일 elasticsearch-full.rb 가 위치하고있는 경로 /usr/local/Homebrew/Library/Taps/elastic/homebrew-tap/Formula/elasticsearch-full.rb 를 이동하여 지목하고 있는 라벨 부분을 수정했습니다. 추후 다른 기술스택의 설치 시 동일한 문제가 발생하면 .rb 루비 패키지 정보 파일에서 해당 부분을 유사하게 수정해야 할 수도 있습니다.

[Spring][258] Elasticsearch 사용을 위한 로컬 환경 구축 기본

문제 상황

웹서비스를 그룹 ID를 다르게 설정하여 각 서버에 배포하려 하던 도중에 문제가 발생 하였습니다.

위 처럼 환경변수로 GROUP_ID를 설정하였지만 여전히 Ec2의 서버에서는 여전히 문제가 발생하엿습니다.

해결 과정

GitHub Actions에서 SPRING_APPLICATION_JSON 환경변수를 사용하여 설정하려 했으나, CodeDeploy를 통한 배포 과정에서 올바르게 적용되지 않고 여전히 문제가 발생 하였습니다. 약간의 고민 끝에 서버의 환경변수 쪽에 설정을 하면 어떨까? 이런 생각이 들었고 실제 진행하여 보았습니다.

테스트

[Spring][258] 트러블 슈팅 : AWS CodeDeploy를 이용한 웹서비스 배포 중 환경 변수 문제

Elasticsearch 로컬 Homebrew를 통한 설치 명령어

Homebrew를 통한 설치 문제 발생과 문제해결

Homebrew를 통한 간편히 설치를 진행하고자 했으나,

[Spring][258] Elasticsearch 검색 성능 개선 03 - Elasticsearch 설치와 테스트 실행 및 설치과정 사소한 트러블슈팅

Elasticsearch는 무엇인지?

•

Elasticsearch는 검색 및 분석을 위한 오픈 소스 분산 검색 엔진입니다.

•

JSON 형식의 문서를 저장하고, 강력한 검색 및 분석 기능을 제공합니다.

•

분산 환경에서 운영되며, 대용량 데이터를 효율적으로 색인화하고 검색할 수 있습니다.

Elasticsearch를 이해 하기 위한 주요 키워드

•

노드 : 노드는 간단하게 말하면 Elasticsearch가 설치된 각 서버를 의미합니다. 

•

클러스터 : 클러스트는 간단하게 말하면 여러 노드의 집합체라고 볼 수 있습니다. 이들이 함께 작동해서 데이터를 효율적으로 관리하고 검색할 수 있는 환경이 제공됩니다.

•

샤드 : 샤드는 간단히 데이터의 조각이라고 생각하면 됍니다. Elasticsearch는 대용량의 데이터를 처리할 수 있도록 데이터를 여러 파티션으로 나눠서 저장하는데, 이 작은 조각을 샤드라고 부릅니다.

왜 이 프로젝트에서 적용하려 하는지?

•

프로젝트에서 Elasticsearch를 도입하는 주된 이유는 검색성능의 개선입니다.

•

MySQL로부터 가져온 도서 데이터를 Elasticsearch에 적재하면, 특히 텍스트 기반의 검색과 분석이 필요한 경우에 강력한 선택지가 될 수 있습니다.

•

Elasticsearch는 분산 구조로 설계되어 있어, 대용량 데이터셋에 대한 높은 성능을 제공합니다.

기존 MySQL과의 차이점?

[Spring][258] Elasticsearch 검색 성능 개선 01 - Elasticsearch란?

시작 전에 점검

토픽 점검

main Server 카프카 정상 할당 점검

traffic Server 카프카 정상 할당 점검

웹 서비스 정상 동작 확인

카프카 서버 정상 동작 확인

메인 및 트래픽 서버 각각 2대로 증가시켜서 동작

1. 각 토픽에 대한 파티션을 2개씩 설정 및 확인

2. 각 서버 파티션 할당 확인

[Spring][258] CI/CD AWS Ec2 서버 다중 배포

1. 개요

기부된 책을 신청하는 과정에서 N+1 문제가 발생하였다.

N+1이 발생하지 않도록 코드를 수정하고 Jmeter로 성능테스트를 하여 결과를 비교하고자 한다.

2. N+1 발생 상황

기부된 책을 신청하는 로직은 아래와 같다.

책 신청 요청을 보내면 아래와 같이 N+1 문제가 발생한다.

3. 해결

코드를 아래와 같이 수정하여 fetch join시켜 문제를 해결하였다.

User와 BookDonationEvent를 fetch join시켜서 가져오도록 변경하였음.

변경후 책 신청 요청을 보내면 아래와 같이 N+1 문제가 발생하지 않는 모습이다.

[Spring][258] BookApplyDonation에서의 N+1 문제 해결 및 성능 테스트

문제 상황

SSH를 통해 AWS EC2 인스턴스에 연결을 시도할 때, team258serverkey.pem 파일의 권한이 너무 개방적으로 설정되어 있어서 연결이 거부되는 문제가 발생하였습니다.

문제 해결 과정

환경

•

운영 체제: Windows

•

명령 프롬프트: cmd

•

사용자: F 드라이브의 hanghae 폴더 내 FinalProjects 폴더의 awsKey 폴더에 위치한 team258serverkey.pem 파일을 사용하여 SSH 연결 시도

명령 프롬프트(cmd)를 엽니다.

문제가 발생한 디렉토리로 이동합니다.

[Spring][258] 트러블 슈팅 : SSH 키 파일 권한 문제로 인한 연결 실패

문제 상황

카프카 컨슈머가 대상 토픽에 대한 파티션을 할당 받지 못하여 정상 동작하지 못하는 문제가 발생했습니다.

문제 원인 분석

컨슈머가 있는 서버에서 카프카 서버 초기화 완료 전에 파티션 할당을 요청하였기에 컨슈머가 파티션 할당을 받지 못한 것으로 추정된다.

해결

카프카 서버가 완전히 부팅된 이후 해당 컨슈머가 있는 서버를 재부팅 하였더니 정상적으로 파티션이 할당되는 것을 확인 가능하다.

[Spring][258] 트러블 슈팅 : 컨슈머 서버가 카프카 서버 토픽의 파티션을 할당 받지 못하는 문제

초기에 Kafka를 도입할 때 Kafka의 구조와 특성으로 동시성 문제를 자연스럽게 해결할 수 있을 것이라 기대하였습니다.

Kafka는 메시지를 파티션 단위로 관리하며, 각 파티션은 순서를 가진 로그로 구성되어 있습니다. 따라서 단일 파티션에 대해서는 프로듀서와 컨슈머 간의 동시성 문제가 크게 발생하지 않습니다

그러나 Kafka 환경이 확장되면서 여러 파티션이 생성되고, 각각의 파티션에 대해 병렬 처리가 필요해지기 시작하면서 동시성 문제가 구조적으로 해결되지 않는다는 것을 알게 되었습니다. 각각의 파티션에 대해 독립적으로 메시지를 처리하지만, 전체 시스템의 관점에서 보면 동시에 여러 작업이 이루어지기 때문에 동시성 문제가 발생할 수 있기 때문입니다

이러한 문제를 해결하기 위해 방법을 찾던 도중 분산 락이라는 것을 알게 되었습니다. redis나 ZooKeeper와 같은 분산 락 서비스를 사용하여 리소스에 대한 접근을 제어함으로써 동시성 문제를 해결할 수 있을 것으로 추정됩니다.

여러 컨슈머가 동일한 리소스에 접근해야 하는 상황에서 ZooKeeper를 사용하여 분산 락을 구현함으로써, 한 번에 하나의 컨슈머만이 리소스에 접근할 수 있도록 제어하는 방향으로 말입니다.

결론적으로 Kafka를 통한 분산 처리와 함께 분산 락을 적절히 사용함으로써, 데이터베이스 락에서 발생할 수 있는 데드락의 위험을 줄이면서 동시성 문제를 해결하는 방향으로 진행할려구 합니다.

[Spring][258] Kafka를 활용한 분산 처리 환경에서의 동시성 문제 해결을 위한 고찰

1. 개요

팀 프로젝트를 진행하며 동시성 문제를 해결하기 위해 다양한 방법들을 사용해 보았으며

이 방법들을 모두 포함한 프로젝트를 AWS를 이용한 서버에 올려서 구동하였다.

서버에서 동시성 부하 테스트를 진행하며 성능을 측정해보았다.

2. 테스트 환경

[Spring][258] 동시성 해결 기법들 Jmeter 부하 성능 테스트

[Spring][258] 뷰페이지 접속시 user쿼리 추가로 2번 발생하는 문제 해결

[Spring][258] 트러블 슈팅 : Kafka 리스너(컨슈머)가 Kafka 서버에서 데이터를 읽지 못하는 문제 발생 및 해결

[Spring][258] 무한스크롤(Infinity Scroll) 기능 구현

[Spring][258] Pagenation→Slice→LoadMore→InfinityScroll 변화로 보는 성능 및 사용자경험의 선택과정

[Spring][258] EC2 Kafka 서버 적용 ( 테스트 환경 : 로컬 )

[Spring][258] bookData 가공 및 bookCategory MySQL 삽입

[Spring][258] 더보기(No Offset) 기능 구현

[Spring][258] Page와 Slice를 통한 데이터 호출 제어

[Spring][258] Kafka 적용한 서버 구조 변경

[Spring][258] 프로젝트에 Kafka 서비스 적용

[Spring][258] Kafka Consumer Group 설정에 대한 고찰

[Spring][258] 트러블 슈팅 : Jackson 라이브러리와 LocalDateTime 타입 처리 문제 해결

[Spring][258] Kafka를 활용한 실시간 데이터 처리: 시스템 구조 및 개선 방향 고찰

[Spring][258] 트러블 슈팅 : Spring Kafka를 사용하여 메시지를 송수신하는 과정에서 org.springframework.kafka.KafkaException: Seek to current after exception 오류가 발생

[Spring][258] 카프카 적용의 적정선: 효율적인 시스템 구조 설계를 위한 고찰

[Spring][258] 트러블 슈팅 : Kafka Consumer 서비스가 `bookDonationEventApplyOutput` 토픽으로부터 메시지를 받아 처리하는 도중 `List<UserResponseDto>` 타입으로의 변환 과정에서 `ListenerExecutionFailedException` 오류가 발생

[Spring][258][3주차 멘토링] 질문내용 정리와 답변

[Spring][258] 트러블슈팅 : 프로듀서에서 메시지를 전송하는 과정에서 역직렬화 문제 발생

[Spring][258] Kafka를 활용한 실시간 데이터 처리: 시스템 구조 및 개선 방향 고찰

[Spring][258] 카프카 기초 구현

[Spring][258] 카프카를 통한 동시성 문제 해결 고민

[Spring][258] JPA → JPQL → QueryDSL 변화과정

[Spring][258] 프로젝트 성능 개선 : 대용량 데이터 처리를 위한 페이징에서 슬라이스로의 전환

[Spring][258] Spring 뮤텍스를 활용한 동시성 문제 해결

[Spring][258] 검색관련 문제해결 및 성능 개선 방안 수집

[Spring][258] 동시성 문제 해결 및 성능 개선 방안 수집

[Spring][258] 프로젝트 성능 개선 : 대용량 데이터 처리를 위한 페이징에서 슬라이스로의 전환

[Spring][258] Spring 세마포어를 통한 동시성 오류 해결

[Spring][258] 트러블 슈팅 : Spring Boot 테스트: @RequestParam의 기본값과 Mockito any() 메서드 사용 시 주의점

[Spring][258] 트러블 슈팅: `BookServiceTest`에서 `NullPointerException` 발생 문제

[Spring][258] [2주차 멘토링] 질문내용 정리와 답변

[Spring][258] 트러블 슈팅 : JPA 페이징 처리

[Spring][258] 트러블 슈팅 : 디버거에서의 지연 로딩(Lazy Loading) 트랩

[Spring][258] 트러블 슈팅 : Spring JPA에서 페이징 쿼리 오류 해결

Project [TEAM258]

1. 검색API Template

2. 검색 파라메터

1. 검색 기능 업그레이드

2. 프론트엔드 네비게이션 변경

프로젝트 기획 배경 설명 (30초)

시연 영상 재생 (1분)

아키텍처 설명 및 기술 도입 배경 (2분)

작업 진행 전

작업 결과

작업 코드

1차 Code 정리 [ resource ( JS, CSS, Templates ) ]

2차 정리 [ Security Filter 및 domain 일부 불필요 컨트롤러 ]

3차 정리 [ 불필요 서비스 및 레파지스터리 정리 ]

마이크로 서비스 아키텍처의 필요성

기존 서버의 모놀리식 아키텍처 흐름도

카프카란?

카프카의 기본 개념과 주요 특징

레디스 분산 락이란?

레디스 분산 락의 필요성

레디스 분산 락의 작동 원리 ( Redisson )

Kafka를 시도하는 이유

KafKa의 동작 흐름

1. 책 대출 신청

2. 책 나눔 신청

동시성 제어란?

웹 서비스에서의 동시성 문제란?

동시성 제어가 필요한 이유

1. 개요

2. 동시성 해결 성능 테스트

지속적인 통합(CI)과 지속적인 배포(CD) 란?

지속적인 통합 (CI)

지속적인 배포 (CD)

책 나눔 서비스

마이크로 서비스 아키텍처란?

마이크로서비스 아키텍처의 주요 특징

프로젝트 내의 마이크로서비스 아키텍처 적용의 필요성

1. 접속 환경 설정

2. 3 Layered 아키텍처와 Elasticsearch 연결

문제 원인

문제 해결

키 파일의 속성 변경

고급 보안 설정 접근

Redis 분산락 구현 ( AWS Server )

설치 환경

Redis EC2에 설치

Redis 설정 파일 변경

메인 서버 스캐일 업

이벤트 적용 서버 스캐일 업

Redis 서버 스캐일 업

1. 문제

2. 원인

3. 해결

1. 문제

2. 원인

3. 해결

1. 비관적 락 사용

이번주 동안 카프카를 진행한 내용

초기

Kafka를 시도하는 이유

문제 상황

문제 원인 파악

해결 방법

문제 상황

웹 서비스 구성

문제 원인

해결

Kafka 메시지 처리의 기본 흐름

문제 상황

해결 과정

테스트

시작 전에 점검

토픽 점검

main Server 카프카 정상 할당 점검

traffic Server 카프카 정상 할당 점검

웹 서비스 정상 동작 확인

카프카 서버 정상 동작 확인

메인 및 트래픽 서버 각각 2대로 증가시켜서 동작

1. 각 토픽에 대한 파티션을 2개씩 설정 및 확인

2. 각 서버 파티션 할당 확인