제 프로젝트는 사용자가 특정 차트를 고르면, 코스피 코스닥 전 종목의 과거(5년) 차트들을 모두 탐색하여 가장 유사한 차트 10개 정도를 골라 사용자에게 보여주는 것이 목표입니다.
similar chart finder
내 종목의 차트는 상승하는 차트일까요?
3.35.36.208
웹 서비스를 끊기지 않고 제공해 보자
살면서 한 번쯤은 자기가 사용하는 애플리케이션, 웹사이트, 게임 등이 점검 중이거나 의도치 않게 서버가 다운된 것을 본 경험이 있을 것입니다.
저도 웹 서비스를 제공하려다 보니 이런 부분들이 꽤 신경 쓰이네요. 특히 갑자기 많은 사용자가 몰리거나 특정 사용자가 악의적으로 무수한 요청을 보내 서버가 다운되는 경우가 제일 걱정됩니다.
제가 하고 있는 프로젝트에는 메모리 누수가 발생하는 부분이 있는 것 같습니다. 여기저기 알아보았지만 아직까지 해결하지 못했습니다. 이렇게 메모리가 쌓이다가 어느 순간이 되면 서버가 다운될 것입니다.
특히 저는 AWS의 EC2 인스턴스를 사용 중인데, 비용을 최대한 절감하려고 최대 메모리가 1.9GB인 저렴한 서버를 사용 중입니다. 그래서 서버가 다운되지 않도록 고가용성을 위한 시스템이 어떤 것들이 있는지 오늘 공부해보려고 합니다.
가용성과 고가용성
가용성(Availability)이란 시스템이 정상적으로 작동하고 사용자에게 서비스를 제공할 수 있는 상태를 의미합니다. 이는 시스템의 신뢰성과 직결되는 개념으로, 시스템의 가용성이 높을수록 사용자는 서비스에 대해 더 높은 신뢰성을 가지게 됩니다.
그렇다면 고가용성(High Availability, HA)은 무엇일까요? 고가용성은 시스템이 지속적으로 정상적으로 작동하도록 하는 능력을 의미합니다. 다시 말해, 고가용성 시스템은 장애가 발생하더라도 빠르게 복구하여 서비스 중단 시간을 최소화합니다. 이는 '항상 사용 가능함'을 보장하는 것이 목표입니다.
가용성 = (작동 시간) / (전체 시간)고가용성은 보통 '5 9s'(99.999%)라는 표현으로 알려져 있습니다. 이는 한 해 동안 시스템이 작동하지 않는 시간이 총 5분 15초를 넘지 않음을 의미합니다. 즉, 고가용성 시스템은 한 해 동안 99.999%의 시간 동안 가용해야 합니다.
이렇게 가용성을 퍼센트로 표현하면 다음과 같이 이해할 수 있습니다:
- 99% 가용성: 주당 약 1.68시간 동안 시스템이 작동하지 않을 수 있음
- 99.9% 가용성: 주당 약 10분 동안 시스템이 작동하지 않을 수 있음
- 99.99% 가용성: 주당 약 1분 동안 시스템이 작동하지 않을 수 있음
- 99.999% 가용성: 주당 약 6초 동안 시스템이 작동하지 않을 수 있음
웹 아키텍처에서 고가용성을 위한 시스템과 전략
웹 서비스는 사용자에게 지속적으로 안정적인 서비스를 제공하기 위해 고가용성을 필수적으로 고려해야 합니다. 고가용성을 달성하기 위한 다양한 시스템과 전략에 대해 자세히 알아보겠습니다.
1. 로드 밸런싱
로드 밸런싱은 시스템에 과부하가 발생하지 않도록 들어오는 네트워크 트래픽을 여러 서버에 분산시키는 방법입니다. 이를 통해, 단일 서버에 과부하가 걸리는 것을 방지하고, 서버 간의 작업 부하를 균등하게 분배하여 전체 시스템의 가용성이 높아집니다.
적용 방법: 로드 밸런싱을 적용하려면, 먼저 로드 밸런서가 필요합니다. AWS의 Elastic Load Balancer, Google Cloud의 Cloud Load Balancing, Nginx, HAProxy 등이 대표적인 로드 밸런서입니다. 이들 로드 밸런서를 사용하면 간단한 설정만으로도 로드 밸런싱을 적용할 수 있습니다.
2. 클러스터링
클러스터링은 동일한 작업을 수행하는 여러 서버의 그룹을 만드는 것입니다. 한 서버가 실패하면 다른 서버가 그 작업을 수행하게 되어 시스템의 가용성이 유지됩니다.
적용 방법: 클러스터링을 적용하려면, 먼저 클러스터 관리 도구가 필요합니다. Kubernetes는 대표적인 컨테이너 오케스트레이션 도구로, 클러스터를 구성하고 관리하는 데 사용됩니다. 또한, MongoDB, MySQL 등의 데이터베이스도 클러스터링 기능을 지원합니다.
3. 데이터 복제
데이터 복제는 데이터를 여러 위치에 복사하여 저장하는 것입니다. 한 위치에서 문제가 발생하더라도 다른 위치에서 데이터에 접근할 수 있게 되어 데이터의 가용성이 보장됩니다.
적용 방법: 데이터 복제는 데이터베이스 관리 시스템(DBMS)을 통해 이루어집니다. MySQL, PostgreSQL, MongoDB 등의 DBMS는 데이터 복제 기능을 제공합니다. 또한, 클라우드 서비스에서도 데이터 복제 기능을 지원하므로, AWS의 RDS, Google Cloud의 Cloud SQL 등을 이용할 수 있습니다.
4. 자동 복구 시스템
자동 복구 시스템은 시스템에 문제가 발생했을 때 자동으로 복구하는 메커니즘을 구축하는 것입니다. 이는 예를 들어, 서버가 다운되면 자동으로 새로운 인스턴스를 시작하는 등의 방식으로 이루어질 수 있습니다.
적용 방법: 자동 복구 시스템은 클라우드 서비스의 Auto Scaling 기능을 통해 구현할 수 있습니다. AWS의 Auto Scaling, Google Cloud의 Managed Instance Groups 등은 서버 장애 시 자동으로 새 인스턴스를 시작하는 기능을 제공합니다.
5. 멀티-지역 배포
멀티-지역 배포는 애플리케이션을 여러 지역에 배포하는 것입니다. 한 지역에서 장애가 발생하더라도 다른 지역에서 서비스를 계속 제공할 수 있게 됩니다.
적용 방법: AWS, Google Cloud, Azure 등의 클라우드 서비스는 전 세계 여러 지역에 데이터 센터를 운영하고 있으므로, 이들 서비스를 이용하면 쉽게 멀티-지역 배포를 구현할 수 있습니다.
6. 헬스 체크와 모니터링
시스템의 상태를 지속적으로 모니터링하고, 문제가 발생하면 즉시 알림을 받아 빠르게 대응할 수 있게 하는 것이 중요합니다.
적용 방법: Prometheus, Grafana, Datadog, New Relic, AWS CloudWatch 등의 모니터링 도구를 사용하면 시스템의 성능을 모니터링하고 이상 상황을 감지할 수 있습니다.
도커 컨테이너의 고가용성을 위한 전략
제 프로젝트는 도커 컨테이너를 주로 사용하고 있습니다. 도커 컨테이너의 관점 위주의 전략은 어떻게 되는지 살펴보겠습니다.
특정 도커 컨테이너의 고가용성을 달성하려면, 컨테이너의 중단 없이 서비스를 계속 제공할 수 있는 전략이 필요합니다. 이를 위해 다음과 같은 방법을 사용할 수 있습니다.
1. 컨테이너 복제 및 로드 밸런싱
고가용성을 위한 가장 기본적인 방법은 동일한 컨테이너를 여러 개 실행하는 것입니다. 이렇게 하면 한 컨테이너가 실패하더라도 다른 컨테이너가 서비스를 계속 제공할 수 있습니다. 도커는 이를 위해 docker run 명령을 사용하여 동일한 이미지로 여러 컨테이너를 생성할 수 있습니다.
이후 로드 밸런서를 사용하여 들어오는 요청을 여러 컨테이너에 분산시킵니다. 이를 통해 단일 컨테이너에 과부하가 걸리는 것을 방지하고, 여러 컨테이너가 균등하게 부하를 나눠 갖게 합니다. 로드 밸런서로는 Nginx, HAProxy 등이 있습니다.
제 프로젝트에 적용 중입니다.
2. 자동 복구 (Auto-restart)
도커 컨테이너는 --restart 옵션을 통해 컨테이너가 종료될 때 자동으로 재시작하도록 설정할 수 있습니다. 이로써 특정 오류나 실패로 인해 컨테이너가 중지되더라도 자동으로 복구되어 서비스가 계속되도록 할 수 있습니다.
3. 건강 상태 확인 (Health checks)
도커는 컨테이너의 건강 상태를 확인하는 기능을 제공합니다. HEALTHCHECK 지시문을 사용하면, 컨테이너가 정상적으로 작동하고 있는지 주기적으로 확인할 수 있습니다. 이를 통해 문제가 발생한 컨테이너를 빠르게 감지하고 대응할 수 있습니다.
4. 로깅 및 모니터링
컨테이너의 로그를 추적하고 모니터링하는 것은 문제를 신속하게 발견하고 분석하는 데 중요합니다. 도커는 로그를 수집하고 관리하는 다양한 방법을 제공합니다. 또한, Prometheus, Grafana 등의 도구를 활용하여 컨테이너의 성능을 모니터링할 수 있습니다.
'웹 아키텍쳐' 카테고리의 다른 글
| 웹 아키텍처16 - 파이썬으로 배포할 때 알고있어야 하는 Gunicorn(WSGI) (0) | 2024.02.17 |
|---|---|
| 웹 아키텍처15 - Gateway Interface(CGI, WSGI) - Spring과의 관계? (0) | 2024.02.17 |
| 웹 아키텍처13 - CDN(Content Delivery Network) (23.11.13) (0) | 2024.02.17 |
| 웹 아키텍처12 - 분산 데이터베이스 시스템(MongoDB) MySQL과 뭐가달라? (0) | 2024.02.17 |
| 웹 아키텍처11 - 오케스트레이션 도구와 Kubernetes (0) | 2024.02.17 |