아마존 클라우드 AWS Essential 13강 AWS 개발 및 운영 방안 > AWS 클라우드

 

이번 시간에는 aws 의 개발과 운영 방안에 대해서 설명 드리겠습니다.
첫번째로 지속적인 통합과 지속적인 배포에 대한 방법을 이해 하실 수가
있습니다.
그리고 두번째 특채로 aws 운영 정책을 여러분들이 정 하시는데 어떤
것들을 정책을 결정하셔야 되는지에 대해서 이해 하실 수가 있습니다.
그리고 마지막으로 여러분들이 aws 에서 서비스를 운영 하시는 거에
어떠한 체크 리스트 목록이 있으며 이런 것들을 어떻게 파악을 하실 수
있는지에 대해서 말씀드리겠습니다.
첫번째 aws 에서 지속적인 코드 배포 방법
지속적인 통합 실제로 여러분들이 aws 뿐만이 아니고 it 인프라 에서
코드를 배포를 하실때 지속적으로 항상 통합 을 하시고 지속적으로 코드를
배포 하시는 방 안으로 설계를 하셔야 되는 거고요
첫번째로 이제 지속적인 통합 에 대한 부분인데 빌드 및 테스트 가 수행이
된 후에 개발자가 코드 변경을
중앙 4 4g 토리 의 감옥 깃이 라던가 서브버전 을 사용한 소스
레퍼토리에 정기적으로 통합 하는 소프트웨어 개발 방식 이라고 말씀드릴 수
있습니다.
그래서 실제로 지속적인 통합 같은 경우는 소프트웨어 릴리즈 프로세스의
중에서 빌드 또는 통합 단계를 주로 말을 하고요
그리고 자동화 구성요소 뿐만이 아니고 문화적인 구성 운영 습도 소까지
포함 하고 있습니다.
지속적인 통합 에 핵심적인 목표 라고 말씀드릴 수가 있는 것은 첫번째로
버그를 신속 쩍 으로 해결하신 다거나 그 다음에 품질을 개선 하신다 거나
그리고 업데이트를 또 검증할 수 있다거나 그리고 추후에 상용 안겨 까지
의지가 되는 시간을 단축시킬 수 있다는 목표가 있습니다.
지속적인 전달 매체로 여러분들이 서비스에 대해서 소스 소스 코드를 빌드
하시고
뭐 첫번째는 개발을 하시고 빌드 하시고 그 외에 대해서
앞에 설명드렸던 것처럼 지속적인 통합을 통해서 여러분들이 코드 의 파지
토리
여러분들의 코드들을 지속적으로 통합을 하셨다면 은
그것들을 지점 달을 하셔야 됩니다.
실제로 상용 에 릴리즈 하기 위한 코드 변경 이 자동으로 빌드 테스트 및
준비 되는 소프트웨어 개발 방식이 입니다.
그리고 아까 말씀드렸던 것처럼 지속적인 통합 으로부터의 확장이 개념
이구요
그래서 코드 변경 같은 것들을 통한 소스에 파스토레 코드를 업데이트가
되어 있다면은 테스트 환경
빌드 단기 이후의 모든 코드 변경을 테스트 환경 및 프로덕션의 환경에
배포 함으로써
앞에서 말씀드렸던 지속적인 통합을 확장을 할 수가 있습니다.
그리고 마지막으로 지속적 배포
실제로 지속적 통합과 지속적 전달이 합쳐져 있는 하나의 전체적인 큰 배포
방법이라고 보시면 될 것 같구요
서비스의 여러분들이 통합이 정상적으로 잘 되고 뭐 전달이 자 정상적으로
잘 될 경우에 프로덕션 환경 까지 가는 거는 뭐 이미 앞에서 검증을 다
됐고 그리고 어떤 것들에 대한 폐포 정책이란 엄마 이런 것들이 다 결정이
돼 있기 때문에
승인 없이 자동으로 프로덕션 환경에 배포 되고 이 일을 통해서 전체적인
소프트웨어 릴리즈 프로세스가 자동화가 되는 게임 지속적인 대포 입니다.
현재 it 환경 같은 경우는 실제로 패치 라던가 뭐 대규모의 핫픽스
라던가 업데이트가 이루어 지기 때문에 이런 지속적으로 통합을 하고 코드를
통합을 하고
긴데 파지 토리 소스를 파지 토리의 저장 을 통합적으로 하고요
그 다음에 점자를 지속적으로 해 주셔야 되구요.
혹은 지속적인 배포를 통해서 전체적인 프로세스를 자동화 를 시켜야지 패치
라던가 혹은 핫픽스 적용 에 대해서 여러분들이 자유롭고 그리고 서비스의
품질 동안 높일 수가 있습니다.
지속적인 코드 배포 의 그런 절차 파이프 라인에 대해서 조금더 그림으로
상세하게 설명드리도록 하겠습니다.
실제로 소스 코드가 개발 단계에서 개발이 될 거구요
이거에 대한 당연히 버전의 컨트롤도 중앙에서 하셔야 되는 거고요
이 소스 코드가 개발이 됐다 라고 했을때 이거에 대한 확인을 하셔야
되고요 확인을 하는데 이제 개발 환경
뭐 이후에 스테이징 환경에서 이 코드를 컴파일하고 뭐 빌드하는 단계를 당
이거 치실 거구요
그거에 대해서
이제 스테이징 환경이 적용을 하시고요
스테이지 환경에 적용할 때는
저번 차 스에서 말씀드렸던 이런 환경 설정과 코드 소스에 분리 를 통해서
환경 설정과 앱 컴필레이션 들 그리고 소스 코드 여기서 오는 소스 코드
같은 것들을
여러분들이 통합을 하셔서 스테이징 환경에 별도의 이제 q&a 를 돌릴 수
있는 환경을
지 만드실 수가 있습니다. 스테이지 환경까지 지속적으로 뭐 배포가 됐다며
는 뭐 전달됐다 며 는
유니테스트 라던가
혹은 o 스모크 테스트 그 다음에 다양한 즉 확인 절차들을 여기서 겉이
실 수가 있습니다.
실제로 여러분들이 이 패치를 한다. 라고 가정했을 때 해치의 대한 소스
코드를 여기서 올리구요 그 외에 대해서 적용을 실제로 하고요
그거에 대한 실제로 검증 단계 라고 보실수가 있습니다.
실제로 코드를 여러분들이 만드셨던 라도 개발 하셨더라 도 제 유저 딴
에서 테스트를 진행한 해주셔야 됐고요
그게 나중에 상용 환경 갔을 때 어떠한 장애 라던가 어떠한 버그가 생길
지를 미리 이 상황에서 판단을 한다.는
절차입니다. 그래서 만약에 여기까지 유저 테스트까지 완료됐다 며 는 이제
뭐 프로덕션 환경으로
올릴 수가 있구요. 이렇게 프로덕션 환경 까지 올린다 며 는
여러분들이 실제로 서비스에 대한 패치 같은 것들을 좀 더 효율적으로
가지고 오실 수가 있습니다.
그래서 이렇게 지속적인 통합과 지속적인 배포
그리고 혹은 지속적인 돈 날 위
효과적으로 운영이 되야지 여러분들이 코드 배포 방법이 좀더 효율적으로
가능하십니다
효율적인 배포 정책에 대해서 설명드리도록 하겠습니다.
아까 말씀드렸던 뭐 ti cd 같은 경우는 이 효율적으로 배포를 하는
하나의 방법 이었구요 이거 를 배포하는 정책에 대한 부분은 이렇게 블루
그린의 대한 방법을 초일 쪽으로 사용하셔야 됩니다.
실제로 사용자가 서비스의
뭐 접근을 했을 때 그 앞단에 부아 분배기 로드 밸런서 에서 트래픽을
받아줄 거고요
그리고 여기서 블루그린 이라고 말을 하는 것은 블루 같은 경우가 버전
원이라고 쳤을 때 그린이 최근 버전 버전 투 라고 보시면 될 것 같습니다.
그래서
무중단 으로 서비스를 제공하기 위해서 기존에 있던 버전 5 4 시스템과
버 전투에 시스템을 같이 운영을 하시면서 처음에는 뭐 90대 모십
그 다음에는 50대 50 문제가 없다면 은 그 다음에 뭐 20 대 80
그 다음에는 뭐 0 대 100 이런식으로 버전 원에서 버전 트 로
넘어가는 방법을 부 중단으로 스무스하게 넘어가는 하나의 배포 정책입니다.
실제로 여러분들이 지속적인 통합과 지속적인 뭐 전달
2 이 방법이 여러분들이 운영이 잘되고 있어야지
이런 효율적인 폐포 정책도 당연히 적용 하실 수가 있구요.
2 효율적인 대포 정책까지 여러분들이 적용을 효과적으로 하셨다면 은
여러분의 서비스를 부 중단으로 효과적으로 매우 탄력적이고 확장성 있게
서비스를 설계를 하실 수가 있습니다.
그래서 최근 들어서 이런 지속적인 배포 정책에 대해서 아는
정책들이 나오고 있구요. 이거에 대해서 좀더 실제 사례를 통해서
설명드리도록 하겠습니다.
효율적 인 배포 지원시스템 실제 예시로 말씀드리도록 하겠습니다.
넷플릭스 에서 활용을 하고 있는 스피 메이커 나는 하나의 시스템이 고요
aws 위에서 넷플릭스가 어떻게 효율적으로 컨테이너 쓰인 태그 레이 션
콘팅 딜리버리 블루 그린의 대한 백보 정책 같은것을 어떻게 효과적으로
운영 할지에 대해서 스 테 마 1개 스핀 레이커 라고 볼 수 있습니다.
스핀 에이커 같은 경우는 뭐 깊 혹은 여러분들이 가지고 있는 소스에 파지
토 리 랑 연동 가능 하시구요
빌드를 하기 위한 채 키스
그리고 뭐 배포 정책 블루 그린의 대한 배포 정책을 지원을 하고 있습니다.
그리고 중간중간에 여러분들이 필요한 버튼 액션을 넣을 수가 있구요.
실제로 예로 봤을 때
이미지를 여러분들이 소스코드를
업데이트 하시고 킷 내 4g 토리의 올리자 따면 은 그에 대해서 빌드를
하셔야 되구요. 빌드한 다음에 그 빌드된 이미지 빌드된 인스턴스 를 가지고
이미지를 궁 는 베이크 작업 일 진행이 되구요.
베이크 가 됐을 때 세로 이 이미지가 정상적 인지 확인 절차를 거치고 요
그 다음에
실제로 스테이징 환경 같은 경우 여러분들이 이미지로 런칭을 하셔서 디플로
일을 하셔서 2스테이지 환경을 꿀이 실 수가 있구요.
2스테이지 환경이 아까 말씀드렸던 것처럼 뭐 유니테스트 라던가 다양한 퀴
a 테스트를
설정을 하실 수가 있구요. 그리고 여기서
스테이트 환경까지 완료가 되고 성 서비스의 q&a 까지 완료됐다 며 는
그래서 프로덕션 상용 환경으로 디플로 일을 할지 말지 에 대한 뭐 결제를
여러분들이 엄동 하실 수가 있구요.
만약에 결제를 해서 가겠다 라고 했을 때는 뭐 프로덕션 환경에 론칭 되고
하지만 뭐 4시간 정도 기다리는 또 트랜잭션을 중간에 놓으실 수가 있구요.
그리고 뭐 기존에 있던 시스템 들 만약에 정상적으로 블루 그린 을 통해
서부 중단으로 스무스하게 버전이 올라갔다면 은 기존에 있는 서버 그룹들을
제거를 하겠다
모델 시간 후에 제거를 하겠다 이렇게 여러분들이 서비스를 설계를 하실
수가 있습니다.
그래서 다양한 방법들 그리고 다양한 시스템들을 을 스핀 에이커 와 연동을
하셔서 여러분들이 지속적으로 코드를 배포 하시고
그리고 어떠한 배포 정책으로 여러분들이 서비스를 버전을 업그레이드 하실
지를 스핀 에이커 를 통해서 효율적으로 운영 하실 수가 있습니다.
두번째 aws 운영방안에 대해서 말씀드리도록 하겠습니다.
첫번째 개정 및 비용 관리
여러분들이 aws 를 운영을 하신다 라고 했을 때는 첫번째로 개정 관리
하셔야 되구요. 비용 관리 또한 하셔야 됩니다.
예를 들면 은 서로 간에 접근통제 라던가 권한부여 교과목 관리 같은
것들을 여러분들 하셔야 됐구요
aws 에서는 다양한 툴을 통해서 서비스를 통해서 효율적으로 관리할 수
있게끔 지원하고 있습니다.
즉 애정에 대해서 여러분들이 분리 하실 경우가 있을 수가 있는데 뭐
보안적인 경리 환경 개발 환경 취해 안경 상영 전 같은 보안 쪽으로
경리가 대하는 애들은 9분에 따라서 계정을 풀리 하실 수가 있고요 그리고
서비스 별로도 5 9분을 하실 수도 있습니다.
이렇게 여러 사유를 통해서 개정을 다수 개 로 운영할 수가 있고 이거에
대해서 과금을
중앙에서 할 수 있게끔 it 이라던가 중앙 부서에서 효율적으로 관리할 수
있게끔 통합 필링 계정으로 운영 하셔야 됩니다.
이게 이제 효과적인 aws 의 개정 및 비용 관리 정책 이라고 볼 수
있습니다.
두번째 자산관리
실제로 여러분들의 aws 에서 서비스를 구성 하셨을 때 그에 대한 에쎄
뜰을 관리하시고 추적 하셔야 되는데
그거에 대한 내용이라고 보실수가 있구요.
효율적으로 자산 운용을 할 수 있도록 aws 에서는 다양한 서비스를
제공하고 있습니다.
특히 aws 에서 몬스터 스 정보 같은 경우는 다양한 메타정보 이미지정보
라던가 혹은 디스크 정보 라던가 혹은 아이 키 정보 라던가 이런 것들을
제공을 하고 있구요.
그리고 api 나 cli 를 통해서 정보 수집이 가능하게끔 지원을 하고
있습니다.
또한 aws 에서 지원을 하지 않는 메타정보 같은 경우는 커스텀 태그를
통해서
정보들을 직접 입력하고 관리 가능 하십니다
세번째 모니터링 및 사고 관리
세로 클라우드 아트 를 통해서 aws 에서는 다양한 모니터링 하실 수가
있습니다.
기본적으로 모니터링 이라고 했을 때는 뭐 어플리케이션 혹은 서비스
모니터링 그 다음에 시스템 모니터링 있는데 기본적인 운영과 장애 대응을
할 수 있는 하나의 방법이고
실제로 여러분들의 비즈니스의 중요도에 따라서 알람 설정 이라던가 모니터링
절 책을 결정하셔야 됩니다.
aws 에서는 클라우드 아치를 통해서 통합된 대시 보드로 모니터링 하실
수가 있구요. 이거에 대한 알람 역시 sns sms 를 통해서 효과적으로
알람 연동을 가능하십니다
그래서 신속하기 서비스의 알람 장애 알람을 받으실 수 있구요.
이거에 대해서 고객과 약속된 서비스 등급 에 맞춰서 장애를 복구 한다.거나
그리고 관리할 수 있는 정책을 가져갈 수가 있습니다.
고가용성 및 탄력성 방안 키스를 aws 에서는 클론 멀티 테너 c 안
환경이다 보니 예전 차수 에서 말씀드렸던 것처럼 장애를 대응하는 디자인
그리고 컴포넌트 속여라 다양한 방법으로 서비스를 설계를 하셔야 됩니다.
그래서 고가용성 및 탄력성 당하는 장애를 대응하는 디자인 4 하나의 구성
요소 라고 볼수 주시면 좋을 것 같구요
그래서 효율적 인제 has 정책 깍 보 가용성 정책에는
aws 의 가용 영역 을 멀티 개 를 활용한 인스턴스 이중 아
관리 그 다음에 로드밸런싱 그 다음에 자동 확장이 노토 스캐닝 다음에
모니터링
그리고 리즈 내의 복구에 대한 방법들을 여러분들이 운영정책에
넣으셔야 됩니다. 그래서 항상 spoof 가 단일 장애 요소들을 제거하고
요 그리고 어플리케이션 의 가용 요구사항이 어느 선 이상이다 라고 했을
때는 그 측면에 바탕으로 서비스 가용성을 확보를 하셔야 됩니다.
그러기 위해서는 아까 말씀드렸던 것처럼 이 중 아 로드밸런싱 모터 스켈링
모니터링과 등 쟁
먼저 손수 가 돼야 되고 a 외에 대한 정책이 결정되어야 됩니다.
고가용성 니 탄력성 당한 중에서 기본적으로 고민을 하셔야 될 운영방안
입니다.
5 이중 아 에 대한 부분 그리고 뭐 로드 밸런스에 대한 부분 확장에
대한 부분이 다뤄지고 있구요.
이거에 대해서는 여러분들이 서비스 운영 하실 때 참고하시면 될 것
같습니다.
br 및 백업 관리 실제로 효율적 인 tr 정책은
단일 컴포넌트의 복구 뿐만이 아니고 어플리케이션 단에서 예상되는 디아
시나리오 수행 들을 포함하고 있습니다.
세로 장애가 여러분들이 발생했다 라고 했을 때는
언제까지 이거를 복구하고 이거에 대한 인지 시간은 언제까지 인지를 할 거
며 이거에 대해서 뭐 손실이 되는 데이터 들에 대해 기간은 어느 정도까지
감안 할 건지를 여러분들의 비즈니스 중요도에 따라서 운영 정책 으로
결정하셔야 됩니다. 그거에 맞춰서 dr 정책을 결정하시고 요 그에 맞춰서
빼 거 관리 정책을 결정하셔야 됩니다.
pr 미 빼고 관리에 대한 부분에 대해서 여러 가지의 체크 리스트가
있는데 예를 들면 뭐 디즈니 하나가 문제가 생겼을 때 그런 데이터 혹은
ami 를 다른 쪽으로 백업을 주기적으로 하고 있는가 혹은 뭐 다른 쪽에
있는 데이터를 저장할 수 있는 공간이 있는지에 대해서 그리고 옷 데이터
보관 이 저장 전문 서비스인 크래셔 같은걸 활용하고 있는지 이런 것들에
대해서 여러분들이 실제로 운영을 하실 때 체크 하시면 될 것 같습니다.
세번째 aws 운영 체크리스트
앞장에서 말씀드렸던 운영에 대한 방안은 세로 엔터프라이즈급 혹은
여러분들이 조금 더 어드밴스트 1 체크리스트 그리고 운영 정책에 대한
부분 이었구요
기본적으로 뭐 ihi 엘의 따른 체크리스트 형태가 이 기본 체크리스트
라고 보시면 될 것 같습니다.
그래서 잠재적인 위험 요소와 통상적인 인프라 체크 상용으로 가는 고
라이브 체크와 같은 하나의 사항이 고요 그래서 비용관리 그 다음에 뭐
다양한 정책들 이런 것들이 어떤 게
여러분들이 운영 정체로 가져와야 될 지에 대해서 aws 가 제공하고 있는
하나의 체크리스트 라고 볼 수 있습니다.
여러분들 운영 체크리스트를 제 관리를 하시고 이거에 대한 체크리스트 에
대한 리스터 글 하셨는데 기본적으로 운영을 하실 때 저희가 첫차 수에서
말씀드렸던 것처럼 a tools 에서는 다양한 서비스 모델이 존재를 하고
있습니다.
이미 한번 얘기 안 내용이지만 이 서비스 운영할 때 매우 중요한 요소이기
때문에 책임 분담 모델이 매우 추면
요소이기 때문에 여기서 잠깐 다시 설명드리도록 하겠습니다.
저희가 사용하는 aws 컴포넌트 들이 책임 분담 모델이 두가지의 방식으로
존재를 하고 있는데 첫 번째로 인프라스트럭처 서비스 모델
예를 들면 이스트 인스턴스 라던가 혹을 음
네트워크에 대한 부분이 라던가 aws 에서 인프라 잊어 서비스를 활용할
때 어디까지가
고객이 관리해야 된 부분이고
어디 프 터 가 aws 가 관리를 해야 된 부분인가 에 대한
모델 정책입니다. 실제로 기본적인 aws 의 하드웨어 우리가 인프라스트럭처
에 져 서비스 보데 를 활용했을 때는 이 기본적인 물리적인 것부터
하드웨어적인 것들 그리고 그 위에 올라오는 가상화된 것들
네트워크 이런 것들이 또 해서 관리를 해야 되는 부분이고요 그 위에
올라오는 뭐 os 라던가 그 다음에 os 위에 올라오는 모파 이오리
라던가 플랫폼 이라던가
o 네트워크 라던가 어플리케이션 데이터 드 명 것들을 우리가 관리 하셔야
됩니다.
여러분들이 aw 서비스를 어떤것을 활용을 하는 거에 따라서 서비스 운영
체크리스트가 달라질 거 고요
그거는 aws 의 책임 분담 모델에 따라서 여러분들이 결정을 하셔야
됩니다.
aws 에서는 인프라스트럭처 써비스 책임 분들 뿐만이 아니고 추상화된
서비스 모델 역시도 존재하고 있습니다.
플랫폼 까지 올라온 파스 형태라고 보실수가 있구요.
혹은 뭐 사스 형태의 서비스 라고 보실 수도 있습니다.
그래서 aws 에서 기존의 인프라스트럭처 애저 서비스 모델 그 책임은 난
모델 이상으로
인프라스트럭처 애저 서비스 보지는 이정도만 책임을 aws 에서 관리를
하고 운영을 했는데 그 위에 올라오는 추상화된 서비스 모델 같은 경우는
os 네트워크 파이 올 플랫폼 어플리케이션 그 다음에 뭐 여러가지 의
이클립스 0 까지 해서 aws 가 운영을 하고 있습니다.
그 위에 저희는 올라오는 데이터들이 나 클라이언트 사이드
아무와 이런 것들을 추가적으로 적용해서 데이터를 보관 할 때 좀 더
안정적으로 하실수가 있습니다.
그래서 실제로 여러분들이 운영 정책을 정하실 때 앞에서 말씀드렸던
인프라스트럭처를 레저 서비스 책이 문자 모델과 추상화된 서비스 모델을
적절하게 혼용 하셔서 서비스 운영 체크리스트를 작성을 하시고 국에 대한
명 방법을 결정하셔야 지 효과적인 운영을 하실 수가 있습니다.
이번 시간에는 개발 및 운영 방안에 대해서 알아보았습니다.
첫번째 지속적 코드 배포 방법
최근 it 환경에서 는 지속적인 통합과 지속적인 전달
다음에 배포 파이프 라인과 다양한 배포 정책들을 결정을 하고요
이거에 대해서 프로세스를 5표 10화 시키고 특히 자동화 시켜서 신속한
서비스 개발과 품질을 올려서 비즈니스 가치를 높이는 데 일조하고 있습니다.
두번째 운영방안 개정 관리 보니 터 링 다음에 목 고 가용성 탄력성 dr
및 백업 관리 같은 여러분들이 7 운영 하실 때 어떻게 운영을 해야 될
지에 대한 정책들을 효과적으로
결정하시고 요 그 외에 대해서 높은 수준의 운영 정책들을 수립을 하셔야
됩니다.
세번째 운영 체크리스트 여러분들이 개발을 하시고 그 이후에 상용의 환경에
서비스를 런칭 하신다 라고 했을 때는
aws 에서 제공하는 뭐 체크리스트 도 있구요. 다양한 my 티아에 레오가
1 체크리스트를 통해서 여러분들이 잠재적인 위험 요소를 제거 하시구요
aws 특히 aws 에서는 여러분들이 서비스 특성에 맞는 책임 분담
모델을
정확하게 명확한 이해 하시고요 이 거에요 버 에서 운영을 효과적으로 수행
하셔야 됩니다.