📔설명
컴퓨터에 대한 수요는 계속 달라지므로 EC2는 이러한 변화에 대응하기 위한 기능을 가지고 있다! 이번에는 인스턴스 규모를 유연하게 변경하는 방법을 알아보자!
🐳Scalability
Scalability : 변화하는 수요에 탄력적으로 공급 가능
EC2의 특징으로는 가상화, 종량제가 있다.
💻가상화
가상머신 : 물리적인 형태를 가진 컴퓨터가 아닌, 소프트웨어로 만든 가짜 컴퓨터
컴퓨터를 쓴다고 하면, 물리적인 기계인 Computer가 필요하다.
그리고 그 컴퓨터를 사용하기 위해선 운영체제를 설치해야한다.
가상머신을 사용한다고 하면, 운영체제에 프로그램(가상머신)을 하나 더 설치하는 것과 같다. 그리고 이 가상머신이 바로 운영체제 위에 설치되어있는 일개 프로그램에 불과하지만 자신이 CPU, 메모리를 가지고 있는 것 처럼 자신이 정말 컴퓨터 인 척을 하는 것이다.
물리적인 기계 위에다가 운영체제를 지금까진 하나를 설치할 수 있었지만, 가상머신 덕분에 여러개의 가상머신을 만들어 운영체제를 설치할 수 있는 것이다.
ex)VMWare, VirtualBox etc..
우리의 컴퓨터에서 가상머신을 운영하기 위해선 어쨌든 컴퓨터 한대가 필요한 것과 마찬가지로, AWS에서도 많은 요청을 처리하기 위해서 어마어마하게 많은 물리적인 컴퓨터를 보유해둔다.
만약, 스타트업에서 클라우드 컴퓨팅을 사용한다면, 저렴한 컴퓨터를 사용할 수 있다. 싼 것이 장점! (동시접속자가 별로 없기 때문!)
하지만, 큰 회사이고 강력한 컴퓨터가 필요하다고 하면 강력한 컴퓨터를 대여하면 된다. 이 강력한 컴퓨터는 여러개의 물리적인 컴퓨터를 묶어 마치 한 대의 컴퓨터 인 것 처럼 해주기 때문에 가능하다.
⛅클라우드 컴퓨팅 이용 vs 이용x
빨간 선은 접속자의 수로, 접속자가 늘어나기도 하고, 없어지기도 한다.
우리 컴퓨터는 저렇게 유동적이지 않다!
수요가 올라감에 따라 컴퓨터(인스턴스)를 더 늘려서 수요에 공급을 맞춰줄 수 있다.
💪🏻Scale Up
Scale Up : 웹사이트에 접속자가 늘어나거나 줄어드는, 컴퓨터적 수요가 계속적으로 변화하는데 이 수요에 탄력적으로 대응하는 방법
컴퓨터 수요가 늘어나면, 더 좋은 컴퓨터로 업그레이드 해서 대체하는 것이다.
이 전략을 EC2인스턴스에서 실현해보자!
그러기 위해선 컴퓨터가 두 대 필요하다. 한 대는 마치 사용자가 늘어나고 있는 상황을 시뮬레이션 하기 위해서, 다른 컴퓨터(서버)에 막 접속하는 모습을 표현하기 위해서이다!
즉, 두 개의 인스턴스를 만들어보자!
😥스트레스 테스트 준비
먼저 웹서버 인스턴스를 빠르게 만들어보자!
테스트를 위해선 다소 무거운 웹 서버가 필요하다!
그러므로 기능이 많아서 좀 비교적 무거운 wordpress를 수비쪽에 두자.
일단, wordpress인스턴스를 먼저 생성하자!
여기서 한 대로 빠르게 해보자!!
wp로 이름을 지정해서 인스턴스를 생성하고 이번엔 공격쪽 인스턴스를 생성하자.
운영체제는 Ubuntu로 해주자! 이름은 user으로 지정하자!
wp에는 우리가 웹서버를 운영하는 입장의 인스턴스, user은 사용자의 접속을 시뮬레이션 할 곳이다.
우선 wp에 접속해보자. public DNS를 인터넷 주소창에 치자!
그 다음 cmd를 켜서 우리 wp에 접속하자!
우리가 만든 인스턴스의 cpu 점유율을 확인하고 싶다고 할 땐,
$top
명령어를 검색하면, 각각의 프로그램들이 얼마나 cpu와 메모리를 차지하는 지 보여준다.
이제 우리가 만든 user인스턴스로 접속을 해보자!
새로운 cmd를 켜고, 그 인스턴스로 접속하자!
우리가 접속을 하려고 직접 클릭하는 건 너무 힘든 일이다.
컴퓨터들끼리 싸움을 붙이기 위해서 사용자들이 많이 접속하는 시뮬레이션을 하는 소프트웨어를 설치할 것이다!
$sudo apt-get update;으로 먼저 업데이트 해주자.
$sudo apt-get install apache2-utils apache2-utils를 설치한다.
우리는 ab라는 프로그램을 쓸 것인데, 아파치에서 만든 부하 발생기이다!
requests : 웹서버에 몇 번의 접속을 시도할 지
concurrency : 동시에 몇 번의 접속을 시도할 것인가?
requests가 100이고, concurrency가 10이면, 한번에 10명이 접속하는 것과 같은 상황을 알려준다.
😣스트레스 테스트 시작
user 인스턴스에서 명령을 내려보자!
아래의 표 내용에 따라 요청, 동시접속을 변화시키면서 테스트를 해보고, 결과를 기록한다!
$ab -n 400 -c 1 접속할 Wordpress Public DNS
#Public DNS 앞에 http:// 꼭 필요, 끝에 / 붙이기
cpu 점유율과 메모리가 올라갔다.
ms는 s의 1/1000
계속해서, 표의 내용대로 테스트해보자!
| 요청 | 동시접속 | 총소요시간 | 실패 | 초당처리속도 | 개별처리속도(초) |
|---|---|---|---|---|---|
| 400 | 1 | 20.085 | 0 | 19.92(1초에 19번) | 0.050 |
| 400 | 2 | 18.637 | 0 | 21.46 | 0.093 |
| 400 | 10 | 19.469 | 0 | 20.55 | 0.486 |
| 400 | 20 | 19.460 | 0 | 20.56 | 0.972 |
| 400 | 20 | 19.462 | 0 | 20.55 | 2.432 |
| 400 | 100 | 19.513 | 0 | 20.50 | 4.878 |
| 400 | 200 | 19.724 | 0 | 20.28 | 9.861 |
위에서 ab명령어를 주면서, public DNS로 wordpress에 접속하면 접속하는데 정말 오래 걸린다!
👻Elastic IPs
우리의 인스턴스를 이미지화 시키고, 그 이미지화 시킨 인스턴스를 다시 켜서 인스턴스 타입으로 변경하면 Scale Up이 된다.
하지만, 이전에 만든 wordpress를 사용자들에게 IP로 접속하게 했다고 치자.
그러나 인스턴스를 중지 시키고 다시 실행 시키면 IP와 DNS가 달라진다.
우리는 지금 인스턴스를 이미지로 만들려고 한다. 이미지로 만들어 놓고, 더 좋은 인스턴스 타입의 컴퓨터를 만들려고 하는 것이다. 하지만 기존의 IP로 접속을 더 이상 못하게 되는 것이다. (IP와 DNS가 중지 시키면 달라지니까!)
우리가 아마존으로부터 IP Address를 받고 소유하면 된다!
Elastic IP : 고정 아이피. 컴퓨터를 교체해도 사용자는 동일한 IP를 통해 서비스에 접근할 수 있는 방법
위의 버튼을 누르고 할당을 하면, IP를 준다.
그러나 하나만 무료!!
탄력적 IP를 삭제하려면 릴리스를 누르면 되고, 이전의 인스턴스와 연결하려면 연결을 하면 된다.
인스턴스에는 wp를 선택하고 프라이빗 IP 주소에 뜨는 것을 선택한 후 연결을 누르면 된다.
그러면 이제 인스턴스를 중지했다가 다시 실행시켜도 동일한 IP로 접속할 수 있다!
🐾인스턴스 교체
일단 wp 인스턴스에 우클릭을 해서 이미지 생성을 하자.
이미지 이름은 아무렇게나 해도 된다.
그 다음 이미지 생성 버튼을 누르면,
이미지가 만들어져있다!
이제 이미지로 인스턴스를 만들기 전에, 어떤 인스턴스 타입을 결정할 지 정해야한다.
우리가 생성한 이미지에서 우클릭을 해서, AMI로 인스턴스 시작을 누르자!
그러면 이전 인스턴스 시작과 같은 페이지가 나오면서, 인스턴스 유형을 바꿔주면 된다!
돈이 나가니까 이것은 실습하지 말자!!
새로 만든 인스턴스에다가 elastic ip를 부여해주면 된다.
그 새로 만든 인스턴스로 스트레스 테스트를 해보자!
확실히 인스턴스 타입이 변경되니까 훨씬 더 빠르다!
그러나 여기있는 모든 인스턴스 타입을 이용해도 한계에 도달 할 때가 있는데, 그 때는 Scale Out인 여러개의 컴퓨터가 협력해서 트래픽을 감당하는 것에 대해 알아보자!
🤝🏻Scale Out
Scale Out : 여러 대의 컴퓨터가 협력해서 동일한 목표를 달성하는 것
즉, 컴퓨터의 사회를 만드는 것과 비슷하다.
🧊Scale Out의 흐름
왼쪽은 우리의 서비스에 접속하는 사용자, 오른쪽은 서버라고 생각하자.
왼쪽의 사용자가 처음에는 적은 사람이 접속했으나, 나중에는 점점 더 많은 사용자가 접속을 하게 된다.
컴퓨터 한 대(인스턴스)에는 세가지의 소프트웨어가 설치되어있다.
웹서버, DB, 미들웨어
웹서버는 사용자가 접속한 것을 받아서 서버에서 처리한 것을 다시 사용자에게 돌려보내는 역할을 한다. ex)아파치
미들웨어는 DB와 웹서버 사이에 위치해서 실질적으로 웹 애플리케이션이 동작하는 방법을 정의해둔 것이다. ex)php, jsp spring, django
그러므로, 만약 한계에 도달하면, 셋 중의 하나를 다른 컴퓨터로 쫓아내는 것이다.
이런식으로 분리가 된다!
미들웨어는 이제 컴퓨터2의 DB에 접속해서 정보를 요청하는 것이다.
성능상의 저하가 있긴 하나 두개의 컴퓨터를 이용하는 것이 성능 상의 이점이 더욱 더 크기 때문에 Scale Out을 사용한다.
여기서 또 문제가 발생하면, Middleware 를 쫓아내서 3대의 컴퓨터로 작동하게 된다.
이렇게 했는데도 DB가 계속해서 느려지는 경우, 또 새로운 컴퓨터를 장만하고 다시 DB를 동일한 상태로 유지한다.
여기서 더 느려진다면 데이터베이스를 또 하나 더 장만하는 방식으로 늘려나간다.
여기서, 웹 서버의 컴퓨터를 늘리는 방법은 바로 DNS 설정을 바꿔서 사용자가 접속을 하면, DNS 서버가 우리의 웹서버의 IP를 알려주고 다른 사용자가 접속을 하면 또 다른 우리 웹서버의 IP를 알려주면 된다.
또는 로드밸런서라는 것을 사용한다.
로드 밸런서 : 부하의 균형을 잡아줘서 골고루 분산될 수 있도록 해주는 장치, 서비스, 또는 시스템
이렇게 되면 로드 밸런서의 IP로 접속하게 된다.
로드 밸런서는 만약 컴퓨터8이 죽으면, 사람들을 컴퓨터9와 컴퓨터 1로만 보내고, 컴퓨터9 성능이 좋다면 대부분의 사람들을 컴퓨터9로 보내는 기능을 가지고 있다.
AWS에서 로드 밸런서를 ELB라고 한다.
🚌ELB
AWS에서 ELB가 죽지 않도록 알아서 잘 처리해준다.
버튼을 눌러보자!
그러면 로드밸런서의 타입을 설정할 수 있게 된다.
로드밸런서 포트는 80번 포트지만, 인스턴스 포트는 다른 포트일 수 있다.
(http로 접속 시!)
Application Load Balancer를 눌러주자!
로드밸런서의 이름을 web-server로 지정해주자.
아까 말한대로 로드밸런서의 포트는 80번으로 잘 설정되어있다.
하나 지정되어있는데, 새로 만들자.
그 외에 설정해주고 로드밸런서 생성을 눌러주자!
로드 밸런서에 따로 설정해줘야 하는 것이 많아서, 이번에는 실습을 하지 않고 실습하는 과정을 살펴보기만 하려고 한다.
이제, 만들어진 로드밸런서의 DNS로 접속하면, ELB에 접속할 수 있다는 얘기이다.
🧭ELB 적용
우리가 만든 ELB는 지금 안에 텅텅 비어있다.
인스턴스를 만들고, 웹서버를 설치하고 하나의 인스턴스를 더 만들어서 부하 발생을 시켜 다투는 것을 확인해보자!
우선 Ubuntu 인스턴스를 생성하는데 이번에는 한번에 2개를 만든다!
(강의 영상을 캡쳐해서, 이전과 다른 화면이겠지만 많이 달라진 건 없으니!)
보안 그룹도 생성해준다.
각각의 인스턴스의 IP(public DNS도 가능)로 접속하자!
부하 발생기에서는 ab를 설치하자! (위에서 스트레스 테스트 했던 것처럼!)
웹서버에는 apache2를 설치하자! 웹서버에서 웹서버만 설치됐다고, 안힘들어하기 때문에 php를 추가로 설치해주자. 그리고 더 힘들도록 간단한 php코드를 작성할 것이다.
$sudo apt-get install php5;이 다음 php 앱을 하나 만들 것이다.
$cd /var/www/html해당 디렉토리로 이동하면 index.html이란 파일이 존재한다.
이 디렉토리에 index.php 파일을 만들것이다.
$sudo nano index.php이제 index.php 안에 아래와 같은 내용을 작성하자
<?php
for($i=0; $i<10000000; $i++){
}
?>헛 일을 아주많이 하는 코드이다.
그 다음 웹서버의 주소/index.php로 접속하자!
그 다음 부하발생기를 이용해서 index.php를 괴롭혀보자!
1000명의 접속자를 동시접속 5명으로 하면, 한 사람당 16초가 걸린다. 이 문제를
ELB를 사용해서 해결해보자!
ELB를 사용할 때 웹서버가 한개인 것은 의미가 없으니 이미지를 만든 다음, 그 이미지를 이용해서 인스턴스를 하나 더 생성해주자!
그 이후 로드밸런서를 이용해보자!
이전시간에 만든 로드밸런서를 선택하면, 인스턴스들이라고 된 곳에 edit instances를 선택하고 우리가 만든 웹서버 두개를 선택하고 누르면 인스턴스 두개가 elb에 붙게 된다.
이제 elb의 DNS Name을 주소창에 치고 /index.php를 뒤에 추가해주자! 그러면 빈 화면이 뜬다! (이게 정상!)
이제 각각의 웹서버에 사용자 입장으로 접속해보자!
사용자가 접속 시 log가 생기는데, 그 현황을 살펴보자!
$sudo tail -f /var/log/apache2/access.log로드밸런서에 접속하게 되면 두 웹서버에서 번걸아가면서 log기록이 남는다.
이제 부하발생기로 웹서버를 또 괴롭혀보자! 이번엔 뒤에 주소를 elb주소로 하자!
총 100번의 요청으로 동시접속을 10으로 하자!
log를 보면 웹서버 2대에서 번갈아가면서 log가 찍히고 있는 것이 확인된다!
이러한 수동으로 한 작업을 자동으로 규모를 조정해주는 것이 Auto Scaling 이다.
🛑ELB 주의사항
우리가 가지고 있는 웹 애플리케이션이 위와 같은 구성을 가지고 있다고 가정해보자. 이 상태에서 scale out을 한 다면,
이런 형태로 된다. 사용자1이 글을 쓰면, 컴퓨터1로 들어갔다고 치자. 그러면 디비에 글이 저장이 된다.
사용자 2가 글을 작성하면, elb를 통해 컴퓨터2로 들어가서 디비에 저장됐다고 생각하자. 다음번에 사용자 2가 접속했을 때, 컴퓨터1로 접속시킨다면 사용자가 그쪽 디비에서 글을 본다면, 자신이 작성된 글은 보이지 않는다.
왜냐하면, DB가 따로 있는 것이기 때문이다. 그러므로, 데이터베이스를 포함한 인스턴스는 scale out을 이런식으로 하면 안된다.
DB와 같은 것은 별도의 컴퓨터로 또 따로 빼서 별도의 컴퓨터로 저장해야한다!
🥚Auto Scaling
Auto Scaling : 우리가 수동으로 했던 컴퓨터를 만들고, 로드밸런서에 붙인 이런 작업들을 기계가 하도록 해주는 서비스
물리적인 컴퓨터를 그냥 쓰는 것 보다는 비용이 효율적일 수는 없지만, 이러한 탄력성이 클라우드 컴퓨팅이 주는 장점이다.
일단 부하발생기 인스턴스가 존재해야 하고, AMI에 웹서버를 ELB에 붙이려고 만든 이미지 webserver가 존재해야 한다. 이전수업에 진행을 못했기 때문에, 이번에도 영상을 보면서 알아보려고 한다.
Auto Scaling 부분에 가면 두가지 종류가 있다.
Launch Configurations는 인스턴스를 생성하는 행위를 말한다. 자세히 말하면 이미지를 실제 동작하는 인스턴스로 만드는 행위에 대한 설정이다.
Auto Scaling Groups는 우리가 위에 한 설정을 토대로 컴퓨터를 실제로 만들어준다.
🤩Launch Configuration
create를 눌러서 계속 진행해보자!
진행하면 먼저, launch configuration를 진행하게 된다.
우리가 인스턴스를 생성할 때 보던 화면을 보게 된다.
우리가 Auto Scaling을 하기 위해서는 Launch Configuration을 먼저 지정하는데, 이때 하는 것이 Auto Scaling에 사용될 이미지를 선택하는 것이 우선이다.
우리가 전에 만들었던 webserver이미지를 선택하자. (ELB 테스트를 위해서 만든것)
Launch Configuration의 이름을 지정하는 것이다.
즉, 설정의 이름을 지정하는 것인데 LC_날짜이런 식으로 지정해주자! (자유)
그 후 보안그룹 설정도 따로 해주자!
그 다음 Create Launch Configuration을 누르면 또 비밀번호를 설정하는 것이 나오고 그 이후에 버튼을 누르면 우리는 Launch Configuration을 만든 것이 된다!
👨👩👦👦AutoScaling Group 생성
위에서 정의한 컴퓨터를 언제, 어느 조건에서 만들 것인지를 지정하는 것이 AutoScaling Group이다.
Group name이라고 된 곳에 이름을 적자! AC_날짜와 같은 식으로 지정해준다.(자유)
그 위에 작성한 Launch Configuration은 아까 위에서 작성한 것에 해당한다.
Group size는 auto scaling을 시작했을 때, 몇 개의 인스턴스로 시작할 것이냐는 것을 지정한다!
Subnet은 그냥 클릭해서 있는 것을 클릭하면 되는데, 가용 구역이라고 생각하면 좋다.
이러면 Auto Scaling이 인스턴스를 만들 때 가용구역 여러개를 번갈아가면서 인스턴스를 생성하게 된다.
우리가 Auto Scaling을 정의해서 인스턴스를 만들면, 그렇게 만든 인스턴스를 특정한 Load Balancer에 자동으로 붙일 수 있는 것이다.
이전에 만든 ELB를 선택하고 Next:를 누르자!
규모 정책을 지정하는 것인데, 인스턴스를 어떤 조건에서 생성할지를 보여준다.
Keep this Group 머시기는 초기에 지정해둔 사이즈를 유지하는 것이다. 우리가 몇개의 인스턴스로 시작할 지 지정했던 것과 관련이 되어있다.
만약, 10으로 해뒀는데 인스턴스가 몇 개 죽었다면 자동으로 10개가 될 때 까지 생성한다는 것이다.
그 밑에 use scaling 뭐시기는 컴퓨팅의 필요에 따라서 인스턴스를 늘리고, 줄이고 하는 작업을 처리하는 것과 관련되어있다.
between부분에 상한과 하한을 지정하는 부분이다. 만약 1과 3으로 지정하면, Auto Scaling을 통해서 만들어지는 인스턴스는 최대 3개고, 최소 1개이다.
그 밑에 Increase는 Auto Scaling이 동작할 때, 어떤 때에 증가시킬 지를 선택하고, 그 밑에 Decrease는 감소에 대한 것이다.
Execute는 오토 스케일링을 통해서 만든 인스턴스들을 aws에서 감시하고 감시 과정에서 인스턴스들이 특정한 상태에 도달했을 때, 알람이 Auto Scaling에게 전달되도록 해준다.
Send notification은 알람이 울렸을 때 이메일이 가도록 하는 기능이다.
Whenever는 Cpu Utilization(Cpu 점유율)의 평균이 ex)60 이상이면, 그리고 이 상태가 5분이상 지속된다면 알람을 울리게 해주는 것이다.
알람이 울렸을 때, Take the action에서 Add 1 instances를 하면 인스턴스를 하나 만든다는 것이다. (cpu 점유율이 60프로 이상일 때)
이 설정은, cpu 점유율이 60이상 80미만이면 한 대의 인스턴스를, 80이상이면 2대의 인스턴스를 생성한다.
이부분은 인스턴스를 삭제하는 부분을 지정하는 것이다.
만약, cpu 점유율이 30프로 이하일 때로 지정한다.
그리고, remove 1로 하면, 30프로 이하의 cpu 점유율일 때, 인스턴스를 삭제한다는 정책을 지정한다.
그 다음 next를 하면 위와 같은 화면이 뜬다. 통보를 받을지를 하는 것이다.
통보 받을 이름을 지정하는 곳이다. autoscaling_start로 이름을 지정하고, 통보받을 이메일을 지정해주면 된다.
그 후 최종적으로 생성해주면 된다.
우리가 생성한 인스턴스를 살펴보면, 최소 1개, 최대 3개인 것을 확인할 수 있다.
300이라고 되어있는 것은, 300초 간은 쉬었다가 다음 작업을 계속 한다는 것이다.
그리고 밑에있는 것은 오토스케일링에 의해서 만들어진 인스턴스가 보인다!
이 밑에 있는 것이 오토 스케일링에 의해서 만들어진 것이다.
로드밸런서로 들어가보면,
오토스케일링으로 자동으로 만들어진 인스턴스가 로드밸런서에 붙어있다!
elb에게 이전처럼 스트레스 테스트를 해보자!
🥟AutoScaling Group 테스트
그 전에 이메일로 온 것을 Confirm Subscription을 해야 이메일을 받을 수 있게 된다.
Cloud Watch는 AWS에서 제공하는 여러가지 서비스들을 볼 수 있는 기능이다.
두 가지 알람 모두 우리가 만든 경보들의 리스트이다.
ALARM은 지금 우리가 만든 인스턴스가 지금 시피유 점유율이 30프로가 5분간 지속되었기 때문에 경보가 울려있는 상태이다.
OK는 cpu점유율이 60프로 이상일 때 인데, 지금 문제가 없으므로 OK라고 떠 있다.
파란색 부분은 현재 인스턴스의 cpu점유율을 말한다.
로드 밸런서의 DNS Name을 복사하자!
그리고 부하발생기를 위한 인스턴스와, 스케일링을 통해서 자동으로 생성된 인스턴스로 각각 접속을 해주자.
밑에 top명령어를 사용해주고, 위에서 ab명령어로 100000명을 동시접속 3을 허용해서 elb의 dns name/index.php으로 접속하자.
그러면 아래 인스턴스의 cpu점유율이 아주 높아지게 된다.
시간이 지나면, 알람이 위처럼 변하고 auto scaling으로 가면
지금 현재 만들어진 인스턴스가 3개이고, desired는 현재 필요한 인스턴스를 말한다.
즉, 3개의 인스턴스가 생성된 것을 확인할 수 있다.
이제 다시 Ctrl C를 눌러서 부하발생기를 멈춰보자.
다시 알림을 보니, 다시 다른 알람이 켜져있다.
Auto Scaling Group에 가보면 2개가 되어야 하는데 현재 3개인 것이다.
그리고 지금 하나는 삭제중인 것이다! 그러므로 desired와 현재 인스턴스 수가 곧 같아질 것이다!
이후 Cooldown 시간이 지나면, desired가 1로 변하면서 최종적으로 1대의 인스턴스만 남게 될 것이다.
어떤 인스턴스가 삭제될 지도 모르기 때문에 쓰고 버린다는 것으로 생각하는 것이 좋다.
실습이 끝나면, Auto scaling도 삭제하고, Alarms도 삭제해주자!
그리고 SNS HOME에 가서 이런 것들도 삭제해주자!
Subscription에도 뭐가 있으면 다 삭제해버리자.
다음엔 AWS를 제어하는 방법에 대해 알아볼 것인데, 6월 10일 SQLD 시험을 치고 돌아오도록!! 해야겠다.
