아마존 웹 서비스가 10년간 배운 열 가지 – Werner Vogels

Written by Dr. Werner Vogels * Disclaimer

AWS의 시작은 10년 전, 3월 14일 Amazon S3 스토리지 서비스를 시작하면서 시작되었습니다. 지난 10년을 되돌아  보면서, 가장 낮은 가격으로 예측 가능한 성능을 보장하면서도 안전하고 믿을 수 있는 확장성 높은 글로벌 서비스를 만들고 운영하면서 배운 것은 수백 가지가 넘습니다.  클라우드 컴퓨팅의 개척하면서 글로벌 서비스를 제공하는 우리에게 이러한 경험은 비즈니스에서 매우 중요합니다.

저희는 “경험에는 어떠한 압축 알고리즘도 없다”라고 말해왔습니다. AWS를 사용하는 백만이 넘는 고객사에는 각자 사용자가 있고, 그 숫자도 수십 억이 넘습니다. 이러한 고객과 함께  많은 경험을 할 수 있는 기회를 얻었고, AWS 고객에 제공할 서비스를 지속적으로 개선할 수 있었습니다.

저는 이 중에서 몇 가지 배운 점들을 뽑아서 여러분들과 공유하고자 합니다.

1. 진화 가능한 시스템을 만들어라
처음 시작한 날(Day One), 우리가 만드는 소프트웨어가 일 년 후에도 똑같이 돌아가는 소프트웨어가 아닐 거라는 점을 알았습니다. 고객의 증가에 따른 확장성 문제를 해결하기 위해 아키텍처를 계속 바꾸고 변경할 필요가 생길 때 마다 수십 수백 번 바꾸었습니다.

하지만, 장애 공지를 한 후 잠깐 멈추고 시스템 업그레이드를 하는 옛날 방식의 접근을 사용할 수 없었습니다. 왜냐하면 글로벌 인터넷 비즈니스는 24시간 가용한 우리 플랫폼에 의존하고 있기 때문입니다. 따라서, 서비스가 다운되지 않으면서도 새로운 소프트웨어 부분을 추가하는 아키텍처를 만들어야 했습니다. Marvin Theimer (아마존 핵심 개발자)는 농담 삼아 Amazon S3는 비행 중인 하나의 엔진을 가진 세스나 비행기로 시작해서 점점 시간이 지나 737기, 747기 편대 그리고 이제는 에어버스 380 편대로 진화 됐다고 이야기하기도 합니다. 그동안 이렇게 비행기를 운행 하면서 공중 주유를 하기도 하고, (알아채지는 못하셨지만) 승객들을 이 비행기에서 저 비행기로 옮기기도 하였습니다.

2. 예상치 못한 일이 발생할 거라 생각하라
문제는 항상 발생하고, 언제라도 어떤 것도 장애가 나올 수 있습니다.(Failures are a given and everything will eventually fail over time). 라우터에서 하드 디스크, 운영체제에서 TCP 패킷이 깨지는 메모리 단위, 단기적인 오류부터 영구적인 장애까지도 말입니다. 이는 비싼 장비를 사용하든 저렴한 장치를 이용하던 항상 일어납니다.

이것은 확장성 측면에서 중요하게 배울 점입니다. 예를 들어, 아마존 S3는 트릴리온(Trillions, 수조)의 객체를 처리하기 때문에 아주 낮은 확률이라도 오류가 나는 것이 현실입니다. 이러한 오류 시나리오를 이미 예견되지만, 더 많은 것들은 아직 알 지 못하는 게 많습니다.

우리는 왜 생기는 건지는 몰랐다 해도 자연적으로 발생하는 이러한 고장을 기꺼이 포용하는 시스템을 만들 필요가 있었습니다. 시스템은 “집에 불이 났다”하더라도 계속 운영되어야 합니다. 전체 시스템을 다운 시킬 필요 없이 영향을 받고 있는 부분 만을 관리 할 수 있는 것이 중요합니다. 우리는 시스템의 전반적인 지속적 운영을 유지 할 수 있도록 장애의 “폭발 반경”을 관리할 수 있는 기반 방법론을 만들었습니다.

