이전 글에서 Prometheus + Grafana를 이용하여 시스템 모니터링을 구성했었다.이번 글에선 Filebeat + Elastic Search + Log Stash + Kibana 를 이용하여 로그 모니터링을 구성한 과정을 작성한다. ELK Stack을 쓰는 이유는 ?로그 수집 / 분석문제가 생긴 원인을 파악하거나 사용자 행위 분석 등 텍스트 기반 검색이 필요할 때"왜" 죽었는지 알 수 있다.구성 요소역할Filebeat로그 파일을 읽어 Logstash로 전달Log Stash로그 수집 및 파싱 (필요 시 변환)Elastic Search로그 저장 및 검색Kibana로그 시각화 및 대시보드 현재 디렉터리 구조는 아래와 같다.msa-deploy/├── docker-compose.yml├── .env 파일들..

모니터링 기법에는 여러가지가 있지만 그 중에서 시스템 상태를 모니터링 하기에 적합한 기술 조합으로 Prometheus + Grafana 조합이 있다.이 모니터링 기법에는 다음과 같은 특징이 있다. 매트릭 수집 / 실시간 데이터 수집 역할시스템의 상태를 빠르게 파악하기에 적합하다. (CPU, 메모리, 응답 시간, 트래픽 변화 등)죽기전 징후를 알려준다.시스템 모니터링을 위하여 Prometheus + Grafana를 적용한 과정에 대하여 설명하겠다. 현재 진행 중인 프로젝트는 Docker를 이용하여 여러 컨테이너를 띄워서 배포하고 있었다.이 과정에서 편리하게 컨테이너를 관리하기 위해 docker-compose를 작성 해 놨었다. Prometheus와 Grafana의 컨테이너도 추가로 띄워야 하므로 docke..

MSA 기반 프로젝트 중 마이크로 서비스 간 통신 방식에 대하여 고민하게 되었다.알람 서비스에서는 Kafka를 이용하여 실시간 비동기 처리를 통해 빠르게 여러 마이크로 서비스에서 이벤트를 받는 식으로 구성했었다.그런데 현재 개발중인 쪽지 서비스에서 채팅방 목록을 출력할 때 상대방의 닉네임들을 같이 출력해야 하는데 이것을 어떻게 가져올지 고민했다.Kafka를 이용하여 가져오기엔 닉네임 하나 가져오자고 굳이 Kafka 설정 코드들을 작성해야 하나 생각이 들었다.물론 실시간성이 중요한 서비스라면 Kafka를 통해 통신하는게 필수라고 생각하지만 채팅방 닉네임 출력 같은 경우에는 한 번만 얻어오면 되고, 그렇게 실시간성을 요하는 기능이 아니라 생각되어서 REST API를 통해 요청을 보내기로 했다.마이크로 서비스..

프론트의 개발 상황을 실시간으로 보고 싶었는데 이를 위해선 서버에 배포할 필요가 있었다.이를 간단한 설정만으로 띄울 수 있는 Netlify라는 서비스를 이용하려한다.Git 브랜치의 커밋을 감지하고 최신 변경 내용으로 배포를 바로 진행해 준다.netlify에 접속 후 로그인을 한다.아래의 화면에서 Import from Git을 선택하고 저장소를 선택한다.아래와 같이 배포가 완료된다.사이트명도 직접 지정할 수 있다.아래와 같이 환경설정에서 수정해준다.처음에 dist/로 되어있지만 Vue.js가 사용하는 디렉토리고, react의 경우 build/ 디렉토리가 기본이다.react + vite 사용하는 경우 dist로 냅둘 것!설정을 마치면 서버 배포가 시작된다.정상 배포 완료 시

GitHub Actions보통 CI 용도로 많이 쓰임코드 변경 감지애플리케이션 빌드테스트 실행Docker 이미지 빌드Docker Hub에 Docker 이미지 푸쉬하지만 도커 컨테이너를 실행하고 배포하는 역할은 자동화 해주지 않기 때문에 이것을 처리 해 주는 Jenkins로 CD를 구성하면 좋음Docker 컨테이너 자동 실행 방법 (CD)Actions + SSH(원격 접속)Actions에서 서버로 SSH 접속 → docker run 명령어 실행해서 컨테이너 배포단점 : 서버에 직접 SSH 접속을 해야 하므로 보안 설정이 필요Actions + AWS ECS / GCP Cloud RunActions에서 ECS나 Cloud Run에 배포하면 컨테이너를 실행한다단점 : 설정이 많고, 인프라 관리가 복잡할 수 있다..

