로그가 필요해 - 서론

개인 프로젝트를 진행 하던 중에 백엔드 파트 쪽 기능이 정상작동을 안한다는 것을 깨달았습니다.

 

로그를 보면 좀 더 쉽게 파악이 가능할텐데 그럼 어떻게 로그를 확인 및 수집할지 고민을 해보았습니다.

 

1. 어떤 로그를 확인하고 싶은지 결정

모든 과정을 마치 알고리즘 문제 풀때 반례 찾듯이 코드 한줄마다 로그를 수집하고 싶지 않아 기준을 정했습니다.

• 기능 단위 동작
• 에러 발생시 시간, 발생 위치, 해당 데이터

 

2. 로그를 띄우는 방법

1) 개발 할때 로그 확인

로그를 통해 entity 값을 확인하는 예제 코드

 

위 스크린 샷 처럼 IDE에서 Log를 찍고 그 결과를 보면 가능합니다.

하지만 이는 서비스를 배포하면 로그를 확인하는데 매우 제한적입니다.

 

장점 : 개발 단계에서 로그를 쉽게 설정할 수 있다.

단점 : 사실상 개발 할때만 확인이 가능하다.

 

2) 로그 발생 시, DB에 저장

    @Autowired
    UserService service;
    
    @Autowired
    DBConnection db;
    
    public String testfun(@PathVariable int number){
        String timeStr = getNowTime(); // 현재시간 가져오는 함수
        try{
            UserEntity entity = service.findByUserId(number);
            db.insertLog(timeStr, entity.toString());
            return entity.toString();
        }
        catch (Exception e){
            db.insertLog(timeStr, e);
            e.printStackTrace();
        }
        return "error";
    }

 

위 코드처럼 원하는 코드가 동작하거나, 예외사항이 발생했을 경우 DB에 해당 값을 넣는 방식을 생각했습니다.

테스트 할때는 무사히 잘 로그가 수집이 되었지만, 문제가 발생했습니다. 바로 DB의 테이블 락이였습니다.

 

로그 데이터를 MariaDB에 저장을 하였는데 만약 한 서비스에서 Insert를 하면서 테이블 락이 걸릴 경우 다른 서비스에서 로그를 기록하는데 원활하게 작동을 하지 않았습니다.

심지어 락을 건 서비스가 강제종료가 되어 다른 서비스가 정상처리 되었음에도 로그를 기록해야하는 기능 때문에,

무한대기에 빠지는 경우도 생겼습니다.

그래서 서비스에서 로그를 저장하는 기능을 분리해야겠다 생각했습니다.

 

장점 : 언제든 DB를 통해 로그를 확인 가능

단점 : 테이블 락이 걸릴 경우 다른 서비스에도 영향을 미침

 

3) Message Queue를 활용하기

앞선 방법으로 에러가 발생한 이유가 뭘까 곰곰히 생각하다가 구조적 문제라고 생각을 했습니다.

바로 로그까지 포함한 End-to-End 구조가 문제라고 생각했습니다.

 

그래서 IoT 프로젝트를 할때 사용했던 MQTT와 같은 구독,발행 구조를 사용하면 좋을거 같아 찾아봤습니다.

많은 Meesage Queue 프로그램들이 있었지만 그 중에서 kafka를 사용해보기로 결정했습니다.

 

수많은 기업들에서도 사용을 한다고 들어 그만한 장점이 있기에 채택한다고 생각하여 더 가점을 주고 아래와 같은 이유로 선정했습니다.

• Message Queue 방식 (당연한 이유)
• 데이터 유실이 타 프로그램보다 위험성이 낮음
• 데이터의 높은 가용성을 활용한 에러난 시점 이후부터 쉬운 복구

이유에 대한 근거는 아래와 같습니다.

 

• Meesage Queue 방식
  • → 로그 내용 던져놓고 서비스는 본인 할일 하기
• 데이터 유실에 대한 위험성 낮음
  •  → 로그 정보가 유실될 걱정을 덜 해도 됨
• 에러난 시점 이후부터 쉬운 복구
  • → 로그 시스템에 어떠한 에러가 발생하여 그 당시에만 중지가 되어도 그 이후 데이터는 계속 수집 가능

 

그러면 kafka는 무엇이며 어떻게 사용하는지, 로그 시스템을 위해 더 필요한 부가적인 서비스는 없는지 하나씩 알아봐야 할것 같습니다.