Skip to main content

대용량 서버 구축을 위한 주요 기술 및 고려사항

오늘은 클라우드 기반 대용량 서버 구축을 위한 주요 기술 및 고려사항에 대해 다루어 보려고 합니다. 대용량 서버 구축의 범위가 너무나 광범위 하고 다양하기 때문에, 이 글에서는 직접 경험한 사례를 바탕으로 클라우드 기반 대용량 처리를 위한 인프라의 기본 사항부터 성능 최적화와 보안에 대한 내용을 다루고자 합니다. 하나 하나 구체적인 내용을 다루기에는 너무 광범위한 내용이지만 대용량 서버 구축을 위한 기본적인 사항들을 이해 하시는데 도움이 되었으면 합니다.

오늘의 내용은 아래의 순서로 다루어 질 예정입니다.

  • 대용량 서버 구축을 위한 주요 고려 사항
  • 대용량 서버 구축 관련 주요 기술
  • 글로벌 서비스 대용량 서버 아키텍처 사례 그럼 시작 해보겠습니다.

1. 대용량 서버 구축을 위한 주요 고려 사항​

대용량 서버를 구축할 때는 서버가 높은 트래픽 부하를 처리하고 안정적인 성능을 제공할 수 있도록 하는 것이 필수적입니다. 그러기 위해서는 아래와 같은 요소들을 고려해야 합니다.

1.1. 확장성 (Scalability)​

  • 대용량 서버는 수평 확장 및 수직 확장을 모두 지원하도록 서버 아키텍처를 설계 되어야 합니다. 이를 통해 인프라는 성능 저하 없이 증가하는 트래픽과 수요를 처리할 수 있습니다.
  • 수평확장 (Horizontal Scaling)은 자원이 부족 할때 서버를 추가하는 확장성을 의미 합니다.
  • 수직확장 (Vertical Scaling)은 기존 서버의 리소스(CPU, Memory, Storage 등)를 증가가 시키는 확장성을 의미 합니다.

1.2. 고가용성 및 중복성 (High availability and redundancy)​

  • 하드웨어, 데이터 및 네트워크 구성 요소 전반에 걸쳐 중복성 있게 구현하여 다운타임을 최소화하고 원활한 작동을 보장합니다. 로드 밸런싱(Load Balancing), 클러스터링(Clustering) 및 복제(Replication)와 같은 기술은 고가용성(high availability)과 높은 장애시 복구성(fault tolerance)을 유지하는 데 도움이 됩니다.

1.3. 성능 최적화 (Performance optimization)​

성능 최적화 에는 캐싱(Caching), 데이터베이스 튜닝 및 효율적인 리소스 할당을 통해 서버 성능을 최적화합니다. 또한 AWS Cloud Front또는 Akamai 와 같은 Content Delivery Networks(CDN)를 사용하여 정적 자산을 배포하고 최종 사용자의 대기 시간을 최소화 할수 있습니다.

1.4 보안 (Security)​

보안 통신 프로토콜(TLS/SSL), 방화벽(WAF), 침입 탐지 시스템(IDS) 및 정기 보안 감사를 포함한 모범 사례를 구현하여 잠재적인 위협으로부터 서버 인프라를 보호합니다. 또한 적절한 접근 액세스 제어, 데이터 암호화 및 시기 적절한 소프트웨어 업데이트를 적용 합니다.

1.5 인프라 모니터링 및 관리 (Infrastructure monitoring and management)​

대용량 서버 구성에서는 인프라 모니터링이 필수적입니다. 모니터링 도구를 구현하여 서버 성능, 리소스 활용 및 잠재적인 문제를 추적합니다. 또한 로그를 정기적으로 검토하여 사용자에게 영향을 미치기 전에 문제를 식별하고 해결 할 수 있습니다.

1.6 기타 고려사항​

  • 백업 및 재해 복구 (Backup and disaster recovery): 데이터 및 서버 구성에 대한 백업 절차를 수립합니다. 예상치 못한 사고가 발생할 경우 서비스를 신속하게 복원할 수 있도록 재해 복구 계획을 수립 합니다.
  • 네트워크 및 대기 시간(Network and latency): 올바른 서버 위치를 선택하고 효율적인 라우팅을 사용하며 Anycast 또는 GeoDNS와 같은 기술을 활용하여 네트워크 성능을 최적화하고 대기 시간을 줄입니다.
  • 하드웨어 및 소프트웨어 선택(Hardware and software selection): 서버 요구 사항에 따라 CPU, RAM 및 스토리지와 같은 적절한 하드웨어 구성 요소를 선택합니다. 성능 및 확장성 목표에 부합하는 적절한 운영 체제 및 서버 소프트웨어를 선택합니다.
  • 비용 효율성(Cost-effectiveness): 하드웨어, 소프트웨어, 및 유지 관리 비용을 포함하여 서버 인프라의 총 비용을 평가 하고 개선해나갑니다. 클라우드 서비스를 이용 할 경우 확장성, 유연성 및 비용 절감에 용이 합니다.

