Nirsa

※ 해당 포스팅은 인스턴스에서 실수로 OS 방화벽을 Enable하여 발생한 경우에 한합니다.

인스턴스 "포트 22에서 VM에 연결할 수 없습니다." 해결 방법
(GCP Instance Unable to connect on port 22)

1. 인스턴스 세부 정보 → 수정

인스턴스 세부 정보는 Google Compute Engine 에서 인스턴스 이름을 클릭하면 들어갈 수 있습니다.

2. 메타 데이터 startup-script

아래로 내리다보면 "맞춤 메타데이터"가 있습니다. 아래 사진과 같이 키에 startup-script를 입력한 후 값에 sudo ufw disable을 입력 해주시면 됩니다. (우분투 기준) 이후 "저장"을 클릭 해주세요.

3. 인스턴스 재시작

인스턴스를 중지한 후 다시 시작을 눌러 주시면 됩니다.

인스턴스가 바로 실행 되었다고 해서 바로 접속은 안되고 SSH가 올라갈 때 까지 시간이 소요 됩니다. 약 3~5분 후 SSH 접속을 시도하면 정상적으로 접속이 가능 합니다.

• AWS S3 버킷 생성/파일 업로드/삭제 

AWS S3 버킷은 쉽게 생각하여 객체 스토리지 시스템으로, 평면 저장소에 데이터를 저장하는 스토리지 서비스 입니다. S3 서비스 종류에 따라 차이가 있으나 AWS S3의 내구성과 가용성은 최소 99.99% 이상을 자랑 합니다.

즉, S3라는 AWS가 제공하는 스토리지 서비스를 이용할 경우 저장된 데이터 손실률은 없다고 봐도 될 정도로 내구성 및 가용성은 최상으로 되어 있습니다. 

해당 포스팅에서는 AWS S3 버킷의 생성, 파일 업로드, 삭제하는 방법에 대해 작성 되며 테스트를 위해 퍼블릭 액세스를 기준으로 작성되기 때문에 참고해주시길 바랍니다. 버전관리 및 수명주기관리 등은 추후 포스팅에서 다룰 예정 입니다.

• 1) AWS S3 버킷 생성

• 1-1) AWS 콘솔 로그인을 하여 AWS Management Console의 스토리지 → S3를 클릭 합니다.

• 1-2) 아래 화면에서 "버킷 만들기"를 클릭 해주세요.

• 1-3) 버킷의 이름과 리전을 선택할 수 있습니다. 버킷 이름을 작성 하고, 리전은 초기 설정으로 진행 하겠습니다.

• 1-4) 저의 경우 테스트 용도로 버킷을 생성하고 테스트 후 바로 삭제할 예정이기에 퍼블릭 액세스를 허용하도록 설정을 하였습니다. 액세스 허용을 한 후 하단의 "버킷 만들기"를 클릭 해주세요. (하단의 버킷 버전관리, 태그 등은 추후 포스팅할 예정이며 기본 설정으로 해두겠습니다)
• 실무에서 사용해야할 경우 퍼블릭으로 데이터를 제공해야되는 경우가 아니라면 서비스 환경에 맞춰 "모든 퍼블릭 액세스 차단" 또는 ACL을 이용해 액세스를 차단해주는것이 좋습니다.

• 1-5) 아래와 같이 버킷이 생성되었습니다.

• 2) AWS S3 버킷에 파일 업로드 및 확인하기

• 2-1) 아래 화면에서 버킷의 이름을 클릭해 접근 해주세요.

• 2-2) 바탕화면에 "AWS S3 test.txt" 메모장 파일을 생성하여 그 안에 아무 내용이나 적어준 후, 파일을 드래그 앤 드롭(끌어놓기) 해줍니다.

• 2-3) 파일을 끌어다 놓으면 아래와 같은 화면으로 넘어가질텐데, 저는 별도의 설정을 하지 않고 파일을 업로드 하겠습니다. (우측 하단의 파일 업로드 클릭)

• 2-4) 파일을 업로드하게 되면 아래 스샷과 같이 파일이 생기는것을 확인할 수 있습니다. 이 파일(객체)의 이름을 클릭하여 객체 URL을 복사 후 웹브라우저에 붙여넣기 해봅시다.

