반응형

소프트웨어 아키텍처 Hard Parts 의 내용을 정리한 내용입니다.

  • BASE 분산 트랜잭션 특유의 속성
    • BA (Basic availavility)
      • 분산 트랜잭션의 모든 서비스 또는 시스템이 분산 트랜잭션에 참여할 수 있으리라고 기대하는것.
    • S (Soft state)
      • 분산 트랜잭션이 진행중이고 원자적 비지니스 요청이 미 완료된 상태.
      • 고객 프로필 정보에서 Profile 테이블에는 데이터카 커밋 됐지만 다른 연관 테이블에는 커밋되지 않은 상태.
    • E (Eventual Consistency)
      • 충분한 시간이 지나면 언젠가는 결국 분산 트랜잭션이 완료되고 모든 데이터가 서로 동기화 된다는 의미.
      • 백그라운드 동기화 패턴 (Background synchronization pattern) - 326p
        • 별도의 외부 서비스나 데이터 소스를 주기적으로 체크해서 데이터 소스를 서로 동기화 한다.
        • 장점
          • 서비스가 디커플링 된다.
          • 응답성이 좋다.
        • 단점
          • 데이터 소스가 결합돤다.
          • 구현부가 복잡해진다.
          • 경계 콘텍스트가 무너진다.
          • 비지니스 로직이 중복될 수 있다.
          • 최종 일관성을 맞추려면 시간이 걸린다.
      • 오케스트레이티드 요청 기반 패턴 (Orchestrated request-based pattern) - 329p
        • 오케스트레이터가 전체 분산 트랜잭션을 관리한다.
        • 장점
          • 서비스가 디커플링 된다.
          • 데이터를 적시에 동기화 할수 있다.
          • 원자적 비지니스 요청이 가능하다.
        • 단점
          • 응답이 느리다.
          • 에러처리가 복잡하다
          • 보상 트랜잭션이 필요하다.
      • 이벤트 기반 패턴 (Event-based pattern) 333p
        • 이벤트나 커맨드 메세지를 이벤트 형태로 비동기 발행 해서 게시하면 구독하는 다른 서비스들이 이벤트를 받아 적절히 응답하는 페턴
        • 장점
          • 서비스가 디커플링 된다.
          • 데이터를 적시에 동기화 할수 있다.
          • 응답이 빠르다
        • 단점
          • 복잡한 에러처리
728x90
반응형
반응형
  • 엔컴퓨터 디바이스로 이루어진 네트워크는 신뢰할 수 있다.
    • 네트워크 실패 가능성을 고려하지 않으면 도착하지 않는 응답을 기다리며 멈춰있을 수 있다.
  • 요청을 보내거나 요청을 처리해 돌려 받을 때 시간 지연이 없다. (제로 레이턴시)
    • 패킷 손실을 무시하면 트래픽 양이 늘어나 대역폭을 낭비하거나 패킷 손실 비율이 높아질 수 있다.
  • 네트워크 대역폭에는 제한이 없다.
    • 너무 많은 데이터를 보내거나 너무 많은 요청을 보내면 가용 네트워크 대역폭이 점점 줄어들어 언젠가는 병목이 생기고 스룻풋(throughput - 시간당 처리할수 있는 데이터 양) 도 줄어든다.
  • 전체 네트워크는 내부나 외부 공격으로부터 안전하다.
  • 네트워크상의 컴퓨팅 디바이스의 위치나 배열은 결코 바뀌지 않는다.
    • 네트워크 변경이나 디바이스 변경은 대역폭이나 지연시간에 영향을 줄 수 있다.
  • 모든 요소마다 관리자가 단 한명 씩 존재한다.
    • 여러관리자가 존재하며 서로 상충되는 보안 정책이 있을 수 있다. 
  • 통신 비용은 0이다.
    • 네트워크 구축, 운용비용은 0이 아니다.
  • 네트워크 전체가 균일하다.

출처 : 엔터프라이즈 자바 마이크로 서비스

