Route 53

DNS 서비스에서 더 발전된 형태의 GSLB 형태의 서비스이다.
GSLB는 Global Server Load Balancing의 약자로서, 지역에 상관없이 부하를 줄여주는 기능을 제공한다.
주기적으로 연결된 서버들에 헬스 체크가 이루어지기 때문에, 기존 DNS 방식과는 달리 다운된 서버로 사용자가 연결되지 않게 한다.

DNS

• naver.com과 같은 문자열 주소를 192.168.0.1과 같은 IPv4로의 주소 변환이 필요하고, 이를 DNS 서비스라 부름
• DNS서버에는 도메인 주소와 IP주소가 서로 맵핑된다.
• 하나의 행을 레코드라고 부르며, 저장되는 타입에 따라, A 레코드와 CNAME으로 구분

Record

• A 레코드 : 도메인 주소와 서버의 IP 주소를직접 맵핑 (naver.com - 192.168.0.1)
  • 한 번의 요청으로 바로 IP 주소를 알 수 있음
  • IP 주소가 자주 바뀌는 경우 번거로움
• CNAME : 도메인 주소를 또 다른 도메인 주소로 맵핑 (post.blog.co.kr - postapi.blog.co.kr)
  • IP 주소가 자주 바뀌어도 유연하게 대응 가능
  • 실제 IP 주소를 얻을 때까지 여러 번 DNS 정보를 요청하며, 성능 저하의 가능성 존재

라우팅 정책

아래와 같은 정책 등을 통해 SLA 100%의 서비스를 제공하는 것이 Route 53이다.

1. 지연시간 기반 : 각 리전에 대한 latency 정보를 가지고 있어서, 고객 기준으로 가장 latency가 작은 서버와 연결
2. 가중치 기반 : 각 서버로 가는 트래픽의 비율을 조정하여, 특정 서버로 연결될 확률을 조정
3. 지역 기반 : 유저의 지역 정보를 기반으로 가까운 지역의 서버로 연결

Route 53 이 정상적인 레코드를 선택하는 방식

1. 라우팅 정책과 레코드에 대해 지정한 값을 기반으로 선택
2. Route 53이 레코드가 정상이라 확인한 경우
   • 상태 확인이 연결된 비별칭 레코드
   • Evaluate Target Health (대상 상태 평가)가 예로 설정된 별칭 레코드
3. 레코드가 정상인 경우 IP주소와 같이 해당되는 값으로 쿼리에 응답 / 레코드가 비정상인 경우 다른 레코드 선택하고 정상 레코드를 찾을 때까지 반복

S3 Bucket 및 객체에 대한 액세스 제어

• IAM 정책
• 액세스 제어 목록 (ACL)
• 버킷 정책

Storage Class

• Standard (액세스 주기가 짧다)

  • 자주 액세스하기 때문에, 비용은 높지만, 데이터 불러오는 속도는 빠르다

• Infrequent Access

• Glacier (액세스 주기가 길다)

  • 저장 비용이 가장 낮지만, deep archive된 만큼 데이터 불러오는 시간, 비용 크다

• 액세스 패턴이 파악되었을 때 -> 수명 주기 규칙 설정

• 액세스 패턴이 파악이 어려울 때 -> S3 Intelligent Tiering

Storage Gateway

• S3가 File System 기반이 아닌 Object 기반이며, REST/HTTP 기반 통신이기 때문에 속도/사용성에서 불편함 존재
  • iSCSI 방식을 지원해주는 것이 Storage Gateway
    • 대부분의 백업 솔루션이 iSCSI 방식을 지원하기 떄문에, 기존 온프레미스 환경의 백업 솔루션을 사용하면서
      데이터 저장만 S3에 할 수 있음 (S3의 안정성과 확장성이라는 장점만 가져올 수 있음)
  • 온프레미스 환경에 S3을 쉽게 Integration 할 수 있게 함

Storage Gateway 구성

• S3를 iSCSI 방식으로 처리하기 위한 appliance를 VM에 설치해야 한다.

Storage Gateway 구성 타입

1. Gateway-Cached Volume
   
   • 데이터 저장은 S3에 하되, 자주 access하는 데이터는 appliance의 로컬 디스크에 cache 형태로 유지
   • S3의 네트워크 latency 제약을 cache를 통해 해결
   • 전체 파일 사이즈의 20% 이상 크기를 cache용 Volume으로 설정
   • Upload Buffer용 Volume(S3에 업로드 이전에 데이터를 잠깐 저장하는 용도)도 필요함.
     • 이후 SSL로 데이터를 암호화하여 업로드 수행
   • I/O가 빈번한 메인 스토리지로서는 용도 부적합