이러한 주요 고려 사항을 반영하여 뛰어난 성능, 안정성 및 보안을 제공하는 대용량 서버를 구축할 수 있습니다.

2. 대용량 서버 구축 관련 주요 기술​

이번에는 클라우드 서비스와 기술을 활용하여 확장 가능하고 효율적인 인프라를 구축에 필요한 주요 기술들을 정리 해보았습니다. 먼저 대용량 서버 구축을 위해 도움이 되는 기본 용어들과 함께 필요한 기술들을 정리 해보겠습니다.

2.1 클라우드 컴퓨팅 기본 사항​

이미 잘 알고 계신 내용일 수 있지만 클라우드 컴퓨팅은 인터넷을 통해 컴퓨팅 리소스를 제공하는 서비스입니다. 주요 클라우두 서비스 업체들은 Amazon Web Services(AWS), Microsoft Azure 및 Google Cloud Platform(GCP)등이 있고 기본이 되는 서비스 들로는 컴퓨팅 인스턴스(AWS EC2, Azure Virtual Machines, GCP Compute Engine), 스토리지(AWS S3, Azure Blob Storage, GCP Cloud Storage) 및 데이터베이스(AWS RDS, Azure SQL Database, GCP Cloud SQL) 등이 있습니다.

2.2 확장성 및 고가용성 (Scalability and high availability: HA)​

확장성 및 고가용성을 위한 클라우드 기술은 크게 부하 분산 기능과 자동 확장기능 두 가지로 나눌 수 있습니다.

  • 부하 분산: AWS ELB, Azure Load Balancer, GCP Cloud Load Balancing
  • 자동 확장기능: AWS Auto Scaling, Azure Virtual Machine Scale Sets, GCP Autoscaler

또한 확장 가능한 클라우드 애플리케이션 구축을 위해서는 분산 시스템(distributed systems) 및 마이크로서비스 아키텍처(microservices architecture)를 적용 해볼수도 있습니다.

2.3 성능 최적화​

성능 최적화를 위한 주요 기술로는 캐싱, 콘텐츠 전송 네트워크(CDN) 등이 있습니다. 캐싱을 위해 많이 쓰이는 서버들은 Redis, RabbitMQ, Memcached 등이 있습니다. 캐싱 서버의 경우 AWS, Azure, GCP에서 제공하는 메니지드 서비스를 이용 할 수 있습니다.

  • 캐싱: Amazon ElastiCache, Azure Redis Cache 및 GCP Cloud Memorystore 등
  • CDN: AWS CloudFront, Azure CDN, GCP Cloud CDN, Akamai 등

2.4 보안 및 모니터링:​

대규모 서비스를 안정적으로 운영하고 보안을 유지하기 위해서는 보안과 모니터링이 필수 입니다. 보안을 위해서는 아래의 내용들을 검토하여 필요한 부분을 적용 합니다.

  • Private Network 구성 및 방화벽(Security Group) 설정
  • 액세스 제어, 암호화 적용
  • Web Application Firewall(WAF) 설정
  • 보안 통신 프로토콜(HTTPS, TLS/SSL) 적용
  • 그 외 침입 탐지 시스템(IDS) 등 보안 관련 서비스 적용

모니터링을 위해서는 기본적으로 AWS CloudWatch, Azure Monitor, GCP Stackdriver와 같은 기본 클라우드 기반 모니터링 및 로깅 도구를 활용 할수도 있지만 Datadog나 국내 업체인 Whatap과 같은 모니터링 서비스를 활용 할수도 있습니다.

또한 Grafana, Prometheus와 같은 오픈소스 모니터링 도구를 활용 할수도 있습니다. Grafana, Prometheus를 통해 다양한 성능 메트릭과 시스템 상태 지표를 시각화하고 추적 할 수 있습니다.

  • Grafana: Grafana는 사용자가 대화형 대시보드를 생성, 탐색 및 공유할 수 있는 강력하고 기능이 풍부한 데이터 시각화 및 모니터링 플랫폼입니다. Prometheus, InfluxDB, Elasticsearch, Graphite 등을 포함한 광범위한 데이터 소스를 지원합니다. Grafana는 사용자가 데이터를 이해하고 분석할 수 있도록 유연한 쿼리 편집기와 그래프, 히트맵, 게이지 및 테이블과 같은 다양한 시각화 옵션을 제공합니다.

