반응형

Git 을 사용하다 보면 branch 를 만들어서 사용하게 된다. 그런데 어느 순간 보면 branch 가 여러개로 늘어나 있고 무엇을 하던 branch 인지 조차도 기억이 안나게 된다.

 

그래서 branch를 삭제를 했다. 난 분명히 branch 를 삭제를 했는데..

 

git branch --all 을 하면 삭제된 remote 브랜치가 여전히 나온다.. 내가 안지웠나???

그래서 직접 git 사이트에 들어가 봤더니 삭제한 브랜치는 나오지 않는다..

 

이때 다음과 같이 실행을 하면 된다.

 

git remote prune origin 

 

이렇게 하고 다시 git branch --all 을 하게 되면 삭제된 브랜치는 나오지 않는다.

 

참고

https://git-scm.com/docs/git-remote

 

728x90
반응형
반응형

 

우리가 살고 있는 지금 이 순간에도 알게 모르게 알고리즘의 영향을 받고 있다. 인터넷을 통해 검색을 한다든지 쇼핑몰에서 제품을 검색한다든지, 그 순간 순간 마다 우리는 모르지만 알고리즘에 의해서 우리의 행동들이 하나 둘씩 어딘가에 쌓이고 있다. 그리고 가끔 브라우저에 보이는 광고를 보고 놀라게 된다. 왜냐하면 내가 최근에 관심있어 했던 물건들의 광고들이 자주 보이기 때문이다. 

 

이처럼 알고리즘은 내가 의식하지 못한 곳에서 나에 대해서 많은 것을 배우고 있고 알아가고 있다. 

 

그중 내가 이 책에서 흥미로웠던 부분에 대해서 이야기 하자면 바로 넷플릭스에 대한 내용이었다. 

 

넷플릭스가 배달을 통해서 서비스 할 때에는 사람들의 성향을 파악하는 데에 제품에 대한 평점을 중요한 정보로 취급을 했다. 하지만 여기에는 몇가지 한계가 있었다. 사람들이 영화를 보고 싶은 그 순간 부터 영화가 배달되는 그 시점까지는 딜레이가 존재할수 밖에 없다. 영화가 배달되기까지 시간이 걸리기 때문이다. 그러면 그 영화에 대한 평점이 영향을 받을 수 도 있다. 또 평점의 대상이 모든것을 퉁쳐서 하나로 하면 간단하지만 영상, 음향, 스토리 등으로 세분화 해서 평점을 받기는 쉽지가 않다. 그게 바로 기존의 한계 였다. 


지금의 넷플릭스에서는 영화를 추천을 해주지만 그 기준에는 평점은 존재하지 않는다. 사용자들이 시청한 시간, 끝까지 봤는지 여부, 중간에 멈춘 시간, 앞으로 돌리거나 뒤로 돌리는 행위등 모든 것들이 추천의 기반이 된다. 그만큼 지금은 영화를 보는 사용자에 대해서 많은 정보를 얻을 수 있고 그것을 기반으로 한 추천들이 매우 효과적이다는 것이다. 

유효 계산 가능성

책에 자주 언급된 단어인데 내가 이해한 바로는 이렇다. 
데이터들을 모이게 되면 이 데이터를 가지고 계산을 할 수 있게 된다. 숫자를 모아 놓지는 않았지만 계산이 가능한 형태가 된다. 그리고 여러 분야, 상황에 대해서 데이터가 쌓이게 되면 계산을 할수 있는 범위도 확장이 되고 예측이 가능해진다.  그리고 그것을 하고 있는게 바로 알고리즘이다.

 

이렇게 내가 몰랐던 부분에 대해서 설명을 해주고 있어서 읽는 동안 고개를 끄덕이는 경우가 많았다. 그런데 그만큼 아쉬웠던 점도 있었다.

 

- 책에서 예로든 몇가지 사례들이(그녀, 스타트랙, 하우스 오브 카드) 내가 보지 않았기 때문에 이해하기가 어려웠다. 

- 문장이 매끄럽지 않다는 느낌을 많이 받았다. 문장 길이가 길고 번역한 형태의 문장들이 많아서 읽고 있는데 무슨 말이지?? 라는 생각을 많이 했다. 

 

문장은 그렇다 치더라도 내용에 대해서는 내가 저 작품들을 보고 난 후에 다시 읽어본다면 이 책을 이해하는데 더 도움이 될거라 생각이 되었다. 

 

728x90
반응형
반응형

오랜만에 Google 세미나에 다녀왔다.

 

지난 4월 9일 ~ 11일 미국에서 열렸던 Next '19 에서 발표된 내용들을 국내에서 소개하는 자리였다. 

총 3개의 트랙으로 진행되었고 각각의 트랙은 "인프라 현대화 및 하이브리드 클라우드", "데이터 매니지먼트", "스마트 애널리틱스" 로 나눠져 있었다. 

 

 


 

인프라 현대화와 하이브리드 클라우드 오버뷰 및 새로운 기능 소개 - 이재근, 구글 클라우드 Field Sales Representative