2020.07.01 - [Enjoy Life/책을 읽자!!] - [나는 리뷰어다] 엔터프라이즈 자바 마이크로 서비스

728x90
반응형
반응형

암호학(cryptograph)

생활코딩 암호학 영상을 보고 요약한 정리 입니다. 

https://www.youtube.com/playlist?list=PLuHgQVnccGMD-9lk4xmb6EG1XK1OmwC3u

  • 암호화의 특징
    • 기밀성 (Confidentiality) : 암호화된것을 알수 없어야함.
    • 무결성 (Integrity) : 내용이 원본과 같다는걸 유지해야함.
    • 인증 (Authentication) : 권한이 있는 사람만 접근 가능해야함.
  • 암호법의 구분
    • 양방향 암호화 : 정보를 감추는 기밀성에 초점이 맞춰짐
      • 대칭키 : 암,복호화시 같은 키 사용
      • 비대칭키 : 암,복호화시 다른 키 사용
    • 단방향 암호화 : 무결성에 초점을 맞춤
  • 단반향 암호화
    • 다른말로 HASH
    • MD5, SHA-256, SHA-512등등
    • 무결성체크, 전자서명, 파일식별자, 패스워드 저장, 블록체인, 가상화패
  • 양방향 암호화
    • 대칭키 방식
      • Twofish, Serpent, AES, DES....
      • 대칭키를 사용할 경우에는 키가 노출될수 있다.
    • 비대칭키 (공개키) 방식
      • 공개키 (public key)
      • 비공개키 (private key)
      • 평문을 공개키로 암호화 (공개키로 복호화 불가능, 비공개키로만 복호화 가능)
      • 평문을 비공개키로 암호화(비공개키로 복호화 불가능, 공개키로만 복호화 가능)
      • 암호화 절처
        • A는 공개키와 비공개키를 생성후 공개키를 노출 시킨다.
        • B는 A가 노출시킨 공개키로 암호문을 만들어 A에게 전달한다.
        • A는 B에게 전달받은 암호문을 자신이 만든 비공개키로 복호화 한다.
      • 전자서명
        • A는 공개키와 비공개키를 생성후 공개키를 노출 시킨다.
        • A는 문서 뒤에 A의 비공개키로 암호화한 text를 추가한다. (이게 전자서명이다)
        • 그걸 B 에게 전달한다
728x90
반응형
반응형

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
반응형
반응형

오랜만에 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
반응형
반응형

회사 건물에서 진행되었던 Agile Korea Conference 2018 에 다녀왔다.

신입사원 때부터 들어왔던 Agile 이지만 아직도 어색하고 제대로 하고 있는지 의문이 들 때가 많아서 이번 컨퍼런스에서 해답을 얻을 수 있을까라는 기대감이 있었다. 

( 주관적으로 생각해서 받아 적은 메모를 바탕으로 작성한 후기 입니다. 잘못된 내용, 잘못 이해한 내용이 있을 수 있습니다. ^^)

        

"Journey to Being Agile"

이번 conference 의 슬로건이다. 대체 Being Agile 이 뭐지??? 부디 컨퍼런스가 끝날때 쯤에는 그 의미를 알수 있기를 바란다.


Lean Coffee

키노트가 시작 되기 전에 Lean Coffee 라는 세션이 있었다. 상세 일정에 나와있길래 뭔지 몰라서 가기전에 한번 찾아봤었다.

http://agilecoffee.com/leancoffee/

Lean Coffee 는 자유로운 토론이라고 생각하면 된다. 토론 주제는 미리 정해지거나 하지 않는다. 진행 절차는 다음과 같다.

1. 이야기 하고 싶은 주제를 칸반보드에 포스트잇으로 붙인다.

2. 주제에 대해서 투표를 한다. 투표 결과에 따라서 우선순위를 정한다.

3. 우선순위가 높은 주제에 대해서 토론을 시작한다.

