꾸준히 성장하는 개발자스토리

AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 실습

묠니르묘묘 — Tue, 22 Oct 2024 01:58:08 +0900

AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 이론
AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 실습

1. 아키텍처 개요

AWS 핵심 서비스로 웹 애플리케이션 아키텍처 기본 설계

이번 실습으로 AWS 기본이 되는 컴퓨팅 서비스인 EC2 를 이용한 웹 애플리케이션을 구축한다.

트래픽이 들어오면 로드 밸런서로 요청을 분산시켜 여러 EC2에 부하를 줄이도록 한다.

최종 아키텍처 설계

이후 모니터링과 오토스케일링, 정적 웹 사이트 호스팅을 추가로 사용하도록 한다.

2. 네트워크 구성하기

2-1. VPC 생성하기

1. VPC 마법사 시작을 클릭하여 VPC 구성을 쉽게 한다.

2. VPC 설정에서 아래 사진처럼 선택한다. 이름은 VPC-Lab , CIDR 블록은 기본값인 10.0.0.0/16 으로 설정

3. 가용영역(AZ)는 1개를 선택하고, 가용영역은 ap-northeast-2a 로 선택한다. 이 가용영역은 아까 설정했던 VPC의 부분집합이다. 밑에 있는 퍼블릭 서브넷 수도 1개로 선택하고, CIDR 블록을 10.0.10.0/24 로 설정한다. 프라이빗 서브넷은 만들지 않으므로 0개를 선택하고 생성한다.

4. VPC 이름을 아래 사진처럼 변경한다.

5. 서브넷 이름도 public subnet A 로 변경한다.

6. 현재까지의 아키텍처 구성은 아래와 같다.

2-2. 추가 서브넷 생성하기

고가용성을 확보하기 위해 다중 가용 영역에 서비스를 배포하는 것이 중요하다. 따라서 기존에 생성한 가용영역A 외에 다른 가용영역 C에 서브넷을 생성해본다.

1. 왼쪽 사이드 바에서 서브넷 메뉴를 클릭하여 서브넷 생성을 한다.

2. VPC ID에는 방금 생성한 VPC 선택

3. 아래 사진처럼 설정한 후 서브넷 생성 클릭

4. 현재까지 아키텍처 구조

2-3. 라우팅 테이블 편집하기

라우팅 테이블에는 서브넷 또는 게이트웨이의 네트워크 트래픽이 전송되는 위치를 결정하는데 사용되는 라우팅이라는 규칙 집합이 포함되어 있다.

기본 라우팅 테이블
- VPC와 함께 자동으로 생성되는 라우팅 테이블
- 다른 라우팅 테이블과 명시적으로 연결되지 않은 모든 서브넷의 라우팅을 제어하는 역할
사용자 지정 라우팅 테이블
- 기본 라우팅 테이블 외에 사용자가 생성한 라우팅 테이블

1. 서브넷 메뉴에서 작업 버튼 클릭 후, 라우팅 테이블 연결 편집 선택

2. 라우팅 테이블 ID에서 기본 라우팅 테이블이 아닌 다른 라우팅 테이블 선택 후 저장한다. 이때, 선택한 라우팅 테이블에 인터넷으로 향하는 경로가 있는지 확인한다.

3. public subnet C 선택 후, 세부 정보 탭에서 변경된 라우팅 테이블 하이퍼 링크를 클릭하면 라우팅 정보 확인 가능

4. 현재까지 아키텍처 구성

2-4. 보안그룹 생성하기

보안 그룹은 인스턴스에 대한 인바운드 및 아운바운드 트래픽을 제어하는 가상 방화벽 역할을 함

1. 왼쪽 사이드바에서 보안그룹 메뉴 클릭 후, 보안 그룹 생성 버튼 클릭

2. 아래 사진처럼 보안 그룹 및 설명 입력 후, 아까 생성한 VPC 선택

3. 인바운드 규칙에서 아래 사진처럼 규칙 부여 후, 보안 그룹 생성 버튼 클릭

3. 웹 서버 생성하기

EC2는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량 제공함
EC2 사용 시, 하드웨어 선 투자할 필요가 없어 빠른 개발 및 배포 가능
원하는 만큼 가상 서버 구축하고 보안 및 네트워크 구성과 스토리지 관리 가능
EC2는 트래픽 증가와 변동 사항에도 신속하게 규모 확장 및 축소 가능하여 서버 트래픽 예측 필요성이 줄어듦

3-1. 웹 서버 인스턴스 생성하기

인스턴스는 아래 단계를 통해 생성된다.

AMI 선택
인스턴스 유형 선택
인스턴스 구성
스토리지 추가
태그 추가
보안 그룹 구성
검토

1. EC2 콘솔홈에서 인스턴스 시작을 클릭하고, 이름에 webserver 1 입력

추가 태그 추가라는 것은 AWS 리소스에는 태그 형태로 메타 데이터를 지정할 수 있다. 태그를 사용하면 리소스를 쉽게 관리, 식별, 정리, 검색 및 필터링을 할 수 있다. 태그를 생성하여 용도, 소유자, 환경 또는 기타 기준으로 리소스를 분류할 수 있다.

2. 애플리케이션 및 OS 이미지에서는 Quick Start 에서 아래와 같이 선택

3. 인스턴스 유형은 t2.micro 선택

4. 키 페어에서는 새 키 페어 생성을 선택하여 아래와 같이 키 페어를 생성한다

5. 네트워크 설정에서 편집 버튼을 클릭하고 VPC와 서브넷, 퍼블릭 IP 자동 할당 세션에 다음 값을 입력

6. 방화벽(보안 그룹)은 기존 보안 그룹 선택하여 아까 생성한 그룹을 선택

7. 스토리지 구성에서는 기본 값인 8 GiB gp2 설정

8. 고급 세부 정보를 펼쳐서 가장 아래로 스크롤 하면 사용자 데이터가 보인다. 그 칸에 아래 내용을 붙여넣는다.

#!/bin/sh
        
# Install a LAMP stack
sudo amazon-linux-extras install -y lamp-mariadb10.2-php7.2 php7.2
sudo yum -y install httpd php-mbstring
sudo yum -y install git
        
# Start the web server
sudo chkconfig httpd on
sudo systemctl start httpd
        
