Spring One Tour Seoul 2018 by Pivotal

PCF (Pivotal Cloud Foundry)

• Pivotal 에서 서비스 하고 있는 클라우드 서비스
• https://pivotal.io/platform
• https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C_%ED%8C%8C%EC%9A%B4%EB%93%9C%EB%A6%AC
  
  

1. Full Stack Reactive Kotlin! with Spring Framework 5, Spring Boot 2, & Project Reactor

연사 : Mark Heckler

• Kotlin 사용 이유
  • Kotlin 은 자바에 비해 새로운 것들을 더 빠르고 자유롭게 구현할수 있게 한다. 또한 좀 더 함축적이고 효율적이라 생각한다.
  • 현재 스프링 5 버전 이후로 Kotlin과 자바를 동등한 수준으로 개발 하고 있다.
  • 메서드가 없다. 오직 함수만 있을뿐 .. 함수 키워드는 fun 그래서 Kotlin은 fun 하다!

• 리액티브 프로그래밍이란 ?
  • non-blocking, event-driven 어플리케이션 구현에 용이함
  • 비동기 프로그래밍을 구현할때 가장 어려운 점은 콜백헬이다. 그런점에서 리액티브 프로그래밍은 좀더 읽기 쉬운 readable 프로그래밍을 가능하게 한다.
  • 리액티브 프로그래밍은 적은 수의 스레드를 사용하여 더 많은일을 적은 자원으로 구현할 수 있게 한다.
    
    

• Reactive Streams : 4 interfaces
  • Publisher<T>
  • Subscriber<T>
  • Subscription
  • Processor<T,R>
    
    

• Reactive Streams initiative
  • 레드햇, 피보탈 등이 기본 스펙을 합의함
    
    
• Project Reactor
  • 컨셉 : 기존 스프링, 자바8 이상의 기술과 경험을 그대로 녹여 사용할 수 있도록 구현하고있다. (새로운 지식에 대한 거부감이 없도록)
  • Reactor에서도 Java8 과 마찬가지로 스트림의 연결에서 map, flatMap등은 Lazy 하게 동작하므로 Terminal Operator (Java8의 경우 collect 등) 가 필요함 (e.g. subscriber)
    
    
• IT Cloud by Netflix 추천!!!!!
  • 개발자들의 눈물과 웃음이 녹아있는 드라마라고함.
    
    
• Coffee service with Kotlin, Reactive and Netty
  • 예제코드 : https://github.com/mkheck/FSR

2. Cloud-Native Spring

연사 : Josh Long

•  “클라우드 네이티브 자바” 서적에서 포함하지 못한 몇가지 예제를 빠르게 보기

• Spring Boot 2.1 부터 Ascii art 를 gif 이미지로 사용할 수 있음
  • 대신 스타터 타임에 30초 이상 더 걸림 .. ㅋㅋㅋㅋ

• RedisRateLimiter를 사용하여 RateLimit 을 사용할 수 있음
  • 동시접속제한 가능
  • 일종의 쓰로틀링 기법
    
    
• 핵심 키워드 Flux & Mono 
  
  • http://tech.kakao.com/2018/05/29/reactor-programming/
    
    
• HTTP 에서만 Reactive 를 사용할 수 있는것이 아니다.
  
  • SaleForce.com 클라우드 CRM 에서 GRPC 컴파일러에서 리액티브를 사용
  • Facebook.com rsocket 프로토콜 Java 클라이언트에서 리액티브를 사용
  • SpringBoot 2.2 에서 별도 add-on없이 rsocket을 native로 지원할 예정
    
    
• 자바 챔피언 Josh Long 과 인증샷!

3. Spring Cloud Gateway

연사 : Younjin Jeong

• 해당 주제는 Spencer Gibb의 Introducing Spring Cloud Gateway 를 한국어로 재발표

• What is an API Gateway ?
  • 현대적 마이크로서비스 어플리케이션은 L7만으론 부족한 기능들이 존재함
  • 특징들 : Routing, Canary-ing, Security, Monolith Strangling, Monitoring, Resiliency
    
    
• Side-car pattern, Proxy pattern 을 합친것을 Mesh pattern
  • 애플리케이션이 존재하는 모든 서버안에 Proxy 가 존재
  • inbound, outbound 모두 proxy를 사용
  • 몇가지 오픈소스 제품들이 나와있음

• 넷플릭스 OSS Zuul
  • 넷플릭스 전체 트래픽을 받고 있음.
  • 뛰어난 성능, 오픈소스
  • 최근 Zuul2 가 발표됨
  • Zuul1은 Servlet 기반의 blocking IO를 사용했음
  • Zuul2는 비동기적 방식 non-blocking IO를 지원함
  • 단점은 Zuul1 과 Zuul2 간의 하위 호환성이 없음 (완전히 새로 개발됨)
  • 그리고 넷플릭스는 자사 OSS 에 대해 적극적으로 maintain 하지 않는다. (물론 자사에서 서비스 중인 제품은 예외)
    
    

• Spring Cloud Gateway
  • 현재 버전에선 Zuul1,2 는 사용하지 않음.
  • 예전 버전에선 Zuul1을 내장하였으나, Zuul 자체가 넷플릭스 비즈니스에 특화되어 개발되어있기때문에 내부적으로 추상화하기 힘들다는 단점이 있었음. (코드더럽..)
  • Netflix Ribbon 을 같이 사용할 수 있다.
  • API Gateway (e.g. POST /login HTTP 1.1 or GET /contents HTTP 1.1 ) -> Netflix Ribbon (Zone Available Latency check) -> API Endpoint

4. Cloud Event Driven Architectures with Spring Cloud Stream 2.0

연사 : Jakub Pilimon

• Event Storming?

• • 개발을 하기 위해선비즈니스 도메인에 대해 우선 이해해야함. 이에 대한 방법을 일컫는다.
  • Card Withdrew -> Limit Assigned -> Card Repaid -> Billing Cycle Closed
  • 위에 비즈니스에서 도메인을 도출 하면 Withdraw, Assign Limit, Repay
  • Withdraw : if there is enough money
  • Assign Limit : if it wasn’t already assigned
  • 현업 과 개발자 간 공통된 언어로 통일
  • 같은 용어를 사용하더라도 각각의 정의가 다를 수 있음.

• Event Sourcing
  • 특정 객체를 저장하는것이 아니라, 변경내역에 대한 이벤트들을 저장한다.
  • 변경내역에 대해 Audit(감사) 하기 쉬워진다.
  • 특정 시점에 문제가 발생하였을경우 state를 변경하여 해당 시점으로 테스트가 가능하다.
    
    

5. Spring and Pivotal Application Service

연사 : Younjin Jeong

• 개발자들이 운영에 얼마나 많은 시간을 소비하는지 ?
  • 코드 작성,유닛테스트,기능 추가 보다 운영업무가 더 많은 시간을 소비함. (슬픈현실 ㅠㅠ)

• You build it, you run it and you support it
  • 개발을 했다면 운영과 배포까지… devops
    
    
• Full Cycle Developers
  • Netflix 가 어떻게 devops 를 실천하는지 테크블로그에 기고
  • https://medium.com/netflix-techblog/full-cycle-developers-at-netflix-a08c31f83249

• Netflix 는 “Operation”팀을 -> “Cloud Platform” 이라는 팀으로 변경
  • 클라우드환경에 맞는 도구들을 만드는데 집중
    
    
• 위로 올라갈수록 개발자 친화, 아래로 갈수록 인프라 친화

• Pivotal Cloud Foundry Family

• Pivotal Application Service (PAS) App Runtime 
  
• Chaos Engineering 최근에 각광받고 있음
  • 대표적으로 Chaos Monkey
  • 일부러 장애를 발생시켜서 서비스에 어떤 영향을 미치는지 사전에 체크할수있도록 함
  • https://github.com/Netflix/chaosmonkey
    
    
• 12 Factors Apps, Security SSO, 배포, Configuration 등을 Cloud Foundry 에서 지원
• 즉 PCF는 현대의 Spring Boot Application 에 특화된 Cloud 플랫폼

ResourceBundle 을 이용한 MessageSource 구현

message.1={0}고객님 안녕하세요. 오늘 날짜는 {1} 입니다.

import java.util.ResourceBundle;

public class MessageSourceUtils {

   private ResourceBundle bundle;

   private static MessageSourceUtils instance = new MessageSourceUtils();

   private MessageSourceUtils() {
      bundle = ResourceBundle.getBundle("messages");
   }

   public static MessageSourceUtils getInstance() {
      return instance;
   }

   public String getMessage(String key) {
      return bundle.getString(key);
   }

