문제 이해 및 설계 범위 확정

• 키-값 쌍의 크기는 10KB 이하이다.

  10KB = 10000 Byte
  UTF-8 인코딩: 14바이트/문자 → 2,50010,000자

• 큰 데이터를 저장할 수 있어야 한다.
• 높은 가용성을 제공해야 한다. 따라서 시스템은 설사 장애가 있더라도 빨리 응답해야 한다.
• 높은 규모 확장성을 제공해야 한다. 따라서 트래픽 양에 따라 자동적으로 서버 증설/삭제가 이루어져야 한다.
• 데이터 일관성 수준은 조정이 가능해야 한다.
• 응답 지연시간이 짧아야 한다.

단일 서버 키-값 저장소

• 한 대 서버만 사용하는 키-값 저장소 설계로 가장 직관적인 방법은 키-값 쌍 전부를 메모리에 해시 테이블로 저장하는 것이다.
  • 이는 빠른 속도를 보장하기는 하지만 모든 데이터를 메모리 안에 두는 것이 불가능할 수도 있다
• 해결책으로는 1) 데이터 압축 / 2) 자주 쓰이는 데이터만 메모리에 두고 나머지는 디스크에 저장

  ✅ 데이터 압축

  • 압축 알고리즘 적용: LZF, LZ4, Zstandard 등 고속 압축 알고리즘을 사용하여 데이터 크기 감소

분산 키-값 저장소

CAP정리

• 데이터 일관성 (Consistency), 가용성 (Availability), 파티션 감내 (Partition Tolerance) 라는 세 가지 요구사항을 동시에 만족하는 분산 시스템을 설계하는 것은 불가능하다는 정리
• 데이터 일관성
  • 분산 시스템에 접속하는 모든 클라이언트는 어떤 노드에 접속했느냐와 관계 없이 언제나 같은 데이터를 보게 되어야 한다.
• 가용성
  • 분산 시스템에 접속하는 클라이언트는 일부 노드에 장애가 발생하더라도 항상 응답을 받을 수 있어야 한다.
• 파티션 감내
  • 파티션은 두 노드 사이에 통신 장애가 발생하였음을 의미한다.
  • 즉, 파티션 감내는 네트워크에 파티션이 생기더라도 시스템이 계속 동작해야 한다는 것을 뜻한다.
• 3가지 요구사항 중 어떤 두 가지를 만족하냐에 따라 다음과 같이 분류할 수 있다.
  • CP시스템
  • AP시스템
  • CA시스템
• 다만 통상 네트워크 장애는 피할 수 없는 것으로 여겨지기 때문에 분산시스템은 반드시 파티션 문제를 감내할 수 있도록 설계되어야 한다. 따라서 CA시스템은 실질 존재하지 않는다.

  ✅ CP, AP 시스템 추가 예시

  • MongoDB (CP 시스템)
    • 비동기 복제를 사용하여 데이터의 여러 복사본을 분산시킨다
    • 주요 구성 요소
      • 프라이머리: 모든 쓰기 작업을 처리하는 마스터 노드
      • 세컨더리: 프라이머리로부터 데이터를 복제받아 동일한 데이터 세트를 유지하는 노드
      • 기본적으로 프라이머리가 모든 읽기와 쓰기를 처리하는데, 프라이머리 실패 시 새로운 프라이머리 선출에 최대 12초가 소요됨
      • 선출 과정 동안 모든 쓰기 작업이 중단됨
  • Cassandra (AP 시스템)
    • 카산드라는 Peer-to-peer 시스템
      • 즉, 카산드라는 프라이머리 노드 없이 모든 노드가 읽기 작업과 쓰기 작업을 수행할 수 있고 복제본을 분리된 다른 노드에 저장
    • 프라이머리 노드 없이 모든 노드가 같은 작업을 수행하므로 SPOF가 없다는 장점이 있음
    • 데이터는 복제 팩터 (데이터 복제본의 수) 에 따라 복제되며, 안정해시 기반 데이터 파티셔닝 제공
    • 파티션이 발생해서 복제본이 업데이트된 데이터 사본을 받지 못하는 상황이 발생할 수 있으나, 다른 노드들은 여전히 사용자가 사용할 수 있으므로 데이터 일관성이 깨짐
    • 그러나 Cassandra는 최종 일관성(eventual consistency) 제공
      • 즉, 모든 노드간 데이터가 동기화되기 전까지 각 노드는 서로 다른 버전의 데이터를 가지고 있을 수 있음
      • 카산드라가 최종 일관성을 보장하는 방법
        • 복제 팩터: 데이터의 복제본 수를 결정하여 여러 노드에 데이터를 분산 저장
        • 일관성 수준 설정: 읽기/쓰기 작업에 대한 일관성 수준 조절 가능
        • 읽기 복구: 일관성이 맞지 않는 데이터를 발견하면 자동으로 최신 데이터로 업데이트
        • 가십 프로토콜: 노드 간 주기적인 데이터 동기화를 통해 일관성 유지 (Cassandra의 모든 노드는 데이터 및 노드 상태에 대한 정보를 브로드캐스트하는 가십 프로토콜이라는 피어 투 피어 통신 프로토콜을 통해 서로 통신)
  • Reference
    • https://www.instaclustr.com/blog/cassandra-vs-mongodb/
    • https://www.analyticsvidhya.com/blog/2020/08/a-beginners-guide-to-cap-theorem-for-data-engineering/#h-understanding-cp-with-mongodb

이상적 상태

• 이상적 환경이라면 네트워크가 파티션되는 상황은 절대로 일어나지 않을 것이다.

실세계의 분산 시스템

• 분산 시스템은 파티션 문제를 피할 수 없다.
• n3에 장애가 발생하여 n1및 n2와 통신할 수 없으면 클라이언트가 n1, n2에 기록한 데이터가 n3에 전달되지 않는다. 또한 n3에 기록되었으나 아직 n1, n2로 전달되지 않은 데이터가 있다면 n1와 n2는 오래된 사본을 갖고 있을 것이다.
• 가용성 대신 일관성을 선택했다면(CP시스템) 세 서버 사이에 생길 수 있는 데이터 불일치 문제를 피하기 위해 n1과 n2에 대해 쓰기 연산을 중단시켜야 하는데, 그렇게 하면 가용성이 깨진다.
  • 은행권의 경우 데이터 일관성을 양보하지 않는다 ex. 온라인 뱅킹 시스템이 계좌 최신 정보를 출력하지 못한다면 큰 문제일 것이다.
  • 이와 같이 만약에 일관성이 깨질 수 있는 상황이 발생하면 이런 시스템은 상황이 해결될 때 까지는 오류를 반환해야 한다.
• 반대로 일관성 대신 가용성을 선택한다면(AP시스템) 낡은 데이터를 반환할 위험이 있다고 해도 계속 읽기 연산을 허용해야 한다. 그리고 n1과 n2에서는 계속 쓰기 연산을 허용할 것이고, 파티션 문제가 해결된 후에 새 데이터를 n3에 전송할 것이다.

시스템 컴포넌트

• 키-값 저장소 구현에 사용될 핵심 컴포넌트들 및 기술들을 살펴본다.
  • 데이터 파티션
  • 데이터 다중화
  • 일관성
  • 일관성 불일치 해소
  • 장애 처리
  • 시스템 아케텍처 다이어그램
  • 쓰기 경로
  • 읽기 경로
  • 데이터 파티션

데이터 파티션

• 대규모 어플리케이션에서 전체 데이터를 한 대 서버에 욱여넣는 것은 불가능하므로, 가장 단순한 해결책은 데이터를 작은 파티션들로 분할한 다음 여러 대의 서버에 저장하는 것이다.
• 데이터를 파티션 단위로 나눌 때는 다음 두 가지 문제를 중요하게 살펴보아야 한다.
  • 데이터를 여러 서버에 고르게 분산할 수 있는가
  • 노드가 추가되거나 삭제될 때 데이터의 이동을 최소화 할 수 있는가
• 이전 장에 배운 안정 해시가 이런 문제를 푸는 데 적합한 기술이다.
• 안정해시를 사용하여 데이터를 파티셔닝하면 좋은 점
  • 규모 확장 자동화
    • 시스템 부하에 따라 서버가 자동으로 추가되거나 삭제 가능 -> ➕ 하지만 안정해시만으로는 서버 자동 추가/삭제가 가능하지 않음. 왜냐하면 안정해시는 서버 추가/삭제 시 데이터 재배치를 최소화하기 위한 기술일 뿐이므로 자동화된 서버 관리를 위해선 추가구현 필요.
  • 다양성
    • 각 서버의 용량에 맞게 가상 노드의 수를 조정할 수 있다.
    • 즉, 고성능 서버는 더 많은 가상 노드를 갖도록 설정할 수 있다. -> ➕ s1,s2,s3 서버가 있을 때 s1 이 고성능 서버라면 s2,s3 와 다른 개수의 가상 노드 설정 가능.

데이터 다중화

• 높은 가용성과 안정성을 확보하기 위해서는 데이터를 N개 서버에 비동기적으로 다중화할 필요가 있다.
  • 여기서 N은 튜닝 가능한 값
• N개 서버를 선정하는 방법은 어떤 키를 해시 링 위에 배치한 후, 그 지점으로부터 시계 방향으로 링을 순회하면서 만나는 첫 N개 서버에 데이터 사본을 보관하는 것이다
• 가상 노드를 사용한다면 위와 같이 선택한 N개의 노드가 대응될 실제 물리 서버의 개수가 N보다 작아질 수 있다. 이를 해결하기 위해서는 같은 물리 서버를 중복 선택하지 않도록 해야 한다.
  • ➕ N=3 인데 해시 링을 순회하며 3개의 가상 노드 선택 시 s1_2, s1_3, s2_1 일 경우에는 3개의 가상 노드를 선택했지만 실제 물리서버 대수가 2인 상황이 됨.
• 같은 데이터 센터에 속한 노드는 정전, 네트워크 이슈 등의 문제를 동시에 겪을 가능성이 있다. 따라서 안정성을 담보하기 위해 데이터의 사본은 다른 센터의 서버에 보관하고, 센터들은 고속 네트워크로 연결한다.

  ✅ 안정 해시 구현 시 사용할 수 있는 방법

  • 데이터 센터 인식 파티셔닝: 해시 링에 노드를 배치할 때 각 데이터 센터의 노드를 번갈아가며 배치
    • 가상 노드 식별자 생성: 각 물리적 서버에 대해 여러 개의 가상 노드를 생성할 때, 데이터 센터 ID를 포함시킴. ex) "DC1-Server1-VNode1", "DC2-Server1-VNode1" 등의 형식으로 식별자 생성
    • 해시 함수 수정: 가상 노드의 해시 값을 계산할 때, 데이터 센터 ID를 고려하는 해시 함수 사용. 이를 통해 같은 데이터 센터의 노드들이 해시 링에서 연속적으로 배치되는 것을 방지 가능
  • 복제 전략 수립: 데이터의 복제본을 다른 데이터 센터의 노드에 저장하도록 설정
  • 고속 네트워크 연결: 데이터 센터 간 고속 네트워크를 구축하여 효율적인 데이터 복제와 동기화를 가능하게 함

데이터 일관성

• 여러 노드에 다중화된 데이터는 적절히 동기화가 되어야 한다.

• 정족수 합의(Quorum Consensus) 프로토콜을 사용하면 읽기/쓰기 연산 모두에 일관성을 보장할 수 있다.

  • N=사본 개수
  • W=쓰기 연산에 대한 정족수. 쓰기 연산이 성공한 것으로 간주되려면 적어도 W개의 서버로부터 쓰기 연산이 성공했다는 응답을 받아야 한다.
  • R=읽기 연산에 대한 정족수. 읽기 연산이 성공한 것으로 간주되려면 적어도 R개의 서버로부터 응답을 받아야 한다.

• 중재자는 클라이언트와 노드 사이에서 프록시 역할을 한다

  ❓ 중재자는 보통 어떤 컴포넌트로 구현되는지? = 어떠한 컴포넌트들이 클라이언트 <-> 노드 사이의 프록시 역할을 하면서, 정족수 합의 프로토콜을 구현할 수 있는지?

  • Kubernetes 의 etcd (모든 클러스터 데이터를 백업하는 Key-value 저장소)
    • Etcd는 Replicated state machine(이하 RSM) 으로, RSM 은 분산 컴퓨팅 환경에서 서버가 몇 개 다운되어도 잘 동작하는 시스템을 만들고자 할 때 선택하는 방법의 하나이다.
    • etcd는 하나의 write 요청을 받았을 때, 쿼럼 숫자만큼의 서버에 데이터 복제가 일어나면 작업이 완료된 것으로 간주하고 다음 작업을 받아들일 수 있는 상태가 됨

  • ex. RSM을 구성하는 서버의 숫자가 3대인 경우 쿼럼 값은 2(3/2+1)
    • 여기서 쿼럼 수식이 N(서버 수)/2+1 인 이유는 다수의 합의 요청이 가능하기 위함이다
    • 보통 클러스터 수는 홀수 개의 노드로 구성한다고 함. ref; 반드시 클러스터 노드의 수가 짝수가 되면 안 되는 건가?

• W, R, N의 값을 정하는 것은 응답 지연과 데이터 일관성 사이의 타협점을 찾는 전형적인 과정이다.

  • W=1 또는 R=1의 구성인 경우, 중재자는 한 대의 서버로부터의 응답만을 받으면 되기 때문에 응답속도는 빠를 것이다.
  • 만약 W, R 의 값이 이보다 큰 경우 데이터 일관성의 수준은 향상되지만 응답 속도는 느려질 것이다.
  • W+N > N의 경우에는 강한 일관성이 보장된다.
    • 일관성을 보증할 최신 데이터를 가진 노드가 최소 하나는 겹칠 것이기 때문이다.

• 가능한 W, R, N 의 구성

  • R=1, W=N : 빠른 읽기 연산에 최적화된 시스템
  • W=1, R=N : 빠른 쓰기 연산에 최적화된 시스템
  • W+R > N : 강한 일관성 보장 (보통 N=3, W=R=2)
  • W+R <= N : 강한 일관성이 보장되지 않는다.

    ❓ 일관성을 보장하게 되는 최종 시점도 중요하지 않은지? 왜 시간에 대한 언급이 없나..
    ex. 1분에 1회씩은 W+R>N 을 보장한다거나.. 무작정 W+R>N 이 될때까지 기다리진 않을테니까..

    • cassandra 예시 https://cassandra.apache.org/doc/3.11/cassandra/configuration/cass_yaml_file.html
      • write_request_timeout_in_ms
      • read_request_timeout_in_ms
    • 타임아웃 설정을 통해서 보장 가능. 실제 타임아웃에 걸리면 (ReadTimeoutException): Cassandra timeout during read query at consistency QUORUM (2 responses were required but only 1 replica responded) after nodetool cleanup 이런식으로 에러가 발생함

일관성 모델

• 일관성 모델은 데이터 일관성의 수준을 결정하는데, 종류가 다양하다.
• 강한 일관성
  • 모든 읽기 연산은 가장 최근에 갱신된 결과를 반환한다.
  • 다시 말해서 클라이언트는 절대로 낡은 데이터를 보지 못한다.
• 약한 일관성
  • 읽기 연산은 가장 최근에 갱신된 결과를 반환하지 못할 수 있다.
• 결과적 일관성
  • 약한 일관성의 한 형태로, 갱신 결과가 결국에는 모든 사본에 반영(즉, 동기화) 되는 모델이다.
• 강한 일관성을 달성하는 일반적인 방법은, 모든 사본에 현재 쓰기 연산의 결과가 반영될 때까지 해당 데이터에 대한 읽기/쓰기를 금지하는 것이다.
  • 이 방법은 고가용성 시스템에는 적합하지 않다
• 결과적 일관성 모델을 따를 경우 쓰기 연산이 병렬적으로 발생하면 시스템에 저장된 값의 일관성이 깨어질 수 있는데, 이 문제는 클라이언트가 해결해야 한다.

비 일관성 해소 기법 : 데이터 버저닝

• 데이터를 다중화하면 가용성은 높아지지만 사본 간 일관성이 깨질 가능성이 높이진다.
  • 버저닝 과 벡터 시계 는 이 문제를 해소하기 위해 등장한 기술이다.
• 버저닝 : 데이터를 변경할 때마다 해당 데이터의 새로운 버전을 만드는 것
  • 따라서 각 버전의 데이터는 변경 불가능

• 이 변경이 이루어진 이후에 원래 값은 무시할 수 있는데, 변경이 끝난 옛날 값이어서이다.
• 두 버전 v1, v2사이의 충돌을 해결하려면, 충돌을 발견하고 자동으로 해결해 낼 버저닝 시스템이 필요하다.
  • 벡터 시계는 이런 문제 해결에 보편적으로 사용되는 기술이다.
• 벡터 시계는 [서버, 버전]의 순서쌍을 데이터에 매단 것이다.
  • 벡터 시계는 D([S1, v1], [S2, v2] ... [Sn, vn])와 같이 표현한다고 가정하자.
  • D는 데이터, vi는 카운터, si는 서버 번호이다.
• 만일 데이터 D를 서버 Si에 기록하면, 시스템은 아래 작업 가운데 하나를 수행해야 한다.
  • [Si, vi]가 있다면 vi를 증가시킨다.
  • 그렇지 않으면 새 항목[Si, 1]를 만든다.

1. 클라이언트가 데이터 D1을 시스템에 기록한다. 이 쓰기 연산을 처리한 서버는 Sx이므로 벡터 시계는 D1[(Sx, 1)]으로 변한다.
2. 다른 클라이언트가 데이터 D1을 읽고 D2로 업데이트 한 다음 기록한다.
   D2는 D1에 대한 변경이므로 D1을 덮어쓴다.
   이 때 쓰기 연산은 같은 서버 Sx가 처리한다고 가정하면 벡터 시계는 D2([Sx, 2])로 바뀔 것이다.
3. 다른 클라이언트가 D2를 읽어 D3로 갱신한 다음 기록한다.
   이 쓰기 연산은 Sy가 처리한다고 가정하면 벡터 시계 상태는 D3([Sx, 2], [Sy, 1]])로 바뀐다.
4. 또 다른 클라이언트가 D2를 읽고 D4로 갱신한 다음 기록한다.
   이 때 쓰기 연산은 서버 Sz가 처리한다고 가정하면 벡터 시계는 D4([Sx, 2], [Sz, 1])일 것이다.
5. 어떤 클라이언트가 D3와 D4를 읽으면 데이터 간 충돌이 있다는 것을 알게 된다. (두 버전 모두 D2([Sx, 2])를 기반으로 함. 이는 D2에서 분기가 발생했음을 의미)
   D2를 Sy와 Sz가 각기 다른 값으로 바꾸었기 때문이다. 이 충돌은 클라이언트가 해소한 후에 서버에 기록한다.
   이 쓰기 연산을 처리한 서버는 Sx였다고 하면 벡터 시계는 D5([Sx, 3], [Sy, 1], [Sz, 1])로 바뀐다.

• 벡터 시계를 사용하면 어떤 버전 X가 버전 Y의 이전 버전인지(따라서 충돌이 없는지) 쉽게 판단할 수 있다.

  • 버전 Y에 포함된 모든 구성요소의 값이 X에 포함된 모든 구성요소 값보다 같거나 큰지만 보면 된다.

• 버전 X와 Y사이에 충돌이 있는지 보려면 Y의 벡터 시계 구성요소 가운데 X의 벡터 시계 동일 서버 구성요소보다 작은 값을 갖는 것이 있는지 확인해 보면 된다.

• 벡터 시계를 사용해 충돌을 감지하고 해소하는 방법의 2가지 단점

  • 충돌 감지 및 해소 로직이 클라이언트에 들어가야 하므로, 클라이언트 구현이 복잡해진다.

  • [서버:버전] 의 순서쌍 개수가 굉장히 빨리 늘어난다

    • 따라서 길이에 임계치를 정하고, 임계치 이상으로 길이가 길어지면 오래된 순서쌍을 벡터 시계에서 제거하도록 해야 한다

      • 위에서 말하는 클라이언트 == 저장소 시스템과 상호작용하는 소프트웨어 컴포넌트
      • 애플리케이션 서버, 데이터베이스 클라이언트 라이브러리 일 수 있음.
      • 애플리케이션 서버가 클라이언트라고 가정한다면, 아래와 같은 코드를 짤 수 있음

      public class VectorClockClient {
      // 벡터 시계를 저장하는 맵. 키는 서버 ID, 값은 해당 서버의 버전
      private Map<String, Integer> vectorClock;
      

    // 생성자: 빈 벡터 시계로 초기화 public VectorClockClient() {

    this.vectorClock = new HashMap<>();

    }

    // 특정 서버의 버전을 업데이트하는 메소드 public void update(String server, int version) {

    // 현재 저장된 버전과 새 버전 중 더 큰 값을 선택하여 저장
    vectorClock.put(server, Math.max(vectorClock.getOrDefault(server, 0), version));

    }

    // 다른 벡터 시계와 충돌을 감지하는 메소드 public boolean detectConflict(Map<String, Integer> otherClock) {

    // 현재 벡터 시계의 각 서버에 대해
    for (String server : vectorClock.keySet()) {
        if (otherClock.containsKey(server)) {
            // 현재 벡터 시계의 버전이 더 크면 충돌
            if (vectorClock.get(server) > otherClock.get(server)) {
                return true;
            }
        }
    }
    // 다른 벡터 시계의 각 서버에 대해
    for (String server : otherClock.keySet()) {
        if (vectorClock.containsKey(server)) {
            // 다른 벡터 시계의 버전이 더 크면 충돌
            if (otherClock.get(server) > vectorClock.get(server)) {
                return true;
            }
        }
    }
    // 충돌이 없으면 false 반환
    return false;

    }

    // 충돌을 해결하고 병합된 벡터 시계를 반환하는 메소드 public Map<String, Integer> resolveConflict(Map<String, Integer> otherClock) {

    // 현재 벡터 시계를 복사하여 새로운 맵 생성
    Map<String, Integer> resolvedClock = new HashMap<>(vectorClock);
    // 다른 벡터 시계의 각 항목에 대해
    for (Map.Entry<String, Integer> entry : otherClock.entrySet()) {
        // 두 벡터 시계 중 더 큰 버전을 선택하여 병합된 시계에 저장
        resolvedClock.put(entry.getKey(), Math.max(resolvedClock.getOrDefault(entry.getKey(), 0), entry.getValue()));
    }
    // 병합된 벡터 시계 반환
    return resolvedClock;

    } }

// 그래서 데이터를 읽을 때 충돌 발생한 것을 클라이언트 (애플리케이션 서버) 가 감지하고 해소 public Data read(String key) { ServerResponse response = server.read(key); Data data = response.getData(); Map<String, Integer> serverClock = response.getVectorClock();

if (vectorClockClient.detectConflict(serverClock)) {
    // 충돌 발생, 해결 로직 실행
    resolveConflict(key, data, serverClock);
} else {
    // 충돌 없음, 로컬 벡터 시계 업데이트
    vectorClockClient.update(serverId, serverClock.get(serverId));
}

return data;

}

