อัตราการจำกัดแอปพลิเคชันแบบไร้เซิร์ฟเวอร์ของคุณ

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

1- ปกป้องทรัพยากรของคุณ: หากคุณให้บริการ API สาธารณะ การรับส่งข้อมูลที่พุ่งสูงขึ้นอาจทำให้คุณภาพของบริการลดลง และอาจนำไปสู่การหยุดให้บริการสำหรับผู้ใช้ทั้งหมดของคุณ คุณจำเป็นต้องปกป้องระบบของคุณจากความล้มเหลวที่ต่อเนื่องกันและเหตุการณ์ Ddos ที่เกิดขึ้นเอง ข้อบกพร่องในแอปพลิเคชันของคุณอาจทำให้เกิดปัญหาดังกล่าวในระบบของคุณ กระบวนการภายในที่ลองจุดปลายอีกครั้งโดยไม่มีกำหนดในกรณีที่เกิดความล้มเหลวอาจทำให้ทรัพยากรของคุณหมดไปได้อย่างง่ายดาย

2- จัดการโควต้าผู้ใช้: คุณอาจต้องการกำหนดโควต้าสำหรับผู้ใช้ของคุณเพื่อใช้บริการของคุณโดยชอบธรรม นอกจากนี้ คุณอาจต้องใช้โควต้าหากคุณให้บริการในระดับราคาที่แตกต่างกัน

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

โซลูชัน

มีโซลูชันการจำกัดอัตราทางเลือกหลายแบบในชั้นต่างๆ ฉันจะแสดงรายการหลัก 3 รายการพร้อมการวิเคราะห์ข้อดี/ข้อเสียโดยย่อ

1- ระดับการทำงานพร้อมกัน:

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

วิธีจำกัดการทำงานพร้อมกันสำหรับฟังก์ชัน AWS Lambda และ Google Cloud

ข้อดี:

• ไม่มีค่าโสหุ้ย
• กำหนดค่าได้ง่าย

ข้อเสีย:

• ไม่ใช่โซลูชันที่สมบูรณ์ ควบคุมการทำงานพร้อมกันเท่านั้น ไม่จำกัดจำนวนครั้งต่อวินาที

2- อัตราจำกัดบน API Gateway

หากคุณกำลังเข้าถึงฟังก์ชันของคุณผ่าน API Gateway คุณสามารถใช้นโยบายการจำกัดอัตรากับ API Gateway ได้ ทั้ง AWS และ GCP มีคำแนะนำเกี่ยวกับวิธีกำหนดค่าโซลูชัน

ข้อดี:

• ไม่มีค่าโสหุ้ย
• กำหนดค่าได้ง่าย

ข้อเสีย:

• ใช้เฉพาะเมื่อคุณใช้ API Gateway เท่านั้น
• ไม่รองรับกรณีที่ซับซ้อนกว่านี้ เช่น โควต้าต่อผู้ใช้หรือต่อ IP

3- จำกัดอัตราด้วย Redis

นี่คือโซลูชันที่สมบูรณ์และทรงพลังที่สุด มีไลบรารีจำกัดอัตราตาม Redis มากมาย ในบล็อกโพสต์ของ Jeremy Daly เขาปฏิเสธ Elasticache ว่าเป็นวิธีแก้ปัญหาที่เป็นไปได้ โดยบอกว่า* this adds a “non-serverless” component and another thing to manage *. ที่นี่ Upstash กลายเป็นทางเลือกที่ดีมากด้วยโมเดลแบบไร้เซิร์ฟเวอร์และราคาตามคำขอ

ข้อดี:

• ทรงพลัง คุณสามารถใช้ตรรกะที่กำหนดเองซึ่งเหมาะกับรูปแบบผู้ใช้ของคุณ
• โซลูชันที่ปรับขนาดได้ ดูวิธีที่ Github ใช้ Redis ในการจำกัดอัตรา
• ระบบนิเวศที่สมบูรณ์ ไลบรารีโอเพนซอร์สมากมาย:redis_rate, redis-cell, node-ratelimiter

ข้อเสีย:

• ค่าใช้จ่ายของการใช้ Redis

รหัส:การจำกัดอัตราด้วย Redis

ต้องขอบคุณไลบรารีที่จำกัดอัตรา มันจึงง่ายมากที่จะใช้การจำกัดอัตรากับรหัสแอปพลิเคชันของคุณ ด้านล่างนี้คือโค้ดตัวอย่างจำกัดการทำงานของฟังก์ชัน AWS Lambda ต่อ IP ต่อวินาที:

const RateLimiter = require("async-ratelimiter");
const Redis = require("ioredis");
const { getClientIp } = require("request-ip");

const rateLimiter = new RateLimiter({
  db: new Redis("YOUR_REDIS_URL"),
  max: 1,
  duration: 5_000,
});

module.exports.hello = async (event) => {
  const clientIp = getClientIp(event) || "NA";
  const limit = await rateLimiter.get({ id: clientIp });
  if (!limit.remaining) {
    return {
      statusCode: 429,
      body: JSON.stringify({
        message: "Sorry, you are rate limited. Wait for 5 seconds",
      }),
    };
  }

  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "hello!",
    }),
  };
};

ไปที่บทช่วยสอนสำหรับตัวอย่างแบบเต็ม

เรื่องรออ่าน

https://cloud.google.com/architecture/rate-limiting-strategies-techniques

https://www.jeremydaly.com/throttling-third-party-api-calls-with-aws-lambda/

https://medium.com/google-cloud/rate-limit-your-api-usage-with-cloud-endpoints-quotas-1270da55d2bf

https://github.blog/2021-04-05-how-we-scaled-github-api-sharded-replicated-rate-limiter-redis/

https://redis.io/commands/incr#pattern-rate-limiter

https://stripe.com/blog/rate-limiters