AWS - วิธีจัดการกับ "เวลาไป-กลับ" ทั่วโลก

สวัสดีชาว serverfault

ลองนึกภาพบริษัท "Software as a Service" ทั่วๆ ไปที่ให้บริการที่ทำงานบน AWS (นี่เราเอง) ไม่มีวิทยาศาสตร์จรวดเข้ามาเกี่ยวข้อง เว็บแอปพลิเคชันมาตรฐานทำงานตามปกติ และแอปสมาร์ทโฟนสำหรับผู้ใช้ปลายทาง เนื่องจากลูกค้ามาจาก ยุโรปโดยธรรมชาติแล้ว ภูมิภาค AWS eu-central-1 จะมีทุกอย่างสำหรับผู้เช่าหลายราย

ตอนนี้ฝ่ายขายจัดการเพื่อชนะใจลูกค้า ออสเตรเลีย - จนถึงขณะนี้ยังดีอยู่ เนื่องจากเว็บแอปพลิเคชันสามารถจัดการเขตเวลา สกุลเงิน และโลแคลต่างๆ ได้แล้ว แต่: ออสเตรเลียอยู่ไกลที่สุดเท่าที่คุณจะหาได้จากยุโรป (อย่างน้อยก็บนโลก) และตอนนี้มีเวลาเดินทางไปกลับค่อนข้างมาก ตามคำขอ เราเห็นประมาณ 300ms - 400ms พิเศษต่อทิศทาง (แก้ไข: สิ่งนี้ผิดเมื่อพูดถึง RTT ตามที่ชี้ให้เห็นในคำชม เราจะเห็น 2x400ms = 800ms พิเศษสำหรับอันแรก HTTPS ขอ).

สำหรับเว็บแอปพลิเคชันที่กล่าวถึง ซึ่งลูกค้าใช้เพื่อวัตถุประสงค์ในการจัดการ ถือว่าใช้ได้ทั้งหมดHTML ที่แสดงผลจะมีขึ้นในภายหลัง แต่ต้องขอบคุณ CDN (CloudFront) สินทรัพย์จึงไม่ใช่ปัญหา

แต่แอปพลิเคชันสมาร์ทโฟนของผู้ใช้ปลายทางซึ่งส่งคำขอ JSON น้อยลงแต่มีจำนวนมากขึ้นจะได้รับผลกระทบ มีความรู้สึกที่ขอบของ "OK-ish" แต่ก็ไม่เร็วอย่างแน่นอน

ตอนนี้คำถามคือ: จะปรับปรุงการกำหนดเวลาจากมุมมองของผู้ใช้ได้อย่างไร เราได้คิดเกี่ยวกับตัวเลือกบางอย่างที่นี่แล้ว:

1. คัดลอกซอฟต์แวร์ทั้งหมดและโฮสต์ไว้ใน AWS ap-southeast-2 ด้วย

   ข้อดี: ประสิทธิภาพที่ยอดเยี่ยม ติดตั้งง่าย CI/CD จะช่วยให้ปรับใช้รหัสเดียวกันพร้อมกันใน EU และ AU

   ข้อเสีย: เราต้องบำรุงรักษาและจ่ายเงินสำหรับชุดโครงสร้างพื้นฐานที่เหมือนกันสองชุด ไม่สามารถแบ่งปันข้อมูลได้ง่าย มีความซ้ำซ้อนมากมายในทุกเงื่อนไข

2. ย้ายเฉพาะอินสแตนซ์การคำนวณไปที่ AWS ap-southeast-2

   ไม่ จะไม่ทำงานเป็นฐานข้อมูลหรือข้อความค้นหา redis จะได้รับผลกระทบจากเวลาไปกลับมากยิ่งขึ้น

3. มีแบบจำลองแบบอ่านอย่างเดียวใน AWS ap-southeast-2 และเขียนใน eu-central-1

   ดีกว่าเป็นตัวเลือกที่ 2 แต่เพิ่มความซับซ้อนในโค้ดและจำนวนการเขียนไม่มากขนาดนั้น

4. หมุนโหลดบาลานเซอร์ใน AWS ap-southeast-2 และเพียร์เชื่อมต่อ VPC

   แนวคิด: ผู้ใช้เชื่อมต่อกับจุดสิ้นสุดของ AU และทราฟฟิกกำลังดำเนินการผ่านการเชื่อมต่อจำนวนมากไปยังอินสแตนซ์ของสหภาพยุโรป อย่างไรก็ตาม เราจะไม่ลดระยะทางลงอย่างแน่นอน และเราไม่แน่ใจเกี่ยวกับการปรับปรุงที่อาจเกิดขึ้น (ถ้ามี?)

มีใครเคยประสบปัญหาที่คล้ายกันและยินดีที่จะแบ่งปันข้อมูลเชิงลึกบ้างไหม?

อัปเดต: ดูเหมือนว่าคำขอ HTTPS แรกเท่านั้นที่ดูเหมือนจะช้ามาก ในขณะที่ค้นหาตัวเลือก AWS Load Balancer ฉันก็สังเกตเห็นเช่นกัน AWS Global Accelerator อาจช่วยได้ เราจึงทำการทดสอบบางอย่าง

จากระบบท้องถิ่น (ในสหภาพยุโรป):

curl -w "dns_ resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
ความละเอียด DNS: 0,019074, tcp_established: 0,041330, ssl_handshake_done: 0,081763, TTFB: 0,103270
ความละเอียด DNS: 0,000071, tcp_established: 0,000075, ssl_handshake_done: 0,000075, TTFB: 0,017285

จาก AU (อินสแตนซ์ EC2):

curl -w "dns_ resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas.example .com/ping" "https://saas.example.com/ping"
ความละเอียด DNS: 0,004180, tcp_established: 0,288959, ssl_handshake_done: 0,867298, TTFB: 1,161823
ความละเอียด DNS: 0,000030, tcp_established: 0,000032, ssl_handshake_done: 0,000033, TTFB: 0,296621

จาก AU ถึง AWS Global Accelerator (อินสแตนซ์ EC2):

curl -w "dns_ resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}\n" -o /dev/null -s "https://saas-ด้วย -global-accelerator.example.com/ping" "https://saas-with-global-accelerator.example.com/ping"
ความละเอียด DNS: 0,004176, tcp_established: 0,004913, ssl_handshake_done: 0,869347, TTFB: 1,163484
ความละเอียด DNS: 0,000025, tcp_established: 0,000027, ssl_handshake_done: 0,000028, TTFB: 0,294524

โดยสรุป: ดูเหมือนว่า TLS handshake จะทำให้เกิดความล่าช้าเริ่มต้นที่ใหญ่ที่สุด หากสามารถนำกลับมาใช้ใหม่ได้ เวลาพิเศษสำหรับ AU ถึง EU ดูเหมือน "แค่" ~277ms (0,294524s - 0,017285s) สำหรับ Time To First Byte

ทักทาย!