클라우드 개발자 앙몬드

너님들 아마 이거 글 찾아 들어왔으면,

우선 아르고CD를 이용해서 인클러스터 (니 아르고CD가 위치한 로컬 쿠버 클러스터) 외에,

타 어카운트 혹은 동일 어카운트 EKS 클러스터로, 앱 배포를 하려는 것일거임 ㅇㅇ 

그리고 니들 이 글 읽고 있으면, 아마 다른 페이지 아르고 멀티 싱크 참조글이 니들 환경에서 동작 안하거나 공식홈피 번역 힘들어서, 마지막으로 여기까지 들어왔을 가능성이 매우 농후함.

ㄱㅊ 그림으로 풀어서 설명해줄게. 우선 본론부터 들어가진 말자.

너님들도 이거 해보려고 여러 페이지 찾아보고, 오피셜도 분명 찾아봤을거임.

대충 우선 이 2개 오피셜은 기본적으로 찾아봤을 테고.

https://github.com/argoproj/argo-cd/blob/master/docs/operator-manual/declarative-setup.md#clusters

https://argo-cd.readthedocs.io/en/stable/operator-manual/declarative-setup/#clusters

둘다 같은내용. 근데 글만 띠리릭 적혀있고 영어로 뭐시기 뭐시기.

근데 설명을 좀 난잡하게 해놨다. 친절하지 않게, 그냥 글만 주루룩 적어놓았다. 

영알못이면 ㄹㅇ 힘들 수 있음. (ㄱㅊ 나도 영어 거의 다 까먹음. 그래도 아직까지 나는 기계번역이 필요치는 않음 ㅅㄱ)

그래서 내가 번역을 해올까 하다가, 이거 찾으러 들어온 사람들 어차피 번역글엔 관심도 없어보일게 뻔하지 않겠냐?

"아 그냥 어떻게 하면 되는지 코드나 내놔" 

다들 이러겠지 ㅇㅇ; 

그래서 아예 그냥 구성요소랑 그림 한장으로 요약해주겠음.

이거 보고서 구현하셈. 쿠버 매니페스트나 IAM json 코드까지는 안내놓을거다. 그래도 설정코드까지는 직접 넣어봐야지 니들 내공에 좀 들어가지 않겠음?

아 나는 그래도 구현이 힘들다하면 비밀글 달아라. 코드 줄게 ㅇㅇ

아르고 문어대가리 멀티 싱크 설정하면서 느낀건데 웬만하면 출발지에서 쓰일 IAM이랑, 목적지 IAM 분리해라.

멀티어카운트로 가야 하는데, 니 만약에 IAM 하나만 쓰고서 서비스 런칭했다고 가정하면, 분리할 때 괜히 고생길 열릴 수 있음.

혹시라도 읽으시는 분들은,

이거 그냥 개인 메모니까 굳이 이 글 말고 다른거 찾아보시면 됨 ㅇㅇ

인덱스

> 샤드

    > 루신 인덱스

    > 세그먼트(다큐먼트들) .. 세그먼트가 실제 디스크 

바로 세그먼트까지 들어가진 않고, 1초동안 버퍼에 있다가 세그먼트로 감. (디폴트 1초임. 이건 보통 좀 크게 리프레시 인터벌을 지정해서..)

검색 기준은 무조건 스토리지 세그먼트에 들어가있어야 함. 

> 샤드 개수 & 레플리카 개수 

  .. 샤드 = 프라이머니 샤드 (최소 3개 이상을 권장함. 아니면 데이터 노드 개수에 맞추어서 배수로. 즉 노드 3개면 3개 마스터 샤드.) 

  .. 레플리카 = 복제본 샤드 (최소 1개 이상은 무조건 있어야 함)

> 오픈서치는 마스터 샤드 최초 설정 이후 변경 불가. 그래서 엘사는 스케일아웃. 오서는 스케일업 을 권장함

> 

> 샤드 고르게 배포하려면, 샤드 수를 데이터 노드 (혹 az) 배수로 구성하면 좋음.

> 가용성 높이려면 az배수 고려해서 레플리카 구성하면 좋음. 

