AWS 기술 블로그

Amazon File Cache로 하이브리드 클라우드 워크로드를 가속화 및 단순화 하기

이 글은 클라우드의 컴퓨팅 자원에서 온-프레미스의 데이터셋에 접근하는 하이브리드 클라우드 워크로드를 대상으로, Amazon File Cache를 통해 애플리케이션을 가속화, 단순화 하는 방법을 소개합니다. 이 글을 통해, 독자들은 Amazon File Cache 사용의 장점과 구체적 활용 방법에 대해 이해할 수 있습니다.

Amazon File Cache는 클라우드에서 고성능 연산을 수행하는 애플리케이션이 원거리 데이터에 높은 대역폭과 낮은 지연시간으로 접근할 수 있도록 설계되었습니다. Amazon File Cache를 Amazon EC2, Amazon ECS 같은 컴퓨팅 서비스의 고성능 캐시로 활용하면, 초당 최대 수백 기가바이트의 대역폭과 밀리 초 미만의 지연시간으로 데이터를 읽을 수 있습니다. File Cache는 POSIX 인터페이스를 기반으로 높은 이식성을 제공합니다. 따라서, 온-프레미스의 파일 시스템에 접근하는 기존 워크플로를 수정하지 않더라도 애플리케이션과 간편하게 통합 가능합니다. 원본 데이터가 NFS v3로 접근 가능한 파일 시스템에 있거나  Amazon S3 버킷에 저장되어 있다면, Amazon File Cache의 원본 데이터 저장소로 구성할 수 있습니다.

Amazon File Cache 활용 시나리오

재무 서비스, 헬스케어, 반도체 설계, 제조 등 고성능 컴퓨팅을 필요로 하는 다양한 산업군에서 리소스가 풍부한 클라우드 환경으로의 워크로드 마이그레이션을 고려합니다. 하지만, 데이터 보안, 데이터 규모, 혹은 일정 상의 이유로, 컴퓨팅에 활용할 원천 데이터 전체를 클라우드로 마이그레이션 할 수 없는 경우가 많습니다. 이런 경우, 온-프레미스의 데이터 저장소와 Amazon File Cache를 연결하면, 클라우드 애플리케이션에서 필요로 하는 데이터 일부만 File Cache로 불러오고, 캐시를 경유하여 빠르고 투명하게(transparent) 데이터에 접근할 수 있습니다.

활용하려는 데이터셋이 여러 리전의 Amazon S3 버킷에 분산 저장되어 있는 다른 시나리오를 생각해봅니다. 데이터에 접근하는 기존 애플리케이션은 전통적 파일시스템 접근 방식(POSIX)으로 구현되어 있으며, 파일에 awk, sed, pipes 등 커맨드라인 도구를 활용하기도 합니다. 애플리케이션은 데이터 접근에 밀리 초 미만의 응답시간을 필요로 하며, 소스코드의 구현 방식을 S3 API로 변경할 계획이 없습니다. 이런 경우에도, Amazon File Cache를 여러 S3 버킷과 연결된 중간 계층 캐시로 구성하여, API 변경 없이 여러 리전의 대규모 데이터셋에 빠르게 접근할 수 있습니다.

이 밖에도, 클라우드에서 영상 파일을 렌더링하고 트랜스코딩하는 미디어 워크로드나, 대규모 데이터를 처리하는 유전체 분석, 병렬 연산을 위해 고성능 읽기를 필요로 하는 기계학습과 데이터 분석 워크로드 등 다양한 사례에 Amazon File Cache를 활용할 수 있습니다. File Cache는 NFS v3 기반 파일 시스템 또는 여러 리전에 위치한 S3 버킷들을 데이터 소스로 지원합니다. 최대 8개의 NFS 파일 시스템 또는 8개의 S3 버킷을 하나의 File Cache에 연결할 수 있고, 여러 데이터 소스에 접근하기 위한 엔드포인트는 File Cache 마운트 경로의 하위 디렉토리로 표시됩니다. Amazon File Cache와 온프레미스 인프라의 연결은 AWS Direct Connect, Site-to-Stie VPN 같은 기존 네트워크 구성을 그대로 사용합니다.

Amazon File Cache는 최소 1.2 TiB에서 페타 바이트 규모까지 용량을 확장할 수 있으며, 프로비저닝 된 용량에 비례한 성능이 할당됩니다. 캐시 용량이 가득 찬 상태에서 새 데이터를 위한 공간이 필요해지면, 오래 전 사용했던 데이터를 캐시에서 자동 축출하는 방식으로 활성 데이터를 캐시에 유지합니다. Amazon File Cache는 TB-hour 단위로 과금 되며, 클라우드 연산 자원을 사용하지 않는 동안에는 캐시를 중단할 수 있으므로, 고정비 없이사용한 만큼의 비용만 지불할 수 있습니다. 온-프레미스에서 File Cache로 수집되는 데이터 전송에는 비용이 발생하지 않고, 같은 가용영역 내에 위치한 EC2 인스턴스와 캐시 사이의 데이터 I/O에도 비용이 발생하지 않습니다.

실습

본 실습에서는 EC2 가상머신과 데이터 저장소의 직접 연결 구조에서, 고성능 캐시 계층으로 Amazon File Cache를 추가함으로써 성능을 가속하는 시나리오를 가정합니다. 실습 환경 구성의 편의를 위해, 데이터 저장소로는 온-프레미스 파일 시스템 대신 AWS 계정의 프라이빗 서브넷에 배포되는 2개의 Amazon FSx for OpenZFS 를 활용합니다. Amazon FSx for OpenZFS는 NFS 연결을 지원하므로, Amazon File Cache의 원본 저장소로 구성될 수 있습니다.

단계 1에서 3까지 File Cache 구성 과정을 실습한 이후, 단계 4, 5에서 File Cache 활용 방법을 알아봅니다. 모든 실습 과정을 수행하는 데에는 약 1시간이 소요됩니다.

단계1 : 사전 준비

이 단계에서는 CloudFormation 스택을 활용해 사전 구성 인프라를 배포합니다. 아래 버튼을 클릭하면 CloudFormation 콘솔의 스택 배포화면으로 이동합니다.

사전 설정된 파라미터를 유지한 상태로, IAM 리소스 생성 권한을 부여하고 스택을 생성합니다. 스택이 생성되는 데에 약 5-10분이 소요됩니다.
스택 생성이 완료되면, CloudFormation 스택의 Outputs 탭을 확인합니다.  Outputs 탭에는 1) Amazon FSx for OpenZFS 접근 경로를 나타내는 2개의 DNS name과 2) 실습을 위한 EC2 인스턴스 접속 URL이 표시됩니다.

단계2 : Amazon File Cache 구성

