확장 성이 뛰어난 웹 사이트를 디자인하는 가장 좋은 방법은 무엇입니까?


34

페이스 북과 같은 소셜 네트워크와 같이 확장 성이 높아야하는 웹 사이트의 경우 웹 사이트를 디자인하는 가장 좋은 방법은 무엇입니까?

  1. 사이트에서 필요한 데이터를 얻기 위해 쿼리하는 웹 서비스가 있어야합니까?

    또는

  2. 사이트가 데이터베이스를 직접 쿼리해야합니까? (테이블을 자동으로 채우는 내장 언어 구성을 사용하여 수행 할 수 있음).

웹 서비스는 중앙 집중식 데이터 액세스를 제공하고 캐싱 등과 같은 것들이 훨씬 쉽게 제어 할 수 있기 때문에 더 나은 디자인이라고 생각합니다.하지만 다른 사람들은 어떻게 생각합니까?


사용할 아키텍처 (MVC 등)에 대한 질문도 있습니다.
Ivan

정확히 무엇을 출시 할 것인지에 대해 더 많이 알지 못하면 대답을하기가 매우 어렵지만 "클라우드 서비스"를 염두에 두십시오. 아마도 응용 프로그램이 일종의 SaaS 앱에 적합 할 것입니다. (중앙 집중식입니다).
deepcell

일반적으로 말하자면, 특별히 염두에 두어야 할 것은 없습니다 ..
Daniel

1
'클라우드'에서 구축하고 HighScalability.com을 읽는 데 많은 시간을 소비하십시오.
Evan Plaice 2018 년

답변:


36

와우, 이것은 간단한 질문이며, 가능한 많은 답변이 있습니다. 질문의 더 명확한 부분은 데이터베이스와 직접 또는 웹 서비스를 통해 인터페이스하는 것이 더 확장 가능한지 묻습니다. 그 대답은 간단합니다. 데이터베이스를 직접 쿼리하십시오. 웹 서비스를 거치면 방화벽 뒤에서 (대부분의) 코드 작동에 완전히 불필요한 대기 시간이 추가됩니다. 예를 들어 웹 서비스는 일부 구성 요소가 요청을 받고, 역 직렬화하고, DB를 쿼리하고, 응답을 직렬화하고 반환해야합니다. 따라서 코드가 모두 방화벽 뒤에서 작동하는 경우 문제를 해결하고 DB를 직접 쿼리하십시오.

그러나 웹 사이트를 확장 가능하게 만드는 것은 처음 제기 한 질문을 넘어선 것입니다. 여기서 탄젠트를 타면 저를 용서해주십시오.하지만 특히 페이스 북을 언급 한 것을 고려하면 도움이 될 것이라고 생각했습니다.

