[신한투자증권 프로 디지털 아카데미] ICT 아키텍처의 이해(2)

 

 

 

1. 클라우드 활용 기초 2

1. 서비스로서의 컴퓨팅

 

1) 서버

: HTTP 요청을 처리하고 클라이언트로 응답을 보냄, API 통신도 포함

: 애플리케이션 호스팅 하기 위해 필요 – 사용자가 원하는 걸 계산한 후에 반환함, 계산기로서의 역할

: 즉, 서버 = compute 하기 위한 리소스

 

- 클라이언트 : 요청을 보내는 사람 또는 컴퓨터

 

2) HTTP는 HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

- 웹페이지는 여러 자원으로 구성(광고, 비디오, 이미지 등)되고, 각각은 서버에서 메소드를 통해 정보를 호출(GET 요청)해서 불러옴

- 모놀리식 구조에서는 여러 자원을 하나의 서버세서 처리

- but 대부분의 실제 시스템에서는 각각의 서버에서 제공됨

 

 

3) DNS는 트래픽을 웹 애플리케이션에 어떻게 라우팅합니까?

 

1. 사용자의 웹 사이트 요청 - 도메인 이름만 가지고 있기 때문에 어디로 접속해야 할지 모름

2. DNS 해석기가 주소를 찾음 - 어디로 접속하고 싶은지를 해석함

• DNS 해석기는 ISP(Internet Service Provider)가 운영 - 인터넷에 접속할 수 있도록 서비스와 인프라를 제공하는 회사
• 그래서 회사별로 다 다름 – 그래서 특정 도메인, 불법 사이트 차단도 가능함 – 탑레벨에서 찾고 네임 서버에서 차단함

3. DNS 루트 네임서버에 물어봄 - .com의 TLD(Top Level Domain) 네임서버 주소 반환, 어디로 가야 할지 알려줌

4. .com TLD 네임서버로 요청 전송 - Amazon Route 53 같은 실제 네임서버의 위치를 알려줌

5-6. 최종 네임서버(Route 53)로 요청 - Amazon Route 53은 실제 서버 IP (192.0.2.44) 를 반환

7. DNS 해석 결과를 사용자에게 전달 - DNS 해석기가 최종 IP 주소를 브라우저에 반환

8. 브라우저가 실제 웹서버로 HTTP 요청 전송 - 이제 브라우저는 http://www.example.com에 직접 접속 가능

9. 웹페이지 응답 수신 - 해당 IP 주소의 웹서버에서 실제 콘텐츠를 받아옴

 

 

4) URL의 구성 요소들

 

- TLD 바로 앞의 도메인만 주소로 사용할 수 있음 – 그래서 탑 네임 서버에 어떤 네임 서버로 가야 하는지 질문하면 아이피 주소를 얻을 수 있음

- ? 뒤에 있는 내용은 쿼리 파라미터

- TLD, 그리고 TLD에 등록되어 있는 도메인과 서브 도메인으로 접속

- 명령을 할 때는 패쓰나 쿼리 파라미터를 이용해서 이동하게 됨

 

5) Request vs Response

- 사용자가 호출할 때 반환하는 값(= response)은 압축되어 있다 - 효율이 좋아짐, content length 가 줄어듦으로

- request 는 압축 X

- request에는 요청 메소드에 따라 이게 어떤 작업인지 명령을 줄 수 있음, 그리고 어떤 패쓰, 어떤 버전을 사용하는지 크롬이 보내게 됨

• 사용자가 www.example.com 요청 → 서버가 HTML 응답을 보냄  → 이때 Content-Encoding: gzip 헤더가 붙어 있음(압축되었음을 의미) → 브라우저는 이걸 해제해서 사용자가 보는 형태로 렌더링함

 

 

 

 

2. Amazon Elastic Compute Cloud

 

1) 컴퓨팅 서비스의 대표적인 영역

 

 

2) Amazon EC2 – 가상 서버 서비스

- 사양이 좋지 않은 걸 써도 workload 에 충분할 수 있으므로 업무 영역이 어떤 것인지 생각해야 한다

- 사용한 만큼만 과금 pay-as-you-go = on demand

 

