Sportmaster가 캐싱 시스템을 선택한 방법. 1 부

안녕하세요! 제 이름은 Alexey Pyankov이고 Sportmaster 회사의 개발자입니다. 그 안에 우편 저는 2012년에 Sportmaster 웹사이트 작업이 어떻게 시작되었는지, 우리가 어떤 계획을 "강화"했는지, 그 반대로 어떤 레이크를 수집했는지에 대해 이야기했습니다.

오늘 저는 사이트 관리 영역에서 Java 백엔드용 캐싱 시스템을 선택하는 또 다른 주제에 대한 생각을 공유하고 싶습니다. 이 줄거리는 나에게 특별한 의미가 있습니다. 비록 이야기가 단 2개월 동안 전개되었지만, 이 60일 동안 우리는 하루도 쉬지 않고 12~16시간을 일했습니다. 이렇게 열심히 일한다는 게 가능하다고 생각해본 적도 상상도 해본 적도 없었어요.

따라서 텍스트를 완전히 로드하지 않도록 텍스트를 두 부분으로 분할했습니다. 반대로 첫 번째 부분은 준비, 소개, 캐싱이 무엇인지에 대한 몇 가지 고려 사항 등 매우 가벼울 것입니다. 이미 숙련된 ​​개발자이거나 캐시 작업을 해본 적이 있다면 기술적인 측면에서 볼 때 이 기사에서 새로운 내용은 없을 것입니다. 하지만 후배에게는 그런 작은 검토가 그가 갈림길에 섰을 때 어느 방향을 봐야 할지 알려줄 수 있습니다.

Sportmaster 웹사이트의 새 버전이 제작에 들어갔을 때 데이터는 다소 편리하지 않은 방식으로 수신되었습니다. 기본은 이전 버전의 사이트(Bitrix)를 위해 준비된 테이블로, ETL로 가져와서 새로운 형식으로 가져오고 1개 이상의 시스템에서 다양한 작은 항목으로 풍부해졌습니다. 새로운 사진이나 제품 설명이 사이트에 나타나려면 다음 날까지 기다려야 했습니다. 업데이트는 하루에 한 번 밤에만 이루어졌습니다.

처음에는 제작에 들어간 첫 주부터 걱정이 너무 많아서 콘텐츠 관리자가 겪는 불편함은 사소한 일이었습니다. 그러나 모든 것이 해결되자마자 프로젝트 개발은 계속되었습니다. 몇 달 후인 2015년 초에 우리는 관리 패널을 적극적으로 개발하기 시작했습니다. 2015년과 2016년에는 모든 것이 순조롭게 진행되고 있으며 정기적으로 출시되고 관리 패널에서 점점 더 많은 데이터 준비를 다루며 곧 우리 팀이 가장 중요하고 복잡한 일인 제품을 맡게 될 것이라는 사실에 대비하고 있습니다. 회로(모든 제품에 대한 데이터의 완전한 준비 및 유지 관리). 그러나 2017년 여름, 상품 회로가 출시되기 직전에 프로젝트는 캐싱 문제로 인해 매우 어려운 상황에 처하게 될 것입니다. 나는 두 부분으로 구성된 이 출판물의 두 번째 부분에서 이 에피소드에 대해 이야기하고 싶습니다.

하지만 이 게시물에서는 멀리서 시작하여 캐싱에 대한 몇 가지 생각, 즉 대규모 프로젝트를 시작하기 전에 살펴보는 좋은 단계가 될 아이디어를 제시할 것입니다.

캐싱 작업이 발생하는 경우

캐싱 작업은 그냥 나타나는 것이 아닙니다. 우리는 소프트웨어 제품을 작성하는 개발자이며 그것이 수요가 있기를 원합니다. 제품에 대한 수요가 있고 성공하면 사용자가 올 것입니다. 그리고 점점 더 많은 사람들이 옵니다. 그러다가 사용자가 많아지면 제품의 부하도 높아지게 됩니다.

