[AWS] 마이크로 서비스

(모듈 1-a) AWS 기반 마이크로 서비스의 개요

(모듈 1-b) 컨테이너와 Docker

(모듈 2) 컨테이너 기반 마이크로 서비스의 지속적 전달

(모듈 3) Amazon Elasitc Container Service를 통한 고가용성 및 확장성

(모듈 4) 컨테이너 기반 마이크로 서비스의 보안

 

(모듈 1-a) AWS 기반 마이크로 서비스의 개요

 

*모놀리스

- 올인원 (하나의 프로세스, 하나의 애플리케이션, 하나의 프로젝트)

- 데이터 액세스 로직

- 비즈니스 로직

- 프레젠테이션 구성 요소

- 애플리케이션 통합 로직

 

*모놀리스 단점

- 코드 유지 관리가 어려움

- 테스트가 어려움

- 전체 시스템을 확장해야 함

- 재사용할 수 없음

- 확장 팀의 부담이 큼

 

*마이크로 서비스 정의

- 한정된 컨텍스트를 갖는

- 느슨하게 결합된 (로드발란서, 큐서버)

- 요소들로 구성된

- 서비스 지향

- 아키텍쳐

 

*마이크로 서비스 속성

- 미니멀

- 독립적 (데이터 레이어까지)

- 탄력적

- 복원성

- 구성 요소 기반

- 기술에 구애받지 않음

- 독립적인 반복 파이프라인

- 더 나은 통찰력

 

*마이크로 서비스 장점

- 기능을 개별 구성 요소로 분할

- 반복할 파트가 더 작아짐

- 테스트할 영역 축소

- 변경에 따른 위험 감소

- 수평적으로 확장 가능

 

*마이크로 서비스 구조

- 데이터 스토어 (데이터도 분리한다. SOA와 다른 점)

- 애플리케이션/로직

 

*개발 프로세스 측정 (생산성, 비즈니스 생존에 중요한 요건)

- 수천 개의 팀

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

- 지속적 배포

- 다양한 개발 환경

 

*마이크로 서비스의 6원칙

- (1) 퍼블릭 API에만 의존한다. (데이터를 숨긴다, API를 기록한다. 버전 관리 전략을 정의한다.)

- (2) 해당 작업에 적합한 도구를 사용한다. (ployglot framework: 다중 언어 코드 프레임워크, polyglot persistence: 다중 언어 코드 지속성)

- (3) 서비스를 보호한다. (심층 방어, 인증/권한 부여)

- (4) 훌륭한 시민이 된다. (레이턴시 등의 정보를 제공한다. 네트워크의 안정성을 위해, [a]분산 모니터링 및 추적, [b]공유 메트릭, [c]분산 추적, [d]사용자 경험 메트릭)

- (5) 기술 혁신 이상이어야 한다. (목표에 집중하는 소규모 개발팀 선호)

- (6) 모든 것을 자동화한다. (DevOps 채택)

 

(모듈 1-b) 컨테이너와 Docker

 

*ECS vs EKS

https://timewizhan.tistory.com/entry/AWS-ECS-vs-EKS

[AWS] ECS vs EKS

*VM

- 가상 하드웨어 기술

 

*컨테이너

- 가상 OS 기술

 

*이미지

- 패키징 기술

 

*네임스페이스 유형(격리)

- User 네임스페이스

- UTS 네임스페이스

- IPC 네임스페이스

- Mount 네임스페이스 (공유 가능)

- PID 네임스페이스

- Network 네임스페이스

 

*가상머신 vs 컨테이너

- 제한된 성능 vs 네이티브 성능

- 하드웨어 수준의 가상화 vs 운영체제 가상화

- 리소스 사용이 높다 vs 가상머신보다 리소스 사용이 적다

- 프로비저닝이 느리다 vs 거의 리얼타임 프로비저닝과 확장성을 제공

- 리소스 사용이 높다 vs 가상머신보다 리소스 사용이 적다

- 가상머신 간 완전한 격리로 인한 완전한 격리 가능 vs

 

*Docker 구성 요소

- Hub (레지스트리)

- 이미지

- 컨테이너

- 명령어

- Dockerfile

 

*Docker 구성 요소

- 자체 레지스트리 만들어야 한다. (Hub는 해킹 위험)

- Registry + Repository + Tag(tag 안 넣어주면 latest, latest를 미리 만들어놔야 한다. 항상 tag를 넣어줘야 한다.) 

 

