Czy powinienem używać AWS Elastic Beanstalk lub Amazon EC2 Container Service (ECS) do skalowania kontenerów Docker?

81

Opracowałem aplikację opartą na platformie Docker składającą się z wielu mikrousług. Musi konsumować wiadomości Amazon SQS i je przetwarzać. Na początku chciałem skorzystać z AWS Elastic Beanstalk, ale potem przewróciłem się o usługę EC2 Container Service. Teraz nie wiem, który wybrać.

Obecnie Elastic Beanstalk obsługuje środowiska wielopojemnikowe. To świetnie, ponieważ każda mikrousługa ma własny serwer aplikacji w kontenerze Dockera. Następnym problemem jest skalowanie:

Nie wiem, jak działa mechanizm skalowania. Na przykład: mam 5 kontenerów docker w moim środowisku Elastic Beanstalk. Teraz tylko piąty kontener docker jest mocno obciążony, ponieważ ma ogromną liczbę komunikatów SQS do przetworzenia, pozostałe cztery są prawie bezczynne, ponieważ nie potrzebują dużo procesora lub może nie mają wielu komunikatów SQS. Załóżmy, że w piątym kontenerze działa serwer aplikacji JBoss. O ile wiem, serwer może zużywać ograniczoną liczbę równoległych żądań, nawet jeśli jest wystarczająco dużo procesora / pamięci.

Jeśli kontener JBoss Docker nie jest w stanie obsłużyć ilości żądań, ale jest wystarczająco dużo procesora / pamięci, oczywiście chcę automatycznie uruchomić drugi kontener Docker / JBoss na tej samej instancji. Ale co się stanie, jeśli nie mam wystarczającej ilości procesora / pamięci? Oczywiście chcę obrócić w drugiej instancji, którą można skonfigurować za pomocą grupy autoskalowania w EB. Teraz kręci się druga instancja, ale każdy pojemnik z wyjątkiem piątego jest prawie bezczynny, oczywiście nie chcę, aby w drugiej instancji pojawiały się 4 niepotrzebne, co byłoby marnowaniem zasobów. Tylko piąta powinna się pojawić, a pozostałe powinny skalować się jak piąta skala w oparciu o konfigurowalne parametry, takie jak np .: procesor / pamięć / SQS.

Nie wiem dokładnie, czy Amazon ECS to robi, czy w ogóle jest to możliwe, ale naprawdę nie mogę znaleźć w Internecie żadnego źródła na ten temat, czyli ogólnie rzecz biorąc, skalowanie oparte na instancjach / kontenerach.

orbatschow
źródło
Czy uważasz, że Twój problem został rozwiązany? Mam bardzo podobne obawy co do EB, podejrzewam, że uruchomi wszystkie 5 kontenerów w osobnej instancji
Cameron Singe
3
Ja też jestem zdezorientowany. Wybrana odpowiedź tak naprawdę nie wyjaśnia, jak działa skalowanie w obu usługach. Również czy ECS / EB naprawdę wykopuje kolejny piąty kontener, a następnie działa równolegle w tej samej instancji, jeśli jest wystarczająco dużo zasobów?
codepushr

Odpowiedzi:

69

EB vs ECS naprawdę sprowadza się do kontroli. Czy chcesz kontrolować skalowanie i pojemność, czy też chcesz, aby to było bardziej abstrakcyjne i zamiast tego skupić się głównie na aplikacji. ECS da Ci kontrolę, ponieważ musisz określić rozmiar i liczbę węzłów w klastrze oraz określić, czy powinno być używane automatyczne skalowanie. Dzięki EB po prostu udostępniasz plik Dockerfile, a EB zajmuje się skalowaniem aprowizacji liczby i rozmiaru węzłów, w zasadzie można zapomnieć o infrastrukturze z trasą EB.

Oto dokumentacja EB na Docker: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html

