interplanetary detour

Sysops 과정은 총 12개 모듈로 구성되어 있으며, 개중에 한 단계 더 분리된 모듈도 존재한다.

Tess와 Arch에서 배운 기초적인 내용이 포함되어 있어 복습 목적의 정리 또한 병행한다.

Module 1 : Systems Operations on AWS 소개

Region

• AWS 서비스가 제공되기 위한 인프라의 논리적인 위치
• 지리적 대표 도시명으로 나타낸다.
• 멀티 AZ로 DR(Disaster Recovery) 구성을 위해 반드시 2개 이상의 AZ가 포함되어야 한다.
• 현재 25개 리전 존재

Availability Zone

• 하나 이상의 데이터센터를 클러스터로 묶은 논리적 단위
• 현재 81개 AZ 존재

Edge Location

• AWS Route53, AWS CloudFront, AWS WAF 등 글로벌 서비스를 위한 인프라
• Region, AZ와 다르게 사용자가 지정할 수 없음

AWS Well-Architected Framework

• AWS 아키텍처 모범 사례를 포함한 백서
• 5가지 핵심 요소
  • 보안
  • 안정성
  • 성능 효율성
  • 비용 최적화
  • 운영 우수성

AWS Well-Architected Tool

• WAF와 다르게 Management Console의 툴로써 제공되며, 일련의 질문에 대답하며 더 간편하게 인프라 구조를 검토할 수 있다.

시스템 운영의 요소

• 배포
  • 인프라 환경의 구성

• 모니터링
  • 모니터링을 통해 개선점 등을 발견
• 고도화
  
  • 구조의 효율성을 위한 변경
• 보안
  • 권한의 핸들링 등 보안 솔루션 관리
• 최적화
  • 고도화와 유사하게 시스템 최적화

운영 우수성 원칙

• 설계 원칙
  • 코드형 작업 수행
  • 작은 규모로 손쉽게 롤백이 가능한 변경 수행
  • 운영 절차의 지속적 개선
  • 장애 예측
  • 모든 운영 실패에서 교훈 습득

단계별 운영 우수성 핵심 서비스

• 준비
  • AWS Trusted Advisor
  • AWS CloudFormation
  • AWS 개발자 도구
  • AWS X-Ray
  • AWS Config
  • AWS Systems Manager
• 실행
  • Amazon CloudWatch
  • Personal/Service Dashboard
  • Amazon CloudWatch
  • Amazon ElasticSearch
  • Amazon SNS
  • Auto Scaling
  • AWS Systems Manager
• 개선
  • Amazon QuickSight
  • Amazon Athena
  • Amazon S3
  • Amazon CloudWatch
  • Amazon Machine Image
  • Amazon SNS
  • AWS Lambda
  • AWS CloudFormation

AWS Trusted Advisor

• 비즈니스 레벨 이상의 AWS Support Plan을 이용할 때 제공받을 수 있는 유지 보수에 대해 도움을 주는 서비스이다.
• https://aws.amazon.com/ko/premiumsupport/plans/

AWS Simple Monthly Calculator

• 리소스에 대한 월별 지불할 비용을 계산해주는 서비스
• 예산 산출에 이용된다.
• 현재 콘솔 상에서 이용하는 AWS Pricing Calculator 개발로 인해 Deprecate 예정이다.
• https://calculator.s3.amazonaws.com/index.html?lng=ko_KR

AWS Cost Explorer

• 비용 및 사용량에 대한 데이터를 분석하여 시각적으로 확인할 수 있게 해주는 서비스
• 가계부와 비슷하다고 볼 수 있음
• https://aws.amazon.com/ko/aws-cost-management/aws-cost-explorer/

Module 2a - 액세스 관리

IAM (Identity and Access Management)

• 인증
  • 맞는 사용자(관리자)인지 확인
  • Management Console 접근은 사용자 ID와 PW, CLI와 SDK 접근은 액세스 키와 시크릿 액세스 키로 인증
• 인가
  • 관리자에 대해 권한을 제어
  • JSON 파일로 Policy를 지정
  • 권한을 할당할 때 최소 권한의 원칙 준수

IAM 권한 유형

• 자격 증명 기반 정책
  • IAM 사용자 종속 
  • 리소스에 관계없이 IAM 사용자에게 권한을 지정한다.
• 리소스 기반 정책
  • 리소스 종속 
  • 리소스에 대한 특정 IAM 사용자의 권한을 지정한다. 
  • 자격 증명 기반과 달리 JSON 파일에 Principal 속성이 포함되어 있다. IAM 사용자를 나타낸다.

STS & Role

• 임시 자격 증명
• 강사가 사옥에 들어갈 때 방문증을 받듯이 임시로 역할을 부여
• STS와 Role은 같이 동작한다.
  • STS가 임시 자격 증명을 발행한다.
  • Role이 권한을 위임한다.

연동 사용자

• SAML 2.0 또는 OpenID Connect를 통해 외부 사용자와 신뢰 관계를 맺는다.
• 이후 STS와 Role을 통해 임시 접근 자격을 부여한다.

IAM 그룹

• IAM 사용자의 모음
• 한 IAM 사용자는 여러 그룹에 속할 수 있음
• 권한은 IAM 정책을 통해 부여됨
• 그룹을 중첩할 수 없음
• 그룹은 보안 주체가 아님

Role on Resource

EC2 인스턴스의 어떤 애플리케이션이 S3 또는 DynamoDB와 상호 작용을 해야한다고 가정했을 때, 애플리케이션에 Role을 부여해서 접근 권한을 지정해 상호 작용을 할 수 있게 한다.

PassRole

Role을 부여할 수 있는 관리 권한

정책 평가 우선순위

• 명시적 Deny : Deny
• 명시적 Allow : Allow
• 명시적 Allow + 명시적 Deny : Deny
• 명시되어 있지 않음 : Deny

Policy 항목 5가지 : 예시 

1. (Required) Resource : EC2
2. (Required) Action : stop / start
3. (Required) Effect : allow / deny
4. (Optional) Condition : 특정 IP 지정 등 조건 지정
5. (리소스 기반 정책) Principal : IAM 사용자 아이덴티티 기술

Policy 생성 방법

• 편집기로 JSON 문서 작성
• AWS 관리형 정책 사용
  • 수정, 편집 불가
• IAM Policy Generator/Simulator 등의 GUI 기반 툴을 통해 생성

자격 증명 관리

• 환경 간 권한은 일관되어야 한다.
• IAM 자격 증명 보고서 검토
  • 주기적 액세스 키 교체
  • 불필요한 자격 증명 삭제

ARN (Amazon Resource Name)

Policy에 리소스 아이덴티티를 기술할 때 사용된다.

AWS Organizations

개발 계정, 테스트 계정, 프로덕션 계정, 공유 서비스 계정 등 여러 계정을 하나의 엔터프라이즈 기업에서 부서별로 관리할 수 있게 해주는 서비스이다.

• 중앙 집중식 계정 관리 및 감사
• 자동화된 계정 생성 및 관리
• 그룹 기반 계정 관리
• 서비스 비용 통합 결제
• SCP(Service Control Policy) : OU(Organization Unit), 루트 계정에도 액세스 제어가 가능
• 트리 구조로 조직도와 같이 구성된다.

Module 2b : 시스템 검색

AWS 리소스와의 상호 작용

• AWS Management Console
  • GUI 관리 툴을 사용해 AWS 서비스에 접속
• AWS CLI
  • 명령어를 통해 AWS 서비스에 접속
• SDK
  • 대부분의 주요 프로그래밍 언어에서 AWS 서비스 API 호출

AWS CLI

• 명령어 구조 : Service - Operation - Parameter - Options
• 단계마다 help 명령어가 전부 제공된다.

Commands & Options

• aws configure 명령어를 통해 액세스 키, 시크릿 액세스 키, 리전 이름, 출력 형식 등을 설정할 수 있다.
• --dry-run
  • 명령어를 실행하지 않고 권한만 확인한다.

AWS Session Manager

• IAM 정책으로 중앙 집중식 액세스 제어
  • 이 때문에 SSH 등 보안성 통신이 아니어도 보안적 이슈가 생기지 않는다.
• Windows, Linux 크로스 플랫폼 지원
• VPC Endpoint를 통해 EC2 인스턴스에 리모트로 연결
  • Jumping Host 없음
  • 인바운드 포트 불필요 (내부적으로 포트포워딩)
  • SSH 키 없음
  • ssm-user에 대한 관리 권한
• 세션 활동 및 로깅 감사
  • AWS CloudTrail (API 호출 로그)
  • Amazon S3
  • Amazon CloudWatch

AWS Systems Manager

리소스를 규모에 따라 안전하게 관리하고 운영할 수 있도록 지원한다.

• 그룹 리소스 (업무 단위로 그룹핑)
• 데이터 시각화
• 작업 수행
• 에이전트 기반

AWS Config

변경 사항을 일관된 형식으로 기록하고 정규화한다. 사내 인프라에 대한 규정을 준수하게 하는 목적.

• 리소스 검색
• 레코드 구성
• 변경 사항 캡처
• 변경 사항 분석 및 문제 해결
• Organizations 환경에서 복수 계정 인벤토리 데이터가 하나의 대시보드에 표시될 수 있다.
• 설정 프로세스
  1. 설정 지정
  2. 규칙 선택
  3. AWS Config에서 리소스 기록 시작
  4. 데이터 보기

AWS Config 규칙

• 관리형 규칙
  • AWS에서 정의하고 관리
  • 구성이 거의 또는 전혀 필요없음
• 사용자 지정 규칙
  • 고객이 정의 및 유지
  • AWS Lambda 사용

Ansible

• 개요 및 장점
  • Agentless
    • Puppet, Chef와 달리 에이전트를 설치할 필요가 없다. OpenSSH 또는 WinRM을 이용하여 각 노드에 앤서블 모듈을 푸시하여 그것을 통해 설정 구성을 실행한다.
  • 고도의 프로그래밍 기술 불필요
  • 쉬운 팀 간 작업 공유
  • 멱등성 지원
    • 멱등성이란 몇 번을 연산해도 항상 같은 결과가 나오는 성질.
    • 패키지 등을 재설치하지 않고 일부만 변경 가능
    • 중복 방지
    • Shell, Command, File Module은 멱등성 미지원
  • 700가지 이상 대다수의 서버와 네트워크 장비 지원
• 앤서블에서 [서버 <--> 노드] 통신 조건
  • 프로토콜
    • Linux : SSH
    • Windows : WinRM(Windows Remote Management)
  • 포트
    • Linux : 22
    • Windows : 5985(HTTP), 5986(HTTPS)
  • 사용자
    • vagrant 동일
• 실습
  • 설치 및 ansible 모듈
    • 앤서블 서버에서 설정 : 1개
      • apt install -y ansible
        • Ansible Core 설치
      • apt install -y sshpass
        • CentOS에선 한 번에 설치?
      • ls /usr/bin/ansible*
        • 모듈 확인
        • ansible : 단일 태스크
        • ansible-playbook
    • 모든 서버 및 노드에서 설정 : 4개
      • passwd root
        • 루트 패스워드 설정
      • apt update
      • ssh 서비스 config 파일 수정
        • sed -i "s/^PasswordAuthentication no/PasswordAuthentication yes/g" /etc/ssh/sshd_config
        • sed -i "s/^#PermitRootLogin prohibit-password/PermitRootLogin yes/g" /etc/ssh/sshd_config
        • systemctl restart sshd
    • 앤서블 서버에 인증키 설정
      • hosts 파일에 노드 추가
        • echo 10.2.11.121 >> /etc/ansible/hosts
        • echo 10.2.11.122 >> /etc/ansible/hosts
        • echo 10.2.11.123 >> /etc/ansible/hosts
      • 인증키 저장
        • ansible all -m ping
          • yes * 3
    • ansible all -m ping -k
      • SSH password:
        • 초록색으로 SUCCESS가 뜨면 인증키 저장 성공.
    • 그룹핑 이후
      • ansible nginx -m ping -k
    • echo 10.2.11.121 >> customized_invent.lst
    • echo 10.2.11.122 >> customized_invent.lst
    • ansible -i customized_invent.lst all -m ping -k
    • ansible all -m ping --list-hosts
    • 모듈 사이트
      • https://docs.ansible.com/ansible/2.9/modules/list_of_all_modules.html
    • ansible -i customized_invent.lst 10.2.11.121 -m shell -a "df -h" -k
      • 쉘을 통해 명령어를 실행할 수 있는데, 이 때 옵션을 붙인다면 더블 쿼테이션으로 묶어주어야 한다.
    • ansible all -m user -a "name=nsuser01" -k
      • Ansible Node에 유저를 추가할 수 있다.
    • ansible all -m shell -a "tail -n 1 /etc/passwd" -k
      • Node마다 passwd 파일의 뒤에서부터 한 줄 읽어오는 것이다.
    • state 종류
      • present : 설치
      • absent : 삭제
      • latest : 최신 버전 설치
      • build-dep : 패키지 빌드 종속성 설치 확인 (dependency)
    • ansible all -m user -a "name=nsuser01 state=absent" -k
      • state=absent 로 삭제한다.
      • 결과에 "changed"=true면 뭔가 변경에 성공한 것.
    • ansible all -m shell -a "tail -n 1 /etc/passwd" -k
      • 삭제가 되었는지 확인해본다.
    • 웹 서버
      • ansible all -m apt -a "name=apache2 state=present" -k
        • state=present로 설정해 웹 서버를 설치한다.
        • Ubuntu : apache2
        • CentOS : httpd
      • 노드의 IP 주소로 브라우저에서 접속
        • 주소창에 10.2.11.121~3 -> Apache2 Ubuntu Default Page
      • 인덱스 페이지 변경
        • apt install -y curl
        • curl httpd.apache.org -o index.html
        • ls
          • index.html을 받아온 것을 확인.
        • ansible all -m copy -a "src=index.html dest=/var/www/html/index.html" -k
          • 앤서블 서버로부터 각 노드들에게 파일을 일괄적으로 덮어쓰기(없다면 생성)
        • 다시 브라우저로 접속해보면 페이지가 바뀌어 있음.
      • 웹 서버 서비스 중지
        • ansible all -m service -a "name=apache2 state=stopped" -k
        • 접속해보면 연결할 수 없음.
        • 속성 종류
          • reloaded
          • restarted
          • running
          • started
          • stopped
      • 웹 서버 삭제
        • ansible all -m apt -a "name=apache2 state=absent" -k
  • ansible-playbook 모듈
    • 사전적 의미 : 각본, 계획, 전술
    • 시스템 정의서 - 자동으로 실행되는 코드
    • 멱등성 적용
      • ansible localhost -c local -m lineinfile -a "path=customized_invent.lst line=192.168.0.204"
      • 노드는 건드리지 않기에 -k 옵션이 필요없다.
    • yaml 파일을 이용한 nginx 배치 실행
      • yaml 파일 작성
        •  
      • 앤서블 서버에서 실행
        • vim nginx_install.yaml
          • VSC에서 작성한 파일 긁어서 넣기
        • ansible-playbook nginx_install.yaml -k
      • 일괄적으로 3개의 노드에 태스크별로 설치, 인덱스 페이지 변경, 실행까지 됨.

Vagrant

• Ansible은 Configuration, Orchestration 기능만 수행할 수 있지만 Vagrant를 통해 Bootstrapping까지 할 수 있다.
  • 가상 머신 생성 및 OS 설치가 가능
• 설치
  • 홈페이지에서 설치 파일 다운로드
  • 재부팅
  • cmd창 열고 vagrant init
    • Vagrantfile이 만들어지는데 이게 중요한 것.
• 실습
  • Windows cmd 접속
  • Vagrantfile 생성
    • :d
    • cd ansible
    • vagrant init
  • 플러그인 설치
    • vagrant plugin install vagrant-vbguest --plugin-version 0.21
  • Box = VM, Vagrant에서 Box Image를 제공한다.
    • https://app.vagrantup.com/boxes/search
    • 원하는 이미지명이 centos/7임을 확인하여 Ruby 기반으로 Vagrantfile을 작성한다.
    •  
  • cmd창에서 vagrant up
    • vagrant up --provider virtualbox
      • 어차피 디폴트가 버츄얼박스이긴 함.
      • 네트워크 인터페이스 선택
      • 꽤 오랜 시간 후 완료됨
  • 구동 상태 확인
    • vagrant status
      • running
  • ssh 접속
    • vagrant ssh
      • cat /vagrant/Vagrantfile
        • 작성한 파일 확인
      • ip a
        • IP 적용 확인
      • ansible --version
        • 앤서블 버전 확인

Role

• 디렉토리
  • defaults
    • 디폴트 변수를 가진다.
    • 우선순위 최하
  • files
    • 노드에 배포할 정적인 파일들이 위치
      • ex) 웹 페이지, 환경 설정 파일 등
  • handlers
    • 핸들러를 선언
  • meta
    • 롤에 대한 추가 정보
      • ex) 작성자 정보, 호환 버전 등
  • tasks (required)
    • playbook에서 사용되는 태스크들을 기입
  • templates
    • 템플릿, 진자2(index.j2)
  • vars
    • 변수들에 대한 정보를 모아둔다.
• 구성 방법
  • 수동 mkdir
  • ansible-galaxy
    • 자동적으로 롤 디렉토리를 만들 수 있다.
    • 또는 타인의 구성을 가져와 적용할 수 있다.
      • 예시
        • ansible-galaxy search --galaxy-tags nginx
        • https://galaxy.ansible.com/
        • ansible-galaxy install jdauphant.nginx

