3 Tier Architecture

3 Tier Architecture 개념

애플리케이션을 프레젠테이션 계층 또는 사용자 인터페이스, 데이터가 처리되는 애플리케이션 계층 그리고 애플리케이션과 관련된 데이터가 저장 및 관리되는 데이터 계층이라는 3개의 논리적이고 물리적인 컴퓨팅 계층으로 구성하는 확립된 소프트웨어 애플리케이션 아키텍처 각 계층이 자체 인프라에서 실행되기 때문에 각 계층이 별도의 개발 팀에 의해 동시에 개발될 수 있으며 다른 계층에 영향을 주지 않고 필요에 따라 업데이트되거나 확장될 수 있음

출처: IBM "3계층 아키텍처란?"

 


목표 아키텍처 구성도

 

참고: [AWS] AWS로 구축하는 3티어 아키텍처

[AWS] AWS로 구축하는 3티어 아키


VPC

VPC & Subnet

사설 IP C 클래스 IP 대역을 사용해 VPC 생성

Subnet은 이중화를 위해 2개의 Availibility Zone(AZ)으로 나눠 생성(고가용성 확보)

AZ당 Public Sunet 1개, Private Subnet 3개를 생성

총 8개의 Sunet으로 네트워크 구성

Routing Table

Public Subnet용 Routing Table(Public RT)와 Private Subnet용 Routing Table(Private RT)로 구성

Public RT은 Internet Gateway로 트래픽을 라우팅하도록 설정

Private RT는 NAT Instance로 트래픽을 라우팅하도록 설정

NAT instance

1. EC2 생성

  • AMI: amzn-ami-vpc-nat

  • Subnet: Public Subnet
  • Security Group: SGnat
  • Public IP: O

2. EC2 설정

  • 대상 확인/변경 중지 처리

3. Routing Table 설정

  • Private Routing Table에 라우팅 대상으로 등록

 


Security

Security Group

Name Desc. Rule
SGnat NAT instance를 위한 보안그룹 HTTP, HTTPS (src: anywhere IPv4),
SSH (src: myIP)
SGdb RDS를 위한 보안그룹 MYSQL/Aurora (src: SGwas)
SGwas WAS를 위한 보안그룹 TCP 8080port (src: SGnlb),
HTTP, HTTPS (src: SGnat),
SSH (src: SGnat)
SGnlb NLB를 위한 보안그룹 TCP 8080port (src: SGweb)
SGweb Web Server를 위한 보안그룹 HTTP (src: SGalb),
HTTP, HTTPS (src: SGnat),
SSH (src: SGnat)
SGalb ALB를 위한 보안그룹 HTTP (src: anywhere IPv4)

 

 

 


 

Database Tier

Subnet Group 생성

정의한 Subnet에 DB instance가 생성되도록 Subnet Group 생성

RDS 생성

MySQL Engine RDS 생성

  • Engine: MySQL 8.0.35
  • Option: 다중 AZ DB 인스턴스
  • Instance: 스탠다드 클래스
  • Storage: 범용 SSG(gp2)
  • Public Access: NO
  • SG: SGdb

파라미터 그룹 수정

시간대는 서울로 정하고, 한글이 깨지지 않도록 수정

 

Name Value
time_zone Asia/Seoul
character_set_client utf8mb4
character_set_connection utf8mb4
character_set_database utf8mb4
character_set_results utf8mb4
character_set_server utf8mb4
collation_connection utf8mb4_general_ci
collation_server utf8mb4_general_ci

 

Failover Test

MySQL에 접근하여 Failover test 진행

  1. DB instance IP 출력 명령어 입력
while true; do host $RDS_Endpoing | grep address; sleep 1; done
  1. RDS > DB 장애조치 실행
  2. Private IP 주소 출력 변경 확인


Application Tier

Instance 생성

  • AMI: Amazon Linux 2023
  • SG: SGwas

프로그램 설정

1. JDK 설치

2. MySQL 설치 및 DB 연동

  • DB 연동을 위한 MySQL Yum Repository 설치

  • DB 연동을 위한 MySQL comminity server 설치

  • MySQL 실행 후 MySQL 접근 확인

  • MySQL Test Data 생성

 

  • Tomcat을 위한 MySQL Connector/J 설치 후 java lib에 위치시킴

 

3. tomcat10 디렉토리에 Tomcat 설치

4. tomcat service 파일 설정 (참고: service란)

[Unit]
Description=Tomcat 10 servlet container
After=network.target

[Service]
Type=forking
User=root
Group=root
Environment="JAVA_HOME=/usr/lib/jvm/java-21-amazon-corretto"
Execstart=/usr/local/tomcat10/startup.sh
ExecStop=/usr/local/tomcat10/bin/shutdown.sh

[Install]
WantedBy=multi-user.target

5. tomcat 실행

6. 별도 경로에 index.jsp 생성

  • WAS 공통점: testDB 데이터베이스의 test 테이블 데이터 출력하도록 함
  • WAS별 차이점: WAS마다 다른 내용 출력하도록 함(WAS A, WAS C)

7. Root Path 설정

  • server.xml에서 Context 설정

8. Tomcat restart

 

TG 생성

  • Protocol: TCP
  • Port: 8080

NLB 생성

  • 체계: 내부
  • SG: SGnlb
  • 리스너 프로토콜: TCP
  • 리스너 포트: 8080
  • NLB AZ 교차 설정: on


Presentation Tier

Instance 생성

  • AMI: Amazon Linux 2023
  • SG: SGweb

프로그램 설정

1. nginx 설치

2. Nginx Redirect 설정

  • Nginx로 접근 시 NLB로 리다이렉트하도록 설정

  • ALB Health check를 위한 Location Block 추가

TG 생성

  • Protocol: HTTP
  • Port: 80

ALB 생성

  • 체계: 인터넷경계
  • SG: SGalb
  • AZ: Public Subnet
  • 리스너 프로토콜: HTTP
  • 리스너 포트: 80
  • Health check 경로: /health

ALB DNS 접근


도메인 설정

도메인 생성 및 매핑

무료 도메인 사이트에서 도메인 생성 후 CNAME에 ALB DNS 매핑

신규 도메인 접근

목표 구성도

 

 

오토스케일링 그룹 세팅은

VPC 생성
▶ 퍼블릿 서브넷 생성
▶ 보안그룹 생성(ALB용, EC2용)
▶ 대상그룹 생성
▶ 로드밸런서 생성
시작템플릿 등록
▶ 오토스케일링 그룹 등록
▶ 스케일인 정책 등록
스케일아웃, 스케일인 테스트

순으로 진행했습니다.

이중 시작템플릿과 세팅 후 테스트 과정을 기록하였습니다.

 

 

1. TEST VPC 및 EC2 생성

- TEST VPC와 퍼블릭 서브넷을 생성했습니다. 

- 보안그룹(SSH, HTTP, ICMP 허용)과 EC2를 생성했습니다. 프로토콜별로 목적은 다음과 같습니다.

ㄴSSH: SSH 연결 

ㄴICMP: ping TEST 진행을 위해 ICMP IPv4를 허용하는 인바운드 규칙을 추가.

ping test를 통해 인터넷 연결을 확인했습니다.

 

2. 사용자템플릿

- 네트워크 구성: 각 인스턴스는 Nginx 설치를 위해 인터넷과 연결되어야 합니다. 이를 위해 퍼블릿 IP 자동 할당을 활성화합니다. 또한 스케일 인에 따른 네트워크 인터페이스가 자동 삭제되어야 하므로 자동 삭제도 활성화해줍니다.

- 사용자데이터: amazon linux1에 nginx를 설치할 것이므로, yum install nginx -y를 넣어줍니다.

yum install nginx -y

추가로 Nginx의 기본 파일 경로는 아파치 웹서버(/var/www/html/index.html)가 아닌 /usr/share/nginx/html/index.html로 설정해줍니다.

/usr/share/nginx/html/index.html

 

#스크립트 실행 환경 선언: Bash 쉘 스크립트
#!/bin/bash

#메타데이터를 가져오기 위한 토큰 설정
TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

#실행되는 인스턴스의 가용영역, 인스턴스ID, 사설IP 값을 변수로 지정
RZAZ=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone-id)
IID=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/instance-id)
LIP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/local-ipv4)

#nginx웹서버 설치
yum update -y
yum install nginx -y

#설치된 nginx 실행
systemctl start nginx && systemctl enable nginx

#첫화면 꾸미기..!
echo "<html>
<head><title>Lets go: 꿈나무</title></head>
<body><h1>Ver 4 : RegionAZ($RZAZ) : Instance ID($IID) : PrivateIP($LIP)</h1></body>
</html>" > /usr/share/nginx/html/index.html

 

 

3. 테스트

3.1 로드밸런싱 테스트

- 우선 2개의 가용영역에 정상적으로 트래픽이 분산되고 있는지 확인이 필요합니다. ALB DNS 값을 변수로 선언한 후 해당 주소로 HTTP 요청을 반복해서 보내보겠습니다.

