이번에 경매 시스템을 개발하면서 실시간 입찰 가격을 사용자에게 전달해야 했는데, 그때 실제로 SSE(Server-Sent Events)를 적용했다. 처음엔 WebSocket이 당연한 선택일 거라 생각했지만, 요구사항을 잘 뜯어보니 오히려 SSE가 더 적합했다. 요구사항은 다음과 같다. 한 유저가 입찰 금액을 업데이트하면, 다른 세션에서도 실시간으로 금액이 바뀌어야 한다.입찰은 유저가 서버로 요청을 보내는 POST /api/bid 같은 API로 처리된다.입찰 결과는 다른 유저들에게 자동으로 보여줘야 한다.그런데 사용자가 서버로 메시지를 보낼 일은 딱히 없다. 전파만 해주면 끝이다.즉, 클라이언트 → 서버 요청은 기존 REST API로 충분하고, 서버 → 클라이언트로 입찰 결과만 단방향으로 푸시해주면 되는 ..

최근 프로젝트에서 JWT(Json Web Token) 기반 인증 시스템을 구축하였다. 이 과정에서 프론트엔드 팀으로부터 "현재 로그인한 사용자의 정보를 가져올 수 있는 API가 필요하다" 는 요청이 있었고, 이에 따라 컨트롤러에서 인증된 사용자 정보를 꺼내는 방법을 고민하게 되었다. 처음에는 단순히 SecurityContextHolder에 유저 정보가 저장되어있기 때문에, SecurityContextHolder에서 꺼내서 반환하려는 로직을 고민하였다. Authentication auth = SecurityContextHolder.getContext().getAuthentication();CustomUserDetailsDto userDetails = (CustomUserDetailsDto) auth.get..

CPU는 메모리에 데이터를 요청할 때, Virtual address를 통해 요청하고 MMU가 그것을 Physical address로 변환시켜 실제 메모리에 엑세스 하게 된다. Virtual address프로세스가 자신만의 독립된 메모리 공간을 사용하는 것처럼 보이게 하기 위해 운영체제가 제공하는 주소각 프로세스는 0번지부터 시작하는 독립적인 주소 공간을 가짐실제로는 여러 프로세스가 동시에 실행되지만, 서로의 메모리 공간을 침범하지 못하게 보호하는 역할Physical address실제 컴퓨터의 RAM에 존재하는 주소모든 데이터와 명령어는 결국 이 물리 주소에 저장되고, CPU는 이 주소를 통해 데이터를 읽고 씀MMU(Memory Management Unit)CPU와 메모리 사시에 위치한 하드웨어 장치MMU..

systemd 서비스를 등록하는 도중, 서비스가 계속해서 실패하는 문제가 발생하였다. journalctl 명령어를 통해 로그를 확인한 결과, ExecStart 경로에 등록된 실행 파일에 대해 "Permission denied" 오류가 발생하는 것을 확인할 수 있었다. journalctl -xeu ***.service4월 22 11:17:39 localhost.localdomain systemd[9513]: ***.service: Failed at step EXEC spawning /home/****/****/bin/****: Permission deniedSubject: Process /home/****/****/bin/**** could not be executedDefined-By: systemdSu..

Core Dump 파일컴퓨터 프로그램이 특정 시점에 작업 중이던 메모리 상태를 기록한 것으로, 보통 프로그램이 비정상적으로 종료했을 때 만들어진다. 즉, 비정상적인 종료가 발생하는 경우 커널에서 해당 프로세스와 관련된 메모리 상태를 기록한 파일이다. Core Dump 파일을 생성하려면 사용자의 리소스 제한을 설정해주어야 한다.# core dump 크기 제한 확인ulimit -c# 0이면 core dump가 생성되지 않음# core dump 제한 해제ulimit -c unlimited 하지만 실제 운영 환경에서는 프로세스가 비정상 종료되기를 기다리는 것이 현실적이지 않거나, 시스템 설정 등의 이유로 core 파일이 생성되지 않을 수 있다. 이런 경우 gcore 명령어를 사용하면 실행 중인 프로세스의 메모..

pstackLinux/Unix 환경에서 실행 중인 프로세스의 스택 트레이스를 확인할 수 있는 디버깅 도구이다. 프로세스가 현재 어떤 함수를 실행 중이며, 어떤 경로로 해당 함수가 호출되었는지 추적할 수 있다. 설치yum install gdb 기본 사용법# 기본 문법pstack [프로세스ID]# 예시pstack 1234 사용 사례 프로세스 행(Hang) 분석$ pstack 1523Thread 1 (Thread 0x7f123456789):#0 0x00007f1234567890 in calculate_hash () at hash.cpp:123#1 0x00007f1234567891 in process_data () at process.cpp:456#2 0x00007f1234567892 in infinite_lo..

pstackLinux/Unix 환경에서 실행 중인 프로세스의 스택 트레이스를 확인할 수 있는 디버깅 도구이다. 프로세스가 현재 어떤 함수를 실행 중이며, 어떤 경로로 해당 함수가 호출되었는지 추적할 수 있다. 설치yum install gdb 기본 사용법# 기본 문법pstack [프로세스ID]# 예시pstack 1234 사용 사례 프로세스 행(Hang) 분석$ pstack 1523Thread 1 (Thread 0x7f123456789):#0 0x00007f1234567890 in calculate_hash () at hash.cpp:123#1 0x00007f1234567891 in process_data () at process.cpp:456#2 0x00007f1234567892 in infinite_lo..

lsof는 "List Open Files"의 약자로, 리눅스 및 유닉스 계열 운영 체제에서 현재 시스템에서 열려 있는 파일과 그 파일을 사용하는 프로세스에 대한 정보를 보여주는 유틸리티이다. lsof는 시스템에서 열려 있는 모든 파일의 목록(일반 파일, 디렉토리, 소켓, 장치 파일 등)을 제공하며, 각 파일을 열고 있는 프로세스의 PID(프로세스 ID), 사용자, 파일의 접근 모드(읽기, 쓰기 등) 등의 정보를 포함한다. 각 헤더의 의미COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME COMAND : 프로세스/명령어의 이름 PID : 프로세스의 고유 식별 번호 USER : 프로세스를 실행한 사용자의 이름 (..