제가 AWS 도입에 대한 운을 뗐더니 “서비스 자체가 불안한게 클라우드인데…

제가 AWS 도입에 대한 운을 뗐더니
“서비스 자체가 불안한게 클라우드인데
클라우드에 올린 데이터가 AWS측 문제로 깨질 경우
또는 서비스 중단 사태가 발생했을 경우
AWS에서 책임을 진다면 사용 검토가 가능하겠다” 고 합니다.

종종 AWS가 사용자 과실 아닌데도 서비스 문제가 발생할 경우가 올라오던데
책임소재는 어떻게 되는지요?

22 thoughts on “제가 AWS 도입에 대한 운을 뗐더니 “서비스 자체가 불안한게 클라우드인데…

  1. 결국 데이터에 대한 책임은 사용자가 지는 건데, 그런 측면에서 보면 AWS가 더 낫죠. 고 가용성 구조, 네트워크 격리 추가적인 백업 장치들 모니터링 시스템….

  2. AWS 교육 받으러 가면, 그래서 저희가 AZ, region 등을 마련했구요. 이중화 하시고, DR 구성하시고, S3 등을 잘 활용하세요. 라고 친절히 말씀하십니다만, 이게 AWS 라서 그렇게 해야 하는게 아니라 인프라의 기본이지 말입니다?

  3. 그럴 경우엔 진행 안하시는게 좋습니다. 애초부터 클라우드에 맞게 수정할 생각이 없는 서비스는 클라우드로 전환하면 큰 어려움을 겪으실 겁니다. 클라우드(AWS 등)는 운영자만 안다고 사용할 수 있는 인프라가 아니기 때문입니다.

  4. 시스템이 뭔지 모르는 분같네요. AWS 가 됐던,물리 서버가 되었던 장애발생을 대비한 아키텍쳐 설계가 해답인데 ‘누가 책임질거냐?’ 는 질문을 하고 있으니…. AWS 라고 서비스 문제 안생기는거 아니겠지만 그걸 회피할수 있는 설계를 하는게 기본인데…

  5. 최종 의사 결정권한이 있으신 분을 모시고 AWS 세미나 한번 같이 참석 하시는 것도 좋겠네요.
    다양한 도입 사례를 보고 직접 느끼고 판단하시는게 좋을 듯 합니다.

  6. 글쎄요.. 전 3년간 미국, 유럽에 EC2 를 사용했는데 단 한차례도 장애가 없었네요. 국내 IDC를 12년간 쓰면서 데이타 유실은 없었지만 네트웍 장애, 해외 라우팅 장애 등이 1년에 두어번씩 발생해서 지난주 서울이 오픈한 후 국내 마스터서버들마저 AWS로 이전작업을 완료하고 오랫동안 써온 국내 IDC와 오늘 이별했네요. 장애가 발생한다고 해도 EC2 구조상 장애대처, 복구가 훨씬 용이할 것으로 판단됩니다.

  7. 심정을 이해못하는 바는 아니라는 생각이 듭니다. 서울리전이든 어디든 결국 저 멀리 떨어진 곳 잘 모르는 사람들에게 서버를 맡긴다는 것 자체가 거부감이 있을 수 있고, 그래서 보수적인 갑님들은 직접 방문 되고 물리서버 있고 유선상담 되는 담당자 붙어있는 데이터센터를 더 선호할수 있는거고요.
    -_-)y=~~~~

  8. 그래서 그 데이터를 직접 소유하는 방법이 더 안전한가에 대해 생각해 보시도록 하면 어떨까 싶습니다. 또한, 설득에 있어 좋은 포인트는 다른 회사 사례들이죠. 동일 산업군에서 유명한 AWS 고객을 예로 들어보시면 어떨까 합니다. 그들의 AWS 사용 의사결정에 동일한 고민이 없었던 것은 아니겠죠. 또한, 그들이 데이터 유실 걱정이 없어서 AWS 를 사용하는 것은 아닐겁니다. 아울러, 기술적으로도 많은 백업 포인트를 제공하고 있기 때문에 구성하기 나름이기도 하구요. 수 테라바이트만 넘어도 디스크 관리는 정말 큰일이죠…

  9. 보수적인 사고방식에서 나오는 책임을 전가하는 질문법이네요. “니가 책임 질거야?” 아마존에서도 SLA를 제공하고 있습니다. 물론 이것이 서비스 퀄리티를 보장하는 것이 아닙니다. 그래서 중요한 것이 어떻게 아키텍처 구성을 할 것인가가 중요한 부분입니다. 보통 대게 Cloud로 이전을 제안할때, 메인 서비스나 시스템을 이전하는 것을 권고하지 않습니다. 신규 서비스나, Test 환경, 실시간성이 적은 시스템 등.. 먼저 진행해서 AWS가 안전하다라는 사용자 경험을 통해서 서서히 옴겨가라고 말씀 드리고 싶습니다. 바로 실행 하려면 오히려 반발이 있을 수 있습니다.

  10. 레거시 시스템 이건 클라우드건 하드웨어 장애가 발새할 가능성은 항상 있습니다. “그래서 서비스 자체가 불안하다” 는 인식에 대해 100% 아니라고는 말 못할것 같습니다. 그러나 오히려 그렇기 때문에 클라우드로 가야만 합니다. 기존의 레거시 시스템에서 일어날 수 있는 여러 장애를 회피할 수 있는 아키텍처를 구성하는것이 가능하기 때문입니다. 결국 클라우드에서 솔루션 아키텍처를 설계/구축할 때 단일 시스템이 다운되도 전체 서비스는 살아있는 아키텍처를 구성하시면 됩니다. 그리고 설득하는 제일 좋은 방법은 일단 양쪽의 아키텍처를 그림으로 그려서 보여주세요.. 그리고 일어날 수 있는 장애요소를 따져보시고 회피할 수 있는 방법을 보여주세요.. 그러면 레거시가 더 불안한것을 인식하실 수 있을겁니다..

  11. 비용관점에서 IDC를 두고 서버/네트워크/보안장비를 운영하는 경우와 클라우드서비스를 이용 경우 비용분석을 해보세요

    IDC운영시 회선비,상면비, 전기사용료 장비 유지보수비와 인력운영등이 고정적으로 발생할것이고
    클라우드는 서비스 이용료와 운영비정도?가 들겠네요

    업무 특성을 고려해서 어떻게 운영하는게 좋을지
    현재까지 IDC운영하면서 장애는 몇번정도 발생했고
    이로인한 비즈니스 영향도는 어느정도 였는지
    클라우드로 전환시 위의 영향이 얼마나 줄어들지
    구체화 수치화해서 보고하면 되지 않을까요?

  12. 원론적인 이야기가 될수 있지만 코로케이션, CDN, 호스팅, IDC, 보안관제, 클라우드 IaaS, 기타 as A service방식의 매니지드 방식의 일련의 서비스들은 고객과의 계약시 계약서와 더불어 SLA(Service Level Agreement)를 같이 조정해서 계약서에 첨부합니다.
    물론 SLA에 각 서비스별로 최소한 품질 보장의 기준이 명시되어 있고, 고객이 서비스제공자가 제시하는 기본적인 기준을 만족하지 못했을때, 추가적으로 고객이 장애레벨, 대응수준, 복구시간, 패널티 및 리펀딩 조건, 등을 구체적으로 리스트업하여 제시할수 있으며 또는 서비스프로바이더에게 요구할수 있습니다 .
    물론 서비스프로바이더는 이를 수용할수도 있고 안할수도 있습니다.
    이 역시 지불하는 과금에 일부 영향이 미칠수도 있습니다.
    이는 계약기간, 계약볼륨( 약정조건(Commitment), 추가사용량(Overage)에 따라 대해 영향을 미칩니다.
    따라서, 계약전 충분히 서비스 프로바이더와 협의하여 계약서에 명시할수 있기때문에 사후 발생한 어떤 사건에 대해서는 계약된 조건대로 법률에 근거하여 대응하시면 되거나, 조치를 취하면 되기 때문에 판단은 고객이 하면 되는것이지요. 어떤 서비스 프로바이더의 서비스를 사용할건지, 만일 그런 협의가 가능하지 않다면 가능한 서비스 프로바이더를 찾으면 됩니다.
    물론, face to face 미팅이 없는 상태로 사용계약을 해야 하는 경우나, 혹은 계약을 위한 Contact Point가 해외에 있는 경우는 아무래도 커뮤니케이션이나 사후처리과정에 애로사항이 발생할수 있겠지요?

답글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다.