Eagle’s dev insights

커뮤니케이션을 줄이는 코드리뷰 팁 6가지

eagle25 — Mon, 31 Mar 2025 01:08:58 +0900

이번 글은 커뮤니케이션을 줄이는 코드리뷰 팁 6가지를 소개합니다.

글을 읽으시면 코드리뷰에서 커뮤니케이션을 줄이는 구체적인 팁들을 얻어가실 수 있고, 복잡한 내용을 쉽게 설명하는 방법도 얻어가실 수 있습니다.

이번 글은 제게 조금 특별한데요, 제가 오픈소스에 기여한 실제 사례를 예시 자료로 사용했기 때문입니다. 실제 사례를 활용한 만큼, 여러분들이 내용을 이해하시는데 도움 되길 바라봅니다!

커뮤니케이션을 줄이는 것은 중요합니다. 특히 개발자라면 코드리뷰에서 다른 개발자와 소통하게 되는데요, 이때 커뮤니케이션이 많이 발생하면 일의 진행 속도를 느리게 하고, 나중에 원하는 정보를 찾기 어려워집니다.

그렇다면 어떻게 코드리뷰에서 커뮤니케이션을 줄일 수 있을까요? 이어지는 내용에서 구체적인 방법을 소개합니다!

1. PR은 한 가지 목적만 포함하라: 리뷰어의 혼란 방지

Pull Request(PR)은 한 가지 목적만을 담는 게 좋습니다.

Fig.1은 서로 다른 성격의 작업이 3개 담겨있는 PR입니다. (기능 수정, 리팩터링, 기능 추가) 여러분이 리뷰어라면 어떻게 느껴지시나요? 저는 무슨 목적으로 코드를 수정했는지 파악이 어렵고, 목적이 여러 개라 혼란스럽게 느껴집니다.

Fig.1, 여러가지 목적이 혼재하는 코드 수정.

다른 관점에서 생각해 보겠습니다. eagle-25라는 동료가 여러분이 올린 PR에 질문을 남겼습니다. 무엇이 문제일까요?

문제는 바로, 대화가 여러 가지 주제로 산발적이게 이뤄진다는 것입니다.

Fig.2, 산발적으로 대화로 이어지는 질문들.

산발적으로 이뤄지는 대화가 왜 문제일까요?

Fig.3에서 대화의 맥락을 보면 2, 3번 수정은 더 이상 리뷰가 필요하지 않습니다. 하지만 PR을 머지하려면 1번 수정이 문제없는지 확인이 끝나야 합니다. 다르게 말하면 1번 때문에 2, 3번 수정이 배포되지 못하는 상황인 것입니다.

또 다른 문제가 있는데, 코드리뷰를 어렵게 한다는 것입니다. 여러 가지 주제로 대화하다 보면, 이해 관계자가 많아지고, 리뷰 시 고려할 요소가 많아집니다. Fig.3을 보면 벌써 PR 하나에서 abc팀과, xyz팀이 등장하고 있습니다.

Fig.3, 산발적으로 이뤄지는 대화.

그렇다면 수정 1, 2, 3을 각각 별개의 PR로 분리했다면 어땠을까요? 먼저 2, 3번을 각각 다른 PR로 분리하고 살펴보겠습니다. (Fig.4)

기존 PR과 비교했을 때, 두 가지 장점이 드러납니다.

수정 목적이 분명해집니다. 기존 PR의 커밋 메시지는 "DB 코드 수정"으로 두루뭉술했다면, 분리된 PR의 커밋 메시지에는 PR의 목적을 분명하게 드러내 리뷰어의 혼란을 줄여줍니다. (e.g., feat: DB().delete() 메서드 추가).

리뷰가 빠르게 진행됩니다. 분리된 PR은 기존 PR 대비 수정된 코드가 훨씬 적습니다. 이는 리뷰어가 각 PR에서 리뷰할 변경이 작아졌기 때문에, approve를 상대적으로 빠르게 주는 결과로 이어집니다.

Fig.4, PR 분리로 내용과 대화가 간소화된 예시.

목적이 다른 수정은 번거롭더라도 PR을 분리하면, 수정 목적을 명확하게 해 리뷰어의 혼란을 줄이고, 각 PR에서 리뷰할 내용이 작아져 리뷰가 빠르게 진행됩니다.

다만, 아래처럼 예외를 둘 수도 있으니, 상황에 맞게 PR을 분리하시면 더 좋습니다.

Q: 목적에는 관계없지만, 아주 간단한 수정도 꼭 분리를 해야 하나요? (e.g., 한 줄짜리 typo 수정)
A: 추가적인 커뮤니케이션이 필요 없다면 분리하지 않아도 됩니다.

2. 부연 설명을 미리 남겨라: 핑퐁 최소화

코드리뷰를 받다 보면 종종 이런 질문을 받습니다.

이 메서드는 왜 추가하셨죠?
이 로직을 제거하신 이유는 무엇인가요?
...

이들 질문의 공통점은 추가적인 맥락이 없다면 의도를 알기 어려운 내용을 질문하고 있다는 것입니다. 때문에 리뷰를 요청하기 전, 부연설명을 미리 남겨두면 커뮤니케이션을 줄일 수 있습니다.

실제 예시를 통해 필요성을 살펴보겠습니다. 아래 사진(Fig.5)은 코드를 수정하면서 기존에 있던 정렬 로직(-L871)을 제거한 모습입니다. 코드를 본 적 있는 리뷰어라 하더라도, 멀쩡한 정렬 로직을 지우는 것으로 느껴질 수 있어 "왜 지운거지?" 하는 의문이 들 수 있습니다.

뿐만 아니라, 리뷰어는 로직을 지운 이유에 대한 설명을 요청할 가능성이 높습니다. 이는 곧 커뮤니케이션 증가로 이어지기 때문에 부연 설명을 미리 추가하는 게 좋습니다.

Fig.5, 설명이 없어, 정렬 로직을 알기 어려운 예시.

