3일
8일
리소스 효율화에 대한 단상
리소스 효율화는 운영 비용을 낮추는 것을 의미하지 않는다. 단지 비용을 낮추는데 도움이 될뿐이다.
예를 들어서 땅파는 사업을 하는 회사가 있다고 해보자. 그 회사는 전통적으로 인부들의 손과 삽으로 땅을 파왔다.
사장은 사업규모가 점점 커지고 작업을 효율적으로 일하기 위해서 포크레인을 도입한다. 문제는 이 회사가 포크레인을 써본 경험이 없다는 것이다. 그래서 테스트 삼아 화단에 꽃을 심기 위해 포크레인으로 땅을 판다. 당연히 조그마한 화단은 포크레인으로는 힘들다. 그래서 작업이 늦어진다. 대책회의가 열리고 한 대로는 빠르게 못파니 여러 대를 투입해서 파기로 결정 한다. 이제 비효율적이다 못해 서로 엉켜서 더 작업이 안된다. 그러고서는 사장이 그렇게 말하는 것이다. “포크레인이 효율적이라더니 영 아닌데..” 그러고서는 다시 인부들에게 삽을 쥐어줄것이다. 그리고 아마 그 회사는 영원히 큰 토목공사는 못할것이다.
말도 안되는것 같다고? IT 세상에서는 워낙 비일비재한 일이다. 무언가 효율을 위해 도입하면서, 정작 자신들이 해오던 관습과 생각과 레거시를 버리질 못한다. 그 결과 더 큰 비효율을 가져온다. 큰 회사일수록 더더욱 그렇다. 포크레인을 왜 써야 하는지 모르고 알고 싶지도 않아 한다. 그져 포크레인이 문제라며, 저 커다란 덩치와 먹는 기름을 보라며 욕을 할 뿐이다.
리소스 효율화로 비용을 낮추고 싶다면, 뭐 하나 도입해서 짜잔 하고 될 생각을 버리고 자신의 생각 부터 바꿔야 한다.
9일
grpc-go 관련
- gprc-go 는 Server의 구현상 HTTP 와 GRPC의 TCP Port 를 공유해서 사용 하기 어렵다.
- 만약 HTTP 와 GRPC를 같은 TCP port 로 제공 해야 한다면 cmax 같은것을 써야 한다.
- 사실 HTTP와 Grpc를 반드시 같은 포트로 제공 해야 하는 이유는 상대적으로 우선순위가 낮다.
- 보안적으로도 당연히 그러하고
- HTTP와 같이 제공하는 경우에는 어차피 grpc-web 또는 grpc-gateway 를 사용해야 해서 중간 proxy를 따로만들어야 하고,
- 필요시에는 서버는 따로 두고 envoy같은 L7 proxy에서 라우팅 해도 되기 때문이다.
- 특히 grpc 같은 경우에는 MSA 구조가 따라오므로 L7 이 필요할떄가 많기도 하다.
- 대안은,
- grpc-web: Type script client lib와 server에 grpc wapper를 제공
- grpc-gateway: grpc 호출을 json 호출로 변환. client lib 을 만들어 주진 않음.
17일
- Table Header 가 복잡할경우 이런식으로 45도 돌린 header 가 적절해 보인다.
- Webpack, rollup 등 js, css를 bundle 해주는 것은 js module을 사용 하면 그닥 적절치 않은 선택일수 있다.
- 그럴떄는 https://www.skypack.dev/ 같은 module 제공 CDN을 사용하면, bundler는 물론 npm 이나 yarn 같은 package 관리지를 사용 안해도 되며, version 문제, cache문제 등도 해결 할수 있다.
23일
29일
31일