유성

코어 수와 쓰레드 수의 관계는 멀티스레드 프로그래밍에서 성능 최적화의 핵심 요소입니다. 쓰레드 수가 특정 코어 개수와 맞지 않을 때 성능이 저하되는 이유는 여러 가지가 있으며, 이는 CPU가 수행하는 컨텍스트 스위칭, 메모리 대역폭 문제, 그리고 CPU 코어의 오버헤드와 관련이 있습니다. 이를 구체적인 예시로 살펴보겠습니다. 1. 코어 개수와 쓰레드 개수의 관계CPU는 보유한 코어 수만큼 작업을 동시에(병렬성) 수행할 수 있습니다. 예를 들어, 4개의 코어가 있는 CPU는 이론적으로 최대 4개의 쓰레드를 동시에 실행할 수 있습니다. 이보다 많은 쓰레드가 실행될 경우, 운영 체제는 TCB(Thread Control Block)을 사용해 각 쓰레드의 상태를 저장하고 복구하면서 컨텍스트 스위칭을 수행하게 됩니..

이 글에서는 기본적인 Application 서비스 환경에서 대규모 서비스로의 전환을 시간 순으로 나열해보겠습니다. 현재  시스템 구성현재 서비스는 1개의 Nginx 웹 서버와 2개의 Tomcat 애플리케이션 서버로 구성되어 있습니다.기존요청의 흐름사용자는 로컬 또는 DNS 서버를 통해 IP를 받아와 HTTPS(443 포트)로 요청을 보냅니다.요청은 웹 서버를 거쳐 애플리케이션 서버로 전달되고, 필요한 경우 데이터베이스(DB)에서 데이터를 가져와 사용자에게 응답을 전송합니다.HTTP 요청과 응답 구조를 따릅니다.대규모 서비스 전환 단계이제 각 컴포넌트의 성능을 높이고 트래픽을 효과적으로 분산하기 위해 시스템을 확장하는 단계를 살펴보겠습니다. 1. Database 의 Scale Up현재 DB 성능이 충분하지..

CachedThreadPool의 동작 방식과 한계Java의 CachedThreadPool은 다음과 같은 특성을 지니며 높은 처리량을 지원하지만, 동시 작업 수가 많을 때 주의가 필요합니다.  /** * 필요한 경우 새 스레드를 생성하지만, 기존에 생성된 스레드가 있으면 * 이를 재사용하는 스레드 풀을 생성합니다. 이 풀은 많은 짧은 비동기 작업을 * 수행하는 프로그램의 성능을 일반적으로 향상시킵니다. * {@code execute} 호출 시 기존에 생성된 스레드가 사용 가능하다면 이를 재사용합니다. * 사용 가능한 기존 스레드가 없으면 새 스레드를 생성하여 풀에 추가합니다. * 60초 동안 사용되지 않은 스레드는 종료되고 캐시에서 제거됩니다. * ..

의존성 역전의 원칙(Dependency Inversion Principle, DIP)은 객체지향 설계의 5대 원칙 중 하나로, 상위 수준 모듈이 하위 수준 모듈에 의존하지 않도록 하여 시스템의 결합도를 줄이고 유연성을 높이는 데 중점을 둡니다. 이 원칙은 애플리케이션이 변화에 쉽게 대응할 수 있도록 구조적으로 설계하는 데 중요한 역할을 합니다. 의존성 역전의 원칙(DIP)의 핵심 개념 DIP는 두 가지 주요 원칙으로 설명됩니다. 1. 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 된다.상위 수준 모듈은 애플리케이션의 비즈니스 로직을 담당하고, 하위 수준 모듈은 데이터베이스나 네트워크와 같은 구체적인 기능을 처리합니다. 상위 모듈이 하위 모듈에 직접 의존하면, 하위 모듈이 변경될 때 상위 모듈도 영향을..

좋은 코드를 작성하는 방법에 대해 많은 이론과 원칙이 있지만, 저는 특히 다음 5가지가 중요하다고 생각합니다. 1. SOLIDSOLID 원칙은 효과적인 소프트웨어 설계의 핵심입니다. 이 중에서도 '단일 책임 원칙(Single Responsibility Principle, SRP)'은 특히 중요합니다. SRP는 하나의 클래스가 단 하나의 책임을 가져야 한다고 말합니다.  이 원칙을 지키면 클래스 간의 복잡도가 줄어들고, 코드의 가독성과 유지보수성이 향상됩니다. 단일 책임 원칙을 통해 각 클래스의 목적이 명확해지며, 이는 전체 시스템의 이해와 확장성에 긍정적인 영향을 미칩니다. 2. 읽기 쉬운 코드좋은 코드인지 확인하는 방법은 아주 간단합니다.좋은 코드의 핵심 요소 중 하나는 바로 '읽기 쉬움'입니다. 다른..

개발 과정에서 복잡한 코드와 구조에 직면했을 때, SOLID 원칙은 강력한 지침이 됩니다.처음 들어본다면 다소 어려울 수 있지만, 이 원칙들은 깔끔하고 유지보수가 쉬운 코드를 작성하는 데 필수적입니다. Single Responsibility Principle 단일 책임 원칙단일 책임 원칙이라는 단어도 왠지 맘에 안듭니다.하나의 객체는 하나의 역할만 해야한다는 내용입니다.예를 들어, "요리사" 객체는 요리만 담당해야 하며, 웨이터의 역할인 "서빙"을 해서는 안 됩니다.객체가 여러 역할을 수행하면 단일 책임 원칙을 위반하게 됩니다. Open-Closed Principle 개방-폐쇄 원칙이름이 더 이해하기 어렵게 만드는 것 같습니다.새로운 기능을 추가할 때 기존 코드가 변경되면 안된다는 내용입니다.예를들어 쇼..

해당 내용은 샤딩에 대한 내용으로 비유적인 설명이 많습니다.이해를 위해서만 봐주시고, 더 궁금하신 내용은 댓글을 남겨주세요.     위에처럼 노트북을 보관해 주는 회사가 있고, 노트북을 1000대 보관할 수 있는 창고가 있습니다. 1. 데이터 분산 저장을 위한 새로운 창고의 추가 (샤딩)보관해야 할 1000대의 노트북이 추가로 들어와서 창고 B를 만들었습니다.창고 A와 B는 모두 노트북이 들어온 순서대로 보관을 하고 있습니다. 만약 고객이 창고에 들어와 노트북을 찾으려면 2000대의 노트북을 하나씩 확인해야만 합니다. 2. 최적화 전략 개발 (샤딩 키 구성)노트북을 찾는 시간이 너무 오래걸려, 시리얼 번호를 기준으로 분류합니다. 시리얼 번호는 한번 정해지면 변경되지 않는 값이므로시리얼 번호가 홀수로 끝나..

Kafka의 안전성과 복구 전략Apache Kafka는 대용량의 실시간 데이터 스트림 처리를 위한 분산 메시징 시스템입니다. Kafka의 안정성과 높은 가용성을 위해 여러 가지 전략과 구성 요소가 사용됩니다. 본 글에서는 Kafka의 주요 안전성 및 복구 전략에 대해 알아보겠습니다. 1. 데이터 복제Kafka는 데이터의 내구성을 보장하기 위해 각 Topic의 파티션을 여러 개의 복제본으로 구성합니다. 각 파티션은 주 브로커(리더)와 여러 팔로워 브로커(복제본)으로 구성됩니다.Producer가 데이터를 전송하면, 해당 데이터는 주 브로커에 저장되고, 주 브로커는 복제본 브로커들에게 데이터를 복제하여 저장합니다. 이렇게 복제된 데이터는 클러스터 내에 여러 브로커에 분산 저장되므로, 하나의 브로커가 장애가 발..

시스템이 성장함에 따라 단일 DB에서는 성능에 저하 또는 장애가 발생할 수 있습니다.이때 DB 구성 방식으로써 해결할 수 있는 방법을 순서대로 설명하겠습니다. * Scale Up첫 번째로 고려할 방법은 "스케일 업"입니다. 이는 기존의 컴퓨터 하드웨어(CPU, RAM, Disk 등)를 더 강력한 것으로 교체하는 방식으로, 기존의 애플리케이션 코드나 데이터베이스 구조를 크게 변경하지 않아도 됩니다.스케일 업은 초기 단계에 고려되는 이유는 기존 DB를 그대로 사용할 수 있으므로 하드웨어 리소스를 제외한 추가 비용이 들지 않기 때문입니다.그러나 Scale Up에는 한계가 있고, 시스템이 더 커진다면 다음 방법을 고려해야 합니다.* Scale Out다음으로 고려할 방법은 "스케일 아웃"입니다. 이는 데이터베이스..

메시지 기반 아키텍처는 대규모 및 복잡한 시스템에 아주 잘 맞는 설계 방식입니다. 이유는 다음과 같습니다. 1. 디커플링메시지 기반 아키텍처는 서비스간 결합도를 낮춥니다. 온라인 쇼핑몰로 예를 들겠습니다. 주문 시스템, 재고 관리 시스템, 배송 시스템 등 여러 서비스로 구성될 수 있습니다. 이 서비스들이 서로 밀접하게 연결되어 있다면, 각 시스템은 다른 시스템의 상태와 행동에 대해 알아야하며, 이는 시스템 간의 강한 결합을 의미합니다.예를 들어, 배송 시스템이 주문 시스템에 직접적으로 연결되어 있고, 주문이 이루어질 때마다 즉시 배송 프로세스를 시작한다면, 주문 시스템의 변경이 배송 시스템에 영향을 줄 수 있습니다. 주문 시스템에 문제가 발생하면 배송 시스템도 문제가 발생하거나, 주문 시스템의 로직이 변..