Grafana의 주요 기능은 다음과 같습니다.

다중 데이터 소스 지원: Grafana는 수많은 시계열 데이터베이스, SQL 데이터베이스 및 기타 데이터 소스와 통합할 수 있습니다.
대시보드 템플릿: 사용자는 대규모 환경을 보다 쉽게 ​​관리할 수 있도록 변수를 사용하여 재사용 가능한 대시보드 템플릿을 만들 수 있습니다.
경고: Grafana는 특정 임계값 및 조건에 따라 알림을 보내는 강력한 경고 기능을 제공합니다.
주석: 사용자는 그래프에 주석을 추가하여 특정 이벤트에 대한 컨텍스트 및 설명을 제공할 수 있습니다.
플러그인 지원: Grafana에는 추가 데이터 소스, 패널 및 애플리케이션을 위한 광범위한 커뮤니티 구축 플러그인 라이브러리가 있습니다.
  • Prometheus:

Prometheus는 안정성과 확장성을 위해 설계된 오픈 소스 모니터링 및 경고 시스템입니다. 컨테이너화 및 마이크로서비스 기반 환경을 모니터링하는 데 특히 적합합니다. Prometheus는 시계열 메트릭 데이터를 수집하고 저장하며, 원하는 대상(예: 애플리케이션, 서비스 또는 기타 모니터링 시스템)에서 메트릭을 주기적으로 수집 합니다.

Prometheus의 주요 기능은 다음과 같습니다.

다차원 데이터 모델: Prometheus는 키-값 쌍으로 식별되는 메트릭이 있는 유연한 데이터 모델을 사용하여 데이터를 쉽게 쿼리하고 필터링할 수 있습니다.
강력한 쿼리 언어: Prometheus의 기본 쿼리 언어인 PromQL을 사용하면 수집된 데이터에 대해 복잡한 쿼리 및 집계를 수행할 수 있습니다.
저장 및 보존: Prometheus는 맞춤형 고효율 스토리지 형식을 사용하여 데이터를 로컬에 저장하고 구성 가능한 보존 정책을 지원합니다.
서비스 검색: Prometheus는 Kubernetes, Consul 또는 DNS와 같은 다양한 서비스 검색 메커니즘을 통해 동적 환경에서 대상을 자동으로 검색하고 모니터링할 수 있습니다.
알림: Prometheus는 Alertmanager 구성 요소와 통합되어 사용자 정의 규칙에 따라 알림 및 알림을 처리합니다.

그리고 대용량 모니터링을 위해서는 대용량 로그 수집 및 처리 기술이 필요하며 아래와 같은 기술 및 서비스 들을 활용 할수도 있습니다.

  • filebeat, logstash, fluentd 등 분산 로그 수집기
  • Elasticsearch 등 로그 저장소
  • AWS Kinesis Data Streams, Azure Event Hubs, GCP Pub/Sub 등 로그 전송
  • AWS Kinesis Data Analytics, Azure Stream Analytics, GCP Dataflow 등 로그 처리

2.3 서버리스 컴퓨팅​

AWS Lambda, Azure Functions, GCP Cloud Functions와 같은 FaaS(Function as a Service) 플랫폼을 비롯한 서버리스 컴퓨팅을 고려 해볼수도 있습니다. 서버리스 컴퓨팅의 경우 서버를 관리할 필요가 없으며, 서버를 프로비저닝하고 관리하는 데 드는 비용을 절감 할 수 있습니다.

서버리스 컴퓨팅의 경우 아래와 같은 장단점이 있으니 팀내 자원 및 요구사항에 맞게 적절히 활용하시기 바랍니다.

서버리스 컴퓨팅의 장점:

  • 비용 효율성: 서버리스 컴퓨팅은 실제 실행 시간과 소비된 리소스에 대해서만 비용을 지불하는 종량제 가격 책정 모델을 따릅니다. 따라서 사전 할당된 리소스에 대해 비용을 지불하는 기존 서버 기반 호스팅에 비해 비용을 절감할 수 있습니다.
  • 확장성: 서버리스 플랫폼은 수요에 따라 애플리케이션을 자동으로 확장하여 수동 개입 없이 많은 수의 요청을 처리할 수 있습니다. 따라서 확장 리소스를 프로비저닝하고 관리할 필요가 없으므로 애플리케이션 개발에 집중할 수 있습니다.
  • 운영 오버헤드 감소: 서버리스 컴퓨팅을 통해 클라우드 공급자는 서버 프로비저닝, 패치 및 유지 관리를 포함하여 기본 인프라를 관리할 책임이 있습니다. 이렇게 하면 서버 관리와 관련된 운영 오버헤드 및 복잡성이 줄어듭니다.

