기록을 통한 복습

백준[21921] 블로그

빠쿤 — Thu, 27 Jun 2024 20:57:54 +0900

문제: https://www.acmicpc.net/problem/21921
분류: 누적합, 슬라이딩 윈도우
난이도: S3
소요시간: 10m
자아성찰:
- 특정 배열구간의 합 관련 문제에서 효율적인 풀이 (= 구간합, 슬라이딩 윈도우)를 복습하고자 선택한 문제
- 문제에서 주어진 배열의 최대 길이, 구간 길이는 250000
  - 이중 for문을 통한 처리 시 O(N^2)로 오랜 시간이 걸림
- 누적합(Prefix Sum)을 통해 구하는 방식
  - a ~ b 구간합 = prefixSum[b] - prefixSum[a - 1]
- 슬라이딩 윈도우(Sliding Window)를 통해 구하는 방식
  - 구간 크기가 X일 때
  - 1 ~ X 합 최초 초기화
  - 이후 위치 i를 증가시키며 현재 윈도우 값 - [i - X]번째 값 (맨 앞의 값) + [i]번째 값 (새로운 값)
- 두 방식을 이용하면 시간복잡도는 O(N)으로 풀이가 가능하다.

누적합 (Prefix Sum) - 372ms

package main;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class B_21921_prefix_sum {
    static int N, X;
    static int[] prefixSum;
    static int max, day = 1;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        X = Integer.parseInt(st.nextToken());
        prefixSum = new int[N + 1];
        st = new StringTokenizer(br.readLine());
        // 누적합 배열 초기화
        // i번째 구간합 = 1 ~ i까지의 합 = i - 1번째 구간합 + i번째 값
        for (int i = 1; i <= N; i++) {
            prefixSum[i] = prefixSum[i - 1] + Integer.parseInt(st.nextToken());
        }
        // 1 ~ X 합 최댓값으로 초기화
        max = prefixSum[X];
        // 구간합 이용, i번째 ~ i + X - 1번째 구간합 계산
        // a ~ b까지 구간합 = prefix[b] - prefix[a - 1]
        for (int i = 2; i <= N - X + 1; i++) {
            int cur = prefixSum[i + X - 1] - prefixSum[i - 1];
            if (cur > max) {
                max = cur;
                day = 1;
            } else if (cur == max){
                day++;
            }
        }
        System.out.println(max == 0 ? "SAD" : max);
        if (max > 0) System.out.println(day);
    }
}

슬라이딩 윈도우 (Sliding Window) - 368ms

package main;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.StringTokenizer;

public class B_21921_sliding_window {
    static int N, X;
    static int[] arr;
    static int max, window, day = 1;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st = new StringTokenizer(br.readLine());
        N = Integer.parseInt(st.nextToken());
        X = Integer.parseInt(st.nextToken());
        arr = new int[N];
        st = new StringTokenizer(br.readLine());
        for (int i = 0; i < N; i++) {
            arr[i] = Integer.parseInt(st.nextToken());
        }
        // 최초 윈도우 값 설정 (0 ~ X 합)
        for (int i = 0; i < X; i++) {
            max += arr[i];
            window += arr[i];
        }
        // 슬라이딩 윈도우 이용, 한 칸씩 윈도우 이동
        // 현재 윈도우 = 현재 윈도우 - 현재 윈도우 맨 첫번째 방문자수 + i일 방문자수
        for (int i = X; i < N; i++) {
            window -= arr[i - X];
            window += arr[i];
            if (window > max) {
                max = window;
                day = 1;
            } else if (window == max) {
                day++;
            }
        }
        System.out.println(max == 0 ? "SAD" : max);
        if (max > 0) System.out.println(day);
    }
}

[AWS, Certified Developer Associate] AWS KMS, SSM Parameter Store

빠쿤 — Tue, 18 Jun 2024 19:44:12 +0900

AWS KMS (Key Management Service)

AWS 서비스에서 '암호화'라고 하면 대부분 KMS 암호화를 의미할 가능성이 높음
암호화 키 관리
CloudTail을 통해 키를 사용하기 위한 API 호출 추적 가능
API call을 통해 KMS 키 암호화 사용 가능 (SDK, CLI 등)
KMS 키
- Symmetric (AES-256)
  - 암호화/복호화에 하나의 키가 사용
  - 대부분의 AWS Service는 대칭키 사용
  - 키 자체에 액세스 불가능 (API call을 통해서만)
- Asymmetric (RSA & ECC)
  - 암호화에 사용되는 공개키 & 복호화에 사용되는 개인키
  - 암/복호화 및 서명/검증 작업에 사용
  - 공개키는 KMS에서 다운로드 가능 / 개인키 액세스 불가능 (API call을 통해서만)
  - 사용사례 : KMS 키에 액세스할 수 없거나 액세스 권한이 없는 사용자가 클라우드 외부에서 공개키를 통해 암호화 수행
    - AWS 계정에서 개인키로 복호화
