정리 블로그

1. Route53의 가중치 기반 라우팅 적용

 -. 가중치 기반 라우팅(Weighted Routing Policy) 적용은 각 서버를 물리적으로 다른 호스트에서 운영할 경우에 적용할 수 있습니다. 예를들어 'IDC를 사용하고 있는 상황에서 클라우드에 서버를 신규로 생성하였고, 완전 클라우드로 이전하기에는 리스크가 있다고 판단하는 경우'(?)도 있을 수 있을거고..혹은 '클라우드에만 서버를 올려서 사용하기 불안하여, IDC와 혼합하여 사용하겠다' 등의 상황이 있겠지만..

해당 라우팅 정책은 각자 목적에 맞게 사용하시면 되겠습니다..

2. Weighted Routing Policy 적용하기

 -. 해당 정책을 적용하기 위해서는 레코드 타입이 모두 A 타입으로 생성이 필요합니다.(CNAME과 섞어서 사용해보려하였으나, 레코드를 생성하는 부분에서 에러가 발생하여 생성되지 않음 확인)

레코드 설정은 아래와 같이 진행해주면 됩니다.

->Routing Policy는 Weighted 로 설정.

->Record ID는 고유한 이름으로 설정하도록 하며, 이름 태그로 생각하면 됩니다.(설정하지 않으면 생성이 안됨)

Weight는 두 개의 레코드 비율을 다르게 줄 수 있습니다. 화면에 보이는지 모르겠으나, 0-255까지 숫자를 입력할 수 있으며, 1번 레코드에 10, 2번 레코드에 20을 넣으면 1:2 비중으로 인입됩니다.(0을 넣으면 해당 서버로는 인입이 없음)

3. 테스트 결과

 -. curl을 이용하여 총 10번의 테스트를 진행해보았을 때, 신기하게 5번 5번의 횟수로 각 서버에 연결되었습니다. 저의 경우, Weight를 각 10으로 설정해주었고, 직접 테스트해보시면 4번 6번의 결과정도가 출력될 수도 있습니다.

4. Simple Rounting Policy로 A레코드를 2개해볼까?

 -. Simple Routing으로 입력되는지 테스트를 해보고자 하였으나...아쉽게도 해당 라우팅 정책으로는 1개 이상이 추가되지 않았습니다.

위와 같이 라우팅 정책이 'Weighted'로 설정되지 않고, 'Simple' 정책으로는 동일한 레코드네임이 입력되지 않습니다.

Simple Policy로 동일한 레코드네임 두 개를 입력했을 때, 발생.

1. Invalidation 수행 목적

-. 해당 작업을 수행하는 목적은 캐싱 시간이 길게 설정되어있는 경우, 원본(Origin)에서 데이터를 변경하게 되더라도 CF 는 변경 전 값을 계속 캐싱하게 됩니다. TTL 시간동안 Origin 값을 가져오지 않아 변경된 데이터가 출력되지 않습니다.
따라서, 수동으로 CF에 원본 값을 재배포하고자 하는 경우 사용하게 됩니다.

2. Invalidation 수행 방법

1) AWS 콘솔에서 CloudFront 서비스로 이동 후 사용중인 Distributions 선택

2) 특정 Distribution 선택 후 Invalidation 선택

3) Create Invalidation 선택하여, Object path 입력

특정 경로에 대한 Invalidation이 적용되며, 'Create invalidation'을 누르는 즉시 적용됩니다. 해당 작업이 완료되기 전까지는 기존 값을 캐싱합니다.

1. AWS QuickSight란?

-. Quick Sight를 사용하는 이유는 BI(Business Intelligence) 대시보드를 활용하기 위함

-. 많은 데이터를 활용하고자 함(시각화 가능)

-. 장점

: 코드나 SQL로 분석하는 것 보다, 시각화로 빠른 인사이트에 도달

: 분석에 대한 자동 확장 및 서버리스

: AWS 서비스와 연결 사용 가능

: API 지원

• Kibana와 결합하여, 대시보드를 추가 이용 가능(WAF BLOCK율 등)
• 서버리스이며, Cloud Native.
• 다양한 데이터로부터 시각화 가능
• 데이터는 SPICE라는 인메모리 엔진에 올려서 분석
• N.Virginia에서는 Forcast 기능이 지원됨(다른 리전은 사용가능한지 확인해보지 않았으나, 서울 리전은 해당 기능이 없는 것으로 확인)

: 나의 AWS VPC와 연결이 가능(피어링 형식으로 진행되는 것 같으나, 정확하진 않음)하여, 내 AWS 리소스를 연결할 수 있음!!

생성 시, 보안그룹 ID도 필요함!

실제 해당 데이터는 2021년 12월까지만 있던 데이터지만, 'Forecast' 기능을 활용하면 해당 그래프와 같이 예측 데이터가 출력됩니다.

2. QuickSight Account

AWS 콘솔에 로그인해서 QuickSight를 사용하더라도, QuickSight용 Account를 만들어야한다.

Enterprise 요금은 위와 같으며, Standard도 별도로 있음.