```

장애 감지

• 보통 두 대 이상의 서버가 똑같이 서버 A의 장애를 보고해야 실제로 해당 서버에 장애가 발생했다고 간주한다

  

  • 모든 노드 사이에 멀티캐스팅 채널을 구축하는 것이 서버 장애를 감지하는 가장 손쉬운 방법이지만 이 방식은 서버가 많을 때에는 비효율적이다

• 가십 프로토콜 같은 분산형 장애 감지 솔루션을 채택하는 편이 더 효율적이다.

  • 각 노드는 멤버십 목록 (각 멤버 ID 와 그 박동 카운터 쌍의 목록) 을 유지한다
  • 각 노드는 주기적으로 자신의 박동 카운터를 증가시킨다.
  • 각 노드는 무작위로 선정된 노드들에게 주기적으로 자기 박동 카운터 목록을 보낸다.
  • 박동 카운터 목록을 받은 노드는 멤버십 목록을 최신 값으로 갱신한다.
  • 어떤 멤버의 박동 카운터 값이 지정된 시간 동안 갱신되지 않으면, 해당 멤버는 장애 상태인 것으로 간주한다.

• 노드 s0은 그림 좌측의 테이블과 같은 멤버십 목록을 가진 상태이다.
• 노드 s0은 노드 s2 (멤버ID=2)의 박동 카운터가 오랫동안 증가되지 않았다는 것을 발견한다.
• 노드 s0은 노드 s2를 포함하는 박동 카운터 목록을 무작위로 선택된 다른 노드에게 전달한다.
• 노드 s2의 박동 카운터가 오랫동안 증가되지 않았음을 발견한 모든 노드는 해당 노드를 장애 노드로 표시한다.

일시적 장애 처리

• 가십 프로토콜로 장애를 감지한 시스템은 가용성을 보장하기 위해 필요한 조치를 해야 한다
  • 엄격한 정족수 접근법 사용 : 읽기와 쓰기 연산 금지
  • 느슨한 정족수 접근법 사용 : 이 조건을 완화하여 가용성을 높인다.
    • 장애 상태인 서버로 가는 요청은 다른 서버가 잠시 맡아 처리한다.
      • 장애 서버로 향하는 요청을 감지하면, 시스템은 해시 링에서 다음으로 가까운 정상 서버로 요청을 리다이렉션
    • 그동안의 변경사항은 해당 서버 복구 시 일괄로 반영하여 데이터 일관성을 보존한다.
    • 이를 위해 임시로 쓰기 연산을 처리한 서버에는 그에 관한 단서 (hint) 를 남긴다.
    • 이런 장애 처리 방안을 단서 후 임시 위탁 기법 (hinted handoff) 라고 부른다.

✅ hinted handoff 실제 예시

• 카산드라가 노드 장애시에도 fault tolerance (결함 내성) 을 유지하는 주요 방법 중 하나는 hinted handoff 메커니즘이다
• cassandra.yaml에서 hinted_handoff_enabled이 true로 설정되어 있으면(기본 설정) 복제 노드 중 하나에 도달 할 수 없을 때 카산드라는 coordinator 노드에 hint를 저장
  • coordinator
  • 해당 힌트는 클러스터에 속한 위치에 대한 정보를 포함한다.
  • 힌트는 코디네이터 노드의 $CASSANDRA_HOME/data/hints 디렉터리에 있는 플랫 파일에 저장됨. 힌트에는 힌트 ID, 변경 사항을 저장할 대상 복제본 노드, 복제본 노드로 전달할 수 없는 직렬화된 변경 사항(blob으로 저장), 변경 사항 타임스탬프 및 변경 사항을 직렬화하는 데 사용된 Cassandra 버전이 포함됨
    • Cassandra의 이전 버전에서는 힌트를 힌트 테이블에 저장했는데, 최신 Cassandra 릴리스는 힌트를 저장하기 위해 디스크의 플랫 파일을 사용
• coordinator가 복제 노드가 다시 정상화되는 것을 알아차리게 되면 hint 정보를 복제 노드에서 replay (코디네이터 노드가 저장해 둔 힌트(hint) 정보를 복구된 복제 노드에 적용하는 과정) 시킨다. 
• 기본적으로 Cassandra는 hint 대기열이 너무 길어지는 것을 방지하기 위해 최대 3시간 동안 hint를 저장한다.
  • cassandra.yaml의 max_hint_window_in_ms 속성(기본 3시간)이 해당 hint가 저장되는 시간을 의미한다. 
  • max_hin_window_in_ms 시간이 지나면 일관성을 복원하기 위해서 노드가 다시 정상화되었을 때 수동으로 node repair를 실행해야 한다.

+) AWS DynamoDB 도 hinted handoff 사용한다고 함.

ref; https://cassandra.apache.org/doc/4.0/cassandra/operating/hints.html

영구 장애 처리

• 단서 후 임시 위탁 기법은 일시적 장애를 처리하기 위한 것이므로 영구적 노드 장애 상태는 다른 처리 방안이 필요하다
• 반-엔트로피 프로토콜을 구현해서 사본들을 동기화해야 한다.
  • 반-엔트로피 프로토콜은 사본들을 비교하여 최신 버전으로 갱신하는 과정을 포함한다.
• 사본 간의 일관성이 망가진 상태를 탐지하고 전송 데이터의 양을 줄이기 위해서는 머클 트리를 사용할 것이다.
• 머클 트리 : 해시 트리라고도 불리며 각 노드에 그 자식 노드들에 보관된 값의 해시, 또는 자식 노드들의 레이블로부터 계산된 해시 값을 레이블로 붙여두는 트리

• 루트 노드의 해시 값이 일치하면 두 서버는 같은 데이터를 갖는 것이다
• 그 값이 다를 경우 왼쪽, 오른쪽 자식노드의 해시값을 비교하면서 아래쪽으로 탐색하다보면 다른 데이터를 갖는 버킷을 찾을 수 있으므로 그 버킷들만 동기화하면 된다

데이터 센터 장애 처리

• 데이터 센터 장애는 정전, 네트워크 장애, 자연재해 등 다양한 이유로 발생할 수 있다.
• 데이터 센터 장애에 대응할 수 있는 시스템을 만들려면 데이터를 여러 데이터 센터에 다중화하는 것이 중요하다.

쓰기 경로

• 아래 구조는 카산드라의 사례를 참고한 것이다

1. 쓰기 요청이 커밋 로그 파일에 기록된다.
2. 데이터가 메모리 캐시에 기록된다.
3. 메모리 캐시가 가득차거나 사전에 정의된 어떤 임계치에 도달하면 데이터는 디스크에 있는 SSTable에 기록된다.
   • SSTable은 Sorted-String Table의 약어로, <키, 값>의 순서쌍을 정렬된 리스트 형태로 관리하는 테이블

읽기 경로

• 데이터가 메모리에 없는 경우에는 디스크에서 가져와야 하며, 어느 SSTable에 찾는 키가 있는지 알아낼 효율적인 방법으로 블룸 필터가 흔히 사용된다.

➕ Cassandra

• 카산드라는 일반적인 DB에서 쓰이는 B-Tree 대신 Log-Structured Merge Tree (LSM Tree) 사용
• 블룸 필터 : Bloom Filter는 어떤 원소 x가 어떤 집합 A 의 원소인지 확률적으로 판단하는 표시함수
• 블룸 필러를 이용한 membership query (어떤 집합 A와 어떤 원소 x가 'x가 A에 포함된' 관계인지 묻는 것) 의 결과 값은 '아마도 해당 집합의 원소인 것 같다', 또는 '확실히 해당 집합에 포함된 원소가 아니다'를 뜻한다.
  이런 특성 때문에 블룸 필터는 단독으로 사용하는 것보다는 확률적인 방법이 아닌 다른 방법을 보조하는 역할로 사용하는 것이 적합하다

1. 데이터가 메모리 있는지 검사한다.
2. 데이터가 메모리에 없으므로 블룸 필터를 검사한다.
3. 블룸 필터를 통해 어떤 SSTable에 키가 보관되어 있는지 알아낸다.
4. SSTable에서 데이터를 가져온다.
5. 해당 데이터를 클라이언트에 반환한다.

• 수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나누는 것이 중요하다

  ❓사용자의 요청을 고르게 분배하기 위해 사용되는 로드밸런서에서는 안정해시 기술을 사용안할까?

  • 목적
    • 로드 밸런서: 네트워크 트래픽을 여러 서버에 분산시켜 서버 과부하를 방지하고 가용성을 높이는 데 사용
    • 안정 해시: 분산 시스템에서 데이터를 균등하게 분배하고 노드의 추가 및 제거 시 재분배를 최소화하는 데 사용
    • 즉, 주된 분산 대상이 다름 ! 로드밸런서는 주로 네트워크 요청이나 트래픽을 분산하며, 안정 해시는 주로 데이터를 분산함
  • 알고리즘의 복잡성
    • 로드 밸런서: 일반적으로 간단한 분산 알고리즘(예: 라운드 로빈, 최소 연결, IP 해시 등)을 사용하여 실시간으로 트래픽 분배
    • 안정 해시: 복잡한 해싱 기술을 사용하여 데이터를 분배하며, 노드의 추가/제거 시에도 최소한의 재분배를 보장하는 알고리즘을 사용
  • 하지만 로드밸런서에서도 안정해시 기술 도입할 수 있음!
    • 구글에서 개발한 Maglev 네트워크 로드 밸런서는 안정 해시 기술을 활용하여 대규모 분산 시스템에서 효율적인 트래픽 분산을 실현
    • NGINX 도 안정해시 알고리즘 지원

  해시 키 재배치 (rehash) 문제

• N개의 캐시 서버가 있을 때 이 서버들에 요청을 균등하게 나누는 보편적인 방법은 아래 해시 함수를 사용하는 것이다.
  • 서버 인덱스 = hash(key) % N (서버의 개수)
• 이 방법은 서버 풀의 크기가 고정되어있고 키의 분포가 균등할 때는 잘 동작한다

  ❓ 서버 풀의 크기가 고정되어 있을 때는 무슨 상관이 있는거지?

  • 재분배할 필요가 없으니까 hash % N 의 결과가 항상 일정하여 캐시 일관성이 유지됨.

• 서버가 추가되거나 기존 서버가 삭제된다면 키에 대한 해시값은 변하지 않아도 나머지 연산을 적용한 서버 인덱스 값이 달라질거고, 그러면 캐시 클라이언트는 데이터가 없는 엉뚱한 서버에 접속하게 된다.
  • 이것은 대규모 캐시 미스(cache miss)가 발생하게 되며 안정 해시는 이 문제를 효과적으로 해결하는 기술이다

안정 해시

• 안정해시는 해시 테이블 크기가 조정될 때 평균적으로 오직 k/n 개의 키만 재배치하는 해시 기술
  • k : 키의 개수, n : 슬롯 (서버)의 개수
  • 대부분의 전통적 해시 테이블은 슬롯의 수가 바뀌면 거의 대부분의 키를 재배치한다 해시 테이블의 크기가 조정되어도 평균적으로 오직 k/n 개의 키만 재배치 하는 해시 기술이다.

해시 공간과 해시 링

• 해시 공간의 양쪽을 구부려 붙여 만든 링이어서 해시 링이라고 한다

서버 조회

• 어떤 키가 저장되는 서버는, 해당 키의 위치로부터 시계 방향으로 링을 탐색해나가면서 만나는 첫번째 서버다

서버 추가

• 서버를 추가하더라도 키 가운데 일부만 추가해주면 된다.
  • 새로 추가된 노드 C로부터 시계방향으로 가장 가까운 노드 A가 관리하던 키들 중, 노드 C 보다 시계 반대 방향에 있는 키들을 모두 C로 재배치한다.

서버 제거

• 하나의 서버가 제거될 때도 키 가운데 일부만 재배치 된다.

기본 구현법의 문제들

• 안정 해시의 기본적인 절차는 다음과 같다

  • 서버와 키를 균등 분포 (uniform distribution) 해시 함수를 사용해 해시 링에 배치한다.

    ✅ 균등 분포 해시 함수 예시

    • SHA-1 (Secure Hash Algorithm 1) : 0부터 2^160-1까지의 범위를 갖고 입력값을 해시 공간에 고르게 분포 시킴
    • MD5 (Message Digest algorithm 5) : 128비트 해시값을 생성하며, 빠른 계산 속도를 제공

  • 키의 위치에서 링을 시계 방향으로 탐색하다 만나는 최초의 서버가 키가 저장될 서버다.

• 이 접근법에는 두가지 문제가 있다.

  • 파티션의 크기를 균등하게 유지하는 게 불가능하다

    • 파티션 : 인접한 서버 사이의 해시 공간
    • C가 삭제되면 A의 파티션과 B의 파티션 크기가 균등하지 않게 된다.

  • 키의 균등 분포를 달성하기 어렵다

• 이 두 문제를 해결하기 위해 제안된 기법이 가상노드/복제 라 불리는 기법이다.

가상 노드

• 가상 노드 : 실제 노드 또는 서버를 가리키는 노드로서, 하나의 서버는 링 위에 여러 개의 가상 노드를 가질 수 있다.
  • 각 서버는 하나가 아닌 여러 개 파티션을 관리해야 한다

    ❓실 사용 사례에서는 가상 노드의 개수를 어느정도로 가져가는가?

• 가상 노드의 개수가 늘어날 수록 표준 편차가 작아져 데이터가 고르게 분포된다.
• 하지만 가상 노드 데이터를 저장할 공간은 더 많이 필요하게 된다

  ❓가상 노드는 실제 노드/서버랑 동일 스펙으로 구성되나?

  • 가상 노드는 실제 물리적인 서버가 아니라, 해시 링 상에서 실제 서버를 여러 개로 나누어 표현하는 논리적 개념이다
  • 따라서 실제 데이터를 저장하지 않고, 단지 실제 서버로 데이터를 라우팅하는 역할을 한다
    • 데이터 분산과 로드 밸런싱을 위한 메타데이터로 사용
  • 가상 노드에서 실제 노드로의 데이터 전달 과정
    • 키 해싱: 데이터의 키가 해시되어 해시 링 상의 위치가 결정됨
    • 가상 노드 매핑: 해당 위치에서 시계 방향으로 가장 가까운 가상 노드를 찾음
    • 실제 서버 식별: 각 가상 노드는 자신이 속한 실제 서버의 정보를 가지고 있으므로 이 정보를 사용하여 해당 데이터가 어느 실제 서버로 가야 하는지 결정
    • 데이터 전송: 식별된 실제 서버로 데이터가 직접 전송
    • 저장 및 처리: 실제 서버에서 데이터를 저장하고 처리
  • 메모리 내 데이터 구조
    • 가상 노드 정보는 주로 해시 맵이나 배열과 같은 메모리 내 데이터 구조에 저장됨
    • 이 구조는 가상 노드의 ID와 해당 실제 노드의 정보(예: IP 주소, 포트 번호)를 매핑함

마치며

• 안정 해시의 이점
  • 서버가 추가되거나 삭제될 때 재배치되는 키의 수가 최소화된다.
  • 데이터가 보다 균등하게 분포하게 되므로 수평적 규모 확장성을 달성하기 쉽다.
  • 핫스팟 키 문제를 줄인다. 특정한 샤드에 대한 접근이 지나치게 빈번하면 서버에 과부하 문제가 생길 수 있다.
• 안정 해시의 유명한 사례
  • 아마존 DynamoDB의 파티셔닝 관련 컴포넌트
  • 아파치 카산드라 클러스터에서의 데이터 파티셔닝
  • 디스코드 채팅 어플리케이션
  • 아카마이 CDN
  • 매그레프 네트워크 로드 밸런서

어느덧 기나 긴 2024년도 끝이 났다 ~! 2024년 12월 말부터 회고를 썼는데 미루고 미루다가 2025년 한달이 지난 이 시점에도 회고를 계속 쓰고 있다..ㅎㅎ (게으름이슈.......🤧 매년 회고를 할 때마다 느끼는건데 작년보다 이것저것 한 것도 많은 것 같고 후회 없이 보낸 것 같은데 연말이 되면 항상 뭘 했는지 모르겠는 느낌이 들곤 한다. 그래서 더더욱 회고를 쓰면서 한 해동안 있었던 나의 성취와 다양한 경험을 떠올려 보려 하는 것 같다. 돌이켜보면 매년 나는 지나온 한 해에 대한 후회가 없었고 내가 할 수 있는 최선을 다했다고 생각한다. 누가 뭐라하든 스스로 내가 보낸 한 해에 만족했으면 되지 않나 싶고... 그런 점에서 2024년 한해도 참 수고했다 !!!! 올해도 투두메이트 열심히 채우면서 잘 살았다 😁

2024년은 크게 4가지의 키워드로 나눠볼 수 있을 것 같아, 키워드 별로 여러가지 경험들을 정리해보고자 한다! 4번 업무에 대한 내용은 쓰다보니 길어지는 것 같아서 업무 회고로 따로 작성해보겠다 🙈

2024년 키워드

1. 운동
2. 자기계발
3. 기부
4. 업무

운동

1. 처음으로 6개월 이상 꾸준히 하고 있는 운동

24년 1,2월만 해도 나는 매주 병원에 가서 도수치료를 받았고 허리 주사를 맞았고 매주 20만원 이상 병원비를 긁었다 😡 허리가 아프다고 느껴진 순간, 그 전과는 정말 달라진 삶이 된다 같은 자세로 오래 앉아있기 힘들고, 어딜가도 의자가 편한 지를 체크하고, 내가 어떤 자세로 앉아있는지 의식적으로 생각하곤 한다. 이 글을 읽고 있는 아직 허리 안 아픈 사람들은 자세를 고쳐 앉길 바란다…

2023년 말 처음으로 PT 를 일주일에 2번씩 받으면서 2024년의 나는 허리가 안아프겠지 기대하며 운동을 했다. 하지만 무게들고 운동을 하면서 허리에 더 무리가 갔고 나는 PT를 그만두었다. 1월부터는 혼자 헬스장을 끊고 운동을 가야겠다고 다짐하였지만 한해의 절반이 간 7월까지도 나는 운동을 하지 않았다.

까지가 나의 2024년 7월까지의 게으른 모습이다...

2024년 8월에 드디어 26년을 살면서 항상 나에게 큰 과제이자 넘어야 할 큰 산처럼 느껴졌던 운동을 시작했다. 운동이 너무 싫어서 운동하느니 차라리 공부를 하겠다고 생각했던 내가 일주일에 최소 1~2번은 운동을 했다. (장족의 발전 😁 사실 가기 싫어서 미루고 미루다가 회원권 끝나기 전에 일주일에 4번씩 간적도 있긴 하다.. 이때 자주가느라 너무 힘들어서 이제는 한 주에 2번은 가는 걸 목표로 하고 있다

맨몸운동이다보니 무게를 많이 들지는 않는데 이젠 조금씩 무게도 올려서 운동을 하게 되었다. 조금씩이라도 무게를 올리는 재미도 있고, 어느정도 코어가 잡혀가고 있어 다행이다! 그동안은 땀흘리며 운동하는 거 자체가 찝찝하고 불편하게 느껴졌었는데, 올해는 운동 후의 개운함과 뿌듯함을 느끼게 되어서 감사하다.

운동 후에 단백질을 챙겨먹으라는 강사님의 말도 잘 듣고 있다. 팀원에게 단백질 음료도 추천 받아서 덕분에 가성비 좋은 단백질 음료도 새로 먹고 있고, 닭가슴살 소세지도 즐겨먹고 있다. 운동 끝나고 단백질 챙겨먹는 시간들도 나에게 소소한 즐거움이 되었다. 왜 이렇게 단백질 타령을 하냐고 친구가 뭐라 한 적도 있을만큼 단백질 챙겨먹어야 된다고 말을 많이 한 것 같다 ㅎ,,,ㅎ

운동 끝나고 배고파서 붕어빵 2개를 품에 안고 집까지 뛰어간 적이 있는데, 그 순간의 행복이 잊혀지지 않는다. 이게 소확행이구나 싶었고, 그 시점 이후로 운동 후의 (붕어빵 사는) 시간들을 더 좋아하게 된 것 같다. 붕어빵 파는 겨울 너무 소중해 >_< 올해도 열심히 끊어서 2025년은 근력량 높이기와 허리가 아프지 않은 선에서 안전하게 운동하는 것에 집중해야겠다 💪 아자아자 !!!!!

2. 꾸준한 스트레칭 루틴

어깨, 등, 손목 스트레칭 뿐만 아니라 (내가 맹신하는) 정선근 교수님이 알려준 종아리 운동, 신전 운동은 거의 매일 했다. 운동을 못가는 날에도 조금씩이라도 꾸준히 해서 루틴으로 자리잡은 것 같아 다행이다. 신전운동을 하면 뻣뻣했던 허리가 말랑말랑(?) 해지는 느낌이 들어서 좋다.....ㅎㅎㅎㅎ 허리 아픈 사람들에게 강추 올 한해도 열심히 스트레칭해서 허리 통증을 작년보다 줄여보자 !!!!

3. 새로운 도전 : 마라톤 참여

올 여름 제일 더울 때 마라톤에 첫 참가를 했다. 뛰는 거 + 땀 나는 것을 질색하던 내가 어떤 마음으로 갑자기 러닝이 하고 싶어진지 아직도 나를 잘 모르겠지만... 완주하고 느껴지는 후련함 + 뿌듯함은 이루 말할 수 없었다. 그래서 첫 5km 마라톤을 완주하고 그 자리에서 바로 2번째 마라톤을 신청했다. 사실 러닝 연습은 한번도 안하고 마라톤만 하러 나갔지만 ㅋㅋㅋㅋㅋ 러닝 연습은 안해도 운동을 하고 있어서 체력이 늘어 그런가 매번 페이스가 줄어드는 게 너무 뿌듯했다. 그런데 이제 더이상 연습 없이는 페이스를 단축시킬 자신이 없어서 ^.ㅠ 내년에는 꼭 연습을 하고 기록단축에도 도전해보고 싶다 !! 특히 허준런은 5km 를 한 번도 쉬지 않고 뛰었어서 더 뿌듯했던 것 같다,,,내가 5km 를 쉼없이 뛸 수 있는 사람이었다니 !!!!!! 하는 놀라움이 나에게도 있었다.

그리고 내년에는 10km 마라톤에도 도전해서 70분 안에 완주해보는 걸 목표로 하고 싶다 ! 러닝할 때 신을 운동화도 장만해야지... 그동안 내가 싫어한다고 생각해왔지만 마라톤을 한번 도전해봄으로써 내가 좋아하는 운동을 발견하게 된 계기가 되었다. 2024년에 기억남는 회고 키워드 중 빠지지 않는게 마라톤일 정도로,, ㅎㅎㅎ 내년에도 열심히 달려보자 !!!! 🤸🏻‍♀️

자기계발

1. 매일 조금씩 감사하는 습관

글또 9기가 끝난 후 감사회고채널에서 10기가 시작되기 전까지 카톡으로 감사회고를 나눌 사람을 모집하고 있었다 ! 감사회고채널에서 활동하지 않았는데도 정말 우연하게 그 스레드를 보게 되었다. 운명이었을지도... 감사일기를 예전부터 쓰려고 몇번 시도를 했는데 혼자 메모장에 쓰니까 꾸준히 써지지가 않았다. 길어봤자 한달 정도? 지속되었던 것 같다. 그래서 여러 명이 함께 있는 채널에서라면 꾸준히 할 수 있을 것 같아 참여를 하게 되었는데 이 습관이 생각보다 길게 지속되고 있다 ! 24년 6월 중순을 기점으로 매일 매일 감사회고를 꾸준히 적었다. 아무리 생각나는 게 없어도 쥐어짜내서 5개씩은 적어보자는 나만의 규칙을 정했다. 어떤 날은 정말 한 게 없어서 저녁이 맛있어서 감사하고 하루종일 누워있어서 감사하고.. 이런 시덥잖은 내용들도 적었지만 그 소소한 일상들마저 감사할 거리라는 것을 느낄 수 있었던 것 같다.

안 좋은 일이 생기더라도 그 순간에 감사하는 마음을 가지기까지는 많은 시간이 필요할 것 같지만 하루를 돌아보면서 작은 것에라도 감사하는 마음이 생긴다는 것만으로도 달라지고 있는 것 같다.. ㅎㅎ 조금씩 긍정적으로 마인드가 바뀌었으면 하는 마음으로 올해도 감사일기 쓰기는 계속 해보아야겠다 🙂

2. 책과 친해진 2024년

2024년은 책과 가까워진 한 해였다 ! 2023년 7월에 저어어어엉말 오랜만에 책을 읽기 시작했다. 초등학생 때 이후로는 거의 책을 1년에 1권을 읽을까말까 했는데 ㅎㅎ... 23년 7월에 이유는 모르겠지만 갑자기 '개발 책 좀 읽어보고 싶은데?' 라는 생각이 들어서 친구랑 무작정 시작했던 북스터디가 이렇게까지 내가 책을 좋아하게 만들 줄이야... 역시 사람 일은 모를 일이다 🧐

올 한해 동안은 개발 9권, 비개발 12권으로 총 21권의 책을 읽었다. 오랜만에 책을 붙잡고 한 해동안 열심히 읽어보았는데 내 생각보다 많은 책을 읽었다는 생각이 들었다! 책을 읽다보니까 자연스레 교보문고 어플에 자주 들어가게 되고, 들어가서 재미있어 보이는 책들을 찜해두니까 찜 목록에도 무려 50권의 책이 담겨져있다 ㅋㅋㅋㅋ 앞으로도 많은 책을 다양하게 읽어보면서 견문을 넓히고 싶다 ! 책을 읽으면 다른 사람들이 삶을 통해 배우고 느낀 지혜를 배우는 느낌이라 참 좋다...

올해는 교보문고 오프라인 매장도 많이 갔다. 방앗간을 그냥 지나치지 못하는 참새처럼... 서점만 보이면 홀린 듯이 들어가서 책 몇권이라도 뒤적거리고 구경하다가 나온 것 같다. 서점은 언제가도 새로운 책들과 내 관심을 끄는 책들이 많아서 참 힐링되고도 좋은 공간인 것 같다. 서점가서 이것저것 구경하다가 올해는 학생때 이후로 오랜만에 문구류도 많이 샀다! 책 읽을 때 밑줄 그을 색연필, 필기할 볼펜들, 제주도 가서 책 읽을 때 필기하려고 산 블랙윙 연필 등... 요즘 블랙윙 연필로 필기하고 노란색 형광색연필로 밑줄 그으며 책읽는게 너무 좋다

조금 아쉬운 점은 분야 편식을 심하게 했다는 점이다. 개발 서적 제외하고는 자기계발 분야나 일에 대한 책들만 골라 읽었다. 사실 문학도 읽어보고 싶고 특히 경제/재테크 분야 책을 읽고 싶었는데 !!!!!!! 다 우선순위에 밀려서 읽지 못했다 🥲

그리고 내가 읽은 모든 책에 대해서 밑줄 친 내용을 정리했지만, 한줄평과 같은 찐 요약을 안해놨다보니까 나중에 그 책에서 중요하게 전달하려는 말이 무엇이었는지 기억이 안 난 경우가 많았다. 그래서 이제는 책을 완독하자마자 그 책에 대한 한줄평을 적어보려고 한다.

올 한해는 다양한 분야의 책을 읽고 실제 삶에 적용해보는 경험들을 더더더 많이 해보고 싶다. 아 내용 좋다 ~! 하고 뒤돌아서면 잊어버리지 않고, 삶을 변화시킬 수 있는 액션포인트들을 많이 찾아서 실천해보자 !!!!!

3. 야무지게 사용한 말해보카 1년 이용권

2023년 7월? 에 친구 추천으로 말해보카를 처음 하게 되었다. 말해보카 처음한 날은 재밌어서 새벽 2시까지 하다 잤던 기억이 있다 ㅋㅋㅋㅋ 말해보카에는 1년 이용권이 있음에도 불구하고 내가 1년동안 이걸 꾸준히 할 자신이 없어서 한 3개월을 월 이용권으로 간보다가, 2023년 10월부터 1년 이용권을 끊고 시작하게 되었다.

친구와 매일 조금씩이라도 말해보카를 하자는 목표를 세웠고, 안하면 하루에 천원씩 벌금을 내기로 했다. 그렇게 우리는 2024년 10월까지 1년 이용권을 야무지게 다 사용하고, 또 다시 1년 이용권을 끊었다 !!!! 말해보카에서 2024년 RECAP 을 보내줬는데 365일 중 353일이나 했으니 그래도 꾸준히 잘한 것 같다 ㅎㅎㅎ 내년에는 단어 뿐만 아니라 리스닝/문법도 같이 꾸준히 해보려고 한다 !!!!! 올해도 열심히 말해보카를 영업하는 한 해가 되길...

기부

어렸을 때부터 엄마로부터 "너가 가진 것을 나누면서 살아라~ 베풀면서 살아라~" 이런 류의 이야기를 많이 들으며 자랐다. 그 때는 그냥 별 생각 없이 지나갔던 말들이었는데, 그런 이야기들을 많이 들은 영향이었는지 성인이 되었을 때 내가 생각하는 이상적인 삶은 "내가 가진 것을 나눌 줄 아는 사람이 되는 것" 이었다.

나누는 것이 돈일 수도, 내가 가진 능력일수도 있는데, 그 2가지를 모두 나누었던 한 해라 뿌듯했던 것 같다. 아직은 소소한 금액이지만 조금 더 여유가 생기면 더 유의미한 변화를 만들어낼 수 있는 금액으로 나눔을 실천해보고 싶다.

1. 아이케어노트 프로젝트 회사 내에서 재능 기부 형태로 프로젝트에 참여할 사람을 모집했는데, 이 프로젝트에 참여하였다. 아이케어노트 관련한 내용은 4번 업무 카테고리에서 적어보려고 한다.

2. 승일희망재단 그룹사 임직원 대상으로 승일희망재단과 협업한 캠페인을 진행했다. 개인적으로 기부하는 것도 좋지만 회사 내에 속해 임직원으로서 캠페인에 참여하여 도움을 주는 것도 의미가 있을 거라고 생각이 들어 바로 참여를 하게 되었다 ! 일시 기부의 형태였지만 취업하고 돈을 번 이후로 처음으로 기부한 경험이라서 뜻깊었고 뿌듯했던 것 같다 ㅎㅎ 이 시점을 기반으로 조금 더 기부에 관심이 갔달까.. ?!

3. 컴패션 컴패션은 엄마가 기부하고 있는 곳이어서 알게 되었는데 어린이 한명에게 정기적으로 후원하는 형태이다. 아이에게 조금 더 금전적인 도움이 되길 바라는 마음에서, 한국 돈으로 환산했을 때 그 나라에서 더 많은 가치를 가질 수 있는 국가로 선택을 했다. 아이가 2살이라서 아직 스스로 글을 써서 나에게 편지를 보내주진 못하지만..ㅎㅎ 이 아이가 자라가는 과정을 볼 수 있다는 점이 벌써 기대가 된다 ! 편지도 써야하는데 자꾸만 까먹게 된다... 잘 자라라는 의미에서 편지도 이번달에는 꼭 써서 보내야겠다 !!

4. 개발자 잔디 기부 캠페인

연말에 항해99 에서 개발자 잔디 기부 캠페인을 한다고 해서 참여했다. 잔디 1개당 100원으로 환산한 금액을 기부하고, 저소득층 아동들에게 코딩 교육을 지원하는데 쓰인다고 한다. 생각보다 2024년에 커밋을 얼마안해서.. 406개라 4만원 밖에 안되지만 😅 그래도 개발과 관련해서 기부할 수 있어서 신기하기도 했고 더 의미있게 느껴졌다 !! 코딩을 배우고 싶어하는 아기들에게 작게나마 도움이 되길,,

5. 사랑의 열매 크리스마스에 광화문에 갔는데 사랑의 열매 부스가 있었다. 2천원을 기부하고 열매네컷을 찍는 캠페인이었는데 역대급 소소한 금액이었지만 ㅎ_ㅎ 캠페인에 참여한다는 것에 의의를 두고 사진 한장 남겨왔다 !

올해는 총 5가지의 나눔을 실천해보았는데, 작은 금액이더라도 내가 가진 것을 나누는 것만으로도 나에게 더 큰 행복과 기쁨이 돌아온다는 것을 느낄 수 있었다. 금액에 연연하지 않고 누군가에게 도움이 될 수 있다는 것만으로 뿌듯함을 느끼면서 앞으로도 꾸준히 기부를 해보아야겠다 !! 그리고 돈 뿐만 아니라 재능기부의 형태로 내가 가진 능력을 나누어보는 것도 많이 해보고 싶다 😁

Outro

아직 업무 회고가 남았긴 하지만 잠깐 2024년을 총 정리(?) 해보려고 한다. ㅎㅎ 업무 외적인 경험들을 되돌아보면 새로운 시작, 작은 반복의 힘 이라는 키워드로 정리해볼 수 있을 것 같다. 마라톤과 운동을 새롭게 시작했고, 매일 책을 읽고 영어공부도 하고, 감사회고도 꾸준히 했다. 특히 올해 신경쓴 점은 매일 루틴을 정해서 시간을 촘촘하게 사용하려고 노력했는데 그 덕분에 생각보다 많은 기술 서적도 읽었고 자기계발에 많은 시간을 투자할 수 있었다.

최근 읽은 책에 "반복의 위력은 결코 과소평가될 수 없다" 라는 문장이 있었다. 정말 격하게!!!!!!! 공감한다.

매일 조금씩이라도 반복하고 꾸준히 하는 습관. 그걸 나의 강점이라고 생각하고 있고, 실제 갤럽 강점 검사에서도 성취가 1등으로 나왔다,,ㅎ 내가 생각보다 성취감에 죽고 못사는 사람인 것 같다는 걸 2024년의 경험을 통해 느꼈다.

최근에도 친구랑 대화를 하다가 "너 꾸준하게 하는 거 하나는 진짜 잘한다" 라는 이야기를 들었다. 솔직히 진짜 기분이 좋았다. 내가 생각하는 장점이자 강점을 다른 사람의 입을 통해 한번 더 확인 받은 느낌이라 그랬던 것 같다.

꾸준함을 통해 얻을 수 있는 성취감, 작은 성취감들이 모여서 더 큰 도전을 할 수 있는 원동력이 된다. 그리고 이 성취감들이 모여서 내가 어떤 것에 도전하더라도 난 할 수 있을 거라는 믿음을 갖게 되는 것 같다. 요즘 참 근자감인지 뭔지 모르겠지만,,, 어떤 것을 처음 시작할 때는 두렵게 느껴지지만 어느 순간 '뭐 나는 해낼 수 있겠지' 라는 생각이 들면서 나 자신에 대한 믿음이 커진 것 같다. 그게 결국 무언가를 조금씩 반복하며 내가 원하는 삶을 만들어가고 있기 때문에 느낄 수 있었던 감정인 것 같다.

2024년은 꾸준함의 힘을 체감한 한 해였는데, 2025년에는 이를 더 단단한 일상으로 만들어보고 싶다. 또한 취미 부자가 되는 게 목표여서 온전히 나로 존재할 수 있을 수 있는 퇴근 후, 주말의 시간들을 더 다채롭게 꾸며보고 싶다. *삶을 재미있게 내가 좋아하는 것들로 가득 채워서 즐겁게 살고 싶다. *2025년은 다채로운 삶의 시작점이 될 수 있길 !!! 🌺🌺🌺

• 처리율 제한 장치 (rate limiter) : 클라이언트 혹은 서비스가 보내는 트래픽의 처리율을 제어하기 위한 장치

  ❓ circuit breaker 랑 차이점?

  • HTTP 를 예로 들면 이 장치는 특정 기간 내에 전송되는 클라이언트 요청 횟수를 제한함
  • API 요청 횟수가 제한 장치에 정의된 임계치를 넘어서면, 추가로 도달한 모든 호출은 처리가 중단됨
• API 에 처리율 제한 장치를 두면 좋은 점
  • DoS 공격에 의한 자원 고갈 방지
  • 비용 절감
    • 우선순위가 높은 API에 더 많은 자원을 할당할 수 있음
  • 서버 과부하
    • 봇에서 오는 트래픽이나 사용자의 잘못된 이용패턴으로 유발된 트래픽을 걸러내는 데 활용할 수 있음

1단계. 문제 이해 및 설계 범위 확정

• 서버측 API를 위한 장치
• 다양한 형태의 제어규칙을 정의할 수 있는 유연한 시스템

  ❓어떤 사례가 있을까?

• 대규모 요청 처리할 수 있어야 함
• 분산 환경에서 동작해야 함
• 한 서버에 대해 제어 규칙이 바뀔 수도 있다는 전제
• 독립된 서비스 or 애플리케이션 코드 포함할 것인가?
• 사용자의 요청이 걸러진 경우, 사용자에게 그 사실을 알려야 함

요구사항

• 낮은 응답시간
• 가능한 한 적은 메모리
• 분산형 처리율 제한 : 여러 서버나 프로세스에서 공유할 수 있어야 함
• 예외 처리
• 높은 결함 감내성 : 제한 장치에 장애가 생겨도 전체 시스템에 영향을 주어서는 안됨

2단계. 개략적 설계안 제시 및 동의 구하기

처리율 제한 장치는 어디에 둘 것인가?

• 클라이언트 측에 둘 경우, 클라이언트 요청은 쉽게 위변조가 가능해서 모든 클라이언트의 구현을 통제하는 것이 어려울 수 있다
• 처리율 제한 장치를 API 서버에 두는 대신 처리율 제한 미들웨어를 만들어 처리할 수도 있다.
• 마이크로서비스의 경우, 처리율 제한 장치는 보통 API 게이트웨이에 구현된다.

  ❓ 마이크로서비스가 아닌 경우에는 보통 어디에 구현되는가?

처리율 제한 알고리즘

토큰 버킷 알고리즘

• 간단하고, 인터넷 기업들이 보편적으로 사용하고 있다
• 아마존, 스트라이프가 API 요청을 통제하기 위해 이 알고리즘 사용한다
• 동작 원리
  • 토큰 버킷 : 지정된 용량을 갖는 컨테이너
  • 해당 버킷에 사전 설정된 양의 토큰이 주기적으로 채워짐
  • 토큰이 꽉 찬 버킷에는 더이상 토큰이 추가되지 않음
  • 버킷이 가득차면 추가 공급된 토큰은 버려짐
  • 각 요청은 처리될 때마다 1개의 토큰 사용
    • 충분한 토큰이 있다면, 버킷에서 토큰을 꺼낸 후 요청을 시스템에 전달
    • 충분한 토큰이 없다면, 해당 요청은 버려짐
• 토큰 버킷 알고리즘은 2가지 인자를 받는다
  • 버킷 크기 : 버킷에 담을 수 있는 토큰 최대 갯수
  • 토큰 공급률 : 초당 몇 개의 토큰이 버킷에 공급되는지

    토큰 공급률이 결국 처리량과 관련있는 지표이므로, 얘도 경계에 요청이 몰리는 문제는 해결 불가능

• 통상적으로 API 엔드포인트마다 별도의 버킷을 둔다
• 장점
  • 구현이 쉽다
  • 메모리 사용 측면에서 효율적이다

    1. 단순한 데이터 구조 : 버킷 크기와 현재 토큰 수만 관리하면 됨 (레디스)
    2. 누출 버킷 알고리즘과 달리 개별 요청을 큐에 저장할 필요 없어 메모리 사용 줄일 수 있음

  • 짧은 시간에 집중되는 트래픽도 처리 가능하다. 버킷에 남은 토킷만 있으면 요청은 시스템에 전달된다.

    단기간 집중되는 트래픽 처리 불가능한 알고리즘 == 누출 버킷 알고리즘
    토큰 버킷 알고리즘은 초당 10만개의 토큰이 공급된다면

    • 0.1초만에 10만 개의 요청이 와도 처리가능.
    • 0.9초동안 온 5만개의 요청은 버려짐
      

    하지만 누출 버킷 알고리즘 (요청 수용 가능한 큐 크기 :15만개 / 처리율 10만개라면) 은 0.1초만에 10만개의 요청이 올 경우 0.9초동안 온 나머지 5만개의 트래픽 요청은 큐에 담겨 있다가 1초뒤에 처리됨

• 단점
  • 버킷 크기, 토큰 공급률이라는 2가지 인자를 적절히 튜닝하는 것이 어렵다

    버킷 크기 : 머신 러닝이나 예측 알고리즘을 사용하여 감지된 패턴에 따라 버킷 크기 동적 조절 필요

    • Akamai의 2023년 연구에 따르면, 동적 토큰 버킷 크기 조정은 전자상거래 애플리케이션의 피크 트래픽 기간 동안 지연 시간을 15% 감소시켜 고객 만족도를 향상시켰다고 함
      

    토큰 공급률 : 예상 평균 트래픽과 일치해야 함.

    • 분당 100개의 요청이 예상되는 API는 분당 약 100개의 토큰을 허용하되, 약간 더 높은 버스트 허용치를 두어야 함

    실제 적용 사례

    1. Twitter의 API 관리

    • 도전 과제: Twitter는 개발자들에게 관대한 API 한도를 제공하면서도 남용을 방지해야 함
    • 해결책: 토큰 버킷 알고리즘을 구현하여 높은 API 트래픽을 관리하고 조용한 시간대에는 버스트를 허용. 사용자 행동에 따라 버킷 크기를 동적으로 조정하여 공정성과 성능의 균형을 맞춤
    • 결과: Twitter는 정당한 개발자들의 원활한 경험을 유지하면서 API 남용 사건을 40% 줄임

    2. Zoom의 대역폭 관리

    • 도전 과제: Zoom은 팬데믹 기간 동안 대규모 트래픽 급증을 경험했고, 이는 인프라에 부담을 주었음
    • 해결책: 토큰 버킷 메커니즘으로 비디오 스트리밍 대역폭을 제어하여 고해상도 스트림을 위한 짧은 버스트를 허용하면서 피크 사용 시간 동안 지속적인 트래픽을 제한
    • 결과: Zoom은 고트래픽 기간 동안 서비스 중단을 최소화하고 대역폭 관련 불만을 25% 줄임

    Reference; https://medium.com/@keployio/the-importance-of-the-token-bucket-algorithm-key-strategies-and-best-practices-for-businesses-faeb52c597d2

누출 버킷 알고리즘

• 누출 버킷 알고리즘은 토큰 버킷과 비슷하지만 요청 처리율이 고정되어 있다는 점이 다르다

  요청 처리율이 고정되어 있다 == 지정된 시간당 처리 가능한 양 (처리율) 이 고정되어 있어서 트래픽이 몰리더라도, 한번에 처리되지 않고 처리율에 따라 일정하게 출력된다

• 보통 FIFO 큐로 구현한다
• 동작 원리
  • 요청이 도착하면 큐가 가득 차 있는지 확인. 빈자리가 있는 경우에는 큐에 요청을 추가
  • 큐가 가득 차 있는 경우에는 새 요청은 버림
  • 지정된 시간마다 큐에서 요청을 꺼내어 처리 (처리율)
• 누출 버킷 알고리즘은 2가지 인자를 사용한다
  • 버킷 크기 : 큐 사이즈와 동일
  • 처리율 : 지정된 시간 당 몇 개의 항목을 처리할지 지정하는 값. 보통 초 단위로 표현
• 장점
  • 큐의 크기가 제한되어 있어서 메모리 사용량 측면에서 효율적
  • 고정된 처리율을 가지므로 안정적 출력이 필요한 경우가 적합하다.
• 단점
  • 단시간 트래픽이 몰릴 경우, 오랜 요청이 쌓여 최신 요청이 버려진다.
  • 토큰 버킷과 마찬가지로 2개의 파라미터를 올바르게 튜닝하기 어렵다.

고정 윈도 카운터 알고리즘

• 동작 원리

  • 타임라인을 고정된 간격의 윈도로 나누고, 각 윈도마다 카운터를 붙임
  • 요청이 접수될 때마다 이 카운터의 값은 1씩 증가
  • 이 카운터의 값이 사전에 설정된 임계치에 도달하면 새로운 요청은 새 윈도가 열릴 때까지 버려짐

• 이 알고리즘의 가장 큰 문제는 윈도의 경계 부근에 순간적으로 많은 트래픽이 집중될 경우, 윈도에 할당된 양보다 더 많은 요청이 처리될 수 있다는 점이다.

• 장점

  • 메모리 효율이 좋다

    레디스를 활용해서 카운터 값만 저장하고 있으면 됨

  • 이해하기 쉽다
  • 윈도가 닫히는 시점에 카운터를 초기화하는 방식은 특정한 트래픽 패턴을 처리하기에 적합하다.

    ❓어떤 트래픽 패턴?

• 단점

  • 윈도 경계 부근에서 일시적으로 많은 트래픽이 몰려드는 경우, 기대했던 시스템의 처리 한도보다 많은 양의 요청을 처리하게 됨

이동 윈도 로깅 알고리즘

• 이동 윈도 로깅 알고리즘은 고정 윈도 카운터 알고리즘의 문제인, 윈도 경계 부근에 트래픽이 집중되는 경우 시스템에 설정된 한도보다 많은 요청을 처리하는 것을 해결한다.
• 동작 원리
  • 요청의 타임스탬프를 추적한다. 타임스탬프 데이터는 보통 레디스의 정렬 집합 같은 캐시에 보관한다.
  • 새 요청이 오면 만료된 타임스탬프는 제거 (만료된 타임스탬프 == 현재 윈도 시작 시점보다 오래된 타임스탬프)
    • ex. 1:01:40 에 새로운 요청이 오면 만료된 타임 스탬프 (== 1:01:40 요청의 현재 윈도 시작 시점인 1:00:40 이전 요청) 인 1:00:01, 1:00:30 제거
  • 새 요청의 타임스탬프를 로그에 추가

    그러면 1:01:31 에 요청이 들어온 순간 1:00:50 요청, 1:01:31 의 요청이 둘다 시스템에 전달됨
    1:01:42 에 새 요청이 들어오면 1:00:42 ~ 1:01:42 사이의 로그가 3이니까 1:01:42 도 요청 거부됨 즉, 이동 윈도 로깅 알고리즘은 호출 횟수를 제한한다 (=요청량을 제한 / 처리율 제한 x)

  • 로그의 크기가 허용치보다 같거나 작으면 요청을 시스템에 전달. 그렇지 않은 경우에는 처리 거부
• 장점
  • 어느 순간의 윈도를 보더라도, 허용되는 요청의 개수는 시스템 처리율 한도를 넘지 않음
• 단점
  • 거부된 요청의 타임스탬프도 보관하기 때문에 다량의 메모리를 사용함.

    ❓개선 가능한 방법은 없을까?

이동 윈도 카운터 알고리즘

• 고정 윈도 카운터 알고리즘과 이동 윈도 로깅 알고리즘을 결합한 것이다.

  고정 윈도 카운터 알고리즘의

  • 윈도 개념
  • 카운터 사용
  • 메모리 효율성
    

  이동 윈도 로깅 알고리즘의

  • 윈도 경계에서 발생할 수 있는 트래픽 문제 해결
  • 이전 윈도 데이터 활용

• 현재 윈도에 몇 개의 요청이 온 것인지 계산하는 방법
  • 현재 1분간의 요청 수 + 직전 1분간의 요청 수 x 이동 윈도와 직전 1분이 겹치는 비율
  • 반올림 혹은 내림하여 쓸 수 있음
• 장점
  • 이전 시간대의 평균 처리율에 따라 현재 윈도의 상태를 계산하므로 짧은 시간에 몰리는 트래픽에도 잘 대응한다.
  • 메모리 효율이 좋다.

    1. 거부된 요청 타임스탬프를 보관하는 이동 윈도 로깅 알고리즘보다 좋다
    2. 카운터를 사용하는 알고리즘 자체가 좋다 (고정 윈도 카운터 알고리즘에도 동일한 장점이 적혀 있음)

• 단점
  • 직전 시간대에 도착한 요청이 균등하게 분포되어 있다고 가정한 상태에서 추정치를 계산하기 때문에 다소 느슨하다.

개략적인 아키텍처

• 처리율 제한 알고리즘의 기본 아이디어
  • 얼마나 많은 요청이 접수되었는지 추적할 수 있는 카운터를,
  • 추적 대상별 (사용자별 / IP주소별 / API 엔드포인트나 서비스 단위) 로 두고,
  • 카운터의 값이 어떤 한도를 넘어서면 한도를 넘어 도착한 요청은 거부하는 것이다
• 카운터를 보관하는 곳은 메모리상에서 동작하는 캐시가 바람직하다
  • 빠른데다 시간에 기반한 만료 정책을 지원하기 때문이다
• 동작 원리
  • 클라이언트 -> 처리율 제한 미들웨어에게 요청 전송
  • 처리율 제한 미들웨어는 레디스의 지정 버킷에서 카운터를 조회, 한도 도달 여부 검증
  • 도달하지 않았다면 요청을 API 서버로 전달, 미들웨어는 카운터 값을 증가시킨 후 다시 레디스에 저장

3단계. 상세 설계

• 처리율 제한 규칙은 어덯게 만들어지고 어디에 저장되는가?
• 처리가 제한된 요청들은 어떻게 처리되는가?

처리율 제한 규칙

• 규칙들은 보통 설정 파일 형태로 디스크에 저장된다

처리율 한도 초과 트래픽의 처리

• 요청이 한도 제한에 걸리면 API 는 HTTP 429 응답을 클라이언트에게 보낸다

처리율 제한 장치가 사용하는 HTTP 헤더

• 아래와 같은 HTTP 응답헤더를 Response 에 담아 클라이언트에 반환

  X-RateLimit-Remaining: 59 // 윈도 내에 남은 처리 가능 요청 수
  X-RateLimit-Limit: 60 // 매 윈도마다 클라이언트가 전송할 수 있는 요청 수
  X-RateLimit-Retry-After: 100 // 한도 제한에 걸리지 않으려면 몇 초 뒤에 요청을 다시 보내야 하는 지 알림

상세 설계

• 처리율 제한 규칙은 디스크에 보관하며, 작업 프로세스는 수시로 규칙을 디스크에서 읽어 캐시에 저장한다
  • ❓ 수시로라면 얼마나 잦은 주기로 읽는거지?
• 클라이언트가 요청을 보내면 먼저 처리율 제한 미들웨어에 도달한다.
• 처리율 제한 미들웨어는 제한 규칙을 캐시에서 가져온다.

분산 환경에서의 처리율 제한 장치의 구현

경쟁 조건

• 경쟁 조건 문제를 해결하는 가장 널리 알려진 해결책은 락(lock)이다. 하지만 락은 시스템의 성능을 상당히 떨어뜨린다는 문제가 있다.
• 위 설계에서 락 대신 쓸 수 있는 해결책이 2가지 있는데, 루아 스크립트와 정렬 집합이라고 불리는 레디스 자료구조를 쓰는 것이다.
  • ❓ 루아스크립트, 정렬집합 찾아보기

동기화 이슈

• 수백만 사용자를 지원하려면 처리율 제한 장치 서버 한대로는 충분하지 않을 수 있다.
• 웹계층은 무상태이므로 클라이언트는 요청을 각기 다른 제한장치로 보낼 수 있기 때문에 모든 처리율 제한 장치 서버의 동기화가 필요해진다.
• 1가지 해결책은 고정 세션을 활용하여 같은 클라이언트로부터의 요청은 항상 같은 처리율 제한 장치로 보낼 수도 있다
  • 하지만 규모면에서 확장 불가하며 유연하지 않다
• 더 나은 해결책으로는 레디스와 같은 중앙 집중형 데이터 저장소를 쓰는 것이다

성능 최적화

• 여러 데이터 센터를 지원하는 문제는 처리율 제한 장치에 매우 중요하다
• 데이터센터에서 멀리 떨어진 사용자를 지원하려다보면 지연시간이 증가할 수밖에 없기 때문이다
  • 사용자의 트래픽을 가장 가까운 에지 서버로 전달하여 지연시간을 줄여야 한다
• 제한 장치 간에 데이터를 동기화할 때 최종 일관성 모델을 사용해야 한다

모니터링

• 채택한 알고리즘이 효과적인지, 정의했던 제한 규칙이 효과적인지를 기본적으로 확인해야한다.
• 제한 규칙이 너무 빡빡하면 많은 유효한 요청이 처리되지 못할 수도 있다는 점을 알아야 한다.
• 깜짝 세일 때문에 트래픽이 급증할 때 토큰 버킷 알고리즘으로 바꾸는 등 트래픽 패턴에 맞는 알고리즘 변경을 고려해야 한다.

4단계. 마무리

• 경성 또는 연성 처리율 제한
  • 경성 처리율 제한: 요청 개수는 임계치를 절대 넘길 수 없다.
  • 연성 처리율 제한: 요청 개수는 잠시 동안은 임계치를 넘어설 수 있다.
    • ❓ 실 사용 예시 + 기준을 어떻게 설정할까
• 다양한 계층에서의 처리율 제한
  • 이번장에서는 애플리케이션 계층에서의 처리율 제한에 대해서만 살펴보았지만 다른 계층에서도 처리율 제한이 가능하다.
  • iptables를 사용해 IP 주소 (3번 네트워크 계층) 를 기준으로 처리율을 제한 할 수도 있다.
    • ❓ 실제 예시 찾아보기
• 처리율 제한을 회피하는 방법. 클라이언트를 어떻게 설계하는 것이 최선인가?
  • 클라이언트 측 캐시를 사용해서 API 호출 횟수를 줄인다.
  • retry 로직을 구현할 때는 충분한 back-off 시간을 둔다.
    • ❓ back off 의 개념

• 시스템 설계 면접에는 정해진 결말도 없고, 정답도 없다.
• 설계 기술을 시연하는 자리이고, 설계 과정에서 내린 결정들에 대한 방어 능력을 보이는 자리이다.
• 면접관의 피드백을 건설적인 방식으로 처리할 자질이 있음을 보이는 자리이다.
• 시스템 설계 면접이 잘 진행되면, 지원자가 협력에 적합한 사람인지, 압박이 심한 상황도 잘 헤쳐나갈 자질이 있는지, 모호한 문제를 건설적으로 해결할 능력이 있는지 등을 살펴볼 수 있다
• 설계의 순수성에 집착한 나머지 타협적 결정을 도외시하고 과도한 엔지니어링을 하고 마는 엔지니어들이 현업에도 많다

✅ 오버 엔지니어링의 위험을 피할 수 있는 방법
1. 기술 의사 결정 과정 기록하기

• 다음과 같은 패턴을 보인다면, 기술 부채가 계속 쌓이면서 오버 엔지니어링이 일어날 가능성이 높다
  • 해결할 문제와 솔루션에 대한 충분한 검토없이 기술 도입 결정
  • 잘못된 선택이나 변화에 대한 두려움 때문에 필요한 결정을 하지 않음
  • 의사 결정 과정이 투명하지도 추적되지도 않아 중복된 논의가 계속됨
    
• 이런 경우, 아키텍처 결정 기록 (Architectural Decision Records, ADR) 프로세스를 사용할 수 있다.
  • ADR : 소프트웨어 아키텍처에 필요한 구성 요소에 대한 의사 결정, 동기 및 맥락 및 그리고 결과에 대해 설명하는 간단한 문서
  • ADR 프로세스를 사용함으로써 동일한 기술 주제에 대한 반복적인 토론을 방지하고, 기존 직원 혹은 신규 입사자에게 기술 도입 과정을 효과적으로 전달할 수 있다
• “왜, RDB가 아니라 NoSQL을 선택했는지, 왜 구현 방법으로 Amazon DynamoDB를 선택했는지”, “왜 쿠버네티스를 선택했는지, 왜 운영 방법으로 Amazon EKS를 선택했는지”, “왜, API의 도메인 범위를 이렇게 나누었는지” 등등 각 의사 결정 사항을 ADR 문서로 저장한다
• ADR 문서는 다양한 템플릿이 존재하는데, 보통 ‘문제에 대한 정의’, ‘의사 결정에 대한 동기 및 맥락’, ‘최종 결정 사항’, ‘예상 결과’, ‘결정 참여자’ 등의 항목을 짧더라도 구체적으로 담아야 한다.

2. 해결하려는 문제 정확히 파악하기

• 해결하려는 문제에 대해 정의를 내리고, 도입하려는 기술에 대한 동기와 맥락을 정확히 알아야만 올바른 의사 결정을 할 수 있다
• ex) 매일 발생하는 대량 로그 처럼 일회적인 쓰기 사용량이 높다고 해서 무턱대고 NoSQL을 선택하는 경우
  • 쓰기 이후에도 읽기나 분석 요구가 많은 경우라면, 간단한 파일 저장소나 Elasticsearch 같은 다른 솔루션을 고려할 필요도 있음.

3. 문제 해결 기술 후보를 선정하고 테스트하기

• 몇 가지 후보를 선택하고 이를 테스트한 후, 나온 결과를 보고 선택해야 해야 한다
  

추가적으로 가끔 오버엔지니어링 처럼 보이는 것이 필요할 때도 있다. 예를 들어, 시스템 보안이나 개인 정보 보호 같은 영역은 법적인 규정 준수 문제들이 있기 때문에 현재 가지고 있는 것 보다 더 많은 고려가 필요하다.

✅ 오버 엔지니어링에 대한 현직자의 생각
확장이나 축소 가능한 상태를 유지하는게 핵심
ex) 현 요구사항보다 +a 를 구현했더라도 축소 가능한 상태로 설계가 되어 있다면 괜찮음.
(from. https://youtu.be/yDOT2-6KPZc?si=nOAjBWaujwo0FJZ2)

효과적 면접을 위한 4단계 접근법

1단계 : 문제 이해 및 설계 범위 확정

• 요구사항을 완전히 이해하지 않고 답을 내놓는 행위는 아주 엄청난 부정적 신호다
• 답부터 들이밀지 말라. 속도를 늦춰라. 깊이 생각하고 질문하여 요구사항과 가정들을 분명히 하라
• 엔지니어가 가져야 할 가장 중요한 기술
  • 올바른 질문을 하는 것
  • 적절한 가정을 하는 것
  • 시스템 구축에 필요한 정보를 모으는 것
• 요구사항을 정확히 이해하는 데 필요한 질문을 하라
  • 구체적으로 어떤 기능인가?
  • 제품 사용자 수는?
  • 회사의 규모는 얼마나 되리라 예상하는가?
  • 회사가 주로 사용하는 기술스택은?
• 요구사항을 이해하고 모호함을 없애는 게 이 단계에서 가장 중요하다

2단계 : 개략적인 설계안 제시 및 동의 구하기

• 설계안에 대한 최초 청사진을 제시하고 의견을 구하라
• 핵심 컴포넌트를 포함하는 다이어그램을 그려라
• 최초 설계안이 시스템 규모에 관계된 제약 사항들을 만족하는지를 개략적으로 계산해보라

3단계 : 상세 설계

• 면접관과 해야할 일은 설계 대상 컴포넌트 사이의 우선순위를 정하는 것이다
  • 대부분의 경우 면접관은 특정 시스템 컴포넌트들의 세부사항을 깊이 있게 설명하는 것을 보길 원한다
• 불필요한 세부사항에 시간을 쓰지 말라

4단계 : 마무리

• 만든 설계를 다시 한번 요약해주는 것도 도움이 될 수 있다
• 오류가 발생하면 무슨 일이 생기는지 (서버 오류, 네트워크 장애 등) 따져보자
• 메트릭은 어떻게 수집하고 모니터링은 어떻게 할 것인가? 로그는? 시스템은 어떻게 배포해 나갈 것인가?

  ❓ 시스템의 배포 방식 종류

• 규모 확장 요구에 어떻게 대처할 것인가?

해야할 것

• 질문을 통해 확인하라. 스스로 내린 가정이 옳다 믿고 진행하지 말라
• 요구사항을 정확히 이해했는지 다시 확인하라
• 면접관과 소통하라
• 가능하다면 여러 해법을 함께 제시하라
• 가장 중요한 컴포넌트부터 진행하라
• 면접관의 아이디어를 이끌어내라
• 포기하지 말라

하지 말아야 할 것

• 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말라
• 개략적 설계를 마친 뒤에 세부사항으로 나아가라
• 소통을 주저하지 말라

시간 배분

• 1단계 - 문제 이해 및 설계 범위 확정 (3~10분)
• 2단계 - 개략적인 설계안 제시 및 동의 구하기 (10~15분)
• 3단계 - 상세 설계 (10~25분)
• 4단계 - 마무리 (3~5분)

• 개략적 규모 추정 : 추정치를 계산하는 행위로서, 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것

모든 프로그래머가 알아야 하는 응답지연 값

• L1 캐시 참조
• 분기 예측 오류

  ✅ 분기 예측 오류란

  • 분기 예측 : 다음 실행될 조건문이 어떤 곳으로 분기할 것인지를 확실히 알게 되기 전에 미리 추측하는 CPU 기술
  • 파이프라인 병목
    • cpu는 효율성을 위해 파이프라인(pipeline) 이라는 구조를 사용한다
    • 이 파이프라인에 명령어(코드)를 한줄 한줄 집어넣어서 동작하는데, if문 (분기문) 을 만나면 다음에 오는 명령어는 2가지 경우의 수가 생긴다.
    • 이 다음에 올 명령어를 if문이 계산되기 전 까지 알 수 없으므로 cpu는 if 문이 계산되는 동안 놀게 된다. (파이프라인이 속도가 느려지는 경우 : control hazard)
  • 파이프라인 병목을 해결하기 위한 방법 -> 분기 예측
  • 만약 파이프라인이 조건 값의 계산이 끝날 때까지 대기한다면, 조건 분기 명령이 전체 파이프라인을 통과할 때까지 다음 명령은 파이프라인에서 수행되지 못하고 대기하게 될 것이다.
    분기 예측기는 이런 낭비를 막기 위해 단순한 알고리즘에 따라 다음 명령을 미리 추론한 후 미리 실행시킨다.
    • 분기 예측기의 예측이 맞을 경우 -> 파이프라인은 낭비 없이 계속 수행
    • 분기 예측기의 예측이 틀릴 경우 -> 미리 실행되던 명령이 파이프라인에서 모두 취소되고 올바른 명령이 다시 실행
  • ✅ 분기 예측 오류 : 분기 예측기가 올바른 예측에 실패하면 파이프라인의 개수 만큼의 클럭 주기가 낭비된다. 복잡한 파이프라인 구조를 가진 현대 아키텍처에서는, 분기 예측기가 실패하면 10-20 클럭 주기가 낭비된다.
  • 조건 분기문이 처음 파이프라인에 들어왔을 때 활용할 수 있는 정보는 많지 않다.
    분기 예측기는 해당 조건 분기문이 분기한 이력이나 루프 구조, 함수 구조 등의 정보를 바탕으로 다음 분기를 예측한다.
  • reference; https://m.blog.naver.com/ektjf731/223052793786?recommendTrackingCode=2
    https://blog.skby.net/%ED%8C%8C%EC%9D%B4%ED%94%84%EB%9D%BC%EC%9D%B8-%EB%B6%84%EA%B8%B0%EC%98%88%EC%B8%A1%EA%B3%BC-%EC%98%88%EC%B8%A1%EC%8B%A4%ED%96%89/

• zippy 로 1KB 압축

  ✅ Zippy 에 대하여

  • zippy는 메모리 내 데이터를 직접 압축할 수 있는 기능을 제공하므로, 파일 시스템을 거치지 않고도 압축할 수 있음
  • zippy는 기본적으로 deflate 압축 알고리즘 사용 -> 이는 ZIP 형식에서 가장 일반적으로 사용되는 압축 방식
  • deflate : 널리 사용되는 무손실 데이터 압축 알고리즘

• 메모리는 빠르지만, 디스크는 아직 느리다
• 디스크 탐색은 가능한 한 피하라
• 단순한 압축 알고리즘은 빠르다
• 데이터를 인터넷으로 전송하기 전, 가능한 압축하라
• 데이터 센터는 보통 여러 지역에 분산되어 있으며, 센터간 데이터 주고받는 데 시간이 소요된다

가용성에 관계된 수치들

• 고가용성 : 시스템이 오랜 시간동안 지속적으로 중단 없이 운영될 수 있는 능력
• 대부분 서비스는 99% ~ 100% 사이의 값을 갖는다
• SLA (Service Level Agreement) : 서비스 사업자와 고객 사이에 맺어진 합의
  • 서비스 사업자가 제공하는 서비스 가용시간이 공식적으로 기술됨

예제 : 트위터 QPS 와 저장소 요구량 추정

• Query Per Second란
  • 데이터베이스나 웹 서버 API 등에서 특정 작업이나 요청이 초당으로 얼마나 처리되는지를 나타내는 지표
• QPS(Query Per Second) 추정치
  • 일간 능동 사용자 = 월간 능동 사용자 * 50% = 1.5억
  • QPS = 일간 능동 사용자 * 2트윗 / (24시간 * 3600초) = 약 3500
  • 최대 QPS = 2 * QPS = 약 7000

    ✅ 최대 QPS (peek QPS)

    • 최대 QPS : 시스템이 처리해야 할 것으로 예상되는 최고 쿼리 비율을 나타내며, 주로 사용량이 많거나 트래픽이 급증하는 시기에 발생
    • 파레토 법칙은 많은 성과에서 결과의 약 80%가 20%의 원인에서 발생
    • ex) 예상 분포 특성을 기반으로 계산하여, 많은 시스템에서 하루 중 20%의 시간 동안 80%의 트래픽이 발생한다고 가정할 수 있음 (파레토 원칙을 변형) 이러한 패턴을 고려하면 평균 QPS의 2배 정도가 최대 QPS로 나타날 수 있음
    • 왜 2를 곱했을까?
      • 2배라는 수치는 절대적인 규칙은 아니고, 실제 시스템의 특성, 과거 데이터, 예상되는 성장률 등을 고려하여 적절한 배수를 선택해야 함 (일부 시스템에서는 1.5배나 3배를 사용하기도 함)

팁

• 근사치를 활용한 계산
• 가정을 적어두라
• 단위를 붙이라
• QPS, 최대 QPS, 저장소 요구량, 캐시 요구량, 서버 수 등을 추정하는 문제가 많이 출제된다

단일 서버

• 웹 앱, 데이터베이스, 캐시 등이 전부 서버 한대에서 실행된다

1. 사용자는 도메인 이름을 이용하여 웹사이트에 접속
   • 접속을 위해서는 도메인 이름을 도메인 이름 서비스 (DNS) 에 질의하여 IP 주소로 변환하는 과정 필요
2. DNS 조회 결과로 웹 서버의 IP 주소 반환
3. 해당 IP 주소로 HTTP 요청 전달
4. 요청을 받은 웹 서버는 HTML 페이지나 JSON 형태의 응답 반환

데이터베이스

• 사용자가 늘면 서버 하나로는 충분하지 않아 여러 서버를 두어야 한다
  • 웹/모바일 트래픽 처리 용도
  • 데이터베이스용

어떤 데이터베이스를 사용할 것인가?

• 비관계형 데이터베이스는 흔히 NoSQL로 불리며 Cassandra, Amazon DynamoDB 등이 있다
• NoSQL은 키-값 저장소, 그래프 저장소, 칼럼 저장소, 문서 저장소 등으로 분류된다.

  reference ; https://ganganichamika.medium.com/deep-dive-into-nosql-database-types-80340598124

  • 키-값 저장소
    • 데이터가 키와 값의 쌍으로 저장
      
    • 대표적인 데이터베이스: Redis, Riak, Amazon DynamoDB
      
  • 칼럼 저장소
    • 데이터가 로우(키 값), 컬럼 패밀리, 컬럼 이름으로 구성
      
    • 2차원 키-값 저장소
      
    • 대표적인 데이터베이스: HBase, Cassandra, Hypertable
  • 문서 저장소
    
    • 키-값 모델을 확장한 형태로, 데이터가 문서(보통 JSON이나 XML 형식) 형태로 저장
      
    • 대표적인 데이터베이스: MongoDB, CouchDB
      

• 비관계형 데이터베이스는 일반적으로 조인 연산은 지원하지 않는다
• 비관계형 데이터베이스가 바람직한 선택인 경우
  • 아주 낮은 응답 지연시간이 요구될 때

    

    reference ; https://velog.io/@park2348190/%EB%85%BC%EB%AC%B8%EB%B2%88%EC%97%AD-SQL-vs-NoSQL-A-Performance-Comparison
    

    • NoSQL 데이터베이스는 일반적으로 밀리초(ms) 단위의 매우 낮은 응답 지연시간을 제공할 수 있다

  • 다루는 데이터가 비정형이라서 관계형 데이터가 아닐 때

    비정형 데이터 : 미리 정의된 데이터 모델이나 스키마가 없는 데이터

    • 텍스트 파일 (워드 문서, PDF 등)
    • 멀티미디어 파일 (이미지, 오디오, 비디오)
    • 소셜 미디어 게시물
    • 이메일 내용
    • 센서 데이터
    • 로그 파일
      

    이러한 데이터는 고정된 스키마를 가진 관계형 데이터베이스에 저장하기 어려우므로, 유연한 스키마를 제공하는 NoSQL 데이터베이스를 활용하여 다양한 형태의 데이터를 쉽게 저장 및 관리 가능

  • 데이터를 직렬화하거나 역직렬화만 하면 될 때

    NoSQL 데이터베이스, 특히 문서 저장소는 JSON, YAML, XML 등의 형식으로 데이터를 직접 저장 가능 -> 객체와 저장 형식 간의 변환 작업이 줄어듦

  • 아주 많은 양의 데이터를 저장할 필요가 있을 때

    일반적으로 테라바이트(TB) 또는 페타바이트(PB) 규모의 데이터를 다룰 때 NoSQL이 유리할 수 있다

    • NoSQL이 대용량 데이터 처리에 유리한 이유
      • 수평적 확장성: 새로운 서버를 추가하여 쉽게 용량을 늘릴 수 있다
      • 분산 아키텍처: 데이터를 여러 노드에 분산 저장하여 대규모 병렬 처리 가능
      • 스키마 유연성: 다양한 형태의 대용량 데이터를 효율적으로 저장 가능
      • 높은 쓰기 성능: 많은 NoSQL 데이터베이스는 대량의 쓰기 작업에 최적화되어 있음

수직적 규모 확장 vs 수평적 규모 확장

• 스케일 업 (수직적 규모 확장) : 서버에 고사양 자원 (더 좋은 CPU, 더 많은 RAM 등) 을 추가하는 것
• 스케일 아웃 (수평적 규모 확장) : 더 많은 서버를 추가하여 성능을 개선하는 것
• 서버로 유입되는 트래픽 양이 적을 때는 스케일 업이 좋은 선택이다.

  트래픽 양이 "적다"는 것에 대한 정확한 수치 기준은 없고 상황에 따라 상대적이며, 다음과 같은 요소들을 고려할 수 있다.

  1. 현재 서버의 성능: CPU, 메모리, 디스크 I/O 등의 리소스 사용률이 낮은 수준(예: 50% 미만) 유지
  2. 응답 시간: 사용자에게 허용 가능한 응답 시간 내에 서비스를 제공 가능
  3. 동시 사용자 수: 일반적으로 수천 명 이하의 동시 사용자를 처리할 수 있다면 단일 서버로 충분할 수 있음
  4. 성장률: 트래픽이 급격히 증가하지 않고 안정적이거나 완만하게 증가한다면 스케일 업으로 대응 가능
  5. 비용 효율성: 스케일 업이 스케일 아웃보다 비용 효율적인 경우
  6. 애플리케이션의 특성: 일부 애플리케이션은 수직적 확장에 더 적합할 수 있다.
     • 단일 스레드 작업이 많은 경우 CPU 성능 향상이 효과적일 수 있음

• 다만 스케일 업에는 한계가 있다.
• 자동복구나 다중화 방안이 제시되지 않아 장애 발생 시 취약하다
• 따라서 대규모 애플리케이션을 지원하는 데는 스케일 아웃이 더 적절하다
• 너무 많은 사용자가 접속하여 웹 서버가 한계 상황에 도달하게 되면, 응답 속도가 느려지거나 서버 접속이 불가능해질 수도 있다
  • 이 때, 부하 분산기 또는 로드밸런서를 도입한다

로드밸런서

• 로드밸런서 : 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산해주는 역할을 한다
• 서버 접속 흐름
  • 사용자는 로드 밸런서의 공개 IP 주소로 접속 (웹 서버는 클라이언트 접속을 직접 처리하지 않음)
  • 로드밸런서는 웹 서버와 통신하기 위해 사설 IP 주소 이용
    • 사설 IP 주소 : 같은 네트워크에 속한 서버 사이의 통신에서만 쓰일 수 있는 IP 주소로, 인터넷을 통해서는 접속 불가능
• 로드밸런서의 부하 분산 집합에 웹서버를 추가하면 장애 자동 복구하지 못하는 문제 해소되며, 웹 계층 가용성 (시스템이 정상 사용 가능한 정도) 이 향상된다
  • 서버 1 다운 시 모든 트래픽은 서버 2 로 전송
  • 트래픽이 가파르게 증가할 경우, 웹 서버 계층에 더 많은 서버를 추가하기만 하면 로드밸런서가 자동적으로 트래픽을 분산하기 시작한다

    ✅ 로드밸런서의 트래픽 분산 원리

    • 각 서버의 상태(사용량, 처리 능력/용량 등)를 모니터링하고, 적절한 알고리즘을 사용하여 트래픽을 분산한다.
    • 로드밸런싱 알고리즘은 크게 2가지 범주로 나뉜다
      • 정적 로드 밸런싱 : 고정된 규칙을 따르며 현 서버 상태와 무관
        • 라운드 로빈 방식 : 클라이언트 요청 순서대로 서버를 배정하는 방식
        • 가중 라운드 로빈 방식 : 서버마다 가중치를 설정하고 가중치에 따라 서버를 배정하는 방식
        • IP 해시 방식 : 클라이언트 IP 주소를 해싱이라고 하는 계산을 수행하여 숫자로 변환하여, 개별 서버에 매칭해 처리
      • 동적 로드 밸런싱 : 서버의 현재 상태 검사
        • 최소 연결 방식 : 연결이 가장 적은 서버를 확인하고 해당 서버로 트래픽 전송
        • 최소 응답시간 방식 : 응답 속도가 빠른 서버부터 우선적으로 트래픽 로드 배분
        • 리소스 기반 방식 : 현재 서버 부하를 분석하여 트래픽 전송. 에이전트라고 하는 특수 소프트웨어는 각 서버에서 실행되며 컴퓨팅 용량 및 메모리와 같은 서버 리소스의 사용량을 계산하고, 해당 서버에 트래픽을 배포하기 전에 에이전트에 충분한 여유 리소스가 있는지 확인함
    • 가장 많이 사용되는 알고리즘은 ?
      • 라운드 로빈 방식은 구현이 간단하고 공평한 분배가 가능하다는 장점이 있어 많은 로드밸런서에서 기본적으로 사용되는 알고리즘
      • NGINX: NGINX는 웹 서버이자 로드밸런서로 널리 사용되며, 기본적으로 라운드 로빈 방식 사용
      • AWS Application Load Balancer (ALB): 이전에는 ALB가 라운드 로빈 알고리즘만을 사용하여 수신 요청을 백엔드 대상에 배포했음
      • HAProxy: 오픈 소스 로드밸런서
      • Apache HTTP Server mod_proxy_balancer: Apache의 로드밸런싱 모듈

데이터베이스 다중화

• 서버 사이에 주(master)-부(slave) 관게를 설정하고, 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식이다
• 쓰기 연산은 마스터에서만 지원한다
  • 부 데이터베이스는 주 데이터베이스로부터 사본을 전달받으며, 읽기 연산 만을 지원한다
• 대부분 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높다
  • 통상 부 데이터베이스의 수가 주 데이터베이스의 수보다 많다
• 데이터베이스를 다중화했을 때 얻을 수 있는 이득
  • 더 나은 성능
    • 읽기 연산은 부 데이터베이스 서버들로 분산되므로, 병렬로 처리될 수 있는 질의 수가 늘어나서 성능이 향상됨
  • 안정성
    • 자연 재해 등의 이유로 데이터베이스 서버가 파괴되어도 데이터는 보존됨 -> 지역적으로 떨어진 여러 장소에 다중화시켜 놓을 수 있기 때문
  • 가용성
    • 하나의 데이터베이스 서버에 장애가 발생해도, 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있음
• 부 서버가 1대 뿐인데 다운되었다면, 읽기 연산은 한시적으로 모두 주 데이터베이스로 전달된다. 또한 즉시 새로운 부 데이터베이스 서버가 장애 서버를 대체할 것이다

  ✅ 즉시 새로운 부 데이터베이스가 추가되니까, 장애가 난 부 서버를 대체한다는 건가 ? 즉시 어떻게 데이터베이스가 추가되지 ? 실제로는 새로운 서버를 준비하고 데이터를 동기화하는 데 어느 정도 시간이 소요된다. 이 기간 동안 시스템은 degraded mode(성능 저하 모드)로 운영될 수 있다.
  고가용성 시스템에서는 이러한 상황에 대비해 미리 준비된 대기 서버(standby server)를 두어 빠르게 전환할 수 있도록 하는 경우도 있음

  스탠바이 서버 (Standby Server)

  • 주로 고가용성(HA) 시스템에서 사용되는 용어
  • 주 서버(Primary/Master)의 장애 시 즉시 대체할 수 있도록 준비된 서버

  슬레이브 서버 (Slave Server):

  • 마스터-슬레이브 복제 구조에서 사용되는 용어
  • 마스터 서버의 데이터 변경사항을 복제하여 동기화하는 서버
    

  공통점

  • 데이터 동기화: 모두 주 서버(마스터)의 데이터 변경사항을 지속적으로 동기화
  • 읽기 전용 작업: 일반적으로 읽기 전용 쿼리를 처리 가능
  • 장애 대비: 주 서버 장애 시 대체 역할을 할 수 있음

  차이점

  • 스탠바이 서버는 주로 고가용성을 위해 사용되며, 즉시 주 서버로 전환될 수 있도록 준비된 상태를 유지
    • 슬레이브 서버는 주로 읽기 부하 분산을 위해 사용되며, 항상 마스터 서버의 복제본 역할을 함
    • PostgreSQL에서는 이러한 서버를 "standby server"라고 부르며, 데이터를 지속적으로 동기화하고 필요시 주 서버로 승격될 수 있음
    • 이 서버는 "warm standby" 또는 "hot standby" 모드로 운영될 수 있으며, 후자의 경우 읽기 전용 쿼리를 처리할 수 있음
    • 기본적으로 주 서버의 데이터를 복제하고 필요시 대체 역할을 하는 서버를 지칭한다고 볼 수 있음

• 주 데이터베이스 서버가 다운되면, 부 데이터베이스 서버가 새로운 주 서버가 될 것이다
  • 하지만 이 경우, 부 서버에 보관된 데이터가 최신상태가 아닐 수 있으므로 없는 데이터는 복구 스크립트 를 돌려서 추가하거나, 다중 마스터, 원형 다중화 방식을 도입하여 이런 상황에 대처할 수 있다

    다중 마스터

    • 여러 데이터베이스 서버가 동시에 마스터 역할을 수행하는 구조
      • 모든 노드가 읽기 및 쓰기 작업을 처리할 수 있음
      • 높은 가용성과 확장성 제공
      • 지리적으로 분산된 환경에서 유용
      • 데이터 충돌 해결 메커니즘 필요

    원형 다중화 방식

    • 데이터베이스 서버들이 원형 구조로 연결되어 데이터를 복제하는 방식
      • 각 노드는 다음 노드에 데이터를 복제
      • 마지막 노드는 첫 번째 노드에 데이터를 복제하여 원형 구조 형성
      • 단일 장애점(Single Point of Failure) 제거
      • 네트워크 트래픽 분산

캐시

• 캐시 : 값비싼 연산 결과 또는 자주 참조되는 데이터를 메모리 안에 두고, 뒤 이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소
• 애플리케이션 성능은 데이터베이스를 얼마나 자주 호출하느냐에 크게 좌우되는데, 캐시는 그런 문제를 완화할 수 있다

캐시 계층

• 캐시 계층 : 데이터가 잠시 보관되는 곳

  • 캐시 계층을 두면 성능이 개선될 뿐만 아니라, 데이터베이스 부하를 줄일 수 있고, 캐시 계층 규모를 독립적으로 확장시키는 것도 가능하다

    수평적 확장 (Scale-Out)

    • 가장 일반적인 방법으로, 캐시 서버의 수를 늘리는 것
    • 여러 캐시 서버를 클러스터로 구성하여 부하를 분산시킴
    • 일반적으로 consistent hashing (안정 해시) 알고리즘을 사용하여 데이터를 여러 캐시 서버에 분산 저장
      

    수직적 확장 (Scale-Up)

    • 개별 캐시 서버의 리소스를 증가시키는 방법
    • 메모리, CPU, 네트워크 대역폭 등을 증가시켜 단일 서버의 성능을 향상시킴

• 캐시 우선 읽기 전략 (read-through)

  • 요청 받은 웹서버가 캐시에 응답이 저장된지 확인
  • 캐시에 저장되어 있다면 해당 데이터를 클라이언트에 반환.
  • 없는 경우에는 데이터베이스 질의를 통해 데이터를 찾아 캐시에 저장 후 클라이언트에 반환

  계층화된 캐시 (Layered Caching) CPU Register > L1 Cache > L2 Cache > L3 Cache > RAM > SSD > HDD 순의 접근 속도를 지니는데, 이 중에 Redis가 사용하는 계층이 RAM이다.

  • Redis : 주로 메인 메모리 (RAM) 에 데이터를 저장하고 관리하는 인메모리 데이터 구조 저장소
  • L1 캐시: CPU 내부에 위치 / CPU 코어마다 별도로 존재하는 가장 빠른 속도로 접근할 수 있는 캐시
  • L2 캐시: L2 캐시는 CPU 회로판에 별도의 칩으로 내장된다. L1 캐시를 먼저 뒤지고, L2 캐시를 뒤져 데이터를 찾는다.
  • L3 캐시 : L2 캐시로 충분히 커버할 수 있기 때문에 웬만한 프로세서에서는 L3 캐시 메모리를 달고있지 않다. L1/L2 캐시 메모리 정도만 CPU 성능에 직접적인 영향을 미치기에 L3 캐시는 크게 신경쓰지 않는것이 일반적인 추세다. L3 캐시는 CPU가 아닌 메인보드에 내장되는 경우가 더 많다.

  지역 분산 캐시 (Geographically Distributed Cache)

  • 전 세계적으로 분산된 사용자를 위해 여러 지역에 캐시 서버를 배치
  • CDN과 유사한 개념으로, 사용자와 가까운 위치의 캐시 서버를 사용
    • Amazon ElastiCache for Redis를 사용하면 여러 AWS 리전에 걸쳐 글로벌 데이터 스토어를 구성 가능

캐시 사용 시 유의할 점

• 캐시가 바람직한 상황
  • 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우
• 캐시는 데이터를 휘발성 메모리에 두므로, 영속적으로 보관해야 하는 데이터는 캐시에 두면 안된다
  • 캐시 서버가 재시작되면 캐시 내의 모든 데이터는 사라진다
• 캐시에 보관된 데이터의 만료 정책을 어떻게 가져갈 것인가?
  • 만료 기한이 너무 짧으면 데이터베이스를 너무 자주 읽게 되고, 너무 길면 원본과 차이날 가능성이 존재한다

    ✅ 레디스의 만료기한 도래 시 데이터 삭제 정책 레디스는 기본적으로 TTL 이 만료된 데이터를 아래 2가지 방법으로 삭제

    • 주기적으로(100ms) 만료시간이 설정된 일부 키를 임의로 선택하여 만료여부를 확인 후 삭제
      • 레디스에 저장된 모든 키를 확인할 경우 CPU 부하가 심해진다. 레디스는 이를 막기위해 일부 키만을 선택하여 확인한다.
    • 만료된 데이터에 접근시 삭제
      • 키를 가져올 때 만료시간이 설정되어 있을 경우 만료여부를 확인한다. 만료되었다면 이 시점에 키를 삭제하고 아무것도 반환하지 않는다.

• 저장소 원본 갱신 연산과 캐시 갱신 연산이 단일 트랜잭션으로 처리되지 않는 경우, 일관성 (데이터 저장소의 원본과 캐시 내의 사본이 같은지 여부) 이 깨질 수 있다
• 캐시 서버를 한 대만 두면 SPOF 가 될 수 있다
  • 따라서 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다
• 캐시메모리가 너무 작으면 데이터가 너무 자주 캐시에서 밀려나 (eviction) 캐시의 성능이 떨어지게 된다
  • 캐시 메모리를 과할당하여 이 문제를 해결할 수 있다
• 데이터 방출 정책 : 캐시가 꽉 차면 추가로 캐시에 데이터를 넣어야할 경우 기존 데이터를 내보내야 하는 것
  • 가장 널리 쓰이는 정책 : LRU (Least Recently Used - 마지막으로 사용된 시점이 가장 오래된 데이터를 내보내는 정책)

    레디스의 데이터 방출 정책

    • noeviction: 메모리가 고갈된 경우 새로운 쓰기 작업을 하려고 할 때 에러를 반환한다.
    • allkeys-lru: 가장 최근에 사용되지 않은 키를 삭제한다.
    • allkeys-random: 키 공간에서 임의의 키를 삭제한다.
    • allkeys-lfu: 사용빈도가 적은 키를 삭제한다.
    • volatile-lru: 만료기간이 설정된 키 중에서 가장 최근에 사용되지 않은 키를 삭제한다.
    • volatile-random: 만료기간이 설정된 키 중에서 임의의 키를 삭제한다.
    • volatile-lfu: 만료기간이 설정된 키 중에서 사용빈도가 적은 키를 삭제한다.
    • volatile-ttl: 만료기간이 설정된 키 중에서 ttl 이 가장 짧은것을 삭제한다.

콘텐츠 전송 네트워크 (CDN)

• CDN : 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크
  • 이미지, 비디오, CSS, javascript 파일 등을 캐시할 수 있음
  • 동적 콘텐츠 캐싱 : 요청 경로, query string, cookie, request header 등의 정보에 기반하여 HTML 페이지를 캐시하는 것
• CDN 동작 원리
  • 사용자가 웹사이트 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달한다
  1. 사용자 A 가 이미지 URL 을 이용해 image.png 에 접근한다
  2. CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버는 원본 서버에 요청하여 파일을 가져온다 (원본 서버는 웹서버일 수도, 아마존 S3 같은 온라인 저장소일 수도...)
  3. 원본 서버가 파일을 CDN 서버에 반환한다
     • 응답 HTTP 헤더에는 해당 파일이 얼마나 오래 캐시될 수 있는지 설명하는 TTL (Time-To-Live) 값이 들어있다
  4. CDN 서버는 파일을 캐시하고 사용자에게 반환하며, 이미지는 TTL에 명시된 시간이 끝날 때까지 캐시됨
  5. 또다른 사용자가 같은 이미지에 대한 요청을 CDN 에 전송한다
  6. 만료되지 않았다면 캐시를 통해 처리된다

CDN 사용 시 고려해야 할 사항

• 비용
• 적절한 만료 시한 설정
• CDN 장애에 대한 대처 방안 : CDN 자체가 죽었을 때, 해당 문제를 감지하여 원본 서버로부터 직접 콘텐츠를 가져오도록 구성하는 것이 필요할 수도 있음
• 콘텐츠 무효화 방법 : 아직 만료되지 않은 콘텐츠라 해도 CDN 에서 제거 가능

무상태 (stateless) 웹 계층

• 상태 정보 (사용자 세션 데이터와 같은) 를 웹 계층에서 제거해야 수평적으로 확장할 수 있다
• 무상태 웹 계층 : 상태정보를 관계형 데이터베이스나 NoSQL 같은 지속성 저장소에 보관하고, 필요할 때 가져오도록 하는 것

상태 정보 의존적인 아키텍처

• 상태를 보관하는 서버는 클라이언트 정보, 즉 상태를 유지하여 요청들 사이에 공유되도록 한다
• 문제는 같은 클라이언트로부터의 요청은 항상 같은 서버로 전송되어야 한다
  • 대부분의 로드밸런서가 이를 지원하기 위해 고정 세션 (sticky-session) 기능을 제공하고 있음
  • 하지만 이는 로드밸런서에 부담을 주며, 뒷단에 서버를 추가하거나 제거하기에 까다로우며 장애 처리도 복잡해짐

무상태 아키텍처

• 웹 서버는 상태 정보가 필요할 경우, 공유 저장소로부터 데이터를 가져온다
  • 따라서 상태정보는 웹서버로부터 물리적으로 분리되어 있다
• 공유 저장소는 관계형 데이터베이스, Memcached/Redis 같은 캐시 시스템, NoSQL 모두 가능하다
  • NoSQL 은 규모 확장 (트래픽 양에 따라 웹 서버를 자동으로 추가하거나 삭제하는 기능) 이 간편하다
• 상태 정보가 웹 서버로부터 제거되었으므로, 트래픽 양에 따라 웹 서버를 넣거나 빼기만 하면 자동으로 규모를 확장할 수 있게 된다

데이터 센터

• 지리적 라우팅 (geo-routing, geoDNS-routing) 장애가 없는 상황에서 사용자는 가장 가까운 데이터 센터로 안내된다
  • 사용자의 위치에 따라 도메인 이름을 어떤 IP 주소로 변환할지 결정할 수 있도록 해주는 DNS 서비스
• 데이터 센터 중 하나에 심각한 장애가 발생하면 모든 트래픽은 장애가 없는 데이터 센터로 전송된다
• 다중 데이터센터 아키텍처를 만들 때 해결해야 하는 기술적 난제
  • 트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법 찾기
  • 데이터 동기화
    • 데이터 센터마다 별도 데이터베이스를 쓴다면 장애가 복구되어 트래픽이 다른 DB로 우회한다 해도, 해당 데이터센터에는 찾는 데이터가 없을 수 있다
    • 이런 상황을 막는 보편적 전략은 데이터를 여러 데이터 센터에 걸쳐 다중화하는 것
  • 테스트와 배포 : 웹 사이트 또는 애플리케이션을 여러 위치에서 테스트해 보는 것이 중요

메시지 큐

• 메시지 큐 : 메시지의 무손실(즉, 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성) 을 보장하는, 비동기 통신을 지원하는 컴포넌트
• 메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.
• 생산자와 소비자 서비스의 규모는 각기 독립적으로 확장될 수 있다.
  • 큐의 크기가 커지면 더 많은 작업 프로세스를 추가해야 처리 시간을 줄일 수 있다

로그, 메트릭 그리고 자동화

• 로그: 에러 로그는 서버 단위로 모니터링 할 수도 있지만, 로그를 단일 서비스로 모아주는 도구 (ex. ELK 스택 (Elasticsearch, Logstash, Kibana)) 를 활용하면 더 편리하게 검색하고 조회할 수 있다.
• 메트릭: 메트릭을 잘 수집하면 사업 현황에 관한 유용한 정보를 얻을 수도 있고, 시스템의 현재 상태를 손쉽게 파악할 수도 있다.
  • 호스트 단위 메트릭: CPU, 메모리, 디스크 I/O에 관한 메트릭
  • 종합(aggregated) 메트릭: 데이터베이스 계층의 성능, 캐시 계층의 성능
  • 핵심 비즈니스 메트릭: 일별 능동 사용자(daily active user), 수익(rev-enue), 재방문(retention)
• 자동화: 지속적 통합을 도와주는 도구를 활용

데이터베이스의 규모 확장

수직적 확장

• 스케일 업이라고도 부르는 수직적 규모 확장법은 기존 서버에 더 많은, 또는 고성능의 자원(CPU, RAM, 디스크 등)을 증설하는 방법
  • 데이터베이스 서버 하드웨어에는 한계가 있으므로 CPU, RAM 등을 무한 증설할 수는 없다.
  • SPOF(Single Point of Failure) 로 인한 위험성이 크다.
  • 비용이 많이 든다.

수평적 확장

• 데이터베이스의 수평적 확장은 샤딩(sharding) 이라고도 부르는데, 더 많은 서버를 추가함으로써 성능을 향상시킬 수 있도록 한다

  ✅ 데이터베이스의 수평적 확장 방법
  

  1. 샤딩(Sharding): 대규모 데이터셋을 더 작은 조각(샤드)으로 나누어 여러 데이터베이스에 분산 저장하는 기법
  2. 레플리케이션(Replication): 동일한 데이터베이스 복사본을 여러 서버에 생성하는 방식 (데이터베이스 다중화)
  3. 페더레이션(Federation): 기능별로 데이터베이스를 분할하는 방식
     ex) 결제, 주문, 프로필 등 각 기능별로 별도의 데이터베이스를 사용하여 각 데이터베이스의 읽기/쓰기 트래픽을 줄이고 전반적인 성능을 향상시킴
  4. 파티셔닝(Partitioning): 큰 테이블을 더 작고 관리하기 쉬운 부분으로 나누는 기법

• 샤딩 : 대규모 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술
  • 모든 샤드는 같은 스키마를 쓰지만, 샤드에 보관되는 데이터 사이에는 중복이 없다.

    ✅ 데이터베이스를 분할하는 2가지 방법 : 샤딩과 파티셔닝

    1. 파티셔닝
       • 매우 큰 테이블을 여러개의 테이블로 각 행들을 분할하는 작업
       • 수평 파티셔닝 : 하나의 테이블의 각 행을 다른 테이블에 분산시키는 것
         (보통 수평 분할은 하나의 데이터베이스 안에서 이루어지는 경우를 지칭) <-> 샤딩 : 서로 다른 데이터베이스로 분산
       • 수직 파티셔닝 : 테이블의 일부 열을 빼내는 형태로 분할. 정규화도 수직 파티셔닝과 관련된 거라고 할 수 있지만, 수직 파티셔닝은 이미 정규화된 데이터를 분리하는 과정이라고 생각해야 함

    단일 서버 내 파티셔닝

    • 일반적으로 말하는 파티셔닝은 하나의 데이터베이스 서버 내에서 데이터를 분할하는 기법
    • 이 경우 서버 대수를 늘리지 않아도 됨. 주로 성능 최적화와 데이터 관리를 위해 사용됨

    다중 서버 파티셔닝 (분산 파티셔닝)

    • 테이블 A와 테이블 B를 서로 다른 서버에 분산하여 저장하는 방식
    • 이 경우 서버 대수를 늘려야 함

    2. 샤딩
       • 샤딩 : 동일한 스키마를 가지고 있는 여러대의 데이터베이스 서버들에 데이터를 작은 단위로 나누어 분산 저장하는 기법
         • 물리적으로 서로 다른 컴퓨터에 데이터를 저장하므로, 쿼리 성능 향상과 더불어 부하가 분산되는 효과까지 얻을 수 있다. 즉, 샤딩은 데이터베이스 차원의 수평 확장(scale-out)인 셈!

• 샤딩 전략을 구현할 때 고려해야 할 가장 중요한 것은 샤딩 키를 어떻게 정하느냐 하는 것
  • 샤딩 키는 파티션 키라고도 부르는데, 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼으로 구성된다.
  • 샤딩 키를 정할 때는 데이터를 고르게 분할할 수 있도록 하는 게 가장 중요하다.
• 샤딩을 도입하면 풀어야 할 새로운 문제
  • 데이터의 재 샤딩
    • 데이터가 너무 많아져서 하나의 샤드로는 더 이상 감당하기 어려울 때
    • 샤드 간 데이터 분포가 균등하지 못하여 어떤 샤드에 할당된 공간 소모가 다른 샤드에 비해 빨리 진행될 때
      • 샤드 소진(shard exhaustion) 이라고도 부르는 이런 현상이 발생하면 샤드 키를 계산하는 함수를 변경하고 데이터를 재 배치하여야 한다
  • 유명 인사 문제: 핫스팟 키(hotspot key) 문제라고도 부르는데, 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
  • 조인과 비정규화 : 하나의 데이터베이스를 여러 샤드 서버로 쪼개고 나면, 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다
    • 데이터베이스를 비정규화하여 하나의 테이블에서 질의가 수행되도록 하면 문제를 해결할 수 있다

백만 사용자, 그리고 그 이상

• 웹 계층은 무상태 계층으로
• 모든 계층에 다중화 도입
• 가능한 한 많은 데이터를 캐시할 것
• 여러 데이터 센터를 지원할 것
• 정적 콘텐츠는 CDN을 통해 서비스 할 것
• 데이터 계층은 샤딩을 통해 그 규모를 확장할 것
• 각 계층은 독립적 서비스로 분할할 것
• 시스템을 지속적으로 모니터링 하고, 자동화 도구들을 활용할 것

스프링의 HttpInterface는 HTTP 요청을 위한 서비스를 자바 인터페이스와 애노테이션으로 정의할 수 있도록 해준다. 그리고 해당 서비스를 구현하는 프록시 객체를 생성하면 이를 통해 쉽게 HTTP 요청을 보낼 수 있다. 

즉, HttpInterface 를 사용하면 코드가 HTTP 호출의 세부사항에 의존하지 않고도 HTTP 메서드와 URL만 알면 사용할 수 있도록 추상화된다. 코드를 통해 HttpInterface 사용 예시를 알아본 후 HttpInterface 의 장점에 대해 마지막으로 다시 정리를 해보겠다 !

이 글은 회원 (User) 에 대한 간단한 CRUD 코드를 기반으로 작성하였다.

@HttpExchange 애노테이션을 활용한 인터페이스 코드 작성

우선 아래와 같이 인터페이스를 생성하여 @HttpExchange 어노테이션을 붙이고, HTTP 요청을 보내는 각 메소드마다 HTTP Method 에 맞는 애노테이션을 붙여준다.

@HttpExchange(accept = MediaType.APPLICATION_JSON_VALUE)
public interface UserApiHttpClient {

    // GET 요청: 특정 userId에 해당하는 User 정보를 가져옵니다.
    @GetExchange("/users/{userId}")
    ResponseEntity<User> getUser(@PathVariable long userId);

    // POST 요청: 새로운 User 데이터를 생성합니다.
    @PostExchange("/users")
    ResponseEntity<User> createUser(@RequestBody User newUser);

    // PATCH 요청: 특정 userId에 해당하는 User의 일부 데이터를 업데이트합니다.
    @PatchExchange("/users/{userId}")
    ResponseEntity<User> updateUserPartially(@PathVariable long userId, @RequestBody Map<String, Object> updates);

    // PUT 요청: 특정 userId에 해당하는 User 데이터를 전체 업데이트합니다.
    @PutExchange("/users/{userId}")
    ResponseEntity<User> updateUser(@PathVariable long userId, @RequestBody User updatedUser);

    // DELETE 요청: 특정 userId에 해당하는 User 데이터를 삭제합니다.
    @DeleteExchange("/users/{userId}")
    ResponseEntity<Void> deleteUser(@PathVariable long userId);
}

@HttpExchange : Http 엔드포인트를 지정하는 일반적인 애노테이션으로, 인터페이스 수준에서 사용하면 모든 메소드에 적용된다
@GetExchange: HTTP GET 요청을 위한 @HttpExchange를 지정 @PostExchange: HTTP POST 요청을 위한 @HttpExchange를 지정 @PutExchange: HTTP PUT 요청을 위한 @HttpExchange를 지정 @DeleteExchange: HTTP DELETE 요청을 위한 @HttpExchange를 지정 @PatchExchange: HTTP PATCH 요청을 위한 @HttpExchange를 지정

@HttpExchange 애노테이션은 인터페이스 수준에서 사용하면 모든 메소드에 적용된다. 예를 들어, 현재 /users 라는 URI 가 모든 메소드에 공통으로 사용되는데 이를 @HttpExchange 의 속성으로 옮기면 모든 메소드에 동일하게 적용된다. 아래와 같이 공통된 URI (/users) 를 @HttpExchange 에 설정하여 코드를 간결하게 만들어줄 수 있다.

@HttpExchange(url = "/users", accept = MediaType.APPLICATION_JSON_VALUE)
public interface UserApiHttpClient {

    @GetExchange("/{userId}")
    ResponseEntity<User> getUser(@PathVariable long userId);

    @PostExchange
    ResponseEntity<User> createUser(@RequestBody User newUser);

    @PatchExchange("/{userId}")
    ResponseEntity<User> updateUserPartially(@PathVariable long userId, @RequestBody Map<String, Object> updates);

    @PutExchange("/{userId}")
    ResponseEntity<User> updateUser(@PathVariable long userId, @RequestBody User updatedUser);

    @DeleteExchange("/{userId}")
    ResponseEntity<Void> deleteUser(@PathVariable long userId);

}

여기까지 작성해본 UserApiHttpClient 는 HTTP 요청을 수행하는 메소드의 형태와 내용은 정의되어있지만, 직접 HTTP 요청을 보내는 로직이 없다. UserApiHttpClient 인터페이스에 정의된 메소드를 호출했을 때 실제 HTTP 요청이 되게 하려면, 해당 인터페이스에 대한 프록시 객체를 만들어주어야 한다.

인터페이스에 대한 프록시 객체 생성을 위한 설정 추가

프록시를 생성하기 위해서는 아래와 같은 WebClient 설정들이 추가로 필요한데, 하나씩 찬찬히 살펴보자 !

@Configuration
public class WebClientConfig {

    public UserApiHttpClient userApiHttpClient() {
        // #1
        WebClient webClient = WebClient
                .builder()
                .baseUrl("https://localhost:8081")
                .build();

        // #2
        WebClientAdapter adapter = WebClientAdapter.create(webClient);

        // #3
        HttpServiceProxyFactory factory = HttpServiceProxyFactory
                .builderFor(adapter)
                .build();

        // #4
        return factory.createClient(UserApiHttpClient.class);
   }
}    

1. WebClient 객체 생성

WebClient webClient = WebClient
        .builder()
        .baseUrl("https://localhost:8081")
        .build();

WebClient 객체를 생성하는 코드이며, WebClient는 Spring의 비동기 및 동기 HTTP 요청 클라이언트로 HTTP 요청을 보낼 수 있도록 설정된다. 위 예제코드에서는 baseUrl 을 지정해줌으로써 모든 HTTP 요청의 기본 URL이 이 값으로 시작되도록 구성하였다. 기본 URL 과 HttpInterface 에서 작성한 아래 API path 와 연결되어 "https://localhost:8081/{userId}" 로 HTTP 요청이 전송된다.

  @GetExchange("/{userId}")
    ResponseEntity<User> getUser(@PathVariable long userId);

2. WebClientAdapter 객체 생성

WebClientAdapter adapter = WebClientAdapter.create(webClient);

WebClientAdapter는 WebClient 객체를 HttpServiceProxyFactory가 사용할 수 있는 형태로 래핑하는 역할을 한다. 이를 통해 WebClient가 HTTP 요청을 수행할 때 HttpServiceProxyFactory에서 활용할 수 있는 어댑터 역할을 한다.

3. HttpServiceProxyFactory 생성

HttpServiceProxyFactory factory = HttpServiceProxyFactory
        .builderFor(adapter)
        .build();

builderFor() 메서드를 통해 앞에서 생성한 WebClientAdapter를 사용하여 HttpServiceProxyFactory 객체를 만든다. 다음 4번째 단계에서 이 팩토리의 메소드를 활용하면, 인터페이스의 메서드 호출을 프록시 객체로 변환하여 실제 HTTP 요청을 처리할 수 있다.

4. UserApiHttpClient 인터페이스의 프록시 객체 생성

UserApiHttpClient userApiHttpClient = factory.createClient(UserApiHttpClient.class);
return userApiHttpClient;

HttpServiceProxyFactory 의 createClient 메소드를 활용하여 UserApiHttpClient 인터페이스의 프록시 객체를 생성한다. 이 프록시 객체는 UserApiHttpClient에 정의된 메서드를 호출할 때 자동으로 WebClient를 사용하여 해당 HTTP 요청을 보내도록 처리한다. userApiHttpClient를 통해 정의된 메서드 호출 시 실제 HTTP 요청이 수행된다.

위와 같은 코드가 작성되고 나면 아래와 같이 호출 했을 때 정상적으로 1번 유저에 대한 객체가 반환된다!

userApiHttpClient.getUser(1); 

지금까지 간단한 회원 CRUD API 명세가 작성된 인터페이스 코드를 살펴보고, 해당 인터페이스를 활용하여 실제 HTTP 요청을 보내기 위한 WebClient 설정 코드에 대해 알아보았다.

프록시 객체 없이 HTTP 요청을 직접 구현한다면?

HttpServiceProxyFactory 의 createClient 메소드를 통해 만들 수 있는 프록시 객체 없이, 직접 HTTP 요청 로직을 작성하게 되면 HTTP 호출에 대한 반복적이고 복잡한 코드가 많아질 수 있다.

극단적인 예시로, 프록시 객체 없이 HTTP 요청을 직접 작성하게 되면 아래와 같이 길고 장황한 (...) 코드를 짜게 될 수도 있다. 각 요청마다 반복되는 코드들이 생기고, HTTP 요청의 세부 구현을 포함하게 되어서 비즈니스 로직과 HTTP 호출 코드가 섞여 응집도도 낮아진다. 또한 API의 기본 URL이 변경되면 모든 메서드의 URI를 수정해야 하므로 유지보수에 어려움을 겪을 수 있다.

public class UserApiService {

    private final WebClient webClient;

    public UserApiService() {
        this.webClient = WebClient.builder()
                .baseUrl("https://localhost:8081")
                .build();
    }

    public User getUser(long userId) {
        return webClient.get()
                .uri("/users/{userId}", userId)
                .accept(MediaType.APPLICATION_JSON)
                .retrieve()
                .bodyToMono(User.class)
                .block();
    }

    public User createUser(User newUser) {
        return webClient.post()
                .uri("/users")
                .contentType(MediaType.APPLICATION_JSON)
                .bodyValue(newUser)
                .retrieve()
                .bodyToMono(User.class)
                .block();
    }

    public User updateUserPartially(long userId, Map<String, Object> updates) {
        return webClient.patch()
                .uri("/users/{userId}", userId)
                .contentType(MediaType.APPLICATION_JSON)
                .bodyValue(updates)
                .retrieve()
                .bodyToMono(User.class)
                .block();
    }

    public User updateUser(long userId, User updatedUser) {
        return webClient.put()
                .uri("/users/{userId}", userId)
                .contentType(MediaType.APPLICATION_JSON)
                .bodyValue(updatedUser)
                .retrieve()
                .bodyToMono(User.class)
                .block();
    }

    public void deleteUser(long userId) {
        webClient.delete()
                .uri("/users/{userId}", userId)
                .retrieve()
                .bodyToMono(Void.class)
                .block();
    }
}

프록시 객체 사용하여 HTTP 통신 로직을 추상화한다면?

프록시 객체를 사용하면 각 메서드에 직접적인 HTTP 로직을 작성할 필요가 없어진다 인터페이스에 따라 메서드 호출만으로 자동으로 HTTP 요청이 이루어져 간결하고 유지보수하기 쉬운 코드를 작성할 수 있다. 또한 코드가 더 깔끔해지고, 비즈니스 로직과 HTTP 통신 로직을 분리할 수 있다. 필요에 따라 다른 HTTP 클라이언트로 교체할 때도 쉽게 변경할 수도 있다.

프록시 구현체는 이처럼 인터페이스만 정의해두고도 실제 HTTP 통신이 가능한 클라이언트를 사용할 수 있어 인터페이스 기반 프로그래밍을 가능하게 하며, 코드의 재사용성, 유지보수성, 테스트 용이성을 높여줄 수 있다

• EnumSet 은 열거형 과 함께 사용하기 위한 Set 인터페이스의 특수 구현 중 하나이다
• EnumSet은 Set 인터페이스를 완벽히 구현하며, 타입 안전하고, 다른 Set 구현체와도 함께 사용할 수 있다
• EnumSet을 사용하면 해당 Set이 특정 enum 타입의 값만을 다룬다는 점이 명확히 표현되어 가독성을 높일 수 있다
• null 값 추가를 허용하지 않으며, 시도하면 NullPointerException 이 발생한다
• thread safe 하지 않으므로 필요한 경우 외부에서 동기화가 필요하다
• EnumSet의 내부는 비트 벡터로 구현되어 있으며 원소의 개수가 64개 이하라면 long 변수 하나로 표현할 수 있어서 비트필드에 비견되는 성능을 보여준다

  비트벡터 : 중복되지 않는 정수 집합을 비트로 나타내는 방식 (자리에 해당하는 수에 0, 1 사용하여 표현)
  -> 메모리 사용 크게 감소 가능

EnumSet 의 내부 noneOf 메소드를 살펴보면, 2가지 구현체로 구현되고 있다.

public static <E extends Enum<E>> EnumSet<E> noneOf(Class<E> elementType) {
        Enum<?>[] universe = getUniverse(elementType);
        if (universe == null)
            throw new ClassCastException(elementType + " not an enum");

        if (universe.length <= 64)
            return new RegularEnumSet<>(elementType, universe);
        else
            return new JumboEnumSet<>(elementType, universe);
    }

• RegularEnumSet
  • RegularEnumSet은 단일 long을 사용하여 비트 벡터를 나타낸다
  • long 의 각 비트는 enum 의 값을 나타냄 -> 열거형의 i번째 값은 i번째 비트에 저장되므로 값이 있는지 여부를 아는 것이 매우 용이하다
  • long 은 64비트 데이터 유형 이므로 이 구현에서는 최대 64개의 요소를 저장 가능하다
• JumboEnumSet
  • JumboEnumSet은 long 배열을 비트 벡터로 사용한다
  • 이를 통해 64개 이상의 요소를 저장 가능하다
  • 이는 RegularEnumSet 과 거의 유사하게 작동하지만 값이 저장된 배열 인덱스를 찾기 위해 몇 가지 추가 계산을 수행한다
  • 배열의 첫 번째 long 요소는 enum 의 첫 번째 값 64개를 저장, 두 번째 요소는 다음 64개 등을 저장한다
• 당연히 RegularEnumSet 성능이 JumboEnumSet 보다 조금 더 좋다. 데이터를 찾기 위해 별도의 배열을 검색할 필요 없이 모든 데이터를 객체 내부에 저장하기 때문이다.

EnumSet 의 이점

• EnumSet의 모든 메서드는 산술 비트 단위 연산을 사용하여 구현된다
• 이러한 계산은 매우 빠르므로 모든 기본 작업이 상수 시간 내에 수행된다
• EnumSet을 HashSet 과 같은 다른 Set 구현 과 비교하면, 값이 예측 가능한 순서로 저장되고 각 계산에 대해 1비트만 검사하면 되기 때문에 일반적으로 더 빠르다.
• HashSet 과 달리 올바른 버킷을 찾기 위해 해시코드 를 계산할 필요가 없다 .
• 게다가 비트 벡터의 특성으로 인해 EnumSet은 매우 컴팩트하고 효율적이다.
• 따라서 메모리를 덜 사용하면서도 모든 이점을 누릴 수 있다.

결론

"Enum을 집합으로 표현하고 싶다면 그냥 HashSet에 넣어도 똑같은 거 아닌가?"

• 물론 기능은 같지만 성능적으로 큰 차이가 있다
• EnumSet의 모든 메서드는 비트 연산을 사용하고 있으며 64개 이하라면 하나의 long 비트만을 사용
• 각 계산에 대해 하나의 비트만 검사하는 EnumSet과 해시 코드를 계산해야 하는 HashSet을 비교한다면 당연히 EnumSet이 빠르다
• 즉, Enum 값을 집합으로 저장할 일이 있다면 가능한 EnumSet을 사용하는 것이 좋다

9기에서 다짐했던 것 😎

• 같은 직군 사람들과 커피챗 하기 (한달에 2번 이상)
• 벽또 참여하기
• 관악또 참여하기
• 단순한 지식 정리가 아닌, 나의 경험을 담은 트러블 슈팅 또는 기술 관련 글 작성하기
• 같은 조 분들의 글 출퇴근 시간에 읽기

하지만 이루지 못했던 것 😵

'같은 조 분들의 글 출퇴근 시간에 읽기' 빼고는 아무것도 이루지 못한 것 같다. 사실 이것도 초반 1~2개월까지는 흥미로운 글들을 골라서 읽어보기도 했는데, 이후에는 흐지부지되었다. 막상 코어 채널만 보더라도 흥미로운 글들이 많았는데 그런 양질의 글들을 눈 앞에서 놓친 느낌이라 아쉽게 느껴졌다.

커피챗 + 소모임 참여는 퇴근 후 시간을 투자해서 참여를 해야하는 활동들이지만, 프로젝트 일정이 바빠지면서 그런 시간을 내는 것이 버겁게 느껴졌다. 그래서 적극적으로 참여하지 못하게 되었던 것 같아 9기가 끝나고도 너무너무 아쉬웠다. 글또는 많은 개발자들이 모인 커뮤니티인 만큼 다양한 사람들을 만날 수 있다는 게 큰 장점이라고 생각했는데, 그런 장점을 내가 잘 받아먹지 못한 느낌 😰 사실 지금도 여유로운 프로젝트 일정은 아니지만 9기에서 아쉬움을 느낀 만큼 10기때는 최대한 시간을 내보면서 참여하고 싶다.

단순한 지식 정리 뿐 아니라 나의 경험을 담은 글을 쓰는 것 또한 시간적인 여유가 없는게 가장 컸다. 이 쯤 되면 못한 거에 대해 다 핑계를 대는 느낌이라 민망하지만 이번 글또에서는 작성할 글감을 정리해보면서 조금 체계적으로 글을 써본다면 이 목표도 조금은 이룰 수 있지 않을까 기대해본다.

10기에서는 이루고 싶은 것 💪

커피챗 제발하기

최근에 친구들과 만나면서도 다른 회사 이야기를 듣고 커리어와 관련된 대화를 할 때가 가장 재미있고 즐겁다는 생각이 들었다. 그래서 내가 잘 모르는 도메인, 회사 문화 등 새로운 분들의 이야기도 많이 들어보면 참 재미있을 것 같다는 생각이 들어서 커피챗을 적극적으로 활용해보고 싶다 (제발) 요즘 일은 왜 열심히 해야할까, 꼭 개발자로서 성장해야할까? 와 같은 한심한 고민들을 하고 있지만 커리어와 관련된 성장 욕심이 있으신 분들과 이야기를 하면서 동기부여도 받고 내 마인드셋도 정비를 하고 싶다. 최근 흑백 요리사를 보면서 자신의 일에 열정이 가득하고, 요리를 정말 사랑한다고 이야기하는 셰프분들이 멋있다고 느꼈다. 나는 과연 나의 일에 열정적으로 임하고 있을까, 나도 저런 마인드를 언젠가는 가질 수 있게 될까에 대한 의구심이 들면서 생각이 많아졌다. 일에 과도하게 매몰되는 것은 좋은 것이 아니지만, 나는 결국 일을 재미있게 할 때 가장 행복하고 뿌듯한 것 같았다. 하지만 이런 마음과는 상반되게 퇴근 후에는 아무것도 안하고 싶고 그저 누워 있고 싶은 마음도 드는 것 같다. 아무튼 이런 고민들을 다른 분들과도 나눠보면서 여러 자극과 동기부여를 받기도 하고 나 또한 나의 루틴과 일상들을 나눠보면서 서로 좋은 영향을 받을 수 있는 관계들이 생겼으면 한다!

대나무숲 활용하여 고민을 나눠 보기 글또 대나무숲은 9기 때부터 참 재미있게 보던 채널이다. 내가 고민하고 있는 부분들을 똑같이 올려주시는 분들도 있어서 덕분에 나의 고민에 대한 해답도 얻고 다양한 인사이트를 얻는 경우들이 많았다. 지금까지는 올라오지 않은 나의 고민도 나눠 본다면 나와 같은 고민을 하던 누군가에게는 도움이 되지 않을까? 하는 생각이 들었다. 지금까지는 주로 친구들이나 부모님께 고민을 나누었는데, 다양한 사람들이 있는 대나무숲도 잘 활용하면 좋을 것 같아 이번 기수에는 활용해보려고 한다

영어해또 / 감사회고해또 매일 인증 참여하기 9기에서는 사실 무언가를 인증하거나 작성하는 소모임에 하나도 참여하지 않았다 (귀차니즘으로 인해). 9기에서도 감사회고 소모임이 있다는 것은 알았지만 나혼자서도 메모장에 감사일기를 매일 적고 있었기에 굳이 다른 채널에 써야할까? 하는 생각이었다. 하지만 혼자 하는 것이 흐지부지되는 순간들이 항상 있었다. 그래서 글또 9기가 끝나고 카톡방에서 진행되는 감사회고 9.5기에 참여하게 되었다. 9.5기에 참여하면서 매일 꾸준히 감사회고를 쓸 수 있었고, 다른 분들의 회고를 읽으면서 나 또한 좋은 자극을 받고 행복해지는 순간들 있었다. 그러면서 혼자 감사회고를 작성하는 것보다 다같이 있는 공간에서 감사회고를 나누는 것이 동기부여도 되고 좋은 에너지를 얻을 수 있다는 확신이 들었다. 그래서 10기에는 감사회고해또 채널에 매일 올리고 있고 내가 기대한 것과 같이 좋은 시너지가 나고 있는 것 같다!

영어해또 또한 감사회고해또와 동일한 이유로 참여하게 되었다. 말해보카를 매일하는 루틴을 갖고는 있지만 다른 분들이 어떻게 영어공부를 하는지 궁금하기도 하고, 같이 으쌰으쌰하는 분위기가 좋아서 참여하게 되었다! 다른 분들의 인증을 보면서 나도 새로운 수단과 방법으로 영어와 가까워지는 계기가 될 수 있을 것 같다.

글또 슬랙 매일 주기적으로 확인하며 인사이트 얻기 9기와 비교했을 때 더 자주 슬랙을 확인하고 있다. 슬랙 알림은 꺼두었지만 하루에도 몇 번씩 슬랙에 들어가고 있어서 많은 글들을 확인하고 있다! 특히 책읽어또 채널에 주목하고 있다. 인증에 참여하고 있지는 않지만, 다른 분들이 읽는 책 리스트를 보면서 내가 읽고 싶은 책을 담아가고 있다. 요즘 책 읽는 재미에 빠져 있어서 인증글들을 보면서 나도 다양한 책을 읽을 기회가 생길 거 같아 기대가 된다. 글을 제출하면서부터는 큐레이션 채널의 글들도 많이 읽어보려고 한다. 더 부지런하게 슬랙의 좋은 정보들을 얻어가고 싶다!

강의 링크 【한글자막】 Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기

강의를 선택한 이유

우선 이 강의를 수강하게 된 이유는, 멀티스레드 환경에서 어떻게 올바르게 코드를 작성할 수 있을 지에 대한 궁금함 때문이었다. 그동안 개발은 계속 해왔지만 멀티스레드 환경이나 병행성, 성능에 대한 내용을 고려하지 못했던 것 같아서 해당 내용을 통해서 조금이나마 감을 잡을 수 있을 거 같았다.

강의 내용

강의는 총 5시간 24분의 분량으로, 개인적으로 그렇게 분량이 많다는 생각은 안들었지만 하나하나 이론과 실습을 따라하다 보니 1.5배~2배의 시간은 들었던 것 같다. 그리고 영어 부족 이슈로 인해.. 영어 자막 없이 소리만 들어서는 쉽게 내용 파악이 불가능하여 자막에 의존하며 듣다보니 훨씬 오래 걸렸던 것 같다 ㅎㅎ;;

강의는 운영체제에서 배운 내용들에 대한 개념 설명부터 시작한다. 위 사진은 강의를 들으며 필기한 일부 내용이다 !

멀티쓰레드가 필요한 이유, 멀티쓰레드 활용 시 성능, 컨텍스트 스위칭, 스레드 스케줄링 등등... 운영체제 수업에서 배웠던 내용들을 한번씩 복습하고 넘어가는 느낌이어서 좋았다 !

OS 기본 개념부터 시작해서, 지연시간을 어떻게 최소화할 것이며, 여러가지 락킹기법, 논블로킹/블로킹 등 심화 개념까지 다뤄주고 있어서 멀티스레드, 병행성과 관련하여 큰 사이클을 모두 경험해볼 수 있는 것도 이 강의의 장점이다.

보통 강의들이 이론이면 이론, 실습이면 실습에 조금씩 치우치는 경우들도 있었는데, 해당 강의는 이론과 실습 중 어떤 것에도 치우침 없이 이론에 대한 언급 + 해당 이론을 실제 어떻게 구현하는지를 바로 보여주어서 이해하기가 편했던 것 같다.

각 챕터마다 퀴즈, 코딩 연습이 준비되어 있어서 실습할 수 있는 환경을 강의에서 제공해준다. 그래서 이론만 알고 구현은 어려워했던 나에게 좋은 수강 방식이었던 것 같다

이 강의를 통해서, 운영체제에 대한 개념에 대한 이해를 바탕으로, 병행성/동시성 이론을 자바 코드로 어떻게 구현하는 지 실제로 경험해볼 수 있었다. 배운 내용을 바탕으로 실무에서도 적용해볼 수 있는 기회가 있었으면 하는 생각이 들었다.

추천 대상

이론으로만 배운 멀티스레딩, 병행성 및 성능 최적화에 대한 내용을 실제 코드로 어떻게 활용될 수 있을지 궁금한 사람들에게 추천하고 싶다.

이해하기 쉽게 설명해주시긴 하지만, 어느정도의 OS 지식을 갖고 있는 사람들이 이해하기 편하고 더 많은 내용을 얻어갈 것 같다는 생각도 들었다.

해당 포스트는 글또 9기를 통해 Udemy 강의 쿠폰을 제공받아 작성하였습니다.

• LSM 트리는 2개 이상의 tree 로 구성될 수 있는데, 1개의 tree 를 제외하고 나머지 tree 는 디스크에 위치한다
• 메모리에 위치한 자료구조를 C0 tree, 디스크에 위치한 자료구조를 C1 tree라고 표현한다

LSM 트리에서 쓰기 요청 처리

1. 쓰기 작업이 요청된다
2. 시스템 다운 시 복구를 위해 별도의 로그성 파일에 데이터를 기록한다 (sequential log)
3. 메모리의 C0 tree에 해당 쓰기 요청 반영 / C0 tree는 메모리에서만 존재하기 때문에 디스크를 위한 최적화는 필요하지 않다
4. C0 tree가 임계치 이상의 크기에 도달하면 rolling merge를 실시하며 Rolling merge를 통해 C0 tree의 연속되는 메모리 영역을 디스크 상의 C1 tree와 병합한다 → 병합을 통해 C0이 사용할 수 있는 메모리 공간을 확보한다

• Rolling merge

  • Rolling merge의 시작은 디스크상의 C1 tree에 위치한 leaf node 데이터를 multi-page block 단위로 메모리에 적재한다

  • 메모리에 적재된 C1 tree의 leaf node 데이터를 disk page 크기 단위로 읽고 이를 C0 tree의 left node데이터와 병합하여 새로운 leaf node를 생성한다

  • 생성된 leaf node는 C1의 parent node가 가리킴으로써 병합과정이 완료된다

  • 메모리에서 병합된 데이터를 디스크로 플러쉬할 때 기존 데이터의 위치에 덮어쓰지 않고 새로운 위치에 저장한다

    

• log-structured (데이터를 순차적으로 로그에 기록) 형식으로 데이터를 저장하면, 항상 파일에 추가만 해야하니까 디스크 공간이 부족해진다

• SS 테이블의 형식으로 디스크에 key-value 데이터를 저장하는 색인 방식

  • log-structured 데이터 형식에 “모든 key-value 쌍을 키를 기준으로 정렬 한다” 라는 요구사항을 추가한 형식 : SS 테이블

  • SS 테이블은 LSM 트리에서 실제로 데이터를 저장하는 단위 로, 디스크 상에 정렬된 세그먼트 파일이다

  • 새로운 데이터가 쓰기 동작으로 인해 메모리에 먼저 쓰여지고 나중에 디스크에 저장될 때 SS 테이블이 형성된다

    

- SS 테이블은 주기적인 병합 작업을 통해, 데이터를 특정 크기의 segment 로 나누고, 주기적으로 compaction (중복된 키를 버리고 각 키의 최신 값만 유지하는 것) 을 수행한다

    ![](https://velog.velcdn.com/images/eunz_juu/post/14487ea2-8431-46dc-ba48-6452dfa55dd7/image.png)



1. 쓰기가 들어오면 인메모리 균형 트리(balanced tree) 데이터 구조(ex. red-black tree)에 추가한다
    - 트리가 이미 키로 정렬된 키-값 쌍을 유지하므로 효율적인 수행이 가능하다
    - 이러한 인메모리 트리를 `멤테이블`(memtable)이라고 한다
        - 멤테이블의 크기가 임계값(보통 수 MB)보다 커지면 SS테이블 파일로 디스크에 기록한다
        - 메모리의 휘발성 특성 때문에 주기적으로 디스크에 기록되거나 SS 테이블로 이동된다
2. 새로운 SS 테이블 파일은 DB 에서 가장 최신 세그먼트가 되고, SS 테이블을 디스크에 기록하는 동안 쓰기는 새로운 멤테이블 인스턴스에 기록된다
3. 읽기 요청을 처리하려면 먼저 멤테이블에서 키를 찾고, 디스크상의 최신 세그먼트부터 찾는다. (인메모리 해시맵이나 bloom filter 를 사용하여 탐색 시간을 줄일 수 있다.)
4. 백그라운드에서 지속적으로 컴팩션 과정을 수행한다

LSM 트리에서 조회 요청 처리

• C0, C1, ... Cn 순서로 수행한다
• C0 tree (메모리) 에서 원하는 데이터를 찾을 수 없다면 C1 tree를 찾고, 이후에도 데이터를 찾을 수 없다면 다음 tree를 확인한다
  • C0를 제외한 나머지 tree는 디스크에 위치하기 때문에 다수의 tree를 탐색해야 한다면 B-Tree와 비교하여 조회 성능이 안 좋을 수 있다
  • Bloom filter : LSM 트리와 같은 DB 시스템에서 사용되는 확률적 자료구조
    • 확률적인 자료 구조 “존재할 것이라고 판단되면 실제로는 존재하지 않을 가능성이 있다” 는 오류 발생 가능성이 있다
    • 불필요한 디스크 액세스 감소 : 특정 데이터가 어떤 레벨의 트리에 있을 지 확률적으로 판단하여 불필요한 디스크 액세스를 줄인다
    • 데이터 조회 최적화 : 특정 데이터 존재 여부를 확률적으로 판단하므로, 실제 존재하지 않는 데이터 조회를 빠르게 거부 가능하다 (읽기 성능 향상)
    • 메모리 효율성 : 비트 배열로 구성되어 메모리 사용량이 적다

스트림이란

• 스트림 : 데이터 원소의 유한/무한 시퀀스
• 스트림 파이프라인 : 데이터 원소들로 수행하는 연산 단계를 표현하는 개념
  • 소스 스트림에서 시작해 종단연산으로 끝난다
  • 그 사이에 하나 이상의 중간 연산이 있을 수 있다 (중간 연산 - 스트림을 어떠한 방식으로 변환)
  • 중간연산은 한 스트림 → 다른 스트림으로 변환한다

스트림의 종단 연산과 중간 연산

• 종단 연산
  • forEach(Consumer<? super T> consumer) : Stream의 요소를 순회
  • count() : 스트림 내의 요소 수 반환
  • max(Comparator<? super T> comparator) : 스트림 내의 최대 값 반환
  • min(Comparator<? super T> comparator) : 스트림 내의 최소 값 반환
  • allMatch(Predicate<? super T> predicate) : 스트림 내에 모든 요소가 predicate 함수에 만족할 경우 true
  • anyMatch(Predicate<? super T> predicate) : 스트림 내에 하나의 요소라도 predicate 함수에 만족할 경우 true
  • noneMatch(Predicate<? super T> predicate) : 스트림 내에 모든 요소가 predicate 함수에 만족하지않는 경우 true
  • sum() : 스트림 내의 요소의 합 (IntStream, LongStream, DoubleStream)
  • average() : 스트림 내의 요소의 평균 (IntStream, LongStream, DoubleStream)
• 중간 연산
  • filter(Predicate<? super T> predicate) : predicate 함수에 맞는 요소만 사용하도록 필터
  • map(Function<? Super T, ? extends R> function) : 요소 각각의 function 적용
  • flatMap(Function<? Super T, ? extends R> function) : 스트림의 스트림을 하나의 스트림으로 변환
  • distinct() : 중복 요소 제거
  • sort() : 기본 정렬
  • sort(Comparator<? super T> comparator) : comparator 함수를 이용하여 정렬
  • skip(long n) : n개 만큼의 스트림 요소 건너뜀
  • limit(long maxSize) : maxSize 갯수만큼만 출력

스트림 파이프라인의 지연 연산과 최적화

• 지연 평가 : 결과값이 필요할 때까지 계산을 늦추는 기법
  • 대용량 데이터에서, 실제로 필요하지 않은 데이터들을 탐색하는 것을 방지해 속도를 높일 수 있다

💡

1. 스트림 파이프라인 실행시, JVM 은 곧바로 스트림 연산 실행 X
2. 최소한으로 필수적인 작업만 수행하고자 지연 연산을 위한 준비 작업을 수행 (스트림 파이프라인이 어떤 중간연산과 종단 연산으로 구성되어있는지에 대한 검사)
   3. 이를 바탕으로 JVM 은 사전에 최적화 방법을 찾아내 계획함
   4. 해당 계획에 따라 개별 요소에 대한 스트림 연산을 수행함

• 종단 연산이 호출될 때 이루어지며, 종단 연산에 쓰이지 않는 데이터 원소는 계산에 쓰이지 않는다 (Short-Circuit 방식)
• limit(n) 연산이 내부적으로 자신에게 도달한 요소가 n 개가 되었을 때 스트림 내 다른 요소들에 대해 더 이상 순회하지 않고 탈출하도록 만들었기 때문에, 아래와 같은 출력 결과가 나온다

void test() {
    List<String> list = List.of("abcde", "asdfasdf", "aa", "zzzzzzzz", "bbb");
        list.stream()
            .filter(x -> x.length() >= 5)
            .peek(x -> System.out.println("intermediate : " + x))
            .limit(2)
            .forEach(x -> System.out.println("terminate : " + x));

intermediate : abcde
terminate : abcde
intermediate : asdfasdf
terminate : asdfasdf

• 지연평가가 무한 스트림을 다룰 수 있게 해주는 열쇠
  • 크기가 정해져있지 않으므로 중복 제거가 불가 → limit () 과 같은 short-circuit 연산을 통해 유한 스트림으로 변환함으로써 가능해진다
    • 중복을 제거하는 distinct() 나, 전체 데이터를 정렬하는 sort() 연산들을 Stateful 연산이라고 함 하지만 이는 지연 평가를 무효화시키고, 결과를 생성하기 전에 전체 데이터를 탐색하는 결과를 초래한다

void test() {
    List<String> list = List.of("abcde", "asdfasdf", "aa", "zzzzzzzz", "bbb");
        list.stream()
            .filter(x -> x.length() >= 5)
            .peek(x -> System.out.println("intermediate : " + x))
            .sorted()
            .limit(2)
            .forEach(x -> System.out.println("terminate : " + x));

intermediate : abcde
intermediate : asdfasdf
intermediate : zzzzzzzz
terminate : abcde
terminate : asdfasdf

• 종단 연산이 없는 스트림 파이프라인은 아무일도 하지 않는 명령어와 동일하다

Char 값을 처리할 때는 스트림 값을 삼가는 편이 나은 이유는 ?

1. 인코딩 문제: 스트림은 기본적으로 바이트 기반이라, CHAR 값을 처리할 때 스트림을 사용하면 인코딩 문제가 발생할 수 있다
   • 특히, 문자 데이터를 바이트로 변환하고 다시 CHAR로 변환할 때
2. 텍스트 데이터의 추상화: 자바에서는 Reader 및 Writer 클래스와 같은 텍스트 데이터를 다루기 위한 특수한 스트림 클래스가 제공되기에, 이 클래스를 사용하면 문자 데이터를 효과적으로 다룰 수 있고, 인코딩 및 디코딩 문제를 줄일 수 있다

스트림이 적합한 경우

• 원소들의 시퀀스를 일관되게 변환한다.
• 원소들의 시퀀스를 필터링한다.
• 원소들의 시퀀스를 하나의 연산을 사용해 결합한다. (더하기, 연결하기, 최소값 등..)
• 원소들의 시퀀스를 컬렉션에 모은다
• 원소들의 시퀀스에서 특정 조건을 만족하는 원소를 찾는다.

스트림이 적합하지 않은 경우

• 데이터가 파이프라인의 여러 단계(stage)를 통과할 때 이 데이터의 각 단계에서의 값들에 동시에 접근하기 어려운 경우
  • 스트림 파이프라인은 한 값을 다른 값에 매핑하고 나면 원래의 값을 잃는 구조이기 때문이다

결론

• 스트림을 과도하게 사용하면 읽기 어렵고 유지보수가 힘든 코드가 만들어지므로, 모든 반복문을 스트림으로 바꾸기보단 둘 다 테스트해보고 더 나은 쪽을 선택하는 것이 좋다

사실 기존 메시징 시스템에서 파일 시스템은,** 메시지의 영속성을 위해서 성능 저하를 감수하면서도 어쩔 수 없이 사용해야하는 애물단지 같은 존재였습니다. **

디스크는 원하는 데이터가 위치한 블록을 찾기 위한 시간(seek time), 블록을 메모리에 카피하는 시간 등의 오버헤드가 존재합니다. 데이터가 캐시나 메모리에 이미 존재하면 이 과정은 생략될 수 있지만, 그렇지 않을 경우 이러한 동작이 반복적으로 필요합니다. 따라서 디스크는 일반적으로 느리다고 인식됩니다.

*하지만 카프카는 이런 편견을 깨고 파일 시스템을 메시지의 주 저장소로 사용하면서도, 기존의 메시징 시스템보다 뛰어난 성능을 보여주는데요. 어떻게 이러한 구현이 가능했을까요? *

카프카는 3가지 방법을 활용하였습니다.

1. 디스크의 Sequential I/O (순차적인 입출력) 활용 2. 페이지 캐시 전략 활용 3. 제로 카피 기법 도입

첫번째, 디스크에 순차적인 I/O 작업을 수행합니다.

디스크 I/O는 어떻게 사용하는지에 따라 느릴수도 있고 빠를 수도 있는데요. 아래 그림을 통해 디스크에 순차적 접근 속도는 디스크 랜덤 엑세스에 비해 150,000배 빠르고, 메모리에 랜덤 액세스하는 것보다도 속도가 빠른 것을 확인하실 수 있습니다.

디스크의 읽기 속도는 실제 데이터를 읽는 속도가 아니라, 데이터가 위치한 블록을 찾기 위한 시간 (seek time) 에 의해 지연됩니다. 카프카는 순차적 접근을 통해, seek time 을 최소화할 수 있습니다. 이는 카프카가 데이터를 로그(segments)로 저장하기 때문에 가능한 일입니다. 로그는 한 번 쓰여지면 변하지 않는 성질, 즉 immutable 한 특성을 지니고 있습니다. 특히 카프카의 데이터는 컨슈머가 읽어도 지워지지 않고 지속적으로 추가됩니다. 이로 인해 카프카의 데이터는 디스크에 조각(fragments) 으로 나뉘어 저장되지 않고, 가능한 연속적인 블록에 저장됨으로써 seek time 을 최소화 할 수 있습니다.

하지만 이 순차적 접근이 항상 보장되는 것은 아닌데요. 카프카의 데이터가 위치하는 파일 시스템을 다른 어플리케이션이 함께 사용하는 경우, 다른 어플리케이션으로 인해 디스크 단편화가 발생할 가능성은 존재합니다. 따라서 카프카의 *순차적 접근을 보장하기 위해, 카프카의 데이터는 가급적 독립된 파일 시스템에 유지할 것을 권장합니다. *

최신 OS들은 앞으로 필요할 것으로 예상되는 메시지를 미리 읽어들이는 read-ahead와 디스크에 실제 쓰는 작업을 비동기적으로 처리하는 write-behind 같은 기술을 통해, 순차 입출력 작업이 더 빠르게 수행되도록 지원하고 있습니다. 또한 디스크 액세스 속도를 더 개선시키기 위해 읽기/쓰기 작업은 OS 페이지 캐시를 최대한 활용한다면 디스크 접근 횟수를 줄일 수 있습니다. OS 페이지 캐시는 2번째 내용에서 조금 더 자세히 다뤄집니다.

따라서, 카프카는 순차적 I/O 의 혜택을 활용함으로써 메모리에 저장하는 MOM 시스템보다 빠른 성능을 제공할 수 있습니다.

두번째, 페이지 캐시 전략을 활용하였습니다

카프카는 메모리에 별도의 캐시를 구현하지 않고 OS의 페이지 캐시에 이를 모두 위임하였습니다. 따라서, 모든 디스크의 읽기/쓰기는 OS의 페이지 캐시를 거치게 되는데요. 어플리케이션에 의해 관리되는게 아니라 OS에 의해 관리되기 때문에, 사용자 영역과 커널 영역의 중복 저장 없이 2배 정도의 캐시를 저장할 수 있습니다.

만약 애플리케이션 내부에서 캐시를 사용한다면, 같은 내용을 운영체제의 페이지 캐시와 애플리케이션 내부 캐시에 중복 저장하게 되는 것입니다.

위 그림을 보시면, 카프카는 Producer가 전송한 메시지를 JVM 힙메모리에 저장하지 않고 페이지 캐시에 저장하고 있습니다. JVM 힙메모리에 저장하지 않음으로써 메시지가 JVM 객체로 변환되면서 크기가 커지는 것을 방지할 수 있고, 힙 내의 데이터가 증가함에 따라 점점 느려지는 GC 의 성능저하 또한 피할 수 있습니다.

또한 카프카 프로세스가 직접 캐시를 관리하지 않고 OS에 위임하기 때문에 프로세스를 재시작 하더라도 OS의 페이지 캐시는 그대로 남아있습니다. 따라서 프로세스 재시작 후 캐시를 워밍업할 필요가 없다는 장점도 있습니다. 여기서 워밍업이란 시스템이나 어플리케이션 시작 시, 또는 특정 작업 수행 전에 캐시를 미리 채워두는 작업을 의미합니다.

요약하면, 카프카는 데이터를 힙 메모리 내에 객체로 저장하는 대신 운영체제가 훌륭하게 최적화하고 있는 페이지 캐시를 활용한 디스크 저장 방식을 도입하여 성능을 높일 수 있었습니다.

세번째, 제로 카피 기법을 도입했습니다.

zero-copy 는 디스크의 데이터를 네트워크로 전송할 때 일어나는 데이터 복사 작업을 최소화 한 데이터 전송 방식입니다. 카프카에서는 파일 시스템에 저장된 메시지를 네트워크를 통해 전송할 때 zero-copy 기법을 사용하여 데이터 전송 성능을 향상시켰습니다. 일반적으로 파일 시스템에 저장된 데이터를 네트워크로 전송할 때는 아래 그림과 같은 데이터 전달이 이루어집니다.

1. 디스크 → Read Buffer (DMA ; Direct Memory Access)

• 유저가 read() 시스템콜을 호출하면, DMA 엔진에 의해 디스크로부터 데이터를 읽어 커널 영역의 Read Buffer 에 저장합니다.

2. Read Buffer → Application Buffer (CPU)

• 커널 주소 공간에는 유저가 접근할 수 없으므로, Read Buffer 의 내용을 Application Buffer 로 복사합니다.

3. Application Buffer → Socket Buffer (CPU)

• 유저는 Application Buffer 에서 읽어들인 데이터를 Socket Buffer 로 전송하기 위해 send() 함수를 호출하고, send() 함수 호출 시 커널 영역에 있는 Socket Buffer로 데이터를 복사합니다.

4. Socket Buffer → NIC Buffer (DMA)

• Socket Buffer에 있는 데이터를 NIC Buffer로 복사하고 네트워크를 통해 전송합니다.

전통적인 데이터 복사 방식은 4번의 컨텍스트 스위칭과 4개의 메모리 복사본이 생기면서 불필요한 복사와 시스템콜이 발생하게 됩니다. 이처럼 비효율적인 동작을 개선하기 위해 소개된 기법이 zero copy 입니다.

리눅스 2.2 버전에서 처음 소개된 sendfile() 시스템 콜이 제로카피 동작을 구현했는데요.

#include<sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t * offset ", size_t" " count" );

자바에서는 nio 패키지의 transferTo(), transferFrom() 메소드로 구현되어 있으며, 이 메서드들 역시 sendfile() 시스템콜을 이용해 구현되어 있습니다.

public void transferTo(long position, long count, WritableByteChannel target);

zero copy 를 사용하면, 커널 영역의 Read Buffer 에서 Socket Buffer로 직접 복사가 가능하여 효율적으로 데이터를 전송할 수 있습니다. read(), send() 2번의 시스템콜이 transferTo() 1번의 호출로 가능해졌습니다.

1. 유저가 transferTo() 메서드를 통해 파일 전송을 요청합니다.
2. read() 시스템콜과 동일하게, DMA 엔진이 디스크에서 파일을 읽어 커널 주소 공간에 위치한 Read Buffer에 데이터를 복사합니다.
3. 커널 모드에서 유저 모드로 컨텍스트 스위칭 없이, 바로 Socket Buffer로 데이터를 복사합니다.
4. Socket Buffer에 복사된 데이터를 DMA 엔진을 통해 NIC Buffer로 복사합니다.

따라서 transferTo() 메서드 호출시 커널모드로 1번, 종료시 유저모드로 1번, 총 2번으로 컨텍스트 스위칭 횟수가 줄었고, 데이터의 복사본이 4군데에서 3군데로 줄어들었습니다. *컨텍스트 스위칭 횟수와 복사본의 개수가 줄어든만큼 CPU 자원의 낭비가 줄어들게 되어 성능이 향상되었습니다. *

리눅스 커널 2.4 이후부터는 NIC 장비가 “Gather Operation”을 지원할 경우 복사본을 더 줄일 수 있게 되었습니다.

1. 사용자가 transferTo() 메서드를 호출합니다. DMA 엔진이 디스크에서 파일을 읽어 커널에 위치한 Read Buffer로 데이터를 복사합니다.
2. 데이터를 Socket Buffer 로 복사하지 않는 대신 데이터가 저장된 위치와 데이터 사이즈에 대한 정보와 함께 디스크립터가 Socket Buffer 에 추가됩니다.
3. DMA 엔진은 이 정보를 이용해 Read Buffer에 있는 데이터를 NIC Buffer 에 바로 복사하고, 네트워크로 데이터를 전송합니다.

이러한 최적화를 위해서는 Gather operation과 프로토콜의 checksum 기능이 추가적으로 필요합니다.

아래 그래프는 실제 리눅스 2.6 커널 버전에서 성능을 비교한 것인데요. 전통적인 방식의 파일 전송과 transfer() 메소드를 이용한 파일 전송 속도를 비교했을 때, 수행시간이 50% 이상 줄어들었습니다.

디스크에서 파일을 읽은 후 추가 작업 없이 바로 네트워크로 전송하는 파일 서버나 정적 파일을 전송하는 웹 서버의 경우 zero copy 기법을 사용하면 성능 개선 효과를 얻을 수 있습니다. 특히 네트워크 속도가 매우 빨라서 성능상 병목점이 CPU로 몰릴 수록 불필요한 데이터 복사를 제거하여 성능 개선을 도모할 수 있습니다.

요약하자면, 디스크에서 파일을 읽고 네트워크로 전달하는 과정에서 read(), send() 두번의 시스템 콜로 인한 컨텍스트 스위칭과 데이터 복사에 따른 성능 저하가 따랐습니다. zero copy의 transferTo() 메서드를 통한 하나의 시스템콜을 활용함으로써, 컨텍스트 스위칭과 데이터 복사에 필요한 비용을 줄여 성능 개선을 이루었습니다.

디스크의 순차적 I/O, 페이지 캐시, 제로 카피.

이 3가지 방법을 사용하여 카프카는 파일 시스템을 메시지의 주 저장소로 사용하면서도 뛰어난 처리량을 구현해낼 수 있었습니다.

zero-copy

zero-copy 는 디스크의 데이터를 네트워크로 전송할 때 일어나는 데이터 복사 작업을 최소화 한 데이터 전송 방식이다. *카프카에서는 파일 시스템에 저장된 메시지를 네트워크를 통해 전송할 때 zero-copy 기법을 사용하여 데이터 전송 성능을 향상시켰다. * 일반적으로 파일 시스템에 저장된 데이터를 네트워크로 전송할 때는 아래와 같은 데이터 전달 절차로 이루어진다.

1. 디스크 → Read Buffer (DMA ; Direct Memory Access)
   • 유저가 read() 시스템콜을 호출하면, DMA 엔진에 의해 디스크로부터 데이터를 읽어 커널 영역의 Read Buffer 에 저장
2. Read Buffer → Application Buffer (CPU)
   • 커널 주소 공간에는 유저가 접근할 수 없으므로, Read Buffer 의 내용을 Application Buffer 로 복사
3. Application Buffer → Socket Buffer (CPU)
   • 유저는 Application Buffer 에서 읽어들인 데이터를 Socket Buffer 로 전송하기 위해 send() 함수 호출
   • send() 함수 호출 시 커널 영역에 있는 Socket Buffer로 데이터 복사
4. Socket Buffer → NIC Buffer (DMA)
   • Socket buffer에 있는 데이터를 NIC buffer로 복사하고 네트워크를 통해 전송
     

전통적인 데이터 복사 방식은 4번의 컨텍스트 스위칭과 4개의 메모리 복사본이 생기면서 불필요한 복사와 system call이 발생하게 된다. 이처럼 비효율적인 동작을 개선하기 위해 소개된 기법이 zero copy 이다.

리눅스 2.2 버전에서 처음 소개된 sendfile() 시스템 콜이 제로카피 동작을 구현하고 있다.

#include<sys/sendfile.h>
ssize_t sendfile(int out_fd, int in_fd, off_t * offset ", size_t" " count" );

자바에서는 nio 패키지의 transferTo(), transferFrom() 메소드로 구현되어 있으며, 2가지 메서드 역시 sendfile() 시스템 콜을 이용해 구현되어있다.

public void transferTo(long position, long count, WritableByteChannel target);
cs

zero copy 를 사용하면, 커널 영역의 Read Buffer 에서 Socket Buffer로 직접 복사가 가능하여 효율적으로 데이터를 전송할 수 있다. read(), send() 두번의 시스템콜이 transferTo() 한번의 호출로 가능해진다.

1. 유저가 transferTo() 메서드를 통해 파일 전송 요청
2. read() 시스템콜과 동일하게, DMA 엔진이 디스크에서 파일을 읽어 커널 주소 공간에 위치한 Read buffer에 데이터를 복사
3. 커널 모드에서 유저 모드로 컨텍스트 스위칭 없이, 바로 Socket buffer로 데이터를 복사
4. Socket buffer에 복사된 데이터를 DMA 엔진을 통해 NIC buffer로 복사

따라서 transferTo() 메서드 호출시 커널모드로 1번, 종료시 유저모드로 1번 총 2번으로 컨텍스트 스위칭으로 줄었고, 데이터의 복사본이 4군데에서 3군데로 줄어들었다. 컨텍스트 스위칭 횟수와 복사본의 개수가 줄어든만큼 CPU 자원의 낭비가 줄어들게 되어 성능이 향상되었다.

리눅스 커널 2.4 이후부터는 NIC 장비가 “Gather Operation”을 지원할 경우 복사본을 더 줄일 수 있게 되었다.

1. 사용자가 transferTo() 메서드를 호출한다. DMA엔진이 디스크에서 파일을 읽어 커널에 위치한 Read Buffer로 데이터를 복사한다.
2. 데이터를 Socket Buffer 로 복사하지 않는 대신 데이터가 저장된 위치와 데이터 사이즈에 대한 정보와 함께 디스크립터가 Socket Buffer 에 추가된다.
3. DMA 엔진은 이 정보를 이용해 Read Buffer에 있는 데이터를 NIC Buffer 에 바로 복사하고, 네트워크로 데이터를 전송한다.

이러한 최적화를 위해서는 Gather operation과 프로토콜의 checksum 기능이 추가적으로 필요하다.

아래 표는 실제 리눅스 2.6 커널 버전에서 성능을 비교한 것인데 전통적인 방식의 파일 전송과 transfer() 메소드를 이용한 파일 전송 속도를 비교했을 때, 수행시간이 약 65% 줄어들었다.

디스크에서 파일을 읽은 후 추가 작업 없이 바로 네트워크로 전송하는 파일 서버나 정적 파일을 전송하는 웹 서버의 경우 zero copy 기법을 사용하면 성능 개선 효과를 얻을 수 있다. 특히 네트워크 속도가 매우 빨라서 성능상 병목점이 CPU로 몰릴 수록 불필요한 데이터 복사를 제거하여 성능 개선을 도모할 수 있다.

요약하자면, 디스크에서 파일을 읽고 네트워크로 전달하는 과정에서 read(), send() 두번의 시스템 콜로 인한 컨텍스트 스위칭과 데이터 복사에 따른 성능 저하가 따랐다. zero copy의 transferTo() 메서드를 통한 하나의 시스템콜을 활용함으로써, 컨텍스트 스위칭과 데이터 복사에 필요한 비용을 줄여 성능 개선을 이룰 수 있다.

금융계산에는 BigDecimal, int 혹은 long 을 사용하라

즉, 정확한 결과가 필요할 때는 BigDecimal 을 사용해야 한다. 이 게시물에서는 BigDecimal 의 개념과 사용 시 유의해야 할 점들 위주로 정리를 해보려고 한다.

BigDecimal 이란?

공식문서 설명은 아래와 같이 설명하고 있는데, 이 중 핵심만 뽑아내보겠다.

Immutable, arbitrary-precision signed decimal numbers. A BigDecimal consists of an arbitrary precision integer unscaled value and a 32-bit integer scale. If the scale is zero or positive, the scale is the number of digits to the right of the decimal point. If the scale is negative, the unscaled value of the number is multiplied by ten to the power of the negation of the scale. The value of the number represented by the BigDecimal is therefore (unscaledValue × 10-scale).

• Immutable, arbitrary-precision signed decimal numbers. : 불변의, 임의 정밀도와 부호를 가진 10진수
• arbitrary precision integer unscaled value and a 32-bit integer scale : 임의 정밀도를 나타내는 unscaled value와 32bit의 scale로 이루어짐

여기서 임의 정밀도를 나타내는 unscaled value 와 scale 은 무엇을 뜻할까?

• unscaled value는 정수부를 표현하고, scale은 소수점 아래 자릿수를 표현한다. ex) BigDecimal 3.14의 경우 unscaled value는 314이고 scale은 2가 된다.

여기서 임의 정밀도라는 개념이 나오게 되는데 조금 더 자세히 알아보자!

임의 정밀도란?

• 정수나 소수를 정확히 표현하기 위해 제한이 없는 정밀도
• 정밀 계산이 필요한 금융, 과학, 통계 분야에서 유용하게 사용된다.
• 큰 숫자 = [int] + [int] + [int] ... 의 형태로, 정수를 숫자 배열로 간주하고 자릿수 단위로 쪼개서 배열형태로 표현함으로써 무제한 자릿수의 정수를 담는 방식이라고 생각하면 된다.

그렇다면, BigDecimal 을 사용할 때 주의해야 할 점은 무엇일까?

1. BigDecimal 초기화할 때, String 으로 초기화하자!

    // double 타입을 그대로 초기화하면 기대값과 다른 값을 가진다.
    // 0.01000000000000000020816681711721685132943093776702880859375
    new BigDecimal(0.01);

    // 문자열로 초기화하면 정상 인식
    // 0.01
    new BigDecimal("0.01");

    // 위와 동일한 결과, double#toString을 이용하여 문자열로 초기화
    // 0.01
    BigDecimal.valueOf(0.01);

double 타입을 그대로 초기화하면, 기댓값과 다른 결과를 낳는데 왜 double 타입을 받는 생성자가 있을까? 하는 의문이 들어 BigDecimal 클래스를 살펴보았다.

1. 이 생성자의 결과는 예측하기 어려울 수 있습니다. 예를 들어, Java에서 new BigDecimal(0.1)을 작성하면 0.1과 정확히 일치하는 BigDecimal이 생성되는 것으로 생각할 수 있지만, 실제로는 0.1000000000000000055511151231257827021181583404541015625와 같이 나타납니다. 이는 0.1을 double로 정확히 표현할 수 없기 때문에 발생하는 현상입니다.
   2. 반면에 String 생성자는 예측 가능합니다. new BigDecimal("0.1")을 작성하면 기대한 대로 0.1과 정확히 일치하는 BigDecimal이 생성됩니다. 따라서 일반적으로 이 생성자 대신 BigDecimal(String) 를 사용하는 것이 권장됩니다.

주석을 통해서도 확인할 수 있듯이, BigDecimal 클래스에서도 String 생성자를 사용하는 것을 권장하고 있다.

그래서 double 생성자 존재 이유에 대한 결론을 내리면, BigDecimal 클래스의 double 타입을 받는 생성자는 부동 소수점 오차를 피하고 정확한 10진수 연산을 위해 제공하고 있다. 명시적으로 이런 생성자를 제공함으로써 double -> BigDecimal 로 변환하도록 도와주긴 하지만, 이미 double 자체가 정확한 10진수로 변환될 수 없는 부정확한 값을 가지고 있기 때문에 정확성을 보장할 수 없다고 한다.

2. BigDecimal은 기본 타입이 아닌 오브젝트이기 때문에 동등 비교 연산 시 유의하자!

• equals() : unscaled value, scale 을 모두 비교
• compareTo() : 소수점 맨 끝의 0을 무시하고 값만을 비교하고 싶을 때 사용

    final BigDecimal b1 = new BigDecimal("7.10");
    final BigDecimal b2 = new BigDecimal("7.1");

    System.out.println(b1 == b2); 
    // false _ 주소값 비교

    System.out.println(b1.equals(b2)); 
    // false _ 7.10과 7.1은 논리적으로 같은 수일지라도, 소수점아래 자릿수가 다르므로 equals의 결과는 false

    System.out.println(b1.compareTo(b2)); 
    // 0 (true) _ 0을 무시하고 7.1 로만 비교하니까 0 출력

1) 2022년에 세웠던 2023년 목표를 얼마나 이루었는지 되돌아보고 2) 2023년을 크게 4가지 키워드 [취업, 독서, 운동] 로 되돌아보고 3) 2024년의 액션아이템을 정해보려고 한다

그럼 스따또.

2022년에 적은 2023년 목표 되돌아보기

위의 목표는 2022년 회고에 적었던 내용을 그대로 들고 왔다!

2023년 목표 *"미니멀리스트가 되자"*

1. 버릴 줄 아는 사람이 되자 (중략) 조급하면 될 것도 안된다 … 인생 80살까지 산다고 생각하면 당장 눈앞에 1년 뭐가 중요할까,,, 여유를 가질 줄 아는 사람이 되자,,, (중략)

2. 내 감정을 스스로 컨트롤할 줄 아는 사람이 되자 (중략) 부정적인 감정을 훌훌 털 줄 알고 그 과정에서 내 옆에 있는 사람들에게도 잘하는 사람이 되고 싶다 (중략)

3. 제발 운동하자 제발제발제발제발제발제발 미친사람아 제발 🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏 (중략) 제발 싸피하면서 건강챙기자 ...............제발... 정말 간절한 목표다 ..............제발 내가 했으면 ...........일주일에 2번이라도 하자..... (중략)

늘 그랬듯 내가 덜 후회 할 선택을 하자 !!!

그래서.. 목표를 이루셨는지?

Q1. 버릴 줄 아는 사람이 되었는가? A1. 적당히 버렸다. 취업하고 3월 말부터 6월말까지 정말 회사일 외에는 아무것도 안했다.. 집에오면 진빠져서 누워있는 이슈 + 회사 적응부터 하자 였기 때문에..

매일 같이 퇴근하고 노는게 일상이었고 3개월 내내 탱자탱자 신나게 놀았다

그러고 나니 7월부터는 슬슬 노는게 지겨워지고 (?) 무언가를 새로 시작할 힘이 생겨서 하반기는 북스터디로 야무지게 달렸다!! 3개월 논거 내 나름대로 많이 버렸다고 생각한다… 내나름대론…

Q2. 내 감정을 컨트롤 할 줄 아는 사람이 되었는가? A2. 잘 모르겠어요. 부정적인 감정… 그렇게 올 한해는 크게 뭔일이 나진 않아서 2번에 대해 고려해본적이 없는 거 같은데.. 그치만 올 한 해 인간관계에서 가장 크게 느낀 것은 하나 있는데.. 나한테 잘해주는 사람 아니면 나도 그냥 그사람이 하는 행동 고대로 똑같이 대해주기로 다짐했다 ~ 이래야 인생살기 좀 편할거 같드라구요

Q3. 운동을 하는가? A3. 시도를 하긴 했다 (9월~12월) 비록 12월 중순부로 피티를 끊고 다니지는 않지만… 내년에는 허리통증 없애기에 전념할 예정 아좌작 !!!!!!!!!!

위의 목표 플러스 알파로 적어두었던게 있길래 하나하나 짧게씩이라도 기록해보려고 한다 생각보다 적어둔게 많아서 힘들군요

2023년 ~ 나의 목표 ~

1. 취업하면 너무 좋지만 압박감에 나를 혹사 시키면서 조급해 하지는 말며 취업하기 (?)

→ 4월 첫출근이면 내 생각보다는 빠르게 취업함 2. 맛있는 스시 나오는 오마카세 먹기. 초 밥 좋 아 → 못먹음 3. 교복 입고 에버랜드 가기, 에버랜드 안간지 15년도 넘었으니 갈 때 됐다 → 못입음. 못감 4. 겨울에 캐리비안베이 가기, 얼굴만 동동 뜨고 위에는 춥지만 아래는 따뜻한 몽롱한 기분 아주 궁금하다 → 못감 5. 일본 가서 규카츠랑 사케동 먹기, 규카츠가 입에서 사르르 녹는다는데 진짜 먹고싶다 → 못감. 못먹음 6. 제발 일주일에 2번 이상 운동하기. 제발 해주세요 → 하다가 말았음 7. 클라이밍 한 달에 1번 이상 가보기. 클라이밍도 재밌던 데 나름의 취미로 삼고 싶어요 → 한번도 안감 8. 욕하지 않기. 대신 웃을 때만은 허용해주세요 → 안한 거 같긴함 아닌가? 화날때도 한거같긴함 9. 독서하는 습관 책 6권 이상 읽기. 절대 안할 것 같음 → 북스터디 덕에 6권읽음 10. 취미 찾기. 독서가 취미가 됐으면 → 취미 못찾음. 독서는 아직 취미라고 하긴 너무 강제적임 11. 자취방 깔끔하게라도 꾸며보기. 지저분하지만 않게 살자 → 지저분함 12. 해외 2번 이상 가기, 그곳이 어디든. → 1번도 못감 13. 여름에 강릉 가기. 강릉엔 항상 좋은 기억들이 많다 → 못감 14. 호캉스 가보기. 호호 불면은 구멍이 뚫리는 커다란 솜사탕 → 못감

• 1번, 9번 완벽달성
• 6번, 8번 애매모호
• 나머지 미달성

2023년, 내가 되고 싶은 ~ 나 ~

1. 하고 싶은 게 생겼을 때 최대한 기회를 잡는 사람 → 하반기에는 심적 여유가 있을 때는 나름 하고 싶었던 것들을 다 도전했음 (북스터디, 외부스터디, 글또) 하지만,, 회사에서 하는 활동 하나를 신청안한게 아직도 후회되는 게 있음
2. 올 한해도 내가 좋아하는 사람들과 행복하게 사는 사람 → 적당히 만나고싶은 사람들만 만나면서 잘 살았음
3. 감사함을 그 때 그 때 표현할 줄 아는 사람 → 고마운건 그때그때 잘 말함
4. 용기내서 내 마음을 말할 줄 아는 사람 → 적당히 할말은 하고 산 듯
5. 부정적인 감정을 빠르게 털어내는 사람 → 하루종일 감. 그래도 저녁에 자고 아침에 일어나면 풀려고 노력했음
6. 기분이 태도가 되지 않는 사람 → 태도가 된 때도 있음
7. 다른 사람의 성공을 진심으로 응원해줄 수 있는 사람 → 사람인지라 여전히 쉽지 않음 사바사 케바케 심함
8. 누군가의 꿈이 되는 삶을 사는 사람 → 이건 모르겠음
9. 만나면 또 만나고 싶은 사람 → 이것도 난 모름
10. 주변 사람을 잘 챙기는 사람 → 잘 챙기지 못한 거 같음

생각보다 자잘하게 적은 투두들은 이루지 못한 것들이 많은 거 같다

흠… 생각보다 내 일상을 채우는 재미있는 활동을 대부분 못한 거 같은데 2024년에는 여가활동도 조금 더 …? 해보면 풍요로운 한 해가 될 거 같다 !

2023년 한 해 되돌아보기

취업

뭐니뭐니해도 2023년 가장 뿌듯하고 행복했던 일은 취업을 했다는 것이다. 작년 하반기부터 조금씩 준비해왔지만 본격 취준은 올해 1월 싸피에 입과하면서부터였다. 9-6시 싸피 수업을 듣고, 수업이 끝나면 도서관에 가서 코테 공부를 하고 돌아와 1시쯤 잠에 들면 7시 반쯤 일어나서 다시 싸피를 갔다. 이 생활을 2주 정도 하고 나니 도저히 이건 1년동안 버틸 수 없겠다 싶었다. 그래서 최대한 빨리 나가는 것을 목표로 잡고 아등바등하다가 3월 29일 싸피를 나가게 되었다. 내 생각보다 더 빠른 싸탈이라서 아직도 놀라운 것 같닥 ㅋ.ㅋ.ㅋ.

가고 싶었던 1순위 회사는 아니었지만, 현재 투입된 프로젝트에서 배울 것도 많고, 함께 하는 팀원들이 너무 좋고 재미있어서, 어느 정도 만족하며 다니고 있다.

취업 준비할 때의 간절함을 잊지 말자라는 문장을 주기적으로 생각하고 출근한다…

그리고 신입사원 교육이랑 연수에서 액자랑 무드등 만들었는데 거기에 적은 문구는 아래와 같다

간절했던 마음을 잊지말자 (입사하자마자) 열정을 전파하자 (입사한지 8개월 후)

이 두가지 문장을 마음속에 품고,,,,,열심히 회사를 다녀보도록 하쟈,,,,,,,,

아침에 일어나는 건 여전히 너무 힘든 것 같다. 아침마다 풀재택근무 회사가고 싶다는 생각을 하며 일어나곤 한다… 그치만 회사가도 항상 후회는 없이 맛있는 밥도 먹고 열심히 집중해서 일하다 와서 여전히 회사가는게 더 좋다구 생각은 한다.. 그치만 일어나기싫어

일단 회사에 가서 깨진 고정 관념들도 있고, 새로 깨달은 점이 몇가지 있어서 적어보려고 한다

신기술 써보는 게 장땡이 아니다.

취준을 하면서 채용공고 필수/우대 사항을 보다보면, 새로운 기술적 개념 + 키워드들에 대해 공부를 해야 한다는 생각이 자주 들었다. 그 기술을 왜 사용해야 하는지도 모르고 냅다 덤벼들어 공부를 해왔던 것 같다. 그런데 회사에서 온보딩을 하며 다른 분이 받은 코멘트를 보니 "회사에서는 '딱히 이유는 없다' 라는 말은 먹히지 않는다." 였다. 그 말이 확 와닿았는데, 결국 회사에서 어떠한 기술을 사용하여 구현했을 때는 그냥 신기술이니까~ 내가 한번 써보고 싶으니까~ 와 같은 이유는 받아들여지지 않는다는 것이다. 지금 내가 구현하는 코드에 해당 기술이 필요한 이유가 무엇이고, 기술을 도입했을 때 발생하는 사이드이펙트는 뭐고, 현재 조직원들이 그 기술을 받아들일 여유가 있고 실력을 갖추고 있는지 등등 고려해야할 사항들이 정말 많다. 그래서 무조건 신기술 신기술 !!!!!! 하던 생각이 옳지 않았다는 것을 (개인적인 생각임) 느꼈고, 여러 기술들을 써보고 왜 쓰는지에 대한 이해를 바탕으로 개발을 하는 것이 오히려 더 중요하다는 것을 깨달았다. 회사에서 못쓴다고 불평불만할게 아니라, 정 궁금하면 사이드 프로젝트로 하면 된다!

도메인 지식이 너무나도 중요하다.

그리고 나는 능력있는, 잘하는 개발자로서의 역량으로 구현능력만을 생각해왔던 것 같다. 취준생때는 다른 사람들의 이력서나 깃허브를 보면서 난 이 기술을 안써봤는데, 이 사람은 할 줄 아네.. 나도 공부해야하는데.. 어떡하지.. 이런식으로 사고가 흘러갔고 내가 부족한 기술적 부분만 보였다.

하지만 회사는 구현 능력 뿐만 아니라 도메인 지식이 정말x100 중요하다는 것을 느꼈다. 모빌리티 산업에 무지했던 나였기에 msrp, fsc 등등 자동차 산업에서 일반적으로 자주 쓰이는 용어들도 몰라서 코드를 보는데 이해가 안되는 부분이 너무 많았다. 그래서 사내 문서나 코드 주석을 참고해서 궁금한 단어를 다 검색해서 자료를 끌어 모아모아 해석해보기도 하고, 많이 물어보면서 도메인 지식을 나름대로 정리해왔다. 하지만 여전히 나는 이 산업에 대해 모르는 게 너무 많은 것 같고, 앞으로도 배워갈 게 많다는 생각이 든다..

그래서 2024년에는 현재 하는 프로젝트에서 배울 수 있는 걸 끌어 모아모아, 누가 물어봐도 이 프로젝트에 적용된 도메인 지식에 대해 대답할 수 있을 정도로 성장하고 싶다. 개발단계 뿐만 아니라 기획/검토 단계에서도 풀어지지 않고, 누구보다 꼼꼼하게 검토하고 문서화하면서 프로젝트에 기여할 수 있는 사람이 되고 싶다 !

문서화의 중요성에 대해 알았다.

처음에는 이걸 왜 정리하고 있는거지.. 라는 생각이 들었고 뭐라도 개발하고 싶고 코드를 치고 싶다는 생각이 많이 많이 들었다

하지만 나는 회사에 속해있고 혼자 일하는 사람이 아니니까.. 함께 일하기 위해서 사용되는 깔끔하고 구조화된 문서가 생산성을 크게 높여준다는 것을 알게 되었다. 같이 일하시는 분 중에 문서화를 증말 기깔나게 하시는 분이 있는데,, 매번 그 문서를 통해 추가 개발 요건에 대한 검토도 쉽게 할 수 있었고, 기획 검토 단계에서는 개발할 때 고려해야 할 부분들을 단번에 모아볼 수 있어서 참 편했다. 그분의 노하우.. (?) 어깨너머 배워봐야겠다. 그래서 나도 누군가에게 도움이 되는 문서, 누가 봐도 알아보기 쉽고 이해하기 쉬운 문서를 작성하고 싶다 !!!

그래서 사실 지금까지 문서 작업을 하면서도 함께 문서를 작성하는 분과 의논하에, 어떻게 하면 더 이해하기 쉬울지, 다른 사람들이 따라할 때 편할까? 를 고민하면서 많이 수정해왔다 !

지금해왔던 것처럼 꼼꼼하게 체계적으로 문서를 만들어보자 ~ 개발안한다고 불평하지말고말야

찾았다 내 롤모델.

총 세분의 롤모델인데,, 자세히 쓰면 드러날 거 같기 때문에 슬렁슬렁 얼레벌레 대충대충 써보려곻 한다

커뮤니케이션 / 개발 / 회사 다니는 마인드 부분에서 배우고 싶은 점이 있는 분들이어서 배울 점들을 쏙쏙 골라 닮아보려고 한다.

1) 커뮤니케이션

• 기획과 사업에서 들어오는 요구사항들을 쳐낼건 쳐내면서 효율적으로 의사소통하시는 거 같다..
• 우선순위에 따라 해야할 일 정리를 잘해주셔서 함께 일하기가 정말 편하고 수월하다..
• 그리고 정말 설명을 잘해주신다.. 이 일을 왜 해야하는지에 대한 설명을 더해주셔서 목적의식을 갖고 일을 하게 된 계기가 된 것 같다
• 이 분이 리더인 조직에서 일하는 사람들은 정말 복받은 거라는 생각이 드는 분이다.. 그냥 함께 있으면 업무 외적으로도 즐겁고 편안한 분위기를 만들어주시는 분이다

2) 개발

• 코드리뷰가 정말 꼼꼼하다.. 리뷰 뿐만 아니라 그냥 모든 업무가 다 꼼꼼하셔서 너무 일잘러다..
• 일할 때 집중해서 하는 모습이 넘 멋지다..
• 코드도 깔끔하고 너무 잘짜신다.. 근데 문서도 잘쓰신다.. 근데 이슈대응도 빠르시다.. 너무 너무 부럽다
• 의견 제시를 하실 때 (의견 + 의견에 대한 타당한 근거) 를 함께 말씀해주시는 게 도움이 많이 된다
• 큰 그림을 잘 그리시는 것 같다.. 뭔가 검토할 때 멀리보고 확장성을 고려한 설계를 하시는 게 정말 멋지다..
• 내가 이분 연차가 되어도 이분처럼 될 수 있을까..? 라는 생각이 들 정도로 멋진 분이고 배울점이 너무 많은분이다..

3) 회사 다니는 마인드

• 회사 생활을 할 때 크게 뭔가 걱정하지 않고 좋은 게 좋은 거지의 느낌으로 다니시는 거 같아서.. 유리멘탈인 나로서는 그런 여유롭고 안정적인 마인드가 부럽다..

취업 분야 4L 회고

• Liked : 좋았던 점은 무엇인가?
  • 꾸준히 열심히 해왔던 것을 바탕으로 기회가 왔을 때 잡을 수 있었다는 생각이 들어서, 뿌듯하고 행복했다.
  • 다행히 개발하는 팀에 들어오게 되어서 성장할 수 있는 기회들이 많이 있을 것 같아 기대가 된다.
    
    
• Lacked : 아쉬웠던 점, 부족한 점은 무엇인가?
  • 조금 더 적극적으로 질문하지 못했던 것이 아쉬웠다. 지금 상황에서 이걸 물어봐도 되나? 하는 의문들이 계속 생겨서 물어보지 못한 것들도 있었는데, 망설일 때가 가장 빠른 시기니까 바로 물어보고 궁금증을 해결해야 겠다.
    
    
• Learned : 배운 점은 무엇인가?
  • 회사에서는 일을 주기만을 바라면 안된다. 일이 없을 때는 스스로 찾아서 하는 방법도 터득해야 한다.
    
    
• Longed for : 앞으로 바라는 것은 무엇인가?
  • 회사 코드에서 아직도 잘 모르는 부분에 대해서 스스로 공부하는 시간을 가지고, 적극적인 질문으로 부족했던 도메인 지식을 채워가자
  • 적극적으로 질문하는 태도를 가지자
  • 시킨다고 아무생각 없이 일하지 말고, 이 일을 왜하는가? 에 대한 근본적인 질문에 대해 스스로 대답해보며, 일의 의미를 찾자

운동

작년 말에 허리디스크 초기라는 진단을 받았다. 1-2월에 싸피를 하면서 통증이 심해져서 두 달 동안 병원을 매주 갔던 것 같다. 이제는 정말 살기 위해서라도 운동이라는 걸 해야될때가 온 것 같구나라는 생각이 들었다. ㅠ ㅠ

그래서 운동과는 정말 거리가 먼 나인데도 불구하고 큰 마음을 먹고 자취방 근처 헬스장을 알아보기 시작했다. 그렇게 PT 20회와 헬스장 이용권을 끊었고 130만원 지출을 하게 되었다. 나에게는 너무 큰 돈이었지만, 운동을 그렇게 하기 싫어하던 내가 일주일에 적어도 2번은 피티를 받으러가고 매번 갈때마다 조금씩 무게와 횟수가 늘어가는 걸 보면서 뿌듯했다 ㅎㅋㅎㅋㅎ 하지만 피티가 아닌 날에는 단 한번도 운동을 가지 않았기에 헬스장 이용권은 거의 버린 셈이었다,,, 그래도 25년 동안 운동안하다가 일주일에 2번이라도 간게 어디냐라고 생각하고 있다.. 20회를 다 끝내고 피티를 조금만 더 받고 개인운동을 하고 싶어서 피티를 재등록했는데, 최근 디스크가 더 악화되어 더이상 피티를 받을 수는 없는 상황이 되었다.

허리가 안좋은데 운동을 잘 모르고 해서 더 악화된건가? 하는 생각이 순간 들어서 속상한 마음도 있었지만 회사를 다니면서 앉아있는 시간이 훨씬 길어져서 그런거라고 생각하려고 한다. 하하

20만보 걷기 챌린지. 장렬히 실패.

10월, 11월에는 회사에서 20만보 걷기 챌린지 이벤트가 있었다. 20만보를 달성한 사람들 중 5명을 추첨하여 에어팟을 준다고 하여 걷기 챌린지하려고 애플 워치까지 샀다. 내가 생각해도 너무 충동적인 구매였는데, 아니나 다를까 한 4번 착용하고 안쓰고 있어서 당근에 팔아버리려고 한다. 아무튼 20만보 걷기를 우리팀+타팀 동기들이랑 같이 내기를 했는데, 마감 날짜를 착각해서 19만 3천보를 달성해버려서 에어팟에 응모조차 못했다. 그리고 11월에는 추운 날씨 이슈로 일주일만에 포기해버렸다. 그래도 회사 덕에 매일 8천보씩 걷고 양재시민의숲역부터 양재역까지 걸어서 퇴근하기도 하면서, 건강을 조금은 얻었을 거라고 생각한다..

올한해는 건강을 최우선목표로 잡고 건강을 챙기려고 한다 !!! 허리아프니까 정말 앉아있기가 힘들고 그래서,, 자취방과 본가에 모션데스크를 사두려고 한다 내 허리건강 지켜 걷기 운동도 퇴근하는 시점을 활용해서 30분씩 걷고, 허리 치료가 어느정도 진행되면 피티 말고 헬스장을 자발적으로 가는 멋진 어른이 되어보려고 한다..

운동 분야 4L 회고

• Liked : 좋았던 점은 무엇인가?
  • 돈을 쏟아붓긴 했지만, 그래도 일주일에 2번씩은 운동을 한 것만으로도 뿌듯했다.
    
    
• Lacked : 아쉬웠던 점, 부족한 점은 무엇인가?
  • 피티 외에는 한번도 혼자 운동하러 헬스장을 가지 않은게 아쉽다. 헬스하려고 운동화도 샀는데 한번도 안 신고 신발장에 쳐박혀있다.
    
    
• Learned : 배운 점은 무엇인가?
  • 아무리 가까워도 헬스장은 혼자 가기 너무 어렵다. 빠른걸음으로 3분 정도 걸리는 거리였는데도 날씨가 추워지니까 피티조차 가기가 싫었다.
    
    
• Longed for : 앞으로 바라는 것은 무엇인가?
  • 일단 피티는 더이상 받지 않고, 허리디스크 치료에 집중을 하기로 했다.
  • 병원에서 알려주는 개인 운동을 루틴화하기
  • 주 5회정도는 30분씩이라도 걷기

독서

7월에 친구랑 만나서 우리 책을 좀 읽어볼까? 라는 이야기를 하다가 시작되었던 북스터디를 6개월 동안 지속해왔다. 처음에는 한 주에 한 챕터씩 읽는 것을 목표로 하였는데, 그렇게 되면 일요일에 항상 벼락치기할게 뻔하다는 것에 둘 다 동의했다. 그래서 매일 1문장이라도 읽기 + 한 주에 한 챕터 읽기, 이 2가지 목표를 가지고 북스터디를 진행해왔다. 하루 안 읽으면 벌금 1000원, 일주일동안 한 챕터를 못 읽은 경우 벌금 5000원으로 진행했고, 12월까지 모인 벌금이 약 15만원 정도였다. 친구와 함께 책을 읽으며 정리한 깃허브 레포 이다 !! 2023년 회고를 하면서 2023년 버전, 2024년 버전으로 노션을 싹 정리했는데 되돌아보았을 때 너무너무 뿌듯한 기록이 되었다

이 스터디를 안했으면 2023년 하반기는 아무것도 남지 않는다고 해도 과언이 아니다..

나는 북스터디를 통해 6개월동안 총 6권의 책을 완독할 수 있었다.

• 함께 자라기
• 육각형 개발자
• 오브젝트
• 자바 코딩의 기술
• 지대넓얕1
• 그림과 작동 원리로 쉽게 이해하는 AWS 구조와 서비스

토비의 스프링, 헤드퍼스트 디자인패턴, 자바 웹 프로그래밍 NEXT STEP, Docs for Developer 를 사두었는데, 그와중에 대규모 시스템 설계2 나왔다고 해서 그 책도 읽어보고 싶어졌다. 사놓은 거부터 읽자 제발

회사에서 지원해주는 도서구입비도 이용하고 사비로 사기도하면서 책을 모으는 재미에도 빠진 것 같다.. ㅎㅎ 이제 책을 사도 실물 책으로만 구매할 것 같다 ! 지금껏 온라인으로 산게 몇권 있는데 ,, 새로 사서 다시 한번 읽는 것도 좋을 것 같다는 생각이 든다.

2024년에는 자바 웹 프로그래밍 NEXT STEP 부터 다시 스터디를 시작할 건데,, 이건 쌩 이론이 아니라 구현과 동시에 가져가야 하는 책이라서 !!! 그래도 2024년에는 코드를 좀 칠 것 같다 기대가 된다

독서 분야 4L 회고

• Liked : 좋았던 점은 무엇인가?
  • 초등학생 때 이후로 정말 오랜만에 자발적으로 책을 읽고 있는 것만으로 뿌듯했다
  • 기술서적 위주로 읽었는데 코드를 실전에 많이 적용해보지는 못했지만, 코드를 볼 때 시야가 넓어진 것이 체감이 되어서 좋았다. 회사에서 리팩토링할 것들을 제안하라고 할 때, 책을 읽기 전에는 제안하지 못했을 내용들이 있어서 신기하고 뿌듯했다.
  • 꾸준함의 힘을 또 다시 느끼게 되었다. 책을 매일 매일 읽으면서 출퇴근길에도 시간을 허투루 쓰지 않고 자투리 시간을 활용하려는 내 모습을 볼 수 있어서 좋았다.
  • 누군가와 함께 책을 읽고 공부하고 있다는 것이 큰 힘이 되었다. 혼자 읽으려고 했으면 한 달도 못했을 것 같은데, 함께 스터디를 하는 사람이 있어서 책 읽기 싫으면 디코에서 함께 노래 틀어놓고 하기도 하면서 재미있게 책을 읽을 수 있었다.
  • 내가 어떤 분야에 관심이 있고 더 배우고 싶어하는지 확실히 알게 되었다. 백엔드 개발자로 취업하긴 했지만 클라우드/인프라 쪽에도 관심이 있어서 공부해보고 싶다는 생각이 있었다. 그런데 AWS 구조와 서비스 책을 완독하고 나니 클라우드를 더이상 공부하고 싶다는 생각이 사라졌다. 자바나 OOP 책읽는게 나에게는 훨씬 재밌다는 걸 느껴서 이 분야에 집중하려고 한다.
    
    
• Lacked : 아쉬웠던 점, 부족한 점은 무엇인가?
  • 12월에는 조금 열정이 떨어져서 그런지 벌금도 많이 내기도 했고, 친구가 쉬자고 할 때 같이 쉬어버리는 경우가 많았는데 1월부터는 다시 마음을 다잡고 새 시작을 해보려고 한다.
  • 책 내용을 그대로 요약하는 것도 물론 나중에 참고할 때 좋지만, 책 내용 플러스 알파로 찾아보면서 공부하는 시간을 가지지 못한 것이 아쉬웠다.
  • 책을 읽으면서 전에 했던 프로젝트 코드를 리팩토링해보고 싶다는 생각을 자주 했는데, 행동으로 옮기지 못한 것이 아쉬웠다.
    
    
• Learned : 배운 점은 무엇인가?
  • 좋았던 점 중에서 3번이 배운 점인 것 같다. 꾸준하게 책 읽고 루틴화하는 방법을 배울 수 있었던 것 같다.
    
    
• Longed for : 앞으로 바라는 것은 무엇인가?
  • 일단 미리 사두기만 한 책들이 널려있는데, 지금까지 읽은 책보다 조금 더 난이도가 있을 거라고 예상된다. 그래서 지금까지 해왔던 것처럼 꾸준함의 힘을 믿고 지치지 않고 완독하는 것이 목표이다.

2024년의 액션아이템

2023년을 돌아봤는데... 생각보다 많은 것들을 배우고 느낀 것 같다 이제 이걸 2024년에 적용하기만 하면 된다!!!! 내년의 마인드셋은 아래와 같다 !!

• 건강이 없으면 공부고 뭐고 아무것도 못한다 → 허리 건강 최우선으로 관리하기 !!!!!!!!!!!!!!!!!!!!!!
• 1년 전의 다른 사람과 비교하지 말고, 나 자신과 비교하기
• 회사 타이틀을 떼고도 개발자 OOO 로 홀로 설 수 있는 실력 만들기
• 열정을 주변에 전파하는 사람이 되기
• 이직은 먼 훗날이겠지만, 내가 앞으로 나아갈 목적지가 어딘지 생각해보기
• 세상은 좁으니 어딜 가서도 최선을 다하는 모습을 보여주기 (그 사람 정말 열심히 하던데? 하는 사람 되기)
• 기술적 겸손함을 갖추기 - 다 안다고 착각하지마라 넌 아는게없다 깨달음의 비탈길을 올라가는 한 해가 되자 ~

우선 크게 운동, 영어공부, 개발공부에 대해서는 해보고 싶은 것들을 투두리스트 형태로 정리해서 2024년 회고할 때 다시한번 얼마나 달성했는지 체크해보려고 한다 굵은 글씨는 반드시 해야 하거나 이미 확정된 일정들이고, 얇은 글씨는 선택사항이다!

업무 관점에서는 내가 업무를 하면서 갖춰야 할 마인드셋 위주로 정리를 했다

운동

일단 피티는 지금 당장은 못하지만, 디스크 치료와 개인 운동을 병행하면서 허리 아픈 것부터 조금 해결해보려고 한다. 젊으니까 좀만 관리해도 낫는다고 말씀하시니 많이 신경쓰면서 건강 관리를 해야겠다. 우하하

• 주 5회 30분씩은 걷기
  • 퇴근시간 이용하기 ; 선릉역으로 퇴근 / 하차 서울대입구 → 낙성대까지 걸어오기
  • 퇴근시간 이용하지 못할 경우 ; 알아서 걷기
• 허리 치료 끝내고 헬스장을 끊어서 최소 주 3회 운동하기
• 다리 스트레칭은 치료할 동안은 매일 하기
• 라운드 숄더 운동 하기

영어 공부

2024년에는 영어라는 키워드를 하나 더 해보려고 한다. 사실 올해도 말해보카라는 어플을 통해 조금씩이라도 영어 공부를 해왔는데, 내가 원하는 것은 영어 회화 공부이다. 회사에서 지원해주는 프로그램을 신청해서, 전화영어로 회화 공부를 하는 것이 목표인데,…………할지를 모르겠다

• 말해보카 매일하기
• 매일 1장 영어 쓰기 습관 100일의 기적 Advanced 완독
• 회화공부 <<< 회사 어학 프로그램 확인 후 추후 계획 작성 필요

개발 공부

자바, 스프링 위주의 책을 읽으면서 실무에서 적용가능한 개발 능력치를 갖추자 앞으로 읽으려고 사둔 책들이 대부분 분량이 많아서, 2024년에는 솔직히 2권…완독해도 잘했다고 생각한다

• 회사 스터디 (일주일에 3시간정도 투자)
• msa 스터디 (일단 이론 책부터 시작)
• 개발 관련 독서
  • 자바 웹 프로그래밍 next step
  • docs for developer
  • 헤드퍼스트 디자인패턴 완독
  • 토비의 스프링 1권 완독
• 구현 능력 키우기
  • url 단축기 만들기
  • XXX프로젝트 리팩토링
  • 테오의 프론트엔드 - 백엔드로 참여
  • 오픈소스 기여해보기
  • 해커톤 참여
  • 넘블 챌린지 참여
  • 재미있는 사이드 플젝 아이디어가 있다면 참여 or 모아보기
  • next step 강의 들으면서 코딩
• 직장인 동아리 가능한 경우 회사 일정 고려하여 지원해보기
• 오픈소스 컨트리뷰트 프로그램 참여
• 글또 X 유데미강의 듣기 (~4월)
  • 【Java 멀티스레딩, 병행성 및 성능 최적화 - 전문가 되기
  • 【한글자막】 Apache Kafka 시리즈 – 초보자를 위한 아파치 카프카 강의 v3

업무

내년 4월이면, 회사생활도 1년이 된다. 지금까지는 시키는 일이니까 하는, 조금은 수동적인 태도로 임했던 것 같다. 하지만 조금 더 적극적인 자세로 다른 사람이 하는 일에도 관심을 갖고 어떤 의미를 가진 일인지 이해하고 수행하는 태도를 가져볼 것이다. 그리고 남일이라고 생각하지 않고 같은 팀이니까, 다른 팀원분들께도 도움이 될 수 있을 정도로 도메인을 이해하는 능력치를 쌓는 것을 목표로.. !! 일잘러를 향해 한걸음…

• 이슈발생 시 어떤 이슈인지 바로 알아내는 사람으로 성장하기
• 개발이 아니라 기획 검토 단계에도, 관통하는 질문으로 기여하기
• 도메인의 큰 흐름을 파악하고 있는 사람으로 성장하기 (누가 물어봐도 대답할 수 있을정도)
• 이번해에는 적극적으로 많은 티켓을 할당받아 개발적으로도 회사에 기여하기
• 하고 싶은 일이 있으면 적극적으로 의사표현하기
• 내 일 아니라고 생각하지 말고 적극적으로 임하기
• 내가 바쁜 와중에도 다른 사람을 도와줄 수 있는 사람이 되기
• 바쁠 때 예민하게 행동하지 않기 (특히 말투 조심하기)
• 공개 커뮤니케이션하기
• 모르면 질문을 좀 하기 (갈수록 더 못 물어보게 됨)
• 업무할 때 나만의 생각과 개념을 정확히 정립한 후에 일하는 습관들이기
• 이 일을 하는 목적이 무엇이고, 어떤 방향으로 흘러가는 것이 옳은지 끊임없이 생각하기
• 스터디를 통해 발표할 기회 잘 활용하기

2023년도 수고한 나자신에게.. 2024년도 고생하렴.. 2024년 목표를 한마디로 정해보고 회고를 마치겠다 !!!!!!!!!!!!!!!!

후회없이 끊임없이 개발에 몰두한 2024년을 만들어가자 🤸‍♀️

정신 건강과 몸 건강을 모두 관리한 2024년을 만들어가자 👊

뭐라도 일을 벌려두지 않으면 아무것도 하지 않는 나를 위해...
이번에는 개발자 글쓰기 커뮤니티에 들어가는 선물을 주었다. 그 커뮤니티가 뭐냐면... 바로... [글또] (https://www.notion.so/zzsza/ac5b18a482fb4df497d4e8257ad4d516) 5개월 간의 글또 생활을 시작하며, 글또를 통해 내가 이루고자 하는 작은 목표들을 적어보려고 한다. (일단 적어놓으면 뭐라도 하겠지라는 생각으로... )

아래는 글또 OT 에서 운영자분께서 공유해주신 질문들이다. 꾸준히 글을 작성하기 위해서는** 단순히 이렇게 이렇게 해야겠다 라는 생각보다 나만의 액션 아이템 을 정하는 것**이 중요한 것 같다. 따라서 아래의 질문들에 짧게 답을 하며 나만의 액션 아이템을 정해보겠다!

• 글또가 끝난 5개월 후에 어떤 모습이길 바라나요?
• 그 모습을 달성하기 위해 무엇을 해야 할까요?
• 그걸 꾸준히 할 수 있는 방법은 무엇일까요?

5개월 후, 나의 모습

• 5개월 후의 나는 ⭐자발적으로 앉아서 블로그에 글을 쓰는 사람⭐ 이 되길 바란다.
  ### 자발적으로 앉아서 글을 쓰려면 무엇을 해야할까?
• 자발적으로 글을 쓰기 위해서는 왜 글을 쓰는지에 대한 동기가 명확해야 한다.
• 따라서 글을 써야 하겠다는 동기를 꾸준하게 만들어 내야 한다.
  ### 글을 쓸 동기를 꾸준히 만들어 내려면 어떻게 해야할까?
• 새로운 경험을 많이 해야한다.
• 새로운 사람을 만나든, 새로운 경험을 하든, 현재 나의 생활에서는 겪지 못했던 "무언가" 를 통해 다른 사람들에게 공유하고 싶은 인사이트가 생기는 것 같다.
  ### 그렇다면 글또에서 할 수 있는 새로운 경험이 무엇일까?
• 같은 직군 사람들과 커피챗 하기
  • 커피챗은 한달에... 2번...이상을 목표로 하겠다 (이상 내향형 인간의 당차고 멋진 포부)
• 벽또 참여하기
  • 벽또는 한달에 1번...? 클라이밍을 취미로 삼고 싶은데 팔힘이 없어서 너무 힘이 들어서 엄두가 안나긴 한다
• 관악또 참여하기
  • 관악또는... 그래도 같은 지역이고 가까우니까 한달에 2번 이상....나가보겠다
• 단순한 지식 정리가 아닌, 나의 경험을 담은 트러블 슈팅 또는 기술 관련 글 작성하기
  • 지금 프로젝트 진행 상 뭔가 새로운 기능을 많이 개발할 일이 없을 것 같긴 하지만, 기존 프로젝트 코드를 리팩토링한다거나 하는 경험 속에서 인사이트를 줄 만한 글을 작성할 수 있지 않을까 생각한다.
• 같은 조 분들의 글 출퇴근 시간에 읽기
  • 글또에는 워낙 사람이 많다보니 관심가는 키워드가 있는 글만 다 읽더라도 많은 글이 있을 거라 예상된다. 일단은 같은 조에 배정된 분들이 작성해주시는 글부터 출퇴근길에 읽어보려고 한다.

1. 글또 활동이 끝난 후에도 이어지는 인연 만들기

나는 어떤 활동을 하든, 활동이 끝나더라도 꾸준히 이어질 인연을 1명이라도 만드는 것을 목표로 한다. 그만큼 나는 새로운 경험을 통해 소중한 인연을 만드는 것을 중요하고 가치 있게 생각한다. 어떤 활동에서 만났느냐에 따라 사람들의 특징도 제각각이며, 나에게 미치는 영향들도 다양하므로, 많은 사람을 만나고 인연을 이어가는 것은 참 의미 있는 일 같다.

글또는 개발자들이 “글쓰기” 에 관심이 많은 개발자들이 같은 목표를 나누고 공유하기 위해 모인 커뮤니티이다. 글쓰기에 관심이 많은 만큼 자신의 생각을 머릿속로도, 글로서도 정리할 줄 아는 사람들이 많다는 생각이 든다. 나보다 글 잘 쓰는 사람들이 정말 많은 것 같아서, 고수분들로부터 글을 짜임새 있게 작성하는 꿀팁들도 얻어가고 싶다.

새로운 사람 만나는 것이 조금은 낯설고 힘든 내향형 인간이지만... 최대한 많은 커피챗을 하도록 노력해보며 커리어와 관련된 이야기들을 많이 나눠보고 싶다. 커피챗을 통해 어떤 이야기를 할지, 내가 어떤 도움을 줄 수 있을지는 아직 잘 모르겠지만, 우선은 편한 마음으로 시도해봐야겠다.

2. 읽었을 때 재미있다고 느끼는 글을 써보기

막연한 목표일 수 있고, 주관적일 수 있다. 그렇지만 대다수 사람들이 읽을 때 재미있다는 느낌을 받는 글을 쓰고 싶다. 지금까지 내가 읽으면서 재미있다고 느꼈던 글들의 특징을 정리해보자면, 아래와 같다

1. 제목이 재치있음
2. 중간중간 웃긴 밈이나 짤들이 존재함
3. 기승전결이 존재함
4. 소제목을 달아 전개함으로써 짧은 호흡으로 글을 읽을 수 있음

나 또한 이러한 특징을 잡아 글을 작성해보려고 한다. 이렇게 작성하면 조금은 지루할 수 있는 기술적인 글도, 소소한 즐거움과 인사이트를 줄 수 있을 거라 기대한다.

또한 “재미” 만에 목매달면서, 글을 재미있게 꾸미는 것에 초점을 두지 않도록 주의해야겠다. 정리하자면 나의 목표는 알맹이 있는 글을 쓰되, 잔잔한 미소가 지어질 수 있는 글을 쓰는 것이다 (?) 적어보니 굉장히 어려운 목표인 듯하다.

아자아자 화이팅 ]]> https://velog.io/@eunz_juu/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0 https://velog.io/@eunz_juu/%ED%85%8C%EC%8A%A4%ED%8A%B8-%EC%BD%94%EB%93%9C-%EC%9E%91%EC%84%B1%ED%95%98%EA%B8%B0 Sat, 31 Dec 2022 06:31:00 GMT

좋은 단위 테스트란?

1. 두가지 동작을 한번에 검증하는 테스트는 X

2. 1스트라이크로 판별한다() 라는 테스트 코드가 여러 개 발생하고, 중복된 코드가 발생

@ParameterizedTest @ValueSource

위의 어노테이션을 사용하면 한 테스트 메소드로 여러 케이스를 테스트할 수 있음

3. 테스트코드에서 if문을 쓰지마라 제어할 수 없는 부분을 제거해라 ex) LocalDateTime 같은 경우

4. 단일작업을 하는데 2개 메소드 호출은 잘못된 API 설계이다

• 테스트코드를 작성해보면서 설계의 부족한 점을 파악할 수 있음

5. 

-> 리플렉션으로 PRIVATE 인 애를 외부로 꺼내서 테스트를 하게 되는 것임 -> 너무 하고 싶으면 PRIVATE 이었던 부분을 클래스 분리해서 해라

6. 랜덤함수를 사용하면 언제는 테스트 코드가 성공하고, 언제는 실패할 수 있음

7.

• 태스트 코드 파악하려고 @BeforeEach 까지 갓다와야 함

• 좋은단위테스트는 그 테스트 하나만으로도 무슨 테스트인지 알아야 함

• 데이터베이스를 세팅한다거나 개발환경에 대한 세팅을 할 때 비포이치를 사용하는 게 좋음 (데이터 세팅이 아니라)

]]> https://velog.io/@eunz_juu/%EC%9C%A0%EC%8A%A4%EC%BD%9822 https://velog.io/@eunz_juu/%EC%9C%A0%EC%8A%A4%EC%BD%9822 Sat, 31 Dec 2022 06:00:42 GMT 객체지향 : 변경을 캡슐화한 객체들이 메시지를 통해 협력하는 프로그래밍

1. 메시지

• 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
• 수신자는 메시지를 처리할 책임을 다하기 위해, 메시지를 처리할 방법인 메소드를 선택한다

협력

• 무엇인가를 요청
• 메시지 전송이 유일한 커뮤니케이션 수단

책임

• 협력에서 수행하는 행동 ex) product 는 재고를 감소시키는 책임을 함

메시지 condition.isSatisfiedBy(screening); 수신자 오퍼레이션명 인자

• GRASP
• 책임할당*을 위한 소프트웨어 패턴

책임을 수행하는데 필요한 정보를 갖고 잇는 객체에게 책임을 지게 한다 -> iNFORMATION EXPERT -> 높은 응집도, 낮은 결합도 -> 유지 보수 쉬움

응집도 : 변경 발생 시 모듈 내부에서 발생하는 변경의 정도

• 높은 응집도 유지해라
• 복잡성 관리할 수 있는 수준으로 유지해라

• 결합도

  • 다른 모듈에 대해 얼마나 많은 지식을 가졌는지 나타내는 척도

• 낮은 결합도를 유지해라

• 의존성 낮추고, 변화의 영향을 줄이고, 재사용성을 증가시킨다

** 오퍼레이션명

• 협력과 관련된 의도만을 포함하도록 메시지 형성
• 이름은 송신자 입장에서 정해야 함
• 내부에서 어떤 일을 하는지 알도록 정하면 안됨.

외부에서 객체에게 명령하듯이 메시지를 전송해야 한다

메시지 정리

• 직접적인 데이터 공유 X, 메시지로 객체의 자율성 보장
• 메시지 만들 때, 협력/책임/역할을 고려

2. 캡슐화

• 변경될 수 잇는 어떤 것이라도 감추는 것!!!!
• 내부 구현 변경으로, 외부 객체가 영향받으면 캡슐화를 위반한 것
• 변화와 불안정성이 다른 요소에 나쁜 영향 미치지않도록 방지

1. 데이터 캡슐화 => 데이터 은닉도 캡슐화의 일부긴 한데 이게 전부는 아님

• private 변수
• public 메소드로 변수 값 변경

2. 메소드 캡슐화

3. 객체 캡슐화 -> 컴포지션 (합성)

-> 컴파일 타임에만 고정

4. 서브타입 캡슐화 -> 다형성

• overloading
• dynamic binding (동적바인딩)

• 실행될 메소드를 런타임에 결정하는 방식

• 변하는 것이 있다면 타입 분리하고, 변화하는 것을 각 타입의 책임으로 할당하여 변화에 유연하게 대처하자!

역할 : 교체할 수 있는 책임의 집합 기프트카드 + 포인트 -> 머니라는 역할 부여

3.상속

• DRY 원칙 : 코드 안에 중복 존재해서는 안된다
• 코드 재사용이 목적이면 안되고, 타입 계층을 구현하는 게 목표여야 함
• 상속은 클래스간의 결합도를 높임

4. 추상화

• 추상적인 존재에 의존해야 결합도를 낮출 수 잇음

]]>