안녕하세요.

developer commit
형상&버전관리 - gitlab

build / test / package - jenkins : gitlab에 있는 소스를 불러와서 build하고 test하고 package 한다. 단위test 통과 못하면 fail되어 개발자에게 알람. 단위테스트 통과하면 dev&prod서버에 배포 진행

정적테스트 및 분석 : 소나큐브

IaC, 빌드된 결과물을 운영환경에 배포 : ansible

운영환경 : 쿠버네티스

이런 일련의 과정을 CI/CD 파이프라인

젠킨스 설치는 도커 컴포즈로 젠킨스 플러그인 전체 설치

jenkins-item이란 : 작업(빌드,배포)최소단위

jenkins git plugin 설치

아이템별 git 레포 설정

jenkins maven plugin 설치

메이븐으로 컴파일 - clean compile package

jenkins > docker 방법

1) publish over SSH

S3란 스토리지 서비스

- 안전하고 가변적인 Object 저장공간을 제공 (ex 구글 클라우드 드라이브, 네이버 클라우드 드라이브)

- 편리한 UI 인터페이스를 통해 어디서나 쉽게 데이터를 저장하고 불러올 수 있음

- 파일 크기는 0KB부터 5TB까지 지원

- 저장공간 무제한

- Bucket 이라는 이름을 사용함(디렉토리와 유사)

- Bucket 은 보편적인 namespace를 사용 : 버킷 이름은 고유해야한다. 리전 상관없이(글로벌설정임)하나의 버킷은 모든 리전에서 고유해야함.

S3 object의 구성요소

- Key
- Value

- Version ID

- Metadata

- CORS(Cross Origin Resource Sharing) : 한 버킷의 파일을 다른 버킷에서 접근되도록 해주는 기능(리전 달라도 가능)

S3 Data Consistency Model

 - Read after Write Consistency(put) : 파일 업로드시 딜레이없이 바로 사용 가능
- Eventual Consistency(update, delete) : 버킷에 올라간 파일을 update&delete시 결과가 바로 나타나지 않는다. 다만 S3 내부에서는 적용돼있음?

S3 스토리지 타입

 - 일반 S3 : 가장 보편적으로 사용되는 스토리지 타입. 높은내구성과 가용성

 - S3 - IA(Infrequent Access) : 자주 접근되지는 않으나 빠른 접근이 요구되는 파일이 많을시 유용, 일반 S3에 비해 비용은 저렴하나 접근시 추가 비용 발생. 멀티 AZ를 통한 데이터 저장으로 가용성이 높음

 - S3 One Zone IA : 단일 AZ에 저장. 상대적으로 낮은 가용성. 데이터 접근시 S3-IA보다 20프로 비용 저렴

 - Glacier : 거의 접근하지 않을 데이터 저장시 유용. 매우 저렴한 비용. 데이터 접근시 대략 4-5시간 소요

 - Intelligent Tiering : 데이터 접근 주기가 불규칙할때 매우 유용, 2가지 티어 존재[Frequent Tier / Infrequent Tier]. 데이터 접근주기에 따라 두가지 티어중 하나로 선택됨. Frequent Tier가 비용이 더 비쌈. 최고의 비용 절감 효율을 누릴 수 있음

rds는 AWS의 RDBMS 서비스

RDS 백업의 종류

Automated Backups (자동 백업)

1. Retention period(Point in TIme) - 1~35일 안의 어떤 시간으로 돌아가게 할 수 있음

2. AB는 그날 생성된 스냅샷과 Transaction logs(TL)을 참고함

3. 디폴트로 AB기능이 설정되어 있으며 백업정보는 S3에 저장. RDS 용량 만큼만 S3 무료제공, 그 이상되면 과금

4. AB동안 약간의 I/O suspension이 존재할 수 있음 > Latency

DB snapshots (데이터베이스 스냅샷)

1. 주로 사용자에 의해 실행됨

2. 원본 RDS instance를 삭제해도 스냅샷은 존재함. 즉 스냅샷만으로도 RDS 인스턴스 복원가능

DB restore할 경우

새로운 객체가 생성됨. 

Multi AZ 

 - 원래 존재하는 RDS DB에 무언가 변화(write)가 생길 때 다른 AZ에 똑같은 복제본이 만들어짐

 - AWS에 의해 자동으로 관리가 이루어짐

 - 원본 RDS DB에 문제가 생길 시 자동으로 다른 AZ의 복제본이 사용됨

 - DR 용

 - Multi AZ는 성능 개선용이 아님. 성능 개선은 Read Replica를 써야함

Read Replicas(RR)

 - 읽기전용 복제본이 생성됨(mysql replcation이라 생각하면 됨)

 - read가 많으면 read replica 사용하면 됨( 스케일아웃가능)

 - 이건 DR용도가 아님

 - 최대 5개까지 RR 가능 - 다만 RR DB의 RR을 다시 생성가능(단 latency 발생) 이럼 무제한 ?

 - 각각의 RR은 자기만의 고유 endpoint 존재 - 아이피로 구분하지 않음

ElasticCache

 - 클라우드 내에 In-memory 캐싱디비

 - 데이터베이스에서 데이터를 읽어오는것이 아니라 캐시에서 빠른 속도로 데이터를 읽어옴

 - Read-Heavy 어플리케이션에서 상당한 Latency 감소 효과

엘라스틱캐시는 2개 타입으로 나뉨 Memcached / Redis

Memcached

 - Object 캐싱 시스템

 - Elastic cache는 Memcached의 프로토콜을 디폴트로 따름

 - 오토 스케일링 가능

 - 오픈소스

 - 단순한 캐싱 모델

Redis

 - Key-Value, set, list와 같은 형태의 데이터를 In memory 캐싱 모델

 - 오픈소스

 - Multi AZ 지원(DR 가능)

 - 리더보드처럼 데이터셋의 랭킹을 정렬하는 용도

---------실습------------

RDS 생성 - mysql 생성

1.버전 선택(디폴트)

2.탬플릿

프로덕션, 개발/테스트, 프리티어 > 선택

PS. 오로라는 프리티어 없음.

3.인스턴스 식별자 - AWS RDS 인스턴스 이름

4.마스터(root) 사용자 이름/ 암호 생성

5.DB 인스턴스 크기 > 디폴트 선택(프리티어니까)

6.스토리지 유형, 용량 > 디폴트

7.스토리지 자동조정이란 오토스케일링이고 디폴트는 활성화

8.가용성 및 내구성이란 멀티 AZ. 프리티어는 멀티 AZ 사용 못함

9.VPC 연결

10.추가 연결 구성. RDS인스턴스의 접근 허용여부. 퍼블릭 엑세스 디폴트 아니오.

11.VPC의 새로운 보안그룹 생성 해야함 ?

12. 가용영역 설정은 뭐하는거지 ? 자동설정 아니였나 ?

Read replicas 생성( 읽기전용 복제본 생성)

1.네트워크 및 보안

ㄴ완전히 다른 지역으로 복제본 생성 

ㄴ혹은 다른 서브넷 그룹

퍼블릭 액세스 (외부 공개 여부)

2.암호화 : 원본 데이터베이스를 암호화하지 않아도 RR의 암호화를 가능하게 해줌

3.모니터링 : RR의 로그 정보를 Cloud watch에 보낼지에 대한 설정

Multi AZ 

1.수정후 다중 AZ 배포 활성화(예)