호랑이한테물릴래

CTO의 요청을 간단히 정리하자면, - 모니터링을 개발자와 클라이언트 모두 쉽게 확인하고 접근할 수 있어야한다. - 이상수치도 모니터링을 통해서 확인할 수 있어야한다. - 진입점(테스트)이 캡슐화될 수 있으면 좋겠다. 그래서 내일부터 진행해야할 업무는 아래와 같다. Lambda 대략적인 코드 webhook s3 데이터 받아오기 에러 코드, 비정상적인 데이터 정제 s3에 밀어넣기 Data processing S3 -> Glue data catalog Athena 연결 Grafana로 연결을 위한 쿼리문 진입점 설계 Kinesis 앞단에 API Gateway 붙여서 Proxy 역할로 사용 센서 데이터를 k6 or python 코드를 활용해서 ECS에 배포 ECS와 API Gateway 연결 Athena 아래..

1) 기술스택 - kinesis : 실시간 데이터를 스트림으로 받아주는 서비스, iot에서 온도, 습도, co2 데이터를 수집하여 필요한 서비스에 전달할 계획이다. - glue : kinesis에서 데이터를 전달받아 데이터를 정제, 가공한다. - s3 : glue에서 정제된 데이터를 받아 저장한다. - athena, quicksight : s3의 데이터에서 쿼리를 이용하여 분석하고 간단한 시각화 작업을 진행한다. + 추가적으로 데이터의 이상값이 발견될 경우, 경보하는 기능 구성을 위해서 s3의 이벤트 트리거로 lambda를 구성할 계획이다. 모든 데이터 값들을 확인하여 이상 데이터를 lambda에서 확인한다고 보면된다. quicksight에서 간단한 시각화는 가능하지만, 일반인이 쉽게 접근하고 이해할 수..

매번 거래소 사이트에 접속해서 시세를 알아보는게 여간 귀찮은게 아니다. 5G가 아니면 접속하는데 은근히 시간이 많이 소요된다. 그래서 빠르게 응답할 수 있는 텔레그램 봇을 이용해서 원하는 코인 시세만 확인할 수 있는 서버를 만들었다. AWS lambda를 활용할 수 있도록 terraform도 구성해봤다. 사용한 라이브러리 : axios, node-telegram-bot-api 시세 API : upbit //app.js require("dotenv").config(); const axios = require("axios").default; const TelegramBot = require("node-telegram-bot-api"); const token = process.env.TOKEN; // Crea..

모든 프로세스에 DB를 거치기 때문에 시스템을 고성능으로 유지하기 위해선 DB의 구조와 매커니즘 또한 아주 중요한 요소 중 하나다. 문제상황 : 너무 많은 읽기 연산 해결책 : 데이터베이스 다중화 Primary를 복제해서 Secondary와 Teriary로 분할한다. 다중화(레플리케이션)의 이점 더 나은 성능(읽기 성능은 부 DB의 갯수와 비례한다)과 CQRS(commit command 책임 분리) 안정성 가용성 주 DB에 문제가 생기면 부 DB가 주 DB로 승격된다. 문제상황 : 너무 많은 데이터(~1TB) 해결책 : 파티셔닝(샤딩) 주 특징은 샤딩된, 나눠진 파티션은 고유한 data만 있다. 그래서 해당 DB를 가지고 하나의 노드를 만들어서 부하분산이 가능해진다. 문제 상황 : 낮은 검색 성능 해결책..

시스템 성능을 파악하는데 주요 메트릭은 Throughput과 Latency다. Throughput 시간당 처리량을 의미한다. 1초에 처리하는 HTTP 요청(Request) 수 혹은 네트워크로 전송되는 데이터 전송 속도가 대표적이다. Throughput을 개선하기 위해서는 병목 구간이 어디인가를 먼저 파악하는 것이 중요하다. 대체로 2가지의 개선방법이 있다. 어플리케이션 개선 : 개발된 어플리케이션을 개선하는 것이다. 현상을 먼저 파악 (APM, Application Performance Monitoring)을 시작으로, 알고리즘 개선, I/O 최소화 등의 개선 방안이 따른다. DevOps가 이를 모니터링하고 개발자가 여러 도구를 통해서 개선해야한다. 하위 시스템의 확장 : 대부분 Throughput 개선..

