기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
신뢰성
정의
신뢰성이란 필요할 때 서비스 또는 시스템이 예상 기능을 수행할 수 있는 능력을 말합니다. 시스템의 신뢰성은 주어진 기간 내의 운영 품질 수준으로 측정할 수 있습니다. 이는 인프라 또는 서비스 중단으로부터 동적이며 안정적으로 복구할 수 있는 시스템의 능력을 의미하는 복원성과 대조됩니다.
가용성과 복원력을 사용하여 신뢰성을 측정하는 방법에 대한 자세한 내용은 AWS Well-Architected Framework의 신뢰성 요소를 참조하세요.
핵심 질문
가용성
가용성은 워크로드를 사용할 수 있는 시간의 비율입니다. 일반적인 목표에는 99%(연간 허용되는 가동 중지 시간 3.65일), 99.9%(8.77시간), 99.99%(52.6분)가 포함되며, 백분율의 9는 줄여서 표현합니다(99%는 ‘9 2개’, 99.9%는 ‘9 3개’ 등). AWS 와 온프레미스 데이터 센터 간의 네트워킹 솔루션 가용성은 전체 솔루션 또는 애플리케이션 가용성과 다를 수 있습니다.
네트워킹 솔루션의 가용성에 대한 핵심 질문은 다음과 같습니다.
-
AWS 내 리소스가 온프레미스 리소스와 통신할 수 없는 경우에도 계속 작동할 수 있나요? 그 반대도 마찬가지인가요?
-
계획된 유지 관리에 대한 예정된 가동 중지 시간은 가용성 지표에 포함시켜야 합니까, 아니면 제외시켜야 합니까?
-
전체 애플리케이션 상태와 별도로 네트워킹 계층의 가용성을 측정하려면 어떻게 해야 합니까?
Well-Architected Framework의 신뢰성 원칙의 가용성 섹션에 가용성 계산을 위한 제안과 공식이 수록되어 있습니다.
복원력
복원력은 인프라 또는 서비스 중단을 복구하고, 수요에 따라 컴퓨팅 리소스를 탄력적으로 확보하고, 구성 오류나 일시적 네트워크 문제 같은 중단 사태를 완화할 수 있는 워크로드의 능력입니다. 다중화 네트워크 구성 요소(링크, 네트워크 디바이스 등)가 자체적으로 예상되는 기능을 제공할 만큼 충분한 가용성을 갖지 못한다면 장애에 대한 복원력이 낮은 것입니다. 그 결과 사용자 경험이 열악해지고 저하됩니다.
네트워킹 솔루션의 복원력에 대한 핵심 질문은 다음과 같습니다.
-
동시에 발생하는 개별 장애는 몇 개까지 허용해야 합니까?
-
연결 솔루션과 내부 네트워크 모두에서 단일 장애 지점을 줄이려면 어떻게 해야 합니까?
-
분산 서비스 거부(DDoS) 이벤트에 대한 취약성은 무엇입니까?
기술 솔루션
먼저, 모든 하이브리드 네트워크 연결 솔루션에 높은 수준의 신뢰성이 필요한 것은 아니며 신뢰성 수준이 높아지면 그에 따라 비용도 증가한다는 점에 유의해야 합니다. 일부 시나리오에서는 다운타임이 비즈니스에 미치는 영향이 더 크기 때문에 기본 사이트에 신뢰할 수 있는 (다중화되어 있으며 복원력이 뛰어난) 연결이 필요할 수 있지만, 지역 사이트는 장애 발생 시 비즈니스에 미치는 영향이 낮기 때문에 동일한 수준의 신뢰성이 필요하지 않을 수 있습니다. AWS Direct Connect 설계에 대한 AWS Direct Connect 높은 복원력을 보장하는 모범 사례를 설명하므로 복원력 권장 사항을
복원력 측면에서 신뢰할 수 있는 하이브리드 네트워크 연결 솔루션을 구현하려면 설계에서 다음 측면을 고려해야 합니다.
-
이중화: 네트워크 연결, 엣지 네트워크 디바이스, 가용 영역 간 이중화, DX 위치 AWS 리전, 디바이스 전원, 광케이블 경로, 운영 체제를 포함하되 이에 국한되지 않는 하이브리드 네트워크 연결 경로의 단일 장애 지점을 제거하는 것을 목표로 합니다. 이 백서의 목적 및 범위를 위해 중복성은 네트워크 연결, 엣지 디바이스(예: 고객 게이트웨이 디바이스), AWS DX 위치 및 AWS 리전 (다수 리전 아키텍처의 경우)에 중점을 둡니다.
-
신뢰할 수 있는 장애 조치 구성 요소: 일부 시나리오에서는 시스템이 작동하지만 필요한 수준에서 기능을 수행하지 못할 수 있습니다. 이러한 상황은 계획된 다중 구성 요소가 중복되지 않은 상태로 작동하는 단일 장애 이벤트 중에 흔히 발생합니다. 즉, 사용량 때문에 네트워킹 부하가 다른 곳으로 갈 곳이 없어 전체 솔루션을 위한 용량이 충분하지 않게 됩니다.
-
장애 조치 시간: 장애 조치 시간은 보조 구성 요소가 기본 구성 요소의 역할을 완전히 인계하는 데 걸리는 시간입니다. 장애 조치 시간에는 장애를 감지하는 데 걸리는 시간, 보조 연결을 활성화하는 데 걸리는 시간, 나머지 네트워크에 변경 사항을 알리는 데 걸리는 시간 등 여러 요소가 있습니다. 링크의 경우 데드 피어 감지(DPD)를 사용하고 VPN 링크의 경우 양방향 전달 감지(BFD)를 사용하여 장애 감지를 개선할 수 있습니다 AWS Direct Connect . 보조 연결을 활성화하는 데 걸리는 시간은 매우 짧거나(이러한 연결이 항상 활성 상태인 경우), 짧은 기간이거나(사전 구성된 VPN 연결을 활성화해야 하는 경우), 더 길 수 있습니다(물리적 리소스를 이동하거나 새 리소스를 구성해야 하는 경우). 나머지 네트워크에 대한 알림은 일반적으로 고객 네트워크 내의 라우팅 프로토콜을 통해 이루어지며, 각 프로토콜의 수렴 시간과 구성 옵션이 다릅니다. 이러한 구성은 본 백서의 범위를 벗어납니다.
-
트래픽 엔지니어링: 복원력이 뛰어난 하이브리드 네트워크 연결 설계의 맥락에서의 트래픽 엔지니어링은 정상 및 장애 시나리오에서 사용 가능한 여러 연결을 통해 트래픽이 어떻게 흘러야 하는지를 해결하는 것을 목표로 합니다. 다양한 장애 시나리오에서 솔루션이 어떻게 작동하는지, 비즈니스에서 수용할 수 있는지 여부를 살펴봐야 하는 design for failure 개념을 따르는 것이 좋습니다. 이 섹션에서는 하이브리드 네트워크 연결 솔루션의 전반적인 복원력 수준을 향상시키는 것을 목표로 하는 몇 가지 일반적인 트래픽 엔지니어링 사용 사례에 대해 설명합니다. AWS Direct Connect 라우팅 및 BGP 트래픽 흐름에 영향을 미치는 여러 트래픽 엔지니어링 옵션(커뮤니티, BGP 로컬 기본 설정, AS 경로 길이)에 대해 설명합니다. 효과적인 트래픽 엔지니어링 솔루션을 설계하려면 각 AWS 네트워킹 구성 요소가 라우팅 평가 및 선택 측면에서 IP 라우팅을 처리하는 방법과 라우팅 선택에 영향을 미칠 수 있는 메커니즘을 잘 이해해야 합니다. 이에 대한 자세한 내용은 이 문서에서 다루지 않습니다. 자세한 내용은 Transit Gateway Route Evaluation Order , Site-to-Site VPN Route Priority , Direct Connect Routing 및 BGP 필요한 경우 설명서를 참조하세요.
참고
VPC 라우팅 테이블에서 추가 라우팅 선택 규칙이 있는 접두사 목록을 참조할 수 있습니다. 이 사용 사례에 대한 자세한 내용은 접두사 목록의 라우팅 우선 순위를 참조하세요. AWS Transit Gateway 라우팅 테이블은 접두사 목록도 지원하지만 적용되면 특정 라우팅 항목으로 확장됩니다.
더 구체적인 경로를 사용한 이중 Site-to-Site VPN 연결 예제
이 시나리오는 인터넷을 통해 에 대한 중복 VPN 연결을 통해 단일 AWS 리전 에 연결하는 소규모 온프레미스 사이트를 기반으로 합니다 AWS Transit Gateway. 그림 10에 나와 있는 트래픽 엔지니어링 설계에서는 트래픽 엔지니어링을 통해 경로 선택에 영향을 주어 하이브리드 연결 솔루션 신뢰성을 높이는 다음과 같은 이점을 얻을 수 있음을 보여줍니다.
-
복원력 있는 하이브리드 연결: 중복 VPN 연결은 각각 동일한 성능 용량을 제공하고, 동적 라우팅 프로토콜(BGP)을 사용하여 자동 장애 조치를 지원하며, VPN 데드 피어 감지를 사용하여 연결 장애 감지 속도를 높입니다.
-
성능 효율성: 전체 VPN 연결 대역폭을 최대화하는 데 도움이 되도록 AWS Transit Gateway 두 VPN 연결ECMP에 걸쳐 를 구성합니다. 또는 사이트 요약 경로와 함께 서로 다른 보다 구체적인 경로를 광고하여 두 VPN 연결에서 부하를 독립성으로 관리할 수 있습니다.
그림 10 - 더 구체적인 경로를 사용한 이중 Site-to-Site VPN 연결 예제
다중 DX 연결이 있는 이중 온프레미스 사이트 예시
그림 11에 나와 있는 시나리오는 서로 다른 지리적 리전에 위치하고 DXGW 및 와 AWS Direct Connect 함께 AWS 를 사용하여 최대 복원력 연결 모델( AWS Direct Connect 복원력 권장 사항
BGP 커뮤니티 속성을 에 보급된 경로와 연결하면 측면에서 AWS DXGW 송신 경로 선택에 영향을 미칠 AWS DXGW수 있습니다. 이러한 커뮤니티 속성은 광고된 경로에 할당된 AWS의 BGP 로컬 기본 설정 속성을 제어합니다. 자세한 내용은 AWS DX 라우팅 정책 및 BGP 커뮤니티 를 참조하세요.
AWS 리전 수준에서 연결의 신뢰성을 극대화하기 위해 각 AWS DX 연결 쌍은 각 온프레미스 사이트와 간의 데이터 전송에 동시에 둘 다를 사용할 수 ECMP 있도록 를 구성합니다 AWS.
그림 11 - 다중 DX 연결이 있는 이중 온프레미스 사이트 예시
이 설계를 사용하면 온프레미스 네트워크(광고된 접두사 길이와 BGP 커뮤니티가 동일한)로 향하는 트래픽 흐름이 를 사용하여 사이트당 듀얼 DX 연결에 분산됩니다ECMP. 그러나 ECMP가 DX 연결 전반에 걸쳐 필요하지 않은 경우 앞서 논의되고 라우팅 정책 및 BGP 커뮤니티 설명서에 설명된 것과 동일한 개념을 사용하여 DX 연결 수준에서 경로 선택을 추가로 엔지니어링할 수 있습니다.
참고: 온프레미스 데이터 센터 내의 경로에 보안 디바이스가 있는 경우 이러한 디바이스는 하나의 DX 링크를 통해 나가고 동일한 데이터 센터 사이트 내의 다른 DX 링크(두 링크 모두 에서 사용됨ECMP)에서 들어오는 트래픽 흐름을 허용하도록 구성해야 합니다.
VPN AWS DX 연결에 대한 백업으로서의 연결 예제
VPN 는 연결에 백업 네트워크 연결을 제공하도록 선택할 수 있습니다 AWS Direct Connect . 일반적으로 이러한 유형의 연결 모델은 인터넷을 통한 예측 불가능한 성능으로 인해 전체 하이브리드 연결 솔루션에 더 낮은 수준의 안정성을 제공하고 퍼블릭 인터넷을 통한 연결에 대해 얻을 SLA 수 있는 것은 없기 때문에 비용에 의해 구동됩니다. 유효하고 비용 효율적인 연결 모델이므로 비용이 최우선 고려 사항이고 예산이 제한적일 때 사용하거나 보조 DX를 프로비저닝할 수 있을 때까지 임시 솔루션으로 사용해야 합니다. 그림 12는 이 연결 모델의 설계를 보여줍니다. VPN 와 DX 연결이 모두 에서 종료되는 이 설계의 한 가지 주요 고려 AWS Transit Gateway사항은 VPN 연결이 에 연결된 DX 연결을 통해 광고할 수 있는 경로에 비해 더 많은 수의 경로를 광고할 수 있다는 것입니다 AWS Transit Gateway. 이로 인해 라우팅이 최적화되지 않는 상황이 발생할 수 있습니다. 이 문제를 해결하기 위한 옵션은 VPN 연결에서 수신한 경로에 대해 고객 게이트웨이 디바이스(CGW)에서 경로 필터링을 구성하여 요약 경로만 수락할 수 있도록 하는 것입니다.
참고: 에서 요약 경로를 생성하려면 요약이 더 구체적인 경로를 따라 전송되도록 라우팅 AWS Transit Gateway 테이블의 임의의 연결에 대한 정적 경로를 지정 AWS Transit Gateway해야 합니다.
AWS Transit Gateway 라우팅 테이블의 관점에서 온프레미스 접두사에 대한 경로는 접두사 길이VPN가 동일한 AWS DX 연결(를 통해DXGW)과 에서 모두 수신됩니다. 의 라우팅 우선 순위 로직 AWS Transit Gateway에 따라 Direct Connect를 통해 수신된 경로는 를 통해 Site-to-Site 수신된 경로보다 선호도가 높VPN으므로 를 통한 경로 AWS Direct Connect 가 온프레미스 네트워크(들)에 도달하는 것이 선호됩니다.
그림 12 - AWS DX VPN 연결에 대한 백업으로서의 연결 예제
다음 의사 결정 트리는 복원력이 뛰어나고 안정적인 하이브리드 네트워크 연결을 달성하기 위해 원하는 결정을 내리는 과정을 안내합니다. 자세한 내용은 AWS Direct Connect Resiliency Toolkit을 참조하세요.
그림 13 - 신뢰성 의사 결정 트리
