트래픽이 많은 웹 사이트를 확장하려면 어떻게해야합니까?

용량을 처리하기 위해 "스케일 아웃"해야하는 웹 사이트에 대해 어떤 모범 사례를 수행해야합니까? 사람들이 클라우드를 고려하고 있기 때문에 특히 관련이 있지만 기본 사항이 누락되었을 수 있습니다.

개발 수준의 작업에서 인프라, 관리에 이르기까지 모범 사례를 고려한 사항에 대해 듣고 싶습니다.

동시성 설계

즉, 코딩 할 때 여러 스레드가 진행되도록 계획하십시오. 공유 상태를 계획하십시오 (종종 db 만). 여러 프로세스를 계획하십시오. 물리적 배포 계획.

이를 통해 시스템을 여러 시스템과로드 밸런싱을 통해 여러 프로세스에 분산시킬 수 있습니다. 장애 발생시 중복 프로세스를 실행할 수 있으며 시스템을 제자리에서 수정해야 할 경우 모든 서비스를 종료하지 않아도됩니다.

고려해야 할 몇 가지 사항 :

• 데이터 스토리지의 읽기 및 쓰기를 분리합니다.
  
  • CQRS / 이벤트 소싱
  • CQS
  • 메시지 전달 / 배우
• 공유 프로세스 및 스레드 상태 방지
  • 따라서 잠금 방지
  • 클래스, 구조체 및 기타 데이터 유형을 변경할 수 없도록 생성하여 생성 후 유형 시스템을 통해이를 피할 수 있습니다. 특히 복잡한 추상 데이터 유형의 경우 놀랍도록 잘 작동합니다 (예 : jQuery의 구현).
• IO에서 웹 서버 스레드를 차단하지 않습니다. ASP.Net을 사용하는 경우 APM 패턴 / 태스크 병렬 라이브러리 (TPL)와 함께 비동기 페이지 / 액션을 사용하십시오.
• 사용자 세션 사전에로드 상태를 저장하지 않음
  • IIS에서 스레드 마이그레이션이 발생할 때 스레드간에 이동해야합니다.
  • 보안되지 않은 / 정적 리소스에는 오버 헤드를 추가하는 동일한 응용 프로그램 프레임 워크 (예 : ASP.Net)가 제공되지 않는 지능적인 라우팅이 있습니다. 예를 들어 다른 웹 서버가있는 것을보십시오.
• 비동기 워크 플로 패턴으로 연속 전달 코드 작성 (예 : 바인드 (haskell) /callcc/Tasks.ContinueWith/F#의 비동기)
• 큐잉 이론을 사용하여 병목 현상이 발생할 수있는 위치를 계산하십시오.
• 풀 기반 업데이트보다는 푸시 기반 업데이트를 사용하여 읽기 모델 및 기타 응용 프로그램 상태를 사용하십시오. 예 : RabbitMQ / nServiceBus를 통한
• 적용 가능한 최소 기능 'http 핸들러'를 사용하십시오.
• 정적 파일의 경우 전자 태그 및 캐시 만료 정책을 제공하여 웹 인프라가 정상적으로 작동하도록합니다 (예 : 오징어 프록시 사용)
• (스케일링 문제를 해결하고 현장 자습서를 받도록 도와주세요.)

아무 아키텍처도 공유하지 않습니다.

이를 염두에두고 생각과 달리 스케일 아웃 솔루션으로 바로 넘어 가지 마십시오. 시스템 외부 오버 헤드와 시스템 내부 호출의 무게를 under 수 없습니다. 예를 들어, 로컬 전화를하는 것보다 네트워크 인터페이스를 통해 DB를 연결하는 데 많은 시간이 걸립니다. 실제 대규모 시스템의 경우 추가 비용과 규모 확장에 필요한 관리, 전력 및 조정 작업에 소요되는 시간을 예산으로 설정하십시오.

그럼에도 불구하고, 나는 "아무것도 공유하지 않는"아키텍처에서 여전히 큰 가치를 지니고 있으며, 때가되면 시스템을 계층화하고 확장 할 수 있습니다.

여러 호스트 이름을 통해 요청을 병렬화

HTTP 표준의 일부는 웹 클라이언트가 DNS 호스트 당 최대 2 개의 세션을 요청한다는 섹션입니다. 다음은 www.domain.com의 별칭을 지정하고 요청 동시성을 높여서 페이지로드 속도를 높이는 솔루션입니다.

/programming/3653609/how-do-i-code-my-asp-net-page-to-parallelize-downloads-across-hostnames

기본적으로 ASP.NET HTTP 처리기를 편집하여 클라이언트를 보내는 대상 호스트를 대체하고 각 호스트는 "www"의 CNAME입니다.

안전하고 빠르며 안정적인 DNS

가동 시간이나 성능에 대한 SLA가없는 레지스트라의 DNS 서버를 사용하는 대용량 웹 사이트를 발견했습니다. 또한 서버는 인도에 위치하고 대기 시간만으로도 DNS 스푸 퍼가 고객 또는 중간 ISP 캐시를 독살 할 가능성이 높아집니다. 이로 인해 SSL 보호 트래픽조차도 아무도 모르게 리디렉션됩니다.

DNS 속도는 레코드가 캐시되기 전에 서버의 초기로드 시간에도 영향을줍니다.

DNS 인프라가 매우 견고하기 때문에 대부분의 고객에게 DynDNS 또는 Neustar를 사용합니다 (비싸고 다른 회사와의 제휴 관계는 없지만).

열쇠가 간단하다고 생각합니다.

간단한 코드를 작성하십시오. 그것은 당신이보고 이해하는 것을 의미합니다. 서버를 확장하고 변경할 때 무슨 일이 일어나고 있는지 알아야합니다. 또한 빠르게 이해해야하는 코더를 추가해야 할 수도 있습니다. 명확하지 않은 임의의 코드를 호출하는 후크 및 XML 파일은 매우 나쁩니다.

그런 다음 문제를 테스트하고 찾을 수 있습니다.

여기를보십시오 : http://blog.servint.net/2013/08/27/going-big-how-to-scale-a-website-part-1-infrastructure-that-scales/

우리는 스텔라 빌드 에서 웹 사이트가 다운 타임없이 확장되도록 노력합니다. 즉, 코드의 기능과 코드의 위치를 ​​알아야합니다. 다른 머신을 테스트하더라도 확장하는 데 시간이 너무 오래 걸리지 않습니다. 대부분의 사람들은 슬프게도 너무 늦을 때만 시작합니다. 내 의견으로는 한 번만 최적화 할 수 있습니다.