Nasdaq 사례로 살펴보는 Amazon Time Sync 기반 분산 시스템 개선

세션 노트

Barbara Lipskovoff의 말: 동기화된 시계는 통신을 줄여 분산 시스템 성능을 향상시킬 수 있습니다.
시계의 목적
일반적인 측정 척도로서의 시계.
분산 시스템에서의 전통적인 사용: 신뢰할 수 있는 기준으로 간주하지 않고 사람의 관찰 용도로 사용합니다.
애플리케이션:
로그 메시지, 지표, 모니터링, UI 대시보드.
금융 서비스, 의료, 방송 미디어, 온라인 게임과 같은 산업 분야의 감사.
신뢰할 수 있는 시계를 활용하면 분산 시스템의 운영을 단순화하고 잠금과 리더 선출에 필요한 통신을 줄일 수 있습니다.

시계란 무엇입니까?

컴퓨터 시계 제작의 기본

주기적으로 틱하는 것과 이러한 틱을 계산하는 것이 필요합니다.
일반적으로 두 기능을 모두 결합한 단일 하드웨어입니다.
방정식 표현:
시간 T에서 클록 C는 경과된 사이클 수를 주파수와 상수로 나눈 값으로 읽을 수 있습니다.
간단한 예:
초당 1 주기로 하드웨어 틱을 사용하여 1000 주기를 계산하면 1000초가 경과됩니다.
결론:
컴퓨터에 시계를 만들기 위한 기본 구성 요소입니다.

시계용 하드웨어 옵션

하드웨어 범위

소형 폼 팩터 수정 발진기부터 세슘빔, 수소 메이저, 곧 출시될 광시계와 같은 대형 장비까지.
폼 팩터는 몇 밀리미터부터 캐비닛 크기의 장비까지 다양합니다.
가격대:
소형 폼 팩터는 클라우드 컴퓨팅에 더 비용 효율적입니다.
대형 장비는 수십만 달러의 비용이 들 수 있습니다.
품질과 정확성:
1마이크로초 이내의 시간을 유지하는 정확도는 다양합니다.
소형 폼 팩터: 몇 초 동안 정확합니다.
수소 메이저 및 광학 시계: 수년, 잠재적으로 수세기 동안 정확합니다.

시계 드리프트

모든 발진기 드리프트

가장 정확한 원자시계라도 드리프트를 경험합니다.
마이크로초 수준의 드리프트를 매우 정확한 시계로 관찰하려면 수세기가 걸릴 수 있습니다.
드리프트 원인:
제조 공정, 노화(물리학자들의 우려)
클라우드 공급자의 경우: CPUs 및 서버에 대한 작업 부하 영향으로 인한 전원 공급 장치 또는 온도 변화의 작은 차이.
드리프트의 영향:
주기의 빈도는 시간이 지남에 따라 변하므로 클록 드리프트가 발생합니다.
예: 5일 동안 실행된 EC2 인스턴스는 수정 없이 75밀리초의 드리프트를 보여주었습니다.
시계 드리프트 해결
추적 및 수정:
인간이 손목시계를 조정하는 것과 마찬가지로 컴퓨터도 드리프트를 추적하고 수정해야 합니다.
Network Time Protocol (NTP):
수십 년 동안 시계를 동기화하는 데 사용되었습니다.
시간을 조정하기 위해 서버(참조 시계)에 메시지를 보내는 클라이언트 시계가 필요합니다.

시계 동기화의 과제

지속적인 조정이 필요함

클록 사이클의 빈도는 끊임없이 변합니다.
한 번이 아니라 반복적으로 정확한 시간을 요청해야 합니다.
네트워크 통신 문제:
네트워크를 통해 교환되는 메시지에는 다양한 지연이 있습니다.
메시지가 삭제되면 오류가 발생할 위험이 있습니다.

문제의 일부인 네트워크

실행 가능성 및 지연

시끄러운 통신 지연으로 인해 실제 클럭 드리프트를 식별하기가 어렵습니다.
네트워크 비대칭:
네트워크는 대칭적이지 않으므로 완벽한 시계에서도 시간 차이가 관찰됩니다.
클럭 오류와 네트워크 비대칭을 구별하기가 어렵습니다.

