이 보도는 에이팀 블레스/에이팀 연결/에이팀 이사무사 Advent Calendar 2018 17일째 보도입니다.업무 외의 기술적 도전을 보도하기 때문에 실제로 업무에 푹 빠지는 말도 가끔 한다.

배경

2016년 Qiita 광고 달력에 쓴 것처럼 Rundeck 관리 이사무사의 일괄 처리는 2년이 지났다.
마침 2년이 지났을 때 갑자기 런덱의 작업이 모두 실패하는 사태에 빠졌기 때문에 그 전말을 기록해야 한다.
참고로 Rundeck의 버전은 2.7.1입니다.2년 전에 넣었는데... 언제 3과가 됐나..

일어난 일

11월의 어느 일요일 밤, 스마트폰 화면에 런덱 작업 수행에 실패했다는 Chatwork 알림이 속속 들어왔다.
(여기서 Rundeck 작업이 실패했을 때 Webhook은 AWS의 API Gateway＆Lambda를 통해 Chatwork에 알림을 보냄)
뭔가를 생각하고 Rundeck 서버에 SSH로 로그인하면 뭘 하고 싶으면/tmp에 파일이 안 나온다는 메시지가 나타납니다.
/tmp와 전체 디스크 볼륨에 충분한 사용 공간이 있습니다...??
운영 체제를 다시 시작하십시오.
문제 없이 멈추고 시동을 걸다.
다시 시작하면/tmp에 파일을 쓸 수 있고 Rundeck 작업도 정상적으로 실행됩니다...
무슨 일이 일어났습니까?

원인

갑자기 생각났어요.
이노드일 수도 있어.

 $ df -i
ファイルシス   Iノード   I使用  I残り I使用% マウント位置
devtmpfs        503510     435 503075     1% /dev
tmpfs           506232       1 506231     1% /dev/shm
/dev/xvda1     3276800 3244430  32370   100% /

역시!빙고.
상술한 것은 리셋 후이기 때문에 그 전에 남은 inode는 이미 없습니다.
inode가 고갈되어 파일을 생성할 수 없어서 작업 수행에 실패한 것 같습니다.
그런데 어디에 그렇게 많은 서류가 있는지... 이렇게 조사를 생각하면/var/lib/rundeck/logs/rundeck/<Project名>/job/<Job ID>/logs/ 아래에 대량의 로그 파일이 생성되었습니다.
작업을 수행할 때마다 위의 디렉토리에서 <実行ID>.rdlog 및 <実行ID>.state.json 두 파일을 생성합니다.
현재 환경에서는 작업이 하루에 3000회 이상 실행되기 때문에 매일 6000개 정도의 파일을 생성하고 저장한다.
상기 df의 결과를 보면/inode의 최대 수량은 300만 정도인 것 같아서 500일까지 계산하면 꽉 찼다.작업의 정의수와 집행 횟수가 점차 늘어나는 것을 감안하면 딱 2년 정도면 충분하다는 것은 논리적이다.

해결 방법

이 로그 파일은 Rundeck의 API를 통해 삭제할 수 있을 것 같지만 작업의 실행 ID마다 일일이 삭제할 수 있거나 작업 ID마다 모두 삭제할 수 있기 때문에 시간이 많이 걸리거나 모두 사라지기 불편합니다.
OS 명령으로 로그 파일을 직접 삭제할 수 있는지는 알 수 없지만 cron에서 Rundeck으로 실행되는 글 읽기만 하면 작업 순환이 개미라고 판단한다.
(3계라면 로그의 유효기간과 자동 삭제 기능이 설치됩니까...)
실제로 파일을 삭제해도 Rundeck의 운행에 특별한 영향을 미치지 않는다.
에서 다음 명령을 실행하는 JOB를 Rundeck에 등록하여 매일 실행합니다.
반 년 이상 (185일) 전의 로그 파일을 삭제했습니다.

find /var/lib/rundeck/logs/rundeck/<Project名>/job/*/logs/ -type f -mtime +185 -exec rm {} +

이렇게 되면 당분간 이노드 고갈은 걱정할 필요가 없다.기쁘고 축하할 만하다!
하지만 반년 이상 전 실행 로그가 보이지 않는다고 생각하면 왠지 파일을 삭제해도 관리 화면에서 볼 수 있는데...
파일 외에 DB에도 기록되어 있나... 왜 이런 이중화를...
파일을 삭제해도 로그를 확인할 수 있다면 반년은 물론이고 더 짧은 시간 안에 파일을 삭제할 수 있다.
이것에 관해서 나는 더 이상 깊이 파지 않았다.

경품

등록된 JOB 수가 100개가 넘고 매일 3000회 이상 JOB를 실행하면 런덱을 켜는 관리 화면도 무거워진다.
JOB가 몇 분 간격으로 실행될 때마다 MySQL(RDS) 측 CPU는 100%가 됩니다.
Rundeck 서버를 분할해야 하는 것 아닌가 싶은데 성능을 조정할 수 없을 때 상기 로그 파일에서 여러 가지 조사를 했을 때 이 일대의 의론 를 발견했습니다.
마찬가지로 INDEX를 붙여 보았을 때 CPU 사용률이 급격히 떨어졌습니다(아래 그림의 11/18 22시 정도).

mysql> ALTER TABLE workflow_workflow_step ADD INDEX workflow_commands_id(workflow_commands_id);

여기 보도.
관리 화면도 움직이기 시작했다.기쁘고 축하할 만하다!

통지

A팀은 함께 활약할 우수 인재를 모집하고 있다.
관심 있으신 분은 꼭 그룹 채용 페이지 문의하세요!
내일은 이사무사 엔지니어웹 사이트 엔지니어 상세 정보 페이지가 등장한다.기대해주세요.