글쓰는 감자

환경: (Amazon Linux 2023, Apache) public EC2  + EFS 구성

AMI 생성

EC2 내부 접속 후 아래 명령어를 통해 Apache 서버로 구성한다.

yum install httpd    # Apache 웹 서버 설치
systemctl start httpd   # Apache 서버 시작
systemctl status httpd  # 상태 확인
systemctl enable httpd  # 부팅 시 자동 시작 설정

http://public-ip/ 로 접속하면 기본 Apache Server 화면이 보이면 된다.

dnf install -y httpd amazon-efs-utils inotify-tools    # 필요한 패키지 설치
sudo mkdir -p /data    # EFS를 마운트할 디렉토리 생성
sudo mount -t efs -o tls fs-XXXX:/ /data    # EFS 마운트
df -hT | grep efs    # EFS 마운트 확인

EFS와 EC2 연결을 위해 명령어를 입력한다.

/data 경로를 생성하고 해당 폴더와 EFS를 연결했다.

fs-xxxx:/ /data efs _netdev,tls 0 0    # /etc/fstab에 추가

/etc/fstab 파일에 아래 명령어를 입력해 서버가 재부팅되어도 EFS가 자동으로 마운트 될 수 있게 추가한다.

sudo vi /etc/httpd/conf/httpd.conf

Apache 웹 서버는 기본적으로 /var/www/html을 DocumentRoot로 사용하지만, 이를 /data로 변경한다.

DocumentRoot "/data"
<Directory "/data">
    AllowOverride None
    Require all granted
</Directory>

파일에서 DocumentRoot를 /data로 변경하고, 아래와 같이 설정을 수정한다.

이후 /data/index.html 파일에 원하는 HTML 파일을 넣어 테스트하면 된다.

위의 설정을 완료한 후, EC2 인스턴스를 AMI로 생성한다. 생성된 AMI는 이후 Auto Scaling Group(ASG)에서 사용할 템플릿으로 활용될 예정!

ASG(AutoScaling Group) 생성

위에서 생성한 ami를 기반으로 시작템플릿을 구성한다.

#!/bin/bash
# EFS 마운트
mkdir -p /data
mount -t efs -o tls fs-xxxx:/ /data

# Apache 시작
systemctl start httpd
systemctl enable httpd

시작템플릿 구성할 때 UserData에 위의 코드를 삽입한다.

생성한 시작템플릿을 바탕으로 ASG 를 생성한다.

ASG의 인스턴스 중 하나에서 /data/index.html 파일을 수정하면, 다른 인스턴스들에도 해당 변경 사항이 반영되는 것을 확인할 수 있다. 이는 EFS에 파일을 저장하고 있기 때문에 모든 인스턴스에서 동일한 파일을 공유하고 있다는 걸 알 수 있다!

이 방식은 Apache 웹 서버를 EFS와 연동하여 파일을 자동으로 반영하는 방법을 보여준다.

CI/CD 환경을 구축하기 어려울 때, 이 방법을 활용하면 유용할 것이다.

하지만 실제 서비스 환경에서는 CI/CD 파이프라인을 구축하여 소스 코드 변경 사항을 자동으로 배포하는 시스템을 구현하는 게 제일 베스트일 것 같다!

▶ ALB(Application Load Balancer)의 타겟 그룹을 활용하여 Hot / Standby 구조를 구현하는 것이 목표

ASG(Auto Scaling Group)에서 관리하는 EC2 인스턴스(Hot)와 Standby 인스턴스를 운영하면서, 장애 발생 시 트래픽을 자동으로 Standby로 전환하는 걸 확인하는 테스트하고자 한다.

CloudWatch Alarm 설정

ALB의 타겟 그룹 헬스 체크 기준에 따라 특정 인스턴스가 UnHealthy 상태가 되면, UnHealthyHostCount 값이 증가하고 CloudWatch Alarm이 트리거 된다. 즉, ASG의 하나의 인스턴스라도 Unhealthy 상태면, 경보가 울린다.