• 2-5) 아래와 같은 화면이 출력될텐데, 퍼블릭 객체로 생성하기 위해서는 사용자 권한을 변경 해주어야 합니다.

• 2-6) 2-4에서와 같이 객체의 이름을 클릭 후 드래그를 조금 내리다보면 아래와 같이 ACL 정책을 설정할 수 있는 필드가 있습니다. 편집을 누른 후 퍼블릭 액세스에 읽기 권한을 부여해주고 하단의 "변경 사항 저장"을 클릭하여 설정을 저장 해주세요.

• 2-7) 이후 다시 웹브라우저에 URL을 입력하면 파일을 읽으면서 메모장에 적었던 내용을 확인할 수 있습니다.

• Q. AWS S3 버킷 생성 시 "모든 퍼블릭 액세스 허용"을 했는데 왜 객체에서 다시 권한을 설정해주어야 하나요?

상단의 1-4와 2-6을 보면 1-4에서는 S3 버킷 생성 시 모든 퍼블릭 액세스 허용으로, 2-6에서는 또 다시 객체의 권한을 설정 합니다.

이렇게 설정 해주어야하는 이유는 버킷을 선택 후 액세스 부분을 클릭하면 친절히 설명이 나와 있습니다. 만약 버킷을 생성할 때 "모든 퍼블릭 액세스 차단"으로 한다면 해당 버킷의 모든 객체는 객체 권한과는 상관 없이 퍼블릭 액세스로 설정이 불가능 합니다.

이미 객체가 퍼블릭 액세스로 되어있는 상태에서, 버킷에 "모든 퍼블릭 액세스 차단"으로 변경 한다면 퍼블릭 액세스로 되어있는 객체는 퍼블릭 액세스 권한이 자동으로 소멸하여 프라이빗으로 변경 됩니다.

• 3) AWS S3 버킷 삭제

• 3-1) AWS S3 버킷을 삭제하기 위해서는 먼저 객체를 삭제 해주어야 하기 때문에 버킷의 이름을 클릭하여 객체 삭제를 진행 해주세요.

• 3-2) 3-1에서 객체를 모두 삭제 했다면, 버킷으로 돌아와 삭제할 S3 버킷을 선택 후 삭제를 눌러 진행 해줍니다.

• 3-3) 아래와 같이 정상적으로 버킷이 삭제된것을 확인할 수 있습니다.

• AWS EC2 Instance 생성하는 방법

• 1) 메뉴 들어가기

AWS 홈페이지(aws.amazon.com/ko/)에 접속 후 로그인하여 AWS 관리 콘솔(AWS Management Console)의 전체 서비스 → 컴퓨팅 → EC2를 클릭 합니다.

EC2 대시보드에서 좌측의 인스턴스를 클릭 해주세요.

우측 상단의 인스턴스 시작을 클릭 합니다.

• 2) 아마존 머신 이미지(AMI) 선택하기

AMI는 여러가지 이미지들이 있는 곳 입니다. 사용하고 싶은 이미지를 선택하면 되고, 저는 가장 상단에 있는 Amazon Linux 2 AMI을 선택 하였습니다.

* 추후 AMI에 대해 포스팅하게 될 때 자세히 다룰것이며 좌측의 메뉴들이 어떠한 것들인지만 간단히 설명하고 넘어 가겠습니다. 

1. 빠른 시작 : AWS에서 제공되는 기본 이미지들이 있습니다.
2. 나의 AMI : 사용자 정의 AMI로써 직접 생성한 이미지를 만들어 사용할 수 있습니다.
3. AWS Marketplace : 이름 그대로 여러 이미지들을 돈을 주고 쇼핑할 수 있는 공간이라고 보셔도 됩니다. 보통 소프트웨어 가격까지 포함되어 시간당 금액이 청구 됩니다.
4. 커뮤니티 AMI : 다른 사용자들이 공개용으로 생성한 이미지들을 사용할 수 있습니다. AWS측에서는 이러한 AMI들의 무결성과 보안성을 보장하지 않는다고 하니 사용 시 주의가 필요합니다.

