책 : 서비스 운영이 쉬워지는 aws 인프라 구축 가이드 _ 1

학원에서 책을 나눠줬다, 얼마 지나지 않아 있을 aws 수업을 위해서 나눠신 듯 했다 

책 내용을 살펴보니, 자격증 공부를 할때 살펴봤떤 내용들이 요약적으로 적혀있어서, 복습하는데 좋을것 같았다

그리고, 지금 구성하고 있는 웹앱 구성에도 도움이 될것 같아서 내용위주로 먼저 정리하고, 실습을 쭉 이어서 진행해보려 한다 

 

 

 

클라우드를 왜 써야 하는가
=> 유연성, 확장성, on - demand 과금방식을 통한 비용절감 

 

● ALB
: 서버 안에서 똑같은 애플리케이션을 여러 프로세스로 만들어 실행해놓고 외부에서 들어온 요청을 프로세스중 하나로 보내주는 역할
=> 한 서버에 들어온 여러개의 요청을 동시에 처리 + 서버 자원을 효율적으로 사용이 가능 

 

 

● 웹서버
: 웹 프로토콜 http https 의 요청을 받고 정적인 응답을 해주는 서버 
=> 코드를 실행해 동적인 응답을 해줄 수 없음
apache

 

● 웹 애플리케이션 서버 web application server WAS
: 요청을 받고 코드를 실행해 동적인 응답을 만들어주는 역할
apache tomcat  / JBoss / pushion passenger  -> 노드, 파이썬, 루비,meteor




● auto scaling  - 대량의 트래픽에대한 처리  / 장애에 대한 fail over
=> 자동 다중 서버 서비스 

auto scaling group
=> 같은 사양, 같은 환경, 같은 코드를 가지고 있는 똑같은 ec2 인스턴스들의 묶음  -> AMI 이미지를 통해서 손쉽게 생성 가능

=> 인스턴스의 수를 자동으로 늘리거나 줄여줌 scale in / out  => 알림 까지 가능 

 

과정
=> 생성하기 위해 자동으로 생성할 인스턴스 고르고 
=> 그 인스턴스의 스냅샷을 이용해서 => 이미지 생성 => 시작 템플릿으로 사용
=> autoscaling group 생성

** 주의할점 
해당 서버를 autoscaling에 사용할 이미지를 만들었으면, 스케일링이 될때 같은 환경의 서버가 작동되기 위해서 해당서버는 되도록 사용하지 않고, 변경점이 있을때만 새로 이미지를 배포하는 식으로 사용해야함

● ELB elastic load balancing

로드 밸런서도 일종의 서버 but 직접 ssh를 통해서 접근할 순 없음

=> 대상 그룹으로는 인스턴스 자체와 auto scaling 그룹을 가질 수 있음
==> 포트에 따라서 대상을 다르게 밸런싱할 수도 있음

ex) 

80 443 => A
53 => B





● 장애조치 아키텍쳐 fail over 

=> 시스템 하나가 죽었을 때 예비 시스템을가동하여 다운 타임을 최소화 하고 서비스의 연속성을 지키는 것


=> 'auto scaling / 로드밸런서' 들을 사용해서 구성할 수 있음

로드 밸런서 -> 로드 밸런싱하고 있는 서버들의 상태를 계속해서 확인하기 때문에 => 즉각적 대처가 가능하고 => 서버의 상태가 올바르지 않으면 트래픽을 보내지 않기 때문에 => 장애조치가 가능함

 

● DNS
도메인에 연결된 웹 서버들의 ip를 저장하고 있고, 쿼리/요청이 들어왔을 때 이 주소를 반환해주는 서버  - route 53


SSL/TLS https  => aws에서 관련된 인증서를 무료로 제공하고 있다고 책에 나와있음 -> 찾아봐야겠다

 

============================================================================================
AMI 이미지 방식은 컴퓨터 하나를 통째로 백업한다고 생각하면 되고, 스냅샷은 하드디스크 내용물만 백업하는 것으로 이해하면 된다. 물론 EC2와 관련된 EBS 여러개를 백업할수도 있다.

AMI 인 경우에는 바로 EC2 인스턴스를 생성할 수 있고,

Snapshot 인 경우는 Snapshot 을 이용해 AMI 를 생성하는 단계를 거쳐야한다는 차이점이 있다.
스냅샷은 EBS의 내용을 백업한 데이터라 직접 바로 인스턴스를 만드는게 불가능 하다.
============================================================================================


코드 배포

