😅Final project Day-3

요약

구체화시킨 요구사항들을 바탕으로 아키텍처 작성

---

⚓️오늘 한 일

1. 요구사항을 반영하여 아키텍처 작성

샌디의 요구사항을 반영하여 실시간으로 화물 운송 드라이버의 위치를 전송하는 전송 아키텍처를 다이어그램으로 그려보았다.
우선, AWS를 주요 인프라로 구축을 하여 Kiensis Data Stream, Fire Hose, OpenSearch Service를 이용하여 그려보았다.

여기서 전제조건들이 몇가지 있다.

• 샌디는 여러 개발 조직을 가지고 있다.
• 우리는 드라이버 앱에서 보낸 위치정보를 가지고 실시간 위치를 사용자(User)에게 보내는 팀이다.
• 다른 부가적인 서비스(예를 들면 드라이버 정보관리, 사용자의 정보, 결재 내역 등은 그에 맞는 서비스 팀들이 구현 해 놓았다.

위의 다이어그램을 보면 굉장히 단순해 보인다. 우리팀은 드라이버 의 위치정보를 사용자 앱에 실시간으로 나타내어서 사용자의 GET요청이 없어도 위치추적을 할 수 있게 구현하는 것이 목표이다.

서비스 시나리오

1. (전제조건)사용자는 화물 운송을 위해서 드라이버와 매칭된 후 실시간 위치정보를 얻으려고 한다.
2. 드라이버는 매칭 후 픽업 위치로 이동한다. 이 때부터 위치전송이 시작된다.
3. 드라이버가 픽업 위치 근처로 도착하면 자동으로 사용자에게 알림이 전송된다.
4. 드라이버가 픽업 후 운송 중 일때, 일정 시간마다 위치를 업데이트 한다.
5. 드라이버가 목적지 근처에 도착하게 되면 사용자에게 알림이 전송된다.
6. 사용자는 드라이버의 위치를 수동적으로 업데이트 하지않고 자동으로 변경되는 위치를 확일할 수 있다.

위의 아키텍처에서 알림에 대한 내용은 반영되지 않았지만 추후 업데이트를 하여 퀄리티 좋은 서비스를 만들어 보려고 한다.

---

2. 아키텍처 구성요소 검토

1. 소비자는 예약 후, 매칭이 이루어진 드라이버의 실시간 정보를 받아올 수 있어야 합니다.
2. 드라이버 전용 앱은 별도로 구성하며, 위치 데이터 스트림이 JSON 형식으로 실시간으로 전송되어야 합니다.
3. 스트림 데이터 처리는 Kinesis Data Stream, Kinesis Data Firehose 사용을 고려해볼 수 있습니다.
4. 드라이버 위치 정보에 대한 로그는 Elasticsearch를 이용합니다.
5. 서비스 간의 연결은 서버리스 형태로 구성해야 합니다.

위의 다섯가지 요구사항에서 다양한 AWS서비스들을 사용하는데 추가적으로 사용하여야 할 서비스가 무엇인지, 어떻게 하면 서비스간의 흐름이 원활 할지 고민 하였다.

이러한 선택이나 고민들이 생길 때 이슈를 만들고 대괄호 안에는 시간을 정해서 팀에서의 의사결정을 하는 방법을 사용하였다.
또한 더 의논할 사항이 있으면 적극 Discussion을 사용했다.

배운 점

1. 정답은 없다.

서비스를 구현하는 것에는 정답이 없다고 깨달았다.
더 좋은 방법은 있지만 또 그것이 정답은 아니고 상황에 따라 바뀔 수 있는 대안들 이라고 생각했다.

그래서 서비스 구현이 목적이 되는게 아니라 해결해야 할 문제들이 무엇인지 파악하는 것이 왜 중요한지 다시한번 깨닫게 되었다.

2. 팀 워크

이런 프로젝트를 혼자 구현 하려면 가능은 할 수 있을지언정 매우매우 힘든 일이 될 것이다.
프로젝트 활동을 하며 팀원들이 서로서로 부족한 점 들을 보완하여 목표를 향해 작은 문제들을 해결하는 과정을 경험할 수 있는 기회가 생겼다는 것에 감사함을 느꼈다.

내일 할 일

1. 서비스 구현 구체화
2. 데모 서비스 구현 시도

---

끝으로

생각보다 쉬울줄 알았지만 예상 외로 진전이 더딘 느낌이다. 처음보다는 모호한 느낌이 줄어들었지만 아직 해결해야 할 문제들이 많아서 화이팅 해야 할 것 같다.
:)