4. 정해진 시간(5분, 10분?)이 지나면 현재 이야기 하고 있는 주제에 대해서 더 진행할지 아니면 그만하고 다른 주제에 대해서 이야기 할지 투표를 한다. 

이런 형태로 진행되는게 Lean Coffee 이다. 한 사람에 의해서 진행되는 토론이 아니라 주제를 만든 사람에게 진행을 위임 함으로써 토론이 좀더 활발하고 적극적으로 이루어질수 있어서 더 몰입할수 있는것 같다. 실제 세션에 참여를 해보니 쌩판 모르는 사람들과 앉아서 이야기를 해도 어색하지 않고 모든 대화가 자연스럽게 흘러갔다. 처음에는 이런 오픈된 토론을 사람들이 많이 참여할까라는 생각을 했었는데 반응도 좋았고 분위기도 매우 좋았다.


키노트

"Mindset & Culture : At the Heart of a Winning Agile Transformation" : Ahmed Sidky

키노트는 Ahmed Sidky 라는 분이 진행을 했다. 라이엇게임즈에 Director(?) 로 있는 분이며 Agile 진영에서 유명한 분인것 같다. 난 처음 봤지만. 

키노트에서 내가 이해했던 내용은 이렇다.

현재 권력의 중심이 고객으로 이동을 하고 있다.  그리고 그것은 당연하고 모든 것들은 고객이 중심이 되어야 한다. 그리고 그 고객의 요구사항들은 결국 기업을 움직이게 하고 있다.

본인이 다니고 있는 라이엇 게임즈도 나보다는 팀, 팀보다는 회사, 회사보다는 게임유저(Player) 가 항상 우선순위가 높다라고 이야기 한다. (흠.. 그런데 롤에 핵도 많이 쓰던데.. 그건 어떻게 안하나...?? ^^;)

그리고 이제는 Output 보다는 Outcome 에 초점을 맞춰야 하는 시대이다. Output? Outcome ? 차이점이 뭘까? Output은 일, 결과, 또는 제품이라면 Outcome 은 가치에 대한 의미이다. 

예를 들어 설명하자면 이렇다. 화석연료 사용을 변화시키고 싶다 라는 목표가 있다. 여기에서 Output은 그냥 전기 자동차를 생산하는것에 한정된다. 하지만 사람들이 비싸더라도 전기 자동차를 구매하도록 변화를 유도하는것이 Outcome 에 해당한다. 결국 행동의 변화를 시키는게 Outcome인 것이다.. (좀 어렵다. -_-;;) 

그리고 여기에서 이야기 할수 있는것이 Doing AgileBeing Agile 이다. 다음 세션이나 내용을 정리할때 계속해서 이야기 할것 같지만 이 둘의 차이점은 일에 초점을 맞출것이냐, 변화에 초점을 맞출것이냐 라는것에 있다. (내가 이해한 관점이기 때문에 틀릴수도 있다.)

이제까지 우리는 Doing Agile 을 해왔다. 그 의미는 Agile을 하기 위해서 시스템적으로 접근을 했다는 이야기 이다. Agile 을 하려면 스크럼을 해야하고 칸반보드에 task 를 뽑아내고 백로그를 뽑아내고 하는 등등. Agile 을 하기 위해 갖춰야 할 항목들을 만들고 그것을 해왔다. 그것만 하면 Agile을 하고 있다고 이야기 해왔고 그랬었지만 지금은 다르다. Being Agile 을 해야 할 때이다. 어떻게 하느냐? 계속 해서 배워야 하고 그것이 행동의 변화로 이어져야 한다. Ahmed Sidky는 Being Agile을 하기 위해서는 모든 사람이 영감을 얻을 만한 비전을 제시해야 하고 전략이나 프로세스 보다는 교육과 사람의 리더쉽이 더 중요하다고 이야기 했다. 