3. 프레임워크가 아닌 재료를 만들어라
우리 고객이 서비스를 사용하고 싶은 욕구가 늘  ‘현재 진행형’이라는 것을 깨닫게 되었습니다. 즉, 우리 고객들이 예전 IT 하드웨어나 데이터 센터의 구시대 유물에 대한 제약에서 벗어나자, 지금까지 볼 수 없었던 새롭고 흥미로운 사용 패턴을 가진 시스템을 고객 스스로 개발하기 시작했습니다. 그래서, 우리는 고객의 요구에 빠르게 기능을 조달해 드리기 위해서 엄청나게 민첩하게 움직여야 했습니다.

우리가 제공하는 가장 중요한 메커니즘 중 하나는 고객들에게 기본 재료(Primitivies)와 도구 모음을 제공하고, 이를 선택하여 고객들이 선호하는 방식으로 AWS 클라우드를 결합하는 자신들 만의 방법을 선택하도록 하는 것입니다. 기존 처럼 사용하도록 강요하는 단일 프레임 워크를 제공하는 대신 말입니다. 이러한 방법은 우리 고객들이 직접 활용하도록 하는 성공을 거두었고, 그 뒤에 나오는 AWS 서비스 역시 고객들에게 익숙한 이전과 같은 재료 서비스로서 만들어지게 되었습니다.

고객들이 자신의 손으로 서비스를 가지고 실제 구축을 시작하기 전까지는 특정한 우선 순위는 두어 고객을 위한 것인지 여부를 예측하는 것은 어렵다는 것을 인식하는 것이 중요합니다. 최소한의 기능 세트와 새로운 추가 서비스를 제공하여 고객이 새로운 기능과 서비스를 확장하기 위한 로드맵을 만들어 나가도록 하는 것이 바로 이 때문입니다.

4. 자동화가 핵심이다
지속적인 운영을 해야 하는 소프트웨어 서비스를 만든다는 것은 고객에게 전달하는 일반적인 소프트웨어와 근본적으로 다릅니다. 확장성 있는 시스템을 관리하는 것은 고객의 신뢰성, 성능 및 확장에 대한 기대에 부응하기 위해 매우 다른 사고 방식이 필요합니다.

이를 달성하기 위한 핵심 매커니즘은 바로 오류가 발생하기 쉬운 수동 작업을 제거하고, 관리 가능하도록 자동화하는 것입니다. 이를 위해, 우리는 비즈니스의 주요 기능을 제어하는​​ 관리 API를 구축하였습니다. AWS에서는 고객도 이렇게 할 수 있습니다. 필수적인 빌딩 블록으로 응용 프로그램을 분해하여, 각각의 관리 API를 가지고 확장 중에도 안정적으로 예측 가능한 성능을 유지하기 위한 자동화 규칙을 적용 할 수 있습니다. 테스트는 서버 또는 인스턴스에 SSH를 접근 해야 하는 경우가 있다면 좋은 리트머스 테스트 항목입니다. 이러한 작업은 더 자동화 해야 하기 때문입니다.

5. API는 영원하다
이미 아마존 소매 사업 경험에서 배운 교훈 이었지만, AWS의 API 중심 사업에서 더 중요해졌습니다. 고객이 일단 API를 사용하여 응용 프로그램이나 시스템의 구축을 시작하면, API를 바꾸는 것은 불가능합니다. 이는 API 변경 자체가 고객의 사업 운영에 영향을 미칠 것이기 때문입니다. 올바르게 API를 설계하는 것은 매우 중요한 과제임을 알고 있습니다.

6. 자원 사용 방식에 대한 가시성 확보
적절한 과금 모델을 가지는 서비스에 대한 재무 모델을 구축하는 경우, 특히 큰 규모의 매출과 낮은 이익을 가지는 사업을 할 때 서비스 비용과 운영에 대한 좋은 데이터를 가지고 있어야 합니다. AWS는 서비스 공급자로서 비용에 대해 꼭 인식을 해야 했습니다. 왜냐하면, 우리 고객에게 서비스를 제공하고 추가 비용을 절감하기 위해 업무 효율을 낼 수 있는 분야를 찾아서 고객에게 가격 절감 부분을 다시 되돌려 주기 위함이었습니다.

초기에 특정 사용 패턴을 제공하는 데 필요한 리소스에 대해 몰랐던 것 중의 대표적인 것이 S3였습니다. 우리는 스토리지 및 네트워크 대역폭을 계속 보강해야 하는 자원이라고 생각하고 있었습니다. 그런데, 요청량 또한 중요한 부분이었다는 것을 깨달았습니다. 만약 고객은 많은 작은 파일이 있으면, 이때 이들 파일이 수백 만번의 요청을 만들더라도 스토리지 및 대역폭은 더 많아지지 않습니다. 우리는 AWS를 지속 가능한 비즈니스가 되도록 리소스를 사용하는 모든 차원을 고려하기 위한 모델을 조정해야 했습니다.

7. 처음부터 보안을 구축하라
고객을 보호하는 것은 항상 최우선이어야 하며, AWS에게도 마찬가지였습니다. 운영 적인 측면 뿐만 아니라 도구 및 메커니즘 모든 분야에서 그렇습니다. 앞으로도 영원한 최고의 투자 영역입니다.

우리는 빨리 배웠던 다른 방법은 서비스를 디자인하는 초기부터 보안 기능을 통합하여, 안전한 서비스를 구축하는 것입니다. 보안팀은 무엇 인가를 만들고 난 후, 검증하는 팀이 아닙니다. 서비스 기획 첫날부터 파트너로서 참여하여 보안에 대한 부분을 신경 써야 합니다. 보안에 관해서는 일절 타협이 없습니다.

8. 암호화는 제일 중요하다
암호화는 고객이 자신의 데이터에 대한 접근 권한을 가진 사람을 완전한 통제를 보장하기 위한 가장 중요한 메커니즘입니다. 10년 전에는 암호화를 위한 도구와 서비스의 사용은 어려웠고, 어떻게 우리 서비스에서 암호화를 가장 잘 통합하는 방법을 배운 것도 불과 몇 년 전입니다.

보안 규정 준수를 위해 S3의 서버 측 암호화 제공 부터 시작했습니다. 데이터 센터에서 디스크가 삭제 된 경우, 어떤 데이터에도 접근할 수 없습니다. 그러나, Amazon CloudHSM(하드웨어 보안 모델의 경우) 도입 이후, Amazon Key Management Service 출시로 인해 고객은 자신의 암호키를 직접 사용할 수 있게 되어 키를 더 이상 직접 관리할 필요가 없습니다.

암호화 지원은 이제 새로운 서비스 설계 단계에서 통합되어 있습니다. 예를 들어, Amazon Redshift 각 데이터 블록은 기본적으로 랜덤 키로 암호화 되어 있고, 이들 랜덤 키 집합은 마스터 키로 암호화 되어 있습니다. 마스터 키는 고객이 관리합니다. 중요한 비즈니스 데이터와 개인 정보에 대한 접근를 해독하고 가질 수 있기 때문입니다.

암호화는 우리 사업에 가장 높은 우선 순위에 있습니다. 우리는 고객들이 더 쉽게 자신과 고객을 보호 할 수 있도록, 암호화 기능을 사용할 수 있도록 하겠습니다.

9. 네트워크의 중요성
AWS는 다양한 워크로드를 지원해 왔습니다. 대량 트랜잭션 처리에서 대용량 비디오 트랜스 코딩을 위한 고성능 병렬 컴퓨팅, 대규모 웹 사이트 트래픽 등이 네트워크 측면에서 각 업무에 대해 각각 자신의 요구 사항을 가지고 있습니다.

