หากคุณกำลังอ่านนี้ คุณน่าจะเคยได้ยิน Amazon Aurora มาแล้ว ตามที่คุณรู้ Amazon Aurora เป็น PaaS Service ที่ AWS จัดให้เป็นส่วนหนึ่งของ RDS Suite of Services มันให้ Fully Managed Relational Database Management System (RDBMS) ที่มี 2 รสชาติ คือ MySQL และ Postgres ขณะที่รักษา Wire Compatibility กับทั้งสอง แต่สิ่งนี้ส่งผลต่อ High Availability Strategies และ Options ของคุณอย่างไร?
คุณอาจสงสัยว่า Amazon Aurora แตกต่างจาก MySQL หรือ PostgreSQL บน Amazon RDS อย่างไร นี่ก็คือ Fully Managed RDBMS Services เช่นกัน ใช่ไหม? ใช่ แต่พวกเขาเป็น Standard Open-source Implementations ที่รันบน Fleet ของ EC2 Instances และถูก Manage โดย AWS ความแตกต่างสำคัญกับ Aurora คือ AWS แยก Storage Engine ออกจาก Database Engine AWS ใช้ Separation of Concerns Principle กับ Open-source Databases
Separation of Concerns
ปกติ RDBMS ต้องรันบน Generally Available Hardware หมายความว่า Implementation ต้องทำงานภายใต้ Limitations ที่ถูก impose โดย OS และ Hardware เพื่อทำ Features ทั้งหมดที่เราคาดหวังจาก Modern Database เช่น: DML และ DDL Processing, ACID Compliant Transactions, Replication, High-Availability (HA) และ Fault Tolerance หากแต่ Implementation ไม่ได้ถูก Require ให้รันบน Generally Available Hardware แต่เฉพาะใน Environment ที่ออกแบบมาเฉพาะสำหรับ Database Responsibilities ต่างๆ ก็สามารถแยกออกเป็น Layers ได้ ทำให้ Database Engine และ Storage Engine สามารถ Focus และ Specialize ได้ ผลลัพธ์คือ High-Availability และ Performance สามารถเพิ่มขึ้นอย่างมีนัยสำคัญ – ถึง 5x มากกว่า Standard MySQL และถึง 3x มากกว่า Standard PostgreSQL
โอเค มันเร็วกว่า แต่ Database และ Storage Engine ที่ Specialize ช่วยเราในเรื่อง HA อย่างไร? มีหลายวิธีที่สิ่งนี้ช่วยให้เราบรรลุ HA ก่อนที่เราจะเจาะลึก มาดูภาพรวมอย่างรวดเร็วว่า Aurora Storage Engine ทำงานอย่างไรเพื่อช่วยให้เราเข้าใจว่า HA มาจาก Separation นี้อย่างไร
เมื่อ Data ถูก Write ไปยัง Aurora Storage Engine Engine จะดูแลให้ Data ถูก Write อย่าง Consistent, Correct และ Durable Data ถูก Write ใน 2 Locations ในแต่ละของ 3 Availability Zones รวม 6 สถานที่ที่แตกต่างกัน Storage Engine จัดการ Complexities ของการทำให้ทั้งหมดเกิดขึ้นอย่างถูกต้อง แม้จะ Oversimplification เล็กน้อย แต่ในฐานะพื้นฐาน Database Engine ตอนนี้สามารถ "Fire-and-forget" ได้ ไม่ต้องกังวลว่าข้อมูลถูกเขียนแล้วหรือยัง Transaction Logs ความเป็นไปได้ของการต้อง Recover ฯลฯ
การเอา Storage Concern ออกจาก Database Engine จำนวน HA Strategies กลายเป็น Available
Read Replicas
ในขณะที่ Concept ของ Read Replicas มานานกว่า Aurora การ Implement ใน Open-source Solutions เกี่ยวข้องกับ Log Shipping หรือ Query Replays ด้วย Aurora Read Replicas มี Read-only Access ไปยัง Exact Same Storage ตรงกับ Master นี่หมายความว่า Replication Latency น้อยมากจากเวลาที่ Data ถูก Write จนถึงเวลาที่มัน Visible ให้ Read Replica (Replication Lag จะเป็น Misnomer ใน Scenario นี้) เมื่อต้องการ Multiple Read Replicas ทุก Read Replicas เห็น Data เดียวกัน ลด Overhead และ Complexity ที่วางบน Master ซึ่งพบใน Standard MySQL และ PostgreSQL Implementations Features เหล่านี้รวมกันทำให้ Read Replica สามารถ Take Over ทันทีหาก Master Fail นอกจากนี้ AWS จัดการ Replacing Failed Instance เพื่อ Meet Provisioned Capacity ด้วย Instance ใหม่ และ Update DNS เพื่อ Point ไปยัง Master ใหม่
นี่เป็น Solution ที่ยอดเยี่ยมสำหรับ Applications ที่มี High Read-to-Write Ratio อย่างไรก็ตาม จำไว้ว่า Primary Instance ของคุณต้องใหญ่พอที่จะ Handle Entire Write Load นอกจากนี้ สำหรับ Write HA คุณต้องการ Provision อย่างน้อยหนึ่ง Read Replica ที่มีขนาดเท่ากับ Master ของคุณ จากนั้น Set Read Replica นี้เป็น Priority Instance เพื่อ Promote เป็น Primary Instance ในกรณี Failure คุณจะ Maintain High Availability สำหรับ Read และ Write Capacity ทั้งคู่
Autoscaling
Autoscaling คือความสามารถในการ Horizontally Scale Out (เพิ่ม Instances) หรือ Scale In (ลด Instances) จาก Set ของ Available Servers คุณอาจเคยได้ยิน Autoscaling สำหรับ EC2 Instances แต่คุณรู้ไหมว่าคุณสามารถมี Elasticity ใน Aurora Read Replicas ได้ด้วย? ทั่วไปคุณจะ Configure Minimum Number ของ Read Replicas เพื่อ Handle Base Load และมี Autoscaling Policies เพื่อ Add หรือ Remove Instances เมื่อ Demand เปลี่ยนแปลง ความสามารถในการใช้ Elasticity เป็น Derivative อีกอย่างของข้อเท็จจริงที่ Storage Engine แยกจาก Database Engine
ตัวอย่าง Scenario ที่มีประโยชน์คือ B2B Ecommerce Site จะมี Heavy Traffic ใน Weekday Business Hours แต่ Very Little Overnight และ Weekends Images และ Content Descriptions มี High Read-to-Write Ratio และได้ประโยชน์จาก Read Replicas และ Autoscaling ทั้งคู่ Autoscaling Read Replicas ของคุณช่วยให้คุณ Meet Demand ใน Peak Hours ในขณะที่ Minimize Cost ใน Off Hours
Cross-Region Replication
หากคุณต้องการนำ Availability ไปสู่ Next Level Replicate ไป Region อื่น โดยมี Database Engine Replicate Data ไป Region อื่น มันสามารถ Read Locally หรือใช้ในกรณี Failure ของ Primary Region Instance ใน Secondary Region ถูก Treat เป็น Read Replica (นี่ไม่ใช่ Multi-master) แต่มันก็สามารถมี Read Replicas ของตัวเอง หรือกลายเป็น Master หาก Primary Region Fail
มีหลายเหตุผลที่ Cross-Region Replication จำเป็น บางครั้ง Data สำคัญเกินไปที่จะจัดเก็บใน Single Geographic Region อาจเป็นเพราะ Business Continuity, Regulatory หรือ Financial Reasons อีกเหตุผลหนึ่งคือ Reduced Latency ระหว่าง Users และ Database Backend ใช้ Ecommerce เป็นตัวอย่างอีกครั้ง การเปลี่ยนแปลง Images และ Descriptions สามารถ Apply ไป Master ใน Single Region แต่ Distributed Globally เพื่อ Read Locally
External Replication
สถานการณ์ที่คุณต้องการ Data นอก Aurora Cluster นั้นมีบ้าง มีสถานการณ์ที่ Corporate Policies หรือ Regulatory Environment ต้องการ หรือคุณมีความต้องการ Process Data หรือ Run Reports นอก Aurora ทุก Cases เหล่านี้สามารถจัดการได้โดยใช้ External Replication
ง่ายที่จะให้ Aurora Replicate Data ไปยัง Amazon EC2 MySQL Instance, Amazon EC2 Instance ที่รัน MySQL หรือแม้แต่ MySQL Instance ที่รันใน Corporate Data Center ของคุณ ด้วย One-way Replication นี้ Data ของคุณจะ Always In Sync กับ Aurora Cluster ของคุณและ Available สำหรับใช้งานนอก Aurora
Serverless
ท้ายที่สุด แต่น้อยที่สุด คือ Serverless อาจเป็นหนึ่งใน Significant Developments สำหรับ Availability และ Scalability คือการเพิ่ม Serverless เข้าไปในสมการ อย่างชัดเจน Serverless ไม่ได้หมายถึง No Servers มันหมายถึงคุณไม่ต้องกังวลเกี่ยวกับ Provisioning, Configuration, Scaling หรือ Maintenance ของ Servers ใดๆ
เพื่อ Configure Aurora Serverless คุณระบุ Capacity ที่ Available ให้ Application ของคุณ และ AWS จัดการ Details ของการทำให้ Capacity นั้น Available On-demand เมื่อ Clients ของคุณต้องการ สำหรับ Serverless Additional Layer คือ Proxy Layer ถูกเพิ่มเข้าไปใน 2 Layers ที่มีอยู่แล้ว คือ Database Engine และ Storage Engine
AWS Maintains Fleet ของ Proxy Servers ที่ Listen สำหรับ Incoming Requests นอกจากนี้ Warm Pool ของ DB Capacity กำลังรอ Serve Request เมื่อ Query แรกของคุณเข้ามา Proxy Fleet รับมัน Request Instance จาก Warm Pool และ Forward Request ไปยัง Instance นั้น หลังจาก Allocated ให้คุณใช้แล้ว แม้แต่มากกว่านั้น จำนวน Instances ที่ Allocated ให้คุณใช้เป็น Elastic และ Scale In และ Out ตาม Demand และ Limits ที่คุณระบุใน Aurora Serverless Configuration ตาม Strategies ก่อนหน้า ความสามารถในการ Dynamically Allocate Database Engine ให้คุณเป็นไปได้จาก Separation ของ Database และ Storage ตาม Configuration ของคุณ Database Instance อยู่ Assigned ให้คุณและ Available สำหรับ Immediate Use หลังจาก Timeout Period Expires Instance จะถูก Return ไป Warm Pool คุณถูก Charge เฉพาะ Resources ที่คุณใช้ เมื่อ Instance ถูก Allocated ให้คุณใช้ คุณถูก Charge สำหรับมันบวก Consumed Storage เมื่อไม่ได้ Allocated คุณถูก Charge เฉพาะ Storage ที่ Consumed
สำหรับ Workloads ที่ Spikey เช่น Development และ Test Environments หรือ New Applications ที่เพียงแค่ไม่มี History เพียงพอที่จะ Predict Usage Patterns Serverless คือทางที่จะไป คุณไม่ต้องจ่ายสำหรับ Resource ที่คุณไม่ใช้ ไม่ต้องกังวลว่า Dev Team ปิดไฟก่อนออก Weekend และคุณไม่ต้องตื่นกลางคืนเพื่อ Adjust Capacity เพราะ Time Zone ของ Users ตรงกับ Sleep Zone ของคุณ
Wrapping Up
Amazon Aurora สร้างขึ้นด้วย Availability, Durability และ Scalability ในใจ หากใช้เหมือน Standard Open-source Implementations คุณมี Database ที่ Solid, Reliable และ Performant ด้วยการมองลึกกว่านั้นที่ Aurora's Capabilities และ Patterns เพื่อ Leverage พวกเขา คุณสามารถ Implement Solution เพื่อ Meet Needs ของคุณได้ ตั้งแต่ Local Read Offloading ไปจนถึง Globally Distributed Availability
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม
