일.확장성이란 무엇인가?
Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
확장성이란, 시스템에 리소스를 추가하는 방식으로 증가하는 작업량에 대응할 수 있는 능력을 의미합니다. 리소스를 추가하는 두 가지 방식이 있습니다:
-
수직 확장 (Vertical scaling): 즉 단일 머신 구성을 향상시키고, 단일 머신에 메모리, 프로세서, 하드디스크 등의 하드웨어 리소스를 추가합니다. 충분한 예산을 투입하면, 호화로운 구성의 서버를砸き낼 수 있습니다
-
수평 확장 (Horizontal scaling): 즉 머신을 추가하고, 수량을 1 대에서 여러 대로 확장하며, 여러 서버로 토폴로지 구조를 형성합니다. 충분한 예산을 투입하면, 1 개의机房, 심지어 전 세계에 퍼진 데이터 센터를 소유할 수 있습니다
시스템 설계에 있어서, 확장성은 시스템이 추가된 더 많은 리소스 (멀티코어, 멀티머신 등) 를 이용할 수 있도록 요구합니다
이.시스템 설계를 관통하는 확장성의 투쟁
하나의 사용자 리퀘스트는 클라이언트에서 출발하여, 네트워크 전송을 거쳐, Web 서비스 층에 도달하고, 다음으로 애플리케이션 층에 진입하며, 마지막으로 데이터 층에抵达합니다:
시스템 설계 중의 각 논리 층에 대응:
경로의 각 층에는 특정 확장성 모드가 있습니다:
마지막으로 이토록 복잡한 시스템 아키텍처가 형성되었습니다:
그 작동 메커니즘은 다음과 같습니다:
-
클라이언트가 DNS 를 조회하여 서비스에 대응하는 IP 주소를 얻음.Web 서비스 이전의 로드 밸런서 를 가리킬 수도 있고, CDN 일 수도 있으며, 오브젝트 스토리지 중의 정적 리소스를 就近 제공
-
Web 서비스에 몰리는 리퀘스트는 로드 밸런서 (예를 들어 리버스 프록시) 에 의해 기정 전략에 따라 대응하는 Web 서버에 배분되어, 애플리케이션 층에 진입
-
리퀘스트가 애플리케이션 층에 도달한 후, Service Discovery, Service Mesh 등의 서비스 조회 메커니즘을 통해 타겟 [마이크로서비스](/articles/마이크로서비스 아키텍처（microservices）/) 를 찾아, 리퀘스트 처리를 시작
-
데이터 리퀘스트는 일련의 읽기/쓰기 API 를 통해 최종적으로 데이터 층으로 전환되며, 비동기 조작은 메시지 큐 에서 큐잉되지만, 최종적으로는 모두 데이터 층에抵达
-
핫 데이터에 대한 리퀘스트는 데이터베이스 이전의 캐시 층 에서 막히고, 나머지는 데이터베이스에 떨어짐.分庫分表, 비정규화 최적화 를 거친 경우도 있고, 복제 메커니즘 에 의해 데이터 일관성을 보증하는 SQL 데이터베이스일 수도 있으며, 쿼리 퍼포먼스가 더 좋은 NoSQL 데이터베이스 일 수도 있고, 혹은 오브젝트 스토리지일 수도 있음
그 중에서, 많은 패턴은 몇 가지 문제를 해결함과 동시에, 몇 가지 새로운 문제도 가져옵니다. 따라서, 시스템 설계에서는, CAP 의 선택에서 배분 전략의 제정까지, 끊임없이 권형취사 를 하고 있습니다
삼.상업화 배경 하의 확장성 요구
至此, 시스템 설계에서 상용적인 확장성 모드는 모두 정리했습니다
돌아와서 확장성을 다시 보다:
확장성이란, 시스템에 리소스를 추가하는 방식으로 증가하는 작업량에 대응할 수 있는 능력을 의미합니다
단순히 정의만으로 보면, 하나의 시스템이 추가된 리소스를 이용할 수 있고,进而더 많은 작업량을 감당할 수 있는 능력이 있다면, 그것은 확장 가능한 것입니다. 이것도確實확장성의基本要求입니다
그러나, 실제 장면 (상업화 배경) 에서, 우리는 확장성에 대해 더 높은 요구를 제기했습니다:
[caption id="attachment_2154" align="alignnone" width="625"]
what does it mean to be scalable[/caption]
많은 경우, 무뇌하게 리소스를 추가하면確實문제를 해결할 수 있지만, 확장성而言, 돈을 태우는 것은 수치입니다:
Well, you can just throw hardware at the problem which is the thing that's thrown around our industry a lot. And I think it's a little bit of a shame, because it is just effectively like burning money.
즉, 시스템은 이용할 수 있을 뿐만 아니라, 가능한 한 효율적으로 추가된 리소스를 이용해야 하며, 단순히 리소스를 추가하여 선형 확장을 실현하는 것만은 아니다 라는 것입니다
이용률의衡量基準은 일반적으로단필 거래의 비용 (비거래 시스템에서는其它유사한 업무 지표일 수도 있음):
단필 거래 비용 = 총비용 / 거래량
그 중에서, 비용은 고정 비용과 가변 비용 두 부분으로 나뉩니다:
-
고정 비용: 전기 작업과 인프라, 상각 비용, 자본 비용, 경영 비용 등
-
가변 비용: 필요에 따라 사용할 수 있는지, 배치에 할인이 있는지, 리소스 이용 가능 확보 (유지 관리 등)
따라서, 상업화 배경에서, 확장성이 대답해야 할 문제는, 1 대의 머신을 추가하면, 얼마나 많은 업무량을 더 지원할 수 있는가 입니다:
A typical question I would ask of anyone is if you add another node to your system how many more units of work or transactions or whatever do you get out of that.
머신을 추가하면 더 많은 작업량에 대응할 수 있다고 확신할 뿐만 아니라, 정확히 "더 많음"이 얼마인지를 알고,进而비용을 최적화하며,精益求精해야 합니다
아직 댓글이 없습니다