멀티탭코딩

[Redis] 1. 대용량 트래픽 처리를 위한 Redis & AWS ElastiCache 완벽 정리 (아키텍처, 캐시전략, 명령어)

defxyj — Wed, 14 Jan 2026 20:39:09 +0900

안녕하세요! 백엔드 개발의 핵심인 Redis와 AWS ElastiCache에 대해 정리한 내용을 공유합니다.
기본 개념부터 대용량 트래픽 처리를 위한 고급 캐싱 전략(PER 알고리즘)과 실무 명령어까지, 교과서처럼 참고하실 수 있도록 정리했습니다.

1. 핵심 개념: Redis와 AWS ElastiCache

1.1 Redis (Remote Dictionary Server)

Redis는 모든 데이터를 메모리(RAM)에 저장하여 처리하는 고성능 키-값(Key-Value) 데이터 저장소입니다.

특징: 싱글 스레드 기반의 이벤트 루프 방식을 사용하여 Context Switching 비용을 최소화하고, I/O 멀티플렉싱을 통해 초당 수십만 건의 요청을 처리합니다.
자료구조: String, List, Set, Sorted Set, Hash, HyperLogLog, Stream 등 다양한 타입을 지원합니다.
영속성: 메모리 기반이지만 RDB(스냅샷)와 AOF(로그) 방식을 통해 디스크에 데이터를 저장하여 유실을 방지할 수 있습니다.

1.2 AWS ElastiCache

AWS에서 제공하는 완전 관리형(Managed) 인메모리 캐시 서비스입니다.

역할: Redis 설치, 패치, 백업, 복구, 모니터링 등 운영 부담을 제거합니다.
고가용성: Multi-AZ(가용 영역) 지원 및 자동 장애 조치(Failover)를 통해 안정적인 서비스를 보장합니다.

2. 캐시 전략 (Caching Strategies)

시스템의 읽기/쓰기 빈도와 데이터 일관성 요구사항에 따라 적절한 전략을 선택해야 합니다.

2.1 읽기 전략 (Read Patterns)

Look Aside (Lazy Loading) - 표준 전략

앱이 캐시를 먼저 조회합니다.
Hit: 캐시에 데이터가 있으면 반환합니다.
Miss: 없으면 DB에서 조회하여 캐시에 적재 후 반환합니다.
장점: Redis 장애 시에도 DB로 서비스가 가능합니다.

2.2 쓰기 전략 (Write Patterns)

Write Around: DB에만 쓰고, 캐시는 읽을 때(Miss 발생 시) 갱신합니다. (데이터 불일치 가능성 있음)
Write Back (Write Behind): 캐시에 먼저 저장 후, 일정 주기마다 비동기 배치(Batch)로 DB에 저장합니다. (쓰기 속도 최상, 장애 시 데이터 유실 위험)
Write Through: 캐시와 DB에 동시에 씁니다. (데이터 정합성 최상, 쓰기 지연 발생)

3. 확장 및 공유 전략 (Scale & Share)

리플리케이션 (Replication): Master(쓰기) - Slave(읽기) 구조로 읽기 트래픽을 분산시킵니다.
샤딩 (Sharding)과 클러스터: 데이터를 여러 노드에 분산 저장하여 메모리 한계를 극복합니다. AWS ElastiCache는 노드 추가/삭제 시 데이터 재배치를 자동 관리합니다.

4. 실무 구현 기술 (Java/Spring 심화)

Spring Boot 환경에서 Redis를 효율적이고 안전하게 사용하기 위한 핵심 기법들입니다.

기술 / 개념	설명 및 장점
StringRedisTemplate	Key/Value를 String으로 직렬화. 이진 데이터보다 가독성(JSON 등)이 좋아 디버깅에 유리함.
Redisson 분산락	Pub/Sub 방식을 사용하여 스핀 락(무한 재시도)의 부하를 해결. 타임아웃 구현 용이.
트랜잭션 동기화	`TransactionSynchronizationManager`를 활용, DB 커밋 직후 캐시를 삭제하여 데이터 불일치 방지.
Lua Scripting	여러 명령어를 하나로 묶어 원자성(Atomicity) 보장. Race Condition 방지에 필수.

5. 대용량 트래픽 문제 해결 (Troubleshooting)

대용량 트래픽에서 가장 주의할 점은 Cache Stampede (Thundering Herd) 현상입니다.
(인기 Key 만료 시 수만 개의 요청이 동시에 DB로 몰려 서버가 다운되는 현상)

해결책: PER (Probabilistic Early Recomputation) 알고리즘

PER 알고리즘은 "만료 시간(TTL)이 다 될 때까지 기다리지 않고, 만료가 임박하면 확률적으로 미리 캐시를 갱신한다"는 전략입니다.

CurrentTime - ( Delta * beta * log(rand()) ) >= ExpiryTime

[동작 원리]
1. 상황: TTL 만료 5초 전, 사용자 요청 발생.
2. 확률 계산: 공식에 의해 "당첨(True)" 확률이 급격히 상승.
3. 선제적 갱신: 당첨된 1명의 사용자가 DB를 조회해 캐시를 갱신.
4. 결과: 다른 사용자들은 대기(Blocking) 없이 갱신된 캐시를 사용하여 응답 속도 저하 없음.

6. 필수 Redis 명령어 모음 (완벽 정리)

실무에서 자료구조별로 가장 빈번하게 사용하는 핵심 명령어입니다.
⚠️ 표시가 있는 명령어는 데이터가 많을 경우 서버 성능 저하(O(N))를 유발할 수 있으므로 주의해야 합니다.

1) Key 관리 (공통)

명령어	예시	설명 및 주의사항
DEL	`DEL key`	키 삭제 (동기 처리)
UNLINK	`UNLINK key`	비동기 삭제 (대용량 키 삭제 시 권장)
EXPIRE	`EXPIRE key 60`	만료 시간(TTL) 설정 (초 단위)
SCAN	`SCAN 0 MATCH user:*`	키 목록 조회 (KEYS 명령어 대체용)

2) String (문자열 - 1:1 구조)

가장 기본이 되는 구조로 캐싱, 세션, 카운터 등에 사용됩니다.

명령어	예시	용도
SET / GET	`SET user:1 "Alice"`	기본 저장 및 조회
SETNX	`SETNX lock 1`	분산락 구현 기초 (없을 때만 저장)
MGET	`MGET key1 key2`	여러 값을 한 번에 조회 (네트워크 절약)
INCR / DECR	`INCR view_count`	값 1 증가/감소 (조회수, 재고 처리)

3) Hash (해시 - 객체 저장)

하나의 키 안에 여러 필드(Field)와 값(Value)을 저장합니다. (Java의 Map과 유사)

명령어	예시	용도
HSET	`HSET user:1 name "Kim"`	특정 필드 값 저장
HGET	`HGET user:1 name`	특정 필드 값 조회
HMGET	`HMGET user:1 name age`	여러 필드 값 동시 조회
HGETALL	`HGETALL user:1`	모든 필드/값 조회 (⚠️ O(N) 주의)

4) Set (집합 - 중복 제거)

순서가 없고 중복을 허용하지 않습니다.

명령어	예시	용도
SADD	`SADD visits "192.168.0.1"`	데이터 추가 (중복 시 무시)
SISMEMBER	`SISMEMBER visits "IP"`	특정 값 존재 여부 확인 (빠름)
SMEMBERS	`SMEMBERS visits`	전체 멤버 조회 (⚠️ O(N) 주의)
SCARD	`SCARD visits`	전체 아이템 개수(Size) 확인

5) Sorted Set (ZSet - 정렬된 집합)

Set에 '점수(Score)'가 추가되어 정렬이 가능합니다. 실시간 랭킹에 사용됩니다.

명령어	예시	용도
ZADD	`ZADD rank 100 "user1"`	점수와 함께 데이터 추가
ZRANGE	`ZRANGE rank 0 9`	하위 10명 조회 (오름차순)
ZREVRANGE	`ZREVRANGE rank 0 9`	상위 10명 조회 (내림차순)
ZINCRBY	`ZINCRBY rank 10 "user1"`	점수 추가 획득

3) 운영 및 모니터링 (CLI)

# 1. Redis 접속
redis-cli

# 2. 실시간 모니터링 (모든 명령어 출력 - 운영서버 주의)
redis-cli monitor

# 3. 서버 상태 통계 (메모리, CPU 튀는지 확인)
redis-cli --stat

도움이 되셨다면 공감과 댓글 부탁드립니다!

Spring JPA 영속성 컨텍스트(Persistence Context), EntityManager,

defxyj — Mon, 16 Jun 2025 16:05:36 +0900

1. 영속성 컨텍스트 (Persistence Context)

정의 : EntityManager 가 관리하는 엔티티 객체들의 집합

DB에서 ‘조회’ 하거나 ‘저장’ 된 엔티티는 영속성 컨텍스트에 ‘영속 상태’ 로 저장됨(영속 = 지속)

하나의 트랜잭션 내에서만 유효되며, 트랜잭션이 끝나면 컨텍스트는 종료됩니다.

• 트랜잭션commit, 엔티티매니저 flush, JPQL 쿼리실행

1차 캐시

• 1. 영속성 컨텍스트는 내부적으로 Map 구조의 1차 캐시를 사용함

• 2. @Id 값을 기준으로 엔티티를 저장하며, 같은 엔티티는 DB를 다시 조회하지 않고 캐시에서 가져옴

• 3. 중복 조회 최소화, 변경 감지(Dirty Checking), 캐시 무효화

2. 엔티티 매니저(EntityManager)

정의 : ‘엔티티’ 를 ‘관리’ 해주는 역할을 하는 메모리 상에 존재하는 가상의 데이터 베이스

EntityManagerFactory 로 생성되는 EntityManager는 Thread-safety 하지 않기 때문에 쓰레드 간에 공유를 하게 되면 동시성 문제가 발생하게 된다. 하지만 Spring 에서 제공하는 EntityManager를 사용한다면 Proxy로 감싸서 EnityManager를 생성해주기 때문에 Thread-Safety를 보장 받을 수 있게 된다.

• EntityManager em = emf.createEntityManager();

• @PersistenceContext 또는 @Autowired 또는 Sprin Data JPA에서 자동 주입

3. 엔티티 매니저 팩토리 (EntityManagerFactory)

정의 : EntityManager를 만드는 공장 객체

Life-Cycle : 애플리케이션 시작시 1번 생성되어 전체 애플리케이션에서 공유

비용이 크고 무겁기 때문에 ‘싱글톤’ 으로 관리 (Spring Container가 관리)

• LocalContainerEntityManagerFactoryBean 를 통해 자동 설정

• EntityManagerFactory emf = Persistence.createEntityManagerFactory("myUnit");

• @EnableJpaRepsitories, Datasource, JpaVendorAdapter 설정 시 자동 생성

4. 엔티티 매니저 팩토리와 엔티티 매니저 전체 흐름

• 1. 스프링 컨테이너를 통해 팩토리는 앱 실행시 딱 한번 생성

• 2. 매 트랜잭션 마다 엔티티 매니저가 생성

• 3. 영속성 컨텍스트를 통해 JPA동작 수행

• 4. 트랜잭션이 끝나면 매니저는 종료되고, 컨텍스트도 사라짐

5. 쓰레드 안정성 (Thread-Safety)

정의 : 여러 쓰레드가 동시에 같은 자원에 접근하더라도 프로그램의 실행 결과가 항상 일관되고 예측 가능하게 유지 되는 상태, 멀티 쓰레드 환경에서도 오류나 추돌 없이 안전하게 작동하는 코드나 객체를 Thread-safe 하다고 말함.

웹 서버의 여러 사용자의 요청을 동시에 처리, 비동기 작업같은 백그라운드 작업이 여러 스레드에서 동시에 실햄됨으로써 이때 동일한 객체나 데이터를 ‘동시’ 에 수정하거나 읽는다면 ‘동기화(Synchronization)’ 없이 접근 시 데이터 손상, 예기치 않은 동작, Race Condition, DeadLock 등이 발생할 수 있음

6. 변경 감지(Dirty Checking)

정의 : 트랜잭션 내 ‘엔티티’ 의 변경 사항을 DB에 자동으로 반영해주는 기능

• 영속성 컨테스트 내에서 최초 엔티티 에 대한 스냅샷을 보관 후

• 트랜잭션 commit 시 ‘엔티티 매니저’ 가 flush 수행할 때, 스냅샷과 엔티티를 비교

• 변경 내용 에 대해 ‘쓰기 지연 SQL 저장소’에 update query 저장 후 트랜잭션 커밋

수정된 필드만의 update 쿼리 가 아닌, 모든 필드에 대해 update 쿼리가 나가는 이유?

• 모든 필드에 경우 DB에 데이터 전송량이 증가하는 단점이 발생

• 그럼에도 모든 필드에 대한 쿼리 수행이 발생하는 이유는 JPA 애플리케이션 로딩 시점에 update 쿼리를 미리 생성해두고, ‘재사용’ 이 가능해 성능상 이점을 가지는 장점

만약 필드의 수가 너무 많아 데이터 전송량에 대한 성능 문제를 일으키는 경우?

• @DynamicUpdate 어노테이션을 사용해 수정된 데이ㅓ만 동적으로 update 쿼리를 사용(성능 향상 기준은 30개 이상)

7. 동시성 제어 (Concurrency Control)

정의 : 여러 쓰레드 나 프로세스 가 공유 자원에 동시에 접근할 때, 데이터의 ‘일관성’ 과 ‘무결성’ 을 보장하기 위해 접근을 제어하는 기술(안전, 결과 예측하게)

원자성, 일관성, 격리성, 내구성 = (ACID)

대표적인 방식

• 동기화 Lock, Database Lock 락 기반 제어로 한 쓰레드가 자원을 사용하는 동안 다른 쓰레드는 ‘대기’

• 낙관적 락, 비관적 락

1. JPA의 @Version을 사용하여 변경시점에 충돌 검사를 통해 실패시 재시도

2. 자원의 락을 걸고, 다른 접근을 막음

• 원자 연산 (Atomic Operations)

1. 별도의 락 없이도 쓰레드 안전한 연산 제공

• ThreadLocal

1. 각 쓰레드에 독립된 변수 공간 제공

2. 공유 자체를 피함 (충돌 자체를 제거)

대표적인 동시성 문제

1. 경쟁 상태 (Race Condition)

정의 : 둘 이상의 쓰레드가 동시에 같은 자원에 접근하고, 그 순서에 따라 결과가 달라지는 문제

해결 방법

1. synchronized 로 임계 구역 보호

2. Atomic 과 같은 동시성 도구인 원자적 연산 사용

2. 교착 상태 (Deadlock)

정의 : 둘 이상의 쓰레드가 서로가 가진 자원을 기다리느라 영원히 진행되지 못하는 상태, 각 쓰레드가 자원을 점유한 채 서로 다른 자원을 요청하다가 서로의 자원을 기다리는 상황에 빠지는 것

해결 방법

1. 자원 획득순서를 쓰레드마다 순서를 부여

2. tryLock + timeout를 사용하여 대기 제한

3. 교착 상태 탐지와 회복 로직을 구현

[CloudFront, S3] CloudFront CDN 퍼블릭 정적 웹 호스팅

defxyj — Wed, 23 Apr 2025 18:57:23 +0900

정적 웹 호스팅

1. S3 버킷 생성 후 파일 업로드

[퍼블릭 액세스를 위해 설정 모두 해제]

[index 파일 업로드 후 URL 복사 버튼을 통해 url 접속]

[정상 동작 확인]

2. 버킷 속성 정적 웹 호스팅 설정

[버킷 > 속성 > 하단 > 정적 웹 호스팅] 활성화

[활성화 후 인덱스 문서, 오류 문서 파일 설정]

[저장 후 > 다시 속성 확인 > 버킷 웹사이트 엔드포인트 값 확인]

[접근]

3. CloudFront CDN 사용

[리전 : 상파울루에 있는 정적 웹 호스팅 상태] - 리전의 거리가 있는 만큼 속도가 걸림으로 CloudFront을 통해 캐시 처리해보자

[Cloud Front > 배포 > 생성]

[객체 압축 시 작은 용량으로 데이터를 엣지 로케이션에 전달]

[선택된 HTTP 방법에 따라 HTTP 메소드 허용]

[캐시 정책은 필요한 경우 생성하여 사용]

[대체 도메인 설정 후, SSL 인증서가 글로벌로 사용할 경우 버지니아 북부 리전에 있어야 해서 [인증서 요청]을 통해 새로 생성

[인증서 발급]

[다시 CloudFront에 와서 SSL 인증서 설정]

[CloudFront의 index 파일 설정]

[배포 생성 완료]

[배포 도메인 이름으로 접속 후 이미지 주소를 복사하여 AWS S3 권한이 없는 EC2에서 wget [이미지 주소]를 통해 가져올 수 있습니다.]

aws s3 접근
: aws s3 ls

이미지 get 명령어 - wget [이미지 주소]
: wget https://d3cf128109mi4m.cloudfront.net/images/two-rabbit.jpg

3. 대체 도메인을으로 접근

[Route53 > 해당 호스팅 > 레코드 생성]

[CloudFront 에서 설정한 대체 도메인 명을 레코드 명으로 사용]

[레코드 생성 완료]

[접근 완료] - 속도가 빨라진 것을 확인 가능함

[NACL] 퍼블릭 과 프라이빗 구성 아키텍처(SG & NACL)

defxyj — Wed, 23 Apr 2025 18:38:41 +0900

퍼블릭과 프라이빗 구성 아키텍처

아키텍처 예시

프라이빗의 리소스를 인터넷을 통해 업데이트 해야 할 경우

NAT GW 를 사용하여 외부 인터넷으로 갈수 있게 합니다.

SG 와 NACL

[SG]		[NACL]
인스턴스 레벨에서 운영됩니다.		서브넷 레벨에서 운영됩니다.
허용 규칙만 지원		허용 및 거부 규칙 지원
상태 저장 : 규칙에 관계없이 반환 트래픽이 자동으로 허용됨		상태 비저장 : 반환 트래픽이 규칙에 의해명시적으로 허용되어야 함
트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가함 인스턴스 시작 시 누군가 보안 그룹을 지정하거나 , 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨		트래픽 허용 여부를 결정할 때 번호가 가장낮은 규칙부터 순서대로 규칙을 처리합니다.
		연결된 서브넷의 모든 인스턴스에 자동적용됨 ( 보안 그룹 규칙이 지나치게 허용적일경우 추가 보안 계층 제공 )

[CloudWatch] AutoScaling 동적 조정과 CloudWatch 연동

defxyj — Tue, 22 Apr 2025 20:12:57 +0900

AutoScaling 동적 조정과 CloudWatch 연동

1. 동적 크기 조정 정책 생성

[인스턴스] > [Auto Scaling] > [해당 Auto Scaling 그룹 선택] > [동적 크기 조정 정책 생성]

단계 크기 조정 : 단계별로 크기를 지정하여 조정

단순 크기 조정 : 단순하게 정한 임계점에 따라 크기 조정 후 CloudWatch로 알림

2. CloudWatch 지표 생성

[CloudWatch] > [경보] > [경보 생성]

[해당 Auto Scaling Group 선택]

[지표 생성 후 임계값 정적 설정]

[조건 설정]

[기존 ASG 생성 시 지정한 SNS Confirm 알림 수락]

[CloudWatch SNS추가]

[SNS 설정 과 Auto Scaling 동적 크기 조정 정책 경보 설정 후 수행할 작업 설정하여 정책 생성 완료]

[용량 단위로 Scale Out 1개씩 추가]

3. Auto Scale In 동적 크기 조정 정책 생성

[Scale Out 과 동일하게 CPU 사용량으로 세팅 하고 임계값만 다르게 설정]

[경보가 총 2개 설정]

[최종 적으로 2개의 정책 설정]

4. SNS 알림 확인

일부러 최소 2개인 Auto Scaling 에서 한 EC2 를 Stop 시킬 경우,

ASG 에서 문제를 인지하여 문제가 된 EC2는 Draing 하고, 최소 용량 갯수를 채워 주기 위해 새로운 EC2 를 초기화 합니다.

HTTP 데몬 서버 Stop 명령어
: systemctl stop httpd

상태 확인 명령어
: systemctl status httpd

[백그라운드 CPU 사용량 증가시키기]

백그라운드에 yes라는 명령어 계속 실행
: yes > /dev/null &

CPU 사용량 확인
: top

[CloudWatch 에서 CPU 점유율 확인]

[ASG 동작 확인]

[EC2] EC2 Auto Scailing 해보기

defxyj — Tue, 22 Apr 2025 19:58:17 +0900

EC2 Auto Scailing 해보기

1. EC2 CPU 사용량 확인해보기

[CPU 사용량 명령어]

top

2. 사전에 EC2 AMI 만들기

[EC2] > [인스턴스 선택] > [작업] > [이미지 및 템플릿] > [인스턴스에서 템플릿 생성]

[AMI 생성]

[ AMI 가 사용 가능한 상태가 된 경우 해당 EC2 서버 기반으로 만든 AMI이므로 스냅샷으로 해당 EC2에 설치된 웹서버가 백업 된것을 확인할 수 있다.]

3. 생성한 AMI로 EC2 템플릿 만들기

[EC2] > [인스턴스] > [시작 템플릿]

[템플릿] > [이름 설정]

[템플릿] > [AMI 설정]

[템플릿] > [인스턴스 유형, 키 페어 설정]

[서브넷의 경우, Auto Scailing 에서 설정할 예정]

[생성 완료]

4. Auto Scaling Group 만들기

[1. 템플릿 선택]

[2. 네트워크 세팅 VPC, AZ, Subnet]

[3. 로드 밸런서 설정]

[Auto Scaling 에서 상태확인 으로 EC2 상태의 문제를 인식하고 다른 EC2 생성 및 문제가 되는 EC2 제거를 위한 해당 추가 상태 옵션 체크] - Elastic Load Balancer 상태 확인 켜기

[4. Group 크기]

[5. Amazon SNS 알림 설정]

[6. 태그 지정]

5. 생성 확인

[ASG]

[대상 그룹]

[인스턴스]

[CloudShell] CloudShell 업로드 기능으로 .tar 압축파일 업로드로 Index 파일 변경

defxyj — Tue, 22 Apr 2025 19:44:20 +0900

CloudShell 업로드 기능

1. CloudShell 에서 .tar 파일 업로드

[업로드]

[파일 확인]

2. CloudShell -> EC2 서버로 파일 복사

[복사 명령어]

scp -i [key.pem] [압축파일] [유저명]@[해당서버ip]:[해당서버업로드경로]

[복사된 파일 확인을 위해 해당 서버 접근]

ssh- -i [key.pem] [유저명]@[해당서버ip]

[tar 압축파일 해제]

sudo tar xvf aws.tar -C /var/www/html/

3. httpd 웹서버의 index파일 변경 확인

[ALB] 로드밸런서와 HTTPS 사용

defxyj — Tue, 8 Apr 2025 23:58:27 +0900

Classic Load Balancer

1. CLB 로드밸런서 생성

2. VPC와 AZ 선택

3. SG와 리스너와 인스턴스 설정

4. SSL 인증서 설정

5. 생성 후 DNS로 정상 동작 확인(CLB - Round-Robin 방식)

https는 아직 접근 불가

5. Route53에서 CLB 레코드 할당

6. 다시 접근

Network Load Balancer

1. 생성

2. 인스턴스 대상 등록

3. 대상 그룹 추가 및 리스너 추가

4. Route53에서 레코드 추가

5. 동작 확인(Hash 방식)

Application Load Balancer

1. 생성

2. 상태 체크를 위한 80, 443 포트 사용

3. HTTPS 포트 및 대상 그룹 설정

4. 레코드 설정

5. 동작 확인

alb의 default가 라운드 로빈 방식이므로 해당 alb 속성에서 트래픽 라우팅 알고리즘을 변경

[ACM] 인증서(Certificate Manager) 만들어서 HTTPS 사용해보기

defxyj — Tue, 8 Apr 2025 23:46:27 +0900

1. 생성

2. *.humbacktest.shop 와일드 카드 입력하여 서브도메인을 전부 적용하게 적용

3. cname 생성(해당 도메인에 대한 소유권)

4. 인증서에 대한 사용과 갱신 자격이 필요!

[RDS] EC2 서버에서 RDS 접근

defxyj — Tue, 8 Apr 2025 23:43:07 +0900

1. 연결한 EC2 서버에 접근하여 DB Client 설치

Client 패키지 설치 명령어

sudo dnf install -y mariadb105

2. DB 접근

mysql -h [엔드포인트] -u [DB유저] -p

DB Master 계정과 패스워드 명령어에 추가

패스워드 입력해도 연결이 안됨, vpc 설정이 필요

mysql -h [엔드포인트] -u [DB유저] -p

3. RDS 생성시 VPC 새로 생성하였으나, 인바운드, 아웃바운드 규칙은 생성하지 않아 편집 필요

4. 연결할 EC2의 프라이빗 IP를 ip a 명령어로 확인하여 인바운드 규칙에 적용

5. 다시 설정 후 재접근하면 접근 가능

DB Master 유저 대신 사용할 DB 유저 생성 SQL
유저/PW 생성 SQL
— CREATE USER 'wpuser'@'%' IDENTIFIED BY ‘test1234’;
DataBase 생성 SQL
— CREATE DATABASE IF NOT EXISTS wrdpress;
— 유저에게 모든 권한 부여 SQL
— GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'%';
— 적용
— FLUSH PRIVILEGES;
접근한 DB 나가기
— quit

6. 다른 유저로 DB 접근

[RDS] RDS 생성해보기

defxyj — Tue, 8 Apr 2025 23:37:00 +0900

1. 데이터베이스 선택

2. 마스터 계정과 암호 설정

3. 스토리지와 VPC 설정 후 생성완료

퍼블릭 액세스 (아니오) -> 프라이빗 사용

[IAM] IAM 설정하기

defxyj — Tue, 8 Apr 2025 23:32:48 +0900

IAM 설정하기

1. Admin 이라는 EC2 최소 권한을 가진 그룹 생성

EC2ReadOnlyAccess 권한 정책 만 적용

2. 사용자 생성

사용자 이름이라는 ID와 자동 생성된 패스워드로 생성

3. 콘솔 로그인 번호와 이름, 암호를 통해 로그인 실행

최초 로그인 시 패스워드 변경 화면

ec2 생성시 권한 정책 때문에 생성이 어려움

4. 권한 정책 변경

[Route53] 도메인 할당하여 EC2 웹서버 설정

defxyj — Tue, 8 Apr 2025 23:27:03 +0900

도메인 할당해보기~

1. 가비아 or 도메인 할당 사이트에서 도메인 구매

2. 구매한 도메인을 복사해서 Route53에 동일하게 생성

3. 생성된 호스팅된 대시보드 결과 확인

4. 호스팅된 레코드에 NS를 구매한 도메인 사이트에 NS 설정

NS(Name Server)의 값/트래픽 라우팅 대상(=AWS의 각 NS들)에 생성한 도메인을 각각 지정하여 적용되도록 설정해야함

+ 설정할 때 해당 NS들의 끝의 .(점=루트경로를 뜻함)을 삭제하여 설정해야함

ns-124.awsdns-15.com. -> ns-124.awsdns-15.com

ns-1709.awsdns-21.co.uk. -> ns-1709.awsdns-21.co.uk

ns-890.awsdns-47.net. -> ns-890.awsdns-47.net

ns-1250.awsdns-28.org. -> ns-1250.awsdns-28.org

AWS의 NS들을 호스팅 해주는 업체의 NS를 수정하여 해당 도메인을 사용시 해당 NS로 돌아가게 해준다.

5. 네임서버(NS) 설정 후 nslookup 명령어를 통해 확인

등록 후 nslookup 명령어를 통해 등록 유무 확인(등록 소요시간 30분)

nslookup -type=ns [도메인]

등록 되기 전

등록 되기 후(8.8.8.8 구글의 ip주소)

6. A 레코드 생성하여 도메인과 EC2 웹서버 연결

curl 확인

도메인 확인(기존에 Apach 웹서버 세팅해놓은 곳)

[VPC] IPv4 주소 범위 설정

defxyj — Tue, 8 Apr 2025 23:17:19 +0900

AWS VPC IPv4 주소 범위 설정

1. VPC 생성

10.0.0.0/16 범위의 IPv4 주소 범위 지정하여 VPC 생성

2. 서브넷 생성

3. 인터넷 게이트 웨이 생성 후 VPC와 연동

4. 라우팅 테이블과 VPC 연결된 상태 확인

5. 새로 생성한 라우팅 테ㅣ블에 인터넷 게이트가 가능하도록 라우팅 설정

5.

EC2 인스턴스 TimeZone 세팅

defxyj — Tue, 8 Apr 2025 23:12:26 +0900

EC2 인스턴스 TimeZone 세팅

1. date 명령어를 통해 확인

2. sudo timedatectl set-timezone Asia/Seoul

SSH Agent 와 SSH key로 ec2 접근

defxyj — Tue, 8 Apr 2025 23:10:17 +0900

SSH Agent 접근하는 방식

1. SSH Agent 실행(CloudShell, local)

실행 명령어

eval "$(ssh-agent -s)"

예시

2. SSH Key 등록

Key 등록 명령어

ssh-add -k my-key.pem

예시

3. ~/.ssh/config 로 Host 설정

config파일 수정 명령어

nano ~/.ssh/config

Host 내용

Host my-test // 호스트명(해당명으로 접근)
	HostName xx.xxx.xx.xxx // 해당 서버 ip
    User ec2-user // 접근할 유저
    IdentityFile ~/.ssh/my-key.pem // 사용할 키
    ForwardAgent yes

예시

4. Host 접근

위에 설정한 Host로 ssh 명령어를 통해 접근

ssh my-test

예시

SSH 명령어와 Key로 바로 접근하는 방식

1. SSH 명령어와 Key와 IP로 바로 접근

ssh -i my-key.pem ec2-user@xx.xxx.xx.xxx

예시

2. 바로 접근 시 접근 허용에 대한 오류 발생으로 변경 필요

밑에와 같이 bad permissions 에 대한 오류 발생

Key 파일에 대한 접근 허용 명령어

chmod 400 my-key.pem

예시

3. 접근 성공

AWS EC2 Access Key 생성

defxyj — Tue, 8 Apr 2025 22:56:40 +0900

AWS EC2 Access Key 생성

Private 키와 쌍을 이루는 Public 키 동시에 생성(default로 RSA 유형의 키로 생성)

1. CloudShell 키 생성 명령어 동작

aws ec2 create-key-pair --key-name my-key --query 'KeyMaterial' --output text > my-test.pem

2. CloudSheel > ls명령어 > 키 생성 확인

3. EC2 > 키 페어 > 키 생성 확인

낙관적 락(Optimistic Lock) 과 비관적 락(Pessimistic Lock)

defxyj — Wed, 13 Nov 2024 18:57:23 +0900

낙관적 락(Optimistic Lock) 과 비관적 락(Pessimistic Lock)

: 낙관적 락 과 비관적 락은 데이터 동시성 문제를 해결 하기 위한 2 가지 주요 기법입니다.

둘 다 동시에 여러 트랜잭션이 동일한 데이터에 접근 할 때 데이터의 일관성을 보장하기 위해 사용됩니다. 하지만, 사용하는 방식과 적용 시점에서 큰 차이가 있습니다.

1. 낙관적 락(Optimisitc Lock)

1. 1. 개념

데이터 충돌이 드물 것이라고 가정
트랜잭션이 데이터베이스에 변경사항을 적용하기 전에만 충돌을 확인
버전 관리(Versioning)를 통해 동시성 문제를 감지

1.2. 동작 방식

데이터를 읽어올 때 트랜잭션이 Lock이 걸지 않습니다.
데이터를 수정한 후 업데이트 시점에 버전 번호를 확인하여 충돌 여부를 판단합니다.
- 데이터베이스의 현재 버전과 트랜잭션 시작 시점의 버전이 다르면 충돌 발생.
충돌 시 OptimisticLockException 이 발생
- 개발에서는 ObjectOptimisticLockingFailureException 에서 걸림
  - 낙관적 락이 적용된 엔티티를 업데이트 할 때 버전 충돌이 발생하는 경우 던져지는 예외입니다. 즉 버전 관리 실패를 나타냅니다.

} catch (ObjectOptimisticLockingFailureException e) {

1.3. 장점

락을 사용하지 않음
- 데이터 읽기 시 락이 걸리지 않으므로 대기 시간이 발생하지 않아 성능이 좋음
- 읽기 작업이 많고 쓰기 작업이 적은 환경에서 효율적
충돌 감지
- 데이터가 충돌할 경우 트랜잭션을 재시도하도록 설계 가능

1.4. 단점

충돌 발생 시 처리 필요
- 충돌이 발생하면 애플리케이션에서 이를 처리하는 추가 로직이 필요
충돌이 잦은 경우 비효율적
- 경합이 잦은 환경에서는 반복적인 재시도로 성능이 저하될 수 있습니다.

1.5 코드

OptProduct.java

package org.springboot.lock.domain;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Version;

@Setter
@Getter
@Entity
@ToString
public class OptProduct {

    // Getter 및 Setter
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private int stock;

    @Version
    private Long version; // 낙관적 락을 위해 버전 필드 추가

    // 기본 생성자
    public OptProduct() {}

    // 생성자
    public OptProduct(String name, int stock) {
        this.name = name;
        this.stock = stock;
    }

}

OptProductRepository.java

package org.springboot.lock.repository;

import org.springboot.lock.domain.OptProduct;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.stereotype.Repository;

@Repository
public interface OptProductRepository extends JpaRepository<OptProduct, Long> {
}

OptProductService.java

package org.springboot.lock.service;

import org.springboot.lock.domain.OptProduct;
import org.springboot.lock.repository.OptProductRepository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;
import javax.persistence.OptimisticLockException;

@Service
public class OptProductService {
    private final OptProductRepository optProductRepository;

    public OptProductService(OptProductRepository optProductRepository) {
        this.optProductRepository = optProductRepository;
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW) // 항상 새로운 트랜잭션을 시작하며, 기존 트랜잭션과는 독립적으로 실행됩니다.
    public void purchaseOptProduct(Long optProductId) {
        try {
            // 상품 조회
            OptProduct optProduct = optProductRepository.findById(optProductId).orElseThrow(()->new IllegalArgumentException("상품을 찾을 수 없습니다."));
            System.out.println("상품 조회 성공 : "+optProduct);
            // 재고가 있는지 확인
            if (optProduct.getStock() > 0) {
                // 재고 감소
                optProduct.setStock(optProduct.getStock() - 1);
                // 엔티티 저장
                OptProduct savedProduct = optProductRepository.save(optProduct);
                System.out.println("재고 감소 성공 : "+savedProduct.getStock());
            } else {
                throw new IllegalStateException("재고가 부족합니다.");
            }
        } catch (OptimisticLockException e) {
            throw new RuntimeException("낙관적 락 충돌 발생! 다시 시도해주세요.",e);
        }
    }
}

2. 비관적 락(Pessimistic Lock)

2.1. 개념

데이터 충돌이 자주 발생할 것이라고 가정
트랜잭션이 데이터를 읽을 때부터 락을 걸어 다른 트랜잭션이 해당 데이터에 접근하지 못하도록 합니다.

2.2. 동작 방식

데이터를 읽는 시점에 락을 걸어 다른 트랜잭션이 동일 데이터를 읽거나 수정하지 못하도록 합니다.
락은 트랜잭션이 종료될 때까지 유지
다른 트랜잭션은 락이 해제될 때가지 대기하거나 예외가 발생

2.3. 장점

충돌 방지
- 데이터 충돌을 사전에 방지하므로 트랜잭션 재시도가 필요 없음
데이터 무결성 보장
- 충돌 상황이 자주 발생하는 경우, 데이터의 일관성을 보장

2.4. 단점

성능 저하
- 락을 걸기 때문에 다른 트랜잭션은 대기 상태가 되며, 동시성 처리 성능이 떨어짐
데드락 위험
- 잘못된 설계로 인해 데드락 이 발생
읽기 작업에도 락이 필요
- 읽기 작업이 많은 환경에서 비효율

2.5 코드

PesProduct.java

package org.springboot.lock.domain;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;

@Setter
@Getter
@Entity
@ToString
public class PesProduct {

    // Getter 및 Setter
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String name;

    private int stock;

    // 기본 생성자
    public PesProduct() {}

    // 생성자
    public PesProduct(String name, int stock) {
        this.name = name;
        this.stock = stock;
    }

}

PesProductRepository.java

package org.springboot.lock.repository;

import org.springboot.lock.domain.PesProduct;
import org.springframework.data.jpa.repository.JpaRepository;
import org.springframework.data.jpa.repository.Lock;
import org.springframework.stereotype.Repository;

import javax.persistence.LockModeType;
import java.util.Optional;

@Repository
public interface PesProductRepository extends JpaRepository<PesProduct, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE) // 비관적 락 적용 특정 엔티티에 대해 비관적 쓰기 락을 걸어 동시성 문제를 방지합니다.
    Optional<PesProduct> findById(Long id);
}

