오픈스택 수동 설치 실습 #.5

오픈스택 수동 설치 실습 #.5 - Message Queue, Memcached, etcd


Message Queue 인 RabbitMQ는 Controller 노드에서만 실행됩니다.


RabbitMQ는 간단하게 말하면 표준 AMQP (Advanced Message Queueing Protocol) 메세지 브로커 소프트웨어(message broker software) 오픈소스입니다.


RabbitMQ를 이해하기 위해서는 우선 MQ(Message Queuing)에 대한 이해가 필요합니다. 프로그래밍에서 MQ는 프로세스 또는 프로그램 인스턴스가 데이터를 서로 교환할때 사용하는 방법이죠. 이때 데이터를 교환할때 시스템이 관리하는 메세지 큐를 이용하는 것이 특징입니다. 이렇게 서로 다른 프로세스나 프로그램 사이에 메시지를 교환할때 AMQP(Advanced Message Queueing Protocol)을 이용합니다. AMQP는 메세지 지향 미들웨어를 위한 open standard application layer protocol 입니다. AMQP를 이용하면 다른 벤더 사이에 메세지를 전송하는 것이 가능한데 JMS (Java Message Service)가 API를 제공하는것과 달리 AMQP는 wire-protocol을 제공하는데 이는 octet stream을 이용해서 다른 네트워크 사이에 데이터를 전송할 수 있는 포멧인데 이를 사용합니다. 이러한 복잡한 설명과 달리 RabbitMQ 튜토리얼에서는 RabbitMQ를 매우 간단하게 편지를 작성하여 받는 사람에게 보낼 우체통, 우체국, 우편배달부가 있듯, post box, post office and postman라고 비유적으로 설명하고 있습니다. 


오픈스택에서는 RabbitMQ를 이용하여 각 모듈간의 API 통신을 합니다.


RabbitMQ 설치

# yum -y install rabbitmq-server

# systemctl enable rabbitmq-server.service

# systemctl start rabbitmq-server.service

RABBIT_PASS에는 openstack이 RabbitMQ 사용에 사용할 패스워드를 입력해주시기 바랍니다.

# rabbitmqctl add_user openstack <RABBIT_PASS>


Creating user "openstack" ...
# rabbitmqctl set_permissions openstack ".*" ".*" ".*"


Setting permissions for user "openstack" in vhost "/" ...


Memcached는 controller 노드에서만 실행됩니다.


Memcached는 범용 분산 캐시 시스템입니다. 외부 데이터 소스(예: 데이터베이스나 API)의 읽기 횟수를 줄이기 위해 데이터와 객체들을 RAM에 캐시 처리함으로써 동적 데이터베이스 드리븐 웹사이트의 속도를 높이기 위해 종종 사용됩니다. Memcached는 BSD 허가서로 라이선스되는 자유-오픈 소스 소프트웨어입니다. Memcached는 유닉스 계열 운영 체제(적어도 리눅스와 macOS), 마이크로소프트 윈도우에서 실행되며, libevent 라이브러리에 의존합니다.


Memcached 설치

# yum -y install memcached python-memcached

# vi /etc/sysconfig/memcached


OPTIONS="-l 127.0.0.1,::1,controller".

# systemctl enable memcached.service

# systemctl start memcached.service


etcd는 go언어와 Raft프레임워크 이용해 작성된 오픈소스 key-value 저장소로 대규모 Docker 클러스터링에 있어서 컨테이너들을 유기적으로 연동시키고 억세스하기 위한 세련된 아키텍처를 제공합니다. 좀 더 설명하자면 OS에 배당된 IP어드레스에 비해 탑재된 컨테이너들의 수는 엄청나게 많은데, 이러한 컨터이너들에 접근하기 위해서는 IP어드레스 이외의 효율적인 어드레싱 수단을 필요로 하게 됩니다. etcd는 이러한 어드레싱을 HTTP/JSON을 이용해 구현하고 있으며 빠른 성능과 암호화 제공등으로 현재 Docker 사용자들에게 주목받고 있습니다. 직접 물리서버에 설치도 가능하고, Vagrant,Amazon EC2, Azure, QEMU/KVM, VMware그리고 OpenStack에 이르기까지 요즘 인기있는 가상화/클라우드 플랫폼은 충실하게 지원하고 있습니다. 특히, docker를 이용한 대규모 클러스터링 구현은 vagrant에 의존하지 않고는 무척 고된작업이 되어버릴 것이며, 지금부터 docker를 이용한 클러스터링에 관심을 가지고 사용해 보려는 유저들에게는 익혀두면 크게 도움이 될 것입니다.


