클라우드 개발자 앙몬드

드디어 스태틱 IAC 떼어버리고, 다이나믹 IAC로 전환할거임 ㅇㅇ 

테라폼보다는 확실히 코드 런타임으로 인프라 구성시키는게 개발자들 입장에서도 러닝커브가 덜할 것이 분명하기 때문 ㅇㅇ 

원래부터 테라폼 문법을 싫어하기도 했고, 이상하게 다들 이겁니드아! 하면 꼭 반례자료 찾아서 드라이브 잘만하는거를 보여주고 싶거든 ㅇㅇㅇ 

람다를 4년가까이 썼는데, 모르는게 아직도 많은 것 같다

글로벌 선언 시 최초 콜드스타트 시점에 일반 오브젝트들만 유지하는게 아니라 커넥션도 유지하는거였다는 사실을 왜 이제 알았을까

람다의 라이프사이클 얘기가 나오는데, 최초 초기화 때 커넥션 재사용하는 부분이 나와있다.

하나 또 잘 배웠다 굳

https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html#runtimes-lifecycle-ib

최근 재미있는 업무 요청이 있었댜

EKS로의 접근 구간 게이트웨이는 대개 LB를 배치해서 진입 구간을 제한한댜 (인그레스)

그게 L4가 되었든 L7이 되었든...

AWS ELB들을 레버리징하는 EKS의 LB들은 SSL 오프로드가 LB레벨에서 이루어진댜

자세한건 밑의 AWS 레퍼런스를 보쟈

https://aws.amazon.com/ko/blogs/aws/elastic-load-balancer-ssl-support-options/

이 떄, 인그레스로 접근 시, path별 리스너가 모두 따로 나뉘게 된댜

/a -> A SVC오브젝트

/b -> B SVC 오브젝트

그리고 호스팅하는 도메인 주소는 AWS 디폴트 주소가 되었든 혹은 SSL 인증서를 입힌 도메인 주소가 된댜

따라서, 이 도메인을 myeks.com 이라고 가정하고, a 앱으로 요청하려면 하기 구조를 가진댜

myeks.com/a  ->  EKS내의 A SVC오브젝트 (쿠버프록시) -> A파드

이슈는 바로 반드시 /a 라는 컨텍스트 패스를 클라이언트가 명시해야한댜.

마이그레이션 하는 클라이언트는 기존에 xyz.com 이라는 도메인만 호출하고, HTTP 메서드도 유지해야 하는데...

처음 생각해본 리디렉션 프록시는 ALB 리디렉션 리스너이댜

https://aws.amazon.com/ko/premiumsupport/knowledge-center/elb-redirect-to-another-domain-with-alb/

여기서 xyz.com -> myeks.com/a  로 보내는 형태이다.

단 이 ALB 리디렉션은 큰 문제가 있댜

바로 301 / 302 응답만 리디렉션이 된댜

우리는 대개 2xx, 4xx, 5xx 응답만을 주로 보고 3xx 응답은 왠만하면 크게 볼일이 없댜

이번에 3xx 응답을 볼줄은...

만약 POST 메서드로, 고객이 xyz.com > myeks.com/a 로 ALB가 리디렉션하게 되면, 무조건 GET 메서드로 치환된다.

이는 301 / 302 응답을 좀 더 확인해볼 필요가 있댜...

다른 멋진 분이 3xx 응답에 대한 정의 다이어그램을 정리해두었으니, 가서 보쟈

https://perfectacle.github.io/2017/10/16/http-status-code-307-vs-308/

클라이언트가 POST로 요청하면, ALB 리디렉션은 이를 모두 GET으로 치환한댜

위와 같은 방법을 유지하고, HTTP Method도 유지할 수 있는 방법은?

307 / 308 응답을 주어서 메서드를 유지하며 리디렉션하는 것!

개인적으로 찾은 회피책은 CF와 람다엣지 조합이댜

xyz.com > CF > 람다엣지 - 307/308 응답 > myeks.com/a

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html

코드는 그리 어렵지 않댜

유의 사항으로, AWS 클라우드프론트 (CloudFront. CF. 클라우드포메이션 아님) 는 글로벌이고 각 리전 네트워크 엣지에서 서비스를 수행한댜

CF 도메인에 SSL 인증서 (AWS ACM) 을 입혀본 경험이 있는 사람은 바로 눈치챌 것이댜

