System Architecture
(추가 예정 - 어느 부분에서 로그를 취득할건지 결정 필요)
<Public>
IGW : 외부 인터넷과 VPC 연결
NLB : 차후 HA 구성을 적용하기 위한 LB
NGW : Private Subnet 에 있는 Grafana를 외부에서 접속하기 위한 게이트웨이
nginx : TLS 인증서 처리, 차후 HA 구성을 적용하기 위한 ALB 역할 담당
ArgoCD : Dockerhub의 이미지 변환 감지를 통한 CD 실행
<Private>
Frontend Server : Vue3 를 사용, 사용자 화면을 제공하는 서버
App : Spring boot를 사용, 비즈니스 로직을 제공하는 서버
Prometheus & Grafana : App서버 메트릭 모니터링 & 화면 제공
Logstash(or Fluentbit) : S3에 저장된 사용자 액세스 로그 파일을 읽어와 Opensearch 에 입력
EC2 : Redis용 서버
Redis : 검색 기능 향상을 위한 캐싱 기능 담당 DB
RDS(MySQL) : 회원의 메타 데이터가 저장되는 테이블만 존재하는 DB
OpenSearch : 액세스 로그 분석, 검색 기능을 지원하는 검색 엔진
<VPC 영역외 서비스>
S3 : 사용자 액세스 로그 파일 및 에러 로그 파일이 저장되는 저장소
Ollama(또는 OpenAI) : AWS상에 올리기에는 최소 RAM 요구량이 많아서 로컬에서 실행, ngrok등을 사용해 외부에서 접근할 수 있도록 설정
Github : 개발 코드의 버전 관리 및 배포
Github Action : 테스트코드 정상 동작 확인 및 CI 실행
Dockerhub : 생성된 docker image 배포
<로그 예상 흐름>
사용자의 특정 단어 검색 ->
조회 메소드에 Aspect 를 사용하여 사용자 정보 및 검색 정보를 로컬 파일에 로깅 ->
일정 기간(현재 매일 00시 1회 예상)이 될 때마다 Logstash(또는 fluentbit)를 통해 Opensearch로 로그 전송 ->
일정 기간(현재 매일 00시 1회 예상)이 될 때마다 S3 Glacier에 장기 보관용 로그 전송
A : 흐름은 로컬 파일 -> fluentbit -> opensearch -> 이후 처리(s3저장이 필요하다면 이후에 추가할 수 도 있지만 별도의 서비스를 따로 만들어야 하니 현재는 추천 안함)
A2 : 액티브 로그 종류는 적당함
A3 : opensearch 로그 저장 주기는 한번 생각해보기 - 비용 문제로 실무만큼 자주는 못 올리더라도 하루 한 번은 결과 확인이 너무 힘들 것 같다. 적당한 주기를 찾아볼 것 (1시간?)
<Q>
1. nginx의 위치가 맞는지?(Public인지 Private인지, LB 전/후)
-> A: Public에 위치할 명확한 이유가 있으면 Public에 위치해도 됨. 그게 아니라면 Private로 넘길 것.
현재 아키텍쳐에서는 외부로부터의 트래픽을 NLB가 public에서 받아주고 있기 때문에 nginx까지 public에 위치할 필요는 없을 것 같음