서로 다른 가용영역의 다른 인스턴스로 요청이 정상적으로 보내지는 걸 확인했습니다.

 

3.2 스케일아웃/스케일인 테스트

- CPU 사용률에 따른 오토스케일링 정책을 설정했습니다. 따라서 CPU 사용률에 따라 스케일아웃과 스케일인이 정상적으로 진행되는지 확인이 필요합니다. ASG 검증용으로 만든 EC2에서 아파치벤치를 통해 인위적으로 트래픽을 발생시켜 CPU 사용률을 늘리고 이를 기반으로 스케일아웃이 진행되는지 확인했습니다.

aws automatic scaling 정책 설정

ASG검증용으로 만든 EC2에는 Apache Bench를 설치해줍니다.

이후 ALB DNS로 트래픽을 보내봅니다.

트래픽을 총 60만개 보냈습니다. 트래픽마다 1000번의 호출이 이뤄지도록 명령했습니다.

트래픽을 처리하는 동안 오토스케일링 설정과 함께 cloudwatch 지표를 확인해봅니다.

auto scaling group의 용량 설정
auto scaling group의 scale out 정책 설정
cloud watch 지표

auto scale group에서 CPU 사용률이 10 이상일 경우 스케일아웃이, 5이하일 경우 스케일인이 진행되도록 설정했습니다. cloudwatch의  CPU 사용률 그래프와 GroupInServiceInstances 그래프를 보면 사용률 증감에 따라 서버가 증감하는 것을 확인할 수 있습니다.

 

 

'프로젝트' 카테고리의 다른 글

AWS 3 Tier Architecture 구축  (0) 2024.05.31
3 Tier Architecture  (0) 2024.04.18

헷갈리거나 기억해야할만한 내용이라고 보이는 것만 부분적으로 정리한 내용입니다.

 

 

VPC Gateway

  • Interface Endpoint
    • Elastic Network Interface를 통해 Private IP 할당되면 해당 IP로 Access하는 방식
      • Interface Endpoint가 Private Subnet 내부에 위치함
      • PrivateLink에 대한 요금 발생
        *AWS PrivateLink는 트래픽을 공용 인터넷에 노출시키지 않고 VPC, AWS 서비스 및 온프레미스 네트워크 간의 비공개 연결을 제공합니다. Amazon VPC 엔드포인트를 통해 비공개로 안전하게 서비스에 액세스할 수 있습니다.
    • SQS, SNS, Kenesis, Sagemaker 등 지원
    • VPC 피어링 또는 AWS Transit Gateway를 통해 다른 Region에서 Access 가능
  • Gateway Endpoint
    • VPC 내부에 위치
    • S3, DynamoDB 등 지원
    • 비용 발생하지 않음
    • 다른 Region에서 Access 허용하지 않음

 

S3

  • 버킷 정책
    • 버킷 정책에서 "aws:SecureTransport" 조건을 사용하면 S3 버킷에 대한 모든 연결이 전송 중에 암호화됩니다
    • S3 버킷에 업로드된 모든 객체가 암호화 PutObject에 x-amz-server-side-encryption 헤더 세트가 없는 경우 거부하도록 버킷 정책을 업데이트합니다
    • S3 기본설정이 모든 객체 암호화임
    • S3 버킷 접근 보호를 Cognito로 할 시 적절한 IAM 역할을 맡도록 Amazon Cognito 자격 증명 풀을 업데이트합니다
  • Amazon S3 Glacier:
    • Expedited Retrieval(신속 검색): Provides access to data within 1-5 minutes.
    • Standard Retrieval(표준 검색): Provides access to data within 3-5 hours.
    • Bulk Retrieval(대량 검색): Provides access to data within 5-12 hours.
  • Amazon S3 Glacier Deep Archive:
    • Standard Retrieval(표준 검색): Provides access to data within 12 hours.
    • Bulk Retrieval(대량 검색): Provides access to data within 48 hours.
  • S3 객체 잠금
    • 법적 보존
      • 객체 잠금 법적 보존 작업을 사용하면 객체 버전에 법적 보존을 적용할 수 있습니다.
      • 보존 기간 설정과 마찬가지로 법적 보존은 객체 버전을 덮어쓰거나 삭제하는 것을 방지합니다.
        • 객체를 삭제해야 하는 사용자의 IAM 정책에 s3:PutObjectLegalHold 권한을 추가합니다
      • 그러나 법적 보존에는 관련 보존 기간이 없으며 제거될 때까지 유효합니다
  • OAI, OAC
    • S3에 직접 접근을 막고 인증된 경로로만 접근할 수 있도록 하는 버킷 정책
      • 예) CloudFront를 통한 접근만 허용할 경우, OAI만 읽기 권한을 갖는 S3 버킷권한을 생성 후 CloudFront에 OAI를 할당합니다.

 

EC2

  • 비용 절약
    • EC2 Instance saving plan 
    • 근데 EC2 인스턴스 패밀리 변경 가능한 건 Compute Savings Plans
      *EC2 Instance saving plan은 family 변경 불가
      • Compute Savings Plans에 대한 운영 유연성: 선결제 없음 > 선결제
        • 선결제 없음은 월별 사용량에 대해서만 지불
  • EC2 Auto Scaling
    • 예측 조정: 트래픽 흐름의 일일 및 주간 패턴에 앞서 Auto Scaling 그룹의 EC2 인스턴스 수를 늘립니다. 정기적인 트래픽 증가 패턴이 있는 경우 예측 확장을 사용하면 예측된 로드보다 먼저 용량을 시작하여 더 빠르게 확장할 수 있습니다. 예측 확장은 기계 학습을 사용하여 CloudWatch의 기록 데이터를 기반으로 용량 요구 사항을 예측합니다. 트래픽이 적을 것으로 예상되는 주말에는 예약된 조정을 사용하여 Auto Scaling 그룹 용량을 0으로 변경합니다. 이렇게 하면 사용되지 않는 인스턴스를 종료하여 비용이 최소화됩니다
    • 대상 추적 조정 정책을 사용하여 인스턴스 CPU 사용률을 기반으로 Auto Scaling 그룹을 조정합니다. 이를 통해 Auto Scaling 그룹은 수요에 따라 동적으로 확장 및 축소할 수 있습니다.
    • 임의의 요일에 갑작스러운 트래픽 증가에도 성능 유지해야한다면, 동적 스케일링(예측 불가하므로 예측 조정X)
  • EC2 Auto Scaling lifecycle hooks: 수명 주기 후크를 사용하면 스크립트가 완료될 때까지 인스턴스 종료를 지연
  • 전용인스턴스와 전용 호스트
    • 오라클 같은 서비스는 라이센스가 CPU 단위로 체결 가능. 인스턴스는 가상 CPU다 보니 이걸론 사용에 한계있음. 그럴 때 쓰는 게 전용호스트
    • 전용 테넌시는 다른 고객과 하드웨어 공유 방지하고 내 워크로드 내에서는 하드웨어 공유됨
      • 시험용) "소켓 및 코어"는 "전용 호스트”
    • 분산 배치 그룹: 노드 그룹이 동일한 기본 하드웨어를 공유하지 못하도록 하는 네트워크 아키텍처
      • 각 인스턴스가 격리된 단일 테넌트 하드웨어에서 실행
  • EC2 백업: 스냅샷 생성 후 AMI 생성
    • EC2 백업전략 세우는데 임시 로컬 스토리지가 없다면? 스냅샷 없이 바로 AMI 생성
  • EC2 인스턴스의 취약점을 적극적으로 검사하고 결과를 자세히 설명하는 보고서를 보내는 솔루션 Amazon Inspector를 켜십시오. Amazon Inspector 에이전트를 EC2 인스턴스에 배포합니다. 결과를 자세히 설명하는 보고서의 생성 및 배포를 자동화하도록 AWS Lambda 함수를 구성합니다.
  • EC2 DR 전략은 장애 조치 지역의 용량을 충족해야 한다면? 장애 조치 지역에서 용량 예약을 구매합니다.
  • EC2 인스턴스에서 메모리를 실행하고 로드하는 시간 감축시켜야 한다면? 최대 절전 모드를 활성화한 상태에서 EC2 온디맨드 인스턴스를 시작합니다. 다음 테스트 단계에서 EC2 Auto Scaling 웜 풀을 구성합니다.
    • 최대 절전 모드: EC2 인스턴스의 메모리 내 상태를 영구 스토리지에 저장하고 인스턴스를 종료합니다. 인스턴스가 다시 시작되면 인 메모리 상태가 복원되어 새 인스턴스를 시작하는 것보다 훨씬 빠르게 시작됩니다.
      =EC2 인스턴스를 "사전 준비" 상태로 유지하여 더 빠르게 생산적인 상태로 전환할 수 있습니다.
    • 웜 풀: EC2 시작 시간을 단축

 

Route 53

