728x90

얼마전 회사 공식 유튜브 채널에서 개발자 밋업 영상을 찍었습니다.
근래에 회사 공식 유튜브나 블로그에 뭔가 기여한 기억도 없고 하여
겸사겸사 "NGINX 쿡북" 2판 번역서 출간 홍보도 할겸 전격 촬영에 임했습니다.

유튜브 라이브로 진행되는 회사 관련 액티비티는
신년대응 관련해서 진행했던 세션 이후로 간만이라.. 감회가 새로웠습니다.
재미있는 것은 이 영상을 찍은 이후에도 회사내에서 NGINX 관련한 이슈들에 난입할 계기가 있었고
세션에서 했던 이야기들이 헛되지 않았구나 하는 생각을 했었습니다 ^^;

아무쪼록 재미있게 봐주시면 좋겠습니다.
이것도 벌써 찍은지 2주가 넘어가는..ㅎㅎ

 

728x90
728x90

트위터에서 돌아다니는 트윗과 짤이 좋은 점은 여러가지가 있지만
하나의 트윗 140자에서 많은 것을 함축적으로 이야기 해야 하기 때문에
컨텐츠(?)의 밀도가 높아서 스낵(snack)처럼 소비하기 좋다는 점입니다 ㅋ

오늘도 지나가다 <6 Linux command you must learn in 2023>라는 트윗을 봤고
여기에 올라와 있던 리눅스 초보자를 위한 터미널 주요 명령을 가져와 봤습니다.
익숙하지 않은 명령들이나 의미를 잘 몰랐던 명령들을 되뇌이는 기회를 만드십시오!

출처 : https://twitter.com/javinpaul/status/1610150056513912833/photo/1

이미지에 포함된 내용들은 사실 굉장히 단순한 명령들입니다. 
하지만 처음 접하시는 분들은 요런 것들도 헷갈릴 수 있다고 봅니다!

#리눅스 #리눅스기초명령어 #linuxcommand #linuxcommandline

 

728x90
728x90

GS네오텍에서 잘 정리해둔 자료가 있어서 읽어보았습니다. 
시장의 싸움은 CMAF와 LL HLS로 압축된 느낌이고 (WebRTC 등은 다른 용도로)
각각은 대부분의 CDN 벤더가 잘 처리해주고 있는 것처럼 생각됩니다.

AWS의 예제로 CloudFront를 사용하는 시나리오가 설명되어 있는데 
다른 특별한 구성이 필요해 보이지는 않는 느낌입니다. 
다만, 내용은 CMAF에 대해서만 염두하고 있는 느낌이고
LL HLS에 대해서는 시험이나 고려되지 않은 것 같습니다. 

https://www.slideshare.net/awskorea/low-latency-live-service-implementation-with-aws

 

AWS 를 활용한 저지연 라이브 (Low Latency Live) 서비스 구현 - 류재춘 컨설턴트/에반젤리스트, GS Neo…

라이브 방송의 성장과 더불어 최근 저지연 라이브 (Low Latency Live) 에 대한 관심이 높아지고 있습니다. 본 강연에서는 Low Latency Live 관련 기술적인 배경과 Latency를 줄이는 원리에 대한 설명을 하고,

www.slideshare.net

 

CMAF를 사용하는 경우 Chunked Transfer가 핵심 기술이 되고
LL HLS를 사용하는 경우 Chunked Transfer가 핵심은 아니긴 합니다. 
아래 장표를 보고나서... 이 자료는 CMAF 기반의 Low Latency 구성이구나를 깨달았습니다. 

 

실제 사용자 환경은 정말 다양하고 품질도 천차만별이라
Low Latency 라이브 서비스를 어떻게 구현할 것인지의 고민이 많을 수 밖에 없습니다.
Trade-off 장표가 그런 고민들을 일목 요연하게 보여줍니다. 

 


AWS Document를 뒤져봐도 Low Latency HLS에 대해서는 이렇다할 내용이 없는 것 같습니다. 
규격상 몇 가지 걸리는 부분들이 있고 CloudFront에 대해서도 고민이 되는 부분인데
조금 더 검색력을 높여 구글신, ChatGPT와 함께 골머리 싸봐야겠습니다.

(추가)
ChatGPT 만세... AWS Elemental MediaPackage가 LLHLS를 지원하네요
셋업해서 한번 시험해 봐야겠습니다!

728x90
728x90

https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/query-logs.html

 

Public DNS query logging - Amazon Route 53

If users are submitting DNS queries for your domain, you should start to see queries in the logs within several minutes after you create the query logging configuration.

docs.aws.amazon.com

 

Route53 은 CloudWatch Logs 로 로그를 보내 분석하기 쉽습니다. 
다만, 이놈의 AWS 는 언제나 문서는 많지만, 원하는 문서를 찾기가 어렵긴합니다.

CWL에서 Log Insights로 Route53 로그를 쿼리할 때
도대체 어떤 컬럼명이 존재하는지 찾는 것도 마찬가지입니다.

일단은 위의 페이지에서 컬럼명을 추정할 수 있고
추정된 컬럼을 쿼리에서 사용할 수 있습니다. 
몇 가지 샘플 쿼리를 미래의 나를 위해 남겨둬 봅니다. 

filter (queryType="A" or queryType="AAAA")
| stats count(*) by queryName, queryType, responseCode, bin(1h)
| limit 50
stats count(*) as numRequests by resolverIp
| sort numRequests desc
| limit 10
filter responseCode="SERVFAIL"
| stats count(*) by queryName

그리고 CWL 쿼리 문서는 아래의 경로에 있습니다. 
정리가 잘 되어 있지 않지만... 대략...?

 

CloudWatch Logs Insights query syntax - Amazon CloudWatch Logs

When you create a query command, you can use the time interval selector to select a time period that you want to query. For example, you can set a time period between 5 and 30-minute intervals; 1, 3, and 12-hour intervals; or a custom time frame. You also

docs.aws.amazon.com

 

#cloudwatch #cloudwatchlogs #route53 #aws #awsroute53 #dns

728x90

+ Recent posts