2-모듈5 인프라 자동화

모듈 5 목표: 인프라 자동화, 마이크오서비스와 서버리스 아키텍처에 대한 분석에 대해 공부

그리고 이를 통해 인프라의 복원력과 비용 효율성 향상하는 방법을 설명합니다.

1.소결합 시스템의 중요성

2.분산적 성격을 지원하는 시스템 결합의 다각적 측면

애플리케이션 배포 방식의 기초 개념 설명

 

수동 구성 : 결합 해제를 위한 설계 패턴과 계층간 상호 종속성을 줄여야 할 필요성에 대해 배웁니다

수동 구성의 문제점

수동 구성이란? 관리 콘솔을 통해 AWS 서비스와 리소스를 생성하고 구성하는 것

--> 동일한 단계를 수동으로 계속 반복하면 오류가 발생하기 쉽다.

-->사람의 개입이 있기 때문에 여러 실수가 일어난다

 

동일한 구성을 정확히 재현하기 위해서 단계별 구성 지침을 문서화하는 것이 좋다

 

 

모법 사례: 리소스 프로비저닝, 종료, 구성을 자동화

이전 패턴--> 애플리케이션 서버 충돌 -> 관리자에게 수동으로 알리고 시스템 관리자가 수동으로 새 서버 시작

Amazon cloudWatch가 자동으로 충돌을 탐지하는 것이 모범사례이다.

충돌이 탐지 --> 관리자에게 알림 --> 구성이 동일한 새 서버 동시 시작

이 모든 단계를 자동화

 

AWS는 거의 모든 인프라 계층에서 모니터링 및 자동화 도구를 기본 제공한다.

요구의 변화에 따라 인프라가 신속하게 대응할 수 있도록 이러한 리소스를 활용하자!

 

자동화 하지 않는 경우 -->

1.시간이 지나면서 서버의 구성이 달라짐

2.패치 수준도 달라진다

3.필요하지 않은 리소스가 실행되고 있다

4. 사용중인 하드웨어에서 새 업데이트를 테스트하기 어렵다.

5. 문제 해결이 어렵다

 

모범 사례 --> 서버와 그 밖의 구성 요소를 임시로 취급하자

인프라를 하드웨어적으로 생각하지 말자!

소프트웨어적으로 생각하는 사고 방식으로 대하자.

AWS에서 리소스란 --> 매우 간단하게 마이그레이션 가능하다. 따라서 항상 임시 요소라고 생각하고

대하자!

 

코드로 인프라를 정의하는 것!

인프라를 코드로 생각한다! == 소프트웨어 개발의 기술 사례 도구를 재사용, 유지 관리, 확장, 테스트가 

가능한 인프라르 만드는데 적용하는 프로세스

 

인프라를 소프트웨어처럼 구축 및 운영

소프트웨어 구성 --> 소스 코드, 소프트웨어 인터프리터, 원하는 애플리케이션 상태

 

-인프라를 코드로 취급할 때의 이점

1. 반복 가능성

2. 재사용성

템플릿 하나로 복잡한 동일 환경을 반복 구축할 수 있다.

ex)AMI 

 

3. 유지 관리성, 일관성, 병렬화

병렬화를 통해 일관성 향상과 작업 감소 효과

 

AWS CloudFormation을 사용한 AWS 기반 코드형 인프라

AWS CloudFormation을 통해 json or yaml 형식의 템플릿으로 환경 설정 가능

리소스 시작, 구성, 연결에 사용할 템플릿을 이때 이용

• Git 또는 Subversion 등 원하는 버전 제어를 사용하여 코드로 취급하고 관리합니다.

• JSON 템플릿 파일로 전체 애플리케이션 스택(즉, 애플리케이션에 필요한 모든 리소스)을 정의합니다.

• Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 크기, Amazon EC2 키 페어 등 템플릿의 런타임 파라미터를 정의합니다.

 

AWS CloudFormation template 사용 방법

1. Atom or subline Text 등으로 Json 구문 작성

--> 만 AWS Management Console에서 제공하는 자체 CloudFormation Designer 도구를 사용하거나

타사 WYSIWYG 편집기를 사용하여 시각적으로 템플릿을 구축할 수도 있다.

 

2. AWS CloudFormation Designer를 사용

리소스를 디자인 영역에 드래그하여 놓으면 JSON or YAML 형식의 CloudFormation 템플릿이 자동 생성됨

기존 CloudFormation 템플릿은 CloudFormation Designer 도구를 사용하여 열고 편집 가능하다!

 

템플릿으로 리소스를 그룹화하는 방법

최소한: 네트워크 리소스 / 보안 리소스 / 애플리케이션 리소스/ 등을 자체 템플릿으로 분리

 

모든 애플리케이션 환경을 하나의 템플릿으로 구축하는 것은 좋지 않다

템플릿 그룹화 기준 1. 수명 주기 단계 2.소유권

최소한 위 3개는 분리해야 한다!

보안 리소스는 중요!!! 따라서 나머지 템플릿과 분리하여 잠궈야 한다.

 

ex) 네트워크 리소스 ==> VPC, 서브넷, 인터넷 게이트웨이, 라우팅 테이블. 네트워크 액세스 제어 목록(ACL)

 

테스트 환경 & 프로덕션 환경 --> 동일한 템플릿을 공유해서는 안된다!

테스트 환경의 리소스 --> 자주 변경해야 함

프로덕션 환경의 리소스 --> 상대적으로 안정적이어야 함

팀 간에 템플릿 공유는 좋지 않다! --> 서로 다른 요구와 기준이 있기 때문이다.

 

단일 템플릿을 여러 애플리케이션에서 공유하지 말자!

의도적으로 해당 리소스 유형을 중앙에서 제어하려는 것이 아닌 한...

 

템플릿 변경은 해당 애플리케이션에만 영향을 준다. 

만약 하나의 템플릿이 변경되었는데 모든 애플리케이션이 영향을 받는다면 accident

 

AWS CloudFormation그룹을 사용하여 스택을 그룹화한 예시

이러한 구성 요소들을 템플릿으로 각각 구성!

 

AWS CloudFormation 템플릿 구조

-description

-Metadata

-메타데이터 : JSON 객체를 사용하여 추가 세부 정보

설정 또는 구성 정보를 검색합니다

cfn-init 헬퍼 스크립트에 대한 구성 작업을 정의

입력 파라미터가 AWS CloudFormation 콘솔에 표시될 때의 순서와 그룹을 정의

리소스가 AWS CloudFormation Designer에 어떻게 배치되는지 설명

파라미터는 고객이 런타임에 템플릿에 값을 전달하여 스택 내에서 사용자 정의할 수 있도록!

etc..

 

-Resources

필수 섹션이다

필요한 스택을 지정

리소스 선언

-depends on

중요한 속성이다.

DependsOn은 AWS CloudFormation이 다른 특정 리소스의 생성이 완료될 때까지 기다렸다가

리소스를 시작하도록 지정하는 방법이다.

 

이 속성이 필요한 경우 --> 뭔가를 기다려야 하는 경우에 사용

대기 조건 필요

ex) DependsOn : "EC2 instance"

ec2가 생성되고 난 후에 시작하는 대기 조건

 

템플릿을 공유하는 경우의 잠재적 문제점

EC2 keypair, 보안그룹 이름, 서브넷 아이디, AWS EBS 스냅샷 ID등 고유한 항목에서 문제가 발생

해결법 -->파라미터, 매핑, 조건을 사용하여 해결

기본 값과 허용된 값을 정의할 수 있는 속성 목록을 포함

-Mapping

mapping: key와 key에 연결된 값 , 조건부 파라미터 값 지정

특정 조건에 따라 리소스의 속성을 사용자 정의할 수 있다!

ex) AMI ImageId 번호는 리전에 고유하며, 템플릿을 수신한 사람은

어떤 AMI를 사용해야 하는지 모를 수도 있습니다.

따라서 Mappings 파라미터를 사용하여 AMI 조회 목록을 제공할 수 있습니다.

 

-Conditions(선택사항)

특정 리소스가 생성되는지 여부 또는 스택 생성이나 업데이트 도중 특정 값이 할당되는지 여부 제어

ex)

프로덕션과 개발 환경은 동일한 스택을 가져야한다.

QA 환경 기능 테스트, 사용자 수용 테스트, 로드 테스트 환경을 conditions문으로 제어

-Outputs

강의 질문