일상_자기계발

Transactional Outbox Pattern 2편

해당 내용은 ChatGPT 와 함께합니다. 제목링크Transactional Outbox Patter 1편https://jm-baek.tistory.com/468✅ Transactional Outbox Patter 2편https://jm-baek.tistory.com/470 목차1. 메세지가 중복 발행되면 어떻게 할까?2. Transactional Outbox의 장단점3. 결국 언제 사용하는 것이 좋을까?1. 메세지가 중복 발행되면 어떻게 할까?Transactional Outbox Pattern을 사용하면 메시지 발행에 실패하더라도 Outbox에 메시지가 남아 있기 때문에 다시 발행할 수 있다. 하지만 재시도가 가능해지면서 또 하나 고려해야 할 문제가 생긴다.바로 메시지 중복 발행이다.Outboxevent..

Transactional Outbox Pattern 1편

해당 내용은 ChatGPT 와 함께합니다. 제목링크✅Transactional Outbox Patter 1편https://jm-baek.tistory.com/468Transactional Outbox Patter 2편https://jm-baek.tistory.com/470 목차1. OutBox / InBox 란?2. 왜 Transactional Outbox가 필요한가?3. Transactional Outbox Pattern이란?4. Outbox 메시지는 어떻게 발행할까?1. OutBox / InBox 란?Transactional Outbox Pattern을 알아보기 전에 Outbox와 Inbox라는 이름이 어떤 의미인지 먼저 알아보자. 이름의 의미를 이해하면 이후 패턴의 동작 방식도 훨씬 쉽게 이해할 수 ..

1장. AWS? 노트북?가장 먼저 고민했던 것은 서비스를 실제로 동작시키기 위해 “어디에 배포할 것인가?”​였다. 처음에는 크게 두 가지 방법을 생각했다.aws 를 사용해서 서버를 올릴까?!아니면 노트북에 가상 서버를 여러 대 띄워서 운영할까?개인 프로젝트인 만큼 비용을 줄이기 위해 노트북에 가상화 서버 여러 대를 띄우는 방법에 대해 많이 고민했다.가상 서버 세 대를 띄우고 네트워크 통신 되는 서버 등 여러 설정을 이것 저것 테스트 해보았고, 생각보다 나쁘지 않다고 느꼈다. 하지만 다른 작업을 하는 동안 노트북 리소스가 계속 사용되고 아무리 개인 프로젝트라고 하지만 사용자를 유입까지 목표로 하고 있기 때문에 안정적으로 서비스를 제공하기 위해 AWS를 선택했다. 사실 AWS를 선택하기까지 가장 부담스러웠던..

1장. 다중 서버???0탄에서 서비스를 배포할 환경으로 AWS EC2를 선택했다.그리고 EC2에 서비스를 올리고 나니 새로운 욕심이 생겼다. “서버를 여러 대 띄우고 사용자의 트래픽을 분산해서 처리해보면 어떨까?” 사실 맞다. 인정한다! 개인 프로젝트에 그렇게 많은 사용자가 접속할 가능성은 높지 않다. 현재 규모만 생각하면 트래픽을 분산하기 위해 서버를 여러 대 구성할 이유도 거의 없다. "사용자도 별로 없는데 굳이 Load Balancer까지 필요한가요?” 라고 물어본다면 딱히 반박할 말도 없다. 하지만 이번 프로젝트의 목표 중 하나는 단순히 서비스를 완성하는 것뿐만 아니라, 직접 인프라를 구성하면서 운영 구조를 경험해보는 것이다. 그렇다고 사용하지도 않을 기술을 전부 가져다 붙이고 싶지는 않았다.최대..

어렵게 생각하지말고.. 그냥 해보자! 하다 보면 알지 않을까? 한 번에 많은 내용을 할 생각은 없다!직접 명령어를 작성해 보고 기능에 대해 궁금해 보자. Scale-out/in 란? Scale-out 해보기현재 Deployment → ReplicaSet → Pod → Service → 브라우저 접속 까지 성공했고, 이제 pod 개수를 늘려보자! 1) 명령어를 실행 해보자. deployment nginx→ nginx라는 이름의 Deployment를 --replicas=3→ Pod가 3개가 되도록 kubectl scale deployment nginx --replicas=3 2) 명령어 결과를 확인해보자.pod 3개가 실행 중인 것을 확인할 수 있다.Deploymentnginx READ..

어렵게 생각하지말고.. 그냥 해보자! 하다 보면 알지 않을까? 한 번에 많은 내용을 할 생각은 없다!직접 명령어를 작성해 보고 기능에 대해 궁금해 보자. Service 란? Service 만들기현재 Deployment → ReplicaSet → Pod 로 되어 있고, 여기에 Service를 연결해보자. 아래 명령어를 실행한다.kubectl expose deployment nginx --type=NodePort --port=80 1. kubectl expose deployment nginx→ nginx Deployment의 Pod들을 외부에 노출할 Service를 만들어줘 2. --type=NodePort→ Node의 포트를 통해 접근할 수 있게 해줘 3. --port=80→ Service는 ..

어렵게 생각하지말고.. 그냥 해보자! 하다 보면 알지 않을까? 한 번에 많은 내용을 할 생각은 없다!직접 명령어를 작성해 보고 기능에 대해 궁금해 보자. Deployment 란? Deployment 만들어 보기Deployment 하나를 만들어 보자는 말을 쉽게하면,nginx가 실행 되는 Pod를 1개 유지하도록 Kubernetes 에게 관리자를 하나 만들어보자라는 뜻이다. 이제 명령어를 실행해 보자.kubectl create deployment nginx --image=nginx 1. create deployment→ Deployment를 만들어라2. nginx→ Deployment 이름을 "nginx"로 해라 3. --image=nginx→ Pod의 컨테이너는 nginx 이미지를 사용해라 ..