서비스 출시 이래 클라우드는 서버 등의 IT 인프라를 안정적으로 운영하면서도 비용도 절감할 수 있는 방식으로 생각되어 왔습니다. 하지만 지난 11월 말에 있었던 AWS의 대규모 접속 장애 발생 후, 현실은 그렇지 않을 수 있으며, 특히 전산 장애 발생 시 이에 대비한 백업 전략이 매우 중요하다는 사실을 새삼 절감했습니다. 멀티(Multi) 클라우드, 하이브리드(Hybrid) 클라우드 등 다양한 안전장치의 확보와 그에 따른 추가 비용도 불가피하다는 인식을 하게 됐습니다.

<로켓펀치> AskMe 3회에서는 클라우드 서비스의 운영 안정성에 대해 살펴보고, 본격화되는 클라우드 시대의 클라우드 서비스 백업 전략 및 실행에 대해 알아봅니다.

 

정창훈 CTO @당근마켓

신현묵 CTO @GooDoc

이동인 CEO @WhaTap

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

 

1. 안정성 경보 울린 AWS 대규모 접속 장애 2. 클라우드 시대, 재난 방지 대책의 새로운 관점 3. 당장 실행할 수 있는 백업 전략 구축 노하우 4. 클라우드 시대를 준비하는 실무자의 자세

* AWS 대규모 접속 장애 사건이란?

▲ AWS 장애로 인한 마비된 홈페이지 2018.11.22

2018년 11월 22일, AWS의 서울 지역(region) ‘아마존 엘리스틱 컴퓨트 클라우드’ 서버에서 도메인네임시스템(DNS) 오류가 발생했다.

AWS를 이용하는 국내 업체들은 오전 8시 19분부터 84분 동안 홈페이지 연결 접속 장애를 겪었다. 배달의민족, 쿠팡, 야놀자, 여기어때, 푹 등의 인터넷 서비스와 업비트, 코인원, 고팍스 등 암호화폐 거래소, 스마일게이트 등의 게임 서비스, KB금융지주 ‘클래온(Clayon)’ 사이트와 신한은행 ‘쿱’ 등 금융사 서비스가 2시간 이상 정상적인 서비스를 제공하지 못했다.

세계 1위 업체인 AWS가 일으킨 ‘역대급’ 사고는 대다수 이용자가 ‘그냥 맡겨 놓으면 되는 줄’ 알았던 클라우드 역시 안전장치는 필요하다는 점을 새삼 환기하고 있다.

*          *          *

[ 안정성 경보 울린 AWS 대규모 접속 장애 ]

1. 지난 11월 말, AWS DNS 통신 장애가 있었습니다. AWS는 클라우드 서비스의 ‘안정성’과는 별개의 문제라고 선을 긋긴 했습니다만, 어떻게 해석할 수 있을까요?

정창훈 CTO @당근마켓

“AWS 장애로 서비스를 정상적으로 제공하지 못한 고객들이 있었기 때문에, 클라우드 서비스의 안정성 관련 사례 중 하나로 기록될 것”

AWS에서 이번 문제가 클라우드 서비스의 안정성과 별개라고 이야기하지 않았을 것이라 생각합니다. 클라우드 서비스에 장애가 있었고 이로 인해 서비스를 정상적으로 제공하지 못한 고객들이 있었습니다. 물론 이 문제가 클라우드 서비스라서 발생한 것은 아니지만 클라우드 서비스의 안정성에 대한 사례 중 하나로 남게 될 것입니다.

신현묵 CTO @GooDoc

“인터넷이나 통신 서비스가 가질 수 있는 보편적인 문제, 오히려 클라우드 서비스였기 때문에 빠르게 문제를 잡을 수 있었다고 생각”

클라우드의 안전성에 대한 큰 의미로 해석한다면, 안전성에는 큰 문제가 없다고 생각합니다. 다만, DNS 통신장애가 이번에 발생한 휴먼 에러에 가까운 실수는 언제나 발생할 수 있는 요소에 해당합니다. 전문가라고 하더라도, 해당 문제는 각각의 서비스를 별도로 운영하거나 IDC에서도 동일하게 발생될 수밖에 없는 이슈였기 때문에 이 문제는 서비스 운영과 관련된 실수라고 봐야하며, 해당 문제를 빠르게 대처한 것은 오히려 클라우드여서 전체적인 문제를 빠르게 잡을 수 있다고 생각합니다. 물론, 좁은 의미로 해석된다면 인터넷이나 통신 서비스가 가질 수 있는 보편적인 문제였다고 설명하는 것이 맞다고 생각합니다.

이동인 CEO @WhaTap

“언제든지 일어날 수 있는 일, 다만 상황과 원인을 즉각적으로 발표하지 않는 등의 늦은 대응은 아쉬워”

DNS 장애는 일어날 수 있는 일입니다. 그리고 모든 클라우드 서비스는 장애가 발생할 수 있습니다. 다만 이번 사고에서 아쉬운 점이 있다면 AWS에서 상황과 원인을 즉각적으로 발표하지 않은 것입니다. 한국 아마존은 미국 본사로부터 확실하게 권한을 위임받아서 장애 발생 시 더 빠른 대처를 보여줘야 합니다.

2. 전적으로 서비스를 한 클라우드에 의존한다면 장애 발생 시 속수무책일 수밖에 없습니다. 그동안 각 클라우드 서비스 제공업체들은 어떤 대책을 갖고 있었나요?

정창훈 CTO @당근마켓

“하나의 클라우드에만 의존했기 때문에 발생한 장애라고 생각하지 않아, AWS에서는 문제 상황을 대비해 최소 2개 이상의 가용 영역(Availability Zone) 제공하고 있어”

한 클라우드에 의존해서 장애가 발생했다고 생각하지는 않습니다. 여러 클라우드를 사용하더라도 그 클라우드 회사들이 하나의 IDC를 공유하거나 하나의 통신선로를 이용한다면 마찬가지입니다. 또한 IDC에서 직접 운영하는 경우 디스크 문제, 전원 문제 등으로 서버가 종료되는 일이 다반사입니다. 기존에 이런 문제가 발생하면 개발자가 직접 IDC로 뛰어가거나 IDC 상주 인력이 빠르게 문제 해결을 해줘야 했었습니다. 클라우드에서는 이정도 문제는 자동화 솔루션을 이용해 대부분 문제가 일어났는지도 모르게 지나가는 경우가 많습니다.

AWS에서도 서비스 안정성을 위해 최소 2개의 AZ 라고 부르는 가용영역을 제공하고 개발자들에게 하나의 가용영역에 문제가 발생하는 상황을 항상 가정하라고 이야기합니다. 다만 이번에는 서울 리전 전체적으로 발생했던 문제였고 이에 대한 AWS의 준비는 부족한 면이 있었다고 생각합니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“장애를 100% 방지하는 것은 불가능, NAVER CLOUD PLATFORM을 비롯한 많은 클라우드 제공업체에서는 다중 존(Multi-Zone) 혹은 가용 존(Availability Zone)을 제공하여, 고객들의 서비스를 분산시켜 장애 영향도를 최소화하도록 권고”

장애는 100% 방지할 수 없고 발생 시에 최우선으로 장애를 복구하는 노력과 더불어 클라우드 서비스 제공자들은 고객과의 소통이 중요합니다. 물론 모든 클라우드 서비스 제공자들이 이중화, 분산화 등 다양한 방법을 통해 인프라와 시스템 가용성을 높이는 구조를 만들고 있고, AWS의 사태처럼 운영상의 실수가 생기지 않도록 운영자의 조작이 필요 없는 운영 자동화를 많이 하고 있지만, 그렇다고 100% 방지는 안 되므로, 빠른 소통과 함께 빠른 대응책을 제시하는 것입니다.

NAVER CLOUD PLATFORM을 포함해서 많은 (전부는 아닙니다.!!) 클라우드 업체들은 다중 존(Multi-Zone) 혹은 가용 존(Availability Zone)으로 한 리전(지역)에 두 개 이상의 IDC에서 클라우드 서비스를 제공하고 있으며, 고객들의 서비스를 Multi-Zone에 분산시켜서, 장애 영향도를 최소화 하도록 권고하고 있습니다. 이번 AWS 장애에서도 AWS는 그 부분을 언급하긴 했으나, 그렇다고 모든 것을 고객 책임으로 돌릴 수는 없으며, 항상 고객과 커뮤니케이션을 하면서 서비스 가용성을 높이고 장애에 빠르게 대응하는 것이 중요합니다.

이동인 CEO @WhaTap

“많이 사용하는 ‘IDC 이중화’는 물리적인 한계가 있으며, 클라우드 서비스 제공업체에서는 리전의 개수를 늘려야 해 ”

국내 주요 서비스들은 모두 IDC(인터넷 데이터 센터)를 이중화하고 있습니다. 이는 물리적인 문제를 함께 가지고 있기 때문에 클라우드 서비스 제공업체에서 대책을 마련한다면 리전의 개수를 늘려야 합니다. 예를 들어 MS Azure는 서울과 부산에 리전을 가지고 있습니다. 아마존도 향후 리전을 늘릴 것으로 예상하고 있습니다.

3. 그동안 재해복구(Disaster Recovery) 시스템 구축에 대해 국내 기업의 인식은 어땠습니까?

이동인 CEO @WhaTap

“금융권에는 잘 구축되어있는 편, 스타트업의 경우 대부분 DR 시스템을 갖추지 못하고 있어”

금융권이 재해복구 시스템에 가장 민감한 분야라고 할 수 있습니다. 금융권에선 통상 주 센터와 DR 센터 간 거리가 20Km 내외로 떨어져 있으면 안전한 것으로 보고 있으며 한국은행이 추진하는 금융공동백업센터의 경우 떨어진 거리를 140Km로 정하기도 했습니다. 하지만 스타트업의 경우 대부분의 기업이 재해복구 시스템을 갖추지 못한 것이 현실입니다.

