Cloud(1)-개요

1.Cloud

 

1)On-Premisee
=>기업이 자체 데이터 및 솔루션을 등을 저장하기 위해서 데이터 센터를 구축하고 IT 서비스를 수행하는 방식
=>하드웨어를 포함한 모든 자원(컴퓨터, 라이센스, 네트워크 등)에 대한 초기 투자 비용 과 탄력적이 않은 제한된 용량으로 인해 지속적 관리 비용이 증가한다는 단점이 있지만 기업에 내재화 된 서비스를 이용하기 때문에 품질 및 보안에 대한 신뢰도는 높음
=>설계를 할 때 가급적 최대 사용량을 근거로 하고 네트워크 트래픽 또한 최대 순간 트래픽을 가정하기 때문에 고사양의 설계를 하게되고 증설에 따른 시간적, 인적 비용도 무시할 수 없음
=>Cloud를 사용하는 경우 초기 도입 비용은 적을 수 있지만 오랜 시간 동안 사용한다면 Cloud 의 비용이 On-Premiss 보다 높을 수 있음
=>Cloud의 접근 방식은 사용한 만큼 지불하는 정산 방식을 통해 필요에 따라 민첩하고 탄력적으로 사용할 수 있기 때문에 Cloud Computing 및 서비스에 대한 정확한 관리 및 조정 능력이 필요하고 현 상황에 적합한 Cloud Setting 값을 찾는 것이 서비스의 안정화 와 비용 절약의 시작

2.Cloud Computing

=>컴퓨터와 소프트웨어를 자신이 소유하는 것이 아니라 네트워크 통해 클라우드 사업자의 컴퓨터와 소프트웨어를 서비스로서 사용할 수 있도록 하는 것
=>서비스 제공자의 최소한의 관리나 개입만으로도 신속하게 생성/제거/구성 할 수 있는 공유 공간의 컴퓨팅 자원들을 언제,어디서,어떤 단말일지와 상관없이 편리하게 네트워크에 접속할 수 있게 만든 몯레

1)Cloud가 등장하기 까지의 흐름
=>메인 프레임 시대: 대형 범용 컴퓨터를 가지고 모든 데이터와 애플리케이션을 저장한 후 단말기를 이용해서 입력을 하면 메인프레임을 처리하고 결과를 단말기를 이용해서 출력하는 방식
=>분산형 클라이언트 서버 모델:클라이언트 단말기에도 기능 부여
=>전 세계에 분산 배치된 서버 리소스를 필요한 만큼 사용하는 Cloud Computing 모델

 

2)보급된 배경

=>기술적 요소

-하드웨어의 급속한 발전

-빨라지고 저렴해진 네트워크

-거대해진 데이터 센터에 의한 규모의 경제(스케일 메리트)

 

=>인적 요소

 

3)정의

=>NIST(미국 국립 표준 기술 연구소)가 정의한 클라우드

공유 구성이 가능한 컴퓨팅 리소스의 통합을 통해 어디서나 간편하게 요청에 따라 네트워크를 통해 접근하는 것을 가능하게 하는 모델

 

4)특징

=>주문형 셀프 서비스:사업자 와 직접 상호 작용하지 않고 사용자의 개별 관리 화면을 통해 서비스를 이용할 수 있도록 합니다.

=>광범위한 네트워크 접속

=>리소스의 공유

=>신속한 확장성

=>측정 가능한 서비스:이용한만큼 요금이 부과

 

5)장점

=>경제성: 초기 투자 비용이 적게 듬 

=>자동화

=>이동성:웹을 지원할 수 있는 모든 장치에서 사용 가능

=>자원 공유

=>가용성

=>빠른 구축 속도

=>확장성(유연성, 탄력성):인디 스쿨이 대표적인 사례

=>Redundancy or Resilience:중복성 또는 탄력성

 

6)한계

=>네트워크 문제--> 인터넷 안되면 아예 안됨

=>보안 -->과연 믿을 수 있을까?

=>privacy

=>vender lock-in

 

3.Cloud Service 종류

1)IaaS(Infrastructure as a Service)

=> 서버, 스토리지, 네트워크 와 같은 인프라 하드웨어 자원을 가상화해서 사용자 요구에 따라 인프라 자원을 사용할 수 있게 하는 Cloud Service

=>물리적인 자원을 서비스

=>AWS 의 EC2 서비스가 대표적인 서비스

=>모든 CSP(Amazon,Google,MS)는 IaaS 를 제공

 