세션이 진행되고 있는 무대 오른편에서 세션 내용에 대해서 바로바로 그림으로 그려주시는 그래픽 퍼실리테이터 분이 있었다. 세션의 내용 하나하나를 멋지게 그림으로 표현하다니 정말 대단하다는 생각이 들었다. 


그래서 검색을 한번 해봤다.

이은현 그래픽 퍼실리테이터 

그래픽 퍼실리테이터는 Visual Image를 통해 사람들과 소통합니다. 함축적으로 표현된 이미지 하나로 소통의 물꼬를 트기도 하고, 간결하게 정리된 Visual Story로 사람들이 보지 못했던 패턴과 메세지를 전달하기도 합니다.

출처 : https://www.inpeople.co.kr/html/introduce/profileView.php?idx=8


애자일 코치의 오해와 진실 : 신원(11번가)

이번 세션에서는 Agile 코치에 대한 설명이었다. 위에 사진에서 보듯이 나도 Scrum Master 하고 Agile Coach 하고 무슨 차이인지 좀 헷갈렸다. 그런데 발표하시는 분의 주관적인 생각에 의해 정리한 부분을 보면 비슷 하지만 규모나 지식의 레벨이 약간 차이가 난다. 결국 이것도 주관적인 의견이기 때문에 객관적인 차이점은 아니다. 

결론적으로 Agile 코치의 역할은 Agile 에 대한 정의와 처한 상황에 따라서 달라진다. 그리고 발표자분이 생각하는 Agile 코치의 중요한 역할은 이상과 현실 사이에서 순간순간 선택을 해야 할 상황이 다가왔을때 접점을 찾는데 도움을 주는 역할이라고 이야기 해주셨다.


삼성 SDS 지속적인 개선을 위한 10년의 노력 : 신황규(삼성SDS)

진행되었던 세션중에 가장 기대한 세션이었다. 회사 이야기이기도 하고 나도 약간은 겪어본 이야기이기도 해서 어떤 내용을 말씀해주시나 기대가 컸다. 

회사 내에서 Agile 을 교육하고 확산하는 노력을 많이 했다는 것은 어느정도 알고 있다. 나도 교육을 받아왔고 프로젝트에서도 해보면서 잘될때도 있었고 안될때도 있었다. 아마 잘 안될때가 더 많았었던것 같다. 결과물과 시간에 대한 상당한 갭이 그런 실패를 만들지 않았나 싶었다. 

10년이 넘는 시간동안 수많은 시도와 실패가 거듭되서 지금의 현재를 만들었고 그리고 지금도 많은 시도를 하고 있다고 한다. 

Agile 기법에 대해서는 정확히 모르지만 회사에서 진행했던 적용방법은 Team-Led Transformation 이라고 한다. 하나의 팀을 적용하고 다른 팀으로 계속해서 확산해 가는 방식이다. 아마도 지금 Act 팀이 지향해가고 있는 방향하고 딱 맞는 그림이라고 생각이 된다. 

그리고 내가 생각하고 있었던 Act팀의 고민거리가 가장 잘 드러났다고 생각한 그림이다. Team-Led Transformation 에서 가장 큰 문제점(?)이 이질감이다. 기존 문화를 간직한게 새로운 팀을 만드는 것이 아니라 현재와는 완전 다른 새로운 팀을 만드는것이기 때문에 기존 팀들과는 이질감이 생긴다. 현재 다른곳에서 Act 팀을 바라보는 시선이 딱 그렇다. 같이 일을 해보지는 않았지만 일단 외향 부터가 다르니 뭔가 다른곳인가 보다라는 생각부터 하게 된다. 점심때 잠깐 시간이 나서 Act 팀이 있는 사무실에 가봤는데 기존 우리 회사의 분위기와는 전혀 다른 분위기 였다. 우리 회사가 맞나 싶을 정도로.? 

그래서 현재 이런 차이들을 어떻게 보완해 나가면서 좀더 발전된 방향으로 나갈까가 고민이라고 하셨다. (큰 고민이실듯 하다. )

