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

Miyeon. Jo

GCP 리소스 모니터링 설정

구글 인사이트
by Miyeon. Jo
목차
  1. Cloud Monitoring 개요
  2. Cloud Monitoring 구성
  3. 대시보드 및 차트 구성
  4. 알림 구성
1. Cloud Monitoring 개요

Cloud Monitoring은 Google Cloud, Amazon Web Services(AWS), 애플리케이션, 이벤트, 메타데이터 등의 메트릭을 수집합니다. 이러한 데이터로 대시보드, 차트, 알림을 통해 필요 자원에 대한 예측과 향후 개선을 위한 사후 검토를 진행할 수 있습니다.
이 글에서는 여러 Google Cloud 프로젝트에 대해 모니터링하는 구성 방법과 저장된 측정항목에 대한 대시보드 및 알림 구성하는 방법에 대해 알아보도록 하겠습니다.

2. Cloud Monitoring 구성

Monitoring의 Metric Scope 구성하여 프로젝트의 메트릭을 개별적으로 확인할 수 있으며 다른 프로젝트에 저장된 메트릭과 함께 볼 수 있습니다.
구성은 4가지의 방법1으로 메트릭을 보고 관리할 수 있는데 그 중 ①, ②번의 Metric Scope를 통해 Cloud Monitoring을 구성하는 방법에 설명하도록 하겠습니다.

① 단일 프로젝트

[이미지 1]

새로운 Project A 를 생성하면 해당 프로젝트는 자동으로 Metric Scope가 설정되고 해당 프로젝트의 메트릭만 볼 수 있습니다.

② 단일 조직 내 여러 프로젝트

[이미지 2]

여러 프로젝트에 대한 모니터링을 한 곳에서 통합 관리할 수 있는 방법으로 Project a-host, a-ingest, a-data 를 Metric Scope에 액세스하면 Scoping Project에서 프로젝트 세 개 모두의 메트릭을 볼 수 있습니다.

  • 구성방법
    GCP Console > Monitoring > Settings > ADD GCP PROJECT 클릭

[이미지 3]

프로젝트 리스트 중 모니터링 할 프로젝트 a-data, a-ingest 선택합니다.

  • 설정된 프로젝트 확인

[이미지 4]

Metrics monitored by this project 의 표에는 Metric Scope를 구성한 프로젝트 리스트와 역할을 확인할 수 있습니다.

  • Scoping Project : 여러 프로젝트에 대한 모니터링을 한 곳에서 통합 관리하는 프로젝트입니다.
  • Monitored Project : 모니터링 하고자 하는 프로젝트입니다.
3. 대시보드 및 차트 구성

대시보드는 사용자에게 중요한 메트릭 데이터를 보고 분석할 수 있습니다.
Cloud Monitoring은 ①사전 정의된 대시보드와 ②커스텀 대시보드를 제공하고 있습니다.

① 사전 정의된 대시보드

GCP Console > Monitoring > Overview

[이미지 5]

사전 정의된 대시보드는 Cloud Monitoring에 의해 프로젝트에서 사용하는 리소스에 따라 자동으로 생성되어지는 대시보드입니다.
사전 정의된 대시보드의 경우 차트 구성 및 기간 수정이 가능하지만, 차트 삭제 또는 메트릭을 변경할 수는 없습니다.
위 [이미지 5]의 대시보드는 3개의 프로젝트를 Metric Scope로 구성하여 각 프로젝트에서 사용 중인 리소스들을 포함해 자동으로 생성되었습니다.

② 커스텀 대시보드

GCP Console > Monitoring > Dashboards > CREATE DASHBOARD

[이미지 6]

커스텀 대시보드는 사용자가 관심 있는 정보를 원하는 방식으로 구성할 수 있는 대시보드입니다. Cloud Console 또는 Cloud Monitoring API를 사용하여 커스텀 대시보드를 생성할 수 있습니다.

[이미지 7]

Cloud Console 화면에서 커스텀 대시보드를 생성하는 경우 [이미지 7]이 보이게 되는데 BASIC / ADVANCED / MQL 방법으로데이터를 차트에 지정할 수 있습니다.

  • BASIC 모드는 대시보드를 구성하는 기본 모드로 사용자가 차트를 쉽고 빠르게 구성할 수 있도록 최소한의 구성옵션을 제공합니다.
  • ADVANCED 모드는 모든 위젯 구성 필드에 액세스하여 대시보드를 생성 할 수 있으며 이 모드는 대부분의 집계 필드에 대한 액세스를 제공합니다.
  • MQL(Monitoring Query Language) 모드는 쿼리 언어를 사용하여 차트를 구성 할 수 있는 모드로 표현형 텍스트 기반 인터페이스를 제공합니다.

[이미지 8] 커스텀 대시보드 ADVANCED 모드로 구성한 대시보드 화면입니다.

4. 알림 구성

알림을 통해 리소스 및 클라우드 애플리케이션의 문제를 적시에 파악하여 문제를 신속하게 해결할 수 있습니다.
Cloud Console, Cloud Monitoring API, Cloud SDK를 사용하여 알림 정책을 추가할 수 있습니다.

  • 구성방법
    Console > Monitoring > Alerting > CREATE POLICY
    ADD CONDITION 버튼을 클릭하여 알림을 설정할 조건을 추가합니다.

[이미지 9]

[이미지 10]

[이미지 11]

조건은 모니터링 리소스, 리소스 측정항목, 조건이 충족되는 시기를 나타냅니다.
[이미지 10] 은 특정 Project에서 Composer DAG 파일을 파싱하는 동안 발생한 오류에 대해 타겟 설정을 합니다.
[이미지 11] 는 설정한 타겟에 대해 알림이 트리거되는 조건을 설정합니다.

[이미지 12]

(선택사항) 구성한 알림 조건으로 여러 채널을 통해 알림을 받을 수 있습니다.
Mobile Devices (Cloud Mobile App), Slack, Webhooks, Email, SMS 등 다양한 채널 선택이 가능합니다. 알림에 대한 이름 설정 후 SAVE 버튼을 클릭하면 알림 설정은 완료됩니다.

  • 1 ① 단일 프로젝트 ② 단일 조직 내 여러 프로젝트 ③ 여러 조직의 여러 프로젝트 ④ 다중 Google Cloud 프로젝트 및 AWS 계정

출처 및 참고사이트

딜리셔스(신상마켓)

by Miyeon. Jo

딜리셔스(신상마켓)

“동대문 도소매 거래를 연결해주는 ‘신상마켓’ 서비스 특성상 야간 시간대 트래픽이 급증하는 패턴을 나타냈습니다. AWS를 사용하면서 서비스 장애 고민이 줄어들고, 트래픽이 급증하는 시간 대에도 효과적인 대응이 가능해졌습니다.”
“베스핀은글로벌은 신상마켓에 필요할 서비스와 솔루션을 미리 제안했고, 안정적인 클라우드 서비스 구축을 도왔습니다.”

– 딜리셔스 조웅 데이터 엔지니어님

Company Overview

딜리셔스는 패션 도소매 거래 No.1 플랫폼인 ‘신상마켓’ 운영 기업입니다. 패션 도소매 사업자들이 사업을 쉽고 즐겁게 할 수 있도록 IT 서비스와 기술력을 전달하고 있습니다. 최근 동대문 소매 사업자의 물류를 일괄 대행하는 풀필먼트 서비스인 ‘딜리버드’를 런칭했습니다.

Challenge

2019년 이전에는 국내 클라우드 서비스를 사용하고 있었습니다. 하지만 관리형 서비스의 발전 속도, 클라우드 안정성 측면에서 불만족스러웠습니다. 동대문 도소매 거래를 연결하는 서비스 특성상 야간 시간대 트래픽이 급증하는 편입니다. 이전 클라우드 환경에서는 트래픽 급증 시 서비스 장애가 많아 개선이 필요했습니다. 고객이 지속적으로 늘고 있기 때문에 트래픽 피크에 효과적으로 대응할 필요가 있었습니다.

Solution

딜리셔스는 2019년 상반기 본격적으로 AWS를 도입해 2020년에 신상마켓의 모든 인프라를 AWS로 이전했습니다. AWS가 전세계적으로 널리 도입된 클라우드 플랫폼이며, 서버와 스토리지를 비롯해 머신러닝, 인공지능까지 175개가 넘는 서비스를 제공하고 있어 선택했습니다. 딜리셔스는 AWS 이전 후, 가용성과 확장성을 강화해 비용까지 절감했습니다. 이제 특정 시간에 집중되는 트래픽 피크에도 문제 없이 서비스를 지속할 수 있게 되었습니다.

딜리셔스는 2019년 상반기 본격적으로 AWS를 도입해 2020년에 신상마켓의 모든 인프라를 AWS로 이전했습니다. AWS가 전세계적으로 널리 도입된 클라우드 플랫폼이며, 서버와 스토리지를 비롯해 머신러닝, 인공지능까지 175개가 넘는 서비스를 제공하고 있어 선택했습니다.
딜리셔스는 AWS 이전 후, 가용성과 확장성을 강화해 비용까지 절감했습니다. 이제 특정 시간에 집중되는 트래픽 피크에도 문제 없이 서비스를 지속할 수 있게 되었습니다.

Benefit

AWS 도입 후, 서비스 환경에 따라 다양한 인스턴스 및 관리형 서비스를 사용하게 되면서 개발 생산성이 매우 높아졌습니다. AWS에서 새로운 기술과 서비스가 나오면 더 좋은 성능의 서비스를 합리적인 가격에 사용할 수 있는 기회가 많아진 것에 만족합니다. 이제 딜리셔스에서는 서비스 개발 시 인프라는 AWS를 기준으로 하며, AWS에 새로운 서비스가 나올 때마다 고도화 및 최적화 하는 방법을 자연스럽게 고민하고 있습니다.

Next Step

딜리셔스의 ‘신상마켓’ 서비스 내 AWS 머신러닝 관련 기술을 도입해 활용할 계획입니다. 특히 컴퓨팅, AI, 데이터플랫폼의 사용 경험을 풍부하게 쌓을 계획입니다.

베스핀글로벌의 Market Overview

베스핀글로벌의 Market Overview : 온라인 커머스 시장 성장이 심상치 않습니다. 신상마켓은 2020년 주문액이 전년보다 25.8% 성장한 4,180억원을 기록했으며, 누적 주문액은 작년 말 기준 1조 3,000억원을 넘어섰습니다. 코로나 19로 비대면 거래가 증가하면서 의류 소비도 방식이 변화하고 있기 때문인데요. 여기에 라이브 커머스 시장까지 급성장하면서 신상마켓과 같은 B2B2C 패션 의류 서비스 성장은 계속 진행될 것으로 보여집니다.
이 모든 것이 오프라인이 아닌 온라인, 모바일 앱에서 돌아가는 세상에 기술력이 매우 중요하겠죠. 서비스는 끊기지 않아야 하고, 매출과 직결되는 부분에는 한치의 오류가 있어서도 안됩니다. 딜리셔스 개발팀에서는 모바일/웹 어플리케이션 개발 및 AWS 기반 데이터 플랫폼 구축, AI/ML 기술 개발을 진행하고 있으며, 향후 기술 고도화를 통한 서비스 확장을 위해 개발 전 분야에 걸쳐 능력있는 개발자를 계속 채용하고 있습니다.

실업급여 신청 포털 및 코로나19 백신 접종 포털 보호에 사용된 reCAPTCHA Enterprise

구글 인사이트
by Miyeon. Jo

코로나19 팬데믹으로 인해 그 어느 때보다 많은 사람들이 생활 속에서 온라인으로 처리하는 업무의 비중을 늘리고 있습니다. 사기범에게는 새로운 공격 방법을 만들어 실행할 수 있는 새로운 장이 펼쳐진 셈입니다. Forrester Consulting에서 의뢰한 조사에 따르면 기업의 84%가 봇 공격이 증가한 것을 경험했으며 조직의 71%에서는 실제 공격을 당한 횟수가 증가한 것으로 나타났습니다. 기업의 65%는 공격 빈도 증가와 봇 공격에 따른 수익 손실 확대를 경험했습니다. 코로나19 백신에 대한 정보, 백신 접종 예약, 실업급여 접수를 위해 정부 웹사이트를 찾는 사람들이 증가하면서 관련 웹페이지는 봇 공격 및 기타 악의적인 활동의 주요 표적이 되었습니다. 하지만 reCAPTCHA Enterprise의 도움 덕분에 주 정부는 코로나19 백신 등록 포털과 실업급여 신청 포털을 악의적인 활동으로부터 보호하고 있습니다.

코로나19 기간 중 실업급여 신청 지원

코로나19의 여파로 실업급여 신청이 크게 증가하면서, 위스콘신주의 노동청을 비롯한 많은 주 정부 기관에서 외부 웹사이트에 대한 악의적인 봇 로그인 시도가 증가하는 것을 확인했습니다. 많은 주에서 악의적인 행위자가 실업급여 신청 포털에 훔친 사용자 인증 정보를 입력해 허위로 실업급여 신청을 접수하는 일이 발생했습니다. 다수의 실업급여 신청 포털이 의무적으로 2주 안에 실업급여를 지급해야 했기 때문에 신청 포털에서 허위 정보가 처리되어 악의적인 행위자가 실업급여 수표를 지급받더라도 그 사실이 몇 주 후에야 발견되곤 했습니다. 이미 그때는 사기범들이 수표를 현금화하고, 훔친 다른 사용자 인증 정보로 이 절차를 반복적으로 악용한 상황이었습니다.

reCAPTCHA Enterprise는 주 정부를 도와 실업급여 신청 포털에서 사용자 인증 정보가 자동으로 재사용되지 않도록 방지하여 허위 신청 건수를 줄였습니다. 대규모로 신속하게 인터넷 사기 행위를 판단하는 reCAPTCHA Enterprise는 텍사스를 비롯해 미국에서 가장 큰 주에 도움이 되었습니다.

코로나19 백신 접종 등록 및 주 정부 보조 재원 이용

펜실베니아를 비롯한 여러 주는 코로나19 백신 접종 단계에 따라 웹 트래픽이 요동치는 어려움을 겪었습니다. 예를 들어 1차 접종 시기에는 극히 적은 백신 접종분에 대한 수요가 몰리면서 사람과 봇에서 발생한 웹 트래픽이 크게 증가했습니다. 2차와 3차 접종이 진행되는 주가 증가하고 백신이 더 널리 보급된 지금은 백신 접종 등록을 위해 백신 관련 웹사이트의 방문자가 증가한다는 사실을 눈치챈 악의적인 행위자 때문에 트래픽이 증가하고 있습니다.

악의적인 행위자가 백신 접종을 예약한 후 다른 웹사이트에서 이 예약분을 판매해 영리를 취하는 봇 스크립팅을 방지하기 위해 reCAPTCHA Enterprise가 구현되었습니다. 이러한 허위 웹페이지는 사람들이 백신을 등록할 수 있는 웹사이트로 잘못 홍보되었습니다. 사기범들은 백신 접종 예약뿐 아니라 다른 정부 시스템에서도 부당 이득을 취하려고 합니다. 교통부와 복지부 역시 해당 조직에서 제공하는 서비스의 예약건을 판매하여 이득을 취하려고 시도하는 사기범의 공격을 자주 받는 기관입니다.

reCAPTCHA Enterprise 덕분에 사기범의 공격을 보다 쉽게 차단할 수 있게 되었습니다. 이 원활한 사기 감지 서비스에는 500만 개가 넘는 사이트로 구성된 Google 네트워크의 데이터와 인터넷을 십년 넘게 보호한 Google의 경험이 활용되었습니다. reCAPTCHA Enterprise 플랫폼은 사기 행위를 이해하고, 봇의 예약을 막는 장애를 일으키며, 정당한 사용자의 백신 포털 및 기타 주 포털 액세스를 허용합니다.

reCAPTCHA Enterprise에서는 최종 사용자가 보안문자를 입력할 필요가 없기 때문에 많은 주 정부에서 검색, 로그인, 등록 웹페이지 등에 reCAPTCHA Enterprise를 설치했습니다. 또한 주 정부는 최종 사용자가 의료 서비스를 이용하거나, 주택 또는 식료품 보조금을 받거나, 차량을 등록하거나, 입법을 제안할 수 있는 웹페이지에도 reCAPTCHA Enterprise를 도입하고 있습니다. reCAPTCHA Enterprise가 설치된 페이지가 증가하면서 악성 소프트웨어나 봇이 다양한 페이지에 침투하기가 더욱 어렵게 되었지만 최종 사용자는 변함없이 탐색, 계정 로그인, 예약, 재원 신청 같은 작업을 수행할 수 있습니다. reCAPTCHA Enterprise는 최종 사용자에게 사기 방지를 위한 어떠한 조치도 요구하지 않기 때문에 주 정부는 웹페이지의 모든 상호작용 지점에 reCAPTCHA Enterprise를 도입하여 사용자 경험에 영향을 주지 않으면서도 보안 수준을 최대로 높였습니다.

전국적인 보안 제공 및 맞춤 가격 책정

많은 주 정부가 종량제 모델로 클라우드 서비스를 구입하는 데 익숙합니다. reCAPTCHA Enterprise 역시 주 정부에 예측, 확장, 맞춤설정이 가능한 가격 책정 방식을 제공해 구매 프로세스를 쉽게 만들었습니다. 주 정부는 reCAPTCHA Enterprise에서 수행하는 평가 횟수에 따라 매월 예상되는 지출액을 사전에 알 수 있습니다. reCAPTCHA Enterprise의 유연한 가격 책정 모델은 백신 접종 등록 및 실업급여 신청을 원하는 방문객의 자연적인 증감에 보조를 맞추고 있습니다. reCAPTCHA Enterprise의 전담 영업팀은 웹페이지 보안과 예산 중 어느 하나도 아쉬움이 없도록 구체적인 사용 사례에 맞게 가격 책정을 조정해 드릴 수 있습니다.

reCAPTCHA Enterprise는 많은 주에서 백신 접종과 실업급여 수령을 더욱 쉽게 만들어 주 정부의 대민 서비스 품질을 높이는 데 도움을 주었습니다. 주민의 공공 서비스 이용에 도움을 주는 한편 공공 서비스를 악용하고 방해하려는 사기 행위는 더욱 어렵게 만들고 있습니다.
사용자 인증 정보 반복 입력을 비롯한 공격으로부터 웹페이지를 보호하기 시작하려면 오늘 바로 reCAPTCHA Enterprise를 시작하세요.

출처 및 참고사이트

TWC (더화이트커뮤니케이션)

by Miyeon. Jo

TWC (더화이트커뮤니케이션)

“Google Cloud의 장점은 AI 서비스에 활용할 제품이 다양하다는 것인데요. 우리 솔루션에 음성인식 API가 필요했던 상황에 찰떡같이 딱 맞는 클라우드 플랫폼이었습니다.”
“인스턴스 수백대가 생성되어 과도한 비용이 청구되는 이슈가 있었습니다. 베스핀글로벌이 구글 클라우드와의 사이에서 잘 해결할 수 있도록 도와주었어요. 클라우드 파트너로서 고마움을 느끼고 신뢰를 쌓는 계기가 되었습니다. 이후 모니터링 교육 및 AlertNow 도입으로 재발 방지까지 마련해주었습니다.”

– TWC 조영준 CTO님

Company Overview

TWC는 ‘Save Time’이라는 슬로건으로 고객이 자사 서비스 운영 오퍼레이션에 시간을 쏟는 대신 본업에 더욱 집중할 수 있도록 돕는 일을 합니다. 서비스 운영에 필요한 인력 아웃소싱과 응대에 필요한 AI 기반의 옴니채널 고객 응대 솔루션을 제공하는 기업입니다.

Challenge

솔루션 개발 시점부터 클라우드 기반 SaaS 서비스를 만들고자 했습니다. 스타트업에서 서버를 직접 구매해 관리하는 인력과 비용이 만만치 않았고, 궁극적으로 고객 응대 데이터를 수집해 효율성을 높이고자 하는 것이었습니다. 특히 데이터 중에서도 음성인식에 대한 니즈가 있어 음성인식 API를 제공해주는 플랫폼 모두를 테스트 했습니다. 클라우드로 가기로 했지만 어떤 플랫폼을 선택해야 할지 고민이 많았습니다.

Solution

TWC는 SaaS 기반의 고객응대 솔루션을 퍼블릭 클라우드, Google Cloud 기반에서 안정적으로 구축했습니다. 클라우드 도입을 통해 인프라 구축과 운영을 합리적인 비용에 할 수 있었으며, 가변적인 클라이언트의 트래픽에 유연하게 대응하고 있습니다.

딜리셔스는 2019년 상반기 본격적으로 AWS를 도입해 2020년에 신상마켓의 모든 인프라를 AWS로 이전했습니다. AWS가 전세계적으로 널리 도입된 클라우드 플랫폼이며, 서버와 스토리지를 비롯해 머신러닝, 인공지능까지 175개가 넘는 서비스를 제공하고 있어 선택했습니다.
딜리셔스는 AWS 이전 후, 가용성과 확장성을 강화해 비용까지 절감했습니다. 이제 특정 시간에 집중되는 트래픽 피크에도 문제 없이 서비스를 지속할 수 있게 되었습니다.

이후 재발 방지를 위해 클라우드 모니터링 방법을 교육했고, 인프라 내 이슈 발생 시 빠르게 확인할 수 있도록 하는 AlertNow(링크) 제품도 활용하고 있습니다.

Benefit

1~2명만으로도 충분히 안정적인 서비스를 할 수 있게 되었습니다. 인프라 구축을 위해 서버를 구입하고 구축, 관리하는 비용을 계산한다면 경제적이기도 합니다. 이는 사람과 비용에 제한이 있는 스타트업에서 IT 인프라를 관리하는 가장 적합한 방식입니다.

Next Step

TWC는 계속 Google Cloud를 활용하며 서비스를 확장해 나갈 것입니다. 또한 개인정보 및 보안이 민감한 사용자들을 위한 엔터프라이즈형 프라이빗 클라우드 구축을 고려하고 있습니다.

Market Overview

베스핀글로벌의 Market Overview : 코로나로 인해 비대면 서비스가 성장하고 있습니다. 그리고 고객들은 자신들의 서비스에 더욱 집중하기 위해 고객 센터나 컨텍 센터를 외부 전문가들에게 맡기고 있는 추세이기도 합니다. 국내 컨택센터 시장은 약 8조9000억원 규모로 23만여 명이 종사하고 있습니다. 금융, 보험, 은행 등 많은 기업은 현재 전화 및 채팅 상담으로 CS 업무를 처리하고 있습니다. 차세대 CS 업무 처리 솔루션으로 TWC처럼 AI를 활용한 SaaS 기업이 늘고 있는데요. 주로 고객의 소리 음성 데이터를 텍스트로 변환하고, 텍스트를 머신러닝으로 돌려 자동응답시스템을 만들어 고객사의 업무 효율을 늘리고 매출 증대를 돕는 역할을 합니다. TWC는 성장 가능성이 높은 시장에 뛰어들어 AI와 클라우드를 활용해 서비스를 강화하고 있습니다.

조직의 Cloud Logging 권장 사항

구글 인사이트
by Miyeon. Jo
목차
  1. 개요
  2. 로그의 종류와 이해
  3. 로그 버킷
  4. 로그 라우터
  5. 조직을 위한 Aggregated Sink
  6. 로그 관리 유의 사항
1. 개요

기업은 조직의 각종 규정 준수 요구 사항을 충족하고, 감사 대응을 위해 다양한 종류의 로그를 생성하며 이를 보관 및 관리하여야만 합니다. GCP는 이러한 요구사항을 충족시키기 위하여 Cloud Logging에서 발생하는 로그를 기업의 요구 사항에 맞게 관리할 수 있는 방안을 지원하고 있습니다. 이 글에서는 기업의 규정 준수 요구사항을 충족하기 위한 Cloud Logging에 대한 이해와 이를 위한 자세한 방법을 다루어 보도록 하겠습니다.

2. 로그의 종류와 이해

로그의 종류는 크게 Audit로그와 그 외의 일반로그로 분류되며, Audit 로그는 각종 감사 요구사항에 필수적으로 활용되는 기본적인 로그입니다.
또한 Audit 로그는 내용에 따라 세부적인 분류로 나뉩니다.

  • Admin Activity Audit 로그
    클라우드 플랫폼 상에서 일어나는 구성변경, 접근 이력 등을 의미하는 로그로, 구글 API 호출 관련 로그 항목, 리소스의 구성 또는 메타데이터를 수정하는 작업 이력 등을 포함합니다. 해당로그는 아래의 Cloud Logging Filter를 이용하여 조회되는 항목입니다.

    logName=projects/[PROJECT | FOLDER | ORGANIGATION_ID]
    /logs/cloudaudit.googleapis.com%2Factivity

  • System Event Audit 로그는 리소스 구성을 수정하는 Google Cloud 작업의 로그 항목으로 Google 시스템에서 생성됩니다. GCE의 Live Migration 로그와 구글 인프라 상에서 발생하는 인스턴스의 시스템 이벤 로그 등이 이에 해당됩니다.

    logName=projects/[PROJECT | FOLDER |
    ORGANIGATION_ID]/logs/cloudaudit.googleapis.com%2Fsystem_event

  • Data Access Audit 로그는 Google API와 GCP 리소스에 대한 접근/변경 이력에 대한 로그 정보를 포함하고 있습니다.

    logName=projects/[PROJECT | FOLDER |
    ORGANIGATION_ID]/logs/cloudaudit.googleapis.com%2Fdata_access

    또한 Data Access Audit 로그는 다시 아래와 같은 종류의 로그로 구분됩니다.

    • Admin Read : GCP 리소스에 대한 메타데이터 또는 구성 정보 Read 기록, 비활성화 불가능
    • Data Read
    • Data Write

    Data Access Audit 로그는 요구 사항에 따라 IAM & Admin 콘솔에서 서비스 별로 Data Access Audit 로그의 활성/비활성을 설정할 수 있습니다.

3. 로그 버킷

로그 버킷은 Cloud Logging으로 전송된 로그들을 위한 별도 저장소입니다. 로그 버킷은 프로젝트 별로 기본적으로 생성되며 이를 위한 기본 Sink 정책이 자동적으로 구성됩니다. 사용자는 조직의 요구 조건에 따라 별도의 로그 버킷을 생성하여 사용자 정의 보관 정책등을 구성할 수 있습니다.

  • 로그 버킷의 종류
    • _Required
      • Admin Activity Audit, System Event Audit, Access Transparency 로그
      • 무료 로그, 400일 동안 보관, 보관기간 및 삭제 불가능
    • _Default
      • _Required 저장 로그를 제외한 모든 수집 로그 저장
      • 표준 Cloud Logging 가격 책정 적용
      • 커스텀 보관 기간을 적용하지 않는 한 30일 보관
      • 버킷 삭제 불가능, 로그를 이 버킷으로 라우팅하는 _Default 로그 싱크 사용 중지 가능
    • Custom
      • 커스텀 보관기간 설정 가능
      • 커스텀 보관기간은 최대 10년

로그 버킷은 클라우드 콘솔의 Logging > Logs Storage에서 신규 로그 버킷을 생성하거나 기존 로그 버킷을 관리할 수 있습니다.

  • 로그 버킷 참고 사항
    • 로그 버킷은 버킷을 삭제하거나 수정이 불가능 하도록 잠금을 지원하며 이를 통해 필요에 따라 요건을 충족시킬 수 있습니다.
    • 로그 버킷에 수집된 로그는 한번 Log Router를 통하여 버킷에 도달한 로그이므로 Cloud Monitoring의 Log Based Metric은 지원하지 않습니다.
    • 특정한 로그만을 제한된 사용자에 보여지도록 권한 설정을 필요로 하는 경우, IAM Condition으로 구현되는 로그 버킷의 커스텀 뷰 보기(현재 Beta) 기능을 활용하여 구성할 수 있습니다.

    • 로그 버킷 생성시 Compliance에 요건 등에 따라 특정 리전(asia-east1 / europe-west1 / us-central1 / us-east1 / us-west1)에 로그를 저장하도록 선택 가능합니다. 해당 리전 외 global 설정 시 로그가 물리적으로 저장되는 위치를 특정하지 않게 됩니다.
    • 로그 버킷은 삭제시 7일간 대기 상태로 유지 후 완전히 삭제되며 해당 기간내 복구 가능합니다.
    • Error Reporting은 Cloud Logging을 기반으로 하는 글로벌 서비스이며, 리전 로그 버킷에 저장된 로그 또는 다른 프로젝트로 라우팅된 로그를 분석하지 않음을 유의해야 합니다.
    • 별도의 로그 버킷에 저장된 로그는 클라우드 콘솔의 Log Viewer에서 “Refine Scope” 을 통해 버킷을 지정하여 열람할 수 있습니다.
4. 로그 라우터

Cloud Logging으로 수신된 로그 중 원하는 로그를 Filter로 선별하여 다른 목적지로 재전송하는 기능으로 기업의 각종 로그 관리 요건을 충족하기 위해 널리 활용되는 기능입니다.

해당 기능은 규정 준수를 위해 유지해야 하는 로그를 별도의 로그 버킷에 저장하거나 수집된 로그를 빅데이터 분석 도구로 활용가능하며, 아래 목적지로 내보내기를 저장합니다.

  • Log Bucket
  • Bigquery
  • Cloud Storage Bucket
  • Cloud Pub/Sub
  • Cloud Monitoring(=Log Based Metric)

로그 라우팅은 각각 프로젝트 레벨, 폴더 레벨, 조직 레벨, 빌링 계정 레벨등의 로그에 대해 설정이 가능합니다. 해당 레벨의 로그 라우팅 설정은 각 레벨에 해당하는 로그만을 포함할 뿐 하위 로그가 포함하는 것은 아님에 유의하여야 합니다. 즉, Organization 레벨의 로그에 대한 Sink를 설정하더라도 Organization 이하 Folder 레벨의 로그가 자동적으로 Sink되는 것이 아닙니다. 특정 리소스 이하에서 전체 내보내기는 Aggregated Sink 기능을 활용하여야 합니다.

5. 조직을 위한 Aggregated Sink

Aggregated Sink는 Cloud Logging의 Log Router를 활용하여, 조직/폴더/프로젝트 레벨 이하의 조건에 부합하는 모든 로그를 지정한 목적지로 전송할 수 있습니다. 설정방법은 gcloud SDK의 명령어를 활용합니다. 예를 들어 아래 명령어를 이용하면 Organization 이하의 모든 Audit 로그를 특정 로그버킷을 취합하여 저장할 수 있습니다.

gcloud logging sinks create [SINK_RULE_NAME]  / 
logging.googleapis.com/projects/[LOG_BUCKET_PROJECT_ID]/locations/[LOG_BUCKET_REGION]/buckets/[LOG_BUCKET_NAME] 
	--log-filter='logName:cloudaudit.googleapis.com' \
	--description="All audit logs from my org log sink" \
	--organization=ORG_NUMBER \
	--include-children

*해당 설정을 위해서 로그 버킷 권한 및 뷰어 권한 설정을 필요로 합니다.

  • Aggregated Sink 활용시 참고 사항
    • 별도의 로그 수집용 프로젝트와 로그 버킷을 권장합니다.
    • 수집된 로그에 대하여 보안을 위해 최소 권한 접근 방식의 권한 관리를 적용합니다.
    • 필요에 따라 로그 버킷의 로그 Retention 기간의 설정과 잠금 기능을 설정합니다.
    • 일상적인 조회가 이루어지는 로그가 아닌, 장기 보관 목적을 필요로 하는 로그의 경우 Cloud Storage로 Sink하여 보관하는 것을 권장합니다.
    • Cloud Storage로 Sink 할 경우 저장되는 개체에 대해 Lifecycle 관리 정책을 설정하여 비용절감을 도모할 수 있습니다.
      • 예) 60일 후 Nearline 변경 > 120일 후 Coldline 변경 > 2555일(약 7년) 후 로그 삭제

    • 조직의 정책과 활용 방식에 따라 Aggregated Sink를 복수로 구성하여 활용합니다.
6. 로그 관리 유의 사항

모든 로그를 저장하는 것이 가장 권장되지만 로그 수집과 저장으로 인해 발생하는 Cloud 비용과 조직의 요구 조건 사이에서 균형점을 선정하여야만 합니다. Cloud Logging은 아래와 같은 가격 정책을 가지고 있습니다.

  • Cloud Logging 가격 정책
    • 로그 데이터 $0.50/GiB, 프로젝트당 월별 최초 50GiB 무료
    • 2021년 3월 31일부터 기본 보관 기간 초과 시 매월 $0.01/GiB의 요금 발생
    • 아래 무료 로그를 제외한 모든 로그에 대해서 무료 사용량을 초과하는 로그에 대해 비용 발생
      • Admin Activity Audit 및 System Event Audit 로그
      • Access Transparency 로그
      • 제외 설정된 로그
      • Anthos 로그 / Dataflow 로그
    • 대량 로그 발생이 우려될 경우, Cloud Monitoring의 로그 발생량 메트릭(“Monthly log bytes ingested”에 대한 모니터링을 적극 권장합니다.
    • Sink 기능을 활용하여 다른 GCP 리소스로 내보내기를 구성할 경우 해당 리소스의 비용이 별도 부과됩니다.
  • 로그 제외 기능
    • 제외 항목은 Logging 할당량으로 집계되지 않음
    • 제외 항목은 로그 탐색기에 표시되지 않음 (즉, Error Reporting 또는 Cloud Debugger에서도 사용불가)
    • 싱크 대상이 포함된 로그 싱크를 사용하여 Cloud Logging 외부로 로그 항목을 내보내기 가능하며 동시에 수집제외 가능
    • 제외 설정 기간 중 이미 제외 처리된 로그는 제외설정을 제거하더라도 조회 불가능함에 유의

출처 및 참고사이트

까르띠에의 디지털 트랜스포메이션

구글 인사이트
by Miyeon. Jo

유럽의 품위와 럭셔리한 감각을 느낄 수 있는 프랑스 브랜드 까르띠에(Cartier)는 165년이 넘는 세월 동안 4대에 걸쳐 그 명성이 빛나고 있습니다. 주얼리와 시계 분야에 있어 장대한 역사를 만들어오며 아름다움과 영원한 열정을 표현하는 전설적인 제품으로 세계 최고의 보석·시계 브랜드로 자리 잡았습니다.

세계 최고의 컬렉션을 자랑하는 까르띠에는 고객에게 신속하고 효율적인 서비스 또한 제공하기 원했습니다. 까르띠에는 2020년 Google Cloud와 AI, 머신러닝 기술을 도입하며 과거 매장에서 영업 사원들이 고객에게 수동으로 카탈로그를 보여주는 방식을 디지털 전환하였습니다. 이제 까르띠에 전 매장의 직원들은 검색 한 번으로 전 매장의 모델을 조회하고, 비교할 수 있게 되었습니다.

AI를 통한 제품 검색 기능 강화 사례

까르띠에의 목표는 시계의 이미지를 표시 할 때, 특정 모델에 대한 자세한 정보를 검색하고, 비슷한 모양의 시계 (가격과 같은 다른 특성이 있을 수 있음)를 2초 이내에 검색할 수 있는 애플리케이션을 개발하는 것이었습니다. 이 앱을 사용하면 판매 직원은 천 개 이상의 시계 카탈로그 내에서 특정 제품을 신속하게 찾을 수 있습니다.

하지만 이 앱을 만드는 것은 까르띠에의 데이터팀이 몇 가지 문제가 있었습니다. 머신 러닝 모델을 훈련하려면 엄청난 양의 훈련 데이터 (이 경우 까르띠에 손목시계 이미지)가 필요한 것과, 매장 내 제품에 대한 이미지가 거의 없었던 점, 배경, 조명, 품질 및 스타일링이 다양하여 제품 식별이 어려웠던 점입니다.

까르띠에는 수준 높은 고객 서비스를 제공하기 위해 최소 90%의 정확도를 가지고 전체 파이프 라인이 5초 이내에 실행될 수 있는 이미지 인식 시스템을 개발할 방법을 찾아야 했습니다. 이러한 문제를 해결하기 위해 까르띠에 데이터팀은 Google Cloud와 파트너십을 통해 고도의 머신 러닝 기능을 찾는 것을 요청했고, Google Cloud 우수한 품질의 AI 서비스를 통해 머신러닝 고도화 프로젝트를 성공적으로 수행할 수 있었습니다.

고객 경험 그 이상을 넘어서

까르띠에 데이터팀은 Google Cloud AI Platform (Auto ML Vision, Vision API) 서비스를 활용해 다양한 머신 러닝 실험을 시도할 수 있었고, 커스텀 코드를 다시 작성하기 전에 데이터 및 비주얼 검색 과제를 해결할 수 있게 되었습니다. 병렬로 실행되는 분류기 조합으로 먼저 시계의 색상과 소재를 하여, 시계가 속한 시계 컬렉션을 식별할 수 있게 되었습니다.

결과적으로 이 데이터 모델을 통해 3초 이내에 최대 96.5%의 정확도로 사용자가 클릭할 수 있는 이미지에 대한 가능한 ID(시각적으로 유사한 시계)의 상위 3개 목록을 제공받을 수 있게 되었습니다.

 

이제 고객이 특정 까르띠에 시계를 필요로 할 때, 매장 직원은 원하는 모델의 사진을 찍어 올리면, 해당 제품이 업로드되어 있는 페이지를 한 번에 찾을 수 있습니다. 또한 이 솔루션은 카탈로그에서 시각적으로 유사한 디자인 제품을 찾아 고객이 탐색 할 수 있도록 자체 이미지, 유사성 점수 및 자세한 설명 (매장 직원이 클릭하는 경우)을 표시합니다.

출처 및 참고사이트

Kubeflow 시작하기

구글 인사이트
by Miyeon. Jo
목차
  1. Kubeflow 개요
  2. 개념적 개요
  3. Kubeflow 구성 제품
  4. GCP에서 Kubeflow를 통한 예시
1. 개요

Kubeflow는 Kubernetes + ML flow를 합한 의미로, 파이프라인이라는 ML워크플로를 구축하고 배포하기 위해 제공되는 플랫폼입니다. 개발, 테스트 및 프로덕션 수준 서비스를 위해 다양한 환경에 ML 시스템을 배포하려는 ML 엔지니어 및 운영 팀을 위한 것입니다.

1.1 파이프라인 구성 요소 이해

AI HUB의 파이프라인 워크플로우는 데이터 사전 처리, 데이터 변환, 모델 학습 등과 같은 단계로 구성되어 있습니다. 워크플로우의 구성요소는 입력 매개 변수 세트, 출력 세트 및 컨테이너 이미지의 위치로 구성되어 있습니다. 구성요소의 컨테이너 이미지는 구성 요소의 실행 코드와 코드가 실행되는 환경의 정의를 포함하는 패키지로 이루어져있습니다.

2. 개념적 개요

Kubeflow는 쿠버네티스에서 머신 러닝 워크 플로를 실행하기 위해서 만들어졌습니다. 일반적으로 다음과 같은 이유로 사용할 수 있습니다.

  • 이미 쿠버네티스 기반의 인프라가 있거나, 새로운 머신 러닝 플랫폼을 만들려는 경우
  • 다양한 환경(예 : 로컬, 온 프레미스 및 클라우드)에서 머신 러닝 모델을 학습하거나 서비스하려는 경우
  • 자원(예 : CPU 또는 GPU)를 할당하여 작업을 하려는 경우
  • Jupyter 노트북을 사용하여 머신 러닝 작업을 하려는 경우
  • Kubeflow에는 Jupyter 노트북 생성 및 관리를 위한 서비스를 이용할 때
  • Kubeflow Pipelines는 Docker 컨테이너를 기반으로하는 다단계 ML 워크 플로를 구축, 배포 및 관리할 때
  • Kubeflow는 여러 플랫폼에서 ML 학습, 초 매개 변수 조정, 워크로드를 자동으로 작업하려는 경우

더 자세한 내용은 아래의 링크를 참고해주시길 바랍니다.

Kubeflow Overview

3. Kubeflow 주요 제품
  • Kubeflow’s UI – Central Dashboard
  • Jupyter Notebooks
  • Metadata
  • Frameworks for Training
  • Hyperparameter Tuning : Katib
  • Pipelines
  • Tools for Serving
3.1 Kubeflow’s UI

Kubeflow의 UI 화면으로서, Kubeflow의 구성 요소를 쉽게 접근할 수 있는 대시보드가 포함되어 있습니다. 특정 작업에 대한 바로 가기, 최근 노트북 목록 및 파이프 라인 목록을 한 번에 볼 수 있습니다. 또한, 파이프라인, 노트북, Katib 등 클러스터에서 실행중인 컴포넌트 목록을 볼 수 있습니다.

3.2 메타데이터

Kubeflow에서 실행하는 머신 러닝 워크 플로우의 메타 데이터를 추적 및 관리하는데 사용합니다. 메타데이터 컴포넌트는 Kubeflow 사용자가 머신 러닝 워크 플로에서 생성하는 메타 데이터를 추적하고 관리함으로써, 머신 러닝 워크 플로를 이해하고 관리 할 수 ​​있도록 도와 줍니다.

3.3 Hyperparameter Tuning : Katib

Kubeflow에서 머신 러닝 모델의 하이퍼 파라미터 튜닝을 할 수 있도록 도와줍니다.
Katib는 머신 러닝 모델의 하이퍼 파라미터 및 뉴럴 아키텍처(Neural Architecture)를 자동으로 튜닝할 수 있는 기능을 제공합니다. Katib는 TensorFlow, PyTorch, Apache MXNet, XGBoost 등 다양한 머신 러닝 프레임 워크를 지원합니다.

3.4 Pipelines

Kubeflow 파이프라인은 컨테이너를 기반으로 확장 가능한 ent-to end 머신 러닝 워크 플로를 구축하기 위한 플랫폼입니다. 머신 러닝 파이프라인을 관리하는 기능을 제공하여 ent-to end 오케스트레이션을 지원합니다. 그리고 수 많은 아이디어와 기술을 시도할 수 있도록 시험(trials)과 실험(experiments)을 관리할 수 있는 기능도 제공합니다.

4. GCP에서 Kubeflow를 통한 예시
4.1 python을 통한 Kubeflow Pipelines 배포
1. Navigation Meun → AI Platform → Pipelines 로 이동
2. New Instance 클릭 → Configure 클릭
3. Access to the following Cloud APIs 허용 → Create cluster 클릭(2~3분 소요) → GCP Marketplace 서비스 약관에 동의 → 배포(10분 정도 소요)
4. Navigation Menu → AI Platform → Notebook → New Instance → Tensorflow Enterprise 2.x _ without GPU (default 셋팅)
5. 필수요소 값 가져오기
RPOJECT ID5-1) 참고
Gcloud Storage name 가져오기5-2) 참고
kfp.Client – host url5-3) 참고
5-1) PROJECT ID 값 가져오기
5-2) Gcloud Storage 이름 가져오기(gshell을 이용)
export PROJECT=$(gcloud config list project --format "value(core.project)")
echo "Your current GCP Project Name is: "$PROJECT