KMS 키는 리전별로 범위가 지정됨
키에 대한 정책 설정 (Key Policies)
정책 설정이 없으면 아무도 해당 키에 접근 불가능
- 기본 정책 : 특정한 사용자 지정 KMS 키 정책이 제공되지 않는 경우 생성 / 기본적으로 계정 내 모든 사람이 키에 액세스 허용
- 사용자 지정 정책 : 키에 액세스 가능한 사용자, 역할 정의 / 키를 관리하는 사람 정의, 교차 계정 액세스 설정 시 유용
4KB 넘어가는 데이터에 대해서는 Envelope Encryption 사용 (GenerateDataKey API)

SSM Parameter Store

구성 / 보안 암호를 안전하게 보관하기 위한 장소
필요 시 KMS 암호화 가능
서버리스 / 확장성 / 내구성 / SDK 사용 쉬움
구성 업데이트 시 버전 생성되어 버저닝 가능
IAM 적용 가능
EventBridge로 알림 설정
CloudFormation과 통합 (매개변수 사용)
계층별로 데이터 관리 가능 (IAM 접근 권한 범위 지정 가능)
파라미터 정책 설정 가능 (고급 플랜에서만)
- 파라미터 만료 날짜 설정 가능
- EventBridge를 통해 n일 뒤 알림 발송 가능 (pw 변경 알림 등에 사용)

SSM Parameter Store vs Secrets Manager

Secrets Manager
- 더 비쌈
- 람다 함수를 통해 암호 순환 자동화 가능
- 람다 함수는 RDS, Redshifts, DocumentDB로부터 제공됨 (시간 절약 가능)
- KMS 암호화 필수
- CloudFormation과 통합 가능
Parameter Store
- 비용 저렴
- 단순한 API
- 암호 순환은 없음 (CloudWatch 이벤트에 의해 트리거되는 람다 함수를 통해 직접 가능)
- KMS 암호화 선택
- CloudFormation과 통합 가능
- Parameter Store API를 통해 Secrets Manager 암호 풀링 가능

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] Step Functions

빠쿤 — Sat, 15 Jun 2024 19:38:50 +0900

AWS Step Functions

AWS 서비스 오케스트레이션 / 비즈니스 프로세스 자동화 / 서버리스 애플리케이션 구축에 사용되는 시각적 워크플로 서비스
실패, 재시도, 병렬화, 서비스 통합 등을 관리
json 형태로 워크플로 정의
상태
- Choice : 브랜치 (or 기본 브랜치)로 보낼 조건 테스트
- Fail / Succeed : 워크플로의 실패 / 성공 여부로 실행을 중지
- Pass : 입력값을 출력값에 전달 or 작업을 수행하지 않고 고정된 데이터 주입
- Wait : 특정 날짜/시간동안 지연
- Map : 단계를 동적으로 반복
- Parallel : 브랜치 수행을 병렬적으로 수행

Step Functions - 오류 핸들링

Step Function 자체에서 오류 처리 메커니즘 정의 가능
이를 통해 코드에서의 에러 처리 제외 > 복잡도 감소
Retry (재시도) / Catch (실패한 경로로 오류 전환) 두가지 방식이 존재
사전정의된 에러 코드
- States.ALL : 모든 오류이름과 매칭
- States.Timeout : 타임아웃
- States.TaskFailed : 태스크 실행이 자체적으로 실패
- States.Permission : 태스크 실행을 위한 권한 관련
Retry
- 오류 발생 시 재시도 관련 처리
- ErrorEquals : 오류 타입 (CustomError, States.TaskFailed ...)
- IntervalSeconds : 재시도 간격
- MaxAttempts : 최대 재시도 횟수 (기본값 3, 0 설정 시 재시도 X)
- BackoffRate : 지수 백오프 수치
- MaxAttempts까지 재시도 후 오류 발생 시 Catch 블록 실행
Catch
- 실패 경로로 오류 전환
- ErrorEquals : 오류 타입
- ResultPath : 전송되는 입력값의 경로 ("$.error" 설정 시 기본 입력값과 함께 오류 정보도 함께 전송, 오류 분석 및 디버깅 가능)
- Next : 결과를 보낼 상태
  - Type : 상태 (Pass 등)
  - Result : 응답 결과
  - End : 종료여부

Step Functions - 워크플로 비교 Standard vs Express

Standard
- Max Duration : 최대 1년
- 실행 모델 : 정확히 1회 실행
- 실행 : 초당 약 2000개 워크플로 실행
- 실행 기록 : 콘솔에 최대 90일 기록 / CloudWatch 사용 영구보존 가능
- 비용 : # of 상태전환
- 사용사례 : 멱등성 보장되지 않는 작업 (결제 처리)
Express
- Max Duration : 최대 5분
- 실행 : 초당 약 10만
- 실행 기록 : 콘솔에서는 기록 불가 / CloudWatch 사용
- 비용 : # of 실행횟수, 실행기간, 메모리 사용량
- 사용사례 : IoT 데이터 수집, 스트리밍 데이터 처리, 모바일 앱 백엔드
- 비동기
  - 최소 1회 실행 보장 (오류 발생 시 동일한 작업 2번 실행 가능 / 멱등성 관리 필요)
  - 실행 결과 기다리지 않음 (CloudWatch에서 결과 확인)
  - ex) 메시지 서비스