etcd 설치

# yum -y install etcd

# vi /etc/etcd/etcd.conf

#[Member]

ETCD_DATA_DIR="/var/lib/etcd/default.etcd"

ETCD_LISTEN_PEER_URLS="http://10.0.0.11:2380"

ETCD_LISTEN_CLIENT_URLS="http://10.0.0.11:2379"

ETCD_NAME="controller"

#[Clustering]

ETCD_INITIAL_ADVERTISE_PEER_URLS="http://10.0.0.11:2380"

ETCD_ADVERTISE_CLIENT_URLS="http://10.0.0.11:2379"

ETCD_INITIAL_CLUSTER="controller=http://10.0.0.11:2380"

ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster-01"

ETCD_INITIAL_CLUSTER_STATE="new"

# systemctl enable etcd
# systemctl start etcd 



오픈스택 수동 설치 실습 #.4

오픈스택 수동 설치 실습 #.4 - Controller 노드에 PostgreSQL DB 설치


자! openstack.org 공식 문서에도 없는 부분이 왔습니다! 

오픈스택의 공식 설치 문서에는 오픈소스 DB인 MariaDB를 사용해서 설치하는 법이 나와 있습니다. 그러나 오픈스택은 역시 오픈소스 DB인 PostgreSQL도 지원하고 있습니다. 그러나 설치는 사용자의 몫. 아쉽게도 공식 문서에는 PostgreSQL을 사용하여 설치하는 법 따위는 소개 하고 있지 않습니다.


이론적으로 OpenStack Compute는 SQL-Alchemy가 지원하는 모든 데이터베이스를 지원합니다. 일반적으로 테스트에는 SQLite3를 개발작업에는 MySQL, PostgreSQL을 사용합니다.


그러면 왜 저는 PostgreSQL을 설치 하느냐? 일단 제 업무 환경이 Postgres로 구성 되어 있습니다. 두번째, 성능면에서 MariaDB보다 뛰어납니다. 세번째, MariaDB보다 설정이 쉽습니다.



※ SQL DB는 controller 노드에만 설치를 합니다.


PostgreSQL Download 홈페이지


홈페이지에 가서 yum repo를 통해 원하는 버전의 패키지를 내려 받아야 합니다.



저는 9.6 버전을 선택했고, 플랫폼은 CentOS7을 설정했습니다.

설정을 하면 나오는 4번 항목의 주소를 복사해서 controller 노드에서 실행합니다.

# yum -y install https://download.postgresql.org/pub/repos/yum/9.6/redhat/rhel-7-x86_64/pgdg-centos96-9.6-3.noarch.rpm


그리고 postgresql을 yum으로 설치해야 하는데, 오픈스택에서 사용하는 driver인 python-psycopg2를 같이 설치해줘야 합니다.


※ python-psycopg2 패키지는 controller 노드 뿐만 아니라 모든 노드에 설치를 해줘야 controller 노드에 설치되어 있는 DB에 접근 할 수 있습니다.


예전에 원하는 경로에 PostgreSQL을 설치하는 포스팅을 한적이 있는데 (http://db.necoaki.net/225) 오늘은 기본값과 최소한의 설치만 가지고 진행하겠습니다. 

# yum -y install postgresql96 postgresql96-server python-psycopg2


yum으로 설치가 완료되면 DB 클러스터를 구성합니다.


# /usr/pgsql-9.6/bin/postgresql96-setup initdb


그리고 DB가 서버 구동시 자동으로 올라오도록 구성해줍니다.


# systemctl enable postgresql-9.6

# systemctl start postgresql-9.6


그럼 DB가 구동 되었는지 확인하기 위해 su - postgres 하여 유저 변환을 합니다.


root@controller:~]# su - postgres

-bash-4.2$


프롬프트 기본값이 영 보기가 좋지 않네요. .bash_profile을 수정합니다. (안해도 됩니다. 취향입니다...)

$ vi .bash_profile

# .bash_profile


# Get the aliases and functions

if [ -f ~/.bashrc ]; then

        . ~/.bashrc

fi


# User specific environment and startup programs


PATH=$PATH:$HOME/.local/bin:$HOME/bin


export PATH


[ -f /etc/profile ] && source /etc/profile

PGDATA=/var/lib/pgsql/9.6/data

export PGDATA