CloudWatch Alarm의 작업 설정은 Alarm / OK 상태 모두 SNS 토픽으로 트리거되게 잡았다.

(여기서 SNS Topic 생성이 필요)

Lambda 생성

import boto3
import json

elb_client = boto3.client('elbv2')

def lambda_handler(event, context):
    # SNS 메시지에서 이벤트 추출
    sns_message = event['Records'][0]['Sns']['Message']
    event_detail = json.loads(sns_message)
    
    # ALB 리스너 ARN과 대상 그룹 ARN
    listener_arn = 'your_arn'
    primary_target_group_arn = 'your_arn'
    standby_target_group_arn = 'your_arn'
    
    # SNS 메시지에서 상태 추출
    state = event_detail['NewStateValue']
    
    if state == 'ALARM':
        # ALARM 상태일 때 Standby로 트래픽 분산 (50:50 or 100:0)
        action = {
            'Type': 'forward',
            'ForwardConfig': {
                'TargetGroups': [
                    {
                        'TargetGroupArn': primary_target_group_arn,
                        'Weight': 20  # 기존 대상 그룹을 일부 유지
                    },
                    {
                        'TargetGroupArn': standby_target_group_arn,
                        'Weight': 80  # 대부분의 트래픽을 Standby로 전환
                    }
                ]
            }
        }
        response_message = 'Listener rule updated: 80% traffic to standby target group'
        
    elif state == 'OK':
        # OK 상태일 때 다시 Primary Target Group으로 복원
        action = {
            'Type': 'forward',
            'ForwardConfig': {
                'TargetGroups': [
                    {
                        'TargetGroupArn': primary_target_group_arn,
                        'Weight': 100  # 다시 Primary Target Group으로 복원
                    },
                    {
                        'TargetGroupArn': standby_target_group_arn,
                        'Weight': 0  # Standby로 가는 트래픽 제거
                    }
                ]
            }
        }
        response_message = 'Listener rule updated: 100% traffic to primary target group'
    
    try:
        # ALB 리스너 규칙 업데이트
        response = elb_client.modify_listener(
            ListenerArn=listener_arn,
            DefaultActions=[action]
        )
        
        print("Response:", response)
        
        return {
            'statusCode': 200,
            'body': response_message
        }
    except Exception as e:
        print("Error:", str(e))
        return {
            'statusCode': 500,
            'body': 'Error updating listener rule'
        }

위 코드를 넣어주고 Deploy 버튼을 눌러 배포해준다.

(가중치는 원하는대로 조정하면 된다.)

Lambda IAM 역할은

AmazonSNSFullAccess, CloudWatchEventsFullAccess, ElasticLoadBalancingFullAccess 의 정책을 연결해준다.

( Lambda 실행 후 CloudWatch Logs에서 로그 확인 (/aws/lambda/{LambdaFunctionName} 경로) ← 해당 로그에서 에러 시 확인하기 좋다.)

Lambda 트리거 설정

SNS Topic을 Lambda가 구독해 트리거 설정을 해준다.

Hot/Standby Test

지금 설정해둔 ALB의 리스너 규칙을 보면, 아래 이미지와 같다.

 asg-tg의 인스턴스를 unhealthy로 만들어주면, CloudWatch Alarm이 Alarm 경보를 보낸다.

아래 이미지와 같이 가중치가 자동으로 변하며, standby-sg 쪽에 트래픽이 분산된다.

다시 asg-tg의 인스턴스를 healthy 상태로 만들어주면, CloudWatch Alarm 상태가 OK 상태로 바뀌고 100 / 0의 가중치로 돌아올 것이다.

위 방식은 나의 머릿 속에서 의식의 흐름대로 적었을 뿐... 더 좋은 방식이 있을 수 있다🙄