서버리스 컴퓨팅의 단점:

  • 벤더 종속: 서버리스 플랫폼에는 독점 API, 구성 및 서비스가 있는 경우가 많기 때문에 클라우드 서비스(AWS, GCP, Azure 등) 간에 전환하거나 기존 서버 기반 인프라로 다시 마이그레이션하기 어려울 수 있습니다.
  • 콜드 스타트: 서버리스 기능이 비활성 기간 후에 호출되면 클라우드 공급자가 새 인스턴스를 초기화함에 따라 대기 시간이 증가하는 "콜드 스타트"가 발생할 수 있습니다. 이는 대기 시간에 민감한 애플리케이션의 성능에 영향을 미칠 수 있습니다.
  • 시간 초과 및 리소스 제한: 서버리스 플랫폼은 일반적으로 실행 시간 및 리소스 할당(메모리, CPU 등)에 제한을 둡니다. 장기 실행 작업 또는 리소스 집약적인 워크로드는 서버리스 아키텍처에 적합하지 않을 수 있습니다.
  • 디버깅 및 모니터링 문제: 서버리스 애플리케이션 디버깅은 함수의 분산 및 임시 특성으로 인해 더 복잡할 수 있습니다. 기존 모니터링 도구는 서버리스 환경에 적합하지 않을 수 있으므로 특화된 모니터링 도구를 사용해야 합니다.

2.4 컨테이너 및 컨테이너 오케스트레이션​

대규모의 서비스를 효율적으로 관리하고 운영 하기 위해서는 Docker와 Kubernetes와 같은 컨테이너 오케스트레이션 기술을 검토 해볼수도 있습니다. Docker와 같은 컨테이너화 기술과 함께 컨테이너화된 애플리케이션을 대규모로 관리하기 위한 Kubernetes, Amazon ECS 및 EKS 같은 컨테이너 오케스트레이션 관련 서비스에 대해서도 알아볼 필요가 있습니다.

컨테이너 오케스트레이션의 경우 대규모 서비스를 가장 효율적이고 정교하게 관리할수 있는 방식이기도 하지만 작은 팀이 운영하기에는 컨테이너 오케스트레이션 플랫폼은 설정, 구성 및 관리의 복잡성과 가파른 학습 곡선이 필요할 수 있습니다. 또한 애플리케이션 배포 및 관리의 여러 측면을 단순화 시켜주기도 하지만 컨테이너 오케스트레이션 인프라를 구성하고, 모니터링, 관리 및 문제 해결하는 데 시간과 리소스를 많이 투자해야 하기 때문에 작은 팀에서는 컨테이너 오케스트레이션을 사용하기에는 부담이 될 수 있습니다.

2.5 모던 서비스 지향 아키텍처와 마이크로서비스 아키텍처 (Modern Service-Oriented Architectures & Microservices Architecture)​

모던 서비스 지향 아키텍처와 마이크로서비스 아키텍처는 대용량 서비스에서 중요한 역할을 하고 있는 디자인패턴이며, 이러한 아키텍처는 대규모 서비스를 구축하고 운영하는 데 도움이 된다고 생각 하여 정리를 해보았습니다.

1) 모던 서비스 지향 아키텍처 (SOA)​

모던 서비스 지향 아키텍처(SOA)는 소프트웨어 디자인 패턴으로, 응용 프로그램을 표준화된 프로토콜을 사용하여 서로 통신하는 느슨하게 결합된 독립적인 서비스의 모음으로 구축하는 것에 중점을 둡니다. 이러한 아키텍처는 소프트웨어 구성 요소의 확장성, 유지 관리 용이성 및 재사용성을 향상시키기 위해 복잡한 응용 프로그램을 더 작고 독립적인 단위로 구성 하며 아래와 같은 특성이 있습니다.

  • 단일 책임(Single responsibility): 각 서비스는 특정 기능 또는 비즈니스 도메인에 대한 책임을 지며 해당 기능과 관련된 로직, 데이터, 프로세스를 캡슐화합니다.
  • 느슨한 결합(Loose coupling): 서비스는 다른 서비스에 대한 종속성을 최소화하도록 설계되어 독립적으로 발전하고 확장할 수 있습니다. 서비스 간 통신은 일반적으로 HTTP 또는 gRPC와 같은 표준 프로토콜을 사용하며, RESTful 또는 GraphQL API와 같은 잘 정의된 API를 사용합니다.
  • 재사용성(Reusability): 관심사를 개별 서비스로 분리함으로써 동일한 응용 프로그램 내에서 다른 응용 프로그램이나 구성 요소간에 각 서비스를 재사용할 수 있습니다. 이로 인해 중복 코드가 줄어들고 더 빠른 개발이 가능해집니다.
  • 확장성(Scalability): 서비스는 서로 독립적으로 확장할 수 있으므로 효율적인 자원 할당과 다양한 작업 부하 처리가 가능합니다. 이는 자동 확장 및 컨테이너화 기술(예: Kubernetes)을 사용하여 서비스 배포와 확장을 관리할 수 있는 클라우드 네이티브 환경에서 특히 유용합니다.
  • 복원력(Resilience): 현대 SOA에서는 서비스가 내결함성을 갖도록 설계되어 실패를 세련되게 처리할 수 있습니다. 서킷 브레이커, 재시도 및 시간 초과와 같은 기술을 사용하여 한 서비스의 실패가 전체 시스템에서 연쇄 실패를 일으키지 않도록 할 수 있습니다.

