🌟 배포와 클라우드
개발 공부를 하며, 아직 시도는 못했지만 배포와 aws에 대해서는 익히 들어왔다.
"단순이 코드를 짠 단계인 즉 개발 단계였던 서비스를 퍼블릭하게 어디서든 접근 가능 하게 해주는 것"이 일종의 배포라고 볼 수 있다.
그리고 클라우드란, 해당 배포 서비스를 일종의 한 회사가 대신 도맡아 주는 것이다.
너무 간단하게 설명했나?
예를 들어, 과거에 모든 웹서비스 회사들이 각각 배포를 하던 시절에는
수많은 서비스를 돌리고 관리하기 위한 서버컴퓨터가 실제로 각 서버실에 배치되어있었다.
그리고 서버를 더 늘리기 위해서는 실제로 그 서버 컴퓨터의 수를 더 늘리는 식으로 서버가 관리되었다.
하지만, 이러한 하드웨어기반의 상황이 매우 비효율적이었고 (서버가 늘었을때, 컴퓨터를 더 샀다가, 다시 줄면...그 새로산 컴퓨터는 구동되지 않게 된다. 또 다른 사례로는 서버실 자체가 손상을 입게되면, 그 웹서비스의 서버는 그대로 사용불가하게 된다.) 배포와 배포 이후의 퍼블릭한 서비스의 사용, 그리고 다양한 사용자들의 접근에 대해 저장해주고 관리해주고 필요할 때마다 사용할 수 있게 해주는 클라우드 서비스가 나타났다.
클라우드 서비스는, 우리 일상에서 사진이나 다양한 문서들을 휴대폰이나 노트북 자체에만 관리하는 것이 불안해, 웹 상의 클라우드에 저장해 놓고, 하드웨어가 바뀌어도 그 데이터를 계속 이용하는 것을 상상하면 클라우드 배포 서비스를 이해하기 쉬울 것이다.
클라우드 서비스들은 사용자들에게(여기서 사용자는 웹서비스 제공자) 돈을 받고, 가상의 서버 컴퓨터를 빌려준다. 그리고 순간적으로 서버량이 늘면 가상의 컴퓨터를 추가해줘서 요금을 추가해서 받고, 다시 서버량이 줄면 그 가상의 컴퓨터를 떼어내준다.
모든 것이 가상이기 때문에 빠르게 이루어질 수 있으며, 웹서비스 제공자 입장에선, 그 복잡한 서버실을 관리하지 않아도 되고, 클라우드라는 가상의 저장소에 나의 서비스들에 대한 일종의 데이터를 저장해 두었기 때문에 손실에 대한 위험도 적어진다.
이러한 클라우드 배포 서비스의 대표격이 AWS 즉, 아마존 웹서비스 이다.
👉🏼내 멋대로 이름 붙인 AWS의 3대 BASIC 서비스
aws에 가입하고 서비스 신청만 하면 배포가 되는 줄 알았건만, 역시 개발의 세계는 그렇게 간단하지가 않다😂
클라우드 배포 서비스 중에서도 가장 보편화된 aws는 많은 서비스를 제공한다.
개발하는 서비스의 종류과 그 영역이 다양한 만큼 그 영역을 다 아우를 수 있도록 많은 서비스를 제공하는 것이다.
이 중에서 웹서비스 개발을 하는 사람이라면 가장 기본적으로, 그리고 필수적으로 알고 있어야 할 3개의 서비스가 있으며, 나는 이를 3대 BASIC 서비스라고 이름 붙여봤다.
웹서비스의 가장 기본적인 뼈대는 client->server->DB 이므로, 해당 영역들의 배포와 관리를 맡는 서비스라 할 수 있다.
1-1. S3 서비스
해당 서비스가 무엇인지 언제 사용하는지에 대해서 간략하게 설명해보자면
"배포하기 전 client 코드를 클라우드에 담아두고 관리하는, 일종의 cloud에서 client코드를 관리하는 서비스" 라고 할 수 있을 것이다.
물론 해당 서비스의 정확한 정의와 그 의미에 대해서 이야기하자면 더 방대하지만, "개발초보"를 위한 AWS서비스 설명이 아닌가?
결론적으로 client 코드를 배포하고자 할 때 s3 서비스를 이용하면 된다!
S3서비스는 일종의 bucket역할을 하며, 실제로 aws에서 S3를 이용하고자 하면 bucket 이라고 이름을 명명하기도 한다.
즉, client 코드들을 한데 모아 담아두어, 필요할 때마다(내 도메인에 접속하는 유저가 브라우저 창을 보기 위한 명령을 내렸을 경우가 대표적이지 않을까?) 이 bucket에 담아둔 코드들을 브라우저에 구현하는 역할을 한다.
실제로 우리가 하나의 웹서비스를 만들때, 프론트부분과 API코드를 구성하는 client코드는 수많은 코드와 파일들로 이루어져 있다. 가장 대표적으로 리액트를 활용하여 client코드를 짠다면, 수많은 컴포넌트 파일들로 이루어지게 될 것이다.
최종적으로 서비스를 퍼블릭하게 배포하고자 할 때, 이 수많은 코드와 파일들을 어떻게 잘 모아서 흐트러지지 않게 사용자에게 제공할 수 있을까? 에 대한 고민의 해결책이 S3 서비스 인것이다.
웹서비스를 구성하는 다양한 콘텐츠(프론트를 구성하는 파일들)들을 저장하는 서비스인 것이다.
S3서비스 자체적으로만 이용하고 버킷을 만드는 것에 있어서 어렵지 않다. client 코드들을 "yarn build" 하여 static한 코드들로 재구성해 주는 작업만 필수적으로 해주며 된다.
🌺 S3 서비스는 실제로 CLI즉, 터미널의 커맨드 라인으로 구현하는 것이 복잡하고 이것이 핵심이다.
이것에 대해서는 이후에 다뤄보고자 한다.
1-2. S3 서비스의 특징
a. 내구성 : 여기서 내구성이란, 파일이 유실될 가능성에 대한 안전도를 의미한다. 즉, aws의 S3서비스를 활용하면, 파일들이 유실될 가능성이 낮다는 것이다.
해당 서비스를 이용하지 않는 다면, 하드웨어적인 문제로 인해, 자체적으로 보관된 데이터들이 유실되거나 손상될 가능성이 있으나, S3 서비스를 이용한다면, 그럴 가능성이 낮다.
b. 비용 진입 장벽이 낮다 : 사용하는 빈도에 따라 요금이 부과되므로, 사용 비용이 저렴하다고 볼 수 있다.
c. SSL을 통해 보안또한 구현 가능하다 : 이는 이후에 더 추가적으로 알아보고자 한다.
2. EC2 서비스
웹서비스를 배포하고자 할 때 가장 핵심적인 부분이며, 개인적으로 클라우드 배포 서비스의 가장 기본적인 서비스가 아닐까 생각한다.
결국 웹서비스 배포를 더 효율적으로 해주고, 각각의 서버실들의 존재가 불필요하도록 해주기 위한 것에서 클라우드 배포서비스가 시작되었기 때문이다.
EC2서비스는 웹서비스의 가상 서버실이라고 생각하면 된다.
즉, 내가 웹서비스를 만들었고 배포를 해야 한다. 서버실을 스스로 만들어서 서버 컴퓨터들을 일일이 사는 것은 비효율이라 생각한다. 이 때, aws는 전 세계적으로 가상의 서버실들을 여러 군데 가지고 있다.
비유하자면 부동산업에 비유할 수 있겠다는 생각이 들었다. 즉 aws에서 전 세계에 서버실을 만들어 놓고, 그곳에 일종의 빌트인 가구들까지 다 구비해두어, 세입자는 그냥 돈을 주고 그 곳에 들어와 살기만 하면된다. 웹서비스 제공자인 나 또한, aws에 돈을 주고, 가상의 서버실을 구매하고 그곳에서 나의 서버가 돌아가게 된다.
aws에서 EC2 서비스 내의 각 서버컴퓨터들을 인스턴스라고 부른다. 즉 인스턴스 하나당 서버컴퓨터 하나인 것이다. 서버량이 늘게 되어 가상의 서버 컴퓨터를 늘려야 한다면 인스턴스를 추가해주고, 다시 서버량이 줄면 새로운 인스턴스를 중지해주기만 하면 된다.
새로운 서버실을 만들기 위해 우선 인스턴스를 시작하여, 셋팅을 해주게 된다. 셋팅을 하게 되면, 해당 서비스에서 알아서 내가 사용할 퍼블릭한 주소를 제공한다. 그리고 권한 설정을 해주어야 한다. 우선 초반 연습 단계에서는 위치 무관으로 하여, 어디서든 다 접근할 수 있게 해두면 되지만, 실제로는 권한 설정을 잘못하면, 과금될 확률이 높으므로...
이렇게 인스턴스를 설정한 이후에는 내 컴퓨터에 일종의 서버실의 틀을 가지고와서, 내부적으로 나의 서버 코드가 들어가서 자연스럽게 구동될 수 있도록 환경 설정을 해주어야 한다. nodejs로 서버를 만들어주었다면, 필요한 프로그램들을 다 다운받아 준 후에, 서버를 구동해주면 된다.
EC2의 권한 설정 부분에 대해서는 별도로 공부해보고자 한다.
그렇다면, 당연히 aws 서버를 셋팅해주는 단계가 필요할 것이다. 내가 만들어둔 서버를
임대한 가상의 서버실에 옮겨서 내가 구성한 대로 코드들이 돌아가게 하기 위해서 그 환경들을 마련해 주어야 하는 것이다.
EC2 서비스를 이용하는 것에 있어서 가장 핵심은, git 저장소에 나의 서버 코드들을 잘 옮겨두는 것이라고 볼 수 있다.
🌺 하지만 해당 서버를 구동한 터미널 창을 끄거나, 컴퓨터 자체를 끄게 되면 결국 서버도 같이 중단되게 된다. 왜냐면 aws의 EC2 서비스는 관리해주는 역할을 하지 서버를 구동해주는 역할을 하는 것이 아니다.
이를 위해 PM2라는 서비스를 이용 할 수 있다.
3. RDS 서비스
해당 서비스는 웹서비시의 DB를 관리해주는 데이터베이스 클라우드 서비스이다.
그렇다면 데이터베이스까지 왜 클라우드로 관리해줄 필요성이 있는 것일까?
EC2 서비스를 통해 서버를 관리하는 것과 비슷한 이유로 생각하면 더 쉽다고 볼 수 있다. 데이터 베이스를 자체적으로 하드웨어에 관리해주는 것 보다는 손상 가능성이 적고, 장기적인 보관에 용이할 것이다.
관계형 데이터들의 양이 많아지게 되면, 자체적으로 관리할 때 발생할 수 있는 백업 문제, 구동 속도 문제, 보안 등의 다양한 문제들이 발생할 가능성이 높아지는데, 클라우드 서비스를 이용하게 되면 해당 문제 발생 가능성이 낮아 지는 것이다.
따라서 이러한 유지 보수 문제에 대한 부담감을 클라우드 서비스가 덜어주면서, 웹서비스 제공자는 스키마 구성과 같은 데이터 베이스 구성 자체의 기본적인 기능에 좀 더 집중할 수 있는 것이다.
또한, 서버가 배포가 된 이후, 현실적으로 서비스 자체를 1인이 관리해주지는 않을 것이다. 즉 팀 내의 다수가 해당 서버와 데이터를 관리하게 될 것이다. 따라서 클라우드 서비스를 통해 개인의 컴퓨터에 하드웨어적으로 관리하기 보다는, 가상의 클라우드에 등록하여 관리하게 되었을 때도 유지 보수 측면에서 더 편리한 것이다.
협업하는 것에 있어서 각자의 컴퓨터가 가지고 있는 상황이 다름에 의해서 개인 마다 mysql 버전이 다른 기본적인 문제부터 해서 데이터 베이스 자체에 접근이 힘든 경우가 흔히들 발생하는 것이다.
정리하며...
실제 웹서비스를 배포하기 위해서는 보안 문제부터 해서 다양한 문제들을 해결하기 위해 더 많은 서비스를 사용할 줄 알아야 한다. 하지만, S3, EC2, RDS는 없어서는 안 될 가장 핵심적인 서비스이므로 이렇게 먼저 정리해 보았다.
S3 서비스는 client 코드들의 수많은 파일들을 깔끔하게 하나의 콘텐츠 형식으로 정리할 수 있게 해주는 서비스이며, EC2 서비스는 서버 구동의 효율성을 위해 일종의 가상의 서버실과 서버 컴퓨터를 대여해주는 서비스라고 이해하면 쉽다. RDS는 데이터의 유지 보수 및 협업과정에 있어서 발생할 수 있는 세세한 문제들을 해결하기 위해 필요한 데이터베이스 관리를 위한 클라우드 서비스라고 기억하면 될 것이다.
