ref : http://www.awskr.org/fb-post/load-balancer%E...

4 Bash If Statement Examples(If then fi, If then else fi, If elif else fi, Nested if )

if 문 예제

Bash conditional statements perform different computations or actions depending on whether a programmer-specified boolean condition evaluates to true or false. These statements are used to execute different parts of your shell program depending on whether certain conditions are true. The ability to branch makes shell scripts powerful.

In Bash, we have the following conditional statements:

1. if..then..fi statement (Simple If)
2. if..then..else..fi statement (If-Else)
3. if..elif..else..fi statement (Else If ladder)
4. if..then..else..if..then..fi..fi..(Nested if)

These are similar to the awk if statements we discussed earlier.

1. Bash If..then..fi statement

if [ conditional expression ]
then
	statement1
	statement2
	.
fi

This if statement is also called as simple if statement. If the given conditional expression is true, it enters and executes the statements enclosed between the keywords “then” and “fi”. If the given expression returns zero, then consequent statement list is executed.

if then fi example:

#!/bin/bash
count=100
if [ $count -eq 100 ]
then
  echo "Count is 100"
fi

2. Bash If..then..else..fi statement

If [ conditional expression ]
then
	statement1
	statement2
	.
else
	statement3
	statement4
	.
fi

If the conditional expression is true, it executes the statement1 and 2. If the conditional expression returns zero, it jumps to else part, and executes the statement3 and 4. After the execution of if/else part, execution resume with the consequent statements.

if then else fi example:

#!/bin/bash
count=99
if [ $count -eq 100 ]
then
  echo "Count is 100"
else
  echo "Count is not 100"
fi

Note: This article is part of the ongoing Bash Tutorial series.

3. Bash If..elif..else..fi

If [ conditional expression1 ]
then
	statement1
	statement2
	.
elif [ conditional expression2 ]
then
	statement3
	statement4
	.
.
.
else
	statement5
fi

You can use this if .. elif.. if , if you want to select one of many blocks of code to execute. It checks expression 1, if it is true executes statement 1,2. If expression1 is false, it checks expression2, and if all the expression is false, then it enters into else block and executes the statements in the else block.

if then elif then else fi example:

#!/bin/bash
count=99
if [ $count -eq 100 ]
then
  echo "Count is 100"
elif [ $count -gt 100 ]
then
  echo "Count is greater than 100"
else
  echo "Count is less than 100"
fi

4. Bash If..then..else..if..then..fi..fi..

If [ conditional expression1 ]
then
	statement1
	statement2
	.
else
	if [ conditional expression2 ]
	then
		statement3
		.
	fi
fi

If statement and else statement could be nested in bash. The keyword “fi” indicates the end of the inner if statement and all if statement should end with the keyword “fi”.

The “if then elif then else fi” example mentioned in above can be converted to the nested if as shown below.

#!/bin/bash
count=99
if [ $count -eq 100 ]
then
  echo "Count is 100"
else
  if [ $count -gt 100 ]
  then
    echo "Count is greater than 100"
  else
  echo "Count is less than 100"
  fi
fi

In our next article, we’ll discuss about how to use Bash conditional expressionswith practical examples.

ref : https://terms.naver.com/entry.nhn?docId=4125984&cid=59321&categoryId=59321

ref : https://www.thegeekstuff.com/2010/06/bash-if-statement-examples/

Amazon EC2 Auto Scaling이란 무엇입니까?

Amazon EC2 Auto Scaling을 통해 애플리케이션의 로드를 처리할 수 있는 정확한 수의 Amazon EC2 인스턴스를 보유하도록 보장할 수 있습니다. Auto Scaling 그룹이라는 EC2 인스턴스 모음을 생성합니다. 각 Auto Scaling 그룹의 최소 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값 아래로 내려가지 않습니다. 각 Auto Scaling 그룹의 최대 인스턴스 수를 지정할 수 있으며, Auto Scaling에서는 그룹의 크기가 이 값을 넘지 않습니다. 원하는 용량을 지정한 경우 그룹을 생성한 다음에는 언제든지 Auto Scaling에서 해당 그룹에서 이만큼의 인스턴스를 보유할 수 있습니다. 조정 정책을 지정했다면 Auto Scaling에서는 애플리케이션의 늘어나거나 줄어드는 수요에 따라 인스턴스를 시작하거나 종료할 수 있습니다.

예를 들어, 다음 Auto Scaling 그룹의 경우 최소 인스턴스 수 1개, 원하는 인스턴스 용량 2개, 최대 인스턴스 수 4개가 됩니다. 사용자가 정의한 조정 정책에 따라 인스턴스 수가 최소 및 최대 인스턴스 수 내에서 지정하는 조건에 따라 조절됩니다.

Auto Scaling의 이점에 대한 자세한 내용은 Auto Scaling의 이점을 참조하십시오.

Auto Scaling 구성 요소

다음 표는 Auto Scaling의 핵심 구성 요소가 나와 있습니다.

	그룹 EC2 인스턴스는 그룹에 정리되어 조정 및 관리 목적의 논리적 단위로 처리할 수 있습니다. 그룹을 생성할 때 EC2 인스턴스의 최소 및 최대 인스턴스 수와 원하는 인스턴스 수를 지정할 수 있습니다. 자세한 내용은 Auto Scaling 그룹 단원을 참조하십시오.
	시작 구성 그룹에서는 시작 구성을 그룹의 EC2 인스턴스용 템플릿으로 사용합니다. 시작 구성을 생성할 때 인스턴스의 AMI ID, 인스턴스 유형, 키 페어, 보안 그룹, 블록 디바이스 매핑 등의 정보를 지정할 수 있습니다. 자세한 내용은 시작 구성 단원을 참조하십시오.
	확장 계획 확장 계획은 Auto Scaling에 확장을 수행하는 시기와 방식을 전달합니다. 예를 들어, 지정한 조건의 발생(동적 확장) 또는 일정에 따른 확장 계획을 수립할 수 있습니다. 자세한 내용은 조정 옵션 단원을 참조하십시오.

시작하기

Auto Scaling을 처음 이용한다면 시작하기 전에 Auto Scaling 수명 주기를 검토하는 것이 좋습니다.

먼저 Amazon EC2 Auto Scaling 시작하기 자습서를 완료하여 Auto Scaling 그룹을 하나 생성한 다음 해당 그룹에서 인스턴스가 종료될 때 어떻게 응답하는지 확인합니다. 실행 중인 EC2 인스턴스가 이미 있는 경우, 기존 EC2 인스턴스를 사용하여 Auto Scaling 그룹을 생성하고 이 인스턴스를 언제든지 그룹에서 제거할 수 있습니다.

ref : https://docs.aws.amazon.com/ko_kr/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html

Elastic Load Balancing이란 무엇입니까?

Elastic Load Balancing은 여러 가용 영역에서 수신되는 애플리케이션 트래픽을 여러 EC2 인스턴스에 자동으로 분산합니다. 이렇게 하면 애플리케이션의 내결함성이 향상됩니다.

로드 밸런서는 클라이언트에 대해 단일 접점의 역할을 하여 애플리케이션의 가용성을 높입니다. 애플리케이션에 대한 요청의 전체적인 흐름을 방해하지 않고 필요에 따라 로드 밸런서에서 인스턴스를 추가 및 제거할 수 있습니다. 애플리케이션에 대한 트래픽이 시간에 따라 변화하므로 Elastic Load Balancing이 로드 밸런서를 자동으로 확장하며 대다수의 워크로드를 자동으로 확장할 수 있습니다.

로드 밸런서가 정상적인 인스턴스에만 요청을 보낼 수 있도록 등록된 인스턴스의 상태를 모니터링하는 데 사용되는 상태 확인을 구성할 수 있습니다. 또한 인스턴스가 주요 작업에 집중할 수 있도록 암호화 및 복호화 작업을 로드 밸런서로 오프로드할 수 있습니다.

Elastic Load Balancing의 기능

Elastic Load Balancing은 Application Load Balancer, 네트워크 로드 밸런서 및 Classic Load Balancer의 세 가지 로드 밸런서 유형을 지원합니다. 애플리케이션 요구 사항에 따라 로드 밸런서를 선택할 수 있습니다. 자세한 내용은 Elastic Load Balancing 제품 비교를 참조하십시오.

각 로드 밸런서 사용에 대한 자세한 내용은 Application Load Balancer용 사용 설명서, 네트워크 로드 밸런서 사용 설명서 및 Classic Load Balancer용 사용 설명서를 참조하십시오.

Elastic Load Balancing에 액세스

다음 인터페이스 중 하나를 사용하여 로드 밸런서를 생성하고, 액세스하고, 관리할 수 있습니다.

관련 서비스

Elastic Load Balancing은 다음 서비스를 통해 애플리케이션의 가용성 및 확장성을 개선합니다.

DNS 서버 : [domain name system server]

domain name system server의 약어. 도메인 이름에서 IP 주소를 추출하는 역할을 하는 서버. DNS 서버는 분산형 데이터 베이스로, 어떤 DNS 서버에서 IP 주소를 알지 못하면 상위의 DNS 서버를 검색하게 된다. 인터넷을 경유하여 메일을 주고받기 위해서는 메일 서버 이름을 DNS 서버에 등록해야 한다.

Route53은 아마존에서 제공하는 DNS 서비스 이다. 

일반 DNS와 다르게 몇 가지 아마존에 특성화된 몇 가지 기능을 가지고 있는데, 특화 기능에 앞서서 DNS 의 일반 개념을 먼저 정리해 보자.

DNS는 domain name (www.example.com)을 ip 주소로 바꿔 주는 일종의 dictionary 서비스 이다.

이러한 맵핑 정보를 저장해 놓는 파일을 DNS Zone file이라고 한다.

이 서비스는 DNS 서버에 저장해놓은 파일을 기반으로 주소를 변환하는데, 여기에 정의되는 레

코드들 중에서 대표적은 레코드는 다음과 같다.

①   SOA 레코드 : 해당 DNS 서버 자체의 설정 정보를 정의 한다.

• DNS 서버는 Primary/Secondary 구조로 장애 대응을 할 수 있는 구조인데, 이를 위해서 SOA 레코드에는 이를 위한 설정이 반영되어 있다.
• serial # - revision #로 Zone 파일이 업데이트 될때 마다 증가하는 일종의 버전
• refresh - secondary server가 primary server로 부터 업데이트를 하는 주기
• retry - primary server로 부터의 query가 실패하였을때, 다음 retry 까지 시간.
• expire : secondary server에서 zone 파일을 유지 하는 시간
• TTL : DNS 응답을 받아가는 서버가 해당 레코드 응답을 얼마나 유지해야 하는 TTL 시간