현재 시스템들이 온프레미스 형태로 운영되고 있는 환경들이 많다. 그러한 환경들을 컨테이너 형태로, 그리고 Google Cloud 를 사용할수 있도록 어떻게 가이드를 하는지 보여줬다. 빅뱅 형태도 있지만 쉽지는 않고 Lift&Shift 나 Improve&Move 라는 형태도 제시를 해줬다. 다양한 상황, 또는 환경에 대해서 분석하고 검토해서 Cloud 환경으로 변화할수 있도록  마련을 하고 있다고 한다. 

그러면서 소개된 제품들이 "벨로스트라타" 와 "Anthos" 이다. 벨로스트라타는 온프레미스 환경의 어플리케이션들을 Cloud 환경으로 이전할수 있도록 도와주는 제품이다. 그리고 Anthos 는 퍼블릭과 프라이빗 클라우드 환경에서의 개발, 배포, 보안, 운영을 통합해주는 제품이다. (자세한 것은 링크를 들어가서 보는게 더 좋을것 같다. ) 

특히 Anthos는 다른 세션들에서도 자주 언급이 되었다. 온프레미스 환경, 다양한 퍼블릭 클라우드를 여러개 동시 쓰는 환경에서 Anthos 가 도움을 줄 수 있는 툴이라는 면에서 매리트가 많아 보였다. (특히 국내 시장은 더욱더 ..)

 

하이브리드 클라우드의 미래 Anthos - 정명훈, 구글 클라우드 Customer Engineer

이번 세션에도 Anthos 에 대한 내용이었다. 그럼 과연 어떻게 동작을 하는 것일까?? 세션에서 들은것만 가지고 내용을 다 이해할 수는 없지만 일단 내가 이해한 내용을 설명해 보겠다. 

GCP 영역은 퍼블릭 클라우드이다. 그리고 vShpere 부분은 이제 온프레미스쪽 영역이다. 일단 그림을 보면 GKE Connect가 각각의 영역에 존재한다. 그리고 모든 통신은 이것을 통해서만 이루어 지는것 같았다. 일종의 gateway 같은 역할을 해주는것 같다. 아마도 연결 구간이 일원화 되어있기 때문에 보안 적인 측면에서도 괜찮겠지..라는 생각을 했다. 다만 스펙은 정확히 알지 못하니 어느정도의 트래픽을 감당해 줄수 있느냐가 관건일것 같다. 그리고 들으면서 궁금했던건 stackdriver 족을 보면 온프레미스 환경쪽에서 다이렉트로 퍼블릭으로 화살표가 되어있어서 좀 의문이 들었다. 저건 그냥 저렇게 연결 해도 되는건지..(물어보지는 못했다. ㅠㅠ)

그리고 통합 빌드나 이벤트 처리에 대해서도 위와같은 구성으로 진행을 할수 있게 되어있었다. 형상관리는 Git 이 될수도 있고 다른 툴이 될수도 있다. 소스 커밋이 되면 자동으로 빌드를 하고 그리고 Slack 같은 곳에 알림 서비스 까지 제공할수 있도록 할수 있다.  (제대로 이해한건지 잘 모르겠다. ㅡㅡ;)

 

Google Kubernetes Engine과 함께하는 인프라 현대화 - 조병욱, 구글 클라우드 Customer Engineer

분명 이 세션에서 많은 것을 들은것 같은데 그때문인지 과부화가 걸린것 같다. 그래서 기억 나는 부분만 설명하겠다.

우선 이건 배포에 대해서 설명하면서 나온 그림이었다. 같은 어플리케이션을 수십대에 동일한 서버에 배포를 한다고 가정을 해보자. 당연히 같은 어플리케이션이고 서버도 숫자만 많을뿐 동일한 설정이니 잘 배포가 될거라 생각이 된다. 하지만 여지없이 실패하고 만다. 그러면서 나온 패턴인데 vm 자체를 다 이미지로 구워서 배포를 하는 패턴이다. os 포함한 모든것을 다 굽기 때문에 그만큼 동일한 환경을 유지할 수 있다. 

 

그리고 Knative 에 대해서 설명을 해주셨는데 잘 기억이 안난다. (ㅠㅠ 망함..)

 

GCP에서 개인화된 쇼핑 경험 만들기 - 박경미, 구글 클라우드 Field Sales Representative

이 세션이 마지막 세션이었는데 그전에 다른 세션도 듣긴 했으나 기억이 나는 세션만 정리하다 보니 바로 이 세션이다. 

애널리틱스 트랙의 세션이었는데 Recommendations AI 에 대한 내용이 재미있었다. 

상품 구매시 추천 상품에 대한 내용인데 아래 사진을 보자. 

