from : http://w3labs.kr/?p=5389
시중에 나와있는 웹소켓 솔루션은 정말 많은 종류가 있습니다.
하지만, 웹소켓을 지원하지 않는 IE6+ , Android2.1+ 버전까지 지원하는 웹소켓 솔루션은
Kaazing 과 Socket.IO 뿐이 없는 실정입니다.
Kaazing 과 Socket.IO 에서는 시뮬레이션모드 라는 것으로 웹소켓 미지원 브라우저에서도 동작 하는데요.
이 시뮬레이션 모드에서 기술의 차이가 발생 합니다.
Socket.IO 는 Long-Polling(Comet) 방식으로 시뮬레이션을 하고 있습니다.
결국 웹소켓이 나오기 이전 기술, 그러니까 결국 Legacy 기술을 이용하는 것으로 웹소켓과는 거리가 멀지요.
웹소켓의 장점인 Full-Duplex 방식이 아닌 Half-Duplex 방식으로 응답(Latency)가 느리고 가비지 트래픽이 발생하게 되지요.
Kaazing 의 경우는 유료 솔루션 답게 시뮬레이션을 자체 기술로 해결 했는데요.
Ajax 통신 2개를 열어 놓고, 하나는 Send를, 하나는 Receive를 담당하게 합니다.
웹소켓과 동일한 Full-Duplex 방식으로 빠른 응답속도와 적은 트래픽을 유발하게 되지요.
또한, 이러한 시뮬레이션 모드가 어떠한 구성환경에서도 완벽하게 동작 하는데요.
* Single Sign-On (SSO) 연동
* VPN 2중화 환경
* DDMZ 환경
* Proxy Server 에서 패킷을 감청 할 수 있는 환경(보안 유지)
* Active-Active Load Balancing
* Binary Data의 WebSocket 지원원
* 병렬적 서버 확장
* 국내 기술지원
이러한 엔터프라이즈 환경의 Needs 를 모두 충족시켜 주고 있습니다.
Kaazing을 도입한 회사들을 보면 솔루션의 완성도를 보실 수 있습니다.
금융권
* JP모건
* HSBC 은행
* 골드만삭스 외 4개사
Software & Service
* 오라클
* 인텔
* 시스코
* 에릭슨
* 구글
* 퀄컴
* 맥아피 외 8개사
Media & Entertainment
* Skybet
* AOL
* The Daily
* CNN Money 외 5개사
기타
* Southwest Airlines 외 4개사
더 자세한 내용은 아래 슬라이드를 참조 하시기 바라며,
문의 사항은 연락 주시기 바랍니다. (contact@w3labs.kr)
* URL : http://w3labs.kr/?p=5389
감사합니다.
대규모 클러스터링 환경에서 사용자에게 투명하게 하나의 시스템으로 보일 수 있도록 세션 클러스터링 기능을 제공하는 WAS 고가용 솔루션입니다. 지금까지 WAS 에 저장되던 세션 영역을 제거하고 이를 데이터그리드 영역에서 저장/관리하여 웹 시스템의 가용성과 확장성을 높여 줍니다. 이러한 아키텍처를 이용하여 여러 종류 제품의 WAS 인스턴스 간의 세션공유나 서로 다른 웹 애플리케이션의 간의 세션 공유를 지원합니다. 또한 Clustering 기능이 미비한 Tomcat 인스턴스 간의 세션 클러스터링도 지원합니다.
주요 기능
- Servlet 2.5 이상을 지원한 WAS 서버에 대한 세션 클러스터링 지원
- Data Grid Library 를 사용하여 WAS 내의 메모리를 사용하여 클러스터링 지원
- 별도로 Data Grid 서버를 구성하여 세션 데이터그리드 형태 지원
- 서로 다른 웹 애플리케이션 간의 세션 공유 기능
- 웹 애플리케이션에서 중복 로그인 방지 기능
- 세션 정보에 대한 모니터링 기능
(Active 세션 개수, 세션 생성/소멸 개수, 중복 로그인 횟수, 초당 세션 생성/소멸/중복로그인 횟수에 대한 MBean 모니터링)
- 세션에서 사용하는 메모리 사용량 모니터링
- 주요 Static Contents에 대해 세션을 생성하지 않도록 필터링
source : http://www.opennaru.com/open-source/containers-metaphor-for-what-docker-is/
컨테이너가 구축하는 애플리케이션에 대한 표준화된 컨테이너는 화물 운송 분야의 컨테이너는 대한 은유입니다.
컨테이너가 Tantlinger 에 의해 기술적인 표준화가 되기 전부터 오랫동안 구축된 개념입니다. HP, 오라클, IBM 과 같은 대형 벤더들은 수년간 켄테이너 기술을 사용해 왔으며, 특히 구글은 내부 프로젝트에서 매우 유사한 구현 방식을 사용하였습니다.
도커는 오픈소스와 커뮤니티를 중심으로 기술의 표준화와 발전을 이끌고 있습니다.
화물 컨테이너의 내부 화물은 운송에 중요하진 않습니다. 세계의 모든 선박과 트럭 그리고 크레인은 컨테이너 규격에 적합해야 합니다. 마찬가지로 도커 컨테이너도 어떤 애플리케이션( 관련 파일, 프레임워크, 의존성 등)이 내부에 있는지 중요하지 않습니다.
컨테이너는 모든 리눅스 배포판에서 실행되며, AMAZON AWS, Micrsoft Azue, Google Cloud Platform, Rackplace 등 모든 퍼블릭 클라우드 환경에서 운영됩니다.
해외로 이사를 간다고 가정을 하면 사실상 컨테이너에 이사짐을 넣은 후 트럭으로 이동하여, 크레인으로 배에 옮겨져 다른 나라로 운송합니다. 마찬가지로 컨테이너를 이용하면 개발자가 로컬 시스템에서 애플리케이션을 빌드하고 테스트 할 수 있으며
애플리케이션을 서버에 Push할 수 있습니다. 개발자는 컨테이너로 배포하게 되면 개발환경이나 운영환경이나 동일하게 동작할 것이라는 것을 알수 있습니다.
CNA(Cloud Native Architecture)
MSA(Micro Service Architecture)
Service Mesh
MDA(Micro Data Architecture)
Data Mesh
MIA(Micro Inference Architecture)
Inference Mesh
Cloud-Native Architecture
MSA(Micro Service Architecture)
MDA(Micro Data Architecture)
MIA(MIcro Inference Architecture)
MSA-Service Mesh
MDA-Data Mesh
MIA-AI Inference Mesh
Kubernetes
Container
Kubeflow
Volcano
Apache Ynikorn
ChatGPT
AGI(Artificial General Intelligence)
ASI(Artificial Specialized Intelligence)
초-전환시대
초-연결시대
SQream GPU DBMS
Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해 서비스화해 제공하고
필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는 MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 MSA형식으로 MDA(Micro Data Architecture)로 전환 후 Data Mesh형태로 관리하고,
AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현(MACRO)보다는 작은|특화된 Deep Learning Network(Model)들로 작게 쪼개서 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타,트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
from : http://w3labs.kr/?p=5389
시중에 나와있는 웹소켓 솔루션은 정말 많은 종류가 있습니다.
하지만, 웹소켓을 지원하지 않는 IE6+ , Android2.1+ 버전까지 지원하는 웹소켓 솔루션은
Kaazing 과 Socket.IO 뿐이 없는 실정입니다.
Kaazing 과 Socket.IO 에서는 시뮬레이션모드 라는 것으로 웹소켓 미지원 브라우저에서도 동작 하는데요.
이 시뮬레이션 모드에서 기술의 차이가 발생 합니다.
Socket.IO 는 Long-Polling(Comet) 방식으로 시뮬레이션을 하고 있습니다.
결국 웹소켓이 나오기 이전 기술, 그러니까 결국 Legacy 기술을 이용하는 것으로 웹소켓과는 거리가 멀지요.
웹소켓의 장점인 Full-Duplex 방식이 아닌 Half-Duplex 방식으로 응답(Latency)가 느리고 가비지 트래픽이 발생하게 되지요.
Kaazing 의 경우는 유료 솔루션 답게 시뮬레이션을 자체 기술로 해결 했는데요.
Ajax 통신 2개를 열어 놓고, 하나는 Send를, 하나는 Receive를 담당하게 합니다.
웹소켓과 동일한 Full-Duplex 방식으로 빠른 응답속도와 적은 트래픽을 유발하게 되지요.
또한, 이러한 시뮬레이션 모드가 어떠한 구성환경에서도 완벽하게 동작 하는데요.
* Single Sign-On (SSO) 연동
* VPN 2중화 환경
* DDMZ 환경
* Proxy Server 에서 패킷을 감청 할 수 있는 환경(보안 유지)
* Active-Active Load Balancing
* Binary Data의 WebSocket 지원원
* 병렬적 서버 확장
* 국내 기술지원
이러한 엔터프라이즈 환경의 Needs 를 모두 충족시켜 주고 있습니다.
Kaazing을 도입한 회사들을 보면 솔루션의 완성도를 보실 수 있습니다.
금융권
* JP모건
* HSBC 은행
* 골드만삭스 외 4개사
Software & Service
* 오라클
* 인텔
* 시스코
* 에릭슨
* 구글
* 퀄컴
* 맥아피 외 8개사
Media & Entertainment
* Skybet
* AOL
* The Daily
* CNN Money 외 5개사
기타
* Southwest Airlines 외 4개사
더 자세한 내용은 아래 슬라이드를 참조 하시기 바라며,
문의 사항은 연락 주시기 바랍니다. (contact@w3labs.kr)
* URL : http://w3labs.kr/?p=5389
감사합니다.
대규모 클러스터링 환경에서 사용자에게 투명하게 하나의 시스템으로 보일 수 있도록 세션 클러스터링 기능을 제공하는 WAS 고가용 솔루션입니다. 지금까지 WAS 에 저장되던 세션 영역을 제거하고 이를 데이터그리드 영역에서 저장/관리하여 웹 시스템의 가용성과 확장성을 높여 줍니다. 이러한 아키텍처를 이용하여 여러 종류 제품의 WAS 인스턴스 간의 세션공유나 서로 다른 웹 애플리케이션의 간의 세션 공유를 지원합니다. 또한 Clustering 기능이 미비한 Tomcat 인스턴스 간의 세션 클러스터링도 지원합니다.
주요 기능
- Servlet 2.5 이상을 지원한 WAS 서버에 대한 세션 클러스터링 지원
- Data Grid Library 를 사용하여 WAS 내의 메모리를 사용하여 클러스터링 지원
- 별도로 Data Grid 서버를 구성하여 세션 데이터그리드 형태 지원
- 서로 다른 웹 애플리케이션 간의 세션 공유 기능
- 웹 애플리케이션에서 중복 로그인 방지 기능
- 세션 정보에 대한 모니터링 기능
(Active 세션 개수, 세션 생성/소멸 개수, 중복 로그인 횟수, 초당 세션 생성/소멸/중복로그인 횟수에 대한 MBean 모니터링)
- 세션에서 사용하는 메모리 사용량 모니터링
- 주요 Static Contents에 대해 세션을 생성하지 않도록 필터링
source : http://www.opennaru.com/open-source/containers-metaphor-for-what-docker-is/
컨테이너가 구축하는 애플리케이션에 대한 표준화된 컨테이너는 화물 운송 분야의 컨테이너는 대한 은유입니다.
컨테이너가 Tantlinger 에 의해 기술적인 표준화가 되기 전부터 오랫동안 구축된 개념입니다. HP, 오라클, IBM 과 같은 대형 벤더들은 수년간 켄테이너 기술을 사용해 왔으며, 특히 구글은 내부 프로젝트에서 매우 유사한 구현 방식을 사용하였습니다.
도커는 오픈소스와 커뮤니티를 중심으로 기술의 표준화와 발전을 이끌고 있습니다.
화물 컨테이너의 내부 화물은 운송에 중요하진 않습니다. 세계의 모든 선박과 트럭 그리고 크레인은 컨테이너 규격에 적합해야 합니다. 마찬가지로 도커 컨테이너도 어떤 애플리케이션( 관련 파일, 프레임워크, 의존성 등)이 내부에 있는지 중요하지 않습니다.
컨테이너는 모든 리눅스 배포판에서 실행되며, AMAZON AWS, Micrsoft Azue, Google Cloud Platform, Rackplace 등 모든 퍼블릭 클라우드 환경에서 운영됩니다.
해외로 이사를 간다고 가정을 하면 사실상 컨테이너에 이사짐을 넣은 후 트럭으로 이동하여, 크레인으로 배에 옮겨져 다른 나라로 운송합니다. 마찬가지로 컨테이너를 이용하면 개발자가 로컬 시스템에서 애플리케이션을 빌드하고 테스트 할 수 있으며
애플리케이션을 서버에 Push할 수 있습니다. 개발자는 컨테이너로 배포하게 되면 개발환경이나 운영환경이나 동일하게 동작할 것이라는 것을 알수 있습니다.
CNA(Cloud Native Architecture)
MSA(Micro Service Architecture)
Service Mesh
MDA(Micro Data Architecture)
Data Mesh
MIA(Micro Inference Architecture)
Inference Mesh
Cloud-Native Architecture
MSA(Micro Service Architecture)
MDA(Micro Data Architecture)
MIA(MIcro Inference Architecture)
MSA-Service Mesh
MDA-Data Mesh
MIA-AI Inference Mesh
Kubernetes
Container
Kubeflow
Volcano
Apache Ynikorn
ChatGPT
AGI(Artificial General Intelligence)
ASI(Artificial Specialized Intelligence)
초-전환시대
초-연결시대
SQream GPU DBMS
Cloud와 Cloud Native의 목표는.. 왜? 어떻게? 뭐가 좋아지나...
1. (왜) 가속화된 초-전환, 초-연결 IT 환경변화에 대비하기 위해서
2. (어떻게-H/W) IT H/W 부분은 IaaS 서비스화하여
점유된, Over Subscription된 H/W(Server, Network, Storage)들 모아서 Pool화하고, 가상화기술을 통해 Tenant로 자원들을 분리해 서비스화해 제공하고
필요시 적시에 Pool의 가상H/W를 제공하고, 상황에 따라 확장・축소(Scale in/out, up/down)하면서, 축소된 자원을 다른 요청들을 위해 빠르게 재-할당하는 유연성을 제공하고
3. (어떻게-S/W) S/W 부문도
PaaS, SaaS 적극 활용으로 App.개발 시간을 단축하고
App.분야인 기존 MACRO Service Architecture형 Monolith Architecture(Web-WAS-DB)를 작게 쪼개서 변화에 빠르게 적응할 수 있는 MSA(Micro Service Architecture)로 변경하여 Service Mesh형으로 관리하고
Data분야도 Data Warehouse, DataLake(Bigdata), LakeHouse등 기존 MACRO Data Architecture를 MSA형식으로 MDA(Micro Data Architecture)로 전환 후 Data Mesh형태로 관리하고,
AI로 동적프로그램 생성하여 App.개발시간 단축하고, AI분야도 초-거대 AI구현(MACRO)보다는 작은|특화된 Deep Learning Network(Model)들로 작게 쪼개서 MIA(Micro Inference Architecture)로 비지니스 환경에 적용하고 Inference Mesh형태로 관리하는 시스템으로 전환하고
4. (어떻게-조직) 조직구조도 CI/CD형 DevOps환경, 데이타,트랜잭션중심업무중심, 기술중심 문제해결중심, 직능중심조직직무중심조직으로 전환하면
5. (좋아지는 것) 초-전환, 초-연결 환경에 빠르고, 지속적으로 적응할 수 IT as a Product 환경을 구현하는 것
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
<1탄>왜 마이크로 서비스인가 - 마이크로서비스로 구성된 애플리케이션 소개
Session abstract:
이번 세션에서는 무엇이 마이크로 서비스고, 어떤 철학과 사상을 가지고 있는지 알아봅니다. 세션이 종료되면 참석하신 분들은 마이크로 서비스의 구성에서 어떤 내용이 중요한지 알게 됩니다. 전체 시리즈로 진행되는 첫 세션 입니다.
Session agenda:
-실 서비스용 데이터베이스를 종료한다면 어떤 일이 벌어질까
-마이크로서비스와 마이크로서비스가 아닌것
-어떻게 시작해야 하나
-마이크로서비스 애플리케이션 소개
-클라우드 네이티브(클라우드 최적화란)
designing, implementing and delivering microservices with event storming, spr...uEngine Solutions
Implementing Microservices is something like an adventure. Analyzing and decomposing microservices with applying DDD and make them into code, all is not easy. With new simple approach - Event storming, designing and implementing an event-driven MSA became easier ever seen before.
Similar to 마이크로서비스 아키텍처 도입의 허와 실 - feat. 문제는 도메인이야 (20)
2. 발표자 소개
기술 배경
클라우드 네이티브 아키텍처 설계, 빅데이터/인공지능 연구 개발,
고성능 고가용성 데이터베이스
주요활동
IT 전문서 번역 (마이크로서비스 도입 이렇게 한다, 클린 코드, 피플웨어, 해커: 광기의 랩소디 등)
개발강의 (삼성전자, 삼성 SDI, SK C&C, 현대자동차 기술 세미나와 교육)
활동채널
블로그: https://jhrogue.blogspot.com
슬라이드 셰어: https://www.slideshare.net/jrogue/presentations
유튜브: https://www.youtube.com/c/박재호dev
문의 jrogue@gmail.com
박재호
3. 일상화된 마이크로서비스 아키텍처
B21 스텔스 폭격기는 마이크로서비스 아키텍처와 쿠버네티스에 기반해
다목적 임무 수행(폭격, 전투 지휘, 정보 수집)이 가능한 형태로 제작됨
5. 아키텍처 변경의 어려움
운영 중인 서비스의 아키텍처를 변경하는 작업은 날고 있는
비행기의 엔진을 교체하는 작업과 유사하다!
* 복잡도 때문
- 분산 시스템은 본질적으로 복잡하다(complex)
- 네트워크 대기 시간, 결함 포용, 재시도 폭풍, …
- 운영 부하도 걸림 → 따라서 DevOps 모델을 적용
* 참고: simple vs complicated vs complex vs chaotic
- simple → 쉽게 알 수 있다
- complicated → 쉽지는 않지만 그래도 알 수 있다
- complex → 완전히 알지는 못해도 합리적으로 예측할 수 있다
- chaotic → 알지도 예측도 못한다
마이크로서비스는 왜 어려운가?
6. 아키텍처 변경의 어려움 – 분산 애플리케이션의 요구
- 배포/롤백
- 배치/스케줄링
- 구성 관리
- 자원/실패 격리
- 자동/수동 확장
- 하이브리드 워크로드
(무상태형, 상태형, 서버
리스 등등)
- 서비스 발견
- 동적 트래픽 라우팅
- 재시도, 타임아웃, 회로 차단
- 보안, 암호화
- 관측성과 추적
- API를 위한 커텍터
- 프로토콜 변환
- 메시지 변환
- 필터링, 경량 메시지 라우팅
- 점-대-점, pub/sub 상호 작용
- 작업흐름 관리
- 시간적인 스케줄링
- 분산 캐싱
- 멱등성
- 사가
- 애플리케이션 상태
The Evolution of Distributed Systems on Kubernetes
by @bibryam at QConLondon2020
7. 모놀리스가 무조건 나쁠까?
레거시와 모놀리스는 우리의 적이 아니다. 살아갈 집이다.
단일 프로세스 모놀리스 모듈식 모놀리스 모듈식 모놀리스
(w/ 분해된 데이터베이스)