프로덕트

아직 프로덕트가 없습니다.

아티클

전체 보기
한경민

한경민

Inception (개인) 프로젝트 소개

기간 : 2022.11. ~ 2022.12.

기술 스택 : Linux (Debian & Alpine), Docker, Shell Script

개요 : Docker 컨테이너로 서비스 실행 환경 구축 자동화.

  • Linux Virtual Machine (UTM/VirtualBox) 에 Docker CLI 설치
  • Dockerfile 로 각 서비스 이미지 build 설정
  • 각 서비스 설정 파일 작성
  • docker-compose 로 여러 서비스 실행 자동화
  • docker network 설정
  • run dependency 설정 (service health check etc.)
  • DB 데이터 & Wordpress Script bind mount 설정

결과물 : github.com/42ghan/inception

3
0
한경민

한경민

BrilliantServer 문제 해결 사례 - writev 사용하여 불필요한 복사 방지 및 시스템콜 호출 감소

0 문제 정의

  • HTTP 응답을 준비할 때, 파싱을 편리하게 하고, 불필요한 메모리 재할당 및 복사를 최소화하기 위해 header 버퍼와 body 버퍼를 별도로 저장하기로 결정.
  • send 시스템콜로 응답을 보내려면, header 와 body 를 모두 담을 수 있는 버퍼를 할당해서 복사하는 과정을 거치거나 send 를 두번 호출해야 한다.
  • 시스템콜 호출과 할당 및 복사 모두 서버의 성능을 저하시킬 수 있는 요인으로 판단.

1 해결책

  • 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 구조체 배열의 주소값을 넣어주고 호출하면, 한번의 시스템콜로 여러개의 버퍼에 담겨 있는 데이터 전송 가능.

2 검증

  • send 결과

  • writev 결과

  • 동일한 양의 데이터 전송 시 writev 를 사용했을 때, 더 나은 성능, 더 적은 시스템콜 호출 횟수 확인.

💡위 비교는 각기 다른 버전의 프로그램으로 테스트한 것이기 때문에 정확한 비교라고 할 수는 없다. 하지만 writev 버전이 상위 버전이고, 총 시스템콜 횟수 증가에서도 볼 수 있듯 timeout 처리 등 추가적인 기능들이 더해졌는데도 더 나은 성능을 보였기 때문에 유의미한 결과라고 볼 수 있다.

3
0
한경민

한경민

BrilliantServer (3인팀) 프로젝트 소개

RFC 9110, 9112 에 정의된 규격을 따르는 HTTP/1.1 버전 origin server 의 구현

개발 기간 : 2022.09. ~ 2022.11.

0 기술 스택

  • C++98
  • CMake
  • GoogleTest

1 기능

  • kqueue 활용한 event loop 기반 non-blocking I/O multiplexing
  • static 파일에 대한 GET/POST/DELETE HTTP Request 처리
  • HTTP 규격에 맞는 응답 생성
  • CGI 실행, name-based virtual hosting, directory listing 지원
  • Google Test & CMake 로 TDD & 유닛 테스팅
  • Connection request header field 의 값에 따라 해당 요청 응답 후, 클라이언트와 네트워크 연결 유지 (keep-alive) / 연결 해제 (close) 결정

2 설계

  • 객체 책임/역할 정의

  • HTTP 요청/응답 flowchart

3 구현

4 성능 테스트

  • siege http load tester 로 성능 테스트
  • 작은 파일 (48.7 KB) GET 요청 10,000 번

  • 큰 파일 (2.5MB image) GET 요청 10,000 번


2
0
한경민

한경민

우리42벤트 문제 해결 사례 - crontab 으로 공휴일 데이터 fetch 자동화 & redis 캐싱

0 배경

  • 공휴일 정보의 경우 어떤 클라이언트가 요청하던지 변하지 않는 데이터인데, 캘린더 표시 월이 바뀔 때마다 공공데이터포탈 Open API 로 데이터를 fetch 해야한다.

1 문제 정의

  • 서비스가 외부 API 서버의 상태에 의존적이다.
  • 공휴일 데이터 fetch 가 오래 걸려서 요청 응답, 캘린더 렌더링이 느려진다.
  • API 서버가 안정적이지 않아서 정확하지 않은 정보가 캘린더에 표시될 때가 있다.
  • 불필요한 네트워크 overhead. 변하지 않는 데이터에 대해 반복적으로 외부 요청을 보내야한다.
  • 클라이언트의 상태에 영향을 받지 않는 데이터를 반복적으로 외부 서비스에 요청해야한다.

