Ashburton Grove

1. 인덱스 머지(Index Merge) vs 결합인덱스(Composite Index)

인덱스 머지는 각각 단 하나의 칼럼으로 구성된 인덱스들을 동시에 사용하는 방법.(개별 칼럼에 인덱스가 생성되어 있으면서 모두 where 절에 '=' 조건으로 사용되며, 각각의 인덱스 조합으로 자료에 접근하는 것을 의미함.)
결합인덱스는 2개 이상의 칼럼으로 구성된 인덱스를 의미함.
결합인덱스가 보다 간결한 프로세스, 좋은 엑세스 경로를 제공함.

2. 결합인덱스의 구성

1) 결합인덱스 칼럼 선택
① WHERE 절에서 AND 조건으로 자주 결합되어 사용되면서 각각의 분포도 보다 두 개의 칼럼이 결합될 때 분포도가 좋아지는 칼럼들 

(분포도란 '칼럼에 속한 데이터의 종류가 많다' 라는 의미.  분포도 = 1 / 칼럼의 DISTINCT 데이터 수 * 100)
② 다른 테이블과 조인의 연결고리로 자주 사용되는 칼럼들
③ 하나 이상의 키 칼럼 조건으로 같은 테이블의 칼럼들이 자주 조회될 때, 이러한 칼럼을 모두 포함(결합)

2) 결합인덱스의 칼럼 순서 결정
① WHERE 절 조건에 많이 사용되는 칼럼 우선
② Equal('=')로 사용되는 칼럼 우선
③ 분포도가 좋은 칼럼 우선
④ 자주 이용되는 Sort의 수서로 결정
* 고정된 Sort의 순서를 가진 SQL문이 자주 사용되는 경우에는 2-3), 2-4)의 비중이 바뀔 수 있음.


3. 결합인덱스 사용 방법

결합인덱스의 첫 번째 칼럼이 where 절에서 제외되어 있는 경우, 결합인덱스를 사용할 수 없음.

* Skip Scanning : 결합인덱스의 첫 번째 칼럼이 WHERE절에서 제외되어 있고, 두 번째 칼럼부터 WHERE절에 조건으로 기술되어 있는 경우에도, 그 인덱스가 사용되는 경우를 의미한다.

* Skip Scannig을 쓰려면 아래와 같이 Hint를 주면 된다
INDEX_SS (테이블명 INDEX명)
INDEX_SS_ASC (테이블명 INDEX명)
INDEX_SS_DESC (테이블명 INDEX명)

4. 결합인덱스 칼럼에 대한 '='의 의미

체크조건이 될 수도, 범위 제한 조건이 될 수도 있다.
(인덱스 순서대로 바로 사용된다면, 범위제한조건이 되고 아니면 체크 조건이 되어 버린다.)

예시)  AREA_X1 : (시, 구, 동) 이라는 index가 존재

WHERE 시 LIKE '서%' 

AND 구 =  '강남구'  ← 체크조건

AND 동 =  '역삼동'  ← 체크조건 

WHERE 시 =  '서울시'  ← 범위제한조건 

AND 구 LIKE '강%'

AND 동 =  '역삼동'  ← 체크조건 

WHERE 시 = '서울시'  ← 범위제한조건 

AND 동 = '역삼동'  ← 체크조건 

* 인덱스 매칭률 =

 WHERE절에서 첫번째 칼럼부터 연속된 칼럼에 대해 상수(값)를 '='로 비교하는 칼럼의 개수 / 인덱스를 구성하는 칼럼의 총 개수  (범위제한 조건인 '=')

예시) AREA_X1 : (시, 구, 동) 이라는 index가 존재

WHERE 시 = '서울시' (매칭률 = 1/3)

WHERE 시 = '서울시'

AND 구 = '강남구'  (매칭률 = 2/3)

WHERE 시 = '서울시'

AND 구 =  '강남구' 

AND 동 =  '역삼동'  (매칭률 = 3/3)

* 인덱스 매칭률 향상을 통한 속도 개선방법 예시

EMP_PAY_X1 : (급여연월, 급여코드, 사원번호) 라는 index가 존재

WHERE 급여연월 LIKE '2016%'

AND 급여코드 = '정기급여' ;

-> 아래와 같이 튜닝이 가능함,

WHERE 급여연월 IN ('201612', '201611', '201610',  ..... , '201601')

AND 급여코드 = '정기급여'

;

1. 인덱스의 필요성

DB에 저장된 자료를 더욱 빠르게 조회하기 위해 인덱스를 생성하여 사용함.
일반적으로, 인덱스는 테이블의 전체 데이터 중에서 일반적인 경우, 10~15% 이하의 데이터를 처리하는 경우에 효율적이며 그 이상의 데이터를 처리할 땐 인덱스를 사용하지 않는 것이 더 좋다. 

(테이블마다 저장된 데이터의 수가 다르므로 그 기준은 절대적이진 않다.)

2.  B* Tree(Balanced Tree)구조

가장 많이 사용되는 인덱스의 구조이며, 인덱스의 데이터 저장 방식이기도 함

- Root(기준) / Branch(중간) / Leaf(말단) Node로 구성됨
- Branch 노드는 Leaf 노드에 연결되어 있으며, 조회하려는 값이 있는 Leaf 노드까지 도달하기 위해 비교/분기해야 될 값들이 저장됨.
- 찾는 데이터는 Leaf 노드에 저장됨.

