시스템관리자의 쉼터, 커피닉스 http://coffeenix.net 시스템관리자의 쉼터 - *NIX, 보안, 네트웍 운영, IT 정보 ko [AWS] Cloudfront edge 확인하기 http://coffeenix.net/bbs/viewtopic.php?p=10636#10636
1. 옳은 edge 에서 다운로드 받은것인지?
2. edge 서버에서 다운로드 받은 파일이 정상적인지(md5)

아마도, 서비스를 개발하고 운영(POC등) 하면서 꼭 필요한 것일지도 모르습니다.
이에, 1,2번 확인 하는 법을 적어 볼까 합니다. 어떻게 확인한다는거야? 라고 생각하실지 모르지만 아주 쉽습니다.

■ edge 위치 확인하기

    1. Edge IP 확인
    2. Reverse lookup을 통해 도메인 정보 확인(빨간부분)
    - ex) server-54-230-249-80.icn51.r.cloudfront.net
    3. 아래표를 참조하여 edge 확인(빨간 부분을 아래표에 대조, 공항코드라고 합니다용.)

** 이쁘게 올리고 싶었으나, 이미지나 표로 올리기 어려워서 복붙했습니다.

--------------- code --

ATA CITY COUNTRY STATE COUNTRY PRICE REGION
AMS1 Amsterdam The Netherlands - Europe Europe
AMS50 Amsterdam The Netherlands - Europe Europe
ARN1 Stockholm Sweden - Europe Europe
ATL50 Atlanta - Georgia United States United States
BOM2 Mumbai India - Asia India
CDG3 Paris France - Europe Europe
CDG50 Paris France - Europe Europe
CDG51 Paris France - Europe Europe
DFW3 Dallas - Texas United States United States
DFW50 Dallas - Texas United States United States
DUB2 Dublin Ireland - Europe Europe
EWR2 Newark - New Jersey United States United States
FRA2 Frankfurt Germany - Europe Europe
FRA50 Frankfurt Germany - Europe Europe
FRA6 Frankfurt Germany - Europe Europe
GRU1 Sau Paulo Brazil - South America South America
GIG50 Rio de Janerio Brazil - South America South America
HKG1 Hong Kong Island Hong Kong - Asia Hong Kong and others
HKG50 Hong Kong Island Hong Kong - Asia Hong Kong and others
HKG51 Hong Kong Island Hong Kong - Asia Hong Kong and others
IAD12 Ashburn - Virginia United States United States
IAD2 Ashburn - Virginia United States United States
IAD53 Ashburn - Virginia United States United States
ICN50 Seoul South Corea - Asia Hong Kong and others
ICN51 Seoul South Corea - Asia Hong Kong and others
IND6 South Bend - Indiana United States United States
JAX1 Jacksonville - Florida United States United States
JFK1 Nueva York - New York United States United States
JFK5 Nueva York - New York United States United States
JFK6 Nueva York - New York United States United States
LAX1 Los Angeles - California United States United States
LAX3 Los Angeles - California United States United States
LHR3 London United Kingdom - Europe Europe
LHR5 London United Kingdom - Europe Europe
LHR50 London United Kingdom - Europe Europe
MAA3 Chennai India - Asia India
MAD50 Madrid Spain - Europe Europe
MEL50 Melbourne - - Australia Australia
MIA3 Miami - Florida United States United States
MIA50 Miami - Florida United States United States
MNL50 Manila Philippines - Asia Hong Kong and others
MRS50 Marseille France - Europe Europe
MXP4 Milan Italy - Europe Europe
NRT12 Tokyo Japan - Asia Japan
NRT52 Tokyo Japan - Asia Japan
NRT53 Tokyo Japan - Asia Japan
NRT54 Tokyo Japan - Asia Japan
SEA4 Seattle - Washington United States United States
SEA50 Seattle - Washington United States United States
SEA50-OneBox Seattle - Washington United States United States
SFO4 San Francisco - California United States United States
SFO5 San Francisco - California United States United States
SFO9 San Francisco - California United States United States
SFO20 San Francisco - California United States United States
SIN2 null Republic of Singapore - Asia Hong Kong and others
SIN3 null Republic of Singapore - Asia Hong Kong and others
STL2 St. Louis - Missouri United States United States
SYD1 Sydney - - Australia Australia
TPE50 Taipei Taiwan - Asia Hong Kong and others
WAW50 Warsaw Poland - Europe Europe

--------------- /code --


■ edge 서버에 직접 서비스 호출하기

    1. header 를 변경해서 서비스 요청하면 됩니다.(쉽죠? ^^)
    2. wget 을 예로 들면 아래와 같습니다.
    wget --header=’Host:xxx.xxx.xxx.xxx.com’ http://ipaddress/xxx/xxx/xxx/xx/xxx.pdf


** 참고로, 이 글은 도남이의 facebook 호출을 듣고 남김거임요 ㅋㅋㅋ]]> AWS Mon, 15 Feb 2016 10:38:39 +0900 Auto-Scaling 의 Termination Process - default 시 http://coffeenix.net/bbs/viewtopic.php?p=10135#10135
기본적으로는 Cloud Watch 의 Metric 을 기준으로 사용량(임계치)에 따라 자동으로 Scale in/out(서버들을 줄였다 늘렸다) 해주는 것이죠.

Scale out(늘어났다가) 이 되었다가 Scale in(줄어들때) 할때, 서버를 어떤 기준으로 하여 Termination(종료 - 없애기) 할까요?

우선은 Default 설정시 Termination 하는 과정을 보겠습니다. 이는 늘상 그렇듯 아마존 문서에 잘 나와 있습니다. (http://docs.aws.amazon.com/AutoScaling/latest/DeveloperGuide/AutoScalingBehavior.InstanceTermination.html#default-termination-policy)

저는 영어라 읽기 어려우신 분을 위해 한글로 잠시 정리해 드리는 거죠. 아래에 자세히 적긴 했는데, 간략하게 다시 한글로만 정리 하면

1. AZ 선택
- Multi AZ 일 경우에 인스턴스가 가장 많은 AZ를 선택하고, 인스턴스의 숫자가 같다면 Random 하게 선택 됩니다.
- Multi AZ 가 아닐경우에는 그 AZ에서 동작 합니다.

2. 가장 오래된 Launch Configure 를 사용하는 인스턴스를 종료 합니다.

3. 가장 오래된 Launch Configure 를 사용하는 인스턴스가 다수일 경우에는 비용 발생이 근접한 인스턴스(비용을 최소화함 - 사용의 극대화) 를 종료 합니다.

4. 비용 발생이 근접한 인스턴스가 다수(Multiple) 있다면, 자동(Random)으로 인스턴스 선택하여 종료(termination)

순서가 이리 되는거죠. AZ 선택 --> 오래된 Launch Confiugre 사용 인스턴스 --> 비용 발생이 도래한 인스턴스 --> 다수일 경우 Random 하게 종료

물론, 이 과정을 사용자가 변경할 수 있습니다.



--------------- quote --

1. Auto Scaling determines whether there are instances in multiple Availability Zones. If so, it selects the Availability Zone with the most instances. If there is more than one Availability Zone with this number of instances, Auto Scaling selects one of these Availability Zones at random.

--> a. 종료(termination) 할 AZ 선태.
- Multi-AZ 가 아니면, 하나의 AZ 기본으로 선택
- Multi-AZ 라면,
: 인스턴스 수가 가장 많은(most) AZ 선택
: 인스턴스 수가 같다면 자동(Random) AZ 선택

2. Auto Scaling determines which instances in the selected Availability Zone use the oldest launch configuration. If there is one such instance, it terminates it.

--> b. 가장 오래된 launch Configuration 을 사용하는 인스턴스를 종료(Termination.)

3. If there are multiple instances that use the oldest launch configuration, Auto Scaling determines which instances are closest to the next billing hour. (This helps you maximize the use of your EC2 instances while minimizing the number of hours you are billed for Amazon EC2 usage.) If there is one such instance, Auto Scaling terminates it.

--> c. 가장 오래됨 Launch Configuration 을 사용하는 인스턴스가 다수(Multiple) 있다면, 비용 발생이 근접한 인스턴스(비용을 최소화함 - 사용의 극대화) 를 종료(Termination)


4. If there is more than one instance closest to the next billing hour, Auto Scaling selects one of these instances at random.

--> 비용 발생이 근접한 인스턴스가 다수(Multiple) 있다면, 자동(Random)으로 인스턴스 선택하여 종료(termination)

--------------- /quote --


자세한 내용이나 궁금하신 사항은 글 남겨주시면 답달겠습니다.

도움 되셨기를..

감사 합니다.]]> AWS Fri, 06 Mar 2015 09:30:42 +0900 ELB Crosszone 설정 http://coffeenix.net/bbs/viewtopic.php?p=10128#10128 2014년에 생겼죠.

ELB 는 ELB node 들의 집합이며, 각 ELB node 들은 해당 region 의 AZ 에 위치해 있죠. 물론 이 Backend Instance 들도 각 AZ에 있었고요. ELB Cross zone 설정이 안 되어 있으면 "해당 AZ의 ELB node <--> Backend Instance" 끼리만 서비스를 한다고 보면 됩니다. Cross Zone 설정을 했을 경우에는 다른 zone의 Instance 에도 서비스를 하는 것이고요. 과거에는 default 설정이 아니였는데 요즘의 ELB를 만들면 default로 설정됩니다.

여기서 ELB가 Backend Instance 어떻게 분배를 할까요?


--------------- quote --
To determine the instances, the load balancer node uses either the round robin (for TCP connections) or the least outstanding request (for HTTP/HTTPS connections) routing algorithm. The least outstanding request routing algorithm favors back-end instances with the fewest outstanding requests.

--------------- /quote --


TCP의 경우는 Round Robin 이고, Http/Https 의 경우는 outstanding requests(아직 처리 되지 않은 요청)이 제일 적은쪽으로 보냅니다.



ELB를 운영하다보면 CloudWatch 의 request count 를 보고 서비스 불균형을 고민할지 모릅니다. 이때 알아야 할 것은 Request count(AZ 별로 보여줍니다.)는 ELB node 에 도착한 request 이지 해당 AZ의 Backend 로 넘어간 Request Count가 아니라는 것입니다. (Cross zone 미설정시는 해당 AZ로 다 서비스가 넘어가겠지만, Cross zone 설정시에는 Cloudwatch 에서 알 수 없습니다.) 단지, 클라이언트의 DNS resolve로 해당 AZ의 ELB node에서 처리중인 요청의 Count 일뿐입니다. Backend Instance의 로드 불균형으로 보기 어렵다는 것입니다.

CloudWatch 의 request Count 와 Backend Instance의 사용량을 보고 혼동하지 말로고 적은 것입니다. 아쉽게도 아마존에서 Backend Instance로 어떻게 처리를 하고 있는지에 대한 지표를 제공하지는 않습니다. Backend 의 Resource 사용량(Network, CPU) 등으로 유추하여야 합니다.

또하나 고민되실겁니다. ELB node가 다른 AZ의 Backend Instance 에 서비스를 전달하는 형태라면, Latancy 가 발생하지 않을까? 지리적(다른 위치에 있어서) 문제로 Latancy가 있을거라는 것이죠. 그러나, 실제 AZ 간의 속도를 측정해 보면, 별반 차이가 없습니다. traceroute 해봤을때 hop 이 하나인가 하고, 바로 연결되기도 하고요. 속도 거의 동일하게 나옵니다. 이 Latancy가 문제 되었다면, Default 설정으로 넣지도 않았을 것이고요.

너무 두서 없이 적었네요. ^^

읽어 보시고 의견 있으시면 글 남겨주세요~!]]> AWS Fri, 06 Feb 2015 10:43:46 +0900 EC2 - jumbo frame(MTU) : 예기치 않은 패킷 손실 http://coffeenix.net/bbs/viewtopic.php?p=10127#10127

--------------- quote --
The maximum transmission unit (MTU) for an instance depends on its instance type. The following instance types provide 9001 MTU (jumbo frames): CC2, C3, C4, R3, CG1, CR1, G2, HS1, HI1, I2, T2, and M3. The other instance types provide 1500 MTU (Ethernet v2 frames).
--------------- /quote --


Instance Type : CC2, C3, C4, R3, CG1, CR1, G2, HS1, HI1, I2, T2, and M3.

은 사용자가 인지 못하하지 못한 상황에서 MTU가 9001로 자동 세팅 됩니다. 이 경우에 커다란 문제는 없습니다만, Network Blackhole 에 빠질 염려가 있습니다.

network path 상의 MTU 사이즈는 source, destination 사이의 network path 상의 사이즈를 확인해서 결정이 됩니다. 이것을 PMTUD 라고 하는데요. Network Path 상의 특정 장비에서 이를 지원하지 않을때(ICMP) 발생합니다.
(자세한 것은 아래 링크를...)

http://en.wikipedia.org/wiki/Black_hole_(networking)#PMTUD_black_holes

이를 회피하기 위해서 jumbo frame(MTU 9001) 설정시 'tcp_mtu_probing' 를 세팅합니다. 위와 같이 ICMP를 지원하지 않아서 Black Hole 이 발생하였을때 보다 작은 Packet size로 시도하는 것입니다.


# man tcp 옵션을 보면 아래 처럼 나옵니다.



--------------- quote --

0 Disabled
: 안 사용한다.
1 Disabled by default, enabled when an ICMP black hole detected
: black hole detected 가 확인 되었을때 enable 되는것이죠.
2 Always enabled, use initial MSS of tcp_base_mss.
: 항시 enable 로 tcp_base_mss 를 따르는 것입니다.

--------------- /quote --


기본 값은 0(disable) 이라고 하네요. 물론, 아마존도 이 값이 0(disable) 되어 있습니다. 이거 해줘야하는거 아닌지 문의 했더니 특별히 해 줄 필요 없고, 문제시 설정하면 된다고 하네요. 미리 해 놓는게 좋지 않을까요?

거두절미하고, 혹 예기치 않은 Packet 손실이 발생하면 이 부분도 고려해 보세요. MTU 를 확인하고, 1500으로 바꾸고 보는거죠. ㅎㅎ

그럼, 위 내용 보시다가 궁금하신 점 있으면 글 남겨 주세요. 답변 달아 드리겠습니다.

감사 합니다. :)]]> AWS Thu, 05 Feb 2015 17:50:51 +0900 ELB Access log 설정 http://coffeenix.net/bbs/viewtopic.php?p=10126#10126
ELB Access log는 S3 에 로그를 쌓아 둔다.
설정 방법은 아래와 같이 2가지로 나뉘어진다.

    1. S3 Bucket을 만들고, ELB Access log를 Enable 하면서 해당 S3 Bucket을 지정해 준다.
    2. ELB Access log를 Enable 하면서 자동 생성을 채크 한다.

이 설정 매뉴월은 아래와 같다. (아마존 만큼 문서화가 잘 된 Cloud 는 없는 듯)

http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/access-log-collection.html

참고로, 장애 원인 분석하다 보면 혼동이 오는게 있는데 ELB Access log 에 기록이 남아도 CloudWatch 의 request count 는 올라가지 않는 경우가 있습니다. 이는 Request count 는 Backend-Instance에 전달된 것만을 요청으로 보기 때문입니다. (즉, Backend-Instance로 전달되지 않았다고 판단되는 경우 Count가 올라가지 않습니다.)

이에 관련된 예를 든다면, ELB를 사용하다가 Backend Instance를 모두 제거 된 경우 ELB에 서비스 요청을 하면, HttpCode_ELB_5xx 카운트는 올라가지만 Request Count는 올라가지 않습니다. ^^

장애분석등을 하기 위해서는 ELB Access log 항목에 대한 이해도 필요한데, 이 부분은 문서에 잘 나와 있습니다. 위의 링크를 보시기를..

혹, 보다가 잘 모르시겠다 싶으신 경우 글 남겨 주세요. 답글 달아 드리겠습니다.]]> AWS Thu, 05 Feb 2015 17:32:08 +0900 ELB Pre-warm 신청은 어떻게 하는가? http://coffeenix.net/bbs/viewtopic.php?p=10125#10125 아마존에서는 이 Scale system 으로 대부분의 경우 사전에 ELB의 용량을 높혀 놓을 필요는 없다고 한다.(pre-warm 은 ELB 의 capacity를 사전에 높혀 놓는 것을 말한다.)


--------------- quote --
Amazon ELB is able to handle the vast majority of use cases for our customers without requiring "pre-warming" (configuring the load balancer to have the appropriate level of capacity based on expected traffic).

--------------- /quote --


그러나, flash 트래픽이나 점진적으로 트래픽을 증가시킬수 없는 load 테스트의 경우에는 Pre-warm 을 위해 아마존에 contact 하기를 추천한다고 한다.


--------------- quote --
In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed".

--------------- /quote --



그러면 이렇게 급격한 트랙픽이 예상 되는(flash traffic/load test) 경우 어떻게 Pre-warm을 요청하여야 하는가? 몇 가지 항목이 필수로 필요하다. 이 항목은 아래와 같다.

    1. ELB를 사용하려는 모든 AZ(Available Zone)에 Instance 스가 In service 상태로 하나이상이 꼭 있어야 합니다.
    2. TPS
    3. 요청시(request/response pair) ELB 에서 처리되는 데이터의 평균 양
    4. Backend Instance 의 Keep-alive 여부
    5. SSL 트래픽 비율
    6. Pre-warm을 할 기간(start-end)
    7. use case(왜 요청하는가?)
    8. Backend Instance 증설 여부(실제 처리하는 Backend Instance 가 Pre-warm 요청하는 양을 처리할 수 있는지를 확인 한다.)


use case 부분이 적절하여야 하며 산정한 규모에 맞게 Backend Instance가 준비되어 있다면 문제 없이 허용될 것으로 보인다. Backend Instance가 규모에 맞게 준비되어 있지 않다면 아마도 아마존이 Pre-warm을 해주지 않을 것이다. 산정된 규모에 맞게 Backend Instance가 없다면 아마존 입장에선 Pre-warm이 의미가 없고 비용만 낭비하는 것일테니까

위 항목을 보고 모르시는 사항은 글 남겨주세요 답변 달아 놓겠습니다.]]> AWS Thu, 05 Feb 2015 17:16:49 +0900 ELB(Elastic Load Balancer) 의 Scale up 방식 http://coffeenix.net/bbs/viewtopic.php?p=10083#10083
물론, 사용량이 줄게 되면 반대의 행위가 이루어진다.

현재 사용량이 늘어날 경우 Scale up이 먼저 발생하고, 다음에 Scale out이 발생한다.

ELB Scale이 발생하게 되면 해당 도메인의 Public IP(node가 변경됨으로)가 바뀜으로 지속적인 쿼리를 통해 Scale이 발생한 내역을 확인 할 수 있다. (CloudWatch 나오지 않는다. 별도로 아마존에 문의해야 확인됨으로..)

거두절미 하고, ELB Scale 방식은

1. 현재 ELB node 보다 큰 Type의 Instance를 ELB에 추가.
2. 기존 ELB node(Instance)는 DNS Lookup 에서 제외.
- 빠진 ELB node는 요청이 없을때까지 서비스를 한다.(ELB에서 빠지는건 아니다. DNS 에서 IP가 제외될 뿐이다.) 그 후에 terminate 되거나, 7일 이후에 terminate 되어진다.

해당 방식으로 보면 ELB Scale 시에 서비스에 영향은 없어야 한다. 그러나, Unhealth Count가 Scale 시 발생하기도 한다.]]> AWS Wed, 30 Apr 2014 16:07:20 +0900 AWS 4월 주요 뉴스 http://coffeenix.net/bbs/viewtopic.php?p=10082#10082
자세한 내용은 Amazon Web Service Blog(http://aws.typepad.com/)를 참조 하십시오.

1. Memory Optimized Type 인 R3 Type 이 출시 되었습니다.

- New Memory-Optimized EC2 Instances (R3) (http://aws.typepad.com/aws/2014/04/now-available-new-memory-optimized-ec2-instances.html)


2. AWS Elastic Beanstalk 에서 ruby2를 지원하게 되었습니다.

- AWS Elastic Beanstalk for Ruby 2 (http://aws.typepad.com/aws/2014/04/aws-elastic-beanstalk-for-ruby-2.html)


3. RDS 에서 Mysql 5.5 에서 5.6 업그레이드를 아마존에서 지원하게 되었습니다.

- MySQL 5.5 to MySQL 5.6 Upgrade Support for Amazon RDS (http://aws.typepad.com/aws/2014/04/mysql-55-to-mysql-56-upgrade-support-for-amazon-rds.html)


4. oracle RDS Instance를 OGG(Oracle Golden Gate)의 source 로 사용할 수 있게 되었습니다.

- Use Oracle GoldenGate with Amazon RDS for Oracle Database(http://aws.typepad.com/aws/2014/04/use-oracle-goldengate-with-amazon-rds-for-oracle-database.html)]]> AWS Wed, 30 Apr 2014 10:54:22 +0900 [요리] 간편 닭계장 만들기 http://coffeenix.net/bbs/viewtopic.php?p=8847#8847

안녕하세요! jjun입니다.

집이나 캠핑갔을때 간편하게 만들어 먹을 수 있는 닭계장 요리법을 소개합니다.
간편함을 위해서 주로 캔, 건조식품을 이용합니다.

재료 : 닭가슴살 캔 2개, 건조야채(육개장용), 양념
제가 사용한 건야채 판매하는 곳 : http://www.siworl.com/

1. 우선 건조야채를 물에 미리 불렸다가(30분정도는 하는게 좋을것 같아요. 질긴지 씹어 보는게 좋을듯.), 물을 넣고 팔팔 끓입니다.




2. 물을 끓이는 동안에 닭고기에 양념을 버무립니다.

양념 : 고춧가루 2숫갈, 다진마늘 2숫갈, 국간장 1술갈, 후춧가루 약간, 참기름 1/2숫갈
저는 캠핑용 양념통으로 애기 약병을 이용했습니다. 다진 마늘은 화장품 알뜰용기 등을 이용하면 될듯해요. ^^


닭고기 캔은 살짝 딴후에 물을 뺀후 이용하시면 됩니다.


다음과 같이 고기와 양념을 버물려주세요.



3. 끓고 있는 물에, 양념한 고기를 넣습니다.


4. 다 익어갈쯤에(기준은 야채가 먹을만치 익었나) 고추를 송송 썰어넣고, 달갈 1개를 풀어서 넣어줍니다. (달걀푼것을 젓지 마세요, 원을 그려가며 천천히 넣어주시면 됩니다.)




5. 다음과 같이 맛난 닭계장이 됩니다.



6. 캠핑가서 먹는 것처럼 집에서도 간편하게 먹어봅니다. ^^
햇반, 맛김, 마늘짱아찌, 닭계장



다음에는 jjun는 백패킹 장비 리스트를 보여드릴께요~ ^^]]> AWS Thu, 30 Aug 2012 16:58:19 +0900 눈 엄청 왔다. 온통 눈세상 http://coffeenix.net/bbs/viewtopic.php?p=2080#2080 오늘 하루만에 34cm 이상의 폭설이 왔다.

덕분에(?) 오후 4시 퇴근에, 낼은 휴무다.. ㅋㅋ




]]> AWS Thu, 22 Dec 2005 00:31:05 +0900