마스터 샤드 3개. 1개의 마스터에 1개 레플리카 혹은 2개 레플리카. 대다수는 1개의 레플리카만 한다. 그리고 무조건 마스터 샤드랑은 다른 곳에 저장된다. 

   좀 더 레플리카 읽기 히트를 높이고 성능 올리려면 레플리카 올려주면 좋긴 함. 근데 대다수는 1개만 씀 ㅇㅇ

> 오픈서치 검색 

(인덱스 패턴)

---롤링 인덱스

 -인덱싱 기간 / 보존 기간 있고, 계속 흘러 들어오는경우.

-올드 인덱스는 보유 기간 따라, 웜/콜드 계층으로 마이그레이션 혹은 삭제 가능. 

ex) ks-log-2022-07

---롱텀 retention 인덱스. 

같은 인덱스에 소스 데이터 저장. 문서 업뎃/삭제 필요한 경우가 많을때

ex) movies, websites,  (날짜별 인덱스가 없음)

(오픈서치 인덱스 사이즈 관리)

---사이즈 기반 로테이션

크기 추정 불가.

삭제 요구사항 없음.

동일 샤드 크기 유지.

ex) index-a-000, index-a-001

---기간(시계열) 기반 로테이션 

크기 추정 가능

삭제 요구사항 있음.

기간 기준 검색 요구사항 있음.

ex) index-a-2022-09-01, index-b-2022-09-02

(인덱스 로테이션 빈도 따른 주의사항)

매일마다 일정 데이터 흐름 속도/양 으로 들어오더라도, 빈도에 따라 샤드 구성 달라진다.

일 데이터량 30기가, 샤드 사이즈 50기가로 가정한다면,

daily rotate 

마스터 샤드 : 30기가 * 1.1/50기가 = 0.66 > 1샤드

weekly rorate 

마스터샤드 수 : 30기가 * 1.1 * 7일 / 50기가 = 4.62 > 5개 샤드

monthly rotate

마스터샤드 수 : 30기가 * 1.1 * 31일 / 50기가 = 20.46 → 21개 샤드

>>> 이거 왜 1.1을 곱하지? 

>>> 스파이크 / 에러 로그 대량 발생으로 달라지게 된다면, 샤드를 따로 만드는가? 

-----------

(도메인 구성)

마스터 노드 역할 = 인덱싱 / 헬스 / 보존기간 등 (3개 최소 무조건임)

데이터 노드 = 검색 전용 (캐싱 가능). ec2 사이즈마다 스토리지 크기 제한.

울트라 웜 노드 = 저장 노드. 이거 ec2 사이즈마다 스토리지 크기도 제한됨. 

콜드 스토리지 = 아카이브

ALB = 내부적으로 통신 시 내장됨. 

opensearch 내부적으로 유저 생성 / 권한 가능. (iam) .. 쿠버랑 비슷. 

---------

(도메인 구성 예측)

스토리지 계층 

(핫 / 울트라 웜 / 콜드 스토리지)

핫 (데이터노드) : 인스턴스 + 데이터볼륨 (비쌈, 래이턴시 낮음) 

울트라 웜 : 인스턴스 + 캐시 + s3 

콜드 : 울트라 웜에서 액세스 할 수 있는 인덱스 저장영역. 콜드에서 인덱스 검색 불가.

--스토리지 크기 예측하기 

핫 = 소스 데이터 크기 * (1 + 오버헤드 0.1 10%) * (1 + 레플리카 샤드) / (1 - os예약공간% 0.05) / (1- 아마존 어픈서치 서비스의 오버헤드% 0.2)

울트라 웜 = 소스 데이터 크기 * (1 + 오버헤드) 

콜드 = 소스 데이터 크기 * (1 + 오버헤드) 

--샤드 개수 맞추기 

작은 크기의 샤드가 너무 많으면, 검색 성능 저하. 높은 힙 사용률 문제 발생.

큰 크기 샤드도 검색 성능 저하.

  롱 텀 리텐션 인덱스 : 10~30기가 

  롤링 인덱스 : 10~50 기가 

인덱스 생성 후 샤드 수 수정 불가.

롱 텀 리텐션 인덱스 : 향후 데이터 증설 고려 필요 

롤링 인덱스 : 향후 데이터 증가 고려 불필요.

샤드당 검색 메모리를 할당.  그래서 작으면 메모리 성능 저하.

샤드 크면 볼륨 하나에서만 스루풋 왔다갔다. 볼륨쪽에서 성능 저하. 

