docs : Alert와 Monitering 추가로 인한 README.md Update (#109)

README.md

@@ -4,10 +4,11 @@
 출결 관리 서비스 I'm here! 입니다 <Br>
 수업을 개설하고, 학생의 출결을 관리해요! <br>
 
-지금 바로 출석하러 가기 -> [https://imhere.im](https://imhere.im)
+## 지금 바로 출석하러 가기 -> [https://imhere.im](https://imhere.im)
 
+<br>
 
-## GDSC Hongik 웹 기초 스터디의 출석 문제를 해결했습니다!
+## 1.1 GDSC Hongik 웹 기초 스터디의 출석 문제를 해결했습니다!
 동아리 GDSC Hongik에서 웹 기초 스터디 강의를 맡게 되었습니다. <br>
 **처음 동아리에선 약 20여명의 수강생을 예상했으나, 실제로는 140명의 신청자가 있었습니다.** <br> <br>
 
@@ -20,7 +21,9 @@
 - [<b>기초 웹 스터디 강의 소개 페이지</b>](https://www.gdschongik.com/web-study/introduce)
 - [<b>수업과 실습 영상 유튜브</b>](https://www.youtube.com/watch?v=KpxVNBJ9UDw)
 
-### 시간과 에너지의 절약했습니다
+<br>
+
+### 1.2 시간과 에너지의 절약했습니다
 개발 일정이 늦어져서, 처음에는 직접 이름을 호명하며 출석을 체크했습니다. <br>
 첫 수업에 참석한 학생의 이름을 하나하나 호명하고 얼굴을 확인하면서 수업을 시작하기 전부터 지치게 되었습니다. <br>
 10분이 넘는 시간과 많은 에너지가 소모되었습니다. <br> <br>
@@ -32,13 +35,26 @@
 
 <br>
 
+### 1.3 유저와 소통하기 위해 노력합니다.
+
+<br>
+
+사용자들이 직접 사용하는 서비스인 만큼, 여러 경로를 통해 피드백을 받고, 반영하기 위해 노력합니다.
+
+
+![피드백](https://github.com/binary-ho/imhere-server/assets/71186266/9340ffde-0bae-4b8a-b107-4a81e9ca7200)
+
+
 # 2. 서비스 기능 소개
 ### [Wiki 바로 가기](https://github.com/binary-ho/imhere-server/wiki)
 
+<br>
+
 # 3. 인프라 구조와 설명
 
-![image](https://github.com/binary-ho/imhere-server/assets/71186266/98c434fe-c34f-42f7-bf48-aca19422516b)
+<br>
 
+![imhere2 drawio](https://github.com/binary-ho/imhere-server/assets/71186266/63912ddf-6d75-4339-8ec6-4d7730706f08)
 
 
 프론트엔드 프로젝트와 백엔드 프로젝트를 직접 구현하고, 배포했습니다.
@@ -53,8 +69,10 @@
  카디널리티가 높은 컬럼에 인덱싱을 적용하여 6.4872초 만에 모든 요청이 성공. 그러나 6.4872초도 사용자 입장에선 느린 응답일 것으로 생각되어, 다른 인덱싱 방법을 고려. 커버링 인덱스나 복합 인덱스를 고려했으나, 인덱싱이 차지하는 용량에 비해 큰 응답 시간 개선이 이루어지진 않았음. 결국 DB I/O를 줄이기 위해 캐싱을 도입하게 됨. <br> <br>
 ▪️ 캐싱 적용 : 0.1434초로 응답 시간 개선. <br>
  수강생들의 조회 요청이 몰리는 상황 직전에 수강생들의 정보를 캐싱하여 0.1434초로 응답 시간을 개선. 강의 데이터는 Hash 자료형으로 저장하고, 수강생 정보는 하나의 Redis Collection에 수강생 정보를 모두 저장하는 경우, 삭제시 Redis 스레드가 오랜 시간 점거될 수도 있으므로, 개별 String 형태로 저장. <br> 수강생 캐싱은 오직 수업을 여는 것이 성공했을 때만 캐싱되어야 하며, 강사는 캐싱 때문에 응답을 늦게 받아선 안 된다. 그리고 캐싱 실패로 인해 강의를 여는 행위가 실패할 필요는 없다. 따라서, 캐싱은 이벤트를 발행해 개별 트랜잭션에서 비동기적으로 수행하게 만들었다. 
-- 학생들의 출석 체크 과정에서 수강 신청 정보를 가져오는 과정의 소요 시간을 인덱싱을 통해 개선했습니다. 수강 신청 정보 테이블의 외래키인 학생 id에 인덱스를 적용했습니다. 이후, 자바 동시성 컬렉션을 이용해 10만 건의 데이터 중 1000건을 동시에 조회하는 테스트를 진행했더니, 기존엔 600건 이상 실패하던 작업을 인덱스 적용 이후 6.4872초 만에 처리할 수 있게 되었습니다.
+- 학생들의 출석 체크 과정에서 수강 신청 정보를 가져오는 과정의 소요 시간을 인덱싱을 통해 개선했습니다. 수강 신청 정보 테이블의 외래키인 학생 id에 인덱스를 적용했습니다. 이후, 자바 동시성 컬렉션을 이용해 10만 건의 데이터 중 1000건을 동시에 조회하는 테스트를 진행했더니, 기존엔 600건 이상 실패하던 작업을 인덱스 적용 이후 6.4872초 만에 처리할 수 있게 되었습니다. <br> <br>
+
 - 유연한 설계와, 회귀 방지를 위한 테스트 작성을 위해 의존성 역전을 적극적으로 활용했습니다. RedisTemplate과 JavaMailSender를 사용하거나, 토큰 생성을 위해 SECRET을 사용하는 객체들을 인터페이스로 추상화하였습니다. 구현체는 빈으로 관리하고, 호출하는 쪽에서는 추상화된 인터페이스를 의존하도록 구현하였습니다. 테스트 시엔 인터페이스를 구현한 Fake 객체를 활용했습니다.
+- 서버가 접속 불가 상태가 되는 문제를 해결하고, 알림을 받기 위해 모니터링과 알림을 도입했습니다. 다운시 디스코드로 알람이 옵니다.
 - 학생과 강사의 사용 가능한 기능을 분리하기 위해 스프링 시큐리티를 통해 인증 기능을 구현했습니다. 서버를 stateless 하게 유지하면서도 회원이 편리하게 이용할 수 있도록 토큰을 활용해 인가 기능을 구현했습니다.
 - 문제 상황 추적을 위해 로깅을 진행하였습니다. 처음엔 일반 출력문을 사용하다가, 파일로 보관하기 위해 로깅 프레임워크를 도입했습니다. 스프링 부트가 기본으로 제공하는 logback 대신 log4j2를 사용하였습니다. 로그는 날짜를 기준으로 파일에 저장되며, 지정 용량을 초과하는 경우 동일한 날짜라도 별도의 파일에 보관됩니다.
 로그로 인해 회원가입 메일이 오지 않는다는 회원의 컴플레인이 서버 문제가 아님을 확신할 수 있었습니다.