🐾
개발자국
  • 🐶ABOUT
  • 🚲프로그래밍
    • 객체 지향 프로그래밍
    • 오브젝트
      • 1장: 객체, 설계
      • 2장: 객체지향 프로그래밍
      • 3장: 역할, 책임, 협력
      • 4장: 설계 품질과 트레이드오프
      • 5장: 책임 할당하기
      • 6장: 메시지와 인터페이스
      • 7장: 객체 분해
      • 8장: 의존성 관리하기
      • 9장: 유연한 설계
      • 10장: 상속과 코드 재사용
      • 11장: 합성과 유연한 설계
      • 12장: 다형성
      • 13장: 서브클래싱과 서브타이핑
      • 14장: 일관성 있는 협력
      • 15장: 디자인 패턴과 프레임워크
    • 도메인 주도 개발 시작하기
      • 1장: 도메인 모델 시작하기
      • 2장: 아키텍처 개요
      • 3장: 애그리거트
      • 4장: 리포지토리와 모델 구현
      • 5장: 스프링 데이터 JPA를 이용한 조회 기능
      • 6장: 응용 서비스와 표현 영역
      • 7장: 도메인 서비스
      • 8장: 애그리거트 트랜잭션 관리
      • 9장: 도메인 모델과 바운디드 컨텍스트
      • 10장: 이벤트
      • 11장: CQRS
    • 클린 아키텍처
      • 만들면서 배우는 클린 아키텍처
        • 계층형 아키텍처의 문제와 의존성 역전
        • 유스케이스
        • 웹 어댑터
        • 영속성 어댑터
        • 아키텍처 요소 테스트
        • 경계 간 매핑 전략
        • 애플리케이션 조립
        • 아키텍처 경계 강제하기
        • 지름길 사용하기
        • 아키텍처 스타일 결정하기
    • 디자인 패턴
      • 생성(Creational) 패턴
        • 팩토리 패턴
        • 싱글톤 패턴
        • 빌더 패턴
        • 프로토타입 패턴
      • 행동(Behavioral) 패턴
        • 전략 패턴
        • 옵저버 패턴
        • 커맨드 패턴
        • 템플릿 메서드 패턴
        • 반복자 패턴
        • 상태 패턴
        • 책임 연쇄 패턴
        • 인터프리터 패턴
        • 중재자 패턴
        • 메멘토 패턴
        • 비지터 패턴
      • 구조(Structural) 패턴
        • 데코레이터 패턴
        • 어댑터 패턴
        • 퍼사드 패턴
        • 컴포지트 패턴
        • 프록시 패턴
        • 브리지 패턴
        • 플라이웨이트 패턴
      • 복합 패턴
  • 시스템 설계
    • 1. 사용자 수에 따른 규모 확장성
    • 2. 개략적 규모 추정
    • 3. 시스템 설계 접근법
    • 4. 처리율 제한 장치
    • 5. 안정 해시
    • 6. 키-값 저장소
    • 7. 유일한 ID 생성기
    • 8. URL 단축기
    • 9. 웹 크롤러
    • 10. 알림 시스템
    • 11. 뉴스 피드
    • 12. 채팅 시스템
    • 13. 검색어 자동완성
    • 14. 유튜브 스트리밍
    • 15. 구글 드라이브
    • ⭐️. 캐싱 전략
    • ⭐️. 재고 시스템으로 알아보는 동시성이슈 해결방법
    • ⭐️. 실습으로 배우는 선착순 이벤트 시스템
  • 🏝️자바
    • 자바의 내부 속으로
      • Java 언어의 특징
      • JDK
      • JVM
        • 메모리 관리
        • Garbage Collector
          • 기본 동작
          • Heap 영역을 제외한 GC 처리 영역
          • (WIP) GC 알고리즘
        • 클래스 로더
      • 자바 실행 방식
      • 메모리 모델과 관리
      • 바이트 코드 조작
      • 리플렉션
      • 다이나믹 프록시
      • 어노테이션 프로세서
    • 자바의 기본
      • 데이터 타입, 변수, 배열
    • 이펙티브 자바
      • 2장: 객체의 생성과 파괴
        • item 1) 생성자 대신 정적 팩토리 메서드를 고려하라
        • item2) 생성자에 매개변수가 많다면 빌더를 고려하라
        • item3) private 생성자나 열거 타입으로 싱글톤임을 보증하라
        • item4) 인스턴스화를 막으려면 private 생성자를 사용
        • item5) 자원을 직접 명시하는 대신 의존 객체 주입 사용
        • item6) 불필요한 객체 생성 지양
        • item7) 다 쓴 객체는 참조 해제하라
        • item8) finalizer와 cleaner 사용 자제
        • item9) try-with-resources를 사용하자
      • 3장: 모든 객체의 공통 메서드
        • item 10) equals는 일반 규약을 지켜 재정의 하자
        • item 11) equals 재정의 시 hashCode도 재정의하라
        • item 12) 항상 toString을 재정의할 것
        • item 13) clone 재정의는 주의해서 진행하라
        • item 14) Comparable 구현을 고려하라
      • 4장: 클래스와 인터페이스
        • item 15) 클래스와 멤버의 접근 권한을 최소화하라
        • item 16) public 클래스에서는 public 필드가 아닌 접근자 메서드를 사용하라
        • item 17) 변경 가능성을 최소화하라
        • item 18) 상속보다는 컴포지션을 사용하라
        • item 19) 상속을 고려해 설계하고 문서화하고, 그러지 않았다면 상속을 금지하라
        • item 20) 추상 클래스보다는 인터페이스를 우선하라
        • item 21) 인터페이스는 구현하는 쪽을 생각해 설계하라
        • item 22) 인터페이스는 타입을 정의하는 용도로만 사용하라
        • item 23) 태그 달린 클래스보다는 클래스 계층구조를 활용하라
        • item 24) 멤버 클래스는 되도록 static으로 만들라
        • item 25) 톱레벨 클래스는 한 파일에 하나만 담으라
      • 5장: 제네릭
        • item 26) 로 타입은 사용하지 말 것
        • item 27) unchecked 경고를 제거하라
        • item 28) 배열보다 리스트를 사용하라
        • item 29) 이왕이면 제네릭 타입으로 만들라
        • item 30) 이왕이면 제네릭 메서드로 만들라
        • item 31) 한정적 와일드카드를 사용해 API 유연성을 높이라
        • item 32) 제네릭과 가변 인수를 함께 사용
        • item 33) 타입 안전 이종 컨테이너를 고려하라
      • 6장: 열거 타입과 어노테이션
        • item 34) int 상수 대신 열거 타입을 사용하라
        • item 35) ordinal 메서드 대신 인스턴스 필드를 사용하라
        • item 36) 비트 필드 대신 EnumSet을 사용하라
        • item 37) ordinal 인덱싱 대신 EnumMap을 사용하라
        • item 38) 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라
        • item 39) 명명 패턴보다 어노테이션을 사용하라
        • item 40) @Override 어노테이션을 일관되게 사용하라
        • item 41) 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라
      • 7장: 람다와 스트림
        • item 42) 익명 클래스보다는 람다를 사용하라
        • item 43) 람다보다는 메서드 참조를 사용하라
        • item 44) 표준 함수형 인터페이스를 사용하라
        • item 45) 스트림은 주의해서 사용하라
        • item 46) 스트림에서는 부작용 없는 함수를 사용하라
        • item 47) 반환 타입으로는 스트림보다 컬렉션이 낫다
        • item 48) 스트림 병렬화는 주의해서 적용하라
      • 8장: 메서드
        • item 49) 매개변수가 유효한지 검사하라
        • item 50) 적시에 방어적 복사본을 만들라
        • item 51) 메서드 시그니처를 신중히 설계하라
        • item 52) 다중정의는 신중히 사용하라
        • item 53) 가변인수는 신중히 사용하라
        • item 54) null이 아닌, 빈 컬렉션이나 배열을 반환하라
        • item 55) 옵셔널 반환은 신중히 하라
        • item 56) 공개된 API 요소에는 항상 문서화 주석을 작성하라
      • 9장: 일반적인 프로그래밍 원칙
        • item 57) 지역 변수의 범위를 최소화하라
        • item 58) 전통적인 for문보다 for-each문을 사용하기
        • item 59) 라이브러리를 익히고 사용하라
        • item 60) 정확한 답이 필요하다면 float, double은 피하라
        • item 61) 박싱된 기본타입보단 기본 타입을 사용하라
        • item 62) 다른 타입이 적절하다면 문자열 사용을 피하라
        • item 63) 문자열 연결은 느리니 주의하라
        • item 64) 객체는 인터페이스를 사용해 참조하라
        • item 65) 리플렉션보단 인터페이스를 사용
        • item 66) 네이티브 메서드는 신중히 사용하라
        • item 67) 최적화는 신중히 하라
        • item 68) 일반적으로 통용되는 명명 규칙을 따르라
      • 10장: 예외
        • item 69) 예외는 진짜 예외 상황에만 사용하라
        • item 70) 복구할 수 있는 상황에서는 검사 예외를, 프로그래밍 오류에는 런타임 예외를 사용하라
        • item 71) 필요 없는 검사 예외 사용은 피하라
        • item 72) 표준 예외를 사용하라
        • item 73) 추상화 수준에 맞는 예외를 던지라
        • item 74) 메서드가 던지는 모든 예외를 문서화하라
        • item 75) 예외의 상세 메시지에 실패 관련 정보를 담으라
        • item 76) 가능한 한 실패 원자적으로 만들라
        • item 77) 예외를 무시하지 말라
      • 11장: 동시성
        • item 78) 공유 중인 가변 데이터는 동기화해 사용하라
        • item 79) 과도한 동기화는 피하라
        • item 80) 스레드보다는 실행자, 태스크, 스트림을 애용하라
        • item 81) wait와 notify보다는 동시성 유틸리티를 애용하라
        • item 82) 스레드 안전성 수준을 문서화하라
        • item 83) 지연 초기화는 신중히 사용하라
        • item 84) 프로그램의 동작을 스레드 스케줄러에 기대지 말라
      • 12장: 직렬화
        • item 85) 자바 직렬화의 대안을 찾으라
        • item 86) Serializable을 구현할지는 신중히 결정하라
        • item 87) 커스텀 직렬화 형태를 고려해보라
        • item 88) readObject 메서드는 방어적으로 작성하라
        • item 89) 인스턴스 수를 통제해야 한다면 readResolve보다는 열거 타입을 사용하라
        • item 90) 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라
    • 모던 자바 인 액션
      • 1장: 자바의 역사
      • 2장: 동작 파라미터화
      • 3장: 람다
      • 4장: 스트림
      • 5장: 스트림 활용
      • 6장: 스트림으로 데이터 수집
      • 7장: 병렬 데이터 처리와 성능
      • 8장: 컬렉션 API 개선
      • 9장: 람다를 이용한 리팩토링, 테스팅, 디버깅
      • 10장: 람다를 이용한 DSL
      • 11장: null 대신 Optional
      • 12장: 날짜와 시간 API
      • 13장: 디폴트 메서드
      • 14장: 자바 모듈 시스템
      • 15장: CompletableFuture와 Reactive 개요
      • 16장: CompletableFuture
      • 17장: 리액티브 프로그래밍
      • 18장: 함수형 프로그래밍
      • 19장: 함수형 프로그래밍 기법
      • 20장: 스칼라 언어 살펴보기
    • 자바의 이모저모
      • Javax
      • Objects
      • NIO
      • Thread
      • Concurrent
        • Atomic
        • Executor, ExecutorService
        • Interrupt
      • Assertions
    • Netty
      • 네티 맛보기
      • 네티의 주요 특징
      • 채널 파이프라인
      • 이벤트 루프
      • 바이트 버퍼
      • 부트스트랩
      • 네티 테스트
      • 코덱
      • 다양한 ChannelHandler와 코덱
      • 웹소켓
      • UDP 브로드캐스팅
    • 자바 병렬 프로그래밍
      • 2장: 스레드 안전성
      • 15장: 단일 연산 변수와 논블로킹 동기화
  • 🏖️코틀린
    • 코틀린 인 액션
      • 코틀린 언어의 특징
      • 코틀린 기초
      • 함수 정의와 호출
      • 클래스, 객체, 인터페이스
      • 람다
      • 타입 시스템
      • 연산자 오버로딩과 기타 관례
      • 고차 함수
      • 제네릭스
      • 어노테이션과 리플렉션
      • DSL 만들기
  • 🌸스프링
    • Spring Core
      • Cron Expression
      • Bean
        • Lifecycle
        • Aware
    • Spring MVC
    • Spring Security
      • 로그인 처리
      • 로그아웃 처리
      • JWT 인증 방식
      • 메소드별 인가 처리
    • Spring Data
      • Pageable
      • Spring Data Couchbase
      • Spring Data Redis
        • Serializer
    • Spring REST Docs
    • Spring Annotations
    • Spring Cloud
      • Service Discovery
      • API Gateway
      • Spring Cloud Config
      • MicroService Communication
      • Data Synchronization
    • Test
      • 테스트 용어 정리
      • JUnit
      • Spring Boot Test
      • Mockito
    • QueryDSL
      • 프로젝트 환경설정
      • 기본 문법
      • 중급 문법
      • 순수 JPA와 QueryDSL
      • 스프링 데이터 JPA와 QueryDSL
    • Lombok
      • @Data
      • @Builder
      • Log Annotations
  • 🕋DB
    • MySQL
      • CentOS7에서 MySQL 8 버전 설치하기
    • MongoDB
      • 
    • Redis
      • Sentinel
      • Cluster
      • Transaction
      • 자료구조
        • String
        • List
        • Set
        • Hash
        • Bitmaps
        • SortedSet
      • Lettuce 단일 서버, 클러스터 서버, 풀링 사용 방법
  • 📽️인프라
    • 리눅스
      • 주요 명령어 모음
    • Docker
      • Docker
      • Docker Compose
      • Docker Swarm
      • Docker Network
      • Linux에서 root 아닌 유저로 docker 실행하기
    • Kubernetes
      • 기초 개념
      • Pod
      • Configuration
      • ReplicationSet
      • Network
      • ConfigMap & Secret
      • Volume, Mount, Claim
      • Controller
      • Multi Container Pod
      • StatefulSet & Job
      • Rollout & Rollback
      • Helm
      • 개발 워크플로우와 CI/CD
      • Container Probes
      • Resource Limit
      • Logging & Monitoring
      • Ingress
      • Security
      • Multi Node/Architecture Cluster
      • Workload & Pod management
      • CRD & Operator
      • Serverless Function
      • K8S Cheat Sheet
    • Kafka
      • 카프카 개요
      • 카프카 설치 및 실습
      • Kafka Broker
      • Topic, Partition, Record
      • Producer
      • Consumer
      • Kafka Streams
      • Kafka Connect
      • MirrorMaker
  • AWS
    • AWS Console / CLI / SDK
    • IAM
    • EC2
      • EC2 Advanced
    • ELB / ASG
    • RDS / Aurora / ElastiCache
    • DynamoDB
    • DocumentDB / Neptune / Keyspaces / QLDB / Timestream
    • Route 53
    • Beanstalk
    • Solution Architect
    • S3
      • 보안
    • CloudFront
    • Global Accelerator
    • AWS Storage
    • Messaging
    • Container
    • Serverless
    • Data Analysis
    • Machine Learning
    • Monitoring
    • Security
    • VPC
    • Data Migration
    • 기타 서비스
  • 🏔️CS
    • 운영 체제
      • Introduction
      • System Structures
      • Process
      • Synchronization
      • Muitithreaded Programming
      • Process Scheduling
      • Memory Management
      • Virtual Memory
    • 네트워크
      • 네트워크 기초
      • 네트워크 통신 방식
      • OSI 7계층
        • 1계층: 물리계층
        • 2계층: 데이터 링크 계층
        • 3계층: 네트워크 계층
        • 4계층: 전송 계층
        • 5계층: 세션 계층
        • 6계층: 표현 계층
        • 7계층: 응용 계층
      • TCP/IP 스택
      • ARP
      • 데이터 크기 조절
      • WDM
      • NAT
      • DNS
      • DHCP
      • VPN
      • 네이글 알고리즘
      • 서버 네트워크
      • 네트워크 보안
        • 보안의 기본
        • 보안 장비
      • 이중화
    • 데이터베이스
      • 트랜잭션
    • 컴퓨터 구조
      • 개요
      • Instruction Set Architecture
      • Procedure Call & Return
      • Linking
      • Pipeline
      • Memory Hierarchy
      • Virtual Memory
      • Interrupt / Exception, IO
    • 자료 구조
      • Array
      • List
      • Map
      • Set
      • Queue
      • PriorityQueue
      • Stack
    • 웹 기술
      • HTTP
        • 쿠키와 세션
  • 🪂Big Data
    • Apache Hadoop
  • 🕹️ETC
    • Git
      • 내부 구조
      • 내가 자주 사용하는 명령어 모음
      • Commit Convention
    • 이력서 작성하기
    • Embedded
      • 라즈베리파이에서 네오픽셀 적용기
    • 기술블로그 모음집
Powered by GitBook
On this page
  • Snow Family
  • Amazon FSx
  • Storage Gateway
  • 하이브리드 클라우드
  • AWS Storage Gateway
  • Amazon S3 파일 게이트웨이
  • Amazon FSx 파일 게이트웨이
  • 볼륨 게이트웨이
  • 테이프 게이트웨이
  • Hardware Appliance
  • AWS Transfer Family
  • DataSync
  1. AWS

AWS Storage

PreviousGlobal AcceleratorNextMessaging

Last updated 28 days ago

Snow Family

  • Snowball

    • 엣지 환경에서 데이터를 수집하고 프로세싱, 마이그레이션하기 위해 사용되는 보안성이 높은 장치

    • PB 단위의 데이터를 마이그레이션할 때 네트워크를 거치는 대신 장치를 통해 이동시킬 수 있다.

    • Snowball(80TB ~ 210TB)보다 적은 양의 데이터를 다루는 Snowcone(8TB HDD ~ 14TB SSD)도 제공된다.

    • 네트워크를 통해 데이터를 전송할 경우 대역폭이 10Gbps라고 할 때 10TB는 3시간, 1PB는 12일까지 소요된다.

    • 네트워크를 공용으로 사용해 모든 대역폭을 소진하지 않아야 하거나, 네트워크 비용이 비싸거나, 연결이나 대역폭이 제한된 환경에서 데이터를 옮기기 위해 사용된다.

  • 엣지 컴퓨팅 환경이란 인터넷 연결이 원활히 되지 않는 환경을 의미한다. 이러한 환경에서 데이터를 수집하거나 프로세싱할 때 스노우볼 엣지 장치를 이용할 수 있다. 엣지 장치에서 EC2 인스턴스나 람다 함수를 실행할 수도 있다.

  • 스노우볼의 데이터는 바로 S3 Glacier로 입력할 수 없다. 따라서 S3 생명 주기 규칙에 의해 Glacier로 이동시켜주어야 한다.

Amazon FSx

  • Amazon FSx는 타사 고성능 파일 시스템을 실행시키는 관리형 서비스이다.

  • FSx for Lustre

    • Linux와 클러스터(Cluster)를 합친 단어로 대량의 연산에 사용되던 분산 파일 시스템이다.

    • 머신 러닝과 HPC, 동영상 처리나 금융 모델링 전자 설계 자동화 등의 애플리케이션에서 쓰이고 확장성이 높다.

    • 초당 수백 GB의 데이터에 수백만 IOPS로 확장되고 밀리초보다 짧은 지연 시간을 보장한다.

    • 스토리지 옵션

      • SSD: 낮은 지연 시간, IOPS 워크로드 위주, 크기가 작은 무작위 파일 작업을 위해 사용한다.

      • HDD: 처리량이 많은 워크로드나 크기가 큰 시퀀스 파일 작업을 위해 사용한다.

    • FSx를 통해 S3를 파일 시스템로 읽어들이고 FSx의 연산 결과를 S3에 쓸 수 있다.

    • 온프레미스 서버에서 VPN, Direct Connect를 통해 사용할 수 있다.

    • 파일 시스템 배포 옵션

      • 스크래치 파일 시스템

        • 임시 스토리지로 데이터가 복제되지 않는다. 따라서 서버가 오작동하면 파일이 모두 유실된다.

        • 초과 버스트를 제공하여 영구 파일 시스템보다 성능을 여섯 배(200MBps per TiB) 늘릴 수 있다.

        • 단기 처리 데이터에 쓰이며 저렴하다.

      • 영구 파일 시스템

        • 동일한 AZ에 데이터가 복제된다.

        • 서버가 오작동했을 때 몇분 내에 해당 파일이 대체된다.

        • 민감한 데이터의 장기 처리 및 스토리지로 사용한다.

  • FSx for Windows File Server

    • 완전 관리형 Windows 파일 서버 공유 드라이브

    • SMB 프로토콜과 Windows NTFS, Microsoft Active Directory 통합을 지원한다.

    • 사용자 보안을 추가할 수 있고 ACL로 사용자 할당량을 추가해 액세스를 제어할 수 있다.

    • Linux EC2 인스턴스에도 마운트할 수 있다.

    • 기존 온프레미스 환경에 Windows 파일 서버가 있는 경우 Microsoft 분산 파일 시스템인 DFS 기능을 이용해서 파일 시스템을 그룹화할 수 있다.

    • 초당 수십 GB에 수백만 IOPS 그리고 수백 PB의 데이터까지 확장될 수 있다.

    • 스토리지 옵션

      • SSD: 지연 시간이 짧아야 하는 워크로드를 저장하기 위해 사용한다.

      • HDD: 비용이 저렴하고 넓은 스펙트럼의 워크로드를 저장하기 위해 사용한다.

    • 프라이빗 연결로 온프레미스 인프라에서 액세스할 수 있다.

    • 다중 AZ에 구성할 수 있다.

    • 모든 데이터는 재해 복구 목적으로 Amazon S3에 매일 백업된다.

  • FSx for NetApp ONTAP

    • NFS, SMB, iSCSI 프로토콜과 호환된다.

    • 온프레미스 시스템의 ONTAP이나 NAS에서 실행 중인 워크로드를 AWS로 옮길 수 있다.

    • 다양한 운영 체제에서 사용 가능하다.

    • 스토리지가 자동으로 확장 및 축소된다.

    • 복제와 스냅샷 기능을 지원한다.

    • 비용이 적게 들고 데이터 압축이나 데이터 중복제거도 가능하다.

    • 새 워크로드 등을 테스트할 때 유용한 지정 시간 복제 기능을 제공한다.

  • FSx for OpenZFS

    • 여러 버전에서의 NFS 프로토콜과 호환된다.

    • 주로 ZFS에서 실행되는 워크로드를 내부적으로 AWS로 옮길 때 사용된다.

    • Linux, Mac, Windows에서 사용할 수 있다.

    • 백만 IOPS까지 확장 가능하고 지연 시간은 0.5 밀리초 이하이다.

    • 스냅샷, 압축을 지원하고 비용이 적지만 데이터 중복제거 기능은 없다.

    • NetApp ONTAP과 동일하게 지정 시간 동시 복제 기능을 제공한다.

