Mail.ru 클라우드 솔루션 플랫폼에서 내결함성 웹 아키텍처가 구현되는 방법

안녕하세요, 하브르! 저는 시스템 관리팀장인 Artem Karamyshev입니다. Mail.Ru 클라우드 솔루션(MCS). 지난해에는 많은 신제품이 출시되었습니다. 우리는 API 서비스가 쉽게 확장 가능하고, 내결함성이 있으며, 사용자 부하의 급격한 증가에 대비할 수 있는지 확인하고 싶었습니다. 저희 플랫폼은 OpenStack을 기반으로 구현되었으며, 장애 허용 시스템을 구축하기 위해 어떤 구성 요소의 장애 허용 문제를 해결해야 했는지 알려드리고자 합니다. OpenStack을 기반으로 제품을 개발하는 사람들에게는 흥미로울 것 같습니다.

플랫폼의 전반적인 장애 허용도는 구성 요소의 안정성에 따라 결정됩니다. 따라서 우리는 위험을 식별하고 종식시킨 모든 수준을 점진적으로 살펴볼 것입니다.

이 스토리의 비디오 버전은 Uptime 4일차 컨퍼런스에서 조직된 프레젠테이션의 원본 소스입니다. IT수마, 당신은 볼 수 있습니다 Uptime Community YouTube 채널에서.

물리적 아키텍처 내결함성

MCS 클라우드의 퍼블릭 부분은 현재 200개의 Tier III 데이터 센터에 기반을 두고 있으며, 두 데이터 센터 사이에는 물리적 수준에서 서로 다른 경로로 예약된 프라이빗 다크 파이버가 있으며, 처리량은 XNUMXGbps입니다. XNUMX단계 수준은 물리적 인프라에 필요한 수준의 내결함성을 제공합니다.

다크 파이버는 물리적 수준과 논리적 수준 모두에서 예약됩니다. 채널 예약 프로세스는 반복적이었으며, 문제가 발생하기도 했습니다. 우리는 데이터 센터 간 연결을 지속적으로 개선하고 있습니다.

예를 들어, 얼마 전 데이터 센터 근처의 우물에서 작업하던 중 굴삭기가 파이프를 뚫었는데, 이 파이프 안에서 주 광케이블과 백업 광케이블이 모두 발견되었습니다. 데이터 센터와의 안전장치 통신 채널이 어느 순간 우물에서 취약한 것으로 드러났습니다. 그 결과 우리는 인프라의 일부를 잃었습니다. 우리는 결론을 내리고 인접한 우물을 따라 추가 광학 장치를 설치하는 것을 포함한 여러 가지 조치를 취했습니다.

데이터 센터에는 통신 제공자의 접속 지점이 있으며, 우리는 BGP를 통해 접두사를 브로드캐스트합니다. 각 네트워크 방향에 대해 가장 적합한 메트릭이 선택되어 다양한 클라이언트에게 최상의 연결 품질을 제공할 수 있습니다. 한 공급업체를 통한 연결이 끊어지면 사용 가능한 공급업체를 통해 라우팅을 재구축합니다.

공급자가 실패할 경우 자동으로 다음 공급자로 전환됩니다. 데이터 센터 중 하나에 장애가 발생하는 경우, 두 번째 데이터 센터에 서비스의 미러 사본을 두고 전체 부하를 담당합니다.

물리적 인프라 복원력

애플리케이션 수준 내결함성을 위해 사용하는 것

당사의 서비스는 다양한 오픈소스 구성요소를 기반으로 구축되었습니다.

엑사BGP — BGP 기반 동적 라우팅 프로토콜을 사용하여 다양한 기능을 구현하는 서비스입니다. 우리는 이를 광범위하게 사용하여 사용자가 API에 접근하는 데 사용하는 화이트 IP 주소를 광고합니다.

HAProxy — OSI 모델의 다양한 수준에서 매우 유연한 트래픽 분산 규칙을 ​​구성할 수 있는 고부하 분산 장치입니다. HAProxy는 데이터베이스, 메시지 브로커, API 서비스, 웹 서비스, 내부 프로젝트 등 모든 서비스의 부하를 분산하는 데 사용됩니다. 모든 것이 HAProxy 뒤에 있습니다.

