오늘도 운영중

[개발면접] 로드 밸런서(Load Balancer)는 왜 필요할까? L4와 L7 차이까지

처음 서비스를 만들 때는 한 대의 서버로도 충분한 경우가 많다.Client ↓Server ↓Database하지만 사용자가 늘어나면 한 대의 서버가 모든 요청을 처리하기 어려워질 수 있다.이때 단순히 더 좋은 서버 한 대로 교체하는 방법도 있지만, 여러 대의 서버로 요청을 나누는 방법도 생각할 수 있다. ┌→ Server AClient → ? ──┼→ Server B └→ Server C여기서 필요한 것이 로드 밸런서(Load Balancer)다.로드 밸런서는 여러 서버 앞에서 요청을 받아 적절한 서버로 전달한다.개발 면접에서는 여기서 한 단계 더 들어가 다음 질문이 자주 이어진다.L4와 L7 Load Balancer는 무엇이 다른가?서버 한 대에 장애가 발생..

Laravel Redis Queue와 Database Queue 차이는 무엇일까?

Laravel에서 Queue를 처음 적용할 때는 Job 코드보다 어떤 Queue Connection을 사용할지 먼저 고민하게 된다.Laravel 프로젝트에서는 별도 인프라 없이 시작할 수 있는 Database Queue가 접근하기 쉽다.Application↓jobs 테이블↓Queue Worker서비스 규모가 커지거나 Queue 처리량이 많아지면 Redis Queue도 자연스럽게 후보에 들어온다.Application↓Redis↓Queue Worker그러면 이런 질문이 생긴다.Database Queue도 잘 동작하는데 Redis로 바꿔야 할까?Redis Queue는 정확히 무엇이 다른가?Job이 얼마나 많아지면 Redis를 사용해야 할까?Redis가 무조건 더 좋은 선택일까?단순히 Redis가 메모리 기반이..

웹 개발을 하다 보면 로그인 이후 페이지를 이동하거나 API를 여러 번 호출해도 로그인 상태가 계속 유지된다.그런데 HTTP는 기본적으로 Stateless한 프로토콜이다. 각각의 요청은 독립적으로 처리되기 때문에 별도의 장치가 없다면 서버는 이전 요청에서 누가 로그인했는지 기억하지 못한다.그렇다면 서버는 어떻게 같은 사용자의 요청이라는 것을 알 수 있을까?이 문제를 이해할 때 가장 먼저 알아야 하는 개념이 쿠키(Cookie)와 세션(Session)이다.핵심 차이부터 보면 다음과 같다.구분CookieSession주요 저장 위치클라이언트서버주요 역할작은 데이터 저장 및 전달사용자 상태 관리인증에서의 역할Session ID 등을 전달로그인 사용자 정보 관리서버 저장 공간직접 필요하지 않음필요주요 고려사항탈취,..

Laravel Queue를 운영할 때 Job이 정상적으로 실행되고 있다는 것만 확인하면 충분해 보일 수 있다.하지만 Queue 장애는 꼭 Worker가 완전히 멈추는 형태로만 나타나지 않는다.Job은 처리되고 있음↓그런데 대기 시간이 점점 길어짐↓사용자는 결과를 늦게 받음또는 실패한 Job은 많지 않은데 특정 Job의 실행 시간이 계속 증가할 수도 있다.이런 문제는 failed_jobs만 확인해서는 발견하기 어렵다.Queue 상태를 제대로 보려면 최소한 다음 질문에 답할 수 있어야 한다.현재 Job이 얼마나 쌓여 있는가?Job은 얼마나 오래 기다리고 있는가?얼마나 빠르게 들어오고 처리되는가?Job 하나를 처리하는 데 얼마나 걸리는가?실패와 Retry가 증가하고 있지는 않은가?Worker는 정상적으로 동작..

Laravel Queue를 운영하다 보면 Job 자체는 몇 초 만에 끝나는데 사용자가 결과를 받기까지는 몇 분씩 걸리는 경우가 있다.이럴 때 처음에는 Worker 수가 부족하다고 생각하기 쉽다.Queue가 느림↓Worker 부족?↓Worker 추가물론 Worker가 부족한 경우도 있다.하지만 Queue가 느려지는 원인은 생각보다 다양하다.Job 유입량 증가Worker 부족특정 Job 실행 시간 증가Slow Query외부 API 지연Retry 반복무거운 Job과 가벼운 Job이 같은 Queue를 사용Worker 프로세스 이상원인을 확인하지 않고 Worker만 늘리면 DB 부하가 더 커지거나 외부 API 요청이 동시에 증가하면서 오히려 상황이 나빠질 수도 있다.그래서 Laravel Queue가 밀릴 때는 단..

