콘텐츠 기반 웹 애플리케이션의 데이터 스토리지 성능을 개선하는 것은 반복 프로세스입니다. 애플리케이션이 지원해야 하는 잠재적 처리량과 데이터 볼륨을 데이터베이스 구조 및 데이터 저장소 기술과 함께 고려하는 것이 중요합니다. 이러한 사항은 초기 설계 단계에서도 고려해야 하는 중요한 고려사항입니다.
다차원 확장 및 캐싱과 같은 기술을 사용하면 애플리케이션을 확장하여 더 많은 사용자와 데이터를 지원할 수 있습니다.
데이터 처리 처리량
데이터 처리 처리량은 컴퓨팅 환경 내의 기기, 시스템 또는 구성요소 간에 데이터가 처리되는 속도를 나타냅니다. 특정 기간 내에 데이터를 처리하기 위한 시스템의 용량을 측정합니다. 처리량은 초당 바이트 (B/s), 초당 메가비트 (Mbps), 초당 트랜잭션 수 (TPS)와 같은 시간 단위당 데이터 단위로 표현됩니다.
처리 데이터 처리량은 특정 시간 내에 데이터베이스가 처리할 수 있는 데이터를 의미합니다. 이는 콘텐츠 기반 웹 애플리케이션에서 대량의 데이터를 실시간으로 처리해야 하는 경우가 많기 때문에 중요합니다.
처리 데이터의 처리량에 영향을 줄 수 있는 요인은 다음과 같습니다.
- 데이터베이스 유형입니다. 일부 데이터베이스는 다른 데이터베이스보다 데이터를 더 효율적입니다.
- 하드웨어 구성입니다. 데이터베이스 서버에는 부하를 처리하기에 충분한 CPU, 메모리, 스토리지가 있어야 합니다.
- 쿼리 복잡성 복잡한 쿼리는 기본 쿼리보다 처리 시간이 더 오래 걸릴 수 있습니다.
확장과 관련하여 처리량은 콘텐츠 기반 웹 애플리케이션의 요청 처리 및 데이터 처리 용량과 효율성을 측정하는 중요한 측정항목입니다. 증가된 트래픽을 관리하고 응답 성능을 유지하기 위해서는 높은 처리량이 필수적입니다.
웹 애플리케이션을 확장할 때 처리량과 관련된 고려사항은 다음과 같습니다.
| 고려사항 | |
|---|---|
| 부하 분산 | 부하 분산기는 애플리케이션의 서버 인스턴스 간에 트래픽을 균등하게 분산합니다. 이렇게 하면 단일 서버가 병목 현상을 일으키지 않으며 여러 서버의 결합된 처리 성능을 활용할 수 있습니다. |
| 수평 확장 | 수평 확장을 사용하여 처리량을 늘릴 수 있습니다. 여기에는 애플리케이션의 인프라에 더 많은 서버 인스턴스를 추가하는 작업이 포함됩니다. 수평 확장을 사용하면 애플리케이션이 요청을 여러 서버로 분산하여 처리량을 높일 수 있습니다. |
| 데이터베이스 확장 | 해당하는 경우 늘어난 읽기 및 쓰기 작업을 처리하기 위한 데이터베이스 확장 기법을 사용하는 것이 좋습니다. 이러한 기법으로는 분산 데이터베이스 사용 또는 데이터베이스 쿼리 및 색인 생성 최적화가 포함될 수 있습니다. |
| 데이터베이스 자동 확장 | 자동 확장 메커니즘은 실시간 트래픽 패턴을 기반으로 서버 인스턴스를 추가하거나 삭제할 수 있습니다. Cloud 플랫폼은 수요에 맞게 리소스를 조정하는 자동 확장 기능을 제공하는 경우가 많습니다. 데이터베이스와 플랫폼에서 사용할 수 있는 확장 기능(예: Spanner용 자동 확장 처리)을 고려하세요. |
| 코드/알고리즘 최적화 | 효율성을 위해 애플리케이션 코드와 알고리즘을 일관되게 검토하고 최적화합니다. 서버 리소스 소비를 최소화하면 처리량이 증가할 수 있습니다. |
| 리전/전역 | 리전 및 전역 데이터 스토리지란 여러 지리적 위치에서 데이터를 저장하고 관리하는 다양한 방법을 의미합니다. 리전 데이터 스토리지는 데이터를 특정 리전 또는 위치에 로컬로 저장하는 것이고, 전역 데이터 스토리지는 전 세계 여러 위치에 있는 서버에 데이터를 저장하는 것을 포함합니다. 리전 및 전역 데이터 스토리지 중에서 무엇을 선택할지는 데이터 크기, 필요한 보안 수준, 여러 사용자 또는 애플리케이션에 대한 데이터 접근성 등의 요소에 따라 달라집니다. |
| 배급 | 데이터 스토리지 분산에는 가용성, 성능, 보안을 보장하기 위해 여러 물리적 또는 가상 위치에 데이터를 분산하는 작업이 포함됩니다. 방법으로는 분산 스토리지 시스템 및 클라우드 솔루션이 포함되며, 이러한 솔루션은 데이터 크기 및 복잡성, 조직 니즈, 사용 가능한 기술과 같은 요소에 따라 선택됩니다. 잘 계획된 전략은 중복성, 확장성, 기타 이점을 제공할 수 있습니다. |
높은 처리량을 달성하려면 하드웨어 및 소프트웨어부터 네트워크 인프라와 데이터 처리 알고리즘에 이르기까지 시스템의 다양한 측면을 최적화하는 작업이 포함됩니다. 콘텐츠 기반 웹 애플리케이션에 필요한 특정 기술과 최적화는 데이터 처리 작업 및 시스템의 잠재적 제약 조건과 관련된 개별 요구사항에 따라 달라집니다.
데이터 볼륨
저장되는 데이터 양 측면에서 웹 애플리케이션을 확장하려면 증가하는 데이터 볼륨을 수용할 수 있도록 데이터 스토리지 용량을 관리하고 확장하는 작업이 필요합니다. 확장할 때는 모든 데이터 성장 과제를 처리할 수 있는 스토리지 인프라를 계획해야 합니다.
웹 애플리케이션을 확장할 때 데이터 스토리지에 대한 고려사항은 다음과 같습니다.
| 고려사항 | |
|---|---|
| 저장되는 데이터 유형 | 이미지, 동영상, 바이너리 데이터와 같은 일부 데이터 유형은 다른 데이터 유형보다 저장이 더 어렵거나 더 많은 공간을 차지할 수 있습니다. 복잡한 데이터 유형이나 구조로 인해 시스템 확장 방법이 복잡해질 수도 있습니다. 애플리케이션에 저장하는 데이터 유형과 이러한 데이터 유형이 최적의 선택인지 고려합니다. 또는 blob 스토리지, 미디어 스토리지 시스템 또는 시계열 데이터베이스와 같이 사용 사례나 데이터에 맞게 특별히 빌드된 스토리지 시스템을 고려해 보세요. |
| 사용자 수 | 애플리케이션의 향후 성장을 고려하세요. 사용자가 더 많이 온보딩될수록 더 많은 데이터를 시스템에서 저장, 액세스, 처리해야 합니다. 애플리케이션 성능 프로필을 기준으로 읽기 및 쓰기를 확장하면 수요 증가에 따라 애플리케이션을 더욱 최적화할 수 있습니다. |
| 데이터 스토리지 기술 선택 | 현실적인 데이터 스토리지 요구사항을 평가하고 NoSQL 및 SQL과 같이 가장 적합한 데이터 스토리지 기술을 선택하세요. 선택 시 데이터 구조, 액세스 패턴, 확장성 요구사항을 고려하세요. |
| 데이터 분할 | 데이터 파티션 나누기 또는 샤딩 전략을 구현하여 여러 스토리지 노드에 데이터를 배포하면 데이터 부하를 분산하여 더 효과적으로 확장할 수 있습니다. 사용자 또는 지리적 위치를 기준으로 파티션을 나누거나 애플리케이션의 데이터 액세스 패턴에 따라 기타 기준을 따를 수 있습니다. |
| 캐싱 및 데이터 압축 | 캐싱 전략을 사용하여 자주 액세스하는 데이터를 메모리에 저장하고 저장소 시스템의 부하를 줄입니다. 또한 데이터 압축 기술은 저장소 요구사항을 최소화하고 데이터 전송 효율성을 개선할 수 있습니다. |
| 데이터 수명 주기 관리 | 데이터 수명 주기 정책을 구현하여 데이터 보관, 보관처리, 삭제를 관리합니다. |
| 데이터베이스 색인 생성 | 해당하는 경우 데이터베이스 색인 생성, 쿼리 성능, 데이터베이스 스키마 설계를 최적화하여 증가하는 데이터 세트를 효율적으로 처리합니다. |
웹 애플리케이션을 확장할 때 데이터 스토리지는 지속적인 프로세스이며 웹 애플리케이션의 필요에 맞게 조정해야 합니다. 증가하는 데이터 양을 효과적이고 효율적으로 처리할 수 있도록 정기적으로 스토리지 요구사항을 평가하고, 성능을 모니터링하고, 필요에 따라 스토리지 인프라 및 전략을 조정해야 합니다.
자주 액세스하는 데이터 캐시
데이터 캐싱은 확장 전략의 중요한 구성요소입니다. 데이터 캐싱은 응답 시간을 개선하고 백엔드 시스템의 부하를 줄이며 전반적인 사용자 환경을 향상하는 데 도움이 됩니다. 캐싱은 소스에서 데이터를 반복적으로 생성하지 않고 빠르게 검색할 수 있도록 자주 액세스하는 데이터를 임시 스토리지 레이어에 저장하는 것을 의미합니다.
애플리케이션이 자주 액세스하는 데이터의 유형, 데이터를 검색하는 패턴과 빈도, 데이터의 크기를 고려하세요.
웹 애플리케이션 확장 시 캐싱 전략의 예는 다음과 같습니다.
| 전략 | |
|---|---|
| 객체 캐싱 | 객체 캐싱은 데이터베이스 쿼리 결과, API 응답 또는 HTML 프래그먼트와 같은 개별 객체를 캐싱하는 것을 의미합니다. 가장 많이 사용되는 옵션으로는 Redis, Memcached, Varnish가 있습니다. |
| 페이지 캐싱 | 페이지 캐싱에는 전체 웹페이지를 캐싱하는 작업이 포함됩니다. 이 옵션은 정적 콘텐츠에 적합하며 리버스 프록시, 정적 사이트 생성기 또는 CDN을 사용하여 구현할 수 있습니다. |
| 데이터베이스 및 쿼리 캐싱 | 데이터베이스 및 쿼리 캐싱이란 데이터베이스 서버의 부하를 줄이기 위해 자주 실행되는 데이터베이스 쿼리의 결과를 캐시하는 것을 의미합니다. |
| 전체 페이지 캐싱 | 전체 페이지 캐싱은 동적 콘텐츠에 사용할 수 있습니다. 서버 및 데이터베이스의 로드를 최소화하기 위해 렌더링된 HTML 페이지 전체를 캐시하는 것을 의미합니다. |
| 클라이언트 측 캐싱 | 클라이언트 측 캐싱은 사용자 기기에 로컬로 애셋을 저장하는 브라우저 캐싱과 같은 메커니즘을 의미합니다. cache-control 헤더를 지정하여 애셋이 브라우저에서 캐시되는 시간을 제어할 수 있습니다. |
캐싱은 애플리케이션이 증가된 사용자 트래픽과 데이터 수요를 효과적이고 효율적으로 처리할 수 있도록 하는 광범위한 성능 최적화 전략에서 중요한 구성요소입니다.
읽기 및 쓰기 확장
처리량 및 데이터 볼륨 요구사항을 잠재적 캐싱 최적화와 함께 고려하여 애플리케이션의 데이터 스토리지를 추가로 확장할 방법을 파악합니다. 데이터 스토리지 시스템을 선택할 때는 읽기 및 쓰기의 영향을 고려해야 합니다. 이를 위한 한 가지 방법은 애플리케이션에서 지원하는 작업 유형을 고려하고 이러한 사용 사례와 사용 패턴에 맞게 데이터 스토리지를 최적화하는 것입니다. 예를 들어 일부 작업은 비대칭 또는 대칭 확장의 이점을 활용할 수 있습니다.
비대칭 확장
경우에 따라 콘텐츠 기반 웹 애플리케이션에서 읽기 또는 쓰기 비대칭이 발생할 수 있습니다. 즉, 다른 유형의 작업에 비해 읽기 또는 쓰기 볼륨이 훨씬 더 많을 수 있습니다. 이러한 경우에는 그에 따라 데이터베이스를 확장하는 것이 중요합니다. 사용 중인 애플리케이션과 데이터 액세스 및 쓰기 방법을 고려하세요.
읽기 또는 쓰기 비대칭에 영향을 줄 수 있는 요인은 다음과 같습니다.
- 애플리케이션의 유형입니다. 일부 애플리케이션은 다른 애플리케이션보다 읽기 집약적입니다.
- 사용자 행동 사용자가 애플리케이션과 상호작용하는 방식이 읽기 또는 쓰기 비대칭에 영향을 줄 수 있습니다.
대칭 확장
대칭적 확장은 애플리케이션 성장에 따른 병목 현상 없이 읽기 및 쓰기 작업을 모두 선형적으로 확장할 수 있음을 의미합니다. 콘텐츠 기반 웹 애플리케이션에서 읽기 및 쓰기 작업에 대한 대칭 확장은 달성하기 어려울 수 있습니다. 특히 많은 양의 데이터와 많은 사용자 트래픽을 관리하는 경우 그렇습니다.
대칭 확장을 달성하기 위한 전략은 다음과 같습니다.
| 전략 | |
|---|---|
| 분산 데이터베이스 | Google Cloud Bigtable과 같은 데이터베이스는 여러 노드에 데이터를 배포하고 읽기 및 쓰기 작업을 위한 확장성을 제공하도록 구축되었습니다. |
| 데이터 분할 | 데이터 파티션 나누기는 데이터가 균등하게 분산되고 각 파티션 또는 샤드가 읽기 및 쓰기 작업을 둘 다 독립적으로 처리할 수 있도록 합니다. |
| 캐싱 레이어 | 즉시 사용 가능한 워크로드를 위한 캐싱 레이어 구현 자주 액세스하는 데이터를 캐시하여 읽기 작업에 대한 데이터베이스의 부하를 줄입니다. |
| 비동기 처리 | 비동기 처리를 사용하여 시간이 오래 걸리거나 긴급하지 않은 쓰기 작업을 백그라운드 프로세스 또는 큐에 오프로드할 수 있습니다. 애플리케이션은 쓰기가 완료될 때까지 기다리지 않고 읽기를 계속 처리합니다. |
대칭적 확장에는 프런트엔드에서 백엔드, 데이터베이스에서 캐싱 레이어까지 전체 애플리케이션 스택에 대한 포괄적인 접근 방식이 필요합니다. 대칭 확장은 성능 일관성, 균형 잡힌 리소스 사용률, 고가용성, 다양한 측정기준에 대한 확장성에 기여합니다. 필요에 따라 확장 전략을 조정하고 병목 현상이 발생할 때 이를 해결할 수 있도록 준비해야 합니다.