반응형

Pivotal 에서 개최한 Cloud-Native Day 세미나에 다녀왔다.

 

https://connect.pivotal.io/CND_Seoul_2019.html

 

Pivotal Cloud Native Day 2019 Seoul

Pivotal combines our cloud-native platform, developer tools, and unique methodology to help the world’s largest companies transform the way they build and run their most important applications. Our technology is used by Global 2000 companies to achieve str

connect.pivotal.io

요즘 관심을 갖고 있는 주제가 Cloud, Kubernetes, Microservice 였는데 마침 Pivotal 에서 Microservice  관련 해서 세미나를 해서 아주 기쁜 마음으로 다녀왔다.

클라우드 네이티브 IT를 위한 4가지 요소와 상관관계
- DevOps, CI/CD, Container, MSA

클라우드 네이티브로 가기 위한 4가지 요소로 DevOps, CI/CD, Container, MSA 를 꼽았다. 각각의 요소들은 다음과 같은 의미를 가지고 있다.

DevOps : 작은 단위의 조직. (보통 Two Pizza team 이라고 많이들 한다.)

CI/CD : 자동화, 시각화, 프로세스의 단순화

MSA : 컴포넌트 단위의 모듈화

Container : MSA를 활용할 수 있는 infra적 요소

 

현재 모놀리스 환경의 어플리케이션들이 클라우드 네이티브로 가기 위해서는 단순히 MSA 적용한다고 해서 되는것은 아니다. 그것을 운영, 개발하는 조직부터 시작해서 모든것이 그것을 잘 활용할 수 있도록 변해가야 가능한 일이다.

 

그리고 왼쪽 사진의 표에 보면 MSA 라면 한가닥 하는 회사들이 나와있다. 그 회사들의 어플리케이션 배포 주기, 배포 준비 시간을 보면 정말 놀랄만 하다. 대부분 실시간으로 사용자에게 서비스를 하는 회사들인대에도 불구하고 일단위로 배포 횟수가 상상을 초월한다. 우리 회사에서는 부끄럽지만 상상도 할수 없는 수치이다. 그런데 그보다 더 중요한 부분이 아래 빨간색으로 써있다. 배포 횟수가 중요한게 아니라 배포가 필요할때 즉시 배포 할수 있는 환경이 중요한 것이다. 여기서 말하는 배포는 무중단 배포를 의미한다. 배포때문에 사용자가 서비스를 사용하지 못하는 그런 배포를 의미하는게 아니다. (그런거 직접 경험 하면 뿌듯할것 같다... )


마이크로서비스 어떻게 디자인할 것인가.
- Pivotal AppTX

MSA를 할때 항상 고민이 되는게 Bounded Context 이다. 대체 어디까지를 하나의 서비스로 볼것인가. 

Pivotal 에서는 다음과 같은 절차로 진행을 한다고 한다. 

1. 목표설정

2. Event Storm

Event Storming 을 통해서 필요한 Event 들을 도출한다. 이건 개발자만 하는게 아니다. 개발자, 설계자, 운영자(현업?) 등이 모여서 실제 모습을 도출해 낸다. 여기에는 프로그래밍적 요소는 없다. 그리고 이것을 통해 서비스의Bounded Context를 설정한다. 

 

3. Thin Slice

Event Storming 을 통해 도출된 내용중 하나의 서비스를 선택한다. 

 

4. Boris

Boris Diagram 을 만든다. 서비스의 흐름에서 발생하는 이벤트 들을 도식화 한것이다. 이걸 함으로써 하나의 서비스에 대한 전체적인 아키택처를 확인할 수 있다. 

(화면에서 보면 포스트잇과 종이를 이용해서 했는데 툴을 사용하지 않는 이유는 툴을 사용하면 툴로 내용을 적는 사람이 말이 많아지며 다른 사람의 참여가 낮아지기 때문이라고 한다. 그리고 종이와 포스트잇을 가지고 하는것 보다 효율적인 툴을 아직까지는 보지 못했다고 한다. Event Storming 때에도 포스트잇과 종이를 이용한다고 한다. )

 

5. Snap-E

이 단계 에서는 각 단위의 api 를 정의하고 데이터 처리 및 로직을 정의한다.

 

6. 테스트 완료 및 코드 생성

7. 재사용 가능한 패턴 정리

 

이렇게 사이클이 마무리 되면 아래와 같은 흐림이 나오게 된다. 