# If you want to customize your settings,

# Use the file below. This is not overridden

# by the RPMS.

[ -f /var/lib/pgsql/.pgsql_profile ] && source /var/lib/pgsql/.pgsql_profile


export PS1="\[\e[27;1m\]\u@\[\e[32;1m\]\h:\[\e[31;1m\]\w]$ \[\e[0m\]"

export TERM=linux


PATH=$PATH:$HOME/bin:/usr/pgsql-9.6/bin

export PATH


export PSQL_HOME=/var/lib/pgsql


alias vi='vim $*'

프롬프트 설정이 완료 되었고, postgres 마스터 계정의 패스워드를 바꿔줍니다. pg_hba.conf 에서 로컬의 접속도 md5로 변환 해줄 것이기 때문에 미리 바꿔줘야 나중에 마스터 계정으로 접속이 가능합니다.



$ vi $PGDATA/pg_hba.conf


맨 밑으로 내려보면 아래와 같은 설정이 있습니다.

# TYPE  DATABASE        USER            ADDRESS                 METHOD


# "local" is for Unix domain socket connections only

local   all             all                                     peer

# IPv4 local connections:

host    all             all             127.0.0.1/32            ident

# IPv6 local connections:

host    all             all             ::1/128                 ident

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local   replication     postgres                                peer

#host    replication     postgres        127.0.0.1/32            ident

#host    replication     postgres        ::1/128                 ident

다음과 같이 바꿔 줍니다.

# TYPE  DATABASE        USER            ADDRESS                 METHOD


# "local" is for Unix domain socket connections only

#local   all             all                                     peer

local   all             all                                     md5

# IPv4 local connections:

host    all             all             127.0.0.1/32            ident

host    all             all             10.0.0.0/24            md5

# IPv6 local connections:

host    all             all             ::1/128                 ident

# Allow replication connections from localhost, by a user with the

# replication privilege.

#local   replication     postgres                                peer

#host    replication     postgres        127.0.0.1/32            ident

#host    replication     postgres        ::1/128                 ident


postgresql.conf 파일을 열어 리스너 부분의 주석을 해제하고 * 옵션을 줘서 모든 ip에 대해 접속 가능하게 리스너 설정을 합니다.


 $ vi $PGDATA/postgresql.conf

# - Connection Settings -


listen_addresses = '*'                  # what IP address(es) to listen on;

저장 후 DB를 재구동 해줍니다.

$ pg_ctl restart

PostgreSQL DB 설치는 완료 되었습니다.


오픈스택 수동 설치 실습 #.3

오픈스택 설치 실습 #.3 - 사전에 각각의 노드에 준비해야 할 것들


저는 일단 controller, compute1, block1 이렇게 3개의 노드를 준비했습니다.

각각 3개의 노드에 /etc/hosts 파일을 수정해서 넣어주고, 서로간에 Ping이 가는지 확인해 봅시다.


※ controller, compute1, block1 에서 모두 설정

# vi /etc/hosts

# controller

10.0.0.11       controller

# compute1

10.0.0.31       compute1

# block1

10.0.0.41       block1



핑이 잘 갑니다.



NTP 설정하기


CentOS 7 설치시에 NTP 옵션을 준 것을 기억하시나요? 그렇다면 각 서버에는 chrony 데몬이 설치 되어 있을 겁니다. 설치가 안되어 있다면, yum install chrony 명령으로 설치를 해줍니다.


chrony 데몬은 RHEL 7버전부터 선택된 기존의 ntpd를 대체하는 시간 동기화 데몬입니다. 네트워크에서 일시 중단되거나 간헐적으로 연결이 끊어지는 시스템 (모바일 및 가상 서버 등)에 가장 적합한 데몬입니다.


▶ chrony의 장점


1) 24 시간 운영되지 않는 데스크톱이나 시스템에서 유용하게 사용되는 시간 및 주파수 오류를 최소화하기 위해 시간 대신 단 몇 분만에 빠른 동기화가 가능합니다. 

2) 클록 주파수의 급격한 변화에 대한보다 나은 대응은 클록 주파수가 불안정한 가상 머신이나 클럭 주파수를 일정하게 유지하지 않는 절전 기술에 유용합니다. 

3) 초기 동기화 후에는 시스템 시간을 필요로하는 응용 프로그램에 영향을 미치지 않도록 시계를 단계별로 조정하지 마십시오. 

