최신 리포트 다운로드 지금 바로 문의하기
최신 리포트 다운로드 지금 바로 문의하기
Author

Miyeon. Jo

BigQuery BI Engine을 활용한 Query 가속화

구글 인사이트
by Miyeon. Jo
목차
  1. 개요
  2. BI Engine의 장점
  3. BI Engine 사용 시 제약 사항
  4. BI Engine 비용
  5. BI Engine 설정 방법
1. 개요

BigQuery BI Engine이란?
BigQuery 내에서 복잡한 데이터 세트를 대화식으로 탐색할 수 있도록 하는 빠른 인메모리 분석 서비스입니다.

  • BI Engine을 사용하면 1초 미만의 쿼리 응답 시간으로 BigQuery에 저장된 데이터를 분석하는 동시에 컴퓨팅 비용을 절감할 수 있습니다.
  • BI Engine은 Looker, Data Studio, Connected Sheets 또는 BigQuery에 연결하는 타사 도구를 비롯한 모든 BI 도구를 기본적으로 통합합니다.
  • BI Engine 용량은 필요에 따라 늘릴 수도 있습니다.
2. BI Engine의 장점
1) 속도

유용한 정보를 도출하는 데 걸리는 시간을 단축하여 성과를 비즈니스 속도에 맞출 수 있습니다.

  • 로드 시간을 최소화하고 BigQuery에 저장된 데이터의 지능형 캐싱을 개선하여 1초 미만의 쿼리 응답 시간을 제공합니다.
  • BigQuery 스트리밍과 통합하면 쓰기 속도 또는 데이터의 최신 상태를 유지하면서 스트리밍 데이터에 대한 실시간 데이터 분석을 수행할 수 있습니다.
2) 간소화된 아키텍처

복잡한 데이터 파이프라인 또는 서버를 관리하지 않고 빠르게 시작할 수 있습니다.

  • BigQuery 내에서 인플레이스 분석을 수행하기 때문에, 데이터를 이동하거나 복잡한 데이터 변환 파이프라인을 만들 필요가 없습니다.
3) 사용 편의성

BigQuery와 동일한 인터페이스를 사용하기 때문에 별다른 BI 도구 없이 BigQuery의 원활한 환경에서 사용 가능합니다.

  • 쿼리가 BI Engine으로 가속화할 수 없는 경우 실패하지 않으며 일반 쿼리로 실행됩니다.
4) 스마트 미세 조정

구성 설정이 거의 없으며, 대시보드의 최적 성능과 로드 시간을 보장합니다.

  • BI Engine의 인메모리 스토리지, BigQuery 쿼리 캐시, BigQuery 스토리지 간에 데이터를 이동하여 쿼리를 자동으로 조정합니다.
  • BigQuery 관리자는 Google Cloud 콘솔을 사용하여 BI Engine 메모리 용량을 쉽게 추가하고 삭제할 수 있습니다.
3. BI Engine 사용 시 제약 사항
1) 한도

다음과 같은 한도가 적용됩니다.

한도기본값
위치당 프로젝트당 최대 예약 크기(SQL 인터페이스)250GB
위치당 프로젝트당 최대 예약 크기(데이터 스튜디오)100GB
테이블당 최대 데이터 모델 크기(데이터 스튜디오)10GB
테이블당 최대 파티션 수(데이터 스튜디오)500 파티션
쿼리당 최대 행 수(데이터 스튜디오)1억 5천만
  • BI Engine 용량보다 큰 쿼리를 실행하면 BI Engine 자체 조정 기능이 BigQuery 슬롯을 사용하여 쿼리를 실행합니다.
  • 쿼리를 실행하는 데 BigQuery 슬롯이 사용되면 BigQuery 주문형 쿼리 가격 책정에 따라 쿼리 작업의 요금이 청구됩니다.
4. BI Engine 비용

BigQuery BI Engine 사용 요금은 프로젝트용으로 구매한 BI Engine 용량에 따라 부과되며, BI Engine 용량을 구매하는 방법은 주문형 용량 구매, 번들 정액제 총 2가지 입니다.

1) 주문형 용량
  • 데이터 처리량(GB)에 따른 주문형 가격
  • 메모리 용량(GB)당 $0.0499 이 발생합니다. (서울 기준)
2) 번들 정액제
  • 쿼리에 대한 월정액 요금제
  • 연간 약정으로 BigQuery 정액제에 등록하면 추가 비용 없이 동일한 월정액 요금으로 BigQuery BI Engine 용량을 추가로 받을 수 있음.
    (결제 보고서에서는 무료 용량도 일반적인 비용처럼 표시되지만 ‘지출 기반 할인’으로 100% 할인됨.)
  • 추가 비용 없이 받을 수 있는 최대 BI Engine 용량은 2,000개의 BigQuery 슬롯 구매 시 100GB. 추가 BigQuery 슬롯이 있고 BI Engine 용량이 100GB 이상 필요한 경우 주문형 가격으로 용량을 추가 구매할 수 있음.

BI Engine은 Google 데이터 스튜디오 사용자에게 최대 1GB의 무료 용량을 제공하며, 예약 없이도 모든 데이터 스튜디오 사용자가 사용할 수 있습니다.
(무료 등급에 대한 SLO 보증은 없기 때문에 프로덕션 워크로드를 실행하는 데 사용하면 안 됩니다.)

5. BI Engine 설정 방법
1) GCP Console > BigQuery > BI Engine > Create Reservation

(BigQuery Reservation API를 사용 설정하라는 메시지가 표시되면 사용 설정 클릭.)

2) Project, Location, Capacity 선택 > Next
  • Location : Query 실행을 위한 Data Set 위치와 동일한 location 선택
  • GB of Capacity : 예약하려는 메모리 용량에 맞게 조정 (최소1GB, 최대 250GB)
3) (선택) Preferred Tables > NEXT
  • BI Engine이 가속화해야 하는 테이블을 선택.
    (미 선택 시 프로젝트 내의 모든 쿼리가 BI 엔진을 사용. )
4) Create

출처

원더피플

by Miyeon. Jo

원더피플

Company Overview

원더피플은 세상을 바꿀 위대한 게임을 만드는 게임 개발사입니다. ‘Mega Hit Poker’ 등 다양한 모바일, PC, 온라인 게임을 제작해 서비스하며 안정적인 성장을 이어가고 있습니다. 현재는 배틀로얄 게임 ‘슈퍼피플’의 오픈을 앞두고 있습니다. ‘슈퍼피플’은 한국 뿐 아니라 북미, 유럽, 일본 등 세계 각지에 서비스되는 글로벌 게임으로 베타 테스트 단계부터 많은 관심과 호응을 받고 있습니다.

Challenge

[인프라팀]원더피플 인프라팀은 게임 개발과 테스트에 필요한 전반적인 인프라 관리와 데브옵스를 지원하고 있습니다. 기존에는 20대~30대 규모의 물리 서버를 활용해 테스트 환경을 구성했었습니다. 하지만 처리해야 할 데이터가 점점 늘어나면서 서버 관리와 장애 대응을 하는 데 많은 시간이 소요되기 시작했습니다. 이를 해결하기 위해서는 물리 서버를 늘리는 것뿐 아니라 네트워크 측면에서도 대응이 필요했지만, 직접 필요한 네트워크를 구축한다면 천문학적 비용이 예상되었습니다. 이에 따라 인프라를 합리적인 비용으로 더욱 효율적으로 관리하기 위해 클라우드 도입을 결정했습니다.

[데이터랩팀]원더피플 데이터랩팀은 유저 경험 개선과 데이터 분석을 위해 로그 데이터를 전문적으로 수집하고 적재・분석하는 업무를 위해 신설된 팀입니다. 하지만 기존의 온프레미스 환경에서는 대용량 로그 데이터를 수입하고 처리하는 데 비용도 많이 들고 매우 비효율적이었습니다. 그래서 게임에서 생성되는 모든 로그 데이터들을 안정적으로 관리하기 위해 본격적인 데이터 파이프라인 구축과 클라우드 도입을 결정했습니다.

Solution

“온프레미스 환경에서 길게는 1시간 이상 걸리던 데이터 조회 시간이 BigQuery 도입 후 60배 빨라졌습니다. 현재는 동일한 쿼리로 데이터 조회 시 평균 1분이면 처리가 가능합니다.”

– 루닛 캔서스크리닝그룹 플랫폼팀 황석환 리드님

여러 클라우드 플랫폼들을 비교하기 위한 PoC를 진행하였고 사용성과 비용, 데이터 활용 측면에서 가장 쉽고 합리적인 Google Cloud를 선택했습니다. 현재 원더피플에서는 Compute Engine, Cloud Load Balancing, BigQuery 등 Google Cloud의 다양한 서비스와 Google Workspace를 함께 사용 중입니다.

[인프라팀]사내 테스트 서버 등 내부 인프라를 Google Cloud로 순차적으로 이전하고 있습니다. Google Cloud 도입 후 서버 관리와 장애 대응에 들어가는 시간이 줄어들었고, 근무 외 시간에 발생하는 이슈에 대해서도 원격으로 관리할 수 있는 부분이 생겨 훨씬 빠른 대응이 가능합니다. 기존의 서버가 지니던 물리적 제약이 사라져 더 효율적으로 인프라를 관리하고 있습니다.

Google Cloud의 가장 큰 장점은 UI가 사용자 친화적으로 구성되어 있고, 개발자 문서도 체계적으로 구성되어 있어 사용하기 정말 쉽다는 점입니다. 클라우드가 익숙하지 않더라도 빠르게 적응할 수 있어 직원들의 만족도가 매우 높습니다. 또한 Google Workspace와 바로 연동되어 클라우드 권한 설정이 매우 간편합니다. 클라우드용 계정을 따로 만들 필요 없이 Google Workspace 계정만 있으면 되기 때문에 사용자 관리나 프로젝트 담당자 확인 등이 훨씬 빠르고 수월합니다.

[데이터랩팀]BigQuery를 비롯한 Google Cloud의 다양한 기능들을 활용해 게임 내 로그들을 수집하고 적재하는 데이터 파이프라인을 구축했습니다. 기존 온프레미스 DB에서는 데이터를 조회할 때 길게는 1시간이 넘게 걸리는 경우도 있었는데, BigQuery 도입 후에는 데이터 조회 속도가 60배 빨라졌습니다. 현재는 동일한 쿼리로 데이터 조회 시 평균 1분이면 처리가 가능하고, 초당 300Mb의 로그 데이터 처리가 가능합니다.