첫 번째 단계에서는 최적화와 코드 성능에 대해 생각하지 않습니다. 가장 중요한 것은 기능, 신속하게 파일럿을 출시하고 가설을 테스트하는 것입니다. 부하가 증가하면 철분을 펌핑합니다. 우리는 그것을 10배, 2배, 5배, 어쩌면 10배로 늘립니다. 여기 어딘가 – 재정이 더 이상 허용되지 않습니다. 사용자 수는 몇 배로 늘어나나요? 100-1000-100 같지는 않겠지만 성공하면 XNUMX~XNUMX번에서 XNUMX만번이 될 것이다. 즉, 조만간 최적화를 수행해야 합니다.

코드의 일부(이 부분을 함수라고 부르겠습니다)가 터무니없이 오랜 시간이 걸리고 실행 시간을 줄이고 싶다고 가정해 보겠습니다. 함수는 데이터베이스에 대한 액세스일 수도 있고 복잡한 논리의 실행일 수도 있습니다. 가장 중요한 것은 실행하는 데 오랜 시간이 걸린다는 것입니다. 실행 시간을 얼마나 줄일 수 있나요? 한도 내에서 더 이상 XNUMX으로 줄일 수 없습니다. 실행 시간을 XNUMX으로 줄이는 방법은 무엇입니까? 답변: 실행을 완전히 제거합니다. 대신 결과를 즉시 반환하세요. 결과를 어떻게 알 수 있나요? 대답: 계산하거나 어딘가를 찾아보세요. 계산하는데 시간이 오래 걸립니다. 예를 들어, 감시한다는 것은 동일한 매개변수를 사용하여 호출했을 때 마지막으로 함수가 생성한 결과를 기억하는 것입니다.

즉, 함수의 구현은 우리에게 중요하지 않습니다. 결과가 어떤 매개변수에 따라 달라지는지 아는 것만으로도 충분합니다. 그런 다음 매개변수 값을 일부 저장소에서 키로 사용할 수 있는 객체 형태로 표현하면 계산 결과를 저장하고 다음에 액세스할 때 읽을 수 있습니다. 결과를 쓰고 읽는 것이 함수를 실행하는 것보다 빠르면 속도 측면에서 이익이 됩니다. 수익금액은 100, 1000, 100배에 달할 수 있습니다(10^5는 오히려 예외이지만 상당히 뒤떨어진 베이스의 경우에는 꽤 가능합니다).

캐싱 시스템의 기본 요구 사항

캐싱 시스템의 요구 사항이 될 수 있는 첫 번째 사항은 빠른 읽기 속도와 약간 덜한 쓰기 속도입니다. 이는 사실이지만 시스템을 프로덕션 환경으로 출시할 때까지만 해당됩니다.

이 사건을 플레이해보자.

현재 로드에 하드웨어를 제공했으며 점차적으로 캐싱을 도입하고 있다고 가정해 보겠습니다. 사용자 수가 조금 늘어나고 로드도 늘어납니다. 약간의 캐시를 추가하고 여기저기에 나사를 조입니다. 이는 한동안 계속되며 이제 무거운 기능은 더 이상 호출되지 않습니다. 전체 기본 로드가 캐시에 저장됩니다. 이 기간 동안 사용자 수가 N배 증가했습니다.

그리고 초기 하드웨어 공급이 2~5배일 수 있다면 캐시의 도움으로 성능을 10배, 좋은 경우에는 100배, 어떤 곳에서는 1000배 향상할 수 있습니다. 즉, 동일한 하드웨어에서 100배 더 많은 요청을 처리합니다. 좋아요, 당신은 진저브레드를 먹을 자격이 있어요!

그런데 지금 어느 좋은 순간에 우연히 시스템이 충돌하고 캐시가 무너졌습니다. 특별한 것은 없습니다. 결국 캐시는 "높은 읽기 및 쓰기 속도, 나머지는 중요하지 않습니다"라는 요구 사항에 따라 선택되었습니다.

시작 부하에 비해 철 보유량은 2~5배였으며 이 기간 동안 부하는 10~100배 증가했습니다. 캐시를 사용하여 무거운 기능에 대한 호출을 제거하여 모든 것이 작동했습니다. 이제 캐시가 없으면 시스템 속도가 몇 번이나 느려질까요? 우리에게 무슨 일이 일어날까요? 시스템이 무너질 것입니다.

캐시가 충돌하지 않고 잠시 동안만 비워진 경우에도 워밍업이 필요하며 시간이 좀 걸립니다. 그리고 이 기간 동안 가장 큰 부담은 기능에 있습니다.