API 애플리케이션 — Python으로 작성된 웹 애플리케이션으로, 사용자가 이를 통해 자신의 인프라와 서비스를 관리할 수 있습니다.

근로자 신청 (이하 간단히 워커라고 함) - OpenStack 서비스에서 이것은 API 명령이 인프라로 전송될 수 있도록 하는 인프라 데몬입니다. 예를 들어, 디스크 생성은 작업자에서 발생하고, 생성 요청은 API 애플리케이션에서 발생합니다.

OpenStack 애플리케이션 표준 아키텍처

OpenStack을 위해 개발된 대부분의 서비스는 단일 패러다임을 따르려고 합니다. 서비스는 일반적으로 API와 워커(백엔드 수행자)의 두 부분으로 구성됩니다. 일반적으로 API는 Python으로 작성된 WSGI 애플리케이션으로, 독립 실행형 프로세스(데몬)로 실행되거나 Nginx, Apache와 같은 기성 웹 서버를 사용하여 실행됩니다. API는 사용자의 요청을 처리하고 작업자 애플리케이션에 실행을 위한 추가 지침을 전달합니다. 전송은 메시지 브로커(보통 RabbitMQ)를 사용하여 이루어지며, 다른 브로커는 지원이 부족합니다. 메시지가 브로커에 도달하면 작업자가 이를 처리하고, 필요한 경우 응답을 반환합니다.

이 패러다임은 실패의 공통된 지점, 즉 RabbitMQ와 데이터베이스를 의미합니다. 하지만 RabbitMQ는 하나의 서비스 내에 격리되어 있으며, 이론적으로는 각 서비스마다 개별적으로 적용될 수 있습니다. 따라서 MCS에서는 이러한 서비스를 최대한 분리하고, 각 프로젝트마다 별도의 데이터베이스, 별도의 RabbitMQ를 만듭니다. 이런 접근 방식이 좋은 이유는 취약한 지점에서 사고가 발생하더라도 서비스 전체가 중단되는 것이 아니라 일부만 중단되기 때문입니다.

워커 애플리케이션의 수에 제한이 없으므로 API를 밸런서 뒤에서 수평적으로 쉽게 확장하여 성능과 내결함성을 높일 수 있습니다.

일부 서비스에는 서비스 내 조정이 필요합니다. 즉, API와 작업자 간에 복잡한 순차적 작업이 발생하는 경우입니다. 이 경우 Redis, Memcache 등과 같은 클러스터 시스템인 단일 조정 센터를 사용하여 한 작업자가 다른 작업자에게 해당 작업이 자신에게 할당되었음을 알릴 수 있습니다("제발 맡지 마세요"). 우리는 etcd를 사용합니다. 일반적으로 근로자는 데이터베이스와 적극적으로 소통하고, 데이터베이스에서 정보를 쓰고 읽습니다. 데이터베이스로는 멀티 마스터 클러스터에 있는 mariadb를 사용합니다.

이러한 고전적인 단일 서비스는 일반적으로 수용되는 OpenStack 방식으로 구성됩니다. 이는 확장성과 내결함성 방법이 매우 명확한 폐쇄 시스템으로 볼 수 있습니다. 예를 들어, API 장애 허용성을 보장하려면 API 앞에 밸런서를 설치하면 됩니다. 근로자 수를 늘리면 근로자 규모도 커진다.

이 전체 체계의 약점은 RabbitMQ와 MariaDB입니다. 이들의 아키텍처에 대해서는 별도의 기사로 다룰 만합니다. 이 글에서는 API 장애 허용성에 대해 중점적으로 다루고자 합니다.

오픈스택 애플리케이션 아키텍처. 클라우드 플랫폼의 균형 및 장애 허용

ExaBGP를 사용하여 HAProxy 로드 밸런서를 장애 허용 가능하게 만들기

API를 확장성, 속도, 내결함성을 높이기 위해 API 앞에 로드 밸런서를 배치했습니다. 우리는 HAProxy를 선택했습니다. 제 생각에는 이 솔루션은 여러 OSI 레벨의 균형 조정, 관리 인터페이스, 유연성 및 확장성, 다양한 균형 조정 방법, 세션 테이블 지원 등 작업에 필요한 모든 특성을 갖추고 있습니다.