4) 일시적인 비대칭 지연을 처리 할 때 안정성이 좋아집니다 (예 : 링크가 대량 다운로드로 포화 된 경우). 

5) 주기적으로 서버를 폴링 할 필요가 없으므로 네트워크 연결이 간헐적으로 연결된 시스템은 여전히 ​​신속하게 클록을 동기화 할 수 있습니다. 


chrony 데몬을 통해 controller 노드는 NTP 서버에서 시간을 가져오고, 각각의 노드는 controller 노드에서 시간을 가져오게 끔 설정합니다.


chrony.conf 파일을 열어 해당 부분의 주석을 제거하고 값을 수정합니다.


※ controller 에서 설정

# vi /etc/chrony.conf


.

.

.

# Allow NTP client access from local network.

allow 10.0.0.0/24

.

.

.


※ compute1, block1 각각의 노드에서 설정

# vi /etc/chrony.conf


.

#server 0.centos.pool.ntp.org iburst #server 1.centos.pool.ntp.org iburst #server 2.centos.pool.ntp.org iburst #server 3.centos.pool.ntp.org iburst server controller iburst

.

.

.


※ 모든 노드에서 실행

# systemctl enable chronyd.service
# systemctl restart chronyd.service

설정이 완료되면 각각의 노드에서 chronyc sources 명령을 통해 확인 할 수 있습니다.



controller 노드는 ntp 서버에서, 각각의 노드는 controller 노드에서 시간을 받아오는 걸 확인 할 수 있습니다.



오픈스택 패키지 설치하기


※ 모든 노드에서 실행 (controller, compute1, block1 )

# yum install centos-release-openstack-rocky

# yum upgrade

# yum install python-openstackclient

# yum install openstack-selinux


이제 오픈스택 설치 준비가 완료 되었습니다.

오픈스택 수동 설치 실습 #.2


오픈스택 수동 설치 실습 #.2 - 네트워크 구성에 대한 이해


 

오픈스택을 처음 설치 하는 분들이 이 부분을 처음에 안 짚고 가면 나중에 Neutron 설치 부분에서 멘붕이 올 수 있습니다. 

네트워크를 어떻게 해야하지? 라는 의문이 들겁니다.



본 네트워크 레이아웃은 가장 최소한의 네트워크 레이아웃 입니다.

그런데 Neutron을 설치하면서 두 가지 상황을 마주하게 됩니다. Provider Network와 Self-service Network 구성입니다.



네트워크의 종류


Management Network - 각 요소 간 네트워크입니다. 서로 API를 호출하는데 사용합니다. Compute, Network, Control Node, 그리고 스토리지와 연결되어 있습니다.


Private Network - VM의 네트워크를 구성하는데 사용하는 네트워크입니다. GRE, VxLAN 등의 기술이 사용됩니다. Compute, Network Node 간에 연결되어 있습니다. 이 Private Network는 Tunnel Network, Overlay Network, VM Data Network 등으로 불리기도 합니다.


Storage Network - 블록 스토리지용 네트워크로 Compute Node와 스토리지 간에 연결되어 있습니다.


External Network - Horizon 접속 또는 유저들이 VM에 접속하기 위한 네트워크로 Network 및 Control Node 간에 연결되어 있습니다.


그런데 네트워크를 Neutron 상에서 설정하기 위한 방식으로 나눌 수도 있습니다.


Provider Network - 서비스하는 사람이 구축한 네트워크라는 의미에서 "Provider Network"입니다. 이 네트워크는 인터넷에 연결되어 있는 네트워크입니다. 그래서 앞서 이야기한 External Network에 대응합니다.


Self-Service Network - 사용자가 직접 VM을 위해 구축한 네트워크입니다. Provider Network을 기반으로 GRE, VxLAN 등의 터널링을 통해 구축합니다.



그럼 두 가지 레이아웃을 비교 해봅시다.


뭔가 다르죠?

Open vSwitch가 구성 되게 되면 가상의 스위치가 노드에 생성되게 됩니다.

랜포트는 하나지만, 하나의 랜포트를 통해 여러개의 NIC가 서비스 될수 있는 겁니다.


Self-service Network는 터널링 구성을 통해서 Compute 노드가 생성한 vm들끼리 통신을 할수 있고, 사설 IP 대역을 이용하면서 공인 IP의 사용을 줄일수 있며, Floating IP 구성을 하여 외부 인터넷 망과도 통신을 할 수 있습니다. Floating 설정이 없으면 터널링 네트워크는 클라우드 내부에서만 통신이 가능합니다.