Leaf 노드 = 인덱스 칼럼의 값(오름(내림)차순으로 Sort되어 저장됨) + ROWID (테이블에 있는 해당 row를 찾기 위해 사용되는 논리적인(저장위치) 정보)

B*Tree 구조의 핵심은 Sort
- Order by에 의한 Sort를 피할 수 없음. (memory 소비가 줄어든다.)
- MAX/MIN의 효율적인 처리가 가능함. (미리 sorting 되어 있으므로)

3. 인덱스 선정 절차

1) 프로그램 개발에 이용된 모든 테이블에 대하여 Access Path 조사
2) 인덱스 칼럼 선정 및 분포도 조사
3) Critical Access Path(자주 수행되는 경로) 결정 및 우선 순위 결정
4) 인덱스 칼럼의 조합 및 순서 결정
5) 시험 생성 및 테스트
6) 결정된 인덱스를 기준으로 프로그램 반영
7) 실제 적용

4. 인덱스 생성 및 변경 시 고려할 사항 

- 기존 프로그램에 미치는 영향도 검토
- 필요할 때 마다 인덱스 생성으로 인한 인덱스 개수의 증가와 이로 인한 DML 작업의 속도가 지연될 수 있음.
- 비록 개별 칼럼의 분포도가 좋지 않을지라도 다른 칼럼과 결합하여 자주 사용되고, 결합할 경우에 분포도가 양호하다면 결합 인덱스 생성을 긍정적으로 검토

5. 인덱스 스캔의 원리

OPTIMIZER가 인덱스 사용을 위한 실행계획을 아래와 같이 수립한다.
1) 조건을 만족하는 최초의 인덱스 row를 찾음
2) Access 된 인덱스 row의 ROWID를 이용해서 테이블에 있는 row를 찾음 (Random Access)
3) 처리 범위가 끝날 때까지 차례대로 다음 인덱스 row를 찾으면서(Scan) 2)를 반복함.

인덱스 스캔시에는 한 번의 I/O가 발생할 때 마다 하나의 Block을 처리함.

1. 옵티마이저의 개념

사용자가 실행한 SQL을 해석하고, 데이터 추출을 위한 실행계획을 수립하는 프로세스. 프로세스가 수립하는 실행계획은 전반적인 SQL의 속도를 결정 짓는다.


2. 옵티마이저의 종류

오라클에서는 RBO(Rule Based Optimizer), CBO(Cost Based Optimizer) 2가지의 옵티마이저를 지원해주고 있다. 나머지 DBMS는 CBO만 지원해주고 있다. 
RBO는 초창기 버전부터 제공. CBO는 v10g부터 기본적인 설정으로 적용되고 있다. 

1) RBO
- 기본적으로 15개의 순위가 매겨진 규칙이 있음. (이를 기초로 하여 실행계획을 수립함.) 순위는 인덱스 구조나 사용하는 연산자에 따라 각각 다르다.
- SQL에 대한 실행계획이 하나 이상일 경우엔, 순위가 높은 규칙을 이용하게 됨.
- 수립될 실행계획이 예측 가능하기 때문에 개발자가 원하는 처리 경로로 유도하기가 쉬움.

* 아래 표는 RBO의 우선 순위를 보여준다.

(Rank 1 ~ 4는 하나의 데이터만 찾는다는게 특징)

2) CBO
- 대상 row들을 처리하는데 필요한 자원 사용을 최소화해서, 궁극적으로 데이터를 빨리 처리하는 데 목적이 있음
- CBO에 영향을 미치는 산정 요소
(각종 통계 정보, Hint, 연산자, Index, Cluster, DBMS 버전, CPU/Memory 용량, Disk I/O 등과 같이 매우 다양함) 

* 통계정보
- CBO의 성능을 최적의 상태로 유지시키기 위해서 테이블, 인덱스, 클러스터 등을 대상으로 통계정보를 생성함 -> 정기적으로 ANALYZE 작업을 하는 것이 가장 중요함(변경된 부분이 생길 수도 있으므로)
- 가장 효율적인 실행계획을 수립하기 위해 최소비용을 계산할 때 중요하게 사용됨

ANALYZE 예시)
ANALYZE TABLE emp COMPUTE STATISTICS; (전체대상)
ANALYZE TABLE emp ESTIMATE STATISTICS
  SAMPLE 10 PERCENT;
ANALYZE TABLE emp ESTIMATE STATISTICS
  SAMPLE 5 ROWS;

ANALYZE 실행 여부 확인 쿼리)
SELECT TABLE_NAME, NUM_ROWS, LAST_ANALYZED
FROM USER_TABLES
WHERE TABLE_NAME IN ('EMP', 'DEPT')
;

-> 오라클에서는 DBMS_STATS Package를 통해 확인 가능함.
(DBMS_STATS.GATHER_TABLE_STATS, DBMS_STATS.GATHER_SCHEMA_STATS, DBMS_STATS.GATHER_DATABASE_STATS)


3. 옵티마이저의 레벨별 설정

1) Instance Level 

- initSID.ora를 이용해서 지정함 (DB전체 차원)
OPTIMIZER_MODE = RULE, CHOOSE, FIRST_ROWS, ALL_ROWS 중에 하나 선택
(9g까지는 CHOOSE가 default, 10g부터는 ALL_ROWS가 default)

2) Session Level
- ALTER SESSION SET OPTIMIZER_MODE = RULE, CHOOSE, FIRST_ROWS, ALL_ROWS 중 하나를 선택