Benefit

“클라우드 도입을 혼자서 고민하기 보다는 클라우드를 제대로 아는 파트너사, 베스핀글로벌과 함께 하시기를 추천합니다. 전반적인 인프라 비용도 줄이고 클라우드도 더 빠르게 적용할 수 있습니다.”

– 원더피플 인프라팀 장운영님

Market Overview

글로벌 게임 시장 규모는 2022년 2,000억 달러를 넘어설 것으로 예상되며, 전 세계 게임 인구는 32억 명으로 추산됩니다. 특히 한국은 대표적인 게임 강국 중 한 곳으로, 지난 해 게임 시장 매출 약 83억 달러를 창출하며 세계 시장 점유율 4위에 올랐습니다. 팬데믹 이후 게임 인구가 더 다양해지기도 했습니다. 60세 이상이 게임을 검색하는 횟수가 200% 증가했고, 직접 게임을 즐기지 않더라도 라이브 스트리밍 플랫폼을 통해 게임을 시청하는 사람도 늘어났습니다. (관련 기사)

 

이처럼 빠르게 성장하는 게임 산업의 원동력 중 하나는 바로 클라우드입니다. 365일 24시간 요구되는 높은 가용성과 게임 출시나 이벤트, 글로벌 진출 등에 필요한 큰 확장성은 클라우드에서 가능하기 때문입니다. 클라우드의 또 하나의 강점은 AI와 빅데이터 분석을 통해 대규모 데이터를 활용할 수 있다는 점입니다. 특히 게임 안에서도 사용자 경험이 중요해지는 요즘, 이를 분석하고 개선하기 위해서는 먼저 효율적인 데이터 관리에 대한 고민이 필요합니다.

 

글로벌 게임 회사 원더피플은 Google Cloud 도입을 통해 그 답을 찾았습니다. BigQuery를 활용해 데이터 파이프라인을 구축해 데이터 조회 속도를 60배 단축시켰고, 게임 안에서 생성되는 모든 로그 데이터들을 안정적으로 관리하고 있습니다. 그리고 이 과정에서 베스핀글로벌과의 파트너십을 통해 데이터 파이프라인 및 클라우드 인프라를 더욱 효율적으로 운영하고 있습니다. 앞으로도 이와 같은 데이터에 대한 투자를 기반으로 글로벌 시장에서 더욱 빠르게 성장해 나갈 원더피플의 행보가 기대됩니다.

구글 클라우드 문의하기

아이아이컴바인드

by Miyeon. Jo

아이아이컴바인드

Company Overview

아이아이컴바인드는 패션 아이웨어 브랜드 “젠틀몬스터”, 코스메틱 브랜드 “탬버린즈”, 디저트 브랜드 “누데이크”를 운영하는 기업입니다. 새롭고 혁신적인 경험을 선사해 MZ 세대를 중심으로 팬층을 확보 중이며, 특히 젠틀몬스터는 아시아를 비롯한 유럽, 미국에도 40여 개 이상의 직영점을 보유하는 등 글로벌 브랜드로 빠르게 성장하고 있습니다.

Challenge

아이아이컴바인드가 제공하는 모든 서비스는 AWS 클라우드 위에서 운영중입니다. 비즈니스가 빠르게 성장하고 운영하는 서비스 개수가 늘면서 클라우드 인프라를 고도화하고 더 효율적으로 관리해야 할 필요를 느꼈습니다.

 

특히 하나의 AWS 계정으로 여러 서비스를 운영할 때의 불편함을 해결해야 했습니다. 예를 들어, AWS는 계정 단위로만 비용 내역을 제공하기 때문에 전체 비용 외에 서비스 별 비용 정보는 확인이 어렵습니다. 하지만 클라우드 인프라를 효율적으로 관리하기 위해서는 각 서비스마다 어느 정도의 비용이 어떻게 사용되고 있는지 세부적인 데이터가 필요했습니다.

Solution

1) 클라우드 인프라 매니지드 서비스 도입
베스핀글로벌의 클라우드 인프라 매니지드 서비스(IMS)를 통해 AWS 인프라를 운영하기로 결정했습니다. 베스핀글로벌은 가장 먼저 기존 인프라의 현황 파악과 아키텍처 분석, 리스크 분석 등 종합 분석을 실시했습니다. 그 과정에서 기존의 AWS Backup 정책이 제대로 동작하고 있지 않음을 발견했고, 이를 더욱 세분화된 정책으로 수정하여 기본 정책을 보완・적용했습니다. 기존 아키텍처의 로드 밸런서 구성 또한 용도에 맞는 ELB*로 변경하고 규칙을 정립해 사용자 유입량이 많은 이벤트를 진행할 때에도 이슈없이 고가용성을 확보할 수 있도록 했습니다. 이 밖에 젠틀몬스터의 서비스 확장으로 싱가포르 등 해외용 인프라 증설이 필요했는데, 이 부분도 베스핀을 통해 안정적으로 구현했을 뿐 아니라 Auto-Spot 기능을 활용해 비용 절감까지 챙길 수 있었습니다. * ELB: Elastic Load Balancer
2) 클라우드 운영 관리 자동화 솔루션 옵스나우 도입

클라우드 파트너로서 베스핀글로벌을 선택한 가장 큰 이유는 바로 옵스나우(OpsNow)입니다. 옵스나우에서는 태그(Tag)를 기반으로 서비스 그룹을 만들어 관리할 수 있는데요. 실제로 아이아이컴바인드는 웹사이트, e커머스, 결제 등 서비스 로직마다 태그를 달아 하나의 계정 안에서도 세부적인 이용 현황과 비용을 바로바로 확인하고 있습니다. 또한 생성되어 있지만 사용되지 않는 자원이나, 조금 더 효율적으로 사용할 수 있는 자원 등도 파악해 즉시 비용을 줄이거나 최적화했습니다.

Benefit

“옵스나우의 활용성과 확장성이 베스핀글로벌을 클라우드 파트너로 선택한 결정적 이유입니다. 베스핀글로벌과의 협업을 통해 더욱 안정적인 서비스 운영과 지속적인 비용 절감 효과를 기대하고 있습니다.”

– 아이아이컴바인드 백엔드 팀장

베스핀글로벌의 IMS와 옵스나우를 통해 클라우드 인프라를 더 체계적으로 관리하고, 자원에 대한 Right Sizing 및 비용 최적화를 진행할 수 있었습니다. 앞으로는 더욱 안정적인 서비스와 지속적인 비용 절감 효과를 기대합니다. 보통 클라우드 인프라 운영을 파트너사에 맡기면 한 명의 전담 인력이 배정되는 경우가 많습니다. 그러다 보면 개인 사정 등에 의해 업무가 지연되거나 공백이 생기기도 합니다. 하지만 베스핀글로벌의 IMS는 팀 단위의 Shared MSP로 진행되어 업무 공백이 전혀 없습니다. 팀 엔지니어 전체가 고객사의 인프라 상황과 운영을 모두 이해하고 있어 서비스 요청에 대응하는 속도도 훨씬 빠릅니다.
베스핀글로벌의 클라우드 IMS의 가치]
전문성 안정성 효율성 비용 절감 보안성 혁신성
클라우드 전문가 서비스
OS, DB, APP, Security 전문		 24✕365 모니터링
베스트 프랙티스 제공		 다양한 전문성 및
클라우드 운영 노하우 제공
비용 최적화 서비스 제공		 비용 최적화 서비스 제공 최적의 보안 방안 제시 아키텍처 리뷰 및
신기술 교육 제공

Market Overview

패션 업계에도 디지털 바람이 불고 있습니다. 온라인 쇼핑몰을 넘어 메타버스, NFT 등을 통해 고객들에게 다가가고, 제품 개발부터 생산, 운영, 고객 관리 영역까지 실시간 데이터로 관리할 수 있도록 IT 체계를 구축합니다. 패션 기업들이 디지털로 전환하는 이유 중 하나는 바로 ‘개인화’입니다. AI와 빅데이터를 통해 고객의 구매 기록, 장바구니, 매장 방문 기록 등을 분석해 취향에 맞는 제품들을 선보이는 것입니다. 그리고 이렇게 많은 데이터를 빠르고 정교하게 분석하고 관리하기 위해서는 클라우드가 필수입니다.

 

클라우드는 도입하는 것도 중요하지만 잘 사용하는 것이 더 중요합니다. 특히 빠르게 성장하는 기업일수록 비즈니스에 집중하다 보면 클라우드 인프라에서 낭비되는 자원과 비용이 발생할 가능성이 높은데요. 따라서 이를 효율적으로 관리하는 방안에 대한 고민이 필요합니다. 글로벌 기업으로 빠른 성장을 기록하고 있는 패션 브랜드 아이아이컴바인드는 그 답을 베스핀글로벌과 옵스나우에서 찾았습니다. 베스핀의 클라우드 경험과 노하우를 담은 옵스나우 덕분에 클라우드 인프라를 서비스별로 체계적으로 관리하고 자원과 비용을 최적화할 수 있었습니다. 앞으로 클라우드 위에서 글로벌 고객들에게 더욱 혁신적인 경험을 선사할 아이아이컴바인드의 행보가 기대됩니다.

문의하기

Hive ACID 테이블을 BigQuery로 마이그레이션 하는 권장사항

구글 인사이트
by Miyeon. Jo
목차
  1. 개요
  2. Hive ACID를 BigQuery로 마이그레이션할때의 이점
  3. Hive ACID 테이블 구조 및 샘플 데이터
  4. Hive ACID 테이블을 BigQuery로 마이그레이션하는 단계
  5. Hive DDL 마이그레이션
1. 개요

Hive ACID 테이블은 업데이트를 수락하고, DML 작업을 삭제하는 트랜잭션을 지원합니다. ACID는 데이터베이스 트랜잭션의 네 가지 특성을 나타냅니다.

  • 원자성(작업이 완전히 성공하거나 실패하고 부분 데이터를 남기지 않음)
  • 일관성(일단 애플리케이션이 작업을 수행하면 모든 후속 작업에서 해당 작업의 결과를 볼 수 있음)
  • 격리(한 사용자의 불완전한 작업이 다른 사용자에게 예기치 않은 부작용을 일으키지 않음)
  • 내구성(한 번 작업이 완료되면 기계 또는 시스템 오류가 발생하더라도 보존됨)

버전 0.14부터 Hive는 트랜잭션을 사용하고, 트랜잭션 테이블을 생성하고, 테이블에서 삽입, 업데이트 및 삭제와 같은 쿼리를 실행할 수 있도록 하는 모든 ACID
속성을 지원합니다.
Hive ACID 테이블의 기초가 되는 파일은 ORC ACID 버전입니다. ACID 기능을 지원하기 위해 Hive는 테이블 데이터를 기본 파일 세트에 저장하고 모든 삽입, 업데이트 및 삭제 작업 데이터를 델타 파일에 저장합니다. 읽을 때 리더는 기본 파일과 델타 파일을 모두 병합하여 최신 데이터를 표시합니다. 작업이 테이블을 수정함에 따라 많은 델타 파일이 생성되고 적절한 성능을 유지하려면 압축해야 합니다.

압축에는 마이너와 메이저의 두 가지 유형이 있습니다.

  • 마이너 압축은 기존 델타 파일 세트를 가져와 버킷당 단일 델타 파일에 다시 씁니다.
  • 메이저 압축은 하나 이상의 델타 파일과 버킷의 기본 파일을 가져와 버킷당 새 기본 파일에 다시 씁니다. 메이저 압축은 더 비싸지 만 더 효과적입니다.

조직은 자동 압축을 구성하지만 자동화 실패 시 수동 압축도 수행해야 합니다. 실패 후 오랜 시간 압축을 하지 않으면 작은 델타 파일이 많이 생깁니다. 이러한 많은 수의 작은 델타 파일에서 압축을 실행하면 리소스를 많이 사용하는 작업이 될 수 있으며 오류가 발생할 수도 있습니다.

Hive ACID 테이블의 몇 가지 문제는 다음과 같습니다.

  • 작은 델타 파일로 인한 NameNode 용량 문제.
  • 압축 중 테이블 잠금.
  • Hive ACID 테이블에서 메이저 압축을 실행하는 것은 리소스를 많이 사용.
  • 작은 파일로 인해 데이터를 DR로 복제하는 데 더 오랜 시간이 걸립니다.
2. Hive ACID를 BigQuery로 마이그레이션할 때의 이점

Hive ACID 테이블을 BigQuety로 마이그레이션하면 다음과 같은 이점이 있습니다.

  • 테이터가 관리형 BigQuery 테이블에 로드되면 BigQuery는 내부 저장소에 저장된 데이터를 관리 및 최적화하고 압축을 처리합니다. 따라서 Hive ACID 테이블에서와 같이 작은 파일 문제가 발생하지 않습니다.
  • BigQuery storage read API는 gRPC 기반이고 고도로 병렬화되므로 잠금 문제는 여기에서 해결됩니다.

ORC 파일은 완전히 자체 기술되므로, Hive Hive Transitore DDL에 의존하지 않습니다. BigQuery에는 ORC 파일에서 스키마를 추론할 수 있는 내장 스키마 추론
기능이 있으며 스키마 추론을 수행하기 위해 Apache Spark와 같은 도구를 사용할
필요 없이 스키마 진화를 지원합니다.

3. Hive ACID 테이블 구조 및 샘플 데이터

다음은 샘플 Hive ACID 테이블 “employee_trans” 스키마입니다.

hive> show create table employee_trans;
OK
CREATE TABLE `employee_trans`(
  `id` int, 
  `name` string, 
  `age` int, 
  `gender` string)
ROW FORMAT SERDE 
  'org.apache.hadoop.hive.ql.io.orc.OrcSerde' 
STORED AS INPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat' 
OUTPUTFORMAT 
  'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat'
LOCATION
  'hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans'
TBLPROPERTIES (
  'bucketing_version'='2', 
  'transactional'='true', 
  'transactional_properties'='default', 
  'transient_lastDdlTime'='1657906607')

이 샘플 ACID 테이블 “employee_trans”에는 3개의 레코드가 있습니다.

hive> select * from employee_trans;
OK
1       James   30      M
3       Jeff    45      M
2       Ann     40      F
Time taken: 0.1 seconds, Fetched: 3 row(s)

모든 삽입, 업데이트 및 삭제 작업에 대해 작은 델타 파일이 생성됩니다. 이것은 Hive ACID 사용 테이블의 기본 디렉토리 구조입니다.

hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delete_delta_0000005_0000005_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delete_delta_0000006_0000006_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delta_0000001_0000001_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delta_0000002_0000002_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delta_0000003_0000003_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delta_0000004_0000004_0000
hdfs://hive-cluster-m/user/hive/warehouse/aciddb.db/employee_trans/delta_0000005_0000005_0000

ACID 테이블의 이러한 OCR 파일은 여러 열로 확장됩니다.

struct<
  operation: int,
  originalTransaction: bigInt,
  bucket: int,
  rowId: bigInt,
  currentTransaction: bigInt,
  row: struct<...>
>
4. Hive ACID 테이블을 BigQuery로 마이그레이션하는 단계
1) 기본 Hive 테이블 HDFS 데이터 마이그레이션

GCS의 employee_trans hdfs 디렉토리 및 스테이지에 있는 파일을 복사합니다.
HDFS2GCS 솔루션 또는 Distcp 를 사용할 수 있습니다 . HDFS2GCS 솔루션은 오픈 소스 기술을 사용하여 데이터를 전송하고 상태 보고, 오류 처리, 내결함성, 증분/델타 로딩, 속도 조절, 시작/중지, 유효성 검사, byte2byte 비교 등과 같은 여러 이점을 제공합니다. HDFS2GCS 솔루션. 이 도구에 대한 자세한 내용은 공개 github URL HDFS2GCS 를 참조하십시오.
원본 위치에는 복사하고 싶지 않은 추가 파일이 포함될 수 있습니다. 여기에서 정규식을 기반으로 하는 필터를 사용하여 확장자가 .ORC인 파일만 복사하는 것과 같은 작업을 수행할 수 있습니다.

2) BigQuery에 ACID 테이블을 있는 그대로 로드

기본 Hive acid 테이블 파일이 GCS에 복사되면 BQ 로드 도구를 사용하여 BigQuery 기본 테이블에 데이터를 로드합니다. 이 기본 테이블에는 모든 변경 이벤트가 있습니다.

3) 데이터 검증

기본 테이블에서 “select *”를 실행하여 모든 변경 사항이 캡처되었는지 확인합니다.
참고 : “select * …”의 사용은 데모 목적으로 사용되며 명시된 모범 사례가 아닙니다.

4) 대상 BigQuery 테이블에 로드

다음 쿼리는 중간 삭제 및 업데이트 작업을 삭제하여 기본 테이블에서 모든 레코드의 최신 버전만 선택합니다.
덮어쓰기 옵션과 함께 주문형 예약 쿼리를 ​​사용하여 이 쿼리의 결과를 대상 테이블에 로드하거나 또는 이 쿼리를 기본 테이블의 보기로 생성하여 기본 테이블에서 직접 최신 레코드를 가져올 수도 있습니다.

WITH
 latest_records_desc AS (
 SELECT
   Row.*,
   operation,
   ROW_NUMBER() OVER (PARTITION BY originalTransaction ORDER BY originalTransaction ASC, bucket ASC, rowId ASC, currentTransaction DESC) AS rownum
 FROM
   `hiveacid-sandbox.hivetobq.basetable` )
SELECT id,name,age,gender
FROM
 latest_records_desc
WHERE
 rownum=1
 AND operation != 2

데이터가 대상 BigQuey 테이블에 로드되면 아래 단계를 사용하여 유효성 검사를 수행할 수 있습니다.

(1) 데이터 유효성 검사 도구를 사용하여 Hive ACID 테이블과 대상 BigQuery 테이블의 유효성을 검증합니다. DVT는 스키마 및 유효성 검사 작업을 수행할 수 있는 자동화되고 반복 가능한 솔루션을 제공합니다. 이 도구는 다음 유효성 검사를 지원합니다.

  • 열 유효성 검사(count, sum, avg, min, max, group by)
  • 행 유효성 검사(BQ, Hive 및 Teradata만 해당)
  • 스키마 유효성 검사
  • 사용자 정의 쿼리 유효성 검사
  • 임시 SQL 탐색

(2) ACID 테이블에서 실행 중인 분석 HiveQL이 있는 경우 BigQuery SQL 변환 서비스 를 사용하여 변환하고 대상 BigQuery 테이블을 가리킵니다.

5. Hive DDL 마이그레이션(선택사항)

ORC는 독립적이므로 로드할 때 BigQuery의 스키마 추론 기능을 활용하세요. Metastore에서 Hive DDL을 추출하는데 종속성이 없습니다. 그러나 마이그레이션 전에 데이터 세트와 테이블을 미리 생성하는 조직 차원의 정책이 있는 경우 이 단계가 유용할 것이며 좋은 출발점이 될 것입니다.

1) Hive ACID DDL 덤프를 추출하고 BigQuery 변환 서비스를 사용하여 변환하여 동등한 BigQuery DDL을 생성합니다.

구글 클라우드 스토리지의 소스 메타데이터 버킷에서 빅쿼리 관련 SQL로 내보낸 HQL(Hive Query Language) 스크립트를 대상 GCS 버킷으로 대량 변환하는 일괄 SQL 변환 서비스가 있습니다.
또한 여러 SQL 언어에 대한 실시간 SQL 변환 도구인 BigQuery 대화형 SQL 변환기를 사용하여 HQL 언어와 같은 쿼리를 BigQuery standard SQL 쿼리로 변환할 수 있습니다. 이 도구를 사용하면 SQL 워크로드를 BigQuery로 마이그레이션하는 데 드는 시간과 노력을 줄일 수 있습니다.

2) 변환된 DDL을 사용하여 관리형 BigQuery 테이블을 만듭니다.

다음은 BigQuery 콘솔의 변환 서비스 스크린샷입니다. HiveQL을 변환하려면 “변환”을 제출하고 쿼리를 실행하려면 “실행”을 제출하십시오. 일괄 변환된 대량 SQL 쿼리에서 테이블을 생성하려면 Airflow BigQuery 연산자(BigQueryInsertJobOperator)를 사용하여 여러 쿼리를 실행할 수 있습니다.

DDL이 변환된 후 ORC 파일을 GCS에 복사하고 BigQuery에서 ELT를 수행합니다. BigQuery로 마이그레이션할 때 Hive ACID 테이블의 문제점이 해결됩니다. ACID 테이블을 BigQuery로 마이그레이션하면 실시간 분석을 위해 BigQuery ML 및 GeoViz 기능을 활용할 수 있습니다.

출처

클라우드 컴퓨팅 최후의 미개척지, ‘메타클라우드’

구글 인사이트
by Miyeon. Jo

클라우드 컴퓨팅 최후의 미개척지, ‘메타클라우드’

현재 클라우드 전문가들은 다양한 퍼블릭 클라우드의 집합 위에 자리 잡은 새로운 기술 레이어의 출현에 주목하고 있다. 멀티클라우드의 진정한 최종 형태라고 할 수 있다. 이 레이어는 애플리케이션 개발, 운영, 관측, 보안, 거버넌스 등을 포괄하는 것으로 개별 퍼블릭 클라우드 제공업체 수준을 뛰어넘어 적용되며 결과적으로 ‘실질적인’ 멀티클라우드를 구현한다.

이를 부르는 용어가 몇 가지 있다. 슈퍼클라우드(supercloud), 분산 클라우드(distributed cloud), 메타클라우드(metacloud), 추상적 클라우드(abstract cloud) 등이다. ‘클라우드 네이티브’라는 용어도 있다. 이런 신조어는 만드는 사람에 따라 정확한 개념이 약간씩 차이가 있지만, 공통으로 퍼블릭 클라우드의 모음을 의미하고 때로는 더 거대한 목표를 위해 함께 작동하는 엣지 기반 시스템을 가리킨다.

이러한 메타클라우드 개념은 퍼블릭 클라우드를 업무에 본격적으로 활용하게 되면서 앞으로 5~10년간 큰 주목을 받게 될 것이다. 추상화와 자동화를 통해 관리되는 여러 가지 클라우드 서비스의 모음을 확보하는 것이, 개별 퍼블릭 클라우드 업체의 서비스를 활용하는 것보다 더 중요해질 것이다.

보통 기업은 추상화된 인터페이스를 통해 스토리지나 컴퓨트, 인공지능, 데이터 등 원하는 서비스에 접근하는 방법으로 퍼블릭 클라우드 업체를 활용한다. 동시에 클라우드 확장 기술 레이어를 통해 이들 서비스를 더 효과적으로 사용하고 싶어 한다. 이 과정에서 복잡성이 필연적으로 발생하는데, 메타클라우드는 이런 복잡성을 제거한다. 또한, 크로스 클라우드 레이어를 통해 비용 효율적으로 멀티클라우드를 지원하는 확장 작업을 하는 것도 가능하다.

결과적으로 기업은 메타클라우드를 통해 보안과 거버넌스, 운영은 물론 애플리케이션 개발과 배포까지 통합된 단일 레이어를 확보할 수 있다. 그동안 기업이 원하던 궁극적인 멀티클라우드의 모습이다. 기존에는 단일 클라우드에서만 작동하는 전용 툴을 이용해 더 많은 사일로를 만들고 더 다양한 툴을 사용해야 했다. 복잡성은 점점 커지고 결국 멀티클라우드는 장점보다 오히려 단점이 더 많은 시스템이 될 수도 있었지만, 메타클라우드를 통해 그 해법을 찾을 수 있다.

이 새로운 멀티클라우드 트렌드를 무엇이라고 부르든 상관이 없다. 메타클라우드라는 용어가 또 다른 혼란으로 이어질지 수도 있음을 알고 있다. 그런데도 메타클라우드가 현재 가장 중요한 아키텍처 측면의 진화라는 사실은 변함이 없고, 우리는 이를 현실화해야 한다. 물론 이런 구현 작업에 실패한다면, 이 기술을 누가 어떤 명칭으로 부르든 아무 의미가 없게 된다.

‘메타클라우드’에 관한 4가지 오해

위에 기술한 ‘클라우드 컴퓨팅 최후의 미개척지, ‘메타클라우드(metacloud)’라는 글에는 제목 때문인지 유독 많은 사람이 관심을 보였으며, 소셜 미디어에 특히 여러 의견과 질문이 있었는데 그중에서 공통적으로 많이 나왔던 내용을 함께 공유하고자 한다.

1. 메타클라우드는 이미 판매 중이다

가장 많이 볼 수 있는 의견이었다. 먼저 메타클라우드는 특정 서비스나 기술이 아니라는 점을 강조하고 싶다.

메타클라우드는 아키텍처 패턴이다. 최근 페이스북이 기업명을 ‘메타 플랫폼(Meta Platforms, Inc.)’이라고 변경해서 혼동할 수 있는데, 페이스북의 메타는 메타클라우드와 상관없다.

메타클라우드는 제품, 기술 또는 아키텍처 표준에 의해 형성된다. 보안, 스토리지, 네트워크 등과관련한 퍼블릭 클라우드 서비스 2개 이상 포함한다.

특정 서비스가 메타클라우드 아키텍처의 일부가 될 수 있지만, 서비스 그 자체는 메타클라우드가 아니다.

2. 메타클라우드에는 기본 클라우드 서비스 업체가 필요하다

클라우드 서비스 업체 대부분이 이 표현을 강조한다. 절반은 맞는 말이다.

무엇으로 지칭하든 메타클라우드 사용자는 논리적으로 두 개 이상의 퍼블릭 클라우드 서비스를 이용한다. 핵심은 ‘논리적으로’이다. 메타클라우드 대시보드는 여러 클라우드의 보안, 운영, 거버넌스, 공통 저장 시스템 등을 논리적으로 확인하고 보여준다.

특정 클라우드 서비스 업체에서만 작동하는 독점 혹은 최적화 서비스가 있다하더라도 이를 볼 수 있는 추상화 기술이 제공된다. 메타클라우드 아키텍처 혹은 기술 스택은 ‘실제로는’ 한 개 혹은 여러 클라우드 서비스 업체의 플랫폼에 위치할 수 있다. 하지만 실제 위치와 상관없이 여러 시스템을 ‘논리적으로’ 한꺼번에 관리한다.

메타클라우드 사용자는 클라우드 지식과 상관없이 이용할 수 있는 쉬운 기술을 찾는 경향이 있다. 그래서 약간 혼란스러울 수 있지만 아무튼 메타클라우드는 어디선가에서 반드시 실행되며 그 실행 위치가 주요 퍼블릭 클라우드가 될 확률이 높다.

만약 여러 클라우드 시스템을 특정 클라우드 서비스 업체에서 관리하면서 메타클라우드를 구축했다면, 해당 클라우드 서비스를 메타클라우드의 기본 서비스 업체라고 봐도 무방하다. 그러나 그런 솔루션은 클라우드를 운영하는 모든 플랫폼 위에서 ‘물리적으로’ 설치해 실행할 수 있기 때문에 메타클라우드로 만드는 결과가 큰 의미가 있을지 모르겠다. 사용하고 있는 솔루션을 살펴보고 가장 적합한 플랫폼을 선택해보자.

3. 멀티클라우드 위에 계층을 추가해 발생하는 복잡성은 숨길 수 있어도 제거하지 못한다

핵심을 잘 파악한 의견이다. 그러나 멀티클라우드가 복잡한 이유는 여러 클라우드 업체를 선택하고, 또 그 안에서 다양한 서비스를 이용하기 때문이다. 보통 결정권을 가진 담당자가 복잡성에 미칠 영향보다 프로젝트 요구사항을 충족시키는 부분을 더 중요시해서 최상의 서비스만 선택할 때 이런 일이 발생한다. 복잡성과 이질성이 나타나는 것이다.

만약 인프라 조직에서 이용할 수 있는 클라우드 서비스 종류를 정해 놓는다면, 복잡성 문제를 미리 피할 수 있다. 대신 사업의 핵심 기술을 만들고 혁신을 추구하는 과정에서 최상의 기술을 이용하지 못할 수 있다. 따라서 기술 혁신이 가져올 이익과 그로 인해 초래할 복잡성 중 어느 것이 어떤 것을 우선해야 하는지 결정해야 한다. 이를 결정했다면, 둘 사이의 최적의 교차점을 찾아내야 한다.

시스템이 이미 복잡한 경우, 구조적 복잡성을 숨긴다고 문제가 해결되지 않는다. 이런 유형의 복잡성은 혁신을 추구하겠다고 좋은 서비스를 선택해서 생긴 복잡성과는 결이 다르다. 설계가 잘못돼 복잡성이 나타났다면, 숨기기보다 고쳐야 한다.

요점은 멀티클라우드를 사용하면 반드시 복잡성이 생긴다는 것이다. 확실히 얻을 이익이 있기 때문에 여러 클라우드를 선택한 것이고, 결국 어느 순간 복잡성이 나타날 수 있다. 하지만 추상화와 자동화 계층을 활용하면 복잡한 멀티클라우드 배포를 어떻게 최적의 방식으로 운영하고 보안성을 높일지 배울 수 있다.

추상화와 및 자동화 계층을 운영하려면 퍼블릭 클라우드 배포와 거의 동일 수준 혹은 그보다 적은 인력과 시스템 리소스를 투입해야 한다. 추상화와 자동화는 특정 유형의 복잡성을 숨길 수 있으며, 그 복잡성 수준은 확장 및 축소될 수 있다.

4. 추상화 계층을 이용하면 지연이 발생한다

마지막으로 흔히 볼 수 있는 의견은 기존 인터페이스와 최종적으로 해당 서비스를 소비하는 인터페이스 사이에 다른 계층을 추가하면 요구와 응답 시간 사이에 지연이 생긴다는 것이다.

예를 들어 기업이 퍼블릭 클라우드 스토리지를 위해 스토리지 인터페이스 추상화, 즉 클라우드 네이티브 스토리지 시스템을 사용하고 있다고 하자. 개발자는 각 퍼블릭 클라우드 서비스 업체의 전용 API와 같이 특정한 API를 사용할 필요가 없다. 인터페이스가 단일 추상 API/CLI를 이용해 그 과정을 자동화하기 때문이다. 물론 여기에는 추가적인 처리와 필수적인 I/O로 인해 지연이 발생한다. 하지만 개발자, 테스터, 사용자 대부분은 알아차리지 못할 수준일 것이다.

물론 메타클라우드에서 이 부분은 간단한 일이 아니다. 메타클라우드는 결국 스토리지와 컴퓨팅 인스턴스를 추상화해, 다양한 퍼블릭 클라우드 안의 여러 서비스가 서로 쉽고 간편하게 상호작용하는 방법을 찾아내는 일이다.

메타클라우드는 보안, 핵심 운영, 관리, 메타 데이터 관리 등 운영 프로세스에 관한 추상화로 이뤄진다. 각 클라우드의 네이티브 시스템을 사용해 이를 처리해야 한다면, 그 작업은 지나치게 복잡하고 번거로울 수 있다. 하나의 스토리지 운영 계층에서 작업하는 대신, 4~5개의 스토리지 운영 계층에서 작업해야 할 때도 있다.

각 퍼블릭 클라우드 서비스 및 세부 기능을 잘 아는 담당자를 확보하는 것은 쉬운 일이 아니다. 공통의 추상화 계층이 없기 때문에 크로스 클라우드 운영 기능이 없는 멀티클라우드를 운영하기 위해서는 평소보다 비용이 3~4배 더 들어갈 수 있다.

출처

IAM 역할 조건 및 태그와 함께 Cloud Bigtable 사용

구글 인사이트
by Miyeon. Jo
목차
  1. 개요
  2. Identity and Access Management (IAM)
  3. IAM 조건(Condition)
  4. IAM 역할에 Tag 조건 구성
  5. 요약
1. 개요

Cloud Bigtable은 지연시간이 짧고 높은 처리량이 지원하는 NoSQL 데이터베이스 입니다.

Bigtable 사용자는 테이블에 수 테라바이트의 데이터를 저장하며 데이터를 안전하게 제어하는 것이 필수적입니다.

Bigtable 데이터에 대한 액세스 보안을 담당하는 관리자 또는 개발자인 경우 Google Cloud 보안 기능을 사용하여 Bigtable 리소스를 잠그고 사용자 인증 모델을 지정할 수 있습니다. 특정 Bigtable 리소스에 대한 액세스를 제어하고, 권한을 적용하기 위해 리소스 범위를 좁히고 개발 환경에 따라 IAM 조건 및 태그를 사용하여 Bigtable 데이터를 보호하는 권한 설정 방법을 설명합니다.

2. Identity and Access Management (IAM)

IAM은 GCP 리소스를 중앙에서 관리하기 위한 세분화된 액세스 제어 및 가시성을 제공합니다. 복잡한 클라우드 조직에는 역할을 기반으로 액세스를 제어하려는 관리자가 구성한 IAM 정책을 바인딩할 수 있는 다양한 리소스가 있을 수 있습니다.

다음 다이어그램은 IAM 정책을 리소스에 바인딩하는 관리자를 보여줍니다. IAM 정책은 구성원이라고 하는 하나 이상의 보안 주체로 구성되며 관리자는 각 보안 주체에게 하나 이상의 역할을 부여할 수 있습니다. 역할 부여 대상은 사용자, 그룹 또는 서비스 계정일 수 있습니다. 역할은 보안 주체가 GCP 리소스에서 일부 작업을 수행하도록 허용하는 권한 모음입니다.

리소스는 리소스 트리의 상위 항목에서 IAM 정책을 상속합니다. 사용자가 요청을 보내면 IAM은 사용자에게 해당 특정 리소스에 대한 작업을 수행할 권한이 있는지 확인합니다.
특정 사용자에게 정책을 부여하려는 경우 정책을 부여하려는 리소스에 바인딩된 IAM 정책이 사용자에게 권한을 부여할 수 있으면 권한이 부여됩니다. 그렇지 않은 경우 IAM은 리소스 트리로 이동하여 이러한 권한을 부여할 수 있는 정책을 검색합니다. 권한을 부여할 수 있는 정책이 리소스 트리에 없으면 권한 거부 오류와 함께 요청이 거부됩니다.

다음 Cloud Console 예시에서는 사용자 “222larabrown@gmail.com”에게 Bigtable Reader 역할을 부여하고 정책을 my-project 프로젝트에 결합합니다.

gcloud CLI 명령어를 사용하여 수행할 수 있습니다.

$ gcloud projects add-iam-policy-binding my-project \
  --member='user:222larabrown@gmail.com' \
  --role='roles/bigtable.reader'

바인딩이 생성되면 my-project 프로젝트 내에서 222larabrown@gmail.com에 Bigtable Reader 역할이 부여됩니다. 즉, 222larabrown@gmail.com은 기존 테이블의 데이터에 대한 읽기 액세스 권한과 컬럼 집합을 포함하는 인스턴스, 클러스터, 테이블의 메타데이터에 대한 읽기 액세스 권한을 가질 수 있습니다.

IAM에는 기본, 사전 정의 및 사용자 지정의 세 가지 역할 유형이 있습니다.
Bigtable Reader 역할은 사전 정의된 역할입니다. IAM 역할에 대한 자세한 내용은 역할 이해를 참조하십시오.

3. IAM 조건(Condition)

IAM 조건(Condition)은 GCP 리소스에 대한 조건부 속성 기반 액세스 제어를 정의하고 시행할 수 있는 기능입니다. 리소스에 대한 역할 바인딩 외에도 리소스 액세스는 구성된 조건이 충족되는 경우에만 보안 주체에게 부여됩니다.

다음은 IAM 조건의 작동 방식을 보여줍니다.

다음 Cloud Console 예시는 “Report tables” 조건으로 사용자 222larabrown@gmail.com에게 Bigtable Reader 역할을 부여하고 정책을 my-project 프로젝트에 결합합니다. “Report tables” 조건에서 222larabrown@gmail.com은 특정 Bigtable 인스턴스 내의 테이블 ID에 “report-”라는 접두사가 포함된 Bigtable 테이블에 대한 읽기 액세스 권한을 갖습니다.

“Report tables” 조건은 다음과 같이 정의됩니다.

  • 소스 유형은 Bigtable 테이블 “bigtableadmin.googleapis.com/Table”이어야 합니다.
  • 리소스(테이블) 이름은 접두사
    “project/my-project/instances/my-instance/tables/report-”로 시작되어야 합니다.
  • 서비스는 Bigtable 관리자 서비스: “bigtableadmin.googleapis.com”이어야 합니다.

gcloud CLI 명령어를 사용하여 수행할 수 있습니다.

$ gcloud projects add-iam-policy-binding my-project \
  --member='user:222larabrown@gmail.com' \
  --role='roles/bigtable.reader' \
  --condition-from-file=CONDITION_FROM_FILE

조건(Condition) 정의 파일을 JSON 또는 YAML 파일로 구성합니다.
“CONDITION_FROM_FILE” : 조건 정의 파일 경로

01   "title": "Report tables",
02   "description": "Tables with 'report-' prefix.",
03   "expression": "resource.type == 'bigtableadmin.googleapis.com/Table' && resource.name.startsWith('projects/my-project/instances/my-instance/tables/report-) && resource.service == 'bigtableadmin.googleapis.com'"
4. IAM 역할에 Tag 조건 구성

운영 환경에 구성된 리소스에는 “222larabrown@gmail.com” 사용자가 접근되어서는 안 되는 민감한 데이터가 포함되어 있습니다. “222larabrown@gmail.com” 사용자는 테스트 또는 스테이징 환경의 데이터에 대한 읽기 액세스 권한만 허용해야 하는 경우 어떻게 구성할 수 있을까요?

요구하는 조건을 구성하는 방법중 하나는 각 환경에서 구성된 리소스에 태그값을 설정하고 IAM 조건을 사용하여 연결된 태그 값으로 리소스에 대한 액세스를 제한하는 것입니다.

태그 사용은 조직 계층의 리소스를 관리하는 좋은 방법입니다. 태그를 사용하여 액세스 제어와 같은 다양한 목적을 위해 특정 리소스를 그룹화할 수 있습니다. 테스트, 스테이징 및 운영 환경과 같은 다양한 환경에 대한 리소스를 그룹화하기 위해 태그를 사용하는 방법을 살펴보겠습니다.

먼저 GCP Console > Google Cloud 조직 > 태그 메뉴에서 조직 구조로 구성된 프로젝트들을 관리할 태그를 만들 수 있습니다. 새 태그에는 “Test”, “Staging” 및 “Prod” 값이 있습니다.

태그가 생성되면 Tag Key ID와 구성된 세 개의 Tag value 들의 대한 Tag Value ID가 생성됩니다.

테스트 환경에 Bigtable 인스턴스 “my-instance”를 사용한다고 가정해보겠습니다. gcloud CLI를 사용하여 다음과 같이 Environment 태그의 “Test” 태그값을 인스턴스에 바인딩할 수 있습니다.

$ gcloud resource-manager tags bindings create \
  --tag-value=tagValues/260761697116 \
  --parent=//bigtable.googleapis.com/projects/my-project/instances/my-instance

참고: 현재 Bigtable 인스턴스에 태그 지정은 Cloud Console에서 지원되지 않습니다.

바인딩이 적용되면 리소스에 “Test” 태그값과 일치하는 태그 값이 있는 경우에만 액세스를 허용하도록 조건을 추가하고 보안 주체에게 역할을 부여할 수 있습니다.
이제 사용자 “222larabrown@gmail.com”은 테스트 환경에만 액세스할 수 있습니다.

자세한 내용은 태그 및 액세스 제어를 참조하십시오.

5. 요약
  • IAM 기초
  • Bigtable 제어에 대한 IAM 역할을 설정하는 방법
  • IAM 조건(Condition)을 사용하여 IAM 역할의 범위를 추가로 제어하는 방법
  • IAM 태그를 사용하여 권한 구성에 대한 환경 요구 사항을 추가하는 방법

출처

계정 2단계 인증을 통한 Google Cloud 보안강화

구글 인사이트
by Miyeon. Jo
목차
  1. 개요
  2. 계정 2단계 인증 종류
  3. 계정 2단계 인증 추가
1. 개요

클라우드를 사용하는데 있어 보안은 언제나 중요한 요소입니다.
그중에서도 구글 클라우드에서 기본적으로 제공하는 사용자 계정 2단계 인증은 따로 비용이 책정되지 않으면서 보안을 강화할 수 있는 좋은 선택입니다. 개인의 계정의 보안을 좀더 강화할수도 있고 클라우드를 사용하는 조직원들에게 적용시켜 프로젝트 전체의 보안레벨을 높일수도 있습니다.

2. 계정 2단계 인증 종류

백업 코드는 다른 수단의 확인이 불가능한 (확인수단이 있는 단말이 오프라인 상태이거나 전원이 없거나) 상황에서도 사용 가능합니다. 백업 코드를 파일 형태로 받게 되며 해당 파일에는 8자리의 보안코드 10개가 들어있습니다. 각각의 코드는 1회용으로 재사용이 불가능합니다.

Google 메시지는 등록한 단말에 지금 로그인한 사용자가 본인이 맞는지 확인하는 메시지가 전송 되며, 기기는 여러개를 등록할 수 있습니다.

OTP(One Time Password) 앱은 구글이 제공하는 Google Authenticator앱을 사용하며 Android, iOS버전이 모두 있습니다. 이 앱은 1분마다 무작위의 6자리 숫자를 생성하여 해당 코드를 입력하여 2차인증을 지원합니다.

보안키는 휴대전화에 내장된 보안키를 사용하거나 따로 구입한 보안키를 블루투스나 USB로 직접 연결해 사용합니다.

3. 계정 2단계 인증 추가
(1) 아래의 링크로 접속하시면 구글 계정의 보안탭으로 들어가시게 됩니다

https://myaccount.google.com/u/0/security

(2) Google에 로그인 을 보시면 2단계 인증이 있습니다. 클릭해서 들어갑니다.
(3) 2단계 인증에서 시작하기를 누릅니다.
(4) 다시 한번 계정 인증을 하게 됩니다.
(5) 전화번호를 등록하는 순서로 넘어가게 됩니다. 기존에 이미 전화번호를 등록하셨다면 이 과정은 생략됩니다. 아래의 옵션에서 코드를 문자 메세지로 받을지 전화통화로 받을지 결정하고 다음을 누릅니다.
(6) 이전에 선택하신 방법에 따라 해당 번호로 인증코드가 보내집니다. 코드 입력란에 수신하신 코드를 입력하고 다음을 누릅니다.
(7) 올바른 코드를 입력하셨다면 아래와 같은 화면을 보시게 됩니다. 사용 버튼을 선택하시면 됩니다.
(8) 그럼 이렇게 전화번호가 등록된 상태에서 2단계 인증방법 선택지가 보이게 됩니다.
(9) 첫번째 선택기인 백업코드를 설정해 보겠습니다. 백업코드 우측의 화살표를 클릭하면 계정 확인을 다시한번 거치고 이후에 아래의 화면이 표시됩니다.
(10) 백업 코드 받기를 누르시면 아래와 같은 화면이 나타납니다. 백업코드는 8자리의 숫자로 이루어진 10개의 코드가 생성됩니다. 각각의 코드는 한번 사용하면 다시 사용할수 없는 1회성이므로 사용후에 사용한 코드를 체크해두시는것을 권장합니다. 코드 인쇄를 누르시면 프린터로 인쇄를 해두실 수 있고 코드 다운로드를 누르시면 Backup-codes-계정명.txt의 파일이 다운로드 됩니다.
(11) 이제 다시 돌아가보면 아래와 같이 2단계 인증에 백업코드가 추가된 것을 볼 수 있습니다. 하지만 이전에 기술한것 처럼 백업코드는 다른 2단계 인증을 사용하기 힘든 상황을 대비한 예비수단으로서 준비해두는 것이므로 일상적으로 사용하기 위한 2단계 인증은 다른 방법을 선택하시기를 추천합니다.
(12) 다음은 Google 메세지입니다. 이 방법은 2단계 인증을 사용 설정했다면 지금까지 구글 계정으로 로그인한적 없는 기기에서 구글 계정에 로그인하려고 하면 이미 로그인되어 있는 모든 기기에 이 로그인이 본인이 로그인하는 시도가 맞는지 확인하게 됩니다. 이미 로그인된 기기에 확인을 하게 되므로 만약 자신이 로그인 시도가 아닌 경우 수신한 메세지 에서 자신이 아니라고 체크하게 되면 해당 로그인 시도는 실패하게 됩니다. 2단계 인증을 사용한다면 다른 설정은 필요하지 않습니다.
(13) 다음은 OPT앱을 사용하는 방법입니다. 선택을 누르고 들어가면 아래와 같은 화면이 표시됩니다. 설명대로 먼저 설치가 가능한 단말에 Google OTP를 설치합니다.
(14) 이 상태에서 화면의 인증자 설정을 누르시면 아래와 같은 QR코드가 화면에 보이게 됩니다.
(15) OTP앱을 설치하시고 +를 누르시고 ‘QR 코드 스캔’을 누릅니다. 카메라 화면으로 바뀌면 위의 QR코드를 스캔하면 OTP앱에서 ‘계정이 추가됨’ 메세지가 뜨면서 앱에 해당 계정의 OTP 6자리 코드가 보이게 됩니다.
(16) 다음을 누르고 넘어가면 아래와 같이 표시되는 6자리 코드를 입력하라는 화면이 나오는데 앱에서 보이는 6자리 코드를 입력하고 인증을 누릅니다.
(17) 이제 2단계 인증 수단으로 OTP를 사용할 수 있게 되었습니다.
(18) 보안키를 이용한 2단계 인증은 현재 한국 구글 홈페이지에서 Titan키를 판매하지 않고 있으므로 여기서는 다루지 않겠습니다. 어떤 것인지 확인하고 싶으시다면 https://store.google.com/us/product/titan_security_key?hl=en-US 링크에 들어가시면 제품을 볼 수 있습니다.

출처

Contract for AWS Resale

by Miyeon. Jo

Contract for AWS Resale

계약 일반 조건
제1조(목적)

본 계약은 고객사와 Amazon Web Services (이하 ‘AWS’)의 공식 파트너인 베스핀과 고객사간 사용계약을 체결함에 있어 필요한 제반 사항을 명시하여 상호신뢰를 바탕으로 성실한 계약 이행과 공동의 이익 발전에 이바지함을 목적으로 한다.

제2조(용어의 정의)
  1. “서비스”란 계약서 표지에 나열된 서비스를 말한다.
제3조(계약기간)
  1. 본 계약의 기간은 표지의 “계약기간”으로 한다. 다만, 양 당사자의 서면 합의로 본 서비스의 기간을 변경할 수 있다.
  2. 본 계약의 만료 1개월 전까지 당사자 일방 또는 쌍방이 계약 내용의 변경을 요구하거나 계약의 종료를 통보하지 아니한 경우에는 본 계약은 동일한 조건으로 1년씩 자동 연장 된다.
