글쓰는 감자

요즘 GPU 인스턴스에 사람들의 관심이 높아져 가고 있다.

그래서 해당 유형들이 뭘 나타내고 어느정도의 사양인지 간단히 정리해보려 한다..

근데 사실 GPU가 뭔지도 제대로 모르고 있다...

GPU가 뭔지 간단하게 알아보면,

- ALU: 산출 연산 처리 장치(연산 담당)

- CU:  컨트롤 유닛(명령어 해석 및 실행)

GPU의 경우 CPU에 비해 월등하게 ALU 개수가 많다. 병렬 처리 방식을 위해 그런 것!

그래서 AI에 많이 사용된다. "AI는 단순 반복 연산을 처리하여 학습하는 특성"을 가지고 있어 병렬 구조로 연산하는 GPU 칩셋이 중요해진다!

그리고 GPU와 다른 리소스 들 사이의 병목 현상을 해결하는게 주요 문제이다.. 아래는 이를 해결할 수 있는 기술들!

(참고: https://www.youtube.com/watch?v=w_CkMjH8tm4 )

• GPU Direct RDMA:  NIC에 있는 버퍼를 GPU가 바로 읽을 수 있게 해주는 기술
  • RDMA(Remote Direct Memory Access): 컴퓨터 간 CPU를 거치지 않고 메모리 끼지 직접 데이터를 주고 받게 하는 기술
• GPU P2P: GPU Direct P2P, Memory 까지 다녀오는게 아닌 GPU 메모리 끼리 참조할 수 있도록
  • P2P(Peer to Peer):  GPU - GPU 간의 사이 연결
• GPU Direct Storage 까지..

(참고로 GPU는 CPU와 비슷하지만, 용도가 다를 뿐.. CPU에 비해 더 작고 전문화된 코어로 구성된 프로세서)

(vCPU: 나누기 2를 해야 실제 물리 코어, 스레드라 생각하면 될듯)

일단 AWS는 GPU 인스턴스를 사용하는 유형들을 가속화된 컴퓨팅(Accelerated Computing) 쪽으로 분류한다.

P 유형

• P4
  • 최신 세대의 GPU 기반 인스턴스, 기계 학습 / 고성능 컴퓨팅 + 최고의 성능
  • ENA / EFA:
    • ENA(Elastic Network Adapter): 향상된 네트워킹 제공, 높은 처리량과 PPS(초당 패킷) 성능 높게..
    • EFA(Elastic Fabric Adapter): 추가 OS 우회 기능이 있는 ENA, 대규모 HPC 앱과 같은 높은 수준의 인스턴스 간 통신을 실행할 수 있도록
  • NVSwitch: NVLink의 고급 통신 기능을 구축해 더 높은 대역폭과 지연 시간 절감(여러 NVLink 연결)
  • NVMe SSD: Non-Volatile Memory, 비휘발성 메모리(RAM과 비슷하지만 다른 점)

• P3
  • 머신 러닝/딥 러닝, 고성능 컴퓨팅
  • NVLink: 높은 대역폭과 향상된 확장성
    • https://www.nvidia.com/ko-kr/data-center/nvlink/

G 유형

• G5
  • 그래픽 집약적인 애플리케이션, 기계 학습 추론 가속화
  • 간단한 기계 학습 모델에서 중간 정도의 복잡한 기계 학습 모델까지 훈련하는데 사용 가능

• G5g
  • AWS Graviton2 프로세서, 그래픽 워크로드에 대해 EC2에서 최고의 가격 대비 성능 제공

F 유형

• FPGA: field programmable gate array, 프로그래머블 반도체 - 용도에 따라 내부 회로를 바꿀 수 있음(GPU와 다름)
  • CPU, GPU는 용도가 정해진 주문형 반도체와 다르게 칩 내부를 용도에 따라 바꿀 수 있음
  • AI 연산을 하는 GPU의 경우 원래의 용도에서 벗어난다. 이를 보완 가능!(딥러닝 학습, 추론 가능)

❗ 여기에 추가적으로 Trn1 유형 정도 괜찮을 듯 싶다. ❗

(Trn1: AWS Trainium 칩으로 구동, GPU 기반 인스턴스 대비 최대 50% 저렴한 훈련 비용)

IoT core 말고 ec2로도 iot 디바이스와 연결할 수 있게 구성해보려 한다.. 나자신 화이팅!

먼저 디바이스와 통신할 수 있는 프로토콜에 대해 먼저 알아보자.(더보기 클릭)

AWS IoT Core가 제공하는 디바이스 통신 프로토콜은 MQTT와 HTTPS 이다.

https://docs.aws.amazon.com/ko_kr/iot/latest/developerguide/protocols.html

메시지를 게시하고 구독하기 위한 MQTT / MQTT over WebSocket(WSS) 프로토콜,

메시지를 게시하기 위한 HTTPS 프로토콜을 사용하는 디바이스 및 클라이언트를 지원!

MQTT

• 제약된 디바이스를 위해 설계된 경량의 메시징 프로토콜
• clientId로 식별되는 디바이스 연결을 지원
• AWS IoT Device SDK 지원(디바이스를 AWS IoT에 연결할 때 권장되는 방법)
  • 만약 SDK 사용 안하면, 필요한 연결과 통신 보안을 제공하면 됨
• MQTT QoS level 0과 1만 지원(QoS level 2의 게시 또는 구독 지원 안함..)
  
  • QoS level 0: 신뢰할 수 있는 통신 링크를 통해 전송되거나 누락되어도 문제 없는 메시지에 이용
  • QoS level 1: 전송한 사람이 PUBACK 응답을 수신해 성공적인 전달을 나타낼 때까지는 완료 안한 것

HTTPS

• HTTP 1.0 또는 1.1 사용해 REST API에 요청하여 메시지 게시 가능
• clientId 값 지원 안함
• 클라이언트별 엔드포인트 및 주제별 URL에 대한 POST 요청을 함으로서 메시지를 게시
  • https://IoT_data_endpoint/topics/url_encoded_topic_name?qos=1"
  • IoT_data_endpoint: AWS IoT 디바이스 데이터 엔드포인트
  • url_encoded_topic_name: 전송되는 메시지의 전체 topic name

EC2에 MQTT를 올리는 작업을 해보자.

참고로 MQTT 브로커 프로그램에는 ActiveMQ, Apollo, IBM Message, Sight, RabbitMQ, Mosquitto 등이 자주 사용됨.

실습에는 Mosquitto를 사용할 예정!

( https://github.com/mqtt/mqtt.org/wiki/server-support : 브로커 특징 비교 자료)

• EC2에 mosquitto 설치

sudo amazon-linux-extras install epel //epel 설치
sudo yum -y install mosquitto //mosquitto 설치
sudo systemctl start mosquitto && sudo systemctl enable mosquitto //mosquitto 서비스 시작
sudo systemctl status mosquitto // mosquitto 서비스 상태 확인

• Mosquitto 사용

Mosquitto: Message 브로커로 pub&sub 명령어 지원

토픽을 구독하고 메시지를 배포!

mosquitto_sub -d -t my-topic

mosquitto_pub -d -t my-topic -m "message check"

창 두개를 띄워서 한쪽 창에서 sub 먼저 하고 다른 창에서 pub 실행해보자.

로그 확인

sudo tail -f /var/log/messages

New client가 연결된 것을 볼 수 있다!

❗ 사실 이렇게만 보면 뭘 했는지 와닿진 않는다.. 메시지를 구독(sub)하고 게시(pub)하는 건 알겠는데.. 실질적으로 IoT에서 어떻게 활용되냐 이말이야.. ❗

나는 EC2로 구축을 진행할려고 한다. 후에 Fargate로도 해봐야지!

• 클러스터 생성

NAT Gateway 생성: 클러스터에서 private subnet에 있는 ec2 인스턴스를 인식할 수 있게..

private rtb에 붙여준다.

클러스터를 생성해주자.

1) vpc는 private subnet으로

2) 인프라는 ec2 인스턴스로(새 ASG 생성 - Amazon Linux2 / t3.medium / 2-4 / 키페어 없음)