정창훈 CTO @당근마켓

“재해 발생 빈도 대비 서비스 구축 비용을 고려하면 일반적인 서비스 업체에서는 쉽지 않은 일”

재해복구 시스템은 금융이나 의료 등 장애가 발생했을 때 영향이 큰 경우에 주로 하는 편이라고 알고 있습니다. 일반적인 서비스 업체의 경우 재해복구에 대해서 신경쓰는 것은 쉽지 않습니다. 재해복구 시스템을 구축하는 비용이 만만치 않은데 장애가 그렇게 자주 발생하는 것도 아니고 장애가 발생해도 피해 금액이 많지 않기 때문입니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“서비스 가용성을 위한 ‘서비스 이중화’ 차원에서 접근해야”

일반적으로 국내 기업들은 재해복구(Disaster Recovery)에 대해 ‘하면 좋은데 비용은 비싸고, 정말로 확률이 거의 없는 재해 재난을 위해 비용 투자를 해야 하는가’라고 인식하고 있습니다. 그러나 이는 재해 복구 순서의 의미일 때이고, 장애 대비의 수준으로 클라우드를 활용할 때는 전혀 다릅니다.

서비스/업무 시스템을 분산시키는 구성 전략이므로 추가 비용이 드는 것이 아니고, 장애가 발생해도 100% 전면 서비스/업무 중단이 아닌 부분 가능 상태가 되고, 클라우드의 장점으로 신속히 증설해서 50%가 80%, 90%가 되게 하는 것이므로, 추가 비용의 부담이 있는 것이 아니며, 또한 장애는 재난과 다르게 발생 가능성이 항상 존재하므로 꼭 필요한 고려 사항입니다.

이를 다른 표현으로는 서비스 이중화라고 하겠습니다​​. 네이버/라인과 같은 대형 온라인 서비스들, 그리고 대형 게임 서비스들은 이미 서비스 이중화의 개념을 가지고 이부분에 더욱 집중하고 있습니다. 많은 기업이 재해복구(DR)와 서비스 이중화의 개념을 혼동하는 경우가 있습니다. 재해복구 DR 시스템을 구축하는 것도 중요하지만, 더 중요한 것은 서비스 가용성을 위한 서비스 이중화입니다. 많은 기업이 DR이라는 용어에 집착하면서 핵심을 놓치고 있는 것은 아닐까 생각됩니다.

[ 클라우드 시대, 재난 방지 대책의 새로운 관점 ]

4. 클라우드 서비스 제공 업체들이 제안하는 재난 방지 대책은 무엇인가요?

이동인 CEO @WhaTap

“IBM에서는 스마트클라우드 매니지드 백업 서비스 솔루션 제공”

재해복구 시스템은 전통적으로 엔터프라이즈 기업들을 위한 시장이었습니다. 중소기업들은 비용 문제로 재해복구 시스템을 도입하지 못했습니다. 최근 클라우드 서비스 제공업체들이 중소기업을 위한 재해복구 시스템에 관심을 보이는 상황입니다. IBM에서는 스마트클라우드 매니지드 백업 서비스와 같은 솔루션을 제공하고 있습니다.

정창훈 CTO @당근마켓

“AWS에서는 언제든지 실패할 수 있다는 가정 아래 AZ 제공하거나 개발자가 직접 재해복구를 하도록 제반 시스템 제공”

아마존 CTO Werner Vogels는 “모든 것은 항상 실패(Everything fails, all the time)한다.”고 이야기했습니다.  이런 기조에 따라 하나의 IDC에 해당하는 AZ는 언제든지 실패할 수 있다고 가정되어 있어서 DB 같은 경우 간단한 옵션만 켜면 추가 비용을 내면서 하나의 AZ에 장애가 발생하더라도 몇 분 이내에 자동으로 다른 AZ에서 복구됩니다. DB처럼 자동으로 아마존이 해주는 부분도 있지만, 개발자들이 직접 해야 하는 부분도 있습니다. 웹 서버를 다른 지역에 이중화한다거나 하는 것들은 직접 해야 합니다.

클라우드 서비스들은 DB 같은 주요 서비스는 쉽게 재해복구를 지원하지만 일반 서버 같은 경우는 개발자들이 직접 재해복구를 구축하도록 하고 있습니다. 재해복구에 필요한 지역 간 네트워크 연결 등 제반 시스템을 제공합니다.

​김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“재난 방지 수준을 어떻게 보느냐에 따라 달라져”

재난 방지의 수준을 어떻게 보느냐에 따라 달라질 수 있습니다.

① 클라우드의 기능 장애, 인프라 장애 수준의 방지 대책을 의미한다면 클라우드 서비스 업체들은 일반적으로 멀티 존(혹은 가용 존)의 사용을 권고합니다. 하나의 서비스/업무를 양쪽 존에 분산해서 구축하는 구성을 제안합니다. 그리고 다양한 데이터 백업 상품들과 함께 관리형 DB 상품들을 제안합니다. 관리형 DB 상품은 DB 서버의 이중화 구성과 데이터 백업이 포함되어 제공되므로 이를 활용하면 고객이 스스로 구성하여야 하는 번거로움이 줄고, 미처 고려하지 못하는 실수를 방지하는 데 도움이 됩니다.