Source Codes

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :
  
Vagrant.configure("2") do |config|

  #==============#
  # CentOS nodes #
  #==============#
  
  #Ansible-Node01
  config.vm.define "ansible-node01" do |cfg|
    cfg.vm.box = "centos/7"
    cfg.vm.provider "virtualbox" do |vb|
      vb.name = "Ansible-Node01"
    end
    cfg.vm.host_name = "ansible-node01"
    cfg.vm.network "public_network", ip: "172.30.1.201"
    cfg.vm.network "forwarded_port", guest: 22, host: 60011, auto_correct: true, id: "ssh"
    cfg.vm.synced_folder ".", "/vagrant", disabled: true 
    cfg.vm.provision "shell", path: "bash_ssh_conf_4_CentOS.sh"
  end

  #==============#
  # Ubuntu nodes #
  #==============#
  
  #Ansible-Node04
  config.vm.define "ansible-node04" do |cfg|
    cfg.vm.box = "ubuntu/trusty64"
  cfg.vm.provider "virtualbox" do |vb|
    vb.name = "Ansible-Node04"
  end
  cfg.vm.host_name = "ansible-node04"
  cfg.vm.network "public_network", ip: "172.30.1.204"
  cfg.vm.network "forwarded_port", guest: 22, host: 60014, auto_correct: true, id: "ssh"
  cfg.vm.synced_folder ".", "/vagrant", disabled: true
 end
  
  #================#
  # Ansible Server #
  #================#

    config.vm.define "ansible-server" do |cfg|
    cfg.vm.box = "centos/7" # '='가 필수적으로 필요 
    cfg.vm.provider "virtualbox" do |vb|
      vb.name = "Ansible-Server" # '='가 필수적으로 필요 
    end
    cfg.vm.host_name = "ansible-server" # '='가 필수적으로 필요 
    cfg.vm.network "public_network", ip: "172.30.1.200"
    cfg.vm.network "forwarded_port", guest: 22, host: 60010, auto_correct: true, id: "ssh"
    cfg.vm.synced_folder ".", "/vagrant"
    cfg.vm.provision "shell", inline: "yum install epel-release -y"
    cfg.vm.provision "shell", inline: "yum install ansible -y"
	  cfg.vm.provision "file", source: "ansible_env_ready.yml", 
	    destination: "ansible_env_ready.yml"
	  cfg.vm.provision "shell", inline: "ansible-playbook ansible_env_ready.yml"

    # generate n input keys
    cfg.vm.provision "file", source: "auto_pass.yml", 
      destination: "auto_pass.yml"
    cfg.vm.provision "shell", inline: "ansible-playbook auto_pass.yml", privileged: false
    
    # facts
    cfg.vm.provision "file", source: "facts.yml", 
      destination: "facts.yml"
    cfg.vm.provision "file", source: "facts_collector.yml", 
      destination: "facts_collector.yml"

    # install nginx
    cfg.vm.provision "file", source: "CentOS.yml", 
      destination: "CentOS.yml"
    cfg.vm.provision "file", source: "Ubuntu.yml", 
      destination: "Ubuntu.yml"
    cfg.vm.provision "file", source: "nginx_install_w_template.yml", 
      destination: "nginx_install_w_template.yml"
    cfg.vm.provision "file", source: "index.j2", 
      destination: "index.j2"
    
    # remove nginx
    cfg.vm.provision "file", source: "CentOS_remo.yml", 
      destination: "CentOS_remo.yml"
    cfg.vm.provision "file", source: "Ubuntu_remo.yml", 
      destination: "Ubuntu_remo.yml"
    cfg.vm.provision "file", source: "nginx_remove_w_if.yml", 
      destination: "nginx_remove_w_if.yml"
    end
  end

ansible_env_ready.yml

---
- name: Setup for the Ansible's Environment
  hosts: localhost
  gather_facts: no
  
  tasks:
    - name: Add "/etc/ansible/hosts"
      blockinfile: 
        path: /etc/ansible/hosts
        block: |
          [nodes]
          172.30.1.201
          172.30.1.204
          
    - name: Create vim env's directories & files
      shell: "{{ item }}"
      with_items:
        - "mkdir -p /home/vagrant/.vim/autoload /home/vagrant/.vim/bundle"
        - "touch /home/vagrant/.vimrc"
        - "touch /home/vagrant/.bashrc"
      
    - name: Install vim-enhanced
      yum: 
        name: vim-enhanced
        state: present
        
    - name: Install git
      yum: 
        name: git
        state: present
        
    - name: Download pathogen.vim
      shell: "curl -fLo /home/vagrant/.vim/autoload/pathogen.vim
              https://tpo.pe/pathogen.vim"
      
    - name: Git clone vim-ansible-yaml
      git:
        repo: https://github.com/chase/vim-ansible-yaml.git
        dest: /home/vagrant/.vim/bundle/vim-ansible-yaml
        
    - name: Configure vimrc
      lineinfile: 
        path: /home/vagrant/.vimrc
        line: "{{ item }}"
      with_items:
        - "set number"
        - "execute pathogen#infect()"
        - "syntax on"

    - name: Configure Bashrc
      lineinfile:   
        path: /home/vagrant/.bashrc
        line: "{{ item }}"
      with_items:
        - "alias ans='ansible'"
        - "alias anp='ansible-playbook'"

auto_pass.yml

---
- name: Create authority between server and nodes
  hosts: nodes
  connection: local
  serial: 1
  gather_facts: no
  vars:
    ansible_password: vagrant

  tasks:
    - name: ssh-keyscan for known_hosts file
      command: /usr/bin/ssh-keyscan -t ecdsa {{ ansible_host }}
      register: keyscan

    - name: input key
      lineinfile:      
        path: ~/.ssh/known_hosts
        line: "{{ item }}"
        create: yes     
      with_items:
        - "{{ keyscan.stdout_lines }}"

    - name: ssh-keygen for authorized_keys file
      command: "ssh-keygen -b 2048 -t rsa -f ~/.ssh/id_rsa -q -N ''"
      ignore_errors: yes
      run_once: true

    - name: input key for each node
      connection: ssh
      authorized_key:
        user: vagrant
        state: present
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"

facts.yml

---
- name: print ipv4.address for nodes
  hosts: nodes
  #gather_facts: no

  tasks:
    - name: debug by msg
      debug:
        msg:
          - "eth0's ip {{ ansible_eth0.ipv4.address }}"
          - "eth1's ip {{ ansible_eth1.ipv4.address }}"

    - name: debug by var
      debug:
        var: "{{ item }}"
      with_items:
        - hostvars[inventory_hostname]['ansible_eth0']['ipv4']['address']
        - hostvars[inventory_hostname]['ansible_eth1']['ipv4']['address']

facts_collector.yml

---
- name: Collect facts for each node
  hosts: nodes

  tasks:
    - name: generate facts
      setup:
      register: facts

    - name: save facts
      local_action:
        module: copy
        content: "{{ facts | to_nice_json }}"
        dest: ./{{ ansible_hostname }}_facts_by_collector.txt

CentOS.yml

- name: install epel-release
  action: "{{ ansible_pkg_mgr }} name=epel-release state=latest"
- name: install nginx web server
  action: "{{ ansible_pkg_mgr }} name=nginx state=present"
- name: upload default index.html for web server
  get_url: url=https://www.nginx.com dest=/usr/share/nginx/html/ mode=0644
  notify:
    - restart nginx web server

Ubuntu.yml

- name: install nginx web server
  action: "{{ ansible_pkg_mgr }} name=nginx state=present update_cache=yes"
- name: upload default index.html for web server
  shell: "sudo curl -fLo /usr/share/nginx/html/index.html https://www.nginx.com/"
  notify:
    - restart nginx web server

nginx_install_w_template.yml

---
- name: Install nginx on the nodes
  hosts: nodes
  become: yes
  vars: 
    nu: "{{ groups.nodes | count }}"
    idx: "{{ groups.nodes.index(inventory_hostname)+1 | int }}"
    lnx_name: "{{ 'CentOS' if ansible_distribution == 'CentOS'
                   else 'Ubuntu' if ansible_distribution == 'Ubuntu'
                   else 'Just Linux' }}"
    
  tasks:
    - name: nginx for any linux
      include_tasks: "{{ lnx_name }}.yml"
      
    - name: create web page for each node
      template:
        src: index.j2
        dest: /usr/share/nginx/html/index.html
        mode: 0644
        backup: yes

  handlers:
    - name: restart nginx web server
      service: name=nginx state=restarted

index.j2

<!doctype html>
<!Create by ansible template at {{ ansible_date_time.iso8601 }}>
<html>
  <head>
    <title>Nginx Web Server</title>
  </head>
  <body>
    <p><font color=pink size=5>Welcome to Ansible world!</font></p>
    <p><font size=5>Here is Nginx Cluster <font color=red>{{ idx }}</font>/{{ nu }}</font></p>
  </body>
</html>

CentOS_remo.yml

- name: remove epel-release
  action: "{{ ansible_pkg_mgr }} name=epel-release state=absent"
- name: remove nginx web server
  action: "{{ ansible_pkg_mgr }} name=nginx state=absent"

Ubuntu_remo.yml

- name: remove nginx web server
  action: "{{ ansible_pkg_mgr }} name=nginx state=absent autoremove=yes"

nginx_remove_w_if.yml

---
- name: Remove nginx on the nodes
  hosts: nodes
  become: yes
  vars:
    lnx_name: "{{ 'CentOS' if ansible_distribution == 'CentOS'
                   else 'Ubuntu' if ansible_distribution == 'Ubuntu'
                   else 'Just Linux' }}"

  tasks:
    - name: nginx for any linux
      include_tasks: "{{ lnx_name }}_remo.yml"

네이버 클라우드 플랫폼 서비스 라인업

Server Types

서버 구축 방식

• VM
  • H/W 위에 HyperVisor 위에 복수 VM
• VDS
  • H/W 위에 HyperVisor 위에 단일 VM
• Bare Metal
  • H/W 위에 바로 OS

클라우드 환경에서 VM 간 간섭 현상에 대한 위험을 0으로 만들기 위해선 VDS 또는 Bare Metal 방식을 사용해야 한다.

Bare Metal Server

• 단독으로 사용할 수 있는 고성능 물리 서버를 클라우드 형태로 제공.
• 하이퍼바이저 없이 물리 서버 자체에 운영 체제를 설치.
• RAID 1+0, RAID 5 등 적합한 RAID 구성 방식 적용 가능.
• 단독 서버이기에 성능에 민감한 서비스의 안정적인 운영 가능.
• CentOS, ORACLE Linux와 Windows 제공.
• '내 서버 이미지', '스냅샷', '추가 스토리지' 기능 사용 불가.
• 서버 장애 시 Live Migration 불가

GPU Server

• 병렬 처리에 최적화된 GPU 서버의 고성능 컴퓨팅 파워를 제공.
• 딥 러닝을 위한 GPU 서버 팜으로 Classic 환경에선 NVIDIA P40, V100 사용.
• VPC 환경에선 NVIDIA T4, V100 사용.
• GRID 방식으로 공유 자원으로써 사용하지 않고 Pass Through를 적용하여 전용 리소스로써 제공.

서버 타입별 기능 비교표

Server Operations

Server Image / Snapshot / 유사 서버

Server Image : 서버 OS + 추가 볼륨에 대한 상태를 이미지로 뜨는 것이다. Classic 환경에선 서버가 셧다운된 상태에서만 가능하고, VPC 환경에선 러닝중이어도 가능하다. 부팅 디스크 타입, 서버 타입(사양) 변경 또는 리전 간 이미지 공유에 사용된다.

Snapshot : 볼륨에 대한 상태를 이미지로 저장한다. 디스크 타입 변경에 사용되며, 사이즈 변경은 불가하다. 볼륨 이미지 또한 리전 간 공유가 가능하다.

유사 서버 : 서버에 대한 스펙만 저장하는 것이다. 실제로 서버의 기능을 할 수 없다.

Init Script

서버 생성 시 최초 1회 실행되는 스크립트. 서버에 설치해야 하는 패키지나 초기 설정 내용을 스크립트로 선언하여 서버 초기화를 빠르고 편리하게 구성할 수 있다.
같은 용도의 서버를 여러 대 일괄로 생성하는 경우 잘 사용된다.

OS별 스크립트 사용
Linux : Python, Perl, Shell
Windows : Visual Basic

서버에서 /var/log/ncloud-init.log 경로로 접속하여 확인할 수 있다.

추가 스토리지 구성

OS 영역인 50GB에 추가로 더 큰 스토리지 용량이 필요할 경우 사용한다. 단일 서버당 최대 15개의 추가 스토리지를 구성할 수 있으며, 스토리지당 10GB~2TB까지 용량을 잡아줄 수 있다. Linux-LVM, Windows-동적 디스크 할당을 통해 여러 개의 디스크를 하나의 볼륨으로 묶음으로써 여러 개의 디스크를 하나의 볼륨인 것처럼 사용할 수 있다.
서버가 중지 상태이거나 대상 스토리지가 서버에서 unmount 되어 있는 상태일 때 서버에 연결된 스토리지를 Detach한 후 다른 서버로 Attach하여 옮길 수 있다.

서버 생성까지의 단계

1. VPC 생성
2. NACL 생성
3. Subnet 생성
4. ACG 생성
5. Server 생성

VPC

계정당 최대 3개의 VPC 생성 가능.

IP 주소 범위

• 10.0.0.0/8 : 10.0.0.0 ~ 10.255.255.255
• 172.16.0.0/12 : 172.16.0.0 ~ 172.31.255.255
• 192.168.0.0/16 : 192.168.0.0 ~ 192.179.255.255

Peering : VPC 간 연결을 위한 네트워크 구성. 다른 계정의 VPC와도 연결이 가능하다(로그인 ID, VPC ID, VPC 이름 입력 필요).

ACG / NACL

AWS의 Security Group과 NACL이라고 볼 수 있다. 외부에서 접속 시 NACL을 먼저 거친 후 서버 레벨에서 ACG가 검문한다.

VPC 환경에서는 서버, 서브넷에 적용된 ACG, NACL을 다른 ACG, NACL로 변경 가능하다.

Subnet

VPC당 최대 200개의 Subnet 생성 가능. 나머진 AWS의 Subnet과 같다.

Load Balancer

Target Group이라는 단위로 관리할 서버들을 묶는다. 동일한 VPC 내에 있는 서버들에 대해 생성 가능하다. 하나의 서버가 동시에 여러 타겟 그룹에 속할 수는 있지만 타겟 그룹을 다수의 로드 밸런서에 연결할 수는 없다. VPC 환경에서의 헬스 체크 주기는 디폴트 30초에 변경 가능이며, Classic 환경에선 디폴트 6초에 변경은 불가하다.

로드 밸런서의 종류

• Network Load Balancer
  • 고성능의 분산 처리 가능
  • Client IP가 그대로 로깅(LB가 브로커로서 관리하지 않고 서버에 Client IP가 찍힌다)
  • DSR(Direct Server Return)을 구현하여 서버에 부하 분산되어 도착한 트래픽에 대한 응답을 클라이언트단으로 보낼 때 LB를 거치지 않고 빠르게 서비스를 제공할 수 있음
  • Hash, RR 알고리즘만 제공
• Network Proxy Load Balancer
  • 프록시 방식의 통신을 제공하여 세션 유지가 필요한 TCP 기반 애플리케이션에 이용
  • SSL 인증 및 암호화 가능
  • 3가지 알고리즘 제공
• Application Load Balancer
  • HTTP/HTTPS 트래픽에 대한 처리
  • URL 기반 분기 가능
  • SSL 인증 및 암호화 가능
  • 3가지 알고리즘 제공

부하 처리 성능별 보장되는 CPS(초당 연결 수=분산 처리 횟수)

로드 밸런싱 알고리즘

• Round Robin : 골고루 각 서버에 트래픽을 1개씩 분배
• Least Connection : 클라이언트 연결이 가장 적은 서버에게 새 커넥션을 분배
• Source IP Hash : 클라이언트 IP에 대한 해시테이블을 통해 서버와 매핑하여 분배

Auto Scaling

오토 스케일링의 3가지 방식

• 스케줄링 : 사용자가 정의한 주기
• 모니터링 : 사용자가 설정한 메트릭(ex: CPU 사용량 80%로 5분 간 유지 시)
• 온디맨드 : 사용자의 요청

Auto Scaling에 설정해야 하는 부분
로드 밸런서에 바인딩되는 서버의 그룹이다.
Launch Configuration, Auto Scaling Group, Event Rule 3가지를 설정해주어야 한다.
Auto Scaling Group당 최대 30대의 서버를 묶을 수 있다.

CDN+ / Global CDN

CDN+는 국내 전용, GCDN은 국외 전용 CDN이다.
대규모 파일 배포나 이미지 서비스, 동영상 서비스 등 대규모로 트래픽이 발생하는 경우 캐싱을 통해 빠른 처리를 가능케 한다.

CDN 관련 용어

과정의 모든 내용이 아닌 일부 내용만 정리하였음.

ELB, CloudWatch, Auto Scaling

이 삼총사는 같이 움직인다.

하나의 예로

ELB

는 연결된 4개의 인스턴스들을 로드 밸런싱 및 모니터링(Health Check)하며 관리하고,

CloudWatch

는 ELB로부터 노티피케이션 받은 인스턴스 정보를 Auto Scaling에게 트리거링 해준다.

또한 전반적인 AWS 컴포넌트들에 대한 모니터링을 수행하며, Amazon S3 등 저장 공간에 연결하여 각종 모니터링에 대한 데이터를(주로 감사 용도로) 저장한다.

Auto Scaling

은 CPU 사용률(지표=Metric)이 5분(지정기간) 동안 50%(임계치)를 초과하는 경우 인스턴스를 하나 추가하는(Scale Out) 등의 정책에 따라 인스턴스 집합(Fleet)을 스케일링한다. 그러면 다시 ELB는 추가된 인스턴스까지 포함해 5개의 인스턴스를 로드 밸런싱하며 관리한다.

3가지 유형의 탄력성

시간 기반(예약) : 특정 시간대에 고정적으로 스케일링

볼륨 기반(동적) : CPU, I/O 등의 모니터링을 통한 스케일링

예측 기반 : ML을 통해 일일 및 주간 추세를 기반으로 향후 트래픽 예측을 통한 스케일링

Auto Scaling - 구매 옵션

오토 스케일링이 인스턴스를 생성할 때 그 인스턴스의 사양과 최소, 최대값을 지정해야 한다.

인스턴스의 사양은 Launch Configuration에서 지정한다.

Min, Max, Desired 값은 Auto Scaling Group에서 지정한다.

RDS Read Replica

관계형 데이터베이스의 읽기 전용 복제본이다.

읽기 작업이 매우 자주 일어나는 상황에서 트래픽의 경합을 막기 위해 여러 복제본으로 트래픽을 분산시킨다.

Amazon Aurora의 경우 최대 15개,

Oracle DB, MS-SQL Server, MySQL, MariaDB, PostgreSQL은 최대 5개까지 생성할 수 있다.

Scale Up/Down

RDS 인스턴스의 리소스 성능을 변경하는 작업이다.

micro부터 24xlarge에 이르는 모든 크기의 인스턴스 타입을 지원한다.

스토리지(EBS) 추가를 제외하면 변경 시에 발생하는 다운 타임은 감안해야 한다.

Amazon Aurora Serverless

Amazon Aurora 위에 MySQL이나 PostgreSQL을 얹어서 사용할 수 있다.

다운 타임 없이 RDS에 대한 수직적 확장 및 축소가 가능하며, 서버 인프라를 관리할 필요없이 애플리케이션의 필요에 따라 자동으로 시작 및 종료하고 용량을 축소 또는 확장하는 DB 클러스터이다.

Infra Automation with CloudFormation (인프라 자동화)

수동 프로세스는 확장, 버전 제어, 감사 내역, 일관성이 없기에 인프라 자동화가 필요하다. 

JSON/YAML로 작성한 템플릿을 CloudFormation 엔진에서 돌려 아키텍처 스택을 만든다.

IaC (Infra as a Code)

반복성, 재사용성 등의 장점이 있고, 템플릿의 내용만 고쳐 쉽게 인프라를 수정할 수 있다. 원래 스택에 대한 변경 집합을 검사한 후 CloudFormation으로 실행한다.

스택은 주로 위와 같이 계층별로 구분지어 따로 만든다. 각 스택을 알아보기 편하고 관리하기 쉽기 때문이다.

AWS Quick Start

AWS Solutions Architect가 구축한 모범 표준 AWS CloudFormation 템플릿.

보안 및 고가용성 모범 사례에 기초하여 만들어졌으며, 클릭 한 번으로 1시간 이내에 전체 아키텍처 생성이 가능하다.

템플릿이 적용할 환경에 정확히 부합하진 않을 것이기 때문에 스크립트로 커스터마이징하여 부트스트랩으로 배포해 사용할 수 있다.

Deployment Automation (배포 자동화)

보안 패치 등을 수많은 인스턴스(Fleet)에 적용하기 위해 Systems Manager를 이용한다.

일괄적으로 명령 실행, 패치 관리, 상태 관리, 세션 관리, 인벤토리 관리가 가능하다.

S/W Inventory : 설치될 제품 목록

AWS OpsWorks

개별 인스턴스 내부의 S/W 설정에 특화되어 있다. 스택에서 인스턴스 외부의 부분은 CloudFormation으로 구축하고, 인스턴스 내부의 상세한 설정은 OpsWorks로 구축하면 된다.

온프레미스에서 사용하던 Chef, Puppet를 사용하여 애플리케이션을 구성 관리할 수 있다.

AWS Elastic Beanstalk

AWS Elastic Beanstalk의 목표는 개발자가 기본 인프라에 대해 걱정할 필요없이 클라우드에 확장 가능한 웹 애플리케이션 및 서비스를 배포하고 유지 관리하도록 돕는 것이다. Elastic Beanstalk은 선택된 플랫폼에서 애플리케이션을 실행하는데 필요한 요소로 구성한다. 애플리케이션 스택을 설치 및 구성하기 위해 인스턴스에 로깅하는 것에 대해 걱정할 필요가 없다.

상황에 맞는 알맞은 솔루션을 선택하여 시스템을 구축한다.

AWS CloudFront

CDN(Contents Delivery Network)서비스란 말 그대로 콘텐츠 전송 네트워크로, 기본적인 멀티 티어 캐시와 광범위한 유연성으로 모든 전송 사례에 최적화되어 있다. 이 세션에선 AWS Edge Location의 CloudFront를 살펴본다.

무엇을 캐싱해야 하는가?

• 수집하려면 느리고 비싼 쿼리가 필요한 데이터
• 비교적 정적이고 자주 액세스하는 데이터(WORM : Amazon S3)
• 공개 거래되는 주식 가격처럼 일정 기간 동안 변화가 없을 수 있는 정보

캐싱 유형

• 클라이언트 - 웹 브라우저
• 서버 - 웹 서버
• 서버 - 역방향 프록시 캐시

원래 동적인 데이터는 캐싱의 대상이 아니지만 AWS CloudFront는 매우 빠른 속도의 AWS Backbone Network를 사용하기 때문에 동적인 부분도 캐싱이 가능은 하다.

콘텐츠 만료 방법

• TTL(Time To Live)
• 객체 이름 변경
• 객체 무효화

Amazon DynamoDB Acclerator (DAX)

DynamoDB와 마찬가지로 완전관리형 서비스이다. DynamoDB는 10밀리초 미만의 일관된 지연 시간을 제공하지만 DAX는 읽기 중심의 워크로드에 대한 초당 수백만 건의 요청에 대해서 마이크로초 단위의 응답 시간을 제공한다.

또한 DynamoDB와 API 호환이 되기 때문에 작동 중인 애플리케이션 코드를 변경할 필요가 없다. DAX 클러스터를 프로비저닝하고 DAX 클라이언트 SDK를 사용하여 DAX 클러스터에서 기존 DynamoDB API 호출을 가리키면, DAX가 나머지 모든 작업을 처리한다.

위와 같이 응답 시간이 중요한 게임 서버 등의 캐시로써 잘 사용된다.

Amazon ElastiCache

Amazon ElastiCache는 클라우드에서 인 메모리 캐시를 배포, 운영, 조정하는 데 사용되는 완전관리형 웹 서비스이다.

여러 개의 캐시 노드(EC2 Instance)들을 묶어 하나의 ElastiCache 클러스터로 관리한다.

ElastiCache는 Memcached와 Redis 두 가지의 유형이 있다.

아래의 다이어그램은 애플리케이션 서버, 캐시, 데이터베이스의 흐름도를 나타낸다.

Write Through (연속 쓰기)

애플리케이션으로부터 쓰기 작업을 요청받으면 Cache와 오리진 DB에 모두 데이터를 입력한다. 

Lazy Loading

애플리케이션으로부터 읽기 작업을 요청받았을 때 캐시에서 요청한 데이터가 Hit되면 그대로 받아오기만 하고, 만약 Miss되어 데이터베이스로부터 읽어왔다면 캐시에 그 값을 저장한다.

CloudFront, 캐시, ELB를 포함한 3-Tier 웹 애플리케이션 아키텍처 예시

Amazon SNS vs. Amazon SQS

Amazon SQS (Simple Queue Service)

아마존의 완전관리형 메시지 서비스이다. 마이크로 서비스 아키텍처를 위한 발신자와 수신자 간 버퍼의 역할을 담당한다. 하루에 수십억 건의 메시지를 처리할 수 있으며, Multi-AZ로 고가용성을 확보해 단일 리전 내에 모든 메시지 대기열과 메시지를 저장한다. 

SSE(Server Side Encryption)는 AWS KMS(Key Management Service)에서 관리하는 키를 사용하여 Amazon SQS 대기열의 메시지 콘텐츠를 보호한다. SSE는 Amazon SQS가 메시지를 수신하는 즉시 이를 암호화해 저장하며, 권한이 있는 사용자에게 전송할 메시지만 복호화한다.

메시지 하나 당 최대 256KB의 용량을 가지며, Producer - Consumer의 관계로 데이터를 처리할 인스턴스(소비자)가 큐(생산자)에 접근하여 능동적으로 메시지를 가져간다(Polling).

여러 애플리케이션에서 동시에 하나의 메시지를 처리하면 경합이 발생할 것이므로 가시성 제한 시간을 두어 하나의 애플리케이션에서만 처리할 수 있게 한다. 일반적으로 이 시간동안 메시지를 처리한 후 처리 완료한 메시지를 대기열에서 삭제한다. default는 30초이며, 0초~12시간 범위에서 설정 가능하다.

애플리케이션 예외 또는 트랜잭션 장애가 발생하면 Amazon SQS DLQ (Dead Letter Queue)로 리디렉션하여 나중에 다시 처리하게 할 수 있다.

Amazon SNS (Simple Notification Service)

Publisher - Topic - Subscriber의 구조로 퍼블리셔가 하나의 토픽으로 게시물을 게시하고(Pushing), 구독자는 게시물에 대한 알림을 받는 구조라고 볼 수 있다. 주로 애플리케이션에 대한 변경점에 이벤트를 걸어 특정 조건에서 트리거링 되게끔 설정한다. 예를 들어 Amazon S3에 새로운 데이터가 업로드 되었는데, 그 중 특정 컬럼값이 0이라면 푸시한다.

또한 당연히 Amazon SNS에 게시된 모든 메시지는 여러 서버와 데이터 센터에 걸쳐 저장된다.

Pushing : 흔히 푸시 알림이라고 하는 것이 이것이다. 

Amazon SNS의 구독 유형은 아래와 같다.

• Email/Email-JSON : 등록된 이메일 주소로 텍스트/JSON객체가 전송된다. 
• HTTP/HTTPS : 등록된 URL로 HTTP POST를 통해 알림이 전송된다.
• SMS 클라이언트 : 등록된 전화번호로 SMS 문자 메시지가 전송된다.
• Amazon SQS Queue : SQS 대기열에 알림 메시지가 추가된다(FIFO 대기열은 불가).
• AWS Lambda 함수 : 람다 함수에 메시지를 전송하여 후속적인 처리를 할 수 있다.

Amazon SQS에는 리콜 옵션이 없다. 메시지가 성공적으로 전송되면 이를 회수할 수 없다. 또한 주문 및 전달을 보장할 수 없다.

Amazon MQ (Message Queue)

Amazon MQ를 이용해 On-premise에서 사용하고 있는 Apache Active MQ와 연결된 하이브리드 시스템을 만들 수 있다.

또한 각 Amazon MQ를 서로 다른 AZ에 Primary와 Standby로 이중화하여 사용한다.

Micro Service (Container)

각 서비스들이 Tightly Coupled 되어 있는 Monolithic 방식은 한 애플리케이션이 Failure되면 전체 구조에 문제가 생기기 때문에 Loosely Coupled하게 구조화함으로써 독립적으로 만든다. 기본적으로 서비스들을 격리해놓고 서비스 간 통신은 REST API로 한다.

한 애플리케이션의 Code, Library, Dependency, Configuration 등을 패키지화 해서 하나의 컨테이너 이미지로 만들 수 있다. 컨테이너는 Hardware Level의 VM과는 달리 OS Level에서 만들고 운용되기 때문에 처리 속도가 더 빠르다(Docker Engine의 사용으로 GuestOS가 없음).

종속성, 라이브러리 등이 컨테이너 이미지 안에 전부 포함되어 있기 때문에 환경에 구애받지 않고 컨테이너를 돌릴 수 있다는 장점도 있다.

Amazon ECS(Elastic Container Service) / EKS(Elastic K8S Service)

Containers on EC2 Instances

위의 사진과 같은 구조로 볼 수 있다. 여러 개의 EC2 인스턴스들을 묶은 Amazon ECS Cluster 위에서 컨테이너가 실행되는 것이다.

ECS는 실행하는 노드 플릿을 유지 관리하고 확장한다. 또한 컨테이너의 배포를 모니터링하며, 클러스터의 전체 상태를 관리한다(인스턴스의 Auto Scaling 포함). Fargate 또는 EC2 두 가지 유형으로 시작 가능하다.

컨테이너 관리를 Docker가 하면 ECS, k8s가 하면 EKS이다. 

전체적인 ECS의 구조는 위와 같다. 마이크로 서비스로써 분리한 3가지의 서비스를 ALB를 통해 접근할 수 있다.

ECR(Registry)

컨테이너 이미지를 보관하는 레지스트리이다. ECS에서 컨테이너를 생성할 때 이곳을 참조해 이미지를 가져온다. 도커 허브와 비슷한 공간이라고 보면 된다.

Serverless

서버리스라고 해서 실제로 서버가 없는 것은 아니고 본인이 관리할 서버가 없다는 것이다.

서버리스는 개발자 등 인프라에 대한 지식이 충분하지 않은 사람이 앱과 서비스를 서버 위에서 실행할 수 있도록 AWS에서 서버를 자동적으로 관리해주는 서비스이다.

AWS Fargate - 완전 관리형 컨테이너 서비스

AWS Fargate는 완전관리형 컨테이너 서비스로써 모든 런타임 환경과 규모를 자동적으로 조정한다.

• 클러스터 프로비저닝 및 관리
• 런타임 환경 관리
• 규모 조정
• ECS 및 EKS 실행 가능

AWS Lambda

• 완전 관리형 컴퓨팅 서비스
• 상태 비저장 코드 실행
• Node.js, Java, Python, C#, Go, Ruby 지원
• 일정 또는 이벤트에 대한 응답으로 코드 실행=Kicking (ex: Amazon S3 버킷 또는 Amazon DynamoDB 테이블의 데이터 변경)
• 엣지에서 실행 가능(Node.js only)
• 구성이 아닌 애플리케이션에 집중
• 요청 시에만 컴퓨팅 리소스 사용
• 마이크로 서비스 아키텍처 구축
• 월별 100만 건 호출까지 무료
• 메모리 사이즈 범위 128MB~3GB를 64MB씩 46단계로 분류(CPU는 메모리에 맞춰 변경됨)되어 비용 발생
• 최대 15분 동안만 명령을 실행할 수 있기 때문에 하루종일 운용해야 하는 서비스의 경우엔 서버리스가 아닌 수동으로 EC2 인스턴스를 만들어 실행하는 편이 낫다.

AWS Lambda가 처리하는 작업

• 서버
• 용량 요구
• 배포
• 조정 및 내결함성
• OS 또는 언어 업데이트
• 지표 및 로깅

AWS Lambda 응용 아키텍처 시나리오

API Gateway

애플리케이션의 현관 역할을 하는 API를 생성할 수 있다.

최대 수십만 건의 동시 API 호출을 처리한다. Amazon EC2, AWS Lambda, 모든 웹 애플리케이션에서 실행되는 워크로드를 처리할 수 있다.

API Gateway를 사용함으로써 엔드포인트 노출 방지, DDoS 및 스크립트 주입 공격으로부터 보호된다.

API Gateway는 API 키를 생성하여 개발자에게 배포하고, 서명 버전 4를 이용해 API에 대한 액세스를 승인한다. 또한 AWS Lambda와 긴밀하게 통합된다.

API Gateway를 활용해 위와 같은 아키텍처를 가져갈 수 있다.

RTO/RPO - Backup

RTO (Recovery Time Objective)

장애가 발생했을 경우의 목표 복구 시간이다. 실제로 애플리케이션을 사용할 수 없는 시간을 의미한다.

RPO (Recovery Point Objective)

장애가 발생했을 경우 그 이전의 알려진 상태로의 롤백할 포인트를 의미한다. 쉽게 말해 백업 주기라고 할 수 있다.

AWS Backup

• 중앙 집중식 백업 관리
• 정책 기반 백업 솔루션
• 태그 기반 백업 정책
• 자동화된 백업 일정 관리

Recovery

위의 다이어그램은 인프라 복구 방법 중 파일럿 라이트 방식이다. 온프레미스에서 기본적으로 서버를 구동하고 있으며, AWS 측엔 실행 중이 아닌 준비된 인스턴스(Seed Light=불씨)들이 있고 Standby DB가 미러링 되어지고 있다.

온프레미스 측에서 Failure가 나면 몇 분 안으로 AWS의 인스턴스가 올라오고 서비스를 지속할 수 있게 된다. 

파일럿 라이트 밖에도 비용과 가용성이 높은 솔루션들이 존재한다.

농구인이라면 누구나 3점슛을 항상 정확하게 넣는 것을 꿈꿀 것이다. 돌파나 페인트존을 장악하는 플레이도 좋지만 수비수에게 외곽슛의 두려움을 줄 수 있다면 돌파나 플레이메이킹 또한 훨씬 쉽게 할 수 있다. 그리고 반코트 게임을 진행하게 된다면 3점슛의 효율은 매우 높아지기 때문에 없어서는 안 될 기본 스탯이라고 할 수 있다.

필자는 그런 3점슛이 너무 복불복 식으로 들어가곤 해서 어떻게 하면 일관된 정확성을 가질 수 있을까 연구했고, 나름 괜찮게 쓰고 있는 몇 가지 팁을 정확도, 비거리, 밸런스 3가지 파트로 나누어 공유하고자 한다.

필자는 마른 체형이며 근육량이 부족한 편이다. 본인이 슛 비거리의 부족 또는 체력 부족으로 인한 정확성 저하까지 이어지고 있다면 비거리 확보 파트까지, 힘과 체력은 충분하다면 정확도 파트와 밸런스 파트까지만 읽어도 괜찮을 것이다.

개인적인 생각을 담은 것 + 사람마다 맞는 방식이 다를 수 있으므로 반드시 이 방식이 맞는 것은 아니다. 참고글 정도로 생각해주기 바람.

또한 적은 근육으로의 극한의 효율성을 위해 슛폼의 낭만을 어느 정도 포기했기 때문에 멜신의 아름다운 슛폼과는 거리가 좀 있다. 이 글을 이해하고 그대로 따라한다면 트레이 영과 비슷한 슛폼이 될 것이다(슛폼은 개인 취향. 트레이 영 선수의 비하 목적 없음).

들어가기에 앞서 이 슛폼이 내게 끼친 영향력을 말하자면 예전엔 운이 아주 좋아야 연속으로 3점 3개를 넣는 정도였는데, 이젠 운이 전혀 아닌 공이 손을 떠날 때부터 들어갔다고 느끼는 슛으로 8연속 성공했다. 지금이라면 그 이상도 충분히 가능할 것이라고 생각한다.

정확도

필자가 정확도를 확보한 방식에 대해 설명한다.
핵심 키포인트는 슈팅의 변수를 제거하는 것이며, 여기서 중요한 포인트는 3가지이다.

공을 캐치한 순간부터 딜리버리를 마치는 순간까지

1. 공을 잡은 손가락의 위치 변화가 없어야 한다.
2. 오른팔의 각도가 지면으로부터 수직이어야 하며, 어깨 근육의 불필요한 사용이 없어야 한다.
3. 어시스트 핸드의 간섭이 생겨선 안 된다.

당신이 공을 캐치할 때 손바닥이 서로를 바라보게 잡은 후, 딜리버리를 하는 과정에서 공을 아예 한 번 고쳐 잡거나 손을 움직여서 어시스트 핸드가 옆에 위치하게끔 만든다면 주목하기 바란다.
필자도 이전엔 후자의 타입으로 공을 잡은 채 양손의 위치를 이동시키며 딜리버리를 하였는데, 이 방식은 상황에 따라 딜리버리를 마친 최종 그립이 매번 달라져 슛의 정확도가 떨어졌다. 그렇기 때문에 패스를 받거나 드리블을 멈추고 공을 잡은 상태에서 릴리즈 직전까지 그립에 변화가 생겨선 안 되는 것인데, 아래의 사진을 참고 바란다.

사람마다 편한 그립은 다 다르겠지만 필자는 슈팅 핸드의 엄지와 어시스트 핸드의 검지를 하나의 라인 상에 위치하도록 공을 잡은 채 그대로 딜리버리 했다. 그립에서 변수가 제거되자 3점슛의 정확도가 상당히 올랐다.

둘째로 오른팔의 각도와 어깨 근육에 대한 이야기다.
딜리버리를 마쳤을 때 공이 머리의 중앙에 있어야 한다 vs. 오른쪽에 있어야 한다로 논쟁이 있는데, 개인적으로 공을 오른쪽에 두고 슈팅할 때 훨씬 안정적으로 느껴졌다. 릴리즈까지 마친 후 팔로스루 상태에서 오른팔의 각도는 지면과 수직이게 된다. 그렇다는 건 딜리버리 전에 오른팔이 수직이 아니었다면 오른팔의 각도에 변화가 있었다는 이야기가 된다. 각도에 변화가 생긴다는 것은 릴리즈 중에 팔의 각도 변경을 위해 힘이 추가적으로 사용된다는 것이기에 이게 변수를 만드는 요소 중 하나였다는 것이다.
또한 공을 중앙으로 올리면 어깨를 약간 조이는 듯한 느낌이 드는 사람이 있을 것이다(나는 그렇다). 온전히 릴리즈에 집중해야 하는 근육을 이미 사용하고, 긴장시켜 놓으면 이것도 마찬가지로 상당한 변수가 되므로 필자는 딜리버리를 마친 시점에서 공을 오른쪽 뺨보다도 약간 옆에 위치시킨다.

셋째는 어시스트 핸드의 간섭인데, 사실 이 부분은 기본적인 부분임에도 필자는 못 지키고 있었다.
물론 카이리 어빙 등 몇몇 선수들은 'Thumb Flick'이라고 해서 릴리즈 시 어시스트 핸드의 엄지도 함께 사용하고 있지만 개인적으로 왼손은 힘이 부족하기에 매번 들어가는 힘이 달라져 변수를 만드는 요소라고 판단해서 아예 사용하지 않기로 했다. 이것도 그립이 상당히 중요하다고 할 수 있는데, 위의 사진과 같은 그립으로 이 부분까지 한 번에 잡았다.

비거리

위와 같은 방식으로 정확도를 확보했다면 사람에 따라 3점 또는 딥쓰리를 위한 비거리를 확보해야 한다.
필자의 경우 이마까지 딜리버리를 하면 처음 코트에 들어가서 힘을 90% 이상으로 사용했을 때 3점 거리가 맞았는데,
코트에서 계속 뛰다 보면 체력이 떨어져 나중엔 슛폼이 무너질 수가 있다. 그래서 체력이 어느 정도 떨어져도 일관된 슛폼을 가져가기 위해 힘을 60~70% 수준으로 사용하는 슛폼으로써 딜리버리 완료 시 공이 뺨 또는 턱의 높이까지만 올라오도록 만들었다. 추가적으로 공의 포물선도 너무 높지 않은 35~45˚ 정도로 잡아 힘을 가볍게 사용할 수 있게 했다(팔로스루 상태에서 팔의 각도와 같음). 이로써 오래 뛰더라도 항상 같은 슛폼으로 슈팅할 수 있게 된다.

밸런스

마지막으로 밸런스인데, 이 파트에선 스탠스와 스텝 두 가지를 언급한다. 반복해서 말하지만 이 부분도 변수를 없애는 것이 핵심이다.

슈팅 스탠스에는 크게 '11자 스탠스'와 '턴 스탠스'가 있는데 개인적으로는 각도를 어느 정도 틀어 턴 스탠스를 사용한다. 스탠스도 당연히 사람마다 맞는 방식이 있겠지만 앞서 소개한 오른쪽에 공을 두는 방식에 따라 턴 스탠스로 밸런스를 잡는 것을 추천한다. 추가로 케빈 듀란트의 슛폼에서 참고한 부분을 소개하자면 딜리버리 과정에서 무릎을 약간 오므리면 탄력이 더해져 더 편하게 비거리를 가져갈 수 있다.

슛을 하기 위해 공을 잡는 과정에서 밟는 스텝 또한 빼놓을 수 없는 매우 중요한 디테일이다. 캐치 앤 슛과 드리블에서 올라가는 슛 두 가지로 나누어 설명할 것인데, 오른손잡이 기준 항상 왼발을 피벗 풋으로 두는 것이 좋다는 점을 알고 들어간다.
먼저 캐치 앤 슛의 스텝이다.

• 리그 탑급의 캐치 앤 슈터 클레이 탐슨이 자주 사용하는 스텝으로 왼쪽 방향으로 3점 라인을 타고 돌면서 공을 받는 동시에 오른발(오른쪽 방향으로 돈다면 왼발)로 땅을 찍고 합스텝을 밟은 후 슛을 올라간다. 이 스텝은 스크린 플레이 이후에 사용하기 좋은 스텝이다.
• 오른쪽에서 오는 공을 받는 동시에 오른발도 땅을 찍어준 후 팔과 다리가 함께 몸으로 오며 딥→딜리버리→릴리즈를 가져간다. 패스가 오른쪽에서 와야 한다는(본인이 코트의 왼편에 있어야 한다는) 제약이 있지만 개인적으로 이 상황이 가장 편하여 이 루프가 실행되면 슈팅 성공률이 매우 높다. 패스를 받는데 수비가 너무 가까이 붙어 있다면 약간 변형해서 공을 받는 동시에 오른발로 잽스텝을 찔러준 후 다시 원위치를 밟고 올라가는 것도 좋다.

드리블 앤 슛의 스텝은 한 가지만 소개하겠다.

• 기본적으로 왼발이 피벗 풋이기에 원투 스텝을 밟을 때 왼→오 로 가져가는 것이 밸런스 잡기에 아주 좋다. 그 기본 스텝을 이용해 무궁무진한 패턴을 만들 수 있는데, 필자가 자주 사용하는 스텝 패턴을 하나만 소개하겠다. 먼저 왼손 드리블과 오른발을 동시에 밟으며 살짝 Float한다. 그리고 사뿐하게 오른발로 받으며 오→왼→오를 빠르게 밟아 슛으로 올라간다. 박자를 표현하자면 오↗오왼오 라고 할 수 있으며 공을 잡는 시점은 왼발 타이밍 정도이다. 주로 속공, 지공 관계없이 코트를 넘어오며 딥쓰리 또는 공간이 확보되어 있을 경우 일반 3점을 쏠 때 사용하는데 캐치 앤 슛의 두 번째 스텝과 함께 나만의 개꿀 스텝 투탑이다. 두 번째 오른발을 밟을 때 옆으로 밀어 사이드 스텝백으로 가져가기도 매우 용이하므로 꼭 연습해보기를 권장한다. 왼손잡이라면 반대로 밟으면 될 것이다.

혼자 수천수만 번 슛을 하면서 연구한 결과가 다른 사람에게도 도움이 되었으면 하는 마음으로 정리해보았다.
최근엔 NBA를 잘 보지 않아서 몰랐는데 연구를 거듭해 만들어 낸 최종 슛폼이 트레이 영의 슛폼과 상당히 유사하다는 점을 알게 되었다. 큰 차이점이라면 나의 슛폼은 왼팔이 많이 벌어지지 않고 비교적 얌전하다는 부분일 것 같다.

포스팅이 도움이 되었다면 하트와 댓글 부탁드립니다.

ENI (Elastic Network Interface)

탄력적 네트워크 인터페이스는 가상 네트워크 인터페이스이다.

동일한 가용역역 안에서 EC2 인스턴스 간에 이동할 수 있다.

새 인스턴스로 이동할 때 ENI는 다음을 유지한다.

• Private IP Address
• Elastic IP Address
• MAC Address

VGW(Virtual GW) & CGW(Customer GW)

VGW란 VPC마다 하나씩 존재할 수 있는 가상 프라이빗 게이트웨이이다.

VGW를 통해 다른 VPC와 통신하거나 고객의 On-premise 네트워크에 연결할 수 있다.

이 때 고객 쪽의 게이트웨이는 CGW라고 한다.

하나인 VGW에 여러 회선을 연결하여 사용할 수도 있으며, 연결 방식은 AWS Direct Connect와 VPN으로 나뉜다.

AWS Direct Connect (DX) vs. VPN

DX - 중요

DX는 AWS와 협약을 맺은 회사들로부터 제공되는 전용선을 통해 통신을 하는 것이다.

VPN 방식에 비해 Network Bandwidth가 확보되고, 보안적 측면에서의 이점도 확실히 가져갈 수 있다는 장점이 있다.

현재 DX Location을 제공하는 파트너는 LG U+, 세종텔레콤, Kinix, Dream Line, Console Connect 이렇게 5개가 있다.

가격대는 DX Partner, Network Bandwidth 등에 따라 천차만별이다.

VPN

통상적으로 쓰이는 방식이다.

인터넷 회선을 통해 통신한다. DX 대비 속도가 떨어지고 보안이 완전하지 않을 수 있다.

보안과 속도가 중요한 케이스에선 DX를 메인, VPN을 보조회선으로 사용하기도 한다.

VPC Peering

2개의 VPC를 직접적으로 연결해 IGW 또는 VGW를 통하지 않고도 서로 간에 통신할 수 있게하는 기능이다.

고가용성 연결로 단일 장애 지점이 없고 대역폭 병목 현상 또한 일어나지 않으며, 트래픽은 항상 글로벌 AWS 백본에서 유지된다. 추가로 서로 다른 리전 간의 연결 또한 가능하다.

2개의 VPC를 각각 Requester와 Accepter로 잡아 Peering Connection을 생성하고, 아래와 같이 각 VPC의 라우팅 테이블에서 서로를 알도록 라우팅해주면 된다.

이를 통해 아래와 같은 인프라를 가져가는 것이 가능하다.

다만 전이적인 Peering은 불가하기에 너무 많은 Peering Connection이 필요할 경우엔 사용하기 힘들다.

n/2 * n-1

연결할 VPC 수를 위 식에 대입하면 만들어야 하는 라우팅 테이블의 수가 나오는데 이 규모가 방대해지면 효율이 크게 떨어지기 때문에 Transit Gateway를 사용해야 한다.

Transit Gateway - 중요

이 방식은 피어링과 달리 VPC 또는 온프레미스 네트워크 간 직접 연결하지 않고 트랜짓 게이트웨이를 통해 연결한다.

하나의 트랜짓 게이트웨이로 최대 5000개의 연결을 관리할 수 있으며, 이 트랜짓 게이트웨이의 라우팅 테이블은 연결된 모든 네트워크를 알고 있다. 

트랜짓 게이트웨이를 통해 아래와 같은 시나리오를 만족할 수 있다.

VPC Endpoint

VPC의 엔드포인트는 다른 AWS 엔드포인트 서비스에 Private하게 연결할 수 있다.

VPC Peering과 비슷하지만, 엔드포인트는 애플리케이션/서비스에 적용한다는 점이 다르다.

엔드포인트에는 두 가지 유형이 있는데, 인터페이스 엔드포인트와 게이트웨이 엔드포인트이다.

Interface Endpoint

ENI와 연결된다. Amazon EC2 API, Amazon SNS, AWS Systems Manager 그리고 다른 AWS 계정에서 호스팅하는 엔드포인트 서비스 등이 여기 포함된다. 

ENI는 EC2 Instance에 달려있는 것이기 때문에 많은 엔드포인트 연결을 필요로 한다면 EC2 Instance 생성 시에 미리 많은 ENI를 생성해 두어야 할 것이다.

Gateway Endpoint

라우팅 테이블과 연결된다. Amazon S3, Amazon DynamoDB가 여기 포함된다.

ELB (Elastic Load Balancing)

연결된 인스턴스들에 대해 주기적으로 Health Check를 하며, 200번 코드를 반환하는 정상 작동 중인 인스턴스에만 요청을 전송한다. 

ELB의 종류

• ALB (Application) : 7계층에서 동작. HTTP 및 HTTPS 트래픽의 고급 로드 밸런싱. RR(Round Robin) 알고리즘을 통한 LB.
• NLB (Network) : 4계층에서 동작. TCP, UDP, TLS 트래픽의 로드 밸런싱. Hashing 알고리즘을 통한 LB.
• CLB (Classic) : 구세대 통합형 LB. EC2 Instance 신규 등록 작업 불가. 예전부터 쓰고 있는 고객들이 있기에 Deprecated 되지 않고 있음.

ELB 동작 원리

위 사진과 같이 2개의 ELB가 배치되며, Internet Facing ELB와 Internal ELB로 나뉜다.

1. Internet Facing에서 Public Subnet의 Instance들에게 Load Balancing을 해주면
2. 그 Instance들로부터 Internal ELB로 전달.
3. 이후 Private Subnet으로 다시 LB된다.

IAM (Identity and Access Management)

말 그대로 인증과 권한에 대한 관리.

IAM의 4개의 주요 Entity는 다음과 같다.

User : 단일 IAM 사용자이다.

User Group : 보통 사내 부서 별로 나뉘어진 개별 그룹이다.

Role(역할) : (모자처럼 생겼으니)모자를 쓰고 있는 Duration만큼 임시 자격 증명.

Policy : AWS Service에 대한 액세스만 제어. User, User Group, Role에 권한 부여. JSON 파일 형식이다.

Federation User

연동 자격 증명 관리. On-premise에서 관리하다가 AWS를 잠깐 관리하기 위해 On-premise의 자격 증명을 받고 AWS에서 권한을 연동해 간단하게 관리할 수 있음.

Root User

결제의 주체. 모든 AWS 서비스와 리소스에 대한 전체 액세스 권한을 갖는다.

Admin 생성 및 사용, Root 접근에 대한 자격 증명 잠금을 하는 것이 안전하다.

IAM 사용자 생성

기본적으로는 묵시적 Access Deny이다. 가장 강하게, 최우선으로 권한을 제한하려면 명시적으로 Deny한다.

AWS Management Console 또는 CLI에 대한 액세스는 명시적으로 부여되어야 한다.

리소스 기반 - 연결된 AWS 리소스 : Amazon S3, Amazon S3 Glacier 등

자격 증명 기반 - 연결된 IAM 보안 주체 : User, User Group, Role