AWS가 탄력적 서비스를 제공하는 방법. 네트워크 확장

Amazon Web Services 네트워크 규모는 미국, 유럽, 아시아, 아프리카, 호주 등 전 세계 69개 지역 22개 영역입니다. 각 영역에는 최대 8개의 데이터 센터, 즉 데이터 처리 센터가 포함됩니다. 각 데이터 센터에는 수천 또는 수십만 대의 서버가 있습니다. 네트워크는 가능성이 낮은 모든 중단 시나리오를 고려하는 방식으로 설계되었습니다. 예를 들어, 모든 지역은 서로 격리되어 있으며 접근성 구역은 수 킬로미터 거리에 걸쳐 분리되어 있습니다. 케이블을 자르더라도 시스템은 백업 채널로 전환되며 정보 손실은 몇 개의 데이터 패킷에 달합니다. Vasily Pantyukhin은 네트워크가 구축된 다른 원칙과 구조에 대해 이야기합니다.

바실리 판튜킨 .ru 회사에서 Unix 관리자로 시작하여 6년 동안 대규모 Sun Microsystem 하드웨어에서 일했으며 11년 동안 EMC에서 데이터 중심 세계를 설교했습니다. 자연스럽게 프라이빗 클라우드로 발전한 후 퍼블릭 클라우드로 이동했습니다. 이제 그는 Amazon Web Services 아키텍트로서 AWS 클라우드에서 생활하고 개발하는 데 도움이 되는 기술 조언을 제공합니다.

AWS XNUMX부작의 이전 부분에서 Vasily는 물리적 서버 설계 및 데이터베이스 확장에 대해 자세히 설명했습니다. Nitro 카드, 맞춤형 KVM 기반 하이퍼바이저, Amazon Aurora 데이터베이스 - 자료에 있는 모든 정보 "AWS가 탄력적 서비스를 제공하는 방법. 서버 및 데이터베이스 확장" 맥락을 읽거나 시청하세요 비디오 녹화 연설.

이 부분에서는 AWS에서 가장 복잡한 시스템 중 하나인 네트워크 확장에 중점을 둡니다. 플랫 네트워크에서 Virtual Private Cloud로의 진화 및 설계, Blackfoot 및 HyperPlane의 내부 서비스, 시끄러운 이웃 문제, 그리고 결국 네트워크, 백본 및 물리적 케이블의 규모. 이 모든 것에 대해 컷 아래에 있습니다.

면책 조항: 아래의 모든 내용은 Vasily의 개인적인 의견이며 Amazon Web Services의 입장과 일치하지 않을 수 있습니다.

네트워크 확장

AWS 클라우드는 2006년에 출시되었습니다. 그의 네트워크는 매우 원시적이었습니다 - 평평한 구조를 가지고 있었습니다. 개인 주소 범위는 모든 클라우드 테넌트에 공통되었습니다. 새 가상 머신을 시작할 때 실수로 이 범위에서 사용 가능한 IP 주소를 받았습니다.

이 접근 방식은 구현하기 쉬웠지만 근본적으로 클라우드 사용이 제한되었습니다. 특히, 지상의 프라이빗 네트워크와 AWS에서 프라이빗 네트워크를 결합한 하이브리드 솔루션을 개발하는 것은 상당히 어려웠습니다. 가장 일반적인 문제는 IP 주소 범위가 겹치는 것이었습니다.

가상 프라이빗 클라우드

클라우드에 대한 수요가 있는 것으로 나타났습니다. 확장성과 수천만 명의 테넌트 사용 가능성에 대해 생각해 볼 때가 왔습니다. 플랫 네트워크가 큰 장애물이 되었습니다. 따라서 우리는 사용자가 독립적으로 IP 범위를 선택할 수 있도록 네트워크 수준에서 사용자를 서로 격리하는 방법을 생각했습니다.

네트워크 격리에 대해 생각할 때 가장 먼저 떠오르는 것은 무엇입니까? 틀림없이 VLAN и VRF - 가상 라우팅 및 전달.

