아마존웹서비스(AWS)의 중요 서비스 중단, 그 의미
이 글은 제가 NIA [한국지능정보사회진흥원] 디지털서비스 이슈리포트 2024년 10월호에 기고한 글입니다. 원본 글 '아마존웹서비스(AWS)의 중요 서비스 중단이 미치는 영향과 대응 방안'를 이곳 브런치에서 공유합니다.
0. AWS의 서비스가 조용히 중단되다.
AWS의 Cloud9, SimpleDB, CodeCommit 등과 같은 서비스가 조용히 멈추고 있다. 시작은 지난 7월 말 이런 서비스가 신규 사용자에게 차단되었다는 한 사용자 보고에서 시작되었다. 기존에 빅테크가 원칙으로 행해왔던 서비스 중단에 관한 공식 발표가 없는 가운데, 사용자들이 당황할 수밖에 없는 상황이 회자하면서부터이다.
아래의 화면은 레딧에서 AWS 관련 토론 중에 CodeCommit 이란 서비스 종료"에 대한 질문이다. 사용자가 CodeCommit 콘솔을 열었을 때, 서비스에서 CodeCommit을 더 이상 지원하지 않으니 다른 곳으로 마이그레이션(이전)하라는 경고 메시지가 나타났다고 보고하고, 하지만 공식적인 공지나 발표는 찾지 못했다고 하며, 왜 이런 경고가 나오는지 궁금해하고 있다.
그림 1. AWS 서비스 종료에 대한 사용자 질문 (출처: 레딧)즉, CodeCommit 서비스가 종료를 준비하고 있는 것으로 보이는 아직 공식적인 안내가 없어서 혼란스러워하는 상황을 설명한 것이다. 이런 상황에서 AWS의 수석 에반젤리스트가 엑스를 통해 “AWS CodeCommit을 포함한 소수의 서비스에 대한 신규 액세스를 중단하기로 했다”라는 짧은 글이 올라가며 더욱 혼란이 가중되었다. 그 트윗에는 CodeCommit 외에 다른 서비스의 이름은 언급하지 않았으며, 이에 대한 자세한 내용이나 발표문 또는 문서 링크도 제공하지 않았다. 엑스에서 여러 번의 대화가 오고 가면서 다음과 같은 AWS 서비스- S3 Select, CloudSearch, Cloud9, SimpleDB, Forecast, Data Pipeline, Snowmobile, CodeCommit-가 중단 대상이라는 답변을 듣게 되었다, 그때까지도 어떤 공식 채널을 통한 발표도 없이 말이다.
1. 클라우드 서비스 중단이 사용자에게 미치는 영향
소프트웨어나 서비스를 라이선스로 구매하여 기업, 기관, 조직에서 직접 설치하여 사용하는 온프레미스 운영 방식에서 구독 방식으로 직접 설치나 관리가 최소한으로만 필요한 클라우드 환경으로의 변화는 비용 효율성, 확장성, 유연성, 보안, 안정성 면에서 크게 개선이 되었지만, 그만큼 클라우드 플랫폼 제공자나 서비스 제공자에 대한 의존도는 훨씬 높아졌다. 이 의존도는 단순히 사용할 때의 특정 벤더에 락인되는 의존성이나 네트워크 스피드 의존성뿐이 아닌 서비스 가용성 및 장애 위험 (Service Availability & Outage Risk)이 가장 큰 요소라고 할 수 있다.
클라우드 서비스도 정기적인 유지보수나 예기치 못한 장애로 인해 서비스가 중단되는 경우야 일반적 허용의 범위 안에 있다고 할 수 있지만, 클라우드 제공자가 특정 서비스를 더 이상 지원하지 않거나 종료할 경우, 고객은 갑작스럽게 대체 솔루션을 찾아야 하는 상황에 놓이게 되고 이에 따라 마이그레이션 비용이나 기술적 어려움이 발생할 수 있다. 클라우드 제공자의 서비스가 갑자기 중단되면 기업이나 사용자가 그 서비스를 의존하고 있는 경우, 다음과 같은 주요 문제들이 발생할 수 있다.
1.1 비즈니스 운영 중단
- 서비스 의존성: 갑작스러운 서비스 중단은 해당 서비스를 사용하는 애플리케이션이나 워크플로우가 중단될 수 있다. 특히 이번에 문제가 된 AWS CodeCommit과 같은 Git 리포지토리 서비스가 중단되면 소스 코드 관리가 중단되어 개발 작업에 지장이 생길 수 있다.
- 데이터 접근 문제: 만약 중단된 서비스에 데이터가 저장되어 있거나 의존하고 있는 경우, 데이터에 접근하지 못하게 되어 비즈니스 운영이 지연될 수 있다.
1.2 마이그레이션 비용 및 시간 소요
- 대체 서비스로 마이그레이션: 중단된 서비스의 기능을 제공하는 대체 서비스로 데이터를 이전하거나 설정을 재구축하는 데 시간이 오래 걸릴 수 있다. 또한 서비스에 대한 맞춤형 설정이나 작업 자동화 스크립트를 새롭게 작성해야 하는 추가적인 개발 노력도 필요할 수 있다.
- 비용 발생: 마이그레이션 과정에서 새로운 서비스 비용이 발생하거나, 전환 과정에서 발생하는 일시적인 비효율로 인해 추가적인 비용이 들 수 있다. 클라우드 제공자 간 이전 시에는 새로운 사용법을 익혀야 하거나 신규 직원의 채용이나 기존 직원 교육 비용도 발생할 수 있다.
1.3 고객 신뢰 및 서비스 품질 저하
- 서비스 신뢰도 문제: 사용자가 특정 클라우드 서비스를 신뢰하고 있던 상황에서 서비스 중단이 발생하면, 고객이 서비스의 신뢰성을 의심하게 되고 이는 기업의 이미지에 부정적인 영향을 미칠 수 있다.
- 서비스 장애와 고객 불만: 서비스가 중단되면 최종 사용자에게도 직접적인 영향이 갈 수 있다. 예를 들어, 고객이 사용하는 애플리케이션이 중단되거나 기능이 제한되면, 고객 불만이 발생할 가능성이 크다.
1.4 기술 지원 및 보안 문제
- 지원 종료: 클라우드 프로바이더에서 서비스를 중단하면 기존의 버그 수정, 보안 패치, 기술 지원이 제공되지 않기 때문에 심각한 보안 문제가 발생할 수 있다. 특히 보안 취약점이 발생했을 때 지원이 없으면 시스템이 위험에 노출될 수 있다.
- 기술적 문제: 중단된 서비스를 대체하기 위해 새로운 기술 스택을 도입할 경우, 기존 시스템과의 호환성 문제, 예기치 못한 성능 저하 또는 기능 결여가 발생할 수 있다.
1.5 법적 및 규제 영향
- 컴플라이언스 및 규제 요구 사항: 서비스 중단으로 인해 데이터를 새로운 위치로 이동해야 하거나 다른 보안 정책을 따르게 되면, 규제나 법적 요구 사항을 준수하는 데 문제가 생길 수 있다. 예를 들어, GDPR 정책과 같이 유럽 지역에 데이터를 저장해야 하는 요구 사항이 있는 경우, 새로운 서비스가 이를 충족하지 못할 수 있다.
2. 글로벌 클라우드 프로바이더의 특정 서비스 중단 사례
이번 AWS의 사례는 매우 예외적이라고 할 수 없으며, 다른 주요 글로벌 클라우드 프로바이더 역시 비슷한 사례가 있다.
2.1 구글 클라우드의 App Maker 종료 (2021)
- 상황: 구글은 2021년에 Google App Maker, 자사의 로우코드 애플리케이션 개발 플랫폼을 종료했다.[1] 이는 구글 워크스페이스 사용자가 내부 툴을 개발할 수 있도록 하는 서비스였지만, 구글은 사용자의 수요가 적고 유지 비용이 크다는 이유로 서비스를 종료했다.
- 영향: 많은 기업이 App Maker를 사용해 특정 비즈니스 프로세스를 자동화하고 있었기 때문에 갑작스러운 서비스 중단으로 인해 대체 솔루션을 찾아야 했고, 비즈니스 애플리케이션을 재구성해야 하는 부담이 발생했다.
2.2 마이크로소프트 애저의 Document DB 중단 (Cosmos DB로 대체)
- 상황: 마이크로소프트 애저는 2017년에 Document DB 서비스를 Cosmos DB로 대체했다.[2] 기존 DocumentDB 사용자는 Cosmos DB로의 이전이 필수였고, 더 이상 Document DB를 지원하지 않았다.
- 영향: 고객들은 데이터베이스를 Cosmos DB로 이전하는 과정에서 마이크로소프트는 고객에게 이전을 원활하게 돕기 위해 안내와 지원을 제공했으나 호환성 문제와 함께 비용이 증가했다. 일부 고객은 기능 차이와 이전 과정에서 겪는 문제로 인해 운영에 차질을 빚기도 했다.
2.3 페이스북의 Parse 서버 종료 (2017)
- 상황: 페이스북의 인기 있는 모바일 백엔드 서비스 Parse가 2017년에 종료되었다. 이 서비스는 개발자가 모바일 애플리케이션의 백엔드를 관리할 수 있도록 제공되던 클라우드 플랫폼이었다. 페이스북은 Parse 종료를 발표하며 오픈 소스로 전환하였지만, 사용자들은 직접 서버를 호스팅해야 했다.
- 영향: 수많은 모바일 개발자가 Parse를 사용하고 있었기 때문에 갑작스러운 서비스 종료로 인해 새로운 솔루션을 찾아야 했고, 많은 애플리케이션이 재구성되는 어려움을 겪었다.
이러한 빅테크 기업의 서비스가 종료되는 경우는 빈번하게 이루어지긴 하나, 이번 AWS의 대처와 다른 점은 일반적으로 1년 전에 프로덕트/서비스 선셋 종료계획을 포함한 라이프사이클을 발표한다는 점이다.
또한 이 종료계획에는 반드시 현재 서비스 상황에 연착륙하기 위한 마이그레이션 계획을 동시에 발표하는 것이 일반적인데, AWS의 경우엔 제대로 된 공식 발표가 없었다는 점에서 혼란과 비난을 면하기는 어렵다는 것이 다른 점이다.
그림 2 구글 안드로이드 라이프사이클 (출처: 구글)3. AWS의 특정 서비스 중단의 의미
많은 엔지니어가 AWS의 은밀한 서비스 중단에 대해 많은 비판을 했고, 심각한 신뢰 문제를 겪은 것은 사실이다. 하지만, 이러한 결정에 대해 어쩌면 AWS와 사용자에게 최선의 결정일 수도 있다는 점에서 냉정하게 판단하는 것이 필요하다. 이번 서비스 중단에 포함되었던 서비스는 경쟁 제품이나 일반적인 “AWS 품질 표준”에 미치지 못했던 것이 사실이다. 소스 코드를 관리하는 CodeCommit은 이미 깃허브와 깃 랩(GitLab)에 상대가 아니었다. 가장 최근의 마지막 업데이트가 바로 4년 전이었으니 이미 손을 놓았다는 것이 맞다. 발표된 다른 서비스들도 상황은 비슷하다. 대부분 사용자의 관심을 많이 끌지 못했다. AWS가 2016년 re:Invent에서 길이 45피트, 높이 9.6피트, 너비 8피트의 데이터 백업 전용 컨테이너 트럭인 스노우모빌(Snowmobile)을 소개한 후, 실제로 작동하는 모습을 본 사람은 거의 없다. 고객들은 트럭을 이용한 데이터 백업에 관심이 없었기 때문이다.
그림 3 발표 당시에 잠깐 관심을 끌었던 AWS의 스노우모빌 (출처: 아마존)이러한 서비스 중단이 AWS의 실패라는 의견도 있을 수 있지만, 그 반대의 경우로 생각해 볼 수도 있다.
AWS는 모든 제품 카테고리에서 시장을 선도할 필요는 없으며, 시장에서 관심을 받지 못하는 서비스보다는 좀 더 효율적인 서비스에 리소스를 투입하는 것이 맞다. AWS는 개발자 경험으로 유명했던 적이 없다. CodeCommit뿐만 아니라 Cloud9 서비스의 경우, 개발자가 브라우저에서 애플리케이션 코드를 작성, 실행, 디버깅할 수 있는 멋진 웹 IDE(통합 개발자 환경ׁ)를 갖춘 훌륭한 도구였기에 개발 툴 경쟁에서 구글과 마이크로소프트와 경쟁하기 위해 인수했지만, AWS는 이 도구에 적합한 곳이 아니었다.
AWS의 핵심은 안정된 인프라를 제공하는 것이지 클라우드와 관련된 모든 것이 아니라는 사실이다. AWS가 클라우드를 사용하는 모든 사람의 모든 것이 될 수는 없다는 사실에 동의가 필요하다. AWS는
서비스형 인프라(IaaS)에서 훌륭한 성과를 거두었지만 백엔드, 프론트엔드, 모바일, IoT 또는 웹 3.0은 금융 서비스나 헬스케어와 같은 산업별 전문 분야에서 모두 잘할 수는 없다. 이러한 경험을 통해 AWS는 인프라에서 가장 잘하는 것에 다시 집중하고 기술 제휴 및 파트너 에코시스템에 더 많이 투자하여 전문 클라우드 공급업체의 부가 가치 서비스를 통합하는 데 더욱 집중하리라 생각한다.
4. 클라우드 서비스 중단에 따른 대응 방안
클라우드 프로바이더의 갑작스러운 서비스 중단은 기업의 비즈니스 연속성에 큰 영향을 미칠 수 있지만, 지속해서 발생할 수 있다는 사실에 집중하여 이를 최소화하기 위한 사전 준비와 체계적인 대응 방안을 마련해야 한다. 몇 가지 주요 전략과 실제 사례를 기반으로 설명하면 다음과 같다:
4.1 멀티 클라우드 및 하이브리드 클라우드 전략
단독 클라우드 프로바이더에만 의존하지 않고, 여러 클라우드 서비스 또는 온프레미스(사내) 인프라를 함께 사용하는 전략이다. 이를 통해 특정 클라우드 프로바이더의 서비스가 중단되더라도, 대체 서비스로 신속하게 전환할 수 있다.
사례 1: 넷플릭스는 AWS를 주 클라우드 플랫폼으로 사용하지만, 일부 핵심 시스템은 온프레미스 데이터 센터나 다른 클라우드로 분산해 관리한다. 이에 따라 AWS의 지역적 장애나 서비스 중단 시에도 시스템 가용성을 유지한다.
사례 2: 에어비앤비는 GCP와 AWS를 함께 사용하는 멀티 클라우드 전략을 통해 클라우드 프로바이더에 대한 의존도를 줄이고, 특정 서비스의 중단 시 다른 클라우드에서 애플리케이션을 즉시 실행할 수 있게 준비해 두었다.
4.2 클라우드 애그노스틱(Agnostic) 애플리케이션 개발
특정 클라우드 프로바이더에 종속되지 않는 애플리케이션을 개발하는 것을 의미한다. 이 방식으로 개발하면, 프로바이더 간의 이전이 쉬워져 특정 클라우드 서비스 종료나 장애에 대비할 수 있다.
사례 1: 쿠버네티스는 컨테이너화된 애플리케이션을 배포하고 관리할 수 있는 플랫폼으로, 다양한 클라우드 프로바이더에서 동일한 방식으로 사용할 수 있다. 이를 통해 기업들은 클라우드 프로바이더 간의 전환을 쉽게 할 수 있으며, 클라우드 중단에 대한 영향을 줄일 수 있다.
사례 2: 쇼피파이는 클라우드 애그노스틱 인프라를 구축하여, 필요시에 AWS와 구글 클라우드 사이를 쉽게 전환할 수 있다. 이에 따라 특정 클라우드 서비스 종료나 장애에도 빠르게 대응할 수 있었다.
4.3 비즈니스 연속성 및 재해 복구 계획[3]
클라우드 서비스 중단 시에도 비즈니스를 연속적으로 운영할 수 있는 계획을 마련하는 것이 중요하다. 재해 복구 계획(Disaster Recovery)을 통해 데이터 백업 및 서비스 복구 절차를 미리 설정하고, 정기적으로 이를 테스트한다.
사례 1: 드롭박스는 AWS에서 자사 클라우드 인프라로 이전할 때, 비즈니스 연속성 계획을 수립하여 클라우드 서비스의 장애 시에도 데이터 손실 없이 신속히 복구할 수 있도록 설계했다. 이를 통해 서비스 가용성을 유지할 수 있었으며, 운영 중단에 대한 영향을 최소화할 수 있었다.
사례 2: 캐피털 원은 클라우드 기반 금융 시스템을 운영하며, 비즈니스 연속성 및 재해 복구를 위해 멀티 리전(Region) 복제 및 자동화된 복구 프로세스를 도입했다. AWS가 특정 리전에서 장애가 발생해도 다른 리전으로 서비스를 자동으로 전환하여 운영에 미치는 영향을 줄였다.
4.4 서비스 레벨 계약 (SLA) 확인 및 클라우드 서비스 제공자의 지속 가능성 평가
클라우드 서비스 제공자와 체결하는 SLA(Service Level Agreement)를 꼼꼼히 검토하여, 서비스 중단 시 클라우드 제공자가 제공할 보상, 다운타임, 데이터 보호 조치 등을 미리 파악해야 한다. 특정 서비스를 프로덕트로 사용하는 경우, 그 서비스의 유지보수 기간을 확인하고, 지원체계를 꼼꼼히 살펴야 한다. 클라우드 프로바이더의 재정적 안정성, 시장 위치, 기술 지원 능력을 평가하여 장기적으로 안정적인 서비스를 제공할 수 있는지 확인하는 것도 중요하다.
사례 : 어도비는 클라우드 인프라의 안정성을 보장하기 위해 클라우드 제공자와의 SLA에 서비스 중단 시 보상 조항을 명확히 포함하고 있으며, 이를 기반으로 클라우드 프로바이더의 안정성 및 지속 가능성을 정기적으로 평가하고 있다.
4.5 데이터 백업 및 이중화(Duplication)
중요한 데이터를 다른 클라우드 서비스 또는 온프레미스에 백업하고 이중화하여 데이터 손실을 방지합니다. 또한 데이터 저장을 한 프로바이더에만 의존하지 않고, 여러 위치에 백업하면 더욱 안전하다.
사례: 슬랙은 AWS를 주 클라우드 플랫폼으로 사용하지만, 중요한 데이터는 이중화하여 다른 리전 및 온프레미스에 백업한다. 이에 따라 특정 AWS 리전에서 장애가 발생하더라도 데이터 손실 없이 빠르게 복구할 수 있다.
4.6 클라우드 이전 전략 수립
기업은 클라우드 서비스나 특정 제품 서비스 중단 시 대체 서비스로 신속히 이전할 수 있도록 사전에 구체적인 이전 전략 마련이 필요하다. 대체 서비스 후보를 선정하고, 필요한 도구와 리소스를 준비해야 한다.
마무리
서비스 선셋은 기술 발전이 지속해서 일어나고 있는 상황에서는 꾸준히 일어날 것이다. 이때 대응 전략의 핵심은 선셋 일정 및 지원 종료일 확인하고 빠른 대체 서비스를 검토한 후 데이터 백업 및 마이그레이션 계획, 애플리케이션 리팩토링 필요성 확인, 비용 분석 및 프로바이더로부터의 기술 지원 활용이 필요하다.
AWS의 Elastic Transcoder의 동영상 변환 서비스가 더 강력한 기능을 제공하는 MediaConvert로 전환을 할 때 API 차이에 대한 자세한 마이그레이션 가이드를 제공하고 고객들이 리팩토링을 통해 효율성을 높이고 혼란을 최소화했던 경험이 좋은 사례가 될 수 있다. 이러한 준비를 통해 갑작스러운 서비스 종료에도 비즈니스 연속성을 유지하고, 기술적 리스크를 최소화할 수 있다.
참고문헌
1) Google Workspace, “Google App Maker will be shut down on January 19, 2021”, Jan 27, 2020
2) Microsoft, “Dear DocumentDB customers, welcome to Azure Cosmos DB!”, May 17, 2017
3) Datacenterknowledge.com, “Dropbox’s Reverse Migration”, Feb 26, 2020