CASE) 웹사이트를 사용할 수 없는 경우 사용자에게 백업 정적 오류 페이지를 표시

  • Route 53 액티브-패시브 장애 조치 구성을 설정합니다 (ALB를 기본 엔드포인트로 사용하고 Amazon S3 정적 웹 사이트를 패시브 엔드포인트로 사용하여 Route 53 액티브-패시브 장애 조치 구성을 설정)
  • Route 53 상태 확인에서 ALB 엔드포인트가 비정상이라고 판단되면 Amazon S3 버킷에 호스팅되는 정적 오류 페이지로 트래픽을 보냅니다.

CASE) 모든 고객에게 개별적이고 안전한 URL을 제공

  • 등록기관에 필요한 도메인을 등록하세요. Route 53 호스팅 영역에 와일드카드 사용자 지정 도메인 이름을 생성하고 API Gateway 엔드포인트를 가리키는 영역에 기록합니다.
  • 동일한 리전에 있는 AWS Certificate Manager(ACM)의 사용자 지정 도메인 이름과 일치하는 와일드카드 인증서를 요청합니다.
  • API 게이트웨이에서 REST API용 사용자 지정 도메인 이름을 생성합니다. AWS Certificate Manager(ACM)에서 인증서를 가져옵니다.

 

CloudFront

  • Edge Location에 캐싱해두는 개념
  • 동적 IP 주소 집합 사용
  • 프로토콜: HTTP, HTTPS
  • Lambda@Edge
    • CloudFront 네트워크의 엣지에서 실행되는 서버리스 함수입니다.
  • 서명된 URL
    • CloudFront 서명된 URL 또는 서명된 쿠키를 사용하여 특정 사용자(예: 요금을 지불한 사용자)를 대상으로 하는 문서, 비즈니스 데이터, 미디어 스트림 또는 콘텐츠에 대한 액세스를 제한합니다.
  • Amazon CloudFront는 특정 국가의 사용자에 대한 액세스를 거부 가능
    = Amazon CloudFront 지리적 제한, 서명된 URL 활용
  • 데이터 전송 중 보호를 위해선 필드 수준 암호화 필요
    • 전체 애플리케이션 스택에서 보호
    • 방법: CloudFront 필드 수준 암호화 프로필을 구성합니다

 

Global Accelerator

  • TCP/UDP 지연 시간 최소화
  • 항상 성능을 기반으로 사용자 트래픽을 최적의 엔드포인트로 라우팅
  • 장기 약정이나 최소 요금이 필요하지 않은 셀프 서비스 종량제 서비스
  • AWS 글로벌 네트워크 인프라를 통한 트래픽 전송 → 성능 개선
  • 고정IP

 

RDS

  • RDS Proxy
    • 데이터베이스 연결 시간 초과로 인한 애플리케이션 오류를 줄이기 위한 가장 좋은 솔루션은 RDS DB 인스턴스에서 RDS Proxy를 활성화하는 것입니다.
    • 데이터베이스와 설정된 연결을 풀링하고 공유할 수 있어 데이터베이스 효율성과 애플리케이션 확장성이 향상됩니다.
    • RDS Proxy는 연결을 풀링하므로 코드를 변경할 필요가 없습니다.
    • RDS Proxy를 사용하면 Aurora 및 RDS 데이터베이스의 장애 조치 시간이 최대 66% 단축됩니다.
    • 시험용) 데이터베이스 연결 거부 오류 = RDS Proxy
  • RDS 자동백업
    • RDS 자동 백업을 사용하면 지정된 보존 기간(최대 35일) 내의 특정 시점(초 단위까지 가능)으로 데이터베이스를 복구할 수 있습니다
  • RDS Storage  Amazon RDS에서는 범용 SSD(gp2 및 gp3라고도 함), 프로비저닝된 IOPS SSD(io1이라고도 함), 마그네틱(표준이라고도 함) 등 세 가지 스토리지 유형을 제공합니다.
  • RDS 비용을 줄이기 위해 적절한 Trusted Advisor 점검
  • 구매거래 데이터 저장소로는 RDS가 적합
  • 데이터베이스 관리자로부터도 민감한 고객 데이터가 보호되기 위해선 Amazon RDS
    *S3는 관리자 액세스 제한 없음
  • RDS의 재해 복구 솔루션?
    • 24시간마다 자동 스냅샷(전체 DB 인스턴스를 백업)을 다른 리전으로 복사합니다.
  • RDS 이벤트 알림
    • RDS DB 내부 데이터 업데이트로 알림 보내주는 건 없습니다. 따라서 데이터베이스가 업데이트될 때 트리거되는 AWS Lambda 함수를 생성해야 합니다.
  • RDS 암호화
    • RDS 암호화 설정은 인스턴스 생성 시에만 가능(생성 후 불가)
      • 단, 암호화되지 않은 스냅샷 사본은 암호화 가능하기에 암호화되지 않은 RDS 인스턴스 암호화 방법은 최신 DB 스냅샷 사본을 암호화합니다. 암호화된 스냅샷을 복원하여 기존 DB 인스턴스를 교체합니다
    • RDS 암호화 시, 모든 로그, 백업 및 스냅샷 암호화됨
  • 기본 OS에 대한 액세스를 유지하기 위해 Amazon RDS Custom으로 마이그레이션
  • RDS 시작 중지
    • AWS Lambda 함수를 사용
      • AWS Lambda 함수를 사용하면 RDS 인스턴스를 프로그래밍 방식으로 시작하고 중지할 수 있습니다.
    • EventBridge 예약 규칙으로 Lambda 트리거
      • EventBridge 예약 규칙은 매일 지정된 시간에 Lambda 함수를 트리거할 수 있습니다.
    • 이를 통해 사용 패턴에 맞춰 일정에 따라 RDS 시작 및 중지를 완전히 자동화할 수 있습니다.
    • RDS 청구는 인스턴스가 실행 중일 때 시간당 청구되므로 사용하지 않을 때 중지하면 비용이 크게 절감됩니다.

 

Aurora

  • 다른 회사에 Aurora 백업 안전하게 공유하기
    • 데이터베이스 스냅샷을 생성합니다. KMS 키 정책에 다른 회사의 AWS 계정을 추가합니다. 다른 회사의 AWS 계정과 스냅샷을 공유합니다
  • RDS 복제지연 해결
    • 데이터베이스를 Amazon Aurora로 마이그레이션합니다. 읽기 전용 복제본을 Aurora 복제본으로 교체하고 Aurora Auto Scaling을 구성합니다. 저장 프로시저를 Aurora 기본 함수로 바꿉니다. 애플리케이션 코드를 크게 변경하지 않고도 복제 지연을 줄이고 지속적인 운영 오버헤드를 최소화하는 데 가장 적합한 솔루션입니다. 데이터베이스를 Amazon Aurora로 마이그레이션하면 Amazon RDS에 비해 복제 성능이 향상되고 확장성이 높아집니다
  • MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진

 

Aurora serverless

  • MySQL용 Aurora Serverless를 사용하면 애플리케이션의 요구 사항에 따라 서비스가 자동으로 확장되거나 축소되므로 특정 인스턴스 유형을 선택할 필요가 없습니다.
  • 실제 사용량을 기준으로 컴퓨팅 용량을 자동으로 확장하고 사용하지 않을 때는 0까지 줄입니다.
    → 이는 간헐적인 사용에 따른 비용을 최소화합니다 (데이터베이스가 활성화되면 초당 요금을 청구)
    *RDS: 시간당 요금을 청구

 

DynamoDB

  • NoSQL "단일 이미지 또는 행" 또는 "단일 키-값 쌍이 있는 하나의 간단한 테이블"
  • 모드
    • 온디맨드모드와 프로비저닝된 모드 지원
      • 프로비저닝된 모드는 RCU와 WCU를 지정하는 방식이다.
        *RCU/WCU=Read/Write Capacity Units
  • 연속 백업
    • DynamoDB의 기본 기능
    • 서버나 클러스터를 관리할 필요 없이 모든 규모에서 작동
    • AWS 리전 및 계정 전체에서 지난 35일 중 원하는 시점으로 초당 단위로 데이터를 내보낼 수 있습니다.
    • 읽기 용량이나 프로덕션 테이블의 가용성에는 영향을 미치지 않습니다.
  • DynamoDB 응답 시간을 밀리초에서 마이크로초로 개선하고 데이터베이스에 대한 요청을 캐시하기 위해 = DynamoDB Accelerator(DAX)
  • TTL속성은 불필요한 데이터 지우는 용도
    • 추가 비용 발생하지 않음
    • 특정 기간 지난 데이터 지우는 용도

 