Standard 계정을 생성 후 추후 Enterprise 요금으로 변경은 가능하지만, Enterprise에서 Standard로 변경은 불가능하기 때문에, 신중히 고려해보고 올릴 것.

3. 다양한 Dataset Import 가능

Dataset은 위와 같이 다양한 데이터를 활용하여 사용 가능합니다.

저는 csv 파일을 활용하였으며, 'Upload a file'을 통해 dataset을 Import 시켰습니다.

4. Import한 데이터 값을 가시적으로 확인 가능

위 그래프 생성 후 좌측 패널에 Insights를 선택하면, 수치로 바로 확인 가능한 리스트들 확인 가능.

해당 수치 중 필요한 수치를 추가하여, 대시보드로 만들 수 있음.

또한 'Fields list'(Import한 데이터 필드값)을 조합하여, 아래와 같이 테이블을 만들 수도 있음.

5. 대시보드 활용하기

위와 같이 차트그래프, 도넛 그래프, 특정 데이터값, 테이블 생성 등 필요한 자료들을 대시보드화하여, 해당 대시보드를 타인에게 공유 가능.

위와 같이 Manage User에 추가하여, 사용 가능함.

6. Report로 활용하기

QuickSight 대시보드를 다 만들었다면 Report 기능을 활용할 수 있음.

위와 같이 스케줄을 사용할 수 있으며, 메일 내용으로 대시보드 화면이 입력됨.(대시보드가 너무 크게 나와, 보기 불편)

Include PDF attachment를 활성화하여, 메일 첨부파일에 PDF 파일을 넣을 수 있고, 대시보드 크기와 동일하므로 보기 메일내용에 포함된 화면보다 보기 가독성이 좋음!

해당 대시보드를 확인할 수 없는 인원도 위와 같이 수신자 리스트에 추가하여 테스트가 가능합니다.

*** 비교할만한 유사한 서비스(AWS 서비스는 아님) : 태블로(Tableau)

1. 목적

AWS에서 오라클 12버전을 더이상 지원하지 않음에 따라 12버전을 사용하는 경우에는 19버전으로 업그레이드가 필요함. 4월 1일(KST)부로 순차적으로 버전 업그레이드가 강제로 진행되며, 일부 문법이 틀린 함수의 경우 동작하지 않을 수 있으니, 사전에 RDS 스냅샷을 이용하여 업그레이드 테스트가 진행되어야 안전함.

2. 오라클 12버전 설정

3. 작업 진행

AWS 콘솔의 RDS '수정'으로 들어가, 원하는 버전 번호를 확인할 것.

버전을 확인(여기서는 19버전)하였으면 작업 전, 19버전에 맞는 Parameter Group과 Option Group 생성이 필요하다.(Parameter Group의 경우, 12버전에서 사용하던 Parameter Group과 비교하여 기존에 기본값에서 변경하였던 부분은 변경해준다.

Option Group의 경우, 사전에 적용했던 옵션[타임존 등]을 확인하여 변경할 것)

RDS 수정 시, 버전 선택 후 '▼ 추가 구성' 을 확인하여, 사전에 생성하였던 파라미터 그룹과 옵션 그룹으로 변경해준다.

변경되는 값을 확인 후 '즉시 적용'으로 진행할 것!

300GB 크기 기준으로 10시 34분 시작 -> 11시 26분정도에 완료되었으니, 참고하세요.

0. 사용 목적

개발계 인스턴스의 경우, 업무시간 외에 지속적으로 실행시킬 필요가 없으므로, 업무시간 외에 AutoStop/Start를 통해 비용 절감 목적

1. Lambda 함수에서 사용할 IAM 생성

Step 1.

-. IAM -> Role 생성 -> AWS Service -> Lambda 선택(EC2는 확인하려고 클릭한거였는데..저렇게 남아있음)

Step 2.

아래 Permission을 추가.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Start*",
        "ec2:Stop*"
      ],
      "Resource": "*"
    }
  ]
}

2. Lambda 함수 생성

-. Start용 함수와 Stop용 함수, 두 개를 생성할 것.

-.함수 생성

위와 같이 Author from scratch 선택하며, Python 3.9로 생성하였음.

Role은 위에서 생성한 Role을 추가해줘야 하며, Stop과 마찬가지로 Start도 생성해줘야함.(EventBridge를 따로 사용해야하므로 각 각 생성)

-. Lambda Stop 함수

import boto3
region = 'us-west-1'
instances = ['i-12345cb6de4f78g9h', 'i-08ce9b2d7eccf6d26']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.stop_instances(InstanceIds=instances)
    print('stopped your instances: ' + str(instances))

위 Code에서 'instance, region'은 내 인스턴스 ID, 인스턴스가 위치한 region으로 수정해줄 것

-. Lambda Start 함수

import boto3
region = 'us-west-1'
instances = ['i-12345cb6de4f78g9h', 'i-08ce9b2d7eccf6d26']
ec2 = boto3.client('ec2', region_name=region)

def lambda_handler(event, context):
    ec2.start_instances(InstanceIds=instances)
    print('started your instances: ' + str(instances))

마찬가지로 region, instances 변수 수정해줄 것.

