Backend
웹 서비스의 사용자들은 위치에 관계없이 빠르고 안정적인 응답을 기대한다. 이에 따라 컨텐츠를 효율적으로 전송하기 위한 CDN(Content Delivery Network)의 중요성이 점점 더 커지고 있다.AWS CloudFront는 Amazon이 제공하는 대표적인 CDN 서비스로, 전 세계에 분산된 엣지 로케이션을 통해 컨텐츠를 빠르게 전달할 수 있도록 도와준다. 다양한 AWS 서비스와 연동하여 사용할 수 있으며, 트래픽 최적화, 보안, 캐싱 전략까지 유연하게 설정할 수 있는 장점이 있다. 이번 포스팅에서는 CloudFront를 이해하기 위한 기본 개념들을 살펴보고, 간단한 적용을 실습해 볼 예정이다.1. AWS CloudFront : 주요 개념 및 기능2. 배포(Distribution)3. 원본(Or..
현대의 인프라 환경에서는 고가용성과 빠른 응답 속도를 확보하기 위해, 단일 서버가 아닌 여러 리전 혹은 엔드포인트에 트래픽을 분산시키는 방식이 일반화되고 있다. 특히 장애 상황에 자동으로 대응하거나, 지역에 따라 더 가까운 서버로 요청을 유도하기 위해서 DNS 레벨의 트래픽 라우팅 정책이 필요하다. AWS Route 53은 단순한 도메인 연결 기능을 넘어서, 헬스 체크 기반의 장애 감지와 다양한 라우팅 정책을 통해 이런 요구를 효과적으로 지원하는 서비스이다. 이번 포스팅에서는 Route 53의 라우팅 정책과 헬스 체크 기능을 알아보고, 이를 활용하여 Failover 웹 서비스 호스팅을 진행해보려고 한다. 지난 포스팅에서 진행한 도메인 호스팅 과정에 대한 이해를 전제로 진행하기 때문에 해당 글을 함께 참조..
현대의 인프라 환경에서는 사용자 요청을 처리할 수 있는 여러 자원(서버, 로드밸런서, CDN 등)이 복잡하게 얽혀 있다. 특히 클라우드 환경에서는 EC2, S3, ALB 등 다양한 서비스에 도메인을 연결하거나 트래픽을 라우팅해야 하는 경우가 많다. AWS는 이러한 요구를 충족할 수 있도록 Route 53이라는 강력한 DNS 서비스를 제공한다. 이번 포스팅에서는 도메인 구입부터 EC2에 연결하는 실습 과정을 따라가며 Route 53의 기본 개념과 구성 방법을 알아보고자 한다. AWS Route53AWS Route 53은 높은 가용성과 확장성을 갖춘 클라우드 기반의 DNS(Domain Name System) 서비스로, 99.99%의 SLA를 보장한다. 이름의 ‘53’은 DNS 통신에 사용하는 포트 번호..
지난 포스팅에 이어서 여러개의 Service Application으로 구성된 마이크로서비스를 컨테이너 오케스트레이션 도구인 Kubernetes를 사용하여 운영 인프라를 구성하는 방법을 알아볼 예정이다. 마이크로서비스 구조에서는 소프트웨어를 작은, 독립적인 서비스 단위로 나누는 방식으로 설계된다. 이러한 독립적인 마이크로서비스는 각각 자체 실행 가능하며, 특정 기능 또는 업무를 처리한다. 다른 마이크로서비스와 통신하여 전체 시스템을 구성하게 된다. 이 때 Kubernetes를 활용하면, 각 마이크로서비스를 독립적으로 배포하고 자동으로 확장(스케일 아웃)할 수 있어, 사용자 요청 증가에 유연하게 대응할 수 있다. 또한, 마이크로서비스의 로드 밸런싱, 자동화된 롤링 업데이트, 장애 복구, 상태 점검(Live..
지난 포스팅에 이어서 여러개의 Service Application으로 구성된 마이크로서비스를 컨테이너 오케스트레이션 도구인 Kubernetes를 사용하여 운영 인프라를 구성하는 방법을 알아볼 예정이다. 마이크로서비스 구조에서는 소프트웨어를 작은, 독립적인 서비스 단위로 나누는 방식으로 설계된다. 이러한 독립적인 마이크로서비스는 각각 자체 실행 가능하며, 특정 기능 또는 업무를 처리한다. 다른 마이크로서비스와 통신하여 전체 시스템을 구성하게 된다. 이 때 Kubernetes를 활용하면, 각 마이크로서비스를 독립적으로 배포하고 자동으로 확장(스케일 아웃)할 수 있어, 사용자 요청 증가에 유연하게 대응할 수 있다. 또한, 마이크로서비스의 로드 밸런싱, 자동화된 롤링 업데이트, 장애 복구, 상태 점검(Live..
이번 포스팅 시리즈에서는 여러개의 Service Application으로 구성된 마이크로서비스를 컨테이너 오케스트레이션 도구인 Kubernetes를 사용하여 운영 인프라를 구성하는 방법을 알아볼 예정이다. 마이크로서비스 구조에서는 소프트웨어를 작은, 독립적인 서비스 단위로 나누는 방식으로 설계된다. 이러한 독립적인 마이크로서비스는 각각 자체 실행 가능하며, 특정 기능 또는 업무를 처리한다. 다른 마이크로서비스와 통신하여 전체 시스템을 구성하게 된다. 이 때 Kubernetes를 활용하면, 각 마이크로서비스를 독립적으로 배포하고 자동으로 확장(스케일 아웃)할 수 있어, 사용자 요청 증가에 유연하게 대응할 수 있다. 또한, 마이크로서비스의 로드 밸런싱, 자동화된 롤링 업데이트, 장애 복구, 상태 점검(Li..
서비스가 안정적으로 운영되기 위해서는 애플리케이션의 상태를 수치로 관찰하고, 이상 징후를 빠르게 감지할 수 있어야 한다.특히 MSA나 클라우드 환경처럼 복잡성이 높아질수록 시스템의 가시성(Observability), 즉 관찰 가능한 지표(Metric), 로그(Log), 트레이싱(Trace)를 수집하고 시각화하는 과정이 필요하다. Spring Boot 기반 애플리케이션에서는 주로 Actuator와 Micrometer를 활용해 메트릭을 수집하고, Prometheus를 통해 데이터를 저장, Grafana로 대시보드를 구성하고 시각화하여 실시간 모니터링 체계를 구축할 수 있다. 이번 포스팅에서는 Micrometer와 Prometheus를 활용을 중심으로, Spring 애플리케이션에 모니터링 기능 적용을 위한 메..
마이크로서비스 환경에서는 하나의 요청이 여러 서비스를 거쳐 처리되기 때문에, 특정 서비스에서의 지연이나 장애가 전체 응답 속도에 영향을 주는 경우가 많다.분산 시스템의 관점에서 보면, 장애의 원인을 빠르게 식별하고 정확히 진단할 수 있는 능력이 곧 운영 안정성과 직결된다. 어디에서 병목이 발생했는지, 어떤 서비스 호출에서 예외가 발생했는지를 파악하기 어려운 구조인 만큼 투명한 추적이 중요해진다.이때 사용하는 도구가 바로 Zipkin이다. Zipkin은 마이크로서비스 간의 호출 흐름을 시각화하고, 트랜잭션별로 어느 지점에서 얼마만큼의 시간이 소요되었는지를 추적할 수 있도록 도와준다.이번 포스팅에서는 Zipkin을 활용한 분산 추적의 기본 개념과 Spring 애플리케이션에 적용하는 방법을 소개하고자 한다. ..
마이크로서비스 간의 유기적인 연결이 많아질수록, 한 서비스의 장애로 인해 전체 시스템으로 확산되는 위험이 함께 존재한다.분산 시스템의 궁극적인 목적은 Fault Tolerance(내결함성), 즉 시스템이 부분적인 장애나 실패 상황에서도 전체 기능을 계속 유지할 수 있도록 만드는 것이다.바로 이때 필요한 것이 장애를 격리하고 시스템의 복원력을 지켜주는 장치로서 Circuit Breaker를 활용할 수 있다.단순히 예외를 잡는 수준이 아니라, 실패가 반복되면 아예 호출 자체를 차단하고 우회(fallback)하게 함으로써 전체 장애로 번지는 것을 막아주는 역할을 한다.이번 포스팅에서는 Circuit Breaker의 개념과 Spring Application에 적용해보는 과정을 다루어 보겠다. CircuitB..