Elasticache

  • 잦은 데이터 세트 반환 요청 또는 호출 ->캐싱으로 해결:Amazon ElastiCache를 구현하여 대규모 데이터 세트를 캐시합니다
  • 실시간 게임 순위표를 쉽게 만들 수 있습니다. 점수별로 정렬된 목록을 유지하면서 요소의 고유성을 제공하는 Redis Sorted Set 데이터 구조를 사용하면 됩니다.
  • 캐싱전략
    • 연속 쓰기 캐싱 전략 - 데이터베이스와 캐시 실시간 동기화
    • 지연 로드 캐싱 전략 - 데이터 요청 시에만 데이터베이스 데이터 가져옴
    • TTL(Time-to-Live) 캐싱 전략 - 만료기간이 있어 데이터가 특정 기간 동안 유효한 것으로 간주
    • AWS AppConfig 캐싱 전략 - 애플리케이션 구성을 배포하고 관리하는 데 도움
  • 세션관리 최적화 목적으로 세션 지속적으로 저장: Elaticache와 ALB 고정세션기능(세션선호도) 활성화
    *Elasticache는 복제지연문제를 해결하지 않음
    • 시험용) 세션 분산 저장 or 코드 변경 허용 → Elasticache
    • 시험용)  세션 정보 단일 인스턴스 저장 or 코드 변경 허용하지 않을 경우 → ALB 세션 선호도(고정 세션)
  • Memcached는 Redis보다 더 나은 성능과 단순성을 제공하지만 가용성은 낮습니다

 

Lambda

  • 함수 URL은 Lambda 함수에 대한 전용 HTTP(S) 엔드포인트입니다.
    =함수 URL을 생성하면 Lambda가 자동으로 고유한 URL 엔드포인트를 생성합니다.
    =함수 URL을 사용하면 Lambda 함수에 대한 직접 호출 엔드포인트가 제공됩니다.
    =추가적인 인프라 없이도 신속하게 함수 URL을 생성하여 제3자에게 제공할 수 있습니다.
  • Lambda SnapStart와 프로비저닝된 동시성 모두 함수 확장 시 콜드 스타트와 이상치 지연 시간을 줄일 수 있습니다.
    • SnapStart를 사용하면 추가 비용 없이 시작 성능을 최대 10배까지 향상시킬 수 있습니다.
    • 엄격한 콜드 스타트 대기 시간 요구 사항이 있는 경우 프로비저닝된 동시성을 사용합니다(요금 발생)

 

AWS Storage Gateway

  • 클라우드 스토리지에 대한 온프레미스 액세스 권한을 제공하는 하이브리드 클라우드 스토리지 서비스
    • 온프레미스 애플리케이션을 클라우드 스토리지에 원활하게 연결
    • 대기 시간이 짧은 액세스를 위해 로컬 위치에 데이터를 캐싱 (로컬 캐싱)
  • 유형: Tape Gateway, Amazon S3 File Gateway, Amazon FSx File Gateway, Volume Gateway
    • Amazon S3 File Gateway
      • NFS 및 SMB 파일 프로토콜 사용
      • SMB 파일 공유 사용자 작업에 대한 감사 로그를 Amazon CloudWatch에 게시
      • 온프레미스 파일 데이터를 Amazon S3의 객체로 저장 가능
    • Amazon FSx File Gateway
      • 업계 표준 SMB 프로토콜을 사용 액세스 가능
      • 완벽한 NTFS 지원, 섀도 복사본 및 액세스 제어 목록(ACL)과 같은 Windows 기본 호환성을 통해 Amazon FSx에서 파일 데이터를 저장하고 액세스
    • Tape Gateway
      • ISCSI 기반 가상 테이프 드라이브와 가상 미디어 체인저로 구성된 가상 테이프 라이브러리(VTL)를 온프레미스 백업 애플리케이션에 제공
      • S3에 가상 테이프를 저장하고 새 테이프를 자동으로 생성하여 관리와 AWS로의 전환 간소화
      • VTL 인터페이스 → 물리적 테이프 인프라 자본에 드는 지출, 수년간의 유지 관리 계약 및 지속적인 미디어 비용을 절감 가능
      • 페타바이트 규모의 테이프 데이터 마이그레이션 요구 사항과 관련하여 Tape Gateway와 함께 Snowball Edge Storage Optimized 디바이스를 사용하여 물리적 테이프 데이터를 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive로 마이그레이션하여 추가적으로 장기 스토리지 비용을 줄일 수 있습니다
    • Volume Gateway
      • ISCSI 프로토콜을 사용하는 블록 스토리지 볼륨을 제공
      • 볼륨의 특정 시점 스냅샷으로 비동기식으로 백업되고 Amazon EBS 스냅샷으로 클라우드에 저장 가능
        • 스냅샷은 변경된 블록만 캡처하는 증분 백업
        • 스냅샷 스토리지는 압축되어 스토리지 비용을 최소화
        • EBS 스냅샷 또는 캐시된 볼륨 복제를 기반으로 한 재해 복구에 사용

 

 

기타 서비스

  • AWS Lake Formation
    • S3 data lake 관리 가능
    • Database 특정 열만 액세스 허용하도록 하여 열 수준 액세스 제어 가능하도록 합니다.
  • API Gateway
    • 사용량 계획
      • API Gateway 사용량 계획을 사용하여 API를 고객을 위한 제품 혜택으로 제공할 수 있습니다. 고객이 선택한 API에 액세스할 수 있도록 사용 계획 및 API 키를 구성하고 정의된 제한 및 할당량에 따라 해당 API에 대한 요청 제한을 시작할 수 있습니다.(e.g. 프리미엄 고객 전용 콘텐츠 제공)
      • 사용량 계획이 있는 API 키는 승인된 앱과 사용자에게만 액세스를 제한합니다.
    • API Gateway 보호 → WAF
      • Region AWS WAF 웹 ACL을 생성합니다. 웹 ACL을 API 게이트웨이 단계와 연결합니다
  • Amazon AppFlow
    • 다양한 SaaS 애플리케이션과 AWS 서비스 간에 데이터를 안전하게 전송할 수 있는 완전관리형 통합 서비스입니다.
    • 내장된 암호화 옵션을 제공하고 SSL/TLS 프로토콜을 사용하여 전송 중 암호화를 지원합니다.
    • AppFlow를 사용하면 Salesforce에서 Amazon S3로의 데이터 전송 흐름을 구성하여 AWS KMS CMK를 활용하여 저장 데이터 암호화를 보장할 수 있습니다.
  • EMR
    • (대용량 데이터 + 병렬 데이터 처리)용
      • 대규모 데이터 세트를 처리하는 데 최적화된 관리형 Hadoop 프레임워크
      • 병렬 데이터 처리를 지원
      • Redshift와 통합 가능
      • Amazon S3에서 반구조화된 데이터를 처리 가능
  • Canary 릴리스 배포
    • 새 API 버전을 일정 비율의 트래픽으로 점진적으로 출시할 수 있습니다. 이는 릴리스 중 고객에게 미치는 영향과 잠재적인 데이터 손실을 최소화합니다.
    • 시험용) 고객에게 미치는 영향 최소화 및 데이터 손실 최소화 = Canary 배포
  • 인프라 취약성 관리 = Inspector
  • PII 식별 = Macie
    *불필요한 모든 리전에서 활성화하는 대신 필요한 리전에서 직접 활성화할 수 있습니다.
  • Build a web application = AWS Amplify
  • Sign in users = Amazon Cognito user pool (사용자풀 O / 자격증명 X)
  • 파일에서 텍스트를 추출하는 Textract
  • 텍스트에서 의료정보 감지 및 추출하는 Amazon Comprehend Medical
  • 여러 화자를 인식하려면 Amazon Transcribe를 사용하십시오
    • 음성 언어를 서면 텍스트로 자동 변환하는 서비스
  • 마케팅 커뮤니케이션 = Amazon Pinpoint
  • EKS
    • Amazon EKS가 워크로드에 따라 확장 및 축소
      • Kubernetes Metrics Server를 사용하여 수평형 포드 자동 크기 조정을 활성화합니다
        → 워크로드 수요에 따라 EKS 클러스터 및 컨테이너 애플리케이션의 자동 크기 조정
      • Kubernetes Cluster Autoscaler를 사용하여 클러스터의 노드 수를 관리합니다
    • EKS 클러스터와 온프레미스 Kubernetes 클러스터를 중앙에서 한번에 보고 싶을 때
      → Amazon EKS 커넥터를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
  • Organizations에서 OU 계층 구조의 변경사항 식별 → AWS Control Tower를 사용하여 AWS 계정을 프로비저닝합니다. 계정 드리프트 알림을 사용하여 OU 계층 구조의 변경 사항을 식별하세요.
  • AWS Control Tower
    • 인터넷 접속 차단, 외부 리전 접근 제어
    • data residency guardrails를 사용하여 인터넷 접속을 차단할 수 있습니다.
    • 특정 리전을 제외한 모든 리전에 대한 액세스를 거부할 수 있습니다.
  • EventBridge는 일치하는 이벤트 수부터 규칙에 의해 대상이 호출되는 횟수까지 모든 항목에 대해 매분마다 Amazon CloudWatch에 지표를 보냅니다 "AWS/Events" 네임스페이스에서 관련 지표를 찾을 수 있으며, 이를 통해 규칙과 일치하는 이벤트 수와 규칙 대상에 대한 호출 수를 모니터링할 수 있습니다.
  • 사용량을 기반으로 비용을 최적화 → AWS의 인스턴스 스케줄러를 사용하여 시작 및 중지 일정을 구성하십시오.
    • 인스턴스 스케줄러는 Amazon Elastic Compute Cloud(Amazon EC2) 및 Amazon Relational Database Service(Amazon RDS) 인스턴스의 시작 및 중지를 자동화
  • AWS Outposts 사용 시 사용자의 담당 사항
    • Outposts 랙에 탄력적인 전원 및 네트워크 연결 제공
    • 데이터센터 환경의 물리적 보안 및 접근통제
    • 서버 오류 및 유지 관리 이벤트를 완화하기 위해 Amazon ECS 클러스터에 추가 용량 제공
      • Outpost 용량은 유한하고 AWS가 사이트에 설치하는 랙의 크기와 수에 따라 결정되므로 초기 워크로드를 실행하고 향후 성장을 수용하며 추가 제공을 위해 필요한 Outposts 용량의 EC2, EBS 및 S3 용량을 결정해야 합니다.
  • Opensearch
    • 로그를 Amazon OpenSearch Service(Amazon Elasticsearch Service)로 스트리밍하도록 CloudWatch Logs 구독을 구성하면 새로운 정책에 따라 회사는 거의 실시간으로 Amazon OpenSearch Service(Amazon Elasticsearch Service)에 모든 애플리케이션 로그를 저장함
  • 셀프 서비스 목적으로 사용할 수 있는 공통 솔루션 및 도구 세트를 중앙에서 관리하고 배포해야 합니다. 》AWS Service Catalog 제품
  • AWS Config는 리소스 구성을 지속적으로 평가하고 태그가 지정되지 않은 리소스를 식별할 수 있습니다
  • CloudFormation은 IaC(Infrastructure as Code)
    • 인프라를 즉시 배포할 수 있는 기능 
    • 시험용) 코드형인프라 = CloudFormation

 