② 재해 복구 수준의 재난 방지를 위한 DR 시스템 구성으로 클라우드 서비스 업체에서 제안하는 유형은 크게 둘로 나눠볼 수 있습니다. 첫 번째는 클라우드를 DR 센터 혹은 Backup 센터로 사용하는 유형인데, ​이미 On-premise로 자체 IT 시스템을 가지고 있는 기업의 경우 (즉 아직 퍼블릭 클라우드를 사용하지 않는 경우)에 클라우드로의 전이(Transformation) 비용이 있기에 메인 시스템을 클라우드로 이전하기 전에, 자체 IT 시스템의 장애나 재난에 대비하기 위해 클라우드에 백업 데이터를 적재하는 방식입니다. 이는 기업의 현재 데이터 백업 솔루션과 클라우드의 여러 스토리지 상품들(예를 들어 오브젝트 스토리지, 아카이빙 스토리지 등)과 연동해서, 클라우드에 자동으로 데이터를 백업하게 됩니다.

두 번째 유형은 이미 클라우드를 사용하고 있거나 아니면 클라우드 이전 가능 (다른 표현으로 Cloud-Native) 구성을 가지고 있는 경우입니다. 클라우드를 이미 사용하고 있는 경우는 멀티 존 구성과 멀티 클라우드 전략을 제안하게 되며, Cloud Native 구성의 경우는 서비스/업무 시스템의 일정 비율을 클라우드에서 구동하도록 하는 것입니다.​

5. 기업 차원에서 할 수 있는 백업 전략들에는 어떤 것들이 있나요?

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“일반적인 DR과 서비스 가용성 혹은 연속성은 달라, 독립적으로 분산할 수 있는 멀티 클라우드 추천”

재해복구(Disaster Recovery)와 서비스 가용성(Service Availability) 혹은 연속성(Service Continuity)는 조금 다른 측면이 있습니다.

DR은 자연재해나 화재, 지진 등의 물리적 재해로 인해 IDC가 가동 불능이 되었을 때를 대비하는 것을 의미하고, 그 준비 수준에 따라 Hot DR(최상위 수준, 재해 발생 시 몇 분 내 곧바로 다른 IDC에서 서비스/업무 재개), Warm DR(중간 수준, 재해 발생 시 수 시간에서 수일 이후 서비스/업무 재개), Cold DR(낮은 수준, 데이터가 안전하게 백업되어 있어서, 신규로 IT 자원을 갖춘다면 언젠가는 서비스/업무가 재개될 수 있는 수준) 이 있습니다. 이런 개념의 DR은 금융 시스템이나 사회 안전 시스템, 공공성이 짙은 시스템들의 경우 필수적으로 갖추어야 하는 요건입니다.

서비스/업무의 가용성 혹은 연속성은, 재해(disaster)가 아닌 장애(fault) 수준에서도 서비스/업무 제공이 가능한지에 대한 관점으로, 이중화 혹은 고가용성(High Availability) 구성 등이 해당하며, IDC 수준의 장애에 대비하기 위해서는 멀티 IDC 혹은 멀티 존을 사용하게 되고, 클라우드 관점에서는 멀티 클라우드를 고려하게 됩니다. 이는 달걀을 한 바구니에 담지 말고 분산하라는 것과 같은 의미로, 예를 들어 서비스/업무 시스템을 2개의 클라우드에 50:50으로 분산시켜 놓았다면, 한 클라우드의 전면 장애에서도 최소한 50%의 서비스 가용성과 업무의 연속성을 보장하는 것입니다.

그리고 다른 두 개의 클라우드 업체를 사용하는 멀티 클라우드 전략과 한 클라우드 업체 내에서 멀티 존 혹은 멀티 리전을 이용하는 것과는 어떤 차이가 있을지에 대한 설명이 필요합니다. 멀티 존/리전을 사용하는 것도 2개의 IDC에 서비스/업무 시스템을 분산시켜 놓는 것이기 때문에 한 존/리전의 클라우드 인프라 장애의 경우에도 다른 존/리전에서 서비스/업무가 연속성을 가지고 제공될 수 있습니다. 하지만 이번 AWS 장애와 같이 운영상의 장애의 경우에는 동시에 양쪽 존, 혹은 여러 리전에 걸쳐서 장애가 발생할 가능성도 있습니다. 그러므로 독립적인 운영 체계로 분리된 복수 클라우드 사업자의 서비스를 사용하는 것, 즉 멀티 클라우드를 사용하는 것이 추가적인 고려 대상이 됩니다.

이동인 CEO @WhaTap

“시간을 기준으로 백업 전략을 결정하고 그에 따라 백업양을 결정, 백업 전략 전문 기업의 컨설팅을 받아 진행 ”

