김명신의 즐거운 하루

11/22일 오전에 한시간 반가량 AWS 서울 리전에 장애가 발생하였습니다. 이에 주요 인터넷 업체들이 제공하는 서비스가 정상 동작하지 않았고, AWS가 네이버 실시간 검색 순위 2위까지 올라가는 위엄(?)을 보였습니다.
사건이 이렇게 파장이 크다보니, 자칭/타칭 전문가들과 언론에서는 정제되지 않은 의견들을 무작위로 쏟아 내고 있는 것 같습니다. 클라우드 무용론을 이야기 하는 이도 있고, 외국계 기업이 개발하는 클라우드는 믿을 수 없다고도 하고, 멀티 클라우드/멀티 리전이 대안이 될 수 있다는 주장을 펼치기도 하더군요. 
클라우드 기술을 수년간 지켜봐온 입장에서 이번 AWS 장애건과 클라우드 도입에 대하여 도움이 되실 만한 글을 간략히 적어 보는 것도 나쁘지 않을 것 같아 평소의 생각을 글로 남겨 봅니다.
거봐라, 까불고 클라우드 쓰더니…
가트너의 보고자료에 따르면 기업체가 연간 집행하는 IT 예산의 72%는 기존에 구축해둔 IT 자산을 유지/보수하는데 사용된다고 합니다. Digital Transformation의 핵심은 전 산업군에 걸쳐 IT 기술을 적극적으로 도입함으로써 기업의 발전을 가속화 하기 위한 전략입니다.  그 취지와 방법에 많은 기업들이 공감하여, Digital Transformation을 위해 더 많은 예산을 집행하고 싶어 하지만, 실제로 IT 예산에 파격적인 투자를 할만큼의 여유를 가지고 있지 못한 경우가 훨씬 많을뿐 아니라, 설사 더 많은 예산을 투입하여 IT 기술을 도입하고 개선하려 해도, 이처럼 대부분의 예산이 기존에 만들어 둔 등대에 불을 밝히는 용도로 사용되어 버리기 때문에 변화의 속도가 기대치에 미치지 못하게 됩니다.
이런 상황에서 다수의 업체가 가장 손쉽게 취할 수 있는 개선 전략은 72%에 달하는 IT 고정 비용을 줄이고, 좀 더 많은 역량(예산/시간/인원)이 회사의 Digital Transformation에 온전히 투입될 수 있도록 하는 것입니다. 회사 내의 IT 부서가 일상적으로 수행하는 업무를 분석하여, 전문성을 가지고 믿을 수 있는 파트너에게 위임함으로써, 새로운 변화를 도모할 수 있는 여유를 만드는 것입니다. 이러한 배경을 충분히 이해하고 있기 때문에 기업들이 클라우드를 적극적으로 도입하고 있는 것이라 믿고 싶습니다.
그러나 클라우드를 도입할 때에는 클라우드가 가진 기술적인 장단점, 특성과 더불어 제약과 극복해야할 부분에 대해서도 반드시 사려깊게 살펴야 합니다. 가장 널리 이야기 되는 부분은 장애를 일상적인 것으로 생각할 것이라는 격언처럼, 장애를 대하는 자세에 대한 근본적인 변화가 필요하다는 부분입니다. 모든 소프트웨어/하드웨어는 장애를 일으킵니다. 하드웨어는 소프트웨어에 비해서 매우 안정적으로 생각되지만, 집에서 일상적으로 사용하는 에어컨이나 냉장고만큼 안정적이지 못합니다. 더불어 소프트웨어는 하드웨어 비해서 더욱 취약할뿐 아니라, 보안공격 등에 광범위하게 노출되어 있기 때문에 지속적인 수정과 보완이 필요합니다. (밥솥은 바이러스에 걸리지 않지만 PC는 바이러스에 걸립니다.) 그런데 이 같은 태생적인 취약성으로 인해, 대규모로 하드웨어와 소프트웨어 인프라를 안정적으로 운영해야 하는 클라우드 제공업체는 고도의 전문성을 바탕으로 문제가 발생했을 경우 적극적으로 문제 증상을 완화하거나, 해소하는 전략을 가지고 있어야 합니다. 일부 머신에 바이러스가 걸리는 경우, 다른 머신으로 바이러스가 파급되지 않도록 차단해야하고, 하드웨어의 고장 등에 대해서도 즉각적으로 대체해야 합니다. 특별히, 보안 문제가 발생하였거나 발생할 가능성이 있는 경우에는 사용자의 동의에 앞서 이를 해결하기 위한 방법을 즉각적으로 강구하고 적용해야 합니다. 그것이 클라우드를 사용하는 다른 사용자를 지키는 유일한 방법이기 때문입니다. 때문에 클라우드 제공업체들은 사용자들의 동의가 없더라도 불가피한 경우 시스템을 일시 중단시키거나 재시작 시키기도 합니다(일정 기간을 유예 해 주는 경우가 더 많기는 합니다). 그런데 클라우드 상에서 운영중인 자사의 시스템이 예상할 수 없는 시점에 발생할 수 있는 클라우드의 중단, 재시작 등에 대하여 사전에 대응책을 마련해 두지 않았다면, 시스템의 부분적인 오류 혹은 전체 시스템의 마비를 가져올 수 있습니다.
이러한 이유로 클라우드를 도입할 때 가장 우선적으로 염두에 두어야 하는 것은 클라우드가 제공하는 서비스의 SLA(Service Level Agreement)를 검토하고, 서비스의 일시 중단등에 대응하는 방법을 강구하는 것입니다. 사용자에게 불편을 감수하라고 할 수도 있으며, 사용시간을 제한하는 등의 임시적인 방법을 강구할 수도 있습니다. 하지만 원칙적으로는 장애발생 내용을 고려하여 관련 코드를 수정하거나 보완하고 장애 복원력이 있는 설계를 해야 합니다. 이를 Cloud Native Design, Cloud Native Architecturing이라고 합니다. 그리고 점차로 클라우드의 장점을 취하되, 단점을 보안하여 전체 시스템의 안정성과 가용성을 확보하기 위한 Cloud Native Design, Cloud Native Architecturing의 중요도가 높아지고 있습니다. 모범 사례의 하나로 Netflix를 들 수 있는데, Netflix는 마치 민방위 훈련과 같이 한달에 한번씩 서비스 중인 시스템의 일부를 강제로 중단시키거나 장애를 일으키는 코드를 주입하여, 장애가 올바르게 처리되는지를 확인하고, 장애 복원력이 있는지를 점검합니다(운영 중인 시스템에는 로그인도 하지 못하게 하는 우리나라의 일반적인 풍토와는 많은 차이가 있습니다.) 또한 그들은 장애를 강제로 유발하는 소프트웨어와 함께 장애 대응 코드 등을 오픈소스로 제공하고 있기도 합니다. 
모든 기업이 반드시 클라우드를 필요로 하는 것은 아닙니다. (자체적으로 대규모의 인프라를 운영 관리할 수 있는 역량과 기술을 가지고 있으며, 자동화 기술을 완비하여 수명의 관리자가 수천대 이상의 시스템은 안정적으로 관리할 수 있다면 말입니다.) 또한 클라우드를 사용하고 싶어도 법과 규정 등에 의해서 클라우드를 활용할 수 없는 기업도 있습니다. 다만, 지금의 시점에서 조망해 보건데, 앞서 언급한 것과 같이 클라우드의 도입은, 일부 극복할 과제들이 없지는 않지만 다수의 기업들이 상대적으로 손쉽게 그들의 IT 자산을 고도화 하고 새로운 변화를 이끌어 내는 마중물의 역할을 하기에 부족함이 없고, 타당하며, 검증된 기술로 볼 수 있을 것 같습니다.  
따라서 지금은 클라우드의 도입을 검토해야 시기를 넘어 클라우드를 사용하지 못하는 이유는 안타까워 해야 하는 시기입니다.
기술 종속성에 대하여
새로운 기술을 도입하고, 새로운 시스템과 플랫폼을 도입할 때에는 늘 기술/플랫폼 종속성과 락인(lock-in) 이야기가 대두 됩니다. 플랫폼 종속성과 락인은 그 자체가 부정적인 의미를 내포하고 있다고 생각될 만큼 반드시 피해야 하는 것으로 생각하지만, 실제로 우수한 플랫폼이 제공하는 긍정적인 가치는 매우 큽니다. 단일의 플랫폼을 활용하면 여러 응용 프로그램들은 플랫폼이라는 공통의 자산을 공유함으로써 예측 가능성과 상호 운영성을 높여 줄 뿐 아니라, 지식의 재사용성을 높여 개발의 가속화와 운영의 편의성 측면에 큰 도움을 줍니다. 부정적인 측면은 기술/플랫폼을 변경하기 어렵기 때문에 타기업이 제공하는 기술/플랫폼으로의 변화가 어렵다는 것인데 이부분은 조금 따져볼 필요가 있습니다. 기술/플랫폼의 종속성을 배제하기 위해서 가능한 기술/플랫폼 중립적인 기술만을 사용하려는 노력은 일면 타당해 보일지 모르겠으나, 여러 기술과 플랫폼을 모두 아우르는 완벽한 중립 기술이라는 것은 환상에 가깝습니다. (야구와 축구를 동시에 할 수 있도록 설계된 사직 야구장을 생각해 보십시오. 야구를 하기에도 축구를 하기에도 적합하지 않은 운동장이 되어버렸습니다. 그리고 지금은 야구만을 하기 위한 플래폼으로 대대적인 개보수를 한것으로 알고 있습니다.)
대부분의 경우 서로 다른 기술/플랫폼의 공통 부분을 제3의 기술로 포장하는 경우가 많고, 아이러니 하게도 이는 제3의 기술에 대한 기술/플랫폼 종속을 유발합니다. 따라서 기술/플랫폼 종속성을 줄이려는 시도를 완전히 무의미 한 것으로 치부할 수는 없지만, 지금처럼 시스템의 빠른 출시와 기민한 개선이 중요한 시기에 과도한 우려의 시각으로 기술/플랫폼의 종속성을 바라보는 것은, 낡은 가치에 대한 과도한 집착일 가능성이 있습니다. 
이 보다 우수하고 적합한 기술/플랫폼을 과감하게 선택하여 풍성한 기능들을 활용하여, 개발과 출시를 가속화 하는 것이 상대적인 득이 높습니다. 육지와 바다에서 동시에 기동 가능한 수륙양용 자동차가 최선이었다면, 람보르기니 스포츠카나, 고급 요트는 만들어 지지 않았겠지요. 
 멀티 클라우드 / 멀티 리전
 클라우드의 도입을 계획하고 있는 회사 중 일부는 이처럼 기술/플랫폼에 종속되는 것을 과도하게 두려워한 나머지, 여러 클라우드 제공업체가 제공하는 다양한 기능 중, VM과 같이 매우 기초적인 인프라수준의 기능만을 사용하고, 고급기능을 의도적으로 사용하지 않으려는 경우가 있습니다. 이러한 모습은 앞서 말씀드린 것처럼 클라우드를 도입하려는 근본적인 배경이 일상적인 업무를 신뢰할 수 있는 클라우드 제공 업체에 위임하여, 예산/인원/시간적인 이득을 취하려 하는 클라우드 도입 배경에 정면으로 위배 됩니다. 이러한 주장을 하는 기업은 대부분 클라우드를 도입하려는 이유를 전혀 이해하지 못하고 있거나, 새로운 기술을 받아들이기 싫어하는 실무자 수준의 의사 결정일 가능성이 높습니다. 
다른 관점으로 여러 클라우드에 공통적으로 적용할 수 있는 제3의 기술을 활용하는 것 또한 완전히 나쁜 전략으로 치부할 수 없으나, 이 또한 제3의 기술에 대한 종속성을 유발한다는 사실이 잊지 마십시오. 더 나쁜 것은 이  같은 제3의 기술이 오픈소스 혹은 일부 집단에 의해서 특정시점의 필요성에 의해 만들어지는 경우가 많아서, 지속적으로 변화하는 클라우드의 기능과 특성을 따라잡지 못하는 경우가 많고, 전체 서비스를 아우르지 못하는 경우가 대부분이라는 것입니다. 통상 멀티 클라우드 전략은 이처럼 서로 다른 방식의 두가지 접근이 있지만, 적지 않은 경우에 기술전략으로 드러나기보다 클라우드를 도입하려는 기업이 클라우드 제공업체를 영업적으로 압박하는 수단으로 활용되는 경우도 있는 것 같습니다. 
그리고 멀티 클라우드 전략의 핵심은 개별 클라우드의 특징과 장점을 잘 파악하여, 개발하려는 시스템에 사용할 최적의 클라우드를 찾아가는 과정이지, 단일 시스템을 구축할 때 여러 클라우드를 섞어 쓰는 것을 의미하는 것이 아닙니다. 이는 가정에서 LG 의 TV와 삼성의 냉장고를 쓸 수 있다는 이야기지, 삼성 TV에  LG 리모컨을 함께 사용하라는 의미가 아님을 이해해야 합니다. 사실 멀티 클라우드와 멀티 리전의 차이는 며느리와 쥐며느리 만큼이나 연관성이 없습니다. 
이미 잘 알고 계시는 바와 같이 클라우드상에서 운영되는 시스템에는 고가용성을 유지하기 위해서 반드시 멀티 리전/멀티 존 등을 적용할 것을 권고합니다. 대다수의 클라우드 제공업체는 각 기능별로 SLA(Service Level Agreement)를 통해서 최소 가용성 수준과 최대 보상 수준을 함께 명기하고 있습니다. 통상 특정 시스템을 개발할 때에는 클라우드의 여러 기능들을 함께 사용하게 되는데, 전체 시스템의 SLA는 클라우드 기능들을 어떻게 결합하여 사용하였는지를 고려하여 계산해 볼 수 있습니다. 실 예로 가용성이 99.9%인 기능 3개를 직렬로 연결하여 사용하면, 시스템 전체의 가용성이 99.7%(99.9%x99.9%x99.9%) 수준으로 떨어집니다. 이 경우 월2시간의 이상의 장애가 발생할 가능성이 있음을 사전에 이해하고 있어야 합니다. 계산된 가용성 수준이 원하는 수준에 미치지 못할 경우 시스템 병렬화 등의 방법을 통해서 Architecture를 개선해야 합니다. 
더하여 고가용성(HA) 전략은 장애복구(DR)과는 구분해서 생각해 보아야 합니다. 극단적으로 빠르게 이루어지는 자동화된 DR은 HA와 유사성이 있을지 모르겠으나, 대부부의 경우 HA와 DR은 그 방법과 절차, 허용범위 등이 매우 다릅니다. 멀티 리전은 단일 클라우드 내에서도 폭넓게 사용되는 방식으로 HA/DR을 위해서 공통적으로 활용될 수 있는 근간이 됩니다. 
 맺으며…
 할말은 더 많지만 글이 길어지면 안 읽으실 것 같아 서둘러 정리합니다. 시장의 자칭/타칭 전문가들이 언론을 통해서 쏟아내는 다양한 메시지는 옥석이 섞여 있을 수 밖에 없습니다.
비전문가의 시선으로 바라보면 모두 그럴싸 하게만 보이지만, 현장에 대한 이해와 클라우드의 특성과 본질을 고려하여 쓰여진 기사는 그리 많지 않은 것 같습니다.
짧은 글이지만 AWS의 장애건에 대해서 그리고 클라우드의 도입에 대해서 균형잡인 시각을 유지하시는데 조금이라도 도움이 되길 바랍니다.

AWS 장애를 바라보며. 클라우드에 대한 단상

댓글