2)PaaS(Platform as a Service)

=>서비스 개발자가 애플리케이션 개발,실행,관리 등을 할 수 있도록 안정적인 플랫폼 또는 프레임워크를 제공하는 서비스

=>서버, 보안, 네트워크 부분을 Cloud 사업자에게 위임해 Paas 이고, 이 부분을 직접해야 하면 IaaS

=>세일즈 포스가 제공하는 Force.com이 대표적인 서비스

 

3)SaaS(Software as a Service)

=>업무에서 사용되는 소프트웨어 기능을 서비스로 제공하는 형태

=>전자 메일,그룹 웨어,CRM 등에 많이 이용

=>Google Apps,Salesforce, MS Office 365, Naver Office 등이 대표적인 서비스

 

4)DaaS(Desktop as a Service)

=>서비스로서의 데스크 탑

=>인터넷만 연결이 되면 언제, 어디서나 어떤 기기로도 기업 내부 망에 접속해서 사용할 수 있는 Cloud 서비스

=>모든 정보가 중앙서버에 저장됨

=>외부에서 기업의 업무망에 접근하는 가장 안전한 기술

=>이러한 가상화를 구현한 공간이 사용자가 보유한 인프라라면 VDI(Virtual Desktop Infrastructure)라고 하고 Public Cloud 공간이면 DaaS 라고 합니다

 

4.Cloud 종류

 

1)Public Cloud

=>Cloud Service Providers(AWS,GCP,Azure,Oracle등)가 시스템을 구축하고 인터넷 망 등의 네트워크를 통해서 서비스 하는 형태

=>이용자를 제한하지 않는 방식

=>사용자 간에 데이터 간섭이 없도록 관리(Multi Tenancy)

 

2)Private Cloud

=>폐쇄적인 구조로 이용자를 제한하는 방식

=>구현 방식

-자사가 보유하고 운용하는 형태:On Premiss Private Cloud

-Cloud 사업자가 보유하고 서비스 형태로 이용하는 형태:Hosted Private Cloud

 

3)Community Cloud

=>공통의 목적을 가진 특정 기업들이 Cloud 시스템을 형성해서 데이터 센터에서 공동으로 운영하는 형태

 

4)Hybrid Cloud

=>Public Cloud와 Private Cloud 를 네트워크를 통해 결합해서 두가지 서비스의 장점을 활용할 수 있도록 만든 Clou

=>기업 내부의 민감하고 중요한 데이터 처리작업은 통제력을 강화하기 위해서 Private Cloud로 만들고 일반 업무 데이터 처리 같은 보안 요구사항이 낮은 작업이나 워크로드가 지속해서 증가하는 작업은 리소스 자동 조정이 가능한 Public Cloud 사용

=>Data 와 Back End 은 Prviate Cloud에 Front End 는 Public Cloud 에 구축하는 경우도 있습니다.

 

5.Cloud를 지탱하는 2개 기술

1)가상화

=>컴퓨터가 어떤 작업을 하려면 물리적인 메모리와 하드 디스크, OS 등 다양한 부품이 필요한데 이를 소프트웨어로 대체하는 기술

=>가상 서버에 할당된 메모리와 스토리지는 소프트웨어적인 개념으로 자유롭게 늘리거나 줄일 수 있음

=>가상화는 소프트웨어 처럼 구축하기 때문에 복제가 쉽고 늘리거나 줄이는 것이 쉬움

 

2)분산 처리와 로드 밸런서

=>분산 처리란 기기 여러 대에 분산해서 처리하는 기술

=>크고 무거운 작업을 나누어서 처리하는 것도 가능하고 작업이 여러 개 발생했을 떄 각 작업을 나누어서 처리하는 것이 가능

=>분산 처리를 하게되면 나누어서 처리하는 것을 모아서 결과를 만들거나 작업을 분배해주는 소프트웨어가 필요

=>동일한 여러 개의 작업이 온 경우 여러 대의 컴퓨터로 나누는 역할을 수행하는 장비 또는 소프트웨어를 Load Balancer 라고 합니다.

 

3)이중화

=>복제의 개념과 로드 밸런서의 개념을 가지고 구현

 

6.Cloud Native

1)개요

=>조직이 퍼블릭, 프라이빗, 하이브리드  Cloud와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해주는 기술로 컨테이너(Docker, Kubernetes), 서비스 메쉬, 마이크로 서비스, 불변 인프라, 그리고 선언형 API등을 의미