단계2에서는 Amazon File Cache를 구성합니다. File Cache를 데이터 소스와 연결하기 위해서는 캐시 생성 단계에서 Data Repository Associations (DRAs)를 설정해야 합니다. 우리는 아래의 실습 과정을 통해 2개의 OpenZFS 파일시스템과 DRA 연결을 구성할 예정입니다. File Cache는 데이터 소스 유형으로 NFS 파일 시스템 또는 S3 버킷(prefix 포함)을 지원하며, 하나의 File Cache에 최대 8개의 DRA를 연결할 수 있습니다. 단, 하나의 File Cache에 두 가지 유형(NFS 및 S3)의 저장소를 함께 구성할 수는 없습니다.

  1. File Cache 구성을 위해 다음 링크의 콘솔로 이동합니다. 그리고 콘솔 우측 상단의 ‘Create cache’ 버튼을 누릅니다.
  2. 캐시 이름을 myfilecache로 하고 용량을 2.4TiB로 지정합니다.
    File Cache의 전송 대역폭은 읽기/쓰기 최고 속도를 의미하며, 용량에 따라 자동으로 설정됩니다. 이 성능 값은 캐시와 클라이언트(애플리케이션) 사이의 연결 뿐만 아니라, 캐시와 원본 데이터 저장소 사이의 연결에도 공유되는 대역폭입니다.네트워크 및 보안 탭에서는 CloudFormation으로 생성된 filecache_Vpc와 filecachesg###을 선택하고, Subnet으로 PrivateSubnet1을 지정합니다.나머지는 기본 값을 유지한 상태로 ‘Next’ 버튼을 누릅니다.
  3. Data Repository Associations 구성에서 File Cache와 OpenZFS 파일시스템을 NFS로 연결합니다.
    아래의 정보를 각 탭에 입력하여, DRA를 구성합니다.

    • Data repository path
      • 소스 파일 시스템의 접근 경로를 nfs://[FSxOpenZFSDNSname1]/fsx/ 형식으로 지정합니다. 온-프레미스의 NFS 파일시스템과 연결할 경우 /fsx/대신 연결 대상 디렉토리 경로를 입력합니다.
      • 위의 경로 형식에서 [FSxOpenZFSDNSname1]는 CloudFormation 스택 Outputs 탭의 FSxZFSDNSname1에 해당하는 값을 참조합니다.
      • NFS 파일시스템 대신 S3 버킷을 File Cache에 연결하려는 경우, s3://[bucket name]/[prefix] 형식을 사용합니다.
    • DNS Server IP addresses
      • NFS 서버의 호스트 이름을 해석하기 위해 접근할 DNS 서버의 IP 주소를 입력합니다.
      • Amazon DNS 서버는 [VPC 네트워크 범위+2]를 IP 주소로 활용합니다. 본 실습 환경의 VPC는 네트워크 범위로 10.0.0.0을 가지므로, DNS 서버 IP 주소는 10.0.0.2입니다.
    • Cache path
      • 데이터 소스를 캐시 하위 디렉토리로 마운트 하기 위한 경로를 지정합니다. 여기에서는 /repo1로 설정합니다.
        위와 같은 형식으로 입력이 완료됐으면, ‘Add’ 버튼을 눌러 저장소를 추가합니다.
  4. 위 작업을 한번 더 반복하여 총 2개의 OpenZFS 파일시스템을 DRA로 연결합니다. 연결이 완료되면 콘솔 하단의 ‘Next’ 버튼을 누릅니다.
    • Data repository path : nfs://[FSxOpenZFSDNSname2]/fsx/
    • DNS Server IP addresses : 10.0.0.2
    • Cache path : /repo2
  5. 마지막으로 입력 정보를 확인한 후 콘솔 하단의 ‘Create cache’ 버튼을 눌러, 캐시 생성을 완료합니다.
    10-15분이 지나면, File Cache가 Available 상태로 변경됩니다.
  6. 데이터 저장소 연결을 확인하기 위해, myfilecache의 Cache ID를 클릭한 다음 ‘Data repositories’ 탭으로 이동합니다.
    이 때, 아래 그림처럼 2개의 연결이 모두 Available 상태로 표시되면 File Cache 구성이 완료된 것입니다.

단계3: EC2 클라이언트의 파일시스템 마운트

이 단계에서는 2개의 OpenZFS 및 1개의 File Cache를 EC2 클라이언트의 로컬 경로에 마운트합니다. 로컬 경로에 File Cache를 마운트 한 이후에는, 일반 파일시스템과 마찬가지로 POSIX 인터페이스로 접근 가능합니다.

  1. CloudFormation Outputs 탭의 ‘Instance ID’ URL을 클릭하여 EC2 인스턴스 연결을 위한 콘솔 화면으로 이동합니다. Session Manager 탭에서 콘솔 우측 하단의 ‘Connect’ 버튼을 눌러 세션에 연결합니다.
  2. 연결된 세션에서 아래 명령어를 입력하여 ssm-user 사용자로 전환합니다. 
    sudo su - ssm-user
  3. 먼저, 데이터 저장소로 활용할 Amazon FSx for OpenZFS 파일시스템을 로컬 경로에 마운트 합니다. 마운트 대상 디렉토리를 구성하기 위해 다음 명령을 입력합니다. 
    mkdir -p datarepo1 datarepo2
  4. 다음 명령어로 로컬 경로의 datarepo1 및 datarepo2에 마운트 합니다. CloudFormation의 Outputs 탭을 확인하여,[FSxOpenZFSDNSname1]과 [FSxOpenZFSDNSname2]에 해당하는 값으로 대체합니다. 
    sudo mount -t nfs -o nfsvers=4.1 [FSxOpenZFSDNSname1]:/fsx/ datarepo1
sudo mount -t nfs -o nfsvers=4.1 [FSxOpenZFSDNSname2]:/fsx/ datarepo2
  5. 파일 시스템 목록의 최하단에 /home/ssm-user/datarepo1 및 /home/ssm-user/datarepo2가 정상 조회되는지 확인합니다. 
    $ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 412K 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
tmpfs 389M 0 389M 0% /run/user/0
/dev/nvme0n1p1 8.0G 1.4G 6.7G 18% /
fs-084286c578d894337.fsx.ap-northeast-2.amazonaws.com:/fsx 64G 0 64G 0% /home/ssm-user/datarepo1
fs-06714b77051bba5c8.fsx.ap-northeast-2.amazonaws.com:/fsx 64G 0 64G 0% /home/ssm-user/datarepo2
  6. 이제 File Cache를 연결할 차례입니다. 우선, File Cache를 마운트 하기 위한 로컬 디렉토리를 생성합니다. 
    mkdir -p filecache
  7. File Cache 콘솔에서 myfilecache를 선택한 후, 우측 상단의 ‘Attach’ 버튼을 클릭합니다.
  8. 팝업 창에 출력된 마운트 명령어를 복사한 다음, 마운트 대상 경로를 /mnt 대신 filecache로 변경합니다.터미널에 입력할 명령어 형식은 다음과 같습니다. 
    sudo mount -t lustre -o relatime,flock fc-0265bdd1f5d70280a.fsx.ap-northeast-2.amazonaws.com@tcp:/76olnbmv filecache

    명령어에는 다음 옵션이 포함됩니다.

    • relatime : 파일 액세스 시점을 기록하는 atime 메타데이터를 사용하되 매번 업데이트 하지는 않고, atime 데이터가 파일의 마지막 수정시점(mtime)과 같고 파일의 액세스 시점이 일정 시간(기본 1일) 지났을 때 atime 데이터를 디스크에 기록하는 정책입니다.  relatime 은 자동 캐시 추출 기능의 정상 작동을 위한 필수 옵션입니다.
    • flock : 캐시를 위한 파일 잠금을 활성화 합니다. 파일 잠금 활성화를 원치 않는 경우, flock 옵션을 제외한 마운트 명령을 사용합니다.
  9. 마운트 된 File Cache 경로를 조회해보면, Data Repository Association 구성에서 지정한 하위 경로(repo1, repo2)가 생성되어 있습니다. 
    $ ls -al filecache
total 98
drwxr-xr-x 5 root root 33280 Feb 14 04:43 .
drwxr-xr-x 2 root root 33280 Feb 14 05:02 repo1
drwxr-xr-x 2 root root 33280 Feb 14 04:43 repo2

단계4 : File Cache 기능 테스트 (Import/Export)

Data Repository Association를 연결하는 시점에 데이터 저장소(예. S3 버킷, NFS)에 존재하던 메타데이터는 캐시에 자동 로드됩니다. 따라서, File Cache를 마운트 했을 때, 파일 목록으로 조회됩니다. 반면, 캐시 생성 이후 데이터 저장소에 업데이트 된 파일과 그 메타데이터는 캐시에 즉각적으로 동기화 되지 않습니다. 그 대신 애플리케이션에서 캐시에 파일 읽기를 요청하면, 파일이 Lazy load 방식으로 불러올 수 있습니다. 아래 실습 과정에서 Lazy load의 동작 방식을 살펴보겠습니다.

  1. 데이터 저장소의 로컬 경로 datarepo1에 10개의 새 파일(test1~test10)을 추가합니다. 
    $ for i in $(seq 1 10); do echo "Testing File Cache" > datarepo1/test${i}; done

    원본 저장소 경로인 datarepo1를 조회하면, 아래와 같이 10개의 파일이 추가되었습니다. 한편, File Cache 경로인 filecache/repo1 에는 파일 목록이 동기화되지 않았습니다.

    $ ls -al datarepo1/
total 54
drwxrwxrwx 2 root root 12 Feb 14 05:20 .
drwx------ 6 ssm-user ssm-user 148 Feb 14 02:47 ..
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test1
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test10
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test2
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test3
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test4
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test5
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test6
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test7
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test8
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test9

$ ls -al filecache/repo1/
total 66
drwxr-xr-x 2 root root 33280 Feb 14 05:21 .
drwxr-xr-x 5 root root 33280 Feb 14 04:43 ..
  1. filecache/repo1에 파일 목록이 조회되지 않더라도, 원본 저장소에 존재하는 파일 경로(ex. filecache/repo/test1)로 데이터에 접근하면 해당 파일을 캐시로 불러오며, 이후에는 파일 목록에도 조회됩니다. 이처럼, 요청에 따라 데이터 저장소와 캐시를 동기화하는 것이 Lazy Load 방법이고, 대부분의 캐시 활용 워크로드에는 Lazy Load 방법이 적합합니다. 
    $ cat filecache/repo1/test1
Testing File Cache
$ ls -al filecache/repo1/
total 66
drwxr-xr-x 2 root root 33280 Feb 14 05:21 .
drwxr-xr-x 5 root root 33280 Feb 14 04:43 ..
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test1

$ cat filecache/repo1/test2
Testing File Cache
$ ls -al filecache/repo1/
total 66
drwxr-xr-x 2 root root 33280 Feb 14 05:27 .
drwxr-xr-x 5 root root 33280 Feb 14 04:43 ..
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test1
-rw-rw-r-- 1 ssm-user ssm-user 19 Feb 14 05:20 test2
  2. 단, Lazy Load는 데이터 접근 시점에 원천 저장소에서 불러오므로, 파일을 처음 읽어올 때 비교적 느린 성능을 발휘합니다. 만약 애플리케이션이 초기(first-byte) 지연시간에 민감하고 접근 패턴을 사전에 파악할 수 있다면, 개별 파일이나 디렉토리를 사전에 File Cache로 불러오는 방법으로 지연시간을 개선할 수 있습니다. 이것이 데이터를 캐시에 Preload하는 방법입니다.
    File Cache에서는 hsm_restore 명령을 활용해 개별 파일을 불러올 수 있고, 파일 컨텐츠가 캐시에 로드 되었는지 확인하기 위해 hsm_action 명령을 사용합니다. hsm_action의 반환 값 NOOP은 파일이 성공적으로 로드 되었음을 의미합니다.

    $ sudo lfs hsm_restore filecache/repo1/test3
$ ls filecache/repo1
test1 test2 test3
$ sudo lfs hsm_action filecache/repo1/test3
filecache/repo1/test3: NOOP
  1. File Cache 내에서 파일이 업데이트 되는 경우에도, 변경 내용이 저장소까지 자동으로 동기화되지 않습니다. 캐시의 변경 내용이 동기화 되지 않은 상태로 저장소 파일에 접근하면, 변경 전의 파일 내용이 남아있습니다. 업데이트 된 파일을 동기화 하기 위해, File Cache에서는 hsm_archive를 통해 데이터 저장소로 내보내고, hsm_state로 확인할 수 있습니다. 상태가 exists archived, archive_id:1로 표시되면 파일이 동기화 된 것입니다. 
    $ echo "Testing File Cache (Modified)" > filecache/repo1/test1
$ cat filecache/repo1/test1
Testing File Cache (Modified)
$ cat datarepo1/test1
Testing File Cache

$ sudo lfs hsm_archive filecache/repo1/test1
$ sudo lfs hsm_state filecache/repo1/test1
filecache/repo1/test1: (0x00000009) exists archived, archive_id:1

$ cat datarepo1/test1
Testing File Cache (Modified)

단계5 : File Cache 성능 확인 실습

이 단계에서는 약 3 GB 크기의 유전자 분석 데이터셋을 활용해서, File Cache  사용에 따른 성능 변화를 실습으로 확인합니다.

  1. AWS 오픈 데이터에서 제공하는 유전자 분석데이터를 로컬 경로의 저장소(datarepo2)에 다운로드 합니다. 다운로드에는 약 3분 정도 소요됩니다. 
    $ aws s3 cp --no-sign-request s3://broad-references/hg38/v0/GRCh38.primary_assembly.genome.fa datarepo2/
  2. 다운로드가 완료되면 파일 목록을 조회하여, GRCh38.primary_assembly.genome.fa 파일을 확인합니다. 
    $ ls -alh datarepo2
total 3.0G
drwxrwxrwx 2 root     root        3 Feb 14 07:14 .
drwx------ 7 ssm-user ssm-user  179 Feb 14 07:00 ..
-rw-rw-r-- 1 ssm-user ssm-user 3.0G Nov  6  2018 GRCh38.primary_assembly.genome.fa
  3. EC2 클라이언트에서 데이터 저장소(OpenZFS)에 보관된 실습 데이터셋을 직접 불러오면서, 시간을 측정합니다.
    데이터를 직접 불러오는 데 걸리는 시간은 원본 저장소 성능에 의존적이며, 최소 용량의 OpenZFS를 활용하는 실습 환경에서 약 30초 소요됐습니다.

    $ sudo mount -o remount,size=4G /dev/shm
