Floney

[플로니] 에러에 대비하는 서비스 만들기

딤섬뮨 2024. 1. 5. 18:33
728x90

플로니가 출시되고 약 1달이 흘렀다. 되게 오래된 것 같은데 1달밖에 안된 건가 싶기도 하고..ㅎ


향로님의 홍보( 경쟁력 있는 신입 포트폴리오 (tistory.com)  감사합니다..🫶) 그리고 소중한 지인들에게 강매(?)하고 지인들이 홍보해 준 덕에 다운자 수 약 300명과 가계부 내역은 약 1500개가 쌓이는 기적으로 인해 서비스 운영이라고 할 수 있게 되었다..!🍀🍀

플로니 팀은 런칭 이후 그동안, 재정비 시간, ver1에 대한 수정사항  및 ver2 일정을 의논했다.

그중 재정비 기간 동안, 서버팀은 에러에 대응하는 몇 가지 인프라 환경을 구축했다.
 
이 부분은 앱 런칭 전에, 운영을 위한 조언받은 것 중 하나였다.
그 당시엔 필요할까 싶었지만, 막상 운영을 하니 터지는 이슈마다, 아 그게 그 말이었구나 싶으면서도 정말 정말 정말 운영에 도움이 정말 많이 된다. 아니 필수적이다.
 
기능만 잘 만들어 놓고, QA 할 때처럼 API를 던지고, 처리해서 되는 게 아니다.
슬슬 유저가 생기다 보니 한사람이 트래픽을 하나 쏠 때랑 여러 명이 여러 개 쏠 때 나오는 잠재적인 이슈들이 터진다..ㅎ 
이제 서비스를 하는 입장에서는 그걸 빨리 해결해줘야 한다.
따라서, 내가 오늘 쓰는 글은 누구보다 플로니 서버팀이 에러를 빨리 해결해 주기 위해... 에러를 대비하는 서비스를 만들기 위해 구축한 것들에 대해 설명해보고자 한다
 
시작합니다🤗

1. 운영서버 에러 - 슬랙 연동


운영에 관한 조언을 받을 때쯤, 근데 ‘에러나면 어떻게 아세요?’라는 질문을 받은 적이 있다.
그때 내 대답은 ‘음 ios쪽에서 개발하다가 안되면 알려주신다’라고 했는데, 실제 운영 때도 그럴 거냐는 질문에 ‘엥.. 그러게요..??!!’라고 깨달음을 얻었다.

사용자가 에러난 즉시 고쳐야하는 타이머는 시작된다고 생각하는데, 일단 고쳐야 하는 시점조차 몰라 버린 상황이 되어버린..ㅎ

그래서 조언을 듣고, 에러가 터지면 슬랙으로 알람이 오게끔 연동해 놨다. 덕분에 생각지도 못한, 다양한 이슈들을 실시간으로 만날 수 있었고 hotfix를 파서 대응을 할 수 있었다. 한 가지 부작용이라면, 자꾸 슬랙 울릴 때마다 깜짝깜짝 놀란다…ㅋㅋ

에러 예시

 

2. 로그 (부제 : 로그를 찾아서..)


로그는 사실 운영에 필수적이다. 이미 지나간 데이터를 보기에 아주 최적이다.
사실 운영 전부터 로그는 개발 사항이였고,  LogBack을 사용해서 찍고 있다.
 
근데 운영을 시작하면서 이슈가 있었다.
로컬에서 테스트할 때는 로그 폴더로 날짜별로, level별로 아주아주 잘만 폴더가 만들어지면서 찍혔는데 EC2에만 배포하면, 로그 폴더가 안생기는 문제가 생겨서 역대 이슈 중 최장 삽질을 했다..(거의 2주?)
 
수동으로  EC2에서 테스트를 해도 잘만 생겨서 , CICD에서 문제가 있나 싶었다. 그렇게 올린 PR만.. 4-5개는 되는 듯.. #318 붙은 PR이 다 나의 로거.. 를 찾아서 떠나는 PR들.. 그 PR들을 간단히 이야기해 보면

 
 
 
1. 가설 1. logback-spring.xml 자체의 문제이다.
 
우선 로컬에서는 너무나도 정상 작동하는 xml이었다. 또한, Log Back xml에 console 관련 설정도 했었는데 console설정은 적용이 잘되고 있어 Ec2에서 xml을 못 읽는다? 는 가설은 아니었던 것 같다.  
 
2.  가설 2. CI/CD에서 생기는 권한 문제이다.
근본적으로 문제는 로그 폴더가 생기지 않는다는 것이다.
무엇인가 생기지 않는다면, 권한 문제일 가능성이 크다. 그러던 중 다음과 같은 글을 보았다.
logback-spring.xml 설정 이후 배포 실패 (tistory.com)
 