=>느슨하게 결합된 시스템 - 한쪽의 변화가 다른 한쪽에 최소의 영향을 미치는 것

 

2)4가지 항목

=>Micro Service

 

=>DevOps

 

=>CI/CD

 

=>Container

 

3)IT 서비스 개발 및 구현 방식의 변화

=>개발 방식

-DevOps/DevSecOps:35.9%

-Agile/Scrum:31.78%- 작은 주기를 가지고 동작하는 소프트웨어를 만드는 것이 목적

프로젝트를 기능 별로 분리를 해서 짧은 주기를 가지고 동작하는 소프트웨어를 개발

 

-Kanban:13.02% -간판

-Waterfall:10.02% -전통적인 개발 방식                                   

전체 프로젝트를 위의 단계별로 나누어서 순서대로 진행

대규모 프로젝트에서는 아직도 이런 방식을 사용

전통적인 방식의 고객 니즈 변화에 취약

기능 별로 구현하면 고객의 needs가 변경되면 바로 반영

 

MicroSevice:짧은 주기를 가지고 자주 배포하고 느슨한 결합을 추가

 

-Water/Scrum/Fall:5.01%

-Lean:4.20%

 

=>구현 방식

 

 

4)Cloud Native 적용이 필요한 이유

=>서비스 배포 시간 단축: Containers 와  MicroService 적용을 통해 개발 팀과 운영 팀 사이의 의사 소통 향항

-상호 이해폭 확대

-DevOps(DevSecOps,MLOps등) 문화의 내재화 촉진

-조직 내 다양한 팀간의 마찰 감소

-CD 적용을 통한 빠른 배포 가능

-변경 프로세스의 복잡성 감소

-변경에 따른 인지된 위험 감소(b/c 느슨한 결합)

 

=>애플리케이션 및 서비스 현대화

-컨테이너를 사용해서 애플리케이션을 배포하기 때문에 인프라에 대한 종속성 감소

예전에는 운영체제에 직접 설치하는 형태를 취했기 때문에 운영체제에 종속 되었지만 지금은 컨테이너 기술만 이용

-Docker 와 Kubernetes 을 이용하면 모든 인프라에 컨테이너를 배포할 수 있는 단일 통합 플랫폼 제공받을 수 있음

 

=>신속한 신규 서비스 개발 사이클

-풍부한 기술 생태계

대규모 커뮤니티

Kubernetes 나 CNCF 슬랙에 35000명 이상의 개발자가 참여

-오픈 소스 기반

풍부한 개발 인력 Pool - 예전에는 특정 기술에 대한 수요가 많았는데 지금은 개발을 할 수 있는지 여부로 판단

 

=>사업 성장을 위한 조직 문화 혁신 촉진

 

5)CNCF Trail Map

=>오픈소스 진영에서 클라우드 네이티브에 관련된 프로젝트를 의미

Product ->Development -> Capacity Planning ->Testing + Release Procedures ->Postmortem/RoodCauseAnalysis           - >Incident Response ->Monitoring

 

=>클라우드 개발자 또는 Cloud Native 개발자가 되고자 하는 경우는 각각의 Map 에 해당하는 기술을 한 가지 이상 습득하거나 사용경험이 있어야 합니다.

============================================================================================

**Micro Service

1.비즈니스 민첩성

1)성공한 인터넷기업들과 비즈니스 민첩성

=>Amazon & Netflix 등 성공한 인터넷 기업들의 공통된 특징은 이미 익숙한 비즈니스에 새로운 비즈니스 개념과 기술을 융합해 자신만의 특화된 서비스를 제공한다는 것

=>자신만의 특화된 서비스를 제공하려는 시도를 누구보다 빨리 실행했고 사용자 피드백을 반영해 끊임 없이 서비스를 개선 - 비즈니스 민첩성(Agility)

 

2)아마존의 배포 속도

=>2011년에 아마존의 배포속도는 11.6초

=>2019년에 아마존의 배포속도는 초당 1.5회

=>배포주기가 비즈니스 민첩성을 간접적으로 보여주는 지표

 

3)Cloud 인프라의 등장

=>전형적인 시스템 인프라 구축 과정은 서버를 도입하고 네트워크를 구축한 뒤 각 서버마다 운영체제를 설치하고 서비스에 필요한 소프트웨어를 설치하는 형태로 진

 인프라 환경을 구축하는 과정 또는 작업이 간단한 작업이 아님

 