백업 전략은 시간을 기준으로 세워볼 수 있습니다. 실시간으로 진행할지 12시간, 24시간 또는 일주일 단위의 백업 전략이 있을 수 있습니다. 어떤 전략을 쓰냐에 따라 전체 시스템 백업을 할지 변경분 백업을 할지 결정하게 됩니다. 이런 전략에 대한 부분은 백업 전략을 전문적으로 제공하는 기업의 컨설팅을 받아서 진행하는 것이 일반적입니다.

정창훈 CTO @당근마켓

“주어진 비용과 서비스 상황에 맞춰 백업 수준을 정한 뒤, 알맞은 백업 전략 선택”

장애 발생 시 우리가 감당할 수 있는 수준을 정하고 그에 따른 대책을 상황에 맞게 정해야 합니다. 백업이나 장애복구의 경우 완벽하게 하려고 하다 보면 끝이 없는데요. 주어진 비용과 서비스 상황에 맞춰서 어느 정도 까지 할지 결정해야합니다.

어느정도까지 서비스를 유지할지 정해지면 그다음으로 알맞은 백업 전략을 찾으면 됩니다. 하나의 클라우드에서 여러 지역으로 분산하거나 여러 개의 클라우드 서비스를 섞어서 사용하거나 IDC를 동시에 운영하는 하이브리드 클라우드 방식도 있습니다.

신현묵 CTO @GooDoc

“기업마다 내부 가이드 라인이 정해져 있는데, 백업 리전을 많이 사용”

중요 디지털 자산들을 관리하기 위한 백업 절차들에 대해서는 각각 가이드라인들을 기준으로 많이들 사용합니다. 백업 리전도 많이 사용합니다.

[ 당장 실행할 수 있는 백업 전략 구축 노하우 ]

6. 결국 하나의 사본을 추가로 운영하는 일인데, 비용은 평균적으로 얼마나 더 들까요?

정창훈 CTO @당근마켓

“복잡해지는 아키텍처에 따른 개발 속도, IDC 운영 등 추가적인 기회비용이 계속 발생할 수 있기 때문에 3배 혹은 5배가 될 수도 있어”

단순히 사본을 하나 추가로 운영한다고 해서 비용이 2배가 되는것은 아닙니다. 비용이 3배 혹은 5배가 될 수도 있습니다. 단순히 하드웨어나 서비스 비용만 생각하는 것보다 서비스의 개발 속도에 따른 기회비용 역시 고려해야 합니다. 장애 대응이나 백업에 대한 고려를 하다 보면 아키텍쳐가 복잡해지고 이에 따른 개발 속도가 느려질 수 있는 부분도 있습니다. 클라우드와 함께 IDC를 직접 운영하거나 임대하기로 결정했다면 단순히 사본 하나가 아니라 IDC 운영에 대한 제반 비용도 추가됩니다.

신현묵 CTO @GooDoc

“단순 데이터 백업이라면 큰 비용이 들지 않지만, 실 운영이 가능한 서비스라면…. 부분적으로 백업하는 경우도 있지만 효과가 좋은 편은 아니기 때문에 잘 선택하지 않아”

사본의 개념이 단순 데이터의 형태라면 큰 비용이 들어가는 것은 아닙니다. 하지만, 실 운영 가능한 서비스의 형태라면 동일한 인스턴스 형태로 구성합니다. 부분적으로 RDS와 같이 데이터베이스를 AWS의 데이터를 저장하고, 인스턴스 분리하고 LB로 구현되는 정책들도 많이 사용합니다. 다만, 이런 서비스 역시 이번의 서울 리전에서의 이슈를 대응하기에는 불가능하기 때문에, 멀티 리전을 구사하는데 비용은 대부분 잘 선택하지 못합니다.

이동인 CEO @WhaTap

“시스템 개발부터 운영까지 2배 이상의 비용이 들지만, 일주일 단위로 백업을 진행한다면 비용 줄일 수 있어”

장애 발생 시 실시간으로 전환 가능한 서비스를 운영하기 위한 전략을 가지고 있다면 2배 이상의 비용이 발생합니다. 데이터 센터 비용도 올라가지만, 설계 복잡도가 높아지면서 시스템 개발에서 운영까지 비용이 올라가게 됩니다. 다만 일주일 단위의 백업을 진행한다면 비용은 매우 줄어들 것입니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“기존 물리적인 DR 개념이라면 비용은 2배 이상, 하지만 클라우드만의 특성을 살리면 전혀 다른 비용으로 접근 가능”

앞서 언급한 것처럼 DR 개념으로 가면 하나의 사본을 추가로 운영하거나 미리 준비해 놓는 것이 되므로 비용이 2배 이상이 됩니다. 그래서 많은 기업이 DR 센터 혹은 백업 센터를 구축하면서 인프라 규모를 축소하여 최소한의 인프라만, 예를 들어 50% 정도만 DR센터에 구축하거나, 아니면 Cold DR 개념으로 데이터만 백업해 놓습니다.