Brad Fitzpatrick (LiveJournal의 설립자이자 현재는 Google의 창립자)가 구축 한 작업과 도구에 대해 읽어 보는 것이 좋습니다. Six Apart에서 그와 함께 일할 때, 그에게서 배운 것들과 LiveJournal의 아키텍처에 대한 확장 성이 매우 뛰어납니다.

  1. 넓은 데이터베이스 테이블과 달리 좁은 데이터베이스 테이블을 사용하십시오 . 어떤이에 대한 매력이었다 쉽게이었다 시스템 생성 된이 아키텍처, 동기가 무엇을 학습했다 신속을업그레이드되었습니다. 넓은 테이블 또는 각 필드 또는 속성이 테이블의 열인 테이블을 사용하는 경우 데이터베이스 스키마를 업그레이드 할 때 (예 : 새 열 추가) 시스템은 스키마 동안 테이블을 잠 가야합니다. 변경이 구현됩니다. 대규모로 운영 할 때 데이터베이스 스키마를 간단히 변경하면 데이터베이스가 크게 중단 될 수 있습니다. 분명히 짜증나. 반면에 좁은 테이블은 단순히 개체와 관련된 각 개별 속성을 데이터베이스에서 단일 행으로 저장합니다. 따라서 데이터베이스에 새 열을 추가하려면 잠금이 아닌 작업 인 레코드를 테이블에 삽입해야합니다. 자, 그것은 약간의 배경입니다. LiveJournal과 같은 작업 시스템에서이 모델이 실제로 어떻게 변환되는지 봅시다.

    개인의 블로그에 마지막 10 개의 저널 항목을로드하고 각 저널 항목에 10 개의 속성이 있다고 가정 해 봅시다. 일반적인 넓은 테이블 레이아웃에서 각 속성은 테이블의 열과 관련이 있습니다. 그런 다음 사용자는 테이블을 한 번 쿼리하여 필요한 모든 데이터를 가져옵니다. 쿼리는 10 개의 행을 반환하고 각 행은 필요한 모든 데이터를 갖습니다 (예 : SELECT * FROM 항목 ORDER BY 날짜 제한 10). 좁은 테이블 레이아웃에서는 상황이 약간 다릅니다. 이 예에는 실제로 두 개의 테이블이 있습니다. 첫 번째 테이블 (표 A)에는 항목의 ID, 작성자의 ID, 항목의 날짜 등으로 검색하려는 간단한 기준이 저장됩니다. 두 번째 테이블 그런 다음 (표 B)는 항목과 관련된 모든 속성을 저장합니다. 이 두 번째 테이블에는 entry_id, key 및 value의 세 열이 있습니다. 테이블 A의 모든 행에 대해 테이블 ​​B에 10 개의 행이 있습니다 (각 속성에 대해 한 행). 따라서 마지막 10 개의 항목을 가져 와서 표시하려면 11 개의 쿼리가 필요합니다. 첫 번째 쿼리는 항목 ID 목록을 제공 한 후 다음 10 개의 쿼리는 첫 번째 쿼리에 반환 된 각 항목과 관련된 속성을 가져옵니다.

    "신성한 몰리!" "어떻게 지구상에서 어떻게 확장 할 수 있을까요?" 완전히 반 직관적 인 권리? 첫 번째 시나리오에서는 데이터베이스 쿼리가 하나 뿐이지 만 두 번째 "확장 성있는"솔루션에는 11 개의 데이터베이스 쿼리가 있습니다. 말이되지 않습니다. 그 질문에 대한 답은 전적으로 다음 글 머리 기호에 의존합니다.

  2. memcache를 자유롭게 사용하십시오. 모르는 경우 memcache는 분산 된 상태 비 저장 지연 시간이 적은 네트워크 기반 캐싱 시스템입니다. Facebook, Google, Yahoo 및 지구상의 모든 인기 있고 확장 가능한 웹 사이트에서 사용됩니다. 좁은 테이블 데이터베이스 설계에 내재 된 데이터베이스 오버 헤드를 상쇄하기 위해 Brad Fitzpatrick이 부분적으로 발명했습니다. 위의 # 1에서 설명한 것과 동일한 예제를 살펴 보도록하겠습니다. 이번에는 memcache를 소개하겠습니다.

    사용자가 처음 페이지를 방문하고 캐시에 아무것도 없을 때 시작합시다. 페이지에 표시하려는 10 개의 항목 ID를 리턴하는 테이블 A를 조회하여 시작합니다. 그런 다음 각 항목에 대해 데이터베이스를 쿼리하여 해당 항목과 관련된 속성을 검색 한 다음 해당 속성을 사용하여 코드와 인터페이스 할 수있는 개체 (예 : 개체)를 구성합니다. 그런 다음 memcache에서 해당 오브젝트 (또는 해당 오브젝트의 직렬화 된 양식)를 숨 깁니다.

    두 번째로 동일한 페이지를로드하면 같은 방법으로 시작합니다. 표시 할 항목 ID 목록에 대해 테이블 ​​A를 쿼리하면됩니다. 각 항목에 대해 먼저 memcache로 이동하여 "캐시에 항목 #X가 있습니까?"라고 말합니다. 그렇다면 memcache는 입력 객체를 반환합니다. 그렇지 않은 경우, 데이터베이스를 다시 조회하여 해당 특성을 페치하고 오브젝트를 구성한 후 memcache에 숨겨야합니다. 대부분의 경우 두 번째로 누군가 동일한 페이지를 방문하면 하나의 데이터베이스 쿼리 만 있고 다른 모든 데이터는 memcache에서 바로 가져옵니다.

    실제로 대부분의 LiveJournal에서 발생하는 결과는 대부분의 시스템 데이터, 특히 덜 휘발성 인 데이터가 memcache에 캐시되었으며 좁은 테이블 스키마를 지원하는 데 필요한 데이터베이스에 대한 추가 쿼리가 모두 완전히 오프셋 된 것입니다.

    이 디자인은 모든 친구와 관련된 게시물 목록을 스트림으로 모으는 것과 관련된 문제를 훨씬 쉽게 "벽"으로 해결했습니다 .

  3. 다음으로 데이터베이스 파티션을 고려하십시오. 위에서 논의한 모델은 또 다른 문제점을 나타내며, 좁은 테이블은 매우 크거나 길다. 그리고 해당 테이블에있는 행이 많을수록 다른 관리 작업이 어려워집니다. 이를 상쇄하기 위해 테이블을 어쨌든 분할하여 테이블 크기를 관리하는 것이 합리적 일 수 있으므로 사용자 클러스터는 한 데이터베이스에서 제공되고 다른 사용자 클러스터는 별도의 데이터베이스에서 제공됩니다. 이렇게하면 데이터베이스에로드가 분산되고 쿼리가 효율적으로 유지됩니다.

  4. 마지막으로 멋진 인덱스가 필요합니다. 쿼리 속도는 데이터베이스 테이블의 인덱스 수준에 크게 좌우됩니다. 나는 건초 더미에서 바늘을 더 효율적으로 찾는 거대한 카드 카탈로그 시스템과 비슷하다는 것을 제외하고는 색인이 무엇인지에 대해 너무 많은 시간을 소비하지 않을 것입니다. mysql을 사용하는 경우 느린 쿼리 로그를 켜서 수행하는 데 오랜 시간이 걸리는 쿼리를 모니터링하는 것이 좋습니다. 레이더에 쿼리가 나타나면 (예를 들어 속도가 느리므로) 속도를 높이기 위해 테이블에 어떤 인덱스를 추가해야하는지 파악하십시오.

