확률과 대칭성

Introduction

수학 문제를 풀 때 유용한 전략 중 하나는 문제에 숨어있는 대칭성을 찾아서 이를 활용하는 것이다.

어떤 여행자가 강의 한쪽 편에서 맞은 편으로 가고자 한다. 밤새 심한 폭풍이 몰아쳐서 각 다리가 독립적으로 50%의 확률로 끊어졌을 수 있다. 이런 상황에서 여행자가 여전히 맞은 편으로 갈 수 있는 확률은 얼마인가?

https://farm6.staticflickr.com/5598/15430136565_bfb2f25682.jpg

제일 먼저 떠오르는 것은 각 경우를 모두 세보는 것이다. 다리가 무너지지 않은 것을 1, 무너진 것을 0으로 표현하면 총 32가지의 경우가 있다. 이를 잘 세보면 총 16가지 경우에 다리를 건널 수 있는 것을 쉽게 확인할 수 있다. 그러므로 여행자가 강을 건널 수 있을 확률은 50%이다.

조금 다른 접근 방법으로 문제의 대칭성을 활용할 수 있다.

보트가 강을 따라서 지나가는 것을 상상해보자. 이 보트는 다리가 무너졌다면 거길 지나갈 수 있다고 가정하자. 이렇게 문제를 생각해보면 이는 위의 여행자 문제와 같은 구조를 지녔음을 알 수 있다. 다만 다리가 무너진 경우에만 지나갈 수 있는 것으로 문제가 변했을 뿐이다.

즉, 여행자가 다리를 건널 수 있는 확률과 보트가 강을 지나갈 수 있는 확률이 같다.

$$p(여행자) = p(보트)$$

또한 여행자가 다리를 건널 수 있다면 보트는 지날 수 없고, 그 반대의 경우도 성립한다.

$$p(여행자) = 1 – p(보트)$$

이를 바탕으로 여행자가 강을 건널 수 있는 확률은 50%임을 쉽게 확인할 수 있다.

Principle of Symmetry

위에서 본 것처럼 확률 문제에서 대칭성을 활용하여 문제에 쉽게 접근할 수 있는 경우가 종종 있다. 가장 대표적인 것이 선 위에 점이 떨어질 때의 대칭성을 활용하는 것이다.

어떤 구간에 \(n \)개의 점이 임의로 떨어지면, 생성되는 \( n+1 \) 개의 작은 구간은 평균적으로 같은 분포를 갖게 된다.

The First Ace

Q: 트럼프를 섞어서 뒷면이 보이도록 순서대로 한 장씩 나열하자. 이때, 처음으로 에이스를 만날 때까지 평균적으로 몇 장의 카드를 뒤집어야 할까?

총 카드가 52장인데, 그중 에이스가 네 장이므로 이를 제외하면 총 48장의 카드가 있다. 이를 하나의 구간으로 생각하면 에이스 네 장은 이를 총 다섯 개의 구간으로 나누게 된다. 대칭성의 법칙을 적용해보면 각 구간은 평균적으로 같은 분포를 가지므로 하나의 구간은 평균적으로 \(\frac{1}{5} \times 48\)의 길이를 갖게 된다. 이는 9.6이고 에이스를 뒤집기 위해 한 번 더 뒤집어야 하므로 평균적으로 10.6장의 카드를 뒤집어야 한다.

The Little End of the Stick

Q: 막대기 하나를 임의의 점을 잡아서 두 토막을 낸다. 작은 조각의 평균 크기는 얼마일까?

임의의 위치를 하나 정하는 것은 막대기 위에 점이 하나 떨어지는 것으로 생각할 수 있다. 점이 떨어지는 곳은 왼쪽 절반 혹은 오른쪽 절반으로 각 위치에 떨어질 확률은 50%로 같다. 만약 왼쪽 절반에 점이 떨어졌다면, 대칭성의 법칙에 의해 점이 구간을 절반으로 나누므로 전체 막대기의 절반의 절반이 작은 조각의 크기가 된다. 오른쪽 절반도 같은 논리로 계산할 수 있다. 그러므로 평균적으로 작은 조각의 크기는 막대기 길이의 \(\frac{1}{4}\)이다.

German Tank Problem

Q: 주축군에서 탱크를 만들면 각각의 탱크에 일련번호를 부여한다. 이는 만들어진 순서에 따라 1부터 순서대로 매겨진다. 어느 날 연합군이 60번의 일련번호가 붙여진 탱크를 포획했다. 주축군은 총 몇 대의 탱크를 만들었을까? 연합군은 60번 탱크 한 대만 관찰하고 다른 탱크의 존재 여부는 전혀 모른다고 가정하자.

이 문제는 당연히 맞는 답이 존재하지 않는다. 하지만 여러 가지 방법으로 접근해 볼 수 있는데, 그중 하나가 대칭성의 법칙을 적용하는 것이다. 60이라는 숫자가 1 ~ N까지의 구간에 떨어진 하나의 점이라고 생각하면 이는 평균적으로 이 구간을 절반으로 나눌 것이다. 그렇다면 왼편으로 59의 작은 구간이 생기므로 오른쪽으로 59의 구간이 있을 것이라고 가정하고 총 119대의 탱크가 있다고 할 수 있다.

Discussion

변수에 대한 사전 확률이 균등 분포를 이룬다면 위의 법칙을 활용해서 꽤 복잡한 문제에 쉽게 접근할 수 있는 것을 살펴보았다.

사실 확률의 대칭성을 고민하는 것은 위에 언급된 것보다 훨씬 심오한 의미가 있다. 위의 예제에서는 어떤 확률변수가 균등한 분포를 가짐을 가정하였지만, 이런 사전확률을 알지 못할 때에도 비슷한 가정을 하고 문제에 접근하는 전략을 예전부터 많은 수학자가 활용하였다. 이는 일견 잘 동작하지만 여러 패러독스를 만들어냈고, 이를 잘 이해하기 위한 이론적 발전이 있었다. 이와 관련된 내용은 따로 다루지는 않겠다. 관심 있는 분들은 probability와 symmetry에 대해 찾아보면 다양한 자료를 접할 수 있을 것이다.

AWS Gateway Load Balancer

2020년 11월 10일 AWS에서 Gateway Load Balancer(GWLB)를 출시했다.

회사에서 온보딩 진행 중 ELB 를 정리하다 알게 되었다.

자세한 것은 AWS 뉴스 블로그에서 확인할 수 있다.

현재 AWS Gateway Load Balancer를 사용할 수 있는 AWS 리전은 미국 동부(북부 버지니아), 미국 서부(오레곤), EU(아일랜드), 남아메리카(상파울루), 아시아 태평양(시드니) 리전이다.

GWLB는 파트너 어플라이언스의 간단한 배포, 확장성, 고가용성을 제공하는 서비스이다.

반대로 AWS 파트너 네트워크 및 AWS Marketplace 파트너들의 측면에서는 GWLB가 가용성, 확장성과 같은 부분을 해결해 줄 수도 있을 듯. (가격이 더 저렴해질려나?)

기존에 AWS Marketplace 등에서 방화벽을 구축하는 경우 (나의 경우는 WAF) 설계에 고려해야 될 부분과 운영 측면에서도 이슈가 많은데 GWLB를 사용하면 이러한 부분을 많이 해결해 줄 수 있을 것 같다.

GWLB는 OSI 세 번째 계층인 네트워크 계층에서 동작한다.

모든 포트에서 모든 IP 패킷을 받아서, 규칙에 지정된 대상 그룹으로 트래픽을 전달한다.

VPC 내 라우팅 테이블에서 구성을 하면 GWLB로 트래픽을 보낼 수 있고, 고객은 가상 어플라이언스에서 트래픽을 분산하여 탄력적으로 확장/축소를 할 수 있다.

고가용성을 보장하기 위해 GWLB의 고급 라우팅 기능을 사용해 트래픽을 정상 어플라이언스로만 보낼 수 있다. 이건 ALB와 비슷한 것 같다.

출처 – https://aws.amazon.com/ko/blogs/korea/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

GWLB는 모든 VPC와 사용자 계정에서 동작하고, 중앙에서 한 번에 가상 어플라이언스를 관리하는 옵션을 제공한다. 이렇게 하면 복잡성이 줄고 보안이 개선된다고 한다.

GWLB는 양방향의 트래픽 흐름을 동일한 어플라이언스로 보내고, 어플라이언스가 Stateful 하게 트래픽 처리를 하게 한다.

GWLB와 등록된 어플라이언스 인스턴스는 6081 포트의 GENEVE 프로토콜 (IETF가 만든 캡슐화 네트워크 프로토콜)을 사용하여 트래픽을 교환한다.

또 AWS PrivateLink로 구동되는 새로운 유형의 VPC 엔드포인트 – Gateway Load Balancer Endpoint(GWLBe) – 를 통해 어플라이언스를 쉽게 배포 할 수도 있다.

