Posts

Today I Learned 날짜 2024년 12월 19일 목요일 내용 시간 단축을 위해 병렬 처리하기 네이버에서 홍보해준 덕에 인스타그램 UGC 서비스를 많은 사람들이 이용하고 있다. 그만큼 저장되어있는 인스타그램 계정과 게시글, 댓글 데이터도 늘어났는데 현재 게시글은 50만개, 댓글은 35만개가 저장되어 있다. 많아진 만큼 업데이트에도 상당한 시간이 소요되고 있는데, 크론이 거의 하루동안 돌아가기도 한다. 로직은 계정 데이터(팔로우 수, 게시글 수 등) 업데이트 게시글 데이터를 가져와 새로 생성된 것 추가하기 기존에 저장된 데이터와 비교하여 삭제된 게시글 삭제하기 태그된 게시글을 가져와 새로 생성된 것 추가하기 기존에 저장된 데이터와 비교하여 삭제된 태그된 게시글 삭제하기 이다. 6백개의 계정 하나하나씩 이 모든 로직을 처리해야 한다. 당연히 오래걸릴터이니 이에 대한 개선이 필요했다. 각각을 람다함수로 처리하고 이 람다함수를 관리하는 걸 SQS가 하면 어떨까 생각했고 이에 대해 코드브루 시간에 태용님께 여쭤봤는데 병렬처리에 관한 아이디어와 코드를 주셨다. 당연히 훨씬 구현이 쉬웠고 변경점도 적었다. 각 인스타그램 계정은 데이터가 서로 독립적이라 이렇게 처리되도 문제가 될게 없었다! 그래서 코드는 ...

10장 하이퍼미디어 동물원 정말 다양한 하이퍼미디어 유형들이 있다. 이에 대해서 더 자세히, 기술적으로 알고 싶다면 해당 하이퍼미디어의 형식 명세서를 읽으면 된다. 도메인 특화 형식 Maze+XML: 미로게임 오픈서치(OpenSearch): 검색 쿼리 문제 상세 문서: 오류 조건을 설명 SVG: 이미지 형식, 벡터 그래픽 VoiceXML: 대화 말하기(음성 인식) 컬렉션 패턴 형식 Collection+JSON: 컬렉션과 아이템 AtomPub OData 필터링: 쿼리 언어를 사용하여 내재된 프로토콜 의미 체계의 집합을 정의 함수들과 메타데이터 문서 서비스 설명 문서로서 메타데이터 문서 순수 하이퍼미디어 유형 HTTP의 프로토콜 의미 체계를 표현하는 데 집중 HTML, HAL, 사이렌, Link 헤더, Location과 Content-Location 헤더, URL 목록, JSON 홈 문서,Link-Template 헤더, WADL, XLink, XForms, GeoJSON: 일반적인 하이퍼미디이 컨트롤, 미디어 유형이 없는 결함있음 의미 체계 동물원 연결 관계의 IANA 등록부 마이크로포맷 위키 hCalendar, hCard, XFN, XOXO,adr, geo, hAtom, hListing, hMedia, hNews, hProduct, hRecipe, hResume, hReview 등 마이크로포맷 위키의 연결 관계, schema.rog, 더블린 코어, 액티비티 스트림즈, ALPS 등록부

Today I Learned 날짜 2024년 12월 18일 수요일 내용 욕심 금지 최근 아임리포트에서 구글 스프레드시트 업데이트하는 요청이 실패하는 경우가 많다. 특히 키워드 데이터를 넣을때가 문제가 되는데, 아무래도 데이터가 너무 많아서 업데이트 요청이 지나치게 오래걸리고, 타임아웃으로 실패하는 듯 하다. 그래서 데이터 제한을 15만에서 10만으로 줄였다. 그럼에도 이 문제는 나아지지 않았다. 하지만 더 줄인다면? 데이터를 더 적게 줘서 돌아간다면 모든게 해결될까? 정작 유저가 필요로 하는 만큼의 데이터를 주지 않는다면 아무 의미가 없다. ...

Today I Learned 날짜 2024년 12월 17일 화요일 내용 드디어 마침내 결국 찾은 오류의 원인 지난주부터 아임리포트에 이상한 현상이 발견되었다. 네이버에서 대용량 보고서 요청을 보내도 빈 응답값이 반환되는 현상이다. 끈질기게 원인을 찾았으나 결국 찾지 못했는데, 증상만 보면 다음과 같다. 매일 오전에 실행되는 자동 업데이트에서만 발생한다. 수동 업데이트를 아무리 많이 보내봐도 재연되지 않는다. 요청에 대한 응답 코드는 200이나 빈 배열이 반환된다. 발생하는 로우데이터, 날짜 모두 불분명하다 여러 시나리오를 추정해봤으나 발견하지 못했다. ...

Today I Learned 날짜 2024년 12월 16일 월요일 내용 네이버는 왜 주지 않는가 아임리포트 자동 업데이트 떄, 생성한 보고서 조회 요청에 자꾸 빈 값이 들어온다. 무작위로 중구난방하게 발생하고 있어 원인을 도저히 파악할 수 없다. 특히나, 매일 아침 실행되는 실서버 정기 업데이트에서만 발생하기 때문에 버그를 재현할 수 없다는게 가장 큰 문제… 일단 구체적으로 어느 날짜의 보고서 조회가 빈값을 반환하는지 확인할 수 있도록 로그문을 추가해놨다. 실제로 없어서 안주는 건지, 뭐가 잘못된건지 내일이면 알 수있지 않을까! ...

