LINE DEVELOPER DAY 2021에서 이수안 님이 발표하신 LINE 플랫폼 서버의 장애 대응 프로세스와 문화 세션 내용을 옮긴 글입니다.
안녕하세요. LINE Platform Engineering 3 센터의 이수안입니다. 이번 글에서는 LINE 플랫폼 서버의 장애 대응 프로세스와 문화와 관련해서 세 가지 내용을 이야기하겠습니다. 첫 번째로 LINE 플랫폼 서버 개발에서 신뢰성(reliability)이 왜 중요한지 설명하고, 두 번째로 장애가 발생했을 때 어떤 과정으로 대응하는지 살펴보겠습니다. 그리고 마지막으로 이 모든 것을 지탱하는 개발자 문화를 소개하겠습니다.
신뢰성과 장애 관리
최고의 신뢰성을 목표로 운영하고 있는 LINE 플랫폼 서버는 다양한 다국적 멤버들이 함께 공유하는 개발 문화에 기반해 발전시키고 있습니다. 저는 LINE 플랫폼 서버 조직이 처음 시작할 때부터 함께 했는데요. 조직을 대표해서 이 목표를 달성하기 위해 LINE 플랫폼 서버 조직에서 10년간 개선하고 발전시켜 온 장애 대응 프로세스와 관련 사례를 공유하려고 합니다.
LINE 플랫폼 서버는 LINE 앱이 탄생했을 때부터 함께 해 온 플랫폼으로, 다음과 같은 LINE 앱 필수 영역의 기능들을 담당하고 있습니다.
LINE은 LINE이 추구하는 Life on LINE이라는 비전처럼 생활 인프라의 일부가 되어 많은 사용자의 생활에 밀접하게 연결되면서 없어서는 안 될 서비스가 되었습니다. 따라서 LINE은 사용자에게 신뢰성 있는 서비스를 제공해야 하며, 신뢰성을 높이기 위해선 사용자가 서비스를 안정적으로 사용할 수 있게 해야 합니다. 저희 팀은 이를 중요한 가치로 여기고 장애가 발생하지 않는 안정적인 서비스를 제공하기 위해 부단히 노력하는 한편 발생한 장애는 최대한 빠르게 해결해 사용자에게 불편을 주지 않으려고 노력하고 있습니다.
장애(outage)란 사용자가 직접 경험할 수 있는 시스템의 문제 또는 사용자에게 직접 영향을 주지는 않더라도 내부 시스템이 기대한 대로 동작하지 않는 것을 말합니다. 2021년 LINE 플랫폼 서버의 장애 건수를 집계해 보면 다음과 같습니다.
그래프를 보면 장애가 불규칙적으로 발생하는 것을 확인할 수 있는데요. 예를 들어 2월과 5월에는 장애가 없었지만 8월에는 무슨 일이 있었는지 장애가 많이 발생했습니다. 이처럼 장애는 예상할 수 없고 언제든지 발생할 수 있습니다. LINE 앱을 출시한 지 어느덧 10년이 되었는데요. 이 그래프를 더 먼 과거로 확장해 봐도 비슷한 모양일 것입니다. 이에 저희는 장애는 어쩔 수 없이 발생하며, 피할 수 없는 문제라고 생각했습니다. 그렇다면 적극적으로 부딪쳐서 그 경험을 기반으로 발전하자고 생각했습니다. 이와 같이 장애를 두려워만 할 게 아니라 장애를 해결해 가는 과정을 널리 알려 플랫폼의 신뢰성을 개선하기 위한 귀중한 경험으로 삼아 함께 발전하자는 것이 LINE의 개발 문화입니다.
장애 대응 프로세스
이제 LINE 플랫폼 서버에서 장애가 발생하면 어떻게 대응하고 어떻게 그 장애로부터 배우는지 알아보겠습니다. 장애 대응 프로세스를 요약하면 다음과 같습니다.
- 장애 탐지 및 전파: 장애가 감지되면 담당자에게 신속히 알립니다.
- 장애 분류 및 해결: 담당자는 장애를 분류하고, 내용을 다른 부서에 전파함과 동시에 수정 작업을 진행합니다. 장애 대응의 핵심 단계라고 할 수 있습니다.
- 장애 복구 및 보고: 장애가 해결되면 장애 상황을 정리하고, 정리한 내용을 유관 부서와 공유합니다.
- 장애 회고: 이해 당사자가 모여 결과를 검토하고 개선점을 논의합니다.
각 단계를 좀 더 자세하게 살펴보겠습니다.
장애 탐지
모니터링 시스템이 장애를 자동으로 감지해 알람을 발생시키기 때문에 대부분 장애가 발생하자마자 담당자들이 신속히 인지할 수 있습니다. 하지만 만약 담당자가 미처 확인하지 못한 상황이 발생한다면, 문제를 확인한 누구든지 담당자에게 연락하여 장애에 대응할 수 있도록 해야 합니다. 이를 위해 책임자와 보고 채널을 쉽게 확인할 수 있도록 연락망을 관리하고 있습니다.
장애 분류
그다음으로는 장애 분류 단계입니다. 장애 등급은 장애 영향도를 알릴 때 효과적으로 소통하기 위해, 또 사후 분류와 같은 관리 용도로 사용하고 있습니다. 장애 등급의 분류 기준은 프로덕트별로 다릅니다. 장애가 발생하면 장애 등급 정보는 프로덕트별로 판단해 공유하며, 장애 등급은 변경될 수 있습니다. 아래 이미지 오른쪽의 표는 실제로 사용하고 있는 장애 등급 기준 표입니다. 이 표는 사용자에게 기능을 제공하는 서비스 플랫폼에서 사용하고 있습니다.
장애 등급 기준을 결정할 때 사용한 지표는 먼저 LINE 사용자 수인 DAU(daily active user)입니다. DAU를 기반으로 장애에 영향받는 사용자 수의 범위를 구분해 영향 범위를 결정합니다. 또 장애가 발생한 기능의 종류와 상태를 기준으로 심각도를 결정합니다. 이 두 지표로 장애 등급 기준을 결정합니다.
장애 전파
LINE 플랫폼 서버는 LINE의 많은 서비스와 서로 긴밀하게 연관되어 있기 때문에 장애 상황을 신속하게 전파하고 공유하는 체계를 만드는 것이 중요합니다. 현재 장애 상황을 등급 기준에 따라 미리 정해 놓은 공유 채널에 전파하고 있으며, 전달받은 각 서버의 담당자는 공유된 정보를 파악해 다른 영향은 없었는지 확인하고, 고객 응대 부서에서는 문제를 인지하고 고객 대응을 준비하고 있습니다.
아래 이미지 오른쪽 '[Outage notice]'는 현재 저희가 장애 전파 공유 내용을 작성할 때 사용하고 있는 템플릿입니다. 다양한 부서에서 공유하기 때문에 작성하기 편하고 이해하기도 쉽도록 템플릿을 만들어 공유 내용을 관리하고 있습니다.
장애 복구
장애 복구는 장애 대응의 핵심 과정입니다. 장애 종류나 영향에 따라서 대응 방법은 다르지만, 장애의 영향도를 최대한 빨리 줄일 수 있는 방법으로 대응합니다. 동시에 장애의 원인도 파악하는데요. 장애가 발생한 부서의 리드가 장애 대응의 총 책임을 맡습니다. 팀원들은 리더의 지시에 따라 대응한 뒤 대응 상황을 리더에게 보고합니다. 장애 처리가 길어지면 장애 상황을 업데이트하고 공유하는 것도 리더의 책임입니다. 만약 리더가 모든 것을 처리할 수 없는 상황이라면 공유 담당자를 지정할 수도 있습니다.
장애 보고
장애 대응 이후 근무일 기준으로 1일 이내에 1차 보고를 완료하는 것이 원칙입니다. 보고서를 작성한 후 정해진 메일링 리스트로 내용을 공유합니다. 보고해야 할 내용 역시 템플릿으로 정의해 놓았는데요. 이미지 오른쪽의 내용을 참고해 주시기 바랍니다.
템플릿의 내용을 살펴보면 다음과 같습니다.
- Summary: 비 개발 부서에서도 내용을 이해할 수 있도록 장애 상황을 요약해 기술합니다.
- Detail: 개발자가 상세 정보를 확인할 수 있도록 서비스의 형태, 대응 이력 등의 정보를 기술합니다.
- Corrective and preventive measures: 세 가지 관점으로 장애를 점검한 내용과 개선 항목을 기술합니다. 이때 세 가지 관점은 장애 재발을 방지하기 위한 관점, 장애를 빠르게 감지할 수 있게 개선하는 관점, 그리고 장애 대응 자체의 관점입니다. 개선 항목은 액션 아이템 형태로 작성하며 Jira 티켓으로도 등록해 관리합니다.
장애 회고
장애 회고는 장애가 발생한 날부터 근무일 기준으로 5일 이내에 실시해야 합니다. 다양한 피드백을 주고받으며 추가 개선점을 찾을 수 있도록 가능한 한 많은 사람이 참여하도록 유도하고 있습니다. 이후에 보고서 내용을 확정하고 장애 대응을 완료합니다.
개발자 문화
지금까지 장애 대응 프로세스를 소개했습니다. 물론 어느 정도 강제하고 있는 프로세스이기도 하지만, 그럼에도 대부분의 개발자분들이 자발적으로 잘 지키고 있다고 생각하는데요. 저는 그 이유가 다음에 설명드릴 개발자 문화 덕분이라고 생각합니다. 그럼 신뢰성과 관련된 LINE의 개발자 문화를 소개하겠습니다.
코드 리뷰
신뢰성을 보장하는 가장 쉬운 방법은 개발 초기 단계부터 이를 고려하는 것입니다. 이에 LINE은 초창기부터 동료 간의 엄격한 코드 리뷰 문화를 형성해 왔고 현재도 잘 유지하고 있습니다. 코드 리뷰는 GitHub를 도입할 때 가장 처음 정착한 개발 문화 중 하나로 기억합니다. 코드 리뷰에 도움을 주기 위해 디자인 문서를 제공하고 리뷰하며 내용을 확인하는 문화가 형성됐습니다.
LINE 초반에는 테스트 코드가 많지 않았지만 지금은 테스트 코드 없이는 코드 리뷰를 통과하기 어려운 개발 문화가 형성됐으며, 또한 일부 팀에서는 유닛 테스트(unit test)1와 더불어 통합 테스트(integration test)2 형태의 엔드 투 엔드(end-to-end) 테스트3까지 관리하고 있습니다. 이렇게 테스트 케이스를 통해 코드 작성 시에 발생할 수 있는 문제를 예방하고 있습니다. 아마 장애 재발 방지책으로 테스트 코드의 보강이 자주 언급되었던 것도 이런 문화 형성에 도움이 되지 않았나 생각합니다.
장애 모니터링 및 대응
LINE 플랫폼 서버는 장애 상황을 감지하기 위해 다양한 조건을 설정하고 모니터링합니다. 만약 특정 조건에 맞는 상황이 발생하면 알림을 전송하는데요. 이때 누군가는 알림에 반응하고 대응해야겠죠. 이와 같이 장애 상황이 발생해 알림이 전송됐을 때 개발자가 돌아가면서 대응하는 것을 온 콜 듀티(On-call Duty)라고 하며, 장애에 가장 적절하게 대응할 수 있는 개발자가 상시 대응할 수 있는 체제로 운영하고 있습니다. 이를 통해 작은 문제가 큰 장애로 확대되는 것을 방지합니다.
장애 회고의 모든 액션 아이템은 Jira 티켓으로 관리하며, 개발자가 장애 관련 티켓도 다른 개발 작업과 동등하게 대응하도록 권장하고 있습니다.
그동안 이런 종류의 티켓이 쉽게 기술 부채4가 되는 것을 목격할 수 있었습니다. 일단 장애 대응이 끝나면 모두의 관심도가 낮아지기 때문이죠. 그러다가 비슷한 원인으로 장애가 또 발생하면 그때 처리하지 못한 티켓에 또 관심이 쏠립니다. 이런 경험을 반복하면서 장애 관련 티켓을 관리하는 게 중요하다는 사실을 깨달을 수 있었습니다.
이를 개선하기 위해 조직의 공통 OKR(Objectives and Key Result) 중 하나로 장애 티켓을 해결하자는 목표를 설정하고, 이 목표를 모든 조직원이 공유하고 실행할 수 있도록 다시 각 팀 내에서 조직의 공통 목표로 이어지도록 팀의 상황에 맞춘 목표를 다시 정의하는 OKR 캐스캐이딩(cascading) 방법을 사용하고 있습니다. 이 과정을 거치며 모든 사람이 장애 티켓을 해결하는 것이 공통의 목표라는 것을 다시 인식할 수 있습니다. 구체적인 실행 방법은 각 팀에서 상황에 맞게 논의한 후 직접 결정하고 있습니다.
앞서 설명드린 장애 대응 티켓의 현재 관리 상태를 공유하려고 합니다.
2021년 1월부터 9월까지 242개의 액션 아이템들이 Jira 티켓으로 등록됐고, 2021년 11월 기준 83%의 티켓이 해결됐거나 해결되고 있는 상태입니다. 다른 개발 업무를 진행해야 하는 부담이 있는 상황에서도 이 정도 수치를 달성했다는 것은 상당히 의미 있는 결과라고 생각합니다.
장애 대응 사례
이제 장애 대응 프로세스를 보다 쉽게 이해할 수 있는 실제 사례를 소개하겠습니다. 2021년 8월 4일에 장애 공유 채널에 공유된 건으로, 장애 보고서의 내용의 일부를 소개하겠습니다.
장애 보고서의 상단에는 장애에 관한 요약 정보를 적는데 이때 장애 대응의 분류 정보와 장애 대응의 영향도 정보도 함께 적습니다. 내용을 살펴보면 요청을 중개하는 프락시 서버의 설정 오류로 요청 제어(request control)가 정상적으로 작동하지 않았고, 이로 인해 백엔드 서버를 다시 시작했지만 서버가 계속 불안정하게 동작한 것이 문제였다고 기술돼 있습니다.
장애 보고서의 다음 내용은 좀 더 상세한 내용을 기술하는 것입니다. 장애가 발생한 시점의 로그나 로그의 발생량을 기술하며, 실패한 API의 형태를 나타내는 다양한 지표를 참고해 영향 범위도 상세하게 적습니다. 또 실패한 API의 수나 종류 등을 기술해 장애에 영향을 받은 사용자 수를 확인합니다.
장애 발생과 복구에 관련된 상세한 정보를 가능한 한 자세히 시간 순으로 적습니다. 전체 타임라인에는 더 많은 정보들이 있지만, 여기서는 장애와 관련된 정보만 일부 발췌했습니다. 장애 원인이 된 업데이트를 한 시점, 장애가 발생한 시점, 장애를 인지하고 해결을 시작한 시점, 복구가 완료된 시점 등을 명시했습니다. 실제 장애 보고서에는 좀 더 다양한 조치 사항들이 기술돼 있습니다.
마지막으로 장애 재발 방지를 위한 액션 아이템을 정리합니다. 실제 장애 보고서에서는 등록한 Jira 티켓을 적습니다. 모든 티켓에는 실행 가능한 내용을 포함해야 하는데요. 어떤 항목이 있는지 자세히 살펴보겠습니다. 장애 발생을 방지하기 위해 프락시 서버의 헬스 체크 기능을 켜는 것이 적혀 있고요. 또 장애 탐지 개선 관점에서 이번 장애는 알림으로 장애를 확인할 수 있었지만 장애가 발생했어도 알림이 오지 않았던 부분을 확인해 보강하겠다는 내용이 기술돼 있습니다. 또 장애 대응 면에서, 롤백으로 복구할 수 있었지만 배포 절차 문서에 롤백 프로세스가 정확하게 정리돼 있지 않던 부분을 보강하겠다는 항목도 있습니다.
이와 같이 장애를 통해 개선책을 찾고 지속적으로 발전시키고 있습니다.
마치며
지난 10년간 얻은 교훈을 정리해 봤습니다. 먼저 프로세스는 사문화되기 쉽다는 점입니다. 프로세스는 해석의 여지없이 바로 실행할 수 있는 형태로 정리해야 하는데요. 프로세스와 관련된 주변 상황은 언제든 변할 수 있기 때문에 변화에 맞춰 지속적으로 프로세스를 업데이트해야 하고 업데이트한 프로세스는 관련된 모든 사람들에게 신속하게 공유해야 합니다. 두 번째로 프로세스는 문화가 뒷받침돼야 한다는 점입니다. 프로세스는 결국 도구에 불과하기 때문에 아무리 잘 정리해 놓은 프로세스라도 조직에서 이를 인정하고 실행하지 않는다면 아무런 의미가 없습니다. 마지막으로 모든 문제는 스스로 해결되지 않는다는 점입니다. 장애 티켓 해결은 모두가 공감하는 중요한 이슈였지만 실제로 진척은 생각보다 더뎠습니다. 그래서 현황을 가시화하고 주기적으로 확인하면서 해결 방안을 함께 논의하며 변화를 유도했습니다. 물론 아직도 해결하기 쉽지 않은 부분이 있어서 꾸준히 도전하고 노력하고 있습니다.
마지막으로 오늘 말씀드린 내용을 요약하며 글을 마치려고 합니다. LINE 플랫폼 조직은 사용자가 기대하는 Life on LINE이 실현될 수 있도록 신뢰성을 중요한 가치로 생각하며 운영하고 있습니다. 이를 위해 문제 상황에 대비하는 프로세스를 명확히 정립했습니다. 여기에 자발적으로 발전하는 개발자 문화가 개발 및 운영 단계에서 신뢰성을 보장하는 든든한 기반이 되어주고 있습니다. 장애를 두려워하는 것이 아니라, 장애를 플랫폼의 신뢰성을 높여가기 위한 귀중한 경험으로 바꿔 나가고 있습니다. 앞으로도 신뢰성은 LINE 플랫폼 서버에서 꾸준히 유지하고 발전시켜 나갈 중요한 가치일 것입니다. 이를 위해 지속적으로 프로세스와 문화를 가꾸고 발전시킬 것입니다. 이번 글을 통해서 LINE 플랫폼 서버에 대한 여러분의 신뢰가 높아지기를 기대합니다. 긴 글 읽어주셔서 감사합니다.
- 단위 테스트(unit test): 프로그램의 기본 단위가 되는 개별 모듈이 제대로 구현되어 정해진 기능을 정확히 수행하는지를 테스트합니다.
- 통합 테스트(integration test): QA 팀에서 하드웨어, 소프트웨어 등 모든 구성 요소가 예상대로 잘 작동하는지를 파악하는 과정입니다. 단위 테스트에서 발견하지 못한 버그나 서로 다른 시스템 구성 요소 간의 종속성 등 좀 더 기술적인 측면을 테스트합니다.
- End-to-end 테스트: 프로덕트를 사용자 관점에서 테스트하는 방법으로, 보통 웹이나 앱 등에서 GUI를 눌러보며 원하는 텍스트가 잘 출력되는지, 버튼을 눌렀을 때 올바른 동작을 수행하는지 등을 테스트합니다. 사용자에게 직접 노출된 부분을 점검하는 과정입니다.
- 기술 부채: 프로젝트의 어떤 문제를 해결할 때 장기적인 관점에서 기획 및 검토하지 않고 임시적인 방편으로 그 문제를 해결하여, 그로 인해 나중에 큰 비용이 발생할 수 있는 요소를 말합니다.