요즘 블로그에 올라오는 출석관리체계 서비스원래는 홈서버에 배포해서 운영하다가새해를 맞이해 클라우드로 옮겨야겠다는 생각이 들었다. 왜냐?작년에 아파트가 한번 점검으로 인해 정전된 적이 있었다.우리집의 네트워크 구조는 이런 구조로 구성되어 있다.포트포워딩을 통해 홈서버로 요청이 들어가 응답이 오는 구조였는데 정전 이후 DHCP로 홈서버의 IP가 변경되면서서버는 살아있지만 외부에서 접속할 수 없는 상황이 발생한것이다.. 하필 이 당시에 나는 제주도에 있었고,,네트워크 설정을 건드릴 수 없는 상황에 놓인것이다. 이 때 나중을 위해서라도 클라우드로 전환이 필요하다고 생각이 들었다. 그렇게 새해부터는 클라우드 비용을 지원받을 수 있게 되어서aws로의 전환을 시도했다. 1차 전환기일단 도메인은 가비아를 통해 구매했..
하도 자주 반복해서 기록용으로 남겨둔다.도메인은 구입해야한다. Client ↓ httpsnginx (host, 443) ↓ proxy_passSpring Boot (Docker, 8080) 전체적인 구조 1. 도메인 dns a 레코드 등록 확인dig api.domain.xyz해당 명령어를 통해 구입한 도메인에 a 레코드가 제대로 등록되었는지 확인한다.새로 구입한 도메인에 경우 운 없으면 1시간이상 걸린다.(내가 그랬다.)2. nginx 설치 ( 호스트)sudo apt update sudo apt install -y nginx상태 확인:sudo systemctl status nginx3. nginx 기본 프록시 설정sudo vi /etc/nginx/sites-enabled/default아마 기본 설정..
교회에서 중고등부 교사를 하면서 비효율적으로 출석 체크를 하는 현상을 확인했다...매주 학생 리스트에 엑셀로 1,0 을 입력하며 출석을 하고 있던 것이였다.. 그래서 간단하게 AI로 프론트 개발하고백엔드는 직접 개발하며 출석관리체계를 만들어 1년간 사용했다. 부끄러운 프론트그냥 간단하게 출석, 지각, 결석 여부를 체크하는 방식이다.뭐 숨겨진 여러 기능이 있긴하다만..2026년이 되면서 2.0으로 업그레이드 할 겸지금까지 쌓은 출석 데이터를 바탕으로 AI 에이전트를 만들어보고자 한다."이번 달 출석 위험 학생 알려줘”“지각이 잦은 순서로 10명 보여줘”“지난 학기 대비 출석 개선된 학생은?”“이번 달 한 번도 안 나온 아이들 알려줘”“3주 연속 결석한 학생 있어?”이런식의 자연어 질문을 AI가 해석하고 응..
요약 (Summary)'동네한끼' 프로젝트의 핵심 기능인 개인화 추천 API의 부하테스트를 진행하며 응답 속도가 평균 26초에 달하는 심각한 성능 저하를 확인했습니다. 이를 해결하기 위해 로직 수정, DB 커넥션 풀 조정, 쿼리 리팩토링, 인덱스 적용, JVM 튜닝의 4단계를 거쳤습니다.그 결과, RPS는 증가(30.19→ 42.4)하고, 응답 속도는 단축(1656ms → 1100ms)하는 성과를 얻었습니다.1. 배경 및 문제 상황 (Background & Problem)프로젝트 리팩토링 과정에서 메인 페이지의 '사용자 맞춤 추천 게시글 조회 API'를 점검하던 중, 예상보다 훨씬 심각한 성능 지연을 발견했습니다.해당 API는 로그인한 사용자의 활동(좋아요, 조회 등)을 분석해 관심사를 파악하고, 이에 ..
auditLog는 기록도 기록이지만 조회가 가장 중요한 API이다.조회 성능을 개선하기 위해 어떤 방식이 있을가 고민하던 중 인덱싱을 적용하기로 했다.인덱싱은 커서 기반 페이징에서 커서 키로 사용하는 CREATE INDEX idx_auditlog_loggedat_id ON audit_log (logged_at DESC, id DESC);logged_at , id 에 인덱싱을 걸었다. 인덱싱 적용 후 이전과 동일하게 마지막 페이지를 조회했더니2025-08-08 18:35:58.215 [https-jsse-nio-443-exec-9] INFO com.welcommu.moduleapi.aop.ExecutionTimeLogger - ⏱️ LogsWithCursor com.welcommu.moduleservi..
이전 게시글에서 AuditLog의 N + 1 문제를 해결하여 성능을 개선하였다.하지만 10,000건의 데이터는 너무 적다.여러 조언을 구해본결과 1000만건은 해야 유의미한 결과를 얻을 수 있다는 판단이 들었다.그렇게 해서 데이터 1000만건 삽입!audlitLog는 1000만건INSERT INTO vivim.audit_log (actor_id, target_type, target_id, action_type, logged_at)WITH RECURSIVE numbers AS (SELECT 1 AS n UNION ALL SELECT n + 1 FROM numbers WHERE n audlitLogDetail는 200만건 삽입하였다.INSERT INTO vivim.audit_lo..
