AWSKRUG 활동 목록

※AWS 강남 비기너 그룹에서 활동 하고 있습니다. 다양한 경험 접해보고 싶습니다.
AWSKRUG 슬랙[커뮤니케이션]
AWS 유저그룹 사이트
AWSKRUG Meetup
AWSKRUG Facebook

17년 4월 19~20일 AWS Summit 이 있습니다. 참가하시는 분들은 뵐 거 같네요~! 

AWS 슬랙 그룹 가입 하셔서 #gangnambeginner 채널에서 인사 부탁드려요
관련 행사 참석에 관심 있으신 분은 아래 달력 참고하시길 바래요~

Slack 가입 안되시는 분들은 링크 참고

AWSKRUG 이벤트 구글 캘린더

AWS SAA 합격 후기 도 필요하신 분 참고 바라요~

Advertisements

Elasticache / Linux 문제

Elasticache의 노드는 보통 싱글 노드당 약 50만 정도의 연결을 수립할 수 있습니다. 하지만, 리눅스 단에서 Elasticache를 연결하기 위해서는, 포트가  필요한데, 리눅스의 사용 가능 포트 기본 값은 약 5만개로 아래와 같이 확인할 수 있습니다.

| # cat /proc/sys/net/ipv4/ip_local_port_range
| 32768 60999
| # expr 60999 – 32768
| 28231

해결 방법은 아래와 같습니다.

| $ sudo sysctl -w net.ipv4.ip_local_port_range=”1024 65535″

이 방법은 재부팅 시, 없어지는 항목이므로, /etc/sysctl.conf에 아래 한 줄을 적습니다.

net.ipv4.ip_local_port_range=”1024 65535″

Python의 파이프라인 기능을 사용하면, 같은 TCP 연결에서 여러개의 요청을 보낼 수 있습니다. 아래는 예제입니다.

r = redis.Redis(host='<Elasticache_Endpoint>’, port=6379, db=0)
p = r.pipeline()

p.set(‘key1’, ‘valueA’)
p.set(‘key2’, ‘valueB’)
p.set(‘key3’, ‘valueC’)
p.set(‘key4’, ‘valueD’)
p.set(‘key5’, ‘valueE’)

p.execute()

참고하면 조금 더 잘 쓸 수 있을 거 같습니다.

 

Cloudfront 잘쓰기

CloudFront(이하 CF) 는 아마존에서 제공하는 CDN 서비스 입니다.

CF를 사용하다보면, 예상치 못한 트래픽 증가 및 비용 증가를 경험할 수 있습니다. 그래서 CF 최적화 작업이 필요한데요, 그 방법은 2가지 정도가 있습니다.

CF 압축 옵션 / CF Cache-Control 옵션.

CF 압축은 텍스트, CSS 파일 등 이 압축 가능하며, 이미지는 이미 압축되어 있음으로 이 항목을 적용하여도 동일한 파일 사이즈로 End-User에게 전달됩니다.

CF – S3 연동 시, Cache-Control 메타데이터를 S3에 먼저 적용하지 않고, 연동 후 Cache-Control을 적용하여도 CF상에서는 적용이 되지 않기 때문에, Purge 작업이 필요합니다. 그러므로, 처음 CF와 연동 시, Cache-Control 작업을 시행 후, CF에 연결하도록 합시다~

EC2 당 붙일 수 있는 EIP 개수는?

EC2에는 여러 개의 EIP를 부착할 수 있다. 그러기 위해서는 ENI(기본제한 350개)를 사용해야하며, EIP의 기본 제한은 5개로, Limit Increase가 필요할 수 있다.

또한 EC2 Type 별로 부착할 수 있는 EIP 개수는 제한이 된다.  아래의 표를 확인해 보자.

 

EC2 Type           최대 ENI 개수                  최대 Private IP 개수 (IPv4)  최대 Private IP 개수(IPv6)
170920 ec2 당 eip 개수.PNG

http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-eni.html

EIP 의 경우, ENI의 개수와 동일하게 생성 가능하다 (1:1 매칭) 주의해야 한다.

EB 2개 생성 후 API 통신 시 TroubleShooting

EB를 통해 배포 자동화를 하고, 2 개의 EB끼리 API 통신을 하는 경우가 있다.
하지만 배포마다 EB 밑 단의 EC2의 공인 아이피가 바뀌므로, 상대 EB-ELB의 도메인을 질의했을 때, ELB의 Security Group에 요청하는 EC2의 정보가 없으므로, 요청이 거부된다. 간단하게 그림으로 표현하면 아래와 같다.170809_야놀자_EB_관련.PNG

위와 같은 현상은 보안 그룹을 규칙의 원본 또는 대상으로 지정할 경우 규칙은 보안 그룹과 연결된 모든 인스턴스에 영향을 주기 때문이다. 유입 트래픽은 퍼블릭 IP 주소 또는 탄력적 IP 주소가 아닌 원본 보안 그룹과 연결된 인스턴스의 프라이빗 IP 주소를 기반으로 허용된다. EB에서 제공하는 도메인의 경우, DNS 질의를 하기 때문에, VPC 외부로 통신을 했어야 하고, 공인 IP로 통신하게 된다. 그러므로 공인 IP를 상대 ELB SG에 추가하는 작업이 필요하다. 하지만 자동화 하는 방법은 없을까?? (참고로 internal ELB로 만들면 문제가 없이 도메인으로 정상 통신된다)

해결책 1. 배포 때마다 새로 생성되는 EC2에 대해서 Public IP를 고정하는 방법이 있다
⇒ 기존에 SG에 추가된 EIP를 disassociate 및 reassociate 하는 AWS CLI 스크립트 작성이 필요할 것으로 보이며, 상대 ELB에 해당 EIP만 SG에 추가하면 된다.

해결책 2. 배포 때마다 새로 생성되는 EC2의 Public IP를 불러와 상대 ELB SG에 추가하는 방법이 있다
⇒ EC2의 유저데이터에 메타데이터를 이용하여 새로 생성된 EC2의 Public IP를 가져와, AWS CLI를 이용하여 상대 측 ELB에 추가하는 스크립트를 이용하여 자동화 할 수 있다. 하지만 이 경우, 보안 상으로기존에 있던 SG의 삭제도 자동화가 필요하다.

해결책 3. EB 배포시 EC2를 Private network으로 두고, 모든 트래픽을 Public Network에 있는 NAT를 통해서 통신하도록 하는 방법
⇒ Public Subnet에 NAT Gateway를 생성하고, EIP를 배정합니다. EB에서 배포 시 Private network에 생성되더라도 모든 트래픽이 NAT를 통하기 때문에 NAT의 EIP만 상대 EB SG에 추가해서 통신하면 된다.

170809_야놀자_EB_관련_2.PNG

 

ELB SSL 적용 및 리디렉션 설정

ELB 에 SSL 을 적용하고 80포트를 443포트로 보내 도메인을 접근할 때, 자동으로 https로 전환하여 모든 통신을 암호화 하도록 설정할 수 있습니다. 우선 준비물로 ACM에서 발급받거나 직접 업로드한 사용 가능한 SSL 인증서가 필요합니다.

1)  ACM 에서 보유 도메인 인증서 신청 및 메일 확인으로 승인

2)  사용 가능한 인증서를 ELB 443 포트에 넣고 81 포트로 리슨하도록 설정
– 80포트는 80포트로 가되, 301 Status Code로 리디렉션 설정

3)  ELB 밑단 인스턴스 접속 및 nginx 설치 후 아래와 같이 설정

vim /etc/nginx/conf.d/1.conf    ## 생성

server {
listen 80 default_server;
listen [::]:80 default_server;
server_name xxx.awssupport.net;
return 301 https://xxx.awssupport.net;
}

vim /etc/nginx/sites-enabled/default   ## listen 80->81
server {
       listen 80 default_server;
       listen [::]:80 default_server ipv6only=on;

       root /usr/share/nginx/html;
       index index.html index.htm;

        # Make site accessible from http://localhost/
       server_name localhost;

       location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
               try_files $uri $uri/ =404;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
       }

service nginx restart    ## 재시작 후 적용

CloudFormation 시작하기

CloudFormation은 json 템플릿 형태를 가진다. CloudFormation은 Chef기반으로 사용하게 되면 설정한 대로 알아서 VPC 및 EC2 생성, Security Group 설정 등이 가능하다.

우선 템플릿 기본구조이다.

{
   "Description" : "이 곳에는 템플릿의 Description을 입력한다.",
   "Parameters": {
   // 스택을 생성할 때 사용자가 입력할 매개변수들이다.
   },
   "Resources" : {
   // AWS 리소스들의 설정 내용 그리고 리소스들간의 관계에 대해 정의할 수 있다.
   },
   "Outputs" : {
   // 스택을 생성 후 출력할 내용이다.
   },
   "AWSTemplateFormatVersion" : "2010-09-09"
}

EC2를 생성하고 EIP를 붙이는 작업을 해주는 템플릿은 아래를 참고한다.
https://s3-us-west-2.amazonaws.com/cloudformation-templates-us-west-2/EIP_With_Association.template

AWS 에서 제공하는 기본 템플릿 모음 문서 사이트

http://docs.aws.amazon.com/ko_kr/AWSCloudFormation/latest/UserGuide/sample-templates-services-us-west-2.html

  • AWS CloudFormer를 사용하면 현재 VPC 자원에 대해 자동으로 템플릿으로 생성해준다.
  • AWS CloudFormation Designer를 사용하면 조금 더 쉽게 접근할 수 있다.