출처 – https://docs.aws.amazon.com/ko_kr/elasticloadbalancing/latest/gateway/getting-started.html

처음에는 API Gateway용인가? 싶었는데, 재미있는 서비스인 것 같다.

실습은 추후에 다시 포스팅 할 예정.

참고자료

https://aws.amazon.com/ko/blogs/aws/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

https://aws.amazon.com/ko/blogs/korea/introducing-aws-gateway-load-balancer-easy-deployment-scalability-and-high-availability-for-partner-appliances/

스토리지 타입 정리

이미지 출저 – https://blog.scaleway.com/understanding-the-different-types-of-storage/

AWS 학습 도중 애매하게 알고 있던 지식을 정리해본다.

블록 스토리지 vs 파일 스토리지 vs 오브젝트 스토리지

파일 스토리지

예) 하드 드라이브나 NAS

계층 구조 스토리지

파일 스토리지 방식으로 저장 시 메타 데이터가 제한적 (생성 날짜, 수정 날짜, 파일 크기 등)

데이터가 늘어나면 성능이 떨어질 수 있다. 따라서 더 많은 용량을 추가해 확장하는 방식이 아닌, 더 많은 시스템을 추가해 Scale Out해야 한다.

오브젝트 스토리지

각각의 데이터가 여러 하드웨어에 분산 개별 저장되는 데이터 저장소 유형.

서버의 블록이나 폴더 등이 아닌 단일 리포지토리에 저장되는 방식.

오브젝트 스토리지 볼륨은 각각의 독립적인 리포지토리이며, 메타데이터는 고유 식별자가 있는 평면 주소 공간에 오브젝트 자체로 저장된다. 메타데이터의 내용은 매우 상세할 수 있다.

데이터를 검색하기 위해 메타데이터와 고유 식별자를 이용하고 오브젝트의 이름은 색인 테이블에서 키 역활을 할 수 있다. 즉, 찾고 싶은 오브젝트의 키만 알고 있으면 색인 테이블을 이용해 쉽고 빠른 검색이 가능하다.

오브젝트 스토리지는 수정이 불가능하다. 그리고 전통적인 데이터베이스와 잘 연동되지 않는다.

오브젝트 작성도 느리고, 오브젝트 스토리지는 HTTP API가 필요하다. 대부분의 언어를 지원한다.

오브젝트 스토리지는 사용한 만큼만 비용을 지불하면 되어서 비용 효율적이다. 확장도 용이해 퍼블릭 클라우드 스토리지로 적합하다. 정적 데이터에 적잡한 스토리지이다.

블록 스토리지

데이터를 하나의 단위가 아닌 블록으로 쪼개어서 저장하는 방식. 각 데이터 블록은 고유 식별자를 가지고 있으며 연속적으로 저장할 필요없이 여러 환경에 분산해서 저장하고 데이터 요청 시 기본 스토리지 시스템이 데이터 블록을 병합해서 제공하는 방식.

각 블록은 서로 독립적으로 존재하기 때문에 별도의 고유 주소가 필요없으며, 계층 구조도 필요없다. 파티션으로 분할될 수 있어서 서로 다른 운영 체제에 접근이 가능하다.

저장 영역 네트워크(SAN) 저장소에 배치되고, 대부분의 애플리케이션에서 오브젝트, 파일 스토리지는 기본 블록 스토리지 맨 위에 있는 계층이다.

파일 스토리지처럼 경로에 의존하지 않아서 신속하게 검색이 가능하다.

대규모 트랜잭션을 수행하는 기업과 대용량 데이터베이스에서도 유리하며 많은 데이터를 저장해야 할 수록 블록 스토리지를 사용하는 것이 유리하다.

단점은 비용이 많이 들 수 있다. 메타 데이터를 처리하는 기능이 제한적이라 애플리케이션이나 데이터베이스에서 취급해야 한다.

AWS Network Firewall

2020년 11월 17일 AWS에서 Network Firewall을 출시했다.

자세한 것은 AWS 뉴스 블로그에서 확인 할 수 있다.

이미 NACL, Security Group, WAF, Shield 등이 있지만, 소개 문서에는 다음과 같이 이야기한다.

AWS Network Firewall은 Amazon VPC를 오가는 트래픽이나 Amazon VPC 사이의 트래픽을 검사하고 필터링하고자 하는 고객을 위한 서비스

