728x90
728x90
728x90
728x90
728x90

 

리인벤트 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도 결국 비슷한 형태이긴 한데...
요즘은 이런 형태의 제품이 많이 나오는 것 같습니다.
마침내 아마존에도 ㅎㅎ


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

 

728x90
728x90

관찰 가능성을 다루다 보면 늘 나오는 용어들.
그 중에서도 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는 "우리가 달성하고자 하는 수준"을 나타냅니다.

 

728x90
728x90

효율적인 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

 

Comparison Functions and Operators — Presto 0.283 Documentation

GREATEST and LEAST These functions are not in the SQL standard, but are a common extension. Like most other functions in Presto, they return null if any argument is null. Note that in some other databases, such as PostgreSQL, they only return null if all a

prestodb.io

 

728x90
728x90

엔지니어에게 로그는 물과 같습니다.
무슨 일이 일어나더라도 충분한 로그가 있으면 해결할 수 있기 때문입니다. 
다양한 환경에서 Proxy로 활용되는 엔진엑스에서도 마찬가지입니다.
문제는 로그가 너무 많은 경우 인스턴스 운용이 어려울 수 있다는 것이죠. 


원칙#1, 로그는 일단 끄고 시작하자

이게 무슨말이냐구요?
로그를 왜 끄고 시작하냐구요?
네, 로그를 끄고 시작하는 것을 권장합니다.