2) 마이크로서비스 아키텍처 (Microservices Architecture)​

이번에는 마이크로서비스에 대해 알아보겠습니다. 마이크로서비스는 각각 특정 기능을 담당하는 소규모 자율 서비스 모음으로 애플리케이션을 구축하는 아키텍처 스타일입니다. 마이크로서비스는 SOA의 진화로 볼 수 있으며, 자율성과 분산된 거버넌스에 더 중점을 두고 더 작고 더 집중된 서비스에 초점을 맞춥니다. 마이크로서비스의 주요 측면은 다음과 같습니다.

  • 작고 집중된 서비스(Small, focused services): 작고 집중적으로 설계되었으며 각 서비스는 단일 기능을 담당합니다. 이렇게 하면 관심사를 더 잘 분리하고 각 서비스를 더 쉽게 이해, 개발 및 유지 관리할 수 있습니다.
  • 독립적 배포(Independent deployment): 독립적으로 배포할 수 있도록 설계되어 더 빠른 개발 주기, 더 쉬운 확장 및 실패 위험 감소가 가능합니다.
  • 분산형 거버넌스(Decentralized governance): SOA와 달리 각 서비스 팀이 자체 기술 선택, 개발 프로세스 및 배포 전략을 담당하는 분산형 거버넌스를 촉진합니다.
  • 경량 통신(Lightweight communication): 종종 서비스 간의 효율적인 통신을 촉진하기 위해 REST 또는 gRPC와 같은 경량 통신 프로토콜에 의존합니다.
  • Polyglot 개발(Polyglot development): 마이크로서비스를 사용하면 각 서비스가 서로 독립적으로 작동하므로 팀은 특정 요구 사항에 가장 적합한 프로그래밍 언어, 프레임워크 및 도구를 선택할 수 있습니다.

모던 서비스 지향 아키텍처와 마이크로서비스 아키텍처에서 사용되는 기술중에는 Envoy Proxy와 Istio가 있습니다. Envoy Proxy와 Istio는 모던 서비스 지향 아키텍처에서 통신을 용이하게 하고 트래픽을 관리하며 다양한 서비스에서 정책을 시행하는 데 사용되는 기술입니다.

1) Envoy Proxy​

Envoy Proxy는 클라우드 네이티브 애플리케이션용으로 설계된 오픈 소스 고성능 서비스 프록시입니다. Lyft에서 개발한 Envoy는 "사이드카" 프록시 역할을 하며 각 서비스 인스턴스 옆에 앉아 서비스 간 네트워크 트래픽을 관리합니다. 간단히 말해서 서비스가 서로 대화하는 데 도움이 됩니다. Envoy Proxy의 일부 주요 기능은 다음과 같습니다.

  • 부하 분산(Load balancing): Envoy는 서비스의 여러 인스턴스에 트래픽을 분산하여 부하를 분산하고 고가용성을 보장합니다.
  • 서비스 검색(Service discovery): Envoy는 사용 가능한 서비스 인스턴스를 자동으로 감지하고 추적하여 트래픽을 적절한 대상으로 보다 쉽게 ​​라우팅할 수 있습니다.
  • 트래픽 관리(Traffic management): Envoy는 URL 경로, 헤더 또는 기타 메타데이터와 같은 다양한 기준에 따라 트래픽을 라우팅할 수 있습니다.
  • 복원력(Resilience): Envoy는 장애를 처리하고 시스템의 전반적인 복원력을 개선하기 위해 재시도, 시간 초과 및 회로 차단에 대한 기본 제공 지원을 제공합니다.
  • 관찰 가능성(Observability): Envoy는 자세한 로그, 메트릭 및 추적 정보를 생성하여 서비스 상호 작용을 보다 쉽게 ​​모니터링하고 디버그할 수 있습니다.