그렇다면 부연 설명을 추가하고 코드를 다시 살펴보겠습니다. 사진에서 eagle-25(PR 작성자)는 정렬 로직을 의도적으로 지웠으며, 그 이유를 설명하고 있습니다. 덕분에 리뷰어는 로직을 지운 이유를 물어보는 대신, 제거를 동의하면서 다른 동료에게 corss-check를 요청하는 방향으로 일이 빠르게 진행되는 모습을 보입니다.

Fig.6, 정렬 로직을 지운 이유에 대한 설명이 남겨진 예시.

질문을 받을 여지가 있거나, 맥락을 쉽게 알기 어려운 수정에는 부연설명을 미리 남겨놓는 게 좋습니다. 리뷰어는 궁금한 내용에 대한 답이 이미 달려있기 때문에 질문할 필요가 없어져 리뷰가 빠르게 진행됩니다.

코드리뷰를 요청하기 전, 부연설명이 필요한 부분은 없는지 살펴보기를 바랍니다.

3. QnA 포맷으로 설명하라: 장황한 줄글은 그만

타인에게 무언가를 설명할 때는 가능한 간결한 게 좋습니다. 하지만 설명할 내용이 복잡하다면 간결하게 글을 쓰기란 쉽지 않습니다. 저는 이때 QnA 포맷을 활용해 설명을 하곤 합니다.

Fig.7은 어떤 코드를 추가하게 된 배경을 설명하기 위해 작성한 글의 첫 번째 버전입니다. 어떠신가요? 제가 글에서 무엇을 말하고자 하는지 한눈에 들어오시나요? 제가 쓴 글이지만 저마저도 무엇을 말하려는지 한눈에 들어오지 않습니다.

Fig.7, 복잡한 내용을 장황한 줄글로 설명하는 예시.

Fig.8은 Fig.7의 내용을 QnA 포맷으로 작성했습니다. Fig.8은 이전과 달리, QnA 포맷으로 작성되어 무엇을 말하려는지 쉽게 알 수 있습니다. 설명하려는 내용이 각각 Q로 분리되어 있기 때문에 독자들은 원하는 정보만 취사선택할 수 있습니다.

Fig.8, 줄글로 설명하던 내용을 QnA로 작성한 모습.

복잡한 내용을 글로 설명하기란 쉽지 않습니다. 이때 QnA 포맷을 사용하면 글이 구조적인 형태를 띠게 되어 가독성이 향상되고, 독자가 원하는 정보만 선택해 글을 읽을 수 있도록 배려할 수 있습니다.

4. 테스트로 동작을 설명하라

때로는 장황한 글보다 테스트 코드 몇 줄이 코드의 동작을 효과적으로 설명합니다. 테스트 코드 자체의 이점은 이미 인터넷에 잘 설명되어 있어서 다루지 않겠습니다.

다만, 테스트 코드를 활용하면 기존 동작과, 변경된 동작을 쉽게 설명할 수 있다는 걸 말씀드리고 싶습니다.

Fig.9에서 assert 문에 바뀐 코드의 동작을, 댓글에는 assert문과 비슷한 형태로 기존 동작을 표현하고 있습니다. 오픈소스 리뷰어인 sgomezvillarmor는 동작의 차이를 쉽게 이해하고 `nice catch` 라는 댓글을 남겼습니다.

Fig.9 기존 동작/변경된 동작을 테스트코드로 설명하는 예시.

테스트코드를 추가하면 기존 동작과, 변경된 동작을 쉽게 설명할 수 있습니다. 장황한 글 대신 테스트 코드로 동작을 설명해 보시는 건 어떠신가요?

5. 기존 로직을 재활용하라

새로운 로직을 추가하기 전, 이미 기존 코드에 있는 로직은 아닌지 살펴보는 게 좋습니다.

실제 사례를 살펴보겠습니다. (Fig.10)

리뷰어인 treff7es는 추가한 메서드(_get_table_name)가 기존에 있는 메서드와 어떻게 다른지 질문합니다.
리뷰이인 eagle-25는 두 메서드가 다르지 않기 때문에, 추가한 메서드를 지우겠다고 합니다.

이 사례는 추가하려는 로직이 이미 존재하는지 검토하지 않았을 때 발생하는 두 가지 문제를 보여줍니다. 바로 불필요한 코드 작성에 시간을 사용하게 되고, 불필요한 커뮤니케이션이 추가된다는 것입니다.

Fig.10, 리뷰어가 기존 로직과, 추가하는 로직이 어떻게 다른지 질문하는 예시.

새로운 로직을 추가하기 전, 기존 로직을 재활용할 수 있는지 먼저 검토하시면, 소중한 시간과 커뮤니케이션 비용을 아낄 수 있습니다.

6. 사소한 문제를 피하라: 발목 잡히지 말라

리뷰를 요청하기 전, 사소한 문제가 없는지 한번 더 확인하는 게 좋습니다. 예시로는 lint 문제와, CI 실패(e.g., 테스트 실패)가 있습니다.

아래 PR들은 변경에 대한 승인은 받았지만, 사소한 문제 때문에 PR 병합이 지연된 모습을 보여줍니다.

Fig.11, 사소한 문제로 발목잡힌 예시. (좌): lint 문제, (우): test 문제

test, lint 등의 사소한 문제를 미리 확인한다면 발목 잡히는 일을 예방할 수 있습니다. 또한 리뷰를 다시 해야 하는 리뷰어와 리뷰를 다시 요청해야 하는 리뷰이의 모두의 시간을 아낄 수 있기 때문에 꼭 확인하시기를 바랍니다.

마치며

이번 글에서는 커뮤니케이션 최소화에 중점을 둔 코드리뷰 팁 6가지를 살펴보았습니다. 실제로 제가 오픈소스에 기여하면서 있었던 사례들과 함께 코드리뷰 기술들의 효과를 설명했는데, 이해하시는데 도움 되었길 바랍니다.

저는 소프트웨어 엔지니어로 커리어를 막 시작했을 때, 코드리뷰에서 많은 어려움을 겪었습니다. 과거의 저처럼 코드리뷰에 익숙하지 않은 분들이 이 글을 읽고, 동료와 함께 시너지를 내는데 도움 되길 바라며 글을 마칩니다.

긴 글 읽어주셔서 감사합니다.

정리

PR은 한 가지 목적을 담자. 산발적인 대화를 줄이고, 리뷰어의 혼란을 방지할 수 있다.
부연 설명을 미리 남겨두자. 질문받을 가능성이 높은 곳에 설명을 남겨두면 커뮤니케이션을 줄일 수 있다.
복잡한 내용을 설명할 때는 QnA 포맷을 활용해 보자. 독자가 원하는 정보를 취사선택해 읽도록 하도록 배려할 수 있다.
기존 / 변경된 코드의 동작을 설명할 때는 테스트 코드를 활용하자. 줄글보다 쉽게 내용을 전달할 수 있다.
새로운 로직을 추가하기 전, 기존 로직을 재활용할 수 있는지 살펴보자. 소중한 시간과 커뮤니케이션 비용을 절약할 수 있다.
리뷰를 요청하기 전, 발목을 잡는 사소한 문제(e.g., test, lint)가 없는지 확인하자.

DynamoDB 성능 문제 빠르게 해결하기

eagle25 — Mon, 18 Mar 2024 17:35:59 +0900

이 글에서는 GSI 동작과 유사한 인덱스 테이블 추가로 조회 성능 문제를 빠르게 해결한 방법에 대해 소개하고자 한다.

<3줄 요약>

인덱스 없는 컬럼 스캔으로 상품 라이브 직후 장애 발생.
GSI 추가는 10시간이 걸리는 문제가 있었음.
보조테이블 추가하고 GSI 처럼 사용해 문제를 빠르게 해결함.

상황

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

문제 원인

문제는 상품 라이브 이후에 발생하기 시작했다. 회사의 DynamoDB 테이블은 광고주가 우리측 서버로 전송한 이벤트를 쌓게 된다.

광고주 서버 --> 우리회사 서버 --> DynamoDB 테이블

장애가 발생된 API는 Dynamo테이블에서 인덱스가 없는 컬럼을 scan해 원하는 데이터를 찾도록 설계했다. 광고주가 보내는 데이터의 규모가 많지 않을것이라 판단했기 때문이다. 그리고 이 판단은 장애로 이어지는 시발점이 되었다.

[기존]

상품 라이브 전에는 광고주가 보내는 데이터가 많지 않았다.

[라이브 이후]

광고주 측에서 데이터를 많이 보내기 시작했다. 광고주의 앱 런칭 시점에 맞춰 제품 라이브를 시작했기 때문에, 사용자가 늘어남에 따라 광고주가 보내는 이벤트가 많아졌다. 데이터가 많은 상황에서 scan을 시도했기 때문에 성능 문제가 발생했다.

해결책

기존 테이블과 동일한 구조의 테이블을 만들었다. 그리고 두 테이블에 동일한 데이터가 쌓이도록 했다. 이전에 쌓인 데이터를 사용해야 할 필요는 없었기 때문에 데이터 migration은 진행하지 않았다.

새로만든 테이블을 v2 테이블이라고 하자. v2 테이블의 hash key는 scan시 사용한 컬럼이 되도록 했다.

그리고 코드에선 사용자_id를 사용해 검색해야 할때, 아닐때를 구분하여 적절한 테이블을 사용하도록 하였다.

class V1Table(Model):
   owner_id # hash_key
   user_id
   
class V2Table(Model):
   owner_id 
   user_id  # hash_key
   
   
class EventRepository():
	def get_events_by_owner_id(id: int):
       return V1Table.query(hash_key=id)
       
	def get_events_by_user_id(id: int):
       return V2Table.query(hash_key=id)

고려사항

두 개의 테이블에 데이터를 쌓기 때문에 WCU를 두 배로 사용하게 되는데, 불필요한 비용이 발생하는것 아닌가? 라는 의구심이 들 수 있다.

원래 테이블이 WCU 100개가 필요하다면 V2 테이블도 WCU 100개가 필요하다.

그러나 답은 그렇지 않다 이다.

먼저 GSI 데이터 구조를 살펴보자.

인덱싱에 사용할 컬럼을 hash_key로 가진다.
나머지 부수적인 값(광고주_id, 이벤트 정보)는 projected attributes라고 부르며 필요에 따라 추가하지 않을수있다.

앞서 추가한 인덱스 테이블과 상당히 유사하지 않은가?

인덱스 테이블

다음은 WCU 할당에 대해 살펴보자

GSI를 사용하려면 GSI 전용 rcu/wcu를 할당해줘야 한다.

The provisioned throughput settings of a global secondary index are separate from those of its base table.

AWS는 테이블이 할당받은 wcu 이상을 gsi에 할당해주기를 권장한다.

To avoid potential throttling, the provisioned write capacity for a global secondary index should be equal or greater than the write capacity of the base table because new updates write to both the base table and global secondary index.

결국 gsi가 사용하는 wcu는 최소 두 배가 되는데, 이는 인덱스 테이블에 데이터를 추가하기 위해 wcu를 할당하는것과 차이가 없다고 볼 수 있다.

배운점

scan operation 사용은 RCU를 지나치게 많이 사용할 수 있어 주의해야 한다.
GSI 생성에 시간이 오래걸리는것은 기존 데이터를 gsi로 migration 하기 때문이다.
Projected Attributes를 필요한 컬럼만 설정해 GSI에서 소모되는 WCU를 줄일 수 있다.

Reference

DynamoDB In 조건의 함정

eagle25 — Sun, 10 Mar 2024 19:17:27 +0900

문제 상황

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개까지만 지정할 수 있다는 것이다.

The maximum number of operands for the IN comparator is 100.

scan 로직은 아래처럼 작성되 있는데, values에 값이 101개가 지정되어 상기 에러가 발생했다.

filter_condition = Table1.attr1.is_in(values)

result = Table1.user_id_index.query(
    hash_key=viewer_id,
    range_key_condition=range_key_condition,
    filter_condition=filter_condition
)

해결

1. in 조건에 지정되는 값 줄이기

가장 근본적인 방법이라 할 수 있겠다. in 조건에 들어가는 데이터를 줄이면 error도 발생하지 않는다.

2. 안전장치 추가하기

로직상 100개가 넘는 상황이 발생할수도 있다. 이 경우 쿼리는 가능하도록 하되, warning log가 남도록 처리했다.

구체적인 로직은 아래처럼 값들을 100개씩 쪼개 in expression으로 만드는것이다. 그러면 100개 제한 조건을 우회할 수 있다.

values = (1... 400) --> where attr1 in (1 .. 100) or attr1 in (101..200) ...

in 조건 지정시에는 아래 코드처럼 특정한 메서드를 사용해 위 동작을 보장하게 하였다.

filter_condition = get_safe_in_expression(Table1.attr1, values)

result = Table1.user_id_index.query(
    hash_key=viewer_id,
    range_key_condition=range_key_condition,
    filter_condition=filter_condition
)

def get_safe_in_expression(attr: Attribute, values: tuple) -> Condition:
    """
    in expression에 100개 이상의 값을 지정하는 filter expression을 생성한다.
    
    @param attr: in expression 을 지정할 attribute
    @param values: in expression 에 포함될 값들
    @return: values의 개수에 따라 in expression을 여러개의 or expression으로 나누어서 반환
    """
    CHUNK_SIZE = 100

    chunks = [values[i : i + CHUNK_SIZE] for i in range(0, len(values), CHUNK_SIZE)]
    filter_expr: Condition = attr.is_in(*chunks[0])
    for chunk in chunks[1:]:
        filter_expr |= attr.is_in(*chunk)
    if len(chunks) > 0:
        logger.warning(f'[in_expression_warning]: values count exceeded 100. / actual values count: {len(values)}')
    return filter_expr

확인 해봐야 할 것

100개 제한을 Quota로 풀 수 있을까?

없다. AWS service quota console에서 확인해봤는데 in 조건과 관련된 내용은 없다.

성능에 영향 없을까?

AWS에서는 괜히 100개 제한을 걸지 않았을 것이다. DynamoDB의 latency나 throughput 성능에 어떤 영향이 있는지 측정해 보아야 한다. 필자는 성능 이슈로 제한을 걸었을 확률이 크다고 보는데, 진짜 성능 문제가 없는지 확인해봐야 할 필요가 있다.

+ 실험 내용 추가한다

실험 환경
- 1.5만개 데이터가 있는 dynamoDB 테이블
- 1000개 RCU 할당
실험 방법
- 특정 데이터를 full scan으로 찾는다.
- 이때, in 조건에 지정되는 값을 100개 지정하고 쿼리를 10회 수행하며 소요 시간을 기록한다.
- 값을 200개, 300개, 400개 추가하며 실행시간을 기록한다.
결과
- 아래 차트와 같이 성능이 측정되었다.
- in 조건에 value 갯수가 많이 추가되면 latency는 일부 증가하나, 치명적인 수준은 아님을 알 수 있다.

python itertools.gropuby() 의 함정

eagle25 — Fri, 8 Mar 2024 19:44:44 +0900

이번 글에서는 itertools.groupby 메서드의 함정에 대해 소개하고자 한다. python 에서 itertools를 사용한다면 이 글을 자세히 보는것을 추천한다.

결론부터 말하자면 itertools.groupby를 쓸 땐, 정렬된 컬렉션을 사용해야 한다. 그렇지 않으면 집계 결과가 잘못될 수 있다. itertools.groupby는 흔히 아는 sql의 groupby처럼 동작하지 않기 때문이다.

배경

itertools.groupby()를 사용하는 로직에서 groupby만 하면 DB에서 가져온 값 일부가 사라지는 문제가 있었다. 원인을 파악하며 함정이 있는것을 알게 되었다.

사전 지식

Itertools
- 파이썬 라이브러리로, 효율적인 알고리즘을 사용해 컬렉션 데이터를 원하는 형태의 iterator를 만들어 주는 역할을 한다.

상황

아래처럼 sample_data가 주어졌을 때, groupby를 하면 어떤 결과가 나올까?

import itertools

sample_data = ["A", "A", "B", "C", "A"]
aggr_data = {k: len(list(v)) for k, v in itertools.groupby(sample_data, key=lambda x: x)}

print(aggr_data)

결론부터 말하면, 아래와 같은 결과가 나오게 된다.

{'A': 1, 'B': 1, 'C': 1}

이상하다. 흔히 알고있는 groupby의 동작(sql의 groupby)이라면 아래와 같은 결과가 나와야 한다.

{'A': 3, 'B': 1, 'C': 1}

즉 gropuby를 사용하면서 A의 값이 제대로 집계되지 않은 것이다.

원인 분석

공식 문서 조사

itertools의 공식 문서에 groupby()에는 다음과 같은 내용이 있다.

The operation of groupby() is similar to the uniq filter in Unix. It generates a break or new group every time the value of the key function changes (which is why it is usually necessary to have sorted the data using the same key function). That behavior differs from SQL’s GROUP BY which aggregates common elements regardless of their input order.

간단하게 내용을 요약해보면 다음과 같다.

sql의 group by와 다르게 동작한다.
key가 바뀔때마다 key에 대한 집계를 처음부터 새로 시작한다.

문제 상기

현재 겪고 있는 문제를 다시 상기시켜보자.

["A", "A", "B", "C", "A"] 컬렉션이 주어졌을 때, itertools로 groupby를 하면 기대한대로값이 이 나오지 않는 문제가 있다.
기대한 결과: {'A': 3, 'B': 1, 'C': 1}
실제 결과: ({'A': 1, 'B': 1, 'C': 1})

실험

주어진 컬랙션은 정렬되지 않은 상태이다. itertools.groupby는 key 가 바뀔때마다 해당 그룹의 집계를 처음부터 다시한다.

It generates a break or new group every time the value of the key function changes (which is why it is usually necessary to have sorted the data using the same key function).

그렇다면 정렬된 값을 주어졌을때는 어떻게 될까? 기대한 값을 반환할 것이라는 가설을 세우고 검증해보겠다.

import itertools

sample_data = ["A", "A", "A", "B", "C"]
aggr_data = {k: len(list(v)) for k, v in itertools.groupby(sample_data, key=lambda x: x)}

