알아놓으면 좋은 10가지 모던 웹 아키텍쳐 컨셉

2021.08.13
4 minutes read
2268 views
thumbnail

10 Must-Know Concepts of Modern Web Architecture

이 글에 대한 번역과 작은 제 생각들을 작성해보았습니다.

들어가면서

Tim Berners-Lee님이 WWW를 발명한 후로 약 30년 정도가 지났습니다.

급격하게 websites와 web application이 발전되면서 다양한 온라인 행동을 브라우저를 통해서 진행할 수 있게 되었습니다.

최근에는 물리적 서비스의 모든 형태가 Cloud ecosystem 으로 옮겨지기 시작했습니다.

Modern web application architecture는 모든 개발자들이 알아야만 하는 클라우드 컴퓨팅 구성 요소가 있습니다.

저자는 Netflix, Medium, Airbnb, Facebook과 같은 거대 기업들에 대해 연구하고 다음 모던 웹 아키텍쳐를 구성하는 10가지 구성 요소에 대해 설명합니다.

  1. Server
  2. Client
  3. Microservice
  4. Cloud Function
  5. Load Balancer
  6. API Gateway
  7. Message Queue
  8. CDN
  9. Database
  10. Services

1. Server

서버는 개인 네트워크나 인터넷을 통해 한 가지 서비스(또는 여러 서비스들)을 제공하는 컴퓨터를 말합니다.

디바이스(클라이언트로 지칭되는)는 서버에 연결할 수 있으며 제공된 서비스를 다른 네트워크 Port를 통해서 받을 수 있습니다.

서버는 제공되는 서비스에 기반하여 일반적으로 이름이 붙여집니다.
예를 들어, 만약 80 포트로부터 HTTP request를 수신하는 서버는 web server라고 불리어집니다. 그 외 파일 서버, 메일 서버, 인증 서버, DB 서버, ap 서버 등이 있습니다.

요즘에는 가상 서버들은 베어메탈 서버 보다 더 유명합니다.

베어메탈 서버 : 가상화를 위한 하이퍼바이저 OS 없이 물리 서버를 그대로 제공하는 것. 다른 클라우드 사용자의 영향을 받지 않는 단독 서버를 사용하는 것입니다.
즉, 물리적 서버 그대로를 서비스 받는 서버 입니다.

클라우드 서비스 제공자들은 hypervisor와 가상화 소프트웨어를 사용함으로써 그들의 물리 하드웨어 위에 가상 머신을 생성합니다.

클라우드 서비스 provider 3대장과 그 가상 머신 서비스들은...

2. Client

클라이언트는 서비스나 리소스를 얻기위해 그것을 제공하는 서버에 연결되는 디바이스 입니다.

클라이언트는 컴퓨터, 웹사이트, 소프트웨어, 임베디드 시스템이 될 수 있습니다.
예를 들어, 웹사이트를 방문한다면 브라우저가 클라이언트가 되는 것입니다.

서버 이름을 붙이는 것과 유사하게 클라이언트도 그들이 사용하는 서비스에 따라 이름이 붙여집니다. 이메일 클라이언트, 웹 클라이언트, DB 클라이언트, Chat 클라이언트 등이 있습니다.

클라이언트-서버 모델에서 특정 유저에게 특정 서비스를 제공하는 인증과 같은 기술들이 들어가게 됩니다.
여기에는 2가지 클라이언트 타입이 있습니다:

  • thin client: 일반적인 SPA(Single Page Application)과 같이 서버에 전적으로 의존하는 클라이언트 입니다.
  • thick client: thin client와 다르게 서버에 의존하지 않습니다. 서버에 데이터를 유지하는 standalone 어플리케이션과 유사합니다.

3. Microservice

Microservice는 어플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍쳐(SOA) 스타일의 일종인 소프트웨어 개발 기법입니다.

일반적인 Monolithic 클라이언트-서버 기반 시스템은 몇가지 단점이 있습니다.
Monolithic 시스템에서 발생되는 에러는 전체 시스템에 영향을 미칩니다. 그래서 유지보수 작업 자체가 문제가 될 수 있습니다.

여기서 이러한 연결고리들을 제거하고자 나온게 Microservice 패턴입니다.

Microservice 패턴은 거대한 Monolithic 시스템을 Microservice라고 불리는 작은 서비스들로 나누어 decompose 하는 것을 목표로 둡니다.