=>이전의 대기업들은 이러한 인프라 구축을 위한 조직을 별도로 두기도 합니다.

이러한 조직을 별도로 두는 경우 개발 조직 과의 의사 소통에 문제가 발생할 수 있음

개발 팀이 먼저 개발하고 다시 인프라를 구축하는 방식 =>서로 다른 영역임에도 불구하고 한꺼번에 진행할 수가 없음

 

=>이러한 문제가 Cloud 인프라의 등장으로 해결

서비스 개발에 필요한 시스템 인프라를 준비하는데 오랜 시간이 걸리지 않음

 

=>Scale Up 과 Scale Out 을 이용해서 성능 및 가용성을 높이는 것이 쉬움

마이크로 서비스 처럼 작은 단위로 느슨한 결합의 형태로 서비스를 만들면 특정 서비스만 탄력성 있게 확장이나 축소가 가능

하나의 애플리케이션에 회원가입과 로그인

하나의 애플리케이션은 회원가입과 로그인을 모두 처리

회원가입하는 트래픽이 증가하는 경우 회원가입서비스와 로그인 처리 모두 업데이트를 해야함

회원가입과 로그인을 별개의 애플리케이션으로 구현한 경우

게임 오픈 초반에는 회원 가입에만 많은 리소스를 투입하고 어느 정도 회원 가입이 이루어지면 다운 그레이드를 하고 로그인에 많은 리소스를 투입하는 형태로 변경

 

=>Cloud Friendly 와 Cloud Native

- 한 덩어리로 Cloud 환경에 올라갈 수 있게만 한 Application을 Cloud Friendly 라고 하고, 독립적으로 분리되어 배포될 수 있는 조작으로 구성된 애플리케이션을 Cloud Native 라고 합니다.

-궁극적으로는 현재 Cloud Friendly 로 구현된 애플리케이션을 Cloud Native 로 전이해야 한다고 함

2.Micro Service

1) Monolithic 과 Micro Service

 

=>Monolithic

-하나의 단위로 개발되는 일체식 애플리케이션

-보통 3-Tier 라 불리는 사용자 인터페이스와 데이터베이스 그리고 서버쪽 애플리케이션으로 구성

-서버 측 애플리케이션이 일체 즉 논리적인 단일체로서 아무리 작은 변화라도 발생하면 새로운 버전으로 전체를 빌드해서 배포해야 하고, 일체식 애플리케이션은 단일 프로세스에 실행되므로 확장이 필요한 경우 특정 기능만 확장할 수 없고 반드시 전체 애플리케이션을 동시에 확장을 해야 합니다.

-이 경우 확장하고자 할 때 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해서 수평 확장

이렇게 복제된 시스템에서는 변경이 발생하면 여러 개의 모놀리식 프로젝트가 전부 다시 빌드해서 배포해야 합니다.

이 구조에서는 데이터베이스를 공유

 

=>Micro Service 

- 서버 측을 여러개의 조각으로 구성해서 별개의 인스턴스로 배포

- 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하고 각 서비스의 소유권을 분리해서 서로 다른 팀이 개발 및 운영하는 것도 가능

파이썬으로 어떻게 데이터를 요청하고 사용할 수 있는지를 공부해야함

 

2)SOA & Micro Service

=>소프트웨어 공학에서의 모듈화(Modularity)발전

-기능을 하향식 분해하는 구조적 방법론

-객체 지향

-모듈화가 기능 별로 재사용 할 수 있는 컴포넌트로 변경:CBD(Component Based Development)

-컴포넌트들을 모아서 비즈니스적으로 의미있고 완결적인 서비스 단위로 모듈화하는 SOA(Service Oriented Architecture)

 

=>CBD 나 SOA 의 개념은 작은 단위로 분할 한 후 이를 재조립해서 시스템을 만드는 개념이라서 MicroService 와 유사한 개념

=>Micro Service 기반으로 시스템을 개발하는 아키텍쳐 또는 개발 방식을 MSA(Micro Service Architecture)라고 합니다.

=>SOA의 개념에 Cloud 인프라 기술을 접목한 Micro Service 가 아마존이나 넷플릭스에서 성공

 

=>Amazon과 Netflix 가 성공한 사례의 특징

- 여러개의 작은 서비스의 집합으로 개발하는 접근 방법

- 각 서비스는 개별 프로세스(실행중인 프로그램 또는 애플리케이션)에서 실행되고 HTTP 자원 API 같은 가벼운 수단을 사용해서 통신