JWT와 세션의 차이점세션서버에서 인증 정보를 관리하는 방식세션 동작 방식사용자가 로그인하면 서버가 세션 ID 생성 후, 서버의 메모리에 세션 정보 저장로그인 후 생성된 세션 ID를 브라우저의 쿠키에 저장클라이언트는 서버에 요청을 보낼 때 세션 쿠키와 함께 전송서버는 요청시 같이 온 세션 ID를 통해 인증을 확인서버에서 해당 세션 ID 정보를 찾아 해당 정보 기반으로 요청을 처리세션 저장 방식저장 위치 특징 장점 단점서버 메모리(기본)HttpSession을 서버가 직접 관리속도가 빠름서버 부담 증가DB (MySQL, PostgreSQL 등)세션 정보를 데이터베이스에 저장서버 메모리 부담 없음, 유지 보수 용이속도가 느림Redis (인 메모리 DB)세션 정보를 Redis에 저장빠른 조회 속도, 다중 서버 ..

고려 사항API 호출이 많이 지면 비용 증가도 감수해야 함 (최적화 필요)간단한 처리가 가능한 부분은 자체 로직을 구현하여 비용 절감데이터 전체를 API에 보내지 않고 전처리 과정 포함속도가 중요한 작업 → 비동기 처리 고려GPT API 호출 같은 외부 API 사용에는 네트워크 지연이 발생할 가능성이 있기에 비동기 처리가 성능 최적화에 중요비용 (4o mini, 4o)100만 토큰 기준으로 작성1000토큰 = 약 750개의 영단어 = 약 한국어 1300~1500자(공백 포함)소설/일반 서적 기준 약 3,000 페이지라고 함입력4o mini : 200원4o : 3500원출력4o mini : 850원4o : 14500원한국어 입력 시 내부에서 영어로 변환 후 처리하지만, 변환 과정에서 발생하는 토큰은 비용에..

ws로 접속하면 실시간으로 양방향 통신 가능ws://localhost:8080/ws → 웹소켓 접속 엔드포인트여기서 뒤의 /ws 는 WebSocketConfig의 엔드포인트 설정에서 직접 설정한 값한 번 접속하면 클라이언트와 서버가 WebSocket을 통해 지속적으로 연결 유지되며 실시간으로 통신이 가능STOMP를 이용해 구독 가능STOMP는 WebSocket 위에서 동작하는 프로토콜로, 메시지를 목적지(구독 엔드포인트)로 라우팅할 수 있음구독메시지를 전송할 때 전송 엔드포인트와 구독 엔드포인트를 동시에 작성예를 들어 /topic/room/1 이라는 경로를 구독하고, /message/send 같은 전송 엔드포인트로 메시지를 전송서버는 받은 메시지를 브로커를 통해 구독자들에게 전달모든 사용자에게 메시지가 ..

HTTP 헤더 - HTTP 전송에 필요한 모든 부가정보 - 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 - 표준 헤더가 너무 많음 - 필요시 임의의 헤더 추가 가능 HTTP BODY (RFC7230) - 메시지 본문을 통해 표현 데이터 전달 - 메시지 본문 = 페이로드 (payload) - 표현은 요청이나 응답에서 전달할 실제 데이터 - 표현 헤더는 표현 데이터를 해석할 수 있는 정보 제공   - 데이터 유형(html, json), 데이터 길이, 압축 정보 등 - 참고 : 표현 헤더는 표현 메타데이터와, 페이로드 메시지를 구분해야 하지만 여기선 생략 표현 - Content-Type : 표현 데이터의 형식   - 미디어 타입, 문자 인코딩   - ..

1xx : 요청이 수신되어 처리중 - 거의 사용 X 2xx (Successful) : 클라이언트의 요청을 성공적으로 처리 - 200 OK : 요청 성공 - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 - 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음   - ex) 웹 문서 편집기의 save 버튼 3xx (Redirection) : 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요 - 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 - 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동   ..