Community

개발자 99% 커뮤니티에서 수다 떨어요!

← Go back
Assignment 9 - MISSION (2022. 5. 23.)
by pksl
#pragmatic
2년 전
860

(1..23) 중에 랜덤으로 하나를 골랐더니 20번이 뽑혔다.

연습문제 20 (p.205)

네 가지 전략 중에서 다음 상황에 맞는 것은 각각 어떤것일까? 여러 전략을 조합해야 할 수도 있다.

Q. 5분 동안 ‘네트워크 인터페이스가 꺼짐’ 이벤트를 세 번 받으면 운영 직원에게 알려라.

다음과 같이 문제를 4분할로 분석할 수 있다고 생각한다.

  1. 네트워크 인터페이스가 꺼진 상황이

  2. ‘5분 동안’이라는 시간 내에

  3. 이벤트가 ‘세 번’ 누적되면

  4. 운영 직원에게 알림

우선 유연하게 설계하자면 인터페이스가 꺼진 상황을 감시하는 기능과 알림 전파 기능은 그대로 두지만, 시간 범위와 이벤트 누적 횟수는 변경이 가능하도록 해야한다.

또한 중요한 점은 이벤트를 데이터로서 쌓는 것이다. 쌓아두고 그중에 특정 시간 범위에 몇 건의 이벤트가 있는지 확인하는 가장 적합한 방법은 ‘이벤트 스트림 처리’같다고 생각한다.

HealthCheck가 일정 주기로 수행되면서 네트워크 인터페이스가 꺼진 것을 확인 한 경우에는 이벤트를 발생시키고, 해당 이벤트를 수신하여 기록(저장)해둔다.

기록 후에는 설정된 값인 ‘최근으로 부터 5분’ 그리고 Unhealthy 상태가 ‘세 번’ 쌓였는지 판단하여 알림을 보낼지 말지 결정한다.

운영 직원이 알림을 받을 수 있는 창구는 수시로 바뀔 수 있는 정보이기 때문에 코드와는 최대한 분리된 ‘게시-구독’ 으로 가는게 제일 올바른 방법이라 생각한다.

A. 이벤트 누적 감시 → ‘이벤트 스트림 처리’ , 운영 직원 알림 → ‘게시-구독’

Q. 일몰 후에 층계 밑에서 동작이 감지된 다음 층계 위에서 동작이 감지되면 위층의 전등을 켜라.

다음과 같이 문제를 4분할로 분석할 수 있다고 생각한다.

  1. 일몰 후에

  2. 층계 밑에서 동작이 감지된 ‘다음’

  3. 층계 위에서 동작이 감지되’면’

  4. 위층의 전등을 ON

우선 주어진 정보가 너무 부족한 것 같다. 전등은 얼마나 켜둬야 하며, 복도만 그냥 지나간 경우 인식한 정보는 언제까지 보관해야하는지, 계단에서 멈춰 계속 모션을 감지하게 경우 계속 위층의 불을 켜야 하는지 등등..

우선 대충 간단한 요구사항만 만족시키는 방향으로 접근하게 되면 각 층별로 복도와 계단에 각각 모션 감지 디바이스가 있다고 이해할 수 있다. ‘1층의 복도에서 모션을 감지 → 1층의 계단에서 모션을 감지 → 2층의 전등을 켬’ 이라는 메커니즘으로 접근해보자.

아무래도 건물 전체에 대한 이벤트를 전달받는 방식으로 접근하는게 좋아보인다. 한 층에서 이벤트가 끝나는게 아닌, 다음 층의 전등 제어까지 이루어지기 때문이다. 그렇게 할 경우 ‘이벤트 스트림 처리’가 어울릴 것 같다고 생각한다. 동시에 여러 층에서 동작이 이루어질 수도 있기 떄문이다.

우선 모든 모션 감지 이벤트는 일몰 전일 경우엔 전부 무시하고 일몰 후부터 이벤트를 처리한다. 특정 층의 복도에서 이벤트를 전달받는 경우 계단 감지 대기 상태로 설정해둔다. 특정 층의 계단에서 이벤트를 전달받는 경우 이전 상태가 계단 감지 대기 상태일 경우 위층의 불을 켠다.