3) Statement Level
- 아래 쿼리와 같은 힌트 사용
SELECT /*+first_rows*/
ename
FROM emp;

* 우선 순위는 Statement Level이 가장 높다.


4. RBO와 CBO의 실행계획 비교

- 동일 SQL에 대해서 각 OPTIMIZER가 수립한 실행계획은 서로 다를 수 있음.
- 이는 SQL의 퍼포먼스가 OPTIMIZER에 따라 다르다는 의미.
- OPTIMIZER 종류에 따라 달라지는 DB성능의 차이점을 이해하는 것이 중요함.

인덱스 :

EC_TASK_PK : COURSE_CODE + TASK_NO

EC_TASK_TERM_IDX00 : COURSE_CODE + TASK_NO + YEAR + COURSE_SQ_NO

쿼리문 :

SELECT 

A.COURSE_CODE, A.TASK_NO, A.BBS_YN, A.UPDATE_DATE,

B.YEAR,  B.S_DATE, B.E_DATE

FROM EC_TASK A, EC_TASK_TERM B

WHERE A.COURSE_CODE = B.COURSE_CODE

AND A.TASK_NO = B.TASK_NO

AND B.COURSE_CODE = 36;

AND B.TASK_NO = 1

AND B.COURSE_SQ_NO = 1

;

위 쿼리문을 RBO로 해석하면 B에서 WHERE 조건절을 통해 데이터를 찾고 A와 조인을 통해 데이터를 합친다.

(B -> A 의 순서)

이에 반해 CBO로 해석하면 JOIN 조건인 COURSE_CODE, TASK_NO의 조건이 A에도 입력되어 있다 가정하고 A에서 데이터를 먼저 찾고 B와 합친다. (A는 조건이 2개(COURSE_CODE, TASK_NO)지만 B는 조건이 3개(COURSE_CODE, TASK_NO, COURSE_SQ_NO) (A-> B의 순서)

SQL를 만들 때, 실행계획이 차이나면 좋지 못한 SQL이다.예시에서는 CBO가 순서가 더 빠르다 ROWS가 적으므로
SQL을 수정한다면, 누가봐도 A에서 데이터를 찾고 B에서 데이터를 찾도록 아래와 같이 수정해야한다,

수정된 쿼리문 :

SELECT 

A.COURSE_CODE, A.TASK_NO, A.BBS_YN, A.UPDATE_DATE,

B.YEAR,  B.S_DATE, B.E_DATE

FROM EC_TASK A, EC_TASK_TERM B

WHERE A.COURSE_CODE = B.COURSE_CODE

AND A.TASK_NO = B.TASK_NO

AND A.COURSE_CODE = 36;

AND A.TASK_NO = 1

AND B.COURSE_SQ_NO = 1

;

사내 교육으로 듣게된 SQL 튜닝 기법에 대한 강의 내용을 정리해본다.

1. 실행계획의 정의

실행계획 : 사용자가 SQL을 실행하여 데이터를 추출하려고 할 때, 옵티마이저가 수립하는 작업절차, SQL의 Performance를 결정짓는 요인. 실행계획이 목적했던 대로 실행되지 않으면, SQL Performance에 문제가 발생함.

OPTIMIZER : SQL 해석 > 실행계획(데이터 처리 절차) 수립 > 실행


2. 실행계획의 확인 방법

오라클에서는 아래 명령어를 사용해 확인 가능함.
(특별한 권한부여가 필요 없다.)

*EXPLAIN PLAN
- SQL에 대한 실행계획만을 확인할 수 있음
- 명령을 사용할 때 데이터를 처리하지 않음. (DB에 부하를 미치지 않음.)
- 데이터를 읽지 않기에 소요시간과 I/O, Sorting 관련 정보는 확인이 어렵다.

*SET AUTOTRACE
- EXPLAIN PLAN 명령과 달리 한 번의 명령으로, 여러 개의 SQL에 대한 실행계획을 바로 볼 수 있음.
- 다양하게 옵션을 사용할 수 있어서 여러 가지의 정보를 선택적으로 확인할 수 있음. (SET AUTOTRACE 뒤에 ON EXPLAIN, ON STATISTICS, TRACEONLY, TRACEONLY EXPLAIN, TRACEONLY STATISTICS, OFF 등의 옵션들이 붙는다.)

큰 데이터에 대한 실행계획을 알아보기 위해서는 실제 데이터를 읽지 않는게 좋은 방법이지만, 데이터의 크기가 작다면 데이터를 읽어가면서 실행계획을 확인하는게 좋은 방법이 될 수 있다.

3. 실행계획 분석

 실행계획은 데이터 처리를 위한 작업 방법으로, 실행계획을 구성하는 내용의 분석을 통해 SQL의 비효율적인 부분을 확인할 수 있음. 실행계획 분석을 통해 SQL이 작성자의 의도대로 실행되었는지 확인할 수 있으며, 그렇지 않았을 경우 성능상 문제가 되는 부분을 찾아낼 수 있음. 실행계획의 정확한 분석을 통해 SQL문장의 튜닝 포인트를 도출할 수 있음.

명령어 예시) 
SET AUTOTRACE TRACEONLY EXPLAIN;
SELECT/*+USE_NL(e d) */
e.name, e.deptno, d.dname
FROM emp e, dept d
WHERE e.deptno = d.deptno;

실행결과 예시)