●무중단/중단 배포
=> 서비스를 중단하지 않고 / 중단하고 배포하는것 -> 업데이트 / 점검
==> 사용자 입장에서는 무중단이 당연히 좋지만 무중단이 꼭 좋은것은 아니다
==> 너무 큰 비용의 발생 / 코드나 스키마의 버전 교체 등등 => 중단이 필요한 경우가 있음

a => a + b => 무중단이 상관없음

a => a' or a' + b => 중단을 사용해야할 수도 있음

=> 애초에 무중단 배포의 원칙이고 / 신버전이 서비스에 동시에 적용될때 문제가 없어야함





●현재 위치 배포

무중단 배포를 하기 위한 방법 

로드밸런싱 되고 있는 서버들에 대해서 일부(예를 들어 절반) 서버를 로드밸런싱 그룹에서 제외하고, 배포를 진행 => 나머지 절반은 문제없이 서비스 진행중 

=> 배포가 완료된 서버로 서비스를 진행 -> 나머지 절반의 서버에 배포를 진행
==> 로드밸런싱 대상에 모든 서버를 올림

=> 새로운 인스턴스를 생성하지 않기 때문에 비용적으로나 시간적으로나 효율적이지만, 배포를 진행하는동안 인스턴스(서버)의 수가 줄어들기 때문에 트래픽에 대해 조심해야함


●블루/그린 배포

무중단 배포를 하기 위한 방법
 
=> 2개의 그룹을 가지고 진행
=> 여기서 말하는 그룹은 대상그룹 / auto scaling 둘다 될 수 있음

 

 

 

-서버단위

로드 밸런서 -> 블루 그룹만을 통해서 서비스하는 중 

블루그룹 => 현재 버전이 배포된 그룹
그린그룹 => 블루 그룹과 똑같은 수의 서버 인스턴스를 생성 => 새로운 배포를 적용

====> 블루 그룹을 통해서 서비스 하는 중 



그린그룹의 배포가 끝나면 로드밸런서에 그린그룹도 추가 
=> 블루 그룹을 로드밸런서에서 제거 
==> 블루 그룹의 인스턴스(서버)를 제거  -> 그룹의 제거 x / 인스턴스를 제거
==> 모든 작업 완료


==> 다음 배포가 있을 경우에, 반대로 진행해주면 됨 



장점
: 구 / 신 버전이 동시에 존재하는 시간이 짧음
=> 새로운 버전을 다 준비한 후에, 로드밸런서에 붙여주기 때문에 

: 롤백을 굉장히 빠르게 할 수 있다는 것
=> 구 / 신버전을 그룹으로 나누어 놓았기 때문에, 신버전에 문제가 생길시 바로 구 버전으로 롤백할 수 있음


: 서비스 하는 인스턴스(서버)의 수를 줄이지 않아도 됨 
=> 서비스를 하는데 트래픽에 대한 부담이 없음


     +-----------------------+----------------------+
     |                   load balancer                 |
     +-----------------------+----------------------+
                                    |
                                    |
                                 ↙
                           ↙
                     ↙
+-------------------------------+----------------------------+
|             BLUE                |            GREEN           |
+-------------------------------+----------------------------+
| Current Production       |     Next Release         |
| Version: 1.0                  |     Version: 1.1            |
| Status: Live                  |     Status: Testing        |
| Last Deployed: Date    |  Last Deployed: Date  |
| Traffic: 100%                |       Traffic: 0%             |
+------------------------------+------------------------------+

=> 원래 버전으로 서비스를 하고 있다가 
=> 최신 버전에 대한 배포가 끝나면 

     +-----------------------+----------------------+
     |                   load balancer                 |
     +-----------------------+----------------------+
                                    |
                                    |
                                     ↘
                                         ↘
                                              ↘
+-----------------------------+----------------------------+
|             BLUE              |            GREEN           |
+-----------------------------+----------------------------+
| Current Production     |     Next Release         |
| Version: 1.0                |     Version: 1.1            |
| Status: Live                |     Status: Testing        |
| Last Deployed: Date  |  Last Deployed: Date  |
| Traffic: 100%              |       Traffic: 0%             |
+----------------------------+------------------------------+

 

=> 최신 버전으로 서비스를 함
=> 이런식으로 서버 전체를 하나의 그룹으로 묶어서 배포작업을 진행
=> 여러개의 인스턴스를 사용한다면 이런 방식으로 해야함 





-서버내
=> 많지않은 양의 인스턴스(1-2개)를 사용한다면 서버내에서 해도됨
=> 서버단위로 그룹화 하는것이 아니라 => 포트로 구분함