mcrouter를 사용하여 memcached를 수평으로 확장

어떤 언어로든 부하가 높은 프로젝트를 개발하려면 특별한 접근 방식과 특별한 도구를 사용해야 하지만, PHP로 애플리케이션을 개발할 경우 상황이 너무 악화되어 예를 들어 다음과 같이 개발해야 할 수 있습니다. 자체 애플리케이션 서버. 이 노트에서는 memcached의 분산 세션 저장 및 데이터 캐싱과 관련된 익숙한 문제와 이러한 문제를 하나의 "와드" 프로젝트에서 해결한 방법에 대해 설명합니다.

이번 행사의 주인공은 업데이트할 사업 계획에 전혀 포함되지 않은 심포니 2.3 프레임워크를 기반으로 한 PHP 애플리케이션입니다. 이 프로젝트는 꽤 표준적인 세션 스토리지 외에도 다음을 최대한 활용했습니다. "모든 것을 캐싱" 정책 memcached: 데이터베이스 및 API 서버에 대한 요청에 대한 응답, 다양한 플래그, 코드 실행 동기화를 위한 잠금 등. 이러한 상황에서는 memcached의 고장이 애플리케이션 작동에 치명적이 됩니다. 또한 캐시 손실은 심각한 결과를 초래합니다. DBMS가 경계선에서 버스트되기 시작하고 API 서비스가 요청을 금지하기 시작하는 등의 문제가 발생합니다. 상황을 안정화하는 데는 수십 분이 걸릴 수 있으며, 이 시간 동안에는 서비스가 매우 느려지거나 완전히 사용할 수 없게 됩니다.

우리는 제공해야했습니다 적은 노력으로 애플리케이션을 수평적으로 확장할 수 있는 능력, 즉. 소스 코드를 최소한으로 변경하고 전체 기능을 보존합니다. 캐시가 오류에 강할 뿐만 아니라 캐시로 인한 데이터 손실을 최소화하도록 노력하십시오.

memcached 자체에 어떤 문제가 있나요?

일반적으로 PHP용 memcached 확장은 기본적으로 분산 데이터 및 세션 저장을 지원합니다. 일관된 키 해싱 메커니즘을 사용하면 여러 서버에 데이터를 균등하게 배치하여 각 특정 키를 그룹의 특정 서버에 고유하게 주소를 지정할 수 있으며 내장된 장애 조치 도구는 캐싱 서비스의 고가용성을 보장합니다. 데이터 없음).

세션 저장소를 사용하면 상황이 조금 더 좋아집니다. 구성할 수 있습니다. memcached.sess_number_of_replicas, 결과적으로 데이터는 한 번에 여러 서버에 저장되며 하나의 memcached 인스턴스에 오류가 발생하면 데이터가 다른 서버에서 전송됩니다. 그러나 서버가 데이터 없이 다시 온라인 상태가 되면(일반적으로 다시 시작한 후 발생) 일부 키가 서버에 유리하게 재분배됩니다. 실제로 이것은 의미합니다 세션 데이터 손실, 누락된 경우 다른 복제본으로 "이동"할 방법이 없기 때문입니다.

표준 라이브러리 도구는 주로 다음을 목표로 합니다. 수평 확장: 캐시를 거대한 크기로 늘리고 다른 서버에 호스팅된 코드에서 캐시에 대한 액세스를 제공할 수 있습니다. 그러나 우리 상황에서는 저장된 데이터의 양이 수 기가바이트를 초과하지 않으며 노드 한두 개 정도의 성능이면 충분합니다. 따라서 유일한 유용한 표준 도구는 적어도 하나의 캐시 인스턴스를 작동 상태로 유지하면서 memcached의 가용성을 보장하는 것입니다. 하지만 이 기회조차 활용할 수 없었습니다... 여기서는 프로젝트에 사용된 프레임워크의 오래됨을 상기할 가치가 있습니다. 이것이 바로 애플리케이션이 서버 풀과 함께 작동하도록 하는 것이 불가능했던 이유입니다. 세션 데이터 손실도 잊지 마세요. 대규모 사용자 로그아웃에 고객의 눈이 꿈틀거렸습니다.