Storage Gateway

하이브리드 클라우드

  • 일부 인프라는 AWS 클라우드에 있고, 나머지는 온프레미스에 두는 방식을 의미한다.

  • 클라우드 마이그레이션이 오래 걸리거나 보안 또는 규정 준수 요건이 있는 경우 이 방식을 사용한다.

  • 엘라스틱 워크로드에만 클라우드를 활용하고 나머지는 온프레미스에 두는 방법을 사용할 수도 있다.

AWS Storage Gateway

  • 온프레미스 데이터와 클라우드 데이터를 이어주는 브릿지 역할을 한다. 정확히는 온프레미스 데이터를 클라우드로 이동시킬 때 사용한다.

  • 다음의 AWS Storage Cloud Native Options들이 있다.

    • Amazon EBS나 EC2 인스턴스 같은 블록 스토리지

    • Amazon EFS나 Amazon FSx 같은 파일 시스템

    • Amazon S3나 Amazon Glacier 같은 객체 수준 스토리지

  • 사용 목적

    • 재해 복구

      • 온프레미스 데이터를 클라우드에 백업해둔다.

    • 백업과 복구

      • 클라우드 마이그레이션, 혹은 온프레미스에서 클라우드 간 스토리지 확장을 사용

    • 계층 스토리지

      • 클라우드에는 콜드 데이터를 두고 온프레미스에는 이보다 더 자주 쓰는 웜 데이터를 둔다.

    • 온프레미스 캐시

      • 대부분의 데이터를 AWS에 저장하고 파일 액세스 지연 시간을 줄이기 위함

  • S3 파일 게이트웨이, FSx 파일 게이트웨이, 볼륨 게이트웨이, 테이프 게이트웨이가 존재한다.

  • 게이트웨이는 온프레미스 환경(ex. 회사 데이터 센터)에 설치되어 있어야 한다.

