기존 아키텍쳐

수능 문제 생성 프로젝트를 개발하면서 Github Actions, ArgoCD, AWS, Rancher를 활용해 MSA 환경을 구축했습니다. LLM을 활용한 RAG 시스템과 프롬프팅 코드의 양이 증가하면서, Django 백엔드 코드의 복잡도가 증가하고 가독성이 떨어졌습니다. 이에 FastAPI 서버를 추가해 LLM API를 별도로 관리하도록 제안하였고, 실제로 구현하였습니다.

• 우선, yaml 파일을 작성하여 Rancher에 새로운 애플리케이션 구성을 정의한 후, Rancher UI를 통해 이를 업로드하고 Kubernetes 클러스터에 배포함으로써 CI/CD 파이프라인을 구축했습니다.
• 그 다음, Langchain의 langserve를 도입해 기존 서버와 통신을 원활하게 하였고, langsmith를 통해 LLM 퍼포먼스를 기록하고 모니터링하는 시스템도 구축하여 프롬프팅 수정 시간을 절감할 수 있었습니다. 이를 통해 코드 업데이트 효율성과 프로젝트의 생산성을 높이는 데 기여할 수 있었습니다.

현재 아키텍쳐

• datadog 도입하였습니다. python3를 monitoring 하면서 rds도 함께 모니터링 하고 있습니다.

• django, fastapi가 서로 request를 보낼 때 ingress 를 거치지 않고 service를 통해 api call을 할 수 있도록 수정하였습니다.
  
  datadog에서 성능 향상을 모니터링 예정입니다.

ingress를 거치지 않을 때 장점

Ingress를 거치지 않고 Kubernetes의 Service를 통해 Pod 간 호출을 주고받는 방식은 클러스터 내부에서 네트워크 통신이 이루어지기 때문에 여러 가지 장점이 있습니다. 주요 장점을 상세히 정리하면 다음과 같습니다.

1. 네트워크 성능 개선

• 저지연 통신: Ingress는 클러스터 외부에서 들어오는 트래픽을 관리하는 역할을 하며, 외부 라우팅 및 인증 절차를 추가로 수행합니다. Pod 간 직접 통신 시에는 이러한 외부 라우팅을 거치지 않아 통신 속도가 더 빠릅니다.
• 간소화된 네트워크 경로: Ingress를 통해 통신할 경우, 트래픽이 클러스터 외부로 나갔다가 다시 내부로 들어와야 합니다. 직접 Service를 사용하면 클러스터 내의 네트워크를 통해 곧바로 트래픽이 전달되므로, 네트워크 경로가 간소화되어 대기 시간이 줄어듭니다.

2. 보안 강화

• 외부 노출 최소화: Ingress는 클러스터 외부로 네트워크를 노출하는 방식이기 때문에 보안상의 위험이 있습니다. 클러스터 내부 Service로만 통신하면 외부에 네트워크를 노출하지 않으므로 외부 공격으로부터 보호할 수 있습니다.
• 내부 전용 통신: ClusterIP 타입의 서비스는 클러스터 내부에서만 접근이 가능하도록 설정되어, 외부로의 접근을 제한할 수 있습니다. 이로 인해 민감한 데이터나 중요 서비스의 경우, 외부의 접근을 원천 차단한 상태에서 안전하게 통신할 수 있습니다.
• IAM 또는 VPC 기반 보안: EKS와 같은 환경에서는 VPC를 활용하여 서비스 간 통신을 제한할 수 있으며, 추가적으로 IAM(Identity and Access Management)으로 각 서비스 간의 권한을 세부적으로 관리할 수 있습니다.

3. 비용 절감

• 클라우드 비용 절감: Ingress를 사용할 때는 클라우드 제공자에 따라 비용이 발생할 수 있습니다. Ingress는 외부에서 접근 가능한 로드 밸런서를 생성하는 경우가 많으며, 이 로드 밸런서 사용료와 외부 트래픽 비용이 추가됩니다. 반면에 클러스터 내부 통신만을 사용하는 Service는 외부 리소스를 사용하지 않아 비용이 들지 않습니다.
• 인프라 비용 절감: Ingress의 추가 설정 및 로드 밸런싱 기능은 컴퓨팅 리소스를 더 많이 요구할 수 있습니다. Service를 사용해 직접 통신할 경우 이러한 오버헤드가 줄어들어 컴퓨팅 리소스를 보다 효율적으로 사용할 수 있습니다.

4. 간편한 설정과 관리

• 설정 단순화: Service를 이용한 Pod 간 통신은 Ingress 설정보다 간단합니다. Service 설정만으로도 간편하게 통신할 수 있어 운영 및 관리가 편리합니다.
  네임스페이스와 DNS를 통한 자동화된 이름 해석: Kubernetes의 내부 DNS는 네임스페이스와 서비스 이름을 조합해 자동으로 주소를 생성해 줍니다. 이로 인해 외부 도메인 관리가 필요 없어, 서비스 이름을 통해 쉽게 통신할 수 있습니다.