가장 먼저 해결해야 할 문제는 밸런서 자체의 내결함성이었습니다. 밸런서를 설치하는 것만으로도 장애 지점이 생성됩니다. 밸런서가 고장나면 서비스가 중단됩니다. 이런 일이 일어나지 않도록 하기 위해 ExaBGP와 함께 HAProxy를 사용했습니다.

ExaBGP를 사용하면 서비스 상태를 확인하는 메커니즘을 구현할 수 있습니다. 이 메커니즘을 사용하여 HAProxy가 작동하는지 확인하고 문제가 있는 경우 BGP에서 HAProxy 서비스를 비활성화했습니다.

ExaBGP+HAProxy 계획

1. 세 대의 서버에 필요한 소프트웨어인 ExaBGP와 HAProxy를 설치합니다.
2. 각 서버에 루프백 인터페이스를 만듭니다.
3. 세 서버 모두에서 이 인터페이스에 동일한 흰색 IP 주소를 등록합니다.
4. 흰색 IP 주소는 ExaBGP를 통해 인터넷에 공개됩니다.

세 개의 서버 모두에서 동일한 IP 주소를 광고함으로써 장애 허용성을 달성합니다. 네트워크 관점에서 볼 때, 동일한 주소는 세 개의 다른 다음 홉에서 접근할 수 있습니다. 라우터는 세 개의 동일한 경로를 보고 자체 메트릭(일반적으로 동일한 옵션)을 기준으로 가장 높은 우선순위의 경로를 선택하고 트래픽은 서버 중 하나로만 이동합니다.

HAProxy 작업이나 서버 장애에 문제가 발생하는 경우 ExaBGP는 경로 광고를 중단하고 트래픽이 원활하게 다른 서버로 전환됩니다.

이런 방식으로 밸런서의 내결함성을 달성했습니다.

HAProxy 로드 밸런서 장애 허용

이 계획은 불완전한 것으로 드러났습니다. 우리는 HAProxy를 예약하는 법을 배웠지만, 서비스 내에서 부하를 분산하는 법을 배우지 못했습니다. 그래서 우리는 이 계획을 조금 확장했습니다. 즉, 여러 개의 흰색 IP 주소 간의 균형을 맞추는 방향으로 전환했습니다.

DNS 기반 밸런싱 및 BGP

HAProxy 앞의 부하 분산 문제는 아직 해결되지 않았습니다. 하지만 우리의 경우처럼 아주 간단하게 해결할 수 있습니다.

3개의 서버를 균형 있게 관리하려면 XNUMX개의 흰색 IP 주소와 오래된 DNS가 필요합니다. 이러한 각 주소는 각 HAProxy의 루프백 인터페이스에서 정의되고 인터넷에 공개됩니다.

OpenStack은 서비스 카탈로그를 사용하여 리소스를 관리하며, 이를 통해 특정 서비스의 API 엔드포인트를 지정합니다. 이 디렉토리에 도메인 이름인 public.infra.mail.ru를 등록하는데, 이 이름은 세 개의 서로 다른 IP 주소로 DNS를 통해 확인됩니다. 결과적으로 DNS를 통해 세 개의 주소 사이에 부하가 분산됩니다.

하지만 화이트 IP 주소를 발표할 때 서버 선택 우선순위를 제어하지 않기 때문에 아직은 균형이 맞지 않습니다. 일반적으로 IP 주소의 선임성에 따라 하나의 서버만 선택되고, BGP에 메트릭이 지정되지 않았기 때문에 나머지 두 서버는 유휴 상태가 됩니다.

우리는 다양한 측정 항목을 사용하여 ExaBGP를 통해 경로를 제공하기 시작했습니다. 각 밸런서는 세 개의 흰색 IP 주소를 모두 발표하지만, 이 밸런서의 주요 주소 중 하나는 최소 메트릭으로 발표됩니다. 따라서 세 개의 밸런서가 모두 작동하는 동안 첫 번째 IP 주소에 대한 요청은 첫 번째 밸런서로 이동하고, 두 번째 IP 주소에 대한 요청은 두 번째 밸런서로 이동하고, 세 번째 IP 주소에 대한 요청은 세 번째 밸런서로 이동합니다.