- 동기
  - 최대 1회 실행 보장 (실패하더라도 워크플로 재시작 X, 재시도 필요 시 사용자가 로직 직접 구현)
  - 실행 결과 기다림 (결과를 즉각적으로 응답받아야 하는 경우)
  - ex) 마이크로서비스 오케스트레이션
  - Gateway or Lambda 함수에서 호출되어 응답 가능

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] Cognito - User Pools, Identity Pools

빠쿤 — Thu, 13 Jun 2024 20:48:37 +0900

Amazon Cognito

사용자에게 자격 증명을 부여해 웹, 모바일 애플리케이션과 상호작용 할 수 있도록 하는 것
두가지 하위 서비스 존재
Cognito User Pools
- 앱 사용자를 위한 로그인 기능 제공
- API Gateway & ALB와 통합
Cognito Identity Pools (Federated Identity)
- 앱에 등록된 사용자가 AWS 리소스에 바로 액세스 가능하도록 임시 AWS 자격 증명 부여
- 사용자 풀과 통합
vs IAM : Cognito는 AWS 외부의 웹/모바일 애플리케이션 사용자를 위한 것 (수백만 사용자, 모바일 사용자, SAML 인증)

Cognito - User Pools

웹 / 모바일 애플리케이션 사용자에 대한 서버리스 데이터베이스를 생성할 수 있는 방법
단순 로그인 : 유저이름(or 이메일) + 패스워드 조합으로 애플리케이션 접속 가능
비밀번호 변경 가능 / 이메일 및 전화번호 인증 가능 / MFA 지원 / Facebook, Google, SAML 등으로 인증 가능 (연합 인증)
개인정보 유출 시 사용자 차단 기능 제공
로그인 시 JWT 제공
자체 내부 사용자 db를 가짐

Cognito - Identity Pools (Federated Identities)

앱에 등록된 사용자가 AWS 리소스에 바로 액세스 가능하도록 임시 AWS 자격 증명 부여
Public Provider를 통해 인증 가능 (Amazon, Facebook, Google, Apple..)
User Pools를 통해 인증 가능
OpenID Connect Provider & SAML Identity Providers를 통해 인증 가능
Developer Authenticated Identites (커스텀 로그인 서버)를 통해 인증 가능
인증되지 않은 게스트 사용자에게도 가능
권한을 받은 사용자는 SDK를 통한 API 콜 | Gateway를 통해 AWS 액세스 가능
이러한 권한 정책은 STS를 거쳐 획득
정책 변수를 통해 특정 AWS 서비스에 접근할 수 있는 권한 설정 가능

Cognito - User Pools vs Identity Pools

User Pools
- 인증, 자격 증명 인증에 사용
- 웹 / 모바일 애플리케이션 사용자를 위한 db
- 연합 로그인 허용
- 인증에 필요한 호스팅 UI 사용자 지정 가능 (로고 등)
- 인증 흐름에서 사전 / 사후 방식으로 람다와 통합 가능
Identity Pools
- 권한부여, 액세스 관리에 사용
- AWS 환경에 액세스 권한 부여
- 게스트 사용자 (미인증) 에 대한 권한 부여 가능
CUP + CIP = 인증 + 인가

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] CodeStar, CodeArtifact, CodeGuru

빠쿤 — Wed, 12 Jun 2024 20:40:24 +0900

AWS CodeStar

GitHub, CodeCommit, CodeBuild, CodeDeploy, CloudFormation, CodePipeline, CloudWatch 등의 서비스를 그룹화하는 통합 솔루션
- 코드 저장 및 버전관리 / 코드 설계 및 테스트 / 코드 배포 / 인프라 프로비저닝 / 파이프라인 조정 / 모니터링 배포
이슈 트래킹 도구 존재 + Jira / Github 이슈와 통합 가능
Cloud9 도구를 통해 코딩을 통합 가능 (Web IDE로 클라우드에서 바로 코딩 가능)
모든 구성요소를 볼 수 있는 대시보드 존재
무료, 다른 서비스에 대한 비용만 지불

AWS CodeArtifact

소프트웨어 개발을 위한 보안, 확장성, 비용 효율적인 아티팩트 관리 시스템
- 아티팩트 관리 : 각각의 소프트웨어 종속성을 저장하고 가져오는 것
일반적인 종속성 관리 도구(Maven, Gradle ..)와 통합됨
개발자와 CodeBuild가 클라우드 내 CodeArtifact에서 종속성 검색 가능
EventBridge와 통합 가능
- CodeArtifact에서 패키지 생성 / 수정 / 삭제 시 이벤트 발생
- 해당 이벤트를 EventBridge에 내보냄
- EventBridge에서 Lambda 함수, Step Function, SNS, SQS 트리거
- CodePipeline 트리거도 가능
  - 업데이트 된 종속성으로 애플리케이션 다시 빌드 (코드 내 항상 최신 종속성 보장)