②   NS 레코드 : DNS 서버가 참조하는 다른 DNS 서버이다. DNS 서버 자신에서 domain name에 대한 주소를 알아 내지 못할때,
                      이 NS 레코드에 정의된 서버로 가서 주소를 알아dhsek.

③   CNAME 레코드: 도메인명을 다른 도메인과 맵핑할때 사용 (일종의 alias)

④   A 레코드:도메인을 ip로 맵핑

⑤   PTR 레코드 : ip를 도메인으로 맵핑 (Reverse Zone에서 사용)

DNS 서버의 특성중에서 주의깊게 봐야 하는 특성은 캐슁이다.

보통 DNS 서버는 클라이언트가 사용하는 로컬 네트워크에 있는 DNS를 사용하게 된다. 회사 네트워크라면 회사내의 DNS 서버,집에서 사용하는 경우 해당 통신사의 DNS서버, 모바일을 사용할 경우, 해당 통신사의 DNS 서버를 사용한다. 이 DNS 서버들은 look up을 요청한 목적 서비스 서버에 대한 ip 주소를 다른 클라이언트가 요청할 때 응답을 빠르게 하기 위해서 자체적으로 캐슁하고 있다.

예를 들어 구글의 A라는 서비스가 있다고 하자. 이 서비스 A는 구글의 DNS 서버에 주소가 정의되었을 것이다. 만약 한국의 사용자가 스마트 폰을 이용하여 이 서비스의 URL을 접근하게 되면, 해당 한국 통신사의 DNS 서버를 통해서 주소를 look up 하게 될 것이고, 이 한국 DNS 서버는 구글의 DNS 서버에 주소를 물어본 후에, 다음 서비스를 위해서 자신의 Cache를 업데이트 한다.

이 캐쉬가 지워지고 다시 업데이트 되는 시간이 TTL 시간인데, 이 TTL은 이후에도 설명하겠지만, 동적으로 DNS 주소를 업데이트하거나 변경하였을때, 로컬의 DNS서버의 캐쉬가 업데이트 되지 않아서 실제 주소가 바뀌더라도 이전 서버의 주소를 리턴하는 경우가 있어서 주소 변경을 어렵게 한다.

이제 Route 53의 고유 기능을 살펴보도록 하자.

Health check & DNS Fail Over

Route53은 자체적으로 Health check 기능을 가지고 있다. 하나의 DNS 명에 대해서 multiple ip address를 return할 수 있는데, 해당 ip의 서버의 상태를 체크해서 장애 상태인 경우에는 list에서 제외하고, 장애가 복구 되면 다시 리스트에 추가하는 형태이다.

앞에서 언급했듯이 이 기능의 경우 local DNS들의 캐슁 때문에, Route53이 장애를 인지하고 바로 list에서 제외한다 하더라도 local DNS에서 캐쉬가 업데이트 되는 시간이 필요하기 때문에 바로 fail over는 되지 않는다. 되도록 빠른 fail over를 하기 위해서는 Route53에서 TTL 시간을 짭게 주는 것이 좋은데, 아마존의 경우 60초이하 의 값을 권장하고 있다.

Latency based routing

Route53의 기능 중에 상당히 흥미로운 기능중의 하나인데, Route53에 하나의 DNS 주소에 대해서 여러개의 서비스 ip가 binding 되어 있을 경우, Route53은 클라이언트로 부터 DNS 주소에 대한 look up 요청을 받았을 경우, 클라이언트로 부터 가장 빠른 응답시간을 보장하는 (거리가 가까운) 서버의 ip 주소를 리턴하는 기능이다.

 원리를 설명해보면 다음과 같다. 아마존 인프라는 각 데이타센터로부터 다른 ip주소 대역까지의 네트워크 latency 값을 주기적으로 수집해서 데이타 베이스화 해서 가지고 있다. 예를 들어 미국 아마존 데이타 센터에서 전세계에 대한 latency를 아마존을 가지고 있다. 한국,중국,유럽 등등. 이렇게 latency 자료를 가지고 있다가, DNS look up 요청이 오면, 요청을 한 클라이언트쪽의 ip를 기반으로 내부 데이타 베이스내의 latency를 체크해여 가장 가까운 아마존 데이타 센터의 ip를 리턴하게 되는 원리이다.

이 때 Route 53으로 request를 보내는 클라이언트는 end user browser나 모바일 기기등이 아니라 end user가 접속된 네트워크의 로컬 DNS 서버가 되게 된다.

 Latency based routing의 경우 로컬 DNS가 클라이언트가 접속하는 망내에 있는 것을 전제로 한다.

ref : http://bcho.tistory.com/795

ElastiCache 클러스터

클러스터는 지원되는 캐시 엔진 소프트웨어의 인스턴스 Memcached 또는 Redis를 모두 실행하는 하나 이상의
캐시 노드 모음입니다. 

클러스터를 만들 때 모든 노드에 사용할 엔진을 지정합니다.

다음 다이어그램은 일반적인 Memcached 및 일반적인 Redis 클러스터를 보여줍니다. Memcached 클러스터에는 데이터를 가로로 분할할 수 있는 노드가 1개에서 20개까지 포함됩니다. Redis 클러스터는 단일 노드 또는 최대 six개의 노드를 샤드(API/CLI: 노드 그룹)에 포함할 수 있으며 Redis(클러스터 모드 비활성화됨) 클러스터는 항상 단일 샤드를 포함합니다. Redis(클러스터 모드 활성화됨) 클러스터는 데이터가 샤드에 분할된 최대 15개의 샤드를 포함할 수 있습니다. 샤드에 여러 노드가 있으면 노드 중 하나는 읽기/쓰기 기본 노드가 됩니다. 샤드의 나머지 노드는 모두 읽기 전용 복제본입니다.

일반적인 Memcached 및 Redis 클러스터

클러스터 수준에서 대부분의 ElastiCache 작업이 수행됩니다. 특정 수의 노드 및 각 노드에 대한 속성을 제어하는 파라미터 그룹을 사용하여 클러스터를 설정할 수 있습니다. 클러스터 하나에 속한 모든 노드는 노드 유형, 파라미터 및 보안 그룹 설정이 동일합니다.

클러스터마다 클러스터 식별자가 있습니다. 클러스터 식별자는 고객이 제공하는 클러스터 이름입니다. ElastiCache API 및 AWS CLI 명령과 상호 작용할 때 이 식별자가 특정한 클러스터를 지정합니다. 클러스터 식별자는 한 AWS 리전 내의 해당 고객에 대해 고유해야 합니다.

ElastiCache는 각 엔진의 여러 버전을 지원합니다. 특별한 이유가 없으면 항상 엔진의 최신 버전을 사용하는 것이 좋습니다.

ref : https://docs.aws.amazon.com/ko_kr/AmazonElastiCache/latest/UserGuide/Clusters.html

1 윈도우 - 마우스 오른쪽 클릭 - 제어판

2 프로그램 클릭

3 '프로그램 및 기능'에서 windows 기능 켜기/끄기 클릭

5 텔넷 클라이언트 체크!

6 변경 내용 적용 - 확인 후 닫기

7 cmd창(ctrl+R -> cmd)에서 'telnet' 명령어를 치면 이렇게 뜬답니다!

ref : https://opentutorials.org/module/2160/12506

이글은 Quora에 올라온 “What’s the difference between sharding and partition?“글의 질문과 모자이크 CTO가 답변한 내용을 번역한 글입니다.

샤딩(sharding)과 파티셔닝(partitioning)의 차이가 무엇인가?

분산 데이터베이스 시스템에서 샤딩과 파티셔닝이라는 단어를 종종 듣는다. 하지만 그들의 차이점을 잘 모르겠다. 그래서 이것들을 위키에서 검색해보았지만 여전히 혼란스럽다. 약간의 예제를 줄 수 있을까?

Tony Bako, Mosaic의 CTO의 답변

파티셔닝이란 퍼포먼스(performance), 가용성(availability) 또는 정비용이성(maintainability)를 목적으로 당신의 논리적인 데이터 엘리먼트들을 다수의 엔티티(table)로 쪼개는 행위를 뜻하는 일반적인 용어이다.

샤딩은 수평 파티셔닝(horizontal partitioning)과 동일하다. 데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리한다. 예를 들면, 나는 고객의 데이터베이스를 CustomerId를 샤드키로 사용하여 샤딩하기로 하였다. 0 ~ 10000 번 고객의 정보는 하나의 샤드에 저장하고 10001 ~ 20000 번 고객의 정보는 다른 샤드에 저장하기로 하였다. DBA는 데이터 엑세스 패턴과 저장 공간 이슈(로드의 적절한 분산 , 데이터의 균등한 저장)를 고려하여 적절한 샤드키를 결정하게 된다.

수직 파티셔닝(vertical partitioning)은 하나의 엔티티에 저장된 데이터들을 다수의 엔티티들로 분리하는것을 말한다. (마찬가지로 공간이나 퍼포먼스의 이유로) 예를 들면, 한 고객은 하나의 청구 주소를 가지고 있을 수 있다. 그러나 나는 데이터의 유연성을 위해 다른 데이터베이스로 정보를 이동하거나 보안의 이슈등을 이유로 CustomerId를 참조하도록 하고 청구 주소 정보를 다른 테이블로 분리할 수 있다.

Vertical Partitioning

요약하면 파티셔닝은 퍼포먼스, 가용성, 정비용이성등의 목적을 위해 논리적인 엔티티들을 다른 물리적인 엔티티들로 나누는것을 의미하는 일반적인 용어이다. 수평 파티셔닝 또는 샤딩은 스키마 복제 후 샤드키를 기준으로 데이터를 나누는것을 말한다. 수직 파티셔닝은 스키마를 나누고 데이터가 따라 옮겨가는것을 말한다.

ref : http://theeye.pe.kr/archives/1917

ref : https://medium.com/@junggil/dynamodb%EB%A5%BC-%EC%84%A0%ED%83%9D%ED%95%98%EB%8A%94-%EC%9E%98%EB%AA%BB%EB%90%9C-%EC%9D%B4%EC%9C%A0-fade0d0984d0

DynamoDB 핵심 구성 요소

DynamoDB 테이블에서, 항목 및 속성은 작업 시 필요한 핵심 구성 요소입니다. 테이블은 항목 집합이고, 각 항목은 속성 집합입니다. DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. DynamoDB 스트림를 사용해서는 DynamoDB 테이블의 데이터 수정 이벤트를 캡처할 수 있습니다.

DynamoDB에 크기 제한이 있습니다. 자세한 내용은 DynamoDB의 제한 값 단원을 참조하십시오.

테이블, 항목 및 속성

다음은 기본 DynamoDB 요소입니다.

다음 다이어그램은 몇 가지 예제 항목과 속성이 있는 People이라는 테이블을 보여 줍니다.

People 테이블에 대해 다음을 알아 두십시오.

