본문 바로가기

분류 전체보기

 (220)
[Architecture]처리율 제한 장치 설계(Rate limiting) 개요 처리율 제한 장치(rate limiter)는 클라이언트 또는 서비스가 보내는 트래픽의 처리율(rate)을 제어하기 위한 장치입니다. 이 기술은 서비스나 애플리케이션에 너무 많은 요청이 한꺼번에 몰리는 것을 방지하여, 서버가 안정적으로 운영될 수 있도록 돕습니다. 예시: 특정 기간 내에 전송되는 클라이언트의 요청 횟수를 제한 사용자는 초당 2회 이상의 새 글을 올릴 수 없습니다. 같은 IP 주소로는 하루에 10개 이상의 계정을 생성할 수 없습니다. 같은 디바이스로 주당 5회 이상 리워드(reward)를 요청할 수 없습니다. API 처리율 제한 장치를 두면 좋은점 DoS(Denial of Service) 공격에 의한 자원 고갈(Resource Starvation)을 방지할 수 있습니다. 비용을 절감할 ..
[Observability]기반기술 이해하기 복원성 복원성 구현의 두 가지 접근 방법 복원성이란 시스템이 장애를 겪었을 때, 원래 상태로 복귀할 수 있는 능력을 의미합니다. 이를 구현하는 방법은 크게 애플리케이션 관점과 인프라 관점으로 나눌 수 있습니다. 1. 애플리케이션 관점에서의 복원성 구현 애플리케이션 내부에서 예외 처리, 재시도, 타임아웃 등을 구현하여 복원력을 강화하는 방법입니다. 에러 분류: 비즈니스 로직에서 발생할 수 있는 에러와 시스템 에러를 구분하여, 각 에러 유형에 맞는 적절한 처리 방법을 적용합니다. 재시도 정책: 일정 간격을 두고 오류 발생 시 재시도를 진행합니다. 이는 일시적인 문제로 인한 요청 실패에 효과적으로 대응할 수 있게 합니다. 2. 인프라 관점에서의 복원성 구현 서비스 메시와 메시징 시스템을 활용하여 인프라 수준에..
[Architecture]안정 해시 설계(consistent hash) 개요 수평적 규모 확작성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는게 중요합니다. 안정 해시는 이 목표를 달성하기 위해 보편적으로 사용하는 기술입니다. 당면한 문제 : 해시 키 재배치(rehash) 문제 전통적인 해시 테이블에서 서버(노드)를 추가하거나 제거할 때 대부분의 키가 재배치되어야 하는 문제가 발생합니다. 이는 시스템에 큰 부하를 주고, 수평적 확장성을 제한하는 주요 원인이 됩니다. 서버의 개수 변하지 않을때: 문제 없음 서버의 개수가 변할때: 대규모 캐시 미스 발생 문제가 발생한 1번 서버에 보관되어 있는 키 뿐만 아니라 대부분의 키가 재분배 되었다. 1번 서버가 죽으면 대부분 캐시 클라이언트가 데이터가 없는 엉뚱한 서버에 접속하게 된다. 해결 방법: 안정 해시(consis..
[Promtail]Install promtail with helm chart Fetch promtail helm chart ➜ helm repo add grafana ➜ helm repo update ➜ helm fetch grafana/promtail ➜ tar zxvf promtail-6.15.5.tgz ➜ helm upgrade --install promtail . -f ./values.yaml --namespace loki --create-namespace Deploy helm chart Edit values.yaml daemonset: enabled: true # DaemonSet을 사용하여 Promtail을 배포할지 여부를 결정합니다. Kubernetes 클러스터의 모든 노드에 Promtail을 배포하려면 true로 설정합니다. serviceAccount: create..
[도서리뷰]가상 면접 사례로 배우는 대규모 시스템 설계 기초 책 정보 제목: 가상 면접 사례로 배우는 대규모 시스템 설계 기초 프로그래밍인사이트 알렉스 쉬 저자(글) · 이병준 번역 개요 이 책은 시스템 설계의 전체적인 개념을 소개한 후, 다양한 실제 사례를 통해 구체적인 설계 방법을 알려줍니다. 평점 별점: ⭐⭐⭐⭐⭐(5/5) 리뷰 다양한 도메인에서 적용 가능한 설계 노하우를 제공해주는 책입니다. 책을 읽는 내내 조금 더 일찍 이 책을 읽었으면 좋았겠다라는 생각이 들었습니다. 확장 가능한 시스템 설계의 기초부터 여러 사례에 대한 심화 내용까지 깊이 있게 다루며, 실제 업무에 적용할 수 있는 실질적인 지식을 제공하고 있습니다. 저의 경우 아키텍처를 어떻게 그리고 어떤 리소스들을 사용할 수 있는지를 중점적으로 보았으며 실제 어떻게 구현할건가에 대한 고민은 구체적으로..
[Architecture]대규모 애플리케이션을 위한 아키텍처 설계 가이드 개요 데이터베이스 선택, 애플리케이션의 확장, 로드밸런싱, 캐싱, CDN 활용, 데이터베이스 샤딩 등의 전략을 통해 효율적이고 확장 가능한 웹 시스템 아키텍처를 설계할 수 있습니다. 요약: 사용자 수에 따른 규모 확장성 웹 계층은 Stateless해야 합니다. 이는 시스템이 더 많은 사용자와 트래픽을 수용할 수 있도록 만듭니다. 모든 계층에 다중화를 도입합니다. 이는 시스템의 부하를 분산시키고 가용성을 높입니다. 가능한 한 많은 데이터를 캐시합니다. 이는 응답 시간을 단축하고 시스템의 전반적인 성능을 향상합니다. 정적 콘텐츠는 CDN을 통해 서비스합니다. 이는 전 세계적으로 빠른 콘텐츠 전달을 가능하게 합니다. 데이터 계층은 샤딩을 통해 확장합니다. 이는 데이터 관리를 보다 효율적으로 만듭니다. 각 계층..
[Architecture]멀티 테넌트 아키텍처 이해하기 멀티 테넌트(Multi-Tenant) 아키텍처는 단일 소프트웨어 인스턴스가 여러 사용자 그룹(테넌트)에 의해 공유되는 구조를 말합니다. 이는 클라우드 컴퓨팅과 SaaS(Software as a Service) 모델에서 널리 사용됩니다. 멀티 테넌트 개념 멀티 테넌트 시스템에서는 다수의 고객이나 사용자 그룹이 동일한 애플리케이션을 공유합니다. 중요한 점은, 각 테넌트의 데이터와 설정이 서로 격리되어 있다는 것입니다. https://blogs.sap.com/2022/08/27/fundamentals-of-multitenancy-in-sap-btp/ 예시: 로그 관리 시스템 시나리오: 단일 로그 관리 시스템이 여러 회사(회사 A, B, C)에 의해 사용됩니다. 이 시스템은 각 회사의 로그를 수집하고 관리합니다..
[S3]초당 쿼리 수 제한(QPS Limit)을 극복하고 성능을 향상시키는 방법 문제 특정 이벤트로 인해 사용자들이 몰리는 현상이 발생하면서 S3 버킷에 대한 요청이 급증했습니다. 이 예기치 못한 트래픽 증가로 인해 S3의 초당 쿼리 수 제한(QPS Limit)에 걸려 많은 파일들이 업로드되지 못하는 문제가 발생했습니다. S3 초당 쿼리 수 제한에 대한 이해 Amazon S3는 각 접두사(prefix) 당 3,500개의 PUT/COPY/POST/DELETE와 5,500개의 GET/HEAD 요청을 처리할 수 있는 높은 요청 빈도로 설계되어 자동 확장됩니다. 이 기본 성능은 S3의 동적 최적화와 확장 능력을 바탕으로 합니다. 그러나, 오늘과 같이 대규모 이벤트가 발생하여 요청이 급증하면, 시스템은 일시적으로 503 에러를 발생시킬 수 있으며, 이는 S3가 새로운 요청 빈도에 맞게 조정되..

티스토리툴바