AWS 해결책: Amazon Time Sync Service

고객을 위해 비결정적 네트워크를 통한 클록 동기화의 복잡성을 해결합니다.
구현:
2017.에서 소개됨
NTP(Network Time Protocol) 엔드포인트를 활용합니다.
전 세계 모든 EC2 인스턴스에 대해 로컬에서 사용할 수 있습니다.
투자:
이 서비스를 전 세계적으로 지원하기 위해 상당한 엔지니어링 및 하드웨어 투자가 이루어졌습니다.

Amazon Time Sync Service

기본 설정

Nitro system 및 소프트웨어 시간 데몬이 있는 EC2 인스턴스.
NTP 패킷은 AWS 배포 시스템에서 Nitro system를 통해 서버 시계를 수정합니다.
정확성:
NTP 서비스 정확도: 1 밀리초 미만, 일반적으로 500-700 마이크로초.
고객 혜택:
손쉬운 무인 서비스; 고객이 기본 기술을 이해할 필요가 없습니다.

나노초 정확도에 대한 과제와 솔루션

고객 요구

고객은 분산 시스템에 대해 1 밀리초 이상의 정확도를 원했습니다.
AWS 접근 방식:
나노초 수준의 정확도를 위해 하드웨어에 투자했습니다.
GPS의 전용 케이블과 중복 원자 하드웨어 시계를 사용했습니다.
AWS 네트워크를 우회하여 EC2 인스턴스로 직접 전송된 신호(GPS).
전용 시계 동기화:
클록 동기화를 위한 신호는 데이터나 제어 평면이 아닌 전적으로 전용입니다.

Nitro 기반 시스템

Nitro 시계: 하드웨어 참조 시계.
NTP 패킷 통신: Nitro 카드와 직접 연결되며 네트워크가 개입되지 않습니다.
PTP 하드웨어 시계:
Nitro system에 Precision Time Protocol(PTP) 하드웨어 시계를 추가했습니다.
사용자는 PTP 하드웨어 시계(PHC)를 읽어 시스템 시계를 로컬로 수정합니다.
정확도 수준:
NTP: 소프트웨어 수준에서 100 마이크로초 미만.
PTP: 소프트웨어 수준에서 약 20 마이크로초.
광범위한 구현:
다양한 서버 유형(Graviton, Intel, AMD, GPUs)에 추가된 참조 PTP 하드웨어 시계입니다.
Nitro system 하드웨어를 기반으로 글로벌 인프라 투자를 지원합니다.

Hardware Packet Timestamping

주요 응용 프로그램 및 이점

목적

타임스탬프 네트워크 패킷에 대해 나노초 수준의 정확도를 활성화합니다.
이익:
분산 워크로드에 대한 네트워크 성능의 관찰 가능성이 향상되었습니다.
나노초 해상도로 서버에서 수신한 메시지의 순서를 지정할 수 있습니다.
드라이버에 내장된 기능으로 클래식 소켓 API 또는 DPDK 툴킷을 통해 액세스할 수 있습니다.

작동 방식

기능 출시 전

애플리케이션 레이어 타임스탬프:
메시지가 도착하고 Nitro system를 통과하여 인스턴스에 도달합니다.
애플리케이션은 시스템 시계에서 시간을 읽고 타임스탬프를 메시지에 첨부합니다.
API 소켓을 사용하여 C 코드의 4 라인을 사용하세요.
기능 출시 이후(Hardware Packet Timestamping):
Nitro system 및 Nitro 시계:
메시지가 도착하고 패킷은 인스턴스에 도달하기 전에 Nitro system 및 Nitro 시계에 의해 타임스탬프가 지정됩니다.
타임스탬프가 지정된 메시지는 애플리케이션 계층으로 전달됩니다.

구현 및 액세스

액세스 방법

클래식 소켓 API.
DPDK(데이터 플레인 개발 키트) 커널 인프라를 우회하여 직접 패킷 액세스를 위한 툴킷입니다.
해결:
네트워크 패킷에 대해 수신된 타임스탬프에 나노초 해상도를 제공합니다.

예시 비교

전에

