เลือก Amazon Aurora Endpoint ที่เหมาะสม: คู่มือปฏิบัติ

ฉันรู้ว่าคุณคิดว่า... ฉันจะแค่เชื่อมต่อกับ Cluster Endpoint สำหรับ Writes, Reader Endpoint สำหรับ Reads ทั้งหมด และทำไมต้องเชื่อมต่อกับ Instance เฉพาะ – นั่น Bypass Built-in Fault Tolerance และขอปัญหา มั้ย? ตามที่กล่าวไว้ก่อนหน้า Application ของคุณและ Interaction กับ Aurora สร้าง Complex (หรืออย่างน้อย Non-trivial) System กับ Complex Systems One-size-fits-all ไม่ใช่กฎที่จะพึ่งพา... เว้นแต่คุณจะชอบโทรศัพท์กลางคืน

มาเดินทางผ่าน Scenarios บางอย่างและดูว่าเมื่อไหร่และที่ไหนควรใช้ Endpoints ต่างๆ

Immediate Consistency

บาง Applications คาดหวังว่า Data จะ Immediately Consistent เมื่อ Applications เหล่านี้ Write Data พวกเขาจะ Read Data ทันทีใน Strict Compliance กับ Design Patterns หลายอย่างที่บอกว่า "Rely on the Model, Not Your Local Data" Amazon Aurora เป็น ACID-Compliant Read จาก Cluster Endpoint ทันทีหลังจาก Successful Write Commit จะ Retrieve Expected Data (สมมติว่า Transaction อื่นไม่ได้ Modify Data ก่อน Subsequent Read)

ปัญหาเกิดขึ้นเมื่อ Writes ส่งไป Cluster Endpoint และ Reads ทำไปที่ Reader Endpoint เนื่องจาก Latency ระหว่างการ Write Data และเมื่อมัน Visible ให้ Readers แม้ Replication Latency จะอยู่ภายใต้ 100 Milliseconds มันไม่ใช่ Instantaneous ทำให้เกิด Race Condition หากคุณมี Scenario ที่ต้อง Read Data ทันทีหลัง Write ใช้ Cluster Endpoint สำหรับ Reads และ Writes ทั้งคู่ ควรสังเกตว่า หากต้องการ Performance เพิ่มเติม คุณต้องเพิ่มขนาด Primary Instance ของคุณ

อย่างไรก็ตาม หาก Eventual Consistency ยอมรับได้และ Application ของคุณรองรับ การใช้ Reader Endpoint เป็นวิธีที่ยอดเยี่ยมในการลด Load บน Primary Instance ของคุณ

Offloading Reads

หาก Immediate Reads หลัง Writes ไม่ได้ OK Reader Endpoint มีประโยชน์อะไร? มี Use-cases หลายอย่างที่ Slightly Inconsistent Data ไม่ใช่ปัญหา ตัวอย่างเช่น: Daily Reporting เมื่อรัน Batch Jobs เพื่อสร้าง Reports จากข้อมูลเมื่อวาน 100-millisecond Replication Lag ไม่มีผลกระทบ ง่ายต่อการจินตนัยสถานการณ์อื่นๆ เช่น Product Descriptions บน Ecommerce Site... คุณมีโอกาสได้ Stale Data ใน Browser ของ User มากกว่าถูก Impact จาก Replication Lag

โดยทั่วไป Read-heavy Workloads ที่ไม่พึ่งพา Immediate Consistency ควรพิจารณาใช้ Reader Endpoint

Non-uniform Workloads

มีสถานการณ์ที่สมเหตุสมผลที่จะใช้ Instance Endpoints สมมติว่าคุณมี Application ที่มี Stateless Microservices จำนวนมากอยู่เบื้องหลัง Elastic Load Balancer ในสถานการณ์นี้ สมเหตุสมผลที่จะ Assume ว่า Queries ถูก Distribute อย่าง Uniform ข้าม Clients และดังนั้นข้าม Read Replicas – เมื่อใช้ Reader Endpoint