Amazon S3 파일 게이트웨이

  • S3 버킷은 원하는 스토리지 클래스를 사용해 구성할 수 있다. 하지만 Glacier는 사용할 수 없다.

  • 애플리케이션 서버가 NFS나 SMB 프로토콜을 사용해 데이터를 보내면, S3 파일 게이트웨이는 해당 요청을 HTTPS 요청으로 변환시켜 Amazon S3 버킷으로 보낸다.

  • 따라서 애플리케이션 서버가 보기에는 일반적인 파일 공유 액세스로 보이지만, 실제로는 Amazon S3 버킷을 사용하게 되는 것이다.

  • S3 버킷에 수명 주기 정책을 생성하여 S3 Glacier로 객체를 옮길 수 있다.

  • S3 파일 게이트웨이로 구성한 모든 버킷은 NFS 및 SMB 프로토콜을 이용해서 접근 가능하다.

  • 가장 최근에 사용된 데이터는 파일 게이트웨이에 캐싱된다.

  • 버킷에 접근하기 위해 각 파일 게이트웨이마다 IAM 역할을 생성해야 한다.

  • Windows 파일 시스템 네이티브인 SMB 프로토콜을 사용하는 경우에는 사용자 인증을 위해 Active Directory와 통합해야 한다.

Amazon FSx 파일 게이트웨이

  • Amazon FSx for Windows File Server에 네이티브 액세스를 제공한다. 즉, 온프레미스 시스템에서 Amazon FSx for Windows File Server에 접근할 수 있다.

  • 빈번히 접근된 데이터를 로컬 캐시에 저장한다.

  • Windows 네이티브인 SMB, NTFS Active Directory와 호환 가능하다.

  • 그룹 파일 공유나 온프레미스를 연결할 홈 디렉터리로 사용할 수 있다.

볼륨 게이트웨이

  • iSCSI 프로토콜을 사용해 S3에 백업 데이터를 저장하는 블록 스토리지

  • 온프레미스 서버에서 볼륨을 EBS 스냅샷으로 백업하여 필요에 따라 온프레미스 볼륨을 복구할 수 있다.

  • 볼륨 게이트웨이 유형

    • 캐시 볼륨: 최신 데이터에 접근 시 지연 시간이 낮다.

    • 저장 볼륨: 전체 데이터가 온프레미스에 있으며 주기적으로 Amazon S3에 백업한다.

  • 애플리케이션 서버 백업이 필요한 경우 iSCSI 프로토콜로 볼륨 게이트웨이를 생성한다. 볼륨 게이트웨이는 Amazon EBS 스냅샷을 생성해 Amazon S3에 저장한다.

테이프 게이트웨이

  • 물리적으로 테이프를 사용하는 백업 시스템이 있는 회사가 테이프 대신에 클라우드를 활용해 데이터를 백업할 수 있도록 한다.

  • 가상 테이프 라이브러리(VTL)는 Amazon S3와 Glacier를 이용한다.

  • 테이프 기반 프로세스의 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업한다.

  • 업계를 선도하는 백업 소프트웨어 벤더가 사용하는 서비스이다.

  • 테이프 기반인 회사 데이터 센터의 백업 서버가 있을 때 테이프 게이트웨이가 이를 클라우드에 연결하여 Amazon S3나 Amazon Glacier에 해당 테이프를 저장한다.

