컨테이너가 확장성을 변경하는 방식

'클라우드 규모'라는 용어는 종종 가볍게 다루어지곤 한다. 이 단어는 마케팅에서 정말 큰 규모를 암시하기 위해 많이 사용되는데, 전통적인 의미의 크지는 않지만 여전히 중요한 규모와는 반대입니다.

그러나 신화와 전설 속에 숨겨진 진실이 있는 것처럼, "구름 규모"라는 용어를 사용하는 방식에도 어느 정도 진실이 있습니다.

진실은 클라우드와 컨테이너가 확장성의 기본 토대를 바꾸었다는 것입니다. 이러한 변화는 수직적 확장 전략과 수평적 확장 전략 간의 근본적인 차이에서 비롯됩니다. 20세기의 첫 10년 동안 우리는 수직적 규모가 우리에게 필요한 속도와 이익을 달성하는 가장 좋은 방법이라는 관념에 거의 전적으로 의지해 왔습니다. 즉, 더 많은 대역폭, 더 많은 컴퓨팅, 더 많은 메모리를 의미했습니다. 더 많은 항구. 더 높은 밀도. 더 빠른 처리.

하지만 클라우드 시대가 도래하면서 초점은 수평적 규모로 바뀌었습니다. 아직 더 많은 대역폭과 컴퓨팅 및 처리 능력이 필요하지만, 우리는 그 요구를 분산하는 방법을 배웠습니다. 아직 하드웨어가 더 필요하지만, 하나의 거대한 개체가 아니라 여러 출처에서 조립할 뿐입니다.

게임의 판도를 바꾸는 것은 자원을 조립하는 방식입니다. 그리고 오해하지 마십시오. 컨테이너 덕분에 게임이 바뀌었습니다.

오늘날의 규모는 제어 평면에 달려 있습니다. 리소스를 시작하고 해제하는 데 사용되는 API의 속도는 아마도 로드 밸런싱 서비스 자체의 속도보다 더 중요할 것입니다. 몇 분 만에 리소스가 시작되고 사용 중지되는 환경에서 서비스 검색 속도는 사용 가능한 인스턴스에 요청을 전달하는 데 가장 중요해집니다.

Sysdig 컨테이너 사용 보고서 2019 에 따르면 컨테이너의 절반 이상(52%)이 수명이 5분 미만입니다. 

• 22% <= 10초 
• 17% <= 1분
• 15% <= 5분

거의 절반(42%)이 201~500개의 컨테이너 인스턴스를 운영합니다. 정확성을 유지하기 위해 제어 평면은 구성 요소를 자주 업데이트합니다. 클라우드보다 훨씬 더 자주 발생하고, 모노리식 애플리케이션에서 볼 수 있는 것보다는 확실히 훨씬 더 자주 발생합니다.

따라서 현재 사용 가능한 리소스 세트를 반영하기 위해 인그레스 컨트롤러(부하 분산 메커니즘)가 업데이트되는 속도는 중요한 기능이 됩니다. 잘못된 경우 소비자 요청이 더 이상 존재하지 않는 리소스로 전달되거나 완전히 다른 서비스를 호스팅할 수 있기 때문입니다. 어느 쪽이든 요청이 사용 가능한 리소스로 리디렉션되므로 결과적으로 응답이 더 길어집니다. 소비자는 답변을 기다리는 데 더 오랜 시간이 걸리고, 대신 포기할 수도 있습니다.

이 모든 것은 컨테이너화된 환경에 배포된 애플리케이션의 확장성을 방해하는 요소로 제어 평면의 속도를 지적합니다.

결국 이는 제어 평면의 규모가 문제라는 걸 의미합니다. API 디자인이 문제입니다. API에 대한 요청과 업데이트를 인증하고 권한을 부여하는 메커니즘이 문제입니다.

오늘날 확장성의 중심은 제어 평면입니다. 견고하고 확장 가능한 제어 평면은 좋은 것이 아닙니다. 오늘은 RFC의 필수 사항입니다.