# Install the web pages for our lab
if [ ! -f /var/www/html/aws-boarding-pass-webapp.tar.gz ]; then
    cd /var/www/html
    wget -O 'techcamp-webapp-2024.zip' 'https://ws-assets-prod-iad-r-icn-ced060f0d38bc0b0.s3.ap-northeast-2.amazonaws.com/600420b7-5c4c-498f-9b80-bc7798963ba3/techcamp-webapp-2024.zip'
    unzip techcamp-webapp-2024.zip
    sudo mv techcamp-webapp-2024/* .
    sudo rm -rf techcamp-webapp-2024
    sudo rm -rf techcamp-webapp-2024.zip
fi
        
# Install the AWS SDK for PHP
if [ ! -f /var/www/html/aws.zip ]; then
    cd /var/www/html
    sudo mkdir vendor
    cd vendor
    sudo wget https://docs.aws.amazon.com/aws-sdk-php/v3/download/aws.zip
    sudo unzip aws.zip
fi
        
# Update existing packages
sudo yum -y update

9. 이제 인스턴스를 시작하고 인스턴스 상태가 실행중으로 된다면 퍼블릭 IP 주소를 브라우저로 켜보면 아래 화면이 나온다.

10. 현재까지 아키텍처 구조

3-2. AMI 생성하기

Amazon Machine Image(AMI)는 인스턴스를 시작하는데 필요한 정보 제공
인스턴스 시작 시, AMI를 지정해야하는데 동일한 구성의 인스턴스가 여러 개 필요할 때는 한 AMI를 사용하여 여러 인스턴스 시작 가능

1. 앞서 생성한 인스턴스를 클릭하고 작업 메뉴에서 이미지 및 템플릿 클릭하고 이미지 생성을 클릭한다

2. 이미지 생성 페이지에서 아래와 같이 값(webserver-ami) 입력하고 우측 하단의 이미지 생성 버튼 클릭

3. 왼쪽 사이드 바에서 AMI 메뉴 클릭 후, 방금 생성한 이미지 확인

4. 현재까지 아키텍처 구성

3-3. AMI 기반 인스턴스 생성하기

1. AMI 메뉴에서 상태 변경이 완료되면 AMI로 인스턴스 시작 버튼 클릭

2. 이름 및 태그에 이름을 webserver 2 로 지정

3. 키 페어(로그인)에서 예전에 생성한 키 페어인 keypair-seoul 로 지정

4. 네트워크 설정에서 편집 클릭 후, 아래와 같이 값 입력하고 인스턴스 시작 버튼 클릭

5. 왼쪽 사이드 바에서 인스턴스 메뉴를 클릭하고 방금 생성한 webserver 2 퍼블릭 IP 주소를 복사하여 웹 브라우저에 붙여 넣으면 아래 그림이 나온다

6. 현재까지 아키텍처 구성

4. 로드밸런서 구성하기

Elastic Load Balancing(ELB)는 들어오는 애플리케이션 트래픽을 Amazon EC2 인스턴스, 컨테이너, IP 주소, Lambda 함수, 가상 어플라이언스와 같은 여러 대상에 자동으로 분산시킨다
단일 가용 영역 또는 여러 가용 영역에서 다양한 애플리케이션 부하를 처리할 수 있다
ELB가 제공하는 네 가지 로드 밸런서는 모두 애플리케이션의 내결함성에 필요한 고가용성, 자동 조정, 강력한 보안을 갖춤
- Application Load Balancer
- Network Load Balancer
- Gateway Load Balancer
- Classic Load Balancer

1. 왼쪽 사이드 바에서 로드 밸런서 클릭 후, 생성 버튼 클릭

2. Load Balancer 유형 중 Application Load Balancer 선택

3. Load Balancer 구성에서 아래와 같이 값을 입력한 후, 스크롤 내림

리스너는 연결 요청을 확인하는 프로세스이다. 리스너는 프로토콜 및 포트로 구성되며 로드밸런서의 앞단과 뒷단을 연결하는 역할을 한다.

4. VPC에서는 생성했던 VPC-Lab 선택하고 매핑 항목에서는 public subent A와 public subnet C 선택한다. 해당 작업은 로드밸런서에서 트래픽을 라우팅할 VPC와 가용 영역을 지정하는 작업이다.

5. 보안 그룹에서 새 보안 그룹 생성 버튼을 클릭하여 아래와 같이 값 입력하고 보안 그룹을 생성한다

6. 다시 로드 밸런서 화면으로 돌아와서 방금 만든 보안 그룹으로 지정한다

7. 리스너 및 라우팅에서 대상 그룹 생성 버튼을 클릭

8. 대상 유형 선택에는 인스턴스를 선택하고 대상 그룹 이름은 webserver-tg 로 지정한다. 프로토콜은 HTTP로 선택한다

9. VPC에는 생성했던 VPC 지정하고 대상 등록에 보이는 두 개의 인스턴스를 아래에 보류중인 것으로 포함 버튼을 통해 대상으로 등록한다

10. 대상 그룹이 생성되면 로드 밸런서 화면으로 돌아와 리스너 및 라우팅에서 대상 그룹으로 지정하고 이후 로드밸런서를 생성한다

11. 로드밸런서를 통하여 웹 애플리케이션에 접근하기 전에 생성했었던 웹 서버가 로드 밸런서의 트래픽만 받게 하기 위하여 보안 그룹 인바운드 규칙을 편집한다. 보안 그룹 메뉴에서 webserver-sg 보안 그룹 선택하여 편집을 한다.

12. 로드밸런서 메뉴로 들어가 방금 생성한 로드밸런서의 DNS이름을 웹 브라우저에 붙여넣으면 아래와 같이 나온다.

로드밸런서 웹 페이지를 새로고침하면 Application Load Balancer에서 기본으로 제공하는 라운드 로빈 알고리즘에 따라 InstanceID, Availabilty Zone 값이 변경되는 것을 확인할 수 있다.

13. 현재까지 아키텍처 구성

AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 이론

묠니르묘묘 — Sun, 6 Oct 2024 23:47:07 +0900

AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 이론
AWS 핵심 서비스로 웹 애플리케이션 구축하기 - 실습

이번 실습으로 아래 아키텍처 설계에 따른 인프라 구축을 해본다.

그 전에 이론 부분들을 살펴보자

최종 아키텍처 구조

1. AWS Region (리전)

전세계에 AWS 데이터센터가 클러스터 형태로 위치한 물리적 위치
1개의 리전은 고가용성, 확장성, 내결함성을 위해 3개 이상의 AZ로 구성

AWS Region, AZ

2. Availability Zones (가용영역, AZ)

모든 AWS Region은 지리적 영역 내에서 격리되고 물리적으로 분리된 최소 3개의 AZ로 구성
모든 가용 영역은 AWS 리전의 중복 전력, 네트워크 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성
AZ 간에는 높은 대역폭, 10ms 이하 짧은 지연시간의 네트워크로 구성
AZ 간 모든 트래픽 암호화
모든 AZ는 서로 100km 이내 거리 위치

AWS Region, AZ

3. Amazon VPC

Virtual Private Cloud
사용자가 정의한 논리적으로 격리된 가상의 프리이빗 네트워크 환경
간단한 구성만으로도 AWS의 확장 가능한 인프라를 기존 데이터센터 환경과 유사하게 사용

Amazon VPC

3-1. Amazon VPC 구성

Amazon VPC 구성

1. VPC 생성할 리전 선택하고 IP 주소 범위 설정

2. 하나의 큰 VPC를 용도에 맞게 퍼블릭 서브넷과 프라이빗 서브넷으로 쪼갬

3. 인터넷과의 통신을 위해 설정

4. 라우팅 테이블 규칙을 설정하여 해당 VPC 내의 트래픽 경로 제어

5. 방화벽 설정하여 접속이 허용된 요청만 접속되도록 네트워크 보호

위 5가지 단계로 VPC를 구성할 수 있음

3-2. IP 주소 범위 설정

IP 주소 범위 설정

CIDR 블록 설정
- Classless Inter-Domain Routing
- IP 대역의 시작 주소와 크기(넷마스크)를 정의
RFC 1918의 사설 IP 대역 사용 권고
- 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8
VPC의 네트워크 범위는 /16 ~ /28까지 가능
CIDR는 생성 후 변경 불가능
향후 직접 연결할 가능성이 있는 네트워크와 주소가 중복되지 않도록 할당 권고
- On0premises network와 연동 고려
- AWS 내 리전 간 확장

3-3. 서브넷 정의

서브넷 정의

네트워크를 잘라서 만든 작은 범위의 네트워크 대역을 의미함
용도에 따른 분리
- A 서비스, B 서비스 ...
여러 가용영역 배포
- 고가용성 확보
- AWS가 예약한 IP 주소들
  - 10.0.0.0 (네트워크 주소)
  - 10.0.0.1 (VPC 라우터)
  - 10.0.0.2 (DNS 용)
  - 10.0.0.3 (향후 대비용)
  - 10.0.0.255 (브로드캐스트 주소)

3-4. Internet Gateway 설정

Internet Gateway 설정

외부에 있는 인터넷과 AWS 내부간에 통신을 하기 위한 연결 통로

3-5. 라우팅 테이블 구성 - 로컬 통신

라우팅 테이블에서는 실제 VPC 내의 트래픽이 어떤 경로로 이동하게되는지 구성하게 됨
라우팅 테이블은 서브넷마다 개별적으로 연결 가능
명시적으로 연결하지 않을 경우 로컬 통신만 가능한 기본 라우팅 테이블로 연결
라우팅 테이블 규칙은 Destination, Target 으로 구성되며 패킷이 이동할 때마다 Destination 과 일치하는 Target으로 이동
Destination은 최종 목적지를 의미하며, Target은 패킷을 보낼 곳을 정의

3-6. 라우팅 테이블 구성 - 인터넷 통신

라우팅 테이블에서 Target을 인터넷 게이트웨이로 설정하면 해당 트래픽은 외부 인터넷으로 나갈 수 있음
사진에서 1.2.3.4 패킷은 인터넷 게이트웨이를 거쳐 외부 인터넷으로 나감
만약 10.0.1.1 로 패킷을 보내면 2개의 Destination에 충족하는데, 이 때는 가장 긴 접두사 매치를 따르게 됨
- 즉, 가장 구체적인 범위를 선택하여 포워딩한다는 의미로 local로 라우팅이 됨

3-7. 퍼블릿 서브넷과 프라이빗 서브넷

라우팅 테이블 설정에 따라서 인터넷 게이트웨이를 통하여 외부 통신이 가능한 서브넷은 퍼블릭 서브넷이고, 그렇지 않으면 프라이빗 서브넷으로 분류
외부 사용자가 접근해야하면 퍼블릭 서브넷, DB처럼 외부 사용자가 접근 못하면 프라이빗 서브넷
- 라우팅 테이블을 활용하여 간단히 망분리 환경 구성 가능

3-8. 퍼블릭 서브넷 (Public Subnet)

퍼블릭 서브넷에 EC2 구성하면 Public IP 부여받을 수 있음
인터넷과 통신은 VPC의 인터넷 게이트웨이
인터넷으로 라우팅은 라우팅 테이블로 설정
인터넷 통신은 필요한데 그 외의 통신은 원치 않을 때는 프라이빗 서브넷을 사용

3-9. 프라이빗 서브넷 (Private Subnet)

Private IP 주소만 사용하고 Public IP 주소가 필요 없음
프라이빗 리소스는 Public IP 주소가 없기에 인터넷 사용을 위해 NAT 게이트웨이 필요
NAT 게이트웨이는 원웨이 아웃 지원
- VPC 안의 리소스로부터 인터넷으로 나가는 아웃바운드 트래픽은 허용
- 인터넷으로부터 VPC 안의 리소스로 들어오는 인바운드 트래픽은 오직 요청에 의한 응답만 허용
- 인터넷에서 VPC 로 요청을 보내 NAT 게이트웨이를 거치려고 하면 실패
퍼블릭 서브넷과 프라이빗 서브넷으로 아웃바운드 인터넷 액세스 구현이 가능함

3-10. VPC 액세스 제어 : NACL 과 보안그룹

VPC에서 액세스를 제어하는 방법

로컬과 인터넷 통신이 가능하다면 보안의 관점에서 VPC 리소스에 대한 액세스를 제어해야 함
서브넷 단위로 제어하는 NACL(낫클), 인스턴스 단위로 트래픽 제어하는 보안그룹
NACL에서 허용한 트래픽이 보안그룹에 허용되지 않으면 인스턴스 접근 불가능
두 가지를 같이 사용하여 두 개의 방화벽 레이어로 애플리케이션 보호 가능

4. Amazon EC2

다양한 EC2와 구매 옵션을 제공하기에 사용자의 환경에 맞춰 사용 가능

4-1. EC2 호스트 가상화

EC2는 Virtual Machine 환경
AWS 글로벌 리전에 위치한 각각의 물리적 호스트 위에 하이퍼바이저를 통해 게스트 OS로써 EC2 인스턴스가 동작
EC2 인스턴스를 사용하기 위해서는 AMI에 대해 알아야 함

4-2. Amazon Machine Image (AMI)

인스턴스 시작에 필요한 정보 제공
동일한 구성으로 한 AMI에서 여러 인스턴스 시작
AMI는 다음을 포함
- 1개 이상의 Amazon Elastic Block Store (Amazon EBS) 스냅샷 또는 루트 볼륨에 대한 템플릿(운영 체제, 애플리케이션)
- AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한
- 인스턴스에 연결할 볼륨을 지정하는 블록 디바이스 매핑

4-3. 인스턴스 유형

EC2 인스턴스 유형

4-4. 인스턴스 유형 네이밍

인스턴스 유형 네이밍

4-5. Elastic Load Balancing

4-6. Amazon EC2 Auto Scaling

ELB와 같이 사용되는 서비스 중에 EC2 Auto Scaling이 있음
인스턴스가 비정상 상태일 때 해당 인스턴스 종료하고 새 인스턴스 시작하는 역할
트래픽 사용량을 통해 자동 확장하거나 축소하는 역할
인스턴스가 낭비되지 않게 탄력적으로 사용
변화하는 수요에 동적으로 대응하고 비용 최적화
인스턴스 시작 시 필요한 정보를 제공해줘야 하는데 이 정보를 시작 템플릿에 담아 오토스케일링에 전달

4-7. 시작 템플릿 (Launch Template)

시작(launch)을 간소화하고 단순화하기 위해 시작 요청을 템플릿화
오토스케일링이 시작 템플릿을 기반으로 새 인스턴스 시작
웹 애플리케이션을 시작할 때 필요한 구성들을 시작 템플릿에 저장하고 운영 가능
수정 사항 생기면 버전 관리 쉽게 가능

AWS Serverless(서버리스)로 서버 고민 없이 웹 애플리케이션 구축하기 #2

묠니르묘묘 — Mon, 9 Sep 2024 23:50:34 +0900

서버리스로 서버 고민없이 웹 애플리케이션 구축하기 #1
서버리스로 서버 고민없이 웹 애플리케이션 구축하기 #2

1편에서 봤듯이 "친구들의 기분 상태를 랜덤으로 매칭하는 서비스"를 서버리스로 구축해보자.

1. 서버리스 아키텍처 개요

3-tier serverless architecture

비즈니스 로직을 AWS Lambda(람다) 함수에 작성하고 람다가 실행되면 DynamoDB에 친구들의 기분 상태 데이터를 저장한다. API Gateway를 통해 람다 함수를 접근할 수 있는 URL을 생성하고 S3에 HTML을 업로드하여 S3 정적 웹 사이트 호스팅 기능으로 웹 사이트를 호스팅한다.

(자세한 내용은 1편에)

2. DynamoDB

완전관리형 AWS의 NoSQL 데이터서비스를 이용하여 데이터를 저장하기 위해 생성한다.

서비스에 연결할 DynamoDB 테이블을 만들면 멤버의 이름과 성격을 저장할 수 있다.

hello-member 이름으로 테이블을 생성해보자.

1. 테이블 생성 누르기

2. 테이블 이름은 hello-member 로, 파티션 키는 name 으로 작성한다. 작성 후 페이지 아래 테이블 생성을 누른다.

3. 아래처럼 활성 상태인 DynamoDB 테이블을 생성했다.

3. Lambda

AWS 대표적인 서버리스 서비스로 많은 요청이 발생할 때에도 람다는 자동 확장되고 관리된다.

추가 기능이나 간단한 서비스 만들 때 람다를 이용하게 된다.

e.g. 사진 이미지 썸네일 만드는 기능 추가, 간단한 데이터 분석, AWS 이벤트 서비스들과 연동해서 이벤트 처리 등

1. 함수 생성 누르기

2. 새로 작성(Author from scratch) 를 선택한다. 이는 람다의 모든 설정을 처음부터 만든다는 의미다.

3. 함수 이름(Function name)은 api-service-create 를 입력하고, 런타임(Runtime)으로는 python 3.12 선택

4. 권한(Permission)을 직접 생성한다. 기본 실행 역할 변경(Change default execution role)을 누르고 실행 역할(Execution role)의 AWS 정책 템플릿에서 새 역할 생성(Create a new role from AWS policy templates)를 선택한다. 역할 이름(Role name)으로는 my-lambda-role 으로 작성한다.

5. NoSQL 데이터베이스 서비스인 DynamoDB와 연결하거나 이용하거나 호출하기 위해 권한이 필요하다. 단순 마이크로서비스 권한(Simple microservice permissions DynamoDB)를 선택한다. 그리고 아래 함수 생성을 누른다.

6. 람다 화면에서 코드 소스(Code source) 부분에 아래 코드를 넣고 Deploy 버튼을 누른다.

import json
import boto3
import random
import json

def lambda_handler(event, context):
    
    member_name = ['Ama','Jone','Zon','Penny','Jessie']
    member_status = ['Happy','Sad','Serious','Satisfied','Free']
    
    dynamodb = boto3.resource('dynamodb',endpoint_url='http://dynamodb.ap-northeast-2.amazonaws.com')
    member_table = dynamodb.Table('hello-member')
    
    name = member_name[random.randint(0,4)]
    status = member_status[random.randint(0, 4)]
    
    member_table.put_item(
       Item={
            'name': name,
            'status': status,
        }
    )
    
    documents = {'name':name,'status':status}
    
    print(documents)
    
    return {
        'statusCode': 200,
        'headers': {'Access-Control-Allow-Origin': '*'},
        'body': json.dumps(documents)
    }

7. Test 버튼을 누르면 테스트 이벤트 구성(Configure test event)가 나온다. 이벤트 이름(Event name)으로는 my-api-test 를 입력하고, 템플릿(Template)은 hello-world 를 선택한다. 그리고 저장을 누른다.

8. Test 버튼을 누르면 테스트가 진행된다. 이제 아래와 같이 결과가 나오면 된다. 출력된 값들은 랜덤하게 선택된 것이다.

9. 테스트 결과가 DynamoDB에 잘 저장됐는지 확인을 해본다. DynamoDB 콘솔창에 들어가서 왼쪽 탐색창에서 테이블을 선택한다. 그리고 기존에 만들었던 hello-member 테이블을 누른다.

10. 표 항목 탐색(Explore table items) 버튼을 누르면 화면 아래쪽에 람다를 실행해서 얻은 값이 저장된 걸 알 수 있다.

4. API Gateway

AWS의 API 관리 서비스를 이용하여 람다를 실행해보자.

API Gateway는 API 를 관리해주고 API 를 통해 외부에서의 호출이 왔을 때 대문 역할을 한다.

API 란 외부에서 기업의 서비스를 이용하려고 할 때 규격을 정해주는 것을 의미한다. 일종의 형식을 정해놓고, 이 형식대로 기업의 서비스를 호출하면 기업은 서비스를 제공해 주는 약속이라고 생각하면 된다.

1. API Gateway 콘솔창에 들어간다. 왼쪽 탐색창에서 API 를 선택하고 HTTP API 보다 API 관리 기능이 더 추가되어 있는 REST API 로 생성하기 위해 구축 버튼을 누른다.

2. API 세부 정보에서 새 API 선택하고, API 이름은 my-api 지정한다. 그 후 API 생성 버튼을 누른다.

3. API를 생성하면 바로 리소스 화면이 나온다. 여기서 메서드 생성 버튼을 누른다.

4. 메서드 유형은 GET 선택한다. 통합 유형은 Lambda 함수를 선택하고, Lambda 프록시 통합 토글 버튼을 클릭하여 활성화한다. Lambda 함수에는 api-service-create 이름을 작성한다. 이후 메서드 생성 버튼을 누른다.

5. 생성한 API의 리소스 메뉴에서 방금 생성한 GET Method를 누르면 오른쪽에 해당 Method 관련된 정보가 보인다. TEST 탭을 선택하여 테스트를 준비한다.

6. 테스트 버튼을 눌러 테스트를 진행한다. 성공했다면 상태(Status)가 200이 나오며, 응답 본문에 랜덤한 값이 나온다.

7. API Gateway를 만들었지만 바로 호출하면 CORS 에러가 발생한다. 호출이 정상적으로 이루어지기 위한 추가 설정을 한다. 생성한 API의 리소스 메뉴에서 CORS 활성화 버튼을 누른다.

8. Access-Control-Allow-Methods 중 방금 생성한 GET Method 선택한 후 저장 버튼을 누른다.

9. 이제 api를 실제로 사용할 수 있게 API 배포 버튼을 누른다.

10. 팝업 창이 뜨는데 스테이지에서는 *새 스테이지* 를 선택하고 스테이지 이름은 dev 입력한다.

11. 완료되면 URL 호출이 나오게 된다. URL은 사람마다 다르며 바로 브라우저를 통해 접속해본다.

12. URL을 브라우저에 붙여넣어 접속하면 아래와 같이 나온다. 이 작업은 URL을 통해 람다를 호출한 것이다.

5. AWS S3

어디서나 원하는 양의 데이터를 검색할 수 있도록 구축된 객체 스토리지이다. 거의 모든 사용 사례를 지원할 수 있고, 비용 효율적인 스토리지 클래스와 사용이 쉬운 관리 기능을 통해 비용을 최적화하고, 데이터를 정리하고, 세분화된 액세스 제어를 구성하여 특정 비즈니스, 조직 및 규정 준수 요구 사항을 충족할 수 있다.

1. S3 콘솔창에 들어와서 버킷 만들기 버튼을 누른다.

2. 버킷 이름에 my-bucket-[랜덤 숫자]를 입력한다. [랜덤 숫자]는 무작위 숫자로 넣으면 되며 대괄호를 빼야한다.

버킷 이름은 전세계에서 유일해야 한다.

3. 아래에 이 버킷의 퍼블릭 액세스 차단 설정이 나오는데 여기서 모든 퍼블릭 액세스 차단 선택을 해제한다. 그리고 나오는 위험 문구에서 현재 설정으로 인해 이 버킷과 그 안에 포함된 객체가 퍼블릭 상태가 될 수 있음을 알고 있습니다. 를 선택한다. 그리고 아래 버킷 만들기 버튼을 누른다.

전세계 사람들이 접근하기 때문에 "정적 웹 사이트 호스팅"과 같은 구체적으로 확인된 사용 사례에서 퍼블릭 액세스가 필요한 경우가 아니라면 차단을 활성화하는 것이 좋다

4. 아래 HTML 파일을 텍스트 에디터에 붙여 넣고 index.html 파일로 저장한다. 그리고 ajax 요청의 url 부분에 URL을 입력하세요 를 API Gateway의 URL로 변경한다.

이 index.html 의 버튼을 누르면 앞에서 만든 람다가 실행된다

<html>

<head>
    <meta charset="utf-8" name="viewport"
        content="width=device-width, height=device-height, minimum-scale=1.0, maximum-scale=1.0, initial-scale=1.0">
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
    <title>Hello World!</title>
    <style>
        #title {
            font-family: arial;
            font-size: 2em;
            color: #eb971a;
            margin-top: 50px;
            text-align: center;
        }

        button {
            background-color: #eb971a;
            border: none;
            color: white;
            border-radius: 5px;
            width: 40%;
            height: 35px;
            font-size: 13pt;
            margin-top: 30px;
            text-align: center;
        }

        #sentence {
            font-size: 17pt;
            margin-top: 30px;
            font-weight: bold;
            color: #eb971a;
        }
    </style>
</head>

<body>
    <p id="title">Hello World From <b>Lambda</b></p>
    <hr id="lambda-line" width="800px" align="center" color="#eb971a;">
    <center><button onclick="checkEvent();">Who are you?</button></center>
    <center>
        <div id="sentence"></div>
    </center>
</body>
<script type="text/javascript">
    function checkEvent() {
        $.ajax({
            type: "GET",
            url: "URL을입력하세요",
            dataType: 'json',
            success: function (data) {
                document.getElementById('sentence').innerHTML = data.status + "&nbsp;&nbsp;" + data.name
            },
            error: function (error) {
                alert('ERROR::');
                console.log(error)
            }
        });
    }
</script>

</html>

5. 앞서 만든 버킷에서 index.html 파일을 업로드한다.

6. 업로드를 하면 버킷에 아래처럼 html 파일이 보인다.

7. 버킷의 속성(Properties) 탭에 들어가서 아래쪽으로 내려가면 정적 웹 사이트 호스팅이 나오며 편집 버튼을 누른다.

8. 인덱스 문서에 index.html 입력한다. 처음 주소로 읽어 들일 html 파일을 지정해주는 부분이다. 변경 사항 저장 버튼을 누른다.

9. 설정이 잘 됐다면 정적 웹 사이트 호스팅 기능이 활성화 되며 아래와 같이 주소가 생성된다.

10. 아직 외부에서 접근할 수 있는 권한이 없어서 사이트가 차단되어 있다. 외부에서 파일을 읽을 수 있도록 권한을 부여한다. 아래와 같이 권한 탭으로 이동하여 버킷 정책에서 편집 버튼을 누른다.

11. 아래 내용을 복사하여 붙여넣는다. 이 때 11,12번째 줄에 [본인버킷번호] 부분을 본인의 버킷 랜덤 숫자를 넣고 저장 버튼을 누른다. 권한의 내용은 본인 버킷의 내용을 모든 사람이 다운로드할 수 있게 하겠다는 내용이다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1709405011428",
      "Action": [
        "s3:GetObject"
      ],
      "Effect": "Allow",
      "Resource": [
        "arn:aws:s3:::my-bucket-[본인버킷번호]",
        "arn:aws:s3:::my-bucket-[본인버킷번호]/*"
      ],
      "Principal": "*"
    }
  ]
}

12. 정적 웹사이트 호스팅 주소를 브라우저에 넣으면 아래 화면처럼 나온다. 버튼을 누르면 웹사이트에 사람이름과 기분이 표시된다. 버튼을 누르면 람다가 실행되는데 DynamoDB에 기록이 잘 됐는지 확인하면 끝이다.

AWS Serverless(서버리스)로 서버 고민 없이 웹 애플리케이션 구축하기 #1

묠니르묘묘 — Fri, 6 Sep 2024 00:15:27 +0900

서버리스로 서버 고민없이 웹 애플리케이션 구축하기 #1
서버리스로 서버 고민없이 웹 애플리케이션 구축하기 #2

AWS 대표 서비스인 Lambda(람다)를 사용하여 서버 고민 없이 간단한 웹 애플리케이션을 구축하는 방법을 다뤄본다.

우리가 만들 웹 서비스는 "친구들의 기분 상태를 랜덤으로 매칭하는 서비스"이다.

https://static.us-east-1.prod.workshops.aws/public/a09c2a3d-2abf-401d-accc-2e749ca0c294/static/images/110-others/architecture-1.png

1. Lambda와 DynamoDB를 활용한 데이터 처리

비즈니스 로직을 AWS Lambda 함수에 작성하고 이 Lambda가 실행될 때마다 친구들의 기분 상태 데이터를 랜덤하게 생성하여 DynamoDB에 저장한다. Lambda는 서버를 직접 관리할 필요 없이 이벤트가 발생할 때 자동 실행된다.

2. API Gateway를 통한 인터넷 연결

Lambda 함수를 API Gateway와 연결하여 인터넷에서 접근할 수 있는 URL을 생성한다. 이 URL을 통해 사용자는 Lambda 함수를 실행할 수 있다.

3. S3를 이용한 정적 웹사이트 호스팅

프론트엔드는 간단한 HTML로 구현한다. HTML에 버튼을 추가해 사용자가 버튼을 누르면 Lambda가 실행되도록 한다. 이 HTML 파일은 S3 버킷에 업로드하여 S3 정적 웹사이트 호스팅 기능을 사용하여 전 세계에서 접근가능하게 한다. 즉, 웹 서버를 따로 두지 않고 S3가 웹 서버 역할을 수행하게 된다.

자 그럼 해당 서버리스 웹 애플리케이션을 구축하기 전에 해당 서비스들의 개념을 살펴보고 해당 웹 애플리케이션 구축은 2번째 게시글에서 살펴보자.

1. 서버리스란?

서버가 없다는 의미가 아닌 서버 관리가 불필요하다는 의미
서버를 관리하고 운영하는 부분은 AWS에 위임
개발자는 오직 비즈니스 문제를 해결하는 코드 작성에만 집중

2. 패러다임의 전환 (paradigm shift)

초기에는 개발자들이 물리적인 서버를 직접 구축하고 관리
클라우드 기술이 발전하면서 가상 머신을 통해 이 작업을 단순화하였고, 대표적인 가상머신으로 AWS EC2가 있음
현재는 컨테이너 기술이 발전하면서 인프라를 컨테이너로 구축하여 사용

위 사항들은 여전히 개발자가 전부 관리해야 한다는 단점이 있음.

서버리스를 사용하게 된다면 AWS가 인프라를 관리해주기 때문에 이런 부담이 줄어들게 됨.

3. 서버리스의 장점

서버 관리 필요 없음
사용한 만큼만 지불
요청에 맞게 스케일링
높은 보안수준
- 대부분 AWS가 책임지므로 덜 신경써도 됨

4. 다양한 범주의 서버리스 서비스

Lambda : 이벤트에 의해 구동되는 이벤트 드리븐 아키텍처에서 많이 사용
Fargate : 컨테이너 노드를 위한 서버리스 서비스
S3 : 객체 오브젝트 저장소
Aurora Serverless : 관계형 데이터베이스
DynamoDB : NoSQL
EventBridge : 이벤트 리스너 또는 라우터 역할
API Gateway : api 엔드포인트 역할
SQS, SNS : 메시징과 관련
Step Functions : 워크 플로우 제어를 위한 것
AppSync : GraphQL 지원

5. 3-Tier 서버리스 아키텍처 구성

S3 : 웹 서버 역할 담당하며 사용자가 가장 먼저 접속하는 웹페이지 제공
API Gateway : Lambda 실행을 위한 API 정의하고 인터넷 주소(엔드포인트) 생성
Lambda : API Gateway에서 호출된 후 비즈니스 로직 처리
DynamoDB : 데이터베이스 역할을 하여 데이터를 저장하고 관리

6. AWS Lambda

AWS 대표적인 서버리스 서비스
많은 요청이 발생할 때에도 Lambda는 자동 확장 및 관리됨
추가하고 싶은 기능이나 간단한 서비스를 만들 때도 쉽게 사용 가능
- 사진 이미지 썸네일 버전 만드는 기능
- 간단하게 데이터 분석하고 싶을 때
- AWS 의 이벤트 서비스들과 연동해서 이벤트 발생 시, Lambda 기능을 이용해서 이벤트 처리

6-1. AWS Lambda 특성

서버를 프로비저닝하거나 관리하지 않고도 코드를 실행해주는 컴퓨팅 서비스

불필요한 서버 관리
자동 확장
고가용성 및 보안
사용한 만큼만 지불

6-2. AWS Lambda를 사용한 아키텍처

이벤트 소스로부터 람다가 호출되면 함수가 구동
여러 언어로 함수의 코드 작성 가능
여러 언어로 애플리케이션을 만들어서 코드만 실행하면 됨
함수는 함수를 호출하거나 DB, 인터넷 등 통신 가능

6-3. AWS Lambda 사용 사례

우리가 만드는 대부분의 서비스는 Lambda로 구축 가능
웹서버, 백엔드 서비스, 데이터 처리, 챗봇, 자동화 등 다양한 사례 존재
AWS에서는 자동화를 위해 Lambda 많이 사용

7. API Gateway

AWS의 API 관리 서비스
API 를 관리해주고 API 를 통해 외부에서의 호출이 왔을 때 대문 역할을 하는 서비스

API 란 외부에서 기업의 서비스를 이용하려고 할 때 규격을 정해주는 것을 의미한다. 일종의 형식을 정하고 이 형식대로 기업 서비스를 호출하면 기업은 서비스를 제공해 주는 약속이라고 생각하면 된다.

7-1. API Gateway 는 API 기반 아키텍처의 관문

어떤 규모에서도 개발자가 API 를 손쉽게 생성, 개시, 유지, 관리, 모니터링 등 할 수 있는 완전관리형 서비스
애플리케이션이 백엔드 서비스에 데이터, 비즈니스 로직, 기능에 접근할 수 있는 정문 역할
사용자로부터 요청을 받으면 Lambda 또는 Load Balancer 등 다양한 서비스에 요청 전달 가능

7-2. 다양한 API 유형 지원

일반적으로 RESTful API 생성 가능
채팅앱, 스트리밍 대시보드와 같은 실시간 양방향 통신은 WebSocket APIs 생성 가능

8. Amazon DynamoDB

대규모 성능에 최적화된 완전 관리형 NoSQL 데이터베이스 서비스
RDB에서는 데이터를 보관하는 형태인 스키마를 정의하고 이를 이용하여 데이터를 저장하지만, DynamoDB와 같은 NoSQL은 스키마 없이 데이터를 원하는 형태로 자유롭게 저장 가능
AWS의 완전관리형 서비스이기에 서버 관리를 신경쓰지 않음

8-1. Dynamo 특징

서버리스

유지관리 불필요
오토 스케일링
고가용성 및 내결함성

높은 성능

Known access pattern 이 있는 애플리케이션에서 이상적 성능
초당 수백만 요청 처리 및 짧은 지연시간
자동화된 글로벌 복제
다른 AWS 서비스와 통합

보안 및 액세스

전송 중 및 저장 시 암호화
API/ORM 을 통한 세부적인 액세스 제어
IAM을 통한 승인

8-2. 데이터베이스 확장

SQL은 하드웨어의 성능을 높이는 방법으로 한계가 있음
NoSQL은 수평 확장 가능하도록 데이터가 설계되었기에 매우 유연함

8-3. Core Concepts - Tables, Items, Attributes, Indexes

RDB 와 달리 서버 사이즈 등 데이터베이스 설정 필요 없음
필요한 키 이외의 스키마를 따로 지정 X, 데이터를 넣으면 넣는대로 들어가기에 따로 저장할 필요 X, 정규화 과정 필요 X
key-value 형태의 스키마 지원
RDB와 동일하게 테이블 생성 가능
partition key라는 것을 만들어야 하며, 이는 유니크한 값이고 정렬이 필요하면 sort key 사용하며, 이 전부가 primary key에 해당함
column 은 attribute
row는 item

9. Amazon S3

Amazon Simple Storage Service
어디서나 원하는 양의 데이터를 저장하고 검색할 수 있도록 구축된 객체 스토리지
높은 확장성, 데이터 가용성, 보안, 대용량 데이터 처리 성능 갖춤

9-1. 정적 웹 사이트 호스팅

S3가 마치 웹서버처럼 동작
S3에 권한을 주어 미리 업로드한 파일(HTML, CSS, JS 등)을 읽을 수 있게 함
정적 웹 사이트 호스팅
- 서버 측 스크립팅(서버 사이드 렌더링) 지원 X
- 클라이언트 렌더링만 가능
버킷 구성
- 웹 사이트 호스팅
- 퍼블릭 읽기 액세스
리전별 웹 사이트 엔드포인트
- 웹 사이트 엔드포인트
- https://[bucketname].s3-website-[Region].amazonaws.com

9-1-1. 차단되는 퍼블릭 액세스의 유형

S3에 데이터를 올리면 오브젝트 형태로 저장되며, 이 공간을 버킷이라고 함
버킷은 기본적으로 모든 접근 차단되며, 특히 퍼블릭 접근 차단
퍼블릭으로 열면 클라우드 특성상 누구든지 접근 가능하기에 위험하며, S3에 데이터 전송 비용도 추가됨
접근을 꼭 해야하는 경우에만 제한적으로 풀기

9-2. S3 버킷 정책

S3 버킷 정책은 익명 사용자에게 읽기 전용 권한 부여
Effect : 허용 및 불가 설정
Action : 권한
Resource : 자원
Principal : 누가 이 적용을 받는지 의미

AWS TechCamp란?

묠니르묘묘 — Wed, 4 Sep 2024 21:47:14 +0900

최근 AWS Builders Korea Program이 새롭게 변화한 AWS TechCamp에 참여하면서 느낀 점을 공유하고자 한다.

기존 프로그램에서는 이론과 간단한 실습을 중심으로 진행되었지만, 이번 테크캠프는 한층 더 강화된 학습 경험을 제공했다.

실시간으로 과외를 받는 듯한 몰입감이 느껴졌고, AWS 서비스를 깊이 이해하고 실전에서 바로 적용해보고 싶다는 열정이 생겼다.

어떻게 진행되나요?

TechCamp는 분기별로 3일간의 세션으로 구성된다.

매년 3월(Modern App), 6월(AI/ML), 9월(Data), 11월(Every App)을 주제로 진행된다.

하루 두 번, 오전 9~12시, 오후 2~5시까지 강의가 열린다.

강의는 기초 과정 (레벨 100), 기본 과정 (레벨 100 - 200) , 심화 과정 (레벨 200 - 300)으로 구성되어 있으며, 이론 강의와 실시간 실습을 진행한다. 궁금한 점이 생기면 실시간으로 질문할 수 있어 이론만 듣고 끝내는 것이 아니라 실제 적용에 큰 도움이 된다.

직접 체험해보니 어떤 느낌인가요?

개인별 전용 웨비나 URL로 접속해 온라인 강의를 들었다.

각 강사님의 개성 넘치는 진행 덕분에 재밌게 강의를 들을 수 있었다.

이론 강의로 시작해 실시간 실습으로 이어지면서, 이론만으로는 다소 이해가 어려운 부분이 실습을 통해 명확해졌다.

실제로 AWS 서비스를 구축하면서 어떻게 활용해야 할지에 대한 감을 잡을 수 있었고, 만족도는 20000% 이다.

특히, 이번 프로그램은 주변 개발자들에게도 적극 추천할 만한 가치가 있었다.

마음에 드는 세션이 있다면 참여해 실시간 실습을 경험해보자.

강의자료와 다시보기는 1개월간 제공되며, 유튜브에 올라올 가능성도 있어 복습하기 좋다.

실습 비용도 대부분 프리티어로 진행되며, 필요한 경우 추후 50달러 크레딧을 받을수 있어 비용 부담이 크지 않다.

단점은 없나요?

가장 큰 단점은 평일에 진행했다는 점이다.

직장인, 학생 등 시간적 여유가 부족한 분들에게는 오전 9시~12시, 오후 2시~5시 일정이 다소 부담스럽다.

다시보기가 제공되지만 이 경우 50달러 크레딧을 못받기에 개인돈을 쪼끔 써야한다.

비록 큰 금액은 안나오지만 비용 부담이 생긴다는 점이 아쉽다.

결론

이번에 들었던 세션들

이번 AWS TechCamp는 이론과 실습을 통해 AWS 서비스를 직접 적용해보는 경험을 선사했다. 특히 새로운 AWS 서비스(AWS Clean Rooms, AWS DataZone ...)를 접하고 활용할 수 있었던 점이 가장 좋았다. 평소에는 접해보지 못한 서비스들을 깊이 있게 다뤄보며, AWS에 대한 이해를 넓힐 수 있는 기회였다. 새로운 관점과 새로운 서비스를 계속해서 경험하고 이해하고 싶은 분들에게 적극 추천한다.

빅데이터의 파일 형식은 무엇으로 해야할까? (feat. Parquet 란?)

묠니르묘묘 — Thu, 29 Aug 2024 23:58:02 +0900

데이터 엔지니어 프로젝트를 진행하면서 컬럼이 수십개에 레코드는 수십만개의 데이터를 다루면서 데이터 유형에 대해 고민하게 되었다. 단순히 보기 편하고 다루기 쉬운 행 기반 형식의 CSV 파일만을 생각했는데 읽고 쓰는 I/O 성능이 느려서 새로운 파일 유형을 찾게 되었다. 그것이 parquet 같은 빅데이터 파일 형식이다.

1. 고민해야할 점

데이터가 기하급수적으로 증가함에 따라 효율적인 데이터 저장방법은 무엇일까?
데이터를 행과 열로 구성하는 것의 차이점과 이것이 저장 및 쿼리 효율성에 어떤 영향을 미칠까?
행 기반 형식으로 데이터를 저장하는 것의 장단점과 쓰기 작업이 많은 작업에 대한 적합성은 무엇일까?
빠른 쿼리 속도와 효율적인 압축 옵션 등 읽기 작업이 많은 작업을 위한 열(컬럼) 기반 저장소의 이점은?
Parquet와 ORC 파일 형식의 차이점과 각 형식의 최적 사용 사례가 무엇일까?

2. Parquet 파일 형식이란?

빠른 분석 쿼리를 위한 무료 오픈소스 스토리지 형식
효율적인 데이터 압축 및 인코딩 체계를 제공
복잡한 쿼리 실행하고 대용량 데이터를 처리하는데 이상적인 파일 형식
Announcing Amazon Redshift data lake export 에서 "Parquet 형식은 텍스트 형식에 비해 UNLOAD 속도가 최대 2배 빠르고, AWS S3 에서 스토리지 사용량이 최대 6배 적습니다" 라고 설명함
- 또한, 하나 이상의 파티션 열을 지정하여 언로드된 데이터를 S3 버킷 폴더로 자동 분할 가능
  - e.g. 연도, 월, 일 별로 분할하도록 선택 가능
- 파티션 잘라내기 기능과 관련없는 파티션 검색 건너뛰기 기능 활용하여 쿼리 성능 개선 및 비용 최소화 가능
데이터를 Parquet 또는 ORC 같은 열 형식으로 변환하는 것도 AWS Athena 성능 개선하는 수단으로 권장
- 필요한 블록만 fetch 하여 쿼리 성능 개선
Apache Parquet 는 Data Lake 사용할 때 시스템 성능에 중요한 역할을 함

3. Parquet vs. ORC (Optimized Row Columnar)

Parquet 와 ORC 는 빅데이터 애플리케이션에 적합한 선택이기에 요구사항을 고려하여 적합한 형식을 선택하자.

쿼리 성능 (Queery Performance)

parquet가 더 광범위하고 복잡한 쿼리 유형 지원

복합 데이터 유형 (Complex Data Types)

ORC 가 더 광범위한 복합 데이터 유형 지원

쓰기 효율성 (Write Efficiency)

ORC 는 Hive에서 ACID 트랜잭션 지원하므로 쓰기 작업이 많을 경우 선택
Parquet는 일반적으로 분석 작업 부하와 크고 복잡한 데이터 구조 작업할 때 좋음
ORC 는 쓰기 작업과 데이터 수정이 필요할 때 더 이상적이며, Parquet에 비해 더 나은 쓰기 속도 제공

읽기 효율성 (Read Efficiency)

Parquet 는 한 번 쓰고 여러 번 읽는 분석 시나리오에서 탁월하며, 매우 효율적인 데이터 압축 및 압축 해제 제공
Parquet 는 데이터 건너뛰기를 지원하며, 쿼리 전체 데이터 행을 건너뛰면서 특정 열 값 반환이 가능하므로 I/O 최소화
데이터 세트에 많은 수의 컬럼이 있고, 특정 데이터 하위 집합에만 접근해야 하는 시나리오에서 ORC 가 유용할 수 있음

호환성 (Compatibility)

ORC 는 Hive 생태계와 호환되며 Apache Hive 와 함께 작업 시, ACID 트랜잭션 지원
Parquet는 Java, Python, C++ 같은 여러 프로그래밍 언어 지원하며 거의 모든 빅데이터 설정에서 사용할 수 있도록 광범위한 접근성 제공하며, AWS Athena, AWS Redshift Spectrum, Qubole, Google BigQuery 등 여러 쿼리 엔진에서 사용됨

파일 크기 (File Size)

디스크 공간이 문제인 경우, ORC 는 일반적으로 더 작은 파일을 생성하여 저장 비용 줄임

압축 (Compression)

둘 다 우수한 압축 제공하기에 적합한 형식은 특정 사용 사례에 따라 다름
그러나 압축이 주요 기준이면 Parquet 를 선택함. 이는 매우 효율적인 압축 및 인코딩 체계로 더 작은 파일 크기를 제공하기 때문이며 컬럼별로 특정 압축 체계를 지원하여 저장된 데이터를 더욱 최적화 가능하기 때문임

진화 (Evolution)

둘 다 스키마 진화(Schema Evolution) 지원
즉, 시간이 지남에 따라 열(column) 추가, 제거 및 수정 가능

Parquet와 다른 파일 형식 비교를 보려면 Parquet, ORC, and Avro: The File Format Fundamentals of Bic Data 를 살펴보자.

4. Parquet 특징

https://www.upsolver.com/wp-content/uploads/2020/05/Screen-Shot-2020-05-26-at-17.52.58.png

열 기반 (Columnar)
- CSV 또는 Avro 같은 행 기반 형식과 달리 열 기반
- 즉, 각 레코드 값이 아닌 각 테이블 열의 값이 나란히 저장
오픈소스 (Open-source)
- Parquet 는 Apache Hadoop 라이센스에 따라 무료 사용 가능한 오픈소스
- 대부분의 Hadoop 데이터 처리 프레임워크와 호환
자체 설명 (Self-describing)
- Parquet 파일에는 데이터 외에도 스키마와 구조를 포함한 메타 데이터 포함
- 각 파일은 데이터와 각 레코드에 액세스하는 데 사용되는 표준을 모두 저장하므로 Parquet 파일을 쓰고, 저장하고, 읽는 서비스를 쉽게 분리 가능
- 각 파일은 각 레코드에 액세스하는 데 사용되는 데이터와 표준을 모두 저장하므로 Parquet 파일을 쓰고, 저장하고, 읽는 서비스를 분리하기가 더 쉬움
- 데이터 타입도 메타데이터에 저장되기에 CSV 와 달리 따로 데이터 유형을 명시하지 않아도 됨

5. Parquet 장점

5-1. 압축 (Compression)

Parquet 에서 압축은 열 단위로 수행되며 데이터 유형별로 유연한 압축 옵션과 확장 가능한 인코딩 스키마를 지원하도록 구축됨
e.g. 정수 및 문자열 데이터를 압축하는 데 서로 다른 인코딩 사용
사전 인코딩 (Dictionary Encoding)
- 고유 값이 적은 데이터에 대해 자동으로 동적 활성화
- 반복되는 값을 고유한 코드로 매핑하여 저장하는 방식이며, 반복되는 값이 많은 열에서 효과적
- 고유 값이 많을 경우에는 사전 크기가 커지면서 오히려 메모리 사용량이 늘어날 수 있음
비트 패킹 (Bit Packing)
- 정수 저장은 일반적으로 정수당 전용 32bit 또는 64bit로 이루어짐
- 이를 통해 작은 정수를 보다 효율적으로 저장
실행 길이 인코딩 (RLE, Run Length Encoding)
- 동일한 값이 여러 번 발생하면 발생 횟수에 따라 하나의 값이 한 번씩 저장됨
- Parquet 는 비트 패킹과 RLE 의 결합 버전을 구현하며, 어떤 인코딩이 최상의 압축 결과를 생성하는지에 따라 인코딩이 전환됨

5-2. 성능 (Performance)

CSV 와 같은 행 기반 파일과 달리 Parquet 는 성능을 위해 최적화 됨
파일 시스템에서 쿼리 실행 시, 매우 빠르게 관련 데이터에만 집중 가능
스캔되는 데이터 양이 훨씬 적어 I/O 사용량 최소화

5-3. 스키마 진화 (Schema evolution)

Parquet 와 같은 열 형식의 파일 사용하는 경우, 사용자는 간단한 스키마로 시작하여 필요에 따라 점차적으로 스키마에 열(컬럼) 추가 가능
이러한 방식으로 사용자는 서로 다르지만 상호 호환되는 스키마를 가진 여러 개의 Parquet 파일을 가질 수 있음
이러한 경우 Parquet 는 이러한 파일 간의 자동 스키마 병합을 지원함

5-4. 오픈소스 및 비독점적 (Open source and non-proprietary)

Apache Parquet 는 오픈소스 Apache Hadoop 생태계 일부
활발하게 개발 진행 중이며 사용자 및 개발자 커뮤니티에 의해 지속적으로 개선 및 유지관리
데이터를 오픈 포맷으로 저장하면 공급업체에 묶이지 않고 유연성 높일 수 있음
많은 최신 고성능 DB에서 사용하는 독점 파일 포맷과 비교 가능
즉, 특정 DB 공급업체에 묶이지 않고도 동일한 데이터 레이크 아키텍처 내에서 AWS Athena, AWS Redshift, Qubole 과 같은 다양한 쿼리 엔진 사용 가능
- 4 Guiding Principles for Modern Data Lake Architecture

6. Parquet 구조

자체 설명 형식으로 각 파일에는 데이터와 메타데이터 모두 포함
파일은 행 그룹(row groups), 헤더(header) 및 푸터(footer)로 구성
각 행 그룹에는 동일한 열 데이터 포함
동일한 열은 각 행 그룹에 함께 저장

https://www.upsolver.com/wp-content/uploads/2020/05/Screen-Shot-2020-05-26-at-17.53.13.png

이 구조는 빠른 쿼리 성능과 낮은 I/O (스캔되는 데이터 양 최소화)를 위해 최적화 되어 있음
- e.g. 열이 1000개인 테이블이 있는데 일반적으로 열의 작은 하위 집합만 사용하여 쿼리한다고 가정한다면
  - Parquet 파일을 사용하면 필요한 열과 해당 값만 가져와서 메모리에 로드하고 쿼리 응답 가능
  - CSV 와 같은 행 기반 파일의 경우에는 전체 테이블을 메모리에 로드해야 하므로 I/O 증가 및 성능 저하

7. 분석 쿼리를 위한 열 기반 스토리지 vs. 행 기반 스토리지

(Column-Oriented vs. Row-Based Storage for Analytic Querying)

데이터는 종종 행으로 생성되고 쉽게 개념화 된다. 우리는 엑셀(Excel) 스프레드 시트 관점에서 생각하는 것이 익숙하며, 특정 레코드와 관련된 모든 데이터를 깔끔하고 체계적으로 정리된 한 행에서 볼 수 있다. 그러나 대규모 분석 쿼리의 경우 열 기반 스토리지는 비용과 성능 측면에서 상당한 이점이 있다.

Logs and Event Streams 와 같은 복잡한 데이터는 수백 또는 수천 개의 컬럼과 수백만 개의 행이 있는 표로 표현된다. 이 표를 CSV 같은 행 기반 형식으로 저장하면 아래와 같다.

쿼리에 대한 결과에 필요한 열의 하위 집합만 쿼리하는 것이 아니라 더 많은 데이터를 스캔해야 하므로 쿼리 실행 시간이 더 오래 걸림
CSV 는 Parquet 만큼 효율적으로 압축되지 않기에 스토리지 비용이 더 많이 듦

열 형식은 더 나은 압축률과 향상된 성능을 기본적으로 제공하며 데이터를 열 단위로 수직으로 쿼리 가능하다.

8. Apache Parquet 는 언제 사용해야 할까?

매우 많은 양의 데이터로 작업할 때

Parquet 는 성능과 효과적인 압축을 위해 만들어짐
여러 벤치마킹 테스트에서 Parquet의 SQL 쿼리 실행 시간과 Avro 또는 CSV 같은 형식과 비교한 결과 Parquet 쿼리가 훨씬 더 빠르게 수행되는 것을 알 수 있음

전체 데이터 집합에 많은 열이 있지만 하위 집합에만 액세스해야 하는 경우

기록하는 비즈니스 데이터가 점점 더 복잡해지면서 각 데이터 이벤트에 대해 20개의 필드를 수집하는 대신 100개 이상의 필드를 수집하고 있을 수 있음
이러한 데이터는 데이터 레이크에 저장하기는 쉽지만, 행 기반 형식으로 저장된 경우 쿼리하려면 상당한 양의 데이터를 스캔해야 함.
Parquet 의 열 형식과 자체 설명 기능을 사용하면 특정 쿼리에 응답하는 데 필요한 필수 컬럼만 가져올 수 있으므로 처리되는 데이터의 양을 줄일 수 있음

여러 서비스가 객체 저장소에서 동일한 데이터를 사용하도록 하려는 경우

Oracle 또는 Snowflake 와 같은 데이터베이스 공급업체는 자사 도구만 읽을 수 있는 독점 형식으로 데이터를 저장하는 것을 선호하지만, 최신 데이터 아키텍처는 스토리지와 컴퓨팅을 분리하는 쪽으로 편향되어 있음
여러 분석 서비스를 사용하여 다양한 사용 사례에 대한 답을 찾으려면 데이터를 Parquet에 저장해야 함 (Read more about data pipeline architecture)

9. AWS 와의 호환성

Redshift 쿼리 결과를 분석을 위한 효율적인 개방형 열 기반 스토리지인 Apache Parquet로 AWS S3 데이터 레이크에 UNLOAD(언로드) 가능
- Redshift 쿼리 결과를 parquet 파일로 S3에 저장 가능
하나 이상의 파티션 열을 지정하여 언로드 된 데이터를 S3 폴더로 자동 분할 가능
- 연도, 월, 일별로 분할하도록 선택 가능
컬럼형 parquet 스토리지는 분석 쿼리에 매우 효율적이며, AWS Athena 또는 AWS Redshift Spectrum과 같은 다양한 서비스에서 액세스 가능

10. AWS Redshift에서 대용량 데이터를 AWS S3에 CSV와 Parquet 파일로 저장하기

Redshift 쿼리편집기에 들어가서 진행함.

naver_real_estate 테이블에는 약 42만건의 데이터와 약 50개의 컬럼이 있음.

단순하게 전체 SELECT(조회) 하는데 데이터가 너무 커서 UNLOAD 명령어를 사용하라고 나온다.

UNLOAD ('SELECT * FROM raw_data.naver_real_estate')
TO 's3://S3버킷이름'
IAM_ROLE 'IAM ROLE 입력'
CSV;

42만건을 UNLOAD 명령어로 S3에 CSV 파일로 저장하는데 19.2초 소요됐다.

이 때 적절한 크기로 분할되는데 단일 파일로 저장하려면 PARALLEL OFF 명령어를 붙이면 된다.

또한, Redshift 명령어로 생성된 출력 파일 크기 제한은 UNLOAD의 경우 6.2GB 정도이다.

gzip 명령어도 사용하면 압축되기에 용량이 더욱 작아진다.

UNLOAD ('SELECT * FROM raw_data.naver_real_estate')
TO 's3://S3버킷명'
IAM_ROLE 'IAM ROLE 값'
CSV
PARALLEL OFF;

파일을 분할하지 않으니 28.6초가 소요되며 파일 크기도 합쳐진 452MB가 생성된다.

UNLOAD ('SELECT * FROM raw_data.naver_real_estate')
TO 's3://S3버킷명'
IAM_ROLE 'iam role 값'
CSV
PARALLEL OFF
gzip;

단일 파일에서 gzip으로 압축하면 22.7초가 소요됐으며 용량은 452MB에서 132MB로 1/3으로 줄었다.

압축파일을 풀면 CSV 파일이 나온다.

UNLOAD 명령어로 Parquet 파일 생성

UNLOAD ('SELECT * FROM raw_data.naver_real_estate')
TO 's3://S3버킷명'
IAM_ROLE 'iam role 값'
PARQUET
PARALLEL OFF;

이번에는 Parquet 파일로 저장해보니 16.7초가 소요되며 CSV 파일을 압축한 것과 비슷한 용량으로 나오는 것을 알 수 있다.

11. Airflow DAG를 통해서 원하는 스키마의 모든 테이블을 S3에 저장하기

dev 데이터베이스에서 raw_data 스키마와 analytics 스키마 안에 있는 모든 테이블을 Parquet로 저장하는 코드를 작성해본다.

@task
def unload():
    conn = get_redshift_connection()
    cur = conn.cursor()
    cur.execute("SHOW TABLES FROM SCHEMA dev.raw_data;")
    tables = cur.fetchall()
    for table in tables:
        table_name = table[2]
        unload_to_s3_parquet('raw_data', table_name, f's3://{BUCKET_NAME}/unload/raw_data/{table_name}/')
        
    cur.execute("SHOW TABLES FROM SCHEMA dev.analytics;")
    tables = cur.fetchall()
    for table in tables:
        table_name = table[2]
        unload_to_s3_parquet('analytics', table_name, f's3://{BUCKET_NAME}/unload/analytics/{table_name}/')

def unload_to_s3_parquet(schema: str, table: str, s3_path: str, parallel: bool = False):
    iam_role = Variable.get("aws_iam_role")
    conn = None
    cur = None
    try:
        conn = get_redshift_connection()
        cur = conn.cursor()

        parallel_option = 'ON' if parallel else 'OFF'
        cur.execute(f"""
            UNLOAD ('SELECT * FROM {schema}.{table}')
            TO '{s3_path}'
            IAM_ROLE '{iam_role}'
            PARQUET
            PARALLEL {parallel_option};
        """)
        logging.info(f"SUCCESS AWS Redshift unloaded {schema}.{table} to {s3_path} as Parquet")
    except Exception as e:
        logging.error(f"Error Failed to UNLOAD {schema}.{table} to {s3_path}: {e}")
        raise
    finally:
        if cur is not None:
            cur.close()
        if conn is not None:
            conn.close()

12. SQL DB 툴 (DataGrip)로 CSV파일 저장하기

데이터베이스 관리도구를 통해서도 테이블을 쉽게 다운로드 할 수 있다.

인텔리제이(IntelliJ)의 DB 툴인 DataGrip 에서도 아래와 같이 간단하게 파일로 저장할 수 있다.

이 때 Parquet 파일 형식은 없고 CSV로는 가능하다.

하지만 CSV 파일 저장 할 때 데이터 양이 많으면 제대로 다운로드가 안되며, 대략 400MB부터 안된다.

이 때 JVM 메모리를 더 높이라고 나오는데 아무래도 자체 메모리 부족으로 안되는 듯 하다.

https://www.upsolver.com/blog/apache-parquet-why-use

Airflow 란 무엇인가?

묠니르묘묘 — Sun, 26 May 2024 15:45:45 +0900

1. Airflow 소개

파이썬으로 작성된 데이터 파이프라인(ETL) 프레임워크
- Airbnb에서 시작한 아파치 오픈소스 프로젝트
- 가장 많이 사용되는 데이터 파이프라인 관리 및 작성 프레임워크
데이터 파이프라인 스케줄링 지원
- 정해진 시간에 ETL 실행 or 한 ETL의 실행이 끝나면 다음 ETL 실행
- 웹 UI 제공
데이터 파이프라인(ETL)을 쉽게 만들 수 있게 해줌
- 다양한 데이터 소스와 데이터 웨어하우스를 쉽게 통합해주는 모듈 제공
- https://airflow.apache.org/docs/
데이터 파이프라인을 DAG(Directed Acyclic Graph)라고 부름
- 1개의 DAG는 1개 이상의 태스크(task)로 구성

2. Airflow 구성

웹 서버(Web Server)
- 웹 UI는 스케줄러와 DAG의 실행 상황을 시각화해줌
- Python Flask로 구현되어 있음
스케줄러 (Scheduler)
- DAG들을 워커들에게 배정하는 역할 수행
- 스케줄러와 각 DAG의 실행 결과는 별도 DB에 저장됨
- 정해진 시간에 실행되게 할 수 있으며, 순차적 태스크 진행
워커 (Worker)
- DAG를 실행하는 역할 수행
메타 데이터 데이터베이스 (Metadata Database)
- SQLite 가 기본 설치
- 실제 프로덕션에서는 MySQL 이나 Postgres 를 사용해야 함
큐 (Queue)
- 다수 서버 구성인 경우에만 사용
- 이 경우 Executor가 달라짐

3. Airflow 구조 : 서버 한대

Airflow 서버 한대 구조

4. Airflow 구조 : 다수 서버

Airflow 서버 다수 구조

스케일링 할 때는 워커를 별도의 서버에서 돌리고, 워커가 있는 서버의 수를 늘리는 형태로 용량 증대

5. Airflow 구조

Airflow 구조

사용자는 UI 를 통해서 웹 서버와 통신
Airflow 서버 안에는 DAG Directory 가 있고, 여기에 파이썬으로 작성된 데이터 파이프라인 코드가 있음
위 다렉토리를 Airflow가 주기적으로 파싱해서 Metadata DB에 기록
스케줄러가 Executor 를 통해서 워커들에게 일을 주는데, Executor 특성에 따라서 Queue 가 있기도 하고 없기도 함

6. Airflow 개발 장단점

장점

데이터 파이프라인 세밀하게 제어 가능
다양한 데이터 소스와 데이터 웨어하우스 지원
백필(Backfill) 쉬움

단점

배우기 쉽지 않음
상대적으로 개발환경 구성하기 쉽지 않음
직접 운영이 쉽지 않으며, 클라우드 버전 사용이 선호됨
- GCP provides "Cloud Composer"
- AWS provides "Managed Workflows for Apache Airflow"
- Azure provides "Data Factory Managed Airflow"

7. DAG 란?

Directed Acyclic Graph
Airflow 에서 ETL 을 부르는 명칭
DAG는 태스크로 구성
- e.g. 3개의 태스크로 구성된다면 Extract, Transform, Load 로 구성

8. 태스크(task)란?

https://magpienote.tistory.com/193

Airflow의 기본 실행 단위
Airflow 의 오퍼레이터(Operator)로 만들어짐
Airflow 에서 이미 다양한 종류의 오퍼레이터 제공
경우에 맞게 사용하며, 오퍼레이터를 결정하거나 필요하다면 직접 개발
e.g. Redshift writing, Postgres query, S3 Read/Write, Hive query, Spark job, shell script

8. DAG 구성 예제

3개의 Task로 구성된 DAG
먼저 t1 실행되고 t2,t3 순으로 순차적 실행

3개의 Task로 구성된 DAG
먼저 t1 실행되고 t2와 t3가 병렬 실행

Airflow 설치 - Docker

묠니르묘묘 — Thu, 23 May 2024 19:01:10 +0900

Apache Airflow 공식 홈페이지 - Running Airflow in Docker 에서 참고하였습니다.

1. 시작 전 (Before you begin)

Docker Community Edition(CE)을 본인 컴퓨터에 설치합니다. OS에 따라 Airflow 컨테이너가 제대로 실행되려면 최소 4.00GB에서 권장 8.00GB 메모리를 사용하도록 Docker를 구성해야 합니다. 자세한 내용은 Windows Docker 또는 Mac Docker 를 참고하세요.
컴퓨터에 Docker Compose v2.14.0 이상 설치해야 합니다. 버전을 확인하려면 `docker compose version` 명령어를 실행하세요.

% docker compose version
Docker Compose version v2.26.1-desktop.1

2. docker-compose.yaml 가져오기

airflow를 설치할 폴더로 이동하여 docker-compose.yaml 파일을 다운로드합니다.

curl -LfO 'https://airflow.apache.org/docs/apache-airflow/2.9.1/docker-compose.yaml'

3. 환경설정 초기화 (Initializing Environment)

Airflow 를 처음 시작하기 전에 환경을 준비해야합니다.

즉, 필요한 파일과 디렉토리를 생성하고 DB를 초기화해야 합니다.

Airflow 사용자 설정 (Setting the right Airflow user)

Linux(리눅스)에서 빠른 시작은 호스트 사용자 아이디를 알아야하고 그룹 아이디가 0으로 설정되어야 합니다.

그렇지 않으면 dags, logs, plugins 에서 생성되는 파일이 루트 사용자 소유권으로 생성됩니다.

mkdir -p ./dags ./logs ./plugins ./config
echo -e "AIRFLOW_UID=$(id -u)" > .env

여기서 저는 디렉토리만 생성하였고, echo 명령어는 실행하지 않았습니다.

리눅스가 아닌 다른 운영체제의 경우 AIRFLOW_UID 가 설정되지 않았다는 경고가 표시될 수 있지만 무시해도 됩니다.

아래 내용이 포함된 .env 파일을 docker-compose.yaml 과 같은 폴더에 수동으로 생성하여 경고를 제거할 수 있습니다.

AIRFLOW_UID=50000

AIRFLOW_UID 의 값은 기본적으로 50000 이 들어갑니다.

지금까지 실행한 명령어 결과

데이터베이스 초기화 (Initialize the database)

모든 운영체제에서 데이터베이스 마이그레이션을 실행하고 첫 번째 사용자 계정을 만들어야 합니다.

docker compose up airflow-init

초기화가 완료되면 다음과 같은 메시지가 표시됩니다.

airflow-init_1 | Upgrades done
airflow-init_1 | Admin user airflow created
airflow-init_1 | 2.9.1
start_airflow-init_1 exited with code 0

이후 생성된 계정 아이디 : airflow , 비밀번호 : airflow 가 만들어집니다.

4. Airflow 시작 (Running Airflow)

이제 아래 명령어로 Airflow를 시작합니다.

docker compose up

`docker ps` 명령어로 모든 프로세스가 동작하는지 확인합니다.

브라우저에서 `http://localhost:8080/` 으로 접근하여 로그인페이지로 이동하는지 확인합니다.

그리고 생성된 계정으로 로그인합니다.

docker ps

Airflow 로그인페이지

airflow 접속

Airflow 컨테이너로 로그인하는 방법

1. `docker ps` 실행하여 airflow-scheduler-1 의 CONTAINER ID 를 추출한다. 아래 이미지에서는 80d7a9eb7b56 이다.

docker ps

2. Container ID ("80d7a9eb7b56")로 `docker exec -it 80d7a9eb7b56 sh` 를 실행하면 쉘 모드로 들어갈 수 있고, 거기서 airflow 명령어를 실행할 수 있다.

airflow 컨테이너 접속

3. root 계정으로 로그인하려면 `docker exec -u 0 -it 80d7a9eb7b56 sh` 를 실행한다.

https://github.com/Sangyong-Jeon/practice_airflow/wiki/Airflow-%EC%84%A4%EC%B9%98-%E2%80%90-Docker

CodeDeploy - CodePipeline 만드는 도중 실패 및 설명

묠니르묘묘 — Sun, 5 May 2024 18:09:04 +0900

1. 실패 이유

CodeDeploy 실패 로그

스프링부트 프로젝트 최상단에 appspec.yml 파일을 만들지 않아서 Deploy가 실패했다.

appspec.yml은 CodeDeploy에서 배포 관리하는데 사용하는 파일이다.

이 파일에 정의된 일련의 수명 주기(lifecycle) 이벤트 후크로 각 배포를 관리하는데 사용된다.

AWS 공식문서 - CodeDeploy 애플리케이션 사양 (AppSpec) 파일 을 참고하면 좋다.

2. appspec.yml 생성

https://www.youtube.com/watch?v=Dofh_X0ta2g

위 규칙대로 정의를 하면 되고, 나는 크게 정의할 필요가 없기에 간단하게 적어본다.

스프링부트 프로젝트 최상단 appspec.yml

이렇게 생성 후 Github에 추가하면 자동으로 우리가 만들었던 CodePipeline이 작동한다.

그럼 Source -> Build -> Deploy 가 자동으로 실행하게 된다.

3. 성공

CodePipeline

나는 codepipeline의 source를 Github 개인 리포지토리로 연결했기에 수정된 사항을 main에 push하면 자동으로 파이프라인이 동작하게 되어 CI/CD가 자동화되는 것이다. 설정하는 단계에서는 복잡했지만 만들고나면 엄청나게 편하다는 것을 느끼게 된다.

4. Code Deploy에 대해서

AWS에서 제공하는 Code Deploy는 3가지 배포 방식을 제공한다.

EC2/온프레미스
Lambda
ECS

AWS CodeDeploy 라이프사이클과 'hooks' 섹션 에 나와있는 내용이지만 학습을 위해 간단하게 적어본다.

AppSpec 파일 'hooks' 섹션의 내용은 위에 적었던 3가지 배포 방식(컴퓨팅 플랫폼)에 따라 다르다.

EC2는 인 플레이스(in-place) 배포와 Blue/Green 배포를 선택할 수 있고,

Lambda와 ECS는 Blue/Green 배포만 가능하다.

나는 EC2를 사용했기에 간단하게 EC2의 Blue/Green(블루/그린) 배포 이벤트 후크를 설명해본다.

https://docs.aws.amazon.com/ko_kr/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png

좌측이 원본 인스턴스 환경이고, 우측이 새로 만들어지는 인스턴스이다.

배포 단계에서 `Start`, `DownloadBundle`, `Install`, `AllowTraffic` , `BlockTraffic` , `End` 처럼 다이어그램이 회색인 단계는 스크립팅(scripting)이 불가능하다. 하지만 appspec.yml의 'files' 섹션을 편집하여 `Install` 이벤트 중에 설치되는 항목을 지정할 수는 있다.

ApplicationStop

이 이벤트에 대한 스크립트를 지정하여 애플리케이션을 정상적으로 중지하거나 배포를 준비하기 위해 현재 설치된 패키지를 제거할 수 있음. (인스턴스에 처음 배포할 때는 동작하지 않음)

DownloadBundle

신규 생성된 파일(application revision files)을 임시 폴더(위치)로 다운로드

BeforeInstall

파일 암호 해독 및 현재 버전의 백업 생성 등의 사전 설치 작업하는 단계

Install

임시 폴더에서 최종 대상 폴더로 생성된 파일(revision files)을 복사함

AfterInstall

애플리케이션 구성 or 파일 권한 변경과 같은 작업하는 단계

ApplicationStart

ApplicationStop 중에 중지된 서비스를 다시 시작함

ValidateService

마지막 배포 수명 주기 이벤트로써, 배포가 성공적으로 완료되었는지 확인함

BeforeBlockTraffic

로드 밸런서에서 등록이 취소되기 전에 인스턴스에서 작업을 실행할 수 있음.

이 단계에서 실패한 배포의 문제를 해결하려면 실패한 ApplicationStop, BeforeBlockTraffic 또는 AfterBlockTraffic 배포 수명주기 이벤트 문제해결을 참조해야함.

BlockTraffic

인터넷 트래픽이 현재 트래픽을 서비스 중인 인스턴스에 액세스하지 못하도록 차단함.

AfterBlockTraffic

이 이벤트를 사용하여 해당 로드밸런서에서 인스턴스 등록이 취소된 후 작업을 실행할 수 있음

이 때 실패한 배포의 문제를 해결하려면 이 링크를 참조하면 됨.

BeforeAllowTraffic

로드밸런서에 등록되기 전에 인스턴스에서 작업을 실행할 수 있음

AllowTraffic

배포 후 인터넷 트래픽이 인스턴스에 액세스할 수 있도록 허용함

AfterAllowTraffic

로드 밸런서에 인스턴스가 등록된 후 인스턴스에서 작업을 실행할 수 있음

CodeBuild - CodePipeline 만드는 도중 build 실패

묠니르묘묘 — Sun, 5 May 2024 16:44:52 +0900

1. 실패 이유

CodeBuild 실패 로그

Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: ./gradlew bootJar. Reason: exit status 1

예전 깃액션(Github Actions)를 사용했을 때와 비슷한 에러여서 금방 찾기도 했고, 메시지에도 적혀져 있어서 바로 해결했다.

아무래도 빌드 사양에서 런타임 버전이 선택되지 않아서 기본값(default) 버전으로 java compile을 시도했지만 버전이 달라 실패했다.

현재 빌드하려는 스프링부트 프로젝트는 JDK 21 버전을 사용하고 있는데, AWS에서는 기본값으로 다른 버전을 사용하나 보다.

그래서 `./graldew bootJar` 가 성공적으로 종료되지 않았다고 적혀있는걸 보고 버전을 명시해줬다.

2. CodeBuild 의 Buildspec 수정

CodeBuild Buildspec

AWS 공식문서의 Runtime versions 에 따라서 변경했으며 여기서 다양한 언어의 사양을 볼 수 있고, 어떻게 변경하는지 적혀있다.

3. 수정 후 성공

CodeBuild Log내용 - 성공

성공적인 로그 기록을 볼 수 있다.

Code Pipeline 성공

장고 활용한 API 서버 만들기(2)

묠니르묘묘 — Tue, 23 Apr 2024 23:08:39 +0900

뷰와 템플릿

SQL order by desc 및 limit 구현 예시
- Question.objects.order_by('-pub_date')[:5]
- order_by 컬럼명 앞 "-"이 있으면 내림차순(desc), 없으면 오름차순(asc)
model에 있는 내용 화면(view)에 출력하는 과정
1. templates/polls/index.html 생성
2. views.py 에서 context 변수에 dict 형태로 선언
  - context = {'first_question' : latest_question_list[0] }
    - 'first_question' 이라는 키와 latest_question_list[0] 이라는 값을 index.html에 전달할 변수
3. index.html에 전달하고자 view.py 에 from django.shortcuts import render 선언
4. index 함수 내 `return render(request, 'polls/index.html', context)` 반환

템플릿에서 제어문 사용하기

{% if 조건 %} 내용 {% elif 조건 %} 내용 {% else %} 내용 {% endif %}
{% for e in elements %} 내용 {% endfor %}

404 에러 처리하기

try-except 처리
get_object_or_404() 처리

폼(Form)과 커스터마이징

<form> 옵션 action과 method 속성 지정
- action="{% url 'polls:vote' question.id %}"
- method="post"
urls.py 에 polls:vote 에 대한 처리 로직 추가
- path('<int:question_id>/vote/', views.vote, name='vote'),
views.py 에 응답 항목에 대한 save 및 예외 처리 로직 추가
- def vote(request, question_id): 추가
- request.POST('choice'] 를 통해 선택한 항목 가져오기
- 예외처리 : 선택하지 않을 경우 try-except-else
  - KeyError 또는 Choice.DoesNotExist 예외 발생시 render의 context에 error_message 추가 전달
    - KeyError 예외 : 선택하지 않은 채 제출
    - Choice.DoesNotExist 예외 : choice id가 제출되는 시점에서 존재하지 않는 경우
  - 정상 요청인 경우 votes += 1 및 save() 이후 Redirect 수행
    - HttpREsponseRedirect(reverse('polls:index'))

Python 문법 - *args, **kwargs

설명 링크
*args : 여러 개의 인자를 묶어서 하나의 튜플로 묵어주고 이를 args에 할당한다고 생각하자
**kwargs : 여러 개의 keyword arguments 들을 묶어서 딕셔너리로 만들어준다고 생각하자

장고 활용한 API 서버 만들기

묠니르묘묘 — Tue, 9 Apr 2024 10:22:47 +0900

Django Project 생성하기

$ django-admin startproject 프로젝트이름

Manage.py

Django 프로젝트를 터미널에서 관리할 수 있도록 명령어를 제공하는 기능의 파일

Django 서버 실행 명령어

$ python manage.py runserver

Django App 생성하기

$ python manage.py startapp polls

특정한 기능을 수행하는 웹 어플리케이션으로 App들이 모여 하나의 Project가 됨
App은 하나의 웹 사이트만 종속되는 것이 아닌, 여러 사이트에서 그 기능을 할 수 있음
`urls.py` 에서 앱 경로를 지정할 수 있음

모델

장고의 모델은 RDB에서 엔티티(테이블)라고 보면 됨
모델을 통해 데이터를 편하게 관리 가능
별도의 SQL 쿼리문 작성 없이 프로그래밍 언어로 데이터의 CRUD 가능

모델 생성

class Question(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    question = models.ForeignKey(Question, on_delete=models.CASCADE)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

두 개의 테이블(엔티티)를 위 코드처럼 만듦.

기본키는 자동으로 AUTOINCREMENT 하는 정수형을 만들어줌.

migration 적용

모델을 생성했으면 스키마에도 구조가 변경된 것을 적용해야함.

$ python manage.py makemigrations polls
$ python manage.py sqlmigrate polls 0001

DB 내용 확인하기

$ sqlite3 db.sqlite3

장고의 DB는 기본적으로 sqlite3을 지원하기에 db.sqlite3 파일을 열어 확인 가능함

migration 롤백

$ python manage.py migrate polls 0001

Django Admin

관리자들이 데이터를 추가하거나 수정하는 페이지
장고에서는 생성한 모델에 대해 웹 페이지에서 데이터를 CRUD하는 기능 지원
`http://127.0.0.1/admin` 으로 접속 가능

관리자 계정 생성하기

$ python manage.py createsuperuser

모델 등록하기

from django.contrib import admin
from .models import Question, Choice

# Register your models here.
admin.site.register(Question)
admin.site.register(Choice)

admin이 접근할 수 있도록 코드 추가함
App 폴더의 admin.py에 위 코드를 추가함
이후 admin 페이지에서 손쉽게 등록 가능

Django shell

$ python manage.py shell

장고의 쉘로 접속하려면 위 명령어를 터미널에서 입력함.

모델 사용하기

>>> from polls.models import *

#모든 Question,Choice 오브젝트 가져오기
>>> Question.objects.all()
>>> Choice.objects.all()

#첫번째 Choice 오브젝트 가져오기
>>> choice = Choice.objects.all()[0]
>>> choice.id
>>> choice.choice_text
>>> choice.votes

#첫번째 Choice와 연결된 Question 가져오기
>>> choice.question
>>> choice.question.pub_date
>>> choice.question.id

Django로 웹서비스를 하고, 글로벌 서비스를 수행한다면 파이썬에서 제공하는 `datetime` 모듈보다는 `timezone` 을 사용하자

새로운 모델 생성하기

#create() 메서드를 활용하여 q3와 연결된 새로운 Choice 오브젝트를 생성하고, choice_text 필드에 값을 넣어주기
>>> q3.choice_set.create(choice_text = "b")

#새로운 Choice 오브젝트를 생성하고 question 필드에 q3 값을 넣어 연결하기
>>> choice_c = Choice(choice_text='c', question=q3)

#새로운 Choice 오브젝트를 데이터베이스에 저장하기
>>> choice_c.save()

레코드 수정 및 삭제하기

>>> from polls.models import *

#Question 오브젝트 중 가장 마지막으로 만들어진 것을 가져오기
>>> q = Question.objects.last()

#해당 오브젝트의 question_text에 새로운 내용을 더해 수정하기
>>> q.question_text = q.question_text + '???'

# DB에 수정내용 적용하기
>>> q1.save() #Choice 오브젝트 중 가장 마지막으로 만들어진 것을 가져오기
>>> choice = Question.objects.last()
>>> choice.queston.choice_set.all()
<QuerySet [<Choice: a>, <Choice: b>, <Choice: c>, <Choice: d>]>

#해당 오브젝트를 삭제하기
>>> choice.delete()
>>> choice.queston.choice_set.all()
<QuerySet [<Choice: a>, <Choice: b>, <Choice: c>>

모델 필터링

>>> Question.objects.get(id=1)
<Question: 제목: 휴가를 어디서 보내고 싶으세요?, 날짜: 2024-04-07 14:34:00+00:00>

# '휴가를' 로 시작하는 행 찾기
>>> q = Question.objects.get(question__startswith='휴가를 ')
>>> q
<Question: 제목: 휴가를 어디서 보내고 싶으세요?, 날짜: 2024-04-07 14:34:00+00:00>

한 개만 가져올 때는 `.get()` 사용

>>> Question.objects.filter(pub_date__year=2024)
<QuerySet [<Question: 제목: 휴가를 어디서 보내고 싶으세요?, 날짜: 2024-04-07 14:34:00+00:00>, <Question: 제목: 가장 좋아하는 디저트는?, 날짜: 2024-04-07 14:34:22+00:00>, <Question: 제목: 커피 vs 녹차, 날짜: 2024-04-08 05:43:35.350925+00:00>, <Question: 제목: abc???, 날짜: 2024-04-08 05:45:30.479683+00:00>]>

여러 개가 반환된다면 `.filter()` 사용
이 경우, QuerySet 이라는 집합으로 결과를 반환함

Seaborn 시각화 라이브러리, 기상청 날씨 정보 시각화, 해시코드 질문태그 빈도 시각화, 단어구름 시각화

묠니르묘묘 — Sat, 6 Apr 2024 18:40:09 +0900

Seaborn 시각화 라이브러리

Python의 데이터 시각화 라이브러리
이를 활용하여 그래프 시각화
%pip install seaborn 으로 설치

Seaborn Essentials

# 시각화에 필요한 라이브러리를 불러와봅시다.
import seaborn as sns

꺾은선 그래프 (Line Plot)

두 변수의 값에 따른 추이를 선으로 이은 그래프
`.lienplot()` 를 이용해서 그릴 수 있음

# Scatterplot을 직접 그려봅시다
sns.lineplot(x=[1, 3, 2, 4], y=[0.7,0.2,0.1,0.05])

막대 그래프 (Bar Plot)

범주형 데이터의 값과 그 값의 크기를 직사각형으로 나타낸 그림
`.bar()` 를 이용해서 그릴 수 있음

# Barplot을 직접 그려봅시다
sns.barplot(x=["amy","bob","cat","dog"],y=[0.7,0.2,0.1,0.05])

Plot 속성

seaborn 은 파이썬 시각화 라이브러리 matplotlib 기반으로 만들어짐
matplotlib.pyplot 의 속성을 변경해서 그래프에 다양한 요소를 변경 및 추가 가능

그래프 제목 추가하기

# matplotlib.pyplot을 불러오기
import matplotlib.pyplot as plt

sns.barplot(x=[1,2,3,4],y=[0.7,0.2,0.1,0.05])

# 그래프 제목 추가하기
plt.title("Bar Plot")

# 보여주기
plt.show()

X, Y Label 추가하기

sns.barplot(x=[1,2,3,4],y=[0.7,0.2,0.1,0.05])

# xlabel과 ylabel 추가하기
plt.xlabel("X Label")
plt.ylabel("Y Label")

plt.show()

그래프 축 범위 지정하기

sns.lineplot(x=[1,3,2,4],y=[4,3,2,1])

# lineplot에서 ylim을 2~3으로 제한해봅시다.
plt.ylim(0, 10)

plt.show()

그래프 크기 지정하기

# 크기를 (20, 10)으로 지정해봅시다.
plt.figure(figsize=(20, 10))
sns.lineplot(x=[1,3,2,4],y=[4,3,2,1])
plt.show()

기상청 날씨 정보 시각화

# 스크래핑에 필요한 라이브러리를 불러와봅시다.

from selenium import webdriver
from selenium.webdriver import ActionChains
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.common.actions.action_builder import ActionBuilder
from selenium.webdriver import Keys, ActionChains
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By

# driver를 이용해 기상청 날씨 데이터를 가져오기
driver = webdriver.Chrome()
driver.get("https://www.weather.go.kr/w/weather/forecast/short-term.do")
driver.implicitly_wait(2)
temps = driver.find_element(By.ID, "my-tchart").text

# 온도에서 "℃" 제거하여 숫자 배열 만들기
temps = [int(i) for i in temps.replace("℃", "").split("\n")]

# 받아온 데이터를 통해 꺾은선 그래프 그려보기
import seaborn as sns

sns.lineplot(
    x = [i for i in range(len(temps))],
    y = temps
)

# 받아온 데이터를 통해 꺾은선 그래프를 그리고, 그래프 축 범위와 제목 지정하기
import matplotlib.pyplot as plt

plt.ylim(min(temps)-2, max(temps) + 2)
plt.title("Expected Temperature from now on")

sns.lineplot(
    x = [i for i in range(len(temps))],
    y = temps
)

plt.show()

해시코드 질문태그 빈도 시각화

# User-Agent 추가
user_agent = {"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36"}

# 필요한 라이브러리를 불러온 후, 요청을 진행
import time
import requests
from bs4 import BeautifulSoup

# 질문의 빈도를 체크하는 dict를 만든 후, 빈도를 체크
frequency = {}

for i in range(1, 11):
    res = requests.get("https://hashcode.co.kr/?page={}".format(i), user_agent)
    soup = BeautifulSoup(res.text, "html.parser")

    # 1. ul 태그를 모두 찾기
    # 2. 1번 안에 있는 li 태그의 text 추출

    ul_tags = soup.find_all("ul", "question-tags")
    for ul in ul_tags:
        li_tags = ul.find_all("li")
        for li in li_tags:
            tag = li.text.strip()
            if tag not in frequency:
                frequency[tag] = 1
            else:
                frequency[tag] += 1
    time.sleep(0.5)

# Counter를 사용해 가장 빈도가 높은 value들을 추출
from collections import Counter

counter = Counter(frequency)

# Seaborn을 이용해 이를 Barplot으로 그리기
import seaborn as sns

x = [elem[0] for elem in counter.most_common(10)]
y = [elem[1] for elem in counter.most_common(10)]

# figure, xlabel, ylabel, title을 적절하게 설정해서 시각화 완성
import matplotlib.pyplot as plt

plt.figure(figsize=(20, 10))
plt.title("Frequency of question in Hashcode")
plt.xlabel("Tag")
plt.ylabel("Frequency")

sns.barplot(x=x, y=y)
plt.show()

뭉게뭉게 단어구름 시각화

wordcloud 라이브러리

Python의 텍스트 클라우드 라이브러리
이를 기반으로 텍스트 구름 그릴 수 있음
konlpy : 한국어 형태소 분석기 라이브러리로, 주어진 문장에서 명사 등을 뽑아 내는 데에 사용 가능
`%pip install wordcloud`
`%pip install konlpy`

# 텍스트 구름을 그리기 위해 필요한 라이브러리를 불러오기

# 시각화에 쓰이는 라이브러리
import matplotlib.pyplot as plt
from wordcloud import WordCloud

# 횟수를 기반으로 딕셔너리 생성
from collections import Counter

# 문장에서 명사를 추출하는 형태소 분석 라이브러리
from konlpy.tag import Hannanum

# 워드클라우드를 만드는 데 사용할 애국가 가사
national_anthem = """
동해물과 백두산이 마르고 닳도록
하느님이 보우하사 우리나라 만세
무궁화 삼천리 화려 강산
대한 사람 대한으로 길이 보전하세
남산 위에 저 소나무 철갑을 두른 듯
바람 서리 불변함은 우리 기상일세
무궁화 삼천리 화려 강산
대한 사람 대한으로 길이 보전하세
가을 하늘 공활한데 높고 구름 없이
밝은 달은 우리 가슴 일편단심일세
무궁화 삼천리 화려 강산
대한 사람 대한으로 길이 보전하세
이 기상과 이 맘으로 충성을 다하여
괴로우나 즐거우나 나라 사랑하세
무궁화 삼천리 화려 강산
대한 사람 대한으로 길이 보전하세
"""

# 형태소 분석기 객체를 사용하여 주어진 문자열에서 명사 추출하기
# Hannanum 객체를 생성한 후, .nouns()를 통해 명사를 추출
hannanum = Hannanum()
nouns = hannanum.nouns(national_anthem)
words = [noun for noun in nouns if len(noun) > 1]

# counter를 이용해 각 단어의 개수를 세기
counter = Counter(words)

# WordCloud를 이용해 텍스트 구름을 만들기
# 이 때, font_path는 한글을 그려주기 위한 폰트를 지정해야해서 각 컴퓨터의 폰트경로 지정
wordcloud = WordCloud(
    font_path="/Users/yong/Library/Fonts/함초롱돋움R.ttf",
    background_color="white",
    width=1000,
    height=1000
)

img = wordcloud.generate_from_frequencies(counter)
plt.imshow(img)

Selenium, WebDriver, Implicit / Explicit Wait, Mouse Event, Keyboard Event

묠니르묘묘 — Sat, 6 Apr 2024 17:59:54 +0900

Selenium 라이브러리

Python을 이용해서 웹 브라우저를 조작할 수 있는 자동화 프레임워크
%pip install selenium 으로 설치
- % 를 이용해서 노트북(.ipynb) 환경에서 터미널 코드 실행 가능

Web Driver

웹 브라우저를 제어할 수 있는 자동화 프레임워크
%pip install webdriver-manager 으로 설치
Chrome (크롬) 브라우저를 사용하기에 크롬 설치 필수

# selenium 으로부터 webdriver 모듈 불러오기
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

# webdriver에서 Chrome() 객체 생성
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()))
# driver = webdriver.Chrome()

# http://www.example.com 으로 요청 보내기
driver.get("http://www.example.com")

# page_source 속성을 통해 Response의 HTML 문서 확인하기
print(driver.page_source)

위 코드 실행 시, Chrome 창이 계속 켜져있음.

이는 해당 창을 끄라고 명령을 내린 적이 없기 때문임.

# with-as 를 사용해서 창을 끄도록 해보자
with webdriver.Chrome(service=Service(ChromeDriverManager().install())) as driver:
    driver.get("http://www.example.com")
    print(driver.page_source)

with 안의 코드가 실행되면 자동으로 Chrome 창이 닫아짐

Driver 에서 특정 요소 추출하기

selenium 은 받아온 응답으로부터 특정 요소 추출 가능
요소 하나 찾기
- .find_element(by, target)
  - by : 대상을 찾는 기준 ( ID, TAG_NAME, CLASS_NAME …)
  - target : 대상의 속성
요소 여러개 찾기
- .find_elements(by, target)
  - by : 대상을 찾는 기준 ( ID, TAG_NAME, CLASS_NAME …)
  - target : 대상의 속성

# By 를 import 하기
from selenium.webdriver.common.by import By

# <p> 해당하는 요소 하나를 찾아보기
with webdriver.Chrome(service=Service(ChromeDriverManager().install())) as driver:
    driver.get("http://www.example.com")
    print(driver.find_element(By.TAG_NAME, "p").text)
    
# <p> 해당하는 요소 여러개 찾아보기
with webdriver.Chrome(service=Service(ChromeDriverManager().install())) as driver:
    driver.get("http://www.example.com")
    for element in driver.find_elements(By.TAG_NAME, "p"):
        print("Text:", element.text)

Implicit Wait (암시적 기다림)

특정 요소에 대한 제약을 통한 기다림
로딩이 다 될 때까지의 한계 시간의 의미를 가지는 것
e.g. 이 태그를 가져올 수 있을 때까지 기다리기
`.implicitly_wait()` 를 활용하여 사용

Explicit Wait

다 로딩일 될 때까지 지정한 시간동안 기다리기
`WebDriverWait()` 와 아래 메서드를 활용하여 사용 가능
- `until()` : 인자의 조건이 만족될 때까지
- `until_not()` : 인자의 조건이 만족되지 않을 때까지
e.g. 다 로딩이 될 때까지 5초동안 기다리기

XPath 란?
- XML, HTML 문서 등의 요소의 위치를 경로로 표현하는 것
- 마치`데스크탑/폴더1/폴더2/음악.mp3` 같은 경로

# 스크래핑에 필요한 라이브러리를 불러와봅시다.

from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from webdriver_manager.chrome import ChromeDriverManager

# 예시 사이트에 요청을 진행하고, 예시 사이트의 첫 번째 이벤트의 제목을 가져와봅시다.
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()))
driver.get("https://indistreet.com/live?sortOption=startDate%3AASC")

# XPath를 이용해서 특정 위치의 값 가져오기
# 이 때, 동적 페이지이기 때문에 스크래핑 시 데이터가 없어서 오류가 날 수 있음
# 따라서 Wait를 넣어줘야함
driver.find_element(By.XPATH, '//*[@id="__next"]/div/main/div[2]/div/div[4]/div[1]/div[1]/div/a/div[2]/p[1]').text

# Implicit Wait를 사용하기 위해 import하기
from selenium.webdriver.support.ui import WebDriverWait

# 10초동안 Implicit Wait를 진행하여 스크래핑이 잘 이루어지도록 수정
with webdriver.Chrome(service=Service(ChromeDriverManager().install())) as driver:
    driver.get("https://indistreet.com/live?sortOption=startDate%3AASC")
    driver.implicitly_wait(10)
    print(driver.find_element(By.XPATH, '//*[@id="__next"]/div/main/div[2]/div/div[4]/div[1]/div[1]/div/a/div[2]/p[1]').text)
    
# EC는 selenium에서 정의된 조건들
# EC의 expected_conditions는 '~가 존재하면' 이라는 의미
from selenium.webdriver.support import expected_conditions as EC

with webdriver.Chrome(service=Service(ChromeDriverManager().install())) as driver:
    driver.get("https://indistreet.com/live?sortOption=startDate%3AASC")
    # explicit wait으로 변경하여, 특정 요소가 존재할 때까지 10초동안 기다리기
    element = WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.XPATH, '//*[@id="__next"]/div/main/div[2]/div/div[4]/div[1]/div[1]/div/a/div[2]/p[1]')))
    print(element.text)

Mouse Event (마우스 이벤트) 처리하기

# 스크래핑에 필요한 라이브러리를 불러와봅시다.

from selenium import webdriver
from selenium.webdriver import ActionChains
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By
from webdriver_manager.chrome import ChromeDriverManager

# 주어진 웹사이트를 누른 후, 우리가 원하는 버튼 요소를 찾은 후 마우스 이벤트를 실행시켜봅시다.
driver = webdriver.Chrome(service=Service(ChromeDriverManager().install()))
driver.get("https://hashcode.co.kr")
driver.implicitly_wait(2)

# 로그인 버튼 찾기
button = driver.find_element(By.CLASS_NAME, 'UtilMenustyle__Link-sc-2sjysx-4.ewJwEL')
# 로그인 버튼 클릭하기
ActionChains(driver).click(button).perform()

위 코드 실행 시, hashcode 홈페이지가 켜지고, 그 페이지에 있는 로그인 버튼 자동 클릭

Keyboard Event (키보드 이벤트) 처리하기

# 스크래핑에 필요한 라이브러리를 불러와봅시다.

from selenium import webdriver
from selenium.webdriver import ActionChains
from webdriver_manager.chrome import ChromeDriverManager
from selenium.webdriver.common.actions.action_builder import ActionBuilder
from selenium.webdriver import Keys, ActionChains
from selenium.webdriver.chrome.service import Service
from selenium.webdriver.common.by import By

import time

driver = webdriver.Chrome()
driver.get("https://hashcode.co.kr")
time.sleep(0.5)

# 내비게이션 바에서 "로그인" 버튼을 찾아서 눌리기
button = driver.find_element(By.CLASS_NAME, 'UtilMenustyle__Link-sc-2sjysx-4.ewJwEL')
ActionChains(driver).click(button).perform()
time.sleep(0.5)

# "아이디" input 요소에 아이디 입력하기
id_input = driver.find_elements(By.CLASS_NAME, "FymRFM681OjzOdzor5nk")[0]
ActionChains(driver).send_keys_to_element(id_input, "아이디@gmail.com").perform()
time.sleep(0.5)

# "패스워드" input 요소에 비밀번호 입력하기
pw_input = driver.find_elements(By.CLASS_NAME, "FymRFM681OjzOdzor5nk")[1]
ActionChains(driver).send_keys_to_element(pw_input, "비밀번호").perform()
time.sleep(0.5)

# "로그인" 버튼을 눌러서 로그인 완료하기
login_button = driver.find_element(By.CLASS_NAME, "itAWTII94uCyf9uUgREi")
ActionChains(driver).click(login_button).perform()
time.sleep(0.5)

위 코드 실행 시, 홈페이지 켜서 로그인 버튼 눌려서 로그인 화면 들어가고, 아이디와 비밀번호 입력하여 로그인 완료시킴

Python - Web Scraping 기초 (BeautifulSoup4 라이브러리)

묠니르묘묘 — Wed, 3 Apr 2024 22:26:44 +0900

BeautifulSoup4 라이브러리

HTML 코드를 분석해주는 HTML Parser 사용 가능

# pip를 사용해 라이브러리 설치
%pip install bs4

# 사이트에 요청한 후 응답 받기
import requests

res = requests.get("http://www.example.com")

# BeautifulSoup4 - bs4 불러오기
from bs4 import BeautifulSoup

# BeautifulSoup 객체 생성하기. 
# 첫번째 인자는 response의 body를 텍스트
# 두번째 인자는 "html"로 분석한다는 것을 명시
soup = BeautifulSoup(res.text, "html.parser")

# 객체 soup의 .prettify()를 활용하여 분석된 HTML을 보기 편하게 반환하기
print(soup.prettify())

위 코드의 마지막 실행 내역

이제 위 코드의 soup로 조작하여 HTML에 쉽게 접근할 수 있다.

# title 가져오기
soup.title

# head 가져오기
soup.head

# body 가져오기
soup.body

# <h1> 태그로 감싸진 요소 찾기
h1 = soup.find("h1")

# 태그 이름 가져오기
h1.name

# 태그 내용 가져오기
h1.text

# <h3> 태그로 감싸진 모든 요소 찾기
h3_result = soup.find_all("h3")

# <h3> 태그로 감싸진 모든 요소의 내용 추출하기
for t in h3_result:
	print(t.text)
    
# id가 results인 div 태그 찾기
soup.find("div", id="results")

# class가 "page-header"인 div 태그 찾기
find_result = soup.find("div", "page-header")

# Pagination이 되어있는 hashcode 질문 리스트의 제목을 모두 가져오기
# 과도한 요청 방지로 1초마다 요청을 보냄
import time

for i in range(1, 6):
    res = requests.get("https://hashcode.co.kr/?page={}".format(i), user_agent)
    soup = BeautifulSoup(res.text, "html.parser")
    questions = soup.find_all("li", "question-list-item")
    for question in questions:
        print(question.find("div", "question").find("div", "top").h4.text)
    time.sleep(0.5)

네트워크, HTTP, Web Scraping, robots.txt, DOM

묠니르묘묘 — Tue, 2 Apr 2024 19:06:02 +0900

네트워크

네트워크란 컴퓨터끼리 연결해서 데이터를 교환하는 시스템
네트워크를 묶어 근거리 지역 네트워크(Local Area Network, LAN) 탄생
범지구적으로 연결된 네트워크인 Inter Network - 인터넷(Internet) 탄생
- 인터넷 : 여러 컴퓨터끼리 네트워크를 연결한 것
인터넷에서 정보를 교환할 수 있는 환경 WWW(World Wide Web, Web) 탄생

Web 상에서 정보를 주고받는 방법?

클라이언트-서버 구조

클라이언트(브라우저)와 서버가 HTTP를 통해 서로 통신을 함

클라이언트(Client) : 정보를 요청하는 곳
서버(Server) : 정보를 제공하는 곳

HTTP는 웹에서 클라이언트와 서버 사이에 필요한 정보는 헤더로 주고받고, HTML 또는 Image 같은 실제 데이터는 페이로드 부분에 받을 수 있도록 설계됨

웹 브라우저는 HTML 요청을 보내고, HTTP 응답에 담긴 HTML 문서를 화면에 그려주는 역할 담당

HTTP (HyperText Transfer Protocol)

HTTP의 자세한 내용은 이 글을 참고하자

HTTP 구조

웹 상에서 정보를 주고 받을 수 있는 프로토콜
웹은 HTTP 프로토콜을 통해 전달되므로 HTTP 성능 개선하면 웹 성능도 향상
기본적으로 HTTP는 애플리케이션 계층으로써 웹 서비스 통신에 사용

HTTP Request(요청)

클라이언트가 서버로 보내는 요청
HTTP Method : GET, POST, PUT, DELETE 등 주로 사용
- <form> 에는 GET, POST만 사용 가능
- RESTful 서버의 특징은 위 메서드를 다양하게 활용하여 리소스를 조작하는 것
HTTP Body : 데이터 (string, jsonstring, binaryfile 등)
HTTP Header : 보안, 브라우저 정보 등

HTTP Response(응답)

Status Code
- 200 : 성공
- 404 : 리소스 찾을 수 없음
- 400 : 실패
- ...
HTTP Body : 데이터 (주로 HTML 또는 JSON, File)
HTTP Header : Content-Type, Content-Encoding 등

HTTP GET

주로 리소스 조회로 사용
서버에 전달하고 싶은 데이터는 query(쿼리 파라미터, 쿼리 스트링)를 통해 전달
메시지 바디를 사용해서 데이터 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장 X

HTTP POST

주로 요청 데이터 처리지만, 범용적으로 쓰임
- PUT, PATCH 등과 같은 메서드를 사용하지 않고 오직 GET, POST만 사용하는 경우도 있음
메시지 바디를 통해 서버로 요청 데이터 전달
주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

Web Scraping 기초

웹 스크래핑 : 특정 목적으로 특정 웹 페이지에서 데이터를 추출하는 것
- e.g. 날씨 데이터 가져오기, 주식 데이터 가져오기
웹 크롤링 : URL을 타고 다니며 반복적으로 데이터를 가져오는 과정 (데이터 색인)
- e.g. 검색 엔진의 웹 크롤러

고려해야 할 점
1. 웹 스크래핑/크롤링을 통해 어떤 목적을 달성하고자 하는가?
2. 나의 웹 스크래핑/크롤링이 서버에 영향을 미치지 않는가?

robots.txt 란?

웹 사이트 및 웹 페이지를 수집하는 로봇들의 무단 접근을 방지하기 위해 만들어진 로봇 배제 표준(robots exclusion standard)이자 국제 권고안
접근 제어 : 웹 사이트에 대한 크롤러의 접근 제한 또는 허용 및 금지 가능
크롤러 지침 제공 : 특정 경로에 대한 크롤링을 어떻게 처리해야하는지 지시 가능

브라우저는 사용자 에이전트(user agent) 정보를 받아서 사용자인지 로봇인지 판별함

User-Agnet : 규칙이 적용되는 대상 사용자 에이전트
Disallow : 크롤링을 금지할 웹 페이지
Allow : 크롤링을 허용할 웹 페이지

DOM (Document Object Model)

웹 페이지의 구조화된 표현을 나타내는 브라우저의 프로그래밍 인터페이스
HTML, XML 등 문서의 구조를 표현하며, 이를 사용하여 JS 같은 스크립트 언어를 사용하여 문서의 내용, 구조 및 스타일을 동적으로 조작 가능
DOM은 계층적인 트리 구조로 표현됨
웹 브라우저는 HTML 문서를 받아와서 이를 파싱하여 DOM 트리를 생성하고, 이 DOM 트리를 사용하여 렌더링 엔진을 통해 화면에 웹 페이지를 표시함

브라우저는 왜 HTML을 DOM으로 변경할까?

원하는 요소를 동적으로 쉽게 변경하려고
원하는 요소를 쉽게 찾을 수 있으므로

HTML

묠니르묘묘 — Tue, 2 Apr 2024 13:02:57 +0900

HTML 기본 문법

콘텐츠를 가지는 태그
<div> 콘텐츠 </div>

콘텐츠를 가지지 않는 태그
<br />

속성과 값

HTML 기본 문서 형식

부모요소 자식요소

들여쓰기 내어쓰기 주의

들여쓰기와 내어쓰기를 제대로 안해도 컴퓨터는 해석 가능
하지만 개발자 간 코드 해석을 위해 잘 지키자

주석

시작 태그 : <!--

종료 태그 : -->

<!-- 주석은 이렇게 사용 -->

<head>

사람 눈에 보이지 않는 문서의 정보가 담기는 영역

메타 데이터 추가 설명

문서 내용의 외형에 영향을 주는 태그

<body>

사람 눈에 실제로 보이는 콘텐츠 영역

block (블록 레벨 요소)

레고 블록처럼 쌓이고 화면 너비가 꽉차는 요소

<div>, <article>, <section> 등

inline (인라인 레벨 요소)

블록 요소 내 포함되는 요소

<span> , <a> , <strong> 등

inline-block

글자처럼 취급되나 block 태그의 성질을 가지는 요소

레이아웃

HTML5 부터 태그를 의미있게 사용하기 위해 "Semantic" 태그 사용
div만 사용했을 때 원하는 내용을 찾기 힘들기 때문

레이아웃 태그 예시

<div> : 가장 흔히 사용되는 레이아웃 태그, 단순 구역을 나누기 위한 태그

<header> : 블로그 글 제목, 작성일 등 주요 정보를 담는 태그

<footer> : 페이지의 바닥줄에 사용되며 저작권 정보, 연락처 등 부차적 정보를 담는 태그

<main> : 페이지의 가장 큰 부분, 사이트의 주요 콘텐츠를 담는 태그 (한페이지에 한 번만 사용)

<section> : 컨텐츠 구역을 나누는 태그

<article> : 블로그 포스트, 뉴스 기사와 같은 독립적인 문서를 전달하는 태그

<aside> : 문서의 주요 내용에 간접적인 정보 전달을 하는 태그

멀티미디어

<img> : 문서 내 이미지를 넣을 수 있는 태그

src : 이미지 경로 지정
alt : 이미지 로딩 실패 시 대체 텍스트 표시

<figure> , <figcaption> : 하나의 독립적인 컨텐츠로 분리하고, 설명을 넣을 수 있는 태그

figcaption 태그를 사용해 컨텐츠의 설명 추가

<vidio> : 문서 내 영상 첨부 태그

src : 비디오 경로 지정
poster : 비디오 로드 전에 포스터 표시
<source> : 여러 타입의 비디오 제공 가능
autoplay : 자동 재생 속성

<audio> : 문서에 소리 첨부

리스트

<ul>, <li> : 순서가 없는 리스트 (정렬x), 기본 불릿 형식으로 목록 표시

<li> : 목록 구성 및 다양한 태그 포함 가능
<ul> : 자식 요소로는 li 태그만 가능하고, 하위 리스트 생성 시 li 태그 안에 ul 태그 사용

<ol>, <li> : 순서가 있는 리스트 (정렬o), 기본 숫자(1,2,3) 형식으로 목록 표시

테이블

<tr> : 행 구분 - row
<td> : 열 구분 - cell
<th> : 열 제목 태그 (자동으로 bold + 가운데 정렬)
<thead> : th 태그를 넣어서 그루핑, 여러번 사용 X
<tbody> : 여러 열의 행을 넣어서 본문 요소를 그룹, 여러번 사용 X
<tfoot> : 여러 열의 행을 넣어서 바닥글 요소 표현

<table>
	<thead>
		<tr>
			<th>cell 셀의 제목1</th>
			<th>cell 셀의 제목2</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td colspan="2">cell 셀1</td> <!-- 셀 병합 -->
		</tr>
		<tr>
			<td>cell 셀1</td>
			<td>cell 셀2</td>
		</tr>
		<tr>
			<td>cell 셀1</td>
			<td>cell 셀2</td>
		</tr>
        <tr>
			<td>cell 셀1</td>
			<td>cell 셀2</td>
		</tr>
	</tbody>
	<tfoot>
		<tr>
			<td>마지막</td>
			<td>tfoot</td>
		</tr>
	</tfoot>
</table>

테이블 코드 예시

Form 양식 태그

정보를 제출하기 위한 태그
입력 및 선택할 수 있는 input, selectbox, textarea 등 가질 수 있음
action 속성으로 정보 제출되었을 때 페이지를 이동 가능
method 속성으로 정보 제출되었을 때 처리방식 결정 가능

<body>
	<form action="chapter05-form-result.html" method="post">
		<input name="id" type="text">
		<input name="password" type="password">
		<select name="opt">
			<option>옵션 1</option>
			<option>옵션 2</option>
			<option>옵션 3</option>
			<option>옵션 4</option>
			<option>옵션 5</option>
		</select>
		<button type="submit">전송!</button> <!-- 기본 타입: submit-->
	</form>
</body>

<label> : input, selectbox 등 설명을 작성하는 태그

<input> : 사용자에게 데이터를 입력받을 수 있는 태그

<select> : 옵션 메뉴를 제공하는 태그

<textarea> : 여러 줄을 입력할 수 있는 대화형 태그

<button> : 클릭 가능한 버튼을 태그로 form 태그 내에 어디서든 사용 가능

힙, 동적계획법, DFS, BFS, PEP8 스타일, Tim Sort

묠니르묘묘 — Mon, 1 Apr 2024 12:18:26 +0900

데이터 엔지니어링 데브코스 Day 5

- 자료구조 및 알고리즘 풀기 5

힙(Heap) 대표 문제 : 더 맵게

import heapq

def solution(scoville, K):
    answer = 0
    heapq.heapify(scoville) # 리스트를 힙으로 변환
    while scoville[0] < K:
        if len(scoville) < 2:
            return -1
        min1 = heapq.heappop(scoville) # 가장 작은 원소
        min2 = heapq.heappop(scoville) # 두번째 작은 원소
        new_scoville = min1 + (min2 * 2)
        heapq.heappush(scoville, new_scoville)
        answer += 1
    return answer

동적계획법 (DP, Dynamic Programming)

주어진 최적화 문제를 재귀적인 방식으로 보다 작은 부분 문제로 나누어 부분 문제를 풀어, 이 해를 조합하여 전체 문제의 해답에 이르는 방식
알고리즘의 진행에 따라 탐색해야 할 범위를 동적으로 결정함으로써 탐색 범위를 한정할 수 있음
동적 계획법도 그리디 알고리즘처럼 최적 부분 구조 조건(Optimal Substructure)를 지닌 중복된 하위 문제들(Overlapping Subproblems)을 분할 정복으로 풀이하는 문제해결 패러다임

대표 문제 : N으로 표현

def solution(N, number):
    s = [set() for _ in range(8)]
    
    for i, x in enumerate(s, start=1):
        x.add(int(str(N) * i))
        
    for i in range(len(s)):
        for j in range(i):
            for op1 in s[j]:
                for op2 in s[i-j-1]:
                    s[i].add(op1 + op2)
                    s[i].add(op1 - op2)
                    s[i].add(op1 * op2)
                    if op2 != 0:
                        s[i].add(op1 // op2)
        if number in s[i]:
            answer = i + 1
            break
    else:
        answer = -1
            
    return answer

PEP8 스타일 가이드

파이썬 개선 제안서, 파이썬 코드를 어떻게 구상할 지 알려주는 스타일 가이드
다른 사람과 원활하게 협업하려면 공통된 스타일 공유 필요
일관성 있는 스타일은 나중에 수정하기 쉬움

whitespace

한 줄의 문자 길이가 79자 이하여야 함
함수와 클래스는 빈 줄 두개로 구분함
클래스에서 메서드는 빈 줄 하나로 구분함
변수 할당 앞 뒤에 스페이스를 하나만 사용
리스트 인덱스, 함수 호출, 키워드 인수 할당에는 스페이스를 사용 X

naming

함수, 변수, 속성 : lowercase_underscore , 소문자로만 이루어지고 단어 사이 구분은 _ 으로 함
보호(protected) 인스턴스 속성 : _leading_underscore , 언더바로 시작하고 구분은 _ 으로 함
비공개(private) 인스턴스 속성 : __double_leading_underscore , 더블 언더바로 시작하고 구분은 _ 로 함
클래스와 예외 : CapitalizeWord , 단어의 첫글자들을 대문자로 표시 (Carmel Case)
모듈 수준 상수 : ALL_CAPS , 전부 대문자
클래스의 인스턴스 메서드에서는 첫번째 파라미터 (해당 객체 참조)의 이름을 self로 지정
클래스 메서드에서는 첫 번째 파라미터 (해당 클래스 참조)의 이름을 cls 로 지정

표현식과 문장

if no a is b 보다는 if a is not b 를 사용
if not somelist 처럼 빈 값은 암시적으로 False가 된다고 가정
if somelist 처럼 값이 있는 리스트는 암시적으로 True가 된다고 가정
한 줄로 된 if문, for, while loop, except 복합문을 쓰지 않음
항상 파일의 맨 위에 import 문을 놓음
모듈 임포트시에는 항상 모듈의 절대 이름을 사용 import foo 대신 from bar import foo
상대적인 임포트를 해야 한다면 명시적인 구문을 서서 from . import foo 라고 함
import 순서 : 표준 라이브러리 모듈 → 서브파티 모듈 → 자신이 만든 모듈 / 각각의 하위 섹션에서는 알파벳 순서

Tim Sort

Tim Sort의 갤로핑 모드(Galloping Mode) 덕분에 배상 비용 최소화 문제에서 sort를 써도 통과 가능

비교 정렬 알고리즘 시간복잡도

평균적으로 느린 정렬 알고리즘 : Bubble Sort, Insertion Sort
평균적으로 빠른 정렬 알고리즘 : Heap Sort, Merge Sort, Quick Sort

시간 복잡도가 O(n log n)이라는 말은 실제 동작 시간은 C * n log n + a 라는 의미이다.

C라는 상수가 곱해져 있어서 이 값에 큰 영향을 끼치는 요소로 '알고리즘이 참조 지역성(Locality of Reference) 원리를 얼마나 잘 만족하는가?' 가 있음.

참조 지역성 원리란, CPU가 미래에 원하는 데이터를 예측하여 속도가 빠른 캐시 메모리에 담아 놓는데 이 때의 예측률을 높이기 위해 사용하는 원리

평균적으로 빠른 알고리즘도 상수 C의 값이 너무 커지지 않게 동작하며, 추가 메모리도 많이 사용하지 않고, 최악의 경우 O(n log n)으로 동작하는 정렬 알고리즘이 필요했다.

Tim Sort 등장

2002년 소프트웨어 엔지니어 Tim Peters에 의해 등장
수많은 종류의 실세계 데이터에 잘 수행하도록 설계된 하이브리드형 안정 정렬 알고리즘
Insertion Sort + Merge Sort 결합하여 만든 정렬
- Binary Insertion Sort 사용
실생활 데이터 특성을 고려하여 최선 O(n), 평균 O(n log n), 최악 O(n log n)
파이썬 2.3 이후 버전, Java SE 7, Android, Google chrome V8 등 많은 언어에서 표준 정렬 알고리즘으로 채택되어 사용
전체를 작은 덩어리로 잘라 각각의 덩어리를 Insertion Sort로 정렬한 뒤 병합하면 좀 더 빠르지 않을까 하는 것이 기본적인 아이디어

출처 : https://d2.naver.com/helloworld/0315536

DFS (깊이우선탐색, Depth-First Search)

한 정점에서 인접한 모든 (아직 방문하지 않은) 정점을 방문하되, 각 인접 정점을 기준으로 깊이 우선 탐색을 끝낸 후 다음 정점으로 진행
스택(Stack)을 이용하여 어느 정점에서 DFS를 하고 있는지를 기억하고 되돌아감

BFS (너비우선탐색, Breadth-First Search)

한 정점에서 인접한 모든 (아직 방문하지 않은) 정점을 방문하고, 방문한 각 인접 정점을 기준으로 (방문한 순서에 따라) 또 다시 너비 우선 탐색을 행함
큐(Queue)를 이용하여 어느 정점에서 BFS를 해야 하는지를 기록하고 진행

대표 문제 : 여행 경로

from collections import defaultdict

def solution(tickets):
    routes = defaultdict(list)
    for start, end in tickets:
        routes[start].append(end)
    for r in routes:
        routes[r].sort(reverse=True)
    stack = ["ICN"]
    path = []
    while stack:
        top = stack[-1]
        if top not in routes or not routes[top]:
            path.append(stack.pop())
        else:
            stack.append(routes[top].pop())
    return path[::-1]

해시, 그리디

묠니르묘묘 — Thu, 28 Mar 2024 18:01:28 +0900

데이터 엔지니어링 데브코스 Day 4

- 자료구조 및 알고리즘 풀기 4

해시 (Hash)

해시

해시 함수(hash function)로도 불리며, 임의의 길이를 갖는 임의의 데이터를 고정된 길이의 데이터로 매핑하는 단방향 함수
- 아무리 큰 숫자를 넣어도 고정된 크기의 숫자가 나옴
- 단방향 함수이기에 출력된 값을 통해 입력값을 알 수 없음
키(key)를 해시 함수로 돌려 나온 해시 값에 따라 해시 테이블(hash table)에 저장
입력된 값이 조금만 변해도 결과가 크게 달라지는 특성 (눈사태 효과, Avalanche Effect)
서로 다른 입력값에도 동일한 값이 출력되는 경우가 있음 (해시 충돌, Hash Collision)
- 입력에 비해 출력의 범위가 작기 때문
- 이 경우, Separate Chaining 또는 Open Addressing 등의 방법을 사용하여 방지

https://ssdragon.tistory.com/132 에서 조금 더 자세히 알 수 있습니다.

✏️ 파이썬의 대표적인 해시 자료구조인 딕셔너리(Dictionary)

딕셔너리는 해시 테이블을 기반으로 구현된 자료구조
딕셔너리는 키(key)와 값(value)의 쌍으로 이루어져 있으며, 각 키는 고유함
딕셔너리는 해시 함수를 사용하여 각 키를 해시 값으로 변환하고, 해시 값으로 딕셔너리 내부의 해시 테이블에서 해당 키와 연관된 위치를 결정하는 데 사용함
빠른 검색 및 삽입 보장

✏️ 해시의 대표 문제 : 완주하지 못한 선수

def solution(participant, completion):
    d = {}
    for x in participant:
        d[x] = d.get(x, 0) + 1
    for x in completion:
        d[x] -= 1
    dnf = [k for k, v in d.items() if v > 0]
    return dnf[0]

그리디 (Greedy)

탐욕 알고리즘 or 욕심쟁이 알고리즘으로 불림
말 그대로 욕심쟁이라서 선택의 순간마다 최적의 선택을 하여 전체적으로 최적이길 바라는 방법
선택의 순간마다 최적의 선택을 했다하여 그것이 최적의 해답이라는 보장 X

탐욕 알고리즘을 적용하기 위한 2가지 조건

탐욕스러운 선택 조건 (Greedy Choice Property) : 앞의 선택이 이후의 선택에 영향을 주지 않음
최적 부분 구조 조건 (Optimal Substructure) : 문제에 대한 최적해가 부분 문제에 대해서도 최적해라는 것

https://ssdragon.tistory.com/114 에서 조금 더 자세히 알 수 있습니다.

✏️ 그리디의 대표적인 문제 : 체육복

def solution(n, lost, reserve):
    s = set(lost) & set(reserve)
    l = set(lost) - s # 체육복 빌려야하는 집합
    r = set(reserve) - s # 체육복 빌려줄 수 있는 집합
    
    for x in sorted(r):
        if x - 1 in l:
            l.remove(x-1)
        elif x + 1 in l:
            l.remove(x+1)
    
    return n - len(l)

큐, 트리, 힙

묠니르묘묘 — Wed, 27 Mar 2024 17:58:08 +0900

데이터 엔지니어링 데브코스 Day 3

- 자료구조 및 알고리즘 풀기 3

큐 (Queue)

큐

자료를 보관할 수 있는 선형 구조
자료를 넣을 때에는 한 쪽 끝에서 넣고, 꺼낼 때는 반대쪽에서 꺼냄
- 넣는 것은 인큐(enqueue) 연산
- 빼는 것은 디큐(dequeue) 연산
선입선출 (FIFO, First-In-First-Out) 특징을 가지는 선형 자료구조
e.g. 프린트에 인쇄할 문서 보낼 때, 대기열 등

환형 큐 (Circular Queue)

환형 큐, 원형 큐

원형 큐라고도 불림
큐의 한 종류로 원형 구조를 갖추어 FIFO 방식을 사용
정해진 개수의 저장 공간을 돌려가며 사용
원형으로 데이터를 저장하며 앞과 뒤가 연결되어 순환
Front는 큐의 맨 앞 요소를 가리키고, Rear는 큐의 맨 뒤 요소를 가리킴
- 데이터 추가하면 Rear 이동
- 데이터 제거하면 Front 이동

우선순위 큐 (Priority Queue)

우선순위 큐

저장되는 데이터는 우선순위를 가지며, 가장 높은 우선순위를 가진 데이터가 항상 먼저 꺼내지게 됨
일반 큐와는 달리 들어간 순서가 아닌, 데이터의 우선순위에 따라 처리됨
Enqueue 할 때 우선순위 순서를 유지하는 방법과 Dequeue 할 때 우선순위 높은 것을 선택하는 방법이 있지만 전자가 효율적
e.g. CPU 작업 스케줄링, 네트워크 라우팅 등

트리 (Tree)

트리의 종류

트리

계층적인 구조를 갖는 비선형 자료구조
노드들이 간선으로 연결되어 있음
하나의 루트 노드에서 시작하여 여러 개의 자식 노드를 갖는 부모-자식 관계로 구성
각 노드는 자식 노드를 가질 수 있고, 각각의 자식 노드는 또 다시 자식 노드들을 가질 수 있음

이진 트리 (Binary Tree)

이진트리

트리의 종류 중 하나로 모든 노드의 차수가 2 이하인 트리

포화 이진 트리 (Full Binary Tree)

포화 이진 트리

모든 레벨에서 노드들이 모두 채워져 있는 이진 트리
모든 내부 노드가 두 개의 자식을 가진 이진 트리
내부 노드가 0개 또는 2개의 자식을 가짐

완전 이진 트리 (Complete Binary Tree)

완전 이진 트리

모든 레벨에서 노드가 왼쪽에서 오른쪽으로 채워진 이진 트리
마지막 레벨을 제외한 모든 레벨에서 노드가 가득 차있고, 마지막 레벨에서는 왼쪽부터 순서대로 노드가 채워짐

넓이 우선 순회 (Breadth First Traversal)

넓이 우선 순회

수준(level)이 낮은 노드를 우선 방문
루트 노드에서 시작하여 각 레벨의 노드를 왼쪽에서 오른쪽으로 방문

이진 탐색 트리 (Binary Search Tree)

이진 탐색 트리

각 노드의 왼쪽 하위 트리에는 해당 노드 값보다 작은 값들만, 오른쪽 하위 트리에는 해당 노드 값보다 큰 값들만 위치하는 이진 트리
데이터를 빠르게 검색할 수 있다는 장점
트리가 균형을 이루지 않으면 검색 성능이 저하될 수 있음
- 이를 해결하기 위해 AVL 트리, 레드-블랙 트리 등의 균형 이진 탐색 트리가 이용됨

힙 (Heap)

최소힙, 최대힙

이진 트리의 한 종류 (이진 힙 - binary heap)
부모 노드의 값이 항상 자식 노드의 값보다 크거나(최대힙), 작거나(최소힙) 같은 규칙을 만족하는 이진 트리
- 루트 노드는 항상 최댓값 또는 최솟값을 가짐
완전 이진 트리여야 함

연결리스트, 스택

묠니르묘묘 — Tue, 26 Mar 2024 17:14:57 +0900

데이터 엔지니어링 데브코스 Day 2

- 자료구조 및 알고리즘 풀기 2

연결 자료구조 방식 (Linked Data Structure)

순차 자료구조 방식에서 연산 시간 및 저장 공간에 대한 문제를 개선한 자료 표현 방식으로 연결 자료구조와 비순차 자료구조(Nonsequential Data Structure)가 있음
순차 자료구조 방식처럼 원소의 논리적 순서와 물리적 순서가 일치할 필요 X
- 연속한 메모리 물리주소에 의해 원소 순서를 표현 X
- 각 원소에 저장되어 있는 다음 원소의 주소에 대한 참조에 의해서 연결되는 방식이기 때문
- 물리적 순서를 맞추기 위한 오버헤드 발생 X
순차 자료구조는 하나의 고정 크기 메모리 공간이 필요하지만, 연결 자료구조는 여러 개의 작은 공간을 연결하여 전체를 표현하기에 크기 변경이 유연하고 효율적 메모리 사용 가능
연결 자료구조 방식을 표현한 구조에는 연결 리스트가 있고, 연결하는 방식에 따라 단순 연결 리스트, 원형 연결 리스트, 이중 연결 리스트, 이중 원형 연결 리스트로 나눌 수 있음

연결 리스트 (Linked List)

연결 리스트

연결 자료구조 방식으로 데이터 요소가 노드로 구성되고, 각 노드는 데이터와 다음 노드를 가리키는 Link(링크)를 포함
데이터 순서가 메모리에 연속적으로 저장 X
데이터 삽입 및 삭제가 빠르지만 특정 인덱스 접근에는 선형 탐색 필요
선형 배열은 데이터 접근이 빠르지만 삽입 및 삭제 시에는 데이터 이동이 필요하여 연산이 느림
연결 리스트는 동적 크기 조정이 되어 메모리 관리 유연하며, 삽입 및 삭제 연산의 비용이 일정
선형 배열은 크기가 고정되어 메모리 사용이 불필요하게 발생 가능하며, 삽입 및 삭제 연산에 따라 메모리 재할당이 필요할 수 있음

양방향 연결 리스트 (Doubly Linked List)

양방향 연결 리스트 (이중 연결 리스트)

연결 리스트는 앞으로만 연결되어 있었지만, 양방향 연결 리스트는 노드들이 앞/뒤로 연결
연결 리스트에 비해 링크가 더 생기므로 메모리 사용량 증가 및 원소 삽입/삭제 연산에서 더 복잡함

스택 (Stack)

스택

스택이란 쌓아올린다는 의미로써, 접시를 쌓듯이 자료를 차곡차곡 쌓아 올린 형태의 구조
스택은 top 이라고 정한 한 곳으로만 쌓을 수 있고, top으로만 접근하도록 제한하여 만든 자료구조
- 삽입/삭제는 전부 top을 통해서만 가능하기에 top이 가리키고 있는 스택의 마지막 자료만 삭제 가능
시간순서에 따라 자료가 쌓이고, 삭제할 때는 가장 마지막에 삽입된 자료가 가장 먼저 삭제되는 후입선출(LIFO, Last-In-First-Out) 구조를 가짐
삽입 연산 push, 삭제 연산 pop

선형배열, 정렬, 탐색, 재귀, 시간복잡도

묠니르묘묘 — Mon, 25 Mar 2024 17:33:53 +0900

데이터 엔지니어링 데브코스 Day 1

- 자료구조 및 알고리즘 풀기 1

선형 배열 (Linear Array)

배열은 원소들을 순서대로 늘어놓은 것 : [1, 3, -9, 10, 4]
배열의 각각의 원소에는 번호가 있는데 이를 index(인덱스)라 함
- index 는 0부터 시작함
- 마지막 인덱스부터 첫 번째 인덱스까지 접근하려면 -1 부터 -1씩 증가시키면 됨
파이썬에서는 서로 다른 종류의 데이터 또한 줄세울 수 있는 list(리스트) 라는 데이터형 있음

파이썬 리스트 예시

리스트에 활용할 수 있는 연산들

1. 리스트 길이와 관계 없이 빠른 실행 결과를 보여주는 연산

원소 덧붙이기 : `.append(추가할원소)`
- 리스트 끝에 추가함
끝에서 원소 하나 꺼내기 : `.pop()'
a번째 원소 하나 꺼내기 : `.pop(a)`
- `pop()` 연산은 해당 원소를 꺼내고 리스트에서 삭제함

2. 리스트 길이에 비례하여 실행 시간이 걸리는 연산

원소 삽입하기 : `.insert(a,b)`
- 리스트의 a번째 위치에서 b를 삽입
원소 삭제하기 : `.del(L[x])` or `del L[x]`
- 리스트 L의 x번째 요소값을 삭제
원소 탐색하기 : `.index(a)`
- 리스트에 a 값이 있으면 a의 인덱스 리턴

정렬(Sort)

복수의 원소로 주어진 데이터를 정해진 기준에 따라 새로 늘어놓는 작업
파이썬 내장 함수 : `sorted(L)`
- 정렬된 새로운 리스트 반환
- 원본 리스트 L은 변경 X
리스트에 쓸 수 있는 메서드 : `.sort()`
- 해당 리스트를 정렬
정렬의 순서를 반대로 하려면 `reverse=True` 옵션 추가
- `L2 = sorted(L, reverse=True)`
- `L.sort(reverse=True)`

숫자(number)가 아닌 문자열을 정렬할 때는 사전순으로 정렬함.
이 때, 문자열 길이가 더 크다고 더 큰 문자로 취급 X
Python 문자열은 대문자가 소문자에 비해 무조건 우선.

예시

L = ['abcd', 'xyz', 'spam']
sorted(L, key=lambda x: len(x))
# ['xyz', 'abcd', 'spam']

L = ['spam', 'xyz', 'abcd']
sorted(L, key=lambda x: len(x))
# ['xyz', 'abcd', 'spam']


## 사전(dictionary)를 정렬하는 방법 중 이름순으로 하는 방법
L = [{'name' : 'John', 'score' : 83},
		 {'name' : 'Paul', 'score' : 92}]
# 레코드들을 이름순 정렬
L.sort(key=lambda x: x['name'])
# 레코드들을 점수가 높은순으로 정렬
L.sort(key=lambda x: x['score'], reverse=True)

`key` 매개변수는 정렬의 기준이 됨
- `lambda x: len(x)` 는 각 원소 x의 길이를 기준으로 정렬하도록 함
- 이를 통해 리스트의 각 요소들이 길이에 따라 정렬됨

lambda(람다)는 파이썬에서 간단한 익명 함수를 생성하는 키워드.
즉, 이름이 없는 함수를 생성할 때 사용됨.
람다 함수의 일반적인 구조는 `lambda 매개변수: 표현식`이다.
- lambda : 함수를 정의하는 키워드
- 매개변수 : 함수의 입력 값
- 표현식 : 함수의 결과 값

람다 함수 예시

addition = lambda x, y: x + y
print(addition(3, 5)) # 8

탐색(Search)

복수의 원소로 이루어진 데이터에서 특정 원소를 찾아내는 작업
기본적으로 선형 탐색(Linear Search)와 이진 탐색(Binary Search)가 있음

선형 탐색

순차 탐색(Sequential Search)라고도 함
순차적으로 모든 요소 탐색하여 원하는 값 찾음
배열의 길이에 비례하는 시간 걸림 O(n)

# 선형 탐색 구현
def linear_search(L, x):
	for i in range(len(L)):
		if x == L[i]:
			return i
	return -1

이진 탐색

탐색하려는 배열이 정렬되어 있는 경우에만 적용 가능
배열 가운데 원소와 찾으려 하는 값을 비교하고, 가운데 원소가 더 작다면 왼쪽의 값들(절반)은 없애고, 다시 오른쪽 배열들에서 반복함
탐색할 때마다 절반씩 사라지므로 빠른 탐색 가능 O(log n)

# 이진 탐색 구현
def binary_search(L, x):
	start, end = 0, len(n) - 1
	while start <= end:
		mid = (start + end) // 2
		if L[mid] == x: return mid
		start, end = (start, mid - 1) if L[mid] > x else (mid + 1, end)
	
	return -1

# 예시
# 시작 상태: 전체 배열 [4, 8, 15, 16, 23, 42, 48, 50, 56, 71, 88]
# 찾고자 하는 값: 23

# 1. 중간 값: 42
#    중간 값이 더 크기에 오른쪽은 탐색 X
#    [4, 8, 15, 16, 23]

# 2. 중간 값: 15
#    중간 값이 더 작기에 왼쪽은 탐색 X
#    [16, 23]

# 3. 중간 값: 16
#    중간 값이 더 작기에 왼쪽 탐색 X
#    [23]

# 4. 중간 값: 23
#    찾고자 하는 값과 중간 값이 일치하므로 찾음

재귀 알고리즘 (Recursive Algorithm)

같은 알고리즘을 반복적으로 적용함으로써 풀어내는 방법
재귀함수는 하나의 함수에서 자신을 다시 호출하여 작업 수행하는 것
종결 조건(trivial case) 명시해야하고, 스택오버플로우가 나지 않도록 주의

예시

# 자연수의 합 구하기
def sum(n):
	if n <= 1:
		return n
	else:
		return n + sum(n - 1)

# 피보나치 구하기
mem = {}

def fibo(n) :
	if n in mem:
		return mem[n]
	if n <= 1:
		return n
	mem[n] = fibo(n-1) + fibo(n-2)
	return mem[n]

mem 이라는 빈 딕셔너리(dictionary)를 만들어서 한번이라도 구했던 값 저장
- 딕셔너리는 키와 값으로 이루어진 데이터 구조
- mem[5] = 8 이 있으면 키가 5이고 값이 8
이 코드는 메모이제이션 기법을 구현한 방법으로, 메모이제이션은 이전에 계산한 값을 저장해 두고 필요할 때마다 사용하는 기법
- 중복 계산을 피하고 효율적인 알고리즘을 만들 수 있도록 도와줌

재귀를 통해 문제를 풀다보면 반복적으로 똑같은 함수를 여러번 실행하여 비효율적인 모습을 보일 때가 있다. 이럴 때 쓰이는 것이 메모이제이션 기법이다.

시간 복잡도

이것에 대해서는 아래 글에 작성했으니 참고하자.

https://ssdragon.tistory.com/100

FK(외래키)를 주식별자인 기본키(PK)로 꼭 넣어야할까? 아니면 비식별자로 넣어야할까?

묠니르묘묘 — Mon, 5 Feb 2024 15:48:33 +0900

우선 간단한 개념부터 살펴보자.

식별자(Identifier) 개념

하나의 엔터티(entity)에 구서된 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성
하나의 엔터티는 반드시 하나의 유일한 식별자가 존재
논리 데이터 모델링 단계에서는 '식별자', 물리 데이터 모델링 단계에서는 '키(key)' 라고도 불림

식별자 분류와 특징

엔터티 내에서 대표성을 가졌는가? 주식별자 or 보조식별자
엔터티 내에서 스스로 생성 되었는가? 내부식별자 or 외부식별자
단일 속성으로 식별 되는가? 단일식별자 or 복합식별자
업무적으로 의미가 있던 식별자 속성을 대체하여 새롭게 만들었는가? 본질식별자 or 인조식별자

(위 질문에 대한 답이 맞으면 왼쪽 아니라면 오른쪽)

주 식별자(Primary Identifier) 특징

유일성 : 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분됨
최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수
불변성 : 주식별자의 값은 변하지 않는 것
존재성 : 주식별자가 지정되면 반드시 값이 존재 (Not Null)

외부 식별자(Foreign Identifier) 특징

주식별자의 특징과 일치하지 않고, 참조무결성 제약조건(Referential Integrity)에 따른 특징 있음
다른 엔터티와의 관계를 통해 자식 쪽 엔터티에 생성되는 속성
DB 생성 시, 외래키(Foreign Key) 역할

식별자 관계(Identifying Relationship)

부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우를 식별자 관계라 함
주식별자의 특징을 전부 가지고 있어야 하며, 부모의 식별자가 손자까지 계속 이어지는 점이 있음
반드시 부모엔터티가 생성되어야 자식엔터티가 생성되는 경우

비식별자 관계(Non-Identifying Relationship)

부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고, 일반적인 속성으로 사용하는 경우
부모엔터티의 식별자가 필수가 아니므로, 부모 없는 자식이 생성될 수 있음
부모-자식 간에 관계가 있지만, 부모 먼저 소멸될 수 있음
부모의 식별자를 자식 식별자로 사용해도 되지만, 별도의 주식별자를 생성하는 것이 유리할 때 사용

식별자 관계로만 설정한다면?

개발 복잡성과 오류를 유발하는 요인이 될 수 있음
지속적인 식별자 관계를 연결한 데이터 모델의 PK의 개수는 데이터 모델의 흐름이 길어질수록 증가
조인할 경우 SQL 구문의 WHERE 절이 매우 길어짐
조인관계를 누락할 가능성이 높아짐

식별자 관계로만 이루어졌을 때

위와 같은 규칙처럼 자식 엔터티가 많아질수록 식별자는 1개씩 추가된다.

비식별자 관계로만 설정한다면?

불필요하게 부모엔터티까지 찾아가면서 자식엔터티에서 조회할 경우가 생김
즉, 불필요한 조인이 다량으로 유발될 가능성
SQL 구문이 길어지면서 복잡성이 증가하고, 성능이 저하될 가능성

비식별자 관계로만 이루어졌을 때

간단하게 손자 테이블에서 부모번호가 '1'인 데이터를 조회할 경우 SQL문은 다음과 같다.

SELECT *
FROM 부모 A, 자식 B, 손자 C
WHERE A.부모번호 = B.부모번호
AND B.자식번호 = C.자식번호
AND A.부모번호 = '1';

만약 식별자 관계였다면 아래와 같다.

SELECT *
FROM 손자
WHERE 부모번호 = '1';

이 상황에서 성능과 개발용이성 측면은 식별자 관계가 더 간단하다.

따라서 일정한 규칙을 가지고 데이터 모델링을 하는 기술이 필요하다.

그럼 어떤 규칙을 가지고 해야할까?

비식별자관계 선택 프로세스

기본적으로 식별자 관계로 모든 관계가 연결되면서 아래 조건에 해당할 경우 비식별자 관계로 조정한다.

비식별자 관계 선택 방법

식별자관계 고려사항

반드시 부모엔터티에 종속
자식 주식별자 구성에 부모 주식별자 포함 필요
상속받은 주식별자속성을 타 엔터티에 이전 필요

비식별자관계 고려사항

약한 종속관계
자식 주식별자 구성을 독립적으로 구성
자식 주식별자 구성에 부모 주식별자 부분 필요
상속받은 주식별자 속성을 타 엔터티에 차단 필요
부모쪽의 관계참여가 선택관계 (부모 없이 자식이 먼저 생성되는 경우)

개인적인 생각

지금까지 다룬 내용은 "SQL 전문가 가이드" 도서를 통해 얻은 지식이다.

이 도서를 통해 얻은 지식을 바탕으로 식별자에 대한 고민을 하게 되었다.

"무조건 비식별자로 두고, 모든 테이블에 시퀀스와 같은 일련번호를 부여한 PK(기본키)를 만드는 것이 좋을까?"

"상황에 따라 다르지만 아니다" 고 말할 수 있다.

대학교 DB 교수님은 "의미있는 속성들로 기본키를 구성하되, 없다면 시퀀스(더미키)를 사용해라"고 말씀하셨다.

실무에서는 회사마다 다르지만 시퀀스(UUID, TSID, 일시 등)를 사용하여 DB 구조를 유연하게 만드는 곳도 있었고, 이는 다양한 기업의 테크 블로그에서 확인할 수 있었다.

이렇듯 ERD 설계에 대한 접근 방식이 다양하지만 크게 개발자 입장과 DBA 입장이 있었음을 확인할 수 있었다.

내가 개발했던 프로젝트는 시퀀스를 이용하고 비식별자로 두었다.

이러한 접근 방식의 장점으로는 아래와 같다.

1. DB 구조의 유연성으로 미래의 변화에 대응하기 쉽다

→ 복합키를 가진 두 테이블 사이에 중간 테이블을 만들어야 하는 경우

→ 주민등록번호와 비슷한 속성과 복합키로 이루어졌으나 정책상 변경해야하는 난감한 경우

→ 비즈니스를 의존하지 않는 시퀀스라면 위 두 상황에서 자유롭게 변경 가능

2. 식별관계로 이루어진 테이블이 자식 테이블로 전파하면서 기본키가 증가하는 특징이 없음

3. 복합키로 된 테이블은 쿼리 조건문에 따라 인덱스가 제대로 사용되지 않을 가능성

4. 비즈니스 로직상 제약조건들이나 쿼리 성능개선에 유연한 대처

단점으로는 불필요한 JOIN과 성능문제, 더미값, 중복데이터 등이 있다.

역설적으로 더미키는 비즈니스에 의존하지 않는 키이므로 '오히려 좋아?'라는 생각이 든다.

결국 개발자 입장에서는 개발편의성과 유지보수성을 생각할 수 밖에 없기에 식별관계로 이루어진 복합키에 대해 잠자면서도 생각했던 것 같다.

위 사이트가 많은 생각을 하게 해주었다.

여러 도서에서는 모델링을 완벽하게 수행해야 개발 도중에 다시 갈아엎는 상황이 생기지 않는다고 한다.

그러나 시간이 부족하거나 지나면서 완벽한 모델링은 없다고 깨달을 것이다.

완벽한 모델링과 실제 개발간의 괴리는 불가피하며, 미래의 변경에 대비하는 것이 가장 중요하다는 것을 깨닫게 된다.

그렇다면 많은 개발자들이 비즈니스와 개발편의성, 유지보수성을 위해 시퀀스를 사용하는 것일까?

아니면 성능을 포기한 것일까?

이는 하드웨어 성능이 향상됨에 따라 식별관계를 통한 성능이 요구되지 않아도 충분한 퍼포먼스를 얻을 수 있다는 측면도 있는 것 같다.

결국 프로젝트 특성과 개발 상황을 고려하여 DB 모델을 유연하게 만드는 방법에 대한 고민은 충분한 시간이 필요하지만, 이렇지 않을 경우거나 DBA가 없다면, 이커머스처럼 MAU가 백만명 넘는 활발한 사용자가 없다면?

시퀀스를 사용하여 테이블 간에 비식별자 관계로 두고 빠른 개발을 하는 것이 낫다고 본다.

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 2편

묠니르묘묘 — Mon, 18 Dec 2023 23:57:12 +0900

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 1편

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 2편

깃허브 주소 : https://github.com/Sangyong-Jeon/practice_core-service

3. 모든 서비스에 공유할 클래스 만들기

저는 Filter를 만들겠습니다.

이 필터는 요청이 들어오면 콘솔창에 log를 남깁니다.

CustomFilter

공유할 클래스를 만드시면 됩니다.

4. 라이브러리 jar 파일로 만들기 위한 준비작업

실행가능한 jar 파일로 빌드하지 않도록 빌드 시스템을 비활성화시키는 작업.

이 작업에서 SpringBootPlugin 비활성화하여 bootJar도 비활성화하고, 실행가능한 jar로 빌드할 수 없게 설정함.

스프링부트 의존성 관리를 위해 bom을 가져오도록 BOM_COORDINATES를 설정함.

bom 파일은 의존성 라이브러리 버전을 명세한 pom 파일.

즉, SpringBootPlugin을 비활성화 했으니 버전관리가 안되므로 이를 정상적으로 작동시키게 하는 작업임.

main 메서드 및 SpringBoot를 실행시키는 클래스 삭제

main 메서드 및 SpringBoot를 실행시키는 클래스 제거함.

공유 라이브러리는 다른 서비스에서 사용하기 위해 존재하기에 실행가능한 클래스파일은 필요 X

build.gradle

SpringBootPlugin을 비활성화하고 BOM_COORDINAES 설정함.

이후 gradle을 리로드하여 갱신

build 해서 jar파일 만들기

우측 Gradle 버튼을 눌려 build를 실행함.

build/libs 폴더에 jar파일이 만들어졌는지 확인함.

이러면 공유 라이브러리로 사용하기 위한 준비작업 끝.

5. 자동 구성(Auto-Configuration) 만들기

우리가 필터를 스프링 빈(컴포넌트)로 만들었지만, 다른 서비스에서 Component Scan(컴포넌트 스캔) 대상이 되지 않는다. 따라서 컴포넌트 스캔 대상으로 만들어서 스프링 빈으로 등록을 하도록 작업한다.

https://docs.spring.io/spring-boot/docs/current/reference/html/features.html#features.developing-auto-configuration

공식문서에 나와있는 방식으로 자동구성을 정의할 것이다.

왜냐하면 공유라이브러리의 스프링 빈(컴포넌트)들은 Component Scan(컴포넌트 스캔) 대상이 아니기 때문이다.

따라서 공유라이브러리에서 `@Bean` 또는 `@Component` 등 작성해도 다른 서비스에서는 스프링 빈으로 등록안됨.

그렇기에 다른 서비스에서도 컴포넌트 스캔 대상이 되도록 정의해야함.

우리는 Locating Auto-configuration Candidates 방식으로 자동구성을 만들어서 스캔 대상이 되도록 할 것임.

AutoConfig 클래스 생성

AutoConfig 클래스를 만들고 위와 같이 작성

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 위치에 파일을 만들고 여기에 AutoConfig 클래스 위치를 적으면 됨.

이후 build를 해서 jar파일을 다시 만듦.

주의사항

자체 테스트할 때 version 조심

build를 하면 프로젝트 이름 + version의 jar 파일이 만들어진다.

자체 테스트할 때, 코드는 변경하지만 버전을 변경하지 않고 다른 서비스에 똑같은 이름의 jar 파일을 다시 테스트하는데 이러면 제대로 작동하지 않는다. 꼭 다른 이름이나 버전으로 지정해야한다.

이거 몰라서 가끔 되다가 안되다가해서 몇시간 날려먹었음.

6. 다른 서비스에서 테스트

테스트할 프로젝트 만듦

저는 테스트하는 프로젝트를 공유 라이브러리와 동일하게 만들었음.

공유라이브러리 jar 파일 가져오기

공유라이브러리 jar 파일을 최상단에 가져옴

build.gradle

build.gradle에 `implementation files('core-service-0.0.3.jar')` 을 작성하고 리로드하여 갱신함

TestController

테스트를 위해 컨트롤러를 만들고 애플리케이션을 실행

테스트 시도하여 정상적으로 log가 남음

정상적으로 CustomFilter가 작동함을 볼 수 있음

7. JitPack으로 배포하기

커밋 내역

지금껏 커밋 내역인데 편의상 아무렇게나 하셔도 상관없지만 일정한 규칙을 가져야 합니다.

태그를 위해 git flow 전략을 사용하고 커밋도 `feat: `, `fix: `, `refactor: ` 등으로 작성하셔야 합니다.

이 상태로 JitPack에 배포하면 자체적으로 build하게 되는데 이 때 기본값으로 JDK 1.8로 시도하기에 에러가 나옵니다.

따라서 JitPack 설정을 합니다.

build.gradle

종속성에 버전을 명시하지 않으면 JitPack에서 build할 때 에러가 발생합니다. 이 것 때문에 몇 시간 날렸습니다 ^^

build.gradle 파일에서 빨간색 네모칸에 있는 것을 추가합니다.

JitPack에서는 Gradle 프로젝트에서 build 하는 경우 maven 또는 mavne-publish 플로그인을 활성화해야 합니다.

(참고 : https://docs.jitpack.io/building/ )

이 작업은 gradle 프로젝트에서 maven local repository에 라이브러리를 배포하는 방법입니다.

jitpack.yml

프로젝트 최상위 경로에 jitpack.yml 파일을 만들어서 위 내용을 적습니다.

이 파일을 JitPack에서 읽고 그대로 실행합니다.

간단하게 설명하면 JDK를 Zulu 17.0.2 버전으로 정의하고 그걸로 build 및 publishToMavenLocal 을 한다는 의미입니다.

https://jitpack.io/

https://jitpack.io/ 에 들어가서 Github랑 연동하면 이렇게 뜹니다.

입력창에 저희가 만들었던 Github Repository URL(주소)를 넣고 [Look up] 버튼을 누르고 아래를 보면 저희가 릴리즈한 버전들이 나옵니다.

JitPack

여기서 [Get it] 버튼을 누르고 기다리면 Log 에 결과가 나옵니다.

빨간색은 실패이고 초록색은 성공입니다. Log를 클릭하면 기록을 보여줍니다.

성공하면 [Get it] 버튼이 초록색인데 누르면 홈페이지 아래에 어떻게 사용하는지 나옵니다.

JitPack

이 방법대로 다시 테스트했던 프로젝트에 적용해봅시다.

test-service 프로젝트의 build.gradle

이렇게 넣고 gradle을 리로드를 하면 정상적으로 JitPack에서 공유라이브러리를 가져오는 것을 볼 수 있습니다.

이제 다른 곳에서도 편하게 라이브러리를 배포받을 수 있습니다.

또 다른 배포 방법

JitPack 말고도 Github Packages 를 사용하여 배포가 가능합니다. 그런데 단점으로는 Github Token을 발급받아서 정의해야하는데 이게 노출됩니다. 따라서 private repository로 바꾸어야하는데 이 때 비용이 발생합니다. 물론 권한을 write:packages 와 delete:packages 만을 주어서 깃허브 패키지만 건들 수 있다고 하지만 찝찝합니다.

또 다른 배포 방법으로는 사설(사내) 저장소인 Nexus(넥서스)를 사용하는 것입니다. 이러면 사내에서만 사용되기에 외부에서 접근이 불가능하고 빠른 배포가 가능합니다.

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 1편

묠니르묘묘 — Mon, 18 Dec 2023 22:33:20 +0900

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 1편

스프링부트 공유라이브러리 만들고 jitpack으로 배포하기 - 2편

깃허브 주소 : https://github.com/Sangyong-Jeon/practice_core-service

작성 이유

SpringBoot(스프링부트)와 Gradle, Java로 라이브러리 만드는 자료가 많이 없었음
Maven은 꽤 있었으나 Gradle은 많이 안보였음
JitPack 으로 배포하는 방법도 있기는 했으나 나에겐 잘 안되던 것들이었음
시행착오를 많이 겪었던 부분이라 기록으로 남겨서 추후에도 사용하기 위함

기술 사양

Java 17.0.2 - Zulu
SpringBoot 3.2
IntelliJ
Github

간단한 동작 설명

공유 라이브러리(core-service)에서 Github의 main branch(브랜치)에 Pull Request(PR)를 하여 Merge를 함
미리 정의했던 Github Actions(깃허브 액션)을 통해 Release(릴리즈) 만듬
JitPack에서 릴리즈의 최신버전을 배포함

Github를 조금이라도 알고있어야 합니다. JitPack은 깃허브와 연동하고 깃허브 릴리즈를 기반으로 만들어 배포하기 때문입니다.

1. 깃허브 액션으로 Tag/Release 자동화 만들기

참고 : https://devocean.sk.com/blog/techBoardDetail.do?ID=164861&boardType=techBlog

Github Repository 만들기

우선 공유 라이브러리인 core-service를 만들겠습니다.

이를 위해 깃허브 리포지토리를 만듭니다.

이후 Actions 탭에 들어갑니다.

깃허브 액션에 와서 [set up a workflow yourself] 클릭

빨간 네모칸에 있는 [set up a workflow yourself] 를 클릭해서 워크플로우를 작성해봅니다.

이미 만들어져있는 워크플로우도 많으니 검색을 해서 그대로 편집하셔도 좋습니다.

깃허브 액션에서 워크플로우 파일 편집

여기서 어떤 작업을 할 것인지(워크플로우)를 작성하면 됩니다.

아래 코드를 넣습니다.

name: github action tag release

on:
  push:
    branches:
      - main
jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    permissions:
      packages: write
      contents: write
      id-token: write
      
    steps:
      - name: Bump version and push tag
        id: tag_version
        uses: mathieudutour/github-tag-action@v6.1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

      - name: Create a GitHub release
        uses: ncipollo/release-action@v1
        with:
          tag: ${{ steps.tag_version.outputs.new_tag }}
          name: ${{ steps.tag_version.outputs.new_tag }}
          body: ${{ steps.tag_version.outputs.changelog }}

name : 워크플로우 이름
on : 어떤 조건에서 워크플로우를 실행시킬 것인가를 정의하는 곳
- 여기서는 main 브랜치에 push가 올 때 실행
jobs : 워크플로우는 여러개의 job으로 구성되며, job들은 기본값으로 병렬실행이기에 순차실행이 필요하면 따로 id 지정해야함
- release : job의 고유한 id를 의미하며 문자열이어야 함.
  - name : 해당 job의 이름 설정
  - runs-on : 어떤 OS에서 실행할 것인지
  - permissions : 권한 설정
  - steps : job 안에서 순차적으로 실행되는 프로세스 단위가 step
    - - name : step 이름
    - id : step의 고유 id
    - uses : 어떤 액션을 사용할지 지정함. 이미 만들어진 액션을 사용할 때 지정.
    - with : 실행할 때 어떤 파라미터를 같이 넣을건지 정의

워크플로우 동작 설명

main 브랜치에 push를 하면 워크플로우가 실행되어 자동 태그하여 릴리즈에 올림
깃허브의 Commit Log를 기반으로 릴리즈 버전이 업데이트되면서 커밋 로그를 바탕으로 배포로그 생성
init, modify 는 버전으로 기록되지 않음
`fix: `, `feat: ` 두 가지의 깃허브 로그가 기록되어 태그되고 배포로그가 생성됨

코드 넣고 커밋

[Commit changes] 버튼을 누르고 커밋합니다.

이제 깃허브 액션으로 자동 태그와 릴리즈를 만드는 것은 끝.

2. 스프링부트 공유 라이브러리 만들기

저는 Git Flow 전략으로 사용하기에 별도의 브랜치를 만들어서 commit과 merge를 합니다.

(저처럼 안하셔도 됩니다)

우선 develop 브랜치를 만들고 여기서 진행하겠습니다.

IntelliJ(인텔리제이)로 스프링부트 Gradle 기반 프로젝트 만들기

깃허브 리포지토리와 폴더를 연결시키고, 거기에 리포지토리 이름과 동일한 프로젝트 이름을 생성함.

저는 /Documents/Github 경로에 practice_core-service 폴더를 만들었음.

그래서 인텔리제이에서 비어있지 않다고 나옴.

이 상태로 다음을 누름.

종속성 정의

현재 가장 최신버전인 스프링부트 3.2.0 버전 사용함.

Spring Web과 Lombok을 넣고 생성함.

이건 편한대로 넣고 진행하면 됨.

Github Desktop으로 Git을 다룸

편의상 Github Desktop을 사용해서 Git을 다룸. 명령어 기반으로 하셔도 됨

이후 커밋하고 PR을 하여 main 브랜치에 Merge하고 Actions 탭에 들어간다

깃허브 액션에서 실행한 워크플로우를 보여줌

저렇게 초록색으로 표시가 되었다면 정상적으로 깃허브 액션 워크플로우가 동작한 것.

깃허브 리포지토리

해당 리포지토리에 들어가면 우측 하단에 릴리즈가 생긴 것을 볼 수 있음.

AWS Builders Online Series 후기

묠니르묘묘 — Thu, 16 Nov 2023 15:30:47 +0900

잡담하기

최근에 아마존의 AWS가 한국에 정말 많은 투자와 관심을 주고 있다는게 느껴졌다.

예전부터 한국어 자막이나 한국어로 된 강의를 찍어서 행사나 강의, 세미나 등 열어주었기 때문이다.

또 최근 뉴스 "AWS에서 2027년까지 7조 8500억원 한국 클라우드 시장 투자"였는데 정말 어마무시하다...;;

AWS 말고도 클라우드 서비스를 하는 국내 기업은 NHN, Naver, Kakao, Samsung 등이 있다.

(해외는 Oracle, Google, Microsoft 등)

네이버는 두 번째 데이터센터 세종을 오픈하고, 카카오 클라우드도 여러 세미나 참여하면서 홍보하고,

NHN 클라우드도 올해 세미나 크게 열면서 엄청났죠.

그런데 저번에 갔던 "대한민국 디지털 미래혁신대전 2023" 컨퍼런스에서 삼성에서도 클라우드 서비스를 하는것을 처음 보았다.

이걸 보고 정말 많은 국내 대기업들이 클라우드 서비스로 진출하고 있다고 느꼈다.

왜 후기를 적는가?

AWS 컨퍼런스를 다시 참여하다보니 예전에 받은 참석 증명서가 보여서 까먹기전에 기록하기 위해서 간단하게 끄적여본다.

AWS Builders Online Series 참석 증명서(23.07.13)

AWS에서는 자주 행사와 강의를 열어주고, 매번 새로운 강의로 볼 수 있었다.

그래서 매번 같은 컨퍼런스이지만 다른 내용의 강의를 들을 수 있어서 정말 좋았다.

오전, 오후로 나뉘고 여러 세션이 있는데 다시보기도 지원하기 때문에 편하게 들으면 되지만 그 날 다 들어아야하는 이유는 AWS 크레딧을 받아야하기 때문이다 (ㅎㅎ)

레벨로 난이도를 나타내는데 나는 가장 쉬운 레벨100을 기준으로 들었고, 그 후 궁금한 것들로만 들었다.

목차 살펴보기

오프닝 연설 : 천만 사용자를 위한 서버리스 기반 클라우드 아키텍처 구성하기
Track 1 : AWS 핵심 서비스 잘 이해하기
Track 2 : AWS를 좀 더 잘 활용해보기
Track 3 : AWS와 함께 비즈니스 키우기

최근에 이 영상에 대해 Amazon Web Services Korea 에서 올려줬기 때문에 시간 날 때 편하게 볼 수 있어서 좋다.

요새 IT 대기업들은 발표한 내용을 유튜브에 올려줘서 너무 좋다...

서울 자주가기 힘들어요... ㅜㅜ

오프닝 연설 살펴보기

예전 발표에 했었던 천만 사용자 서비스 만들기 자료를 보여주면서 진행을 했다.

아마존 웹 서비스와 함께 천만 사용자 서비스 만들기

인스턴스 기반 천만 사용자 아키텍처

이 내용은 AWS 블로그에 나와있다. 무려 7년 전에 영상을 찍었는데 대단한 것 같다.

이 천만 사용자를 위한 클라우드 아키텍처는 가장 기본 콘텐츠로 매년 업데이트가 되면서 설명을 해주고 있다.

이번에 들었을 때는 인스턴스 기반이 아닌 서버리스 기반의 천만 사용자 아키텍처였다.

초기 서버리스 아키텍처

완성된 서버리스 기반 천만 사용자 아키텍처

서버 구성은 AWS가 알아서 해주기 때문에 앱 구현에만 집중할 수 있게 된다.

아무래도 고객의 요청에 따라서 빠른 변화가 필요한 서비스에 필요한 것 같다.

간단한 사례를 보면 아래와 같다.

느낀점

클라우드 서비스에서 불필요한 것들은 없애고 자동화로 만들어서 편의성을 향상시킴
AWS의 새로운 서비스가 계속 생김
AWS 컨퍼런스마다 새로운 영상을 찍어서 매년 보게 됨

위 장점들 때문에 계속 AWS를 보게되는 선순환(?)이 생기고 있다.

강제로 AWS 공부시키고 관심을 가지게 만든다...

또한, 다양한 기업에서 AWS 도입 사례도 올라오기에 재밌게 보게 된다.

("어? 이 기업도 AWS를 쓰네?" 라면서 역시 클라우드는 AWS인가..?)

컨퍼런스를 참석하면 크레딧도 주기 때문에 쏠쏠하다.

나조차도 이러는걸 생각해보면 AWS는 역시 막강하다.

나는 Oracle Cloud 써보았는데 Oracle에서도 클라우드 서비스 하는지 모르는 사람도 꽤 있다.

삼성도 그렇고... 많이 쓰는 것만 보이니 안 쓰는 것은 알 방법이 없는 것 같다.

국내 클라우드 서비스 힘내요 ㅜㅜ!!

이번에 네이버가 두 번째 데이터센터 세종을 오픈하면서 그 쪽으로 그나마 점유율이 올라가지 않을까 싶다.

한 번 클라우드 서비스 사용하면 쭉 사용하게 되니까 첫 도입하는 기업들을 잘 노려야 할 듯 싶다.

요새 OpenAI의 GPT가 유행하고 최근 발표로는 GPTs 도 나오면서 개인용 AI 비서 얘기가 잘 나오는데, 오픈AI에 투자한 마이크로소프트가 다시 1위 클라우드 기업이 될 지도 모르겠다. 오픈AI 입장에선 투자사인 마소랑 협약해서 하는게 맞을테니 거대한 인공지능을 개인들에게 보급할 때 마소의 Azure가 빛을 발휘하지 않을까?

현재 기업들에게 클라우스 서비스 보급하지만, 삼성의 온디바이스AI와 GPT 연동된 기기 및 AI기기들이 나오면서 개인이 가지는 클라우드 인공지능도 생기지 않을까? 자연어로 GPTs를 사용하여 챗봇을 커스터마이징을 하니까 말이다. 그렇기에 현재는 기업에 많이 알리는 것도 중요하지만 개인들의 관심도 넓혀야하지 싶다. 자연스럽게 "클라우드 서비스면 OOO 아니야?" 라면서 생각하게끔 말이다.

Spring Cloud 마이크로서비스들은 어떻게 서로 통신 할 수 있을까? - Discovery Client

묠니르묘묘 — Mon, 9 Oct 2023 16:24:12 +0900

어떻게 마이크로서비스(MS)들은 서로 위치를 알고 호출하는 걸까?

Eureka(유레카)를 이용하여 서로 물리적 위치를 검색하여 찾기 때문이다.

서비스 디스커버리를 위해 MS들이 Spring Cloud Load Balancer(로드밸런서)와 상호 작용할 수 있는 3가지 방법을 찾아보자.

스프링 Discovery Client
REST 템플릿을 사용한 스프링 Discovery Client
넷플릭스 Feign Client

스프링 Discovery Client

Discovery Client와 표준 스프링 RestTemplate 클래스를 사용하여 호출
로드 밸런서와 그 안에 등록된 서비스에 대해 가장 낮은 수준 접근 가능
즉, Discovery Client를 사용하면 로드밸런서에 등록된 모든 서비스와 URL을 쿼리할 수 있음

@SpringBootApplication
@RefreshScope
@EnableDiscoveryClient // Eureka Discovery Client를 활성화
public class MicroServiceApplication {
	public static void main(String[] args) {
    	SpringApplication.run(MicroServiceApplication.class, args);
    }
}

`@EnableDiscoveryClient`로 스프링 클라우드에서 애플리케이션이 Discovery Client와 스프링 클라우드 로드 밸런서 라이브러리를 사용할 수 있게 됨.

@Component
@RequiredArgsConstructor
public class UserDiscoveryClient {

	// Discovery Client를 클래스에 주입
	private final DiscoveryClient discoveryClient;
    
	public User getUser(String userId) {
		RestTemplate restTemplate = new RestTemplate();
		// 유저 서비스의 모든 인스턴스 리스트를 얻음
		List<ServiceInstance> instances = discoveryClient.getInstances("user-service");
		if (instances.isEmpty()) return null;
        
		// 서비스 엔드포인트를 검색해서 가져옴
		String serviceUri = String.format("%s/v1/user/%s", instances.get(0).getUri().toString(), userId);
		// 서비스 호출을 위해 표준 스프링 RestTemplate 클래스 사용
		ResponseEntity<User> restExchange = restTemplate.exchange(serviceUri, HttpMethod.GET, null, User.class, userId);
		return restExchange.getBody();
	}
}

단점

Discovery Client를 직접 호출해서 모든 서비스 리스트를 얻고, 그 중 호출할 서비스 인스턴스를 개발자가 책임지고 선정
개발자가 서비스 호출하는 데 사용될 URL 생성
RestTemplate을 직접 생성하여 사용
- 자동 구성이 필요하지 않고 직접적인 제어가 필요할 때 직접 생성함
- 로드밸런서 인터셉터의 영향을 피하고 특정한 설정 적용가능

로드 밸런서를 지원하는 스프링 REST 템플릿

향상된 스프링 RestTemplate으로 로드밸런서를 사용하는 서비스 호출
스프링을 통해 로드 밸런서와 상호 작용할 수 있는 일반적인 방법

@SpringBootApplication
@RefreshScope
public class MicroServiceApplication {
	public static void main(String[] args) {
		SpringApplication.run(MicroServiceApplication.class, args);
	}

	// RestTemplate 또는 WebClient가 스프링 클라우드 서비스 디스커버리(유레카)와 통합
	// 서비스 이름을 기반으로 특정 서비스에 대한 인스턴스를 선택하고 요청 가능
	@LoadBalanced
	@Bean
	public RestTemplate getRestTemplate() {
		return new RestTempalte();
	}
}

서비스의 물리적 위치 대신 호출하려는 서비스의 유레카 서비스 ID를 사용하여 대상 URL 생성 가능

@Component
@RequiredArgsConstructor
public class UserRestTemplateClient {

	private final RestTemplate restTemplate;
    
	public User getUser(String userId) {
		ResponseEntity<User> restExchange = 
			restTemplate.exchange("http://user-service/v1/user/{userId}", HttpMethod.GET, null, User.class, userId);
        
		return restExchange.getBody();
	}
}

첫 번째 방법과 다르게 Discovery Client가 없어짐
URL에서 서버 이름은 유레카에 등록한 서비스 키의 애플리케이션 ID를 사용
즉, 로드 밸런서를 지원하는 RestTemplate 클래스는 전달된 URL을 파싱하고 서버 이름으로 전달된 것을 키로 사용하여 서비스의 인스턴스를 로드 밸런서에 쿼리함
실제 서비스 위치와 포트는 개발자에게 완전히 추상화
RestTemplate 클래스를 사용하면 스프링 클라우드 로드 밸런서는 서비스 인스턴스에 대한 모든 요청을 라운드 로빈 방식으로 부여

Feign Client

넷플릭스 Feign Client 라이브러리를 사용하여 로드 밸런서를 경유하여 서비스 호출
자바 인터페이스를 정의하고, 스프링 클라우드 애노테이션을 추가하여 쉽게 사용

@SpringBootApplication
@RefreshScope
@EnableFeignClients // Feign Client 사용하도록 설정
public class MicroServiceApplication {
	public static void main(String[] args) {
		SpringApplication.run(MicroServiceApplication.class, args);
	}
}

유저 서비스의 엔드포인트를 호출할 Feign Client의 Interface 정의를 해보자.

@FeignClient("user-service") // Feign에 서비스를 알려줌
public interface UserFeignClient {
	
    @GetMapping("/v1/user/{userId}") // 엔드포인트 경로와 액션(verb) 정의
    User getUser(@PathVariable String userId); // 엔드포인트에 전달되는 매개변수 정의
}

표준 스프링 RestTemplate은 서비스 호출에 대한 HTTP 상태 코드(status code)는 ResponseEntity의 getStatus()에 반환된다. 하지만 Feign Client는 호출된 서비스에서 반환한 모든 HTTP 4xx ~ 5xx 상태코드가 FeignException에 매핑된다. 이 예외에 특정 에러 메시지에 대해 파싱할 수 있는 JSON 내용이 포함되어 있다.

Feign은 사용자가 정의한 Exception 클래스에 에러를 재매핑하는 에러 디코더(ErrorDecoder) 클래스를 작성할 수 있는 기능을 제공한다.

결론

이 중 역시 Feign Client가 가장 쉽게 작성가능하며, 추상화 되어 있고, Load Balanced 지원하기에 이것을 사용하는것이 가장 좋은 방법으로 보인다. 하지만 예외처리는 평범한 RestTemplate과는 다르니 FeignException 또는 FeignErrorDecoder, CircuitBreaker (Resilience4j) 등 클라이언트 측 회복성을 위한 다양한 방법을 숙지해야 한다.

스프링 마이크로서비스 코딩공작소 개정2판

Spring Cloud 마이크로서비스들이 직접 Vault에서 값을 읽도록 만들어야 할까? - 보안과 유연성의 고민

묠니르묘묘 — Sat, 7 Oct 2023 16:43:24 +0900

현재 상황

Vault를 적용한 Spring Cloud 아키텍처

Spring Cloud Config Server (구성서버)는 가장 중요한 정보를 Vault에서 가져옴 (id, pw ...)
덜 중요한 정보는 Github를 통해 가져옴 (application.yml ...)
- application.yml에는 `${vault.gitId}`로 vault값을 사용하고 있음

application.yml 또는 application.properties에 굳이 ${vault.gitId}를 사용하지 않고, Vault에서 "spring.cloud.config.server.git.username" 키에 값을 넣으면 자동으로 적용되게 된다. 따라서 소스코드에서 Vault를 통해 값을 주입받는다는 기록을 남기지 않을 수 있다. 나는 왜 Vault에서 값을 가져온다고 명시했냐면 추후 설정정보를 변경하게 될 때 빠르게 찾기 위해서이다. 이것 또한 trade-off이다. 소스코드에 남기느냐 남기지 않느냐이기 때문이다.

문제점

각 마이크로서비스들은 Vault에서 값을 가져오지 못하는 문제점 발생
- `${vault.gitId}`를 문자 그대로 인식하고 있는 문제점
- 즉, Vault에서 값을 못가져왔음

따라서 나는 2가지 해결방법을 생각했다.

Vault에서 값을 가져오도록 각 MS(마이크로서비스)에 Vault와 Bootstrap 라이브러리 추가하기 (유연성 하락)
Github의 application.yml에 id,pw 명시하기 (보안 하락)

보안을 선택하면 각 마이크로서비스들은 Vault에 의존성이 생기며,

유연성을 선택하면 구성 서버만 잘 관리하면 된다.

해결방법

보안을 선택한 Spring Cloud 아키텍처 구조

보안을 선택해서 각 MS들도 Vault와 Bootstrap 라이브러리를 추가했다.

Github에 중요 정보를 적어놓으면 불안하기 때문이다.

때문에 Vault와 Config Server(구성서버)의 고가용성이 보장되어야하는 아키텍처 구조가 만들어졌다.

✅ 그런데 순간 머리에서 생각이 팍! 하고 나왔다.

Config Server의 백엔드 저장소를 vault, github, native를 사용하고 있는데 그러면 여기 저장소들에서 설정값을 MS에 배포하니 MS에서는 Vault를 의존하지 않아도 되는것이 아닌가????

Config Server에서 배포하는 UserService의 설정파일

Config Server에서 Vault에 user-service/dev 값을 넣으니 위 그림처럼 제공되고 있었다.

즉, MS에서는 Vault를 의존하지 않고 Config Server에서 모든 값들을 제공받으므로 의존성을 추가하지 않아도 됐다.

Native에 있던 것은 테스트하려고 한 것이라 Github에 이동시킬 예정

Spring Cloud Config Server에서 제공하는 설정정보

Config Serveer가 Vault와 Github에서 설정정보를 가져와 취합하여 한번에 설정정보를 제공
MS들은 Config Server만 의존하면 됨
MS들은 Vault 라이브러리를 추가하지않아도 되었음

처음 봤었던 아키텍처 구조와 동일하게 보안적으로 향상된 구조가 되었다.

한 쪽을 선택해서 다른 한 쪽을 포기하게 되는 trade-off를 생각하다보니 큰 고민을 하게 되었다.

고민을 가지고 깊게 생각하다보니 내가 놓치고 있었던 부분을 발견하게 되어 최고의 선택지가 나오게 되었다.

처음에는 단순하게 MS에다가 Vault 라이브러리를 추가하여 값을 읽도록 하지만 의존성이 생기는 차선책을 선택했지만,

Spring Cloud Config Server의 백엔드 저장소를 제대로 생각하지 못했다는 점을 깨달았다.

Vault의 Secret Engine은 각 MS별로 만들어야하는 줄 알았기 때문이다. (~~나 약간 바보...?~~)

Config Server가 읽고있는 Secret Engine에다가 "user-service/dev" 를 만들어 값을 넣으니 제대로 작동되었다.

Vault 저장소

위 사진처럼 "config-service-secret" 이라는 Secret Engine이 있는데, 여기에 "user-service" 값을 넣었어야 했는데 또 다른 Secret Engine으로 만들었었다. 그래서 각 MS별로 Secret Engine을 읽어야하는 줄 알았는데 Config Server가 읽어서 거기서 나온 값을 MS로 전달하면 되었던 것이다. 계속 코드를 살펴보고 찾다보니 이렇게 놓치고 있었다는 점을 깨닫게 된다.

글로 설명하면 이해가 안갈 수 있으니 그림으로 내가 착각했던 것을 남겨본다.

착각했던 Vault 사용법과 올바른 Vault 사용법

파란색이 Secret Engine을 의미한다.

Spring Cloud Config Server와 Vault에 대한 자료 및 강의가 많이 없기에 외국 행님들의 영상도 찾아보며 고생했던 기억이 무척 많이 남았다. 그래서 글을 써보게 되는데, 나중에는 무료강의도 한번 찍어볼 수 있지 않을까 싶다.

Spring Cloud Config Server - Vault 적용

묠니르묘묘 — Sat, 23 Sep 2023 18:19:18 +0900

Spring Cloud Config 란?

Spring Cloud Config Server

분산 시스템에서 애플리케이션 구성 데이터를 하나의 중앙화 된 저장소에서 관리 가능
각 서비스를 다시 build(빌드)하지 않고 최신 구성 정보 적용 가능
스프링 및 스프링이 아닌 서비스와 긴밀한 통합
애플리케이션 환경에 맞는 구성 정보 사용 가능(dev, local. prod ...)
속성 값 암호화 및 해독(대칭 or 비대칭)
MSA 인스턴스를 많이 실행하더라도 항상 동일한 구성 보장 가능
자체 프로퍼티(property) 관리 저장소가 있지만, 오픈 소스 프로젝트와도 통합 가능
- Git(깃)
- Eureka(유레카)
- Vault(볼트)
- ....

그림처럼 Config Server는 외부 저장소에서 최신 구성 정보를 가져오고, 그것을 애플리케이션에게 줄 수 있습니다.

애플리케이션은 각각 필요한 구성 정보를 가져올 수 있으며, 그림에 있는 구성정보 외에도 키-값으로 이루어진 데이터를 가져옵니다.

외부 저장소는 어떤 것을 사용해야 할까?

Config Server는 로컬 저장소(파일 저장소)를 사용해도 된다.

하지만 클라우드 기반 애플리케이션에서는 실용성이 크게 없다.

공유 파일 시스템을 설정하고 관리해야하기 때문에 손쉽게 구성 정보를 갱신할 수 있어야 한다.

따라서 Git과 Vault를 사용하는 것이다.

Github 저장소

깃허브에 구성 정보를 저장하고 손쉽게 변경 및 제어를 할 수 있음
원격 저장소이기 때문에 개발자는 어디서든지 구성 정보 제어 가능
private repository로 관리를 해야하는 것이 중요!

단점

Github 저장소에 의존적이어서, SPOF(단일장애지점)이 될 가능성 있음
Github에 접속하기 위한 ID, PW 또는 토큰값을 서버에 미리 설정해야 함 (보안)

이렇게 결국 Github ID, PW, 토큰값이나 각종 중요한 ID,PW를 미리 설정하거나 Github의 private repository에 저장해야한다는 문제점이 있다. 암호화를 하여 읽을때 해독하는 방법도 제공하지만 나는 이런 중요한 정보들(ID,PW)를 또 다른 외부 저장소인 Vault에 저장하기로 했다.

HashiCorp Vault(하시코프 볼트)

secrets(시크릿)에 민감한 정보를 안전하게 접근 및 관리 할 수 있는 오픈소스 도구
PW, 인증서, API 키 등 접근을 제한하거나 제한하려는 어떤 정보로도 시크릿 정의 가능
Spring Cloud Config Server의 설정 저장소로 Git과 Vault 지원
관리자, 다른 Vault 사용자도 내 토큰이 없으면 정보를 읽을 수 없음

Spring Cloud Config Server와 Vault, Github 구조

따라서 볼트에 가장 중요한 정보를 저장하고, 그 후에 Git에 저장하기로 한다.

하지만 나는 가장 중요한 정보에 Github의 ID,PW도 포함시키고 싶다.

따라서 내가 생각하는 구조는 아래와 같다.

Spring Cloud Config Server 외부 저장소 구조 설계

Github 뿐만 아니라 DB나 중요한 정보는 전부 Vault에 저장하고 꺼내 쓰는 것으로 한다.

따라서 Config Server는 Vault에 먼저 접속해서 설정정보를 가져와야하므로 Bootstrap 라이브러리를 활용해야 한다.

Bootstrap(부트스트랩)

properties와 yml을 동일하게 여기시면 됩니다.
e.g. application.properties == application.yml

서버 실행 시, application.yml보다 bootstrap.yml이 먼저 로드되게 함
Bootstrap Context는 Application Context의 상위 컨텍스트
2021년도 기준으로 Spring Cloud에서는 bootstrap을 자동으로 읽어오는 기능이 없음
- 따라서 spring-cloud-starter-bootstrap 의존성 추가해야 함
bootstrap.yml은 Config Server(구성서버)를 준비하기 위한 것
application.yml은 애플리케이션과 관련된 속성을 위한 것

Spring Cloud Config Server 외부 저장소 설계

Spring Cloud Config Serve 보안 설계

Vault와 Github 연동하고 사용해보기

이 구조를 사용하려면 우선 아래 라이브러리 추가가 필요하다.

implementation 'org.springframework.cloud:spring-cloud-config-server' //구성 서버
implementation 'org.springframework.cloud:spring-cloud-starter-bootstrap' //부트스트랩
implementation 'org.springframework.cloud:spring-cloud-starter-vault-config' //볼트

우선 볼트 라이브러리를 추가한 것에 의아할 수도 있다.

왜냐하면 Config Server에서 기본적으로 설정 저장소로 지원하기 때문이다.

여기서부터는 나의 여러 실험 환경에 의한 개인적인 의견이 포함된다.

처음엔 Config Server와 Bootstrap 의존성만 추가하고 테스트 해보았지만 Vault에서 가져온 값으로 Github에 접속할 수 없었다.

spring:
  profiles:
    active: git, vault
  cloud:
    config:
      server:
        git:
          uri: file:///path/to/git/repo
          order: 2
        vault:
          host: 127.0.0.1
          port: 8200
          order: 1

이런 식으로 우선순위를 정해보기도 하고, bootstrap.yml에 따로 적어보기도 하는 등 구글과 스택오버플로우 등 여러 방법을 적용해봤지만 절대로 불가능했다.

따라서 Vault에서 가져온 값으로 Github 접속하는 것이 아니라, Vault와 Github를 접속할 수 있는 값을 미리 적는 경우라면 상관이 없었다.

하지만 나는 Vault에서 가져온 값으로 Github에 접속하고 싶었기에 Vault 라이브러리를 추가해보았다.

그리고 성공했다.

bootstrap.yml

우선 bootstrap.yml에 vault에 접속하기 위한 설정정보를 적는다.

이 값을 통해서 vault에 접속하고 값을 미리 가져온다.

application.yml

그리고 vault에서 github ID, PW를 가져와서 application.yml에 넣어 접속을 시도하고 가져온다.

config-server 설정정보에서 vault를 적지않아도 되지만 나는 config-server에서도 vault 구성정보를 확인하고 싶었기에 추가했다.

spring cloud config server 확인

이렇게 "localhost:8888/config-service/dev" 를 통해 vault에 있는 값을 최우선적으로 가져오는 것을 알 수 있다.

마지막으로 github에서 application.yml을 가져왔다.

application.yml에서 config-server의 백엔드 구성정보에 vault를 작성하지 않으면 github의 application.yml만 확인할 수 있고, 가져올 수 있다.

Vault를 도커로 실행하기

컴퓨터에 볼트를 설치하기 싫으니 도커 컨테이너로 실행하기로 한다.

docker run -d -p 8200:8200 --name vault -e 'VAULT_DEV_ROOT_TOKEN_ID=myroot' -e 'VAULT_DEV_LISTEN_ADDRESS=0.0.0.0:8200' vault:1.13.3

VAULT_DEV_ROOT_TOKEN_ID
- 루트 토큰(root token) ID 설정하는 것
- 루트 토큰은 볼트 구성을 시작하는 초기 액세스 토큰
VAULT_DEV_LISTEN_ADDRESS
- 개발 서버의 IP주소와 포트 설정
- 기본값은 0.0.0.0:8200

위 도커 명령어로 vault 1.13.3 버전 이미지를 가져오고 컨테이너로 실행시킨다.

이후 편의성을 위해 볼트 UI를 이용하여 설정하기로 한다.

CLI(명령어)를 선호한다면 그건 다른 쪽에서 알아보자.

application.yml과 bootstrap.yml에서 vault의 토큰값을 넣는 부분이 있는데 여기서 설정한 루트 토큰값을 넣으면 된다. 위 명령어대로라면 "myroot"를 넣으면 된다.

Vault UI (볼트 UI) 접속 페이지

"http://0.0.0.0:8200/ui/vault/auth" 주소를 통해 볼트를 접속한다.

토큰값은 도커를 실행했을 때 설정했던 루트 토큰값인 "myroot"를 통해 접속한다.

Vault UI 접속 후, 시크릿(secret) 목록들

접속하면 초기 secret들이 있는데 새로 만들기로 한다.

[Enable new engine] 버튼을 누른다.

Enable new engine 버튼 클릭 후 설정

새로운 엔진 중에서 범용 KV 를 선택하고

enable new engine 시크릿 엔진 데이터 입력

KV 시크릿 엔진 데이터를 입력한다.

우리는 시크릿 이름을 "config-service-secret"으로 설정한다.

시크릿

새로운 시크릿 엔진이 만들어졌다면 이제 시크릿을 생성해보자.

[Create secret] 버튼을 누른다.

Vault Secret 생성

그럼 이제 시크릿을 생성할 수 있다.

시크릿 이름을 적을 때 "/"를 기준으로 세분화할 수 있다.

"config-service/dev"를 적고, 여기에 저장할 데이터를 입력한다.

우리는 gitId와 gitPw를 적어놓는다.

이후 [Save] 버튼을 누르면 끝난다.

새로운 secret 생성

이제 정상적으로 Vault 데이터를 가져오는지 확인해보자.

Spring Cloud Config Server 테스트

"localhost:8888/config-service/dev" 주소를 입력해서 가져오는지 확인한다.

아까 저장했던 gitId와 gitPw가 가져와지는 것을 알 수 있고, 이 데이터로 Github에 접속해서 application.yml 구성정보를 가져오는 것도 확인할 수 있다.

참고로 Github에서 public repository라면 ID와 PW를 적을 필요 없이 주소(uri)만 적으면 가져올 수 있다. 여기서는 Github의 private repository에 접근하기 위해 ID와 PW를 입력해야하는 것이다.

분산환경에서 DB 기본키(PK)는 어떤 ID 생성 전략으로 만들어야할까? (UUID,ULID,TSID...)

묠니르묘묘 — Sun, 3 Sep 2023 19:08:00 +0900

보통 개발 편의성을 위해 Oracle의 Sequence, MySQL의 auto_increment 로 숫자를 1씩 증가시키는 것으로 만든다.

이것은 어떤 문제점이 있을까?

외부에서 해당 시스템 PK를 예측하기 쉬워져서 SQL Injection 문제
Sequence, auto_increment는 중앙 집중식으로 값을 생성하는 방식이므로 DB에 의존적이게 되어 확장성이 제한되는 문제
서비스 폭풍성장 시, ID 고갈되는 문제 (BIGINT 최댓값은 4,294,967,295 이고, unsigned BIGINT라면 18,446,744,073,709,551,615)
데이터베이스 변경의 어려움
DB가 2대 이상일 때 중복 문제

MySQL 5.7 이하 버전에서는 AUTO_INCREMENT counter 값을 메모리에 저장하였기에 재기동한다면 이 값이 소멸된다. 따라서 0부터 시작하게되는 문제가 발생한다.

MySQL 8.0 이후부터는 AUTO_INCREMENT counter 값을 디스크에 저장하는 방식으로 변경되었다.(redo log에 저장) 따라서 재기동되더라도 counter값이 남아있기에 중복문제가 발생하지 않는다.

분산환경에서 유일성이 보장되는 ID를 만드는 방법은 어떠한 것이 있을까?

다중 마스터 복제(multi-master replication)

다중 마스터 복제 예시

DB의 auto_increment 기능을 활용하고, 1씩 증가하는 것이 아닌 서버의 수 k만큼 증가시키는 방법
각 DB서버가 다음에 만들 ID값은 자신이 생성한 이전 ID값에 전체 서버의 수 k를 더한 값
- 위 그림에서는 DB서버가 2개이므로 k = 2 가 됨
규모 확장성을 어느정도 해결

단점

여러 데이터 센터에 걸쳐 확장 어려움
시간 흐름에 맞춰 ID값을 커지도록 보장할 수 없음
서버 추가 및 삭제 할 때도 잘 동작하도록 만들기 어려움

UUID

UUID값 예시 : bb6266a8-09aa-4c90-b597-05f1cc958acd

컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수
UUID 값은 충돌 가능성이 매우 낮음 (중복 확률 0.00000000006% 인데 운석 맞을 확률임)
서버 간 조율 없이 독립적으로 생성 가능
알파벳은 소문자로 표현되며, 입력시 대소문자를 구분하지 않음

장점

UUID 생성은 간단
동기화 이슈 X
규모 확장 쉬움

단점

ID값이 128비트로 길며, 용량도 큼
- 대규모 테이블에서 저장공간 많이 차지
시간순 정렬 X
숫자가 아닌 값 포함
UUID 값은 문자 단위로 비교되기 때문에, 정수와 비교하면 성능이 느림 (2.5배 ~ 28배 성능 저하)
MySQL(innoDB) 인덱스는 B+Tree 구조로써 순차성에 강한데, UUID는 랜덤이므로 성능 저하가 크게 발생 가능

InnoDB는 기본키(PK)의 B+Tree에 테이블 행을 저장한다.이를 클러스터형 인덱스(clustered index)라고 부른다. 클러스터형 인덱스는 기본키를 기준으로 자동으로 행의 순서를 지정한다. 그런데 무작위 UUID를 가진 행을 삽입하면 여러 문제가 발생할 수 있어 성능 저하를 초래한다. 이와 관련된 내용은 아래 참고자료를 살펴보자.

참고자료

ULID

(ULID Github 링크)

https://blog.daveallie.com/ulid-primary-keys

UUID와 많이 유사하며, 128bit 용량을 가짐
앞의 Timestamp(타임스탬프)가 48bit 사용하므로 시간순 정렬 가능
- 기원시간인 Epoch(밀리초)로 시간을 인코딩
뒤의 Randomness(무작위성)은 80bit를 가짐
밀리초의 정밀도를 가지며, 단순하게 증가
밀리초 내에 동시 생성되면 무작위성에 따라 순서가 달라짐

장점

UUID의 단점을 해결하기 위해 만들어짐
UUID의 36문자와 달리 ULID는 26문자로 인코딩됨
- UUID는 Base16, ULID는 Base32 문자 집합을 사용하기 때문에 ULID가 더 짧은 문자열을 가짐
특수 문자 없음 (URL 안전)
대소문자 구분하지 않음
시간순 정렬 가능
효율성과 가독성을 위해 Crockford의 Base 32 사용
- "I", "L", "O", "U" 제외됨
- 문자당 5bit

단점

128bit로 상대적으로 용량이 큼

Base32는 Base16보다 더 많은 정보를 한 문자에 담을 수 있기 때문에 ULID가 문자열이 26자로 표현된다. Base16은 16진수로 표현된 데이터를 나타내며, 각 문자는 4비트를 나타낸다. 128bit(16byte)의 데이터를 Base16으로 표현하면 32자의 문자열이 필요하다. 반면에 Base32는 각 문자가 5비트의 정보를 표현하고, 128bit 데이터를 26자의 문자열만으로 표현할 수 있다.

UUID는 Base16이므로 32문자로 표현할 수 있지만 특수문자인 하이픈(`-`)이 4개 추가되기 때문에 총 36문자이고, ULID는 특수문자가 없기 때문에 온전히 26문자로 표현이 가능하다. 이것이 UUID와 ULID를 구별짓는 중요한 차이 중 하나이다.

티켓 서버(ticket server)

티켓 서버 예시

auto_increment 기능을 갖춘 DB를 중앙 집중형으로 하나만 사용하는 것
즉, 분산 환경에서 고유한 식별자를 생성하고 관리하기 위해 사용되는 중앙 집중식 서버를 의미
티켓 서버는 다양한 클라이언트나 서비스가 동시에 접근하여 고유한 티켓(식별자)를 얻을 수 있는 장소로 사용됨

장점

유일성이 보장되는 숫자로만 구성된 ID를 쉽게 생성
구현하기 쉽고, 중소 규모 애플리케이션에 적합

단점

티켓 서버가 SPOF(Single-Point-of-Failure, 단일장애지점)이 됨
- 티켓 서버 장애 발생 시, 해당 서버를 이용하는 모든 시스템이 영향을 받음
티켓 서버 여러 대 준비해야하는데 이러면 데이터 동기화 같은 새로운 문제 발생
확장하기 어려움
여러 서버에서 티켓 서버로 요청하므로 병목 현상 발생 가능

트위터 스노플레이크(snowflake) 접근법

트위터는 고가용성 방식으로 초당 수만 개의 ID를 생성할 수 있는 것이 필요했고, 이러한 ID는 대략적으로 정렬 가능해야 하며, 64bit의 용량을 가져야 한다. MySQL 기반 티켓 서버는 일종의 재 동기화 루틴을 구축해야 했고, 다양한 UUID는 128bit가 필요했다. 따라서 대략적으로 정렬된 64bit 용량을 가진 ID를 생성하기 위해 타임 스탬프(timestamp), 작업자 번호(worker number) 및 시퀀스 번호(sequence number)의 구성을 결정했다. 시퀀스 번호는 스레드별로 지정되며, 작업자 번호는 시작 시 Zookeeper를 통해 선택된다. [원문링크] [Github 링크]

트위터(twitter)가 OSS(Open Source System, 오픈소스)로 공개한 ID 생성기(generator)
Time-base 한 ID (시간대별 정렬 가능하며, 의미를 가지는 ID)
확장 가능하며, 병렬로 유일성을 가진 ID 생성 가능
생성해야 하는 ID 구조를 여러 영역(section)으로 분할하여 사용

twitter snowflake(트위터 스노우플레이크) 예시

스노우플레이크 구조 설명

사인(sign) 비트
- 1bit 할당
- 음수와 양수를 구별하는 데 사용
타임스탬프(timestamp)
- 41bit 할당
- 기원 시각(epoch) 이후로 몇 밀리초(millisecond)가 경과했는지 나타내는 값
- 41bit로 표현할 수 있는 타임스탬프 최댓값은 2^41 - 1 = 2199023255551ms
- 최댓값은 69년이므로 이 생성기는 69년동안 정상 작동
- 시간의 흐름에 따라 큰 값을 가지게 되므로 결국 ID는 시간순 정렬 가능.
데이터센터(datacentor) ID
- 5bit 할당
- 2^5 = 32개 데이터센터 지원 가능
서버(server) ID
- 5bit 할당
- 데이터센터당 32개 서버를 사용 가능
일련번호(sequence number)
- 12bit 할당
- 12bit이므로, 2^12 = 4096개의 값을 가질 수 있음
- 각 서버에서는 ID 생성할 때마다 이 일련번호를 1만큼 증가
- 일련번호는 1밀리초가 경과할 때마다 0으로 초기화(reset)
- 즉, 1밀리초 내에 두 개 이상의 ID를 생성하지 않는 한 이 영억은 일반적으로 0 이다

데이터센터ID와 서버ID는 시스템 시작 시 결정되며, 일반적으로 시스템 운영 중에는 바뀌지 않음.
타임스탬프나 일련번호는 ID 생성기가 돌고 있는 중에 만들어지는 값.

장점

프로세스당 초당 최소 10,000개 ID 생성
응답 속도 2ms (네트워크 대기 시간 추가)
시계열(시간순, 날짜순) 정렬 가능
UUID 128bit에 비해 64bit로 상대적으로 적으면서 많은 id 생성 가능
독립적으로 ID 생성 가능하므로 분산환경에서 확장성 높음
병렬로 유일한 ID 생성 가능

단점

69년동안 사용가능함
중~소규모에서 운영할 때는 trade-off를 생각해야 함
- sequence 또는 auto_increment에 비해 용량이 크기때문에 비용이 상대적으로 높음
- 서비스가 폭풍성장한다면 DB구조변경, 데이터 마이그레이션, 동시성 문제같은 여러 비용을 생각한다면 미리 만드는것이 좋을수 있음

TSID(Time-Sorted Unique Identifier)

(TSID Github 링크)

twitter의 snowflake와 ULID Spec의 아이디어를 결합한 것
64bit 정수 생성 가능
문자열 형식은 Crockford의 base32로 저장
문자열은 URL 형식을 구분하지 않음
UUID, ULID, KSUID보다 짧음
13자의 문자(13 chars)로 저장 가능

TSID 구조

시간(Time component) 42bit 와 랜덤구성요소(Random component) 22bit 로 이루어짐
시간구성요소는 2020-01-01 00:00:00 UTC 이후의 밀리초 수
랜덤구성요소는 노드ID(node ID)의 0~20bit와 카운터(counter)의 2~22bit로 이루어짐
- e.g. 노드 비트가 10이면 카운터 비트는 12로 제한되는 것
시간구성요소는 부호 있는 64bit 정수 필드에 저장되면 약 69년 동안 사용 가능
시간구성요소는 부호 없는 64bit 정수 필드에 저장되면 약 139년 동안 사용 가능

장점

64bit(8 byte)로 UUID에 비해 상대적으로 적은 용량
DB에 bitint로 저장하고, Java에서 long 사용 가능
UUID와 기존 정수 기반 ID 모두 활용 가능
기본키를 바이트 배열 대신 읽을 수 있는 정수(64bit)로 가져옴
시계열 정렬이 가능해서 DB 성능 저하가 발생하지 않음
JPA와 Hibernate에서 구현되었기에 매우 간단하게 사용 가능

단점

69년 또는 139년동안만 사용가능함

참고자료

‍ JPA & Hibernate 엔티티에서 사용방법

Spring Boot 3 버전을 사용할 경우 Hibernate 6 버전을 사용한다.

따라서 아래 코드를 build.gradle의 dependencies(의존성)에 추가하자.

(아래 코드의 맨 마지막 버전은 자기 프로젝트 호환성에 맞게 고쳐도 됨)

implementation 'io.hypersistence:hypersistence-utils-hibernate-60:3.5.1'

위 라이브러리를 추가했다면 이제 `@Tsid` 어노테이션만 사용하면 아주 간단하게 구현이 되었다.

import io.hypersistence.utils.hibernate.id.Tsid;
import jakarta.persistence.Id;

public class TestEntity {

    @Id @Tsid
    private Long id;

    private String title;
}

Hypersistence Utils 프로젝트는 Spring과 Hibernate 모두를 위한 범용 유틸리티를 제공하는데 여기에 TSID가 구현되어있기 때문이다. Hypersistence Utils 3.2 버전부터 시간정렬식별자(tsid)를 제공하고 있다.

이 외에도 Hibernate 5에서 사용하거나 TSID 값 생성기를 커스터마이징 하고 싶으면 이 글을 참고하자.

TSID 값만 생성하는 것이 필요하다면 TSID Github를 의존성 추가하여 사용하자.

결론

외부에 왠만하면 추측가능한 ID를 노출하지 않는게 좋음 (엔티티를 외부에 노출하지 않듯이)
- e.g. "/users/109" 보다는 "/users/38352658568129975" 또는 "/users/01294A2BDA2"
- 외부 노출용 ID를 따로 생성해서 내부 pk와 키-값으로 연결하여 주고받거나, 내부 pk를 암호화하는 방법도 있음
"이게 제일 좋다!" 라는 것은 없고 상황마다 적절한 것을 trade-off 하여 사용하여야함
- e.g. 내부적으로 사용하는 것이라면 굳이 PK를 UUID, TSID로 사용할 필요 없이 auto_increment 사용
- e.g. 숫자는 문자열에 비해 작은 크기를 가지므로 저장 및 검색 속도에서 좋고, 문자열은 복잡하게 구성 가능
분산환경에서는 UUID의 단점을 개선한 TSID, snowflake 를 사용하는 것이 좋음
- 각 서버가 독립적으로 유일성이 보장된 ID를 생성할 수 있기 때문
DB가 2대 이상 확장될 수 있는 가능성이 있다면 auto_increment보단 TSID, snowflake이 좋음

맥 m1 mysql 데이터베이스 경로(위치) 찾기

묠니르묘묘 — Tue, 1 Aug 2023 12:24:40 +0900

homebrew로 mysql을 설치하고, m1 맥북이어서 예전의 경로와 다르다.

따라서 mysql에 접속한 후 아래 2가지 쿼리 방법으로 database(데이터베이스)가 저장된 폴더 경로(위치)를 알아낼 수 있다.

# 1번째
show variables like 'datadir';

# 2번째
select @@datadir;

쿼리 결과

m1 맥에다가 homebrew로 설치한 나는 "/opt/homebrew/var/mysql/" 위치에 데이터베이스가 저장되고 있었다.

백엔드 아키텍처 기초 6 - DB 규모 확장

묠니르묘묘 — Tue, 18 Jul 2023 16:44:02 +0900

서비스 규모가 커지면 DB 부하도 같이 증가한다.

그렇기에 DB 확장에 대한 다음 2가지 방법을 생각해야 한다.

수직적 규모 확장 (scale up)
수평적 규모 확장 (scale out)

수직적 규모 확장과 수평적 규모 확장

수직적 확장

기존 서버의 자원(CPU, RAM 등)을 고사양 or 더 많이 증설하는 방법
하드웨어의 한계로 무한 증설 X
서버 1대로 모든 트래픽 감당 X
SPOF(Single Point of Failure) 위험성 증가
고성능 자원일수록 비용 증가

수평적 확장

DB의 수평적 확장은 샤딩(sharding)이라고 부름
더 많은 서버 추가로 성능 향상시키는 방법
샤딩은 대규모 DB를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술
모든 샤드는 같은 스키마를 사용하지만 샤드에 보관되는 데이터에는 중복 X

샤드로 분할된 DB 예시

위 예시는 id % 4 조건을 해시 함수로 사용하여 데이터가 보관될 샤드를 정함

DB에 들어가는 데이터 예시

샤딩 전략 구현 시 샤딩 키(sharding key) 정의가 중요함
- 샤딩 키는 파티션 키(partition key)라고 부름
- 데이터가 어떻게 분산될지 정하는 하나 이상의 컬럼으로 구성됨
- 위 그림 예시에서는 샤딩 키는 id
- 샤딩 키로 데이터 조회나 변경을 처리하므로 효율 높일 수 있음
- 샤딩 키는 데이터를 고르게 분할할 수 있도록 하는게 중요함

샤딩 도입 시 생길 수 있는 문제

데이터의 재 샤딩(resharding)

데이터가 너무 많아져서 하나의 샤드로 감당 못할 때
샤드 간 데이터 분포가 균등하지 못하여 특정 샤드만 공간 소모가 심할 때

위 2가지 상황을 샤드 소진(shard exhaustion)이라고 부르며, 이 때 재 샤딩 발생
샤드 소진 시, 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치 해야함
안정 해시(consistent hashing) 기법 활용하여 문제 해결 가능

유명인사(celebrity) 문제

핫스팟 키(hotspot key) 문제라고도 부름
특정 샤드에 질의가 집중되어 서버에 과부하 생기는 문제
해결하려면 특정 샤드 데이터를 분산시키거나 더 잘게 쪼개야 함

조인과 비정규화(join and de-normalization)

하나의 DB를 여러 샤드 서버로 쪼개면 데이터 조인이 힘들어짐
해결하려면 DB 비정규화하여 하나의 테이블에서 질의가 수행되도록 하는 것

DB 샤딩을 적용한 아키텍처 구조

데이터베이스 샤딩을 적용한 아키텍처 구조

지금까지 아키텍처 구조 정리

웹 계층은 무상태 계층으로
모든 계층에 다중화 도입
접근이 많은 데이터는 가능한 많이 캐시할 것
여러 데이터 센터를 지원하여 지리적 라우팅 할 것
정적 콘텐츠는 CDN 서비스할 것
데이터 계층은 샤딩을 통해 규모 확장
각 계층은 독립적 서비스로 분할할 것
시스템을 지속적으로 모니터링하고, 자동화 도구 활용할 것

백엔드 아키텍처 기초 5 - 메시지 큐, 로그, 메트릭, 자동화

묠니르묘묘 — Mon, 17 Jul 2023 15:38:26 +0900

기초 4에서는 전 세계에서 사용할 때 나라별로 데이터센터를 두어 지리적 라우팅으로 요청 및 응답을 처리하였다. 하지만 데이터 센터마다 데이터 동기화 문제가 있을 수 있다. 이러한 문제를 해결하기 위해 메시지 큐를 사용해보자.

메시지 큐(message queue)

메시지 큐는 메시지의 무손실(durability)을 보장하는 비동기(asynchronous) 통신을 지원하는 컴포넌트
- 즉, 메시지 큐에 보관된 메시지는 꺼낼 때까지 안전히 보관된다는 특성을 지님

메시지 큐 기본 아키텍처 구조

생산자(producer) or 발행자(publisher)라고 불리는 입력 서비스가 메시지를 메시지 큐에 발행(publish)
큐에는 소비자(consumer) or 구독자(subscriber)라고 불리는 서비스 혹은 서버가 연결되어 있음
소비자가 메시지를 받아 그에 맞는 동작을 수행

메시지 큐 장점

메시지 큐를 이용하면 서비스 or 서버 간 결합이 느슨해짐
- 따라서 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋음
생산자는 소비자 프로세스가 다운되어도 메시지 발행 가능
소비자는 생산자 서비스가 가용한 상태 아니라도 메시지 수신 가능

시간이 오래 걸리는 작업을 메시지 큐에 넣고, 작업 프로세스들은 메시지 큐에서 비동기적으로 꺼내 완료시킨다.

이러면 생산자와 소비자 서비스 규모는 각기 독립적으로 확장가능하다.

메시지 큐로 데이터 동기화

데이터 센터간 독립적인 DB로 데이터 불일치 문제가 있을 수 있다.

이러한 문제는 데이터베이스 다중화(넷플릭스 다중화 참고)나 여러 해결방법이 있지만 메시지 큐를 이용한 방법도 있다.

데이터 변경 시 다른 DB에 알려줘서 데이터 반영하기

로그, 메트릭, 자동화

로그(log)

에러 로그로 시스템 오류와 문제를 보다 쉽게 찾아낼 수 있기에 중요함
에러 로그는 서버 단위 모니터링 가능
로그를 단일 서비스로 모아주는 도구 활용하면 더 편리하게 검색 및 조회 가능

메트릭(metric)

특정 수치들을 시각화해서 보여주거나 그대로 알려주는 것
메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻거나, 현 시스템 상태를 손쉽게 파악 가능
호스트 단위 메트릭 : cpu, 메모리, 디스크 I/O 등
종합(aggregated) 메트릭 : DB 계층 성능, 캐시 계층 성능 등
핵심 비즈니스 메트릭 : 일별 능동 사용자(daily active user), 수익(revenue), 재방문(retention) 등

자동화(automation)

시스템이 크고 복잡해지면 생산성을 높이기 위해 자동화 도구를 사용해야 함
지속적 통합(CI, Continuous Integration)을 도와주는 도구를 활용하면 쉽게 문제 감지 가능
빌드, 테스트, 배포 등의 절차를 자동화하여 개발 생산성 크게 향상 가능

메시지 큐, 로그, 메트릭, 자동화를 반영한 아키텍처 구조

메시지 큐, 로그, 메트릭, 자동화 반영된 아키텍처 구조

메시지 큐는 각 컴포넌트가 느슨히 결합될 수 있도록 하고, 결함에 대한 내성 높임
- 시간이 오래 걸리는 작업은 메시지 큐에 넣고, 작업 서버가 비동기적으로 꺼내서 처리함
로그, 모니터링, 메트릭, 자동화 등을 지원하기 위한 장치 추가

kafka 서버에 요청 시 TimeoutException 발생

묠니르묘묘 — Sat, 8 Jul 2023 18:27:00 +0900

kafka 3.5버전

문제 상황

zookeeper 서버 실행 -> kafka 서버 실행 -> kafka 서버에 토픽이 있는지 확인 요청 -> TimeoutException

zookeeper와 kafka 서버 둘 다 서버 기동 확인하고 포트번호 확인하였고, 그 후 카프카 서버에 토픽 확인 요청이나 생성 요청을 보낼 시에 찾지못하고 TimeoutException이 발생했다.

자세한 내용을 보면 "Timed out waiting for a node assignment"로 노드 할당 대기 시간 초과라고 되어있었다.

카프카 서버에 무언가 제대로 요청이 안되었음을 직감하고 stackoverflow에 검색해보았다.

해결 방법

카프카 설정폴더(config)에서 server.properties 수정

카프카 설정폴더 안에 server.properties를 수정한다.

위 사진처럼 주석이 되어있거나 없다면 listeners=PLAINTEXT://localhost:9092 를 넣고 카프카 서버를 재기동한다.

이 후 다시 카프카 서버에 토픽 확인 및 생성 요청을 하면 정상 수행되는 모습을 볼 수 있었다.

server.properties의 listeners 옵션은?

해당 파일에 주석으로 설명이 되어있는데 이를 읽어보자.

server.properties 파일

소켓 서버가 수신 대기하는(listen) 주소이다. 만약 구성되지 않은 경우, 호스트 이름(host_name)은 java.net.InetAddress.getCanonicalHostName()과 같고, PLAINTEXT 수신기 이름(listener_name)과 포트(port) 9092이다.

위 영어글 밑에는 FORMAT과 EXAMPLE이 있는데 포맷에 주석에 나와있는 내용을 넣어보면 EXAMPLE이 된다.

즉, 아래와 같다.

listener_name -> PLAINTEXT
host_name -> your.host.name
port -> 9092

그래서 소켓 서버가 수신대기하는 주소를 저렇게 localhost:9092 로 명시함으로써 실행이 된 것이다.

advertised.listeners 옵션은?

사진 바로 아래에 advertised.listeners 옵션 설정도 있기에 놓치면 안될 것 같아서 위 사진에 나온 내용을 해석하여 아래에 적어본다.

브로커가 클라이언트에 알릴 Listener name, hostname, port 를 설정하지 않으면 "listeners" 값을 사용한다.

이건 설정안하면 위에서 설정했던 "listeners"를 그대로 사용한다.

즉, "listenres" 는 내부적으로 바인딩하는 주소이고, "advertised.listeners"는 클라이언트(컨슈머,프로듀서)같은 외부에 노출할 주소인 것이다. 내부와 외부에 오픈할 특정 IP 주소를 별도로 두기 위해 존재하는 것이다.

https://stackoverflow.com/questions/42998859/kafka-server-configuration-listeners-vs-advertised-listeners

https://shinwusub.tistory.com/133

백엔드 아키텍처 기초 4 - 데이터 센터

묠니르묘묘 — Fri, 7 Jul 2023 22:05:19 +0900

기초 3에서는 무상태 웹 계층을 가지면서 유연하고 확장성 있는 아키텍처 구조를 살펴보았다.

이제는 전 세계에서 접속한다고 했을 때를 생각해보자.

전 세계에서 사용한다면?

데이터 센터

장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터에서 처리됨
이를 지리적 라우팅(geoDNS-routing)이라고 함

데이터 센터가 있을 때 아키텍처 구조

한국 사용자는 Korea DC1, 미국 사용자는 USA DC1 으로 안내됨
만약 데이터 센터 하나가 장애 발생 시, 다른 데이터 센터로 모든 트래픽이 전송됨

⚠️ 다중 데이터 센터 구성 시 주의사항

올바른 데이터 센터로 트래픽을 보내는 효과적인 방법 찾기
- GeoDNS는 사용자에게서 가장 가까운 데이터센터로 트래픽을 보내야 함
데이터 동기화(synchronization)
- 데이터 센터마다 별도의 데이터베이스를 사용할 때, 장애 발생 시 다른 데이터 센터에 데이터가 쌓이고 원래 데이터센터에는 데이터가 없을 것임
- 이런 상황을 막으려면 여러 데이터 센터에 걸쳐 다중화를 해야 함 (넷플릭스 다중화 참고)
테스트와 배포
- 여러 데이터 센터를 사용하도록 시스템이 구성된 상황일 때, 웹 사이트 or 애플리케이션을 여러 위치에서 테스트 해봐야 함
- 자동화된 배포 도구는 모든 데이터 센터에 동일한 서비스가 설치되도록 하는 데 중요한 역할을 함

위와 같은 주의사항(분산 시스템의 여러 문제들)을 해결하기 위해 메시지 큐(message queue)를 사용하기도 한다.

다음은 메시지 큐를 살펴보자.

Spring Cloud Config Client에서 actuator refresh 장애

묠니르묘묘 — Sat, 1 Jul 2023 15:58:19 +0900

Spring Cloud Config Client 에서는 Config Server의 변경된 설정정보를 받기위해서는 actuator refresh 방법으로 설정정보를 갱신할 수 있다. 그런데 아무리 refresh를 해도 변경된 설정정보가 갱신이 안되는 장애를 겪었다. 아무리 살펴봐도 application.yml에 잘못적은 것이 아닌데 무엇이 문제인가 생각하다가 bootstrap 라이브러리때문인 것을 알게되었다.

상황

Spring Cloud Config Server에서 변경된 설정정보를 받으려고 Actuator refresh API 호출함
refresh API 호출하였지만 설정정보가 갱신되지 않음

문제해결

Spring Cloud Config 공식홈페이지에서 Spring Cloud Config Client 챕터를 살펴보다가 레거시가 되버린 bootstrap 라이브러리 때문이지 않을까 싶어서 dependencies에서 제거하니 갱신이 되었다.

정보

Spring Boot 2.4 버전 이전에는 Spring Cloud Bootstrap을 통해 Spring Cloud Config Server 설정을 관리할 수 있었다. 하지만 Spring Boot 2.4 버전 이후에는 application.yml 설정파일로도 Config Server 데이터를 가져올 수 있게 되면서 더 이상 쓰지않게 되었다.

Spring Boot 2.4 버전 이후에는 application.yml에 아래와 같이 설정하면 된다.

spring:
profiles:
active: dev #참조하고자 하는 yml파일명 뒷부분
cloud:
config:
name: ecommerce #참조하고자 하는 yml파일명 앞부분
config:
import: optional:configserver:http://localhost:8888 # Config Server의 URI

만약 ecommerce-dev.yml 파일과 ecommerce-prod.yml 파일이 있다고 할 때, 위와 같은 설정이면 ecommerce-dev.yml 파일을 Config Server로부터 가져와서 활성화하게 된다.

만약 레거시한 방법인 bootstrap을 사용하려면 공식 홈페이지에 나와있는 대로 설정해야한다. 공식 홈페이지에서는 `spring-cloud-starter-bootstrap` 스타터를 통해 활성화 해야 한다고 적혀있다. 속성은 아래와 같이 설정한다.

spring.cloud.bootstrap.enabled=true

이렇게 bootstrap이 활성화되면 bootstrap.yml 에 적어놨던 spring.cloud.config.uri 속성을 통해 Config Server에 연결된다.

간단하게 bootstrap.yml에는 아래와 같이 설정되어 있다.

spring:
cloud:
config:
uri: http://localhost:8888
name: 파일명

백엔드 아키텍처 기초 3 - 웹 계층 수평적 확장

묠니르묘묘 — Tue, 27 Jun 2023 14:35:47 +0900

백엔드 아키텍처 기초 1에서는 규모에 따른 웹 계층을 수평적 확장하는 방법을 알아봤다.

웹 서버를 Scale Out 하더라도 로드 밸런서를 통해 트래픽 분산을 시키는 방법이다.

하지만 사용자 상태 정보와 같은 점은 생각하지 않았다.

이번에는 그에 관해 고민하고 정리한다.

웹 서버끼리 상태 정보는 어떻게 하나요?

무상태(stateless) 웹 계층

상태 정보를 웹 계층에서 제거하고, DB 같은 지속성 저장소에 보관하고 필요할 때 가져오는 것

상태 정보 의존적인 아키텍처

서버는 클라이언트(사용자)의 상태 정보를 유지하여 요청들 사이에 공유되도록 함

상태 정보 의존적인 아키텍처

같은 클라이언트(사용자)로부터의 요청은 항상 같은 서버로 전송되어야 하는 단점 존재
- 즉, 사용자 A가 서버 2에 요청하면 새로 로그인을 해야 함
- 이를 위해 로드밸런서가 고정 세션(sticky session) 기능 제공
- 하지만 고정 세션도 하나의 서버에만 트래픽이 몰릴 수 있는 문제점 존재
- 또한, 고정 세션을 사용하면 서버 추가 및 제거도 까다로울 수 있음

무상태 아키텍처

클라이언트 요청은 어떤 웹 서버로도 전달될 수 있음
웹 서버는 상태 정보가 필요할 경우 공유 저장소에서 데이터 가져옴
즉, 상태 정보는 웹 서버로부터 물리적으로 분리되어 있음

무상태 아키텍처

이 구조는 단순하고 안정적이며 규모 확장 쉬움
공유 저장소는 RDBMS, Memcached/Redis, NoSQL 일 수 있음
- 자동 규모 확장(autoscaling)이 지원되는 저장소 사용을 추천

무상태 웹 계층이 추가된 아키텍처 설계

상태 정보가 웹 서버들로부터 제거
트래픽 양에 따라 웹 서버 추가 및 제거만 해도 자동으로 규모 확장 가능

백엔드 아키텍처 기초 2 - 응답시간 개선

묠니르묘묘 — Mon, 26 Jun 2023 13:09:36 +0900

백엔드 아키텍처 기초1에서는 사용자 규모에 따른 시스템 설계를 알아봤다.

이제는 응답시간(Latency) 개선에 대해 알아보자.

응답 시간은 캐시(Cache)와 콘텐츠 전송 네트워크(CDN, Content Delivery Network)로 개선할 수 있다.

사용자는 어떻게 웹사이트의 응답을 빨리 받아볼 수 있을까?

캐시

비싼 연산 결과 or 자주 참조되는 데이터를 메모리에 올린 후, 메모리에서 응답하는 임시 저장소
DB에서 조회하는 것보다 메모리에서 조회하는 것이 매우 빠름
단점으로는 용량이 디스크에 비해 매우 적고, 비용이 비쌈

캐시 계층

데이터가 잠시 보관되는 곳으로 DB보다 매우 빠름
DB의 부하를 줄이고, 캐시 계층의 규모를 독립적으로 확장 가능

캐시 계층에 데이터가 있다면 아래 구조로 빠른 데이터를 반환받을 수 있음

캐시에 데이터가 존재할 때

캐시 계층에 데이터가 없다면 DB에서 데이터를 반환받아야 함

캐시에 데이터가 없을 때

위 캐시 계층 구조처럼 캐시에 데이터가 있으면 반환하고 없으면 DB에서 반환받는 캐시 전략을 주도형 캐시 전략(Read-Through Caching Strategy)라고 한다. 이 외에도 다양한 캐시 전략이 존재한다.

캐시 사용 시 주의사항

Q. 캐시는 어떤 상황에서 사용해야하는가?

A. 데이터 갱신은 자주 발생 X, 참조는 자주 발생 O

Q. 어떤 데이터를 캐시에 두는가?

A. 영속적 보관 데이터는 X, 휘발성 데이터는 O, 따라서 중요 데이터는 지속적 저장소에 보관

Q. 캐시 데이터의 만료시간은?

A. 만료된 데이터는 삭제해야하며, 너무 짧으면 DB조회가 많이 발생하며, 너무 길면 원본 데이터와 차이날 가능성 존재하므로 적절하게 설정해야함

Q. 일관성(consistency)은 어떻게 유지하는가?

A. 원본 데이터 갱신 연산과 캐시 갱신 연산이 단일 트랜잭션으로 처리되지 않으면 일관성이 깨질 수 있음. 따라서 Cache Invalidation, Cache Refresh, Write-Through, Read-Through, Write-Behind, Cache Validation 같은 방법들로 일관성을 유지할 수 있다.

✅ 캐시 무효화 (Cache Invalidation)

웹 서버가 데이터 요청 시, 캐시에서 찾아보고 없으면 DB나 다른 백엔드 서비스에서 데이터를 가져와 캐시에 저장한다.

쓰기(write) 요청일 경우, 웹 서버는 DB에 SQL문을 요청하고 memcache에 삭제 요청을 전송하여 오래된 데이터를 무효화시킴.

캐시된 데이터를 갱신하는 것보다 삭제하는 이유는 삭제는 중복적으로 수행해도 안전하기 때문이다. (멱등성)

위 같은 방법을 페이스북 논문인 Scaling Memcache at Facebook 에서 소개하고 있다.

세계에서 가장 큰 소셜 네트워크 서비스를 운영하는 페이스북의 Memcached 활용방법을 살펴보면 많은 도움이 될 것 같다.

Q. 장애 대응은 어떻게 할 것인가?

A. 캐시 서버 한 대만 두면 단일 장애 지점(Single Point of Failure) 될 가능성 존재함. 따라서 여러 지역에 걸쳐 캐시 서버를 분산해야 함.

Q. 캐시 메모리의 크기는?

A. 너무 작으면 용량 초과로 장애가 나거나, 데이터가 너무 자주 밀려나서(eviction) 캐시 성능 떨어짐. 결국 과할당(overprovision)해야 여러 문제를 방지할 수 있음.

Q. 데이터 방출(eviction) 정책은?

A. 캐시가 꽉 차면 기존 데이터를 방출할 정책을 정해야 한다. 보통 LRU 많이 쓰고, LFU, FIFO 등 상황에 맞게 사용함.

→ LRU : 가장 마지막으로 사용된 데이터 방출

→ LFU : 사용 빈도가 가장 낮은 데이터 방출

→ FIFO : 가장 먼저 들어온 데이터 방출

콘텐츠 전송 네트워크 (CDN)

정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크
이미지, 비디오, CSS, JavaScript 파일 등 캐시 가능
사용자가 웹 사이트 방문 시, 지리적으로 가장 가까운 CDN 서버가 정적 콘텐츠를 제공함
물리적 거리가 가까울수록 속도가 빠름

지리적 거리에 따른 속도

미국 서버를 한국에서 접근하면 느리기에 한국 CDN서버로 빠른 응답 제공

CDN 동작 방식

사용자A가 이미지 파일 접근
CDN 서버의 캐시에 이미지가 없으면 원본 서버에서 가져옴
원본 서버가 파일을 CDN 서버에 반환
CDN 서버는 파일을 캐시하고 사용자A에게 반환
사용자B가 이미지 파일 접근
만료되지 않은 이미지 요청은 CDN 캐시를 통해 반환

CDN 사용 시 주의사항

비용
- CDN은 제3 사업자에 의해 운영되며, 데이터 전송량에 따라 비용 발생
- 따라서 자주 사용되는 콘텐츠만 캐싱해서 사용
적절한 만료 시한 설정
- 캐시처럼 짧으면 서버와 자주 접속하고, 길면 일관성 문제 발생
CDN 장애 대응
- CDN 서버 장애 시 원본 서버에서 정적 컨텐츠 제공하도록 시스템 구성
컨텐츠 무효화 방법 설정
- CDN 서비스 사업자가 제공하는 API로 컨텐츠 무효화
- 컨텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝(object versioning) 이용

캐시와 CDN이 추가된 아키텍처 설계

캐시와 CDN 서버가 추가된 아키텍처 설계

정적 컨텐츠(JS, CSS, 이미지 등)은 웹 서버가 아닌 CDN에서 제공하여 응답속도 개선
캐시를 통해 DB의 부하를 줄이고 응답속도 개선

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬

AWSome Day 온라인 컨퍼런스 후기

묠니르묘묘 — Wed, 21 Jun 2023 15:12:59 +0900

편하게 듣고 정리할 생각은 없었는데 메일을 보니 참석 증명서를 보내주길래 적게되었다.

받아보면 성취감과 AWS의 좋은 감정이 생겨서 글로써 남기고 싶어졌다.

AWSome Day 온라인 컨퍼런스 참석 증명서(23.06.08)

클라우드 서비스를 제공하는 여러 회사들이 있다.

AWS
Azure
Google Cloud
Oracle Cloud
네이버 클라우드
...

이 중 가장 많은 점유율을 가지고 있는 AWS가 궁금했었는데 마침 AWS 온라인 컨퍼런스 신청을 받고 있길래 냅다 신청하고 들었다. 온라인 강의처럼 3시간동안 듣는 형식이라 큰 부담이 없었다.

AWS 클라우드 개념
AWS 핵심 서비스 설명
AWS 사용 사례

위와 같은 내용으로 이루어져 있어서 입문자가 듣기 아주 좋았다.

강연 목록

AWSome Day 온라인 컨퍼런스 강연 목록

AWS 클라우드 소개

온프레미스와 클라우드

온프레미스는 데이터 센터를 직접 구축, 소유, 운영하는 것
클라우드는 사용한 만큼만 비용 지불하는 방식으로, 직접 데이터 센터를 구축 및 운영 필요가 없음

클라우드 컴퓨팅의 장점

클라우드 컴퓨팅에서는 인프라를 더 이상 하드웨어라고 생각하지 않고 소프트웨어라고 생각하고 사용할 수 있다.

선행 비용을 가변 비용으로 대체
속도 및 민첩성 향상
규모의 경제로 얻게 되는 이점
데이터 센터 운영 및 유지 관리에 비용 투자 불필요
용량 추정 불필요
몇 분 만에 전 세계에 배포

✏️ AWS 핵심 인프라 및 서비스

AWS 핵심 인프라 및 서비스(우측)

좌측은 온프레미스 환경에서 서비스를 운영하기 위한 구조
우측은 클라우드 환경에서 서비스를 운영하기 위한 구조

✏️ AWS 주요 서비스 영역

AWS 주요 서비스 영역

VPC : 논리적으로 할당된 가상 네트워크 공간
- EC2 : 서버 가상머신
- EBS : 서버에 대한 영구적인 블록 스토리지
S3 : 거의 모든 종류의 데이터를 저장 및 검색할 수 있는 객체 스토리지
DynamoDB : 빠르고 유연한 NoSQL 데이터베이스 서비스
Lambda : 서버를 구축할 필요 없이 코드 실행할 수 있는 이벤트 중심의 서버리스 컴퓨팅 서비스
SageMaker : 기계 학습 모델을 구축, 훈련, 배포하는 완전관리형 서비스

느낀점

AWS에는 정말 다양한 서비스를 제공하고 있어서 다른 클라우드 서비스가 필요가 없다. 하지만 개인이 사용하기에는 아주 치명적인 단점이 있다. 그것은 "비용"이다. Oracle Cloud 같은 경우는 프리티어로 사용해도 한계점을 넘으면 서비스가 중단되고 과금되지 않지만, AWS는 프리티어 용량을 넘기면 과금되는 구조로써 가장 치명적인 단점이다. 이 때문에 AWS를 쉽게 접근하지 못하는 개발자들이 꽤나 있는걸로 알고 있고, 또는 프리티어를 사용하다가 무료 제공되지 않는 서비스나 용량을 넘겨 과금되는 경우가 있어 치를 떠는 개발자도 있었다. 그렇기에 이런 입문자용 컨퍼런스나 강의가 가장 필요하며 AWS가 널리 알려줘야한다고 생각한다. (과금 요소 없애는게 가장 좋지만...)

AWS 핵심 서비스를 이해하는데 도움됨
VPC나 보안 등 알기 힘들었던 부분에 대해서도 너무 좋았음
입문자용 컨퍼런스가 있다면 다음에도 들을 생각이 있음

이렇게 AWS에 대해 하나씩 듣다보면 자격증에도 관심이 자연스레 생길 듯 싶다.

AWSOME DAY 온라인 컨퍼런스 공식 홈페이지

https://velog.io/@j3ss83/AWSome-Day-온라인-컨퍼런스-강연-내용-정리-참여-후기

https://blog.kico.co.kr/2022/03/08/aws-vpc/

백엔드 아키텍처 설계 기초

묠니르묘묘 — Mon, 19 Jun 2023 16:54:17 +0900

백엔드 개발자로서 서버 개발을 먼저 학습했지만, 정작 아키텍처 설계를 어떻게 해야하는가에 대한 고민을 많이 하지 않았다. 당연하게 [클라이언트]-[서버]-[데이터베이스] 구조로만 생각했었다. 지금은 MSA와 여러 아키텍처에 대한 학습을 하다보니 어떤 식으로 설계를 해야하는가에 대한 고민이 생겼다.

메시지 큐(message queue)는 어느 환경에서 사용해야할까?
트래픽이 증가하면 단일 서버가 장애나지 않을까?
현재 프로젝트를 멀티 서버로 했을 때의 문제점은?
DB가 하나일 때 장애가 난다면 서비스를 빠르게 복구하기 힘들지 않은가?
DB보다 빠른 캐시 서버의 도입은?
MSA에서 각 서비스마다의 통신은 어떻게?
채팅 서비스를 만든다고 했을 때의 아키텍처 설계는 어떻게?

위와 같은 여러 의문점들이 많은데 그에 따른 정형화된 패턴이 없다. 왜냐하면 사용자 수, 트래픽, 비용 등 여러 변수들로 각각의 상황마다 전부 다른 아키텍처 설계를 적절히 해야하기 때문이다. 현재 상황보다 이상적인 아키텍처 설계를 한다면 오버 엔지니어링 문제로 비용이 상당히 커질 수도 있다. 그렇다면 어떻게 유연하고 가용성있는 아키텍처 구조를 설계할 수 있을까?

가장 단순한 단일 서버에서부터 생각해보자

단일 서버

웹, DB, 캐시 등 모든 것이 서버 한 대에서 실행되는 간단한 구조

단일 서버 아키텍처 구조

사용자는 웹 브라우저에 URL 입력
URL은 DNS(Domain Name Service)에서 IP 주소로 변환되어 반환
반환된 IP 주소로 HTTP 요청
요청 받은 웹 서버는 HTML 또는 JSON 형태의 응답을 반환

사용자가 늘어난다면 서버를 여러대 두어야 하나요?

데이터베이스 분리

웹/모바일 트래픽 처리 서버(웹 계층)와 데이터베이스 서버(데이터 계층)를 분리시킨 구조
용도에 따른 분리로 각각 독립적으로 확장 가능

웹 계층과 데이터 계층 분리 구조

웹 브라우저는 www.naver.com을 요청하여 웹 서버에서 HTML을 반환받음
모바일 앱은 api.naver.com을 요청하여 웹 서버를 거쳐서 데이터베이스에서 데이터를 반환 받음
단순 사용자 증가라면 정적 콘텐츠 반환 트래픽이 증가하니 웹 서버를 증가
사용자가 데이터를 많이 사용한다면 데이터베이스 서버를 증가

서버를 증가시키는 방법만 있을까? NO

✅ 수직적 규모 확장(scale up)과 수평적 규모 확장(scale out)

수직적 규모 확장
- 서버의 사양(CPU, RAM 등)을 고사양으로 추가하는 행위
수평적 규모 확장
- 서버를 추가해서 트래픽을 분산시켜 성능 개선하는 행위

위와 같은 방식으로 웹 서버나 데이터베이스 서버의 성능을 개선할 수 있다.

하지만 수직적 규모 확장의 경우 아래와 같은 단점이 있다.

확장의 한계로, 고사양 자원을 무한대로 증설할 방법 X
장애 대응 X, 자동복구나 다중화 방안이 없어서 장애 발생 시 완전 중단

위와 같은 단점으로 대규모 트래픽 서비스같은 경우 수평적 규모 확장법을 사용한다.

Scale Out을 한다면 어떻게 요청을 분산시키나요?

로드 밸런서

로드밸런서는 부하 분산 집합(Load Balancing Set)에 속한 웹 서버들에게 트래픽 부하를 고르게 분산시킴
수평적 규모 확장으로 웹 서버 증설 후, 로드밸런서로 트래픽 부하를 분산시키는 구조
- 하나의 웹 서버에 많은 사용자가 몰릴 때의 문제점을 해결

로드 밸런서 추가

클라이언트는 공개 IP 주소(Public IP Address)로 접속하고, 로드밸런서는 적절히 사설 IP 주소(Private IP Address)를 이용하여 요청 처리함
- 클라이언트는 사설 IP 주소를 모르기에 보안적인 측면에서도 좋음
- 또한 사설 IP 주소는 인터넷을 통해 접속 X
서버 1이 장애 시, 모든 트래픽은 서버 2로 처리
트래픽 증가를 처리하려면 웹 서버를 추가하기만 하면 되며, 나머지는 로드밸런서가 처리해줌

웹 계층은 트래픽 처리가 되지만 데이터베이스는 어떡하나요?

데이터베이스 다중화

데이터 계층에서 DB 장애 및 부하 문제를 데이터베이스 다중화를 통해 해결할 수 있음
데이터베이스 다중화는 서버 사이에 주(Master)-부(Slave) 관계를 설정하여 데이터 원본은 주 서버, 사본은 부 서버에 저장하는 방식
주 서버(Master)
- 쓰기 연산(Write Operation)
- 데이터 원본
부 서버(Slave)
- 읽기 연산(Read Operation)
- 데이터 사본
대부분 애플리케이션의 경우에 읽기 연산 비중이 훨씬 높기에 부 서버가 많음
부 서버가 전부 장애 발생 시, 주 서버가 읽기 연산을 처리함
주 서버가 장애 발생 시, 부 서버 중 하나가 새로운 주 서버가 됨
- 부 서버의 데이터가 최신 상태가 아닐 가능성이 있음
- 최신 상태가 아니거나 없는 데이터가 있을 시, 복구 스크립트로 추가해야 함
- 이런 문제를 해결하려면 다중 마스터(Multi-Masters), 원형 다중화(Circular Replication) 방식을 생각할 수 있음

데이터베이스 다중화 구조

성능
- 데이터 변경 연산은 Master 에만 전달하고, 읽기 연산은 Slave 들로 분산하여 병렬로 처리될 수 있는 질의(Query)의 수가 늘어나므로 성능이 좋아짐
안정성(Reliability)
- 서버 중 하나가 파괴 및 장애가 나도 데이터 보존 가능
- 데이터를 지역적으로 떨어진 여러 장소에 다중화 가능하기 때문
가용성(Availability)
- 데이터를 여러 지역에 복제함으로써, 하나의 DB에 장애 발생하더라도 다른 서버의 데이터를 가져와서 계속 서비스 할 수 있음

로드밸런서와 데이터베이스 다중화를 고려한 구조는 어떻게 생겼나요?

로드밸런서와 데이터베이스 다중화를 고려한 설계

로드밸런서와 데이터베이스 다중화 아키텍처 구조

사용자는 DNS로부터 로드밸런서의 공개 IP 주소 받음
사용자는 해당 IP 주소를 사용하여 로드밸런서 접속
HTTP 요청은 서버 1 or 서버 2로 전달
웹 서버는 사용자의 데이터를 Slave DB에서 읽고, 데이터 변경 연산은 Master DB로 전달

마무리

지금까지 가장 기본적으로 서버를 유연하고 확장시킬 수 있는 아키텍처 구조를 살펴보았다.

웹 계층과 데이터 계층 분리
각 계층마다 수평적 규모 확장(Scale Out)
Scale Out으로 추가된 웹 서버들은 로드밸런서로 트래픽 분산
데이터베이스 다중화로 부하 분산

이러한 구조를 만들려면 클라우드 서비스를 이용하는 것이 가장 좋다.

현재 AWS가 가장 인기있고 점유율이 높다.

현재 아키텍처 구조가 가장 이상적인 설계안일까요? NO
응답시간을 개선할 수 있어요!

응답시간을 개선하기 위한 방법은 다음 게시글을 통해 알아보자.

가상 면접 사례로 배우는 대규모 시스템 설계 기초 | 알렉스 쉬

로컬에서 동일한 SpringBoot 서버를 여러개 실행하는 방법

묠니르묘묘 — Fri, 2 Jun 2023 17:05:15 +0900

스프링부트 1개의 서버를 로컬에서 여러개 띄워야하는 경우에는 여러 방법을 통해 실행할 수 있다.

IDE(통합개발환경) 사용하기

IntelliJ(인텔리제이)에서는 서버 옵션을 편하게 설정할 수 있다.

나는 인텔리제이 2022.2.3(Ultimate edition) 버전을 사용하고 있음.

1. 수동으로 포트번호 설정하기

위 사진처럼 구성 편집(Edit Configurations...) 을 클릭

서버를 복사 후 VM 옵션 추가

인텔리제이 버전마다 다르지만 내가 사용하는 버전에서는 [옵션 수정] 버튼을 눌려서 VM 옵션을 추가해야 보인다.

VM 옵션에 위 사진처럼 적기

-Dserver.port=포트번호

VM 옵션에서 [포트번호적기]에 원하는 포트번호를 적으면 해당 포트번호로 서버가 실행되게 된다.

만약 "-Dserver.port=1234" 를 적었으면 1234 포트번호로 서버를 실행시킨다는 의미이다.

참고로 복제한 것에 이름은 바꿔주고 [적용] - [확인] 을 눌려준다.

서버 실행하기

서버 실행은 평소와 똑같이하고 중지시키는 것도 똑같은 위치로 들어가서 중단시키면 된다.

2. 자동으로 포트번호 설정하기

https://ssdragon.tistory.com/150

SpringBoot 랜덤포트로 실행하기

상황 1개의 SpringBoot 서버를 여러개로 실행해야 함 따라서 포트번호를 서버마다 다르게 지정해야 함 수동으로 지정하는 것은 매번 관리하는 것이 어려움 해결 방법 server: port: 0 application.ym

ssdragon.tistory.com

위 내용에서 나온 것처럼 스프링부트 서버를 랜덤포트로 설정한다.

VM 옵션 삭제

수동으로 설정했던 VM 옵션부분을 삭제한 후 동일하게 실행시키면 개발자는 편하게 실행시킬 수 있다.

Gradle 사용하기

스프링부트 프로젝트 폴더

스프링부트 프로젝트 폴더에 있는 gradlew 를 사용한다.

인텔리제이는 터미널을 바로 사용할 수 있으므로 해당 IDE에서 gradlew를 통해 실행시켜본다.

만약 없다면 컴퓨터에서 따로 터미널을 실행시켜 해당 위치로 들어가서 진행하면 된다.

1. 수동으로 포트번호 설정하기

터미널에서 gradlew 실행

./gradlew bootRun --args='--serverport=포트번호'

사진이 작아서 안보이겠지만 위 명령어를 터미널에서 사용하여 서버를 실행시켰다.

2. 자동으로 포트번호 설정하기

포트번호를 랜덤포트로 설정했다면 아래 명령어만 입력하여 실행시키면 된다.

./gradlew bootRun

maven 사용하기

gradle이 아니라 maven 프로젝트라면 아래 명령어를 터미널에서 사용하면 된다.

mvn spring-boot:run -Dspring-boot.run.jvmArguments='-Dserver-port=포트번호'

만약 실패한다면 jar 파일이 없거나 설정 문제이므로 아래 명령어로 다시 패키징하여 실행해보자.

mvn clean compile package

이것 또한 랜덤포트로 설정해놨다면 아래 명령어로 서버를 실행하면 된다.

mvn spring-boot:run

java 사용하기

스프링부트 프로젝트를 jar로 패키징하고, jar을 java로 실행시킨다.

정확히는 JRE가 있어야하는데 개발자의 경우 JDK로 보통 설치해놨으므로 바로 실행하면 된다.

(JDK에 JRE 포함)

gradle 프로젝트

Gradle 프로젝트라면 위 사진 경로에 jar 파일이 있다.

없다면 아래 명령어를 실행하여 jar 파일 만든다.

./gradlew bootJar

maven 프로젝트

Maven 프로젝트라면 위 사진 경로에 jar 파일이 있다.

없다면 아래 명령어를 실행하여 jar 파일 만든다.

mvn package

이후 아래 명령어를 통해 서버를 실행한다.

java -jar "-Dserver.port=포트번호" ./build/libs/파일.jar

보면 알 수 있듯이 공백을 기준으로 맨 마지막에는 jar파일 경로를 적어주면 된다.

랜덤포트라서 VM 옵션을 추가하지 않아도 되면 아래 명령어처럼 입력하면 된다.

java -jar ./build/libs/파일.jar

SpringBoot 랜덤포트로 실행하기

묠니르묘묘 — Mon, 15 May 2023 16:19:03 +0900

상황

1개의 SpringBoot 서버를 여러개로 실행해야 함
따라서 포트번호를 서버마다 다르게 지정해야 함
수동으로 지정하는 것은 매번 관리하는 것이 어려움

해결 방법

server:
  port: 0

application.yml 또는 application.properties 에서 SpringBoot 서버 포트를 랜덤으로 사용하겠다고 설정
위 예시코드는 yml
이러면 포트가 중복되어도 해당 포트를 우회하여 다른 값을 설정하게 됨

선착순 쿠폰 발급을 위한 redis 분산락

묠니르묘묘 — Thu, 11 May 2023 19:03:02 +0900

선착순 쿠폰 발급을 위한 백엔드 시스템을 구현한 코드는 깃허브에서 볼 수 있다.

요구사항

멀티 서버
선착순 쿠폰 발급
중복 발급 X
짧은 시간 대용량 트래픽 발생

구현 기술스택

Language : Java 11
Framework : Spring Boot 2.7.8
Database : MySQL 8.0, JPA, QueryDSL, Redis
API Documentation : Swagger 3.0.0

해결 방법

1. DB Exclusive Lock(배타적 잠금)

회원쿠폰 발급 로직

JPA Pessimistic Lock(비관적 락)을 이용하여 DB에 배타적 잠금 사용
다른 트랜잭션에서 읽기, 수정, 삭제 방지

SQL 배타적 잠금

SQL을 보면 select for update 구문을 사용하는 것을 볼 수 있음

@Lock(LockModeType.PESSIMISTIC_WRITE)
@QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value = "5000")})
Optional<Coupon> findLockById(Long id);

배타적 잠금은 JpaRepository에 위 코드처럼 작성하여 사용 가능
다른 트랜잭션이 대기하는 시간을 @QueryHints로 설정
대기시간이 지나면 LockTimeoutException 발생

2. Redis Distribution Lock(분산 락)

배타적 잠금에서는 해당 쿠폰 레코드를 Lock 했기에, 해당 쿠폰을 사용하는 다른 서비스에서 데드락 걸릴 가능성 존재
따라서 Redis를 이용한 분산락으로 변경하여 해결하였음
Redis Client는 대표적으로 Redisson과 Lettuce가 있음
- Lettuce : Spin Lock을 사용함. 이는 계속 Lock을 얻으려고 시도하기에 많은 부하 발생
- Redisson : Pub-Sub 기반으로 분산 락 제공함. 따라서 Lettuce보다 부하가 적음

Pub-Sub(Publisher-Subscriber)이란?
메세지 큐 시스템으로 볼 수 있음. Pub을 구독한 Sub들에게 메세지를 알려주는 것. 따라서 여기서는 Pub이 Lock 점유를 끝냈으면 Sub에게 끝냈다고 알려주기에 Sub은 Lock을 얻으려고 시도하지 않음.

2-1. 코드 구현

implementation 'org.redisson:redisson-spring-boot-starter:3.17.0'

public CreateMemberCouponResponse createMemberCoupon(CreateMemberCouponCommand command) {
    RLock lock = redissonClient.getLock(couponLockName);

    try {
        if (!lock.tryLock(10, 3, TimeUnit.SECONDS)) {
            throw new RuntimeException("Lock 획득 실패");
        }
		
        // Lock 획득했으므로 아래부터는 비즈니스 로직 처리
        if (isNotStock(command.getCouponId())) {
            throw new CouponNotRemainException();
        }

        if (isDuplicateCoupon(command)) {
            throw new DuplicateCouponException();
        }

        updateCouponStatePort.decreaseRemainQuantity(command.getCouponId());
        MemberCoupon memberCoupon = createMemberCouponPort.createMemberCoupon(command.getMemberId(), command.getCouponId());
        return new CreateMemberCouponResponse(memberCoupon.getId(), command.getCouponId(), memberCoupon.getCreateDateTime());
    } catch (InterruptedException e) {
        throw new RuntimeException(e);
    } finally {
        if (lock != null && lock.isLocked()) {
            lock.unlock();
        }
    }
}

왼쪽 : 배타적 잠금, 오른쪽 : Redis 분산락 적용

기존 코드와 비교하기위해 사진도 첨부했다. Redis 분산락을 얻기 위한 getLock()과 tryLock()이 생기면서 try/catch 문이 생겨서 코드의 복잡성이 증가했다. 해당 코드는 여기에서 볼 수 있다.

끝내면서

트래픽이 적고, 다른 서비스에서 해당 쿠폰을 많이 사용하지 않으며, 다른 라이브러리를 의존하지 않고 끝내려면 배타적 잠금을 사용
트래픽이 많고, 다른 서비스에서 해당 쿠폰을 많이 사용한다면 Redis 분산락 사용

다른 방법으로는 대기열 아키텍처 방식도 있다. 대규모 동시 요청이 들어온다면 Redis 분산락도 많은 부하가 생길 수 있다. 따라서 대기열을 만들어 처리하는 방법이 있다. 이 대기열 방식은 콘서트나 티켓 예매 사이트와 아래 사이트를 참고하여 알게되었는데 나중에 한번 만들어보고 싶다.

참고

Redis 공식문서

Swagger 3.0 documentationPluginsBootstrapper 에러 해결하기

묠니르묘묘 — Wed, 3 May 2023 13:57:33 +0900

에러 발생 원인

org.springframework.context.ApplicationContextException: Failed to start bean 'documentationPluginsBootstrapper'; nested exception is java.lang.NullPointerException

해당 에러는 SpringBoot 2.6 버전 이후 spring.mvc.pathmatch.matching-strategy 값이 ant_path_matcher에서 path_pattern_parser로 변경되면서 발생하는 오류이다.

따라서 아래와 같이 application.yml 또는 application.properties를 고치면 된다.

spring:
  mvc:
    pathmatch:
      matching-strategy: ant_path_matcher

이렇게 몇달전에 해결하여 Swagger3.0을 잘 사용하였고, 현재 다시 프로젝트를 실행해보니 똑같은 에러가 나오기 시작했다.

그래서 해당 swagger 라이브러리를 제공하고 있는 springfox의 깃허브에 들어가서 관련 이슈를 찾아보니 여러 사람들이 겪고 있던 문제여서 해결방법이 있었다.

해결 방법

1. application.yml을 수정한다

위에서 적었던 방법을 사용한다.

2. IntelliJ IDEA를 사용하고 있다면 캐시 무효화/다시시작을 한다

인텔리제이 캐시 무효화

나는 한글버전의 인텔리제이여서 캐시 무효화로 나와있지만 영어로는 Invalidate Cache/Restart 라고 되어있을 것이다.

3. WebMvcEndpointHandlerMapping 스프링 빈 설정하기

@Bean
public WebMvcEndpointHandlerMapping webEndpointServletHandlerMapping(WebEndpointsSupplier webEndpointsSupplier, ServletEndpointsSupplier servletEndpointsSupplier,
                                                                     ControllerEndpointsSupplier controllerEndpointsSupplier, EndpointMediaTypes endpointMediaTypes,
                                                                     CorsEndpointProperties corsProperties, WebEndpointProperties webEndpointProperties, Environment environment) {
    List<ExposableEndpoint<?>> allEndpoints = new ArrayList<>();
    Collection<ExposableWebEndpoint> webEndpoints = webEndpointsSupplier.getEndpoints();
    allEndpoints.addAll(webEndpoints);
    allEndpoints.addAll(servletEndpointsSupplier.getEndpoints());
    allEndpoints.addAll(controllerEndpointsSupplier.getEndpoints());
    String basePath = webEndpointProperties.getBasePath();
    EndpointMapping endpointMapping = new EndpointMapping(basePath);
    boolean shouldRegisterLinksMapping = this.shouldRegisterLinksMapping(webEndpointProperties, environment, basePath);
    return new WebMvcEndpointHandlerMapping(endpointMapping, webEndpoints, endpointMediaTypes, corsProperties.toCorsConfiguration(), new EndpointLinksResolver(allEndpoints, basePath), shouldRegisterLinksMapping, null);
}

private boolean shouldRegisterLinksMapping(WebEndpointProperties webEndpointProperties, Environment environment, String basePath) {
    return webEndpointProperties.getDiscovery().isEnabled()
            && (StringUtils.hasText(basePath)
            || ManagementPortType.get(environment).equals(ManagementPortType.DIFFERENT));
}

해당 코드는 SpringBoot Actuator의 WebMvcEndpointHandlerMapping 빈을 정의하는 것이다.

이 Bean은 Actuator 엔드포인트를 Spring Web MVC 요청 매핑에 등록한다.

이 해결 방법이 내 코드를 크게 수정하지 않고 Swagger 에러를 해결할 수 있는 방법이었다.

이 외에도 여러 해결방법들이 있었지만 이 것으로 해결되었기에 여기까지만 작성하고 이 방법들은 springfox 깃허브 이슈에서 확인하였으므로 아래 참고 URL을 보길 바란다.

참고

https://github.com/springfox/springfox/issues/3791

[Clean Code] 3장 함수

묠니르묘묘 — Thu, 27 Apr 2023 17:53:37 +0900

들어가면서

지금껏 개발하면서 함수(메서드)를 어떻게 만들어야할지 많은 고민을 했었다. SRP(단일책임원칙)을 지켜야하므로 함수는 한 가지 책임만 가지게 만들어 유지보수성을 높여야한다고 하지만 생각과는 다르게 개발이 되었던 경우가 많았다. 예전에 읽었던 책을 빠르게 읽어보면서 다시끔 클린코드를 생각해보자.

어떤 프로그램이든 가장 기본적인 단위가 함수이다. 아래 질문을 가지고 이번 장을 살펴보자.

함수가 읽기 쉽고 이해하기 쉬운 이유는 무엇일까?
의도를 분명히 표현하는 함수를 어떻게 구현할 수 있을까?
함수에 어떤 속성을 부여해야 처음 읽는 사람이 프로그램 내부를 직관적으로 파악할 수 있을까?

✏️ #1, 작게 만들어라!

함수를 더욱 작게 만들수록 좋다
각 함수가 이야기 하나를 표현하여 명확하게 파악할 수 있다

함수가 작을수록 더 좋다는 증거는 없지만, 100줄 넘는 함수보다 10줄의 함수가 더욱 파악하기 쉽다

함수를 작게 만들라는 규칙이 가장 중요하다고 생각된다. 작게 만들기위해서는 각 함수가 SRP를 지키며 명확하게 작성해야하기 때문이다. 그래서 이야기를 풀듯이 개발할 수 있다.

#1-1, 블록과 들여쓰기

if문, else문, while문 등에 들어가는 블록은 한 줄이어야 한다
블록 안에서 호출하는 함수 이름을 적절히 짓는다면, 코드를 이해하기 쉬움
중첩 구조가 생길만큼 함수가 커져서는 안된다
들여쓰기 수준은 1~2단을 넘어서면 안된다

위 규칙을 지킨다면 함수는 읽고 이해하기 쉬워진다.

들여쓰기는 가독성에서도 중요한 부분이다. if문 3중 중첩을 본적이 있는가? 정말 힘들다. 처음 개발할 당시에도 이런식으로 작성했지만 추후 유지보수 때 파악하기 힘들어 주석을 남겼었는데 지금 생각해보면 주석을 써야할만큼 복잡했다는 의미가 된다. 우아한 테크코스에서도 들여쓰기는 2단을 넘기지 말아야 한다고 했다.

✏️ #2, 한 가지만 해라!

함수는 한 가지를 해야 한다
그 한 가지를 잘 해야 한다
그 한 가지만을 해야 한다

함수 한 개에 여러 작업이 있다면, 함수명을 적절히 지으면서도 함수를 작게 만들어야한다. 벌써부터 힘들지 않은가? 차라리 각 작업을 함수로 추출해서 사용하는 것이 함수명을 적절히 지으면서도 함수를 작게 만들 수 있는 방법이다.

✏️ #3, 함수 당 추상화 수준은 하나로!

함수가 '한 가지' 작업만 하려면 함수 내 모든 문장이 추상화 수준이 동일해야 한다
추상화 수준을 섞으면 코드를 읽는 사람이 헷갈린다
특정 표현이 근본 개념인지 아니면 세부사항인지 구분하기 어렵기 때문이다

`getHtml()` 은 추상화가 가장 높고, `PathParser.render(pagepath);`는 중간이고, `.append("\n")`는 가장 낮음

#3-1, 위에서 아래로 코드 읽기

코드는 위에서 아래로 이야기처럼 읽혀야 좋음
핵심은 짧으면서도 '한 가지'만하는 함수
위에서 아래로 읽어내려 가듯이 코드를 구현하면 추상화 수준을 일관되게 유지하기 쉬워짐

✏️ #4, 서술적인 이름을 사용하라!

함수가 작고 단순할수록 서술적인 이름을 고르기 쉬워짐
"코드를 읽으면서 짐작했던 기능을 그대로 수행한다면 깨끗한 코드"
길고 서술적인 이름이 짧고 어려운 이름보다 좋음
길고 서술적인 이름이 길고 서술적인 주석보다 좋음
이름을 붙일 때는 일관성이 있어야 함

✏️ #5, 함수 인수

함수에서 이상적인 인수 개수는 0개이며, 다음은 1개(단항), 다음은 2개(이항)이다
3개(삼항) 이상은 가능한 피하자
인수가 적을수록 이해하기 더 쉽다
입력 인수를 변환하는 함수라면 변환 결과는 반환값으로 돌려주자
함수에 플래그 인수(boolean)을 넘기는 것은 좋지 않음
이항 함수는 위험이 따른다는 것을 이해하고 가능하면 단항 함수로 변경하는 것이 좋음
삼항 함수는 이항 함수보다 순서, 무시 등 문제가 2배 늘어나는 것을 생각하자
인수가 2~3개 이상 필요하다면 독자적인 클래스를 만들어보자
- e.g. `makeCircle(double x, double y, double radius)` -> `makeCircle(Point center, double radius)`
함수의 의도나 인수의 순서와 의도를 제대로 표현하려면 좋은 함수 이름이 필수
- `write(name)` : 이름이 무엇이든 쓴다
- `writeField(name)` : 이름이 필드 이름이라는 것을 알 수 있음
함수 이름에 키워드를 추가해보자
- `assertEquals(expected, actual)`보다 `assertExpectedEqualsActual(expected, actual)`를 작성하면 인수의 순서를 기억할 필요가 없음

✏️ #6, 부수 효과를 일으키지 마라!

함수는 한 가지 일만 해야하는데 여러 작업을 하게되면 부수 효과가 일어남
부수 효과로 숨겨진 경우에는 혼란이 매우 커짐
예를 들면, 비밀번호 검증 함수인데 실패하면 세션 정보를 지워버리는 부수효과를 만들면 예상치 못한 혼란을 초래할 수 있음

✏️ #7, 오류 코드보다 예외를 사용하라!

오류 코드 대신 예외를 사용하면 오류 처리 코드가 원래 코드에서 분리되어 깔끔해짐
try/catch 블록은 좋지않으며, 코드 구조에 혼란을 일으키며, 정상 동작과 오류 처리 동작을 뒤섞어서 좋지않으므로 블록을 별도 함수로 뽑아내자
오류 처리도 '한 가지' 작업에 속하므로 오류를 처리하는 함수는 오류만 처리하자

✏️ #8, 반복하지 마라!

중복은 문제
코드 길이가 늘며, 알고리즘 변경 시 여러 곳을 손봐야하며, 한 곳을 빠뜨리면 오류 발생
중복을 없애면 가독성 크게 높아짐
많은 원칙과 기법은 중복을 제거하거나 제어할 목적으로 나왔다는 사실을 명심

✏️ #9, 함수를 어떻게 짜죠?

소프트웨어를 개발하는 것은 글짓기와 비슷함
먼저 생각을 기록하고 읽기 좋게 다듬는다
초안은 서투르고 어수선하므로 원하는 대로 읽힐 때까지 다듬고 고치고 정리함
함수를 작성할 때도 위와 마찬가지이며, 처음부터 완벽하게 작성할 순 없다

마치면서

프로그래밍의 기술은 언제나 언어 설계의 기술이다.

이 규칙을 잘 따른다면 길이가 짧고, 이름 좋고, 체계 잡힌 함수가 나올 것이다.

진짜 목표는 "시스템이라는 이야기를 풀어가는 것"을 명심하자.

작성하는 함수가 분명하고 정확한 언어로 깔끔하게 맞아떨어지면 이야기를 풀기 쉬워진다.

Clean Code / 로버트 C.마틴 지음 / 박재호, 이해영 옮김 / 인사이트

Decorator(데코레이터) 패턴이란?

묠니르묘묘 — Tue, 18 Apr 2023 15:12:23 +0900

데코레이터 패턴이란?

객체에 추가 요소를 동적으로 더할 수 있는 패턴
데코레이터를 사용하면 서브클래스를 만들 때보다 훨씬 유연하게 기능을 확장할 수 있음

데코레이터 패턴 대표적인 구조

위 그림에서는 구성 요소의 형식으로 Component를 추상 클래스로 만들었는데, 데코레이터 패턴에서는 특정한 추상 구성 요소를 지정하지 않기 때문에 인터페이스를 사용해도 된다. 따라서 기존의 코드 구조가 추상 클래스면 추상 클래스로 진행하고, 아니라면 인터페이스로 만들면 된다. 여기서는 추상 클래스로 생각하고 진행하겠다.

✏️ Component

기본 기능을 뜻하는 추상 클래스 or 인터페이스
데코레이터들은 이 클래스를 상속하고 있기에 서로를 감쌀 수 있음

✏️ ConcreteComponent

기본 기능(Component)을 구현(정의)하는 클래스

✏️ Decorator

Component를 상속한 클래스들을 장식하는 기능에 대한 인터페이스 or 추상클래스
데코레이터에는 구성 요소(Component)의 레퍼런스를 포함한 인스턴스 변수가 있음
데코레이터는 자신이 장식할 구성 요소와 같은 인터페이스 또는 추상 클래스 상속

✏️ ConcreteDecoratorA, ConcreteDecoratorB

데코레이터는 Component 상태를 확장할 수 있음 (Component에 동적으로 추가될 수 있는 추가 행동을 정의)
데코레이터가 감싸고 있는 Component 객체용 인스턴스 변수가 있음
데코레이터가 새로운 메서드를 추가할 수 있지만, 일반적으로 Component에 있던 메서드를 별도의 작업으로 처리해서 새로운 기능을 추가함

예시 코드 작성해보기

커피 주문 서비스를 위해 커피를 데코레이터 패턴으로 만들어보자

커피 데코레이터 패턴

커피 종류마다 구성 요소를 나타내는 구상 클래스 (HouseBlend, Decaf, Espresso)
각각의 추가 요소를 나타내는 데코레이터 (Milk, Mocha, Whip)
데코레이터 패턴은 데코레이터로 감싸는 객체의 형식과 같으므로 CondimentDecorator가 Beverage를 상속받음
- 구성 요소가 들어갈 자리에 자기가 들어갈 수 있어야하기 때문

✏️ Beverage 추상 클래스

public abstract class Beverage {

    String description;

    public String getDescription() {
        return description;
    }

    public abstract int cost();
}

✏️ Espresso 구현 클래스

public class Espresso extends Beverage {

    public Espresso() {
        description = "에스프레소";
    }

    @Override
    public int cost() {
        return 1000;
    }
}

description은 Beverage로부터 상속받는 인스턴스 변수
구현 클래스에서는 cost()를 구현해줌
나머지 HouseBlend와 Decaf 클래스도 동일

✏️ CondimentDecorator 추상 클래스

public abstract class CondimentDecorator extends Beverage {

    Beverage beverage;

    public abstract String getDescription();
}

각 데코레이터가 감쌀 음료를 나타내는 Beverage 객체를 인스턴수 변수인 beverage에 저장
- 커피를 지정할 때는 데코레이터에서 어떤 커피든 감쌀 수 있도록 Beverage 슈퍼클래스 사용
모든 추가 요소 데코레이터에 getDescription()을 새로 구현하도록 만들기 위해 추상 메서드 추가

✏️ Mocha 구현 클래스

public class Mocha extends CondimentDecorator {

    public Mocha(Beverage beverage) {
        this.beverage = beverage;
    }

    @Override
    public int cost() {
        return beverage.cost() + 500;
    }

    @Override
    public String getDescription() {
        return beverage.getDescription() + ", 모카";
    }
}

Mocha 생성자는 Beverage 레퍼런스가 들어와있음
- 이 데코레이터는 커피에서 추가적으로 넣는 요소이기 때문
cost()에는 커피 가격에 모카를 추가한 가격을 구현
getDescription()에는 커피 이름과 아이템 이름도 같이 구현

✏️ 테스트해보기

Beverage espresso = new Espresso();
System.out.println(espresso.getDescription() + " : " + espresso.cost());
// 에스프레소 : 1000

Beverage decaf = new Decaf();
decaf = new Mocha(decaf);
decaf = new Whip(decaf);
System.out.println(decaf.getDescription() + " : " + decaf.cost());
// 디카페인, 모카, 휘핑 : 2500

Beverage houseBlend = new HouseBlend();
houseBlend = new Milk(houseBlend);
houseBlend = new Milk(houseBlend);
houseBlend = new Whip(houseBlend);
System.out.println(houseBlend.getDescription() + " : " + houseBlend.cost());
// 하우스 블렌드 커피, 우유, 우유, 휘핑 : 3000

위 코드는 여기를 클릭하면 나옴

https://gmlwjd9405.github.io/2018/07/09/decorator-pattern.html

오라클 클라우드 MFA 분실로 인한 로그인 문제

묠니르묘묘 — Fri, 31 Mar 2023 11:21:01 +0900

스마트폰을 바꾸면서 기존에 있었던 Oracle Cloud MFA 키를 가져오지 않았다.

키를 이동시키는 방법은 잘 모르니 OCI에 접속해서 MFA 키를 비활성화하거나 대체 로그인을 설정했어야 했다.

하지만 MFA 비활성화도 하지 않고, 대체 로그인도 설정하지 않아서 오라클 클라우드에 로그인 할 수 없었다.

그렇다.. 망한거다...하...

하지만 드디어 오늘 해결이 되었기에 그 과정을 적어보고자 한다.

문제 발생

오라클 클라우드 로그인 1

우선 계정 이름을 적어 로그인을 시도한다.

오라클 클라우드 로그인 2

여기서도 이메일과 비밀번호를 적어 로그인을 시도한다.

오라클 클라우드 MFA 키 로그인

그럼 이제 2차 인증으로 MFA 인증을 해야한다.

MFA는 Multi-Factor Authentiacation으로 다중 인증 기능이라고 보면 된다.

이걸 사용하면 내 휴대폰에 설치된 앱을 통해 비밀번호를 확인해야 한다.

그 비밀번호는 30초마다 변경되기에 해킹에 매우매우 안전하다.

클라우드 서비스를 이용하다보면 보안 문제에 민감하기 때문에 이 설정을 했었다.

비밀번호는 아래 사진처럼 휴대폰을 통해 확인할 수 있다.

어플은 Oracle Mobile Authenticator이다.

오라클 클라우드 Authenticator 앱

하지만 나는 MFA키가 없었으니까 대체 로그인 방법 표시를 클릭했지만 설정하지 않았기 때문에 로그인을 할 수 없어서 고객센터에 문의를 해야한다.

오라클 클라우드 대체 로그인

여기까지가 오라클 클라우드 MFA 분실로 인한 로그인 문제이다.

해결 방법

1. 오라클 고객센터 이메일 문의 (X)

2월에 이 방법을 시도했다가 실패했다.

oraclehelp_ww@oracle.com 문의했다가 c2csupport_ww@oracle.com 여기로 Cloud 문의하라고 해서 보냈는데 아무것도 못해서 화났다. 몇주씩 기다리고 그랬는데 못했다. 화나서 계정 삭제시키려고 했는데 계정 삭제도 못했다. 문의를 해서 삭제시켜준댔는데 안됐다. 그래서 화나서 카드 재발급 받고 다시 회원가입해서 사용하려고 했었는데 그냥 냅뒀다.

2. 홈페이지 라이브 채팅 (X)

오라클 클라우드에서 클라우드 서버 방치하고 있다고 메일이 와서 뭔가 불안했다. 아무도 로그인 할 수 없었지만 그래도 불안했다. 그래서 다시 아이디를 되찾아보기 위한 노력을 했다.

오라클 홈페이지 라이브 채팅

Live Chat 의 경우에는 실제로 유료 구매 고객에게만 사용할 수 있는 기능이다.

Free Tier를 사용하고 있는 나는 사용할 수 없는 기능이라고 들었다.

Live Chat으로 문의하던 도중 아이디를 부르고나니 무료 계정은 이 라이브 채팅 지원을 사용할 수 없다고 들었다.

서러웠다.

그래서 HUB 팀에 문의하라고 URL 남겨주는 진짜 서러웠다.

HUB 팀 URL : https://www.oracle.com/uk/support/contact.html

3. 오라클 HUB 팀 지원센터 (O)

위의 오라클 서포트 연락처 사이트에서 Korea 를 검색하면 나온다.

즉, 오라클 글로벌 지원 한국 고객센터 전화번호는 +82.1588.8501 이다.

전화를 거니 영어 엄청 잘하시는 여성분이 친절하게 가르쳐주신다.

이 때 감동이었다. (서러운 경험을 받고 친절함을 겪어서일까?)

차근차근 하나씩 문제를 듣고 해결방안을 실시간으로 알려주는데 나는 빛을 보았다.

우선, Oracle Cloud Infrastructure 로그인을 MFA 분실로 인해 못하는 것이기 때문에 기술 지원을 받아야 한다고 했다.

My Oracle Support 에 접속해서 기술 지원에 대한 서비스 요청을 해야 한다고 가르쳐주셨다.

우선 Oracle Cloud 계정과 동일한 이메일을 가진 Oracle 계정이 필요하다.

해당 Oracle 계정으로 로그인해서 Cloud 문의를 해야한다.

위 홈페이지 로그인을 해서 들어가면 아래 사진이 나온다.

My Oracle Support

서비스 요청 탭을 클릭해서 기술적 서비스 요청을 시도한다.

기술적 SR 생성 버튼을 클릭해서 문의를 한다.

My Oracle Support 서비스 요청 문의하기

기술적 SR 생성을 누르면 위 페이지가 나온다.

작성해야하는 부분은 빨간색 상자로 표시해놨다.

Oracle Cloud MFA 로그인 문제라면 위 옵션을 그대로 선택해도 될 듯 하다.

필요에 따라서 변경을 하면 된다.

나는 서비스 유형이 너무 많았기에 무엇을 선택해야하는지 몰라서 비기술적 SR 생성했다가 이렇게 문의하지말라고 한마디 듣고 그쪽에서 자동으로 기술지원으로 변경해줬다. 고마웠다...

저렇게 생성하고나면 담당자가 배정되고 문제에 대해 얘기할 수 있다.

영어로 대화하듯이 글을 남기기에 번역기를 사용하면 된다.

My Oracle Support 서비스 요청

업데이트 추가 버튼을 클릭해서 해당 내용에 대한 답변을 하면 된다.

위 사진처럼 최신순으로 정렬되기에 대화하듯이 사용할 수 있다.

이렇게 Oracle Cloud 로그인 문제를 해결할 수 있었다.

결론

나는 Oracle Cloud MFA 분실로 인해 OCI에 로그인을 못했었지만, 문의를 통해 MFA 초기화해서 로그인을 할 수 있었다.

오라클 또는 오라클 클라우드에 관한 문제는 My Oracle Support 를 통해서 문의를 남기고 해결을 받자.

그게 아니라면 오라클 한국 지원센터에 전화를 해서 상담받도록 하자.

나는 저 HUB팀 전화 아니었으면 지금도 해결못했을거다.

너무 감사하다.

Observer(옵저버) 패턴이란?

묠니르묘묘 — Thu, 30 Mar 2023 15:08:43 +0900

옵저버 패턴이란?

옵저버 패턴

주제(subject)가 변경될 때마다 옵저버(observer)들에게 변화를 알려주는 디자인 패턴
한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체에게 연락이 가고 자동으로 내용이 갱신되는 방식으로 일대다(one-to-many) 의존성을 정의함

주제와 객체를 따로 두는 경우도 있음. 즉, 주제가 객체를 관찰하다가 변화가 생기면 옵저버들에게 알려주는 것

주제는 옵저버들이 인터페이스를 구현한다는 것을 제외하면 옵저버에 대해 아무것도 모른다. 따라서 이들 사이의 결합은 느슨한 결합(Loose Coupling)이다.

옵저버는 언제든지 새로 추가 및 제거 가능
새로운 형식의 옵저버를 추가할 때도 주제는 변경할 필요 X
주제와 옵저버는 서로 독립적으로 재사용 O
주제나 옵저버가 달라져도 서로에게 영향 X

예시 코드 작성해보기

Producer(프로듀서)의 데이터가 변경될 때마다 Consumer(컨슈머)들에게 변화를 알려주는 예시를 작성해보자.

예시 코드 구조

주제는 여러개의 옵저버가 있을 수 있음
주제는 상태가 바뀔때마다 notifyObservers()로 옵저버들에게 알려줘야 함
옵저버가 되려면 Observer 인터페이스만 구현하면 됨

Subject 인터페이스

옵저버 등록, 제거, 변화를 알려주는 메서드가 있음

public interface Subject {
    void registerObserver(Observer o);
    void removeObserver(Observer o);
    void notifyObservers();
}

Producer 클래스

Subject 인터페이스를 구현한 클래스
상태값으로 dataA, dataB를 가짐
전체 상태값을 변경하는 setData() 사용 시, notifyObservers()로 옵저버들에게 변화를 알려줌
상태값 각각의 getter 메서드도 구현되어 있음. 이는 옵저버들이 풀 방식으로 상태값을 직접 가져오기 위함

옵저버 패턴을 사용하면 주제가 데이터를 보내는 푸쉬(push) 방식과 옵저버들 각각 원하는 데이터만 직접 가져오는 풀(pull) 방식이 있다. 일반적으로 풀 방식이 더 옳은 방식으로 간주하고 있다.

public class Producer implements Subject {
    private final List<Observer> observers;
    private String dataA;
    private String dataB;

    public Producer() {
        observers = new ArrayList<>();
    }

    @Override
    public void registerObserver(Observer o) {
        observers.add(o);
    }

    @Override
    public void removeObserver(Observer o) {
        observers.remove(o);
    }

    @Override
    public void notifyObservers() {
        observers.forEach(Observer::update);
    }

    public void setData(String dataA, String dataB) {
        this.dataA = dataA;
        this.dataB = dataB;
        notifyObservers();
    }

    public String getDataA() {
        return dataA;
    }

    public String getDataB() {
        return dataB;
    }
}

Observer 인터페이스

public interface Observer {
    void update();
}

ConsumerA 클래스

Observer 인터페이스를 구현한 클래스
주제를 저장하지 않아도 되지만, 추후 옵저버 목록에서 탈퇴할 때 유용함

public class ConsumerA implements Observer {
    private String dataA;
    private Producer producer;

    public ConsumerA(Producer producer) {
        this.producer = producer;
        producer.registerObserver(this);
    }

    @Override
    public void update() {
        dataA = producer.getDataA();
        System.out.println("ConsumerA가 수정됨 : " + dataA);
    }
}

ConsumerB 클래스

ConsumerA와는 다르게 dataB만을 필요로하는 클래스
따라서 주제가 변경되면 주제에서 원하는 데이터만 직접 가져오는 풀 방식이 더 좋음

public class ConsumerB implements Observer {
    private String dataB;
    private Producer producer;

    public ConsumerB(Producer producer) {
        this.producer = producer;
        producer.registerObserver(this);
    }

    @Override
    public void update() {
        dataB = producer.getDataB();
        System.out.println("ConsumerB가 수정됨 : " + dataB);
    }
}

테스트해보기

class ObserverTest {
    @Test
    void start() {
        Producer producer = new Producer();
        ConsumerA consumerA = new ConsumerA(producer);
        ConsumerB consumerB = new ConsumerB(producer);

        producer.setData("AAA", "BBB");

        producer.removeObserver(consumerA); // consumerA 옵저버 제거

        producer.setData("CCC", "DDD");
    }
}
/*
ConsumerA가 수정됨 : AAA
ConsumerB가 수정됨 : BBB
ConsumerB가 수정됨 : DDD
*/