ID | Opreation                                                      | Name

0   |  SELECT STATMENT                                   |
1   |  NESTED LOOPS                                         |
2   |      NESTED LOOPS                                     |
3   |          TABLE ACCESS FULL                        | EMP
4   |          INDEX UNIQUE SCAN                       | PK_DEPT
5   |      TABLE ACCESS BY INDEX ROWID      | DEPT

들여쓰기 depth가 같다면 위에 있는 것이 먼저 실행되며,  실행계획을 도식화하면 아래 트리구와 같다.

위 트리구조의 실행순서 : 3 -> 4 -> 2 -> 5 -> 1 -> 0

가장 먼저실행되는 것은 가장 왼쪽하단에 위치한 노드이며, 왼쪽 하단 노드 -> 오른쪽 하단 노드 -> 중간 상단 노드의 순서로 실행되는 트리구조이다.

Cloud Native :  클라우드의 주요 특징과 장점을 극대화하는 방법론들의 총칭을 의미함.
(CI/CD, DevOps, Microservices, Container 개념들이 유기적으로 돌아가는 서비스를 제공하는 것)

전통적 IT 구조의 조직은 cloud native 적용에 다양한 커스터마이징이 필요.
IT 서비스 의존성이 높은 기업(스타트업 등)은 자연적으로 cloud native 하게 갖춰져 가는 경우가 많다.

1. MSA

 작은 서비스 여러개를 엮어 활용하는 구조

2. Container

 서비스가 인프라 레벨로 들어간 것. 가상화 기술 영역 중 가장 경량화된 최신 기술.

 가장 가볍고 빠르게 활용이 가능한 가상화 기술을 의미한다.

  MSA 구조를 사용하기 위해 최종적으로 고려되는 가상화 기술.

위 그림과 같이 운영체제(OS)위에 컨테이너 관리 SW가 존재한다.

컨테이너 관리 SW를 쓰게되면 사용자는 사용되는 클라우드가 Public, Private 인지 신경쓰지 않아도 되는 장점이 있다.

Hybrid cloud를 구성할 떄, 컨테이너 관리 SW(플랫폼)이 있으면 MSA가 Public과 Private을 마음대로 사용 가능하기에 
장기적인 관점에서 cloud native하다는 것은 컨테이너를 사용하는 것이라 보면 된다.

-> Multi/Hybrid cloud 사용자 관점에서는 어느 클라우드 환경의 자원을 쓰는지 상관없이(Public / Private), 동일한 인터페이스로 서비스를 활용 가능함. 컨테이너 개념을 통해 장기적으로는 클라우드의 대세는 Multi /Hybrid cloud로 나아갈 것.

3. DevOps (Development + Operation)

개발과 운영이 유기적으로 하나로 돌아가는 현상을 의미한다.
지속적인 개발, 운영, 피드백 반영, 적용을 위해 개발팀과 운영팀을 하나로 합치는 개념. 

DevOps는 아래와 같은 특징들을 가지고 있다.
1) 지속적으로 피드백을 바로 반용해서 새로 개발에 반영하도록 함
2) 조직 입장에 대응력을 높이며 신기능 추가 및 개선을 할 수 있는 환경 가능

4. CI/CD (Continuous Integration / Continuous Deployment)

지속적인 통합과 배포 

현업에서 요청한 서비스를 각 팀, 부서 별로 개발하다보면 통합(integration)의 필요성이 증대되는 경우가 많다.
여기서, 통합이란 API로 통신하면서 서비스가 유기적으로 돌아갈 수 있도록 프로토콜을 맞추는 작업을 의미함.

이러한 통합 과정을 원활하게 수행하기 위해서 활용되는 DevOps와 CI/CD는 개선사항을 빠르게 반영하고 다시 운영에 들어갈 수 있도록 한다. (비즈니스 요구사항을 맞춰주는 개발 속도와 대응력을 높임)

1. 클라우드 도입시 고려사항

1) 클라우드 도입 이유
 

 트렌드, 해외사업확장, 신규 업무 시작, 비용적인 이유, DT,  단순히 기술적 이점 이외에도 조직의 체질 개선, 클라우드 환경을 선호하는 기술 인력을 위한 인재 확보 차원 등이 있다. 

 또한 클라우드 도입을 통해 기능적 장점(필요할 때 빠르게 사용가능), 운영적 장점(자동화를 통한 관리 포인트의 감소)을 얻을 수 있다.

 클라우드 신규 도입(클라우드 환경에 최적화하여 신규 서비스를 개발)은 상대적으로 높은 수준의 난이도를 요구하지 않는다. (자동화를 통해 관리 포인트들이 줄어들었으므로) 하지만 기존 legacy 환경에서 운영되던 프로그램을 클라우드로 이관하는 이슈는 다른 차원의 난이도로 볼 수 있다.

2) 클라우드 도입의 선택지
 

 외산 클라우드가 더 최신 기술, 많은 선택지를 제공할 수는 있으나, 저렴한 비용과 수월한 지원을 보장하는 국산 cloud도 좋은 선택지가 될 수 있음. 클라우드 도입에 있어 원하는 것이 무엇인지 정확한 기준이 있어야 알맞은 선택이 가능하다.

 예를 들어 Private cloud의 경우, 공개된 무료 오픈소스부터 기존 대형 클라우드 회사들이 제공하는 기술, Public Cloud 회사가 제공하는 Private형 솔루션 등 다양한 형태가 존재한다.
 (보통 Public cloud로 클라우드를 경험한 뒤, Private cloud로 이관하여 사용량 산정 및 사용처를 점검하는 형태를 취함,)
 

 클라우드 도입에 있어 중요한 결정사항들은 아래와 같다.