다음은 음악 파일을 추적하는 데 사용할 수 있는 Music이라는 다른 예제 테이블입니다.

Music 테이블에 대해 다음을 알아 두십시오.

자세한 내용은 DynamoDB의 테이블 작업 단원을 참조하십시오.

기본 키

테이블을 생성할 때는 테이블 이름 외에도 테이블의 기본 키를 지정해야 합니다. 기본 키는 테이블의 각 항목을 나타내는 고유 식별자입니다. 따라서 두 항목이 동일한 키를 가질 수는 없습니다.

DynamoDB는 두 가지의 기본 키를 지원합니다.

각 기본 키 속성은 스칼라여야 합니다(즉, 단일 값만 가질 수 있음). 기본 키 속성에 허용되는 데이터 형식은 문자열, 숫자 또는 이진수뿐입니다. 다른 키가 아닌 속성에는 이러한 제한이 없습니다.

보조 인덱스

테이블에서 하나 이상의 보조 인덱스를 생성할 수 있습니다. 보조 인덱스는 기본 키에 대한 쿼리는 물론이고 대체 키를 사용하여 테이블 데이터에 대한 쿼리까지 실행할 수 있습니다. DynamoDB는 인덱스를 사용하도록 요구하지는 않으면서도 데이터를 쿼리할 때 애플리케이션에 보다 많은 유연성을 제공합니다. 테이블에서 보조 인덱스를 생성한 후에는 테이블에서 데이터를 읽는 것과 같은 방식으로 인덱스에서 데이터를 읽을 수 있습니다.

DynamoDB는 다음과 같이 두 가지 종류의 인덱스를 지원합니다.

테이블당 최대 5개의 글로벌 보조 인덱스 및 5개의 로컬 보조 인덱스를 정의할 수 있습니다

앞에 나온 예제 테이블인 Music 테이블에서는 Artist(파티션 키) 또는 Artist 와 SongTitle(파티션 키 및 정렬 키)을 기준으로 데이터 항목에 대한 쿼리가 가능합니다. Genre및 AlbumTitle로도 데이터를 쿼리하고 싶다면 어떻게 해야 할까요? 그렇게 하려면 Genre 및 AlbumTitle에 대해 인덱스를 생성한 후 Music 테이블을 쿼리한 방법대로 인덱스를 쿼리하면 됩니다.

다음 다이어그램은 Music 테이블과 GenreAlbumTitle이라는 새 인덱스를 보여 줍니다. 인덱스에서 Genre는 파티션 키이고, AlbumTitle은 정렬 키입니다.

GenreAlbumTitle 테이블에 대해 다음을 알아 두십시오.

GenreAlbumTitle 인덱스를 쿼리하여 특정 장르의 앨범을 모두 찾을 수 있습니다(예: 모든 Rock 앨범). 또한 인덱스를 쿼리하여 특정 앨범 제목이 있는 특정 장르에 속하는 모든 앨범을 찾을 수도 있습니다(예: 제목이 알파벳 H로 시작하는 모든 Country 앨범).

자세한 내용은 보조 인덱스를 사용하여 데이터 액세스 향상 단원을 참조하십시오.

DynamoDB 스트림

DynamoDB 스트림는 DynamoDB 테이블의 데이터 수정 이벤트를 캡처하는 선택적 기능입니다. 이러한 이벤트에 대한 데이터가 이벤트가 발생한 순서대로 거의 실시간으로 스트림에 표시됩니다.

각 이벤트는 스트림 레코드에 의해 나타납니다. 테이블에서 스트림을 설정하면 다음과 같은 이벤트 중 하나가 발생할 때마다 DynamoDB 스트림가 스트림 레코드를 기록합니다.

각 스트림 레코드에는 또한 테이블의 이름, 이벤트 타임스탬프 및 다른 메타데이터가 포함되어 있습니다. 스트림 레코드의 수명은 24시간이며, 24시간이 지나면 스트림에서 자동으로 제거됩니다.

DynamoDB 스트림와 AWS Lambda를 함께 사용하여 트리거(관심 있는 이벤트가 스트림에 표시될 때마다 자동으로 실행되는 코드)를 만들 수 있습니다. 예를 들어, 회사의 고객 정보가 들어 있는 Customers 테이블을 생각해 볼 수 있습니다. 새 고객마다 "환영" 이메일을 보내려고 한다고 가정해 보십시오. 해당 테이블에 스트림을 설정한 다음, 스트림을 Lambda 함수와 연결할 수 있습니다. Lambda 함수는 새로운 스트림 레코드가 표시될 때마다 실행되지만 Customers 테이블에 추가된 새로운 항목만 처리합니다. EmailAddress 속성이 있는 모든 항목에 대해 Lambda 함수는 Amazon Simple Email Service(Amazon SES)를 호출하여 해당 주소에 이메일을 보냅니다.

트리거뿐만 아니라 DynamoDB 스트림는 AWS 리전 내외에서의 데이터 복제, DynamoDB 테이블의 구체화된 데이터 보기, Kinesis 구체화된 보기를 사용한 데이터 분석 등의 강력한 기능을 제공합니다.

자세한 내용은 DynamoDB 스트림를 사용하여 Table Activity 캡처하기 단원을 참조하십시오.

ref : https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html

1. AWS란?

2. AWS의 네트워크 서비스

VPC를 사용하면 AWS 환경의 인프라 자원을 기존의 네트워크에서 사용하는 것처럼 활용할 수 있습니다. 따라서 인터넷으로 접근할 필요가 없는 사내 시스템 등도 보안을 유지한 상태로 AWS로 가동시킬 수 있습니다

Direct Connect는 데이터 센터 또는 오피스의 네트워크와 AWS를 전용선으로 접속할 수 있게 해주는 서비스입니다. VPN보다도 안정된 빠른 통신 환경이 필요한 경우에 사용합니다. 예를 들어, DB 서버를 On Premise에 배치하는 하이브리드 구성에서 서버들끼리 고속 통신이 필요할 때 사용합니다

AWS의 서비스들끼리 연계할 때는 DNS 호스트 이름(FQDN)을 사용하는 것이 좋습니다. 예들 들어, 디폴트로 EC2 인스턴스는 기동될 때마다 IP 주소가 자동적으로 할당됩니다. 따라서 접근할 때 필요한 IP 주소가 계속해서 변합니다. 따라서 기동 때 자동으로 자신의 IP 주소를 FQDN으로 Route 53에 등록하면, IP 주소가 변경되어도 같은 FQDN 이름으로 해당 인스턴스에 접근할 수 있습니다

Route 53은 도메인 레지스트라(Domain Registrar) 서비스도 제공합니다. 이 서비스를 사용하면 도메인 구매부터 정보 설정까지 Route 53으로 한번에 관리할 수 있습니다. 새로운 도메인을 사용할 때는 물론이고 기존 시스템의 도메인을 마이그레이션하는 것도 가능합니다

Route 53의 장애 허용 아키텍처(Fault Tolerant Architecture)는 DNS Failover입니다. 예를 들어, 가동하고 있는 시스템에 장애가 발생해서 웹 사이트로 들어갈 수 없을 때 일시적으로 접속위치를 다른 서버로 전환하는 등에 사용합니다

AWS가 제공하는 네트워크는 크게 AWS 네트워크와 VPC 네트워크로 구분할 수 있습니다. AWS 네트워크는 인터넷에서 접근할 수 있는 네트워크를 나타내며, VPC 네트워크는 VPC 환경 내부에서만 사용할 수 있는 네트워크를 나타냅니다. 참고로 VPC 네크워크로 사용할 수 있는 서비스는 당연히 AWS 네트워크에서도 사용할 수 있습니다

하지만 서비스 조합에 따라서 VPC 네트워크로 사용하는 서비스도 AWS 네트워크 접속(인터넷 접속) 설정이 필요하기도 합니다. 예를 들어, VPC 네트워크 위의 EC2 인스턴스에서 S3에 접근하는 경우를 생각해 봅시다. S3는 AWS 네트워크로만 사용 가능한 서비스이므로, AWS 네트워크(인터넷) 통신 설정이 필요합니다

3. 하드웨어 리소스

인스턴스 스토리지는 EC2 인스턴스가 가동되는 물리 서버에 있는 로컬 디스크를 나타냅니다. 인스턴스 스토리지를 사용할 때 주의해야 하는 것은 인스턴스 스토리지에 있는 데이터는 EC2 인스턴스를 중지하면 사라진다는 것입니다. 따라서 처리에 필요한 임시 파일 또는 캐시 데이터 등을 저장할 때 사용합니다

EBS-Backed 인스턴스는 OS를 포함한 루트 디바이스 정보를 EBS에 저장한 인스턴스를 나타냅니다. AWS도 EBS-Backed 인스턴스를 권장하고 있습니다. EBS에 기록되므로, 인스턴스를 정지해도 변경 사항이 유지됩니다. 따라서 이후에 변경 내용이 반영된 상태로 인스턴스를 기동할 수 있습니다

반면 Instance Store-Backed 인스턴스는 OS를 포함한 루트 디바이스 정보를 S3에 저장한 인스턴스입니다. 인스턴스 기동 때는 S3에서 인스턴스 스토리지에 데이터를 복사하고 기동합니다. 이후에 다시 기동하면 S3에서 루트 디바이스를 처음부터 읽어 들이므로, 이전의 변경 사항은 모두 파기됩니다

​

​EBS를 생성할 때 암호화 옵션을 활성화할 수 있습니다. 암호화 옵션을 활성화한 EBS는 읽고 쓰는 데이터들을 암호화하게 됩니다

​

​EC2 인스턴스 또는 EBS를 운용할 때 빼놓을 수 없는 것이 AMI와 EBS 스냅샷이라는 백업입니다. 인스턴스 또는 EBS로부터 AMI, EBS 스냅샷을 생성하면, 언제든지 해당 시점으로 복구할 수 있습니다

​

​Amazon Machine Image(AMI)는 가상 서버에 있는 인스턴스 기동에 필요한 정보를 저장하고 있습니다

​

​EBS 스냅샷은 EBS를 백업해서 S3에 저장하는 기능입니다

​

​S3는 버킷(Bucket)이라는 컨테이너를 놓을 리전을 선택하고, 해당 컨테이너 내부에 객체(Object)라는 형태로 데이터를 저장합니다

​

​S3에 데이터를 저장할 때는 데이터를 자동으로 암호화하는 서버 사이드 암호화(SSE)를 활용할 수 있습니다

​

​S3 버킷, 객체에서 이벤트가 발생했을 때 다음과 같은 이벤트 알림을 보낼 수 있습니다

- SNS 토픽으로 메시지 발행

- SQS 큐에 메시지 생성

- Lambda Function으로 알림

​

