🥇AWS가 탄력적인 서비스를 "요리"하는 방법. 서버 및 데이터베이스 확장

클라우드는 마술 상자와 같습니다. 필요한 것이 무엇인지 물어보면 리소스가 갑자기 나타납니다. 가상 머신, 데이터베이스, 네트워크 - 이 모든 것은 귀하에게만 속합니다. 다른 클라우드 임차인이 있지만 우주에서는 당신이 유일한 통치자입니다. 당신은 항상 필요한 리소스를 받을 것이라고 확신하고, 누구도 고려하지 않으며, 네트워크가 어떤 것인지 독립적으로 결정합니다. 클라우드가 리소스를 탄력적으로 할당하고 테넌트를 서로 완전히 격리하게 만드는 이 마법은 어떻게 작동합니까?

AWS 클라우드는 2006년부터 진화적으로 진화해온 초대형 복합 시스템입니다. 이 개발의 일부가 발생했습니다. 바실리 판튜킨 - 아마존 웹 서비스 아키텍트. 아키텍트로서 그는 최종 결과뿐만 아니라 AWS가 극복한 과제에 대해서도 자세히 살펴봅니다. 시스템 작동 방식에 대한 이해가 높을수록 신뢰도가 높아집니다. 따라서 Vasily는 AWS 클라우드 서비스의 비밀을 공유할 것입니다. 다음은 물리적 AWS 서버의 설계, 탄력적인 데이터베이스 확장성, 맞춤형 Amazon 데이터베이스 및 가상 머신의 성능을 높이는 동시에 가격을 낮추는 방법입니다. Amazon의 아키텍처 접근 방식에 대한 지식은 AWS 서비스를 보다 효과적으로 사용하는 데 도움이 되며 자체 솔루션 구축을 위한 새로운 아이디어를 제공할 수도 있습니다.

발표자 정보: Vasily Pantyukhin(암탉)는 .ru 회사에서 Unix 관리자로 시작하여 6년 동안 대규모 Sun Microsystem 하드웨어에서 일했으며 11년 동안 EMC에서 데이터 중심 세계를 설교했습니다. 자연스럽게 프라이빗 클라우드로 진화했고, 2017년에는 퍼블릭 클라우드로 전환됐다. 이제 그는 AWS 클라우드에서 생활하고 개발하는 데 도움이 되는 기술적 조언을 제공합니다.

면책 조항: 아래의 모든 내용은 Vasily의 개인적인 의견이며 Amazon Web Services의 입장과 일치하지 않을 수 있습니다. 비디오 테이프 기사의 기반이 된 보고서는 YouTube 채널에서 확인할 수 있습니다.

Amazon 장치에 대해 이야기하는 이유는 무엇입니까?

내 첫 번째 차는 수동 변속기를 사용했습니다. 내가 차를 운전하고 완벽하게 통제할 수 있다는 느낌이 들어서 좋았어요. 또한 작동 원리를 최소한 대략적으로 이해했다는 점이 마음에 들었습니다. 당연히 나는 상자의 구조가 매우 원시적이라고 상상했습니다. 자전거의 기어 박스와 같습니다.

교통 체증으로 갇힌 한 가지를 제외하고는 모든 것이 훌륭했습니다. 앉아서 아무것도 하지 않는 것처럼 보이지만 끊임없이 기어를 바꾸고 클러치, 가속 페달, 브레이크를 밟고 있습니다. 정말 피곤해집니다. 교통 체증 문제는 가족이 자동 차를 구입했을 때 부분적으로 해결되었습니다. 운전을 하면서 오디오북을 들으며 생각을 하는 시간을 가졌습니다.

내 차가 어떻게 작동하는지 완전히 이해하지 못했기 때문에 내 인생에 또 다른 미스터리가 나타났습니다. 현대 자동차는 복잡한 장치입니다. 자동차는 가속 페달, 브레이크, 운전 스타일, 도로 품질 등 수십 가지 다양한 매개변수에 동시에 적응합니다. 나는 그것이 어떻게 작동하는지 더 이상 이해하지 못합니다.

Amazon 클라우드 작업을 시작했을 때에도 그것은 나에게 미스터리였습니다. 자동차에는 한 명의 운전자가 있고 AWS에는 수백만 명의 운전자가 있기 때문에 이 미스터리만이 훨씬 더 큽니다. 모든 사용자가 동시에 조향하고 가속 페달을 밟고 브레이크를 밟습니다. 그들이 원하는 곳으로 가는 것은 놀라운 일입니다. 그것은 나에게 기적입니다! 시스템은 각 사용자에게 자동으로 적응하고 확장하며 탄력적으로 조정되므로 사용자는 이 우주에 혼자인 것처럼 보입니다.

