[발 번역] 왜 Twilio는 오늘 AWS 장애에 영향을 받지 않았나?(2011-04-22)

해당 블로그는 KT UCloud의 지원을 받고 있습니다.

해당 내용은 http://www.twilio.com/engineering/2011/04/22/why-twilio-wasnt-affected-by-todays-aws-issues/ 라는 글을 발 번역한 것입니다. twilio는 Voice 와 SMS 관련 어플리케이션을 쉽게 제작할 수 있는 API를 제공해주는 회사입니다. 엔지니어링 블로그에 흥미있는 글이 올라와서 잠시 올려봅니다.

항상 제가 얘기하는 것들 중에 하나가, AWS 나 다른 클라우드 자체의 장애에 대해서 논하기 전에 자신의 서비스가 HA를 제공하는지, fault tolerance 한지 이런 부분을 체크하는 것이 우선입니다. 또 한, 이런 설계를 해놓았다고 생각하시는 업체나 개발자분들께서도 실제 해당 상황과 비슷하게 테스트를 하셔서 실제로, 장애가 없다는 것을 확신하시는 분은 생각보다 적지 않을까 어설프게 생각해봅니다. 가끔, 이런식으로 테스트를 해놔도, 실제 장애때는 상황이 달라서 장애가 발생하는 케이스가 있기도 했습니다. 테스트란 내가 아는 상황에 대한 준비이지, 모르는 상황에 대해서 100% 해둘 수 는 없으니깐요.  그렇기 때문에 이런 식의 자료는 도움이 될 수 있습니다.

참고로 여기에 나오는 AWS 장애는 2011년 4월 22일에 있었던 내용입니다. 올해에 발생했던 이슈에 대한 부분은 아니니 주의하세요. ^^, 그리고 오역에 주의하시기 바랍니다.

오늘 아침 일찍 부터, 아마존 웹 서비스는 동쪽 연안의 데이터센터들에서 몇 가지 서비스 문제를 경험했습니다. 몇몇 사이트들이 영향을 받았고, 클라우드 서비스의 놀라운 성공을 보여주던 유명한 업체들도 영향을 받았을 뿐만 아니라, 클라우드 서비스를 이용할 때, 유연한 아키텍처의 중요성도 함께 일깨워줬습니다.

Twilio의 API와 서비스는 오늘 AWS 장애에 영향을 받지 않았습니다 Twilio는 여전히 아마존 웹 서비스 위에서 성장하고 확장되고 있습니다. Twilio는  가끔씩 발생할 수 있는 장애의 영향을 최소화 하기 위한 아키텍처 설계 원칙을 따르고 있습니다만,  인프라스트럭처에 닥치는 이슈들은 피할 수 없습니다.

Unit-of-failure is a single host

가능하다면, 서버 장애가 발생한다고 가정을 하고 서비스와 인프라스트럭처를 선택해야 합니다. 여러대의 서로 연관된 서버를 구축하는 것보다 한대의 서버로 간단한 서비스를 구축하고, 이에 대한 복제된 서비스를 구축하면, 서버 장애시에도 서비스를 할 수 있습니다. (역자 주: 이런식으로 구성하려면, 데이터가 Shared Northing 형태가 되어야 합니다. 더 고민해야 될 부분은, 부하가 몰릴 경우, 이에 대해서 어떻게 부하를 잘 분산할 것인지가 그 다음 고민이 될껍니다.)

예를 들어, 한 어플리케이션이 비지니스 로직 컴포넌트 A,B,C 로 구성되어 있고, 각각이 분리된 호스트에서 동작한다면, 우리는 서비스 그룹을  (A, B, C), (A, B, C) 혹은 컴포넌트 풀을 구성해서 (A, A, …), (B, B, …), (C, C, …) 형태로 구축할 수 있습니다. (A, B, C) 형태로 구성을 하게 되면 한대의 장비의 장애는 전체 시스템 그룹의 유실을 야기하게 됩니다. 독립적인 풀로 자원을 나눔으로써, 한 대의 장비의 장애는 그냥 한대 장비가 기능하는 정도로의 손실만 야기합니다. 해당 접근법의 장단점은 다른 포스트에서 더 다루도록 하겠습니다.(역자 주: 저는 최초에 한 장비에 (A,B,C)를 다 구성해둔 것으로 생각을 하고, 이해가 안되었는데, 이러면 A,B,C 한쌍의 서버가 죽어도 다른 (A,B,C) 쌍 들의 서버가 서비스가 된다고 생각을 했는데, 이런 느낌이 아니었습니다. 각 컴포넌트 들은 각각 하나의 장비이고,  (A,B,C) 이렇게 세 대가 서로 엮여있는 의존적인 상황을 설명하는 것입니다. 이 때 장비 한대가 나가면 하나의 서비스 군 자체가 서비스가 안되는 거죠. 그리고 풀은 (A,A,A) (B,B,B) (C,C,C) 형태로 각각의 서비스 풀이 있고, 각 기능의 요청을 풀로 하고 전체가 하나의 시스템을 구성하는 것입니다. 그래서 A한대가 죽더라도 (A,A) (B,B,B) (C,C,C) 이므로 여전히 서비스가 가능합니다. 오직 A 한대 정도의 기능만 손실이 생긴겁니다.)

Short timeouts and quick retries

장애가 발생했을 때, 소프트웨어가 해당 장애를 빨리 확인하고, 요청을 다시하게 됩니다. 각 서비스의 다수의 복제된 서비스가 동작하면, 하나가 장애가 나거나 이용할 수 없더라도, 타임아웃이 나고 다시 재시도 할 수 있습니다.

  1. 요청을 보내고, 일시적인 장애를 리턴받거나, 짧은 정해진 시간 동안 응답을 받지 못한다면( 짧은 시간이라는 것은 어플리케이션의 동작에 달려있습니다.)
  2. 요청을 서비스의 다른 인스턴스로 재시도 합니다.
  3. 서비스에서 허용된 내 까지 재시도합니다.

만약, 분산시스템에서, 빨리 실패하지 않고 재시도 한다면, 특히 process나 thread 기반의 시스템일 경우,  리소스가 소비되어서 서비스가 느려지거나 서비스가 되지 않는 것을 볼 수 있습니다.(역자 주: DOS 공격과 비슷한 상황이 됩니다. 왜 nginx가 apache 보다 DOS에 유리한지는 그 서비스 모델에 있습니다.)

Idempotent service interfaces

요청을 재시도 하는 것에 대해서 안전하게 서비스를 구성해야 합니다. 해당 개념에 익숙하지 않으면, 멱등성(idempotency) 이라는 놀라운 세상에 대해서 읽어보시기 바랍니다.

“컴퓨터 사이언스에서, 멱등성(idempotent) 이라는 단어는 한번 이상 실행되더라도 항상 같은 결과를 내는 것이라고 설명할 수 있습니다.”

(역자 주: ADD 1 이라는 명령이 여러 번 재시도 한다면 어떻게 될까요? 처음에 값이 0이었다면 3번 재시도 후에 3이 되어 있을 것입니다. 그런데 SET 1 이라는 명령이 세번 실행되면 어떻게 될까요? 그냥 1입니다. 이런 개념이 멱등성입니다. 보통 DBMS 등에서의 복제 로그나 WAL 로그등은 이런 형태의 명령으로 치환되어서 저장이 됩니다.)

의존 적인 서비스의 API가 idempotent 하다면, 실패한 요청에 대해서 재시도해도 안전하다는 것을 의미합니다.(  위의 #2를 보시기 바랍니다.)  만약 서비스가 유저 계정에 돈을 넣는 기능을 제공한다면, idempotent  한 인터페이스는 서비스가 요청에 실패한 후, 안전하게 재시도하는 것을 보장합니다. 여기에는 많은 얘기거리가 있고, 미래에 좀 더 다루도록 하겠습니다.

(역자 주: 그러나, idempotent  라는 것은 쉽게 보시면 안되는 어려운 개념입니다. 예를 들어, 동시에 두 명이 유저의 계정에 돈을 추가하는데 처음에 100원이 있고 A는 50원을 추가해서 150으로 만들고, B는 100원을 추가해서 200으로 생각하고 리퀘스트를 보내는 데, A는 실패해서, 성공하고, B는 성공했다고 하면, 최종적인 결과가 150이 될 수 도 있습니다. 물론, 작업의 최종 수행 시간을 보고, 이를 처리하도록 해서 해결하는 방법도 있지만, 이를 설계하기 위해서는 많은 고민이 필요합니다. 해당 연산이 처리될 수 없다면, 명확하게 에러를 보내고 이에 대한 인터페이스및 컨셉을 명확하게 구성하셔야 합니다. Idempotent 때문에 고생하는 케이스 많습니다.)

Small stateless services

비지니스 로직을 간단한 동일 서비스 풀로 구성된 작은 stateless 서비스들로 나눕니다. Twili의 인프라스트럭처는 voice and SMS APIs  의 부분을 구현한 많은 서비스 풀로 구성됩니다. 예를 들어, TwiML의 <Record> 를 사용하여 레코딩을 할 때, 음성의 질을 향상시키고, 레코딩 서버 풀에서 제공하는 스토리지에 저장하는 작업을 레코딩의 뒷부분에서 하게 됩니다. stateless 레코딩 서비스 풀은 동작중인 서비스에서 다른 레코딩 서비스에 실패한 리퀘스트를 재시도 하는 것을 허용합니다. 게다가 레코딩 서버 풀의 사이즈는 부하에 따라 실시간으로 쉽게 증가시키거나 줄일 수 있습니다.(역자 주: stateless 하다는 의미는 아무것도 저장하거나 남기지 않는 다는 뜻입니다. 보통 function language를 사용하는 쪽에서는 side-effect 가 생기지 않는 다는 것을 강조하는데, stateless 하다는 것도 동일한 효과를 제공합니다. 기억하는 것이 없고 항상 들어온 값으로 연산하면, side-effect 라는게 없습니다.)

Relax consistency requirements

엄격한 일관성이 요구되지 않을 때는, 읽기용으로 데이터를 이중화한 풀을 생성할 수 있습니다. 중요한 핵심 개념중에 하나는, 어플리케이션에서 읽기와 쓰기 데이터를 구분할 수 있다는 것입니다. 예를 들어, 드물게 쓰여지는 큰 데이터 풀이 있을 때, 이 데이터를 읽기용 과  쓰기용으로 분리합니다. 이렇게 분리 함으로 써 서비스 요청에 연관되지 않은 읽기 복제본을 만들 수 있습니다. 예를 들어, DB의 마스터에 데이터를 쓰고, DB slave에서 데이터를 읾음으로써, 성능과 가용성을 증가시키기 위해서, 읽기용 slave 의 수를 쉽게 확장 할 수 있습니다.

AWS 이슈는 클라우드에 서비스되는 어플리케이션의 디자인에 대해서 깊게 고려할 필요를 보여줍니다. Twilio 안으로 외부 서비스를 쉽게 연결하고 구성하기 위해서 도움이 될 만한 잘 알려진 분산 시스템 디자인의 베스트 프랙티스를 강조하고 있습니다.

[UPDATE] 최근 AWS 이슈의 주요 원인은 아마존 EBS 서비스였습니다. Twilio는 EBS를 오직 중요하지 않고 반응속도에 신경쓰지 않는 서비스에만 사용하고 있습니다. EBS가 아직 “unit-of-failure is a single host principle.” 를 만족시키지 못하기 때문에, 인프라스트럭처의 저장소로서의 중요한 부분에 대해서는 천천히 적용하고 있습니다.  EBS에서 문제가 발생하면, 의존하는 서비스가 모두 장애가 발생하게 됩니다. 대신에, 각 EC2 장비의 임시 디스크의 저장소로의 사용에 초점을 맞추고 있습니다. 임시 디스크가 고장나면, 오직 해당 장비에만 에러가 국한됩니다. 다음 포스트에 I/O 성능을 높이기 위해서 임시 디스크 간에 어떻게 RAIDo striping을 적용하는지에 대해서 설명한 계획이 있습니다.


이것은 Twilio Engineering blog의 첫번째 포스트입니다. 아마존과 같은 클라우드 플랫폼의 기능을 이용해서 Twilio의 스케일링과 구현에 대한 경험을 나누는 것에 적극적입니다. 이런 주제에 관심이 있다면, 분산 시스템 구축에 대한 멋진 블로그가 있습니다.