본문 바로가기

전체 글

 (123)
HTTP 전송을 위한 TCP 커넥션에 대하여 TCP 커넥션 생성 크롬과 같은 브라우저 주소창에 URL을 입력하면 브라우저는 IP주소를 알아내기 위해 호스트명을 추출하고, 또한 포트번호를 추출하여 IP주소와 포트번호로 해당 서버에 TCP 커넥션을 생성한다. TCP의 역할 TCP는 전송하고자 하는 데이터를 세그먼트라 불리는 조각 단위로 나눠 IP 패킷에 담아 전송한다. 이때 전송하고자 하는 데이터는 HTTP 요청 방식에 따라 차이가 있겠지만 '요청 메서드', '요청 URL', 그 외 '요청 헤더'에 담기는 각종 정보들이다. 결론적으로 IP 패킷 내 전송을 위한 정보를 담은 'IP 헤더'에 'TCP 세그먼트'가 동봉되어 전송되는 셈이다. TCP 세그먼트에는 데이터 스트림 말고도 서버와 커넥션을 맺고, 소통하기 위한 정보가 담겨있다. 그 중 SYN, AC..
JWT와 토큰 생성, 강제 로그아웃에 대하여 JWT가 등장한 이유 기존에는 유저의 로그인 상태, 권한 등에 대한 정보를 파악하기 위해 로그인 시 '세션' 이라는 데이터 구조를 생성해 서버에 저장하고, 세션ID를 쿠키에 담아 클라이언트에게 전달해 주는 방식을 취해왔다. 그래서 로그인 상태를 파악하려면 세션ID를 서버에 전달해서 필요한 정보를 확인하는 흐름을 가졌다. 해당 방식은 서버에서 세션을 유지해야 함(stateful)을 의미하는데 이는 서버 메모리, 데이터베이스 혹은 메모리 캐시와 같은 저장소에 보관되었다. 이는 동시 접속 유저 수가 증가할수록 세션 정보를 조회하거나 상태 변경을 위한 요청 횟수가 증가함을 의미하고, 이는 곧 CPU, 메모리 자원 소모가 증가함을 의미한다. 또한 유저 수가 증가하면서 서비스의 규모가 증가하면 서버와..
데이터베이스의 1:N 관계에서 N+1 문제가 무엇인가? ORM 사용에서 OneToMany와 ManyToOne과 같은 연관 관계로 묶인 테이블을 조회할 때 성능이슈가 발생하는 문제을 말한다. 가령 Channel과 User라는 Entity가 1:다 관계로 묶여 있다고 하고, Channel의 레코드는 총 10개가 있다고 가정하자. 이제 ORM으로 Channel Entity를 대상으로 findAll을 명령하면 내부적으로 "SELECT * FROM Channel"이라는 쿼리문 하나를 생성하여 데이터베이스에 요청할 것이다. 이때 생성된 쿼리문이 1개이고 딱 한 번 요청을 하는 것이다. 하지만 문제는 Channel과 연관된 User데이터도 함께 가져오려고 한다는 것이다. 그래서 최초 요청했던 findAll의 결과로 총 10개의 레코드를 획득할텐데, 이 각각의 채널에 속한..
var, let, const의 차이와 호이스팅, 스코프 자바스크립트에서 var, let, const 모두 호이스팅을 한다는 사실을 뒤늦게 알게 되었다. 사실 호이스팅 자체가 잘 이해가 가지 않았기 때문인 것 같다. "호이스팅은 선언된 변수나 함수를 코드의 상단으로 끌어올린다." 라는 표현을 쓰는데 이전에는 "var apple;을 선언한 뒤 console.log(apple)을 입력하고, 그 아랫줄에 apple = 1이라고 초기화하면 console.log(apple)은 1이 출력되어야 한다는 말인가?" 라고 받아들여졌다. 하지만 틀린 말이다. 실제로 출력값은 undefined가 나오기 때문에 별 문제가 없어보인다. 그럼 상단으로 끌어올려지는건 대체 뭐란 말인가? 호이스팅 일단 호이스팅은 스크립트의 컴파일 단계에서 벌어지는 일이라고 한다. 컴파일 과정에서 var,..
Redis에 대해서 살펴보자 아래 깃헙에서 더 깔끔하게 볼 수 있습니다. https://github.com/issuebombom/study_notes_nodejs_backend/blob/main/contents/redis.md Redis 캐시로 사용하기 Cache란?) 데이터의 원래 소스보다 더 빠르고 효율적으로 엑세스할 수 있는 임시 데이터 저장소 Redis는?) 단순한 key-value 구조로 저장하는 캐시 In-memory 저장소 (평균 작업 속도 < 1 ms) 캐싱전략(읽기) 데이터베이스에 접근하기에 앞서 Redis에 먼저 접근하여 필요한 데이터를 빠르게 가져온다.(Cache Hit) Redis에 필요한 자료가 없을 경우(Cache Miss) 데이터베이스에 접근하여 데이터를 가져오도록 한다. (Lazy Loading) 특징 ..
HTTP와 Kafka를 통한 MongoDB 도큐먼트 생성 비교 (부하테스트) 먼저 구현한 서비스의 로직을 살펴보자 - main(nestjs) 서버는 엔드포인트로 유튜브 링크를 전달받습니다. - main에서 extractor(python) 서버로 받은 링크 정보를 또 다시 전달합니다. - extractor 서버에서 유튜브 링크 관련 정보(메타데이터)를 추출합니다. - 정보를 데이터베이스(MongoDB Atlas) 저장합니다. 위 과정에서 axios를 사용하여 http 통신을 하는 것과 카프카 브로커로 메시지를 전달하는 두 가지 방식을 비교해 보았다. 각 서버는 모두 컨테이너로 실행했다. axios로 http 요청 후 도큐먼트 생성 먼저 axios로 구현한 코드를 살펴보자 // links.service.ts import { HttpService } from '@nestjs/axios..
카프카 컨테이너로 메시지 전송하기 - nest.js, python GitHub - issuebombom/get_youtube_audio Contribute to issuebombom/get_youtube_audio development by creating an account on GitHub. github.com Nest.js로 클라이언트에게 유튜브 링크를 입력받으면 이를 카프카 브로커에 메시지로 전송하고, python 라이브러리인 pytube로 해당 링크의 영상 정보를 획득하기 위해 python에서 consumer를 구현하여 메시지를 구독한다. 오늘 핵심 주제는 위 과정을 docker compose를 이용하여 각각 컨테이너로 빌드하여 동작하게 하는 것을 구현하는 과정과 이 과정에서 해결한 문제들에 대해서 알아보자. 컨테이너 없이 로컬 환경에서 간단하게 구현하는 내용..
성경 읽기 사이트 제작 과정 정리 - python, javascript 제작 배경 평소 교회 갈 때는 성경이 무겁다는 핑계로 잘 들고 다니지 않게 되다 보니 간단한 성경 조회 사이트를 만들어서 휴대폰으로 볼 수 있게 만들어야겠다는 결심을 하게 되었다. 사실 성경을 볼 수 있는 무료 앱도 있지만 상단에 비치되는 배너 광고가 보고 싶지 않았다. 얼핏 생각해도 금방 만들 수 있을 것 같아서 시작하게 되었고, 예상대로 금방 만들었다. 먼저 제작 과정은 아래와 같았다. 성경 내용 수집, 조회 방식을 고려한 데이터 형식 선정 성경 조회 서비스 개발(백엔드) 성경 조회 및 결과 확인을 위한 정적 html 제작 (프론트) 위 제작 과정에 따라 차근차근 살펴보도록 하겠다. 성경 내용 수집 사이트 선정 (http://www.holybible.or.kr/) 성경 수집을 위해 구글, 네이버 서칭..

티스토리툴바