보안 업무 관련

  • 다른 인터넷 트래픽은 차단하고 타사 소프트웨어 저장소에만 액세스 가능할 경우
    • 아웃바운드 트래픽을 AWS 네트워크 방화벽으로 라우팅하도록 프라이빗 서브넷의 라우팅 테이블을 업데이트합니다. 도메인 목록 규칙 그룹을 구성합니다 특정 도메인을 허용하고 다른 모든 도메인을 거부하는 상태 저장 아웃바운드 규칙 *보안 그룹의 아웃바운드 규칙에는 URL을 사용할 수 없습니다
  • VPC 보안
    • Network ACL → 서브넷 앞에 위치 → 서브넷 트래픽 제어
      • Subnet의 Access List 제어(Subnet 검문서)
      • 인바운드, 아웃바운드 규칙으로 나뉨
      • NACL→ 여러 서브넷 적용 가능. 그러나 서브넷에 여러 NACL 적용은 불가능(1개만 가능)
      • 허용(Allow) 규칙, 거부(Deny) 규칙 생성 가능
      • 규칙 우선순위 설정 가능(가장 적은 숫자가 우선 적용) → 최우선 규칙만 통과하면 통과(그 다음 규칙은 무시됨)
      • NACL 규칙목록은 인바운드, 아웃바운드 각각 최대 20개 지정 가능
      • Stateless: 서브넷 안으로 들어올 땐 인바운드 규칙, 나갈 땐 아웃바운드 규칙 적용됨
  • Security Group → 서브넷 안에 위치 → 서브넷 안 인스턴스 등 가상컴퓨터 트래픽 제어
    • 정확히 말하면 VPC 내에서 Elastic Network Interface(ENI)를 갖는 모든 서비스에 Security 탑재 가능
    • 인스턴스 단위로 설정 가능
      • 하나의 인스턴스에서 최대 5개 Security Group 동시 적용 가능 → Security Group 모든 룰 적용됨
      • 각 인스턴스에 각각 다른 Security Group 할당 가능
    • 인바운드, 아웃바운드 규칙으로 나뉨
      • 기본적으로 모든 아웃바운드 규칙은 허용
    • 프로토콜 유형, 포트, IP 단위로 설정 가능
    • 허용 규칙만 생성 가능(Deny 불가능)
    • Stateful: 허용받아서 들어온 놈은 아웃바운드 규칙과 상관없이 나갈 수 있다
  • WAF
    • 봇 식별 및 교정 도구가 있어 봇넷의 사기성 요청으로 인해 애플리케이션 트래픽이 급증 방어 가능
    • 트래픽 제어 기능
    • WAF는 Cloudfront 배포와 연결되어 있습니다
      =Amazon CloudFront 배포에서 AWS WAF를 활성화합니다.
    • 국가 단위 제어 가능
      • AWS WAF를 사용하여 최종 사용자의 지리적 위치에 따라 애플리케이션 액세스를 제한할 수 있습니다. 지역 일치 조건을 사용하면 AWS WAF에서 액세스를 허용해야 하는 국가를 선택할 수 있습니다
  • Network Firewall
    • VPC 간 트래픽 검사
    • URL 필터링

 

결제 및 비용 업무 관련

  • 각 계정에서 정의된 태그를 기반으로 비용 통합 조회할 경우
    • 조직 마스터 계정에서 각 계정별로 정의된 태그를 활성화
    • AWS 결제 콘솔에서 특정 사용자 정의 태그를 선택
  • 프로그래밍 방식으로 사용 비용에 액세스할 경우
    • 페이지 매김 기능이 있는 AWS Cost Explorer API를 사용하여 사용량 비용 관련 데이터에 액세스합니다.

 

계정 관리 업무 관련

  • 조직의 계정 바꾸기
    • 계정은 일단 조직을 떠나야 다른 조직에 가입할 수 있습니다
      1. 이전 조직에서 회원 계정을 제거합니다.
      2. 새 조직의 회원 계정으로 초대를 보냅니다.
      3. 회원 계정에서 새 조직에 대한 초대를 수락합니다.

 

컨테이너에 포함된 Microservice로 라우팅

  • ALB와 API 게이트웨이 모두 트래픽을 컨테이너에 포함된 마이크로서비스로 라우팅하는 데 사용할 수 있다
    • Application Load Balancer가 실행되는 각 시간 또는 부분 시간과 시간당 사용된 로드 밸런서 용량 단위(LCU) 수에 대해 요금이 부과됩니다.
    • Amazon API Gateway에서는 API를 사용할 때마다 비용을 지불합니다(API 호출당 비용)

로드밸런싱: 트래픽 분산 처리

AWS의 로드 밸런싱 서비스: ELB(Elastic Load Balancing)

"트래픽을 ELB가 받아 다수의 대상으로 로드 밸런싱하여 전달"


ELB 구성요소

  • 로드 밸런서
    • 트래픽 분산하는 애
    • Client 요청을 받아 대상 그룹(여러 EC2 인스턴스나 IP주소, 람다 등)에 전달하거나, 대상 그룹이 응답한 정보를 Client에게 반환함
    • ELB 생성하면 가용 영역별로 로드 밸런서 노드가 가용영역 안에 생성됨
  • 대상 그룹
    • 로드 밸런서가 분산할 대상의 집합
    • 로드 밸런서는 라우팅 규칙에 따라 대상 그룹 내 Client의 요청을 받을 애를 선택함
    • 정기 점검으로 대상그룹의 건강상태를 체크하고, 정상 작동하는 애한테만 트래픽(Client 요청) 전달함
      • Health Check: 건강상태 체크
      • Monitoring: 처리 가능한 애 감독
  • 리스너
    • 로드 밸런서에서 사용할 포트와 프로토콜 설정하는 구성 요소
    • 로드 밸런서에 연결된 프로토콜과 포트를 기반으로 요청을 검사하고 적절한 요청만 골라 대상 그룹에 전달하는 역할 수행
    • 로드밸런서당 최소 1개에서 최대 10개 가능
    • 대상 그룹의 라우팅 정의
    • 리스너 규칙(Rule)
      • 트래픽 분배를 위한 라우팅 규칙
      • 규칙과 규칙 충족했을 경우 수행할 액션 정의

트래픽 흐름도

1) Client가 ELB 도메인 주소로 요청 전달

2) 도메인 해석 후 알맞는 가용 영역의 로드 밸런서 노드로 트래픽 전달

3) 로드밸런서가 대상 그룹 중 선택하여 요청 전달

4) 역순으로 Client에게 응답 반환


불균형 로드 밸런싱 문제

  • 교차 영역 로드 밸런싱 없을 경우, 가용영역 간 트래픽 분산 비중이 동일. 이로 인해 가용영역 내 대상 그룹의 크기가 다를 경우 부하 불균형 문제 발생
    • 예를 들어, A 가용영역에 트래픽 100, B 가용영역에 트래픽 100
    • A 가용영역에 인스턴스 개수는 10인대, B 가용영역에 인스턴스 개수는 40이라면?
    • A 가용영역의 인스턴스 당 부하는 10이지만 B 가용영역의 인스턴스 당 부하는 2.5
  • 교차 영역 로드 밸런싱 있을 경우,  대상 그룹 크기에 맞게 트래픽 분산
    • 그렇게 되면, A 가용영역, B 가용영역 인스턴스 부하가 4
  • ALB에는 활성화 기본이지만 NLB에선 비활성화
  • 교차 영역 로드 밸런싱 사용 시 가용 영역 간 통신 비용 발생