결론: 로드가 많은 프로덕션 프로젝트에는 읽기 및 쓰기 속도가 빠를 뿐만 아니라 데이터 안전과 오류 방지를 보장하는 캐싱 시스템이 필요합니다.

선택의 밀가루

관리자 패널이 있는 프로젝트에서 선택은 다음과 같습니다. 먼저 Hazelcast를 설치했습니다. 우리는 이미 메인 사이트의 경험을 통해 이 제품에 대해 잘 알고 있었습니다. 그러나 여기서 이 선택은 실패한 것으로 나타났습니다. 로드 프로필에서 Hazelcast는 느릴 뿐만 아니라 매우 느립니다. 그리고 그 당시 우리는 이미 출시일을 등록했습니다.

스포일러: 우리가 그렇게 큰 일을 놓치고 급박하고 긴박한 상황에 이르게 된 상황이 정확히 어떻게 전개되었는지 - 두 번째 부분에서 말씀드리겠습니다. 그리고 우리가 어떻게 끝나고 어떻게 빠져나왔는지. 하지만 지금은 스트레스가 너무 많았고 "생각하기에는 어쩐지 생각이 안 나네요. 우리가 병을 흔들고 있습니다."라고 말하고 싶습니다. "병을 흔드는 것" 역시 스포일러입니다. 이에 대해서는 나중에 자세히 설명하겠습니다.

우리가 한 일:

1. Google과 StackOverflow가 제안하는 모든 시스템 목록을 작성합니다. 30 조금 넘음
2. 우리는 프로덕션에 일반적인 로드를 사용하여 테스트를 작성합니다. 이를 위해 우리는 프로덕션 환경에서 시스템을 통과하는 데이터를 기록했습니다. 이는 네트워크가 아닌 시스템 내부의 데이터를 탐지하는 일종의 스니퍼입니다. 정확히 이 데이터가 테스트에 사용되었습니다.
3. 팀 전체가 목록에서 다음 시스템을 선택하고 구성하고 테스트를 실행합니다. 그것은 테스트를 통과하지 못하고, 짐을 지탱하지 못합니다. 우리는 그것을 버리고 다음 줄로 넘어갑니다.
4. 17일 시스템에서는 모든 것이 절망적이라는 것이 분명해졌습니다. 병을 흔들지 말고 진지하게 생각할 때입니다.

그러나 이는 사전 준비된 테스트에서 "속도를 통과"할 시스템을 선택해야 하는 경우의 옵션입니다. 아직 그러한 테스트가 없고 빨리 선택하고 싶다면 어떻게 해야 할까요?

이 옵션을 모델링해 보겠습니다(중간 이상의 개발자가 공백 상태에 살고 있으며 선택 당시 어떤 제품을 먼저 시도할지에 대한 선호도를 아직 공식화하지 않았다고 상상하기 어렵습니다. 따라서 추가 추론은 이론가/철학/에 더 가깝습니다. 후배 정도).

요구 사항을 결정한 후 즉시 솔루션을 선택하기 시작합니다. 바퀴를 재발명해야 하는 이유: 기성 캐싱 시스템을 사용하겠습니다.

방금 시작하고 Google에 검색하면 주문을 주거나 받겠지만 일반적으로 지침은 다음과 같습니다. 우선 Redis를 만나게 될 것입니다. 어디에서나 들립니다. 그러면 EhCache가 가장 오래되고 가장 입증된 시스템이라는 것을 알게 될 것입니다. 다음으로 솔루션의 독특한 면모를 지닌 국내 개발사인 Tarantool에 대해 글을 써보겠습니다. 또한 Ignite는 현재 인기가 높아지고 있으며 SberTech의 지원을 받고 있기 때문입니다. 마지막에는 Hazelcast도 있습니다. 왜냐하면 기업 세계에서는 대기업 사이에 자주 나타나기 때문입니다.

목록은 완전하지 않으며 수십 개의 시스템이 있습니다. 그리고 우리는 한 가지만 망칠 것입니다. '미인 콘테스트'에 선정된 5개 시스템을 선택해 보겠습니다. 누가 승자가 될까요?

Redis