어떻게 네트워크를 구성 할 것인가는 사전 기획 단계에서 충분히 논의 되어져야 하고, 실습 환경에서는 원하시는대로 진행 하시면 됩니다.





오픈스택 수동 설치 실습 #.1


오픈스택 수동 설치 실습 #.1 - OS 준비


일단 오픈스택을 수동으로 설치를 해보면 오픈스택을 이해하기에 조금 더 도움이 됩니다. 그러니 VM 환경에다가 구축 실습을 해봅니다. 설치 버전은 rocky 버전으로 가장 최신 버전이며, 설치하면서 부분 부분 설명을 가미 해보도록 하겠습니다.


https://docs.openstack.org/rocky/install/


해당 공식 설치 문서를 참고하여 진행합니다.



CentOS 7 버전을 이용해 OS를 준비해 보겠습니다.


하드웨어 설정에 controller 노드의 용량은 RAM 4GB, HDD 50GB 입니다.

compute 노드는 RAM 2GB, HDD 50GB 입니다.




보안 정책을 꺼줍니다.



KDUMP도 꺼버립니다.



NIC 설정입니다.

ens32는 Bridge 네트워크로 Provider Network가 될 부분입니다. DHCP로 놔두어도 상관 없습니다.






ens33은 NAT로 구성했습니다.

VM의 네트워크 매니저에서 10.0.0.0/24 대역으로 구성했습니다. Management Network로 구성될 부분입니다.






파티션은 원하는대로 설정해도 되고, 그냥 기본으로 설치해도 됩니다.

용량은 50GB 할당 했습니다.



네트워크 통신이 된다면 NTP도 되겠죠?



설치 되는 동안 ROOT의 패스워드를 설정해주고 완료 되면, Reboot 합니다.




미니멀로 설치 했기 때문에 터미널 모드로 부팅합니다.

편한 작업을 위한 SSH 설정을 위해 sshd_config 파일을 수정해 줍니다.

 # vi /etc/ssh/sshd_config

PermitRootLogin yes

해당 부분 주석 해제

 # vi /etc/selinux/config

SELINUX=disable

이 부분은 선택입니다. 오픈스택은 SELINUX를 사용해 보안 설정을 할 수 있기 때문에 사용하기도 합니다. 그런데 저는 MariaDB가 아닌 PostgreSQL을 기본 DB로 선택할 것이기 때문에 SELINUX가 PostgreSQL에서 문제가 발생 할 수있는 여지가 있어 해제하고 설치를 진행합니다.


 # yum -y install net-tools vim

ifconfig 같은 명령이나 vim이 없기 때문에 설치를 진행 합니다.



프로파일을 수정합니다.

# vi .bash_profile 

아래 항목을 추가해서 노드가 헷갈리지 않게 합니다.

그리고 기본 에디터를 vim으로 사용하기 위해 설정을 해줍니다.

export PS1="\[\e[36;1m\]\u@\[\e[32;1m\]\h:\[\e[31;1m\]\w]# \[\e[0m\]"

export TERM=linux

alias vi='vim $*'

그리고 SELINUX 설정을 적용하기 위해 재부팅을 한번 해줍니다.


Controller Node의 준비가 끝났습니다.


이와 같은 방식으로 Compute Node와 Block Storage Node, Network Node를 준비하시면 됩니다.

Block Storage Node와 Network Node는 옵션입니다. 최소 controller와 compute만 있어도 설치는 가능합니다.

VM을 복사해서 hostname과 ip를 바꿔서 만들어도 상관 없습니다.



.bash_profile의 프롬프트 설정 부분의 가운데 숫자 (export PS1 .... 32->33) 변경하니 노드의 색이 바뀌었습니다. 

두 노드를 왔다 갔다 하면서도 쉽게 구분 할수 있겠죠?

오픈스택의 아키텍처 맵

오픈스택의 아키텍처 맵



openstack.org에 가면 확인할수 있는 맵 파일 입니다.

전체적인 큰 그림을 머릿속에 넣어두고 시작해 봅시다.

Git Bash



윈도우용 Bash 쉘이 포함된 Git 입니다.


개발하거나 리눅스가 편리하시분들 윈도우에서도 Bash 명령을 이용해 작업을 할 수 있습니다.

putty 대용으로도 사용 할 수 있고, grep을 이용해 로그의 특정 부분을 긁어 모으거나 vi가 편하신분들에게 유용합니다.


