AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
AWS 클라우드를 활용하면 사용자의 트래픽에 따라 IT 인프라 아키텍처를 확장할 수 있습니다. 이번 강연에서는 서비스 초기의 작은 트래픽에 대응할 수 있는 단순한 아키텍처로 시작해 사업 성장 후의 수백만 사용자에 달하는 대규모 트래픽을 지탱할 수 있는 고확장성 아키텍처에 이르기까지의 단계별 아키텍처 구성 방법에 대해 소개해 드리고 컴퓨팅 및 데이터베이스 선택 및 사용자 증가에 따른 트래픽 경감 방법, 오토스케일링 및 모니터링과 자동화, DB 부하 분산, 고가용성 확보 등에 대한 다양한 모범사례를 알려드릴 예정입니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
클라우드 여정의 시작 - 클라우드 전문가 조직의 프랙티컬 가이드-김학민, AWS SA Manager::AWS 마이그레이션 A to Z 웨비나Amazon Web Services Korea
마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
Secured API Acceleration with Engineers from Amazon CloudFront and SlackAmazon Web Services
In this session, we talk about how customers running their websites or APIs on AWS can improve security while increasing performance of their applications by using Amazon CloudFront’s globally distributed edge locations. We go through architectural patterns such as TLS termination at the edge, inherent DDoS Protection, and AWS Web Application Firewall (WAF). Then Slack, makers of cloud-based team collaboration software, discuss how they are using ELB and CloudFront to accelerate their APIs.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
OpenSearch는 배포형 오픈 소스 검색과 분석 제품군으로 실시간 애플리케이션 모니터링, 로그 분석 및 웹 사이트 검색과 같이 다양한 사용 사례에 사용됩니다. OpenSearch는 데이터 탐색을 쉽게 도와주는 통합 시각화 도구 OpenSearch와 함께 뛰어난 확장성을 지닌 시스템을 제공하여 대량 데이터 볼륨에 빠르게 액세스 및 응답합니다. 이 세션에서는 실제 동작 구조에 대한 설명을 바탕으로 최적화를 하기 위한 방법과 운영상에 발생할 수 있는 이슈에 대해서 알아봅니다.
카카오 광고 플랫폼 MSA 적용 사례 및 API Gateway와 인증 구현에 대한 소개if kakao
황민호(robin.hwang) / kakao corp. DSP개발파트
---
최근 Spring Cloud와 Netflix OSS로 MSA를 구성하는 시스템 기반의 서비스들이 많아지는 추세입니다.
카카오에서도 작년에 오픈한 광고 플랫폼 모먼트에 Spring Cloud 기반의 MSA환경을 구성하여, API Gateway도 적용하였는데 1년 반 정도 운영한 경험을 공유할 예정입니다. 더불어 MSA 환경에서는 API Gateway를 통해 인증을 어떻게 처리하는지 알아보고 OAuth2 기반의 JWT Token을 이용한 인증에 대한 이야기도 함께 나눌 예정입니다.
- 동영상 보기: https://www.youtube.com/watch?v=Rq4I57eqIp4
Amazon RDS 프록시는 Amazon Relational Database Service (RDS)를 위한 완전 관리형 고가용성 데이터베이스 프록시로, 애플리케이션의 확장 성, 데이터베이스 장애에 대한 탄력성 및 보안 성을 향상시킬 수 있습니다. (2020년 6월 서울 리전 출시)
source : http://www.opennaru.com/cloud/msa/
마이크로서비스는 애플리케이션 구축을 위한 아키텍처 기반의 접근 방식입니다. 마이크로서비스를 전통적인 모놀리식(monolithic) 접근 방식과 구별 짓는 기준은 애플리케이션을 핵심 기능으로 세분화하는 방식입니다. 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있습니다. 이는 개별 서비스가 다른 서비스에 부정적 영향을 주지 않으면서 작동(또는 장애가 발생)할 수 있음을 의미합니다.
클라우드 여정의 시작 - 클라우드 전문가 조직의 프랙티컬 가이드-김학민, AWS SA Manager::AWS 마이그레이션 A to Z 웨비나Amazon Web Services Korea
마이그레이션 도중 고객 IT팀은 On-premise 운영 모델에서 클라우드 운영 모델로 전환되어야 합니다. 전환 도중에 ITIL을 클라우드, 애자일, DevOps 기반 역량과 프로세스에 매핑해야 합니다. 해당 세션에서는 클라우드 운영 모델로 원활한 전환을 도와주는 CEE (Cloud Enablement Engine)의 작동 원리 및 적용 방식을 살펴보고자 합니다.
Secured API Acceleration with Engineers from Amazon CloudFront and SlackAmazon Web Services
In this session, we talk about how customers running their websites or APIs on AWS can improve security while increasing performance of their applications by using Amazon CloudFront’s globally distributed edge locations. We go through architectural patterns such as TLS termination at the edge, inherent DDoS Protection, and AWS Web Application Firewall (WAF). Then Slack, makers of cloud-based team collaboration software, discuss how they are using ELB and CloudFront to accelerate their APIs.
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study (박주홍 데이터 분석 및 인프라 팀...Amazon Web Services Korea
데브시스터즈 데이터 레이크 구축 이야기 : Data Lake architecture case study
이 세션에서는 데브시스터즈의 Case Study를 통하여 Data Lake를 만들고 사용하는데 있어 요구 되는 사항들에 대해 공유합니다. 여러 목적에 맞는 데이터를 전달하기 위해 AWS 를 활용하여 Data Lake 를 구축하게된 계기와 실제 구축 작업을 하면서 경험하게 된 것들에 대해 말씀드리고자 합니다. 기존 인프라 구조 대비 효율성 및 비용적 측면을 소개해드리고, 빅데이터를 이용한 부서별 데이터 세분화를 진행할 때 어떠한 Architecture가 사용되었는지 소개드리고자 합니다.
Once upon a time, Personal Information Management was, well, personal. The “Personal Information” was phone
numbers and to-dos and notes and emails and personal papers and files and folders. The “Management” was about
how one organized what one had so that it could be re-found when it was needed to get our everyday work done.
Things have changed. Personal Information is still personal, but there is so very much more of it. My bookmarks. My
songs. My social network. And some of it is considerably more personal than it used to be. My locations as reported
by my smart phone. My weight as gathered by my wifi scale. My steps and heart rate sensed during my workouts.
Furthermore, as personal as it is, we are choosing to share much of it, for reasons that go far beyond simply getting our
everyday work done. “Management” seems like an increasingly inadequate word for what we do with our personal
information. In this talk I reflect on PIM, how it has changed over the two decades I’ve been studying it, and the
challenges I see ahead.
GDG DevFest 2017 Seoul 프론트엔드 모던 프레임워크 낱낱히 파헤치기Kenneth Ceyer
GDG DevFest 2017 Seoul
프론트엔드 모던 프레임워크 낱낱히 파헤치기 세션의 발표자료입니다.
이 발표자료에서는 여러분이 항상 궁금해 하신
프론트엔드 프레임워크의 삼총사
Angular, React, VueJS를 다차원적으로 깊이있게 비교하고 각각의 이점과 특화된 기능을 소개하고 있습니다.
이러한 프레임워크를 경험해보지 못한 분들을 위해 프레임워크 별로 특징부터 쉽게 접근하여 설명하기 때문에 경험 불문하고 가볍게 읽어 보실 수 있습니다.
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 환경을 구현하는 것
Domain Driven Design 기반의 마이크로서비스 디자인 방법론에 대해 설명을 하고 피보탈이 권장하는 모노리스 애플리케이션의 마이크로서비스 전환 방법론에 대해 살펴봅니다. 또한 실제 마이크로서비스 프로젝트에서 발생할 수 있는 우려사항들에 대해서도 국내 프로젝트 경험을 바탕으로 짚어봅니다.
[Container 기반의 DevOps] Cloud Native
열린기술공방에서 처음으로 런칭한 교육 프로그램의 트렌드 세션 자료입니다. 급변하는 환경에 맞춘 SW를 개발하고 배포하기 위해, 빠른 의사결정을 할 수 있는 환경과 프로세스가 더욱 중요해지고 있는데요. 기업들에게 왜 클라우드 네이티브 전략이 필수적인지에 대해 소개한 자료입니다.
열린기술공방의 교육 과정을 통해 Kubernetes위에서 동작하는 Application의 빌드부터 배포까지의 과정을 한 눈에 확인하실 수 있습니다.
어느 해커쏜에 참여한 백엔드 개발자들을 위한 교육자료
쉽게 만든다고 했는데도, 많이 어려웠나봅니다.
제 욕심이 과했던 것 같아요. 담번엔 좀 더 쉽게 !
- 독자 : 백엔드 개발자를 희망하는 사람 (취준생, 이직 희망자), 5년차 이하
- 주요 내용 : 백엔드 개발을 할 때 일어나는 일들(개발팀의 일)
- 비상업적 목적으로 인용은 가능합니다. (출처 명기 필수)
Kubernetes advanced sheduling
- Taint and tolerant
- Affinity (Node & inter pod)
Learn how to place Pod like (same or different) node, rack, zone, region
2. 발표자 소개
조 대 협 본명: 조병욱
회원 13만명 온라인 개발자 커뮤니티 자바스터디(www.javastudy.co.kr) 운영자.. (기억의 저편..)
한국 자바 개발자 협회 부회장,서버사이드 아키텍트 그룹 운영자
벤쳐 개발자
BEA 웹로직 기술 지원 엔지니어
장애 진단, 성능 튜닝
NHN 잠깐
오라클 컨설턴트 (SOA,EAI,ALM,Enterprise 2.0,대용량 분산 시스템)
MS APAC 클라우드 수석 아키텍트
프리렌서 (잘나가는 사장님)
삼성전자 무선 사업부 B2B팀 Chief Architect
전 피키캐스트 CTO
6. 요즘 실리콘 밸리에서는
잘하는 것 부터 시작해서 발전
대세는 스크립트 언어
스스로 공부,스스로 개발,내재화
소규모 조직 [10~20명]
대우 받는 개발자
클라우드 컴퓨팅
빠른 시장 진입,저비용,누구나 서비스
젊은 개발자 (한국은 접는 개발자)
협업
[SNS,오픈소스,GitHub]
CI to CD
유연한 고용 시장
메뚜기!!
3년 넘으면 바보
한국은 배신자
개발자의 변신은 무죄
새로운 능력..!! 잉여력STAR UP
8. • 3가지 관점에서 트랜드를 분석
소프트웨어 개발
중심의 변화
시대별 기술의
변화
개발 방식의
변화
9. 소프트웨어 개발 중심의 변화
시대별로 소프트웨어를 개발하는 이유가 어떻게 변화 했을까?
우리가 지금 쓰는 기술들은 왜?
인터넷,SNS의 시대엔터프라이즈 시대 모바일 시대
서비스 사업자
대단한 님들!!
벤더
개발자!!
(스타트업,앱개발자)
당신도 할 수 있다
기술 변화의 주체
10. 시대별 기술의 변화
인터넷,SNS의 시대엔터프라이즈 시대 모바일 시대
EJB, JAVA, SERVLET/JSP
들어는 보셨나요?
벤더 : “이게 최신 기술임!!.
교육 부터 다 해드림!!
나만 믿으세요” $$$
먹고 살 걱정 없음!!
Spring,Hibernate,MySQL
,Struts,Ruby On
Rails,PHP ..
서비스사 : 제품은 비싸요.
우리가 만든거 가져다 쓰
세요!! 대신 책임은 니꺼!
공부해야 함.. 압박!!
조금씩 먹고 살기 힘들어짐
(버틸만 함-그래도 대세는 있음)
JavaScript,
Cloud,node.js, Ruby
on Rails,NoSQL
개발자:어려워서 못 써
먹겠음. 차라리 만듬..!!
기술 변화도 심함
이제는 생존의 문제!!
명퇴가 눈앞에..
11. 시대별 기술 변화
인터넷,SNS의 시대엔터프라이즈 시대 모바일 시대
UNIX 서버
벤더 소프트웨어
X86 서버
오픈소스
클라우드
오픈소스
스크립트 언어!!
ORACLE MySQL NoSQL
API
HTML 5
안드로이드,IOS웹웹,4GL
쉽고 빠른 개발
기술의 홍수
대체제 성격
새로운 기술 흐름을
만드는 전환기
안정성,미션 크리티
컬 업무 위주
12. 시대별 기술자
• 왜 이런 현상이 생기는가? 쉬운 기술이 주목 받는 이유
스타트업. 앱 개발조합 1.
기획자 창업
디자이너 - 기획자 여자 친구
개발자 – 기획자의 친구 (디자이너를 사랑함)
조합 2.
디자이너 창업
기획자 - 디자이너의 여자 친구
개발자 – 디자이너의 친구 (기획자를 사랑함)
개발자 1인 혼자 다 해야함 (클라이언트, 서버, 하드웨어 인프라)
배우기 쉬워야 함
돈 떨어지기전에 시장 출시해야함
빨리 배울 수 있어야함
14. 요구 되는 기술
빠른 출시, 빠른 업데이트가 필요
쉬운 기술 필요
낮은 비용
클라우드
컴퓨팅
스크립트
언어
운영 효율화
Devops
자동화
15. 클라우드 컴퓨팅
• 클라우드 컴퓨팅이 가져다준 변화
• 저비용으로 시작 가능
• 무제한적 리소스
• 지역/시간 제약에서 자유로워짐
• 쉽다. 하드웨어 인프라에 대한 작업이 없어짐
개발자가 인프라를 핸들링 가능
16. 클라우드 컴퓨팅
• 고려해야 하는 것들
빠른 시장 진입
운영비 절감
초기 투자비 절감
유연한 자원 사용
(Auto Scale Out)
느려요
IO Performance
싸지 않아요
기존 솔루션이 안돌아요
장애가 납니다. 아주 잘!!
(멀티 데이타 센타 설계)
클라우드 컴퓨팅의 장점 설계시 고려 사항
17. Devops의 등장
Devops = Development + Operation (개발 + 운영)
개발과 운영 조직을 하나로 묶어서 원할한 의사 소통
빠른 반영, 빠른 피드백 반영 가능
18. 자동화
• 흔한(평범한) 개발 환경 시나리오
• 개발자가 아침에 출근해서
• 이클립스를 키고, 소스코드를 Git에서 Check Out 한후
• JIRA를 통해서 오늘 할당된 작업을 확인 한후에 코딩을 하고
• PC에서 Junit등을 이용하여 단위테스트등을 모두 끝 마치고
• 코드를 Git에 Commit하면
• Jekins에서 코드 변경을 감지하여, 자동으로 Check Out해서 mvn을 이용해서 컴파일 하고, 테스트 서버에 배포해서 단
위 테스트를 모두 수행하고, 코드의 라인커버리지를 분석하여 리포팅 한다.
• 팀장은 빌드가 완료되었음을 확인하고, 단위 테스트 100% 완료 및 라인 커버리지 80% 완료를 확인한다.
• 릴리즈 날짜가 오면, 배포 엔지니어는 별도의 작업 없이 Jenkins에서 빌드된 그날 WAR를 확인하고, Fabric으로 된 배포
스크립트를 수행하면, 자동으로 개발,QA 환경으로 배포가 되고, 환경별로 필요한 resource 파일들이 자동으로
customization해서 배포가 완료된 후, Junit 기반의 단위 테스트, SOAP UI 기반의 REST API 테스트, Seleniuem 기반의
UI 테스트까지 자동으로 완료 한다. 만약에 배포나 테스트가 실패하면, 이전 버전으로 자동 롤백한다.
22. 레퍼런스
• SOA
• SOA Design Pattern (Thomas Erl) – 좋은지 잘 모르겠음. 유명하니까.
• Applied SOA – Michael Rosen – 추천
• Enterprise SOA – Dirk Krafzig – 옛날 책이지만 추천
• Enterprise integration Pattern – Gregor Hohpe 연동 패턴 잘 설명됨
• 사이트
• HighScalability.com
• http://aosabook.org/en/distsys.html
• http://martinfowler.com/articles/microservices.html
23. 대용량 분산 시스템 디자인 패턴
• 대용량 분산 시스템도 디자인 패턴이 있고 대부분의 설계가 비슷함
• 여기서는 자주 사용되는 공통되는 패턴을 소개함
• 계속해서 변화되기 때문에 꾸준이 패턴을 공부하는 것이 필요함
24. 분산 아키텍쳐 디자인 패턴
• 서비스 지향적
• Redudant & Resilience
• 파티셔닝
• Query Off Loading
• 캐슁
• CDN & ADN
• 로깅
• 비동기 패턴
25. 디자인 PRINCIPALS
• 디자인시 다음과 같은 항목을 고려해서 디자인 해야 함
• 가용성 (Availability)
• 성능 (Performance)
• 확장성 (Scalability)
• 안정성 (Reliability)
• 관리성(Manageability)
• 비용 (Cost)
• 우선 순위를 정하는 것도 도움이 됨
26. 서비스 지향적인 접근 방법 (Service Oriented Approach)
• Loosely coupled
• 기능을 API로 제공
• 표준 API
• 공통 서비스
• 컴포넌트화
27. Redundant vs Resiliency
• Redundant (엔터프라이즈 서비스에 유리)
• 이중화
• 비싼 고가용성 서버, 클러스터링, 엔터프라이즈
• 트렌젝션을 깨지지 않고 보장
• Resilience (대세, B2C 서비스에 유리)
• 장애가 나면 빠르게 복구
• X86 Commodity 하드웨어, Shared Nothing, B2C
• 트렌젝션이 깨짐
왜?) 대용량 서비스에서 비용을 낮추다 보니, 장애가 남. 장애가 나는 것을 전제로 하고, 고 가용에
들어가는 비용을 낮춤
28. 파티셔닝 (샤딩/SHARDING)
• 데이타를 여러 DB에 나눠서 자ㅓ장
• 방식
• 수평적 샤딩(Horizontal Sharding)
• 수직적 샤딩(Vertical Sharding)
• 데이타 쏠림에 주의
• 검색이 어려움. (별도의 Index 서버 고려)
• 일반적으로 애플리케이션에서 분산 처
리 (솔루션 차원에서 지원하기도함.)
20 대
30 대
40대
댓글 DB
컨텐츠 DB
사용자 DB
수직적 샤딩 수평적 샤딩
29. 쿼리 오프 로딩
• 읽기와 쓰기를 분리
• 일반적으로 읽기:쓰기 비율 = 80:20
• Master node : 쓰기 중심
• Salve node : 읽기 중심 (무한 확장 가능)
• 중간에 스테이징 DB를 놓는 방법을 고려
• 애플리케이션에서 분리 되서 구현현되어야
함
애플리케이션
쓰기 커넥션풀 읽기 커넥션풀
쓰기 DB
스테이징 DB
읽기 DB
스테이징 DB
스테이징 DB
30. 캐슁
• 중앙 집중형 캐쉬
Client
Client
Client
Cache Data
Client
Client
Client Cache
Data
Reverse proxy
Service Bus
Pass through Referal
Client
Client
Client
Data
Cache
Cache
Cache
Consistencyhashing
Client
Client
Client
Cache Data
Local
Cache
Local
Cache
Local
Cache
• 분산형 캐쉬 • 분산형 캐쉬
31. 부하분산 (로드 밸런싱)
• 로드밸런싱
• 알고리즘
• Hash
• Round Robin
※ Sticky Session (Timeout 주의)
• L4,L7,Reverse Proxy(HAProxy, Nginx), ELB
• 글로벌 로드 밸런싱
• Dynamic : DNS approach (Amazon Route 53)
• Static : Look up & pinning (*)
• CDC
• Regional info
• 복제할 필요가 없음.
(비행기 타고 날라가도 같은 데이타 센터에)
LB
TransactionServer
TransactionServer
TransactionServer
32. CDN & ADN
• CDN
• 정적 컨텐츠를 지역적으로 분산된 EDGE NODE에 배포
• 지능형 기술 보유 ( CSS,HTML 압축, WebP 변환등)
• CloudFlare (무료 CDN)
• ADN
• 압축 전송 : 리버베드 (Riverbed)
• 전용망 서비스 : 아카마이, AWS 클라우드 커넥스
• 클라우드 리전에 프록시 서버를 넣어도 유사 효과
33. 로깅
• 글로벌 트렌젝션과 로컬 트렌젝션
Component
Component
Component
진입점
트랜젝션 ID가 없으면 Global Tx
Id 생성
아니면 API G/W 사용
중간 Tx 포인트 : 같
은 GTX ID에 Local
TX ID 증가
GTXID:LocalTXID =
0001:001
GTXID:LocalTXID =
0001:002
GTXID:LocalTXID =
0001:003
• TX ID Propagation
• GTX ID : Header에 넘겨서 전달
• Local TX ID : Thread Local 에 넘겨서, Local Tx내에 Propagation
• APM 이나 로깅 서비스를 사용하는 것도 좋음
• Newrelic, Scout (오픈소스), 제니퍼
34. 분산 로깅
• 로깅 방식
• Pulling
• Shared storage
• 로깅 계층
• 시스템 로깅 (ELK etc)
• 이벤트 로깅 (Sentry)
• 모바일 로깅 (Flurry)
Server
Log
Server
Log
Server
Log
Log Server
pulling
Server
Log
Server
Log
Server
Log
Shared
Storage
Shared Storage
Log Server
• Good at auto-scale out/in
35. 비동기 패턴
• 대용량 트렌젝션 처리에 유리함
• 큐 자체에 대한 파티셔닝 (또는 대용량 큐 eg. 카프카)을 고려
Publisher Queue
Worker
Worker
Worker
Worker
Worker
Worker
Scale out
Publisher LB
:
37. 소프트웨어 개발 트렌드의 변화
• 대규모/긴기간 에서 소규모/단기간 (스타트업)
• 빠르고 잦은 릴리즈 (애자일)
• 고객의 VOC를 수용 (빅데이타,SNS)
• 개발과 운영을 통합 (DEVOPS)
• 열심히 일하는 것으로 감당 안됨 (자동화)
• 스페샬 리스트에서 제너럴 리스트 (수퍼엔지니어)
• 대용량 글로벌 스케일
• 오픈소스
• 구글링,STACKOVERFLOW,블로그,GITHUB
38. 소프트웨어 아키텍쳐의 변화
• 아키텍쳐 스타일의 변화
중앙 집중형 저장소
(RDBMS,NFS)
UX + 비지니스 로직
분산형 저장소
(NoSQL,Sharding)
REST API
비지니스 로직
자바스크립트
• HTML,Servlet/JSP
• EJB,Spring
• RDBMS
• Data center
• HTML5,AngularJS
• REST,WebSocket
• Node.JS,IMDG
• NoSQL,Sharding
• Cloud computing
동기식,중앙 집중형,고가용성
클러스터링
비동기식, 분산형, Resilience
Shared Nothing
39. 소프트웨어 아키텍쳐의 변화
• 다음 아키텍쳐 스타일 예상
• PaaS 기반의 조합형 아키텍쳐
• 서버리스(Serverless) 컴퓨팅
• 클라우드 인프라 프레임웍이 되는 아키텍쳐
• AWS Lambda, Azure Function, IBM Bluemix open whisk, Google Cloud function
• 인공지능 & 데이타 분석 API
• Google Cloud Vision API, Google Machine Learning, Microsoft Machine Learning API etc
• 빅데이타 분석 플랫폼 (Yahoo Flurry, Google Analytics etc)
40. 일반적인 시스템의 구조
• Business Logic :
일반적인 트렌젝션 처리 (서비스)
• External Interface :
대외 연계
• Data analytics :
데이타 수집 및 분석/리포트 생성
• OSS (Operation Support System) :
Tech Ops, Biz Ops
• BSS (Business Support System) :
리포트, PO 관리
Business logic
External Interface
Data analytics
OSS BSS
User
Request
External
System
Business
System
42. 대용량 분산 시스템 아키텍쳐
• SOA 기반의 대용량 분산 아키텍쳐
• ACCESS LAYER
• 사용자로 부터 들어오는 요청에 대한 관문
• 외부 시스템으로의 연계
• BUSINESS LAYER
• 요청에 대한 처리를 하는 주요 비지니스 로직
• PERSISTENT LAYER
• BUSINESS LAYER에 의해서 처리되는 또는 처리된 데이타를 저장
43. ACCESS LAYER
• 사용자 API에 대한 END POINT (접점)
REVERSE PROXY
• 부하분산(로그 밸런싱)
• SSL
• IP 블록킹
• 로깅
• 패킷 압축
(NGINX,APACHE,ELB,HAPROXY ..)
44. ACCESS LAYER
• API 게이트 웨이 (양날의검)
• API 에 대한 버스(백본) 역할
• CROSS CUTTING CONCERN 처리 (사
용자 인증, 인가, 로깅 처리)
• 메디에이션 (Mediation)
• 메세지 라우팅
• 메세지 변환
• 메세지 포맷 또는 프로토콜 변환
• MEP 변환 (동기 비동기)
• QoS 관린
• 오케스트레이션
(Strongloop, Tyk.io, APIgee, CA Layer 7) API 게이트웨이에 대해서는 MSA 부분에서 자세하게 다룸
45. ACCESS LAYER
• IDM (Identity management system : 계정 관리 시스템)
• 사용자 계정 관리 : 사용자 계정 및 사용자 프로파일 정보 저장 및 관리
• 접근 관리: Authentication, Authorization, Audit
• 계정 생명 주기 관리 : Identity lifecycle management
• 페데레이션 : 여러 계정 시스템을 묶어서 연동 (FACEBOOK 계정 로그인, 구글 계정 로그인 등)
• 프로비저닝 : 계정 정보를 다른 시스템으로 복사
• SINGLE SIGN ON (SSO)
• 이거 하나로만으로도 하루종일 이야기할 수 있음
• 보통 잘 모르고 시작했다가 나중에 폭망하는 컴포넌트.
(회사에 몇개의 IDM이 있는건 보통인 경우가 많음)
• WSO2 Identity manager를 보고 개념 잡는것을 추천
46. ACCESS LAYER
• 토폴로지별 IDM 구축 모델
독립형 계정 관리 모델
(Isolated IDM Model)
중앙 집중형 계정 관리 모델
(Centralized IDM Model)
연합형 계정 관리 모델
(Federated IDM Model)
• 시스템별 다른 계정으로 접근
• 시스템별 각자 사용자 정보 저장
• 시스템별 같은 계정으로 접근
• 사용자 정보를 중앙에 저장
• 시스템별 같은 계정으로 접근
• 시스템별 각자 사용자 정보 저장
47. ACCESS LAYER
• INTEGRATION (시스템 연계)
• Integration Type
• API Integration
• Native Adapter – JCA, Mecator,
TopLink ,WTC
• Data replication – ETL/CDC
• Consideration
• Logging (Audit)
• Retry
• Ignore
• Notification
• Retry
• Manual Handling EAI (Enterprise Application Integration) 패턴을 참고 하는 것이 좋음
Apache Camel 프레임웍 참고
48. BUSINESS LAYER
• 트렌젝션 처리 (동기)
• 우리가 일반적으로 생각하는 웹서버,애플리케이션 서버
• 서버에 요청이 들어오면 응답을 주는 구조
• SHARED NOTHING, STATELESS 구조로 설계하는 것이 좋음
• 중앙에 데이타 그리드 (레드스등)을 사용하거나
• 또는 상태 정보를 JWT 토큰등을 이용하여 유지
• 무거운 트렌젝션 처리, 동시에 적은 사용자만 처리 가능
• 톰캣과 같은 전통적인 애플리케이션 서버
• 일반적으로 멀티 쓰레드로 작동
• 가벼운 트렌젝션 처리, 동시에 많은 사용자 처리 가능 (C10K)
• 싱글 쓰레드 모델
• VERTE.X, NODE.JS, NGINX
50. BUSINESS LAYER
트렌젝션 처리 (싱글 쓰레드 모델)트렌젝션 처리 (멀티 쓰레드 모델)
http://strongloop.com/strongblog/node-js-is-faster-than-java/
51. BUSINESS LAYER
• 분산 트렌젝션 처리
• 엔터프라이즈 시스템 : XA 기반 2 PHASE-COMMIT - JTS 등 트렌젝션 코디네이터 필요
• B2C 서비스 시스템 : 보상 트렌젝션 (Compensation Transaction)
52. BUSINESS LAYER
• 비동기 처리
• 메세지 큐를 기반 (MQ, RABBIT MQ,KAFKA, SQS etc)
• 응답을 기다리지 않고 바로 리턴
• 큐 뒤에 다수의 워커가 메세지를 읽어서 처리 (워커수를 조정하여 대용량 처리가 용이)
메세지
WORKER
WORKER
WORKER
클라이언트
54. BUSINESS LAYER
• 비동기 에러 처리
• 재처리 (RETRY) : AGING 필요
• 무시
• 리포팅 (수동 처리)
메세
지 WORKER클라이언트
메세
지
재시도에러큐
무시
리포팅
처리중 에러
에러 호스피텔 (ERROR HOSPITAL)
55. BUSINESS LAYER
• 데이타 그리드
• 클러스터링된 중앙 공유 메모리
• 세션 및 상태(STATE) 정보 저장 및 공유
• REDIS, MEMCACHED 와 같은 메모리 그리
드 솔루션을 이용하여 구현됨
• 자가 클러스터링 기능이 중요
APPLICATION
SERVER
APPLICATION
SERVER
APPLICATION
SERVER
APPLICATION
SERVER
DATA GRID
56. BUSINESS LAYER
• 워킹스페이스 (WORKING SPACE)
• 작업을 위해서 임시로 파일을 저장하는 곳
• 파일 업로드, 인코딩등
• 로컬 파일 시스템을 사용하거나 HA를 대비하여 마운트 가능한 파일 시스템 사용 (NFS,
GLUSTER FS)
메세지 WORKER클라이언트
워킹 스페이스
동영상 파일 인코딩에서 워킹 스페이스 활용
57. PERSISTENCE LAYER
• RDBMS
• NOSQL
• COLUMN DB (CASSANDRA, HBASE)
• DOCUMENT DB (MONGODB, COUCHBASE,RIAK)
• GRAPH DB (NEO4J)
• 파일 시스템
• 일반 파일 시스템
• OBJECT STORAGE (AWS S3, AZURE BLOB, SWIFT etc)
58. ANALYTICS LAYER
• 데이타 분석 및 리포팅
• 단순 리포팅 인사이트 발견 예측
• 리포팅
• 리포트 생성 (엑셀)
• 대쉬 보드 (웹)
• AD-HOC 쿼리
로그 수집 변환 저장 리포팅
59. ANALYTICS LAYER
• 전통적인 OLAP 방식의 분석 방법
• ETL, 로그 수집 솔루션을 이용하여 정재
된 데이타를 데이타 웨어하우스에 중앙
저장
• 부서별 필요한 데이타가 있는 데이타
마트에 데이타를 옮기고 쿼리 수행
• 실시간 보다는 배치로 수행하는 것이
일반적
• 빅데이타?
하드웨어 어플라이언스. ORACLE 엑사
데이타 $$$$
데이타소스
데이타소스
데이타소스
데이타 수집
원본 데이타
데이타 웨어하우스
데이타 마트
데이타 마트
데이타 마트
리포팅
리포팅
리포팅
60. ANALYTICS LAYER
• 람다 아키텍쳐
• 실시간성 보장
• 전날까지의 데이타는 배치로
집계값 저장, 실시간 데이타는
원본 데이타를 고속 데이타 저
장소에 저장하여 조회
로그
오늘 까지 통계에 대한 누적 집계 (배치/RDBMS)
실시간 원본 데이타
리포팅
61. ANALYTICS LAYER
• 람다 아키텍쳐 구성
• 원본 데이타 저장소 : S3, HDFS
• 배치 처리 : Map & Reduce
• 배치 뷰 : AWS Redshift, Hbase, Elastic search
• 실시간 처리 : Storm, Spark
• 실시간 뷰 : Redis, RDBMS
원본 데이타 저장 배치처리 배치뷰
실시간 처리 실시간 뷰
로그수집
서빙 레이어배치 레이어
스피드 레이어
리포팅
62. ANALYTICS LAYER
• 람다 아키텍쳐 구성
원본 데이타 저장 배치처리 배치뷰
실시간 처리 실시간 뷰
로그수집
리포팅
데이타 사이언티스트
원본 데이타를 분석하여
새로운 의미 발견
데이타 엔지니어
새로운 알고리즘을 구현
1
2
3
63. OAM (OPERAION ADMIN & MONITORING) 시스템 운영 관리
• CMDB
• 애플리케이션의 CONFIG나 메타 정보 저
장소
• ZOOKEEPER,RDBMS
• CONFIGURATION MANAGEMENT
• 솔루션의 설정 정보를 관리하여, 솔루션
배포나 수정시 일괄 통제
• CHEF,PUPPET
• 배포 시스템
• RPM, FABRIC,ANCIBLE
• 모니터링
• 시스템 대쉬 보드 : NAGIOS
• 히스토리 모니터링 : CACTI,
GANGLIA,ZZABIX
• APM : JENNIFER, SCOUT
• 클라우드 모니터링 : NEWRELIC
• 로그 수집 시스템
• ELK (Elastic search + Logstash + Kibana)
• 에러 이벤트 핸들링 : Sentry
• 클라우드 서비스 : LogEntries
64. 글로벌 지원 시스템
• 고려 사항
• 레귤레이션 (REGULATION) : 법률 (데이타 위치와 이동, 개인 정보 보호, 결재)
• 지역별 기술 차이 : 클라우드 리전간 기능 차이 존재
• 네트웍 레이턴시, 3G/4G 보급율, 모바일 요금제
• 데이타 센간 데이타 복제
• DB 복제 : CDC, ETL
• API 복제 : API 중복 호출
• GLOBALIZATION (국제화) – 다국어 지원
• LOCALIZATION (지역화) – 한국은 카톡 로그인, 국가별 멀티 태넌트 시스템
65. 글로벌 지원 시스템
• 위치 선정
• 법적 이슈 및 세금 (미국, 중국, 유럽 순으로 유리)
• 네트워크 속도 (더블린, 미서부, 일본)
• 인력 수급의 용이성
• 세제 혜택
• 가격
• PROCUREMENT ( 서버 구매등)
66. 글로벌 지원 시스템
• 구성 방식
• Master center / Regional center
• Master / Master center
• 서비스 Look up : 주로 데이타 복제 가능 여
부에 따라 디자인
• 가까운 곳 우선 (데이타 센터간 동기화가 잘
되어 있을 경우 – 주로 근거리 또는 전용망)
• 특정 데이타 센터 지정 방식 ※ Global Load
Balancer 디자인이 관건
사실 요즘 망이 좋아서, 대충 아시아는 일본, 글로벌 서비스는 미국에 넣으면 됨
68. 클라우드 컴퓨팅
• 퍼브릭 클라우드
• IaaS,PaaS,SaaS
• 결코 싸지 않음
• 같은 서비스라도 지역별로 가격이 다름
• 생각보다 장애 많이 남 (99.95%)
• IO가 함정
• CPU Core가 2000년대 초 Xeon 수준 (요즘 CPU 수준이 아닌 가상화됨)
• 비쌈!!
• Infra Service, Fundamental Service
• IaaS : Amazon(갑), MS Azure, Google Compute engine, IBM Layer 7
• PaaS : Heroku, Google App Engine, Azure, MongoLab, Cloudant, MS Directory Service
• 저가 ? Digital Ocean
69. 클라우드 컴퓨팅
• 스타트업 중심의 아키텍쳐 변화 ”만들기 보다는 가져다 조합해 쓴다!!”
• 인원이 적으니 어쩔 수 없이 DEVOPS = 되도록이면 managed service
• Heroku, Google App engine 등의 PaaS 유행
• 전문 managed service를 이용한 짜 붙이기
• RedisLabs, Compose IO와 같은 미들웨어 서비스
• OneSignal, Zencoder와 같은 플랫폼 서비스
• 서버리스 컴퓨팅의 시작
• AI API 활용 (Azure ML, Cloud Vision)
• 데이타 분석 플랫폼의 서비스화 (Flurry, GA 등)