เหตุขัดข้องของศูนย์ข้อมูล AWS ใน Northern Virginia - แก้ไขแล้ว

 (cnbc.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • AWS รายงานปัญหาในการดำเนินงานตั้งแต่คืนวันพฤหัสบดี โดยเหตุขัดข้องที่เชื่อมโยงกับความร้อนสูงเกินไปในศูนย์ข้อมูลของรีเจียน US-East-1 ใน Northern Virginia ได้ส่งผลกระทบต่อแพลตฟอร์มซื้อขายอย่าง Coinbase และ FanDuel
  • AWS ระบุในอัปเดตเมื่อเวลา 15:29 น. (ET) ของวันศุกร์ว่า คาดว่ายังต้องใช้เวลาอีกหลายชั่วโมงกว่าจะกู้คืนได้ทั้งหมด และการกู้คืนเป็นไปช้ากว่าที่ประเมินไว้ก่อนหน้านี้
  • AWS อธิบายว่าปัญหาเกิดขึ้นใน Availability Zone เดียวของรีเจียนดังกล่าว และกำลังนำกำลังการทำความเย็นเพิ่มเติมขึ้นมาใช้งานเพื่อกู้คืนฮาร์ดแวร์ที่เหลือ
  • FanDuel ระบุว่าหลังจากตรวจสอบปัญหาทางเทคนิคที่ทำให้ผู้ใช้ไม่สามารถเข้าถึงแพลตฟอร์มได้ ก็พบว่าเชื่อมโยงกับเหตุขัดข้องของ AWS ในวงกว้าง ขณะที่ผู้ใช้ออกมาร้องเรียนว่าไม่สามารถถอนเงินสดออกได้จนทำให้เกิดการขาดทุนจากการเดิมพัน
  • Coinbase ระบุว่าเหตุขัดข้องในหลายโซนของ AWS ทำให้เกิดการหยุดให้บริการเป็นเวลานานของบริการซื้อขายหลัก และได้โพสต์ว่าปัญหาสำคัญได้รับการแก้ไขทั้งหมดแล้ว

ความคืบหน้าในการกู้คืน

  • AWS ระบุในอัปเดตเมื่อเวลา 9:51 น. (ET) ของวันศุกร์ว่า “เรากำลังทำงานอย่างเต็มที่เพื่อนำกำลังการทำความเย็นเพิ่มเติมขึ้นมาใช้งาน ซึ่งจะช่วยให้เรากู้คืนฮาร์ดแวร์ที่เหลือในพื้นที่ที่ได้รับผลกระทบได้”
  • AWS กำลังแก้ไขเหตุขัดข้องของ EC2 instances ที่ให้ความจุเซิร์ฟเวอร์เสมือน
  • แดชบอร์ดสุขภาพของ AWS โพสต์ครั้งแรกเมื่อเวลา 20:25 น. (ET) ของวันพฤหัสบดีว่า “กำลังตรวจสอบเหตุขัดข้องของอินสแตนซ์”
  • AWS ไม่มีแถลงการณ์เพิ่มเติม

ผลกระทบแยกตามบริการ

  • FanDuel ระบุบน X เมื่อเวลา 21:00 น. (ET) ของวันพฤหัสบดีว่าได้รับทราบถึงปัญหาทางเทคนิคในปัจจุบันที่ทำให้ผู้ใช้ไม่สามารถเข้าถึงแพลตฟอร์มได้ และกำลังตรวจสอบอยู่
  • FanDuel อัปเดตในอีกประมาณ 2 ชั่วโมงถัดมาว่า ปัญหาดังกล่าวเชื่อมโยงกับเหตุขัดข้องของ AWS ในวงกว้าง
  • ผู้ใช้ FanDuel ร้องเรียนว่าไม่สามารถถอนเงินสดบนแพลตฟอร์มได้จนทำให้เกิดการขาดทุนจากการเดิมพัน
  • Coinbase ก็โพสต์บน X ในวันศุกร์เช่นกันว่า เหตุขัดข้องในหลายโซนของ AWS ทำให้เกิด “การหยุดให้บริการเป็นเวลานานของบริการซื้อขายหลัก”
  • Coinbase ระบุในโพสต์ดังกล่าวว่าปัญหาสำคัญได้รับการแก้ไขทั้งหมดแล้ว

บริบทของตลาดคลาวด์

  • AWS ครองสัดส่วนราว หนึ่งในสาม ของตลาดเทคโนโลยีโครงสร้างพื้นฐานคลาวด์
  • AWS ให้บริการแก่บริษัทหลายล้านแห่ง

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Hacker News

  • AWS US-East 1 ยังคงเป็นส้นอคิลลีสของอินเทอร์เน็ต
    ถึงจะออกแบบให้ครอบคลุมหลายรีเจียนและหลาย Availability Zone ได้ แต่ AWS ก็เกิดเหตุที่ปัญหาใน US-East 1 ส่งผลวงกว้างซ้ำแล้วซ้ำอีก ทำให้มันไม่ได้มีความซ้ำซ้อนและความทนทานสูงอย่างที่ AWS ชวนให้คิด

    • ความคิดที่ว่าบริการของ AWS แยกขาดกันตามรีเจียนอย่างสมบูรณ์ นั้นใกล้เคียงกับเป็นเรื่องเล่ามาโดยตลอด
      บริการด้านตัวตนและการเข้าถึงทั้งหมดของ public cloud นอกจีน หรือสิ่งที่พนักงานเรียกว่า “IAM สำหรับ aws partition” ถูกศูนย์รวมอยู่ที่ us-east-1 การจะมองเห็นบัญชี การเรียกเก็บเงิน และสิทธิ์ต่าง ๆ ให้สอดคล้องกัน ก็แทบจำเป็นต้องมีการรวมศูนย์แบบนี้
      ตัว IAM เองก็ไม่ได้เป็นซอฟต์แวร์สแตกที่เป็นอิสระโดยสมบูรณ์ และพึ่งพาบริการบางตัวอย่าง DynamoDB ขณะที่บริการเหล่านั้นก็พึ่งพา IAM แบบวนกลับอีกที
      ระหว่างที่ us-east-1 ล่ม บางครั้งยังใช้โทเคนหรือเซสชันเดิมจากรีเจียนอื่นต่อได้ แต่ไม่สามารถออกโทเคนใหม่ได้ สมัยก่อนตอนทำงานอยู่ยังจำได้เลยว่าเคยบอกคน on-call ว่าอย่าปิด SSH session หรือแท็บเบราว์เซอร์ AWS console เพราะอาจถูกล็อกออกจนกว่าปัญหาจะจบ
    • ทุกคนพูดแบบนั้น แต่รอบนี้มันเป็นปัญหาใน Availability Zone เดียว
      ช่วง 3 ปีที่ผ่านมา ผมรันสตาร์ตอัปแทบทั้งหมดอยู่บน use-1 และเคยเจอรีเจียนล่มแค่ครั้งเดียว แถมยังเป็นการล่มบางส่วนจน instance ส่วนใหญ่ไม่ได้รับผลกระทบ
      พูดตรง ๆ ข้อดีก็คือลูกค้าของลูกค้าเราก็อยู่บน use-1 กันหมด ดังนั้นความเสียหายมันจึงมีความสัมพันธ์กับลูกค้าอยู่แล้ว
    • คนใช้มันเยอะเกินไป
      ในดินแดนมหัศจรรย์ในอุดมคติ โหลดจะถูกกระจายเท่า ๆ กันไปยังผู้ให้บริการคลาวด์หลายเจ้า และจะไม่มี จุดล้มเหลวเพียงจุดเดียว
      ผมก็สมหวังกับแฟนคนแรก ฝาแฝดก็พูดได้ทั้งอังกฤษและเกาหลี และทุกคนก็รู้ว่าเวลา deploy บริการขนาดใหญ่ไม่ควรพึ่ง AWS เจ้าเดียว
      ค่ารักษาพยาบาลในสหรัฐก็จ่ายไหว แต่โลกจริงก็ยังคงเป็นเหมือนเดิม และ AWS US-East 1 เพียงแห่งเดียวก็ยังทำให้อินเทอร์เน็ตส่วนใหญ่ล้มได้
    • ถ้าจะใช้หลายรีเจียนและหลาย Availability Zone เพื่อความทนทาน ก็เตรียมจ่าย ภาษีด้านความจุ ได้เลย
      ถ้ามี 2 รีเจียนก็ต้องมีความจุ 2 เท่า ถ้ามี 3 รีเจียนก็ต้องมีความจุ 1.5 เท่า และในสถาปัตยกรรมหลายรีเจียน เครื่องเหล่านั้นต้องรันอยู่แล้วก่อนเกิดเหตุ อย่าคาดหวังว่าจะค่อยเปิด instance หรือไปหา capacity เอาตอนระบบล่ม และต้องรับความซับซ้อนเพิ่มเติมของการโฮสต์หลายรีเจียนด้วย
    • เท่าที่ได้ยินมา เหมือน us-east-2 ก็โดนผลต่อเนื่องเพราะคนย้ายหนีจาก us-east-1
      มันตลกนิด ๆ ที่ทั้งที่สถาปัตยกรรมหลายรีเจียน/หลาย Availability Zone ดูเป็นแค่ภาพลวงตาอย่างโจ่งแจ้งขนาดนี้ แต่ทุกคนก็ยังเชื่อมันเหมือนเป็นหลักศรัทธาของศาสนาคลาวด์

  • การเดิมพันแบบนี้อันตราย เพราะคนอย่างพนักงานที่ทำให้ AWS ล่มได้ก็สามารถ เดิมพัน ได้
    การเดิมพันแบบนี้ไม่ได้ไร้พิษภัยอย่างที่เห็น เพราะหลายครั้งคนที่ลงเดิมพันสามารถมีอิทธิพลต่อผลลัพธ์หรือเปลี่ยนผลลัพธ์ได้

    • โชคดีจริง ๆ ที่บริษัท Big Tech จ้าง วิศวกรที่มีจริยธรรม ไม่ใช่คนที่สนใจแต่เงินหรือสถานะทางสังคม
    • แต่ถ้าเว็บเดิมพันทั้งหมดรันอยู่บน US-East1 ก็จบเหมือนกัน
    • นึกภาพได้เลยว่า AWS ล่มจนเว็บเดิมพันเองก็ปิดไปด้วย
      โดยรวมแล้วผมเห็นด้วยกับข้อโต้แย้งที่ว่าตลาดพยากรณ์แบบนี้อาจจูงใจให้เกิด insider trading และสถานการณ์ด้านลบได้ เพราะมันสร้างแรงจูงใจให้คนหากำไรจากเหตุการณ์แบบนั้น

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

    • ผมเคยทำงานในดาต้าเซ็นเตอร์ที่มีเครื่องทำความเย็นสำรองหลายตัวบนหลังคา และมีอุปกรณ์ทำความเย็นสำรองหลายชุดในแต่ละชั้น แต่พอ ท่อน้ำจ่าย พังไม่ว่าทางไหน ระบบทำความเย็นทั้งอาคารก็หยุดพร้อมกัน
      เขาไม่ได้บอกรายละเอียดสาเหตุ แต่ดูเหมือนว่าท่อระหว่างแต่ละชั้นกับหลังคาไม่ได้ทำ redundancy ไว้ และใช้เวลาเกือบ 24 ชั่วโมงกว่าจะซ่อมเสร็จ
    • แทบจะแน่นอนว่าเป็นปัญหาอุปกรณ์เสีย
      การระบายความร้อนของดาต้าเซ็นเตอร์ก็เหมือนอย่างอื่นทั้งหมด คือมีทั้ง overprovision และ underprovision อยู่พร้อมกัน
      อุปกรณ์แลกเปลี่ยนความร้อนขนาดใหญ่จะเป็นแบบ N+1 และในไซต์โหลดขนาดเล็กที่สำคัญมากก็อาจเป็น 2N/3N จึงถือว่า overprovision เพราะต้องหยุดลงเพื่อตรวจเช็กตามรอบ มีอัตราเสียสูงกว่าชิ้นส่วนดาต้าเซ็นเตอร์แบบดั้งเดิม และต้องพึ่งการซ่อมเครื่องจักรที่ต้องใช้ช่างเฉพาะทางกับเวลาจัดหาอะไหล่นาน
      ในไซต์ขนาดใหญ่ ถ้า N ใหญ่ขึ้น ก็ไม่ใช่เรื่องแปลกที่ระบบทำความเย็นจะเป็น N+3 หรือมากกว่านั้น มักจะมีบางอย่างอยู่ระหว่างการซ่อมบำรุงเสมอ หรือมีเครื่องที่กำลังรออะไหล่เพราะต้องสั่งทำใหม่ทั้งชิ้นจากแบบของชิ้นส่วนที่เลิกผลิตไปแล้ว ซึ่งยังถูกกว่าการเปลี่ยนอุปกรณ์ทั้งชุด
      ในอีกด้านหนึ่ง ถ้ากำลังประมวลผลทั้งหมดของศูนย์พุ่งจากการใช้ไฟเฉลี่ยไปเป็น 100% ทันที ก็จะเกินขีดความสามารถของระบบทำความเย็น จึงถือว่า underprovision ด้วย เส้นทางด้านไฟฟ้าและระบบอื่น ๆ ก็มักถูกใช้เกินเช่นกัน ธรรมชาติของอุตสาหกรรมนี้ก็คล้ายการขายเกินอยู่แล้ว
      โดยปกติแล้วมันไม่ใช่ปัญหาใหญ่ ภาระงานคอมพิวต์แทบไม่เคยพุ่งถึง 100% ของความจุทั้งหมด และถึงจะพุ่งก็ไม่นาน อีกทั้งไม่มีใครสร้างไซต์โดยวางความจุไฟฟ้าหรือความเย็นไว้แบบเฉียดฉิวขนาดนั้น
      ปัญหาจะเกิดเมื่อหลายเหตุการณ์มาซ้อนกัน ระบบทำความเย็นอาจถูกออกแบบให้รองรับ 200% ของโหลดเฉลี่ย เพื่อเผื่อทั้งงานซ่อมและเหตุขัดข้องต่าง ๆ
      วันอังคารช่างซ่อมเข้ามาดูอุปกรณ์ตัวหนึ่งแล้วพบว่าตลับลูกปืนเสีย ต้องเอาอะไหล่มาจากต่างรัฐ และเพื่อไม่เสี่ยงทำให้ชุดพัดลมพังไปด้วย จึงปิดอุปกรณ์นั้นทิ้งไว้ทั้งคืน
      เครื่องทำความเย็นข้าง ๆ อีกสองตัวจึงทำงานหนักขึ้นเล็กน้อย แล้วหนึ่งในนั้นอาจมีมอเตอร์ไม่สมดุลนิดหน่อย หรือมีฟิวส์ที่เริ่มหลวมจนร้อนขึ้น ชิ้นส่วนที่เคยทนมาได้หลายปีจึงพังเพราะอัตราการใช้งานที่เพิ่มขึ้น
      ตอนนี้ไซต์แบบ N+2 เสียไปสองเครื่อง แต่เพราะออกแบบตามโหลดเฉลี่ย 200% จึงยังไม่วิกฤต
      ถ้าเครื่องที่สามฝั่งตรงข้ามกับเครื่องแรกเกิดเผยอาการเสียภายใต้โหลดที่สูงขึ้นอีก ตอนนี้ไซต์ N+2 ก็เสียไปสามเครื่อง ถึงอย่างนั้นด้วยการออกแบบที่ 200% ของโหลดเฉลี่ย มันก็ยังไม่ใช่หายนะใหญ่
      แต่ตอนนั้นเป็นตี 4 เจ้าหน้าที่ปฏิบัติการในไซต์แก้ปัญหานี้เองไม่ได้ ผู้รับเหมาจะตื่น 7 โมงและมาถึง 9 โมง ระหว่างนั้นโหลดก็เริ่มสูงขึ้น
      เรื่องแบบนี้เกิดขึ้นทุกวันในดาต้าเซ็นเตอร์ที่ไหนสักแห่งในสหรัฐ และน่าจะเกิดกับทุกดาต้าเซ็นเตอร์ปีละครั้งประมาณนั้น
      สิ่งที่ทำให้มันกลายเป็นข่าวคือเหตุการณ์ถัดไปที่เข้ามาสมทบ ลูกค้ารายใหญ่รายหนึ่งเห็นว่านี่เป็นเวลาที่เหมาะจะเริ่มงาน batch ขนาดใหญ่ บาง fintech รันโมเดลใหญ่ก่อนตลาดเปิด หรือบริษัทน้ำมันกำลังรันวิเคราะห์ด่วนของแหล่งใหม่
      มีการเปิด VM ใหม่ 10,000 ตัว ปกติคงไม่เป็นไรเพราะยังมีความจุเหลือ
      แต่ระบบทำความเย็นถูกวางแผนไว้แค่ 200% ของความเย็นเฉลี่ย และโหนดชุดนี้ไม่ใช่โหนดที่ยุ่งพอประมาณ แต่เป็นโหนดที่รันงานคำนวณเชิงตัวเลขเข้มข้นแบบปรับแต่งแล้ว ดึงไฟสูงสุดและปล่อยความร้อนทิ้งสูงสุด
      ไม่ใช่แค่ภาระงานตามจำนวนเครื่องทั้งหมดเท่านั้น แต่ผลกระทบด้านความร้อนเฉลี่ยก็สูงขึ้นด้วย จากนั้นความล้มเหลวแบบต่อเนื่องก็เริ่มขึ้น และระบบทำความเย็นก็กลายเป็น N-4
      พัดลมของเซิร์ฟเวอร์เริ่มหมุนเร็วขึ้น กินไฟมากขึ้น ระบบทำความเย็นก็กลายเป็น N-5 และสัญญาณเตือนก็ดังไปทั่ว
      ระบบป้องกันของเครื่องทำความเย็นเริ่มตัดการทำงานทีละตัวเพราะโหลดและแรงดันสารทำความเย็นที่สูงขึ้น ทำให้ระบบทำความเย็นกลายเป็น N-6, N-7 และสุดท้ายเหลือ 0
    • มันคือการที่ วงจรทำความเย็น วงหนึ่งของดาต้าเซ็นเตอร์เสีย
    • หัวข้อใกล้เคียงกันที่น่าฟังอยู่ที่นี่: https://signalsandthreads.com/the-thermodynamics-of-trading/

  • ปีนี้ใน EU สงสัยว่า Hetzner uptime ดีกว่า AWS หรือเปล่า

    • ไม่เข้าใจว่าทำไม OVH ถึงไม่ค่อยได้รับความรัก
      ผมรู้สึกว่า UI ของ Hetzner ชวนสับสนเกินไปจนจัดการยาก

  • โพสต์ที่เกี่ยวข้อง: AWS EC2 outage in use1-az4 (us-east-1)
    https://news.ycombinator.com/item?id=48057294

  • East 1 ตลอดเลย พูดจริง ๆ เลิกมุกก่อน ผมไม่เข้าใจว่าทำไม east-1 ถึงล่มบ่อยกว่ารีเจียนอื่นขนาดนี้
    ในเชิงสถาปัตยกรรมมันก็น่าจะคล้ายกับรีเจียนอื่นพอสมควร

    • ผมเดาว่า east one เป็น ดาต้าเซ็นเตอร์หลัก และเป็นที่เก่าแก่ที่สุด
      มันน่าจะมีโหลดมากกว่ารีเจียนอื่น และตอนสร้างใหม่ ๆ ทีมก็คงมีประสบการณ์น้อยกว่า จึงมีทั้ง technical debt และ debt ด้านสถาปัตยกรรม/วิศวกรรมมากกว่า
      เท่าที่จำได้ ก็มีบริการบางตัวที่พึ่ง east-1 เป็นจุดล้มเหลวเดียว เช่น IAM หรือการตั้งค่า S3 บางอย่าง
    • มันเป็นระบบรีเจียนที่เก่าแก่ที่สุด และมี บทบาทสำคัญเชิงโครงสร้าง เช่นการมี internal CA อยู่ที่นั่น
    • ตลกดีที่มีบทความนี้อยู่

      AWS in 2025: The Stuff You Think You Know That’s Now Wrong
      us-east-1 is no longer a merrily burning dumpster fire of sadness and regret.
      — https://www.lastweekinaws.com/blog/aws-in-2025-the-stuff-you...
      นอกนั้นเป็นบทความที่ดี

  • Coinbase บอกว่าหลาย Availability Zone ล่ม แต่ประกาศของ AWS ระบุว่าได้รับผลกระทบแค่ Availability Zone เดียว
    สงสัยว่ามีใครรู้รายละเอียดมากกว่านี้ไหม

    • Coinbase ยืนยันบน X ว่า exchange ของตัวเองรันอยู่แค่ Availability Zone เดียวเพราะเหตุผลด้าน latency: https://x.com/i/status/2052855725857329254
    • อย่าไปเชื่อว่าบริษัทคริปโตจะซื่อสัตย์
    • หาแหล่งทางการไม่เจอ แต่ดูเหมือนว่า blast radius จะไม่ได้จำกัดอยู่แค่ Availability Zone นั้น
      ผมรันระบบอยู่ใน us-east-1 และระหว่างเหตุการณ์ก็เห็นปัญหาการเชื่อมต่อสะดุดเป็นช่วง ๆ ที่อธิบายยากและไม่เคยเจอมาก่อน แม้อยู่นอก az4
    • เวลาที่ East-1 ล่ม มันมักกระทบ Availability Zone อื่นบางส่วนเสมอ เพราะจะมีบางอย่างที่พึ่ง East-1 อยู่ตลอด
    • ทั้งเย็นผมนั่งดู กราฟ SLI ว่าจะกลายเป็นรีเจียนล่มทั้งก้อนหรือเปล่า แต่สุดท้ายก็ไม่ถึงขั้นนั้น
      มีแค่ EBS volume ของ Availability Zone เดียวในบาง environment ที่แย่ลงเล็กน้อย และชัดเจนว่าเป็นปัญหาของ Availability Zone เดียว (use-az4)

  • ก่อนหน้านี้เคยเห็นประโยคว่า “ถ้าเป็นเพื่อนกันจริง จะไม่ปล่อยให้เพื่อนไปใช้ USE1” แล้วพอมีข้อความใน Slack ว่า USE1 กับของทั้งหมดที่ deploy ไว้บนนั้นพังหมด ผมก็นึกถึงคำนั้นทันที

  • ในคอมเมนต์ที่นี่มีเรื่องเดิม ๆ เยอะมากว่า us-east-1 ถูกรวมศูนย์ เป็น จุดล้มเหลวเดียว ของ AWS ควรแก้ไข และไม่ควรเอาของไปลงที่นั่น
    แต่เหตุการณ์นี้คือปัญหาของดาต้าเซ็นเตอร์เพียงแห่งเดียวในหนึ่งโซนของรีเจียนแบบหลายโซน
    แน่นอนว่า IAM/R53 และอื่น ๆ ถูกรวมศูนย์อยู่ที่นั่น และการกระจายบริการเหล่านั้นให้เป็นแบบข้ามรีเจียน/ไม่รวมศูนย์ก็เป็นเรื่องดี แต่ตัว us-east-1 เองเป็นรีเจียนหลายโซนที่มีอยู่แล้ว 6 โซน และจะมีโซนที่ 7 ในปี 2026 อีกทั้งภายในโซนเดียวก็ยังมีหลายดาต้าเซ็นเตอร์
    เท่าที่จำได้ เวลาบริการ global อย่าง IAM ล่ม สาเหตุมักเป็นบั๊กด้าน implementation หรือ dependency มากกว่าจะเป็นเรื่องว่า “ถ้าเป็น cross-region คงไม่ตาย”
    ครั้งนี้ไม่ใช่เหตุขัดข้องของบริการ global ของ AWS สิ่งที่ดูเหมือนโดนหนักกว่าหน่อยมีแค่ MSK ซึ่งน่าจะเป็นปัญหาฝั่ง Kafka มากกว่าจะเกี่ยวกับ AWS เอง

  • สงสัยว่าทำไมไม่สร้างอะไรแบบนี้ใกล้ทะเล เหมือนโรงไฟฟ้านิวเคลียร์ที่ต้องใช้ ความสามารถในการระบายความร้อน สูง ๆ ไม่ใช่หรือ
    น่าจะเอาความร้อนออกด้วยการหมุนเวียน 2 วงจรผ่าน heat exchanger ได้

    • เหตุผลที่ Ashburn VA กลายเป็นฮับดาต้าเซ็นเตอร์ก็เพราะที่นั่นมีจุดแลกเปลี่ยนอินเทอร์เน็ตนอกภาครัฐแห่งแรกของโลกอยู่ (https://en.wikipedia.org/wiki/MAE-East)
      ในยุค 1990 ทราฟฟิกอินเทอร์เน็ตของโลกเกือบครึ่งหนึ่งผ่าน MAE-East และผลลัพธ์ก็คือ AWS ตั้งรีเจียนแรกไว้ที่นั่น us-east-1 ออกมาก่อน eu-west-1 อยู่ 2 ปี และก่อน us-west-1 อยู่ 3 ปี
      เมื่อมีทั้งคนที่รู้วิธีสร้างดาต้าเซ็นเตอร์และผู้ขายที่รู้วิธีซัพพลายมากขึ้น Dulles Corridor ก็กลายเป็นฮับหลักของดาต้าเซ็นเตอร์หลายบริษัท
      สำหรับ AWS นั้น us-east-1 คือรีเจียนแรก จึงมีความซับซ้อน ความประหลาด และความพึ่งพาจาก control plane ของบริการ AWS อื่นจำนวนมากมากที่สุด นั่นจึงทำให้มันล่มบ่อยกว่ารีเจียนอื่น และพอล่มก็กลายเป็นข่าวระดับประเทศ ต่างจาก eu-south-2 ในสเปน
      NoVA ในกรณีนี้เป็นตัวอย่างของดาต้าเซ็นเตอร์ ไม่ใช่โรงงาน แต่เป็นคลัสเตอร์เศรษฐกิจแบบเดียวกับหัวข้อวิจัยที่ทำให้ Paul Krugman ได้รางวัลโนเบลเศรษฐศาสตร์
    • ผมเคยเจอเหตุ overheat รุนแรงในดาต้าเซ็นเตอร์สองแห่ง
      แห่งหนึ่งคือดาต้าเซ็นเตอร์ SOMA ของ Hosting.com ที่ร้อนจนต้องเอาสายยางฉีดน้ำบนหลังคาเพื่อลดความร้อน อีกแห่งคือดาต้าเซ็นเตอร์ Chai Wan ของ Alibaba ที่ร้อนจนทุกอย่างที่รันอยู่ที่นั่นรวมถึง control plane ล่มหมด
      เพราะงั้นผมเลยไม่คิดว่าการอยู่ใกล้ทะเลจะให้ข้อได้เปรียบเพิ่มในแง่ การระบายความร้อนฉุกเฉิน ความสามารถในการระบายความร้อนออกสู่ภายนอกมีขีดจำกัดอยู่ดี และไม่ว่าจะอยู่ริมทะเลหรือกลาง Nebraska ระบบทั้งหมดก็ต้องถูกออกแบบให้ได้ประสิทธิภาพตามที่ต้องการ
    • ตอนเรียนปริญญาโทผมเคยมีวิชาดาต้าเซ็นเตอร์ และอาจารย์ยกตัวอย่างดาต้าเซ็นเตอร์ในพื้นที่ร้อนของตอนกลางสหรัฐมาเทียบกับสถานการณ์ในอุดมคติ
      ในสไลด์มีหลายปัจจัยที่มีผลต่อการเลือกทำเลดาต้าเซ็นเตอร์ ซึ่งรวมถึงการหาพื้นที่เพียงพอและหา แรงงานฝีมือ ที่จะมาทำงานในดาต้าเซ็นเตอร์นั้นได้ และบางครั้งก็มีการเมืองเข้ามาเกี่ยวกับการเลือกที่ตั้งดาต้าเซ็นเตอร์แห่งถัดไปด้วย
    • เท่าที่นึกออก ระบบน้ำที่มีระดับความเค็มแบบน้ำทะเลมีค่าบำรุงรักษาแพงกว่ามาก วงจรรองก็เช่นกัน
      ที่ดินริมชายฝั่งก็แพงกว่ามาก และถ้าไปชายฝั่งที่ห่างไกลก็มีโอกาสเข้าถึงไฟฟ้าได้ไม่ดี
      พื้นที่ชายฝั่งมักเผชิญสภาพอากาศรุนแรงกว่า
      และยังมีเรื่องที่คาดเดายาก เช่นโรงไฟฟ้านิวเคลียร์ Diablo Canyon เคยมีปัญหา ช่องรับน้ำทะเลสำหรับหล่อเย็น อุดตันเพราะเศษซากและการเคลื่อนตัวของแมงกะพรุน
      https://www.nbcnews.com/news/world/diablo-canyon-nuclear-pla...
    • ในทะเลมีเกลือ น้ำเค็มทำร้ายอุปกรณ์อิเล็กทรอนิกส์มากกว่าน้ำธรรมดามาก
      น้ำต้องลึกพอ ไม่อย่างนั้นมันก็จะอุ่นขึ้นจนถึงอุณหภูมิผิวน้ำ และยังต้องแข่งขันด้านต้นทุนกับการระบายความร้อนแบบระเหยดั้งเดิมได้ด้วย
      กรณีตัวอย่างตามตำราคือ Toronto ที่มี ทะเลสาบน้ำจืดลึก อยู่ไม่ไกลจากชายฝั่ง และในย่านใจกลางเมืองอสังหาริมทรัพย์แพงจนแนวทางดั้งเดิมใช้ยาก
      https://en.wikipedia.org/wiki/Deep_Lake_Water_Cooling_System