chanstory

Amazon DynamoDB 란? AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스 DynamoDB는 키-값 기반의 데이터 모델을 사용하며, 높은 확장성, 성능, 가용성, 보안 및 내구성을 제공함 클라우드 환경에서 확장성이 뛰어난 분산형 데이터 저장소로서, 매우 빠른 읽기 및 쓰기 성능을 제공함 스키마리스(Schemaless) 데이터 모델을 사용하기에 데이터 모델을 변경하거나 데이터 베이스 구조를 수정하는 작업이 매우 수월함 AWS Lambda, AWS Kinesis 등의 AWS 서비스와의 통합이 간편함 안정성과 내구성 보장을 위한 여러 보안 및 백업 기능 제공 DynamoDB Stream vs Kinesis Stream DynamoDB Stream DynamoDB 테이블에서 발생하는 모든 ..

부하 테스트 진행 전 서비스 수준 목표(SLO) 설정 Latency에 중점을 둔 SLO 예시 GET 호출의 90%는 1ms 이내에 완료해야 한다. GET 호출의 99%는 10ms 이내에 완료해야 한다. GET 호출의 99.9%는 100ms 이내에 완료해야 한다. Throughput에 중점을 둔 SLO 예시 (1일 기준으로의 RPS 계산) - 순간적으로 요청이 치솟는 피크(peak) 트래픽에서의 처리량을 바탕으로 함 DAU(Daily Active User : 1일 접속자 수 ) : 5만명 1명당 편균 접속 횟수 : 20회 1일 평균 접속 수에 대한 피크 트래픽 배율 : 3배 (보통 평균의 2~3배를 곱함) 안전 계수 (얼마만큼 넉넉하게 프로비저닝 할 것인가) : 3배 하루 = 86,400초 50000 x ..

버스트 기능이란? - Burst 기능이란 EC2 인스턴스 유형에서 사용할 수 있는 기능 중 하나임 - 일정 기간 동안 인스턴스의 CPU 용량을 잠재적으로 초과하는 능력을 제공하여 예기치 않은 작업 부하에 대한 대처 가능 => 인스턴스가 기본 CPU 크기보다 높은 CPU 사용량을 일시적으로 처리 한다는 것 => CPU를 더 큰 인스턴스로 업그레이드 할 필요 없어 효율적임 => CPU 크레딧 사용함 CPU 크레딧 이란? - 시간당 CPU 용량을 나타냄 - 인스턴스가 활성화 되어 있을 때 CPU 크레딧이 충분하지 않으면 인스턴스의 CPU 사용량이 기본 CPU 크기로 제한 됨 - 트래픽이 적을 때는 CPU 크레딧을 충전하고, 높아지면 CPU 크레딧을 사용하여 인스턴스를 버스트 모드로 전환할 수 있음 => CPU..

병목현상 이란? - 시스템 내에서 전체적인 처리 속도를 떨어뜨리게 되는 특정한 부분을 가리키는 용어 - 시스템의 CPU나 메모리, 디스크 등의 자원 중 하나가 다른 자원들에 비해 처리 속도가 느려서, 전체적인 성능을 제한하는 경우를 말함 - 효율적인 자원분배 및 최적화를 고려해야함 응답성능에 대한 병목현상 원인 - 네트워크 대역폭 부족 - 하드웨어 자원 부족 - 어플리케이션 설계의 문제 - 데이터베이스 부하 Throughput 개선 - 시스템의 흐름을 고속도로에 비유해보자 - 대구와 부산 사이에 병목현상이 발생하고 있다. - 통행량을 늘려 병목현상을 해결한다. - 처리량에 대해서 네트워크 대역폭이나 부족한 자원을 증가시켜 처리할 수 있다. ** Throughtput의 개선이 Latency 개선으로 이어진..

가용성과 확장성을 염두하여 시스템을 설계하는 것이 중요하다. 다수의 노드를 가진 분산 시스템, 또한 서버리스 아키텍처 등을 통해 가용성과 확장성 확보가 가능하다. 가용성(Availability)이란? 가용성이란 - 시스템이 정상적으로 사용 가능한 정도 - uptime / (uptime + downtime) => 정상가동시간(uptime), 사용 불가 시간(downtime), 합친 전체 사용 시간 (uptime + downtime) - ex) 가용성 99.95% = 약 1년에 4시간 22분의 다운타임을 갖는다. * 단일 장애점 (Single Point of Failure)을 없애야 한다. ** 어떤 한 노드에서 장애가 발생해도, 동일한 처리 능력을 가진 다른 노드로 대체 될 수 있어야 한다. => 시스템 ..