우리는 그들이 공식 웹사이트에 쓴 글을 읽었습니다.
Redis - 오픈소스 프로젝트. 인메모리 데이터 스토리지, 디스크에 저장하는 기능, 자동 파티셔닝, 고가용성 및 네트워크 중단 복구 기능을 제공합니다.

모든 것이 괜찮은 것 같습니다. 가져 가서 조일 수 있습니다. 필요한 모든 것이 그렇습니다. 하지만 재미삼아 다른 후보들을 살펴보겠습니다.

Eh캐시

Eh캐시 - "가장 널리 사용되는 Java용 캐시"(공식 웹사이트의 슬로건 번역) 또한 오픈 소스. 그리고 Redis는 Java용이 아니라 일반용이며 Redis와 상호 작용하려면 래퍼가 필요하다는 것을 이해합니다. 그리고 EhCache가 더 편리해질 것입니다. 시스템은 또 무엇을 약속합니까? 신뢰성, 입증된 전체 기능. 글쎄, 그것은 또한 가장 일반적입니다. 그리고 테라바이트 규모의 데이터를 캐시합니다.

Redis는 잊혀졌고 EhCache를 선택할 준비가 되었습니다.

하지만 애국심 때문에 Tarantool의 장점이 무엇인지 알게 되었습니다.

타란툴

타란툴 - "실시간 데이터 통합 ​​플랫폼"이라는 명칭을 충족합니다. 매우 복잡하게 들리므로 페이지를 자세히 읽어보니 "RAM에 데이터를 100% 캐시합니다."라는 큰 문구가 나와 있습니다. 이는 질문을 제기해야 합니다. 결국 메모리보다 데이터가 훨씬 더 많을 수 있습니다. 설명은 Tarantool이 메모리에서 디스크에 데이터를 쓰기 위해 직렬화를 실행하지 않는다는 의미입니다. 대신 메모리가 매우 우수한 I/O 성능을 갖춘 파일 시스템에 매핑되는 경우 시스템의 낮은 수준 기능을 사용합니다. 일반적으로 그들은 훌륭하고 멋진 일을 해냈습니다.

구현을 살펴보겠습니다: Mail.ru 기업 고속도로, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...

Tarantool에 대해 여전히 의문점이 있다면 Mastercard의 구현 사례가 나를 마무리합니다. 저는 타란툴을 먹습니다.

하지만 어쨌든…

불을 붙이다

… 더 있나요? 불을 붙이다, "인메모리 컴퓨팅 플랫폼...페타바이트 데이터의 인메모리 속도"로 청구됩니다. 여기에는 분산된 인메모리 캐시, 가장 빠른 키-값 저장 및 캐시, 수평적 확장, 고가용성, 엄격한 무결성 등 많은 장점도 있습니다. 일반적으로 가장 빠른 것은 Ignite입니다.

구현: Sberbank, American Airlines, Yahoo! 일본. 그러다가 Ignite가 Sberbank에서만 구현되는 것이 아니라 SberTech 팀이 제품을 개선하기 위해 직원을 Ignite 팀 자체에 파견한다는 사실을 알게 되었습니다. 이것은 완전히 매혹적이며 Ignite를 선택할 준비가 되었습니다.

이유가 완전히 불분명합니다. 저는 다섯 번째 요점을 보고 있습니다.

헤이젤 캐스트

나는 사이트에 간다. 헤이젤 캐스트, 독서. 그리고 분산 캐싱을 위한 가장 빠른 솔루션은 Hazelcast라는 것이 밝혀졌습니다. 이는 다른 모든 솔루션보다 훨씬 빠르며 일반적으로 인메모리 데이터 그리드 분야의 선두주자입니다. 이런 배경에서 다른 것을 취하는 것은 자신을 존중하는 것이 아닙니다. 또한 데이터 손실 없이 클러스터를 지속적으로 운영하기 위해 중복 데이터 스토리지를 사용합니다.

이제 Hazelcast를 사용할 준비가 되었습니다.

비교

하지만 보시면 다섯 명의 후보자 모두 각자가 최고라는 방식으로 설명되어 있습니다. 선택하는 방법? 어느 것이 가장 인기가 있는지 확인하고 비교를 찾아보면 두통이 사라질 것입니다.

우리는 이런 것을 발견합니다 개요, 5가지 시스템을 선택하세요.

