Nirsa

• IBM 클라우드 오브젝트 스토리지의 특징

1. 파일 시스템이 아님 (디렉토리 구조가 없음)
2. 블록 스토리지가 아님 (디스크처럼 보이지 않음)
3. 데이터가 BUCKETS에 저장됨
4. 데이터는 메타 데이터 및 고유 식별자와 함께 객체로 저장

• IBM 클라우드 오브젝트 스토리지를 사용하는 이유

1. 효과적으로 무제한 저장 (쉽게 확장 또는 축소가 가능)
2. 대량의 비정형 데이터 저장 및 검색
3. 대용량 데이터 세트, 백업 및 아카이브 파일 등에 자주 사용
4. 성능이 저하되는 경향이 있으므로 자주 액세스하는 데이터/고성능 액세스에 적합하지 않음

• IBM 클라우드 오브젝트 스토리지 계층 (ibm cloud object storage archive tier)

위와 같은 이유들로 인해 여러가지의 스토리지 계층이 존재하고, 어떤게 가장 나의 환경에 잘 맞는지 파악해야 합니다.

데이터 보호를 요구하는 복구 옵션이 필요한지, 클라우드 안팎으로 빠르게 데이터 이동이 필요한지, IBM SQL Query를 사용한 데이터 쿼리가 필요한지 등이 대표적인 예입니다.

IBM 클라우드의 오브젝트 스토리지 계층은 Standard, Vault, Cold Vault, Flex 총 4가지로 구분이 됩니다.

스토리지 계층의 핵심은 액세스가 얼마나 자주 발생하는지에 따라 나눠집니다.  아래는 좀 더 보기 쉽게 IBM Cloud에서 테이블 형태로 제공해주는 내용 입니다.

또한 오브젝트 스토리지에 대해 3가지의 복원성 옵션을 제공 하는데 교차 지역(Cross-Region), 지역(Regional), 단일 데이터 센터(Single Datacenter)가 있습니다. 3가지의 복원성 옵션을 쉽게 보자면 아래와 같습니다.

1. 교차 지역(Cross-Region) : 근처 국가의 최대 3개 지역에 저장됩니다. (AP Cross-Region의 경우 Hongkong - Tokyo - Seoul)
2. 지역(Regional) : Regional 내의 여러 데이터 센터 시설에 저장 됩니다. (아시아의 경우 Regional JP-TOK)
3. 단일 데이터 센터(Single Datacenter) : 하나의 데이터 센터 내의 여러 디바이스에 저장 됩니다.

• IBM Cloud 대시보드에서 상단의 카탈로그를 클릭 해주세요.

• Cloud Foundry를 검색 후 클릭 합니다.

• 공용 애플리케이션을 클릭 해주세요.

• 지역과 플랜을 선택 합니다. Lite 계정이므로 최대 256MB의 메모리를 사용할 수 있습니다.

• 런타임에서 본인이 사용할 언어를 선택 해주세요. Lite 계정에서는 JAVA, Node.js, ASP.NET, GO 등의 언어를 지원하고 있습니다.

• 우측을 보면 아래 이미지와 같은 화면이 보입니다. 작성을 클릭해서 생성해주세요.

• 아래와 같은 매뉴얼 창으로 넘어가며 생성이 완료 됩니다. 좌측 상단의 Starting이 Running으로 변경되면 생성이 완료된 것 입니다.

• IBM 클라우드의 가상 서버 유형과 베어메탈 서버 (Public, Dedicated, Transient, Reserved)

IBM 클라우드의 가상 서버 유형에는 약 4가지의 다양한 유형의 가상 서버를 제공 하는데, 가상 서버들의 유형을 알아보기 전에 IBM Cloud의 가상서버에는 아래와 같은 공통점들이 있습니다.

전 세계에서 사용 가능, 최대 64개의 vCPUs / 512GB RAM 사용 가능, Public 그리고 Private에서 최대 1Gbps의 네트워크 성능과 최대 5개의 SAN 볼륨을 사용할 수 있습니다. (SAN 볼륨은 하나의 boot 디스크와 4개의 마운트된 볼륨으로 구성됨)

 - 전 세계에서 사용 가능 (45 + DC)
 - 최대 64 개의 v CPU / 514GB RAM
 - 퍼블릭 및 프라이빗에서 1Gbps의 네트워크 성능
 - 최대 5 개의 SAN 볼륨 (또는 전용 VS의 5 개의 로컬 디스크)

• 1) Public Virtual Server

Public Virtual Server는 멀티 테넌트(multi-tenant)로 배치 됩니다. 멀티 테넌트란, 하나의 물리 서버에 여러개의 기업을이 공존하며 리소스와 스토리지 등을 공유하여 사용중인 환경이라고 볼 수 있습니다.

 - 공유 (다중 테넌트) 하드웨어에 상주하는 가상 서버
 - 확연히 확장 가능
 - 시간별 또는 월별 청구

• 2) Dedicated Virtual Server

Dedicated Virtual Server는 싱글 테넌트(single-tenant)로 배치 됩니다. 하나의 기업이 전용 물리서버에 배치받아 사용하게 되어 어떠한 규정, 보안, 프로비저닝시 성능 등의 이점을 가져갈 수 있습니다.

또한 원하는 데이터센터를 찾고, 복원력을 위해 각기 다른 전원 공급 장치를 사용할 수 있으며 모든 호스트에는 56개의 CPU 코어가 있습니다. 

아무래도 Public의 경우 결국 하나의 물리서버 안에 여러개의 기업이 사용중이기 때문에 보안상으로 보나, 성능상으로 보나 Dedicated보다 밀릴 수 밖에 없습니다.

* IBM Cloud Essentials 코스에서는 Dedicated Virtual Server라고 칭하여 제작했지만, 개인적으로는 Dedicated Virtual Server 보다는 Dedicated Host가 의미상 더 맞지 않을까 싶습니다.

 - 가상 서버가 전용 (단일 테넌트) 하드웨어에 상주
 - 규정 준수, 보안, 성능
 - 호스트 프로비저닝 후 호스트의 VM
 - 월별 또는 월별 결제

• 3) Transient Virtual Server

Transient Virtual Server는 IBM Cloud Data Center의 예비 용량을 사용하게 됩니다. IBM에서 용량이 필요로 한다면 프로비저닝이 해제되기 때문에 항상 실행되어야 하거나 어떠한 서비스를 제공중인 환경에서는 사실상 사용하기 힘들어 보입니다. (즉, 언제든 사라질 수 있는 임시 가상 서버라고 생각하셔도 무방 합니다.)

대신 저렴한 비용으로 사용이 가능하며, 예비 용량을 사용하게 되므로 시간당으로 비용이 청구 됩니다.

 - 공유 (다중 테넌트) 하드웨어에 상주하는 가상 서버
 - 표준 공공 VS 비용의 비율
 - 시간당 청구
 - 클라우드 데이터 센터에서 '예비'용량 사용
 - 용량이 필요할 때 자동으로 프로비저닝 해제
 - 유연한 워크로드에 적합

• 4) Reserved Virtual Server

Reserved Virtual Server는 장기간 서비스 예약을 통해 저렴한 비용으로 사용하기 위한 서비스 입니다. 1년 또는 3년 동안 예약이 가능하며 그만큼 할인을 받아 더 저렴한 가격으로 사용할 수 있기 때문에 오래동안 IBM Cloud를 사용할 때 이점을 발휘할 수 있습니다.

 - 공유 (다중 테넌트) 하드웨어에 상주하는 가상 서버
 - 1년 또는 3년 동안 예약 가능
 - 오래 지속되는 워크로드에 적합
 - 약정으로 인한 큰 할인
 - 시간별 또는 월별 청구

• 5) Bare Metal Server

베어 메탈 서버는 쉽게 설명하자면 VM이 아닌 물리 서버가 그대로 할당되는 개념의 서비스 입니다. DB 등과 같이 보안상 데이터를 공유하는 환경에서 사용하기가 꺼려지거나, 좀 더 물리서버의 성능을 완벽히 사용하고 싶을 때 베어 메탈 서비스를 이용할 수 있습니다.

Dedicated Virtual Server와 굉장히 비슷한 개념이지만 완벽히 같은 의미를 지니고 있지는 않습니다. Dedicated와 Bare Metal의 가장 큰 차이점은 공급자(클라우드 업체)에서 제공하는 방식 입니다.

Bare Metal의 경우 시간별로 청구 모델이 제공되어 몇시간 또는 며칠 동안만 Bare Metal 특유의 보안과 성능을 이용한 작업을 처리하고 종료할 수 있습니다.

IBM Cloud 에서는 Dedicated와 Bare Metal의 차이점을 아래와 같이 정의 하였습니다.

사실 Dedicated와 Bare Metal의 차이점은 좀 추상적인 면이 없잖아 있기 때문에 성능에 따라서도 부르는 용어가 달라지기도 하는걸로 보입니다.

• 간단히 보는 클라우드 네이티브(Cloud Native) 란?

RedHat과 CNCF(Cloud Native Computing Foundation)는 클라우드 네이티브에 대해 아래와 같이 정의 했습니다.

