아마존 클라우드 AWS Essential 4강 클라우드 모범사례 > AWS 클라우드

 

이번 차 시에서는 클라우드 컴퓨팅의 모범 사례에 대해서 이해 하실 수
있습니다.
첫번째로 클라우드 컴퓨팅의 모범 사례 중에서
장애를 고려한 디자인 그 다음에 컴포넌트의 속여 락 그 다음에 탄력성
그리고 통 식성을 가진 서비스의 고용과 특히 중요한 보안을 고려한 구성
방안에 대해서 이해 하실 수 있습니다.
4 첫장 장애를 고려한 디자인 클라우드 환경에서는 설계를 할 때 특히
장애가 발생 한다.는 가정하에 보수적으로 설계를 진행 하셔야 되고
장애로 부터 자동으로 국구 하고 보검 가능한 시스템으로 디자인 하셔야
됩니다.
특히 클라우드 환경에서는 다양한 라이트 환경들 예를 들면 은 서버나
스토리지 나 네트워크 같은 다양한 it 컴포넌트 들이 존재를 하기 때문에
이 하나의 장애가 발생했을 때 저희가 구성한 어플리케이션 혹은 웹사이트의
서비스 장애로 즉결 되지 않아야 합니다.
그게 흥행이 저희가 말하는 장애 요소들
하드웨어가 장애 발생 하더라도 어플리케이션이나 서비스 레벨에서 장애로
직결된 지 않도록 단일 부분에 장애 요소들
spoof 라고 하는데요 싱글 포인터 펜 려 그래서 단일 장애 요소
시스템이 단일 구성 요소가 장애가 나더라도 전체 시스템에는 영향을 주지
않아야 된다 라는 딸입니다. 그래서 항상 클라우드 컴퓨팅 혹은 전통적인
it 인프라 환경에서도 esp of 를 제거해 주는게 가장 중요한
일이구요 esp off 가 제거가 됐을 때 탄력성이 라던가
그 다음에 확장성
를 보장할 수 있게 됩니다. 이렇게 장애를 고려한 디자인에 대해서 aws
에서는 어떠한 식으로 제공을 서비스를 제공하는지 알아보도록 하겠습니다.
우선 전통적으로 서비스의 이중 아 사례 가 spoof 를 제거한 서비스
이종하 사례에 대해서 먼저 말씀 드리도록 하겠습니다.
첫번째로 뭐 하나의 서버가
있다 라고 가정했을 때 뒤 땅에 예를 들면 은 데이터베이스
아 있을거구요 네 이게 데이터베이스가 만약에 1개만 있을 따고 가정하에
이게 첫번째 데이터베이스 두번째 데이트 페이스
흔히 이제 마스터 라고 불리우는데 여튼 이렇게 하나의 웹 서버에서 tv
모 두 번째는 좀있다 설명을 드리겠습니다. 그래서 한쪽만 만약에 이 이쪽
라인이 아직은 없다 라고 가정하고 요
이쪽 라인만 통신을 하고 있었다 라고 가정했을 때 만약에 이쪽에 네트워크
장애가 발생했을 때
전체적인 시스템에 영향을 줄 수 밖에 없습니다.
이 하나의 웹 서버에 여기에 들어있던 데이터베이스의 정보를 가져와야 되는
고객 정보
음 키타 제 d 데이터베이스에 있는 데이터들을 가지고 올 수 없어서
전체적인 서비스의 장애가 발생하게 되는데요
그래서 천통 적인 방식에서도 동일하구요 이거에 대해서 저희가 프라이머리와
보통 세컨더리 혹은 마스터 또는 슬레이브 그 다음에 뭐 라이브 서버 그
다음에 때 겁 이런식으로 전래 이중화 구성을 합니다.
그래서 이쪽 라인에서 장애가 발생 을 하더라도 이쪽에서 서비스를
지속적으로 가능하게끔 서비스 이중화 구성을 하셔야 되고요
이게 sp of 를 제거했다 라고 하는 디자인이라고 볼 수 있습니다.
4 장애를 고려한 디자인의 대표적인 정책 요소들에 대해서 알아보도록
하겠습니다.
첫번째 일관성 있는 백업과 복구 정책 그리고 자동 아 에 부분입니다.
특히 클라우드 환경 뿐만이 아니고 기본적인 idc 환경 온 프라미스
환경에서도 백업과 복구 정책이 영악하게 있어야 되구요.
이 정책들을 자동으로 설정을 할 수 있게끔 다양한 백업과 복구 정책들이
간소화 되어 있고 프로세스와 돼 있어야 됩니다.
하나의 서비스가 장애가 발생했을 때 다른 서비스를 이 서비스로 대처를
한다. 라고 했을 때 그것에 해당하는 백업서버 라던가 혹은 복구를 할수
있는 정책들이 존재 하셔야 되고요
그런 족 정책들 기반 위에 자동화된 스크립트 프로그래밍 을 통해서
여러분들이 서비스를 장애를 회피할 수 있는 기능들을 고려 하셔야 됩니다.
이게 첫 번째로 대표적인 정책 이라고 말씀드릴 수 있습니다.
두번째 제기동 이후에 진행되는 프로세스의 적립
실제로 제기동 서버가 장애가 발생해 서 리 스타트 가 된다 라고 가정했을
때 이후에 올라오는 프로세스들이 나 혹은 소프트웨어 혹은 설정 같은
것들이 적립이 안 돼 있다 라고 했을 때는
서버에 장애가 서비스의 장애로 직결될 수 가 있습니다.
서버 가 제기동 2 됐을 때 서비스의 2b 됐는데 실제로 설정 값이
라던가 혹은 뭐 데이터들이 최신버전으로 맞춰져 있지 않다 라고 했을 때는
서비스의 인프라에 장 의 이우 이외에 서비스의 장애 서비스의 이상한
현상이 발생이 될 수가 있구요.
이런 것들을 프로세스 상으로 적립을 해 놓으셔야 됩니다.
세번째
데이터를 리로드 하거나 다시 동계 할 수 있는 상태의 허용 이라고
말씀드릴 수 있습니다.
실제로 웹서버 라던가 와 스 서버가 제기동 2 됐을 때 혹은 프로세스가
리로드 됐을 때
중앙에서 공유하고 있는 데이터들 혹은 어떤 메세지 들에 대해서 가져올 수
있게끔 상태가 오용 돼 있어야 됩니다.
앞에서 말씀드렸던 것처럼 하나의 서버에 데이터를 혹은 유저 세션 같은
것들을 공유 하지 않아야 된 구요
이거에 대해서 중앙에 있는 데이터베이스 라던가 혹은 q 를 통해서
메시지를 통신을 하게 되는데 이런 것들을 다시 제기동 2 됐을 때
데이터들을 리로드 하고 다시 동계 할 수 있는 상태로 서버 들을 설정해
놓으셔야 됩니다.
세번째 이미지의 표준화된 사전 설정 및 최적화 정책 관리 부분입니다.
실제로 서버가 제기동 2 됐다 혹은 이 서버가 문제가 생겨서 다른 서버
로 대처 해야 된다 라고 했을 때 그 위에 올라오는 기본적인 os 위에
올라오는 설정값 뜰 그 다음에 프로세스의 설치 혹은 어떤 구성에 대한
자동 와 같은 것들이 구성이 돼 있어야지 동일한 상태로 표준화된 구성을
가지고 서버 그리고 서비스 올라올 수가 있구요.
이런거 역시 최신 혹은 최적화 정책으로 관리 하셔야 됩니다.
뭐 다양한 툴을 통해서 5 최신 의 버전을 체크를 하고 이런 것들을
올라왔을 때 제대로 동작하는지 확인하는 툴들이 있구요.
이런 것들이 고려가 되야지 대표적으로 장애를 고려한 디자인 이라고
말씀드릴 수 있습니다.
2 메모리 세션이 나 유저정보 상태를 저장하는 방식을 지향 하셔야 됩니다.
위에서 말씀드렸던 것처럼 데이터를 리로드 하고 다시 동기 할 수 있어야
되는데 만약에 하나의 서버에 서버 안에 메모리에 세션을 들고 있다거나
혹은 유저정보 상태를 하나의 서버 안에 데이터 안에 저장하고 있다 라고
했을 때는 그 서버에 장애가 났을 때 전체적인 서비스의 영향을 줄 수가
있습니다.
한쪽에서 가지고 있는 자기만의 독립적인 데이터가 있다 라고 했을 때는
유저들 혹은 서비스 이 서비스가 장애가 났을 때 이 정책 의 설정 값에
대해 혹은 이 세션의 대해서는 다른 서버 들이 알지 못하기 때문에 이
고객 입장에서는 서비스의 품질의 저하 낸 요소로 받아들일 수가 있습니다.
그래서 인메모리 세션이 나 유저정보 상태를 로컬에 저장하는 게 아닌
중앙에서 공유할 수 있는 부분에 저장을 하셔야지
장애를 고려한 디자인 이라고 말씀드릴 수 있습니다.
4 컴포넌트에 대한 소개 라 에 대해서 말씀드리도록 하겠습니다.
우선 컴포넌트에 대한 소개 라베 대해서 말씀을 드리면
특히 클라우드에서 는 soa 디자인 5 집중한 아니 더 큰 확장을 위해서
시스템의 구성요소들을
보다 소개합 시킨다 에 에 정책의 설계 방식을 따라 갑니다
예를 들어서 다양한 요소들을 구성할 때 서로간의 밀 결합을 지향을 하고요
그 다음에 하나의 구성 요소의 문제가 발생 했을 때 다른 구성요소에 해당
문제와 상관없이 지속적으로 서비스 가능 해야 한다.는 개념입니다.
지속적으로 서비스가 가능 해야지 저희가 구성한 어플리케이션 혹은 웹사이트
혹은 웹페이지에서 지속적으로 서비스를 통해서 고객들에게 유연하고 그리고
정확한 데이터들을 전송을 할 수가 있구요.
이게 특히 서비스의 품질과 도 연동 칠 수도 있습니다.
그래서 더 큰 확장을 위해서 그리고 탄력적으로 시스템을 운영을 하기
위해서 시스템의 구성요소들을
아까 말씀드린대로 보다 소 결합을 시켜서 각각의 컴포넌트 별로 확장성을
가지고 갈 수 있게끔 설계를 하셔야 됩니다.
간단한 예로 말씀을 드리겠습니다. 우선 소개 아랍의 대해서
루즈 커플 더 라고 말하는데요 단계별 독립적인 방식 단계가
5 5가지 단계가 있다 라고 가정했을 때
얘네들이 독립적으로 운영을 할 수가 있게 끔 독립적으로 관리할 수 있는
하나의 방식이라고 볼 수 있구요.
밀 결합 같은 경우 타이 티 커플 더 라고 하는데요
절차 재앙 적인 방식이라고 보실 수 있습니다.
그래서 하나의 제 구성요소들이 독립적으로 움직이는 게 아니고 밀접하게
서로 간에 연관관계가 밀접하게 구성이 되어 있다 라고 보실 수 있습니다.
그래서 소개 락 같은 방식 같은 경우는
저희가 프로세스를 1 수행을 한다. 혹은 데이터베이스 저희 지금 말하는
클라우드 환경에서 웹 사이트 랑 던가 어플리케이션을 구성을 한다. 라고
했을 때 하나의 모의 웹서버와 쓰
뭐 데이터베이스 혹은 뭐 어 스토리지
뭐 이런 것들이 독립적으로 각각 구성이 되게 됩니다.
그래서 실제로 이쪽에서 만약에 장애가 발생 하더라도 이쪽에서는 왔을
쪽이나 데이터베이스 쪽에서는 이런 것들을
뭐 장애 직결될 지 않고 서로의 연동 관계가 좀 소개 라비 돼 있으니까
얘네들 구성 요소들이 영향을 크게 받지 않고요
그래서 2 맵 서버가 혹시 장애 발생 하였을 때 라도 이쪽을 새로운
웹서버로 갈아치우고
새롭게 웹서버를 연동해 쓸 때 이쪽에 대해서 구성의 연동에 필요한 부분만
설정을 해주면 은 서비스가 지속적으로 가능하다 라고 보실수가 있구요.
4 하지만 밀 결합 구조에서는 얘네들이 다 각각 즉 밀접하게 연관이 돼
있기 때문에 웹 봤음
어디라고 구성했을 때 은 애들이 특히 이제 밀 결합 같은 경우는 한쪽
서버에 보통 다같이 구성을 하는 그런 구성 방식 이라고 표현을 할 수가
있는데요
웹서버가 문제가 생겼는데 이쪽 하나의 서버에 문제가 생겼는데 그 서버에
웹 또 있고 할 수도 있고 데이터베이스 수도 있다 라고 했을 때는 실제로
인해 들이 각각 프로세스로 돌기 때문에 독립적으로 돌아가는 것처럼
보이지만 하드웨어에 문제가 생겼을 때 웹서버에 있는 특정 뭐 스토리즈 에
디스크가 홀트 않았다거나 혹은 메모리에 어떤 문제가 생겨 따거나 cpu
가 문제가 생겼을 때
와 스와 데이터베이스 역시 동일한 서버에 존재하기 때문에 얘네들 각각의
구성 콤포넌트 들이
한번에 같이 장애를 제집 장애와 집결 되게 됩니다.
그래서 이렇게 밀 결합 구조에서는 뭐 실제로 구성 하기는 좀 더 편할
수도 있지만
장애가 발생했을 때 이거에 대해서 대응을 하지 못하고 유로 확장성도 뛰어
뛰어나지 못하다는 단점이 있구요.
하지만 그래서 현재 에서는 이런 소결 합에 대한 방식으로 구성을 하고
있습니다. 그래서 여러분들이 서비스를 구성을 하실때도 현재 마크 흔히
말하는 마이크로 서비스 아키텍처 같은
각각의 컴포넌트들을 별로 구성을 1단 음행 얘네들을 api 표준화된
인터페이스 형태로 연동을 한다.는 그런 방식이 소개 락과 루즈 커플 드와
일맥상통 한다. 는 개념이라고 볼 수 있습니다.

