Eagle’s dev insights

이번 글은 커뮤니케이션을 줄이는 코드리뷰 팁 6가지를 소개합니다. 글을 읽으시면 코드리뷰에서 커뮤니케이션을 줄이는 구체적인 팁들을 얻어가실 수 있고, 복잡한 내용을 쉽게 설명하는 방법도 얻어가실 수 있습니다. 이번 글은 제게 조금 특별한데요, 제가 오픈소스에 기여한 실제 사례를 예시 자료로 사용했기 때문입니다. 실제 사례를 활용한 만큼, 여러분들이 내용을 이해하시는데 도움 되길 바라봅니다! 목차1.PR은 한 가지 목적만 포함하라: 리뷰어의 혼란 방지2. 부연 설명을 미리 남겨라: 핑퐁 최소화3. QnA 포맷으로 설명하라: 장황한 줄글은 그만 4. 테스트로 동작을 설명하라5. 기존 로직을 재활용하라6. 사소한 문제를 피하라: 발목 잡히지 말라 커뮤니케이션을 줄이는 것은 중요합니다. 특히 개발자라면 ..

이 글에서는 GSI 동작과 유사한 인덱스 테이블 추가로 조회 성능 문제를 빠르게 해결한 방법에 대해 소개하고자 한다. 인덱스 없는 컬럼 스캔으로 상품 라이브 직후 장애 발생.GSI 추가는 10시간이 걸리는 문제가 있었음.보조테이블 추가하고 GSI 처럼 사용해 문제를 빠르게 해결함.상황회사에서 DynamoDB 를 사용하는 api의 조회 성능에 문제가 발생했다. 제품 라이브중에 발생한 이슈라 빠른 해결이 필요한 상황이었다. 인덱스 없는 컬럼을 스캔하다 발생한 문제라, 처음엔 단순하게 GSI 추가를 생각했다. 그러나 해당 api가 사용하는 테이블은 400만개의 row가 있어 GSI 추가에 오랜 시간이 걸리는 문제가 있었다. 장애 상황인지라 빠르게 문제를 해결해야 하는데 GSI 추가는 이런 상황과 상충되는 해..

문제 상황 DynamoDB scan하는 로직에서 아래와 같은 에러가 발생했다. An error occurred (ValidationException) on request (XXXX) on table prod_XXXX ... 중략 ... The IN operator is provided with too many operands; number of operands: 101 구글링 해본 결과 DynamoDB in operation에는 제약 조건이 있음을 알게 되었다. The IN operator is provided with too many operands; number of operands: 101 AWS 문서 내용에는 다음과 같이 작성되어 있다. 즉, IN operation에는 값을 100개까지만 지정할 ..

이번 글에서는 itertools.groupby 메서드의 함정에 대해 소개하고자 한다. python 에서 itertools를 사용한다면 이 글을 자세히 보는것을 추천한다. 결론부터 말하자면 itertools.groupby를 쓸 땐, 정렬된 컬렉션을 사용해야 한다. 그렇지 않으면 집계 결과가 잘못될 수 있다. itertools.groupby는 흔히 아는 sql의 groupby처럼 동작하지 않기 때문이다. 배경 itertools.groupby()를 사용하는 로직에서 groupby만 하면 DB에서 가져온 값 일부가 사라지는 문제가 있었다. 원인을 파악하며 함정이 있는것을 알게 되었다. 사전 지식 Itertools 파이썬 라이브러리로, 효율적인 알고리즘을 사용해 컬렉션 데이터를 원하는 형태의 iterator를 만..

DB locking은 DB의 동시성 제어 기법 중 하나이다. 다수의 사용자나 프로세스가 DB에 동시에 접근해 데이터를 읽거나 쓰면서 발생할 수 있는 충돌을 방지해 데이터의 무결성을 보장하는 기법이다. 이번 글에서는 DB locking의 기법 중 optimistic locking과 pessimistic locking에 대해 다루어 보고자 한다. Optimistic locking DB에서 데이터를 읽거나 수정할 때 lock을 점유하지 않는 기법이다. 특징 Optimistic locking이 적용된 app은 데이터의 수정 / 삭제 작업을 시도할 때 원본 데이터의 변경이 없을 것이라고 가정한다. 만약 원본 데이터에 변경이 발생한 경우 수정/삭제 작업은 실패하게 된다. 이 경우 app logic에서 fail에 대..

