Haonly's Blog

첫 글 쓰기 전에...

API 개발이야 여러 번 해 봤지만 제대로 설계를 하고 개발한 적은 거의 없다고 본다.

그저 개발하기 급하게 개발한 못난이 API 투성이.. ㅠㅠ 

그러다가 한 반년 전에 개발한 API를 봤는데 너무나도 엉망이라 ㅋㅋㅋㅋㅋ 진짜 너무나도 거지 같아서 새로 설계하고 다시 짜렸는데 반년 전의 나와 지금의 나의 다른 점은.. 크게 없으므로 제대로 공부를 좀 해보고 개발하려고 공부하려고 한다!

책은 그냥 이 전에 개발 잘하시는 책임님이 사시던거 기억해두고 따라 샀던 책이라 어디 구석탱이에 있던 게 생각나 꺼내왔다.

고럼 화이팅 하매~~~

1부. API 디자인의 기초

1장. API 디자인이란 무엇인가

API는 인터페이스로 시스템 간 통신을 위한 인터페이스로 작용한다.

스마트폰의 예시를 들어봤을때,

스마트폰 UI와 비교를 들었는데, 스마트폰 화면을 터치하여 모바일 애플리케이션과 사람 간의 상호작용하는 역할을 하는 UI가 애플리케이션이 다른 애플리케이션과 상호작용을 하기 위해 작용하는 프로그래밍 인터페이스인 API와 비교할 수 있다.

모바일 애플리케이션이 백엔드와 커뮤니케이션하기 위해 인터넷을 사용하는데 HTTP를 사용 -> 그래서 웹 API라는 것

예를 들어 소셜 네트워크에 사진과 글을 올리는 과정을 설명하는데,

소셜 네트워크 백엔드가 사진과 텍스트를 수신하면, 사진은 서버의 파일 시스템에 저장되고, 텍스트는 사진의 식별자와 함께 데이터베이스에 저장된다. 

하진을 저장하기 전에 직접 만들어 둔 얼굴 인식 알고리즘을 이용해 사진 속에 친구가 포함되어 있는지 확인할 수도 있다.

위 과정을 확장하면 애플리케이션 하나가 여러 독립된 애플리케이션을 다루는 상황도 상상해 볼 수 있다고 한다.

API를 통해 사진과 텍스트를 저장하고, sns 백엔드에서는 얼굴인식 API, 저장 API, 타임라인에 추가 API 등을 호출하여 작업이 이루어진다고 이해했다. 이런 과정이 레고와 같다고 한다.

API로 접근이 가능해 어디서든 실행 가능하니 동시에 여러 곳에서 사용 가능하며 이러한 점이 API의 성능과 확장성을 관리하는데 유리하다.  

API 디자인이 중요한 이유

API를 사용하는 consumer 입장에서 사용하기 쉬워야 하기 때문인 것이 내가 생각하는 첫 번째 이유인 듯하다.

외부 API를 사용하는 경우라면 누가 개발한 지 모른 채 사용하게 되는데 이때 사용에 어려움이 없어야 좋은 API라고 할 수 있기 때문이다. 

이러한 API를 사용하는 개발자의 경험을 Developer Experience라고 한다. 사용하기 유용하고 쉽도록 개발하는 것이 API 개발의 키라고 한다.

API는 구현을 숨긴다

API 내부가 어떻게 구현되는지 consumer는 알 필요가 없다.

음식점에서 음식을 주문하는 경우와 비교를 했는데, 우리가 음식점에 가서 음식을 주문할 때 요리가 어떻게 되는지는 알지 못하고 점원을 통해 음식 주문과 서빙을 받는다.

이 점이 API를 통해 상호작용하는 점과 비슷하다. API에게 요청한 결과가 구현되고 수행되는 것은 provider 애플리케이션에서 일어난다.

어설픈 API 디자인은 끔찍한 결과를 초래

형편없이 디자인된 제품들은 잘못 쓰이거나 제대로 쓰이지 않거나 아예 쓰이지 않는다. 사용자들에게만 위험한 것이 아니라 제품을 만든 조직에도 위험하다.

(내가 만든 API가 이런 상황.. ㅠㅠㅠ)

상황이 어찌 됐든 간에 API 디자인 결함은 이 API를 사용하는 소프트웨어가 들이는 시간과 노력과 비용을 증가시킨다,

그러므로 API를 적절하게 디자인하는 법을 학습하면 된다.

모든 API가 이해하기 쉽고 사용하기 쉽게 만들어져야 한다.