CodeArtifact 리포지토리 액세스 권한 부여 시에는 모든 패키지 액세스 권한 부여 or 아무것도 부여 X

AWS CodeGuru

머신러닝 기반 서비스
자동화된 코드 검토
- Reviewer에서 정적 코드 분석으로 자동 코드 분석 (개발)
애플리케이션 성능 권장 사항 제공
- Profiler에서 런타임 (프로덕션)에 애플리케이션에 관한 가시성 / 비용 개선 등 권장 사항 제공
Agent 구성을 통해 프로파일 조정 가능
- MaxStackDepth : 메서드 깊이에 대해 검사할 깊이 설정
- MemoryUsageLimitPercent : 프로파일러가 사용 가능한 메모리양
- MinimumTimeForReportingInMilliseconds : 보고서 전송 간 최소 시간
- SamplingIntervalInMilliseconds : 샘플을 프로파일링 하는데 사용되는 샘플링 간격

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] CodeCommit, CodePipeline, CodeBuild, CodeDeploy

빠쿤 — Tue, 11 Jun 2024 19:25:07 +0900

AWS CodeCommit

GitHub, GitLab, Bitbucket 등의 버전관리 툴과 달리 코드가 AWS 클라우드의 개인 VPC 내에 있음
- 비공개 Git Repo
- 사이즈 제한 없음 (코드를 GB 크기까지 확장가능)
- 완전관리형, 고가용성
- 코드는 AWS 클라우드 내에만 저장 -> 일관된 형식 / 높은 보안
- 보안 강화 (암호화, IAM을 통한 액세스 제어)
- 젠킨스, CodeBuild 등의 CI 툴과 통합 가능
보안
- 인증 (Authentication) : SSH Key / HTTPS
- 인가 (Authorization) : IAM 정책
- 암호화
  - AWS KMS를 통해 암호화
  - 코드 커밋 시 HTTPS or SSH를 통해서 암호화된 상태로만 전송됨
- 교차 계정 접근 : IAM 역할 생성 & AWS STS (AssumeRole API) 통해 코드커밋 repo 액세스

AWS CodePipeline

AWS 안에서 CI/CD를 오케스트레이션 할 수 있는 시각적 워크플로 툴
소스 - CodeCommit, ECR, S3, Bitbucket, GitHub
빌드 - CodeBuild, Jenkins, CloudBees, TeamCity
테스트 - CodeBuild, AWS Device Farm, 3rd party tools
배포 - CodeDeploy, Elastic Beanstalk, CloudFormation, ECS, S3
호출 - Lambda, Step Functions
수동 승인 기능 제공
각 단계마다 artifacts가 S3 버킷에 저장되고 다음 스테이지로 이동

AWS CodeBuild

CodeCommit 등의 소스코드 내에 설정 파일이 존재 (buildspec.yml, 코드의 루트에 존재해야함)
출력 로그는 S3 & CloudWatch Logs에 적재될 수 있음
CloudWatch Metrics를 통해 빌드 통계를 모니터링 가능
EventBridge로 빌드 실패 / 트리거 알림 감지 가능
CloudWatch Alarm을 통해 다량의 실패에 대한 threshold 확인 가능
Build Projects는 CodePipeline이나 CodeBuild에서 정의될 수 있음
or 이미 존재하는 Build Projects 호출 가능
빌드 시 S3에 진행상황을 캐싱하여 재시도 지원 (최적화)

AWS CodeDeploy

애플리케이션 배포를 자동화해주는 배포 서비스
EC2 Instance, 온프레미스 서버, 람다 함수, ECS 서비스에 배포
CloudWatch Alarm 트리거 등의 이벤트에 대한 롤백도 가능
배포 조절 가능 (한번에, 하나씩, 절반씩, 블루/그린)
- AllAtOnce : 한번에 업데이트 (다운타임 높음)
- HalfAtTime : 절반씩 업데이트
- OneAtATime : 하나씩 업데이트 (가장 느림, 가용성 좋음)
- 커스텀하게 % 정의 가능
배포 방식을 통제하는 appspec.yml 파일
EC2 인스턴스 / 온프레미스 서버 플랫폼
- in-place 배포 (현재 위치에 down / 배포)
- blue/green 배포 (새로운 ASG 생성해 배포)
- 타겟 인스턴스에 CodeDeploy Agent가 실행되어야 함
람다 플랫폼
- 람다 별칭에 대해 점진적으로 트래픽 신규 버전으로 이동 가능
  - Linear : 100% 도달까지 N분마다 트래픽 이동
  - Canary : X% 트래픽 이후 100% 트래픽 이동
  - AllAtOnce
ECS 플랫폼
- 자동으로 새로운 ECS 태스크 정의
- 블루/그린 배포에만 사용 가능
  - Linear : 100% 도달까지 N분마다 트래픽 이동
  - Canary : X% 트래픽 이후 100% 트래픽 이동
  - AllAtOnce

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] API Gateway - 개요, 엔드포인트 유형, 통합 방식

빠쿤 — Mon, 10 Jun 2024 21:22:39 +0900

AWS API Gateway