엔진엑스 구성 파일은 복잡합니다. 
여러개의 분리된 파일을 include 로 쓰는 것이 기본 구성이고
디폴트 구성 자체가 이렇게 되어 있다보니 
대부분 nginx.conf 에서 /conf.d/*.conf 로 이어지는 구성을
채택하고 사용하고 계실 겁니다.

권고 드리는 기본 구성은 nginx.conf 에서 access_log를 끄고
location 지시자 등 필요한 경우에 access_log를 활성화하는 방식입니다. 

// nginx.conf

http {
    ...
    log_format  main  '$remote_addr - $remote_user [$time_local] "$scheme" "$request" '
                      '$status $upstream_status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$http_host" "$upstream_addr"';

    access_log off;
    ...
    ...
    include /etc/nginx/conf.d/*.conf;
}

위 설정은 nginx 기본 설정 파일인 nginx.conf의 예입니다. 
http 서빙을 위해 http 블록이 들어가 있고 
로그 형식을 지정하는 log_format과 access_log 지시자가 있습니다. 

access_log 는 기본적으로 활성화 되어 있기 때문에
off 를 지정하여 http 요청에 대해 기본적으로 로깅을 하지 않도록 구성했습니다. 
패키지 저장소에서 nginx를 설치했기 때문에 /etc/nginx/에 필요한 파일들이 위치해 있고 
conf.d 경로 아래의 conf 확장자를 가진 파일들을 include 하고 있습니다.

 

원칙#2, 로그는 필요한 경우에만 켜자

로깅을 껐으면 이제는 필요한 부분에서 로깅을 켜야 합니다. 
보통은 location 블록을 활용해 업스트림 서버를 구분하거나 
필요한 프록시 기능을 구현하고 계실겁니다. 
다음의 설정은 location 블록 내에서 로깅을 활성화하는 예시입니다. 

// /conf.d/default.conf

server {
    ...
    location = /no-log-path {
        ...
        ## 여러 설정들 ##
        ...
    }

    location = /admin {
        ...
        access_log /var/log/nginx/admin.access.log  main;
        ...
    }
}

이렇게 구성하면 /no-log-path 경로로 들어오는 요청들은
앞서 http 블록에서 지정한 access_log off 에 따라 로깅을 하지 않습니다. 
대신 중요한 경로인 /admin 으로 들어오는 요청들은 
앞서 지정한 main 로그 형식에 따라 지정된 경로에 로그를 남기게 됩니다. 

 

원칙#3, 필요한 경우 샘플링해서 로그를 남기자

이렇게 필요한 경우에만 로그를 남기도록 구성했더라도 
요청량이 너무 많은 경우에는 제한적으로 로그를 남길 필요가 있습니다. 
엔진엑스의 access_log 지시자는 if 구문을 이용해 조건부로 활성화 할 수 있습니다.
위의 예제를 조금 수정해 보겠습니다. 

// /conf.d/default.conf

split_clients $remote_addr $is_need_to_logged {
    5%    1;
    *     0;
}

server {
    ...
    location = /no-log-path {
        ...
        ## 여러 설정들 ##
        ...
    }

    location = /admin {
        ...
        access_log /var/log/nginx/admin.access.log  main if=$is_need_to_logged;
        ...
    }
}

split_clients 지시자를 이용해 사용자 IP중 5%에 대해서
$is_need_to_logged 라는 변수 값을 1로 지정하도록 했습니다. 
1은 true의 의미를 갖는다는 것을 활용해 access_log 지시자의 if 구문에 활용했습니다. 
이렇게 구성한 설정의 흐름을 정리하면 다음과 같습니다.

  1. 엔진엑스 서버로 http 요청이 들어오면 일단 로그를 비활성화 한다
  2. /admin 경로로 들어오는 요청은 main 형식으로 /var/log/nginx/admin.access.log 파일에 로그를 기록한다
  3. 다만, 요청 사용자 IP기준으로 5%의 사용자에 대해서만 로그를 남긴다

로그는 중요합니다. 
하지만 로그는 가장 큰 부담중 하나입니다.
적절한 규모로 로그를 관리하는 것이
편안한 취침의 지름길입니다.

엔진엑스의 다양한 활용에 대해 알고싶다면
제가 번역한 <엔진엑스 쿡북>을 읽어보시는 건 어떨까요? :-)

 

 

NGINX 쿡북 - 예스24

애플리케이션의 성능, 신뢰성, 보안을 책임지는만능 웹 서버 소프트웨어 엔진엑스 제대로 활용하기엔진엑스 설치 및 사용법부터 다양한 모듈과 실전 운영 팁까지 다룬다. 엔진엑스라는 애플리

www.yes24.com

 

 

본 포스팅은 제휴 마케팅을 통해
소정의 수수료를 지급받는 링크를 포함하고 있습니다

728x90
728x90

오랜만에 소식 전합니다.
요즘 가장 뜨거운 분야중 하나인 관찰가능성!
영어로 옵저버빌리리~ Observability라고 하죠.
K8s처럼 더 멋진 용어로는 o11y라고도 합니다. 

<관찰 가능성 엔지니어링>은 packt에서 출간된
<Cloud-native Observability with OpenTelemetry>의 번역서입니다.
관찰 가능성을 공부하시는 분이라면
오픈텔레메트리 OpenTelemetry라는 이름을
한번쯤 들어보셨을거라 생각합니다!

 

관찰 가능성을 위한 도구는 무척 많습니다. 
하지만 너무 많은 도구들이 난립해있죠.
초보자들에게는 어디서부터 어떻게 시작해야 하는지
시작 자체가 어려워지는 상황으로 치닫고 있기도 합니다.

이 책은 오픈텔레메트리를 중심으로 
그라파나, 예거, 집킨 등 다양한 도구를 사용하여
여러분의 소프트웨어와 인프라에 대한 관찰 가능성 체계 구성을 가이드 해줍니다.

왜 OS 영역인지는 잘...

원서에서 사용한 버전이 조금 예전 버전이라
한 땀, 한 땀, 새로운 버전에 맞추어 소스코드를 개정했고
쉽게 실습하실 수 있도록 정리했습니다.

원저자의 깃허브보다는
책의 내용을 하나씩 따라 입력하면서
소스코드를 시험하는 것을 추천드립니다!
자세한 내용은 각 서점에서 확인해 보시기 바랍니다!

 

관찰 가능성 엔지니어링 - 예스24

“또 오류가 발생했다.. 정확한 원인이 뭐지?” “잠재적인 오류도 미리 알 수 있을까?”이 질문들의 답은 관찰 가능성에 있다! *OpenTelemetry 설치 및 사용법 수록마이크로서비스와 클라우드가 보

www.yes24.com

 

본 포스팅은 제휴마케팅을 통해 소정의 수수료를 지급 받을 수 있습니다.
번역서는 번역비로 끝인지라 링크를 통해 책을 구입하시면
다음 번역서를 위해 다시 달릴 수 있는 원동력이 될거라 믿습니다!

 

728x90
728x90

.env 파일을 이용해 환경 변수를 설정하는 방식이 널리 사용되고 있습니다.
개인적으로는 dotenv 패키지를 이용해서 .env 파일을 사용중인데요
오랜만에 프로젝트 환경을 구성 하다보니 dotenv 패키지가 없더군요.

그런데!

pip install dotenv를 아무리 해도 설치되지 않는 당혹스러움을 마딱드렸습니다. 
패키지가 없어진건가? 사내 네트워크에서 막힌건가? 온갖 생각을 하다 찾아보니...
dotenv의 패키지 이름은 python-dotenv 였습니다 ㅠㅠ 
오랜만에 만난 그 이름... 어쩐지 익숙합니다.

pip install python-dotenv

당황하지 말고, python-dotenv를 설치하십시오, 닝겐!

728x90

+ Recent posts