불행히도 작동하지 않았습니다. VLAN ID는 12비트에 불과하므로 격리된 세그먼트는 4096개만 제공됩니다. 가장 큰 스위치라도 최대 1~2개의 VRF를 사용할 수 있습니다. VRF와 VLAN을 함께 사용하면 서브넷이 수백만 개만 제공됩니다. 이는 각각 여러 서브넷을 사용할 수 있어야 하는 수천만 명의 테넌트에는 확실히 충분하지 않습니다.

또한 예를 들어 Cisco나 Juniper 등에서 필요한 수의 대형 상자를 구입할 여유가 없습니다. 두 가지 이유가 있습니다. 엄청나게 비용이 많이 들고, 우리는 그들의 개발 및 패치 정책에 휘둘리고 싶지 않습니다.

결론은 하나뿐입니다. 자신 만의 솔루션을 만드십시오.

2009년에 우리는 발표했습니다. VPC - 가상 프라이빗 클라우드. 이름은 그대로 유지되었으며 현재 많은 클라우드 제공업체에서도 이 이름을 사용하고 있습니다.

VPC는 가상 네트워크입니다. SDN (소프트웨어 정의 네트워크). 우리는 L2 및 L3 수준에서 특별한 프로토콜을 개발하지 않기로 결정했습니다. 네트워크는 표준 이더넷 및 IP에서 실행됩니다. 네트워크를 통한 전송의 경우 가상 머신 트래픽은 자체 프로토콜 래퍼에 캡슐화됩니다. 테넌트의 VPC에 속한 ID를 나타냅니다.

간단하게 들리네요. 그러나 극복해야 할 몇 가지 심각한 기술적 과제가 있습니다. 예를 들어 가상 MAC/IP 주소, VPC ID 및 해당 물리적 ​​MAC/IP 매핑에 대한 데이터를 저장하는 위치와 방법입니다. AWS 규모에서 이는 액세스 지연을 최소화하면서 작동해야 하는 거대한 테이블입니다. 이에 대한 책임 매핑 서비스, 이는 네트워크 전체에 얇은 층으로 퍼져 있습니다.

차세대 시스템에서는 하드웨어 수준에서 Nitro 카드를 통해 캡슐화가 수행됩니다. 이전 인스턴스에서는 캡슐화 및 캡슐화 해제가 소프트웨어 기반이었습니다. 

일반적인 용어로 어떻게 작동하는지 알아 봅시다. L2 레벨부터 시작해 보겠습니다. 물리적 서버 10.0.0.2에 IP 192.168.0.3를 사용하는 가상 머신이 있다고 가정해 보겠습니다. 10.0.0.3에 있는 가상 머신 192.168.1.4으로 데이터를 보냅니다. ARP 요청이 생성되어 네트워크 Nitro 카드로 전송됩니다. 단순화를 위해 두 가상 머신이 동일한 "블루" VPC에 있다고 가정합니다.

맵은 소스 주소를 자체 주소로 바꾸고 ARP 프레임을 매핑 서비스로 전달합니다.

매핑 서비스는 L2 물리적 네트워크를 통한 전송에 필요한 정보를 반환합니다.

ARP 응답의 Nitro 카드는 물리적 네트워크의 MAC를 VPC의 주소로 대체합니다.

데이터를 전송할 때 논리적 MAC 및 IP를 VPC 래퍼로 래핑합니다. 우리는 적절한 소스 및 대상 IP Nitro 카드를 사용하여 물리적 네트워크를 통해 이 모든 것을 전송합니다.

패키지가 전송될 물리적 시스템이 검사를 수행합니다. 이는 주소 스푸핑 가능성을 방지하는 데 필요합니다. 머신은 매핑 서비스에 특별 요청을 보내고 다음과 같이 묻습니다. “물리적 머신 192.168.0.3에서 파란색 VPC의 10.0.0.3을 대상으로 하는 패킷을 받았습니다. 그는 합법적인가요? 

매핑 서비스는 리소스 할당 테이블을 확인하여 패킷 통과를 허용하거나 거부합니다. 모든 새로운 인스턴스에는 Nitro 카드에 추가 검증이 내장되어 있습니다. 이론적으로도 이를 우회하는 것은 불가능하다. 따라서 다른 VPC의 리소스에 대한 스푸핑은 작동하지 않습니다.