2 해결책

  • 서비스 배포 전 +-12개월 공휴일 데이터를 fetch 받아서 각 월별 m_{year}{month} : stringified 공휴일 날짜 array 형태로 redis 에 SET 하여 캐싱.
  • 공휴일 데이터 API 서버가 안정적이지 않아서 24개월치 공휴일을 한꺼번에 요청할 때 실패하는 연월들이 생긴다.
  • Promise.allSettled 로 비동기 요청들을 보내고, 성공 실패 여부를 각 연월별로 ‘fulfilled’ / ‘rejected’ 여부로 STDOUT 으로 로깅.
  • 이미 캐싱에 성공한 연월은 redis EXISTS 로 확인하여 다음 시도에서 제외하고, 24개월 데이터가 모두 캐싱될 때까지 script 를 재실행한다. 보통 두번 하면 다 성공.
  • crontab 으로 매월 첫째날 3AM 에 다음 해 해당 월 공휴일 데이터 fetch.
0 3 1 * * [node executable path] [script path] >> ~/log/our42vent/updateHolidays.log 2>&1
  • eviction policy - 캐시 값들을 영구적으로 쌓을 수 없기 때문에 캐싱된 달의 1일로부터 +12개월 후에 캐시 값 지워지도록 TTL 설정.
  • 결과적으로 항상 +-12개월 공휴일 데이터 캐싱. 그 외의 범위는 공휴일을 표시하지 않는다.
2
0
한경민

한경민

우리42벤트 (4인팀) 프로젝트 소개

슬랙에 마구잡이로 올라오는 42 이벤트들을 한 눈에 볼 수 있는 캘린더 웹서비스

Github 레포지토리 : github.com/innovationacademy-kr/our42vent

대상 : 42 Seoul 커뮤니티

개발 기간 : 2022.01. ~ 2022.02.

0 서비스 배포

배포 기간 : 2022.02 ~ 2022.12

1 기술 스택

2 목적

현재 42 서울 이벤트들은 슬랙 random 채널을 통해 공지. 이러한 커뮤니케이션 방식에서 아래와 같은 문제 발견:

  • 글이 쌓여서 필요한 정보를 못 보는 사람들이 생긴다.
  • 관심있는 이벤트의 일정을 개인적으로 저장해야 한다.
  • 인트라의 agenda 캘린더는 공식 이벤트 정보만 볼 수 있고, 사용이 불편하다.
  • 학생들은 인트라 캘린더에 이벤트를 등록할 수 없다.

42의 모든 구성원들이 이벤트를 등록할 수 있고, 이벤트들을 한눈에 볼 수 있는 캘린더 웹사이트 구현.

3 기능

👤 로그인

  • 42 API OAuth 로 일차 인증 후, access token & refresh token 발급하여 사용자를 인증합니다.

✅ 이벤트 일정 확인

  • 캘린더 뷰에서 다양한 42 이벤트들의 일정을 확인할 수 있습니다.
  • 이벤트들은 종류별 카테고리로 분류되어 있고, 각 카테고리에 해당하는 이벤트들만 선택하여 볼 수 있습니다.

✨ 이벤트 생성

  • 특강, 외부 컨퍼런스, 개인이 여는 이벤트등을 캘린더 이벤트로 생성할 수 있습니다.
  • 본인이 생성한 이벤트 정보를 수정하거나 삭제할 수 있습니다.

🔔 이벤트 구독

  • 이벤트를 구독하여 나만의 캘린더로 관리할 수 있습니다.
  • 알림설정을 통하여 브라우저 알림을 (ServiceWorker API & WebPush API) 받을 수 있습니다.

📣 이벤트 홍보

  • 이벤트 생성 후 자동으로 홍보글이 만들어져서 손쉽게 홍보할 수 있습니다.

4 아키텍쳐

  • AWS lightsail 인스턴스.
  • NGINX 로 HTTPS 설정 및 reverse proxy.
  • Express application server.
  • MariaDB.
  • Redis Cache Storage.

5 역할 및 기여

기여도

  • 커밋 : 46% (139/300 commits without merges)
  • 이슈 : 46% (59/127 assigned issues)
  • PR : 38% (33/86 merged PRs)

역할

  • 캘린더 CSR view & API 구현
  • Service Worker API & Push API 로 사용자가 등록한 이벤트 push 알림 기능 & 알림 설정 UX 구현
  • 공공데이터포탈 Open API 로 공휴일 데이터 요청 & 표시
  • ejs 로 여러 view 에서 공통으로 활용되는 SSR layout 설정



2
0

포스트

아직 포스트가 없습니다.