여기에서는 정렬되어 있습니다. Redis가 XNUMX위, Hazelcast가 XNUMX위, Tarantool과 Ignite가 인기를 얻고 있으며 EhCache는 예전이나 지금이나 동일하게 유지됩니다.

하지만 살펴보자 계산 방법: 웹사이트 링크, 시스템에 대한 일반적인 관심, 구인 정보 - 좋습니다! 즉, 내 시스템이 실패하면 나는 이렇게 말할 것입니다. “아니요, 믿을만해요! 채용공고가 많이 나오네요..." 이런 단순한 비교는 불가능합니다.

이러한 시스템은 모두 단순한 캐싱 시스템이 아닙니다. 또한 데이터가 처리를 위해 클라이언트로 펌핑되지 않는 경우를 포함하여 많은 기능이 있지만 그 반대의 경우도 마찬가지입니다. 데이터에 대해 실행해야 하는 코드가 서버로 이동하여 그곳에서 실행되고 결과가 반환됩니다. 그리고 캐싱을 위한 별도의 시스템으로 간주되는 경우가 많지 않습니다.

좋아, 포기하지 말고 시스템을 직접 비교해보자. Redis와 Hazelcast라는 상위 두 가지 옵션을 선택해 보겠습니다. 우리는 속도에 관심이 있고, 이 매개변수를 기반으로 비교하겠습니다.

HZ 대 Redis

우리는 이것을 발견합니다 비교:


파란색은 Redis, 빨간색은 Hazelcast입니다. Hazelcast는 모든 곳에서 승리하며 이에 대한 근거가 있습니다. 다중 스레드이고 고도로 최적화되어 있으며 각 스레드는 자체 파티션에서 작동하므로 차단이 없습니다. 그리고 Redis는 단일 스레드이므로 최신 멀티 코어 CPU의 이점을 얻지 못합니다. Hazelcast에는 비동기 I/O가 있고 Redis-Jedis에는 차단 소켓이 있습니다. 결국 Hazelcast는 바이너리 프로토콜을 사용하고 Redis는 텍스트 중심이므로 비효율적입니다.

혹시라도 다른 비교 소스를 살펴 보겠습니다. 그는 우리에게 무엇을 보여줄까요?

Redis 대 Hz

또 다른 비교:


여기서 반대로 빨간색은 Redis입니다. 즉, Redis는 성능 면에서 Hazelcast를 능가합니다. Hazelcast가 첫 번째 비교에서 승리했고 Redis가 두 번째 비교에서 승리했습니다. 여기 Hazelcast가 이전 비교에서 승리한 이유를 매우 정확하게 설명했습니다.

첫 번째 결과는 실제로 조작된 것으로 밝혀졌습니다. Redis는 기본 상자에 포함되었고 Hazelcast는 테스트 사례에 맞게 조정되었습니다. 그러다가 밝혀졌습니다. 첫째, 우리는 누구도 믿을 수 없으며, 둘째, 최종적으로 시스템을 선택한 후에도 시스템을 올바르게 구성해야 합니다. 이러한 설정에는 수십, 거의 수백 개의 매개변수가 포함됩니다.

병을 흔드는 중

그리고 우리가 지금까지 해왔던 전체 과정을 다음과 같은 비유로 설명할 수 있습니다: “병을 흔들다.” 즉, 이제 프로그래밍할 필요가 없으며 이제 가장 중요한 것은 stackoverflow를 읽을 수 있다는 것입니다. 그리고 내 팀에는 중요한 순간에 이와 똑같이 일하는 전문가가 있습니다.

그는 무엇을 하고 있나요? 그는 깨진 것을 보고, 스택 추적을 보고, 거기에서 몇 가지 단어(프로그램에 대한 그의 전문 지식)를 가져오고, Google에서 검색하고, 답변 중에서 stackoverflow를 찾습니다. 읽지 않고, 생각하지 않고, 질문에 대한 답변 중에서 그는 "이것 저것 하라"라는 문장과 가장 유사한 것을 선택합니다(그런 대답을 선택하는 것은 그의 재능입니다. 항상 가장 많은 좋아요를 받은 대답은 아니기 때문입니다). Apply ,looks: 뭔가 변경된 것이 있다면 좋습니다. 변경되지 않은 경우 롤백합니다. 그리고 실행-확인-검색을 반복하세요. 그리고 이러한 직관적인 방식으로 그는 일정 시간이 지난 후에도 코드가 작동하는지 확인합니다. 그는 왜 그랬는지 모르고, 자신이 무엇을 했는지도 모르고, 설명할 수도 없습니다. 하지만! 이 감염은 효과가 있습니다. 그리고 “불이 꺼졌습니다.” 이제 우리가 무엇을 했는지 알아봅시다. 프로그램이 작동하면 훨씬 더 쉬워집니다. 그리고 시간이 많이 절약됩니다.