다음으로 데이터는 해당 데이터가 의도된 가상 머신으로 전송됩니다. 

매핑 서비스는 서로 다른 서브넷의 가상 머신 간에 데이터를 전송하기 위한 논리적 라우터로도 작동합니다. 모든 것이 개념적으로 간단하므로 자세히 설명하지 않겠습니다.

각 패킷을 전송할 때 서버는 매핑 서비스를 사용하는 것으로 나타났습니다. 불가피한 지연을 처리하는 방법은 무엇입니까? 캐싱, 물론이야.

장점은 거대한 테이블 전체를 캐시할 필요가 없다는 것입니다. 물리적 서버는 상대적으로 적은 수의 VPC에서 가상 머신을 호스팅합니다. 이러한 VPC에 대한 정보만 캐시하면 됩니다. "기본" 구성에서 다른 VPC로 데이터를 전송하는 것은 여전히 ​​적법하지 않습니다. VPC-피어링 등의 기능을 사용하면 해당 VPC에 대한 정보가 추가로 캐시에 로드됩니다. 

VPC로의 데이터 전송을 정리했습니다.

블랙 풋

인터넷이나 VPN을 통해 지상으로 트래픽을 외부로 전송해야 하는 경우 어떻게 해야 합니까? 여기서 우리를 도와줍니다 블랙 풋 — AWS 내부 서비스. 남아프리카 팀이 개발했습니다. 그래서 서비스 이름은 남아프리카에 사는 펭귄의 이름을 따서 지어졌습니다.

Blackfoot은 트래픽을 캡슐화 해제하고 필요한 작업을 수행합니다. 데이터는 있는 그대로 인터넷으로 전송됩니다.

VPN을 사용할 때 데이터는 IPsec에서 캡슐화 해제되고 다시 래핑됩니다.

Direct Connect를 사용하면 트래픽에 태그가 지정되고 적절한 VLAN으로 전송됩니다.

하이퍼플레인

내부 흐름 제어 서비스입니다. 많은 네트워크 서비스에는 모니터링이 필요합니다. 데이터 흐름 상태. 예를 들어 NAT를 사용할 때 흐름 제어는 각 IP:대상 포트 쌍에 고유한 나가는 포트가 있는지 확인해야 합니다. 밸런서의 경우 NLB - 네트워크 로드 밸런서, 데이터 흐름은 항상 동일한 대상 가상 머신으로 전달되어야 합니다. 보안 그룹은 상태 저장 방화벽입니다. 들어오는 트래픽을 모니터링하고 나가는 패킷 흐름을 위해 암시적으로 포트를 엽니다.

AWS 클라우드에서는 전송 지연 시간 요구 사항이 매우 높습니다. 그렇기 때문에 하이퍼플레인 전체 네트워크의 성능에 매우 중요합니다.

Hyperplane은 EC2 가상 머신을 기반으로 구축되었습니다. 여기에는 마법이 없고 교활함만 있습니다. 비결은 이것이 대용량 RAM을 갖춘 가상 머신이라는 것입니다. 작업은 트랜잭션 방식으로 이루어지며 메모리에서만 수행됩니다. 이를 통해 수십 마이크로초의 지연을 달성할 수 있습니다. 디스크로 작업하면 생산성이 모두 저하됩니다. 

하이퍼플레인(Hyperplane)은 수많은 EC2 머신으로 구성된 분산 시스템입니다. 각 가상 머신의 대역폭은 5GB/s입니다. 전체 지역 네트워크에 걸쳐 이는 놀라운 테라비트의 대역폭을 제공하고 처리를 허용합니다. 초당 수백만 개의 연결.

HyperPlane은 스트림에서만 작동합니다. VPC 패킷 캡슐화는 완전히 투명합니다. 이 내부 서비스의 잠재적인 취약점으로 인해 여전히 VPC 격리가 깨지는 것을 방지할 수 있습니다. 아래 수준은 보안을 담당합니다.

