# 배포 후 문제 발생 시 대처 및 롤백

ROS2 Humble 기반의 패키지를 배포한 뒤, 예상치 못한 문제나 장애가 발생하는 경우가 종종 있다. 이러한 상황에 적절히 대응하기 위해서는 빠른 문제 원인 진단과 긴급 패치(Hotfix), 그리고 경우에 따라 롤백(Rollback) 메커니즘을 숙지해야 한다. 본 장에서는 배포 후 발생할 수 있는 대표적인 문제 유형을 살펴보고, 이를 해결하거나 패키지를 롤백하는 절차와 전략을 자세히 다룬다. 실제 운영 환경에서 발생하는 문제는 단순히 코드의 오류뿐 아니라, 구성(Configuration), 종속성(Dependency), 통신(QoS) 문제 등 매우 다양하므로 상황별로 대응 방안을 준비해야 한다.

#### 문제 진단과 로그 확인

배포 후 문제가 발생했을 때, 가장 먼저 해야 할 일은 로그 확인과 증상에 대한 분석이다. ROS2 Humble에서 노드와 토픽을 진단하는 대표적인 방법을 살펴보자.

**ROS2 CLI(명령줄) 활용**:

다음과 같은 명령으로 노드 동작 여부를 확인한다.

```
ros2 node list
ros2 node info <노드명>
```

토픽 데이터를 실시간으로 모니터링하고 싶다면:

```
ros2 topic list
ros2 topic echo <토픽명>
```

서비스 호출이 필요한 경우:

```
ros2 service list
ros2 service call <서비스명> <서비스타입> "{요청데이터}"
```

**시스템 레벨 로그**:

ROS2 자체 로그뿐 아니라, 시스템 레벨의 로그(예: Linux에서는 `journalctl`, `dmesg` 등)를 함께 확인한다.

다음은 `journalctl`의 예시:

```
journalctl -u <ROS2-서비스-유닛명>
```

컨테이너나 VM 환경에서 구동 중이라면, 호스트와 컨테이너 각각의 로그를 모두 확인해야 한다.

**네트워크 점검**:

ROS2에서는 DDS를 사용하므로, 네트워크 설정이나 방화벽, QoS 설정 문제로 인해 통신이 불안정할 수 있다.

문제 발생 시 ROS\_DOMAIN\_ID 설정, TCP/UDP 포트, 멀티캐스트 설정 등을 재점검한다.

**QoS(품질 서비스) 분석**

특정 토픽에 신뢰( Reliability ) 또는 내구성(Durability) 옵션이 잘못 설정되어 있으면 통신 장애가 발생할 수 있다.

예시로, 내구성 있는 퍼블리셔가 많은 데이터를 축적하고 구독자가 늦게 연결되면, 큐가 꽉 차서 지연이 발생하거나 연결 실패로 이어질 수 있다.

이처럼 문제 진단을 위해서는 ROS2 CLI, 시스템 로그, 네트워크 상태, QoS 설정 등 다각적인 시야가 필요하다. 문제 원인을 정확히 파악한 후에야 올바른 대처 방법을 적용할 수 있다.

#### 긴급 패치(Hotfix) 적용

운영 환경에서 치명적인 문제가 발생한 경우 빠르게 대처해야 한다. 간단한 버그 수정이라면 단시간 내에 긴급 패치를 적용하는 전략을 쓴다.

**빠른 수정 및 재배포**:

* 문제가 발생한 특정 모듈을 최소 단위로 수정하고, 기능 테스트와 단위 테스트를 거친 뒤 재배포한다.
* 이는 크고 복잡한 수정보다 위험도가 낮으며, 장애 해소를 목표로 한다.

**버전 관리**:

* 긴급 패치도 버전 태그를 부여해 추적이 가능하도록 해야 한다.
* 예: Git 태그로 `v1.0.1-hotfix` 등의 이름을 부여하여 별도의 브랜치에서 작업 후 머지(Merge)하거나, patch 브랜치를 운영한다.

**테스트 환경에서 검증**:

* 긴급 패치라도 반드시 사전 테스트를 거친 뒤 운영 환경에 반영한다.
* 로컬 환경, CI/CD, 스테이징 환경 등에서 문제가 없음을 확인한 뒤 최종 배포한다.

긴급 패치를 통해 일시적으로 문제를 해결할 수 있지만, 근본적인 원인 분석과 장기적인 대응책을 마련하지 않으면 추후에 동일한 문제가 재발할 수 있다.

#### 롤백(Rollback) 개념

롤백은 새 버전의 배포 후 문제가 해결되지 않거나 오히려 더 심각한 에러를 야기할 경우, 이전 안정 버전으로 되돌리는 행위이다. 이는 서비스 가용성 측면에서 매우 중요한 전략이다.

* **즉시 롤백(Immediate Rollback):** 새 버전 배포 후 심각한 장애가 발생하면, 장애 확산을 막기 위해 즉시 이전 버전으로 되돌리는 방식이다.
* **점진적 롤백(Gradual Rollback):** 배포가 순차적으로 진행되거나, 일부 노드만 새 버전으로 업데이트된 경우, 문제가 확인된 노드만 이전 버전으로 되돌리고 나머지 노드는 계속 새 버전을 사용한다.

롤백은 단순히 코드를 이전 버전으로 돌리는 것이 아니라, 해당 버전에 맞는 설정 파일, 의존성 패키지, 네트워크 구성 등을 모두 원래 상태로 복원하는 과정이다.

#### 롤백 절차

배포 후 문제가 심각하고 빠른 조치가 필요할 경우, 아래 단계를 거쳐 롤백을 수행한다. 운영 환경마다 세부 절차는 다를 수 있지만, 크게는 이전 버전 식별, 구성 복원, 재배포, 검증 과정을 거친다.

**이전 버전 식별**:

* 가장 최근에 안정적으로 동작하던 배포 버전을 정확히 확인한다.
* ROS2 패키지의 버전 정보, Git 태그, Docker 이미지 태그 등을 통해 대상 버전을 식별한다.

**구성(Configuration) 복원**:

* 해당 버전에서 사용하던 설정 파일, 환경 변수, 종속성 목록 등을 다시 적용한다.
* 네트워크 설정, QoS 정책, 노드별 리소스 할당 등이 변경되었을 수 있으므로 이전 상태를 모두 복원해야 한다.

**배포 환경 재조정**:

* 새 버전을 롤백하기 위해서는 현재 운영 중인 노드를 종료한 뒤 이전 버전 노드로 교체한다.
* 예: Docker 컨테이너 환경인 경우, 새 이미지를 중지한 뒤 이전 이미지로 재시작한다.

  ```bash
  docker stop <new_version_container>
  docker run -d --name <old_version_container> <repo>:<old_tag>
  ```
* 시스템 서비스 단위(unit)로 관리하는 경우에는 서비스 재시작 시 유닛 파일 또는 실행 스크립트를 이전 버전으로 돌려야 한다.

**롤백 후 검증**:

* 롤백된 노드가 정상 동작하는지 ROS2 CLI로 노드 상태, 토픽 퍼블리시/구독 여부를 점검한다.
* 이후 시스템 로깅 툴을 사용하여 에러 발생 여부, 리소스 점유 상황 등을 모니터링한다.

**추가 오류 및 데이터 불일치 모니터링**:

* 롤백 과정에서 데이터베이스 스키마 또는 메시지 구조가 바뀌었다면, 이전 버전과의 호환성 문제를 야기할 수 있다.
* 데이터 및 상태가 불일치하는 부분이 있는지 지속적으로 모니터링하고 필요하면 수동 조정 혹은 마이그레이션 스크립트를 적용한다.

#### 롤백 자동화

수작업으로 롤백 절차를 수행하면, 긴급 상황에서 잘못된 버전을 복원하거나 설정 파일을 누락하는 등 실수가 발생하기 쉽다. 자동화된 도구와 프로세스를 마련해 두면 롤백 시간이 단축되고 정확도가 높아진다.

**CI/CD 파이프라인 확장**

