본문 바로가기

전체 글

 (17)
이벤트 주도 아키텍처(EDA)와 API: 어떤 걸 선택해야 할까? 오늘은 이벤트 주도 아키텍처(EDA)에 대한 이야기를 나누려 합니다. 이벤트 주도 아키텍처는 한번씩 들어봤을 수 있으실텐데요. 이름에서도 알 수 있듯 이벤트를 생성하고 소비하는 방식으로 동작하는 아키텍처 패턴입니다. 사실 궁금한 것은 EDA가 왜 필요할까? 입니다. 기존 아키텍처에서는 서비스 간 연결방식은 API였어요. 필요한 것이 있으면 API로 요청하고, 응답을 받아 나머지 일들을 처리하는 방식이죠. 이 방식은 직관적이고, 시스템의 전체 흐름을 이해하기 쉬웠습니다만 몇가지 한계를 가지고 있었습니다. 1. 요청처리 실패 소비자의 요청이 급격히 증가하면 생산자가 실패를 리턴하거나 서비스불능 상태가 될 수 있습니다. 2. 동기 처리 생산자에서 처리가 완료될 때까지 소비자가 기다려야 합니다. 3. 의존성 생..
CQRS 패턴 오늘은 CQRS(Command and Query Responsibility Segregation, 명령과 쿼리 책임 분리) 패턴에 대해 이야기해보도록 하겠습니다. 아마도 많은분들이 이 패턴에 대해 들어보지 못했을 수 있는데요. 그렇다고 CQRS 패턴이 신세계 같은 존재는 아닙니다. 이미 많은 기업에서 CQRS를 적용하여 복잡한 데이터 처리 문제를 효율적으로 해결하고 있습니다. CQRS는 원래 데이터를 생성하고 처리하는 방식을 분리하는 것을 의미하는 패턴입니다. 말 그대로 명령(Command)과 쿼리(Query)의 책임을 분리한다는 것입니다. 즉, 데이터의 상태를 변경하는 명령과 데이터를 조회하는 쿼리를 각각 별개의 모듈 혹은 오브젝트로 취급합니다. 이 패턴은 Martin Fowler와 Greg Young..
Bulkhead 패턴 선박은 여러 개의 독립적인 구역으로 나눠져 있고, 한 구역에서 문제가 발생해도 다른 구역에는 영향을 끼치지 않는 설계를 가지고 있습니다. 이 Bulkhead는 선박 한쪽에 큰 구명이 뚫려도 손상을 최소화해 여전히 항해를 할 수 있게 해주죠. 여기서 영감을 받은 것이 'Bulkhead Pattern'입니다. Bulkhead Pattern은 소프트웨어 설계 패턴 중 하나로, 논리적으로 서로 다른 작업을 분리하고, 실패가 전체 시스템에 영향을 미치지 않도록 격리하는 것을 목표로 합니다. 마이크로서비스 아키텍처에서 서로 다른 서비스 간에 공유 자원에 대한 액세스를 제한하여 특정 서비스에서 발생한 문제가 전체 시스템에 영향을 미치는 것을 방지하는 역할을 하죠. Bulkhead Pattern은 사실 Fault To..
서비스 메시 클라우드 네이티브 환경에서 서비스 간의 통신을 관리하는 것은 복잡한 일이 될 수 있습니다. 컨테이너와 마이크로서비스를 도입하면 하나의 애플리케이션은 수많은 서비스로 나뉘게 되고, 각 서비스는 제각각 확장되기도, 재시작되기도 합니다. 이러한 환경에서 안정적인 서비스 운영을 위해 '서비스 메시'라는 개념이 중요해지고 있습니다. 서비스 메시란? 서비스 메시는 마이크로서비스 아키텍처에서 서비스 간의 통신을 관리하는 인프라 계층입니다. 일반적으로 서비스 메시는 서비스 간의 모든 네트워크 통신을 중재하고, 보안, 로드 밸런싱, 장애 복구, 메트릭 및 로깅 등의 기능을 제공합니다. 덕분에 개발자들은 좀 더 비즈니스 로직에 집중할 수 있게 되죠. 하지만 이런 설명으로는.. 저도 잘 이해되지 않습니다. 한번 예시를 들어..
Amazon API Gateway vs API Gateway 직접 구현 API 게이트웨이는 마이크로서비스 아키텍처의 핵심 구성요소입니다. API 요청을 처리하고 적절한 서비스로 라우팅하는 역할을 하죠. API 게이트웨이패턴에 대해 궁금하시다면 여기서부터 탐독하시면 좋습니다. 오늘은 Amazon API Gateway와 직접 구현한 API Gateway를 비교해 보고, 각각의 장단점을 알아보겠습니다. Amazon API Gateway Amazon API Gateway는 AWS에서 제공하는 완전관리형 서비스로 개발자들이 손쉽게 API를 생성하고 배포할 수 있게 해줍니다. 대표적으로 Netflix, Twitter, Airbnb와 같은 기업들이 Amazon API Gateway로 이동하는 추세를 보이고 있습니다. 장점 1. 간편한 관리 Amazon API Gateway는 서버와 인프..
서비스 디스커버리 패턴 서비스 디스커버리 패턴(Service Discovery Pattern)은 마이크로서비스 구조에서 중요한 역할을 하는 디자인 패턴입니다. 클라우드 기반 인프라에서는 수백, 수천 개의 서비스가 동시에 운영되고, 각각의 서비스는 동적으로 확장하거나 축소할 수 있습니다. 이런 복잡한 시스템에서, 어떤 서비스가 어디에 있는지, 어떻게 연결할 수 있는지를 찾아내는 것이 쉬운 것은 아닙니다. 이 때 한 서비스가 다른 서비스를 찾아 연결하는 것이 '서비스 디스커버리'입니다. ​ 그런데 말입니다.. DNS에 IP를 여러개 붙여놓으면 되는 것 아닐까요? 왜 굳이 서비스 디스커버리가 필요한 걸까요? 쿠버네티스의 '서비스'가 바로 그 필요성을 설명하는 단적인 예입니다. ​ 참고로 쿠버네티스는 컨테이너화된 애플리케이션의 배포,..
API 게이트웨이 - Rate limit 지난 번에는 API 게이트웨이에서의 인증에 대해 살펴봤는데요, 이번에는 rate limit에 대해 알아보겠습니다. ​ rate limit은 간단히 말하면 서비스에 대한 요청 수를 제한하는 기술입니다. 일정 시간 동안 특정 클라이언트(또는 전체 시스템)가 서버에 보낼 수 있는 요청 수를 제한함으로써, 서비스가 과부하 상태로 진입하는 것을 방지합니다. ​ 이렇게 말해서는 와닿지 않으실 겁니다. 제가 rate limit이 왜 필요한지 예시를 들어보겠습니다. 상상해봅시다. 여러분이 카페의 사장입니다. 훌륭한 바리스타들과 맛있는 커피를 보유하고 있죠. 하지만 한 고객이 들어와서 1분에 한 잔씩 커피를 주문하기 시작했습니다. 매우 열심히 일하고 있는데도 불구하고, 이 고객의 요청을 처리하는 동안 다른 고객들은 커피..
Spring Boot를 이용한 OAuth 2.0 인증 구현 지난 시간에는 OAuth 인증의 개념과 그 동작 방식에 대해 알아보았습니다. 이번 포스트에서는 인기 있는 백엔드 프레임워크인 Spring Boot를 사용하여 OAuth 2.0 인증을 어떻게 구현하는지 알아보도록 하겠습니다. 1. 의존성 추가하기 먼저, 프로젝트에 필요한 의존성을 추가해야 합니다. `pom.xml` 파일에 아래의 내용을 추가합니다. org.springframework.boot spring-boot-starter-security org.springframework.boot spring-boot-starter-oauth2-client 2. Google에 앱 등록 Google에 앱을 등록하고, 사용자가 구글을 통해 로그인을 하면 우리는 그 토큰을 받아 인증하도록 하겠습니다. 우선 구글Google..

티스토리툴바