Англійська для розробників GCP Cloud Run Jobs
Освоєння англійської лексики для Google Cloud Run Jobs: завдання проти служби, завдання, виконання, паралельність, тайм- аути, повторні спроби і тригери Cloud Scheduler.
Google Cloud Run Jobs розширює платформу Cloud Run за межі HTTP-сервісів для обробки пакетних і запланованих завантажень, які виконуються до завершення, а не чекають на запити. Розробники, які переміщуються між службами Cloud Run і роботами, часто плутали термінологію, і використання цих термінів точно в документації, runbooks і обговореннях команди запобігає дорогим нерозумінням у виробничих середовищах.
Ключовий словник
** Завдання ** — ресурс Cloud Run, який виконує код контейнера до завершення, на відміну від служби, яка прослуховує запити HTTP без обмеження часу.
- “Ми перетворили нічний генератор звітів з служби, яку запускає cron, на завдання Cloud Run, оскільки воно має визначений початок і кінець, а не постійний слухач.” *
** Служба ** — ресурс Cloud Run, який обслуговує HTTP- трафік, масштабується за обсягом запитів і виконується безперервно до тих пір, поки його не буде явно зупинено. “REST API розгортається як служба; конвеєр даних, який його живить, виконується як завдання за фіксованим розкладом.”
** Задача ** — окрема одиниця роботи у межах виконання завдання. Якщо ви встановите кількість завдань більше ніж одне, Cloud Run створить декілька незалежних екземплярів завдання.
- “Ми встановили кількість завдань на 200, щоб кожне завдання обробляло один файл CSV паралельно, зменшуючи загальний час виконання конвеєра з чотирьох годин до дванадцяти хвилин.” *
** Виконання ** — один запуск завдання, створеного вручну, за допомогою тригера планувальника або за допомогою API. Виконання містить один або декілька екземплярів завдання.
- “Виконання завдання у понеділок зазнало невдачі, оскільки контейнер джерела був порожній; логіка завдання тепер перевіряє вхідні дані перед обробкою, щоб уникнути помилкових станів невдачі.” *
** Паралелізм ** — максимальна кількість екземплярів завдань, які виконуються одночасно під час одного виконання. “Встановити паралельність до 50 і кількість завдань до 200; Cloud Run буде виконувати 50 завдань одночасно і встановить решту 150 у чергу до тих пір, поки не з’ являться вільні місця.”
** Тайм- аут ** — максимальний час, протягом якого можна виконувати кожне завдання, перш ніж Cloud Run завершить його виконання і позначить його як невдалу спробу.
- “Збільшити час очікування виконання завдання з 10 хвилин до 30 хвилин — крок відтворення PDF іноді триває довше, ніж очікувалося, для великих документів.” *
** Повторні спроби ** — кількість разів, коли Cloud Run автоматично перезавантажуватиме екземпляр завдання, виконання якого зазнало невдачі, перед тим, як позначати виконання як невдале.
- “Налаштувати три повторні спроби з експоненціальним відступом, щоб тимчасові помилки з’ єднання з базою даних не приводили до скасування всього імпорту за одну ніч.” *
** Тригер Cloud Scheduler ** — завдання Google Cloud Scheduler, налаштоване для виклику завдання Cloud Run за допомогою виразу cron, що дозволяє заплановане пакетне виконання без підтримки постійного робочого процесу. “Замінити завжди активну віртуальну машину на тригер Cloud Scheduler, який запускає завдання щоночі о 02:00 UTC, скорочуючи витрати на обчислення на 90%.”
Звичайні фрази
- «Запустити вручну виконання, щоб перевірити логіку завдання, перш ніж планувальник підбере його.»
- «Виконання затрималося на рівні завдання, а не на рівні завдання — перевірте окремі журнали завдань»
- «Ми використовуємо паралельність 10, щоб залишатися в межах нашого обмеження на підключення до Cloud SQL»
- «Дизайн ідемпотентності завдання забезпечує, що повторне виконання невдалого виконання не створить дублікатних записів»
- Cloud Scheduler передає аргументи виконання як змінні середовища всередині контейнера
Приклади висловлювань
При поясненні різниці між завданням і службою учаснику:
- “Служба Cloud Run працює безперервно і відповідає на запити користувачів у реальному часі. Cloud Run завдання запускається на запит або за розкладом, обробляє визначене навантаження, а потім зупиняється - ви платите тільки за час, коли він фактично працює. ”*
Під час написання звітності про подію:
- “Виконання зазнало невдачі, оскільки тайм- аут завдання було встановлено на 600 секунд, але експорт бази даних для великих користувачів потребує до 900 секунд. Ми оновили тайм-аут і додали журнал прогресу на рівні завдання, щоб виявити подібні проблеми раніше. ”*
Під час запропонованого перенесення з віртуальної машини cron до завдання Cloud Run: “Пересуваючи нічний ETL з виділених екземплярів n2-standard-4 на завдання Cloud Run, запускане Cloud Scheduler, ми виключаємо витрати на простої 24/7 VM, одночасно отримуючи автоматичний паралелізм завдань і повторне оброблення.”
Професійні поради
- Завжди вказуйте ** кількість завдань ** і ** паралельність ** окремо у документації — вони незалежні і обидва впливають на пропускну здатність і вартість неочевидними способами.
- Під час обговорення ** повторних спроб **, поясніть, чи логіка повторних спроб реалізована в самому коді контейнера, чи делегована вбудованому механізму повторних спроб Cloud Run — змішування обох може призвести до заплутаної поведінки.
- Використовуйте фразу « історія виконання », коли вказуєте колегам на перегляд консолі Cloud Run минулих запусків завдань — це відповідає мітки інтерфейсу користувача і уникає плутанини з журналами рівня програми.
- Довідка ** Cloud Scheduler trigger ** замість « cron job » в контекстах GCP, щоб уникнути неоднозначності з вкладками cron Linux або Kubernetes CronJobs.
Практичні вправи
- Поясніть менеджеру продукту різницю між службою Cloud Run і завданням Cloud Run у двох реченнях без використання слова « контейнер »
- У вас є завдання з 500 завданнями і екземпляр Cloud SQL з максимум 100 з’ єднаннями. Як би ви налаштували паралельність і чому? Напиши три речення.
- Виконання завдання зазнало невдачі після 8 годин, оскільки один з завдань перевищив час очікування. Які дві зміни конфігурації ви б розслідували першими?
Розрізняють: мовні стереотипи — стереотипи, що стосуються мовлення людей, які не говорять рідною мовою
Будьмо чесними — вивчення професійної англійської, особливо в технічній сфері, такій як GCP Cloud Run Jobs, не просто про запам’ятовування визначення. Це про розуміння того, як рідні носії насправді спілкуються. Якщо ви не є носієм мови, вам може бути складно перекласти певні фрази або поняття безпосередньо з вашої першої мови. Різниця між «задачею» і «роботом» в контексті Cloud Run є головним прикладом. Хоча «робота» може мати ширше значення, тут «задача» конкретно відноситься до однієї одиниці роботи — функції, виконаної всередині контейнера. Вираз « Мені слід створити нове завдання » може призвести до плутанини; точнішим і зрозумілішим буде вираз « Мені слід визначити нове * завдання *, яке буде виконано Cloud Run ». Аналогічно, розуміння тонких відмінностей у використанні слів * виконання * і * запуск * є ключовим для ефективного спілкування з вашою командою. « Виконання » означає фактичний процес виконання коду, а « запуск » може мати більш загальний зміст.
Іншою областю, де нюанс має велике значення, є опис проблем під час перегляду коду або при повідомленні про вади. Замість того, щоб вказати « Служба не працює », що є неясним, краще буде вказати « Не вдалося завершити виконання * завдання * за налаштований час очікування ». Таким чином ви отримаєте контекст і звернете увагу на конкретну проблему: завдання, яке перевищує його визначений час. Крім того, повідомлення Slack, що вимагають допомоги, повинні уникати надмірно буквальних перекладів. Запит на допомогу з « завдання Cloud Run », коли ви насправді маєте на увазі « заплановане завдання », ймовірно, призведе до запізнення відповіді або непродуктивної дискусії. Сфокусуйтесь на ясному вираженні того, що відбувається і чому вам потрібна підтримка. Використання правильної термінології у вашому запиті — «Чи може хтось допомогти мені у вирішенні проблеми невдалого виконання завдання, запущеного Cloud Scheduler?» — значно збільшує шанси швидкого отримання необхідної допомоги.
Нарешті, пам’ ятайте, що документація і запити на завантаження є формальними засобами зв’ язку. При описі змін у PR використовуйте точну мову, щоб уникнути неоднозначності. Наприклад, замість того, щоб сказати « Я додав деякі коди », скажіть « Я реалізував механізм повторних спроб для виконання невдалих завдань, щоб поліпшити надійність ». Такий рівень докладності демонструє професіоналізм і забезпечує, що ваші колеги повністю зрозуміють вплив ваших змін. Це про передачу інформації точно і ефективно - те, що рідні носії роблять інстинктивно.
gcloud run jobs create my-scheduled-job --region us-central1 --schedule "0 8 * * *" --timeout 600 --retry-attempts 3 --image gcr.io/my-project/my-app:latest