* 일반적으로 CI/CD는 새 버전 배포만을 자동화한다. 여기에 ‘롤백’도 가능하도록 워크플로우를 설계한다.
* 예: GitOps 방식(Argo CD, Flux 등)을 활용하면, 특정 Git 태그나 커밋으로 돌아가는 과정을 자동화할 수 있다.

**버전별 아티팩트(Artifact) 관리**

* ROS2 패키지나 Docker 이미지를 버전별로 레지스트리에 보관해두면, 롤백 명령 실행 시 레지스트리에서 대상 버전을 자동으로 가져올 수 있다.

**에러 모니터링 연동**

* 배포 후 에러가 감지되면 자동으로 알림을 보내고, 심각도에 따라 스크립트가 자동으로 롤백을 수행하도록 설정할 수 있다.
* 단, 자율 롤백이 항상 최선은 아니므로, 경우에 따라서는 알림만 보내고 운영팀이 직접 확인 후 롤백을 진행하는 형태가 안전하다.

#### 롤백 시 고려해야 할 사항

롤백을 진행하기 전에, 현재 운영되고 있는 프로세스나 서비스가 얼마나 민감하게 영향을 받을지 평가가 필요하다.

* **데이터 호환성**: 메시지 형식 혹은 프로토콜이 바뀌었다면 이전 버전과의 호환 여부를 반드시 체크해야 한다.
* **트랜잭션 유실**: 새로운 버전에서 생성된 데이터가 이전 버전에서 유효하지 않을 가능성을 고려한다.
* **의존성 버전 충돌**: 특정 라이브러리나 DDS 설정이 바뀐 경우, 이를 되돌릴 수 있는지 확인한다.

#### 블루-그린(Blue-Green) 및 카나리(Canary) 전략 활용

무중단 배포를 위해 블루-그린 또는 카나리 배포 방식을 사용하면, 롤백 또한 훨씬 쉽게 진행할 수 있다.

**블루-그린 배포**

* 현재 동작 중인 ‘블루’ 환경과, 새 버전을 배포할 ‘그린’ 환경을 동시에 준비한다.
* 문제가 발생하면 바로 블루 환경으로 트래픽을 되돌려서 롤백한다.

**카나리 배포**

* 전체 노드 중 일부(카나리)만 새 버전으로 업데이트하여 모니터링한다.
* 장애가 없음을 확인한 후 점진적으로 확대 배포를 진행한다.
* 카나리 그룹에서 문제가 발견되면, 해당 그룹만 이전 버전으로 되돌린다.

이런 전략들은 대규모 시스템에서도 배포 리스크를 줄이고, 문제가 발생했을 때 신속한 롤백을 가능하게 한다.

#### 부분 롤백(Partial Rollback)

복잡한 ROS2 시스템에서 모든 노드를 동시에 롤백하기보다는, 문제가 발생한 특정 노드나 기능만 이전 버전으로 되돌리는 상황이 흔히 발생한다. 이를 ‘부분 롤백’이라고 부른다.

1. **문제 구역 명확화**
   * 시스템 전체를 분석해 어느 노드, 어떤 패키지에서 문제가 발생했는지를 분명히 파악한다.
   * 이를 위해 에러 로그, 토픽 스트림, 서비스 호출 상태 등을 종합적으로 검토한다.
2. **의존 관계 검토**
   * 문제가 된 노드가 다른 노드와 긴밀하게 연동될 경우, 해당 노드를 롤백할 때 의존 노드에도 영향을 끼칠 수 있다.
   * 예: 메시지 타입이 변경된 상태라면, 해당 메시지를 구독하는 노드도 롤백이 필요한지 확인해야 한다.
3. **테스트 후 제한적 교체**
   * 문제 노드만 이전 버전으로 교체한다.
   * 교체 후 ROS2 CLI 명령이나 자동화된 테스트 스크립트를 통해 정상 동작을 빠르게 검증한다.
4. **추가 모니터링**
   * 부분 롤백을 한 노드와 유지되는 최신 버전 노드 간의 통신에 문제가 없는지 재차 모니터링해야 한다.
   * 에러가 재발하거나 새로운 문제가 발생하는지 지속 관찰한다.

#### 배포 관리 도구 활용

