Pagbabalik-tanaw sa AWS re:Invent

Nasdaq: Bumuo ng Resilient Infrastructure para sa Global Financial Services (HMC327)

Serye ng Pagbabalik-tanaw

Mga Tala ng Sesyon

NASDAQ's Cloud Journey at Resilient System Architecture

  • pagbuo ng nababanat, mataas na pagganap ng mga sistema para sa mga serbisyong pinansyal.
  • Pangkalahatang-ideya ng paglalakbay sa ulap ng NASDAQ, mga diskarte sa pagbawi ng sakuna, mga solusyon sa hybrid na imprastraktura, pagsasaalang-alang sa arkitektura, at pananaw sa hinaharap.
  • Background ni NASDAQ:
  • Pioneer sa mga electronic exchange, na tumatakbo sa mga 30 exchange sa buong mundo.
  • Nagbibigay ng software sa higit sa 130 marketplaces, kabilang ang trading, clearing, risk management, at anti-financial crime solutions.
  • Nag-aalok ng mga solusyon bilang tradisyonal na pinamamahalaang software, pinamamahalaang mga serbisyo, at SaaS.
  • Cloud Journey:
  • Nagsimula 15 taon na ang nakalipas, unti-unting nag-migrate ng mga kritikal na sistema tulad ng pagtutugma ng mga makina at sistema ng merkado.
  • Umunlad mula sa T+1 backups hanggang sa mahirap na real-time system, na nangangasiwa ng mga ultra-low latency na transaksyon.
  • Inilipat mula sa hindi gaanong kritikal patungo sa sistematikong mahahalagang sistema para sa pambansang ekonomiya.
  • Mga hamon:
  • Mga ultra-low latency na transaksyon na sinusukat sa microseconds at nanoseconds.
  • Mga partikular na kinakailangan sa pisikal na lokasyon dahil sa mga pagsasaalang-alang sa kalapitan at latency.

Disaster Recovery Strategies at Hybrid Infrastructure

Resiliency at Regulatory Requirements

  • High resiliency target na may inaasahan ng customer na 100% uptime.
  • Pangangasiwa sa regulasyon sa maraming hurisdiksyon sa buong mundo.
  • Disaster Recovery Spectrum:
  • Mula sa backup at restore hanggang sa multi-site, active-active, multi-region system.
  • Kahalagahan ng paghahanay sa RPO at RTO na mga target at pag-unawa sa mga tugon ng sistema sa mga sakuna.
  • Tumutok sa mga Kritikal na Sistema:
  • Nakasentro sa mga sistema na dapat mabuhay sa lahat ng oras at hindi maaaring bumaba.
  • Hybrid compute na may mga Outpost, mga domain ng pagkabigo, static na katatagan, at disconnected na operasyon.
  • Hybrid Compute na may mga Outpost:
  • Paggamit ng Mga Outpost upang maglagay ng mga workload sa mga data center habang pinamamahalaan ang mga ito gamit ang EC2 API at imprastraktura ng Amazon.
  • Direct Connect circuit para sa pagkakakonekta sa pagitan ng rehiyon at data center.
  • Paggamit ng mga EC2 server sa data center racks, pinamamahalaan bilang isang serbisyo.
  • Pagdaragdag ng mga ultra-low latency network interface card para sa mga market system.
  • Pagpapatupad ng mga bare metal na server at network para sa ganap na pisikal na magkahiwalay na data plane.
  • Mga hubad na server ng metal
  • pisikal, nag-iisang nangungupahan na server na nagbibigay sa isang kliyente ng direkta, eksklusibong pag-access sa lahat ng mapagkukunan ng hardware, hindi tulad ng mga virtual server na nagbabahagi ng hardware sa pamamagitan ng hypervisor. Nag-aalok ang setup na ito ng maximum na performance, pare-parehong I/O, at kumpletong kontrol sa software stack, na ginagawa itong perpekto para sa high-performance na computing, demanding na mga application tulad ng gaming o AI/ML, at mga workload na nangangailangan ng pisikal na paghihiwalay o mga partikular na configuration ng hardware.

Mga Domain ng Pagkabigo at Static Stability