"이 위대한 배경에 대해 감사하지만, 성스러운 일이다. 그것은 내가 작성해야 할 많은 코드이다."

반드시 그런 것은 아닙니다. memcache와의 인터페이스가 정말 쉬운 많은 라이브러리가 작성되었습니다. 또 다른 라이브러리는 위에서 설명한 전체 프로세스를 체계화했습니다. Perl의 Data :: ObjectDriver는 그러한 라이브러리입니다. 다른 언어의 경우 자체 연구를 수행해야합니다.

이 답변이 도움이 되었기를 바랍니다. 내가 발견 한 것보다 자주 발견 한 것은 시스템의 확장 성이 코드에 따라 점점 줄어들고, 건전한 데이터 저장 및 관리 전략 / 기술 설계에 점점 더 많이 발생한다는 것입니다.


3
+1 나는 정말로 이것을 좋아한다. 와우, 이것은 간단한 질문이며, 가능한 많은 답변이 있습니다.
Pankaj Upadhyay

1
나는 '데이터베이스 직접 쿼리'에 완전히 동의하지 않습니다. API 인터페이스로 단일 마스터 다중 슬레이브 아키텍처를 쉽게 구현할 수있을 때 성능을 위해 데이터베이스 파티션을 언급했습니다. 응용 프로그램에서 DB를 분리하면 API 계층에서 원하는대로 요청을 배포 할 수 있다는 이점이 있습니다. API는 기본 구현을 변경하거나 응용 프로그램을 중단하지 않고 데이터를 재사용 할 수있는 추상화입니다.
Evan Plaice 2016 년

1
(계속) 직렬화는 항상 오버 헤드를 추가하지만 동시에 실행되는 여러 인스턴스로 구성된 API 계층에서만 추가됩니다. 유선 전송 속도가 걱정된다면 JSON으로 변환하면 gzip으로 압축 될 가능성이 높습니다. 작업이 서버에서 클라이언트로 푸시 될 때 가장 쉬운 성능 향상을 찾을 수 있습니다. 중요한 질문은 응용 프로그램 내에서 또는 서버 수준에서 요청을 배포하겠습니까? 어느 것이 더 복제하기 쉬운가?
Evan Plaice 2016 년

1
@EvanPlaice-서비스를 사용할 때 재사용 성과 서비스 로직 구현 변경에 대한 요점. 또한 캐시 인프라는 직접 데이터베이스 호출 대신 서비스에서 사용할 수 있습니다.
Ashish Gupta

