한경민
기간 : 2022.11. ~ 2022.12.
기술 스택 : Linux (Debian & Alpine), Docker, Shell Script
개요 : Docker 컨테이너로 서비스 실행 환경 구축 자동화.
한경민
BrilliantServer 문제 해결 사례 - writev 사용하여 불필요한 복사 방지 및 시스템콜 호출 감소
send 시스템콜로 응답을 보내려면, header 와 body 를 모두 담을 수 있는 버퍼를 할당해서 복사하는 과정을 거치거나 send 를 두번 호출해야 한다.writev 시스템콜 사용하여 한번의 시스템콜로 각기 다른 두 버퍼에 있는 header 와 body 순서대로 클라이언트에게 전송.#include <sys/uio.h>
ssize_t writev(int fildes, const struct iovec *iov, int iovcnt);
struct iovec {
char *iov_base; /* Base address. */
size_t iov_len; /* Length. */
};
struct iovec *iov 에 각 버퍼의 주소값과 길이가 순서대로 담긴 iovec 구조체 배열의 주소값을 넣어주고 호출하면, 한번의 시스템콜로 여러개의 버퍼에 담겨 있는 데이터 전송 가능.send 결과
writev 결과💡위 비교는 각기 다른 버전의 프로그램으로 테스트한 것이기 때문에 정확한 비교라고 할 수는 없다. 하지만 writev 버전이 상위 버전이고, 총 시스템콜 횟수 증가에서도 볼 수 있듯 timeout 처리 등 추가적인 기능들이 더해졌는데도 더 나은 성능을 보였기 때문에 유의미한 결과라고 볼 수 있다.
한경민
개발 기간 : 2022.09. ~ 2022.11.
kqueue 활용한 event loop 기반 non-blocking I/O multiplexingGET/POST/DELETE HTTP Request 처리Connection request header field 의 값에 따라 해당 요청 응답 후, 클라이언트와 네트워크 연결 유지 (keep-alive) / 연결 해제 (close) 결정
한경민
우리42벤트 문제 해결 사례 - crontab 으로 공휴일 데이터 fetch 자동화 & redis 캐싱
m_{year}{month} : stringified 공휴일 날짜 array 형태로 redis 에 SET 하여 캐싱.Promise.allSettled 로 비동기 요청들을 보내고, 성공 실패 여부를 각 연월별로 ‘fulfilled’ / ‘rejected’ 여부로 STDOUT 으로 로깅.EXISTS 로 확인하여 다음 시도에서 제외하고, 24개월 데이터가 모두 캐싱될 때까지 script 를 재실행한다. 보통 두번 하면 다 성공.0 3 1 * * [node executable path] [script path] >> ~/log/our42vent/updateHolidays.log 2>&1
한경민
Github 레포지토리 : github.com/innovationacademy-kr/our42vent
대상 : 42 Seoul 커뮤니티
개발 기간 : 2022.01. ~ 2022.02.
배포 기간 : 2022.02 ~ 2022.12
현재 42 서울 이벤트들은 슬랙 random 채널을 통해 공지. 이러한 커뮤니케이션 방식에서 아래와 같은 문제 발견:
42의 모든 구성원들이 이벤트를 등록할 수 있고, 이벤트들을 한눈에 볼 수 있는 캘린더 웹사이트 구현.
한경민
기절초퐁 문제 해결 사례 3 - 유저 접속 상태 변경 알림 최적화
userActivity WebSocket 이벤트로 공지된다.GET /user/:userId/info 와 요청자가 머무르고 있는 UI 정보를 바탕으로 :userId 로특정되는 유저 정보를 보고 있는 유저들의 목록 in-memory 로 저장하고, 변화 시 업데이트.activity-${userId} 라는 room 에 넣어두고, 해당 room 에만 userActivity 이벤트 전송.
한경민
기절초퐁 문제 해결 사례 2 - 게임 엔진 코드 클라이언트에서 서버로 이전
한경민
기절초퐁 문제 해결 사례 1 - 유저-유저 & 유저-채팅방 관계 in-memory 캐싱
SELECT 시 JOIN 이 매번 일어난다.channels & channel_members 테이블SELECT
cm.member_id,
cm.channel_id,
c.access_mode,
c.name, c.dm_peer_id,
(
SELECT COUNT(*)
FROM messages msg
WHERE msg.channel_id = cm.channel_id
AND msg.created_at > (
SELECT viewed_at
FROM channel_members
WHERE member_id = my_id AND channel_id = cm.channel_id
)
) AS unseen_count,
(
SELECT COUNT(*)
FROM channel_members cm2
WHERE cm2.channel_id = cm.channel_id
) AS member_count
FROM channel_members cm
LEFT JOIN channels c ON c.channel_id = cm.channel_id
WHERE cm.member_id = my_id;
channels & channel_members 테이블SELECT cm.member_id, cm.is_admin, c.owner_id FROM channel_members cm LEFT JOIN channels c ON c.channel_id=cm.channel_id;
Service 객체들과 DB 사이에 관계 정보를 in-memory 에 캐싱하여 들고 있는 Storage 객체 구현.UserRelationshipStorage 객체.ChannelStorage 객체.Service 객체는 관계 정보 CRUD 시 반드시 Storage 객체를 거친다.💡 Dependency Injection 패턴의 NestJs 에서 주입된 의존 객체가 Singleton 으로 유지되기 때문에 가능한 해결책이었다.
💡 TL;DR 요청이 많을수록 유리, 유저가 많을수록 불리
한경민
Github 레포지토리 : github.com/brilliantshell/ft_transcendence
개발 기간 : 2022.12. ~ 2023.03.
한경민
👨🏻💻 저는 이런 Problem Solver 입니다