Envoy Proxy 를 사용하는 회사:

  • Lyft: Envoy Proxy를 만든 Lyft는 마이크로서비스 아키텍처에서 Envoy Proxy를 광범위하게 사용하여 서비스 간 통신을 관리하고 시스템의 복원력을 개선합니다.
  • Airbnb: Airbnb는 마이크로서비스 기반 인프라에서 서비스 간 통신, 로드 밸런싱 및 트래픽 관리를 위해 Envoy 프록시를 사용합니다.
  • Pinterest: Pinterest는 서비스 간의 네트워크 트래픽을 처리하고 관찰 가능성을 개선하며 고가용성을 보장하기 위해 Envoy 프록시를 채택했습니다.
  • Square: 결제 처리 회사인 Square는 Envoy Proxy를 사용하여 트래픽 관리, 로드 밸런싱 및 서비스 전반의 관찰 가능성을 제공합니다.

2) Istio​

Istio는 마이크로서비스 아키텍처에서 서비스 간의 통신을 관리하고 보호하는 데 도움이 되는 오픈 소스 서비스 메시 플랫폼입니다. Envoy Proxy를 기반으로 구축되며 서비스 동작을 제어하고 관찰하기 위한 상위 수준 기능을 제공합니다. Istio의 몇 가지 주요 기능은 다음과 같습니다.

  • 트래픽 관리(Traffic management): Istio는 서비스가 서로 상호 작용하는 방식을 테스트하고 제어하기 위해 트래픽 분할, 라우팅 및 결함 주입과 같은 고급 트래픽 관리 기능을 지원합니다.
  • 보안(Security): Istio는 상호 TLS 인증 및 역할 기반 액세스 제어와 같은 기본 제공 보안 기능을 제공하여 서비스 간 통신을 보호하고 정책을 시행합니다.
  • 관찰 가능성(Observability): Istio는 메트릭, 로그 및 분산 추적을 포함하여 서비스 상호 작용에 대한 보다 포괄적인 보기를 제공하여 Envoy의 관찰 가능성 기능을 향상시킵니다.
  • 정책 적용(Policy enforcement): Istio를 사용하면 속도 제한 또는 액세스 제어와 같은 서비스에 대한 정책을 중앙 집중식의 일관된 방식으로 정의하고 적용할 수 있습니다.

Istio를 사용하는 회사:

  • eBay: eBay는 Istio를 활용하여 마이크로서비스 아키텍처를 관리 및 보호하고 고급 트래픽 관리, 관찰 가능성 및 보안 기능을 제공합니다.
  • AutoTrader: 온라인 자동차 마켓플레이스인 AutoTrader는 Istio를 사용하여 서비스 간의 통신을 관리 및 보호하고 시스템의 탄력성과 성능을 개선합니다. 즉, 인적 자원 플랫폼은 마이크로 서비스 아키텍처에서 트래픽 관리, 보안 및 관찰 가능성을 위해 Istio를 활용합니다.
  • Tetrate: 엔터프라이즈급 서비스 메시 솔루션을 제공하는 회사인 Tetrate는 Istio를 제품의 핵심 구성 요소로 사용합니다.
  • Red Hat: Red Hat은 Istio를 Red Hat OpenShift에 통합하여 서비스 메시를 쉽게 사용할 수 있도록 지원합니다.
  • Google: Google은 Istio를 Google Kubernetes Engine(GKE)에 통합하여 서비스 메시를 쉽게 사용할 수 있도록 지원합니다.

요약하면 Envoy Proxy는 서비스 간의 통신을 관리하는 데 도움이 되는 고성능 서비스 프록시인 반면 Istio는 트래픽 관리, 보안 및 관찰 가능성을 위한 고급 기능을 제공하기 위해 Envoy Proxy 위에 구축되는 서비스 메시 플랫폼입니다. 이러한 기술은 마이크로서비스 기반 애플리케이션의 확장성, 복원력 및 보안을 개선하기 위해 함께 사용되는 경우가 많습니다.

3. 글로벌 서비스 대용량 서버 아키텍처 사례​

3.1 넷플릭스 (Netflix)​

Netflix는 수백만 명의 사용자를 지원하고 콘텐츠를 전 세계적으로 효율적으로 제공하는 대용량 서버 아키텍처를 갖춘 선도적인 글로벌 스트리밍 서비스입니다. Netflix는 클라우드 인프라에 Amazon Web Services(AWS)를 사용하지만 Open Connect라는 맞춤형 CDN을 사용하여 전략적으로 배치된 전 세계 데이터 센터 및 서버의 비디오 콘텐츠를 캐시하고 제공합니다. 또한 Amazon S3, Amazon DynamoDB 및 Apache Cassandra와 같은 다양한 AWS 데이터 저장 및 처리 서비스를 사용하여 고객 데이터, 메타데이터 및 기타 정보를 저장합니다. Apache Spark 및 Apache Flink와 같은 빅 데이터 처리 도구는 통찰력과 권장 사항을 위해 대량의 데이터를 분석하고 처리하는 데 사용됩니다.

