Edit Files
Login Register

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일