원출처는 https://gitforwindows.org/



pwd를 치면 기본 홈은 /c/user/{$사용자} 입니다.


CMD창도 git 스타일로 이용할 수 있습니다.


Git-2.20.1-64-bit.zip

Git-2.20.1-64-bit.z01

Git-2.20.1-64-bit.z02

Git-2.20.1-64-bit.z03

Git-2.20.1-64-bit.z04



클라우드 컴퓨팅에서 데이터베이스 전문가의 방향

클라우드 컴퓨팅에서 데이터베이스 전문가의 방향



  지금까지 오라클 데이터베이스 엔지니어로 10년 가까이 일해 왔지만, 앞으로 오라클만 할 줄 아는 DB 엔지니어 혹은 DBA는 시장에서 살아 남기가 힘들거라고 예상을 하고 있습니다. 장비가 가격이 내리고, 성능이 좋아져서 SQL 쿼리 튜닝에 투자하는 비용이 점점 줄어들고 있어 튜너들이 설자리가 점점 없어지고 있습니다. 또, 오라클의 비싼 라이센스 정책에 반하여 기업들은 어떻게든 비용 절감을 위해 오픈 소스를 도입한다거나, 클라우드를 구축한다거나, 아니면 다른 회사가 제공하는 클라우드 플랫폼을 이용하는 경우도 있습니다. 

 

 물론 오라클의 안정성과 성능은 인정합니다. 하지만 지금 시대는 예전에 오라클을 대체하지 못하던 시절과 많이 다릅니다. 오픈소스 DB의 대표적인 DB인 PostgreSQL의 성능은 이미 오라클의 바짝 뒤쫓고 있으며, 오픈 소스인 만큼 가격적인 측면에서 뛰어난 가성비를 제공합니다. EDB 같은 업체를 통해 PPAS의 유지보수 기술지원도 제공 받을수 있으며, 그 비용이 오라클과의 유지보수 계약에 비하면 정말 싼편이기 때문에, 이젠 충분히 대체 선택을 할 만하다고 생각합니다. 




 또, 앞으로는 DB 시장이 빅데이터와 클라우드를 중심으로 움직일 것이기에 HPE에서도 하드웨어 시장에 집중하기 보다는 빅데이터 분석을 위한 데이터베이스인 Vertica 같은 회사의 제품을 인수하여 시장에 내놓고 있으며, 새로운 환경에 특화된 데이터베이스들이 많이 나오고 있습니다. 오픈소스 기반의 DB들도 빠른 속도로 발전하고 있으며, 빅데이터에 특화 되어 있거나, 클라우드의 컨테이너 환경에 더 어울리는 DB가 발전 가능성이 크고 좀 더 많은 사용자가 유입 될 것이라고 예상합니다.


 클라우드 환경에서는 자체적으로 이중화 삼중화가 되어 있기 때문에, 오라클 같은 RAC 환경의 Active-Active 구성이 아니더라도, DB가 설치된 VM이 장애가 발생하더라도, 시스템이 자동으로 다른 컴퓨트 노드에 동일한 VM을 구동시켜 빠르게 장애 상황을 대체 할 수 있습니다. 이러한 기술은 RAC에 들어가는 라이선스와 장비의 비용 절감 효과가 엄청나기 때문에 기업 입장에서는 구미가 당길수 밖에 없는 상황이죠.



 DB의 부하가 걸려 자원이 더 필요한 상황이 오더라도, 스케일아웃을 통해 자동으로 노드를 추가하여 VM들의 클러스터링 통해 성능을 높일수 있고, 또 부하가 줄어든 시점에 자동으로 노드를 제거하여, 자원 효율을 극대화 시킬 수도 있습니다. 일반적인 상황에서 스케일아웃은 하드웨어 장비가 들고, 상면 랙이 늘고 하는 상황이 발생하지만, 클라우드 환경에서는 VM만 늘어나면 되기에 관리도 어렵지 않고, 필요없는 자원에 대한 회수도 용이합니다. 




 요즘은 MS도 자사의 클라우드 플랫폼인 Azure에 대한 홍보를 적극적으로 하고 있죠. 클라우드 환경에서의 관계형 DB로 시장이 크게 넘어가고 있는 중입니다. 당장 하던일을 그만 두라는 것은 아니지만, 계속 IT쪽에서 일을 해야 한다면, 앞으로 다가올 미래에 대한 대비 정도는 해야하지 않을까 생각해 봅니다.