아마도 쉽지 않을거라는 생각이 든다. 저 사진에 있는 빨간색 삼각형은 현재 10년이 넘는 시간을 거쳐 만들어졌다. 아마도 시간이 지날 수록 완성도 있게 만들어질것이다. 하지만 그러면 그럴수록 바깥쪽과는 차이는 심하게 날것이다. 과연 이 갭을 어떻게 채워나갈지... 다름이 아니라 나아가야할 방향이며 변화를 받아들여야 하고 발전해 나가야 한다는 것을 인식시키기 위해서 또 얼마나 시간이 걸릴지. 좀 .. 오래걸릴것 같아서 안타까운 마음이 들었다.


Doing Agile 을 넘어 Being Agile 로 Agile Transformation : 이현찬(삼성SDS)

이번 세션은 Doing Agile 과 Being Agile 에 대한 이론을 정리할수 있는 세션이었다. 

기존 Agile 도입에 대한 문제점이다. Agile 을 적용하기 위해서 스터디를 하고 교육을 한다. 또는 컨설팅을 받고 고칭을 받고 적용을 한다. 그걸 계속해서 반복을 하지만 결국은 실패로 돌아온다. 왜 그럴까??

결론적으로 Agile 을 도입하는게 목적이 되었기 때문이다. 사진에서 처럼 How(Waht) 에 집중을 했기 때문이다. Agile 을 도입하면 모든 문제가 해결될것 같아서 도입을 한다. 그러면서 어떻게 해야 Agile을 하는것인가에 집중을 하게된다. 그리고 나중에서는 Agile 을 했는데 왜 결과가 이모양이냐 라고 끝맺음을 맺게된다. 이게 바로 기존에 해왔던 Doing Agile 이다.

그렇다고 해서 Doing Agile 이 무조건적으로 나쁜것만은 아니다. 단기 성과가 필요하거나 성공 사례등을 만들어야 하거나 또는 특정 상황에 따라서는 필요한 수도 있다. 

앞에서도 계속 말했지만 Doing 과 Being 에 차이점은 위와 같다. 

Being Agile 로 가기 위해서는 지속적으로 의문을 제기하고 마인드의 전환이 필요하다. 가치에 의미를 두고 교육이나 배움을 통해서 자기 스스로를 성장시켜 나가야 한다. 그리고 개인이 성장을 통해서 행복함을 느껴야 한다는 것도 중요한 포인트 이다.


마무리

내가 이 컨퍼런스에 참석하면서 얻고자 하는것은 딱 하나였다. "나는 회사에서 Agile을 잘 적용하고 있나?" 라는 의문을 풀기 위해서였다. 그래서 절차를 찾아보기도 하고 프로세스를 검색해보기도 했다. 그런데 내 물음에 답해준 딱 한가지 화면이 생각이 난다. 

신황규 선배님이 발표하신 자료에 있던 화면이다. 

"오늘 지금 잘한게 중요한것이 아니라 다음에 나아지지 않았다면 더이상 Agile 이 아니다"

Being Agile 에서 말하는 가치에 초점을 두고 배우고 성장하고. 이 모든것이 결론적으로는 좀더 나아지기 위한 밑걸음이다. 무엇인가 좀더 발전된 방향으로 나아가기 위해 하는 행위, 또는 노력 하나하나가 바로 Agile 이다. 

그래서 우리는 하루하루 오늘 보다는 내일 더 나아지기 위해 노력을 해야한다. 그러면 내가 변화하게 될것이고 그 변화는 다른 주위의 것들도 변화를 줄것이다. (앞으로 더 노력하자.)

개발과 관련되어있는 듯 하면서 약간은 차이가 있는 컨퍼런스였다. 그래서 좀더 내용이 어렵고 낯설게 느껴졌지만 그래도 몰랐던 의문은 풀고 가서 좋았다. 



728x90
반응형
반응형


지난번 Google Summit 에 이어 이번에는 피보탈에서 주최하는 SpringOne Tour 세미나에 참석을 했다.


