2024-05-30-TIL
2024-05-30-TIL
Today I Learned
비정형 데이터
- https://terms.tta.or.kr/dictionary/dictionaryView.do?subject=%EB%B9%84%EC%A0%95%ED%98%95+%EB%8D%B0%EC%9D%B4%ED%84%B0
TTA 정보통신용어사전은 비정형 데이터를 정의된 스키마나 테이블 구조 없이 저장되어, 자동으로 처리하려면 별도의 구조화 과정이 필요한 데이터로 정의한다. 행과 열이 고정된 관계형 테이블에 바로 들어가지 않는다는 점에서 정형 데이터와 구분된다. 대표적인 예로 텍스트 문서, 전자우편 본문, 이미지, 음성, 동영상, 센서 로그, 소셜미디어 게시물을 든다.
백엔드 입장에서는 저장보다 처리가 문제다. 그대로 쌓아 둘 수는 있지만 검색하거나 집계하려면 텍스트에서 필드를 뽑거나 이미지에 태그를 붙이는 식의 전처리를 거쳐 정형 데이터로 바꿔야 한다. 사전에서도 AI 기반 레이블링으로 특성을 자동 추출하는 기술이 비정형 데이터 분석을 쉽게 만들었다고 설명한다.
Retry with backoff pattern
- https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/retry-backoff.html
- https://velog.io/@jazz_avenue/%EC%A2%80-%EB%8D%94-%EC%9A%B0%EC%95%84%ED%95%9C-Retry-Expenential-Backoff-with-Jitter
분산 환경에서는 스로틀링(429 Too Many Requests), 잠깐의 네트워크 단절, 일시적인 서비스 중단 같은 일시적 오류(transient error)가 생긴다. 이런 실패는 조금 뒤에 다시 시도하면 성공하는 경우가 많아서 자동 재시도가 효과적이다. 그런데 실패하자마자 같은 간격으로 계속 재시도하면 이미 힘든 서버에 부하를 더 얹는다. 그래서 재시도할 때마다 대기 시간을 늘리는 지수 백오프(exponential backoff)를 쓴다.
AWS 문서는 이 패턴을 쓸 때 고려할 점을 정리해 둔다.
- 멱등성 : 같은 요청을 여러 번 보내도 결과가 한 번 보낸 것과 같아야 한다. 그렇지 않으면 재시도가 부분 갱신을 남겨 상태를 망가뜨린다.
- 빠른 실패 : 일시적이지 않은 오류라면 재시도보다 서킷 브레이커로 빨리 실패하는 편이 낫다.
- 대기 시간 : 백오프가 길어지면 최종 사용자가 기다리는 시간도 길어진다.
문서의 Step Functions 예시는 최대 3회, 배수 1.5로 설정한다. 첫 재시도가 3초 뒤라면 두 번째는 4.5초, 세 번째는 6.75초 뒤에 일어난다.
지수 백오프만으로는 부족한 경우가 있다. 많은 클라이언트가 동시에 실패하면 같은 시점에 다시 몰려오기 때문이다. AWS Architecture Blog의 글은 여기에 지터(jitter), 즉 대기 시간에 무작위성을 섞는 방법을 비교한다. 0부터 백오프 상한 사이에서 무작위로 고르는 Full Jitter, 백오프의 절반은 유지하고 나머지만 흔드는 Equal Jitter, 직전 대기 시간을 기준으로 상한을 늘려 가는 Decorrelated Jitter가 있다. 세 방식 모두 지터가 없을 때보다 클라이언트 작업량을 크게 줄였고, 그중에서는 작업량은 조금 더 많고 시간은 훨씬 오래 걸린 Equal Jitter가 가장 불리했다는 결과였다.
AI 키워드: GPT-4o
OpenAI가 5월 13일 GPT-4o를 발표했다. “o”는 omni를 뜻하고, 텍스트, 오디오, 이미지, 영상을 어떤 조합으로든 입력받아 텍스트, 오디오, 이미지로 출력한다. 이전 음성 모드는 음성을 글로 바꾸는 모델, 답을 만드는 모델, 다시 음성으로 바꾸는 모델을 이어 붙인 파이프라인이었는데, GPT-4o는 이를 하나의 신경망으로 처음부터 끝까지 학습했다. 그래서 오디오 입력에 평균 320ms로 응답한다고 한다. 여러 모델을 잇는 대신 한 모델이 모든 형태의 입력을 직접 다루게 됐다는 말이구나.
댓글
아직 댓글이 없습니다