급증하는 트래픽에 ASG 인스턴스 늘어나는 속도가 트래픽 속도를 못 따라 잡을 때 대응 방법으로 생각해본 것!

NAS 란

참고: https://aws.amazon.com/ko/what-is/nas/

팀원들이 네트워크를 통해 효과적으로 협업할 수 있도록
데이터를 지속적으로 사용할 수 있게 하는
파일 전용 스토리지 디바이스

•  통신 프로토콜: IP + TCP
  • IP에 파일 데이터를 전송할 주소를 얻어 TCP가 데이터를 패킷으로 결합해 네트워크를 통해 패킷 전송
• 파일 형식 프로토콜
  • NFS: Linux, Unix (모든 하드웨어, OS 또는 네트워크 아키텍처에서 작동)
  • SMB: Microsoft Windows
  • AFP: MacOS의 Apple 디바이스

일반적으로 생각하는 시놀로지와 같은 NAS 구성은 아래의 방법들로 구성할 수 있습니다.

FSx 활용

참고: https://aws.amazon.com/ko/blogs/storage/accessing-smb-file-shares-remotely-with-amazon-fsx-for-windows-file-server/

Amazon FSx for Windows File Server는 완전한 네이티브 Windows 파일 시스템이 지원하는 완전 관리형 Microsoft Windows 파일 서버를 제공합니다.

AD를 통해 사용자의 권한을 관리합니다. 이는 AWS Managed 서비스를 활용해도 좋고 기존의 Windows 환경 위에 구성된 자체 AD 서버를 활용해도 좋습니다. (단, AD 서버를 관리할 수 있어야 합니다!)

Storage Gateway는 캐시 효과를 위한 부가적인 서비스로 선택적 서비스라고 생각하시면 됩니다.

• 장점
  • SMB client에서 접속하는 NAS와 제일 비슷한 환경을 제공해준다.
  • 아무래도 VPN 접속 등 내부 네트워크를 통해 접근이 가능하다.
• 단점
  • 비싸다.
  • AD 사용을 위한 기술력이 필요하다.
  • STGW를 위한 온프렘 서버가 필요하다.

Workdocs 활용 (2025.04.25 지원 종료 - 생성 불가)

참고: https://blog.kyobodts.co.kr/2023/08/01/hands-on-aws-workdocs-site-%EC%99%80-drive-%EA%B5%AC%EC%84%B1%ED%95%98%EA%B8%B0/

Amazon WorkDocs는 구글 드라이브와 비슷한 AWS에서 개발한 SaaS 서비스 라고 생각하시면 됩니다.

실제 파일들을 올리면 S3에 저장되게 되고 WorkDocs는 이를 파일 스토리지 처럼 보이게 만들어 줍니다.

위의 FSx와 달리 HTTPS 통신을 하게 되어 업로드/다운로드를 할 때 인터넷 통신을 하게  됩니다.

관리자가 사용자를 생성해 전달하면 해당 사용자를 위한 저장 공간이 생기고 사용자는 해당 공간에 ID/PW로 접속하게 됩니다.

• 장점
  • 사용자 당 요금으로 상대적으로 저렴하게 사용할 수 있다.
  •  사용하기 편리하다.

• 단점
  • SaaS 서비스로 에러가 나면... AWS Support에 질문해야한다. (드라이브 앱 오류가 상당히 많음)
  • 사용자 관리할 관리자가 필요하다. (추후 복잡해지면, 관리하기 어려울 수도...)

AWS에서 직접 사용자를 위한 NAS 서비스가 없어서 구현에 어려움이 있다...

사실 그냥 NAS 서버 사서 쓰는게 젤 베스트 일지도...? ㅎㅎ

eksctl-control-host 생성(EC2)

보안그룹이 ssh 접속을 할 수 있게 한 뒤 EC2 인스턴스 한 대를 생성합니다. (t3.micro)

# kubectl
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