메시지 수신 후 시스템 시계에서 시간을 읽는 간단한 프로세스입니다.
후에:
메시지가 애플리케이션에 도달하기 전에 하드웨어에서 패킷 타임스탬프를 수행하여 보다 정확한 타임스탬프를 제공하는 향상된 프로세스입니다.

Hardware Packet Timestamping의 향상된 이점

정확도 향상

네트워크 성능에 대한 보다 정확한 보기를 제공합니다.
예: 두 인스턴스 간의 왕복 시간을 측정합니다.
사용자 공간 애플리케이션 측정: ~400 마이크로초.
하드웨어 패킷 타임스탬프 측정: ~100-150 마이크로초.
관찰 가능한 차이점:
운영 체제 및 네트워크 스택에서 소요된 시간으로 인한 ~250 마이크로초의 차이.
왕복 시간의 약 2/3를 나타내며 보다 정확한 관찰 가능성을 강조합니다.
보다 선명한 네트워크 성능:
애플리케이션과 네트워크 간의 지연을 식별하고 분석할 수 있습니다.

NASDAQ의 사용 사례 소개

목적

AWS의 정밀 시간 기술을 사용하여 퍼블릭 클라우드 환경에서 시장 운영을 향한 NASDAQ의 발전을 보여줍니다.

NASDAQ 배경

금융시장의 혁신가

1971.에서 만들어진 세계 최초의 전자 거래소
주식, 채권, 옵션 및 파생상품을 포함하여 전 세계적으로 30 시장을 운영합니다.
Amazon을 포함하여 시가총액 기준 최고의 기술 기업을 호스팅하는 것으로 알려져 있습니다.
기술 제공자:
130 시장 운영자 및 2300 금융 기관에 서비스를 제공합니다.
전 세계적으로 NASDAQ 거래소에 상장된 44,400개 이상의 공개 회사를 지원합니다.
자본 시장 수명주기 지원을 위해 6000 기업에 기술을 제공합니다.

NASDAQ의 클라우드 여정

10년 전에 시작됨

AWS Redshift(2012-2013)를 사용하여 데이터 저장소 및 데이터 웨어하우징으로 시작했습니다.
현재 백오피스 기능을 지원하는 약 60 페타바이트의 데이터를 저장합니다.
실시간 처리로의 진화:
스트리밍 실시간 시장정보를 활용한 시장 감시.
퍼블릭 클라우드를 통해 시장 데이터 유통이 가능합니다.
AWS Outpost에서 옵션 교환 시작:
2022,에서는 AWS Outpost에서 NASDAQ MRX를 시작했습니다.
현재 Outpost에서 6+ 시장 시스템을 실행하고 있습니다.
퍼블릭 클라우드의 중요 시스템:
시장 참가자에게 실시간 통찰력을 제공하는 호스트 시스템입니다.
대규모 메시지 볼륨과 최대 관리 용량에 맞게 클라우드 확장성, 성능, 적절한 크기 조정을 활용합니다.

클라우드로 이전할 때의 구체적인 과제

지리적 제약

주식 및 주식 옵션 거래는 주로 뉴저지 북부에서 이루어집니다.
대기 시간 종속성은 특정 위치에 컴퓨터를 배포해야 합니다.
초저지연 트랜잭션:
~20 마이크로초의 명령 실행 시간으로 측정된 트랜잭션입니다.
높은 메시지 볼륨:
하루에 100 10억 개의 메시지를 처리합니다.
특정 교환 시스템은 초당 최대 2-3백만 개의 메시지를 처리합니다.
높은 탄력성 및 가동 시간 기대:
효율적이고 잘 운영되는 자본 시장에 매우 중요합니다.
수많은 공개 회사의 주요 상장 장소입니다.

NASDAQ 교환 시스템 아키텍처

매칭 엔진

주문, 거래 예약, 구매자와 판매자 매칭을 위한 기본 로직을 처리합니다.
주문 포트:
주문 흐름을 거래소로 보내는 고객을 위한 인터페이스입니다.
검증, 거래 전 위험 및 기타 기능을 수행합니다.
공개 시장 데이터 피드:
매칭 엔진 활동 보기를 시장에 게시합니다(예: NASDAQ I).
클라이언트:
인바운드 트랜잭션을 통해 주문 포트 및 매칭 엔진에 대한 주문 흐름을 제공합니다.