지표 설정 - 서비스나 시스템에 있어 중요한 지표를 판단하는 근거가 있어야함 - 적절한 SLI(서비스 수준 판단을 위해 정량적으로 측정한 값)의 선정은 시스템의 분류에 따라 달라질 수 있음 1. 사용자가 직접 대면하는 시스템 => 보통 프론트엔드에 해당 / 이경우 가용성, 응답시간, 처리량이 중요 2. 저장소 시스템 => 응답 시간, 가용성, 내구성이 중요 3. 빅데이터 시스템 => 데이터 파이프라인이 이에 해당하며 처리량, 엔드포인트 간 응답 시간이 중요 척도 수집 - 측정 원본 합산 or 평균을 내는 방법이 있겠지만 대부분의 경우 분포가 중요 - 일부 요청이 빠르게 처리되어도 나머지 요청이 균일하게 느리다면 실제로 서비스는 느린것 - 평균은 이러한 흐름의 변화를 감지하기 어려움 척도의 표준화 - SL..

SLI (서비스 수준 척도, Service Level Indicator) - 서비스 수준을 판단할 수 있는 몇가지를 정량적으로 측정한 값 1. 응답속도 : 요청에 대한 응답이 리턴되기까지의 시간 2. 에러율 : 전체 요청 수 대비 3. 처리량(throughput) : 초당 처리할 수 있는 요청 수 4. 가용성 : 서비스가 사용 가능한 상태로 존재하는 시간의 비율 5. 내구성 : 데이터 저장이 중요한 목적인 서비스의 경우 특히 중요 SLO (서비스 수준 목표, Service Level Object) - SLI에 의해 측정된 서비스 수준의 목표 값, 또는 일정 범위의 값을 의미 // SLO 표현 SLI

Prometheus 란? 1. 오픈소스 모니터링 / 알림 시스템 2. 다양한 지표(metric) 수집 및 저장 => 이를 기반으로한 경고 알림 (alerting) 및 대시보드 작성 지원함 3. 쿠버네티스, 노드, 프로메테우스 자체를 모니터링 할 수 있음 4. 유연성과 확장성이 높아 대규모 시스템에서도 사용할 수 있음 Prometheus 구성 요소 1. 프로메테우스는 시계열 (time series) 데이터를 저장함 2. 프로메테우스 서버는 다양한 export로 부터 각 대상의 메트릭을 pull하여 주기적으로 가져오는 모니터링 시스템 => 쿠버네티스 관련 메트릭 가져오기 - exporter => mongoDB 관련 메트릭 가져오기 - mongoDB exporter 3. Alert manager는 경고 및 알..