ELB 종류

  • CLB
    • 현재 레거시 서비스로 분류됨
    • 서버 주소 변경 시 새로 생성 필요
    • 포트나 헤더 같은 데이터 수정 불가
  • ALB
    • L7 로드 밸런서
      • HTTP/HTTPS 프로토콜 지원
      • HTTP 헤더 정보 기반 라우팅  기능 제공
        • URL 경로 기반 요청 분산, 호스트 이름 기반 요청 분산, URL 쿼리 문자열 기반 요청 분산
    • IP주소가 항상 변동되기에 Client는 ELB의 DNS Name를 이용
    • 대상 그룹 상태 검사 및 문제 발생 시 장애 조치
    • 대상 그룹 유형: IP, 인스턴스, Lambda, 컨테이너 등
    • 모니터링
      • CloudWatch → 트래픽이 ELB 통과 시 시스템 정상 작동 측정
        • 정상 범위 이탈 시 이메일 알림 보내기 가능
      • 액세스 로그 → Load Balancer에 보낸 요청 캡처 및 S3 저장 가능
      • 요청 추적 → HTTP 요청 추적 가능
      • CloudTrail → ELB API에 대한 요청 정보 캡처 및 S3 저장 가능
    • 보안그룹 사용
    • 주로 웹 애플리케이션을 위한 로드밸런서로 사용
    • SSL 인증서 게시하여 SSL Offload 실시 가능
      • 개별 인스턴스에서 SSL 증명서 설정할 필요 없고 ELB에서만 관리하여 운영 부담 감소
      • 통신 암호화/복호화를 개별 인스턴스에서 수행할 필요 없어 부하 감소
    • Public Subnet에 위치해야함
  • NLB
    • L4 로드 밸런서
      • TCP/UDP/TLS 프로토콜 지원
    • 대규모 트래픽 처리
      • 높은 처리량: 초당 수백만 개 연결 처리
      • 빠른 응답
      • 높은 가용성
    • Elastic IP를 Static IP로 사용해 Client는 고정된 IP 주소를 사용해도 되고, DNS Name을 사용해도 됨
    • 대상 그룹 유형: IP, 인스턴스, ALB, Lambda, 컨테이너
    • 모니터링
      • CloudWatch → 트래픽이 ELB 통과 시 시스템 정상 작동 측정
        • 정상 범위 이탈 시 이메일 알림 보내기 가능
      • VPC 흐름 로그 → VPC 출입 트래픽 정보 캡처
      • 액세스 로그 → Load Balancer에 보낸 TLS 요청 캡처 및 S3 저장 가능
      • CloudTrail → ELB API에 대한 요청 정보 캡처 및 S3 저장 가능
      •  
    • 보안그룹 사용
    • 주로 게임서버, VoIP 서비스, 미디어 스트리밍 등으로 사용
  • GWLB
    • 네트워크 트래픽을 서드파티의 방화벽/어플라이언스 장비로 부하분산 처리하는 로드 밸런서
    • 인스턴스로 트래픽 보내기 전에 트래픽 검사/분석/인증/로깅하는 작업 수행

 

출처

 

Application Load Balancer 모니터링 - Elastic Load Balancing

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

Network Load Balancer 모니터링 - Elastic Load Balancing

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

☁️ ELB(Elastic Load Balancer) 구성 & 사용법 가이드

ELB (Elastic Load Balancer) 이란 ELB(Elastic Load Balancer)란 애플리케이션 트래픽을 여러 대상에 자동으로 분산시켜 안정적인 AWS서버 환경을 운용하는데에 도움을 주는 서비스다. EC2뿐만 아니라 컨테이너(

inpa.tistory.com

책) 길벗출판사 『AWS 교과서』

'AWS' 카테고리의 다른 글

AWS C03 합격 기록  (0) 2024.02.09
SAA-C03 시험용 정리  (1) 2024.02.09
AWS 데이터베이스 서비스(Amazon RDS, Aurora, DynamoDB, Elasticache)  (0) 2024.01.06
EBS Volume 유형  (0) 2023.12.30
AWS Glue  (0) 2023.12.29

AWS Storage Service에는 S3, EFS, FSx, EBS, File Cache가 있다.

 

EBS는 EC2의 하드 드라이브처럼 써먹을려고 설계된 저장소이다.

 

EC2 Instanc와 EBS Volume 둘은 네트워크로 연결된다. 그래서 EC2 Instance 정지 후 재가동해도 문제 없다.

다만, EC2 Instanc와 EBS Volume 둘은 동일한 가용영역(AZ)에 위치해야한다.

EC2 Instance와 EBS Volume은 1:N으로 연결할 수도 있고 또 N:1(다중연결, Multi-Attach)로 연결할 수도 있다

  • EC2 Instance : EBS Volume = 1 : N
  • EC2 Instance : EBS Volume = N : 1 (프로비저닝된 IOPS SSD 한정)

 


 

EBS Volume은 크게 SSDHDD 그리고 Magnetic으로 나뉜다.

  • SSD(Solid State Drive) Volume범용 SSD Volume프로비저닝된 IOPS SSD Volume 유형으로 나뉜다.
    • 범용 SSD Volume은 부트 볼륨, 중간 규모의 단일 Instance Database, 개발 및 테스트 환경을 위한 저장소로 적합하다
      • 범용 SSD(Solid State Drive) Volume은  또 gp3와 gp2로 나뉜다.
    • 프로비저닝된 IOPS SSD Volume은 일관된 *IOPS 속도와 짧은  지연 시간 성능을 갖춘 스토리지이다.
      • I/O 집약적 워크로드 요구사항을 충족하도록 설계됐다.
      • 예측 가능한 방식으로 Instance 당 수만 IOPS까지 확장할 수도 있다.
      • 프로비저닝된 IOPS SSD Volume은 또 io2 Block Express와 io1으로 나뉘는데 io2 Block Express 같은 경우 최고 수준의 Volume 내구성을 제공한다.
  • HDD(Hard Disk Drive)처리량 최적화 HDD Volume(st1)콜드 HDD Volume(sc2) 유형으로 나뉜다. 
    • HDD는 대규모 워크로드에 최적화되어 있는 마그네틱 스토리지이다(속도(IOPS) < 양(처리량))
    • 처리량 최적화 HDD Volume(st1)은 Amazon EMR, ETL, 데이터 웨어하우스, 로그 처리 같은 대용량 순차 워크로드에 적합하다
    • 쓰루풋이 중요한 애플리케이션이나 Hdoop, OLAP Database 등에도 적합하다
      • 저비용 마그네틱 스토리지이다.
    • 콜드 HDD Volume(sc2)는 순차적인 대용량 **콜드 데이터 워크로드에 적합하다
      • 데이터에 자주 액세스할 필요 없고 비용 절약을 원한다면 저렴한 블록 스토리지로 적합하다
  • Magnetic Volume 유형
    • 데이터 액세스 빈도가 낮거나 성능 일관성이 중요치 않은 작은 규모 데이터세트 워크로드에 사용하는 유형이다.
    • 이전 세대 볼륨이라 한다. 처리량 최적화 HDD Volume(st1)과 콜드 HDD Volume(sc2)가 마그네틱 스토리지인데 아마 이 스토리지의 전 세대가 Magnetic Volume유형 아닐까 싶다.

 


 

*IOPS란?

  • Input/Output Operations Per Second의 약자
  • 일반적으로 불륨 크기가 클수록 IOPS 성능이 올라간다

 

**콜드 데이터?

  • 활발히 사용되는 데이터 → 핫(hot) 데이터
  • 일정 기간 동안만 자주 액세스되는 데이터 → 웜(warm) 데이터
  • 자주 액세스되지 않거나 전혀 액세스가 없는 데이터, 비활성 데이터 → 콜드(cold) 데이터

 

 


출처

 

Amazon EBS 볼륨 - Amazon Elastic Compute Cloud

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

Amazon EBS 볼륨 유형 - Amazon Elastic Compute Cloud

마그네틱은 이전 세대 볼륨 유형입니다. 이전 세대 볼륨이 제공할 수 있는 것보다 더 높은 성능 또는 성능 일관성이 필요한 경우 최신 볼륨 유형 중 하나를 사용하는 것이 좋습니다.

docs.aws.amazon.com

 

Amazon EBS 이전 세대 볼륨 – Amazon Web Services

EBS 마그네틱 볼륨은 하드 디스크 드라이브(HDD)에서 지원하며, 데이터에 대한 액세스 빈도가 낮거나 성능 일관성이 별로 중요하지 않은 작은 규모의 데이터 세트의 워크로드에 사용할 수 있습니

