앞서 언급된 대로 Google 측에서는 GA 데이터 연계를 목적으로 Core Reporting API 라는 인터페이스를 제공한다.
R 에서도 해당 API 를 통해 GA 데이터를 가져올 수 있는데, 그 패키지가 바로 googleAnalyticsR 패키지다.
가령, Google 측이 제공하는 Affinity 세그먼트 별로 제품 조회 수를 알고 싶은 경우, 관련된 샘플 R 코드는 다음과 같다.
코드 별 상세 설명은 주석을 참고 바란다.
# googleAnalyticsR 패키지를 설치 및 로드
install.packages("googleAnalyticsR")
library("googleAnalyticsR")
# R 과 GA를 연동. 별도 브라우저 탭이 뜨고 계정 인증을 하면 된다.
ga_auth()
# GA ID 입력을 위해 해당 목록 조회. Property가 여러 개로 나눠져 있는 경우 유의해서 입력해야 한다.
ga_accounts <- ga_account_list()
View(ga_accounts)
# GA ID 입력
ga_id <- 12345678
# View ID 입력. View ID 는 GA 화면에서 Admin > View > View Settings 에서 조회 가능하다.
view_id <- 98765432
#스키마: https://ga-dev-tools.appspot.com/dimensions-metrics-explorer/
#데이터 호출
Affinity_PV <- google_analytics (view_id,
date_range = c("2020-01-01","2021-05-31"),
metrics = c("ga:pageviews"),
dimensions = c("ga:productDetailViews","ga:interestAffinityCategory"),
anti_sample = TRUE,
max = -1 )
UNIX time 이란, 1970년 1월 1일 00:00:00 UTC 로부터 현재까지의 누적된 초(seconds) 값을 의미한다.
가령, ‘2021-05-23 09:00:00 KST’ 위 시간을 UNIX time으로 표현한다면
① KST(local time)를 UTC 로 변환해서, ‘2021-05-23 00:00:00 UTC’ ② UNIX time 의 기준 시간인 ‘1970-01-01 00:00:00 UTC’ 에서부터 누적 초를 계산
아래 숫자 값을 도출하게 된다. ‘1621728000’
2. 왜 UNIX time 인가?
UNIX time 은 UNIX 운영체제를 개발한 벨 연구소에서 정의한 개념이다.
Date/Timestamp 데이터형을 Numeric 데이터형으로 표현 시, 기존에 Date/Timestamp가 갖는 한계점을 해결할 수 있어 UNIX time 의 개념이 도입되었다.
Date/Timestamp 의 한계점 1. 로컬 시간대(ex. KST) 명시 필요 2. 비연속적, 비선형적인 값이므로 계산 시 변환 필요
하필 기준 시간이 1970년 1월 1일 00시 00분 00초 UTC 인 이유는, UNIX 운영체제의 최초 출시년도가 1971년이어서 그렇다. 근방에 그럴싸한 시간을 임의로 잡은 것이다.
UNIX time 을 epoch time 또는 POSIX time 이라고도 부르는데, 이는 epoch 라는 단어가 특정 시대를 구분짓는 기준점(reference point from which time is measured = reference epoch) 이라는 의미를 가졌기 때문이고, POSIX 는 UNIX 운영체제를 기반으로 둔 운영체제 인터페이스여서 같은 의미로 사용된다.
3. 쿼리 시 주의사항
UNIX time 을 취급할 때 쿼리 시 간과하기 쉬운 부분은, 다름 아닌 UTC 기준이라는 것이다.
하여 당신이 영국이나 스페인 같이 UTC +00:00 timezone 국가에 거주하지 않는 이상, UNIX time 을 취급할 때는 항상 로컬 시간대로 변환하는 추가 작업을 해야한다. (이게 은근 까먹기 쉽다)
가령, Google Analytics 에서 수집한 고객 행동 데이터를 기반으로 접속 시간(hour)을 추출하는 쿼리를 작성한다고 하면, 다음과 같이 9시간에 해당되는 초(32,400)를 더해주어야 한다.
–BigQuery 기준 EXTRACT(HOUR FROM TIMESTAMP_SECONDS(CAST(visitStartTime+32400 AS INT64))) hh
목차 1. “No Code” Citizen Creators 2. Platforms, Networks & Marketplaces 3. The Great App Explosion 4. From Big Data to Big Ops 5. Harmonizing Humans & Machine
코딩의 영역은 UI에 의해 잠식당하고 있고, 그 속도는 점점 가속화되고 있다. 이제 디지털 세계에서 창작 활동은 개발자의 전유물이 아니다.
웹사이트 제작에서부터 시작해, 데이터 분석이나 심지어 앱, 챗봇, 머신러닝 개발까지도 이제 코딩 없이 제작할 수 있다.
표1. 활동 별 No Code Vendors
이를 Automation & Workflow, Content & UI Design, Databases & Spreadsheet-Driven 총 3가지 영역으로 구분해서 파악하기도 한다.
그림1. No Code Vendors 구분
☞ SO WHAT?
이러한 흐름이 초래할 결과는 다음과 같다.
디지털 세계에 비개발자 출신의 창작자(a.k.a. Citizen Creator)가 많아진다.
더 많고 다양한 디지탈 창작물(ex. SW, 디지털 자산, 앱, 분석물, 워크플로우 등)이 나온다.
이것들을 조율/활용 가능한 ①플랫폼 ②거버넌스③API연계의 중요성이 대두된다.
여러 영역을 다룰 줄 아는 Multi player로써의 전문가 니즈가 늘어날 것이다.
2. Platforms, Networks & Marketplaces
플랫폼, 네트워크, 마켓플레이스는 현 시대의 비즈니스 모델이자 운영 모델이다. 선도기업들은 이러한 모델들을 조합해 지속 가능한 하나의 생태계를 만든다.
그림2. 모델 별 특징 및 사례
이 생태계를 중심으로, 여러 벤더사들은 크게 3가지 수익화 전략을 구사하고 있다.
벤더사들은, – Provide: 참여자들에게 생태계 자체를 제공한다. – Engage: 참여자들이 기존 생태계에서 잘 활동할 수 있도록 지원한다. – Create: 참여자들이 직접 생태계를 만들 수 있도록 돕는다.
그림3. 벤더사들의 생태계 수익화 전략
☞ SO WHAT?.
운영 모델 수립 시, 기존의 ~ Chain (ex.Value, Supply etc.) 기반의 Linear한 개념에서 벗어나 보다 동적이고 다층적인 개념 적용을 고려해야 한다.
전략 수립 시 플랫폼 구축 방안을 항상 고려해야 한다.
3. The Great App Explosion
세상에는 수 많은 앱이 있으나, 다음 5가지 종류로 분류될 수 있다.
앱 종류
특징
예시
Custom App
기업에 의해 커스텀된 앱
웹사이트, 모바일 앱
Specialist App
특정 도메인/기능에 특화된 앱 API 지원되나 앱을 지원하는 생태계는 없음
Hotjar, Invision, Loom, SEMrush, Unibounce
App Platform
도메인/기능 전반을 지원하는 앱/스위트(Suite)
HubSpot, Salesforce, ServiceNow, Shopify
Service Platform
특정 비즈니스 서비스를 지원하기 위해 타 앱에 임베드할 수 있는 API 제공
Twilio, Stripe, AuthO
Cloud Platform
앱/서비스를 빌드하게끔 지원해주는 IaaS/PaaS
AWS, Azure, GCP
표1. 앱 종류 별 특징. 하단으로 갈수록 개수가 적어짐
Custom App을 제외한 미국 SaaS 시장은, 솔루션 수 기준으로 2020년 8,000 여 개로 집계되었다.
이는 지난 10년 간 무려 52배가 늘어난 수치다. 폭발(Explosion)이라는 표현이 결코 과하지 않다.
이 성장세는 앞으로도 계속해서 이어질 전망이다. 트렌드 2번에서도 기술된 Platform, Marketplace가 꾸준히 성장하면서 더 많은 참여자들을 유인할 것이다.
이로 인해 – 경쟁이 심화되고 – 벤더사들의 교섭력이 약화되어 가격이 전반적으로 낮아지면서 – 동시에 벤더사들은 서로 모방과 차별화를 반복해 전반적인 기능 수준이 높아지고 – 결과적으로, 앱 시장에서 기업들이 체감하는 효용은 증가할 것이다.
☞ SO WHAT?.
기업이 보유한 앱 포트폴리오를 얼마나 잘 orchestrate해 비즈니스 목적에 최적화해 활용하는가(Global Optimum)는, operation 단의 화두이자 중요 과제로 점점 부상할 것이다. 해당 역할을 잘 수행하는 agency 또는 인재가 각광을 받을 것이다.
위 역할을 수행하고자 하는 사람이라면, 앱 시장에서의 역학 변화를 눈 여겨 보아야 한다. 중위 값 기준 하나의 앱은 15개의 다른 앱과 연계가 가능하며, 앱의 89%는 API를 제공하고 있다(Pandium 2020.5). 연계가 가장 많이 되는 앱 플랫폼 또는 앱은 무엇인지 현황과 트렌드를 잘 살핀다면, 현재 어느 앱 플랫폼/앱이 주도권을 쥐고 있는지 파악할 수 있을 것이다.
4. From Big Data to Big Ops
2020년 7월 IDC와 Seagate의 조사에 따르면, 기업이 취급하는 데이터 중 32%만이 활용된다. 전체 데이터의 24%는 수집 후 방치되고 있고, 나머지 44%는 수집조차 되지 않는 Dark Data다.
이는 상당수의 기업이 데이터를 제대로 활용하지 못하고 있음을 시사한다. 암만 데이터를 모아봤자 뭐하나? 아무런 가치가 없는데. 게다가 방치되는 데이터는 기업의 손익에서 0이 아닌 음수(-)의 관계다. 데이터의 저장에는 유지보수 관리 비용이 수반된다.
이러한 데이터의 활용에 관한 문제의식에서 출발한 개념이 Big Ops다.
기존에 ‘데이터’에 초점을 맞춘 Big Data가 있었다. 데이터를 수집/저장/처리하는 데 만전을 가하자는 2010년대의 주된 담론이었다.
반면 Big Ops는 ‘조직’에 초점을 맞춘다. 조직이 데이터를 얼마나 잘 연결시키고, 활성화해 의사결정에 반영하는가가 관건이다. 이것이 최근 2020년대 들어 화두가 되고 있는 주제이다.
이러한 관점에서 데이터는 다음 2가지 측면에서 다루어야 한다. 데이터를 증류(distillation)하고, 활성화(activation) 시켜야 한다.
그림4. Data Distillation & Data Reflexes
데이터를 가공한다는 표현은 기존에 보편적으로 사용되었으나, 증류한다는 표현은 생소하다. 보아하니, 딥러닝 영역에서 사용하는 전문 기법이라고도 하는데 이를 확장시킨 듯 하다.
데이터 증류의 종착점은 지식과 통찰(knowledge & insight)이다. 그렇다면, 데이터 활성화는 어떨까? 데이터 활성화는 고도화됨에 따라 자동화(automated)로 수렴한다.
☞ SO WHAT?.
기업은 데이터를 활성화시키기 위해 먼저 데이터를 연결시킬 것이다.
내부적인 연결을 통해 데이터 관리의 복잡성이 증대되고, 이를 조율 및 제어하는 역량과 거버넌스의 역할이 대두된다.
외부 인터페이스 주로 대외기관 I/F, 제도 및 기준 변경 시 발생한다. I/F 중복성, 표준 준수 여부를 중점적으로 관리해야 한다. #항목명 #목적설명 #입력원천 #출력방향 #유효범위 #시간 #다른I/O관계 #데이터포맷 #최종메시지
기능 개선 시스템 I/O 관련 활동 및 프로세스의 기능에 대한 요건이다. 불가변성(기능 개선 요건이 향후 재변경되지 않도록 근본적인 개선 방안 요청), 범용성(많은 사용자가 편리하게 사용할 수 잇는 요건을 우선적으로 요청)을 중점적으로 관리해야 한다. #입력에대한유효성 #정확한처리순서 #비정상상태에대한반응(오버플로우,에러등) #매개변수기능 #I/O간관계 #I/O순서 #I/O공식
성능 개선 일반적으로 동시 사용자 수, 정보 처리의 양/종류/소요시간 관련된 내용이다. 실현, 측정 가능성을 중점적으로 관리해야 한다. #성능측정기준 #모니터링
보안 개선 데이터 보안을 위한 물리적 제한통제, 사용통제를 말한다. 불가변성, 실현가능성을 중점적으로 관리해야 한다. #정보등급관리 #이용자등급관리 #접근통제기준 #사용통제기준 #모니터링
LinkedIn 의 Architecture Migration (from Monolith to Microservice)
Mid-tier Service의 Data Model/Back-end Service로 API 접근 횟수 증가
이를 Service 별로 처리하기 위한 Service 별 여러 Data Pipeline들을 구축
Site Traffic에 따라 개별 Data Pipeline들이 Autoscaling 하지 못하는 문제 발생
이에 Autoscaling이 가능한 단일 Distributed Pub-Sub Platform 개발 필요 발생
아래 Design Principles에 입각하여 개발 – 심플한 API (producers & consumers양측 모두) – 높은 정보처리량(throughput) – Scale-out 방식 아키텍쳐
Use-case
현재 Kafka를 사용하는 기업 (출처 : Apache Kafka)
LinkedIn, Twitter, NetFlix, Spotify, Uber, Goldman Sachs, PayPal, Airbnb …
*Globally하게 Tech-savvy한 기업들.. Open Source 운용에는 DevOps팀 또는 그에 준하는 인력이 필요하다고 여실히 보여진다.
작동 방식
Kafka 의 작동 방식에 관해서는 DevTimes Blog 에 깔끔하게 잘 설명되어 있으니 참고.
기존 Message Queue System 과의 차이점에 대해 간략히 요약하자면,
Producer ~ Broker : 개별 메시지 전송 뿐만 아니라 Batch 전달 가능
Broker : Memory 가 아닌 File System에 메시지 저장
Broker ~ Consumer : Consumer 메시지 Push 받는 방식이 아닌 Pull 하는 방식
Increase only and does not repartition existing data
Re-shard by merging or splitting shards
Partition/Shard Limitation
No limit. Optimal partitions depend on the use case
500 shards in US East (N. Virginia), US West (Oregon), and EU (Ireland) regions. 200 shards in all other regions.
Data Replication/DR
Cluster mirroring
Automatically across 3 Availability Zones
Message Delivery Semantics
Kafka guarantees at-least-once delivery by default. Kafka supports exactly-once delivery in Kafka Streams
Kinesis Data Streams has at least once semantics
Security
Either SSL or SASL and authentication of connections to Kafka Brokers from clients; authentication of connections from brokers to ZooKeeper; data encryption with SSL/TLS
Data can be secured at-rest by using server-side encryption and AWS KMS master keys on sensitive data within KDS. Access data privately via your Amazon Virtual Private Cloud (VPC)
Monitoring
Yammer Metrics for metrics reporting in the server
AWS CloudWatch and CloudTrail
Dependency
ZooKeeper
DynamoDB
Cost
Requires a lot of human support on installation, set up, configuration and clusters management. Setup in weeks
가상화(Virtualization)는 물리적인 컴포넌트(Components, HW장치)를 논리적인 객체로 추상화 하는 것을 의미하는데, 마치 하나의 장치를 여러 개처럼 동작시키거나 반대로 여러 개의 장치를 묶어 마치 하나의 장치인 것처럼 사용자에게 공유자원으로 제공할 수 있어 클라우드 컴퓨팅 구현을 위한 핵심기술이다.
가상화의 대상이 되는 컴퓨팅 자원은 프로세서(CPU), 메모리(Memory), 스토리지(Storage), 네트워크(Network)를 포함하며, 이들로 구성된 서버나 장치들을 가상화함으로써 높은 수준의 자원 사용율(물리서버 10~15% vs 가상화 70% 이상) vs 과 분산 처리 능력을 제공할 수 있다.
가상머신
가상화를 통하여 구현되는 복제된 컴퓨팅 환경.
운용목적1. 하나의 하드웨어위에 동시에 여러 종류의 운영체제나 프로토콜을 실행
운용목적2. 하나의 하드웨어 자원을 여러 사용자에게 분할
운용목적3. 가상화를 통해 분할된 시스템 간 상호 간섭이 없는 독립성(Isolation)을 보장
하이퍼바이저
공유 컴퓨팅 자원을 관리하고 가상머신들을 컨트롤(I/O 명령 처리) 하는 중간관리자.
컨테이너
모듈화되고 격리된 컴퓨팅 공간 또는 컴퓨팅 환경을 의미하며, 시스템 환경 의존성을 탈피하고 안정적으로 구동.
컨테이너 기술의 등장 배경 : 개발한 프로그램이 구동환경의 달라짐에 따라 예상하지 못한 각종 오류를 발생시키는 것을 해결하기 위함 (= 컴퓨팅 환경 간 이식성 ↑)
가상머신과 컨테이너의 차이점
컨테이너는 가상화에서 하이퍼바이저와 게스트OS 불필요
대신, 컨테이너는 OS 레벨에서 프로세스를 격리하여‘모듈화된 프로그램 패키지’로써 수행함
따라서 컨테이너는 가상머신보다 가볍고(수십 MB) 빠름
이는 더 많은 응용프로그램을 더 쉽게 하나의 물리적 서버에서 구동시키는 것을 가능케 함
초간단 요약
1 컨테이너 = ( 1 하이퍼바이저 + Σ 게스트OS )
표 요약
컨테이너 기술 Leading Vendors : 쿠버네틱스(Kubernetes), 도커(Docker)
복수의 object들을 포함한 json 파일을 R 로 import 하는 경우, jsonlite가 선호된다.
선호 이유는, import 결과물인 list 형태에서
JSON object의 data.frame 추출이 jsonlite에서 더 용이하기 때문이다.
.
#rjson 으로 import
my_j <- rjson::fromJSON(file=’파일명.json’)
#jsonlite 으로 import
my_jl <- jsonlite::fromJSON(‘파일명.json’)
.
위 코드 실행했을 때 결과는 아래와 같다.
rjson의 결과(my_j)는 Large list 이고,
jsonlite 의 결과(my_jl)는 일반적인 list 이다.
rjson의 결과(my_j)가 Large list 인 이유는,
json array 내 각각의 object 마다 임의 숫자로 numbering이 부여되기 때문이다. (ex.[1], [2], …)
이 numbering 으로 인해 as.data.frame 을 사용하여 list 에서 data frame으로 변환 시 rjson 에서는 오류가 발생한다. Error in (function (…, row.names = NULL, check.rows = FALSE, check.names = TRUE, : arguments imply differing number of rows: 1, 0
Food for iThought 