클라이언트가 액세스 가능하도록 공개적인 REST API를 만들 수 있는 서버리스 서비스
람다 + 게이트웨이 = 완전관리형 서버리스
실시간 스트리밍 - 웹소켓 프로토콜 지원으로 실시간 스트리밍 가능
버저닝 - API 버저닝 가능 (v1, v2.. )
다양한 환경 지원 (dev, test, prod..)
인증, 권한 부여 목적으로 보안 처리 가능
API 키를 통해 게이트웨이의 요청 수에 따라 쓰로틀링 가능
Swagger, Open API 3.0등 표준을 통해 API 정의 가능
API 게이트웨이 수준에서 요청/응답을 변환 및 무효화 통한 유효성 검사 가능
SDK, API 규격 생성 가능
API 응답 캐싱 가능
람다와 통합
- 람다 함수 실행
- 람다를 REST API로 쉽게 내보낼 수 있음
HTTP와 통합
- HTTP 엔드포인트를 내보낼 수 있음
- 온프레미스 HTTP API, ALB를 API로 내보낼 수 있음
- 용도 : API 게이트웨이를 사용한 속도제한, 캐싱, 사용자인증, API 키를 활용한 쓰로틀링 등
AWS 서비스와 통합
- ex 1) API 게이트웨이에서 바로 SQS에 메시지 전송
- ex 2) API 게이트웨이에서 바로 Kinesis Data Streams로 요청 전송 -> Kinesis Data Firehose -> S3 버킷

AWS API Gateway - 배포방식 (엔드포인트 유형)

Edge-Optimized (default)
- 글로벌 클라이언트에 이용
- 모든 CloudFront Edge Location을 통해 요청을 라우팅하므로 지연시간 짧음
- API 게이트웨이는 생성한 한 리전에만 남으나 모든 CloudFront Edge Location에서 액세스 가능
Regional
- CloudFront Edge Location 사용 X
- 모든 사용자가 API 게이트웨이를 만든 리전 내에 위치할 것으로 예상할 때 사용
- CloudFront 배포를 자체적으로 만들 수 있음 (Edge-Optimized와 동일한 방식 / 캐싱 전략, 분산 전략 등 더 많은 제어 가능)
Private
- VPC 내에서만 액세스 가능 (interface VPC endpoint (ENI) 사용)
- 액세스 정의에 리소스 정책 사용 가능

AWS API Gateway - 통합 방식

MOCK
- 백엔드로 요청을 전송하지 않고 응답이 반환 (mock 데이터)
- 개발 및 테스트 용도
HTTP / AWS (Lambda & AWS Services)
- 통합 요청 / 응답을 모두 구성하는 방식
- 요청 / 응답 매핑 템플릿을 사용해 데이터 매핑 구성 가능 (쿼리 문자열 매개변수 이름 변경, 본문 콘텐츠 수정, 헤더 추가/수정)
  - Velocity Template Language (VTL)을 통해 for 루프, if문 등 처리
- Content-Type은 application/json 또는 application/xml 설정
- Client -> API Gateway -> SQS Queue 처리 시 요청 구성 / SQS 큐가 이해할 수 있도록 API 호출에 대해 변경, 이름변경, 재정렬 수행
AWS_PROXY (Lambda Proxy)
- 클라이언트의 요청이 람다의 입력이 됨 (람다로 프록싱)
- 요청 / 응답 수정 불가
- 요청 / 응답 로직에 대해 함수만 동작
HTTP_PROXY
- 요청이 직접 전달 (HTTP 백엔드로 프록싱)
- 백엔드 응답 시 응답을 클라이언트에게 전달
- HTTP 헤더 추가 가능 (ex, API 키 추가)
- ex) Client -> API Gateway -- API Key 추가 --> ALB

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] DynamoDB - LSI, GSI, DAX, S3와 연동 사례

빠쿤 — Sun, 9 Jun 2024 17:55:48 +0900

AWS DynamoDB - LSI (Local Secondary Index)

테이블에 대체 정렬 키 제공 (Alternative Sort Key)
하나의 스칼라 속성으로 존재 (String, Number, Binary)
테이블 당 최대 5개 LSI 가능
테이블 생성 전 정의
테이블로부터 일부 또는 전체 속성 얻을 수 있음 (LSI 생성 시 결정)
메인테이블의 WCU, RCU 사용
특별히 쓰로틀 고려할 것 없음

AWS DynamoDB - GSI (Global Secondary Index)

테이블에 대체 기본 키 제공 (Alternative Primary Key)
non-key 속성의 쿼리 속도 높이는데 유용
하나의 스칼라 속성으로 존재 (String, Number, Binary)
해당 인덱스에 대해서는 반드시 RCU, WCU 프로비저닝 해야함
테이블 생성 후에도 추가 및 생성 가능
GSI에서 쓰로틀 발생 시 메인 테이블도 쓰로틀됨

AWS DynamoDB - Accelerator (DAX)

