개발새발

UPS(Uninterruptible Power Supply, 무정전 전원 장치)는 정전이 났을 때 배터리로 잠깐 동안 전기를 대신 공급해주는 장치입니다. 그런데 UPS는 단순히 전기만 흘려보내는 게 아니라, 컴퓨터에게 자기 상태를 실시간으로 보고합니다. (예: 배터리 잔량, 입력 전압 등)이 보고가 어떻게 이루어지는지, USB 표준 차원에서 의외로 흥미로운 구조가 숨어 있어서 정리해보려고합니다. 1. UPS와 컴퓨터는 두 가닥으로 연결UPS와 컴퓨터 사이에는 보통 두 개의 케이블이 동시에 연결됩니다.두 채널이 물리적으로 완전히 독립이라는 것입니다. USB가 빠져도 전기는 흐르고, 정전이 나도 USB는 잘 통신합니다(배터리 모드). 같은 케이블에 못 흐르는 완전히 다른 흐름이라 분리되어 있습니다. 2. U..

한 모델에 모든 걸 맡길 것인가, 여러 모델이 역할을 나눠 협업하게 할 것인가. 멀티 에이전트는 후자입니다. 그 순간 "누가 누구에게 일을 넘기고, 누가 감독할지"를 정해야 합니다. 그게 아키텍처 패턴입니다.왜 단일 호출로는 부족한가혼자 쓰고 혼자 검수한 글에는 빈틈이 남습니다. 다른 눈이 한 번 더 들어가야 잡힌다. 단일 모델도 마찬가지입니다. 자기 답을 스스로 검증할 동기도 능력도 부족합니다. 틀려도 모릅니다.멀티 에이전트는 이걸 분업으로 풉니다. 한 에이전트가 답을 만들면, 다른 에이전트가 검증하고, 또 다른 에이전트가 다듬습니다. 토론과 합의로 품질을 끌어올리는 것, 즉, 하나의 결과를 여러 에이전트가 토론과 합의로 검증하는 것입니다. 4가지 패턴1. 단일 에이전트(Single Agent) 사용..

ServerDB장점1. 수평 확장 좋음(서버 확장 설계 쉬움)2. 프레임워크로 수정 용이1. 네트워크 트래픽 저하2. 복잡한 쿼리 연산 속도 최적화 가능단점1. DB왕복 증가시 latency 상승2. CPU, Memory, IO부하(But, 캐싱 처리, 비동기 처리로 해결 가능)1. 소스코드와 같이 레이어가 나눠있지 않아 가독성이 낮다.(즉, 수정이 어렵다. ex. 프로시저)2. 서버 확장시 설계 난이도 Up Server의 역할비즈니스 로직 실행- 요청 검증/인증/권한 검사, 도메인 규칙 처리- 계산/변환/비즈니스 워크 플로우API 제공- REST/GraphQL 엔드포인트, gRPC 서비스- 입력값 파싱/응답 직렬화(JSON/XML 등)외부 연동- 메시지 큐(Kafka, RabbitMQ), 외부 API ..