밸런서 중 하나가 다운되면 어떻게 되나요? 밸런서 중 하나에 장애가 발생하면 해당 밸런서의 주 주소가 다른 두 개에 계속 광고되고, 트래픽은 두 밸런서 간에 재분배됩니다. 따라서 우리는 DNS를 통해 사용자에게 여러 개의 IP 주소를 동시에 제공합니다. DNS와 다양한 메트릭을 사용하여 부하를 분산함으로써 세 개의 밸런서 모두에 부하가 균등하게 분산됩니다. 동시에 우리는 내결함성을 잃지 않습니다.

DNS + BGP 기반 HAProxy 부하 분산

ExaBGP와 HAProxy 간의 상호 작용

따라서 우리는 경로 공지 종료를 기반으로 서버 장애 발생 시 장애 허용 기능을 구현했습니다. 하지만 HAProxy는 서버 장애 이외의 다른 이유로도 종료될 수 있습니다. 관리 오류, 서비스 내부 오류 등이 그 예입니다. 이런 경우에도 우리는 깨진 밸런서를 부하로부터 제거하고 싶으며, 다른 메커니즘이 필요합니다.

따라서 이전 방식을 확장하여 ExaBGP와 HAProxy 간의 하트비트를 구현했습니다. 이는 ExaBGP와 HAProxy 간의 상호작용을 소프트웨어로 구현한 것으로, ExaBGP는 사용자 정의 스크립트를 사용하여 애플리케이션의 상태를 확인합니다.

이렇게 하려면 ExaBGP 구성에서 HAProxy 상태를 확인할 수 있는 상태 검사기를 구성해야 합니다. 우리의 경우, HAProxy에서 상태 백엔드를 구성하고 ExaBGP 측에서 간단한 GET 요청으로 확인했습니다. 해당 공지가 더 이상 나오지 않는다면 HAProxy가 실행되지 않을 가능성이 높으므로 공지할 필요가 없습니다.

HAProxy 상태 점검

HAProxy 피어: 세션 동기화

다음으로 해야 할 일은 세션을 동기화하는 것이었습니다. 분산 밸런서를 사용하면 클라이언트 세션에 대한 정보 저장을 구성하는 것이 어렵습니다. 하지만 HAProxy는 Peers 기능 덕분에 이를 수행할 수 있는 몇 안 되는 밸런서 중 하나입니다. Peers 기능이란 서로 다른 HAProxy 프로세스 간에 세션 테이블을 전송하는 기능을 말합니다.

균형을 맞추는 데에는 여러 가지 방법이 있습니다. 간단한 방법도 있습니다. 라운드 로빈, 그리고 확장된 세션에서는 클라이언트의 세션이 기억되고, 매번 이전과 같은 서버에 접속하게 됩니다. 우리는 두 번째 옵션을 구현하고 싶었습니다.

HAProxy는 이 메커니즘의 클라이언트 세션을 저장하기 위해 스틱 테이블을 사용합니다. 이들은 클라이언트의 원래 IP 주소, 선택된 대상 주소(백엔드) 및 일부 서비스 정보를 저장합니다. 스틱 테이블은 일반적으로 소스 IP + 대상 IP 쌍을 저장하는 데 사용되며, 라운드 로빈 로드 밸런싱 모드와 같이 다른 로드 밸런서로 전환할 때 사용자 세션 컨텍스트를 전달할 수 없는 애플리케이션에 특히 유용합니다.

스틱 테이블이 서로 다른 HAProxy 프로세스(밸런싱이 발생하는 프로세스) 사이를 이동하도록 가르치면 밸런서가 단일 스틱 테이블 풀로 작업할 수 있습니다. 이를 통해 밸런서 중 하나에 장애가 발생해도 클라이언트 네트워크를 원활하게 전환할 수 있습니다. 클라이언트 세션 작업은 이전에 선택한 동일한 백엔드에서 계속 진행됩니다.

