안녕하세요 @realmankwon입니다.

현재 동작하는 봇의 비즈니스 로직에는 큰 문제가 없이 잘 동작하는 것을 확인했습니다.
하지만 아직까지 서비스의 중단 문제는 여전히 남아 있는 상태입니다.
관련해서 차주부터는 1~2개월동안 안정화를 위한 작업만을 할 계획입니다.
쉬는동안 생각했던 방안을 정리해 봅니다.

1 . Steem Api 응답 없음 문제 & 알림 기능개발 (자동 봇 재실행)

• HF21, HF22 이후 Steem Api 호출 후 응답이 없는 경우가 불특정하게 발생하고 있습니다.
  이로인해 가장 문제가 되는 것은 스팀 블럭을 저장하는 봇이 중단되는 현상입니다.
  KRWP 보상, SCTR 에어드롭이 저장된 블럭 정보를 이용한 서비스이다 보니 근거 데이터가 없으면 동작을 하지 않습니다.
  그래서 현재 가장 중요한 봇이 바로 스팀 블럭을 저장하는 봇입니다.
  이것을 해결 하기 위해서 생각한 것은 몽고 db 에서 마지막 블럭 번호가 3분 동안 변경이 없으면 봇을 재실행시키는 봇을 추가로 개발할 계획입니다.
  이때 봇을 재실행하기 전 알림을 보내도록 하여 현재 상태를 확인하도록 하는 기능도 개발 예정입니다.

2 . 봇 중단 후 블럭 정보 저장 문제(다건의 블럭 정보 입력)

• 블럭 정보 저장 봇이 중단되고 난 이후에 다시 블럭 정보를 하나하나 저장하는 체계이다 보니 그동안 처리되지 않은 데이터를 실행할때까지 오랜 시간이 걸리게 됩니다.
  현재 스팀 블럭을 한꺼번에 읽어서 저장하는 로직은 개발이 된 상태입니다.
  하지만 이때 가지고는 블럭은 블럭 헤더 정보만 가지고 오고 irreversible 정보는 가지고 오지 않습니다.
  몽고 db 에 저장할 때 중복 데이터가 들어가지 않도록 하기 위해서 블럭 정보를 저장하기 전에 해단 블럭 번호와 동일한 데이터를 다 지우고 블럭 정보를 저장하다 보니 블럭 헤더와 irreversible 정보를 동시에 입력하지 않으면 먼저 입력된 정보가 삭제되는 문제가 있습니다.
  이 부분을 해결을 하지 않으면 여러건을 한꺼번에 넣는 것을 실행하기가 힘이 듭니다.
  구조적인 부분을 변경해서 장애 발생 후에 다건의 블럭 정보를 입력하여 빠른 시간 안에 처리되지 못한 정보를 실행할 수 있도록 해야겠습니다.

3 . 대쉬보드

• 현재는 간단하게 다음과 같은 형태로 봇의 상태를 체크하고 있습니다.
  
  제가 초기 개발했던 봇의 마지막 실행 시간을 웹소켓으로 보내도록 한 것입니다.
  허접하지만 아침에 일어났을때 이 화면에서 무사히 실행이 되고 있으면 일단 안심입니다.
  시간이 갱신이 안 되면 서버에 접속하여 로그를 확인한 후에 재실행을 시킵니다.
  이 화면을 대쉬보드로 추가 개발을 할 예정입니다.
  웹 소켓 방식 외에 로그를 남겨서 추이를 보고 중단되었으면 해당 exception 이나 마지막 봇의 로그를 출력하는 방향으로 구상 중입니다.

4 . 로그 관리

• 현재 봇은 node.js로 모두 개발이 되었고 실행은 forever로 시켰습니다.
  각 봇마다 로그를 쌓고 있는데 장애 발생시 최대한 어떤 상태에서 에러가 발생했는지 쉽게 찾기 위해서 세부적으로 로그를 남기 상황입니다.
  그렇다보니 용량도 무시할 수가 없습니다.
  아직까지는 큰 문제가 되지 않지만 이 부분도 일자별로 로그를 남기고 일주일 이전 로그는 삭제하는 방식으로 수정을 하여 추후에 로그로 인한 디스크 용량 부족 문제가 발생하지 않도록 할 예정입니다.

안정화 관련해서는 이미 오래전부터 생각하고 있었지만 초반에 개발해야 할 것들도 많았고 제이콥님의 휴가로 대응을 하다보니 안정화가 점점 미뤄지고 있었습니다.
다음주면 제이콥님께서도 복귀를 하시고 서비스도 현재 상황에서는 정상적으로 운영중이기 때문에는 그동안 미뤄왔던 안정화를 시킬 예정입니다.
이 작업이 끝나고 나서도 예상치 못한 장애가 발생하겠지만 그래도 현재까지 나온 문제나 기본적으로 원래 해야할 안정화는 될 것 같습니다.