배경(Problem)
서비스 소개(Solution)
아키텍처 및 핵심 기능
Cluster Spec
•
ami type : AL2_x86_64
•
Instance type : t3.large
•
Volume : 40 GB
•
EBS 활성화
•
Node 수 : 2
•
Terraform을 사용한 IaC
•
Ingress를 통한 Front -Back의 소켓 연결
◦
Ingress에서 Prefix를 사용하여 “/socket.io/”로 요청이 올 경우 Backend로 연결
“/”로 요청이 올 경우 Frontend로 연결
•
환경 변수를 통한 주소 주입
◦
Frontend를 배포할 때 환경 변수를 통해 ALB의 주소를 주입하여 웹소켓 연결
◦
Backend를 배포할 때 환경 변수를 통해 FLASK의 DNS 주소를 주입하여 데이터 통신
•
자체 서명 인증서를 사용한 https
◦
openssl을 통해 key와 cert를 생성하여 AWS의 Certificate Manager에 등록하여 https 연결
•
리소스 모니터링을 위한 Prometheus와 Grafana 설치
•
Pod 배포 제한에 따른 자동 노드 확장을 위한 Karpenter 설치
활용 라이브러리 및 개발 환경
모델 선택 근거
프로젝트는 한국어 강의 자료를 효과적으로 요약하기 위해 다양한 BERT 변형 모델을 실험했습니다. 데이터는 전처리 후 다양한 높이와 각도에서 실험되었고, BERT, RoBERTa, DistilBERT 모델의 초기 테스트를 거쳐 각각의 장단점을 분석했습니다. 추가 레이어의 적용이 복잡한 문장과 긴 텍스트의 요약에 긍정적인 영향을 미치는 것을 ROUGE-L 점수를 통해 확인했습니다.
LSTM 레이어를 추가한 BERT 모델을 개발하여 실시간 강의 자료 요약의 효율성을 증가시켰습니다. 실험적으로 하이퍼파라미터를 조정하고, 모델의 학습 과정을 검증 데이터 세트를 통해 지속적으로 모니터링했습니다. 결과적으로, LSTM 레이어를 통한 모델의 요약 정확도는 약 20% 향상되었으며, 특히 실시간 데이터 처리와 짧은 문장 요약에서 우수한 성능을 보였습니다.
Textrank
1.
형태소 분석기 활용:
•
한국어의 복잡한 문장 구조와 다양한 의미, 문법적 기능을 이해하는 데 유리합니다.
•
Okt 형태소 분석기를 사용하여 문맥상 중요한 명사를 효과적으로 추출할 수 있습니다.
2.
공동 출현 단어 분석:
•
함께 자주 등장하는 단어들은 문서의 중요한 주제를 반영합니다.
•
한국어의 문맥상 의미를 파악하는 데 매우 유용합니다.
3.
가중치와 방향성 고려:
•
네트워크 분석을 통해 단어 쌍 간의 가중치를 계산합니다.
•
단순한 빈도수 분석보다 더 깊은 통찰력을 제공합니다.
4.
TextRank 알고리즘 적용:
•
단어 간의 연결 강도를 고려하여 중요한 단어를 선정합니다.
•
전체 네트워크 내에서의 단어의 상대적 중요성을 평가합니다.
트러블 슈팅
문제 1) Frontend와 Backend를 웹소켓으로 연결하기 위해 DNS를 사용할 경우 웹소켓 연결이 완료되기 전에 웹소켓이 닫혀 연결이 불가능
•
해결 방안 1)
◦
Backend인 Express를 NodePort로 배포 후 LoadBalancer로 변경하여 ELB를 생성
◦
Frontend인 Vue에 생성된 ELB 주소를 직접 입력하고 이미지화하여 배포
•
해결 방안 2)
◦
Ingress를 생성하여 “/” 요청의 경우 Frontend로 연결하고, “/socket.io/” 요청의 경우 Backend로 연결
◦
Frontend인 Vue에 생성된 Ingress의 ALB 주소를 직접 입력하고 이미지화하여 배포
•
해결 방안 3)
◦
Frontend를 배포할 때 환경 변수를 적용하여 ALB 주소를 환경 변수로 주입
→ 해결 방안 1, 2의 경우 Backend / Ingress에 문제가 생겼을 경우 Frontend까지 재 이미지화 및 재 배포의 단점이 있기 때문에 해결 방안 3을 적용
문제 2) Node 당 Pod 배포 제한에 따른 Pod 배포 불가
•
해결 방안
◦
instance type을 t3.large로 변경하고 EKS 재구성
문제 3) Flask 배포 불가
- 문제 2)를 해결하면서, Pod의 배포 제한이 커지면서 Node를 1개만 생성
→ AI Model의 용량이 커지면서 Node의 임시 저장소 용량 부족 발생
•
해결 방안)
◦
EKS를 생성할 때 Node의 저장소 용량을 여유롭게 지정
▪
기존 : 20GB
▪
변경 : 40GB
문제 4) HTTP 접속에 따른 마이크 사용 불가
•
해결 방안)
◦
Openssl을 사용한 자체 서명 인증서를 생성하여 AWS에 등록
◦
Ingress 및 각 서비스의 포트를 HTTPS로 변경
문제 5) Node AutoScaling 불가
•
Pod를 Node에 배포할 수 있는 최대 Pod 수 보다 높게 scale 변경하여도 Node가 추가 되지 않아 Pod이 Pending 상태에 빠짐
•
해결 방안 1)
◦
AWS의 EC2 AutoScaling 그룹에서 동적 크기 조정 정책 생성
•
해결 방안 2)
◦
Node에 배포할 수 있는 Pod가 꽉 찼을 때 Node를 Autoscaling
→ 동적 크기 조정 정책의 경우 CPU의 사용량이나 네트워크의 입출력 용량에 따라 AutoScaling을 수행하기 때문에 이를 측정하기 어려워 해결 방안 2)를 적용