*docker 레지스트리

- 컨테이너 이미지 저장소로 어디서든 이미지를 배포하기 위한 도구

 

*이미지 배포를 위한 저장소 유형

- Hub 레지스트리

- 프라이빗 레지스트리

 

*레지스트리 구성요소

- 레지스트리

- 레포지토리

- 인덱스

 

*레포지토리

- 동일한 이름의 다른 태그로 이루어진 여러 docker 이미지들의 콜렉션 네임스페이스

- 레지스트리는 일반적으로 여러 레포지토리를 호스트한다.

 

*ECR 구성요소

- 레지스트리

- 레포지토리

- 레포지토리 정책

 

*컨테이너는 휘발성

 

*ECR 구성요소

- 레지스트리

 

docker rmi ubuntu

sudo ls -l /var/lib/docker/

sudo ls -l /var/lib/docker/overlay2

docker run -it ubuntu

mkdir /test

docker ps -a

docker commit [Container ID]

docker run -it ubuntu ls /

docker run -it ubuntu:v1 ls /

docker run -it ubuntu

 

 

*PID, PPID

- PID 1번

 

*이미지 레이어

*이미지 관리팀

 

*dockerfile

 

*nginx

 

*컨테이너 유형

- OS 컨테이너

- APP 컨테이너

 

docker ntework ls

 

*네트워크 모드

- 브릿지

- 호스트

- awsvpc

- 없음

 

*호스트 port 충돌

 

*Fargate

 

*docker 기본 네트워크

- docker 설치시 자동으로 생성되는 기본 네트워크

 

*ECS

 

*docker, host, cluster, node, controlla, master, slave(node, worker)

*API, API server, REST API, 스켸쥴러

*desired number, current status

 

*ECS 작업 배치

- 작업 배치 전략

- 작업 배치 제약

 

*ECS

- 클러스터

- 작업 정의

- 작업

- 서비스

- 스케쥴러

- 컨테이너 에이전트

 

*daemon

*서비스 daemon도 컨테이너

 

docker info

docker ps -a

curl -s localhost:51678

 

*fargate

 

*ECS 작업 정의

- 클러스터 템플릿 선택

- Task Definition

 

*ECS 작업 정의의 파라미터

 

*docker.com

 

*ECS 작업 정의 예

 

*ECS awsvpc

- ENI 트렁킹 사용 조건

 

*Task vs Service

- Load Balancer 통합 : full integration vs no integration

 

*Fargate와 EC2모드

- 비용 : 작업 단위 vs EC2 인스턴스 단위

- EFS 통합 : No vs 가능

- EBS 통합 : No vs 가능

- 네트워크 : awsvpc vs

 

*Fargate 스팟

- AWS Fargate의 새로운 배포 옵션

- Fargate 요금보다 최대 70% 할인된 금액

- 사용한 vCPU 및 메모리 리소스 양에 대해 비용을 지불

- 요금은 초 단위로 계산되며 최소 1분

- Compute Savings Plans 활용 가능

 

*Fargate에서 유효하지 않은 작업 정의

 

*CLI 작업

*ECR

 

docker build -t forklift .

docker run -dp 8000:8000 forklift

=> -p는 컨테이너의 8000번 포트를 호스트 상의 8000번 포트에 연결한다는 뜻

=> -d는 docker에게 분리모드에서 실행하도록 명령

 

docker compose로 컨테이너들을 결합하여 컨테이너들이 서로 협력하도록 하는 방법

 

docker build -t mustacheme:base .

docker-compose up -d

 

amazon ECR을 docker 이미지용 리파지토리 장소로 활용하는 방법

Elastic Container Registry는 개발자가 이미지를 손쉽게 저장, 관리, 배포할 수 있게 해주는 완전관리형 docker container registry

 

ecs-cli compose

 

(모듈 2) 컨테이너 기반 마이크로 서비스의 지속적 전달

 

*소프트웨어 수명 주기용 AWS 서비스

*파이프라인

*AWS CodePipline

*AWS CodeCommit

 

*Jenkins와 Postman

 

*Jenkins

- java로 작성된 오픈 소스 지속적 통합 도구

- 소프트웨어를 빌드하고 테스트를 실행하는 것과 같은 반복 작업의 실행을 모니터링

- AWS 서비스와 통합된 많은 플러그인을 포함하여 수백 개의 사용 가능한 플러그인을 통해 확장 가능

 