올바른 작동을 위해서는 세션이 설정된 밸런서의 소스 IP 주소를 확인해야 합니다. 우리의 경우, 이는 루프백 인터페이스의 동적 주소입니다.

피어의 올바른 작동은 특정 조건 하에서만 달성됩니다. 즉, TCP 세션이 끊어질 시간이 없도록 TCP 타임아웃이 충분히 커야 하거나 전환이 충분히 빨라야 합니다. 하지만 이렇게 하면 원활하게 전환할 수 있습니다.

우리는 동일한 기술을 사용하여 구축된 IaaS 서비스를 보유하고 있습니다. 이것 OpenStack을 위한 서비스로서의 로드 밸런서옥타비아라고 불립니다. 이는 두 개의 HAProxy 프로세스를 기반으로 하며 기본 피어 지원 기능을 갖추고 있습니다. 그들은 이 서비스에서 매우 뛰어나다는 것을 입증했습니다.

이 그림은 세 개의 HAProxy 인스턴스 간 피어 테이블의 이동을 개략적으로 보여주며, 이를 설정하는 방법에 대한 구성이 제공됩니다.

HAProxy 피어(세션 동기화)

동일한 방식을 구현하는 경우 작동 방식을 주의 깊게 테스트해야 합니다. 100%의 경우에 동일한 형태로 작동한다는 것은 사실이 아닙니다. 하지만 적어도 클라이언트의 소스 IP를 기억해야 할 때 스틱 테이블을 잃어버리지는 않을 것입니다.

동일한 클라이언트의 동시 요청 수 제한

API를 포함한 공개적으로 이용 가능한 모든 서비스는 엄청난 요청의 영향을 받을 수 있습니다. 그 이유는 사용자 오류부터 표적 공격까지 매우 다양할 수 있습니다. 우리는 주기적으로 IP 주소에 의한 DDoS 공격을 받고 있습니다. 클라이언트는 종종 스크립트에서 실수를 하여 우리에게 소규모 DDoS 공격을 가합니다.

어떤 식으로든 추가적인 보호가 필요합니다. 가장 확실한 해결책은 API에 대한 요청 수를 제한하고 악성 요청을 처리하는 데 프로세서 시간을 낭비하지 않는 것입니다.

이러한 제한을 구현하기 위해 우리는 동일한 스틱 테이블을 사용하여 HAProxy를 기반으로 구성된 비율 제한을 사용합니다. 제한은 매우 간단하게 설정되며 API에 대한 요청 수에 따라 사용자를 제한할 수 있습니다. 이 알고리즘은 요청이 이루어지는 소스 IP를 기억하고 한 사용자의 동시 요청 수를 제한합니다. 물론, 우리는 각 서비스에 대한 평균 API 부하 프로필을 계산하고 그 값의 약 10배로 한도를 설정했습니다. 우리는 상황을 계속 면밀히 모니터링하고 최신 동향을 파악합니다.

실제로는 어떻게 보일까요? 자동 확장을 위해 항상 당사의 API를 사용하는 고객이 있습니다. 그들은 아침에 가까워질수록 1000~XNUMX개의 가상 머신을 만들고 저녁에 가까워질수록 삭제합니다. OpenStack의 경우 PaaS 서비스를 포함한 가상 머신을 만들려면 최소 XNUMX개의 API 요청이 필요합니다. 서비스 간의 상호작용도 API를 통해 이루어지기 때문입니다.

이런 식으로 업무를 바꾸는 것은 상당한 스트레스를 유발합니다. 우리는 이 부하를 평가하고, 매일 최대 부하량을 수집하여 10배로 늘렸고, 이것이 우리의 요금 한도가 되었습니다. 우리는 항상 최신 동향을 파악합니다. 우리는 종종 봇과 스캐너가 실행 가능한 CGA 스크립트가 있는지 확인하려고 하는 것을 보고, 우리는 적극적으로 이를 잘라냅니다.

사용자가 눈치채지 못하게 코드베이스를 업데이트하는 방법

또한 코드 배포 프로세스 수준에서도 장애 허용 기능을 구현합니다. 롤아웃 중에는 오류가 발생할 수 있지만 서비스 가용성에 미치는 영향은 최소화할 수 있습니다.

