🤔 클라우드 컴퓨팅, 왜 필요할까?
몇 년 전 새해 첫 날 첫 시(?)만 해도, 카카오톡은 새해 복을 주고 받는 수 많은 사람들 때문에 몇 시간 동안 먹통이 되곤 했다.
하지만 이렇게 특정 시간에 늘어나는 트래픽을 감당하기 위해
서버를 구매하는 것은 아주 큰 낭비가 아닐 수 없다!
따라서 필요한 시간에만 서버를 다른 곳에서 잠깐 빌리고, 필요하지 않게 되면 다시 반납하는.. 뭐 그런 게 필요하게 됐다.
이것이 바로 클라우드 컴퓨팅 이 탄생하게 된 계기 되시겠다!
📌 클라우드 컴퓨팅의 정의
클라우드 컴퓨팅은 사용자의 직접적인 활발한 관리 없이
데이터 스토리지와 컴퓨팅 파워와 같은 컴퓨터 시스템 리소스를
필요시 바로 제공(on-demand availability)하는 것을 말한다.
인터넷 기반 컴퓨팅의 일종으로 정보를 자신의 컴퓨터가 아닌 클라우드에 연결된 다른 컴퓨터로 처리하는 기술을 의미한다.
📌 Service Model
클라우드에서 Runtime은 무슨 뜻이야?
서비스가 구동되고 실행되는 환경 정도로 이해하면 된다! 대표적인 IaaS인 AWS EC2를 사용할 때, 서버가 의도치 않은 트래픽으로 멈추게 되면 우리는 해당 인스턴스에 접속하여 서버를 복구하고, 같은 인스턴스를 늘리고 코드를 수정해야 했다면, PaaS 중 하나인 AWS Lambda를 이용하면 에러가 났다고 서버가 꺼지거나 날아가지 않으므로 서버의 트래픽, 의도치 않은 에러를 관리할 필요가 없다. 그저 나중에 log를 확인하고 고치면 된다.
On-site
우리가 통째로 다 관리한다.
IaaS
Infrastructure-as-a-service라고 한다. 그림에서 보이다시피 O/S 밑단만 관리한다! 가상화, 서버, 스토리지, 네트워킹은 클라우드 회사에서 담당하고, 사용자는 OS, 미들웨어, 런타임, 데이터, 어플리케이션을 제공하면 이에 맞게 서비스를 이용할 수 있다. 즉, Virtual Machine을 서버 형태로 제공해주는 것이라고 생각하면 된다. 사용자 입장에선 손이 많이 갈 순 있지만, 확장성 측면에선 제일 자유로운 모델이다. 예시로 Linux, Windows, iOS 등의 Container을 제공하는 AWS EC2가 있다.
PaaS
Platform-as-a-service이라고 한다. '우리는 함수 몇개만 해서 어플리케이션이나 만들자.'는 느낌으로 이해하면 된다! 이름에서 보이다시피 Platform 레벨의 클라우드 서비스를 제공하는데, IaaS 서비스 + OS, 미들웨어, 런타임을 클라우드 서비스 회사에서 제공하고, 데이터, 어플리케이션을 사용자가 담당하면 이에 맞춰 사용자가 서비스를 이용할 수 있다. 사용자가 간단한 코드 정도만 제공하면 매우 빠르게 원하는 서비스를 사용할 수 있는 게 장점이지만 특정 플랫폼에 종속 되어 다른 플랫폼으로 이용하는 게 어렵다는 게 단점이다. (커스터마이징이 어렵다..) 예시로는 Heroku, Google App Engine 등이 있다.
SaaS
Software-as-a-service, 소프트웨어까지 제공해준다. 사용자가 '걍 만들어진 거나 쓰자.' 싶을 때 쓰면 된다. 모든 것을 클라우드 서비스 회사에서 SW 형태로 제공한다! 사용자는 그저 웹이나 어플리케이션으로 접속하여 사용하기만 하면 되는데, 커스터마이징이 아예 불가능 하다는 것이 단점으로 작용한다. 예시로 구글 드라이브가 있다!
그럼 뭐가 제일 좋은거야?
정해진 건 없다!
사과 자를 때 전기톱 쓰고, 나무 자를 때 과도를 쓸 수는 없지 않은가?
그때그때 필요한 걸 쓰면 되는 거다!
📌 Container
local 개발 환경에선 돌아가는 것들이 실서버(remote) 환경에선 돌아가지 않는 경우가 이따금씩 생긴다.
local과 remote의 개발 환경이 다르기 때문인데, 아무리 동일한 환경을 구성 한다고 해도, OS가 다르고, 여러 환경변수와 네트워크, 설치 방법 등 아주 많은 것들이 다르기 때문에 완전 동일한 환경은 만들기 어렵다.
그래서 Container 방식으로 실행하는 것이 대두가 되기 시작했다!
아~주 쉽게 설명하자면 이렇다. 다음과 같은 상황을 가정해보자.
A: Linux에서 돌아가는 jango,A'- jango 그 자체B: Linux에서 돌아가는 React,B'- React 그 자체C: Linux
그렇다면 A = C + A' 으로 나타낼 수 있고, B = C + B'로 나타낼 수 있다. A와 B모두에 C가 있으므로 오버헤드를 줄일 수 있도록 C를 공유하도록 하면 된다.
즉, Container 방식의 장점은 커널을 공유함으로써 가상화에 많은 자원을 사용하지 않으며, 비슷한 종속성을 가진 컨테이너 끼리는 이미지 자원을 공유하여 최적화 한다. 또한, 동일한 환경에서 프로세스가 실행될 수 있도록 하면서 충돌이 일어나지 않도록 프로세스를 구성한다.
더 많은 장점을 열거해보면,
1. 로드 밸런싱에 용이하다.
컨테이너는 켜고 끄는 것이 빠르고 간편하기 때문에 특정 기능에 사람들이 몰리면 해당기능을 담당하는 마이크로서비스의 컨테이너 수를 늘리면 된다! 또한 특정 컨테이너에 트래픽이 몰리면, 네트워크 트래픽을 로드 밸런싱하여, 동일 기능을 하는 컨테이너에 옮길 수도 있다!
2. Self Healing
특정 컨테이너에 에러가 발생하면 서버를 껐다 킬 수도 있지만 그저 컨테이너를 교체할 수도 있다! 특정 요청에 응답하지 않으면, 노드가 건강하지 않다고 판단(똑똑하다!)하는 방식으로 진행한다. 이러한 일련의 과정을 클라이언트에 보여 주지 않는 기능도 제공한다. 이게 왜 중요하냐! 세개의 컨테이너에 서비스 요청이 막 오는데 맛 간 컨테이너 하나에도 요청이 간 상황을 가정해보자. 이런 경우 컨테이너는 맛 간 컨테이너를 파악해서 정상작동하는 컨테이너로 옮겨준다. 아~주 똑똑하다!
3. Health Check를 통한 비정상적인 실행 방지
서버 컨테이너와 DB 컨테이너 같이 종속성을 가지고 있는 경우에는 DB 컨테이너가 켜져야 서버 컨테이너가 작동하는 것처럼 서비스 운영에 있어서도 안정감을 가져 올 수 있다.
이 외에도 마이크로서비스 운영, 이식성, 일관성 등 여러가지 장점이 존재한다.
