Translated 2022 day84-90 to korean
This commit is contained in:
Me1e
parent
f3da0c898b
commit
3bc75d8481
73
2022/ko/Days/day84.md
Normal file
73
2022/ko/Days/day84.md
Normal file
@ -0,0 +1,73 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - The Big Picture: Data Management - Day 84'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - The Big Picture Data Management
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048747
|
||||
---
|
||||
|
||||
## 큰 그림: 데이터 관리
|
||||
|
||||
|
||||
|
||||
데이터가 몇 년 전보다 더 중요해졌다는 것은 알고 있지만, 데이터 관리는 결코 넘어야 할 새로운 벽이 아닙니다. 가치 있고 끊임없이 변화하는 데이터는 자동화와 빈번한 소프트웨어 릴리스의 지속적인 통합, 테스트 및 배포에 대해 이야기할 때 엄청난 악몽이 될 수도 있습니다. 영구 데이터와 기본 데이터 서비스는 종종 문제가 발생할 때 주범이 되기도 합니다.
|
||||
|
||||
하지만 클라우드 네이티브 데이터 관리에 들어가기 전에 한 단계 더 올라가야 합니다. 이번 챌린지를 통해 다양한 플랫폼을 다루었습니다. 물리, 가상, 클라우드 또는 클라우드 네이티브(Kubernetes 포함) 등 어떤 플랫폼이든 데이터 관리에 대한 요구 사항을 충족하지 않는 플랫폼은 없습니다.
|
||||
|
||||
비즈니스에서 가장 미션 크리티컬한 시스템을 위한 것이든, 아니면 적어도 일부 톱니바퀴가 시스템의 일부 수준에 영구 데이터를 저장하고 있든, 환경 어딘가에 숨어 있는 데이터베이스를 찾을 가능성이 높습니다.
|
||||
|
||||
### 데브옵스와 데이터
|
||||
|
||||
데브옵스 원칙에 대해 이야기했던 이 시리즈의 맨 처음과 마찬가지로, 데이터와 관련하여 더 나은 프로세스를 위해서는 적절한 인력을 포함시켜야 합니다. 여기에는 DBA가 포함될 수도 있지만, 마찬가지로 데이터 서비스의 백업에 관심이 있는 사람들도 포함될 것입니다.
|
||||
|
||||
둘째, 데이터와 관련된 다양한 데이터 유형, 도메인 및 경계를 식별해야 합니다. 이렇게 하면 데이터베이스 관리자, 스토리지 엔지니어 또는 백업에 집중하는 엔지니어 사이에서만 사일로 방식으로 처리되는 것이 아닙니다. 이렇게 하면 전체 팀이 더 넓은 비즈니스를 위한 애플리케이션을 개발하고 호스팅하는 데 있어 최선의 조치 경로를 결정하고 데이터 아키텍처에 집중할지, 아니면 나중에 고려할지 결정할 수 있습니다.
|
||||
|
||||
이제 데이터 라이프사이클의 다양한 영역에 걸쳐 데이터 수집에 대해 이야기할 수 있습니다. 서비스나 애플리케이션에 데이터를 어디서 어떻게 수집할 것인가? 서비스, 애플리케이션 또는 사용자는 이 데이터에 어떻게 액세스할까요? 또한 데이터를 어떻게 보호할 것인지, 그리고 그 데이터를 어떻게 보호할 것인지에 대해서도 이해해야 합니다.
|
||||
|
||||
### 데이터 관리 101
|
||||
|
||||
[데이터 관리 지식 체계](https://www.dama.org/cpages/body-of-knowledge)에 따르면 데이터 관리는 "데이터 및 정보 자산의 가치를 제어, 보호, 제공 및 향상시키는 계획, 정책, 프로그램 및 관행을 개발, 실행 및 감독하는 것"입니다.
|
||||
|
||||
- 데이터는 비즈니스의 가장 중요한 측면입니다 - 데이터는 전체 비즈니스의 한 부분일 뿐입니다. "데이터는 비즈니스의 생명선"이라는 표현을 본 적이 있는데, 대부분 사실일 것입니다. 혈액이 신체에 매우 중요하지만, 혈액만으로는 혈액을 액체로 만드는 데 필요한 신체적 측면이 부족하다는 생각이 들었습니다.
|
||||
|
||||
- 데이터 품질은 그 어느 때보다 중요합니다. 데이터를 비즈니스 자산으로 취급해야 하며, 이는 자동화 및 DevOps 원칙에 따라 데이터에 필요한 고려 사항을 제공해야 한다는 것을 의미합니다.
|
||||
|
||||
- 적시에 데이터에 액세스해야 합니다. - 효과적인 의사 결정을 내리기 위해 적시에 적절한 데이터에 액세스하지 못하는 것을 참을 수 있는 사람은 아무도 없습니다. 데이터는 프레젠테이션에 관계없이 간소화된 방식으로 적시에 사용할 수 있어야 합니다.
|
||||
|
||||
- 데이터 관리는 DevOps의 조력자가 되어야 합니다 - 앞서 간소화에 대해 언급했지만, 데이터 관리 요구 사항을 주기에 포함시켜 데이터의 가용성뿐만 아니라 데이터 포인트에 대한 다른 중요한 정책 기반 보호와 함께 완전히 테스트된 복구 모델도 포함시켜야 합니다.
|
||||
|
||||
### 데이터옵스
|
||||
|
||||
데이터옵스와 데브옵스 모두 기술 개발 및 운영의 모범 사례를 적용하여 품질을 개선하고, 속도를 높이고, 보안 위협을 줄이고, 고객을 만족시키고, 숙련된 전문가에게 의미 있고 도전적인 업무를 제공합니다. DevOps와 DataOps는 가능한 한 많은 프로세스 단계를 자동화하여 제품 제공을 가속화한다는 목표를 공유합니다. 데이터옵스의 목표는 탄력적인 데이터 파이프라인과 데이터 분석을 통한 신뢰할 수 있는 인사이트입니다.
|
||||
|
||||
데이터옵스에 중점을 두는 가장 일반적인 상위 영역은 머신 러닝, 빅 데이터, 인공 지능을 포함한 데이터 분석이 될 것입니다.
|
||||
|
||||
### 데이터 관리는 정보 관리입니다.
|
||||
|
||||
이 섹션에서는 머신 러닝이나 인공 지능을 다루지 않고 데이터 보호 관점에서 데이터를 보호하는 데 초점을 맞출 것이며, 이 하위 섹션의 제목은 "데이터 관리는 정보의 관리"이며 정보 = 데이터라고 연관 지을 수 있습니다.
|
||||
|
||||
데이터와 관련된 여정에서 고려해야 할 세 가지 핵심 영역은 다음과 같습니다:
|
||||
|
||||
- 정확성 - 프로덕션 데이터가 정확한지 확인하는 것과 마찬가지로 백업 형태의 데이터도 작동하는지 확인하고 복구에 대해 테스트하여 장애나 사유가 발생할 경우 가능한 한 빨리 다시 가동할 수 있도록 해야 합니다.
|
||||
|
||||
- 일관성 - 데이터 서비스가 여러 위치에 걸쳐 있는 경우 프로덕션의 경우 모든 데이터 위치에서 일관성을 유지하여 정확한 데이터를 얻을 수 있도록 해야 하며, 이는 이러한 데이터 서비스를 보호하는 데 있어서도 마찬가지입니다. 특히 데이터 서비스는 백업, 복제본 등을 위해 해당 데이터의 깨끗한 사본을 생성할 수 있도록 다양한 수준에서 일관성을 보장해야 합니다.
|
||||
|
||||
- 보안 - 액세스 제어와 마찬가지로 일반적으로 데이터를 보관하는 것은 현재 전 세계적으로 화두가 되고 있는 주제입니다. 적절한 사람만 데이터에 액세스할 수 있도록 하는 것이 가장 중요하며, 이는 다시 데이터 보호로 이어져 필요한 사람만 백업에 액세스하고 백업에서 복원할 수 있으며 다른 버전의 비즈니스 데이터를 복제하여 제공할 수 있도록 해야 합니다.
|
||||
|
||||
더 나은 데이터 = 더 나은 의사 결정
|
||||
|
||||
### 데이터 관리의 Days
|
||||
|
||||
앞으로 6회에 걸쳐 데이터베이스, 백업 및 복구, 재해 복구, 애플리케이션 모빌리티에 대해 자세히 살펴보면서 데모와 실습을 병행할 예정입니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
[Day 85](day85.md)에서 봐요!
|
||||
152
2022/ko/Days/day85.md
Normal file
152
2022/ko/Days/day85.md
Normal file
@ -0,0 +1,152 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Data Services - Day 85'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Data Services
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048781
|
||||
---
|
||||
|
||||
## 데이터 서비스
|
||||
|
||||
데이터베이스는 우리 환경에서 가장 흔히 접하는 데이터 서비스가 될 것입니다. 이번 세션에서는 다양한 유형의 데이터베이스와 각 데이터베이스의 사용 사례에 대해 살펴보고자 합니다. 이번 챌린지를 통해 우리가 사용하고 본 몇 가지 사례를 살펴보겠습니다.
|
||||
|
||||
애플리케이션 개발 관점에서 올바른 데이터 서비스 또는 데이터베이스를 선택하는 것은 애플리케이션의 성능과 확장성 측면에서 매우 중요한 결정이 될 것입니다.
|
||||
|
||||
https://www.youtube.com/watch?v=W2Z7fbCLSTw
|
||||
|
||||
### Key-value
|
||||
|
||||
Key-value 데이터베이스는 간단한 Key-value 방식을 사용하여 데이터를 저장하는 비관계형 데이터베이스의 한 유형입니다. Key-value 데이터베이스는 키가 고유 식별자 역할을 하는 Key-value 쌍의 모음으로 데이터를 저장합니다. 키와 값은 단순한 객체부터 복잡한 복합 객체에 이르기까지 무엇이든 될 수 있습니다. Key-value 데이터베이스는 고도로 파티셔닝이 가능하며 다른 유형의 데이터베이스에서는 달성할 수 없는 규모로 수평 확장이 가능합니다.
|
||||
|
||||
Key-value 데이터베이스의 예로는 Redis가 있습니다.
|
||||
|
||||
_Redis는 인메모리 데이터 구조 저장소로, 분산형 인메모리 Key-value 데이터베이스, 캐시 및 메시지 브로커로 사용되며 내구성을 옵션으로 선택할 수 있습니다. Redis는 문자열, 목록, 맵, 집합, 정렬된 집합, HyperLogLogs, 비트맵, 스트림, 공간 인덱스 등 다양한 종류의 추상 데이터 구조를 지원합니다._
|
||||
|
||||
|
||||
|
||||
Redis에 대한 설명에서 알 수 있듯이 이것은 데이터베이스가 빠르다는 것을 의미하지만, 그 대가로 공간에 제한이 있다는 것을 의미합니다. 또한 쿼리나 조인이 없으므로 데이터 모델링 옵션이 매우 제한적입니다.
|
||||
|
||||
Best for:
|
||||
|
||||
- 캐싱
|
||||
- Pub/Sub
|
||||
- 리더보드
|
||||
- 쇼핑 카트
|
||||
|
||||
일반적으로 다른 영구 데이터 레이어 위에 캐시로 사용됩니다.
|
||||
|
||||
### Wide-column
|
||||
|
||||
Wide-column 데이터베이스는 데이터 저장소를 여러 서버 또는 데이터베이스 노드에 분산할 수 있는 유연한 컬럼으로 구성하고, 다차원 매핑을 사용하여 컬럼, 행, 타임스탬프로 데이터를 참조하는 NoSQL 데이터베이스입니다.
|
||||
|
||||
_Cassandra는 무료 오픈소스, 분산형, 광역 열 저장소, NoSQL 데이터베이스 관리 시스템으로, 여러 상품 서버에서 대량의 데이터를 처리하도록 설계되어 단일 장애 지점 없이 고가용성을 제공합니다._
|
||||
|
||||
|
||||
|
||||
스키마가 없어 비정형 데이터를 처리할 수 없지만 일부 워크로드에는 이점으로 작용할 수 있습니다.
|
||||
|
||||
Best for:
|
||||
|
||||
- 시계열
|
||||
- 과거 기록
|
||||
- 많은 쓰기, 적은 읽기
|
||||
|
||||
### 문서
|
||||
|
||||
문서 데이터베이스(문서 지향 데이터베이스 또는 문서 저장소라고도 함)는 문서에 정보를 저장하는 데이터베이스입니다.
|
||||
|
||||
_MongoDB는 소스 사용이 가능한 크로스 플랫폼 문서 지향 데이터베이스 프로그램입니다. NoSQL 데이터베이스 프로그램으로 분류되는 MongoDB는 선택적 스키마와 함께 JSON과 유사한 문서를 사용합니다. MongoDB는 MongoDB Inc.에서 개발했으며 서버 사이드 퍼블릭 라이선스에 따라 라이선스가 부여됩니다._
|
||||
|
||||
|
||||
|
||||
NoSQL 문서 데이터베이스를 사용하면 복잡한 SQL 코드를 사용하지 않고도 간단한 데이터를 저장할 수 있습니다. 안정성 저하 없이 빠르게 저장할 수 있습니다.
|
||||
|
||||
Best for:
|
||||
|
||||
- 대부분의 애플리케이션
|
||||
- 게임
|
||||
- 사물 인터넷
|
||||
|
||||
### 관계형
|
||||
|
||||
데이터베이스를 처음 사용하시지만 데이터베이스에 대해 알고 계신다면 관계형 데이터베이스를 접해 보셨을 것입니다.
|
||||
|
||||
관계형 데이터베이스는 1970년 E. F. Codd가 제안한 데이터의 관계형 모델에 기반한 디지털 데이터베이스입니다. 관계형 데이터베이스를 유지 관리하는 데 사용되는 시스템은 관계형 데이터베이스 관리 시스템입니다. 많은 관계형 데이터베이스 시스템에는 데이터베이스를 쿼리하고 유지 관리하기 위해 SQL을 사용할 수 있는 옵션이 있습니다.
|
||||
|
||||
_MySQL은 오픈소스 관계형 데이터베이스 관리 시스템입니다. 이 이름은 공동 창립자 Michael Widenius의 딸 이름인 'My'와 구조화된 쿼리 언어의 약자인 'SQL'을 조합한 것입니다._
|
||||
|
||||
MySQL은 관계형 데이터베이스의 한 예이며 다른 많은 옵션이 있습니다.
|
||||
|
||||
|
||||
|
||||
관계형 데이터베이스를 연구하는 동안 **ACID**라는 용어 또는 약어가 많이 언급되었는데, (원자성, 일관성, 격리성, 내구성)은 오류, 정전 및 기타 사고에도 불구하고 데이터 유효성을 보장하기 위한 데이터베이스 트랜잭션의 일련의 속성입니다. 데이터베이스의 맥락에서 ACID 속성을 충족하는 일련의 데이터베이스 작업(데이터에 대한 단일 논리적 작업으로 인식될 수 있음)을 트랜잭션이라고 합니다. 예를 들어, 한 은행 계좌에서 다른 은행 계좌로 자금을 이체하는 경우, 한 계좌에서 인출하고 다른 계좌에 입금하는 등 여러 가지 변경 사항이 포함되더라도 이는 단일 트랜잭션에 해당합니다.
|
||||
|
||||
Best for:
|
||||
|
||||
- 대부분의 애플리케이션(수년 동안 사용되어 왔지만, 최고라는 의미는 아님)
|
||||
|
||||
비정형 데이터에는 적합하지 않으며, 특정 워크로드에 대해 더 나은 확장 기능을 제공하는 다른 NoSQL이 언급되는 경우 확장 기능이 이상적이지 않습니다.
|
||||
|
||||
### 그래프
|
||||
|
||||
그래프 데이터베이스는 테이블이나 문서 대신 노드와 관계를 저장합니다. 화이트보드에 아이디어를 스케치하는 것처럼 데이터가 저장됩니다. 데이터는 사전 정의된 모델에 제한되지 않고 저장되므로 매우 유연한 방식으로 데이터를 사고하고 사용할 수 있습니다.
|
||||
|
||||
_Neo4j는 Neo4j, Inc.에서 개발한 그래프 데이터베이스 관리 시스템입니다. 개발자는 네이티브 그래프 저장 및 처리 기능을 갖춘 ACID 호환 트랜잭션 데이터베이스라고 설명합니다._
|
||||
|
||||
Best for:
|
||||
|
||||
- 그래프
|
||||
- 지식 그래프
|
||||
- 추천 엔진
|
||||
|
||||
### 검색 엔진
|
||||
|
||||
지난 섹션에서는 Elasticsearch 방식으로 검색 엔진 데이터베이스를 사용했습니다.
|
||||
|
||||
검색 엔진 데이터베이스는 데이터 콘텐츠 검색 전용으로 사용되는 비관계형 데이터베이스의 한 유형입니다. 검색 엔진 데이터베이스는 인덱스를 사용해 데이터 간에 유사한 특성을 분류하고 검색 기능을 용이하게 합니다.
|
||||
|
||||
_Elasticsearch는 Lucene 라이브러리를 기반으로 하는 검색 엔진입니다. HTTP 웹 인터페이스와 스키마가 없는 JSON 문서를 갖춘 분산형 멀티테넌트 지원 전체 텍스트 검색 엔진을 제공합니다._
|
||||
|
||||
Best for:
|
||||
|
||||
- 검색 엔진
|
||||
- Typeahead
|
||||
- 로그 검색
|
||||
|
||||
### Multi-model
|
||||
|
||||
Multi-model 데이터베이스는 단일 통합 백엔드에 대해 여러 데이터 모델을 지원하도록 설계된 데이터베이스 관리 시스템입니다. 반면, 대부분의 데이터베이스 관리 시스템은 데이터를 구성, 저장 및 조작하는 방법을 결정하는 단일 데이터 모델을 중심으로 구성됩니다. 문서, 그래프, 관계형, Key-value 모델은 Multi-model 데이터베이스에서 지원할 수 있는 데이터 모델의 예입니다.
|
||||
|
||||
_Fauna는 네이티브 GraphQL을 통해 안전하고 확장 가능한 클라우드 API로 제공되는 유연하고 개발자 친화적인 트랜잭션 데이터베이스입니다._
|
||||
|
||||
Best for:
|
||||
|
||||
- 데이터 모델 선택에 얽매이지 않는 경우
|
||||
- ACID 준수
|
||||
- 빠름
|
||||
- 프로비저닝 오버헤드 없음
|
||||
- 데이터를 어떻게 소비하고 클라우드에 무거운 작업을 맡기고 싶으신가요?
|
||||
|
||||
어떤 산업에 종사하든 데이터베이스의 한 영역을 접하게 될 것이므로, 이것으로 데이터베이스 개요 세션을 마무리하겠습니다. 그런 다음 이 섹션의 뒷부분에서 몇 가지 예를 들어 데이터 관리, 특히 이러한 데이터 서비스의 보호 및 저장에 대해 살펴볼 것입니다.
|
||||
|
||||
아래에 링크한 수많은 리소스를 통해 모든 데이터베이스 유형과 이에 수반되는 모든 것을 심도 있게 살펴보는 데 90년이 걸릴 수도 있습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Redis Crash Course - the What, Why and How to use Redis as your primary database](https://www.youtube.com/watch?v=OqCK95AS-YE)
|
||||
- [Redis: How to setup a cluster - for beginners](https://www.youtube.com/watch?v=GEg7s3i6Jak)
|
||||
- [Redis on Kubernetes for beginners](https://www.youtube.com/watch?v=JmCn7k0PlV4)
|
||||
- [Intro to Cassandra - Cassandra Fundamentals](https://www.youtube.com/watch?v=YjYWsN1vek8)
|
||||
- [MongoDB Crash Course](https://www.youtube.com/watch?v=ofme2o29ngU)
|
||||
- [MongoDB in 100 Seconds](https://www.youtube.com/watch?v=-bt_y4Loofg)
|
||||
- [What is a Relational Database?](https://www.youtube.com/watch?v=OqjJjpjDRLc)
|
||||
- [Learn PostgreSQL Tutorial - Full Course for Beginners](https://www.youtube.com/watch?v=qw--VYLpxG4)
|
||||
- [MySQL Tutorial for Beginners [Full Course]](https://www.youtube.com/watch?v=7S_tz1z_5bA)
|
||||
- [What is a graph database? (in 10 minutes)](https://www.youtube.com/watch?v=REVkXVxvMQE)
|
||||
- [What is Elasticsearch?](https://www.youtube.com/watch?v=ZP0NmfyfsoM)
|
||||
- [FaunaDB Basics - The Database of your Dreams](https://www.youtube.com/watch?v=2CipVwISumA)
|
||||
- [Fauna Crash Course - Covering the Basics](https://www.youtube.com/watch?v=ihaB7CqJju0)
|
||||
|
||||
[Day 86](day86.md)에서 봐요!
|
||||
181
2022/ko/Days/day86.md
Normal file
181
2022/ko/Days/day86.md
Normal file
@ -0,0 +1,181 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Backup all the platforms - Day 86'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Backup all the platforms
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1049058
|
||||
---
|
||||
|
||||
## 모든 플랫폼 백업
|
||||
|
||||
이번 챌린지를 진행하는 동안 다양한 플랫폼과 환경에 대해 논의했습니다. 이 모든 플랫폼과 환경의 공통점은 모두 어느 정도의 데이터 보호가 필요하다는 사실입니다!
|
||||
|
||||
데이터 보호는 수년 전부터 존재해 왔지만, 오늘날의 풍부한 데이터와 이러한 데이터가 가져다주는 가치는 여러 노드와 애플리케이션 전반의 고가용성을 통해 인프라 장애에 대한 복원력을 확보해야 할 뿐만 아니라 장애 시나리오가 발생할 경우 안전하고 안전한 위치에 중요한 데이터의 사본이 필요하다는 점을 고려해야 한다는 것을 의미합니다.
|
||||
|
||||
요즘 사이버 범죄와 랜섬웨어에 대한 이야기를 많이 듣는데, 이는 엄청난 위협이며 랜섬웨어의 공격을 받을 수 있다는 사실에 대해 오해하지 마세요. 랜섬웨어는 시기의 문제가 아닙니다. 따라서 그 시기가 닥쳤을 때를 대비해 데이터를 안전하게 보호해야 하는 이유는 더욱 커집니다. 그러나 데이터 손실의 가장 흔한 원인은 랜섬웨어나 사이버 범죄가 아니라 실수로 인한 삭제입니다!
|
||||
|
||||
우리 모두는 실수로 삭제하지 말았어야 할 파일을 삭제하고 순간적으로 후회한 경험이 있을 것입니다.
|
||||
|
||||
챌린지 기간 동안 논의한 모든 기술과 자동화를 통해 상태 저장 데이터 또는 복잡한 stateless 구성을 보호해야 하는 요구 사항은 플랫폼에 관계없이 여전히 존재합니다.
|
||||
|
||||
|
||||
|
||||
하지만 자동화를 염두에 두고 데이터 보호를 수행할 수 있어야 하며 워크플로우에 통합할 수 있어야 합니다.
|
||||
|
||||
백업이 무엇인지 살펴보면
|
||||
|
||||
_정보 기술에서 백업 또는 데이터 백업은 데이터 손실이 발생한 후 원본을 복원하는 데 사용할 수 있도록 컴퓨터 데이터의 복사본을 다른 곳에 저장하는 것입니다. 이러한 과정을 나타내는 동사 형태는 "back up"이고, 명사 및 형용사 형태는 "백업"입니다._
|
||||
|
||||
이를 가장 간단한 형태로 분류하면 백업은 데이터를 복사하여 새 위치에 붙여 넣는 것입니다. 간단히 말해, 지금 당장 C: 드라이브에 있는 파일을 D: 드라이브로 복사하여 백업을 만들면 C: 드라이브에 문제가 발생하거나 파일 내에서 잘못 편집된 부분이 있을 때를 대비해 복사본을 확보할 수 있습니다. D: 드라이브에 있는 사본으로 되돌릴 수 있습니다. 이제 C 드라이브와 D 드라이브가 모두 있는 곳에서 컴퓨터가 죽으면 보호되지 않으므로 시스템 외부의 솔루션이나 집에 있는 NAS 드라이브에 데이터 사본을 저장하는 방법을 고려해야 하나요? 하지만 집에 무슨 일이 생기면 다른 위치의 다른 시스템에 저장하는 것을 고려해야 할 수도 있고, 클라우드가 옵션이 될 수도 있습니다. 장애 위험을 줄이기 위해 중요한 파일의 사본을 여러 위치에 저장할 수 있을까요?
|
||||
|
||||
### 3-2-1 백업 방법론
|
||||
|
||||
이제 3-2-1 규칙 또는 백업 방법론에 대해 이야기하기에 좋은 시기인 것 같습니다. 이 주제를 다룬 [라이트닝 토크](https://www.youtube.com/watch?v=5wRt1bJfKBw)를 진행한 적이 있습니다.
|
||||
|
||||
데이터를 보호해야 하는 이유에 대해서는 이미 몇 가지 극단적인 예를 들었지만, 아래에 몇 가지를 더 말씀드리겠습니다:
|
||||
|
||||
|
||||
|
||||
이제 3-2-1 방법론에 대해 말씀드리겠습니다. 데이터의 첫 번째 복사본 또는 백업은 가능한 한 프로덕션 시스템에 가깝게 저장해야 하는데, 그 이유는 복구 속도를 고려한 것이며, 다시 실수로 삭제하는 경우가 가장 흔한 복구 이유가 될 것이라는 원래의 이야기로 돌아가겠습니다. 하지만 원본 또는 프로덕션 시스템 외부의 적절한 보조 미디어에 저장하고 싶습니다.
|
||||
|
||||
그런 다음 다른 집, 건물, 데이터 센터 또는 퍼블릭 클라우드 등 두 번째 위치로 데이터 사본을 외부 또는 오프사이트로 전송하고 싶습니다.
|
||||
|
||||
|
||||
|
||||
### 백업 책임
|
||||
|
||||
백업을 하지 않아도 된다는 속설에 대해 "모든 것이 stateless 상태"라는 말을 들어보셨을 것입니다. 모든 것이 stateless 상태라면 비즈니스는 무엇일까요? 데이터베이스도 없고, 워드 문서도 없나요? 비즈니스 내의 모든 개인이 데이터를 보호해야 할 책임이 있지만, 미션 크리티컬 애플리케이션과 데이터에 대한 백업 프로세스를 제공하는 것은 대부분 운영 팀에서 담당하게 될 것입니다.
|
||||
|
||||
데이터베이스에 실수를 해서 클러스터의 모든 노드에 복제되거나 화재, 홍수, 피의 시나리오로 인해 클러스터를 더 이상 사용할 수 없게 되어 중요한 데이터가 손실되는 경우를 제외하고는 "고가용성은 내 백업이고, 클러스터에 여러 노드를 구축했으니 절대 다운될 일은 없습니다!"라고 생각하는 것도 좋은 생각일 수 있습니다. 고집을 부리는 것이 아니라 데이터와 서비스를 인식하는 것이 중요하며, 모든 사람이 아키텍처에 고가용성 및 내결함성을 고려해야 하지만 이것이 백업의 필요성을 대체할 수는 없습니다!
|
||||
|
||||
복제는 데이터의 오프사이트 복사본을 제공하는 것처럼 보일 수 있으며, 위에서 언급한 클러스터가 여러 위치에 분산되어 있을 수도 있지만 첫 번째 실수는 여전히 그곳에 복제될 것입니다. 하지만 백업 요구사항은 환경 내에서 애플리케이션 복제 또는 시스템 복제와 함께 고려해야 합니다.
|
||||
|
||||
이제 이 모든 것을 말했듯이 다른 쪽에서도 극단적으로 나아가 너무 많은 위치에 데이터 사본을 전송할 수 있으며, 이는 비용뿐만 아니라 표면 영역이 크게 확장되어 공격받을 위험이 높아집니다.
|
||||
|
||||
어쨌든 백업은 누가 관리하나요? 각 비즈니스마다 다르겠지만 누군가는 백업 요구 사항을 이해해야 합니다. 그리고 복구 계획도 이해해야 합니다!
|
||||
|
||||
### 모두가 신경 쓸 때까지 아무도 신경 쓰지 않습니다.
|
||||
|
||||
백업은 대표적인 예로, 무언가를 복원해야 할 때까지 아무도 백업에 대해 신경 쓰지 않습니다. 데이터를 백업해야 한다는 요구 사항과 함께 복원 방법도 고려해야 합니다!
|
||||
|
||||
텍스트 문서의 예에서는 아주 작은 파일에 대해 이야기하고 있으므로 앞뒤로 복사하는 기능이 쉽고 빠릅니다. 하지만 100GB 이상의 파일에 대해 이야기하는 경우에는 시간이 오래 걸립니다. 또한 가상 머신을 예로 들면 복구해야 하는 수준도 고려해야 합니다.
|
||||
|
||||
전체 가상 머신이 있고 운영 체제, 애플리케이션이 설치되어 있으며 데이터베이스 서버인 경우 일부 데이터베이스 파일도 있습니다. 실수로 데이터베이스에 잘못된 코드 줄을 삽입한 경우 전체 가상 머신을 복원할 필요는 없으며, 복구 대상만 세분화하여 복구하고 싶습니다.
|
||||
|
||||
### 백업 시나리오
|
||||
|
||||
이제 일부 데이터를 보호하는 시나리오를 구축해 보겠습니다. 특히, 로컬 컴퓨터(이 경우에는 Windows이지만 제가 사용할 도구는 무료 오픈 소스일 뿐만 아니라 크로스 플랫폼도 지원합니다)에서 일부 파일을 보호하고 싶습니다. 집에 로컬로 있는 NAS 장치뿐만 아니라 클라우드의 Object Storage 버킷에도 보호되도록 하고 싶습니다.
|
||||
|
||||
이 중요한 데이터를 백업하고 싶은데, 마침 90DaysOfDevOps의 저장소이기도 하고, 지금 이 글을 읽고 있는 GitHub로도 전송되고 있는데, 만약 내 컴퓨터가 죽고 GitHub가 다운되면 어떻게 될까요? 다른 사람이 어떻게 콘텐츠를 읽을 수 있을 뿐만 아니라 해당 데이터를 다른 서비스로 어떻게 복원할 수 있을까요?
|
||||
|
||||
|
||||
|
||||
이를 달성하는 데 도움이 되는 많은 도구가 있지만, 저는 백업을 암호화, 중복 제거 및 압축하는 동시에 여러 위치로 백업을 보낼 수 있는 오픈 소스 백업 도구인 [Kopia](https://kopia.io/)라는 도구를 사용하려고 합니다.
|
||||
|
||||
[여기](https://github.com/kopia/kopia/releases)에서 릴리스를 다운로드할 수 있으며, 이 글을 쓰는 시점에서는 v0.10.6을 사용할 것입니다.
|
||||
|
||||
### Kopia 설치하기
|
||||
|
||||
Kopia CLI와 GUI가 있는데, 여기서는 GUI를 사용하겠지만 GUI를 제공하지 않는 리눅스 서버의 경우 CLI 버전도 사용할 수 있다는 것을 알고 있습니다.
|
||||
|
||||
저는 `KopiaUI-Setup-0.10.6.exe`를 사용하겠습니다.
|
||||
|
||||
다음번 설치는 매우 빠르게 진행되며, 애플리케이션을 열면 백업 저장소로 사용할 스토리지 유형을 선택할 수 있는 선택 항목이 표시됩니다.
|
||||
|
||||
|
||||
|
||||
### 리포지토리 설정하기
|
||||
|
||||
먼저 로컬 NAS 장치를 사용하여 리포지토리를 설정하고 SMB를 사용하여 이 작업을 수행하려고 하지만 NFS를 사용할 수도 있습니다.
|
||||
|
||||
|
||||
|
||||
다음 화면에서는 비밀번호를 정의할 것이며, 이 비밀번호는 리포지토리 콘텐츠를 암호화하는 데 사용됩니다.
|
||||
|
||||
|
||||
|
||||
이제 리포지토리가 구성되었으므로 임시 스냅샷을 트리거하여 리포지토리에 데이터 쓰기를 시작할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
먼저 스냅샷할 대상의 경로를 입력해야 하며, 여기서는 `90DaysOfDevOps` 폴더의 복사본을 만들고자 합니다. 곧 스케줄링 측면으로 돌아가겠습니다.
|
||||
|
||||
|
||||
|
||||
스냅샷 보존을 정의할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
제외하려는 파일이나 파일 형식이 있을 수 있습니다.
|
||||
|
||||
|
||||
|
||||
일정을 정의하려면 이다음 화면에서 할 수 있으며, 이 스냅샷을 처음 생성할 때 이 페이지가 정의할 첫 페이지입니다.
|
||||
|
||||
|
||||
|
||||
그리고 여기에서 처리할 수 있는 몇 가지 다른 설정이 표시됩니다.
|
||||
|
||||
|
||||
|
||||
지금 스냅샷을 선택하면 데이터가 리포지토리에 기록됩니다.
|
||||
|
||||
|
||||
|
||||
### S3로 오프사이트 백업
|
||||
|
||||
Kopia에서는 UI를 통해 한 번에 하나의 리포지토리만 구성할 수 있는 것처럼 보입니다. 그러나 UI를 통해 창의력을 발휘하여 여러 리포지토리 구성 파일을 선택하여 로컬 및 오프사이트에 복사본을 오브젝트 스토리지에 저장하려는 목표를 달성할 수 있습니다.
|
||||
|
||||
제가 데이터를 전송하기 위해 선택한 오브젝트 스토리지는 Google 클라우드 스토리지입니다. 먼저 Google 클라우드 플랫폼 계정에 로그인하고 스토리지 버킷을 생성했습니다. 시스템에 이미 구글 클라우드 SDK가 설치되어 있었지만 `gcloud auth application-default login`을 실행하면 계정으로 인증되었습니다.
|
||||
|
||||
|
||||
|
||||
그런 다음 Kopia의 CLI를 사용하여 이전 단계에서 SMB 리포지토리를 추가한 후 리포지토리의 현재 상태를 표시했습니다. `C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status` 명령을 사용하여 이 작업을 수행했습니다.
|
||||
|
||||
|
||||
|
||||
이제 데모를 위해 리포지토리에 대한 구성을 교체할 준비가 되었습니다. 이 두 리포지토리에 모두 적용하는 장기적인 솔루션을 원한다면 `smb.config` 파일과 `object.config` 파일을 생성하고 이 두 명령을 실행하여 데이터 사본을 각 위치로 전송할 수 있어야 할 것입니다. 리포지토리를 추가하기 위해 `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository create gcs --bucket 90daysofdevops`를 실행합니다.
|
||||
|
||||
위의 명령은 우리가 생성한 구글 클라우드 스토리지 버킷의 이름이 `90daysofdevops`라는 것을 고려합니다.
|
||||
|
||||
|
||||
|
||||
이제 새 리포지토리를 생성했으므로 `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config repository status` 명령을 다시 실행하면 이제 GCS 리포지토리 구성이 표시됩니다.
|
||||
|
||||
|
||||
|
||||
다음으로 해야 할 일은 스냅샷을 생성하여 새로 생성한 리포지토리로 전송하는 것입니다. `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config kopia snapshot create "C:\Users\micha\demo\90DaysOfDevOps"` 명령을 사용하여 이 프로세스를 시작할 수 있습니다. 아래 브라우저에서 이제 Google 클라우드 스토리지 버킷에 백업에 기반한 kopia 파일이 있는 것을 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
위의 프로세스를 통해 중요한 데이터를 두 개의 다른 위치로 전송해야 하는 요구 사항을 해결할 수 있으며, 그중 하나는 Google Cloud Storage의 오프사이트에 있고 물론 다른 미디어 유형에 데이터의 프로덕션 사본이 여전히 있습니다.
|
||||
|
||||
### 복원
|
||||
|
||||
복원은 또 다른 고려 사항이며 매우 중요한 기능으로, Kopia는 기존 위치뿐만 아니라 새로운 위치로도 복원할 수 있는 기능을 제공합니다.
|
||||
|
||||
`"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config snapshot list` 명령을 실행하면 현재 구성된 리포지토리(GCS)에 있는 스냅샷이 나열됩니다.
|
||||
|
||||
|
||||
|
||||
그런 다음 `"C:\Program Files\KopiaUI\resources\server\kopia.exe" --config-file=C:\Users\micha\AppData\Roaming\kopia\repository.config mount all Z:` 명령을 사용하여 GCS에서 직접 해당 스냅샷을 마운트할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
또한 `kopia snapshot restore kdbd9dff738996cfe7bcf99b45314e193`을 사용하여 스냅샷 내용을 복원할 수도 있습니다.
|
||||
|
||||
위의 명령어가 매우 긴데, 이는 실습 상단에 설명한 대로 KopiaUI 버전의 kopia.exe를 사용했기 때문이며, kopia.exe를 다운로드하여 경로에 넣으면 `kopia` 명령어만 사용하면 됩니다.
|
||||
|
||||
다음 세션에서는 Kubernetes 내에서 워크로드를 보호하는 데 중점을 두겠습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
[Day 87](day87.md)에서 봐요!
|
||||
190
2022/ko/Days/day87.md
Normal file
190
2022/ko/Days/day87.md
Normal file
@ -0,0 +1,190 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Hands-On Backup & Recovery - Day 87'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Hands-On Backup & Recovery
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048717
|
||||
---
|
||||
|
||||
## 백업 및 복구 실습
|
||||
|
||||
지난 세션에서는 로컬 NAS와 클라우드 기반 오브젝트 스토리지에 중요한 데이터를 백업하는 데 사용한 오픈소스 백업 도구인 [Kopia](https://kopia.io/)에 대해 살펴봤습니다.
|
||||
|
||||
이번 섹션에서는 Kubernetes 백업의 세계로 들어가 보겠습니다. 이 플랫폼은 챌린지 초반에 [큰 그림: Kubernetes](/2022/Days/Days/day49.md)에서 다뤘던 플랫폼입니다.
|
||||
|
||||
이번에도 Minikube 클러스터를 사용하지만, 이번에는 사용 가능한 몇 가지 애드온을 활용하겠습니다.
|
||||
|
||||
### Kubernetes 클러스터 설정
|
||||
|
||||
Minikube 클러스터를 설정하기 위해 `minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p 90daysofdevops --kubernetes-version=1.21.2`를 실행하면 백업을 수행할 때 이를 최대한 활용하기 위해 `volumesnapshots` 및 `csi-hostpath-driver`를 사용하고 있는 것을 알 수 있습니다.
|
||||
|
||||
이 시점에서는 아직 Kasten K10을 배포하지 않았지만, 클러스터가 가동되면 다음 명령을 실행하여 Kasten K10이 이를 사용할 수 있도록 volumesnapshotclass에 주석을 달려고 합니다.
|
||||
|
||||
```Shell
|
||||
kubectl annotate volumesnapshotclass csi-hostpath-snapclass \
|
||||
k10.kasten.io/is-snapshot-class=true
|
||||
```
|
||||
|
||||
또한 다음을 사용하여 기본 저장소 클래스를 표준 기본 저장소 클래스에서 csi-hostpath 저장소 클래스로 변경할 것입니다.
|
||||
|
||||
```Shell
|
||||
kubectl patch storageclass csi-hostpath-sc -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
|
||||
|
||||
kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
|
||||
```
|
||||
|
||||
|
||||
|
||||
### Kasten K10 배포하기
|
||||
|
||||
Kasten Helm 리포지토리를 추가합니다.
|
||||
|
||||
`helm repo add kasten https://charts.kasten.io/`
|
||||
|
||||
여기에서도 `arkade kasten install k10`을 사용할 수 있지만 데모를 위해 다음 단계를 진행하겠습니다. [자세한 내용](https://blog.kasten.io/kasten-k10-goes-to-the-arkade)
|
||||
|
||||
네임스페이스를 생성하고 K10을 배포합니다.(약 5분 정도 소요됨)
|
||||
|
||||
`helm install k10 kasten/k10 --namespace=kasten-io --set auth.tokenAuth.enabled=true --set injectKanisterSidecar.enabled=true --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecar=true --create-namespace`
|
||||
|
||||
|
||||
|
||||
다음 명령어를 실행하여 pod가 생성되는 것을 확인할 수 있다.
|
||||
|
||||
`kubectl get pods -n kasten-io -w`
|
||||
|
||||
|
||||
|
||||
포트 포워딩을 통해 K10 대시보드에 접속하고, 새 터미널을 열어 아래 명령을 실행한다.
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Kasten 대시보드는 `http://127.0.0.1:8080/k10/#/`에서 사용할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 대시보드로 인증하려면 다음 명령어로 얻을 수 있는 토큰이 필요합니다.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
이제 이 토큰을 가져와 브라우저에 입력하면 이메일과 회사 이름을 입력하라는 메시지가 표시됩니다.
|
||||
|
||||
|
||||
|
||||
그러면 Kasten K10 대시보드에 액세스할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
### stateful 애플리케이션 배포
|
||||
|
||||
Kubernetes 섹션에서 사용한 stateful 애플리케이션을 사용합니다.
|
||||
|
||||
|
||||
|
||||
이 애플리케이션의 YAML 구성 파일은 여기에서 찾을 수 있습니다. -> [pacman-stateful-demo.yaml](Kubernetes/pacman-stateful-demo.yaml)
|
||||
|
||||
|
||||
|
||||
`kubectl get all -n pacman`을 사용하여 다가오는 pod를 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
그런 다음 새 터미널에서 pacman 프론트엔드를 포트 포워드할 수 있습니다. `kubectl port-forward svc/pacman 9090:80 -n pacman`을 실행합니다.
|
||||
|
||||
브라우저에서 다른 탭을 열어 http://localhost:9090/
|
||||
|
||||
|
||||
|
||||
시간을 내어 백엔드 MongoDB 데이터베이스에서 높은 점수를 기록하세요.
|
||||
|
||||
|
||||
|
||||
### 높은 점수 보호
|
||||
|
||||
이제 데이터베이스에 미션 크리티컬한 데이터가 있으며 이를 잃고 싶지 않습니다. 이 전체 애플리케이션을 보호하기 위해 Kasten K10을 사용할 수 있습니다.
|
||||
|
||||
Kasten K10 대시보드 탭으로 돌아가면 Kubernetes 클러스터에 pacman 애플리케이션이 추가되어 애플리케이션 수가 1개에서 2개로 늘어난 것을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
애플리케이션 카드를 클릭하면 클러스터에서 자동으로 검색된 애플리케이션을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
Kasten K10을 사용하면 스토리지 기반 스냅샷을 활용할 수 있을 뿐만 아니라 사본을 오브젝트 스토리지 옵션으로 내보낼 수도 있습니다.
|
||||
|
||||
데모에서는 클러스터에 수동 스토리지 스냅샷을 생성한 다음, 고득점 데이터에 불량 데이터를 추가하여 실수로 실수하는 상황을 시뮬레이션해 보겠습니다.
|
||||
|
||||
먼저 아래의 수동 스냅샷 옵션을 사용할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
데모에서는 모든 것을 기본값으로 두겠습니다.
|
||||
|
||||
|
||||
|
||||
대시보드로 돌아가면 실행 중인 작업에 대한 상태 보고서가 표시되며, 완료되면 이와 같이 성공적으로 표시됩니다.
|
||||
|
||||
|
||||
|
||||
### 실패 시나리오
|
||||
|
||||
이제 애플리케이션에 규범적인 잘못된 변경을 추가하기만 하면 미션 크리티컬 데이터에 치명적인 변경을 수행할 수 있습니다.
|
||||
|
||||
아래에서 볼 수 있듯이, 프로덕션 미션 크리티컬 데이터베이스에는 원하지 않는 두 가지 입력이 있습니다.
|
||||
|
||||
|
||||
|
||||
### 데이터 복원
|
||||
|
||||
이것은 간단한 데모이며 현실적이지 않은 방식이지만 데이터베이스를 삭제하는 것이 얼마나 쉬운지 보셨나요?
|
||||
|
||||
이제 고득점 목록을 실수하기 전의 상태로 조금 더 깔끔하게 정리해 보겠습니다.
|
||||
|
||||
애플리케이션 카드와 pacman 탭으로 돌아가면 이제 복원할 수 있는 복원 지점이 하나 생겼습니다.
|
||||
|
||||
|
||||
|
||||
복원을 선택하면 해당 애플리케이션에 연결된 모든 스냅샷과 내보내기를 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
복원을 선택하면 사이드 창이 나타나며, 기본 설정을 유지하고 복원을 누릅니다.
|
||||
|
||||
|
||||
|
||||
복원할 것인지 확인합니다.
|
||||
|
||||
|
||||
|
||||
그런 다음 대시보드로 돌아가서 복원 진행 상황을 확인할 수 있습니다. 다음과 같은 화면이 표시됩니다.
|
||||
|
||||
|
||||
|
||||
하지만 더 중요한 것은 미션 크리티컬 애플리케이션에서 고점수 목록이 어떻게 보이는지입니다. 앞서 다룬 대로 pacman으로 포트 포워딩을 다시 시작해야 합니다.
|
||||
|
||||
|
||||
|
||||
매우 간단한 데모이며, 백업과 관련하여 Kasten K10이 달성할 수 있는 것의 표면적인 부분만 다루었습니다. 앞으로 이러한 영역 중 일부에 대해 좀 더 심층적인 비디오 콘텐츠를 제작할 예정입니다. 또한 재해 복구 및 데이터의 이동성과 관련하여 데이터 관리와 관련된 몇 가지 다른 주요 영역을 강조하기 위해 Kasten K10을 사용할 것입니다.
|
||||
|
||||
다음에는 애플리케이션 일관성에 대해 살펴보겠습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
[Day 88](day88.md)에서 봐요!
|
||||
296
2022/ko/Days/day88.md
Normal file
296
2022/ko/Days/day88.md
Normal file
@ -0,0 +1,296 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Application Focused Backup - Day 88'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Application Focused Backups
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048749
|
||||
---
|
||||
|
||||
## 애플리케이션 중심 백업
|
||||
|
||||
데이터 서비스 또는 데이터베이스와 같은 데이터 집약적인 애플리케이션에 대해서는 이미 [day 85](day85.md)에서 설명한 바 있습니다. 이러한 데이터 서비스의 경우 특히 애플리케이션 일관성과 관련하여 일관성을 관리하는 방법을 고려해야 합니다.
|
||||
|
||||
이 글에서는 애플리케이션 데이터를 일관되게 보호하는 것과 관련된 요구 사항을 자세히 살펴보겠습니다.
|
||||
|
||||
이를 위해 우리가 선택한 도구는 [Kanister](https://kanister.io/)입니다.
|
||||
|
||||
|
||||
|
||||
### Kanister 소개
|
||||
|
||||
Kanister는 Kasten이 만든 오픈소스 프로젝트로, Kubernetes에서 애플리케이션 데이터를 관리(백업 및 복원)할 수 있게 해줍니다. Kanister를 Helm 애플리케이션으로 Kubernetes 클러스터에 배포할 수 있습니다.
|
||||
|
||||
Kanister는 Kubernetes 커스텀 리소스를 사용하며, Kanister를 배포할 때 설치되는 주요 커스텀 리소스는 다음과 같습니다.
|
||||
|
||||
- `Profile` - 백업을 저장하고 복구할 대상 위치입니다. 가장 일반적으로는 오브젝트 스토리지입니다.
|
||||
- `Blueprint` - 데이터베이스를 백업 및 복구하기 위해 수행해야 하는 단계가 Blueprint에 유지되어야 합니다.
|
||||
- `ActionSet` - 대상 백업을 Profile로 이동하고 복원 작업을 수행하는 동작입니다.
|
||||
|
||||
### 실행 연습
|
||||
|
||||
실습에 들어가기 전에 Kanister가 애플리케이션 데이터를 보호하기 위해 취하는 워크플로우를 살펴보겠습니다. 먼저 컨트롤러를 Helm을 사용하여 Kubernetes 클러스터에 배포하고, Kanister는 해당 네임스페이스 내에 위치합니다. 커뮤니티에서 지원하는 많은 Blueprint를 사용할 수 있으며, 이에 대해서는 곧 자세히 다루겠습니다. 그런 다음 데이터베이스 워크로드가 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 ActionSet을 생성합니다.
|
||||
|
||||
|
||||
|
||||
ActionSet을 사용하면 특정 데이터 서비스에 대해 Blueprint에 정의된 액션을 실행할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
ActionSet은 차례로 Kanister 함수(KubeExec, KubeTask, 리소스 라이프사이클)를 사용하여 백업을 대상 리포지토리(Profile)로 push합니다.
|
||||
|
||||
|
||||
|
||||
해당 작업이 완료/실패하면 해당 상태가 ActionSet에서 업데이트됩니다.
|
||||
|
||||
|
||||
|
||||
### Kanister 배포
|
||||
|
||||
이번에도 Minikube 클러스터를 사용하여 애플리케이션 백업을 수행합니다. 이전 세션에서 계속 실행 중이라면 이 클러스터를 계속 사용할 수 있습니다.
|
||||
|
||||
이 글을 쓰는 시점에, 우리는 다음 Helm 명령으로 이미지 버전 `0.75.0`을 사용하여 Kubernetes 클러스터에 kanister를 설치합니다.
|
||||
|
||||
`helm install kanister --namespace kanister kanister/kanister-operator --set image.tag=0.75.0 --create-namespace`
|
||||
|
||||
|
||||
|
||||
`kubectl get pods -n kanister`를 사용하여 pod가 실행 중인지 확인한 다음 사용자 정의 리소스 정의가 사용 가능한지 확인할 수 있습니다.(Kanister만 설치한 경우 강조 표시된 3이 표시됩니다.)
|
||||
|
||||
|
||||
|
||||
### 데이터베이스 배포하기
|
||||
|
||||
Helm을 통해 MySQL을 배포합니다:
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl create ns ${APP_NAME}
|
||||
helm repo add bitnami https://charts.bitnami.com/bitnami
|
||||
helm install mysql-store bitnami/mysql --set primary.persistence.size=1Gi,volumePermissions.enabled=true --namespace=${APP_NAME}
|
||||
kubectl get pods -n ${APP_NAME} -w
|
||||
```
|
||||
|
||||
|
||||
|
||||
초기 데이터로 MySQL 데이터베이스를 채우고 다음을 실행합니다:
|
||||
|
||||
```Shell
|
||||
MYSQL_ROOT_PASSWORD=$(kubectl get secret --namespace ${APP_NAME} mysql-store -o jsonpath="{.data.mysql-root-password}" | base64 --decode)
|
||||
MYSQL_HOST=mysql-store.${APP_NAME}.svc.cluster.local
|
||||
MYSQL_EXEC="mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD} -DmyImportantData -t"
|
||||
echo MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD}
|
||||
```
|
||||
|
||||
### MySQL 클라이언트 생성하기
|
||||
|
||||
클라이언트 역할을 할 다른 컨테이너 이미지를 실행합니다.
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
```Shell
|
||||
Note: if you already have an existing MySQL client pod running, delete with the command
|
||||
|
||||
kubectl delete pod -n ${APP_NAME} mysql-client
|
||||
```
|
||||
|
||||
### MySQL에 데이터 추가하기
|
||||
|
||||
```Shell
|
||||
echo "create database myImportantData;" | mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD}
|
||||
MYSQL_EXEC="mysql -h ${MYSQL_HOST} -u root --password=${MYSQL_ROOT_PASSWORD} -DmyImportantData -t"
|
||||
echo "drop table Accounts" | ${MYSQL_EXEC}
|
||||
echo "create table if not exists Accounts(name text, balance integer); insert into Accounts values('nick', 0);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('albert', 112);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('alfred', 358);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('beatrice', 1321);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('bartholomew', 34);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edward', 5589);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edwin', 144);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('edwina', 233);" | ${MYSQL_EXEC}
|
||||
echo "insert into Accounts values('rastapopoulos', 377);" | ${MYSQL_EXEC}
|
||||
echo "select * from Accounts;" | ${MYSQL_EXEC}
|
||||
exit
|
||||
```
|
||||
|
||||
아래와 같은 데이터를 볼 수 있을 것입니다.
|
||||
|
||||
|
||||
|
||||
### Kanister Profile 생성
|
||||
|
||||
Kanister는 Blueprint와 이 두 유틸리티를 통해 오브젝트 스토리지 공급자와 상호작용할 수 있는 CLI인 `kanctl`과 또 다른 유틸리티인 `kando`를 제공합니다.
|
||||
|
||||
[CLI 다운로드](https://docs.kanister.io/tooling.html#tooling)
|
||||
|
||||
이제 Profile 대상과 복원 위치로 사용할 AWS S3 버킷을 생성했습니다. 환경 변수를 사용하여 `kanctl`로 실행하는 명령을 계속 보여드릴 수 있도록 환경 변수를 사용하여 kanister Profile을 생성하겠습니다.
|
||||
|
||||
`kanctl create profile s3compliant --access-key $ACCESS_KEY --secret-key $SECRET_KEY --bucket $BUCKET --region eu-west-2 --namespace my-production-app`
|
||||
|
||||
|
||||
|
||||
### Blueprint 시간
|
||||
|
||||
[Kanister 예제](https://github.com/kanisterio/kanister/tree/master/examples)에 나열되어 있지 않은 데이터 서비스가 아니라면 처음부터 만들 필요는 없지만, 커뮤니티 기여를 통해 이 프로젝트의 인지도를 높일 수 있습니다.
|
||||
|
||||
우리가 사용할 Blueprint는 아래와 같습니다.
|
||||
|
||||
```Shell
|
||||
apiVersion: cr.kanister.io/v1alpha1
|
||||
kind: Blueprint
|
||||
metadata:
|
||||
name: mysql-blueprint
|
||||
actions:
|
||||
backup:
|
||||
outputArtifacts:
|
||||
mysqlCloudDump:
|
||||
keyValue:
|
||||
s3path: "{{ .Phases.dumpToObjectStore.Output.s3path }}"
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: dumpToObjectStore
|
||||
objects:
|
||||
mysqlSecret:
|
||||
kind: Secret
|
||||
name: '{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}'
|
||||
namespace: '{{ .StatefulSet.Namespace }}'
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .StatefulSet.Namespace }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="/mysql-backups/{{ .StatefulSet.Namespace }}/{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}/{{ toDate "2006-01-02T15:04:05.999999999Z07:00" .Time | date "2006-01-02T15-04-05" }}/dump.sql.gz"
|
||||
root_password="{{ index .Phases.dumpToObjectStore.Secrets.mysqlSecret.Data "mysql-root-password" | toString }}"
|
||||
mysqldump --column-statistics=0 -u root --password=${root_password} -h {{ index .Object.metadata.labels "app.kubernetes.io/instance" }} --single-transaction --all-databases | gzip - | kando location push --profile '{{ toJson .Profile }}' --path ${s3_path} -
|
||||
kando output s3path ${s3_path}
|
||||
restore:
|
||||
inputArtifactNames:
|
||||
- mysqlCloudDump
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: restoreFromBlobStore
|
||||
objects:
|
||||
mysqlSecret:
|
||||
kind: Secret
|
||||
name: '{{ index .Object.metadata.labels "app.kubernetes.io/instance" }}'
|
||||
namespace: '{{ .StatefulSet.Namespace }}'
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .StatefulSet.Namespace }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="{{ .ArtifactsIn.mysqlCloudDump.KeyValue.s3path }}"
|
||||
root_password="{{ index .Phases.restoreFromBlobStore.Secrets.mysqlSecret.Data "mysql-root-password" | toString }}"
|
||||
kando location pull --profile '{{ toJson .Profile }}' --path ${s3_path} - | gunzip | mysql -u root --password=${root_password} -h {{ index .Object.metadata.labels "app.kubernetes.io/instance" }}
|
||||
delete:
|
||||
inputArtifactNames:
|
||||
- mysqlCloudDump
|
||||
phases:
|
||||
- func: KubeTask
|
||||
name: deleteFromBlobStore
|
||||
args:
|
||||
image: ghcr.io/kanisterio/mysql-sidecar:0.75.0
|
||||
namespace: "{{ .Namespace.Name }}"
|
||||
command:
|
||||
- bash
|
||||
- -o
|
||||
- errexit
|
||||
- -o
|
||||
- pipefail
|
||||
- -c
|
||||
- |
|
||||
s3_path="{{ .ArtifactsIn.mysqlCloudDump.KeyValue.s3path }}"
|
||||
kando location delete --profile '{{ toJson .Profile }}' --path ${s3_path}
|
||||
```
|
||||
|
||||
이를 추가하기 위해 `kubectl create -f mysql-blueprint.yml -n kanister` 명령을 사용합니다.
|
||||
|
||||
|
||||
|
||||
### ActionSet을 생성하고 애플리케이션 보호하기
|
||||
|
||||
이제 이 애플리케이션에 대한 백업을 정의하는 ActionSet을 사용하여 MySQL 데이터의 백업을 수행하겠습니다. 컨트롤러와 동일한 네임스페이스에 ActionSet을 생성합니다.
|
||||
|
||||
`kubectl get profiles.cr.kanister.io -n my-production-app` 명령은 이전에 생성한 Profile을 표시하며, 여기에 여러 Profile을 구성할 수 있으므로 다른 ActionSet에 특정 Profile을 사용할 수 있습니다.
|
||||
|
||||
그런 다음 `kanctl`을 사용하여 다음 명령으로 ActionSet을 생성합니다.
|
||||
|
||||
`kanctl create actionset --action backup --namespace kanister --blueprint mysql-blueprint --statefulset my-production-app/mysql-store --profile my-production-app/s3-profile-dc5zm --secrets mysql=my-production-app/mysql-store`
|
||||
|
||||
위의 명령에서 네임스페이스에 추가한 Blueprint, `my-production-app` 네임스페이스의 statefulset, 그리고 MySQL 애플리케이션에 들어가기 위한 시크릿을 정의하고 있음을 알 수 있습니다.
|
||||
|
||||
|
||||
|
||||
ActionSet 이름을 가져와서 다음 명령 `kubectl --namespace kanister describe actionset backup-qpnqv`를 사용하여 ActionSet의 상태를 확인합니다.
|
||||
|
||||
마지막으로, 이제 AWS S3 버킷에 데이터가 있는지 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
### 복원
|
||||
|
||||
복원하기 전에 약간의 손상을 입혀야 합니다. 테이블을 떨어뜨릴 수도 있고, 실수일 수도 있고 그렇지 않을 수도 있습니다.
|
||||
|
||||
MySQL pod에 연결합니다.
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
중요 데이터 DB는 `echo "SHOW DATABASES;"와 함께 있는 것을 볼 수 있습니다. | ${mysql_exec}`로 확인할 수 있습니다.
|
||||
|
||||
그런 다음 drop하기 위해 `echo "DROP DATABASE myImportantData;" | ${mysql_exec}`를 실행했습니다.
|
||||
|
||||
그리고 데이터베이스를 보여주기 위해 몇 번의 시도를 통해 이것이 사라진 것을 확인했습니다.
|
||||
|
||||
|
||||
|
||||
이제 Kanister를 사용하여 `kubectl get actionset -n kanister`를 사용하여 앞서 가져 온 ActionSet 이름을 찾아 중요한 데이터를 다시 가져올 수 있습니다. 그런 다음 `kanctl create actionset -n kanister --action restore --from "backup-qpnqv"`를 사용하여 데이터를 복원하기 위한 복원 ActionSet을 생성합니다.
|
||||
|
||||
|
||||
|
||||
아래 명령어를 사용하여 데이터베이스에 연결하면 데이터가 복구되었는지 확인할 수 있습니다.
|
||||
|
||||
```Shell
|
||||
APP_NAME=my-production-app
|
||||
kubectl run mysql-client --rm --env APP_NS=${APP_NAME} --env MYSQL_EXEC="${MYSQL_EXEC}" --env MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD} --env MYSQL_HOST=${MYSQL_HOST} --namespace ${APP_NAME} --tty -i --restart='Never' --image docker.io/bitnami/mysql:latest --command -- bash
|
||||
```
|
||||
|
||||
이제 MySQL 클라이언트에 들어가서 `echo "SHOW DATABASES;" | ${MYSQL_EXEC}`를 실행하면 데이터베이스가 다시 돌아온 것을 확인할 수 있습니다. 또한 `"select * from Accounts;" | ${MYSQL_EXEC}`를 실행하여 데이터베이스의 내용을 확인할 수 있으며 중요한 데이터가 복원되었습니다.
|
||||
|
||||
|
||||
|
||||
다음 포스트에서는 Kubernetes 내의 재해 복구에 대해 살펴보겠습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Kanister Overview - An extensible open-source framework for app-lvl data management on Kubernetes](https://www.youtube.com/watch?v=wFD42Zpbfts)
|
||||
- [Application Level Data Operations on Kubernetes](https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kanister-application-level-data-operations-on-kubernetes/)
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
[Day 89](day89.md)에서 봐요!
|
||||
221
2022/ko/Days/day89.md
Normal file
221
2022/ko/Days/day89.md
Normal file
@ -0,0 +1,221 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Disaster Recovery - Day 89'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Disaster Recovery
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048718
|
||||
---
|
||||
|
||||
## 재해 복구
|
||||
|
||||
장애 시나리오에 따라 복구 요구 사항이 어떻게 달라지는지 이미 언급했습니다. 화재, 홍수, 피의 시나리오의 경우 대부분 재해 상황으로, 워크로드를 완전히 다른 위치에서 가능한 한 빨리 가동하거나 최소한 복구 시간 목표(RTO)를 거의 0에 가깝게 설정해야 할 수 있습니다.
|
||||
|
||||
이는 전체 애플리케이션 스택을 standby 환경으로 복제하는 작업을 자동화할 때만 대규모로 달성할 수 있습니다.
|
||||
|
||||
이를 통해 클라우드 리전, 클라우드 제공업체 간 또는 온프레미스와 클라우드 인프라 간에 빠른 페일오버를 수행할 수 있습니다.
|
||||
|
||||
지금까지의 주제에 따라 몇 세션 전에 배포하고 구성한 Minikube 클러스터를 사용하여 Kasten K10을 사용하여 이를 달성하는 방법에 대해 집중적으로 살펴보겠습니다.
|
||||
|
||||
그런 다음 이론상 어느 위치에서나 standby 클러스터 역할을 할 수 있는 또 다른 Minikube 클러스터를 Kasten K10을 설치하여 생성할 것입니다.
|
||||
|
||||
Kasten K10은 또한 실행 중인 Kubernetes 클러스터에 문제가 발생할 경우 카탈로그 데이터를 복제하여 새 클러스터에서 사용할 수 있도록 하는 기능을 내장하고 있습니다. [K10 재해 복구](https://docs.kasten.io/latest/operating/dr.html).
|
||||
|
||||
### K10에 오브젝트 스토리지 추가
|
||||
|
||||
가장 먼저 해야 할 일은 백업을 위한 대상 위치로 오브젝트 스토리지 버킷을 추가하는 것입니다. 이것은 오프사이트 위치 역할을 할 뿐만 아니라 복구할 재해 복구 소스 데이터로도 활용할 수 있습니다.
|
||||
|
||||
지난 세션에서 Kanister 데모를 위해 생성한 S3 버킷을 정리했습니다.
|
||||
|
||||
|
||||
|
||||
포트 포워딩을 통해 K10 대시보드에 접속하고 새 터미널을 열어 아래 명령을 실행합니다:
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Kasten 대시보드는 `http://127.0.0.1:8080/k10/#/`에서 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
대시보드로 인증하려면 이제 다음 명령으로 얻을 수 있는 토큰이 필요합니다.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
이제 이 토큰을 가져와 브라우저에 입력하면 이메일과 회사 이름을 입력하라는 메시지가 표시됩니다.
|
||||
|
||||
|
||||
|
||||
그러면 Kasten K10 대시보드에 액세스할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 Kasten K10 대시보드로 돌아왔으므로 location profile을 추가하고 페이지 상단의 "Settings"와 "New Profile"을 선택합니다.
|
||||
|
||||
|
||||
|
||||
아래 이미지에서 이 location profile의 위치를 선택할 수 있는 것을 볼 수 있으며, Amazon S3를 선택하고 민감한 액세스 자격 증명, 지역 및 버킷 이름을 추가할 것입니다.
|
||||
|
||||
|
||||
|
||||
새 프로필 생성 창을 아래로 스크롤하면 S3 Object Lock API를 활용하는 변경 불가능한 백업도 활성화할 수 있다는 것을 알 수 있습니다. 이 데모에서는 이 기능을 사용하지 않겠습니다.
|
||||
|
||||
|
||||
|
||||
"Save Profile"을 누르면 아래와 같이 새로 생성되거나 추가된 location profile을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
### pacman 앱을 오브젝트 스토리지에 보호하는 정책 만들기
|
||||
|
||||
이전 세션에서는 pacman 애플리케이션의 임시 스냅샷만 만들었으므로 애플리케이션 백업을 새로 생성한 오브젝트 스토리지 위치로 전송하는 백업 정책을 만들어야 합니다.
|
||||
|
||||
대시보드로 돌아가서 정책 카드를 선택하면 아래와 같은 화면이 표시됩니다. "Create New Policy"를 선택합니다.
|
||||
|
||||
|
||||
|
||||
먼저 정책에 유용한 이름과 설명을 지정할 수 있습니다. 또한 on-demand로 사용하는 데모 용도로 백업 빈도를 정의할 수도 있습니다.
|
||||
|
||||
|
||||
|
||||
다음으로 스냅샷 내보내기를 통해 백업을 활성화하여 데이터를 location profile로 내보내려고 합니다. location profile이 여러 개 있는 경우 백업을 전송할 위치를 선택할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
다음으로 이름 또는 레이블로 애플리케이션을 선택하는데, 저는 이름과 모든 리소스를 기준으로 선택하겠습니다.
|
||||
|
||||
|
||||
|
||||
고급 설정에서는 이 중 어떤 것도 사용하지 않을 것이지만, 어제 작성한 [Kanister 사용법](https://github.com/MichaelCade/90DaysOfDevOps/blob/main/Days/day88.md)에 따라 Kasten K10의 일부로 Kanister를 활용하여 데이터의 애플리케이션 일관된 사본을 가져올 수 있습니다.
|
||||
|
||||
|
||||
|
||||
마지막으로 "Create Policy"을 선택하면 이제 정책 창에서 정책을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
생성된 정책의 맨 아래에는 "Show import details"가 있는데, standby 클러스터로 import하기 위해서는 이 문자열이 필요합니다. 지금은 안전한 곳에 복사하세요.
|
||||
|
||||
|
||||
|
||||
계속 진행하기 전에 "run once"을 선택하여 개체 스토리지 버킷으로 백업을 전송하기만 하면 됩니다.
|
||||
|
||||
|
||||
|
||||
아래 스크린샷은 데이터 백업 및 내보내기가 성공적으로 완료된 것을 보여드리기 위한 것입니다.
|
||||
|
||||
|
||||
|
||||
### 새 MiniKube 클러스터 생성 및 K10 배포
|
||||
|
||||
그런 다음 두 번째 Kubernetes 클러스터를 배포해야 하며, OpenShift를 포함하여 지원되는 모든 버전의 Kubernetes가 될 수 있지만 교육용으로는 다른 이름의 무료 버전의 MiniKube를 사용하겠습니다.
|
||||
|
||||
`minikube start --addons volumesnapshots,csi-hostpath-driver --apiserver-port=6443 --container-runtime=containerd -p standby --kubernetes-version=1.21.2`를 사용하여 새 클러스터를 생성할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
그리고 다음을 사용하여 이 클러스터에 Kasten K10을 배포할 수 있습니다:
|
||||
|
||||
`helm install k10 kasten/k10 --namespace=kasten-io --set auth.tokenAuth.enabled=true --set injectKanisterSidecar.enabled=true --set-string injectKanisterSidecar.namespaceSelector.matchLabels.k10/injectKanisterSidecar=true --create-namespace`
|
||||
|
||||
이 작업에는 시간이 걸리겠지만, 그동안 `kubectl get pods -n kasten-io -w`를 사용하여 pod가 실행 상태가 되는 진행 상황을 확인할 수 있다.
|
||||
|
||||
Minikube를 사용하고 있기 때문에 import 정책을 실행할 때 애플리케이션이 실행되며, 이 standby 클러스터에서 스토리지 클래스가 동일하다는 점에 주목할 필요가 있다. 그러나 마지막 세션에서 다룰 내용은 이동성과 변환입니다.
|
||||
|
||||
pod가 가동되고 실행되면 다른 클러스터에서 이전 단계에서 수행한 단계를 따를 수 있습니다.
|
||||
|
||||
포트 포워딩을 통해 K10 대시보드에 액세스하고 새 터미널을 열어 아래 명령을 실행합니다.
|
||||
|
||||
`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`
|
||||
|
||||
Kasten 대시보드는 `http://127.0.0.1:8080/k10/#/`에서 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
대시보드로 인증하려면 이제 다음 명령으로 얻을 수 있는 토큰이 필요합니다.
|
||||
|
||||
```Shell
|
||||
TOKEN_NAME=$(kubectl get secret --namespace kasten-io|grep k10-k10-token | cut -d " " -f 1)
|
||||
TOKEN=$(kubectl get secret --namespace kasten-io $TOKEN_NAME -o jsonpath="{.data.token}" | base64 --decode)
|
||||
|
||||
echo "Token value: "
|
||||
echo $TOKEN
|
||||
```
|
||||
|
||||
|
||||
|
||||
이제 이 토큰을 가져와 브라우저에 입력하면 이메일과 회사 이름을 입력하라는 메시지가 표시됩니다.
|
||||
|
||||
|
||||
|
||||
그러면 Kasten K10 대시보드에 액세스할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
### pacman을 새로운 Minikube 클러스터로 import
|
||||
|
||||
이제 해당 standby 클러스터에서 import 정책을 생성하고 개체 스토리지 백업에 연결하여 어떤 모양과 방식으로 가져올지 결정할 수 있습니다.
|
||||
|
||||
먼저, 앞서 다른 클러스터에서 살펴본 location profile을 추가하고, 여기에 다크 모드를 표시하여 프로덕션 시스템과 DR standby location의 차이를 보여줍니다.
|
||||
|
||||
|
||||
|
||||
이제 대시보드로 돌아가서 정책 탭으로 이동하여 새 정책을 생성합니다.
|
||||
|
||||
|
||||
|
||||
아래 이미지에 따라 import 정책을 만듭니다. 완료되면 정책을 만들 수 있습니다. 여기에는 import 후 복원하는 옵션이 있으며, 일부 사용자는 이 옵션을 원할 수 있으며, 이 옵션은 완료되면 standby 클러스터로 복원됩니다. 또한 복원할 때 애플리케이션의 구성을 변경할 수 있으며, 이는 [day 90](day90.md)에 문서화한 내용입니다.
|
||||
|
||||
|
||||
|
||||
on demeand import를 선택했지만 언제 import를 수행할지 일정을 설정할 수 있습니다. 이 때문에 한 번 실행하겠습니다.
|
||||
|
||||
|
||||
|
||||
아래에서 성공적인 import 정책 작업을 확인할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 대시보드로 돌아가서 애플리케이션 카드로 이동하면 아래에 "Removed" 아래에 표시되는 드롭다운을 선택하면 여기에 애플리케이션이 표시됩니다. 복원을 선택합니다.
|
||||
|
||||
|
||||
|
||||
여기에서 사용 가능한 복원 지점을 확인할 수 있습니다. 이것은 기본 클러스터에서 pacman 애플리케이션에 대해 실행한 백업 작업입니다.
|
||||
|
||||
|
||||
|
||||
다음 세션에서 더 자세히 다루고자 하므로 기본값은 변경하지 않겠습니다.
|
||||
|
||||
|
||||
|
||||
"Restore"을 누르면 확인 메시지가 표시됩니다.
|
||||
|
||||
|
||||
|
||||
아래에서 standby 클러스터에 있는 것을 확인할 수 있으며, pod를 확인하면 실행 중인 애플리케이션이 있는 것을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 포트 포워딩을 할 수 있습니다.(real-life/프로덕션 환경에서는 애플리케이션에 액세스하기 위해 이 단계가 필요하지 않으며, ingress를 사용할 것입니다).
|
||||
|
||||
|
||||
|
||||
다음으로 애플리케이션 이동성 및 변환에 대해 살펴보겠습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [Kubernetes Backup and Restore made easy!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes Backups, Upgrades, Migrations - with Velero](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [Disaster Recovery vs. Backup: What's the difference?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam Portability & Cloud Mobility](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
[Day 90](day90.md)에서 봐요!
|
||||
127
2022/ko/Days/day90.md
Normal file
127
2022/ko/Days/day90.md
Normal file
@ -0,0 +1,127 @@
|
||||
---
|
||||
title: '#90DaysOfDevOps - Data & Application Mobility - Day 90'
|
||||
published: false
|
||||
description: 90DaysOfDevOps - Data & Application Mobility
|
||||
tags: 'devops, 90daysofdevops, learning'
|
||||
cover_image: null
|
||||
canonical_url: null
|
||||
id: 1048748
|
||||
---
|
||||
|
||||
## 데이터 및 애플리케이션 이동성
|
||||
|
||||
90DaysOfDevOps 챌린지 90일 차! 이번 마지막 세션에서는 데이터와 애플리케이션의 이동성에 대해 다뤄보겠습니다. 특히 Kubernetes에 초점을 맞출 예정이지만, 플랫폼 간 및 플랫폼 전반의 요구사항은 계속 증가하는 요구사항이며 현장에서 볼 수 있는 것입니다.
|
||||
|
||||
"워크로드, 애플리케이션 및 데이터를 한 위치에서 다른 위치로 이동하고 싶다"는 사용 사례는 비용, 위험 또는 비즈니스에 더 나은 서비스를 제공하기 위한 것 등 여러 가지 이유가 있을 수 있습니다.
|
||||
|
||||
이 세션에서는 워크로드를 가지고 한 클러스터에서 다른 클러스터로 Kubernetes 워크로드를 이동하는 방법을 살펴보되, 이 과정에서 대상 위치에서 애플리케이션이 있는 방식을 변경할 것입니다.
|
||||
|
||||
여기에는 [재해 복구](day89.md)에서 겪었던 많은 특징이 사용됩니다.
|
||||
|
||||
### **요구 사항**
|
||||
|
||||
현재 Kubernetes 클러스터로는 수요를 감당할 수 없고 비용이 천정부지로 치솟고 있기 때문에 프로덕션 Kubernetes 클러스터를 다른 퍼블릭 클라우드에 위치한 재해 복구 위치로 이전하여 확장 기능을 제공하면서도 더 저렴한 요금으로 운영하고자 하는 비즈니스 결정이 내려졌습니다. 또한 대상 클라우드에서 사용할 수 있는 일부 기본 클라우드 서비스를 활용할 수도 있습니다.
|
||||
|
||||
현재 미션 크리티컬 애플리케이션(Pac-Man)에 데이터베이스(MongoDB)가 있고 느린 스토리지에서 실행되고 있는데, 더 빠른 새로운 스토리지 계층으로 옮기고 싶습니다.
|
||||
|
||||
현재 Pac-Man(NodeJS) 프론트엔드는 확장이 잘되지 않으며, 새로운 위치에서 사용 가능한 pod의 수를 늘리고 싶습니다.
|
||||
|
||||
### IT팀에 문의하기
|
||||
|
||||
간략하게 설명했지만, 실제로는 이미 재해 복구 Kubernetes 클러스터에 임포트한 상태입니다.
|
||||
|
||||
가장 먼저 해야 할 일은 재해 복구 테스트를 위해 89일에 수행한 복원 작업을 제거하는 것입니다.
|
||||
|
||||
"standby" Minikube 클러스터에서 `kubectl delete ns pacman`을 사용하여 이 작업을 수행할 수 있다.
|
||||
|
||||
|
||||
|
||||
시작하려면 Kasten K10 대시보드로 이동하여 애플리케이션 카드를 선택합니다. 드롭다운에서 "Removed"을 선택합니다.
|
||||
|
||||
|
||||
|
||||
그러면 사용 가능한 복원 지점 목록이 표시됩니다. 여기에는 미션 크리티컬 데이터가 포함되어 있으므로 사용 가능한 지점을 선택합니다. (이 예에서는 복원 지점이 하나만 있습니다.)
|
||||
|
||||
|
||||
|
||||
재해 복구 프로세스를 작업할 때는 모든 것을 기본값으로 두었습니다. 그러나 애플리케이션을 변환해야 하는 재해 복구 프로세스가 있는 경우 이러한 추가 복원 옵션을 사용할 수 있습니다. 이 경우 스토리지와 복제본 수를 변경해야 합니다.
|
||||
|
||||
|
||||
|
||||
"Apply transforms to restored resources" 옵션을 선택합니다.
|
||||
|
||||
|
||||
|
||||
수행하려는 변환에 대한 두 가지 기본 제공 예제가 요구 사항에 필요한 것입니다.
|
||||
|
||||
|
||||
|
||||
첫 번째 요구 사항은 기본 클러스터에서는 `csi-hostpath-sc`라는 스토리지 클래스를 사용했지만, 새 클러스터에서는 `standard`를 사용하고자 하는 것이므로 여기서 변경을 수행할 수 있습니다.
|
||||
|
||||
|
||||
|
||||
이제 하단의 변형 만들기 버튼을 누르세요.
|
||||
|
||||
|
||||
|
||||
다음 요구 사항은 pacman 프론트엔드 배포를 "5"로 확장하는 것입니다.
|
||||
|
||||
|
||||
|
||||
이 과정을 잘 따라가셨다면 아래와 같이 두 가지 transform을 모두 보실 수 있을 것입니다.
|
||||
|
||||
|
||||
|
||||
이제 아래 이미지에서 아래 나열된 모든 아티팩트를 복원할 것임을 알 수 있으며, 원한다면 복원하려는 대상을 더 세분화할 수도 있습니다. "Restore" 버튼을 누릅니다.
|
||||
|
||||
|
||||
|
||||
다시 한번 작업을 확인하라는 메시지가 표시됩니다.
|
||||
|
||||
|
||||
|
||||
마지막으로 터미널로 돌아가서 클러스터를 살펴보면, 이제 pacman pod에 대해 5개의 pod가 있고 스토리지 클래스가 표준 대 csi-hostpath-sc로 설정된 것을 볼 수 있습니다.
|
||||
|
||||
|
||||
|
||||
변환을 통해 다양한 옵션을 얻을 수 있습니다. 마이그레이션뿐만 아니라 재해 복구, 테스트 및 개발 유형 시나리오 등에도 적용할 수 있습니다.
|
||||
|
||||
### API 및 자동화
|
||||
|
||||
API를 활용하여 이러한 작업 중 일부를 자동화하는 기능에 대해서는 언급하지 않았지만, 이러한 옵션은 존재하며 UI 전체에 걸쳐 일부 이동 경로가 자동화 작업에 API를 활용할 수 있는 명령 집합을 제공합니다.
|
||||
|
||||
Kasten K10에서 주목해야 할 중요한 점은 배포 시 Kubernetes 클러스터 내부에 배포된 다음 Kubernetes API를 통해 호출할 수 있다는 것입니다.
|
||||
|
||||
이것으로 데이터 저장 및 보호에 관한 섹션을 마무리하겠습니다.
|
||||
|
||||
## 자료
|
||||
|
||||
- [쿠버네티스 백업과 복원이 쉬워졌다!](https://www.youtube.com/watch?v=01qcYSck1c4&t=217s)
|
||||
- [Kubernetes 백업, 업그레이드, 마이그레이션 - Velero와 함께](https://www.youtube.com/watch?v=zybLTQER0yY)
|
||||
- [7가지 데이터베이스 패러다임](https://www.youtube.com/watch?v=W2Z7fbCLSTw&t=520s)
|
||||
- [재해 복구와 백업: 차이점은 무엇인가요?](https://www.youtube.com/watch?v=07EHsPuKXc0)
|
||||
- [Veeam 이동성 및 클라우드 이동성](https://www.youtube.com/watch?v=hDBlTdzE6Us&t=3s)
|
||||
|
||||
### **Closing**
|
||||
|
||||
이 챌린지를 마무리하면서, 정보가 항상 관련성이 있는지 확인하기 위해 계속해서 피드백을 요청하고 싶습니다.
|
||||
|
||||
또한 데브옵스 주제와 관련하여 미처 다루지 못했거나 더 깊이 파고들지 못한 많은 주제가 있다는 점에 감사드립니다.
|
||||
|
||||
이는 내년에 이 챌린지를 다시 시도하여 90일 분량의 콘텐츠와 워크스루를 다시 만들 수 있다는 것을 의미합니다.
|
||||
|
||||
### 다음은 무엇인가요?
|
||||
|
||||
우선, 잠시 글쓰기를 쉬면서 2022년 1월 1일에 이 챌린지를 시작해서 2022년 3월 31일 19시 50분(BST)에 마쳤습니다! 슬로건이었죠. 하지만 제가 오랫동안 말하고 말했듯이이 콘텐츠가 한 사람에게 도움이 된다면 항상 공개적으로 배울 가치가 있습니다!
|
||||
|
||||
앞으로 이 콘텐츠를 어디로 가져갈지에 대한 몇 가지 아이디어가 있는데, 이 콘텐츠가 깃허브 저장소 외에 다른 곳에서 활용될 수 있기를 바라며 전자책이나 실제 책으로도 제작하는 것을 검토해 볼 수 있기를 바랍니다.
|
||||
|
||||
그런 일이 일어나기 전에 각 게시물을 다시 살펴보고 모든 것이 문법적으로 올바른지 확인해야 한다는 것도 알고 있습니다. 마크다운을 인쇄물이나 전자책으로 만드는 방법에 대해 알고 계신 분이 있다면 피드백을 주시면 감사하겠습니다.
|
||||
|
||||
언제나 그렇듯이 이슈와 홍보를 계속 보내주시기 바랍니다.
|
||||
|
||||
Thanks!
|
||||
@MichaelCade1
|
||||
|
||||
- [GitHub](https://github.com/MichaelCade)
|
||||
- [Twitter](https://twitter.com/MichaelCade1)
|
||||
Loading…
Reference in New Issue
Block a user