개요

왜 사람들은 PGO(Profile Guided Optimization)을 적극적으로 사용하지 않을까?

저는 이 의문을 예전부터 품고 있었습니다. 생각해보니 프로파일을 저장하고, 가져오는 어떠한 표준화된 프로토콜이 없다는 게 이유로 보였습니다. 사실 쓸 사람들은 어떻게든 쓰고 있겠지만, 저도 처음 PGO를 적용할 때에 어떻게 저장하고 가져와야 할지 고민을 좀 했었습니다. 그래서 이번 글에선 해당 내용에 대한 공유를 하겠습니다.

설계 및 구현

전형적인 읽는 사람 따로, 쓰는 사람 따로인 구조

PGO 특성 상, 프로파일을 주기적으로 생성하고 업로드하는 실제 서비스로 올라간 어플리케이션과, 해당 프로파일들을 받아서 하나로 합치고 빌드할 때 적용하는 빌드 어플리케이션이 있습니다. 두 과정이 철저하게 분리되어 있기에 동기적으로 사고할 필요가 없습니다. 그럼 가장 적합한 구조는 중간에 버퍼나 저장소를 두고 계속 데이터를 추가, 필요할 때 다운로드, 주기적으로 데이터를 삭제하는 과정만 있으면 됩니다.

?

대는 소를 포함한다는 말은 법률상으로 상위 개념과 하위 개념이 존재할 경우, 상위 개념에 대한 법을 하위 개념에도 적용하는 것입니다. 쉽게 이야기하면, 법률적으로는 자전거가 자동차의 하위 개념이니 자동차에 적용하는 다양한 법을 자전거에도 같이 적용하는 것입니다. 하지만 제가 법률 전문가도 아니고, 법과 관련된 이야기를 하고 싶은 건 아닙니다.

소프트웨어 설계에서

범용은 전용을 포함한다

저희는 때때로 범용으로 무언가를 만들고, 전용으로 사용하는 방법을 취합니다. 대표적인 예로 postgres는 많은 데이터를 저장하고 쿼리할 수 있지만, 저희는 스키마를 한정해서 한정적인 데이터 형태를 저장하고 활용합니다. MongoDB같은 경우엔 그렇지 않다구요? 하지만 높은 확률로 로직이나 환경적으로 들어갈 자료, 해야할 쿼리는 정해져 있을 겁니다. 그게 정녕 비정형 JSON을 저장하기 위한 data lake라 할 지라도요. 그리고 그를 위한 별도 모듈이 존재할 것입니다.

배경

NATS는 정말 아름다워

NATS는 Go 언어로 작성된 메시지큐입니다. 그리고 제가 개인적으로 좋아하는 오픈소스 프로젝트이기도 합니다. 한때 NATS에서 서브스크립션이 메시지를 받는 방식이 단순 채널이 아닌 독특한 자료구조가 따로 있는 걸 봤었던 적이 있습니다. 이 자료구조는 연결리스트를 통해 특정 서브스크립션에 전달될 메시지를 저장합니다. 그리고 sync.Cond를 이용하여 별도의 대기 중인 서브스크립션을 위한 고루틴에게 알려줍니다.

1. 서브스크립션은 생성될 때, 별도 고루틴에서 sync.Cond의 Wait() 메서드를 통해 메시지가 추가되길 대기합니다.
2. 커넥션은 외부 연결을 통해 서브스크립션에 대한 메시지를 받아옵니다.
3. 커넥션은 해당 서브스크립션의 연결리스트에 메시지를 추가하고, sync.Cond의 Signal() 메서드로 해당 고루틴을 깨웁니다.
4. 서브스크립션은 연결리스트를 순회해서 메시지를 읽어 처리합니다.

쓰는 사람 따로, 읽는 사람 따로

이 구조는 쓰는 주체가 가지는 상태와 읽는 주체가 가지는 상태가 별도로 존재한다는 것에 의의를 느꼈습니다. 물론 channel도 버퍼를 주게 되면 상태를 따로 가질 수 있습니다만, 기본적으로 내부에서 락을 가지는 구조이며 반쯤 동기식으로 동작하도록 코드가 작성됩니다. 그리고 무엇보다 채널은 팬아웃(fan out)에 적합한 구조가 아닙니다.

메락아, 그게 무슨 소리니?

아니 일단 들어봐

서비스가 되었든, 소프트웨어가 되었든, 어떤 프로젝트에 대해 보통 기업은 신기술에 밝거나, 손이 빠르거나, 임원의 말을 잘 듣는 사람에게 첫 스타트를 시키는 경우가 많습니다. 하지만 단순히 그렇게 되어서는 서비스나 소프트웨어의 수명이 줄어들어서, 유지보수 비용의 증가 뿐만 아니라 해당 프로젝트를 대체할 새로운 프로젝트를 해야할 수 있어, 큰 지출로 다시 돌아올 수 있습니다.

그래서?

만약 아키텍트가 시작할 때, 어떠한 철학이나 체계 없이 주먹구구로 프로젝트를 진행하면 어떤 일이 벌어질까요?

이것 또한 최근 포스트와 마찬가지로, 최근에 진행했던 프로젝트의 회고입니다.

개요

해당 프로젝트에는 개인적으로 몇가지 이해가 어려운 부분들이 좀 있었습니다. 그 중 R&R에 대해 제가 품은 의문과 그에 대한 제 나름의 해결 방법을 서술하고자 합니다.

본문

어떤 부분이?

1. API GW와 서비스만 책임 분리
2. API GW와 인증 및 인가 책임
3. 각 서비스 간의 역할과 책임 분리

API GW와 서비스간의 책임 분리에 대해

설계 당시부터 지금까지 모든 서비스는 k8s에 pod로써 운영되고 있습니다. 대략적으로 네트워크 요청 트래픽은 ingress -> API GW -> each service로 흐릅니다. 이 중 API GW는 솔루션이 아니라 자사에서 내부적으로 만든 것입니다. 기능으론 일반적인 API GW와 유사하게 요청에 대해 특정 서비스로의 라우팅과 요청에 대한 인증 토큰 검증 등이 있습니다. 그리고 각 서비스는 특정 데이터를 다루는 서비스와 저장하는 DB를 세트로 구성됩니다. 제가 보는 문제는 이 구조로 인해 생성되는 gray zone이 있습니다.

개요

이전 포스팅과 동일한 프로젝트에 대한 회고를 내용으로 합니다. 이 포스트에선 비교적 안일하게 생각했던 라이프타임에 대해 생각했던 걸 적어보려합니다. 여기서 말하는 라이프타임은 객체의 라이프사이클, 캐시 수명, 요청의 타임아웃 등을 포함하는 어떤 것의 발생과 소멸까지의 시간을 의미합니다.

뭐가 문제였지?

대부분의 라이프타임 관리는 괜찮게 했습니다. 하지만 몇몇 경우에 대해서 시스템을 맹신한 나머지 안일하게 관리를 했고, 관련 부분에 대한 내용이 주가 될 것같습니다.

본문

해당 프로젝트가 Go로 구현된 만큼 context 패키지를 주로 활용하였고, context 패키지에 대해 처음 보신다면, 제가 이전에 작성한 포스트를 같이 읽으시면 좋아 보입니다.

개요

최근 그래도 규모가 조금 있는 프로젝트를 처음부터 설계하고, 구현 및 운영한 경험이 생겼습니다. 상당히 많은 부분에서 하고 싶은 걸 했고, 부족한 점을 느끼기고 했고, 발전했다고 생각합니다. 하지만 안타깝게도, 기반 시스템(혹은 라이브러리)에 대해서 조직 내에서도 명확히 어떻게 해왔다는 게 없었어서 상당히 아쉬운 결과를 낳게 되었습니다. 지금에 와서 매우 많은 부분에 스며들어 있어서 일일이 교체하기에도 비용이 큰 작업이 되었구요. 그 중 하나가 로그입니다.

뭐가 문제?

해당 프로젝트의 로그 라이브러리는 zerolog를 사용하고 있습니다. 그리고 필요한 곳에서, 물론 실제 코드와는 다르지만, 단순하게 log.Error().Str("error", err).Str("ip", ip).Int("port", port).Msg("not expected connection closed")처럼 그 자리에서 필요한 필드를 넣고 로그를 남기는 형태입니다.
그리고 이벤트 로그에 대한 개념도 필요했습니다. 저에게 이벤트 로그에 대한 개념이 부족 했던 것도 있지만, 과연 ‘모든 행동에 로그를 찍는 것이, 이벤트 로그를 작성하는 바람직한 방식인가’에 대해서 고찰의 시간이 필요했습니다.

Liskov Substitution Principle with inheritance

리스코프 치환 법칙은 객체지향 프로그래밍에서 중요한 법칙 중 하나입니다.

서브 타입은 언제나 슈퍼 타입으로 대체될 수 있어야 한다.

개인적으로는 살짝 헷갈린 적이 있는 표현이지만, 코드 내의 인스턴스 타입을 교체하는 케이스로 이해하면 쉽습니다.

상속을 활용한 케이스

이 법칙은 일반적인 상속이 존재하는 객체지향 지향 언어에서 쉽게 설명되는 법칙입니다.
예를 들어 보통 자바에선 이런 식으로 많이 예제를 작성합니다.

class Shape {
    int width;
    int height;
}

class Rectangle extends Shape {
    void setWidth(int width) {
        this.width = width;
    }

    void setHeight(int height) {
        this.height = height;
    }
}

class Square extends Shape {
    void setWidth(int width) {
        this.width = width;
        this.height = width;
    }

    void setHeight(int height) {
        this.width = height;
        this.height = height;
    }
}

위 코드에서 Rectangle과 Square는 Shape를 상속받고 있습니다.
그리고 Square와 Rectangle을 주고 받을 수 있는 곳은 Shape로 대체할 수 있습니다.
그리고 상속받은 객체를 다음과 같이 수퍼 타입으로 받을 수 있습니다.