CF 인증서는 us-east-1, 노스 버지니아에서 따서 입혀야 한다는 것을.

마찬가지로 CF에서 요청을 인터셉트하여 리디렉션을 수행하는 람다엣지 또한 노스 버지니아에 배포한 뒤, CF 요청을 트리거링해야 한댜

람다 콘솔에서 트리거 추가할 떄, 다른 리전과는 달리 us-east-1 에서 람다 트리거 항목에 유일하게 CloudFront가 있는 것을 확인할 수 있댜

CF의 네트워킹 구간은 4개로 나뉜다.

https://docs.aws.amazon.com/lambda/latest/dg/lambda-edge.html

- 뷰어 리퀘스트

- 오리진 리퀘스트

- 오리진 리스판스

- 뷰어 리스판스

리디렉션 코드를 수행해야 하는 부분은 당연히 최초 요청이 진입하는 뷰어 리퀘스트 구간이므로, 이 구간에 람다 엣지로 인터셉트하여 리디렉션을 돌린댜

오리진 리퀘스트 구간에서는 수행해보진 않았는데 한번 테스트 돌려보길 희망할 수 있지만, 괜히 네트워크 레이턴시를 CF에서 뒤로 또 돌리는걸 원치 않아 뷰어 리퀘스트에서 이를 낚아챘댜

추가로, CF에서 람다엣지 인터셉트할 때, event 객체 안에 요청자의 uri path와 쿼리스트링이 들어있는 것을 조합해서 리디렉션해야한댜

이건 지금 참조페이지가 어딨는지 까먹었댜... 검색을 해보도록 하쟈

API  : https://elasticsearch-py.readthedocs.io/en/7.x/

Nginx Access Log가 들어있는 ES 데이터를 1분단위 (혹은 시간 범위) + 매칭쿼리.

AWS S3로 파일적재. (코드 최적화는 아직 안된 상태며 기능 구현에 초점)

Nginx 로그 1만줄을 S3 파일로 (비동기로) 옮기는데 대략 10초가 안될 정도로 소요됨.

람다 스펙은 10G 최대로 테스트해본 상태였댜.

현재 단순 산술식으로 하면, 특정 필터랑 쿼리로 걸러진 Nginx 로그들을 6만줄 (분당 6만건 요청. 6만 TPM) 까지는 처리가 가능하다는 얘기가 나온댜

이건 1분마다 도는 그 시간인, 1분안에 끝내야 한다는 조건이 굳이 없다면

크론을 1분마다 돌리고 타임아웃 5분정도로 설정하면 충분히 Nginx Access Log를 정제해서 SRE 요소로 뽑을 수 있다는 얘기가 성립될 수 있댜 ㅇㅇ

즉 실제로 데이터 보여주는 기간에 시간 차를 두어서 1~5분 딜레이 정도면 SLI/SLO 를 준.실시간으로 (semi-realtime) 보여줄 수 있댜

조합해서 가져오는 파이썬 런타임 람다 업로드한댜.

람다 레이어와 환경 설정은 본 항목에선 배제한댜.

- 람다레이어 : 서버리스 런타임 중 필요로 하는 라이브러리 / 디펜던시를 가져오는 기능. 리눅스 기반에서 돌아가기에, 경로가 아마 /opt 이하로 라이브러리들이 떨궈짐

import json, os
import pprint as ppr
from elasticsearch import Elasticsearch
from dateutil import tz
from datetime import timedelta, datetime
import boto3


"""

"""

