금융 IT 그리고 클라우드

Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

yundream
2023-04-25
2019-12-11
89568

## 금융 IT, 그리고 클라우드

**금융IT, 그리고 클라우드 - 김기완 솔류션즈 아키텍트(AWS)** 영상의 분석 문서다. 문서를 분석하는 이유는 금융 서비스를 퍼블릭클라우드에 올리는 것에 관심을 가지고 있기 때문이다.

금융 시스템을 경험해 본 적이 없기 때문에, 위 자료의 데이터를 토대로 주로 인터넷 사이트를 통해서 검색한 정보로 금융 시스템 관련 내용을 기술한다. "찾아본 결과 이러하더라 수준" 정도의 내용일거다.

## 영상 개요

이 영상은 2018.5.1일 배포됐다. 금융권 클라우드 이용 확대 관련 내용을 포함한**2019년 1월 1일 개정 전자금융감독규정 개정-시행** 이전의 자료이므로 지금보다는 좀 더 보수적인 환경을 상정하고 있다. 또한 아직은 금융권 클라우드 이용에 대한 가이드가 없는 상태이기 때문에 구체적인 적용 사례가 아닌, 클라우드에 대한 소개, 클라우드로 이전 했을 때 얻을 수 있는 장점들에 대한 개괄적인 내용을 다루고 있다.

개괄적이지만 있어야 할 내용로 빼곡히 채워져 있는 좋은 자료라서, 한단계 더 들어가서 분석을 하기로 했다.

## 금융 산업의 특징

금융 산업은 다른 산업에 비해서 규제가 많은 산업이다. (2018년 5월 1일)국내의 경우 금융산업업은 비중요정보만을 클라우드에서 사용 할 수 있도록 규제하고 있다. 개인신용정보와 고유식별정보는 클라우드에서 사용 할 수가 없기 때문에 일부 빅데이터 분석과 AI 서비스를 활용한 (실험적인)대고객 서비스, 단순 대고객 신규서비스등만을 개발 할 수 있었다. 사실상 금융 서비스에 클라우드를 이용하는 것은 불가능하다고 보면 되겠다.

**2019년 1월 1일 개정 전자금융감독규정 개정-시행**에 따라서 클라우드에서 개인신용정보와 고유식별정보를 사용 할 수 있게 됨에 따라서 클라우드 기반 금융서비스를 개발 할 수 있는 길이 열렸다.