기존 온프레미스 모델

목적

참가자에게 결정론적이고 통계적으로 공정한 시장을 제공합니다.
물리적 특성에 대한 의존성:
데이터 센터의 광섬유 길이.
시스템 구성 요소와 고객 간의 스위치 홉 수입니다.
네트워크 지연의 원인:
D1 및 D2:
물리적 설정으로 인한 네트워크 지연의 주요 원인입니다.
D3:
네트워크 및 처리 구성 요소를 모두 포함합니다.
왕복 지연 시간의 약 절반, 대략 10 마이크로초입니다.
순차적 처리:
매칭 엔진의 순차적 처리를 통해 주문이 고객이 제출하고 공개 시장 데이터 피드에 반환될 때 일관되고 반복적으로 처리되도록 보장합니다.

퍼블릭 클라우드의 과제

예측할 수 없는 네트워크 상태.
고정된 케이블 길이나 알려진 스위치 홉이 없습니다.
다른 네트워크 트래픽이나 예측할 수 없는 노드 배치로 인해 지연이 발생할 수 있습니다.

해결 방법: 하드웨어 타임스탬프 및 버퍼 재정렬

주요 기간

D1, D2, 및 D3에 집중하여 네트워크를 통한 트랜잭션 시간을 이해하세요.
하드웨어 타임스탬프:
나노초 정밀도를 사용하여 각 네트워크 지점에서 각 트랜잭션의 시간을 기록합니다.
Nitro 및 Amazon Time Sync Service를 통해 제공됩니다.
버퍼 재정렬:
매칭 엔진 앞에 앉습니다.
인바운드 트랜잭션 주문에 중점을 둡니다(아웃바운드 흐름에도 유사한 기술이 적용됨).
시간 기반 경계:
하드웨어 타임스탬프를 사용하여 정의합니다(예: 클라이언트 주문의 경우 T1, T2, T3).
트랜잭션이 시작된 순서대로 처리되도록 보장합니다.
특허 기술:
대기 시간이 짧은 시스템을 위한 퍼블릭 클라우드를 향한 NASDAQ의 자세를 발전시키는 기반입니다.

프로토타입 및 실험

AWS 사용된 인스턴스

M7I.2XL 인스턴스.
근접 배치 그룹:
컴퓨팅 노드가 몇 개의 랙 또는 동일한 랙 내에 서로 가깝게 배치되었는지 확인했습니다.
재주문을 위한 하드웨어 타임스탬프:
타임스탬프를 기준으로 패킷을 재정렬하는 데 사용됩니다.
시간 경계를 사용한 테스트:
5 마이크로초 경계는 ~25% 패킷을 재정렬했습니다.
50 마이크로초 경계는 최대 84% 이상의 패킷으로 재정렬되었습니다.
반복과 발전:
근접 배치 기능과 Amazon Time Sync Service에 대한 지속적인 작업을 통해 더욱 세분화되었습니다.

전략적 비전

확장 가능한 거래 시스템

퍼블릭 클라우드에 배포하든 온프레미스에 배포하든 확장 가능한 고성능 시스템을 개발하는 것을 목표로 합니다.
퍼블릭 클라우드의 혁신:
AI 및 퍼블릭 클라우드로의 데이터 마이그레이션을 포함한 클라우드 혁신을 수용하세요.
향상된 보안 및 안정성:
가용성, 보안 및 안정성에 대한 기대가 높습니다.
퍼블릭 클라우드는 탄력성을 고려하여 책임감 있게 구축할 경우 상당한 이점을 제공합니다.
시장 전문 지식 활용:
30개 거래소를 전 세계적으로 운영하고 130개 시장에 기술을 공급하는 리더로서 NASDAQ는 기술 적용에 대해 전략적으로 생각합니다.

소프트웨어에서 좋은 시계 활용