라는 것이 결론이며 내가 개발해왔던 API를 생각해보면 그때는 reasonable 하다고 생각했던 것들이 전혀 그렇지 않고 내가 놓치고 개발한 점들도 참 많다. 이제라도 다시 개발해 볼 생각을 한 것만으로도 기특하다고 해야 할까.. ㅎㅎ

Kafka consumer group 모니터링 중 "Preparing rebalance" 상태가 떠서 정확히 알아볼 겸 consumer state 에 대한 정리...

(기초는 차차 정리하고 일단 당장 궁금한 것부터!)

Rebalancing 정의

• 카프카 컨슈머 그룹을 구성하여 데이터를 처리할 때 운영상황에서 마주치는 다양한 경우의 수에 대해
• 그룹에 참여하는 컨슈머 클라이언트 구성에 변화가 생길 경우 이 변화를 반영하기 위한 과정
• 컨슈머 클라이언트를 사용하여 필요한 논리적인 그룹을 형성하고, 그 그룹 멤버들끼리 리소스(파티션)을 적절히 분배하는 프로세스

Consumer Group

• 특정 토픽에 발행된 메시지를 consumer group이라는 논리적 멤버십을 제공함으로서 각 그룹에서 목적에 맞게 읽고 처리할 수 있도록 함
• consumer group과 그 멤버 인스턴스, 토픽의 파티션과의 관계는 복잡함
• 컨슈머 인스턴스 제약
  • 카프카에서 1개 파티션은 consumer group 내의 최대 1개 인스턴스까지만 접근 가능
  • 즉, 1개 consumer group 인스턴스 수가 토픽이 가진 파티션 갯수보다 많을 수 없음
  • 다시 적자면, 파티션 수가 consumer group내에서 실제 컨슈밍을 진행하고 있는, 최대 active consumer 갯수를 제한함
  • (consumer group과 파티션 사이의 관계가 있다는 것이며 이런 맥락에 기반하여 분산 처리 및 로드 밸런싱이 이루어짐)

Kafka Rebalance Protocol

• 토픽을 컨슈밍할 논리적인 그룹을 형성하고 파티션을 재분배하는 과정
• Group management를 사용하여 카프카 클라이언트들을 논리적인 그룹에 참여시킴으로서 cooperating 하며
• Cooperating 과정에서 그룹 코디네이터(Group Coordinator)는 GroupCoordinator 인스턴스를 백그라운드 프로세스로 실행하며 consumer group을 관리하는 역할을 가진 카프카 브로커임
• Kafka Rebalancing Protocol에서 코디네이터의 역할 대신 클라이언트 단의 역할이 크게 작용하게 되며, 이에 따른 장점이 있음
  • 클라이언트 자체로 로드밸런싱 알고리즘을 수행: autonomy → 클라이언트가 로드벨런싱 자체의 디테일 작업에 집중하며 브로커의 코드가 단순화됨

1. 감사하자

• 바쁜 일정 중다시 열정 찾을 수 있는 나에게 감사하다!
• 어려운 일이더라도 yes 한 나에게 기회가 온 것에 감사하다!

2. 열정과 이유

열정 찾는 것은 어렵다. 

이 전 글에서 하고자 했던 일의 절반 정도 했다. 이 정도면 잘한 것 같다.

여전히 못한 일들은 차차 하도록 합시다 ㅇㅅㅇ

오늘 아침에 일찍 나와 카페에서 재택근무를 했다. 월요일이니 새로 시작하는 마음가짐으로 해 잘 드는 카페에 앉아서 오전 업무를 보는데 여유롭게 책도 읽고 밀린 블로그 글을 쓰거나 공부도 하고 생각 정리를 하고 싶다는 생각이 들었다.

퇴근하고 조금씩이라도 공부하고 생각 정리도 하고 주말에 여유롭게 카페에 가서 블로그 글을 써야겠다.

https://www.youtube.com/watch?v=qp0HIF3SfI4 

아직 1.5회 정도 돌려봤지만 몇 번 더 보고 완전히 머리속에 박고 싶다.

"People don't buy what you do people buy why you do"

내가 마케팅을 하거나 사업을 하는 사람은 아니지만 나 자신의 가치를 높이고 자기 계발을 하려는 사람으로서 와닿는 말이었다.

결국에 내가 하는 일들의 이유를 정확히 알고, 진심을 가진다면 아직은 모르지만 결과로 보일 수 있다는 것이다.

내가 하고 있는 것들(일, 취미, 자기 계발, 운동 등등), 모든 것들에서 나의 이유를 정리해 봐야겠다.

