المستوى: محترف

وقت القراءة: 9 دقائق

لو Lambda function بياخد 3.2 ثانية على أول طلب بعد deploy جديد، ونسبة Cold Start في الـ traffic بتاعك عند 12%، P99 latency بيقفز فوق 4 ثواني وعميل الـ API بيشوفها timeout. SnapStart في 4 سطور إعداد بيختصر الزمن لـ 180 مللي ثانية، بدون تعديل سطر كود، وبدون تكلفة شهرية ثابتة زي Provisioned Concurrency.

Cold Start مش مشكلة Lambda — هي مشكلة الـ Init Phase

المشكلة باختصار

كل ما Lambda يحتاج يشغّل instance جديد (بسبب scale up أو deploy أو طول idle لأكثر من 5 دقائق)، الـ runtime بيمر بأربع مراحل قبل ما الكود بتاعك يبدأ يرد:

1. تحميل الـ runtime نفسه (JVM, CPython, .NET CLR).
2. استيراد الـ dependencies (boto3, pandas, Spring beans).
3. تشغيل static init code (DI containers, DB clients, config loaders).
4. تنفيذ الـ handler function نفسه.

الخطوات التلاتة الأولى دي اسمها Init Phase، وبتاخد بين 800 مللي ثانية و 6 ثواني حسب الـ runtime وحجم الـ dependencies. الـ handler نفسه عادة بياخد ميلي ثواني. يعني انت بتدفع 95% من زمن أول طلب على حاجة مش الكود اللي كتبته.

تشبيه يوضح فكرة SnapStart

تخيّل إنك صاحب محل قهوة بتفتح كل صبح. التحضير العادي بياخد 6 دقايق: تشغيل ماكينة الـ POS، تحميل كاتالوج الأسعار، تجهيز ماكينة القهوة، شوية تنوير. لو في 50 زبون قدام الباب الساعة 9، أول واحد بيستنى 6 دقايق ساعة ما تخلص التحضير.

SnapStart بيقلب اللعبة. في اليوم الأول بس انت بتفتح المحل لحد ما يخلص كل التحضير. بعدين كاميرا بتاخد لقطة (snapshot) للمحل في الحالة دي. كل صبح بعد كده، انت مش بتعيد التحضير من أوله — بتنسخ اللقطة دي وخلاص. الزبون الأول بيلاقي القهوة دافية والكاتالوج جاهز قبل ما يدخل من الباب.

التعريف العلمي

SnapStart بياخد microVM snapshot للـ Lambda execution environment بعد ما الـ Init Phase يخلص بالكامل (بما فيها static init وأي class loading). الـ snapshot بيتخزّن مضغوط ومشفّر في cache مدار من AWS. أول invocation جديد، Firecracker hypervisor بيستعيد الـ snapshot في 50–200 مللي ثانية بدل ما يبدأ الـ initialization من الصفر.

الأرقام الحقيقية

على Spring Boot function بحجم 76MB (deployment package + dependencies)، AWS قاست في تجربة موثّقة:

• بدون SnapStart: P99 cold start = 6.1 ثانية
• مع SnapStart: P99 cold start = 1.4 ثانية (تحسّن 4.3x)

على Python 3.12 function بستيراد pandas + numpy + sqlalchemy:

• بدون SnapStart: 3.2 ثانية
• مع SnapStart: 180 مللي ثانية (تحسّن 17.7x)

الافتراض هنا: الـ memory size 1024MB و الـ region us-east-1. لو Function بتاعك أصغر أو الـ dependencies أقل، التحسّن هيكون أقل بطبيعة الحال.

الكود — تفعيل SnapStart بـ 4 سطور SAM

في ملف template.yaml الخاص بـ AWS SAM:

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.12
      MemorySize: 1024
      Timeout: 30
      CodeUri: ./src/
      Handler: app.handler
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live

الـ AutoPublishAlias ضروري لأن SnapStart بيشتغل على published versions فقط، مش على $LATEST. بدون alias، أي تحديث للكود مش هيستفيد من SnapStart خالص.

SnapStart vs Provisioned Concurrency — الـ trade-off الجوهري

الفرق بينهم مش بس في الـ latency، هو في model التكلفة بالكامل:

• SnapStart: تكلفة 0.0000015046$ لكل GB-second cache + 0.0001397998$ لكل GB استعادة. Function بحجم 1GB و 1M invocation/شهر بيطلع تقريبًا 8$ زيادة. النتيجة: 100–500ms latency، runtimes محدودة (Java 11/17/21، Python 3.12+، .NET 8).
• Provisioned Concurrency: 10 instances × 512MB × 730 ساعة = 15.21$ شهري ثابت + تكلفة الـ invocation. النتيجة: 10–30ms latency، كل الـ runtimes مدعومة، بتدفع حتى لو Function معندوش traffic.

القاعدة العملية: لو الـ traffic عندك متغير وفيه ساعات هدوء (شغل internal أو B2B)، SnapStart أرخص بنسبة 60–80%. لو الـ traffic ثابت 24/7 وعايز P99 تحت 50ms (شغل consumer-facing)، Provisioned Concurrency أوفر هندسيًا رغم تكلفته الثابتة.

فخ خفي: ephemeral state بعد restore

أهم تفصيلة بيغفل عنها كتير: لو الكود فتح DB connection أو HTTP client في init code، الـ socket ده بيتحفظ في الـ snapshot. لما SnapStart يستعيد الـ instance بعد 4 ساعات، الـ connection بقى ميت من زمان والـ DB بترفض الطلبات بـ connection reset by peer.

الحل: استخدم BeforeSnapshot و AfterRestore hooks. على Java مع aws-lambda-java-libs ده بيتعمل بـ implementation لـ Resource interface. على Python فيه decorator اسمه register_before_snapshot بيقفل الـ connections قبل الـ snapshot ويفتحها تاني بعد الـ restore.

متى لا تستخدم SnapStart

• لو الـ function بيستخدم EFS mount — مش مدعوم خالص.
• لو محتاج ephemeral storage فوق 512MB — مش مدعوم.
• لو الـ runtime مش Java 11/17/21 أو Python 3.12+ أو .NET 8 — Node.js و Go و Ruby مش متاحين لـ SnapStart حتى مايو 2026.
• لو الكود بيعتمد على state دايمًا متجدد في init (uniqueness tokens، random seeds للـ encryption، open WebSocket connections). الـ snapshot بيحفظ القيم القديمة وممكن يكسر منطق التطبيق صامتًا.
• لو محتاج تجمع SnapStart مع Provisioned Concurrency على نفس الـ function — AWS بتمنع الكومبو ده.

الخطوة التالية

افتح template.yaml بتاعك دلوقتي، ضيف الـ 4 سطور دول، deploy، وقيس P99 على CloudWatch قبل وبعد. لو الـ function Python أو Java، التحسّن بيظهر في أول 20 invocation. لو شغّال Node.js أو Go، خليك مع Provisioned Concurrency لحد ما SnapStart يدعم runtimes إضافية. ابعتلي الأرقام لو الفرق طلع أقل من 3x — غالبًا الـ init code عندك خفيف أصلًا والمشكلة في حتة تانية.

المصادر

• AWS Lambda Documentation — SnapStart
• AWS Compute Blog — Under the hood: how AWS Lambda SnapStart optimizes function startup latency
• AWS Compute Blog — Starting up faster with AWS Lambda SnapStart
• AWS Compute Blog — Optimizing cold start performance with advanced priming strategies
• AWS Lambda Pricing