달력

12

« 2025/12 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2016. 4. 1. 12:13

AWS 서울 리전 신규 서비스 출시 소식 Cloud2016. 4. 1. 12:13

아마존 웹 서비스(AWS)에서 생각보다 빠르게 서울 리전에 대한 서비스를 추가해 나가고 있습니다.


AWS에서 발생하는 모든 변경 사항을 추적하고 로깅하는 서비스인 AWS Config를 이제 서울 리전에서도 사용할 수 있으며,

아직 도쿄 리전에서도 제공되지 않는 MS SQL의 RDS 서비스에 대한 Multi-AZ(이중화)를 지원합니다. (와우~!) 


그리고, AWS의 말을 빌리면 'MySQL과 완벽한 호환성을 제공하면서 5배의 성능을 제공한다'고 하는 Aurora RDS 서비스도 서울 리전에서 사용할 수 있게 되었습니다.



위에 언급한 서비스들은 지금 바로 사용이 가능합니다.




자세한 내용은 아래 링크를 참고하세요.



AWS Config, 서울 리전 출시!

https://aws.amazon.com/ko/blogs/korea/aws-config-launches-in-asia-pacific-seoul/


Amazon RDS for SQL Server, 다중-AZ 미러링 기능 서울 리전 지원!

https://aws.amazon.com/ko/blogs/korea/amazon-rds-for-sql-server-add-mirroring-support-seoul-region/


Amazon Aurora, 서울 리전 출시!

https://aws.amazon.com/ko/blogs/korea/amazon-aurora-now-available-in-seoul-region/



:
Posted by 커널64

HAProxy는 L4/L7 로드 밸런서 역할을 해주는 오픈 소스 소프트웨어입니다.

성능 또한 나쁘지 않기 때문에 물리적으로 로드 밸런서를 둘 수 없는 상황이라면 좋은 대안이 될 수 있을 것 같습니다.


저는 개인적으로 Linux 환경에 익숙하지 않은데, 저와 같은 분들을 위해 설치 절차를 정리해 공유합니다.


먼저, 테스트 시스템 환경은 다음과 같습니다.


- HAProxy VIP: 192.168.0.150

- HAProxy #1: 192.168.0.151

- HAProxy #2: 192.168.0.152


- Web Server #1: 192.168.0.153

- Web Server #2: 192.168.0.154



1. CentOS 7을 설치합니다. 저의 경우 최소 설치 모드로 설치한 후 SELINUX를 Disable 하였습니다.

vi /etc/sysconfig/selinux

SELINUX=disabled


2. 두 HAProxy 서버에 HAProxy와 keepalived 패키지를 설치합니다.

yum install -y haproxy keepalived


3. 먼저, keepalived를 설정하겠습니다. 원본 설정 파일을 복사해 새 설정 파일을 만듭니다.

cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.origin


4. 텍스트 편집기로 /etc/keepalived/keepalived.conf 설정 파일을 엽니다.

vi /etc/keepalived/keepalived.conf


5. 메일 알림 관련 설정은 삭제합니다.

global_defs {

   notification_email {

   }

}


6. virtual_ipaddress 항목을 VIP로 설정하고, 아래의 나머지 설정들은 삭제합니다. MASTER 서버는 state MASTER, priority 200, BACKUP 서버는 state BACKUP, priority 100으로 설정합니다.

vrrp_instance VI_1 {

    state MASTER

    interface eth0

    virtual_router_id 51

    priority 200

    advert_int 1

    authentication {

        auth_type PASS

        auth_pass 1111

    }

    virtual_ipaddress {

        192.168.0.150

    }

}


7. 두 HAProxy 서버에서 keepalived를 실행합니다.

service keepalived start


8. 간단히 테스트를 위해 VIP로 ping으로 테스트해 본 결과 MASTER에서 BACKUP으로의 Failover 시에는 ping이 적게는 1개, 많게는 3개가 빠지는 것으로 확인되었으며, BACKUP에서 다시 MASTER로의 Failback 시에는 ping loss 없이 되는 것을 확인할 수 있었습니다.




여기까지는 HAProxy 서버에 대한 이중화를 위한 구성이었으며, 이제부터의 작업은 실제 로드 밸런싱을 처리하는 패키지인 HAProxy에 대한 설정을 설명합니다.


HTTP 및 TCP에 대한 로드 밸런싱이 가능하기 때문에 필요에 따라 여러 서비스(DB, Redis 등)에 대한 부하 분산 용도로 사용이 가능합니다만, 여기서는 일반적으로 웹 서버에 대한 부하 분산 설정으로 구성합니다.


또한, 단순히 HTTP 요청(TCP 80)을 Backend 서버로 전송하도록 설정하는 경우에는 웹 서비스마다 HAProxy를 두어야 하는 상황이 될 수 있기 때문에 요청 주소에 따라 분기하도록 하고, 쿠키를 사용한 Sticky Session 설정을 한 구성입니다.



9. 원본 파일은 복사해 둔 후 HAProxy 설정 파일을 텍스트 편집기로 엽니다.

cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.origin

vi /etc/haproxy/haproxy.cfg


10. 아래는 호출한 도메인에 따라 두 대의 Backend 서버로 각각 분기하는 예제입니다. 

global

    log           127.0.0.1 local2

    chroot      /var/lib/haproxy

    pidfile       /var/run/haproxy.pid

    maxconn 100000

    user        haproxy

    group      haproxy

    daemon

    stats socket /var/lib/haproxy/stats


defaults

    mode                    http

    log                     global

    option                  httplog

    option                  dontlognull

    option http-server-close

    option forwardfor       except 127.0.0.0/8

    option                  redispatch

    retries                 3

    timeout http-request    10s

    timeout queue           1m

    timeout connect         10s

    timeout client          1m

    timeout server          1m

    timeout http-keep-alive 10s

    timeout check           10s

    maxconn                 3000


#-------- Custom Error Page

#    errorfile 400 /etc/haproxy/errors/400.html

#    errorfile 403 /etc/haproxy/errors/403.html

#    errorfile 408 /etc/haproxy/errors/408.html

#    errorfile 500 /etc/haproxy/errors/500.html

#    errorfile 502 /etc/haproxy/errors/502.html

#    errorfile 503 /etc/haproxy/errors/503.html

#    errorfile 504 /etc/haproxy/errors/504.html



#------- Main Frontend

frontend   http *:80

#-- redirect http to https     

#   redirect scheme https if !{ ssl_fc }

    acl host_name1 hdr(host) -i naver.com www.naver.com

    acl host_name2 hdr(host) -i daum.net www.daum.net


    use_backend webfarm1 if host_name1

    use_backend webfarm2 if host_name2


#------- Web Farm #1

backend webfarm1

    mode http

    balance roundrobin

    option httpchk GET / HTTP/1.0

    option log-health-checks

    option forwardfor

    option httpclose

    cookie SERVERID insert indirect nocache

    stats enable

    stats uri /haproxy

    server node1 192.168.0.153:8081 cookie node1 check inter 1000 rise 3 fall 3

    server node2 192.168.0.154:8081 cookie node2 check inter 1000 rise 3 fall 3


#------- Web Farm #2

backend webfarm2

    mode http

    balance roundrobin

    option httpchk GET / HTTP/1.0

    option log-health-checks

    option forwardfor

    option httpclose

    cookie SERVERID insert indirect nocache

    stats enable

    stats uri /haproxy

    server node1 192.168.0.153:8082 cookie node1 check inter 1000 rise 3 fall 3

    server node2 192.168.0.154:8082 cookie node2 check inter 1000 rise 3 fall 3


11. 구성 파일을 저장한후 각각의 HAProxy 서버에서 서비스를 시작 후 정상적으로 시작되었는지 확인합니다.

service haproxy start

systemctl status -l haproxy.service

12. 부팅 시 각각의 서비스가 시작되도록 설정합니다.

systemctl enable keepalived

systemctl enable haproxy


13. 이제 테스트를 위해 Windows 클라이언트에서 HOSTS 파일에 daum.net과 naver.com에 대한 IP 주소를 HAProxy의 VIP로 설정한 후 테스트해 정상적으로 부하분산이 되는 것을 확인하였습니다. Fiddler로 요청을 확인해 보면 아래와 같이 Cookie 정보를 받아오는 것을 확인할 수 있습니다.



14. 설정에 따라 /haproxy 페이지로 이동하면 전체적인 노드 응답 상태, 요청 수 등의 상황을 확인할 수 있습니다.




전체 설정 옵션은 아래 링크를 참고하세요.

http://cbonte.github.io/haproxy-dconv/configuration-1.5.html




HAProxy_cfg_L4_PortOnly.txt


HAProxy_cfg_L7_Hostname.txt








:
Posted by 커널64
2016. 3. 29. 20:24

AWS Auto Scaling의 기본 Termination 정책 Cloud2016. 3. 29. 20:24

AWS의 서비스 중 부하에 따라 L4 하단 노드(서버)를 자동으로 증가(Scale out) 또는 축소(Scale in) 시키는 Auto Scaling이라는 좋은 기능이 있습니다. 그런데, Scale in 발생 시 어느 노드를 선택해 중지(Termination) 시킬까요?




기본적으로, 가용성을 최우선 순위로 하며, 순서적으로 정리하면 다음과 같습니다.

Scale-in 이 발생할 때의 순서이며, 해당하는 EC2 인스턴스가 하나이면 종료됩니다.


1) 다중 가용존(Muliple AZ) 구성의 경우, EC2 인스턴스가 가장 많은 AZ 선택

2) 가장 오래된 Launch Configuration으로 구동된 EC2 인스턴스(들) 선택

3) 구동 시간 기준으로 다음 과금 시간에 가장 가까운 EC2 인스턴스(들) 선택

4) 위 과정을 거쳤으나 선택된, 해당되는 EC2 인스턴스가 여러 개일 경우 무작위 선택




:
Posted by 커널64