반응형

Tutorial: Setting Up Node.js on an Amazon EC2 Instance

A common scenario for using Node.js with the SDK for JavaScript is to set up and run a Node.js web application on an Amazon Elastic Compute Cloud (Amazon EC2) instance. In this tutorial, you will create a Linux instance, connect to it using SSH, and then install Node.js to run on that instance.

Prerequisites

This tutorial assumes that you have already launched a Linux instance with a public DNS name that is reachable from the Internet and to which you are able to connect using SSH. For more information, see Step 1: Launch an Instance in the Amazon EC2 User Guide for Linux Instances.

You must also have configured your security group to allow SSH (port 22), HTTP (port 80), and HTTPS (port 443) connections. For more information about these prerequisites, see Setting Up with Amazon EC2 in the Amazon EC2 User Guide for Linux Instances.

Procedure

The following procedure helps you install Node.js on an Amazon Linux instance. You can use this server to host a Node.js web application.

To set up Node.js on your Linux instance

  1. Connect to your Linux instance as ec2-user using SSH.

  2. Install the current version of node version manager (nvm) by typing the following at the command line to install version 33.8.

    curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash

    We will use nvm to install Node.js because nvm can install multiple versions of Node.js and allow you to switch between them. See the nvm repo on GitHub for the current version to install.

  3. Activate nvm by typing the following at the command line.

    . ~/.nvm/nvm.sh
  4. Use nvm to install the version of Node.js you intend to use by typing the following at the command line.

    nvm install 6.11.5

    To install the latest LTS (long-term-support) release of Node.js, type the following at the command line.

    nvm install --lts

    Installing Node.js also installs the Node Package Manager (npm) so you can install additional modules as needed.

  5. Test that Node.js is installed and running correctly by typing the following at the command line.

    node -e "console.log('Running Node.js ' + process.version)"

    This should display the following message that confirms the installed version of Node.js running.

    Running Node.js v6.11.5


Creating an Amazon Machine Image

After you install Node.js on an Amazon EC2 instance, you can create an Amazon Machine Image (AMI) from that instance. Creating an AMI makes it easy to provision multiple Amazon EC2 instances with the same Node.js installation. For more information about creating an AMI from an existing instance, see Creating an Amazon EBS-Backed Linux AMI in the Amazon EC2 User Guide for Linux Instances.

Installing Node.js on Enterprise Linux

For instructions on how to install Node.js on any Red Hat® Enterprise Linux® / RHEL, CentOS and Fedora or other distributions, see the following Node.js documentation at https://nodejs.org/en/download/package-manager/.





Hello world 예제

기본적으로 이 앱은 여러분이 작성할 수 있는 가장 간단한 Express 앱일 것입니다. 이 앱은 하나의 파일로 된 앱이며 Express 생성기를 통해 얻게 되는 앱과는 같지 않습니다. (이 예제와 달리 Express 생성기를 통해 얻게 되는 앱은 다양한 목적을 위한 여러 JavaScript 파일, Jade 템플리트 및 하위 디렉토리를 포함하는 전체 앱에 대한 스캐폴딩을 작성합니다.)

먼저, myapp이라는 이름의 디렉토리를 작성한 후 이 디렉토리로 이동하여 npm init를 실행하십시오. 이후 설치 안내서에 따라 express를 종속 항목으로서 설치하십시오.

myapp 디렉토리에 app.js라는 이름의 파일을 작성한 후 다음과 같은 코드를 추가하십시오.



1
2
3
4
5
6
7
8
9
10
11
var express = require('express');
var app = express();
 
app.get('/'function (req, res) {
  res.send('Hello World!');
});
 
app.listen(3000function () {
  console.log('Example app listening on port 3000!');
});
 




앱은 서버를 시작하며 3000번 포트에서 연결을 청취합니다. 앱은 루트 URL(/) 또는 라우트에 대한 요청에 “Hello World!”로 응답합니다. 다른 모든 경로에 대해서는 404 Not Found로 응답합니다.

req(요청) 및 res(응답)는 Node가 제공하는 동일한 오브젝트이며, 따라서 req.pipe()req.on('data', callback) 그리고 Express의 관여가 필요 없는 다른 모든 항목을 호출할 수 있습니다.

다음의 명령을 이용하여 앱을 실행하십시오.


$ node app.js





ref : https://docs.aws.amazon.com/ko_kr/sdk-for-javascript/v2/developer-guide/setting-up-node-on-ec2-instance.html

ref : http://expressjs.com/ko/starter/hello-world.html

반응형
반응형

Open a terminal and write-

  1. cd /tmp
  2. wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
  3. sudo dpkg -i google-chrome-stable_current_amd64.deb
  4.  

The 32-bit version is no longer available.

If you encounter any errors simply use

  1. sudo apt-get -f install
  2.  

To run it from terminal use google-chrome or hit the super key and search Google or Chrome









ubuntu 16.04 에서 chrome 설치하기.


인프런 강의를 하나 듣기 시작했다. 크롤링을 한번 해보고 싶었는데, 막상 시작을 하려고 하니 어디서 시작을 해야할지 감이 오지 않았다. 그래서 혹시나 강의가 있지 않나 해서 검색을 하니, 역시나 검색이 되어서 나온다. 세상에는 참 고마운 분들이 많은 것 같다. 나도 지금까지 일해온 것들을 정리해서 하나씩 공유하고 싶었는데, 막상 시작하려니 쉽지가 않다. 그리고 트렌드 자체가 바뀌어 버려서 정작 내용을 정리해서 공유하더라도 누가 관심을 가져 주겠나 하는 탄식도 하게 되어서, 계속 머뭇거리고는 있다. 좀 더 내공을 쌓으면 시도해봐야겠다. 언제 내공이 쌓일지... 

강의는 "파이썬을 이용한 웹 크롤링 서비스 어플리케이션 만들기" 이다. 쉽게 개념과 실전을 설명을 원큐님이 해주셔서 많은 도움이 된 것 같다. 크롤링을 하기 위해서 웹페이지의 요소를 분석을 하는 부분이 있다. 이런 기능을 처음 알게 되었는데, 이 기능을 이용하니깐 지금 보고 있는 요소가 HTML 의 어디에 해당하는지를 금방 알 수 있었다. 툴의 사용법을 잘 익히는 사람이 참 부럽기도 하는데, 한 가지 기술을 쉽게 하나 알게 되었다. 요소를 표현하는 방법이 CSS 와 xpath 를 이용한 방법이 있다는 것을 알게 되었고, 이러한 형태로 웹 브라우저가 기능을 제공한다면 확인해볼 수 있다. 윈도우에서 chrome 을 사용하고 있는 나는 바로 이것을 시도해봤다. 그러나, 윈도우의 chrome 에서는 이 기능이 지원되지 않는 것 같다. 결국 이 기능을 확인해보려면, 원큐님이 사용하고 있는 환경에서 해보는 수 밖에 없었다. 어짜피 강의의 예제도 실행해볼 겸, virtualbox 를 이용해서 ubuntu 16.04 를 설치했다. 기본적인 빌드 환경을 설치해놓고, ubuntu 에서 기본적으로 제공하는 firefox 를 실행해서, 확인해보는 것을 시도했다. 그러나, firefox에서는 요소에 대해서 CSS 를 이용한 표현법만 제공을 했다. 난감했다. 이거 하나 확인해보겠다고 virtualbox, ubuntu 까지 설치했는데... 이제는 ubuntu 에서 chrome 을 설치해야겠다는 생각이 들었다. chrome 웹 사이트 접속해서 다운로드하고 실행. 그러나 진행은 제대로 되지 않고... 파일 자체를 받아서 수작업으로 설치를 시작했지만, 종속성 때문에 설치가 되지 않는 듯 했다.

수작업으로 설치한 내용은,

sudo dpkg -i google-chrome-stable_current_amd64.deb

chrome 데비안 패키지 많으로는 설치가 되지 않는다. libappindicator1 와 ca-certificates 패키지가 우선적으로 설치 되어야 한다.

기존에 실패한 패키지 작업을 되돌리기 위해서,

sudo apt-get remove google-chrome-stable

종속성을 가지는 패키지를 우선 설치하고, 다시 chrome 설치를 시도했다. 

sudo apt-get install ca-certificates

sudo apt-get install libappindicator1

sudo dpkg -i google-chrome-stable_current_amd64.deb

무사히, chome 을 설치할 수 있었다.

어이없는 상황이 발생했는데, xpath 확인은 윈도우의 chrome 에서도 확인할 수 있었다. 웹 페이지의 컨텍스트 메뉴에서 바로 볼 수 있다고 생각하고 시도했었는데, 그것이 아니라 요소 검사 윈도우에서 특정 요소에 대해 컨텍스트 메뉴를 이용해야 하는 것이었다. 삽질을 엄청하긴 했지만, chrome 을 설치했다는 부분으로 만족하는 수 밖에... 종종 차분하지 못한 나의 모습이 안타깝게 느껴지긴 한다.








크롬 실행


Symbolic Link터미널에서 웹브라우저(Chrome) 열기

#Ubuntu 16.04 LTS


 시작 전 테스트환경 살피기

   Time

    2017년 08월 18일

   OS

    Linux(Ubuntu 16.04 LTS)



기본적으로 터미널에서 firefox를 실행시키면 실행이된다.

하지만, 동일한 방법으로 chrome을 실행시키면 열리지 않는다. 


# firefox 


# chrome

chrome: command not found



이유는 실행파일의 위치를 정의해 놓은 환경변수( PATH )에 크롬의 위치가 정의되어있지 않기 때문이다.

이를 해결하는 방법은 두 가지가 있다.



1. 환경변수( PATH ) 파일 편집


- 환경변수 파일을 편집하여 크롭에 속해 있는 폴더를 환경변수에 추가 시킨다.



2. 크롬파일 이동


- 크롬파일을 이미 환경변수에 등록되어 있는 폴더에 옮긴다.


A. locate 명령어로 실행파일의 위치를 찾는다. (  /opt/google/chrome 에 위치해있다. )

B. 위 폴더로 이동 후 ls를 쳐보면 녹색파일( chrome )을 볼 수 있는데 이것이 바로 실행파일이다.

C. /opt/google/chrome/ 에 있는 chrome 파일의 심볼릭링크 파일을 일반 유저들이 자주 쓰는 어플리케이션들이 담겨있는 /usr/bin 에 만든다.

sudo ln -s /opt/google/chrome/chrome /usr/bin/chrome


- 링크파일을 만드는 명령어 ln에 심볼릭링크 옵션 -s를 주고 앞에는 파일이 있는 절대경로, 뒤에는 만들고자하는 파일의 위치를 적어준다.


D. 터미널창에 Chrome이라고 쳐서 실행되는지 확인한다.




+ Tips


1. 아래 명령어를 터미널에 입력하면 해당 url로 chrome을 통해서 이동한다.

# chrome 홈페이지url


- 컴퓨터에 저장되어 있는 html 문서또한 절대경로 혹은 상대경로를 적어주면 열린다.





ref : https://www.quora.com/How-do-you-install-chrome-on-Ubuntu


반응형
반응형


무료 아마존 웹 서비스, 100% 알뜰하게 사용하는 방법


아마존 웹 서비스(Amazon Web Services)의 무료 서비스인 '프리 티어'(free tier)는 디딤돌 정도로 생각하면 가장 적절하다. AWS와 EC2의 기본 메카니즘에 흠뻑 빠지게 하고 가상 머신 인스턴스와 스토리지, 데이터, 네트워킹을 다루는 아마존의 방식을 이해시키고 궁극적으로는 유료 AWS로 유인하려는 징검다리인 것이다. 또한 어떻게 AWS 사용을 관리하고 제한하는지도 배울 수 있는데 부주의하게 사용하면 '프리 티어'라고 해도 결국 비용을 지불해야 하는 상황에 직면할 수 있다.
 
따라서 여기서는 프리 티어의 무료 사용 조건을 자세하게 살펴보고 그 제한 범위 내에서 무엇이 가능한지 실용적인지도 상세하게 살펴본다. 아마도 거의 모든 AWS 사용자들은 아마존 클라우드가 제공하는 모든 혜택을 누리고 싶어할 것이다. 그렇다면 무료 서비스도 최대한 활용해야 할지 않을까. 프리 티어는 AWS를 시험해보고 몇몇 프로젝트를 시작해보고 심지어 기능적 애플리케이션까지 구축해보는 매우 훌륭한 방법이다.
 
한 가지 덧붙이면,  아마존의 프리 티어 관련 설명 중에는 “아마존은 이 무료 사용의 신규 등록을 언제라도 중단할 수 있다”라는 불길한 문장이 포함돼 있다. 이 문구는 아마존의 입장에서 보면 일종의 면피책이 될 수 있지만 만약 무료 계정을 사용해 볼 생각이 있다면 아마존이 중단하기 전에 지금 바로 실행하는 것이 좋을 것이다.
 
월 0달러로 무엇을 얻을 수 있나
AWS 무료 사용 티어(AWS Free Usage Tier)는 설정과 실행을 하기에 충분할 정도의 다양한 AWS 요소들을 제공한다. 유용한 무언가를 개발할 필요한 모든 것을 지원해 주지는 않지만 분명히 무언가 기능적인 성과물을 만들어낼 수 있다. 가장 대표적인 다음과 같은 것들이다.
 
서버 : 613MB의 RAM과 함께 구성된 EC2상에 리눅스나 윈도우 서버 마이크로 인스턴스를 월 750시간까지 실행할 수 있다. 이는 한달 내내 무료로 연속적으로 사용할 수 있다는 것을 의미한다.
 
아마존은 다량의 우분투 서버 12.04와 12.10, 마이크로소프트 윈도우 서버 2008과 2012, 그리고 아마존의 자체 아마존 리눅스 AMI(Amazon Linux AMI)등을 포함한 각기 다른 리눅스와 윈도우 시스템들을 실행할 수 있게 해주는 AMI(Amazon Machine Images) 카탈로그를 지원한다.

모든 AMI를 무료로 사용할 수 있는 것은 아니지만 실행 가능한 것들이 다수 포함돼 있다. AWS 마켓플레이스(AWS marketplace)에도 역시 AMI 인스턴스로 이용할 수 있는 다양한 서드파티 애플리케이션 어플라이언스들과 서버가 있지만 이를 모두 무료로 사용할 수는 없다.  
 
스토리지 : EC2 인스턴스는 스토리지 공간 없이는 별로 쓸모가 없다. 프리 티어는 기본적으로 30GB의 엘라스틱 블록 스토리지(Elastic Block Storage)와 5GB의 아마존 S3 스토리지, 200만 I/O, 그리고 1GB의 스냅샷 스토리지가 제공된다. I/O 사용량 한도에 주목해보자. 아마존은 I/O에 따라 과금하기 때문에 여기에서 문제가 복잡해질 수 있다.

프리 티어를 넘어서면 아마존은 월 100만 I/O마다 10센트씩 요금을 부과하는데 주어진 인스턴스에 의해 사용되는 I/O의 양은 이를 어떻게 사용하느냐에 따라 크게 달라질 수 있다. (잠시 후 이를 관리하는 팁을 살펴본다)
 
데이터베이스 : 아마존의 관계형 데이터베이스 서비스(Relational Database Services)에는 MySQL, 오라클(Oracle) BYOL, 혹은 마이크로소프트 SQL 서버 익스프레스(SQL Server Express) 등이 포함돼 있다. 사용자는 이 중 선택할 수 있으며 각각 월 750시간, 20GB의 스토리지, 1000만 I/O, 20GB의 백업 스토리지 등을 제공받는다.

NoSQL을 선호하는 이들의 경우 아마존은 이를 다이나모DB(DynamoDB) 형태로 제공하지만 프리 티어에는 단 100MB의 스토리지만 제공한다. 여기서도 또다시 I/O 추산이 복잡해지지만 저-트래픽, 데이터베이스-주도형 사이트를 테스트하기에는 충분하기 때문에 크게 문제가 되지는 않을 것이다.
 
데이터 전송 : 이 부분은 쉽다. 15GB의 외부 송출 대역폭이 모든 AWS 기능에 걸쳐 주어진다. 이해를 돕기 위해 예를 들면 월 5000명의 방문객이 오는 필자의 개인 사이트는 월 1.2GB의 대역폭을 소모한다. 비교적 간단하거나 개인적인 웹사이트의 경우 15GB는 충분하고도 남는 수준이다.
 
제약은 무엇인가
이제 나쁜 소식을 들려줄 차례다. 아마존은 프리 티어 사용에 엄격한 조건들을 덧붙였다. 앞서 설명한 사용량 외에도 다른 제한사항이 많다.
 
핵심 서비스는 단 12개월만 무료 : EC2, S3, RDS등을 포함한 대부분의 주요 AWS 서비스는 최초 등록 이후 12개월만 무료로 사용할 수 있다. 그 기간이 지나면 보통의 요금제와 마찬가지로 사용한 만큼 돈을 지불해야 한다.

다행인 것은 일부 서비스의 경우 12개월 이후에도 프리 티어로 사용할 수 있다는 것이다. 다이나모DB, 심플 워크플로(Simple Workflow), 심플 큐 서비스(Simple Queue Service), 심플 노티피케이션 서비스(Simple Notification Service), 아마존 엘라스틱 트랜스코더(Amazon Elastic Transcoder) 클라우드워치(CloudWatch) 등이 대표적이다.
 
CPU(와 대역폭) 감속을 예상하라 : 마이크로 인스턴스는 간헐적으로 수요가 폭증할 때를 대비해 최대 CPU에 맞춰 공급하도록 설계됐다. 아마존은 '연산 유닛'(compute unite)이라 부르는 전체의 연속적인 인스턴스는 공급하지 않는데 이를 위해서는 M1 스몰 인스턴스로 업그레이드해야 한다. 이를 통해 아마존의 표현대로라면 마이크로 인스턴스를 '추가적인 연산 사이클을 주기적으로 필요로 하는 낮은 스루풋 애플리케이션과 웹사이트에 적합'하게 만들어준다.
 
CPU가 가끔씩 100퍼센트까지 치솟게 만드는 애플리케이션을 실행한다면 문제는 없을 것이다. 그러나 장시간 CPU를 100퍼센트로 고정시키는 앱이라면 처음에는 100퍼센트로 실행되지만 차후 감속된다. 감속 머신의 내부 통계는 여전히 CPU가 100퍼센트로 실행되고 있다고 보고하기 때문에 이에 속으면 안 된다는 점을 명심하라.
  
아마존의 EC2 대시보드를 통해 사용량 통계를 모니터할 수 있지만 실행 기계 내부의 통계에서 더욱 세분화된 정보를 얻을 수 있다.
 
프리 티어의 윈도우 서버 인스턴스가 부족할 수 있다. 또 무엇을 계획하느냐에 따라 윈도우 서버 인스턴스에 할당된 메모리가 이를 실행하기에 불충분할 수도 있다. 정적 웹페이지를 유지하는 정도라면 문제될 것이 없다. 필자는 MySQL/아파치(Apache) 인스턴스를 그런 머신에 (AMPPS 웹 스택을 통해) 설치해 20%정도의 RAM을 남기고 실행할 수 있었다.
 
만약 AWS 호스트된 데이터베이스 인스턴스(RDS)를 통해 데이터베이스를 사용하고 있다면, 다행이도 이 데이터베이스는 전적으로 실행중인 머신과 분리되어 시작된다. 이 때문에 RDS로 인해 사용하는 실제 인스턴스상에 데이터베이스 서버를 실행해 훨씬 많은 메모리를 잡아먹게될 걱정을 할 필요가 없어진다.
 
기본 설정상 일관된 IP 주소를 쓸 수 없다 : 프리 티어는 AWS가 주소를 할당하는 방식이기 때문에 인스턴스는 고정 IP 주소나 일관된 사설 DNS 이름이 자동적으로 따라오지 않는다. 이 때문에 사용하는 인스턴스 재설정이 IP 주소 역시 재설정시켜 일종의 DNS 기술을 적용하지 않으면 외부 사용 목적의 무료 사이트 호스팅을 하기 어렵다.
 
다행히도 이런 문제는 해결하기 비교적 쉽다. 만약 누구나 지금 서비스하는 서버에 지속적으로 접속할 수 있도록 하려면 EC2 엘라스틱 IP 주소(EC2 Elastic IP Addresses)를 사용해 무료 인스턴스에 고정 IP를 제공할 수 있다. 단 주소를 보관한 채 실제로 이를 인스턴스와 연결하지 않는다면 소정의 요금이 부과될 것이다.
 
프리 티어, 100% 활용하기
분명 프리 티어에는 많은 함정들이 있다. 자원 제약들은 사용자가 미리 조심하지 않으면 너무나도 쉽게 넘어서게 되어 있다. 따라서 마이크로 인스턴스 최대한을 활용하고 싶다면 다음과 같은 점을 반드시 명심하기 바란다.
 
요금에 신경써라 : 말할 필요도 없겠지만 정기적으로 AWS 계정 활동 페이지를 체크해 아무도 모르게 요금이 부과되지 않는지 확인하라. 기본 설정상 아마존은 프리 티어 한도를 넘어서서 요금이 부과되더라도 따로 알려주지 않는다. 별도의 통지도 없이 사용 초과분만큼 그대로 요금이 부과된다.

만약 추정 사용량에 대한 알림을 받고싶거나 정해 놓은 예산을 초과할때 경고를 받고 싶다면 아마존이 제공하는 요금 경고 시스템을 사용하면 된다. 그러나 프리 티어에서는 설정가능한 경고와 알림의 수가 제한되어 있다.
 
I/O 사용량을 챙겨라 : 만약 개인용도로 서버를 사용한다면 I/O 요금 폭탄을 맞을 일은 없을 것이다. 그러나 서버를 공공으로 돌리면 상황이 하늘과 땅차이로 완전히 뒤바뀔 수도 있다.
 
인스턴스 I/O 사용량을 알아내는건 그리 어렵지 않지만 성실성과 정밀한 조사가 필요하다.  EC2 관리 콘솔은 모니터링 툴을 제공하지만 프리 티어의 콘솔은 유료 콘솔만큼 세분화되어 있지 않다. 무료 인스턴스를 오분 간격으로 체크하는데 유료일 경우 일분 간격으로 사용량을 볼 수 있다.
 
또한 인스턴스 자체 내에서도 OS의 자체 툴을 사용해 I/O 사용량을 확인할 수 있다. 리눅스 운영체제에서 사용할 수 있는 방법 하나를 소개한다. 윈도우내에서는 초당 디스크 전송(Disk Transfer) 성능 카운터를 사용할 수 있다.
  
아마존 리포팅 시스템을 통해 서비스 요금을 추적할 수 있고 CSV/XML 포맷의 세부 내역도 다운로드 할 수 있다.
 
골치 아픈 일을 피하기 위해 엘라스틱 주소를 할당하라 : 엘라스틱 주소(elastic address)를 사용하면 크게 요금이 늘어나지도 않으면서 훨씬 시스템에 연결하기 쉬워진다. 원격 데스크톱(Remote Desktop) 연결 툴이 연결 주소와 암호를 모두 저장하기 때문에 특히 윈도우 인스턴스에서는 더 편리하다. 그렇지 않으면 사이트가 새로운 IP 주소로 프로비저닝할 때마다 완전히 새로운 원격 데스크톱 연결을 만들어야 한다.
 
클라우드에 아이템들을 백업하라 : 작업중인 서버는 언제 고장나서 초기화 될지 모른다. 귀찮은 재 업로드를 하는 대신 아마존 클라우드에 적절한 데이터를 미리 넣어두는게 좋다. EBS 스냅샷(EBS Snapshot)은 이 작업을 위한 아주 편리한 방법 중 하나지만 프리 티어는 1GB의 스냅샷 스토리지 밖에 얻을 수 없다. 따라서 대신 시스템에서 외부 드라이브로 백업을 수행하는 방식처럼 EBS 볼륨을 덧붙여서 직접 파일을 백업할 수 있다.
 
그럼 이제 무엇을 해야 하나 
프리 티어 AWS에 어느 정도 익숙해지면 아마도 제대로 써보고 싶은 생각이 더 들 될 것이다. 마이크로 인스턴스의 차상위 단계는 M1 스몰 인스턴스로, 메모리가 두 배이고 온전한 연산-유닛치의 CPU가 제공된다. 대부분의 M1 인스턴스의 사용요금은 월 15달러에서 시작한다.
 
만약 일주일 내내 24시간 실행되는 서버가 필요하지 않은 구두쇠라면 스팟 인스턴스(spot instance)를 고려해 보라. 스팟 인스턴스는 시간당 지불할 의사가 있는 최대 가격을 특정지어 연산 용적을 입찰하는 식이다. 만약 스팟 인스턴스의 현재 시간당 가격이 (수요와 공급에 따라 변동적으로) 그 설정액을 초과하면 인스턴스가 자동으로 작동을 중단한다.
 
마지막으로 만약 백업 서버같이 무언가 자동으로 실행하고 싶다면, 예약 인스턴스(reserved instance)를 활용하라. 예약 인스턴스를 쓰면 일년에서 삼년 사이의 특정 기간에 일회 요금을 내고 상당폭 할인된 시간당 사용료로 이용할 수 있다. 예를 들어 지금 시점에서 단일 M1 스콜 리눅스 인스턴스는 연 61달러에 시간당 3.4센트인데 이를 100% 활용한다고 추정할 경우 연 354달러 정도 되는 가격이다.
 
M1 스몰, 스팟 인스턴스, 예약 인스턴스 모두 상당히 저렴한 가격이다. 프리 티어를 졸업해 이들 중 하나를 선택할 때가 되면 아마존의 툴을 사용하면서 비용을 절약하는 상당한 실전 경험을 가진 자신을 발견할 것이다. editor@idg.co.kr
  



스팟 인스턴스는 입찰을 통해 비사용 용량으로 기계를 실행하게 해준다. 이는 적은 돈으로 간헐적으로 기계를 구동하는 유용한 방식이다.




ref : http://www.itworld.co.kr/print/81311


반응형
반응형

사전 조건

PuTTY을(를) 사용하여 Linux 인스턴스에 연결하려면 먼저 다음 사전 요구 사항을 완료하십시오.

  • PuTTY 설치

    PuTTY 다운로드 페이지에서 PuTTY를 다운로드하여 설치합니다. 이미 이전 버전의 PuTTY가 설치되어 있다면 최신 버전을 다운로드하는 것이 좋습니다. 전체 제품군을 설치해야 합니다.

  • 인스턴스의 ID 보기

    Amazon EC2 콘솔을 사용하여 인스턴스의 ID를 볼 수 있습니다([Instance ID] 열에서). describe-instances(AWS CLI) 또는 Get-EC2Instance(Windows PowerShell용 AWS 도구) 명령을 사용할 수도 있습니다.

  • 인스턴스의 퍼블릭 DNS 이름 보기

    Amazon EC2 콘솔을 사용해서 사용자의 인스턴스에 대한 퍼블릭 DNS를 얻을 수 있습니다([Public DNS (IPv4)] 열 확인. 이 열이 숨겨진 경우는 [Show/Hide] 아이콘을 클릭하고 [Public DNS (IPv4)]를 선택). describe-instances(AWS CLI) 또는 Get-EC2Instance(Windows PowerShell용 AWS 도구) 명령을 사용할 수도 있습니다.

  • (IPv6 전용) 인스턴스의 IPv6 주소를 얻습니다.

    인스턴스에 IPv6 주소를 할당했다면 퍼블릭 IPv4 주소나 퍼블릭 IPv4 DNS 호스트 이름 대신 IPv6 주소를 사용하여 인스턴스에 연결할 수도 있습니다. 로컬 컴퓨터에 IPv6 주소가 있고 IPv6를 사용하도록 컴퓨터를 구성해야 합니다. Amazon EC2 콘솔을 사용하여 인스턴스의 IPv6 주소를 얻을 수 있습니다([IPv6 IPs] 필드 확인). describe-instances(AWS CLI) 또는 Get-EC2Instance(Windows PowerShell용 AWS 도구) 명령을 사용할 수도 있습니다. IPv6에 대한 자세한 내용은 IPv6 주소 단원을 참조하십시오.

  • 프라이빗 키 찾기

    인스턴스를 시작할 때 지정한 키 페어를 찾기 위해 .pem 파일의 컴퓨터 상 위치에 대한 정규화된 경로를 얻습니다.

  • 인스턴스를 시작하는 데 사용한 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 공급자에게 문의하십시오.

  • IP 주소에서 인스턴스로의 인바운드 SSH 트래픽 활성화

    인스턴스와 연관된 보안 그룹이 IP 주소로부터 들어오는 SSH 트래픽을 허용하는지 확인하십시오. 기본 보안 그룹은 기본적으로 들어오는 SSH 트래픽을 허용하지 않습니다. 자세한 내용은 Linux 인스턴스의 인바운드 트래픽 권한 부여 단원을 참조하십시오.





Install Ubuntu Desktop on AWS EC2

I assume that you already set up a VM on EC2 by choosing Ubuntu Server AMI.

First, install Ubuntu Desktop on the server instance by running the following command.

$ sudo apt-get install ubuntu-desktop

Reboot the VM instance.

Next, install VNC server on the VM.

$ sudo apt-get install tightvncserver

After installation, launch VNC server (as a non-root user):

$ vncserver :1

The first time you run VNC server, it will ask you for VNC password. The VNC password should be at least 6 characters and up to 8 characters long. If the typed password is longer than that, only the first 8 characters will be used.

Once VNC server is launched successfully, it will create ~/.vnc directory and configuration files in it. A log file for VNC server will be located at ~/.vnc/*.log







윈도우에서 Ubuntu (AWS EC2) GUI 이용

윈도우에서 AWS EC2에 올린 Ubuntu를 GUI로 접속할 일이 있었다.

그리고 몇 시간의 시도 끝에 해결!

[ubuntu] sudo apt-get update
[ubuntu] sudo apt-get install ubuntu-desktop

설치를 시도하면 알겠지만, ubuntu-desktop의 용량이 크다. (2G 넘었나?)

좀 더 작은 용량만으로 하고 싶다면 필수 패키지만 설치하는 방법이 있다. (작동은 똑같이 됨!

[ubuntu] sudo aptitude install --without-recommends ubuntu-desktop

이제 나머지 필요한 것들도 설치하자.

[ubuntu] sudo apt-get install tightvncserver gnome-panel gnome-settings-daemon metacity nautilus gnome-terminal

설치가 끝났다면 초기 세팅 파일을 만들기 위해 한번 VNC서버를 작동하자. (아마 비밀번호를 입력하라고 하는데 잘 기억해뒀다가 나중에 GUI접속을 할 때 사용하면 된다.)

[ubuntu] vncserver :1

그리고 설정파일을 수정하자.

[ubuntu] vi~/.vnc/xstartup

아래와 같이 수정해주면 된다.

#!/bin/sh

export XKL_XMODMAP_DISABLE=1
unset SESSION_MANAGER
unset DBUS_SESSION_BUS_ADDRESS

[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey

vncconfig -iconic &
gnome-panel &
gnome-settings-daemon &
metacity &
nautilus &
gnome-terminal &

변경된 사항을 반영하기 위해 서버를 끄고 다시 시작해주자.

[ubuntu] vncserver -kill :1
[ubuntu] vncserver :1

설정을 다 했으면 이제 SSH 터널을 설정해줘야 한다.

Putty를 켜서 EC2에 접속을 설정해둔 것을 LOAD한 후 다음과 같이 수정하자.

EC2에 접속하기 위해 사용하는 것을 Load! 해주자
1.1.1.1 대신 서버 IP주소를 입력해주고 Add 버튼을 누르면 된다.

이제 우리 로컬 5902포트에서 서버의 5901포트를 들어갈 수 있게 되는 것이다! 이제 AWS Management Console의 Security Groups 탭에 가서 5901포트틀 사용하겠다고 말해주면 된다.

마지막으로 Tight-VNC를 다운받아서 localhost::5902로 접속하면 된다.

localhost::5902로 접속을 누르고 위에서 설정했던 비밀번호를 입력하면 된다.

localhost::5902 로 접속하는 것은 Putty Configuration 을 통해서 먼저 EC2 에 접속 해놓은 다음에 연결이 가능한데 Remote Host: EC2_IP:5901   을 직접 기입하면 Putty Configuration 을 띄울 필요 없이 바로 원격 접속잉 가능하다

접속이 잘 안되면 

vncserver 를 kill 했다가 다시 켜보자

ref : https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/putty.html
ref : http://xmodulo.com/how-to-set-up-ubuntu-desktop-vm-on-amazon-ec2.html
ref : https://medium.com/@ggomma/%EC%9C%88%EB%8F%84%EC%9A%B0%EC%97%90%EC%84%9C-ubuntu-aws-ec2-gui-%EC%9D%B4%EC%9A%A9-ee2567a85d8f


반응형
반응형


아마존 ElastiCache 소개

다루는 내용

∙ 아마존 ElastiCache 클러스터 생성하기
∙ 아마존 ElastiCache 클러스터에 접근 권한 부여하기
∙ 아마존 ElastiCache 클러스터에 접속하여 명령 실행하기
∙ 아마존 ElastiCache 클러스터 삭제하기

 

 

실습


준비


 

1. Putty 다운로드
2. EC2 인스턴스

 

 


아마존 ElastiCache 클러스터 생성하기


 

1. 콘솔에서 ElastiCache 클릭
2. Get Started Now 클릭
3. Select Engine 섹션

· Redis 선택
· Next 클릭

4. Specify Cluster Details

· Replication Group Name : ECLabcluster
· Replication Group Description : ECLabcluster TEST
· Next 클릭

5. Configure Advanced Settings

· VPC Security Group(s) : default 선택
· Next 클릭

6. Review

· Launch Replication Group 클릭
· Close 클릭

 

 


아마존 ElastiCache 클러스터에 접근 권한 부여하기


 

EC2 인스턴스에서 ElastiCache 클러스터에 접속하기위한 설정

 

1. 콘솔에서 EC2 클릭
2. NETWORK & SECURITY  Security Groups 클릭
3. 앞에서 클러스터의 보안그룹을 default를 사용하도록 하였으므로 Group Name이 default인 보안그룹 선택
4. 화면 하단의 Inbound 탭 클릭
5. Edit 클릭
6. 클러스터 접속에 사용될 6379 포트 허용

· Type : Custom TCP Rule
· Protocol : TCP
· Port Range : 6379
· Source : 0.0.0.0/0

7. EC2 접속에 사용될 22 포트 허용

· Type : SSH
· Protocol : TCP
· Port Range : 22
· Source : 0.0.0.0/0 혹은 MyIP

 



 

 


아마존 ElastiCache 클러스터 사용하기


 

EC2 인스턴스에서 ElastiCache 클러스터에 접속하여 기본 명령을 실행해 본다.

 

1. Putty로 EC2 인스턴스 SSH 로그인

· “아마존 Elastic Compute Cloud(EC2) 소개” 문서 참고

2. telnet 유틸리티 설치

· sudo yum install telnet

3. ElastiCache 클러스터의 Endpoint에 접속

· 콘솔에서 ElastiCache 클릭
· 왼쪽 메뉴에서 Replication Groups 클릭
· 생성한 클러스터 그룹 선택 (예. eclabcluster)
· 상세화면에서 Primary Endpoint 확인
예. eclabcluster.ugaeqh.ng.0001.use1.cache.amazonaws.com:6379
telnet eclabcluster.ugaeqh.ng.0001.use1.cache.amazonaws.com 6379

4. Redis 명령 실행

 

 

※ ElastiCache는 캐시 클러스터에 액세스하는 모든 클라이언트가 Amazon VPC 네트워크에 위치해야 하며, 보안 그룹을 통해 인증되어야 합니다.

 

 


아마존 ElastiCache 삭제하기


 

1. 콘솔에서 ElastiCache 클릭
2. 왼쪽 메뉴에서 Replication Groups 클릭
3. 삭제할 클러스터 그룹 선택
4. Delete 클릭
5. Delete Replication Group 화면에서

· Create final snapshot? No
· Delete 클릭

6. 왼쪽 메뉴 Cache Clusters 선택하여 개별 클러스터 삭제도 가능하다.

 

 


참고


ref : https://blog.wisen.co.kr/?p=174

반응형
반응형

nodejs 설치 파일을 이용해 Linux에 설치하는 경우 향후 파일 시스템 접근 시 권한 문제가 발생할 수 있다. 예를 들어 Yeoman, Bower, Grunt등을 설치할 때 permission 문제가 발생하여 곤란을 겪을 수 있다. 여러 가지 방법을 찾아보고 실행해 본 결과, 가장 좋은 방법은 node.js를 설치 시에 ‘sudo’ permission이 아니라 일반 계정의 permission으로 설치를 하는 것이다.

기존 nodejs 제거

시스템에 이미 nodejs가 설치되어 있는 경우 이를 제거 한다.

$ sudo rm -r /usr/local/bin/node /usr/local/bin/npm /usr/local/include/node /usr/local/lib/node_modules /usr/local/share/man/man/node.1

자신 계정의 .npm 폴더를 제거한다.

$ rm -r ~/.npm $ rm -r .npm

nvm 설치

nvm 다운로드 및 설치

사용자 계정의 루트 폴더에서 nvm을 설치하기 위해 다음 명령을 수행한다.

curl https://raw.githubusercontent.com/creationix/nvm/v0.23.3/install.sh | bash

또는 curl 대신 wget을 이용할 수 있다.

wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.23.3/install.sh | bash

이제 shell에 .nvm 설정을 추가한다.

$ source ~/.bashrc

nodejs 설치

stable 버전 설치

nvm을 이용하여 sudo permission없이 node.js를 설치하자.

$ nvm install stable

이제 nodejs가 잘 설치되었는지 확인해보자.

$ node -v

이제, sudo 권한 없이도 node를 성공적으로 설치하였다.

설정 & Test

다음 명령을 통해 node version을 확인할 수 있다.

$ node -v

위 명령의 결과를 ~/.bashrc 파일에 추가한다. (v4.0.0이 그 결과라고 가정한다.)

nvm use v4.0.0 



ref : http://hochulshin.com/linux-nodejs-installation/


반응형
반응형

C.4. 리눅스의 장치 이름

리눅스에서 디스크와 파티션을 부르는 이름이 다른 운영 체제와 다르기도 합니다. 파티션을 만들고 파티션할 때 이 리눅스 이름을 알고 있어야 합니다. 기본적으로는 다음 규칙을 따릅니다:

  • 첫번째 플로피 디스크 드라이브는 /dev/fd0이라고 합니다.

  • 두번째 플로피 디스크 드라이브는 /dev/fd1이라고 합니다.

  • 첫번째 발견한 하드디스크의 이름은 /dev/sda입니다.

  • 두번째 발견한 하드디스크의 이름은 /dev/sdb이고, 그 이후는 마찬가지입니다.

  • 첫번째 SCSI CD-ROM은 /dev/scd0이라고 하고, /dev/sr0이라고도 합니다.

드라이브의 파티션 이름은 디스크 이름 뒤에 숫자를 붙입니다. sda1와 sda2는 각각 첫번째 SCSI 디스크의 첫번째와 두번째 파티션을 말합니다.

실제 예를 들어보면 다음과 같습니다. SCSI 디스크가 2개 있어서, 하나는 SCSI 주소 2에 연결되어 있고 다른 하나는 4에 연결되어 있습니다. 첫번째(2번 주소에 연결된) 디스크가 sda이고, 두번째(4번 주소에 연결된) 디스크가 sdb입니다. sda에 파티션이 3개이면, 그 파티션의 이름은 sda1sda2sda3입니다. sdb 디스크와 그 파티션도 같은 방식입니다.

SCSI 호스트 버스 어댑터(컨트롤러)가 2개 있으면 어느 드라이브가 첫번째가 될지 알기 어려울 수도 있습니다. 이 경우엔 부팅할 때 메시지를 잘 보고, 드라이브의 모델과 용량으로 파악하는 게 최선의 방법입니다.



Linux 인스턴스의 디바이스 명명

볼륨을 인스턴스에 연결할 때 해당 볼륨에 대한 디바이스 이름을 포함합니다. 이 디바이스 이름은 Amazon EC2에서 사용합니다. 인스턴스의 블록 디바이스 드라이버는 볼륨이 마운트될 때 실제 볼륨 이름을 할당하고 할당된 이름은 Amazon EC2에서 사용하는 이름과 다를 수 있습니다.


사용 가능한 디바이스 이름

다음 표에 Linux 인스턴스의 사용 가능한 디바이스 이름이 나와 있습니다. 인스턴스에 연결할 수 있는 볼륨의 수는 운영 체제에 따라 결정됩니다. 자세한 내용은 인스턴스 볼륨 제한 단원을 참조하십시오.

가상화 유형응시 가능루트 전용EBS 볼륨 추천인스턴스 스토리지 볼륨NVMe 볼륨

반가상화(PV)

/dev/sd[a-z]

/dev/sd[a-z][1-15]

/dev/hd[a-z]

/dev/hd[a-z][1-15]

/dev/sda1

/dev/sd[f-p]

/dev/sd[f-p][1-6]

/dev/sd[b-e]

/dev/sd[b-y] (hs1.8xlarge)

해당 사항 없음

HVM

/dev/sd[a-z]

/dev/xvd[b-c][a-z]

AMI에 따라 다름

/dev/sda1 또는 /dev/xvda

/dev/sd[f-p]

/dev/sd[b-e]

/dev/sd[b-h] (h1.16xlarge)

/dev/sd[b-y] (d2.8xlarge)

/dev/sd[b-y] (hs1.8xlarge)

/dev/sd[b-i] (i2.8xlarge)

/dev/nvme[0-26]n1 *

* NVMe 인스턴스 스토어 볼륨은 자동으로 열거되고 디바이스 이름이 할당됩니다. 블록 디바이스 매핑에 NVMe 인스턴스 스토어 볼륨을 지정할 필요가 없습니다.

인스턴스 스토어 볼륨에 대한 자세한 내용은 Amazon EC2 인스턴스 스토어 단원을 참조하십시오.

NVMe EBS 볼륨에 대한 자세한 내용은 Amazon EBS 및 NVMe 단원을 참조하십시오.

디바이스 이름 고려 사항

디바이스 이름을 선택할 때는 다음 사항에 주의하십시오.

  • 인스턴스 스토어 볼륨을 연결할 때 사용된 디바이스 이름을 사용하여 EBS 볼륨을 연결할 수 있지만, 이러한 경우 예기치 않은 동작이 발생할 수 있으므로 수행하지 않는 것이 좋습니다.

  • 커널의 블록 디바이스 드라이버에 따라 디바이스는 사용자가 지정한 것과는 다른 이름에 연결될 수 있습니다. 예를 들어 /dev/sdh라는 디바이스 이름을 지정할 경우 디바이스 이름이 /dev/xvdh 또는 /dev/hdh로 바뀔 수 있습니다. 대부분의 경우 뒤에 오는 문자는 그대로 유지됩니다. Red Hat Enterprise Linux의 일부 버전과 CentOS와 같은 Red Hat Enterprise Linux의 변형 버전에서는 뒤에 오는 문자가 변경될 수도 있습니다(즉 /dev/sda가 /dev/xvde로 바뀔 수 있음). 이 경우 각 디바이스 이름에서 뒤에 오는 문자는 같은 수로 늘어납니다. 예를 들어 /dev/sdb가 /dev/xvdf라는 이름으로 바뀌면 /dev/sdc는 /dev/xvdg로 이름이 바뀝니다. Amazon Linux AMI는 이름이 바뀐 디바이스에 지정한 이름에 대해 심볼 링크를 생성합니다. 다른 AMI는 다르게 작동할 수 있습니다.

  • 인스턴스의 NVMe 인스턴스 스토어 볼륨의 수는 인스턴스의 크기에 따라 다릅니다. 디바이스 이름은 /dev/nvme0n1/dev/nvme1n1 등입니다.

  • Linux 인스턴스에서는 반가상화(PV) 및 하드웨어 가상 머신(HVM)과 같은 두 가지 유형의 가상화를 사용할 수 있습니다. 인스턴스의 가상화 유형은 인스턴스를 시작할 때 사용된 AMI에 의해 결정됩니다. 인스턴스 유형에 따라 PV와 HVM을 모두 지원하거나, HVM 또는 PV만 지원합니다. 인스턴스의 가상화 유형에 따라 권장되고 사용 가능한 디바이스 이름이 다르기 때문에 AMI의 가상화 유형에 주의해야 합니다. 자세한 내용은 Linux AMI 가상화 유형 단원을 참조하십시오.

  • 뒤에 숫자가 있거나 있지 않고 디바이스 이름의 문자가 동일한 볼륨은 연결할 수 없습니다. 예를 들어, 볼륨을 /dev/sdc로 연결한 다음 다른 볼륨을 /dev/sdc1에 연결하면 인스턴스에서는 /dev/sdc만을 볼 수 있습니다. 디바이스 이름 끝에 숫자를 사용하려면 기본 문자가 동일한 모든 디바이스 이름의 끝에 숫자를 사용해야 합니다(/dev/sdc1/dev/sdc2/dev/sdc3 등).

  • 하드웨어 가상 머신(HVM) AMI는 디바이스 이름에 추적 번호를 사용하는 것을 지원하지 않습니다. 단, 루트 디바이스에 예약된 디바이스 이름은 예외입니다.

  • 일부 사용자 지정 커널은 사용을 /dev/sd[f-p] 또는 /dev/sd[f-p][1-6]으로 제한하는 제약 조건이 있을 수 있습니다. /dev/sd[q-z] 또는 /dev/sd[q-z][1-6]을 사용하는 데 문제가 있을 경우 /dev/sd[f-p] 또는 /dev/sd[f-p][1-6]으로 전환해 보십시오.


ref : https://www.debian.org/releases/stable/mips/apcs04.html.ko

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

반응형
반응형
S3 버킷을 삭제 하려고 할때 지우려는 사용자의 권한이 존재하지 않는데 삭제를 하려고 하면 접근 급지 에러가 뜨게 된다, 

이때는 해당 버킷 안에 들어가 > 권한 > 해당 사용자에게 권한을 부여 한다음 버킷 삭제를 처리하면된다



웹 사이트 액세스에 필요한 권한

예를 들어, 버킷을 웹 사이트로 구성하려면 제공할 객체를 공개 읽기로 설정합니다. 이를 위해 모든 사용자에게 s3:GetObject 권한을 부여하는 버킷 정책을 만듭니다. 웹 사이트 엔드포인트에서 존재하지 않는 객체를 사용자가 요청하는 경우, Amazon S3은 HTTP 응답 코드 404 (Not Found)를 반환합니다. 객체가 존재하지만 해당 객체에 대한 읽기 권한을 부여하지 않았다면 웹 사이트 엔드포인트는 HTTP 응답 코드 403 (Access Denied)을 반환합니다. 이 응답 코드를 사용하여 특정 객체가 존재하는지 여부를 유추할 수 있습니다. 이 동작을 원하지 않을 경우, 버킷에 웹 사이트 지원을 설정해서는 안 됩니다.

다음의 예제 버킷 정책은 모든 사용자에게 특정 폴더의 객체에 대한 액세스를 허용합니다. 버킷 정책에 대한 자세한 내용은 버킷 정책 및 사용자 정책 사용를 참조하십시오.

{ "Version":"2012-10-17", "Statement":[{ "Sid":"PublicReadGetObject", "Effect":"Allow", "Principal": "*", "Action":["s3:GetObject"], "Resource":["arn:aws:s3:::example-bucket/*" ] } ] }

ref : https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html





반응형
반응형

CloudFormation 템플릿 : 스크립트 파일이 템플릿 이라 불림

CloudFormation 템플릿 으로 CloudFormation 스택 을 생성하게 됨

스택 : 리소스 모음 , 하나의 단위로 관리할 수 있는 AWS  리소스 모음으로 생성, 업데이트 삭제되며

스택의 모든 리소스는 CloudFormation 템플릿에 의해서 정의된다

예를 들어 스택에는 웹 애플리케이션을 실행하는 데 필요한

모든 리소스(예: 웹 서버, 데이터베이스 및 네트워킹 규칙)가 포함될 수 있습니다.

해당 웹 애플리케이션이 더 이상 필요하지 않은 경우 간단히 스택을 삭제하면 관련 리소스가 모두 삭제됩니다.











스택 작업

스택이란 하나의 단위로 관리할 수 있는 AWS 리소스 모음입니다. 다시 말해서 스택을 생성, 업데이트 또는 삭제하여 리소스 모음을 생성, 업데이트 또는 삭제할 수 있습니다. 스택의 모든 리소스는 스택의 AWS CloudFormation 템플릿에 의해 정의됩니다. 예를 들어 스택에는 웹 애플리케이션을 실행하는 데 필요한 모든 리소스(예: 웹 서버, 데이터베이스 및 네트워킹 규칙)가 포함될 수 있습니다. 해당 웹 애플리케이션이 더 이상 필요하지 않은 경우 간단히 스택을 삭제하면 관련 리소스가 모두 삭제됩니다.

AWS CloudFormation은 모든 스택 리소스가 적절히 생성 또는 삭제되도록 합니다. AWS CloudFormation은 스택 리소스를 하나의 단위로 처리하기 때문에 스택을 생성하거나 삭제하려면 모든 리소스를 생성하거나 삭제해야 합니다. 리소스를 생성할 수 없는 경우 AWS CloudFormation은 해당 스택을 롤백하고 생성된 모든 리소스를 자동으로 삭제합니다. 리소스를 삭제할 수 없는 경우, 스택이 삭제될 때까지 나머지 모든 리소스가 그대로 유지됩니다.

AWS CloudFormation 콘솔API 또는 AWS CLI를 사용하여 스택으로 작업할 수 있습니다.

참고

스택을 곧바로 삭제했더라도 스택 리소스가 작동된 시간 동안 스택 리소스에 대한 책임은 사용자에게 있습니다.



ref : https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/stacks.html


반응형
반응형

 AWS CloudFormation에서 지원하는 리소스 유형 참조


AWS 리소스 유형 참조

이 단원에는 AWS CloudFormation에서 지원하는 모든 AWS 리소스에 대한 참조 정보가 포함되어 있습니다.

리소스 유형 식별자는 항상 다음 형식을 사용합니다.

AWS::aws-product-name::data-type-name

항목

ref : https://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/aws-template-resource-type-ref.html


반응형
반응형


AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker를 사용하여 Apache, Nginx, Passenger, IIS와 같은 친숙한 서버에서 개발된 웹 애플리케이션 및 서비스를 간편하게 배포하고 조정할 수 있는 서비스입니다.

코드를 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 자동 크기 조정부터 시작하여 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리합니다. 이뿐만 아니라 애플리케이션을 실행하는 데 필요한 AWS 리소스를 완벽하게 제어할 수 있으며 언제든지 기본 리소스에 액세스할 수 있습니다.

Elastic Beanstalk는 추가 비용 없이 애플리케이션을 저장 및 실행하는 데 필요한 AWS 리소스에 대해서만 요금을 지불하면 됩니다.


ref : https://aws.amazon.com/ko/elasticbeanstalk




반응형
반응형



Auto scaling  을 통해 서벌를 늘리고 서버를 들리는 만큼 DB > RDS 에서도 Master는 쓰기 전용으로 만들어 놓고


Slave DB를 추가로 만들어 Master 와 Slave 가 데이터 동기화 되도록 해놓으면(RDS 가 처리해줌) 어느정도 Auto Scale 에 맞춰 


대응이 되는데 Auto scaling 로 서버가 많이 늘어날 경우 RDS 쪽에서 샤딩으로 데이터베이스를 분할하여 쓰기 작업즉을 분산 시킨다


즉 쓰기로 몰려 있는 Master 의 부하를 샤딩으로 줄여줄 수 있다




DB를 분산(읽기 , 쓰기)처리를 하기위해선 


코드 상에서 읽기 DB 주소와 쓰기 DB주소를 얻어온 후 각각 쓰기와 읽기를 처리하면 된다 



반응형
반응형

load balancer를 elatic ip에 연결을 할 수 있나요?ㅎㅎ elastic ip에서…

load balancer를 elatic ip에 연결을 할 수 있나요?ㅎㅎ

elastic ip에서 association할 때 목록에 load balancer는 뜨지가 않네요ㅠ

2 thoughts on “load balancer를 elatic ip에 연결을 할 수 있나요?ㅎㅎ elastic ip에서…

  1. 넵 ELB의 IP는 고정할 수 없습니다.ELB는 도메인 명만 제공합니다. ELB가 자체적으로 부하에 따라서 확장되거나 하기 때문인데요~ 그럼에도 불구하고 IP고정이 필요하신 경우에는 ec2에 EIP를 부여하시고 haproxy등을 검토해 보시는게 좋을꺼 같습니다~

  2. LB는 eip가 자동으로 2개가 연결되어 있죠 ㅎ 저희가 고정시키거나 제어를 못해서 문제지만요 ㅎㅎ dns까지 aws r53쓰실 예정이시면 cname alias를 사용하시는 거가 가장 나이스 하신거 같고 다른 dns 서버 쓰실꺼면 eip고정한 haproxy쓰시는게 낫더라구요 ㅎ



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


반응형
반응형


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의 핵심 구성 요소가 나와 있습니다.

 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에 액세스

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

  • AWS Management 콘솔 — Elastic Load Balancing에 액세스할 때 사용할 수 있는 웹 인터페이스를 제공합니다.

  • AWS 명령줄 인터페이스(AWS CLI) — Elastic Load Balancing을 비롯한 다양한 AWS 서비스에 사용되며, Windows, Mac 및 Linux에서 지원되는 명령을 제공합니다. 자세한 내용은 AWS Command Line Interface를 참조하십시오.

  • [AWS SDK] — 언어별 API를 제공하고, 서명 계산, 요청 재시도 처리 및 오류 처리와 같은 많은 연결 세부 정보를 관리합니다. 자세한 내용은 AWS SDK를 참조하십시오.

  • 쿼리 API — HTTPS 요청을 사용하여 호출하는 하위 수준의 API 작업을 제공합니다. 쿼리 API 사용은 Elastic Load Balancing에 액세스하는 가장 직접적인 방법이지만, 애플리케이션에서 요청에 서명할 해시 생성 및 오류 처리와 같은 하위 수준의 세부 정보를 처리해야 합니다. 자세한 내용은 다음 자료를 참조하십시오.

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

  • Amazon EC2 — 클라우드에서 애플리케이션을 실행할 수 있는 가상 서버입니다. 로드 밸런서를 구성하여 EC2 인스턴스에 트래픽을 라우팅할 수 있습니다. 자세한 내용은 Linux 인스턴스용 Amazon EC2 사용 설명서 또는 Windows 인스턴스용 Amazon EC2 사용 설명서 단원을 참조하십시오.

  • Amazon ECS — EC2 인스턴스 클러스터에서 Docker 컨테이너를 실행, 중단 및 관리할 수 있게 해 줍니다. 로드 밸런서를 구성하여 컨테이너에 트래픽을 라우팅할 수 있습니다. 자세한 내용은 Amazon Elastic Container Service Developer Guide를 참조하십시오.

  • Auto Scaling — 인스턴스에 장애가 발생하더라도 원하는 수의 인스턴스를 실행하고 인스턴스의 수요가 변경되면 자동으로 인스턴스 수를 늘리거나 줄일 수 있게 해 줍니다. Elastic Load Balancing과 함께 Auto Scaling을 사용하는 경우, Auto Scaling이 시작한 인스턴스는 자동으로 로드 밸런서에 등록되고 Auto Scaling이 종료하는 인스턴스는 자동으로 로드 밸런서에서 등록 취소됩니다. 자세한 내용은 Amazon EC2 Auto Scaling 사용 설명서 섹션을 참조하십시오.

  • Amazon CloudWatch — 로드 밸런서를 모니터링하고 필요에 따라 조치를 취할 수 있게 해 줍니다. 자세한 내용은 Amazon CloudWatch 사용 설명서 단원을 참조하십시오.

  • Route 53 — 도메인 이름(예: www.example.com)을 192.0.2.1과 같이 컴퓨터 간 연결을 위해 사용되는 숫자로 된 IP 주소(예: 192.0.2.1)로 변환하는 이 서비스는 안정적이며 경제적으로 방문자를 웹 사이트로 연결할 수 있습니다. AWS는 로드 밸런서와 같은 사용자의 AWS 리소스에 URL을 배정합니다. 그러나 기억하기 쉬운 URL이 필요한 경우도 있습니다. 예를 들어 도메인 이름을 로드 밸런서로 매핑할 수 있습니다. 자세한 내용은 Amazon Route 53 개발자 안내서를 참조하십시오.


반응형

'서버(Server) > Aws' 카테고리의 다른 글

load balancer 에는 EIP 가 아닌 도메인명으로  (0) 2018.05.21
Amazon EC2 Auto Scaling  (0) 2018.05.20
Amazon Route 53 DNS 서비스  (0) 2018.05.20
ElastiCache 클러스터  (0) 2018.05.18
DynamoDB를 선택하는 잘못된 이유  (0) 2018.05.18
반응형

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

반응형

'서버(Server) > Aws' 카테고리의 다른 글

Amazon EC2 Auto Scaling  (0) 2018.05.20
ELB(Elastic Load Balancing) [부하 분산]  (0) 2018.05.20
ElastiCache 클러스터  (0) 2018.05.18
DynamoDB를 선택하는 잘못된 이유  (0) 2018.05.18
DynamoDB 핵심 구성 요소  (0) 2018.05.17
반응형

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


반응형
반응형


DynamoDB를 선택하는 잘못된 이유

이 글은 https://blog.codebarrel.io/why-we-switched-from-dynamodb-back-to-rds-before-we-even-released-3c2ee092120c 에 대한 생각을 정리한 내용입니다.


링크의 내용에서 지적한 AWS DynamoDB의 Limitation은 다움과 같습니다.

  • pagination의 자유도가 떨어지고
  • index 추가에 따른 비용의 부담이 있으며
  • sorting 기준이 table 생성 시점에 결정되어야 하며
  • bursty read/write에 대한 대응이 가격 효율적이지 못하다 
    (최근 autoscale이 적용되면서 더이상 유효하지 않습니다)

AWS DynamoDB의 API가 주는 불편함에는 동의하지만, 글쓴이가 DynamoDB를 선택한 이유에 대해서는 동의하기 어렵다고 생각합니다.

We’re a small startup and as such keeping costs low and development speed high are incredibly important for us.

DynamoDB를 선택한 이유로 ‘개발 생산성’과 ‘비용’을 뽑았기 때문입니다. 물론 해당 부분도 장점이될 수 있지만, DynamoDB의 핵심적인 장점은 infinite한 확장성과 최소 성능에 대한 보장에 있다고 봐야 하지 않을까 싶습니다.

따라서 ‘개발 생산성’과 ‘비용’을 이유로 DynamoDB를 선택했다면 적절한 선택이 아니었을 수 있으며, 결론처럼 EC2에 RDS를 설치해서 사용하는 것이 더 효율적인 선택이라고 봅니다.

해당 회사는 현재는 DynamoDB에서 RDS로 이전을 했지만, 이후에 서비스가 성공적으로 확장되고 Traffic이 빠르게 늘어나는 경우에는 반대로 RDS에서 DynamoDB등으로 재이전이 필요한 상황도 발생할 수도 있지 않을까요?

결국 어떤 이유로 기술을 선택한 것이냐에 따른 Trade off가 아닐까 싶습니다.

빠르게 rolling하는 startup들이 겪는 공통적인 상황이겠지만, 기술을 선택할 때 충분히 선택이 가져오는 implication들을 파악하지 못하고 진행된다는 문제점이 있을 수 있습니다.

DynamoDB와 같은 NoSQL 경우에는 Table구조를 어떻게 잡느냐에 따라서 이후 사용에 비용적인 차이와 데이터를 사용(예: join, pagination, bulk delete)하기 위한 노력에 큰 영향이 있습니다. (현 시점에는 이러한 결정을 도와줄 Best Practice들이 많이 공개되어 있습니다. 예 — Hot/Cold Data분리, daily rolling table … ) 개발팀이 ‘빠른 개발’을 위해서 이러한 고민을 충분히 하지 못한채로 개발이 진행되는 상황이 많이 있을 것이라고 생각됩니다. 그렇지만 흔히 그렇듯이 이런 사소한 지나침은 향후 기술 부채의 형태로 다시 돌아오곤 하죠. :)



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

반응형

'서버(Server) > Aws' 카테고리의 다른 글

Amazon Route 53 DNS 서비스  (0) 2018.05.20
ElastiCache 클러스터  (0) 2018.05.18
DynamoDB 핵심 구성 요소  (0) 2018.05.17
AWS 서비스들의 요약 설명 및 용어  (0) 2018.05.16
AWS Databases (RDS)  (0) 2018.05.16
반응형


DynamoDB 핵심 구성 요소

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

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

테이블, 항목 및 속성

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

  • 테이블 – 다른 데이터베이스 시스템과 마찬가지로 DynamoDB는 데이터를 테이블에 저장합니다. 테이블은 데이터의 집합입니다. 예를 들어, 친구, 가족 또는 기타 관심 있는 사람에 대한 정보를 저장하는 데 사용할 수 있는 People이라는 예제 테이블을 살펴 봅니다. 또한 Cars 테이블에 사람들이 운전하는 차량에 대한 정보를 저장할 수도 있습니다.

  • 항목 - 각 테이블에는 0개 이상의 항목이 있습니다. 항목은 모든 기타 항목 중에서 고유하게 식별할 수 있는 속성들의 집합입니다. People 테이블에서 각 항목은 한 사람을 나타냅니다. Cars 테이블의 경우 각 항목은 차량 한 대를 나타냅니다. DynamoDB의 항목은 여러 가지 면에서 다른 데이터베이스 시스템의 행, 레코드 또는 튜플과 유사합니다. DynamoDB에서는 테이블에 저장할 수 있는 항목의 수에 제한이 없습니다.

  • 속성 – 각 항목은 하나 이상의 속성으로 구성됩니다. 속성은 기본적인 데이터 요소로서 더 이상 나뉠 필요가 없는 것입니다. 예를 들어 People 테이블의 항목에는 PersonIDLastNameFirstName 등의 속성이 있습니다. Department 테이블의 경우 항목에 DepartmentIDNameManager 등의 속성이 있을 수 있습니다. DynamoDB의 속성은 여러 가지 면에서 다른 데이터베이스 시스템의 필드 또는 열과 유사합니다.

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






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

  • 테이블의 각 항목에는 항목을 테이블의 다른 모든 항목과 구별해 주는 고유 식별자인 기본 키가 있습니다. People 테이블에서 기본 키는 한 개의 속성(PersonID)으로 구성됩니다.

  • 기본 키를 제외하고, People 테이블에는 스키마가 없습니다. 이는 속성이나 데이터 형식을 미리 정의할 필요가 없음을 의미합니다. 각 항목에는 자체의 고유 속성이 있을 수 있습니다.

  • 대부분의 속성은 스칼라인데, 이는 하나의 값만 가질 수 있다는 의미입니다. 문자열 및 숫자가 스칼라의 일반적인 예입니다.

  • 일부 항목은 내포 속성(Address)을 갖습니다. DynamoDB는 최대 32 수준 깊이까지 내포 속성을 지원합니다.

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

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

  • Music의 기본 키는 두 개의 속성(Artist 및 SongTitle)으로 구성되어 있습니다. 테이블의 각 항목이 이러한 두 속성을 가지고 있어야 합니다. Artist와 SongTitle의 조합은 테이블의 각 항목을 다른 모든 항목과 구별해 줍니다.

  • 기본 키를 제외하고, Music 테이블에는 스키마가 없습니다. 이는 속성이나 데이터 형식을 미리 정의할 필요가 없음을 의미합니다. 각 항목에는 자체의 고유 속성이 있을 수 있습니다.

  • 항목 중 하나에는 내포 속성(PromotionInfo)이 있는데, 이 속성은 다른 내포 속성을 포함합니다. DynamoDB는 최대 32 수준 깊이까지 내포 속성을 지원합니다.

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

기본 키

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

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

  • 파티션 키 – 파티션 키로 알려진 하나의 속성으로 구성되는 단순 기본 키.

    DynamoDB는 내부 해시 함수에 대한 입력으로 파티션 키 값을 사용합니다. 해시 함수 출력에 따라 항목을 저장할 파티션(DynamoDB 내부의 물리적 스토리지)이 결정됩니다.

    파티션 키로만 구성되어 있는 테이블에서는 어떤 두 개의 테이블 항목도 동일한 파티션 키 값을 가질 수 없습니다.

    테이블, 항목 및 속성에서 설명한 People 테이블은 기본 키(PersonID)가 하나인 테이블의 예입니다. 이 항목에 PersonId 값을 입력하여 People 테이블의 모든 항목에 바로 액세스할 수 있습니다.

  • 파티션 키 및 정렬 키 – 복합 기본 키로 지칭되는 키로, 이 형식의 키는 두 개의 속성으로 구성됩니다. 첫 번째 속성은 파티션 키이고, 두 번째 속성은 정렬 키입니다.

    DynamoDB는 내부 해시 함수에 대한 입력으로 파티션 키 값을 사용합니다. 해시 함수 출력에 따라 항목을 저장할 파티션(DynamoDB 내부의 물리적 스토리지)이 결정됩니다. 파티션 키가 동일한 모든 항목은 정렬 키 값을 기준으로 정렬되어 함께 저장됩니다.

    파티션 키와 정렬 키로 구성되어 있는 테이블에서는 두 개의 항목이 동일한 파티션 키 값을 가질 수 있습니다. 그러나 두 아이템의 정렬 키 값은 달라야 합니다.

    테이블, 항목 및 속성에서 설명한 Music 테이블은 복합 기본 키(Artist 및 SongTitle)가 있는 테이블의 예입니다. 원하는 항목에 Artist 및 SongTitle 값을 입력하고 Music 테이블의 해당 항목에 바로 액세스할 수 있습니다.

    복합 기본 키를 사용하면 보다 유연하게 데이터를 쿼리할 수 있습니다. 예를 들어 Artist 값만 제공하는 경우, DynamoDB는 해당 아티스트의 모든 노래를 검색합니다. Artist 값과 함께 SongTitle 값 범위를 입력하여 특정 아티스트의 노래 중 일부만 검색할 수도 있습니다.

참고

항목의 파티션 키를 해시 속성이라고도 합니다. 해시 속성이라는 용어는 파티션 키 값에 따라 파티션에 데이터 항목을 고르게 분배하는 DynamoDB의 내부 해시 함수를 사용하는 것에서 유래합니다.

항목의 정렬 키를 범위 속성이라고도 합니다. 범위 속성이라는 용어는 DynamoDB가 동일한 파티션 키를 지닌, 물리적으로 상호 근접한 항목들을 정렬 키 값에 의한 정렬 순서로 저장하는 방식에서 유래합니다.

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

보조 인덱스

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

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

  • Global secondary index – 파티션 키 및 정렬 키가 테이블의 파티션 키 및 정렬 키와 다를 수 있는 인덱스입니다.

  • 로컬 보조 인덱스 – 테이블과 파티션 키는 동일하지만 정렬 키는 다른 인덱스입니다.

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

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

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

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

  • 모든 인덱스는 테이블에 속해 있는데, 이를 인덱스의 기본 테이블이라고 합니다. 앞의 예제에서 GenreAlbumTitle 인덱스의 기본 테이블은 Music입니다.

  • DynamoDB는 인덱스를 자동으로 유지합니다. 기본 테이블의 항목을 추가, 업데이트 또는 삭제하면 DynamoDB는 해당 테이블에 속하는 모든 인덱스의 해당 항목을 추가, 업데이트 또는 삭제합니다.

  • 인덱스를 생성할 때는 기본 테이블에서 인덱스로 복사하거나 프로젝션할 속성을 지정해야 합니다. 적어도 DynamoDB는 기본 테이블의 키 속성을 인덱스로 예상합니다. GenreAlbumTitle의 경우가 그러한데, Music 테이블의 키 속성만 인덱스로 프로젝션됩니다.

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)를 호출하여 해당 주소에 이메일을 보냅니다.

참고

이 예제에서 마지막 고객인 Craig Roe는 EmailAddress가 없어 이메일을 받지 못합니다.

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

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


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


반응형

'서버(Server) > Aws' 카테고리의 다른 글

ElastiCache 클러스터  (0) 2018.05.18
DynamoDB를 선택하는 잘못된 이유  (0) 2018.05.18
AWS 서비스들의 요약 설명 및 용어  (0) 2018.05.16
AWS Databases (RDS)  (0) 2018.05.16
Network ACL(Access Control List)  (0) 2018.05.15
반응형

1. AWS란?




 On Premise : 비용(초기에 모두 필요함), 서버 조달 기간(몇주-몇달), 서버 추가/변경(시간과 비용 발생)


 AWS : 비용(과금정책에 따른 비용 발생), 서버 조달 기간(몇 분), 서버 추가/변경(시간이 거의 들지 않음)






Amazon Elastic Compute Cloud (EC2)

: EC2는 AWS의 가장 핵심적인 서비스로 가상 서버를 나타냅니다. 참고로 가상 서버를 실행하는 머신 이미지를 Amazon Machine Image(AMI)라고 부르며, 실행된 가상 서버를 인스턴스라고 부릅니다


AWS Elastic Load Balancing (ELB)

: ELB는 부하 분산 장치입니다. EC2 인스턴스 앞(Front)에 두고, 여러 개의 EC2 인스턴스에 통신을 분산해줍니다. ELB를 이용하면 가용성과 확장성이 높은 시스템을 쉽게 구축할 수 있습니다


Auto Scaling

Auto Scaling은 CPU 또는 메모리 사용량 등에 따라 EC2 인스턴스를 자동으로 늘리고 줄이는 서비스입니다. 이 기능을 사용하면 부하에 따라 자원을 자동으로 최적화할 수 있습니다. Auto Scaling 기능은 ELB와 함께 사용하는 경우가 많습니다


Amazon Simple Storage Service (S3)

: S3는 온라인 스토리지 서비스입니다. 온라인이라는 글자가 붙은 이유는 데이터 조작에 HTTP/HTTPS를 통한 API가 사용되기 때문입니다


Amazon Glacier

: Glacier는 빙하라는 의미로 데이터를 장기 보관하기 위해 설계된 서비스입니다. S3의 1/3의 비용으로 사용할 수 있습니다


Amazon Elastic Block Store (EBS)

: EBS는 EC2 인스턴스에서 사용하는 스토리지입니다. 일종의 외장 하드디스크라고 생각하면 됩니다. EC2와는 네트워크를 기반으로 연결되며, 내부적으로 RAID1과 같은 구성으로 디스크가 확장됩니다. EBS는 스토리지 이미지를 스냅샷 형식으로 S3에 백업해서 보관 또는 복제를 쉽게 할 수 있습니다


Amazon Relational Database Service (RDS)

: RDS는 데이터베이스 PaaS입니다. OS 계층 또는 미들웨어 패치 등은 모두 AWS가 자동으로 해줍니다. 레플리케이션(Replication, 데이터를 다른 컴퓨터로 복제하는 것)으로 마스터/슬레이브 구성, 특정 시간에 자동 백업 등 AWS가 제공하는 기능들이 있습니다. 데이터베이스 엔진은 Amazon Aurora, PostreSQL, MySQL, MariaDB, Oracle, SQL Server 등이 있습니다


Amazon ElasticCache

ElasticCache는 인 메모리 캐시 시스템 PaaS입니다. 지원하는 엔진은 Memcached와 Redis입니다. ElasticCache를 사용하면 데이터베이스 캐시를 통한 고속화, 애플리케이션 세션 스토어를 통한 장애 해결 능력 향상 등이 가능해집니다


Amazon Virtual Private Cloud (VPC)

: VPC는 AWS 네트워크 내부에서 논리적으로 분리된 네트워크를 생성하는 서비스입니다. 원하는 프라이빗 주소로 네트워크 생성 또는 서브넷 분할할 수 있으므로, On Premise처럼 DMS 세그먼트 또는 Trusted 세그먼트 구성 등을 할 수 있습니다. 인터넷 게이트웨이 설정을 하면 인터넷과의 통신도 가능합니다. 또한, VPN 게이트웨이도 생성할 수 있으므로, 기존의 데이터 센터 또는 회사 내부의 네트워크와 연결할 수도 있습니다


AWS Direct Connect

: Direct Connect는 AWS의 VPC에 접속하기 위한 전용선 접속 서비스입니다. 자신의 회사 또는 데이터 센터에서 전용선을 AWS에 직접 연결할 수 있습니다. On Premise와 클라우드를 모두 사용하는 하이브리드 클라우드 형태를 구성할 때 Direct Connect를 사용합니다


Amazon CloudFront

CloudFront는 AWS가 제공하는 콘텐츠 전송 네트워크(CDN) 서비스입니다. 콘텐츠를 엣지 로케이션(Edge Location)이라고 부르는 전 세계에 퍼져 있는 거점을 기반으로 전달합니다. 사용자로부터 가장 가까운 엣지 로케이션에서 데이터를 제공하므로 빠르게 데이터를 전송할 수 있습니다


Amazon Route 53

: Route 53은 도메인 이름 시스템(DNS) 서비스입니다. 취약성 또는 DDoS 공격에 대한 대응, 시간이 오래 걸리는 DNS 운용을 쉽게 할 수 있게 해줍니다. DNS는 인터넷의 근간을 담당하는 서비스이므로 100%의 SLA(Service Level Agreement, 서비스 품질)를 보증하고 있습니다


Amazon Simple Queue Service (SQS)

: SQS는 메시지 큐 서비스입니다. SQS는 메시지의 가용성, 확장성, 큐 시스템의 신뢰성 등을 AWS가 높은 수준으로 구현하고 있습니다


Amazon Simple Notification Service (SNS)

: SNS는 푸시 형태의 메시지 전달 서비스입니다. SNS를 사용하면 이메일, 모바일 푸시, SQS, HTTP/HTTPS 등의 다양한 프로토콜로 알림할 수 있습니다. 호출하는 쪽의 애플리케이션/프로그램은 SNS API를 사용해 처리를 작성하기만 하면 됩니다


Amazon Simple Email Service (SES)

:  SES는 메일 전송 서비스입니다. 단순한 전송 기능뿐만 아니라 메일 전송 품질을 위한 다양한 기능을 제공합니다


AWS Identity and Access Management (IAM)

: IAM은 AWS의 계정 관리 서비스입니다. 사용자 또는 그룹에 대한 AWS 리소스 접근 권한 제어를 해줍니다. AWS를 안전하게 운용하려면 사용해야 하는 필수 서비스입니다


AWS CloudTrail

CloudTrail은 AWS API 호출을 기록하는 로깅 서비스입니다. CloudTrail를 사용해서 로그 데이터를 축적/분석할 수 있습니다


Amazon CloudWatch

CloudWatch는 AWS의 리소스 또는 애플리케이션 모니터링 서비스입니다. 각각의 리소스를 특정 조건을 사용해 감시할 수 있습니다. 예를 들어, CPU 사용률이 80%를 넘었을 때 알림을 보내는 것 등이 가능합니다


AWS Elastic Beanstalk

Elastic Beanstalk은 웹 애플리케이션 서버 PaaS입니다. 서버를 구축하지 않고도 Java, .NET, PHP, Node.js, Python, Ruby, Docker 플랫폼 등을 사용할 수 있습니다. Auto Scaling 설정을 하면 애플리케이션 확장 등을 자동으로 수행해줍니다. EC2에서 자체적으로 미들웨어를 구축하기 전에 Elastic Beanstalk만으로 구축할 수는 없는지 검토해보면 좋을 것입니다


AWS CloudFormation

CloudFormation은 AWS 환경 구축을 자동화하는 도구입니다. 서식에 따라 템플릿을 작성하면, 해당 템플릿을 기반으로 환경을 쉽게 재현할 수 있습니다. CloudFormation을 사용하면 AWS를 사용할 때 인프라 구축을 효율적으로 할 수 있습니다. 템플릿은 JSON 형식의 파일이며, Git 등의 저장소로 관리할 수 있습니다. 따라서 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는 사용할 때 두가지 모델로 비용을 지불할 수 있습니다.

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

 

장점

1. 쉽게 설치 가능하다

2. 패치 적용 및 백업이 자동으로 이루어진다.

3. HA구성 자동화

단점

1. RDS 인스턴스의 OS에 로그인 할 수 없다.

2. 관리가 어렵고 불편하다.

3. RDS EC2처럼 정지할 수 없다한번 가동하면

계속 실행되어 비용을 줄일려면 인스턴스를 삭제해야 한다.

 


2. 자동백업 및 수동백업

자동백업

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

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

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

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


수동 백업(DB 스냅샷)

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

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

 


3. RDS의 네트워크

 RDS 인스턴스의 IP주소와 DNS

 RDS에 접근할 때는 반드시 DNS를 사용합니다. RDS 인스턴스의 IP주소는 고정되어 

 있지 않습니다따라서 접근할 때는 인스턴스 생성할 때 발행하는 DNS이름을 

 사용해야 합니다RDS의 DNS 이름은 엔드포인트라고 합니다.

 RDS 인스턴스 접근 포트

 RDS 인스턴스 접근 시 특정 포트와 특정 프로토콜을 사용해야 한다

 예를 들어 MySQL이라면 접근 가능 포트는 디폴트로 3306입니다

 포트는 1150 이상의 번호라면 원하는 포트로 변경가능 합니다.

 보안 그룹

 보안 그룹(Security Group)을 설정 가능하며 IP주소 또는 EC2 인스턴스마다 

 접근 제한을 할 수 있습니다

 VPC를 사용해 가동 가능

 RDS인스턴스를 특정 서브넷에 소속시킬 수 있으며따라서 RDS에 부여할 IP 주소의

 범위를 어느 정도 압축할 수 있습니다.

 또한프라이빗 서브넷에 소속시켜서 외부와의 통신을 차단할 수 있습니다.  

 VPC 위에 두면 VPC의 라우트 테이블과 네트워크 ACL도 적용할 수 있으므로 보다 

 안전한 네트워크를 구축할 수 있습니다.

 멀티AZ(스탠바이 레플리카)

 멀티AZ기능을 활성화하면생성한 RDS 인스턴스의 예비 복제본이 

 다른 AZ(Availabiliy Zone)에 추가로 생성됩니다.  

 RDS 인스턴스가 사용 불가능해지면 저동적으로 예비 복제본으로 페일오버됩니다

 현재 RDS 인스턴스가 소속된 AZ와 페일오버 때 어떤 AZ로 변경될지는 

 AWS매니지먼트 콜솔에서 확인 할 수 있습니다.

 RDS의 SLA에서 언급했던 것처럼 SLA는 멀티 AZ 인스턴스에 적용됩니다.

 멀티 AZ는 리전에 따라 사용/미사용임으로 리전별로 확인이 필요합니다.

 수동 페일오버

 수동으로 페일오버 할 수 있으며 이때 DNS를 캐시해서 사용하고 있는지 않은지 

 등의 문제를 발견할 수 있습니다

 또한페일오버에 얼마나 걸리는지 시간도 확인해 볼 수 있습니다.

 

페일오버 주의점

페일오버가 발생해도 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의 보안을 강화하고 모니터링하는 데 사용할 수 있는 세 가지 기능을 제공합니다.

  • 보안 그룹 - 연결된 Amazon EC2 인스턴스에 대한 방화벽 역할을 하여 인스턴스 수준에서 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어합니다.

  • 네트워크 ACL(액세스 제어 목록) - 연결된 서브넷에 대해 방화벽 역할을 하여 서브넷 수준에서 인바운드 트래픽과 아웃바운드 트래픽을 모두 제어합니다.

  • 흐름 로그 - VPC의 네트워크 인터페이스에서 송수신되는 IP 트래픽에 대한 정보를 수집합니다.

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

인스턴스 수준에서의 적용(1차 보안 계층)

서브넷 수준에서의 적용(2차 보안 계층)

허용 규칙만 지원

허용 및 거부 규칙 지원

상태 저장: 규칙에 관계없이 반환 트래픽이 자동으로 허용됨

상태 비저장: 반환 트래픽이 규칙에 의해 명시적으로 허용되어야 함

트래픽 허용 여부를 결정하기 전에 모든 규칙을 평가함

트래픽 허용 여부를 결정 시 규칙을 번호순으로 처리함

인스턴스 시작 시 누군가 보안 그룹을 지정하거나, 나중에 보안 그룹을 인스턴스와 연결하는 경우에만 인스턴스에 적용됨

연결된 서브넷에서 모든 인스턴스에 자동 적용됨(백업 보안 계층이므로 보안 그룹을 지정하는 사람에게 의존할 필요 없음)

다음 다이어그램은 보안 그룹과 네트워크 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

반응형
반응형


AWS : linux 에서 초기 세팅 및 npm , nodejs , 설치하기








    sudo yum update

This is going to take some time so be patient.



Yum package manager have no direct node.js or node repository so you need to manually download and compile the node.js binary package. This step will take some time so make sure you grab a coffee before starting.

1 : Install GCC++ and Make.

    sudo yum install gcc-c++ make

2 : Install openssl-dev.

    sudo yum install openssl-devel

3: Install git

    sudo yum install git

Execute these commands one by one and then run following.

1 : Download latest version of Node.js

    git clone git://github.com/nodejs/node.git

Switch to node folder.

    cd node

In order to install Node.js, you need to switch to latest branch of it. Current stable version at the time of writing this tutorial is v0.12.2.

Run this command to switch to branch.

git checkout v0.12.2

Run following command one by one.

./configure
make
sudo make install

Above steps will take around 10-15 minute to complete. Once done you should be able to use node.js in your Amazon EC2 system.

Install NPM :

Before installing any node modules in your system we need to add path where those modules should get installed. To do so, you need to edit sudoers file. Here is how to do so.

sudo su
vi /etc/sudoers

Once VI editor is opened, find this line.

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Once found, press “i” key to go in insert mode in VI and at the end of this line add following.

:/usr/local/bin

Or replace it with this.

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

In order to save your changes, press ESC key and type “wq” and hit ENTER in VI editor.

All right, let’s install NPM module.

1 : Clone the NPM.

git clone https://github.com/isaacs/npm.git

2 : Install the NPM.

cd npm
sudo make install

Wait for few minutes and you are done !

Say “Hello World”

Congratulations ! We have finally setup and install the Amazon EC2 and Node.js. It’s time to test the setup. Let’s create one simple project and print “Hello World”.

Create a new folder and switch to that folder. create package.json using VI and paste this code.

package.json
{
  "name": "sample",
  "version": "0.0.1",
  "dependencies": {
    "express": "^4.12.3"
  }
}





Run

npm install



실행했는데 이런 에러가 나면 (if you met this installing error)

npm ERR! code UNABLE_TO_GET_ISSUER_CERT_LOCALLY

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

이 명령줄을 실행한다



to install Express.

Create app.js file and paste following code.

app.js
var express = require("express");
var app = express();


app.get("/",function(req,res){
        res.send("<h1>Hello from EC2</h1>");
});

app.listen(80);

Run this app using following command.

sudo node app.js

Make sure you use SUDO for it. Visit your public DNS and you should see screen like this.

Conclusion :

Amazon is one of the best cloud provides and above all they let us try their System for free. You can use it to host your project, blog, website or anything. We have covered almost everything you need to get started but there are still some configuration left like mapping domains to EC2 instance. Will cover it later.




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


반응형
반응형


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

반응형
반응형


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
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
PermlinkReplies: 10 Pages: Last Post: Nov 20, 2017 1:19 PM by: jtscott
Replies
Re: How could I remove custom metrics in CloudWatch?
Posted by:  D. Svanlund RealName(TM)
Posted on: May 16, 2011 12:48 PM
in response to: oneskyapp in response to: oneskyapp
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 in response to: D. Svanlund
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 RealName(TM)
Posted on: Sep 27, 2011 12:30 AM
in response to: rakesh_ in response to: rakesh_
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 in response to: oneskyapp
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 in response to: oneskyapp
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_ in response to: rakesh_
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 in response to: secgeek
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 in response to: oneskyapp
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 in response to: Joaquim@AWS
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 in response to: Neels
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

반응형
반응형

AMI 생성과정과 EC2 인스턴스 생성



ami 로 부터 EC2 인스턴스를 생성하게 되고 AMI 에 어떤것이 담겨있느냐에 따라 다르지만 우선 Amazon Linux AMI 를 

기준으로 설명한다면 이것은 EBS 기반의 AWS 를 지원하는 AMI 이며 EC2 인스턴스(linux) 와 EBS(HW) 를 생성하는 이미지이다







과정은 AMI 로 부터 EC2 와 EBS(마치C:\ 드라이브) 가 기본적으로 만들어지고 EBS를 기준으로 스냅샷(EBS를 그대로 복사한 것)을 하나 만들어
이 스냅샷을 기준으로 AMI(Amazon Machine Image)를 만들수 있다 (마치 .ios) 그리고 이를 통해 새로운 EC2 인스턴스를 생성 할 수 있게 된다


또한 스냅샷을 통해 다른 지역으로 Copy 가 가능한데 다른 지역으로 넘기는 것은 스냅샷을 통해서만 가능하다



반응형
반응형

본 세션에서는 Amazon VPC의 기본 사항을 살펴 봅니다. 먼저 IP 주소, 서브넷, 라우팅, 보안, NAT 등을 포함하는 VPC의 구축 및 디자인 기본 사항에 대해서 알아봅니다. 그런 다음 VPN 또는 AWS Direct Connect를 사용하여 VPC를 물리적 데이터 센터에 연결하기 위한 다양한 접근 방법과 사용 사례를 살펴봅니다. 이 세션은 Amazon VPC에서 사용할 수 있는 빌딩 블록을 이해하는데 관심이있는 아키텍트, 네트워크 관리자 및 기술적 의사 결정자를 대상으로 합니다.



반응형

+ Recent posts