오늘 들은 내용들 중에서 가장 기억에 남는 세션이었다. 요즘 회사에서 개발을 하면 그냥 화면 단위로 하나씩 쪼개서 맡아서 개발한다. 저렇게 서비스에 대한 내용을 다같이 모여서 그려본다든지 해본적은 거의 없었던것 같다. 단지 말로 전달 받고 그때그때 물어가면서 개발을 했다. 그런데 생각해보면 안한거지 못할 정도의 상황은 아닌것 같다. 그리고 이렇게 포스트잇으로 그려보면서 하면 좀더 재미있고 구체적인 설계가 가능하지 않을까 생각이 들었다.


마이크로서비스 어떻게 구현할 것인가.

구현의 측면에는 다른것도 다 쉽지는 않지만 특히 Database, Transaction 부분이 어렵다고 한다. 그래서 Cache, Event Sourcing 등을 사용해서 어려운 부분들을 해결한다고 한다. 


클라우드 네이티브 플랫폼의 미래
- Kubernetes 기반의 PCF 로드맵

PCF가 지향하려는 방향이 멀티 클라우드에서 벤더에 관계 없이 서비스를 사용할수 있게 해주고 개발자는 서비스 개발에만 집중할수 있도록 만들어주는 것이다. 그걸 위해서 Istio 와 Envoy 를 사용하고 있다고 한다. 이 두개는 전에 Google Cloud 세미나에서도 자주 언급되었던 건데 내용을 좀더 자세하게 살펴봐야겠다.

또 추가적으로 빌드팩에 대해서도 설명을 했다.

보통 도커 이미지를 만들려면 사용자가 필요한 라이브러리들을 Dockerfile에 정의하고 해야 하는데 빌드팩은 그런게 필요 없었다.

개발자가 서비스를 개발해서 PKS에 cf push 를 통해서 올리면 자동으로 필요한 라이브러리들을 찾아서 이미지를 만들어준다. 그리고 도커 이미지의 특정 레이어를 rebase 해서 교체를 할수 있다. (이게 좀 신기했다.)


Pivotal Concourse 를 활용한 CI/CD pipeline automated build-up & Workflow management solution 소개

CI/CD 툴로 Jenkins가 아닌 Concourse를 소개하는 세션이었다. 

Jenkins 가 UI 를 통해서 쉽게 Build pipeline을 만들 수 있는데 오히려 그 부분이 약점이 라고 한다. Concourse  는 특정 파이프라인을 만들고 지우고 또 새로 생성하는 모든 부분들을 yaml을 파일에 정의해서 자동으로 실행을 할수 있다. 그런데 yaml 파일 작성이 쉽지는 않다고 들었던것 같다. ^^;


숨겨진 마이크로서비스

캐시, 메세지 큐에 대한 내용이 많았다. 그리고 MSA를 위한 여러가지 아키텍처에 대한 설명도 있었는데 역시 마지막 시간은 집중력이 떨어졌다. ^^;; 특히 Kafka 를 로그를 위한 장치가 아닌 다른 용도로 응용해서 사용할수도 있는데 꼭 알아두라고 한다. 전에 개인 발표 때문에 Kafka 쓰다가 사리 나올뻔 했는데 이번 기회에 다시 한번 보는것도 좋을것 같다. 


 

언제나 그랬듯이 세미나를 들으면 공부 뽐뿌가 오게 된다. 일단 적어두고 차근차근 알아보자.!!!

Kafka, EvCache, Istio, Envoy

 

그리고 올해도 역시 spring one 행사가 열린다. 얼리버드는 할인을 해준다는데...정말 가고싶다. ㅠㅠ 언제쯤 한번 가볼수 있으려나...

 

728x90
반응형
반응형

10월 25일 Google Cloud Summit 2018 이 삼성역 코엑스에서 열렸다.


https://cloudplatformonline.com/2018-Summit-Korea-Home.html


페이스북으로 올라온 글을 보고 신청기간에 등록을 해서 참석하게 되었다. 



Google Cloud Summit



세미나 할때마다 자주 가는 코엑스. 처음에 돌아다닐때에는 위를 보지 않아서 오른쪽 그림이 걸려있는지 몰랐다. -_-;;. 

국내에서 처음 하는 Google Cloud Summit 이어서 인지 전에 와봤던 다른 세미나보다 현수막들이 많이 달려 있는 느낌이었다.



행사 일정이다. 파란색의 낯익은 로고를 보고 정말 의외라고 생각했다.




키노트 하는 오디토리움 내부에서 봤던 로고이다. 개인적으로 왼쪽 로고와 색깔이 맘에 들었다. 



Session