# eksctl
# for ARM systems, set ARCH to: `arm64`, `armv6` or `armv7`
ARCH=amd64
PLATFORM=$(uname -s)_$ARCH
curl -sLO "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_$PLATFORM.tar.gz"

# (Optional) Verify checksum
curl -sL "https://github.com/eksctl-io/eksctl/releases/latest/download/eksctl_checksums.txt" | grep $PLATFORM | sha256sum --check
tar -xzf eksctl_$PLATFORM.tar.gz -C /tmp && rm eksctl_$PLATFORM.tar.gz
sudo mv /tmp/eksctl /usr/local/bin

eksctl version

위의 명령어를 하나씩 실행하며 kubectl, eksctl을 설치합니다.

mkdir .ssh
ssh-keygen
aws ec2 import-key-pair --key-name "<key-pair-name>" --public-key-material fileb://~/.ssh/id_rsa.pub

위 명령어로 worknode 생성할 때 사용할 예정!

EKSCTL 명령어 실행

 eksctl create cluster \
		--name <cluster-name> \
		--version 1.29 \
		--vpc-private-subnets <subnet-id>,<subnet-id> \
		--vpc-public-subnets <subnet-id>,<subnet-id> \
		--without-nodegroup



eksctl create nodegroup \
		--cluster <cluster-name> \
		--name <nodegroup-name> \
		--node-type t3.small \
		--node-volume-size=8 \
		--nodes 1 \
		--nodes-min 1 \
		--nodes-max 2 \
		--node-private-networking \
		--ssh-access \
        --ssh-public-key <key-pair-name> \
		--managed

위에 생성한 host 서버에 해당 명령어를 입력합니다.

위 이미지 처럼 클러스터와 노드그룹이 생성된 것을 콘솔에서 확인할 수 있습니다.

aws eks update-kubeconfig --name <cluster-name> --region <region>

위 명령어를 입력해 kubeconfig를 업데이트 합니다.

혹, 콘솔 상에서 IAM 보안주체 뭐시기 에러나면, 액세스 항목을 확인하시면 됩니다.

eksctl.yaml 파일 작성

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
 
metadata:
  name: <eks-cluster-name>
  region: ap-northeast-2
  version: "1.29"
 
vpc:
  subnets:
    private:
      ap-northeast-2a: { id: <subnet-a-id> }
      ap-northeast-2c: { id: <subnet-c-id> }
  
managedNodeGroups:
  - name: <eks-nodegroup-name>
    instanceType: t3.small
    instanceName: <eks-nodegroup-ec2-name>
    volumeSize: 8
    ssh:
      allow: true
      sourceSecurityGroupIds: ["<sg-id>"]
    minSize: 1
    desiredCapacity: 1
    maxSize: 2
    labels: { type: eks-node }
    privateNetworking: true

iam:
  withOIDC: true
  
# 참고: https://eksctl.io/usage/creating-and-managing-clusters/

위 코드에 알맞은 구성을 설정한 뒤 해당 yaml파일을 s3 버킷에 업로드 합니다.

eksctl 배포

aws configure 설정을 위한 user와 accesskey를 생성한 뒤 설정합니다.

aws s3 cp <s3-uri> .

s3에 업로드한 eksctl.yaml파일을 가져옵니다.

eksctl create cluster -f eksctl.yaml

위 명령어를 통해 cluster를 생성합니다.

위 이미지와 같이 keypair 에러가 나면 ssh-keygen 명령어로 해결합니다.

노드그룹 까지 잘 설정된 것을 확인할 수 있습니다.

eksctl delete cluster -f cluster.yaml

위 명령어를 입력하면 클러스터가 삭제됩니다.

* 기본적인 세팅은 되어 있는 상태 입니다. (VPC, Nat GW, ALB, EC2(private subnet) 구성)

* private ec2: etech-private-ec2(10.0.11.130)

3. OpenVPN을 통한 접속