แต่ว่าสถานการณ์ที่ Workload ของแต่ละ Client ไม่ Uniformly Distributed ลองดู ถ้าเพิ่ม Reporting Service เข้าไป Read Replica หนึ่งจะมี Load ที่ Disproportionally High เทียบกับอื่นๆ หาก Microservices ที่กล่าวมาข้างต้นก็ใช้ Read Replica นี้ด้วย มี Probability สูงของ Poor Query Performance เมื่อ Query Instance ที่ถูกใช้โดย Reporting Service หนึ่งวิธีในการหลีกเลี่ยงคือ Manage Distribution ของ Connections ฝั่ง Client Side แทนที่จะให้ Amazon Aurora ทำให้ คุณโชคดีเพราะทำได้ง่ายด้วยการใช้ Instance Endpoints แทน Reader Endpoint ด้วย MariaDB Connector/J for Aurora for MySQL หรือ Fast Failover with Amazon Aurora PostgreSQL Driver สามารถทำให้ Aware ของ Individual Instances ที่คุณต้องการใช้เป็น Read Replicas ทำให้ Driver จัดการได้โดยตรงว่า Queries ถูก Distribute ไปยัง Individual Instances อย่างไร

จัดการ DNS Caching

นอกจากการเข้าใจ Nature ของ Workloads แล้ว การเข้าใจว่าการเชื่อมต่อถูก Allocate อย่างไรเพื่อให้ Aurora's High Availability และ Reader Endpoint Load Balancing ทำงาน สิ่งสำคัญ

การจัดการ Automatic Cluster Endpoint Failover และ Reader Endpoint Load Balancing จัดการผ่าน DNS (Amazon Route 53) ไม่ใช่ที่ IP, TCP หรือ Database Client Protocol Layers การจัดการ Distribution ของ Connections ผ่าน DNS หมายความว่า Application ของคุณต้องทำ DNS Query สำหรับแต่ละ New Connection Request Applications ที่ใช้ DNS Caching ควรปรับ Cache Timeout ให้ตรงกับ DNS Record TTL สำหรับ Amazon Aurora การ Cache DNS Responses นานกว่า Aurora DNS Record TTL จะทำให้เกิด Error Conditions 2 แบบ หากมี High-Availability (HA) Failover Event นั่นคือ Read Replica ถูก Promote เป็น Primary Cached DNS Response จะหมายความว่า Application ของคุณจะพยายาม Reconnect ไปยัง Old Failed Instance ในกรณีของ Reader Endpoint การ Cache DNS Response จะทำให้ Multiple Connections ไปยัง Read Replica เฉพาะแทนที่จะ Distributed ข้าม Read Replicas ที่พร้อมใช้งาน

Wrapping Up

เช่นที่เราเห็น ไม่มี One-size-fits-all Solution เมื่อพูดถึง Non-trivial Production Workload หาก Application ของคุณต้องการ Immediate Consistency ต้องแน่ใจว่า Reads และ Writes ส่งไป Cluster Endpoint ทั้งคู่ เมื่อ Read Queries จัดการ Replication Lag ได้เล็กน้อย Offload Read Queries ไป Reader Endpoint หากคุณสามารถใช้ Read Replicas แต่ Queries ของคุณไม่ Uniformly Distributed ข้าม Clients ทั้งหมด ให้ใช้ Instance Endpoints และ Manage Distribution ของ Connections ฝั่ง Client Side เพียงแค่จดจำว่า หาก Application ของคุณใช้ DNS Caching ด้วย Cache Timeouts นานกว่า DNS Record TTL Endpoints จะดูเหมือนไม่ทำงานตามที่คาดหวังระหว่าง Cluster Endpoint HA Failovers หรือเมื่อใช้ Reader Endpoint

การเข้าใจ Nature ของ Application ของคุณ ว่า Aurora Endpoints ทำงานอย่างไร และนำความรู้ไปใช้อย่างถูกต้อง จะนำไปสู่ Application Environment ที่ Robust มากขึ้น ซึ่งสำคัญมากสำหรับคุณและลูกค้าของคุณ ไม่มีใครอยากได้ Outage Call กลางคืน

ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม