AWS를 이용하여 파일 서버
AWS에 파일서버를 두는 기업들이 있다. 파일 서버는 클라이언트가 되는 업무 시스템이나 사용자에 의해 설계 패턴이 크게 달라지는 것이 특징이다. 보통 파일 서버는 문서를 공유하거나 업무 시스템에서 파일 저장, 데이터 연계용으로도 사용한다. 단순 파일 저장뿐 아니라 접근 관리를 포함한 콘텐츠 관리 기능도 요구되는 경우도 있다.
인프라 설계 사항
1. 앱에서 EFS를 파일 서버로 사용
2. 스토리지 게이트웨이로 저장소를 자동 계층 관리
3. 워크독스로 파일공유
제약이 많은 S3
보통 AWS 환경의 시스템을 사용하여 파일서버로 사용하면 S3를 이용하는 방법과 EFS를 이용하는 방법이 있다. S3는 비용이 저렴하고 간편하게 구축할 수 있으며 내구성이 높아 일반적인 기업이라면 다중화를 할 필요가 없으며 조작 실수에 의한 파일 손실만을 대비하여 백업을 잘 해두면 된다. 하지만 오브젝트 스토리지기 때문에 파일 서버로 사용하려면 서비스 특징이 시스템 요구 사항을 만족시키는지 여부를 반드시 확인해야 한다.
첫번째. 프로그램이 파일로 접근하려면 REST API를 사용해야한다.
HTTP/HTTPS로 접근하기 때문에 일반적인 NFS보다 응답이 느리다. 환경이나 파일 크기 나름이지만 응답시간은 차이가 매우 크기 때문에 사전에 확인해보는 것이 좋다. 또한 앱에서 사용하는 언어에 제약이 있거나 반드시 파일 시스템에 접근하도록 설계되어 있다면 REST API를 사용하지 못할 가능성도 존재한다. 이경우 s3fs를 사용하여 가상의 네트워크 드라이브로 마운트하여 NFS처럼 사용가능하도록 할 수 있다. 물론 이 마저도 결국 HTTP/HTTPS로 이루어 지므로 응답은 느리다.
두번째. 파일에 대한 배타적인 접근 제어 불가능
파일에 대한 배타적인 접근 제어를 할 수 없다. 애플리ㅔ이션이 파일 시스템의 배타적 접근 제어에 의존하도록 만들어져 있는 경우에는 적합하지 않다.
세번째. S3 업데이트가 최종 일관성 모델로 동작한다는 점
S3는 스토리지의 고장 등으로 데이터가 손상되지 않도록 물리적으로 복수 복사본을 가지는 분산 파일 시스템이다. 파일을 갱신하면 복사본 중 하나가 업데이트 되며 시간에 따라 다른 복사본도 업데이트 되어간다. 업데이트 직후에 참조하게 된다면 이전 데이터가 반환될 가능성이 존재한다. 이러한 특징 때문에 여러 프로세스를 동시에 읽고 쓰는 앱은 의도치 않은 업데이트 결과를 얻을 수 있다.
EFS를 NFS서버로 이용
S3의 요구사항이 맞지 않는다면 EFS를 이용하여 파일서버로 사용한다. EFS는 관리형 파일서버로 NFS 프로토콜을 지원하여 리눅스와 연결하여 사용할 수 있다. 윈도우의 경우 Amazon FSx for Windows File Server를 이용하여 파일 서버를 구축한다. 리눅스에서 NFS 마운트를 사용하게 되면 공유 스토리지, 파일 서버등 다양한 용도로 사용 가능하다. NFS를 이용해 많은 앱을 그대로 실행할 수 있으며 기존 시스템을 AWS로 마이그레이션하면 변경을 최소화할 수 있다.
EFS는 액세스 권한관리, 동시접속, 읽기 일관성과 같은 NFS의 일반적인 특성을 갖추고 있으며 S3는 읽는 동안 파일을 잠글 수 없지만 EFS에서는 읽기 시점만 같다면 여러 클라이언트에서 동일 데이터를 읽어오는 것이 보장되며 파일 잠금 기능도 사용 가능하다. 관리형 서비스로 제공되므로 가용성이나 용량 확장,축소 관리가 필요없다. I/O 응답속도는 S3보단 빠르지만 EBS보단 느리다. 더 빠른 응답속도를 원한다면 EBS를 사용하는 것이 적합할 수 있다.
EFS의 마운트, 이용패턴
EFS를 설정하면 앱과 마운트할 대상이 VPC내에서 만들어진다. 마운트 대상은 IP 주소와 도메인 명을 가지고 있어 EFS를 마운트할 때 둘중 하나를 사용한다. 파일 시스템은 최초에 생성된 VPC에서만 접속할 수 있으며 여러 VPC로부터 동시에 접속할 수 없다.
EFS를 이용할때 가장 먼저 파일시스템과 클라이언트가 설치되는 네트워크를 설계한다. 파일시스템을 이용하는 가용 영역에 마운트 타겟이 위치할 서브넷을 설정하고 반드시 필요한 통신만 통과하도록 NACL을 설정한다. 클라이언트가 위치할 가용영역 전체에 마운트 타겟을 하씩 작성한다. 클라이언트는 마운트 타겟을 NFS 마운트하여 파일 시스템에 접근할 수 있다.
만일 같은 가용영역에 마운트타겟이 작성되어 있다면 EC2에서도 이용가능하다. 다른 가용 영역에 위치한 마운트에 접속하는 것도 가능하지만 반응 속도가 커지게 된다. 마운트 타겟의 작성에는 비용이 발생하지 않으며 클라이언트와 같은 가용 영역에 마운트 타겟을 작성하여 접속한다.
- EFS는 반응속도가 느리기때문에 고성능이 요구되는 DB저장소에는 적합하지 않다.
스토리지 게이트웨이로 계층형 스토리지 구축
온프레미스 환경에서 파일서버, 저장소의 크기가 커져 비용에 관련된 문제를 겪고 있는 기업이라면 스토리지 게이트웨이를 이용해 계층형 스토리지 구축하는 것이 좋다. 스토리지 게이트 웨이는 온프레미스의 저장소와 AWS환경의 스토리지를 연계시키는 기능을 제공해준다. 이는 VMware ESXi나 Hyper-V와 같은 하이퍼 바이저에서 동작하는 가상 머신 형태로 제공된다. 도입하려면 온프레미스 환경에 하이퍼 바이저를 인스톨한 서버와 가상머신이 사용할 스토리지가 필요하며 이 스토리지를 사용하여 캐시 볼륨을 작성, 연계 대상인 S3 버킷을 지정하면 파일 자동 계층화 관리가 시작된다.
게이트웨이 캐리 볼륨을 이용하면 S3 버킷에 모든 파일을 저장한다. S3는 응답속도가 느려서 이용 빈도가 높은 파일은 복사본을 온프레미스 환경에서 캐시한다. 스토리지 게이트웨이가 자동으로 판한해서 관리하기 때문에 별도로 캐시할 파일을 지정하거나 관리정책을 작성할 필요는 없다.
스토리지 게이트웨이에 접속하는 업무 시스템은 iSCSI볼륨으로 캐시된 볼륨을 마운트한다. 이렇게 하면 S3에 업로드하고 있던지, 파일을 캐시중이던지 신경쓰지 않고 사용할 수 있다. 업무 시스템에서 파일 참조에 대해 캐시된 파일은 캐시스토리지가 대응한다. 캐시에 존재하지 않는다면 S3가 캐시스토리지에 파일을 전송하고 응답한다.
스토리지 게이트웨이 캐시 볼륨모드는 확장이 용이하고 소유 비용이 저렴하다. 이러한 소유 비용을 줄이는 방안은
첫번째. 온프레미스 환경 스토리지 크기를 작게한다.
두번째. 마스터 데이터를 비용이 낮은 S3에 둔다.
세번째. S3로부터 데이터 통신량을 억제한다.
가 있다.
하지만 주의해야할 것은 응답 속도이다. 고빈도 접근파일은 응답속도가 보장되지만 사용 빈도가 낮은 파일은 S3에서 전송된 이후에 접근이 가능하므로 응답속도가 매우 떨어진다.
전용선을 이용하여 안정성, 보안 확보
스토리지 게이트웨이를 이용하려면 온프레미스와 AWS를 연결하는 통신 회선이 필요하다. 암호화 하더라도 인터넷으로 중요 정보를 전송하는 것 자체를 금지하는 보안 규정을 지닌 기업도 많고 인터넷 품질이 불안정한 기업도 많다. 이러한경우 AWS 다이렉트 커넥트 서비스를 이용하면 문제를 해결할 수 있다.
워크독스에서 파일공유
사용자 간 파일 공유에는 역활에 따라 권한을 제한하는 관리 기능이 필요하다. 온프레미스 환경에서는 액티브 디렉터리를 사용하여 권한을 관리하는 기업이 많다. 이와 비슷한 구성으로 AWS환경에서는 워크독스라는 서비스를 제공한다. 워크 독스는 업무용 파일 공유 서비스이며 완전 관리형이기 때문에 인프라를 설계할 필요가 없다.
아마존 워크독스를 이용하려면 콘솔에서 서비스를 개시하여 관리화면에서 원하는 관리작업을 하면 된다. 관리자는 사용자에게 파일이나 폴더 단위로 권한을 부여할 수 있다. 심플 AD를 이용하여 로그인 인증을한다. 여기서 심플 AD는 워크독스와 세트로 구성되있기 떄문에 별도의 설정을 하지 않아도 연동이 된다.
워크독스는 서울리전을 지원하지 않는다.