Netflix는 "Chaos Monkey"라는 도구를 사용하여 시스템의 복원력을 테스트하고 개선하기 위해 의도적으로 인프라에 오류를 도입합니다. 또한 이중화, 폴백 전략(Fallback Strategy) 및 서킷 브레이커 패턴(Circuit Breaker Pattern)을 사용하여 시스템 안정성을 보장하고 오류의 영향을 최소화합니다.

  • Chaos Monkey Chaos Monkey는 클라우드 인프라의 탄력성을 향상시키기 위해 Netflix에서 개발한 도구입니다. Chaos Monkey는 프로덕션 환경에서 인스턴스를 종료하는 것과 같은 오류를 의도적으로 도입하여 시스템이 오류에 어떻게 반응하고 복구하는지 테스트합니다. 의도적으로 이러한 오류를 유발함으로써 엔지니어링 팀은 시스템의 약점을 식별하고 수정하며 전반적인 안정성을 향상시킬 수 있습니다. Chaos Monkey는 시스템이 예기치 않은 인프라 문제를 견디고 원활한 사용자 경험을 유지할 수 있도록 합니다.
  • Circuit Breaker Pattern 서킷 브레이커 패턴은 소프트웨어 개발, 특히 마이크로서비스 아키텍처에서 상호 의존적인 서비스 전반에 걸쳐 계단식 오류를 방지하기 위해 사용되는 설계 패턴입니다. 서비스가 실패하거나 응답 속도가 느려지면 회로 차단기가 문제를 감지하고 회로를 "개방"하여 실패한 서비스에 대한 요청을 일시적으로 중지할 수 있습니다. 이를 통해 서비스를 복구하거나 시스템에서 문제를 처리할 시간을 제공하여 시스템의 다른 부분에 영향을 미치는 추가 오류나 지연을 방지할 수 있습니다.

3.2 페이스북 (Facebook)​

Facebook은 수십억 명의 사용자와 엄청난 양의 데이터를 처리할 수 있는 대용량 서버 인프라를 갖춘 글로벌 소셜 미디어 거대 기업입니다. Facebook의 아키텍처는 사용자 데이터 저장을 위한 Apache Cassandra, 실시간 분석을 위한 HBase, 캐싱을 위한 Memcached 등 분산 시스템에 의존합니다. 또한 "Kad"라는 사용자 지정 로드 밸런서를 사용하여 수신 요청을 처리하고 트래픽을 적절한 백엔드 서비스로 유도합니다. 또한 API용 GraphQL과 같은 다양한 오픈 소스 기술을 사용합니다.

3.3 트위터 (Twitter)​

Twitter는 수백만 명의 사용자와 대량의 실시간 데이터를 처리할 수 있는 대용량 서버 아키텍처를 갖춘 글로벌 소셜 네트워킹 플랫폼입니다. Twitter는 데이터 저장을 위한 Apache Cassandra, 실시간 데이터 스트리밍을 위한 Apache Kafka, 서비스 간 통신을 위한 Finagle(맞춤형 RPC 시스템)과 같은 기술을 사용하는 분산 인프라를 사용합니다.

3.4 에어비앤비 (Airbnb)​

Airbnb는 글로벌 사용자 기반을 지원하기 위해 대용량 서버 아키텍처를 갖춘 숙박 및 경험을 제공하는 선도적인 온라인 마켓플레이스입니다. Airbnb의 아키텍처는 빠르게 성장하는 시장의 수요를 처리하기 위해 구축되어 여행자와 전 세계 호스트를 연결합니다. 웹 애플리케이션에 Ruby on Rails와 React의 조합을 사용하고 백엔드 서비스에 마이크로서비스 아키텍처를 사용합니다. Airbnb는 클라우드 인프라에 AWS를 사용하고 분산 스토리지용 Apache Cassandra, 메시징용 Apache Kafka, 컨테이너 오케스트레이션용 Kubernetes와 같은 다양한 기술을 사용합니다.

3.5 스포티파이 (Spotify)​

Spotify는 수백만 명의 사용자와 방대한 음악 카탈로그를 처리할 수 있는 대용량 서버 인프라를 갖춘 인기 있는 글로벌 음악 스트리밍 서비스입니다. Spotify는 콘텐츠 전송을 위해 Google Cloud Platform(GCP)과 맞춤형 CDN을 결합합니다. 그들은 데이터 스토리지를 위한 Apache Cassandra, 이벤트 스트리밍을 위한 Apache Kafka, 컨테이너 오케스트레이션을 위한 Kubernetes와 같은 기술을 사용합니다.

