많은 서버는 HTTP 프로토콜을 이용해 클라이언트와 통신합니다. 이외에도 DB와 TCP 기반의 프로토콜을 사용하여 데이터 송수신을하게 됩니다. 서버의 API 에서도 네트워크 통신을 기반으로 동작합니다.이처럼 서버는 다양하고 많은 네트워크 통신 및 IO 처리를 하게 됩니다. 하지만 이러한 통신이 많아 지게되면, 이전의 처리되고 있는 I/O 요청을 기다리게되는 병목 현상이 생기게됩니다. 이러한 I/O 병목 해결문제를 "주니어 개발자가 반드시 알아야할 실무지식" 해당 책을 토대로 정리 해보았습니다. I/O의 병목은 왜 생길까?I/O 처리는 대체로 다음과 같은 특성을 갖습니다:블로킹(Blocking) 동작: 데이터 입출력이 완료될 때까지 스레드가 멈춰서 기다립니다.실행 시간의 대부분을 IO 대기에 소모합니..

동시성 데이터란 여러 작업(요청 또는 프로세스)을 동시에 처리하며 발생하는 문제말합니다. 이번 글에서는 서버가 동시성을 처리하는 방법과 도중에 발생할 수 있는 문제들 "주니어 개발자가 반드시 알아야할 실무지식" 해당 책을 토대로 정리 해보았습니다. 서버에서의 동시 실행 처리와 필요성100개의 요청을 처리한다고 가정해 보겠습니다. 1개의 요청을 처리하는 데 0.1초가 걸린다면, 순차적으로 처리하면 총 10초가 걸립니다. 하지만 동시에 10개씩 병렬로 처리할 경우, 처리 시간은 1초로 단축됩니다. 서버가 동시성을 처리하는 주요 방법은 크게 다음과 같은 두 가지로 나뉩니다:클라이언트 요청마다 스레드를 할당하여 처리비동기 I/O(Non-blocking I/O)를 사용하여 처리동시 처리의 장점을 살리는 것은 중..

동기 방식은 프로세스가 요청(Request)을 보내면 응답(Response)을 받을 때까지 기다리는 전통적인 방식입니다. 다음 코드가 실행되기 전에 이전 작업이 끝날 때까지 대기해야 하죠. 동기 방식의 장점직관적이고 이해하기 쉬움 : 코드를 순차적으로 따라가기 때문에 직관적이고 디버깅도 용이합니다.분석 툴 활용 가능 : 코드의 흐름을 그대로 쫓아가며 성능 이슈나 예외를 쉽게 파악할 수 있습니다.하지만... 외부 연동에서 문제가 생기면?외부 시스템(API, 데이터베이스 등)과 동기 방식으로 연동한 경우, 몇 가지 중요한 점을 고려해야 합니다:외부 연동 실패가 전체 기능에 끼치는 영향 : 예를 들어, 사용자가 회원가입을 하면 쿠폰을 발급한다고 가정해 볼게요. 쿠폰 발급은 외부 연동을 통해 이루어진다고 할 ..

서비스 자체는 문제가 없는데, 외부 연동 서비스의 트래픽 처리 한계로 인해 장애가 발생하는 경우가 많습니다.A 서비스는 외부 인증 정보를 얻기 위해 B 서비스에 연동 요청을 보냅니다.하지만 B 서비스가 몰려드는 트래픽을 감당하지 못하고, 응답을 제대로 주지 못합니다. (에러발생!!!)이처럼 연동 서비스의 문제를 완전히 차단하기는 어렵습니다.왜냐하면, 외부 연동이 필수적인 경우가 많기 때문이죠. 외부 연동이 모든 상황에서 완벽할 수는 없기에, 이에 대비한 전략이 필요합니다.이 글에서는 외부 연동에서 발생할 수 있는 문제 상황과 이를 해결하는 방법을 "주니어 개발자가 반드시 알아야할 실무지식" 해당 책을 토대로 정리 해보았습니다. 타임아웃, 설정하셨나요?외부 연동에서 가장 중요한 설정 중 하나는 바로..

