AWS2 RDS (3)모니터링, 백업과 복원, 마치며

===

DB서버를 운영하기 시작했다면 서버의 상태를 파악하는게 굉장히 중요

인스턴스를 클릭해서 들어가보면

그럼 CloudWatch라는 섹션이 있는데, 얘는 RDS내의 기능이 아니고, 독립된 AWS의 모든 인프라의 상황을 관제할 수 있는 파악할 수 있는 독립된 서비스

 

원래는 CloudWatch에 데이터가 모이는데, 서비스 내에서 보면 편하니까, RDS에다가도 보여주고 있는 것

이 CloudWatch 부분이 선택돼야 CloudWatch다

 

첫번째 페이지에 나오는게 아무래도 중요한 것들이겠죠 3페이지까지 여러가지 항목들이 있다

 

CPU 사용률 : RDS가 돌아가는 컴퓨터의 CPU 점유율, 계속 높게 나타나고 의도한게 아니면 RDS인스턴스 타입중 cpu쪽이 강한걸 고려해보는게 좋다.

 

DB 연결 : DB클라이언트가 DB서버에 접속을 할 때 접속 하나하나가 연결이다. 연결이 꽉차면 성능에 큰 영향을 미치기 때문에 연결이라는 지표도 중요하다.

 

여유 스토리지 공간 : 중요하겠죠. 꽉차면 못쓰니까. 꽉차기 전에 조치를 취해야. CloudWatch에는 어떤 조건을 걸어놓으면 그 조건에 해당됐을 때 이메일을 보낸다든지 어떤 작업을 하게 할 수 있다. 여유스토리지에 하한을 정해놨다가 그 상황에 도달하면 경보가 울리면서 이메일이나 메시지같은 것들이 가도록 할 수 있다.

 

사용 가능한 메모리 : 꽉차있으면 느리다. 그러면 메모리가 강한 인스턴스로 업그레이드 고려하기

 

IOPS : Input Output Per Second, 초당 입력과 출력에 대한 성능. 저장장치의 성능을 파악할 때 많이 사용되는 벤치마킹 지표. 얘가 어느정도가 적당한가, 이것은 여러분이 선택한 스토리지의 성능이 있을텐데 스토리지의 iops를 지정할 수가 있고, 그 iops와 여기에 기록되는 iops를 비교해서 더 높일지 낮출지를 파악하는게 필요

 

기타 등등..

 

===

확장 모니터링은 기능을 켜야 사용이 되고, 유료다

 

CloudWatch와 확장모니터링은 둘다 비슷하게 시스템의 상태를 보여주는데 CloudWatch는 컴퓨터의 하드웨어 감시

확장 모니터링은 DB서버가 설치돼있는 운영체제 안에다가 프로그램을 심어서 그 프로그램이 실시간으로 현재 상태를 전송해줌. 제가 알기로 1초 간격으로 데이터를 업데이트 시켜주는 기민한 서비스. (CloudWatch는 1분에 한번씩 기록)

 

 

===

OS 프로세스 목록은

실행되고 있는 컴퓨터의 운영체제 상에서 여러가지 실행되고 있는 프로그램들의 상태를 보여주는 그런 지표

 

===

각각의 지표가 뭔지 알았으면 수 감각을 갖는게 중요하다. = 각각의 상태가 어떤 상태가 일반적인 여러분 시스템의 상태인지를 계속 보고 있으면 나중에 어떤 문제가 생겼을 때 어떤 특이점에 의해 문제가 발생했는지, 또 어떤 특이점이 다가오고 있는지에 대한 수 감각을 갖게됨 => 정확한 의사결정 가능, 쉽지 않은 일이다. 자주 봐야된다는 말.

 

============

5. 백업과 복원

인스턴스가 있으면 인스턴스에 대한 설정을 지정하는 것중에

인스턴스 및 IOPS쪽에 백업 자동화 라고 돼 있는게 있다 : aws는 백업을 8시간 간격으로  기본적으로 한다. 그 우리가 만든 백업을 7일 동안 보관하겠다 라는 뜻.

 

저 값은 지정안해서 백업을 안할수도 있고 맘대로 지정할 수 있다. 길게 지정할 수록 안정감이 있고 돈이 더 든다