https://springonetour.io/2018/seoul


우연히 Facebook 타임라인에 뜬 세미나 일정과 Agenda 를 보고 신청을 했었다. Spring 관련 세미나라서 내용에 대한 기대가 컸다. 세미나의 전체적인 주제는 Reactive 와 Cloud 관련 내용들이 많이 있었다. 회사에서 많이 쓰지는 않는 내용들이었지만 그래도 공부하면서 봤었던 유투브에서 봤던 내용들이어서 어느정도 이해할 수 있었다. 그리고 대부분 라이브 코딩이 포함되어 있어서 오히려 더 도움이 됐다. 


세션 요약

1. Reactive Spring with Spring Boot 2.0 - Mark Heckler


화면에는 Reactive Java 라고 되어있지만 다음 페이지에 바로 Reactive Kotlin 으로 변경했다. 라이브 데모 소스도 Kotlin 으로 작성을 했지만 눈으로 따라가는데에는 어렵지 않았다. 내용은 reactive programing 에 대한 내용이었다. 기존에 application 을 유지하기 위해 많은 양의 Thread 가 필요 했다면 이제는 non-blocking 이다 event-driven 을 이용해서 그 Thread 를 좀더 줄일수 있다, 아니 일정 수준으로 계속 유지 할수 있다는 내용 이었다. 그리고 backpressure 라는 내용이 있었는데 그부분은 좀 생소했다. 처음 듣는 단어라서 좀더 찾아봐야 할것 같다. 


참고사이트

http://www.reactive-streams.org/

https://projectreactor.io/

https://github.com/mkheck/FSR


2. Cloud-Native Spring - Josh Long

두번째 세션에서는 Josh Long 의 발표가 있었다. spring 관련 내용을 찾다 보면 이분 내용의 글들이 많이 있었는데 실제로 보니 정말 유쾌한 분이었다. 유머 감각도 있고. 그리고 놀라운것은 코드 작성 속도가 정말 빠르다. 말도 빨리 하는데 코드 작성하는 속도는 말보다 빠르다. 짧은 시간내에 라이브 코딩으로 gateway도 구현하는 라이브 코딩을 보여주었다. 그리고 역시나 처음본 rsocket?? 을 이용해서 코드를 바꿔서 보여주기도 했다. 


3. Spring Cloud Gateway - Younjin Jeong


API Gateway 에 대한 내용이었다. 그중 Netflix 에서 Zuul 을 사용했는데 asynchronous  non-blocking을 지원하기 위해 Zuul 2 를 새로 만들었다고 한다. 그런데 이게 non-blocking 이다 보니 기존 버전과 하위 호환성은 없다고 한다. 완전 새로은 제품이라고 생각하면 된다. Netflix 에서 자기들이 마이크로서비스를 위해서 사용했던 기술들을 라이브러리로 해서 많이 나왔지만 이게 내부에서 사용했던 것들이라서 소스코드가 깔끔하지 않다는 의견이 있었다. 약간 기억이 정확하지는 않지만 Spring 에서는 Zuul 2 는 아직 지원을 않하고 Zuul 1 을 지원한다고 했던것 같다. (정확하지 않음)


그리고 Zuul 을 설명해주면서 Ribbon 하고 비교설명해준게 내게 도움이 많이 됐다. 전에도 이 2개를 헷갈리고 뭔차이지 라는 생각은 하고 있었는데 오늘 설명을 듣고 좀 명확해 졌다.


Zuul 은 외부 트래픽에 대해서 이 트래픽을 어떤 서비스로 보낼지를 결졍해준다. 

Ribbon 은 Zuul 에서 결정된 서비스중 어느곳으로 보낼지를 결정해준다. 


또 Netfilx 에서 자기들이 직접 개발 운영하면서 Gateway 를 설계할때 Concurrent Connection, Thread Count, Latency 를 잘 판단해서 설계를 해야 한다고 했다. 저건 Youtube 동영상을 캡쳐한 화면인데 시간이 될때 한번 봐야겠다. 