그러나 클라우드의 특성을 잘 살리면 전혀 다른 관점으로 바라볼 수 있습니다. DR이 아닌 서비스 이중화나 서비스 가용성, 서비스 연속성의 관점에서 클라우드의 빠른 증설 및 확장 가능이라는 특성을 살리는 것입니다. 예를 들어 현재 A 클라우드의 1개 존에 서비스/업무 시스템 전체를 구축하여 사용하고 있다면, 이를 두 개의 존에 분산 배치할 수 있습니다. 클라우드에서는 하나의 로드 밸런서로 2개의 존을 커버할 수 있으므로 서비스 사용자 입장에서는 동일합니다. 예를 들어 10대의 웹서버를 운영하는 서비스였다면 5대 5대씩 두 개의 존에 나누어 놓지만, 전면에는 하나의 로드밸런서를 이용해서 10대의 웹 서버를 하나의 접속점 (ex. www.naver.com)으로 운영할 수 있습니다. 만약에 한쪽 존에 장애가 발생해서 5개대의 웹 서버가 서비스를 할 수 없는 상황이 된다면, 수 분 만에 서버 증설을 할 수 있다는 클라우드의 장점이자 특징을 활용하여 5대의 웹서버를 10대로 늘리는 것은 수 분 만에 가능해 질 것입니다. 혹은 아예 자동으로 늘어나도록 하는 ​Auto Scaling이라는 클라우드만의 기능을 적용할 수도 있습니다. 따라서 고객 관점에서는 항상 10대의 웹서버만 운영하는 것이므로, 추가 비용이 발생하지 않으면서도 장애에 대비할 수 있게 됩니다.

결론적으로 항상 준비되어 있고 빠르게 증설할 수 있으며 사용한 만큼만 비용을 지불한다는 클라우드의 특성이 기존의 비용이 2배가 된다는 DR의 관념을 바꿔 놨다고 할 수 있습니다.​

7. 새로 백업 리전/클라우드를 구축하려면 기간은 얼마나 걸릴까요?

신현묵 CTO @GooDoc

“규모와 복잡도 차이로 일정하지는 않지만, 큰 시간이 걸리지는 않아”

보통은 일반적인 배포 정책에서 백업 리전과 멀티 리전을 동일하게 구성하여 사용하는 경우가 대부분입니다. 이번 서울 리전 이슈때문에 많은 업체들이 멀티 리전 정책을 취하면서, 분석하고 구성을 완료하기까지 큰 시간이 투여되지는 않습니다. 다만, 이 기간 역시 규모와 복잡도의 차이 때문에 일정하지는 않습니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“멀티 클라우드 구축은 ‘즉시’! 기존 물리적인 DR, 백업 센터를 준비하고 구축하는 데에 드는 시간과 확연히 달라”

앞서 이야기한 관점에서 멀티 클라우드 전략을 실현할 때 소요되는 구축 시간은 ‘즉시’라고 할 수 있습니다. 물론 서비스/업무 애플리케이션의 구조 등을 미리 잘 파악하고 있어야 합니다만, 기존 물리 구성으로 DR 센터 혹은 백업 센터를 구축하기 위해 준비하고 구축하는데 드는 소요 시간과는 확연히 다르다고 할 수 있습니다.

정창훈 CTO @당근마켓

“서비스 상황에 따라 하루에서 1년까지 천차만별”

서비스 상황마다 달라서 대략 얼마 정도 걸릴 것이라고 이야기 하기 어렵습니다. 어떤 회사는 하루 만에도 할 수 있고 다른 회사는 1년이 걸릴 수도 있습니다. 어떤 경우에는 클라우드 서비스에서 제공하는 유일한 기능으로 인해 전체 서비스를 백업하지 못하고 일부만 대응해야 할 수 있습니다.

8. 구체적인 운영 방법이 궁금합니다. 백업 리전이나 클라우드 운영 시 어떤 장단점이 있고, 운영 노하우가 있다면 무엇인가요?

신현묵 CTO @GooDoc

“백업 리전을 사용하는 경우, 개발-스테이징-리얼 서비스 3단계에서는 스테이징, 리얼 서비스 단계를 다른 리전으로 구성하는 것을 추천”

기본적으로 백업 리전을 운영하고 있으며, 내부적으로 멀티 인스턴스에 LB를 혼용하는 일반적인 구성요소를 사용합니다. 개발-스테이징-리얼 서비스의 3단계 정책으로 긴급 상황에 스테이징 서비스를 리얼로 대신할 수 있게 하는 단계를 사용합니다. 일반적인 상황에서는 테스트 목적으로 사용하고 있는 구조입니다. 그리고, 이 구조에서 스테이징과 리얼 서비스를 다른 리전으로 구성하는 것이 가장 좋다고 생각합니다.

정창훈 CTO @당근마켓

“백업 리전이나 클라우드 운영으로 모두 해결되는 것이 아니기 때문에, 어느 정도까지 재해복구 시스템을 구축할지 정하는 것이 중요”

