13. 학습의 단계_AWS Bedrock_ 두번째 강의 -9일차 -
2025년 4월 29일
- Bedrock 두번째 강의 수강 시작.
-------
1단계. 학습의 단계
1. AWS Bedrock
첫번째 강의) Building Multi-Agentic AI Workflows on AWS Bedrock: 수강완료 (2025/4/13~04/16)
두번째 강의) Learn Agentic AI Basics, Amazon Bedrock Multi-Agent Framework, Build 2 Use Cases- Hotel Booking & Multi-Agent Travel App: 수강시작 (2025/4/29~)
I. 수강 전 기대
첫번째 강의에서 아쉬웠던 Hands-on을 조금 더 해볼 수 있을 것으로 기대함. 커리큘럼을 보니 간단하지만 Bedrock에서 만든 multi agent를 프론트로 배포하는 것도 배울 수 있는 것으로 보임.
II. 수업내용
1일차(4/29): 앞으로 배울 내용 개괄 + AI Agent 5가지 요소 (Planning, Tools & Actions, Memory, Guardrails, Agent Communication)
2일차(4/30): 어제 배운 AI Agent의 기능 중 첫번째 Planning에 관한 Demo ~ Agent Communication
3일차(5/1): Deep dive - Amazon Bedrock Agents (Agent creation 및 setting)
4일차(5/6): How do Agents work? ~ Use Case 1 - Hotel Booking Agent
5일차(5/7): Use Case 1 - Hotel Booking Agent ~ Agent Creation
6일차(5/14): Agent Integration with Knowledge Bases for Room Information ~ Hotel Room Availability
7일차(5/19): Hotel Room Booking - DynamoDB ~ Hotel Room Booking - Agent & Lambda & Action Group Integration
8일차(5/20): Hotel Room Booking - Agent & Lambda & Action Group Integration ~ Final Demo
8일차(5/20): Hotel Room Booking - Agent & Lambda & Action Group Integration ~ Final Demo
9일차(5/22): Frontend Deployment to EC2 Server ~ Adding application load balancer to EC2
이제까지 만든 Use Case 1의 Agent를 실제 웹으로 띄우는 작업을 할 것이다. 이를 위해서 AWS EC2 Instance를 생성하고 만들어 둔 python 파일 등을 웹에 올려 외부에서도 접속할 수 있도록 할 것이다. (이 부분이 첫번째 강의와 가장 큰 차이점이었기 때문에, 가장 기대되는 부분이다. 왜냐하면 이 강의를 통해서 Bedrock Agent가 실제 서비스로 어떻게 접목될 수 있는지를 확인할 수 있기 때문이다.)
1. AWS EC2 인스턴트 생성 (AWS Linux, Key pair 생성 등)
2. Github에서 새로운 repository 생성
3. Github의 repository에서 upload existing files로 Python 파일과 Dockerfile이 있는 폴더를 업로드
3. Github의 repository에서 upload existing files로 Python 파일과 Dockerfile이 있는 폴더를 업로드
4. AWS EC2 인스턴트에서 'Connect'로 접속하여, EC2_Deployment Setting에 따라 배포 설정 진행
1) root 계정으로 변경 (sudo su)
2) yum update (sudo yum update -y)
3) git 설치 (yum install git)
4) git clone "repository URL"
4) git clone "repository URL"
5) python, python-pip, boto3, python-dotenv, streamlit, PyYAML 설치
6) EC2 IAM role 세팅 - EC2용도의 IAM role 생성 후 EC2 Instance로 가서 'Action -
7) streamlit run app.py
- 드디어 public web에 app.py가 올라가게 되었다
- 그러나 External URL로 접속 시 '보안 이슈'로 인해 접속이 되지 않는다.
- EC2 Instance - Security Group 에 접속해서 보안 이슈를 해결해줘야 한다.
*8501 포트로 접속 시도 시 anywhere에서 접속 가능하도록 설정완료하면 접속 가능.
이렇게 public 웹 환경에서 Agent를 이용할 수 있도록 한 후, 다음으로 Load balancer 설정을 한다.
1. AWS EC2 - Target Group 생성
2. AWS EC2 - Load balancer 생성
3. DNS name 도메인으로 접속 시도 -> Target Group의 Health Status가 Unused에서 Initial, 그리고 Healthy로 바뀌게 되면 성공적으로 접속 된다.
*처음에는 제대로 접속되지 않아서 문제를 확인해보니 EC2 인스턴트의 보안그룹 설정이 추가로 되어있지 않아 생긴 문제였다. 이 부분을 해결하고나니 load balancer를 통해 dns name 으로 접속이 잘 되었다.
(참고) Load Balancer의 역할에 대해 추가적으로 찾아보았다.
1. AWS에서는 Load Balancer를 ALB(Application Load Balancer)라고 함.
2. ALB는 많은 트래픽이 있는 경우, 해당 트래픽을 여러 개의 EC2 인스턴트로 분산시켜 주는 역할을 함.
3. 이 과정에서 Target Group이라는 개념이 사용됨. 하나의 Target Group에 두 개 이상의 EC2가 연결될 수 있음.
4. ALB를 Cloudwatch와 연동하는 경우, 서비스의 응답속도 또는 CPU 가용률에 따라, t3.small Instance를 사용할지, 아니면 t3.large Instance를 사용할지 결정할 수 있음. 이 설정 과정에서 가중치 라는 개념을 사용할 수 있고, 가용률 등에 따라 메인 인스턴스를 바꾸도록 하기 위해서는 Cloudwatch - Action에서 Lambda 기능을 만들어서, 특정 조건에 따라 두 인스턴스의 가중치를 변경함으로써 트래픽을 컨트롤 할 수 있음. (이 때 수동으로 정해진 인스턴스들 내에서 트래픽을 통제할 수도 있고 Auto Scailing 기능을 통해 자동으로 인스턴스를 제어하도록 할 수 있음.)
5. 만약 단 1개의 EC2를 사용하려고 할 때에도, ALB를 사용하는 것은 다음과 같은 이점을 제공함.
- 사용자가 고정된 URL로 접속할 수 있도록 함. 물론 이는 Route53만으로도 어느정도 해소할 수 있지만, 이번 예제와 같이 비표준화된 Port (8501)를 사용하는 경우에는, 서비스 도메인 뒤쪽에 :8501 을 표기해야하는 등 제한이 된다고 함. 그러나 ALB를 통하게 되면 Port 80으로 접속하더라도 이를 8501로 라우팅할 수 있다고 한다. (ALB없이도 이 문제를 해결할 수 있기는 하나, 이 경우 Nginx, Apache 같은 별도의 웹 서버를 두어서 포트 매핑을 별도로 해야하는 번거로움이 있다.)
- EC2의 유동 IP를 매번 업데이트할 필요가 없음. (이 부분은 Elastic IP로도 해결 가능하나, 이 경우에도 추가 비용이 발생함.)
- 기존 인스턴스에 문제가 생겨 교체하거나 백업용 인스턴스를 Target Group에 연결하는 경우 등 유지보수 시에도 보다 편리하게 수정이 가능하다.
댓글
댓글 쓰기