PesProductService.java

package org.springboot.lock.service;

import org.springboot.lock.domain.PesProduct;
import org.springboot.lock.repository.PesProductRepository;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

@Service
public class PesProductService {
    private final PesProductRepository pesProductRepository;

    public PesProductService(PesProductRepository pesProductRepository) {
        this.pesProductRepository = pesProductRepository;
    }

    @Transactional
    public void purchaseProduct(Long productId) {
        // 비관적 락 적용하여 상품 조회
        PesProduct product = pesProductRepository.findById(productId).orElseThrow(()->new IllegalArgumentException("상품을 찾을 수 없습니다."));
        // 재고가 있는지 확인
        if (product.getStock() > 0) {
            // 재고 감소
            product.setStock(product.getStock() - 1);
            // 엔티티 저장
            PesProduct savedProduct = pesProductRepository.save(product);
            System.out.println("재고 감소 성공 : "+savedProduct.getStock());
        } else {
            throw new IllegalStateException("재고가 부족합니다.");
        }
    }
}

3. 테스트

package org.springboot.lock.product;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;
import org.springboot.lock.domain.OptProduct;
import org.springboot.lock.domain.PesProduct;
import org.springboot.lock.repository.OptProductRepository;
import org.springboot.lock.repository.PesProductRepository;
import org.springboot.lock.service.OptProductService;
import org.springboot.lock.service.PesProductService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.orm.ObjectOptimisticLockingFailureException;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import static org.assertj.core.api.Assertions.assertThat;

@SpringBootTest
public class ProductServiceTest {

    @Autowired
    private OptProductRepository optProductRepository;

    @Autowired
    private PesProductRepository pesProductRepository;

    @Autowired
    private OptProductService optProductService;

    @Autowired
    private PesProductService pesProductService;

    private Long optProductId;
    private Long pesProductId;

    @BeforeEach
    public void setUp() {
        System.out.println("setUp Start : ");
        /** 낙관적 락 */
        OptProduct optProduct = new OptProduct("Test OptProduct", 10); // 재고 10개 생성
        optProductRepository.save(optProduct);
        optProductId = optProduct.getId();

        /** 비관적 락 */
        PesProduct pesProduct = new PesProduct("Test PesProduct", 10); // 재고 10개 생성
        pesProductRepository.save(pesProduct);
        pesProductId = pesProduct.getId();
        System.out.println("setUp End : ");
    }


    @DisplayName("낙관적 Lock 발생")
    @Test
    public void testOptimistic() throws InterruptedException {
        int numberOfThreads = 2; // 동시에 실행할 스레드 개수
        ExecutorService executorService = Executors.newFixedThreadPool(numberOfThreads);
        CountDownLatch latch = new CountDownLatch(numberOfThreads);
        for (int i = 0; i < numberOfThreads; i++) {
            executorService.submit(() -> {
                try {
//                    System.out.println("Thread " + Thread.currentThread().getName() + " 시작");
                    optProductService.purchaseOptProduct(optProductId);
//                    System.out.println("Thread " + Thread.currentThread().getName() + " 성공");
                } catch (ObjectOptimisticLockingFailureException e) {
                    System.out.println("Thread " + Thread.currentThread().getName() + " 충돌 발생: " + e.getMessage());
                } catch (Exception e) {
                    System.out.println("Thread " + Thread.currentThread().getName() + " 실패: " + e);
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await(); // 모든 스레드가 끝날 때까지 대기
        executorService.shutdown();

        // 결과 검증
        OptProduct product = optProductRepository.findById(optProductId).orElseThrow();
        System.out.println("result : "+product);
        //assertThat(product.getStock()).isEqualTo(0); // 최종 재고가 0이 되어야 함
        assertThat(product.getStock()).isLessThanOrEqualTo(9); // 재고는 9 이하로 감소해야 함

    }
    @DisplayName("비관적 Lock 발생")
    @Test
    public void testPesimistic() throws InterruptedException {
        int numberOfThreads = 10; // 동시에 실행할 스레드 개수
        ExecutorService executorService = Executors.newFixedThreadPool(numberOfThreads);
        CountDownLatch latch = new CountDownLatch(numberOfThreads);
        // test //
        for (int i = 0; i < numberOfThreads; i++) {
            executorService.submit(() -> {
                try {
                    pesProductService.purchaseProduct(pesProductId);
                } catch (Exception e) {
                    System.out.println("Exception: " + e.getMessage());
                } finally {
                    latch.countDown();
                }
            });
        }

        latch.await(); // 모든 스레드가 끝날 때까지 대기
        executorService.shutdown();

        // 결과 검증
        PesProduct product = pesProductRepository.findById(pesProductId).orElseThrow();
        System.out.println("result : "+product);
        assertThat(product.getStock()).isEqualTo(0); // 최종 재고가 0이 되어야 함
    }
}

낙관적 Lock Test

setUp Start : 
Hibernate: insert into opt_product (id, name, stock, version) values (default, ?, ?, ?)
Hibernate: insert into pes_product (id, name, stock) values (default, ?, ?)
setUp End : 
Hibernate: select optproduct0_.id as id1_0_0_, optproduct0_.name as name2_0_0_, optproduct0_.stock as stock3_0_0_, optproduct0_.version as version4_0_0_ from opt_product optproduct0_ where optproduct0_.id=?
Hibernate: select optproduct0_.id as id1_0_0_, optproduct0_.name as name2_0_0_, optproduct0_.stock as stock3_0_0_, optproduct0_.version as version4_0_0_ from opt_product optproduct0_ where optproduct0_.id=?
상품 조회 성공 : OptProduct(id=1, name=Test OptProduct, stock=10, version=0)
상품 조회 성공 : OptProduct(id=1, name=Test OptProduct, stock=10, version=0)
재고 감소 성공 : 9
재고 감소 성공 : 9
Hibernate: update opt_product set name=?, stock=?, version=? where id=? and version=?
Hibernate: update opt_product set name=?, stock=?, version=? where id=? and version=?
2024-11-13 18:55:59.069  INFO 10871 --- [pool-1-thread-2] o.h.e.j.b.internal.AbstractBatchImpl     : HHH000010: On release of batch it still contained JDBC statements
Thread pool-1-thread-2 충돌 발생: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; statement executed: update opt_product set name=?, stock=?, version=? where id=? and version=?; nested exception is org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1; statement executed: update opt_product set name=?, stock=?, version=? where id=? and version=?
Hibernate: select optproduct0_.id as id1_0_0_, optproduct0_.name as name2_0_0_, optproduct0_.stock as stock3_0_0_, optproduct0_.version as version4_0_0_ from opt_product optproduct0_ where optproduct0_.id=?
result : OptProduct(id=1, name=Test OptProduct, stock=9, version=1)

비관적 Lock Test

setUp Start : 
Hibernate: insert into opt_product (id, name, stock, version) values (default, ?, ?, ?)
Hibernate: insert into pes_product (id, name, stock) values (default, ?, ?)
setUp End : 
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
재고 감소 성공 : 9
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 8
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 7
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 6
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 5
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 4
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 3
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 2
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 1
Hibernate: update pes_product set name=?, stock=? where id=?
재고 감소 성공 : 0
Hibernate: update pes_product set name=?, stock=? where id=?
Hibernate: select pesproduct0_.id as id1_1_0_, pesproduct0_.name as name2_1_0_, pesproduct0_.stock as stock3_1_0_ from pes_product pesproduct0_ where pesproduct0_.id=? for update
result : PesProduct(id=1, name=Test PesProduct, stock=0)

Mysql dump 명령어

defxyj — Sun, 14 Jul 2024 21:26:50 +0900

Mysql dump 명령어

1. 구조

mysqldump [옵션] > 파일명.sql

2. 백업

단일 DB 백업

mysqldump -u root -p 데이터베이스이름 > 백업파일명.sql

사용자로 로그인하면 -u 및 -p 옵션 생략 하여

mysqldump 데이터베이스이름 > 백업파일명.sql

ex) mysqldump db1_schema > db1_dump.sql

여러 DB 백업

—databases 옵션을 사용하여 백업 데이터베이스 목록들을 공백으로 구분하여 사용하고 단일 덤프 파일이 생성됩니다.

mysqldump -u root -p —databases db_1 db_2 > db_1_2_dump.sql

모든 DB 백업

—all-databases 옵션 사용하여 모든 DB를 백업

mysqldump -u root -p —all-databases > all_db.sql

모든 DB를 별도 덤프 파일로 백업

mysqldump는 모든 DB를 별도 파일로 백업하는 옵션을 없지만, Bash For 루프를 통해 쉽게 백업 가능합니다.

for DB in $(mysql -e ‘show databses’ -s —skip-column-names); do

mysqldump $DB > “$DB.sql”;

done

데이터베이스 이름을 파일 이름으로 사용하여 별도의 덤프 파일을 생성

압축된 DB 백업 생성

DB 크기가 클 경우 출력을 압축하는 것이 좋습니다. gzip 유틸리티에 연결하고 리파일로 리디렉션을 하면 됩니다.

mysqldump db_name | gzip > db_name.sql.gz

타임스탬프를 사용하여 백업

mysqldump db_name > db_name-$(date +%Y%m%d).sql

3. 복원

Mysql 덤프를 복원

mysql 유틸리티를 사용하여 덤프로 복원

mysql db_name < file_nm.sql

데이터베이스가 이미 있는 경우 먼저 데이터베이스를 삭제해야합ㄴ디ㅏ.

ex) 데이터베이스 생성후 덤프

mysql -u root -p -e “create database db_name”;

mysql -u root -p db_name < db_name.sql

전체 Mysql 덤프에서 단일 DB복원

—one-database 옵션을 사용하여 여러 DB 백업 파일에서 단일 DB를 복원

mysql —one-database db_name < all_dbs.sql

4. Cron 백업

Cron을 사용하여 백업 자동화

cron job을 사용하여 자동 백업 설정

1. 사용자 홈 디렉토리에서 .my.cnf 파일 생성 후 텍스트 입력

sudo nano ~/.my.cnf

[client]

user = dbuser
password = dbpassword

2. 사용자만 액세스할 수 있도록 자격증명 파일의 사용권한 제한

chmod 600 ~/.my.cnf

3. 백업 저장할 디렉토리 생성

mkdir ~/db_backups

4. 사용자 crontab 파일오픈

crontab -e

매일 오전 3시에 DB이름 mydb의 백업을 생성하는 다음 cron작업을 추가

0 3 * * * /usr/bin/mysqldump -u dbuser mydb > /home/username/db_backups/mydb-$(date +\%Y\%m\%d).sql

사용자 이름을 실제 사용자 이름으로 바꾸는 것을 잊지 마세요.

또한 다른 cronjob을 생성하여 30일보다 오래된 백업을 삭제

find /path/to/backups -type f -name “*.sql” -mtime +30 -delete

Docker + Mysql 구성한 Database 원격 접근

defxyj — Sun, 14 Jul 2024 21:19:32 +0900

[Docker + Mysql 구성한 Database 원격 접근]

일을 다니면서 퇴근 후 인강들으면서 공부하다보니 DB를 자꾸 껐다 켰다 반복하고 드문드문 공부하다보니 깜빡하는 것들이 생겨놔서 집에 남는 맥북도 있어 도커로 별도 DB 컨테이너를 구성해서 휴대하고 다니는 맥북으로 공부할 때마다 상시 켜져 있는 DB에 원격 접근하도록 구성해봐야겠다는 생각이 들어서 하게 되었다.

1. Docker 설치

https://www.docker.com/products/docker-desktop/

Docker Desktop: The #1 Containerization Tool for Developers | Docker

Docker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.

www.docker.com

3. Docker compose 설정파일로 Docker Container 생성

docker-compose.yml 설정

별도의 docker 디렉토리를 만들고 안에 docker-compose.yml 파일을 만들어서 활용하였다.

services:
  db:
    image: mysql:8.0  // 위에 있던 version과 image를 맞춰준다.
    platform: linux/x86_64 // 리눅스 기반 도커 환경에서 실행


    restart: always // 오류 발생시 재시작 여부 or 첫 부팅시 자동 실행 여부
    ports:
      - "3306:3306" // mySQL로의 인바운드 규칙
    environment:
      MYSQL_ROOT_PASSWORD: 1234 // MySQL 접속시 사용하게될 루트 PW
      MYSQL_DATABASE: mysqldb // 생성할 DB 이름
      MYSQL_USER: humbackdb // 굳이 적지 않아도되지만 자신의 아이디
      MYSQL_PASSWORD: 1234 // 그리고 비밀번호
      TZ: Asia/Seoul //TimeZone 설정 나중에 DB에 시간 관련 데이터를 입력할때를 대비해서 미리 입력해놓으면 좋다
    volumes: // 볼륨설정 (외부나 특정 장소에 mount하는 명령어)
      - ./db/mysql/data:/var/lib/mysql /
      - ./db/mysql/config:/etc/mysql/conf.d
      - ./db/mysql/init:/docker-entrypoint-initdb.d

도커 compose 명령어 실행

docker-compose -p mysqldb up -d

[

container 확인

4. 원격 접근

포트 확인 lsof

[lsof 명령어]
sudo lsof -PiTCP -sTCP:LISTEN

특정 포트 확인하기

sudo lsof -i :3000

포트 PID로 포트 닫기

sudo kill -9 PID

포트 확인 netstat

netstat -anv|grep LISTEN

포트 열어주기

22 : ssh 
3306 : Mysql 포트

5. 이제 서버PC 포트 열어준 바탕으로 서버PC 외부주소IP로 접근

쓰레드(Thread)와 멀티쓰레드(Multi-Thread)

defxyj — Fri, 14 Jun 2024 12:32:47 +0900

1. 쓰레드와 멀티쓰레드

프로세스를 실행 중인 프로그램이라고 하면, 프로그램은 OS로 부터 실행에 필요한 메모리를 할당받아 프로세스가 됩니다.

프로세스의 메모리를 이용해서 실제로 작업을 수행하는 것이 쓰레드 입니다.

둘 이상의 쓰레드를 가진 프로세스가 멀티 쓰레드 프로세스 입니다.

2. 멀티쓰레드 장단점

장점

1. CPU 사용률 향상

2. 효율적인 메모리 사용

3. 사용자에 대한 응답성 향상

4. 작업이 분리되어 코드 간결

단점

1. 동기화와 교착 상태 문제

3. 쓰레드 구현

쓰레드를 구현하는 방법은 Thread 클래스를 상속받는 방법과 Runnable 인터페이스를 구현하는 방법이 있습니다.

public class MyThread extends Thread{
    @Override
    public void run() {
        for(int i=0; i<3; i++){
            System.out.println("MyThread : "+i+", "+getName());
        }
    }
}

public class OtherThread implements Runnable{
    @Override
    public void run() {
        for(int i=0; i<3; i++){
            System.out.println("OtherThread :"+i+", "+Thread.currentThread().getName());
        }
    }
}

public class Process1 {
    public static void main(String[] args) {
        MyThread t1 = new MyThread();

        Runnable runn = new OtherThread();
        Thread t = new Thread(runn);// 생성자 Thread(Runnable target)이 존재

        // 실행대기 상태에 있다가 자신의 차례 시 실행
        t1.start();
        t.start();
    }
}

MyThread : 0, Thread-0
MyThread : 1, Thread-0
OtherThread :0, Thread-1
OtherThread :1, Thread-1
OtherThread :2, Thread-1
MyThread : 2, Thread-0

MyThread : 0, Thread-0
MyThread : 1, Thread-0
OtherThread :0, Thread-1
MyThread : 2, Thread-0
OtherThread :1, Thread-1
OtherThread :2, Thread-1

Thread Class를 상속 받은 것은 자손 클래스의 인스턴스를 생성하여 바로 생성 => 직접 호출 사용

Runnble Interface를 통해 구현한 것은 Runnable 인스턴스를 생성하고, Thread 클래스의 생성자에 매개변수로 구현 참조하여 사용합니다. => Thread 생성자에 넘겨주어 사용

start() 와 run() 의 차이

start는 새로운 쓰레드가 작업을 실행하는데 필요한 호출 스택(call stack)을 생성한 다음에 run()을 호출해서 생성된 호출 스택에 run()이 첫 번째로 올라가게 한다.

모든 쓰레드는 독립적인 작업을 수행하기 위해 자신만의 호출 스택을 필요로 하기 때문에, 새로운 쓰레드를 생성하고 실행시킬 때마다 새로운 호출 스택이 생성되고, 스레드가 종료되면 작업에 사용된 호출 스택은 소멸한다.

1. main->start 호출

2. 새로운 쓰레드와 안에 start 생성(호출스택 생성)

3. 호출 스택에 run 호출

4. 호출 스택 2개 구성이므로 스케줄러가 순서에 의해 수행

참고

https://cano721.tistory.com/161

Github Pull Request(PR) 방법

defxyj — Fri, 14 Jun 2024 12:28:46 +0900

Pull Request 절차

1. Fork

2. clone, remote

로컬에 clone

git clone https://github.com/humback915/Design.git

원격 저장소에 추가

git remote add <원격저장소> <프로젝트 레포지토리주소>

원격 저장소 현황

git remote -v

3. branch 생성

로컬에서 작업할 branch 생성 및 이동

git switch -c sub

4. add, commit, push

git 수정 파일 추가

git add .

git commit 메세지 추가

git commit -m <“메세지”>

git 원격 저장소에 push 하여 로컬 개발 브랜치가 원격 저장소에 생성

git push <원격저장소> <브랜치명>

5. Pull Request 생성

6. Merge

7. branch 삭제 및 동기화

원격 저장소와 로컬 동기화

git pull

로컬 브랜치 삭제

git branch -d <브랜치명>

원격 브랜치 확인

git branch -r

원격 브랜치 삭제

git push origin —delete <브랜치명>

5. 옵저버 패턴(Observer Pattern)

defxyj — Fri, 14 Jun 2024 12:21:36 +0900

옵저버 패턴(Observer Pattern)

변화가 일어 났을 때, 미리 등록된 다른 클래스에 통보해주는 패턴을 구현하는 것입니다.

일대다(one-to-many) 의존성을 가지며, 분산 이벤트 핸들링 시스템을 구현하는 데 사용됩니다.

ex) event listener

옵저버 패턴 흐름

1. 일 대 다 관계로 구성

2. 관찰 대상의 상태가 변경되면 옵저버 한테 통보

3. 통보 받은 값을 바꿀 수 있고, 삭제 하는 등의 적절한 대응을 합니다.

4. 일 대 다 관계의 그룹에서 추가/삭제 될 수 있으며 그로 인하여 정보를 전달 받거나 받을 수 없게 합니다.

옵저버 패턴 특징

1. 대상 객체의 상태가 변경될 때마다 다른 객체의 동작을 트리거해야 할때

2. 앱이 한정된 시간, 특정한 케이스에만 다른 객체를 관찰해야 할 때

3. 한 객체의 상태가 변경되면 다른 객체도 변경해야 할 때

옵저버 패턴 장점

1. 일대다 관계에서 일(one)의 상태 변경을 주기적으로 조회하지 않고 자동으로 감지할 수 있습니다.

2. 일(one)의 코드를 변경하지 않고도 새 다(many) 클래스를 도입할 수 있어 개방폐쇄 원칙을 준수합니다.

3. 런타임 시점에서 연관 관계를 맺스브니다.

4. 상태를 변경하는 객체와 변경을 감지하는 객체의 관계를 느슨하게 유지할 수 있습니다.

옵저버 패턴 단점

1. 알림 순서를 제어할 수 없고, 무작위 순서로 알림을 받습니다. 가능하지만 복잡성과 결합성만 높아집니다.

2. 패턴을 자주 구성하면 구조와 동작을 알아보기 힘들어져 코드 복잡도가 증가합니다.

3. 다수의 옵저버 객체를 등록 이후 해지하지 않는다면 메모리 누수가 발생합니다.

옵저버 패턴 코드

관찰자 인터페이스

/**
 * 관찰자 인터페이스
 */
public interface IObserver {
    void update();
}

관찰자 클래스

public class Observer implements IObserver{
    @Override
    public void update() {
        System.out.println("업데이트 사항이 존재하여 이벤트 알림 발생");
    }
}

타겟 인터페이스

/**
 * 옵저버가 관찰할 대상 인터페이스
 */
public interface ITarget {
    void notifiy();
    void addObserver(IObserver o); // 옵저버 추가
    void removeObserver(IObserver o); // 옵저버 제거
}

타겟 클래스

import java.util.ArrayList;
import java.util.List;

public class Target implements ITarget{

    List<IObserver> observerList = new ArrayList<>();

    @Override
    public void notifiy() {
        for(IObserver o : observerList){
            o.update();
        }
    }

    @Override
    public void addObserver(IObserver o) {
        observerList.add(o);
        System.out.println("그룹 대상 추가 : "+o);
    }

    @Override
    public void removeObserver(IObserver o) {
        observerList.remove(o);
        System.out.println("그룹 대상 삭제 : "+o);
    }
}

메인 실행

public class NotifyMain  {
    public static void main(String[] args) {
        /** 관찰 대상 생성 */
        ITarget t = new Target();

        /** 대상 옵저버 생성 */
        IObserver ob1 = new Observer();
        IObserver ob2 = new Observer();

        /** 그룹에 옵저버 추가 */
        t.addObserver(ob1);
        t.addObserver(ob2);

        /** 그룹 내 옵저버들에게 알림 */
        t.notifiy();

        /** 그룹에 옵저버 삭제 */
        t.removeObserver(ob2);

        /** 그룹 내 속한 ob2를 제외한 옵저버들에게 알림 */
        t.notifiy();
    }
}

그룹 대상 추가 : com.pattern.design.observer.Observer@372f7a8d
그룹 대상 추가 : com.pattern.design.observer.Observer@2f92e0f4
업데이트 사항이 존재하여 이벤트 알림 발생
업데이트 사항이 존재하여 이벤트 알림 발생
그룹 대상 삭제 : com.pattern.design.observer.Observer@2f92e0f4
업데이트 사항이 존재하여 이벤트 알림 발생

참고

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%EC%98%B5%EC%A0%80%EB%B2%84Observer-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90

4. 팩토리 메소드 패턴(Factory method pattern)

defxyj — Mon, 3 Jun 2024 21:07:53 +0900

팩토리 메소드 패턴(Factory method pattern)

생성 패턴 중 하나로 객체를 생성할 때 어떤 클래스의 인스턴스를 만들지 서브 클래스에서 결정합니다.

즉, 인스턴스 생성을 서브 클래스에게 위임합니다.

부모(상위) 클래스 코드에 구체 클래스 이름을 감추기 위한 방법으로도 사용합니다.

부모 추상 클래스는 인터페이스에만 의존하고 실제로 어떤 구현 클래스를 호출할 지는 서브 클래스에서 구현합니다.

이렇게 하면 새로운 구현 클래스가 추가되어도 기존 Factory 코드의 수정없이 새로운 Factory를 추가하면 됩니다.

팩토리 메소드 패턴의 구조

팩토리 메소드 패턴 코드

Product 인터페이스

/**
 * 물건 A의 클래스
 */
public class CreateProductA implements Product{
    @Override
    public void producting() {
        System.out.println("ProductA create");
    }
}

Product 클래스

/**
 * 물건 A의 클래스
 */
public class CreateProductA implements Product{
    @Override
    public void producting() {
        System.out.println("ProductA create");
    }
}

Factory 추상 클래스

/**
 * 물건을 만드는 팩토리 추상 클래스
 */
public abstract class Factory {

    /** Instance 생성시 abstract create() 호출하여 생성 */
    /** 외부에서 객체 생성 시 해당 메소드로 호출, but 어떤 타입의 객체인지는 하위 클래스에서 정의 */
    public Product newInstance(){
        Product p = create();
        p.producting();
        return p;
    }

    /** 접근 제한을 위해 protected 사용 */
    protected abstract Product create();
}

Factory 하위 클래스

/**
 * A의 타입을 만드는 팩토리 하위 클래스
 */
public class FactoryA extends Factory{

    @Override
    protected Product create() {
        return new CreateProductA(); /** 클래스마다 만드는 물건타입이 달라짐 */
    }
}

생성

public class FactoryMain {
    public static void main(String[] args) {
        /** 물건 A만드는 팩토리 */
        Factory f = new FactoryA();
        Product p = f.newInstance(); /** newInstance()에서 create A */
        // CreateProduct 클래스에 대한 의존성 없이 상위클래스로 인스턴스 사용 가능
    }
}

팩토리 메소드 패턴 장단점

장점

1. 수정에는 닫혀있고 확장에는 열려있는 개방폐쇄의 원칙(OCP)을 잘 지킬 수 있습니다.

2. 확장할 때 기존 코드의 변경이 없어도 됩니다. ex) B팩토리 생성에 대하여 상위클래스 수정없이 하위 클래스만 정의하여 만들 수 있습니다.

단점

1. 간단한 기능을 사용할 때보다 많은 클래스를 정의해야 하기 때문에 코드량이 증가합니다.

1. 도커(Docker)의 정의 및 아키텍처, 생명주기(작성중)

defxyj — Thu, 30 May 2024 02:43:13 +0900

Docker 도커

https://docs.docker.com/get-started/overview/

컨테이너 가상화 방식 기술

애플리케이션을 개발, 제공 및 실행하기 위한 개방형 플랫폼

Docker를 사용하면 애플리케이션을 인프라에서 분리하여 소프트웨어를 신속하게 제공

코드 전달, 테스트 및 배포 지연시간을 줄임(코드 작성과 프로덕션 환경 사이)

Docker는 개발자가 애플리케이션과 서비스를 제공하는 로컬 컨테이너를 사용하여 표준화된 환경에서 작업할 수 있도록 하여 개발 수명 주기를 간소화

컨테이너는 CI/CD(지속적인 통합 및 지속적 전달) 에 적합

Docker 플랫폼

컨테이너라고 하는 격리된 환경에서 애플리케이션을 패키징하고 실행하는 기능 제공

컨테이너

실행 가능한 이미지 인스턴스, Docker API 또는 CLI를 사용하여 컨테이너를 생성, 시작, 중지 이동 또는 삭제 가능

가상화(Virtualization)

자원을 가상적으로 분할하여 여러 개의 가상 환경을 만들어 내는 기술

ex) 자원 = 메모리, 하드웨어, 컨테이너, 네트워크