$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"
$ time cat datarepo2/GRCh38.primary_assembly.genome.fa > /dev/shm/fsx
real    0m30.433s
user    0m0.016s
sys     0m1.740s
  4. 이번에는 File Cache의 읽기 성능을 확인하기 위해, hsm_restore 명령으로 실습 데이터셋을 캐시에 Preload 합니다. 잠시 뒤, hsm_action 수행 결과로 NOOP이 반환되면 캐시 로드가 완료된 것입니다. 
    $ ls -al filecache/repo2/
total 0
drwxr-xr-x 2 root     root          33280 Feb 14 07:34 .
drwxr-xr-x 5 root     root          33280 Feb 14 06:30 ..

$ sudo lfs hsm_restore filecache/repo2/GRCh38.primary_assembly.genome.fa
$ sudo lfs hsm_action filecache/repo2/GRCh38.primary_assembly.genome.fa
filecache/repo2/GRCh38.primary_assembly.genome.fa: NOOP
  5. 캐시 경로를 대상으로 읽기 작업을 요청합니다. 이번에는 데이터가 이미 캐시에 로드되어 있으므로 캐시의 읽기 성능을 발휘합니다. 캐시를 활용한 실습 환경에서는 약 6초로, 데이터 저장소에 접근하던 30초 대비 대폭 개선되었습니다. 
    $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" 
$ time cat filecache/repo2/GRCh38.primary_assembly.genome.fa > /dev/shm/fsx 
real    0m6.061s 
user    0m0.024s 
sys     0m3.801s

File Cache 사용에 의한 성능 향상은 데이터 셋의 종류, I/O 접근 유형, 데이터 저장소 및 네트워크 대역폭, File Cache에 할당된 용량 등 다양한 변수의 영향을 받습니다. 따라서, File Cache 도입을 고려한다면, 실제 워크로드와 유사한 조건에서 사전 테스트를 수행할 것을 권장합니다.

추가 고려사항

  • 암호화 – File Cache는 데이터의 저장 중 암호화와 전송 중 암호화를 지원합니다. 모든 데이터는 기본적으로 AWS KMS를 통해 상시 암호화 되고, 서비스 소유의 키나 고객 키를 사용할 수도 있습니다.
  • 비용 – File Cache는 별도의 고정비용 없이, 프로비저닝 한 스토리지 용량 및 메타데이터 스토리지 용량에 대한 비용이 청구됩니다. File Cache에서 과금 되는 비용 외에도, 구성 환경에 따라 데이터 전송 비용이 추가로 발생할 수 있습니다. 예를 들어, S3 요청 비용, AWS Direct Connect 비용, AZ/리전 간 네트워크 전송 비용, 인터넷으로 나가는 아웃바운드 트래픽 비용 등이 이에 해당합니다.

리소스 정리하기

이번 게시글에 사용했던 리소스는 향후 불필요한 과금을 예방하기 위해 모두 제거합니다.

마무리

Amazon File Cache는 미디어 및 엔터테인먼트, 금융 서비스, 의료 및 생명과학 등 다양한 산업군에서 클라우드 버스팅과 하이브리드 워크로드를 빠르고 간편하게 수행합니다. 캐시 클라이언트가 여러 위치의 데이터 셋을 통합 네임스페이스로 접근함으로써 아키텍처를 단순화하고, 애플리케이션이 데이터에 액세스할 때 해당 데이터를 캐시에 자동 로드하기 때문에 전체 데이터 셋을 복사하지 않고도 워크로드를 시작할 수 있습니다. 지연시간은 1 밀리 초 미만으로 일정하게 유지되며, 초당 수백 GB의 처리량과 수백 만 건의 작업 처리량으로 워크로드를 더욱 빠르게 완료할 수 있습니다. Amazon File Cache에 대한 더 자세한 내용은 File Cache 공식 문서를 참고하시기 바랍니다.

Kihyeon Myung

Kihyeon Myung

명기현 솔루션즈 아키텍트는 다양한 분야의 엔지니어 경험을 바탕으로, 고객이 AWS 클라우드에서 효율적 아키텍처를 구성하고, 원하는 비즈니스 목표를 달성할 수 있도록 지원하고 있습니다.