동기화된 시계를 사용하여 분산 시스템에서 통신을 줄이는 것을 강조합니다.
AWS 시간 동기화 서비스:
소프트웨어에서 마이크로초 정확도의 나노초 범위 클럭을 제공합니다.
Hardware Packet Timestamping:
애플리케이션이 보다 정확한 타이밍의 이점을 활용하여 성능과 관찰 가능성을 향상할 수 있도록 합니다.

분산 시스템의 과제

다중 시계

분산 시스템에는 각각 자체 시계가 있는 여러 서버가 있습니다.
시계가 완벽하게 동기화되지 않아 이벤트 순서가 복잡해집니다.
기존 솔루션:
주문에 사용되는 분산 잠금, 리더 선택 및 합의 알고리즘.
이러한 알고리즘은 시스템이 성장함에 따라 성능을 제한하고 복잡성을 증가시킵니다.

클록 불확실성 및 오류 한계

인간의 관점

인간은 시간이 정확하다고 생각하지만(예: 오후 2) 시계에는 불확실성이 있습니다.
정밀 시계:
AWS 소프트웨어 계층의 정밀 클록에는 불확실성(예: ±20 마이크로초)이 있습니다.
응용 프로그램의 오류 한계:
애플리케이션은 이러한 오차 한계를 고려해야 합니다.
예: 은행 계좌 거래에서는 초과인출을 방지하기 위해 올바른 주문이 필요합니다.

시계 불확실성 추정

복잡한 질문

고객은 시계의 불확실성 간격을 이해해야 합니다.
예:
오류를 추정하려면 EC2 인스턴스에서 시간 동기화 데몬을 검사하세요.
시간 동기화 소스:
인터넷 NTP 서버(예: time.aws.com): ~395 마이크로초의 불확실성.
Nitro system를 통한 로컬 NTP 서버: ~90 마이크로초의 불확실성.
PTP 하드웨어 시계(Nitro system를 통해 Amazon Time Sync Service 향상): 더 정확합니다.

AWS 단순화

AWS는 고객의 시계 불확실성을 단순화하고 관리하는 것을 목표로 합니다.
깊은 기술 지식이 없어도 고객에게 도움이 될 수 있도록 자세한 설명이 제공됩니다.

AWS Clockbound 소프트웨어

목적

고객이 클록 불확실성을 쉽게 이해하고 관리할 수 있습니다.
유효성:
2021.
이후 GitHub에서 사용 가능한 오픈 소스 주요 기능:
한 번의 작업으로 세 가지 정보를 제공합니다.
현재 시간: E.g., 월요일 2:00 오후
불확실성의 창: E.g., ±20 마이크로초.
시계 상태: 초기화됨, 자유 실행 또는 동기화됨.
지원 및 확장성:
PTP 하드웨어 및 NTP 소스를 지원합니다.
초당 수백만 개의 쿼리가 가능한 까다로운 워크로드로 확장됩니다.
언어 및 호환성:
성능과 메모리 안전을 위해 Rust로 작성되었습니다.
RSS에서 클라우드 및 C 애플리케이션으로 사용할 수 있습니다.

시계 오류 경계

오실레이터 드리프트 및 통신 지연으로 인한 최악의 클럭 오류에 대한 가장 엄격한 경계입니다.
Clockbound의 역할:
누적된 오류에도 불구하고 나노초 및 마이크로초 수준의 정확도 시나리오에서 빛나는 정확한 답변을 제공합니다.
YugabyteDB Clockbound의 사용법
AWS의 오픈 소스 Clockbound 소프트웨어를 사용하는 오픈 소스 데이터베이스입니다.
하이브리드 논리 클록 시스템:
전통적인 논리적 순서와 정밀 시계를 결합합니다.
관찰된 이점:
대기 시간 감소: 고객은 대기 시간이 3배 단축되는 것을 경험했습니다.
처리량 증가: 트랜잭션 처리량이 두 배로 증가했습니다.
재시도 횟수 감소: 트랜잭션(예: 읽기 및 쓰기) 간의 충돌 감소로 인해 재시도 횟수가 1000배 감소했습니다.
향상된 고객 경험:
데이터베이스의 일관성, 격리 및 전반적인 사용자 경험이 향상되었습니다.

AWS의 정밀 시계 사용

정밀시계를 활용한 서비스

