반응형 전체 글133 Loki, Promtail 활용 로그 모니터링 환경 구축 해당 포스트에서는 Loki와 Promtail을 활용하여 서버에서 발생하는 로그들을 모니터링 서버에 보내고, 이를 손쉽게 확인할 수 있도록 만들도록 해보겠습니다.해당 포스트는 아래의 2개의 포스트에 있는 내용인 Prometheus, Grafana를 활용한 모니터링 환경 구축, Logback을 활용한 서버 로그 관리에 이어서 작업하도록 하겠습니다.프로젝트명이 변경된 부분을 제외하고는 내용은 동일합니다. Prometheus, Grafana를 이용한 EC2 모니터링 환경 구축프로젝트를 진행하면서 이후 유저에게 서비스를 제공하는 상황을 대비하여 배포 서버에 대한 모니터링 환경 구축을 해보고자 합니다.데이터 수집 툴 선택우선 EC2를 모니터링하기 위한 방식을dy-coding.tistory.com Logback을 .. 2024. 12. 4. SpringBoot와 Clova Studio를 활용한 RAG 구현 이번에 진행하게 된 프로젝트에서 사용자에게 맞춤형 강좌/시설을 추천해 주는 기능을 구현하게 되었습니다.유저의 앱 사용 기록 등을 토대로 추천을 진행해도 되지만 이러한 방식을 선택하는 경우 앱 사용자가 아직 많은 활동을 하지 않은 경우 추천해 줄 콘텐츠의 정확도나 만족도가 낮을 수 있다는 판단을 하였고, 온보딩 단계에서 사용자의 흥미, 앱 사용 목적 등을 받아 이에 적합한 추천 서비스를 제공하자는 생각을 하여 아래와 같은 온보딩 정보를 회원가입시 받아 이를 추천에 활용하였습니다.온보딩 및 MongoDB에 MongoUser document 생성위와 같은 온보딩 과정이 끝나게 되면 MongoDB에 아래와 같이 MongoUser라는 해당 사용자의 온보딩 정보를 담고 있는 document가 생성됩니다.MongoD.. 2024. 12. 3. Offset을 사용하지 않는 무한 페이징 기능 구현 이번 게시글에서는 무한 페이징 기능을 구현하면서 나온 문제 상황을 해결해 보도록 하겠습니다.프로젝트를 진행하면서 페이징 기능을 구현하면서 페이징을 진행할 때 중복된 데이터가 나오는 상황이 발생하였습니다.해당 상황은 게시글에 달린 리뷰를 최신순으로 가져와 사용자에게 보여주는데 A 유저가 페이징을 진행하던 중 중간에 잠시 멈추고 B 유저가 새로운 리뷰를 달았을 때 A 유저가 다시 페이징을 진행하면 이전에 확인한 데이터가 다시 보여진다는 것이었습니다.이 상황이 발생하는 이유는 offset을 사용하여 paging을 진행하고 있었기 때문입니다. offset을 사용하면 문제가 발생하는 이유는 아래와 같습니다.위 사진에서는 page의 크기가 5라고 지정하였습니다. 이때 A 유저가 계속 페이징을 진행하는 상황에서 B .. 2024. 9. 30. 공간 좌표를 사용할 때 MySQL과 MongoDB의 성능 비교 스프링부트를 이용한 프로젝트를 진행하면서 공간 좌표를 다룰 수 있는 기회를 가질 수 있었습니다.요구 사항은 서울시에서 관리하는 여러 공공 쉼터들의 데이터를 DB에 저장해 놓고 사용자가 앱을 이용하면 해당 사용자의 근방 Nm에 있는 쉼터 정보를 모두 프론트로 넘겨주어야 하는 것이었습니다.해당 요구 사항을 만족시키기 위해서 구현한 내용 및 리팩토링 과정을 소개하도록 하겠습니다.MySQL st_distance_sphere 함수를 이용한 공간 좌표 활용저는 공간 좌표를 다루기 위해서 우선 저에게 제일 익숙한 DBMS인 MySQL을 사용하였습니다. 아래와 같은 도메인을 만들었고 경도, 위도를 따로 저장하여 활용하였습니다.package com.shwimping.be.place.domain;import com.shw.. 2024. 9. 23. AOP를 이용한 분산락(Named Lock) 처리 아래의 게시글에서 마지막 부분에 분산락을 처리하기 위하여 @Transactional에 propagation 속성을 REQUIRES_NEW로 설정했었습니다. synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용한 데드락 처리이번 게시글에서는 synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용하여 데드락을 처리해 보도록 하겠습니다.우선 제가 redis나 zookeeper 등을 사용하여 데드락을 처리하지 않은 이유는 새dy-coding.tistory.com하지만 위의 방식은 커넥션을 추가로 필요로 하고 이 때문에 많은 요청이 한 번에 오면 커넥션을 얻지 못하여 데드락이 발생하는 상황도 발생했습니다.위의 상황을 막기 위해서 커넥션 풀을 분리하면 .. 2024. 7. 28. synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용한 데드락 처리 이번 게시글에서는 synchnonized, 비관적 락, 낙관적 락, 분산락(named lock)을 사용하여 데드락을 처리해 보도록 하겠습니다.우선 제가 redis나 zookeeper 등을 사용하여 데드락을 처리하지 않은 이유는 새로 인프라를 추가하게 된다면 개발 환경, 배포 환경 등에 변화가 생기게 되어 이로 인한 side effect가 발생할 수 있기 때문입니다.제가 진행했던 프로젝트에서는 redis를 사용하지 않았기 때문에 redis를 이용하여 분산락을 처리하지 않고 mysql에서 제공하는 분산락(named lock)을 이용하도록 하겠습니다.데드락 발생 상황우선 데드락이 발생하는 상황에 대해서 먼저 설명해 드리도록 하겠습니다.요구 사항은 유저가 ImageQuiz 문제를 풀고 제출하면 서버에서 이를 채.. 2024. 7. 26. Prometheus, Grafana를 이용한 EC2 모니터링 환경 구축 프로젝트를 진행하면서 이후 유저에게 서비스를 제공하는 상황을 대비하여 배포 서버에 대한 모니터링 환경 구축을 해보고자 합니다.데이터 수집 툴 선택우선 EC2를 모니터링하기 위한 방식을 선택할 때 2가지의 선택지를 고민했었습니다.첫 번째 선택지는 InfluxDB였고, 두 번째는 Prometheus였습니다. 둘 다 TSDB(Time Series DataBase)로써 시계열 데이터를 다루는 데에 특화된 데이터베이스입니다.저는 이 두 TSDB 중에서 아래의 글들을 참고하여 Prometheus를 선택하였습니다.https://multicloud.tistory.com/m/84 Prometheus vs InfluxDB편향적인 내용으로 당연히 절대 평가는 되지 않습니다. 상황에 맞게 써야 하며, 특성을 참고하는데 도움은.. 2024. 7. 18. Logback을 이용한 EC2 환경 로그 관리 이번 게시글에서는 Logback을 활용하여 EC2 환경에서 로그 관리하는 방법에 대해서 다루도록 하겠습니다.프로젝트를 진행하면서 로컬에서 개발할 때는 바로 로그를 확인할 수 있지만 EC2에 프로젝트를 배포해 놓았을 때는 로그를 바로 확인하지 못하면 사라지는 문제가 있었습니다.오류가 발생해도 로그 관리를 하지 못하여 인지하지 못하거나 다시 확인하지 못하는 것은 심각한 문제라 생각하여 스프링에서 제공하는 기능은 Logback을 활용하여 로그 관리를 하기로 결정하였습니다.로그백 설정Logback은 build.gradle에서 아래와 같은 라이브러리를 등록하면 사용할 수 있습니다. 해당 라이브러리는 스프링 개발을 위해서 필수적이기 때문에 사실상 추가로 해주어야 하는 작업은 없다고 생각하시면 됩니다.implemen.. 2024. 7. 17. 이전 1 2 3 4 ··· 17 다음 반응형
