2021.09.29

글로벌 칼럼 | 유지보수를 위한 다운타임, '유지보수 윈도우'는 정당화할 수 없다

Lee Atchison | InfoWorld
몇 년 전에 집에서 사용할 디지털 '스마트' 온도조절기를 구입했다. 집에 없을 때 원격으로 온도를 설정하고 확인하기 위해서였다. 제품을 설정하고 제조업체 클라우드 백엔드에 연결하는 과정 모두 문제없이 원활했다. 잘 샀다고 생각했다.
 
ⓒ Getty Images Bank

몇 주 뒤에 해당 제조업체로부터 서비스 업그레이드 예정에 관한 이메일 한 통을 받았다. 업그레이드하는 몇 개월 동안에는 '한 번에 몇 시간 동안' 애플리케이션을 중단시킬 수 있으며 이는 '하루 중 다양한 시간대에 발생할 수 있다'는 내용이었다(시간은 명시되지 않음). 물론 이 업체는 불편함에 대해 미리 사과했다.

언제든 갑자기 몇 시간 동안 온도조절기 작동이 멈출 수 있고, 그런 상황이 몇 개월 동안 지속된다는 이야기다. 필자는 다음 날 바로 온도조절기를 다른 회사 제품으로 교체했다. 그런 수준의 형편없는 서비스를 감내할 수는 없었기 때문이다.


가용성은 중요하다

필자의 아들은 미국 정부에 의무적으로 수입을 신고해야 한다. 아들은 이를 위해 휴대폰 애플리케이션을 사용한다. 한 달에 한 번 애플리케이션에 로그인해서 이전 달 수입을 신고한다. 그런데 이 아이폰 애플리케이션에는 중대한 문제가 있다. 앱이 작동하지 않는 시간이 있고 그 시간에 실행하면 '이 애플리케이션은 미동부표준시 월~금요일 오전 8시부터 오후 5시까지 작동한다'는 메시지가 표시된다.

이게 무슨 소리인가? 말 그대로다. 이 온라인 SaaS 기반 애플리케이션은 '일반 영업 시간'동안에만 작동한다. 결과적으로 애플리케이션을 사용하기가 매우 어렵다. 애플리케이션 사용 시간을 이렇게 제한하는 이유가 무엇일까? 정부 기관이니만큼 애플리케이션을 지원할 사람이 사무실에 없는 시간에는 동작하지 않도록 했을 것이다. 뭔가 잘못되더라도 사무실에 아무도 없으니 고칠 수 없지 않은가?


계획된 다운타임도 다운타임이다

앞서 설명한 두 가지 사례는 극단적이지만 많은 온라인 애플리케이션의 공통적인 문제를 보여준다. 애플리케이션을 운영하는 기업이 유지보수와 업그레이드를 위해 '유지보수 윈도우(Maintenance windows)', 즉 정기적으로 애플리케이션을 오프라인으로 내리는 기간을 둔다는 것이다. 그리고는 이 시간을 '자유로운 다운타임'으로 취급하면서 언제든 애플리케이션을 다운시켜 작업할 수 있다고 여기고, 이를 다운타임에서 제외하는 것이다.

완전히 틀린 생각이다. 다운타임은 다운타임이다. 계획된, 예상된 다운타임인지 계획에 없거나 예기치 못한 다운타임인지는 관계가 없다. 고객이 애플리케이션을 사용하고자 할 때 어떤 이유로든 애플리케이션이 제공되지 않는다면 다운타임이다.

높은 수준의 가용성을 유지하는 것은 현대 디지털 온라인 애플리케이션이나 서비스를 운영하는 데 있어 필수적이다. 고객은 서비스를 사용하고자 할 때 그 서비스가 정상 가동할 것이라고 기대한다. 고객은 기업의 스케줄에 관심 없고 다운타임을 용인하지도 않는다. 애플리케이션을 운영하는 회사가 아닌 본인에게 편리한 시간에 애플리케이션을 사용한다. 

애플리케이션 장애로 인한 가용성 저하만 해도 충분히 나쁘다. 그러나 유지보수 윈도우 형태로 다운타임을 계획하는 것은 고객 불만을 공식화하는 것일 뿐이다.

애플리케이션 개발에 사용할 수 있는 도구와 서비스가 넘쳐나는 현재 시점에서 디지털 애플리케이션의 유지보수나 업그레이드를 위해 다운타임이 필요할 이유가 없다. 고객 관점뿐만 아니라 기술 관점에서도 받아들일 수 없는 것이다. 

거의 모든 업그레이드는 다운타임 없이 실시간으로 가능하다. 데이터베이스 스키마 변경 및 기타 데이터 마이그레이션 작업이 필요한 업그레이드조차 다운타임 없이 실행할 수 있다. 유지보수 작업은 애플리케이션이 계속 작동하는 중에도 가능하다. 현대 애플리케이션에서 다운을 계획하거나 실행할 합당한 이유는 더 이상 없다.


유지보수 윈도우, 기술 부채일뿐 당연한 게 아니다 

오래된 아키텍처 문제로 인해 애플리케이션에 정말 유지보수 윈도우가 필요하다면 이는 문제로 취급해야 한다. 회사 비용을 소모하는, 애플리케이션에 전가된 기술 부채다. 해결해야 하는 어떤 것이다. 고객은 애플리케이션이 다운된 이유에는 관심이 없다. 다운됐다는 사실 자체가 중요할 뿐이다.

애플리케이션이 성장하고 확장될수록 정기적인 다운타임을 정당화하기도 더 어려워진다. 고객의 사용 패턴이 확장되고, 고객은 해당 애플리케이션이 밤낮으로 항상 작동할 것으로 기대한다.

또한 유지보수 윈도우를 사용할 필요가 없는 개발 조직 시스템과 프로세스를 구축하면 배포 및 운영 모범 사례 준수를 독려하는 효과도 있다. 필자와 같은 개발자는 유지보수 윈도우라는 카드를 손에 쥐고 있는 상태에서는 게을러지는 경향이 있다.

유지보수 윈도우가 필요 없는 방식으로 변경을 설계하고 구현하기 위해서는 부가적인 시간과 고민이 필요하므로 개발자는 세부적인 부분에 더 주의를 기울이게 된다. 개발자가 변경이 운영에 미치는 영향에 대해 생각해야 하는 입장이 되면 결과에 대한 고민 없이 '프로덕션에 던져 넣는' 상황에 비해 운영상의 문제가 덜 발생하는 경향이 있다. 유지보수 윈도우에 의존하면 전체적인 품질과 가용성이 떨어지게 된다.

애플리케이션을 오프라인으로 내려도 될 듯한, 사용량이 낮은 시간대가 지금은 있다 하더라도 이후에 확장하고 성장하면 상황이 바뀔 수 있다. 해외로의 확장, 제품군 확장, 고객층 확장 모두 24x7 가용성의 필요성을 높일 수 있는 요소다.


유지보수 윈도우, 비용을 계산한 적이 있는가

필자의 전 고객사 가운데 하나는 매주 정기적으로 2시간의 유지보수 윈도우를 확보해 업그레이드와 데이터 조정을 수행하고 나머지 시간 동안에는 정상적으로 운영했다.

문제는 유지보수 윈도우는 그 자체로 가용성에 큰 타격이란 점이다. 주 2시간 유지보수 윈도우는 고객에게 제공할 수 있는 최대 가용성이 98.8%라는 뜻이다. 어떻게 해도 운영 시간을 98.8%보다 높일 수 없다.