- 서비스는 비즈니스 기능 단위로 구성되고 자동화된 배포 방식을 이용해서 독립적으로 배포

- 서비스에 대한 중앙 집중적인 관리는 최소화하고 각 서비스는 서로 다른 언어와 데이터 저장 기술을 사용할 수 있음

 

=>특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 Polyglot  하다라고 표현

- 클라우드 등의 가상 인프라가 지닌 유연성이 이를 가능하게 함

-CBD/SOA 에서는 애플리케이션은 모듈별로 분리 했지만 , 데이터 저장소 까지 분리하지는 못함

 

3)Micro Service를 구현하기 위한 조건

=>업무 기능 중심 팀

-콘웨이 법칙: 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영하도록 하는 것

-예전에 일하는 방식은 하나의 애플리케이션을 만들 떄 UI 팀, 서버 개발 팀, DB 팀과 같은 기술별로 팀을 나누고 하나의 애플리케이션을 개발할 때 팀 간의 의사소통이 필요하기 때문에 시스템도 이러한 의사 소통 구조를 그대로 반영했는데 이렇게 하면 팀간의 의사소통이 느리고 어려움

-다양한 역할(기획자, 디자이너,UI 개발자, 서버 개발자, 설계자 등)으로 구성되고 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖추고 있는 구조

아마존에서는 이 팀을 two pizza team이라고 합니다

 

=>관리 체계의 변화- 자율적인 분권 거버넌스, 폴리글랏

- 팀은 빠르게 서비스를 만드는 것을 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아서 적용

-자기 서비스에 맞는 기술을 이용하도록 하는 것

 

=>개발 수명 주기의 변화 - 프로젝트가 아니라 제품 중심

-초기에 모든 일정을 계획하고 요구 사항 정의를 통해 개발할 기능을 나열하고 이에 대한 설계를 진행한 후 설계가 완료되어야 개발이 진행되고 각 단계는 완료 데드라인이 있어서 그 일정을 완료함으로써 최종 기능을 제공하기 때문에 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못함

 

완료된 후 기능 개선을 할 때 최악의 경우는 프로젝트를 다시 진행해야 하는 경우도 발생

- 점진 반복적인 모델 제품 중심의 Agile 개발 방식을 채용

2~3주 정도의 Sprint를 통해서 소프트웨어를 개발 및 배포해서 바로 피드백을 받아 소프트웨어에 반영

 

=>인프라 자동화

-Micro Service 는 독립적으로 배포하기 때문에 여러 개를 배포할 가능성이 높으므로 이를 수동으로 배포하는 것은 바람직 하지 않습니다.

-개발을 하고 이를 배포하는 과정을 전부 자동화해서 사용

개발 과정과 배포과정을 자동화하는 것이 DevOps 의 궁극적인 목적

 

=>저장소 변화:통합 저장소가 아닌 분권 데이터 관리

-이전에는 단일 데이터베이스를 유지하는 방식으로 데이터를 관리했는데 이렇게 하면 데이터를 잘 정리하는 정규화가 반드시 추구해야 할 가치였지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커져서 굳이 데이터를 뭉쳐 작은 공간에 넣을 필요가 없음

-각 서비스는 저장소를 공유하지않고 API를 통해서만 데이터를 주고 받습니다.

이 방식에서 발생 할 수 있는 문제는 데이터의 비즈니스 정합성을 맞춰줘야 하는 데이터 일관성문제가 발생

이를 해결하는 방식은 2단계 커밋을 이용하는 방법과 비동기 이벤트 처리하는 방식이 있습니다.

비동기 이벤트 처리를 권장

NoSQL은 일반적으로 2단계 커밋을 허용하지 않음

 -2단계 커미슨 여러 애플리케이션의 서비스를 묶어서 하나의 트랜잭션을 만드는 방식

-비동기 이벤트를 처리하는 방식은 Kafka 나 RabbitMQ 같은 메세지 큐를 이용해서 트랜잭션을 처리하는 방식

 

=>실패를 고려한 설계

- 클라이언트 서버 프로그래밍을 할 때 완벽하게 동작하면 좋지만 반드시 동작한다는 보장은 할 수 없습니다.

서버가 중지되었을 때 클라이언트에서 어떻게 이를 정상적으로 처리할 것인가 하는 문제?

실제 서비스를 만들떄는 에ㅚ처리를 하는 것이 좋음. 우리끼리는 간결하게 하려고 한것이지만, 실제 서비스에서는 반드시 될 경우가 없음.