현재 AWS Network Firewall을 사용할 수 있는 AWS 리전은 미국 동부(버지니아 북부), 미국 서부(오레곤) 및 유럽(아일랜드)이다.

AWS Network Firewall의 How it Work 도식도

AWS Network Firewall은 VPC에 대한 필수 네트워크 보호 기능을 쉽게 배포할 수 있도록 지원하는 관리형 서비스이다. 몇 번의 클릭으로 서비스를 설정하고, 자동으로 확장할 수 있어서 관리에 신경을 쓸 필요가 없다.

AWS Network Firewall의 유연한 규칙 엔진을 사용하면 네트워크 트래픽을 세부적으로 제어할 수 있는 Firewall policies를 정의하여 악의적인 활동을 방지할 수 있다.

VPC->AWS Network Firewall 카테고리 안에 Firewall policies와 Network Firewall rule groups이 있는데 policies와 groups가 있는 것은 WAF와 비슷한 것 같다.

그리고 이미 공통 오픈소스 규칙 형식으로 만들어진 규칙을 가져올 수 있고, AWS 파트너가 소싱한 인텔리전스 피드와 통합을 활성화 할 수도 있다.

AWS Network Firewall은 AWS Firewall Manager과 함께 작동해서 AWS Network Firewall policies을 VPC 및 계정에 중앙 집중식으로 적용할 수 있다.

가용 영역 별로 방화벽을 사용하며, 각 가용 영역에 대해 트래픽을 필터링 하는 방화벽 엔드포인트 용 서브넷을 선택하고, 각 엔드포인트는 엔드포인트용 서브넷을 제외한 나머지 서브넷을 보호할 수 있다.

AWS Network Firewall의 구성 요소

방화벽(Firewalls)

보호 대항 VPC를 방화벽 정책과 연결한다. 사용자는 보호할 각 가용 영역에 방화벽 엔트포인트 전용 서브넷을 연결한다. 그리고 방화벽 엔트포인트를 통해 트래픽을 전송하도록 라우팅 테이블을 업데이드 한다.

방화벽 정책(Firewall policies)

Stateful, Stateless 규칙 그룹 및 기타 설정을 정의한다.

규칙 그룹(Network Firewall rule groups)

방화벽 정책에 대한 모음이다. 또한 suricate 오픈 소스 규칙을 사용할 수도 있다.

AWS Network Firewall의 기능

1. 고가용성 및 자동 확장

모든 트래픽이 일관성 있게 검사 및 모니터링 되도록 기본으로 이중화 기능을 제공

99.99%의 가용성의 SLA을 제공하며, 트래픽 부하에 따라 방화벽 용량을 자동으로 스케일업/다운할 수 있다.

2. Stateful 방화벽

소스 주소 및 프로토콜 유형에 따라 세분화된 정책을 위해 트래픽의 흐름을 고려하며, 이 Stateful 방화벽의 일치 기준은 AWS Network Firewall Stateless 검사 기능과 동일하며, 트래픽의 방향에 대한 일치 설정이 추가된다. AWS Network Firewall은 TCP/UDP 트래픽 필터링뿐만 아니라 모든 포트를 필터링한다.

3. 웹 필터링

AWS Network Firewall은 암호화 되지 않은 웹 트래픽에 대한 인바운드/아웃바운드 웹 필터링을 지원한다. 암호화된 웹 트래픽은 SNI를 사용하여 FQDN(정규화된 도메인 이름)을 필터링 할 수 있다.

4. 칩입 방지

AWS Network Firewall의 칩입 방지 시스템은 취약성 공격 및 애플리케이션 계층 보호 기능으로 트래픽 흐름 검사를 제공한다.

5. 경고 및 Flow logs

경고 로그는 규칙 별로 상이하며, 트리거된 규칙과 특정 세션에 대한 추가 데이터를 제공한다.

Flow logs는 방화벽을 통과하는 모든 트래픽의 흐름에 대한 상태 정보를 제공하며, AWS S3, Amazon Kinesis, AWS CloudWatch에 저장할 수 있다.

6. 중앙 집중식 관리 및 가시성

AWS Firewall Manager은 AWS 조직의 서비스, VPC 및 계정 전반에 대한 보안 정책을 중앙에서 배포 및 관리 할 수 있다.

7. 규칙 관리 및 사용자 정의

AWS Network Firewall을 통해 고객은 사내 자제 규칙 및 써드 파티, 오픈 소스 플랫폼에서 조달한 Suricata 호환 규칙을 실행할 수 있다.