3.6 쇼피파이 (Shopify)​

Shopify는 기업이 온라인 상점을 만들고 판매를 관리할 수 있도록 하는 선도적인 전자 상거래 플랫폼입니다. 그들은 글로벌 사용자 기반을 지원하고 대량의 트랜잭션을 처리할 수 있는 대용량 서버 아키텍처를 가지고 있습니다. Shopify는 인프라에 AWS와 GCP를 모두 사용하는 다중 클라우드 전략을 사용합니다. 그들은 컨테이너 오케스트레이션을 위한 Kubernetes, 데이터 스토리지를 위한 MySQL, 캐싱을 위한 Redis와 같은 기술에 의존합니다.

3.7 우버 (Uber)​

Uber는 수백만 명의 사용자, 실시간 위치 데이터 및 복잡한 물류 알고리즘을 처리하도록 설계된 대용량 서버 아키텍처를 갖춘 글로벌 차량 호출 및 배달 플랫폼입니다. Uber의 아키텍처는 운전자와 승객 위치에 대한 실시간 업데이트를 효율적으로 지원하고, 최적의 경로를 계산하고, 수요와 공급을 관리하고, 지불을 처리해야 합니다. 이를 달성하기 위해 Uber는 다음과 같은 서비스 특성이 있습니다.

  • 마이크로서비스: Uber의 아키텍처는 각 서비스가 특정 기능(예: 여행 관리, 위치 추적 또는 청구)을 담당하는 마이크로서비스 접근 방식을 사용하여 구축되었습니다. 이를 통해 격리, 내결함성 및 확장성이 향상됩니다.
  • 데이터 스토리지: Uber는 다양한 데이터 스토리지 솔루션을 사용하여 다양한 유형의 데이터와 워크로드를 처리합니다. 분산 스토리지에는 Apache Cassandra, 관계형 데이터에는 PostgreSQL, 실시간 데이터 스트리밍에는 Apache Kafka를 사용합니다.
  • 지리 공간 데이터(Geospatial data): Uber의 아키텍처에는 대량의 지리 공간 데이터를 관리하고 처리 합니다.
  • 지리 공간 데이터 소스: Uber는 지도 데이터, GPS 좌표, 관심 지점(POI)과 같은 지리 공간 정보를 수집하기 위해 다양한 데이터 소스에 의존합니다. 이러한 데이터 소스에는 Google Maps 및 OpenStreetMap과 같은 타사 매핑 서비스와 Uber의 사용자 및 운전자가 생성한 데이터가 포함됩니다.
  • H3: Uber는 공간 데이터를 효율적으로 관리하고 처리하기 위해 오픈 소스 공간 색인 시스템인 H3를 개발했습니다. H3는 지구 표면을 육각형 셀의 그리드로 나누고 각 셀에 고유한 인덱스를 할당합니다. 이 계층적 그리드 시스템을 통해 Uber는 지리 공간 데이터를 다양한 해상도로 표현하고 공간 검색, 집계 및 시각화와 같은 작업을 보다 효율적으로 수행할 수 있습니다.
  • 지리 공간 데이터 처리: Uber는 대량의 지리 공간 데이터를 실시간으로 처리하여 ETA, 경로 계획, 운전자-승객 매칭과 같은 기능을 제공합니다. 실시간 데이터 스트리밍을 위한 Apache Kafka와 스트림 처리를 위한 Apache Flink와 같은 도구를 사용하여 이 데이터를 효율적으로 처리합니다.
  • 컨테이너 오케스트레이션: Uber는 컨테이너 오케스트레이션을 위해 Kubernetes를 사용합니다. 이를 통해 Uber는 컨테이너를 빠르게 배포하고 관리할 수 있습니다.

4. 결론​

지금 까지 클라우드 기반 대용량 서버 구축을 위한 주요 기술 및 고려사항을 살펴보았습니다. 워낙 방대한 내용이다 보니 어려운 내용도 많이 있을거 같고 부족 한 부분도 있을거라고 생각이 되지만 혹시나 대용량 서버를 구축하고자 하는 분들 께 조금이라도 도움이 되어보고자 정리를 해보았습니다. 개발팀 리소스 현황이나 프로젝트 요구 사항을 고려 하여 적합한 대용량 서버 인프라를 구성 하시는데 도움이 되셨으면 좋겠습니다.

본 포스팅은 ChatGPT의 도움을 받아 작성 되었으며 개인적인 개발 경험을 바탕으로 작성되었습니다.