다른 온라인 애플리케이션과 비교하면 98.8%는 형편없는 수치다. 예를 들어 아마존 S3 서비스는 99.99% 서비스 가용성을 보장한다(데이터 무결성 SLA는 이보다 더 높음). 이 보장 수치를 시간으로 환산하면 매주 61초에 해당한다. 아마존 S3가 이 SLA를 유지하려면 어떤 유지보수를 위한 다운타임도 절대 계획할 수 없다. 어떤 형태든 중단이 발생하면 곧바로 SLA 위반이기 때문이다.

또한 아마존은 무중단 정책을 돈으로 뒷받침한다. 아마존 S3가 1개월을 기준으로 4.3분 다운되면 AWS는 그 달 전체의 스토리지 비용의 10%를 모두에게 환불해준다. 상상할 수 있겠지만 실제로 그렇게 된다면 막대한 수익 손실이다.

S3뿐만 아니라 AWS와 아마존 전반적인 태도 또한 마찬가지다. 아마존의 모든 엔지니어들이 마음 속에 새기고 있다. 시스템에 어떤 변경이 일어나든 다운타임이 필요할 일이 없도록 만든다. 다운타임은 절대 없다.

물론 99.99%는 높은 보장 가용성 수준이고, 모든 기업이 성공하기 위해 반드시 이 정도가 필요한 것도 아니다. 그러나 이보다 낮은 가용성에서도 계획된 유지보수 윈도우를 둘 여지는 거의 없다.

- 99% 가용성은 주당 최대 다운타임 1.6시간을 의미한다.
- 99.9% 가용성은 주당 최대 다운타임 10분을 의미한다.
- 99.99% 가용성은 주당 최대 다운타임이 61초 미만임을 의미한다.

상대적으로 낮은 가용성 수준에서도 매주 계획된 2시간의 다운타임은 애플리케이션이 항상 SLA를 충족하지 못한다는 것을 의미한다. 계획된 다운타임을 다운타임으로 계산하지 않는 기업도 있지만 고객은 다운타임으로 계산한다. 중요한 것은 고객이다. editor@itworld.co.kr


2021.09.29

글로벌 칼럼 | 유지보수를 위한 다운타임, '유지보수 윈도우'는 정당화할 수 없다

Lee Atchison | InfoWorld
몇 년 전에 집에서 사용할 디지털 '스마트' 온도조절기를 구입했다. 집에 없을 때 원격으로 온도를 설정하고 확인하기 위해서였다. 제품을 설정하고 제조업체 클라우드 백엔드에 연결하는 과정 모두 문제없이 원활했다. 잘 샀다고 생각했다.
 
ⓒ Getty Images Bank

몇 주 뒤에 해당 제조업체로부터 서비스 업그레이드 예정에 관한 이메일 한 통을 받았다. 업그레이드하는 몇 개월 동안에는 '한 번에 몇 시간 동안' 애플리케이션을 중단시킬 수 있으며 이는 '하루 중 다양한 시간대에 발생할 수 있다'는 내용이었다(시간은 명시되지 않음). 물론 이 업체는 불편함에 대해 미리 사과했다.

언제든 갑자기 몇 시간 동안 온도조절기 작동이 멈출 수 있고, 그런 상황이 몇 개월 동안 지속된다는 이야기다. 필자는 다음 날 바로 온도조절기를 다른 회사 제품으로 교체했다. 그런 수준의 형편없는 서비스를 감내할 수는 없었기 때문이다.


가용성은 중요하다

필자의 아들은 미국 정부에 의무적으로 수입을 신고해야 한다. 아들은 이를 위해 휴대폰 애플리케이션을 사용한다. 한 달에 한 번 애플리케이션에 로그인해서 이전 달 수입을 신고한다. 그런데 이 아이폰 애플리케이션에는 중대한 문제가 있다. 앱이 작동하지 않는 시간이 있고 그 시간에 실행하면 '이 애플리케이션은 미동부표준시 월~금요일 오전 8시부터 오후 5시까지 작동한다'는 메시지가 표시된다.

이게 무슨 소리인가? 말 그대로다. 이 온라인 SaaS 기반 애플리케이션은 '일반 영업 시간'동안에만 작동한다. 결과적으로 애플리케이션을 사용하기가 매우 어렵다. 애플리케이션 사용 시간을 이렇게 제한하는 이유가 무엇일까? 정부 기관이니만큼 애플리케이션을 지원할 사람이 사무실에 없는 시간에는 동작하지 않도록 했을 것이다. 뭔가 잘못되더라도 사무실에 아무도 없으니 고칠 수 없지 않은가?


계획된 다운타임도 다운타임이다

앞서 설명한 두 가지 사례는 극단적이지만 많은 온라인 애플리케이션의 공통적인 문제를 보여준다. 애플리케이션을 운영하는 기업이 유지보수와 업그레이드를 위해 '유지보수 윈도우(Maintenance windows)', 즉 정기적으로 애플리케이션을 오프라인으로 내리는 기간을 둔다는 것이다. 그리고는 이 시간을 '자유로운 다운타임'으로 취급하면서 언제든 애플리케이션을 다운시켜 작업할 수 있다고 여기고, 이를 다운타임에서 제외하는 것이다.

완전히 틀린 생각이다. 다운타임은 다운타임이다. 계획된, 예상된 다운타임인지 계획에 없거나 예기치 못한 다운타임인지는 관계가 없다. 고객이 애플리케이션을 사용하고자 할 때 어떤 이유로든 애플리케이션이 제공되지 않는다면 다운타임이다.

높은 수준의 가용성을 유지하는 것은 현대 디지털 온라인 애플리케이션이나 서비스를 운영하는 데 있어 필수적이다. 고객은 서비스를 사용하고자 할 때 그 서비스가 정상 가동할 것이라고 기대한다. 고객은 기업의 스케줄에 관심 없고 다운타임을 용인하지도 않는다. 애플리케이션을 운영하는 회사가 아닌 본인에게 편리한 시간에 애플리케이션을 사용한다. 

애플리케이션 장애로 인한 가용성 저하만 해도 충분히 나쁘다. 그러나 유지보수 윈도우 형태로 다운타임을 계획하는 것은 고객 불만을 공식화하는 것일 뿐이다.

애플리케이션 개발에 사용할 수 있는 도구와 서비스가 넘쳐나는 현재 시점에서 디지털 애플리케이션의 유지보수나 업그레이드를 위해 다운타임이 필요할 이유가 없다. 고객 관점뿐만 아니라 기술 관점에서도 받아들일 수 없는 것이다. 

거의 모든 업그레이드는 다운타임 없이 실시간으로 가능하다. 데이터베이스 스키마 변경 및 기타 데이터 마이그레이션 작업이 필요한 업그레이드조차 다운타임 없이 실행할 수 있다. 유지보수 작업은 애플리케이션이 계속 작동하는 중에도 가능하다. 현대 애플리케이션에서 다운을 계획하거나 실행할 합당한 이유는 더 이상 없다.


유지보수 윈도우, 기술 부채일뿐 당연한 게 아니다 

오래된 아키텍처 문제로 인해 애플리케이션에 정말 유지보수 윈도우가 필요하다면 이는 문제로 취급해야 한다. 회사 비용을 소모하는, 애플리케이션에 전가된 기술 부채다. 해결해야 하는 어떤 것이다. 고객은 애플리케이션이 다운된 이유에는 관심이 없다. 다운됐다는 사실 자체가 중요할 뿐이다.

애플리케이션이 성장하고 확장될수록 정기적인 다운타임을 정당화하기도 더 어려워진다. 고객의 사용 패턴이 확장되고, 고객은 해당 애플리케이션이 밤낮으로 항상 작동할 것으로 기대한다.