백업 기간은 백업을 몇 시에 하는지

 

백업타입 : 백업이 두가지 타입이 있는데, 모든 변경 사항들을 다 기록하는 백업이 있는데, 그 백업타임을 이용하면 초단위로 그 어떤 특정한 시기로 돌아갈 수가 있다. 저 쓰여져 있는 건 저 시간까지 복원이 가능하다는 말. 저 시간은 5분 단위로 갱신된다고 AWS가 설명한다

 

내가 설정을 하는것으로 백업에 대한 정책을 바꿀 수 있다.

 

===

여기 스냅샷에 현재 백업된 버전들이 보인다

이 시간까지의 전체 데이터가 담겨있다.

자동화는 자동으로 백업한다고

필요에따라 위험한 작업을 하기 전에 DB전체를 백업해놓을 수가 있다.

이 스냅샷 만들기

스냅샷이 생성이 되기 시작하고,

DB형식에 따라 DB가 잠깐 꺼지는 다운 타임이 발생할 수도 있다.

서비스를 켜놓고 백업을 진행하면서 서비스가 잘 돌아가고 있는지 체크하는 것도 필요할 겁니다.

 

===

백업을 복원할 때는 

스냅샷을 선택하고 그 페이지에서 스냅샷 복원

그럼 인스턴스를 새로 생성하는 화면이 나오는데 

기존에 있던 인스턴스를 옛날로 돌리는게 아니라 새로운 인스턴스를 만들고 그 인스턴스에 내가 복원하고 싶은 지점을 적용시키는 방식이라서

 

===

특정한 시기로 정교하게 돌아가고 싶다면

여기서 원하는 인스턴스를 선택하면

용어가 헷갈리는데 

가장 빠른 복원 가능 시간 : 이 이전시간으로는 복원할 수 없다.

최근 복원 가능 시간 : 이 시간보다 더 최근의 변화로는 복원할 수 없다.

범위를 표현해주는 것

여기 Actions에 특정 시점 복원을 선택하고 

최근 복원 가능 시간은 최대한 빨리

사용자 지정은 초까지 지정할 수 있다.

 

===

*자동 백업은 인스턴스를 삭제하면 걔도 삭제된다.

*수동으로 백업한 것들은 인스턴스가 삭제돼도 삭제되지 않으니까 나중에라도 그걸 이용해서 복원할 수 있다.

 

인스턴스를 삭제할 때 스냅샷을 만들거냐고 물어본다. 어떤 경우라도 반드시 스냅샷을 만들어놓고 삭제를 하세요. 삭제하면 절대로 안되는걸 삭제하는 경우가 있을 수 있다.

 

복원의 핵심은 수련이다. 사태가 생기면 복원하면 되지 라는 생각은 안일할 수 있다.

사태가 발생했을 때 능수능란하게 복원할 수 없다면 초조해서, 시간이 없어서 복원을 하는 과정에서 굉장히 심각한 실수를 할 수 있다.

 

===

6.가격

https://youtu.be/qVo9KJKCc0Y

밑에 MySQL을 선택하면

여러분은 온디맨스 DB 인스턴스 / 예약 DB 인스턴스 둘중 하나를 선택 해야해. 둘다 DB서버가 동작하는 컴퓨터의 사양과 관련

데이터베이스 스토리지 : 데이터를 저장하는 저장장치의 크기와 관련

백업 스토리지 : 데이터를 백업할 때도 스토리지가 필요, 그 스토리지와 관련

데이터 전송 : 인터넷 사용 요금

 

AZ : Availability Zone, 가용성 지역. 지역마다 건물이 두개에서 세개 독립된 건물이 있어.

단일 AZ는 하나에만 서버와 데이터를 저장.

다중 AZ는 2개의 건물에다가 동시에. 훨씬 더 안전

 

온디맨드 DB 인스턴스를 보면

리전

인스턴스(컴퓨터의 사양, EC2쪽으로 가면 어느정돈지 알 수 있다), 시간당 금액을 월로 계산해서 감잡기

 

예약 DB 인스턴스를 보면 꽤 복잡함

n년 계약해서 할인받는 것

선결제 없음 : 월정액

부분 선결제 : 할인쿠폰, 대부분은 켜져 있는데 끄는 경우가 있다면 이렇게.