1. Public / Private 중 어느 것을 선택할 것인가
2. 구체적인 서비스는 무엇을 쓸 것인가
3. IaaS / PaaS / SaaS 중 어느 것을 쓸 것인가

3) 장기적 관점에서의 도입 계획

 각각 클라우드 서비스(Public, Private, Hybrid 등)로 공유되는 특징과 함께 차이점에서 발생하는 장단점 파악이 중요하다.   또한 조직에 상황(신규도입, 이관)에 따라 도입 계획이 달라질 수 있다. 다만 향후 클라우드 도입이 더욱 확장되고 조직의 대응력이 높아지면 Multi/Hybrid cloud를 주로 사용하게 될 가능성이 높다.

2. 클라우드 이관시 고려사항

이관(Migration) : 기존 IT환경에서 운영되던 것(AS-IS)이 새로운 IT(TO-BE)환경으로 넘어가는 것을 의미함. 여기에서 TO-BE는 클라우드 환경을 의미한다. 

 기업 내 legacy 시스템이 오래되었거나 여러 개 존재하는 경우, 클라우드로 일부분을 이관시켜보면서 클라우드의 장점이 실제로 발현되는지 확인해보는 경우가 일반적이다.
(클라우드를 도입하려는 기업은 기존 on-premise 환경에서 클라우드로 이관(off-premise)하는 상황을 가장 많이 대면함.
 이관은 기존 환경에서 구동되는 어플리케이션에 대한 이해가 필수적으로 요구되기에, 어려움을 수반한다.

 클라우드 이관에는 표준이 없다. 각  클라우드의 특징과 이관하고자하는 어플리케이션의 특징을 이해하고 이관에 대한 순서 및 전략을 세워야 한다. 이관 전략을 위해 고려해야할 사항은 어플리케이션 간 의존성, 전환 편리성 등이 있다.

1) 클라우드 이관 방법

클라우드 이관 방법에는 아래와 같이 2가지 방법이 존재한다.

Lift  and Shift :  가장 원론적인 이관 방법, 기존 인프라 환경을 클라우드에 그대로 옮기는 것.
① 어플리케이션 구조 변경이 없기에 빠른 이전 가능
② 가장 리스크가 적고 빠른 방법
③ MSA에 최적화되어 있지 않아 클라우드의 장점 활용이 어려움
④ 클라우드의 장점을 포기하게 되고 성능 저하, 비용 추가 등의 문제를 내포함

Re-Architect : 기존 서버 환경의 어플리케이션을 클라우드에 최적화하여 재구성한 다음에 옮기는 것
① 클라우드의 장점을 극대화하기 때문에 가장 이상적인 이관 방법론
② 기존 어플리케이션의 이해도가 낮을수록 시간과 비용이 어느 정도 소요될지 가늠하기 어려움
③ 리스크 측면에서 상당히 난이도가 올라가는 방법

실제 이관 프로젝트에서는 아래와 같이 두가지 방법을 혼용하는 경우가 많음. 

① Lift and Shift 의 방법으로 프로젝트를 진행한다.

② Lift and Shift로 리스크(성능적 개선이 어렵거나, 클라우드에서 기능제공이 어려운 이슈 등)들을 조금씩 해결하고 테스트를 마침.

③ Lift and Shift를 위해 점진적 이관을 진행

④ Re-Architect를 통해 최적화를 완성.

이를 도식화시켜보면 아래 그림과 같다.

Cloud는 Pay per Use가 기본 사상.

* Pay per Use : 사용량 기반, 사용한 만큼 비용을 지불한다.

비용 체계를 정의하기 위해서는 무엇을 사용한 만큼 비용을 청구할 것인지를 정의해야 한다. 이를 Price Factor라 칭한다.

(cloud에서는 서버가 켜져 있는 시간, 사용자 수에 따른 과금, 용량에 따른 과금 등등 여러 기준이 존재한다.)

cloud 종류에 따른 비용체계는 아래와 같다.

SaaS : 특징(사용자 수, 용량, 서버 호스트 수 등)에 따라 다양한 과금 체계가 존재함.
PaaS / IaaS : 인프라 관점에서 사용량 및 사용시간 등에 따라 과금하는 것이 일반적.

AWS를 예시로 들면, 비용 체계는 크게 3가지가 존재한다.

1. 온디맨드 (On-Demand)

사용량에 따라 과금하는 가장 기본적인 모델
1) 실시간은 아니며, 시간당 과금 체계로 구성됨
2) 가장 cloud 형식에 맞는 과금 방식

2. 예약 인스턴스 (Reserved Instance)

정액제 개념, 일정 사용량을 예약하고 확정해서 돈을 내고 사용하는 방식
1) 1년/3년 등의 연 단위 계약을 통해 구매(분납 가능함)
2) 예약인 만큼 상당한 할인이 들어가는 경우가 많음. 온디맨드 방식보다 상당히 저렴한 금액으로 cloud 활용 가능

