~ WW37

 

240826

- 검색이랑 달력 필터링 기능 추가
- scantime 날짜타입 변경필요!!

 

240827

- 모킹서버 구성

- 서버 5개 모두 띄어서 확인

- CI CD 테스트코드

- 이미지 5세트 + 쉘스크립트

 

240902

- sql 세미나 준비
- jpql과 쿼리 dsl 성능 동일함!!

 

 

240903

- Saga Pattern : 마이크로 서비스에서 데이터 일관성을 관리하는 방법
각 서비스는 로컬 트랜잭션을 가지고 있으며, 해당 서비스 데이터를 업데이트하며 메시지 또는 이벤트를 발행해서, 다음 단계 트랜잭션을 호출.

만약, 해당 프로세스가 실패하게 되면 데이터 정합성을 맞추기 위해 이전 트랜잭션에 대해 보상 트랜잭션을 실행
-> Orchestration 방식과 Choreography 방식

 

 

 

240904

- out box pattern : 데이터베이스를 업데이트하는 트랜잭션 안에 발행해야할 메시지를 데이터베이스에 저장하고,
별도의 프로세스가 데이터베이스에 저장된 이벤트를 읽어서 메시지 브로커에 전송하는 것입니다.

ㄴ 주의할 점
1. 이벤트의 중복 (아이디 부여해서 비교해서 중복 막기)
ㄴ 레디스 사용..?
2. NoSQL시 주의
3. 메세지 순서 주의 (정렬 필요)

 

<publish 할 메시지 구성 방식>
ㄴ Polling Publisher : Outbox DB 테이블에 저장하여 테이블에 polling하여 publish 할 메시지를 가져옴
ㄴ Transaction Log Tailing :  publish 할 메시지를 on-demand로 생성. DBMS마다 트랜잭션이 처리되면 log(예를 들어 MySQL의 경우 binlog)를 생성하게 되는데, 해당 log에 대한 CDC(Change Data Capture)를 구현


https://devocean.sk.com/blog/techBoardDetail.do?ID=165445
https://ridicorp.com/story/transactional-outbox-pattern-ridi/
https://sweeeetgoguma.tistory.com/entry/%E3%80%8COutBox-Pattern%E3%80%8D-%ED%99%9C%EC%9A%A9


axon으로 saga 적용이 가능하다니..?!

 

 

 

240905

- 배포하여 성능 테스트 중.. (병렬처리로)

 

240906

- netty vs tomcat
:성능Netty는 비동기 방식의 클라이언트 요청을 처리하기 위해 멀티 코어를 활용하여 수십만 개의 동시 연결을 처리할 수 있다. Tomcat은 대규모 웹 어플리케이션을 처리하기 최적화되어 있어 일반적으로 단일 코어로 수천 개의 동시 연결을 처리 가능

 

- sqld 결과 나오는 날! 합격 ㅎ.ㅎ

 

240909

- msa에서 일부 서비스 실패시 관리할 서비스 개발 시작 

 

kafka-topics.sh --if-not-exists --create --topic 토픽이름 --bootstrap-server kafka-3:9094



리버스 프록시 
https://inpa.tistory.com/entry/NETWORK-%F0%9F%93%A1-Reverse-Proxy-Forward-Proxy-%EC%A0%95%EC%9D%98-%EC%B0%A8%EC%9D%B4-%EC%A0%95%EB%A6%AC

 

240910

- 테스트코드 작성

- Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)
- Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고 HTTP 요청시 서버로 전달

 

< 카프카 파티션, 레플리카>
카프카 브로커(Kafka broker) 3개로 구성된 클러스터로 구성되어 있음! (각 브로커가 동일한 주키퍼 주소를 사용해서 클러스터로 설정되어 있음)
토픽을 3개 중에 한곳에만 생성을 해도 같은 클러스터에 속해 있기 때문에 서로 공유됨 