Today I Learned 날짜 2024년 12월 13일 금요일 내용 pre-signed url이 작동하지 않는 이유 현재 티켓페이지에서 사용자가 추가한 이미지와 파일을 저장하는 방식은 그다지 좋지 않다. 서버에게 티켓의 이미지와 파일을 S3에 저장해달라고 요청을 보냄 서버는 저장 후 그 링크를 반환함 반환받은 링크를 티켓 데이터에 추가하여 티켓 데이터 생성 요청을 보냄 이 방식이다. 만약 클라이언트가 S3에 저장할 수 있다면 굳이 서버에게 파일을 보내지 않아도 된다. 이를 위해 pre-signed-url을 보내도록만 요청을 변경해야 한다. 이 URL은 설정한 시간만큼만 유효한 URL이다. 서버에게 어떤 버킷 내 어떤 키에 생성해야 할지 알려주고 url을 받아왔으나 생성이 되지 않는다. 클라이언트의 요청에 0 Unknown Error만 나와 정확한 원인도 모른다… 구글링을 한참 해보니 pre-signed url을 생성하기 위해 boto3 클라이언트를 초기화할 때 리전을 입력해보라고 한다. ...

Today I Learned 날짜 2024년 12월 12일 목요일 내용 선택적으로 path parameter 받기 쇼핑몰 상세 페이지에서 오른쪽 네비게이션 바를 통해 티켓을 볼 수 있다. 이 티켓을 클릭하면 티켓 페이지를 새창으로 띄워줘야 하고 상세보기에는 해당 티켓이 나타나야 한다. 티켓페이지에선 상세보기도 하위 컴포넌트로 구현되어 있어서 어떤 티켓을 눌러도 중앙 쪽에 있는 돔에만 변화가 생길뿐 나머지는 그대로다. 즉, 티켓 페이지의 최상위 컴포넌트에는 정해져있는 로직에 따라 최초로 상세보기에 띄울 티켓을 선택할 뿐이고 그 외는 없어서 구현해야 했다. ...

9장 설계 절차(1) 2단계 설계 절차 가장 단순한 형태 표현에 사용할 미디어 유형을 선택한다. 프로토콜 의미 체계(HTTP 프로토콜 하에서 API의 행동 양식)와 애플리케이션의 의미 체계(표현이 참조할 수 있는 실제 세계의 것들)에 제약 사항들을 결정 그 외 모든 것을 다루는 프로파일을 작성한다. JSON을 선택 ⇒ 프로토콜 애플리케이션 의미 체계에 아무런 제한이 없음 ⇒ 2에 모든 시간을 소비 7단계 설계 절차 API에서 클라이언트가 얻길 원하는 것이나 또는 API를 통해 넣길 원하는 모든 정버를 열거함 의미 체계 서술자 API를 나타내는 상태 다이어그램을 그림 연결 관계 기존에 있는 프로파일의 문자열을 이 API의 마법 문자열과 조정함 이 API의 프로토콜 의미 체계와 애플리케이션 의미 체계와 호환되는 미디어 유형을 선택하거나 새롭게 정의 애플리케이션 의미 체계를 기술하는 프로파일을 작성 코드 작성 광고판 URL 게시 미로 게임을 예시로 둔다. ...

Today I Learned 날짜 2024년 12월 11일 수요일 내용 리마인더 알람기능 이것저것 아주 간단한 기능들을 고치거나 만드는 중. 기본 코드가 워낙 보기 쉽게 잘 짜여져있고 로직도 단순해서 큰 어려움은 전혀 없었다. 다만, 리마인더 기능은 조금 고민이 들었다. 티켓에는 리마인더 기능이 있는데, 노션에서 처럼 일정 기간 후 유저에게 알려줘야 한다. 물론 유저가 티켓 페이지에 접속했을 떄만.. 그래서 유저가 티켓 페이지에 들어왔을 때 리마인더를 조회하도록 했다. 설정된 리마인더 시간이 가장 빠른 것부터 보여준다(다시 말하면 알람이 울린지 가장 오래되었다는 뜻). ...

Today I Learned 날짜 2024년 12월 10일 화요일 내용 코어 작업에 투입되었다. 아는 구조, 로직, 코드가 하나도 없어서 작은 태스크부터 맡기로 했는데 우선 티켓 관리 페이지 QA부터 처리하기로 했다. 프론트까지! 딱 작년 이맘때에 첫 태스크를 맡았을 때의 느낌이 난다. 1년동안 열심히는 살았는지, 로직 파악이나 코드 파악 등도 훨씬 빨라졌고 로컬 세팅도 알아서 잘 했다. 첫 시작으로 아주 좋은 태스크를 맡은 듯 하다. 회고 정말 오랜만에 다른 사람의 코드를 보는 거라 뭔가 설렌다. ...