[TIL] 7주차_Day30: AWS 클라우드 실습 (5)

💡Today I Learned

• AWS 클라우드 실습에 대한 다섯 번째 수업을 진행했습니다.
• Lambda, Docker 실습

---

1. Lambda

- Lambda 함수

: 서버리스 서비스 (별도의 물리적 서버, 환경 없이 소스코드로만 등록해서 돌아감)

: 함수만 등록해서 서비스 제공

: 별도의 서버 없이 함수 등록으로 어플리케이션이 작동

: 이벤트(=트리거) 발생 시 이 함수를 동작시킬 수 있도록 구성 가능

: 트리거 설정 가능

 

- Lambda 함수 생성하기 (실습)

: Lambda > 함수 생성 > 블루프린트(샘플 소스코드) > 이름, 역할 설정 > 생성

: 테스트 > 이벤트 생성 > key-value 수정해서 이벤트 생성

: 코드 직접 작성 후에는 Deploy → 생성

 

- S3 관련 트리거 생성하기 (실습)

: S3 > 사용할 버킷 > 파일 업로드 (트리거의 입력으로 사용될 파일)

: S3 > 사용할 버킷 > 속성 > 이벤트 알림 > 알림 생성 > 이벤트 유형 = 전송(v) > 대상 = lambda 함수(v), 만든 lambda 함수 선택 > 저장

: Lambda > S3 이벤트에 연결한 함수 > S3 트리거 (생성돼있음을 확인) > 모니터링 > 로그 확인할 수 있음

 

2. Docker

- Docker

: HW+OS 위에서 App → 가상화 (하나의 OS에서 여러 개의 App을 별도의 논리적으로 분리된 공간에서 구동 by. Hypervisor) → Docker (경량화된 이미지 빌드, 컨테이너 위에 올려 App 구동) + Kubernetes (오케스트레이션, 여러 개의 Docker 운영)

: +) 더 많은 SW 더 빨리 제공, 운영 표준화, CI/CD DevOps, 원활한 이전, 비용 절감 etc...

 

$ brew install --cask docker

: 도커 설치  (MacOS)

 

- process

: Dockerfile → build → Docker image → run → Docker container

 

- Docker Image

: 컨테이너를 생성할 때 필요한 요소, 소스코드

: 컨테이너의 목적에 맞는 바이너리, 의존성이 설치돼있음 (여러 계층으로 된 바이너리 파일로 존재)

: 만들거나 / Docker Hub(공유 repo)에서 미리 만들어놓은 거 갖다 쓰거나

 

- Docker Container

: 호스트 & 다른 컨테이너들로부터 독립적으로 격리된  공간의 시스템 자원 & 네트워크를 사용하는 프로세스

: 변경사항은 컨테이너 계층에 저장 → 따라서 컨테이너에서 무슨 짓을 하든 컨테이너를 만든 원본 이미지에는 영향 x

 

- Docker Network

: host(물리적 서버) 안에 container가 존재 → 별도의 port로 연결됨

$ docker run -p 8000:80 httpd

: 포트 포워딩 (외부는 8000번, 내부는 80번으로 포트 포워딩 하고싶은 경우)

: ex) http://example.com:8000/index.html ↔ (8000번_외부) Host ↔ (80번_내부) Container

 

- Docker 명령어, Dockerfile 문법

 

- Docker-compose.yml

: 여러 개의 Dockerfile을 띄우거나 관리하고싶을 경우

: docker-compos up -d

 

- Container

: AWS 내에서 Docker 기반 서비스

 

3. CloudWatch

: 정보를 수집해 application 모니터링, 성능에 대한 대응, 리소스 사용률 최적화, 알람/분석 서비스

: 대시보드 → 리소스 상태 평가

: 시각화 → 한 눈에 시각화

: 알림 → 네트워크, 성능, 용량, 트래픽 등의 특정 임계치 설정 및 임계치에 도달할 경우 SNS, 이메일, ... 알림 서비스

: 오토스케일링 → 장애 발생 시 특정 작업