(예제)

매일마다 200기가 씩 들어오는 로그 데이터

각 샤드 크기는 30기가 설정했음.

롤링빈도 = 50기가 초과이므로 매일 롤링

3az에 3개의 데이터 노드가 분산되어 배포. 

프라이머리 샤드 수 = (소스데이터크기 + room for growth) * (1 + 오버헤드 0.1) / 30기가 샤드크기  * 1일 = 7

  7이니까 데이터노드 개수 배수로. 6 아니면 9로 마스터 샤드 개수 설정. 

레플리카 = 6*2 (6은 마스터 샤드 개수)

-------------

샤드/스토리지 기반 스펙 예상하기 

• (일반) 액티브 샤드 당 1.5 vcpu 할당.
• (고부하) 2v cpu. 스토리지 100기가 당. 이 경우 샤드 크기가 50기가 정도 되어야함

> 액티브 샤드?

  -인덱싱 요청과 빈번한 검색 요청 처리하는 샤드

    -인덱싱 요청 : 직접 인덱싱 하는데 사용하는 마스터 샤드 + 레플리카 샤드 수 

    -검색 요청 : 마스터 샤드 수만 포함 

r타입 = 메모리타입. 데이터 내리는거보다 실시간 조회에 좀 더 힘을 실을 때 

gp3 스토리지를 추천함. 

---------

검색 성능 최적화 

..인스턴스 스토어..

많은 양 데이터 검색/집계 시, 높은 io가 필요함

!!!중첩 필드 유형은 가능한 피해야함. (nested json)

nested json을 오픈서치가 다 풀어서 인덱싱하기때문에..

!!!조인 필드 피하셈. 

1:N 관계 구조.

--------

인덱싱 최적화

.. 벌크 api 이용해서 한방에 저장하자 ㅇㅇ (3~5메가 정도 될거임)

------

리프레시 인터벌.

jvm heap : 인덱싱 버퍼 (48메가 < 10% 힙)

> (리프레시) >파일시스템 캐시 (페이지 캐시임) : 세그먼트데이터.

> (플러시) > 디스크 (세그먼트 저장)

-------

(오토 튜닝)

..유지 관리 기간 중 블루.그린 배포로 반영됨. 

jvm 셋팅 (힙 크기 최대 128기가까지) 

GC

-------

엘사 analyzer , 형태소분석기(은전한닢)  설치해보기 ㅇㅇ 

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

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

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

하나 또 잘 배웠다 굳

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

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-install-linux-alt.html

AWS 이용 시, 아마존 리눅스 이미지로 머신을 기동시키면, 몇몇개의 AWS 관련 데몬 및 에이전트가 실행됩니다.

이 때, 가만히 보면 SSM, 즉 simple system manager 라는 에이전트 또한 기동되는데

이 SSM을 이용해, AWS Systems Manager를 통한 일괄제어 방법 중 하나를 소개해드릴까 합니다.

(근데 항상 아마존은 Simple하다, 단순하다, 쉽다 하는데, 막상 까보면 하나도 쉬운거 없던디... 앙몬드만의 생각...)

머신들이 Systems Manager에 관리형 인스턴스로 들어오기 위해서는 몇가지 조건이 있는데, 

자세한 페이지는 AWS 백서를 참조해주시면 됩니다. (밑에 밑에..)

docs.aws.amazon.com/ko_kr/systems-manager/latest/userguide/setup-instance-profile.html

그 중 코어는 2가지입니다. 

  (1) (회피불가) 아마존 리눅스로..

 (2) 아마존 리눅스 머신의, SSM IAM

        - IAM : AmazonSSMManagedInstanceCore

특히 2번이 되어야, EC2 머신이, Systems Manager 관리대상 인스턴스에 등록이 되기 떄문에, Systems Manager에서 머신이 보이지 않는다면, 99.99999% 확률로 IAM 이슈일 가능성이 높습니다. (AWS는 IAM으로 시작해서 IAM으로 끝난다는 말이 있죠..)

그러면, Systems Manager에 등록된 머신들을 컨트롤링 할 때, 람다 혹은 기타 어플리케이션들은, 이 시스템 매니저와의 통신으로, 수많은 머신들을 한꺼번에 제어할 수 있습니다.