OpenVPN은 가상 사설 네트워크(VPN)를 구축하여 외부에서 안전하게 인프라에 접속할 수 있도록 합니다.

사용자는 OpenVPN 클라이언트를 사용하여 VPN에 연결한 후 private 리소스에 접속할 수 있습니다.

1) OpenVPN 서버를 생성합니다.

더 많은 AMI 찾아보기를 클릭합니다.

openvpn을 검색하고 Marketplace AMI 중 제일 위에 있는 이미지를 선택합니다.

인스턴스 유형은 small 이상으로 잡아주시면 됩니다.

vpc는 private-ec2가 올라가있는 public subnet을 선택하고 인바운드 보안 그룹 규칙은 디폴트로 설정 합니다.

(TCP/22 (SSH), TCP/943, TCP/443(웹 인터페이스에 대한 HTTPS 액세스) 및 UDP/1194)

나머지 설정은 디폴트로 두고 인스턴스 시작을 클릭합니다.

* EIP를 할당해 openvpn server의 ip가 고정이 될 수 있게 설정을 하는 것을 추천드립니다.

2) OpenVPN 서버에 접속해 설정 및 사용자를 생성 합니다.

host에 OpenVPN 서버의 public ip를, username에 openvpnas, 서버의 key pair까지 넣고 ssh 접속을 합니다.

쭉 디폴트로 enter를 치면 끝에 이미지와 같이 접속 정보를 얻을 수 있습니다.

해당 서버에서 자체 발행 한 인증서를 통해 SSL 접속을 제공하기 때문에 브라우저에서 접속이 안전하지 않을 수도 있음을 경고하는 것으로 고급을 클릭한 뒤 안전하지 않음으로 이동해주세요.

해당 Admin UI 주소로 접속한 뒤 user / password를 입력합니다.

왼쪽 내비게이션 바 CONFIGURATION > VPN Settings로 들어가 사진에 표시되어 있는 부분을 Yes로 바꿔줍니다.

스크롤을 쭉 내려서 Save Settings 버튼 클릭 해줍니다.

저는 user1으로 생성을 하였고 More Settings을 클릭하여 Password를 입력해주고 스크롤을 내려 Save Settings 버튼을 클릭 합니다.

그리고 꼭 Update Running server를 클릭해 줘야 설정값들이 업데이트됩니다.

3) 위에서 생성한 사용자로 로그인 합니다.

admin을 제외한 주소인 Client UI로 접속해 생성했던 사용자(user1)로 로그인 합니다.

접속할 사용자 OS에 맞는 클라이언트를 다운로드 한 뒤 설치 합니다.

OpenVPN server IP를 넣어주고 NEXT 버튼 클릭 후 Accept 버튼을 클릭합니다.

사용자(user1)을 넣어주고 VPN을 켜줍니다.

private ec2 접속이 잘 되는 것을 확인할 수 있습니다.

4. EIC endpoint를 통한 접속

EC2 인스턴스에 연결하기 위한 엔드포인트로 EC2 웹 콘솔이나 AWS CLI를 통해서 Endpoint에 접근해 인스턴스로 접속할 수 있습니다.

(SSM과의 차이점은 NAT Gateway가 없어도 EIC endpoint를 통해 접속이 가능합니다.)

1) VPC endpoint를 생성합니다.

엔드포인트 생성 전에 보안그룹을 먼저 생성합니다. VPC는 private ec2가 있는 vpc를 선택합니다.

(인바운드 규칙은 신경쓰지 않으셔도 좋습니다.)

EIC 엔드포인트를 생성합니다. VPC는 private ec2가 있는 vpc를 선택합니다.

위에서 생성했던 보안그룹을 선택하고 서브넷은 원하는 곳으로 선택합니다. (private, public 둘 다 가능합니다.)

엔드포인트 생성 버튼을 클릭합니다.

엔드포인트가 사용 가능 상태가 된다면, private ec2 접속 가능합니다.

