<피드백>

  1. 현재의 아키텍처를 구성하게된 근거들 또한 조금 더 추가되면 좋겠습니다. -대본수정

  2. Redis는 어디에 위치해있는것인지 잘 보이지 않습니다. 또한, 현재의 아키텍처를 가졌을 때 발생할 수 있는 문제점들은 어떤것들이 있을지 그리고 그 해결방법은 무엇인지 생각해 보셨을까요? -

  3. 발표 자료에서 조금 더 기술적인 부분들로 내용들이 채워지면 좋겠습니다. -

<아키텍처 문제점>

  1. 단일 실패 지점 (Single Point of Failure, SPOF): EC2 인스턴스가 단일 노드로 보이는데, 이 경우 하나의 EC2 인스턴스에 장애가 발생하면 전체 서비스가 다운될 수 있어. 고가용성을 위해 여러 인스턴스와 함께 로드 밸런서 뒤에 애플리케이션을 배치하거나, 자동 복구 및 스케일링을 가능하게 하는 서비스 (예: AWS Auto Scaling, Elastic Load Balancing)를 사용하는 것이 좋아.

  2. 데이터베이스 백업 및 복구: 아키텍처에는 데이터베이스 백업 및 복구 전략이 명시되어 있지 않아. Amazon RDS는 자동 백업을 제공하지만, 재해 복구를 위한 전략(예: 다중 AZ 배포, 스냅샷, 복제)을 구현하는 것이 중요해.

  3. 스케일링 전략: 사용자의 수가 증가함에 따라 시스템이 어떻게 수평적으로 확장될 수 있는지에 대한 정보가 없어. 트래픽 증가에 따른 자동 스케일링을 지원하기 위한 전략이 필요해.

  4. 데이터베이스 보안: RDS 인스턴스가 VPC 내에 존재하는지, 적절한 보안 그룹과 네트워크 ACL로 보호되고 있는지 확인해야 해. 또한, 데이터베이스를 공개 인터넷에 노출하지 않도록 주의해야 해.

  5. 트래픽 암호화: 다이어그램에서는 사용자와 NGINX 사이의 HTTPS 연결만 표시되어 있어. EC2 인스턴스 내부와 RDS, Redis, S3 버킷 간의 통신도 암호화되어야 하는데, 이 부분이 명확하지 않아.

  6. 모니터링 및 로깅: 시스템의 상태를 실시간으로 모니터링하고 로그를 수집하는 시스템의 부재는 장애 발생 시 빠른 대응을 어렵게 만들어. AWS CloudWatch 또는 ELK 스택 같은 도구를 사용해 모니터링과 로깅을 강화해야 해.

<원본>

안녕하십니까 Spring 3기 B-7조 사뿐 발표 시작하겠습니다.

발표는 다음과 같은 순서로 진행하겠습니다.