이런면에서 보면, Ansible 의 AWS버전 같기도 하네요 :)

밑에는 boto3를 이용한, 파이썬3 -> SystemsManager -> EC2_머신_프로세스 확인을 하는 코드입니다.

현재 상황은, Systems Manager에 Batch 어플리케이션 머신들을 등록하고, 이 어플리케이션이 죽었는지 살았는지를 검사하는 코드와 초간단 아키텍처 입니다. :)

ssm = boto3.client('ssm', region_name="ap-northeast-2",)

command = "ps -ef | grep java | grep -v 'grep'"
instance_id = "AWS의 머신 id가 들어가야합니다!"

# 커맨드로는, 자바 프로세스를 긁어오는 커맨드를 넣어봤습니다.

for 기준정보 in 배치머신_기준정보:
    instance_id = 기준정보["머신_id"]
    command_response = ssm.send_command(
                                InstanceIds = [ instance_id ],
                                DocumentName = "AWS-RunShellScript",
                                Parameters = {
                                    'commands':[command],
                                    'executionTimeout': ['3600'], },
                                TimeoutSeconds = 30, )
    command_id = command_response['Command']['CommandId']
    command_result = ''

    for sec in range(10):
        time.sleep(1)
        command_real_time_status = ssm.get_command_invocation(
            CommandId=command_id,
            InstanceId = instance_id, )

        if (command_real_time_status['Status'] == 'Pending') or (command_real_time_status['Status'] == 'In Progress'):
            continue
        else:
            command_result = command_real_time_status
            #print('아웃풋 컨텐츠 : ', command_result['StandardOutputContent'])
        break

    list_command_result_output = command_result['StandardOutputContent'].split('\n')
    list_command_result_output.remove('')

    # print("****결과물 정제****")
    # print(list_command_result_output)
    # print("****************\n\n\n")    

오늘은 참 신기한 일이 있었댜...

어쩌면 지금까지 맹신하고 있었던 AWS 리소스들에 대한 API 명세서를 다시 한번 읽어보아야겠다는 의심을 가지는 하루..

먼저 플랫폼에 대한 아키텍처를 하기와 같이 간단하게 그려보았습니다.

1. 상황설명

  - AWS의 ECS 컨테이너 오케스트레이션 적용. EC2 컨테이너 인스턴스들, 오토스케일링 그룹

  - Launch Configuration 을 통하여, EC2 인스턴스 오토 스케일아웃 시, EBS 또한 자동 증설 및 마운트

  - EC2의 네임태그는 현재 관리가 되나, EBS 네임태그 관리되지 않아 파이썬을 통한 네임태그 자동화 스크립트 개발!

  - 해당 VPC 내부에 위치하는 람다를 이용하여, EC2의 정보를 읽어와 EBS의 네임태그 자동생성하는 것이 목적!

어찌보면 조금 간단합니다. 뭐 로컬에서 CLI나, 해당 VPC 내부에 임시 인스턴스, 혹은 저처럼 람다를 이용하여 개발하는 방법 등등 여러개가 있죠. 하지만 개발자 앙몬드는 람다의 재미에 빠져있기에 람다를 쓴댜 실시

람다를 사용하기로 한 앙몬드는, 파이썬3 런타임의 람다, 그리고 AWS에서 제공하는 파이썬용 AWS SDK boto3를 이용해, 상기 과제를 수행하기로 합니다. 작업 설계/계획은 다음과 같았죠.

2. 앙몬드가 생각한 작업 순서

 a. 람다에서, 해당 VPC 내부에 위치한 EC2 인스턴스들에 대한 정보를 가져온댜

 b. 인스턴스들에 마운트 (탑재) 된 EBS 정보를 리스트로 추출한댜

 c. EBS의 네임태그에 조합할, EC2 네임 태그도 같이 추출한댜

 d. EBS 태그 생성을 위해, 볼륨 ID를 추출한댜

 e. b/c/d 의 조합을 가진 리스트로, EBS 정보를 호출해 네임태그를 생성한댜

 *. EBS 네임태그 규칙 : volume--(탑재된_인스턴스_네임)--(마운트경로) / ex. volume--angmond_instance_1--/dev/xvda

어찌보면, 참 단순합니다. 단지, 저것에 해당하는 API가 무엇인지, 열심히 영문 API 명세서를 읽는 일이 문제였죠..

