Як не втратити ефективність доставки email і оптимізувати перехід з одного сервісу на інший
Привіт, я Кирило Михайлець, фул-стек інженер у продуктовій студії Railsware. Сьогодні розкажу вам, як нам вдалося створити оптимальне рішення для переїзду з одного мейл-сервісу на інший для платформ і застосунків у Ruby on Rails.
Цей матеріал буде корисний усім, кому в роботі доводиться стикатися з масовою відправкою email за допомогою сторонніх сервісів, а також тим, для кого ефективність доставки електронних листів має принципове значення для результату.
Як усе починалося: чому бізнесам важлива ефективна робота email-сервісу
Знайома ситуація для інтернет-бізнесу: є у вас застосунок чи комерційна платформа з функціоналом розсилки мейлів. Причому, від справності потрапляння листів (особливо транзакційних) до скриньки користувача залежить репутація і статки вашої справи. Приміром, якщо замовник не отримає підтвердження про отримання чи оплату свого замовлення, скоріш за все, ви матимете неприємності. Мейл у скриньці — довіра у серці клієнта.
Припустімо, компанія, в якій ви працюєте, не задоволена своїм нинішнім email service provider, сервісом доставки електронної пошти. Які є часті проблеми з такими платформами:
- вони нерідко «прилягають» або потребують постійних фіксів;
- якісь фічі потрібно час від часу докуповувати, щоб моніторити загалом ефективність доставки ваших email;
- служба підтримки така, що годі достукатися.
Питання наступне: як безболісно змінити email-сервіс? Адже у вас уже є розігрітий IP, репутація відправника, яка, як відомо, визначає ефективність потрапляння мейлів у скриньку, а не до спаму чи фільтрів. Що робити? Залишитися з проблематичним сервісом чи ризикнути репутацією відправника і домену, а, відповідно, і ефективністю email-доставки? Невже доведеться залишатись з ризикованим сервісом, аж поки якість стане зовсім неприпустимою?
Наша команда вже понад 15 років працює з email-інфраструктурами, тож про нюанси та проблеми цієї галузі ми знаємо з перших рук. Крім того, ми розширювали функціонал власної платформи доставки email, Mailtrap.io, і хотіли запропонувати клієнтам зручний та надійний спосіб міграції.
Наше основне завдання полягало у тому, щоб гарантувати клієнтам «переїзд» без втрати авторитету домену і репутації відправника. Для цього необхідно було ефективне технічне рішення.
Варіанти розв’язання проблеми: що ми пробували
Зміна поштового сервісу може фундаментально вплинути на низку технічних факторів. А значить, і зіпсувати оцінки листів, навіть якщо їхній зміст не змінився. Отже, «переїзд» — справа вкрай ризикована. Вихід такий — переносити пошту на нового провайдера поступово, починаючи з незначної частки загального обсягу. Але як це зробити технічно?
Спочатку ми випробували кілька варіантів розв’язання проблеми міграції між email-сервісами.
Proxy-сервер
Як це працює: проксі-сервер перекидає 99% з цих мейлів на попередній email-сервіс, а 1% відправляє.
Чому це все ж не дуже хороша ідея:
- ненадійність: складно обробити помилки, що виникають при відправці, треба якось агрегувати та перевіряти логи;
- проблема з безпекою — треба з проксі мати доступ до всіх email-сервісів, що використовуються. Плюс треба продумати якусь авторизацію для доступу до самого проксі.
Перекидання 99% мейлів «назад» до попереднього сервісу — сама по собі ненадійна практика для забезпечення високого рівня ефективності потрапляння мейлів саме до скриньки клієнта. До того ж є ризик небажаної зміни певних заголовків самим проксі-сервером.
Щодо безпеки, то торкатися коду і налаштувань попереднього сервісу доставки мейлів — не дуже безпечно і правильно. Адже таким чином ми виносимо налаштування відправки разом з безпекою назовні відносно основного застосунку. А отже, створюємо ще один шар між застосунком і кінцевим адресатом.
Тому варіант з проксі сервером ми відкинули як ненадійний.
Дописування коду вручну
Як це працює? Отримуєте доступ до коду клієнта і вручну дописуєте кілька рядків для розподілення потоків відправки листів. Щоб гарантувати ефективність доставки мейлів, необхідний поступовий перехід. Спочатку доставляти кожний
Через тиждень (оскільки усе працювало, як слід, і не вплинуло на репутацію відправника та авторитетність домену), уже перейшли на 5% відправки мейлів з новим сервісом. І так поступово збільшували відсоток.
Яка основна проблема з цим варіантом «переїзду»:
- кожного разу код потрібно було дописувати вручну у застосунку бізнес-клієнтів;
- це не зручно і не оптимізовано;
- доступ до коду не завжди можливий (якщо клієнт з різних міркувань безпеки його не хоче надавати повністю);
- треба мати доступ до клієнтського коду, а також щоразу зʼясовувати, як він працює.
Хочеш зробити добре — зроби сам
Зрештою, щоб оптимізувати процес «переїзду» і гарантувати високу ефективність доставки мейлів клієнтам бізнесів, ми створили власне рішення, ActionMailer Balancer (AMB). Під час його розробки нам важливо було врахувати наступне:
- Системність, надійність і ефективність email-доставки.
- Безпека. Робота напряму з вашим застосунком без додаткових інтеграцій, сервісів, плагінів чи ще чогось. Загалом, щоб процес відправки email майже не змінився.
- Проста інсталяція і конфігурація гема.
- Більший контроль над ефективністю доставки мейлів.
- Можливість обирати між сервісами доставки мейлів з найвищою ефективністю.
- Робота як зі спільними, так і з виділеними IP-адресами.
Наше рішення для RoR-застосунків дозволяє пропорційно розподіляти та збалансовувати потоки відправки листів між двома різними сервісами. При цьому зберігає репутацію відправника і не втрачає високого рівня ефективності доставки мейлів.
Специфіка ActionMailer така, що в ньому досить просто створити власний метод доставки, і так само просто можна викликати з одного методу доставки інший. Власне на цьому й базується робота AMB. Ми створюємо власний метод, в якому визначаємо, який з налаштованих методів маємо використати при доставці листа, і викликаємо саме його.
Так, наприклад, можна збалансувати відправку email наступним чином:
SendGrid 99% / Mailtrap 1%, або Postmark 60% / Mailgun 40%.
Балансер працює з будь-яким валідним методом доставки в ActionMailer, або вбудованим, або таким, який можна додати з бібліотеки.
Як це працює
Після інсталяції гему Балансера у ваш Ruby on Rails застосунок з функціоналом email-відправки та кількох нескладних конфігурацій, буде розширено метод відправки через ActionMailer.
Характерна особливість гему полягає в тому, що він сам збалансує і розподілить відсоток відправки між мейл-сервісами (той відсоток, який ви встановите, і між тими сервісами, які ви обрали) ще до власне виклику ActionMailer.
Наприклад, скажімо, ви використовуєте SendGrid як основний сервіс доставки електронної пошти. Потім бізнес приймає рішення (з правових, фінансових, географічних причин) мігрувати на Mailtrap. Ви не можете в один крок «переїхати». Тобто, звичайно, можете, але, швидше за все, ваші мейли будуть або відфільтровуватися, або потрапляти в спам, оскільки ваша репутація відправника просяде.
Отже, вам потрібно «мігрувати» поступово, крок за кроком, нарощуючи обсяг мейлів, які відправляються з новим email-сервісом. Ось тут Балансер і стає в пригоді як технічне рішення, яке дозволяє здійснити цей поступовий перехід.
У яких основних випадках необхідне балансування відправки мейлів
Будь-які випадки так чи інакше пов’язані зі зменшенням ризиків відправки email і підвищенням ефективності їхнього потрапляння у скриньку отримувачів.
- Для безпроблемного переходу з одного сервісу доставки листів на інший
Збереження авторитетності домену і репутації відправника, включно з автоматичним розігрівом ІР-адреси та поступовим графіком переключення розсилки, починаючи від 1% і далі.
- Для розподілу обсягів (не лімітів!) відправки електронних листів між двома email сервісами
Йдеться про збалансовану розсилку електронної пошти, розподілену за обсягами між двома обраними сервісами. Це технічне рішення не стосується лімітів відправки і не може розв’язувати їхню проблему.
- Для переключення з SMTP відправки на API
Процес міграції з одного технічного рішення для відправки мейлів на інше дуже схожий на процес переїзду з одного сервісу на інший. Потребує такої ж продуманої поступовості і графіку. Балансер допомагає вирішити та це питання технічно.
- Для створення можливості протестувати будь-який сервіс доставки мейлів на ринку без особливих ризиків
Іноді, обираючи сервіс відправки електронної пошти, ми не завжди враховуємо його сильні та слабкі сторони, і як вони корелюють з потребами бізнесу і нашими цілями. І обране рішення для відправки email може виявитися несумісним із завданнями розробників чи компанії. З Балансером можна спробувати інші email-сервіси, які існують на ринку, без будь-яких ризиків для основного методу доставки.
Як почати користуватися ActionMailer Balancer: покрокова інструкція
Встановіть Балансер. Це можна зробити двома способами:
- Якщо ви використовуєте
bundler
, додайте цей рядок до Gemfile застосункуgem 'actionmailer-balancer'
, потім запустіть$ bundle install
- Або ж, в іншому випадку, встановіть ось так: $ gem install actionmailer-balancer
Your::Application.configure do config.action_mailer.delivery_method = :balancer config.action_mailer.balancer_settings = { delivery_methods: [ { method: :mailtrap, settings: {api_key: ENV.fetch('MAILTRAP_API_KEY')}, weight: 10 } ] } end
Де settings — стандартні налаштування для вибраного методу відправки.
Власне, і все. Тепер користуйтесь ActionMailer, як і раніше до цього. Балансер сам розподілятиме обсяги розсилки мейлів.
Детальну інформацію щодо boilerplate можна глянути на ActionMailer Balancer Github page.
Замість висновків
ActionMailer Balancer підходить для проєктів, які працюють з Ruby on Rails. З ним можна переїжджати на нові мейл-сервіси доставки, експериментувати з ними, розподіляти обсяги email-розсилок між двома сервісами і загалом уникати ризиків з ефективністю доставки email, що очевидно важливо для кожного бізнесу, де доставка мейлів — це наріжний камінь спілкування з клієнтом.
Ще один важливий урок, який ми винесли зі створення AMB, — ідеї для продуктів можуть (і навіть мають) виникати з ваших особистих потреб і викликів та прагнень їх вирішувати.
Цілком вірогідно, що, створюючи рішення для однієї з ваших робочих проблем, ви зможете розробити щось, що допоможе тисячам колег в індустрії.
1 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів