SlideShare a Scribd company logo
1 of 93
Download to read offline
Cloud, the NEXT 기술 소개:
CNA  MSA+MDA+MIA
Service | Data | Inference Mesh
AI Solution Architect Team@Megazone Cloud
박 문 기 | mkbahk@megazone.com
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
발표자 이력 소개
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
목 차
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 환경을 구현하는 것
Cloud Tech. Review
IT Infra. 환경 변화 대응: Cloud
자원풀화
가상화
표준화
자동화
※ Tenant: 클라우드 내 한 사용자 또는 조직이
사용할 수 있는 가상 컴퓨터, 가상스토로지,
가상네트워크의 집합
Cloud형 서비스의 종류
가상화
(SDDC)
Cloud 서비스의 구분
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
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
Cloud 서비스의 가치(3/3)
80% 15% 5%
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)
주목할 몇가지 IT 트랜드
몇 가지 중요 트랜드(1/8): 초-전환시대: 급변하는 비지니스와 IT기술 변화
아마추어는 일을 위한 조건과 환경을 구성하느라 일을 시작 못하고,
프로는 일단 일을 시작한 후 필요한 조건과 환경을 일에 맞춘다.
5천 만명
몇 가지 중요 트랜드(2/8): 초-전환시대: 더 급변하는 비지니스와 IT기술
변화
몇 가지 중요 트랜드(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증가, 생물학적 다양성증가종심의존|종속성감소독립적인 부분변화 가속생존성증가
왜 우리는 네트워크를 만들고 있는가 또는 스스로 결과적으로 네트워크화 되어가고 있나요?
몇 가지 중요 트랜드(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 통합 수행 환경
몇 가지 중요 트랜드(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
몇 가지 중요 트랜드(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...
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
몇 가지 중요 트랜드(7/8): Composable Enterprise
몇 가지 중요 트랜드(8/8): 양자컴퓨팅과 QML(Quantum Machine Learning)
소스: https://youtu.be/-o9AhIz1uvo?t=880
소스: https://youtu.be/-o9AhIz1uvo?t=1035
Qbit가 추가될 때 마다 NQbitNQbit 병렬처리 능력 향상
CNA환경에서 App. 개발전략 및 방법론
MSA(Micro Service Architecture)
&
Service Mesh
CNA(Cloud Native Architecture)와 MSA(Microservices Architecture)의 필요성
CNA(Cloud Native Arch. or Strategy)이란?
Host/Slave(1-Tier)Client/Server(2-Tier)Web Service(3-Tier: WebWASDB, SOA)CloudNative(NxN-Tier, NxAPI-GWNxMicroservicessNxDB, SOA+MSA)
MSA(Cloud Native한 S/W 개발 아키텍쳐)  Platform | Eco-System as a Product
Service-Oriented Architecture
compose of
Loosely coupled elements
that have
bounded contexts Microservices
App. Block
Monolith
App. Box
[초기장점->확장되면 단점으로]
1. 개발 속도가 빠름어려움
2. 테스트하기 쉬움어려움
3. 배포하기 쉬움어려움
4. 기능개선이 쉬움어려움
5. 통합된 신기술 도입어려움
[장점]
1. 모듈 독립성 유지로 배포용이
2. 신기술 도입이 용이
3. Ployglot: 적소에 최적기술사용
다양한 [아키텍쳐|언어|DataStore]
4.기능개선이 용이
5. 장애격리 용이
6. 확장성 용이
[단점]
1. 도입의 어려움
2. 복잡한 운영
3. 트랜잭션 유지의 어려
움
4. 디버깅의 어려움
Session-Oriented
Tightly Coupled
Monolith vs. MSA 서비스 확장성(Scale in/out, up/down) 비교
MSA와 Polyglot(다언어, 다형성)
MSA의 이점
소스: AWS
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
Microservices
App. Block
Monolith
App. Box
Container, MSA을 담을 그릇(초-전환)
MSA
Container(Docker Container가 Embedded Tomcat Container 보다는...)
Microservices
App. 구조
Sidecar, Proxy, Agent
Add-on, Interceptor,...
MSA구현을 위한 기반 플랫폼: Spring Cloud vs. Kubernetes
MSA성공하려면 Java@Spring Framework, PaaS-TA, Oracle, 통일, 표준화,... 버려야!!!
MSA구현 플랫폼 예시: Spring Cloud
Container Orchestrator(Kubernetes)
 S/W적으로 변경가능한 SDDC(SDC, SDS, SDN)형 구성을 위한 모든 인프라 제공
 가장 중요한 속성: 주어진 형상을 끝까지 유지하려는 속성
 MSA의 De facto Standard 환경
 App. 배포 및 서비스에 최적화된 O/S...
전통적인 서비스 수행환경 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
MSA설계방법론: DDD(Domain Driven Design)
데이타,트랜젝션중심  업무중심
기술중심  문제해결중심
직능중심조직  직무중심조직
MSA를 위한 개발문화 중 필수조건  배포 자동화 및 지속적 배포
Anytime, not scheduled
소스: AWS
MSA신속성을 위한 CI/CD형 응용프로그램 개발 및 지속적 배포
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 제품 팀은 소프트웨어를 만들고 운영하는데 필
요한 모든 것을 소유
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 상태가 없고 요청이 자기완비적이기 때문에 서비스도 수평적
으로 쉽게 확장
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
MSA 복잡성(I)
DataLake
DataLake
DataLake
Service Mesh
MSA 복잡성해결사Service Mesh의 출현
MSA
API Gateway
Meshed Service Network
(L-7 Application Layer Networking)
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
CNA환경에서 Data 분야 변화:
MDA(Micro Data Architecture)
Data Fabric & Data Mesh)
SQream: GPU-Accelerated AnalyticDB
분석DB
GPU로 가속된 rDBMS형, SQL을 지원하는 초-거대용량 “정형” 빅데이타 처리용 병렬분산•분석DB
2005~
In-Memory
Omnisci
(MapD)
Kinetica
Aerospike
SAP HANA
VoltaDB
IBM-DB2 BLUM
emSQL
Altibase
2010~
MassiveData
(DataLake, LakeHouse)
1990~
MPP(EDW)
Teradata MongoDB
Vertica Redshift
Oracle-Exadata
IBM-Netezza
Greenplum
Sybase IQ
Oracle
DB2
SQLServer
Informix
Sybase ASE
SQreamDB
Hadoop-Hive
Snowflake
BigQuery
1970~
ClassicalRelational
2010~
NO-SQL
1) WIDE COLUMN DATABASE(Store)
Hbase, GoogleBigTable, Vertica,
Druid, Accumulo, Hypertable
2) GRAPH DATABASE
Neo4j, Blazegraph, OrientDB
3) DOCUMENT DATABASE(Store)
MongoDB, Azure CosmosDB, CouchDB,
MarkLogic, OrientDB
4) KEY-VALUE DATABASE(Store)
Cassandra, LevelDBRocksDB, Redis,
Oracle NoSQLDB,Voldemorte,
Oracle BerkeleyDB, Memcached, Hazelcast
RelationalDB NoSQL & Hadoop Public Cloud Only
GPU Database
GPU Accelerated+rDBMS-SQL+MPP+NO-SQL(WIDE COLUMN, Key-Value DB)  SQream AnalyticDB
Data Warehouse(MPP, ETL-Filtering)
RDBMS APP.
BI
RDBMS APP.
BI
ETL/CDC
MPP
BigdataDataLake(Hadoop, No/Selective Filtering)
ETL/CDC
ELT
Messaging
Bus
Data Warehouse + DataLake  Lakehouse
Lakehouse
[Lakehouse의 기능들]
⦿ 거래지원
⦿ 스키마 시행 및 거버넌스
⦿ BI, ML/DL, 데이터 과학, 스트리밍 분석 지원
⦿ 스토리지는 컴퓨팅에서 분리
⦿ 개방 상태
⦿ 비정형 데이터부터 정형 데이터까지 다양한
데이터 유형 지원
⦿ 다양한 워크로드 지원
⦿ 종단 간 스트리밍
Data Governance
Data Catalog
DataLake
MPP
Data Lake 및 Lake House 접근방식
소스: https://youtu.be/vXSEV0q_T8g?t=243
MACRO Data Architecture의 문제점
소스: https://youtu.be/vXSEV0q_T8g?t=243
Micro Data Arch. + Dash Mesh의 출현
소스: https://youtu.be/vXSEV0q_T8g?t=243
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
Data Fabric = Federated DBMS, No Storage
Super Queryer w/ DataCatalog
Data Virtualization
EDWLDW(Logical DW)
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) 실-시간성 부족
MSA를 위한 MDA DB 구성전략
MSA를 위한 MDA DB 분리 및 활용
MSA를 위한 MDA DB 분리 및 활용
MSA를 위한 MDA DB 트랜잭션 패턴-공유 데이타베이스
MSA를 위한 MDA DB 트랜잭션 패턴(명령어/쿼리 역할분리)
CQRS,Command Query Responsibility Segregation
Message Bus
MDA - Data Mesh에서 데이타 복제는
ETL
MSA Service Mesh상에 MDA & Data Mesh구현
DataLake
DataLake
DataLake
MDA=Data Fabric + Data Mesh
Super Queryer
Data Gov.
MSA-Service Mesh + MDA-Data Mesh
Data Fabric
DataOps
Data Pipeline
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
CNA환경에서 AI Service 통합
MIA(Micro Inference Architecture)
&
Inference Mesh
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
AI란 무엇인가?
인간 구성요소의 지능기계화:
육체  로봇
이성  정형데이타, CPU를 위한 정적으로 코드화된 프로그램(수학·논리적인 수리과학 능력 필요)
감정  비정형데이타, GPU에 의한 동적으로 생성되는 프로그램(ML/DL 모델 , 통계 · 자연과학 · 인문학적 능력 필요)
결국, 인간을 닮은
“지능기계”를 만드
는 것
지능(Intelligence): 경험에서 받아들여진 불완전한 지식에 근거한 합리적판단(추론) 능력”이다.
학습(Learning)은 경험된 데이터의 응축(통계모델)을 형성합니다. 불확실성이 없이는 지능도 없다.
딥너링의 대부:
제프리 힌튼 교수
 학사: 생리학, 물리학
 석사: 철학, 심리학
 박사: 인공신경망
대량의 데이타, 대량의 컴퓨팅파워, 대량의 전기를 투입하여,
인간보다 빠르고, 안정적, 누적적으로 지식을 학습하는 과정
AIMLDL의 출현(2번의 겨울을 이겨낸 인고의 결과...)
인공신경망(Perceptron)XOR문제xMLP(다층신경망)학습시간↑문제오차역전파로 해결기울기소실문제발생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활용, OverfittingDropout + 자비어 글로렛 ReLU활성화함수
PEI-PEI LI
14,197,122장 이미지
20,000개 카테고리
인간 5.51%에러:
SuperVision팀: 25%에러율15~16%, Google: 6.65%, MS: 152개 층 3.56% 달성
Google 신이 죽고, ChatGPT 신이 오셨다.
100만명 도달: 5일
100만명 도달: 10개월
100만명 도달: 3년
Microsoft 100억 $, 12조원 투자 Google 비상경영 선언
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
결정론적 프로그래밍 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)
AI로 인한 Data에 대한 중요한 관점 변화
소스: https://youtu.be/3Q_XbPmICPg?t=484
Deep Learning 수행구조- GRAPH 구조/알고리즘
Vertices(정점)
Node
Gateway
Neuron
Edge(간선)
Link
Connection
Synapse
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
반복
AI, Deep Learning Training의 결과  AI Model
초-전환시대 프로그램 짤 시간도 부족해....그냥 AI 동적으로 만들어 주면 않되...
https://playground.tensorflow.org/
Neural Network의 기본구조와 종류들
AI Trained Model Service  Inference
MLOps
AGI(Artificial General Intelligence) vs. ASI(Artificial Specialized Intelligence)
일반(범용) 인공지능(artificial general intelligence, AGI)은 인간이 할
수 있는 어떠한 지적인 업무도 성공적으로 해낼 수 있는 (가상적
인) 기계의 지능을 말한다. 이는 인공지능 연구의 주요 목표이며,
SF 작가들이나 미래학자들의 중요한 소재이다. 인공 일반 지능
은 강한 AI, 완전 AI, 또는 '일반 지능적 행동'을 실행하는 기계의 능
력이라고도 한다.
Massive AI Inference Service
ex) OpenAI GPT, DeepMind AlphaGoAlphaZero, 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로 동적생성프로그램 먼저 고려
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년 세계 경제를 지배할 것.
"맥킨지 글로벌 인스티튜트"
초-거대 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
QML(Quantum Machine Learning) for AI
소스: https://youtu.be/-o9AhIz1uvo?t=880
소스: https://youtu.be/-o9AhIz1uvo?t=1035
핵심: Qbit가 추가될 때 마다 NQbitNQbit 병렬처리 능력 향상
CNA환경에서 Storage Service 통합
분산 ∙ 병렬 스토리지
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
스토리지접근
Cloud, Container, AI, HPC용 분산병렬스토리지의 중요성(2/2)
Hadoop HDFS는 어디에 있는가?
결론...
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
???
???
석기시대가 끝난 이유는...
• "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조원
Thank you

More Related Content

What's hot

민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWSAmazon Web Services Korea
 
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAmazon Web Services Japan
 
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
 
OpsNow를 활용한 AWS Cloud 비용 최적화 전략
OpsNow를 활용한 AWS Cloud 비용 최적화 전략OpsNow를 활용한 AWS Cloud 비용 최적화 전략
OpsNow를 활용한 AWS Cloud 비용 최적화 전략BESPIN GLOBAL
 
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...Amazon Web Services Korea
 
[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様Shuji Kikuchi
 
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤Amazon Web Services Japan
 
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014Amazon Web Services
 
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWSBest Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWSAmazon Web Services Japan
 
세션 3: IT 담당자를 위한 Cloud 로의 전환
세션 3: IT 담당자를 위한 Cloud 로의 전환세션 3: IT 담당자를 위한 Cloud 로의 전환
세션 3: IT 담당자를 위한 Cloud 로의 전환Amazon Web Services Korea
 
オンプレミスRDBMSをAWSへ移行する手法
オンプレミスRDBMSをAWSへ移行する手法オンプレミスRDBMSをAWSへ移行する手法
オンプレミスRDBMSをAWSへ移行する手法Amazon Web Services Japan
 
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트) IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트) Amazon Web Services Korea
 
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続Amazon Web Services Japan
 
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)Amazon Web Services Japan
 
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...Amazon Web Services Korea
 
20190522 AWS Black Belt Online Seminar AWS Step Functions
20190522 AWS Black Belt Online Seminar AWS Step Functions20190522 AWS Black Belt Online Seminar AWS Step Functions
20190522 AWS Black Belt Online Seminar AWS Step FunctionsAmazon Web Services Japan
 
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...Amazon Web Services Korea
 
AWS Black Belt Techシリーズ AWS Data Pipeline
AWS Black Belt Techシリーズ  AWS Data PipelineAWS Black Belt Techシリーズ  AWS Data Pipeline
AWS Black Belt Techシリーズ AWS Data PipelineAmazon Web Services Japan
 
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順Amazon Web Services Japan
 
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법Amazon Web Services Korea
 

What's hot (20)

민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
민첩하고 비용효율적인 Data Lake 구축 - 문종민 솔루션즈 아키텍트, AWS
 
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツールAWS における Microservices Architecture と DevOps を推進する組織と人とツール
AWS における Microservices Architecture と DevOps を推進する組織と人とツール
 
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...
 
OpsNow를 활용한 AWS Cloud 비용 최적화 전략
OpsNow를 활용한 AWS Cloud 비용 최적화 전략OpsNow를 활용한 AWS Cloud 비용 최적화 전략
OpsNow를 활용한 AWS Cloud 비용 최적화 전략
 
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...
클라우드 마이그레이션 성공적인 여정, 그 중요한 시작 "Readiness Assessment (전환 준비 평가)" - 김준범, AWS Mi...
 
[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様[AKIBA.AWS] VGWのルーティング仕様
[AKIBA.AWS] VGWのルーティング仕様
 
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤
202106 AWS Black Belt Online Seminar 小売現場のデータを素早くビジネス に活用するAWSデータ基盤
 
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
(SPOT301) AWS Innovation at Scale | AWS re:Invent 2014
 
Best Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWSBest Practices for Running PostgreSQL on AWS
Best Practices for Running PostgreSQL on AWS
 
세션 3: IT 담당자를 위한 Cloud 로의 전환
세션 3: IT 담당자를 위한 Cloud 로의 전환세션 3: IT 담당자를 위한 Cloud 로의 전환
세션 3: IT 담당자를 위한 Cloud 로의 전환
 
オンプレミスRDBMSをAWSへ移行する手法
オンプレミスRDBMSをAWSへ移行する手法オンプレミスRDBMSをAWSへ移行する手法
オンプレミスRDBMSをAWSへ移行する手法
 
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트) IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
IDC 서버 몽땅 AWS로 이전하기 위한 5가지 방법 - 윤석찬 (AWS 테크에반젤리스트)
 
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
20200219 AWS Black Belt Online Seminar オンプレミスとAWS間の冗長化接続
 
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)
AWS初心者向けWebinar RDBのAWSへの移行方法(Oracleを例に)
 
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...
AWS 비용 효율화를 고려한 Reserved Instance + Savings Plan 옵션 - 박윤 어카운트 매니저 :: AWS Game...
 
20190522 AWS Black Belt Online Seminar AWS Step Functions
20190522 AWS Black Belt Online Seminar AWS Step Functions20190522 AWS Black Belt Online Seminar AWS Step Functions
20190522 AWS Black Belt Online Seminar AWS Step Functions
 
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...
대용량 데이터베이스의 클라우드 네이티브 DB로 전환 시 확인해야 하는 체크 포인트-김지훈, AWS Database Specialist SA...
 
AWS Black Belt Techシリーズ AWS Data Pipeline
AWS Black Belt Techシリーズ  AWS Data PipelineAWS Black Belt Techシリーズ  AWS Data Pipeline
AWS Black Belt Techシリーズ AWS Data Pipeline
 
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
AWS EC2 Eメール制限解除 - 逆引き(rDNS)設定 申請手順
 
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
[AWS Builders] AWS 스토리지 서비스 소개 및 사용 방법
 

Similar to __Cloud_CNA_MSA_Service+Data+InferenceMesh 소개-박문기@메가존클라우드-20230320.pptx

MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...문기 박
 
[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략Ji-Woong Choi
 
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브[열린기술공방] Container기반의 DevOps - 클라우드 네이티브
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브Open Source Consulting
 
Open standard open cloud engine for digital business process
Open standard open cloud engine for digital business process Open standard open cloud engine for digital business process
Open standard open cloud engine for digital business process uEngine Solutions
 
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)SAMUEL SJ Cheon
 
Why opensource cloud
Why opensource cloudWhy opensource cloud
Why opensource cloudsprdd
 
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님OpenStack Korea Community
 
Cloud review 1011_서울대
Cloud review 1011_서울대Cloud review 1011_서울대
Cloud review 1011_서울대Jaekyu Choi
 
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야Jay Park
 
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황mosaicnet
 
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdfSAMUEL SJ Cheon
 
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)KINX
 
꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가VMware Tanzu Korea
 
성공적인 하이브리드 클라우드를 위한 레드햇의 전략
성공적인 하이브리드 클라우드를 위한 레드햇의 전략성공적인 하이브리드 클라우드를 위한 레드햇의 전략
성공적인 하이브리드 클라우드를 위한 레드햇의 전략rockplace
 
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...OpenStack Korea Community
 
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처hoondong kim
 
모바일 개발 트랜드
모바일 개발 트랜드모바일 개발 트랜드
모바일 개발 트랜드Terry Cho
 
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)Metatron
 
클라우드컴퓨팅 V4
클라우드컴퓨팅 V4클라우드컴퓨팅 V4
클라우드컴퓨팅 V4Alex Yang
 
OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316기한 김
 

Similar to __Cloud_CNA_MSA_Service+Data+InferenceMesh 소개-박문기@메가존클라우드-20230320.pptx (20)

MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
MSA(Service Mesh), MDA(Data Mesh), MIA(Inference Mesh) 기술동향 소개-박문기@메ᄀ...
 
[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략[오픈소스컨설팅] 2019년 클라우드 생존전략
[오픈소스컨설팅] 2019년 클라우드 생존전략
 
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브[열린기술공방] Container기반의 DevOps - 클라우드 네이티브
[열린기술공방] Container기반의 DevOps - 클라우드 네이티브
 
Open standard open cloud engine for digital business process
Open standard open cloud engine for digital business process Open standard open cloud engine for digital business process
Open standard open cloud engine for digital business process
 
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)
(Red hat]private cloud-osp-introduction(samuel)2017-0530(printed)
 
Why opensource cloud
Why opensource cloudWhy opensource cloud
Why opensource cloud
 
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님
[OpenInfra Days Korea 2018] (오픈소스컨설팅) 키노트 - 최지웅 이사님
 
Cloud review 1011_서울대
Cloud review 1011_서울대Cloud review 1011_서울대
Cloud review 1011_서울대
 
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야
마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야
 
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황
클라우드 컴퓨팅 패러다임이 뒤바꾼 일 IT산업의 현황
 
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf
(Enterprise,RedHat) - SDC(IaaS) with SDS, Cloud References 2020-07 Samuel.pdf
 
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)
네이버 클라우드 플랫폼의 서비스 전략(공공, Cloud Connect)
 
꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가꿀밋업1탄_왜_마이크로서비스인가
꿀밋업1탄_왜_마이크로서비스인가
 
성공적인 하이브리드 클라우드를 위한 레드햇의 전략
성공적인 하이브리드 클라우드를 위한 레드햇의 전략성공적인 하이브리드 클라우드를 위한 레드햇의 전략
성공적인 하이브리드 클라우드를 위한 레드햇의 전략
 
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...
[OpenInfra Days Korea 2018] (Track 2) Microservice Architecture, DevOps 그리고 5...
 
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
[AI & DevOps] BigData Scale Production AI 서비스를 위한 최상의 플랫폼 아키텍처
 
모바일 개발 트랜드
모바일 개발 트랜드모바일 개발 트랜드
모바일 개발 트랜드
 
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)
[DDC 2018] Metatron 오픈소스화 및 생태계 구축 (SKT 이정룡, 김지호)
 
클라우드컴퓨팅 V4
클라우드컴퓨팅 V4클라우드컴퓨팅 V4
클라우드컴퓨팅 V4
 
OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316OPEN_POWER8_SESSION_20150316
OPEN_POWER8_SESSION_20150316
 

__Cloud_CNA_MSA_Service+Data+InferenceMesh 소개-박문기@메가존클라우드-20230320.pptx

  • 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 환경을 구현하는 것
  • 7. IT Infra. 환경 변화 대응: Cloud 자원풀화 가상화 표준화 자동화 ※ Tenant: 클라우드 내 한 사용자 또는 조직이 사용할 수 있는 가상 컴퓨터, 가상스토로지, 가상네트워크의 집합
  • 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
  • 22. 몇 가지 중요 트랜드(7/8): Composable Enterprise
  • 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
  • 25. CNA(Cloud Native Architecture)와 MSA(Microservices Architecture)의 필요성
  • 26. CNA(Cloud Native Arch. or Strategy)이란? Host/Slave(1-Tier)Client/Server(2-Tier)Web Service(3-Tier: WebWASDB, SOA)CloudNative(NxN-Tier, NxAPI-GWNxMicroservicessNxDB, SOA+MSA)
  • 27. MSA(Cloud Native한 S/W 개발 아키텍쳐)  Platform | Eco-System as a Product Service-Oriented Architecture compose of Loosely coupled elements that have bounded contexts Microservices App. Block Monolith App. Box [초기장점->확장되면 단점으로] 1. 개발 속도가 빠름어려움 2. 테스트하기 쉬움어려움 3. 배포하기 쉬움어려움 4. 기능개선이 쉬움어려움 5. 통합된 신기술 도입어려움 [장점] 1. 모듈 독립성 유지로 배포용이 2. 신기술 도입이 용이 3. Ployglot: 적소에 최적기술사용 다양한 [아키텍쳐|언어|DataStore] 4.기능개선이 용이 5. 장애격리 용이 6. 확장성 용이 [단점] 1. 도입의 어려움 2. 복잡한 운영 3. 트랜잭션 유지의 어려 움 4. 디버깅의 어려움 Session-Oriented Tightly Coupled
  • 28. Monolith vs. MSA 서비스 확장성(Scale in/out, up/down) 비교
  • 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
  • 32. Microservices App. Block Monolith App. Box Container, MSA을 담을 그릇(초-전환) MSA
  • 33. Container(Docker Container가 Embedded Tomcat Container 보다는...) Microservices App. 구조 Sidecar, Proxy, Agent Add-on, Interceptor,...
  • 34. MSA구현을 위한 기반 플랫폼: Spring Cloud vs. Kubernetes MSA성공하려면 Java@Spring Framework, PaaS-TA, Oracle, 통일, 표준화,... 버려야!!!
  • 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
  • 38. MSA설계방법론: DDD(Domain Driven Design) 데이타,트랜젝션중심  업무중심 기술중심  문제해결중심 직능중심조직  직무중심조직
  • 39. MSA를 위한 개발문화 중 필수조건  배포 자동화 및 지속적 배포 Anytime, not scheduled 소스: AWS
  • 40. MSA신속성을 위한 CI/CD형 응용프로그램 개발 및 지속적 배포
  • 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)
  • 48.
  • 49. SQream: GPU-Accelerated AnalyticDB 분석DB GPU로 가속된 rDBMS형, SQL을 지원하는 초-거대용량 “정형” 빅데이타 처리용 병렬분산•분석DB 2005~ In-Memory Omnisci (MapD) Kinetica Aerospike SAP HANA VoltaDB IBM-DB2 BLUM emSQL Altibase 2010~ MassiveData (DataLake, LakeHouse) 1990~ MPP(EDW) Teradata MongoDB Vertica Redshift Oracle-Exadata IBM-Netezza Greenplum Sybase IQ Oracle DB2 SQLServer Informix Sybase ASE SQreamDB Hadoop-Hive Snowflake BigQuery 1970~ ClassicalRelational 2010~ NO-SQL 1) WIDE COLUMN DATABASE(Store) Hbase, GoogleBigTable, Vertica, Druid, Accumulo, Hypertable 2) GRAPH DATABASE Neo4j, Blazegraph, OrientDB 3) DOCUMENT DATABASE(Store) MongoDB, Azure CosmosDB, CouchDB, MarkLogic, OrientDB 4) KEY-VALUE DATABASE(Store) Cassandra, LevelDBRocksDB, Redis, Oracle NoSQLDB,Voldemorte, Oracle BerkeleyDB, Memcached, Hazelcast RelationalDB NoSQL & Hadoop Public Cloud Only GPU Database GPU Accelerated+rDBMS-SQL+MPP+NO-SQL(WIDE COLUMN, Key-Value DB)  SQream AnalyticDB
  • 50. Data Warehouse(MPP, ETL-Filtering) RDBMS APP. BI RDBMS APP. BI ETL/CDC MPP
  • 52. Data Warehouse + DataLake  Lakehouse Lakehouse [Lakehouse의 기능들] ⦿ 거래지원 ⦿ 스키마 시행 및 거버넌스 ⦿ BI, ML/DL, 데이터 과학, 스트리밍 분석 지원 ⦿ 스토리지는 컴퓨팅에서 분리 ⦿ 개방 상태 ⦿ 비정형 데이터부터 정형 데이터까지 다양한 데이터 유형 지원 ⦿ 다양한 워크로드 지원 ⦿ 종단 간 스트리밍
  • 55. Data Lake 및 Lake House 접근방식 소스: https://youtu.be/vXSEV0q_T8g?t=243
  • 56. MACRO Data Architecture의 문제점 소스: https://youtu.be/vXSEV0q_T8g?t=243
  • 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 EDWLDW(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) 실-시간성 부족
  • 61. MSA를 위한 MDA DB 구성전략
  • 62. MSA를 위한 MDA DB 분리 및 활용
  • 63. MSA를 위한 MDA DB 분리 및 활용
  • 64. MSA를 위한 MDA DB 트랜잭션 패턴-공유 데이타베이스
  • 65. MSA를 위한 MDA DB 트랜잭션 패턴(명령어/쿼리 역할분리) CQRS,Command Query Responsibility Segregation Message Bus
  • 66. MDA - Data Mesh에서 데이타 복제는 ETL
  • 67. MSA Service Mesh상에 MDA & Data Mesh구현
  • 68. DataLake DataLake DataLake MDA=Data Fabric + Data Mesh Super Queryer Data Gov. MSA-Service Mesh + MDA-Data Mesh Data Fabric DataOps Data Pipeline
  • 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. AIMLDL의 출현(2번의 겨울을 이겨낸 인고의 결과...) 인공신경망(Perceptron)XOR문제xMLP(다층신경망)학습시간↑문제오차역전파로 해결기울기소실문제발생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활용, OverfittingDropout + 자비어 글로렛 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/
  • 82. AI Trained Model Service  Inference MLOps
  • 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 AlphaGoAlphaZero, 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 병렬처리 능력 향상
  • 87. CNA환경에서 Storage Service 통합 분산 ∙ 병렬 스토리지
  • 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 스토리지접근
  • 89. Cloud, Container, AI, HPC용 분산병렬스토리지의 중요성(2/2) Hadoop HDFS는 어디에 있는가?
  • 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조원

Editor's Notes

  1. 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
  2. 자:고통, 타:시련
  3. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  4. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  5. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  6. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  7. 자:고통, 타:시련
  8. 번역 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
  9. 번역 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
  10. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  11. 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
  12. 자:고통, 타:시련
  13. 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. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
  14. 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. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
  15. 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. 조직이 성장할 수록 배포 대기시간이 비약적으로 증가함
  16. 아파치 톰캣(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 모듈을 사용한다.
  17. Hystrix: Circuit Breaker Ribbon: Client Side Load Balancer Eureka: Service Registry Feign: Declarative HTTP Client Zuul: API Gateway
  18. 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은 크게 변경 가능합니다.
  19. representation state transfer
  20. 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에는 영구 연결 개념과 메시지 브로드캐스트에 대한 기본 제공 지원이 있습니다
  21. 자:고통, 타:시련
  22. 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
  23. Data Mesh는 최근에 소개된 새로운 데이터 아키텍처 패턴입니다. 기존의 중앙집중식 데이터 아키텍처에서 벗어나서 조직 전체에서 데이터를 분산시키고, 자율적으로 운영 및 관리할 수 있도록 하는 것이 목적입니다. 이를 위해 Data Mesh는 다음과 같은 기본 원칙을 제안합니다. 도메인 중심 데이터 소유권: 데이터는 도메인에 속하는 비즈니스 팀에서 소유하고 운영합니다. 이는 데이터를 생성하고 가공하는 일련의 작업에 대한 책임을 도메인 팀에게 부여하여, 데이터 품질과 더불어 데이터 이해도와 활용도를 높이기 위함입니다. 자율적 데이터 팀: 데이터 팀은 자체적으로 의사결정을 내릴 수 있는 자율적인 조직이 되어야 합니다. 데이터 스키마, 저장소, 프로세스, 파이프라인 등 데이터에 대한 모든 측면을 자율적으로 관리하며, 데이터 품질과 데이터 사용자 요구사항을 충족하는 책임을 지게 됩니다. 분산 데이터 아키텍처: 중앙 집중식 데이터 아키텍처가 아니라, 분산 데이터 아키텍처를 채택합니다. 이를 위해서 데이터는 작은 단위로 나누어 각각의 도메인 팀에서 관리하며, 이러한 분산 데이터가 전체적으로 연결되어서 데이터의 통합성과 일관성을 유지할 수 있도록 합니다. 데이터 제품화: 데이터를 단순히 저장하는 것이 아니라, 데이터 제품(Product)으로 생각하여 생산, 소비, 재사용 가능한 형태로 관리합니다. 이를 통해 데이터를 서비스로써 제공하고, 데이터를 이용하는 비즈니스 측면에서는 데이터를 이해하고 활용하기 쉽도록 합니다. 자체 서비스: 데이터 팀은 자체적으로 서비스(Service)를 제공하는 조직이 되어야 합니다. 이는 데이터를 소비하는 사용자들을 위한 데이터 검색, 데이터 카탈로그, 데이터 보안 및 데이터 모니터링 등을 제공하여 데이터 사용의 용이성과 안정성을 확보합니다. 이러한 기본 원칙은 Data Mesh를 구성하는 핵심 요소이며, 각각의 원칙은 분산 데이터 아키텍처와 데이터 제품화를 위한 설계와 개발에 대한 지
  24. 자:고통, 타:시련
  25. 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 솔루션을 제공하고자 노력하고 있습니다.
  26. 존 매카시(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.
  27. 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
  28. 번역 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
  29. 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 솔루션을 제공하고자 노력하고 있습니다.
  30. 아이작 뉴튼: 역학 F=ma M은 Mass에서 따온 m으로 "질량"을 가진 물체를 지칭합니다. A는 Acceleration의 A로서 힘을 받은 물체가 가지게 되는 "가속도" F란 Force의 F로서 물체에 가해지는 "힘"을 말합니다. 결정론적 프로그래밍과 확률론적 프로그래밍 일반적인 소프트웨어 프로그래밍은 어떠한 함수가 실행되면 그 출력값이 동일한것을 전제로 한다. 이러한 식으로 프로그램을 작성하는것을 결정론적(Deterministic) 프로그래밍이라고 한다.  이런 결정론적 프로그래밍이 소프트웨어서는 일반적이다. 그런데 실제 세상에서는 이렇게 입력과 출력이 항상 기대한대로 동작 하지는 않는다.  예를 들어 날씨 예보를 떠 올려봐도 내일 비가 올것인지를 명시적으로 판단할수는 없다. 단지 우리는 확률적으로 내일 비가 올 확률이 몇%인지를 예측할 뿐이다. 이런 식의 예측성 함수를 작성할때는 비가 올만한 단서들을 잘 추려내어 통계적인 기법으로 예측을 해내게 되는데, 이를 일반적인 프로그래밍적인 방법으로 구현 하기는 매우 어렵다.   이런 예측성 문제들을 함수로 구현해 내려면 예측값을 추론하기 위한 수학적 과정들이 필요하다.  이런 수학적 과정으로는 통계적 가설수립, 확률 분포 모형 함수생성, 데이터 시뮬레이션을 통한 통계적 추론 , 데이터 샘플링, 확률분포간의 비교과정등이 있다. 또한 이러한 확률적 프로그래밍 방법에는 컴퓨팅 자원도 많이 필요해 OS와 프레임워크수준에서 CPU병렬처리나 GPU등의 사용도 효과적으로 지원도 되어야 한다. 위 처럼 다양한 추론 과정들을 쉽고 효율적으로 작성하도록 도와주는 프로그래밍 방법을 Probabilistic Programming이라고 한다.
  31. 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)
  32. 자:고통, 타:시련
  33. 자:고통, 타:시련
  34. Arize AI Arize AI, Inc. Machine learning observability and model monitoring platform for performance management and RCA.