print(aggr_data)

상기 코드의 실행 결과는 다음과 같다. 정렬된 컬렉션을 groupby하면 기대한대로 결과가 나오고 있음이 검증되었다.

{'A': 3, 'B': 1, 'C': 1}

결론

정렬된 컬렉션을 제공했을 때 itertools.groupby() 값을 누락없이 집계함을 확인할 수 있었다. 반대로 정렬되지 않은 값은, 집계가 잘못 되는 문제가 있었다. 따라서 itertools.groupby를 사용할땐 정렬된 컬렉션을 사용해야 한다.

itertools.groupby()의 대안

itertools.groupby()를 꼭 사용할 필요가 없다면, defaultdict를 활용해 groupby를 구현하자. 가장 성능이 좋은 방법이다.

from collections import defaultdict

sample_data = ["A", "A", "B", "C", "A"]

aggr_data = defaultdict(str)
for key in sample_data.items():
    aggr_data[key] = value
    
print(aggr_data)

defaultdict를 사용했을 때 성능이 얼마나 좋은걸까? itertools, defaultdict, pure python dict 3가지 로직의 실행 속도를 비교해보았다.

input 데이터는 아래처럼 A, B, C, D, E 알파벳들을 백만개씩 나열한 컬렉션이다. python3.10에서 이 데이터를 groupby 하는데 걸린 시간을 측정해 보았다.

values = ["A", "B", "C", "D", "E"] 
sample_data = [random.choice(values) for _ in range(1000000)]

실행 결과는 다음과 같다. defaultdict가 제일 빠른 성능을 보여주고 python pure dict, itertools 가 그 뒤를 잇는다.

횟수	python pure dict	defaultdict	itertools.groupby()
1	51.35	41.82	119.90
2	51.02	41.68	116.09
3	53.89	44.19	118.97
4	61.94	51.73	116.92
5	57.28	47.96	117.18
평균	56.03 ms	45.47 ms	117.81 ms

실험에 사용한 코드는 다음과 같다.

import itertools
import random
from collections import defaultdict
import time


values = ["A", "B", "C", "D", "E"] 
sample_data = [random.choice(values) for _ in range(1000000)]

def measure_execution_time(method):
    def wrapper(*args, **kwargs):
        start_time = time.time()
        result = method(*args, **kwargs)
        end_time = time.time()
        print(f"{(end_time - start_time) * 1000:.3f}  ms")
        return result
    return wrapper

@measure_execution_time
def groupby_pure_python_dict(values):
    aggr_data = {}
    for key in values:
        aggr_data[key] = aggr_data.get(key, 0) + 1
    return aggr_data
    
@measure_execution_time
def groupby_defaultdict(values):
    aggr_data = defaultdict(int)
    for key in values:
        aggr_data[key] +=1
    return aggr_data

@measure_execution_time
def groupby_itertools(values):
    values = sorted(values)
    return {k: len(list(v)) for k, v in itertools.groupby(values, key=lambda x: x)}


_ = groupby_pure_python_dict(sample_data)
_ = groupby_defaultdict(sample_data)
_ = groupby_itertools(sample_data)

DB locking 낙관적 vs 비관적

eagle25 — Tue, 5 Mar 2024 14:04:41 +0900

DB locking은 DB의 동시성 제어 기법 중 하나이다. 다수의 사용자나 프로세스가 DB에 동시에 접근해 데이터를 읽거나 쓰면서 발생할 수 있는 충돌을 방지해 데이터의 무결성을 보장하는 기법이다.

이번 글에서는 DB locking의 기법 중 optimistic locking과 pessimistic locking에 대해 다루어 보고자 한다.

Optimistic locking

DB에서 데이터를 읽거나 수정할 때 lock을 점유하지 않는 기법이다.

특징

Optimistic locking이 적용된 app은 데이터의 수정 / 삭제 작업을 시도할 때 원본 데이터의 변경이 없을 것이라고 가정한다. 만약 원본 데이터에 변경이 발생한 경우 수정/삭제 작업은 실패하게 된다. 이 경우 app logic에서 fail에 대한 핸들링을 해 주어야 한다. (예, Retry; 원본 데이터 다시 읽은 후 작업 재시도)

장점

동시성이 향상(동시에 처리할 수 있는 작업이 많아진다)된다.

단점

그러나 다음과 같은 단점을 수반하기도 한다.

Fail handling 로직 추가로 인해 application code의 복잡성 증가 여지 있음
거짓 부정 혹은 거짓 긍정 문제 발생 가능성 있음.
- 거짓 부정: 데이터가 변경되지 않았지만, 업데이트 시도가 거부되는 현상
- 거짓 긍정: 데이터가 변경되었지만 이를 감지하지 못해 잘못된 데이터가 업데이트 되는 현상

적합한 사용 예

동시성 성능 중요한 대규모 시스템
session 내에서 connection을 유지할 필요가 없는 경우

Pessimistic locking

optimistic locking과 상반되는 개념으로, 충돌이 예상되는 데이터에 미리 접근을 제한하는 기법이다.

특징

트랜잭션이 시작될 때 미리 lock(shared or exclusive)을 hold해 접근을 제한하고 수정 / 삭제 등의 작업을 수행한다. 작업이 완료되면 lock을 해제한다. 트랜잭션을 유지해야 하기 때문에

장점

데이터의 일관성과 무결성을 확실히 보장한다.

단점

데드락 발생 가능성이 있다.

동시 처리 시스템의 성능 저하 원인이 될 수 있다.

적합한 사용 예

은행 시스템과 같이 데이터 무결성이 중요한 환경.

CloudFront의 점진적 배포를 위한 Continuous Deployment

eagle25 — Tue, 27 Feb 2024 00:17:15 +0900

Continous Deployment

이 기능을 통해 우리는 staging distribution CF에 변경된 config을 적용하고, 일부 트래픽만 흘려보내 변경 이후에도 CF가 정상적으로 동작하는지 검증할 수 있다.

continuous deployment의 하위 개념은 2개 정도가 있다. (아래 사진은 AWS 문서에서 발췌했다.)

Continuous deployment policy
Staging distribution