완전 관리형, 고가용성의 인메모리 캐시
인기있는 데이터 쿼리 시 캐시된 읽기와 쿼리에 대해 마이크로초 지연
애플리케이션 로직 변경 없이 기존 DynamoDB API와 호환 (DAX 클러스터 생성)
핫키 문제 해결에 유용 (RCU 쓰로틀 방지)
Application <-> DAX Cluster <-> DynamoDB
기본 TTL 5분
노드로 구성. 최대 10개 노드
프로덕션 권장 사양인 노드가 최소 3개 이상인 다중 AZ 설정 사용 권장 (AZ당 하나씩)
vs ElastiCache
- DAX는 개별 객체 캐시 / 쿼리&스캔 캐시 (간단한 유형의 쿼리)
- ElastiCache는 복잡한 연산/집계 결과 등 캐시

AWS DynamoDB - Streams

테이블에서 item level의 수정에 대한 정렬된 스트림
KDS, Lambda, Kinesis Client Library applications 등에서 스트림을 읽을 수 있음
보존 주기는 최대 24시간
사용 사례
- 테이블에서 발생하는 실시간 변경사항에 대응 (환영 이메일 등)
- 분석
- 글로벌 테이블과 cross-region replication 구현 등
- Application -> Table -> DynamoDB Streams -> Kinesis Data Streams -> Kinesis Data Firehose -> Amazon Redshift (분석) / Amazon S3 (아카이빙) / Amazon ElasticSearch (인덱싱)
- 사용자 지정 로직을 태우려면 DynamoDB Streams를 EC2에서 실행되는 KCL App or Lambda에서 읽어 처리 가능 (SNS로 보내 메시지, 알림 처리 가능 / 필터링, 변환을 통해 다시 DynamoDB 테이블에 저장)

AWS DynamoDB - S3와 연동

큰 사이즈의 객체를 DynamoDB에 저장
- DynamoDB 테이블에는 400KB 데이터까지만 저장 가능
- 이미지, 영상 등을 저장하기에는 부적합
- S3에 이미지, 영상 저장 -> DynamoDB에 메타데이터 저장 (url 등, S3에 대한 포인터 역할)
DynamoDB를 S3 객체 메타데이터의 인덱스로 사용
- S3에 저장 -> 알림을 통해 람다 수행 -> 람다는 DynamoDB에 S3 객체의 메타데이터 저장
- S3 버킷의 특정 타임스탬프로 객체 검색 / 사용자 사용 총 스토리지 / 속성에 따라 객체를 리스팅 / 업로드된 S3 객체 검색 등의 애플리케이션 요청에 대해 DynamoDB 테이블 쿼리를 통해 결과를 빠르게 찾고 S3 버킷에서 필요한 객체를 검색

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

[AWS, Certified Developer Associate] DynamoDB - 기초, 용량 모드, 기본 API

빠쿤 — Sun, 9 Jun 2024 16:37:35 +0900

AWS DynamoDB - 소개

고가용성의 NoSQL 서버리스 데이터베이스
여러 AZ에 걸쳐 즉시 복제 가능
검색 속도가 빠르고 지연시간 낮음
보안, 권한부여, 관리를 위한 IAM과 통합
DynamoDB Streams를 통해 이벤트 기반 프로그래밍 활성화 가능
낮은 비용, 오토스케일링 지원

AWS DynamoDB - 기초

각 테이블은 Primary Key(기본 키)를 가짐
- 테이블을 만들기 전에 기본키를 정의해야 함
각 테이블은 items(=rows)을 무한으로 가질 수 있음
각 item은 속성(attribute)을 가짐 (nullable) (시간이 지나도 추가 가능)
각 item의 최대 크기는 400KB
데이터 타입 지원
- 스칼라 타입 - 문자열, 숫자, 이진수, boolean, null
- 문서 타입 - List, Map
- 집합 타입 - String Set, Number Set, Binary Set

AWS DynamoDB - 기본키 (Primary Key)

옵션 1 - Partition Key (Hash 전략)
- 항목마다 고유해야 함
- 데이터가 분산될 수 있을만큼 다양해야함 (카디널리티가 높은 속성을 택해야함)
옵션 2 - Partition Key + Sort Key (Hash + Range 전략)
- 두 항목의 조합은 고유해야 함
- 데이터는 파티션 키를 기준으로 그룹핑됨
- ex) 여러 게임을 하는 사용자에 대해 PK : user_id / SK : game_id

AWS DynamoDB - 읽기 / 쓰기 용량 모드 (Capacity Mode)

테이블의 용량을 제어하는 방법
프로비저닝 모드 (기본값)
- 초당 읽기/쓰기 처리량 지정 (읽기용량유닛 RCU, 쓰기용량유닛 WCU)
- 사전에 용량을 설정해야함
- 프로비저닝 된 RCU, WCU에 따라 비용 지불
- 사용량에 따라 자동으로 설정해주는 오토스케일링 옵션 설정 가능
- 프로비저닝된 용량보다 더 많은 처리 시 버스트 용량 사용됨
- 버스트 용량까지 모두 소진 시 PrivisionedThroughputExceededException 발생
  - 해당 오류 발생 시 지수 백오프를 통한 retry
