#193 프로젝트 할일, 해결할 문제들 추가 pt.2 (#195)

* Doc : 프로젝트 과제 한번 더 정리

* Doc : 프로젝트 과제 추가

readme.md

@@ -84,51 +84,39 @@
 - **뜻깊은 이벤트**
     - [2년차 개발자의 회고, 우아한 중계서비스 프로젝트의 실제 거인들을 만나다. #우아한중계서비스 #토이프로젝트 #회고 #개발자회고 #F-Lab](https://vince-kim.tistory.com/42)
 
-- **서비스 점검**
-  - info-service에서 주문관련 정보를 MongoDB에 저장하는 현재 방식은 어떤 장단점이 있을까? 다른 데이터스토어와의 차이점은?
-  - 라이더위치정보를 Redis 저장하는 것은 어떤 장단점이 있을까? 다른 데이터스토어와의 차이점은?
+- **현재 프로젝트의 장애 대응 역량**
 
-- **라이더 위치정보 서비스를 최적화하려면?**
-    - 하루 최소 1억건이 발생하는 라이더 위치 정보 데이터는 얼마나 최소화 할 수있을까?
-    - 라이더 위치 정보 데이터는 어떤 방식의 프로토콜을 사용해야 하는가?
-    - 라이더 위치 정보 서비스를 위한 최적의 데이터스토어는?
-    - 라이더 위치 정보 서비스를 위해 Redis가 최선인가? Redis의 특징, 트레이드오프, 장단점, 비교대상은?
+### :bicyclist: //Todo : 프로젝트를 통해 해결하려는 궁금증과 문제들
 
-- **가용성**
+- 가용성/Failure
     - 서비스의 가용성을 측정하는 방법은? 또는 서비스에서 만들어 볼 만한 가용성 지표들은?
+    - 서비스의 Failure를 최대한 빠르게 감지하는 전략은? 어떤 지표로 Failure를 정의해야하는가?
+    - 프로젝트에 적용가능한 Failover 전략들은 무엇이 잇을까? Failover의 성능 최적화 전략은?
     - 주문이 반드시 전달되야하는 중계서비스
     - 현재 서비스의 단일실패지점들은(SPOF)은? 해당 부분들을 어떻게 이중화를 해야하는가? 어떻게 테스트해야하는가?
     - 각 서비스별(info, relay, location, etc....) failover 전략은 무엇이 있을까? 어떻게? 왜?
-    - 장애는 예방이 아니라 관리하는 것. 장애 대비한 모든 대응방법을 생각해보자.
-
-- **중개서비스 (Relay-Service)**
+    - 장애는 예방이 아니라 관리하는 것. 장애에 대응가능한 대응방법을 생각해보자.
+- 테스트
+    - 배달의민족 서비스는 최저점 대비 100배까지 증가하는 점심, 저녁 피크타임 트래픽 스파이크를 어떻게 해결할까요?
+    - Failover 테스트 작성방법은?
+    - Chaos Engineering을 체험해보고 싶다면...?
+- 성능 개선
+    - 각 서비스의 스타트업 타입은 얼마나 빨라질 수 있을까?
+    - 위치정보서비스의 Redis 캐시는 얼마나 최적화 되어있을까?
+    - info,relay 서비스에 적용한 MongoDB는 최선의 선택일까? 다른 Document기반 데이터스토어와 비교했을때 어떤 장단점이 있을까? 다른 데이터스토어와의 차이점은?
+    - 라이더위치정보를 Redis 저장하는 것은 어떤 장단점이 있을까? 다른 데이터스토어와의 차이점은?
+    - 배달완료된 주문을 분리해야한다면? 배달완료된 주문정보 데이터를 서비스 성능에 부담을 주지않으며 이동시키는 방법은?
+    - SpringBoot의 내장 Netty Server는 어떻게 작성되어있지? 내가 직접 NIO 서버를 작성해서 주입하면 지금 성능을 향상 시킬 수 있을까?
+- 서버간 통신
+    - 메시지,이벤트 기반 비동기 통신은 왜 장애와 급증하는 트래픽에 강한걸까?
+    - 서버간 통신속도를 향상 시키는 방법은 무엇이 있을까?
+    - 서버 간 통신을 비동기로 변경하기. - 현재는 Sync 로 구현
+    - 기존 성능테스트에서 개선할 점들을 찾아내서 어떤 부분이 느렸고 왜 느렸는지 분석해나가기 (HTTP Duration, API Tracing, etc...)
+- 중개서비스 (Relay-Service)
     - 중개서비스가 다양한 클라이언트에게 이벤트(신규주문접수/라이더배정)를 전달하는 방법은?
-
-- **아키텍처, 설계**
-    - 왜 메시지,이벤트 기반 비동기 통신은 예상치못한 장애와 급증하는 트래픽에 강한걸까?
-    - 우아한 중계서비스도 비동기통신을 적용한다면...?
-
-- **내 서버의 스타트업 타입은 얼마나 빨라질 수 있을까?**
-
-- **서버간 통신속도를 향상 시키는 방법은 무엇이 있을까?**
-
-- **위치정보서비스의 Redis 캐시는 얼마나 최적화 되어있을까?**
-
-- **배달완료된 주문은 별도 분리가 필요합니다.**
-
-- **기존 성능테스트에서 개선할 점들을 찾아내서 어떤 부분이 느렸고 왜 느렸는지 분석해나가기**
-    - HTTP Duration, API Tracing w/ Zipkin, Pinpoint or AWS X-Ray.... dissect API requests etc...
-    - MongoDB Write I/O 최적화
-
-- **서버 간 통신을 비동기로 변경하기.** - 현재는 Sync 로 구현
-
-- **데이터베이스 MongoDB 부하방지**
-
-- **SpringBoot의 내장 Netty Server는 어떻게 작성되어있지? 내가 직접 NIO 서버를 작성해서 주입하면 지금 성능을 향상 시킬 수 있을까?**
-
-- **분산환경에서 여러 서비스들과 통신하는 과정을 경험하기**
-
-- **배달의민족 서비스는 최저점 대비 100배까지 증가하는 점심, 저녁 피크타임 트래픽 스파이크를 어떻게 해결할까요?**
-    - analyze service traffic change/variance then..... scale? up? out? queue?
+- 라이더 위치정보 서비스를 최적화하려면?
+    - 하루 최소 1억건이 발생하는 라이더 위치 정보 데이터는 얼마나 최소화 할 수있을까?
+    - 라이더 위치 정보 서비스에 활용가능한 데이터스토어는 무엇이있을까? Redis가 최선인가? Redis의 특징, 트레이드오프, 장단점, 비교대상은? 벤치마크
+    - 라이더 위치 정보 데이터는 어떤 방식의 프로토콜을 사용해야 하는가?
 
 <br>