1
@AshishGupta 정확히, 데이터를 별도의 서비스로 분할하는 것의 유일한 차이점은 사용자가받는 것입니다. 대신 서버에서 html + 컨텐츠를 조립하십시오. 사용자는 데이터와 html을 별도로 받고 클라이언트 브라우저는 리 어셈블리를 처리합니다. 데이터를 별도의 서비스로 사용하면 모바일 응용 프로그램이나 웹 기반이 아닌 다른 클라이언트 (예 : 스마트 TV 응용 프로그램)에서 사용할 수있게됩니다.
Evan Plaice

13

페이스 북과 같은 소셜 네트워크와 같이 확장 성이 높아야하는 웹 사이트의 경우 웹 사이트를 디자인하는 가장 좋은 방법은 무엇입니까?

법안.

나는 생각할 것입니다 ...

잘못된 정책.

실제 측정이 필요합니다.


정량적 지표 FTW.
bhagyas

1
알았어 ... 측정 후 무엇을합니까?
Pacerier

9

확장 성은 특정 구현 전략의 기능이 아니라 애플리케이션 아키텍처를 설계하는 것이 아니라 대규모 리팩토링 및 재 작성없이 데이터 액세스 계층을 발전시킬 수 있습니다.

확장 가능한 시스템을 구축 할 때 중요한 기술은 높은 수준의 데이터 액세스 요구 사항을 이해하고 이에 대한 인터페이스 계약을 작성하는 것입니다. 예를 들어, 한 명의 사용자확보 하거나 가장 최근에 게시 한 50 명의 사진나열 해야 할 수도 있습니다 .

애플리케이션 비즈니스 로직과 데이터 액세스 로직 사이에 네트워크 채널이 반드시 필요한 것은 아닙니다. 논리 연산 당 하나의 메소드로 메소드 호출 간접을 시작하는 것이 좋습니다.

이러한 데이터 액세스 방법을 최대한 간단하게 만드십시오. 응용 프로그램이 실제 사용 패턴을 제공하고 병목 현상이 발생한 위치에 대한 데이터를 수집 할 때까지 성능 문제가 발생할 위치를 예측하는 것은 매우 어렵습니다.

잘 정의 된 데이터 액세스 인터페이스를 사용하면 전체 애플리케이션을 크게 변경하지 않고도 데이터 액세스 구현을 발전시킬 수 있습니다. 비즈니스 로직에 투명하게 웹 서비스 아키텍처로 전환하기로 결정할 수도 있습니다.

위의 많은 답변은 성능 병목 현상을 발견 한 후 진행하는 방법에 대한 훌륭한 조언을 제공하지만 너무 일찍 적용하면 코드의 복잡성으로 인해 복잡성이 필요한지 여부를 알 수 있습니다.


4

간단한 웹 사이트를 개발하고 트래픽 수준에 도달하도록하십시오. 라인을 따라 확장 가능한 웹 사이트를 만드는 방법을 배우게됩니다.

문제에 직면 할 때까지는 해결책을 생각할 수 없습니다 .

사이트를 롤링하고 스케일링 요구 사항을 충족하면 나를 믿으십시오. 그 방법을 확실히 알 수 있습니다. :-)


좋은 견적 !!!!!!!!!!
AmirHossein

2

웹 응용 프로그램은 기본적으로 웹 (프레젠테이션), 응용 프로그램 및 데이터베이스 계층의 세 계층으로 설계되어야합니다. 이 부서는 각 계층의 요구 사항이 다르기 때문에 일반적으로 데이터베이스의 품질 디스크 액세스 / 저장, 앱 계층의 높은 CPU / 메모리 및 웹 계층의 높은 외부 대역폭 / 메모리 / 지리적 분산입니다. 데이터베이스 시스템은 종종 초기 애플리케이션로드를 처리하기 위해 구축 할 수있는 대규모 서버 인 경향이 있기 때문에 애플리케이션 / 데이터베이스 계층은 종종 애플리케이션 라이프 사이클에서 훨씬 나중에 하나로 통합됩니다.

그러나 애플리케이션에 적합한 특정 레이어 수와 적절한 아키텍처는이 모델이나 다른 모델과 일치하지 않아도됩니다.

시스템의 모든 활동을 측정하고 모니터링해야합니다. 2 단계 또는 3 단계 디자인에서 시작하여 디자인 할 때 가장 많은 리소스가 필요한 것처럼 보이는 부분에 집중하십시오. 실행중인 응용 프로그램이이 레벨에서 설계를 안내하게하십시오. 더 많은 정보를 수집할수록 더 정확하고 상세할수록 응용 프로그램이 성장함에 따라 더 나은 결정을 내릴 수 있습니다.

나중에 프레임 워크와 아키텍처를 선택하면 필요한 변경을 가능한 한 신속하고 고통없이 피봇 / 만들 수 있습니다. 데이터 액세스 / 스토리지 / 프로세싱 및 응용 프로그램 처리가 동일한 실행 파일에서 수행 되더라도 제대로 인수 분해되면 예를 들어 나중에 두 개의 레이어로 분리하는 것이 어렵지 않습니다.


2

데이터베이스에 연결하는 추가 단계는 단지 오버 헤드입니다. 예를 들어, 사이 UI -> Business Facade -> Business -> Data Access -> DatabaseUI -> Database두 번째 방법은 더 빠르다. 그러나 제거 할 단계가 많을수록 시스템 유지 관리가 덜되고 복제가 더 많이 나타납니다. 프로필, 홈 페이지, 친구 관리 페이지 등에서 친구 목록을 검색하는 데 필요한 코드를 작성한다고 상상해보십시오.

따라서 고성능 (물론 높은 확장성에 직접적인 영향을 미침)과 유지 관리 성 사이에서 균형을 유지해야 합니다.

그러나 확장 성이 뛰어난 웹 사이트를 만들 때 데이터베이스 연결 주제에 국한되지 마십시오 . 다음 항목도 고려하십시오.

  1. 올바른 플랫폼 선택 (PHP는 스크립팅 특성으로 인해 더 빠르지 만 ASP.NET은 요청 된 파일을 즉시 컴파일하여 처리하고 무언가를 제공해야합니다. 또한 node.js콜백 때문에 확장 성이 뛰어납니다. 기반 아키텍처 )
  2. 웹 서비스 모델 (SOA) 대신 RESTful 아키텍처 사용
  3. XML 대신 데이터 전송에 JSON 사용 (전송되는 바이트 수 감소)
  4. Yahoo의 성능 지침 준수
  5. 로드 밸런싱 또는 계층 아키텍처 와 같은 네트워크 및 하드웨어 주제

2
PHP가 더 빠르다고 말할 수는 없습니다. 올바르게 작성된 ASP.NET 응용 프로그램은 대부분의 경우 PHP보다 성능이 뛰어납니다. naspinski.net/post/AspNet-vs-php--speed-comparison.aspx
Andrew Lewis

+1 실제로, '간단한'솔루션은 UI-> 데이터 액세스-> 데이터베이스입니다. 2 REST는 이미 대부분의 브라우저에 내장되어 있기 때문에 '쉬운'것입니다. 명령 응답 API 휠을 다시 만들 필요가 없습니다. 3 JSON은 작을뿐만 아니라 HTML 엔터티를 확인할 필요가 없으므로 직렬화-직렬화 해제 단계가 더 적습니다. 좋은 물건.
Evan Plaice 2018 년

1

확장 및 확장하는 두 가지 기본 방법이 있습니다.

확장은 기계를보다 강력한 기계로 교체하는 것입니다. 스케일 아웃은 기존 머신이 수행하는 작업을 수행하기 위해 다른 머신을 추가하는 것을 의미합니다.

트래픽이 많은 웹 사이트는 확장 할 수 있어야합니다. 소프트웨어 아키텍처는 사이트가 더 바 빠질수록 더 많은 기계를 쉽게 추가 할 수 있도록하는 것과 같은 방식입니다.

일반적으로 이는 각 계층에서 더 많은 서버를 연결하고 재생할 수 있도록 응용 프로그램을 계층으로 분할하는 것을 의미합니다.

옵션 1을 수행하고 직접 수행하는 대신 서비스를 사용합니다. 지금까지 단일 응용 프로그램 만 확장 할 수 있습니다.


0

클라우드에 대한 완벽한 통합 지원 기술 플랫폼을 사용하여 사이트를 개발하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.