- 파티션(Partition): 토픽 데이터를 나누어 저장하는 단위입니다. 각 파티션은 독립적으로 메시지를 저장하고 처리할 수 있어 병렬 처리가 가능합니다. 파티션 수가 많을수록 데이터 처리 성능이 향상됩니다.

- 레플리카(Replica): 파티션의 복사본입니다. 고가용성을 위해 동일한 데이터를 다른 브로커에 복제합니다. 만약 브로커가 다운되면 다른 브로커에 있는 레플리카가 그 데이터를 대신 처리해 데이터 손실을 방지합니다.

간단히 말하면, 파티션은 데이터를 나누어 처리하고, 레플리카는 데이터를 안전하게 복제하여 고가용성을 보장합니다.

 

 

240911

 

- 도커 이미지 경량화 (멀티 스테이징 빌드)
ㄴ 도커 이미지는 여러개의 레이어로 구성됨. 기존 레이어는 그대로 둔 채 새로 업데이트된 내용만 담고 있는 레이어만 쌓는 개념으로 관리
ㄴ 레이어 특징 : 격리(독립적), 재사용(여러 이미지 공유 가능), 버전 관리(이미지 업데이트 시 이전버전 레이어 유지), 도커파일 기반 레이어 생성(파일 시스템에 변화가 발생하는 경우만 이미지 레이어를 생성)
ㄴ 도커 이미지 분산의 핵심 ‘UnionFS’ : 두 개 이상의 디렉토리를 하나의 디렉토리인 것처럼 합쳐서 보여주는 시스템
ㄴ 도커 이미지는 배포되는 과정에서 여러번 pull & push 되기 때문에 이미지의 크기가 작을수록 배포 속도가 향상되며 disk 공간이 낭비되지 않습니다.
ㄴ alpine 기반 : 알파인 리눅스를 기반으로 한 이미지. Alpine Linux는 가볍고 보안에 중점을 둔 Linux 배포판으로, 작은 크기, 단순성, 효율성으로 유명.
ㄴ 멀티 스테이지 빌드 : 컨테이너 이미지를 만들면서 빌드 등에는 필요하지만, 최종 컨테이너 이미지에는 필요 없는 환경을 제거할 수 있도록 단계를 나누어 기반 이미지를 만드는 방법 (빌드는 다른 이미지로 하고, 실행은 빌드했던 이미지에서 가져와서 다른 이미지로 하는 방법. 즉, 실행하는 이미지만 최종빌드되어 도커 이미지를 최적화 하는 방법)

 

- Redis : 각 서비스별 말고 글로벌로 하나의 레디스 사용하게 
ㄴ 레디스 자료구조 공부 (주로 list와 set을 자주 사용하긴 함)

 

240912

- 도커 이미지 경량화 

 

- 도커파일에서 상위 폴더 가져오는 방법
 : 루트 디렉토리에서 
    docker build -t 이미지이름 -f 서비스이름/Dockerfile .   

 

 

240913

- OSIV (Open Session in View) 패턴은 스프링 JPA에서 데이터베이스 세션을 웹 요청 처리 동안 계속 열어 두는 전략입니다. 이 패턴을 사용하면, 웹 요청의 전체 처리 과정 동안 Hibernate 세션이 열려 있어 Lazy Loading과 같은 기능이 정상적으로 작동할 수 있습니다. (default가 true)
ㄴ 불필요한 세션 유지, 지연 로딩 관련 문제, 성능 최적화시에 false 처리!

 

 

 

*** 캐시를 구성하는 목적은 빠른 성능 확보와 데이터 전달에 있으며, 데이터의 영속성을 보장하기 위함이 아니라는 점을 기억하고 설계해야 한다.



레디스 : Read Through + Write Around 
ㄴ 데이터 정합성은 지킬 수 있으나 레디스가 다운될 경우 서비스 이용에 차질이 생기므로 클러스터 구성으로 가용성 높여야함!
ㄴ Jedis 보다 Lettuce 를 쓰자  (https://jojoldu.tistory.com/418)