chanstory

JDBC란? => Java Database Connectivity => 데이터 베이스에 대한 표준화 된 접근 방식 제공 => DBMS에 독립적으로 작성된 자바 어플리케이션이 데이터 베이스와 통신 가능 구성 자바 어플리케이션 -> JDBC API -> JDBC 드라이버 -> 데이터 베이스 JDBC 흐름 JDBC 드라이버 로드 -> DB 연결 -> 데이터 추가 및 수정 (SQL 문 사용) -> 결과처리 -> DB 연결 종료 JDBC 소스 예제 (간단한 SELECT문 사용 예제) => MySQL DB 내 customers 테이블 데이터 조회 import java.sql.*; public class JdbcExample { public static void main(String[] args) { // JDBC ..

mod_jk => 아파치 웹 서버와 톰캣 사이의 통신 담당 (AJP 프로토콜 사용) => 아파치 웹 서버에서 동적인 요청을 톰캣으로 전달 장점 - 높은 처리량 : AJP 프로토콜을 사용하여 아파치와 톰캣 간 효율적 통신 지원 - 유연한 설정 : workers.properies 파일을 사용하여 톰캣 서버와의 통신 설정을 자세히 할 수 있음 단점 - 설정 복잡성 : 사용자가 구성 옵션을 정확히 이해하고 설정해야 함 - 모듈 추가 필요 : mod_jk 모듈을 따로 설치하고 활성화 해야함 mod_proxy => 아파치 웹 서버를 프록시 서버로 동작 시켜 클라이언트의 요청을 톰캣과 같은 백엔드 서버로 전달 => HTTP, HTTPS 프로토콜 지원 장점 - 단순한 설정 : 아파치 웹서버 내장 모듈이므로 추가 설치 ..

yum 이란? => Yellowdog Updater Modififed => RPM 기반 리눅스 배포판에서 사용되는 패키지 관리 도구 => 패키지 의존성을 자동으로 처리하고 필요 패키지를 자동으로 설치함 => 패키지의 업데이트 및 관리를 쉽게 할 수 있음 => 설치된 소스들이 정해진 위치에 저장됨 => 설치 시간 단축 및 간단 단점 : 인터넷 연결 필수 및 패키지 저장소에 최신버전 패키지의 업데이트 시간이 소요될 수 있음 rpm 이란? => Red Hat Package Manager => 리눅스에서 사용되는 S/W 패키지 포맷 => 패키지를 설치, 업데이트, 제거 하는데 사용되는 명령어 => 패키지 의존성을 명확히 추적하고 관리 할 수 있음 => 독립적으로 작동하며 인터넷 연결이 필요치 않음 단점 : 패키..

Lambda 요금 부과 기준 요금 부과 기준 : 호출된 함수 실행 시간과 메모리 사용량에 따라 청구 요금 : 무료 티어 (매달 1백만 요청 또는 400,000 초의 실행 시간)를 포함하여 사용량에 따라 청구 매달 요청 수에 대해 $0.20/백만 요청, 함수 실행 시간에 대해 $0.00001667/GB-초의 가격이 부과 SNS 요금 부과 기준 (표준 주제 기준) 요금 부과 기준 : 호출된 함수 실행 시간과 메모리 사용량에 따라 청구 요금 : 무료 티어 (매달 1백만 SNS 요청 및 1백만 푸시 알림 메시지 무료제공)를 포함하여 사용량에 따라 청구 => 이후 1백만 개당 0.50 USD 요금 부과 (푸시 알림 메시지의 경우 추가 0.50 USD / 백만 메시지) => 64KB의 게시된 데이터 청크 하나가 1..

AWS SES 란? AWS 에서 제공하는 완전 관리형 이메일 발송 서비스 안전하고 신뢰성 높은 방법으로 이메일을 전송 이메일 인프라를 구축하고 관리할 필요 없이 비용 절감 가능 이메일 발송 이력과 통계 추적 가능 스팸 필터링, 이메일 유효성 검사, 이메일 인증 및 보안 기능 제공 -> 신뢰성 및 안전성 보장 이메일 마케팅, 발송 이메일, 회원 가입 확인 메일 등에 사용됨 AWS SES와 AWS SNS 이메일 차이점 SES는 완전 관리형 이메일 발송 서비스이며 안전하고 신뢰성 높은 방법으로 전송 SMTP, API 또는 AWS SDK를 통해 메일을 전송하고 이메일 템플릿을 사용하여 본문 구성 가능 SES는 필터링, 이메일 유효성 검사, 이메일 인증 및 보안 기능 제공 SNS는 다양한 푸시 알림 및 메시지를 ..

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..