가상머신

가상 머신은 하나의 호스트 OS 위에 가상 머신을 만들고, 거기에 운영체제를 설치, 사용, 즉 가상 머신마다 커널이 다르다

가상화 기술은 서로 다른 환경(로컬, 테스트, 프로덕션)을 어떻게 효율적으로 에뮬레이트할지를 지향

하이퍼바이저(Hypervisor)

가상머신을 생성하고 구동하는 소프트웨어

OS에 자원을 할당 및 조율

Host OS가 존재하기도 함

컨테이너

컨테이너 기술은 가상 머신과 다르게 따로 가상 하드웨어를 만들지 않는다. 하나의 호스트 OS 위에 컨테이너 엔진을 설치하고, 그 위에 컨테이너를 만드는 것이다.

컨테이너 기술은 애플리케이션의 실행환경을 모아서 이식성을 높이고 확장성이 좋은 환경에서 작동하는 것을 지향

가상머신과 컨테이너의 공통점

환경 격리 : 두 기술 모두 애플리케이션을 격리된 환경에서 실행하여, 다른 시스템이나 애플리케이션과의 충돌을 방지
이식성 : 소프트웨어를 하나의 환경에서 다른 환경으로 쉽게 이전 가능
리소스 활용의 최적화 : 기존의 물리적 하드웨어 자원을 보다 효율적으로 사용

가상머신과 컨테이너의 차이점

가상화 레벨
리소스 사용
부팅 시간
관리 및 유지보수

커널

컴퓨터 운영체제의 핵심이 되는 컴퓨터 프로그램

컨테이너는 리눅스 커널의 기능을 사용하여 만들어짐

chroot : 파일 시스템을 격리

namespace : 프로세스 격리

cgroup : 하드웨어 자원 격리

설치

https://docs.docker.com/desktop/install/mac-install/

Install Docker Desktop on Mac

Install Docker for Mac to get started. This guide covers system requirements, where to download, and instructions on how to install and update.

docs.docker.com

Docker 아키텍처

Docker는 클라이언트-서버 아키텍처를 사용

Docker 클라이언트는 Docker 컨테이너를 구축, 실행 및 배포하는 무거운 작업을 수행하는 Docker 데몬과 통신

Docker 클라이언트와 데몬은 동일한 시스템에서 실행

Docker 클라이언트를 원격 Docker 데몬에 연결 가능

Docker 클라이언트와 데몬은 UNIX 소켓 또는 네트워크 인터페이스를 통해 REST API를 사용하여 통신

Docker 데몬

도커 엔진의 핵심 구성요소

Docker APi 요청을 수신하고 이미지, 컨테이너, 네트워크, 볼륨과 같은 개체를 관리

컨테이너를 생성, 시작, 중지, 삭제하는 등의 작업을 실행

이미지

Docker 컨테이너를 생성하기 위한 지침이 포함된 읽기 전용 템플릿

도커 컨테이너 생명주기

1. 생성(create) + 시작(start) = 실행(run)

docker create <이미지이름>

create 명령어를 실행하면 컨테이너 ID를 반환합니다.

docker start <이미지ID>

start 명령어를 실행하면 컨테이너가 실행됩니다.

2. 중지(stop), 즉시 중지(kill)

docker stop <이미지ID>

stop 명령어의 경우 stop 요청 전 작업을 마치고 중지를 합니다.

docker kill <이미지ID>

kill 명령어의 경우 즉시 정지합니다.

3. 삭제(rm)

docker rm <이미지ID>