변동성이 큰 비용체계는 public cloud의 장점이나 사용량등이 정확히 예측 가능하다면, 전통적 IT나 private cloud가 더 유리하다.  cloud 사용량이 많은 경우, public cloud를 기반으로 일부는 예약 인스턴스로 구성하여 특정 서비스를 정액제로 가져가는 경우가 많다. 또는 처음에는 온디맨드를 이용하다가 사용 추이가 어느 정도 파악되면 예약 인스턴스를 사용하여 비용 절감을 하는 경우도 존재함.

3. 스팟 인스턴스 (Spot Instance)

 순간적으로 필요한 부분을 대기해두고 공용 자원을 저렴하게 사용하는 방식. 공용 자원은 수요와 공급에 따라 가격이 변동하는 특징을 가진다.

1) 온디맨드보다 저렴하게 이용이 가능함.
2)  단, 필요한 때에 자원 확보가 안되는 경우엔 사용이 어려움.
-> 사용자가 대기할 수 있는 경우, 예약 인스턴스와 스팟 인스턴스를 혼합하여 활용하는 경우가 많음.

cloud를 도입하면서 어느 부분을 고정비, 온디맨드형 변동비, 스팟 인스턴스 형으로 구성하여 가져갈 것인지는 충분한 고민이 필요하다. (어떤 서비스를, 어떤 인프라를 통해, 어떤 비용으로 구성할 지가 어렵다. 이번 차세대 프로젝트에서도 이에 관한 논의가 가장 길었었고..)

마지막으로 cloud의 비용적인 측면에서의 장,단점을 정리하면 아래와 같다.

비용적인 장점
1) 비즈니스 확장을 통해 얻을 수 있는 이득(이점) 대비 저렴한 비용으로 infra 환경을 제공받을 수 있음.
2) 서비스하는 업무가 유동적이거나 확장시점을 예측할 수 없을 때 cloud 사용이 합리적임.

비용적인 단점
1) 사용량이 고정적이며 큰 변화도 없고, 투자가 필요 없는 업무에 cloud를 적용하는 것은 비용적 측면에서 최소한 손해를 볼 여지가 있음.
2) 비용적 장점이 있더라도, 보안 등 조직에서 고려하는 여러 사유로 cloud 도입이 꺼려지는 측면이 있을 수도 있다.


* 기존 서버(On-premise) 방식은 1회성 구매 후 유지보수 등의 일부 비용만 발생함(cloud에 비해 상대적으로 저렴한 비용)

cloud를 설명할 때 여러 개념들이 등장하지만 여기서는 확장성과 가용성에 대해 다루어본다.

확장성과 가용성을 설명하기전, cloud서비스의 장점을 다시 한 번 복습하면 아래와 같다.

* 클라우드 서비스의 장점 
1. 주문형 셀프 서비스 : 필요할 때 사용
2. 준비된 대규모 자원 : 이미 있는 대규모의 물리 서버(클라우드 회사의)를 활용 가능
3. 종량제 과금 : 사용 기반의 과금 체계
4. 관리편의성 : API, 직관적 UI 등

1. 확장성(Scalability)

 cloud는 확장성을 제공해 주는 기반이 잘 되어있을 뿐, 실제 확장성 구현에는 여러 고민이 필요함.

 특히나 최근 IT환경에서는 서비스 부하에 대응해 탄력적으로 대응할 수 있는 환경(On-Demand)이 필요하였음.

(블랙프라이데이와 같이 특정 기간에만 사용량이 크게 늘어나는 경우들..)

-> 특정 시간에만 임대할 수 있는 환경을 어떻게 구현할 수 있을까?라는 질문에 대한 답을 구하는 과정에서 '확장성'이라는 개념이 등장하게 됨.

* On-Demand : 공급이 아니라 수요가 모든 것을 결정하는 시스템 또는 전략을 의미함.

확장성에는 아래와 같이 2가지 종류가 존재.

1) 수직적 확장(Scale up)

가상화 서버를 더 큰 규모로 확장

하나의 서버에서 모든 부하를 받아야되는 구조에서 사용함.

예) 2 Core, 메모리 1GB -> 4 Core, 메모리 2GB로 변경

2) 수평적 확장(Scale out)

 동일한 규모의 가상화 서버를 복제 / 추가하는 방식

 부하가 분산될 수 있는 구조인 경우에서 사용함.
 예) 2 Core, 메모리 1GB 한개를 3개로 늘림

cloud 환경에서는 수평적 확장을 더 선호함 (서버를 필요에 의해 늘렸다가 다시 줄이는 것이 수직적 확장보다 용이하므로)
사실 모든 서비스가 확장이 필요한 건 아님. 서비스 특성에 따라 확장하지 않고 추가되는 요구들은 차단해버리는 경우가 생길 수도 있다.

 -> '서버를 어느 시점에 늘릴 것인지'  이를 자동화시켜놓는게 중요하고 어려운 이슈.

cloud가 자체적으로 확장 기술을 제공하지는 않으므로, 확장성을 자동화시키기 위해서는 cloud를 모니터링(관제)해야할 필요성이 생김.  전통적인 IT 환경보다 cloud는 불안정하기에, 관제해야하는 부분은 많다. 모니터링과 관제를 통해 쌓은 경험과 노하우를 바탕으로 CPU, Disk, 메모리 사용량에 대한 다양한 조건 설정을 찾고 자원이 적절히 분배되도록 설정해놓는게 중요하다.

2. 가용성(Availablity)

가용성이란 장애나 문제가 생겼을 때에도 서비스를 제공할 수 있는지의 여부를 의미한다.

