DevBoi

카프카 클러스터에는 브로커를 각기 다르게 설정할수있다. 이런한 클러스터들은 하나의 주키퍼 앙상블로 운영이 될 수가 있는데 아래와 같다. 하나의 주키퍼 앙상블은 여러대의 클러스터들과 매핑이되고 각 클러스터는 각기 다른 브로커수를 가진다. 카프카 클러스터를 운영하려면, 반드시 주키퍼가 필요하다. 3.0부터는 주키퍼가 없어도 클러스터 자체로 사용가능하다. 하지만, 예전 버전에서는 주키퍼가 필수였어서 앙상블이라는 개념이 도입되었다.

주키퍼 카프카 브로커는 카프카 클라이언트와 데이터를 주고받기 위해 사용하는 주체이자 데이터를 분산 저장하여, 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션이다. 하나의 서버에는 한개의 카프카 브로커 프로세스가 실행된다. 하나의 서버에는 한개의 카프카 브로커 프로세스가 실행된다. 카프카 브로커 서버 1대로도 기본 기능이 실행되지만, 데이터를 안전하게 보관하고 처리하기 위해 3대이상의 브로커서버를 1개의 클러스터로 묶어서 운영한다. 그래서 하나의 클러스터에는 3개의 브로커를 사용하는게 기본이고 해당 클러스터를 늘리거나, 브로커의 수를 늘리는경우가 있다. 브로커는 한개당 프로세스이다. 한개로도 돌아가지만, 안전하게 사용하려면 한개의 브로커가 아니라 최소 3개이상의 브로커로 운영을 하는게 ..

카프카 생태계는 아래와 같다. 토픽을 가져가는 건 컨슈머가 가져간다. 토칙에 저장된 데이터를 Stateful, Stateless 하게 데이터를 처리해서 다시 토픽에 넣고싶다면? 카프카 스트림즈를 쓴다. 커넥트는 싱크커넥트와 소스 커넥트가 있다. 소스 커넥트는 프로듀서 역할을 하고 싱크 커넥트 같은 것들은 타겟 애플리케이션으로 데이터를 보내는 역할을 한다. 커넥트는 템플릿화를 하여 반복적으로 여러번 파이프라인 생성이 가능하다. MM2 이러메이커라는 것이 있고, 클러스터 단위로 토픽에 있는 데이터를 완벽하게 복제하기위해서 사용하기도 한다.

카프카가 왜 데이터 파이프라인으로 활용하게 되는지 살펴보자 1. 높은 처리량 카프카는 프로듀서가 브로커로 데이터를 보낼때와 컨슈머가 브로커로부터 데이터를 받을때 모두 묶어서 전송한다. 많은 양의 데이터를 송수신할 때 맺어지는 네트워크 비용은 무시할 수없다. 동일한 양의 데이터를 보낼때 네트워크 통신 횟수를 최소한으로 줄인다면, 동일 시간 내에 더 많은 데이터 를 전송할 수 있다. 또한 파티션 단위를 통해 동일 목적의 데이터를 여러 파티션에 분배하고, 데이터를 병렬 처리할 수 있다. 파티션 개수만큼 컨슈머 개수를 늘려서 동일 시간당 데이터 처리량을 늘리는 것이다. 최소한의 네트워크 비용으로 최대한의 데이터 전송이 가능하다는 것이 결론이다. 파티션은 최소 1개이상, N개까지 가능하다. 컨슈머 개수를 한개 늘..

링크드인에서 만들었다. 데이터를 생성하는 소스애플리케이션과 데이터가 최종 적재되는 타깃애플리케이션을 연결해야할때 사용한다. 소스 애플리케이션의 타깃애플리케이션의 개수가 점점 많아지면서 문제가 생겼다. 내부데이터 흐름을 개선하기 위해 한곳에 모아서 처리를 하는 방식이 가장 큰 특징이다. 카프카는 토픽이라는 개념을 바탕으로, 프로듀서와 컨슈머로 나눠지면 해당 파티션으로 전송이 된다. 프로듀서는 특정 데이터에 대해서 보내게 되면, 파티션 중 하나의 데이터가 저장되고 그 파티션의 내부구조는 큐 형태로 동일하게 구현이 되어있다. 파티션마다 다르게 큐에 담겨서 데이터가 컨슈머에게 전달이 되게 된다. (순차적으로) 큐에 데이터를 보내는 것이 프로듀서고 큐에서 데이터를 가져가는 것이 컨슈머 이다. 또한 컨슈머는 큐에 ..

쉽게 json과 ObjectMapper를 많이 쓴다. 이유는 String Object간의 자유로운 이동과 변환을 위해서 많이 사용한다. 내가 주로 사용하는것 외에도 다른 기능들이 존재할 것 같아서, 해당 기능들을 사용하면서 포스팅해보자 1. 의존성 추가 implementation 'com.fasterxml.jackson.core:jackson-databind:2.12.3' 2. 간단한 사용 예제 (Object -> String, writerValue) package com.example.demo; import com.fasterxml.jackson.databind.ObjectMapper; import lombok.RequiredArgsConstructor; import org.springframework..

queryBuilder를 간략하게 썼었다. 근데 조금 더 심화를 써보자 1) 조인되는 엔티티가 여러개이다. 2) 조인되는 엔티티중 원하는 값만 가져오자 3) 각 조인되는 엔티티는 마스터 이외에는 left조인으로 해보자 or innerJoin으로 해보자 해당 조건을 충족하는 쿼리빌더는 아래와 같다. async getCart(id: string): Promise { const result = await this.cartRepository.createQueryBuilder('cart') .innerJoin(Food,'food','food.id=cart.foodId') .innerJoin(Member,'member','member.id=cart.memberId') .select (['food.id','food...

오늘은 AuthGuard를 이용하여, 해당 가드를 적용할건데 각기 다른 정책으로 관리가 되게 개발을 할 것이다. 쉽게 얘기하면, 한개는 일반 사용자인지, 즉 auth bearer token으로 요청을 하는지 또 한개는 해당 사용자이지만, 사업가의 authCode인지를 체크하는 것이다. 적용한 코드를 참고 바란다. 1.패키지 구조 2.auth-guard.ts import { ExecutionContext, Injectable } from "@nestjs/common"; import { AuthGuard as NestAuthGuard } from "@nestjs/passport"; import { Observable } from "rxjs"; @Injectable() export class JwtAuthGu..

엔티티간의 다대다 관계인 경우, 해당 매핑 테이블을 생성하는 것이 좋은데 매핑 테이블을 엔티티로 선언하는 것보다, 해당 역할을 하는 엔티티를 생성하는 것이 좋다. 1) 매핑 엔티티 import { Entity, Column, PrimaryGeneratedColumn, CreateDateColumn, UpdateDateColumn, JoinColumn, OneToOne, ManyToOne } from 'typeorm'; import { Member } from 'src/member/entities/member.entity'; import { Campaign } from 'src/campaign/entities/campaign.entity'; import { CampaignMemberResDto } from..

의존성 추가 npm install --save bcrypt @types/bcrypt 메소드 구현 (암호화 모듈) async transformPassword(member: MemberReqDto): Promise { member.password = await bcrypt.hash( member.password, 10, ); return Promise.resolve(); } 컨트롤러 소스 async registerUser(memberReqDto: MemberReqDto): Promise { await this.transformPassword(memberReqDto); console.log(memberReqDto); return null; } 해당 transformPassword를 통해 해당 암호화를 리턴받을..