2. Gateway-Stored Volume
   
   • 데이터 저장을 appliance 내 local storage(Local IDC)에 저장하고, 비동기적으로 S3에 스냅샷 형태로 백업하는 방식
   • Gateway-Cached 방식보다 빠른 데이터 access를 원할 때 사용
3. Gateway-VTL Volume
   
   • Tape 방식 백업을 지원하는 솔루션에서 VTL(Virtual Tape Library) 형태의 인터페이스를 제공하여, S3에 저장하고, 이를 장기 보관할 수 있도록 Glacier로 아카이빙할 수 있도록 하는 방식

VPC

사용자 지정된 가상의 네트워크 환경이다. 논리적으로 격리되어 있는 공간이다.
리전을 선택하고, 원하는 IP range를 가장 먼저 설정한다.
가용영역 단위로 서브넷을 생성하고, 서브넷의 목적에 따라 라우팅 테이블과 연결한다.

서브넷

서브넷의 종류에는 크게 Public Subnet과 Private Subnet이 있다.

• Public Subnet : Internet Gateway와 연결된 서브넷
• Priavate Subdnet : Internet Gateway와 연결되지 않은 서브넷. 펌웨어 패치 등을 위해 NAT Gateway와 연결되어 있다.

CIDR

서브넷 마스크의크기는 /16 ~ /28 사이이다.

• /16 : 16bit의 CIDR을 사용하면 B클래스와 동일하게 네트워크 할당 (16 비트 네트워크 아이디 + 16비트 호스트 아이디 => 2^16 == 65536개 IP range 사용 가능)
• /24 : 16bit 네트워크 아이디 + 8비트 서브넷 아이디 + 8비트 호스트 아이디 => 2^8 == 251개 (나머지 5개는 예약 IP)의 IP range 사용 가능

NACL & Security Group

• NACL (Network aces control list)
  • 서브넷으로 들어오려는 모든 인터넷 패킷은 NACL을 거치고, 패킷의 permission을 판단
  • Stateless (인바운드, 아웃바운드 주소/포트를 모두 선언해야 힘)
• Security Group
  • 같은 서브넷 내에서, 허용되는 IP를 제외하고 block
  • Stateful (인바인드가 허용이면, 아웃바운드는 자동으로 허용)

고가용성

• 두 번째 서브넷을 만들고, Auto Scaling을 사용해 새 리소스가 두 번째 서브넷으로 자동 시작되게 할 수 있음
• ALB는 서브넷의 엔드 포인트 간 로드를 분산할 수 있음 (A/B 테스트 및 블루/그린 배포 가능)
• 별도의 가용 영역(AZ)에 두 번째 서브넷을 유지함으로써, 한 AZ의 리소스를 사용할 수 없더라도 다른 AZ에서 사용 가능 (다중 AZ)
• 새 서브넷에서 라우팅 테이블을 따로 생성하지 않고, 이전에 생성한 라우팅 테이블과 연결
• ELB는 연결된 리소스에 상태 체크를 하여 장애 조치를 처리함

3-Tier VPC

Single Tier VPC는 모든 것을 하나의 서브넷에 넣기 떄문에 보안에 취약 (개인 블로그나 웹 사이트 등의 애플리케이션의 경우에는 비용 효율적일 수 있다.)

• NAT, ELB (Public Subnet) : 들어오는 트래픽 (ALB), 나가는 트래픽(NAT)

  • 가장 적게 IP가 필요 (ex> /22)

• App (Private Subnet)

  • 가장 많은 IP가 필요 (ex> /20)

• Data (Private Subnet)

  • 퍼블릭보다는 많이 필요하지만, App에 비해서는 적게 (ex> /21)

• 3티어 설계에 적합한 트래픽 패턴 - IGW -> ALB -> App -> Data -> App -> NAT -> IGW

• enableDnsHostnames

  • PC에서 시작된 인스턴스가 퍼블릭 DNS 호스트 이름을 가져오는지 여부
  • true인 경우 VPC의 인스턴스는 퍼블릭 DNS 호스트 이름을 갖지만, enableDnsSupport가 true인 경우에만 가능

• enableDnsSupport

  • VPC에 대해 DNS 확인이 지원되는지 여부
  • false이면 퍼블릭 DNS 호스트 이름을 IP주소로 확인하는 DNS 서버가 활성화되지 않음
  • true이면 Amazon 제공 DNS 서버에 대한 쿼리와 예약된 IP주소에 대한 쿼리가 성공

VPC Peering

• 프라이빗 IPv4 또는 IPv6 주소를 사용하여 두 VPC 간 트래픽을 라우팅하기 위한 VPC 간의 네트워킹 연결
• 온프레임과 연결시 모든 VPC에 VPN Connection을 해주어야 하는 번거로움
• VPC 당 최대 VPC Peering 가능 개수 : 125개
• 대역폭 제한 없음
  • 대역폭 제한이 문제가 된다면 VPC Peering 사용

Transit Gateway

• VPC와 온프레미스 네트워크를 단일 게이트웨이에 연결할 수 있도록 해주는 서비스
• 여러 VPC를 한번에 연결할 수 있게 함 + VPN Connection의 개수도 줄어듦
• 대역폭 제한 : 50 Gbps
• Transit Gateway당 VPC 최대 연결 개수 : 5000개
  • VPC 1개당 125개가 넘는 VPC Peering이 필요하다면, Transit Gateway 사용
  • 단순한 구조이지만, VPC Peering 보다 많은 비용 청구

온프레미스와 VPC 연결

VPN