Aurora DSQL: 다중 지역, 글로벌 규모의 데이터베이스입니다.
Dynamo DB 전역 테이블: 다중 지역, 전역 규모 데이터베이스.
사용 이유:
지역 간 네트워크 지연 시간(예: US West 2과 US East 1 사이의 70밀리초) 정밀 시계의 장점:
마이크로초에서 나노초 범위의 시계를 사용하면 네트워크를 통해 패킷을 보내는 것보다 더 빠른 트랜잭션 주문이 가능합니다.

AWS의 Aurora DSQL에서 정밀 시계 사용

다중 지역 데이터베이스 일관성

다중 지역 데이터베이스에서 일관성과 격리를 유지하는 데 중요합니다.
Clockbound의 불확실성 창:
여러 지역의 이벤트를 관리하는 데 사용됩니다.
예: 이벤트 1는 이벤트 2 또는 3.에 비해 과거임이 보장됩니다.
2 및 3 이벤트는 중복되므로 재시도를 방지하려면 신중한 처리가 필요합니다.
가능한 해결책:
재시도를 방지하기 위해 이벤트(예: 이벤트 3) 시작을 지연합니다.
데이터베이스 설계 고려 사항:
시스템 설계, 이벤트 유형 및 고객 요구 사항에 따라 다릅니다.

새로운 EST 데몬 릴리스

목적

고객을 위한 고급 타이밍 기능의 사용을 단순화합니다.
개량:
기존 Clockbound 소프트웨어와 동일한 소프트웨어 스택 아래 구축되었습니다.
더 높은 정확성과 신뢰성을 위해 대폭 개선되었습니다.
고객 신뢰:
AWS는 시간이 지남에 따라 고객의 신뢰와 경험을 유지하고 개선하는 것을 목표로 합니다.
독립형 시간 클라이언트:
Clockbound에는 이제 독립형 시간 클라이언트와 데몬이 포함됩니다.
동기화 및 정보 제공:
운영 체제 시계를 동기화합니다.
현재 시간, 불확실성 창 크기, 시계 상태를 애플리케이션에 제공합니다.
규제 및 관찰 가능성 이유:
규정 준수 및 시스템 관찰 가능성에 중요합니다.
내장된 지표 및 관찰 가능성:
관찰 가능성은 기본 제공 측정항목을 갖춘 일류 시민입니다.
고성능 및 메모리 안전성:
메모리 안전성과 고성능을 위해 동일한 Rust 소프트웨어 스택을 기반으로 구축되었습니다.
프로세스 간 통신을 위한 공유 메모리 세그먼트를 통해 높은 성능을 구현합니다.

클라우드 우선 설계 패러다임 전환

클라우드 우선으로 시스템을 재설계했습니다.
기존 피드백 루프 시스템에서 클라우드 애플리케이션에 더 적합한 피드포워드 정보 시스템으로 이동합니다.
테스트용 시뮬레이터
새로운 소프트웨어 스택은 시뮬레이터와 함께 제공됩니다.
사용자가 소프트웨어를 테스트하고, 문제를 보고하고, 개선 사항을 제안할 수 있습니다.
클라우드 네이티브 동기화
가용성은 모든 가상화 계층에서 최우선 순위입니다.
VM clock(가상 머신 시계)이라는 Linux 커널에 새로운 기능을 제공했습니다.
새로운 Clockbound 릴리스와의 조합:
Nitro 시계에서 인스턴스로 시간을 직접 전송할 수 있습니다.
유지 관리 이벤트 중 성능을 향상하여 원활한 워크로드 운영을 보장합니다.
새로운 시스템의 성능
시스템은 여러 시간에 걸쳐 ±1 마이크로초 이내로 드리프트를 추적하고 수정합니다.
불확실성의 창:
Clockbound 데몬을 쿼리하여 표시된 불확실성 창의 크기입니다.
톱니 모양 동작: 시계가 업데이트됨에 따라 커지고 작아집니다.
달성된 불확실성 창: 애플리케이션 내에서 20에서 26 마이크로초 사이입니다.

