اپ ساختهشده با هوش مصنوعیتان معرفی شد. آیا از پس هجوم ترافیک برمیآید؟
یک نفر اپ شما را به اشتراک گذاشته و هزار نفر یکباره سر رسیدهاند. اینجا میگوییم چطور به اپ ساختهشده با هوش مصنوعیتان کمک کنید از پس یک هجوم ترافیک بربیاید، بدون اینکه شب پیش از روز مهم آن را از نو بسازید.
نسخهٔ خوبِ یک روز بد را تصور کنید. اپ ساختهشده با هوش مصنوعیتان را در جامعهای که عضوش هستید منتشر کردهاید، یا کسی با دنبالکنندههای زیاد آن را امتحان و به اشتراک گذاشته، یا سر از صفحهٔ اول انجمنی درآورده که حتی خودتان آن را آنجا ثبت نکرده بودید. ناگهان آن جریان باریکِ همیشگی بازدیدکنندهها تبدیل به سیل میشود. هزار نفر، همه در یک ساعت، در حال کلیک کردن اینسو و آنسو.
این همان لحظهای است که برایش این چیز را ساختید. این همچنین همان لحظهای است که بسیاری از اپهای ساختهشده با هوش مصنوعی بیسروصدا از کار میافتند — صفحههای کند، لودرهای چرخان، فرم ثبتنامی که ثبت نمیشود. کسانی که بالاخره آمده بودند به دیوار میخورند و میروند، و بیشترشان دیگر هرگز برنمیگردند که دوباره امتحان کنند.
خبر خوب: جان بهدر بردن از یک هجوم ترافیک عمدتاً به مشتی تصمیم کسلکننده بستگی دارد که میتوانید آنها را پیش از وقوع هجوم بگیرید. لازم نیست مهندس باشید. لازم است بدانید کدام گوشهها را نباید بزنید.
وقتی ترافیک میپرد، واقعاً چه چیزی خراب میشود
وقتی صد برابر تعداد معمولِ افراد همزمان از اپ شما استفاده میکنند، چیزها بهصورت تصادفی خراب نمیشوند. آنها به ترتیبی قابلپیشبینی خراب میشوند، و تقریباً همیشه همان سه نقطهٔ یکسان است.
پایگاه داده زیر بار له میشود. هر بار که کسی یک صفحه را باز میکند، اپ شما معمولاً از پایگاه دادهاش سؤالی میپرسد: «دادهٔ این کاربر چیست؟» یک نفر که میپرسد چیزی نیست. اما هزار نفر که همان سؤال را در یک دقیقه میپرسند میتوانند سریعتر از آنچه پایگاه داده توان پاسخدادن دارد روی هم تلنبار شوند، و صفحهٔ همه به کندیِ یک لاکپشت میرسد.
چیزی بیرون از اپ شما کند میشود. بیشتر اپهای ساختهشده با هوش مصنوعی به سرویسهای دیگری تکیه میکنند — ارسال ایمیل، پردازش پرداخت، فراخوانی یک مدل هوش مصنوعی. این سرویسها اغلب محدود میکنند که چقدر سریع میتوانید فراخوانیشان کنید. زیر ترافیک عادی هرگز متوجه این محدودیت نمیشوید. زیر یک هجوم، اپ شما به آن میخورد، و ناگهان هر کنشی که به آن سرویس مربوط میشود متوقف میماند.
اپ کار پرهزینهٔ یکسانی را بارها و بارها انجام میدهد. اگر صفحهٔ اصلی شما هر بار که کسی بازدید میکند یک محاسبهٔ سنگین اجرا کند — گرفتن یک فهرست، رتبهبندیاش، قالببندیاش — برای ده بازدیدکننده مشکلی نیست و برای هزار نفر فاجعه است. این کار همیشه اتلاف بود. ترافیک کم فقط آن را پنهان میکرد.
به الگو دقت کنید: هیچکدام از اینها باگهای جدیدی نیستند. هجوم چیزی را خراب نکرد. ضعفهایی را آشکار کرد که از قبل آنجا بودند و بیسروصدا زیر ترافیک کم نشسته بودند.
ارزانترین راهحل: چیزهایی را که تغییر نمیکنند کش کنید
کشکردن (caching) فنی به نظر میرسد، اما ایدهاش ساده است: اگر پاسخ یک سؤال برای همه یکسان است و بهندرت تغییر میکند، یک بار آن را محاسبه کنید و دوباره بهکار ببرید، بهجای اینکه کار را برای هر بازدیدکننده از نو انجام دهید.
صفحهٔ اصلی شما احتمالاً برای هر هزار نفری که سراغش میآیند یک شکل دارد. پس چرا از پایگاه داده بخواهید آن را هزار بار از نو بسازد؟ یک بار بسازیدش، نتیجه را چند دقیقه ذخیره کنید، و همان نسخهٔ ذخیرهشده را به همه تحویل بدهید. شما همین حالا هزار رفتوآمد پرهزینه به پایگاه داده را به یک رفتوآمد تبدیل کردید.
دقیقاً همین را به اپساز هوش مصنوعیتان بگویید: «صفحهٔ اصلی و فهرست عمومی محصولات را برای پنج دقیقه کش کن تا در هر بازدید به پایگاه داده نخوریم.» هر چیزی که برای همه یکسان است و لازم نیست لحظهبهلحظه بهروز باشد — یک صفحهٔ قیمتگذاری، یک فهرست عمومی، یک نمایهٔ وبلاگ — کاندیدای کششدن است. چیزهای شخصیشده (داشبورد خودِ یک نفر، تنظیمات حسابش) را نمیتوان به همان شکل کش کرد، اما اینها معمولاً سهم کوچکی از ترافیک در حین هجوم هستند. بیشتر مردم به همان چند صفحهٔ عمومی نگاه میکنند.
مردم را برای چیزهایی که میتوانند بعداً اتفاق بیفتند منتظر نگذارید
این یک اشتباه است که آسان رخ میدهد و آسان هم رفع میشود. فرض کنید کسی ثبتنام میکند و اپ شما یک ایمیل خوشآمدگویی برایش میفرستد. اگر اپ شما او را در صفحهٔ ثبتنام منتظر بگذارد تا ایمیل کاملاً ارسال شود، آنگاه یک سرویس ایمیل کند، ثبتنام شما را کند میکند — درست در همان لحظهای که بیشترین تعداد افراد در حال ثبتنام هستند.
راهحل این است که بگذارید کارهای کند در پسزمینه اتفاق بیفتند. کاربر بلافاصله «وارد شدید!» را میبیند، و ایمیل چند ثانیه بعد بدون اینکه کسی منتظرش بماند ارسال میشود. نتیجه یکسان است، اما بازدیدکننده زل نزده به یک لودرِ چرخان در حالی که یک سرور ایمیل سه شرکت آنطرفتر سرِ فرصت کارش را انجام میدهد.
از اپسازتان بخواهید: «ایمیل خوشآمدگویی را در پسزمینه بفرست تا ثبتنام منتظرش نماند.» همین منطق برای هر چیزی که لازم نیست پیش از ادامهٔ کارِ کاربر تمام شود صدق میکند — تولید یک گزارش، همگامسازی با ابزاری دیگر، فرستادن یک اعلان. اگر کاربر همین الان به نتیجه نیاز ندارد، او را برایش منتظر نگذارید.
یک برنامه برای «آدمها خیلی زیادند» داشته باشید
گاهی هجوم بزرگتر از هر چیزی است که برایش آماده شدید، و حرکت صادقانه این است که بهجای فروپاشی، با وقار افت کنید. یک اپ کند که هنوز کار میکند بهتر از یک اپ خراب است.
چند نسخهٔ ساده از این کار:
- یک پیام انتظارِ دوستانه. اگر چیزی واقعاً زیر بار است، نشاندادن «الان بازدیدکنندههای زیادی داریم — کمی صبر کنید» بهمراتب بهتر از یک صفحهٔ خالی یا یک خطای خام است. مردم یک اپ شلوغ را میبخشند. یک اپ خراب را نمیبخشند.
- سنگینترین قابلیت را موقتاً خاموش کنید. اگر یک قابلیت همان پرهزینه است — مثلاً یک تولید با هوش مصنوعی که هر کلیک پول و زمان واقعی میبرد — میتوانید در حین موج آن را پنهان کنید و بقیهٔ اپ را سریع نگه دارید. بههرحال بیشتر بازدیدکنندهها در حین هجوم در حال مرور هستند، نه استفاده از پرتقاضاترین قابلیت شما.
- بدانید صورتحسابتان از کجا میآید. اگر اپ شما در هر بازدید یک مدل هوش مصنوعی پولی را فراخوانی میکند، هزار بازدیدکننده میتواند به معنای یک هزینهٔ غافلگیرکننده باشد، نه فقط یک صفحهٔ کند. دانستن اینکه کدام کنشها پول میبرند به شما اجازه میدهد از قبل تصمیم بگیرید چه چیزی را سقف بگذارید.
یک تمرین آزمایشی سیدقیقهای
برای پیداکردن نقاط ضعفتان به ابزارهای پیچیده نیاز ندارید. به چند دوست و نیمساعت وقت نیاز دارید.
از پنجشش نفر بخواهید همزمان اپ شما را باز کنند و چند دقیقه جدی اینسو و آنسو کلیک کنند — ثبتنام کنند، از قابلیت اصلی استفاده کنند، صفحههای شلوغ را باز کنند. خام است، اما چیزهای آشکار را سریع رو میکند. اگر اپ همین حالا با شش نفری که دارند زورش را میکِشند کند به نظر میرسد، هزار نفر صافش میکنند. اگر چابک بماند، دستکم از سدّ پایین گذشتهاید.
وقتی دارند کلیک میکنند، حواستان باشد کدام صفحه کندترین حس را میدهد. آن صفحهٔ کند دقیقاً همانجایی است که یک هجوم ترافیک واقعی بیشترین آسیب را خواهد زد، و اولین چیزی است که ارزش کشکردن یا سادهکردن دارد. شما در پی شبیهسازی هزار کاربر نیستید. در پی پیداکردن آن یک صفحهای هستید که همین حالا با شش نفر هم در زحمت است.
هدف واقعی
شما نمیتوانید اپتان را بینهایت ضدّگلوله کنید، و لازم هم نیست. هدف این نیست که در اولین لحظهٔ ویروسیشدنتان دههزار نفر را بینقص اداره کنید. هدف این است که جلوی همان چند صد نفری که بالاخره آمدند خودتان را شرمنده نکنید — مطمئن شوید کسانی که اینقدر سخت برای جذبشان تلاش کردید یک اپ کارآمد بگیرند، نه یک چرخ چرخان.
صفحههایی را که تغییر نمیکنند کش کنید. کارهای کند را به پسزمینه ببرید. برای «آدمها خیلی زیادند» یک برنامه داشته باشید. پیش از آنکه به آن نیاز پیدا کنید، یک تمرین آزمایشی با پنج دوست انجام دهید. هیچکدام از اینها نیازی به کدنویسی توسط خودتان ندارد — فقط دانستن چیزهای درستی که باید از اپساز هوش مصنوعیتان بخواهید.
آنگاه، وقتی لحظهٔ شما برسد، میتوانید بهجای اشکالزدایی سراسیمه از آن لذت ببرید. پس این پرسش ارزش دارد که این هفته رویش بنشینید: اگر فردا هزار نفر سر برسند، کدام صفحه اول خراب میشود — و آیا همین حالا جوابش را میدانید؟