Microservice는 특정 프로세스를 담당하는 느슨하게 결합되고 독립된 서비스를 가리킵니다.

만약 사용자 관리 시스템을 개발한다면, 이 시스템의 Microservice은 사용자 등록 서비스, 보고서 생성, 결제 프로세스등이 있을 수 있습니다.

웹 기반 소프트웨어 시스템에서는 대부분의 Microservice는 가상 머신 또는 가상 컨테이너 내에서 동작하는 RESTful APIs 입니다.

4. Cloud Function

서버 관리에 대한 걱정은 줄이고 코드 실행과 컴퓨팅 시간에 집중

- ncloud 클라우드 Function 소개글

Microservice는 코드 복잡성이 증가되면 무거워지고 유지보수하기 어렵게 될 수 있습니다.

또한, 일반적으로 가상 머신이나 컨테이너에서 클라이언트 연결을 항상 기다리기 때문에 인프라 비용이 증가할 수 있습니다.

serverless 개념은 거대 시스템을 serverless function(aka cloud function)이라고 하는 유지관리 하기 쉽게 더 작은 기능으로 쪼개는 방법을 도입했습니다.

serverless는 서버가 없다는 뜻이 아닙니다. 관리해야 할 서버가 없다는 것을 말합니다.

cloud function은 요청이 들어올 때에 활성화 됩니다.
그렇지 않다면 cloud function은 hibernation(수면) 모드로 들어갑니다.

cloud function의 lifecycle은 각 클라우드 서비스 제공자에 의해 개발된 특정 서버에 의해 다루어집니다.

개인이나 스타트업 기업은 적은 인프라 비용 때문에 cloud function을 선택하기도 합니다.

5. Load Balancer

둘 혹은 셋 이상의 자원에게 작업을 나누는 것을 의미합니다.
- load balancing_위키

Web 아키텍쳐에서 로드 밸런서는 Web 트래픽을 가용성에 따라 다른 서버로 보내는 구성요소입니다.

로드 밸런서 타입에는 크게 2가지가 있습니다.

  • HLB(Hardware-based Load Balancer)
  • SLB(Software-based Load Balancer)

요즘엔 기본적으로 HLB가 비싸고 물리 서버가 필요하기 때문에 HLB보단 SLB가 더 선호됩니다.

현재는 거의 모든 클라우드 서비스 provider에서 서비스들 중에 잘 알려진 서비스형(as-a-service) 모델을 사용한 로드 밸런서를 통합하여 제공합니다.

6. API Gateway

Amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 생성, 게시, 유지 관리, 모니터링 및 보안 유지할 수 있도록 하는 완전관리형 서비스입니다.

- aws api gateway

aws-api-gateway

Web 어플리케이션은 다수의 API를 가질 수 있습니다. 그리고 모든 API는 사용제한범위 를 벗어나는 사용으로부터 보호되어져야 합니다.

API Gateway는 다수 API들이나 다른 서비스들로 접근할 수 있는 single point를 제공합니다.(흡사 Load Balancer와 유사합니다. )

API Gateway는 모든 클라이언트 요청을 매핑된 서비스로 보냅니다. API 관리 시스템의 한 부분으로 제공되는 것이 일반적입니다.
(API 관리 시스템은 API를 관리할 수 있는 GUI를 제공합니다.)

API Gateway는 모니터링, 속도 제한, 사용율, 버전관리 등과 같은 통합된 다양한 서비스를 제공합니다.
대게 RESTful API와 함께 제공되지만 SOAP, GraphQL, gRPC, TCP 등도 지원합니다.

7. Message Queue

마이크로서비스로 제공된 아키텍쳐에서 각 서비스들 사이에 RESTful API메시지 큐를 이용해 통신합니다.

메시지 큐는 마이크로서비스 사이에 pub-sub 아키텍쳐를 가진 비동기 메시지 채널을 만듭니다.

메시지 큐는 동기식 RESTful 인터페이스에 비해 몇가지 이점이 있습니다.
예를 들어 만약 REST 요청이 실패했을 때, 클라이언트(또는 initiator)가 오류 처리에 대한 책임을 가져가야 합니다. 또한, 오류를 일으켰던 REST 메시지를 버리게 되며 아무 곳에도 저장하지 않습니다.