​S3는 정적 콘텐츠를 제공하는 웹 호스팅 기능도 제공합니다. 추가로 정적 웹 사이트에는 S3의 자체적인 도메인이 할당되는데요. Route 53 등의 도메인 이름 서비스(DNS)를 사용해서 다른 도메인을 부여할 수 있습니다

​

​EBS 스냅샷과 S3 객체의 차이

: EBS 스냅샷은 S3에 저장됩니다. 하지만 S3의 객체처럼 REST, SOAP 통신에서 로컬 환경으로 가져오는 등의 작업을 할 수 없습니다. EBS 스냅샷은 어디까지나 EC2 내부에서만 사용할 수 있게 한정되어 있습니다

​

​S3의 버전 관리

: S3는 간단한 버전 관리 기능도 가지고 있습니다. 버전 관리 기능을 사용하면 객체를 덮어쓰거나 삭제할 때 이전 버전의 객체를 자동으로 저장해줍니다

​

​S3 수명 주기 설정

: S3에는 객체 생성부터 전환/제거까지의 수명을 관리하고 설정하는 수명 주기(Life Cycle) 설정 기능이 있습니다

​

​Amazon Glacier

: Amazon Glacier는 S3같은 내구성을 가지면서 더 저렴한 가격으로 사용할 수 있는 아카이브 스토리지 서비스입니다. 저렴하지만 데이터의 저장과 추출에 시간이 조금 걸립니다. 추가로 S3와 다르게 저장하는 데이터에 명칭을 붙일 수 없으며, 자동 채번(Auto Numbering)으로 부여되는 아카이브 ID로 관리됩니다. 따라서 Glaicer는 장기간 보존하며, 접속 빈도가 낮은 데이터를 저장하는 데 적합하다고 할 수 있습니다 

4. 애플리케이션 기반

RDS는 자동 백업과 DB 스냅샷이라는 두 가지 백업 방법을 제공합니다. 자동 백업을 하면 1일에 한번 스냅샷을 생성할 수 있습니다. 생성한 스냅샷은 S3에 저장됩니다. 보존 기간은 최소 1일, 최대 35일입니다. 수동 백업(DB 스냅샷)은 보존 기간에 제한이 없습니다

RDS에 접근할 때는 반드시 DNS를 사용합니다

멀티 AZ 기능은 RDS의 가용성을 높이는 기능입니다

Elastic Beanstalk는 미들웨어, EC2 인스턴스, RDS, ELB, Auto Scaling, CloudWatch를 사용한 감시와 알림 설정, SNS를 사용한 알림 등을 포함한 서비스를 운용하기 위해 필요한 환경을 모두 자동으로 구축해줍니다

5, AWS의 애플리케이션 서비스

Amazon Simple Queue Service(SQS)에서 작업(Job) 등록자는 메시지를 사용해 큐에 작업을 등록합니다. 수신자는 SQS에 지속적으로 폴링하며, 메시지가 있을 경우 메시지를 받아서 어떠한 처리를 하게 됩니다. 처리를 할 때에는 락(lock)이 걸리므로 다른 수신자는 해당 메시지를 확인할 수 없습니다. 처리가 완료되면 큐에서 메시지가 삭제됩니다

SQS는 다음과 같은 2가지 원칙을 가지고 동작합니다

- 전송한 메시지는 무조건 도달한다. 다만 2번 이상 같은 메시지를 수신할 가능성은 있다

- 메시지의 순서는 보장하지 않는다

SQS를 사용할 때는 이러한 2가지 원칙을 이해하고 애플리케이션을 구현해야 합니다

Amazon Simple Notification Service (SNS)는 푸시 형태의 알림 서비스입니다. 사용할 수 있는 프로토콜은 SMS, email, http/https, SQS, iOS, Android 등의 모바일 장치입니다

SNS는 토픽이라는 단위로 관리합니다

CloudWatch 알림 기능

CloudWatch Logs는 로그 수집과 감시라는 2가지 기능이 있습니다

ref : https://horajjan.blog.me/221216271467

AWS Databases (RDS)

1. DB종류

Amazon Aurora. PostgreSQL, MySQL, MariaDB, Oracle, SQL Server

* 라이선스

Oracle과 SQL Server는 사용할 때 두가지 모델로 비용을 지불할 수 있습니다.

라이선스 비용을 인스턴스 사용 비용에 포함한 모델과 이미 가지고 있는 라이선스를 사용하는 모델 두 가지를 제공합니다.

2. 자동백업 및 수동백업

- 자동백업

1일에 한번 완전한 스냅샷을 생성할 수 있습니다. 생성한 스냅샷은 S3에 저장됩니다.  

스냅샷을 생성하는 시간은 자유롭게 선택 가능하며 자동 백업 기능을 활성화하면 특정 시점으로 복구 할 수 있습니다.

매일매일의 스냅샷과 트랜잭션 로그를 기반으로 데이터베이스를 과거의 특정 시점에서의 상태로 되돌릴 수 있습니다.

백업 데이터 보존 기간 : 최소 1일, 최대 35일

- 수동 백업(DB 스냅샷)

수동 백업은 보존 기간이 제한이 없으며 잠시 사용하지 않는 인스턴스를 삭제하기 전에 DB 스냅샷을 추출하고 저장합니다.

수동으로 백업한 것을은 수동으로 제거해 줘야 하며 DB스냅샷 유지에 비용이 발생합니다.

3. RDS의 네트워크

* 페일오버 주의점

페일오버가 발생해도 RDS인스턴스의 DNS이름은 변하지 않습니다. DNS 참조 대상이 변경될 뿐이므로, 

애플레케이션에서의 접속 정보를 변경할 필요는 없습니다. 하지만 AP서버 등에서 DNS를 캐시하는 경우에는 

접근이 불가능해질 수 있습니다.  AP서버에서 DNS를 변수에 저장하여 활용하는 경우 또한, RDS인스턴스가 사용 

불가능하다는 것을 감지한 이후부터 처리가 시작되므로, 페일오버가 완료될 때까지 다운 타임이 발생합니다. 

페일오버시간은 명확하지 않으며, 일반적으로는 몇 분이지만 트랜잭션 양과 데이터베이스 엔진에 따라 늘어날 수 있습니다.

4. IOPS/스토리지 유형

범용(SSD), 프로비저닝된 IOPS(SSD), 마그네틱

5. RDS로그

AWS 매니지먼트 콘솔에서 RDS로그 확인할 수 있습니다.

확인할 수 있는 로그는 데이터베이스와 관련된 로그뿐이며, OS로그는 확인할 수 없습니다.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.Concepts.MySQL.html

6. 파라미터 그룹

각각의 데이터베이스 엔진에 대한 설정을 관리/적용하는 기능입니다. 

기동 후에도 적용할 수 있지만 RDS인스턴스를 재부팅해야 합니다.

7. 옵션 그룹

데이터베이스의 추가 기능을 관리/적용하는 기능입니다.

http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithOptionGroups.html

ref : https://blog.naver.com/theswice/221020333848

네트워크 ACL

네트워크 ACL(액세스 제어 목록)은 1개 이상의 서브넷 내부와 외부의 트래픽을 제어하기 위한 방화벽 역할을 하는 VPC를 위한 선택적 보안 계층입니다. 보안 그룹과 비슷한 규칙으로 네트워크 ACL을 설정하여 VPC에 보안 계층을 더 추가할 수 있습니다. 

보안

Amazon VPC는 다음과 같이 VPC의 보안을 강화하고 모니터링하는 데 사용할 수 있는 세 가지 기능을 제공합니다.

VPC에서 인스턴스를 시작할 경우 생성된 보안 그룹을 한 개 이상 연결할 수 있습니다. VPC의 각 인스턴스는 서로 다른 보안 그룹 세트에 속할 수 있습니다. 인스턴스를 시작할 때 보안 그룹을 지정하지 않으면 VPC의 기본 보안 그룹에 자동으로 속하게 됩니다. 보안 그룹에 대한 자세한 내용은 VPC의 보안 그룹을 참조하십시오.

보안 그룹만 사용하여 VPC 인스턴스를 보호할 수 있지만 2차 보안 계층으로 네트워크 ACL을 추가할 수 있습니다. 네트워크 ACL에 대한 자세한 내용은 네트워크 ACL을 참조하십시오.

VPC, 서브넷 또는 개별 네트워크 인터페이스에 대한 흐름 로그를 생성하여 인스턴스에서 송신하고 수신하는 IP 트래픽의 수락과 거부를 모니터링할 수 있습니다. 흐름 로그 데이터는 CloudWatch Logs에 게시되며 너무 거부적이거나 허용적인 보안 그룹과 네트워크 ACL 규칙을 진단하는 데 도움이 됩니다. 자세한 내용은 VPC 흐름 로그를 참조하십시오.

AWS Identity and Access Management를 사용하면 조직에서 보안 그룹 및 네트워크 ACL과 흐름 로그를 생성하고 관리할 수 있는 권한을 가진 사람을 통제할 수 있습니다. 예를 들어 이러한 권한을 네트워크 관리자에게만 부여하고, 인스턴스만 시작하면 되는 사용자에게는 부여하지 않을 수 있습니다. 자세한 내용은 Amazon VPC 리소스에 대한 액세스 제어 단원을 참조하십시오.

Amazon 보안 그룹과 네트워크 ACL은 링크-로컬 주소(169.254.0.0/16) 또는 AWS에서 예약한 IPv4 주소—(VPC에 대한 Amazon DNS 서버 주소가 포함된 서브넷의 첫 IPv4 주소 4개)를 주고받는 트래픽을 필터링하지 않습니다. 마찬가지로 흐름 로그는 이러한 주소에서 송수신되는 IP 트래픽을 수집하지 않습니다. 이들 주소는 DNS(Domain Name Service), DHCP(Dynamic Host Configuration Protocol), Amazon EC2 인스턴스 메타데이터, KMS(Key Management Server - Windows 인스턴스용 라이선스 관리) 및 서브넷에서 라우팅 등의 서비스를 지원합니다. 인스턴스에서 추가 방화벽 솔루션을 구현하여 링크-로컬 주소와의 네트워크 통신을 차단할 수 있습니다.

보안 그룹 및 네트워크 ACL 비교

다음 표는 보안 그룹과 네트워크 ACL의 근본적인 차이를 요약한 것입니다.

다음 다이어그램은 보안 그룹과 네트워크 ACL에서 제공하는 보안 계층을 보여 줍니다. 예를 들어, 인터넷 게이트웨이의 트래픽은 라우팅 테이블의 라우팅을 사용하여 적절한 서브넷에 라우팅됩니다. 서브넷과 연결된 네트워크 ACL 규칙은 서브넷에 허용되는 트래픽 유형을 제어합니다. 인스턴스와 연결된 보안 그룹 규칙은 인스턴스에 허용되는 트래픽 유형을 제어합니다.

