파이널 프로젝트

마지막 프로젝트의 본격적인 시작을 하였다.
오늘은 주요 기능들에 대한 구현을 회의를 통하여 생각해보고 정리하였다.
그리고, 팀원들과 정리한 기능을 바탕으로 CTO(역할)님께 질의응답 하는 시간을 가져보았다.

질문 리스트

• 로그인이 되어있는지
• Oauth2.0 타플랫폼 아이디로 회원가입 및 로그인 기능
• AWS 코스 남은 금액을 합산해서 사용할 수 있는지 (하나의 계정으로 팀원의 남은 금액을 사용하고 싶음)
• 빠른 예약 조회 / 그냥 예약조회의 차이 ?
• elasticache 와 elasticsearch 가 중복되는 기능같다
• 예약 정보조회의 내용이 어느기간정도까지 유지되야하는지 ?
• 프로젝트 내에서 금액 산정 (사용해야 하는 유형이나, 이정도면 된다하는 용량)

답변

• 로그인 기능은 필요 없다 —> 우리의 영역은 그 이후 단계부터
  (즉, 예약 정보를 포함한 요청을 받는 이후 과정)
• 예약 등록, 삭제, 수정 로그 기록이 담긴 내용을 logging 해야 한다.
  (OpenSearch를 통하여)
• 요구사항 이외에 사용하고 싶은 기능구현은 자유로우나 요구사항에 충실할 것.
• 드라이버가 알아야 할 사항들은 → 알림서버로 전달되어야함
  (느슨한 결합을 통하여)
• 팀원의 AWS 금액 합산해서 통합 사용가능 ($240)
• 예약정보 인터페이스는 구현하지 않으며 정보가 전달되는것을 검증하면 되면 된다.
• cache를 사용하는 이유를 설명할 수 있어야 한다.
• 예약의 기간은 필요한 만큼을 정해서 구현하면 된다.
• 아키텍처를 구현하기 위한 최소한의 인스턴스유형을 사용하면 된다.

느낀점

팀장을 맡으면서 팀을 잘 이끌 자신감이 있었다.
그만큼 팀원들을 믿으며, 잘 따라와주어서 자심감이 생기는것 같다.
요구사항과 관련된 기능을 어떻게 구현할지 회의를 통하여 정리를 해보았다.
먼저, 기능 명세를 각자 적어보라고 하였는데 잘 따라오지 못하는 팀원이 한 분 있어서 걱정이다.

계획

기능명세를 정리하고 간략하게 CRUD를 기준으로 동작을 테스트해보는 API를 작성할 예정이다.
팀원이나, 나 역시 ElastiCache, OpenSearch에 대해서 처음 접하는 서비스이기 때문에
내일은 각자 각 서비스에 대하여 알아보고 정리자료를 공유해보기로 하였다.
또, 느슨한 결합에 대하여서도 단순히 sns,sqs를 사용하면 된다고 생각했었는데, 여기에 대해서도 복습을 가질 예정이다.

This is my Architechure

직방의 아키텍처를 보았는데, 트래픽 분산을 이중화하여 ECS의 오토스케일링이 동작하는 사이에 이중화된 MSA를 통하여 부하를 분산하여 텀을 줄이고 높은 가용성을 가질 수 있는 아키텍처를 보았다.
프로비저닝을 아무리 잘 하였어도 갑작스런 트래픽에 대응하기란 어려울 것이다.
그래서, 직방의 이중화 아키텍처를 보고 좋은 아이디어라고 생각 되었다.

팀원분들께

마지막 프로젝트, 다들 힘내서 좋은 결과를 만들어 나갔으면 좋겠다.