Hardware Appliance

  • 게이트웨이를 실행할 가상 서버가 없는 환경이라면 AWS에서 제공하는 하드웨어를 구매해 사용할 수 있다

  • 하드웨어 어플라이언스는 미니 서버가 되어 파일 게이트웨이, 볼륨 게이트웨이 혹은 테이프 게이트웨이를 수행시킬 수 있다.

  • 원활히 작동하려면 충분한 CPU, 메모리 네트워크, 그리고 SSD 캐시 리소스가 필요하다.

  • 소규모 데이터 센터의 일일 NFS 백업 시에 유용하다.

AWS Transfer Family

  • Amazon S3 또는 EFS의 파일을 내보내거나 업로드할 때 FTP 프로토콜을 사용하도록 지원한다.

  • S3 API나 EFS 네트워크 파일 시스템도 사용하고 싶지 않을 때 적합하다.

  • FTP, FTPS(SSL 사용한 FTP), SFTP(보안 파일 전송 프로토콜) 프로토콜을 이용한 AWS 전송을 지원한다.

  • 완전 관리형 인프라이며 확장성, 안정성이 높고 가용성이 높다.

  • 시간당 프로비저닝된 엔드 포인트 비용에 전송 제품군 안팎으로 전송된 데이터의 GB당 요금을 더해 과금된다.

  • 서비스 내에서 사용자 자격 증명을 저장 및 관리할 수 있다.

  • 기존의 인증 시스템과 통합할 수 있다.

    • Microsoft Active Directory, LDAP, Okta, Amazon Cognito, Custom ..

  • 파일 공유, 공개 데이터셋 공유, CRM, ERP 등을 위해 사용한다.

  • 사용자는 FTP의 엔드 포인트를 통해 직접 액세스하거나, Route 53를 사용하여 FTP 서비스에 도메인 이름을 제공할 수 있다.

  • FTP 서비스에 IAM 역할을 부여해야 Amazon S3나 Amazon EFS의 파일을 보내거나 읽을 수 있다.

