Jenkins 버전 업그레이드 과정에서 LDAP 플러그인 오류로 인해 Jenkins가 정상 기동되지 않는 문제가 발생했습니다. 본 글에서는 해당 오류를 config.xml에서 임시로 보안 설정을 비활성화하여 해결하고, 최신 jenkins.war를 사용해 Standalone Jenkins를 systemd 서비스로 구성한 과정을 정리했습니다.

1. 문제 상황

Jenkins 버전 업그레이드 이후 기동 과정에서 LDAP 관련 플러그인 오류가 발생하며 Jenkins가 정상적으로 올라오지 않았음

• Jenkins UI 접근 불가
• 로그 상 LDAP / securityRealm 관련 예외 발생
• 플러그인 업데이트 없이 Jenkins 자체 기동이 불가능한 상태

👉 일단 Jenkins를 띄워야 문제 분석 및 플러그인 정리가 가능했기 때문에 임시 조치로 보안 설정을 비활성화하는 방법을 선택

2. Jenkins 보안 설정 임시 비활성화

2-1. config.xml 백업

cd /home/ec2-user/.jenkins
cp config.xml config.xml.bak_$(date +%Y%m%d%H%M)

2-2. config.xml을 수정하여 LDAP 및 권한 관련 설정을 제거

vi /home/ec2-user/.jenkins/config.xml

(1) 보안 사용 여부 비활성화
<useSecurity>false</useSecurity>

(2) authorizationStrategy 태그 전체 삭제
<authorizationStrategy class="hudson.security.ProjectMatrixAuthorizationStrategy">
    ...
</authorizationStrategy>

(3) securityRealm 태그 전체 삭제 (LDAP 설정)
<securityRealm class="...">
    ...
</securityRealm>

👉 위 설정을 제거하면 Jenkins는 보안이 비활성화된 상태로 기동됨 (임시 조치이므로 운영 환경에서는 반드시 재설정 필요)

3. 최신 Jenkins WAR 다운로드

mkdir /home/ec2-user/jenkins-standalone
cd /home/ec2-user/jenkins-standalone

# 최신 stable WAR 파일을 다운로드
wget https://get.jenkins.io/war-stable/latest/jenkins.war

4. Jenkins를 systemd 서비스로 등록

4-1. systemd 서비스 파일 생성

sudo vi /etc/systemd/system/jenkins.service

-------------------------------------------------------
[Unit]
Description=Jenkins Standalone
After=network.target

[Service]
Type=simple
User=ec2-user
Environment="JENKINS_HOME=/home/ec2-user/.jenkins"
ExecStart=/home/ec2-user/apps/jdk_21/bin/java \
  -jar /home/ec2-user/jenkins-standalone/jenkins.war \
  --httpPort=12000
Restart=always

[Install]
WantedBy=multi-user.target
-------------------------------------------------------

4-2. systemd 반영 및 서비스 기동

# systemd에 새로 등록한 서비스 파일을 인식시키기 위해 데몬을 다시 로드
sudo systemctl daemon-reload

# 시스템 부팅 시 Jenkins 서비스가 자동으로 시작되도록 활성화
sudo systemctl enable jenkins

# Jenkins 서비스를 즉시 기동
sudo systemctl start jenkins

# Jenkins 서비스가 정상적으로 실행 중인지 상태 확인
sudo systemctl status jenkins

정상적으로 기동되면 최신 버전의 Jenkins UI에 접근 가능

5. 이후 작업 (권장)

Jenkins가 정상 기동된 이후에는 아래 작업을 진행하는 것이 좋음

5-1. 플러그인 버전 호환성 확인

• Jenkins 업그레이드 이후 플러그인 버전을 함께 업데이트하지 않으면 일부 Job 실행, 설정 화면, 기능 사용 시 오류가 발생할 수 있음
• Pipeline, SCM, Credential 관련 플러그인은 Jenkins Core 버전과의 호환성 확인이 필요

5-2. 불필요한 플러그인 정리

• 미사용 플러그인이 남아 있을 경우, 다른 플러그인과의 충돌로 인해 일부 Job의 UI가 깨지거나 설정 저장이 불가능한 문제가 발생할 수 있음
• 실제 사용 중인 Job 기준으로 플러그인을 정리하면 Jenkins 안정성과 관리 복잡도를 동시에 개선할 수 있음

5-3. LDAP / Authorization 재설정

• 임시 조치로 비활성화한 보안 설정을 다시 구성

AWS 보안 그룹(Security Group)에 설정된 기존 IP 범위(OLD_PREFIX)를 기반으로 새로운 IP 범위(NEW_PREFIX)를 자동으로 추가하는 스크립트입니다.

핵심 목적 기존 IP가 111.222.333.N/32이면, 자동으로 110.220.330.N/32를 같은 규칙에 추가합니다. 단, 동일한 IP가 이미 등록되어 있으면 생략합니다.

#!/usr/bin/env python3

import argparse
import sys
import boto3
from botocore.exceptions import ClientError

def normalize(cidr):
    return cidr.split('/')[0]

def replicate_permission(sg_id, perm, old_prefix, new_prefix, ec2):
    proto = perm['IpProtocol']
    from_port = perm.get('FromPort')
    to_port   = perm.get('ToPort')
    existing = [normalize(r.get('CidrIp','')) for r in perm.get('IpRanges', [])]

    if any(ip.startswith(new_prefix + '.') for ip in existing):
        print(f"  [SKIP] SG {sg_id} {proto} {from_port}-{to_port}, new-prefix already present")
        return

    old_ips = [ip for ip in existing if ip.startswith(old_prefix + '.')]
    if not old_ips:
        return

    print(f"  [INFO] SG {sg_id} {proto} {from_port}-{to_port}: found old-prefix entries {old_ips}")
    for old_ip in old_ips:
        last = old_ip.split('.')[-1]
        new_ip = f"{new_prefix}.{last}"
        if new_ip in existing:
            print(f"    - skip {new_ip}/32, already exists")
            continue
        ip_perm = {
            'IpProtocol': proto,
            **({'FromPort': from_port, 'ToPort': to_port} if from_port is not None else {}),
            'IpRanges': [{'CidrIp': f"{new_ip}/32"}]
        }
        print(f"    + adding {new_ip}/32 ... ", end='')
        try:
            ec2.authorize_security_group_ingress(
                GroupId=sg_id,
                IpPermissions=[ip_perm]
            )
            print("OK")
        except ClientError as e:
            code = e.response['Error']['Code']
            if code == 'InvalidPermission.Duplicate':
                print("AlreadyExists")
            else:
                print(f"ERROR ({code})")