뉴저지 북부의 주식 및 옵션 시장이 중요한 이유는 Wall Street 거래를 지원하는 주요 금융 데이터 허브(예: Secaucus의 Equinix)가 있고, 지리적 근접성 덕분에 금융 전문가들이 모이며, 안정적인 배당을 제공하는 NJR 같은 기업을 포함한 탄탄한 지역 경제가 형성되어 있기 때문입니다. 이 모든 요소는 강력한 인프라와 NYC 통근망의 지원을 받아

첨단 데이터 센터부터 전통 기업까지 아우르는 다양한 투자 환경을 조성합니다.

Northern NJ가 주식 및 옵션의 허브인 이유

강력한 데이터 센터: Secaucus, NJ는 초단타 거래, 맨해튼의 활동 이동 및 NJ를 금융 기술의 중심 위치로 만드는 데 중요한 주요 데이터 센터(예: Equinix NY4)를 호스팅합니다.
NYC 근접성: 우수한 교통 수단(기차, 페리)이 NJ를 NYC에 연결하여 금융 전문가를 유치하고 맨해튼 금융 지구에서 일하는 사람들을 위한 최고의 주거 지역으로 만들어 버겐 및 허드슨 카운티와 같은 곳의 지역 경제를 활성화합니다.
강력한 현지 회사: 뉴저지에는 New Jersey Resources(NJR)와 같은 회사가 설립되었으며, 이 회사는 일관된 배당금 및 가치 지표로 유명한 배당 중심의 주식 투자자에게 매력적입니다.
투자 생태계: 이 지역은 강력한 부동산 평가(자본 형태), 안정적인 수요, NJEDA(뉴저지 경제 개발청)가 지원하는 성장하는 "혁신 생태계"의 혜택을 받아 전통적 투자와 기술 중심 투자를 모두 육성합니다.
세금 및 규제 환경: 뉴저지에는 비거주 스톡 옵션 소득과 같은 특정 규정이 있어 투자자에게 영향을 미치는 정교한 금융 규제 프레임워크를 나타냅니다.
이것이 투자자에게 의미하는 바
데이터 및 기술 포커스: 금융을 지원하는 기술 관련 영역 및 데이터 인프라에 기회가 있습니다.
가치 및 소득: 부동산 투자(부동산 자산)와 함께 주 또는 그 근처에 기반을 둔 안정적이고 배당금을 지급하는 회사를 찾으십시오.
통근 매력: NYC로의 통근이 많은 지역(예: Weehawken, Bergen 카운티)은 수요가 높아 견고한 부동산 자산 플레이를 나타냅니다.

Equinix의 Secaucus, NJ 캠퍼스(NY2, NY4, NY5, NY6)는 Wall Street의 핵심 저지연 허브로,

주요 금융 거래소 및 거래 생태계에 직접 연결되고

수많은 금융 회사를 수용하며 보안성과 신뢰성이 높은 코로케이션을 제공합니다.

이를 통해 고빈도 거래(HFT)와 Dow Jones 뉴스 피드 같은 필수 데이터 서비스에 필요한

속도와 시장 근접성을 보장합니다. 이러한 시설은 디지털 백본 역할을 하며 기업이

더 빠르게 거래할 수 있도록 서버를 거래소 가까이에 배치할 수 있게 합니다.

Wall Street에게 중요한 이유

낮은 대기 시간: 교환에 대한 물리적 근접성은 HFT에 중요한 데이터 이동 시간을 최소화합니다.
시장 접근: 거래 장소, 데이터 제공자(예: Dow Jones) 및 기타 금융 참여자와 직접 연결됩니다.
신뢰성: 중단 없는 금융 운영을 위해 강력한 전력, 냉각 및 보안을 제공하도록 설계되었습니다.

Amazon Aurora HA 및 DR 글로벌 탄력성을 위한 디자인 패턴

(DAT442)

탄력성 정의

중단으로부터 워크로드를 복구하는 능력
리소스의 동적 확보 및 중단 완화와 관련됨
고가용성(HA):
워크로드를 사용할 수 있는 시간 비율
역사적으로 측정됨(예: 5 9s 가용성)
재해 복구(DR):
사고 발생 후 워크로드를 복구하는 기술
복구 시간 목표(RTO): 서비스를 재개하는 최대 시간
복구 시점 목표(RPO): 허용되는 최대 데이터 손실
Aurora에 중점:
Aurora PostgreSQL(APG) 및 Aurora MySQL(AMS)
유사한 기능 및 탄력성

