베이스캠프 Sprint9

21.03.15부터 21.03.21까지 베이스캠프 Sprint9를 진행했다. 크게 두 가지의 컨셉을 가진 Sprint였는데 두가지는 바로

1. QA
2. 운영

이다. 실질적인 개발이 완료된 서비스에 대해 출시를 위한 준비를 하는 Sprint라고 볼 수 있을 것 같다.

QA

일종의 알파테스트 느낌으로 다른 TF와 크로스 QA를 진행하기도 하고 우윤정 수석님이 추가적으로 QA를 진행해주셨다. 당연하게도 많은 버그나 개선사항들이 발견되었고, 대부분 마이너한 것들이어서 그 양은 많았지만 수정하는데는 오래걸리지 않은 것 같다.

기억 남는 버그가 두 개가 있는데 중 하나는 브라우저의 뒤로 가기 행동 시 버그가 있었는데, 관련해서 브라우저의 BFCache(Back-forward Cache)에 대해 몰랐었기에 버그 픽스하는데 시간을 많이 들였던 것 같다. 나머지 하나는 QA 제보를 통해 알게 된 건 아니고 혼자 테스트하다가 왕복 검색 시 가는 편 선택 후 오는 편 선택 페이지로 넘어갈 때 가끔 500 Error가 발생하는 걸 발견했다. 해당 버그는 redirectAttribute의 addFlashAttribute()으로 인한 버그였는데 개인적으로 흥미로운 트러블 슈팅 과정이라 블로그에 남길 예정이다.

QA 내용에 대해 하나씩 버그픽스해내가며 태스크를 완료처리하는 재미가 있었다. 그 중에서도 한가지 아쉬웠던 점은 개선사항으로 제시된 것 중 하나가 왕복 항공편 선택시 가는 편과 오는 편을 계속 바꿔가며 비교하기에 굉장히 불편한 구조라는 것이다. 그런데 이부분은 나도 알고 있었고, 이러한 불편함을 예상해서 기획 단계에서도 검색 결과 화면 상단 헤더에 재검색할 수 있는 모듈을 넣자고 기획했었다. 그러나 개발단계에서 시간 상 스펙아웃했던 부분인데 그 부분이 뼈아프게 돌아왔다.

운영

서비스 출시 이후에 안정적인 서비스 운영을 위한 커리큘럼이 진행되었다. 서비스 오픈은 끝이 아니라 시작이라는 말씀이 기억에 남는다. 직접 경험하기에 앞서 이경한 수석의 교육이 있었는데, 정말 감명을 많이 받았다. 개인적으로 베이스캠프 기간 중에 들었던 많은 교육 중에 가장 인상 깊었던 것 같다. 교육은 대부분 이경환 수석님의 지난 수년간의 운영 경험에 대한 공유가 주 내용이었다.

교육을 듣고 나니 서비스 운영을 위해서는 애플리케이션에 대해서만 알아야하는 게 아니라는 걸 깨달았다. 정말 예상치도 못한 다양한 곳에서 장애가 발생할 수 있다는 걸 알게 되었다. 캐시로 인한 장애부터 시작해서 심지어는 파일 시스템의 inode개수로 인한 장애까지.. 정말 예측은 고사하고 장애 원인을 찾아낸 게 더 놀라운 수준이었다. 그 장애를 해결하기 위해서는 당연하게도 그 다양한 부분에 대한 지식이나 경험이 있어야하며, 대응에도 역시 노하우가 필요함을 깨달았다. 그리고 그 다양한 지식과 경험을 갖추고 공유해주시는 이경환 수석님이 정말 대단하다고 느껴졌다.

교육이 끝나고는 직접 운영을 위한 실습을 진행했다. 크게 아래와 같은 하위 태스크로 나누어졌고, 난 그중에서 1,2번을 맡아서 진행했다.

1. Log & Crash 적용
2. Watchdog 연동
3. 운영 통계 스크립트 작성
4. 무중단 배포
5. 자동 재기동(crontab 이용)
6. Nsight 연동

Log & Crash

Log & Crash는 서버의 로그를 수집하여 검색 및 정렬 기능을 제공하는 클라우드 서비스이다. 기존에 서버에 직접 하나씩 들어가서 로그를 들여다보는 방식보다 훨씬 수월한 것이다. 이걸 우리 프로젝트에 적용해야했는데, 이를 위한 설정을 하는 과정에서 logger에 대한 이해를 높일 수 있었다. 간단할 줄 알았는데 logger에 대한 이해가 부족해서 생각보단 오래걸렸다. 사실 그동안 Log4j2니, logback이니, Slf4j니 다 똑같은 logger인 줄 알았는데 그게 아니었다. Slf4j는 일종의 인터페이스이고 Log4j2와 logback이 그 구현체인 것 같았다. 그리고 Log & Crash를 위해서는 logback을 위한 설정을 해주어야했는데, 그 과정에서 logback.xml 작성 시 console과 logncrash 두가지 appender를 설정하는 법을 알 수 있었다. 그리고 spring profile(dev/prod)에 따라 로깅을 따로하기 위해 spring profile을 가져오는 방식으로 구성했는데, 그 과정에서 spring property를 logback.xml에서 쓰는 방법을 알 수 있었다.

Watchdog

Watchdog은 애플리케이션이 잘 작동하고 있는지 모니터링해주는 것이었다. VIP와 RIP(사실 VIP와 RIP가 Virtual IP, Real IP라는 걸 이때 처음 알았다.) 각각에 대한 헬스체크 및 API 체크를 추가해주었고, 배포 시 watchdog 전파 중지 설정까지 해주었다. 모니터링과는 큰 관련이 없지만 여기서 한가지 기억에 남는 것은 XPath(XML Path)라는 걸 처음 알았다. XPath란 DOM을 탐색하듯이 XML을 탐색하기 위한 언어 느낌이었다. 모니터링을 위해 메인 페이지 로딩 시 form 태그가 뜨는지 확인하기 위해 XPath를 활용하여 체크를 했는데 이런게 있다는 걸 몰랐다는 사실 자체가 정말 개발의 세계는 넓다는 걸 새삼 느끼게했다.

그리고 새벽에 watchdog 전파가 되는 대참사가 발생했는데, 전파가 잘돼서 watchdog 설정이 잘된 것은 확인했지만(?) 정말 너무 아찔했다. 전파 그룹을 분리할 필요 또한 절실히 느꼈다.

그 외

이 외에도 다른 팀원들이 진행한 무중단 배포, crontab을 이용한 자동 재기동과 같은 것들도 현업에서 정말 많이 사용할 것 같은 기술들이었다. 현업에 가서도 운영을 분명히 하게 될텐데 이러한 경험들이 정말 많은 도움이 될 것 같다.