DataSync

  • 대용량의 데이터를 한 곳에서 다른 곳으로 동기화할 수 있다.

  • 온프레미스나 다른 클라우드의 데이터를 AWS로 옮길 수 있다. 양방향으로 데이터를 옮길 수 있다.

  • 서버에서 NFS, SMB HDFS 또는 다른 프로토콜을 사용해야 할 경우, 온프레미스나 연결할 다른 클라우드에 에이전트가 있어야 한다.

  • AWS 서비스에서 다른 AWS 서비스로 데이터를 옮길 수 있다. 이 경우에는 에이전트가 필요 없다.

  • 동기화 가능한 대상은 다음과 같다.

    • Amazon S3의 Glacier를 포함한 모든 스토리지 클래스

    • Amazon EFS

    • Amazon FSx (모든 운영 체제 지원)

  • 복제 작업은 주기를 지정하여 매 시간, 매일, 혹은 매주 실행되도록 할 수 있다.

  • DataSync는 파일 권한과 메타데이터 저장 기능을 제공한다.

    • NFS POSIX 파일 시스템 그리고 SMB 권한을 준수할 수 있다.

    • 파일을 한 곳에서 다른 곳으로 옮길 때 파일의 메타데이터를 보존할 수 있다.

  • 에이전트 하나의 태스크가 초당 10Gb까지 사용할 수 있으며 네트워크 성능을 초과하고 싶지 않은 경우 대역폭에 제한을 걸 수 있다.

  • 동작 과정

    • 예를 들어 SMB 혹은 NFS 프로토콜을 사용하는 온프레미스 서버의 파일을 AWS로 동기화하려면, 온프레미스에 AWS DataSync 에이전트를 설치한다.

    • DataSync 에이전트를 NFS 또는 SMB 서버에 연결시킨다.

    • 에이전트를 이용하여 암호화를 거쳐 DataSync 서비스에 연결해야 한다.

    • Amazon S3 버킷의 스토리지 클래스나 AWS EFS 혹은 Amazon FSx에 동기화를 위해 데이터를 보내거나 받을 수 있다.

  • DataSync를 이용하려 하지만 네트워크 대역폭이 부족할 경우 AWS Snowcone 장치를 사용하면 된다.

    • Snowcone 장치에는 DataSync 에이전트가 사전에 설치되어 있다.

    • 온프레미스에서 Snowcone을 실행하고 데이터를 가져온 다음 DataSync 에이전트를 실행하면 데이터가 AWS 리전으로 전송되어 AWS의 스토리지 리소스 외부에 데이터를 동기화할 수 있다.

  • 서로 다른 AWS 스토리지 서비스 간 동기화도 가능하다.

    • Amazon S3, Amazon EFS 또는 Amazon FSx를 Amazon S3, Amazon EFS Amazon FSx로 다시 동기화할 수 있다.

    • 이를 통해 데이터 복사본을 만들 수 있다.

    • 서로 다른 AWS 스토리지 서비스 간 메타데이터 또한 유지된다.