구성 요소
- 웹 브라우저 (클라이언트)
- 웹 서버
- 웹 애플리케이션 서버 (WAS)
- DB 서버
웹 브라우저
- 역할
a) Request / Response 전송
b) HTML, CSS 명세에 따라 HTML 파일 해석 및 표시 - 종류
: Mozilla Firefox, Google Chrome, Microsoft Edge, Opera 등 - 구성 요소
- 유저 인터페이스
- 브라우저 엔진
- 렌더링 엔진
- 네트워킹
- 자바스크립트 인터프리터
- UI 백엔드
- Data Persistence
웹 서버
- 역할
a) 웹 서버에서 처리할 수 없는 동적인 정보를 처리해서 웹 서버에 정적인 정보를 제공
b) 일반적으로 웹 서버의 기능을 내제하고 있어 웹 서버 없이도 서비스 가능함 - 종류
: Apache Tomcat, JBoss, WebLogic, JEUS 등
추가적인 내용
Jonathan Fulton의 “Web Architecture 101” 내용 중
로드 밸런서 (Load Balancer)
애플리케이션의 수평적 확장이 가능하게 해주는 역할
- 서버로 들어오는 요청을 복제/미러링 된 수많은 애플리케이션 서버 중 하나로 연결하고, 서버의 응답을 클라이언트로 전송해준다
- 모든 서버가 특정 요청을 같은 방식으로 처리하고, 로드 밸런서는 이 서버들에 과부하가 걸리지 않도록 들어오는 요청을 적절히 분배해준다
cf) 수평적 vs. 수직적 애플리케이션 확장
- 수평적 애플리케이션 확장: 더 많은 장치를 새로 추가하는 것
- 수직적 애플리케이션 확장: 이미 사용하고 있던 장치의 성능 (예: CPU, RAM)을 높이는 것
웹 애플리케이션 서버 (WAS)
사용자 요청이 들어오면 핵심 비즈니스 로직을 실행하고, 그 결과를 HTML에 담아 브라우저로 전송하는 역할
- 이 과정에서 데이터베이스, 캐싱 계층, 잡 큐, 검색 서비스, 기타 마이크로 서비스, 데이터/로그 큐 등 다양한 백엔드 인프라와 데이터를 주고 받는다
데이터베이스 서버
데이터 구조를 정의하고, 새로운 데이터를 삽입하고, 데이터 찾기, 수정, 삭제 등 데이터로 연산을 수행하는 역할
- 대부분은 WAS와 직접 통신
- 각각의 백엔드 서비스는 애플리케이션의 다른 영역과 분리된 자신만의 데이터베이스를 갖고 있을 수 있다
- NoSQL (Non-SQL): 대규모 웹 애플리케이션에 의해 생성되는 많은 양의 데이터를 처리하기 위해 등장한 최신 데이터베이스 기술의 집합
👉 SQL에서 파생된 기술 대부분은 수평적 확장이 어려우며, 특정 지점에 도달하면 수직적 확장만 가능하기 때문
캐싱 서비스
정보를 거의 O(1) 시간 안에 찾을 수 있는 키-값 데이터 저장소를 제공하는 역할
- 자원이 많이 소모되는 연산의 결과를 다시 계산하지 않고 캐시에서 가져와서 효율 상승
예) 데이터베이스의 쿼리 결과, 외부 서비스 호출 결과, 주어진 URL의 HTML 등
잡 큐 (Job Queue) & 잡 서버
- 잡 큐: 비동기적으로 실행될 작업 목록을 저장하고 있다
- 애플리케이션이 정기적인 일정이나 사용자에 의해 발생한 작업을 실행할 필요가 생기면, 해당 작업을 큐에 추가한다
- 제일 간단한 FIFO 큐를 사용하다가, 애플리케이션 규모에 따라 우선순위 큐가 필요해지기도 한다
2. 잡 서버: 작업을 처리한다
- 잡 큐를 가져와서 할 일이 있는지 확인하고, 있으면 큐에서 잡을 뽑아내서 실행한다
전체 텍스트 검색 서비스
많은 웹 애플리케이션이 사용자가 텍스트 입력을 하면, 검색을 하고 가장 ‘관련 있는’ 결과를 보여주는 기능을 제공한다. 이 기능을 가능하게 하는 것이 “전체 텍스트 검색”이라고 불리고, 이것은 쿼리 키워드를 포함하는 문서를 빠르게 찾기 위해 역 인덱스(inverted index)를 활용한다.
- 역 인덱스:
계정 서비스: 모든 사이트의 사용자 정보를 저장해서 교차 판매 기회를 더 쉽게 제공하고, 일관적인 사용자 경험을 간으하게 함
컨텐츠 서비스: 모든 비디오, 오디오, 이미지의 메타데이터를 저장한다. 또 콘텐츠 다운로드 인터페이스와 다운로드 이력을 보여주는 기능을 제공한다
결제 서비스: 고객이 카드로 결제할 수 있는 인터페이스를 제공한다
HTML → PDF 서비스 변환 서비스
데이터
데이터를 어떻게 다루는지가 기업 입장에서 매우 중요한데, 특정 규모에 도달하면 데이터를 제어, 저장, 분석하기 위해 데이터 파이프라인이 필요하기 때문이다
- 앱은 보통 사용자 상호작용으로 발생한 데이터를 데이터 ‘firehose’라 불리는 곳으로 전달한다. 그것은 데이터를 받아들이고 처리할 수 있는 스트리밍 인터페이스를 제공한다. 가공되지 않은 원시 데이터는 변형되거나(transformed) 추가 정보와 함께(augmented) 다른 firehose로 전달된다. AWS Kinesis, Kafka는 이런 작업을 위한 대표적인 기술이다.
- 원시 데이터와 최종 데이터는 모두 클라우드 스토리지에 저장된다. AWS Kinesis는 원시 데이터를 AWS의 클라우드 스토리지(S3)에 저장할 수 있도록 매우 쉽게 사용할 수 있는 ‘firehose’로 불리는 설정을 제공한다.
- 변형/추가된 데이터는 종종 분석을 위해 데이터 웨어하우스(DW)에서 로드된다. 큰 기업에서는 Oracle이나 기타 독점적인 웨어하우스 기술을 사용하고, 스타트업 업계에서는 Redshift를 많이 사용하고 있으며 점유율도 계속 오르고 있다. 만약 데이터가 충분히 축적되었다면 분석을 위해 Hadoop 같은 NoSQL MapReduce 기술이 필요하게 될 것이다.
클라우드 스토리지
인터넷을 통해 데이터를 저장, 접근, 공유할 수 있는 단순하고 확장성 있는 방법
- 로컬 파일 시스템에 저장할 수 있는 거의 모든 것을 클라우드에 저장하고 접근할 수 있다
- 예: 아마존의 S3
CDN (Content Delivery Network)
HTML, CSS, JavaScript, 이미지 같은 정적인 데이터를 웹을 통해 1개의 원본(origin) 서버를 사용하는 것 보다 빠르게 제공하기 위한 기술
- 컨텐츠를 전 세계의 많은 ‘엣지(edge)’ 서버에 분산시켜 저장하는 방식으로 동작
- 사용자는 데이터를 원본 서버 대신 본인에게 가장 가까운 엣지 서버로부터 다운로드 하기 때문에 빠르게 데이터를 가져올 수 있다
🔗 참고한 글:
https://blog.rhostem.com/posts/2018-07-22-web-architecture-101