2) private ec2에 접속합니다.

인스턴스 연결을 클릭합니다.

EC2 EIC 엔드포인트를 사용하여 연결을 클릭한 뒤 연결 버튼을 클릭합니다.

위 이미지와 같은 화면이 확인되면 성공적으로 접속되었음을 알 수 있습니다.

+) AWS CLI를 활용한 ssh로 접속합니다.

* aws cli 설치 되어있음

EIC 터널링 전용 IAM 사용자를 생성하기 위해 정책을 먼저 생성 합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2InstanceConnect",
	    "Effect": "Allow",
	    "Action": "ec2-instance-connect:*",
	    "Resource": "*"
        },
        {
            "Sid": "Describe",
            "Action": [
            "ec2:DescribeInstances",
            "ec2:DescribeInstanceConnectEndpoints"
            ],
        "Effect": "Allow",
        "Resource": "*"
        }
    ]
}

EIC 터널링 전용 IAM 사용자를 생성 합니다.

위에서 생성했던 정책을 연결해 사용자를 생성합니다.

해당 사용자 인증을 위한 액세스 키를 발급 받습니다.

터미널 위에서 ssh 접속을 시도 합니다.

생성했던 액세스 키로 aws configure 명령어를 통해 저장 합니다.

aws ec2-instance-connect ssh --instance-id <private-ec2-id> --connection-type eice

위의 명령어를 입력합니다.

위와 같이 접속한 화면을 확인 할 수 있습니다.

* 기본적인 세팅은 되어 있는 상태 입니다. (VPC, Nat GW, ALB, EC2(private subnet) 구성)

* private ec2: etech-private-ec2(10.0.11.130)

1. bastion server를 통한 접속

사용자가 Bastion Server를 통해 private ec2에 ssh 프로토콜을 사용해 접속합니다.

1) bastion server를 생성합니다.

(t3.nano의 작은 유형으로도 bastion server에는 충분합니다.)

vpc의 public subnet을 선택해주시고, public ip 활성화를 선택해줍니다.

보안 그룹은 원하는 이름을 넣어주시고 소스 유형을 "내 IP"로 선택해 관리자만 접속할 수 있게 설정해줍니다.

나머지 설정은 디폴트로 두고 인스턴스 시작을 클릭해 생성합니다.

2) 관리자가 사용하기 편한 ssh 접속 툴을 활용해 bastion server를 통해 private ec2에 접속합니다.

* MobaXterm을 활용했습니다.

Remote host는 private ec2의 ip를 넣고 Specify username에는 OS에 맞는 username을 넣어줍니다.

private key는 인스턴스 생성 시 선택했던 key pair를 넣어 주시면 됩니다.

위에서 생성했던 bastion server의 public ip와 username, port와 ssh key pair를 넣고 세션을 연결합니다.

성공적으로 접속하면 아래와 같은 화면을 보실 수 있습니다.

2) SSM(System Manager)를 통한 접속

IAM 역할에 SSM 권한을 부여합니다. 그런 다음 해당 IAM 역할을 EC2에 연결하여, private 네트워크에서도 안전하게 접속할 수 있습니다.

1) AmazonSSMManagedInstanceCore 역할을 생성합니다.

ssm 연결을 위해 ec2에 필요한 역할을 생성해줍니다.

위 설정이 끝나면 역할 생성을 클릭합니다.

2) private ec2에 위에서 생성한 역할을 연결해줍니다.

위에서 생성한 역할을 선택한 뒤 IAM 역할 업데이트를 클릭합니다.

( 해당 역할을 적용하는 데 시간이 상당히 소요될 수 있습니다. 빠르게 적용시키기 위해 인스턴스를 재부팅하여 시간을 단축시킬 수 있습니다.)

3) private ec2 에 접속합니다.

위와 같은 화면을 보면 private ec2에 접속 성공한 것을 알 수 있습니다.