docker rm ‘docker ps -a -q`

컨테이너를 완전 삭제하며, 해당 컨테이너가 삭제 전 중지되어야 삭제가 가능합니다.

3. 프록시 패턴(Proxy Pattern)

defxyj — Mon, 27 May 2024 02:59:35 +0900

Proxy Pattern

프록시 패턴은 객체 간의 간접적인 접근을 가능하게 하는 구조를 제공하는 패턴입니다.

Proxy 클래스를 통해 대신 전달하는 형태로 설계되며, 객체를 바로 호출하는 것이 아닌 Proxy를 호출하는 패턴입니다.

그러므로 실제 Client는 Proxy로 부터 결과를 받습니다.

Proxy의 효과로 캐싱(Caching), 보안(Aop), 데이터 유효성, 지연 초기화, 로깅, 원격객체 등이 있습니다.

객체지향 설계원칙 중 개방폐쇄의 원칙(OCP)과 의존 역전 원칙(DIP)을 따릅니다.

Proxy Pattern 장단점

장점

보안성 향상
유연성 향상
성능 향상

단점

코드 복잡성
성능 저하

Proxy Pattern 구조

프록시와 객체는 동일한 인터페이스를 가지고 있으며 이를 통해 다른 인터페이스와 완전히 호환되도록 바꿀 수 있습니다.

인터페이스가 있기 때문에 클라이언트는 프록시(Proxy) 와 실제객체(RealSubject) 역할의 차이를 의식할 필요가 없습니다.

클라이언트는 프록시를 중간에 두고 프록시를 통해 실제 객체와 데이터를 주고 받습니다.

프록시는 흐름 제어만 할 뿐 결과값을 조작하거나 변경하면 안됩니다.

Proxy Pattern 종류

원격 프록시
가상 프록시
보호 프록시

Cache Proxy

public interface DisplayIF {
    Browser show();
}

public class Browser {
    private String text;

    public Browser(String text){
        this.text = text;
    }
}

public class Computer implements DisplayIF {

    private String text;

    public Computer(String text){
        this.text = text;
    }
    @Override
    public Browser show() {
        System.out.println("Computer display loading : "+text);
        return new Browser(text);
    }
}

public class ComputerProxy implements DisplayIF {

    private String text;
    private Browser browser;

    public ComputerProxy(String text){
        this.text = text;
    }
    @Override
    public Browser show() {
        if(browser == null){
            this.browser = new Browser(text);
            System.out.println("ComputerProxy display loading : "+text);
        }
        System.out.println("ComputerProxy display use cache : "+text);
        return browser;
    }
}

public class ProxyMain {
    public static void main(String[] args) {
        DisplayIF i = new ComputerProxy("admin");
        i.show();
        i.show();
    }
}

ComputerProxy display loading : admin
ComputerProxy display use cache : admin
ComputerProxy display use cache : admin

Aop Proxy

public class AopComputer implements DisplayIF {
    private String text;
    private Browser browser;

    /** */
    private Runnable before;
    private Runnable after;
    public AopComputer(String text, Runnable before, Runnable after){
        this.text = text;
        this.before =before;
        this.after = after;
    }
    @Override
    public Browser show() {
        before.run();
        if(browser == null){
            this.browser = new Browser(text);
            System.out.println("AopComputer browser display loading : "+text);
            try {
                Thread.sleep(2000);
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        }
        after.run();
        System.out.println("AopComputer browser cache display loading : "+text);
        return null;
    }
}

public class AopProxyMain {
    public static void main(String[] args) {
        AtomicLong start = new AtomicLong();
        AtomicLong end = new AtomicLong();
        DisplayIF i = new AopComputer("user",
                () ->{
                    System.out.println("before : ");
                    start.set(System.currentTimeMillis());
                },
                () ->{
                    long now = System.currentTimeMillis();
                    end.set(now - start.get());
                });
        /** 객체 loading */
        i.show();
        System.out.println("loading time : "+end.get());
        /** 객체를 cache로 불러옴 */
        i.show();
        System.out.println("loading time : "+end.get());
    }
}

before : 
AopComputer browser display loading : user
AopComputer browser cache display loading : user
loading time : 2006
before : 
AopComputer browser cache display loading : user
loading time : 0

참고

https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-%ED%94%84%EB%A1%9D%EC%8B%9CProxy-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90#%EC%BA%90%EC%8B%B1_%ED%94%84%EB%A1%9D%EC%8B%9C_caching_proxy

Git & Github 명령어 정리

defxyj — Tue, 21 May 2024 10:35:47 +0900

Git & Github 명령어

1. git config 확인

git config —list

2. git config 설정

git config —global user.name
- user.name 확인하는 명령어입니다.
git config —global user.name “name”
- user.name을 지정하는 명령어입니다.
git coonfig —global user.email
- user.email을 확인하는 명령어입니다.
git coonfig —global user.email “email”
- user.email을 지정하는 명령어입니다.

3. git config 삭제

git conifg —unset —global user.name
git conifg —unset —global user.email

4. git init 초기화

디렉토리를 git으로 관리 초기화 한다는 뜻
.git 파일 생성

5. git status 상태 보기

현재 폴더 git 상태 보기

6.gitignore 파일 생성

git에 필요하지 않은 파일일 경우, 보안이 필요한 파일의 경우 배제하여 관리해야합니다.

7. git add

git add로 특정파일 git 추가 및 전체 파일 git 추가
git add <파일명>
- 특정 파일명을 git에 add
git add .
- 수정한 전체 파일을 git에 add

8. git commit

git commit하여 버전 관리
- git commit -m “버전명메시지”
- git commit -am “버전명메시지” (새로 추가된 파일이 없을 경우 사용)

9. git log

git 커밋 이력 조회 명령어
git log —all —decorate —oneline —graph
- git log를 그래프 형식으로 보여줍니다. (GUI형식으로)

10. git diff

commit이나 branch 사이에 다른점 혹은 파일이나 repository와 working 디렉토리의 사이의 다른점을 보여주는 명령어

11. git rm

git rm <파일명>
- git에서 해당 파일 삭제

12. git reset

git reset —hard <로그해시값>
- reset 사용하여 해당 과거 버전으로 이동, 이후 버전은 히스토리에서 삭제
git reset —hard
- 로그해시값없이 실행 시 마지막 커밋 버전으로 이동

13. git revert

git revert —hard <로그해시값>
- revert를 사용하여 해당 버전의 코드를 삭제
git revert —no-commit <로그해시값>
- commit 되지 않은 상태로 돌아가는 법
git revert —continue
- 아직 끝나지 않은 git 상태를 계속 진행

14. git branch

git branch
- git 브랜치 현황 조회
git branch <브랜치명>
- git 브랜친 생성
git branch -d <브랜치명>
- git 브랜치 삭제
git branch -m <기존> <새로운브랜치명>
- git 브랜치 이름 변경
git branch -M main
- git 기본 브랜치 명 지정
git branch -all 또는 git branch -a
- 로컬저장소와 원격저장소의 브랜치 목록조회

15. git fetch

원격저장소의 브랜치들을 목록에 업데이트하는 명령어입니다.
git switch -t <원격저장소명>/<해당브랜치명>
- -t 옵션을 사용하여 원격 저장소의 브랜치를 로컬에 두고 연결하겠다는 명령어입니다.

16. git switch

git switch <브랜치명>
- 현재 브랜치 변경
git switch -c <브랜치명>
- 브랜치 생성과 동시에 이동
git checkout -b <브랜치명>
- 이전 버전에 switch를 checkout 명령어로 사용
git switch -t <원격저장소명>/<해당브랜치명>
- -t 옵션을 사용하여 원격 저장소의 브랜치를 로컬에 두고 연결하겠다는 명령어입니다.

17. git merge

git merge <합칠브랜치>
- 현재 브랜치와 합칠 브랜치를 명령어에 넣어 합칩니다.
git merge —abort
- git merge시 충돌 해결 시 중단 처리 명령어입니다.

18. git rebase

git rebase <해당위치브랜치명>
- 해당위치 브랜치로 현재 브랜치를 붙여줍니다.
- merge 때와는 반대로 생각하면됩니다.
- 이후 브랜치를 merge를 통해 브랜치 시점을 합쳐줍니다.
- git merge <브랜치명>
git rebase —abort
- git rebase 충돌 해결 시 중단 처리 명령어입니다.
git rebase —continue
- rebase할 commit들이 여러개 일 경우 하나씩 처리 후 git add . 한 후 다음 충돌 건을 처리하기 위한 명령어입니다.

19. git remote

git remote add <원격저장소명> <github주소>
- git remote add origin https://github.com/…/*.git
- origin = 원격 저장소명
- 로컬 git과 원격 저장소인 github 연동
git remote
- 현재 프로젝트에 연결된 원격 저장소명을 보여주는 명령어입니다.
git remote -v
- 원격 저장소의 주소를 보여주는 명령어입니다.

20. git push

git push -u <원격저장소명> <해당브랜치명>
- git push -u origin main
- git push —set-upstream origin main
- 원격저장소 브랜치에 어느 브랜치를 push(업로드)한다는 명령어입니다.
git push
- 원격 저장소로 커밋 업로드한다는 명령어입니다.
- 이미 git push -u <원격저장소명> <로컬저장소명> 으로 대상 원격 브랜치가 지정되었기에 위의 명령어로만 push 가능합니다.
git push —force
- 로컬의 내역을 강제로 push(업로드)한다는 명령어입니다.
git push <원격저장소명> —delete <원격브랜치명>
- 원격 저장소의 브랜치명 삭제하는 명령어입니다.

21. git pull

git pull
- 원격저장소에서 내려받은 수정사항이 있을 때 내려받기위한 명령어입니다.
push 시 pull 한 최신 버전과 충돌이 있을 경우
- 일단 로컬저장소의 버전을 최신버전으로 맞추어 함으로 pull 명령어가 필요합니다.
- git pull —no-rebase
  - no-rebase이므로 두 브랜치를 병합하는 merge 방식입니다.
  - 작업 후 push 필요
- git pull —rebase
  - 로컬의 브랜치를 원격저장소의 브랜치에 붙이는 rebase 방식입니다.
  - 작업 후 push 필요

22. git clone

git clone <github주소>
- github 레포지토리에 있는 파일을 현재 디렉토리로 복사한다는 명령어입니다.

23. git checkout

git checkout -- <파일이름.확장자>
- 워크트리에서 파일을 수정했는데 이를 되돌려야 하는 경우가 있습니다.

24. git restore

git restore .
- 현재 디렉토리에 있는 모든 변경 사항을 버리고 원상태로 돌아가려면 다음과 같이 입력하면 됩니다.

ON DELETE CASCADE 옵션

defxyj — Mon, 22 Apr 2024 13:06:17 +0900

ON DELETE CASCADE 옵션

관계형 데이터 베이스에서 외래 키 (Foreign Key) 제약 조건을 정의 할 때 사용되는 옵션 중 하나 입니다.

이 옵션을 설정 하면 부모 테이블에서 행이 삭제 될 때 해당 행을 참조하는 자식 테이블의 행도 자동으로 삭제됩니다.

간단히 말해, 만약 부모 테이블의 한 행이 삭제되면, 이 행을 참조하는 자식 테이블의 모든 관련 행도 함께 삭제됩니다.

이를 통해 데이터 무결성을 유지하고 데이터베이스의 일관성을 유지 할 수 있습니다.

예를 들어, 다음과 같은 두 개의 테이블이 있다고 가정해보겠습니다.

CREATE TABLE 부모 (
    부모_ID NUMBER PRIMARY KEY,
    부모_이름 VARCHAR2(50)
);

CREATE TABLE 자식 (
    자식_ID NUMBER PRIMARY KEY,
    부모_ID NUMBER,
    자식_이름 VARCHAR2(50),
    CONSTRAINT fk_부모 FOREIGN KEY (부모_ID) REFERENCES 부모(부모_ID) ON DELETE CASCADE
);

여기서 자식 테이블의 ‘부모_ID’ 열은 ‘부모’ 테이블의 ‘부모_ID’ 열을 참조하는 외래키 입니다.

ON DELETE CASCADE 옵션이 설정되어 있으므로 만약 부모 테이블의 어떤 행이 삭제되면 해당 행을 참조하는 자식 테이블의 모든 행도 자동으로 삭제됩니다.

Overloading) 오버로딩 시 생성자 에러(Constructor Class is already defined in Class)

defxyj — Mon, 22 Apr 2024 11:06:04 +0900

1. 오버로딩 시 생성자 에러(Constructor Class is already defined in Class)

'Child(String)' is already defined in 'com.java.javacode.overloding.Child'

‘Class(Type)’ is already defined in ‘package.class’

생성자를 오버로딩(Overloading) 시 매개변수를 받는 자료형이 종류와 갯수가 동일할 경우 에러가 발생합니다.

이유는, 해당 type을 가진 생성자가 이미 선언되었기 때문입니다.

생성자가 다르게 보일지라도 컴퓨터의 입장에서는 클래스 객체 생성 시 어떤 생성자를 가지고 생성해야하는지 판단하지 못하기 때문입니다.

Parent

public class Parent {

    public void print(){}
}

Child

public class Child extends Parent{

    private String c_id;
    private String c_name;

    public Child() {
    }
    public Child(String id) {
        this.c_id = id;
    }
    public Child(String name) {
        this.c_name = name;
    }
    public Child(String id, String name) {
        this.c_id = id;
        this.c_name = name;
    }
}

Java의 Excepton클래스 종류 및 구조

defxyj — Wed, 17 Apr 2024 22:34:28 +0900

1. Throwable 클래스

Java의 모든 예외는 java.lang.Throwable 클래스를 상속합니다.
Throwable은 예외처리를 하기 위한 최상위 클래스입니다.
직접 사용되지 않고 상속받은 자식 클래스들이 예외처리에 사용됩니다.

2. RuntimeException과 IOException의 차이

: 예외 상황을 처리하는데 강제성을 가지고 있는가 없는가 하는 것

RumtimeException의 경우

: 프로그램 실행 도중 발생하는 예외로 프로그래머의 잘못이 발생했다는 것

Ex) IndexOutOfBoundsException, NullPointerException, Type...

예외 처리하는데 강제성을 가지고 있지 않다.

IOException의 경우

: 런타임 예외는 언제 에러가 발생하는지 알 수 없기 때문ㅇ네 처리를 하지 않아도 되지만,

IOException은 예외가 발생할 시점과 종류를 알 수 있기 때문에 반드시 처리해야 한다.(강제성)

상위 클래스

import java.io.IOException;

public class ObjectA {

    public void print(){
        System.out.println("ObjectA print()");
    };
    public void error1(){
        System.out.println("ObjectA error1()");
    }
    public void printIO() throws IOException{
        System.out.println("ObjectA printIO()");
    }
    public void error2() throws IOException{
        System.out.println("ObjectA error2()");
    }
    public void printRun() throws RuntimeException{
        System.out.println("ObjectA printRun()");
    }
    public void error3() throws RuntimeException{
        System.out.println("ObjectA error3()");
    }
    public void error4() throws IOException{
        System.out.println("ObjectA error4()");
    }
}

하위 클래스

import java.io.IOException;

public class ObjectB extends ObjectA{

    /**
     * RuntimeException과 IOException의 차이
     * 예외 상황을 처리하는데 강제성을 가지고 있는가 없는가 하는 것
     *
     * RumtimeException의 경우
     * 프로그램 실행 도중 발생하는 예외로 프로그래머의 잘못이 발생했다는 것
     * IndexOutOfBoundsException, NullPointerException, Type...
     * 예외 처리하는데 강제성을 가지고 있지 않다.
     *
     * IOException의 경우
     * 런타임 예외는 언제 에러가 발생하는지 알 수 없기 때문ㅇ네 처리를 하지 않아도 되지만,
     * IOException은 예외가 발생할 시점과 종류를 알 수 있기 때문에 반드시 처리해야 한다.(강제성)
     */

    /**
     * 1. 상위클래스의 메소드에 throws가 없을 경우
     * IOException은 throws 줄에서 에러가 발생
     * RuntimeException은 정상동작
     * @throws RuntimeException
     */

    @Override
    public void print() throws RuntimeException{
        super.print();
        System.out.println("ObjectB print()");
    }
    @Override
    public void error1() throws IOException{ // 여기서 throws IOException 시 상위클래스에 정의되지 않아 에러
        super.error1();
        System.out.println("ObjectB error1()");
    }

    /**
     * 2. 상위클래스의 메소드에 IOException이 선언되어 있을 경우
     * IOException은 정상동작
     * RuntimeException의 경우 상위 클래스의 메소드의 정의가 달라서 super호출 시 에러
     * @throws IOException
     */
    @Override
    public void printIO() throws IOException {
        super.printIO();
        System.out.println("ObjectB printIO()");
    }
    @Override
    public void error2() throws RuntimeException {
        super.error2(); // throws RuntimeException시 상위클래스에 IO가 선언되어 여기서 에러
        System.out.println("ObjectB printIO()");
    }

    /**
     * 3. 상위 클래스의 메소드에 RuntimeException이 선언되어 있을 경우
     * RuntimeException은 정상동작
     * IOException은 throws에서 에러 발생
     * @throws RuntimeException
     */
    @Override
    public void printRun() throws RuntimeException {
        super.printRun();
        System.out.println("ObjectB printRun()");
    }
    @Override
    public void error3() throws IOException {
        super.printRun();
        System.out.println("ObjectB error3()");
    }

    /**
     * 4. 상위 클래스의 메소드에 IOException이 선언되어 있을 경우
     * RumtimeException이 정상동작
     * @throws RuntimeException
     */
    @Override
    public void error4() throws RuntimeException {
        super.printRun();
        System.out.println("ObjectB error4()");
    }
}

인덱스(INDEX) 정의와 인덱스 튜닝 기초

defxyj — Mon, 1 Apr 2024 04:55:44 +0900

1. 인덱스

추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조입니다.

데이터베이스에서 테이블의 모든 데이터를 검색하면 시간이 오래 걸리기 때문에 데이터와 데이터의 위치를 포함한 자료구조를 생성하여 빠르게 조회할 수 있도록 돕고 있습니다.

* 만약 index를 사용하지 않은 컬럼을 조회해야 하는 상황이라면 전체를 탐색하는 Full Scan을 수행해야 합니다.

Full Scan은 전체를 비교하여 탐색하기 때문에 처리속도가 떨어집니다.

1-1. 인덱스(index)의 장점

1. 테이블을 조회하는 속도와 그에 따른 성능을 향상시킬 수 있습니다.

2. 전반적인 시스템의 부하를 줄일 수 있습니다.

1-2. 인덱스(index)의 단점

1. 인덱스를 관리하기 위해 DB의 약 10%에 해당하는 저장공간이 필요합니다.

2. 인덱스를 관리하기 위해 추가 작업이 필요합니다.

3. 인덱스를 잘못 사용할 경우 오히려 성능이 저하되는 역효과가 발생할 수 있습니다.

1-3. 인덱스(index)를 사용하는 경우

1. 대량의 데이터 검색

2. 정렬된 결과 출력

3. 조인 연산 수행

4. 유니크 값 검색

5. 검색 빈도가 높은 필드

* 사용되지 않는 인덱스는 제거해주어 인덱스 관리를 해줍니다.

2. 인덱스(index) 자료구조

인덱스를 구현하기 위해서는 다양한 자료구조를 사용할 수 있는데, 가장 대표적인 해시 테이블과 B+Tree가 있습니다.

2-1. 해시 테이블(Hash Table)

해시테이블은 key와 value 로 데이터를 저장하는 자료구조 중 하나로 빠른 데이터 검색이 필요할 때 유용합니다. 해시 테이블은 key값을 이용해 고유한 index를 생성하여 그 index에 저장된 값을 찾아오는 구조입니다.

해시 테이블 기반의 DB 인덱스는 컬럼의 값, 데이터의 위치를 key와 value로 사용하여 컬럼의 값으로 생성된 해시를 통해 인덱스를 구현합니다.

해시 테이블의 시간복잡도는 O(1)이며 매우 빠른 검색을 지원합니다.

하지만 DB 인덱스에서 해시 테이블이 사용되는 경우는 제한적인데, 그 이유는 해시가 등호(=) 연산에만 특화되었기 때문입니다.

해시 함수는 값이 1이라도 달라지면 완전히 다른 해시 값을 생서하는데, 이러한 특성에 의해 부등호(>,<) 연산이 자주 사용되는 데이터베이스 검색을 위해서는 해시 테이블이 적합하지 않습니다.

이러한 이유로 데이터베이스의 인덱스에서는 B+Tree가 일반적으로 사용됩니다.

2-2.B+Tree

자식 노드가 2개 이상인 B-Tree를 개선시킨 자료구조

기존의 B-Tree는 어느 한 데이터의 검색은 효율적이나 모든 데이터를 한 번 순회하는데에는 트리의 모든 노드를 방문해야 하므로 비효율적이며 이를 개선한 것이 B+Tree입니다.

B+Tree는 오직 leaf node에만 데이터를 저장하고 나머지 노드에는 자식 포인터만 저장합니다.

leaf node끼리는 Linkedlist로 연결되어있습니다.

장점

1. leaf node에만 데이터 저장하므로 메모리 확보

2. Full Scan의 경우 leaf node에만 데이터 저장되어있고, 이들이 Linkedlist로 연결되어 있어 선형시간이 소모됩니다.

단점

1. 반드시 특정 key에 접근하기 위해서 leaf node까지 가야한다.

* 인덱스에서는 왜 B-Tree가 아닌, B+Tree를 주로 이용하는 이유

인덱스 컬럼은 부등호(>, <)를 이용한 순차 검색 연산이 자주 발생합니다.

B+Tree의 Linkedlist를 이용하면 효율적인 순차 검색이 가능해집니다.

3. 인덱스 스캔 방식

3-1. Index Range Scan

그림처럼 인덱스 루트 블록에서 리프 블록까지 수직적으로 탐색한 후에 리프블록을 필요한 범위만 스캔하는 방식입니다.

Index Range Scan이 나타난다고 해서 항상 빠른 속도를 보장하는 것은 아니다.

범위와 테이블 액세스 횟수를 얼마만큼 줄일 수 있느냐가 중요합니다.

Index Range Scan이 가능하게 하려면 인덱스를 구성하는 선두 컬럼이 조건절에 사용되야 합니다.

Index Range Scan 과정을 거쳐 생성된 결과 집합은 인덱스 컬럼 순으로 정렬된 상태가 되기 때문에 이런 특징을 잘 이용하면 sort order by 연산을 생략하거나 min/max 값을 빠르게 추출할 수 있습니다.

3-2. Index Full Scan

수직적 탐색없이 인덱스 리프 블록을 처음부터 끝까지 수평적으로 탐색하는 방식으로서, 대개는 데이터 검색을 위한 최적의 인덱스가 없을 때 차선으로 선택됩니다.

개념적으로 설명하기 위한 것이고 실제로는 수직적 탐색이 먼저 일어난다. 루트 블록과 브랜치 블록을 거치지 않고는 가장 왼쪽에 위치한 첫 번째 리프 블록으로 찾아갈 방법이 없기 때문입니다.

3-3. Index Unique Scan

수직적 탐색만으로 데이터를 찾는 스캔 방식으로서 Unique 인덱스를 ‘=‘ 조건으로 탐색하는 경우에 작동한다.

3-4. Index Skip Scan

인덱스 선두 컬럼이 조건절로 사용되지 않으면 옵티마이저는 기본적으로 Table Full Scan을 선택한다. 또는 Table Full Scan 보다 I/O를 줄일 수 있거나 정렬된 결과를 쉽게 얻을 수 있다면 Index Full Scan 방식을 사용한다고 했다.

오라클은 인덱스 선두 컬럼이 조건절에 빠졌어도 인덱스를 활용하는 새로운 스캔방식을 Index Skip Scan라고 합니다.

내부 수행원리는 루트 또는 브랜치 블록에서 읽은 컬럼 값 정보를 이용해 조건에 부합하는 레코드를 포함할 ‘가능성이 있는’ 하위 블록(브랜치 또는 리프 블록)만 골라서 액세스하는 방식이라고 할 수 있습니다.

이 스캔 방식은 조건절에 빠진 인덱스 선두 컬럼의 Distinct Value 개수가 적고 후행 컬럼의 Distinct Value 개수가 많을 때 유용합니다.

3-5. Index Fast Full Scan

Index Full Scan 보다 빠른 스캔 방식입니다. 빠른 이유는 인덱스 트리 구조를 무시하고 인덱스 세그먼트 전체를 Multiblock Read 방식으로 스캔하는 방식 때문입니다.

3-6. Index Range Scan Descending

인덱스를 뒤에서부터 앞쪽으로 스캔하기 때문에 내림차순으로 정렬된 결과 집합을 얻는다는 점에서 Index Range Scan와 다르다.

4. 인덱스 튜닝 기초

인덱스를 정상적으로 사용하려면 범위 스캔 시작지점을 찾기 위해 루트 블록부터 리프 블록까지 수직적 탐색과정을 거쳐야 합니다.

만약 인덱스 선두 컬럼이 조건절에 사용되지 않으면 범위 스캔을 위한 시작점을 찾을 수 없어 옵티마이저는 인덱스 전체를 스캔하거나 테이블 전체를 스캔하는 방식을 선택합니다.

인덱스 선두 컬럼이 조건절에 사용되더라도 범위 스캔이 불가능하거나 인덱스를 사용 못하는 경우에 대해 알아봅시다.

4-1. 범위 스캔이 불가능하거나 인덱스 사용이 불가능한 경우

가. 인덱스 선두컬럼을 조건절에 가공한 경우

Ex) where substr(업체명, 1, 2) = ‘대한’

나. 부정형 비교를 사용한 경우

Ex) where 직업 <> ‘학생’

다. is not null 조건의 부정형 비교일 경우

Ex) where 부서코드 is not null

—> 위 세 경우 모두 정상적인 인덱스 범위 스캔이 불가능해지고 Index Full Scan이 가능하다.

4-2. 인덱스 컬럼 가공 튜닝 방안(튜닝 전 -> 튜닝 후)

문자열 자르기에 경우 where 문에 쿼리를 가공하지 말고 like 사용

where substr(업체명, 1, 2) = ‘대한’ -> where 업체명 like ‘대한%’

계산식의 경우 where 문에 하지 말고 우측에서 계산대입

where 월급여 * 12 = 36000000 -> where 월급여 = 36000000/12

date 형식의 범위값 지정은 and 와 >=,< 범위로 사용하고 data 형식을 사용

where to_char(일시, ‘yyyymmdd’) = :dt -> where 일시 >= to_date(:dt, ‘yyyymmdd’) and 일시 < to_date(:dt, ‘yyyymmdd’)+1

두 컬럼을 합쳐서 where 조건에 넣지 말고 값에서 함수 적용

where 연령 || 직업 = ’30공무원’ -> where 연령 = 30 and 직업 = ‘공무원’

4-3. 묵시적 형변환

인덱스 컬럼을 사용자가 명시적으로 가공하지 않더라도 조건절에서 비교되는 두 값의 데이터 타입이 다르면 내부적으로 형변환이 일어납니다.

number형 컬럼에 대하여 검색조건으로 숫자형이 맞지만, 실수로 문자형으로 코딩하는 경우가 있습니다.

Ex) select * from emp where deptno = ’20’

—> 문자형과 숫자형이 만나면 옵티마이저가 문자형을 숫자형으로 변환해주는 DBMS가 제공하는 기능입니다.

5. 테이블 액세스 최소화

5-1. 인덱스 ROWID에 의한 테이블 랜덤 액세스

쿼리에서 참조되는 컬럼이 인덱스에 모두 포함되는 경우가 아니라면, 테이블 랜덤 액세스가 발생한다.

(Table Access By Index ROWID)

Ex) Execution Plan 중 TABLE ACCESS *BY INDEX ROWID) OF ‘컬럼명’

인덱스 ROWID에 의한 테이블 액세스 구조

인덱스에 저장돼 있는 rowid는 흔히 ‘물리적 주소정보’라고 일컬어진다. 오브젝트 번호, 데이터 파일 번호, 블록 번호 같은 물리적 요소들로 구성돼 있기 때문입니다.

물리적 위치정보로 구성되어 있지만, 인덱스에서 테이블 레코드로 직접 연결되는 구조가 아니기 때문에 ‘논리적 주소정보’라고 표현하기도 합니다.

* rowid는 메모리 상의 위치정보가 아니라 디스크 상의 위치정보로 데이터 블록을 읽을 때는 항상 버퍼 캐시를 경유하므로 메모리 상에서 버퍼 블록을 찾기 위해 해시 구조와 알고리즘을 사용합니다.

자세하게 설명하자면 아래와 같은 메커니즘을 말합니다.

인덱스 ROWID를 이용해 테이블 랜덤 액세스로 블록을 읽는 메커니즘

1. 인덱스 ROWID -> DBA(디스크 블록 위치 정보)를 해시함수로 해시 값 확인

2. 해시 값 -> 해시 버킷 검색

3. 버킷에 연결된 해시 체인 스캔하면 블록헤더를 검색

4-1. 블록 헤더에 저장된 포인터로 버퍼 블록 읽음

4-2. 블록 헤더를 못 찾을 경우 버퍼 공간에 적재하기 위해 공간 확보 및 직접 디스크 블록을 읽고 버퍼에 적재

이를 통해 항상 버퍼 캐시를 참색하는 것이 고비용 구조이고 접근 과정 중 내부 매커니즘도 존재하기에 그런 과정과 경합이 발생하여 블록 하나 읽는데 생각보다 많은 비용이 치러지고 성능 저하가 발생하여 해결하기 위해 테이블 랜덤 액세스를 줄여야 합니다.

5-2. 클러스터링 팩터

Clustering Factor라는 개념을 사용해 인덱스 ROWID에 의한 테이블 액세스 비용을 평가합니다.

클러스터링 팩터는 ‘군집성 계수(데이터가 모여 있는 정도)’로 번역되며, 특정 컬럼을 기준으로 같은 값을 갖는 데이터가 서로 모여 있는 정도를 의미합니다.

데이터가 물리적으로 근접해 있다면 흩어져 있을 때보다 데이터를 찾는 속도가 빨라집니다.

물리적으로 근접해 있으면 ROWID로 테이블 액세스 할 때 테이블 블록에 대한 포인터를 가지고 있어 다음 데이터를 액세스 할 때 이전 스캔한 ROWID를 가지고 있으므로 포인터를 다시 찾지 않고 재사용하기 때문에 블록 I/O가 적게 발생하여 속도가 빠릅니다.

인덱스 손익분기점

인덱스 ROWID에 의한 테이블 액세스는 생각보다 고비용 구조입니다. 따라서 일정량을 넘는 순간 테이블 전체를 스캔할 때보다 오히려 더 느려집니다.

Index Range Scan에 의한 테이블 액세스가 Table Full Scan보다 느려지는 지점을 흔히 ‘손익분기점’ 이라고 부릅니다.

예를 들어 손익 분기점이 10% 라는 의미는 1000개 중 100개 레코드 이상을 읽을 때는 인덱스를 이용하는 것보다 테이블 전체를 스캔하는 것이 더 빠르다는 뜻입니다.

손익 분기점은 클러스터링 팩터에 따라 달라지며, 나쁘면 5%미만, 좋으면 90% 수준까지 올라갑니다.

정리하자면 클러스터링 팩터가 좋을 수록 데이터가 잘 모여있어 인덱스 스캔보다 테이블 전체를 스캔하는 것이 더 빠르다는 뜻입니다.

5-3. 인덱스 스캔이 테이블 전체 스캔보다 느리게 만드는 요인

1. 인덱스는 랜덤 액세스, 풀 스캔은 시퀀셜 액세스 방식

2. 디스크 I/O 시 인덱스는 Single Block Read 방식, 풀스캔은 Multi Block Read 방식

간단히 설명하자면

시퀀셜 액세스는 레코드 간 논리적 또는 물리적인 순서를 따라 차례대로 읽어 나가는 방식

랜덤 액세스는 레코드 간 논리적, 물리적 순서를 따르지 않고 한 건을 읽기 위해 한 블록 씩 접근하는 방식

Single Block Read는 한번의 I/O 하나의 데이터 블록만 읽어 메모리에 적재하는 것입니다.

Multi Block Read는 I/O 때 필요한 시점에 인접한 블록들을 같이 읽어 메모리에 적재하는 것입니다.

6. 테이블 액세스 최소화 튜닝

6-1. 기존 인덱스 컬럼 추가

해당하는 인덱스가 없어서 새로 인덱스를 만들어 여러 개의 인덱스를 관리하는 것보다 기존 인덱스에 컬럼을 추가하면 테이블 랜덤 액세스를 줄일 수 있습니다.

Ex) select /*+ index(emp emp_x01) */ ename, job, sal from emp where deptno = 30 and sal >= 2000;

인덱스 컬럼 추가 전 컬럼 : emp_x01(deptno, job)

인덱스 컬럼 추가 후 컬럼 : emp_x01(deptno, job, sal)

6-2. Covered Index

필요한 모든 컬럼에 인덱스를 포함시키는 방법으로 인덱스만 읽어 처리하는 방식입니다.

6-3. 인덱스 클러스터 테이블

클러스터링 팩터 좋은 경우 참고

Ex)

— 인덱스 클러스터 생성

create cluster c_dept ( deptno number(2) ) index;

— 클러스터 인덱스 생성

create index c_dept_idx on cluster c_dept;

— 클러스터 테이블 생성

create table dept( deptno number(2) not null, … ) cluster c_dept( deptno );

6-4. 해시 클러스터 테이블

해시 함수에서 반환된 값이 같은 데이터를 물리적으로 함께 저장하는 구조입니다.

클러스터 키로 데이터를 검색하거나 저장할 위치를 찾을 때 해시 함수를 사용하는데, 해시 함수가 인덱스 역할을 대신하는 것이며, 해싱 알고리즘을 이용해 클러스터 키 값을 데이터 블록 주소로 변환 해줍니다.

대신 항상 ‘=‘ 조건으로만 검색되는 컬럼을 해시 키로 선정해야 합니다.

Ex)

— 해시 클러스터 생성

create cluster c_dept ( deptno number(2) ) hashkeys 4;

— 클러스터 테이블 생성

create table dept ( deptno number(2) not null, … ) cluster c_dept( deptno );

6-5. 배치 I/O(=부분 범위 처리)

대량의 데이터를 조회하면, 디스크 I/O 발생량도 함께 증가하므로 성능히 좋지 않다.

테이블 블록에 대한 디스크 I/O Call을 미뤘다가 읽을 블록이 일정량 쌓이면 한꺼번에 처리하는 방법입니다.

대신 배치 I/O 기능은 인덱스를 이용해서 출력하는 데이터 정렬 순서가 매번 다를 수 있다.

Ex) 힌트 명시 와 실행 계획

select /*+ batch_table_access_by_rowid(e) */ * from emp e where deptno = 20 order by job, empno;

실행계획에는 table access by index rowid batched 라고 출력됩니다.

7. 인덱스 스캔 효율화

앞서 랜덤 액세스 발생량을 최소화하는 방법에 대해 설명하였고, 시퀀셜 액세스 방식의 비효율을 해소하는 방법에 대해 설명해보자

7-1. 인덱스 선행 컬럼이 범위 조건일 때의 비효율(=)

인덱스 구성 컬럼이 조건절에서 모두 등치 ‘=‘ 조건으로 비교되거나 일부가 등치 ‘=‘ 조건이거나 조건절에 생략되는 것이 후행 컬럼이면 비효율이 없습니다.

Ex)

인덱스 컬럼 [컬럼1+컬럼2+컬럼3+범위1]

where 컬럼1 = a ;

where 컬럼1 = a and 컬럼2 = b ;

where 컬럼1 = a and 컬럼2 = b and 컬럼3 = c and 범위1 between d and f ;

반면 인덱스 선행 컬럼이 조건절에 누락되거나 between, 부등호(><), like 같은 범위 검색 조건이 사용되면 인덱스를 스캔하는 방식에 비효율이 발생하고 조건을 만족하지 않는 레코드까지 스캔하고 버려야 하는 경우가 생깁니다.

Ex)

인덱스 컬럼 [범위1+컬럼1+컬럼2+컬럼3]

where 컬럼1 = a ;

where 컬럼1 = a and 컬럼2 = b ;

where 컬럼1 = a and 컬럼2 = b and 컬럼3 = c and 범위1 between d and f ;

7-2. 범위 조건을 In-List로 전환(BETWEEN -> IN)

7-1의 경우처럼 인덱스 순을 변경하면 좋지만, 운영중인 시스템에서 인덱스 구성을 바꾸기가 어려운 경우가 있습니다.

이럴 때, 범위 조건을 다음과 같이 IN-List 로 바꾸어주면 효과를 얻을 수 있습니다.

인덱스에서 수직적 탐색이 발생하여 필요 없는 레코드를 스캔하지 않게 된다.

Ex)

where 범위1 in (‘d’, ’f’) and 컬럼1 = a and 컬럼2 = b….

실행계획에는 inlist iterator 라고 명시됩니다.

7-3. 범위 조건을 2개 이상 사용할 때의 비효율

like와 같은 범위 검색 조건이 2개 이상 사용하면 필터 역할을 하는 like는 대량의 데이터를 스캔할 때에는 비효율을 보여줍니다.

여러 like를 사용할 경우 나누어 만들어 주거나 UNION ALL을 이용하여 사용하는 방법이 있습니다.

7-4. 선두 컬럼에 OR 조건의 경우 인덱스를 타지 않는다.

7-5. LIKE 보단 비교적 BETWEEN 사용

8. 인덱스 설계

인덱스 많으면 DML 성능 저하, DB 사이즈 증가, DB 관리 및 운영 비용 증가가 발생합니다.

8-1. 인덱스 설계 기준

1. 조건절에 항상 사용 및 자주 사용하는 컬럼 선정

2. ‘=‘ 조건을 선행 컬럼에 위치

3. 수행 빈도 고려

4. 업무상 중요도 고려

5. 좋은 클러스터링 팩터

6. 데이터 량 고려

7. 저장공간 고려

8. 필요없는 인덱스 제거

프로시저(Procedure)란

defxyj — Sat, 30 Mar 2024 10:51:01 +0900

프로시저(Procedure)란

데이터 베이스에 대한 일련의 작업을 정리한 절차를 RDBMS에 저장한 것으로 영구저장 모듈(Persistent Storage Module)이라고 합니다.

보통 저장 프로시저(Stored Procedure)를 프로시저라고 부르며, 일련의 쿼리를 마치 하나의 함수처럼 실행하기 위한 쿼리의 집합입니다.

즉, 특정 작업을 위한 쿼리들의 블록입니다.

장점

1. 하나의 요청으로 여러 SQL문을 실행시킬 수 있습니다.

2. 네트워크 소요 시간을 줄여 성능을 개선할 수 있습니다.

3. 여러 애플리케이션과 공유가 가능합니다.

4. 기능 변경이 편합니다.

단점

1. 문자나 숫자열 연산에 사용하면 오히려 C, Java보다 느린 성능을 보일 수 있습니다.

2. 유지보수가 어렵습니다.

1. 프로시저 생성 구조

CREATE OR REPLACE PROCEDURE [프로시저이름] (파라미터1, 파라미터2…);

IS 
[변수]

BEGIN
[쿼리문]

END [프로시저이름] ;

Ex) p1 프로시저 생성

CREATE OR REPLACE PROCEDURE p1

IS

BEGIN

DBMS_OUTPUT.PUT_LINE (‘A’);

END;

2. 프로시저 조회

DECLARE

[출력될 변수 선언]

[실행할 프로시저]

[출력물]

END

Ex) p1 프로시저 2번 호출

DECLARE 
PROCEDURE p1

IS
BEGIN
DBMS_OUTPUT.PUT_LINE (‘B’);

END;

BEGIN
p1; 
scott.p1;
END;

——— 결과 ———
B
A

설명

첫 번째 p1는 중첩 프로시저가 수행

두 번째 scott.p1는 저장 프로시저가 수행

프로시저를 호출하면 중첩 프로시저의 존재여부를 먼저 확인하고 프로시저를 스키마 명으로 한정하면 저장 프로시저를 수행할 수 있다.

* SQL*Plus의 EXEC 명령어로도 저장 프로시저를 수행할 수 있다.

EX) EXEC p1

// A

* ALTER PROCEDURE 문은 저장 프로시저를 컴파일합니다.

ALTER PROCEDURE [프로시저이름] COMPILE;

Ex) ALTER PROCEDURE p1 COMPILE;

3. 프로시저 수정

수정은 CREATE OR REPLACE 구문을 사용하면 해당 프로시저명이 있다면 수정, 없다면 생성되게 됩니다.

CREATE OR REPLACE PROCEDURE [프로시저이름] (파라미터1, 파라미터2…);

IS 
[변수]

BEGIN
[쿼리문]

END [프로시저이름] ;

4. 프로시저 삭제

DROP PROCEDURE [프로시저명] ;

Ex) DROP PROCEDURE p1;

5. 매개변수 선언

형식 파라미터(매개변수)

: 헤더에 선언하는 매개변수의 이름, 방식, 데이터 타입, 기본값

실질 파라미터(인수)

: 호출 시 매개변수에 할당하는 값이나 표현식

Ex)i_v1, iv2 형식 파라미터와 1, 2 인수

DECLARE
	PROCEDURE p1 (i_v1 IN NUMBER, i_v2 IN NUMBER) — 형식 파라미터
IS

BEGIN
	DBMS_OUTPUT.PUT_LINE(i_v1 || ‘, ’ || i_v2);
END;

BEGIN
	p1(1, 2); —실질 파라미터
END;

// 1, 2

6. 매개변수 방식

입력 IN
출력 OUT
입출력 IN OUT

1. 입력 IN

Ex) 입력 매개변수는 프로시저 내부에서 상수로 동작하며 값을 변경할 수 없습니다.

DECLARE
	PROCEDURE p1 (i_v1 IN NUMBER)
..(생략)
BEGIN 
	i_v1 := 2;
END;

Ex) %TYPE 속성으로 기본값 선언한 값은 호출 시 인수 생략가능합니다.

DECLARE
	PROCEDURE p1 (i_deptno IN dept.deptno%TYPE DEFAULT 10)
IS
	v_dname dept.dname%TYPE;
BEGIN
	SELECT dname INTO v_dname FROM dept WHERE deptno = i_deptno;
	DBMS_OUTPUT.PUT_LINE (v_dname);
END;

BEGIN
	p1;
END;

Ex) 레코드 타입으로 매개변수 전달

DECLARE
	v1 dept%ROWTYPE;
	PROCEDURE p1 (i_dept IN dept%ROWTYPE)
IS
BEGIN
	DBMS_OUTPUT.PUT_LINE (i_dept.deptno || ‘: ‘ || i_dept.dname);
END;

BEGIN
	v1.deptno := ’10;
	v1.dname :’ ‘ACCOUNTING’;
	p1 (v1);
END;

// 10: ACCOUNTING

2. 출력

Ex) SYS_REFCURSOR 타입으로 o_rc 출력 매개변수로 선언하고, deptno에 해당하는 커서 변수를 전달하고 출력

DECLARE
    v_rc SYS_REFCURSOR; —  v_rc 커서 변수
    v_emp emp%ROWTYPE; — v_emp 로우 타입 변수
	PROCEDURE p1 (i_deptno IN dept.deptno%TYPE, o_rc OUT SYS_REFCURSOR) -- o_rc 출력
IS
BEGIN
	OPEN o_rc FOR SELECT * FROM emp WHERE deptno = i_deptno ORDER BY empno; — o_rc에 결과 레코드
END;

BEGIN
	p1 (10, v_rc); — 호출
    
LOOP
	FETCH v_rc INTO v_emp;
	EXIT WHEN v_rc%NOTFOUND;
	DBMS_OUTPUT.PUT_LINE (v_emp.ename);
END LOOP;

END;

3. 입출력 매개변수 IN OUT

Ex). 값 스왑(swap)

DECLARE
    v1 NUMBER := 1;
    v2 NUMBER := 2;
	PROCEDURE p1 (io_v1 IN OUT NUMBER, io_v2 IN OUT NUMBER)
IS
	v1 VARCHAR2(1);
BEGIN
	v1 := io_v1;
	io_v1 := io_v2;
	io_v1 := v1;
END;

* 프로시저 정보 검색

USER_OBJECTS 테이블 : DB에 존재하는 모든 오브젝트의 목록 정보(TABLE, VIEW, PROCEDURE, FUNCTION…)

SELECT * FROM USER_OBJECTS;

USER_PROCEDURES 테이블 : DB에 존재하는 프로시저 목록 정보

SELECT * FORM USER_PROCEDURES;

USER_SOURCE 테이블 : 프로시저 내용과 TYPE정보

SELECT 
	NAME, — 프로시저 명
	TEXT — 내용
FROM USER_SOURCE

[WebToB<->JEUS 연동하기]-http.m과 JEUSMain.xml 설정

defxyj — Sat, 30 Mar 2024 10:36:41 +0900

WeBToB(WEB)와 JEUS(WAS) 연동 시 설정

1. WEB/WAS 분리하는 이유

: 대용량의 요청이 들어왔을 때 WEB/WAS를 분리하여 정적인 페이지는 WebTob가, 동적인 요청일 경우 WAS에서 처리할 수 있게끔 연동을 해야한다.

2. WebtoB 설정(http.m)

경로 : webtob_home/config/http.m

구성	설명
DOMAIN 절	멀티 도메인 사용시 설정에 사용, 기본 default 사용
NODE 절	기본 서비스 설정 및 WebtoB 기능 설정
WEBTOBDIR	웹서버 경로
DOCROOT	Doc 경로
HostNAME	호스트 도메인 이름
IndexName	Index 페이지
VHOST 절	처음 서버로 요청이 유입되면 어떠한 서비스로 인식 후 처리할 지를 설정
ServiceOrder	URI절, EXT 절 우선순위 설정
Port	서비스 요청을 받을 서버포트
SVRGROUP 절	서비스 처리를 수행하는 서버들의 그룹
SERVER 절	요청에 대한 처리를 수행할 실제 서버 설정
URI 절	클라이언트 요청한 URI경로에 대해 설정
EXT 절	클라이언트가 요청한 확장자에 대해 어떤 처리를 할지를 설정

*DOMAIN
webtob1

*NODE
localwas	WEBTOBDIR="D:/xxxx/xxxx/jeus/webserver",
					SHMKEY = 54000,
					DOCROOT="D:/xxxx/xxxx/xxxx/webdocs",
					PORT = "80",
					HTH = 1,
					IPCPERM = 0777,
					JSVPORT = 9900,
					HostName="www.xxxxxx.go.kr",
					ServiceOrder = "uri,ext",
					IndexName = "index.jsp",
					NODENAME = "$(NODENAME)"
					
*VHOST
vhost_xxxx      DocRoot="D:/xxxx/xxxx/xxxx/webdocs",
                HostName="lxxx.xxxxxx.go.kr",
                NodeName=localwas,
                IndexName="home.jsp",
                Port="80"

*SVRGROUP
htmlg	    NODENAME = "localwas", SVRTYPE = HTML
xxxx	    NODENAME = "localwas", SVRTYPE = JSV,  VhostName="vhost_xxxx"

*SERVER
html			SVGNAME = htmlg, 		MinProc = 15, MaxProc = 30, ASQCount = 100
xxxx			SVGNAME = xxxx,  		MinProc = 15, MaxProc = 30, ASQCount = 100

*URI
image           Uri = "/images",    Svrtype = HTML
css             Uri = "/css",       Svrtype = HTML
js              Uri = "/js",        Svrtype = HTML

*LOGGING

*EXT
htm             MimeType = "text/html", SvrType = HTML
html            MimeType = "text/html", SvrType = HTML
jsp             MimeType = "application/jsp", SvrType = JSV

3. 제우스 설정 (JEUSMain.xml)

제우스의 주요 설정은 JEUSMain.xml에서 설정한다.

WebToB와 JEUS연동을 위해 http.m의 SERVER 이름과 JSVPORT 등 정보와 일치시켜줘야 합니다.

경로 : \JEUS_HOJME\config\<nodename>

<?xml version="1.0" encoding="utf-8"?>
<jeus-system xmlns="http://www.tmaxsoft.com/xml/ns/jeus" version="6.0">
	<node> <!-- node 설정 -->
		<name>nodename</name>
		<enable-webadmin>true</enable-webadmin>
		
		<naming-server>
			<!-- JNDI 설정 -->
		</naming-server>
		<security-manager>
			<!-- Security 설정 -->
		</security-manager>
		<engine-container> <!-- 컨테이너 설정 -->
			<name>xxxx</name>
			<command-option>
				-Dserver.type=L
				-Dserver.id=xxxx
				-Xdebug
				-Xnoagent
				-XX:+HeapDumpOnOutOfMemoryError          			
				 -XX:PermSize=256m -XX:MaxPermSize=512m
				-XX:HeapDumpPath=D:\xxxx\logs\heapdump
			</command-option>	
			<sequential-start>true</sequential-start>
			<engine-command>
				<type>servlet</type>
				<name>xxxx</name>
			</engine-command>
		</engine-container>
	</node>
	
	<resource> <!-- 외부 리소스 설정 -->
		<data-source>
			<database>
				<vendor>oracle</vendor>
				<export-name>xxxxDs</export-name>
				<data-source-class-name>oracle.jdbc.pool.OracleConnectionPoolDataSource</data-source-class-name>
				<data-source-type>LocalXADataSource</data-source-type>
				<database-name>dbname</database-name>
				<data-source-name>oracle.jdbc.pool.OracleConnectionPoolDataSource</data-source-name>
				<user>user</user>
				<password>1234</password>
				<port-number>1521</port-number>
				<server-name>xxx.xxx.xxx.xx</server-name>
				<driver-type>thin</driver-type>
				<connection-pool>
					<pooling>
						<min>3</min>
						<max>10</max>
						<step>1</step>
						<period>14000000</period>
					</pooling>
					<wait-free-connection>
						<enable-wait>true</enable-wait>
						<wait-time>10000</wait-time>
					</wait-free-connection>
				</connection-pool>
			</database>
		</data-source>
	</resource>

	<application> <!-- 제우스가 기동할 때 deploye되는 설정 -->
		<name>xxxx</name>
		<path>D:/xxxx/xxxx/xxxx/webapps</path>
		<deployment-type>COMPONENT</deployment-type>
		<web-component>
		<jeus-web-dd>D:/xxxx/xxxx/xxxx/webapps/WEB-INF/jeus-web-dd_xxxx.xml</jeus-web-dd>
		</web-component>
		<deployment-target>
			<target>
				<engine-container-name>xxxx_xxxx</engine-container-name>
				<web-context-group>
					<name>xxxx</name>
				</web-context-group>
			</target>
		</deployment-target>
	</application>
</jeus-system>

참고

https://technet.tmaxsoft.com/upload/download/online/jeus/pver-20140203-000001/server/chapter_server_conf.html

제2장 JEUS 설정

. . . johan 128 9937 3 40 3600000 true true true 192.168.*.* 211.180.1.* . . . . . . 다음은 설정에 사용되는 각 태그에 대한 설명이다.

technet.tmaxsoft.com

[leetcode 75 1456. Maximum Number of Vowels in a Substring of Given Length] - 슬라이딩 윈도우

defxyj — Fri, 22 Mar 2024 22:22:24 +0900

문제

https://leetcode.com/problems/maximum-number-of-vowels-in-a-substring-of-given-length/description/?envType=study-plan-v2&envId=leetcode-75

문자열 s과 정수가 주어 지면 길이가 있는 하위 문자열에서 모음 문자의 최대 개수를k 반환합니다 .sk

영어의 모음 글자'a' 는 , 'e', 'i', 'o', 입니다 'u'.

예시 1:

입력: s = "abciiidef", k = 3

출력: 3

설명: 하위 문자열 "iii"에는 3개의 모음 문자가 포함되어 있습니다.

예 2:

입력: s = "aeiou", k = 2

출력: 2

설명: 길이가 2인 하위 문자열에는 모음 2개가 포함됩니다.

예시 3:

입력: s = "leetcode", k = 3

출력: 2

설명: "lee", "eet" 및 "ode"에는 2개의 모음이 포함됩니다.

제약:

1 <= s.length <= 105
s영문 소문자로 구성됩니다.
1 <= k <= s.length

코드

class Solution {
    public int maxVowels(String s, int k) {
       int max=0;
       int current=0;

       // 첫번째 k사이즈 내에서 모음 값
       for(int i=0; i<k; i++){
        if(isVowel(s.charAt(i))){
            // 처음이 최대값
            max++;
        }
       }
       // 최대값이자 현재값
       current = max;

       for(int i=k; i<s.length(); i++){
        // 오른쪽으로 움직일 때 모음이 있을 경우 ++
        if(isVowel(s.charAt(i))){
            current++;
        }
        // 오른쪽으로 움직이면 왼쪽은 하나가 빠짐으로 모음일경우 --
        if(isVowel(s.charAt(i-k))){
            current--;
        }
        // max 재정리
        max = Math.max(max,current);
       } 
       return max;
    }
    public boolean isVowel(char c){
        return 'a'==c || 'e'==c || 'i'==c || 'o'==c || 'u'==c;
    }
}

[leetcode 75 198.House Robber] - DP, Math.max

defxyj — Fri, 22 Mar 2024 22:02:10 +0900

문제

https://leetcode.com/problems/house-robber/?envType=study-plan-v2&envId=leetcode-75

당신은 거리의 집을 털려는 전문 강도입니다. 각 집에는 일정 금액의 돈이 숨겨져 있습니다. 각각의 집에서 물건을 강탈하는 것을 막는 유일한 제약은 인접한 집에 보안 시스템이 연결되어 있고 같은 밤에 인접한 두 집에 침입한 경우 자동으로 경찰에 연락한다는 것입니다 .

nums각 집의 금액을 나타내는 정수 배열이 주어지면 오늘 밤 경찰에 신고하지 않고 훔칠 수 있는 최대 금액을 반환하세요 .

예시 1:

입력: nums = [1,2,3,1]

출력: 4

설명: 1번 집(돈 = 1)을 털고 3번 집(돈 = 3)을 털었습니다.

도둑질할 수 있는 총 금액 = 1 + 3 = 4.

예 2:

입력: nums = [2,7,9,3,1]

출력: 12

설명: 도둑의 집 1(돈 = 2), 도둑의 집 3(돈 = 9) 및 도둑의 집 5(돈 = 1).

도둑질할 수 있는 총 금액 = 2 + 9 + 1 = 12.

예 3:

입력: nums = [2,1,1,2]

출력: 4

제약:

1 <= nums.length <= 100
0 <= nums[i] <= 400

코드

class Solution {
    public int rob(int[] nums) {
        // 길이가 1개일 경우 제약조건 참조
        if(nums.length == 1) return nums[0];
        // dp배열은 누적 값
        int[] dp = new int[nums.length];
        dp[0] = nums[0];
        dp[1] = Math.max(nums[0],nums[1]);
        
        for(int i=2;i<nums.length;i++){
            // 현재위치에서 최대로 가져갈 수 있는 값은
            // 현 위치+누적금액 or 이전 위치
            dp[i] = Math.max(nums[i] + dp[i-2], dp[i-1]);
        }
        return dp[nums.length-1];
    }
}

[leetcode 75 746.Min Cost Climbing Stairs] - DP, Math.min()

defxyj — Fri, 22 Mar 2024 21:28:54 +0900

문제

https://leetcode.com/problems/min-cost-climbing-stairs/?envType=study-plan-v2&envId=leetcode-75

코드

class Solution {
    public int minCostClimbingStairs(int[] cost) {

        // i가 2부터인 이유는 제약조건
        for(int i = 2; i < cost.length; i++){
            // 두칸 아래와 한칸 아래 계단 중 더 값이 작은 계단을 밟으면 된다.
            // 그리고 밟은 계단의 비용을 더해준다.
            cost[i] = cost[i] + Math.min(cost[i-2], cost[i-1]);
        }
        // 배열 길이의 + 1 의 위치가 꼭대기라고 하면 꼭대기에서 한칸 아래와 두칸 아래 중 작은 값이 밟은 계단의 비용 최소값
        return Math.min(cost[cost.length-1], cost[cost.length-2]);
    }
}

[leetcode 345. Reverse Vowels of a String] - 스택, StringBuilder

defxyj — Thu, 21 Mar 2024 15:23:33 +0900

문제

https://leetcode.com/problems/reverse-vowels-of-a-string/?envType=study-plan-v2&envId=leetcode-75

코드

class Solution {
    private Boolean isVowel(char c){
        return c=='a' || c=='e' || c=='i' || c=='o' || c=='u' || c=='A' || c=='E' || c=='I' || c=='O' || c=='U';

    }
    public String reverseVowels(String s) {
        // 스택 형식으로 모음을 담으면 뒤집어서 반환가능
        Stack<Character> vowels = new Stack<>();
        // 반환 문자열 생성시 필요한 StringBuilder객체
        StringBuilder result = new StringBuilder();
        // 1. 주어진 문자열에서 모음을 찾아 스택에 push
        for(int i=0; i< s.length(); i++){
            if(isVowel(s.charAt(i))){
                vowels.push(s.charAt(i));
            }
        }
        // 2. 다시 주어진 문자열에 모음일 경우 스택에 있는 값으로 아닌경우 기존 문자로
        for(int i=0; i< s.length(); i++){
            if(isVowel(s.charAt(i))){
                result.append(vowels.pop());
            }else{
                result.append(s.charAt(i));
            }
        }
        return result.toString();
    }
}

[2023 KAKAO 개인정보 수집 유효기간] - HashMap, List, Array

defxyj — Thu, 8 Feb 2024 11:50:02 +0900

문제

고객의 약관 동의를 얻어서 수집된 1~n번으로 분류되는 개인정보 n개가 있습니다. 약관 종류는 여러 가지 있으며 각 약관마다 개인정보 보관 유효기간이 정해져 있습니다. 당신은 각 개인정보가 어떤 약관으로 수집됐는지 알고 있습니다. 수집된 개인정보는 유효기간 전까지만 보관 가능하며, 유효기간이 지났다면 반드시 파기해야 합니다.

예를 들어, A라는 약관의 유효기간이 12 달이고, 2021년 1월 5일에 수집된 개인정보가 A약관으로 수집되었다면 해당 개인정보는 2022년 1월 4일까지 보관 가능하며 2022년 1월 5일부터 파기해야 할 개인정보입니다.
당신은 오늘 날짜로 파기해야 할 개인정보 번호들을 구하려 합니다.

모든 달은 28일까지 있다고 가정합니다.

다음은 오늘 날짜가 2022.05.19일 때의 예시입니다.

약관 종류	유효기간
A	6 달
B	12 달
C	3 달
번호	개인정보 수집 일자	약관 종류
1	2021.05.02	A
2	2021.07.01	B
3	2022.02.19	C
4	2022.02.20	C

• 첫 번째 개인정보는 A약관에 의해 2021년 11월 1일까지 보관 가능하며, 유효기간이 지났으므로 파기해야 할 개인정보입니다.

두 번째 개인정보는 B약관에 의해 2022년 6월 28일까지 보관 가능하며, 유효기간이 지나지 않았으므로 아직 보관 가능합니다.
세 번째 개인정보는 C약관에 의해 2022년 5월 18일까지 보관 가능하며, 유효기간이 지났으므로 파기해야 할 개인정보입니다.
네 번째 개인정보는 C약관에 의해 2022년 5월 19일까지 보관 가능하며, 유효기간이 지나지 않았으므로 아직 보관 가능합니다.

따라서 파기해야 할 개인정보 번호는 [1, 3]입니다.

오늘 날짜를 의미하는 문자열 today, 약관의 유효기간을 담은 1차원 문자열 배열 terms와 수집된 개인정보의 정보를 담은 1차원 문자열 배열 privacies가 매개변수로 주어집니다. 이때 파기해야 할 개인정보의 번호를 오름차순으로 1차원 정수 배열에 담아 return 하도록 solution 함수를 완성해 주세요.

제한사항

today는 "YYYY.MM.DD" 형태로 오늘 날짜를 나타냅니다.
1 ≤ terms의 길이 ≤ 20
1 ≤ privacies의 길이 ≤ 100
today와 privacies에 등장하는 날짜의 YYYY는 연도, MM은 월, DD는 일을 나타내며 점(.) 하나로 구분되어 있습니다.
파기해야 할 개인정보가 하나 이상 존재하는 입력만 주어집니다.

입출력 예

today	terms	privacies	result
"2022.05.19"	["A 6", "B 12", "C 3"]	["2021.05.02 A", "2021.07.01 B", "2022.02.19 C", "2022.02.20 C"]	[1, 3]
"2020.01.01"	["Z 3", "D 5"]	["2019.01.01 D", "2019.11.15 Z", "2019.08.02 D", "2019.07.01 D", "2018.12.28 Z"]	[1, 4, 5]

입출력 예 설명

입출력 예 #1

문제 예시와 같습니다.

입출력 예 #2

약관 종류	유효기간
Z	3 달
D	5 달
번호	개인정보 수집 일자	약관 종류
1	2019.01.01	D
2	2019.11.15	Z
3	2019.08.02	D
4	2019.07.01	D
5	2018.12.28	Z

오늘 날짜는 2020년 1월 1일입니다.

첫 번째 개인정보는 D약관에 의해 2019년 5월 28일까지 보관 가능하며, 유효기간이 지났으므로 파기해야 할 개인정보입니다.
두 번째 개인정보는 Z약관에 의해 2020년 2월 14일까지 보관 가능하며, 유효기간이 지나지 않았으므로 아직 보관 가능합니다.
세 번째 개인정보는 D약관에 의해 2020년 1월 1일까지 보관 가능하며, 유효기간이 지나지 않았으므로 아직 보관 가능합니다.
네 번째 개인정보는 D약관에 의해 2019년 11월 28일까지 보관 가능하며, 유효기간이 지났으므로 파기해야 할 개인정보입니다.
다섯 번째 개인정보는 Z약관에 의해 2019년 3월 27일까지 보관 가능하며, 유효기간이 지났으므로 파기해야 할 개인정보입니다.

코드

import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import java.time.LocalDate;
class Solution {
    public int[] solution(String today, String[] terms, String[] privacies) {
        HashMap<String, String> date = new HashMap<>();   
        List<Integer> broken = new ArrayList<>();
        // A, 6
        // B, 12
        // C, 3
        for(int i=0; i<terms.length; i++){
            String[] term = terms[i].split(" ");
            date.put(term[0], term[1]);
        }
        // today -> 총 일수
        // 년 의 경우 년*월수(12)*일수(28)
        String[] t = today.split("\\.");
//        int year = Integer.parseInt(t[0])*28*12;
//        int month = Integer.parseInt(t[1])*28;
//        int day = Integer.parseInt(t[2]);
//        int all_day = year+month+day;
        int year = Integer.parseInt(t[0]);
        int month = Integer.parseInt(t[1]);
        int day = Integer.parseInt(t[2]);
        LocalDate all_day = LocalDate.of(year, month, day);
        // 개인정보 기한 + 약관종류의 유효기간
        for(int j=0; j<privacies.length; j++) {
        	String[] priv = privacies[j].split(" ");
//    		int num = Integer.parseInt(priv[0].split("\\.")[0])*28*12
//    				+(Integer.parseInt(priv[0].split("\\.")[1])
//    						+Integer.parseInt(date.get(priv[1])))*28
//    				+Integer.parseInt(priv[0].split("\\.")[2]);
    		LocalDate num = LocalDate.of(Integer.parseInt(priv[0].split("\\.")[0])
    				,Integer.parseInt(priv[0].split("\\.")[1])
    				,Integer.parseInt(priv[0].split("\\.")[2]));
    		num = num.plusMonths(Integer.parseInt(date.get(priv[1]))).minusDays(1);
    		if(all_day.isAfter(num)) {
    			broken.add(j+1);
    		}
        }
        return broken.stream().mapToInt(x->Integer.valueOf(x)).toArray();
    }
}

[leetcode 283. Move Zeroes 0으로 이동] - 투포인터

defxyj — Thu, 8 Feb 2024 11:46:20 +0900

문제

정수 배열이 주어지면 0이 아닌 요소의 상대적 순서를 유지하면서 모든 을 배열의 끝으로 nums이동합니다 .0

배열의 복사본을 만들지 않고 이 작업을 내부에서 수행해야 합니다 .

예시 1:

입력: 숫자 = [0,1,0,3,12]

출력: [1,3,12,0,0]

예시 2:

입력: 숫자 = [0]

출력: [0]

제약:

1 <= nums.length <= 104
-231 <= nums[i] <= 231 - 1

코드

class Solution {
    public void moveZeroes(int[] nums) {
        int tmp = 0;
        int index = 0;
        for(int len =0;len < nums.length; len++){
            if(nums[len] != 0){
                tmp = nums[len];
                nums[len] = nums[index];
                nums[index] = tmp;
                index++;
            }
        }
    }
}

[leetcode 328. Odd Even Linked List 홀수 짝수 연결 리스트] - LinkedList

defxyj — Thu, 8 Feb 2024 11:44:10 +0900

문제

단일 연결 리스트 의 경우 head, 홀수 인덱스를 가진 모든 노드를 그룹화한 다음 짝수 인덱스를 가진 노드를 그룹화하고 재정렬된 리스트를 반환합니다 .

첫 번째 노드는 홀수로 간주되고 두 번째 노드는 짝수로 간주됩니다.

짝수 그룹과 홀수 그룹 내부의 상대적 순서는 입력과 동일하게 유지되어야 합니다.

O(1) 추가 공간 복잡도와 O(n)시간 복잡도 문제를 해결해야 합니다 .

예시 1:

입력: 헤드 = [1,2,3,4,5]

출력: [1,3,5,2,4]

예시 2:

입력: 헤드 = [2,1,3,5,6,4,7]

출력: [2,3,6,7,1,5,4]

제약:

연결된 목록의 노드 수는 범위 내에 있습니다 .[0, 104]
-106 <= Node.val <= 106

코드

/**
 * Definition for singly-linked list.
 * public class ListNode {
 *     int val;
 *     ListNode next;
 *     ListNode() {}
 *     ListNode(int val) { this.val = val; }
 *     ListNode(int val, ListNode next) { this.val = val; this.next = next; }
 * }
 */
class Solution {
    public ListNode oddEvenList(ListNode head) {
        if(head == null) return head;
        ListNode odd = head;
        ListNode even = head.next;
        ListNode evenHead = even;

        while(odd.next != null && even.next != null){
            odd.next = odd.next.next;
            even.next = even.next.next;
            odd = odd.next;
            even = even.next;
        }
        odd.next = evenHead;
        return head;
    }
}

[leetcode 872. Leaf-Similar Trees 잎과 유사한 나무] - Tree

defxyj — Thu, 8 Feb 2024 11:41:41 +0900

문제

이진 트리의 모든 리프를 왼쪽에서 오른쪽 순서로 고려하면 해당 리프의 값은 리프 값 시퀀스를 형성합니다 .

예를 들어, 위의 주어진 트리에서 리프 값 시퀀스는 입니다 (6, 7, 4, 9, 8).

두 개의 이진 트리는 리프 값 순서가 동일하면 리프 유사로 간주됩니다 .

헤드 노드가 있고 잎이 유사한 true두 개의 주어진 트리가 있는 경우에만 반환합니다 .root1root2

예시 1:

입력: root1 = [3,5,1,6,2,9,8,null,null,7,4], root2 = [3,5,1,6,7,4,2,null,null,null ,null,null,null,9,8]

출력: true

예시 2:

입력: root1 = [1,2,3], root2 = [1,3,2]

출력: false

제약:

각 트리의 노드 수는 범위에 속합니다 [1, 200].
주어진 트리 모두는 범위 내의 값을 갖습니다 [0, 200].

코드

/**
 * Definition for a binary tree node.
 * public class TreeNode {
 *     int val;
 *     TreeNode left;
 *     TreeNode right;
 *     TreeNode() {}
 *     TreeNode(int val) { this.val = val; }
 *     TreeNode(int val, TreeNode left, TreeNode right) {
 *         this.val = val;
 *         this.left = left;
 *         this.right = right;
 *     }
 * }
 */
import java.util.*;
class Solution {
    List<Integer> list1;
    List<Integer> list2;
    int[] arr1;
    int[] arr2;
    public boolean leafSimilar(TreeNode root1, TreeNode root2) {
        list1 = new ArrayList<>();
        list2 = new ArrayList<>();
        bfs(root1, list1);
        bfs(root2, list2);
        arr1 = list1.stream().mapToInt(x->Integer.valueOf(x)).toArray();
        arr2 = list2.stream().mapToInt(x->Integer.valueOf(x)).toArray();

        return Arrays.equals(arr1,arr2);
    }
    public void bfs(TreeNode root, List list){
        if(root.left == null && root.right == null){
            list.add(root.val);
            return;
        }
        if(root.left != null) bfs(root.left,list);
        if(root.right != null) bfs(root.right,list);
    }
}

[leetcode 20. Valid Parentheses 유효한 괄호] - Stack

defxyj — Thu, 8 Feb 2024 11:37:44 +0900

문제

, , , 및 s문자만 포함된 문자열이 주어 지면 입력 문자열이 유효한지 확인합니다.'('')''{''}''['']'

다음과 같은 경우 입력 문자열이 유효합니다.

열린 괄호는 동일한 유형의 괄호로 닫혀야 합니다.
열린 괄호는 올바른 순서로 닫혀야 합니다.
모든 닫는 괄호에는 동일한 유형의 해당 열린 괄호가 있습니다.

예시 1:

입력: s = "()"

출력: true

예시 2:

입력: s = "()[]{}"

출력: true

예시 3:

입력: s = "(]"

출력: false

제약:

1 <= s.length <= 104
s괄호로만 구성됩니다 '()[]{}'.

코드

import java.util.Stack;
class Solution {
    public boolean isValid(String s) {
        Stack<Character> st = new Stack<>();
        for (int i=0; i<s.length(); i++){
            Character x = s.charAt(i);
            if (x=='(' || x=='{' || x=='['){
                st.push(x);
            }else{
                if(st.size() == 0) {
                    return false;
                }
                Character y = st.pop();
                if(x==')' && y!='('){
                    return false;
                }else if(x=='}' && y!='{'){
                    return false;
                }else if(x==']' && y!='['){
                    return false;
                }
            }
        }
        if(st.size()>0){
            return false;
        }
        return true;
    }
}

[leetcode 841. Keys and Rooms 열쇠의 방] - DFS

defxyj — Thu, 8 Feb 2024 11:35:57 +0900

문제

에서 n으로 표시된 방이 있으며 방을 제외한 모든 방은 잠겨 있습니다 . 당신의 목표는 모든 방을 방문하는 것입니다. 그러나 열쇠가 없으면 잠긴 방에 들어갈 수 없습니다.0n - 10

방을 방문하면 그 방에서 고유한 열쇠 세트를 찾을 수 있습니다 . 각 열쇠에는 어느 방의 잠금이 해제되는지 나타내는 숫자가 있으며, 이 열쇠를 모두 가져가면 다른 방의 잠금을 해제할 수 있습니다.

room을 방문했을 때 얻을 수 있는 키 세트가 있는 배열이 주어지면 rooms모든 방 을 방문할 수 있으면 반환 하고 그렇지 않으면 반환합니다 .rooms[i]itrue false

예시 1:

입력: Rooms = [[1],[2],[3],[]]

출력: true

설명:

방 0을 방문하여 키 1을 가져왔습니다.

그런 다음 방 1을 방문하여 키 2를 가져왔습니다.

그런 다음 방을 방문합니다. 2 그리고 열쇠 3을 집습니다.

그런 다음 방 3을 방문합니다

. 모든 방을 방문할 수 있었으므로 true를 반환합니다.

예 2:

입력: Rooms = [[1,3],[3,0,1],[2],[0]]

출력: false

설명: 방을 잠금 해제하는 유일한 열쇠가 방 번호 2에 있기 때문에 방 번호 2에 들어갈 수 없습니다. .

제약:

n == rooms.length
2 <= n <= 1000
0 <= rooms[i].length <= 1000
1 <= sum(rooms[i].length) <= 3000
0 <= rooms[i][j] < n
의 모든 값은 고유rooms[i] 합니다 .

코드

import java.util.List;
class Solution {
    boolean[] visited;
    public boolean canVisitAllRooms(List<List<Integer>> rooms) {
        //1.자료구조 초기화
        visited = new boolean[rooms.size()];
        //2.dfs
        dfs(0, rooms);
        // 방문체크한 거 체크해서 return
        for(int i=0; i<visited.length;i++){
            if(visited[i] == false){
                return false;
            }
        }
        return true;
    }
    public void dfs(int start, List<List<Integer>> rooms){
        //3.종료조건 -> 없음 rooms 파라미터만 체크 하고 끝내면됨
        //3.방문여부처리 및 재귀
        visited[start] = true;
        List<Integer> list = rooms.get(start);
        for(int key : list){
            if(!visited[key]){
                dfs(key, rooms);
            }
        }
    }
}

[leetcode 1137. N-th Tribonacci Number N번째 트리보나치 수] - DP

defxyj — Thu, 8 Feb 2024 11:33:27 +0900

문제

트리보나치 수열 Tn 은 다음과 같이 정의됩니다.

T 0 = 0, T 1 = 1, T 2 = 1, 그리고 T n+3 = T n + T n+1 + T n+2 for n >= 0.

가 주어지면 Tnn 값을 반환합니다 .

예시 1:

입력: n = 4

출력: 4

설명:

T_3 = 0 + 1 + 1 = 2

T_4 = 1 + 1 + 2 = 4

예 2:

입력: n = 25

출력: 1389537

제약:

0 <= n <= 37
답은 32비트 정수 내에 들어맞는 것이 보장됩니다. answer <= 2^31 - 1.

코드

class Solution {
    int a[];
    public int tribonacci(int n) {
        a = new int[n+1];
        for(int i=0; i<=n; i++){
            a[i] = -1;
        }
        if(n == 0){
            return 0;
        }else if(n == 1){
            return 1;
        }else if(n == 2){
            return 1;
        }else{
            a[0] = 0;
            a[1] = 1;
            a[2] = 1;    
        }
        return dp(n);
    }
    public int dp(int n){
        if(a[n] != -1){
            return a[n];
        }
        return a[n] = dp(n-3)+dp(n-2)+dp(n-1);
    }

}

[leetCode 2352. Equal Row and Column Pairs, 동일한 행과 열 쌍] - HashMap

defxyj — Thu, 8 Feb 2024 11:30:24 +0900

문제

0부터 인덱스가 지정된 정수 n x n행렬이 주어 지면 행 과 열이 동일하도록 쌍의 수를 반환합니다 .grid(ri, cj)ricj

행과 열 쌍은 동일한 순서로 동일한 요소를 포함하는 경우(즉, 동일한 배열) 동일한 것으로 간주됩니다.

예시 1:

입력: 그리드 = [[3,2,1],[1,7,6],[2,7,7]]

출력: 1

설명: 1개의 동일한 행과 열 쌍이 있습니다:

- (행 2, 열 1 ): [2,7,7]

예 2:

입력: 그리드 = [[3,1,2,2],[1,4,4,5],[2,4,2,2],[2,4,2,2]]

출력: 3

설명: 3개의 동일한 행과 열 쌍이 있습니다.

- (행 0, 열 0): [3,1,2,2]

- (행 2, 열 2): [2,4,2,2]

- (행 3, 열 2): [2,4,2,2]

제약:

n == grid.length == grid[i].length
1 <= n <= 200
1 <= grid[i][j] <= 105

코드

import java.util.HashMap;
import java.util.List;
import java.util.Arrays;
class Solution {
    public int equalPairs(int[][] grid) {
        HashMap<Integer, List<int[] >> hm =new HashMap<>();
        for(int i=0; i<grid.length; i++){
            hm.put(i, Arrays.asList(grid[i]));
        }
        
        int cnt = 0;
        for(int j=0; j<hm.size(); j++){
            List<int[] > arr = hm.get(j);
            int[] a = arr.get(0);
            for(int i=0; i<a.length; i++){
            	int sum = 0;
            	for(int k=0; k<grid[0].length; k++) {
                    if(a[k] == grid[k][i]){
                        sum++;
                    }
            	}
            	if(sum == grid.length)
            		cnt++;
            }
        }
        return cnt;
    }
}

5 - AWS Certified Solutions Architect Associate(SAA) 기출문제(101~120문제 정리)

defxyj — Sat, 13 Jan 2024 06:03:50 +0900

101.한 회사가 고성능 컴퓨팅 애플리케이션과 데이터를 온프레미스에서 AWS 클라우드로 마이그레이션하려고 함. 이 회사는 애플리케이션을 주기적으로 실행하는 동안 애플리케이션을 지원하기 위해 핫 고성능 별령 스토리지와 함게 온프레미스 계층형 스토리지를 사용하고, 애플리케이션이 활발하게 실행되지 않을 때 데이터를 보관하기 위해 보다 경제적인 콜드 스토리지를 사용합니다. 애플리케이션의 스토리지 요구 사항을 지원하기 위해 솔루션 설계자가 권장해야 하는 솔루션 조합은 무엇입니까?

-> 콜드 데이터 스토리지용 Amazon S3, 고성능 병렬 스토리지를 위한 Amazon FSx for Lustre

Amazon FSx for Lustre : 고성능 파일 시스템을 쉽고 비용 효율적으로 실행. ML, HPC, 비디오 처리, 금융 모델링 등 속도가 중요한 워크로드에서 사용.세계에서 가장 빠른 컴퓨터를 위해 설계된 널리 사용되는 파일 시스템

102.회사의 애플리케이션이 단일 리전의 Amazon EC2 인스턴스에서 실행되고 있습니다. 재해 발생 시 솔루션 설계자는 리소스를 두 번째 지역에도 배포할 수 있는지 확인해야 합니다. 이를 달성하기 위해 솔루션 설계자는 어떤 작업 조합을 수행해야 합니까?

-> 새 리전의 AMI에서 새 EC2 인스터스를 시작. 또는 EC2 인스턴스의 AMI를 복사하고 다른 리전을 지정.

교차 리전 EC2 AMI 복사 : AMI Copy를 사용하면 AWS 간에 AMI를 쉽게 복사.
다중 리전 배포 : 한 리전에서 다른 리전으로 AMI를 복사

103.솔루션 설계자는 VPC의 Amazon EC2 인스턴스에서 Amazon DynamoDB에 대한 API 호출이 인터넷을 통과하지 않도록 해야 함. 이를 달성하기 위해 솔루션 설계자는 무엇을 해야 함?

-> 엔드포인트에 대한 라우팅 테이블 항목을 생성 또는 DynamoDB용 게이트웨이 엔드포인트를 생성

VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 장치, VㅖN 연결 또는 AWS DX 연결 없이 VPC를 지원하는 AWS 서비스 및 AWS PirvateLink에서 제공하는 VPC 엔드포인트 서비스에 비공개로 연결 가능. VPC의 인스턴스는 서비스의 리소스와 통신하기 위해 퍼블릭 IP 주소가 필요하지 않은 VPC와 다른 서비스 간의 트래픽은 Amazon 네트워크를 벗어나지 않음
게이트웨이 앤드포인트 : 지원되는 AWS 서비스로 향하는 트래픽에 대한 라우팅 테이블의 경로에 대한 대상으로 지정하는 게이트웨이

104.회사의 레거시 애플리케이션은 현재 암호화 없이 단일 인스턴스 Amazon RDS MySQL 데이터베이스에 의존. 새로운 규정 준수 요구 사항으로 인해 이 데이터베이스의 모든 기존 데이터와 새 데이터를 암호화해야함. 이것은 어떻게 달성되어야 하는가?

-> RDS 인스턴스의 스냅샷을 찍음. 스냅샷의 암호화된 복사본을 만듬. 암호화된 스냅샷에서 RDS 인스턴스를 복원

RDS 스냅샷 암호화 : MySQL, Oracle, SQL Server, PostgreSQL 또는 MariaDB용 RDS에 적용. Amazon Aurora를 사용하는 경우 암호화되지 않은 DB 클러스터 스냅샷에서 복원할 때 AWS KMS 암호화 키를 지정하면 암호화되지 않은 Aurora DB 클러스터 스냅샷을 암호화된 Aurora DB 클러스터로 복원 가능

105.제조회사에서 기계장비에 대한 예측 유지 관리를 구현. 이 회사는 데이터를 실시간으로 AWS에 보낼 수천 개의 IoT 센서를 설치. 솔루션 설계자는 각 기계 자산에 대해 순서대로 이벤트를 수신하고 나중에 추가 처리를 위해 데이터를 저장하도록 하는 솔루션을 구현. 가장 효율적인 솔루션을 무엇?

->각 장비 자산에 대한 파티션이 있는 실시간 이벤트에 Amazon Kinesis Data Streams를 사용. Amazon Kinesis Data Firehose를 사용하여 데이터를 Amazon S3에 저장.

106.회사의 웹사이트는 ALB 뒤의 Amazon EC2 인스턴스에서 실행. 웹사이트에는 동적 콘텐츠와 정적 콘텐츠가 혼합. 전 세계 사용자들이 웹사이트가 느리다고 보고하고 있음. 전세계 사용자의 웹사이트 성능을 향상시키는 조치는?

-> Amazon CloudFront 배포를 생성하고 ALB를 오리진으로 구성. 그런 다음 CloudFront 배포를 가리키도록 Amazon Route53 레코드를 업데이트 함.

Amazon CloudFront : 정적 및 동적 웹 콘텐츠를 사용자에게 빠르게 배포하는 웹 서비스. 엣지로케이션이라고 하는 전 세계 데이터 센터 네트워크를 통해 콘텐츠를 제공. 사용자가 요청하면 사용자는 지연시간이 가장 짧은 엣지 로케이션으로 라우팅되므로 콘텐츠가 가능한 최상의 성능으로 제공.

107.한 회사는 지난 몇 년 동안 Amazon RDS 인스턴스에 분석 데이터를 저장해 왔습니다. 회사는 솔루션 아키텍트에게 사용자가 API를 사용하여 이 데이터에 액세스할 수 있는 솔루션을 찾아달라고 요청. 애플리케이션이 비활성 기간을 경험하지만 몇 초 내에 폭발적인 트래픽을 수신할 수 있음. 솔루션 설계자는 어떤 솔루션을 제안?

-> Amazon API Gateway를 설정하고 AWS Lambda 함수를 사용합니다.

AWS Lambda : 관리 없이 거의 모든 유형의 애플리케이션 또는 백엔드 서비스에 대한 코드를 실행. 코드를 업로드하기만 하면 Lambda가 코드를 실행하고 확장하는데 필요한 모든것을 처리. 다른 AWS 서비스에서 자동으로 트리거하거나 웹 또는 모바일 앱에서 직접 호출하도록 코드를 설정.
Amazon API Gateway : 개발자가 모든 규모에서 API를 쉽게 생성, 게시 유지 관리, 모니터링 및 보호할 수 있게 해주는 완전 관리형 서비스. API는 애플리케이션이 백엔드 서비스의 데이터, 비즈니스 로직 또는 기능에 액세스하기 위한 정문 역할. 실시간 양방향 통신 애플리케이션을 지원하는 RESTful API 및 WebSocketAPI를 쉽게 생성. 컨테이너화된 서버리스 워크로드와 웹 애플리케이션을 지원. 트래픽 관리, CORS 지원, 권한 부여 및 액세스 제어, 스로틀링, 모니터링, API 버전관리를 포함하여 최대 수십만건의 동시 API 호출을 수락하고 처리하는 것과 관련된 모든 작업을 처리.

108.게임 회사는 레이어 4의 사용자와 통신하는 멀티플레이어 게임을 위해 단일 가용 영역에 여러 EC2 인스턴스를 보유. 최고 기술 책임자는 아키텍처의 가용성과 비용 효율성을 높이려고 함. 솔루션 설계자는 이러한 요구사항을 충족하기 위해 무엇을 해야함?

->여러 가용 영역에서 자동으로 인스턴스를 추가하거나 제거하도록 Auto Scaling 그룹을 구성. 또는 EC2 인스턴스 앞에 NLB를 구성

109.회사는 현재 Amazon RDS MySQL 데이터베이스에서 지원하는 웹 애플리케이션을 운영. 매일 실행되고 암호화되지 않은 자동 백업이 있음. 보안 감사에서는 향후 백업을 암호화하고 암호화되지 않은 백업을 파기해야 함. 회사는 이전 백업을 파기하기 전에 적어도 하나의 암호화된 백업을 만듬. 향후 백업을 위해 암호화를 활성화하려면 어떻게 해야 함?

->데이터베이스의 스냅샷을 만듬. 암호화딘 스냅샷에 복사. 암호화된 스냅샷에서 데이터 베이스를 복원.

110.한 회사가 여러 ALB 뒤에서 웹사이트를 호스팅하고 있음. 회사는 전 세계적으로 콘텐츠에 대한 다양한 배포 권한을 가지고 있음. 솔루션 설계자는 배포 권한을 침해하지 않고 사용자에게 올바른 콘텐츠를 제공. 솔루션 설계자는 이러한 요구 사항을 충족하기 위해 어떤 구성을 선택해야 함?

->지리적 위치 정책으로 Amazon Route 53을 구성.

111.솔루션 설계자가 새 AWS 계정을 생성했으며 AWS 계정 루트 사용자 액세스를 보호해야 합니다. 어떤 작업 조합이 이를 달성합니까?

-> 루트 사용자가 강력한 암호를 사용하는지 확인. 또는 루트 사용자에 대한 다단계 인증을 활성화

112.전자상거래 회사의 솔루션 설계자는 애플리케이션 로그 데이터를 Amazon S3에 백업하려고합니다. 솔루션 설계자는 로그에 액세스하는 빈도 또는 가장 많이 액세스할 로그를 확신하지 못합니다. 회사는 적절한 S3 스토리지 클래스를 사용하여 비용을 가능한 낮게 유지하려고합니다. 요구사항을 충족하려면 어떤 S3 스토리지 클래스를 구현해야 합니까?

-> S3 지능형 계층화

113.회사의 웹사이트는 대중에게 제품을 판매하는데 사용됩니다. 이 사이트는 ALB 뒤에 있는 Auto Scaling 그룹의 Amazon EC2 인스턴스에서 실행. Amazon CloudFront 배포도 있으며 SQL 삽입 공격으로부터 보호하기 위해 AWS WAF를 사용하고 있습니다. ALB는 CloudFront 배포의 오리진입니다. 최근 보안 로그를 검토한 결과, 웹사이트 접근을 차단해야 하는 외부 악성 IP가 발견되었습니다. 애플리케이션을 보호하기 위해 솔루션 설계자는 무엇을 해야 합니까?

->악성 IP 주소를 차단하기 위해 IP 일치 조건을 추가하도록 AWS WAF 구성을 수정.

AWS WAF : 허용되거나 허용되지 않은 요청 또는 IP 주소를 정의하는 액세스 제어 목록, 규칙 및 조건을 사용. 웹 애플리케이션의 특정 부분에 대한 액세스를 선택적으로 허용하거나 거부할 수 있으며 다양한 SQL 삽입 공격으로부터 보호할수도 있음.

114.솔루션 설계자는 2단계 주문 프로세스를 위한 애플리케이션을 디자인하고 있습니다. 첫 번째 단계는 동기식이며 대기 시간이 거의 없이 사용자에게 반환되어야 합니다. 두번째 단계는 더 오래 걸리므로 별도의 구성 요소에서 구현됩니다. 주문은 접수된 순서대로 정확히 한 번만 처리되어야 합니다. 솔루션 설계자는 이러한 구성 요소를 어떻게 해야 합니까?

->Amazon SQS FIFO 대기열을 사용.

115.웹 애플리케이션은 AWS 클라우드에 배포. 웹 레이어와 데이터베이스 레이어를 포함하는 2계층 아키텍처로 구성. 웹 서버는 XSS 교차 사이트 스크립팅 공격에 취약. 취약점을 수정하기 위해 솔루션 설걔자는 무엇을 해야 합니까?

-> ALB를 생성. 로드 밸런서 뒤에 웹 계층을 배치하고 AWS WAF를 활성화.

교차 사이트 스크립팅 XSS : 웹 애플리케이션의 취약성을 악용하기 위해 웹 요청에 스크립트를 삽입하는 경우가 있음. AWS WAF에서 가능한 악성 스크립트를 검사하도록 하려는 웹 요청 부분을 식별.

116.회사의 웹사이트는 트랜잭션 데이터 스토리지에 Amazon RDS MySQL 다중 AZ DB인스턴스를 사용. 내부 일괄 처리를 위해 데이터를 가져오기 위해 이 DB 인스턴스를 쿼리하는 다른 내부 시스템이 있음. 내부 시스템이 데이터를 가져올 때 RDS DB 인스턴스의 속도가 크게 느껴짐. 이것은 웹 사이트의 읽기 및 쓰기 성능에 영향을 미치며 사용자는 느린 응답 시간을 경험. 어떤 솔루션이 웹사이트의 성능을 향상시킬까요?

->RDS DB 인스턴스에 읽기 전용 복제본을 추가하고 읽기 전용 복제본을 쿼리하도록 내부 시스템을 구성.

117.애플리케이션은 여러 가용 영역의 Amazon EC2 인스턴스에서 실행. 인스턴스는 ALB 뒤의 Amazon EC2 Auto Scaling 그룹에서 실행. 애플리케이션은 EC2 인스턴스의 CPU 사용률이 40% 또는 거의 40%일때 최상의 성능을 발휘. 솔루션 설계자는 그룹의 모든 인스턴스에서 원하는 성능을 유지하기 위해 무엇을 해야 합니까?

->대상 추적 정책을 사용하여 Auto Scaling 그룹을 동적으로 확장.

대상 추적 조정 정책 : 조정 지표를 선택하고 대상 값을 설정. 트리거하고 지표 및 대상 값을 기반으로 조정을 계산하는 CloudWatch 경보를 생성 및 관리합니다. 메트릭을 지정된 목표 값 또는 그에 근접하게 유지하는 데 필요한 만큼 용량을 추가하거나 제거.

118.회사에서 내부 브랑루저 기반 애플리케이션을 실행. 애플리케이션은 ALB 뒤의 Amazon EC2 인스턴스에서 실행. 인스턴스는 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행. Auto Scaling 그룹은 근무 시간 동안 최대 20개의 인스턴스로 확장되지만 밤에는 2개의 인스턴스로 축소. 오전 중반까지는 잘 돌아가는데도 하루가 시작되면 애플리케이션이 매우 느리다고 직원들이 불평. 직원 불만을 해결하고 비용을 최소화하기 위해 확장을 어떻게 변경해야 합니까?

->사무실이 열리기 직전에 원하는 수용 인원을 20명으로 설정하는 예약 작업을 구현.

119.회사에서 AWS에 배포된 기존 워크로드에 대한 AWS Well-Architected 프레임워크 검토를 수행. 검토에서는 다른 AWS 서비스를 지원하기 위해 최근에 설치된 Microsoft Active Directory 도메인 컨트롤러와 동일한 Amazon EC2 인스턴스에서 실행되는 공개 웹 사이트를 식별. 솔루션 설계자는 아키텍처의 보안을 개선하고 IT 직원의 관리 요구를 최소화하는 새로운 설계를 권장해야 함. 솔루션 설계자는 무엇을 추천해야 합니까?

->AWS Direct Service를 사용하여 관리형 Active Directory를 생성. 현재 EC2 인스턴스에서 Active Directory를 제거.

120.팀의 모든 AWS 계정에서 특정 서비스 또는 작업에 대한 액세스를 제한하는 보안 팀. 모든 계정은 AWS Organizations의 대규모 조직에 속합니다. 솔루션은 확장 가능해야 하며 권한을 유지할 수 있는 단일 지점이 있어야 합니다. 이를 달성하기 위해 솔루션 설계자는 무엇을 해야 합니까?

->루트 조직 단위에 서비스 제어 정책을 만들어 서비스 또는 작업에 대한 액세스를 거부.

서비스 제어 정책 : SCP는 계정의 모든 IAM 엔티티에 대한 중앙 액세스를 제공. 이를 사용하여 비즈니스의 모든 사람이 따르기를 원하는 권한을 적용.

4 - AWS Certified Solutions Architect Associate(SAA) 기출문제(81~100문제 정리)

defxyj — Sat, 13 Jan 2024 06:02:52 +0900

82.솔루션 설계자는 기본 웹사이트를 사용할 수없는 경우 사용자가 백업 정적 오류 페이지로 이동하는 솔루션을 설계하고 있음. 기본 웹사이트의 DNS 레코드는 해당 도메인이 Application Load Balancer를 가리키는 Amazon Route53에서 호스팅 됨. 솔루션 설계자는 변경 및 인프라 오버헤드를 최소화하면서 회사의 요구사항을 충족하기 위해 어떤 구성을 사용?

-> Route53 활성-수동 장애 조치 구성을 설정. Route 53 상태 확인에서 ALB 엔드포인트가 비정상이라고 판단하면 Amazon S3 버킷 내에서 호스팅되는 정적 오류 페이지로 트래픽을 보냄.

S3
Route53 활성-수동 장애조치

83.솔루션 아키텍트는 Amazon EC2 에서 고성능 컴퓨팅(HPC) 워크로드를 설계. EC2 인스턴스는 서로 자주 통신해야 하며 대기 시간이 짧고 처리량이 높은 네트워크 성능이 필요. 어떤 EC2 구성이 이러한 요구 사항을 충족?

-> 하나의 가용 영역에 있는 클러스터 배치 그룹에서 EC2 인스턴스를 시작.

클러스터 배치그룹

84.회사는 AWS에서 확장 가능한 웹 애플리케이션을 호스팅. 응용프로그램은 전 세계 여러 지역의 사용자가 액세스 가능. 애플리케이션 사용자는 최대 기가 바이트 크기의 고유한 데이터를 다운로드하고 업로드. 개발 팀은 업로드 및 다운로드 대기 시간을 최소화 하고 성능을 최대화 할 수 있는 비용 효율적인 솔루션을 원함. 이를 달성하기 위한 필요한 것은?

->Auto Scaling 및 Amazon CloudFront와 함께 Amazon EC2를 사용하여 애플리케이션을 호스팅

확장 가능 -> Auto Scaling
전 세계 여러 지역의 사용자가 액세스, 데이터 다운로드하고업로드 -> Amazon CloudFront
Amazon S3 Transfer Acceleration : 클라이언트와 S3 버킷 간의 장거리 파일 전송을 파일을 빠르쉽고 안전하게 전송할 수 있는 버킷 수준 기능. 전 세계에서 S3 버킷으로 전송 속도를 최적화하도록 설계

85.회사가 온프레미스 인프라에서 AWS 클라우드로 마이그레이션하고 있음. 회사의 애플리켕키션 중 하나는 DFSR(Distributed File System Replication)을 사용하여 데이터 동기화를 유지하는 Windows 파일 서버 팜에 저장. 솔루션 설계자는 파일 서버 팜을 교체해야함. 어떤 서비스를 사용해야 함?

-> Amazon FSx

Windows 파일 서버 -> Amazon FSw(File Server for windows)

86.회사에는 데이터를 두 부분으로 처리하는 레거시 응용 프로그램이 있음. 프로세스의 두 번째 부분은 첫 번째 부분보다 오래 걸리므로 회사는 독립적으로 확장할 수 있는 Amazon ECS에서 실행되는 두 개의 마이크로 서비스로 애플리케이션을 다시 작성하기로 결정. 설계자는 마이크로서비스를 어떻게 통합해야 합니까?

-> 마이크로 서비스 1에서 코드를 구현하여 Amazon SQS 대기열로 데이터를 전송. 마이크로 서비스2에서 코드를 구현하여 대기열의 메시지를 처리.

Amazon ECS : 확장성이 뛰어나고 빠른 컨테이너 서비스.
Amazon SQS : 분산 소프트웨어 시스템 및 구성 요소를 통합 및 분리할 수 있는 호스팅 대기열을 제공

87.회사의 애플리케이션은 ALB 뒤의 Amazon EC2 인스턴스에서 실행. 인스턴스는 여러 가용 영역에 걸쳐 Amazon EC2 Auto Scaling 그룹에서 실행. 매월 1일 자정에 월말 재무 계산 일괄 처리가 실행되면 응용 프로그램이 훨씬 느려짐. 이로 인해 EC2 인스턴스의 CPU 사용률이 즉시 100%에 도달하여 애플리케이션이 중단. 애플리케이션이 워크로드를 처리하고 다운타임을 방지할 수 있도록 하기 위해 설계자는 무엇을 권장?

-> 월별 일정을 기반으로 EC2 Auto Scaling 예약 조정 정책을 구성.

88.회사는 뉴스 콘텐츠를 호스팅하는 다중 계층 웹 애플리케이션을 실행. 애플리케이션은 ALB 뒤의 Amazon EC2 인스턴스에서 실행. 인스턴스는 여러 가용 영역의 EC2 Auto Scaling 그룹에서 실행되며 Amazon Aurora 데이터베이스를 사용. 솔루션 설계자는 요청 비율의 주기적인 증가에 대해 애플리케이션의 탄력성을 높임. 솔루션 설계자는 어떤 아키텍처를 구현?

-> Aurora 복제본 추가. ALB 앞에 Amazon CloudFront 배포를 추가.

Amazon CloudFront : 개발자 친화적인 환경 내에서 짧은 지연 시간, 높은 전송속도로 데이터, 비디오, 애플리케이션 및 API를 전 세계 고객에게 안전하게 전달하는 빠른 콘텐츠 전송 네트워크 서비스(CDN)
AWS Global Accelerator : 지연 시간에 민감한 애플리케이션을 위한 가속. 많은 애플리케이션, 특히 게임, 미딩, 모바일 앱 및 금융과 같은 분야의 경우 우수한 사용자 경험을 위해 매우 짧은 지연 시간이 필요. 사용자 경험을 개선하기 위해 Global Accelerator는 사용자 트래픽을 클라이언트에 가장 가까운 애플리케이션 엔드포인트로 보내 인터넷 대기시간과 지터를 줄임.

89.AWS에서 실행되는 애플리케이션은 데이터베이스에 Amazon Aurora 다중 AZ배포를 사용. 솔루션 설계자는 성능 매트릭을 평가 할 때 데이터베이스 읽기로 인해 높은 I/O가 발생하고 데이터베이스에 대한 쓰기 요청에 대기 시간이 추가된다는 사실을 발견. 쓰기 요청에서 읽기 요청을 분리하기 위해 솔루션 설계자는 무엇을 해야함?

-> 읽기 전용 복제본을 생성하고 적절한 엔드포인트를 사용하도록 애플리케이션을 수정.

Amazon RDS 읽기 전용 복제본 : RDS 인스턴스에 향상된 성능과 내구성을 제공. 읽기가 많은 데이터베이스 워크로드에 대해 단일 DB 인스턴스의 용량 제약을 넘어 탄력적으로 쉽게 확장할 수 있음. 주어진 원본 DB 인스턴스의 복제본을 하나 이상 생성하고 데이터의 여러 복사본에서 대량의 애플리케이션 읽기 트래픽을 처리하여 전체 읽기 처리량을 높임. 읽기 전용 복제본은 RDS for MySQL, MariaDB, PostgreSQL, Oralce, SQL Server 및 Amazon Aurora를 사용.

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html https://aws.amazon.com/rds/features/read-replicas/

Working with DB instance read replicas - Amazon Relational Database Service

Within an AWS Region, we strongly recommend that you create all read replicas in the same virtual private cloud (VPC) based on Amazon VPC as the source DB instance. If you create a read replica in a different VPC from the source DB instance, classless inte

docs.aws.amazon.com

90.최근에 인수한 회사는 AWS에서 자체 인프라를 구축하고 한 달안에 여러 애플리케이션을 클라우드로 마이그레이션해야함. 각 애플리케이션에는 약 50TB의 데이터를 전송. 마이그레이션이 완료된 후 이 회사와 모회사는 모두 데이터 센터에서 애플리케이션까지 일괄된 처리량과 함께 안전한 네트워크 연결이 필요. 솔루션 설계자는 일회성 데이터 마이그레이션과 지속적인 네트워크 연결을 보장. 이러한 요구 사항을 충족하는 솔루션은?

-> 초기 전송을 위한 AWS Snowball 및 지속적인 연결을 위한 AWS Direct Connect

AWS Snowball : 물리적 스토리지 디바이스를 사용하여 인터넷보다 빠른 속도로 S3와 온사이트 데이터 스토리지 위치 간에 대량의 데이터를 전송.
AWS Direct Connect(DX) : 온프레미스 네트워크와 AWS 간에 전용 네트워크 연결을 설정.

-> Amazon CloudFront를 사용하여 애플리케이션을 제공하고 차단된 국가에 대한 액세스를 거부

Amazon CloudFront: 정적 및 동적 웹 콘텐츠를 사용자에게 빠르게 배포하는 실시간 스트리밍 배포 웹 서비스. 엣지 로케이션이라고 하는 전세계 데이터 센터 네트워크를 통해 콘텐츠를 제공. 지리적 제한을 사용하여 특정 지리적 위치에 있는 사용자가 CloudFront 웹 배포를 통해 배포하는 콘텐츠에 액세스하지 못하도록 가능.

92.회사에서 많은 양의 데이터를 저장할 새 애플리케이션을 만들고 있습니다. 데이터는 매시간 분석되고 여러 가용영역에 배포된 여러 Amazon EC2 Linux 인스턴스에 의해 수정. 애플리케이션 팀은 필요한 공간이 양이 향후 6개월 동안 계속 증가할 것이라고 생각. 이러한 요구 사항을 지원하기 위해 솔루션 설계자는 어떤 조치를 취해야함?

-> Amazon Elastic File System은 AWS 클라우드 서비스 및 온프레미스 리소스와 함께 사용할 수 있는 간단하고 확장 가능하며 완벽하게 관리되는 탄력적 NFS 파일 시스템을 제공. 애플리케이션 중단 없이 온디맨드 방식으로 페타바이트까지 확장할 수 있도록 구축되었으며, 파일을 추가 및 제거함에 따라 자동으로 확장 및 축소되므로 성장을 수용하기 위해 용량을 프로비저닝하고 관리할 필요가 없음.

93.회사에서 3계층 애플리케이션을 AWS로 마이그레이션하고 있음. 애플리케이션에는 MySQL 데이터베이스가 필요. 과거에는 응용 프로그램 사용자가 새 항목을 만들 때 응용 프로그램 성능이 좋지 않다고 보고함. 이러한 성능 문제는 근무 시간 동안 애플리케이션에서 서로 다른 실시간 보고서를 생성하는 사용자로 인해 발생. 애플리케이션을 AWS로 이전할 때 애플리케이션의 성능을 향상시키는 솔루션은?

-> 여러 읽기 전용 복제본이 있는 Amazon Aurora MySQL 다중 AZ DB 클러스터를 생성. 보고서에는 판독기 엔드포인트를 사용하도록 애플리케이션을 구성.

클러스터 엔드포인트 : 애플리케이션을 해당 DB 클러스터의 현재 기본 DB 인스턴스에 연결. 애플리케이션은 이 인스턴스를 읽고 쓸 수 있음.
판독기 엔드포인트 : 사용가능한 읽기 전용 복제본 풀 전체에서 연결 부하를 분산. 여기에서 읽기 쿼리를 오프로드하여 기본 DB 인스턴스의 로드를 줄임.
인스턴스 엔드포인트 : 클러스터의 특정 인스턴스에 연결.

94.솔루션 아키텍트가 Amazon API Gateway를 기반으로 하는 새로운 서비스를 설계. 서비스에 대한 요청 패턴은 예측할 수 없으며 초당 0개 요청에서 500개 이상으로 갑자기 변경 가능. 백엔드 데이터베이스에 유지해야 하는 데이터의 총 크기는 현재 1GB 미만이며 향후 증가를 예측할수 없음. 간단한 키 값 요청을 사용하여 데이터를 쿼리할 수 있음. 이러한 요구 사항을 충족하는 AWS 서비스 조합은?

-> AWS Lambda, Amazon DynamoDB

95.글로벌 이벤트의 주최자는 일일 보고서를 정적 HTML 페이지로 온라인에 게시하려고 함. 이 페이지는 전 세계 사용자로부터 수백만 건의 조회수를 생성할 것으로 예상. 파일은 Amazon S3 버킷에 저장. 솔루션 설계자는 효율적이고 효과적인 솔루션을 설계하라는 요청을 받음. 이를 달성하기 위해 솔루션 설계자는 어떤 조치를 취해야함?

-> S3 버킷과 함께 Amazon CloudFront를 원본으로 사용.

96.스타트업 회사는 us-east-1 지역에 기반을 둔 웹 애플리케이션을 보유. 여러 가용 영역에서 ALB 뒤에서 실행되는 여러 EC2 인스턴스가 있음. 회사의 사용자 기반이 us-west-1 리전에서 증가함에 따라 대기 시간이 짧고 가용성이 높은 솔루션이 필요. 이를 달성하기 위해 솔루션 설계자는 무엇을 해야함?

-> us-west-1에서 EC2인스턴스를 프로비저닝하고 ALB 를 구성. 두 리전의 로드 밸런서 엔드포인트를 포함하는 엔드포인트 그룹을 사용하는 AWS Global Accelerator에서 엑셀러레이터를 생성.

97.솔루션 설걔자는 이미지 카탈로그에 액세스하고 사용자에게 이미지를 사용자 지정하기 위한 요청을 제출할 수 있는 기능을 제공하는 솔루션을 설계. 이미지 사용자 지정 매개변수는 AWS API Gateway API로 전송되는 모든 요청에 포함. 맞춤형 이미지는 주문형으로 생성되며 사용자는 클릭하여 맞춤형 이미지를 보거나 다운로드할 수 있는 링크를 받게 됨. 솔루션은 이미지 보기 및 사용자 정의에 대한 가용성이 높음. 이러한 요구 사항을 충족하는 가장 비용 효율적인 솔루션은?

-> AWS Lambda를 사용하여 원본 이미지를 요청된 사용자 지정으로 조작. 원본 이미지와 조작된 이미지를 Amazon S3에 저장. S3 버킷을 오리진으로 사용하여 Amazon CloudFront배포를 구성.

98.회사에서 비즈니스 크리티컬 데이터 세트를 Amazon S3로 마이그레이션할 계획. 현재 솔루션 설계는 us-east-1 리전에서 버전 관리가 활성화된 단일 S3 버킷을 사용하여 데이터 세트를 저장. 회사의 재해 복구 정책에 따르면 모든 데이터는 여러 AWS 리전. 솔루션 설계자는 S3 솔루션을 어떻게 설계?

-> 다른 리전에서 버전 관리를 사용하여 추가 S3 버킷을 생성하고 리전간 복제를 구성.

99.회사에는 VPC의 Amazon EC2 인스턴스에서 실행되는 애플리케이션이 있음. 애플리케이션 중 하나는 Amazon S3 API를 호출하여 객체를 저장 하고 읽어야 함. 회사의 보안 정책은 애플리케이션에서 인터넷에 연결된 모든 트래픽을 제한. 보안을 유지하는 조치는?

->S3 게이트웨이 엔드포인트를 구성

S3 게이트웨이 엔드포인트

100.회사의 웹 애플리케이션은 Amazon RDS PostgreSQL DB 인스턴스를 사용하여 애플리케이션 데이터를 저장. 매월 초 재무 결산 기간 동안 회계사는 높은 사용량으로 인해 데이텁레이스 성능에 영향을 미치는 대규모 쿼리를 실행합니다. 회사는 보고 활동이 웹 애플리케이션에 미치는 여향을 최소화하려고 함. 최소한의 노력으로 데이터 베이스에 미치는 영향을 줄이기 위해 솔루션 설계자는 무엇을 해야 합니까?

-> 읽기 복제본을 생성하고 보고 트래픽을 복제본으로 보냄

Amazon RDS : MariaDB, MySQL, Oracle, PostgreSQL 및 Microsoft SQL Server DB 엔진의 내장 복제 기능을 사용하여 원본 DB 인스턴스에서 읽기 전용 복제본이라는 특별한 유형의 DB 인스턴스를 생성. 원본 DB 인스턴스에 대한 업데이트는 읽기 전용 복제본에 비동기식으로 복사. 애플리케이션에서 읽기 전용 복제본으로 읽기 쿼리를 라우팅하여 소스 DB 인스턴스의 로드를 줄임 가능. 읽기 전용 복제본을 생성 할 때 먼저 기존 DB 인스턴스를 원본으로 지정. 그 다음 RDS는 소스 인스턴스의 스냅샷을 만들고 스냅샷에서 읽기 전용 인스턴스를 생성 . 그 후 RDS는 원본 DB 인스턴스가 변경될 때마다 DB엔진에 대한 비동기 복제 방법을 사용하여 읽기 전용 복제본을 업데이트 함.

3 - AWS Certified Solutions Architect Associate(SAA) 기출문제(51~80문제 정리)

defxyj — Sat, 13 Jan 2024 06:01:26 +0900

51.AWS에서 여러 Windows 워크로드를 실행. 회사 직원은 두개의 Amazon EC2 인스턴스에서 호스팅되는 Windows 파일 공유를 사용. 파일 공유는 서로간에 데이터를 동기화하고 복제본을 유지. 회사는 사용자가 현재 파일에 액세스하는 방식을 보존하는 가용성이 높고 내구성이 뛰어난 스토리지 솔루션을 원함

-> 다중 AZ 구성을 사용하여 파일 공유 환경을 Windows 파일 서버용 Amazon FSx로 확장. 모든 데이터를 FSx for Windonws File Server로 마이그레이션

Amazon FSx for Windows File Server(Window 파일 서버용 Amazon FSx) : 완전한 네이티브 Windows 파일 시스템이 지원하는 완전관리형 Microsoft Windows 파일 서버를 제공하며 Windows 워크로드를 지원. 파일 시스템 기능을 기본적으로 지원하며 네트워크를 통해 파일 스토리지에 액세스할 수 있는 서버 메시지 블록(SMB) 프로토콜 지원.EC2 인스턴스와 온프레미스 컴퓨팅 인스턴스에서 파일 공유에 액세스 가능. Direct Connect 또는 AWS VPN을 사용하여 동일한 VPC 있는 파일 공유에 액세스할 수 있다.

52.아키텍처는 EC2 인스턴스와 RDS DB 인스턴스를 사용하여 애플리케이션을 호스팅. 아키텍처는 2개의 가용영역에 있는 6개의 서브넷으로 구성. 각 가용 영역에는 퍼블릿 서브넷, 프라이빗 서브넷 및 데이터베이스 전용 서브넷이 포함. 프라이빗 서브넷에서 실행되는 EC2 인스턴스만 RDS 데이터베이스에 액세스할 수있습니다. 충족하는 솔루션은?

-> 프라이빗 서브넷의 인스턴스에 할당된 보안 그룹에서 인바운드 트래픽을 허용하는 보안 그룹을 생성. 보안 그룹을 DB 인스턴스에서 연결

53.Amazon Route 53에 도메인 등록. 회사는 ca-central-1리전의 API Gateway를 백엔드 마이크로서비스 API용 퍼블릭 인터페이스로 사용. 타사 서비스는 API를 안전하게 사용. 회사는 타사 서비스가 HTTPS를 사용할 수 있도록 회사의 도메인 이름과 해당 인증서로 API 게이트웨이 URL을 설계하려고함. 충족하는 솔루션은?

->지역 API 게이트웨이 엔드포인트를 생성. API Gateway 끝점을 회사의 도메인 이름과 연결. 회사 도메인 이름과 연결된 공인 인증서를 동일한 리전의 AWS Certificate Manager 로 가져옴. API Gateway 엔드포인트에 인증서를 연결. 트래픽을 API 게이트웨이 엔드포인트로 라우팅하도록 Route 53 구성

Amazon Route 53 : 가용성과 확장성이 뛰어난 DNS 웹서비스. 주된 기능은 도메인 등록, DNS 라우팅, 상태확인이다.

Route53이 도메인의 트래픽을 라우팅하는 방법

사용자가 웹 브라우저를 열어 주소 표시줄에 www.example.com을 입력하고 Enter 키를 누릅니다.
www.example.com에 대한 요청은 일반적으로 케이블 인터넷 공급업체, DSL 광대역 공급업체 또는 기업 네트워크 같은 인터넷 서비스 제공업체(ISP)가 관리하는 DNS 해석기로 라우팅됩니다.
ISP의 DNS 해석기는 www.example.com에 대한 요청을 DNS 루트 이름 서버에 전달합니다.
DNS 해석기는 www.example.com에 대한 요청을 이번에는 .com 도메인의 TLD 이름 서버 중 하나에 다시 전달합니다. .com 도메인의 이름 서버는 example.com 도메인과 연관된 4개의 Route 53 이름 서버의 이름을 사용하여 요청에 응답합니다.
DNS 해석기는 4개의 Route 53 이름 서버를 캐싱(저장)합니다. 다음에 누군가 example.com을 찾아볼 때 example.com의 이름 서버가 이미 있으므로 해석기는 3단계와 4단계를 건너뜁니다. 이름 서버는 일반적으로 2일 동안 캐시에 저장됩니다.
DNS 해석기는 Route 53 이름 서버 하나를 선택하여 www.example.com에 대한 요청을 해당 이름 서버에 전달합니다.
Route 53 이름 서버는 example.com 호스팅 영역에서 www.example.com 레코드를 찾아 웹 서버의 IP 주소 192.0.2.44 등 연관된 값을 받아 이 IP 주소를 DNS 해석 프로그램에 반환합니다.
DNS 해석기가 마침내 사용자에게 필요한 IP 주소를 해석해 냅니다. 해석기는 이 값을 웹 브라우저로 반환합니다.

Amazon API Gateway : 백엔드 HTTP 엔드포인트, AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한 RESTful 애플리케이션 프로그래밍 인터페이스(API)의 생성, 배포 및 관리. AWS Lambda 함수 또는 기타 AWS 서비스를 노출하기 위한 WebSocket API의 생성, 배포 및 관리. 프런트 엔드 HTTP 및 WebSocket 엔드포인트를 통해 노출된 API 메서드 호출
API Gateway REST API, API Gateway HTTP API, API Gateway WebSocket API : 백엔드 HTTP 엔드포인트, Lambda 함수 또는 기타 AWS 서비스와 통합되어 있는 HTTP 리소스와 메서드 모음.

API Gateway의 아키텍처
API Gateway 엔드 포인트 : 특정 리전에 배포되는 API Gateway의 API 호스트 이름으로 유형으로 엣지 최적화 API 엔드포인트, 프라이빗 API 엔드포인트, 리전 API 엔드포인트가 있다.
엣지 최적화 API 엔드포인트 : 일반적으로 AWS 리전 전체에서 클라이언트 액세스가 용이하도록 CloudFront 배포를 사용할 때 지정된 리전에 배포되는 API Gateway API의 기본 호스트 이름. API 요청은 지리적으로 다양한 클라이언트를 위해 연결 시간을 일반적으로 향상하는 가장 가까운 CloudFront 로 라우팅됩니다.
프라이빗 API 엔드포인트 : 인터페이스 VPC 엔드포인트를 통해 노출되고 클라이언트가 VPC 내부의 프라이빗 API 리소스에 안전하게 액세스할 수 있도록 해주는 API 엔드포인트. 프라이빗 API는 퍼블릿 인터넷과 격리되어 있으며, 액세스 권한이 있는 API Gateway의 VPC 종단점을 사용해야만 액세스 가능
리전 API 엔드포인트 : 특정 리전에 배포되고 동일한 AWS 리전에서 EC2 인스턴스와 같은 클라이언트에 서비스를 제공하는 API의 호스트 이름. API 요청은 CloudFront 배포판을 거치지 않고 리전별 API Gateway로 직접 지정.
AWS Certificate Mananger(ACM) : 에서 제고ㅇ한 SSL/TLS 인증서를 요청하는 외에도 AWS 외부에도 취득한 인증서를 가져올 수 있음. 서트파티 인증기관(CA)의 인증서, 외부에서 가져온 인증서를 ACM과 통합된 모든 AWS 서비스와 함께 사용 가능.

54.웹사이트는 사용자에게 이미지를 업로드하여 다른 사용자와 공유할 수 있는 기능을 제공. 회사는 이미지에 부적절한 콘텐츠가 포함되어 있지 않은지 확인하려고함. 회사는 개발 노력을 최소화하는 솔루션이 필요.

-> Amazon Rekognition을 사용하여 부적절한 콘텐츠를 감지. 신뢰도가 낮은 예측에는 사람의 검토를 사용.

Amazon Rekognition : 기계 학습 전문 지식이 필요하지 않은 입증되고 확장성이 뛰어난 딥러닝 기술을 사용하여 이미지 및 비디오 분석을 애플리케이션에 쉽게 추가 가능하며 이미지와 동영상에서 객체, 사람, 텍스트, 장면, 활동을 식별하고 부적절한 콘텐츠를 감지 및 분석 비교.

55.확장성 및 가용성에 대한 요구 사항을 충족하기 위해 컨테이너에서 중요한 애플리케이션을 실행하려고 함. 회사는 중요한 응용 프로그램의 유지 관리에 집중하는 것을 선호. 회사는 컨테이너화된 워크로드를 실행하는 기본 인프라를 프로비저닝하고 관리하는 책임을 원하지 않음. 충족하는 방법은?

-> AWS Fargate에서 Amazon ECS를 사용

Amazon Elastic Container Service(ECS) : 컨테이너화된 애플리케이션을 쉽게 배포, 관리, 스케일링할 수 있도록 도와주는 완전 관리형 컨테이너 오케스트레이션 서비스, AWS Fargate의 서버리스 옵션으로 서버를 관리하거나, 용량 계획을 처리하거나, 보안을 위해 컨테이너 워크로드를 격리할 필요가 없음.

56.300개 이상의 글로벌 웹사이트와 애플리케이션을 호스팅. 회사는 매일 30TB 이상의 클릭스트림 데이터를 분석할 플랫폼이 필요. 클릭 스트림 데이터를 전송하고 처리하기 위해 무엇이 필요?

-> Amazon Kinesis Data Streams에서 데이터를 수집. Amazon Kinesis Data Firehose를 사용하여 데이터를 Amazon S3 데이터 레이크로 전송. 분석을 위해 Amazon Redshift에 데이터를 로드

Amazon Kinesis Data Streams : 대규모 데이터를 수집하고 처리. 데이터 스트림의 데이터 레코드가 실시간으로 표시.
Amazon Kinesis Data Firehose : 실시간 스트리밍 데이터를 제공하는 완전 관리형 서비스, Kinesis Data Streams, Kinesis Data Analytics와 함께 Kinesis 스트리밍 데이터 플래폼의 일부로 Firehose로 데이터를 보내도록 데이터 생산자를 구성하면 지정한 대상으로 데이터가 자동으로 전달됨. 데이터를 전송하기 전에 데이터를 변환하도록 구성 가능
Amazon S3 데이터 레이크 : 엔터프라이즈 환경 내의 다양한 소스로부터 원본 데이터를 획득, 처리, 분석 및 제공하는 거대한 규모의 데이터 저장소, 온프레미스 또는 클라우드에 구축 가능하며 주로 S3에 사용
Amazon Redshift : 기존 비즈니스 인텔리전스 도구를 사용하여 모든 데이터를 효율적으로 분석하는 작업을 간단하고 데이터 병렬 처리를 지원하며 비용 효율적으로 만드는 빠르고 완전 관리형 데이터 웨어하우스 서비스

57.웹사이트는 HTTP와 HTTPS를 별도로 처리하도록 구성된 ALB 뒤에 있음. 회사는 요청이 HTTPS를 사용하도록 모든 요청을 웹사이트로 전달. 충족하기 위해 무엇을 해야 함?

-> ALB 에서 리스너 규칙을 생성하여 HTTP 트래픽을 HTTPS로 리다이렉션

ALB : Elastic Load Balancing 은 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동 분산. Application Load Balancer는 개방형 시스템간 상호 연결 모델의 일곱 번째 계층인 애플리케이션 계층에서 작동. 요청을 받으면 우선 순위에 따라 리스너 규칙을 평가하여 적용할 규칙을 결정한 다음, 규칙 작업의 대상 그룹에서 대상을 선택

58.AWS에서 2계층 웹 애플리케이션을 개발 중. 회사의 개발자는 백엔드 Amazon RDS 데이터베이스에 직접 연결되는 EC2 인스턴스에 애플리케이션을 배포. 회사는 애플리케이션에 데이터베이스 자격 증명을 하드코딩해서는 안됨. 정기적으로 데이터 베이스 자격 증명을 자동으로 교체하는 솔루션을 구현.

-> 데이터베이스 자격 증명을 AWS Secrets Manager에 비밀로 저장. 보안 비밀에 대해 자동 회전을 켭니다. 암호에 대한 액세스 권한을 부여하려면 EC2 역할에 필요한 권한 연결

데이터베이스 자격 증명
AWS Secrets Manager : IAM 권한 정책을 사용하여 권한 있는 사용자만 보안 암호에 액세스 하거나 보안 암호를 수정할 수 있도록 동작. 암호를 포함하여 코드의 하드 코딩된 자격증명을 Secrets Manager에 대한 API 호출로 대체하여 프로그래밍 방식으로 암호를 검색 가능하며 이렇게 하면 비밀이 코드에 더 이상 존재하지 않기 때문에 코드를 검사하는 누군가가 비밀을 손상시킬 수 없음. 또한 지정된 일정에 따라 암호를 자동으로 교체하도록 구성 가능

59.AWS에 새로운 퍼블릭 웹 애플리케이션을 배포. 애플리케이션 ALB 뒤에서 실행. 외부 인증(CA)에서 발급한 SSL/TLS 인증서를 사용하여 엣지에서 애플리케이션을 암호화해야함. 인증서는 만료되기 전에 매년 교체해야 함

-> AWS Certificate Manager(ACM)를 사용하여 SSL/TLS 인증서를 가져옴. ALB에서 인증서를 적용. 인증서 만료가 가까워지면 Amazon EventBridge(Amazon CloudWatch Events)를 사용하여 알림을 보냄. 인증서를 수동으로 교체

60.AWS에서 인프라를 실행하고 문서관리 애플리케이션에 대해 700,000명의 등록된 사용자 기반을 가지고 있습니다. 회사는 대용량, .pdf 파일을 .jpg 이미지 파일로 변환하는 제품을 만들려고 함. pdf파일의 평균 크기는 5MB . 회사는 원본 파일과 변환된 파일을 보관해야 함. 솔루션 설계자는 시간이 지남에 따라 빠르게 증가할 수요를 수용할 수 있는 확장 가능한 솔루션을 설계

-> pdf파일을 Amazon S3 에 저장. 파일을 jpg 형식으로 변환하고 Amazon S3에 다시 저장하는 AWS Lambda 함수를 호출하도록 S3 PUT 이벤트를 구성

61.회사는 온프레미스에서 실행되는 Windows 파일 서버에 5TB 이상의 파일 데이터를 보유. 사용자와 애플리케이션은 매일 데이터와 상호작용. Windows 워크로드를 AWS로 이전하고 있음. 회사가 이 프로세스를 계속 진행함에 따라 회사는 최소한의 대기 시간으로 AWS 및 온프레미스 파일 스토리지에 액세스해야 함. 회사는 운영 오버헤드를 최소화하고 기존 파일 액세스 패턴을 크게 변경할 필요가 없는 솔루션이 필요. 이 회사는 AWS에 연결하기 위해 AWS Site-to-Site VPN 연결을 사용. 요구사항에 충족하기 위한 방법은?

-> AWS에서 Windows File Server용 Amazon FSx를 배포하고 구성. 온프레미스 파일 데이터를 FSx for Windows File Server로 이동합니다. AWS에서 Windows File Server 용 FSx를 사용하도록 워크로드를 재구성

AWS Site-to-Site VPN : 기본적으로 Amazon VPC로 시작하는 인스턴스는 자체(원격) 네트워크와 통신할 수 없음. Site-to-Site VPN 연결을 생성하고 연결을 통해 트래픽을 전달하도록 라우팅을 구성하여 VPC에서 원격 네트워크에 대한 액세스를 활성화 가능, VPN 연결을 통해 온프레미스 장비와 VPC간의 보안 연결, VPN 터널을 통해 데이터가 고객 네트워크에서 AWS와 주고 받을 수 있는 암호화된 링크
대상 게이트웨이 Target gateway : 사이트 간 VPN연결의 Amazon 측 VPN 엔드포인트를 일컫는 용어
가상 프라이빗 게이트웨이 : 단일 VPC에 연결할 수 있는 사이트 간 VPN 연결의 Amazon 측 VPN 엔드포인트
전송 게이트웨이 :사이트 간 VPN 연결의 Amazon 측 VPN 엔드포인트로 여러 VPC와 온프레미스 네트워크를 상호 연결하는 데 사용될 수 있는 전송 허브

62.한 병원은 최근 Amazon API Gateway 및 AWS Lambda와 함께 RESTful API를 배포. 병원은 API 게이트웨이와 Lambda를 사용하여 PDF 형식과 JPEG 형식의 보고서를 업로드. 병원은 보고서에서 보호 건강 정보(PHI)를 식별하기 위해 Lambda 코드를 수정. 요구사항에 충족하기 위한 방법은?

-> Amazon Textract를 사용하여 보고서에서 텍스트를 추출. Amazon Comprehend Medical을 사용하여 추출된 텍스트에서 PHI를 식별

Amazon Textract : 애플리케이션에 문서 텍스트 감지 및 분석 기능을 쉽게 추가. 다양한 문서에서 입력 및 필기 텍스트를 감지, API를 사용하여 구조화된 데이터가 있는 문서에서 텍스트 및 테이블 추출 가능
Amazon Comprehend Medical : 의사 노트, 퇴원 요약, 검사 결과 및 사례 노트와 같은 비정형 임상 텍스트에서 유용한 정보를 감지하여 반환, 자연어 처리 모델(NLP)을 사용하여 PHI와 같은 의료 정보에 대한 텍스트 참조인 엔터티를 감지

63.회사에는 각각 크기가 약 5MB인 많은 수의 파일을 생성하는 응용 프로그램이 있음. 파일은 Amazon S3에 저장. 회사 정책에 따라 파일은 삭제되기 전에 4년동안 저장되어야 함. 파일에는 재현하기 어려운 중요한 비즈니스 데이터가 포함되어 있으므로 즉각적인 액세스 가능성이 항상 필요. 파일은 개체 생성 후 처음 30일 동안 자주 액세스되지만 처음 30일 이후 에는 거의 액세스되지 않습니다. 가장 비용 효율적인 스토리지 솔루션은?

-> 객체 생성 30일 후에 S3 Standard에서 S3 Glacier로 파일을 이동하는 S3 버킷 수명 주기 정책을 생성. 객체 생성 후 4년이 지나면 파일을 삭제

64.회사는 여러 Amazon EC2 인스턴스에서 애플리케이션을 호스팅. 애플리케이션은 Amazon SQS 대기열의 메시지를 처리하고 Amazon RDS 테이블에 쓰고 대기열에서 메시지를 삭제. 때때로 중복 레코드가 RDS 테이블에 발견. SQS 대기열에는 중복 메시지가 없음. 메시지가 한번만 처리되도록 하려면 어떻게 해야 합니까?

-> ChangeMessageVisibility API 호출을 사용하여 가시성 제한 시간을 늘림

가시성 제한 시간 : 소비자가 대기열에 메시지를 수신하고 처리하면 메시지는 계속 대기열에 있음. SQS에서 메시지를 자동으로 삭제하지 않음. 소비자는 메시지를 수신하고 처리한 후 대기열에서 메시지를 삭제해야 함. 다른 소비자가 메시지를 다시 처리하지 못하게 하기 위해 SQS에서 메시지를 수신하고 처리할 수 없도록 차단하는 기간을 말함.
ChangeMessageVisibility : 대기열에 있는 지정된 메시지의 가시성 제한 시간을 새 값으로 변경

65.회사의 온프레미스 인프라를 AWS로 확장하기 위해 새로운 하이브리드 아키텍처를 설계하고 있음. 회사는 AWS 리전에 대해 지속적으로 짧은 지연 시간을 갖는 고가용성 연결이 필요. 회사는 비용을 최소화해야 하며 기본 연결이 실패할 경우 더 느린 트래픽을 수용할 의향이 있음. 요구사항을 충족하기 위한 방법은?

-> 리전에 대한 AWS Direct Connect 연결을 프로비저닝함. 기본 Direct Connect 연결이 실패할 경우 VPN 연결을 백업으로 프로비저닝함

66.회사는 Application Load Balancer 뒤의 Amazon EC2 인스턴스에서 비즈니스 크리티컬 웹 애플리케이션을 실행. EC2 인스턴스는 Auto Scaling 그룹에 있음. 애플리케이션은 단일 가용 영역에 배포된 Amazon Aurora PostgreSQL 데이터베이스를 사용. 회사는 가동 중지 시간을 최소화하고 데이터 손실을 최소화하면서 애플리케이션의 가용성을 높이길 원함. 요구사항에 충족하는 솔루션은?

-> 여러 가용 영역을 사용하도록 Auto Scaling 그룹을 구성. 데이터베이스를 다중 AZ로 구성. 데이터베이스에 대한 Amazon RDS Proxy 인스턴스를 구성

Amazon RDS Proxy : 애플리케이션이 데이터베이스 연결을 풀링하고 공유하도록 허용하여 확장 기능을 향상할 수 있음. 애플리케이션 연결을 유지하면서 예비 DB 인스턴스에 자동으로 연결하여 데이터베이스 장애에 대한 애플리케이션의 복원력을 높임. 예기치 않은 데이터베이스 트래픽 급증을 처리할 수 있음.

67.회사의 HTTP 애플리케이션은 NLB 뒤에 있음. NLB의 대상 그룹은 웹서비스를 실행하는 여러 EC2 인스턴스와 함께 Amazon EC2 Auto Scaling 그룹을 사용하도록 구성. 회사는 NLB가 애플리케이션에 대한 HTTP 오류를 감지하지 못한다는 것을 알게 됨. 이러한 오류는 웹서비스를 실행하는 EC2 인스턴스를 수동으로 다시 시작 해야 함. 회사는 사용자 지정 스크립트나 코드를 작성하지 않고 애플리케이션의 가용성을 개선해야함. 요구사항에 충족하기 위한 방법은?

-> NLB를 Application Load Balancer로 교체. 회사 애플리케이션의 URL을 제공하여 HTTP 상태 확인을 활성화. 비정상 인스턴스를 교체하도록 Auto Scaling 작업을 구성

NLB(Network Load Balancer) : 둘 이상의 가용 영역에서 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 걸쳐 수신되는 트래픽을 자동으로 분산. 등록된 대상의 상태를 모니터링하면서 상태가 양호한 대상으로만 트래픽을 라우팅. TCP, UDP 트래픽의 경우 프로토콜, 원본 IP 주소, 원본 퐅, 대상 IP 주소 에 따라 흐름 해시 알고리즘을 사용하여 대상을 선택

68.회사는 Amazon DynamoDB를 사용하여 고객 정보를 저장하는 쇼핑애플리케이션을 실행. 데이터 손상의 경우 솔루션 설계자는 15분의 RPO(복구 지점 목표)와 1시간의 RTO(복구 시간 목표)를 충족하는 솔루션을 설계. 요구사항을 충족하기 위한 방법은?

-> DynamoDB 특정 시점으로 복구. RPO 복구를 위해 원하는 시점으로 복원

DR : 재해복구 전략의 시작은 백업 및 잊웅화 워크로드 구성 요소를 갖추는 것, RTO 및 RPO는 워크로드 복원을 위한 것.
RTO : 복구 시간 목표는 서비스 중단 시점과 복원 시점 간에 허용되는 최대 지연 시간으로 서비스를 사용할 수 없는 상태로 허용되는 기간을 결정
rpo : 복구 시점 목표는 마지막 데이터 복구 시점 이후 허용되는 최대 시간으로 마지막 복구 시점과 서비스 중단 시점 사이에 허용되는 데이터 손실량을 결정

69.회사는 동일한 AWS 리전에 있는 Amazon S3 버킷에서 사진을 자주 업로드하고 다운로드해야 하는 사진 처리 애플리케이션을 실행. 솔루션 아키텍트가 데이터 전송 비용의 증가를 발견하고 이러한 비용을 줄이기 위한 솔루션은?

-> S3 VPC 게이트웨이 엔드포인트를 VPC에 배포하고 S3 버킷에 대한 액세스를 허용하는 엔드포인트 정책을 연결

70.2계층 웹 애플리케이션을 설계하고 있음. 애플리케이션은 퍼블릭 서브넷의 EC2 에서 호스팅되는 퍼블릭 웹 계층으로 구성. 데이터베이스 계층은 프라이빗 서브넷의 EC2에서 실행되는 Microsoft SQL Server로 구성. 보안은 회사의 최우선 순위. 보안그룹을 어떻게 구성?

->0.0.0.0/0에서 포트 443의 인바운드 트래픽을 허용하도록 웹계층에 대한 보안 그룹을 구성. 웹계층의 보안 그룹에서 포트 1433의 인바운드 트래픽을 허용하도록 데이터베이스 계층의 보안 그룹을 구성

보안 그룹 : EC2 인스턴스에 대한 수신 및 발신 트래픽을 제어하는 가상 방화벽 역할을 합니다. 인바운드 규칙은 인스턴스로 들어오는 트래픽을 제어하고 아웃바운드 규칙은 인스턴스에서 나가는 트래픽을 제어. VPC에서 인스턴스를 시작할 때 해당 VPC에 대해 생성된 보안 그룹을 지정해야 함. 보안 그룹은 네트워크 인터페이스와 연결됨.
TCP 1433 포트는 Microsoft SQL Server 액세스 허용, 3306는 MySQL 액세스 허용

71.회사는 단일 공장에 있는 여러 기계에서 매일 10TB의 계측 데이터를 받음. 데이터는 공장 내에 위치한 온프레미스 데이터 센터의 SAN(Storage Area Network)에 저장된 JSON 파일로 구성. 회사는 이 데이터를 거의 실시간에 가까운 중요한 분석을 제공하는 여러 추가 시스템에서 액세스 할 수 있는 S3로 보내려고 함. 데이터가 민감한 것으로 간주되기 때문에 안전한 전송이 중요. 안정적인 데이터 전송 제공 솔루션은?

-> AWS Direct Connect 를 통한 AWS DataSync

AWS DataSync : 온프레미스 스토리지와 S3, EFS, FSx 간에 대량의 데이터를 온라인으로 이동. 복사 작업 스크립팅, 전송 예약 및 모니터링, 데이터 검증, 네트워크 활용 최적화를 포함하여 이러한 많은 작업을 제거하거나 자동으로 처리함.

72.회사는 애플리케이션에 대한 실시간 데이터 수집 아키텍처를 구성. 회사는 API, 데이터가 스트리밍될 때 데이터를 변환하는 프로세스, 데이터를 위한 스토리지 솔루션이 필요. 요구사항에 충족하는 솔루션은?

-> Amazon Kinesis 데이터 스트림으로부터 데이터를 전송하도록 Amazon API Gateway API를 구성. Kinesis 데이터 스트림을 데이터 소스로 사용하는 Amazon Kinesis Data Firehose 전송 스트림을 생성. AWS Lambda 함수를 사용하여 데이터를 변환. Kinesis Data Firehose 전송 스트림을 사용하여 데이터를 Amazon S3로 보냄

73.사용자 트랜잭션 데이터를 Amazon DynamoDB 테이블에 보관해야 함. 회사는 데이터를 7년간 보관. 요구사항 충족하는 솔루션은?

-> AWS Backup을 사용하여 테이블에 대한 백업 일정 및 보존 정책을 생성

AWS Backup : AWS 서비스, 클라우드 및 온프레미스에서 데이터 보호를 쉽게 중앙집중화하고 자동화할 수 있는 완전관리형 서비스. AWS 리소스에 대한 백업 정책을 구성하고 활동을 한 곳에서 모니터링 가능.

74.회사에서 데이터 저장을 위해 Amazon DynamoDB 테이블을 사용할 계획. 회사는 비용 최적화에 관심. 테이블은 대부분의 아침에 사용되지 않음. 저녁에는 읽기 및 쓰기 트래픽을 예측할 수 없는 경우가 많음. 트래픽 급증이 발생하면 매우 빠르게 발생. 솔루션 설계자는 무엇을 추천?

-> 온디맨드 용량 모드에서 DynamoDB 테이블 생성

75.회사가 최근 애플리케이션 마이그레이션 이니셔티브를 지원하기 위해 AWS MSP(Managed Service Provider)파트너와 계약을 체결. 솔루션 설계자는 기존 AWS 계정의 Amazon Machine Image(AMi)를 MSP파트너의 AWS 계쩡과 공유. AMI는 Amazon Elastic Block Store에서 지원하며 AWS KMS 고객 관리형 키를 사용하여 EBS 볼륨 스냅샷을 암호화. 솔루션 설계자가 AMI를 MSP 파트너의 AWS 계정과 공유할 수 있는 안전한 방법?

-> AMI의 launchPermission 속성을 수정. MSP 파트너의 AWS 계정과 AMI를 공유. MSP 파트너의 AWS 계정이 키를 사용할 수 있도록 키 정책을 수정.

76.AWS에 배포되는 새로운 애플리케이션을 위한 클라우드 아키텍처를 설걔. 프로세스는 처리할 작업 수에 따라 필요에 따라 애플리케이션 노드를 추가 및 제거하는 동안 병렬로 실행. 프로세서 애플리케이션은 상태 비저장. 솔루션 설걔자는 애플리케이션이 느슨하게 결합되고 작업 항목이 지속적으로 저장되는지 확인해야함. 어떤 디자인을 사용해야함?

-> 처리해야 할 작업을 보관할 Amazon SQS 대기열을 생성. 프로세서 애플리케이션으로 구성된 AMI를 생성. AMI를 사용하는 시작 템플릿을 생성. 시작 템플릿을 사용하여 Auto Scaling 그룹을 생성. SQS 대기열의 항목 수에 따라 노드를 추가 및 제거하도록 Auto Scaling 그룹에 대한 조정 정책을 설정

77.AWS 클라우드에서 웹 애플리케이션을 호스팅. AWS Certificate Manager(ACM)로 가져온 인증서를 사용하도록 Elastic Load Balancer를 구성. 각 인증서가 만료되기 30일 전에 회사의 보안팀에 알려야 함. 요구사항을 충족하기 위해 무엇을 권장?

->30일 이내에 만료되는 모든 인증서를 감지하는 Amazon EventBridge(Amazon CloudWatch Events) 규칙을 생성. AWS Lambda 함수를 호출하도록 규칙을 구성. Amazon SNS를 통해 사용자 지정 알림을 보내도록 Lambda 함수를 구성

78.회사의 동적 웹 사이트는 미국의 온프레미스 서버를 사용하여 호스팅. 이 회사는 유럽에서 제품을 출시하고 있으며 새로운 유럽 사용자를 위해 사이트 로드 시간을 최적화하려고 함. 사이트의 백엔드는 미국에 남아 있어야 함. 이 제춤은 며칠 안에 출시되며 즉각적인 솔루션이 필요.

-> 온프레미스 서버를 가리키는 사용자 지정 오리진과 함께 Amazon CloudFront를 사용

오리진 : 원래 콘텐츠들이 있는 곳, 웹서버 호스팅이 되는 곳.S3, EC2

79.회사에서 기존 3계층 웹 아키텍처의 비용을 줄이고자 함. 웹, 애플리케이션 및 데이터베이스 서버는 개발, 테스트 및 프로덕션 환경을 위해 Amazon EC2 인스턴스에서 실행. EC2 인스턴스는 사용량이 많은 시간에 평균 30%의 CPU 사용률을 보이고 사용량이 적은 시간에는 10%의 CPU 사용률을 보임. 프로덕션 EC2인스턴스는 하루 24시간 실행. 개발 및 테스트 EC2 인스턴스는 매일 최소 8시간 동안 실행. 이 회사는 개발을 중지하고 사용하지 않는 EC2 인스턴스를 테스트하기 위해 자동화를 구현할 계획. 어떤 EC2인스턴스 구매 솔루션이 회사의 요구사항에 효율적일까?

-> 프로덕션 EC2 인스턴스에 예약 인스턴스를 사용. 개발 및 테스트 EC2 인스턴스에 온디맨드 인스턴스를 사용

80.회사에는 사용자가 웹 인터페이스 또는 모바일 앱을 통해 7문서를 업로드하는 프로덕션 웹 애플리케이션이 있음. 새로운 규제 요구 사항에 따라 새 문서는 저장된 후에 수정하거나 삭제할 수 없음. 요구사항을 충족하기 위한 방법은?

->S3 버전 관리 및 S3 객체 잠금이 활성화된 Amazon S3 버킷에 업로드된 문서를 저장.

2 - AWS Certified Solutions Architect Associate(SAA) 기출문제(21~50문제 정리)

defxyj — Sat, 13 Jan 2024 05:58:44 +0900

21.일부 파일은 자주 액세스되는 반면 다른 파일은 예측할 수 없는 패턴으로 거의 액세스되지 않음. 미디어 파일을 저장하고 검색하는 비용을 최소화하는 방법

-> S3 지능형 계층화 : 3개의 액세스 계층에 자동으로 저장. 한 계층은 빈도가 높은 액세스에 최적화되어 있고, 하나의 저렴한 계층은 빈도가 낮은 액세스에 최적화되어 있고, 또 다른 매우 저렴한 계층은 거의 액세스하지 않은 데이터에 최적화 되어 있음, 저렴한 월별 객체 모니터링 및 자동화 요금으로 액세스 패턴을 모니터링하고 연속 30일 동안 액세스하지 않은 객체를 Infrequent Access 계층으로 자동 이동, 90일 동안 액세스한 적이 없으며 성능 영향이나 운영 오버헤드 없이 객체가 Archive Instant Access 계층으로 이동.

22.EC2 인스턴스에 대한 인스턴스 유형의 원치 않는 수직확장을 발견, 최근 2개월간의 EC2 비용을 비교하는 그래프를 생성하고 심층 분석을 수행하여 수직 확장의 근본 원인을 식별

-> AWS Billing and Cost Management 대시보드의 그래프를 사용하여 지난 2개월 동안 인스턴스유형을 기준으로 비교

AWS Billing and Cost Management : 청구서를 지불하고 비용을 최적화 하는데 도움이 되는 기능.

23.AWS Lambda함수를 사용하여 API Gateway를 통해 정보를 수신하고 Amazon Aurora PostgreSQL 데이터베이스에 정보를 저장, 대량의 데이터를 처리하기 위해 Lambda 할당량을 크게 늘려야 함

-> 두 개의 Lambda 함수를 설정, 정보를 수신하도록 하나의 기능을 구성, 데이터베이스에 정보를 로드하도록 다른 기능을 구성, SQS 대기열을 사용하여 Lambda 함수를 통합

24.클라우드 배포를 검토하여 S3 버킷에 무단 구성 변경이 없는지 확인

-> 적절한 규칙으로 AWS Config를 사용

AWS Config

25.CloudWatch 대시보드에 애플리케이션 지표를 표시. 회사의 제품관리자는 이 대시보드에 정기적으로 액세스해야함. 근데 AWS 계정이 없음. 최소 권한 원칙에 따라 액세스 권한 제공하는 방법

-> CloudWatch 콘솔에서 대시보드를 공유. 제품 관리자의 이메일 주소를 입력하고 공유 단계를 완료, 제품 관리자에게 대시보드에 대한 공유 가능한 링크를 제공

최소 권한 원칙 : 관리 사용자를 만든 후 더 제한적인 권한 집합을 만들어 동일한 사용자에게 할당.ㅋ

26.AWS Organizations를 사용하여 중앙에서 계정을 관리. 회사의 보안 팀은 회사의 모든 계정에 대한 SSO 솔루션이 필요. 회사는 온프레미스 자체 관리 Microsoft Active Directory에서 사용자와 그룹을 계속 관리

-> AWS SSO 콘솔에서 SSO 활성화. Microsoft Active Directory용 AWS Directory Service를 사용하여 회사의 자체 관리형 Microsoft Active Directory 를 AWS SSO와 연결하는 양방향 포리스트 트러스트를 생성

SSO : AWS 계정과 비즈니스 애플리케이션에 대한 SSO 액세스 관리를 간소화하는 클라우드 기반 서비스. AWS 조직 내 모든 AWS 계정에 걸쳐 SSO 액세스 및 사용자 권한을 제어.
양방향 신뢰

27.UDP 연결을 사용하는 VoIP 서비스를 제공. Auto Scaling 그룹에서 실행되는 EC2 구성. 여러 AWS 지역에 배포됨. 회사는 지연시간이 가장 짧은 리전으로 사용자를 라우팅 해야함, 회사는 또한 리전 간에 자동화된 장애 조치 필요

-> NLB 및 연결된 대상 그룹을 배포, 대상 그룹을 Auto Scaling 그룹과 연결. 각 리전에서 NLB를 AWS Global Accelerator 엔드포인트로 사용

Global Accelerator : TCP,UDP와 같은 HTTP 및 비HTTP프로토콜
CloudFront : HTTP 프로토콜

28.성능 개선 도우미가 활성화된 MySQL DB 인스턴스용 범용 Amazon RDS에서 매월 리소스 집약적인 테스트를 실행. 테스트는 한달에 한번 48시간 동안 진행되며 데이터베이스를 사용하는 유일한 프로세스이다. 팀은 DB인스턴스의 컴퓨팅 및 메모리르 속성을 줄이지 않고 테스트 실행 비용을 줄이는 방법

-> 테스트가 완료되면 스냅샷을 생성. 필요한 경우 DB 인스턴스를 종료하고 스냅샷을 복원

29.AWS에서 웹 애플리케이션을 호승팅하는 회사는 모든 EC2 인스턴스를 보장하려고 합니다. RDS DB 인스턴스, RedShift 클러스터는 태그로 구성. 회사는 이 검사를 구성하고 운영하는 노력을 최소하하기를 원함.

-> Config 규칙을 사용하여 적절하게 태그가 지정되지 않은 리소스를 정의하고 감지

30.개발팀은 다른 팀에서 액세스할 웹 사이트를 호스팅해야 합니다. 웹사이트 콘텐츠는 HTML,CSS,클라이언트 측 Javascript 및 이미지로 구성. 웹사이트 호스팅에 가장 비용 효율적인 방법은 무엇입니까

-> S3 버킷을 생성하고 그곳에서 웹사이트를 호스팅

31.수십만 명의 사용자에게 서비스 제공. 수백만 건의 금융 거래 세부 정보를 다른 여러 내부 애플리케이션과 공유하기 위해 확장 가능한 실시간에 가까운 솔루션이 필요. 짧은 대기 시간 검색을 위해 문서 데이터 베이스에 저장되기 전에 민감한 데이터를 제거하기 위해 트랜잭션을 처리. 요구 사항을 충족하기 위해 무엇을 권장?

-> 트랜잭션 데이터를 Amazon Kinesis Data Streams로 스트리밍. AWS Lambda 통합을 사용하여 모든 트랜잭션에서 민감한 데이터를 제거한 다음 트랜잭션 데이터를 Amazon DynamoDB에 저장. 다른 애플리케이션은 Kinesis 데이터 스트림 외부에서 트랜잭션 데이터를 사용

Amazon Kinesis Data Streams : 대규모 데이터를 수집하고 처리. 데이터 레코드가 실시간으로 표시되며 처리된 레코드를 대시보드로 보거나, 알림을 생성하는데 사용하거나, 요금 및 광고 전략을 동적으로 변경하거나, 다른 레코드에 데이터를 보냄, 사용하는 일반적인 시나리오는 가속화된 로그 및 데이터 피드 인테이크 처리(로그 데이터 손실 방지), 실시간 측정치 및 보고, 실시간 데이터 분석, 복잡한 스트림 처리
데이터 레코드 : 저장되는 데이터의 단위
민감한 데이터 처리 : Lambda 사용
Amazon DynamoDB : 완전 관리형 NoSQL 데이터베이스 서비스로서 원활한 확장성과 함께 빠르고 예측가능한 성능을 제공. 원하는 양의 데이터를 저장 및 검색하고 어느 수준의 요청 트래픽도 처리할 수 있는 데이터베이스 테이블을 생성 가능. 온디맨드 백업 기능을 제공하여 전체 백업을 생성하여 장기간 유지 및 보관

32.AWS에서 다중계층 애플리케이션을 호스팅. 규정 준수, 거버넌스, 감사 및 보안을 위해 회사는 AWS 리소스에 대한 구성 변경을 추적하고 이러한 리소스에 대한 API 호출 기록을 기록

-> AWS Config를 사용하여 구성 변경을 추적하고 AWS CloudTrail을 사용하여 API 호출을 기록

AWS CloudTrail : AWS 계정의 운영 및 위험 감사, 거버넌스 및 규정 준수를 활성하는데 도움을 주는 서비스, 사용자, 역할 또는 AWS 서비스가 수행하는 작업은 CloudTrail에 이벤트로 기록

33.ELB 뒤에 있는 VPC 내의 EC2 인스턴스로 구성. 타사 서비스가 DNS에 사용됩니다. 회사의 솔루션 설계자는 대규모 DDoS 공격을 탐지하고 방어하는 솔루션을 추천

-> AWS Shield Advanced를 활성화하고 여기에 ELB를 할당

AWS Shield : DDoS(분산 서비스 거부) 공격에 대한 보호 기능, AWS Shield Advanced 추가적인 DDoS 탐지, 완화 및 대응 기능으로 보안 상태를 개선하는 관리형 위협 방지 서비스

34.애플리케이션은 두 AWS 리전의 Amazon S3 버킷에 데이터를 저장. 회사는 KMS 고객 관리형 키를 사용하여 S3 버킷에 저장된 모든 데이터를 암호화햏야 합니다. 두 S3 버킷의 데이터는 동일한 KMS 키로 암호화 및 암호 해독되어야 합니다. 데이터와 키는 두 지역 각각에 저장. 요구사항을 충족하는 솔루션은?

-> 고객 관리 다중 리전 KMS 키를 생성. 각 리전에서 S3 버킷을 생성. S3 버킷 간의 복제를 구성. 클라이언트 측 암호화와 함께 KMS키를 사용하도록 애플리케이션을 구성

다중 리전 키 관리 : 대부분의 작업에서 단일 리전 키를 사용하고 관리하는 것과 동일한 방식으로 다중 리전 키를 관리. 복제본 키 중 하나가 기본 키로 변경되고 현재 기본 키가 복제본으로 변경, 사용자가 기본 키에서만 자동 키 교체를 사용, 관련 기본 키 또는 복제본 키에서 비대칭 다중 리전 키를 위한 퍼블릭 키를 가져옴.

35.S3에 정적 웹사이트를 호스팅하고 DNS에 Route53을 사용. 웹사이트는 전 세계적으로 수요 증가. 웹사이트에 접속하는 사용자의 대기 시간을 줄여야 합니다. 충족하는 솔루션은?

-> S3 버킷 앞에 Amazon CloudFront 배표를 추가. CloudFront 배포를 가리키도록 Route53 항목을 편집

36.웹사이트에서 항목의 검색 가능한 저장소를 유지 관리. 데이터는 1000만개 이상의 행을 포함하는 RDS for MySQL 데이터베이스 테이블에 저장. 데이터베이스에는 2TB의 범용 SSD 스토리지가 있습니다. 회사 웹사이트를 통해 매일 이 데이터에 대한 수백만 건의 업데이트가 있음. 일부 삽입 작업이 10초이상 걸리는 것을 발견. 회사는 데이터베이스 스토리지 성능이 문제라고 판다. 해결하는 솔루션은?

-> 스토리지 유형을 프로비저닝된 IOPS SSD로 변경

RDS 스토리지 유형 :

37.회사에는 매일 총 1TB의 상태 알림을 생성하는 수천 개의 에지 장치가 있습니다. 각 알림의 크기는 약 2KB입니다. 솔루션 설계자는 향후 분석을 위해 경고를 수집하고 저장하는 솔루션을 구현해야 합니다.
회사는 고가용성 솔루션을 원합니다. 그러나 회사는 비용을 최소화해야 하며 추가 인프라를 관리하기를 원하지 않습니다. 또한 회사는 즉각적인 분석을 위해 14일간의 데이터를 유지하고 14일보다 오래된 모든 데이터를 보관하기를 원합니다.

->Amazon Kinesis Data Firehose 전송 스트림을 생성하여 알림을 수집합니다. Amazon S3 버킷에 알림을 전달하도록 Kinesis Data Firehose 스트림을 구성합니다. 14일 후에 데이터를 Amazon S3 Glacier로 전환하도록 S3 수명 주기 구성을 설정합니다.

Amazon Kinesis Data Firehose : 를 사용하면 애플리케이션을 작성하거나 리소스를 관리할 필요가 없음. Kinesis Data Firehose로 데이터를 전송하도록 데이터 생산자를 구성하면 지정한 대상으로 데이터가 자동으로 전송 및 전송 전 변환하도록 구성 가능
Kinesis Data Firehose 전송 스트림 : Kinesis Data Firehose는 Kinesis Data Firehose 전송 스트림을 만든 다음 전송 스트림을 생성하여 전송하여 Kinesis Data Firehose를 사용

38.애플리케이션은 데이터 수집을 위해 여러 SaaS 소스와 통합. EC2 인스턴스를 실행하여 데이터를 수신하고 분석을 위해 데이터를 S3 버킷에 업로드. 데이터를 수신하고 업로드하는 동일한 EC2 인스턴스도 업로드가 완료되면 사용자에게 알림을 보냄. 느린 응용프로그램 성능을 발견했으며 성능을 개선하고자 함. 요구에 충족하는 솔루션은?

-> 각 SaaS 소스와 S3 버킷 간에 데이터를 전송하는 Amazon AppFlow 흐름을 생성. S3 버킷에 대한 업로드가 완료되면 Amazon Simple Notification Service 주제로 이벤트를 보내도록 S3 이벤트 알림을 구성

Amazon AppFlow : SaaS 애플리케이션과 Amazon S3 및 Amazon Redshift와 같은 AWS 서비스 간에 안전하게 데이터를 교환할 수 있게 해주는 완전관리형 통합 서비스, 빠른 시작, 데이터 동기화 유지, 데이터 통합, 데이터 추적, 데이터 보안 유지, 데이터 비공개 전송, 검색 및 탐색을 위한 데이터 카탈로그화, 전송된 데이터를 파티션 및 파일 구성, 사용자 지정 커넥터 개발

39. 단일 VPC의 EC2 인스턴스에서 고가용성 이미지 처리 애플리케이션을 실행. EC2 인스턴스는 여러 가용 영역에 걸쳐 여러 서브넷내에서 실행. EC2 인스턴스는 서로 통신하지 않음. 그러나 EC2 인스턴스는 S3 에서 이미지를 다운로드하고 단일 NAT 게이트웨이를 통해 S3에 이미지를 업로드. 회사는 데이터 전송 요금에 대해 가장 효율적인 방법은?

-> S3 용 게이트웨이 VPC 엔드포인트를 배포

40.S3에 백업되는 대량의 시간에 민감한 데이터를 생성하는 온프레미스 애프릴케이션이 있음. 인터넷 대역폭 제한에 대한 사용자의 불만. S3에 적시에 백업하고 내부 사용자의 인터넷 연결에 미치는 영향을 최소화 하는 충족 방법?

-> 새로운 AWS Direct Connect 연결을 설정하고 이 새로운 연결을 통해 백업 트래픽을 전달

AWS Direct Connect : 를 사용하면 표준 이더넷 광섬유 케이블을 통해 내부 네트워크를 AWS Direct Connect 위치에 연결할 수 있음. 케이블의 한쪽 끝을 사용자의 라우터에 연결하고 다른 쪽 끝을 AWS Direct Connect 라우터에 연결. 이 연결을 통해 가상 인터페이스 퍼블릭 AWS 네트워크 경로에서 인터넷 서비스 공급자를 우회하여 S3 또는 VPC로 전송.

AWS Direct Connect 네트워크와 상호 작용

41.회사에는 중요한 데이터가 포함된 Amazon S3 버킷이 있음. 회사는 우발적인 삭제로부터 데이터를 보호. 요구 충족하는 행동?

-> S3 버킷에서 버전관리를 활성화, MFA 삭제를 활성화

S3 버킷 : Amazon S3에 저장된 객체에 대한 컨테이너, 버킷에 저장할 수 있는 객체 수에는 제한이 없음. ACL, 버킷정책 또는 둘다를 통해 버킷 및 객체에 퍼블릭 액세스 권한이 부여
S3 버전관리, 버킷에 버전관리, MFA Delete

42.새로운 데이터 전달에 대한 알림을위한 SNS 주제, 데이터 처리하고 메타 데이터를 기록하는 Lambda 함수 수집 워크플로가 실패하는 것을 회사에서 관찰. 때때로 네트워크 연결 문제로 인해, 이러한 실패가 발생하면 회사에서 수동으로 작업을 다시 실행하지 않는 한 Lambda 함수는 해당 데이터를 수집하지 않음. 모든 데이터를 수집하기 위한 작업은?

-> SQS 대기열을 생성하고 SNS 주제를 구독, SQS 대기열에서 읽도록 Lambda 함수를 수정

43.SFTP를 통해 거래 데이터를 회사에 업로드하고 데이터를 처리 및 분석하여 새로운 마케팅 제안을 생성. 일부 파일은 크기가 200GB를 초과할 수 있음. 최근 회사는 일부 매장에서 포함되어서는 안되는 개인 식별 정보(PII)가 포함된 파일을 업로드 한것을 발견. 회사는 PII가 다시 공유될 경우 관리자에게 알림을 받기를 원합니다. 회사는 문제 해결을 자동화하기를 원함.

-> S3 버킷을 안전한 전송 지점 사용, Amazon Macie를 사용하여 버킷의 객체를 스캔. 객체에 PII가 포함된 경우 Amazon SNS를 사용하여 관리자에게 PII가 포함된 객체를 제거하라는 알림을 트리거

Amazon Macie : 기계 학습과 패턴 매칭을 사용하여 민감한 데이터를 검색하고, 데이터 보안 위험에 대한 가시성을 제공하며, 이러한 위험에 대한 자동 보호를 지원하는 데이터 보안 서비스, 민감한 데이터의 검색 및 보고를 자동화하여 조직이 S3에 저장하는 데이터를 더 잘 이해하도록 함.

44.1주일 동안 지속되는 예정된 이벤트를 위해 특정 AWS 리전에 있는 3개의 특정 가용 영역에서 보장된 Amazon EC2 용량이 필요, 보장하기 위해 무엇을?

-> 필요한 리전 및 세 개의 가용 영역을 지정하는 온디맨드 용량 예약을 생성

온디맨드 인스턴스 : 시작하는 인스턴스에 대한 비용을 초 단위로 지불
예약 인스턴스 : 1년 또는 3년 기간 동안 인스턴스 유형 및 리전을 포함하여 일관된 인스턴스 구성을 약정하여 비용 절감
Savings Plans(절감형 플랜) : 1년 또는 3년 기간 동안 시간당 USD로 일관된 사용량을 약정하여 비용 절감
스팟 인스턴스 : 미사용 EC2 인스턴스를 요청하여 비용 대폭 절감
전용 호스트 : 인스턴스 실행을 전담하는 실제 호스트 비용을 지불
용량 예약 : 원하는 기간 동안 특정 가용영역의 EC2 인스턴스에 대한 예약

45.웹사이트는 항목 카탈로그에 EC2 인스턴스 스토어를 사용. 회사는 카탈로그의 가용성이 높고 카탈로그가 안정적인 위치에 저장되기를 원함.

-> 카탈로그를 Amazon EFS 파일 시스템으로 이동

Amazon EFS(내구성)
Amazon ElasticCache(메모리) : 클라우드에서 분산된 인메모리 데이터 스토어 또는 캐시 환경을 손쉽게 설정, 관리 및 확장할 수 있는 웹 서비스로 고성능 캐싱 솔루션 제공
Service Catalog : 를 사용하면 승인된 IT 서비스(AMI, 서버, 소프트웨어, 데이터베이스) 카탈로그를 생성하고 관리

46.월단위로 통화 기록 파일을 저장. 사용자는 통화 후 1년 이내에 임의로 파일에 액세스하지만 1년 후에는 드물게 파일에 액세스, 회사는 사용자에게 1년 미만의 파일을 가능한 한 빨리 쿼리하고 검색할 수 있는 기능을 제공하여 솔루션을 최적화, 이전 파일 검색 지연은 허용, 효율적인 솔루션은?

-> Amazon S3 Intelligent-Tiering 에 개별 파일을 저장. S3 수명 주기 정책을 사용하여 1년 후 파일을 S3 Glacier Flexible Retrieval로 이동, Amazon Athena를 사용하여 Amazon S3에 있는 파일을 쿼리하고검색, S3 Glacier Select를 사용하여 S3 Glacier에 있는 파일을 쿼리하고 검색

S3 Glacier Flexible Retrieval : 분 단위로 데이터 일부를 검색해야 하는 아카이브에 사용. 해당 클래스에 저장된 데이터는 최소 스토리지 기간이 90일이며, 신속 검색을 사용하여 최소 1~5분 이내에 액세스 함. 검색 시간은 유연하며 최대 5~12시간 내에 무료 대량 검색을 요청
S3 Glacier Instant Retrieval : 거의 액세스하지 않고 밀리초 단위로 검색해야 하는 데이터를 아카이브하는데 사용. 저장된 데이터는 S3 Stand-IA 스토리지 클래스와 동일한 대기 시간 및 처리량 성능으로 S3 Standard-IA 스토리지 클래스보다 비용을 절감
S3 Glacier Deep Archive : 거의 액세스 할 필요가 없는 데이터를 보관할 때 사용. 클래스에 저장된 데이터의 최소 스토리지 기간은 180일이고 기본 검색 시간은 12시간, 가장 저렴한 스토리지 옵션

47.회사에는 1000개의 Amazon EC2 Linux 인스턴스에서 실행되는 프로덕션 워크로드가 있음. 워크로드는 타사 소프트웨어로 구동, 회사는 중요한 보안 취약성을 수정하기 위해 가능한 빨리 모든 EC2 인스턴스에서 타사 소프트웨어를 패치해야 함, 요구사항에 충족하는 ?

-> AWS System Manager Run Command를 사용하여 패치를 모든 EC2인스턴스에 적용하는 사용자 지점 명령을 실행

AWS System Manager Run Command : 관리 노드의 구성을 원격으로 안전하게 관리. 일반적인 관리 작업을 자동화하고 대규모로 일회성 구성 변경을 수행, 애플리케이션을 설치 또는 부트스트랩하고, 배포 파이프라인을 구축하고, Auto Scaling 그룹에서 인스턴스가 제거될 때 로그 파일을 캡처하고, 인스턴스를 Windows 도메인에 가입시키는 등의 작업을 수행

48.REST API로 검색할 주문 배송 통계를 제공하는 애플리케이션을 개발, 회사는 배송 통계 추출하고 데이터를 읽기 쉬운 HTML 형식으로 구성하고 매일 아침 동시에 여러 이메일 주소로 보고서를 보내려고 함. 요구사항 충족방안?

-> Amazon SES를 사용하여 데이터 형식을 지정하고 이메일로 보고서를 보냄, 데이터에 대한 애플리케이션의 API를 쿼리하기 위해 AWS Lambda 함수를 호출하는 Amazon EventBridge(CloudWatch Events) 예약 이벤트를 생성

Amazon Simple Email Service : 디지털 마케터와 애플리케이션 개발자가 마케팅, 알림 및 트랜잭션 이메일을 보낼 수 있도록 설계된 클라우드 기반 이메일 전송 서비스, 이메일을 사용하여 고객과 연락하는 모든 규모의 기업을 위한 안정적이고 비용 효과적인 서비스.
Amazon EventBridge : 이벤트를 사용하여 애플리케이션 구성요소를 서로 연결하는 서버리스 서비스이므로 확장 가능한 이벤트 기반 애플리케이션을 쉽게 구축. 자체 개발 애플리케이션, AWS 서비스 및 타사 소프트웨어와 같은 소스의 이벤트를 조직 전체의 소비자 애플리케이션으로 라우팅. 이벤트를 수집, 필터링, 변환 및 전달하는 간단하고 일관된 방법을 제공하므로 새 애플리케이션을 빠르게 구축
Amazon CloudWatch Events : AWS 리소스의 변경 사항을 설명하는 시스템 이벤트의 스트림을 거의 실시간으로 전달. Amazon EventBridge는 이벤트를 관리하는데 선호되는 방법.

49.온프레미스 애플리케이션을 AWS로 마이그레이션하려고 함. 애플리케이션은 수십 기가바이트에서 수백 테라바이트에 이르는 다양한 크기의 출력 파일을 생성. 애플리케이션 데이터는 표준 파일 시스템 구조에 저장되어야 합니다. 회사는 자동으로 확장되는 솔루션을 원함. 가용성이 높고 최소한의 운영 오버헤드가 필요

-> 다중 AZ Auto Scaling 그룹의 EC2 인스턴스로 애플리케이션을 마이그레이션 합니다. 스토리지에 Amazon Elastic File System을 사용

50.회계기록을 Amazon S3에 저장. 기록은 1년 동안 즉시 액세스할수 있어야 하며 추가 9년동안 보관해야 함. 관리 사용자 및 루트, 사용자를 포함하여 회사의 그 누구도 전체 10년 기간 동안 레코드를 삭제할 수 없습니다. 기록은 최대한 탄력적으로 저장

-> S3 수명 주기 정책을 사용하여 1년 후 레코드를 S3 Standard에서 S3 Glacier Deep Archive로 전환. 10년 동안 규정 준수 모드에서 S3 객체 잠금을 사용.

S3수명 주기 정책 : 일정 시간이 지났을 때 사용되지 않는 파일들을 삭제하거나 다른 곳에 백업하여 S3 저장 공간을 절약할 수 있는 비용 효율적인 방법.
S3 Standard : 기본 스토리지 클래스, 객체를 업로드 할때 스토리지 클래스를 지정하지 않으면 S3가 해당 클래스를 할당
Reduced Redundancy : RRS 스토리지 클래스는 S3 Standard 스토리지 클래스보다 더 적은 중복성으로 저장될 수 있는 데이터 중에서도 중요하지 않고 재현 가능한 데이터를 목적으로 설계, 내구성 측면에서 객체 손실이 발생하므로 사용하지 않는 것이 좋음

1 - AWS Certified Solutions Architect Associate(SAA) 기출문제(1~20문제 정리)

defxyj — Sat, 13 Jan 2024 05:57:14 +0900

1.모든 글로벌 사이트의 데이터를 단일 S3 버킷에 집계 및 운영 복잡성을 최소화

-> 대상 S3 버킷에서 S3 Transfer Acceleration을 킴. 멀티파트 업로드를 사용하여 사이트 데이터를 대상 S3 버킷에 직접 업로드

S3 Transfer Acceleration : 클라이언트와 S3 버킷 간의 장거리 파일 전송을 파일을 빠르고 쉽고 안전하게 전송할 수 있는 버킷 기능. 전 세계에서 S3 버킷으로 전송 속도를 최적화. Amazon CloudFront에서 전 세계에 분산된 엣지 로케이션을 활용
사용하는 이유? : 전 세계 각지에서 중앙의 버킷으로 업로드하는 경우

2.로그파일을 분석하는 기능 필요, JSON 형식으로 저장, 쿼리는 간단하고 주문형, 최소한의 운영 오버헤드

-> S3와 함께 Athena를 직접 사용

Athena : 표준 SQL을 사용하여 S3에 있는 데이터를 직접 간편하게 분석할 수 있는 대화형 쿼리 서비스. 자동으로 확장되어 쿼리를 병렬로 실행하여 대규모 데이터 집합과 복잡한 쿼리에서도 빠르게 결과를 얻음.

3.S3 버킷에 대한 액세스를 AWS Organizations의 조직 내 계정 사용자로만 제한

-> 조직 ID에 대한 참조와 함께 aws PrincipalOrgID 전역조건 키를 S3 버킷 정책에 추가

AWS Organizations : 여러 AWS 계정을 생성하고 중앙에서 관리하는 조직으로 통합할 수 있는 계정 서비스, 조직의 계층적 구조를 구성하는 루트 및 OU, 조직의 멤버, 조직 내 다음 개체에 연결하는 정책, 조직 상태를 변경할 때 사용하는 핸드세이크에 대해 액세스 제어
aws:PrincipalOrgID : 리소스 기반 정책의 Principal 요소 지정을 간소화. 전역 키는 조직 내 모든 AWS 계정의 계정 ID를 전부 나열하는 대안을 제공. 조직의 멤버인 모든 계정을 나열하는 대신 Condition 요소에 조직 ID를 지정.

4.EC2 인스턴스는 인터넷 연결없이 S3 버킷에 액세스, 프라이빗 네트워크 연결 솔루션

-> S3 버킷에 대한 게이트웨이 VPC 엔드포인트를 생성

게이트웨이 VPC 엔드포인트 : VPC용 인터넷 게이트웨이 또는 NAT 디바이스가 없어도 Amazon S3 및 DynamoDB에 안정적인 연결을 제공
Gateway API : 규모와 관계없이 REST 및 WebSocket API를 생성, 게시, 유지, 모니터링 및 보호하기 위한 AWS 서비스, HTTP 기반, 상태비저장, 표준 HTTP 메서드를 구현

5.모든 문서를 한번에 볼수 있도록하기 위한 솔루션 설계

-> EBS 볼륨의 데이터를 Amazon EFS로 복사, 새 문서를 EFS에 저장하도록 수정

EBS : EC2 인스턴스에 사용할 수 있는 블록 수준 스토리지 볼륨, 인스턴스 수명에 관계없이 지속, 데이터에 빠르게 액세스하고 장기적으로 지속해야 하는 경우 사용하는 것이 좋음. 세분화된 업데이트가 필요하고 형식이 지정되지 않은 블록 수준의 원시 스토리지에 액세스해야 하는 파일 시스템, 데이터베이스 또는 애플리케이션의 기본 스토리지로 사용하기에 적합, 임의 읽기 및 쓰기에 의존하는 데이터베이스 스타일의 애플리케이션과 장시간의 지속적인 읽기 및 쓰기를 수행하는 처리량 집약적 애플리케이션에 모두 적합
EFS : 완전히 탄력적인 서버리스 파일 스토리지를 제공하므로 스토리지 용량 및 성능을 프로비저닝 하거나 관리하지 않고도 파일 데이터를 공유 가능. 애플리케이션에서 파일을 추가하고 제거 가능

6.최소한의 네트워크 대역폭을 사용하면서 마이그레이션

-> 온프레미스에 S3 파일 게이트웨이를 배포, S3 파일 게이트웨이에 연결할 공용 서비스 엔드포인트를 생성, S3 버킷을 생성, S3 File Gateway에서 새 NFS 파일 공유를 생성, 기존 NFS 파일 공유에서 S3 파일 게이트웨이로 데이터를 전송

S3 파일 게이트웨이 : AWS Storage Gateway는 온프레미스 소프트웨어 어플라이언스를 클라우드 기반 스토리지에 연결하여 데이터 보안 기능으로 온프레미스 환경과 AWS 스토리지 인프라, 서비스를 사용하여 데이터를 저장 가능

7.수신메시지 수집 애플리케이션, 확장성을 높이는 방법

-> 여러 SQS 구독이 있는 SNS에 메세지를 게시하여 대기열의 메시지를 처리

Amazon Kinesis Data Analytics : 스트리밍 소스에 대해 강력한 SQL 코드를 작성하고 실행하여 시계열 분석을 수행하고 실시간 대시보드를 제공하고, 실시간 지표를 생성
SQS : 내구력이 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공
SNS : 게시자에서 구독자(생산자, 소비자)로 메시지를 전송하는 관리형 서비스, 메시지를 전송하여 구독자와 비동기식으로 통신. 클라이언트는 SNS 주제를 구독하고 Amazon Kinesis Data Firehose, Amazon SQS, AWS Lambda, HTTP, 이메일, 모바일 푸시 알림 및 모바일 문자 메시지(SMS)와 같이 지원되는 엔드포인트 유형을 사용하여 게시된 메시지를 수신

8.자주 액세스되는 대용량 파일을 저장하는 파일서버, 7일 후에는 거의 액세스하지 않음, 짧은 대기 시간 액세스를 잃지 않고 스토리지 공간을 늘리는 솔루션

-> S3 File Gateway를 생성하여 스토리지 공간 확보,7일 후에 데이터를 S3 Glacier Deep Archive로 전환

S3 Glacier Deep Archive : 거의 액세스할 필요가 없는 데이터를 보관할 때 사용. 저장된 데이터의 최소 스토리지 기간은 180일이고 기본 검색 시간은 12시간. 가장 저렴한 스토리지 옵션

9.접수된 순서대로 처리되는 솔루션

-> SQS FIFO 대기열에 메시지를 전달하여 Lambda 함수를 호출하도록 구성

10.EC2 인스턴스는 파일에 로컬로 저장된 사용자이름 암호를 사용하여 데이터베이스 연결, 자격 증명 관리의 운영 오버헤드를 최소화하는 방법

-> AWS Secrets Manager를 사용

AWS Secrets Manager : 암호화된 보안 암호값을 런타임에 프로그래밍 방식으로 검색, 다른 유형의 보안 암호 저장, 보안 암호 데이터 암호화, 자동으로 보안 암호 교체, 완전 구성되고 바로 사용할 수 있는 교체 지원 기능을 갖춘 데이터베이스, 교체지원 기능을 갖춘 다른 서비스(Redshift, DocumentDB), 보안 암호에 대한 액세스 제어

11.정적 데이터 및 동적 데이터의 성능을 개선하고 대기 시간을 줄이려는데 Route 53에 등록된 자체 도메인 이름을 사용하는 방법

CloudFront : 정적 및 동적 웹 콘텐츠를 사용자에게 빠르게 배포하는 웹서비스, 엣지 로케이션이라고 하는 전 세계 데이터 센터 네트워크를 통해 콘텐츠를 제공, CloudFront에서 제공하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 짧은 엣지 롯케이션으로 요청이 라우팅되므로 콘텐츠가 가능한 최상의 성능을 제공
Global Accelerator : 사용자가 엑셀러레이터를 사용하여 로컬 및 글로벌 사용자를 위한 애플리케이션의 성능을 향상, 전 세계 사용자가 이용하는 인터넷 애플리케이션의 가용성을 향상, 글로벌 엑셀러레이터는 표준 가속기를 사용하여 AWS 글로벌 네트워크를 통한 트래픽을 클라이언트와 가장 까까운 리전의 엔드포인트로 보냄

12.여러 리전에서 RDS 데이터베이스에 대한 자격증명 교체 방법

-> 자격 증명을 AWS Secrets Manager에 비밀로 저장, 필요한 리전에 대해 다중 리전 비밀 복제를 사용, 일정에 따라 비밀을 교체하도록 Secrets Manager 구성

Secrets Manager

13.EC2 인스턴스에 호스팅 되는 MySQL 데이터베이스에 트랜잭션 데이터를 저장, 애플리케이션 로드가 증가하면 데이터베이스 성능이 빠르게 저하, 쓰기 트랜잭션보다 더 많은 읽기 요청을 처리, 가용성을 유지하면서 예측할 수 없는 읽기 워크로드의 수요를 충족하기 위해 데이터베이스를 자동으로 확장하는 솔루션은?

-> 다중 AZ 배포와 함께 Aurora 사용, Aurora 복제본으로 Auto Scaling 구성

Aurora : MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진, 일부 워크로드의 경우 Aurora은 기존 애플리케이션을 거의 변경하지 않고도 MySQL의 처리량을 최대 5배, PostgreSQL의 처리량을 최대 3배 제공. 고성능 스토리지 하위시스템이 포함, 기본 스토리지는 필요에 따라 자동으로 커짐, 데이터베이스 클러스터링 및 복제를 자동화하고 표준화

14.검사 서버는 트래픽 흐름 검사 및 트래픽 필터링을 수행, 동일한 기능을 수행하는 AWS 클라우드 기능을 솔루션

-> AWS Network Firewall을 사용하여 프로덕션 VPC에 대한 트래픽 검사 및 트래픽 필터링에 필요한 규칙을 생성

Network Firewall : VPC 경계에서 네트워크 트래픽을 필터링, 상태를 저장하는 관리형 네트워크 방화벽이자, 침입 탐지 및 방지 서비스

15.데이터 시각화를 제공하고 데이터 레이크 내의 모든 데이터 소스를 포함하는 보고 솔루션이 필요, 관리 팀만 모든 시각화에 대한 전체 액세스 권한을 가져야함

-> Amazon QuickSight에서 분석을 생성, 모든 데이터 소스를 연결하고 새 데이터 세트를 만듬, 대시보드를 게시하여 데이터를 시각화, 적절한 사용자 및 그룹과 대시보드를 공유

QuickSight : 어디에 있든 함께 일하는 사람들에게 easy-to-understand 통찰력을 제공하는 데 사용할 수 있는 클라우드급 비즈니스 인텔리전스 서비스, 조직 구성원들은 매일 비즈니스에 영향을 미치는 결정을 내리기 위한 정보를 확보

16.EC2 에서 문서 저장을 위해 S3 버킷을 사용, 액세스 할 수 있는지 확인하는 방법

-> S3 버킷에 대한 액세스 권한을 부여하는 IAM 역할 생성, 역할을 연결

IAM 역할 : 계정에 생성할 수 있는 특정 권한을 지닌 IAM 자격증명
버킷 정책 : 적절한 권한을 가진 사용자만 객체에 액세스할 수 있도록 하여 버킷의 객체 액세스를 보호

17.이미지를 자동으로 처리하기 위해 내구성있고 상태 비저장구성요소를 사용하는 솔루션은?

->SQS 대기열 생성하여 이미지가 S3 버킷에 업로드 되도록 구성, 대기열을 호출 소스로 사용하도록 Lambda 함수를 구성, 성공적으로 처리되면 삭제

Lambda : 서버를 프로비저닝하거나 관리하지 않고도 코드를 실행할 수 있게 해주는 컴퓨팅 서비스, 파일처리, 스트림 처리, 웹 애플리케이션, IoT 백엔드, 모바일 백엔드에 사용, Lambda를 사용하면 사용자는 자신의 코드에 대해서만 책임을 갖음

18.트래픽이 웹서버에 도달하기 전에 애플리케이션에 대한 모든 트래픽을 검사하기 위해 웹애플리케이션을 어플라이언스와 통합하는 최소한의 운영오버헤드로 충족하는 솔루션?

-> 애플리케이션 VPC의 퍼블릭 서브넷에 ALB를 생성하여 패킷검사를 위해 트래픽을 어플라이언스로 라우팅

19.대량의 생산 데이터를 동일한 리전의 테스트 환경으로 복제하는 기능을 개선. 데이터에 액세스하는 소프트웨어에는 지속적으로 높은 I/O 성능이 필요. 프로덕션 데이터를 테스트 환경으로 복제하는 필요한 시간을 최소화하는 방법?

-> 프로덕션 EBS 볼륨의 스냅샷을 찍음과 복원기능을 사용하여 복원하고, 테스트환경에 새 EBS 볼륨을 EC2 인스턴스에 연결

EBS 스냅샷 : 지정 시간 스냅샷을 만들어 S3에 EBS 볼륨의 데이터를 백업 가능, 스냅샷을 만드는데 필요한 시간이 최소화되며 데이터를 복제하지 않으므로 스토리지 비용이 절약

20.사용량이 많은 시간에 밀리초 대기 시간으로 시간당 수백만 건의 요청을 처리할 수 있는 환경

-> S3 버킷을 사용하여 웹사이트의 정적 콘텐츠를 호스팅, CloudFront 배포, S3 버킷 오리진으로 설정, 백엔드 API에 API Gateway 및 Lambda 함수를 사용, DynamoDB에 데이터 저장

멀티탭코딩

[Redis] 1. 대용량 트래픽 처리를 위한 Redis & AWS ElastiCache 완벽 정리 (아키텍처, 캐시전략, 명령어)

목차

1. 핵심 개념: Redis와 AWS ElastiCache

1.1 Redis (Remote Dictionary Server)

1.2 AWS ElastiCache

2. 캐시 전략 (Caching Strategies)

2.1 읽기 전략 (Read Patterns)

2.2 쓰기 전략 (Write Patterns)

3. 확장 및 공유 전략 (Scale & Share)

4. 실무 구현 기술 (Java/Spring 심화)

5. 대용량 트래픽 문제 해결 (Troubleshooting)

해결책: PER (Probabilistic Early Recomputation) 알고리즘

6. 필수 Redis 명령어 모음 (완벽 정리)

1) Key 관리 (공통)

2) String (문자열 - 1:1 구조)

3) Hash (해시 - 객체 저장)

4) Set (집합 - 중복 제거)

5) Sorted Set (ZSet - 정렬된 집합)

3) 운영 및 모니터링 (CLI)

Spring JPA 영속성 컨텍스트(Persistence Context), EntityManager,

1. 영속성 컨텍스트 (Persistence Context)

2. 엔티티 매니저(EntityManager)

3. 엔티티 매니저 팩토리 (EntityManagerFactory)

4. 엔티티 매니저 팩토리와 엔티티 매니저 전체 흐름

5. 쓰레드 안정성 (Thread-Safety)

6. 변경 감지(Dirty Checking)

7. 동시성 제어 (Concurrency Control)

[CloudFront, S3] CloudFront CDN 퍼블릭 정적 웹 호스팅

정적 웹 호스팅

1. S3 버킷 생성 후 파일 업로드

2. 버킷 속성 정적 웹 호스팅 설정

3. CloudFront CDN 사용

3. 대체 도메인을으로 접근

[NACL] 퍼블릭 과 프라이빗 구성 아키텍처(SG & NACL)

퍼블릭과 프라이빗 구성 아키텍처

아키텍처 예시

SG 와 NACL

[CloudWatch] AutoScaling 동적 조정과 CloudWatch 연동

AutoScaling 동적 조정과 CloudWatch 연동

1. 동적 크기 조정 정책 생성

2. CloudWatch 지표 생성

3. Auto Scale In 동적 크기 조정 정책 생성

4. SNS 알림 확인

[EC2] EC2 Auto Scailing 해보기

EC2 Auto Scailing 해보기

1. EC2 CPU 사용량 확인해보기

2. 사전에 EC2 AMI 만들기

3. 생성한 AMI로 EC2 템플릿 만들기

4. Auto Scaling Group 만들기

5. 생성 확인

[CloudShell] CloudShell 업로드 기능으로 .tar 압축파일 업로드로 Index 파일 변경

CloudShell 업로드 기능

1. CloudShell 에서 .tar 파일 업로드

2. CloudShell -> EC2 서버로 파일 복사

3. httpd 웹서버의 index파일 변경 확인

[ALB] 로드밸런서와 HTTPS 사용

Classic Load Balancer

1. CLB 로드밸런서 생성

2. VPC와 AZ 선택

3. SG와 리스너와 인스턴스 설정

4. SSL 인증서 설정

5. 생성 후 DNS로 정상 동작 확인(CLB - Round-Robin 방식)

Network Load Balancer

5. 동작 확인(Hash 방식)

Application Load Balancer

1. 생성

2. 상태 체크를 위한 80, 443 포트 사용

3. HTTPS 포트 및 대상 그룹 설정

4. 레코드 설정

5. 동작 확인

[ACM] 인증서(Certificate Manager) 만들어서 HTTPS 사용해보기

1. 생성

2. *.humbacktest.shop 와일드 카드 입력하여 서브도메인을 전부 적용하게 적용

3. cname 생성(해당 도메인에 대한 소유권)

4. 인증서에 대한 사용과 갱신 자격이 필요!

[RDS] EC2 서버에서 RDS 접근

[RDS] RDS 생성해보기

1. 데이터베이스 선택

2. 마스터 계정과 암호 설정