ref : https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_ACLs.html

ref : https://docs.aws.amazon.com/ko_kr/AmazonVPC/latest/UserGuide/VPC_Security.html

on premise 사내 직접 설치

온프레미스(On-premise)란 소프트웨어 등 솔루션을 클라우드 같이 원격 환경이 아닌 자체적으로 보유한 전산실 서버에 직접 설치해 운영하는 방식을 말합니다. 온프레미스는 클라우드 컴퓨팅 기술이 나오기 전까지 기업 인프라 구축의 일반적인 방식이었기 때문에 이전 또는 전통적인 이라는 단어와 함께 사용됩니다. 

일반적으로 온프레미스 시스템을 구축하는데 시간이 수개월 이상 걸렸고 비용 또한 많이 들어, 퍼블릭 클라우드가 나올 당시만 해도 온프레미스 환경이 금방이라도 모두 사라질 것 같았습니다. 하지만 보안 적인 이유로 비즈니스에 중요하고 보안이 필요한 서비스와 데이터는 온프레미스 환경에서, 덜 중요한 것은 퍼블릭 클라우드 환경을 사용하는 하이브리드 IT 인프라가 대세를 이루고 있습니다. 

온프레미스 vs 오프프레미스

ref : http://mickeyh-words.blogspot.kr/2014/01/vs.html

ref : http://www.dt.co.kr/contents.html?article_no=2017012602102269041001

[소캣(Socket)]

소켓(socket)은 통신의 극점(EndPoint)를 뜻한다. 두 프로세스가 네트워크 상에서 통신을 하려면 양 프로세스마다 하나씩 총 두 개의 소켓이 필요하다. 클라이언트 프로세스가 연결을 요청하면 호스트 컴퓨터가 포트 번호를 부여한다. 이때 포트 번호는 1024(0~1024는 시스템 예약)보다 큰 임의의 정수가 사용된다. 모든 연결은 유일 해야 한다.

소켓을 이용한 통신은 분산된 프로세스들 간에 널리 사용되고 효율적이기는 하지만 너무 저수준이다. 우선 소켓은 쓰레드들 간에 구조화되지 않은 바이트 스트림만을

통신하도록 하기 때문이다. 이러한 원시적인 바이트 스트림 자료를 구조화 하여 해석하는 것은 클아이언트와 서버의 주요 작업이 된다.

소켓이란 무엇인가?

소켓 통신

일반적으로 서버는 특정 포트가 바인딩된 소켓를 가지고 특정 컴퓨터 위에서 돌아갑니다.
해당 서버는 클라이언트의 연결 요청을 소켓을 통해 리스닝하면서 그냥 기다릴 뿐이죠.

클라이언트는 서버가 떠 있는 머신의 호스트네임과 서버가 리스닝하고 있는 포트 번호를 알고 있습니다.
따라서 클라이언트는 이 호스트 네임과 포트를 통해서 서버와 연결을 시도하게 됩니다.
또한 클라이언트는 서버 상대로 자신을 식별시켜주기 위해서 연결동안 사용될 로컬 포트에 바인딩됩니다.
이 포트 바인딩 작업은 보통 시스템에 의해서 이뤄집니다.

5connect

만약에 모든 게 순조롭게 이뤄진다면 서버는 연결을 수락하게 됩니다.
수락하자마자, 서버는 동일한 로컬 포트에 바인딩된 새로운 소켓을 얻게 되며 클라이언트의 주소와 포트로 세팅된 리모트 엔드 포인트를 가지게 됩니다.
서버가 별개의 새로운 소켓이 필요한 이유는 연결된 클라이언트의 요청을 처리하면서, 동시에 기존의 소켓을 통해서는 지속적으로 연결 요청을 받아야 하기 때문입니다.

6connect

클라이언트 입장에서는 만약에 연결이 수락되면 소켓은 성공적으로 생성되며 클라이언트는 서버와 통신하기 위해서 소켓을 사용할 수 있게됩니다.

클라이언트와 서버는 이제 소켓에 데이터를 쓰거나 읽음으로써 통신할 수가 있게됩니다.

소켓의 정의

소켓은 네트워크 상에서 돌아가는 두 개의 프로그램 간 양방향 통신의 하나의 엔트 포인트입니다.
소켓은 포트 번호에 바인딩되어 TCP 레이어에서 데이터가 전달되야하는 어플리케이션을 식별할 수 있게 합니다.

엔드 포인트란?

여기서 엔드 포인트라 함은 아이피 주소와 포트 번호의 조합을 의미합니다.
모든 TCP 연결은 2개의 앤드 포인트로 유일하게 식별되어질 수 있습니다.
따라서 클라이언트와 서버 간 여러 개의 연결이 맺어질 수 있습니다.

Socket 클래스

자바 플랫폼에서 java.net 패키지는 네트워크 상에서 두개의 프로그램 간 양방향 통신에서 한쪽 지점을 구현하는 Socket 클래스를 제공합니다.
Socket 클래스는 특정 시스템의 세부사항은 감추면서 플랫폼 독립적인 구현의 최상단에 위치합니다.
네이트브 코드에 의존하는 대신에 java.net.Socket 클래스를 이용해서 플랫폼 독립적인 방식으로 네트워크 상에서 통신을 할 수 있습니다.

추가적으로 java.net 패키지는 서버가 클라이언트로 부터 연결을 리스팅하고 수락하는데 사용되는 소켓을 구현하는 ServerSocket 클래스도 포함합니다. 본 튜토리얼에서는 Socket과 ServerSocket 클래스를 어떻게 사용하는지 살펴볼 것입니다.

Web 통신

혹시 Web 통신을 하려고 한다면, URL 클래스와 관련 클래스(URLConnection, URLEncoder)들이 아마도 본 소켓 클래스보다 더 적당할 것입니다. 사실상, URL은 Web에 대한 상대적으로 고수준의 연결이며 기저 구현으로 소켓을 사용합니다.
URL을 통한 Web 통신 관련해서는 해당 튜토리얼을 참고바랍니다.

ref : http://sqlmvp.tistory.com/169

ref :http://www.daleseo.com/what-is-a-socket/

npm config set registry http://registry.npmjs.org/  

ref : https://codeforgeek.com/2015/05/setup-node-development-environment-amazon-ec2/

ref : https://stackoverflow.com/questions/45884752/npm-err-code-unable-to-get-issuer-cert-locally

※ 사용예

rm  file1  file2

: 파일1과 파일2를 삭제한다.

rm directory

: rm 명령어는 -r 옵션을 주지 않을 경우 디렉토리는 삭제할 수 없다.

m -i file1 file2

: rm 명령어에 -i 옵션을 줘서 삭제하기 전 사용자에게 지울지 물어본다.

rm -fr di* fi*

: 옵션으로 f와 r을 줘서 디렉토리 및 그 하위 모든 내용을 강제로 삭제하는데, di로 시작하는 모든것과 fi로 시작하는 모든 것을 삭제한다. 다른 예로 rm *.txt라고 하면 확장자가 txt인것들을 삭제한다.

ref : http://shaeod.tistory.com/506

Linux – sudo와 su의 차이

su와 sudo 모두 root권한으로 명령을 내리는데 사용된다. root는 윈도우에서 Administrator와 같은 개념으로 시스템에 대한 모든 권한을 갖고 작업을 할 수 있다. 일반 사용자 계정의 경우 작업 내용과 보안 수준에 따라 필요한 권한만을 가지고 시스템에서 작업을 한다. 예로, 시스템에 새로운 프로그램을 설치하거나 특정 디렉토리에 접근이 안될 수 있다. 만약 이러한 작업을 수행해야한다면 su나 sudo로 권한을 획득할 수 있다.

su를 아무런 옵션 없이 실행하면 root계정으로 사용자를 전환(switch user)할 수 있다. 이때 root계정의 암호를 입력해야 한다. 물론 아시다시피 root계정뿐만 아니라 다른 사용자 계정으로 전환이 가능하다. 예로, su keepdelight를 입력하고 keepdelight계정의 암호를 입력하면 keepdelight계정으로 전환이 된다.
root계정으로 작업을 수행한 후에는 exit로 빠져나와 다시 원래 – 제한된 권한이 부여된 – 계정으로 돌아와야 한다.

이에비해 sudo는 root권한으로 한 번 명령어를 실행한다. 만약 sudo command(root권한으로 실행할 명령어)를 입력하면 명령어를 실행하기 전에 먼저 현재 사용자 계정의 비밀번호를 물어본다. 비밀번호 입력 후 실행되는 명령은 일반 사용자 권한이 아닌 root 권한으로 실행하게 된다.

이상이 su와 sudo의 주요 차이점이다. su는 사용자를 아예 root사용자로 전환시키는데 비해(root계정의 비밀번호 입력 필요) sudo는 사용자 전환 없이 단일 명령에 대해 root권한을 부여하게 된다.(root계정의 비밀번호를 입력하지 않는다.)

참고로 su를 sudo처럼, 그리고 sudo를 su처럼 사용할 수도 있다.

su -c 'command'

 
su에 c 옵션을 줘서 sudo처럼 입력한 command에 한해 root권한으로 실행할 수 있다. 다만, sudo와는 달리 이때에도 root계정의 비밀번호를 입력해야 한다.

sudo –i

 
sudo에 i옵션을 주면 root계정으로 전환된다. 이때도 역시 root계정의 암호 대신 현재 사용자의 암호를 입력하게 된다.

howtogeek 번역 및 정리 (원문보기)

ref : http://plaboratory.org/archives/4398

CloudFront는 AWS에서 제공하는 CDN(Content Delivery Network) 서비스이다. CDN 서비스를 이용하면 서비스 대기 시간과 성능이 개선되어 이미지, 오디오, 비디오 및 일반 웹 페이지 등을 최종 사용자에게 빠르게 제공할 수 있다. CDN에 대한 추가적인 설명은 이곳에서 확인할 수 있다.

CloudFront에 대해서 알기 전에 에지 로케이션(Edge Location)에 대해서 이해할 필요가 있는데 간단히 설명하면 CloudFront를 위한 캐시 서버를 의미한다.

일반적으로 멀리 떨어진 서버보다는 가까운 서버에서 데이터를 제공 받는 것이 더 빠르기 때문에 AWS는 전세계 다양한 곳에 에지 로케이션을 두고 서비스를 제공하고 있다. 서울에도 인터넷 액세스 포인트가 구축되어 전 세계 엣지 로케이션으로 구성된 글로벌 네트워크와 연결된다. 엣지 로케이션 위치에 대한 자세한 정보는 이곳에서 확인할 수 있다.

