파이널 프로젝트 4일차

최종 아키텍처 그림을 완성하기 위해 CTO님과 미팅을 하였다.
생각해두었던 질문중에서 mysql을 rds가 아닌, 별도의 ec2서버에 올려서 관리하고자 하였다.
예전에는 그렇게 했을지도 모르지만 굳이..
RDS 서비스를 사용하여 DB인스턴스에 대한 관리를 하지 않고도 복제본 또는 스냅샷에 대한 관리를 수월하게 할 수 있다.

많은 피드백과 함께 느슨한 결합방법을 확정하였다.
요구사항에 맞는 서비스들을 직접 생성해 보면서 만난 에러들을 찾아보며 해결하기 위해 검색하였다.

다음주에는 생성 및 연결을 완료하고 테스트를 위한 간단한 api 코딩을 진행할 예정이다.

CTO 미팅, 회의록

예약정보 API_SERVER (EC2)에 filebeat설치 log파일 필터링, OpenSearch 엔드포인트에 로그 누적.
ElastiCache 캐싱전략에 맞게 작동 시키기. (https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html)
느슨한결합 SNS, SQS 하면서 SNS를 굳이 써야하는지 - 나중에 토픽을 구분해서 처리할 수 있도록 확장성을 고려함.
초기작동 Test환경은 간단한 Nodejs 서버를 사용하지만 확인후 최소한 컨테이너화 또는 EKS 환경으로 작동.

추가 QnA (1)

API_SERVER안에 MySQL을 설치하고 사용하여도 되는가?

• 3 Tier architechture를 사용해야하는 이유
• 보안, 직접 DB에 연결하지 않고 클라이언트에 DB에 대한 어떠한 정보도 저장하지 않는다.
• 대용량 서비스, 서버에서 connectionless방식을 사용하여 db서버의 부담을 줄인다.
• 클라이언트 배포 단순화
• 다중 DB 사용 용이
• 비즈니스 단위의 분리

추가 QnA (2)

예약정보 API와 알림 API 서버를 로드밸런서로 연결해도 되는가?
ELB - ELB의 연결은 어찌보면 단단한 결합과 가깝다.
좀 더 느슨하게 연결하려면 SQS나 다른 서비스를 알아보자.

추가 QnA (3)

ElastiSearch를 컨테이너화 시킨 서버로 실행해도 되는가?
그렇게 사용해도 되겠지만, 우리는 AWS가 관리해주는 서비스를 사용함으로써 Search 기능에 집중할 수 있다.