마이크로소프트 애저는 [2019년 11월 19일 금융 클라우드 안전성 평가 완료](https://news.microsoft.com/ko-kr/2019/11/19/azure_finance/)했으며, AWS 역시 " [AWS가 한국 금융 클라우드 시장에 진출하기 위해 금융보안원의 안전성 평가를 통과하기 위한 절차를 밟고 있는 중](https://www.ajunews.com/view/20191205100234488?fbclid=IwAR3f7FNY9Gmx9Hy1hjXOT4gNRrAFam93vMGhQXepcCtv6zxKiMxmoD6z0cs)"이다. 국내외를 막론하고 금융 클라우드를 위한 토대는 마련됐다고 볼 수 있다.

글로벌하게는 이미 많은 금융 서비스들이 클라우드위에서 개발하고 있으며, 그 흐름이 가속화되고 있다. 이런 흐름이 가속화하는 원인을 찾기 위해서 먼저 지금의 (금융을 제외한)인터넷 서비스의 클라우드 활용 흐름을 살펴봐야 할 것 같다.

## 지금의 인터넷 서비스
소비자금융시스템, 계정 시스템, 신용평가 시스템, 채권관리시스템, 광고관리 시스템 등의 솔류션을 기반으로 구성한다. 현재의 인터넷 서비스와 많은 차이를 보이고 있으므로 지금의 (비 금융권)인터넷 서비스가 어떤 방식으로 개발/운영되고 있는지 살펴볼 필요가 있다.

![Born in the cloud vs Large Enterprise](https://docs.google.com/drawings/d/e/2PACX-1vSKEvmR0eV2VS18BxvoqWeYOC05hB1uk8oSn9RCKZf1I8prlduxw39HTJ6EOkbfaMZ3CBGLbr6fMz79/pub?w=816&h=495)

10년이라는 비교적 짧은 시간에 많은 클라우드를 기반으로 하는 기업과 서비스들이 나타났다. 이들은 전통적인 IT 강자들과 경쟁하고 있다.
-   (2019년 12월)현재 Airbnb 의 기업가치는 310억달러(약 37조원)로 힐튼과 메리어트를 뛰어넘었다. Airbnb는 10년 정도된 회사다.
-   우버의 기업가치는 113 조이며, 10년 정도의 역사를 가지고 있다.
-   NETFLIX의 기업가치는 약 165조원이다. 1998년부터 서비스를 시작했는데, 비디오 대여 사업, DVD를 거쳐 지금은 오라인 스트리밍을 위주로 서비스하고 있다. 디즈니와 애플, 아마존닷컴, AT&T가 스트리밍 시장에 뛰어들게 하는 등 스트리밍 시장 붐을 일으킨 회사다. 어느정도냐면 한때 디즈니의 시가총액을 뛰어넘어서 **세계 최대의 엔터테인먼트 기업**이라는 타이틀을 얻었다.

이들 회사들은 모두 AWS를 적극적으로 사용하고 있다. 기타 최근 생겨나는 많은 인터넷 서비스 기업들이 **클라우드우선 전략(cloud-first strategies)**을 펼치고 있다. "클라우드로 부터 태어난(Born in the cloud)기업"이라고 할 수 있겠으며, 전통적인 시장강자들과 강력하게 경쟁하는 형국이다.

아래 그래프는 2008년 부터 2019년까지의 퍼블릭 클라우드 시장의 성장률을 보여준다.
![클라우드 시장 성장](https://docs.google.com/drawings/d/e/2PACX-1vRCgGO530TaGtsQYH3jrR_6tfDGjLWNA1yGUNTqOmEu83OIMJnku7it7JBgHq5-_tqOkyeDoqzxEYVo/pub?w=597&h=367)

출처 : [Public cloud computing market worldwide 2008 ~ 2020](https://www.statista.com/statistics/510350/worldwide-public-cloud-computing/) 단위는 Billion, 매년 12% 이상 성정하고 있다. 가트너는 매년 15% 이상 성장을 하며, 2021년 3025억달러로 확장될 것으로 전망하고 있다.

아래는 주요 국가별로 IT에 사용하는 전체 비용 대비 클라우드에 사용하는 비용의 비율을 보여준다.
![국가별 클라우드 사용 비용](https://docs.google.com/drawings/d/e/2PACX-1vTcpQpr9mf9NZgeVor-pWcfLshmCvgkZKvsmUIvDin9ig5NX3R92bnaxeILhyokJmfAKC4RrmQJhOiJ/pub?w=617&h=378)

미국의 경우 9.2%다. 낮은 수치라고 생각 할 수 있는데 "전체 IT에 사용하는 비용이 분모"다. 대한민국의 경우에는 3.7%로 매우 낮은 수치인데, 달리 생각하면 앞으로 성장가능성이 매우 높을 것이라는 예측을 할 수 있다.

## Cloud-first strategies를 선택하는 이유
인터넷의 특징을 이용 많은 기업들이 다양한 지역에서의 서비스를 목표로하고 있다. 수시로 변하는 다양한 고객의 요구사항에 **빠르게 적응**해서 빠르게 서비스를 제공해서 기회를 찾는 것을 주요 전략 중 하나로 선택하고 있다.

클라우드는 빠른 적응과 기술, 전략의 선택을 가능하게 한다. 온프레미스기반으로 하드웨어/소프트웨어 인프라를 구성하고 소프트웨어를 올리기 위해서는 많은 시간이 소비된다. 디지털 금융 서비스를 만들어야 한다고 생각해보자. 컴퓨팅, 스토리지, 네트워크에 대한 **용량산정**부터 난관에 부닥칠거다. 보안, 데이터 분석 시스템의 구성, 모니터링및관제, K8s, Kafka, Redis Cluster, 고가용성 데이터베이스... 각 시스템에 대한 운영/유지/보수, 인력(개발,운영,유지/보수)... 핵심 시스템 인프라를 구성해야 하면, 하드웨어 용량산정->하드웨어 선정->발주->배치 까지 몇 달의 시간이 소모될 수 있다.

중요정보(개인정보,신용정보)를 다루어야 한다면 보안/컴플라이언스 이슈를 신경써야 한다. 글로벌 서비스를 생각한다면 지역별 보안/컴플라이이언스 이슈에 대응해야 한다.

당신이 스타트업이라면 인력, 시간, 비용의 문제로 서비스에 접근 할 수 없을 것이다. 이미 해당 산업에 진출한 기업이라면 새로운 서비스를 개발하는데 어려움을 겪을 것이다.

- 스타트업 : 기존 산업에 진입하는 것 자체가 힘들 것이다. 일단 스타트업은 인력 구성하는 것부터 쉽지 않다.
- 시장에 안착한 기업 : 새로운 서비스 개발에 허들로 작동 한다. 경쟁력을 확보하는데 어려움을 겪을 것이다.

클라우드를 선택 할 경우 **속도**와 **유연성**을 얻을 수 있다. 속도와 유연성이 성공의 전부는 아니다. 하지만 성공에 중요한 도움을 줄 수 있다.

- 인프라 전개 & 테스트 사이클이 월 단위에서 분단위가 된다.
- 가용성, 확장성, 보안, 모니터링의 많은 부분을 클라우드 서비스 제공자에게 **위임**할 수 있다.
- 새로운 기술에 대한 빠른 접근이 가능하다. 기술 탐색, 검토, 테스트, 적용, 실패, 기술탐색... 의 사이클을 극적으로 줄일 수 있다.

속도와 유연성을 이용해서 **시장 환경에 대한 적응력**을 얻을 수 있는데, 인터넷 시장에서 **적응**은 가장 중요한 덕목이다.

컴퓨팅 인프라를 구축한다고 가정해보자. AWS EC2는 일종의 가상화된 컴퓨팅 시스템인데 아래와 같은 다양한 유형을 제공한다.

- General Purpose : 범용적으로 사용 할 수 있는 인스턴스
- Compute Optimized : 게임서버, 과학 모델링, 고성능 웹서버, 미디어 트랜스코딩과 같은 높은 CPU 성능을 제공하는 인스턴스. 최대 96 core(vCPUs) 인스턴스를 제공한다.
- Storage and IO Optimized : Hadoop과 같은 대용량 데이터세트에 대한 높은 순차적 읽기/쓰기를 제공하는 스토리지 인스턴스.
- GPU Enabled Instance : 딥 러닝 목적으로 사용한다. NVIDIA Tesla V100 GPU, K80 GPU, Tesla M60 GPU 등을 제공 한다.
- Memory Optimized : 실시간 빅 데이터 분석, 대용량 인 메모리캐시, 고성능 데이터베이스와 같은 메모리 집약적 애플리케이션을 위한 인스턴스. 최대 24T 메모리 인스턴스를 제공한다.
- F1 FPGA Instance : 하드웨어 가속을 위한 FPGA 하드웨어를 제공한다. 빅 데이터 분석, 유전체학, EDA(전자 설계 자동화), 이미지 및 비디오 처리, 압축, 보안, 검색/분석 영역에서 사용 할 수 있다.

딥 러닝 프로젝트를 수행해야 한다고 가정해보자. 하드웨어 선정과 테스트 배치까지 몇 달이 걸릴지 예상 할 수 없다. AWS 클라우드에서는 몇 분안에 최대 16개의 NVIDIA K80GPU를 사용할 수 있는 인스턴스를 만들어서 테스트 할 수 있다. 적당하지 않는 하드웨어라고 판단되면 ? 그냥 끄면 된다.

이러한 이유로 많은 스타트업들이 **Cloud-First 전략**을 사용하고 있다.

## Cloud-First strategies 는 모든 것을 클라우드로 하라는 전략이 아니다.

의사결정자는(CTO, CIO)는 클라우드 전략을 만들라고 지시하기 보다는 기존의 비지니스 환경을 개선하라고 지시하는게 좋은 방향이다. 아키텍트(혹은 개발자)는 비지니스 환경의 개선을 목표로 **Cloud Native**, **Hybrid cloud**등의 기업환경에 맞는 전략을 세워나가야 한다.

## 금융과 클라우드
앞서 언급했듯이 기존 기업도 비지니스 환경 개선과 혁신을 꾀하고 있다. 비교적 안정적으로(어느 정도 예상 가능한) 경쟁하던 기업들 뿐만 아니라 빠르게 치고 올라오는 인터넷 기업들과도 경쟁을 해야 하기 때문에 비지니스 환경을 개선하기 위한 활동은 필수적인 활동이 되고 있다. 당연히 벤치마킹을 통해서 클라우드의 도입에 적극적으로 나서고 있다.

[Oscar Insurance](https://www.hioscar.com/)는 뉴욕에 본사를 두고 있는 **건강 보험** 회사다. 이 회사는 단 3개월 만에 AWS위에 분석 시스템을 포함한 건강 보험 플랫폼을 개발했다. 건강 보험은 규제 서비스로 HIPAA(미국 의료 정보 보호법)의 요구사항을 만족해야 한다. AWS는 HIPAA인증 서비스 제공자이며, 애플리케이션 레벨에서 HIPAA를 만족하기 위한 서비스/기능들 역시 제공한다. 이 회사는 AWS의 공동 책임 모델에 따라서 보안부담을 줄이면서 AWS에서 제공하는 암호화된 안전한 스토리지/볼륨, 데이터웨어하우스 서비스, 보안 그룹, 접근제어 서비스 등을 이용해서 구축기간을 크게 앞당길 수 있었다. Oscar에서 사용한 보안 관련 서비스는 아래와 같다.
-   Encrypted [S3](https://www.joinc.co.kr/w/taglist?name=S3), [MFA](https://www.joinc.co.kr/w/man/12/mfa)
-   EC2 Encrypted EBS Volumes
-   Compliant Redshift Analytics
-   Security Groups

[Simple Bank](https://www.simple.com/)는 오리건주에 위치한 미국 은행이다. 이 회사는 AWS를 사용해서 PCIDSS(Payment Card Industry Data Security Standard)를 준수하는 가상 뱅킹 플랫폼을 구축했다.

[Capital One](https://www.capitalone.com/)은 버지니아 맥린에 본사를 둔 신용카드, Auto loan, 뱅킹을 전문으로 하는 은행 지주 회사로 자산규모로 미국 최대 은행 목록에서 10위를 차지했다. [Capital One Innovator](https://aws.amazon.com/ko/solutions/case-studies/capital-one/)에서 **Capital One on AWS**관련해서 흥미로운 정보들을 얻을 수 있다. 간단히 요약했다.

- 20년만에 성숙된 기술인 클라우드 컴퓨팅은 모든 유형의 규모의 비지니스에서 속도와 민첩성을 극대화하며, 운영을 분리 함으로써 새로운 고객 가치를 혁신하고 구축하는데 집중할 수 있게 했다.
- 대기업들은 항상 그러한 변화에 어느 정도 저항을 하고 있는데, 복잡한 운영규칙과 광범위한 규정준수 요구사항을 가진 금융기관은 특히 그러했다.
- Capital One은 고객 경험을 변화시키는 새로운 기술을 빠르게 선택하길 원했다. 새로운 기술을 효과적으로 활용할 수 있도록 관행과 사고방식을 변화시켰는데, 즉 Capital One을 디지털 기술회사로 만들기 위한 일련의 실천적 활동을 수행했다. 그 최전선에는 [DevOps](https://www.joinc.co.kr/w/taglist?name=DevOps)가 있다.
- DevOps는 애자일이 기초로 하고 있으며, 개발/테스트/배포의 자동화, 모니터링과 지속적인 통합(CICD)을 통한 개발주기의 단축으로 고객의 요구에 빠르게 반응하는 데 중요한 역할을 하고 있다.
- Capital One은 고객의 피드백에 집착하며, 고객의 아이디어를 제품화해서 금융서비스 경험을 최고 수준으로 올릴 수 있다.
- 이를 위해서 Cloud-first 정책을 사용하고 있으며, 모든 새로운 애플리케이션들은 클라우드에 맞게 설계되고 마이크로서비스 모델로 배포하고 있다.
- AWS를 사용하여 몇 개월이 걸리던 프로세스를 자동화 할 수 있었다.

[DBS Bank](https://www.dbs.com.sg/)는 싱가포르의 Marina Bay Financial Center에 본사를 둔 다국적 은행 및 금융 서비스 회사다. 모든 퍼블릭 웹 자산을 AWS로 이전(인터넷 뱅킹을 워크로드와 고객 트래픽의 50%)하려하고 있다. 또한 디지털 변환 과정의 일환으로 AWS Lambda, 머신 러닝, 그리드 컴퓨팅 및 데이터 분석 워크로드도 실험하고 있다.

[AWS 금융 서비스 사례 연구](https://aws.amazon.com/ko/financial-services/case-studies/)에서 다양한 사례를 찾아볼 수 있다.

## 금융의 과거(현재)

금융은 메인프레임으로 부터 시작했다. 구성은 아래와 같다.
![메임프레임 그리고 더미 터미널](https://docs.google.com/drawings/d/e/2PACX-1vQbEVFxR4D4UefWChgPNOERRpcuCM2Yt7brd4kuFrMgunGoXkkyi1nkE11nCTL8YQozf9j0qX5_nrdf/pub?w=720&h=670)

모든 애플리케이션을 실행하는 거대한 중앙집중적인 컴퓨터 메인프레임이 존재한다. 그리고 은행의 각 지점에 있는 더미 터미널을 통해서 메인프레임에 접근해서 업무를 처리하는 방식이다. PC 통신시절의 터미널 서비스를 생각하면 되는 간단한 구조다.

시장(고객)의 요구사항과 기술은 변하기 마련이라서 지금의 아키텍처로는 업무 처리 효율이 떨어지는 시점이 오기 마련이다. 이제 금융기업은 "차세대 프로젝트"라는 것을 수행해서 아키텍처를 고도화 한다. 대략 아래와 같은 모습이 될 것이다.

![차세대 프로젝트](https://docs.google.com/drawings/d/e/2PACX-1vRWiVzn_oeF6PG_ZQNdmoko_XXc1wfGvtXROs03pPr6JbF9A1xvdgcDp6ecDSKk8QLDPrY0mGOLoxxX/pub?w=782&h=676)

데이터베이스, TX 처리, middleware, batch processing등 핵심적인 업무는 여전히 메인프레임이 처리한다. 그외의 대외계, EAI, 채널, 외환 BP 서버등은 Unix/Windows 서버를 활용한다. 메인프레임을 클러스터링하거나 SNA(System Network Architecture)네트워크를 TCP/IP등으로 마이그레이션 하는 작업을 수행한다. 하지만 근본적인 아키텍처의 변화는 보이지 않는다. 여전히 계층적인 구조이며, 모노리딕 구조를 사용한다.

이러한 구조로도 한계가 보이면 "다운사이징"을 한다. 데이터베이스로 오라클을 사용하고 웹 환경으로 이주한다. 아래 그림을 보자.

![다운사이징](https://docs.google.com/drawings/d/e/2PACX-1vQjapKpi8wCbMXigA7OktpfH33mFwr9BbLn7uHdbAwSl83nl3pSCnahEsKMV3I10s7bmuOui56nUaU2/pub?w=782&h=676)

메인프레임-차세대-다운사이징에 따른 변화가 있기는 하지만 전체적으로 봤을 때, 아키텍처레벨에서의 변화는 없는 걸 확인 할 수 있다. DB 구조 및 애플리케이션 컨테이너만 변경되었을 뿐 여전히 모노리딕 구조를 가지고 있다. 아래 그림은 모노리딕 구성을 묘사하고 있다.

![모노리딕 구성](https://docs.google.com/drawings/d/e/2PACX-1vRM8U9Bu97l1SiN4JtT8ZgmLGY8u345Cc9lNW7gp3U5hP1nFUH8cM3OeHHdPEzDxo85f1gwUARtbG6q/pub?w=738&h=684)

모든 데이터베이스는 **액세스 패턴**에 관계없이 관계형 데이터베이스에 저장이 되며, 애플리케이션은 **특성과 무관하게** 하나의 미들웨어 환경에서 동작한다.

**액세스 패턴**은 애플리케이션의 요구에 따라서 어떻게 저장하고 읽어야지 효과적으로 작동할 수 있을지를 계획해서 설계해야 한다. 하나의 액세스 패턴을 가지게 되면 비지니스 요구사항의 변화에 효과적으로 대응하기 어려워진다. 시간이 지날 수록 효율이 떨어질 것이다. 쿼리가 복잡해지고 결국 한 페이지가 넘어가는 SQL 문을 만드는 등의 문제가 발생한다.

애플리케이션 개발 환경도 통합된다(보통 Java, 그 중에서도 Java Spring 프레임워크). 코드는 아키텍처를 따라가기 때문에 통합될 수 밖에 없다. 여기에서도 액세스 패턴에서 발생했던 문제가 발생한다. 다양한 환경에서 다양한 경험을 가지고 있는 개발자들을 고용 할 수 없게 되면서 트랜드에서 점점 멀어지게 된다.

이러한 것들이 하나하나 모여서 **기술부채**가 쌓인다.

>  
> 
> Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. - Ward Cunningham, 1992  
>   
> 일단 코드를 만들면 부채도 함께 지게된다. 작은 부채는 코드의 재 작성을 통해서 즉시 상환하는게 가능하며, 이는 개발의 속도를 높인다. 부채가 상환되지 않으면 위험이 발생한다. 올바르게 수정되지 않은 이러한 코드들은 이자를 낳고 전체 엔지니어링 조직은 불완전한 구현으로 인한 기술적 빚더미에 놓인다. 이 상태에서 엔지니어링 조직은 발전을 멈추게 된다.

아무리 좋은 코드를 만들었다고 하더라도 일단 코드가 배포되고 나면, 부채가 만들어진다. "환경이 변하기 때문"이다. 부채를 그때 그때 제거하지 못하고 계속 쌓이다 보면, 부채의 무게를 감당 할 수 없게 되는데 이때 하는게 "차세대"다. 중앙집중식 모노리딕은 모든 기능과 컴포넌트들이 밀접하게 연결되어 있기 때문에 부채를 민첩하게 제거하는게 쉽지 않다. 하나의 부채를 해결하려다 전체 시스템의 균형이 무너질 수 있기 때문이다. 그러다보니 차세대는 전체 시스템을 갈아 엎는 수준의 거대하고 위험한 작업이 된다. 이러한 환경에서 혁신적인 시도는 쉽지 않을 것이다.

"인터넷에서 올바른 답을 얻는 가장 좋은 방법은 질문을 하는 것이 아니라 틀린답을 올리는 것이다."라는 격언이 있다. 외부 컨설팅을 받고 고민고민해서 완전한 하나의 큰 계획을 세워서 몇 년에 걸처서 차세대를 한다. 하지만 더 좋은 방법은 코드를 만들어서 테스트를 하고 새로운 기능을 추가하고 문제를 수정 할 수 있으면 된다. 부채의 상환을 미루고 미루고 미뤄서 차세대를 해야 할 필요가 있느냐는 것이다.

기술부채의 빠른 상환, 시장의 요구에 발빠른 대응을 위해서 논의되고 있는 기술들이 **MSA**와 **DevOps**다.

## 현대적인 아키텍처들 방법론들
인터넷에서 "올바른 답을 얻는 가장 좋은 방법은 질문을 하는 것이 아니라 틀린답을 올리는 것"이다. 틀린답을 올리기 위해서는 빠른 실행이 선행되야 한다. 오랜 시간을 거쳐서 고민을 하고 만드는 대신, 빠르게 실행하고 빠르게 틀려보고 빠르게 해법을 찾는 방법이 더 효과적이지 않을까 ? 클라우드 환경에서는 가능하다.

앞서 언급했던 MSA(Micro Service Architecture)를 살펴보자. 기존 금융에서는 데이터를 오라클이나 DB2에 전부 집어 넣었다. 서비스를 만들 경우 중앙에 있는 이 데이터베이스에 질의를 해야 하는데, 서비스에 최적화되지 않는 데이터베이스다 보니 이런 저런 복잡한 쿼리를 만들어서 사용해야 한다. MSA에서는 "서비스 별로" 기능과 데이터베이스를 모두 분리한다. 신용 조회 서비스, 계약서 조회 서비스, 상품 조회 서비스 ... 등의 서비스를 모두 분리하고 각 서비스마다 **서비스 목적과 액세스 패턴에 맞는 데이터베이스를 선택**할 수 있다. 효과적인 시스템을 구성 할 수 있을 것이다.

![마이크로 서비스](https://docs.google.com/drawings/d/e/2PACX-1vR1J9i87XEVFovgvZbS5CEk0iePjqpe9iNOEXROXSyDFlOO5oj6PyDeb9Q7PnBtWnI0duxkLt_E5xw9/pub?w=454&h=258)

각 서비스가 서로 느슨하게 연결되기 때문에 피해가 발생해도 크게 확산되지 않도록 할 수 있다.

서비스가 분리되며, 각 개발조직은 자신의 서비스에 대한 주도권을 가져갈 수 있기 때문에 개발조직도 유연하게 구성 할 수 있다. 아래 그림을 보자.

![독립적인 개발 파이프 라인 구성](https://docs.google.com/drawings/d/e/2PACX-1vRj6WyY-CFKbqOZti9RMESx-C4wxNyFO0vRwNgD_c2ITmhg-MNpUuVUQUV0H1mxDVUvUr-EanXFzc3v/pub?w=878&h=359)

어떤 서비스는 굳이 RDBMS를 사용 할 필요가 없을 것이다. NoSQL 경우에 따라서는 그냥 File로 저장한 후 처리 할 수도 있다. 언어도 하나를 고집 할 필요가 없다. Python, GoLang, Java, Node.js 다양하게 가져 갈 수 있다. CICD툴, UnitTest, Logging, 모니터링, 데이터 플랫폼, 분석 플랫폼, A.I 플랫폼 ... 등등 서비스에 맞는 기술을 선택 할 수 있다. 결국 각 서비스별로 독립적인 개발 파이프라인을 구성 할 수 있게 된다.

독자적인 개발 파이프라인, 독자적인 데이터베이스와 애플리케이션을 가지고 있기 때문에 기능 추가와 변경, 실패에 따른 위험의 확산을 최소화 할 수 있다. 따라서 서비스에 대한 주도권을 가지고 빠른 개발이 가능하다.

물론 MSA, DevOps과 같은 기술과 툴들을 금융과 보험 분야에 지금 당장 큰 폭으로 적용하는 건 쉽지 않을 것이다. 하지만 기술적인 빚을 넘어서기 위해서 준비해가야 할 것이다.

1. 차별화에 집중 : 금융과 보험서비스에 대한 핵심역량 역량을 가지고 있다. 이들 핵심역량을 강화하기 위해서 인프라, 비지니스 애플리케이션의 리소스를 점진적으로 재배치할 필요가 있다.
2. 전략 맞춤형 마이그레이션 : 당장 전체 시스템을 클라우드로 올리는 것은 리스크가 클 수 있다. 하이브리드 전략을 사용 할 수 있을 것이다. 각 조직에 맞는 거버넌스를 수립하고 거버넌스를 지원하기 위한 정책과 툴들을 선택한다. 파트너십을 이용해서 안전한 클라우드 전략을 수립할 수 있다.
3. 빠른 속도의 혁신 : 빠른 실패, 낮은 실패비용으로 혁신을 실험해야 한다. 경쟁 우위를 유지하기 위해서 지속적인 변경과 테스트와 실패를 할 수 있어야 한다.
4. 위험 요소 최소화 : 그럼에도 불구하고 리소스에 대한 보안을 신경써야 한다. 금융과 보험의 특성상 보안, 컴플라이언스, 가용성을 모두 고려한 애플리케이션을 개발해야 해야 한다.

## 금융권과 DevOps, MSA 사례들
금융권에서도 DevOps, MSA 도입이 늘어나고 있다. Capital One은 [Hygieia](https://www.capitalone.com/tech/solutions/hygieia/)라는 DevOps 관리 소프트웨어를 개발해서 사용하고 있으며, 오픈소스로 배포하고 있다.

Hygieia는 소프트웨어 개발에서 배포까지의 파이프라인을 시각화해서 단일 대시보드로 제공한다.
- 팀 대시보드 : 작업항목, 코드 저장소, 빌드, 품질(유닛테스트, 보안, 테스트 커버리지)등을 하나의 대시보드에서 모니터링 할 수 있다.
- 설정 대시보드 : 프로젝트의 가장 중요한 위젯들을 대시보드에 출력 할 수 있다.
- 실시간 상태 : 대시보드를 통해서 실시간으로 품질, 생산성, 진행중인 작업을 모니터링 할 수 있다.
- 의사결정 대시보드 : 주요 DevOps 메트릭의 집약된 뷰를 제공한다.

**Critical Stack**은 컨테이너의 실행, 컨테이너 네트워크, 로깅, 역할 기반 액세스제어(Role Based Access Control), 배포자동화, 요구 변화에 따른 오토 스케일링, 가용성, 성능 모니터링 등을 포함한 소프트웨어다. Capital One은 이런 소프트웨어를 다른 금융회사에도 판매하고 있다.

금융권에서의 DevOps, MSA가 멀리 있는 이야기가 아니란 것이다. 금융서비스 기업들도 소프트웨어회사로의 전환을 서두르고 있다.

## 기술적인 빚을 갚아나가기
![기술적인 빚을 갚아나가기](https://docs.google.com/drawings/d/e/2PACX-1vQNbwHyS-22OX_8RrxD4NO-kcKA036zRyiZ2VxfBPAQirfVlwbrrA6kruurgy3_46r4zU6cIHiXJogC/pub?w=878&h=490)
Capital One 외에도, DBS, BBVA, Finra, Allianze 등 많은 뱅킹&페이먼트, 캐피탈, 보험사들이 기술적인 빚을 줄여가면서 디지털 역량을 키우기 위해서 (AWS를 기반으로)노력하고 있다.

## 왜 AWS를 사용하는가
### 혁신
![AWS를 통한 빠른 혁신](https://docs.google.com/drawings/d/e/2PACX-1vTKdklVZn0lvRVAJBkE3uDEcZ7o_ELk1MkQVmufJ6OzO5pIdsg_vtLCe8IBQ-nZGmC7jJxMq7SbiGNo/pub?w=1042&h=373)

IDC 환경에서 컴퓨팅 파워는 제한된다. Core, 메모리, 스토리지 모두 제한된다. 많은 운영 비용이 들어간다. 한번 배치된 하드웨어는 빠르게 교체하기가 힘들기 때문에 하드웨어와 운영체제가 노후화될 수 있다.

AWS로 이전 할 경우

1. 리소스 제약이 사라진다. Core와 메모리를 거의 무제한으로 사용 할 수 있다. S3를 사용 할 경우 역시 무제한의 스토리지를 사용 할 수 있다. 모든 자원은 미래를 대비해서 미리 준비할 필요 없이, 쓸 만큼만 사용하고 비용을 지불 할 수 있다.
2. 빠른 사용이 가능하다. IDC 환경에서 서버 50대가 필요하다고 가정해보자. 50대를 IDC에 전개하는데 3~6개월은 걸릴거다. 용량 산정하고 기안올리고 제안서 발송하고 물건너서 서버 배달되고 IDC에 배치하는 여러 프로세스를 거쳐야 하기 때문이다. AWS에서는 몇 분안에 필요한 서버자원을 전개 할 수 있다.
3. AWS는 인프라스트럭처만 제공하지 않는다. 아래의 AWS Platform 스택을 보자.

![AWS Platform](https://docs.google.com/drawings/d/e/2PACX-1vTGOkjGtoR5K1jwvp3SK2VVMjQQmUKiLLYPBmsyGGwtQxkBTyMLvOgWNHZZvrySVGWwpz9HcV7arZaJ/pub?w=1464&h=990)

인프라스트럭처라고 할 수 있는 영역은 3개 정도 영역이다. 이외에 비지니스를 위해서 필요한 데이터베이스, 분석, 머신러닝, 보안, 기술지원, 인증/교육 등 수많은 서비스들을 제공한다. 이러한 서비스들의 대부분은 API를 이용해서 즉시 사용 할 수 있다.

AWS에서의 **혁신**의 핵심은 인프라스트럭처의 **소프트웨어화**이다. 소프트웨어를 실행해서 원하는 업무를 수행하는 것처럼, 인프라스트럭처도 API를 호출해서 즉시즉시 사용 할 수 있다.

## 컴퓨팅 환경
클라우드 서비스를 사용 할 때, 가장 관심이 있는 부분은 아마도 (AWS에서는 EC2라고 부르는) 컴퓨팅 서비스일 것이다. AWS는 다양한 워크로드의 지원을 위해서 다양한 타입의 EC2를 제공한다.

![EC2 타입](https://docs.google.com/drawings/d/e/2PACX-1vSWU8pUDGI68iOZ7y2XieoseyB-B4diQq1B9a2twK0PJ9qOfXL-7Migxz-Yol2BZvSH0WQcfKwGo1Br/pub?w=1225&h=358)

범용목적의 인스턴스에서, 컴퓨팅 최적화, 메모리 최적화, 스토리지 최적화, 그래픽 목적, 딥 러닝을 위한 GPU 컴퓨팅, FPGAs(field programmable gate array), Bare Metal 까지 워크로드에 최적화된 리소스를 사용 할 수 있다.

## Serverless
워크로드에 따라서 아예 서버가 없는 Serverless 인프라를 구성 할 수 있다. 서버리스아키텍처를 사용하면, 서버를 고려하지 않고 애플리케이션과 서비스를 구성 할 수 있다. 서버 혹은 클러스터 프로비저닝, 패치적용, 운영체제 유지관리, 용량 산정과 같은 인프라 관리 작업을 덜어낼 수 있다. 아래 아키텍처를 보자.

![Serverless 아키텍처](https://docs.google.com/drawings/d/e/2PACX-1vSsv59fBL6CqF5i9pWiutfp7WGUw1oyNky1yL4dBEuzsr6ly61FvU1yVftDIz-oCLmdd_x3Zsb2WWKM/pub?w=812&h=416)

위 아키텍처는 이미지와 동영상 파일을 처리하는 시스템을 묘사하고 있다. AWS에서 제공하는 Application Load balancer, API Gateway, DynamoDB, S3, Kinesis, SQS 등은 이벤트 소스(Event Source)로 설정 할 수 있다. S3에 파일이 upload되면, 이벤트가 발생하고 이 이벤트를 처리할 "Lambda 함수"를 실행 할 수 있다. Lambda란 일종의 코드 조각이라고 보면 된다.

1. S3(Object Stroage)에 유저가 파일을 올린다.
2. 파일 Upload 이벤트가 발생했을 때, 처리할 Lambda를 등록한다.
3. 이 Lambda는 섬네일을 만들고, 변환하고, 분류/태깅 하는 등의 작업을 수행한다.
4. 작업을 마치면 DynamoDB의 레코드를 Update 한다.
5. DynamoDB는 레코드 Update에 대한 Lambda 함수를 실행해서, 유저에게 작업완료 push를 전송한다.

이 작업을 하는데 어떤 서버도 필요없다. 사용자는 그냥 코드만 올리면 된다. 2019년 현재 Lambda는 Node.js, Python, Java, C#, [golang](https://www.joinc.co.kr/w/taglist?name=Go), PowerShell, Ruby를 지원한다.

서버리스는 모든 워크로드에 적용 할 수 있지만 CPU 사용율이 낮은 작업, 비 주기적으로 실행되는 작업, 주기적으로 실행되는 작업(스케쥴 이벤트를 발생 시킬 수도 있다)등에 특히 효과적으로 사용 할 수 있다. 비용은 Lambda의 실행 시간(100ms 단위)당 과금이므로 비용도 절약 할 수 있을 것이다.

## Serverless 개발 툴들
그 외에도 다양한 Serverless 개발 툴을 제공한다.

![AWS에서 제공하는 다양한 툴들](https://docs.google.com/drawings/d/e/2PACX-1vQSuOOU9P0YaSpoo910bJ_Ied_Yd5kt2_yyPhM2wqvW_fRPlRYau1GD5h8dKxoFEGPbdDaYFiuXZTLU/pub?w=937&h=819)

DynamoDB의 경우 인스턴스를 만들고 HA 구성하고, 확장작업, 백업계획을 고민할 필요 없이 그냥 테이블만 만들면 된다. Amazon Aurora RDBMS도 Serverless타입을 선택할 경우 역시 서버 관리 부담이 사라진다.

기타 개발을 도와주기 위한 Cloud9(클라우드 IDE), SAM(Serverless Application 개발 플랫폼), CodeBuild(CI), CodePipeline(CI/CD), X-RAY(분산 추적 시스템)등의 서비스도 제공한다.

이러한 서비스를 이용해서 개발자는 "비지니스로직 개발에만" 집중할 수 있다.

## DevOps 툴들
DevOps는 개발, 배포, 모니터링, (고객 혹은 시장으로 부터의)피드백이 다시 개발에 반영되는 사이클을 자동화하고 빠르고 안전하게 출시하는 것을 목표로 한다. 주기적으로 자주 배포를 하면서 **통합의 지옥**으로 부터 벗어나고 빠르게 시장에 적응 할 수 있다.

AWS는 DevOps를 위한 완전한 툴을 지원한다.
![AWS의 DevOps 툴들](https://docs.google.com/drawings/d/e/2PACX-1vQKITFxEsVt9mqoKVYuabVaK5BEcVv2bKm0kqMJ6pJw7hvb-RbyOBwFtQvkHJBavQo5Cr8HdZdfKYqA/pub?w=889&h=431)

AWS는 CodeCommit라는 Git 저장소를 제공한다. 개발자가 개발한 코드를 Commit 하면, AWS CodeCommit가 CodeBuild를 호출해서 코드를 빌드한다. AWS CodeCommit대신 GitHub, BitBucket등의 git 저장소를 사용 할 수도 있다.

AWS CodeBuild가 코드를 빌드하면서 3-party 툴을 이용해서 코드를 테스트 한다. 각 언어와 플렛폼에서 제공하는 유닛테스트 툴, 정적분석 툴등을 실행 할 수 있다.

빌드가 다 끝나면 AWS CodeDeploy로 코드를 배포한다. EC2 인스턴스 뿐만 아니라, ECS(Container 서비스), EKS(관리형 kubernetes 서비스), Lambda, 온-프레미스까지 자유롭게 배포 할 수 있다. 단지 "실행파일"만 배포하는 것이 아니라 애플리케이션을 구성하는 로드밸런서, 네트워크, 데이터베이스, 스토리지등 전체 형상을 일관되게 일괄 배포 할 수 있다. 뿐만 아니라 Blue/Green, Canary 배포도 가능하기 때문에 무중단으로 안전하게 배포 할 수 있다.

아래 그림은 AWS DevOps 툴을 이용한 컨테이너 기반의 개발/배포 환경을 묘사하고 있다.

![DevOps 도구로 컨테이너 배포](https://docs.google.com/drawings/d/e/2PACX-1vSGktTKBuz5GKKBEyBtv3l1gKgy1bDhlJVXckkNu-hr62Ac-u1Dq95_kuZF2zobymk6235qEE2Gnniy/pub?w=765&h=492)

개발자가 코드를 commit 하면, Codebuild에서 빌드를 한다. 빌드가 끝나면 도커 이미지로 만들고 ECR(AWS에서 제공하는 docker image registory)에 Push 할 수 있다. 이후 EKS(Elastic Kubernetes Service)혹은 ECS(Elastic Container Service)로 배포 할 수 있다.

### [17.](https://www.joinc.co.kr/w/man/12/finance/ITandFinance#toc) 클라우드 배포와 레거시 배포의 차이

![클라우드 배포와 레거시 배포의 차이](https://docs.google.com/drawings/d/e/2PACX-1vSospTVRIyFCGPa4kDat4hSkhW5_OlfPprjVXZe00BKvKHWMBNCm098mlEN-P0DQUh5-mgmpqRAJUvX/pub?w=880&h=746)

레거시 배포환경과 클라우드 배포환경의 차이점을 살펴보자.

레거시에서는 **UAT(User Acceptance Testing)**, **SIT(System Integration Testing)**으로 이어지는 테스트를 끝내고 나면 **Production**으로 배포를 한다. 이때 UAT와 SIT는 Production의 축소된 환경으로 구성을 하게 된다. Production과 동일한 환경에서 테스트를 하면 바람직하겠으나 고정비용이 워낙 크게 들어가고 구성하는데도 상당한 시간이 들어가기 때문이다. 레거시 환경은 아래와 같은 문제를 가진다.

1.  Production 환경과 테스트 환경이 다르다.
2.  Production 환경과 테스트 환경을 수동으로 구성해야 한다. Chef나 스크립트로 자동화 할 수 있겠으나, 이런 환경을 찾아볼 수 있을지 모르겠다.
3.  롤백이 어렵다. 즉 변경작업에 큰 위험이 따르고, 위험을 줄이기 위해서 출시기간이 길어진다.

클라우드는 자원의 제한이 없다. 그리고 인프라와 인프라를 구성하는 자원을 코드화(IaC - Infrastructure As Code) 할 수 있다. AWS에서 제공하는 CloudFormation이나 [Terraform](https://www.joinc.co.kr/w/taglist?name=Terraform)을 이용해서 Product 환경을 코드화 하면, 코드를 복사하듯이 테스트 환경으로 복사 할 수 있다. 수분만에 테스트 환경을 만들 수 있을 뿐만 아니라 (테스트가 끝나면)자원을 바로 회수 할 수 있으니, 비용 걱정도 없다.

이러한 특성 때문에, 클라우드에서는 **Blue/Green 배포**를 어려움 없이 사용 할 수 있다. 운영 중인 Production을 Blue로 하고, 새로 배포할 Production을 Green으로 실행 한 다음 네임서버를 Green으로 바꿔주는 방식이다. 무중단으로 배포 할 수 있으며, Blue 환경도 일정기간 운영하면서 Green 환경에 문제가 생기면 즉시 롤백 할 수도 있다.

## 글로벌 인프라스트럭처

![AWS 글로벌 인프라스트럭처](https://docs.google.com/drawings/d/e/2PACX-1vRkTiEK1W7G5sdwhSxaAlzvkX5bQpXWlqUE5GVvh3xmLeuHNf6BPRBzbHdV6o8yNHpTibjaVI1xaHvu/pub?w=956&h=536)

금융서비스도 글로벌화 되고 있으며, 계속 확대될 것이다. 2020년 1월 현재 AWS는 전 세계 22개 리전, 69개의 가용 영역, 119개의 Edge Locaion, 11개의 Regional Edge Caches 를 가지고 있다.

AWS를 이용하면 전 세계에 걸친 금융 서비스 인프라를 구축 할 수 있다. 물론 각 지역별 보안&컴플라이언스 이슈가 있기 때문에 쉬운일은 아닐 것이다. 하지만 역으로 생각해보면 AWS를 이용하는 것으로 지역이슈를 쉽게 해결 할 수 있다. 예를 들어서 유럽에서 금융 서비스를 하려면 GDPR을 준수해야 하는데, AWS는 GDPR을 준수하고 있으므로 유럽리전에 금융 서비스를 전개 할 수 있다. 자세한 것은 [AWS의 규정 준수 프로그램](https://aws.amazon.com/ko/compliance/programs/)을 참고하자.

## AWS 비용에 대한 이해
AWS 클라우드에 전개하는 것과 온프레미스로 전개할 때 필요한 비용에 대해서 살펴보자.

"우리 서비스를 위해서는 16core, 1024G 메모리 그리고 1T SSD 가 필요하다. 장비를 직접 구매하면 xxx 정도의 비용이 들어가고 AWS의 EC2로 구성하면 yyy의 비용이 들어간다" 이러한 단순한 비교는 의미가 없다. 왜냐하면 EC2는 단지 core, 메모리, 디스크만 배포하는게 아니기 때문이다.

1. 통합된 모니터링 시스템
2. Audit 시스템
3. 호스트 레벨 방화벽
4. EC2를 제어하기 위한 API
5. 볼륨 백업/복구 서비스
6. 네트워크 서비스
7. EC2 자원에 대한 Role 기반 접근제어 서비스

기타 숨어 있는 많은 기능들을 가지고 있기 때문이다.

클라우드에서 비용을 산정하기 위해서는 아래의 것들을 고려해야 한다.

- 코어 수와 메모리 크기로 EC2의 용량을 산정 할 수 있는가 ?
    - 서버의 실제 리소스 사용량. :
    - 24시간 항상 운영되어야 하는가 : 배치작업은 특정 시간에만 사용 될 것이다.
    - 꼭 서버를 사용해야 하는가 : 어떤 작업은 serverless로 가능 할 것이다.
    - 스케일 업/다운, 스케일 인/아웃이 자유로운가 : 서버 사용량이 줄어든다면 ? 마케팅등으로 서버 사용량이 늘어난다면 ?
- SAN/NAS vs S3/EBS
    - 온프레미스라면 항상 여분의 스토리지를 보유하고 있어야 할 것이다. AWS는 사용한 만큼만 과금한다.
    - 백업 공간과 백업 소프트웨어는 ? AWS의 S3는 무한정의 백업공간을 제공하며, AWS의 서비스들은 이 백업공간에 백업을 할 수 있다. 백업 소프트웨어가 기본으로 제공된다고 보면 된다.
    - AWS 에서는 백업을 하기 위한 서버가 필요 없다.
    - AWS에서는 데이터의 저장과 컴퓨팅을 분리 할 수 있다.
- 관리 비용
    - AWS의 운영체제, 완전 관리형 서비스들을 이용해서 관리비용을 크게 줄일 수 있다.

**용량산정**방식에도 차이가 있다. 워크로드에 따라서 차이가 있겠으나 일반적으로 온프레미스에서 용량은 **연피크**를 고려해서 산정한다. 반면 클라우드는 요청이 늘어날 때 스케일 업/아웃 해서 대응하고, 요청이 줄어들면 스케일 다운/인을 한다.

![클라우드에서의 사이징](https://docs.google.com/drawings/d/e/2PACX-1vRxPia_tHkgiP98GLe6EXPXvaQxfPcPdLjzBe2zBogXQI8PrzRbGzRkkxHVhQyYiJVrnl_U2vJgfuTY/pub?w=973&h=381)

## DR 아키텍처
AWS 인프라는 Region과 가용 영역으로 구성된다. Region은 각 지역을 나타내는 논리적인 단위이다. 실제 물리적인 단위 즉 IDC에 해당하는 것이 **가용 영역(availability zone)**이다. 각 Region은 최소한 최소한 2개의 가용 영역으로 구성이 된다. 아래 그림은 가용 영역으로 구성된 리전(region)을 묘사하고 있다.

![가용영역](https://docs.google.com/drawings/d/e/2PACX-1vSL-euuJhE7baFy-WdKbbMXNyEW5EdyXEPitQhOP3v38xDldjpinQxOzRNn230G1qtaq7kH4uivpbkD/pub?w=812&h=602)

이들 가용 영역은 짧은 지연을 가지는 네트워크로 연결이 되며, 관리자는 이들 가용영역을 묶어서 가상 네트워크를 구성 할 수 있다. 이러한 가용 영역 특성을 이용해서 DR(재해 복구) 시스템을 구축 할 수 있다.

![availability zone을 이용한 DR 구성](https://docs.google.com/drawings/d/e/2PACX-1vR4RzYGqUX-NX1GkVoXCdItBLoOWBb-fZaURfymCmiMPkIZG-fRsOvcCUd7CYsGawsCyKvePcU7MaCf/pub?w=679&h=538)

서버 자원들을 서로 다른 가용 영역에 두고 로드 밸런서를 이용해서 서비스를 할 수 있다. 가용 영역은 물리적으로 분리된 IDC 이기 때문에 IDC 하나가 서비스 불능 상태가 되더라도 다른 가용 영역을 이용해서 서비스를 수행 할 수 있다. 위 그림에서는 로드밸런서(Elastic Load Balancer)가 하나인 것 처럼 나왔는데, 실제로는 가용 영역에 분산되서 배치된다.

## 클라우드 비용 최적화 과정
클라우드 도입 비용은 처음에는 **TCO 관점**에서 접근 한다. 하지만 지금까지 설명했듯이, AWS의 자원은 탄력적이고 어떻게 이용하느냐에 따라서 자원을 절약 할 수 있다. 처음에는 모니터링 결과를 보고 인스턴스의 사양을 낮추거(Scale Down)나 갯수를 줄이는(Scale In) 작업을 할 것이다. 이후 워크로드와 모니터링 결과를 분석해서 예약 인스턴스 사용, 스토리지 최적화, 스팟 인스턴스 도입, 서버리스 아키텍처 적용 등의 활동을 통해서 점진적으로 인프라를 개선하면서 비용 최적화를 달성하게 된다.

![클라우드 비용 최적화 과정](https://docs.google.com/drawings/d/e/2PACX-1vROQM-fsF2ub5HK9zXC6xKnzRVK-Z38rUX7OAPrf-YQ9GfTbMx0QXmav1Orcjk2y-xsXvsfZpDrIcjD/pub?w=779&h=345)

이런 **활동**은 한번에 이루어지지 않는다. 최소 6개월에서 1년에 걸쳐서 단계적으로 수행되며 결과적으로 50% 이상의 비용 절감 효과를 얻게 된다.

## AWS의 보안 기능
### Virtual Private Cloud
AWS는 VPC(Virtual Private Cloud) 서비스를 제공한다. 이 서비스를 이용해서 사용자는 Account 단위 그리고 서비스 단위로 인터넷으로 부터 그리고 다른 조직으로 부터 격리된 네트워크를 만들 수 있다. 퍼블릭한 공간에 사설 네트워크를 구성할 수 있는 기능이라고 보면 된다.

사용자는 API 호출로 즉시 16비트 크기의 VPC를 만들 수 있으며, 이 VPC를 적절하게 서브넷팅해서 EC2 인스턴스와 데이터베이스 등을 배치 할 수 있다. AWS VPC는 라우터와 Security Group과 Network ACL 등을 이용해서 서브넷을 보호 할 수 있다.

- Security Group : 인스턴스 단위로 적용되는 방화벽이다. 리눅스에서 사용하는 iptables와 유사한 효과를 가진다. Port/IP에 대한 접속 허용/차단을 제어 할 수 있다. 자원단위로도 컨트롤 할 수 있는데, 예를 들어 로드밸런서의 특정 포트, 특정 인스턴스 그룹으로 부터의 특정 포트등으로 제어 할 수 있다.
- Network ACL : Security Group이 호스트 단위 방화벽이라면 Network ACL은 서브넷 단위의 방화벽이다. 인바운드/아웃바운드 트래픽을 허용 혹은 차단 할 수 있다.

아래는 일반적으로 사용하는 VPC 네트워크 아키텍처를 묘사하고 있다.
![VPC 네트워크의 묘사](https://docs.google.com/drawings/d/e/2PACX-1vTvcVnpMuphRvWda5FSgTVO8m4HQvvPfN-AD-y-8LemyQL70EekFpwZ13wTsrEWxygmUU2GEP9dL-NG/pub?w=995&h=718)

- 3 x 2(가용영역) = 6개의 서브넷을 만들었다.
- 앞단의 서버에는 로드밸런서를 배치했다. 로드밸런서가 배치된 서브넷은 "0.0.0.0/0"로 향하는 트래픽을 인터넷게이트웨이(IGW)로 향하게 했다. 따라서 인터넷에서는 로드밸런서에 접근 할 수 있다. 나머지 서브넷들의 라우팅 테이블에는 IGW 레코드가 없기 때문에 인터넷에서 접근 할 수가 없다.
- 데이터베이스는 Security Group을 이용 EC2 IP에서 3306포트로만 접근을 허용하고 있다.
- EC2 인스턴스는 ELB에서 80포트로만 접근을 허용하고 있다.

운영체제 레벨에서 iptables등을 이용해서 복잡하게 설정할 필요 없이, API만을 이용해서 간단하게 기본적인 보안 설정을 할 수 있다.

### Amazon GuardDuty
Amazon GuardDuty는 AWS 계정과 워크로드를 보호하기 위해 악의적 활동 또는 무단 동작을 지속적으로 모니터링하는 위협 탐지 서비스다. GuardDuty는 AWS 계정에서 발생하는 **CloudTrail**, Amazon VPC Flow Logs(네트워크 트래픽 데이터), DNS 로그(name query 패턴)에서 수십억건의 이벤트를 분석한다. 분석결과 계정 침해, 인스턴스 침해 및 악의적 정찰과 관련있는 활동을 식별해서 침해사고에 대응할 수 있게 한다.

![GuardDuty](https://docs.google.com/drawings/d/e/2PACX-1vRoyjAVk0_9zeWS8iilBR21SXyiFFg-5Y7RQFfxcyI2kop5V4diiIPSOmJBfE8vbcDDygPsX7kSu_PC/pub?w=1130&h=456)

툴이 제공된다고 하더라도 24시간 모니터링/관제를 위한 조직을 갖추는 건 쉬운일이 아니다. 관제 서비스를 제공하는 AWS Partner 를 찾아보는 것도 도움이 될 것이다.

### AWS WAF
AWS WAF(Web Application Firewall)은 AWS에서 제공하는 **웹 애플리케이션 방화벽**서비스다. Amazone CloudFront, Application Load balancer, Amazon API Gateway 등 HTTP/HTTPS 기반의 클라이언트 접점에서SQL Injection, Cross-Sit Scripting(XSS) 과 같은 웹 공격을 탐지하고 차단한다. WAF는 신속한 룰(Rule)의 관리가 중요한데 [마켓플레이스](https://aws.amazon.com/marketplace/solutions/security/waf-managed-rules)에서 서비스 목적에 맞는 3rd-party 관리형 룰 서비스를 사용 할 수 있다.

![AWS WAF](https://docs.google.com/drawings/d/e/2PACX-1vTM8eV5izr2vvqejcnWOoBwtcgCwqYrwC9v7vTmY0ZcCKtqgpA-NM6m3PVzZTRiqpxU_t-Yy2e24ozY/pub?w=688&h=309)

### AWS 보안 기능 정리
- 인프라 보안 : AWS VPC, AWS WAF, 모든 서비스에 TLS 적용
- DDos 대응 : Amazon CloudFront, Amazon Route 53
- Data 암호화 : Object Storage/Block Storage/File Storage/Database/Redshift 암호화, [KMS](https://www.joinc.co.kr/w/man/12/aws/kms)(AWS Key Management Service), CloudHSM, 메시지 큐 암호화
- 인벤토리 및 구성관리 : Amazon Inspector(애플리케이션 취약점 점검, 손상된 OS/스토리지 점검)
- 모니터링 & 로깅 : AWS CloudTrail, Amazon CloudWatch Logs/Events/Alarm , ELK 연계
- 계정 관리 및 접근 제어: [IAM](https://www.joinc.co.kr/w/taglist?name=IAM)(AWS Identity and Access Management), AWS Fulti-factor Authentication, AWS Directory Service

### 클라우드 환경의 보안을 믿을 수 있을까 ?
> I see the big cloud providers in the same way I see a bank," he says. "They have the incentive, they have skills and abilities, and they have the motivation to do a much better job of security than any one company or any one organization can probably do.[...] I think today the better bet is get to the cloud as quick as you can because you're guaranteed almost to have better security there than you will in any private thing you can do,  
>   
> 대형 클라우드 제공업체들은 은행과 비슷합니다. 그들은 그것을 할 수 있는 의욕과 기술, 능력을 가지고 있습니다. 또한 다른 어떤 회사나 조직보다도 더 나은 보안을 제공하여야만 하는 동기도 가지고 있습니다.[...] 스스로 할 수 있는 어떤 보안보다 강력한 보안을 제공하기 때문에 할 수 있는 한 빠르게 클라우드로 이전하는 것이 좋다고 생각합니다.  
>   
> 토니 스캇, USA CIO - CIO 매거진 - https://www.cio.com/article/2996268/us-cio-tells-it-leaders-to-trust-the-cloud.html

은행에 돈을 맡길 때, "내가 관리하는게 아니니 보안에 더 취약할거야"라고 생각하는 사람은 없을 것이다. 은행은 고객의 자산을 안전하게 보장하기 위한 기술에 집중적으로 투자해서 충분한 안전성을 확보해야 한다. 이 것은 기업 생존의 문제이기 때문에 대충 대충 할 수 있는게 아니다. 정부의 규제 또한 매우 강력하며, 최고의 보안 전문가들로 그들의 시스템을 관리한다.

퍼블릭 클라우드도 마찬가지다 "IDC에 직접 관리하는게 아니니 보안에 더 취약할거야"라고 생각 할 수 있지만 그렇지 않다. 생각 할 수 있는 다양한 고객, 워크로드, 고객의 자산(데이터)를 저장하고 처리해야 한다. 퍼블릭 클라우드 서비스 제공자 입장에서 보안과 가용성은 기업 생존의 문제다. 강력한 정부의 규제를 만족해야 하며, 최고의 보안 전문가들이 의욕을 가지고 시스템을 개발하고 있다.

## 참고
-   [Why Cloud Computing is the Future of Enterprise Application Platform](https://blog.westagilelabs.com/cloud-computing-is-the-future-of-enterprise-application-platform/)
-   [Public Cloud Soaring To By 2022 According To Gartner](https://www.forbes.com/sites/louiscolumbus/2019/04/07/public-cloud-soaring-to-331b-by-2022-according-to-gartner/#5ea33beb5739)
-   [Cloud spending trends predict the world's future digital leader and laggards](https://siliconangle.com/2019/08/25/cloud-spending-trends-predict-worlds-future-digital-leaders-laggards/)
-   [클라우드 전략이 따로 필요 없는 이유](http://www.itworld.co.kr/print/61947)

Search For:

BY TAGS

Recent Posts

Archive Posts

Tags

About

Get in Touch

Categories