EC2나 S3의 데이터에 접근을 했을 때 CloudFront 서비스를 사용하지 않는다면 해당 리전에서 데이터를 직접 가져오므로 해당 리전이 멀리 떨어져 있다면 아무래도 비교적 지연 시간이 있을 수 밖에 없다. CloudFront는 오리진 서버에 위치한 원본 파일을 전세계에 위치한 에지 로케이션으로 배포하고 에지 로케이션은 이 데이터를 캐싱하며 사용자는 자신의 위치와 가까운 에지 로케이션에서 캐싱된 데이터를 제공 받으므로 이런 문제를 어느 정도 해결할 수 있다. 오리진 서버는 S3 버킷, EC2 혹은 ELB(Elastic Load Balancer)와 같은 다른 AWS이거나 자체 오리진 서버일 수 있다.

ref : http://wildpup.cafe24.com/archives/830

HTTP Referer는 HTTP 헤더값으로서 웹 브라우저에서 생성하는 데이터입니다. 

http referer : 현재 페이지로 오기 전의페이지주소값이 담겨있는 환경변수

HTTP 환경변수의 HTTP_REFERER를 이용해서 어느정도 확인할 수 있습니다. 
대부분의 웹사이트 접속통계를 내주는 곳에서도 이런 방법으로 처리를 합니다. 

각 언어별로 HTTP_REFERER를 확인하는 방법은 아래와 같습니다. 
ASP => Request.ServerVariables("HTTP_REFERER") 
PHP => $_SERVER['HTTP_REFERER'] 
JSP => request.getHeader("REFERER") 

HTTP_REFERER의 값의 유무와 각 웹서버의 로그파일을 이용해서 
어떻게 방문했는지를 추출할 수 있습니다. 
1. 주소창에 주소를 입력해서 들어오는 경우 
- HTTP_REFERER의 값이 없음 
2. '즐겨찾기'를 이용해서 들어오는 경우(IE의 경우) 
- HTTP_REFERER의 값이 없음 
- 로그파일에 ..../favicon.ico로그가 먼저 남는다. 
- 이는 IE가 즐겨찾기를 눌러서 사이트를 방문할 경우 
favicon.ico 요청을 하고, 해당 URL의 요청을 하기때문입니다. 
3. 링크를 통해서 들어오는 경우. 
- HTTP_REFERER에 이전 URL정보가 들어있음. 
- e.g) http://search.empas.com/search/all.html?s=&f=&z=A&q=검색어 

이렇게 3가지 패턴으로 어느정도 확인을 할 수가 있습니다. 

추가적으로 어떤 검색엔진이나 사이트에서 링크를 통해서 들어왔는지는 
3번의 URL의 주소를 분석해서 알수 있습니다. 

배너광고나 검색엔진등에 등록했을때 유용하게 사용할 수 있습니다. 

ref : https://blog.naver.com/sungs6031/40011125523

서브도메인은 무엇입니까?

ref :https://kr.godaddy.com/help/what-is-a-subdomain-296

정적 웹 페이지 (Static Web Page)

• 서버(웹 서버, Web Server)에 미리 저장된 파일(HTML 파일, 이미지, JavaScript 파일 등)이 그대로 전달되는 웹 페이지
• 서버는 사용자가 요청(Request)에 해당하는 저장된 웹 페이지를 보냄
• 사용자는 서버에 저장된 데이터가 변경되지 않는 한 고정된 웹 페이지를 보게 됨

동적 웹 페이지 (Dynamic Web Page)

• 서버(웹 서버, Web Server)에 있는 데이터들을 스크립트에 의해 가공처리한 후 생성되어 전달되는 웹 페이지
• 서버는 사용자의 요청(Request)을 해석하여 데이터를 가공한 후 생성됭되는 웹 페이지를 보냄
• 사용자는 상황, 시간, 요청 등에 따라 달라지는 웹 페이지를 보게 됨

 인터넷을 이용하면서 보게되는 웹 페이지는 크게 두가지로 나눌 수 있습니다. 하나는 정적 웹 페이지이고 다른 하나는 동적 웹 페이지입니다.
정적 웹 페이지는 마치 컴퓨터에서 저장된 텍스트 파일을 메모장으로 열어보듯이 저장된 그대로 보는 것이며,
동적 웹 페이지는 그런 내용들이 다른 변수들에 의해서 변경되어 보여집니다. 가장 큰 차이는 사용자가 받아보는
웹 페이지가 동적으로 변하는가 아닌가에 있습니다.

 우리가 보는 대부분의 웹 페이지는 동적 웹 페이지라 할 수 있습니다. 커뮤니티 사이트에서 게시글을 본다거나, 뉴스 사이트에 올라오는 뉴스를
 본다거나, 포털 사이트 같은 곳에서 웹툰을 본다거나, 이런 웹 페이지는 사용자의 요청에 따라서 원하는 페이지를 동적으로 생성하여 보내주는
것입니다. 모두 동적 웹 페이지죠. 2000년대 초만 하더라도 정적 웹 페이지가 꽤 많았지만, 웹 서비스의 발전에 따라, 사용자 및 서비스 제공자의
요구를 충족시키기 위해, 현재는 대부분(모두가 아님) 동적 웹 페이지로 구성되어 있습니다. 서비스 제공자 입장에서, 예를 들어 쇼핑몰 운영자라
가정할 때, 정적인 웹 페이지로만 웹 페이지를 구성하게 되면 상품을 등록하거나 제거할 때, 회원관리할 때, 상품 재고 관리할 때 등 그때마다 정적
웹 페이지를 제작해줘야 하지만, 동적 웹 페이지로 웹 사이트를 구축하여 상품등록 및 관리, 회원가입 등에 해당하는 스크립트만 작성하고 자동으로
페이지가 생성되게 해주면 사이트 관리 비용이 절감되게 되는 것입니다.

 사용자 입장에서는 서버에서 처리된 웹 페이지를 전달받기 때문에 정적 웹 페이지와 동적 웹 페이지를 구분지을 필요가 없습니다.
결국 전달받는 웹 페이지는 HTML로 이루어진 웹 페이지기 때문이죠(JavaScript 등을 이용해서 클라이언트 측에서 동적으로 변하는 웹페이지도
 있습니다만 여기에서 설명하는 부분은 서버 측 기준이고, 스크립트 역시 정적인 데이터라 분류했기 때문에 여기에서 다루지 않습니다). 하지만
웹 사이트를 구축할려는 입장에서는 이런 부분에 대해서 최소한 개념적으로라도 이해를 해야한다고 생각합니다.

정적 웹 페이지 vs 동적 웹 페이지

• 정적 웹 페이지 장점
  • 빠르다 : 요청에 대한 파일만 전송하면 되기 때문에 추가적인 작업이 없음
  • 비용이 적다 : 마찬가지로 웹 서버만 구축하면 됨
• 정적 웹 페이지 단점
  • 서비스가 한정적이다 : 저장된 정보만 보여줄 수 있음
  • 관리가 힘들다 : 추가/수정/삭제의 작업 모두 수동
• 동적 웹 페이지 장점
  • 서비스가 다양하다 : 다양한 정보를 조합하여 동적으로 생성하여 제공 가능
  • 관리가 쉽다 : 웹 사이트 구조에 따라서 추가/수정/삭제 등의 작업이 용이
• 동적 웹 페이지 단점
  • 상대적으로 느리다 : 사용자에게 웹 페이지를 전달하기 전에 처리하는 작업이 필요
  • 추가 비용이 든다 : 웹 서버외에 추가적으로 처리를 위한 어플리케이션 서버(Web Application Server)가 필요

 동적 웹 사이트는 정적 웹 사이트와는 달리 서버 내부에서 추가적인 작업이 필요하기 때문에 서버 내부에 그런 작업들을 처리하기 위한
모듈 같은 것이 필요합니다. 설치형 사이트인 워드프레스의 경우를 보더라도 PHP와 MySQL를 요구합니다. 스크립트 처리기(PHP)와
데이터베이스(MySQL)입니다. 따라서 서버를 구성하실 때 해당 모듈을 설치해야 하며, 웹 호스팅을 이용할 때도 해당 모듈들을 제공하는
서비스를 선택해야합니다(대부분의 웹 호스팅은 PHP와 MySQL를 제공합니다. 하지만 요구 버전 등이 있으니 확인하셔야 합니다).
이런 모듈들은 서버의 자원(CPU, 메모리 등)을 이용하기 때문에 비용에 속합니다.이런 모듈들을 이용해서 동적 웹 페이지를 생성한다는 것
자체가 당연히 바로 전송하는 것보다 느립니다. 이런 부분도 비용에 해당합니다. 하지만 웹 사이트 구축과 운영/관리 측면에서 보면,
구조화된 웹사이트 구축과 관리의 용이성 때문에 전체적인 비용이 절감된다고 볼 수 있습니다. 정적 웹 페이지는 각각 독립되어 있기
때문에 같은 코드가 포함된다 해도 각각 따로 저장되어야 하지만(iframe 등의 태그 이용 제외), 동적 웹 페이지는 중복 코드는 하나의 파일로
만들어서 스크립트로 불러오기가 가능합니다. 따라서 구조화된 웹 사이트를 구축할 수 있으며, 수정 또한 정적 웹 페이지는 각각 페이지를
수정해줘야 하지만, 동적 웹 페이지는 공통된 부분 한번만 수정을 해서 전체 웹 사이트가 수정되는 효과를 가져올 수 있습니다.

 그렇다고 모두 동적 웹 페이지로 구성하고 정적 웹 페이지를 전혀 사용하지 않는 것은 아닙니다. 자주 변경되지 않은 페이지(About과 같은)의
 경우는 굳이 동적 웹 페이지로 만들 필요는 없습니다. 그리고 최근에는 정적 웹 페이지의 적은 비용이라는 장점을 이용하는 방법도
많이 사용됩니다. 정적 웹 페이지 생성기를 통해서 정적 웹 페이지로만 이루어진 블로그 등이 있습니다. 자신의 웹 사이트의 성격에 맞게,
각각 페이지 특성에 맞게 정적과 동적 웹 페이지를 적절하게 섞어서 사용하시면 되겠습니다.

ref : http://titus94.tistory.com/4

AWS 프리 티어에는 Amazon CloudWatch에서 사용할 수 있는 지표 10개, 경보 10개, API 요청 1,000,000건이 포함됩니다.

Amazon CloudWatch 작동 방식

Amazon CloudWatch는 기본적으로 지표 리포지토리입니다. AWS 서비스(예: Amazon EC2)는 지표를 리포지토리에 저장하므로 이러한 지표를 기반으로 통계를 검색할 수 있습니다. 사용자 지정 지표를 리포지토리에 저장하면 해당 지표에 대한 통계도 검색할 수 있습니다.

지표를 사용하여 통계를 계산한 다음 CloudWatch 콘솔에서 데이터를 그래픽으로 나타낼 수 있습니다.