위 코드는 여기를 클릭하면 나옴

결론

주제와 옵저버 모두 인터페이스를 사용해서 느슨한 결합을 만듦
옵저버 패턴에서는 구성을 활용해서 옵저버들을 관리하므로 확장성 좋음
옵저버들은 서로 독립적이기 때문에 하나의 옵저버가 문제 발생하더라도 다른 옵저버는 영향이 없음
옵저버 객체가 많아질수록 모든 옵저버 객체에 대한 처리를 해야하므로 성능 저하될 가능성 있음

Java Stream(스트림)은 원본 데이터를 변경할 수 있다!?

묠니르묘묘 — Mon, 27 Mar 2023 17:14:02 +0900

나의 의문점을 말하기전에, 스트림이 무엇인지 간단하게 살펴보자.

1. 스트림(Stream) 이란?

Java 8부터 도입된 데이터 처리 기능
데이터 소스에서 데이터를 추상화하여 처리할 수 있도록 도와줌
컬렉션, 배열, 파일 등의 데이터 소스에서 데이터를 읽고, 중간 처리 및 최종 처리하여 원하는 결과를 만듦
스트림은 기존 데이터 소스의 요소를 가져와 중간 처리 연산을 수행하고 새로운 Stream으로 반환함
중간 처리 연산은 lazy evaluation 방식으로 동작하기에 최종 처리 연산이 호출될 때만 수행됨
- 즉, 중간 처리 연산을 호출해도 즉각적인 연산이 되지 않음
- 최종 연산이 수행되어야 스트림의 요소들이 중간 처리 연산을 거쳐 최종 연산에서 소모됨
함수형 프로그래밍 개념을 적용하여 작성했기에 가독성과 유지보수성이 높음
원본 데이터 소스를 변경하지 않고, 새로운 데이터 소스를 생성하여 데이터를 처리함

