📌 Amazon 초창기에는 애플리케이션 개발 방식은 모놀리스 방식
- 다시 말해 단일 플랫폼의 단일 티어에 결합된 다양한 구성 요소로 이루어진 밀결합 된 아키텍처 구조였음
- 새 애플리케이션이나 애플케이션 업데이트가 필요한 경우, 모놀리스 아키텍처는 하나로 이루어진 구조라서 유연성이 부족하고, 내결함성도 낮았음.
📌 그래서 Amazon은 마이크로서비스를 다루는 더 작고 더 민첩하며 자율적인 팀으로 기능 계층 구조를 바뀜
-> 6~8명이 팀으로 구성됨
-> 구체적 역할과 전문성은 기술 격차를 제거하고 마이크로서비스의 완전한 소유권을 증진시킴
-> 팀은 개발 파이프라인의 모든 부분을 책임
📌 과거에는 개발자가 여러 인프라에 빠르고 효과적으로 배포할 방법을 찾아야 했고, 이것이 자동화로 이어짐
- 처음에는 배포만 자동화 되었고 나중에는 처음부터 끝까지 제품의 전체 개발 주기가 자동화되어 마이크로서비스의 복잡성을 관리했음
- 이것은 교육 과정 뒷부분에서 다루는 지속적 통합/ 지속적 전달 파이프라인으로 간주됨
📌 그래서 완전히 공유되고 통합된 운영 책임임
- 개발 팀과 운영 팀의 분리가 거의 또는 전혀 없는 경우를 보여줌, 이 토폴로지가 성공하기 위해서는 두 팀의 팀원들이 공통의 목표에 고도로 집중함
👉 DevOps
- DevOps는 소프트웨어 개발과 정보 기술 운영을 결합하는 문화 철학, 사례 도구의 조합
- DevOps에서 중요한 것은 장벽 제거
- 개발팀과 운영팀이 함께 협력하여 개발자의 생산성과 운영의 신뢰성을 모두 최적화
- 도구보다 프로세스, 프로세스보다 사람
👉 DevOps 구현 개념
- 지속적 통합 및 지속적 전달
-> 8~10명 정도 팀을 구성해, 코드의 개선이나 인프라의 개선을 유지보수함
-> 위의 과정 시간을 최소화하기 위해 최대한 자동화를 해야 함
-> 보안 검사나 test를 자동으로 해서 다음 단계로 넘기는 것
- 마이크로 서비스
- 코드형 인프라
-> 코드형 인프라를 구성해서 빠르게 제공함
- 모니터링 및 관측 가능성
-> 각각의 마이크로 서비스들이 모니터링을 하는데 한계가 있음
-> 그래서 관측 가능성이라는 개념이 나왔음
- 커뮤니케이션 및 협업
👉 DevOps 문화
- DevOps에 사 중요한 것은 장벽 제거임
- 함께 협력하여 개발자의 생산성과 운영의 신뢰성을 모두 최적화함
- 도구보다 프로세스, 프로세스보다 사람
- 지속적 통합
-> 개발자부터 시작함
-> 개발자는 Git 같은 공유 중앙리포지토리에 정기적으로 코드를 체크인함.
-> 다음으로 자동화된 검사가 정기적으로 실행되어 공유 코드 베이스와 비교하여 오류를 찾음
-> 마지막으로 개발자는 자동화된 검사로부터 코드에 대한 피드백을 받고, 코드를 편집하여 리포지토리에 다시 제출
-> 지속적 통합(CI), 지속적 전달(CD), 지속적 배포(CD)는 파이프라인에서 개발을 위한 소프트웨어 전달 프로세스를 지원하는 프로세스임
- 코드형 인프라는 버전 제어나 지속적인 통합과 같은 코드 및 소프트웨어 개발 기법을 사용하여 인프라를 프로비저닝 하고 관리하는 방식임
- 클라우드의 API 중심 모델을 사용하면 개발자와 시스템 관리자는 리소스를 수동으로 설정하고 구성할 필요 없이 개발자와 시스템 관리자는 리소스를 수동으로 설정하고 구성할 필요 없이 대규모 인프라와 프로그래밍 방식으로 상호 작용할 수 있음
📌 인프라 자동화
- 자동화는 설정, 구성, 배포, 인프라 지원 및 해당 인프라에서 실행되는 애플리케이션 등 DevOps의 다양한 구성 요소에 초점을 맞춤
- 이런 의미에서 자동화란 자동 릴리스 프로세스를 말함
- 자동화를 했을 때 수동 프로세스를 제거하고, 인프라 프로비저닝을 자동화하여 인적 오류로 인해 발생할 수 있는 비일관성이 줄어듦
- 인프라에 가능한 것은 애플리케이션 소스 코드처럼 버전 지정 및 관리를 하고 반복적이고 안정적으로 생성, 끄기 및 재생성을 해주고 최신 애플리케이션 버전 테스트를 위해 필요에 따라 생성함.
👉 Cloudformation 템플릿 생성 관리 계획
- 교차 스택
-> 자격 증명, 기본 네트워크, 공유, 백엔드, 프런트엔드, 계층별로 별도의 독립 스택 생성
-> 스택의 리소스 생성을 위한 속성을 타 스택을 참조
- 중첩 스택
-> 각각의 계층을 담은 중첩 스택들을 포함한 부모 스택의 생성
-> 부모 스택의 생성 완료를 통한 마이크로서비스 인프라 배포
👉 Cloudformation 템플릿 테스트
- AWS Taskcat
- cfn-lint
- cloudformation vaildate-template 명령어
👉 Cloudformation 스택 업데이트 절차
👉 Cloudformation 스택 운영
- 드리프트 탐지 - 수동 변경 작업 파악
- 스택 정책 - 종료 및 다운타임 방지
- 삭제 정책 - 종료 보호 또는 데이터 백업
📌 사용자 지정 리소스
- 사용자 지정 리소스를 통해 스택을 생성, 업데이트(사용자 지정 리소스를 변경한 경우) 또는 삭제할 때마다 AWS CloudFormation이 실행하는 사용자 지정 프로비저닝 로직을 템플릿에서 작성할 수 있음. 사용자 지정 리소스를 사용하면 AWS CloudFormation 스택에 비 AWS 리소스를 포함할 수 있음.
📌 스택 업데이트
- 중단 없는 업데이트
-> AWS CloudFormation이 리소스 운영 중단 없이, 리소스의 물리적 이름 변경 없이 리소스를 업데이트함
- 일부 중단이 있는 업데이트
-> AWS CloudFormation이 리소스를 업데이트할 때 일부 중단이 발생하지만 물리적 이름은 유지됨
- 교체
-> AWS CloudFormation이 업데이트 중에 리소스를 다시 생성하며 새 물리적 ID도 생성됨
-> AWS CloudFormation은 먼저 교체 리소스를 생성하고, 교체 리소스를 가리키도록 다른 종속 리소스의 참조를 변경한 다음 이전 리소스를 삭제함.
📌 AWS CloudFormation 헬퍼 스크립트
- 스택을 생성할 때 다음 스크립트를 사용하여 소프트웨어를 설치하고 서비스를 시작함
-> cfn-init
리소스 메타데이터를 검색 및 해석하고, 패키지를 설치하고, 파일을 생성하고, 그러면 필요한 리소스나 애플리케이션 준비될 때 스택의 다른 리소스를 동기화할 수 있음
-> cfn-signal
CreationPolicy 또는 WaitCondition을 사용하여 신호를 보내는 데 사용함
그러면 필요한 리소스나 애플리케이션이 준비될 때 스택의 다른 리소스를 동기화할 수 있음
-> cfn-get-metadata
리소스의 메타데이터 또는 특정 키의 경로를 검색하는 데 사용함
-> cfn-hup
- 메타데이터 업데이트를 확인하고 변경 사항이 탐지될 때 사용자가 지정 후크를 실행하는 데 사용
- 리소스 메타데이터에서 변경 사항이 있는지 CloudFormation스택을 폴링
- 변경 사항이 탐지되면 사용자가 지정 작업 실행
- cfn-hup를 통해 리소스 메타데이터 변경 사항 탐지 가능
📌운영 중단 방지
- 기본적으로 스택의 모든 리소스는 업데이트 권한이 있는 사용자라면 누구나 업데이트할 수 있음
- 하지만 일부 리소스는 업데이트 중에 중단이 필요하거나 완전히 교체되어 새로운 물리적 ID나 완전히 새로운 스토리지가 생길 수 있음
- 이러한 리소스가 부주의로 업데이트되는 것을 방지하기 위해 스택 정책을 설정할 수 있음.
- 스택 정책은 보호되는 리소스를 누군가가 실수로 업데이트하는 것을 방지함
- 보호되는 리소스를 업데이트하려면 해당 리소스를 명시적으로 지정해야 함
📌 DevOps 민첩성 및 자동화
AWS CLI: 명령줄에서 AWS 리소스를 관리함
AWS SDK: 널리 사용되는 프로그래밍 언어를 사용하여 애플리케이션을 AWS서비스와 통합함, 각 SDK는 API, 코드 예제 및 설명서를 제공함
AWS CDK: 익숙한 프로그래밍 언어를 사용하여 클라우드 애플리케이션 리소스를 모델링하기 위해 클라우드 인프라(Iac)를 정의하고 프로비저닝함
AWS SAM: 템플릿에서 서버리스 아키텍처를 정의하고, AWS CLI를 사용하여 이 아키텍처를 로컬에서 빌드하고 테스트하며 패키징을 함
📌 AWS Command Line Interface(AWS CLI)
- AWS 서비스를 관리하고 자동화하기 위한 도구
- 터미널에는 AWS관리 콘솔에서 사용할 수 있는 모든 기능이 포함되어 있음
- Window, Linux, macOS 및 Docker 컨테이너에 설치
- 서버 측 자동 완성, 자동 프롬프트 및 법사를 포함한 대화형 기능
📌AWS CDK란?
- 클라우드 인프라를 코드로 정의하고 AWS CloudFormation을 통해 프로비저닝 하기 위한 소프트웨어 개발 프레임워크
- 예측 가능하고 반복 가능한 방식으로 AWS 인프라 배포를 생성하고 프로비저닝 할 수 있음
- 기본 AWS 인프라 생성 및 구성에 대해 신경을 쓸 필요 없이 클라우드에서 매우 안정적이고 확장 가능하며 비용 효율적인 애플리케이션을 빌드할 수 있음
- 템플릿 파일을 사용하여 리소스의 모음을 단일 단위로 함께 생성하고 삭제할 수 있음
📌AWS CDK의 이점
- 더 쉬워진 클라우드 온보딩: AWS로의 온보딩을 가속화함
- 사용자 정의 및 공유 가능: 조직의 보안, 규정 준수 및 거버넌스 요구 사항을 충족하는 재사용 가능한 구성 요소를 직접 설계할 수 있음
- 더욱 빨라진 개발 프로세스: 인프라 정의를 위한 프로그래밍 언어의 표현 기능을 제공함
- 콘텍스트 전환 없음: IDE 벗어나지 않고도 클라우드 애플리케이션을 빌드함
📌Amazon Q
- Amazon Q는 기존 거버넌스 자격 증명, 역할 및 권한을 이해하고 존중할 수 있는 생성형 AI기반 어시스턴트임
- 기본적으로 보안이 유지되는 비공개로 설계됨
- 관리 제어를 사용하면 가드레일을 적용하여 응답을 사용자 지정하고 제어할 수 있음
- 기본 모델을 개선하기 위해 데이터를 수집하는 경우 다양한 옵션이 있음.
- 구독을 통해 Amazon Q에 액세스 하는 사용자의 경우 자동으로 옵트아웃이 됨
👉개발 도구를 사용한 CI/CD
📌애플리케이션 릴리스 파이프라인
-> 지속적 전달 및 지속적 배포는 지속적 통합을 확장하여 애플리케이션을 자동으로 릴리스 함
-> 지속적 전달과 지속적 배포의 차이점음 지속적 전달은 파이프라인이 일시 중지되고 프로덕션 배포 전에 작업자의 개입이 필요하다는 것
📌CI
-> 소스 - 빌드 - 테스트의 자동화
-> 지속적 개발은 지속적 통합의 중요한 요소임.
-> 지속적 개발 사례에서는 여러 사람이 코드 작업을 함
-> 모든 사람이 작업에 최신 작업용 빌드를 사용하는 것이 매우 중요함
-> 코드 리포지토리는 서로 다른 버전의 코드를 유지 관리하고 팀에서 코드에 액세스 할 수 있도록 함
-> 리포지토리에서 코드를 체크아웃하고, 로컬 사본에서 코드를 변경하거나 새 코드를 작성하고, 코드를 컴파일 및 테스트 한 다음 코드를 다시 리포지토리에 자주 커밋함
📌CD
-> 애플리케이션의 프로덕션 환경에 자동 전달 혹은 배포 자동화
-> 지속적 전달 - 전달까지만 하고 수동 승인으로 배포한다면
-> 지속적 배포 - 프로덕션 환경까지 자동으로 배포
📌GitHub - 소스
-> 애플리케이션 소스 제어를 위한 브랜치 전략 구현
-> Git Flow
📌Trunk (줄기) 기반
✅ 브랜치(Branch)란?
브랜치 = 메인 트렁크에서 잠깐 갈라져 나오는 독립 작업 공간\
✅ 트렁크(Trunk)란?
트렁크 = 개발자들이 함께 작업하는 공통 메인 브랜치를 말함
보통 main 또는 master 브랜치를 말함
-> 트렁크 기반 개발은 많은 개발자가 트렁크라고 하는 단일 공유 브랜치를 통합하거나 여기로 커밋하는 또 다른 분기 모델임
-> 이 브랜치는 일반적으로 소스 제어되므로 대부분의 커밋이 트렁크에서 발생함
-> 생성되는 다른 브랜치가 삭제됨
-> 릴리스 브랜치는 단시간 유지되며 커밋은 팀의 개인 특정 개인 또는 역할에 의해 제어됨
-> 대부분의 조정/ 수정/ 커밋은 트렁크에서 발생하고 그런 다음 릴리스 브랜치에 병합
📌폴 리퀘스트 작업
-> 여러 개발자가 한 리포지토리에서 협업할 수 있는 방법
-> 협업하여 코드 변경 내용을 검토하고 한 브랜치에서 다른 브랜치로 병합
-> 작업 브랜치와 대상 브랜치 간 비교
--> 소스 브랜치: 검토할 소스를 포함
--> 검토한 코드를 병합하는 위치
-> 코멘트에 응답하여 풀 리퀘스트를 업데이트
-> 새 풀 리퀘스트를 알리도록 리포지토리 알림을 구성
📌Amazon CodeGuru
- 자동화된 코드 검토 및 애플리케이션 성능 프로파일링을 위한 기계 학습 서비스
- Amazon의 수십 년 지식과 경험으로 훈련됨
- 프로덕션에서도 지속적으로 최적화 검색
- 식별된 문제를 해결할 수 있도록 실행 가능한 권장 사항 제공
- 코드에서 찾기 어려운 결함을 자동으로 검사
📌AWS Codebuild - 빌드
-> 소스 코드를 컴파일하고 테스트를 실행하며 소프트웨어 패키지를 생성하는 완전 관리형 빌드 서비스
-> AWS 관리형으로 제공되는 빌드 및 단위 테스트를 서비스
-> 빌드 결과물인 아티팩트를 S3에 저장
-> Bamboo
: 자동화된 빌드, 테스트 및 릴리스를 단일 워크플로로 연결하는 도구임
📌AWS CodeDeploy - 배포
- 지속적 전달은 대부분의 소프트웨어 릴리스 프로세스를 자동화함
- 커밋되는 모든 개정 버전은 업데이트를 빌드하고 테스트하고 단계별로 스테이징하는 자동화된 흐름을 트리거함
- 그러나 개발자는 자동화되지 않은 라이브 프로덕션 환경으로 최종 배포를 트리거해야 함
- 지속적 배포에서는 소스 코드의 최초 체크인을 제외한 전체 릴리스가 자동화됨
- 지속적 전달은 빌드 단계 이후 모든 코드 변경 내용을 테스트 환경이나 프로덕션 환경 또는 두 환경 모두에 배포하여 지속적 통합을 확장함
- 지속적 전달이 적절하게 구현되면 개발자는 테스트 및 배포 준비가 완료된 빌드를 갖게 됨
- AWS CodeDeploy는 Amazon EC2, AWS Fargate, AWS Lambda, 온프레미스 서버 등 다양한 컴퓨팅 서비스에 대한 소프트웨어 배포를 자동화하는 완전관리형 배포 서비스임
- AWS CodeDeploy를 사용하면 더 간편하게 새로운 기능을 신속하게 릴리스하고, 애플리케이션 배포 시 가동 중지 시간을 방지하고, 애플리케이션 업데이트의 복잡성을 처리할 수 있음