이번 장에서는 탄력성과 동 실성 그리고 보안을 고려한 구성 방식에
대해서 알아보도록 하겠습니다.
첫번째로 탄력성과 동시성 이 있는 구성에 대해서 먼저 말씀 드리도록
하겠습니다.
탄력성이 있는 구성이란
탄력성을 사실은 구현을 하기 위해서 뭐 배포 절차를 자동화하고
구성을 간소화하는 프로세스의 구성이 필요합니다.
쉽게 얘기해서 탄력성이 있게끔 시스템을 구성하기 위해서는 서로의 os
뿐만이 아니고 소프트웨어들을 배포 절차를 자동화 시키고 요 그 다음에
각각의 설정 값들을 간소화 시키고 그리고 프로세스 상으로 이런 것들을
정책으로 잡아낼 수 있게끔 구성이 필요합니다.
그래서 탄력성이 있는 구성의 대표적인 제 이해가 사용자의 개입 없이
확장이 지 필요 하게 되구요.
이렇게 자동화 되고 그리고 구성에 대해서 간소화 돼 있을 뿐만 아니라
이런 것들이 이제 프로세스로 구성이 돼 있기 때문에 사용자의 개입
없더라도 스크립팅 이라던가 프로그래밍을 통해서 다양한 서비스 자원들을
탄력적으로 구성을 할 수 있게 됩니다.
그래서 실제로 탄력성 있는 구성을 하게 된다면 여러분들이 실 사용량 에
부합되는 자원으로 만 서비스를 운영을 할 수가 있습니다.
앞에서 말씀드렸던 것처럼 이런 전통적인 인프라스트럭처 방식에서는
낭비 요소 라던가 혹은 사용자 품질 서비스의 품질의 저하가 되는 그럼
인프라 구성이 스케일러 빌레트 에서 말씀을 드렸었는데요 탄력성이 만약에
있다면 은 실 사용량 의 부합되게 자원을 제공함으로써 여러분들은 서비스의
품질을 라던가 혹은
비용 낭비 같은거 를 줄일 수가 있습니다.
그래서 이제 마지막으로 말씀드리는게 자원의 효율성과 비용 효율성을 가져
온다 라는 게임 r 이라고 볼 수 있습니다.
그 다음에 두 번째로 동시성 이 있는 구성 사실 연못 동시성 이라고
말했을 때 뭐 이런 병렬화 라고도 똑같이 얘기를 하는데요
병렬적으로 서비스 를 구성해서
멀티쓰레드 형태로 서비스를 구성해서
예를 들어서 동일한 시점에 데이터를 저장 하면서 요청을 수행하는 작업들
하나의 서비스 가진 서비스를 형태로 제공하는 데
데이터를 저장하는 서비스 프로세스 들이 돌면서
그거에 대해서 요청을 수행하는 프로세스의 함께 돈다
멀티쓰레드 형태로 병렬적으로 서비스가 구현이 된다 라고 하는게 제동시
성이 있는 구성이 라고 말씀드릴 수 있습니다.
실제로 클라우드 환경에서는 이런 탄력적인 구성
이 가능하기 때문에 동시성 도 또한 가져올 수가 있습니다.
그래서 클라우드 에서는 작업을 병렬 하고 자동화 할 수가 있습니다.
그래서 처음에 클라우드 컴퓨팅의 개의 워 에 대해서 말씀드렸을 때 도
동시 성에 대한 부분을 말씀 드렸는데
하나의 서버에 자원이
잡을 수행을 하는데 이 하나의 컴퓨팅 자원 에서 실제로 처리할 수 있는
양이 정해져 있기 때문에 하나의 잡을 처리를 하는데 어 10시간이 걸린다
라고 봤을 때 클라우드 에서는 탄력적으로 서비스들을 늘릴 수가 있기
때문에 하나의 서버 부터
10개의 서버를 탄력적으로 들릴 수가 있습니다.
이럴 경우 똑같은 자 배양에 틀어 5 왔을 때
한씨 * 시간이 걸릴 게 10개의 서버가 돌기 때문에 현 시간이 소요된다
라고 볼 수 있습니다.
이렇게 이제 동시성 에 있는 구성을 통해서 여러분들 서비스 혹은 기능
그리고 앞으로 비즈니스 모델을 어떻게 나갈지 를 설정을 하실 수가 있구요.
5 특히 로그분석 같은 것들이 동시성 있는 구성 중에 대표 사례라고 볼
수 있습니다.
4 그래서 탄력적 구성 방법의 사례에 대해서 말씀드리도록 하겠습니다.
탄력적인 구성방법 사례에서는
실제로 서버 자원들을
인프라 구성 들 및 인프라의 대한 소프트웨어 들 혹은 뭐 프리키 전 들을
배포를 자동화 시키고 요
그러면은 이쪽에 웹서버 라도 그래프
특정 제한 3가지의 서버들을 예를 들어서 말씀드리겠습니다.
앱 서버 라던가 혹은 대체 서버 라던가 웹 서버의 역할을 수행을 할 수가
있는 it 자원들이 생성이 되구요.
그리고 또한 인프라 구성 및 자동화를 통해서 데이터베이스와 데이터베이스
역시 이렇게 두가지로 구성하는 것들을 자동화를 시킬수가 있습니다.
그리고 이 인프라 구성 만 했다 라고 해서 끝나는게 아니고 서로의 역할을
수행할 수 있게끔 그니까 이 서버에 이 서버가 웹서버로 돌지 혹은
웹서버로 돌지 혹은 배치 서버로 돌지 를 실제로 소프트웨어 적으로 홈
플러스 s 를 설치를 하고 구성을 하고 운영을 하셔야 됩니다.
인프라 구성 만 했다고 끝나는게 아니고 부트스트랩 을 통해서
부트스트랩 이라고 말씀 드리는 것은 자체의 동작이 에서 어떤 소정의
상태로 이행되도록 설정 하는 방법 이라고 보실수가 있습니다.
그래서 이런 2초 정 의 상태로 이행되도록 설정을 하기 위해서는 자동화된
소프트웨어 설치 라던가 혹은 구성에 대한 것들이 프로세스 상으로 간소화가
돼 있고 이것을 스크립팅 홈 프로그래밍을 할 수가 있으셔야 되구요.
그래서 만약에 스크립팅 그리고 프로그래밍이 되있어서 부트스트랩 핑이
가능하다 라고 했을 때는 서버 에 장원이 생성이 되고
얘네들이 os 만 설치되어 있는게 아니라 실제로
어플리케이션을 설치를 드 트래핑 으로 진행하구요
그 다음엔 얘는 배치 서버에 역할 을 수행할 수 있게끔 소프트웨어가
깔리고 요
웹 같은 경우는 이외 배에 해당하는 아파치 라던가 통해 같은게 설정이
되구요.
설치가 되구요. 그리고 데이터베이스 역시도
데이터베이스 있어 번은 데이터베이스 중에서도 마스터로 쓸 거야
혹은 이 서버는 데이터 베이스 중에서도 슬레이브 로 쓸 거야
걔네들 연동 한계 역시 자동화된 스크립팅을 통해 가지고
탄력적으로 구성을 하실수가 있습니다.
그러면은 인프라 구성 및 배포 자동화 뿐만이 아니고 부트스트랩 핑을
통해서 간단한 설정 혹은 어려운 설정까지 여러분들이 신속하게 빠르게
안전하게 간단하게 하실 수가 있구요.
이게 탄력적으로 서비스 자원들을 블로 이 하고 제거하고 하는거에 대해서
구성을 가능하게 끔 준다 라고 말할 수 있습니다.
 그 다음에 동시성 에 있는 구성에 대해서 말씀드리도록 하겠습니다.