컴퓨터 구조를 공부하다 보면 메모리가 하나의 공간처럼 느껴지기 쉽다.하지만 실제로는RegisterL1 CacheL2 CacheL3 CacheRAMSSD처럼 여러 단계의 저장 공간을 함께 사용한다.그리고 이 저장 공간들은 속도, 용량, 가격이 모두 다르다.가장 빠른 저장 공간만 사용하면 좋을 것 같지만 현실적으로는 불가능하다.빠른 저장 공간은 비싸고 용량이 작기 때문이다.그래서 컴퓨터는 빠른 공간은 작게, 느린 공간은 크게 구성한다.이 구조를 Memory Hierarchy(메모리 계층 구조) 라고 한다.이번 글에서는 메모리 계층 구조가 왜 필요한지, 각 계층은 어떤 역할을 하는지, 그리고 백엔드 개발자 입장에서 왜 알아두면 좋은지 정리해보자.메모리 계층 구조란?메모리 계층 구조는 데이터를 저장하는 공간을 ..

개발을 하다 보면 Cache라는 말을 정말 자주 듣게 된다.Redis CacheBrowser CacheCDN CacheMySQL Buffer PoolCPU Cache종류는 다르지만 기본 아이디어는 비슷하다.자주 사용하는 데이터를 더 빠른 곳에 보관해두고, 느린 곳까지 접근하는 횟수를 줄이는 것이다.백엔드 개발에서는 Cache라고 하면 Redis를 먼저 떠올리기 쉽다. 하지만 Cache라는 개념은 훨씬 아래 계층인 CPU와 메모리 구조에서도 사용된다.CPU는 RAM보다 훨씬 빠르게 동작하기 때문에 CPU 입장에서는 메모리에서 데이터를 가져오는 시간조차 긴 대기 시간이 될 수 있다.그래서 CPU 가까이에 매우 빠른 Cache Memory를 두고 자주 사용할 가능성이 높은 데이터를 미리 보관한다. 여기서 중요..

네트워크 관련 개발 면접에서 정말 자주 등장하는 질문이 있다."TCP 3-Way Handshake를 설명해주세요."여기서 끝나지 않고 보통 이런 질문도 이어진다."연결할 때는 왜 3번이고, 종료할 때는 왜 4번인가요?""TIME_WAIT은 왜 필요한가요?"처음 공부할 때는SYNSYN + ACKACK순서만 외우기 쉽다.하지만 면접에서는 순서 자체보다 왜 이런 과정을 거치는지를 이해하고 설명하는 게 중요하다.핵심부터 정리하면 다음과 같다.TCP 3-Way Handshake는 클라이언트와 서버가 데이터를 주고받기 전에 서로 통신 가능한 상태인지 확인하고 연결을 설정하는 과정이다.반대로 연결을 종료할 때는 4-Way Handshake를 사용한다.하나씩 살펴보자.TCP부터 간단하게 정리해보자TCP는 Transmi..

Context Switching이란? 프로세스와 스레드 전환 비용 이해하기운영체제 관련 개발 면접에서 프로세스와 스레드의 차이를 설명하다 보면 자주 이어지는 질문이 있다."Context Switching이 뭔가요?"또는 조금 더 깊게 들어가면"프로세스와 스레드 중 Context Switching 비용은 어느 쪽이 더 큰가요?"라는 질문을 받을 수도 있다.Context Switching은 한마디로 정리하면 다음과 같다.CPU가 현재 실행 중인 작업의 상태를 저장하고 다른 작업의 상태를 불러와 실행 대상을 전환하는 과정이다.멀티태스킹을 이해하려면 반드시 알아야 하는 개념이고, 서버에서 스레드나 프로세스를 무작정 많이 만들면 왜 성능이 떨어질 수 있는지 설명할 때도 중요한 개념이다.CPU는 여러 프로그램을 동..

Laravel Queue를 운영하다 보면 결국 한 번쯤 이런 고민을 하게 된다.Worker를 몇 개 띄워야 하지?1개면 부족한가?5개면 충분한가?10개로 늘리면 더 빨라질까? 처음에는 Queue가 밀리기 시작하면 Worker 수부터 늘리고 싶어진다.Queue 대기100건↓Worker 2개↓처리 느림↓Worker 10개로 증가겉으로 보면 단순하다. Worker가 많아지면 동시에 처리하는 Job 수도 늘어나기 때문에 Queue가 더 빨리 줄어들 것처럼 보인다. 하지만 실제 운영에서는 Worker를 많이 늘린다고 무조건 좋은 것은 아니다.CPU 부족메모리 증가DB Connection 증가Slow Query 동시 실행외부 API Rate Limit 초과Redis 부하 증가같은 문제가 생길 수 있다. 특히 Que..