이 글을 보고 권한 문제라는 나의 가설에 힘을 얻어 여러 생각을 해봤다.
 
[ 로그 폴더가 안 생기는 원인이 권한 문제인 근거를 찾았다..]
생각해 보니 CI/CD로 jar 폴더를 deploy 할 때 우분투의 root 경로에서 배포를 한다. root 경로는 sudo 권한이 있어야 명령어를 수행할 수 있다

<included>
    <appender name="FILE-ERROR" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>./log</file> // 로그 폴더가 생성되는 경로
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>ERROR</level>
        </filter>
        <encoder>
            <pattern>${LOG_FILE_PATTERN}</pattern>
        </encoder>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>./backup/error/error-%d{yyyy-MM-dd}.%i.log</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <maxHistory>30</maxHistory>
            <totalSizeCap>3GB</totalSizeCap>
        </rollingPolicy>
    </appender>
</included>

그 당시 로그 폴더가 생성되길 원하는 경로는./log로 root 경로에 생성을 하고자 했다.
실제 root경로에서 deploy 명령어를 수행하면 다음과 같이 log 폴더를 만드는데 실패했다는 에러가 난다.

 
 
(2) 권한 해결 삽질 1 (실패)
sudo 명령어를 사용해서 빌드를 하면 되지 않을까 했는데 실패했다.

실패

 
 
(3) 권한 해결 삽질 2 (실패)
 code deploy는 755 권한으로 실행되고 있었고, 해당 소유자 외에 다른 사용자(프로세스)는 해당 파일에 권한이 없어 로그 파일이 안 생기나?라는 가정을 통해 777 권한을 줘보았다. 하지만, 이것도 실패

 
 
(4) 권한 해결 삽질 3 - 그냥 최상위  root 경로 말고 하위 경로에 로그를 생성하면 어떨까?? (성공)

 



그렇게 로거 폴더를 다시 돼 찾았다.. 이쁘게 잘 찍히고 있다.. 블로그엔 정리된 몇 가지 삽질만 올리지만, 정말 별 짓을 다했던 것 같다..ㅎ... 되찾아서 너무 행복했다!

소중한 나의 로거 파일



3. 모니터링 서버


지난번에 올렸었는데,  서버가 자꾸 죽는 이슈가 있었다.

2023.10.03 - [Floney] - [플로니] 서버야 왜 자꾸 죽니


이 문제도 서버 자체의 문제였는데, 이미 지나간 상황이라 재현도 안되고 hikari pool 문제인 것 같아도, 지나간 일에 대한 파악도 잘 안 되고 여러모로 애를 먹었었고 그 당시 결론은 모니터링 서버를 구축합시다! 였다

그래서 이번 재정비 기간에 프로메테우스 + 그라파나를 통해 모니터링 서버를 올렸다.

운영서버 로컬에 모니터링 서버를 구축하는 방법과, 모니터링 서버를 따로 올리는 방법 중에 고민을 하다가, 아무래도
비용이 조금 들긴 하지만, 전자는 운영서버가 죽으면 모니터링 서버가 같이 죽어버리는 단점이 있기에, 후자의 아키텍처를 택했다. 
 
다음과 같이 개발 서버와 운영서버의 데이터를 모니터링 서버에서 수집한다.
 

프로메테우스에서 수집한 데이터를 그라파나로 보여줌으로 한눈에 볼 수 있다.

 

 

그라파나에서 알람을 설정하면, 특정조건이 위배되었을 때 슬랙, 메일로 받아볼 수 있다.

예를 들어, 서버가 다운 되었는지 체크하는 조건을 다음과 같이 걸어두면 알람을 받아볼 수 있고, 무한정 알람이 계속 오는 게 아니라

특정 에러가 위배될 경우 notification policy에서 몇분동안 지켜보다가 다시 에러를 뿜을지 같은 설정도 할 수 있다. 

 

예시로, 우리 서버는 항상 up{jobup {job = "floney_monitor"} = 1인데, 일부로  up {job = "floney_monitor"} < 2 일경우 에러가 나게 해 보았다.

 

 

 

우리 서버가 정상적으로 켜져있다면 항상 1일 테니, 에러가 잘 날아오게 된다.

만약 IS BELOW 값을 다시 1로 초기화한다면 알람이 더 이상 날아오지 않고, 아까 지켜보던 에러는 해결되었단 메시지도 함께 오게 된다


앞으로 이런 인프라들을 가지고 에러에 잘 대응하고 예방하며 원활한 서비스 운영을 하길 바란다. 그동안 만난 많은 에러는, 잘 정리해서 포스팅해 보겠다🤣 

728x90