온디맨드 모드
- 워크로드에 기반해 읽기/쓰기를 자동으로 스케일링 (업/다운)
- 사전에 용량 설정 X
- 사용한 만큼만 비용 지불 (프로비저닝 모드보다 훨씬 비쌈, 약 2.5배)
- 성공한 요청을 기반으로 계산 (RRU, WRU, Request Unit)
- 워크로드, 트래픽 예측이 불가능 할 때 사용
24시간 마다 모드 변경 가능
쓰기 용량 유닛 (WCU)
- 최대 1KB item에 대한 초당 1개의 쓰기
- item이 1KB보다 클 경우 더 많은 WCU 사용
- ex 1) 초당 10 item write / item size 2KB
  - 10 * (2KB / 1KB) = 20 WCUs 필요
- ex 2) 초당 6 item write / item size 4.5KB
  - 6 * (5KB / 1KB) = 30 WCUs 필요 (WCU 계산 시 소수점은 항상 올림)
- ex 3) 분당 120 item write / item size 2KB
  - 2 * (2KB / 1KB) = 4 WCUs 필요
읽기 용량 유닛 (RCU)
- DynamoDB 내부적으로는 여러 대의 서버가 존재
- 애플리케이션에는 하나의 서버에만 쓰기하지만, 내부적으로 서버2, 서버3과 같은 서버에 쓰기 복제
- 애플리케이션에서 읽기 시 서버2, 서버3에서 읽을 수도 있음
- Strongly Consistent Read
  - 쓰기 이후 읽기 시 짧은 간격이어도 최신 데이터를 읽음
  - 이를 설정하기 위해 GetItem, BatchGetItem, Query, Scan 등 API에서 ConsistentRead = true로 두어야함
  - 해당 읽기 방식은 RCU를 2번 소비하므로 기본값으로 되어있지 않음 (비싼 읽기비용, 지연시간 높음)
- Eventually Consistent Read (기본값)
  - 쓰기 후 읽기 시 오래된 데이터를 읽을 가능성이 있음 (짧은 간격일 경우 복제 전일 수 있음)
- 크기가 최대 4KB인 item마다 초당 SCR 1개 or ECR 2개
- 4KB보다 크면 더 많은 RCU 소비
- ex 1) 초당 10 SCR / item size 4KB
  - 10 * (4KB / 4KB) = 10 RCUs 필요
- ex 2) 초당 16 ECR / item size 12KB
  - (16 / 2) * (12KB / 4KB) = 24 RCUs 필요
- ex 3) 초당 10 SCR / item size 6KB
  - 10 * (8KB / 4KB) = 20 RCUs 필요 (6KB는 가장 가까운 4KB로 올림)

AWS DynamoDB - 파티션

테이블마다 파티션이 나눠져 있으며 데이터는 파티션에 저장
모든 데이터는 해싱 알고리즘을 거침
해싱 알고리즘을 통해 파티션키에 해당하는 파티션으로 분산되어 저장
프로비저닝 된 WCU, RCU는 각 파티션에 고르게 분배됨

AWS DynamoDB - 쓰로틀링

각 파티션마다 RCU, WCU 초과 시 ProvisionedThroughputExceededException 발생
사유
- 파티션이 핫키일 수 있음 (특정 파티션에 데이터가 몰림)
- 데이터 사이즈가 너무 큼 (많은 WCU, RCU 소비)
해결
- 지수 백오프를 통한 재시도 (SDK 사용시 포함된 해결법)
- 파티션 키를 최대한 분산
- RCU 이슈일 경우 DynamoDB Accelerator 사용 (DAX)

AWS DynamoDB - 기본 API

Write
- PutItem
  - 기본키가 같은 새 항목을 만들거나 완전히 교체
  - WCU 소모
- UpdateItem
  - 기존 항목 속성 편집. 없을 경우 새 항목 추가
  - 원자성 카운터(Atomic Counter)와 함께 사용 가능
- Conditional Writes
  - 조건을 충족했을 때만 쓰기/업데이트/삭제 수행
  - 항목에 동시 액세스 유용
Read
- GetItem
  - 기본키 기반 읽기 (Hash, Hash + Range)
  - Eventually Consistent Read (기본값) / Strongly Consistent Read
  - API를 통해 ProjectionExpression 지정 가능 (특정 속성만을 읽을 수 있음)
- Query
  - KeyConditionExpression에 따라 항목 반환
    - PK (= 연산, 필수)
    - SK (=, <, >, Between, Begin with 연산, 선택)
  - FilterExpression 지정 가능
    - Query 수행 이후 데이터 반환 전에 필터 추가
    - non-key 속성에 적용 가능 (Hash, Range에 적용 불가능)
  - 리스트 형태로 반환 (limit 설정 시 항목 수 제한)
  - 항목 수 제한 도달 or 데이터 용량 최대 1MB 도달 시 반환
  - 페이징 처리 가능
  - 테이블, 로컬 보조 인덱스, 글로벌 보조 인덱스 쿼리 가능