   public String getMessage(String key, String... replaceTexts) {
      String message = getMessage(key);
      if (replaceTexts == null) {
         return message;
      }

      for (int i = 0; i < replaceTexts.length; i++) {
         message = message.replace("{" + i + "}", replaceTexts[i]);
      }

      return message;
   }
}

사용 방법

MessageSourceUtils messageUtils = MessageSourceUtils.getInstance();
String sendMessage = messageUtils.getMessage("message.1", "이상훈",LocalDate.now().format(DateTimeFormatter
      .ofPattern("yyyy-MM-dd")));

대학교에서 전산 수업을 들은 사람이라면, IPC(Inter-process communication)의 방법으로서 메시지큐에 대해서 들어봤을 것이다. Win32 프로그래밍을 하던 사람이라면 마우스 이벤트 등이 메시지큐를 통해서 관리된다고 들어보았을 것이다.

여기서 다루려는 메시지큐는 위의 2가지는 아니다. OS레벨이 아니라, IT 시스템을 구성하는데 많이 사용하는 메시지 큐에 대한 것이다. 요즘에는 Rabbit MQ, Active MQ, zero MQ 등 메시지 큐등이 많이 있고PubNub 이라는 메시지큐 서비스도 있는데 나의 의문점은.. “왜 이런 서비스들을 사용해야 하지?” 였다. 검색하다가 좋은 글이 있어서 번역을 해보려고 한다.

원문 : Queue everything and delight everyone (2008년 7월 4일 작성)

이 글은 내가 최근 1,2년 동안에 내 머릿속에서 돌아다니던 내용을 마침내 블로그에 옮긴 것이다. 이글은 내 생각을 갑자기 머리속에서 끄집어내고 싶다는 충동의 결과물이다.

From Let the microblogs bloom – RussellBeattie.com:

(앞문장에서 단순한 쿼리와 caching 등을 통한 확장성 있는 웹시스템에 대해 설명함.) 이런 시스템이 널리 퍼지고 나면 (나와 이 점에 있어서 논쟁하고 싶은 사람은 많겠지만), 시스템의 차별점은 그 사이트가 얼마나 잘 버티는지가 아니라, 사용자 입력이 얼마나 빨리 처리되고 반영되느냐가 될 것이다. 어떤 서비스들은 거의 실시간으로 입력이 반영되는데 반해 어떤 시스템은 많은 기능 등으로 인해 속도가 느린 시스템도 있을것이다. 문제의 키포인트는 입력을 그때그때 실시간으로 웹사이트에서 보이도록 하는(publishing)것이 아니라 메시징으로 해결하는 것이다.

See also: Rearchitecting Twitter: Brought to You By the 17th Letter of the Alphabet – random($foo)

많은 최신 웹앱들이 가지고 있는 문제점은 모든 것을 한꺼번에 하나의 코드에서 처리하고 사용자에게 피드백을 주려고 한다는 거이다. 그것은 유저 인터페이스를 만듦에 있어서, 같은 UI모듈(또는 라이브러리)에서 보여지는 것은 한꺼번에 처리하는 것이 구현하기 쉽기 때문이다.

누군가가 즐겨찾기를 저장하고 싶어 한다면? 또는 메시지를 보내고 싶어 한다면? 물론 당신은 사용자가 만들어낸 콘텐츠(User Generated Content)가 시스템이 지원하는 모든 태그, 수신인, 키워드, 알림 채널에 반영되기를 원할 것이다.

하지만, 그 콘텐츠를 생성한 사용자가 웹앱이 빨리 피드백을 주기를 하염없이 기다리고 있는데도, 정말 그것을 한꺼번에 해야 할까? 브라우져에서 로딩 이미지가 돌아가는 것을 지켜보고있는 사용자에게 그 모든 작업들이 당장 처리되는 것이 중요할까?

별로 중요하지 않다. 서비스 사용자는 계속 무언가를 진행하기를 원한다. 작성한 콘텐츠가 시스템에 받아들어졌다고 확인하고, 자신이 보고있는 화면에 당장 반영되기를 원한다. 이 사람에게 자신이 작성한 메시지가 지금 당장 친구의 메시지함에 나타고 공개 타임라인에 반영되고, 태깅되거나 RSS나 Atom 피드반영 되는 것이 중요할까?

다시 말하지만, 중요하지 않다. 동시에 처리되는지 별로 신경쓰지도 – 대부분의 사용자가 별로 감사해 하지도 않는다. 그대신에 그 콘텐츠가 주위 사람들에게 퍼지면서 생길 소셜 파급효과를 생각해 보자