def lambda_handler(event, context):

    # (0) 환경설정
    환경 = os.environ.get('env')
    서비스명 = os.environ.get('servicename')
    서비스_path명 = f"/{서비스명}/"
    seoul_tz = tz.gettz('Asia/Seoul')
    
    호스트 = ""
    포트 = 80
    if 환경 == 'dev' :
        호스트 = "(개발환경_엘사_호스트)"
    elif 환경 == 'prd' : 
        호스트 = "(운영.라이브.상용 환경 엘사_호스트)"
    
    es = Elasticsearch(hosts=호스트, port=포트)
    
    # (1) 시간 설정 및 조회
    지금시간 = datetime.now(tz=seoul_tz)
    기준시간 = datetime(지금시간.year, 지금시간.month, 지금시간.day, 지금시간.hour, 지금시간.minute, 00, tzinfo=seoul_tz)
    기준시간2 = 기준시간 - timedelta(minutes=1)
    기준시간1 = 기준시간 - timedelta(minutes=2)
    
    results = es.search(
    	index="k8s-gateway*",
    	body={
    		"size" : 10000,
    		"_source": {"includes": [ "log" ],},
    		"query": {
    			"bool": {
    				"must": 
    				[
    				 	{
    						"range": {
    							"time": {
    								"from"	: 기준시간1,
    								"to"	: 기준시간2
    							}}},
    				# 		"range": {
    				# 			"time": {
    				# 				"from"	: datetime(2021, 12, 22, 9, 00, 00 , tzinfo=seoul_tz),
    				# 				"to"	: datetime(2021, 12, 22, 9, 30, 00 , tzinfo=seoul_tz)
    				# 			}}},
    					{ 
    						"match": {"log": f"{서비스_path명}"} , }
    				] }} })
    
    리스트_nginx로그 = []
    
    for result in results['hits']['hits']: 
        리스트_nginx로그.append(result['_source'])
        #print('score:', result['_score'], 'source:', result['_source'])
    print("----------------")
    #for i in 리스트_nginx로그: print(i)
    #print(len(리스트_nginx로그))
    #print(리스트_nginx로그)
    
    # (2) s3 파일 생성한다
    s3 = boto3.Session().resource('s3')
    s3 = boto3.client('s3')

    버킷명 = "앙몬드가_넣을_버킷명"
    키파일 = 서비스명 + "/" + str(기준시간).replace("+09:00", "").replace(" ","_")
    
    # 안에 내용물이 딕셔너리다보니, join이 안되는거 같음 ㅇㅇ..  
    # 페이로드 = "\n".join(리스트_nginx로그)
    페이로드 = []
    
    print(f"지금 로그 개수 {len(리스트_nginx로그)}" )
    
    for 로그한줄 in 리스트_nginx로그 : 
        버퍼 = str(로그한줄).split(" ")
        시간 = 버퍼[4] + 버퍼[5]
        URL = 버퍼[6] + " " + 버퍼[7] + " " + 버퍼[8]
        리퀘스트코드 = 버퍼[9]
        
        리퀘스트레이턴시 = ""
        for index, value in enumerate(버퍼):
        	if "[gateway-to-" in value:
        		리퀘스트레이턴시 = 버퍼[index-1]
        		break
        
        리스판스코드 = 버퍼[-2]
        리스판스레이턴시 = 버퍼[-3]
        
        #print(f"{시간}  |  {URL}  |  {리퀘스트코드}  |  {리퀘스트레이턴시}  |  {리스판스코드}  |  {리스판스레이턴시}")
        
        변환한_한줄 = "|".join([시간,URL,리퀘스트코드,리퀘스트레이턴시,리스판스코드,리스판스레이턴시])
        페이로드.append( 변환한_한줄 )
        
    페이로드 = '\n'.join(페이로드) + "\n"

    response = s3.put_object( 
        Bucket=버킷명,
        Body=페이로드,
        Key=키파일
    )

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

AWS EKS를 쓰다 도저히 잡히지 않는 에러가 발생하여 한창 고민한 하루입니다.

상황에 대한 시나리오입니다.

(1) 쿠버네티스 클러스터 노드 중 일부 노드 그룹 (레이블로 그룹핑) 의 노드가 비정상 동작을 감지

(2) 비정상 동작 시, 해당 노드의 파드들이 정상동작되지 않는 사태

    -> OOM (unable to create new native Thread) , Connection Exception, 뭐 등등등등.. 일반적으로 스레드 풀 획득 실패

(3) 파드가 다운되고, HPA 스케일러가 이를 복구하며, 무한반복 및 파드 스케줄에 펜딩 걸리는 난장판이 펼쳐지기 시작 (와우!)

아직도 쿠버네티스 운전 잘 못하는 앙몬드의 트러블슈팅 시작..

(1) 2번 상황에서, 모든 이슈가 하나의 공통점으로 수렴하는데, 네트워크 자원에 대한 문제가 있었댜..? 

=> 문제는 해당 노드의 모든 파드가 그런 증상을 보이진 않았으며, 만약 그렇다면 ENI 매니지드 서비스에 대한 클라우드 AZ단위 장애일 가능성이 높고, 그에 대한 알람을 받은 적이 없으므로 패스

