Cloud Computing On Demand

https://alex.dzyoba.com/blog/nginx-mirror/

잘쓰고 있는 미러링 모듈.

정리는 천천히... ㅠㅠ

리인벤트 2023의 키노트 중 하나입니다.
David Brown 님의 세션을 들으며 메모해 봅니다.

`Networking is about connections`

역시나 쩌는 AWS global backbone network
AWS AS 들고 계신 분은 세상을 다 가진 기분일 듯
AZ와 Edge Location을 연결하고 있다!
2030년에는 96% 이상의 차량이 네트워크에 연결되어 있을 것이다.

뉴질랜드, 캐나다, 말레이시아, 태국에 새로운 리전이 런칭예정

Latency를 더 줄이기 위해 도입한 AWS Local Zone은 벌써 35개
아직 데이터 전송 속도를 빛의 속도까지 끌어올리진 못한 인간의 한계를 극복하자 ㅎㅎ
9개의 Local Zone이 추가로 준비중

LA에 있는 엔드유저 입장에서 오레곤 리전과 LA Locla Zone의 RTT차이
안쓸수가 없음 !!

Direct Connect 로케이션은 130개 이상
회사 규모가 좀 있고 AWS 쓰고 AS 있다면 안쓸 이유가 없는 서비스.
가격은 제 알바는 아닙니다만... ㅎㅎ
올해 20개 이상 추가로 생긴다고..

클라우드프론트 팝이 이렇게 많이 늘었나..
2018년에 150개에서 2023년 기준 600개

AWS Nitro 칩이 하이퍼바이저에 오래전부터 이용중이었구나...
관심 없었던 부분이라 흐흐...

이런게 Nitro 때문에 가능하다고 이야기 하는 중.
AI/ML은 엄청난 대역폭이 필요함

기존 CLOS 네트웍 환경에 AI/ML 인스턴스가 배치되었을때 발생 가능한
네트워크 컨제스쳔 회피를 위해 울트라 클러스터를 만들었음

1.0의 한계 극복을 위해 울트라 클러스터 2.0을 만들었음

Topology API 를 새로 내놓았고,
이를 통해 최적의 Hop 을 갖는 GPU 인스턴스에 Job 을 배치할 수 있게 되었음 
즉, 울트라 클러스터 내에서의 효율성 증대를 위한 목적의 API

전통적인 라우팅 경로상의 특정 장비 문제로 인한 대규모 장애를 막기 위한 라우팅 설계

58개 이상의 인스턴스 타입에서 이용할 수 있음 
ENA Express (SRD) 라는 옵션만 키면 되고
결정적으로 무료!

Cloud WAN은 아직 잘 모르겠습니다. 
아마도 회사 네트워크 담당자들은 좀 더 큰 관심이 있을 것 같죠?
에코시스템이 있고, 대부분의 네트워크 벤더들이 들어가 있는 듯 싶습니다. 

이러나 저러나 모두에게 IP 주소 관리는 여전히 일
기존에 제공되는 IPAM 보다 향상된 제품이 나온 느낌.
참고 삼아 들어봤습니다!

IPv6 도입하느라 정말 고생했는데 (네트워크실 멤버에 비하자면 세발의 피지만...)
뭔가 Natively v6 지원에 진심인 AWS를 보고 있으면 무척 흥미진진합니다. 

인프라의 꽃은 LB 입니다. 
네, 개인적인 생각이지만 LB가 꽃인 것 분명합니다 
ELB는 그 정점에 서있고, 이번에도 흥미로운 기능을 발표했군요.
Automatic이 늘 좋은 것은 아니지만, 쓸모 있는 시나리오들이 종종 생기죠. 
자동으로 Target의 Weight를 조정할 필요는 많이들 느끼셨을겁니다.ㄹ
상세한 내용을 좀 들여다 볼 신기능이네요!

S2N? 뭔지 좀 찾아봐야겠다.

LB 에서 mTLS 도 구현해 뒀군요. 
이것도 종종 퍼블릭으로 배포된 Embedded Device 에서 이용하고자 하는 수요가 있어서
LB 레벨에서 지원해 주는 건 여러가지로 쓸모가 많을 것 같습니다. 
AWS Private CA도 지원하는군요. (당연하게도)