간단하게 시작할 수 있는 것은 아마존의 경우 Multi AZ 기능을 제공하는 서비스는 Multi AZ 기능을 활성화 하는것이 기본입니다. 그다음으로 DB의 백업 데이터를 주기적으로 다른 리전이나 다른 클라우드로 복제 한다거나 서버를 어디서라도 바로 실행할 수 있도록 서버 설치에 대한 방법을 코드로 관리하는 Packer 같은 툴을 이용하거나 인프라 시스템을 코드로 관리하는 Terraform 툴을 사용하는 것도 좋습니다.

백업 리전이나 백업 클라우드를 사용한다고 모두 해결되는 것은 아닙니다. 백업 리전을 운영했는데 운이 없게도 백업 리전과 현재 리전이 동시에 장애가 발생 할 수도 있고 백업 클라우드를 운영했는데 서로 다른 클라우드 서비스 회사가 알고 보니 같은 IDC 건물에 있어서 같이 안 될 수도 있습니다. 이렇기 때문에 어느 선까지 재해복구 시스템을 구축할지 정하는 것이 중요합니다.

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

“전통적인 DR이나 백업 센터 개념에서 벗어나, 클라우드 특성을 활용한 ‘서비스 가용성’ 측면에서 장/단점 파악할 것”

전통적인 DR 센터, 백업 센터 구축과 운영의 관점으로 보지 않고, 클라우드 특성을 활용한 멀티 존, 멀티 클라우드로의 분산 환경 구축을 통한 서비스 연속성, 서비스 가용성의 관점으로 바라본다면 어떤 장단점이 있는지가 잘 드러날 것으로 생각됩니다. 장점뿐만 아니라 단점을 명확히 하고, 그 단점을 극복할 방안을 마련하는 것이 중요합니다.

멀티 클라우드 전략의 경우도 동일한 개념이 적용될 수 있습니다. A 클라우드가 장애가 났을 때 B 클라우드에서 빠르게 용량 증설을 통해 서비스/업무의 가용성을 유지할 수 있습니다. 더구나 On-prem (기업 자체 IDC에 비 클라우드) 형태의 기업이더라도 클라우드와 병행하는 하이브리드 구성을 한다면, On-prem 장애의 경우에 클라우드에서 재빠르게 증설하여 서비스를 지속할 수 있습니다.

멀티 클라우드 전략의 단점은, 클라우드 서비스 업체별로 100% 동일한 환경이 아니고 클라우드 상품 사용 방법이나 상품의 기술적 스펙 등에 차이가 있으며, 이러한 차이로 인해 100% 동일한 구성을 할 수 없다는 점입니다. 예를 들어 A 클라우드에서 서버를 생성하는 절차와 B 클라우드에서 서버를 생성하는 절차는 다를 것이고, A 클라우드에서 제공하는 상품/서비스의 종류와 기능들은 당연히 다른 클라우드와 차이가 있을 것입니다.

이러한 차이는 사용 기업 관점에서는 운영의 복잡성을 가져오게 되고, 나아가서는 시스템 운영 절차와 방법론의 차이에서 오는 무형의 운영 비용의 증가가 발생합니다. 또한 A 클라우드에서만 제공되는 특별한 상품/기능을 사용하고 있었다면, 멀티 클라우드 전략을 가져가는 데 걸림돌이 되면, 결국 1개의 클라우드 사업자에 Lock-in 되어 버리는 꼴이 됩니다.

그러므로 멀티 클라우드 전략을 가져가는 경우는 각 클라우드의 차이점을 충분히 이해하고, 또한 하나의 클라우드에 lock-in 되지 않도록 시스템 아키텍처에 신경을 써야 하면서, 정형화된 자체 운영 프로세스도 고려해야 합니다.

다행히도 이런 멀리 클라우드 전략을 택하는 사용자를 위한 다양한 멀티 클라우드 도구(툴)들이 존재하며, 이러한 소프트웨어 툴들을 사용하면 단점을 어느 정도 극복할 수 있습니다. 오픈 소스 도구 중에 가장 유명한 Packer나 Terraform 과 같은 소프트웨어 툴을 사용하면, A 클라우드, M 클라우드, N 클라우드와 상관없이 단일한 방식으로 즉 Packer와 Terraform의 사용법만으로 여러 클라우드에 서버를 생성하고 설정할 수 있습니다. NAVER CLOUD PLATFORM은 이러한 중립적인 오픈 소스 도구들을 지원함으로써 사용자들이 멀티 클라우드 전략을 쉽게 구현할 수 있도록 돕고 있습니다.

[ 클라우드 시대를 준비하는 실무자의 자세 ]

9. 클라우드 서비스는 피할 수 없는 거대한 흐름입니다. 클라우드 서비스 도입을 고민하는 실무 담당자가 꼭 고려해야 할 것이 있다면 무엇인가요?

이동인 CEO @WhaTap

“아마존의 독주에서 점차 다양해지고 있는 클라우드 시장! 기업의 서비스 특성에 맞는 클라우드를 선택할 수 있어”

