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

어떤 언어로든 부하가 큰 프로젝트를 개발하려면 특별한 접근 방식과 특수 도구 사용이 필요하지만 PHP 애플리케이션의 경우 상황이 너무 악화되어 다음과 같은 작업을 개발해야 할 수 있습니다. 자체 애플리케이션 서버. 이 글에서는 memcached에서 분산 세션 저장과 데이터 캐싱을 할 때 흔히 겪는 어려움에 대해 이야기하고, 이러한 문제를 하나의 "ward" 프로젝트에서 어떻게 해결했는지 알아보겠습니다.

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

우리는 제공해야 했습니다 최소한의 노력으로 애플리케이션을 수평적으로 확장할 수 있는 기능즉, 소스 코드를 최소한으로 변경하고 기능을 완전히 보존하는 것을 의미합니다. 캐시를 내결함성만 높이는 것이 아니라, 캐시에서 발생하는 데이터 손실을 최소화하도록 하세요.

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

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

세션 저장소를 사용하면 상황이 조금 더 좋아집니다. 다음을 구성할 수 있습니다. memcached.sess_number_of_replicas따라서 데이터는 여러 서버에 동시에 저장되고, 하나의 memcached 인스턴스가 실패하면 다른 인스턴스에서 데이터가 반환됩니다. 하지만 서버가 데이터 없이 다시 온라인 상태가 되면(일반적으로 재시작 후 발생함) 일부 키가 서버에 유리하게 재분배됩니다. 사실, 이것은 다음을 의미합니다. 세션 데이터 손실실패할 경우 다른 복제본으로 "이동"할 가능성이 없기 때문입니다.

표준 라이브러리 도구는 주로 다음을 목표로 합니다. 수평 확장성: 캐시를 거대한 크기로 확장할 수 있고 다른 서버에 호스팅된 코드에서 액세스할 수 있습니다. 하지만 우리의 상황에서는 저장된 데이터의 양이 수 기가바이트를 넘지 않으며, 1~2개 노드의 성능으로도 충분히 충분합니다. 따라서 표준 도구가 할 수 있는 유일한 유용한 일은 적어도 하나의 캐시 인스턴스를 작동 순서대로 유지하면서 memcached의 가용성을 보장하는 것입니다. 하지만 이 기회조차 활용되지 못했습니다. 이 부분에서는 프로젝트에 사용된 프레임워크가 너무 오래되어 서버 풀에서 애플리케이션을 작동시킬 수 없었다는 점을 상기해 볼 가치가 있습니다. 세션 데이터 손실을 잊지 마세요. 사용자의 대량 로그아웃으로 인해 고객의 눈이 씰룩거렸습니다.

이상적으로는 필요했습니다 memcached 쓰기 복제 및 복제본 순회 실수나 오류가 발생한 경우. 우리는 다음의 도움으로 이 전략을 구현할 수 있었습니다. 맥라우터.

맥라우터

이는 Facebook이 자사의 문제를 해결하기 위해 개발한 memcached 라우터입니다. memcached 텍스트 프로토콜을 지원하여 다음을 허용합니다. Memcached 설치 확장 엄청난 크기입니다. mcrouter에 대한 자세한 설명은 다음에서 찾을 수 있습니다. 이 발표에서. 다른 것들 중 폭넓은 기능 그는 우리에게 필요한 것을 할 수 있습니다.

• 기록 복제
• 오류가 발생할 경우 그룹의 다른 서버로 대체합니다.

원인을 위해!

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"
       ]
     }
   }
 }
}

왜 수영장이 세 개일까? 서버가 반복되는 이유는 무엇입니까? 이것이 어떻게 작동하는지 알아보겠습니다.

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

메인 마이너스 이 계획은 캐시에 실제로 데이터가 없는 경우 클라이언트의 각 요청에 대해 실제로 memcached에 대한 N개의 요청이 실행된다는 것입니다. 모두 풀 내의 서버. 예를 들어 풀의 서버 수를 2개로 줄이는 것이 가능합니다. 스토리지 안정성을 희생함으로써 b를 얻게 됩니다.о열쇠 분실 요청으로 인한 부담을 줄이고 처리 속도를 높입니다.

NB: mcrouter 학습에 유용한 링크도 있습니다. 위키 문서 и 프로젝트 문제 (폐쇄형도 포함) 다양한 구성의 귀중한 보물 창고를 나타냅니다.

mcrouter 빌드 및 실행

저희 애플리케이션(그리고 memcached 자체)은 Kubernetes에서 실행되므로 mcrouter도 거기에 있습니다. 을 위한 컨테이너 조립 우리는 사용 워프, 이에 대한 구성은 다음과 같습니다.

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