거의 깡통의 클러스터를 생성한 듯

• ASG 관리

EC2 → ASG로 들어가면 클러스터를 만들면서 생성한 ASG가 보인다.

이를 손봐주자..

1) 시작템플릿 관련

현재 상황이다. 보안그룹을 변경해주자.(ecs-sg(container)) 

그러면 새로운 시작 템플릿 버전이 생기는데 이를 ASG에 연결해주자.

새로생성한 Latest(2)를 선택한다.

변경된 것을 확인할 수 있다.

후에 인스턴스 새로고침 진행

시작 템플릿 변경된 것을 적용시키기 위함이다!  → ec2 인스턴스의 정보를 확인해서 ecs-sg로 연결이 잘 되어있는지 확인.

• 작업 정의(Task definition)

ALB를 먼저 생성해주자.

1) vpc는 퍼블릭으로

2) 보안그룹은 ecs-alb-sg로

3) 대상그룹은 생성하자.(ec2는 클러스터 생성을 통해 만들어진 인스턴스를 추가한다.)

4) alb로 돌아가 생성한 대상그룹 선택

alb를 생성하자.

• 작업 정의(Task definition)

1) 컨테이너 생성의 경우 생성했던 ECR 리포지토리의 URI 삽입

2) 앱 환경은 EC2, 네트워크 모드는 브릿지

• 서비스 생성

1) 클러스터의 경우 생성했던 클러스터 선택

2) 시작 유형 - EC2

3) 배포 구성에서 원하는 태스크의 수를 2개로

4) ELB 구성의 경우 위에서 생성했던 것들로 선택해서 진행

후에 배포를 진행..

타겟 그룹을 확인해 보면 49153 포트 번호로 EC2 인스턴스가 추가된 것을 확인할 수 있음.

위에서 설정을 동적 포트 매핑을 사용했기 때문에 호스트 포트를 0으로 설정하면 에페메랄 포트(32768-61000) 범위의 포트가 자동으로 할당되며 alb에 설정해놓은 target grp의 포트는 무시됨.

• alb 확인

