클라우드 개발자 앙몬드

어떤거는 컨피그맵에 넣고, 어떤거는 인그레스에 넣고 ㅋㅋ

이런거나 업데이트좀 해서 하나로 몰아넣지  

이래서 쿠버충들은 안된다는 겁니댜... 

무튼 nginx 클라이언트 바디 패킷 크기 제한은 인그레스에 넣으셈

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

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

인덱스

> 샤드

    > 루신 인덱스

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

바로 세그먼트까지 들어가진 않고, 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 , 형태소분석기(은전한닢)  설치해보기 ㅇㅇ 

기본적으로 부하테스트의 기본 카테고리는 성능테스트로 진입한댜

성능테스트 하위 단위로는 다음과 같댜

> LoadTest : 물량. 점진적인 것이고, 스케일링 테스트에 주로 사용

>StressTest : 스파이크 테스트. 일시적으로 한순간에 대량의 트래픽을 순간 쏟아넣음.

>EnduranceTest : 고가용성 테스트. 이것저것 중간에 한두대 빼고 죽이고 다운시키고 드르드르등등등

로커스트를 주력으로 사용하는데, 옵션 찾기가 힘들어서 헤매다가 다음과 같은 옵션을 찾았댜

- 유저 하나가, 1초에 몇 RPS까지 줄것인갸? (로커스트 단어로, task 데코레이터를 1초에 몇번 실행할 것인가)

> constant_throughput

class MyUser(User):
    wait_time = constant_throughput(0.1)
    @task
    def my_task(self):
        time.sleep(random.random())

.. 1초에 0.1번 태스크를 수행. 즉, 10초에 1번 수행

- 유저 하나가, 몇 초당 1 RPS를 줄 것인갸?

> constant_pacing

class MyUser(User):
    wait_time = constant_pacing(10)
    @task
    def my_task(self):
        time.sleep(random.random())

.. 10초에 한번 수행

자세한건 로커스트 스크립트 API 공식문서 참조하셈.

다음에는 성능테스트 관련 정리 글좀 올리겠음

https://docs.locust.io/en/stable/api.html

jmeter를 써본적은 없는데, 파이썬만 요즘 할줄 알아서 그냥 쿠버찡에다가 로커스트 올려봤다 

딜리버리히어로 독일 본사측에서 헬름차트 깔끔하게 만들어줬으니 쿠붕이들 가서 설치하셈 

파이썬 코드 개발은 직접 공홈 가서 보시고 

https://docs.locust.io/en/stable/writing-a-locustfile.html 

우선 처음 받은 태스크가, 배치 형태로 API를 호출하는걸 받았다

이거 신기한게 컨트롤할 수 있는 기능이 많지는 않고, 직접 거의 파이썬 코드 로우레벨로 건드려야함

특히 사이클은 단순하게 시스템 time.sleep 써서 하면 됨. 

대충 사이클 이렇게 나오고, 12초 이상으로 슬립 시키면 rps 안나온다 조심해라.

그리고 이거 부하테스트는 사실 http 평문통신 전용이고, DB부하테스트도 되긴 하는데 밑에와 같이 응답 차트는 안나온다.

대충 써본 결론은.

난 jmeter 써본 적 없고, 로커스트만 부하테스트 써봤다.

들리는 얘기로는 jmeter가 아무래도 제공해주는 기능이 압도적으로 많은 것 같음.

자바 아직도 주력 언어로 쓰고 컨테이너 충이면 jmeter 설치해서도 써보셈 ㅇㅇ 

설치 이렇게 하시고 

https://www.opsmx.com/blog/how-to-setup-ldap-and-openldap-for-argocd/

LDAP 연동을 위한 아르고 헬름 덱스서버 설정은 이거 보셈.

위에꺼 중 중간 과정에 LDAP config 관련 절차 나옴 ㅇㅇ 

그떄 이거로 들어가서 보시면 됨 

https://medium.com/yapi-kredi-teknoloji/argo-cd-ldap-authentication-and-rbac-configuration-7c1b7b0cb7a1#:~:text=LDAP%20Configuration,drive%20authentication%20for%20other%20apps

생각해보면, 도커 빌드에 파드 생성, SVC연결, 인그레스 연결, 기타 쿠버충들의 생태계까지 구축하고 버전업을 인플레이스까지 해보았다.

근데 로그쪽은 항상 중요하게 생각하면서도 내가 처음부터 구축해본 적이 없었다는 것을 최근 깨달았댜 ㅇㅇ..

요즘 로그 첫 구축 시도해보려고 하는데, 신기한게 있어서 우선 여따 적어놓는다

로그의 트러블슈팅이자 스트리밍 구간은 크게 2개이다.

1. 로그가 호스트에 떨어지는가.

2. 로그를 정제해서 스토리지로 전달했는가.

이 중 1번이 관건. 

파드 표준 출력 로그가 /var/log/containers (아눅스2 EKS 최적화 이미지 기준) 에 떨궈지는데, 이게 항상 json 포맷으로 떨어지더라 ㅇㅇ 

대충 형태가

{"log" : "표준출력 로그임 ㅇㅇ"}

이렇게 떨어짐.

나는 저 log라는 json키를 붙인 적이 없는데, 저걸 붙이는 범인은 누구였을까.

처음에는 쿠버가 붙이는줄 알고 별 짓거리를 다했는데, 알고보니 그냥 도커의 디폴트 로그 드라이버가 json으로 떨어짐 ㅇㅇ 참고하셈

https://docs.docker.com/config/containers/logging/json-file/ 

도커로 진짜 날로 배우고 왔었는데 하.. 컨테이너d 가도 이런 기본적인 포맷들이나 특성들은 유지가 되겠지? 흠