aws.amazon.com

 

[기고] 최적의 콜드 스토리지 전략을 위해 고려해야 할 사항

많은 기업들이 데이터의 가치를 디지털 혁신의 수단으로 인식하고 있다. 데이터는 가치를 구현하고, 새로운 수익원을 창출하며, 전략적 방향을 제시하는 핵심적인 수단이다. 그러나...

zdnet.co.kr

 

가비아: 국내 1위

 

customer.gabia.com

 

https://docs.aws.amazon.com/ko_kr/glue/latest/dg/components-key-concepts.html

AWS Glue는 ETL 워크플로를 생성 및 관리할 수 있는 서비스이다

 

ETL이란 데이터를 Extract(추출) → Transform(변환) → Load(적재)하는 작업을 의미한다.

 

AWS Glue는 Crawler 정의를 통해 ETL 작업을 정의한다.

이때 필수 메타데이터에 대한 정의도 포함해서 ETL 작업 정의한다

 

AWS Glue는 Script 생성을 통해 Transform 및 Load 작업을 진행한다

Script는 시간 기반 스케줄 또는 이벤트 기반으로 진행되도록 할 수 있다.

Script는 Apache Spark 환경에서 실행된다.

 

AWS Glue는 데이터 재처리를 방지하기 위해 작업 북마크를 사용한다.

작업 북마크는 데이터의 작업 상태를 나타낸다.

 

AWS Glue는 ETL 작업을 실행하는 데 사용된 작업자 수에 따라 시간당 요금이 발생한다.

Glue를 시작하거나 종료하는데 소용된 시간에 대해선 과금하지 않는다

작업자란 데이터 처리 단위(DPU)를 의미한다.

택시 리터기 생각하면 될 것 같다. 택시는 거리에 따라 금액이 달라지지만, 시간대에 따라 거리당 금액이 달라진다.

마찬가지로 Glue도 ETL에 소요된 시간만큼 비용이 발생하지만 ETL에서의 데이터 처리하는 단위가 클수록 시간당 요금이 커지는 구조라 생각하면 되지 않을까 싶다.

 


출처

 

AWS Glue 개념 - AWS Glue

AWS Glue에 있는 테이블과 데이터베이스는 AWS Glue Data Catalog의 객체입니다. 이 객체들은 메타데이터를 포함하지만 데이터 스토어의 데이터는 포함하지 않습니다.

docs.aws.amazon.com

 

S3 버전관리

  • 동일 버킷 내에 여러개의 객체 변형을 보유하는 수단
  • 버킷 소융자를 포함해 승인받은 모든 사용자는 버전 관리 사용 가능
  • 버킷 내 모든 버전의 객체를 보존, 검색 및 복원 가능
  • 객체 복원 원리
    • 객체 삭제 시 S3에서 영구 제거하는 것이 아닌 해당 객체에 삭제 마커를 삽입하기에 복원 가능
    • 객체를 덮어쓴 경우 버킷에 새 객체 버전이 생기는 것이기에 복원 가능

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/versioning-workflows.html

  • 기본적으로 S3 버전관리는 미사용 상태
    • 버킷 버전관리 상태: 미사용(default), 사용, 일시 중지
    • "사용 → 미사용" 불가
    • "사용 → 일시중지" 가능
  • 버전관리 기능은 버킷 전체에 적용됨(일부 객체에만 적용 불가)이
  • 버전 사용 설정 후부턴 모든 객체에게 고유한 버전ID 부여
    → 수정될 때마다 고유한 버전 ID 부여됨
  • 수명 주기 관리와 연동 가능 → 일정 주기로 특정 버전만 옮기기 가능
  • 비용은 모든 버전에 대해 발생함
    • 1TB 객체 버전 3개 있다면, 총 3TB에 대해 비용 발생

MFA Delete

  • MFA란 Multi-Factor Authentication
  • S3 버전관리 사용 시 설정 가능
  • 버킷 소유자만 사용 설정 가능
  • MFA Delete 활성화 → 버킷 소융자가 버전 삭제 또는 버전관리 상태를 변경하는 경우 추가 인증 필수
    • 보안 자격 증명
    • 승인된 인증 디바이스에 표시된 유효한 일련번호, 공백, 6자리 코드 연결

S3 Object Lock

  • S3 버전관리 사용 시 설정 가능
  • write-once-read-many(WORM) 모델을 사용하여 객체 저장 가능
    → 특정 기한 또는 무기한 객체 삭제 또는 덮어쓰기 방지 가능
  • 객체 보관 방법 2종류: 보관 기간(Retention Mode), 법적 보존(Legal Hold)
    • 보관 기간(Retention Mode) : 일정 기간 WORM으로 보호받음
      • 규정 준수 모드: 루트 유저 포함 누구도 잠금 설정 및 삭제 불가
      • 거버넌스 모드: 권한있는 자만 삭제 혹은 잠금 설정 가능(이외 불가)
    • 법적 보존 (Legal Hold) : 만료날짜가 없고 명시적으로 제거할 때까지 유지됨
      • Hold라는 딱지가 붙어있으면 기한 없이 삭제/수정 불가

 

AWS-SAA_C03_V18.35_Q44

Mission

  • 중요 데이터가 포함된 S3 버킷
  • 데이터의 우발적 삭제 보호 조치 필요

Action

  • S3 버킷의 버전 관리 활성화
  • S3 버킷의 MFA 삭제 활성화

AWS-SAA_C03_V18.35_Q53

Mission

  • 회사는 S3에 회계 기록을 저장해야 함
    • 기록은 1년 동안 즉시 액세스 가능해야함
    • 그 후 추가로 9년 동안 보관해야함
  • 관리자를 포함해 어느 누구도 10년 동안 기록 삭제 불가
  • 기록은 최대한의 복원력으로 저장해야함

Action

  • S3 수명 주기 정책으로 1년은 S3 Standard에서, 이후 9년은 S3 Glacier Deep Archive로 전환
  • 10년 동안 S3 Object Lock 사용

출처

 

S3 버킷에서 버전 관리 사용 - Amazon Simple Storage Service

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

S3 버전 관리 작동 방식 - Amazon Simple Storage Service

