MEGOLANG

map $upstream_cache_status $cache_status {
  'HIT' 'HIT';
  default $upstream_http_x_cache_status;
}

server {
  server_name edge;
  proxy_cache cache_1;
  proxy_cache_key $host$uri;
  proxy_cache_valid 200 206 301 302 10s;
  add_header X-Cache-Status $cache_status;
  proxy_hide_header X-Cache-Status;
  proxy_set_header Host relay;
  location / {
    proxy_pass http://relay;
  }
}

server {
  server_name relay;
  proxy_cache cache_1;
  proxy_cache_key $host$uri;
  proxy_cache_valid 200 206 301 302 10s;
  add_header X-Cache-Status $upstream_cache_status;
  proxy_hide_header X-Cache-Status;
  proxy_set_header Host origin;
  location / {
    proxy_pass http://origin;
  }
}

내 값이 HIT가 아니면, 윗 relay의 값을 참조하게 설정했다.

마지막 relay는 upstream 값이 없기에, 무조건 기본 값으로 넣어야한다.

map $time_iso8601 $year {
    '~^(?<y>\d{4})-'  $y;
}

map $time_iso8601 $month {
    '~^\d{4}-(?<m>\d{2})-'  $m;
}

map $time_iso8601 $day {
    '~^\d{4}-\d{2}-(?<d>\d{2})'  $d;
}

map $time_iso8601 $hour {
    '~T(?<h>\d{2}):'  $h;
}

map $time_iso8601 $minute {
    '~T\d{2}:(?<m>\d{2}):'  $m;
}

map $minute $minute5 {
  ~00|01|02|03|04 00;
  ~05|06|07|08|09 05;
  ~10|11|12|13|14 10;
  ~15|16|17|18|19 15;
  ~20|21|22|23|24 20;
  ~25|26|27|28|29 25;
  ~30|31|32|33|34 30;
  ~35|36|37|38|39 35;
  ~40|41|42|43|44 40;
  ~45|46|47|48|49 45;
  ~50|51|52|53|54 50;
  ~55|56|57|58|59 55;
}

server {
  access_log /var/log/nginx/5m/$year-$month-${day}_$hour:$minute5.log;
}

목표

중앙 집중식 로그 서버를 구축하여, 통계를 만들어낸다.

전체 로깅 시스템

• 일일 단위 로깅
• 5분 단위 로깅

일일 단위 로깅

실제로 각각의 서버에서 임시로 저장되는 로그 파일 (7~30d적절하다고 생각)
디버깅 시 해당 파일을 이용하여 사용
파일 경로는 다음과 같은 형식

tail -F /var/log/nginx/access/daily/20240513/example.com.log

5분 단위 로깅

해당 로그 파일은 중앙 집중식 로그 서버 구축하여 전달하기 위한 파일

tail -F /var/log/nginx/access/5m/1.1.1.1_20240513-1425A_example.com.log

crontab 을 이용해서 5분마다 파일이 전달되도록 설정

*/5 * * * * * /opt/gzip_and_send_log_to_server.sh 2.2.2.2

해당 실행 파일은 다음과 같은 순서를 가진다.

1. 약 3초 정도의 sleep (로그 파일이 안정적으로 쓰기를 종료)
2. 5m 폴더의 로그 파일 메타데이터를 API로 전달 (서버로 전달될 로그 파일의 갯수 및 해시)
3. gzip으로 압축 (네트워크 비용 감소)
4. FTP 등을 이용해서 로그파일 업로드

로깅 시스템 에러 발생 시 복구

중앙 서버에서 FTP 트리거를 이용하여 gzip 파일을 받아서 ungzip 이후 메타데이터와 비교 (정상적으로 전달이 됐는지 확인)
5분 뒤 API를 이용해서 받은 로그파일 갯수와 FTP로 전송받은 로그 파일 갯수 확인
파일 갯수가 다르면 알림 발생
분석 솔루션 시작 (5분 이내로 분석이 완료되도록 스케일 아웃 필요)

터지지 않고, 속은 다 익은 상태임

듀얼 모니터암 설치 완료 후에 듀얼 모니터암을 추천하지 않는 이유라는 글을 봤다.

https://www.youtube.com/watch?v=_gbt-BHToRI&pp=ygUT65OA7Ja8IOuqqOuLiO2EsOyVlA%3D%3D

설치에 시간과 노력을 투입했으니, 그냥 사용할려다가 주변의 모든 사람의 비추를 받고 반품 후 싱글 2개로 변경했다.

https://www.coupang.com/vp/products/7803766078

결국 이 제품으로 변경했다.

이걸로 바꾸니 4~5만원 추가 금액이 더 들었다.

이제 모니터만 사면 된다.

모니터는 급하지 않아 할인을 기다리고 있다.

27UP850N

안에 광안대교 불꽃놀이 액자 같은 것이 걸려 있던 곳에서 먹어봤을 때, 맛있었다.

끄읏

백엔드 개발을 담당하지만, 프론트 프로젝트를 실행하는 경우가 많다.

이런 경우 PM2라는 npm 어플리케이션을 사용한다.

pm2 start 'npm run dev' --name new-page

이를 활용하면 Go도 실행 상태를 유지할 수 있다.

pm2 start 'go run main.go' --name backend

{
  "postId":1,
  "commentIdList":[
    1,2,3
  ]
}

API 서버는 이렇게 Json을 반환하고, 이에 따라 Front는 다음과 같이 요청한다.

curl company.com/posts/1
curl company.com/comments/1
curl company.com/comments/2
curl company.com/comments/3

게시글과 댓글을 모두 캐시 할 수 있다.

게시글과 댓글이 수정 및 삭제 된다면, Purge 요청으로 재 갱신한다.

여기서 캐시율을 더 높이고 싶으니, 댓글을 5개씩 페이징 하는 것으로 변경해보자.

{
  "postId":1,
  "commentIdList":[
    1,2,3,4,5
  ]
}

댓글이 5개가 작성되는 순간 Cache-Control을 이용해서 TTL을 높게 주자.

게시글, 댓글 모두 각각 개별의 URI가 나오므로, 캐시율이 높아지지 않을까? 예상을 해본다.