Road to Backend

REQUEST 요청하면 HTML > CSS > 이미지/리소스 > JS 순으로 응답 온다.파서를 이용해서 HTML을 파싱하고 DOM 트리 구성HTML, CSS, 이미지/리소스를 이용하여 렌더링을 한다.JS는 브라우저에서 실행된다.쿠키를 사용하여 상태 저장쿠키는 key/v

과거에는 REST 대신 SOAP(Simple Object Access Protocol)를 사용 하였던것 같다.지금의 REST API들이 JSON으로 통신하는것에 비해 SOAP는 XML를 사용하여 통신하는 것이 인상적이다.

2011 베니스 SW 아키텍처 워크샾에서 Micro Service라는 용어 처음 사용MSA는 작은 서비스로 나누어서 개발각 서비스끼리 독립적 개발할 수 있어야함각 서비스마다 최적화된 개발 플랫폼을 사용할 수 있어야함각 서비스마다 통신은 REST 통신을 많이 사용

DispatcherServlet -> /백엔드에서 Dispatc란 의미는 사용자의 요청을 받아서 처리할 수 있는 개체에 전달한다는 의미이다. Dispatcher는 클라이언트의 모든 요청을 처음 받아서 적절한 핸들러에 요청을 전달한다. 이 핸들러는 Controller나

1. Java, maven, Tomcat 설치 및 경로 설정 maven : Java 프로젝트를 빌드/패키징(외부에 배포할 수 있도록) 작업 할 수 있도록 도와주는 SW. 개발에 필요한 라이브러리를 알아서 다운로드. maven 프로젝트의 설정 파일은 pom.xml이다.

많은 양의 파라미터를 직접 전달할 필요 없음병렬 처리를 고려하여 코드를 작성하도록 가이드. 로직과 설계시 병렬 처리를 적극적으로 활용하도록 작성하게됨.

디커플링은 어떻게 구현 되는가 ? 바로 인터페이스다.인터페이스는 다음과 같은 특징을 가지고 있다표준화 되어 있다.표준화 되어 있어 여러 회사, 조직에서 사용한다.많은 곳에서 사용하기에 쉽게 변경되지 않는다.인터페이스의 규칙만 지킨다면 인터페이스와 접합된 모듈은 언제든

Remote Procedure Call : 네트워크로 연결된 서버 상의 프로시저(함수, 메서드, ...)를 원격으로 호출하는 기능. RPC를 사용하면 클라이언트는 마치 로컬에서 함수를 호출 하듯 서버의 프로시저를 호출할 수 있다.RPC의 구성품. 마샬링 처리 수행.함수

Before 카프카 엔드투엔드(end-to-end) 연결 방식의 아키텍쳐. 데이터 연동의 복잡성 증가(HW, OS, System, ...). 각기 다른 데이터 파이프라인 연결 구조. 확장에 엉청난 노력 필요. 모든 시스템으로 데이터를 전송 실시간 처리도 가능한 것

server.properties

컨슈머에서 그룹을 지정하여 메시지를 polling 할 경우 다음과 같이 동작한다.지정한 그룹을 추가한다.메시지를 읽은 offset을 기억하여 offset 부터 읽기 시작한다.N개의 파티션에 기록된 메시지를 병렬적으로 가져온다(입력된 메시지 순서가 보장되지 않을 수 있다

key, value가 제대로 들어 오는지 확인하기 위해서 콘솔 컨슈머를 다음 옵션과 함께 실행key 값을 넣지 않는 방식으로 레코드 전달 할 경우카프카가 전달하는 메시지는 레코드라고 한다.레코드 키는 메시지를 구분하는 구분자 역할을 한다.동일 키는 동일 파티션에 적재한

데이터를 가져가는 polling 주체.커밋을 통해 읽은 컨슈머 offset을 카프카에 기록.데이터 저장 위치.FileSystem(.csv, .log, .tsv)Object Storage(S3, Minio)Hadoop(Hdfs, Hive)RDBMS(Oracle, Mysq

컨슈머 그룹의 파티션 소유권이 변경될 때 일어나는 현상.컨슈머와 파티션 할당 변경.리밸런스를 하는 동안 일시적으로 메시지를 가져올 수 없으며 리밸런스 발생시 데이터 유실/중복 발생 가능성 있음.commitSync() 또는 추가적인 방법(unique key)으로 데이터

1 : 1 프로세스 + 1 쓰레드(컨슈머)간략한 코드프로세스 단위 실행/종료다수의 컨슈머 실행 필요시 다수의 프로세스 실행 필요2 : 1 프로세스 + n 쓰레드(동일 컨슈머 그룹)복잡한 코드쓰레드 단위 실행/종료스레드간 간섭 주의(세마포어, 데드락등)다수 컨슈머 실행시

컨슈머 마지막 커밋 오프셋과 토픽의 마지막 오프셋 차이.컨슈머 랙을 모니터링 하는것은 중료. 컨슈머 랙이 크다는 것은 서비스 처리가 느리다는 의미.컨슈머 랙은 컨슈머의 상태를 나타내는 지표. 컨슈머 랙의 최대값은 컨슈머 인스턴스를 통해 직접 확인할 수 있음.consum

제 3의 그룹이 토픽이 필요할때 만들고 더 이상 니즈가 없으면 컨슈머 삭제하고 토픽도 삭제.레코드 안에 타임 스탬프를 기록하여 병렬 처리 하여도 타임 스탬프 순서로 처리.파티션은 기본적으로 3개 사용 하지만 컨슈머 랙에 따라 파티션을 늘림. 파티션을 늘리는 일은 큰 일

syntax : "proto3"Proto version 지정. 명시하지 않으면 default로 version 2.지원 언어 차이.Proto2 지원 언어 : C++, Java, Python, GoProto3 지원 언어 : C++, Java, Python, Go, Ruby

message 들은 일련의 Key-Value 쌍으로 이루어진 binary data로 인코딩된다. Key는 Field Number 뿐만 아니라, 해당 Field의 data type을 지시하는 "Wire Type"을 표현.Key 구성Key = (field_number &l

정규화(사람이 데이터 관리하기 편한 방식)된 데이터 구조에서 성능 지향적인 데이터 구조로 변경BeforeAfterjoin 할 필요 없이 tag_name에 컬럼을 추가.데이터 중복 발생BeforeAfter관계를 표현하기 위한 테이블 추가. Join 할 필요 없이 topi

LoggerFactory로 생성하고 직접 클래스 지정2024-01-14T13:31:27.447+09:00 INFO 10908 --- \[ main] c.example.ktorsamplespring.MyLogTester : Test Loggradl