BackEnd/쿠링14 [쿠링] 헥사고날 아키텍처를 향하여 (By TDD) 이번 글을 통하여 기존의 쿠링의 계층형 아키택처를 Hexagonal Architecture로 리팩토링 해 나가려 한다. 그럼 기존에 어떠한 점이 불편했기에 이러한 선택을 하게 되었을까? 기존의 문제점부터 한번 살펴보자. 1. 기존 아키텍처의 문제점 1-1) 데이터 중심의 설계? 우선 가장 첫 문제점은 우리의 앱이 어느순간부터 데이터베이스 중심적으로 설계가 진행되고 있었다는 점이다. 사용자를 위한 애플리케이션이라면, 해당 문제를 해결할 도메인 로직이 중요한데... 정작 이점은 고려하지 못하고 구현된 아키텍처였다. 다음 글은 내가 이에 대하여 좀더 설명해 둔 글이기에, 자세한 설명은 다음 글을 읽어봐 주시길! https://blogshine.tistory.com/688 계층형 아키텍처는 왜 데이터베이스 중심.. BackEnd/쿠링 2024. 2. 2. [쿠링] Pattern 하나로 서버 OOM발생시켜 다운시키기 (Heap Dump 보기) 1. 처음엔 문제인 줄 몰랐다... 현 쿠링은 엄청 비싼 인스턴스를 사용하지는 않고 있기 때문에 인스턴스 한대당 Memory가 512MB에 불과한 서버를 사용 중이다. (대신 값싼 거 3대로 운영 중) 심지어 메인서버는 Heroku이고, 테스트서버와 모니터링 서버는 AWS에서 기동중이다. (메인 서버 이전이 쉽지가 않다...) 평상시에는 크게 문제처럼 느껴지지 않던 부분이 시간적 여유를 갖고 보니 조금은 어색하게 느껴진 부분이 있었다. 우선 다음 모니터링 기록을 살펴보자 ▶ Heap : G1 Eden Space ▶ Heap : G1 Survivor Space G1 Eden 영역에 수시로 생성되고 있는 양이 어림잡아 170MB, 그중 Survivor로 살아남는 녀석들은 MAX 7MB. 그럼 163MB나 매.. BackEnd/쿠링 2024. 1. 18. [쿠링] Spring JDBC를 사용한 Batch Insert 구현과 고민 예전부터 시간 나면 해결하고 싶었던 문제 중 하나인 Batch(Bulk) insert에 대한 구현을 하며 이번글을 남기게 되었다. 기존에 주로 사용해 왔던 JPA의 한계로 인하여 이러한 결정을 하게 되었는데, 어떤 문제점과 고민이 있었는지 이번 글을 통하여 공유해 볼까? 한다. 고민 1 : JPA가 무엇인가? 이것부터 생각해 보기 기존에 내가 사용하던 ORM 기술인 JPA는 ORM의 대표 기술이다. 그럼 ORM은 어떤 철학을 갖고 설계된 것일까? 이를 wiki에서 검색해 보았다! ORM (Object–relational mapping) Object–relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programmin.. BackEnd/쿠링 2024. 1. 14. [쿠링] 사용자 인증의 시작부터 끝까지의 여정 항상 프로젝트를 진행할 때마다 한 번씩은 고민해 왔던 문제가 있다. 바로 "인증, 인가 가 과연 해당 서비스의 핵심 비즈니스 로직인가?"에 대한 고민이다. 경험이 부족했던 시점에야 당연히 이러한 생각조차 하지 못하여 논의할 내용조차 없었다 경험이 조금 있는 시점에서는 일단은 API수준에서 구현은 가능하지만 이를 어떤 방식으로 분리해야 할지 몰랐다. 이번 글에서는 이러한 나의 고민을 스스로 적어보고, 해결해나가는 과정을 기술할 것이다! (즉, 지극히 개인적인 내용.... 태클 환영) 고민 1 : Core Business란 무엇인가? 경계가 있는가? 가장 우선적으로 고민했던 부분은 Core Business라는 것 이 뚜렷한 경계가 있는 것 인가였다? 이에 대한 확인을 위해 위대하신 GPT에게 질문을 던져보았.. BackEnd/쿠링 2023. 10. 7. [쿠링] 효율적인 Log 관리를 위한 여정 - 1 1. 문제가 되는 상황 여유가 생겼을 때 쿠링이 Log를 남기고 있는 과정에 대하여 한번 고민해보고 싶었다. 오늘 글은 크게 3가지에 대한 고민으로부터 시작되었다. 1) Log의 level이 적합한가? (이번 글에서 해결할 내용) 2) Log 파일의 사이즈가 너무 커지지 않도록 나뉘어 저장되고 있는가? (이번 글 에서 해결할 내용) 3) Log의 모니터링이 편리하게 되고 있는가? (추가 글에서 다룰 예정) 일단 2가지에 대하여 답해보면, 현 쿠링은 "아니요"라고 답할 수 있을 거 같다. 크게 기준없이 설정된 log들의 level, 더 나아가 log를 보기 위해서는 직접 EC2에 접근하여 로그 파일을 살펴봐야 했다... 또한 로그가 중요하다는 생각에 무분별하게 남기는 것이 과연 좋은가? 나는 습관적으로 예.. BackEnd/쿠링 2023. 8. 27. [쿠링] 테스트 서버의 간헐적 다운 현상 (feat, Prometheus & Grafana) 1. 문제가 되는 상황 테스트 서버가 새벽에 지속적으로 다운되는 현상이 발생하고 있다.... 로그만으로는 정확한 원인을 파악하기 힘들어... prometheus와 grafana를 통해 메트릭을 정확하게 측정하게 되었다. 총 3부분을 살펴보았다. 1) CPU 사용량 2) JVM 메모리 사용량 초과 3) 커넥션 풀 고갈 4) vmstat 확인 2. 모니터링 2 - 1) CPU 사용량? 우선 다음 지표를 살펴보자 정기적으로 새벽 2기에 작동하는 작업이 있기 때문에 0시 ~ 4시 의 지점을 살펴보게 되었다. 다행히 터진시각 또한 대략 3시 15분경인데, 그래프에 보이듯 System CPU 사용량이 정상대비 급증하다 다운된 것 같다. 평균값이 0.00939인 상황에서 CPU 사용량이 0.0682 까지, 약 7배가.. BackEnd/쿠링 2023. 7. 17. [쿠링] 홍보 부스 후기 (feat 건국대 일감호 축제) 건국대 일감호 축제에서 2일간 "쿠링 홍보 부스"를 운영하면서 경험한 내용을 기록해볼까 한다! 1. 부스 신청부터 ~ 준비까지 1.1) 일단 신청부터 사실 신청 당일까지만 하더라도 내가 부스 대표자가 될 거라는 생각은 1도 하지 못하고 있었다.... 하지만 눈떠보니 부스 대표자가 되어 있었다랄까? 하지만 대표자가 된 이상, 성공적으로 끝까지 부스를 완주시키고 싶었다! 일단 부스 이름은 "쿠리의 공지 단속"으로 정하게 되었다. 요즘 인기있는 영화 제목을 이용한 "우영" 님의 아이디어 였는데, 가장 마음에 드는 이름이라 좋았다! iOS개발자 이시지만, 디자인까지 함께 해주신 "재성"님께 감사의 인사를 다시 한번 전한다! 1.2) 팀원들과 거침 없는 회의 팀원 대부분이 직장인이기 때문에, 회의 시간 동안 많은.. BackEnd/쿠링 2023. 5. 20. [쿠링] 검색 쿼리에 Full Text Index 적용하기 해당 글은 개인 프로젝트를 개선해 나가면서 내용을 정리하는 글입니다. 1. 문제 되는 상황 현 쿠링은 검색어를 입력받으면 like절을 사용하여 원하는 text를 필터링하고 있다. SELECT * FROM notice WHERE notice.contents LIKE '%장학금%' explain을 통해 실핼계획을 보면 다음과 같다. 예상했듯.... full scan을 하고 있다... 그래도 스토리지 엔진에서 데이터를 불러온 후, 100% filtering 하고있는걸 보면 조건절이 스토리지 엔진에 전달되어 필요한 데이터만 가져왔음을 알 수 있다. 이러한 방식은 검색한 text의 내용이 많아지면 어마어마하게 성능이 저하된다. 몇년치 데이터에서 like로 검색을 한다 생각하면.... 과부하가 발생하고, respo.. BackEnd/쿠링 2023. 5. 11. [쿠링] Multi thread를 활용한 공지 조회속도 개선 (feat 동기화) 해당 글은 개인 프로젝트를 개선해 나가면서 내용을 정리하는 글입니다. 1. 도입 배경 쿠링에서는 학교의 전체 공지를 주기적으로 scrap해와야 한다. 하지만 이를 동기 처리 하다 보니 특정 학과의 scrap 속도가 늦어지면, 자연스럽게 전체 작업 속도가 늦어지는 문제가 발생하였다. 문제는 학교의 API를 사용하는 방식이 아니라, 직접 scrap을 통해 정보를 긁어오는 형식이기 때문에 주기적으로 신규 공지를 확인해줘야 하는데, 단일 코어상의 싱글 스레드로 처리하기에는 작업이 너무나 오래 걸렸다. 내가 생각한 공지 확인 간격보다, 한번 업데이트하는 시간이 더 길어지는 문제가 발생한 것이다! 나는 이를 해결하기 위해 Multi Thread를 도입한 비동기 처리를 해야겠다 생각하게 되었다! 2. 사전에 예상되는.. BackEnd/쿠링 2023. 4. 28. [쿠링] SonarCloud와 CI 도입 해당 글은 개인 프로젝트를 개선해 나가면서 내용을 정리하는 글입니다. 1. 도입 배경 기존의 쿠링의 배포 과정에서 CI 과정이 없다는 점이 아쉬웠다. 따라서 이번에는 SonarCloud를 통한 정적분석과 코드 커버리지 측정을 위한 CI과정을 추가해야겠다는 생각이 들었다! SonarCloud공식문서를 보면서 하나하나 해결해봅시다~ https://docs.sonarcloud.io/advanced-setup/ci-based-analysis/github-actions-for-sonarcloud/ GitHub Actions To configure analysis of your project using GitHub Actions you should follow the in-product tutorial. docs... BackEnd/쿠링 2023. 4. 21. [쿠링] 형상관리를 위한 Flyway 도입기 해당 글은 개인 프로젝트를 개선해 나가면서 내용을 정리하는 글입니다. 1. 도입 배경 이번 쿠링 전 학과별 공지 지원 과정에서 기존의 Notice 테이블이 아닌, DepartmentNotice가 추가적을 발생하게 되었다. 새로운 테이블을 기존의 Notice테이블에 Dtype으로 구분하기 시작하면서, 추가된 속성들이 있고, 새로운 값들이 추가되었다. 물론 나야 내가 변경했으니 해당 의미들 을 빠르게 파악 가능하지만, 과연 다른 이가 봐도 이를 빠르게 이해할 수 있을까? 란 의문이 들었다. 또한 서로 다른 환경(local, test, prod)간에 통일된 스키마를 가지기 위해서 많은 리소스가 사용된다. 그러한 과정 속에서 다음 3가지 목표가 생기게 되었다. 업데이트마다 운영 DDL과 개발 DDL을 하나하나 .. BackEnd/쿠링 2023. 3. 31. [쿠링] 중복코드를 Template Method Pattern으로 Refactoring 하기 해당 글은 개인 프로젝트를 개선해 나가면서 내용을 정리하는 글입니다. 1. 현 상황 (개선하기 전의 코드) 우선 다음 코드는 Notice를 Scarp 하는 코드입니다. 문제는 (scarp, scarpAll), (requestWithDeptInfo, requestAllPageWithDeptInfo) 간의 중복 코드가 너무나 많다는 점입니다. scarp : 최근 공지 조회 scarpAll : 모든 공지 조회 이렇게 2개의 메서드를 구분하다 보니 발생한 중복 코드였습니다. 템플릿 메서드 패턴, 함수형 인터페이스, 람다식을 통하여 중복을 제거할 생각입니다! 우선 개선하기 전의 코드는 다음과 같습니다! @Slf4j @Component @NoArgsConstructor public class DepartmentNo.. BackEnd/쿠링 2023. 3. 27. 이전 1 2 다음