• IPSec 네트워크 프로토콜 기반 VPN 연결
• VPN Tunnels은 기본적으로 이중화(되어 있고, TLS 통신이기 때문에 안전하게 통신 가능
• 인터넷 기반이기 때문에 성능, 품질이 전용선보다는 떨어지고, 지연이 생길 수 있다. (Bandwidth와 Latency가 가변적)
• AWS 상에 VPN을 연결하기 위한 Virtual Private Gateway(VGW)가 만들어지고, 해당 VGW와 온프레미스의 CGW(Customer Gateway)가 통신

Direct Connect

• VPN처럼 AWS와 직접 연결하지 않고, 중간에 AWS와 연결된 DX Location이 있어, 해당 DX Location 까지만 전용회선을 구축하면 되는 형태
  • 이후 DX Location 내 고객/파트너의 상면에 고객의 라우터를 설치, AWS Cage에 있는 AWS의 라우터와 연결한다. 이 작업을 Cross Connect라고 부름
• DX Location은 국내에서 가산의 KNIX, 평촌의 LG U+가 있다.
• 전용선을 사용하기 때문에 Bandwidth와 Latency가 일관적
• 이중화 방법 (반기에 한번 씩 Direct Connect의 정기 점검이 있어 고가용성 보장을 위해 이중화가 필요)
  1. Direct Connect + VPN 백업
     • 라우팅의 우선 순위는 무조건 VPN < DX
     • DX에 문제가 발생할 때 VPN으로 Failover가 되는 구성
     • 이중화 방법 중 가장 비용이 싼 방법
     • 즉, Direct Connect는 active 상태, VPN은 failover를 위해 standby 상태로 존재한다.
  2. DX Location 내에 inter-connection을 2개 설정하는 방법
  3. LAG (Link Aggregation Group) : 전용선의 최대 Bandwidth가 10Gbps까지이기 때문에, 이것을 4개 묶어 40Gbps까지 높인 방법
  4. DX Location과 전용선을 모두 2개씩 구축하는 방법 (가장 비용이 비쌈, 주로 금융권에서 사용)

Direct Connect의 active/standby 우선순위

대부분의 고객들은 일관적인 트래픽의 flow를 위해 active/standby 방식을 선호하며, BGP parameter를 통해 이것을 조절할 수 있다.

1. global적으로 longest prefix(CIDR가 더 긺)가 우선순위를 가진다.
2. AWS to On-Premise 트래픽 : AS prepending 파라미터를 통해 보다 적은 AS-PATH를 가지는 회선이 우선순위 (61000 > 61000, 61000)
3. On-Premise to AWS 트래픽 : BGP의 Local Preference 파라미터를 통해 우선순위가 높은 회선을 사용 (7300 > 7100)

따라서 동일한 회선이 항상 사용되도록 BGP parameter를 조정하는 것이 필요

Reference

• VPC Peering과 Transit Gateway 어떻게 다를까
• AWS Summit Seoul 2016 - AWS Direct Connect 및 VPN을 이용한 클라우드 아키텍쳐 설계 (Steve Seymour, AWS)
• KINX와 함께 하는 AWS Direct Connect 도입 - 남시우 매니저(KINX)
• 실전! AWS 하이브리드 네트워킹 (AWS Direct Connect 및 VPN 데모 세션) - 강동환, AWS SA:: AWS Summit Online Korea 2020

AWS IAM

• console 기반 작업 -> Script 기반 -> 프로비저닝 엔진 (CloudFornmation, Terraform) -> DOM (CDK)

  • 어떤 방식을 사용하든 API로 이루어진다.

• AWS에서 API 인증

  • AWS 자격 증명 = Access Key + 비밀 KEY (HMAC) (+ 임시는 Session Token)
  • 요청 내용과 비교하면 서명값 확인 -> 타임 스탬프 확인 -> 권한 판단 -> 허용 여부 판단

• 데이터, 어플리케이션 (클라우드 위의 보안)은 고객이 보안을 책임 (데이터 + IAM)

• IAM : AWS 전체의 권한 통제 시스템 (Identity and Access Management)

  • Identity : AWS로 요청할 수 있는 보안 주체(principal)을 만들어줌
  • Access Management : 누가 어떤 리소스에 대해 어떠 일을 할 수 있는 권한을 가지는지 정의

• Access Advisor를 통해 일정 기간동안 접근하지 않은 서비스에 대해 검사 가능 -> 이후 권한 회수할 것이 권장됨

Identity

• Root User 는 보안상 취약(권한 조정할 수 없는 슈퍼 유저), 따라서 IAM User, Role을 사용해야 함
  • IAM 사용자 : 로그인할 수 있는 보안 주체로 사용되기도 함 (장기 Credential을 이용해 서비스에 접근하는 보안 주체)
  • IAM Role
    • IAM 사용자가 장기 Credential 사용하기 때문에, 자격증명이 영구지속되기 때문에 서버 안에서 사용하든지, 하드코딩하기에는 위험
    • Role은 자동으로 로테이션 되는 임시 Credential 사용 (키값에 더해 일정 시간이 지나면 만료되는 Token 존재)
    • API적인 접근 / 외부 사용자(외부에 존재하는 보안주체)를 SAML, OpenIDC을 이용해 Role과 연계

Access Management

• AWS에서의 인가

• 디폴트가 Deny, 명시적 allow < 명시적 deny

• AND 조건으로 권한 인가

• Effect : allow or deny

• action : 어떤 행위를?

• Resource : 어떤 객체에 대해?

• Condition : 어떤 조건에서?

{
    "Effect": "Allow",
    "Action": "dynamodb:GetItem",
    "Resource": [
        "arn:aws:dynamodb:us-east-2:1111222233333:table/MyTable"
    ],
    "Condition": {
        "IpAddress": {
            "aws:SourceIp": "1.1.1.1"
        },
    }
}

IAM 정책 종류

• Identity-based : IAM User, Role (요청하는 보안 주체에게 연결)

• Resource-based : 자원에 할당 (요청을 받는 리소스에 연결) (Principal이라는 보안주체 속성이 추가)

• Permission Boundary : 권한의 최대치 규정

• SCP : 멀티 어카운트

• Session, ACL, Endpoint

• 동일 어카운트 환경에서 Identity, Resource 충돌 -> 합집합 (한쪽에만 allow 라면, 다른 쪽도 요청 허용)

• 크로스 어카운트 환경에서는 교집합 (한쪽에만 allow 라면, 다른 쪽은 요청 거부)

AWS 계정 활동 모니터링 및 감사

• AWS CloudTrail : 모든 API 활동 기록을 확인 가능, 문제가 발생했을 때 트러블 슈팅하기 위함
• AWS IAM Access analyzer : 외부 엔티티와 공유되는 리소스를 식별
• Amazon GuardDuty : CloudTrail, DNS로그, VPC Flow로그를 기반으로 해킹시도나 보안 위협을 탐지
• AWS Security Hub : 다양한 AWS 보안 서비스를 통합하여 보여주는 통합 대시보드 서비스

ABAC

• Role기반(RBAC)의 문제점 : 역할이 많거나 서비스 확장
  • ABAC : 태그를 이용하여 접근 제어
    • ARN 기반 정적 권한관리가 아닌, 보안 주체의 태그와 리소스의 태그를 비교하여, 동적 권한관리

완전 관리형 데이터베이스

• 고객은 스키마 설계, 쿼리 작성, 쿼리 최적화에만 신경

• AWS에서 백업, 복구, 보안, 스케일링, 모니터링 등 모두 지원

• MySQL, PostgreSQL, MariaDB 등 오픈소스DB 지원

  • 상용 DB보다 성능, 가용성 안 좋다

• 이를 해결하기 위해 Amazon Aurora 출시

AWS DB 종류

• 관계형 : RDS, Aurora (ACID)
• Key-value : DynamoDB (높은 처리량, 낮은 지연)
  • Aurora와는 달리 서버리스
  • 아이템(항목) (== RDB의 row)
  • Attributes (속성) (== RDB의 column)
    • 모든 아이템들이 동일한 속성을 가지지 않아도 된다
    • 테이블이 생성된 이후에도 원하는 아이템에 대해서 속성을 추가할 수 있다.
  • 파티션키 지정 (데이터 분산이 잘 되도록)
  • 조회를 빠르게하기 위해 소트키를 옵션으로 지정
• Document : DocumentDB
• In-memory : ElastiCache (마이크로 초단위 레이턴시, 애플리케이션에서 바로 접근 가능한 캐시 구조)
• GraphQL : Neptune
• Time-series : Timestream (시계열 데이터)
• Ledger : QLDB (블록체인)
• Wide column : Keyspaces (아파치 카산드라 호환)

OLAP vs OLTP

• OLAP (OnLine Analytical Processing) : 온라인 분석 처리
  • 데이터 웨어하우스의 데이터를 전략적인 정보로 변환시키는 역할. 기본 접근, 조회, 계산, 시계열, 복잡한 모델링
• OLTP (OnLine Transaction Processing) : 온라인 트랜잭션 처리
  • 여러 이용자가 실시간으로 데이터 베이스의 데이터 갱신, 조회하는 작업을 처리하는 방식. 주로 금융 전산 관련

DR 구성

• mirroring 상태로 active/active로 두면 동기화 문제는 없지만 비용 높음
• Hot / Cold로 나눠서 생각할 수 있음
  • Hot : 데이터만 이중화, 네트워크는 이중화 X
  • Cold : 수동 작업

DevOps

• 유연함을 위한 작은 단위로 나눔 (MSA, 2 피자팀)

  • 유닛을 가능한 작게, 기능 단위가 아니라 Sacling(확장) 단위 기반으로 분리
  • 각각의 서비스를 별도로 운영하여, 각각 다른 라이프사이클로 돌게 함
  • 투- 피자팀 : 12~15명 정도

• 모든 것을 자동화

  • 개발, 테스팅 모두 자동화

• 애플리케이션 아키텍쳐적인 변화가 중요하다!!

• 표준 도구 사용

• 프로세스 표준화(템플릿)

• IaC

• 아마존도 초기에 모놀리스 서비스였음 (운영 파이프 라인도 1개만 있었음, 모든 개발자가 한 사이클이 지날 때까지 기다릴 수 밖에 없는)

  • 따라서 운영 파이프라인을 서비스 단위로 나누게 되었음

DevOps 도구

• CodeCommit : 소스를 저장 관리

• CodeBuild (빌드, 테스트)

• CodeDeploy (배포)

• AWS X-Ray, AWS CloudWatch (모니터링)

• Cloud9

• 디펜던시, 패키징, 빌드 검증 (중간)

• 베타(성능), 감마(프로덕션 레디 검증), 프로덕션 (프로덕션)

AWS 운영 책임 모델

• 서버리스 (Lambda, Fargate, S3, Aurora, DynamoDB)

• 컨테이너 (EKS, ECR, ECS)

• AWS Cloud Development Kit(CDK) : VPC 생성하는 코드가 2줄 내지, IaC로 코드로 관리할 수 있는 것

  • CloudFormation 템플릿화, DevOps가 CloudFormation으로 구현되는 것이다
  • CloudFormation의 러닝 커브를 줄여 준다.

• 블루-그린 배포

  • 블루 : 기존 버전
  • 그린 : 새 버전
  • 트래픽을 일정 수준 이상 전환해보고 문제 없이 작동되면 그린 환경으로 배포, 이후 블루 환경 제거

• DevOps Guru는 머신러닝 기반으로, 애플리케이션 가용성을 개선

  • 이상을 감지하고, 노이즈 제거
  • 연관관계를 몰라서 의미를 찾기 힘든 경우를 찾아줌
  • CDK 혹은 CloudFormation 단위로 적용 가능