동시성 이 있다라고 했을 때는 그 작업의 병렬적 인 구성이 가능하다 라고
말씀 드렸는데요
실제로 모 하나의 유저가
파일을 업로드를 했다 라고 가정했을때
기본적으로 서버가 1대 있었다면 은 웹 요청도 처리를 해야 되구요.
이 파일을 뭐 변환하는 다른 포맷으로 변화는 작업도 한 서버에서 진행을
해야 되고요 그리고 이거에 대한 파일도 저장을 해야 되구요.
특히 저장까지 하고 난 다음에 또 다른 프로세스를 통해서 뭐 인덱싱 이나
로그 분석을 하셔야 되구요.
그리고 이 데이터가 다른 쪽으로 복제가 필요하다 백업이 라던가 혹은 다른
리 전에 서비스를 위해서 독재를 해야 된다 라고 했을 때는 복제 까지
같이 수행을 하셔야 되구요.
이게 병렬적으로 동시적으로 일어나지 않는다면 은 하나의 파일을 업로드
했는데
이거에 대해서 수 많은 시간이 걸릴 수가 있습니다.
하지만 클라우드 환경에서는 이런 것들 서비스 자원들을 탄력적으로 만들고
스켈 어빌리티를 보장을 하기 때문에 여러 대 의 각각의 서비스 컴포넌트
별로 구성 요소를 나누고 요
웹 요청을 처리하는 서버 변환 작업을 처리하는 서버 그 다음에 인덱싱
나로 그 분석하는 서버를 분리를 시키고 요 나의 파일 저장 하는거 역시도
불이익을 시켜서 얘들이 동시 멀티 스레딩 으로 될수 있게끔 설정을 하실
수가 있습니다.
또한 이런 것들을 타지역으로 복제할 수 있게끔 o aws 든 다른 여러
클라우드 프로바이더 들이 명 것들 복제하는 기능들을 제공하고 있구요.
그래서 이렇게 작업이 병렬적으로 구성이 됐을 때 여러분들 서비스의 다양한
기능들을 구성 하실 수 있다 라고 말씀드릴 수 있습니다.
 보안을 고려한 구성에 대해서도 알아보도록 하겠습니다.