ROS2 Humble 패키지의 배포 및 롤백은 운영 환경에 따라 다양한 도구를 활용할 수 있다. 일반적으로 컨테이너 기반 환경(Docker, Kubernetes 등)에서 많이 쓰이는 배포 도구는 다음과 같다.

**Docker Compose**:

* 여러 컨테이너를 묶어서 관리할 수 있다.
* 버전 태그를 서로 다르게 두어, `docker-compose.yml` 파일에서 롤백 대상 이미지를 지정할 수 있다.

```bash
docker-compose down
# old_version으로 tags 교체
docker-compose up -d
```

**Kubernetes(쿠버네티스)**:

* Rolling Update, Rollback 기능이 내장되어 있어, `Deployment` 나 `StatefulSet` 객체를 업데이트할 때 이전 리비전을 간단히 복원할 수 있다.

```bash
kubectl rollout undo deployment/<deployment_name>
```

* Helm 차트 사용 시, `helm rollback <release_name> <revision>` 명령으로 특정 리비전으로 되돌릴 수 있다.

**GitOps(Argo CD, Flux 등)**:

* Git 저장소에 선언적으로 시스템 상태를 정의하고, Argo CD나 Flux가 이를 실제 쿠버네티스 클러스터에 자동 적용한다.
* 이전 커밋 혹은 태그로 이동하면 GitOps 엔진이 해당 상태를 다시 배포하므로, 자동으로 롤백이 이뤄진다.

#### 진단 자동화

장애 상황에서 신속한 대응이 가능한 환경을 구축하기 위해 진단 과정을 자동화할 수 있다. 자동화된 진단 시스템은 문제 발생 시점을 빠르게 포착하고, 원인 후보를 제시해주므로 운영팀의 분석 시간을 크게 단축한다.

1. **시스템 상태 스냅샷(Snapshot) 저장**
   * 특정 주기(예: 분 단위, 10초 단위 등)나 이벤트 트리거(에러 발생 시)에 맞춰 ROS2 노드 상태, 토픽 트래픽, CPU/메모리 사용량을 저장한다.
   * 이를 통해 문제 시점 근처의 상태를 빠르게 재현(Replay)할 수 있다.
2. **에러 패턴 매칭**
   * 과거에 발생했던 에러 로그를 머신 러닝 모델이나 단순 키워드 매칭으로 분석하여, 유사도가 높은 문제가 재발했을 때 대응책을 자동으로 추천한다.
   * 예: “토픽 연결 끊김” 문제 발생 시 QoS 설정 재점검 절차를 자동으로 가이드해주는 스크립트.
3. **자동화된 알림 및 대시보드**
   * Prometheus, Grafana, ELK(Elasticsearch, Logstash, Kibana) 스택 등을 연동해 실시간으로 로그를 수집하고 시각화한다.
   * 장애가 감지되면 Slack, 이메일, SMS 등으로 운영팀에 즉시 알림을 발송한다.

#### 사후 조치

롤백이 일단락된 후에는 재발 방지와 장기적인 개선책을 마련하기 위해 후속 작업이 필요하다.

1. **뿌리 원인 분석(Root Cause Analysis)**
   * 긴급 패치나 임시 조치로 문제는 해결됐더라도, 근본적으로 무엇이 문제였는지 면밀히 파악한다.
   * 재발 방지 대책을 문서화하고, 관련 테스트 케이스를 강화한다.
2. **문서 및 브랜치 정리**
   * 롤백 과정에서 사용된 버전, 수정 사항, 의존성 변동 등을 모두 기록해 두어야 한다.
   * Git 리포지토리 브랜치와 태그를 정비하고, 소스 코드 및 CI/CD 파이프라인 문서도 최신 상태로 업데이트한다.
3. **장애 대응 회고(Incident Postmortem)**
   * 해당 장애가 전체 시스템에 끼친 영향, 장애 발생부터 해결까지 소요된 시간, 개선 필요점 등을 내부적으로 공유한다.
   * 이러한 회고 과정을 통해 향후 비슷한 이슈가 생겼을 때 더 빠르게 해결할 수 있다.