문제 상황
까비 슬랙 채널에 서버가 내려갔다는 제보가 들어왔다..!
원인
2023/10/16 오전 4시 30분 경에 서버가 내려간 것을 확인했지만 그라파나나 핀포인트를 확인해봐도 해당 시간에 이상 증상이 딱히 발견되지 않았다…
오전 4시 45분에 서버 인스턴스가 재가동되었다는 로그가 남아있었다.
하지만 왜 재가동되었는지 파악되지는 않았고, 현재까지 원인을 파악중이다.
사이트 공격?
서버 인스턴스가 내려갔을 시점 즈음에 서버에 공격이 있기는 했다. 하지만 이로 인해 트래픽이 크게 발생하였다면 모니터링 로그에 남아있었을텐데 그렇지 않았다..
단순히 brute force로 보안을 탈취하려는 늘 있는 악성봇 정도로 추측이 된다.
이 시간대가 아니더라도 로그를 보면 이러한 시도가 있었음을 확인할 수 있었다.
최종 해결
서버가 갑자기 재가동된 원인을 파악하지는 못했지만, 이렇게 예기치 못한 상황이 발생해서 서버가 재부팅되더라도 애플리케이션은 자동으로 정상화가 되어야 할 것이다.
하지만 이슈가 발생했을 당시, 정상화 루틴이 없어서 그대로 애플리케이션이 죽어있는 채로 6시간이나 흘렀다…!
애플리케이션이 정상화되지 않은 원인
크게 2가지 원인이 있었다.
1.
iptables 설정 초기화
iptables로 80으로 오는 요청을 애플리케이션 서버가 돌고 있는 4242로 포워딩을 해주고 있었는데, 서버 인스턴스가 재가동되면 iptables 설정이 초기화가 되고 있었다.
2.
도커 데몬 프로세스가 가동되지 않음
systemd으로 도커 데몬 프로세스가 활성화되지 않아, 서버 인스턴스가 재가동되더라도 도커 데몬이 실행되지 않았다.
게다가 배포용 docker compose 파일에도 애플리케이션 컨테이너의 restart 조건에 always가 빠져 도커 데몬이 실행된다고 하더라도 애플리케이션 컨테이너가 가동되지 않았을 것이다.
서버 인스턴스 재가동 시 애플리케이션이 정상화되도록 설정
1.
서버 인스턴스 재가동 시 iptables 로드
sudo yum install -y iptables-services
Bash
복사
iptables-services는 현재 iptables 규칙을 저장해두었다가 서버 인스턴스가 재가동될 때 저장했던 규칙대로 바로 적용하게 해주는 프로그램이다.
sudo iptables -t nat -L
Bash
복사
iptables로 관리되는 포트와 포워딩 설정을 확인할 수 있다.
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT
Bash
복사
80 포트에 대한 인바운드 규칙을 추가할 수 있다.
sudo iptables -I OUTPUT -p tcp --dport 80 -j ACCEPT
Bash
복사
80 포트에 대한 아웃바운드 규칙 추가할 수 있다.
sudo iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 4242
Bash
복사
80포트에서 4242 포트로의 리다이렉트 규칙을 추가할 수 있다.
sudo iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
Bash
복사
80포트에서 4242 포트로의 리다이렉트 규칙을 제거할 수 있다.
sudo service iptables save
Bash
복사
현재 iptables 규칙을 저장한다. 규칙을 변경할 때마다 수행해주어야 한다.
sudo chkconfig iptables on
Bash
복사
iptables 서비스를 시스템 시작 시 자동으로 시작되도록 설정한다.
2.
서버 인스턴스 재가동 시 도커 데몬 실행 및 컨테이너 재가동
sudo systemctl enable docker
Bash
복사
docker를 시스템 데몬으로 등록한다.
애플리케이션 컨테이너의 설정을 restart: always로 변경한다.