예외처리를 안하면 경험이 없다고 판단. 그냥 책보고 따라한 애라호 판단. Test 할 때 올바르게 했다고 생각하지 않음

 

4)리액티브 선언

=>리액티브 선언의 4가지 요소

-응답성(responsive):사용자에게 신뢰성있는 응답을 빠르고 적절하게 제공하는 것

-탄력성(resilient): 장애가 발생하거나 부분적으로 고장나더라도 시스템 전체가 고장나지 않고 빠르게 복구하는 능력

-유연성(Elastic):시스템 사용량에 변화가 있더라도 균일한 응답성을 제공하는 것을 의미하며 시스템 사용량에 비례해서 자원을 늘리거나 줄이는 능력

-메시지 기반(Message Driven):비동기 메세지 전달읕 통해서 위치 투명성(위치를 알 필요가 없다-여러 개의 마이크로서비스가 하나의 시스템을 만들어서 서비스를 제공하는 경우 각 마이크로서비스의 위치나 구현되는 방법에 대해서 사용자는 알 필요가 없다), 느슨한 결합(하나의 변화가 다른 서비스에 영향을 최소화), 논블로킹 통신(통신을 수행할 때 하나의 요청에 대한 응답을 기다리지 않고 다음 요청을 전송할 수 있는 방식)을 지향

 

5)강결합에서 느슨한 결합의 아키텍쳐로의 변화

=>예전에는 아키텍쳐의 구성요소들을 각 기업이나 특정 벤더의 제품에 전적으로 의존해서 구축하거나 수정이 필요한 부분만 별도로 직접 개발하는 경우가 많았기 때문에 특정 벤더 솔루션이나 프레임워크가 변경될 경우 그것에 의존하는 애플리케이션의 많은 부분들을 변경해야 하는 강결합의 형태를 가졌고 특정 벤더에 의존하다보니 특정 기술에 lock-in 되어 쉽게 변경하거나 확장하지 못한다는 단점이 있음

 

=>Cloud 환경 하에서 사용되는 오픈 소스 또는 오픈 소스를 기반으로 한 사용 제품들이 이전의 유명 벤더 제품군 만큼 품질이 높아지고 다양한 기능을 지원하면서 서로 다른 오픈소스 제품 간에도 충분한 호환성을 제공

 

=>레이어 별로 별도의 오픈 소스 애플리케이션을 이용해서 개발하는 것을 권장

 

3.MSA 구성 요소 및 MSA 패턴

1)구성 요소 및 패턴의 유형

=>인프라 구성 요소

=>플랫폼 패턴

=>애플리케이션 패턴

 

2)인프라 구성요소

=>가상화되서 제공

=>Publoc Cloud 나 베어 메탈, private cloud, Virtual Machine, Container(Docker) ,컨테이너 오케스트레이션(Kubenetes)

 

3)플랫폼 패턴

=>데브옵스 인프라 구성

-개발과 운영이 분리되지 않은 개발 및 운영을 병행할 수 있는 ㅈ직 또는 문화

=>CI/CD:지속적인 인도와 배포를 위한 파이프라인 설계

=> 넷플릭스에서는 플랫폼 패턴으로 Spring Boot + 넷플릭스 OSS 조합을 이용

=>BFF 패턴

애플리케이션 종류 별로 진입점을 만들고 API 게이트 웨이를 이용해서 서비스를 이용하는 방식

다양한 모바일 장비를 사용하기 떄문에 다양한 클라이언트를 고려해야 한다.

Backend For Frontend 를 줄여서 VFF 라고 함

 

=>외부 구성 저장소 패턴

외부 저장소와 관련된 정보를 소스 코드에 포함시키면 외부 저장소를 수정하게 되면 소스 코드를 다시 빌드해야 하므로 저장소와 관련된 접오는 소스코드에 하드 코딩하지 말고 외부 환경 설정정보를 활용하도록 하는 것

대부분의 프레임워크는 설정 정보를 저장할 수 있는 별도의 텍스트 파일이나 프로터티 파일을 사용할 수 있도록 하고 형상 관리를 위한 서비스에서도 이를 암호화 할 수 있는 기능을 제공

 

=>인증/인가 패턴

-로그인을 어떻게 구현할 것인가 하는 문제

-예전에는 중앙 집중식 세션 관리를 이용했는데 최근에 클라이언트 토큰 방식(JWT)을 이용