saii 잡다한 블로그

콘솔에서 다운로드 하려고 했는데 폴더로는 다운로드가 안되어 CLI를 사용하여 버킷을 다운로드 해보는 방법을 포스팅해보았다. 생각보다 어렵지않다. 리눅스 명령어가 가능하다.

아래처럼 aws s3 명령어 URL 해주면됩니다.

aws s3 sync s3://버킷/객체 ./저장하려는 폴더명
aws s3 sync s3://Test ./TEST

https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/userguide/accessing-an-object.html

PowerShell이나 명령 프롬프트를 D 드라이브로 변경하려고 하면 명령어가 안되서 당황할 수 있다.

한번에 변경하려는 풀주소를 입력하면 안된다.

우선 바꾸려는 드라이브로 변경 후 cd 명령어로 이동하면된다.

PowerShell이랑 명령프롬프트(cmd)가 좀 다르다.

PowerShell의 경우

1. cd D:(원하는 폴더명)

2. Set-Location -Path D:\(원하는 폴더명)

명령프롬프트(cmd)

1. D:     << 그냥 이렇게만 쳐야 됨

CLI를 사용하기 위해선 자신이 사용중인 프롬프트를 자격증명을 해야합니다.

아래의 명령어를 해보면 이미지처럼 나올겁니다.

aws configure list

아래 내용들을 따라하면 추가됩니다.

aws configure

Access Key ID 와 Secret Access Key는 IAM 에서 사용자 추가할 때 같이 생성된 것을 넣어주고 region은 자기가 사용하고 있는 곳을 입력해주면 된다.

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html

CLI를 무사히 설치 했다면 CLI에서 사용할 서비스들이 있을 것이다.

근데 우선 그 서비스를 CLI에서 사용하기 위해서 자격증명이란게 필요하다.

쉽게 말해 CLI 환경에서 AWS 로그인을 한다고 생각하면 될 것 같다. 

그게 바로 IAM 이다.

1. AWS 콘솔 로그인 후 IAM 대시보드

2. 대시보드 왼쪽 메뉴에서 액세스 관리 > 사용자 > 사용자 추가 

3. 이름 설정 후 우선 액세스 키만 선택합니다.

4.권한 설정 에서 그룹 생성

5. 그룹 이름 입력 후 필요한 정책을 선택합니다. (TEST를 위해서 전체 권한 설정하겠습니다. - AdministratorAccess)

6. 다시 사용자 추가 화면에서 생성한 그룹 체크 후 쭉 다음 클릭하면 사용자 생성 성공

아래 처럼 나오면 성공입니다. 

추후 CLI Configure에서 꼭 사용되니 액세스 키 ID 와 비밀 액세스 키를 저장해줍니다. 꼭 저장하세요.

https://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/getting-started_create-admin-group.html

회사에서 쓰던 AWS 서비스를 다 정리하라고 한다.

서버를 다 구축 했기 때문에 굳이 돈 내면서 쓰지 않겠다고 한다.

우선 CLI 설치를 해보자. 하는 이유는 나중에 나온다.

버전1을 사용했는데 에러가 났는데 버전2에서 사용하라고 해서 버전2를 사용한다. 아래는 AWS 공식 문서다.

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

PowerShell로 해도 되고 명령프롬프트로 해도 된다.

일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다. 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

세션 특징

웹 서버에 클라이언트의 정보를 저장한다.

웹 서버의 저장되는 쿠키(=세션 쿠키)

브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되므로, 쿠키보다 비교적 보안이 좋다.

각 클라이언트에 고유 Session ID를 부여한다. 

세션의 동작 방식

클라이언트가 서버에 로그인 요청을 한다.

서버는 로그인 요청의 유효성을 확인하고 session-id를 response 헤더에 추가하여 응답한다.

클라이언트는 session-id를 저장해놓고 추후 재요청시 포함하여 사용한다.

사용 예시

다른 화면으로 이동해도 로그아웃이 되지않고 로그아웃하기 전까지 유지된다.

쿠키와 세션 차이점

저장위치

  - 쿠키는 클라이언트, 세션은 서버에 저장

보안

 - 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높다.

라이프사이클

 - 쿠키는 브라우저를 종료해도 파일로 남아있지만, 세션은 브라우저 종료되면 만료기간과는 상관 없이 삭제한다.

속도

 - 쿠키가 우세하다. 쿠키는 파일에서 읽고, 세션은 요청마다 서버에서 세션 저장소에서 찾아서 처리해야 한다.

 HTTP 쿠키는 웹 쿠키, 브라우저 쿠키로도 불리는데 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각을 의미한다. 쿠키는 주로 세션 관리(서버에서 관리하는 로그인 등의 정보를 의미), 개인 설정유지, 사용자 트래킹 용도로 사용된다.

쿠키는 브라우저를 끄게 되면 삭제되는 방식과 지정된 날짜에 삭제되는 방식이 있다.

쿠키 특징

1. 이름, 값, 만료일(저장기간), 경로 정보로 구성되어 있다.

2. 클라이언트에 총 300개의 쿠키를 저장할 수 있다.

3. 하나의 도메인 당 20개의 쿠키를 가질 수 있다.

4. 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.

쿠키 작동 방식

1. 클라이언트가 서버로 HTTP 요청을 하면 서버에서는 HTTP Header에 쿠키를 담아서 Response를 보낸다.

2. 클라이언트는 Response를 받아 쿠키를 저장한다. 

3. 클라이언트가 서버에 재요청을 할 때 쿠키를 같이 포함하여 전송한다.

4. (만약 쿠키가 업데이트 됐다면) 서버에서 Response를 보낼 때 업데이트 하여서 보낸다.

사용 예시

1. 방문 사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"

2. 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크

범용 고유 식별자는 소프트웨어 구축에 쓰이는 식별자 표준으로, OSF에서 분산 컴퓨팅 환경의 일부로 표준화 하였다. 주로 분산 컴퓨팅 환경에서 사용되는 식별자이다. 

UUID는 총 36개의 문자열(32개 문자와 4개의 하이픈)으로 구성되어 있고, 8-4-4-4-12 의 자릿 수로 구성되어 있다.

> 9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d

버전마다 특정 자리와 특정 문자(Version, Variant Field)에는 의미가 있다고 하는데 공부하다보니 내가 굳이 거기까지 기억할 필요는 없는 것 같다.

고유 식별자로 사용되지만 꼭 중복 될 확률이 0%는 아니다. 다만 0%에 수렴할 뿐이다. 그렇기 때문에 단일로 PK키로 사용하진 말아야 할 것 같다. 

UUID의 버전은 1~5 까지 있는 것 같고, 대부분의 개발자들이 많이 쓰는건 v4 인듯 하다.

  - 버전 1 (시간 + MAC 주소)

  - 버전 2 (시간 + DCE 보안)

  - 버전 3 (시간 + MD5 해시)

  - 버전 4 (시간 + 랜덤)

  - 버전 5 (시간 + SHA-1 해시)

UUID의 장점

 - UUID가 생성할 수 있는 340,282,366,920,938,463,463,374,607,431,768,211,456개의 키를 생성할 수 있기 때문에 중복은 쉽지 않다.

 - 연속성이 없기 때문에 데이터를 유추하기 어렵다.

UUID의 단점

  - 연속성이 없기 때문에 Indexing을 할 때 성능 저하 및 시간과 자원을 더 사용하게 된다.

  - 보통의 순차증가키보다 공간을 더 많이 차지한다.

https://ko.wikipedia.org/wiki/%EB%B2%94%EC%9A%A9_%EA%B3%A0%EC%9C%A0_%EC%8B%9D%EB%B3%84%EC%9E%90

https://www.rfc-editor.org/info/rfc4122