(2) 파드 내부 컨테이너 런타임인 어플리케이션의 문제댜..?

=> 그럼 다른 노드의 같은 어플리케이션들은 왜 잘 돌아가는지에 대한 확신이 없으므로, 이 또한 아니댜..

(3) 노드가 터졌댜..?

=> 반드시 그런건 아니고, 노드에 할당된 (Allocation) 은 노드 내부 프로세스 리소스 사용률을 고려하여, 70%까지만 유지하였고, 또한 이 당시에 파드가 제한값까지 치는 상황은 일어나지 않았댜.. 그런데.. NodeNotReady는 왜 뜨지.. 안의 파드들은 정상 기동중이댜..

(4) 뭐냐 그럼...?

사실 AWS EKS를 살펴보다 보면, 생각보다 간과하고서 넘어간 부분이 있습니다.

kubectl describe node {노드명}

커맨드로 쿠버 API를 호출하면, 맨날 지나쳤던 로그의 일부분. (맨날 정상이었으니 그냥 넘어갔지....)

노드의 상태값인데, 자세히 보면, Ready Type이 False. 즉 노드가 NotReady 상태로 나타났고, 이 노드를 매니징해야하는 Kubelet, 쿠버 워커노드의 중간관리자가 일할 준비가 안되어있죠.

그리고, 그 옆에 왜 쿠블릿이 정상동작하지 못한 사유가 나옵니다

"PLEG is not healthy: pleg was last seen active .... ~~"

당신 뭡니까..? PLEG요..? 아직 쿠버 초보운전이라지만, 이건 또 뭡니까..? 

developers.redhat.com/blog/2019/11/13/pod-lifecycle-event-generator-understanding-the-pleg-is-not-healthy-issue-in-kubernetes/

레드햇 공홈의 영어 원문입니다. 워커노드의 중간관리자인 쿠블릿 안에 위치한 모듈이고, 컨테이너 런타임의 상태를 조절하는 녀석이라고 설명하고 있습니다. 자세한 사항은 상기 레퍼런스를 참조해주시면 좋을 것 같아요! (머리속에 집어넣을 것도 많은데 CKA도 따야 하는건가..)

자 그럼 여기서 문제를 던져보면, PLEG모듈이 왜 컨테이너들의 상태를 비정상이라고 판단하였는지, 그리고 쿠블릿이 정상적으로 동작하던 파드들을 마구마구 죽이면서 저 에러가 난 것일까라는 의문에 도달하고 마는데!

* 그렇다면 PLEG에 대한 로그는 어떻게 볼까?

보통은, 노드의 이벤트 필드에 그 값이 나타나지만, 많은 로그를 보여주진 않습니댜.

따라서, 이에 대한 로그를 시간대별로 볼 방법이 필요한데....

* journalctl -xfu kubelet (OS별로 커맨드는 다를 수 있어요! 제가 사용하고 있는 것은 AML2, 레드햇계열 리눅스입니다)

워커노드의 쿠블릿에 대한 로그를 보여줍니다.

그러나, 이 로그와, 실제 어플리케이션의 활동로그를 보면 상이한 차이가 발생했는데..

    - kubelet : pleg가 그러던데, 너님 이상하니까 아웃

    - pod : ?????? 아니 왜 선량한 저를...

지금 이 상황입니다 정말..

결국, 왜 쿠블릿의 pleg 모듈이 저 파드들을 전부 이상한 사람 취급해서, 못살게 구나는 야간 철야로도 밝혀지지 않게 되었고, 다음 날 EKS 실제 테크니션의 답변을 듣게 됩니다.

아.. 지금 야간 작업 해야하니 간단하게만 결론 내고 가죠..

EKS 1.16 미만 의 버전에서, 노드의 CPU가 100% 가까이 사용될 때, pleg가 오작동을 하는 버그가 존재합니다.

글로벌적으로도 많이 문의가 들어온 내역입니다.

EKS의 버그이며, 현재 사용하고 있는 1.14 버전을 업그레이드 해주시면 됩니다.

.....?

그리고 이건 쿠블릿 아키텍처입니다.

programmer.help/images/blog/30f7ca203efd66487c602c86184b5b87.jpg