나중에 Amazon에서 건축가로 일하게 되었을 때 그 마법은 조금 사라졌습니다. 우리가 직면한 문제가 무엇인지, 어떻게 해결하는지, 서비스를 어떻게 개발하는지 살펴보았습니다. 시스템 작동 방식에 대한 이해가 높아질수록 서비스에 대한 신뢰도가 높아집니다. 그래서 저는 AWS 클라우드의 내부 내용을 사진으로 공유하고 싶습니다.

무슨 얘기를 할까?

저는 다양한 접근 방식을 선택했습니다. 이야기할 가치가 있는 흥미로운 서비스 4개를 선택했습니다.

서버 최적화. 물리적 구현을 갖춘 임시 클라우드: 윙윙거리고 뜨거워지며 조명으로 깜박이는 물리적 서버가 있는 물리적 데이터 센터입니다.

서버리스 기능 (Lambda)는 아마도 클라우드에서 가장 확장성이 뛰어난 서비스일 것입니다.

데이터베이스 확장. 우리가 자체적으로 확장 가능한 데이터베이스를 구축하는 방법에 대해 말씀드리겠습니다.

네트워크 확장. 우리 네트워크의 장치를 여는 마지막 부분입니다. 이것은 놀라운 일입니다. 모든 클라우드 사용자는 자신이 클라우드에 혼자 있고 다른 테넌트를 전혀 볼 수 없다고 믿습니다.

메모. 이 문서에서는 서버 최적화 및 데이터베이스 확장에 대해 설명합니다. 다음 기사에서는 네트워크 확장을 고려하겠습니다. 서버리스 기능은 어디에 있나요? 그들에 대한 별도의 성적표가 출판되었습니다.작지만 똑똑합니다. 폭죽 마이크로가상 언박싱" 여러 가지 확장 방법에 대해 설명하고 가상 머신과 컨테이너의 최고 품질이 공생하는 Firecracker 솔루션에 대해 자세히 설명합니다.

서버

클라우드는 일시적입니다. 그러나 이러한 일시적인 현상은 여전히 서버라는 물리적인 구체화를 갖고 있습니다. 처음에 그들의 아키텍처는 고전적이었습니다. 가상 머신이 실행되는 표준 x86 칩셋, 네트워크 카드, Linux, Xen 하이퍼바이저.

2012년에 이 아키텍처는 해당 작업을 매우 잘 수행했습니다. Xen은 훌륭한 하이퍼바이저이지만 한 가지 큰 단점이 있습니다. 그 사람은 충분해요 장치 에뮬레이션에 대한 높은 오버헤드. 새롭고 더 빠른 네트워크 카드나 SSD 드라이브를 사용할 수 있게 되면 이 오버헤드가 너무 높아집니다. 이 문제를 어떻게 처리합니까? 우리는 한 번에 두 가지 측면에서 작업하기로 결정했습니다. 하드웨어와 하이퍼바이저 모두 최적화. 작업은 매우 심각합니다.

하드웨어 및 하이퍼바이저 최적화

한꺼번에 모든 일을 잘하면 효과가 없습니다. 무엇이 "좋은" 것인지도 처음에는 불분명했습니다.

우리는 혁신적인 접근 방식을 취하기로 결정했습니다. 즉, 아키텍처의 중요한 요소 중 하나를 변경하여 이를 프로덕션에 적용하기로 결정했습니다.

우리는 모든 갈퀴를 밟고 불만과 제안을 듣습니다. 그런 다음 다른 구성 요소를 변경합니다. 따라서 우리는 사용자 및 지원의 피드백을 기반으로 전체 아키텍처를 조금씩 점진적으로 변경합니다.

변화는 2013년 가장 복잡한 것, 즉 네트워크에서 시작되었습니다. 안에 С3 예를 들어 특수 네트워크 가속기 카드가 표준 네트워크 카드에 추가되었습니다. 문자 그대로 전면 패널의 짧은 루프백 케이블로 연결되었습니다. 예쁘진 않은데 구름에 안보이네요. 그러나 하드웨어와의 직접적인 상호 작용은 지터와 네트워크 처리량을 근본적으로 향상시켰습니다.

다음으로 우리는 블록 데이터 스토리지 EBS(Elastic Block Storage)에 대한 액세스를 개선하기로 결정했습니다. 네트워크와 스토리지의 결합이다. 문제는 Network Accelerator 카드가 시장에 존재하는 동안 단순히 Storage Accelerator 하드웨어를 구매할 수 있는 옵션이 없었다는 것입니다. 그래서 우리는 스타트업으로 전향했습니다 안나푸르나 연구소, 우리를 위해 특수 ASIC 칩을 개발했습니다. 원격 EBS 볼륨을 NVMe 장치로 마운트할 수 있었습니다.

경우에 따라 C4 우리는 두 가지 문제를 해결했습니다. 첫 번째는 유망하지만 당시에는 새로운 NVMe 기술의 미래를 위한 기반을 구현했다는 것입니다. 둘째, EBS에 대한 요청 처리를 새 카드로 전송하여 중앙 프로세서의 부하를 크게 줄였습니다. 결과가 좋아 이제 Annapurna Labs는 Amazon의 일부가 되었습니다.

2017년 XNUMX월에 우리는 하이퍼바이저 자체를 변경할 때가 되었다는 것을 깨달았습니다.

새로운 하이퍼바이저는 수정된 KVM 커널 모듈을 기반으로 개발되었습니다.

이를 통해 장치 에뮬레이션의 오버헤드를 근본적으로 줄이고 새로운 ASIC과 직접 작업할 수 있게 되었습니다. 인스턴스 С5 새로운 하이퍼바이저가 내부적으로 실행되는 최초의 가상 머신이었습니다. 우리는 그 사람의 이름을 지었습니다. 니트로.

타임라인에서 인스턴스의 진화.

2017년 XNUMX월 이후 등장한 모든 새로운 유형의 가상 머신은 이 하이퍼바이저에서 실행됩니다. 베어메탈 인스턴스에는 하이퍼바이저가 없습니다., 그러나 특수한 Nitro 카드를 사용하기 때문에 Nitro라고도 합니다.

향후 1년 동안 Nitro 인스턴스 유형의 수는 A5, C5, M3, TXNUMX 등 수십 가지를 초과했습니다.

인스턴스 유형.

확장 가능한 데이터베이스

전통적인 데이터베이스는 계층화된 구조를 가지고 있습니다. 크게 단순화하기 위해 다음 수준을 구분합니다.

SQL — 클라이언트 및 요청 디스패처가 작업합니다.
식량 업무 - 여기에서는 ACID 등 모든 것이 명확합니다.
캐싱, 이는 버퍼 풀에서 제공됩니다.
벌채 반출 — 리두 로그 작업을 제공합니다. MySQL에서는 Bin 로그, PosgreSQL에서는 WAL(Write Ahead Logs)이라고 합니다.
저장 – 디스크에 직접 기록합니다.

계층화된 데이터베이스 구조.

데이터베이스를 확장하는 방법에는 샤딩, Shared Nothing 아키텍처, 공유 디스크 등 다양한 방법이 있습니다.

그러나 이러한 모든 방법은 동일한 단일 데이터베이스 구조를 유지합니다. 이로 인해 확장이 크게 제한됩니다. 이 문제를 해결하기 위해 우리는 자체 데이터베이스를 개발했습니다. Amazon Aurora. MySQL 및 PostgreSQL과 호환됩니다.

Amazon Aurora

주요 아키텍처 아이디어는 기본 데이터베이스에서 스토리지 및 로깅 수준을 분리하는 것입니다.

앞으로는 캐싱 수준도 독립적으로 만들었다고 말씀드리겠습니다. 아키텍처는 더 이상 단일체가 아니며 개별 블록을 확장할 때 추가적인 자유도를 얻습니다.

로깅 및 스토리지 수준은 데이터베이스와 별개입니다.

기존 DBMS는 데이터를 블록 형태로 스토리지 시스템에 기록합니다. Amazon Aurora에서는 언어를 구사할 수 있는 스마트 스토리지를 만들었습니다. 재실행 로그. 내부의 스토리지는 로그를 데이터 블록으로 변환하고 무결성을 모니터링하며 자동으로 백업합니다.

이 접근 방식을 사용하면 다음과 같은 흥미로운 것을 구현할 수 있습니다. 복제. 모든 데이터의 완전한 복사본을 생성할 필요가 없기 때문에 근본적으로 더 빠르고 경제적으로 작동합니다.

스토리지 계층은 분산 시스템으로 구현됩니다. 이는 매우 많은 수의 물리적 서버로 구성됩니다. 각 Redo 로그는 동시에 처리되고 저장됩니다. 여섯 개의 매듭. 이를 통해 데이터 보호 및 로드 밸런싱이 보장됩니다.

읽기 확장은 적절한 복제본을 사용하여 달성할 수 있습니다. 분산 스토리지를 사용하면 데이터를 쓰는 기본 데이터베이스 인스턴스와 나머지 복제본 간의 동기화가 필요하지 않습니다. 모든 복제본에서 최신 데이터를 사용할 수 있도록 보장됩니다.

유일한 문제는 읽기 전용 복제본에 오래된 데이터를 캐싱하는 것입니다. 하지만 이 문제는 해결되고 있어 모든 REDO 로그 전송 내부 네트워크를 통해 복제본을 생성합니다. 로그가 캐시에 있으면 잘못된 것으로 표시되어 덮어쓰게 됩니다. 캐시에 없으면 간단히 삭제됩니다.

우리는 저장 공간을 정리했습니다.

DBMS 계층을 확장하는 방법

여기서 수평 확장은 훨씬 더 어렵습니다. 그러니 우리가 구불구불한 길로 가보자 전형적인 수직 확장.

마스터 노드를 통해 DBMS와 통신하는 애플리케이션이 있다고 가정해 보겠습니다.

수직으로 확장할 때 더 많은 프로세서와 메모리를 갖춘 새 노드를 할당합니다.

다음으로 애플리케이션을 이전 마스터 노드에서 새 노드로 전환합니다. 문제가 발생합니다.

이를 위해서는 상당한 애플리케이션 가동 중지 시간이 필요합니다.
새 마스터 노드에는 콜드 캐시가 포함됩니다. 캐시가 워밍업된 후에만 데이터베이스 성능이 최대가 됩니다.

상황을 개선하는 방법은 무엇입니까? 애플리케이션과 마스터 노드 사이에 프록시를 설정합니다.

이것이 우리에게 무엇을 줄까요? 이제 모든 애플리케이션을 새 노드로 수동으로 리디렉션할 필요가 없습니다. 전환은 프록시 하에서 수행될 수 있으며 기본적으로 더 빠릅니다.

문제가 해결된 것 같습니다. 하지만 아닙니다. 여전히 캐시를 워밍업해야 하는 문제가 있습니다. 또한 새로운 문제가 나타났습니다. 이제 프록시가 잠재적인 실패 지점이 되었습니다.

Amazon Aurora 서버리스를 사용한 최종 솔루션

우리는 이러한 문제를 어떻게 해결했습니까?

대리인을 떠났습니다. 이는 별도의 인스턴스가 아니라 애플리케이션이 데이터베이스에 연결하는 전체 분산 프록시 집합입니다. 장애가 발생하는 경우 모든 노드를 거의 즉시 교체할 수 있습니다.

다양한 크기의 웜 노드 풀을 추가했습니다.. 따라서 더 크거나 작은 크기의 새 노드를 할당해야 하는 경우 즉시 사용할 수 있습니다. 로드될 때까지 기다릴 필요가 없습니다.

전체 스케일링 프로세스는 특수 모니터링 시스템에 의해 제어됩니다. 모니터링은 현재 마스터 노드의 상태를 지속적으로 모니터링합니다. 예를 들어 프로세서 로드가 임계값에 도달한 것을 감지하면 웜 인스턴스 풀에 새 노드를 할당해야 함을 알립니다.

분산 프록시, 웜 인스턴스 및 모니터링.

필요한 전력을 갖춘 노드를 사용할 수 있습니다. 버퍼 풀이 여기에 복사되고 시스템은 전환할 수 있는 안전한 순간을 기다리기 시작합니다.

일반적으로 전환하는 순간은 매우 빠르게 옵니다. 그런 다음 프록시와 이전 마스터 노드 간의 통신이 일시 중단되고 모든 세션이 새 노드로 전환됩니다.

데이터베이스 이력서 작업.

그래프를 보면 서스펜션이 실제로 매우 짧다는 것을 알 수 있습니다. 파란색 그래프는 부하를 표시하고, 빨간색 단계는 조정 순간을 표시합니다. 파란색 그래프의 단기 하락은 바로 그 짧은 지연입니다.

그런데 Amazon Aurora를 사용하면 주말과 같이 데이터베이스를 사용하지 않을 때 비용을 완전히 절약하고 데이터베이스를 끌 수 있습니다. 부하를 중지한 후 DB는 점차적으로 전력을 감소시키며 일정 시간 동안 꺼집니다. 부하가 돌아오면 다시 부드럽게 상승합니다.

Amazon 장치 이야기의 다음 부분에서는 네트워크 확장에 대해 이야기하겠습니다. 구독하다 우편 기사를 놓치지 않도록 계속 지켜봐 주시기 바랍니다.

에 HighLoad ++ Vasily Pantyukhin이 보고서를 작성합니다.휴스턴, 우리에게 문제가 생겼다. 장애에 대비한 시스템 설계, Amazon 내부 클라우드 서비스 개발 패턴" Amazon 개발자가 사용하는 분산 시스템의 설계 패턴은 무엇인지, 서비스 실패 이유는 무엇인지, 셀 기반 아키텍처는 무엇인지, 지속적인 작업, Shuffle Sharding 등이 흥미로울 것입니다. 컨퍼런스까지 한 달도 채 남지 않았습니다. 티켓을 예약하세요. 24월 XNUMX일 최종 가격 인상.

출처 : habr.com

AWS가 탄력적 서비스를 제공하는 방법. 서버 및 데이터베이스 확장