확장 가능한 분산 시스템이란

확장성 있는 웹 사이트나 애플리케이션을 만들고 관리한다는것은 무엇일까? 
자원이나 자원에 대한 접근 권한을 여러개의 서버에 분산되어 있을때를 말한다. 

이제 막 비즈니스를 시작하려는 소규모의 웹 사이트를 만들때에도 설계 시 고려 사항에 대해 생각한다면 좀 더 현명한 결정을 내릴 수 있을 것이다. 주요 고려 사항은 아래와 같다. 

가용성 : 항상 가용적이고 장애에 유연한 아키텍처를 가지는 것이 기본적인 비즈니스 요구사항이다. 분산 시스템에서 높은 가용성을 얻기 위해, 중요한 컴포넌트의 이중화가 실패가 발생했을 경우에 빠른 복구 방법, 문제가 발생할때 일부만으로 동작할 수 있게, 하는 구성에 대한 고려가 필요하다. 

성능 : 웹 사이트의 속도는 사용성, 만족성 뿐 아니라 수익과 유지에 연관이 있다. 빠른 응답 시간과 낮은 레이턴시를 위해 최적화가 필요하다.

신뢰성 : 항상 똑같은 요청에는 똑같은 결과가 제공되어야 한다. 

확장성 : 대규모의 분산 시스템에서라면 규모 자체는 확장성에서 고려해야할 측면에 불과하다.중요한건 더 많은 부하를 처리할 수 있도록 처리량을 증가시키기 위해 필요한 노력이다. 시스템 확장성이란 시스템의 여러 특징이나 기능/ 비기능적 한계 상황으로 설명할 수 있다. 옐르 들어, 얼마나 많은 추가적인 트래픽을 처리할 수 있는지, 저장 공간을 추가하기가 어람나 쉬운 지, 얼마나 더 많은 트랙잭션을 처리할 수 있는지. 

관리성 : 쉽게 운용할 수 있는 시스템을 설계하는것은 또 다른 중요한 고려사항이다. 운용 ( 유지와 업데이트) 확장성과 같은 말이다. 관리성이 좋아지려면 문제 발생 시 분석이 용이해야하고 문제를 이해하기 쉬워야한다. 업데이트와 수정, 시스템 운용 자체가 쉬워야 한다. 

비용 : 비용은 중요한 요소다. 비용은 하드웨어와 소프트웨어의 비용을 포함하지만, 시스템을 배포하고 관리하는 비용 또한 중요하게 고려해야한다. 빌드 걸리는 시간, 시스템 실행 시 운용 노력의 양, 필요한 교육 비용까지 포함된다. 즉, 시스템 소유에 필요한 모든 비용이다.

이러한 고려 사항들은 어느 하나를 향상시키는 것은 다른 하나의 하락을 가져올 수 있다. 서버를 수평 확장하는것은 서버를 추가로 관리해야하기 때문에 관리성과 비용 측면에선 좋지 않다.

무엇이 옳은 부분인지 어떻게 해야 잘 맞추어질지. 확장성이 필요치 않은데 확장성에 투자하는건 현명하지 않다. 다만, 시스템 설계 시, 확장성을 미리 고려하는것은 결과적으로 시간과 자원을 절약할 수 있다. 

기초, 

예를 들어, 이미지 호스팅 시스템에서는, 
1. 저장될 이미지 개수에 제한이 없다. ( 저장공간 확장성 고려 ) 
2. 이미지 보기 다운로드 시 응답 시간 빨라야한다 ( 성능 ) 
3. 사용자가 이미지를 업로드 이후에 해당 이미지는 항상 저장되어있어야한다 ( 신뢰성 ) 
4. 시스템을 운용하기 쉬워야한다 ( 관리성 ) 
5. 서비스 자체의 이익율이 높지 않기 때문에 시스템은 비용 효율적으로 운용할 필요가 있다. 


서비스들, 

확장성 있는 시스템을 설계할 떄, 인터페이스를 기반으로 기능별로 나누는것은 좋은 생각이다. 이러한 방식으로 설계하는것을 SOA라고 한다. 명확한 기술은 문제 분리에도 도움을 주지만, 각각을 독립적으로 확장시키는것도 효과적이다. ( 객체지향과 아주 유사하다. )

위 서비스를 분리해서 다운로드, 업로드 속도가 똑같다고 해도, 읽기는 캐시의 도움을 받을 수 있지만, 쓰기는 디스크에 도착해야한다. 모든 DB는 쓰기가 읽기보다 느리다.

아파치나 lighthttps같은 웹 서버는 동시 커넥션 수에 상한선이 있다. 읽기는 비동기일 수 있다. 

분리해서 생각한다면 각각 문제를 독립적으로 해결할 수 있다. 

이중화 : 이중화가 잘 고려되어야한다. 
shared nothing 아키텍처를 만드는 것이다. 중앙부 없이 독립적으로 동작 가능해야한다. 

파티션, 하나는 수직적 확장, 하나는 수평적 확장이다. 수직적 확장은 하나의 서버에 자원을 추가하는것이고, 수평적은 노드를 추가한다. 

수평적 확장의 경우에는 데이터 로컬러리 문제와 비정합성 문제가 있을 수 있다. 
데이터 액세스 방법을 처리하는데는
캐시나 로드 밸런스 프락시, 인덱스, 로드 밸런서등의 방법이 있다. 

캐시, 캐시를 요청 노드에 배치하는것으로 요청 노드 안에서 먼저 데이터를 찾아본다. 다만, 요청 노드가 여러개로 된다면, 캐싱 미스가 될 수 있다. 전역 캐시와 분산 캐시가 있다. 

캐시가 올바르게 구현되어있다면, 더 빠르게 처리 가능하다. 

프락시는, 프락시 서버를 통해 클라이언트 요청을 암호화, 필터링 로깅 등을 한다.
인덱스는 쓰기할때 느려진다. 왜냐하면 추가적으로 인덱스를 업데이트를 해야하기 때문이다.
인덱스는 목차와 같이 데이터 위치를 알려주는 역할을 한다. 색인을 통해서 데이터의 위치를 알 수 있다. 

로드 밸런서는 여러개 쓰는게 특이하지 않다. 다만, 많으면 복잡성이 증가한다.

큐는 동작 리스트를 만들어, 클라이언트는 요청이 잘 쌓였다는 참조값을 받는다. 큐는 클라이언트가 비동기 방식으로 동작할 수 있는데에 의의가 있다.