캐싱 가이드라인

GitLab 애플리케이션에서 사용하는 다양한 캐싱 전략과 효과적인 구현 방법, 그리고 주의해야 할 사항을 설명합니다.

이 문서는 GitLab에서 사용하는 다양한 캐싱 전략, 효과적인 구현 방법, 그리고 여러 주의사항에 대해 설명합니다. 이 내용은 훌륭한 캐싱 워크숍 에서 발췌했습니다. 캐시란 무엇인가? # 데이터를 위한 더 빠른 저장소로, 다음과 같은 특징이 있습니다: 컴퓨팅의 다양한 영역에서 사용됩니다. 프로세서에도 캐시가 있고, 하드 디스크에도 캐시가 있으며, 많은 곳에 캐시가 있습니다! 데이터가 최종적으로 도달해야 할 위치에 더 가깝게 위치하는 경우가 많습니다. 데이터를 위한 더 단순한 저장소입니다. 임시적입니다. 무엇이 빠른가? # 모든 웹 페이지의 목표는 100ms 이내에 응답을 반환하는 것이어야 합니다: 이는 달성 가능하지만, 현대 애플리케이션에서는 캐싱이 필요합니다. 더 큰 응답은 빌드하는 데 더 오래 걸리며, 일정한 속도를 유지하기 위해서는 캐싱이 매우 중요합니다. 캐시 읽기는 일반적으로 1ms 미만입니다. 이것으로 개선되지 않는 경우는 거의 없습니다. 이후 페이지 로드에서만 빠른 것은 충분하지 않습니다. 초기 경험도 중요하기 때문에, 이것만으로는 완전한 해결책이 되지 않습니다. 사용자별 데이터는 이를 어렵게 만들며, 기존 애플리케이션을 이 속도 목표에 맞게 리팩토링하는 데 있어 가장 큰 과제입니다. 사용자별 캐시도 효과적일 수 있지만, 사용자 간에 공유되는 일반 캐시보다 캐시 히트 수가 적습니다. 우리는 페이지 로드의 대부분이 항상 캐시에서 가져오는 것을 목표로 합니다. 캐시를 사용하는 이유 # 작업을 더 빠르게 만들기 위해! IO를 피하기 위해. 디스크 읽기. 데이터베이스 쿼리. 네트워크 요청. 동일한 결과를 여러 번 재계산하는 것을 피하기 위해: 뷰 렌더링. JSON 렌더링. Markdown 렌더링. 중복성을 제공하기 위해. 일부 경우에는 캐싱이 CloudFlare의 "Always Online" 기능과 같이 다른 곳에서의 장애를 숨기는 데 도움이 될 수 있습니다. 메모리 소비를 줄이기 위해. Ruby에서 더 적게 처리하고 큰 문자열만 가져옵니다. 비용을 절약하기 위해. RAM에 비해 프로세서가 비싼 클라우드 컴퓨팅에서 특히 그렇습니다. 캐싱에 대한 의구심 # 일부 엔지니어들은 캐싱을 마지막 수단으로만 사용하자며 반대합니다. 이들은 캐싱을 임시방편으로 보고, 진짜 해결책은 근본적인 코드를 더 빠르게 개선하는 것이라고 생각합니다. 이는 이해할 수 있는 캐시 만료에 대한 두려움에서 비롯될 수 있습니다. 하지만 캐싱은 여전히 더 빠릅니다. 진정한 성능을 달성하려면 두 가지 기법을 모두 사용해야 합니다: 예를 들어, 초기 콜드 쓰기가 너무 느려서 타임아웃이 발생한다면 캐싱을 해도 의미가 없습니다. 하지만 캐싱이 성능 향상이 아닌 경우는 거의 없습니다. 그러나 캐싱을 빠른 임시방편으로 충분히 활용할 수 있으며, 그것도 괜찮습니다. 때로는 "진짜" 수정에 몇 달이 걸리지만, 캐싱은 하루 만에 구현할 수 있습니다. GitLab에서의 캐싱 # Redis 캐싱의 단점에도 불구하고, GitLab 애플리케이션 내부와 GitLab.com의 캐싱 설정을 자유