참고사이트

https://github.com/spring-cloud/spring-cloud-gateway

https://github.com/spring-cloud-samples/spring-cloud-gateway-sample

http://slides.com/spencer/spring-cloud-gateway

https://github.com/ryanjbaxter/gateway-s1p-2018



4. Cloud Event Drive Architectures with Spring Cloud Stream 2.0 - Jakub Pilimon


세션 중반까지 잘 듣다가 잠깐 졸았던게 후회되는 세션이었다. 대체 왜 졸았을까.......



먼저 개발을 하기 전에 Event Storming 에 대한 이야기 이다. Event Storming 은 실제 현업과 이야기를 하면서 그들이 사용하고 있는 시스템에 대해서 이야기를 하는것이다. 기술적인 내용 없이 어떤 기능들이 있는지 이야기를 하는 부분이다. Event Storming 을 통해서 우리는 그 대화에서 Event 들을 도출해낸다. 


또 Event Storming 을 통해서 도출된 Event 에 대해서 우리가 해야 할 부분은 이 event 가 동작해야 하는 조건들을 추가하는 것이다. 바로 Event 에 대한 트리거를 확인 하는 작업이다. 


하아.. 이 다음이 문제다. 잠깐 졸고 일어났더니 라이브 코딩이 한창이었다. 그런데 내용을 보니 event 를 저장해서 뭔가를 하는 부분이었는데 그게 바로 Event Sourcing 부분이었던것 같다. 정신을 차리고 코드를 따라가보긴 했는데 결과적으로 주된 내용은 어플리케이션에서 트랜잭션이 일어날 경우 바로 DB 에서 처리하는게 아니라 그걸 발생시킨 Event를 하나씩 저장을 해서 처리를 한다는 것이었다.


그럼 왜 이렇게 하느냐에 대한 설명이 나왔다. 이해가 가는 부분도 있고 안되는 부분도 있어서 좀더 공부를 해봐야 할것 같다. 


- 장점

  이벤트를 통해서 모델에 대한 오딧이 가능하다. (이건 좀 이해가 안갔다... )

  이벤트 기반으로 히스토리 확인이 가능하다.

  특정 이벤트 별로 확인 및 분석이 가능하다.

- 단점

  코드가 많고 복잡하다.

  기존에 만들었던 방식과 다르기 때문에 사고의 전환이 필요하다.


참고사이트

https://github.com/ddd-by-examples

https://github.com/pilloPl/credit-cards-producer

https://github.com/pilloPl/credit-cards-consumer

http://pillopl.github.io/


5. Spring, Functions, Serverless and You - Nate Schutta

이번 세션에서는 아키텍처에 대한 내용들이 주제 였다. 세미나 가면 자주 듣던 예인데 전에는 Server를 애완동물처럼 애지중지 하게 다뤘지만 이제는 Server 가 애완동물이 아닌 가축으로 생각되고 있다는 이야기 이다. 다시 말해 Server가 죽으면 교체한다는 의미이다. 

위 사진에서 보여 주듯이 위로 올라갈 수록 Complexity 가 줄어들고 운영하기 좋아지기 때문에 최대한 Serverless 로 올려야 한다는 내용이었다. (4번 세션이후로 점점 집중력이 떨어져서 잘 듣지 못했다..)


6. Spring Boot & Cloud on Pivotal application Service - Younjin Jeong

이번 세션에서는 Pivotal 에서 어떤 서비스들을 제공하고 있고 어떤 플랫폼들이 있는지에 대한 내용이 대부분을 차지 했다. 

내용중에 이부분이 좀 와닿았다. 개발자들이 운영을 하는데 얼마나 시간을 소비하고 있는가. 새로운 기능을 만드는 것보다 대부분의 시간이 기존에 만들었던 거를 수정하고 디버깅하는데에 시간이 사용된다. 이걸 무슨 단어가 있었는데 생각이 안난다. 결과적으로 저렇게 되면 개인에게도 손해고 회사에도 손해이다. 