export REGION=us-central1

gsutil mb -l ${REGION} gs://${PROJECT}

gsutil ls
5-3) kfp.Client – host url 값 가져오기
piplelines 중에 배포할 모델의 SETTINGS 클릭 → 박스 안에 있는 kfp.Client(host=’https://**********************’) 값 중 ‘____’ 값 가져오기
6. NOTEBOOKS에서 OPEN JUPYTERLAB 클릭 → Terminal 클릭 → 터미널 창에 아래 코드 입력 후, 데이터 다운로드 확인
git clone https://github.com/kubeflow/pipelines.git
cd pipelines
git checkout d87c3be6114af867760d07f1d70f4d95d4456c52
7. root/pipelines/samples/core/ai_platform/ai_platform.ipynb 열기 → 위에서 구한 필수요소 값 입력
  • Project ID / Storage Location 입력
  • kfp.client 값은 아래와 같이 변경
8. 코드 전체 실행 → 배포된 모델 및 결과 확인
  • 배포가 제대로 완료되면 아래와 같은 그림으로 kubeflow pipeline이 작성됨
  • 배포가 완료되면 아래와 같이 cloud storage에 csv파일로 결과값이 저장됨
4.2 Run of [Demo] XGBoost – Iterative model training
1. AI Platform → 파이프라인 → 새 인스턴스 생성 → 파이프라인 대시보드 열기
2. Central Dashboard에서 pipelines 클릭 → [Demo] XGBoost – Iterative model training 클릭
3. 우측 상단에 있는 Create experiment 클릭 → Experiment Name 칸에 실험 이름 입력(ex : test01-2021-04-29) → 옵션들은 default로 두고 start 클릭
4. Runs 선택 후, Run name 중 돌렸던 모델을 클릭 → 상자 우측 상단에 초록색 체크 표시가 있으면, 성공적으로 돌아갔음을 확인할 수 있음
5. 각 단계별 input / output를 박스 클릭하여 확인할 수 있음.
(여기서는 log, table, mse, r , squared r 값 등을 확인할 수 있음)

출처 및 참고사이트

2021 클라우드 동향 7가지

구글 인사이트
by Miyeon. Jo

클라우드 컴퓨팅은 IT 포트폴리오 현대화에 있어 특히 선호되는 모델로 자리잡았다. 특히 코로나 사태 중에 업무 회복성을 높이고 전자상거래 모델로 전환하기 위해 클라우드 서비스 소비가 늘어났다.
이로써 인터넷을 통해 제공되는 소프트웨어의 시장이 더 없이 확실히 검증된 셈이 되었다.
퍼블릭 클라우드와 프라이빗 클라우드의 혼합 환경으로 애플리케이션을 이전하면 업무 민첩성이 훨씬 커질 수 있을 것으로 기대하는 CIO들이 많다. 그러나 하이브리드 클라우드 환경 구축에는 아직 어려움이 많다. 대규모 이전에 동반되는 가상 스프롤(virtual sprawl) 현상도 그 중 하나다. 클라우드 환경을 운영하는 재무 모델에도 독특한 어려움이 따른다. 통제 관리가 미흡하면 클라우드 서비스 실행 비용이 구내에서의 컴퓨팅 서비스 운영 비용보다 클 수 있다는 사실이 드러났기 때문이다. 최신 클라우드 서비스와 아키텍처를 따라잡는 것이 어렵다는 점도 염두에 두어야 한다.
그럼에도 불구하고, 클라우드 전략을 제대로 실행할 경우의 장점은 무시할 수 없을 정도로 크다. 2021년 클라우드 전략과 관련한 주요 동향을 살펴본다.

1. 비즈니스 가치 창출을 위한 고군분투

먼저, 안타까운 사실은 클라우드 투자 가치 극대화에 어려움을 겪는 조직이 대부분이라는 점이다.
11월에 발표된 액센츄어 조사 내용에 따르면, 업무 임원 및 IT 임원 750명 가운데 37%만이 클라우드 투자에 기대한 가치를 실현 중이라고 밝혔다. 뿐만 아니라, 소속 조직의 클라우드 이주 계획이 기대한 가치를 기대한 시기에 실현할 것으로 완전히 확신한다는 응답자의 비율은 29%에 그쳤다.
액센츄어 클라우드 퍼스트 부서 글로벌 책임자 카르틱 나라인은 구형 시스템에서 빨리 벗어나지 못하고 가장 쉬운 애플리케이션 이전(migration)에 지나치게 치중하는 것 등이 장애물이라고 지적했다.
예를 들면, 접객 체인이 비용 관리는 퍼블릭 클라우드로 옮기면서 핵심 예약 시스템은 사내에 유지하는 경우를 생각해볼 수 있다. 주변 서비스를 위해 핵심이 무시된다면 가치 창출이 미미해진다.
깔끔한 이전과 최고의 변화 관리 전략 지정에 어려움을 겪는 조직들은 2021년에도 클라우드 투자 수익률 창출에 계속 어려움을 겪게 될 것이라고 나라인은 내다봤다.

2. ‘클라우드 2.0’ 시대

IaaS는 10년 넘게 고도 성장을 누렸다. 기업 클라우드 환경 관리 지원 소프트웨어 판매회사 VM웨어의 클라우드헬스 사업부 VP 조 킨셀라에 따르면 2021년에는 PaaS, 마이크로서비스, API를 통한 업무 서비스에 더욱 탄력이 붙을 것이며, 이는 다시 더 많은 생태계에 동력을 제공할 것이다.
예를 들면, API를 통해 은행들은 마찰 없는 상거래와 할인으로 소비자를 유인할 수 있도록 우버(Uber), 리프트(Lyft) 등 긱(gig) 경제 참여 업체와 제휴를 맺을 수 있게 된다. 킨셀라에 따르면, 클라우드 2.0는 재호스팅 방식은 줄이고 마이크로서비스로 구축한 클라우드 네이티브 앱에 대한 의존도는 늘리는 효과도 가져올 것이다.

3. 클라우드 공동 혁신의 증가

가치 창출에 더욱 박차를 가하기 위하여 몇몇 대기업들은 클라우드 업체 및 컨설턴트들과의 제휴를 통한 기능 공동개발에 나서고 있다고 나라인은 말했다.
예를 들어, 랜드오레이크스(Land O’Lakes)와 페덱스(FedEx)는 마이크로소프트와 함께 제품을 만들고 있으며 타케다(Takeda)와 캐리어(Carrier)는 AWS와 함께 기술을 구축 중이다. 2020년이 이러한 동향에 ‘발끝을 담가보는’ 시기였다면, 2021년에는 대기업과 하이퍼스케일 클라우드 업체들 간의 공동 혁신이 급증할 것이다.

4. 클라우드 복잡성의 계속적인 증가

킨셀라(VM웨어의 클라우드헬스 사업부 VP)에 따르면, 새로운 구축 및 배치 모델을 잘 파악하는 일은 늘 어려웠다. 그러나 회사들이 더 많은 애플리케이션을 지원하기 위하여 가상 서버와 저장장치를 늘림에 따라 이러한 클라우드 환경을 관리하는 일은 더욱 어려워질 전망이다. 더 많은 애플리케이션이 다른 서비스에 연결되면서 상호 의존성이 더욱 많아질 것이기 때문이다.
이에 더하여 AWS, 마이크로소프트, 구글은 주기적으로 새로운 클라우드 서비스(예컨대 서버리스 및 서비스형 펑션)를 출시하는데 이들 서비스를 사용하고 관리하는 데 필요한 도구들은 따라가지 못하고 있다. 킨셀라는 “클라우드가 매우 복잡해지고 있다. 아키텍처 지형은 항상 변화한다”고 덧붙였다.
클라우드 환경 관리용 셀프서비스 제공회사 클라우드볼트(CloudBolt) CEO 제프 쿠코스키는 전체적으로 통제 관리, 보안 등의 기능이 충분히 자동화되지 않은 조직이 대부분이라고 전제하고 “무엇이든 사용자화 코딩은 어려운 일”이라고 덧붙였다.

5. 클라우드 비용 제어

예산에 따라 하이브리드 클라우드 시스템을 운영하기 위한 재무 모델은 여전히 주요한 걸림돌로 남아 있다. 지출 통제에 어려움을 겪는 조직이 많다고 밝힌 킨셀라는 자신 또한 초기에 AWS를 채택하면서 코드 초과로 청구 비용이 2배가 뛰어 35만 달러에 달한 적이 있다고 전했다.
일부 CIO들은 핀옵스(FinOps)를 활용한다. 핀옵스는 클라우드 소비 비용을 계산하는 분석 소프트웨어와 업무 관리 관행을 결합한 것이다. 그럼에도, 핀옵스 재단 조사 결과에 따르면, 핀옵스 사용자 750명 중 49%는 클라우드 지출 관리를 거의 자동화하지 않아 핀옵스의 가치를 제대로 활용하지 못하고 있는 것으로 나타났다.

6. 클라우드 시장의 인수합병

2021년에는 클라우드 관리 서비스 시장이 계속해서 통합될 것이라고 쿠코스키(클라우드볼트 CEO)는 내다봤다. 쿠코스키의 소속 회사는 프로비저닝 도구와의 무코드 통합과 AWS 및 애저 환경 최적화 지원을 위해 지난해 소브랩스(SovLabs)와 쿠몰러스(Kumolus)를 각각 인수한 바 있다. 이 분야의 거침없는 인수합병이 계속되었다. 지난 4년간 VM웨어가 클라우드헬스를 차지한 것 이외에도 HPE가 클라우드 크루저(Cloud Cruiser)를 인수했고 플렉세라(Flexera)는 라이트스케일(RightScale)을 가져갔으며 앱티오(Apptio)는 클라우더빌리티(Cloudability)를 사들였다.
쿠코스키는 “하이브리드 클라우드, 멀티클라우드 분야는 마치 미국 서부시대 의 미개척지와 같으며 풀어야 할 문제가 많다”라고 말했다.

7. 클라우드는 이제 최고 임원들의 고려사항

CIO들의 숨통이 트였다. 고위급 임원들 중에 CIO들만 클라우드의 가치를 극찬하던 때가 지났기 때문이다. 나라인에 따르면, 클라우드 서비스로의 이전으로 얻는 업무상 장점에 관한 전략적 논의에 참여하는 CEO들과 최고 임원들이 늘어나고 있다.
나라인은 “지난 6개월 간 CEO를 비롯한 최고 임원들과 나눈 클라우드 관련 대화 횟수가 급등했다”고 밝혔다. 요컨대 클라우드는 하향식 시도로 자리잡았다.

결론

클라우드를 많이 활용할수록 비즈니스 성과가 향상되는 경향이 나타난다. 나라인에 따르면, 클라우드를 적극 채택한 기업 중 46%가 기대한 클라우드 장점을 완전히 실현하고 있다고 밝힌 반면, 보통 또는 낮은 수준으로 채택한 기업의 경우 그 비율이 각각 36%와 28%에 그쳤다.
이러한 수치를 향상시킬 묘책은 없다. 기술적인 부분이 아니라 행정적인 부분에서 비롯된 어려움이 많기 때문이다. 그러나 2021년에는 IT 부서에서 더 많은 ‘클라우드 네이티브’ 솔루션을 구축하여 업무 민첩성을 더 많이 창출할 것으로 나라인은 예상하고 있다.

출처 및 참고사이트

Policy Tag를 사용한 BigQuery의 Column 수준 보안

구글 인사이트
by Miyeon. Jo

구글 PS1팀 김소원

GCP(Google Cloud Platform)에서는 Policy Tag를 통해, 개인 정보 등 민감한 정보의 Column에 권한이 부여된 개인정보 취급자1에게만 정보를 공개하여 안전하게 데이터를 관리합니다.
Policy Tag의 계층 적 그룹을 만들고, BigQuery Column에 Policy Tag를 지정하여 액세스 제어를 적용합니다.

데이터 클래스의 계층 구조

조직에서 처리하는 데이터의 종류를 고려하여 업무에 적합한 데이터 클래스의 계층 구조를 만듭니다. Policy Tag의 데이터 클래스 계층 구조를 만들면 아래와 같이 관리할 수 있습니다.

  • 하나의 Policy Tag를 여러 Column에 적용 가능하며, 몇 개의 Policy Tag 만으로 여러 Column을 효율적으로 관리합니다.
  • 서로 다른 Policy Tag에 액세스해야 하는 사용자 그룹이 있다면, Policy Tag 별로 사용자 그룹에게 권한을 주어 관리 할 수 있습니다.
  • Policy Tag를 그룹화하여, Policy Tag가 모두 포함된 루트 Policy Tag를 만들어 사용 할 수 있으며, 상위 레벨에 권한을 부여하면 하위 Tag 에도 동일하게 적용이 됩니다.

BigQuery Column 수준 보안

BigQuery Column 수준 보안을 사용하면 Query시 사용자에게 적절한 액세스 권한이 있는지 확인하며 다음과 같은 액세스 검사를 시행합니다.

  • Credit_Card(Column)을 보려면 Business Criticality:high 에 권한 있어야 합니다.

GCP 실습

Policy Tag 생성

GCP Console > Data Catalog2 > Policy Tags

[GCP Console > Data Catalog2 > Policy Tags]

BigQuery Dataset Info

[BigQuery Dataset Info]

  • 분류(taxonomy)의 Location과 Big Query의 Table의 Data Location이 일치해야 Policy Tag를 설정할 수 있습니다.
  • Policy Tag 생성을 위해 아래 권한이 필요합니다.
역할설명
roles/datacatalog.categoryAdmin분류(Taxonomy)를 관리합니다.

Policy Tag를 BigQuery Column에 적용

Policy Tag 적용 전

  • 모든 Column 조회 성공

Policy Tag 적용 후

  • BigQuery Column에 Policy Tag 적용한 화면
BigQuery > Table > EDIT SCHEMA > Column 선택 > ADD POLICY TAG > Policy Tag 선택

[BigQuery > Table > EDIT SCHEMA > Column 선택 > ADD POLICY TAG > Policy Tag 선택]

※ Policy Tag 설정된 Column의 데이터를 보기위해 아래 FineGrainedReader 권한이 필요합니다.

역할설명
roles/datacatalog.categoryFineGrainedReader정책으로 태그를 지정한 하위 리소스(예: BigQuery 열)에 대한 읽기 액세스 권한입니다.
  • 해당 Column에 적용된 Policy Tag의 Fine-Grained Reader 권한이 없을 시, 조회 실패(Query : Select Credit_card From table_01)
  • 해당 Column에 적용된 Policy Tag의 Fine-Grained Reader 권한이 있을시, 조회 성공(Query : Select name, email From table_01)
Low의 Fine-Grained Reader 권한에 사용자/그룹 추가

[Low의 Fine-Grained Reader 권한에 사용자/그룹 추가]

Low 하위 권한(name, email) Column 조회 가능

[Low 하위 권한(name, email) Column 조회 가능]

  • 1 개인정보 처리에 관한 업무를 총괄해서 책임지는 자
  • 2 조직에서 Google Cloud의 모든 사내 데이터를 신속하게 찾고 관리하며 파악할 수 있도록 지원하는 확장 가능한 완전 관리형 메타데이터 관리 서비스.

출처 및 참고사이트

직방

by Miyeon. Jo

직방

“직방은 빠르게 성장하는 스타트업입니다. 백엔드 담당자들만 약 30명에 달하죠. 서비스가 급성장하니 병목현상도 발생하고, 알람을 처리해야하는 담당자가 모호해지기 시작했습니다. 얼럿나우(AlertNow) 를 활용하면서 알람 필터링으로 담당 파트가 바로 받기 때문에 자연스럽게 대응이 빨라졌어요. 직방은 전사가 재택근무를 하고 있습니다. 얼럿나우와 같은 SaaS 도구를 사용해 알람을 관리하니 업무 효율성이 높아졌습니다.”
– 직방 서비스개발그룹 백엔드팀 리드 이동욱님

Company Overview

직방 서비스가 성장하면서 알람을 효과적으로 관리할 수 있는 서비스가 필요하는 니즈가 있었습니다. 서비스 초기에는 백엔드 인원이 많지 않아 개발자 전체가 모든 알람을 다 받았었습니다. 하지만 서비스가 커지면서 백엔드 담당자만 30명 가까이 늘어났고, 알람을 받고 해결해야하는 담당자가 모호해지기 시작했습니다. 알람이 적합한 직원에게 전달되는 기능을 직접 개발할까 고민하던 찰나 베스핀글로벌의 얼럿나우(AlertNow)가 원하는 기능을 제공한다는 것을 알게 되었습니다.

Challenge

직방 서비스가 성장하면서 알람을 효과적으로 관리할 수 있는 서비스가 필요하는 니즈가 있었습니다. 서비스 초기에는 백엔드 인원이 많지 않아 개발자 전체가 모든 알람을 다 받았었습니다. 하지만 서비스가 커지면서 백엔드 담당자만 30명 가까이 늘어났고, 알람을 받고 해결해야하는 담당자가 모호해지기 시작했습니다. 알람이 적합한 직원에게 전달되는 기능을 직접 개발할까 고민하던 찰나 베스핀글로벌의 얼럿나우(AlertNow)가 원하는 기능을 제공한다는 것을 알게 되었습니다.

Solution

얼럿나우 도입 전에는 알람이 하루에 2~3건은 기본적으로 발생했습니다. 개발하는 도중 이런 알람을 받게 되면 방해가 됩니다. 해결할 수 있는 적합한 담당자를 찾아야하고, 우선순위를 정하고 해결하느라 시간을 낭비하기도 합니다. 얼럿나우 도입 이후에는 파트별 담당자에게 알람이 자연스럽게 나뉘는 구조가 되었습니다. 내가 해결할 알람이 아니면 받을 일이 없게 되면서 자연스럽게 업무 효율이 높아졌습니다.

AWS 시스템 알람, DB 모니터링하는 와탭(WhaTab), 데이터 시각화 도구인 키바나(Kibana)와 같은 도구들과 연동했습니다.
얼럿나우 사용이 어렵지 않아 도입부터 적응까지 약 2주 정도 소요되었습니다. 직접 개발하려고 했던 것을 생각하면 무척 짧은 시간이라고 볼 수 있습니다.

Benefit

인시던트를 전파하는 과정이 효율적이고 파트에 할당하는 기능을 가장 잘 활용하고 있습니다. 앱 푸시와 문자로 전송해주는 기능만으로도 얼럿나우의 장점을 충분히 체감합니다. 특히 사용자가 받는 메시지를 정리할 수 있다는 점도 큰 장점입니다.

Next Step

직방의 전직원이 재택근무를 하기 때문에 효과적인 알람관리가 필요하다는 것을 느낍니다. 지금은 얼럿나우를 개발팀만 사용하고 있지만, 점차 확산해 알람뿐만 아니라 전사 직원에게 공지를 전달하는 방식으로도 활용하는 방안을 고려 중입니다.

1. 프롭테크(Proptech): 부동산과 기술의 합성어이며, 부동산업과 기술업을 결합한 새로운 형태의 산업, 서비스, 기업 등을 포괄한 개념

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