왼쪽은 기존에 가지고 있던 추천 시스템으로 테스트 한 결과이고 오른쪽은 Recommendations AI 를 학습시켜서 테스트한 결과이다. 저게 아마 블랙펜서 마스크였던것 같다. 사진을 보면 오른쪽에는 블랙펜서 장갑도 나오고 피규어들도 나오지만 왼쪽은 다른 것들이 나온다. 그래서 현재 Beta 이긴 하지만 적용을 한 업체에서는 만족을 하고 있다고 한다. 

그리고 발표자분께서 말씀하시길 유투브의 시청자들의 70%정도가 추천된 영상을 본다고 한다. 자신이 의도적으로 찾아서 본 영상이 아닌 내가 보고 있던 영상을 바탕으로 추천된 영상을 보는 비율이 70% 정도라고 하니 추천이 얼마나 중요한지 알수 있었다. 

 


오랜만에 갔던 세미나여서 인지 몸은 힘들었지만 머리는 맑아지는 느낌이 들었다. 요즘 공부하면서 약간은 지쳐가고 있었는데 다시 공부의 필요성을 느끼게 되서 나 자신에게도 다행이라고 생각되었다. 이제 갔다왔으니 다시 공부를 시작해야겠다. ^^;;;

 

728x90
반응형
반응형

최근에 Kubernetes에 어플리케이션을 올리다가 몇일간 맨붕 상태가 온 내용을 남겨두고자 한다. 

 

Kubernetes 클러스터에 my-test1 이라는 네임스페이스로 ingress, servcie, deployment 를 생성하였다. 

 

여기 까지는 문제가 없었는데 도메인을 설정하고 tls 를 설정하면서 문제가 발생했다.

 

1. test.com 이라는 도메인으로 사설 인증서 생성.

2. crt 파일과 key 파일을 이용해서 secret 생성

3. ingress 에 tls 설정에 host와 tls 를 설정.

 

위와같이 진행을 하고 접속을 해봤다. 

그런데 이상하게 브라우저에서 "주의요함" 부분을 클릭해보면 내가 만든 사설인증서의 도메인이 나오는게 아니라 Kubernetes의 Fake 인증서가 나왔다. 분명히 나는 인증서를 설정했는데..

 

이것때문에 원인을 찾느라 한참 고생했다.

 

결국 원인을 찾았는데 문제는 동일한 도메인을 사용하는 다른 ingress 들 때문이었다. 

 

내가 사용중인 네임스페이스의 ingress 를 생성하면 kube-system 에 있는 ingress-constroller 에 등록이 된다. 이때에 내가 설정한 어플리케이션 뿐만 아니라 다른 네임스페이스의 어플리케이션의 ingress 도 생성하면 동일하게 등록이 된다. 

 

이때에 중요한 점은 같은 도메인일 경우이다.

 

만약 내가 ingress 의 tls 설정을 아래와 같이 했다고 가정해보자

 

tls:
- hosts:
- test.com
secretName: my-test-secret

 

그런데 다른 어플리케이션에서 ingress 를 아래와 같이 설정을 했다.

 

tls:
- hosts:
- test.com

 

이럴 경우 아래쪽에 ingress 의 설정에 secret 이 없기때문에 Fake 인증서를 사용하게 된다. 아마도 순서에 영향을 받지 않나 싶다. 결과적으로 ingress 를 반영을 하게되면 kube-system의 ingress-controller 에 반영이 되고 결국 내부의 nginx.conf 파일에 반영이 되기 때문에 아마도 순서에 영향을 받을 것 같긴 하다. 

 

따라서 같은 도메인일 경우에는 namespace 별로 secret을 다 만들어서 같이 설정을 해두던지 아니면 하나의 ingress 에서만 secret 설정을 하고 나머지는 tls 설정을 삭제 해줘야 한다.

 

이것때문에 너무 시간도 많이 낭비했는데.. 역시 모르면 몸이 고생이다. ㅠㅠ

 

728x90
반응형
반응형

ReplicaSet 은 Replicatation Controller 의 새로운 버전이다.

 

다른것은 다 동일한데 아래와 같은 차이점이 존재 한다.

 

ReplcaSet : Set-based Selectors

Replicatation Controller : Equality-based Selectors

 

  Equality-based  Set-based
support  Service, Replication Controller Job, Deployment, ReplicaSet, Daemon Set
Operation  =, ==, != in, notin, exists
Example  enviroment=prd enviroment in (prd)
Command Line kubectl get pods -l enviroment=prd kubectl get pods -l 'enviroment in (prd)'
Manifest selector: 
  enviroment: prd
selector:
 matchExpressions: 
   - {key: enviroment, operation: In, values: [prd]}

 

추가적으로 sectors 에 matchLabels 가 존재할 경우 아래와 같은 차이점이 있다.

Manifest

selector:
  app: nginx 

selector: 
  matchLabels: 
     app: nginx
support  Services, Replication Controller ReplicaSets, Deployments, Jobs, DaemonSet|

 

참고자료

https://www.youtube.com/watch?v=Y5ADo_tjfIs&list=PLMPZQTftRCS8Pp4wiiUruly5ODScvAwcQ&index=19

728x90
반응형

+ Recent posts