예시
작동 방식
- ReactiveCaching의 하드 제한 설정
사용 시기
사용 방법

`ReactiveCaching`

본 문서는 reactive_caching.rb을 참조합니다.

ReactiveCaching 고려사항은 일부 데이터를 백그라운드에서 검색하고 Rails 캐시에 저장하여 요청되는 동안 최신 상태로 유지합니다. reactive_cache_lifetime 동안 데이터가 요청되지 않으면 새로 고쳐지지 않고 제거됩니다.

예시

class Foo < ApplicationRecord
  include ReactiveCaching
  
  after_save :clear_reactive_cache!
  
  def calculate_reactive_cache(param1, param2)
    # 여기서 비용이 많이 드는 작업이 이루어집니다. 이 메서드의 반환 값이 캐시됩니다
  end
  
  def result
    # `with_reactive_cache`에 어떤 인수든 전달할 수 있습니다. `calculate_reactive_cache`가 동일한 인수로 호출됩니다.
    with_reactive_cache(param1, param2) do |data|
      # ...
    end
  end
end

이 예시에서 #result가 처음 호출되면 nil을 반환합니다. 그러나 #calculate_reactive_cache를 호출하고 초기 캐시 수명이 10분인 백그라운드 작업이 대기열에 추가됩니다.

작동 방식

첫 번째 #with_reactive_cache 호출 시에 백그라운드 작업이 대기열에 추가되고 with_reactive_cache는 nil을 반환합니다. 백그라운드 작업은 #calculate_reactive_cache를 호출하고 그 반환 값을 저장합니다. 또한 reactive_cache_refresh_interval 이후에 다시 실행되도록 백그라운드 작업을 다시 대기열에 추가합니다. 따라서 저장된 값이 최신 상태로 유지됩니다. 계산이 동시에 실행되지는 않습니다.

캐시가 수명이 존재하는 동안 #with_reactive_cache를 호출하면 #with_reactive_cache에 주어진 블록이 호출되어 캐시된 값이 제공됩니다. 또한 reactive_cache_lifetime 값으로 캐시의 수명을 연장합니다.

수명이 만료된 후에는 더 이상 백그라운드 작업이 추가되지 않으며 #with_reactive_cache를 다시 호출하면 다시 nil이 반환되어 프로세스가 다시 시작됩니다.

ReactiveCaching의 하드 제한 설정

성능을 유지하려면 ReactiveCaching을 포함하는 클래스에서 하드 캐싱 제한을 설정해야 합니다. 설정 방법 예시를 확인하세요.

더 많은 정보는 내부 이슈인 Redis (또는 ReactiveCache) 소프트 및 하드 제한을 읽어보세요.

사용 시기

외부 API로 요청을 보내야 하는 경우(예: k8s API로의 요청). 응용 프로그램 서버 워커를 외부 요청의 기간 동안 차단하는 것은 권장되지 않습니다.
모델이 많은 데이터베이스 호출이나 다른 시간이 많이 소요되는 계산을 수행해야 하는 경우.

사용 방법

모델 및 통합에서

ReactiveCaching 고려사항은 모델 및 통합(app/models/integrations)에서 사용할 수 있습니다.

모델에 고려사항을 포함합니다.
모델에 고려사항을 포함하려면:
```
include ReactiveCaching
```
통합에 고려사항을 포함하려면:
```
include Integrations::ReactivelyCached
```
모델 또는 통합에서 calculate_reactive_cache 메서드를 구현합니다.
캐시된 값이 필요한 모델 또는 통합에서 with_reactive_cache를 호출합니다.
[reactive_cache_work_type을 해당되는 대로 설정합니다].

컨트롤러에서

ReactiveCaching을 사용하는 모델이나 서비스 메서드를 호출하는 컨트롤러 엔드포인트는 백그라운드 워커가 완료될 때까지 기다리지 않아야 합니다.

