Це кілька досягнень, яких я зміг досягти в 2024 році:
Я отримав кілька сертифікатів на Cisco Networking Academy.
Я отримав кілька сертифікатів від Coursera.
Я досяг 4.7 середнього балу в школі.
Нарешті, я зміг визначитися з моєю спеціалізацією в кібербезпеці та розробити чіткий план.
Хоча я все ще обмежений шкільними активностями, я зрозумів, що це дало мені більше свободи для відкладання справ. Хоча я міг би зробити більше для розвитку своєї кар'єри, я безмежно вдячний за значний прогрес і радий, що досяг. І, безумовно, сподіваюся зробити більше в 2025 році. Моя вдячність усім, хто витратив свій час, щоб допомогти мені та підтримати мене, коли я стикався з труднощами на своєму шляху.
У 2025 році я почну з складання іспиту ISC2 CC та виклику #100днівкібербезпеки 🎯.
При створенні високопродуктивних застосунків розглядайте Amazon S3 як розподілену систему великого масштабу, а не як єдину точку мережі, як традиційний сервер зберігання. Найкраща продуктивність досягається шляхом одночасних запитів до Amazon S3.
Розподіляйте ці запити через окремі з'єднання, щоб максимізувати доступну пропускну здатність Amazon S3. Amazon S3 не накладає обмежень на кількість підключень до вашого бакету.
c) Використовуйте пошук за діапазоном байт
При використанні заголовка HTTP Range в запиті GET, ви можете отримати діапазон байт з об'єкта, передаючи лише вказану частину.
Можна використовувати одночасні з'єднання до Amazon S3 для отримання різних діапазонів байт в одному об'єкті. Це допомагає досягти вищого агрегованого пропуску, порівняно з одним запитом до повного об'єкта. Пошук менших діапазонів великого об'єкта також дозволяє вашій програмі покращити час повторних спроб, коли запити перериваються.
curl -H "Range: bytes=1500-1999" -o parte_do_arquivo_final.dat http://exemplo.com/arquivo_grande.dat
Зазвичай запити на діапазон байт складають 8МБ або 16МБ.
Для кращої продуктивності, якщо об'єкти завантажуються за допомогою multipart-завантаження, корисно отримувати їх тими ж розмірами частин (або хоча б вирівняними по межах частин).
Запити GET можуть звертатися безпосередньо до окремих частин; наприклад, GET?partNumber=N.
d) Retry request (повторна спроба запиту) для застосунків, чутливих до затримок.
Тайм-аути та повторні спроби, налаштовані агресивно (by Santos: які швидко реагують на помилки або високі часи відповіді), допомагають зберігати постійну затримку.
Зважаючи на великий масштаб Amazon S3, якщо перший запит буде повільним, повторний запит ймовірно піде іншим маршрутом і буде успішно виконаний швидше. (by Santos: обхід повільних шляхів — нова спроба може бути направлена по швидшому шляху).
SDK AWS мають налаштовувані значення тайм-аутів та повторних спроб.
e) Поєднуйте Amazon S3 (зберігання) і Amazon EC2 (обчислення) в одній регіоні AWS
Хоча імена бакетів Amazon S3 є унікальними у всьому світі, кожен бакет зберігається в конкретному регіоні, обраному під час його створення.
Для оптимізації продуктивності рекомендується отримувати доступ до бакету з інстанцій Amazon EC2, розташованих в тому ж регіоні AWS, коли це можливо. Це допомагає зменшити затримку мережі та витрати на передачу даних.
f) Використовуйте Amazon S3 Transfer Acceleration для мінімізації затримки, спричиненої відстанню
Amazon S3 Transfer Acceleration полегшує швидку, просту та безпечну передачу файлів на великі відстані, коли між клієнтом і бакетом S3 існують великі географічні відстані.
Він використовує глобально розподілені точки доступу Amazon CloudFront. Як тільки дані потрапляють до точки доступу, вони маршрутизуються до Amazon S3 через оптимізований мережевий шлях.
Transfer Acceleration ідеально підходить для регулярної передачі гігабайт або терабайт даних між континентами. Також корисний для клієнтів, які надсилають дані до централізованого бакету з різних частин світу.
Ви можете використовувати інструмент Amazon S3 Transfer Acceleration Speed Comparison для порівняння швидкостей завантаження з і без прискорення в різних регіонах Amazon S3. Цей інструмент використовує multipart-завантаження для передачі файлу з вашого браузера до різних регіонів S3, що дозволяє оцінити ефективність Amazon S3 Transfer Acceleration.
g) Використовуйте останню версію SDK AWS
SDK AWS підтримують багато з рекомендованих директив оптимізації продуктивності для Amazon S3.
Вони надають спрощений API для інтеграції Amazon S3 у ваші застосунки та регулярно оновлюються для включення найновіших найкращих практик. Наприклад, SDK включають логіку для автоматичного повторного виконання запитів у разі помилок HTTP 503 і мають оптимізований код для реагування та адаптації до повільних з'єднань.
SDK також надають Transfer Manager, який автоматизує горизонтальне масштабування з'єднань, дозволяючи досягти тисяч запитів на секунду при використанні запитів за діапазоном байт (byte-range requests), коли це доцільно. Важливо використовувати останню версію SDK AWS для використання найбільш актуальних можливостей оптимізації продуктивності.
При використанні REST API слід дотримуватися тих самих найкращих практик, що й в SDK: налаштовуйте тайм-аути та повторні спроби для роботи з повільними запитами і використовуйте кілька з'єднань для паралельного отримання даних з об'єктів.
2. Патерни проєктування для продуктивності в Amazon S3
При проєктуванні застосунків для завантаження та отримання даних з Amazon S3 використовуйте рекомендовані патерни проєктування для досягнення найкращої продуктивності для вашого застосунку. Також надаються Директиви продуктивності, які слід враховувати при плануванні архітектури вашого застосунку.
a) Використання кешу для часто запитуваного контенту
Багато застосунків, які зберігають дані, отримують однаковий запит від користувачів. Якщо є повторювані запити GET для спільного набору об'єктів, ви можете використовувати кеш, такий як Amazon CloudFront, Amazon ElastiCache або AWS Elemental MediaStore для оптимізації продуктивності.
Успішне впровадження кешу може призвести до низької затримки та високих швидкостей передачі даних. Застосунки, що використовують кеш, також надсилають менше запитів безпосередньо до Amazon S3, що допомагає знизити витрати на запити.
Amazon CloudFront — це швидка мережа доставки контенту (CDN), яка здійснює прозоре кешування даних з Amazon S3 у великій мережі точок присутності (PoPs), розподілених географічно.
Коли об'єкти можуть бути доступні в кількох регіонах або через інтернет, CloudFront дозволяє зберігати дані в кеші ближче до користувачів, які до них звертаються. Це може призвести до високої продуктивності доставки популярного контенту, що зберігається в Amazon S3.
Amazon ElastiCache — це керований сервіс кешування в пам'яті. За допомогою ElastiCache ви можете надавати інстанції Amazon EC2, які зберігають об'єкти в пам'яті. Таке кешування призводить до значного зменшення затримки запитів GET і значного збільшення швидкості завантаження.
Щоб використовувати ElastiCache, потрібно змінити логіку застосунку для заповнення кешу найчастіше запитуваними об'єктами та перевіряти кеш перед тим, як робити запити до Amazon S3.
AWS Elemental MediaStore — це система кешування та доставки контенту, створена спеціально для відеопотоків та доставки медіаконтенту з Amazon S3.
MediaStore надає API для зберігання від початку до кінця, орієнтовані на відео, і рекомендується для відео-завантажень, чутливих до продуктивності. Для додаткової інформації про MediaStore зверніться до AWS Elemental MediaStore User Guide.
b) Тайм-аути та повторні спроби для застосунків, чутливих до затримок
Існують ситуації, коли застосунок отримує відповідь від Amazon S3, вказуючи, що необхідна повторна спроба. Amazon S3 відображає імена бакетів та об'єктів на відповідні дані. Якщо застосунок генерує високі рівні запитів (зазвичай стабільні рівні понад 5.000 запитів на секунду для невеликої кількості об'єктів), він може отримати відповіді HTTP 503 з помилкою "повільно".
Коли ці помилки виникають, кожен AWS SDK автоматично реалізує логіку повторної спроби, використовуючи експоненційний зворотний зв'язок.
Якщо ви не використовуєте AWS SDK, важливо реалізувати логіку повторних спроб при отриманні помилки HTTP 503.
Amazon S3 здійснює автоматичне масштабування у відповідь на нові постійні рівні запитів, динамічно оптимізуючи продуктивність. Протягом періоду внутрішньої оптимізації для нового рівня запитів ви можете отримати тимчасові відповіді HTTP 503, поки оптимізація не буде завершена. Після завершення оптимізації запити зазвичай обробляються без необхідності повторних спроб.
Для застосунків, чутливих до затримок, Amazon S3 рекомендує активно моніторити та повторно виконувати більш повільні операції. При повторній спробі запиту рекомендується використовувати нове з'єднання з Amazon S3 та здійснити нове DNS-резолюцію.
Великі запити (змінні): Більше 128 МБ рекомендується моніторити швидкість передачі і повторювати запити для 5% найповільніших.
Малі запити: Менше 512 КБ, де середні затримки зазвичай становлять десятки мілісекунд, орієнтуйтесь на повтор запиту GET або PUT через 2 с. Якщо необхідно повторити спробу, використовуйте експоненційний зворотний зв'язок. Наприклад: 1-а спроба після 2 с, 2-га спроба після додаткових 4 с.
Запити фіксованого розміру: можна очікувати більш постійні часи відповіді. У цьому випадку визначте 1% найповільніших запитів і повторіть їх. Зазвичай одна спроба вже зменшує затримку.
Примітки щодо AWS KMS:
Якщо ви використовуєте AWS Key Management Service (AWS KMS) для шифрування на стороні сервера, зверніться до Квот в AWS KMS Developer Guide для отримання інформації про підтримувані рівні запитів для вашого випадку використання.
c) Горизонтальне масштабування та паралелізація запитів для високої швидкості передачі
Amazon S3 є розподіленою системою великого масштабу. Для того, щоб скористатися цією масштабованістю, ми рекомендуємо горизонтальне масштабування паралельних запитів до кінцевих точок сервісу Amazon S3. Окрім того, що це допомагає розподіляти запити всередині Amazon S3, цей підхід також допомагає розподілити навантаження через кілька шляхів у мережі.
Для передачі з високою швидкістю передачі (high-throughput), Amazon S3 рекомендує використовувати застосунки, які використовують кілька з'єднань для GET або PUT даних паралельно.
Це підтримується Amazon S3 Transfer Manager в AWS Java SDK. Більшість інших AWS SDKs також надають подібні структури.
Для деяких застосунків можна отримати паралельні з'єднання, ініціюючи одночасні запити на різних потоках застосунку або в різних екземплярах застосунку. Найкращий підхід залежить від структури застосунку та формату об'єктів, до яких здійснюється доступ. Рекомендації для передачі високих швидкостей
- Використання AWS SDKs для здійснення запитів GET та PUT безпосередньо. Це коригує робоче навантаження безпосередньо, зберігаючи переваги підтримки повторних спроб і обробки відповідей HTTP 503.
- Конкурентні запити за діапазонами байт. При завантаженні великих файлів всередині регіону Amazon S3 до Amazon EC2:
- Здійснюйте конкурентні запити за діапазонами байт об'єкта з гранулярністю 8–16 МБ.
- Здійснюйте один конкурентний запит для кожних 85–90 МБ/с бажаної пропускної здатності мережі. ( 85–90 МБ на секунду зазвичай є ідеальним завантаженням або завантаженням однієї HTTP-з'єднання. І пропускна здатність означає обсяг даних, який можна передати за допомогою того ж самого з'єднання.)
- Для насичення мережевої карти (NIC) зі швидкістю 10 Gb/s, використовуйте близько 15 одночасних запитів на окремих з'єднаннях.
- Для швидших мережевих карт (наприклад, 25 Gb/s або 100 Gb/s), збільшіть кількість одночасних запитів на додаткові з'єднання.
3. Оцініть продуктивність, щоб знайти ідеальну кількість одночасних запитів:
- Почніть з одного запиту за раз і оцініть пропускну здатність та використання ресурсів (наприклад: процесор, пам'ять).
- Визначте вузьке місце (ресурс з найбільшим використанням) та налаштуйте кількість одночасних запитів. Наприклад: якщо обробка одного запиту використовує 25% процесора, це означає, що можна підтримувати до 4 одночасних запитів.
- Перевіряйте використання ресурсів, коли швидкість запитів зростає.
- Використання REST API: Якщо ви використовуєте REST API Amazon S3 безпосередньо, рекомендується:
- Використовувати пул з'єднань HTTP.
- Перевикористовувати кожне з'єднання для серії запитів, щоб уникнути налаштування з'єднання для кожного запиту. Це усуває необхідність у TCP slow-start та SSL handshake для кожного запиту.
- Для отримання додаткової інформації про використання REST API, зверніться до Вступу до REST API Amazon S3.
Увага до DNS: Переконайтесь, що запити розподілені на широкий пул IP-адрес Amazon S3:
- DNS-запити до Amazon S3 проходять через велику кількість IP-ендпоінтів.
- Кешувальники DNS або код програми, що використовує єдину IP-адресу, не використовують різноманітність адрес та балансування навантаження, що з ним пов'язане.
Мережеві інструменти на кшталт команди netstat можна використовувати для перевірки IP-адрес, що використовуються для зв'язку з Amazon S3.
d) Використання Amazon S3 Transfer Acceleration для прискорення передачі даних через великі відстані
Просте пояснення Transfer Acceleration можна знайти на YouTube
Amazon S3 Transfer Acceleration зменшує або усуває затримку, спричинену географічною відстанню між глобально розподіленими клієнтами та регіональними застосунками, що використовують Amazon S3. Воно використовує edge-локації (локальні сервери кешу), розподілені по всьому світу в рамках CloudFront, щоб прискорити передачу даних.
Локація на межі AWS — фізичні комп'ютери, що використовуються як сервери для CloudFront
Глобальна мережа точок присутності (PoPs) включає більше 50 локацій. Ця інфраструктура використовується для розподілу контенту через CloudFront, швидкого реагування на DNS-запити через Amazon Route 53 і прискорення передачі даних до і з Amazon S3.
Ідеальні сценарії використання — передача даних між континентами або на великі географічні відстані. Вони мають швидкі інтернет-з'єднання, працюють з великими об'єктами та великими обсягами контенту.
Якщо ваше з'єднання повільне, ви все одно можете використовувати Transfer Acceleration, але вигоди від підвищення продуктивності можуть бути не такими значними. Це рекомендація більше для того, щоб гарантувати, що ви отримаєте максимальну користь від цього сервісу, усуваючи довгі відстані. (By santos)
Як це працює? Коли дані потрапляють в edge-локацію (локальну точку доступу), вони направляються до Amazon S3 через оптимізований мережевий шлях AWS.
Збільшення швидкості зазвичай зростає з відстанню від регіону Amazon S3. Тобто, чим далі клієнт від сервера, тим більше Transfer Acceleration оптимізує шлях.
Увімкнути Transfer Acceleration можна для нових або існуючих бакетів. Для доступу до edge-локацій AWS буде використовуватися окремий кінцевий ендпоінт Amazon S3 Transfer Acceleration.
Використовуйте Amazon S3 Transfer Acceleration Speed Comparison Tool для оцінки продуктивності.
Цей інструмент допомагає визначити, чи може Transfer Acceleration покращити продуктивність ваших запитів.
Ви можете порівняти цей лінк_ який AWS надає для перевірки збільшення швидкості у вашому регіоні при використанні acceleration. (By santos)_
($$$) Плата буде стягуватися тільки за передачі, де Transfer Acceleration може потенційно покращити продуктивність завантаження.
Ефективність Transfer Acceleration залежить від мережевих налаштувань та локальних і тимчасових умов. Воно найбільш вигідне для віддалених клієнтів від регіонів Amazon S3, особливо при міжнародних передачах. (Оскільки якщо вони знаходяться поруч, ефект не такий великий, правда?) офіційна документація.
Перекладено з: Melhores práticas de Padrões de Design: otimizando a desempenho da Amazon S3