Continuous deployment policy

primary로 들어오는 traffic을 어떻게 staging distribution으로 얼마나 흘려보낼지 결정하는 역할을 한다.

Staging distribution

policy에 의해 받게되는 primary traffic 일부를 처리하는 CF이다. 이 CF에 변경된 설정을 먼저 적용하고 조금의 트래픽을 흘려보내 정상 여부를 검증한다.

Continuous deployment policy

앞서 이 개념(이하 policy로 명명)은 traffic을 어떻게 얼마나 staging distribution으로 흘려보낼지 설정하는 정책이라고 설명했다.

그렇다면 먼저, traffic을 어떻게 분리할 수 있는지 살펴보겠다. policy에는 두 가지 type이 있다.

Weight based
Header based

Weight based type

전체 트래픽의 n%를 staging distribution으로 보내는 옵션이다.

AWS 콘솔의 설정창을 보면 몇 %의 트래픽을 보낼지 입력받는 weight 항목이 있다. 이 weight는 0 ~ 15%까지 설정할 수 있다.

session stickiness도 설정할 수 있다.

Header based type

CloudFront에 HTTP요청을 보낼 때, 미리 지정한 헤더의 key와 value를 보내면 staging distribution으로 트래픽을 보내준다.

header의 key는 aws-cf-cd 로 시작해야 하며, 반드시 영문자 1글자 이상을 포함해야 한다. value는 자유롭게 지정하면 된다.

왼쪽 사진처럼 header based policy를 설정했다면 http 요청시

헤더에 aws-cf-cd-xxxxx: 123을 보내면 staging distribution 으로 트래픽이 가게 된다.

목적을 다한 staging distribution의 후처리 (feat. promotion)

staging distribution은 변경된 config을 일부 traffic에만 적용해 안전성을 검증하는데 사용한다고 소개했다. 그렇다면 안전성이 검증된 이후 staging distribution은 어떻게 해야할까?

staging distribution 의 변경된 설정을 그대로 primary로 적용하고자 할 경우 promote를 하면된다. 아니라면 그냥 지우는 방법도 있다.

Disable
Promotio

Staging distribution 생성 시 콘솔에서 보이는 모습

1. 생성 안 했을 때

2. 생성했을때 (Weight type, header type도 비슷하다)

3. staging distribution을 생성하면 Type이 Staging인 CF가 한 개 더 생긴다.

주의사항

staging distribution을 사용할 때 아래 3 가지 사항을 고려해야 한다.

쿼타(사용량)에 제한이 있다.

계정당 최대 20개 이하로 staging distribution, continous deployment policy 만들 수 있다.
weight based의 최대값은 15%이다.
session stickiness idle duration: 300–3600 seconds

HTTP3 사용 지원하지 않음

staging distribution만 지원하지 않는다.

AWS 사정에 따라 Staging Distribution으로 요청이 가지 않을수도 있다

특정한 경우 staging distribution으로 트래픽이 가지 않을 수 있다. 대표적인 예로 트래픽 스파이크 상황이 있다.

AWS측 CloudFront의 리소스 사용량이 일정 수준 이상으로 튀면 모든 트래픽을 primary로 보내게 된다. 중요한 내용이므로 문서의 내용을 인용한다.

Cases when CloudFront sends all requests to the primary distribution

In certain cases, such as periods of high resource utilization, CloudFront might send all requests to the primary distribution regardless of what's specified in the continuous deployment policy.
CloudFront sends all requests to the primary distribution during peak traffic hours, regardless of what's specified in the continuous deployment policy. Peak traffic refers to the traffic on the CloudFront service, and not the traffic on your distribution.

Staging distribution 및 policy에 쿼타 제한을 둔 점, AWS CF의 리소스 상황에 따라 primary로만 트래픽을 보네는 정책이 있는 점을 미루어 봤을 때 staging distribution 기능을 운영하는데 필요한 리소스가 무시하기 어려운 수준이라고 추정된다.

CloudFront 안전하게 변경하기 #2, (Staging Distribution)

eagle25 — Tue, 27 Feb 2024 00:17:08 +0900

개요

이번 글에서는 기존 버킷에 있던 파일들이 새로운 버킷에 모두 있는지 검증하는 과정에 대해 소개하고자 한다.

이 단계는 새로운 버킷으로 전체 트래픽을 옮기기 전 선행되어야 한다. 새로운 버킷으로 migration이 누락된 파일이 있을 경우, 해당 리소스를 요청하는 모든 client는 에러를 경험하게 될 것이고, 이는 서비스 장애에 준하는 상황으로 이어질 수 있다.

필자는 staging distribution 기능을 활용해 새로운 버킷으로만 전체 트래픽의 5% 요청을 보내보고, Popular Object 기능을 활용해 4xx, 5xx 관련 에러가 발생하지 않았는지 모니터링을 진행 했다. 그리고 이 과정에 대해 상세하게 다뤄보고자 한다.

현재 상태

이전 글에서 진행한 작업 덕분에 아래와 같은 상태가 되었다.

CF에 새로운 버킷이 추가되었다.
새로운 버킷에서 파일을 읽을 수 있는 상태이다. (권한 문제 등 이슈 없음)

작업 목표

작업 목표를 다시한번 정의해보자. 이번 단계의 작업 목표는 기존 버킷에 있던 파일이 모두 새로운 버킷에도 있는지 검증하는 것이다.

작업 방향

전체 트래픽의 5% 요청을 새로운 버킷으로 보내본다. <-- continous deployment (Staging Distribution) 기능 활용
5% 요청 중 4xx, 5xx 에러가 발생한 요청이 있는지 확인한다. <-- Popular Object 기능 활용

Continous Deployment

continous deployment를 사용하면 CF의 변경을 안전하게 적용할 수 있다. 이 기능의 핵심 원리는 트래픽 분리인데, 원래 CF와 동일한 CF를 새로 만들고 여기에 일부 트래픽을 보내는 것이다. 이때 새로 만들어진 CF가 바로 staging distribtuion이 된다. (원래 CF는 primary distribution이 된다.) 이 기능을 통해 우리는 staging distribution CF에 변경된 config을 적용하고, 일부 트래픽만 흘려보내 변경 이후에도 CF가 정상적으로 동작하는지 검증할 수 있다. 보다 자세한 내용은 이 글을 참조하자.

Popular Object

이 기능을 통해 CF에 발생한 요청별 횟수, cache miss / hit, 2xx, 4xx, 5xx 횟수 등의 집계 정보를 얻을 수 있다. 이를 통해 staging distribution에 발생한 트래픽을 모니터링하면서 서빙에 문제 없는지 4xx, 5xx 에러의 비율 모니터링을 통해 검증하고자 한다.

아래는 Popular objects의 실제 모습이다. /image.png 요청은 7일동안 99번 발생했는데 4xx 응답코드가 52번 나갔다. 즉 서빙이 원활하지 않았음을 확인할 수 있다. 마찬가지로 staging distribution을 이 기능으로 모니터링 했을 때, 4xx or 5xx 발생 비율이 높다면 정상적으로 서빙되지 않거나, 혹은 버킷에 파일이 누락되어있음을 찾을 수 있다. 보다 자세한 내용은 이 문서 를 참조하도록 하자.

Popular Object 기능은 콘솔 좌측 탭에서 Reports & analytics 에서 찾을 수 있다.

CloudFront 안전하게 변경하기 #1, (CacheBehavior)

eagle25 — Sun, 25 Feb 2024 17:14:54 +0900

개요

이 글에서는 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 CloudFront to get objects.

간략하게 요약해 보자면, Cache Behavior는 CloudFront가 각 요청별로 리소스를 어떤 origin에서 가져올지를 설정하는 기능인 것이라 할 수 있다. 물론 이름이 Cache Behavior만큼 캐싱과 관련된 기능도 있지만, 이번 편의 핵심은 요청별로 origin을 다르게 사용하는, 즉 routing과 관련되어 있기 때문에 해당 내용은 생략한다.

작업 목표

이번편의 목표는 CloudFont가 새로운 버킷에서 파일을 읽을 수 있는 상태인지 검증하는 것이다.

아래처럼 버킷을 바로 변경해버릴 경우, CF의 서빙에 문제가 발생될 수 있다. 이는 전체 장애로 이어지게 된다. 따라서, 새로운 버킷에서 파일을 잘 읽을 수 있는지 확인해야 한다.

작업 과정

선행 작업

1. CloudFront의 origin에 새로운 버킷을 추가한다. AWS 문서에 따르면, 단순히 버킷만 추가하는것은 기존 동작에 영향을 주지 않는다고 한다.

If you have two origins and only the default cache behavior, the default cache behavior will cause CloudFront to get objects from one of the origins, but the other origin is never used.

2. Legacy 버킷에 있는 파일 중, 서빙이 되지 않아도 문제 없는 파일을 1개 선택하고 새로운 버킷으로 복사한다. 필자는 예시로 /image.png(아무런 의미도 없는 파일) 를 사용했다

Cache Beavior 추가

앞서 Cache Behavior는 CloudFront가 각 요청별로 리소스를 어떤 origin에서 가져올지를 설정하는 기능이라고 소개했다.

이제, 추가된 버킷에서 CF가 파일을 읽을 수 있도록 behavior를 추가해야 한다.

유의사항
Cache Behavior를 추가할 때, 경로 설정에 유의해야 한다. 아직 새로운 버킷을 사용해도 문제 없는지 확실하지 않은 상태이다. 따라서 파일 한 개에 대해서만 새로운 버킷을 사용하도록 해야 점진적 변경이 가능하다. 이 파일은 읽기를 실패해도 문제 없는 만만만한 파일을 사용하면 된다. (예, 위에서 언급한 /image.png)

Behavior 추가하기
CloudFront Behavior는 기본적으로 아래처럼 설정되어 있다.

Create Behavior를 눌러 Behavior를 생성한다. 이 Behavior는 /image.png 요청은 새로운 버킷에서 가저오도록 설정하는 역할을 한다. Cache나 기타 설정은 본인 필요에 따라 자유롭게 설정하자.

Behavior 생성을 완료하면 /image.png의 priority가 0인것을 확인할 수 있다. 즉 우선순위가 제일 높다는 것이다.

작업 결과

Cache Behavior까지 설정이 완료되었다면, 이제 CloudFront는 어떻게 동작하는지 다이어그램을 통해 설명해보겠다.

아래 다이어그램에서 CF는 New, Legacy 총 두 개의 S3 origin을 가진다. Cache Behavior의 경우, /image.png는 new 버킷에서, 그 외 파일은 legacy 버킷에서 파일을 읽도록 셋팅되어 있다.

/image.png 패턴의 우선순위가 가장 높고, 해당 요청은 new 버킷에서 파일을 읽는다.

/image.png 외 다른 요청은 * 패턴과 매칭되기 때문에 Legacy 버킷에서 파일을 읽는다.

검증

새로운 버킷에서 파일을 읽는것이 문제 없는지 검증해 보겠다. 먼저 CF에서 /iamge.png 파일 읽기에 문제가 없다면, Legacy 버킷에서 /image.png를 지워본다. 파일을 지운 이후에도, /image.png 파일 읽기에 성공한다면 New 버킷에서 파일을 읽을 수 있는 상태가 된 것이다.

마무리

이번 편에서는 Cloud Front의 Cache Behavior가 어떤 역할을 하는지 살펴 보았다. 이를 응용해 새로 추가된 s3에서 CF가 파일을 잘 읽어올 수 있는지 검증까지 진행했다.

다음 편에서는 새로운 버킷에서 전체 요청을 처리도록 하기 전, 기존 버킷에 있던 파일이 새로운 파일에 모두 있었는지 검증하도록 하겠다.

CloudFront 안전하게 변경하기 #0, (에필로그)

eagle25 — Sun, 25 Feb 2024 17:01:31 +0900

에필로그

필자는 최근에 CF에서 S3를 안젼하게 교체하는 작업을 진행했다.

작업시 아래와 같은 고려사항이 있었고, 각 작업별 사용한 CF의 기능들에 대해 두 편에 나눠 소개하고자 한다.