그렇다면 AWS Network Firewall은 AWS 기존 서비스들과 AWS 마켓 플레이스의 제품과 뭐가 다를까?

AWS Network Firewall 전체 VPC에 대한 3~7 계층의 네트워크 트래픽을 제어하고 가시성을 제공하여 기존 서비스 및 마켓플레이스 제품의 보안을 보완한다. 사용 사례에 따라 VPC 보안 그룹, WAF의 규칙, AWS 마켓플레이스 제품과 같은 기존 보안 규칙을 따라 AWS Network Firewall을 구축할 수 있다.

AWS Network Firewall을 언제 사용해야 될까?

URL, IP, 도메인 기반 트래픽을 제어할 수도 있지만 VPC to VPC, Transit Gateway를 통해 실행되는 AWS Direct Connect 및 AWS VPN 서비스를 보호 할 수 있어서 이런 케이스 때 사용하면 좋을 것 같다.

AWS Network Firewall의 배포 모델

단일 AZ에 배포된 AWS 네트워크 방화벽 및 공용 서브넷의 워크로드에 대한 트래픽 흐름
각각 보호된 VPC에 배포된 AWS 네트워크 방화벽
다중 AZ 구성으로 배포된 AWS 네트워크 방화벽
ALB/NAT 게이트웨이 사이의 트래픽을 검사하기 위한 모델
중앙 집중식 모델
Transit Gateway를 통해 들어오는 트래픽을 검사하기 위한 모델

다음에는 HOL을 작성할 예정.

참고 자료

https://aws.amazon.com/ko/blogs/korea/aws-network-firewall-new-managed-firewall-service-in-vpc/

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/

aws ec2에 wordpress 설치 시 Mixed Content Error 해결방법

블로그 용 워드프레스를 alb + ec2 + rds 구성에 설치하였다.

SSL 인증서는 ACM을 통해 발급 받았다.

설치 화면을 보려고 하는데, css/js 등이 적용되지 않은 화면이 나왔고 개발자 도구로 확인하니

이런 에러가 나왔다.

실력은 없지만 그동안 웹 개발자로 지내왔으니, 어떤 에러인지는 알고 있었고,

워드프레스 쪽에서 설정해줘야 되는 것이 있는지 확인해 보니

wp-config.php에서 아래 코드를 추가해주니 정상적으로 나왔다.

$_SERVER['HTTPS']='on';

AWS Route 53 다른 계정으로 도메인 이전

프리티어가 끝나서 새로운 계정을 만들어서 기존 도메인 이전을 했다.

도메인 이전은 AWS CLI로 할 수 있다

자세한 내용은 아래에서 확인할 수 있다.

https://awscli.amazonaws.com/v2/documentation/api/latest/reference/route53domains/transfer-domain-to-another-aws-account.html

우선 구 계정에서 aws accout id를 확인해야 되는데,

웹 콘솔에서 계정 이름 하위 메뉴에서 확인할 수 있고

aws cli을 이용하면

aws sts get-caller-identity

으로 확인할 수 있다.

우선 기존 계정으로 route53domains transfer-domain-to-another-aws-account를 실행시킨다. 매개변수 –domain-name에는 도메인 명, –account-id에는 위에서 알아낸 AccountID를 입력한다.

aws route53domains transfer-domain-to-another-aws-account --domain-name 도메인명 --account-id AccountID

출력 결과로 아래와 같이 나오는데

{
    "OperationId": "xxx",
    "Password": "xxx"
}

OperationId와 Password는 새로운 계정에서 도메인 이전 승일 때 필요하니 잘 메모해두자.

이제 새로운 계정에서 route53domains accept-domain-transfer-from-another-aws-account을 통해 도메인 이전 승인을 해야한다.

aws route53domains accept-domain-transfer-from-another-aws-account --domain-name 도메인명 --password 위 명령어에서 얻은 패스워드

위와 같이 입력하면 아래와 같은 출력 결과를 볼 수 있다.

{
    "OperationId": "xxxxxxxx"
}

이제 route 53에서 확인을 하면 되는데, 바로 되지는 않고 대략 3~5분 정도가 소요된 것 같다.

route 53 대시보드에 알림 섹션에서 도메인 이전이 된 것을 확인할 수 있다.

이전 시, 기존 서버에서 작성한 호스팅 영역 정보는 자동으로 이전 되지 않는다.

aws cli을 사용해 route53 list-resource-record-sets으로 리스트를 받아와서 마이그레이션 할 수 있다. 이 내용은 차후에 다시 포스팅 할 예정.