- EC2 인스턴스 : AWS 만 사용하는 표현임, 인스턴트처럼 필요한 순간에 사용하고 다수의 사람이 오더라도 빠르게 공급할 수 있다

 

- 어떤 OS, 프로그램을 사용할 건지 선택해야 한다

 

3) Amazon Machine Images(AMIs)

- 설정을 번거롭게 중복해서 다시 할 필요가 없다 = 내 가상 컴퓨터를 백업해뒀다 

- AMI는 EC2 인스턴스의 상태(운영체제, 설정, 소프트웨어 등)를 이미지로 저장해 두는 기능

- 이를 통해 같은 설정의 가상 컴퓨터(EC2 인스턴스)를 반복해서 만들거나 복구할 수 있어서 매번 설정을 다시 할 필요가 없다

 

 

Q. AMI 중 어떤 걸 쓸래?

- Amazon Linux : AWS 에서 자체적으로 만들었기 때문에 AWS 를 사용할 때 성능이 최적화되어 있고 업데이트도 자주 이루어짐 but AWS에 종속되어 있음, vender lock-in

- Ubuntu : 데스크탑/서버 모두 널리 사용됨

 

cf. Amazon Linux, centOS : yum으로 설치 / Ubuntu : apt로 설치

 

4) Amazon EC2 instance 특징

- 인스턴스 크기는 2배씩 증가하도록 설정되어 있다

• micro – small – large – xlarge - 2xlarge - … - 10xlarge

 

5) 인스턴스 패밀리의 종류

• M 계열 : 범용, CPU, 메모리 균형 있음 - 웹 서버, 개발 환경
• C 계열 : 고성능 CPU - 게임 서버, 연산 처리 많은 백엔드
• R 계열 : 메모리 사용량이 많은 경우 - Redis, 데이터베이스 등 메모리를 기반으로 한 SW
• T 계열 : 성능 순간 확장, 기본은 저성능, 필요할 때만 성능을 급하게 높임, 일반적으로 이걸 많이 사용, 프리티어 이걸로 제공됨 - 소규모 웹서버, 테스트 서버
• G 계열 : Graviton (ARM 기반 CPU), ARM 아키텍처 기반의 저비용 고효율 서버 - 비용 효율성↑, 성능도 우수함 (AWS가 직접 개발한 CPU)
• I 계열 : 디스크와 빠른 입출력이 필요한 경우, SSD 기반의 초고속 인스턴스 스토리지 - NoSQL, 대용량 읽기/쓰기
• D : 인스턴스 스토어 존재 여부 - D가 붙으면 로컬 SSD 저장소 있음, 없으면 EBS(Elastic Block Store, AWS에서 제공하는 가상 디스크 서비스)만 사용함

Q. 인스턴스 스토어 vs EBS ?

	EBS (Elastic Block Store)	인스턴스 스토어 (D타입 SSD)
데이터 보존	인스턴스를 꺼도 유지됨	인스턴스 꺼지면 삭제됨
속도	네트워크 기반이라 상대적으로 느림 - 병목이 생길 수 있음	EC2에 물리적으로 붙어있어서 매우 빠름
장점	안정적, 백업 가능	초고속 I/O 처리에 유리
사용 예시	일반적인 서비스, DB	Redis 캐시, 일시적 고속 처리, 임시 연산용 등

 

 

6) 프로세서 및 아키텍처 선택

- 어떤 CPU를 사용할 건지?

 

• x86 아키텍처 : intel, AMD - 동일한 명령 체계를 사용함.
• 인텔 기반 인스턴스는 고성능이지만 가격이 비싸고, AMD 기반 인스턴스는 가격 대비 성능이 좋음
• AWS는 비용 효율성을 위해 자체 개발한 Graviton(Arm 아키텍처 기반) 프로세서도 제공함

 

7) Amazon Elastic Compute Cloud(EC2)

- 서버의 개수 ≠ 컴퓨터의 개수

• 사용자가 EC2 인스턴스를 22개 생성했다면, 1대의 물리 서버로 사용할 수도 22대가 필요할 수도 있다