- Scan
  - 테이블 전체를 읽음
  - 전체 테이블 반환 - 각 스캔은 최대 1MB 데이터 반환
  - 계속 읽어오고자 한다면 페이징 처리
  - 전체 테이블을 읽어오므로 많은 RCU 소모
  - 정상적인 작업에 영향을 주지 않기 위해서는 limit문을 스캔에 적용 or 결과 크기를 줄이고 pause
  - RCU를 많이 사용하는 대신 최대한 빠르게 스캔 작업을 수행하려면 병렬 스캔 (Parallel Scan) 사용
  - ProjectionExpression, FilterExpression(클라이언트 측에서 변경, 비효율적)과 함께 사용 가능
Delete
- DeleteItem
  - 개별 항목 삭제 시 사용
  - 조건부 삭제 가능
- DeleteTable
  - 테이블 및 테이블 내 모든 데이터 삭제
  - Scan을 통해 각 항목에 대한 DeleteItem보다 훨씬 빠름
  - 전체 삭제를 위해서는 Scan 수행이 아닌 DeleteTable 사용 권장
Batch
- 일괄로 작업을 처리하여 지연시간 절약 API 호출 횟수 감소
- 모든 일괄 작업은 병렬로 수행되어 효율성 높임
- 일부 실패 시 실패항목만 다시 시도 가능
- BatchWriteItem
  - 한번 호출로 최대 25개 PutItem / DeleteItem 가능
  - 최대 16MB 데이터 기록 가능 / 항목마다 400KB 제한 적용
  - 업데이트 불가능 (UpdateItem 사용)
  - 항목을 write 할 수 없는 경우에는 UnprocessedItems 반환 -> 지수 백오프로 시도 or WCU 증가 가능
    - 주로 WCU 부족으로 인한 이슈
- BatchGetItem
  - 하나 이상의 테이블에서 항목 반환
  - 최대 100개 항목, 최대 16MB 반환
  - 지연시간 최소화를 위해 모든 항목을 병렬적으로 read
  - 항목을 read 할 수 없는 경우에는 UnprocessedKeys 반환 -> 지수 백오프로 시도 or WCU 증가 가능
    - 주로 RCU 부족으로 인한 이슈
PartiQL
- SQL 구문을 통해 DynamoDB에서 처리 가능
- Join 불가능

Reference

Udemy - AWS Certified Developer Associate 시험 합격을 위한 모든 것!

백준[19598] 최소 회의실 개수

빠쿤 — Thu, 6 Jun 2024 18:11:48 +0900

문제: https://www.acmicpc.net/problem/19598
분류: 그리디, 정렬, 우선순위큐
난이도: G5
소요시간: 15m
자아성찰:
- 처음에는 남은 회의 중 종료 시간이 빠른 순으로 배정된 회의실중 종료시간이 제일 빠른 회의실을 배정하면 되겠다라고 생각했다.
- 스스로 테스트케이스를 생각해보면서, 다음 같은 상황에서 답이 맞지 않을 것 같았다.
  - 현재 배정된 회의실 중 종료시간은 30, 40
  - 남은 회의는 50-60 / 30-70
  - 50-60 회의가 종료시간 30 회의실 배정
  - 30-70 회의실은 종료시간 40 회의실 배정이 불가하므로 회의실 +1
  - 30-70 회의가 30 회의실을 먼저 배정받고, 50-60 회의가 40 회의실을 배정받으면 추가로 회의실 배정 필요없음
- 시작시간이 빠른 순 / 시작시간이 같을 경우 종료시간 빠른 순으로 회의를 정렬하면 빨리 시작해야 하는 회의가 최대한 종료시간이 빠른 회의실을 먼저 배정받을 수 있겠다라고 생각했다.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.PriorityQueue;
import java.util.StringTokenizer;

public class B_19598 {

    static int N, result;
    // 회의 시작 빠른 순 PQ
    static PriorityQueue<Meeting> meet = new PriorityQueue<>();
    // 회의실 종료시간 빠른 순 PQ
    static PriorityQueue<Integer> room = new PriorityQueue<>();

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;
        N = Integer.parseInt(br.readLine());
        while (N-- > 0) {
            st = new StringTokenizer(br.readLine());
            int start = Integer.parseInt(st.nextToken());
            int end = Integer.parseInt(st.nextToken());
            meet.add(new Meeting(start, end));
        }
        while (!meet.isEmpty()) {
            Meeting cur = meet.poll();
            // 회의실 새로 배정 (첫 회의 or 비어있는 회의실 없는 경우)
            if (room.isEmpty() || cur.start < room.peek()) {
                result++;
                room.add(cur.end);
            } else {
                // 기존 회의실 사용
                room.poll();
                room.add(cur.end);
            }
        }
        System.out.println(result);
    }

    static class Meeting implements Comparable<Meeting> {
        private final int start;
        private final int end;

        public Meeting(int start, int end) {
            this.start = start;
            this.end = end;
        }

        // 시작시간 빠른 순 / 같을 경우 종료시간 빠른 순
        @Override
        public int compareTo(Meeting obj) {
            if (this.start == obj.start) {
                return obj.end - this.end;
            }
            return this.start - obj.start;
        }
    }
}