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