doongu doongu

(멘토링 예시를 위해 작성된 게시글입니다.)1. 프로세스란?프로세스는 운영체제로부터 자원을 할당받아 실행하는 작업의 단위운영체제로부터 주소 공간, 파일, 메모리 등을 할당받는다스택, 힙, 데이터, 코드로 구성된 프로세스 메모리를 갖는다.프로세스 상태: New, Running, Waiting, Ready, Teminated 2. 프로세스의 상태란?총  New, Running, Waiting, Ready, Teminated 5가지를 가진다. new -> 프로세스 생성중인 상태커널에 PCB가 만들어진 상태 ready  -> 프로세스가 CPU를 기다리는 상태ready상태를 가지는 프로세스는 여러개가 될 수 있으며, CPU를 받게 된다면 바로 실행 가능한 상태 running -> 프로세스가 CPU를 할당받아 명령..

blue-greem배포를 nginx를 활용해 진행하고자 한다. 우선 많은 사람들이 위와 같은 구조로 무중단 배포를 개발했다. 그런데 하나 의문점이 드는 건, nginx를 reload 할 때에 정말 멈추지 않는가? 였다. 안정적인 서버 배포를 위해 nginx를 계속해서 공부하기 시작했고 nginx아케텍처 구조에서 오는 안정성을 배우게 되었다. nginx는 master process가 있고 worker process가 있다. 그리고 connection 형성, 제거, 새로운 요청을 처리하는 ‘이벤트’ 중심 구조로 동작한다. 그렇기에 process수가 적으며, woker process에게 큐 형식으로 이러한 이벤트들을 커널이 제공해 준다. 그래서 worker process가 쉬지 않고 일한다는 장점이 있다. 그..

프로젝트를 진행하다보면 늘 부딪히는 문제가 재정적인 문제이다. 항상 느끼지만 컴퓨터와 관련 된 것은 재정적인 것과 연관이 깊다. 예를들어 컴퓨터를 맞춰도 "당연히" 비싼 컴퓨터를 사면 빠르고 좋다. 우리가 고민하는 것은 "현재 상황에 맞는" 컴퓨터일 것이다. 마찬가지로 프로젝트를 진행할 때에도 현재 상황에 맞는 구성을 해야만 한다. 놓인 상황 : 1. 프론트엔드만 개발된 프로젝트였고, AppStore에 출시되어 이미 사용자가 있었다. 나를 포함한 2명이 여기에 합류하게 되어 백엔드 시스템 구축을 맡게 되었다. 2. 아직 수익창출이 되지 않았다. 놓인 상황으로 생각한 점 : - 규모에 비해 적은인원의 백엔드 개발 인원이 구성되었다고 생각했다. - 재정적인 한계가 있다. - 이미 사용자가 있기 때문에 백엔드..

기존에는 Monitoring을 위해 아래와 같은 구조를 많이 사용했습니다.(OTEL기준) 각 observability에 대응하는 제품을 사용했습니다. Trace : Grafana Tempo Metrics : Prometheus Logs : Loki 이렇게 하는 이유는 오랫동안 Grafana + Premetheus를 업계 표준으로 사용해 왔고, 그런 다음 다른 observability를 다루는 제품들이 등장해 위와 같이 '분산'된 구조를 사용하게 되었습니다. Time Series DB, Trace DB, Column Stores를 통합할 수는 없을까요? 이를 통합하게 된다면 분명 확장성에 이득이 있을 것이라고 생각했습니다. 각 3종류의 DB를 확장하는 것 보다 통합한 하나의 DB를 확장하는 것이 쉽다고 생..

ClickHouse로 일원화하여 아래와 같은 구조를 형성했었는데, Grafana에서 대시보드를 구성한 내용을 소개하고자 합니다. 우선 Grafana에 아래와 같은 ClickHouse Plugin을 설치해야 DataSource로 ClickHouse룰 사용할 수 있습니다. 목차 1️⃣ Service Graph 2️⃣ Service OverView 3️⃣ Requests Rates 4️⃣ Response Times 5️⃣ Error Rates 6️⃣ CPU Usage 7️⃣ Memory Usage 8️⃣ Disk Usage 9️⃣ Traces ( + Traces Details ) 🔟 Summary 대시보드 구성 및 쿼리문 설명 1. Service Graph 1-1. nodes otel_traces 테이블에서 ..

목차 1️⃣ 개요 2️⃣ 테스트 환경 3️⃣ 스키마 및 데이터 설정 4️⃣ 테스트 진행 및 결과 5️⃣ 결론 6️⃣ ISSUE 1️⃣ 개요 Partitioning이란? 파티셔닝은 큰 테이블이나 인덱스를 작은 파티션(Partition) 단위로 나누어 관리하는 기법을 뜻한다. Vertical Partitioning ( 수직 ) 장점 자주 사용하는 칼럼을 분리하여 성능을 향상할 수 있다. 같은 타입의 데이터가 저장되어 데이터 압축률을 높일 수 있다. 조회 시 필요 없는 칼럼을 조회하지 않아도 되므로 성능상의 이점이 있다. 단점 데이터를 찾는 과정이 기존보다 복잡하므로 Latency가 증가한다. Horizantal Partitioning ( 수평 ) 장점 데이터의 개수를 기준으로 나누어 파티셔닝 한다. 데이터의..

목차 1️⃣ 개요 2️⃣ 성능 측정 환경 3️⃣ Python3로 데이터 넣기 4️⃣ 테이블 스키마 5️⃣ 테스트 결과 6️⃣ 결론 7️⃣ ISSUE 및 느낀 점 8️⃣ 간단한 외주가 들어와서.. 무료로 진행했는데, DB 시니어 개발자 만나서 간단한 이야기를 나누었다. 1️⃣ 개요 빠르다는 의견, 느리다는 의견이 분분한데, 종결하고 싶다. 테이블 조인 하면 느리다? 다음의 1번과 2번 중 어느쪽이 더 빠를까요? 1. Join이 빠르다. select A.userno, A.name, B.guildname from [user] A JOIN guild B ON A.guildno = B.guildno 2. Join하지 않는 것이 빠르다. select userno, name, guildname from [user] ..

목차 1️⃣ 개요 2️⃣ 테이블 구성 3️⃣ 컬럼 데이터 구성 4️⃣ 결과 5️⃣ user를 찾을 때(두 번째 요소) composite_index가 더 느린 이유가 뭘까? 실행 계획을 보자. type=range와 type=ALL이 여기서 어떻게 동작과정이 다를까? Optimizer가 왜 저런 type을 지정했을까? 좀 더 구체적으로 알아보자. 6️⃣ composite_index의 앞의 요소를 모두 1로 적용하면 어떻게 될까? 7️⃣ 결론 1️⃣ 개요 복합키에 대한 index가 유의미 한지 궁금하다. 이번 테스트에서는 (career, user) 이렇게 index(clustered index)를 이루는 경우, user를 찾을 때 유의미 한지 테스트해 본다. 2️⃣테이블 구성 비교를 위해 (career)만 i..