[TIL]

Microservices Architecture (MSA)MSA는 하나의 애플리케이션을 여러 개의 독립적인 서비스로 분리하여 개발, 배포, 유지보수를 용이하게 하는 소프트웨어 아키텍처 스타일각 서비스는 특정 비즈니스 기능을 수행하며, 서로 독립적으로 배포되고 확장될 수

MSA에서 각 서비스의 위치를 동적으로 관리하고 찾아주는 기능각 서비스는 등록 서버에 자신의 위치를 등록하고, 다른 서비스는 이를 조회하여 통신주요 기능으로는 서비스 등록, 서비스 조회, 헬스 체크 등넷플릭스가 개발한 서비스 디스커버리 서버.모든 서비스 인스턴스의 위치

네트워크 트래픽을 여러 서버로 분산시켜 서버의 부하를 줄이고, 시스템의 성능과 가용성을 높이는 기술서버 간 트래픽을 고르게 분배하여 특정 서버에 부하가 집중되는 것을 방지종류 : 클라이언트사이드 로드 밸런싱, 서버 사이드 로드 밸런싱클라이언트가 직접 여러 서버 중 하나

서킷 브레이커는 마이크로서비스 간의 호출 실패를 감지하고 시스템의 전체적인 안정성을 유지하는 패턴외부 서비스 호출 실패 시 빠른 실패를 통해 장애를 격리하고, 시스템의 다른 부분에 영향을 주지 않도록 한다.상태 변화: Closed -> Open -> Half-OpenR

API 게이트웨이는 클라이언트의 요청을 받아 백엔드 서비스로 라우팅하고, 다양한 부가 기능을 제공하는 중간 서버입니다.클라이언트와 서비스 간의 단일 진입점 역할을 하며, 보안, 로깅, 모니터링, 요청 필터링 등을 처리합니다.라우팅: 클라이언트 요청을 적절한 서비스로 전

마이크로서비스 아키텍처에서는 각 서비스가 독립적으로 배포되고 통신하기 때문에 보안이 매우 중요합니다.데이터 보호, 인증 및 권한 부여, 통신 암호화 등을 통해 시스템의 보안성을 확보해야 합니다.OAuth2는 토큰 기반의 인증 및 권한 부여 프로토콜입니다.클라이언트 애플

Spring Cloud Config는 분산 시스템 환경에서 중앙 집중식 구성 관리를 제공하는 프레임워크입니다.애플리케이션의 설정을 중앙에서 관리하고, 변경 사항을 실시간으로 반영할 수 있습니다.Git, 파일 시스템, JDBC 등 다양한 저장소를 지원합니다.중앙 집중식

분산 추적은 분산 시스템에서 서비스 간의 요청 흐름을 추적하고 모니터링하는 방법입니다.각 서비스의 호출 관계와 성능을 시각화하여 문제를 진단하고 해결할 수 있도록 돕습니다.주요 개념: 트레이스(Trace), 스팬(Span), 컨텍스트(Context)트레이스(Trace)

MSA를 도입하기 위해서는 수업의 내용처럼 많은 것들이 사용되며, 정책 설정을 해야 할 것이 많다. 빠르게 프로젝트의 프로토 타입을 만들어야 한다면 모놀리틱 아키텍쳐를 사용하고, 후에 부분, 부분 전환하는 것도 방 법 중 하나다.개발에 정답은 없다. 개발팀이 추구하는

기존엔 redis image 만 사용했었는데, 다른 이미지도 존재했다.redis/redis-stack-server 는 여러 플러그인이 추가된 Redis Stack 서버 이미지이며, 확률형 데이터, JSON 문서 등을 사용하고 싶다면 선택하면된다.redis/redis-s

간단하게 세션 클러스터링을 구성해본다.RedisConnectionFactory 를 통해 application.yml 파일에서 설정한 redis 세팅을 RedisTemplate에 적용시키고, 직렬화 옵션도 설정해준다.간단하게 HttpSession 을 통해 session의

기존에 Github Action + s3 + Code Deploy 를 통해 CI/CD 환경을 구축했었다.그리고 여러 작은 프로젝트에서 배포는 DockerHub를 통해 직접 배포하는 형식으로 간단하게 구축했었다.이번에는 AWS의 ECS와 GitLab을 통해 CI/CD 파

어플리케이션을 개발 후, 안정적이고 효율적인 운영을 위한 모니터링은 필수적이다.중요한 점은 시스템의 성능, 가용성, 안정성을 지속적으로 감시하면서, 잠재적인 문제를 발견해 이상 징후를 조기에 발견해 심각한 문제가 생기기전 해결하는 것이다.서버 모니터링: CPU, 메모리