시끄러운 이웃

여전히 문제가 있습니다 시끄러운 이웃 - 시끄러운 이웃. 노드가 8개 있다고 가정해 보겠습니다. 이러한 노드는 모든 클라우드 사용자의 흐름을 처리합니다. 모든 것이 괜찮은 것 같고 부하가 모든 노드에 고르게 분산되어야 합니다. 노드는 매우 강력하며 과부하가 어렵습니다.

그러나 우리는 가능성이 희박한 시나리오를 기반으로 아키텍처를 구축합니다. 

확률이 낮다고 해서 불가능하다는 뜻은 아닙니다.

한 명 이상의 사용자가 너무 많은 로드를 생성하는 상황을 상상할 수 있습니다. 모든 HyperPlane 노드는 이 로드 처리에 관여하며 다른 사용자는 잠재적으로 일종의 성능 저하를 경험할 수 있습니다. 이는 테넌트가 서로 영향을 미칠 수 없는 클라우드의 개념을 무너뜨립니다.

시끄러운 이웃의 문제를 해결하는 방법은 무엇입니까? 가장 먼저 떠오르는 것은 샤딩(sharding)이다. 8개의 노드는 논리적으로 각각 4개의 노드로 구성된 2개의 샤드로 나뉩니다. 이제 시끄러운 이웃은 전체 사용자의 XNUMX분의 XNUMX만 방해하지만 크게 방해할 것입니다.

일을 다르게 해보자. 각 사용자에게 3개의 노드만 할당하겠습니다. 

비결은 노드를 다른 사용자에게 무작위로 할당하는 것입니다. 아래 그림에서 파란색 사용자는 다른 두 사용자(녹색 및 주황색) 중 한 명과 노드를 교차합니다.

8개의 노드와 3명의 사용자가 있는 경우 잡음이 많은 이웃이 사용자 중 한 명과 교차할 확률은 54%입니다. 파란색 사용자가 다른 테넌트에 영향을 미칠 가능성이 높습니다. 동시에 부하의 일부만 발생합니다. 이 예에서 이 영향은 적어도 모든 사람이 아니라 전체 사용자의 XNUMX/XNUMX에게만 눈에 띄게 나타납니다. 이미 좋은 결과입니다.

교차할 사용자 수

확률(%)

0

18%

1

54%

2

26%

3

2%

상황을 현실에 더 가깝게 만들어 보겠습니다. 100개의 노드와 5개의 노드에 5명의 사용자가 있다고 가정하겠습니다. 이 경우 어떤 노드도 77%의 확률로 교차하지 않습니다. 

교차할 사용자 수

확률(%)

0

77%

1

21%

2

1,8%

3

0,06%

4

0,0006%

5

0,00000013%

수많은 HyperPlane 노드와 사용자가 있는 실제 상황에서는 잡음이 많은 이웃이 다른 사용자에게 미치는 잠재적 영향이 최소화됩니다. 이 방법은 혼합 샤딩 - 셔플 샤딩. 노드 장애로 인한 부정적인 영향을 최소화합니다.

Network Load Balancer, NAT Gateway, Amazon EFS, AWS PrivateLink, AWS Transit Gateway 등 많은 서비스가 HyperPlane을 기반으로 구축되었습니다.

네트워크 규모

이제 네트워크 자체의 규모에 대해 이야기해 보겠습니다. 2019년 XNUMX월 AWS는 다음과 같은 서비스를 제공합니다. 22개 지역, 외 9개가 더 계획되어 있습니다.

• 각 지역에는 여러 가용 영역이 포함되어 있습니다. 전 세계적으로 69개가 있습니다.
• 각 AZ는 데이터 처리 센터로 구성됩니다. 총 8 개가 넘지 않습니다.
• 데이터 센터에는 엄청난 수의 서버가 있으며 일부 서버는 최대 300대에 달합니다.

이제 이 모든 것을 평균화하고 곱하여 이를 반영하는 인상적인 수치를 얻습니다. 아마존 클라우드 규모.