가용성과 확장성 가용성(Availability)는 시스템이 정상적으로 사용 가능한 정도를 의미한다. 정상 사용시간(Uptime)을 정상사용시간과 사용불가시간(Downtime)을 합친 전체 사용시간으로 나눈값을 표현한다. 가용성 99.95%는 1년에 4시간 22분의 다운타임이 된다. 서비스 사용 불가시간을 최소로 하는 것이야말로, 더 높은 가용성을 달성하는 것이다. 또한, 가용성의 핵심으느 단일 장애점(Single Point of Failure)를 없애는 것이다. 어떤 한 노드가 장애가 발생하더라도, 다른 노드가 대체할 수 있어야한다. 이것을 시스템 확장이라고 말한다. 확장성(Scalability)은 요구되는 시스템의 성능에 따라서 동적으로 서버 구성이 변경되고, 시스템 처리 능력을 최적화할 수 있는 것을..

SLI(서비스 수준 척도, Service Level Indicator) 서비스 수준을 판단할 수 있는 정량적인 측정 값이다. 응답속도: 요청에 대한 응답이 리턴되기까지의 시간 에러율: 전체 요청 수 대비 에러 처리량: 초당 처리할 수 있는 요청 수 가용성: 서비스가 사용가능한 상태로 존재하는 시간 비율 내구성: 데이터 저장이 중요한 경우 SLO(서비스 수준 목표, Service Level Objectives) SLI를 기준으로 서비스의 목표를 정한다. SLI

지난 프로젝트2를 기억하면 늦게 합류해서 정신없이 하다가 애매하게 마무리했던지라, 이번 프로젝트3는 '1인분이라도 하자'는 심정으로 시작했다. (프로젝트2는 도움을 많이 받았으나, 이번에는 내가 누군가에게 도움이 될 수 있으면 좋겠다는 작은 바램과 함께) 돌이켜보면 프로젝트를 할때마다, '코딩'에서 많이 헤맸다. 그래서 이번 프로젝트를 시작하기 전에 지난 스프린트들의 코드들을 한번 더 살펴보고 AWS 서비스들을 구성하는 연습을 했다. 결과적으로, 이번 프로젝트는 다행히도 1인분?은 한것같다. 처음 tutorial에서 서버리스 부분에서 헤맸지만, 본격적인 msa 구성에서부터 조금씩, 스스로 나아갈 수 있었고 팀원과 고민하고 작은 도움도 줄 수 있었다. 이전과는 다르게, 전체 코드를 간단히 파악해서 작은 수..

프로메테우스는 오픈소스 모니터링/알림 시스템이다. 쿠버네티스와 노드, 프로메테우스를 모니터링할 수 있다. 쿠버네티스를 지원하는 재단 CNCF가 프로메테우스를 관리하고 있고 이 두 도구의 시각화를 담당하는 Grafana를 포함, 이 세 가지가 한 묶음으로 많이 쓰이는 편이다. Prometheus 구성요소 시계열(Time series) 데이터를 저장 다양한 exporter로부터 대상의 메트릭을 pull하여 주기적으로 가져오는 모니터링 시스템 Alert manager로 경고, 알람 설정 사용자가 직접 질의가능한 Web UI(PromQL언어 사용) 쿠버네티스 exporter 프로메테우스는 쿠버네티스 메트릭을 가져올 수 있는 쿠버네티스 exporter가 있다. exporter는 kube API를 사용한다.

TEST - 1 function hello(){ return 'hello'; } async function helloAsync(){ return 'hello Async'; } console.log(hello()); helloAsync().then((res)=>{ console.log(res); }) async를 선언한 함수의 리턴값은 resolve의 결과값이 된다. TEST - 2 function delay(ms){ return new Promise((resolve)=>{ setTimeout(resolve, ms) }) } // 3초 기다린뒤 hello Async 반환하는 것 async function helloAsync(){ return delay(3000).then(()=>{ return "hello..