저희는 서비스를 지속적으로 업데이트하고 있으며, 코드베이스 업데이트 과정이 사용자에게 영향을 미치지 않도록 해야 합니다. 우리는 HAProxy 관리 기능을 사용하고 서비스에 Graceful Shutdown을 구현하여 이 문제를 해결할 수 있었습니다.

이 문제를 해결하려면 밸런서 관리와 서비스의 "올바른" 종료를 보장해야 했습니다.

• HAProxy의 경우 제어는 통계 파일을 통해 수행되는데, 이 통계 파일은 본질적으로 소켓이며 HAProxy 구성에서 정의됩니다. stdio를 통해 명령을 전달할 수 있습니다. 하지만 우리의 주요 구성 제어 도구는 Ansible이므로 HAProxy를 관리하기 위한 내장 모듈이 있습니다. 우리는 이를 적극적으로 활용하고 있습니다.
• 대부분의 API와 엔진 서비스는 정상적인 종료 기술을 지원합니다. 즉, 종료 시에는 현재 작업(http 요청이든 일부 서비스 작업이든)이 완전히 완료될 때까지 기다립니다. 근로자에게도 똑같은 일이 일어납니다. 그는 자신이 해야 할 모든 일을 알고 있으며, 모든 것을 성공적으로 끝마치면 끝납니다.

이 두 가지 점 덕분에 우리의 안전한 배포 알고리즘은 다음과 같습니다.

1. 개발자는 새로운 코드 패키지(우리의 경우 RPM)를 빌드하고, 개발 환경에서 테스트하고, 스테이지 환경에서 테스트한 후 스테이지 저장소에 그대로 둡니다.
2. 개발자는 "아티팩트"에 대한 가장 자세한 설명과 함께 배포 작업을 설정합니다. 여기에는 새 패키지의 버전, 새 기능에 대한 설명, 필요한 경우 배포에 대한 기타 세부 정보가 포함됩니다.
3. 시스템 관리자가 업데이트를 시작합니다. Ansible 플레이북을 실행하면 다음 작업이 수행됩니다.
   • 스테이지 저장소에서 패키지를 가져와서 이를 기반으로 제품 저장소의 패키지 버전을 업데이트합니다.
   • 업데이트되는 서비스의 백엔드 목록을 컴파일합니다.
   • HAProxy에서 업데이트할 첫 번째 서비스를 종료하고 해당 프로세스가 실행을 마칠 때까지 기다립니다. 원활한 서비스 종료 덕분에 현재 고객 요청이 모두 성공적으로 완료될 것으로 확신합니다.
   • API와 작업자가 완전히 중지되고 HAProxy가 종료된 후 코드가 업데이트됩니다.
   • Ansible이 서비스를 시작합니다.
   • 각 서비스에 대해 여러 가지 사전 정의된 주요 테스트에 대한 단위 테스트를 수행하는 특정 "핸들"을 가져옵니다. 새로운 코드에 대한 기본적인 검사가 수행됩니다.
   • 이전 단계에서 오류가 발견되지 않으면 백엔드가 활성화됩니다.
   • 다음 백엔드로 넘어가겠습니다.
4. 모든 백엔드가 업데이트된 후 기능 테스트가 실행됩니다. 해당 기능이 누락된 경우 개발자는 자신이 만든 새로운 기능을 살펴봅니다.

이것으로 배포가 완료되었습니다.

서비스 업데이트 주기

이 계획은 단 하나의 규칙도 없다면 효과가 없을 것입니다. 우리는 전투에서 이전 버전과 새 버전을 모두 지원합니다. 소프트웨어 개발 단계에서는 서비스 데이터베이스에 변경 사항이 있어도 기존 코드는 손상되지 않을 것이라고 미리 가정합니다. 결과적으로 코드베이스는 점진적으로 업데이트됩니다.

결론

내결함성 WEB 아키텍처에 대한 나만의 생각을 공유하면서, 다시 한번 핵심 사항을 강조하고 싶습니다.

• 물리적 결함 허용성
• 네트워크 장애 허용(밸런서, BGP)
• 사용 및 개발된 소프트웨어의 내결함성.

모두들 안정적인 가동시간을 보내세요!

출처 : habr.com