• 예시
• 동작 방식
  • ReactiveCaching의 하드 제한 설정
• 사용 시기
• 사용 방법
  • 모델 및 통합에서
  • 컨트롤러에서
  • 모델이나 서비스에 구현해야 하는 메서드
    • #calculate_reactive_cache (필수)
    • #reactive_cache_updated (선택적)
  • 모델이나 서비스에 의해 호출되는 메서드
    • #with_reactive_cache (필수)
    • #clear_reactive_cache! (옵션)
    • #without_reactive_cache (옵션)
  • 구성 가능한 옵션들
    • self.reactive_cache_key
    • self.reactive_cache_lease_timeout
    • self.reactive_cache_refresh_interval
    • self.reactive_cache_lifetime
    • self.reactive_cache_hard_limit
    • self.reactive_cache_work_type
    • self.reactive_cache_worker_finder
• 캐시 키 변경

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)에서 사용할 수 있습니다.

1. 모델에 관심사를 포함합니다.

   모델에 관심사를 포함하려면:

   include ReactiveCaching
   

   통합에 관심사를 포함하려면:

   include Integrations::ReactivelyCached
   

2. 모델이나 통합에서 calculate_reactive_cache 메서드를 구현합니다.
3. 캐시된 값이 필요한 모델이나 통합에서 with_reactive_cache를 호출합니다.
4. reactive_cache_work_type을 해당되는 대로 설정하세요.

컨트롤러에서

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

• ReactiveCaching을 사용하는 모델이나 서비스 메서드를 호출하는 API는 캐시가 계산 중일 때(#with_reactive_cache가 nil을 반환할 때) 202 accepted를 반환해야 합니다.
• 또한 폴링 간격 헤더를 설정해야 합니다. Gitlab::PollingInterval.set_header로.
• 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
  

#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에 전달된 매개변수들입니다.

• 만약 이 concern을 통합(app/models/integrations/)에 포함하는 경우, 기본값을 오버라이드하기 위해 다음을 추가해야 합니다:

  self.reactive_cache_key = ->(integration) { [integration.class.model_name.singular, integration.project_id] }
  

  만약 당신의 reactive_cache_key가 정확히 위와 같다면, 기존의 Integrations::ReactivelyCached concern을 사용할 수 있습니다.

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메가바이트입니다. 이 값보다 크게 되는 데이터는 캐시되지 않으며, Sentry에서 ReactiveCaching::ExceededReactiveCacheLimit를 조용히 발생시킵니다.

self.reactive_cache_hard_limit = 5.megabytes

self.reactive_cache_work_type

• 이것은 calculate_reactive_cache 메서드에 의해 수행되는 작업의 유형입니다. 이 속성에 기반하여 올바른 워커를 선택하여 캐싱 작업을 처리할 수 있습니다. 작업이 외부 요청을 수행하는 경우 (예: Kubernetes, Sentry) :external_dependency로 설정하세요. 그렇지 않으면 :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를 호출합니다.

캐시 키 변경

리액티브 캐싱 작동 방식으로 인해, calculate_reactive_cache 메서드의 매개변수를 변경하는 것은 Sidekiq 워커의 매개변수를 변경하는 것과 같습니다. 따라서 동일한 규칙을 따라야 합니다.

예를 들어, calculate_reactive_cache 메서드에 새 매개변수가 추가되는 경우;

1. 기본값과 함께 calculate_reactive_cache 메서드에 인수를 추가하세요 (릴리스 M).
2. with_reactive_cache 메서드의 모든 호출에 새 인수를 추가하세요 (릴리스 M+1).
3. 기본값을 제거하세요 (릴리스 M+2).