• 네트워크 정책을 통한 세부 제어: Kubernetes NetworkPolicy를 활용해 네임스페이스나 특정 레이블을 기준으로 Pod 간 트래픽을 세부적으로 제어할 수 있습니다. 이 기능을 통해 특정 애플리케이션 간에만 통신을 허용하는 등, Ingress보다 더 세부적인 제어가 가능합니다.

5. 확장성 및 유연성

• 수평적 확장 용이: Service를 통한 통신은 Service 객체가 알아서 로드 밸런싱을 수행하므로, Pod의 수가 증가해도 자동으로 트래픽이 분산됩니다. 이를 통해 서비스 간 통신이 원활하게 유지됩니다.
• 내부 트래픽 관리 최적화: Ingress는 외부 트래픽을 주로 관리하는 데 적합하고, 내부 트래픽 관리는 Service가 더 최적화되어 있습니다. Service는 Pod의 IP 주소가 바뀌더라도 Kubernetes DNS를 통해 자동으로 업데이트되므로, 가용성이 보장됩니다.

6. 신뢰성 향상

• 내부 서비스 복구와 자동화: Service는 Kubernetes 컨트롤러에 의해 관리되므로, Pod가 죽거나 새로 생성되더라도 DNS가 자동으로 업데이트되어 지속적인 서비스 접근이 가능합니다.
• 지속적인 헬스 체크: Kubernetes는 각 Pod의 상태를 지속적으로 모니터링하고, 비정상 Pod를 자동으로 대체합니다. Ingress보다 직접적인 통신을 통해 문제가 발생한 Pod에 대한 빠른 대처가 가능해집니다.

MORE

• 외부 user가 접근할 때는 외부 user → IGW → ALB/NLB → Public Subnet → Ingress Controller → Service → Pod

• 내부 호출할 때 pod(BE) -> Service -> pod(LLM)
  infra 장애가 일어나면 pod가 degraded 상태로 변한다. 새로 생긴 pod는 ip가 바뀌기 때문에 고정된 service ip를 가지고 연결하게끔 되어있다. (kernel의 iptable을 참조해서 고정적 ip와 가변적 ip를 연결시켜준다)

• pod에 container가 2개 있는 경우?
  내 프로젝트는 datadog을 daemonset pod로 지정해놓아서, datadog이 pod(서버), db를 모니터링해줄 수 있다. 하지만, pod내 container마다 APM을 확인하고 싶다면 pod내부에 container를 1개 더 띄워서 모니터링 해준다.

• git push를 하면 tekton이 image를 만들어주고 image 저장소에 저장해준다. k8s(kubelet)는 이 이미지를 pull하고 ArgoCD가 GitOps 방식으로 변경 사항을 감지하고, 이를 반영하여 Deployment를 업데이트함으로써 새로운 Pod를 생성합니다.

• IaC(Kubernetes YAML 파일)는 ArgoCD와 연동되어 Kubernetes 클러스터의 리소스를 선언적 방식으로 관리한다. 이를 통해 ReplicaSet의 개수, Ingress 설정(AWS Gateway 연동), Nginx 활용 등 다양한 설정을 코드로 정의하고 자동으로 적용할 수 있다.

sw architecture

CI/CD 와 사용하는 기술들을 정리하여 SW Architecture을 만들어 보았습니다.

Trouble Shooting

RAG과정에서 GPT 4o -> o1 preview로 업데이트 하면서, 문제 생성 시간이 길어졌다. 이 시간이 1분을 넘어갈때 계속해서 CORS ERROR를 호출하는 오류가 일어났다. 따라서, EC2 Load Balancer의 limit 시간을 60초에서 180초로 증가시켰다. 더 이상 cors error 는 없었다 !!
(처음에는 llmops의 uvicorn, django의 gunicorn, django backend의 csrf 문제라고 생각했다. 하지만, 근본적인 원인은 load balancer에 있었다. cors error가 날 수 있는 경우의 수를 기억하자. middleware에 대해 더 공부해보자.)

Pod degraded

backend 서버의 dependency가 늘어나고 기능이 계속해서 추가되면서 pod 의 용량이 부족한 상황이 나타났다..! ephemeral-storage의 limit을 강제로 늘려서 해결하는 방법이 있다 하지만, AWS EKS를 사용하면 node EC2 tier를 업데이트 하는 방법 밖에 없다 🥲

DOCKER IMAGE 용량을 줄일 수 있는 방법을 보다 docker slim, alpine을 알게 되었다. slim을 적용시켜 dev 서버에 배포해보았는데, 일단은 모든 기능이 정상적으로 작동한다. image 크기도 거의 절반으로 줄었다 !!
🤔하지만, 좀 더 지켜봐야 할 것 같다.

참고