Devfest Seoul 2018
10 Nov 2018
GCP를 활용하여 코딩 없이 앱 서비스 분석 인프라 구축 삽질기 : 전인아
raw data의 직접 추출과 자동화 Big Query : 데이터 분석용 웨어하우스 서비스 로그 데이터 분석을 한 곳에서 관리 firebase + big Query
google data studio (대시보드) 금액이 기하급수적으로 늘어난다.
view의 결과를 table로 만드는 과정 data prep -> data flow big Query에 query scheduling이라는 기능이 아예 들어감
airflow stackdrive?
Building Conversational Experiences with Actions on Google : Jessica Dene Earley-Cha
#AoGDevs for twitter google wanted to be user with over 500+ devices. provide some languages google assistance : help users actions on google for developers physical hurbs : devices
Actions on Google is just one another platform for develpers ‘action’ instead of developers. interaction model in dialogflow device record the dialog and send the audio to google assistance which translates the message and action google assitance translate text to speech google assistance transelate text to speech, speech to text ation or app : returns back to text
NLP : parse the natural languages -> dialogflow which tries to match that usrs say what nlp cannot handle is entity extraction but dialogflow developers
dialogflow trains with machine learning models different colors mean identify that it’s important data not naturally know that it’s important so need to make entities new entities => what kinda informations are important = variables not everything is important but wanna know about ‘protein’ actiona and parameters manages the importants verbals
webhook : back-end intent change actually lead to new thread and need some actions to develop new one could customize instead of default
action : from google assistant to the ‘application’ actiona designing conversation is hard than the visual since there are more cases customer might come over. there is a website to help how to design design voice should come first js client library
speech : what action says text : presented on screen ssml : systhesis markup language add and modify the speech
ask for informations application has to do something with users, google will ask first and go ahead
play with sample actions
마이크로 서비스 아키텍쳐에 서비스메시 끼얹기 : 김충섭
생산성에 대하여 소스가 크고 복잡해질수록 커지는 문제점 더 정교한 프로젝트 설계 / 서버리스 / 마이크로 서비스 아키텍쳐 (MSA) microservice : 기존 구조를 여러 서비스로 분리한다. 다만, 서비스들의 관계가 복잡해진다. 마이크로 서비스의 도입은 관리와 운영이 효율적이나 연관성에 따라서 확인해야 하는 부분이 많다 . 운영 배포는 여러 서비스를 따로 배포 디버깅이 어려워진다. 트랜잭션이 어렵다.
서비스메시 : 단일 시스템에서 분산 시스템으로 service call 에서 http call로 바뀐다. 다만 network에 대한 이슈가 발생한다. 분산 컴퓨팅에 대한 착오 network에 대한 신뢰 / bandwidth 등을 장담하지 못한다. 단순히 network를 통해서 서비스를 분리하면 그에 따른 작은 일들이 생긴다.
retry
ZUUL HYSTRIX RIBBON EURWKA
라이브러리가 언어에 종속되낟.
기존에 a->b를 호출하는 대신 proxy를 사용하는 방법
microservice는 모두 proxy를 두고 proxy를 통해서 통신을 한다.
linkerd / envoy / istio istio 경로 관리
kubermetes / istio control plane이 때로 설치되고, 기존의 환경은 영향을 받지 않는다.
go와 gRPC로 함께하는 MicroService : 손은주
go + gRPC + MicroService이지만 gRPC에 초첨이 맞춰져있고
gRPC : socket ~ rest socket : 네크쿼크 상태가 좋지 않고 서버가 즉시 응답할 수 없는 상태일 때 RPC CORDA DCOM RMI SOAP / REST http를 이요한 시도 xml과 json을 사용해서 통신을 사용하게 되었다.
stubby -> GPRC 테이터센터 내 마이트로 서비스들을 연결하기 위해서 사용, 사내 rpc인 stubby를 오픈 소스화
stub : 서버와 클라이언트 사이에서 교환되는 파라미터들을 언어 중립적으로 변환시켜주는 일련의 코드를 의미 polyflot programming idl : interface description language 서버와 클라이언트 사잉의 인터페이스를 정의 stub 코드를 생성하는 데 사용됨 protocol buffers : 구글이 만든 직렬화 매카니즘 idl을 토대로 sercive interface code를 생성 -> 언어에 대한 정보가 필요하다.
Unary gRPC
go를 사용한 이유 :gRPC 지원 언어중 라이브러리가 가장 많고 cloud tool을 만드는데 사용이 되었다는 점이 장점
양방향 비동기 통신이 가능하다. 번거로운 테스트 개발 생테계 curl postman Rest에 비해 개발 생테계에서 reference를 찾기가 어려웠다.
환경에 떄라 REST와 병행한다.
go;s http request multiplexer content=type base routing applicaion.grpx applicaion baoundray를 늘려서 handler 를 만들어 버리는 방법이 있다.
microserice : 느슨하게 연결된 서비스들으 ㅣ짖ㅂ하바 개발자 / 팀들이 독립적으로 개발을 진행하게 된다. 서버의 분리, mulitprocessing이 가능하고 이해와 개발이 쉽다. 뭐 네트워크나 분리 관리 비용이 좋재 containter 기술의 발전예 따라 사용이 늘어난다.
microservice와 함께 상호적을 ㅗ통신을 한다. 서버리스에서도 제대로 동작을 했던 점이 이싿. container가 대중화된 점 REST와 함꼐 사용
Flutter / Actions on Google
https://codelabs.developers.google.com/codelabs/actions-1/index.html#5 https://console.actions.google.com/u/0/