(내가 메모하는 것을 귀찮아 해서 들었던 기억력을 더듬어 가면서 적는 것이기 때문에 내용이 정확하지 않을 수 있다. 아니면 내가 잘못 이해했을 수도 있다.^^;)


빅데이터와 데이터 분석 소개



수많은 데이터를 어떻게 하면 의미있는 정보로 만들것인지, 그 만드는 과정이 굉장히 어렵다. 그런 부분을 Google 에서 쉽게 접근 할수 있도록 도와 주고 있다. 그리고 BigQuery를 통해서 수백만건의 자료들을 빠르게 필터링 하거나 원하는 정보만 가져올 수 있다. 



위와 같은 형태로 수집부터 변환, 분석까지 다양한 서비스를 손쉽게 사용할 수 있도록 제공하고 있다. 



클라우드 플랫폼 정글에서 살아남기 : 하이브리드 클라우드 구성 가이드



이 세션에서는 듣다가 느낀점이 좀 많았다. 클라우드 벤더사들도 많고 하나의 벤더만 사용하면 괜찮지만 여러개의 벤더사들을 섞어서 사용할 경우 발생하는 문제점 들이다. (회사에서) 퍼블릭 클라우드 자체를 자주 사용하지 않다보니 이러한 이슈에 대해서 고민 해본적이 없었다. 


통신 비용 : 서로 다른 클라우드 간에 트랜젝션이 발생할 경우 아웃바운드, 인바운드에 대한 비용이 발생한다. 그게 계속 되고 트래픽이 많아질수록 비용은 높아진다.

성능 :  같은 서비스라도 벤더사마다 제공하는 버전이 다르고 최적화가 다를 수 있다. 그럴 경우 결론적으로 하향 평준화 된다. 성능이 낮은 쪽으로 맞춰진다는 이야기 이다. 

보안 : 이건 어떻게 보면 당연한 이야기 이다. 내부에서 발생하는 트래픽이 아닌데.. 물론 암호화를 거치기는 하겠지만 그래도 문제가 생길 가능성이 있다. 



마이크로 서비스 아키텍처 구성하기 : Kubernetes, Istio, Spinnaker, Knative


가장 관심 있었던 세션이었는데 사진 찍는것을 깜빡했다. 마이크로 서비스에 대한 다양한 관점들, 그리고 내가 몰랐던 패턴들에 대해서 설명을 들을 수 있었다. 


죽지만 다시 살아나는 피닉스 서버 패턴. 여기에서 처음 들어봤는데 한번 찾아볼만한 내용이었다. 그리고 몰랐는데 Google Container Registry 에 이미지 올리면 취약점을 자동 스캔한다는 것을 여기에서 처음 알았다. ^^;;



클라우드 앱 디버깅과 성능 모니터링 : Stackdriver



마이크로 서비스 세션에서도 들었었지만 모든 어플리케이션이 컨테이너화 되면서 모니터링, 디버깅에 대한 내용이 강조되고 있다. 그걸 좀더 손쉽게 할수 있도록 도와주는 서비스 이다. 설명을 들으면서 느꼈는데 상당히 매력적인 툴이었다. 특히 디버거나 로깅 같은 경우는 실제 소스를 재배포 하지 않고도 Logger 를 삽입한다던가 디버깅을 해볼수 있다니. 정말 내게는 매력적이었다. 로그 찍을려고 다시 이미지 구워서 올리고 재배포 하고 했었는데. 그럴 필요가 전혀 없다는 거다. -_-;;; 정말 안되는게 없는 세상이다. 



Cloud Study Jam


참여하고 있던 Cloud Study Jam 마지막 미션과제. 발표가 있었다. 



시간표에 이름이 올라와 있는 "피넛버터" 



그래서 이렇게 저 시간에 가서 무사히(?) 팀 발표를 마쳤다. 정말 허접했지만 준비하느라 걱정이 많았었다. 만든건 왜 대체 잘 안돌아가는 건지. -_-;; 대체 외 Pod 간 연결이 안되는건지. 거의 초보인 내게 컨테이너에 뭔가를 해본다는 것 자체가 시간이 많이 걸리는 일이었다. 그래도 그 덕분에 이것 저것 사용을 해보고 해서 많은 공부가 되었다. 

나중에 동영상으로 녹화한거 다시 들어봤는데 민망해서 영상을 못보고 소리만 들었다. -_-;;; 다음에는 좀더 연습을 해야겠다. 


드디어 4개 다 모았다.~^^


기념품들 



이것 말고도 파트어 업체에서 받은 것들도 있지만 그건 제외 했다. 



Action Item