ReactiveCaching을 사용하는 모델이나 서비스 메서드를 호출하는 API는 (#with_reactive_cache가 nil을 반환할 때) 202 accepted를 반환해야 합니다.
또한 폴링 간격 헤더를 설정해야 합니다.
API의 소비자는 API를 폴링할 것으로 예상됩니다.
서버 부하를 줄이기 위해 ETag 캐싱을 구현할 수도 있습니다.

모델이나 서비스에서 구현해야 하는 메서드

이러한 메서드는 ReactiveCaching을 포함하는 모델/서비스에서 구현해야 하는 메서드입니다.

`#calculate_reactive_cache` (필수)

이 메서드는 반드시 구현되어야 합니다. 그 반환 값이 캐시됩니다.
캐시를 채우어야 할 때 ReactiveCaching에 의해 호출됩니다.
with_reactive_cache에 전달된 모든 인수가 calculate_reactive_cache에도 전달됩니다.

`#reactive_cache_updated` (선택적)

필요하다면 이 메서드를 구현할 수 있습니다.
캐시가 업데이트될 때마다 ReactiveCaching 고려사항에 의해 호출됩니다. 캐시가 새 캐시 값과 이전 캐시 값이 동일하면 이 메서드는 호출되지 않습니다. 새 값이 캐시에 저장될 때만 호출됩니다.
캐시가 업데이트될 때마다 작업을 수행하는 데 사용할 수 있습니다.

모델이나 서비스에서 호출하는 메서드

이러한 메서드는 ReactiveCaching에서 제공되며 모델/서비스에서 호출되어야 합니다.

`#with_reactive_cache` (필수)

calculate_reactive_cache의 결과가 필요한 곳에서 with_reactive_cache를 반드시 호출해야 합니다.
with_reactive_cache에는 블록을 제공할 수 있습니다. 또한 with_reactive_cache에는 모든 인수가 전달될 수 있습니다. with_reactive_cache에 전달된 인수는 캐시 키 이름에 추가됩니다.
결과가 이미 캐시되어 있을 때 with_reactive_cache가 호출되면 블록이 호출되어 캐시된 값이 제공되고 블록의 반환 값이 with_reactive_cache에 의해 반환됩니다. 또한 캐시의 타임아웃을 reactive_cache_lifetime 값으로 재설정합니다.
아직 결과가 캐시되어 있지 않은 경우 with_reactive_cache는 nil을 반환합니다. 또한 calculate_reactive_cache를 호출하고 결과를 캐시합니다.
백그라운드 작업이 완료되고 결과가 캐시되면 다음 with_reactive_cache 호출이 캐시된 값을 가져옵니다.

아래 예시에서 data는 with_reactive_cache에 주어진 블록에 전달된 캐시된 값입니다.

class Foo < ApplicationRecord
  include ReactiveCaching
    
  def calculate_reactive_cache(param1, param2)
    # 여기서 비용이 많이 드는 작업이 이루어집니다. 이 메서드의 반환 값이 캐시됩니다
  end
    
  def result
    with_reactive_cache(param1, param2) do |data|
      # ...
    end
  end
end

`#clear_reactive_cache!` (선택 사항)

이 메서드는 캐시를 만료/지울 필요가 있을 때 호출할 수 있습니다. 예를 들어, 모델의 after_save 콜백에서 호출하여 모델이 수정된 후에 캐시를 지울 수 있습니다.
이 메서드는 with_reactive_cache로 전달된 동일한 매개변수로 호출되어야 합니다 왜냐하면 매개변수는 캐시 키의 일부입니다.

`#without_reactive_cache` (선택 사항)

이는 디버깅 목적으로 사용할 수 있는 편의 메서드입니다.
이 메서드는 백그라운드 워커가 아닌 현재 프로세스에서 calculate_reactive_cache를 호출합니다.

구성 가능한 옵션

튜닝할 수있는 class_attribute 옵션이 있습니다.

`self.reactive_cache_key`

이 속성의 값은 data 및 alive 캐시 키 이름의 접두사입니다. with_reactive_cache로 전달된 매개변수는 캐시 키 이름의 나머지 부분입니다.

기본적으로 이 키는 모델의 이름과 레코드의 ID를 사용합니다.

self.reactive_cache_key = -> (record) { [model_name.singular, record.id] }

data 캐시 키는 "ExampleModel:1:arg1:arg2"이고 alive 캐시 키는 "ExampleModel:1:arg1:arg2:alive"입니다. 여기서 ExampleModel은 모델의 이름, 1은 레코드의 ID, arg1 및 arg2는 with_reactive_cache로 전달된 매개변수입니다.
이 관심사를 통합 프로그램(app/models/integrations/)에 포함하는 경우 기본값을 재정의해야 합니다. 다음을 통합에 추가함으로써 기본값을 재정의해야합니다:
```
self.reactive_cache_key = ->(integration) { [integration.class.model_name.singular, integration.project_id] }
```
이와 정확히 같은 경우에는 기존의 Integrations::ReactivelyCached 관심사를 사용할 수 있습니다.

`self.reactive_cache_lease_timeout`

ReactiveCaching은 Gitlab::ExclusiveLease를 사용하여 캐시 계산이 여러 워커에 의해 동시에 실행되지 않도록 보장합니다.
이 속성은 Gitlab::ExclusiveLease의 타임아웃입니다.
기본값은 2분이지만 다른 타임아웃이 필요한 경우 재정의할 수 있습니다.

self.reactive_cache_lease_timeout = 2.minutes

`self.reactive_cache_refresh_interval`

이것은 캐시가 새로 고침되는 간격입니다.
기본값은 1분입니다.

self.reactive_cache_refresh_interval = 1.minute

`self.reactive_cache_lifetime`

이것은 캐시가 요청이 없으면 만료되는 기간입니다.
기본값은 10분입니다. 이 캐시 값에 대한 10분 동안 요청이 없으면 캐시가 만료됩니다.
캐시 값이 만료되기 전에 해당 캐시의 타임아웃이 reactive_cache_lifetime로 재설정됩니다.

self.reactive_cache_lifetime = 10.minutes

`self.reactive_cache_hard_limit`

이것은 ReactiveCaching이 캐싱 할 수있는 최대 데이터 크기입니다.
기본값은 1메가바이트입니다. 이 값을 초과하는 데이터는 캐시되지 않으며 조용히 ReactiveCaching::ExceededReactiveCacheLimit을 Sentry에서 발생시킵니다.

self.reactive_cache_hard_limit = 5.megabytes

`self.reactive_cache_work_type`

이것은 calculate_reactive_cache 메서드에서 수행되는 작업의 유형입니다. 이 속성을 기반으로 올바른 워커가 캐싱 작업을 처리할 수 있습니다. 작업이 외부 요청을 수행하는 경우 :external_dependency로 설정해야합니다 (예: Kubernetes, Sentry); 그렇지 않으면 :no_dependency로 설정하세요.

`self.reactive_cache_worker_finder`

이것은 백그라운드 워커가 calculate_reactive_cache를 호출 할 수 있는 객체를 찾거나 생성하는 데 사용되는 메서드입니다.
기본값은 모델 기본 키를 사용하여 객체를 찾습니다.

self.reactive_cache_worker_finder = ->(id, *_args) do
  find_by(primary_key => id)
end

기본 동작은 사용자 정의 reactive_cache_worker_finder를 정의하여 재정의 할 수 있습니다.

class Foo < ApplicationRecord
  include ReactiveCaching
  
  self.reactive_cache_worker_finder = ->(_id, *args) { from_cache(*args) }
  
  def self.from_cache(var1, var2)
    # 이 메서드는 "bar1" 및 "bar2"가 인수로 전달되어 백그라운드 워커에 의해 호출됩니다.
    new(var1, var2)
  end
  
  def initialize(var1, var2)
    # ...
  end
  
  def calculate_reactive_cache(var1, var2)
    # 여기서 비용이 많이 드는 작업을 수행합니다. 이 메서드의 반환 값이 캐시됩니다.
  end
  
  def result
    with_reactive_cache("bar1", "bar2") do |data|
      # ...
    end
  end
end

이 예에서 기본 키 ID가 reactive_cache_worker_finder에 전달되며 with_reactive_cache로 전달된 매개변수와 함께 전달됩니다.
사용자 정의 reactive_cache_worker_finder는 with_reactive_cache로 전달된 매개변수와 함께 .from_cache를 호출합니다.

GitLab 원문 보기

도움말

기능 사용 가능성과 제품 평가판

모든 GitLab Tier와 기능을 보거나 업그레이드하려면
가격 페이지를 확인하세요.

GitLab을 무료로 체험해 30일 동안 모든 기능에
액세스해 보세요.

도움받기

기능을 설정하거나 사용하는 데 문제가 있으면
인포그랩에 지원을 요청하세요.
(GitLab 구독에 따라 다름)

지원 요청하기