반면, 메시지 큐는 모든 메시지를 유지합니다.

그러므로 생산자가 메시지를 보낼 때 소비자가 실패한다면 소비자는 다시 시작될 때 특정 메시지를 pick up 할 수 있습니다.

이러한 이점은 트랜잭션 안정성이 높아야되는 아키텍쳐일 때 메시지 큐를 선택할 경우 이점이 될 수 있습니다.

kafka라는 잘 알져진 시스템이 있습니다.

AWS에서는 SQS 라는 이름으로 제공합니다.

8. CDN

Content Delivery Network: 콘텐츠 전송 네트워크

CDN는 웹 어플리케이션의 성능, 가용성, 보안을 향상시키기 위해 정적 콘텐츠를 캐쉬하는 지리적으로 분산된 서버를 가리킵니다.

일반적으로 웹 어플리케이션은 다양한 리소스로 구성됩니다. 이미지, 비디오, CSS 파일, JS 파일, HTML 파일 등이 있습니다.

사용자들이 웹 어플리케이션을 방문할 때마다 각 사용자들의 브라우저는 서버로부터 리소스를 받을 것입니다.
만약 물리적으로 서버 위치와 멀리 있는 사용자가 방문한다면 페이지 로딩 시간이 증가할 것입니다.(상식적으로)

CDN은 전 세계에 있는 서버들에 정적 컨텐츠를 캐쉬합니다. 그리고 클라이언트와 더 가까운 위치에서 제공하도록 하여 빠르게 로드할 수 있게 해줍니다.

더욱이 CDN 캐싱 서버가 원래 서버에 대한 프록시 서버 역할을 하기 때문에 DDoS 공격을 방어하거나 완화할 수 있습니다.

9. Database

Database(DB)는 데이터 다양한 형태의 정보들을 저장하는 구성 요소 입니다.

Database 유형에는 크게 2가지 종류가 있고 세세하게 몇 가지 종류가 더 있습니다.

  • SQL: 전통적인 관계형 데이터베이스
  • No-SQL: SQL(전통적인 관계형 데이터베이스)이 아닌 비관계형 데이터 베이스
    • Key-Value
    • Document
    • Graph
    • ...

데이터베이스 서버는 클라이언트와 통신 할 때 각 데이터베이스마다 사용되는 커뮤니케이션 프로토콜을 사용합니다.
예를 들어, MySQL은 MySQL Protocol을 사용합니다.

웹 설계자는 실제 요구 사항에 따라 데이터베이스 타입을 결정해야 합니다.
예를 들어, 만약 unique ID에 기반한 많은 user session을 저장해야될 필요가 있을 경우 key-value 타입의 No SQL DB가 좋은 결정이 될 수 있습니다.

10. Services

Web 어플리케이션은 인증, emaling, loggin, 모니터링, 머신 러닝, 결제 등등과 같은 다른 서비스들을 요구합니다.

또한 Web 어플리케이션은 개발, 아키텍쳐, 배포 시스템, CI/CD, Database, 호스팅, CDN, Searching/Indexing 등등이 필요합니다.

많은 오픈 소스 프레임워크는 이러한 서비스에 대해서 충족합니다. 그러나 이러한 오픈 소스 서비스는 설치하기 위한 인프라도 같이 필요합니다.

최근에는 많은 기업들이 as-a-service 모델 형식의 클라우드 서비스를 제공합니다.

이러한 서비스들을 잘 찾고 잘 이용한다면 비용이나 많은 노력들을 줄일 수 있고 최신 기술들을 적용할 수 있습니다.

저 또한 그러고 있고, 이런 부분에 있어서 정보라던지 시야를 넓히고 있어야 될 것 같습니다.

마무리

요즘에는 다양한 곳에서 많은 클라우드 서비스들이 많습니다.

aws는 말할 것도 없이 이런 것들 조차 지원돼? 하는 것들도 많습니다.

최근에는 개발 플랫폼 조차 github codespace처럼 브라우저에서도 개발할 수 있는 상당한 수준들의 플랫폼들이 나오고 있습니다.

항상 시야를 열고 다양한 정보를 받아들일 마음을 가지는 게 중요한 것 같습니다.

이젠 모든 플랫폼에서 클라우드 시대라는 것을 실감하고 있는 나날들이 이어져 나가는 것 같습니다.