def main():
    parser = argparse.ArgumentParser(
        description="Replicate OLD_PREFIX→NEW_PREFIX CIDRs for all SGs in a region"
    )
    parser.add_argument('--old-prefix', required=True,
                        help="Old prefix, e.g. 111.222.333")
    parser.add_argument('--new-prefix', required=True,
                        help="New prefix, e.g. 110.220.330")
    parser.add_argument('--region', required=True,
                        help="AWS region, e.g. ap-northeast-2")
    parser.add_argument('--profile',
                        help="AWS CLI profile name")
    args = parser.parse_args()

    sess_kwargs = {'region_name': args.region}
    if args.profile:
        sess_kwargs['profile_name'] = args.profile
    session = boto3.Session(**sess_kwargs)
    ec2 = session.client('ec2')

    paginator = ec2.get_paginator('describe_security_groups')
    sg_ids = []
    for page in paginator.paginate():
        sg_ids += [sg['GroupId'] for sg in page['SecurityGroups']]
    print(f"[INFO] Found {len(sg_ids)} SGs in {args.region}")

    for sg_id in sg_ids:
        try:
            sg = ec2.describe_security_groups(GroupIds=[sg_id])['SecurityGroups'][0]
        except ClientError as e:
            print(f"[ERROR] describe SG {sg_id}: {e}", file=sys.stderr)
            continue
        perms = sg.get('IpPermissions', [])
        print(f"\n[PROCESS] SG {sg_id} ({len(perms)} permissions)")
        for perm in perms:
            replicate_permission(sg_id, perm, args.old_prefix, args.new_prefix, ec2)

if __name__ == '__main__':
    main()

사용 예시

python sg_replicate_by_prefix.py \
  --old-prefix 111.222.333 \
  --new-prefix 110.220.330 \
  --region ap-northeast-2 \
  --profile my-aws-profile

특정 리전에 존재하는 모든 보안 그룹에 IP를 자동으로 등록함으로써, 매번 수동으로 IP를 추가해야 하는 번거로움을 효과적으로 해소했습니다.

MongoDB의 한 데이터베이스에서 다른 데이터베이스로, 컬렉션별로 인덱스를 복사합니다. 단, 기본 인덱스인 id\ 는 제외하고 복사함.

함수 정의: copy_indexes(...)

from pymongo import MongoClient

def copy_indexes(source_uri, source_db_name, target_uri, target_db_name):
    # 소스와 타겟 MongoDB 연결
    source_client = MongoClient(source_uri)
    source_db = source_client[source_db_name]

    target_client = MongoClient(target_uri)
    target_db = target_client[target_db_name]

    # 소스 DB의 모든 컬렉션 이름 가져오기
    collection_names = source_db.list_collection_names()

    for collection_name in collection_names:
        print(f"📁 복사 중: {collection_name}")

        source_collection = source_db[collection_name]
        target_collection = target_db[collection_name]  # 컬렉션이 없으면 pymongo가 자동 생성함

        # 인덱스 리스트 (기본 _id 인덱스는 제외)
        indexes = [idx for idx in source_collection.list_indexes() if idx['name'] != '_id_']

        # 인덱스 복사
        for index in indexes:
            # 인덱스 키를 리스트의 튜플로 변환하되, 방향 값을 명시적으로 int로 변환
            keys = [(k, int(v)) for k, v in index['key'].items()]
            kwargs = {k: v for k, v in index.items() if k not in ['key', 'ns', 'v']}
            target_collection.create_index(keys, **kwargs)

        print(f"✅ 완료: {collection_name} 인덱스 복사")

    print("🎉 모든 컬렉션 인덱스 복사 완료")