또한 유지보수 윈도우를 사용할 필요가 없는 개발 조직 시스템과 프로세스를 구축하면 배포 및 운영 모범 사례 준수를 독려하는 효과도 있다. 필자와 같은 개발자는 유지보수 윈도우라는 카드를 손에 쥐고 있는 상태에서는 게을러지는 경향이 있다.

유지보수 윈도우가 필요 없는 방식으로 변경을 설계하고 구현하기 위해서는 부가적인 시간과 고민이 필요하므로 개발자는 세부적인 부분에 더 주의를 기울이게 된다. 개발자가 변경이 운영에 미치는 영향에 대해 생각해야 하는 입장이 되면 결과에 대한 고민 없이 '프로덕션에 던져 넣는' 상황에 비해 운영상의 문제가 덜 발생하는 경향이 있다. 유지보수 윈도우에 의존하면 전체적인 품질과 가용성이 떨어지게 된다.

애플리케이션을 오프라인으로 내려도 될 듯한, 사용량이 낮은 시간대가 지금은 있다 하더라도 이후에 확장하고 성장하면 상황이 바뀔 수 있다. 해외로의 확장, 제품군 확장, 고객층 확장 모두 24x7 가용성의 필요성을 높일 수 있는 요소다.


유지보수 윈도우, 비용을 계산한 적이 있는가

필자의 전 고객사 가운데 하나는 매주 정기적으로 2시간의 유지보수 윈도우를 확보해 업그레이드와 데이터 조정을 수행하고 나머지 시간 동안에는 정상적으로 운영했다.

문제는 유지보수 윈도우는 그 자체로 가용성에 큰 타격이란 점이다. 주 2시간 유지보수 윈도우는 고객에게 제공할 수 있는 최대 가용성이 98.8%라는 뜻이다. 어떻게 해도 운영 시간을 98.8%보다 높일 수 없다.

다른 온라인 애플리케이션과 비교하면 98.8%는 형편없는 수치다. 예를 들어 아마존 S3 서비스는 99.99% 서비스 가용성을 보장한다(데이터 무결성 SLA는 이보다 더 높음). 이 보장 수치를 시간으로 환산하면 매주 61초에 해당한다. 아마존 S3가 이 SLA를 유지하려면 어떤 유지보수를 위한 다운타임도 절대 계획할 수 없다. 어떤 형태든 중단이 발생하면 곧바로 SLA 위반이기 때문이다.

또한 아마존은 무중단 정책을 돈으로 뒷받침한다. 아마존 S3가 1개월을 기준으로 4.3분 다운되면 AWS는 그 달 전체의 스토리지 비용의 10%를 모두에게 환불해준다. 상상할 수 있겠지만 실제로 그렇게 된다면 막대한 수익 손실이다.

S3뿐만 아니라 AWS와 아마존 전반적인 태도 또한 마찬가지다. 아마존의 모든 엔지니어들이 마음 속에 새기고 있다. 시스템에 어떤 변경이 일어나든 다운타임이 필요할 일이 없도록 만든다. 다운타임은 절대 없다.

물론 99.99%는 높은 보장 가용성 수준이고, 모든 기업이 성공하기 위해 반드시 이 정도가 필요한 것도 아니다. 그러나 이보다 낮은 가용성에서도 계획된 유지보수 윈도우를 둘 여지는 거의 없다.

- 99% 가용성은 주당 최대 다운타임 1.6시간을 의미한다.
- 99.9% 가용성은 주당 최대 다운타임 10분을 의미한다.
- 99.99% 가용성은 주당 최대 다운타임이 61초 미만임을 의미한다.

상대적으로 낮은 가용성 수준에서도 매주 계획된 2시간의 다운타임은 애플리케이션이 항상 SLA를 충족하지 못한다는 것을 의미한다. 계획된 다운타임을 다운타임으로 계산하지 않는 기업도 있지만 고객은 다운타임으로 계산한다. 중요한 것은 고객이다. editor@itworld.co.kr


X