: 로그 → 별도의 서버 구축하지 않는 서버리스 서비스에 대한 자세한 모니터링

: 지표 → 대시보드에 보여주거나 비정형 데이터로 분석 가능

: etc... (더 많은 기능)

 

- 대시보드 생성하기 (실습)

: CloudWatch > 대시보드 생성 > 위젯 추가 (시각화, ex: 탐색기) > 템플릿 선택 (ex: EC2) > 생성

 

4. DevOps

: 소프트웨어 개발 + 운영

: 소통, 협업, 통합을 강조하는 개발 환경이나 문화

: 주로 애자일 방법론(빠르게 개발, 빠르게 배포)과 병행

 

- DevOps 엔지니어

: Soft Skill → 의사소통 기술, 소셜 인텔리전스

: Technical Skill → Linux, 클라우드, 오픈소스, 서버관리, 프로그래밍, 데이터베이스 ...

: 연차가 쌓이면서 여러 스택을 습득해 현장에 적용해가며 성장 ...

 

- MLOps

: 데이터 엔지니어링 + ML + DevOps

: 자동화된 파이프라인 (build(모델 학습, 테스트, 패키징 ..) → deploy → monitor)

: 데이터 파이프라인 = 데이터 생성 → 수집 → 전처리 및 저장 → 분석 및 시각화

: 관련 서비스 → AWS Kinesis, Spark(배치 프로세싱), AWS DMS, Spark streaming(실시간), AWS Glue, Airflow, Redshift(대용량 데이터 적재), AWS SageMaker

 

5. ECR/ECS

- ECR (Elastic Container Registry)

: AWS 내 도커 이미지를 private하게 저장할 수 있는 서비스 (like Docker Hub)

 

- ECS (Elastic Container Service)

: ECR에 저장된 이미지를 기반으로 가상화 서비스를 제공하는 AWS 서비스

: 별도의 서버 필요 x (서버리스), ECR의 이미지만 가지고 운영할 수 있도록 제공

 

- ECR 생성하기 (실습)

: ECS > ECR > 리포지토리 생성 > 이름 > 생성 (private)

: 생성 리포지토리 > 푸시 명령 보기 > 준비된 Dockerfile로 푸시 명령 가이드라인 따라하기

1) Docker 클라이언트 인증  2) Dockerfile 빌드  3) 이미지 태그 지정  4) 이미지 리포지토리에 push하기)

$ aws ecr get-login-password --region ap-northeast-2 | docker login --username AWS --password-stdin [--]

$ docker build -t [ECR 리포지토리 이름] .

$ docker tag [ECR 리포지토리 이름]:latest [--]/[ECR 리포지토리 이름]:latest # == 이미지 URI

$ docker push [--]/[ECR 리포지토리 이름]:latest # == 이미지 URI

*) 권한 관련 문제 시 IAM에서 ecr-fullaccess 가능한 정책 추가하기

*) 1~4 가이드라인으로 push 시 Dockerfile이 위치한 디렉토리에서 터미널 실행?

*) 'Dockerfile' 이름의 파일은 디렉토리 내에서 단 1개만 생성 가능

 

- ECS 생성하기 (실습)

: ECS > 클러스터 생성 > 이름, VPC, 서브넷(private 서브넷) 설정 > AWS Fargate(논리적인, 가상화된 서버리스 서비스를 사용하겠다, 별도의 EC2 없이) > 생성

: ECS > 태스크 > 태스크 정의 > 태스크 정의 패밀리 > CPU, 메모리 설정 > 80포트 > 컨테이너 이름 (ECR에 등록된 이미지로 만들 것임), 앞서 만든 ECR 내의 이미지 URI 복붙 > 생성

: ECS > 생성한 클러스터 > 태스크 > 새 태스크 실행 > 배포 구성 > 패밀리 > 작업 정의 패밀리 선택 > 앞서 만든 태스크 선택 > 생성

: ECS > 생성한 클러스터 > 서비스 > 생성 > 배포 구성 > 패밀리 (작업 정의 패밀리 선택 _ 앞서 만든 태스크) > 서비스 이름 > 생성

 