전체 선결제 : 1년 내내 키면 이 금액이라고

 

===

데이터베이스 스토리지

범용 스토리지, 처음시작하시는 분. 저렴하고 느림. 속도를 지정할 순 없는데, 저장장치 크기 키우면 빨라짐

프로비저닝 IOPS(SSD) 스토리지 : 크기 지정, 속도 지정. 속도가 아주 중요(동접↑)한 DB라면 이것 써서 속도 직접 튜닝

마그네틱 스토리지(DB쓸땐 이거 안쓴대)

 

===

백업 스토리지

자동 백업, 스냅샷 백업 등의 용량에 대한 금액

리전의 전체 DB스토리지의 100%에 해당하는, 10기가 구매하면 10기가까지의 백업데이터는 공짜. 

10기가를 샀다면 보통 1기가 정도의 데이터를 사용함. 백업을 한다면 그 1기가를 대상으로 백업이 진행된다.

실제로 사용하는 데이터가 저장소의 전체 크기보다 적다. 대부분의 고객들은 백업 스토리지에 대한 비용을 지불할일이 없을 것입니다.

 

===

데이터 전송 :

DB서버쪽으로 요청이 들어오면 돈 안내지만, 응답할 때는 돈을 냄

RDS에서 다른 AWS의 서비스로 보내는 내용. CloudFront로 보내는건 공짜

 

===

실습을 위해 만들어놨던 인스턴스 삭제하기.

수정

그리고 즉시 적용

자동 백업 데이터는 다 날라가니까 명시적으로 만들거냐. 무조건 하세요 우리 자신을 불신해야 합니다 사용자를 위해.

Retain automated Backups : 체크가 돼 있으면 자동 백업은 삭제가 안된다. 어 이런게 있었네요 하신다

 

===

Multi Availability Zones

다중 가용성 지역

DB는 데이터를 안전하게 보관하는게 중요하다. 예산이 허락된다면 이 옵션 쓰세요

 

 

===

Scale UP : 컴퓨터의 사양을 높이는 걸 통해서 성능향상

과거에는 DB사양을 높이는게 쉽지 않았다. DB가 세팅이 돼 있으니까

RDS같은 서비스를 사용하면 전혀 어렵지 않다. 클라우드 콘솔에서 클릭클릭만 하면 돼

 

Scale UP은 한계가 있다. 한개의 컴퓨터가 가질 수 있는 성능은 한계가 있기 때문.

 

인간이 사회를 이루듯이 여러대의 컴퓨터가 협력할 수 있도록 애플리케이션을 변경시키면 돼

 

쓰기와 관련된 작업을 전문적으로 하는컴퓨터와 읽기를 구분.

->그래도 부족하면 읽기를 여러대 붙이기 : 굉장히 많은 부하를 견딜 수 있게 됨

Scale을 옆으로 확장시킨다는 점에서 Scale Out

 

AWS에서는 읽기 전용 DB를 쉽게 만들어서 붙일 수 있는 방법을 제공하기 때문에 이 솔루션을 적용하시면 됩니다.

 

===
오로라는 AWS가 만든 DB다. MySQL과 PostgreSQL과 호환된다.

이 두개로 만들어진 애플리케이션이라면 그대로 오로라로 전환할 수 있다.

AWS가 mysql보다 5배 빠르고 Post쟤 보단 3배 빠르대

오라클같은 고가의 상용 DB에 비해 1/10가격으로 상용서비스 수준의 보안과 안정성을 제공한다고 홍보함.

10기가가 기본이고 꽉차면 자동으로 10기가가 늘어나는 식으로 64테라바이트까지 자동으로 늘어남. 용량이 꽉차면 어떡하지 같은 걱정은 안해도 된다.

 

최근에 오로라 Serverless라는 버전이 출시했는데, 이걸 쓰면 내가 DB를 쓰고 있지 않은 동안은 컴퓨터가 꺼져있다.

DB사용하는 시점에 순간적으로 컴퓨터가 켜지면서 사용한 만큼 요금을 내면 된다.

사용량이 많아지면 더 높은 사양 컴퓨터로 자동 교체되는 AutoScaling이 적용된 제품이기도 하다. DB사용량을 예측하기 어려운 분들에게는 아주 좋은 솔루션