보아는 특히 매우 중요한 구성요소 구역 지켜야 될 사항이 고요
특히 클라우드 뿐만이 아니고 엠프 아미스 환경 가 저희가 모커리 가지고
있는 환경에서도 보안이 매우 중요하구요
그래서 보아는 모든 어플리케이션 계층에서
적용돼야 되는 필수적인 조건 이라고 말씀드릴 수가 있습니다.
특히 클라우드 컴퓨팅 환경에서는 멀티 태어난 c 환경이기 때문에 보안이
더욱 더 중요해지고 요
멀티 10c 라고 표현했는데 멀티 태는 씨에 대해서 말씀을 드리며 는
이렇게 클라우드 환경 뿐만이 아니고 뭐 다양한 환경에서도
하나의 자원들 을 열어 에 사용자들이 공유를 한다.
이게 이제 멀티 테너 씨의 하나의 개념이라고 보실수가 있구요.
그래서 멀티 태는 씨를 간단하게 설명을 드리면 은 특정 단위의 클라우드
같은 하나의 이 소스 풀 단 이 단위를 사용자들이
자원들 혹은 어플리케이션을 물리적인 자원들을 서로 공유하고 요
서로에 대해서 논리적으로 분리하고 접근을 제어해서 사용하는 구성 환경
이라고 말씀드릴 수 있습니다.
이런 실제로 물리적인 자원을 공유를 하기 때문에 4 톤이나 혹은
논리적으로 구성을 저희가 나누는 작업들을 클라우드 프로바이더 들이 제공해
주고 있구요.
실제로 네트워크 레벨에서 봤을 때는 v 랜 이라고 하는
것을 통해서 물리적으로 하나의 인터페이스로 통신을 하더라도
각각 테넌트 별로 사용자별로 하나의 그룹별로 v 랜을 쪼개서 논리적으로
인해 들을 서비스를 나눌 수 있게끔 구성을 할 수 있는 작업을 하게
됩니다.
이렇게 네트워크 단에서 분리된 네트워크 환경을 가져갈 수가 있고요 그
다음에 뭐 스토리지 같은 경우는 하나의 파티션 혹은 뭐 인류의 이라고
말을 하는데 뭐 lun 단위로 서비스를 제공해 줄 수가 있구요.
혹은 뭐 2위에 소프트웨어를 올려서 논리적으로 더 낫 세세하게 나눠서
고객들에게 서로의 접근을 가능하지 않도록 논리적으로 구성해서 제공할 수가
있습니다.
이렇게 어플리케이션 단에서 실제로 물리적인 환경만 공유를 하기는 하지만
서로에 대해서는 물리적으로 접근을 불가능하 더라도
저희 사용자 입장에서는 뭐 보안에 대해서 저희 환경 예를 들면 은
네트워크나 혹은 어플리케이션 단에서 저희가 추가적으로 보안에 대한
모포 한 사례 라던가 추 를 통해 가지고 저희 서비스의 보안 레벨을 도
높일 수 있도록 작업을 해주셔야 됩니다.
그래서 기본적인 보안에 대해서 모범 사례에 대해서 간단하게 말씀 드리도록
하겠습니다.
보안 모범 사례에 대해서는 무수히 많지만 기본적으로 데이터 전송에 대한
보호 데이터를 전송 을 하는 와중에 정보가 손실이 될 수도 있긴 하지만
이게 누군가에 의해서 탈 치가 당할 수도 있습니다.
그래서 데이터 전송을 위해서 어 다양한 잉크 리액션 방식이 라던가 혹은
다양한 출 들을 이용해서 데이터 전송 시에 정보를 보호 를 하셔야 되구요.
그 다음에 데이터 저장에 대한 보호 5
실제로 제가 데이터를 저장한다. 라고 했을때 물리적인 환경 자체가
공유하는 환경이기 때문에 아무리 논리적으로 분리가 돼 있다고 하더라도
보안적인 툴을 통해서 예를 들어 데이터 저장을 할 때 특정 뭐 암호화
방식을 택해서
이 공유되는 풀 안에서도 내가 내 악 나의 서비스가 아니고서는 이걸 읽을
수가 없게끔 구성을 하실 수도 있고요 그 다음에 어플리케이션의 보호 5
실제로 어플리케이션에서 다양한 서비스를 올라오게 되는데 이런 서비스들을
각각 뭐 포트 라던가 혹은 네트워크 레벨에서 얘네들을 디도스 공격
이라던가 혹은 다양한 해킹의 방지할 수 있게끔 앞단에
뭐 갚으라는 네파 2월이 라는 이런 것들을 통해서 어플리케이션 보호를
하셔야 되구요.
그 다음에 클라우드 자원에 대한 보호 실제로 여러분들이 클라우드 자원
위해서 서비스를 올리게 되는데 클라우드 자원 역시도 보호가 필요합니다.
예를 들면 여러분들이 서비스 를 생성하는 다양한 뭐 ui 에서 여러분들
서비스 를 생성할 수가 있구요. 웨이 k 라던가 cl 통해서 서비스 를
생성할 수가 있는데 이런 것들에 대한 x 스키 라던가 씨크릿 키를 통해서
보호할 수 있도록 여러분들이 추가적으로 설정을 해주셔야 됩니다.
그 다음에 다수 사용자의 혹은 권한에 대한 보호 라고 말씀드릴 수
있습니다.
하나의 서비스를 구성하는 엔지니어 혹은 개발자들이 여러 명이 될 수가
있는데 여러 명의 됐을 때 혹은 오보 하나의 컴포넌트는 외주 업체가
운영을 하고 관리하고 개발 한다.고 가정했을 때 이런 다수의 사용자가
동일한 클라우드 환경에서 존재를 하게 되는데 그 다수의 사용자들을 권한
베이스로 쪼개서 얘들을 모래 예를 들면 개발자는 서버 자원에 대해서
믿어온 이고는 엔지니어는 리드 라이트 다음에 사업 팀은 빌링 에 대한
리드 보는 이렇게 구성을 하실수가 있습니다. 그래서 그렇게 권한에 대한
보호를 잘게 쪼개서 여러분들이 앞으로 서비스를 구성을 하실 때 보다 보안
수준이 높게 끔 설계를 하셔야 됩니다.
4 지금까지 클라우드 모범 사례에 대해서 알아보았습니다.
첫번째로 장애를 고려한 디자인 클라우드 환경에서는 장애가 날 수 있다는
가정하에 보수적으로 디자인을 하셔야 되구요.
특히 자녀 로부터 자동으로 복근 아 복원이 가능하도록 시스템을 디자인
하셔야 됩니다.
그리고 처음에 말씀드렸던 것처럼 창에 요소들을 제거를 하면서 서비스 레벨
단위로 spf 를 있는지 그리고 sp sp of 가 어떻게 제거를 해야
되는지에 대해서 설계를 하셔야 됩니다.
두번째로 컴포넌트에 대한 소 결 합
서비스 높은 확장성을 위해서 하나의 구성 요소가 문제가 발생을 하였을 때
다른 구성 요소의 영향을 끼치지 않고 그 문제와 상관없이 지속적으로
서비스가 가능하도록 서비스 컴포넌트들을 각각 소개 없이 키 셔야 됩니다.
소개 라 블 치킨 이후에 탄력성과 확장성을 보장받을 실수가 있습니다.
세번째 탄력성과 동시성 보안을 고려한 구성
특히 클라우드 환경에서는 탄력적이고 동시성을 가져올 수 있는 it 인프라
환경이기 때문에 이런 것들을 충분히 클라우드 n 이점을 충분히 여러분들
서비스의
도입 하셔서 서비스 역시도 탄력적이고
동시성을 가지고 11 기능들을 한꺼번에 멀티쓰레드 형태로 제공할 수
있게끔 서비스를 만드셔야 되구요.
특히 클라우드 환경에서는 보안이 매우 중요하게 됩니다.
그래서 다양한 보안 사례 및 풀들을 고려해서 여러분의 서비스의 보안
레벨을 높이고
여러분들 서비스에서 요구하는 보안 요구 사항
레벨 들을 맞춰야 됩니다.