고가용성(HA)

목표: 시스템을 지속적으로 실행하고, 중단을 최소화하고, 단일 실패 지점을 방지합니다.
방법: 중복성, 자동 장애 조치, 로드 밸런싱(종종 동일한 데이터 센터 또는 지역 내)
예: 여러 인스턴스가 있는 웹 서버, 하나의 노드가 실패할 경우 자동 전환이 가능한 데이터베이스 클러스터.
초점: 사소하고 자주 발생하는 문제(예: 하드웨어 오류, 유지 관리)에 대한 내결함성.
재해 복구(DR)
목표: 대규모 재해(자연재해, 대규모 데이터 손상) 발생 후 비즈니스 운영을 복원합니다.
방법: 백업, 복제, 오프사이트 데이터 센터, 정의된 복구 절차(RTO/RPO).
예: 클라우드 백업에서 데이터 복원, 지역 중단 후 보조 지역으로 장애 조치.
초점: 대규모의 재난에 대한 탄력성.
주요 차이점 및 관계
범위: HA는 작은 오류를 처리합니다. DR는 큰 것을 처리합니다.
접근 방식: HA는 적극적입니다. DR는 반응적입니다.
통합: 보완적입니다. 강력한 HA는 DR의 필요성을 줄이는 반면, DR는 HA가 충분하지 않을 때 최고의 안전망을 제공합니다.

내 데이터베이스 노드가 실패하면 어떻게 되나요?

자체 관리형 데이터베이스

데이터베이스 엔진과 스토리지가 결합된 단일 노드
백업 중 잠재적인 성능 문제
RPO는 24시간만큼 높을 수 있습니다.
노드가 실패하면 RTO는 몇 시간이 걸릴 수 있습니다.
Aurora 내구성:
하나의 가용성 영역에서 단일 데이터베이스 클러스터로 시작
데이터 복제를 위해 Aurora 스토리지를 활용합니다.
3 AZs에 분산된 노드가 있는 멀티 테넌트 스토리지 제품군
각 쓰기는 3 AZs 전체에서 6 번 복제됩니다.
사용자는 사본 한 개에 대해서만 비용을 지불합니다.
RPO는 비동기 복제가 없는 0입니다.
Aurora는 페이지가 아닌 로그 레코드만 기록하여 내구성과 성능을 향상시킵니다.
Aurora의 백업 및 복원:
스토리지 엔진은 성능에 영향을 주지 않고 지속적으로 S3에 데이터를 백업합니다.
특정 시점 복원(PITR)은 복원 가능한 가장 빠른 시간(최대 35일)부터 가장 늦은 시간(사용량이 많은 데이터베이스의 경우 약 5분 전)까지 사용할 수 있습니다.
복원 프로세스에는 내부 로그 레코드를 적용하고 트랜잭션 복구를 위한 엔진을 시작하는 S3,에서 데이터를 가져오는 작업이 포함됩니다.
데이터베이스 인스턴스 가용성:
기본 구성에는 하나의 인스턴스가 포함됩니다. 실패하면 교체하는 데 10-15 분이 필요합니다.
대기 인스턴스를 추가하면 가용성이 향상됩니다. Aurora는 기본과 동기화를 유지합니다.
동일한 크기와 로드 용량을 유지하면서 대기 인스턴스로의 장애 조치가 몇 초 내에 발생합니다.
RPO의 0 및 RTO는 일반적으로 약 30초에 발생하여 다중 AZ 가용성 패턴을 달성합니다.

성능 탄력성

애플리케이션 요구 사항에 따라 성능이 변동될 수 있으며 이로 인해 리소스가 낭비될 수 있습니다.
오픈 소스 솔루션은 확장(하드웨어 업그레이드) 또는 확장(데이터베이스를 여러 조각으로 분할)을 제공하는데, 둘 다 일관성을 유지하기 어렵고 이웃이 시끄럽습니다.