특정 기준을 충족하는 경우 Amazon EC2 인스턴스를 중지, 시작 또는 종료하도록 경보 작업을 구성할 수 있습니다.

또한 Amazon EC2 Auto Scaling 및 Amazon Simple Notification Service(Amazon SNS) 작업을 대신 시작하는 경보를 만들 수 있습니다. 

CloudWatch 경보를 만드는 방법에 대한 자세한 내용은 개 경보 단원을 참조하십시오.

AWS 클라우드 컴퓨팅 리소스는 가용성이 매우 높은 데이터 설비에 있습니다. 확장성 및 안정성을 더욱 높이기 위해 각 데이터 센터 설비는 지역이라고 하는 특정 지리적 영역에 있습니다. 장애 격리 및 안정성을 최대한 높이기 위해 리전이 서로 완전히 분리되도록 설계되었습니다. 

Amazon CloudWatch에서는 지역 간 데이터는 집계하지 않습니다. 따라서 지표는 리전 간에 완전히 개별적입니다. 

자세한 내용은 Amazon Web Services 일반 참조의 리전 및 엔드포인트를 참조하십시오.

지표를 생성하여 CloudWatch에 전송하는 다른 AWS 리소스에 대한 자세한 내용은 Amazon CloudWatch 지표 및 차원 참조를 참조하십시오.

ref : https://docs.aws.amazon.com/ko_kr/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html

프리티어사용시 요금폭탄 막기위한 팁

프리티어로 AWS서비스를 체험하면서 프리티어로 사용할 수 있는 자원의 할당량만 사용한다면 요금이 청구될 일은 없습니다.

하지만 프리티어를 사용하면서 혹시 요금이 발생할 수도 있는 부분에 대해서 체크해보고 청구되는 요금을 줄이시기 바랍니다.

AWS프리티어 사용가능 리소스

Elastic IP

Elastic IP주소는 ip주소를 고정으로 사용할 수 있도록 해주는 서비스입니다.

EC2가 stop/start 되는경우 ip주소가 매번 변경되는데 이를 EC2에 연결 해두고 Elastic ip주소로 접근하면 항상 같은 주소로 접근할 수 있게 됩니다.

http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html

프리티어에서 Elastic IP 1개를 무료로 사용할 수 있습니다.

하지만 Elastic IP는 EC2에 연결해두지 않으면 요금이 청구됩니다.

ip가 부족한 상황에서 Elastic ip를 만들어두고 EC2에 연결하지 않으면 ip가 만들어져 있지만 사용되지 않고 있으므로 요금이 청구됩니다.

또한, EC2에 연결해두었더라도 EC2가 stop되어있는 상태라면 요금이 청구됩니다.

만약 Elastic ip를 만들어두고 할당을 하지 않은 상태라면 실행중인 EC2에 할당 혹은 Elastic ip 삭제를 하시길 바랍니다.

RDS

RDS도 1개는 프리티어에서 무료로 사용할 수 있습니다.

다만, RDS생성시 Multi-AZ와 고성능 I/O인 Provisioned IOPS Storate를 사용하지 않도록 설정해야 합니다.

기본설정으로 [Yes]가 선택되어 있기때문에 많이 실수하는 부분입니다.

물론 돈을 내고서라도 이런 기능이 필요하시다면 선택을 하시면 되지만, 온전히 프리티어로 사용하고자 하신다면 [No]로 체크하시고 RDS를 생성하셔야 합니다.

ElastiCache

프리티어에서 ElastiCache 1개는 무료로 사용할 수 있습니다.무료사용 대상은 t2.micro 입니다.

아래 그림은 ElastiCache Redis를 생성할때 기본적으로 세팅되어있는 것들입니다.

[Node Type]에서 프리티어대상인 t2.micro를 선택하려고하면 비활성화되서 선택되지 않는것을 확인할 수 있습니다.

[Multi-AZ]가 체크해제해야 t2.micro를 선택할 수 있습니다.

EBS

EBS는 프리티어에서 30GB까지 무료로 사용할 수있습니다.

EC2생성시 기본세팅을 조정하지 않으셨다면 EC2 1개당 8GB의 EBS가 생성될 것입니다.

프리티어사용자라면 EC2를 1개만 사용할 것이기때문에 전혀 문제가 되지 않을것이라고 생각할 수 있습니다.

하지만 문제는 EC2를 stop하면 요금은 청구되지않지만 EBS는 여전히 사용중인 것으로 됩니다.

예를들어보겠습니다.

오전 10시에 EC2 1개를 생성하고 나서 30분뒤에 stop시켰습니다.

오전 11시에 EC2 1개를 생성하고 나서 40분뒤에 stop시켰습니다.

그렇게 반복적으로 총 6시간동안 6개의 EC2를 생성하고 1시간안에 stop할 경우 프리티어로서 EC2사용시간은 총 750시간에 전혀 영향을 미치지 않습니다.

총 6개의 EC2를 생성했지만 1시간에 1개의 EC2만 사용했으므로 문제가 없는것입니다.

하지만 문제는 EC2를 terminate시키지않고 stop만 시켰다는것입니다.

EC2를 terminate시킬경우 함께만들어진 EBS도 없어지게 됩니다.

하지만 위의 경우처럼 EC2 6개를 생성하고 stop만 해두었다면 6개의 EBS볼륨은 그대로 남아있게 됩니다.

8GB x 6개 = 48GB를 사용하고 있으므로 프리티어 30GB를 초과하게되어 요금이 발생합니다.

사용하지 않는 EC2가 있다면 stop이 아닌 terminate를 시켜주어 EBS 사용량 초과로 요금이 발생하는것을 막아주시길 바랍니다.

이외에 추가적으로 프리티어를 사용하면서 알아두어야할 사항들이 있다면 댓글로 알려주시기 바랍니다.

프리티어 사용하면서 현재 사용량을 알고싶은경우나 내가설정한 요금이상으로 요금이 발생할경우 알림을 받고싶을때 아래 포스팅을 참고하시기 바랍니다.

프리티어(Free Tier)사용량 확인하는 방법

AWS를 사용하는 용도는 매우 다양하실겁니다.

실제 운영하는 서비스에 적용시키신분도 계실것이고, 테스트용도 혹은 작은 서비스로 Free tier 유저로서만 사용하고 싶으신분들 계실겁니다.

AWS의 좋은점은 여러가지 다양하고 획기적인 서비스를 제공해주기도하지만 1년동안 주요 서비스들을 일정부분 무료로 사용할 수 있다는 것일겁니다.

AWS Free Tier 혜택보기

저는 이런 아마존의 프로모션 전략이 참 마음에 듭니다.

초기사용자를 유입시키고 계속 자사서비스를 사용하게 만들어서 나중에는 추가결제를 하도록 유도하는 방식은 처음부터 결제를 요구하는 서비스보다 효과적으로 느껴집니다.

하지만 프리티어 유저로서 무료로 사용하고 싶으신분들이 계실겁니다.

일부 개발자들은 프리티어 이상의 기능을 사용해서 요금이 발생하여 지불하기도 합니다.

그래서 우리는 요금이 청구되면 바로 알려주어서 해당 기능들을 끄도록 할 수 있습니다.

예상 청구요금 알림 받는 방법

하지만 그 이전에 현재 내가 프리티어 서비스 할당량중에 얼마나 쓰고있는지를 파악하고 예측하고 싶은 개발자들이 많을것 입니다.

AWS는 정말 대인배라고 생각됩니다.

Free Tier 사용량 확인하기

1. 내 계정에서 [Billing & Cost Management] 클릭

2. [대시보드]메뉴에서 [사용량별 상위프리티어 서비스] - [모두보기] 클릭

3. [사용량별 모든 프리 티어 서비스] 사용량 확인

사용량을 확인하셔서 현재 내가 프리티어 사용량중 얼마나 사용하고있는지 확인해볼 수 있습니다.

또한, 이대로 계속 사용할경우 이번달 내가 할당량중 얼마나 사용하게될지도 예상할 수 있습니다.

혹시 실수로 인스턴스를 terminate 시키지 않았거나 불필요하게 2개이상 서비스를 사용하고있었다면 이를 확인하고 불필요한 요금청구를 막을 수 있을것입니다.

AWS를 사용하면서 일정수준의 요금 이상이 청구될 예정일경우 알림을 받고싶은 경우가 있습니다.

1. 현재 Free Tier를 사용하고있는데 그 이상으로 돈이 청구되는걸 막고 싶은경우

2. 서비스를 운영중인데 월100$정도는 낼 의향이 있으나 그 이상은 지불하고 싶지 않은경우

3. 기타 내가 원하는 요금 이상으로 청구되는경우 알림 받고 싶은경우

매일매일 AWS 콘솔을 들어가서 Billing을 확인해보면 좋겠지만 여러분은 아주 바쁘고 귀찮은걸 싫어하기때문에 편리하게 확인을 하고 싶으실 겁니다.

AWS에서는일정 이상의 요금이 청구되는 경우 알림을 받아볼수있도록 서비스를 제공해주고 있습니다.

알림을 설정하는 방법에 대해서 소개하겠습니다.

1. [Billing & Cost Management]

2. [기본설정]

3. [결제 알림받기] 체크 - [기본 설정 저장]

4. [Create Alarm]

5. 알림받고 싶은 최소 금액 설정, 알림받을 메일주소 설정 - [Create Alarm]

예) 1$ 이상으로 청구가 될 예정인경우 알림을 보내줍니다. 

6. 생성 확인

실제로 1$이상이 청구될 예정이 될경우 제 메일로 알림이 온 예제 입니다.

메일로 알림이 오도록 해두어서 매일 확인할 필요가 없고 메일이 왔을때만 콘솔에 들어가서 Billing을 체크해주면 됩니다.

ref : http://gun0912.tistory.com/45

ref : http://gun0912.tistory.com/35

ref : http://gun0912.tistory.com/11

AWS 사이드 툴s  URL 

amazon linux 에 연결하여 GUI 로 폴더를 보면서 조작 할 수 있는 툴 (탐색기 같은 툴)

WinSCP is a popular SFTP client and FTP client for Microsoft Windows! Copy file between a local computer and remote servers using FTP, FTPS, SCP, SFTP, WebDAV or S3 file transfer protocols.

https://winscp.net/eng/download.php

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

ssh key 를 생성하거나 원격으로 Amazon Linux 에 접속 할 수 있는 툴

Amazon S3   를 위한 GUI 툴

CloudBerry Explorer

https://www.cloudberrylab.com/explorer/amazon-s3.aspx

Details

How could I remove custom metrics in CloudWatch? Posted by: oneskyapp Posted on: May 15, 2011 9:07 PM   Reply This question is not answered. Answer it to earn points. Hi there,  We've justed added some custom metrics for testing and found nowhere to remove them from CloudWatch. Please kindly help, thanks! OneSkyApp Replies: 10 | Pages: 1 - Last Post: Nov 20, 2017 1:19 PM by: jtscott