이 글에서는 Redis를 안정적으로 적용하기 위한 구성 방식, 특히 Sentinel과 HAProxy를 활용한 고가용성 아키텍처에 대해 단계적으로 알아보려 합니다.들어가기에 앞서, HAProxy가 필요한 이유부터 차근차근 살펴보겠습니다.1. 배경 지식1-1. OSI 7 Layer 1-2. Redis란?인메모리 기반의 고속 Key-Value 저장소(다양한 자료구조를 지원하는 NoSQL DB) 1-3. HAProxy vs Nginx 비교개인적으로 Nginx와 HAProxy의 차이가 궁금해서 찾아보았습니다. 차이점은 아래와 같이 HAProxy와 Nginx 각각이 주로(강점) 역할을 수행하는 곳이 L4, L7로 서로 달랐습니다. 1-4. HAProxy란?먼저, 간단하게 HAProxy는 부하 분산(Load Bala..

JVM 메모리 누수가 나는 이유와 상황에 대해 작성해 보려고 한다.먼저, JVM의 구조, 동작 방식 등을 알아보고 마지막에 상황을 가정하고 테스트 해볼 예정이다.1. JVM 동작 방식1. 프로그램 실행시 JVM은 OS로부터 메모리를 할당받는다.2. 자바 컴파일러(javac)가 소스코드(.java) -> 바이트 코드(.class) 컴파일3. Class Loader는 동적 로딩을 통해 필요한 클래스들을 로딩 및 링크 하여 Runtime Data Area(실질적인 메모리를 할당 받아 관리하는 영역)에 올린다.4. Runtime Data Area에 로딩 된 바이트 코드는 Execution Engine을 통해 실제 기계어로 변환(인터프리터, JIT)4-1. Execution Engine에 의해 Garbage C..

1. 운영체제 기본 구조 2. 메모리(Memory) 3. 프로세스(Process) & 스레드(Thread) 4. 동기화(Synchronization) 5. 가상 메모리(Virtual Memory)6. 페이징(Paging)7. 파일 시스템(File System)7-1. FAT File System

문제 정의게시판의 데이터가 많아질수록 DB에서 게시판을 불러오는 속도가 느려지는 상황 발생예상 원인Full Table Scan으로 인해 속도가 느려진다.인덱스 미사용으로 인한 비효율적인 검색디스크 I/O 증가 기술 선정기술설명장점Hash Index특정 값(=)에 대해 해시 테이블을 생성하여 빠르게 검색'=' 검색 속도가 빠름Full-Text Index긴 텍스트(TEXT, VARCHAR)에서 키워드 검색을 빠르게 수행특정 키워드 검색 최적화B+ Tree Index범위 검색(>, 특정 범위 검색에 효과적  B+ Tree 인덱스 선정 이유기존에 사용하고 있는 MariaDB에서 기존 테이블을 변경하지 않으면서, 범위 검색 성능을 최적화하기 위한 최적의 선택지는 B+ Tree 인덱스라고 생각하여 B+ Tree 기..

1. 문제 - DB 병목 현상 및 성능 저하모든 읽기(조회)와 쓰기(저장) 작업이 단일 데이터베이스(DB)에서 수행되면, 트래픽 증가 시 심각한 병목 현상이 발생높은 동시 요청 처리 시 DB 부하 증가, 응답 속도 지연, 트랜잭션 충돌 증가, 서비스 장애 가능성 증가캐싱(Redis)이 적용되어도, 근본적인 읽기/쓰기 처리 구조를 개선하지 않으면 한계가 존재 2. 원인 - 단일 DB 구조의 한계읽기(SELECT)와 쓰기(INSERT, UPDATE, DELETE) 요청을 같은 DB에서 처리함으로써 트랜잭션 경쟁 발생읽기 트래픽(조회)이 과도할 경우, 쓰기 성능이 저하됨Redis 캐싱이 적용되더라도 DB 요청을 완전히 줄이지 못함 → 근본적인 읽기/쓰기 분리가 필요함CQRS(Command Query Resp..

문제 정의데이터 조회 시 속도가 느려 서비스 성능 저하반복적으로 동일한 요청이 발생하여 서버 부하 증가불필요한 DB 트래픽으로 인해 성능 저하 및 운영 비용 상승 원인데이터베이스의 조회 시간이 길어지는 경우동일한 요청이 빈번하게 발생하지만 캐시를 활용하지 않는 경우트래픽이 급증하는 순간에도 모든 요청이 DB에 직접 접근하는 구조캐시 없이 매번 데이터를 연산하여 조회하는 구조 해결목표 설정불필요한 트래픽을 줄이고, 서버의 부하 감소빠른 처리성능(조회)을 확보하여 고객에게 더 나은 서비스경험을 제공TTL(Time To Live) 설정주요 캐싱 대상 선정 캐싱 전략을 사용하기 전 주의 사항"용도에 맞지 않는 정보나 서비스요청에 캐시를 남용하게 되면 서비스 신뢰도에 큰 문제가 생길 수 있는 위험성을 내포한다."..