- 호스트 서버 : 물리 서버 - 하나가 여러 인스턴스를 가상화할 수 있음

- 하이퍼바이저 : 각 인스턴스에 몇 개의 CPU, 메모리 등을 할당할지 결정

 

8) AMI와 EC2 인스턴스 간의 관계

- 루트 볼륨: 리눅스에서 / 디렉터리를 의미, 윈도우의 C드라이브 같은 개념

- 기본적으로 모든 데이터는 루트 볼륨에 저장되기 위해 EBS를 사용함

- EBS는 인스턴스 외부에 있는 스토리지로, 인스턴스가 종료되어도 데이터가 영구 보존됨

 

- AMI(Amazon Machine Image) : 서버 환경(운영체제, 애플리케이션, 설정 등)을 저장한 템플릿

- EC2 인스턴스 : 그 템플릿을 기반으로 만들어진 실제 서버

• AMI를 사용해서 EC2 인스턴스를 생성할 수 있는데, 설정이 끝났다면 이 인스턴스의 이미지를 AMI로 다시 생성할 수 있음
  → 그 이미지로 동일한 환경 빠르게 복제 가능

3. Amazon EC2 인스턴스 수명 주기

 

1) EC2 인스턴스 위치

- 기본값으로 EC2 인스턴스는 기본 Amazon Virtual Private CloudAmazon VPC라는 네트워크에 배치됨

- 기본 VPC에 넣은 모든 리소스는 공개되고 인터넷에서 액세스할 수 있으므로 고객 데이터 또는 개인 정보를 이러한 VPC에 배치하면 안 됨

 

2) 고가용성을 위한 설계

- 프론트엔드에 단일 인스턴스만 있을 경우 이 인스턴스가 실패하면 애플리케이션이 다운됨

- but 워크로드가 10개의 인스턴스에 분산되어 있을 경우 이 중 하나가 실패하면 플릿의 10%만 손실되고 애플리케이션 가용성은 거의 영향을 받지 않음

- 그래서 애플리케이션을 고가용성으로 설계할 때는 두 개의 개별 가용 영역에서 최소 두 개의 EC2 인스턴스를 사용하는 것이 좋음

 

3) EC2 인스턴스 수명 주기

 

1. 보류중 : 인스턴스를 시작하면 보류중 상태로 들어감, 사용 가능한 인스턴스가 있는지 판단하고 만약 있다면 바로 생성해서 실행 중 단계로 바뀜

2. 실행중 : 인스턴스가 활성 상태로 동작 중, 요금 청구 시작

3. 재부팅중 : = OS 재부팅, 몇 초 뒤에 실행 중 상태로 돌아오게 됨, 모든 데이터 유지되고 있음

4. 중지중

• 중지를 클릭하면 컴퓨터의 유저 단의 프로그램이 꺼지고 OS 단의 커널 꺼짐, 물리 리소스 해지 준비
• 중지됨
  • 어떤 것도 compute 하지 않겠다는 뜻
  • 점유하는 컴퓨터가 없어졌다 = 물리적 공간이 할당되지 않았으므로 컴퓨팅 비용 발생 안 함
  • EBS 스토리지는 유지되므로 해당 요금은 부과
  • 퍼블릭 IP 변경, 프라이빗 IP 는 유지
  • 인스턴스 스토어 삭제
  • 물리적 호스트에서 분리된 상태
• 중지 후 다시 실행
  • 새로운 물리 서버에 인스턴스 재할당
  • EBS 기반 루트 볼륨에서 OS 부팅 - 가용 자원 탐색 후 인스턴스 실행
  • 퍼블릭 IP 새로 부여, 프라이빗 IP 유지
  • EBS 덕분에 데이터 복구 가능

5. 종료 : 더 이상 사용할 수 없는 단계로 넘어가게 됨

• 인스턴스 영구 삭제
• 모든 컴퓨팅 자원 해제
• 루트 볼륨 및 인스턴스 연결된 EBS도 삭제 가능(설정에 따라)
• 퍼블릭/프라이빗 IP 모두 소멸
• 복구 불가 (별도로 스냅샷을 남기지 않았다면)

 

Q. 중지했는데도 요금이 나오게 됐다면 그 요금은 어디서 발생했을까?

AMI 사용해서 컴퓨터를 할당하게 되는데 그게 꺼지면 비용 발생 안 함, 근데 저장된 공간인 하드디스크 EBS 는 자원을 점유하고 있기 때문에 삭제되지 않음, 그래서 얘에 대한 비용은 중지를 하더라도 계속 발생하게 됨

 

4) 디스패치

- 기존 IDC 인프라의 한계점 : 트래픽 피크를 기준으로 요금이 책정되는 것이 불합리함
→ AWS 로 바꿈 – 오토 스케일링 활용

 

5) 요금

- 요금 옵션 선택 가능 : 온디맨드, 리저브드, 스팟

• 온디맨드 : 약정없이 쓴 만큼만 지불 - 갑작스런 트래픽, 예측하기 어려운 신규 서비스
• 리저브드 : 장기 계약하면 할인해줌 - 항상 사용 중인 안정화된 서버 자원
• 스팟 : 남은 자원에 대한 경매 방식 - 단기적으로 수요가 많을 경우

- 보통은 늘 사용하는 부분은 리저브드, 과부화된 부분은 온디맨드로 사용함 : 비용을 optimizing

 

6) 자동 서버 확장 / 축소

- 오토 스케일링이 잘 작동 안 하는 경우도 많음 – 왜? 기준을 설정해줘야 하고 트리거를 설정해야 함, 시간을 기준으로 100% 인데 늘림 → 그 늘어나는 와중에도 100% 이면 또 늘림 … 계속 늘려서 비용이 많이 발생할 가능성도 있음

 

7) 스팟 인스턴스로 비용 절감

- 가장 저렴하지만 중단될 가능성이 있음, 2분 전 경고 표시 - 데이터 분석, 머신 러닝의 경우 이걸로 사용됨

 

8) 서버가 여러 대인 경우 부하 분산은?

- 과거 로드 밸런서 라는 하드웨어 장치를 사용했으나, 최근에는 소프트웨어 로드 밸런서를 사용함

 

9) Elastic Load Balancing

- 클래식 로드밸런서는 속도가 느려서 이제는 사용 안 함

- 우리는 보통 ALB를 사용함 - 왜? 통신할 때 HTTP, HTTPS 를 주로 사용하게 되므로

 

10) EC2 인스턴스 상세

 

- 인스턴스 스토어는 물리적으로 서버와 연결되어 있기 때문에 빠른 통신이 가능한 것임, 그래서 생성될 때부터 인스턴스 서버와 연결된 경우만 사용 가능 - 즉, 인스턴스 스토어는 인스턴스와 함께 만들어지고, 해당 인스턴스에서만 사용할 수 있으며, 인스턴스가 종료되면 데이터도 함께 삭제됨

- 그래서 인스턴스 B의 경우에는 저장하려면 EBS가 적어도 하나 연결되어야 함 – like C drive, E drive

- 삭제한 인스턴스의 EBS 를 다른 인스턴스에 붙일 수 있음, 그래서 터미네이트 할 때 같이 삭제할 건지 남겨둘 건지를 선택할 수 있음

- EBS 는 네트워크로 연결이 되어 있으므로 대역폭 등에 영향을 받기 때문에 느림

- 여기서 EBS 를 어떤 유형을 선택하느냐에 따라 비용 차이가 발생함

 

11) 폭 넓은 스토리지 포트폴리오

 

• 블록 스토리지 : Amazon EBS 는 네트워크로 연결되어 있어서 느리고 일대일 연결임, 여러 개의 인스턴스가 여러 개의 EBS를 공유할 수 없음
• 파일 스토리지 : 네트워크로 공유해야 되는 파일, 인스턴스에서 공용적으로 사용해야 하므로 엘라스틱 시스템 을 통해서 파일을 네트워크로 공유할 수 있도록 함
• 오브젝트 스토리지
  • 스탠다드 = 온디맨드
  • Glacier(빙하) : 얼려둠, 만약 다시 사용하기 위해서는 n시간 전에 요청을 해야 됨

 

⭐️ 총 정리