Ssl offloading что это
Описание
Балансировка нагрузки с помощью FortiGate включает в себя все необходимые функции для распределения трафика между несколькими серверами в вашей инфраструктуре, развернутой в Selectel, включая как выделенные аппаратные серверы, так и виртуальные серверы в Облачной платформе Selectel.
FortiGate обеспечивает комплексную защиту вашей инфраструктуры и балансирует нагрузки серверов, распределяя потоки трафика по заданным правилам, что позволяет объединить в одном устройстве функции балансировщика нагрузки, Next Generation Firewall (NGFW) и защиту от угроз.
Балансировка нагрузки на основе решений FortiGate обеспечивает:
Балансировщик нагрузки поддерживает HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL или более низкоуровневые протоколы TCP/UDP или IP. Сохранение сеанса поддерживается на основе идентификатора сеанса SSL или на основе введенного файла cookie HTTP. 
Перед началом работы
Прежде чем настраивать балансировку нагрузки в графическом интерфейсе, включите отображение специального раздела настроек:
В данном примере будут рассмотрены настройки Load Balancing для HTTP и HTTPS на аппаратном FortiGate-100E, первоначальную базовую настройку которого можно провести согласно инструкциям по настройке межсетевых экранов. В качестве серверов используются облачные серверы в Облачной платформе Selectel.
FortiGate и проект в Облачной платформе соединены приватной сетью, для подключения которой используется L3VPN между регионами и услугами, что позволяет устанавливать за межсетевым экраном также выделенные серверы и серверы в Облаке на базе VMware.
Термины и определения
Методы балансировки нагрузки
Трафик может распределяться между серверами на основе методов:
Health Check
Health Check — механизм проверки работоспособности серверов для предотвращения отправки трафика балансировки нагрузки на неработающие серверы. Для проверки используется ICMP ping или другое более сложное тестирование TCP-соединений. Health Check удаляет из кластера балансировки нагрузки неработающие реальные серверы. Удаление реальных серверов из кластеров основано на настройках:
Типы Health Check по протоколам: TCP, HTTP, PING.
Virtual Server
Virtual Server — виртуальный сервер, на чей внешний IP-адрес поступает трафик, который перенаправляется к балансировщику нагрузки.
Real Server
Real Server — действительный, реальный, сервер, на который поступают запросы после балансировки. За каждым виртуальным сервером может быть закреплено несколько реальных серверов. Конфигурация реального сервера включает IP-адрес и номер порта, на котором реальный сервер принимает сеансы. Устройство FortiGate отправляет сеансы на IP-адрес реального сервера, используя номер порта назначения в реальной конфигурации сервера. Конфигурация сервера включает его IP-адрес и номер порта, на котором принимает сеансы.
SSL Offloading
SSL Offloading — механизм ускорения SSL-соединения клиентов с сервером, при котором операции шифрования производятся на FortiGate вместо самих серверов с помощью отдельного специального процессора. Данный механизм можно применить, только если для балансировки нагрузки задан тип одного из протоколов SSL (HTTPS, IMAPS, POP3S, SMTPS, SSL). FortiGate предоставляет возможность выбрать, какие сегменты SSL-соединения будут получать разгрузку SSL, определив режим:
HTTP multiplexing
HTTP multiplexing — функция, которая позволяет веб-клиенту использовать одно соединение TCP для всех запросов к серверу. Данная особенность снижает нагрузку на веб-сервер за счет установки единого соединения, по которому параллельно отправляются запросы и ответы. Каждый фрагмент ассоциируются с помощью специальных встроенных мета-данных, что обеспечивает возможность корректной обработки множества несвязанных запросов HTTP или HTTPS в различном порядке в одном и том же соединении. Более того, ответы получаются по мере их готовности, следовательно, тяжелые запросы не будут блокировать обработку и выдачу более простых объектов.
Например, если веб-браузеры пользователей совместимы только с HTTP 1.0, в котором данная функция не реализована, то включение опции HTTP multiplexing может повысить производительность между веб-сервером и FortiGate.
Persistence
Persistence — параметр, который сохраняет и отслеживает данные сеанса, чтобы убедиться, что пользователь подключается к одному и тому же серверу каждый раз, когда он делает запрос, являющийся частью одного и того же сеанса или последующих сеансов. HTTP cookie persistence использует внедренные файлы cookie для обеспечения сохраняемости.
При настройке Persistence FortiGate балансирует нагрузку нового сеанса на реальный сервер в соответствии с методом балансировки нагрузки. Если у сеанса есть HTTP cookie или идентификатор сеанса SSL, устройство FortiGate отправляет все последующие сеансы с одним и тем же файлом cookie HTTP или идентификатором сеанса SSL на один и тот же реальный сервер.
SSL/TLS Offloading, Encryption, and Certificates with NGINX and NGINX Plus
NGINX and NGINX Plus provide a number of features that enable it to handle most SSL/TLS requirements. They use OpenSSL and the power of standard processor chips to provide cost‑effective SSL/TLS performance. As the power of standard processor chips continues to increase and as chip vendors add cryptographic acceleration support, the cost advantage of using standard processor chips over specialized SSL/TLS chips also continues to widen.
Decrypting HTTPS traffic on NGINX brings many benefits
There are three major use cases for NGINX and NGINX Plus with SSL/TLS.
SSL/TLS Offloading
When NGINX is used as a proxy, it can offload the SSL decryption processing from backend servers. There are a number of advantages of doing decryption at the proxy:
For more details, see NGINX SSL Termination in the NGINX Plus Admin Guide.
SSL/TLS Encryption to the Origin Servers
There are times you might need NGINX to encrypt traffic that it sends to backend servers. These requests can arrive at the NGINX server as plain text or as encrypted traffic that NGINX must decrypt in order to make a routing decision. Using a pool of keepalive connections to the backend servers minimizes the number of SSL/TLS handshakes and thus maximizes SSL/TLS performance. This is achieved very simply by configuring NGINX to proxy to “https” so that it automatically encrypts traffic that is not already encrypted.
End-to-End Encryption
Because NGINX can do both decryption and encryption, you can achieve end‑to‑end encryption of all requests with NGINX still making Layer 7 routing decisions. In this case the clients communicate with NGINX over HTTPS, and it decrypts the requests and then re‑encrypts them before sending them to the backend servers. This can be desirable when the proxy server is not collocated in a data center with the backend servers. As more and more servers are being moved to the cloud, it is becoming more necessary to use HTTPS between a proxy and backend servers.
Client Certificates
NGINX can handle SSL/TLS client certificates and can be configured to make them optional or required. Client certificates are a way of restricting access to your systems to only pre‑approved clients without requiring a password, and you can control the certificates by adding revoked certificates to a certificate revocation list (CRL), which NGINX checks to determine whether a client certificate is still valid.
Additional Security Features
There are number of other features that help support these use cases, including (but not limited to) the following:
For a more details, check out these resources:
Examples
Here are a few examples of NGINX’s security features. These examples assume a basic understanding of NGINX configuration.
The following configuration handles HTTP traffic for www.example.com and proxies it to an upstream group:
Now add HTTPS support, so that NGINX decrypts the traffic using the certificate and private key and communicates with the backend servers over HTTP:
Or if you instead receive traffic over HTTP and send it to the backend servers over HTTPS:
To try NGINX Plus, start your free 30-day trial today or contact us to discuss your use cases.
Learn how to protect your apps with NGINX and NGINX Plus
SSL Offloading
SSL Offloading Definition
SSL offloading is the process of removing the SSL based encryption from incoming traffic that a web server receives to relieve it from decryption of data. Security Socket Layer (SSL) is a protocol that ensures the security of HTTP traffic and HTTP requests on the internet. SSL traffic can be compute intensive since it requires encryption and decryption of traffic. SSL (called TLS or Transport Layer Security now) relies on public key cryptography to encrypt communications between the client and server sending messages safely across networks. Encryption of sensitive information protects against potential hackers and man-in-the-middle attacks.
FAQs
What is SSL Offloading?
SSL is a cryptographic procedure that secures communications over the internet. SSL encoding ensures user communications are secure. The encryption and decryption of SSL are CPU intensive and can put a strain on server resources. In order to balance the compute demands of SSL encryption and decryption of traffic sent via SSL connections, SSL offloading moves that processing to a dedicated server. This frees the web server to handle other application delivery demands.
How does SSL Offloading Work?
SSL offloading relieves a web server of the processing burden of encrypting and decrypting traffic sent via SSL. Every web browser is compatible with SSL security protocol, making SSL traffic common. The processing is offloaded to a separate server designed specifically to perform SSL acceleration or SSL termination. SSL certificates use cryptography keys for encryption. RSA keys of increasing key lengths (e.g. 1024 bits and 2048 bits) were the most common cryptography keys until a few years ago. But more efficient ECC (Elliptic Curve Cryptography) keys of shorter key lengths are replacing the RSA keys as the mechanism to encrypt traffic.
How to Configure SSL Offloading?
To configure SSL offloading, organizations enable routing of SSL requests to an application delivery controller that intercepts SSL traffic, decrypts the traffic, and forwards it to a web server. In SSL offloading, importing a valid certificate and key and binding them to the web server are important to ensure correct exchange of unencrypted traffic.
What is SSL Offloading in a Load Balancer?
SSL offloading on a load balancer is now a required capability and these load balancers also referred to as SSL load balancer. This is a load balancer that has the ability to encrypt and decrypt data transported via HTTPS, which uses the SSL protocol to secure data across the network.
Does Avi Offer SSL Offloading?
Yes, Avi Vantage provides SSL offloading of encrypted traffic that uses RSA 2K keys as well as those that use ECC keys. Avi Vantage delivers high performance for SSL offloading, as well as a number of enterprise-grade features to help understand the health of SSL traffic including alerting on incorrect versions and to troubleshoot SSL-related issues.
For more information on ssl offloading see the following resources:
SSL Offloading: What is it? How does it work? What are the benefits?
What is SSL Offloading? Performing SSL at the Load Balancer level.
Today we’re going to cover a question that comes up from time to time, and may seem especially foreign to people without an IT background: What is SSL offloading? We’ll give a quick overview of what SSL offloading means, why you may want to do it and whether you should.
One of the misnomers about SSL/TLS and really with the way the internet works in general is that it’s a 1:1 connection. A person’s computer connects directly with a web server and communication goes directly from one to the other. In reality, it’s far more complicated than that, with sometimes upwards of a dozen stops between end points.
That’s an important piece of information to keep in mind as we start getting into SSL offloading.
So, what is SSL offloading and how does it work?
What is SSL offloading?
Before TLS 1.3, even before TLS 1.2, frankly, SSL/TLS used to legitimately add latency to connections. That’s what lent itself to the perception that SSL/TLS slowed down websites. Ten years ago, that was the knock on SSL certificates. “Oh they slow down your site.” And that was true at the time.
It’s not today, but in the past SSL/TLS was considered a bit resource hungry. For starters, you have the SSL/TLS handshake. It’s been refined to where it’s now a single roundtrip in TLS 1.3, but before that it took several roundtrips. Then, following the handshake, additional processing power had to be exerted to encrypt and decrypt the data being transmitted. As the additional load from SSL/TLS increases on the server, it’s no longer able to process at full capacity.
Again, a lot of this has been cleaned up in TLS 1.3, and HTTP/2 – which requires the use of SSL/TLS – helps to increase performance even more, but even with all of those improvements, SSL/TLS can still add latency with higher volumes of traffic.
So, what is SSL offloading? Well, to help offset the extra burden SSL/TLS adds, you can spin up separate Application-Specific Integrated Circuit (ASIC) processers that are limited to just performing the functions required for SSL/TLS, namely the handshake and the encryption/decryption. This frees up processing power for the intended application or website. That’s SSL offloading in a nutshell. Sometimes it’s also called load balancing. You may hear the term load balancer tossed around. A load balancer is any device that helps improve the distribution of workloads across multiple resources, for instance distributing the SSL/TLS workload to ASIC processors.
What are the advantages of SSL offloading?
SSL offloading has several benefits:
That last one is one of the most important: that in some cases SSL offloading can assist with traffic inspection. As important as encryption is, it has one major drawback: attackers can hide in your encrypted traffic. There’s no shortage of high-profile exploits that have occurred as a result of attackers hiding in HTTPS traffic, recently Magecart has been using HTTPS traffic to obfuscate the PCI it’s been exfiltrating from various payment pages.
Being able to inspect HTTPS traffic becomes almost compulsory once your organization reaches a certain size, and one of the best ways to do that is to offload your SSL/TLS processes.
How does SSL offloading work?
When we talk about SSL offloading there are two different ways to accomplish it:
Let’s start with SSL termination first because it’s a little bit simpler. Essentially it works this way, the proxy server or load balancer you use for the SSL offloading acts as the SSL terminator, which also acts as an edge device. When a client attempts to connect to a website, the client connects to the SSL terminator—that connection is HTTPS. But the connection between the SSL terminator and the application server is via HTTP.
Now, you may be asking how that doesn’t cause problems with the browser, it’s because the HTTP connection is taking place behind the scenes – on the internal network, protected by firewalls – the client still has a secure connection with the SSL terminator, which is acting as a pass-through.
Here’s a visualization of SSL Termination:
SSL Bridging is extremely similar conceptually, except rather than sending the traffic and requests on via HTTP, it re-encrypts everything before sending it to the application server.
Here’s a visualization of SSL Bridging:
Both allow you to perform traffic inspection and can help tremendously when you’re dealing with high volumes of traffic on larger networks.
Bear in mind, encryption is an incredibly CPU-intensive task. When the industry migrated from 1024-bit RSA keys to 2048-bit ones, the CPU-usage involved increased somewhere between 4-7 times depending on server. We’ll likely never even get to 4096-bit keys because frankly, at that point the increase in cpu-usage isn’t consummate to the improvement in security. That’s why we’re seeing a push towards more elliptic curve-based cryptosystems.
So let’s cover one last item: should you consider SSL offloading?
And frankly, that all comes down to you, your website and what you’re trying to do. A large media site like an ESPN or a CNN would be well-suited to use a load balancer owing to the volume of traffic they both handle. On the other hand, if you’re just running a website for a local bakery, you’d probably be fine just letting your server handle everything—especially with the improvements made by TLS 1.3.
That’s all for today, as always, leave any comments or questions below.
Сравнение решений по балансировке высоконагруженных систем
И вновь мы публикуем расшифровки выступлений с конференции HighLoad++, которая прошла в подмосковном Сколково 7—8 ноября 2016 года. Сегодня Евгений Пивень знакомит нас с решениями балансировки в облаках.
Меня зовут Женя, я работаю в компании IPONWEB. Сегодня мы поговорим про развитие наших решений в балансировке высоконагруженных систем.
Сначала я пробегусь по понятиям, которыми буду оперировать. Начнём с того чем мы занимается: RTB, Real Time Bidding — показ рекламы с аукционом в реальном времени. Очень упрощенная схема того, что происходит, когда вы заходите на сайт:
Для того, чтобы показать рекламу, идет запрос на RTB-сервер, который запрашивает у рекламных серверов их ставки и потом решает, какую рекламу вам показать.
Особенности IPONWEB
У нас вся инфраструктура в облаках. Мы очень активно пользуемся Amazon и GCE, у нас несколько тысяч серверов. Главная причина, по которой мы полностью живем в облаках, — это скалируемость, то есть у нас реально часто нужно добавлять/удалять инстансы, иногда очень много.
У нас есть миллионы запросов в секунду, все эти запросы HTTP. Это может быть не до конца применимо к остальным протоколам. У нас очень короткие ответы. Может быть, и не очень, я думаю, в среднем от одного до несколько килобайт ответы. Мы не оперируем какими-то большими объемами информации, просто очень большим их количеством.
Для нас не актуально кэширование. Мы не поддерживаем CDN. Если нашим клиентам нужны CDN, то они сами занимаются этими решениями. У нас есть очень сильные суточные и событийные колебания. Они проявляются во время праздников, спортивных событий, каких-то сезонных скидок и т. д. Суточные можно хорошо посмотреть на таком графике:
Красный график — обычный стандартный график в европейской стране, а синий график — это Япония. На этом графике мы видим, что каждый день примерно в двенадцать у нас есть резкий скачок, и примерно в час трафик резко падает. Связано это с тем, что люди уходят на обед, и как очень порядочные японские граждане они пользуются интернетом активно больше всего на обеде. Такое очень хорошо видно на этом графике.
У нас есть большой разброс пользователей по всему миру. Это — вторая большая причина, почему мы пользуемся облаками. Нам очень важно отдать ответ быстро, и если сервера находятся в каких-то других регионах от пользователей, то часто это неприемлемо для RTB-реалий.
И у нас есть чёткое разграничение серверного и пользовательского трафика. Вернёмся к той схеме, которую я показал на первом слайде. Для простоты всё то, что приходит от пользователя до первичного RTB-сервера — это пользовательский трафик, все то что происходит за ним — это серверный трафик.
Зачем балансировать?
Две главные причины — это масштабируемость и доступность сервисов.
Масштабируемость — это когда мы добавляем новые сервера, когда мы из одного сервера, который уже не может справиться, вырастаем как минимум до двух, и между ними надо как-то раскидывать запросы. Доступность — это когда мы боимся, что с этим одним сервером что-то случится. Опять же нужно добавить второй, чтобы между ними как-то всё это балансировать и распределять запросы только по тем серверам, которые могут на них ответить.
Что ещё часто требуется от балансировщиков? Эти функции, естественно, для целей каждого приложения могут быть разными. Для нас больше всего актуально SSL Offload. Как это работает, показано здесь.
От пользователя до балансировщика идёт трафик, который зашифрован. Балансировщик расшифровывает его, раскидывает по бэкендам уже расшифрованный HTTP-трафик. Потом балансировщик обратно зашифровывает его и отдает пользователю опять в зашифрованном виде.
Ещё нам очень важна такая штука, как Sticky-балансировка, которую часто называют session affinity.
Почему для нас это актуально? Когда мы видим несколько слотов для рекламы на странице, мы хотим, чтобы при открытии этой страницы все запросы пришли сразу на один бэкенд. Почему это важно? Есть такая особенность как roadblock. Она означает, что если мы показали в одном из слотов баннер, например, Pepsi, то в другом мы не можем показать баннер той же самой Pepsi или Coca-Cola, потому что это конфликтующие баннеры.
Нам нужно понимать, какие баннеры мы показываем в данный момент пользователю. При балансировке нам нужно удостовериться, что пользователь пришел на один бэкенд. На этом бэкенде у нас создается некое подобие сессии, и мы понимаем, какие именно рекламы можно показать этому пользователю.
Также у нас есть Fallback. На примере сверху виден баннер, на котором он не работает, а справа — баннер, на котором он работает.
Fallback — это ситуация, когда по каким-то причинам бэкенд не справляется, и дабы не сломать страницу пользователю, мы отдаем ему обычно совсем пустой пиксель. Здесь я его нарисовал большим зеленым прямоугольником для понимания, но на самом деле обычно это просто маленькая гифка, двухсотый HTTP Response и правильный набор header’ов, чтобы у нас не сломалось ничего в верстке.
Так у нас выглядит нормальная балансировка.
Синяя жирная линия — это сумма всех запросов. Эти маленькие линии, много-много, — это идут запросы на каждый инстанс. Как мы видим, тут балансировка достаточно хорошая: практически все они идут почти одинаково, сливаясь в одну линию.
Это — балансировка курильщика. Здесь что-то пошло не так.
Проблема — на стороне Amazon. Подобное, кстати, произошло совсем недавно, буквально две недели назад. С амазоновских балансеров трафик стал приходить в таком виде.
Стоит сказать, что метрики — это хорошо. Здесь Amazon до сих пор не верит нам, что у нас происходит что-то плохое. Они видят только вот этот общий график, в котором видно лишь сумму запросов, но не видно, сколько запросов приходит по инстансам. До сих пор с ними боремся, пытаемся им доказать, что что-то с их балансировщиком идет не так.
Балансировка DNS
Итак, про балансировку я расскажу на примере одного из наших проектов. Начнем собственно с самого начала. Проект был молодой, мы примерно около начала этого проекта.
Большая часть трафика в этом проекте — серверный. Особенность работы с серверным трафиком: мы можем легко решать некоторые проблемы. Если у нас есть специфика у одного из наших клиентов, то мы можем как-то договориться с ним, чтобы они что-то поменяли на своем конце, как-то обновили свои системы, что-то еще сделали, чтобы у нас лучше работало с ними. Можно выделить их в отдельный пул: мы можем просто взять одного клиента, у которого есть какая-то проблема, привязать его к другому пулу и решить проблему локально. Либо, в совсем тяжелых случаях, можно даже его забанить.
Первое, чем мы начали пользоваться, — это была обычная DNS-балансировка.
Пользуемся Round-robin DNS-пулами.
Каждый раз при запросе на DNS, пул ротируется, и сверху оказывается новый IP-адрес. Таким образом работает балансировка.
Проблемы обычного Round-Robin DNS:
Балансировка gdnsd
На помощь приходит gdnsd – это DNS сервер, который многие, наверное, знают, которым мы активно пользуемся и сейчас.
Через какой-то промежуток времени мы сталкиваемся с проблемой 512 байт.
Проблема 512 байт — это проблема практически всех DNS-серверов. Изначально, когда DNS только проектировался, максимальный MTU у модемов был 576 байт. Это 512 байт + 64 длины заголовка. Пакеты от DNS исторически не отсылают больше чем 576 байт по UDP. Если у нас пул длиннее, чем 512 байт, то мы отсылаем только часть пула, включаем в нем флаг truncated. Потом уже от клиента приходит запрос по TCP, переспрашивая нас опять это пул. И тогда мы присылаем ему полный пул, теперь уже по TCP.
Эта проблема была только у части наших клиентов, примерно у 15%. Мы смогли выделить их отдельно в пул и использовать для них weighted-пулы в gdnsd.
Бонус weighted-пулов в этом случае — их можно разбивать. Если у нас, скажем, 100 серверов, мы их разбиваем на 5 частей. Мы отдаем на каждый запрос один из этих маленьких подпулов, в которых всего 20 серверов. И Round-robin проходит по этим маленьким пулам, каждый раз он выдает новый пул. Внутри самого пулa тоже используется Round-Robin: он шаффлит эти айпишники и каждый раз выдает новые.
Веса gdnsd можно использовать помимо этого для, например, staging серверов. Если у вас есть более слабый инстанс, вы на него можете изначально отсылать гораздо меньше трафика и проверять, что что-то там сломалось, только на нём, отсылая на него достаточно маленький набор трафика. Или если у вас есть разные типы инстансов, либо вы используете разные сервера. (Я часто говорю «инстансы» потому что у нас всё в облаках, но для вашего конкретного случая это может быть не так.) То есть вы можете использовать разные типы серверов и с помощью gdnsd слать на них больше или меньше трафика.
Тут у нас тоже возникает проблема — DNS-кэширование. Часто, когда идет запрос этого пула, мы отдаем только маленький пул, и этот пул кэшируется. С этим пулом у нас продолжает жить какой-то клиент, не переспрашивая наш DNS. Такое случается, когда DNS-клиент плохо себя ведет, не придерживается TTL и работает только с маленьким ограниченным набором IP-адресов, не обновляя его. Если он получил изначально полный лист по TCP, это нормально. Но если он получил только маленький пул, который weighted, то это может быть проблемой.
Через какое-то время мы сталкиваемся с новой проблемой.
Те оставшиеся 85% серверного трафика всё ещё пользуются обычными мультифопулами, как это называется в gdnsd. С некоторыми из них начинаются проблемы.
Мы поняли, что проблема происходит только у амазоновских DNS. То есть у тех наших клиентов, которые сами хостятся в Amazon, при ресолве пула, в котором находится больше 253 хостов, им просто приходит ошибка NXDOMAIN, и они полностью не ресолвят этот целый пул.
Это произошло тогда, когда мы добавили около 20 хостов, и у нас их стало 270. Мы локализовали число до 253, мы поняли, что на этом количестве становится проблемно. Сейчас эту проблему уже починили. Но на тот момент мы поняли, что топчемся на месте, и надо как-то эту проблему решать дальше.
Так как мы находимся в облаках, первое, о чем мы подумали, — попробовать вертикальное масштабирование. Оно сработало, соответственно, мы сократили количество инстансов. Но опять же, это временное решение проблемы.
Мы решили попробовать что-то еще, тогда выбор пал на ELB.
ELB – это Elastic Load Balancing, решение от Amazon, которое балансирует трафик. Как это работает?
Они предоставляют вам CNAME, в данном случае это вот эта страшная строчка под www.site.com : elb, цифры, регион и так далее. И этот CNAME ресолвится на несколько внутренних айпишников инстансов, которые балансируют на наши бэкенды. В таком случае нам нужно всего один раз привязать их CNAME в нашем DNS к нашему пулу. Потом мы уже добавляем в группу серверы, на которые раскидывают балансировщики.
ELB умеет SSL Offload, к нему можно прицепить сертификат. Также он умеет HTTP status checks, чтобы понимать, насколько живые у нас инстансы.
Мы практически сразу стали сталкиваться с проблемами с ELB. Есть так называемый прогрев балансировщиков ELB. Это нужно, когда вы хотите пускать больше 20—30 тысяч запросов в секунду. Прежде чем перевести весь ваш трафик на ELB, вам нужно написать письмо в Amazon, сказать, что мы хотим пустить много трафика. Вам присылают письмо с кучей страшных вопросов про характеристики вашего трафика, сколько, когда, как долго вы собираетесь это всё поддерживать. Затем они добавляют новых инстансов в свой пул и готовы к наплыву трафика.
И даже при предварительном прогреве мы столкнулись с проблемой. Когда мы у них запросили 40 тысяч запросов в секунду, примерно на 30 тысячах у них все сломалось. Нам пришлось все это дело быстро откатывать.
Ещё у них есть балансировка по скорости ответов. Это алгоритм работы амазоновского балансировщика. Он смотрит насколько быстро ваши бэкенды отвечают. Если он видит, что быстро, то шлет туда больше трафика.
Проблема здесь в чем? Если ваш бэкенд отчаянно пятисотит [выдаёт код состояния HTTP 5XX, что говорит об ошибке сервера] и не справляется, то балансировщик думает, что бэкэнд очень быстро отдает ответы, и начинает слать ему ещё больше трафика, загибая ваш бэкэнд ещё сильнее. В наших реалиях это ещё проблемнее, потому что мы, как я уже рассказывал, обычно отсылаем 200-ый ответ, даже если всё плохо. Пользователь не должен видеть ошибку — просто посылаем пустой пиксель. То есть для нас эту проблему решить ещё сложнее.
На последней конференции Amazon они рассказывали, что если у вас что-то плохое происходит, то в exception’ы заворачивайте какие-нибудь таймауты по 100-200 мс, искусственно замедляя 500-ые ответы, чтобы амазоновской балансировщик понимал, что ваш бэкенд не справляется. Но вообще, по-хорошему надо делать правильные status checks. Тогда ваш бэкенд понимал бы, что есть проблемы, и отдавал бы на status checks проверки проблему, и его просто выкидывало бы из пула.
Теперь у Amazon появилось новое решение: Application Load Balancer (ALB). Это довольно интересное решение, но нам оно не сильно актуально, потому что оно для нас ничего не решает и скорее всего будет стоить гораздо больше. Их система с хостами стала сложнее.
Есть поддержка WebSocket, HTTP/2 и контейнеров. Если у вас Docker внутри одного инстанса, то он может распределять между ними.
В Google мы пользуемся GLB. Это довольно интересное решение. По сравнению с Amazon, у него есть много преимуществ.
Первое — у нас всего 1 IP. Когда вы создаете балансировщик в Google, вам даётся единственный айпишник, который вы можете привязать к своему сайту. Это значит, что вы можете привязать его даже к «голому» домену. CNAME же можно привязать к домену второго уровня.
Вам нужно создать всего один балансировщик по всем регионам. То есть в Amazon нам нужно в каждом регионе создавать по балансировщику, чтобы балансировать между инстансами внутри этого региона, а в Google — всего один балансировщик, всего один один IP, и он балансирует между всеми вашими инстансами по разным регионам.
Гугловский балансировщик умеет Sticky и по IP, и по cookie. Я рассказывал, зачем нужен Sticky — нам нужно одного пользователя переслать на один бэкэнд. Амазоновские балансировщики умеют только по cookie, то есть они сами на уровне балансировщика выдают cookie. Потом его проверяют, и если видно, что у пользователя cookie, соответствующий одному из инстансов, его отсылают на тот же самый. Гугловский умеет IP, что нам гораздо лучше, хоть и не всегда решает все проблемы.
У балансировщика Google есть Instant warm-up: его не надо никак прогревать, на него сразу можно отсылать до миллиона запросов. Миллион запросов — это то, что они обещают сами точно, и то, что я сам проверял. Думаю, дальше они растут как-то сами внутри.
Но при этом у них есть проблема с резким изменением числа бэкендов. В какой-то момент мы добавили около 100 новых хостов. На этом этапе гугловский балансировщик загнулся. Когда мы стали общаться с инженером из Google, они сказали: добавляйте по одному в минуту, тогда будет вам счастье.
Также недавно в их HTTP-балансировщике подрезали порты, которыми вы можете пользоваться при создании балансировщика. Раньше было обычное поле для ввода, сейчас можно выбрать только между 80 и 8080 портами. Для кого-то это может быть проблемой.
Ни у одного из этих облачных балансировщиков нет поддержки SNI. Если вам нужно поддерживать несколько доменов и несколько сертификатов, то вам нужно на каждый сертификат создавать по отдельному балансировщику и к нему привязывать. Это решаемая проблема, но такая ситуация может быть неудобной.