Mga Domain ng Pagkabigo

  • Konsepto ng mga domain ng pagkabigo upang maunawaan ang ibinahaging kapalaran sa mga bahagi ng system.
  • Mga EC2 server na nagpapatakbo ng software na may maraming instance at hot spares (pre-provisioned EC2 instance) para sa redundancy.
  • AB mga pares ng bawat bahagi ng software, na tinitiyak na ang mga backup na bahagi ay hindi magkakasamang matatagpuan sa parehong pagkakataon.
  • Rack Level Failure Domains:
  • Pagsasaalang-alang ng mga potensyal na pagkabigo sa antas ng rack (hal., pagkawala ng kuryente).
  • mga pagkabigo sa antas ng rack: ang isang buong server rack ay napupunta offline dahil sa pagkawala ng kuryente, pagkabigo sa paglamig, pagkabigo sa switch ng network, o pisikal na pinsala, na nakakaapekto sa lahat ng mga server sa loob nito.
  • Maraming rack ang ginagamit, na may AB pares ng mga bahagi ng software na nakakalat sa iba't ibang rack upang maiwasan ang sabay-sabay na pagkawala ng parehong bahagi.
  • Mga Domain sa Pagkabigo sa Antas ng Site:
  • Maramihang mga pisikal na site para sa mga data center upang matiyak ang katatagan.
  • Pangunahing site sa New Jersey at pangalawang site sa Chicago para sa mga US market.
  • Static Stability:
  • Paggamit ng mga maiinit na ekstra (pre-provisioned EC2 instance) upang matiyak ang agarang pagkakaroon ng backup na mapagkukunan.
  • AB pares ng mga bahagi ng software na kumakalat sa mga rack at site upang mapanatili ang integridad ng system kung sakaling mabigo.
  • mainit na spare:
  • Pangunahing ipinapatupad ang mga pre-provisioned EC2 instance sa AWS sa pamamagitan ng feature na EC2 Auto Scaling warm pools. Binibigyang-daan ka ng functionality na ito na mapanatili ang isang pool ng mga pagkakataon na handang ilagay sa serbisyo kaagad kapag ang iyong application ay kailangang i-scale out.
  • Disaster Recovery (DR) Strategy: Ang mga warm pool ay isang mahalagang bahagi ng "warm standby" o "pilot light" na mga diskarte sa pagbawi ng kalamidad
  • Mas Mabilis na Pag-scale: Ang mga instance sa isang mainit na pool ay paunang sinimulan, ibig sabihin ay tumatakbo na ang mga proseso ng pagsisimula ng application at pagsasaayos ng oras.

Static Stability at Disconnected Operation

Static na Katatagan

  • Ang konsepto ng static na katatagan upang matiyak ang katatagan ng system sa panahon ng mga pagkagambala.
  • Paggamit ng mga maiinit na spares (pre-provisioned DC2 instance) upang maiwasan ang pagdepende sa EC2 control plane sa panahon ng pagkabigo.
  • Layunin na mapanatili ang functionality ng system nang walang mga pagbabago sa panahon ng pagkagambala, umaasa sa paunang na-configure na mga mapagkukunan.
  • Naka-disconnect na Operasyon:
  • Paghahanda para sa mga sitwasyon kung saan maaaring maputol ang koneksyon sa mga serbisyong AWS (hal., pagkasira ng optical cable).
  • Pagtitiyak na ang mga sistema ng merkado ay maaaring magpatuloy sa paggana nang hindi umaasa sa mga panlabas na serbisyo sa mga naturang kaganapan.
  • Paggamit ng mga maiinit na spare at paunang na-configure na mga mapagkukunan upang mapanatili ang functionality sa mga hindi nakakonektang sitwasyon.
  • Mga Operational Runbook:
  • Kahalagahan ng pagkakaroon ng mahusay na tinukoy na mga operational runbook para sa bawat antas ng mga domain ng pagkabigo.
  • Ang mga pamamaraan para sa pagtugon sa mga pagkabigo sa server, rack, at antas ng site ay dapat na choreographed at pamilyar sa mga tauhan ng pagpapatakbo.
  • Ang layunin ay magkaroon ng predictable at mahusay na pagsasanay na mga tugon sa mga sakuna, na pinapaliit ang mga sorpresa sa mga aktwal na kaganapan.

Nadiskonekta ang Operasyon at Pagsubok

Naputol ang Operasyon

  • Paghahanda para sa mga sitwasyon kung saan nawawala ang pagkakakonekta sa mga serbisyo ng AWS (hal., pagputol ng linya ng network).
  • Paggamit ng lokal na gateway para sa break glass access para pamahalaan ang mga system nang lokal nang hindi umaasa sa mga panlabas na serbisyo.
  • Kaalaman sa mga panloob na dependency at pagpapatakbo na maaaring mangailangan ng panlabas na koneksyon, na tinitiyak na ang mga ito ay natugunan o naiiwasan.
  • Mga Mode ng Pagkabigo sa Pagsubok:
  • Pagsasagawa ng masusing pagsubok sa pamamagitan ng pagdiskonekta sa mga outpost sa mahabang panahon upang obserbahan ang gawi ng system.
  • Pagtukoy at pagtugon sa mga operasyong maaaring mabigo sa panahon ng mga pagkawala (hal., SSL na mga pagsusuri, IAM na pakikipag-ugnayan).
  • Pagtitiyak na mananatiling naa-access ang lokal na gateway kahit na sa panahon ng mga isyu sa pag-link sa rehiyon o serbisyo.
  • Buod ng mga Istratehiya:
  • Paggamit ng mga outpost sa mga data center para sa mga hybrid na computer.
  • Pagsusuri ng mga domain ng pagkabigo upang maunawaan ang mga magkakaugnay na bahagi at ibinahaging kapalaran.
  • Disenyo at pagsubok para sa static na katatagan upang mapanatili ang functionality ng system nang walang pagbabago sa panahon ng pagkagambala.
  • Tumutok sa naputol na operasyon upang matiyak na ang mga system ay maaaring magpatuloy sa paggana nang lokal kung maputol sa mga serbisyong AWS.
  • Pagbibigay-diin sa maingat na pagpaplano, mahusay na tinukoy na mga runbook sa pagpapatakbo, at malawak na pagsubok upang makamit ang katatagan at maiwasan ang mga sorpresa sa panahon ng mga sakuna.
  • Basagin ang salamin
  • Ang pag-access ay isang hakbang sa seguridad na nagpapahintulot sa mga awtorisadong tauhan na i-bypass ang mga normal na kontrol sa pag-access at makakuha ng emergency na access sa mga kritikal na system, data, o mga function. Ang termino ay nagmula sa konsepto ng pagbasag ng salamin upang ma-access ang mga kagamitang pang-emergency tulad ng alarma sa sunog. Ito ay isang fail-safe na protocol na ginagamit kapag nabigo ang mga karaniwang pamamaraan dahil sa mga insidente tulad ng mga paglabag sa seguridad, mga malfunction ng system, o mga lockout ng password. Ang mga break glass na account ay paunang na-configure na may mataas na mga pribilehiyo ngunit pinananatiling ligtas at tulog hanggang sa magkaroon ng emergency, at ang paggamit ng mga ito ay dapat na mahigpit na subaybayan at idokumento.
  • Pang-emergency na pag-access: Kapag may nangyaring krisis at hindi available ang mga karaniwang paraan ng pag-access.
  • Mga kontrol sa pag-bypass: Ang mga account na ito ay idinisenyo upang iwasan ang normal na pagkakakilanlan at pamamahala sa pag-access (IAM).
  • Mataas na antas ng mga pribilehiyo: Ang mga account ay paunang na-configure na may mataas na mga pribilehiyo.
  • Mahigpit na pamamahala: Upang maiwasan ang maling paggamit, ang mga kredensyal ng basag na salamin ay pinamamahalaan nang may matinding pag-iingat.

Mga Direksyon at Pagpapahusay sa Hinaharap