• 일 - 특히, 내가 지금 하고 있는 일인 이유
• 취미 - 독서, 하고 싶은 취미(그림 등등)를 하는 이유
• 자기 계발 - 스터디하고 있는 것들이 있는데 이것들을 하는 이유(간단해서 바로 생각난다. 더 잘하고 싶으니까)
• 운동 - 러닝과 클라이밍. 이것도 간단해서 바로 생각난다. 재미있고 건강하려고(근데 이건 내 성장에서 마이너의 부분인 것 같다. main과 minor 구분을 해야겠다)

가장 집중해서 정리해야 할 부분이 특히 일인 것 같다.

개발자인 이유, 그중에 데이터 엔지니어인 이유, 더 공부하고 싶은 분야와 그 이유

맨날 하는 말이 '일 하기 싫다ㅠㅠ'인데 그럼에도 일을 하고 있고, 하기 싫다면서 스터디해가며 하는 데는 이유가 있다.

(하고 싶고 더 잘하고 싶은 나와, 하기 싫은 나의 체력과 몸뚱이의 싸움이랄까...)

이렇게 영감을 주는 영상과 할 일들을 적어두면 꼭 하겠지...!

힘내라 나 자신! 열정 되찾아라 나 자신! 

카프카 토픽 파티션 갯수 설정

토픽을 새로 생성했는데 파티션을 몇개로 설정할지 고민에 빠졌다.
파티션 갯수를 늘리면 로드가 줄어들기는 하지만 늘리는 만큼 복제 지연 이슈가 있을 수 있으니 적당히 나눠야 한다.

바람직한 갯수는 아래와 같다.
#partitions = desired throughput / partition speed

예를 들어 하루에 1TB 의 throughput을 원한다고 하고 하나의 파티션 속도가 10MB/s 라면
1TB/24h = 11.5MB/s 이므로
대략 1개~2개 정도면 원하는 throughput을 만족할 수 있는 속도가 나온다.

Scala best practices에 따르면 sequence(list, map 등) 으로부터 head를 뽑을 때 `head` 보다는 `headOption` 사용을 권장

Seq.empty[Int].head
-> head of empty list exception 발생

headOption은 sequence의 head를 뽑아내는 좀 더 안전한 방법!
Seq(1, 2, 3).headOption
// res0: Option[Int] = Some(1)

Seq.empty[Int].headOption
// res1: Option[Int] = None

exception 방지를 위해서는 None이 아닌 조건을 넣으면 될듯

또 몇 주 만에 쓰게 되는 주간회고! 

이 정도면 주간회고가 아니라 맘대로 회고가 아닐지... ㅎㅎ

이번 주 총평

첫 일주일 간의 휴가 이후 회사로의 복귀라서 그랬는지 난이도가 꽤 높은 한 주였다.

일단 지난주 일요일부터 장염과 이로 인한 몸살로 아파 뒤지는 줄 알았고 휴가 기간 동안 내가 직장인이라는 사실과 회사를 다니던 사람이었던가 라는 생각이 들 정도로 휴가에 푹 빠져있다가 복귀하려니 매우 혼란스러웠다 ㅋㅋㅋ

월 - 재택 하며 죽만 먹고 으어어 하다가 끝남

화 - 회사를 갔는데 이 날이 제일 아팠던 듯. 그래도 개발 건 다 끝내고 으어어 하고 지하철 타서 땀 삐질삐질 흘리며 퇴근 한 뒤 기절.

수 - 재택하고 죽만 먹고 저녁에는 토마 이후 쉬다가 토마 멘토 전화받고 하루 끝

목 - 출근해서 고랭 스터디도 하고 개발도 와다다다다 해서 테스트 마친 뒤 갑자기 오후 반차 내고 병원 갔다가(장염이 낫지 않아서 ㅠ) 갑자기 클라이밍 하러 감(?) ㅋㅋㅋ그리고 집에 와서는 Division Council Meeting! (내가 Division Director라 빠질 수 없었던,,)

금 - 재택한 뒤 집에서 청소하며 푹 쉼!

토 - 몸이 좀 괜찮아진 듯하여 클라이밍 한 4시간? 5시간? 때림 ㅋ

아팠던 것 치고는 꽤 빡쎈 일주일이었다. 

아파서 이번주에 못했던 일:

• 투자 공부
• 알고리즘 공부

사실 어제, 오늘 좀 해보려고 했는데 일단 아직 못했다.. ㅎㅎ 

아팠다니까~ ㅎㅎ 다음 주는 저녁에 시간 좀 내서 공부해야지!!

한 주 또 열심히 살아가자구요~~~