세미나에서 들으면서 몇가지 써봐야 겠다고 생각한 것들을 요약해 본다. 


- Stackdrvier 사용해보기 (디버거, 프로파일러, 로깅등)

- SRE(Site Reliability Engineering) 에 대해서 좀 찾아보자

- BigQuery 한번 써보자.

728x90
반응형
반응형

사진 백업 때문에 한참 고민을 많이 했다. 어떻게 관리를 해야 가장 편할까. 

먼저 사진을 찍는 기기를 생각했다. 핸드폰은 2개 (내꺼, 와이프꺼) 그리고 미러리스 카메라. 이렇게 총 3개의 기기를 통해서 사진을 찍는다. 

그래서 사진을 백업을 할때 하드디스크에 미러리스 폴더 하나, 내꺼 핸드폰용 폴더, 와이프꺼 폴더 이렇게 각각 만들어서 사진을 나눠서 보관했다. 그렇다 보니 미러리스는 그렇다 치더라도 핸드폰에서 옮길때 컴퓨터에 연결하는게 좀 귀찮았다. 그리고 결정적으로 가장 큰 문제는 와이프와 내가 공유한 파일들이 중복해서 올라가는 거였다. 그래서 한곳에 보관을 하면 정말 좋을것 같다는 생각을 많이 했다. 

처음에는 구글 클라우드를 생각했다. 1년에 1TB 사용하는데 10만원 조금 안되는 가격이었다. 한참을 고민을 했다. 이걸 쓸까 말까. 그렇게 고민을 하던 차에 오피스365 Home 버전을 1년 구독하면 1TB OneDrive용량을 준다는 것을 알게 되었다. 그래서 구글클라우드와 OneDrive두개 사이에 고민을 하다가 가격면에서 더 저렴한 OneDrive를 쓰기로 했다. 오피스365 home을 5만원 초반으로 구매를 했으니 구글 클라우드에 비해서 반값정도 된다. 거기에다 오피스도 쓰니깐 일석 이조이다. 인터넷 찾아보면 그래도 평은 드롭박스 > 구글클라우드 > 원드라이브..등등 순으로 나오긴 하던데 일단 결정은 OneDrive로 했다. 



인터넷 찾아보면 이렇게 패키지 상품으로 보내주는게 아니라 KEY 만 보내주는 경우도 있는데 난 이렇게 패키지 상품으로 구매를 했다. 그리고 또 내가 고려했던게 PC/Mac 및 태블릿 5대 공유라는 점이었다. 그래서 내가 사용을 하면서 사용자를 추가를 하면 다른 PC 에서도 동일하게 사용을 할수가 있다. 전주 집에 있는 PC 에 설치를 해도 괜찮다는 것이다. 그리고 그렇게 추가 설치할때마다 OneDrive 1TB를 준다. 완전 이득이다. ^^



패키지 포장과 내용물은 지난번 샀던 크롬캐스트 포장하고 거의 비슷한것 같다. 아니면 요즘은 다들 이렇게 나오는건지는 잘 모르겠다. 패캐지상품을 샀다고 실제 미디어가 들어있는것은 아니다. 저렇게 카드같이 생긴거에 제품 코드가 적혀있다. 그래서 그 코드가지고 오피스365를 설치하면된다. 





같이 들어있는 설명서에도 써있지만 office.com/setup 에 가서 로그인을 하면 저렇게 제품키를 입력하라고 나온다. 그럼 패키지 안에 있는 제품키를 넣으면 된다. 


그러면 저렇게 나오는데 자동갱신을 할건지 안할건지 물어본다. 난 일단 자동갱신을 안했다. 갱신비용도 저렇게 119000원인데 그냥 내가 제품을 구매해서 다시 입력하면 자동갱신이 되기 때문이다. 그래서 내년쯤 해서 날짜 만료되기 전에 구매를 해서 갱신을 할 예정이다. 그리고 자동갱신을 하게되면 카드정보를 넣는것 같았기 때문에 안했다. 귀찮아서.



이렇게 하면 끝나고 다운로드해서 설치를 하면 된다. 요즘은 대부분 인터넷을 통해서 설치가 되기때문에 시디 넣고 하던 옛날보다는 훨씬 간편해졌다. 



이렇게 하고 나서 OneDrive에 가서 저장소 용량을 보니 저렇게 1TB로 변경되어있다. 이제 일단 기존에 있던 사진 자료들을 잘 정리해서 올려놓고 핸드폰에 있는 사진들을 어떤 방법으로 옮기고 백업을 할지 고민을 해봐야겠다. 


728x90
반응형

+ Recent posts