이 방법은 이 예를 통해 매우 잘 설명됩니다.

한때 범선을 병에 담아 모으는 것이 매우 인기가 있었습니다. 동시에 범선은 크고 깨지기 쉬우며 병의 목이 매우 좁아서 안으로 밀어 넣는 것이 불가능합니다. 그것을 조립하는 방법?

매우 빠르고 효과적인 방법이 있습니다.

배는 막대기, 밧줄, 돛, 접착제 등 여러 가지 작은 것들로 구성됩니다. 우리는 이 모든 것을 병에 담았습니다.
우리는 양손으로 병을 잡고 흔들기 시작합니다. 우리는 그녀를 흔들고 흔들었습니다. 물론 일반적으로 그것은 완전한 쓰레기로 판명됩니다. 하지만 가끔은. 때로는 배로 밝혀지기도 합니다! 더 정확하게는 배와 비슷한 것입니다.

우리는 이것을 누군가에게 보여줍니다. “세료가, 보이시나요!?” 그리고 실제로 멀리서 보면 배처럼 보입니다. 그러나 이것이 계속되는 것을 허용할 수는 없습니다.

또 다른 방법이 있습니다. 해커와 같은 고급 사용자가 사용합니다.

나는 그 사람에게 임무를 주었고 그는 모든 것을 다하고 떠났습니다. 그리고 당신은 그것이 끝난 것처럼 보입니다. 그리고 잠시 후, 코드를 마무리해야 할 때, 그 사람 때문에 이런 일이 시작되는데... 그 사람이 벌써 멀리 도망가서 다행이다. 이들은 병의 예를 사용하여 이렇게 할 사람들입니다. 보시다시피 바닥이 있는 곳에서는 유리가 구부러집니다. 그리고 그것이 투명한지 아닌지는 완전히 명확하지 않습니다. 그러면 '해커'들이 이 바닥을 잘라 거기에 배를 꽂고 다시 바닥을 풀로 붙이면 원래 그런 모양이 되는 것입니다.

문제를 설정하는 관점에서 보면 모든 것이 올바른 것 같습니다. 하지만 배를 예로 들면, 도대체 왜 이 배를 만드는 걸까요? 어쨌든 누가 필요할까요? 어떠한 기능도 제공하지 않습니다. 일반적으로 그러한 배는 일종의 상징, 표시로 위의 선반에 올려 놓은 매우 고위층에게 선물입니다. 그리고 그런 사람이 대기업 대표나 고위 공직자라면 목이 잘린 해킹을 어떻게 깃발이 세울 것인가? 그가 그것에 대해 전혀 몰랐다면 더 좋았을 것입니다. 그렇다면 소중한 사람에게 선물할 수 있는 배를 어떻게 만들까요?

실제로 아무것도 할 수 없는 유일한 핵심 장소는 신체입니다. 그리고 배의 선체가 목에 꼭 맞습니다. 배는 병 밖에서 조립되는 반면. 하지만 그것은 단지 배를 조립하는 것이 아니라, 진짜 보석 공예입니다. 특수 레버가 구성 요소에 추가되어 들어올릴 수 있습니다. 예를 들어, 돛을 접고 조심스럽게 안쪽으로 가져온 다음 핀셋을 사용하여 매우 정밀하고 정밀하게 당겨서 들어 올립니다. 그 결과, 깨끗한 양심과 자부심을 지닌 예술 작품이 탄생하게 되었습니다.