Dzięki ECS będziesz musiał najpierw zbudować infrastrukturę, zanim zaczniesz wdrażać plik Dockerfile, więc tak naprawdę sprowadza się to do 1) znajomości infrastruktury i 2) poziomu wysiłku, jaki chcesz poświęcić na infrastrukturę w porównaniu z aplikacją.

alanwill
źródło
7
Tak, ale jak działa mechanizm automatycznego skalowania obu usług, czy Elastic Beanstalk skaluje kontenery według kontenera, więc jeśli tylko jeden jest pod obciążeniem, skaluje tylko ten jeden, czy też zawsze skaluje instancje i uruchamia wszystko kontenery, bez względu na to, pod jakim obciążeniem są?
orbatschow
6
Teraz, gdy ECS jest GA, EB wykorzystuje ECS do zapewnienia swojej infrastruktury wielokontenerowej. Automatyczne skalowanie jest wykonywane przy użyciu typowego prymitywu grupowego automatycznego skalowania EC2. Czynnikiem wyzwalającym skalowanie w górę lub w dół nie jest kontener, ale węzeł wystąpienia. To znaczy, jeśli ruch w interfejsie sieciowym lub obciążenie procesora lub dysku osiągnie określony próg, wówczas klaster można skalować w poziomie lub w dół. W naszym przykładzie, jeśli węzeł 5. kontenera był mocno obciążony procesorem, można ustawić wyzwalacz grupy automatycznego skalowania na podstawie Na tym.
alanwill
Pamiętaj również, że możesz pozostać przy bardziej kontrolowanym podejściu ECS zorientowanym na kontener i odroczyć odpowiedzialność za kontrolę klastra za pomocą AWS Fargate .
dmulter
A co z cenami? Czy to jest inne?
Daniel Vilela
12

Nie po to, żeby wskrzesić martwe pytanie, ale miejmy nadzieję, że to komuś pomoże.

Przyjęta odpowiedź nie jest wystarczająco jasna: na podstawie tego, co opisano w OP, OP chce ECS, a nie Multi-Container Elastic Beanstalk (MCEB). O ile wiem, MCEB nigdy nie próbuje efektywnie pakować kontenerów w instancje. OP pyta w komentarzu „jeśli tylko jeden jest pod obciążeniem, skaluje tylko ten, czy też zawsze skaluje instancje i uruchamia wszystkie kontenery, bez względu na to, pod jakim są obciążeniem?” Odpowiedź brzmi: „to drugie”; MCEB skaluje instancje i uruchamia wszystkie kontenery, niezależnie od obciążenia, pod jakim się znajdują.

Edytować

Nie używaj architektury, którą sobie wyobrażasz.

Jak mikro są Twoje mikroserwisy? Czy byłoby śmieszne dać im t2.nano? Następnie utwórz z nich pojedynczą aplikację Docker EB - aplikacje robocze EB mogą być obsługiwane przez komunikaty SQS. Lub użyj apex.run .

Edycja 31.01.18:

AWS Fargate wydaje się całkiem fajne.

Edycja 05.06.19:

Użyj EKS, jeśli chcesz zaaranżować pojemniki, aby zaspokoić swędzenie. Ale naprawdę staraj się tego unikać. Systemy rozproszone są trudne.

Sam H.
źródło
1
Robi dokładnie to. Dla nas to nie jest duży problem, ponieważ tworzymy nasze aplikacje w sposób stosowy, w którym zwykle jest w porządku, aby były skalowane razem. Jeśli jest to potrzebne do niezależnego skalowania aplikacji, powiedziałbym, że powinna to być inna aplikacja na EB. Naprawdę bardzo się staram wymyślić dobry scenariusz, w którym jest to potrzebne. Czytałem wiele przypadków osób wyrażających to pragnienie i nie mogę zdecydować, czy jest to tylko kwestia akademicka, problem projektowy, czy naprawdę ważny przypadek.
Jacob Thomason