در یک پست مهندسی تفصیلی، شرکت یِلب (Yelp) نحوه ساختن یک خط لوله قابل توسعه و مقرونبهصرفه برای پردازش لاگهای دسترسی سرور Amazon S3 در سراسر زیرساخت خود را شرح داد. این رویکرد به آنها کمک کرد تا از محدودیتهای سنتی ذخیرهسازی خام لاگ و پرسوجو با حجم بالا عبور کنند.
به طور خلاصه، یِلب اکنون ترابایتها از لاگهای دسترسی روزانه را پردازش میکند، اما این لاگها به آرشیوهای فشردهای با فرمت Parquet تبدیل میشوند که امکان پرسوجو آسان با ابزارهایی مانند Amazon Athena را فراهم میکنند. از طریق فرآیندی به نام “تراکم” (compaction)، اشیاء متن خام لاگ در فایلهای بزرگتر Parquet ادغام شده و مصرف فضا را حدود 85٪ کاهش داده و تعداد اشیاء را بیش از 99.99% کم میکند.
این تبدیل، تحلیلها را کارآمد و مقرونبهصرفه کرده است. این امر امکان جستجوهای سریع برای اشکالزدایی مجوزها، تخصیص هزینه، بررسی حوادث و تجزیه و تحلیل حفظ دادهها را فراهم می کند.
در پشت صحنه، معماری از AWS Glue Data Catalog برای مدیریت طرحوارهها در چندین حساب AWS استفاده میکند. همچنین ترکیبی از کارهای دستهای زمانبندیشده، توابع Lambda و جداول مبتنی بر تابعی Projection برای ورود قوی و خودکار به لاگ استفاده میشود. این سیستم طوری طراحی شده است که تأخیر یا تکرار تحویل لاگ را تحمل کند – چیزی که SAL (Server Access Logs) بهطور ذاتی اجازه میدهد – با انجام درجهای idempotent و علامتگذاری اشیاء قدیمی لاگ برای انقضای چرخه حیات پس از بایگانی ایمن محتوای آنها.
سیستم یِلب همچنین از موارد استفاده عملیاتی کلیدی پشتیبانی میکند. برای اشکالزدایی، مهندسان میتوانند بررسی کنند که آیا یک شیء خاص در زمان معینی دسترسی (یا عدم دسترسی) داشته است یا خیر. برای تحلیل هزینه، امکان تجمیع استفاده API بر اساس IAM Role وجود دارد تا مشخص شود کدام خدمات یا تیمها بیشترین ترافیک را تولید میکنند. برای حفظ بهداشت داده، ترکیب لاگهای دسترسی با موجودی S3 به تیم اجازه میدهد اشیاء بدون دسترسی در دورههای تعریف شده را شناسایی و بهطور ایمن حذف کنند.
اهمیت کار یِلب دو وجهی است: این موضوع نشان میدهد که ثبت سطح شیء در S3، که پیشتر گران یا غیرعملی در مقیاس بزرگ تلقی میشد، میتواند کارآمد و از نظر عملی قابل مدیریت باشد. همچنین یک معماری مرجع برای سایر شرکتهایی که به دنبال دید مشابه یا وضعیتی سازگار هستند ارائه میکند. با افزایش تقاضا برای حکمرانی دادههای دقیقتر، حسابرسی و شفافیت هزینه در محیطهای ذخیرهسازی ابری، درسهای یِلب رویکردی عملی برای مقیاسبندی ثبت دسترسی بدون ایجاد هزینههای اضافی یا به خطر انداختن قابلیت پرسوجو ارائه میدهد.
علاوه بر مثال یِلب، نمونههای دیگری نیز وجود دارند که الگوهای طراحی مشابه آنچه را که یِلب در معماری خود برای “لاگهای دسترسی S3 در مقیاس” شرح دادند، منعکس میکنند. Upsolver یک پلتفرم Data Lake/ETL است که از پشتیبانی داخلی برای وارد کردن لاگهای دسترسی S3، تبدیل آنها به قالبهای آماده تحلیلی و بهینهسازی آنها برای موتورهای پرسوجو برخوردار است. گردش کار پردازش لاگهای دسترسی S3 در Upsolver دقیقاً مشابه آنچه یِلب انجام داد است: دریافت لاگها، تبدیل آنها و امکان جستجوی آنها توسط موتورهای SQL مانند Amazon Athena.
همچنین AWS خود یک معماری نمونه را برای پردازش لاگهای دسترسی سرور S3 با استفاده از Glue Job منتشر کرده است (بهطور خاص در ترکیب با Ray برای پردازش مبتنی بر Python قابل مقیاس). این خط لوله، پارتیشنبندی میکند، قالببندی میکند (به Parquet)، کاتالوگبرداری میکند و سپس از Athena (یا گاهی اوقات ابزارهای تجسم مانند QuickSight) برای پرسوجو یا تجزیه و تحلیل الگوهای دسترسی در مقیاس استفاده میکند. این اساساً الگوی “تراکم + جدول + کاتالوگ + پرسوجو” را که یِلب پذیرفته است، تکرار میکند، اما به عنوان یک دستور العمل مدیریت شده از AWS.
برای سازمانهایی که نیاز به جستجوی/هشدار نزدیک به زمان واقعی (به عنوان مثال برای امنیت یا تشخیص ناهنجاری) دارند، AWS همچنین الگویی را توصیف کرده است تا لاگهای سرور دسترسی را از S3 وارد OpenSearch کند (با استفاده از Lambda + خطوط ورود). اگرچه این کار برخی از کارایی ذخیرهسازی طولانیمدت که Parquet+ Athena ارائه میدهد را قربانی میکند، اما قابلیت تحقیق و نظارت فوری را فراهم می کند – برای زمینه های امنیتی، انطباق یا عملیاتی مفید است.
📌 توجه: این مطلب از منابع بینالمللی ترجمه و بازنویسی شده است.