가용 영역과 데이터 센터 사이에는 많은 광 링크가 있습니다. 가장 큰 지역 중 하나에는 서로 간의 AZ 통신 및 다른 지역과의 통신 센터(환승 센터)만을 위해 388개의 채널이 배치되었습니다. 전체적으로 이것은 미친 짓이다 5000테라비트.

백본 AWS는 클라우드용으로 특별히 구축되고 최적화되었습니다. 우리는 채널을 기반으로 구축합니다 100GB/초. 중국 지역을 제외하고는 완전히 통제합니다. 트래픽은 다른 회사의 부하와 공유되지 않습니다.

물론, 당사가 프라이빗 백본 네트워크를 갖춘 유일한 클라우드 제공업체는 아닙니다. 점점 더 많은 대기업이 이 길을 따르고 있습니다. 이는 독립적인 연구자들에 의해 확인되었습니다. 예를 들어 전신.

그래프는 콘텐츠 제공업체와 클라우드 제공업체의 점유율이 증가하고 있음을 보여줍니다. 이로 인해 백본 제공업체의 인터넷 트래픽 점유율은 지속적으로 감소하고 있습니다.

왜 이런 일이 발생하는지 설명하겠습니다. 이전에는 대부분의 웹 서비스를 인터넷에서 직접 액세스하고 사용할 수 있었습니다. 요즘에는 점점 더 많은 서버가 클라우드에 위치하며 다음을 통해 액세스할 수 있습니다. CDN - 콘텐츠 배포 네트워크. 리소스에 액세스하기 위해 사용자는 인터넷을 통해 가장 가까운 CDN PoP로만 이동합니다. 프레즌스 포인트. 대부분 근처 어딘가에 있습니다. 그런 다음 공용 인터넷을 떠나 개인 백본을 통해 예를 들어 대서양을 건너 리소스에 직접 도달합니다.

이런 추세가 이어진다면 10년 뒤 인터넷은 어떻게 변할지 궁금합니다.

물리적 채널

과학자들은 아직 우주에서 빛의 속도를 높이는 방법을 알아내지 못했지만 광섬유를 통해 빛을 전송하는 방법에서는 큰 발전을 이루었습니다. 우리는 현재 6912 광섬유 케이블을 사용합니다. 이는 설치 비용을 크게 최적화하는 데 도움이 됩니다.

일부 지역에서는 특수 케이블을 사용해야 합니다. 예를 들어, 시드니 지역에서는 흰개미 방지 특수 코팅이 된 케이블을 사용합니다. 

누구도 문제로부터 안전하지 않으며 때로는 채널이 손상될 수도 있습니다. 오른쪽 사진은 미국 한 지역의 광케이블이 건설 노동자들에 의해 찢어진 모습이다. 이번 사고로 인해 데이터 패킷이 13개만 손실됐는데, 이는 놀라운 일이다. 다시 한번 - 단 13개! 시스템은 문자 그대로 즉시 백업 채널로 전환되었으며 규모가 작동하고 있습니다.

우리는 Amazon의 클라우드 서비스와 기술 중 일부를 질주했습니다. 우리 엔지니어들이 해결해야 할 작업의 규모에 대해 최소한 어느 정도 알고 계시기를 바랍니다. 개인적으로 저는 이것이 매우 흥미롭다고 생각합니다. 

이것은 AWS 장치에 관한 Vasily Pantyukhin의 XNUMX부작 중 마지막 부분입니다. 안에 첫 번째 부분에서는 서버 최적화 및 데이터베이스 확장에 대해 설명합니다. 초 — 서버리스 기능 및 Firecracker.

에 HighLoad ++ XNUMX월에는 Vasily Pantyukhin이 Amazon 장치에 대한 새로운 세부 정보를 공유할 예정입니다. 그 말할 것이다 Amazon의 실패 원인과 분산 시스템 설계에 대해 설명합니다. 24월 XNUMX일은 아직 가능해요 예약하다 좋은 가격에 티켓을 구매하고 나중에 결제하세요. HighLoad++에서 여러분을 기다리고 있습니다. 와서 이야기 나눠보세요!

출처 : habr.com