클라우드 데이터 센터

part1. 클라우드

데이터센터를 많이 갖고 있는 회사? 텔레콤회사(sk,kt,lg) + 삼성sds 등 it자회사

데이터센터는 다양한 네트워크 형식의 컴퓨팅 및 스토리지 인프라를 수용하는데 사용하는 물리적 인프라를 말한다.

대부분의 데이터센터가 수도권에 집중되어 있음 → 대부분의 회사가 수도권에 집중되어 있기 때문에

요즘 강원지역에 데이터센터를 많이 짓고 있음

• 지역적으로 시원함
• 토지 가격 저렴

데이터센터 등급 분류

• 1~4티어 등급이 높을수록 데이터센터의 신뢰도가 높음 → 연간 다운타임에 따라 구분
• Five Nine 99.999% == 다운타임이 5.256분 ⇒ 적어도 Four Nine 정도 되면 서비스가 안정적

LG U+ 평촌 메가센터의 경우

• 공냉방식 - 하절기에만 냉방기 가동 그 외 외기 냉방
• 한전변전소와 비슷하게 들어온다. ⇒ 한전과 가까움
• 모든 전원이 이중화 장비도 이중화
• 집적도가 높으면 서버를 많이 넣을 수 있다.
• 물리적 보완성 ⇒ 동을 2개로 나눔
• 고객사의 장비를 넣고 데이터센터로서 역할하기 위함 aka. Colocation(공간을 빌려줘서 서비스할 수 있도록 함)

part2. 클라우드 데이터 센터

aws > Azure > Google Cloud > Alibaba Cloud > IBM Cloud > salesforce > Tencent Cloud > Oracle

구글 클라우드 vs 구글 데이터센터 → 서로 다른 법인

• 구글 클라우드는 코로케이션을 제공하는 곳에 데이터센터가 존재함 ↔

Region vs AZ (가용영역 Availability Zone)

part3. Region and Availability Zone

AWS리전은 더 높은 가용성, 확장성, 내결함성을 위해 다중의 가용영역으로 구성

• 리전은 aws가 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치임. 서울의 경우 4개

가용영역(AZ)을 4개 이상 구성하도록 함 → 침수될 수 있기 때문에

EC2 - 외부 스토리지를 가져와 사용

아마존 EC2 인스턴스 표기법 M5d.xlarge

• M 인스턴스 패밀리
• 5 인스턴스 세대
• d 추가기능
• xlarge 인스턴스 크기

vpc로 네트워크를 연결

인스턴트 크기

• 8코어짜리 를 2, 4, 8 개로 나누어 판매 및 운영 → 가격은 서로 비슷함
• 좀 더 작은 코어로 구성하면 비용을 줄일 수 있다. 다만, 오토 스케일링을 잘 해놔야 함

서울 리전 최소 4개의 AZ가 있다. 하나의 가용영역이 사용 불가하게 됐을 때 대비하기 위함

리전은 전 세계에서 데이터 센터를 클러스터링하는 물리적 위치이다.

리전의 중복 전력, 네트워킹 및 연결이 제공되는 하나 이상의 개별 데이터 센터로 구성된다.

part4. 마이크로 서비스

On-Prem온프레미스 - 자사의 것들을(어플리케이션과 데이터) 클라우드로 올려보내고 있음

워크로드=데이터센터

pay as you go 사용한 만큼 지불하라

5년 감가상한 ⇒ 5년 동안 사용할 서버를 사놓음 But 클라우드는 필요한 만큼 사용 및 사용한 만큼 비용 지불

클라우드Cloud vs 온프렘On-Prem ⇒ 신규, 도전적인 서비스의 경우 클라우드 사용, 서비스 안정화되면 온프렘 사용

CNCF 란? 클라우드향으로 만드는 거에 대한 기준점을 제시하는 단체

1. Containerized
2. Dynamically orchestrated
3. Microservices oriented

CNCF Cloud Landscape → 서로

마이크로 서비스란?

예로 자바에서는 하나의 패키지에 모든 기능이 포함되어 있다면 마이크로 서비스란 기능들을 분리시켜 별개의 컨테이너로 만듬 → 장애가 일어나더라도 부분적으로만 이슈가 있음

• 안정성이 높다↑
• T2M(Time To Market) ⇒ 변경사항이 많은 ex.넷플릭스 같은 앱 경우
• 복잡도가 증가한다↑
• 구현하기 어려움
• 하나의 서비스 장애가 연쇄적으로 다른 시스템 장애로 전파
  ⇒ 서비스에 문자게 발생하면 스위치를 내렸다가 일정 시간이 지난 후 테스트 리퀘스트를 날려서 통과하면 그때 서비스를 재개(ex. 넷플릭스)

컨테이너Container & 쿠바네티스Kubernetes(K8S)

Hardware Operating System App App

Hardware Operating System Hypervisor(=virture box와 비슷) VM1-OS-Bin/Lib-App , VM2-OS-Bin/Lib-App

격리제공

게스트OS 단점

1. os 뜨는 시간이 오래 걸림
2. 리소스 오버헤드
3. 부트업 타임 증가

→ 이를 해결하기 위한 Container

Hardware Operating System Container1-Bin/Lib-App, Container2-Bin/Lib-App

• 리소스 오버헤드X
• 부트업 타입 감소↓

대표적인 컨테이너 런타임 ⇒ 도커 Docker

💡 **Serverless** 개발자가 서버를 관리할 필요 없이 애플리케이션을 빌드하고 실행할 수 있도록 하는 클라우드 네이티브 개발 모델

식당에 가면 종업원을 부르기 위한 벨이 있고, 종업원은 벨을 누른 테이블에 서비스를 제공한다.
종업원은 항상 우리 테이블만 쳐다보며 기다리지 않는다. 서버리스는 벨을 눌러 종업원을 부르는 시스템에 가깝다. 이는 서버리스의 기본적인 개념의 이해를 돕기 위한 비유로 사용자가 가상 머신이나 서버를 소유하고 있는 것이 아니라, 필요에 따라 서비스를 프로비저닝한다는 것을 의미한다.

쿠버네티스Kubernetes란?

• master node - worker nodes 로 구성
• 명령에 따라 여러 컴포넌트들을 알아서 관리하는 것 ex. 5개의 컴포넌트를 실행해야하는데 만약 여기서 2개의 컴포넌트가 죽는다면 쿠버네티스가 이를 확인하고 다시 실행시킨다.
  

---

애자일 방법론(Agail Software Development)

애자일이란?

소프트웨어 개발 방법론 - 우리 이렇게 개발을 해보자! 와 같은 철학에 가까움

기존 방법-폭포수 방법론 ⇒ 이전 단계가 끝날 때까지 다음 단계를 실행하지 않고 대기함

• 장점
  • 단순한 선형 모델
  • 단계별 정형화된 접근
  • 명확한 진행사항 파악
• 단점
  • 각단계 병행 불가능
  • 중요결함에 대한 대응 어려움
  • 유연성이 떨어짐

애자일 선언문

• 공정과 도구보다 개인과 상호작용을
• 포괄적인 문서보다 작동하는 소프트웨어를
• 계약 협상보다 고객과의 협력을
• 계획을 따르기보다 변화에 대응하기를

💡 애자일 방법은 하나가 아니다. 그 외 다른 방법론도 마찬가지.

피드백을 받아 유동적으로 개발하는 방법들이 왜 필요하게 됐을까?

• 즉각적으로 유저의 피드백을 받을 수 있는 환경이 조성됨
• 개발도구들의 다양화 → 빠른 개발 가능 ⇒ 대표적인 기업이 토스Toss
  

애자일 방법론 종류

1. 스크럼(Scrum)

스크럼 프레임워크 Scrum Framework

• 민첩하게 개발하기 위한 방법론 중 하나의 프레임워크
• Product Backlog → Sprint Planning → Sprint Backlog → Daily Scrum → Increment → sprint Reviwe
  • Sprint Planning을 보면 스프린트가 얼마나 잘 되었는지 판단가능
  • 백로그를 쌓아두고 차근차근 개발