제 4 조(계약상세조건)
  1. 고객사는 본 계약 체결을 통해 서비스 사용과 관련하여 AWS 라이선스 계약조건
    (AWS+Solution+Provider+Program+-+Program+Guide+for+End+Customers.pdf)에 나열된 조건들을 포함하나 이에 한정하지 않고)을 포함한 관련 규정들을 준수할 것을 확약하며, 필요시 고객사는 인터넷 박스 클릭 등의 형태로 AWS와 별도 약관, 라이선스 계약 등을 체결한다.
  2. 고객사가 선택한 Support plan에 따라 AWS에서 고객사에 제공하는 기술지원서비스가 제한될 수 있다. (https://aws.amazon.com/ko/premiumsupport/compare-plans/)
  3. 고객사는 베스핀의 원활한 고객지원을 위해 베스핀이 고객사를 대신하여 AWS Support Center 에 접속 및 관리할 수 있도록 IAM계정을 생성하여 베스핀에 위임하여야 하며, 고객사가 상기 절차를 완료하지 않았을 경우 서비스 중지를 포함하여 서비스 이용에 제약이 있을 수 있다.
  4. 제공되는 서비스가 본 계약에 명시된 바와 다르다고 고객사가 판단할 경우, 고객사는 베스핀에게 이러한 사실을 서면으로(이메일 포함) 통보하고 베스핀은 이에 지체없이 대응하여야 한다. 베스핀은 서비스가 아무런 장애나 에러 없이 제공되거나, 본 계약서에 명시되지 않은 고객사의 요구사항이나 기대치에 부합할 것을 보증하지는 않는다.
제5조(대금지급조건)
  1. 본 계약에 따라 고객사가 베스핀에 지급해야 할 서비스 사용료는 매월 고객사의 AWS의 사용료를 기준으로 베스핀이 산정하는 금액(부가세 별도)으로 한다.
  2. 제 3자의 서비스는 제3자 서비스 제공자의 서비스 대금지급조건을 따른다.
  3. 고객사는 베스핀에게 서비스에 대한 대가를 매월 발행된 세금계산서 수령 후 당월 25일 이내 지급한다.
  4. 베스핀은 고객사의 전월 사용금액에 대해 사용월 마지막 영업일 기준 서울외국환중개소 환율을 적용하여 세금계산서를 발행한다.
  5. 지급기일에 지급이 이루어지지 않는 경우 연 15%의 지연이자가 적용 된다.
제6조(권리의무의 양도금지)

고객사와 베스핀은 상대방의 사전 서면 동의 없이 본 계약상의 권리와 의무를 제3자에게 양도하거나 처분할 수 없다. 단, 베스핀이 자신의 계열사에게 본 계약상의 권리와 의무의 일부 또는 전부를 양도하는 경우는 예외로 한다.

제 7 조(비밀유지)

베스핀과 고객사는 본 계약의 체결 및 이행과 관련하여 알게 된 상대방의 업무상 비밀을 상대방의 사전 서면 동의 없이 제 3자에게 공개, 유출, 제공하여서는 아니 된다. 상대방의 상호, 로고 등은 영업비밀에 해당하지 않으며 계약 당사자들이 홍보 목적 등으로 사용할 수 있으나 그 사용이 상대방의 명성을 저하시키거나 명예를 훼손하여서는 아니 된다.

제8조(계약의 해지)
  1. 각 당사자는 다음 각호의 사유가 있는 경우 상대방에 대한 최고절차 없이 서면통지로써 본 계약을 즉시 해지할 수 있다.
    1. 당사자가 발행, 배서한 유가증권의 부도, 파산·회생절차의 신청 또는 개시 등으로 계약상의 의무를 수행하기 어려운 경우
    2. 주요재산에 대한 압류, 가압류, 가처분, 경매, 체납처분 등 강제처분이 있어 본 계약상의 의무를 수행하기 어려운 경우
    3. 본 계약과 관련한 지적재산권 등 분쟁발생, 제3자의 소송제기ㆍ고소ㆍ고발, 행정기관의 제재처분 등으로 인하여 본 계약상의 의무를 정상적으로 이행할 수 없게 되거나 현저히 어렵다고 판단되는 경우
    4. 상대방에게 본 계약에 따른 의무 불이행에 대하여 그 이행 또는 시정을 요구하였음에도 14일 이내에 이행/시정하지 않은 때
    5. 발행 또는 배서한 어음· 수표가 부도 등 지급되지 않은 때
    6. 영업정지처분 등 행정조치로 인하여 본 계약의 이행이 어렵다고 판단되는 때
    7. 상대방에게 제공한 영업비밀(개인정보 포함)이 상대방에 의하여 공개, 유출 등 본 계약 이외의 용도로 사용된 때
    8. 천재지변 기타 이에 준하는 사태로 인하여 상당한 기간 동안 정상적인 계약관계를 기대할 수 없는 때
    9. 상대방의 신용, 이미지 훼손, 신뢰관계 파괴 등 기타 본 계약을 계속 유지하기 어려운 중대한 사유가 발생한 때
  2. 본 계약이 해지되는 경우 또는 본 계약에 따른 의무 불이행이 발생한 경우에 그로 인하여 상대방에게 손해가 발생한 때에는, 그 책임이 있는 당사자는 상대방이 입은 손해를 배상하여야 한다. 고객이 손해배상을 주장시, 베스핀의 손해배상액은 손해가 발생하였다고 고객이 주장하는 해당월 직전월까지 고객이 베스핀에 지급한 금액을 그 한도로 한다
  3. 계약당사자는 30일 이상 전에 상대방에 대한 서면 해지통보를 함으로써 본 계약을 해지할 수 있다.

  4. 계약 기간 중 고객의 단순변심 또는 고객의 귀책 사유로 서비스 해지 시 회사는 고객에게 아래의 산식에 의해 산정된 위약벌을 청구할 수 있다.

    위약벌 = 서비스 해지시 까지 고객이 일반요금 대비 본 계약에 의거하여 할인 받은 금액의 총액 (즉 고객의 실제 이용개월 수 X 본 계약상 월별 할인금액)

    상기 위약벌은 본 계약 8조 2항에 명시된 손해배상과는 별도의 금액으로 한다.

제9조(계약의 변경 및 해석)
  1. 본 계약의 효력기간 중에 계약 내용을 변경할 필요가 있는 경우 양 당사자는 상호 서면 합의에 의하여 계약의 내용을 변경할 수 있다.
  2. 양 당사자는 본 계약에서 정하지 아니한 사항에 관한 보충 또는 부속합의서를 체결할 수 있다.
  3. 본 계약의 해석과 관련하여 양 당사자의 의견이 일치하지 아니하거나 본 계약(보충 또는 부속합의서를 포함한다)에서 규정되지 아니한 사항에 대해서는 관련 법률 및 일반 상관례에 따르도록 한다.
제10조(분쟁해결)

본 계약과 관련하여 분쟁이 발생한 경우 상호 협의를 통하여 해결하는 것을 원칙으로 하되, 협의에 의하여 해결되지 아니할 경우에는 베스핀의 주소지 관할법원을 관할법원으로 하여 해결한다.

왜 멀티 클라우드가 필요한가요?

구글 인사이트
by Miyeon. Jo
멀티 클라우드란? (Multi Cloud)

멀티 클라우드는 서로 다른 업체에서 2개 이상의 퍼블릭 클라우드를 이용해 하나의 서비스를 운영하는 것을 말합니다. 퍼블릭 클라우드 시스템 업체를 다르게 하여 이중 구성하는 형태입니다.

1. 멀티클라우드의 필요성

업체 종속성을 피하고, 특정 업체의 클라우드 시스템에 장애가 발생했을 때 서비스에 타격을 주지 않기 위함입니다.

2. 멀티 클라우드의 특징 설명

여러 공급자를 이용한 멀티클라우드는 다양한 기능과 기반 인프라, 보안 및 공급자에 특화된 기타 제안 사항에 접근하는 것을 의미합니다. 이 모두를 함께 연결함으로써 기업과 조직이 모든 공급자에 접근할 수 있으며 각 데이터 활용에 최적화된 장소에 이를 보관할 수 있습니다.

구분특징보완 설명
클라우드 공급자
Lock-in 탈피 측면		기술 의존성 탈피
선택적 서비스 사용		– 다양한 대안 조합
– 라이선스, 구독 형태
클라우드 공급자의
협상 경쟁력 확보		– ROI, 규모의 경제 가능
– 협상을 통한 비용 최소화/절감
클라우드
상호운용성
및 HA 측면		클라우드 서비스 간
상호 운용성 보장		– 표준 기반 호환성 확보
– 클라우드 간 연계 가능
가상머신 스냅샷 기반
상호 백업 체계		– VM 스냅샷 호환성 확보
– 클라우드 고가용성 확보
실시간 컨테이너
마이그레이션 측면		실시간 컨테이너
Live Migration		– 서비스 무중단 컨테이너 이동
– Kubernetes Orchestration
실시간 컨테이너 적용
그로스해킹 최적화		– 멀티 서비스 및 서비스 출시 단축
– A/B Test, Funnel Analysis 적용
클라우드 간 서비스
탄력성 확보 측면		최소 비용 자원 확보로
서비스 탄력성 유지		– 실시간 과금 비용 비교
– 최저 비용 클라우드 선택
클라우드 기반
BCP 체계 구축		– 클라우드 간 백업/복구 체계
– BS25999, RTO/RPO 적용
조직 특성
다양성 보장 측면		셀프 서비스 스토어
최적 도구 사용		– Shadow IT 예방 가능
– 실행 도구 표준화 가능
MSA API 서버 기반
Polyglot 환경 확보		– Cross Compiler 환경 제공
– NoSQL 등 다양한 Infra 환경 지원
3. 멀티 클라우드 구축 시 고려사항

멀티 클라우드를 구축할 때 고려해야 할 사항은 무수히 많지만, 퍼블릭 클라우드는 서비스로 IT 인프라를 이용하는 것이기 때문에 ‘어떤 업체’의 클라우드 서비스를 ‘어떤 방식’으로 이용할 것인지를 결정해야 합니다. 이때 고려해야 할 사항은 다음과 같습니다.

가. 클라우드 연계 관점의 고려사항
구분고려사항달성 방안
분산 APP

서비스 연계 측면

배포 시 개체 위치

최적화/자동화 수행

– URL 기반 경로 최적화 기술 적용

– 최적 액세스 위치 탐색

가상 멀티테넌시

컨테이너 서비스 적용

– 오버레이 네트워크 적용

– Service Orchestration

XaaS 오퍼링

연계 측면

Contents as a Service

기반 서비스 제공

– URI 기반 RESTful API 적용

– 오브젝트 스토리지 사용

I/P/SaaS 연계

서비스 프로비저닝

– 부하/배포/과금 기술 연계

– 씬 프로비저닝 기반 탄력성 확보

나. 멀티 클라우드 보안성 확보 관점의 고려사항
구분고려사항달성 방안
멀티레이어
보안성 확보 측면		기초 계층 데이터
암호화, 인증 적용		– AES, SHA-2, RSA 암호화
– IAM 기반 자원 접근 통제
응용 계층 가상화
NFV 보안 기능 적용		– SECaaS 기반 CASB 연계
– vFDS  등 VNF 기반 보안 기능 가상화
데이터 보호 및
흐름 가시화 측면		데이터 중요도 별
Access 가능자 분리		– Data 접근 원천 봉쇄
– Bell-LaPadula 모델 적용
능동형 URL 기반
감시 가시화 적용		– APP 접근하는 URI 경로 감시
– 가상화 DPI 기반 페이로드 분석
4. 멀티 클라우드 서비스 동향 및 향후 전망
가. 멀티 클라우드 서비스 최근 동향
  • 최근 글로벌 클라우드 서비스의 리전 장애로 단일 클라우드의 백업 부재, 신뢰성, 기술적 의존성(Lock-in) 등 단일 클라우드 사용 시 문제점 부각되고 있습니다.
  • 글로벌 클라우드 공급자와 지역 클라우드 공급자 간 상호 백업 등 클라우드 서비스 간 상호 연계한 멀티 클라우드 서비스 활성화가 되고 있습니다.
나. 멀티 클라우드 서비스 향후 전망
  • 데이터 흐름 가시성 확보의 어려움으로 인해 정보 침해 등 보안 사고 시 피해 최소화 여부가 멀티 클라우드 서비스 활성화를 결정할 것으로 전망 되어 집니다.

출처

금융위원회 ‘금융분야 클라우드 및 망분리 규제 개선방안’ 발표

구글 인사이트
by Miyeon. Jo

금융위원회는 2022. 4. 14. 보도자료를 배포하여 그 동안 금융회사 또는 전자금융업자(이하 “금융회사 등”)가 디지털 신기술을 도입·활용하는 데 어려움으로 작용했던 클라우드 및 망분리 규제에 대한 개선방안(이하 “본 개선방안”)을 밝혔습니다.

본 개선방안에 따라 그 동안 금융혁신을 저해한다고 평가되었던 클라우드 및 망분리 규제가 상당 부분 완화될 것으로 예상되는바, 본 개선방안의 주요 내용 및 금융회사 등이나 클라우드서비스제공자(Cloud Service Provider, 이하 “CSP”)의 실무에 미칠 영향을 구체적으로 살펴보면 다음과 같습니다.

■ 클라우드 규제 개선
1. 클라우드 이용 업무에 대한 중요도 평가기준 명확화

현행 규정상 클라우드를 이용하는 경우 금융회사 등은 클라우드를 통하여 “개인신용정보/고유식별정보를 처리하는 경우” 또는 클라우드 이용이 “전자금융거래의 안전성 및 신뢰성에 중대한 영향을 미치는 경우”(이하 클라우드가 위 두 경우 중 어느 하나에 해당하는 경우를 “중요 시스템”이라 하며, 그 외의 경우를 “비중요 시스템”이라 함)에는 금융감독원 보고의무 등 엄격한 클라우드 이용절차를 거쳐야 합니다. 그런데 “전자금융거래의 안전성 및 신뢰성에 중대한 영향을 미치는 경우”에 해당하는지 여부의 판단을 위한 중요도 평가기준이 명확하지 않아 금융회사가 중요 시스템을 비중요 시스템으로 잘못 판단하고 클라우드를 이용하여 향후 제재를 받을 리스크가 있었습니다.

금융위원회는 본 개선방안에서 중요도 평가기준을 구체적으로 마련하겠다고 하였는바, 향후 클라우드 이용절차가 더욱 명확해져 금융회사 등은 중요 시스템 여부를 잘못 판단함으로 인한 제재 리스크가 감소될 수 있고, 비중요 시스템임에도 불필요한 보고의무를 이행하는 사례가 줄어들 수 있을 것으로 예상됩니다.

2. 업무 중요도에 따른 클라우드 이용절차 차등화

현행 규정상, 클라우드 이용 대상 정보처리시스템이 비중요 시스템으로 판단되어도 클라우드 이용보고가 필요 없게 된다는 점 외에는 클라우드 이용절차 및 준비 서류가 중요 시스템인 경우와 동일합니다(전자금융감독규정 제14조의2제1항, 제2항, 제5항).

본 개선방안을 통하여, 비중요 시스템일 경우 업무 연속성 계획, 안전성 확보조치 관련 별도의 기준이 제시되는 등 클라우드 이용 시 절차적 차이점이 명확해질 것으로 예상됩니다.

3. 클라우드 이용 시 사전보고를 사후보고로 전환 및 서류 간소화

현행 규정에 따르면, 중요 시스템을 클라우드로 이용할 경우 7영업일 이전에 금융감독원에 보고하여야 하는데, 이러한 사전보고 과정이 원활하게 진행되지 않아 클라우드 도입이 지연되는 문제점이 있었습니다.

본 개선방안을 통하여, 사전보고가 3개월 이내 사후보고로 전환되면 클라우드 이용에 적시성을 확보할 수 있게 될 것으로 기대됩니다. 아울러, 클라우드 이용보고 시 제출해야 하는 서류에 있어서도 유사·중복되는 사항을 간소화할 예정이므로 서류 작성 및 제출 부담도 완화될 것으로 예상됩니다.

4. CSP 평가항목 축소

현행 클라우드 이용절차 중 가장 큰 부담으로 작용하고 있던 CSP 건전성·안전성 평가(이하 “CSP평가”) 항목이 총 141개에서 54개(필수항목 16개+대체항목 38개)*로 대폭 간소화될 예정입니다. 불필요하거나 과도한 평가항목이 간소화됨으로써 평가가 보다 합리적·효율적으로 진행될 것으로 예상됩니다.

* 간소화된 평가항목 54개 중에서도 국내·외 보안인증(CSAP 등)을 취득한 CSP의 경우 인증 시 평가받은 평가항목을 제외한 항목만을 평가 가능하며, 현재에도 기본보호조치항목(109개)은 국내·외 보안인증(CSAP 등)을 취득·유지하고 있는 CSP의 해당서비스에 대해서는 기본보호조치 항목 평가 생략이 가능합니다.

5. SaaS 형태의 클라우드 서비스에 대한 별도 평가기준 마련

현재의 CSP 평가항목은 서버·저장장치 등을 이용하는 형태의 클라우드 서비스(IaaS)를 기준으로 마련되어 있어, 소프트웨어 형태의 클라우드 서비스(Software-as-a-Service, 이하 “SaaS”)의 CSP를 평가하기에는 적합하지 않은 측면이 있고, 잘못된 기준 설정은 부적합한 평가로 이어질 수 있다는 문제점이 제기되어 왔습니다.

금융위원회는 SaaS에 대하여서는 클라우드 서비스 보안인증제(CSAP)와 유사하게 별도 평가 기준을 마련하겠다고 밝혔는바, 평가 기준의 정비를 통하여 합리적인 평가가 진행될 수 있을 것으로 예상됩니다.

6. 대표평가제 도입

현행 규정상, 클라우드를 이용하는 금융회사 별로 CSP 평가를 수행하여야 하는 평가절차의 중복 문제를 개선하기 위해 2021. 6월부터는 동일한 CSP를 통해 클라우드를 이용하려는 금융회사 중 대표 금융회사를 선정하여, 대표 금융회사가 CSP평가를 주도하고 금융보안원이 지원하는 방식(합동평가제)이 실무상 이용되고 있습니다.

본 개선방안을 통하여, 전문 평가기관인 금융보안원이 주도하여 CSP를 평가하고 각 금융회사는 금융보안원의 평가결과를 활용할 수 있도록 하는 방식(대표평가제)이 도입될 예정으로, 금융회사 등의 CSP평가 부담이 크게 줄어들게 될 것으로 예상됩니다.

■ 망분리 규제 개선
1. 개발·테스트 분야에 대한 망분리 규제 예외 적용

다양한 신기술 및 오픈소스 등을 이용한 개발을 위해서는 인터넷 연결이 필수적이나, 현행 망분리 규제 하에서는 이러한 연결에 제한이 있어 금융회사 등의 혁신 서비스 개발에 저해가 되고 있습니다.

전자금융감독규정의 개정을 통하여, 개인신용정보 등이 저장되지 않고 전자금융거래의 중요성이 낮은 개발·테스트 서버에 대해서는 물리적 망분리 규제가 완화될 예정인바, 금융회사 등은 망분리 규제로 인해 이용이 어려웠던 신기술 및 오픈소스 등을 효율적으로 이용할 수 있게 될 것으로 예상됩니다. 다만, 개발·테스트 서버에 고객의 개인신용정보 또는 거래정보 등의 활용 금지, 오픈소스 접속·활용에 대한 내부기준 수립·이행 의무화 등 보완조치도 함께 마련될 예정인바, 이러한 망분리 규제 완화에 따른 보완조치를 준수하여야 한다는 점은 유의하시기 바랍니다.

2. 비금융업무 및 SaaS에 대한 망분리 예외조치 적용

금융회사 등이 인사관리 등 후선업무에 서비스로서의 소프트웨어(SaaS)를 이용하려는 경우에도 망분리 규제가 적용되는데, SaaS는 인터넷 구간에 위치하는 경우가 많아 망분리 예외가 적용되는 경우에만 사용이 가능하였습니다.

본 개선방안에서는 규제 샌드박스를 활용하여 비금융업무 및 SaaS에 대한 망분리 규제 예외를 허용하겠다고 밝혔는바, 규제 샌드박스를 통하여 SaaS의 이용이 좀 더 활성화될 수 있을 것으로 예상됩니다. 다만, 규제 샌드박스를 통하여 허용되는 SaaS의 종류, SaaS 접속 방안 등은 규제 샌드박스 심사 결과에 따라 달라질 수 있어 향후 사례들을 지켜 보아야 할 것으로 보입니다.

3. 단계적 망분리 규제 완화 추진

금융위원회는 중장기적으로 보안 리스크에 대비하여 금융회사의 책임성 확보, 금융보안원의 보안관제 강화 등 대체방안을 전제로, 망분리 대상 업무를 축소하고, 금융회사가 업무에 따라 물리적·논리적 망분리를 선택할 수 있도록 하는 방식도 고려하는 등 망분리 규제를 단계적으로 완화 및 개선할 계획이라는 점을 밝혔습니다.

향후 금융회사는 회사의 특성 및 업무의 중요도에 따라 망분리 규제 적용 방식을 선택할 수 있을 것으로 전망되고, 이에 따라 효율적인 내부통제 운영이 가능할 것으로 예상됩니다. 이에 대하여서는 향후 법령 및 규정의 개정 과정을 유의하여 살펴보아야 할 것으로 생각됩니다./p>

■ 향후 계획

금융위원회는 본 개선방안이 제도적으로 안착될 수 있도록 2022. 4월 중 이번 발표의 내용을 반영한 ‘전자금융거래법 시행령 및 감독규정 개정안’을 입법예고하고, 금융보안원이 2019. 1월 배포한 ‘금융분야 클라우드컴퓨팅서비스 이용 가이드’도 2022년 말까지 개정하여 전 금융권이 실무적으로 참고할 수 있는 구체적인 절차 및 기준을 마련할 계획입니다.

■ 시사점

본 개선방안은 그동안 금융분야에서 적극적인 디지털 신기술 도입·활용을 가로막던 클라우드 및 망분리 규제에 대한 완화의 초석을 마련하였다는 측면에서 의미가 있습니다. 특히 개발·테스트 분야에서 신기술 도입이 활성화될 것으로 예상되며, 그 외에도 클라우드 이용에 관한 절차의 완화를 통하여 금융회사등의 클라우드 도입에 대한 부담이 경감될 것으로 예상됩니다. 금융위원회는 단계적으로 제도 개선을 추진할 예정이라고 그 기본 방향을 밝혔는바, 올 4월 ‘전자금융거래법 시행령 및 감독규정’ 개정뿐만 아니라 향후 법령 및 규정의 개정 과정을 지속적으로 모니터링 할 필요가 있습니다.

한편, 비금융업무 및 SaaS에 대한 망분리 규제는 법령 및 규제의 개정 방법을 취하지 않고, 규제 샌드박스를 활용하여 실질적인 규제 완화가 이루어질 예정이므로 규제 샌드박스의 개별 지정 사례에 대해서도 지속적으로 유의 깊게 살펴 볼 필요가 있습니다.

출처

Load More Posts
문의하기 베스픽 구독하기
궁금한 점이 있다면 클릭해주세요.