(누가 boto3 한글 번역좀 내주소!!!!)

3. boto3 API를 모아보쟈

EC2 인스턴스를 호출하기 위한 API입니다.

리턴 포맷까지 봐야하는데.. 너어어어무 기니까 우선 레퍼런스로 남길게요... (사실 출처도 필요했어!)

  출처 : boto3.amazonaws.com/v1/documentation/api/latest/reference/services/ec2.html#EC2.Client.describe_instances

하지만, 추출 시 필요한 녀석들은 캡처를 했죠 (흐뭇)

자.. 아무튼 요렇게 3가지를 이용했고, 이제 EC2 서비스 내부에 EBS 통신 커넥터를 생성해보죠!

하기와 같습니다.

ec2.Volume의 id는 EC2 인스턴스 id가 아니라, EBS 볼륨 ID입니다. 주의하세요!

그래서 describe_instances 시, EBS 매핑정보에서 VolumeID를 추출한거죵!

이제 다 왔습니다. EBS 볼륨에 태그 생성 함수를 호출해 끝내죠!

AWS 콘솔에서 이제 자동 완성된 EBS 네임태그를 한번 구경후 끝내려는데.. 이슈가 나옵니다.

대다수 EBS에 네임태그가 생성되었는데, 생성이 안된 녀석들이 있네..? (나닛!)

4. 트러블슈팅 시작

이제부터 또 트러블슈팅 들어가야죠.. 뭐가 문제였는지..

사실 가장 먼저 떠오른건..

    ****** EC2 인스턴스 정보를 못가져왔나?

그리고 그 불길한 예감은 맞았습니다.

콘솔 확인결과, 100개의 인스턴스가 제 눈에 보였는데,

boto3.client("ec2").describe_instances() 에는 100개보다 적은 90개만 보였기 때문이죠.

음? 왜? 뭐지? AWS가 고장났다

한참을 고민한 끝에.. 오랜만에 영문 독해를 다시 시작하고서야 깨닫는군요..

다시 아키텍처를 보죠.

우리가 처음에 고정 인스턴스를 사용자 혹은 어카운트 오너가 직접 생성합니다.

그러나, ECS에 묶인 ASG EC2 클러스터들은 유저가 생성하는 것이 아니라, ASG 즉 AWS 자체에 의해서 & 내가 정한 규칙에 의해 생성됩니다.

즉, 규칙은 내가 정했으나, EC2 실제 생성은 AWS에 위임한 것이죠.

그리고 EC2 describe_instances API 명세서에 그 단서가 나옵니다. 다시 찬찬히 읽어보죠.

형광펜 칠한 부분이 보이시나요?

"내가 소유하지 않은 인스턴스를 명세할 시, describe_instances 함수의 결과값으로 반환되지 않습니다."

즉, 저 100개 중, 10개는 ECS 오토스케일 아웃 정책으로 확장되었기에, 내가 직접 만든 인스턴스가 아니라고 판단하는 것으로 추정되는 것.

따라서, 100개의 정보가 아니라, 90개만, 내가 직접 생성한 것만 넘어온 것이며, 시스템에 의해 오토스케일 아웃된 EC2 인스턴스들은 이 API의 결과로 얻을 수 없었습니다.

프로덕션 단계의 서비스에 대하여 만든 스크립트이기에, 강제 스케일 인 하여 결과를 확인해보진 않았지만, 이에 대한 정확한 답은 AWS에 이슈잉을 하여 정확한 답변을 들어봐야겠습니다.

물론 지금 위에 있는 것은, 어디까지나 앞뒤 상황을 맞추어서 제가 추론해본 것이기에 정확하지 않습니다.

아니 어쩌면 앙몬드가 틀렸을 수도 있죠..

5. 앙몬드와 회고

단지 이게 보토스 (boto3) 의 오류만인지는, 내일 AWS CLI를 직접 날려보아 보토스와 결과가 같은지를 확인해보아야 겠습니다.

만약 둘 모두 결과가 동일하다면, CLI를 사용하여 클라우드에 액션을 취하는 행위도 굉장히 조심스럽게 될 수 밖에 없을 것 같습니다.

전국의 Cloud Architect들 화이팅!

그리고 영어를 열심히 공부합시댜.....