AWS는 그것이 무엇이든지 고객의 워크로드가 가진 요구 사항을 충족하기 위해 적용 가능한 유연한 네트워크 인프라를 제공할 수 있는 데이터 센터의 배치와 운영을 혁신 하는 독특한 기술을 개발했습니다. 시간이 지남에 따라, 다양한 고객을 확보하기 위해 우리 고유의 하드웨어 솔루션을 개발하는 것을 두려워하지 말아야 한다는 사실을 배웠습니다. 이는 최고 수준의 보안을 제공하기 위해 네트워크에서 AWS 고객을 서로 격리하는 기능 등 우리의 매우 구체적인 요구 사항을 충족합니다.

AW 내부에 설계된 네트워크, 하드웨어 및 소프트웨어는 고객을 위한 성능 향상을 위해 가상 머신에서 네트워크를 사용하는 가상 비용에 대한 부분입니다 네트워크 접근은 공유 자원이기 때문에 고객은 필요한 만큼 네트워크를 사용하고 비용을 지불 할 수 있어야 합니다. 루트 I/O 가상화를 지원하는 네트워크 카드(NIC)를 개발하여 각 VM에 가상화 NIC를 제공하게 되었습니다.이것은 2배 지연 속도를 감소 시키고, 네트워크 대기 시간 변동에 10배가 넘는 성능 개선이었습니다.

10. 창의성을 막지 마라
AWS 개발팀은 고객을 위한 매우 폭넓고 깊은 플랫폼을 만들기 위해 많은 서비스와 기능을 제공하여 왔습니다. 하지만, AWS가 내부에서 개발한 것 보다 더 풍부한 기능을 제공합니다. 다양한 개발자 생태계와 오픈 소스 라이브러리가 생겨났고, 새로운 방향으로 플랫폼이 확장됨에 따라 AWS 파트너가 제공하는 많은 서비스가 존재합니다.

예를 들어, 결제 서비스를 제공하는 Stripe, 문자 메시지를 전송하는 프로그램을 만드는 Twilio 등이 있습니다. 고객의 대부분은 특정한 자체 기능 요구 구현을 위해 AWS에 자신들 만의 플랫폼을 구축 하고 있습니다 : Eagle Genomics는 유전 데이터 처리 플랫폼을 구축하고 있으며, Ohpen는 AWS상의 소매 금융을 위한 플랫폼을 구축하였고, Philips는 의료 데이터를 관리하기 위한 Healthsuite 디지털 플랫폼을 구축하고 있습니다. 중요한 것은 AWS 플랫폼에는 고객들이 할 수 있는 것과 할 수 없는 것을 구분하는 게이트 키퍼가 존재하지 않는다는 것입니다.”게이트 키퍼가 없다”는 점은 혁신적인 프로세스를 제공하여, 예기치 않은 새로운 발명을 위해 다양한 가능성을 열어 줄 수 있습니다.

지금까지 고객과 함께 우리가 배워온 것을 공유하였는데, 향후 10년 동안 우리가 새롭게 배울 점 역시 기대하고 있습니다. 우리는 아직 첫날(Day One)이기 때문입니다.

Disclaimer
본 글은 Werner Vogels의 허락 하에 10 Lessons from 10 Years of Amazon Web Services를 한국어로 번역한 글로서, 본 글은 Werner Vogels의 개인적인 의견이며, 본 블로그의 의견이 아닙니다. 한국어 번역 기사인 본 글에 대한 인용 및 사용 허가는 오직 Werner Vogels의 영문 원글에 효력이 있습니다. 본 글을 인용하실 때에는 이러한 주의 사항을 반드시 추가하시기 바랍니다. (Disclamar: This article is a Korean translation of 10 Lessons from 10 Years of Amazon Web Services written by Werner Vogels. It is not opinion of this blog and this translation may contain some errors or incorrect expressions. Please only refer to the original article that was published in English for accuracy.)

- Channy Yun (윤석찬);

※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)