이번엔 여러 보안 관련 시큐어 코딩 정리를 하려고 한다.이번에 정처기를 준비하면서 대부분 봤던 개념들인데, 정확히 어떤건지 어떻게 예방하는지를 정리하고자 한다.가장 많이 접하는 문제가 아닐까 싶다.한 출처(도메인, 프로토콜, 포트) 에서 실행 중인 웹 애플리케이션이 다

얼마나 많은 사용자가 시스템을 사용할 것인지 파악하는 것이 중요합니다. 기존 시스템에 새로운 기능을 추가하는 경우, 시스템 모니터링을 통해 하루에 몇 명의 사용자가 접속하는지 알 수 있습니다. 그러나 단순히 하루 접속량을 파악하는 것만으로는 충분하지 않습니다. 더 중요

메시지 브로커로, 메시지를 큐(queue)에 저장하고, 필요할 때 적절한 수신자에게 전달한다.비동기 처리 : 데이터를 비동기적으로 처리해 시스템의 응답성을 높인다.부하 분산 : 여러 소비자에게 메시지를 분산시켜 시스템의 부하를 균형 있게 분산한다.내결함성 : 메시지를

이해하기 복잡해 보일 수 있지만, 간단하다.주문을 생성하면, 해당 event를 exchange를 통해 product 큐로 메시지를 전송한다. 그리고 product service에서 payment 큐로 exchange를 통해 이벤트를 전달한다.여기서 각 서비스에서 오류가

kumoh-talk 프로젝트를 진행하면서 권한에 대해 고민할 부분이 생겼었다.이처럼 처음 사용자 추가 정보를 작성하거나, 세미나 신청폼을 작성한다면 -> 스터디/프로젝트 글을 작성하거나, 신청가능하며 세미나 요약 글 작성이 가능하게 되는 구조를 가지고 있다.처음에는 각

이젠 MSA 라고 한다면 정답이 없다고 무방할 정도로 많은 선택지가 존재하고, 그 선택지 중에서 가장 자신의 프로젝트에 맞는 선택을 하면 된다고 생각한다.그 중에서 인증/인가 처리에 대한 얘기를 해보자 한다.현 진행 프로젝트의 초기 아키텍처 구상 구조이다.인증/인가 측

soft-delete 적용 이유?실제 서비스를 운영하는 프로젝트 개발하면서 사용자가 테러 이후 회원 탈퇴 처리를 해서 아무런 정보를 확인할 수 없다거나, 사용자가 게시글 같은 자료를 잘못 삭제한 경우에 대해 운영자 측에서 복구해 줄 수도 있게 soft-delete를 사

나는 처음 보는 도메인 지식에 대해 쉽게 이해하기 힘들거나, 특정 기능의 flow를 다른 개발자나 일반인들에게 설명하기에 시퀀스 다이어그램이 가장 쉽게 이해가능하다고 생각한다.그 중에서 Mermaid라는 웹 에디터를 통해 쉽게 작성한 후기를 쓰려 한다.https&#x3

백엔드 개발자라면 기능을 개발하고, 실제 controller에 http 요청을 보내기 위한 툴로 Postman을 가장 많이 사용하고 있을 것이다.이번 글에선 Postman에서 제공하는 Flows 라는 기능을 사용해본 후기를 작성하려 한다.https://blog

lock 중에서 낙관적 락 (Optimistic Lock), 비관적 락 (Pessimistic Lock), 분산 락(Distributed Lock)에 대해서 알아보고 실습해보았다. 이라는 가정을 들고, 구현해보았다.여기서 @Version 필드를 통해 낙관적 락에 사용될

Rate Limiting 은 특정 시간 내에 트래픽의 처리율(rate)을 제어하기 위한 장치이며, 단위 시간 동안 얼마만큼의 실행을 허용할 것인지 제한하는 매커니즘을 가지고 있다.서버가 제공할 수 있는 자원에는 한계가 있기 때문에 안정적으로 서비스를 제공하기 위해 사용

오늘 라즈베리파이 3대가 다 설치되어서 쿠버네티스 클러스터를 한 번 구축해보려다가 kubespray 설치하는데만 몇 시간을 쓴지 모르겠다..24단계 실습으로 정복하는 쿠버네티스 책을 기반으로 따라하고 있었는데, 아무래도 나온지 조금 된 2022년 책이다 보니 옛날 버전