• ECS 컨테이너에 접속

EC2 인스턴스에 연결되어 있는 ecsInstanceRole을 수정(EC2RoleforSSM 추가)

EC2를 Session Manager를 통해 들어가보자.

근데 연결이 되질 않네..? → 적용될 때 까지 시간이 걸림..ㅎㅎ

들어가서 설치 잘 되었는지 확인..

sudo -s
cd /var/lib/docker/overlay2
ls
find / -name "*.html"

변경해줘야할 index.html 파일을 찾아야하는데 find / -name "*.html" 명령어를 활용해서 찾자..

/var/lib/docker/overlay2/b2b5c3ddc547fd0347e12b129d7f3f52a5776b20b5d59e4b770a8dab2e6dd504/merged/usr/share/nginx/html/index.html

나는 위의 파일에 해당 내용이 있다.(참고로 merged 폴더 안의 파일이어야 한다..)

원하는대로 html 파일을 변경해주고 적용시키자!

A AZ에는 hello ecs! 가

C AZ에는 hello c AZ ecs! 가 나와야 한다. 확인해보자.

❗ 더 찾아봐야할 것! ❗

위와 같이 진행할 경우 target group에 맨 처음 생성했었던 흔적(?)이 남는다.. 물론 ec2의 경우 종료되어있지만 저거 어떻게 지우지?

→ 일단 내가 네트워크 모드를 bridge - 호스트포트 0번으로 설정을 했기에 포트가 변경된 것...

ECS 서비스를 이용해 타겟 그룹에 인스턴스를 등록하는 경우 타겟 그룹의 포트는 무시됨.

(+) 서비스에 지정하는 컨테이너 포트는 태스크 정의의 컨테이너 포트와 같아야한다.

근데 보통 awsvpc로 하니까 다음 실습 땐 awsvpc 모드로 실행해보자

CloudFront + S3 배포

• S3 버킷 생성

버킷 이름만 정해주고 버킷을 생성한다.(다른 옵션들은 나중에 다뤄볼 것!)

test page를 작성해 객체 업로드(진짜 간단하게 작성해도 괜찮다.)

• CloudFront 배포 생성

해당 원본 도메인을 방금 생성한 버킷 도메인으로 설정한다.

다음으로 S3 버킷 액세스는 OAI를 사용할 수 있도록 체크하고 제어 설정 생성을 해준다.

(왜 갑자기 S3 버킷 정책을 수동으로 업데이트 하게 되는지 모르겠지만... aws가 업데이트가 되었나?)

CloudFront와 S3는 HTTP 연결을 하고 있고 우리가 할 최종 목표는 사용자와 CloudFront의 HTTPS 연결이니까 프로토콜을 Redirect로 해주자.(상황에 맞춰서 설정해주면 된다.)

기본값 루트 객체를 써 넣으면, 도메인 뒤에 따로 써주지 않아도 처음 들어갔을 때 해당 객체로 들어간다.

배포 생성을 누르면 아래와 같이 정책을 업데이트 하라고 뜨는데 해당 정책 복사를 클릭하고 업데이트 해주면 된다.

• S3 버킷 정책 업데이트

버킷 권한에서 버킷 정책을 편집하면 된다. 아까 복사해뒀던 정책을 넣어주자.

배포가 완전히 적용될 때 까지 잠깐 기다렸다가 생성한 배포 도메인을 복사해 붙여주면 원하는 test page를 확인할 수 있다.

CloudFront + EC2 배포

• EC2 생성

원하는 웹페이지나 테스트 페이지를 넣고 EC2에 올린다.(이거는 가볍게 apache 서버 올려서 테스트를 진행했다.)

보안 그룹이나 이런 것들도 잘 열어줘야 한다..(HTTP(80), HTTP(443), TCP(8080), SSH(22))

해당 인스턴스의 퍼블릭 IPv4 DNS를 복사해두자. (어차피 테스트 용으로 만든 거라 삭제 예정)

• CloudFront 배포 생성

S3와 같이 원본 도메인에 해당 복사해둔 퍼블릭 IPv4 DNS를 넣어주자.

(현재는 테스트라 ec2로 했는데 이중화를 원하거나 가용성을 원하면 ALB 구성이 필요하다.)

프로토콜 역시 원하는대로 선택하고 그냥 배포 생성하면 된다.

이것 또한 배포 도메인으로 웹 페이지를 확인할 수 있다.

CloudFront + EC2 + S3 (Multi Origin) 배포

아까 생성했던 CloudFront + EC2 배포에 추가 해보자.

해당 배포로 들어가 원본을 추가하자.

• 원본 생성

아까 설정했던 대로 S3 버킷 정책 업데이트까지 진행하자.

• 동작 생성

경로 패턴의 경우 아까 난 S3 버킷에 test.html 파일을 넣어두었기 때문에 해당 경로로 설정했다.

상황에 맞게 경로를 설정하자.

해당 설정까지 마치면 원본 2개, 동작 2개가 있어야 맞다.

조금 기다린 후 배포도메인만 사용하면 ec2의 화면이, 배포도메인/test.html 로 들어가면 s3의 화면이 나온다.