작업 목표

필자는 CF가 사용하는 origin 버킷을 legacy에서 new로 변경해야 했다. 한번에 버킷을 바꾸는 것은 리스크가 있기에, Cache Behavior와 Staging Distribution을 사용했다.

기존

변경

논외지만, 버킷을 바꾸는 배경은 간략히 소개하자면 다음과 같다.

dev / prod 파일이 한 개의 버킷에서 관리되고 있었음. 작업자 실수로 인해 prod 파일에 문제가 생긴 사례가 있었고, dev / prod 버킷 분리가 필요해짐.
서비스 공용 버킷이 있으나, 해당 CF 는 다른 버킷을 사용하고 있었음. 서비스 파편화를 줄이기 위해 공용 버킷을 사용하도록 해야했음.

DynamoDB 응답 지연 시간 최소화 하기

eagle25 — Tue, 20 Feb 2024 00:30:59 +0900

최근 면접 질문에서 DynamoDB의 응답 시간을 최소화 할 수 있는 방법에 대해 질문을 받았다. 나는 consistency 수준을 낮추는 것 외에 다른 방법에 대해서는 답변하지 못 했다. 다음번에 같은 상황이 오지 않도록 복기해보고자 한다.

방법을 찾아보던 중, AWS에서 작성한 문서가 내용이 좋아서 가져왔다. 문서에서는 Latency를 줄일 수 있는 여러가지 방법을 제시하고 있다.

1. Adjust request timeout and retry behavior

AWS SDK는 network resiliency, tcp packet timeout 등의 상황에 대비하기 위해 retry와 timeout이 적절한 균형을 이루도록 설정되어 있다.

다만, 최소 latency가 주 고려사항이라면 SDK의 timeout, retry 동작에 대한 조정이 필요하다.

조정은 클라이언트들이 일반적으로 겪는 latency를 기준으로 맞추면 된다. 평소보다 오래걸리는 request는 fail했을 확률이 높기 때문에, 실패로 처리하고 새로운 요청으로 fail fast 하는것이 결과적으로 latency를 줄일 수 있다.

2. Client와 DynamoDB간의 거리 최소화

network trip time 또한 latency에 포함된다. client와 dynamo의 endpoint간 물리적 거리가 길어질수록 network triptime 증가로 이어진다.

글로벌 트래픽이 발생하는 환경이라면, 물리적 거리로 인한 latency를 줄이기 위해 두 가지 전략을 사용할 수 있다.

방법	특징
Global Table	multi region replication 통해 client가 local region의 replication table에서 데이터 읽으면 응답 지연 시간이 크게 감소한다. 활성화할 region은 따로 선택 가능
gateway VPC Endpoint	VPC Endpoint를 활용해 서비스와 dynamoDB 데이터 교환이 AWS 내부망에서 이루어지도록 할 수 있다. IGW 통해 트래픽 이동하는 것 대비 물리적 trip 거리가 감소하여 latency 감소 기대 가능함.

3. 캐시 사용

읽기 요청이 heavy하게 발생한다면 cache를 두는것도 좋다. DAX나 Redis등의 In-Memory cache를 적극 사용하자.

문서에서는 DAX를 사용할 경우, 최대 10배 이상의 성능 향상을 기대할 수 있다고 소개하고 있다.

4. 커넥션 재활용

DDB 요청은 기본적으로 HTTPS 통신에서 세션이 만들어진다. http connection 초기화 과정은 latency가 많이 발생한다. 그래서 일반적으로 첫번째 커넥션의 지연시간이 가장 크다.

따라서 새로운 커낵션을 매 번 만들기보다, 기존 커넥션을 잘 활용하는 것이 좋다. 커넥션이 항상 alive 하도록 유지하기 위해 30초마다 GetItem 등의 요청을 보낼 수 있다. 그러나 코드 복잡성을 야기할 수 있기 때문에 사용 전 고민해보는것이 좋다.

5. Use eventually consistent read

application이 strongly consistent reads를 요구하지 않는다면 eventually consistent 수준의 read를 사용하자.

eventually consistent read의 장점

1. 저렴한 비용

2. 일시적인 latency 증가를 경험할 가능성이 더 낮다.

Eagle’s dev insights

커뮤니케이션을 줄이는 코드리뷰 팁 6가지

목차

1. PR은 한 가지 목적만 포함하라: 리뷰어의 혼란 방지

2. 부연 설명을 미리 남겨라: 핑퐁 최소화

3. QnA 포맷으로 설명하라: 장황한 줄글은 그만

4. 테스트로 동작을 설명하라

5. 기존 로직을 재활용하라

6. 사소한 문제를 피하라: 발목 잡히지 말라

마치며

정리

DynamoDB 성능 문제 빠르게 해결하기

상황

문제 원인

해결책

고려사항

배운점

Reference

DynamoDB In 조건의 함정

문제 상황

해결

1. in 조건에 지정되는 값 줄이기

2. 안전장치 추가하기

확인 해봐야 할 것

python itertools.gropuby() 의 함정

배경

사전 지식

상황

원인 분석

결론

itertools.groupby()의 대안

DB locking 낙관적 vs 비관적

Optimistic locking

Pessimistic locking

CloudFront의 점진적 배포를 위한 Continuous Deployment

Continous Deployment

Continuous deployment policy

목적을 다한 staging distribution의 후처리 (feat. promotion)

Staging distribution 생성 시 콘솔에서 보이는 모습

주의사항

CloudFront 안전하게 변경하기 #2, (Staging Distribution)

개요

현재 상태

작업 목표

작업 방향

Continous Deployment

Popular Object

CloudFront 안전하게 변경하기 #1, (CacheBehavior)

개요

CacheBehavior

작업 목표

작업 과정

선행 작업

Cache Beavior 추가

작업 결과

검증

마무리

CloudFront 안전하게 변경하기 #0, (에필로그)

에필로그

작업 목표

DynamoDB 응답 지연 시간 최소화 하기

1. Adjust request timeout and retry behavior

2. Client와 DynamoDB간의 거리 최소화

3. 캐시 사용

4. 커넥션 재활용

5. Use eventually consistent read