# 예시 실행
copy_indexes(
    source_uri="mongodb://user:password@mongodb-1.internal:27017",
    source_db_name="AAADB",
    target_uri="mongodb://user:password@mongodb-2.internal:27017",
    target_db_name="BBBDB"

해당 스크립트를 실행하면 AAADB의 인덱스들을 BBBDB로 복사합니다.

##주의 사항##

1. 대상 컬렉션에 이미 같은 인덱스가 있을 경우 중복 생성은 되지 않지만, name 충돌 등의 이슈가 발생할 수 있음

2. 데이터 자체는 복사되지 않음 (인덱스만 복사)

3. 인덱스의 unique/sparse 조건도 그대로 복사되므로, 타겟 컬렉션이 비어있지 않다면 충돌 가능성 존재

AWX를 사용하면 민감 정보를 간편하게 관리할 수 있습니다. 새로운 인증 정보 유형을 생성하여 민감 정보를 변수(variable)로 정의하고, 플레이북 실행 시 이를 참조할 수 있습니다.

1. 새로운 인증 정보 유형을 추가

2. 원하는 항목과 변수를 직접 추가하여 인증 정보 유형 만들기

입력 구성

fields:
  - id: Credential_TEST_01
    type: string
    label: Credential 01
    secret: false
  - id: Credential_TEST_02
    type: string
    label: Credential 02
    secret: true    # 인증정보에서 데이터를 암호화 할지 여부

인젝터 구성

extra_vars:
  Credential_TEST_01: '{{ Credential_TEST_01 }}'
  Credential_TEST_02: '{{ Credential_TEST_02 }}'

3. 인증 정보 추가

4. 직접 생성한 인증 정보 유형을 사용하여 새 인증 정보 만들기

5. 인증 정보를 참조하는 플레이북 생성

### 테스트를 위한 Playbook 
---
- name: Create Credential TEST file
  hosts: all
  tasks:
    - name: Ensure test.txt file exists
      ansible.builtin.file:
        path: /home/ec2-user/{{ Credential_TEST_01 }}.txt
        state: touch

    - name: Ensure test.txt file exists
      ansible.builtin.file:
        path: /home/ec2-user/{{ Credential_TEST_02 }}.txt
        state: touch

6. 작업 템플릿을 생성할때 인증 정보를 추가

7. 변수를 참조하여 정상적으로 플레이북 실행

새로운 인증 정보 생성 완료 - ̗̀( ˶' ３'˶) ̖́-

일반적인 Nginx 버전 업그레이드가 아닌, EOS 상태인 Amazon Linux 2에서 Nginx를 업그레이드할 때 모듈 충돌을 방지하고 nginx.conf 파일이 삭제되지 않도록 하는 방법입니다.

Amazon Linux 2에서 제공하는 amazon-linux-extras를 통해 설치 가능한 Nginx 버전은 1.22.1까지만 지원되며, 이는 보안적으로 최신 상태가 아닙니다. 그래서 1.26.2 이상의 버전을 신속하게 사용해야 하는 상황이 발생한다면, AWS에서는 더이상 업데이트 계획이 없기 때문에 외부 저장소를 추가하여 최신 버전으로 업그레이드를 진행해야합니다.

AWS 답변
Amazon Linux 2는 "AL2 End of Life is 2025-06-30" 예정이며,
고객님과 동일한 사례의 내역을 살펴 보면 현재로서는 "amaon-linux-extra를 통한 nginx package version" 
신규 버전 지원은 예정에 없는 것으로 파악 됩니다.

이 글에서는 Amazon Linux 2에서 새로운 저장소를 추가하여 Nginx를 최신 안정 버전으로 업그레이드하는 방법을 다룹니다.

1. nginx.repo 추가

sudo vi /etc/yum.repos.d/nginx.repo

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/amzn2/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true
priority = 1

2. 레포 enable 해주기

   sudo yum-config-manager --enable nginx-stable

3. yum 캐시 날리기

   sudo yum clean all

4. Nginx 설치 가능 버전 리스트 보기

   # 리스트 확인
   sudo yum --showduplicate list nginx
   

install 하면 모듈 충돌 발생함

sudo yum install -y nginx

5. 기존 설치 되어있는 모듈 리스트 확인

rpm -qa | grep nginx

이런 모듈들 있음

nginx-filesystem-1.22.1-1.amzn2.0.4.noarch nginx-mod-http-xslt-filter-1.22.1-1.amzn2.0.2.x86_64 nginx-1.22.1-1.amzn2.0.4.x86_64 nginx-mod-stream-1.22.1-1.amzn2.0.2.x86_64 nginx-core-1.22.1-1.amzn2.0.4.x86_64 nginx-mod-http-image-filter-1.22.1-1.amzn2.0.2.x86_64 nginx-mod-http-perl-1.22.1-1.amzn2.0.2.x86_64 nginx-mod-http-geoip-1.22.1-1.amzn2.0.2.x86_64

6. 충돌 발생하는 모듈 삭제

nginx-core는 지우면 nginx.conf가 삭제됨 주의해야함

nginx-core 제외 충돌 발생하는 모듈만 삭제해야함

sudo yum remove nginx-mod-http-xslt-filter nginx-mod-http-geoip nginx-mod-http-perl nginx-mod-http-image-filter nginx-mod-mail nginx-mod-stream -y

모듈 지우고 install 해보면 nginx-core 패키지 충돌 오류남

sudo yum install -y nginx

7. conf 파일 삭제 되지 않도록 swap으로 현재 설치된 패키지를 다른 패키지로 교체

sudo yum swap nginx-core nginx -y

8. 필요 모듈을 다시 설치, 추가한 레포에서 모듈 지원하는지 확인

yum list available --disablerepo=amzn2extra-nginx1 --enablerepo=nginx-stable | grep nginx-mod

9. 리스트에서 필요 모듈 설치

sudo yum install nginx-module-geoip nginx-module-image-filter nginx-module-perl nginx-module-xslt -y --disablerepo=amzn2extra-nginx1 --enablerepo=nginx-stable

10. Nginx 재시작

sudo systemctl daemon-reload sudo systemctl restart nginx

#버전 확인 nginx -v

AWX에 호스트를 등록하는 방법중 AWS에서 인스턴스 리스트를 받아서 자동으로 호스트를 등록하는 방법으로 동적 인벤토리 소스(예: AWS, GCP, VMware, Ansible Tower 자체 등)를 설정할 때, 인벤토리를 자동으로 가져올 수 있습니다.

1. AWS에서 AmazonEC2FullAccess 권한을 가진 사용자를 생성하고 액세스 키 발급

2. AWX 인증 정보에 AWS에서 생성한 사용자의 액세스 키를 입력하여 새 인증 정보 생성

3. 새 인벤토리 만들기

4. 생성한 인벤토리에 소스 추가

   소스 변수는 특정 소스에 대한 필요한 매개변수를 설정합니다. 예를 들어, API 키, 리전, 필터 조건 등을 설정하여 인벤토리를 커스터마이징할 수 있습니다.

   # 변수 내용

region: ap-northeast-2 filters: "instance-state-name": running strict_permissions: False hostnames:

• name: 'instance-id' separator: '_' prefix: 'tag:Name' compose: ansible_host: private_ip_address

5. 소스 추가 완료 후 동기화 진행

6. 호스트 자동 등록 확인

인벤토리 등록 완료 (๑•᎑<๑)ｰ☆

k3s를 이용한 최신 버전의 AWX 구축 방법 스펙 : CentOS 7 (최소 2vCPU/ 4Mem)

사전 설치 패키지

sudo yum -y install tar git make jq

1. k3s 설치

curl -sfL https://get.k3s.io | sudo bash -

1-1. k3s 실행을 위한 권한 설정

sudo chmod 644 /etc/rancher/k3s/k3s.yaml
sudo chown -R $USER. /etc/rancher
mkdir ~/.kube
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown -R $USER. ~/.kube/config

1-2. k3s 실행 상태 확인

sudo systemctl status k3s.service

2. Kubernetes에 AWX Operator 배포

git clone https://github.com/ansible/awx-operator.git

2-1. NAMESPACE 생성

export NAMESPACE=awx
kubectl create ns ${NAMESPACE}

2-2. defalt 컨텍스트 변경

kubectl config set-context --current --namespace=$NAMESPACE

2-3. AWX Operator 릴리스의 최신 버전을 브랜치로 체크아웃

cd awx-operator
RELEASE_TAG=`curl -s https://api.github.com/repos/ansible/awx-operator/releases/latest | grep tag_name | cut -d '"' -f 4`
echo $RELEASE_TAG
git checkout $RELEASE_TAG
git log -1

2-4. 클러스터에 AWX Operator 배포

export NAMESPACE=awx
make deploy

약 5분 후 설치 확인

kubectl get pods -n awx

3. Ansible AWX 설치

3-1. PVC 생성

mkdir ~/awx
cd ~/awx
vi public-static-pvc.yaml

# 아래 코드 추가
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: public-static-data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-path
  resources:
    requests:
      storage: 5Gi

# pvc 배포
kubectl apply -f public-static-pvc.yaml -n awx

kubectl get pvc -n awx

3-2. AWX 배포

vi awx-instance-deployment.yml

#아래 내용 추가
---
apiVersion: awx.ansible.com/v1beta1
kind: AWX
metadata:
  name: awx
  namespace: awx
spec:
  service_type: nodeport
  projects_persistence: true
  projects_storage_access_mode: ReadWriteOnce
  ee_extra_env: |
    - name: RECEPTOR_KUBE_SUPPORT_RECONNECT
      value: enabled
  web_extra_volume_mounts: |
    - name: static-data
      mountPath: /var/lib/projects
  extra_volumes: |
    - name: static-data
      persistentVolumeClaim:
        claimName: public-static-data-pvc

# AWX deployment 배포
kubectl apply -f awx-instance-deployment.yml -n awx

배포 완료까지 10분 정도의 시간이 소요될 수 있음

3-3. 배포 상태 확인 방법

watch kubectl get pods -l "app.kubernetes.io/managed-by=awx-operator" -n awx

STATUS 가 모두 Running 상태면 배포가 완료됨

초기 관리자 계정의 경우 ID는 admin이고 패스워드는 아래 명령어로 확인

kubectl -n awx get secret awx-admin-password -o go-template='{{range $k,$v := .data}}{{printf "%s: " $k}}{{if not $v}}{{$v}}{{else}}{{$v | base64decode}}{{end}}{{"\n"}}{{end}}'

AWX 구축 완료 (๑❛ڡ❛๑)☆

ALB의 Access log를 S3에 저장하고 저장된 로그를 AWS의 "Athena"를 이용해서 분석하는 방법

1. ALB의 Access Log를 저장할 s3버킷 생성 (버킷은 LB와 같은 리전에 생성해야하며, 접두사에는 "AWSLogs" 라는 문구가 포함되지 않아야합니다.)

S3 버킷 정책

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<elb-account-id: 600734575887(ap-northeast-2)>:root"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::aws-alb-log-s3-jay/*"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "logdelivery.elb.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::aws-alb-log-s3-jay/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

2. ALB에서 s3에 로그 수집 활성화 < Access Log 비활성화 -> 활성화 설정 >

alb의 속성에서 로그수집을 위해 생성한 s3를 alb에 연결합니다.

alb에 로그가 활성화되면 lb에서 s3 버킷을 검증하고 버킷 정책에서 필수 권한이 지정됐는지 확인하는 테스트 파일을 생성합니다. 파일이 정상적으로 생성되지 않았다면 정책을 다시 확인해야합니다.

잠시후 lb에 요청이 있다면 아래와 같이 Access 로그가 정상적으로 저장됩니다.

3. Athena를 이용한 Access Log 분석

   AWS Athena 란? Amazon Athena는 표준 SQL을 사용하여 Amazon S3(Amazon Simple Storage Service)에 있는 데이터를 직접 간편하게 분석할 수 있는 대화형 쿼리 서비스입니다. AWS Management Console에서 몇 가지 작업을 수행하면 Athena에서 Amazon S3에 저장된 데이터를 지정하고 표준 SQL을 사용하여 임시 쿼리를 실행하여 몇 초 안에 결과를 얻을 수 있습니다.

athena에서 작업 그룹을 생성합니다.

쿼리편집기의 설정을 위에서 생성한 작업그룹으로 변경합니다.

s3 폴더에 athena의 쿼리 결과를 저장할 수 있습니다.

쿼리 편집기에서 alb의 로그를 저장할 db를 생성합니다.

CREATE DATABASE jaytestalbdb;

쿼리 편집기에서 alb 로그의 테이블 생성

CREATE EXTERNAL TABLE IF NOT EXISTS alb_logs (
            type string,
            time string,
            elb string,
            client_ip string,
            client_port int,
            target_ip string,
            target_port int,
            request_processing_time double,
            target_processing_time double,
            response_processing_time double,
            elb_status_code int,
            target_status_code string,
            received_bytes bigint,
            sent_bytes bigint,
            request_verb string,
            request_url string,
            request_proto string,
            user_agent string,
            ssl_cipher string,
            ssl_protocol string,
            target_group_arn string,
            trace_id string,
            domain_name string,
            chosen_cert_arn string,
            matched_rule_priority string,
            request_creation_time string,
            actions_executed string,
            redirect_url string,
            lambda_error_reason string,
            target_port_list string,
            target_status_code_list string,
            classification string,
            classification_reason string
            )
            ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
            WITH SERDEPROPERTIES (
            'serialization.format' = '1',
            'input.regex' = 
        '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*)[:-]([0-9]*) ([-.0-9]*) ([-.0-9]*) ([-.0-9]*) (|[-0-9]*) (-|[-0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) (.*) (- |[^ ]*)\" \"([^\"]*)\" ([A-Z0-9-_]+) ([A-Za-z0-9.-]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^\"]*)\" ([-.0-9]*) ([^ ]*) \"([^\"]*)\" \"([^\"]*)\" \"([^ ]*)\" \"([^\s]+?)\" \"([^\s]+)\" \"([^ ]*)\" \"([^ ]*)\"')
            LOCATION 's3://your-alb-logs-directory/AWSLogs/<ACCOUNT-ID>/elasticloadbalancing/<REGION>/'

테이블이 정상적으로 생성된것을 확인할 수 있습니다.

이제 Athena SQL를 이용해서 alb로그의 다양한 값을 구할 수 있습니다. 예를 들면 아래와 같은 쿼리로 alb의 시간대별 request_processing_time의 최고값을 구할 수 있습니다.

SELECT hour(parse_datetime(time,'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z')), MAX(target_processing_time) 
FROM alb_logs
WHERE (parse_datetime(time,'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z') 
     BETWEEN parse_datetime('2023-02-20-00:00:00','yyyy-MM-dd-HH:mm:ss') 
     AND parse_datetime('2023-02-20-23:59:00','yyyy-MM-dd-HH:mm:ss'))
     AND(target_status_code = '200')
GROUP BY hour(parse_datetime(time,'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z'))
ORDER BY hour(parse_datetime(time,'yyyy-MM-dd''T''HH:mm:ss.SSSSSS''Z'))

이처럼 Athena를 이용해서 간편하게 Log를 분석할 수 있으며, NLB또한 같은 방법으로 액세스 로그를 수집할 수 있지만 NLB의 경우 TLS리스너가 있어야 하며 액세스 로그가 TLS 요청에 관한 정보만 포함하는 경우에만 액세스 로그가 생성됩니다🧐

1. 태깅 기반의 리소스 비용 추적

AWS의 비용 할당 태그를 이용하면 AWS 비용을 더 자세히 추적할 수 있습니다. AWS 리소스에 태그를 적용하고 Billing and Cost Management 콘솔에서 태그를 활성화하면, AWS는 활성 태그를 기준으로 그룹화한 사용 내역 및 비용이 포함된 비용 할당 보고서를 쉼표로 분리된 값을 파일(CSV 파일)로 생성합니다. 또한 Cost Explorer에서 보기를 필터링하는 데에도 태그를 사용할 수 있습니다.

2. Compute Optimizer 기반의 리소스 프로비저닝 상태 확인

AWS Compute Optimizer 콘솔에 opt in하면 AWS Compute Optimizer가 vCPU,메모리,스토리지와 같은 리소스 사양을 지난 14일을 기준으로 CloudWatch지표에서 분석합니다.(향상된 인프라 지표 권장 사항 기본 설정을 활성화하는경우 14일 이상도 분석 가능) 분석이 완료되면 Compute Optimizer가 대시보드 및 권장 사항 페이지에서 최적화 리소스 추천을 확인할 수 있습니다.

3. 주된 Inbound/Outbound 트래픽 방향 확인

AWS 리전의 모든 서비스 간 인바운드 데이터 전송에는 요금이 부과되지 않지만, AWS에서 인터넷으로의 아웃 바운드 데이터 전송 요금은 서비스당 부과되며, 각 비용은 리전에 따라 다릅니다.

(AWS 서비스간 데이터 전송 요금은 소스, 대상 및 트래픽 양에 따라 부과되는 점 참고) 따라서 AWS 내에서 AWS 서비스에 연결할 때 인터넷을 통해 트래픽을 라우팅하지 않도록 VPC엔드포인트를 사용하는것이 좋습니다.

4. 사용하는 스토리지 & 데이터베이스 스토리지 옵션 확인

AWS에는 S3, EBS, EFS, FSx 같이 다양한 스토리지 서비스가 존재합니다. 이 중에서 사용 중인 스토리지에서 과도한 저장비용이 발생하고 있지는 않은지 확인하고 조치하는 것이 좋습니다. (예를들어 버전관리가 활성화된 S3에서 완전히 삭제되지 않은 데이터가 누적되어 비용이 발생하고 있지는 않은지 등) 또한 데이터 액세스 빈도 및 속도에 따라 비용을 최적화할 수 있습니다.

5. Cost Usage Report 활성 여부 및 비용 분석 관련 체계 구성

AWS Cost & Usage Report(CUR)는 AWS 사용량을 추적하고 계정과 관련된 예상 요금을 제공하며, 계정에 대한 가장 포괄적인 비용 및 사용량 데이터를 검토하고 항목화하며 정리할 수 있습니다.

Report를 활성화하면 시간, 일 또는 월, 제품 또는 제품 리소스 또는 직접 정의한 태그별로 비용을 세분화하는 비용 보고서가 하루에 한번씩 S3에 업데이트 됩니다.

6. IAM Role 등 계정에 대한 Permission 구성 체계 확인

AWS IAM 역할과 계정을 관리하여 허가받은 인원만이 리소스를 생성할 수 있도록 권한을 제어해야합니다.

node의 버전 관리를 위해 nvm을 설치하고 여러 버전의 node를 사용하는 방법에 대한 포스팅입니다.

Node js 설치

sudo apt install nodejs
sudo apt install nodejs-legacy 

#node 버전 확인
node -v

nodejs-legacy 는 우분투 버전이 16이하에서 설치가 필요하지만 18이상에서는 설치 필요없음

NVM 설치

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

#nvm 버전 확인
nvm -v 

버전 목록 확인

nvm list

원하는 버전의 노드를 다운로드

nvm install <버전>

노드 버전 변경

nvm use <버전>

AWS의 ElastiCache for Redis를 사용하면서 발생하는 문제점과 해결 방안

1. AWS ElastiCache for Redis란? AWS 에서 분산된 인 메모리 데이터 스토어 또는 캐시 환경을 손쉽게 설정, 관리 및 확장할 수 있는 웹 서비스입니다.

2. 주요 개념 및 기능 ```

• 캐시 노드 실패에서 자동 감지 및 복구를 합니다.

• 복제를 지원하는 Redis 클러스터에 있는 읽기 전용 복제본으로 실패한 기본 클러스터를 조치하는 다중 AZ입니다.

• Redis(클러스터 모드 활성화됨)는 최대 500개 샤드로의 데이터 분할을 지원합니다.

• Redis 버전 3.2 이상에서는 모든 버전이 전송 중 데이터 암호화와 인증으로 저장된 데이터 암호화를 지원합니다. 이 지원을 통해 HIPAA 규정 준수 애플리케이션을 구축할 수 있습니다.

• 내결함성 향상을 위한 노드 및 클러스터의 유연한 가용 영역 배치.

• Amazon EC2, Amazon CloudWatch, AWS CloudTrail 및 Amazon SNS 같은 다른 AWS 서비스와의 통합. 이러한 통합을 통해 고성능과 높은 보안성을 갖춘 관리되는 인메모리 캐싱 솔루션을 제공합니다.

• ElastiCache for Redis는 백업, 소프트웨어 패치, 자동 장애 감지 및 복구를 관리합니다.

• 필요할 때 자동화된 백업을 수행하거나 고유한 백업 스냅샷을 수동으로 만들 수 있습니다. 이러한 백업을 사용하여 클러스터를 복원할 수 있습니다. ElastiCache for Redis 복원 프로세스는 안정적이고 효율적입니다.

• 기본 인스턴스 및 문제 발생 시 장애 조치를 수행할 수 있는 동기식 보조 인스턴스에서 가용성을 높일 수 있습니다. 읽기 전용 복제본을 사용하여 읽기 조정을 높일 수도 있습니다.

• AWS Identity and Access Management를 사용하여 사용자 및 권한을 정의하여 ElastiCache for Redis 클러스터에 대한 액세스를 제어할 수 있습니다. 클러스터를 Virtual Private Cloud(VPC)에 넣어 클러스터를 보호할 수도 있습니다.

• Redisdyd 글로벌 데이터 스토어 기능을 사용하면 AWS 리전 간에 빠르고 안정적이며 안전한 완전 관리형 복제를 수행할 수 있습니다. 이 기능을 사용하면 ElastiCache for Redis에 대한 리전 간 읽기 전용 복제본 클러스터를 생성하여 AWS 리전 간에 지연 시간이 짧은 읽기 및 재해 복구를 수행할 수 있습니다.

• 데이터 계층화는 데이터를 메모리에 저장하는 것 외에도 각 클러스터 노드에서 저렴한 SSD(solid state drives)를 활용하여 Redis 워크로드에 대한 가격 대비 성능 옵션을 제공합니다. 데이터 계층화는 전체 데이터 세트의 최대 20%까지 정기적으로 액세스하는 워크로드와 SSD에서 데이터에 액세스할 때 추가 지연 시간을 허용할 수 있는 애플리케이션에 이상적입니다. 자세한 내용은 섹션을 참조하세요데이터 계층화

3. 최근 Redis를 사용하면서 발생한 문제 클러스터모드가 활성화된 redis에 아래와 같이 접근해서 명령어 수행하면 간혹 readonly 오류가 발생하는 경우가 있음

   redis-cli -h [구성엔드포인트] -c 

   여러번 접근을 하면 어떨때는 정상적으로 명령어가 수행되고 어떨때는 오류가 발생하는 경우가 있음

   (error) READONLY You can‘t write against a read only replica.

   AWS 기술팀에 확인 해보면 접근 명령어(redis-cli -h [redis 구성 엔드포인트] -c)의 경우 클러스터의 모든 노드(레플리카 포함)에서 실행되어 레플리카 노드에서 ReadOnly 오류가 수신되는 것으로 확인되며, 명령어는 각 샤드의 마스터 노드에서만 실행해야 정상적인 동작이 가능한것을 확인

해결 방안으로는 cluster nodes 또는 cluster slots 명령어로 마스터노드의 정보를 획득&접근하여 개별적으로 명령어를 실행하는 것!!

DevOps의 기본인 CI/CD를 AWS의 서비스를 이용하여 구축하는 방법에 대해서 작성했습니다. 해당 포스팅에서는 빌드를 진행하지 않았기 때문에 CodeBuild는 사용하지 않았습니다.

시나리오 CodeCommit에 테라폼 소스를 업로드 하고 VSCode와 연동하여 push진행 하면 인스턴스에 자동으로 배포

1. 사전 준비 EC2인스턴스를 생성하고 Terraform, codedeploy-agent 를 인스턴스에 설치

   Terraform 설치

   wget https://releases.hashicorp.com/terraform/1.0.7/terraform_1.0.7_linux_amd64.zip
   unzip terraform_1.0.7_linux_amd64.zip
   sudo mv terraform /usr/bin/

CloudDeploy-Agent 설치

sudo apt install ruby -y
wget https://aws-codedeploy-ap-northeast-2.s3.amazonaws.com/latest/install
chmod 755 install
sudo ./install auto

sudo service codedeploy-agent start

2. 사전에 준비된 인스턴스에 IAM Role 생성하여 연결 필요 정책 : AmazonEC2RoleforAWSCodeDeploy, AmazonVPCFullAccess

3. AWS CodeCommit 리포지토리 생성

CodeCommit을 로컬 VScode와 연동 하는 방법

1-1) IAM 사용자 생성 후 CodeCommit 접근을 위한 권한 추가

필요 정책 : AWSCodeCommitPowerUser

1-2) 보안 자격 증명에서 https 자격증명 생성

자격 증명 생성 하면 id랑 패스워드 나옴 잘 저장해두기

1-3) CodeCommit에서 URL 복제

1-4) VScode에서 git 연동하기에 해당 URL 입력하고 ID,PW 입력하면 연동 완료

4. 리포지토리에 파일 추가

vpc 생성하는 코드인 vpc.tf

provider "aws" {
  region = "ap-northeast-1"
}

variable "vpc_cidr" {
  description = "CIDR for the VPC"
  default     = "10.166.0.0/16"
}

variable "tag" {
  default     = "Terraform"
}

resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true
  tags = {
    Name = "${var.tag}-VPC"
  }
}

CodeDeploy 실행시키는 appspec.yml 코드

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/terraform/

hooks:
  AfterInstall:
    - location: /scripts/run_terraform.sh
      timeout: 300
      runas: root

→ files 부분은 리포지토리 소스를 서버의 어느 디렉토리에 복사할지 경로부분

→ hooks 부분은 리포지토리에서 실행시킬 스크립트 작성해주는 부분

/home/ubuntu/terraform/ 경로에 복사된 파일들을 실행시키는 terraform 명령어를 스크립트(run_terraform.sh)에 작성해서 추가함

terraform -chdir=/home/ubuntu/terraform/ init
terraform -chdir=/home/ubuntu/terraform/ apply -auto-approve

5. CodeDeploy 애플리케이션 생성

먼저 배포를 진행할 역할을 추가 생성함

필요 정책 : AWSCodeDeployRole

위에서 생성한 역할 입력하여 애플리케이션 생성

6. CodePipeline 생성

위에 생성한 CodeCommit과 CodeDploy를 이어주는 파이프라인을 생성하여 자동으로 배포가 이루어질 수 있도록 함

7. 로컬에서 소스 push 해주면 자동으로 CodePipeline통해서 Deploy되고 VPC 생성됨

AWS를 이용한 간단한 CI/CD 테스트 였습니다.

여러 서버에서 동일한 스크립트를 실행해야하는 상황에서 Ansible을 이용하여 간단하게 진행하는 방법을 설명하려고 합니다.

1. Ansible 설치 간단하게 apt install로 설치

   sudo apt install ansible

   

2. 접근하고자 하는 서버의 정보를 hosts 파일에 ip또는 host를 등록

3. 호스트 서버에 접근을 위한 설정 3-1. public key 생성 아래 명령어로 퍼블릭키를 생성하고 ./ssh 경로에 생성된 id_rsa의 값을 접근하고자 하는 호스트 서버의 authorized_keys에 등록한다

   ssh-keygen -t rsa

   

3-2. private key 지정 AWS의 EC2접근을 위해 패스워드 설정을 하는 경우도 있지만 보안상 pem키를 이용하는 경우가 많음 그럴때는 ansible_ssh_private_key_file 을 이용해서 경로를 지정함

[testsvr:vars]
ansible_ssh_private_key_file = ~/test.pem

[testsvr]
10.10.6.144

4. playbook 작성 로컬에 존재하는 스크립트파일을 리모트 서버로 가져가서 실행하는 playbook을 yaml 파일로 작성

• name: "Script Start" hosts: all become: yes become_method: sudo vars: local_path: /home/ubuntu remote_path: /home/ubuntu tasks:
  • name: "Script Send" copy: src: "{{ local_path }}/script.sh" dest: "{{ remote_path }}/script.sh" owner: ubuntu group: ubuntu mode: '0755'
  • name: "Script run" ignore_errors: yes shell: cmd: |

    {{ remote_path }}/script.sh 

5. playbook 실행

   ansible-playbook -i <hosts 경로> <playbook 파일>

위와 같이 작성하고 실행하면 여러서버에서 한번에 스크립트를 실행 시킬 수 있습니다.

두번째 포스팅은 추출한 pdf파일을 드라이브에 자동으로 업로드 하기 위한 인증 설정 방법과 업로드하는 간단한 파이썬 스크립트에 관한 포스팅입니다.

1. 구글 자격 증명 설정 먼저 GCP에 접속하여 새프로젝트를 생성하고 OAuth 동의 화면을 구성

2. API 라이브러리에서 Google Drive API 사용

3. 사용자 인증 정보 만들기에서 OAuth 클라이언트 ID 생성 로컬PC인 경우 - 데스크톱 클라이언트 리눅스 서버의 경우 - TV클라이언트 생성한 Client 인증 정보가 들어있는 JSON파일은 잘 가지고 있어야함

4. 구글 드라이브에 파일을 업로드하는 파이썬 스크립트 /home/ubuntu/daily_report/daily_infra_report/ 경로에 전날 일자를 이름으로 가진 pdf파일을 똑같이 전날 일자를 이름으로 내 드라이브에 업로드하는 스크립트

   #!/usr/bin/python3
   

from googleapiclient.discovery import build from httplib2 import Http from oauth2client import file, client, tools from datetime import date, timedelta

yesterday = date.today() - timedelta(1)

try : import argparse flags = argparse.ArgumentParser(parents=[tools.argparser]).parse_args() except ImportError: flags = None

SCOPES = 'https://www.googleapis.com/auth/drive.file' store = file.Storage('storage.json') creds = store.get()

if not creds or creds.invalid: print("make new storage data file ") flow = client.flow_from_clientsecrets('/home/ubuntu/daily_report/<다운 받은 자격증명파일.json>', SCOPES) creds = tools.run_flow(flow, store, flags) if flags else tools.run(flow, store)

DRIVE = build('drive', 'v3', http=creds.authorize(Http()))

FILES = ( ('/home/ubuntu/daily_report/daily_infra_report/' + yesterday.strftime( 'daily_infra_report_'+'%Y%m%d'+'.pdf')), )

folder_id = '<내 드라이브 URL중 마지막 암호화된 부분>'

for file_title in FILES : file_name = file_title metadata = {'name': yesterday.strftime( 'daily_infra_report_'+'%Y%m%d'+'.pdf'), 'parents' : [folder_id], 'mimeType': None }

res = DRIVE.files().create(body=metadata, media_body=file_name).execute()
if res:
    print('Uploaded "%s" (%s)' % (file_name, res['mimeType']))

```

이러한 스크립트를 crontab에 등록해두면 매일 인프라 현황을 수동으로 체크하지 않고 보고서로 빠르게 확인이 가능하니 걱정 없습니다!

Grafana 대시보드를 pdf 형식으로 추출 하여 구글 드라이브에 자동으로 업로드하는 방법에 대해 설명하려고 합니다. 그중 첫번째 포스팅에서는 Grafana 대시보드를 추출하는 방법에 대해서 작성하였습니다.

1. Grafana 대시보드를 pdf 형식으로 추출하기 위해서 grafana-reporter를 설치 Grafana reporter는 그라파나 대시보드를 pdf 형식으로 추출하는 도구로 아래 사이트에서 자세한 사항 확인 가능 (https://github.com/IzakMarais/reporter)

설치 전 필요사항

• pdflatex
• golang
• grafana-image-renderer

#pdf 파일을 위한 패키지 설치
sudo apt-get install texlive-full

#grafana-reporter 설치
go get github.com/IzakMarais/reporter/...
go install -v github.com/IzakMarais/reporter/cmd/grafana-reporter

2. Grafana apikey 생성

3. 특정 대시보드를 pdf로 추출

   ./grafana-reporter -grid-layout=1 -cmd_enable=1  -cmd_o -cmd_dashboard <dashboardUID> -cmd_apiKey <apikey>

   grafana-reporter 참고 옵션 ``` grafana-reporter --help

-cmd_apiKey string Grafana api key. Required (and only used) in command line mode. -cmd_apiVersion string Api version: [v4, v5]. Required (and only used) in command line mode, example: -apiVersion v5. (default "v5") -cmd_dashboard string Dashboard identifier. Required (and only used) in command line mode. -cmd_enable Enable command line mode. Generate report from command line without starting webserver (-cmd_enable=1). -cmd_o string Output file. Required (and only used) in command line mode. (default "out.pdf") -cmd_template string Specify a custom TeX template file. Only used in command line mode, but is optional even there. -cmd_ts string Time span. Required (and only used) in command line mode. (default "from=now-3h&to=now") -grid-layout Enable grid layout (-grid-layout=1). Panel width and height will be calculated based off Grafana gridPos width and height. -ip string Grafana IP and port. (default "localhost:3000") -port string Port to serve on. (default ":8686") -proto string Grafana Protocol. Change to 'https://' if Grafana is using https. Reporter will still serve http. (default "http://") -ssl-check Check the SSL issuer and validity. Set this to false if your Grafana serves https using an unverified, self-signed certificate. (default true) -templates string Directory for custom TeX templates. (default "templates/")

```

구글 드라이브 업로드를 위한 자격증명 생성은 다름 포스팅에서 이어서..

참고 사이트

• https://github.com/IzakMarais/reporter

Instance Scheduler을 이용하여 특정 시간 동안만 인스턴스를 이용하고 해당 시간 이외에는 인스턴스가 종료되도록 설정하여 비용효율적으로 인스턴스를 관리하는 방법

1. 인스턴스 스택 생성

• https://docs.aws.amazon.com/solutions/latest/instance-scheduler/deployment.html#step1 사이트에서 기본 템플릿 다운

2. 스택 이름 지정

3. Time Zone 설정 및 스케쥴 동작 시간 설정, 태그 입력

4. 스택 옵션 설정은 별도 추가 필요하지 않음

5. [AWS CloudFormation에서 IAM 리소스를 생성할 수 있음을 승인합니다.] 체크 후 생성 진행

6. 태그 이용하여 중지된 인스턴스를 실행하는 테스트( DynamoDB의 ConfigTable 에서 Type 확인)

7. 테스트 인스터스에 태그를 추가 (키 -> Schedule  / 값 - > running)

8. 스택 설정 중 Frequency 항목에서 설정한 5분 단위로 인스턴스를 확인하며 중지되있을경우 인스턴스를 시작시킴

9. 특정 시간대 지정 인스턴스 중지/실행 테스트

• DynamoDB의 테이블에서 ConfigTable 의 Type -> period, Name -> office-hours 을 선택한 후 작업에서 복사하여 복제본인 office-hours-test 를 생성

10. 생성된 복제본을 수정

• 인스턴스를 실행하고 싶은 시간과 요일을 설정

11. Type -> schedule, Name -> uk-office-hours 을 선택한 후 복제본 생성

12. timezone을 Asia/Seoul 설정 후 periods 에 위에 생성한 office-hours-test를 추가하여 kr-ec2-test schedule을 생성

13. 생성한 schedule 을 적용한 인스턴스에 추가

추가적으로 확실하게 관리하기 위해서는 인스턴스를 생성할때 필수적으로 태그를 추가해야 생성이 가능하게 설정하는것이 좋음!!

블록체인이란..

• 누구나 열람할 수 있는 디지털 장부에 거래 내역을 투명하게 기록하고, 여러 대의 컴퓨터에 이를 복제해 저장하는 분산형 데이터 저장 기술을 뜻함
• 가상화폐뿐 아니라 어떠한 데이터를 거래할 때 그 모든 기록들이 컴퓨터에 저장되는데, 내 컴퓨터 뿐만 아니라 나와 거래하는 사람들의 컴퓨터에도 동시에 똑같이 데이터가 저장되고 데이터에 변동사항이 생기면 참여하는 모두에게 동시에 업데이트가 발생함 그렇기 때문에 블록체인은 위조나 변조가 어렵다
• 특정 중앙기관에서 거래에 대한 내용을 관리하는 것이 아니라 참여하는 모든 사람들이 검증과 승인, 합의 등의 활동을 하며 해당 거래가 유효한지를 판단하는 '탈중앙화'의 특성이 있음
• 블록체인은 크게 아무나 참여할 수 있는 퍼블릭블록체인, 허가받아야 참여할 수 있는 프라이빗 블록체인으로 나누어짐

용어

1. 디앱(DApp) : 디앱이란 Decentralized Application의 약자로 , 이더리움, 큐텀, 이오스 같은 플랫폼 코인 위에서 작동하는 탈중앙화 분산 애플리케이션을 말한다.

2. 퍼블릭 블록체인(Public Blockchain) : 공개형 블록체인이라고 불리기도 하며, 전 세계의 누구나 모두 읽고 거래 정보를 발송하고 거래가 유효한지 확인할 수 있으며, 누구나 합의 과정의 블록체인에 참여할 수 있다. 통상적으로 완전한 탈중앙화 시스템으로 여겨진다.

3. 프라이빗 블록체인(Private Blockchain) : 폐쇄형 블록체인이라고 불리기도 하며, 기관 또는 조직에서 권한을 통해 관리되는 블록체인을 말한다. 이 해당 네트워크에 참여하기 위해서는 고유의 인증 방식을 통과해야 한다.

4. 컨소시엄 블록체인(Consortium Blockchain) : 미리 선정된 노드에 의해서 제어되는 퍼블릭과 프라이빗 블록체인 사이의 반 중앙형 블록체인이다. 미리 선정된 기관이 노드를 한 개씩 운영하고 각 기관의 노드 간 동의가 일어나야 거래가 생성된다. 블록체인의 기록 열람 권리는 처블릭 블록체인처럼 대중에게 부여할 수 도 있지만, 특정 기관에서만 제공하거나 API를 통해 특정 인원에게만 공개할 수 도 있다.

5. 토큰(Token) :  독립된 블록체인 네트워크(메인넷)가 아닌 이더리움과 같은 플랫폼을 이용하여 발생할 수 있는 암호화폐이다. 독립된 블록체인 네트워크를 소유한 경우에는 코인으로 부르며,비트코인,이더리움,큄텀,스팀 등이 있다 코인과 같이 메인넷 시스템을 한번에 구축하는 것은 어렵기 때문에 먼저 이더리움과 같은 플랫폼 위에 토큰을 발행한 뒤 개발을 통하여 코인으로 전환하게 된다.

6. 메인넷(Mainnet) : 메인넷은 기존에 존재하는 플랫폼에 종속되지 않고, 독립적인 플랫폼으로 새로운 생태계를 구성하고 자체 지갑을 생성하는 것이다. 안정성이 검증된 메인넷을 같는 것은 난이도가 상당하며 그만큼의 기술력을 필요로 한다.

7. 트랜잭션(Transaction) : 암호화폐를 송금하는 이체 거래 과정에서 전송되는 서명된 정보를 의미하며 하나의 문자열로 생성된다.

8. 합의 알고리즘(Consensus Algorithm) : 생성된 블록의 유효성을 검토하여 블록체인에 반영여부를 의사결정하는 방식을 의미한다. 대표적으로 작업증명(PoW),지분증명(PoS),위임증명(DPoS) 방식이 있다.

9. 작업 증명 (PoW : Proof of Work) : 컴퓨터 연산 작업을 수행하여 블록체인에 기여하는 대가로 보상을 받는 방식이다. 연산을 위해서는 성능이 우수한 장비를 필요로 한다.P2P 네트워크에서 시간과 비용을 들여 수행된 컴퓨터 연산 작업을 신뢰하기 위해 참여당사자 간에 간단히 검증하는 방식이다.

10. 지분 증명 (PoS : Proof  of Stake) : 노드에 기여하는 대가로 보상을 받는 방식이다. 채굴파워가 아닌 지분에 따라 정당한 의사 결정이 이루어지며 채굴 파워에 의한 중앙화를 방지하며 에너지 낭비를 최소화한 친환경적인 방식이다. 지분에 비례한 공정한 보상 지급을 통해 작업 증명 방식의 단점을 보완한다.

11. 위임 증명(DPoS : Delegated Proof of Stake) : 자격을 갖춘 선택된 증인이 참여자들이 보유하고있는 지분을 위임받아 블록을 검증하는 방식이다. 이중 채굴과 그라인딩 어택에 대해 내성을 갖는 합의 프로토콜이라 평가받는다. 모든 참여자가 블록을 검증하는 것이 아닌 소수의 중인만이 블록을 검증하기 때문에 증명 속도가 빠르다는 장점이 있다.

12. 권위 증명 (PoA : Proof of Authority) : 신분에 기반한 합의를 통해서 거래를 제공하는 블록체인과 함께 사용 되는 알고리즘이다. 지분증명에서 수정된 합의 메커니즘 방식으로 행위자의 영향력을 무시하고 동작하며 개인의 신원 유효성 검증 능력을 우선시 한다. 권위 증명은 참가자가 네트워크를 확인하고 보상을 받을 권리를 대신하여 개인의 신원을 확인할 수 있다.

RDS MariaDB에서 Aurora Mysql로 Migration하는 방법

AWS RDS에서 Mysql을 사용하는 경우 스냅샷 복원 등 간편한 방법으로 Aurora로 마이그레이션할 수 있지만 MariaDB에서는 해당 방법들이 지원되지 않음

그렇기 때문에 단절을 최소화하고 가장 안전하게 데이터를 이전하기 위해서는 MariaDB의 데이터를 mysqldump 유틸리티를 이용해서 덤프를 생성하고 Aurora에 덤프 데이터를 이전한 후에 두 DB를 replication 설정하여 데이터를 동기화하는 방법이 최선임

AWS DMS를 이용한 방법도 있지만 DMS는 데이터를 마이그레이션하는데 필요한 데이터베이스 개체 만을 만들고 이러한 개체에는 테이블과 기본 키가 포함되어있음 즉, 기본적인 데이터만 마이그레이션되어지는 것이고 전체 스키마를 마이그레이션하려면 먼저 대상에서 views, foreign key constraints, stored procedures , triggers 등과 같은 다른 데이터베이스 개체를 미리 만들고 DMS를 사용하여 데이터를 마이그레이션해야 함

그렇기 때문에 auto_increment 속성과 같은 설정들을 유지하기 위해서는 기본 유틸리티인 mysqldump를 이용한 데이터 이전이 최선의 방법임

mysqldump 이전 방법

1. MariaDB에 테스트용 DB 생성 (auto_increment 속성 포함)

2. MariaDB의 데이터를 mysqldump를 이용해서 덤프를 생성

   # mysqldump -u [DBUSER] -p -h [DBENDPOINT] [DBNAME] > mariadbdump.sql

   

3. Aurora에 동일한 이름의 DB를 생성하고 해당 DB에 덤프 데이터를 이전함

   # mysq -u [DBUSER] -p -h [DBENDPOINT] [DBNAME] < mariadbdump.sql

   

4. Aurora에 데이터 및 속성이 정상적으로 이전되었음을 확인

Replication 설정 방법

<마스터 설정(MariaDB)>

1. 마이그레이션 기간을 완료하기 전에 binlog 파일이 삭제되지 않도록 마스터 인스턴스에서 binlog 보존을 설정해야 함(예를 들어: 보존을 1일로 설정)

   MariaDB> CALL mysql.rds_set_configuration('binlog retention hours', 24);

   

2. replication용 사용자 생성

   MariaDB> CREATE USER '[USER]'@'%' IDENTIFIED BY '[PASSWORD]';

   

3. 생성한 사용자에게 외부접근을 허용하는 권한 부여

   MariaDB> GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO '[USER]'@'%' IDENTIFIED BY '[PASSWORD]';

   

4. 사용자가 정상적으로 생성 되었음을 확인

5. MariaDB의 마스터 정보를 확인하고 기록해둠

   MariaDB> show master status\G

   

<슬레이브 설정(Aurora)>

1. Aurora에서 복제를 중지

   mysql> CALL mysql.rds_stop_replication;

   

2. MariaDB의 마스터 정보를 이용하여 슬레이브를 구성함 (Port, User, PW, bin_log, Position) ``` mysql> CALL mysql.rds_set_external_master(

-> '[DBENDPOINT]', -> 3306, -> [USER], -> [PW], -> [bin_log], -> [Position], -> 0);

![](https://images.velog.io/images/jiyeon_hong/post/bad91a40-1441-4c39-a03e-359dece07a11/image.png)

3. Aurora에서 복제를 시작

mysql> CALL mysql.rds_start_replication;

![](https://images.velog.io/images/jiyeon_hong/post/7e22b288-bbb6-423b-8c23-309c2fad48cd/image.png)

4. replication이 정상적으로 설정 되었음을 확인

mysql> show slave status\G

```

Web Deploy를 이용한 IIS 마이그레이션 방법

1. 마이그레이션하고자 하는 A, B서버 모두에서 MSDeploy를 설치

2. A서버의 hosts파일에 B서버 ip와 호스트등록 후 저장

3. A서버의 CMD창에서 Web Deploy의 설치 경로로 (C:\Program Files\IIS\Microsoft Web Deploy V3)이동 후 아래 명령어 실행

MSDeploy.exe -verb:sync -source:metakey=lm/w3svc/4 -dest:metakey=lm/w3svc/2,computerName=bws-db-p01,username=bebeadmin,password=1Bebeelql@%*) -disableLink:ContentExtension -enableLink:AppPoolExtension

lm/w3svc/4 = A서버 IIS에있는 복사하고 싶은 웹서비스의 ID값 lm/w3svc/2 = A에서 복사한 ID를 B서버 IIS에 붙여 넣을 ID값

🔸정상적인 통신을 위해서는 A,B서버의 80포트가 열려 있어야 함

CloudFront의 Geo-location(지리적 제한)이용한 허용외 지역에 대한 에러코드 반환 구현

1. 이미지와 간단한 html파일이 업로드된 S3를 준비

2. S3 버킷을 오리진으로 CloudFront 생성

3. Route53에 새로운 도메인을 생성하고 레코드값에 CloudFront를 바라보게 설정

4. CloudFront의 CNAME 설정과 SSL 설정 (CloudFront에서 ACM을 이용하기 위해서는 무조건 북부버지니아 리전에 인증서가 존재해야함)

5. CloudFront의 지리적 제한 설정

6. Blacklist 설정으로 한국을 제외한 모든국가에서의 접속을 허용

7. 허용되지 않은 사용자의 요청에 반환되는 에러페이지를 설정

8. 한국 ip로의 접근 시 확인되는 에러 메시지

9. Whitelist를 이용하여 한국을 제외한 국가에서의 접근을 차단하도록 설정

10. 한국에서의 정상접속 확인

터널베어 VPN을 이용하여 일본ip를 통한 사이트 접속시 접속 실패 확인