비용과 안정성 그리고 비즈니스의 속도를 고민할 때 클라우드를 쓰지 않을 이유가 없습니다. 현재까지는 아마존의 독주였지만 최근 MS가 빠르게 성장하고 있습니다. 내년에는 오라클도 한국에 클라우드 리전을 오픈할 예정입니다. 한국의 클라우드 업체들도 특화된 서비스들을 만들어 가면서 빠르게 입지를 넓히고 있습니다. 이제 클라우드 시장에는 정말 다양한 선택지가 펼쳐지고 있습니다. 이제 실무 담당자는 가격뿐만이 아니라 기업의 서비스 특성에 맞는 클라우드를 선택해야 합니다.

정창훈 CTO @당근마켓

“서버에 대한 ‘관점의 전환’을 이해하는 것 필수 ”

클라우드 서비스가 보편화 되면서 서버를 바라보는 관점이 바뀌었습니다. 담당자는 이러한 관점의 전환을 이해 해야 합니다.

기존에는 서버를 운영하면서 하드웨어 사양을 미리 좋은 것들을 준비해야 했습니다. 메모리나 하드디스크를 업그레이드하려면 서버를 중지해야 했고 몇 시간이 걸리기도 하고 서비스가 동작하지 않기 때문에 항상 미리 준비하고 계획해야 했습니다. 트래픽이 늘어서 서버를 추가해야 하면 장비를 발주해서 구매하고 OS를 설치하는데 며칠이 걸립니다. 하지만 클라우드에서는 몇 분만에 완료되고 자동으로 모니터링해서 서버를 추가하는 것도 몇 분이면 됩니다.

클라우드 관점에서는 서버에 설치하다가 잘 안 되면 새로운 서버를 실행해서 처음부터 다시 시도하고 기존 서버는 과감하게 버립니다. 서버 하드웨어에 문제가 생기면 그것을 복구하려고 노력하기보다 그 서버는 버리고 새로운 서버를 실행합니다. 이제 서버는 쉽게 쓰고 버리는 개념으로 다가왔습니다.

이러한 관점의 전환을 이해하고 서버를 바라보는 담당자의 생각이 바뀌어야 클라우드 서비스를 제대로 활용할 수 있습니다. 클라우드에서도 기존에 운영하던 방식으로 접근한다면 클라우드 서비스가 주는 장점이 없다고 느낄 수 있습니다.

신현묵 CTO @GooDoc

“클라우드 또한 실 서버 운영과 동일하게 문제가 발생할 수 있어, 꾸준히 모니터링하면서 관리하는 자세 필요”

클라우드가 아니라, 실 서버로 운영을 한다고 하더라도, 문제는 계속 발생할 수 있습니다. 서비스는 중단될 수 있고, 예기치 못한 이슈로 문제를 일으키게 되는 것이 맞습니다. 언제나 죽을 수 있다는 상황을 꾸준하게 모니터링하면서 관리하는 자세가 가장 중요합니다.

10. 앞으로 계속 발전할 클라우드 서비스, 원활하게 운영하려면 어떤 태도를 가져야 할까요?

신현묵 CTO @GooDoc

“서비스는 곧 비즈니스 신뢰와 연결, 안정적인 상황을 위해 균형을 지키는 다소 보수적인 태도가 꼭 필요”

서비스 운영자는 매우 보수적으로 되는 것이 당연합니다. 서비스 중단은 비즈니스의 중단과 신뢰에 매우 큰 영향을 줄 수 있습니다. 보안과 안전성을 지키는 자세를 가지고, 비용이 허락되는 최대한의 리소스를 기업 내부에서 계산하고, 해당 기업의 비즈니스의 속도에 따른 적절한 환경을 구성해야 합니다. 비용은 한정적이고, 대응 자세는 그 역량에 따른 것이니까요. 보수적이고, 안정적인 상황을 위한 균형을 지키려는 태도를 꼭 가지도록 조언하고 싶습니다.

정창훈 CTO @당근마켓

“클라우드 서비스의 장단점을 파악하고, 적절하게 사용하기 위해서 끊임없이 공부하는 자세”

클라우드 서비스에 대해 방어적인 태도를 취하기보다 클라우드 서비스에서 얻을 수 있는 장점을 활용하는 것을 고민해야 합니다. 클라우드 서비스에 대해 계속 공부해서 클라우드 서비스의 장단점을 이해하고 적절하게 사용하는 것이 좋습니다.

*          *          *

 

‘클라우드 서비스’ 프로들과 인맥을 맺고, 새로운 비즈니스 기회를 만나보세요.

정창훈 CTO @당근마켓

신현묵 CTO @GooDoc

이동인 CEO @WhaTap

김세라 마케팅 수석 @네이버 비즈니스 플랫폼

※ [AskMe]는 개인적 경험을 바탕으로 진행된 인터뷰로, 특정 회사의 입장을 대변하는 글이 아님을 밝힙니다.

※ 본 콘텐츠에 대해 궁금한 점이 있으시면 startup@rocketpunch.com으로 연락주세요.