뭔가 VPC 애드온 같은 상품인데... Overall 한 관리를 하게 해주나 봅니다.
일단 참고하기 위해 제품명만 기억해 둡니다. 
서비스 네트워크의 생성과 정책의 정의는 네트워크 어드민이,
서비스 오너나 개발자는 그 위에서 서비스를 만드는 개념

전통적인 NW Firewall 의 AWS 버전인듯 합니다.
보안은 중요하지만 일단 머리가 아프니 ㅎㅎ..

아카마이 EA와 비슷한 느낌이네요.
Duo나 okta도 결국 비슷한 형태이긴 한데...
요즘은 이런 형태의 제품이 많이 나오는 것 같습니다.
마침내 아마존에도 ㅎㅎ

풀 영상은 아래에 붙여 두었습니다.
대략 위의 내용 보시고 영상 보시면 더 좋을 것 같네요!

관찰 가능성을 다루다 보면 늘 나오는 용어들.
그 중에서도 SLI, SLO, SLA는 늘, 반드시 나옵니다.

SLI - Service Level Indicator

SLI는 단일하면서도 측정 가능한 서비스의 동작을 나타내는 지표입니다.
중요한 것은 SLI의 대상은 명확하게 의미를 갖고 있는 것이어야 합니다.

• 예시
  
  • Availability (%)
  • Response time (ms)

SLA - Service Level Agreement

SLA는 여러 SLI를 조합한 형태로 보통 표현되는 지표입니다. 
특히 계약 관계가 얽혀 있을때는 패널티 Penalty 나 크레딧 Credit 을 부여하는 기준이 되기도 합니다. 
때문에 벤더 제품이나 플랫폼을 사용할 때 늘 첨예한 충돌이 일어나는 지점이기도 합니다. 
사내에 제공되는 내부 개발 플랫폼이라 하더라도 
SLA를 명확하게 정의해 두는 것이 정신건강을 위해 좋습니다.

SLA의 내용은 보통 (1) 보장하고자 하는 것과, 이를 위해 제시되는 (2) 제약 조건으로 구성됩니다.

• 예시
  • 매일 99% 이상의 요청이 200ms 이내의 응답시간으로 응답되어야 하며, 이 때 응답 Body 크기는 1MB 이하여야 합니다. 이보다 큰 Body를 응답하는 경우 응답시간을 보장할 수 없습니다

가만히 보면 SLA를 구성하는 요소들이 바로 SLI입니다. 

• 예시 SLA에 포함된 SLI들
  • Availability (% of requests)
  • Latency (ms)
  • Content Length (MB)

SLA는 서비스에 대한 SLA가 일반적으로 이야기되지만 
컴포넌트 단위의 SLA도 정의할 수 있습니다. 

SLO - Service Level Objective

SLO는 내용상으로보면 SLA와 거의 동일합니다. 
따라서 구성 요소도 SLA와 마찬가지로 여러 SLI가 됩니다. 
다만 SLA가 "꼭 지켜야만 하는 수준"을 나타낸다면 
SLO는 "우리가 달성하고자 하는 수준"을 나타냅니다.

효율적인 SQL 구문은 아니지만, 가벼운 SQL 쿼리문에서는 WHERE절에 `IN`을 이용한 Multiple Value에 대한 매칭을 하는 경우가 종종 있습니다. 안타깝게도 Presto 쿼리 신텍스에는 동일한 구문이 존재하지는 않습니다. 다만, 비슷한 방식으로 사용하는 구문이 존재합니다. 

-- Presto Query

SELECT id, name, department
  FROM data_source.default
 WHERE department = ANY (VALUES 'ORG1', 'ORG2')

Presto의 WHERE 구문에서는 ANY라는 키워드를 이용할 수 있습니다. 이후 VALUES 키워드에 이어서 해당 컬럼에서 찾고자 하는 여러 값을 콤마로 구분해서 넣어주면 됩니다. 보다 자세한 구문 설명은 아래 링크에서 참고하세요. 

https://prestodb.io/docs/current/functions/comparison.html