Discussion

AWS의 Load Balancer Service

CI 과정들은 깃 액션을 이용해 구현 하였다면, CD 즉 서버 배포 자동화 과정과 Https로의 프로토콜 변경의 경우는 온전히 AWS서비스들을 통해 구현하였다. 이 Https 로 CD 기능을 구현하기 위해 고려했던 아키텍쳐로는 먼저 AWS의 EC2, CodeDeploy와 로드밸런서, ACM 온전히 AWS서비스만을 이용한 Https 서버 자동배포 기능과 AWS의 EC2, CodeDeploy와 NginX, cerbot을 통한 Https 서버 자동 배포를 고려하였다.

• AWS에 제공하는 로드밸런서를 사용해 Https를 구현했을 경우
  • 방법: EC2인스턴스의 태그와 ACM인증서를 발급받아 로드밸런서를 생성. 80포트와 443포트를 로드 밸런서를 통해 연결
  • 장점: 외부 프로그램이 아닌 온전히 AWS에서 제공해주는 서비스들로 서버 자동배포부터 Https 프로토콜 변경까지 모두 구현하여 이후 aws 기능들을 통한 확장성이 용이함
  • 단점: 요금이 Nginx 방식에 비해 약간 더 소모됨
• NginX를 사용해 Https를 구현했을 경우
  • 방법: EC2인스턴스 환경 안에서 NginX와 cerbot을 설치 및 cerbot이 제공해주는 설정파일 적용.
  • 장점: 요금을 aws 서비스를 온전히 사용할 때보다 소량 아낄 수 있음
  • 단점: aws에서 제공해주는 확장 기능들을 사용하려 할 때 추가적인 설정들이 더 필요함

결론: 소규모 프로젝트이며 단기 프로젝트이기에 요금대비 시간이 중요하다 생각하여 AWS 서비스 만으로 구축해보기로 함

KakaoAPI 소셜 로그인

PWA 앱으로 프로젝트가 결정된 만큼 유저가 회원가입하는 절차를 거치는 것이 번거로울 것이라는 의견이 제시 되었다.  일반 유저는 소셜 로그인을 통해 앱을 사용할 수 있도록하여 카카오 로그인 api와 구글 로그인 중에서 고려하였고   프로젝트의 주 타겟층을 대한민국의 20대, 30대를 대상으로 하였기 때문에 카카오 소셜 로그인으로 모든 회원가입 절차 생략하기로 결정하였다. 카카오 로그인을 기본 회원가입으로 한만큼 카카오 api를 적극적으로 사용하기로 하여 카카오 공유하기, 카카오 푸시 알림, 메세지 보내기 등을 시도하였으나 사파리 브라우저의 FCM 미지원 문제와 공유하기과 메세지 보내기의 기능이 흡사하다는 문제로 일부 반려되었다.

Envers

관리자의 입장에서 유저의 정보들이 누락되는 경우 민원 처리나 클레임을 대처할 때, 어려움이 있을 수 있다. 그러한 점을 고려하여 미션 인증 내역을 따로 저장하는 기능을 구현했다. 그 과정에서 고려한 기능은 일반 테이블에 JPA로 자동 기록하게 하는 형식과 envers 라이브러리를 통한 내역 테이블 자동생성 두 기능을 비교하였다.

• 일반 테이블에 JPA로 자동 기록하게 하는 형식
  • 방법: JPA @PrePersist 와 @PreUpdate를 통하여 테이블 자동 생성
  • 장점: 원하는 정보만을 선별하여 꼭 필요할 때에만 내역을 저장할 수 있다.
  • 단점: 자바class가 여러 개가 생성되며 단순 내역 기록에 사용되기에는 코드의 양이 많은 편이다.
• envers 라이브러리
  • 방법: envers를 사용하여 @Audited와 @NotAudited로 테이블 내 정보를 선별하여 Rev파일 자동 생성
  • 장점: 이미 생성되어 있는 테이블에 어노테이션 @Audited로 테이블에 변경사항이 생길 때 자동으로 내역 테이블을 별도의 클래스 없이 생성한다.
  • 단점: 테이블 내에 있는 정보가 아니면 기록되지 않는다.

결론: 필요한 정보가 submitMission 테이블에 존재하기 때문에 envers 라이브러리를 사용하기로 결정.

SSE

CDN