Elastic Load Balancer & SSL терминация
Я настраиваю приложение Rails на AWS, которое: 1) весь трафик должен быть зашифрован ssl 2) будет сильно колебаться в объеме трафика еженедельно 3) будет поддерживаться кем-то, кто сильнее кодера, чем sysadmin
Я думаю, что завершение SSL на эластичном балансировщике нагрузки при поддержке небольших экземпляров ec2 под управлением nginx и единорога
Небольшое подмножество запросов займет больше 10 секунд, поэтому я также обсуждаю использование "thin" вместо "единорога".
У меня такой вопрос: это нормально? Я вступаю в трясину проблем с ценами, ремонтопригодностью, безопасностью или производительностью?
1 ответ
Больше, чем вменяемое или нет, если вы не являетесь системным администратором и позаботитесь об этом, вы станете системным администратором очень быстро. Вы до этого?:) Возможно, я здесь упускаю суть, но позвольте мне рассказать немного о своем опыте работы с рубиновым чуваком, играющим роль сисадмина на Амазонке:
Для работы на amazon нужно выполнить множество хитростей: - ELB (Elastic Load Balancer) на amazon - это всего лишь запись CNAME, поэтому вы не можете указать yourdomain.com на ELB, поэтому вам потребуется один веб-сервер с эластичным ip, чтобы иметь.htaccess или отражение или что-то еще, что переписать на nginx или единороге. Запланируйте это так, чтобы оно не откусило вас назад.
Что касается худого против единорога, то в данном случае это амазонская стратегия дизайна. Я никогда не использовал тонкие, но слышал хорошие мысли для длинного пула соединений кометного стиля. Амазон должен быть просто отлично для долгоживущих соединений, ИМХО. Если вы даже хотите стать более безопасным, вы можете использовать липкие куки, чтобы браузер клиента привязывался только к одному серверу.
"Я ступаю в болото стоимости?"
Да, это быстро становится дорогим на Амазонке.
"Я вступаю в трясину ремонтопригодности?"
И да и нет. Я привык иметь машины "с несколькими милями", где я мог пойти и сбросить или заменить жесткий диск. На amazon вам нужно быть готовым к тому, что одна из ваших машин устареет, и вам придется ее перезагрузить. Так что вам нужно планировать либо иметь сильный имидж и постоянно обновлять его, либо выбрать шеф-повара или кукольную штуку для управления вашими серверами (и сойти с ума, это так сложно настроить, это заняло у меня месяц, но я научился с 0)
"Я вступаю в болото производительности?"
Помните, что диск io далек от идеала, поэтому БД для записи замедляется, если ваша база данных выполняет много записи, определенно сделайте простую пробную версию, чтобы убедиться, что скорость достаточно хорошая. А также, вам придется использовать EBS для файлов базы данных.
Скорость процессора и память довольно хорошие. Я бы не волновался.
А также, я бы пошел на большие экземпляры, прежде чем перейти на горизонтальный уровень во многих небольших экземплярах, если только вы не планируете исчерпать порты из-за этих длинных соединений пула. Если вы хотите иметь лучшую производительность, дешевле масштабировать по вертикали, пока вы не нажмете на xlarge, вместо того, чтобы крутить тонны машин.
"Я вступаю в трясину ремонтопригодности?" --- снова
Если у вас есть тонна маленьких машин, вы хотите, чтобы машины поднимались и опускались, и это будет хлопотно.
Если вы хотите дружить с разработчиком, я бы пошел с EngineYard и проверил, можете ли вы развернуть их сервисом. Оно того стоит.
Пожалуйста, не стесняйтесь задавать вопросы!