이와 같은 상태의 흐름은 ‘FSM’으로 구현이 가능할 것으로 보인다.

A. 상태 관리 → ‘FSM’ , 동작 감지 이벤트 통합 처리 → ‘이벤트 스트림 처리’

Q. 다양한 보고 시스템에 주문이 완료되었음을 알린다.

간단히 요약하자면 다음과 같다.

  1. 주문이 완료 됨

  2. 다양한 보고 시스템에 전파

위에서 운영 직원에게 네트워크 인터페이스 꺼짐 알림을 전달할 때 처럼 ‘게시-구독’ 이 올바른 것으로 보인다.

A. 보고 시스템 전파 → ‘게시-구독’

Q. 고객에게 자동차 대출을 집행할 수 있는지 평가하기 위하여 애플리케이션이 세 가지 다른 서비스에 요청을 보내고 응답을 기다려야 한다.

여기서 필요한 정보는 다음과 같다.

  1. 각 서비스에 요청을 보내고

  2. 결과를 취합해서

  3. 평가

병렬적으로 요청을 처리하고 최대한 빠르게 평가로 진입하게 위해선 ‘이벤트 스트림 처리’ 를 적용하는게 올바르다.

A. 각각의 서비스에 요청을 보내고 취합 → ‘이벤트 스트림 처리’

연습문제 해답 (p.425)

  • 5분 동안 ‘네트워크 인터페이스가 꺼짐’ 이벤트를 세 번...... 상태 기계로 구현하는 것도 가능하기는 하다. 하지만 처음에 생각했던 것 보다는 조금 까다로운 면이 있을 것이다. 예를 들어 1분, 4분, 7분, 8분에 각각 이벤트가 발생했다고 하자. 그렇다면 네 번째 이벤트가 발생했을 때 경고를 울려야 할 텐데, 그러려면 상태 기계가 이벤트 없이도 스스로 상태를 바꿀 수 있어야 한다. 그래서 이 경우에는 이벤트 스트림을 사용하는 편이 낫다. size와 offset 파라미터를 받는 buffer라는 반응형 함수를 사용하면 이벤트가 발생할 때 마다 최근 이벤트 세 개를 묶어서 전달받을 수 있다. 그러면 묶음의 첫 이벤트와 마지막 이벤트의 발생 시각을 보고 경고를 울려야 할지 판단할 수 있을 것이다.

  • 일몰 후에 층계 밑에서 동작이 감지된 다음 층계 위에서 동작이 감지되면...... 아마 게시-구독과 상태 기계를 조합하여 구현할 수 있을 것이다. 게시-구독을 사용하면 여러 상태 기계에 이벤트를 퍼트릴 수 있고, 상태 기계가 이런 이벤트를 받아서 어떻게 할지 판단하면 된다.

  • 다양한 보고 시스템에 주문이 완료되었음을 알리고...... 아마 게시-구독 모델이 가장 좋을 것이다. 스트림을 사용할 수도 있지만 그러려면 알림을 받는 보고 시스템도 스트림 기반이어야 할 수도 있다.

  • 세 가지 다른 서비스에 요청을 보내고 응답을 기다려야 한다. 이것은 본문에서 사용자 데이터를 받아 오기 위해 스트림을 사용한 예제와 유사하다.

오답 노트

나머진 얼추 비슷한데 두번째 문항이 틀렸다… ‘게시-구독’ 으로 접근하지 못했다.

답을 보고서 다시 생각해보니 ‘게시-구독’ 이 훨씬 나은 모델일 수 밖에 없는게, 통합으로 관리하는 프로그램을 만들어버리면 그에 대한 유지 보수 비용이 생겨난다. 하지만 각각 채널을 구독하고 전파하는 방법으로 처리하면 통합 관리 프로그램이 불필요해진다.

동시에 여러군데에서 이벤트가 발생할 수 있는 복잡도에 대해 설명까지 해두고 ‘게시-구독’ 에 생각이 닿지 못한게 아쉽다.