진행사항
1. 아키텍처 검토 전 질문사항을 정리하여 질문 후 피드백을 받았다.
2. EC2 내 filebeat 설치 후 로그를 수집하고, 해당 로그를 Opensearch로 운반 (진행중) - 자료 검색
아키텍처 검토 (질문/답변)
Q1. 예약 정보에 대한 기능을 하는 API 서버(EC2)에 fliebeat를 설치 후 log 타입만 받아 Opensearch 엔드 포인트에 로그를 누적해도 되는가? -> OK
Q2. 느슨한 결합을 위해 SNS를 굳이 사용해야 하는가? -> 지금이야 간단한 알림만을 전송, 그러나 나중에 토픽이 여러가지일 경우 구분해서 처리할 수 있도록 확장성을 고려 (+ 초기작동 Test 환경은 Node서버를 그냥 띄워 진행하지만, 그 이후 적어도 docker이용하거나 EKS 환경으로 작동하게 해야함)
Q3. RDS를 사용하지 않고 데이터베이스 서버(EC2)를 하나 생성해서 MySQL을 수동으로 관리해도 되는가? -> RDS가 없다면 그렇게 하는 것이 맞겠지만, RDS는 데이터베이스 관리를 자동으로 해준다. 사용하는 것을 추천
Q4. 예약정보에 관련된 서버와 알림에 관련된 서버를 로드밸런서로 연결해도 되는지? -> ELB-ELB 연결을 할 경우 둘 사이에 장애가 발생할 경우 치명적인 문제가 생기기때문에 강한 결합에 가깝다. 따라서 느슨한 결합을 위해 SQS 또는 다른 서비스를 검색
Q5. ElasticSearch를 포함하는 ELK 스택을 컨테이너화 시켜 실행해도 되는지? -> 그렇게 사용은 가능하나, 이번 프로젝트에서는 AWS가 관리하는 서비스를 사용함으로써 다른 기능에 집중하는 것이 좋음
( + ElasticCache 캐싱 전략에 맞게 작동 (참고: https://docs.aws.amazon.com/AmazonElastiCache/latest/mem-ug/Strategies.html) )
느낀점
오늘 아키텍처에 관한 검증을 받는 과정에서 지금까지 학습해온 내용의 핵심을 제대로 파악하지 못했고, 사용했을 때의 장점을 정확히 파악하지 않고 따라가기 급급했다는 것을 많이 느꼈다. 부트캠프가 끝나게 되더라도 부족한 부분에 대해 꾸준히 학습을 해야하겠다는 생각도 들었다.
댓글