[AWS] DevOps #4

*Modern Development Map

- Value

- Velocity

- Ownership

- Two Pizza Team (피자 2판으로만으로 점심을 해결할 수 있을 정도의 인원으로 팀을 구성, 최소 3명 이상~20명까지)

- Serverless Architecture

- immutable infrastructure : container 기술(docker)

- high availabilty

- chaos engineering

- cloud computing

- ticket driven development (GIRA사용 : 관리자 입장에서 편함, Github사용: 개발자 입장에서 편함)

- iteration develop process

- time boxing model (http://ecomputernotes.com/software-engineering/timeboxing-model)

- Code Management System

- Code Review

- Domain Driven Design (책 나와 있음)

 

*일을 내가 주도할 수 있느냐 = Ownership

 

*수평적 조직 가능 (한국 사회에서도)

- 반말 금지(모두 다 존대말)

- XXX님

 

*관리자 vs 개발자

- 관리자가 되는게 개발자들의 승진의 대상이 되어서는 안된다.

 

*Manager의 역할

- 궁극적으로는 일이 되게 해야 한다.

 

*테스트와 DevOps

- 끊임없이 변화하는 비즈니스 환경에 대처하는 데는 데브옵스가 효율적인 접근 방식

- 성공적인 데브옵스 = 강력한 CI/CD 파이프라인

- 지속적 테스트가 강력한 CI/CD 파이프라인을 보장

- 데브옵스 문화에서 소프트웨어 제품의 품질은 모두의 품질

 

*테스팅 피라미드

- 유닛

- 서비스/통합/구성 요소

- 성능/규정 준수

- UI

 

*지속적 테스트가 중요한 이유

- 성실하게 이행되는 지속적 테스트는 고효율의 지속적 전달로 이어짐

 

*자동화 테스트 과정에서 직면하는 도전 과제

- 테스트를 위한 서버 확보

- 복수 환경 관리

- 더딘 실험

- 프로덕션 환경과 일치하지 않는 개발 환경

 

*프로덕션 환경 복제가 중요한 이유

- 프로덕션 환경에 부합하는 정확한 테스트 시나리오

- 프로덕션 리소스를 사용한 성능 테스트, 로드 테스트

- 개발자에 실험 권한 위임

- 프로덕션 디버깅 : 용이한 복제/버그 재현

 

*모의 실험(Mocking)의 작동 방식

- 자동화 테스트 서버

- 테스트 중인 애플리케이션 인스턴스

- 모의 서버

- 종속성 모의 실험

 

*CI/CD 파이프라인의 테스트 시나리오

- 지속적 통합

- 지속적 전달/배포

- 개발 -> 빌드 -> 스테이징 -> 프로덕션

- 개발 : 유닛 테스트, 정적 코드 분석

- 빌드 : 통합 테스트, 구성 요소 테스트, 회귀 테스트

- 스테이징 : 시스템 테스트, 성능 테스트, 로드 테스트(어디가 한계인지 테스트), 규정 준수 테스트, UAT

- 프로덕션 : A/B 테스트, 카나리아 분석

 

*유닛 테스트 관련 몇 가지 모범 사례

- 모든 코드 변경 사항에 대한 유닛 테스트를 실시하여 품질을 검증

- 유닛 테스트는 서로 독립성을 유지

- 한 유닛 테스트의 실패가 다른 테스트에 영향을 미치지 않아야 함

- 기능이 구별되는 코드의 작은 부분을 테스트

- 적절한 코드 범위(coverage) 보장

- 빠른 테스트와 빠른 실패

- 화이트 박스 테스트 vs 블랙 박스 테스트(대부분 이게 더 유용함)

 

*유닛 테스트 및 테스트 주도 개발(TDD)

- TDD 접근 방식을 통해 유닛 테스트에서 보다 나은 코드 범위 구현

- TDD의 개념은 코드를 작성하기 전에 자동화된 유닛 테스트를 작성하는 것

- 따라서 처음에는 유닛 테스트 실패가 당연

- 그런 다음 개발자가 테스트에 통과할 수 있도록 코드를 작성

- 필요에 따라 코드 기반 리팩터링

 

*종속성을 지닌 구성 요소/서비스 테스트

- 자동화된 테스트는 신뢰성 없는 종속성 서버로 인해 실패 가능성 존재

- wiremock과 같은 모의 프레임워크를 사용하여 이와 같은 문제를 방지

- 모의 프레임워크는 다음을 위한 라이브러리 제공

- dependency injection 패턴

 

*통합 테스트

- 빅뱅

- 하향식 : GUI부터 시작해서 하위 모듈로 (UI에 민감한 애플리케이션은 이 방식을 사용) 

- 상향식 (대부분 이 방식을 사용)

 

*통합 테스트와 유닛 테스트의 다른 점

- 통합 테스트 : 비용 많이 듬, 아침 + 점심 때 한번 (하루에 텀을 두고 여러 번)

- 유닛 테스트

 

*내결함성 검사

- 업무적으로 중요한 애플리케이션에 권장하는 모범 사례

- 애플리케이션이 코너 케이스(복합 경계 조건)를 어떻게 처리하는지 테스트

- 고의적으로 구성 요소 하나를 제거하여 시스템이 장애로부터 복구하는지 확인

- EC2 인스턴스 하나를 종료하여 EC2 Auto Scaling이 인스턴스를 프로비저닝 하는지 확인

 

*성능 튜닝 기본 사항

- 자체 부하 및 확장 테스트를 수행하는 것보다 좋은 방법은 없다.

- 포괄적인 튜닝 조언을 그대로 따르는 것은 "다른 사람의 약을 복용하는 것과 같다." : Brendan Gregg, Netflix

- 좋은 테스트를 위해서 필요한 것 : 프로덕션과 같은 환경, 적절한 양의 데이터, 여러 사용자, 확장/축소 정책

 

*성능 기준선 설정하기

- 테스트 도구를 사용하여 로드를 생성하고, 성능을 측정하며, 이후의 측정을 위한 기준선을 설정 : Apache Bench, Bees with Machine Guns, J/Meter, Tsung

- 측정에 대한 결정 : 90% 백분위수, 표준 편차, 10/5 규칙

 

*CloudWatch

 

*CloudWatch 경보 및 작업

 

*CloudWatch Event 기반 워크플로

- 사용자 지정 애플리케이션별 지표, CloudWatch를 지원하는 AWS 리소스

 

*CloudWatch 지표 사용

- Elastic Load Balancing (단기간에 400에러가 많이 나면, DDos 공격)

- 인스턴스

- 네트워크

- I/O

- 사용자 지정

 

*A/B 테스트 : 기능 실험별로 사용자 분리 (머신러닝 관련 프로젝트에서는 필수)

 

*인스턴스 유형 테스트

- Netflix : 단일 인스턴스 카나리아 접근 방식

- 특정 유형의 인스턴스를 기존 ELB에 추가하여 수행된 워크로드와 관련된 스트레스와 로드를 측정

- 새로운 인스턴스가 성능이 뛰어난 경우, 트래픽이 새로운 시작 구성의 EC2 Auto Scaling 그룹으로 점신적으로 이동

 

*상태 코드 지표 모니터링

 

*Elastic Load Balancer 최적화

- Amazon EC2 인스턴스 용량을 가용 영역 전체에서 밸런싱

- 사전 워밍은 AWS Support에 문의

- 로드 밸런서 DNS를 캐시하지 말아라 : 트래픽을 균등하게 배분할 수 있도록 자주 다시 확인

- 지연 시간이 짧은 응답 시간을 제공하는 애플리케이션 기반 상태 확인을 구현

- Route 53 별칭 레코드를 로드 밸런서와 함께 사용

- keepalive를 활성화

 

*AWS에서의 성능 테스트 구성 요소

 

*AWS를 사용한 로깅

 

*CloudWatch Logs 사용하기

- 로그 이벤트 (로그 1줄)

- 로그 스트림 (로그 파일 1개)

- 로그 그룹

 

*CloudWatch Logs Insight

 

*CloudTrail을 사용하여 인프라 이벤트 관찰

- 로그 관련해서는 Elasticsearch가 원탑

 

*OpsWorks

 

*AMI 빌드 및 AWS Systems Manager의 핵심 개념

- 마치 하나의 서비스처럼 관리

 

*AMI 및 수명 주기

 

*기본 구성으로 사용자 정의 AMI 사용

- 특정 구성, 사전 설치된 소프트웨어로 기본 AMI 생성

- 사용자 데이터, 구성 소프트웨어를 통한 사용자 정의

 

*AMI 빌드 전략

- AMI 인벤토리 : 뜨는 속도 제일 빠름

- Golden AMI

- JeOS AMI와 레시피 라이브러리(설치 스크립트) : 뜰 때마다 가장 최신의 상태 유지, 뜨는데 시간이 오래 걸림, 인스톨하다가 실패할 수 있어서 안정성이 좀 떨어짐

 

*어떤 접근 방식

- AMI 구성은 연속적으로 이루어지므로 요구 사항에 맞는 균형점을 찾아야 한다

- OS만 구성된 AMI

- 부분 구성된 AMI

- 전체 AMI (빌드할 때 시간이 오래 걸림)

 

*접근 방식 사례(Netflix)

- Linux AMI

- 기초 AMI

- 베이스 AMI

- 애플리케이션 AMI

 

*CodePipeline 및 AWS CodeBuild를 통한 AMI 빌드 자동화

- Packer HashiCorp

 

*AMI 배포 옵션

- 현재 위치 배포(in-place)

- 대체 및 폐기

 

*구성 전략 생성

- 상호 배타적인 구성 기술은 없다.

- 변화가 느린 기본 구성 요소, 회사 차원의 도구 및 표준은 AMI로 베이크

- Netflix Aminator(업데이트 계속 안되고 있음), Packer(지금은 이거 씀)

 

*소프트웨어/OS 패치 관련 문제

- OS 또는 애플리케이션이 매년 패치가 요구되는 새로운 취약점을 나타낼 수 있음

 

*AWS Systems Manager

-시스템 구성을 정의 및 추적하고 Amazon EC2 및 온프레미스 구성이 소프트웨어 규정을 준수하도록 유지 관리할 수 있다.

- Run Command

- State Manager

- 인벤토리

- Maintenace Window

- Patch Manager

- 자동화

- Parameter Store

 

*SSM 에이전트

 

*Patch Manager

- 패치와 관련된 보편적인 문제

- 패치 관리자 사용하는 경우(종단 간 패치, 용이한 자동화)

 

*Patch Manager 워크플로

 

*CLI 명령을 사용한 Patch Manager 워크플로

 

*자동화 워크플로

 

*사전 정의 자동화 문서(Automation Documents)

 

*자동화 문서

- Jenkins CI 서버

 

*AWS Systems Manager Paramter Store

 

*AWS CodeDeploy Parameter Store 이용하기

 

*컨테이너와 VM의 유사성

- 컨테이너는 격리되어 있지만, OS를 공유하고, 해당하는 경우 바이너리/라이브러리도 공유

 

*Docker

- 단일 프로세스 컨테이너

- 상태 비저장

- 이식성

- 마이크로 서비스 아키텍처

- 행복한 개발자

 

*도커 이미지

- 커널

- 기본 이미지

- 이미지(emacs추가)

- 이미지(apache 추가)

- 컨테이너(쓰기 가능)

 

*도커 구성 요소

- 로컬 데몬

- 레지스트리(push, pull)

- Docker Hub(퍼블릭, 프라이빗), 프라이빗 레지스트리

 

*Dockerfile (선언적 이미지)

- dockerfile 형식을 사용하면 linux 유사 명령을 사용하여 새로운 도커 이미지를 생성할 수 있음

 

*Docker 버전 관리

- 버전은 태그를 사용하여 지정

- latest는 가장 최신 버전의 약칭으로 사용

- 태그는 Docker tag 명령을 사용하여 지정

 

*Docker에서의 CI/CD 워크플로

- (1) 데브옵스 엔지니어가 Docker push(인증된 베이스 이미지)

- (2) 개발자가 pull + 마스터로 커밋

- (3) 지속적 통합 서버

 

*Docker의 해결 과제

- 집합(fleet)관리는 어려운 일

- Orchestraion 이라고 함

- AWS는 ECS가 솔루션

 

*Fargate vs EC2

- 완전관리형 인프라 및 조정

- 사용한 CPU 및 메모리 시간에 대해서만 지불

- 인프라에 대한 SSH 액세스 없음

 

*EMR

- Amazon EMR is the industry leading cloud-native big data platform for processing vast amounts of data quickly and cost-effectively at scale

 

*ECS

- 클러스터(EC2)

- 컨테이너

- 에이전트

- 작업정의

 

*ECS(Elastic Container Service) 워크플로

- Dockerfile -> 이미지 생성 -> 컨테이너 이미지 -> 레지스트리에 게시 -> 컨테이너 레지스트리

 

*ECS 작업정의

- 사용할 도커 이미지

- 각 컨테이너에 사용할 CPU 및 메모리

 

*하이퍼쓰레드

- https://donghoson.tistory.com/19

하이퍼 스레딩이란? - (1)

 

*논리코어

- https://qastack.kr/unix/88283/so-what-are-logical-cpu-cores-as-opposed-to-physical-cpu-cores

그렇다면 물리적 CPU 코어와 달리 논리적 CPU 코어는 무엇입니까?

*작업 정의 파라미터

 

*기존의 VM vs 도커

- 논리코어를 독점적으로 사용 vs -쓸때만 사용

 

*ECS 작업 스케줄링

- 작업 및 컨테이너에 대한 유연한 스케줄 관리 기능을 제공

- 장기 실행되는 서비스 및 애플리케이션에 대해 관리 기능을 제공

 

*ECS 작업 배치

- 작업 배치 전략 : 작업 배치 또는 작업 종료를 위한 인스턴스를 선택하는 알고리즘

- 작업 배치 제약 조건 : 작업 배치 동안 적용되는 규칙

 

*작업 배치의 작동 방식

- 클러스터 제약 조건

- 사용자 지정 제약 조건 : 위치, 인스턴스 유형, AMI 또는 사용자 지정 속성 제약 조건

- 배치 전략 : 분산 또는 상자 채우기

- 필터 적용

 

*클러스터 쿼리 언어

- ECS API와의 상호 작용에 사용

- 애플리케이션 배치에 대한 직접적인 제어 권한을 부여하는 강력한 실행 시간 인수 빌드

 

*인스턴스 패밀리 또는 유형 필터링

 

*복수 표현식 필터링

 

*샘플 서비스 정의

 

*ECS 사용자 지정 스케줄러

 

*ECS 이벤트 스트림

 

*Blox

- 몰라도 된다

 

*Elastic Container Registry

- 완전관리형 Docker 컨테이너 레지스트리

- 표준 Docker 도구와 Docker CLI 명령을 사용할 수 있도록 허용

 

*CI/CD 파이프라인

 

*Amazon ECR을 CI 시스템과 통합

- 애플리케이션의 롤링 배포를 지원

 

*보안관리

 

*컨테이너의 런타임 비밀정보

- 컨테이너화 애플리케이션의 비밀정보 : API 키, 암호, 인증서 등과 같은 실행 시의 민감한 정보

- 그와 같은 비밀정보를 처리하는 것은 까다로운 일이며 Docker 컨테이너에 있어 반복적인 문제

- parameter store에 저장

 

*보안 관리에 수반되는 위험

- 환경 변수

 

*S3 및 AWS IAM 정책

- S3 버킷을 사용하여 데이터베이스 자격 증명 저장

- 계층화 접근 방식을 통해 클러스터를 위한 VPC를 생성하여 보안 강화

- S3 엔드포인트를 생성하여 특정 VPC에서 실행되는 리소스만 S3 버킷 콘텐츠에 액세스할 수 있도록 조치

- S3 버킷에 대한 읽기 전용 액세스를 구성하여 저장 및 전송 중에 비밀이 암호화되도록 보장

- IAM 역할을 사용하여 S3 버킷에 대한 액세스 제한 : 개발팀/운영팀 직원은 액세스 권한 없음