• 프로젝트가 6개월-1년 정도의 큰 사이즈일 때 스크럼을 도입하면 좋음
• 스크럼의 특성
  • 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
  • 날마다 15분 정도 회의를 가져라. 항상 팀 단위로 생각하라.
  • 원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.

2. 기능주도 방법론

백로그에 대해 모델링을 하고 설계와 개발을 함께 진행

몇 가지 큰 기능 또는 작은 기능을 개발하게 된다면 기능주도 방법론이 좋음

3. XP(eXtreme Programming)

혼자개발하는 것보다 둘이 개발하는게 낫다 ⇒ 둘이 같이 개발하면 코드 퀄리티가 무너지지 않을 가능성이 있다.

테스트 종류
1. Unit test - 각각의 메소드가 정상적으로 동작하는지 확인
2. Acceptance test - 각각의 메소드가 서로 연결되어 동작되는지 확인
3. Integration test - 통합테스트

• 내 서비스 내에서 정상적으로 동작하는지?
• 다른 서비스와 유기적으로 동작하는지?

피쳐 테스트,컴포넌트 테스트(개발팀 내에서) → 인테그레이션 테스트(QA팀에서)

현업에서는?

• 현업에서는 스크럼을 많이 사용함
• 작은 기능은 tf를 따로 빼서 기능주도로 진행
• Product Owner(PO)때문에 Product Backlog의 변경이 잦음

PO가 여러 요구사항의 우선순위 설정 → Product Backlog 작성 → Sprint Planning Meeting 어떻게 Sprint할 건지?

1️⃣ 스프린트가 끝났다고 개발이 끝난게 아니다.
2️⃣ 개발하는데 오래 걸리는 기능은 스프린트를 여러 차수로 나눠도 된다.
3️⃣ 스프린트 기간은 약간의 변동성을 가질 수 있다.

Product Backlog 요구사항 목록(추상적) ⇒ Sprint Backlog 실질적으로 해야하는 일 목록

Scrum Team 구성

스크럼 마스터(Scrum Master)의 역할

• 팀을 보호하고 장애요소 해결
• 일일 스크럼 회의 진행
• 모니터링 및 트래킹

스탠드업 미팅 = 데일리 스크럼 미팅

• 인원은 피자 두 판의 법칙에 따른다. “모든 팀은 피자 두 판을 먹는데 알맞은 인원으로 이루어져야 한다.”

스프린트 일정은 어떻게 잡는가? 보통 2주 동안 개발→배포 3-4일 ⇒ 총 3주

💡 스프린트 일정은 보수적으로 잡는다.

데브옵스(DevOps)

• 개발와 오퍼레이트의 합성어
• 요구사항과 인프라 환경을 어떻게 개선할건지 끊임없이 고민해야한다.

스프린트가 끝나면? 스프린트 리뷰와 스프린트 회고가 남아있다.

스프린트 리뷰와 스프린트 회고의 차이는?

리뷰는 개선사항이나 요구사항이 나온 경우 → Product Backlog를 다시 쌓아 우선순위 재설정

회고는 행동, 문화적인 부분을 개선하는 경우 - 잘하고 있는 부분과 못하고 있는 부분에 대해서 짚는다. → 앞으로 우린 무엇을 해야할까? 에 대해 반드시 작성한다.

회고하는 방법

1. Flat
2. Pleasure and Gain
3. Well, Not so Well, New idea
4. Hot-air Balloon
5. Speed Car
6. Open the box
7. Small starfish
8. 4L(Liked, Learned, Lacked, Long For)

💡 Tools

• Metro Retro(회고용 외의 용도로도 사용 가능/유료 플랜)
• GitHub(Projects, Org)
• Jira
• Trello(코드 없이 문서(설계 등)를 만들 때 활용하기 좋음)

스프린트, 백로그를 쌓는다→ 스프린트 끝나면 스프린트 회고랑 리뷰 → 매일매일 데일리 스크럼 미팅을 한다.