(장애가 발생하더라도 안정적인 서비스가 제공되기를 원하므로..)
전통적인 IT환경보다 cloud 인프라가 불안하다. 그 관점에서 본다면 가용성이 확보되지 않을 수도 있음. 이를 극복하기 위해 등장한 개념이 MSA.

-> 가용성을 이해하기 위해서는 클라우드 회사가 어떤 형태로 데이터센터와 물리서버를 갖추었는지 이해하는게 중요하다.

 (여기서는 AWS를 예시로 설명해보도록 한다.)

Region : 가장 큰 기준임. 클라우드의 모든 서비스가 존재하는 물리적 위치
Region 아래에는 여러 개의 가용 영역(Availability zone)이 존재, 1개의 가용 영역은 물리 데이터 센터 하나로 보면 된다.
가용영역이 여러개로 구분되어 있는 이유는, 재해 등 장애 발생시 다른 리전을 통해 서비스를 공급하기 위함.
(재난센터, 재해복구(DR)센터와 같이 전통적인 IT 환경에서도 사용하는 방식)

Availability zone : 실제 데이터가 존재하는 데이터센터

아래 그림을 보면 서울 Region에는 4개의 가용 영역이 있음을 알 수 있다. (23.06 기준)

* Edge Location : 캐시(Cache) 서버 역할 기반 CDN(Content Delivery Network) 서비스

(물리적으로 떨어진 데이터센터간의 전용망을 설치하고, 큰 용량의 콘텐츠 데이터(동영상, 음악, 사진 등)는 복구가 되도록 별도의 물리공간을 구성. 데이터센터 중간에 Caching 기능을 추가 한 것이라 보면 이해가 쉽다.)

전통적인 IT에서는 컴퍼넌트개념, MSA개념이 적용되지않은 경우가 많다. 또한 기본적으로 장애(서버가 죽는다.)가 안나는 것을 전제로 하고 있음. 하지만 cloud에서는 서버가 죽을 수도 있다라는 것을 전제로 한다.

* SLA(Service Level Agreement)
가상화를 사용하고 물리공간이 떨어진 클라우드이기에, 회사 내 자체 서버와 관리자가 있는 것보다는 대응이 미진할 수 밖에 없다. -> SLA의 등장 배경
SLA는 서비스 제공자가 이용자에게 제공하는 서비스의 수준을 정량화한 서비스 품질에 대한 보증문서를 의미한다. 특정 이슈가 발생시, 약속이 지켜지지 않은 경우 서비스 품질에 대한 보상이 기재되어 있음.

* SLA의 주요지표
1. 서비스 가용성 : 갑작스런 클라우드 서비스 장애로 인한 서비스 중단 우려를 최소화하기 위해 서비스 가용 기준 제시
2. 데이터 백업, 복구 및 보안 : 사용자의 데이터가 손상될 경우를 대비하여 서비스 제공자가 데이터의 백업 및  복구 체계를 갖추도록 백업 준수율을 제시하며, 각 고객 기업이 원하는 보안 수준을 제공함.
3. 고객 지원 및 VOC 처리 : 고객 요청 처리율, 서비스 요청 적기 처리율 등을 규정하여 고객 불만등에 대한 처리 기준을 제시함.

클라우드회사가 제공할 수 있는 최대 및 최소의 서비스 기준을 갖추어 놓은 문서가 바로 SLA

(이슈 발생시 누가 책임지는지, 어떤 식으로 처리할 것인지..)

MicroService Architecture를 설명하기 위해서는 Monolithic Architecture의 개념에 대해 이해가 필요하다.

1. Monolithic Architecture

cloud 등장 이전, 전통적인 IT 환경에서 쓰이는 아키텍처는 Monolithic Architecture라 칭함.
일반적으로 대규모 프로젝트(3~5년 이상의)는 완전무결한 구조로 가고자 하는 니즈가 많다.

완전무결한 구조를 위해 cloud 이전 IT 프로젝트에서는 단일구조 형식을 선호하게 되었음.

* Monolithic Architecture의 특징
1) 단일화된 통합 데이터베이스를 사용
2) 서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)

* Monolithic Architecture의 단점
1) 기술이 끊임없이 바뀌는 환경에서 기존 framework에 의존성이 생기며, 잠재적인 이슈가 발생할 가능성이 커짐.
2) 기능이 많아지고 규모가 커져 복잡해질수록 지속적인 통합/배포(CI/CD) 및 유지보수가 어렵다.
3) SPOF(Single Point of Failure, 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용불가)가 발생

4) 빠르게 변하는 트렌드를 따라잡기 어렵다. (서비스 수정 시, 배포등을 위해 전체 재기동 등의 이슈가 발생할 가능성이 높음)

-> 위 단점을 해결하고자 전용망과 고가의 HW 구입, 안정적인 유지보수를 제공하는 기업용 SW를 통해 서비스를 개발함
(장애 가능성을 원천적으로 최소화하기 위한 노력)

위와 같은 Monolitic 구조를 어떻게 보완할지에 대한 대응 방안이 바로 MSA

2. MSA(Mirco Service Architecture)

MSA는 기존 IT 체계에서 사용하던 Monolithic Architecture의 단점을 보완하기 위하여 등장하였다.
아마존, 넷플릭스와 같이 cloud 환경을 성공적으로 활용하는 회사들이 공통적으로 도입하고 있는 아키텍처.
서비스들이 다중 복합적으로 구성되어서 사용자에게 하나의 서비스 화면을 만들어주는 형태의 구조.