*Postman

*CodePipeline

 

*AWS CloudFormation 템플릿

- 네트워크

- Lambda

- Amazon ECS 클러스터

- Jenkins 서비스

- 전달 파이프라인

- CLI 인스턴스

- 마이크로 서비스 파이프라인

- 마이크로 서비스 스택

 

*디버깅을 위한 amazon cloudwatch 로그

 

*FireLens

- ECS 및 Fargate용 로그 라우터

- Fluentd 및 Fluent Bit

 

*AWS Systems Manager Run Command

 

*Docker 자격 증명 헬퍼

- IAM 역할, 자격 증명 파일 또는 환경 변수로부터 권한을 받는다.

- docker login 명령을 실행할 필요가 없다.

- ECR 사용을 쉽게 해준다.

 

*CloudFormation의 핵심 부분에는 다음 항목이 포함

- Lambda 함수로 내장된 Jenkins 작업을 생성용 "JenkinsBuildJobResource"라는 사용자 정의 CloudFormation 리소스

- 마이크로 서비스와 그 이름이 같은 CodeCommit 리포지토리를 생성하기 위한 CodeCommit 리포지토리 리소스

- Application Load Balancer의 특정 포트에 전송된 트래픽을 마이크로 서비스로 전달하기 위한 Application Load Balancer 리스너 리소스

- 이 마이크로 서비스에 ECS 서비스를 연결하기 위해 ECS가 사용할 Application Load Balancer 타겟 그룹

- CodeCommit 리포지토리를 새로운 git push 명령에서 트리거되는 소스로 포함하고, Jenkins를 빌드 리소스로 포함하며, 마이크로 서비스 ECS 작업 정의를 생성하고 마이크로 서비스를 위한 ECS 서비스를 배포할 AWS Lambda 함수를 포함하는 CodePipeline 리소스

 

(모듈 3) Amazon Elasitc Container Service를 통한 고가용성 및 확장성

- 고가용성

- 클러스터 관리 및 스케쥴링

- 모니터링

- 클러스터 확장

- 서비스 확장

 

*Amazon ECS, 에이전트 통신

*Amazon ECS, 키/값 스토어

*Amazon ECS, API

*Amazon ECS, 스켸쥴링

- 서비스 스케쥴러

- 수동 작업

- cron 같은 예약 기능을 기반으로 작업 실행

 

*Amazon ECS, 작업 배치

- Binpack

- Random

 

*Amazon ECS, 작업 배치 제약

- memberOf

- distinctInstance

 

*Auto Scaling(Container의 workload를 확장)

- 대상 추적 조정 정책

- 단계 조정 정책

- 예약된 조정

 

*Capacity Provider

- 컨테이너의 컴퓨팅 용량을 관리하는 새로운 방법

- 용량 공급자

- 용량 공급자 전략

- 기본 용량 공급자 전략

- ECS 클러스터 Auto Scaling을 활성화하려면 용량 공급자라고 하는 새 ECS 리소스 유형을 생성

- ECS 클러스터에 용량 공급자를 추가하면 클러스터에서 ECS의 2가지 새로운 기능을 사용(관리형 조정, 관리형 인스턴스 종료 보호)

 

*Fargate Capacity Provider

*CLI 작업

 

*스케쥴링 서비스 : 장기 실행 앱

- 최소 정상 상태 백분율 (minimumHealthyPercent)

- 최대 백분율 (maximumPercent)

- 블루/그린 배포

 

*CloudWatch 컨테이너 인사이트

 

*컨테이너 기반 마이크로 서비스에 대한 지속적 전달 파이프라인

 

(모듈 4) 컨테이너 기반 마이크로 서비스의 보안

 

docker run -it ubuntu

 

*CAP_NET_ADMIN

- root 지만 capability 가 없어서 작업 못하게 막을 수 있음

 

docker inspect ubuntu

 

*Docker Bench Test

*Twistlock

*Twistlock Trust

 

*규정 준수 - IAM

- IAM 역할을 사용하여 AWS 리소스에 액세스

- 액세스 및 비밀 키를 보유할 필요가 없음

- 작업별로 세분화된 권한을 정의

 

*규정준수 - 시크릿 관리

- 소스 코드에 시크릿을 기록하지 말아라.

 

*ECS 작업 정의의 보안 파라미터

 

*소스 코드 점검

- Git hook를 사용해 코드를 분석