2. 최종연산 시 원본 데이터 소스가 변경되는 경우

스트림 특징 중 "원본 데이터 소스를 변경하지 않는다"를 읽었는데, 이 의문점은 뭐란 말인가?

일단 해당 특징을 간단하게 살펴보자.

List<String> names = new ArrayList<>();
names.add("myomyo");
names.add("aaa");
names.add("bbb");

Stream<String> strStream = names.stream().map(String::toUpperCase);
names.forEach(System.out::println);
/*
myomyo
aaa
bbb
*/

위 코드에서 names를 대문자로 변환하는 중간 처리 연산을 수행한 Stream을 만들고, names를 출력했지만 소문자로 출력된다. 이것이 원본 데이터 소스가 변경되지 않는다이다.

그렇다면 "원본 데이터 소스가 변경된거 아닌가?"라는 의문점은 어디에서 온것인가?

// given
List<String> names1 = new ArrayList<>();
names1.add("myomyo");
names1.add("aaa");

List<String> names2 = new ArrayList<>();
names2.add("bbb");

List<List<String>> namesList = new ArrayList<>();
namesList.add(names1);
namesList.add(names2);

// when
namesList.stream()
		.filter(names -> names.size() == 2)
		.forEach(names -> names.add("new"));

// then
namesList.stream()
		.flatMap(Collection::stream)
		.forEach(System.out::println);