Re: How could I remove custom metrics in CloudWatch? Posted by:  D. Svanlund  Posted on: May 16, 2011 12:48 PM  in response to: oneskyapp   Reply CloudWatch metrics are stored for two weeks. Old data will be removed automatically.

Re: How could I remove custom metrics in CloudWatch? Posted by: rakesh_ Posted on: Sep 27, 2011 12:15 AM  in response to: D. Svanlund   Reply Is there no other way.. seeing them make me irritated.. One more qu: Will we be charged for these metrics even if don't use these.

Re: How could I remove custom metrics in CloudWatch? Posted by:  D. Svanlund  Posted on: Sep 27, 2011 12:30 AM  in response to: rakesh_   Reply It is currently not possible to delete CloudWatch metrics. But you will only be charged for the hours where you are actually putting data into your custom metric.

Re: How could I remove custom metrics in CloudWatch? Posted by: secgeek Posted on: Mar 19, 2015 1:58 PM  in response to: oneskyapp CloudWatch_issue.JPG (41.6 KB)   Reply Can someone explain the double InstanceName in the attached screen shot? The first time I specified the custom metric I hadn't included the InstanceName and the field was showing as blank even though a name had been defined for the Instance through the AWS console.  In assuming that the lack of an InstanceName was my fault I specified the it second time and also corrected the instanceID, but now it shows up twice.  I know there multiple mentions that metrics can not be deleted but any update that I might have missed on this issue?

Re: How could I remove custom metrics in CloudWatch? Posted by:  Joaquim@AWS Posted on: Mar 23, 2015 8:40 PM  in response to: oneskyapp   Reply Hi there oneskyapp, To confirm the answers that are already in this thread, the custom metrics are removed after two weeks. Quim.

Re: How could I remove custom metrics in CloudWatch? Posted by:  Joaquim@AWS Posted on: Mar 23, 2015 8:43 PM  in response to: rakesh_   Reply Hi Rakesh_ Unfortunately there is no method to delete the metrics at this time. As also confirmed you will only be charged for metrics that are used. For more pricing details see the below link: http://aws.amazon.com/cloudwatch/pricing/ Quim.

Re: How could I remove custom metrics in CloudWatch? Posted by:  Joaquim@AWS Posted on: Mar 23, 2015 9:06 PM  in response to: secgeek   Reply Hi again oneskyapp, Unfortunately you have not missed anything, there is still no way to manually delete custom metrics. In regards to your question about the custom metrics screenshot, if you are still having issues PM me with the details and timelines and I will see if I can clarify what is going on. Quim.

Re: How could I remove custom metrics in CloudWatch? Posted by:  Joaquim@AWS Posted on: Mar 23, 2015 9:07 PM  in response to: oneskyapp   Reply Cannot remove manually. After 2 weeks with no data they are removed.

Re: How could I remove custom metrics in CloudWatch? Posted by: Neels Posted on: May 19, 2016 8:43 AM  in response to: Joaquim@AWS   Reply I still don't see a functionality to delete the custom metrics. Is that expected? Also, can we at least change the retention to 1 day as opposed to the default of 2 weeks?

Re: How could I remove custom metrics in CloudWatch? Posted by: jtscott Posted on: Nov 20, 2017 1:19 PM  in response to: Neels   Reply I'm still being billed for Firehose metrics that are no longer in use and the streams have been deleted already. It seems like the metrics must still be in use but not sure how or by what. Is there any ETA on an API to be able to delete custom metrics? Please confirm it is at least on the feature request list?

 ref : https://forums.aws.amazon.com/message.jspa?messageID=281904

[CPU 점유율이 높은 프로세스 종료시키기]

리눅스에서는 기본적으로 프로세스의 CPU 점유율이 한 자릿수입니다.

그런데 만일 두 자릿수가 존재한다면, 이는 해킹을 시도하는 백도어 파일일 가능성이 높습니다.

오늘 실습에서는 두 자릿수 프로세스를 백그라운드로 실행하고, 프로세스를 찾아 없애는 작업을 해보겠습니다.

일단 CPU를 잡아먹는 프로세스를 백그라운드로 실행시킵니다.

yes > /dev/null &

& 기호는 백그라운드에서 실행시킨다는 뜻입니다.

이 루프 계속 실행되는 것을 종료 시킬때는 ctrl + c

jobs 명령으로 백그라운드에서 돌아가는 프로세스를 확인할 수 있습니다.

이제 CPU 상태를 살펴 보겠습니다.

>top

CPU의 전반적인 상황이 실시간으로 보여집니다. 5초 간격으로 새로고침이 되는 중입니다.

Shift + P 키를 누르면, CPU 점유율이 높은 순으로 목록이 떨어집니다.

맨 위에 yes라는 프로세스가 무려 CPU의 98.9%를 차지하고 있네요. 엄청난 수치입니다.

해당 프로세스의 PID를 기억해둡니다.

PID: Process ID

이 프로세스를 없애기 위해서는, KILL 시그널을 보내줘야 합니다. 다음과 같은 명령어를 실행합니다.

>kill -9 20519

20519가 yes의 PID 입니다. kill -9를 쓰면 특정 프로세스를 종료시킬 수 있습니다.

*PID가 아닌 프로세스명으로 명령을 내리기 위해서는?

>killall 프로세스명

예를 들어 여기에서는 killall yes를 눌러도 프로세스 종료가 됩니다. 하지만 우리는 kill -9를 적용해보겠습니다.

네, 매우 정직하게도 죽었다고 메시지가 나왔습니다.

제대로 죽었는지 CPU에서 확인해봅시다.

>top

yes가 없어진 것을 확인할 수 있습니다.

**Tip!

top 상태를 벗어나지 않고 KILL 시그널을 수행하려면?

k 키를 눌러 PID를 입력하고 해당 시그널 번호를 입력해주면 수행된다.

ex> top → Shift+P → PID 확인 후 k 키→ PID → 9 (프로세스 종료)

ref : https://blog.naver.com/7meaning/60203209840

1. vi 실행하기

2. 입력모드 전환 명령어

3. 커서의 이동

4. 삭제

5. 복사와 붙여넣기

6. 문자열 찾기

7. 문자열 대체

8. 파일 저장 및 불러오기

9. 기타

녹색으로 표시한 명령어는 많이 사용하는 명령어이다.

ref : http://hyeonstorage.tistory.com/274

WinSCP를 사용하여 Linux 인스턴스로 파일 전송

WinSCP는 SFTP, SCP, FTP 및 FTPS 프로토콜을 사용하여 원격 컴퓨터로 파일을 업로드하고 전송할 수 있는 Windows용 GUI 기반 파일 관리자입니다. WinSCP를 사용하면 Windows 시스템에서 Linux 인스턴스로 파일을 끌어 놓거나 두 시스템 간에 전체 디렉터리 구조를 동기화할 수 있습니다.

WinSCP를 사용하려면 PuTTYgen을 사용하여 프라이빗 키 변환에서 생성한 프라이빗 키가 필요합니다. 또한 Linux 인스턴스의 퍼블릭 DNS 주소도 필요합니다.

1. http://winscp.net/eng/download.php에서 WinSCP를 다운로드하여 설치합니다. 대부분 사용자의 경우 기본 설치 옵션을 그대로 사용해도 좋습니다.

2. WinSCP를 시작합니다.

3. [WinSCP Login] 화면에서 [Host name]에 인스턴스의 퍼블릭 DNS 호스트 이름 또는 퍼블릭 IPv4 주소를 입력합니다.

   (IPv6 전용) 인스턴스의 IPv6 주소를 이용해 로그인하려면 인스턴스의 IPv6 주소를 입력합니다.

4. 사용자 이름에는 AMI의 기본 사용자 이름을 입력합니다.

   • Amazon Linux AMI의 경우 사용자 이름은 ec2-user입니다.

   • Centos AMI의 경우 사용자 이름은 centos입니다.

   • Debian AMI의 경우 사용자 이름은 admin 또는 root입니다.

   • Fedora AMI의 경우 사용자 이름은 ec2-user 또는 fedora입니다.

   • RHEL AMI의 경우 사용자 이름은 ec2-user 또는 root입니다.

   • SUSE AMI의 경우 사용자 이름은 ec2-user 또는 root입니다.

   • Ubuntu AMI의 경우 사용자 이름은 ubuntu 또는 root입니다.

   • ec2-user 및 root를 사용할 수 없는 경우 AMI 공급자에게 문의하십시오.

5. 인스턴스의 프라이빗 키를 지정합니다. [Private key]에서는 프라이빗 키의 경로를 입력하거나 ["..."] 버튼을 선택하여 파일을 찾아봅니다. 최신 WinSCP 버전의 경우 [Advanced]를 선택하여 고급 사이트 설정을 열고 [SSH]에서 [Authentication]을 선택하여 [Private key file] 설정을 찾습니다.

   다음은 WinSCP 버전 5.9.4의 스크린샷입니다.

   
   

   

   
   

   
   

   WinSCP에는 PuTTY 프라이빗 키 파일(.ppk)이 필요합니다. PuTTYgen을 사용하여 .pem 보안 키 파일을 .ppk 형식으로 변환할 수 있습니다. 자세한 내용은 PuTTYgen을 사용하여 프라이빗 키 변환 단원을 참조하십시오.

6. (선택 사항) 왼쪽 패널에서 [Directories]를 선택하고 파일을 추가할 디렉터리의 경로를 [Remote directory]에 입력합니다. 최신 WinSCP 버전의 경우 [Advanced]를 선택하여 고급 사이트 설정을 연 다음 [Environment]에서 [Directories]를 선택하여 [Remote directory] 설정을 찾습니다.

7. [Login]을 선택하여 연결하고 [Yes]를 선택하여 호스트 지문을 호스트 캐시에 추가합니다.

   

8. 연결이 설정된 후 연결 창에서 Linux 인스턴스는 오른쪽에 있고 로컬 시스템은 왼쪽에 있습니다. 로컬 시스템에서 원격 파일 시스템으로 파일을 직접 끌어 놓을 수 있습니다. WinSCP에 대한 자세한 내용은 http://winscp.net/eng/docs/start의 프로젝트 설명서를 참조하십시오.

   "Cannot execute SCP to start transfer" 오류가 표시되는 경우 먼저 Linux 인스턴스에 scp를 설치해야 합니다. 일부 운영 체제의 경우, 이 명령어는 openssh-clients 패키지에 있습니다. Amazon ECS 최적화 AMI 같은 Amazon Linux 변형의 경우에는 다음 명령을 사용하여 scp를 설치하십시오.

   [ec2-user ~]$ sudo yum install -y openssh-clients

ref : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/putty.html