기본 웹 아키텍처 개념

최신 웹 애플리케이션 아키텍처 개요

https://www.storyblocks.com/ 웹사이트(영상, 오디오, 이미지 등 다양한 스톡 미디어를 제공하는 구독 기반 플랫폼)의 아키텍쳐 표현

 

사용자가 "숲 속의 강렬하고 아름다운 안개와 햇살"을 검색하여 Storyblocks의 이미지 상세 페이지에 접속하면 다음과 같은 일련의 과정이 빠르게 진행됩니다.

1. (1) DNS: 사용자가 브라우저에 Storyblocks 주소를 입력하면, 가장 먼저 (1) DNS 서버에 요청하여 해당 주소의 실제 IP 주소를 찾습니다. 이는 Storyblocks 서버로 연결하기 위한 첫 번째 단계입니다.
2. (사용자 브라우저) → (2) Load Balancer: IP 주소를 얻은 브라우저는 Storyblocks 서버로 접속을 시도합니다. 이때, 사용자의 요청은 (2)로드 밸런서에 먼저 도착합니다. (접속 및 로드 밸런싱) 로드 밸런서는 여러 대의 (3)웹 앱 서버가 효율적으로 작업을 분담할 수 있도록 트래픽을 관리하며, 현재 상황에 맞춰 적절한 서버를 선택하여 요청을 전달합니다.
3. (2) Load Balancer → (3) Web app servers: 로드 밸런서에 의해 선택된 (3)웹 앱 서버는 사용자의 요청을 처리하기 시작합니다. (데이터 조회) 이 서버는 먼저 (5)캐싱 서비스에서 요청된 이미지에 대한 정보가 있는지 확인하여 빠르게 응답하려고 시도합니다. 만약 캐시에 정보가 없거나, 상세 정보를 위해 추가적인 데이터가 필요하다면 (4)데이터베이스에 접근하여 필요한 정보를 가져옵니다.
4. (3) Web app servers → (6a) 작업 대기열 → (6b) Job servers → (4) Database: (비동기 작업 처리) 이미지의 색상 프로필이 아직 생성되지 않았다면, 웹 앱 서버는 이 작업을 (6a) 작업 대기열에 등록합니다. 이후 (6b) 작업 서버가 이 작업을 비동기적으로 처리하고, 완료되면 (4)데이터베이스에 그 결과를 저장합니다.
   (*색상 프로필은 특정 장치나 색 공간의 색상 특성을 설명하는 일종의 "설명서" 역할)
5. (3) Web app servers → (7) Full text search service: (유사 이미지 검색) 사용자가 보고 있는 이미지와 유사한 이미지를 추천하기 위해, 웹 앱 서버는 이미지의 제목을 (7) 전체 텍스트 검색 서비스에 전달하여 관련 이미지를 검색합니다.
   (*이미지들을 텍스트로 관리하고 있음)
6. (3) Web app servers → (8) Services(api 집합체): (사용자 정보 확인) 만약 사용자가 Storyblocks에 로그인한 상태라면, 웹 앱 서버는 (8)계정 서비스에 사용자의 계정 정보를 조회하여 맞춤형 경험을 제공하거나 사용자별 권한을 확인합니다.
7. (3) Web app servers → (9a) Data Firehose → (9b) Cloud storage → (9c) Data warehouse: (사용자 활동 기록 수집) 사용자가 이미지 상세 페이지를 조회했다는 정보는 (9a) 데이터 파이어호스를 통해 실시간으로 수집되어 (9b) 클라우드 스토리지에 저장되고, 최종적으로 (9c) 데이터 웨어하우스로 통합됩니다. 이 데이터는 분석가들이 서비스 개선 및 비즈니스 의사 결정을 위한 중요한 자료로 활용합니다.
   *데이터 파이어호스 : AWS(Amazon Web Services)에서 제공하는 서비스로, 실시간 스트리밍 데이터를 안정적이고 확장 가능하게 수집, 변환, 로드하여 데이터 레이크, 데이터 웨어하우스 및 분석 서비스로 전달하는 완전 관리형 서비스(이름처럼 끊임없이 쏟아지는 데이터를 소방 호스처럼 원하는 목적지로 흘려보내는 역할)
8. (3) Web app servers → (2) Load Balancer → (사용자 브라우저): (HTML 렌더링 및 전송) 필요한 데이터 조회가 완료되면, 웹 앱 서버는 이미지 정보, 관련 데이터, 그리고 사용자 정보 등을 기반으로 웹페이지의 HTML 코드를 생성하여 (2)로드 밸런서를 거쳐 사용자의 브라우저로 전송합니다.
9. (사용자 브라우저) → (11) CDN: (리소스 로딩) 전송된 HTML에는 웹페이지를 구성하는 이미지, 스타일시트(CSS), 자바스크립트 파일 등에 대한 정보가 담겨 있습니다. 브라우저는 이러한 정적 자원들을 (11)CDN(Content Delivery Network)에 요청하여 다운로드합니다. CDN은 지리적으로 가까운 서버에서 콘텐츠를 제공하여 페이지 로딩 속도를 최적화합니다.
10. (사용자 브라우저): (페이지 표시) 마지막으로, 브라우저는 다운로드한 HTML, CSS, 자바스크립트 파일들을 해석하고 렌더링하여 사용자에게 시각적으로 완성된 웹페이지를 보여줍니다.

핵심: 사용자가 하나의 이미지 페이지를 보는 간단한 행위 뒤에는 DNS 조회, 로드 밸런싱, 캐싱, 데이터베이스 접근, 비동기 작업 처리, 검색 서비스 호출, 사용자 정보 조회, 데이터 로깅, HTML 렌더링, CDN을 통한 리소스 로딩 등 다양한 기술적 과정들이 복잡하게 얽혀서 작동하고 있습니다.

 

 

이상적인 웹 서비스 흐름으로 볼 수 있는 이유:

• 로드 밸런싱 (2): 트래픽이 많은 웹 서비스에서 로드 밸런서는 필수적입니다. 여러 대의 웹 서버 (3)에 트래픽을 분산시켜 특정 서버에 과부하가 걸리는 것을 방지하고, 서비스의 안정성과 가용성을 높여줍니다.
• 캐싱 서비스 (5): 자주 사용되는 데이터를 캐싱 계층에 저장함으로써 데이터베이스 (4)에 대한 불필요한 접근을 줄이고, 응답 속도를 크게 향상시킵니다. 사용자 경험 개선에 중요한 역할을 합니다.
• 비동기 작업 처리 (6a, 6b): 시간이 오래 걸리는 작업(예: 이미지 처리)을 별도의 작업 큐와 작업 서버를 통해 비동기적으로 처리함으로써, 사용자 요청에 대한 응답성을 유지합니다. 사용자 경험 저하를 방지하는 중요한 패턴입니다.
• 전체 텍스트 검색 서비스 (7): 방대한 양의 데이터에서 빠르고 정확하게 원하는 정보를 검색하는 데 필수적입니다. 사용자 편의성을 높이는 중요한 기능입니다.
• 마이크로서비스 아키텍처 (8 Services): 다양한 기능을 독립적인 서비스로 분리함으로써 개발, 배포, 확장이 용이해집니다. 전체 시스템의 안정성을 높이고 유지보수성을 향상시키는 현대적인 아키텍처 패턴입니다. (비록 하나의 'Services' 블록으로 표현되었지만, 실제로는 여러 개의 독립적인 서비스로 구성될 가능성이 높습니다.)
• 데이터 파이프라인 (9a, 9b, 9c): 사용자 활동 데이터를 효율적으로 수집, 저장, 분석하는 파이프라인은 서비스 개선, 비즈니스 통찰력 확보에 필수적입니다.
• CDN (11): 정적 자원(이미지, CSS, JavaScript 등)을 사용자에게 더 가까운 서버에서 제공함으로써 페이지 로딩 속도를 크게 개선하고 네트워크 트래픽을 최적화합니다. 사용자 경험 향상에 중요한 요소입니다.
• 명확한 역할 분담: 각 구성 요소가 특정 역할을 수행하며 서로 협력하는 구조는 시스템의 복잡성을 줄이고 유지보수성을 높입니다.

하지만 모든 웹 서비스가 완전히 동일한 구조를 따르는 것은 아닙니다. 서비스의 규모, 복잡성, 요구사항에 따라 아키텍처는 얼마든지 달라질 수 있습니다. 예를 들어, 트래픽이 적은 소규모 서비스라면 로드 밸런서나 별도의 작업 큐가 필요 없을 수도 있습니다.

결론적으로, 제시된 아키텍처는 확장성, 안정성, 성능, 유지보수성을 고려한 현대적인 웹 서비스의 이상적인 모델 중 하나라고 볼 수 있습니다. 많은 기업들이 이러한 구조를 참고하여 자사의 웹 서비스를 설계하고 발전시켜 나가고 있습니다.