Mga Dynamic na Deployment

  • Pagpaplano para sa higit pang mga dynamic na deployment na may mga setup na nakabatay sa panuntunan.
  • Paggamit ng mga pattern ng affinity at anti-affinity para balansehin ang performance at resiliency.
  • Ang mga anti-affinity pattern ay mga panuntunan sa cloud/virtualization (tulad ng Kubernetes, VMware, OpenStack) na pumipigil sa mga partikular na workload (VMs, Pods) na tumakbo nang magkasama sa parehong pisikal na host o sa parehong domain ng failure, na tinitiyak ang mataas na availability, fault tolerance, at load balancing sa pamamagitan ng pagpapakalat ng mga ito, contrasting with affinity na sumusubok na mag-colocate ng mga bagay.
  • Layunin na sukatin ang mga system nang walang downtime habang lumilipat ang mga merkado sa pampublikong cloud.
  • Eksperimento sa Advanced na Hardware:
  • Mga positibong karanasan sa Graviton 4, pakikipagtulungan sa Amazon para sa mga susunod na henerasyong CPU.
  • Pagsubok ng mga ultra-low latency network card para sa Graviton at iba pang mga advancement.
  • Pag-explore ng pinabilis na pag-compute gamit ang mga FPGA at GPU para sa real-time na pagsusuri sa panganib.
  • Ang FPGA (Field-Programmable Gate Array) ay isang reconfigurable integrated circuit na maaaring i-program para magsagawa ng malawak na hanay ng mga digital logic function pagkatapos ng pagmamanupaktura.
  • Pagpapalawak ng Mga Kakayahang Outpost:
  • Interes sa pagdadala ng mas advanced na mga bahagi (custom na silicon, FPGA, GPU) sa mga outpost.
  • Pagbebenta ng mga system sa mga third party, na naglalayong mag-alok ng higit pang functionality at serbisyo.
  • Maingat na Pagsasama ng Serbisyo:
  • Maingat na diskarte sa pagdaragdag ng higit pang mga serbisyo sa mga outpost, pagsasagawa ng malalim na pagsisid sa mga service team.
  • Tumutok sa pag-unawa sa mga mode ng pagkabigo at pagtiyak ng mataas na availability at functionality ng serbisyo.
  • Konklusyon:
  • Patuloy na pagsisikap na pahusayin ang katatagan ng system, performance, at availability.
  • Pagbibigay-diin sa masusing pagpaplano, pagsubok, at pakikipagtulungan sa AWS upang makamit ang mga layunin sa hinaharap.
  • Pagpapahalaga para sa pakikipag-ugnayan at paghihikayat ng madla na punan ang form para sa karagdagang impormasyon.

AWS Mga Outpost sa loob ng isang Nasdaq data center para suportahan ang mga ultra-low latency trading operations. Ang

pangunahing mga bahagi at ang kanilang mga pag-andar ay

  • AWS Cloud at Rehiyon: Ang karaniwang AWS na kapaligiran na nagbibigay ng mga serbisyo sa maramihang, nakahiwalay na Availability Zone (AZ).
  • AWS Direct Connect: Isang nakatuong pribadong koneksyon sa network na nagli-link sa Nasdaq data center sa pangunahing rehiyon ng AWS, na ginagamit para sa control plane at service link connectivity upang pamahalaan ang Outposts.
  • Nasdaq Data Center (On-premises): Ang pisikal na lokasyon na nagho-host ng AWS Outposts, na nagbibigay-daan sa mga workload na tumakbo nang lokal para sa mababang latency at pagsunod sa regulasyon.
  • AWS Mga Outpost: Na-deploy sa loob ng Nasdaq data center, ang mga ito ay ganap na pinamamahalaan AWS compute at storage capacities na nagpapalawak ng AWS na imprastraktura, mga serbisyo, at mga API sa nasa nasasakupan na kapaligiran.
  • Amazon EC2 Instances na may Nitro at ULL NICs: Ang mga computer instances na nagpapatakbo ng mga trading application. Ginagamit nila ang AWS Nitro System para sa pinahusay na performance at seguridad at gumagamit ng Ultra-Low Latency (ULL) Network Interface Cards (NICs) upang matugunan ang mahigpit na latency na kinakailangan ng financial trading.
  • Local Gateway: Ang bahaging ito ng Outpost ay nagkokonekta sa nasa nasasakupan na network sa mga instance sa loob ng VPC subnet ng Outpost, na nagpapadali sa komunikasyon sa kasalukuyang imprastraktura ng Nasdaq.

Mga Network ng Nasdaq

  • ULL Trading Network: Isang pisikal na hiwalay na network na idinisenyo para sa napakababang latency, direktang nakikipag-interface sa mga ULL NIC sa mga EC2 na pagkakataon para sa mabilis na pagproseso ng transaksyon.