/*
myomyo
aaa
new
bbb
*/

given에서 테스트할 데이터를 생성
when에서 namesList에 들어있는 List의 사이즈가 2인 것만 필터링해서 그 List에 "new" 추가
then에서 namesList가 가지고 있는 List의 모든 요소를 출력
결과는 원본 데이터인 namesList에 "new"가 추가되어 있음

이것은 스트림의 최종연산인 forEach로 반복하는 것이 참조 객체인 List이기 때문이다.

따라서 참조를 통해 객체를 변경하는 것이므로 당연히 "new"가 추가되는 것이다.

이에 따라 아래 예시코드처럼 클래스의 인스턴스를 가진 리스트도 당연히 원본 데이터 수정이 가능하다.

class A {
    int age;
    public A(int age) {
        this.age = age;
    }
}

A a1 = new A(1);
A a2 = new A(1);

List<A> AList = new ArrayList<>();
AList.add(a1);
AList.add(a2);

AList.stream().forEach(a -> a.age = 2);

AList.forEach(a -> System.out.println(a.age));
/*
2
2
*/

참조된 객체를 변경하는 것이므로 막을 방법은 없다.

이 작업을 수행할 수 있다하더라도 이것은 사용해도 좋은걸까 의문점이 든다.

스트림은 원래의 데이터 소스를 변경하지 않는 것이 side-effects(부작용)를 만들지 않는다고 배웠기 때문이다.

