InfoGrab DocsInfoGrab Docs

ETag 캐싱을 활용한 폴링

요약

변경 사항을 폴링(서버에 새로운 변경이 있는지 반복적으로 질의)하면 GitLab 인스턴스에 높은 부하가 발생합니다. 대신 Redis를 활용한 ETag 캐싱 폴링 메커니즘을 사용해야 합니다. 폴링할 엔드포인트의 경로를 Gitlab::EtagCaching::Router에 추가합니다.

변경 사항을 폴링(서버에 새로운 변경이 있는지 반복적으로 질의)하면 GitLab 인스턴스에 높은 부하가 발생합니다. 일반적으로 최소 몇 개의 SQL 쿼리를 실행해야 하기 때문입니다. 이로 인해 GitLab.com과 같은 대규모 GitLab 인스턴스의 스케일링이 매우 어려워지므로, 데이터베이스를 직접 조회하는 폴링이 필요한 새 기능 추가는 허용하지 않습니다.

대신 Redis를 활용한 ETag 캐싱 폴링 메커니즘을 사용해야 합니다.

사용 방법#

  • 폴링할 엔드포인트의 경로를 Gitlab::EtagCaching::Router에 추가합니다.

  • Gitlab::PollingInterval.set_header를 사용해 응답에 폴링 간격 헤더를 설정합니다.

  • Gitlab::EtagCaching::Store를 사용해 엔드포인트 경로에 대한 캐시 무효화를 구현합니다. 리소스가 변경될 때마다 해당 리소스에 의존하는 경로의 ETag를 무효화해야 합니다.

  • 메커니즘이 올바르게 동작하는지 확인합니다:

    요청이 상태 코드 304를 반환해야 합니다.

  • log/development.log에 SQL 쿼리가 기록되지 않아야 합니다.

ETag 캐싱 폴링 동작 방식#

캐시 미스(Cache Miss):

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: How polling with ETag caching works accDescr: Diagram showing how polling with ETag caching works with a cache miss

Client->>+Rails: GET /projects/5/pipelines Rails->>+EtagCaching: GET /projects/5/pipelines EtagCaching->>+Redis: read(key = 'GET ') rect rgba(0, 0, 0, 0) Redis->>+EtagCaching: cache MISS end EtagCaching->>+Redis: write('') EtagCaching->>+Rails: GET /projects/5/pipelines Rails->>+Client: JSON response with ETag

캐시 히트(Cache Hit):

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: How polling with ETag caching works accDescr: Diagram showing how polling with ETag caching works with a cache hit

Client->>+Rails: GET /projects/5/pipelines Rails->>+EtagCaching: GET /projects/5/pipelines EtagCaching->>+Redis: read(key = 'GET ') rect rgba(0, 0, 0, 0) Redis->>+EtagCaching: cache HIT end EtagCaching->>+Client: 304 Not Modified

  • 리소스가 변경될 때마다 임의의 값을 생성하여 Redis에 저장합니다.

  • 클라이언트가 요청을 보내면 Redis의 값을 ETag 응답 헤더에 설정합니다.

  • 클라이언트는 응답을 캐시(클라이언트 사이드 캐싱)하고, 동일한 리소스에 대한 이후의 모든 요청에 ETag 값을 If-None-Match 헤더로 전송합니다.

  • If-None-Match 헤더가 Redis의 현재 값과 일치하면, 리소스가 변경되지 않은 것이므로 데이터베이스를 전혀 조회하지 않고 즉시 304 응답을 반환할 수 있습니다. 클라이언트의 브라우저는 캐시된 응답을 사용합니다.

  • If-None-Match 헤더가 Redis의 현재 값과 일치하지 않으면 리소스가 변경된 것이므로 새로운 응답을 생성해야 합니다.

ETag 캐싱을 활성화하려는 엔드포인트에는 쿼리 파라미터(예: ?scope=all)를 사용하지 마세요. 미들웨어는 요청 경로만 고려하고 쿼리 파라미터는 무시합니다. 모든 파라미터는 요청 경로에 포함되어야 합니다. 이렇게 하면 쿼리 파라미터 순서 문제를 방지하고 라우트 매칭을 더 쉽게 할 수 있습니다.

더 자세한 정보는 다음을 참조하세요:

ETag 캐싱을 활용한 폴링

GitLab v19.1
원문 보기
요약

변경 사항을 폴링(서버에 새로운 변경이 있는지 반복적으로 질의)하면 GitLab 인스턴스에 높은 부하가 발생합니다. 대신 Redis를 활용한 ETag 캐싱 폴링 메커니즘을 사용해야 합니다. 폴링할 엔드포인트의 경로를 Gitlab::EtagCaching::Router에 추가합니다.

변경 사항을 폴링(서버에 새로운 변경이 있는지 반복적으로 질의)하면 GitLab 인스턴스에 높은 부하가 발생합니다. 일반적으로 최소 몇 개의 SQL 쿼리를 실행해야 하기 때문입니다. 이로 인해 GitLab.com과 같은 대규모 GitLab 인스턴스의 스케일링이 매우 어려워지므로, 데이터베이스를 직접 조회하는 폴링이 필요한 새 기능 추가는 허용하지 않습니다.

대신 Redis를 활용한 ETag 캐싱 폴링 메커니즘을 사용해야 합니다.

사용 방법#

  • 폴링할 엔드포인트의 경로를 Gitlab::EtagCaching::Router에 추가합니다.

  • Gitlab::PollingInterval.set_header를 사용해 응답에 폴링 간격 헤더를 설정합니다.

  • Gitlab::EtagCaching::Store를 사용해 엔드포인트 경로에 대한 캐시 무효화를 구현합니다. 리소스가 변경될 때마다 해당 리소스에 의존하는 경로의 ETag를 무효화해야 합니다.

  • 메커니즘이 올바르게 동작하는지 확인합니다:

    요청이 상태 코드 304를 반환해야 합니다.

  • log/development.log에 SQL 쿼리가 기록되지 않아야 합니다.

ETag 캐싱 폴링 동작 방식#

캐시 미스(Cache Miss):

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: How polling with ETag caching works accDescr: Diagram showing how polling with ETag caching works with a cache miss

Client->>+Rails: GET /projects/5/pipelines Rails->>+EtagCaching: GET /projects/5/pipelines EtagCaching->>+Redis: read(key = 'GET ') rect rgba(0, 0, 0, 0) Redis->>+EtagCaching: cache MISS end EtagCaching->>+Redis: write('') EtagCaching->>+Rails: GET /projects/5/pipelines Rails->>+Client: JSON response with ETag

캐시 히트(Cache Hit):

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: How polling with ETag caching works accDescr: Diagram showing how polling with ETag caching works with a cache hit

Client->>+Rails: GET /projects/5/pipelines Rails->>+EtagCaching: GET /projects/5/pipelines EtagCaching->>+Redis: read(key = 'GET ') rect rgba(0, 0, 0, 0) Redis->>+EtagCaching: cache HIT end EtagCaching->>+Client: 304 Not Modified

  • 리소스가 변경될 때마다 임의의 값을 생성하여 Redis에 저장합니다.

  • 클라이언트가 요청을 보내면 Redis의 값을 ETag 응답 헤더에 설정합니다.

  • 클라이언트는 응답을 캐시(클라이언트 사이드 캐싱)하고, 동일한 리소스에 대한 이후의 모든 요청에 ETag 값을 If-None-Match 헤더로 전송합니다.

  • If-None-Match 헤더가 Redis의 현재 값과 일치하면, 리소스가 변경되지 않은 것이므로 데이터베이스를 전혀 조회하지 않고 즉시 304 응답을 반환할 수 있습니다. 클라이언트의 브라우저는 캐시된 응답을 사용합니다.

  • If-None-Match 헤더가 Redis의 현재 값과 일치하지 않으면 리소스가 변경된 것이므로 새로운 응답을 생성해야 합니다.

ETag 캐싱을 활성화하려는 엔드포인트에는 쿼리 파라미터(예: ?scope=all)를 사용하지 마세요. 미들웨어는 요청 경로만 고려하고 쿼리 파라미터는 무시합니다. 모든 파라미터는 요청 경로에 포함되어야 합니다. 이렇게 하면 쿼리 파라미터 순서 문제를 방지하고 라우트 매칭을 더 쉽게 할 수 있습니다.

더 자세한 정보는 다음을 참조하세요: