1. 서론현대의 분산 시스템에서는 다양한 메시징 시스템이 존재하며, 각 시스템은 특정 요구사항에 따라 장점과 단점을 보입니다.이 글에서는 대표적인 세 가지 메시징 솔루션—Kafka, Redis Pub/Sub, 그리고 전통적인 메시지 큐(RabbitMQ, ActiveMQ 등)를 비교하면서,어떤 상황에서 어떤 시스템을 선택하는 것이 유리한지 실제 구현 예제와 테스트 결과를 통해 살펴보겠습니다.2. 메시징 시스템 개요 및 특징2.1 Kafka특징 및 아키텍처:고처리량, 확장성, 내구성(영속적인 로그 저장)토픽, 파티션, 오프셋 관리 방식을 통해 메시지 순서와 병렬 처리를 효과적으로 지원단일 파티션 내에서는 메시지 순서가 보장됨 (동일 키 사용 시)장점:대규모 데이터 스트림 처리에 적합높은 처리량과 확장성, 장..
전체 글
Spring 프레임워크를 2.x 버전에서 3.x로 마이그레이션하는 과정에서 예상치 못하게 여러 이슈가 발생해 롤백을 했던 경험이 있었습니다. 이번 블로그 포스트에서는 실제로 발생했던 CORS 이슈 및 기타 주요 문제와 이를 해결했던 방법에 대해 공유하고자 합니다. 1. CORS 이슈 배경Spring 3.x로 마이그레이션한 이후, 프론트엔드와 백엔드 간 통신을 시도할 때 CORS 관련 오류가 발생했습니다. 브라우저 콘솔에는 다음과 같은 오류 메시지가 나타났습니다:CORS redirect is not allowed for a preflight request. Spring 2.x 였을 때는 특별한 설정없이 cors 이슈가 없었는데, 버젼 문제일 거라고 생각을 하고 어떻게 해결할 것인지 생각을 해보았습니다. ..
배경현재 회사에서 FastAPI를 쓰고 있다. 자바를 전문적으로 쓸 수 있는 개발자도, 팀장님도 잘 모르시는 상황이기에 (혹은 여러가지 이유로 인해) 자바가 아닌 상대적으로 다루기 쉬운 파이썬을 사용하고 있으며, 그 중에 FastAPI 프레임워크를 사용하고 있고 앞으로도 그렇게 사용할거 같다. 둘 다 사용해본 입장에서 성능 측면에서는 컴파일러이니까 springboot가 fastapi보다 빠르다고 생각은 하지만 얼마나 성능차이가 날까 궁금해서 한 번 직접 더미 데이터로 실험을 해보려고 한다. 컴퓨터 사양은 다음과 같고더보기프로세스 : 12th Gen Intel(R) Core(TM) i7-12700F (20 CPUs), ~2.1GHz메모리 : 16384MB Springboot와 FastAPI에 대한 사..
배경 내가 운영하고 있는 서비스가 실서버에 배포 및 운영을 하는 상태인데, 회사 내부 상품 정보를 많이 가져오면서도 처리속도를 빠르게 하기 위해 API 내부에는 ExecutorService 라는 객체를 쓰면서 멀티쓰레드를 활용해 여러번 API 호출하는 부분이 있었는데, 그걸로 인해 힙 메모리가 일정비율로 채워졌음에도 불구하고 GC가 제대로 일어나지 않은 것처럼 보이고 힙 메모리 사용량 70% 이상임에도 계속 늘어나는 메모리 누수가 일어나는 현상이 일어나고 있었다. 현재 다른 서비스 개발에 집중을 하고 있어서 왜 그런지에 대해서 명확히 찾지를 못했채, 힙 메모리 사용량 일정 비율에 의해 모니터링 알람 울리면 강제로 GC 명령어를 입력해서 임시방편으로 대응하고 있다. 원인 파악 내가 생각한 메모리 누수 원인..
MSA의 장점 **유연성과 확장성**: 각 마이크로서비스는 독립적으로 개발되고 배포될 수 있기 때문에, 필요한 서비스만을 선택적으로 확장할 수 있습니다. 이는 시스템 전체의 확장성을 크게 향상시킵니다. **개발 효율성의 증가**: 서비스가 작고 분리되어 있어 개발자들이 더 빠르게 개발하고 테스트할 수 있습니다. 다양한 프로그래밍 언어와 기술 스택을 사용할 수 있는 유연성도 제공합니다. **고장 격리**: 한 서비스의 실패가 전체 시스템을 다운시키는 것을 방지합니다. 오류가 발생해도 해당 서비스만 영향을 받고, 시스템의 나머지 부분은 정상 작동을 계속할 수 있습니다. **배포 용이성**: 각 마이크로서비스는 독립적으로 배포될 수 있어, 새로운 기능을 빠르게 시장에 출시하고, 버그 수정을 신속하게 반영할 수..
Runnable 인터페이스 Runnable 인터페이스는 매우 단순합니다. 단 하나의 메서드, void run()을 정의하며, 이 메서드는 반환 값도, 예외도 없습니다. 이는 Runnable이 작업 실행의 단순함을 반영하며, 실행 결과나 오류를 직접 반환하지 않습니다. 결과적으로, Runnable 구현체는 별도의 로직(예: 공유 객체를 통한 결과 저장)을 통해 결과를 관리해야 할 수도 있습니다. Runnable은 직접적으로 스레드를 생성하고 실행할 때, 혹은 Executor Framework를 사용하여 스레드 풀에 작업을 제출할 때 사용됩니다. public class RunnableExample implements Runnable { @Override public void run() { // 실행하고자 하..
SHA-1: 이제는 지나간 보안 기준 SHA-1은 160비트의 해시 값을 생성하는 알고리즘으로, 한 때는 디지털 서명, SSL 인증서, 소프트웨어 패키지 검증 등에 널리 사용되었습니다. 하지만 2017년, Google과 CWI Amsterdam의 연구팀이 SHA-1 충돌을 성공적으로 시연하며, 이 알고리즘의 취약성이 명확하게 드러났습니다. 이후로 SHA-1은 더 이상 안전하지 않은 것으로 간주되며, 새로운 프로젝트나 시스템에서의 사용이 권장되지 않습니다. SHA-2: 강화된 보안성을 제공하는 현대의 선택 SHA-2는 SHA-1의 후속으로 개발되었으며, 224, 256, 384, 512비트 등 여러 버전의 해시 값을 생성할 수 있는 능력을 가집니다. 이 알고리즘은 현대의 보안 요구사항을 충족시키며, 현재 ..
보안은 디지털 세계에서 가장 중요한 요소 중 하나입니다. 데이터의 무결성과 인증은 모든 소프트웨어 개발 프로젝트에서 우선시되어야 합니다. 이러한 보안 요구 사항을 충족하기 위해 HMAC(Hash-based Message Authentication Code)이 널리 사용됩니다. 이 블로그 글에서는 HMAC의 기본 개념, 작동 방식 및 개발자가 이를 알아야 하는 이유를 살펴보겠습니다. HMAC이란 무엇인가? HMAC은 특정 데이터의 무결성과 인증을 보장하기 위해 해시 함수를 사용하는 메시지 인증 코드입니다. 이는 데이터가 전송 중에 변경되지 않았으며, 신뢰할 수 있는 소스로부터 왔음을 확인하는 데 사용됩니다. HMAC 구현은 두 가지 주요 구성 요소에 의존합니다: 강력한 암호화 해시 함수(예: SHA-256..
서론: 인터넷 상에서 안전한 정보 교환은 어떠한 웹 서비스에서도 필수적인 부분입니다. 이를 위해 개발된 다양한 기술 중 하나가 바로 JWT (JSON Web Token)입니다. JWT는 간결하고 자가 수용적인 방법으로 정보를 안전하게 전달할 수 있게 해줍니다. 본 글에서는 JWT의 기본 구조와 그것이 어떻게 작동하는지에 대해 알아보겠습니다. JWT의 구조: JWT는 크게 세 부분으로 구성되어 있습니다: 헤더(Header), 페이로드(Payload), 그리고 서명(Signature). 각 부분은 점(.)으로 구분되며, Base64Url 인코딩 방식으로 인코딩됩니다. 헤더(Header): 헤더는 토큰의 타입과 사용된 알고리즘에 대한 정보를 담고 있습니다. 예를 들어, 알고리즘은 HS256이나 RS256과 같..
mcrouter의 기본 라우팅 기법 mcrouter를 사용하면서 특별한 설정을 하지 않았다면, mcrouter는 다음과 같은 기본 또는 가장 일반적인 라우팅 설정을 사용하게 됩니다: Consistent Hashing: 분산 캐시 시스템에서 널리 사용되는 라우팅 방식으로, 키를 기반으로 요청을 캐시 서버에 일관적으로 분산시킵니다. Pool Route: 캐시 서버들을 그룹화하여 구성된 풀을 통해 요청을 라우팅합니다. 이는 가장 기본적인 형태의 라우팅 설정입니다. 설정 파일을 통한 라우팅 기법 확인 및 조정 mcrouter의 동작은 설정 파일을 통해 세부적으로 조정할 수 있습니다. JSON 형식의 이 파일에서는 서버 풀, 라우팅 정책, 복제 및 샤딩 설정 등을 포함하여 다양한 옵션을 지정할 수 있습니다. 설정..