imhamburger 님의 블로그

우리 프로젝트의 경우, 각기 다른 티켓예매사이트들의 티켓정보들을 한 사이트로 모아 여기저기 티켓을 찾아볼 필요없이 한 사이트에서 찾아볼 수 있는 서비스를 기획했다. 원래는 추천시스템을 만들 생각은 없었지만, 추천시스템이 없으면 단순 데이터 검색? 기능뿐이라 추천시스템을 추가하게 되었다.추천시스템은 DB에 적재되어 있는 공연의 상세설명(공연설명)을 읽어와 모든 공연 설명들에 대해 코사인 유사도로 계산하여 각 공연마다 유사도가 가장 높은 TOP3 까지의 공연만 보여주는 것이다. 그리고 나는 조건을 몇 개 더 추가하여 필터링하였다.기준 공연 시작일 이후이면서 기준공연 시작일 + 90일까지로 날짜 제한 설정기준 공연과 같은 지역으로 설정 추천시스템 코드 흐름공연설명을 형태소 분석기로 명사만 추출 (전처리)Wor..

지난글에서 user_id를 headers.get 하여 얻어오는 방식을 이용했었는데 그 부분을 바꿔야 한다.이유는 우리 프로젝트는 로그인 기능을 jwt토큰을 이용하였기 때문이다. 여기서 jwt란 Json Web Token 으로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰이다.jwt 토큰에는 Header / Payload / Signature 로 구성되어 있다. (jwt 토큰)  1. Header헤더는 JWT의 타입과 서명에 사용된 알고리즘을 나타낸다.{ "typ": "JWT", "alg": "HS256"}  2. Payload페이로드는 JWT에 포함될 실제 데이터이다. 이 데이터에는 사용자 정보나 권한과 같은 정보가 들어갈 수 있다.{ "sub": "1234567890", "u..

파이널 프로젝트에서 DB 설계를 하던 중 3개의 웹사이트에서 크롤링한 데이터를 DB에 적재할 때 중복값 처리는 어떻게 할지 고민이었다.같은 웹사이트에서 가져오는 데이터라면 고유번호를 기준으로 DB에 적재하면 되는데 각기 다른 사이트이기에 이 방법은 쓸 수 없었다. 하지만 중복값이라는 건 어쨋든 같은 데이터이기 때문에... 대표 1개의 웹사이트를 정해서 먼저 DB에 데이터를 적재한 후,나머지 2개를 DB에 넣을 때 같은 값이 있을 경우에 "hosts"라는 컬럼 안에 site_id와 url 이 추가되는 것으로 처리하였다. Mongodb 초기 설계{ "_id": ObjectId("..."), "title": "뮤지컬 공연 제목", "start_time": "2024-11-20T19:00:00", "en..

파이널 프로젝트에서 우리의 서비스를 이용하는 사용자 로그를 s3에 적재하는 것을 설계했었다.로그데이터는 실시간으로 찍히기 때문에 Apache Kafka를 이용하면 딱! 이겠다라는 생각이 들었다. 로그데이터를 저장하려고하는 이유는,각 부서가 데이터 기반 의사결정을 내릴 수 있도록 지원하기 위해, 대시보드에서 실시간 데이터를 시각화하고 활용할 수 있게 만들기 위함이다. 이를 위해 로그 데이터를 실시간으로 수집하고 적재하는 안정적인 파이프라인이 필요하다.Apache Kafka는 높은 처리량과 낮은 지연 시간을 보장하며, 로그 데이터의 스트리밍 처리에 적합한 도구로, 실시간 데이터 수집과 처리에 딱 맞는 솔루션이라고 생각했다.  따라서, 로그데이터 적재 설계는 다음과 같다.   1. 우선 나는 로그를 생성하는 ..

내 로컬에 있는 것을 원격 깃허브에 푸시하려할 때 다음과 같은 메세지가 떴다. 에러메세지(?) To push, remove secret from commit(s) or follow this URL to allow the secret. 이 오류 메시지는 Git 커밋에 민감한 정보(예: 비밀번호나 API 키)가 포함되어 있을 때 발생할 수 있다고 한다.GitHub와 같은 Git 호스팅 서비스에서는 보안상의 이유로 민감한 정보가 푸시되는 것을 막는다. 알고보니, 내가 테스트하려고 만들어 놓은 파이썬 파일에 AWS 키가 들어가 있었다....(큰일날뻔)그래서 그거를 삭제하고 푸시하려하니... 에러가 해결되지 않았다. 삭제한 후에도 같은 오류가 발생하는 경우, Git 커밋 기록에 여전히 민감한 정보가 남아 있을 수..

이번엔 에어플로우를 통해 크롤링한 RAW DATA를 s3에 적재하는 방법에 대해 공유하고자 한다.(사실 너무 간단해서 의아했다.....ㅎ) 나의 파이프라인은 다음과 같다. s3에 적재에 성공하면 라인을 통해 success 메세지를 받는다.  먼저, dag 파일을 작성하기 전에 에어플로우 창에서 s3 관련 정보들을 입력해줘야 한다. 1. Admin - Connections 들어가기   2. 하나 만들어 다음과 같이 입력하고 save 하기  그런다음 다시 DAG파일로 돌아오자.에어플로우와 s3를 연결하기 위해서는 airflow.providers.amazon.aws.hooks.s3 이 필요하다.에어플로우에서 제공하는 모듈이니 import를 하면된다.  나의 DAGfrom airflow.providers.ama..

지난주에는 에어플로우 스케줄러를 이용해 정기적으로 크롤링해오는 기능을 만들었다. 크롤링 기능을 별개의 가상환경에서 실행하도록 설계했으며, 배치 작업과 크롤링 기능을 분리한 이유는 추후 크롤링에서 에러가 발생했을 때 크롤링 기능만 수정하면 되기 때문에 유지보수가 용이하다는 점이었다. 하지만 문제는 배치 작업이 실행될 때마다 크롤링을 처음부터 다시 시작해야 할지에 대한 것인가? 이다. 만약 그렇다면 효율적이지 않다.그래서 offset.ini 파일을 사용해 마지막으로 크롤링한 페이지 번호를 저장하고, 크롤링이 끝난 후 마지막 페이지 번호를 offset에 저장했다. 하지만 이 방법을 에어플로우에서 사용하려니 문제가 생겼다.크롤링 기능은 가상환경에서 실행되기 때문에, 그곳에서 저장된 offset.ini 파일을 에..

드디어 파이널 프로젝트를 시작했다. 우리팀 파이널 프로젝트 주제는 다음과 같다. 팀프로젝트 주제 현재 다양한 플랫폼에 분산된 공연 및 스포츠 경기 등의 티켓 정보를 한곳에서 확인하고 비교할 수 있도록 지원하는 플랫폼 개발이를 통해 사용자들이 다양한 선택지를 쉽게 탐색하고 티켓 구매의 편의성을 높이고자 한다.  목표 사용자가 여러 티켓 플랫폼에서 제공되는 티켓 정보를 쉽게 비교할 수 있도록 하여, 공연 및 스포츠 경기 티켓 구매 과정에서 시간을 절약하고, 최적의 선택을 할 수 있는 환경을 제공한다.  나의 역할 데이터 수집** 티켓 정보 크롤링** 티켓 홈페이지에서 티켓 정보 크롤링** 티켓 정보 크롤링** 홈페이지에서 티켓 정보 크롤링** 티켓 정보 크롤링** 티켓 홈페이지에서 티켓 정보 크롤링자체 회원..

이번에 진행한 팀프로젝트는 파이널  프로젝트를 위한 빌드업으로 docker compose로 모든 어플리케이션을 실행하는 환경을 구축하였다.이번에도 주어진 시간은 3일이었고 파이널프로젝트 아키텍쳐를 기반으로 각자의 역할을 정했다. 그 중 나의 역할은 kafka를 docker compose로 띄우는 것이었다.  팀프로젝트 주제똑같은 개발환경에서 개발 가능 하도록 (docker, docker compose, minikube, k3s ... 등등 적합한것 활용)prometheus - grafana - exporter 대시보드 만들기prometheus 로 수집된 모니터링 지표 관리 프로그램에 연결scale 조정 관리 화면 만들기 나의 역할Kafka를 docker compose로 설정하기kafka 실행 로그를 pr..

파이널 프로젝트 시작 전에 모든 개발환경을 yaml 파일로 실행시키고 Grafana 시각화를 만드는 작은? 프로젝트를 먼저 진행하였다. (작은?!!)나는 그중에서 Kafka를 맡았는데 이번에 Kafka를 yaml로 구축하면서 더 자세히 들여다볼 수 있는 시간을 가졌던 것 같다.  카프카는 Broker를 통해 데이터를 보내고 받는 형식이다.Broker는 내가 개수를 지정할 수 있는데, 이러한 의문이 들었다. Broker는 몇 개가 적당한거지? 그래서 여기저기 검색해보니 브로커를 최소 3개를 사용하는게 좋다는 내용을 보았다.그리고 홀수개여야 한다는 점! 왜 3개가 좋은건지 이해하기 전에 acks 와 min.insync.replicas 옵션을 먼저 짚고 넘어가야 한다. 카프카에서 acks는 프로듀서가 메시지를..