(아래 아마존 홈페이지 캡처본에서 붉은 테두리로 표기된 각각의 항목이 하나의 서비스) 

각 서비스들은 API를 통해 데이터를 송수신하며, 분업을 극대화시킨 구조이다,

Monolithic Architecture과 MicroService Architecture를 그림으로 비교하면 아래와 같다.

파란원으로 표기된 Business Logic는 서비스와 동일한 개념이다.

* MSA의 구성원칙
1) 단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐.
2) 독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포할 수 있음.
3) 느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화함. (서비스 간의 통신은 API를 통해서 진행)
4) 높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능함. (각각 서비스는 변경도 되고 끊임없이 바뀌지만 별도의 다운타임 없이 사용자에게  서비스를 제공해 주는 구성이 가능함.)
5) 팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영이 가능. (DevOps와 이어짐)

* MSA의 장점
1) 서비스별 독립적인 배포가 가능함.
2) 스케일링(Scailing, 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장) 가능
3) 장애 대응 용이(전체 서비스 제공에 미치는 영향을 최소화)

-> 일부 서비스에 이슈가 발생할 경우, 이슈가 발생한 서비스만 내리고 나머지 서비스는 제공하므로서, 사용자 입장에서는 이슈가 있었는지도 모를 정도로 유연하게 대응이 가능함.
4) 다중언어(Polyglot, 각 서비스마다 다양한 언어/환경 구성 가능) 지원 -> 신기술 적용이 용이

* MSA의 단점

1) 유지보수가 어려움 

(여러 서비스가 합쳐진 통합테스트를 진행하게 될 경우, 통합된 시스템이 아니므로 유지보수의 난이도와 복잡도가 크게 증가한다.)

2) 애매한 업무분장(도메인) (각 서비스별 업무분장, 도메인을 제대로 정하지 않을 경우, 업무에 비효율성을 초래)

* 왜 MSA 쓰는지?

cloud는 가상화 기능을 사용하게 되고 가상화 기능의 특성상,  물리서버보다 장애에 취약함.
물론 cloud 업체들이 보완기능을 제공하고 있지만, 전통적인 IT 환경보다는 장애 가능성이 더 높다.

-> 장애 취약점을 보완하기 위해 MSA를 활용하기 시작.

Managed Service : As A Service 에 내재화된 개념, 관리 및 서비스의 영역

As a Service : 사용자가 어떤 것을 선택하느냐
- 선택에따라 클라우드 업체의 관리 및 서비스 제공 범위가 달라짐

왜 Managed Service 라는 용어가 등장했나?
- Platform Layer(기업용 SW(DB, Middleware 등) 때문,
 기업용 SW는 어플리케이션, 서비스 구축 뿐만 아니라 전통적인 IT 환경에서 운영할 수 있는 관리자 확보도 매우 중요함.

(관리 인력을 구하기도 어렵도, 비용도 만만 찮음. 실력있는 DBA를 구하기가 얼마나 어려운지 생각해보면..)

Managed service 라는 것은 2010년대 후반부터 시작했으며 2020년대 각광을 받음.

DB를 cloud로 제공하는 회사들은 DBA가 하는 부분까지 직접 Managed Service로 제공하면서, cloud의 장점을 극대화시킴
(PaaS Lock-in 효과로 인해 IaaS를 적용해 기업용 SW적용하는 경우가 많았음.)

cloud는 운영,관리 부분을 cloud 회사가 상당 부분 대신해준다는 장점을 극대화 한다는데서 시작되었다. 그런데 제약이 발생하면 cloud를 이용하는 장점이 줄어든다. 그래서 등장한게 Managed Service의 개념

(사용자는 설치, 운영 및 유지보수를 모두 서비스로 제공받아 사용함.)

예를 들어 Snowflake, mongoDB, okta는 cloud운영하지않고, 기업용 sw만 패키징해서 제공하고 있다.
즉, cloud환경에  sw 설치, 기업들에게 cloud형태로 서비스를 제공(구독형)

( OS, 미들웨어 등 IaaS 위에 독립적인 PaaS 레벨의 서비스를 제공)

* Managed Service 특징
- 사용자는 한 번의 클릭으로 DB를 자동 구성하여 실제 DB에 담아서 이용할 data와  어플리케이션의 연동만 처리

* Managed Service가 생긴 이유

oracle, tmax, redhat같이 기업용 SW만 개발하는 회사들이 인프라 환경이 cloud환경으로 변하면서, cloud vender를 지원할 필요가 생기게 되었다. 여기서 지원이란 cloud 회사 플랫폼 위에서 SW를 제공하거나 자체 서비스를 개발 후 고객이 원하는 환경을 만들어 운영하는 방법이 있음. (HW처럼 활용하는 형태로)

* 장점
- 한 번의 클릭으로 바로 사용할 수 있는 서비스가 제공되어 빠르게 업무 도입 가능
- 관리 및 유지보수가 가능한 기술력 또는 인력이 없더라도 사용 가능
- 다양한 API를 지원하여 개발, 테스트 및 배포 프로세스를 쉽고 빠르게 확보할 수 있음.

* 단점
- Lock-in 효과가 여전히 있음. (선택지가 넓어지긴 했지만)
(snowflake는 AWS, MS, Google만 가능. 국내 업체는 서비스 제공이 안됨)
- Managed 되고 있는 영역에 대해 접근이 제약적임