나는당신이 식료품 점의 주인이라고 상상해보십시오.청구 카운터가 하나 있습니다.고객이 당신의 상점, 물건을 골라서이 청구서 카운터에 줄을 서서 지불하십시오.고객을 돌보는 청구 카운터 뒤에 John이라는 직원이 있습니다.John은 각 고객을 미소로 맞이하고 청구하는 동안 고객과 작은 대화를 나누는 행복한 행운의 사람입니다.John은 매장의 고객 수가 적을 때 자신 만의 달콤한 시간을 보냅니다.줄 서두르지 않고 아무도 불평하지 않습니다.그러나 서두르는 날이 많을 때 John은 대화를 줄이고 빠르게 움직이고 고객을 관리하려고합니다.

얼마 지나지 않아 식료품 가게가 마을에서 유명해지면서 매장으로 유입되는 고객이 몰려 드는 것을 볼 수 있습니다.그것은 사업에 매우 좋습니다.그러나 이제 당신은 문제에 직면 해 있습니다.직원 John 1 명과 청구 카운터 하나만 있습니다.John은 고객 부담을 처리하기 위해 최선을 다하고 있지만 그가 투입 할 수있는 노력에는 물리적 한계가 있습니다. 결국 그는 인간입니다.또 다른 문제가 있습니다.John이 건강하지 않거나 휴가를 가야하는 날이 있습니다.이러한 경우에는 다른 일을하기 위해 주로 외곽에 있기 때문에 상점을 닫아야합니다.가게는“유효한”그런 날에.

당신은해야“규모”이러한 문제를 해결하기 위해

Sam이라는 다른 직원을 고용하고 두 번째 청구 카운터를 열기로 결정했습니다.이것은“하중”존에.2 개의 대기열이 있습니다.일부 고객은 Sam으로 이동하고 다른 고객은 John으로 이동합니다.당신은 행복하고 John은 행복하며 고객도 행복합니다.이것은 또한 두 번째 문제를 어느 정도 해결합니다.직원 중 한 명을 사용할 수없는 날에는 다른 직원이 고객을 처리 할 수 있습니다.물론 그에 대한 부담은 훨씬 더 많 겠지만 적어도 그날 매장을 닫을 필요는 없습니다.여전히 “사용 가능”합니다.

결국 고객 수가 계속 증가하고 있으며 세 번째 청구 카운터를 열고 세 번째 직원을 고용하기로 결정합니다.이 전략은 효과가 있습니다.상점은 항상 가득 차 있으며 고객은 이제 3 개의 대기열을 형성합니다.그러나 때로는 한 청구 카운터에서 다른 것보다 라인이 큰 상황이 있습니다.고객은 임의의 카운터에 서기로 결정하고 한 직원은 매우 바쁘고 다른 두 직원은 상대적으로 자유로울 수 있습니다.이러한 상황을 극복하기 위해 네 번째 직원을 고용합니다.그의 임무는 3 개의 카운터 모두 중앙에 서서 어떤 카운터가 무료인지 등을 확인하여 고객에게 어디로 가도록 안내하는 것입니다.그는 직원들에게 어느 정도 균등하게 분산되도록 작업 부하를 “균형”합니다.

===================================

이것이 소프트웨어 애플리케이션과 어떤 관련이 있습니까?거의 모든 부분.

매우 높은 수준에서 소프트웨어 웹 애플리케이션은 애플리케이션을 호스팅하는 웹 서버와 데이터를 유지하는 데이터베이스 서버로 구성됩니다.위의 이야기에서-

“식료품 점”을 “소프트웨어 응용 프로그램”으로 교체

John을이 응용 프로그램을 유지 관리하는 웹 서버 / 데이터베이스 서버로 바꿉니다.

고객을 애플리케이션의 “사용자”로 바꾸십시오.

이 설정의 아키텍처는 다음과 같습니다.

사용자 (또는 고객)는 URL (www.myapplication.com)을 통해 애플리케이션에 액세스합니다.HTTP 요청은 웹 서버로 전송됩니다.웹 서버는 HTML 페이지를 반환합니다.웹 서버 / DB 서버를 John이 고객의 요청을 처리하는 것처럼 생각하십시오.고객 수가 증가하면 설정 (예 : John)에 대한 부하가 증가합니다.고객은 응답 속도가 느리거나 웹 서버 / DB 서버가 사용 중이기 때문에 응답을받지 못하는 고객이있을 수 있습니다.너 뭐하니?당신은해야“규모”

Vertical Scaling

수직 확장 ( “확장”이라고도 함)은 서버에 더 많은 전력을 추가하는 것을 의미합니다.예 : 더 많은 부하를 처리 할 수 있도록 더 많은 CPU 또는 RAM을 추가합니다.이것은 John이 더 많은 에너지를 사용하고 잡담을 줄이고 빠르게 행동하기 시작한다고 말하는 것과 같습니다.나는 이것이 매우 나쁜 비유라는 것을 알고 있지만 당신은 아이디어를 얻습니다.

수직 확장에는 제한이 있습니다.하나의 서버에 무제한 메모리 또는 모든 무제한 CPU를 추가 할 수는 없습니다.그것은 존이 자신의 신체적 한계만큼 빨리 행동 할 수 있다고 말하는 것과 같습니다.그 이상은 아닙니다.또한이 경우 서버가 다운되면 (John이 휴가를 떠난다) 애플리케이션이 다운됩니다.”사용할 수 없음”이됩니다.

수평 확장

수평 확장 또는 “확장”은 설정에 더 많은 서버를 추가하는 것을 의미합니다.추가 직원을 고용하고 매장에 더 많은 청구 카운터를 여는 것과 같습니다.이 접근 방식은 사용자가 많고 데이터 처리가 필요한 대규모 애플리케이션에 더 적합합니다.설정에 추가 할 수있는 서버 수에는 사실상 제한이 없습니다.따라서 애플리케이션은 가능한 한 많은로드를 처리 할 수 있습니다.설정에 많은 서버가있는 경우“로드 밸런서”들어오는 트래픽을 서버에 균등하게 분배하기 위해 (식료품 점에 대한 이야기에서 고객을 다른 청구 카운터로 안내하는 일을 맡은 네 번째 직원을 고용했습니다.)

이렇게하면 문제도 해결됩니다. 한 서버가 다운 되어도 다른 서버는 계속 작동 할 수 있으며 응용 프로그램이 “사용 불가능”상태가되지 않습니다.이 개념은“고 가용성”.

데이터베이스 복제

위의 시스템 설계 (예…. 시스템 설계 또는 소프트웨어 아키텍처라고 부를 수 있음)에서 우리는 웹 서버를 관리했습니다.데이터베이스 서버는 어떻습니까?또한 데이터베이스 서버를 확장 할 수 있습니다.이것은 … 불리운다데이터베이스 복제.아이디어는 간단합니다.마스터 데이터베이스와이 마스터 데이터베이스의 여러 복사본 (슬레이브라고 함)이 있습니다.모든 삽입 / 업데이트 / 삭제는 마스터 DB에서 수행되고 슬레이브는 읽기 전용 데이터 저장소로 사용됩니다.이렇게하면 데이터베이스의 고 가용성도 보장됩니다.

간단히 말해서 확장성에 대해 생각하거나 소프트웨어 응용 프로그램이나 시스템 설계 또는 소프트웨어 아키텍처가 확장 가능하다고 말할 때 이는 시스템이 허용 가능한 응답 시간 제한 내에서로드 또는 요청을 처리 할 수 있음을 의미합니다.

웹 서버와 데이터베이스 서버의 수평 적 확장은이를 달성하는 훌륭한 방법입니다.하지만로드 / 응답 시간을 개선하기 위해 할 수있는 다른 조치가 있습니까?

캐싱

애플리케이션이 사용 중일 때 기본적으로 데이터베이스에 대한 요청이 처리되고 사용자에게 제공됩니다.이러한 요청 중 일부는 동일하고 반복적 일 수 있습니다.이러한 요청에 해당하는 데이터를 데이터베이스보다 빠른 임시 저장소에 저장하면 의미가 있습니다.”캐시”는 그러한 스토리지 중 하나입니다.애플리케이션 아키텍처에 캐시를 추가 할 수 있습니다.요청을 받으면 웹 서버는 먼저 데이터가 캐시에서 사용 가능한지 확인합니다.그렇다면 캐시에서 가져 와서 클라이언트로 보냅니다.그렇지 않으면 데이터베이스를 쿼리하고 데이터를 캐시에 저장 한 다음 클라이언트로 보냅니다.

이 기사가 확장성에 대해 생각하는 방법에 대한 접근 방식을 제공하기를 바랍니다.확장 가능한 시스템을 설계하고 구축하기위한 다른 많은 보완 기술이 있습니다.나는 후속 기사에서 그것들을 다루려고 노력할 것입니다.