추가 공부 참여율이 떨어지는 듯하여, 5주차부터는 추가 공부 없이 레퍼런스 문서로 질문과 답을 동시에 드리는 방식으로 변경했습니다.
localhost가 뭘까?
클라우드에 서버를 구축하고 애플리케이션을 실행하면, 해당 서버의 고정 IP로 HTTP 요청을 보내서 원하는 템플릿 파일을 받을 수 있습니다. 그런데 문득 이런 의문이 듭니다. (나만 그랬을 수도..) 지금까지 저희가 개발을 하고 테스트할 때는 브라우저로 localhost:8080 에 접속하여 결과를 확인했습니다. 템플릿 파일은 내 컴퓨터에 있는데, localhost에 요청을 날렸더니 그 파일을 찾아서 브라우저에 출력했습니다. 어떻게 이것이 가능한걸까요? 직관적으로 생각해보면 localhost가 네트워크 상에서 내 컴퓨터를 가리킨다고 할 수 있어요. 너무 당연한 말처럼 들리는데요. localhost가 실제로 네트워크에서 어떻게 내 컴퓨터를 가리키는지 알아보겠습니다.
위의 그림은 localhost로, 아래 그림은 127.0.0.1에 접속한 결과입니다. 완전히 동일한 것을 알 수 있어요. 이 말은 localhost라는 도메인의 실제 ip 주소는 127.0.0.1라는 것입니다. 127.0.0.1는 네트워크에서
특수한 ip주소인데요, 루프백(loopback) 혹은 로컬호스트 주소(localhost) 라고 부릅니다.
네트워크 통신은 호스트 둘이 패킷을 주고 받는 것을 말합니다. 송신 호스트의 네트워크 계층에서 수신 호스트의 네트워크 계층에 패킷을 전송하면 상위 계층은 패킷을 분해하여 순수 데이터를 얻습니다. 그런데 이때 목적지 IP 주소가 루프백이라면 송신 호스트는 외부로 패킷을 전송하지 않습니다. 전송하지 않고 고스란히 자신이 다시 받은 것처럼 처리하여, 상위 계층으로 올려 보냅니다. 즉 자신이 송신한 패킷을 그대로 수신한 효과를 줍니다.
루프백을 활용하면 별도의 서버와 네트워크를 구축할 필요 없이 자신의 컴퓨터로 개발 내용을 확인할 수 있습니다. 그래서 localhost를 개발 환경으로 주로 사용하는 것입니다. 하지만 거꾸로 말하면 다른 컴퓨터에서는 이 주소에 접근할 수는 없다는 의미가 됩니다. localhost는 자신의 컴퓨터를 가리키는 특별한 주소인데, 해당 템플릿 파일을 가지고 있지 않은 외부 컴퓨터는 아무리 localhost로 요청을 날려봤자 파일을 받을 수 없을 것입니다.
그래서 우리가 해야 하는 작업은 우리가 개발한 애플리케이션을 다른 사용자들도 접속할 수 있도록 서버를 구축하는 것입니다. 서버-클라이언트 구조에서 서버는 24시간 구동되어야 합니다. 이런 서버를 개인이 만들려면, 안 쓰는 컴퓨터에 서버 애플리케이션을 실행하고 24시간 구동해야 합니다.(홈 네트워크) 기업이라면 서버실을 따로 두고 여기에서 접속을 관리합니다. 이러한 방법은 초기 비용이 클 뿐만 아니라, 네트워크를 잘 알고 있는 인력이 있어야 가능합니다. 이것이 부담스러운 사람들을 위한 선택지가 바로 클라우드 컴퓨팅을 활용하는 것입니다. 자세한 내용은 다음 단락에서 이어가겠습니다.
💡 localhost는 개발 환경이다. 다른 컴퓨터는 이 주소로 우리의 컴퓨터에 요청을 보낼 수 없다. 따라서 24시간 구동되는 서버를 따로 구축해야 한다.
개발 환경 나가면 개고생이라는 의미로 사용되는 밈입니다. 우리의 미래일지도…
왜 클라우드를 사용해야 할까?
클라우드 컴퓨팅이 등장하기 전에도 서버는 존재했습니다. 서버를 통해 서비스를 제공하는 기업들은 자체 시설에서 데이터 센터, 애플리케이션 서버, 웹 서버 등을 보유하고 직접 유지 관리했습니다. 그러다보니 초기 비용이 많이 들고, 네트워크를 잘 알고 있는 인력이 필요했습니다. 더 큰 문제는 사용자들의 요청에 유연하게 대처하기가 어렵다는 점이었습니다. 요청이 갑자기 늘면 서버를 한대 더 구입해 네트워크에 연결하고 SW를 설치해야만 했습니다. 그러다 요청이 줄면 노는 서버들이 생기고, 결국 비용 낭비로 이어집니다.
이 방식을 온프레미스라고 합니다. 인프라를 직접 구축하는 것이므로 기업의 요구 사항에 더 잘 맞는 운영이 가능하지만, 적은 자원으로 시작하는 창업자나 우리처럼 개인 서비스를 운영하는 사람들 입장에서는 비용과 시간이라는 단점이 너무 커서 도입하기 부담스럽습니다. 그래서 클라우드 서비스가 등장한 이후에는 물리적 장비와 운영에 필요한 기능을 원격 환경에 세팅하여 사용하는 방식이 온프레미스의 대안이 되었습니다.
요즘에는 보수적이기로 유명한 금융권도 클라우드를 도입하고 있는 추세입니다. 빅테크 기업들의 사업 확장으로 위기감을 느낀 기업들이 비즈니스 모델을 빠르게 디지털 위주로 전환하기 위해 클라우드를 도입하고 있습니다. 거대한 고객 데이터와 유동적인 서비스를 위해 클라우드를 활용하고 있다고 합니다. 재정이 충분한 금융권조차도 대용량 데이터와 기하급수적으로 커지는 디지털 수요를 감당하기 위해 클라우드를 도입하고 있으니, 다른 기업들은 더 적극적으로 클라우드 서비스를 사용할 것입니다. 채용 공고 조건에서 클라우드 환경에서의 서비스 구축 경험을 어렵지 않게 찾을 수 있는 것을 보면 말 다했죠!
물론 아주 큰 회사에 들어가면 인프라 엔지니어들이 따로 있기는 하지만, AWS를 적극적으로 사용하고 있는 회사라면 AWS의 다른 서비스를 조합해서 빅데이터를 처리하거나, ML 모델을 학습하고 배포하거나, 서버리스 서비스를 통해 애플리케이션 개발에 사용할 수도 있습니다. 인프라 엔지니어가 따로 없다면 보통 서버 개발자가 인프라까지 다룬다고 합니다.
EC2 인스턴스를 생성한다는 것은 무슨 의미일까?
EC2 인스턴스를 생성한다는 것은 가상 서버를 구축한다는 말입니다. AWS가 가지고 있는 HW 장비를 일부 빌려, 해당 자원에 OS를 설치하고 네트워크를 구성해 내가 개발할 애플리케이션을 실행하면 배포 완료입니다. 우리가 인스턴스를 생성하며 설정했던 값들을 살펴볼까요?
인스턴스 설정값
AMI
저희는 Amazon Linux AMI를 사용했는데요, 여기에는 아마존이 제공하는 레드햇 기반의 리눅스가 있습니다. 그래서 생성한 인스턴스에 접속했을 때 리눅스 환경으로 접속할 수 있었던 것입니다.
AMI는 개인이 만들 수 있습니다. 같은 구성의 서버를 복제하거나, 구축한 서버의 백업용으로 사용하면 편리합니다. 웹 서버으로 활용할 서버를 여러개 만들려고 한다면, 해당 AMI에 서버 OS, 아파치, 그외 소프트웨어 등을 넣어두고 해당 AMI를 선택하여 인스턴스를 만들면 됩니다.
AMI(Amazon Machine Image)는 EC2를 지탱하는 중요한 요소 중 하나입니다. AMI란 소프트웨어 구성을 기록한 템플릿입니다. AMI는 서버 디스크에 설치된 내용이 통째로 들어있어서, AMI에서 인스턴스를 생성하면 모든 것이 복사됩니다. AMI를 사용하면 동일한 설정의 서버를 손쉽게 대량으로 만들 수 있습니다.
인스턴스 유형
인스턴스 유형은 머신의 용도를 말합니다. CPU, 메모리, 스토리지, 네트워크 등 필요한 컴퓨팅 자원이 용도에 맞게 조합되어 있습니다. 저희가 생성할 때 선택했던 T2가 이것입니다. 규모에 따라 크기도 선택해야 합니다. 단가는 인스턴스 유형과 크기에 따라 다르게 책정됩니다.
VPC, 서브넷
웹 서버나 데이터베이스 서버와 같은 서버들은 같은 네트워크에 연결되어 있어야 합니다. AWS 서비스인 EC2나 RDS도 마찬가지로 네트워크에 연결되어 있어야 하는데요, 이러한 네트워크를 구축하기 위해 사용되는 것이 Amazon VPC입니다. Amazon VPC는 AWS 계정 전용 가상 네트워크 서비스로, AWS에서 제공하는 리소스만 설치할 수 있습니다. 특히 EC2나 RDS는 VPC를 선택하지 않으면 서버를 생성할 수 없습니다. AWS에 VPC를 생성하고, 그 안에 서버(인스턴스)를 설치합니다.
보안 그룹
보안 그룹은 VPC의 가상 방화벽입니다. 방화벽은 네트워크 통신을 제어하는 방식을 말하는데요, 인바운드 규칙(외부 네트워크에서 EC2 인스턴스로 향하는 정책)과 아웃바운드 규칙(EC2 인스턴스에서 외부 네트워크로 향하는 통신 정책)을 설정합니다.
인바운드 규칙은 외부에서 이 인스턴스에 접속하려는 상황에서, 어떤 외부 접근을 허용할 것인지 지정합니다. SSH 접속을 담당하는 22번 포트로 들어오는 접속은 실습하고 있는 장소에 연결된 네트워크의 IP 주소를 가진 요청을 허용합니다. 웹 서버로 활용할 8080번 포트로 들어오는 접속은 모두에게 오픈하여, 어떤 사용자든 이 인스턴스의 8080번 포트로 요청을 보낼 수 있도록 허용합니다.
아웃바운드 규칙은 이 인스턴스에서 외부 네트워크로 응답이 나가는 상황에서, 어떤 외부 네트워크게 응답을 허용할 것인지 지정합니다. 이 인스턴스는 딱히 응답을 가릴 필요가 없으므로 모든 대상에게 포트 전체를 열어두었습니다.
아웃바운드 규칙은 이 인스턴스에서 외부 네트워크로 응답이 나가는 상황에서, 어떤 외부 네트워크게 응답을 허용할 것인지 지정합니다. 이 인스턴스는 딱히 응답을 가릴 필요가 없으므로 모든 대상에게 포트 전체를 열어두었습니다.
가상화
한편으로는 이런 의문점이 듭니다. 내 애플리케이션을 실행하기 위해 HW 장비를 빌렸다는건데, 그러면 인스턴스 하나당 AWS가 가지고 있는 컴퓨터 하나가 할당되는건가? 그럼 이 많은 수요를 AWS는 어떻게 감당하고 있는거지? 인스턴스 하나당 컴퓨터 하나를 할당하면 당연히 감당하지 못할 것입니다. 그렇다면 인스턴스는 컴퓨터 한대보다 훨씬 작은 단위의 HW를 사용하고 있다는 말이 되는데요. 이것이 어떻게 가능한걸까요?
그것은 바로 가상화라는 기술 덕분입니다. 가상화란 한 대의 시스템 하드웨어를 논리적으로 분할하여 가상의 시스템에 활용하는 개념입니다. 가상 시스템들은 서로 독립적인 하나의 시스템으로 인지되기 때문에 주어진 하드웨어 리소스를 효율적으로 사용할 수 있습니다.(HW를 제공하는 기업 입장에서) 또 제대로 격리가 이루어진다면 하나의 가상 시스템 안에서 문제가 발생하더라도 그 밖에 다른 영역으로 영향을 미치지 않는다는 장점이 있습니다. 내가 사용하고 있던 인스턴스에 문제가 생기더라도, 다른 사용자의 인스턴스에는 영향이 가지 않습니다.
가상화는 클라우드 컴퓨팅을 가능하게 만든 아주 중요한 개념입니다. 더 깊게 들어가면 내용이 엄청 어려워지는데요, 우리는 인프라 공부를 하고 있는게 아니니까 가상화 덕분에 우리가 HW 자원을 빌려서 독립적으로 사용할 수 있다는 정도만 알고 계시면 됩니다.
RDS와 EC2 연동하기
사실 RDS 서비스를 사용하지 않아도, ec2 인스턴스에 데이터베이스 서버 프로그램을 설치해서 ec2 인스턴스가 데이터베이스 서버로 동작하게 해도 됩니다. 하지만 그렇게 하려면 교재에서 언급한대로 모니터링, 알람, 백업, HA 구성 등을 직접 해야합니다. RDS 서비스를 사용하면 AWS가 알아서 관리해주니 부담이 훨씬 덜하므로 특별한 요구 사항이 있는게 아니라면(RDS가 지원하지 않는 DB 엔진을 사용하더던지) RDS를 사용하는 것이 좋습니다.
RDS와 EC2의 네트워크 설정
대부분의 경우 RDS는 EC2에 설치된 소프트웨어와 연동하여 사용합니다. 그러려면 EC2와 같은 네트워크에 위치해야 하고, EC2와 RDS 모두 같은 VPC에 위치해야 합니다. 대시보드에 들어가서 EC2와 RDS의 VPC ID를 보면 동일한 것을 알 수 있습니다.
또 EC2 인스턴스에서 RDS의 DBMS를 사용하기 위해, RDS 보안그룹의 인바운드 규칙에 EC2 인스턴스의 접속을 허용해야 합니다.
RDS 인스턴스 설정값
- 데이터베이스 엔진 : DBMS의 종류를 선택합니다. MySQL, PostgreSQL, Maria DB, Amazon Aurora 등
- 데이터베이스 인스턴스 : 인스턴스 클래스(EC2 인스턴스처럼), 스토리지 유형, 스토리지 용량, 자동 스케일링, 스케일링 임계 값, 마스터 사용자 정보 등
- 네트워크 설정 : VPC, 서브넷 그룹, 퍼블릭 액세스 설정, 가용 영역, 보안 그룹 등
- 데이터베이스 환경 : 데이터베이스명, 포트, 데이터베이스 파라미터 그룹, 옵션 그룹, 백업, 모니터링, 로그, 유지 관리, 삭제 방지, 암호화 등
RDS 서비스가 EC2 서비스와 다른 점은 매니지드 서비스라는 점입니다. 매니지드 서비스는 백업 및 업데이트가 자동으로 이루어지기 때문에 관리자가 수동으로 관리하지 않아도 돼서 관리 부담이 줄어듭니다. 다만 주의해야 할 점은, DBMS의 버전을 AWS가 자동으로 관리하기 때문에 업데이트하면 곤란한 시점이 수행되는 경우도 있습니다. 이때는 업데이트 시간을 지정해두어 사용자에게 미리 공지할 수 있습니다.
레퍼런스 문서의 대부분은 오가사와라 시게타카의 <그림으로 이해하는 AWS 구조와 기술>을 참고하였습니다. 300쪽 정도의 짧은 분량이고, 그림이 많아서 이해하기 수월하니 AWS 서비스에 관심이 있는 분들은 이 책을 읽어보시면 좋을 것 같아요. 이번주도 수고하셨습니다!