"왜 특정 쿼리의 성능이 이렇게 안 좋지? 어디서부터 잘못된 걸까?"개발자로 일하면서 누구나 한 번쯤 마주치는 상황입니다.원활했던 서비스에서 갑자기 데이터베이스 연결이 계속 끊기거나, 응답 시간이 급격하게 길어지는 경우 말입니다. 특히, 사용자 수가 서비스 피크 시간대라면 문제는 더욱 심각해집니다. 이 글에서는 이런 성능 문제를 인덱스 외에도 쿼리 조회 성능을 개선할 수 있는 방법을 "주니어 개발자가 반드시 알아야할 실무지식" 해당 책을 토대로 정리 해보았습니다. 집계 쿼리를 미리 계산해 저장하기데이터 조회 시점에 COUNT 나 SUM 같은 집계 쿼리를 실행하는 과정에서 성능 문제가 자주 발생합니다. 이는 트래픽이 몰릴수록 심각해지는데요, 이를 해결하는 가장 간단한 방법은 집계 데이터를 미리 ..

"왜 특정 쿼리의 성능이 이렇게 안 좋지? 어디서부터 잘못된 걸까?"개발자로 일하면서 누구나 한 번쯤 마주치는 상황입니다. 실제로 일주일에도 마주한 상황입니다 ㅜㅜ 원활했던 서비스에서 갑자기 데이터베이스 연결이 계속 끊기거나, 응답 시간이 급격하게 길어지는 경우 말입니다. 특히, 사용자 수가 서비스 피크 시간대라면 문제는 더욱 심각해집니다. 이 글에서는 이런 성능 문제의 주요 원인 중 하나인 데이터베이스 설계와 쿼리 최적화를 "주니어 개발자가 반드시 알아야할 실무지식" 해당 책을 토대로 정리 해보았습니다. 성능 저하의 원흉: "full Scan"이란?우리가 흔히 서비스 성능이 느려지는 이유 중 첫 손에 꼽히는 것이 바로 *풀 스캔* 입니다. 풀 스캔이란, 쿼리를 실행할 때 테이블의 모든 데이터를 ..

서버캐시DB 서버를 확장하지 않고 응답 시간과 처리량을 개선하고 싶다면 캐시 사용을 고려해보자.캐시에 데이터를 읽어오면 DB의 연동시간이 줄어 응답시간이 단축된다. 적중률 과 삭제 규칙캐시가 얼마나 효율적으로 사용되는지는 적중률도 판단할 수 있다. 100건의 요청중ㅇ 80건이 데이터가 캐시가 존재했다 그럼 이 적중률은 80퍼가 된다.그럼 캐시에 모두 넣으면 적중률이 높아져서 빨라지겠네?하지만 캐시는 메모리 자원을 사용하여 사용할 수 있는 용량의 한계가 있다.서버가 사용하는 캐시에는 크게 두가지가 있다로컬 캐시리모트 캐시 (우리가 주로 캐시할떄 사용하는 레디스 케시가 여기에 해당한다)로컬 캐시의 경우 서버 프로세스와 캐시가 동일한 메모리 공간에 사용되기때문에 빠르게 접근할 수 있따.하지만 서버와 같이 사용..

어제까지만 잘만 되던 서비스가 갑자기 느려졌어요 ㅜㅜ 어디부터 봐야할까? 어디가 느려졌는지 파악하자 응답시간 : API 호출 하여 전체 JSON을 응답 받을 때까지의 소요된 시간이 응답 시간- 주로 API 연동 + DB 연동 이 주 수행시간이다. - API 연동이 없는 경우에는 70~80퍼가 DB 연동시간임→ 이러하 이유로 응답시간을 줄일 때는 DB연동과 API 연동 시간을 줄이는 것에 집중해야한다. 처리량 : TPS : 초당 트랜잭션 수최대 TPS를 초과하는 요청이 들어왔을 때 사용자의 입장에서 응답시간이 증가하는 문제 발생한다. ex) 7개의 요청이 들어오고 최대 TPS가 5개라면 나머지 2개는 먼제 처리된 5개의 요청이 끝난 후에야 처리할 수 있다.** 응답시간의 증가는 사용자의 이탈로 이어질..