그래서 필요한게 Full Cycle Developers 다. Netflix 에서 한 말이고 어느정도 와닿는다. 하지만 저렇게 되려면 개인만 해서는 안되고 조직 자체가 그렇게 변해야 하기 때문에 쉬운 일은 아니다. 


Full Cycle Developers at Netflix — Operate What You Build


7. Using Spinnaker to Create a Development Workflow on Kubernetes - Paul czarkowski

마지막 세션에서는 Kubernetes 에 대한 내용이 많이 나왔다. 최근에 자주 보던 내용이어서 많이 집중해서 보지는 않았는데 마지막에 나온 Spinnaker 에 대해서는 좀 찾아 봐야겠다. 


마무리


마지막에 운좋게 당첨되서 "클라우드 네이티브 자바" 책을 받아왔다. 세션 중간에 책 사서 Josh Long 한테 사인 받을까 했었는데 참길 잘했다. ^^ 

앞에서도 말했지만 세션 전체적으로 모르는 내용이 많이 있긴 했지만 중간중간 중복해서 설명되는 내용도 있었고 코드를 따라가다 보면 이해가 되는 내용도 많았다. 역시 개발자는 코드로 대화를 할수 있어야 한다는게 괜한 말이 아니었다. ^^;; 최근 GCP 공부하다 보니 Spring 쪽은 약간 소홀한 면이 있었는데 오늘 세미나를 듣고 보니 잠깐 쉬는동한 공부해야 할게 참 많아졌구나라고 느꼈다. 좀더 분발해야 할것 같고 궁금했던 부분들에 대해서는 빨리 찾아봐야겠다. 


Action Item

Backpressure 란 무엇인지 찾아보자.

rsocket 에 대해서 찾아보자. Facebook 에서 사용한다고 하는데??

Zipkin 사용해보면 좋을것 같다.

Event Sourcing 에 대해서 개념 파악해보고 소스한번 다시 보자.

Spinnaker 에 대해서 알아보자. 



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
반응형
반응형

Window 환경에서 Kafka 를 설치해보고 실행 해보려고 한다. 


1. 설치

설치는 간단하다. 아래의 URL 로 가서 다운로드 받은후 압축 풀면 설치 끝이다. 


https://kafka.apache.org/downloads


2. 실행

Kafka 는 Zookeeper 를 사용하기 때문에 먼저 zookeeper 부터 실행을 한다. 카프카 설치 디렉터리로 이동해 보면 sh 파일들이 있는데 Window 환경에서 실행하는 실행파일들은 windows 폴더 아래에 따로 모아져 있다.


zookeeper 실행

카프카설치디렉터리\bin\windows\zookeeper-server-start.bat ../../config/zookeeper.properties


kafka server 실행

카프카설치디렉터리\bin\windows\kafka-server-start.bat ../../config/server.properties


3. 토픽

- 생성


kafka-topics.bat --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic [토픽명]


- 토픽 목록 확인


kafka-topics.bat --list --zookeeper localhost:2181


4. Message

kafka-console-producer.bat --broker-list localhost:9092 --topic [토픽명]


이렇게 하면 메세지를 입력할 수 있는 프롬프트로 변경된다 


kafka-console-consumer.bat --bootstrap-server localhost:9092 --topic [토픽명] --from-beginning


위에서 입력한 메세지를 바로바로 볼수 있다. 


728x90
반응형

'Development > Tech&Seminar' 카테고리의 다른 글

SpringOne Tour 참석 후기  (0) 2018.11.08
Google Cloud Summit 2018 후기  (0) 2018.10.26
Google Cloud Hackathon 간단한 후기  (0) 2018.10.08
TCC가 뭐지???  (0) 2018.09.07
Openssl로 SSL 을 위한 인증서 발급하기 (HTTPS)  (2) 2018.08.22

+ Recent posts