따라서 A클래스를 가진 리스트가 있을 때, age가 20 넘는 것들에 대해서만 age를 +1 해주는 예시를 만들어본다.

List<A> AList = new ArrayList<>();

// 스트림 예시
AList.stream()
    .filter(a -> a.age > 20)
    .forEach(a -> a.age = a.age + 1);
    
// 컬렉션 for loop 예시
AList.forEach(a -> {
    if(a.age > 20) {
        a.age = a.age + 1;
    }
}

// 일반 for loop 예시
for(A a : AList) {
    if(a.age > 20) {
        a.age = a.age + 1;
    }
}

age에 관련된 메서드를 만들면 더욱 간결하게 만들 수 있지만 일단 그것은 논외로 친다.

위 코드에서 무엇이 가장 간결해 보이는가?

나는 스트림 방식이 가장 보기 편하고 눈에 잘들어온다.

그렇기에 스트림의 forEach문으로 참조 객체의 상태를 변경하는 것이 아닐까 싶다.

3. 최종연산 forEach로 참조 객체의 상태를 변경하는 것이 좋을까?

우선 스트림에서 반복할 수 있는 연산은 peek()라는 중간연산과 forEach() 최종연산이 있다.

peek()는 공식문서에 따르면 주로 디버깅을 위해 존재하는 것이라 명시했기에 잘 사용하지 않는다.

그러므로 반복은 forEach() 최종연산을 통해 할 수 밖에 없다.

따라서 해당 의문점을 찾아보기 위해 stackoverflow의 질문과 답변을 확인했다.

https://stackoverflow.com/questions/30778017/modifying-objects-within-stream-in-java8-while-iterating

https://stackoverflow.com/questions/22753755/how-to-add-elements-of-a-java8-stream-into-an-existing-list/22755225#22755225

위 내용을 참고해서 적어본다.

3-1. 반복하는 동안 Java8의 Stream 내 객체를 변경해도 될까?

아래와 같은 코드가 있을 때 이렇게 사용해도 될까?

users.stream().forEach(u -> u.setProperty("value"))

가능하다.

하지만 스트림 내부의 객체 상태를 수정할 수 있지만 대부분의 경우 스트림 소스의 상태를 수정하면 안된다.

스트림 공식문서의 non-interference에 따르면 다음과 같다.

스트림을 사용하면 ArrayList와 같은 안전하지 않은 스레드 컬렉션을 포함하여 다양한 데이터 소스에서 병렬 집계 연산을 실행할 수 있다. 이는 스트림 파이프라인을 실행하는 동안 데이터 소스와의 간섭을 방지할 수 있는 경우에만 가능하다. escape-hatch 연산인 iterator()와 spliterator()를 제외하고는 터미널 연산이 호출될 때 실행이 시작되고 터미널 연산이 완료되면 실행이 종료된다.

대부분의 데이터 소스에서 간섭을 방지한다는 것은 스트림 파이프라인을 실행하는 동안 데이터 소스가 전혀 수정되지 않도록 하는 것을 의미한다. 여기에는 동시 수정을 처리하도록 특별히 설계된 concurrent collections를 소스로 하는 스트림은 예외이다. 동시 스트림 소스는 Spliterator가 CONCURRENT 특성을 보고하는 스트림 소스이다.

병렬 집계 연산을 하려면 데이터 소스와의 간섭을 방지할 수 있는 경우에만 가능
데이터 소스 간섭 방지는 보통 스트림 파이프라인을 실행하는 동안 데이터 소스가 전혀 수정되지 않도록 하는 것

따라서 내가 병렬 집계 연산을 사용하지 않는다면 사용해도 큰 부작용은 없을 듯하다.

다음과 같은 예시 코드를 스택오버플로우에서는 제공하고 있다.

  List<User> users = getUsers();

// 사용해도 괜찮은 예시 #1
  users.stream().forEach(u -> u.setProperty(value));
//                       ^    ^^^^^^^^^^^^^
//                        \__/

// 사용하면 위험한 예시 #1
  users.stream().forEach(u -> users.remove(u));
//^^^^^                       ^^^^^^^^^^^^
//     \_____________________/

// 사용하면 위험한 예시 #2
  List<Integer> list = IntStream.range(0, 10).boxed().collect(Collectors.toList());

  list.stream()
      .filter(i -> i > 5)
      .forEach(i -> list.remove(i));  //throws NullPointerException

하지만 아까 non-interference에서 말했듯이 데이터 소스가 전혀 수정되지 않도록 하는 것을 의미한다고 했다.

그런데 사용해도 괜찮은 예시 #1에서는 데이터 소스를 수정하고 있다.

그에 따른 또 다른 대답은 여기서 볼 수 있었다. (링크)

List<User> users = getUsers();

// #1. user의 나이가 20이상인 것만 변경할 때
List<User> newUsers = users.stream()
			.filter(u -> u.age >= 20)
			.collect(toList());
                            
newUsers.forEach(u -> u.setProperty(value));

// #2. 위 코드를 하나로 합쳐 부작용이 생길 수 있는 코드
users.stream()
	.filter(u -> u.age >= 20)
	.forEach(u -> u.setProperty(value));

여기서는 나이 20이상인 user를 모은 새로운 리스트를 만들고 그 리스트를 컬렉션의 forEach로 반복해서 변경한다.

만약 기존 리스트인 users를 재사용한다면 '부작용이 생길 수 있는 코드'처럼 작성하게 된다.

이 답변을 한 사람은 "코드의 길이는 안전 및 유지 관리성과 관련이 없다" 라고 말을 했다.

#1 코드보다는 #2 코드가 깔끔해보여서 이렇게 작성하고 싶은 욕심이 마구마구 생기지만 stackoverflow와 공식문서의 side-effects 부분을 보면 #1이 안전하다는 것을 알 수 있다.

side-effects(부작용)에 대한 공식문서 내용은 아래와 같다.

// 불필요한 부작용 사용하는 코드
ArrayList<String> results = new ArrayList<>();
stream.filter(s -> pattern.matcher(s).matches())
	.forEach(s -> results.add(s));  // Unnecessary use of side-effects!
    
// 부작용이 없는 코드
List<String>results = stream.filter(s -> pattern.matcher(s).matches())
			.collect(Collectors.toList());  // No side-effects!

위 코드 내용은 문자열 스트림에서 지정된 정규식과 일치하는 문자열을 검색하고 일치 항목을 목록에 넣는 코드이다.

불필요한 코드에 대한 공식문서 내용은 아래와 같다.

이 코드는 불필요하게 부작용을 사용한다. 병렬로 실행하면 ArrayList의 non-thread-safety로 인해 잘못된 결과가 발생할 수 있고, 필요한 동기화(synchronization)를 추가하면 경합이 발생하여 병렬 처리의 이점을 훼손할 수 있다. 또한 여기서 부작용을 사용하는 것은 전혀 불필요하며, forEach()를 더 안전하고 효율적이며 병렬화에 적합한 축소 연산으로 간단히 대체할 수 있다.

따라서 forEach에 로직을 추가하면 동시성 보장이 어렵고 가독성이 떨어지며, 스트림의 의도를 벗어나게 된다.

forEach는 종료를 하기 위한 연산이다.

로직을 수행하는 역할은 중간 연산이 해야하는 일이다.

즉, 최종 연산인 forEach가 중간 연산의 책임을 하게 된다는 의미이다.

4. 너무 길어서 요약하기

List<A> aList = new ArrayList<>();

// #1
aList.stream()
	.filter(a -> a.age >= 20)
	.forEach(a -> a.age += 1); // side-effects 발생 가능

// #2
List<A> updateAList = aList.stream()
		.filter(a -> a.age >= 20)
		.collect(toList());
updateAList.forEach(a -> a.age += 1); // side-effects 발생 X

디버깅을 위한 peek() 연산에서 객체의 상태를 변경하는 것은 좋지 않음
Stream의 forEach()는 최종 연산이다
Stream의 forEach()에 로직을 구현하는 것은 중간 연산의 책임을 하는 것
이펙티브 자바 46에 따르면, forEach 연산은 최종 연산 중 기능이 가장 적고 '덜' 스트림하기에 계산 결과를 보고할 때(print 기능)만 사용하고 계산하는 데는 쓰지 말자 라고 함
forEach를 통해 원본 데이터 소스를 변경하면 side-effects가 발생할 수 있음
스트림을 통한 병렬(paraller) 연산은 사용할만한 상황이 매우 적음 (잘못하면 큰일)
병렬 연산이 매우 적더라도 side-effects가 있는 로직을 구현한다면 나중에 먼 미래에 큰일날 수도?

5. 나의 생각

적을수록 의문점이 들어 글 한번 쓰기 어려웠다. 대부분 스트림의 병렬 연산을 사용하지 않으므로 큰 에러없이 Stream의 forEach()를 통해 원본 데이터 소스를 변경하거나 여러 로직을 구현했을 것이다. 그게 가장 쉬운 방법이면서 보기도 편하기 때문이다.

만약 전체 유저를 가져오고 그 중 일부만 상태값을 변경하고 전체 유저를 반환하는 코드를 작성해야 한다고 생각해보자.

List<User> users = getUsers();
users.stream()
	.filter(u -> u.getAge() >= 20)
	.forEach(u -> u.setAge(u.getAge()+1));
return users;

이 코드는 ArrayList일 때 users의 내부 상태를 변경했기에 ConcurrentModificationException이 발생할 수도 있다는 걸 생각하면서 안전하게 데이터 소스를 수정할 수 있는지 고려해야 한다.

이걸 side-effects 없이 만드려면 어떻게 해야할까?

List<User> users = getUsers();
// 1번째 방법
List<User> updateUsers = users.stream()
		.map(u -> {
			if(u.getAge() >= 20) 
				return new User(u.getAge()+1);
			return u; 
		})
		.collect(toList());
return updateUsers;

// 2번째 방법
List<User> updateUsers = users.stream()
		.filter(u -> u.getAge() >= 20)
		.collect(toList());
updateUsers.forEach(u -> u.setAge(u.getAge() + 1));

List<User> nonUpdateUsers = users.stream()
		.filter(u -> u.getAge() < 20)
		.collect(toList());

List<User> newUsers = new ArrayList<>();
newUsers.addAll(updateUsers);
newUsers.addAll(nonUpdateUsers);
return newUsers;

어떤 방법을 사용하든지 상대적으로 가독성이나 코드가 길어지고 불편해지는 점이 있다.

아마 보기 싫을 수도 있다. 나도 1번째나 2번째 코드보다는 side-effects가 있는 코드가 더 보기 좋아보인다.

따라서 다음과 같이 결론을 내릴 수 있다.

스트림의 forEach()를 사용할 때 안전한 데이터 소스 수정을 고려해야 함
side-effects 없이 데이터 소스를 수정하려면 코드가 길어지고 가독성이 떨어짐
병렬 연산을 대부분 하지 않으니 side-effects 있는 방식을 사용해도 괜찮아보임
혹시 모르니 Stream API를 더 깊이 이해하고 안전한 코드 작성을 위해 노력하는 것이 중요

인덱스(index)란?

묠니르묘묘 — Thu, 23 Mar 2023 14:04:45 +0900

1. 인덱스란?

DB 테이블에 대한 검색 속도를 향상시켜주는 자료구조
인덱스는 보통 B-Tree로 구현되며, 다른 것으로는 Hash Table, Bitmap 등이 있음
인덱스를 테이블의 특정 컬럼에 생성하면 해당 컬럼의 값을 정렬하여 별도의 메모리 공간에 데이터를 물리적 주소와 함께 저장함
인덱스는 insert, update, delete 와 같은 데이터 변경 작업을 느리게 할 수 있지만, select와 같은 검색 작업은 빠른 수행 가능
인덱스는 적절하게 설계하고 유지보수하는 것이 DB 성능 향상에 중요한 역할을 함

예를 들면, 책에서의 목차 또는 색인이라 볼 수 있다. 목차를 보고 빠른 내용을 찾을 수 있기 때문이다.

1-1. 왜 인덱스를 사용하면 검색 속도가 빠를까?

기존 where 문으로 특정 조건 데이터를 찾기 위해서는 전체 테이블 스캔 작업이 필요함
인덱스를 이용하면 데이터들이 정렬되어 있기에 조건에 맞는 데이터를 더 빠르게 탐색 가능
또한, order by문이나 min/max 같은 경우도 이미 정렬되어 있기에 빠른 수행 가능

전체 테이블 스캔(Full Table Scan) : 테이블에 존재하는 모든 데이터를 읽으면서 조건 비교
인덱스 스캔(Index Scan) : 인덱스를 구성하는 컬럼의 값을 기반으로 데이터를 추출하는 액세스 기법

2. Hash Table이란?

간단하고 빠른 검색이 가능한 자료구조
등호 연산에 최적화되어 있으며, key-value 구조로 데이터 저장
인덱스에서는 컬럼 값이 key, 저장된 레코드의 물리적 주소가 value
해시 함수를 이용해 key를 해시값으로 변환하고, 이를 이용해 빠른 데이터 검색 가능
해시 함수를 이용할 때 충돌 발생 시, 일반적으로 해시 테이블은 각각의 슬롯에 연결리스트 사용해서 충돌 처리(Separate Chaining)
해시 테이블은 검색 속도가 매우 빠르지만, 범위 검색에는 적합하지 않음
범위 검색이 자주 일어나는 경우 B-Tree와 같은 자료구조를 사용하는 것이 좋음

2-1. Hash Table에서 범위 검색은 왜 비효율적일까?

범위 검색 수행 시, 일반적으로 연속된 인덱스 엔트리를 찾아야함
해시 테이블은 해시함수에 의해 무작위로 분산되어 저장되기에 인덱스 엔트리들이 서로 물리적으로 연속되어 저장되지 않을 수 있음
이 경우, 연속된 인덱스 엔트리를 찾기 위해 모든 인덱스 엔트리를 검색해야 하기 때문에 비효율적
따라서, 해시 테이블은 주로 동등비교(equality search)에 사용하며, 범위 검색에는 비효율적

인덱스 엔트리(Index Entry)란?
- DB 인덱스에서 각각의 인덱스 키 값에 대한 정보를 담고 있는 데이터 레코드를 말함
- 인덱스 엔트리에는 인덱스 키 값과 해당하는 레코드의 위치 정보가 포함
- 인덱스 엔트리는 인덱스 자료구조의 종류에 따라 다양한 방식으로 구현됨
- B-Tree에서는 인트리가 키와 포인터로 이루어짐
- Hash Table에서는 해시값과 해당 키에 대응되는 데이터 레코드의 위치 정보로 이루어짐

3. B-Tree란?

자주 사용되는 데이터를 효율적으로 검색하기 위해 설계된 트리 구조
B-Tree는 Balanced Tree의 약자로, 트리의 균형을 유지하여 검색 속도를 높이는 것이 핵심
DB 인덱스를 구현하는 데 많이 사용되며, 대용량 데이터를 저장 및 검색하는 데 매우 효율적

3-1. B-Tree 특징

균형 잡힌 트리
여러 개의 자식 노드를 가질 수 있음
각 노드에는 여러 개의 데이터가 저장될 수 있음
데이터 삽입, 삭제, 검색할 때 모든 연산은 트리의 높이에 비례
평균적으로 시간 복잡도는 O(log n)

4. 인덱스 사용 시 주의사항

자주 검색하지 않는 컬럼이면 인덱스 생성 및 관리 비용이 더 늘어날 수 있음
중복 인덱스 방지
- 동일 컬럼을 기준으로 여러 개의 인덱스 생성하지 않도록 주의
- 중복된 인덱스는 불필요한 저장공간을 차지하며 데이터 삽입, 삭제, 수정 시에도 불필요한 비용 발생 가능
인덱스는 공간적 비용이 발생하므로, 너무 많은 인덱스는 성능 저하가 올 수 있음
필드의 크기가 크면 인덱스의 크기도 커짐
인덱스를 지정하면 데이터 삽입, 수정, 및 삭제의 성능이 감소될 수 있음

4-1. 범위 조건 검색일 때 인덱스 사용 주의사항

인덱스는 특정 열에 대한 검색을 빠르게 수행할 수 있도록 테이블의 데이터를 정렬하여 저장함
인덱스의 효율성은 범위 조건 검색의 시작점과 종료점을 찾는 것에 크게 영향을 받음
예를 들면, `WHERE age BETWEEN 20 AND 30` 과 같은 쿼리 실행 시
- `age` 열에서 20~30까지의 범위를 찾아야 함
- 만약 인덱스에서 20~30까지의 값이 연속적으로 저장되어 있다면 인덱스를 효율적으로 사용 가능
- 만약 인덱스에 20,25,30,35와 같이 불규칙하게 저장되어 있다면 인덱스를 사용할 수 있으나 매우 많은 페이지를 탐색해야 하므로 검색 성능이 떨어짐
위 예시를 이유로 범위 조건 검색에서는 인덱스의 효율성이 상대적으로 떨어질 수 있음