• 콘텐츠를 생산하고있는 사람을 행복하게 하려면, 그사람의 화면에서 피드백을 50-200 ms(milliseconds) 안에 주어야 한다.(즉, 최악의 경우에도 0.5초안에 피드백이 와야 한다는 것이다)
• 다음으로 만족시켜야 할 사람은 콘텐츠를 생산한 사람을 팔로우하고있는 사람이다. 그에게는 수만 ms 정도는 용납이 가능하다. (즉, 최악의 경우에도 10초안에 피드백이 와야 한다는 것이다)
• 마지막으로 콘텐츠 생산자와 전혀 상관없는 대중에게 보여지는 tag 페이지라던지, 키워드 페이지, 그리고 다른 공개된 페이지에 대해서 신경쓸 차례다. 이 곳에는 수십만 ms 정도 반영이 늦어져도 괜찮다 (즉, 최악의 경우에도 1~2분 안에는 적용되어야 한다는 것이다)

여기서 말하고자 하는것은 소셜 시스템 구조는 확장성이 있어야 하는 동시에, 사용자들이 즐겁게 사용할 수 있어야 한다는 것이다. 이런 시간의 딜레이(delay)에도 불구하고, 이런 시스템이 메신저나 이메일 보다 콘텐츠 생산자들이 다른이들에게 메시지를 전달하는데 효과적이다. 물론 그것은 대부분의 작업이 수초 이내에 처리된다는 전제하에 말이다.

어떻게 이런 시스템을 만들 수 있을까? Queue를 사용하는 것이다. 물론 콘텐츠를 작성하고 완료버튼을 누르자마자 사용자의 DB에 저장하는 것은 바로 처리되어야한다. 그리고 나서 그 이후의 일은 queue에 저장하고 사용자가 다음일을 할 수 있도록 해주어야 한다. 실제로는, 사용자 단에서는 단 하나의 작업만을 queue에 넣고 그 하나의 작업이 여러 작업들을 또 queue에 넣거나 분산처리가 필요한 작업들을 처리하도록 하는 것이다.

그동안 콘텐츠를 작성한 사용자는 작업이 처리된데에 만족하고 다른 일을 할 것이다. 어쩌면 그 일이 새로운 콘텐츠를 계속 빠르게 작성하는 일일 수도 있다. 시스템이 빠르게 반응하기 때문에 가능한 일이다.

웹 기반의 콘텐츠 작성 인터페이스의 진정한 목적이 바로 그것이다 – 사용자들의 입력을 빠르게 처리해서 다른 것을 또 입력하고 싶어하도록 만드는 것 말이다. 작성하는 화면 외에 정보를 시스템에서 읽어오는 부분은 분산되어있는 데이타를 가능하면 빠르게 읽어오도록 해야한다.

빠르게 정보를 읽어들이는 일은 또 다른 주제이다. queue를 사용해서 처리한 것을 빠르게 불러오려면 시스템의 부하를 가져오는 SQL join문을 통해서 불러오기 보다는, 이곳 저곳에 중복되어 저장되어있는 정보를 간단한 쿼리로 읽어는 것이 좋은 방법이다.

출처 : http://earlybird.kr/1489#comment-49121

robots.txt 를 무시하는 MS의 bingbot

어제 새벽 미국에서 사내 인트라넷에 접속하여 로그인한 기록이 발견되어 회사가 발칵 뒤집혀졌다. 안그래도 요즘 업계에 보안사고때문에 흉흉한데 임원분 계정으로 접속한게 확인되어 다들 분석을 하고있었는데 일단 접속한 IP는 40.77.167.5 였다.

구글링을 통해 검색해보니 MS의 bingbot 이라고 검색이 되어 우리 사내 인트라넷은 robots.txt가 걸려있는데 왜 크롤러가 접근했는지 궁금하여 더 확인하다보니 재밌는걸 알아냈다. 

첨부한 이미지 내용중에서 흥미로운 부분은 Respect robots.txt 라는 필드인데 이 필드의 값이 'no' 이다. 

말그대로 robots.txt 를 존중하지않는다. robots.txt를 무시하고 크롤링하면 저작권 문제나 다른 법적문제가 뒷따를수도 있을거 같은데 (이부분은 확실하지않다.) MS는 그런걸 별로 신경쓰지 않는모양이다.