이상적으로는 필수였습니다. Memcached의 레코드 복제 및 복제본 우회 실수나 실수가 있는 경우. 이 전략을 구현하는 데 도움이 되었습니다. 맥라우터.

맥라우터

이것은 Facebook이 이러한 문제를 해결하기 위해 개발한 Memcached 라우터입니다. 이는 memcached 텍스트 프로토콜을 지원합니다. memcached 설치 확장 미친 비율로. mcrouter에 대한 자세한 설명은 다음에서 확인할 수 있습니다. 이 발표. 다른 것들 사이 다양한 기능 그것은 우리에게 필요한 것을 할 수 있습니다:

• 복제 기록;
• 오류가 발생하면 그룹의 다른 서버로 대체합니다.

원인을 위해!

마이크로터 구성

바로 구성으로 이동하겠습니다.

{
 "pools": {
   "pool00": {
     "servers": [
       "mc-0.mc:11211",
       "mc-1.mc:11211",
       "mc-2.mc:11211"
   },
   "pool01": {
     "servers": [
       "mc-1.mc:11211",
       "mc-2.mc:11211",
       "mc-0.mc:11211"
   },
   "pool02": {
     "servers": [
       "mc-2.mc:11211",
       "mc-0.mc:11211",
       "mc-1.mc:11211"
 },
 "route": {
   "type": "OperationSelectorRoute",
   "default_policy": "AllMajorityRoute|Pool|pool00",
   "operation_policies": {
     "get": {
       "type": "RandomRoute",
       "children": [
         "MissFailoverRoute|Pool|pool02",
         "MissFailoverRoute|Pool|pool00",
         "MissFailoverRoute|Pool|pool01"
       ]
     }
   }
 }
}

왜 수영장이 XNUMX개인가요? 서버가 반복되는 이유는 무엇입니까? 그것이 어떻게 작동하는지 알아 봅시다.

• 이 구성에서 mcrouter는 요청 명령을 기반으로 요청이 전송될 경로를 선택합니다. 그 사람이 그 사람에게 이렇게 말해요. OperationSelectorRoute.
• GET 요청은 핸들러로 이동 RandomRoute배열 개체 중에서 풀이나 경로를 무작위로 선택합니다. children. 이 배열의 각 요소는 차례로 핸들러입니다. MissFailoverRoute, 이는 데이터가 포함된 응답을 받을 때까지 풀의 각 서버를 거치며 클라이언트에 반환됩니다.
• 독점적으로 사용한다면 MissFailoverRoute XNUMX개의 서버 풀을 사용하면 모든 요청이 첫 번째 memcached 인스턴스에 먼저 전달되고 나머지는 데이터가 없을 때 잔여 방식으로 요청을 받게 됩니다. 그러한 접근 방식은 목록의 첫 번째 서버에 과도한 로드가 발생했습니다.따라서 서로 다른 순서의 주소로 XNUMX개의 풀을 생성하고 무작위로 선택하기로 결정했습니다.
• 다른 모든 요청(및 이는 기록)은 다음을 사용하여 처리됩니다. AllMajorityRoute. 이 처리기는 풀의 모든 서버에 요청을 보내고 최소한 N/2 + 1 서버의 응답을 기다립니다. 사용부터 AllSyncRoute 이 방법은 긍정적인 응답이 필요하기 때문에 쓰기 작업을 중단해야 했습니다. 모든 그룹의 서버 - 그렇지 않으면 반환됩니다 SERVER_ERROR. mcrouter는 사용 가능한 캐시에 데이터를 추가하지만 호출하는 PHP 함수는 오류를 반환합니다 통지가 생성됩니다. AllMajorityRoute 그다지 엄격하지 않으며 위에서 설명한 문제 없이 장치의 최대 절반까지 서비스를 중단할 수 있습니다.

메인 마이너스 이 방식은 캐시에 실제로 데이터가 없으면 클라이언트의 각 요청에 대해 memcached에 대한 N개의 요청이 실제로 실행된다는 것입니다. 모두 풀에 있는 서버. 예를 들어 풀의 서버 수를 XNUMX개로 줄일 수 있습니다. 즉, 스토리지 안정성이 희생됩니다.о키 누락에 대한 요청에서 더 빠른 속도와 더 적은 부하가 발생합니다.

NB: mcrouter 학습에 유용한 링크를 찾을 수도 있습니다. 위키 문서 и 프로젝트 문제 (닫힌 것 포함), 다양한 구성의 전체 창고를 나타냅니다.

mcrouter 빌드 및 실행

우리 애플리케이션(및 memcached 자체)은 Kubernetes에서 실행됩니다. 따라서 mcrouter도 Kubernetes에 있습니다. 을 위한 컨테이너 조립 우리는 사용 워프, 구성은 다음과 같습니다.

NB: 기사에 제공된 목록은 저장소에 게시됩니다. 플란트/맥라우터.

configVersion: 1
project: mcrouter
deploy:
 namespace: '[[ env ]]'
 helmRelease: '[[ project ]]-[[ env ]]'
---
image: mcrouter
from: ubuntu:16.04
mount:
- from: tmp_dir
 to: /var/lib/apt/lists
- from: build_dir
 to: /var/cache/apt
ansible:
 beforeInstall:
 - name: Install prerequisites
   apt:
     name: [ 'apt-transport-https', 'tzdata', 'locales' ]
     update_cache: yes
 - name: Add mcrouter APT key
   apt_key:
     url: https://facebook.github.io/mcrouter/debrepo/xenial/PUBLIC.KEY
 - name: Add mcrouter Repo
   apt_repository:
     repo: deb https://facebook.github.io/mcrouter/debrepo/xenial xenial contrib
     filename: mcrouter
     update_cache: yes
 - name: Set timezone
   timezone:
     name: "Europe/Moscow"
 - name: Ensure a locale exists
   locale_gen:
     name: en_US.UTF-8
     state: present
 install:
 - name: Install mcrouter
   apt:
     name: [ 'mcrouter' ]

(werf.yaml)

...그리고 스케치해 보세요 투구 차트. 흥미로운 점은 복제본 수를 기반으로 하는 구성 생성기만 있다는 것입니다. (누구나 좀 더 간결하고 우아한 옵션이 있다면 댓글로 공유해주세요):

{{- $count := (pluck .Values.global.env .Values.memcached.replicas | first | default .Values.memcached.replicas._default | int) -}}
{{- $pools := dict -}}
{{- $servers := list -}}
{{- /* Заполняем  массив двумя копиями серверов: "0 1 2 0 1 2" */ -}}
{{- range until 2 -}}
 {{- range $i, $_ := until $count -}}
   {{- $servers = append $servers (printf "mc-%d.mc:11211" $i) -}}
 {{- end -}}
{{- end -}}
{{- /* Смещаясь по массиву, получаем N срезов: "[0 1 2] [1 2 0] [2 0 1]" */ -}}
{{- range $i, $_ := until $count -}}
 {{- $pool := dict "servers" (slice $servers $i (add $i $count)) -}}
 {{- $_ := set $pools (printf "MissFailoverRoute|Pool|pool%02d" $i) $pool -}}
{{- end -}}
---
apiVersion: v1
kind: ConfigMap
metadata:
 name: mcrouter
data:
 config.json: |
   {
     "pools": {{- $pools | toJson | replace "MissFailoverRoute|Pool|" "" -}},
     "route": {
       "type": "OperationSelectorRoute",
       "default_policy": "AllMajorityRoute|Pool|pool00",
       "operation_policies": {
         "get": {
           "type": "RandomRoute",
           "children": {{- keys $pools | toJson }}
         }
       }
     }
   }

(10-mcrouter.yaml)

테스트 환경에 출시하고 다음을 확인합니다.

# php -a
Interactive mode enabled

php > # Проверяем запись и чтение
php > $m = new Memcached();
php > $m->addServer('mcrouter', 11211);
php > var_dump($m->set('test', 'value'));
bool(true)
php > var_dump($m->get('test'));
string(5) "value"
php > # Работает! Тестируем работу сессий:
php > ini_set('session.save_handler', 'memcached');
php > ini_set('session.save_path', 'mcrouter:11211');
php > var_dump(session_start());
PHP Warning:  Uncaught Error: Failed to create session ID: memcached (path: mcrouter:11211) in php shell code:1
Stack trace:
#0 php shell code(1): session_start()
#1 {main}
  thrown in php shell code on line 1
php > # Не заводится… Попробуем задать session_id:
php > session_id("zzz");
php > var_dump(session_start());
PHP Warning:  session_start(): Cannot send session cookie - headers already sent by (output started at php shell code:1) in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Failed to write session lock: UNKNOWN READ FAILURE in php shell code on line 1
PHP Warning:  session_start(): Unable to clear session lock record in php shell code on line 1
PHP Warning:  session_start(): Failed to read session data: memcached (path: mcrouter:11211) in php shell code on line 1
bool(false)
php >

오류 텍스트를 검색해도 결과가 나오지 않았지만 "맥라우터 PHP"최전선에는 프로젝트에서 가장 오래되고 해결되지 않은 문제가 있었습니다. 지원 부족 memcached 바이너리 프로토콜.

NB: memcached의 ASCII 프로토콜은 바이너리 프로토콜보다 느리며 일관된 키 해싱의 표준 수단은 바이너리 프로토콜에서만 작동합니다. 그러나 이는 특정 경우에 문제를 일으키지 않습니다.

트릭은 가방에 있습니다. ASCII 프로토콜로 전환하기만 하면 모든 것이 작동합니다.... 하지만 이 경우에는 답을 찾는 습관이 php.net 문서 잔인한 농담을 했습니다. 거기에서 정답을 찾을 수 없습니다... 물론 섹션의 끝으로 스크롤하지 않는 한 "사용자 기여 메모" 충실할 것이고 부당하게 반대표를 받은 답변.

예, 올바른 옵션 이름은 다음과 같습니다. memcached.sess_binary_protocol. 비활성화해야 하며 그 후에는 세션이 작동하기 시작합니다. 남은 것은 mcrouter가 포함된 컨테이너를 PHP가 포함된 포드에 넣는 것뿐입니다!

결론

따라서 인프라 변경만으로 문제를 해결할 수 있었습니다. 즉, memcached 내결함성 문제가 해결되었고 캐시 스토리지의 신뢰성이 높아졌습니다. 애플리케이션에 대한 명백한 이점 외에도 이는 플랫폼에서 작업할 때 조작할 여지를 제공했습니다. 모든 구성 요소에 예비가 있으면 관리자의 수명이 크게 단순화됩니다. 예, 이 방법에도 단점이 있습니다. "목발"처럼 보일 수 있지만 비용을 절약하고 문제를 묻고 새로운 문제를 일으키지 않는다면 왜 안 될까요?

PS

블로그에서도 읽어보세요.

• "dapp으로 연습하세요" (예를 들어 Symfony-demo 사용): 1부(간단한 애플리케이션 구축) и 2부(Helm을 사용하여 Kubernetes에 Docker 이미지 배포);
• «Kubernetes 생활에서: HTTP 서버가 스페인 사람들을 선호하지 않은 이유".

출처 : habr.com