끄적이는 보송

S3의 특정 경로에 있는 객체의 byte 단위로 정확한 Total size를 계산할 일이 있었다. 콘솔 환경에서 'Calculate total size'를 찾아 클릭하면 되겠지만 문제는 아래처럼 대략적인 total size만 출력이 된다는 것이다. --recursive --summarize 옵션을 이용하기 이 문제는 summarize 옵션을 이용한 아래의 AWS CLI 명령어로 해결할 수 있다. 아래 명령어로 최종적으로 S3에 있는 객체의 개수와 byte 단위의 크기를 확인할 수 있다. (아마도 콘손 상에 보였던 S3 버킷의 total size는 --human-readable 옵션 값을 출력하여 보여준 게 아닌가 싶다) aws s3 ls "" --recursive --summarize 명령어를 수행하면 ..

Amazon FSx for Windows File Server을 생성할 일이 최근에 있었다. 생성한 FSx를 윈도우 서버에 붙이는 일은 어렵지 않다. FSx 콘솔 화면 우측 상단의 'Attach'를 클릭하면 잘 설명되어 있다. 콘솔 화면에서 가이드 해준대로 아래의 net use 명령어를 사용하면 된다. net use Z: \\\share 위 명령어를 이어 'user name'과 'password'를 입력해주면 FSx에 마운트 할 수 있게 된다. 하지만 분명 계정 ID/PW 전부 맞는 것을 확인했고 아무리 시도를 해보아도 network password is not correct라는 오류를 반환했다. 네트워크적인 이슈라면 계정의 오류보단 네트워크 관련 오류 메시지를 뱉어냈을 텐데 이상했다. 문제 해결 알고 ..

실시간으로 쌓이는 로그를 모니터링을 할 때 'tail -f '을 즐겨 사용했다. 그러다 문뜩 떠오른 생각이 있었는데... "실시간으로 쌓이는 로그에 Line Number도 같이 출력할 수 없을까? 실시간으로 쌓이는 로그에 오류가 발견되면 꼭 ctrl+c를 누르고 나가서 확인해야 할까? " 라는 생각에 찾아본 명령어가 이거다. less -N + F 이 명령어라면 실시간으로 출력되는 로그와 함께 아래 예시처럼 Line Number도 같이 출력된다고 한다. 그리고 도중에 오류가 발견되면 'ctrl + c'를 실행하여 잠시 추가되는 로그를 중지할 수 있고, 무엇이 잘못됐는지 확인되면 다시 '대문자 F'를 실행하여 실시간 로그를 실행하여 계속 이어갈 수도 있다. 또한 'less -N + F' 명령어는 기본적으로 ..

데이터 중복 제거란 (Data Deduplication) Amazon FSx for Windows File Server(이하 FSx)에 데이터 중복제거(Data Deduplication)이라는 기능이 제공된다. 데이터 중복제거란 혹은 줄여서 Dedup은(이하 중복제거) 데이터의 중복되는 복사본을 제거하고(고유하게 만들어) 스토리지 용량을 크게 줄일 수 있는 기능이라고 한다. FSx에서 제공되는 기능이지만 AWS의 기능이 아닌 Microsoft 사의 기능이라고 한다. 데이터 중복 제거 작동 방식 우선 데이터 중복 제거는 아래와 같은 순서로 동작한다. 1. Data Deduplication chunking algorithm이 중복 제거 대상이 되는 파일 시스템 파악 2. 파일을 청크(Chunk) 단위로 쪼개..

여러 파일을 CLI 명령어로 S3에 한 번에 옮기려 했으나, 내 예상과는 달리 "*"(아스타리스크)가 먹히지 않아 당황스러웠었다 (ex. s3 cp ). S3 CLI 명령어에는 파일과 폴더를 재귀적으로 처리하는 옵션이 있으며, "--recursive", "--exclude", "--include" 옵션을 활용해 여러 객체에 명령어를 수행할 수 있다. 이참에 S3 CLI 명령어로 여러 객체에 수행할 수 있는 것을 정리해볼까 한다. 예를 한번 들어보면서 시작해 보겠다. S3 버킷에 있는 모든 객체 로컬로 다운로드 aws s3 cp s3:/// ./ --recursive S3 버킷에 있는 모든 객체를 로컬 시스템의 현재 경로로 복사를 하겠다는 명령어다. 만약 해당 버킷에 폴더가 있다면, 복사 대상의 경로에도 ..

오늘은 깊게 분석할 것 없이 아래의 간단한 실습을 해볼 생각이다. 1. CloudTrail 생성 및 로그가 S3에 쌓이도록 구성 2. S3에 쌓인 로그 파일을 Athena로 분석하기 굳이 CloudTrail 로그를 S3에 올리는 이유는 CloudTrail의 최대 로그 보존 기간이 90일이기 때문이다. 그 이전의 데이터는 유지하지 않기에 간혹 과거의 데이터를 조회하지 못해 난감한 경우가 있었다. (누가 어떤 작업을 했는지, CreateInstance 로그 등등) 또한 로그 파일이 쌓이다 보면 일일이 수많은 파일을 열어 확인해야 하는 번거로움이 있는데 이를 Athena를 활용해 쿼리를 날려 내가 원하는 데이터를 추릴 수 있다. 오늘은 이 실습을 해보려 한다. 1. CloudTrail 생성 및 로그가 S3에 ..

AWS의 어떤 서비스는 이름 앞에 'Amazon'이 붙는가 하면, 어떤 서비스는 'AWS'가 붙는다. 별생각 없이 이용해 왔지만 도대체 무슨 차이가 있길래 이름이 다른 걸까? AWS를 다룬다면 한 번쯤 의미는 알아둬도 좋을 것 같다. AWS와 Amazon의 이름 차이 'Amazon' 은 단독으로 실행 가능한 서비스에 붙는 이름이고, 'AWS' 는 다른 서비스의 유틸리티 서비스로 쓰이는, 즉 혼자서는 쓸 수 없는 서비스에 붙는 이름이다. 그러하다.

Instance Metadata (IMDS) 란 Instance Metadata란 실행 중인 인스턴스를 구성하거나 관리하는데 사용되는 인스턴스에 대한 데이터를 의미한다. 당연하게 EC2를 생성하고 생각 없이 사용해 왔지만 사실 EC2는 그저 가상화한 하드웨어의 조각일 뿐, 자신이 EC2인지 클라우드에 올라간 서버인지 모른다. EC2를 생성하게 되면 해당 EC2는 자동으로 Metadata와 연결되어 정보를 얻고, 서비스를 제공한다고 생각하면 된다. EC2 생성 시, 디폴트로 생성하면 Metadata는 '선택'에 놓여있으며, 별도의 수정이 아니라면 해당 EC는 IMDS v1, v2를 모두 사용하게 된다. 아래 이미지는 EC2 생성 시, '고급 세부 정부'에서 확인할 수 있다. Metadata와 Userdat..