CNA(Cloud Native Architecture)
MSA(Micro Service Architecture)
Service Mesh
MDA(Micro Data Architecture)
Data Mesh
MIA(Micro Inference Architecture)
Inference Mesh
1. Cloud, the NEXT 기술 소개:
CNA MSA+MDA+MIA
Service | Data | Inference Mesh
AI Solution Architect Team@Megazone Cloud
박 문 기 | mkbahk@megazone.com
2. Documentation History
Revision Date Editor Contents Comment
0.1 2022-11-04 박문기 최초 작성
0.2 2022-12-13 박문기 IT분야 과제부문 추가
0.5 2023-03-06 박문기 Data Loop, Data Domain TTL 개념 추가
Revision History
Date Written by Documentation Title
2022-11-04 박문기 Cloud, CNA, MSA, Service | Data | Inference Mesh 소개
Original Documentation
3. 발표자 이력 소개
o Physical Networking
o 과거 약 -10년간
o Cisco(CCIE), Alcatel-Lucent, Juniper
o Router, Switch, Firewall, IPS/IDS, L4 Switch/LB, ...
o Ethernet-Spanning-Tree, RIP, OSPF, ISIS, BGP, ...
o Virtual Networking
o 과거 약 +10년간, SDDC(SDC+SDN+SDS)
o OpenStack with KVM, Neutron, Ceph, ...
o VMWare with EXSi, NSX, vSAN,...
o Microsoft Hyper-V with Hyper-V, Hyper-V Networking, Storage Space Direct, ...
o Application Layer Networking
o 지금은, +6이상, Public-Private-Hybrid Cloud VPC,..., Kubernetes Calico,... , Bigdata-AI(Pipeline),
HPC, ...
o Application Networking: MSA+Service Mesh
o Data Networking: MDA+Data Mesh
o Inference Networking: MIA+Inference Mesh
5. Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
o 점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해
서비스화해 제공하고
o 필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청
들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
o PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
o App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는
MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
o Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 작게 쪼개서 MDA(Micro Data
Architecture)로 전환 후 Data Mesh형태로 관리하고,
o AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현하는 AGI(Artificial General Intelligence, MACRO)보
다는 작은|특화된 ASI(Artificial Specialized Intelligence)인 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference
Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타중심, 트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중
심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
10. Cloud 서비스의 가치(1/3)
비용절감 (TCO) 직원 생산성 향상 운영 안정성 비즈니스 민첩성
Example
신제품 출시까지 걸리는 시간이
75% 빨라짐 (Unilever)
Example
재해복구를 고려하여, 중요
업무를 Multi-AZ및 Multi-리 전
에서 운영 (Expedia)
Example
TCO 50%이상 절감 (GE)
Example
매해 서버 구성하는데 사용되
는
500시간 이상을 줄임 (Sage)
What is it?
인프라스트럭처 비용 절감/클
라우드로 이관하는 비용 최소
화
What is it?
개별 업무 단위로 역할별 업
무 효율 개선
What is it?
SLA 향상및 예정되지 않은 다
운타임을 줄임으로 얻는 효과
What is it?
새로운 기능 및 어플리케이션을
빠르게 출시하고 그 과정에서의
오류를 줄임
Cost impact Value impact
11. Cloud 서비스의 가치(2/3)
Source: “Fostering Business and Organizational Transformation to Generate Business Value with Amazon Web Services”, IDC, Feb 2018.
8%
13%
32%
47%
IT인프라스트럭처 비용 절
감
리스크 회피–사용자 생산
성 증대
IT 인력 생산성
비즈니스 생산성 효
과
0% 10% 20% 30% 40% 50%
비용 절감 (TCO)
운영 안정성 비즈니스 민첩성
직원 생산성
클라우드로 이관 후 얻은 효과의 각 영역별 분포
Cloud Value Framework
13. Private Cloud w/ SDDC 구성 예)
OoB Mgmt Switch
UTM
DDoS
Leaf-Group
Port-Group
10G x 4E, Bonding
802.1q Tagging
Leaf-Spine Architecture
Open pSwitch
Internet
HDDC(Hardware Defined Data Center)
SDDC(Software Defined Data Center)
15. 몇 가지 중요 트랜드(1/8): 초-전환시대: 급변하는 비지니스와 IT기술 변화
아마추어는 일을 위한 조건과 환경을 구성하느라 일을 시작 못하고,
프로는 일단 일을 시작한 후 필요한 조건과 환경을 일에 맞춘다.
5천 만명
16. 몇 가지 중요 트랜드(2/8): 초-전환시대: 더 급변하는 비지니스와 IT기술
변화
17. 몇 가지 중요 트랜드(3/8): 초-연결 시대, Networking is Everything...
The Tree of Life
WarCraft 본진
✘
Simplicity and unity are best, but dangerous. Complexity
and Diversity are not best, but stable.
www
Internet
Evolution
Universe
Data Fabric & Mesh
AI-Deep Neural Network
MSA
금융 탈-중앙화
하나의 통일된 체계(초기:생산성증가 중기:생산성감소 말기:생존성약화)
물리학적 Entropy증가, 생물학적 다양성증가종심의존|종속성감소독립적인 부분변화 가속생존성증가
왜 우리는 네트워크를 만들고 있는가 또는 스스로 결과적으로 네트워크화 되어가고 있나요?
18. 몇 가지 중요 트랜드(4/8): AI & GPU Computing
IT for Business IT is Business
Data for Business Data is Business
AI for Business AI is Business
AI, Open the age of wisdom
GPU Computing 활용영역 확장
1. Game, Rendering, Video Transcoding,
암호화폐마이닝
2. AI Deep Learning
3. GPU Database(ex. SQream)
4. MCMC 금융공학
5. HPC Simulation
6. Live SR(Super Resolution)
7. 메타버스
o AI, GPU Computing 대두
o Static Programing(CPU) + Dynamic Programing(GPU-AI Model/Inference) 통합 서비스 환경
o CPU Computing + GPU Computing 통합 수행 환경
19. 몇 가지 중요 트랜드(5/8): GP∙GPU Computing(계속)
o GP∙GPU Computing 예) GPU기반 Database System - SQream
o Columnar Database : 원시 데이터는 컬럼 계열로 수직화 분류 및 저장됨
o I/O 단위 최적화 : 컬럼 계열의 데이터는 “Chunking” 되며 메타데이터가 부여 됨
o 모든 “Chunk”는 자동적으로 저장 시 압축 • 로딩 시 압축해제 됨
o 시스템 메모리에 들어온 “Chunk”는 GPU메모리에 적재되며 Parallel Processing 됨
o 성능비교: 국내L통신사 CDR-요금제별 서비스 1일분석업무, Hadoop 100대-1:10:00, SQream 1대 w/ A100x8: 0:19:06
Automatic adaptive
compression
Data Data Data
GPU
Parallel chunk
processing
Data Skipping
Data Data Data
Chunking
Data Data Data
+ Metadata tagging
Columnar process
Data Data
Data
Data
Raw data
Data Data Data
Data Data Data
Data Data Data
GPU
Parallel chunk
processing
GPU 가속
분석DBMS
AMD EPYC 9004 GENOA CPU 96 Cores
vs.
NVIDIA H100 GPU 16,896 FP32 CUDA Cores
20. 몇 가지 중요 트랜드(6/8): Virtualization기반Container기반으로 급속 전환
Cloud
Whitebox Switch H/W+Open vSwitch S/W
== Openflow enabled SDN Switch or Open pSwitch
VxLAN, GRE
Tunnel
옵션#1 옵션#2 옵션#3
Container Container Orchestrator
BareMetal VM Container FaaS...
21. Kubernetes Clustering Platform
CPU 클러스터 운영 클러스터
GPU 클러스터
K8s CSI(Cloud Storage Interface)+CRI-O(Cloud Runtime Interface-OCI)+CNI(Cloud Network Interface), GDS(GPUDirect Storage)
분산병렬스토리지
K8s Container기반 AI-HPC-Bigdata-Quantum(6/8): 통합 플렛폼
DevOps DataOps
MLOps
23. 몇 가지 중요 트랜드(8/8): 양자컴퓨팅과 QML(Quantum Machine Learning)
소스: https://youtu.be/-o9AhIz1uvo?t=880
소스: https://youtu.be/-o9AhIz1uvo?t=1035
Qbit가 추가될 때 마다 NQbitNQbit 병렬처리 능력 향상
24. CNA환경에서 App. 개발전략 및 방법론
MSA(Micro Service Architecture)
&
Service Mesh
31. Container내 MSA모듈 기본구성요소
(Service + Process + DataStore + Infra)
Microservices
K8s App. POD.
Sidecar, Proxy, Agent
Add-on, Interceptor,...
Biz Process
Mini
WWW Engine
Mini Mgmt. Web Page.
http://localhost:15xxx
L-4 LoadBalancer
Service Registry
/health
/config_dump
/env_dump
/logging
/process
/memory
/help
/api
/listeners
/secrets or cert
/ip
/hostname
/datacatalog
/....
Datastore
API-GW Portal
Data Portal
Service Mesh
Web Portal
Service Catalog
Service POD IP Mapping
36. Container Orchestrator(Kubernetes)
S/W적으로 변경가능한 SDDC(SDC, SDS, SDN)형 구성을 위한 모든 인프라 제공
가장 중요한 속성: 주어진 형상을 끝까지 유지하려는 속성
MSA의 De facto Standard 환경
App. 배포 및 서비스에 최적화된 O/S...
37. 전통적인 서비스 수행환경 vs. Kubernetes
Internet L-3 Router Firewall
L-4/L-7
LB Switch
L-2
Access Switch
Servers Storages
Desktop & Notebooks
DNS
Server
vLAN
vLAN
vLAN
vLAN
Backbone
L-3 Switch
41. MSA를 위한 조직문화: CI/CD형 DevOps DataOps + MLOps 까지...
Monolith:
o 개발, 테스트, 배포, 운영조직 분리되어 있었음.
o 다른 쪽으로 일을 던진 후 알아서 처리하라고 잊
어버리는 방식
MSA:
o MSA 개발 및 운영조직 통합(Dev+Ops = DevOps)
o You run it, you build it. 만들면 운영까지 – Amazon
CTO 베르너 보겔수
o 개발팀은 프로젝트 그룹이 아닌 제품(Product) 그
룹에 소속
o 운영과 제품 관리 모두가 포함되어 조직적 구조,
o 제품 팀은 소프트웨어를 만들고 운영하는데 필
요한 모든 것을 소유
42. APIFirst: 외부와의 통일된 MSA 통신패턴: REST API(초-연결)
HTTP, REST API
o HTTP
o 클라이언트의 상태를 가지 않음(Stateless)
o 각 요청은 자기완비적(Self-Contained)
o REST vs. 그 외(EJB, SOAP, etc, ...)
o REST API
o 2000년 로이필딩(Roy Fielding)박사가 소개(HTTP 명세 writer)
o 원격자원(Resource)와 엔티티(Entity)를 다루는 데 초점
o 동사 대신 명사를, 행위 대신 엔티티에 집중
o REST는 기술 표준이 아닌 아키텍처 제약사항
o 상태가 없고 요청이 자기완비적이기 때문에 서비스도 수평적
으로 쉽게 확장
43. APIFirst: 외부와 통신 통제-API Gateway
Microservices
K8s App. POD.
Sidecar, Proxy, Agent
Add-on, Interceptor,...
Biz Process
Mini
WWW Engine
Mini Mgmt. Web Page.
http://localhost:15xxx
L-4 LoadBalancer
Service Registry
/health
/config_dump
/env_dump
/logging
/process
/memory
/help
/api
/listeners
/secrets or cert
/ip
/hostname
/datacatalog
/....
Datastore
45. MSA 복잡성해결사Service Mesh의 출현
MSA
API Gateway
Meshed Service Network
(L-7 Application Layer Networking)
46. MSA 복잡성 문제 해결사: Service Mesh(istio + kiali)
Application-Aware Networking, Application Layer Networking, SDN
다수의 MSA로 구성되는 아키텍처의 특
성을 서비스간 통신과 관련하여 발생하
는 다양한 문제를 해결하는 솔루션
[Envoy Proxy-SDN Data Plane]
o Dynamic service discovery
o Load balancing, TLS termination
o HTTP/2 and gRPC proxies
o Circuit breakers, Health checks
o Staged rollouts with %-based traffic split
o Fault injection, Rich metrics
[Istiod-SDN Controller Plane]
o service discovery
o certificate management
o configuration management
MSA
47. CNA환경에서 Data 분야 변화:
MDA(Micro Data Architecture)
Data Fabric & Data Mesh)
52. Data Warehouse + DataLake Lakehouse
Lakehouse
[Lakehouse의 기능들]
⦿ 거래지원
⦿ 스키마 시행 및 거버넌스
⦿ BI, ML/DL, 데이터 과학, 스트리밍 분석 지원
⦿ 스토리지는 컴퓨팅에서 분리
⦿ 개방 상태
⦿ 비정형 데이터부터 정형 데이터까지 다양한
데이터 유형 지원
⦿ 다양한 워크로드 지원
⦿ 종단 간 스트리밍
57. Micro Data Arch. + Dash Mesh의 출현
소스: https://youtu.be/vXSEV0q_T8g?t=243
58. MDA & Dash Mesh의 출현과 기본원칙
o MACRO Data(DWH, Bigdata, DataLake, LakeHouse) Arch.의 문제점
o 데이타를 한곳에 모이지 않고도 Bigdata의 효과(통합쿼리)를 낼 수 있는 방법은 없을까?
o 그래도, 그래도 데이타는 역시 실-시간 쿼리가 중요한데요 ETC/CDC/ELT은 시간차가 발생합니다.
o MSA-Service Mesh에 맞추어 데이타분야는 어떻게 진화해야 할까요?
o MDA, Data Mesh 기본원칙 by Zhamak Dehghani@Thoughtworks
o 목적: 기존의 중앙집중식 데이터 아키텍처에서 벗어나서 조직 전체에서 데이터를 분산시키고, 자율
적으로 운영 및 관리할 수 있도록 하는 것
o 정의: Data Mesh is a decentralized sociotechnical approach in managing and accessing analytical data at scale.
o 원칙:
1) 도메인 중심 데이터 소유권: 데이터는 도메인에 속하는 비즈니스 팀에서 소유하고 운영
2) 자율적 데이터 팀: 데이터 팀은 자체적으로 의사결정을 내릴 수 있는 자율적인 조직이 되어야 함
3) 분산 데이터 아키텍처: 데이터는 작은 단위로 나누어 각각의 도메인 팀에서 관리하며, 이러한 분
산 데이터가 전체적으로 연결되어서 데이터의 통합성과 일관성을 유지함
4) 데이터 제품화: 데이터를 단순히 저장하는 것이 아니라, 데이터 제품(Product)으로 생각하여 생산,
소비, 재사용 가능한 형태로 관리함
5) 자체 서비스: 데이터 팀은 자체적으로 서비스(Service)를 제공하는 조직이 되어야 함
o 결론: 이러한 기본 원칙을 따르면 분산 데이터 아키텍처와 데이터 제품화를 통해 데이터를 보다 효율
적으로 관리하고, 사용자들이 데이터를 보다 쉽게 이용할 수 있도록 함
소스: https://www.youtube.com/watch?v=_bmYXWCxF_Q
59. Data Fabric = Federated DBMS, No Storage
Super Queryer w/ DataCatalog
Data Virtualization
EDWLDW(Logical DW)
60. MACRO DATAArch. Micro DATAArch.(MDA)로
Microservices
K8s App. POD.
Sidecar, Proxy, Agent
Add-on, Interceptor,...
Biz Process
Mini
WWW Engine
Mini Mgmt. Web Page.
http://localhost:15xxx
L-4 LoadBalancer
Service Registry
/health
/config_dump
/env_dump
/logging
/process
/memory
/help
/api
/listeners
/secrets or cert
/ip
/hostname
/datacatalog
/....
Datastore
o DataStore, not DBMS
o Single Table, not joining
o Tabular, .Json, .Yaml, .XML,...
o Loosely Coupled by Message bus
o Query Engine과 Storage 분리
o Distributed Transaction
o Eventually Consistency
MACRO DATAArchitecture의 문제:
(DWH, Lake, Lakehouse,...)
1) 너무 많은 스토리지 용량
2) 너무 많아지는 데이타 소스
3) MSA에 대한 부적응
4) 실-시간성 부족
69. Dash Mesh의 구현
Data Mesh
Super Queryer
3) Data Linage by
Data Tagging for Data Tracing
2) Super Queryer 도입
DataOps
4) Data Loop
DAG(방향성 비순환 그래프)
5) Data Domain
TTL(Time-to-Live)
1) Dynamic Catalog Update
Data Resource Registry
6) Best Data?
X
70. CNA환경에서 AI Service 통합
MIA(Micro Inference Architecture)
&
Inference Mesh
71. 4차 산업혁명시대의 IT의 위상
IT for Business IT is Business
Data for Business Data is Business
AI for Business AI is Business
AI, Open the age of wisdom
72. AI란 무엇인가?
인간 구성요소의 지능기계화:
육체 로봇
이성 정형데이타, CPU를 위한 정적으로 코드화된 프로그램(수학·논리적인 수리과학 능력 필요)
감정 비정형데이타, GPU에 의한 동적으로 생성되는 프로그램(ML/DL 모델 , 통계 · 자연과학 · 인문학적 능력 필요)
결국, 인간을 닮은
“지능기계”를 만드
는 것
지능(Intelligence): 경험에서 받아들여진 불완전한 지식에 근거한 합리적판단(추론) 능력”이다.
학습(Learning)은 경험된 데이터의 응축(통계모델)을 형성합니다. 불확실성이 없이는 지능도 없다.
딥너링의 대부:
제프리 힌튼 교수
학사: 생리학, 물리학
석사: 철학, 심리학
박사: 인공신경망
대량의 데이타, 대량의 컴퓨팅파워, 대량의 전기를 투입하여,
인간보다 빠르고, 안정적, 누적적으로 지식을 학습하는 과정
73. AIMLDL의 출현(2번의 겨울을 이겨낸 인고의 결과...)
인공신경망(Perceptron)XOR문제xMLP(다층신경망)학습시간↑문제오차역전파로 해결기울기소실문제발생RBM(제한된 볼프만 머쉰),
ReLU함수, 정규화로, Weight초기화로 해결 (Artificial NN(죽은단어X), Big Learning(Big Data선점)) Deep Neural Network출현Deep Learning, DNN
(AlexNet) ImageNet Classification with
Deep CNN(Convolutional Neural Network))
계층적특성학습
SuperVision팀: 제프리 힌튼+알렉스 크리체프스키 +일리야 수츠케버
+니티시 스리바스타바 CNN, GPU활용, OverfittingDropout + 자비어 글로렛 ReLU활성화함수
PEI-PEI LI
14,197,122장 이미지
20,000개 카테고리
인간 5.51%에러:
SuperVision팀: 25%에러율15~16%, Google: 6.65%, MS: 152개 층 3.56% 달성
74. Google 신이 죽고, ChatGPT 신이 오셨다.
100만명 도달: 5일
100만명 도달: 10개월
100만명 도달: 3년
Microsoft 100억 $, 12조원 투자 Google 비상경영 선언
75. AI, "창작의 시대""생성의 시대(Generative Age)"로 전환
o 프로그램은 개발하는 것이 아니에요, 생성하는 것이에요. by chatGPT
o 시나 소설은 창작하는 것이 아니에요 , 생성하는 것이에요. by chatGPT
o 작곡도 창작하는 것이 아니에요, 생성하는 것이에요. by musicplugin, ampermusic, jukedesk
o 그림은 그리는 것이 아니에요, 생성하는 것이에요. by DAL・E 2, midjourney
o 비디오도 촬영하는 것이 아니에요, 생성할 수 있어요. by Runway, Stable Diffusion Videos, Meta AI
o 수십개의 언어에 대한 번역도 사람이 하는 것이 아니라, AI가 할 수 있어요. by Google Translator
76. 결정론적 프로그래밍 vs. 확률론적 프로그래밍
물체의 속성(feature):
질량, 온도, 가속도, 부피, 색깔,…
F=ma
Computer
Data
Program
Output 물체가 받는 힘
그래서, Accel은 얼마는 밟아야…
엄청나게 많은 물체의 속성(feature):
질량, 온도, 가속도, 부피, 색깔,…
(정답)
Computer
DataSet
Program
(Model)
Output
물체가 받는 힘
새로운 Output
Accell의 양은 얼마임
F=ma
새로운 물체의 속성(feature)
기계학습(Machine Learning)
지식공학(Knowledge Engineering)
(정답)
Processing(처리)
Learning(학습) |
Training(훈련)
Prediction(예측)
| Inference(추론)
Service
(정적 코드화)
(동적으로 생성된)
출처: "Field of study that gives computers the ability to learn without being explicitly programmed” Arthur Samuel(1959)
77. AI로 인한 Data에 대한 중요한 관점 변화
소스: https://youtu.be/3Q_XbPmICPg?t=484
78. Deep Learning 수행구조- GRAPH 구조/알고리즘
Vertices(정점)
Node
Gateway
Neuron
Edge(간선)
Link
Connection
Synapse
79. Deep Learning 수행구조
Y = W ・X + b
X1
X2
W1
W2
b
MatMul
(W ・X + b)
Ȳ
XNew
Drop
가중치
갱신
Transfer Function
(Hypothesis)
Activation Function
Optimizer
Forward Propagation
Backward Propagation
MSE
Binary Crossentropy
Categorical Crossentropy
SparseCategoricalCrossentropy
Hings
Huber
KLDivergence
Logcosh
Poisson
Reduction
…
MatMul
Convolution
Pooling
Merge
Recurrent
Embedding
Normalization
Noise
Dense Attention
…
Sigmoid
ReLU
Leaky RelU / PReLU
ELU
Maxout
Tanh
…
GD
SGD
Momentum
NAG
Nadam
Adam
Adagrad
AdaDelta
RMSPorp
Yes
No
Input
Output
Ȳ == Y
Loss Function
(Error, Object)
Yes
No
L1 정규화
L2 정규화
L1-L2 정규화
반복
Backpropagation
Feed Forward
반복
80. AI, Deep Learning Training의 결과 AI Model
초-전환시대 프로그램 짤 시간도 부족해....그냥 AI 동적으로 만들어 주면 않되...
https://playground.tensorflow.org/
83. AGI(Artificial General Intelligence) vs. ASI(Artificial Specialized Intelligence)
일반(범용) 인공지능(artificial general intelligence, AGI)은 인간이 할
수 있는 어떠한 지적인 업무도 성공적으로 해낼 수 있는 (가상적
인) 기계의 지능을 말한다. 이는 인공지능 연구의 주요 목표이며,
SF 작가들이나 미래학자들의 중요한 소재이다. 인공 일반 지능
은 강한 AI, 완전 AI, 또는 '일반 지능적 행동'을 실행하는 기계의 능
력이라고도 한다.
Massive AI Inference Service
ex) OpenAI GPT, DeepMind AlphaGoAlphaZero, StartCraft 2,...
• 찬성론자: 레그(웹마인드), 괴르첼(딥마인드), 샘알트만
(OpenAI)
• 반대론자: 일론머스크(OpenAI), 얀 르쿤 & 앤듀르 응(AI 4대 천
왕 중),...
• AGI의 문제점: 돈, 데이타, 컴퓨팅 파워
• GPT-3: 초-거대 AI 기준, 1,750억 파라메터, 3,000억개 데이
타셋, NVIDIA V100-1,024개, 4개월, 500억 학습비용
• chatGPT 운영비용: 일일10만$(13억원), 매월: 300만$(390억
원) , 유료화 월 30,000원
• Naver Clova AI: 진입비용 1,000억원, 700PF, NVIDIA DGX-
A100 140대, GPU 1,120개
특화 인공지능(Artificial Specialized Intelligence, ASI) '강한 AI'와
구별하여 특정 문제 해결이나 이성적 업무의 연구, 완수
를 위해 사용되는 소프트웨어를 '응용 AI'(또는 '좁은 AI', '약
한 AI')라 부르기도 한다. 약한 AI는 강한 AI와는 반대로 인
간의 인지적 능력의 모든 범위를 수행하려 시도하지 않는
다.
Micro AI Inference Service
ex) 기타 모든 AI..
정적 프로그래밍 보다
AI로 동적생성프로그램 먼저 고려
84. DataLake
DataLake
DataLake
MSA Service Mesh와 AI Inference Service 결합 Inference Mesh
정적프로그램 + 동적프로그램 결합,
Inferencing Mesh
Networked ASI MIA(Micro Inference Arch.)
초-거대 AI
(AGI)
외부-특화AI
(ASI)
외부
AI DataSet
API
API
API
API
API
ASI
ASI
ASI
ASI
ASI
ASI
ASI ASI
ASI
F#1) Model Catalog Update
Model Resource Registry
F#3) Model Linage by
Data Tagging
F#2) Inference Loop
DAG
F#4) Model Domain
TTL(Time-to-Live)
"2025년까지 인공지능을 완전히 가치 창출 워크플로에 흡수하는 기업들은
+120%의 현금 흐름 성장을 이루며, 2030년 세계 경제를 지배할 것.
"맥킨지 글로벌 인스티튜트"
85. 초-거대 AI(AGI) Backbone Network of Neural Network
DataLake
DataLake
DataLake
초-거대 AI(AGI)
Backbone of Neural Network
ASI
ASI
ASI
ASI
ASI
ASI
ASI ASI
ASI
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
특화AI(ASI)
Inferencing Mesh
86. QML(Quantum Machine Learning) for AI
소스: https://youtu.be/-o9AhIz1uvo?t=880
소스: https://youtu.be/-o9AhIz1uvo?t=1035
핵심: Qbit가 추가될 때 마다 NQbitNQbit 병렬처리 능력 향상
88. Cloud, Container, AI, HPC용 분산병렬형 통합스토리지의 중요성(1/2)
네트워크의 성능이 스토리지 성능을 결정
오픈소스형 소프트웨어 정의 분산형 스토리지
통합 I : 객체, 블럭, 파일스토리지
통합 II : Workload별 IOPS, Throughput, Cost & Capacity-최적화
무한 확장성
일반 x86하드웨어에서 동작
결험허용 제공-단일실폐 방지
자동관리, 자동치료 기능
Sage Weil
SAN NAS
Backup /
Archive
GPUDirect Storage Weka POSIX Client
AI Training
분산병렬처리
HPC / Com pute Grid
분산병렬처리
Kubernetes
CSI
수천/ 만개의
Container
스토리지접근
iSCSI, SMB, NFS
Traditional Platform
Protocols
수천/ 만개의 VM
스토리지접근
BLOCK, FileShare, Object FileShare
MPP Hadoop
수백대 DB Engine
스토리지접근
91. DataLake
DataLake
DataLake
초-연결, 초-전환시대는 Cloud전환 후 새로운 S/W Architecture CNA는...
(MSA)Service Mesh | (MDA)Data Mesh| (MIA)Inferencing Mesh over Kubernetes
Service Mesh Inferencing Mesh
Service Mesh
Data Mesh
AI Inferencing Mesh
DevOps DataOps MLOps
Orchestration & Monitoring
Kubernetes Clustering Platform
CPU 클러스터 운영클러스터
GPU 클러스터
K8s CSI(Cloud Storage Interface)+CRI-O(Cloud Runtime Interface-OCI)+CNI(Cloud Network Interface), GDS(GPUDirect Storage)
분산병렬스토리지
nvm e
nvm e
nvm e
nvm e
nvm e
nvm e
Data Mesh
???
???
92. 석기시대가 끝난 이유는...
• "The Stone Age didn't end because they ran out of
stones, but because came up with a better idea", 사
우디 석유장관 "아흐메드 자키 야마니"
• 초-전환, 초-연결시대 세상의 변화들
• MP3 Player iPhone
• 내연기관자동차 전기자동차
• 석유 재생에너지
• KTX에는 개찰구가 없어졌고.
• Next iPhone ChatGPT,...
• 역경(주역)의 결론
窮則變(궁즉변), 變則通(변즉통), 通則久(통즉구)
궁하면 변해야 하고, 변하면 통할 것이요, 통하면 만수무강하다.
92
170km 직선
700조원
midjourney AI inference service on discord:
Keyworld: /imagine prompt Republic of Korea, Port City Busan Metropolitan City,2023 Busan World Expo, Gadeokdo New Airport, 15 minutes City Busan, North Port Re-development, Elko Delta City, Green Smart City
https://cdn.discordapp.com/attachments/1008571063732539392/1066671353941459105/Sang-Bong_Bahk_Republic_of_Korea_Port_City_Busan_Metropolitan_C_90016c8a-99e9-49be-9049-950e49b60e33.png
자:고통, 타:시련
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
자:고통, 타:시련
번역 Google BERT: MNIST DataSet을 함수형태로 훈련시킬 수 있는 신경망을 Python 코드로 만들어 주세요.
ChatGPT: Please write a functional neural network that can train the MNIST Dataset in python code.
개발툴: colab.research.google.com
번역 Google BERT: MNIST DataSet을 함수형태로 훈련시킬 수 있는 신경망을 Python 코드로 만들어 주세요.
ChatGPT: Please write a functional neural network that can train the MNIST Dataset in python code.
개발툴: colab.research.google.com
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
Rich scheduling policies
Volcano supports a variety of scheduling policies:
Gang scheduling
Fair-share scheduling
Queue scheduling
Preemption scheduling
Topology-based scheduling
Reclaim
Backfill
Resource reservation
You can also configure plug-ins and actions to use custom scheduling policies.
Enhanced job management
You can use enhanced job features of Volcano for high-performance computing:
Multi-pod jobs
Improved error handling
Indexed jobs
Multi-architecture computing
Volcano can schedule computing resources from multiple architectures:
x86
Arm
Kunpeng
Ascend
GPU
Faster scheduling
Compared with existing queue schedulers, Volcano shortens the average scheduling delay through a series of optimizations.
Ecosystem
Volcano allows you to use mainstream computing frameworks:
Spark
TensorFlow
PyTorch
Flink
Argo
MindSpore
PaddlePaddle
Open MPI
Horovod
MXNet
Kubeflow
KubeGene
Cromwell
자:고통, 타:시련
Loosely coupled: Not Session, No state, No Transactional, Message Oriented, Eventually Consistency,...
bounded contexts: 제한된 컨텍스트
https://www.youtube.com/watch?v=ZfFj4hOLQKc
Monolithic:
장점: 초기에 Startup일 때
1. 개발 속도가 빠름
2. 테스트하기 쉬움
3. 배포하기 쉬움
4.기능개선이 쉬움
사업이 커지면, 모든 장점이 모든 단점으로 변함
<진흙잡탕 / 에러 두더지 게임>
에러를 고치면 또 다른 Side Effiect이 많음
WAR 파일 배포에 2시간
<야 오늘 배포한대! 관련자들 다 불러>
1. 이걸 고치면 저기에도 영향이 간다.
2. 어플리케이션 시작이 오래 걸림
3. 일반 노트북에서 실행이 안되는 순간이 찾아옴
war 파일은 Web Application aRchive의 약자로 웹 애플리케이션을 이루는 요소들을 한곳에 모아 배포하는데 사용되는 JAR 파일이다. 흔히들 이클립스를 사용하고 로컬에서 웹 애플리케이션을 실행한다면 이러한 배포를 별도로 진행하지 않을 것이다. 이는 이클립스에서 자동으로 등록된 톰캣 서버에 배포를 진행하기 때문이다.
아키텍쳐상 장애가 발생하면 한반에 끝
물귀신 아키텍쳐
<모의해킹 한방에 ALL STOP>
서버 및 프로세스 장애로
서비스가 죽었을 경우
HA(이중화) 도입이 않되어 있다면 그냥 다 죽는 것이다.
<새벽3시...>김과장! 서비스가 죽었어! 빨리 회사로 빨리 와
DB에 값을 넣다. 용량이 꺼지면 다 죽음
DBMS을 바꾸겠다고요? 미쳣습니까 휴먼?
전통을 수호하는 아키텍처
<아키텍처가 Tlq선비라 뭘 도입하거나 바꿀 수가 없어>
새로운 기술 스텍 도입이 어렵다.
차세대 프로젝트라는 단어가 괜히 나온 것이 아니다.
모노리식은 사업이 확장될 수록 서비스가 계속 붙어 결국 Big Ball of mud?
<진흙잡탕 괴물>
단일 애플리케이션에 계속 기능을 계속 붙이다 보면, 신규 개발과 유지보수가 힘들어지는 결말에 직면
물귀신 아키텍쳐
마이크로 서비스란?
API를 통해 통신하는 작고 독립적인 서비스의 모임
MSA의 장점?
1. 향상된 모듈성 유지: 직접적인 DB커넥션, 백도어 등 이상한 짓만 않하면
API라는 국경선으로 서비스가 나뉘어져 있어 기존 모노리식에 비해 애플리케이션의 모듈성을 유지하기 쉽다.
모노리식: 한국, 일본, 중국,...
MSA: 미국식,...
2. 새로운 기술 스텍 도입에 유리
<나 말고 아무도 유지보수 못하게 Ruby로 개발해 보자>
서비스를 독립적으로 배포하며 서비스 간 통신은 API로 하기 때문에 가능
결제기능: Spring과 Oracle
고객관리기능: nodejs와 MariaDB
E-Mail일괄발송: 파이선 장고와 몽고DB로
도룡뇽 아키텍처
<서비스가 독립적으로 배포되어 있어 가능한 현상>
장애가 발새앟면 적어도 장애가 난 곳만 죽습니다.
말 그대로 작다
<서비스가 작아 관리에 유리하다>
코드베이스가 작으니,IDE가 느려지지도 않고, 애플리케이션 시동 시간이 짧음, 배포하는 과정이 빠르다. 생산성 향상
MSA의 단점:
<준비된 자만 다를 수 있는 야생마 같은 아키텍처>
1. 도입의 어려움
2. 복잡한 운영
3. 트랙잭션 유지의 어려움
4. 헬모드 디버깅
쿠팡사례:
문제점:
1. 부분 장애가 전체 서비스 장애로 이어지는 경우가 종종 있음
2. 서비스를 부분적 Scale-Out하기 어려움
3. 서비스 변경이 어렵고, 수정시 영향도를 파악하기 어려움
4. 작은 변경에도 많은 테스트가 필요함
4. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
Loosely coupled: Not Session, No state, No Transactional, Message Oriented, Eventually Consistency,...
bounded contexts: 제한된 컨텍스트
https://www.youtube.com/watch?v=ZfFj4hOLQKc
Monolithic:
장점: 초기에 Startup일 때
1. 개발 속도가 빠름
2. 테스트하기 쉬움
3. 배포하기 쉬움
4.기능개선이 쉬움
사업이 커지면, 모든 장점이 모든 단점으로 변함
<진흙잡탕 / 에러 두더지 게임>
에러를 고치면 또 다른 Side Effiect이 많음
WAR 파일 배포에 2시간
<야 오늘 배포한대! 관련자들 다 불러>
1. 이걸 고치면 저기에도 영향이 간다.
2. 어플리케이션 시작이 오래 걸림
3. 일반 노트북에서 실행이 안되는 순간이 찾아옴
war 파일은 Web Application aRchive의 약자로 웹 애플리케이션을 이루는 요소들을 한곳에 모아 배포하는데 사용되는 JAR 파일이다. 흔히들 이클립스를 사용하고 로컬에서 웹 애플리케이션을 실행한다면 이러한 배포를 별도로 진행하지 않을 것이다. 이는 이클립스에서 자동으로 등록된 톰캣 서버에 배포를 진행하기 때문이다.
아키텍쳐상 장애가 발생하면 한반에 끝
물귀신 아키텍쳐
<모의해킹 한방에 ALL STOP>
서버 및 프로세스 장애로
서비스가 죽었을 경우
HA(이중화) 도입이 않되어 있다면 그냥 다 죽는 것이다.
<새벽3시...>김과장! 서비스가 죽었어! 빨리 회사로 빨리 와
DB에 값을 넣다. 용량이 꺼지면 다 죽음
DBMS을 바꾸겠다고요? 미쳣습니까 휴먼?
전통을 수호하는 아키텍처
<아키텍처가 Tlq선비라 뭘 도입하거나 바꿀 수가 없어>
새로운 기술 스텍 도입이 어렵다.
차세대 프로젝트라는 단어가 괜히 나온 것이 아니다.
모노리식은 사업이 확장될 수록 서비스가 계속 붙어 결국 Big Ball of mud?
<진흙잡탕 괴물>
단일 애플리케이션에 계속 기능을 계속 붙이다 보면, 신규 개발과 유지보수가 힘들어지는 결말에 직면
물귀신 아키텍쳐
마이크로 서비스란?
API를 통해 통신하는 작고 독립적인 서비스의 모임
MSA의 장점?
1. 향상된 모듈성 유지: 직접적인 DB커넥션, 백도어 등 이상한 짓만 않하면
API라는 국경선으로 서비스가 나뉘어져 있어 기존 모노리식에 비해 애플리케이션의 모듈성을 유지하기 쉽다.
모노리식: 한국, 일본, 중국,...
MSA: 미국식,...
2. 새로운 기술 스텍 도입에 유리
<나 말고 아무도 유지보수 못하게 Ruby로 개발해 보자>
서비스를 독립적으로 배포하며 서비스 간 통신은 API로 하기 때문에 가능
결제기능: Spring과 Oracle
고객관리기능: nodejs와 MariaDB
E-Mail일괄발송: 파이선 장고와 몽고DB로
도룡뇽 아키텍처
<서비스가 독립적으로 배포되어 있어 가능한 현상>
장애가 발새앟면 적어도 장애가 난 곳만 죽습니다.
말 그대로 작다
<서비스가 작아 관리에 유리하다>
코드베이스가 작으니,IDE가 느려지지도 않고, 애플리케이션 시동 시간이 짧음, 배포하는 과정이 빠르다. 생산성 향상
MSA의 단점:
<준비된 자만 다를 수 있는 야생마 같은 아키텍처>
1. 도입의 어려움
2. 복잡한 운영
3. 트랙잭션 유지의 어려움
4. 헬모드 디버깅
쿠팡사례:
문제점:
1. 부분 장애가 전체 서비스 장애로 이어지는 경우가 종종 있음
2. 서비스를 부분적 Scale-Out하기 어려움
3. 서비스 변경이 어렵고, 수정시 영향도를 파악하기 어려움
4. 작은 변경에도 많은 테스트가 필요함
4. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
Loosely coupled: Not Session, No state, No Transactional, Message Oriented, Eventually Consistency,...
bounded contexts: 제한된 컨텍스트
https://www.youtube.com/watch?v=ZfFj4hOLQKc
Monolithic:
장점: 초기에 Startup일 때
1. 개발 속도가 빠름
2. 테스트하기 쉬움
3. 배포하기 쉬움
4.기능개선이 쉬움
사업이 커지면, 모든 장점이 모든 단점으로 변함
<진흙잡탕 / 에러 두더지 게임>
에러를 고치면 또 다른 Side Effiect이 많음
WAR 파일 배포에 2시간
<야 오늘 배포한대! 관련자들 다 불러>
1. 이걸 고치면 저기에도 영향이 간다.
2. 어플리케이션 시작이 오래 걸림
3. 일반 노트북에서 실행이 안되는 순간이 찾아옴
war 파일은 Web Application aRchive의 약자로 웹 애플리케이션을 이루는 요소들을 한곳에 모아 배포하는데 사용되는 JAR 파일이다. 흔히들 이클립스를 사용하고 로컬에서 웹 애플리케이션을 실행한다면 이러한 배포를 별도로 진행하지 않을 것이다. 이는 이클립스에서 자동으로 등록된 톰캣 서버에 배포를 진행하기 때문이다.
아키텍쳐상 장애가 발생하면 한반에 끝
물귀신 아키텍쳐
<모의해킹 한방에 ALL STOP>
서버 및 프로세스 장애로
서비스가 죽었을 경우
HA(이중화) 도입이 않되어 있다면 그냥 다 죽는 것이다.
<새벽3시...>김과장! 서비스가 죽었어! 빨리 회사로 빨리 와
DB에 값을 넣다. 용량이 꺼지면 다 죽음
DBMS을 바꾸겠다고요? 미쳣습니까 휴먼?
전통을 수호하는 아키텍처
<아키텍처가 Tlq선비라 뭘 도입하거나 바꿀 수가 없어>
새로운 기술 스텍 도입이 어렵다.
차세대 프로젝트라는 단어가 괜히 나온 것이 아니다.
모노리식은 사업이 확장될 수록 서비스가 계속 붙어 결국 Big Ball of mud?
<진흙잡탕 괴물>
단일 애플리케이션에 계속 기능을 계속 붙이다 보면, 신규 개발과 유지보수가 힘들어지는 결말에 직면
물귀신 아키텍쳐
마이크로 서비스란?
API를 통해 통신하는 작고 독립적인 서비스의 모임
MSA의 장점?
1. 향상된 모듈성 유지: 직접적인 DB커넥션, 백도어 등 이상한 짓만 않하면
API라는 국경선으로 서비스가 나뉘어져 있어 기존 모노리식에 비해 애플리케이션의 모듈성을 유지하기 쉽다.
모노리식: 한국, 일본, 중국,...
MSA: 미국식,...
2. 새로운 기술 스텍 도입에 유리
<나 말고 아무도 유지보수 못하게 Ruby로 개발해 보자>
서비스를 독립적으로 배포하며 서비스 간 통신은 API로 하기 때문에 가능
결제기능: Spring과 Oracle
고객관리기능: nodejs와 MariaDB
E-Mail일괄발송: 파이선 장고와 몽고DB로
도룡뇽 아키텍처
<서비스가 독립적으로 배포되어 있어 가능한 현상>
장애가 발새앟면 적어도 장애가 난 곳만 죽습니다.
말 그대로 작다
<서비스가 작아 관리에 유리하다>
코드베이스가 작으니,IDE가 느려지지도 않고, 애플리케이션 시동 시간이 짧음, 배포하는 과정이 빠르다. 생산성 향상
MSA의 단점:
<준비된 자만 다를 수 있는 야생마 같은 아키텍처>
1. 도입의 어려움
2. 복잡한 운영
3. 트랙잭션 유지의 어려움
4. 헬모드 디버깅
쿠팡사례:
문제점:
1. 부분 장애가 전체 서비스 장애로 이어지는 경우가 종종 있음
2. 서비스를 부분적 Scale-Out하기 어려움
3. 서비스 변경이 어렵고, 수정시 영향도를 파악하기 어려움
4. 작은 변경에도 많은 테스트가 필요함
4. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
아파치 톰캣(Apache Tomcat)은 아파치 소프트웨어 재단에서 개발한 서블릿 컨테이너(또는 웹 컨테이너)만 있는 웹 애플리케이션 서버이다.
톰캣은 웹 서버와 연동하여 실행할 수 있는 자바 환경을 제공하여 자바서버 페이지(JSP)와 자바 서블릿이 실행할 수 있는 환경을 제공하고 있다. 톰캣은 관리툴을 통해 설정을 변경할 수 있지만, XML 파일을 편집하여 설정할 수도 있다. 그리고, 톰캣은 HTTP 서버도 자체 내장하기도 한다.
아파치 톰캣은 Apache Licence, Version 2를 채용한 오픈소스 소프트웨어로서, 자바서버 페이지이나 자바 서블릿를 실행하기 위한 서블릿 컨테이너를 제공하며, 상용 웹 애플리케이션 서버에서도 서블릿 컨테이너로 사용하는 경우가 많다. 버전 5.5 이후는 기본적으로 Java SE 5.0 이후를 대응한다.
참고로 Tomcat은 사전적 의미로 '수고양이'를 뜻한다.
웹 서버와의 연동[편집]
아파치 톰캣에 내장된 웹 서버로만 웹 시스템을 구성할 수 있지만, 대규모의 사용자가 사용하는 시스템을 구축하려면 웹 서버와 연동하는 안정적인 시스템을 구축해야 한다. 이때, 웹 서버인 아파치 HTTP 서버와는 연동모듈을 사용하여 연동하고, 연동모듈로는 버전 1.3, 2.0은 mod_jk를 이용하고, 버전 2.2 이후는 mod_proxy_ajp 모듈을 사용한다.
Hystrix: Circuit Breaker
Ribbon: Client Side Load Balancer
Eureka: Service Registry
Feign: Declarative HTTP Client
Zuul: API Gateway
high cohesion: 높은 응집력
bounded context: DDD에서 서브도메인 내의 도메인 모델을 더 명확하게 표현하기 위한 명시적인 경계를 Bounded Context라 부릅니다. Bounded Context에서는 특정 도메인에 특화된 개념을 유비쿼터스 언어로 정의하며, 이 개념들의 관계를 ‘독자적인’ 도메인 모델(속성 + 오퍼레이션)로 표현합니다.(실제로는 시스템, 비즈니스 서비스를 표현하기도 합니다.)
느슨한 결합(Loose Coupling)
느슨한 결합은 하나의 콤포넌트의 변경이 다른 콤포넌트들의 변경을 요구하는 위험을 줄이는 것을 목적으로 하는 시스템에서 콤포넌트 간의 내부 의존성을 줄이는 것을 추구하는 디자인 목표다. 느슨한 결합은 시스템을 더욱 유지 할 수 있도록 만들고, 전체 프레임워크를 더욱 안정적으로 만들고 시스템의 유연성을 증가하게 하려는 의도를 가진 포괄적인 개념이다.
(Loose Coupling의 강력함) 두 객체가 느슨하게 결합되어 있다는 것은, 그 둘이 상호작용을 하긴 하지만 서로에 대해서 서로 잘 모른다는 것을 의미합니다.간단히 말하면 느슨한 결합은 대부분 독립적이라는 의미입니다.
스프링 프레임 워크는 객체 간의 긴밀한 결합 문제를 극복하기 위해 POJO / POJI 모델의 도움으로 의존성 주입 메커니즘을 사용하며 의존성 주입을 통해 느슨한 결합을 달성 할 수 있습니다.
Translation, Session을 맺지 않는다.
• REST API를 이용해서 Sessionless한 환경으로 운영된다.
• Kafka와 같은 pub-sub모델의 메세지 큐, 메세지 브로커를 이용하여 Eventually Consistency 확보한다.
Java JMI
예 : 셔츠를 갈아 입으면 몸을 바꾸지 않아도됩니다. 그렇게 할 수 있을 때 커플링이 느슨합니다. 그렇게 할 수 없다면, 긴밀한 결합이 있습니다. 느슨한 결합의 예는 인터페이스, JMS(Java Message Service)입니다.
Tightly Coupled(밀결합)
피부를 바꾸려면 몸이 서로 결합되어 있기 때문에 몸의 디자인도 바꿔야합니다. 밀접한 결합의 가장 좋은 예는 RMI (Remote Method Invocation)입니다.
Java RMI(Remote Method Invocation)
Tight Coupling과 Loose Coupling의 차이점
Tight Coupling은 시험 가능성이 좋지 않습니다. 그러나 Loose Coupling은 시험 가능성을 향상시킵니다.
일반적으로 Tight Coupling은 대부분의 경우 코드의 유연성과 재사용성을 감소 시키므로 변경을 훨씬 어렵게 만들고 시험 가능성(Testability) 등을 방해합니다.
Loose Couplingd은 응용 프로그램을 변경하거나 확장해야 할 때 느슨하게 결합 된 아키텍처로 디자인하는 경우 요구 사항이 변경 될 때마다 응용 프로그램의 일부에만 영향을 미칩니다.
Tight Coupling은 인터페이스 개념을 제공하지 않습니다. 그러나 Loose Coupling은 구현이 아닌 인터페이스에 대한 프로그램의 GOF 원칙을 따르는 데 도움이됩니다.
Tight Coupling에서는 두 클래스간에 코드를 쉽게 교체 할 수 없습니다. 그러나 Loose Coupling으로 다른 코드 / 모듈 / 객체 / 구성 요소를 교체하는 것이 훨씬 쉽습니다.
Tight Coupling에는 변경 기능이 없습니다. 그러나 Loose Coupling은 크게 변경 가능합니다.
representation state transfer
gRPC:
구글이 최초로 개발한 오픈 소스 원격 프로시저 호출 시스템이다. 전송을 위해 HTTP/2를, 인터페이스 정의 언어로 프로토콜 버퍼를 사용하며 인증, 양방향 스트리밍 및 흐름 제어, 차단 및 비차단 바인딩, 취소 및 타임아웃 등의 기능을 제공한다.
https://docs.microsoft.com/ko-kr/aspnet/core/grpc/comparison?view=aspnetcore-6.0
gRPC 서비스와 HTTP API 비교
아티클
2022. 07. 06.
읽는 데 12분 걸림
기여자 6명
작성자: James Newton-King
이 문서에서는 gRPC 서비스와 JSON을 사용한 HTTP API(ASP.NET Core Web API 포함)를 비교하는 방법을 설명합니다. 앱에 대한 API를 제공하는 데 사용되는 기술은 중요한 선택 이며 gRPC는 HTTP API와 비교해서 고유한 이점을 제공합니다. 이 문서에서는 gRPC의 장점과 단점을 설명하 고 다른 기술에서 gRPC를 사용하는 시나리오를 권장합니다.
개괄적인 비교
다음 표에서는 gRPC와 JSON을 사용하는 HTTP API 간의 고급 기능 비교를 제공합니다.
기능gRPCJSON을 사용하는 HTTP API계약필수(.proto)선택 사항(OpenAPI)프로토콜HTTP/2HTTPPayloadProtobuf(소형, 이진)JSON(대형, 사람이 읽을 수 있음)규범엄격한 사양느슨함. 모든 HTTP가 유효합니다.스트리밍클라이언트, 서버, 양방향클라이언트, 서버브라우저 지원아니요(gRPC-웹 필요)예보안전송(TLS)전송(TLS)클라이언트 코드 생성예OpenAPI + 타사 도구
gRPC 장점
성능
gRPC 메시지는 효율적인 이진 메시지 형식인 Protobuf를 사용하여 직렬화됩니다. Protobuf는 서버와 클라이언트에서 매우 빠르게 직렬화합니다. Protobuf serialization은 작은 메시지 페이로드를 발생시키며 이는 모바일 앱과 같은 제한된 대역폭 시나리오에서 중요합니다.
gRPC는 HTTP 1.x에 비해 상당한 성능 이점을 제공하는, HTTP의 주요 개정판인 HTTP/2용으로 설계되었습니다.
이진 프레이밍 및 압축. HTTP/2 프로토콜은 간단하며, 보내고 받을 때 모두 효율적입니다.
단일 TCP 연결보다 여러 HTTP/2 호출의 멀티플렉싱. 멀티플렉싱은 HOL(Head of Line) 차단을 제거합니다.
HTTP/2는 gRPC에만 국한되지 않습니다. JSON을 사용한 HTTP API를 포함하여 다양한 요청 형식에서 HTTP/2를 사용하고 성능 개선을 활용할 수 있습니다.
코드 생성
모든 gRPC 프레임워크는 코드 생성에 대한 최고 수준의 지원을 제공합니다. gRPC 개발의 핵심 파일은 gRPC 서비스 및 메시지의 계약을 정의하는 .proto 파일입니다. gRPC 프레임워크는 이 파일에서 서비스 기본 클래스, 메시지, 전체 클라이언트를 생성합니다.
서버와 클라이언트 간에 .proto 파일을 공유하여 메시지와 클라이언트 코드를 종단 간에 생성할 수 있습니다. 클라이언트의 코드 생성은 클라이언트와 서버에서 메시지의 중복을 제거하고 강력한 형식의 클라이언트를 만듭니다. 클라이언트를 작성하지 않아도 되므로 많은 서비스를 갖춘 응용 프로그램의 개발 시간이 상당히 절감됩니다.
엄격한 사양
JSON을 사용하는 HTTP API에 대한 공식 사양은 없습니다. 개발자는 URL, HTTP 동사 및 응답 코드의 가장 좋은 형식을 논의합니다.
gRPC 사양은 gRPC 서비스가 따라야 하는 형식에 대한 지침입니다. gRPC는 플랫폼 및 구현에 상관없이 일치하므로 논쟁이 불필요하며 개발자 시간을 절약합니다.
스트리밍
HTTP/2는 수명이 긴 실시간 통신 스트림에 대한 기초를 제공합니다. gRPC는 HTTP/2를 통한 스트리밍을 위한 최고 수준의 지원을 제공합니다.
gRPC 서비스는 모든 스트리밍 조합을 지원합니다.
단항(스트리밍 없음)
서버-클라이언트 스트리밍
클라이언트-서버 스트리밍
양방향 스트리밍
최종 기한/시간 초과 및 취소
gRPC는 클라이언트가 RPC가 완료될 때까지 대기하는 기간을 지정하도록 할 수 있습니다. 최종 기한이 서버에 전송되고 서버에서 최종 기한을 초과하는 경우 수행할 작업을 결정할 수 있습니다. 예를 들어 서버에서 제한 시간에 진행 중인 gRPC/HTTP/데이터베이스 요청을 취소할 수 있습니다.
자식 gRPC 호출을 통해 최종 기한 및 취소를 전파하면 리소스 사용 제한을 강제로 적용할 수 있습니다.
gRPC 권장 시나리오
gRPC는 다음과 같은 시나리오에 적합합니다.
마이크로 서비스: gRPC는 대기 시간이 짧고 처리량이 높은 통신을 위해 설계되었습니다. gRPC는 효율성이 중요한 경량 마이크로 서비스에 적합합니다.
지점 간 실시간 통신: 양방향 스트리밍을 위한 뛰어난 지원 기능을 제공합니다. gRPC 서비스는 폴링을 사용하지 않고 실시간으로 메시지를 푸시할 수 있습니다.
Polyglot 환경: gRPC 도구는 널리 사용되는 모든 개발 언어를 지원하며, 따라서 gRPC는 다중 언어 환경에 적합합니다.
네트워크 제한 환경: gRPC 메시지는 경량 메시지 형식인 Protobuf를 사용하여 직렬화됩니다. gRPC 메시지는 해당하는 JSON 메시지보다 항상 작습니다.
IPC(프로세스 간 통신) : Unix 도메인 소켓 및 명명된 파이프와 같은 IPC 전송은 gRPC에서 동일한 머신에 있는 앱 간에 통신하는 데 사용할 수 있습니다. 자세한 내용은 gRPC와 프로세스 간 통신을 참조하세요.
gRPC 약점
제한된 브라우저 지원
현재 브라우저에서 gRPC 서비스를 직접 호출하는 것은 불가능합니다. gRPC는 HTTP/2 기능을 많이 사용하며, 브라우저에서 gRPC 클라이언트를 지원하기 위해 웹 요청에 필요한 제어 수준을 제공하지 않습니다. 예를 들어, 브라우저는 호출자가 HTTP/2를 사용하도록 요구하거나 기본 HTTP/2 프레임에 대한 액세스를 제공하지 않습니다.
다음과 같은 두 가지 일반적인 방법으로 gRPC를 브라우저 앱으로 가져올 수 있습니다.
gRPC-Web은 브라우저에서 gRPC 지원을 제공하는 gRPC 팀의 추가 기술입니다. gRPC-Web을 사용하면 브라우저 앱에서 gRPC의 고성능과 낮은 네트워크 사용량을 활용할 수 있습니다. gRPC-웹에서 모든 gRPC 기능을 지원하지는 않습니다. 클라이언트 및 양방향 스트리밍이 지원되지 않으며 서버 스트리밍이 제한적으로 지원됩니다.
.NET Core는 gRPC-Web을 지원합니다. 자세한 내용은 브라우저 앱에서 gRPC 사용을 참조하세요.
RESTful JSON 웹 API는 HTTP 메타데이터로 .proto 파일에 주석을 달아 gRPC 서비스에서 자동으로 만들 수 있습니다. 따라서 앱은 gRPC와 JSON 웹 API 둘 다에 대해 별도의 서비스를 구축하는 노력을 들이지 않고도 둘 다를 지원할 수 있습니다.
.NET Core는 gRPC 서비스에서 JSON 웹 API 만들기에 대한 실험적인 지원을 제공합니다. 자세한 내용은 gRPC JSON 코드 변환을 참조하세요.
사람이 읽을 수 없음
HTTP API 요청은 텍스트로 전송되며, 사람이 읽고 만들 수 있습니다.
gRPC 메시지는 기본적으로 Protobuf로 인코딩됩니다. Protobuf는 송신 및 수신에 효율적이지만, 이진 형식은 사람이 읽을 수 없습니다. Protobuf를 사용하려면 올바른 역직렬화를 위해 .proto 파일에 지정된 메시지의 인터페이스 설명이 필요합니다. 네트워크에서 Protobuf 페이로드를 분석하고 요청을 직접 작성하려면 추가 도구가 필요합니다.
서버 리플렉션 및 gRPC 명령줄 도구와 같은 기능은 이진 Protobuf 메시지를 지원하기 위해 존재합니다. 또한 Protobuf 메시지는 JSON 변환을 지원합니다. 기본 제공 JSON 변환은 디버그할 때 Protobuf 메시지를 사람이 읽을 수 있는 형식으로 변환하는 효율적인 방법을 제공합니다.
대체 프레임워크 시나리오
다음과 같은 시나리오에서는 gRPC보다 다른 프레임워크가 권장됩니다.
브라우저에서 액세스 가능한 API: gRPC는 브라우저에서 완전히 지원되지는 않습니다. gRPC-웹은 브라우저 지원을 제공할 수 있지만 제한 사항이 있으며 서버 프록시를 도입합니다.
브로드캐스트 실시간 통신: gRPC는 스트리밍을 통해 실시간 통신을 지원하지만 등록된 연결에 메시지를 브로드캐스트하는 개념이 없습니다. 예를 들어 대화방의 모든 클라이언트에 새 채팅 메시지를 보내야 하는 대화방 시나리오에서 각 gRPC 호출은 클라이언트에 새 채팅 메시지를 개별적으로 스트리밍하는 데 필요합니다. SignalR은 이 시나리오에 유용한 프레임워크입니다. SignalR에는 영구 연결 개념과 메시지 브로드캐스트에 대한 기본 제공 지원이 있습니다
자:고통, 타:시련
MPP의 문제: CPU를 이용한 데이타로딩과 압축저장 시 CPU 50%육박(10Gbps, 1.2Gbyte처리시)
Insight:
1. 종류가 많다는 것은 DBMS가 기업들의 핵심 IT자산이라는 것이다.
2. 다중 특성을 가진 DB들이 많아서 분류가 쉽지 않다.
3. 위 분류는 인터넷 기업이 아닌 일반기업 중심, RDMS회사들 중심으로 분류된 것이다.
4. MPP는 EDW용도가 주 포인트였다.
http://m.bikorea.net/news/articleView.html?idxno=26470
HP-Vertica
SAP-Sybase IQ
AWS-Redshift
https://d2.naver.com/helloworld/29533
NO-SQL:
http://www.incodom.kr/NoSQL_DB_%EC%9D%98_%EC%A2%85%EB%A5%98
NoSQL DB의 종류
NoSQL DB의 종류에는 크게 4가지 유형이 존재한다. DOCUMENT STORE 또는 DOCUMENT DATABASE, WIDE COLUMN STORE 또는 WIDE COLUMN DATABASE, KEY-VALUE STORE 또는 KEY-VALUE DATABASE, 그리고 GRAPH DATABASE가 있다. 본 글에서는 이런 NoSQL DB의 종류들과 그 개념들을 간략하게 알아보도록 한다.
WIDE COLUMN DATABASE
행마다 키와 해당 값을 저장할 때마다 각각 다른값의 다른 수의 스키마를 가질 수 있다. '그림2'를 참고하면 사용자의 이름(key)에 해당하는 값에 스키마들이 각각 다름을 볼 수 있다. 이러한 구조를 갖는 WIDE COLUMN DATABASE 는 대량의 데이터의 압축, 분산처리, 집계 쿼리 (SUM, COUNT, AVG 등)및 쿼리 동작 속도 그리고 확장성이 뛰어난 것이 그 대표적 특징이라 할 수 있다.
대표적인 DATABASE
Cassandra
HBase
GoogleBigTable
Vertica
Druid
Accumulo
Hypertable
DOCUMENT DATABASE
테이블의 스키마가 유동적, 즉 레코드마다 각각 다른 스키마를 가질 수 있다. 보통 XML, JSON과 같은 DOCUMENT를 이용해 레코드를 저장한다. 트리형 구조로 레코드를 저장하거나 검색하는 데 효과적이다.
대표적인 DATABASE
MongoDB
Azure Cosmos DB
CouchDB
MarkLogic
OrientDB
GRAPH DATABASE
데이터를 노드로(그림4에서 파란, 녹색 원) 표현하며 노드 사이의 관계를 엣지(그림4에서 화살표)로 표현, RDBMS 보다 Performance가 좋고 유연하며 유지보수에 용이한 것이 특징. Social networks, Network diagrams 등에 사용할 수 있다.
대표적인 DATABASE #
Neo4j
Blazegraph
OrientDB
KEY-VALUE DATABASE
기본적인 패턴으로 KEY-VALUE 하나의 묶음(Unique)으로 저장되는 구조로 단순한 구조이기에 속도가 빠르며 분산 저장시 용이하다.Key 안에 (COLUMN, VALUE) 형태로 된 여러 개의 필드, 즉 COLUMN FAMILIES 갖는다. 주로 SERVER CONFIG, SESSION CLUSTERING등에 사용되고 엑세스 속도는 빠르지만, SCAN에는 용이하지 않다.
대표적인 DATABASE
Redis
Oracle NoSQL Database
Voldemorte
Oracle Berkeley DB
Memcached
Hazelcast
Data Mesh는 최근에 소개된 새로운 데이터 아키텍처 패턴입니다. 기존의 중앙집중식 데이터 아키텍처에서 벗어나서 조직 전체에서 데이터를 분산시키고, 자율적으로 운영 및 관리할 수 있도록 하는 것이 목적입니다. 이를 위해 Data Mesh는 다음과 같은 기본 원칙을 제안합니다.
도메인 중심 데이터 소유권: 데이터는 도메인에 속하는 비즈니스 팀에서 소유하고 운영합니다. 이는 데이터를 생성하고 가공하는 일련의 작업에 대한 책임을 도메인 팀에게 부여하여, 데이터 품질과 더불어 데이터 이해도와 활용도를 높이기 위함입니다.
자율적 데이터 팀: 데이터 팀은 자체적으로 의사결정을 내릴 수 있는 자율적인 조직이 되어야 합니다. 데이터 스키마, 저장소, 프로세스, 파이프라인 등 데이터에 대한 모든 측면을 자율적으로 관리하며, 데이터 품질과 데이터 사용자 요구사항을 충족하는 책임을 지게 됩니다.
분산 데이터 아키텍처: 중앙 집중식 데이터 아키텍처가 아니라, 분산 데이터 아키텍처를 채택합니다. 이를 위해서 데이터는 작은 단위로 나누어 각각의 도메인 팀에서 관리하며, 이러한 분산 데이터가 전체적으로 연결되어서 데이터의 통합성과 일관성을 유지할 수 있도록 합니다.
데이터 제품화: 데이터를 단순히 저장하는 것이 아니라, 데이터 제품(Product)으로 생각하여 생산, 소비, 재사용 가능한 형태로 관리합니다. 이를 통해 데이터를 서비스로써 제공하고, 데이터를 이용하는 비즈니스 측면에서는 데이터를 이해하고 활용하기 쉽도록 합니다.
자체 서비스: 데이터 팀은 자체적으로 서비스(Service)를 제공하는 조직이 되어야 합니다. 이는 데이터를 소비하는 사용자들을 위한 데이터 검색, 데이터 카탈로그, 데이터 보안 및 데이터 모니터링 등을 제공하여 데이터 사용의 용이성과 안정성을 확보합니다.
이러한 기본 원칙은 Data Mesh를 구성하는 핵심 요소이며, 각각의 원칙은 분산 데이터 아키텍처와 데이터 제품화를 위한 설계와 개발에 대한 지
자:고통, 타:시련
4차 산업의 기본 동력이 “데이타”가 되면서, 이것을 기반으로 IoT, BigData, AI, 블럭체인들이 그것을 사용하여 새로운 비지니스를 창출하는 엔진들로 인식되고 있습니다.
그로인한 IT(정보기술)의 위상도 급격하게 변하고 있습니다.
“IT for Business” 즉 비지니스의 도구로써의 IT가 “IT is Business” 변화, 즉 IT 자체가 비지니스가 된다는 인식으로 바뀌고 있습니다. 마찬가지로,
“Data for Business”, 비지니스를 위한 데이타에서, “Data is Business”, 데이타 자체가 비지니스의 가치를 가지며,
또한,
AI도 “AI for Business”, 현재는 AI도 비지니스를 도와주는 도구이지만, 바로 “AI is Business”, 즉, AI 자체가 비지니스가 될 것으로 예상됩니다.
AI는 우리가 일을 하는 방식을 근본적으로 되돌아보게 하고 있습니다. 혹시 이것 AI로 되는 것이 아니야? 혹시 이것 AI로하면 지금하는 방식보다는 훨씬 효율적으로 할 수 있는 것이 아니야? 이런 질문들이 들어옵니다.
이러한 시대적 흐름에 의해 영국 그래프코어와 저의 메가존클라우드는 고객사와 협력사들에 최고의 AI 솔루션을 제공하고자 노력하고 있습니다.
존 매카시(John McCarthy, 1927년 9월 4일 - 2011년 10월 24일) 박사는 미국의 전산학자이자 인지과학자이다. 인공지능에 대한 연구 업적을 인정받아 1971년 튜링상을 수상했다. 리스프 프로그래밍 언어를 설계 및 구현하였으며, 1956년에 다트머스 학회에서 처음으로 인공지능(Artificial Intelligence)이라는 용어를 창안했다.
서양철학이 추구하는 인간관: 칸트 진선미, 미스코리아 진선미
내가 그린 그림에 맞는 시와 음악을 함께 작성할 수 있다. 예술창작가들을 위하 새로운도구, 백남준 비디오아트를 생각해 보라.
Intelligence
The capacity for rational judgement(inference) based on imperfect knowledge adapted with experience”
Learning is forming a condensate (statistical model) of experienced data.
There is no intelligence without uncertainty.
AI분야 4대 천황: 제프리 힌튼, 죠수야 벤지오, 얀 르쿤, 엔듀르 응
1. 퍼셉트론(Perceptron)이란?
-프랑크 로젠블라트가 1957년에 고안한 알고리즘으로 Neural-Network(신경망)의 기원이 되는 알고리즘.
-가장 오래되고 단순한 형태의 판별 함수 기반 예측 모형(discriminant function based predition model) 중 하나
-퍼셉트론은 다수의 신호를 받아(input) 하나의 신호(0 또는 1)로 출력(output).
XOR문제 해결을 위한 MLP(Multi-Layered Perceptron) 제안, 그러나
Minsky 교수는 해결책을 고심하긴 했습니다. 그것이 MultiLayer Perceptron(MLP)입니다. MLP는 입력층과 출력층 사이에 하나 이상의 중간 레이어가 있어서 비선형 데이터도 학습이 가능합니다. 문제는 parameter를 업데이트하려면 목표값과 출력값의 비교가 필요합니다. 이것이 입력층과 출력층만 있을 때는 문제가 되지 않았지만 중간층이 존재하고 나서는 중간층의 목표값은 무엇인지 알 수가 없는 것입니다. 이 당시에 이러한 이유로 인공신경망 연구는 침체기를 걷습니다.
MLP의 이러한 제한사항을 극복한 것이 backpropagation(역전파)입니다. 두둥
Hinton교수(Google): 제자인 얀레쿤) 교수와 딥러링 발표, 오류역전파기술: G.Hinton 교수가 재-발견
얀레쿤(Facebook): 블라디미르뱁니크와 SVM(Support Vector Machine)발표), CNN(w/ Hinton)저작
요슈아 벤지요(Yoshua Bengil)-알고리즘 수학적 규명,
유르겐 슈미트후버(Jurgen Schmidhuber)-재귀망 난제 해결
Deep Learning vs. Traditional Computer Vision
인공 신경망
XOR 문제
퍼셉트론 모델로는 간단한 XOR 문제를 풀 수 없음이 증명됨
다층 퍼셉트론(Multilayer Perceptron)
XOR 문제를 해결하기 위해선 다층 퍼셉트론 모델이 필요하지만, 학습시킬 수 있는 방법이 없음(1969)
약 20년간 1차 AI 겨울
역전파(Backpropagation)
최종 계산된 결과를 통해 가중치를 역으로 계산해내는 기법 개발되어 다층 퍼셉트론 문제 해결(1986)
기울기 소실 문제(Vanishing Gradient Problem)
Gradient Vanishing & Exploding:
W = W -learning_rate * (QE/QW)
Vanishing: 0이하의 Gradient를 여러번 곱하다 보면 결국 0에 가까운 값이 되어 기존의 Weight값이 변화가 없게되는 것,
Exploding: 1이상의 값을 너무 많이 곱하다 보면 값이 너무 커져서 기본의 weight값이 너무 달라지는 현상
다중 퍼셉트론 구조로 XOR 문제는 해결 가능하지만, 레이어가 많아질 경우 가중치 계산이 불가능해 지는 문제 발견, 즉 역전파값이 뒤로 깔대 X Input쪽에 가까워 질 수록 영향을 적게 주는 것, 약 15년간 2차 AI 겨울,
다층 퍼셉트론 모델이 아닌 SVM 등의 다른 메커니즘 출현
ReLU의 적용으로 기울시 소실 문제를 해결하고, 딥 러닝 등장
2006년 : 캐나다 토론토대학의 제프리힌튼 교수, 신경망네트워크(Neural Network) 딥러닝 알고리즘 발표
2012년 : 토론토대학 제프리힌튼교수 연구실의 알렉스 ㅊ크리제브스키(Alex Krizhevsky)가 IMAGENET(이미지인식 경진대회)에서 딥러닝알고리즘 활용하여 우승함으로서 진정한 의미의 인공지능의 부흥기 시작이면서 Perceptron(단일 신경망)MLP(Multi-layered Perceptron, 다층 신경망)원래는 Big Learning으로 하고 싶었는데 Big Data가 선정해서 Deep Learning으로 부르기로 함.
IMAGENET은 1000개의 카테고리와 100만개의 이미지로 이미지인식의 정확도를 겨루는 대회였고 기존에 75%의 정확도를 넘어서 알렉스는 84.7%의 정확도로 우승하게 됩니다.
2015년에는 MS팀이 IMAGENET에서 GPU를 사용하여 무려 96%의 정확도로 우승을 차지하기도 합니다.
2012년 제프리힌튼교수의 딥러닝알고리즘의 발표후 인공지능이 다시 부활할수 있었던것은 검색엔진을 통해 인터넷혁명이 일어나고 이에 따른 1) 빅데이터의 발전과 2) GPU등과 처리플랫폼으로 컴퓨팅능력의 향상, 그리고 우연이었지만 Drop Out과 ReLU 활성화 함수, 정규화를 사용하여 3) 과적합문제(Overfit)의 해결을 통해 인공지능의 새로운 도약이 가능했습니다.
제프리힌튼(Geoffrey Hinton 토론토대)교수가 발표했던 딥러닝 연구는 앤드류응(Andrew Ng 스탠퍼드대 교수)과 얀레쿤(Yan Lecun 뉴욕대교수)과 같은 AI 구루들에 의해 발전되어가고 이후 이 세명은 구글, 페이스북, 바이두 같은 글로벌 IT 기업에 영입되어 기술의 발전이 더 가속화 되게 됩니다.
2006년에 알파고가 이세돌에게 바둑 승리
서포트 벡터 머신(support vector machine, SVM[1].[2])은 기계 학습의 분야 중 하나로 패턴 인식, 자료 분석을 위한 지도 학습 모델이며, 주로 분류와 회귀 분석을 위해 사용한다. 두 카테고리 중 어느 하나에 속한 데이터의 집합이 주어졌을 때, SVM 알고리즘은 주어진 데이터 집합을 바탕으로 하여 새로운 데이터가 어느 카테고리에 속할지 판단하는 비확률적 이진 선형 분류 모델을 만든다. 만들어진 분류 모델은 데이터가 사상된 공간에서 경계로 표현되는데 SVM 알고리즘은 그 중 가장 큰 폭을 가진 경계를 찾는 알고리즘이다. SVM은 선형 분류와 더불어 비선형 분류에서도 사용될 수 있다. 비선형 분류를 하기 위해서 주어진 데이터를 고차원 특징 공간으로 사상하는 작업이 필요한데, 이를 효율적으로 하기 위해 커널 트릭을 사용하기도 한다.
[기울기 소실(Gradient Vanishing)과 폭주(Exploding)]
깊은 인공 신경망을 학습하다보면 역전파 과정에서 입력층으로 갈 수록 기울기(Gradient)가 점차적으로 작아지는 현상이 발생할 수 있습니다. 입력층에 가까운 층들에서 가중치들이 업데이트가 제대로 되지 않으면 결국 최적의 모델을 찾을 수 없게 됩니다. 이를 기울기 소실(Gradient Vanishing)이라고 합니다.
반대의 경우도 있습니다. 기울기가 점차 커지더니 가중치들이 비정상적으로 큰 값이 되면서 결국 발산되기도 합니다. 이를 기울기 폭주(Gradient Exploding)이라고 하며, 뒤에서 배울 순환 신경망(Recurrent Neural Network, RNN)에서 발생할 수 있습니다.
1. ReLU와 ReLU의 변형들
앞에서 배운 내용을 간단히 복습해봅시다. 시그모이드 함수를 사용하면 입력의 절대값이 클 경우에 시그모이드 함수의 출력값이 0 또는 1에 수렴하면서 기울기가 0에 가까워집니다. 그래서 역전파 과정에서 전파 시킬 기울기가 점차 사라져서 입력층 방향으로 갈 수록 제대로 역전파가 되지 않는 기울기 소실 문제가 발생할 수 있습니다.
기울기 소실을 완화하는 가장 간단한 방법은 은닉층의 활성화 함수로 시그모이드나 하이퍼볼릭탄젠트 함수 대신에 ReLU나 ReLU의 변형 함수와 같은 Leaky ReLU를 사용하는 것입니다.
은닉층에서는 시그모이드 함수를 사용하지 마세요.
Leaky ReLU를 사용하면 모든 입력값에 대해서 기울기가 0에 수렴하지 않아 죽은 ReLU 문제를 해결합니다.
은닉층에서는 ReLU나 Leaky ReLU와 같은 ReLU 함수의 변형들을 사용하세요.
2. 그래디언트 클리핑(Gradient Clipping)
그래디언트 클리핑은 말 그대로 기울기 값을 자르는 것을 의미합니다. 기울기 폭주를 막기 위해 임계값을 넘지 않도록 값을 자릅니다. 다시 말해서 임계치만큼 크기를 감소시킵니다. 이는 RNN에서 유용합니다. RNN은 BPTT에서 시점을 역행하면서 기울기를 구하는데, 이때 기울기가 너무 커질 수 있기 때문입니다. 케라스에서는 다음과 같은 방법으로 그래디언트 클리핑을 수행합니다.
from tensorflow.keras import optimizers Adam = optimizers.Adam(lr=0.0001, clipnorm=1.)
3. 가중치 초기화(Weight initialization)
같은 모델을 훈련시키더라도 가중치가 초기에 어떤 값을 가졌느냐에 따라서 모델의 훈련 결과가 달라지기도 합니다. 다시 말해 가중치 초기화만 적절히 해줘도 기울기 소실 문제과 같은 문제를 완화시킬 수 있습니다.
1) 세이비어 초기화(Xavier Initialization)
논문 : http://proceedings.mlr.press/v9/glorot10a/glorot10a.pdf
2010년 세이비어 글로럿과 요슈아 벤지오는 가중치 초기화가 모델에 미치는 영향을 분석하여 새로운 초기화 방법을 제안했습니다. 이 초기화 방법은 제안한 사람의 이름을 따서 세이비어(Xavier Initialization) 초기화 또는 글로럿 초기화(Glorot Initialization)라고 합니다.
이 방법은 균등 분포(Uniform Distribution) 또는 정규 분포(Normal distribution)로 초기화 할 때 두 가지 경우로 나뉘며, 이전 층의 뉴런 개수와 다음 층의 뉴런 개수를 가지고 식을 세웁니다. 이전 층의 뉴런의 개수를 ninnin, 다음 층의 뉴런의 개수를 noutnout이라고 해봅시다.
2) He 초기화(He initialization)
논문 : https://www.cv-foundation.org/openaccess/content_iccv_2015/papers/He_Delving_Deep_into_ICCV_2015_paper.pdf
He 초기화(He initialization)는 세이비어 초기화와 유사하게 정규 분포와 균등 분포 두 가지 경우로 나뉩니다. 다만, He 초기화는 세이비어 초기화와 다르게 다음 층의 뉴런의 수를 반영하지 않습니다. 전과 같이 이전 층의 뉴런의 개수를 ninnin이라고 해봅시다.
He 초기화는 균등 분포로 초기화 할 경우에는 다음과 같은 균등 분포 범위를 가지도록 합니다.
4. 배치 정규화(Batch Normalization)
ReLU 계열의 함수와 He 초기화를 사용하는 것만으로도 어느 정도 기울기 소실과 폭주를 완화시킬 수 있지만, 이 두 방법을 사용하더라도 훈련 중에 언제든 다시 발생할 수 있습니다. 기울기 소실이나 폭주를 예방하는 또 다른 방법은 배치 정규화(Batch Normalization)입니다. 배치 정규화는 인공 신경망의 각 층에 들어가는 입력을 평균과 분산으로 정규화하여 학습을 효율적으로 만듭니다.
1) 내부 공변량 변화(Internal Covariate Shift)
배치 정규화를 이해하기 위해서는 내부 공변량 변화(Internal Covariate Shift)를 이해할 필요가 있습니다. 내부 공변량 변화란 학습 과정에서 층 별로 입력 데이터 분포가 달라지는 현상을 말합니다. 이전 층들의 학습에 의해 이전 층의 가중치 값이 바뀌게 되면, 현재 층에 전달되는 입력 데이터의 분포가 현재 층이 학습했던 시점의 분포와 차이가 발생합니다. 배치 정규화를 제안한 논문에서는 기울기 소실/폭주 등의 딥 러닝 모델의 불안전성이 층마다 입력의 분포가 달라지기 때문이라고 주장합니다. (배치 정규화를 제안한 논문에서는 이렇게 주장했지만, 뒤에 이어서는 이에 대한 반박들이 나오기는 했습니다. 하지만 그 이유가 어찌되었든 배치 정규화가 학습을 돕는다는 것은 명백합니다.)
공변량 변화는 훈련 데이터의 분포와 테스트 데이터의 분포가 다른 경우를 의미합니다.
내부 공변량 변화는 신경망 층 사이에서 발생하는 입력 데이터의 분포 변화를 의미합니다.
2) 배치 정규화(Batch Normalization)
배치 정규화(Batch Normalization)는 표현 그대로 한 번에 들어오는 배치 단위로 정규화하는 것을 말합니다. 배치 정규화는 각 층에서 활성화 함수를 통과하기 전에 수행됩니다. 배치 정규화를 요약하면 다음과 같습니다. 입력에 대해 평균을 0으로 만들고, 정규화를 합니다. 그리고 정규화 된 데이터에 대해서 스케일과 시프트를 수행합니다. 이 때 두 개의 매개변수 γ와 β를 사용하는데, γ는 스케일을 위해 사용하고, β는 시프트를 하는 것에 사용하며 다음 레이어에 일정한 범위의 값들만 전달되게 합니다.
3) 배치 정규화의 한계
배치 정규화는 뛰어난 방법이지만 몇 가지 한계가 존재합니다.
1. 미니 배치 크기에 의존적이다.
배치 정규화는 너무 작은 배치 크기에서는 잘 동작하지 않을 수 있습니다. 단적으로 배치 크기를 1로 하게되면 분산은 0이 됩니다. 작은 미니 배치에서는 배치 정규화의 효과가 극단적으로 작용되어 훈련에 악영향을 줄 수 있습니다. 배치 정규화를 적용할때는 작은 미니 배치보다는 크기가 어느정도 되는 미니 배치에서 하는 것이 좋습니다. 이처럼 배치 정규화는 배치 크기에 의존적인 면이 있습니다.
2. RNN에 적용하기 어렵다.
뒤에서 배우겠지만, RNN은 각 시점(time step)마다 다른 통계치를 가집니다. 이는 RNN에 배치 정규화를 적용하는 것을 어렵게 만듭니다. RNN에서 배치 정규화를 적용하기 위한 몇 가지 논문이 제시되어 있지만, 여기서는 이를 소개하는 대신 배치 크기에도 의존적이지 않으며, RNN에도 적용하는 것이 수월한 층 정규화(layer normalization)라는 방법을 소개하고자 합니다.
5. 층 정규화(Layer Normalization)
층 정규화를 이해하기에 앞서 배치 정규화를 시각화해보겠습니다. 다음은 mm이 3이고, 특성의 수가 4일 때의 배치 정규화를 보여줍니다. 미니 배치란 동일한 특성(feature) 개수들을 가진 다수의 샘플들을 의미함을 상기합시다.
참조: https://wikidocs.net/61375
번역 Google BERT: MNIST DataSet을 함수형태로 훈련시킬 수 있는 신경망을 Python 코드로 만들어 주세요.
ChatGPT: Please write a functional neural network that can train the MNIST Dataset in python code.
개발툴: colab.research.google.com
4차 산업의 기본 동력이 “데이타”가 되면서, 이것을 기반으로 IoT, BigData, AI, 블럭체인들이 그것을 사용하여 새로운 비지니스를 창출하는 엔진들로 인식되고 있습니다.
그로인한 IT(정보기술)의 위상도 급격하게 변하고 있습니다.
“IT for Business” 즉 비지니스의 도구로써의 IT가 “IT is Business” 변화, 즉 IT 자체가 비지니스가 된다는 인식으로 바뀌고 있습니다. 마찬가지로,
“Data for Business”, 비지니스를 위한 데이타에서, “Data is Business”, 데이타 자체가 비지니스의 가치를 가지며,
또한,
AI도 “AI for Business”, 현재는 AI도 비지니스를 도와주는 도구이지만, 바로 “AI is Business”, 즉, AI 자체가 비지니스가 될 것으로 예상됩니다.
AI는 우리가 일을 하는 방식을 근본적으로 되돌아보게 하고 있습니다. 혹시 이것 AI로 되는 것이 아니야? 혹시 이것 AI로하면 지금하는 방식보다는 훨씬 효율적으로 할 수 있는 것이 아니야? 이런 질문들이 들어옵니다.
이러한 시대적 흐름에 의해 영국 그래프코어와 저의 메가존클라우드는 고객사와 협력사들에 최고의 AI 솔루션을 제공하고자 노력하고 있습니다.
아이작 뉴튼: 역학 F=ma
M은 Mass에서 따온 m으로 "질량"을 가진 물체를 지칭합니다.
A는 Acceleration의 A로서 힘을 받은 물체가 가지게 되는 "가속도"
F란 Force의 F로서 물체에 가해지는 "힘"을 말합니다.
결정론적 프로그래밍과 확률론적 프로그래밍
일반적인 소프트웨어 프로그래밍은 어떠한 함수가 실행되면 그 출력값이 동일한것을 전제로 한다. 이러한 식으로 프로그램을 작성하는것을 결정론적(Deterministic) 프로그래밍이라고 한다. 이런 결정론적 프로그래밍이 소프트웨어서는 일반적이다.
그런데 실제 세상에서는 이렇게 입력과 출력이 항상 기대한대로 동작 하지는 않는다. 예를 들어 날씨 예보를 떠 올려봐도 내일 비가 올것인지를 명시적으로 판단할수는 없다. 단지 우리는 확률적으로 내일 비가 올 확률이 몇%인지를 예측할 뿐이다. 이런 식의 예측성 함수를 작성할때는 비가 올만한 단서들을 잘 추려내어 통계적인 기법으로 예측을 해내게 되는데, 이를 일반적인 프로그래밍적인 방법으로 구현 하기는 매우 어렵다.
이런 예측성 문제들을 함수로 구현해 내려면 예측값을 추론하기 위한 수학적 과정들이 필요하다. 이런 수학적 과정으로는 통계적 가설수립, 확률 분포 모형 함수생성, 데이터 시뮬레이션을 통한 통계적 추론 , 데이터 샘플링, 확률분포간의 비교과정등이 있다. 또한 이러한 확률적 프로그래밍 방법에는 컴퓨팅 자원도 많이 필요해 OS와 프레임워크수준에서 CPU병렬처리나 GPU등의 사용도 효과적으로 지원도 되어야 한다.
위 처럼 다양한 추론 과정들을 쉽고 효율적으로 작성하도록 도와주는 프로그래밍 방법을 Probabilistic Programming이라고 한다.
https://www.technologyreview.kr/artificial-general-intelligence-robots-ai-agi-deepmind-google-openai/
http://www.datanet.co.kr/news/articleView.html?idxno=177814
람다는 GPT와 거의 동일하게 거대한 트랜스포머이며 약 1370억개의 파라미터로 구성돼 있다. 인터넷 등을 통해 공개된 약 30억개의 문서, 11억개의 대화를 사전학습 데이터로 사용했다초거대 AI는 자본력이 있는 빅테크 기업이 아니라면 도전하기 쉽지 않다. 진입비용만 1000억원이라는 이야기가 있을 정도로 구축 비용이 비싸고, 운영단가가 매우 높다.대표적인 국내 빅테크 기업인 네이버의 경우 하이퍼클로바 개발을 위해 700PF 성능의 슈퍼컴퓨터를 구축했다. 140개의 컴퓨팅 노드를 갖고 있고 장착된 그래픽처리장치(GPU) 수만 1120여개에 이른다. 이 정도 비용과 인프라를 중소기업이나 연구기관이 구축하기 어려운 만큼, AI업계에서는 자본력에 따른 기술 격차가 발생할 수 있다고 염려된다. 현재 많은 AI 스타트업 기업은 실질적인 매출도 내지 못하고 있는 상황이고, 여기서 기술 격차까지 발생한다면 생존의 위기까지 발생할 것이다.출처 : 데이터넷(http://www.datanet.co.kr)
자:고통, 타:시련
자:고통, 타:시련
Arize AI
Arize AI, Inc.
Machine learning observability and model monitoring platform for performance management and RCA.