• "클라우드 네이티브" 애플리케이션은 프라이빗, 퍼블릭 및 하이브리드 클라우드 환경 전체에 지속적인 개발과 자동화된 관리 환경을 제공하기 위해 특별히 설계된 애플리케이션을 뜻합니다. - RedHat
• 클라우드 네이티브 기술을 사용하는 조직은 현대적인 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같이 동적인 환경에서 확장성 있는 애플리케이션을 만들고 운영할 수 있다. 컨테이너, 서비스 메시, 마이크로서비스, 불변의 인프라스트럭처, 그리고 선언적 API가 전형적인 접근 방식에 해당한다. 
  
  이 기술은 회복성이 있고, 관리 편의성을 제공하며, 가시성을 갖는 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화와 함께 사용하면, 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 
  
  Cloud Native Computing Foundation은 벤더 중립적인 오픈소스 프로젝트 생태계를 육성하고 유지함으로써 해당 패러다임 채택을 촉진한다. 우리 재단은 최신 기술 수준의 패턴을 대중화하여 이런 혁신을 누구나 접근 가능하도록 한다. - CNCF(Cloud Native Computing Foundation)

클라우드 네이티브에 대해 검색하면 전형적인 문서 형식의 글이 많고 클라우드 네이티브에 대한 설명이 조금씩 차이가 있는데, 공통적인 부분은 Container + CI/CD + DevOps + Micro Service 이렇게 4가지가 있으며 이러한 환경들을 잘 융합하여 구성한것을 클라우드 네이티브라고 볼 수 있습니다.

간단히 4가지의 기술들을 소개하겠습니다.

• Container & Container Orchestration

하이퍼 바이저 기반의 가상화 기술보다 훨씬 경량화된(오버헤드가 적은) 기술 이며 정확히는 가상화가 아닌 프로세스를 격리 시키는 기술 입니다. 코드로 관리되다 보니 이미지의 이력 관리에 유리하며, 일관된 개발 환경, 가상화 기술에 비해 가볍고 빠르다는 장점 등이 있습니다. 

또한 Kubernetes와 같은 Container Orchestration Tool을 도입하여 중앙화 관리, 자동화된 장애 대응(self-healing), 리소스에 따른 scale in/out, 무중단 배포 등 굉장히 많은 이점을 제공 받을 수 있습니다.

• CI/CD

CI/CD는 지속적인 통합, 지속적인 서비스 제공, 지속적인 배포를 뜻 합니다. jenkins와 같은 툴을 사용해 CI/CD 파이프라인을 구축해 개발 단계를 자동화하고 애플리케이션의 통합, 테스트 단계, 제공 및 배포에 이르는 모든 라이프 사이클 전체에 걸쳐서 지속적인 모니터링과 자동화를 제공 합니다.

일명 통합 지옥(integration hell)이라 불리는 팀 구성원들이 각자의 코드를 통합할 때 발생하는 문제를 해결하기 위한 솔루션으로써 대표적인 툴은 jenkins가 있습니다. 일반적으로 이러한 환경을 CI/CD pipeline 이라고 부릅니다.

• DevOps

DevOps는 개발(Dev)과 운영팀(Ops)의 중간 포지션에서 두 팀을 잘 융합시키고 의사소통을 이끌어내는 문화로 시작 하였지만 우리나라에 넘어오면서 그런 문화보다는 특정 직책의 성향이 많이 강해졌습니다.

회사마다 조금씩 다르지만 현재 우리나라에서의 DevOps는 개발팀과 운영팀을 융합 시킨다기보다는 인프라 자동화 + Cloud + Container + CI/CD Pipeline 또는 백엔드 개발 + Cloud + Contaier + CI/CD Pipeline의 업무를 맡아 진행하는 직책으로 거의 굳어진 상태 입니다.

클라우드 네이티브에서 말하는 DevOps는 우리나라에 넘어오기 전의 조직/문화의 개념으로써 표현 됩니다.

• Micro Service

마이크로 서비스는 보통 MSA(Micro Service Architecture) 라고도 불립니다.

마이크로 서비스의 반대되는 개념인 모놀리틱 아키텍처(Monolithic Architecture)가 있는데 모든 코드가 하나로 묶여있어 서비스의 복잡도가 증가할수록 아주 작은 기능 하나를 추가하기 위해 여러개의 코드를 수정하고 여러개의 코드를 수정함으로써 영향을 미치는 범위가 증가하여 테스트 및 검증하기 위한 시간과 인력이 많이 소비됨은 물론 배포 시간의 증가, 안전성 감소 등의 문제가 있었습니다.

이러한 문제를 해결하기 위해 나온 방법론이 마이크로 서비스 아키텍처(MSA) 입니다. 독립적인 역할을 수행하는 서비스를 작은 단위로 분리하여 설계함으로써 규모가 커지고 복잡도가 높아질수록 많은 이점을 갖습니다.

독립적이므로 서비스의 코드 수정에 따른 영향 범위가 적으며, 특정 서비스별로 독립적인 배포가 가능한것이 가장 큰 특징 입니다. 또한 특정 서비스에서 많은 양의 리소스를 필요로 하거나, 특정 서비스에서는 아주 적은양의 리소스가 필요하다면 각각의 환경에 맞게 리소스를 할당하여 사용할 수 있기에 서버의 리소스를 효율적으로 사용할 수 있게 됩니다.