버킷에서 버전 관리를 처음으로 활성화할 때 변경 사항이 완전히 전파되는 데 시간이 조금 걸릴 수 있습니다. 버전 관리를 활성화하고 나서 15분 정도 기다린 후, 버킷의 객체에 대해 쓰기 작업(P

docs.aws.amazon.com

 

S3 객체 잠금 사용 - Amazon Simple Storage Service

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

MFA Delete 구성 - Amazon Simple Storage Service

이 페이지에 작업이 필요하다는 점을 알려 주셔서 감사합니다. 실망시켜 드려 죄송합니다. 잠깐 시간을 내어 설명서를 향상시킬 수 있는 방법에 대해 말씀해 주십시오.

docs.aws.amazon.com

 

AWS의 네트워크 및 애플리케이션 보호 서비스

  • 호스트 수준의 보호와 조직 전반의 가시성 및 제어: Amazon VPC Security Group, AWS Firewall Mananger
  • 애플리케이션 수준 보호: AWS Shield, AWS WAF
  • 네트워크 수준 보호: AWS Network Firewall, AWS Shield, Network ACL, Amazon Route 53 Resolver DNS Firewall

AWS Network Firewall

Amazon Virtual Private Cloud(VPC)에 대한 필수 네트워크 보호 기능을 쉽게 배포할 수 있는 관리형 서비스
  • VPC로 오가는 트래픽 검사 및 필터링 솔루션
  • 고가용성 및 Auto Scaling
    • 네트워크 트래픽에 따라 자동으로 확장 가능(트래픽 부하에 따라 방화벽 용량을 자동으로 확장하거나 축소)
    • 모든 트래픽을 일관되게 검사 및 모니터링할 수 있도록 내장된 중복 기능 제공
    • 99.99%의 가동 시간을 약속
  • 중앙 관리
    • AWS Firewall Manager와 연동 가능
      • AWS Firewall Manager는 호스트 수준의 보호와 조직 전반의 가시성 및 제어 기능 제공
      • AWS Firewall Manager 규칙 기반으로 정책 구축한 후 해당 정책을 중앙에서 제어 가능(VPC 및 계정 전반에 적용하거나 계층적으로 제어 가능)

 


Network Access Control List (NACL)

  • Subnet 앞에 위치하여 Subnet 의 트래픽을 제어
    • 일종의 Subnet 검문소
  • NACL을 여러 Subnet 에 적용할 수 있으나, Subnet 은 1개의 NACL만 따를 수 있음
  • Inbound, Outbound 규칙으로 나뉨
  • NACL의 규칙목록은 Inbound, Outbound 각각 최대 20개 지정 가능
    • 규칙목록에서의 우선순위 설정 가능 → 최우선 규칙만 통과하면 됨
  • Allow 규칙, Deny 규칙 생성 가능
  • Stateless: Subnet 안으로 들어올 땐 Inbound 규칙, 나갈 땐 Outbound 규칙 따름

Security Group

  • Subnet 안에 위치하여 해당 Subnet 안에 있는 Instance 등 가상컴퓨터 트래픽 제어
    • 정확히는 VPC 내부 Elastic Network Interface(ENI)를 갖는 모든 서비스(아래부턴 편의상 Instance라 표현함)
  • Instance 단위로 설정 가능
    • 하나의 Instance에서 최대 5개 Security Group 동시 적용 가능 → 트래픽은 모든 Security Group 규칙 통과해야함
    • 각 Instance에 각기 다른 Security Group 할당 가능
  • Inbound, Outbound 규칙으로 나뉨
    • 기본적으로 Outbound 규칙은 허용
  • Allow 규칙만 생성 가능
  • Stateful: 들어올 때 통과한 놈은 나갈 때는 프리패스(Outbound 규칙과 상관없이 나갈 수 있음)

AWS_SAA-C03_18.36V_Q15

Situation

  • 최근에 AWS로 마이그레이션함
  • 과거 사내 데이터 센터에 검사 서버가 있었는데 트래픽 흐름 검사 및 트래픽 필터링과 같은 작업을 수행했었음

Mission

  • VPC로 들어오고 나가는 트래픽 보호 솔루션을 구현해야함
  • AWS 클라우드에서 동일 기능 제공하는 솔루션은?

Action

  •  AWS Network Firewall을 사용하여 VPC에 대한 트래픽 검사 및 트래픽 필터링에 필요한 규칙 생성

출처

 

AWS의 네트워크 및 애플리케이션 보호

AWS는 네트워크 및 애플리케이션 보안 팀에 특정한 보호 요구 사항 및 규정 준수 요구 사항을 해결하는 서비스를 제공합니다. AWS 네트워크 및 애플리케이션 보호 서비스는 호스트, 네트워크 및

aws.amazon.com

 

 

AWS Network Firewall 기능 – Amazon Web Services

 

aws.amazon.com

 

 

[AWS] 📚 VPC 개념 & 사용 - 보안 설정 [Security Group / NACL]

VPC 방화벽 [Security Group / NACL] 이번엔 VPC의 트래픽을 통제하고 제어하는 서비스들을 살펴보자. 이 서비스들은 흔히 특정 IP를 밴 한다거나 외국에서는 접속을 못하게 한다거나 등 이러한 방화벽

inpa.tistory.com

 

 

SQS란

일종의 "TODO LIST - 시스템ver." 이다.

서버들끼리 사용 가능한 메시지 큐를 제공하는 서비스이다.

비동기 메시징 서비스를 제공한다.


기본 아키텍처

https://docs.aws.amazon.com/ko_kr/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-basic-architecture.html

분산 대기열 구조를 가지고 있다.

생산자가 메시지를 대기열로 보내면 대기열로 보내진 정보는 여러 SQS 서버에 해당 메시지를 중복 저장한다. 분산 저장한다는 의미이다.

대기열에 올라왔더라도 소비자가 바로 처리하는 건 아니고 처리할 준비가 되면 메시지를 수신하여 처리를 진행한다.

소비자가 대기열 메시지를 수신하면 Visibility timeout period가 시작되는데 일종의 타이머 같은 개념이다.

소비자가 메시지를 수신했더라도 대기열의 메시지는 삭제되지 않는다.

타이머가 종료되기 전에 소비자가 메시지 처리를 끝내면 그제야 대기열의 메시지도 삭제된다. 

그럼 대기열에 있는 다음 메시지 처리가 시작된다.


주요 구성요소

메시지

SQS의 기본 데이터 단위이다.

XML, JSON과 같은 텍스트 형태 데이터이고 최대 64KB까지 가능하다

 

대기열(큐)

메시지를 담는 공간이다.

메시지는 무제한 담아낼 수 있다

Region별로 생성할 수 있고 Region에 있는 큐 이름은 유일해야한다

연속 30일 동안 대기열(큐)에 아무런 요청이 없을 경우 AWS에서 해당 대기열(큐)를 삭제할 수 있다

대기열 종류는 표준 대기열과 FIFO 대기열이 있다.

  • 순서 상관 없을 경우, 표준대기열
  • 선입선출해야하는 경우, FIFO 대기열

AWS SAA-C03 V18.35 Q7

Situation

  • 회사로 들어오는 메시지 수집 응용 프로그램이 있음
  • 애플리케이션과 마이크로 서비스가 프로그램이 수집한 메시지를 빠르게 소비함
  • 메시지 수는 초당 100,000개로 갑자기 증가하기도 함

Mission

  • 솔루션을 분리하고 확장성을 높여야 함

Action

대기열에서 읽을 수 있도록 스프트웨어 업데이트

→ 들어오는 요청을 Amazon Simple Queue Service(SQS)에 라우팅 (SNS 주제에 메시지 게시)

→ 처리 인스턴스의 작업 요청 분리

→ 대기열의 크기에 따라 인스턴스 수를 확장할 수 있고 더 많은 리소스를 제공할 수도 있음

 


출처

 

Amazon SQS 기본 아키텍처 - Amazon Simple Queue Service

Amazon SQS는 최대 메시지 보존 기간 넘게 대기열에 유지된 메시지를 자동으로 삭제합니다. 기본 메시지 보존 기간은 4일입니다. 그러나 SetQueueAttributes 작업을 사용하면 메시지 보존 기간을 60초에

docs.aws.amazon.com

 

[AWS] SQS 란?

Amazon Simple Queue Service (Amazon SQS) 는 내구력 있고 가용성이 뛰어난 보안 호스팅 대기열을 제공하며 이를 통해 분산 소프트웨어 시스템과 구성 요소를 통합 및 분리할 수 있습니다. (https://docs.aws.amaz

velog.io

 

[AWS] SNS , SQS 란 ?

SNS , SQS

velog.io

 

 

VPC Endpoint란?

VPC 내부에 있는 Resource가 VPC 외부에 있는 서비스에 접근하기 위해선 Internet Gateway나 NAT Gateway 등 인터넷 연결이 필요하다. VPC Endpoint는 외부 인터넷 없이 내부 네트워크만으로 VPC 내부 Resource가 외부 서비스에 접근할 수 있도록 하는 서비스이다.

 

근데 외부 인터넷으로 연결하면 안되나?

해도 된다. 하지만 보안 상 문제가 발생할 수 있다.

외부 인터넷을 통해 공개적으로 통신하기에 트래픽이 노출될 우려가 있고 이는 보안 상 좋지 않기 떄문이다.

또한 VPC 외부로 나가는 트래픽에는 비용이 발생하기도 한다.


VPC Endpoint 종류: Interface Endpoint, Gateway Endpoint

  • Interface Endpoint
    • Elastic Network Interface를 통해 Private IP가 할당되는데 이 IP를 통해 Access하는 방식이다
    • PrivateLink에 대한 요금이 발생한다
    • Private Subnet 내부에 위치한다
    • SQS, SNS, Kenesis, Sagemaker 등 서비스 연결을 지원한다
    • VPC Peering 또는 AWS Transit Gateway를 통해 다른 Region에 Access를 허용할 수 있다
  • Gateway Endpoint
    • Route Table에서 경로 대상을 지정해 Endpoint에 Access하는 방식이다
    • VPC 내부에 위치하고, Private Subnet 외부에 위치한다
    • 통신 프로세스: EC2 → Route Table → Router → Gateway Endpoint → S3
    • S3, DynamoDB 등을 지원한다
    • 다른 Region에서의 Access는 허용하지 않는다

AWS_SAA-C03_V18.35_Q4

Situation

  • 애플리케이션이 VPC의 Amazon EC2 Instance에서 실행되고 있다
  • 애플리케이션이 S3 버킷에 저장된 로그를 처리한다

Mission

  • EC2 Instance는 인터넷 연결없이 S3 버킷에 액세스해야 한다
  • S3에 대한 Private Network 연결을 제공하는 솔루션은?

Action

VPC Gateway Endpoint

 


출처

 

[AWS] 📚 VPC 개념 & 사용 - 엔드포인트 [End Point]

VPC 엔드 포인트(End Point) VPC 엔드포인트는 VPC 내 Resource들이 VPC 외부의 서비스(S3, Dynamo DB, Cloudwatch) 등에 접근할 때 Internet Gateway, NAT Gateway 등의 외부 인터넷 전송 서비스를 타지 않고 내부 네트워

inpa.tistory.com

 

 

AWS VPC S3 endpoint gateway vs interface 차이 - BESPIN Tech Blog

1. AWS VPC endpoint 란? VPC 엔드포인트를 통해 인터넷 게이트웨이, NAT 디바이스, VPN 연결 또는 AWS Direct Connect 연결이 필요 없이 Virtual Private Cloud(VPC)와 지원 서비스 간에 연결을 설정할 수 있습니다. 따

blog.bespinglobal.com

 

+ Recent posts