그리고 프로젝트가 성공하려면 팀에 보석 세공사가 한 명 이상 있어야 합니다. 제품의 품질에 관심을 갖고 중요한 일을 희생하고 긴급한 일을 해야 하는 상황에서 스트레스를 받는 순간에도 아무것도 희생하지 않고 모든 측면을 고려하는 사람입니다. 지속 가능하고 시간의 시험을 견뎌낸 모든 성공적인 프로젝트는 이 원칙을 바탕으로 구축되었습니다. 그들에게는 매우 정확하고 독특한 것이 있으며, 가능한 모든 가능성을 활용하는 것이 있습니다. 병 속의 배가 있는 예에서는 배의 선체가 목을 통과한다는 사실이 표현됩니다.

캐싱 서버를 선택하는 작업으로 돌아가서 이 방법을 어떻게 적용할 수 있을까요? 저는 존재하는 모든 시스템 중에서 선택할 수 있는 옵션을 제공합니다. 병을 흔들거나 선택하지 말고 원칙적으로 무엇이 있는지, 시스템을 선택할 때 무엇을 찾아야 하는지 살펴보세요.

병목 현상을 찾을 수 있는 곳

병을 흔들지 말고, 거기에 있는 모든 것을 하나씩 살펴보지 말고, 우리가 갑자기 우리 작업을 위해 그러한 시스템을 직접 설계하면 어떤 작업이 발생하는지 봅시다. 물론, 자전거를 조립하지는 않겠지만, 이 도표를 참고하여 제품설명에서 주의할 점을 파악하도록 하겠습니다. 그러한 다이어그램을 스케치해 봅시다.

시스템이 분산되어 있으면 여러 대의 서버(6)를 갖게 됩니다. XNUMX개가 있다고 가정해 보겠습니다(사진에 배치하는 것이 편리하지만 물론 원하는 만큼 많이 있을 수 있습니다). 서버가 서로 다른 노드에 있는 경우 이는 해당 노드가 클러스터를 형성하고 중단 시 서로 연결하고 인식하도록 하는 일부 코드를 실행한다는 의미입니다.

실제로 캐싱에 관한 코드 논리(2)도 필요합니다. 클라이언트는 일부 API를 통해 이 코드와 상호 작용합니다. 클라이언트 코드 (1)은 동일한 JVM 내에 있거나 네트워크를 통해 액세스할 수 있습니다. 내부에 구현된 논리는 어떤 개체를 캐시에 남겨두고 어떤 개체를 버릴 것인지 결정하는 것입니다. 캐시를 저장하기 위해 메모리(3)를 사용하지만 필요한 경우 일부 데이터를 디스크(4)에 저장할 수 있습니다.

어느 부분에서 부하가 발생하는지 살펴보겠습니다. 실제로 모든 화살표와 모든 노드가 로드됩니다. 첫째, 클라이언트 코드와 API 사이, 이것이 네트워크 통신이라면 침강이 상당히 눈에 띌 수 있습니다. 둘째, API 자체의 프레임워크 내에서 복잡한 로직을 과도하게 사용하면 CPU에 문제가 발생할 수 있습니다. 그리고 논리가 기억에 시간을 낭비하지 않는다면 좋을 것입니다. 그리고 파일 시스템과의 상호 작용이 남아 있습니다. 일반적인 버전에서는 직렬화/복원 및 쓰기/읽기가 이루어집니다.

다음은 클러스터와의 상호작용입니다. 대부분 동일한 시스템에 있을 것이지만 별도로 존재할 수도 있습니다. 여기서는 데이터 전송, 데이터 직렬화 속도 및 클러스터 간의 상호 작용도 고려해야 합니다.

이제 우리는 코드의 요청을 처리할 때 캐시 시스템에서 "어떤 기어가 회전할지"를 상상할 수 있고, 다른 한편으로는 코드가 이 시스템에 생성할 요청의 내용과 수를 추정할 수 있습니다. 이것은 우리의 사용 사례에 맞는 시스템을 선택하기 위해 다소 냉정한 선택을 하는 데 충분합니다.

헤이젤 캐스트

이 분해를 목록에 적용하는 방법을 살펴보겠습니다. 예를 들어 헤이즐캐스트.

Hazelcast에서 데이터를 넣거나 가져오기 위해 클라이언트 코드는 (1) API에 액세스합니다. Hz를 사용하면 서버를 임베디드로 실행할 수 있으며, 이 경우 API에 액세스하는 것은 JVM 내부의 메소드 호출이므로 무료로 간주할 수 있습니다.