클러스터 환경에서의 문제 해결의 어려움 - 노드가 사용하는 리소스 확인 (CPU / 메모리 리소스 사용량 확인 가능) => % kubectl top - 여러 개의 마이크로서비스가 워크로드로서 실행되고, 클러스터 안에서 서로 연결되어 있는 경우가 대부분 일것 => 이 경우 문제의 원인을 찾아내는 것이 조금 더 복잡합니다. - 각 파드에서 사용하는 리소스에 문제가 발생할 경우 미리 경고를 준다거나, Liveness Probe를 통해 어플리케이션에서 발생하는 응답이 오류로 전달되는 경우 즉시 모니터링 할 수 있다면 좋을 것 클러스터 환경에서의 주요 이슈 쿠버네티스 환경 그 자체 => 제어판(control plane)의 주요 컴포넌트 상태가 비정상적인 경우 노드의 리소스 가용량 (CPU, 메모리 요청에 대한 비..

목표 특징 메트릭이 임계치를 넣을 때, 수평 확장이 자동으로 진행되게 하는 것이 바람직함 Auto Scaling Group (ASG)의 원리를 파악하고 주요 메트릭의 임계치 달성 시점을 경보 형태로 제공해야 함 이를 SNS 및 람다를 통해 구현한다. 최소 요구 사항 EC2 서버를 ASG를 통해 구성 CloudWatch 알람을 통해 ASG의 스케일 인/아웃 진행 스케일 인/아웃 진행 시 디스코드 알람 전송 메트릭을 바탕으로 장애 발생 예상 시점에 디스코드 알람 전송 => CPU 사용률 (CPUUtilization) 값이 특정 값 이상일 때 경보 발생 시작 템플릿 구성 그룹정보 - 원하는 용량 : 1 - 최소 용량 : 1 - 최대 용량 : 1 시작 템플릿 구성 - Ubuntu Server (LTS) - t2..

목표 CI/CD 파이프라인 중 가장 마지막 단계인 운영에 있어 필요한 측정 항목(metric)과 AWS의 대표적인 모니터링 도구인 CloudWatch를 좀 더 잘 다룰 수 있게 연습합니다. 또한, 쿠버네티스 환경에서 사용하는 Prometheus와 Grafana 조합을 살펴봅니다. 모니터링 목표 - 서비스에 생길 수 있는 현황을 파악하고 문제를 모니터링 함 => 어떤 지표를 수집하고, 어떤 메트릭을 기준으로 삼아야 할까?? - 시간을 기준으로 측정되는 주요 메트릭을 최소화 하여 고가용성 달성 - 사용량을 추적하여, 배포에 앞서 세운 가설을 검증하고 개선 => 애자일에서는 "검증된 학습 (Validated learning) 을 적용한다." 고 함 https://www.boldare.com/blog/lean-..

프로젝트 개요 AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된 (loosely coupled) 어플리케이션 아키텍처에 대한 이해 프로젝트 요구사항 및 시나리오 프로젝트 명 : 을 위한 MSA 구성 Day 3 목표 Factory-API 문서 Factory-API Document Method - POST Path - /api/manufactures Request Body Schema : application/json { MessageGroupId : string(메시지 그룹 아이디) //"stock-arrival-group", MessageAttributeProductId : string(추가 생산이 필요한 제품 아이디), MessageAttributeProductCnt : string(추가 생산 요청..

프로젝트 개요 AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된 (loosely coupled) 어플리케이션 아키텍처에 대한 이해 프로젝트 요구사항 및 시나리오 프로젝트 명 : 을 위한 MSA 구성 Day 2 목표 메시지 큐의 Pub/Sub 패턴과 Producer/Consumer 패턴의 차이를 이해한다 DB와 서버와의 통신이 가능하도록 연결한다 특정 상황에서 SNS, SQS로 메세지가 전달되도록 시스템을 구성한다 SQS에 들어온 메세지를 레거시 시스템(Factory API)으로 전달하는 시스템을 구성한다 레거시 시스템(Factory API)의 콜백 대상이되는 리소스를 생성해 데이터베이스에 접근 할 수 있게 한다 Step 1 : Lambda 서버 (Sales API) - DB 연결 #1. 제공 받은 레..

프로젝트 개요 AWS 클라우드 환경을 기반으로 하는 느슨하게 연결된 (loosely coupled) 어플리케이션 아키텍처에 대한 이해 최소 요구 사항 Serverless 를 이용한 메시지 대기열 활용 이해 및 구현 요구사항에 따른 어플리케이션과 인프라 구현 문제사항 해결을 위한 추가 리소스 생성 -> DLQ, Legacy 시스템 성능문제 해결, SES 아키텍처 다이어그램 제작 Advanced 인프라 관리와 재사용성을 위한 IaC 활용 -> Terraform을 통한 리소스생성 프로젝트 요구사항 및 시나리오 프로젝트 명 : 을 위한 MSA 구성 시나리오 는 온라인으로 도너츠를 판매합니다. 웹사이트 통해서 주문 버튼을 누르는 것으로 구매(Sales API)가 가능합니다. 창고에 재고가 있다면 재고가 감소하고 ..

ReplicationController Deployment Statefulset DaemonSet Job CronJob ReplicationController Pod의 복제본 수를 유지하고 관리하는 컨트롤러 지정된 수의 Pod 본제본을 유지하고, Pod가 삭제되거나 장애가 발생한 경우새로운 Pod를 자동으로 생성한다. 장점 - 쉽게 구성이 가능하며, 안정적이고 예측가능한 작동이 가능하다. 단점 - 업그레이드나 롤백 작업과 같은 변경 사항이 발생할 때 수동으로 처리해야 하는 한계가 있다. Deployment ReplicationController 의 업그레이드된 버전으로, Rolling Update와 같은 전략을 통해 Pod를 업데이트할 수 있다. pod의 롤아웃을 관리하고 여러개의 ReplicationC..