Continous Deployment continous deployment를 사용하면 CF의 변경을 안전하게 적용할 수 있다. 이 기능의 핵심 원리는 트래픽 분리인데, 원래 CF와 동일한 CF를 새로 만들고 여기에 일부 트래픽을 보내는 것이다. 이때 새로 만들어진 CF가 바로 staging distribtuion이 된다. (원래 CF는 primary distribution이 된다.) 이 기능을 통해 우리는 staging distribution CF에 변경된 config을 적용하고, 일부 트래픽만 흘려보내 변경 이후에도 CF가 정상적으로 동작하는지 검증할 수 있다. continuous deployment의 하위 개념은 2개 정도가 있다. (아래 사진은 AWS 문서에서 발췌했다.) Continuous dep..

개요 이번 글에서는 기존 버킷에 있던 파일들이 새로운 버킷에 모두 있는지 검증하는 과정에 대해 소개하고자 한다. 이 단계는 새로운 버킷으로 전체 트래픽을 옮기기 전 선행되어야 한다. 새로운 버킷으로 migration이 누락된 파일이 있을 경우, 해당 리소스를 요청하는 모든 client는 에러를 경험하게 될 것이고, 이는 서비스 장애에 준하는 상황으로 이어질 수 있다. 필자는 staging distribution 기능을 활용해 새로운 버킷으로만 전체 트래픽의 5% 요청을 보내보고, Popular Object 기능을 활용해 4xx, 5xx 관련 에러가 발생하지 않았는지 모니터링을 진행 했다. 그리고 이 과정에 대해 상세하게 다뤄보고자 한다. 현재 상태 이전 글에서 진행한 작업 덕분에 아래와 같은 상태가 되었..

개요 이 글에서는 Cache Behavior를 사용해 CF에 새로 추가한 버킷에서 파일을 읽을 수 있는지 검증하는 방법에 대해 소개한다. 이전 글에서는 CloudFront의 S3를 교체하게 된 배경과, 어떤 작업 과정을 거쳐 버킷을 안전하게 변경할 것인지 소개했다. 자세한 내용은 이 글을 참조하자. CacheBehavior 이번 1편에서 다룰 핵심 기술이다. 소개에 앞서, 이 기술을 소개하는 AWS 문서의 핵심 내용을 인용해보았다. CacheBehavior is a complex type that describes how CloudFront processes requests. Each cache behavior specifies the one origin from which you want CloudFr..

에필로그 필자는 최근에 CF에서 S3를 안젼하게 교체하는 작업을 진행했다. 작업시 아래와 같은 고려사항이 있었고, 각 작업별 사용한 CF의 기능들에 대해 두 편에 나눠 소개하고자 한다. 새로 추가한 버킷에서 파일을 읽을 수 있는지 검증한다. (Cache Behavior 사용) 새로 추가한 버킷에, 기존 버킷의 파일이 모두 있는지 확인한다. (Staging distirbution 사용) 작업 목표 필자는 CF가 사용하는 origin 버킷을 legacy에서 new로 변경해야 했다. 한번에 버킷을 바꾸는 것은 리스크가 있기에, Cache Behavior와 Staging Distribution을 사용했다. 기존 변경 논외지만, 버킷을 바꾸는 배경은 간략히 소개하자면 다음과 같다. dev / prod 파일이 한 ..

최근 면접 질문에서 DynamoDB의 응답 시간을 최소화 할 수 있는 방법에 대해 질문을 받았다. 나는 consistency 수준을 낮추는 것 외에 다른 방법에 대해서는 답변하지 못 했다. 다음번에 같은 상황이 오지 않도록 복기해보고자 한다. 방법을 찾아보던 중, AWS에서 작성한 문서가 내용이 좋아서 가져왔다. 문서에서는 Latency를 줄일 수 있는 여러가지 방법을 제시하고 있다. 1. Adjust request timeout and retry behavior AWS SDK는 network resiliency, tcp packet timeout 등의 상황에 대비하기 위해 retry와 timeout이 적절한 균형을 이루도록 설정되어 있다. 다만, 최소 latency가 주 고려사항이라면 SDK의 time..