(2)의 논리가 작동하기 위해 Hz는 직렬화된 키의 바이트 배열 해시에 의존합니다. 즉, 키는 어떤 경우에도 직렬화됩니다. 이는 Hz에 있어서 불가피한 오버헤드입니다.
퇴거 전략은 잘 구현되어 있지만 특별한 경우에는 자신만의 전략을 추가할 수 있습니다. 이 부분은 걱정하지 않으셔도 됩니다.

저장소(4)를 연결할 수 있습니다. 엄청난. 임베디드에 대한 상호작용(5)은 즉각적인 것으로 간주될 수 있습니다. 클러스터의 노드 간 데이터 교환(6) - 예, 존재합니다. 이는 속도를 희생하면서 내결함성에 대한 투자입니다. Hz 기능인 Near-cache를 사용하면 가격을 낮출 수 있습니다. 클러스터의 다른 노드에서 수신된 데이터는 캐시됩니다.

이러한 상황에서 속도를 높이려면 어떻게 해야 합니까?

예를 들어 (2)의 키 직렬화를 방지하려면 가장 인기 있는 데이터를 위해 Hazelcast 위에 다른 캐시를 연결하세요. Sportmaster는 이러한 목적으로 카페인을 선택했습니다.

레벨(6)에서의 비틀기의 경우, Hz는 IMap과 ReplicatedMap이라는 두 가지 유형의 저장소를 제공합니다.


Hazelcast가 어떻게 Sportmaster 기술 스택에 합류했는지 언급할 가치가 있습니다.

2012년에 우리가 미래 사이트의 첫 번째 파일럿 작업을 하고 있을 때 검색 엔진이 반환한 첫 번째 링크는 Hazelcast였습니다. 지인은 "처음으로"시작되었습니다. 우리는 불과 XNUMX시간 후에 시스템에 Hz를 연결했을 때 작동했다는 사실에 매료되었습니다. 그리고 그것은 잘 작동했습니다. 하루가 끝날 무렵 우리는 여러 가지 테스트를 완료했고 행복했습니다. 그리고 이러한 활력은 시간이 지남에 따라 Hz가 토해낸 놀라움을 극복하기에 충분했습니다. 이제 Sportmaster 팀은 Hazelcast를 포기할 이유가 없습니다.

그러나 "검색 엔진의 첫 번째 링크" 및 "HelloWorld가 빠르게 조립되었습니다"와 같은 주장은 물론 예외이자 선택이 발생한 순간의 특징입니다. 선택한 시스템에 대한 실제 테스트는 프로덕션 릴리스부터 시작되며, 캐시를 포함한 시스템을 선택할 때 주의를 기울여야 하는 것은 바로 이 단계입니다. 사실 우리의 경우에는 우연히 Hazelcast를 선택했다고 말할 수 있지만 알고 보니 우리가 선택한 것이 옳았습니다.

프로덕션의 경우 모니터링, 개별 노드의 오류 처리, 데이터 복제, 확장 비용이 훨씬 더 중요합니다. 즉, 로드가 계획보다 수십 배 높을 때, 실수로 잘못된 위치에 무언가를 업로드할 때, 새 버전을 출시해야 할 때 등 시스템 유지 관리 중에 정확하게 발생하는 작업에 주의를 기울일 가치가 있습니다. 코드를 작성하고, 데이터를 대체하고 클라이언트가 눈치채지 못하도록 수행합니다.

이러한 모든 요구 사항에 대해 Hazelcast는 확실히 적합합니다.

계속하려면

하지만 헤이즐캐스트는 만병통치약이 아닙니다. 2017년에는 단순히 과거 경험에서 얻은 좋은 인상을 바탕으로 관리자 캐시로 Hazelcast를 선택했습니다. 이것은 매우 잔인한 농담에서 핵심적인 역할을 했으며, 이로 인해 우리는 어려운 상황에 처해 있었고 60일 동안 "영웅적으로" 그 상황에서 빠져나왔습니다. 하지만 이에 대해서는 다음 부분에서 자세히 설명합니다.

그 동안... 새 코드를 즐기세요!

출처 : habr.com