3. EventBridge Rule 생성할 것.

EventBridge 규칙은 Cron을 활용하여 진행할 것이며, Cron의 시간은 GMT 기준이므로 한국시간으로 계산하여 작성 필요.

위 Cron식은 한국시간 기준 19시 55분을 기준으로 설정.

대상과 함수를 지정하여 Rule 생성할 것.

*STOP 함수도 위와 동일하게 생성해주면 됨.

5. Cron 표현식 참고

** 해당 방법으로 ec2 뿐 아니라, rds도 적용 가능할 것으로 보이나, 테스트해보지 않았습니다. 추후 필요하신 분은 테스트해보시면 될 것 같습니다.

++TMI : RDS의 경우, Stop하여도 7일 뒤면 자동 Start가 진행됩니다. 시작되는 일정에 맞춰 AutoStop을 설정하는 것도 하나의 방법

1. 문제 원인

Linux(Amazon Linux2) 환경에서 보안 강화를 하고자 firewalld를 설치 후 실행하였음.

yum install -y firewalld
systemctl enable --now firewalld

firewalld를 수행할 경우, 22번 포트는 막히지 않으나, 보안 강화를 위해... ssh 포트를 변경하여 사용중이었음.

따라서, 22번 포트는 막히지 않았으나, 22번 포트 외 실제 사용하는 ssh 포트 사용 불가.

2. 해결 방법

사용중인 EC2를 Stop 후 user-data에 추가한 뒤 EC2 Start 진행.

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
systemctl stop firewalld
systemctl disable firewalld
iptables -F
service sshd restart
--//

3. 유저데이터 값 입력 후 수행

유저데이터 입력 후 EC2 시작

----------------------------------------------------------------------------------

EC2를 다시 시작하면 정상적으로 ssh 접속 되는 것을 확인할 수 있으며, 접속 확인이 완료되면 EC2를 다시 한번 Stop 후 유저데이터를 삭제해줄 것.(Optional이지만, 유저데이터를 지워주지 않을 경우, 재시작할 때, 해당 작업을 또 수행함)

1. 가트너의 하이프 사이클이란?

 미국의 정보 기술 연구 및 자문 회사인 가트너에서 개발한(?) 기술의 성숙도를 표현하는 시각적 도구

기술촉발 - 부풀려진 기대의 정점 - 환멸 단계 - 계몽 단계 - 생산성 안정 단계.

총 5단계로 구성되어있는 사이클.

신기술에 대한 시장의 기대가 어떻게 변하는지 정리된 곡선이며, 신기술을 해당 곡선에 표현하여, 매년 기술을 해당 그래프에 표기하는 형식.

2. 하이프 사이클 그래프

3. 단계별 명칭 설명

(출처:위키피디아)

4. 하이프 사이클(엔터프라이즈 네트워킹 부분 - 2021)

가트너의 하이프 사이클은 위 그림과 같이 분야에 대한 사이클이 표시됨.

5. 개인적인 생각

 하이프 사이클에서 클라우드는 '4단계-계몽 단계'와 '5단계-생산성 안정 단계'의 사이 즈음이 아닐까 하는 생각이 든다. 정부시스템까지도 클라우드에 올리려는 움직임이 있으며, 기술이 시장의 주류를 이루는 것으로 생각한다.

ALB의 경우, WhiteList 방식이 아니라, 전체 허용. 특정 IP에만, 특정 경로를 접근하도록 하고싶었음. 

1. ALB에 규칙

ALB를 생성하면 위 화면과 같이 리스너를 생성하고, 여러개의 리스너를 사용할 경우에는 각 리스너별로 규칙을 생성할 수 있다. 각 리스너 규칙별로 ALB에 접근하는 소스 IP별 분기, 호스트별 분기, 특정 웹 Path별 분기가 가능함. 1개의 규칙에 소스 IP+호스트 분기와 같이 조합을 통해 다양한 방법으로 분기가 가능하니, 익혀두면 도움이 될 것.

2. 규칙 생성하기

위와 같이 규칙을 준 이유.

1) /admin/page.html 이라는 웹서버 경로에 특정 IP가 접근 가능.

2) /admin/page.html 경로로 접속할 경우, 404 응답 반환(에러 코드는 관리자 임의 지정 가능. 444와 같은 커스터마이징된 에러코드도 가능하며, 한글 반환도 가능) - 위에서 허용된 특정 Source가 아닌 경우임

마지막) 두 가지 조건에 해당하지 않는 경우, test라는 타겟 그룹으로 전달됨.

3. 규칙 생성 후 테스트

환경 구성 1) 클라이언트 PC의 IP는 /admin/page.html로 접근이 허용된 IP

환경 구성 2) 클라이언트 모바일 IP는 접근 허용이 되지 않은 IP

1) 클라이언트 PC에서 메인 페이지 접근

2) 클라이언트 PC에서 /admin/page.html 페이지 접근

3) 모바일에서 메인 페이지 접근

4) 모바일에서 /admin/page.html 접근 (허가되지 않은 Source IP)

*접근 권한이 없을 때, 응답 반환은 관리자가 임의로 표기한 문구가 출력