*) 이후 별도의 ELB(로드밸런서)를 구성해 ECS 서비스로 연결되는 포트를 지정해주기

*) private 서브넷에 존재하는 ECS 서비스와의 연결을 위해 baston host (in public 서브넷) 인스턴스(=ELB 대상)와 연결되는 [ELB-대상그룹-대상] 구성

: EC2 > 로드밸런서 > 로드밸런서 생성 > Application 단의 로드밸런서 > 이름 > 네트워크 매핑 (VPC) > 대상 그룹 추가 > 대상 그룹에 대상 등록 (기존 인스턴스_baston host EC2 인스턴스 추가)

 

6. AWS API Gateway

: 게이트웨이 역할을 하는 서버리스 서비스

: 람다 함수를 실행하는 트리거 역할을 할 수 있음

: 백엔드 서버 (주로 REST API 이용) 부분 → 별도의 서버 구성 없이 간단한 코드로 게이트웨이 구성 가능

 

- API 유형

: HTTP

: WebSocket (채팅 애플리케이션, 실시간 통신)

: REST API (가장 많이 사용되는)

: VPC 내에 private 서브넷에 설치 가능한 REST API

 

- REST API 게이트웨이 구축하기 (실습)

: API Gateway > REST API > 구축 > 새 API > 이름 > 엔드포인트 유형 (엣지 최적화 API: 요청을 가장 가까운 CloudFront 접속 지점으로 라우팅) > 생성

: 만든 API > 리소스 > 리소스 생성 > 메소드 생성 > ex: POST > 통합 유형 lambda 함수 > 만든 lambda 함수 선택

→ 이렇게 만든 API로, 연결된 lambda 함수를 call할 수 있음

→ 메소드 테스트 (간단한 JSON 구성해서 요청) 후 200 응답 & lambda 함수 출력 확인

→ lambda 함수 > 모니터링 > CloudWatch Logs > 로그 스트림 > 로그 이벤트로 테스트 한 내용 확인 가능 (요청 & 응답)

 

- API Gateway

: 클라이언트 애플리케이션 & 백엔드 서비스 서로 상호 작용할 수 있도록 도와주는 서비스

: API를 관리하고 보안, 모니터링, 스케일링 ... 담당

1. API 관리: API를 생성/게시/유지/관리할 수 있는 도구 제공, API 버전 관리, 엔드포인트 설정
2. 인증 및 권한 부여: 클라이언트의 요청을 검증/인증, API 호출에 대한 권한 부여, 사용자나 애플리케이션에 따라 접근 제어
3. 로드 밸런싱: 다양한 백엔드 엔드포인트로의 트래픽을 분산해 로드 밸런싱을 수행, 성능 향상, 가용성 보장
4. 모니터링 및 분석: API 호출 및 사용량 모니터링, 로그를 기록/분석
5. 보안: 보안을 강화하기 위해 API 호출에 대한 암호화, DDoS 공격 방어, 웹 방화벽 등의 기능 제공

 

---

 

💡Furthermore

• 설명 부족한 부분 따로 개념 이해
  
  • Docker 장점 중 '운영 표준화' 구체적인 의미
  • API Gateway
• day3~4: 종합 실습 
  • (To Do): Springboot&Gradle 프로젝트로 백엔드 모듈 구성 / Elastic bs 애플리케이션, 환경 생성 / baston host EC2 인스턴스 / React 프론트 구성 / Route 53 도메인 설정
  • (Done): S3 버킷 생성 / RDS 데이터베이스 생성 & DB 클라이언트 툴로 연결 / CI/CD CodePipeline 구축 _ code commit 부분에서 깃허브 연동은 x.. config만 설정? / VPC 구성 (가용영역 2개의 public/private 서브넷 2개_a, b 씩 구성 → a, c로 변경..?)
  • 종합 실습 미완료 부분으로 설정 못한 부분 (ex: elastic bs, baston host, VPC 생성 → 여기서 만든 VPC 내에서 ECS 서비스 & ELB 연결해야 함  (baston host 인스턴스를 대상으로 하는 ELB) )