• 3) 인스턴스 유형 선택 및 생성 하기

여러가지 인스턴스 유형들을 선택할 수 있습니다. 자신의 환경에 맞는 유형을 찾아 생성해야하고, 저같은 경우 프리티어로 이용중이기 때문에 t2.micro를 선택 하였습니다.

필요에 따라 좌측 상단의 "인스턴스 구성", "스토리지 추가", "태그 추가", "보안 그룹 구성" 등을 선택하여 필요한 부분을 수정하여 사용하면 됩니다.

저는 단순 테스트 용으로 사용할것이기 때문에 더이상의 설정은 필요 없어서 우측 하단의 "검토 및 시작"을 눌러 스킵 하였고, 검토 단계에서 "시작하기"를 눌러 주었습니다.

• 4) 키 페어 생성하기

안전한 SSH 연결을 위해 키페어를 생성하라고 나옵니다. 처음인 경우 "새 키 페어 생성"을 누른 후 키 페어 이름은 임의로 작성 후 "키 페어 다운로드"를 눌러 주면 우측 하단의 "인스턴스 시작" 버튼이 활성화 되니 클릭하여 인스턴스를 생성 해줍니다.

* 키 페어는 추후 인스턴스에 SSH 연결을 할 때 필요하기 때문에 잘 보관하고 있어야 합니다.

• 5) 인스턴스 생성 확인

키 페어 생성 후 인스턴스를 시작 했다면 아래와 같은 화면을 볼 수 있습니다. 우측 하단의 "인스턴스 보기" 버튼을 클릭하면 인스턴스 메뉴로 다시 넘어가지면서 실행중 상태인것을 확인할 수 있습니다.

• IBM 클라우드 오브젝트 스토리지의 특징

1. 파일 시스템이 아님 (디렉토리 구조가 없음)
2. 블록 스토리지가 아님 (디스크처럼 보이지 않음)
3. 데이터가 BUCKETS에 저장됨
4. 데이터는 메타 데이터 및 고유 식별자와 함께 객체로 저장

• IBM 클라우드 오브젝트 스토리지를 사용하는 이유

1. 효과적으로 무제한 저장 (쉽게 확장 또는 축소가 가능)
2. 대량의 비정형 데이터 저장 및 검색
3. 대용량 데이터 세트, 백업 및 아카이브 파일 등에 자주 사용
4. 성능이 저하되는 경향이 있으므로 자주 액세스하는 데이터/고성능 액세스에 적합하지 않음

• IBM 클라우드 오브젝트 스토리지 계층 (ibm cloud object storage archive tier)

위와 같은 이유들로 인해 여러가지의 스토리지 계층이 존재하고, 어떤게 가장 나의 환경에 잘 맞는지 파악해야 합니다.

데이터 보호를 요구하는 복구 옵션이 필요한지, 클라우드 안팎으로 빠르게 데이터 이동이 필요한지, IBM SQL Query를 사용한 데이터 쿼리가 필요한지 등이 대표적인 예입니다.

IBM 클라우드의 오브젝트 스토리지 계층은 Standard, Vault, Cold Vault, Flex 총 4가지로 구분이 됩니다.

스토리지 계층의 핵심은 액세스가 얼마나 자주 발생하는지에 따라 나눠집니다.  아래는 좀 더 보기 쉽게 IBM Cloud에서 테이블 형태로 제공해주는 내용 입니다.

또한 오브젝트 스토리지에 대해 3가지의 복원성 옵션을 제공 하는데 교차 지역(Cross-Region), 지역(Regional), 단일 데이터 센터(Single Datacenter)가 있습니다. 3가지의 복원성 옵션을 쉽게 보자면 아래와 같습니다.

1. 교차 지역(Cross-Region) : 근처 국가의 최대 3개 지역에 저장됩니다. (AP Cross-Region의 경우 Hongkong - Tokyo - Seoul)
2. 지역(Regional) : Regional 내의 여러 데이터 센터 시설에 저장 됩니다. (아시아의 경우 Regional JP-TOK)
3. 단일 데이터 센터(Single Datacenter) : 하나의 데이터 센터 내의 여러 디바이스에 저장 됩니다.