SlideShare ist ein Scribd-Unternehmen logo
1 von 85
Downloaden Sie, um offline zu lesen
Observability,
Service Mesh
and Microservices
Taiki Ono
Software Engineer
Cookpad Inc.
Service Mesh
便利
採用目的™
https://info.cookpad.com/careers
Draft: Observability, Service Mesh and Microservices
今回のお話
• なぜマイクロサービスに挑戦しているのか
‣ 時間の都合上カット、資料に掲載
• 「service mesh とは」について背景やメ
リットなど普遍的な話
• クックパッドでの事例紹介: Envoy + 自作
control-plane
• 組織のステージは色々ありそれぞれのステージで必
要なものは変わる
• こういう事例もあるのか〜の場
• 資料にリンクをいっぱい貼ったので知らないことは
後で調べてもらえれば OK、この発表は新しいことを
楽しんでくれるとうれしい
• 卒 Rails の場 (個人的に Ruby も Rails も好きだけ
ど、 Rails の話をしないトークも歓迎とのことなの
で…!)
語り手
• Taiki Ono, Cookpad Inc.
• 開発基盤: 開発生産性上げていく
• @taiki45 at GitHub
• 大規模プロダクト開発, network proxy
• 地域研究をやっていたのでペルシア語対応人材
‣ 膝に矢を受けてしまってな…
なぜマイクロサービス?
なぜマイクロサービス?
• スケーラビリティの問題: 4人の組織
から2000人の組織へ
‣ オーナーシップの問題: 意思決定の速度
‣ Agility: 開発サイクルの速度
Q: 4人のチームでアプリを
どう作る?
• Rails で1アプリ、web/API 兼任、
1DB
• ノーマイクロサービス
• そもそも Firebase とか
• インフラ層にかかる手間はほぼ無、そ
んなことよりプロダクト開発
Q: 2000人のチームでたくさんのアプリを
どう作る?
• いくつも事業領域があったり
• 毎日5億人が使ってたり
• 毎日リリース
A: 例えば水平に組織を分割
• 事業領域や機能毎に一通りのことができる小さな
チームを複数作る
• それぞれのチームが裁量を持ってプロダクト開発
を進める、チーム同士のコミュニケーションを減
らす
• それぞれのチームは最低限の境界上の約束を作っ
て連携する
• それぞれのチームは小さく頻繁なリリースを行う
モノリシックアーキテクチャの限界
• 組織を水平に分割しても、モノリシックアーキ
テクチャでは結局デプロイの調整とかコミュニ
ケーション問題が復活してつらい
• 小さなリリースがやりづらくなる、アプリを壊
すリスクがある大胆な意思決定がしづらくなる
• オーナーシップに影響が出てきて自律的プロダ
クト開発がしにくくなる、イノベーションを阻
害する
Service Oriented Architecture へ
• ソフトウェアのアーキテクチャも変えて1
チームで1つ以上のアプリを担えるように
したらオーナーシップの問題解決しそう
• その上で、アプリ境界上の最低限の約束事
だけ決めたらチーム内で好きにできるから
コミュニケーションコストも減りそう
• Agility 復活じゃん
マイクロサービスとは
• このように組織が大きくなっても、小さな
組織のような素早いプロダクト開発をなる
べく維持するための方法がマイクロサービ
ス
• そのような方法のために設計されたアーキ
テクチャをマイクロサービスアーキテクチャ
と呼んだりすることがある (そういう文脈を
抜きにすれば SOA と言ってもいいと思う)
Pros of マイクロサービス
• 小さなチームへの責任と権限の委譲
• 頻繁なトライアンドエラー
• 高速かつ高精度な意思決定のサポート
Cons of マイクロサービス
• アプリケーションはシンプルになるが
システム全体として複雑になる
• 個々のアプリケーションの開発は楽に
なるがシステム全体の運用がめっちゃ
難しくなる
マイクロサービスと言ったら
「小さいチームで意思決定バーン、
アプリ数もそれに合わせてドーン」
• クックパッドも昔は必要なかったが、大きくなる
につれ自然とマイクロサービスへと進んでいった
• マイクロサービスと名前がつく前から同じことを
していた組織は多い
• マイクロサービスはもちろん not 銀の弾丸、デ
メリットもある
• 技術的課題をやっつけてなるべくメリットを享受
するぞ!
Service Mesh とは
技術的課題と Service Mesh
• 分散アーキテクチャの難しさ→倒してメリットを享受
するぞ!
‣ 技術的課題の変遷を簡単に紹介
• Service mesh とは
‣ 特に中核の Envoy proxy について
‣ もしかしたら Istio について聞いたことがあるかも? そこ
ら辺の話
• 将来マネージドサービスが出た時に役に立つ話かも?
Service Mesh という言葉
• ちょくちょく周りでも聞くようになっ
た気がする
• もちろん聞いたことなくて全然OK、
これから話します
全世界: 5年スパン
https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh
日本: 5年スパン
https://trends.google.com/trends/explore?date=today%205-
y&geo=JP&q=service%20mesh
一体何者なんだ…
https://trends.google.com/trends/explore?date=today%205-y&q=service%20mesh
Service Mesh、
• Kubernetes と関係ありそう
• Istio ってやつと関係ありそう
• Envoy というものと関係ありそう
マイクロサービスの技術的課題の変遷
マイクロサービス初期の課題1
• アプリケーションの動作環境の整備が
大変
• A: Puppet 等によるサーバー構築の自
動化
コンテナアーキテクチャの台頭と進化
• Docker によるコンテナ技術のパッ
ケージング
• リソーススケジューラー・オーケスト
レーションソフトウェアの成熟: k8s
• マネージドサービスの進化: GKE,
Amazon EKS/AWS Fargate
マイクロサービス初期の課題2
• サービス同士を繋げるのが大変
(service discovery の問題)
• Internal ELB, Airbnb SmartStack,
consul-template 等
サービス同士を繋げるのは難しい
• 素朴な時代: 2013年頃、掲示板サービスの情報をレシ
ピサービスへ出してたら巻き込み落ち
• サービス境界は慎重に区切っているが新しい事業の進展
とともにどうしてもサービスは増加する
‣ 障害発生時のトラブルシューティングの難しさ
‣ TV 放映時等のスパイク向けのキャパシティプランニング
の難しさ
• クックパッドではエスパーでまだなんとかなってるけど
10xの規模とかを見据えると厳しい
http://techlife.cookpad.com/entry/2017/09/06/115710
技術的課題の変遷
• 1つ1つのアプリケーションはシンプルになる
が、システム全体としての複雑性は上がる: 運
用の複雑性の増加
‣ たくさんのアプリケーションを動かすのは技術
的に解決されつつある
‣ たくさんのアプリケーションをうまく繋げるこ
とに課題がシフトしつつある
• どうやったらもっとうまく運用できるだろうか
Observability Engineering
• Twitter 社のエンジニア発の概念。Dapper
等、Google 内部での知見が発端っぽい
• 分散システムをうまく運用するためにシス
テムの繋がりの部分の挙動に注目して可視
化・監視する
• 取得すべき値や集約・ストレージの設計等
がスコープ
• システム全体はどんな姿で、どのように動いているのか
‣サービス境界でなにが起こっているか: RPS, status, リト
ライ・タイムアウト・サーキットブレーカの発動
‣あるリクエストを処理したサービスがどれで、その処理結
果がどうだったのか: 分散トレーシング
• これらを加入したての開発者でも素早く把握できること
に価値がある
• また効率的にシステム障害の解決したり、キャパシティ
プランニングするのに必要
オーナーシップ問題再び
• プロダクト開発者は基本的には自分たちのプロ
ダクト・サービスに責任を持っている: 責任の
分離
• しかしシステム全体は協調して動作させる必要
があるので組織横断的なチームが必要: SRE 等
• 横断的なチームがアプリケーションの細部を把
握しなくてもシステム全体の動作を理解できる
必要がある → 中央で管理する必要性
どこで実現するか
• それぞれアプリケーション内で実装するのは厳し
い。ではライブラリで提供する?
• Polyglot との相性が悪い、実装毎の一貫性の問題
• ライブラリのメンテナンスのためにアプリケーショ
ンのデプロイが必要: 横断的チームがやるのはし
んどい
• このような関心事をアプリケーションから分離で
きると良いのでは→ Out Of Process モデル
Service Mesh To The Rescue
Service Mesh とは
• アプリケーションに代わりネットワーク層の仕事
をする
‣ メトリクス取得/送信、リトライ等の実行、分散ト
レーシング用のログの送信、service discovery,
load balancing 等も行う
• 2つのコンポーネントで構成される
‣ data-plane: proxy として上記タスクを行う
‣ control-plane: 各 proxy の挙動を管理する
ライブラリモデル
• アプリケーショ
ンに埋め込み
• 設定値はアプリ
ケーションプロ
セスの中に
http://blog.christianposta.com/istio-workshop/slides
Service Mesh モデル
• proxy として別
プロセスに
• proxy を管理す
る control-
plane
http://blog.christianposta.com/istio-workshop/slides
Service Mesh の新規性
• よくできた proxy はすでにある: HAProxy, NGINX
• サービスのつなぎ目の要所になる proxy を中央の
control-plane から管理できるようにしたところに新規
性がある
‣ コンテナオーケストレーションと相性が良かった
• Observability を強く意識していて metrics に重点を
置いた
‣ クックパッドでも昔 Observability のために HAProxy2 作
ろうかみたいな話をしていた
どんな組織が使っている?
• Lyft, Google, IBM, ebay, Apple,
Microsoft, stripe, Netflix,
Pinterest, Meduim, Salesforce,
Square, Paypal, Expedia, AOL...
• クックパッドも!
Service Mesh の実装の1つ
• Istio
‣ control-plane: Pilot, Mixer, Istio-Auth
‣ data-plane: Envoy
‣ k8s 以外でも使えるようになったっぽい
• 今回は data-plane について深掘り
(後述するように control-plane は
自作したので)
data-planes
• Linkerd: Feb, 2016 from Buoyant
• Envoy: Sep, 2016 from Lyft
• Conduit proxy: Dec, 2017 from
Buoyant
data-planes
• Linkerd: Scala, Netty/Finagle
• Envoy: C++14, using nghttp2
• Conduit proxy: Rust, early stage
• クックパッドは Envoy proxy を選択
Envoy vs Linkerd at Cookpad
• no VM vs JVM
‣ less resource usage
‣ hot restart
• 豊富な設定、xDS API による更新
• h2, gRPC support が not experimental
• Istio での採用状況: community の厚さ
C++?
• 実は modern C++ は言うほど読みにくくない、syntax
的にむしろ読みやすい方
• 実は modern C++ は言うほど書きにくくない、覚えるこ
とはわりとあるが step by step でパッチを書ける
• 各種ツールが優秀: clang-tidy, AddressSanitizer,
ThreadSanitizer...
• あくまでアプリケーションを読み書きする上では。ライ
ブラリはわからない
• Envoy コミュニティのレビュー層が厚い
詳解 Envoy
What’s Envoy
• Service mesh 用 data-plane proxy
• Edge proxy: TLS termination, routing,
load balancing
• gRPC サポート
• 受付システムの Envoy と名前被りして
るので ”Envoy proxy” でググる
• hot reload/hot restart のサポート
• nghttp2 for h2, single process multi-
threaded, libevent for aysnc IO
• 豊富な stats: per AZ, per listener, per
upstream cluster, per canary...
• リトライ・タイムアウト・サーキットブレーカー
• 分散トレーシング: request ID の発行・ログの送
信
余談: Envoy v1.6.0 release 🎉
https://twitter.com/taiki45/status/976317282870689792
Getting started
• main code: https://github.com/
envoyproxy/envoy
• doc/API spec: https://github.com/
envoyproxy/data-plane-api
• 公式 Docker image あり
• ビルドツールに bazel を使っている
Envoy のコンポーネント
• Listener: TCP connection をハンドル
• Cluster: upstream host 群(endpoints)の情報を持って
る
• Filter: data を受け取り処理をして流す
‣ Network filters: Client TLS Authn, Redis, Mongo...
‣ HTTP filters: Router, gzip, Lua...
• Stats sink: statistics を送る口
• xDS API: 自身の設定を更新 →
xDS API
• data-plane API とも呼ばれている
• Envoy 内の情報を更新するための API spec
‣ LDS: Listener Discovery Service
‣ CDS: Cluster Discovery Service
‣ EDS: Endpoint Discovery Service
‣ RDS: Route Discovery Service
‣ その他…
コンポーネントの概観
Thread model
https://blog.envoyproxy.io/envoy-threading-model-a8d44b922310
Hot Restart
https://blog.envoyproxy.io/envoy-hot-restart-1d16b14555b5
stats の送信/保存
• statsd sink -> relay -> DB
• dog_statsd sink -> statsd_exporter <-
Prometheus
• admin /stats <- Envoy listener/filter <-
Prometheus
• クックパッドは2個目のやつ採用(というか
自分たちで使うから作った)
gRPC support
• gRPC health checking
• HTTP/1.1 bridge
• gRPC-JSON transcoding
• gRPC-Web support
go-control-plane
• Istio チームが開発中
• Envoy data-plane-api に沿った
control-plane を go で書くためのラ
イブラリ
• Java 版もある
• まだまだ Envoy のおもしろいところ
はあるけど、そろそろクックパッド
での事例へ…
クックパッドでの事例
Service Mesh の未来(予測)
• コンテナ管理のサービスに付随して、たぶんマ
ネージドサービスが各 Cloud Vendor から出て
くると思う
• コンテナの設定と一緒にサービスを繋ぐ設定を
書いておいたらいい感じにコンテナ内からルー
ティングされて、コンソールとかで可視化でき
るやつ
• 便利そう、しかしまだ無い(し、出て来る確証は
ない)、意外と簡単だし作るぞ!
現状
クックパッドでの Service Mesh
• AWS ECS with Hako, no k8s
• data-plane: Envoy proxy
‣ コミットほぼ全部見てるので origin HEAD を使ってる
• control-plane: kumonos + Amazon S3 + lyft/
discovery
‣ kumonos は今のところ実装のみの公開
• metrics: dog_statsd sink + statsd_exporter +
Prometheus
Our control-plane
• 中央のリポジトリで各サービスの依存情報を YAML で管理す
る
• kumonos gem で依存定義を CDS/RDS API 用の JSON に変換
• 生成した JSON を S3 で各 Envoy に配布
• CDS で配布する endpoint は Internal ELB に限定する
‣ 後に ELB 無しに動的なホスト群を扱えるようにもした: for
gRPC client-side load balancing
• CDS/RDS API 経由で各 Envoy インスタンスのルーティングや
retry/timeout/circuit-breaker の設定を更新
Our Service Mesh
中央のリポジトリで管理する理由
• 変更履歴を理由付きで管理しておきた
い: Git が適任
• サービスを繋ぐ設定変更を横断的な
チームがレビューできるようにした
い: GitHub が適任
• これで service discovery, retry/
timeout/circuit breaking が実現
Envoy stats on Grafana
• サービス毎、特定のサービス×サービス
‣ 各 upstream 毎の RPS/status/latency
などなど
‣ retry/timeout/circuit-breaker の発動
状況
• 各 Envoy の状況
Draft: Observability, Service Mesh and Microservices
Service Mesh の現状
• メトリクスの可視化ができている
• retry/timeout/circuit-breaker をアプリケーショ
ンの外で実現できている
‣ その設定値が GHE 上で管理されていて変更履歴が追え
る
‣ その設定値をアプリケーションとは別にレビューできる
• 余談: gRPC 用の client-side load balancing on ECS
も service mesh があったのでサクッとできた
今後
さらなる可視化
• 収集・表示するメトリクスを増やす
‣ gRPC サービスの手前に Envoy を置いてアク
セスログ収集等も
‣ 運用していく過程でほしくなったメトリクス
• promviz を使った可視化
• 社内のコンソールソフトウェアとの統合
https://github.com/Netflix/vizceral
さらなる自動化
• サービス繋がり部分での各種異常やイベ
ントのアラート発火
‣ まずは SRE へ
‣ プロダクト開発チームへも届けたい(権限と
責任の委譲)
• retry 等の設定値調整用のツール整備・自
動化
Out of Process の進展
• 分散トレーシングを service mesh 層で
実現する
‣ AWS X-Ray 用の Tracer 実装
• 認証・認可処理やデッドラインの実現・
伝播
• Failure Injection をして設定値のテスト
• 余談: config は v2 だけど xDS API
は v1 のものを使ってるので v2 に置
きかえてく
‣せっかくなので Amazon ECS のまま
control-plane に Istio のコンポーネ
ントを使えないか検証もする予定
まとめ
Service Mesh
便利
採用目的™
https://info.cookpad.com/careers
Draft: Observability, Service Mesh and Microservices
今回のお話
• なぜマイクロサービスに挑戦しているのか
‣ 時間の都合上カット、資料に掲載
• 「service mesh とは」について背景やメ
リットなど普遍的な話
• クックパッドでの事例紹介: Envoy + 自作
control-plane

Weitere ähnliche Inhalte

Was ist angesagt?

JVM上でのストリーム処理エンジンの変遷
JVM上でのストリーム処理エンジンの変遷JVM上でのストリーム処理エンジンの変遷
JVM上でのストリーム処理エンジンの変遷Sotaro Kimura
 
tweleve-factor-app_and_enterprise
tweleve-factor-app_and_enterprisetweleve-factor-app_and_enterprise
tweleve-factor-app_and_enterpriseNaoto TAKAHASHI
 
Cloud Foundryで学ぶ、PaaSのしくみ講座
Cloud Foundryで学ぶ、PaaSのしくみ講座Cloud Foundryで学ぶ、PaaSのしくみ講座
Cloud Foundryで学ぶ、PaaSのしくみ講座Kazuto Kusama
 
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)Daisuke Ikeda
 
パフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいパフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいzaru sakuraba
 
誰にでもできるパフォーマンスチューニング
誰にでもできるパフォーマンスチューニング誰にでもできるパフォーマンスチューニング
誰にでもできるパフォーマンスチューニングKiyokazu Kaba
 
クラウド時代だからSpring-Retryフレームワーク
クラウド時代だからSpring-Retryフレームワーククラウド時代だからSpring-Retryフレームワーク
クラウド時代だからSpring-RetryフレームワークY Watanabe
 
知って欲しいPaaSの話
知って欲しいPaaSの話知って欲しいPaaSの話
知って欲しいPaaSの話Kazuto Kusama
 
はじめてのCF buildpack
はじめてのCF buildpackはじめてのCF buildpack
はじめてのCF buildpackKazuto Kusama
 
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3Toshiaki Maki
 
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Kazuto Kusama
 
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めたJJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めたKoichi Sakata
 
SpringOne 2015 報告会 - Lattice + Spring Cloud Netflix
SpringOne 2015 報告会 - Lattice + Spring Cloud NetflixSpringOne 2015 報告会 - Lattice + Spring Cloud Netflix
SpringOne 2015 報告会 - Lattice + Spring Cloud NetflixTommy Ludwig
 
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話Kentaro Yoshida
 
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用DeNA
 
Lineにおけるspring frameworkの活用
Lineにおけるspring frameworkの活用Lineにおけるspring frameworkの活用
Lineにおけるspring frameworkの活用Tokuhiro Matsuno
 
Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Kazuto Kusama
 
Single Command Deployのための gradle-aws-plugin講座
Single Command Deployのための gradle-aws-plugin講座Single Command Deployのための gradle-aws-plugin講座
Single Command Deployのための gradle-aws-plugin講座都元ダイスケ Miyamoto
 
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話JustSystems Corporation
 

Was ist angesagt? (20)

JVM上でのストリーム処理エンジンの変遷
JVM上でのストリーム処理エンジンの変遷JVM上でのストリーム処理エンジンの変遷
JVM上でのストリーム処理エンジンの変遷
 
tweleve-factor-app_and_enterprise
tweleve-factor-app_and_enterprisetweleve-factor-app_and_enterprise
tweleve-factor-app_and_enterprise
 
Cloud Foundryで学ぶ、PaaSのしくみ講座
Cloud Foundryで学ぶ、PaaSのしくみ講座Cloud Foundryで学ぶ、PaaSのしくみ講座
Cloud Foundryで学ぶ、PaaSのしくみ講座
 
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
クラウド環境向けZabbixカスタマイズ紹介(第5回Zabbix勉強会)
 
パフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したいパフォーマンス計測Ciサービスを作って得た知見を共有したい
パフォーマンス計測Ciサービスを作って得た知見を共有したい
 
誰にでもできるパフォーマンスチューニング
誰にでもできるパフォーマンスチューニング誰にでもできるパフォーマンスチューニング
誰にでもできるパフォーマンスチューニング
 
クラウド時代だからSpring-Retryフレームワーク
クラウド時代だからSpring-Retryフレームワーククラウド時代だからSpring-Retryフレームワーク
クラウド時代だからSpring-Retryフレームワーク
 
知って欲しいPaaSの話
知って欲しいPaaSの話知って欲しいPaaSの話
知って欲しいPaaSの話
 
はじめてのCF buildpack
はじめてのCF buildpackはじめてのCF buildpack
はじめてのCF buildpack
 
MySQL Binlog Events でストリーム処理してみた #MySQLUC15
MySQL Binlog Events でストリーム処理してみた #MySQLUC15MySQL Binlog Events でストリーム処理してみた #MySQLUC15
MySQL Binlog Events でストリーム処理してみた #MySQLUC15
 
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
Reactive Webアプリケーション - そしてSpring 5へ #jjug_ccc #ccc_ef3
 
Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較Docker PaaSとしての OpenShift, Deis, Flynn比較
Docker PaaSとしての OpenShift, Deis, Flynn比較
 
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めたJJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
JJUG CCC 2017 Spring Seasar2からSpringへ移行した俺たちのアプリケーションがマイクロサービスアーキテクチャへ歩み始めた
 
SpringOne 2015 報告会 - Lattice + Spring Cloud Netflix
SpringOne 2015 報告会 - Lattice + Spring Cloud NetflixSpringOne 2015 報告会 - Lattice + Spring Cloud Netflix
SpringOne 2015 報告会 - Lattice + Spring Cloud Netflix
 
爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話爆速クエリエンジン”Presto”を使いたくなる話
爆速クエリエンジン”Presto”を使いたくなる話
 
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用
IoTと業務システムをつなぐgRPC/RESTサービスの開発と運用
 
Lineにおけるspring frameworkの活用
Lineにおけるspring frameworkの活用Lineにおけるspring frameworkの活用
Lineにおけるspring frameworkの活用
 
Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践Cloudn PaaSチームのChatOps実践
Cloudn PaaSチームのChatOps実践
 
Single Command Deployのための gradle-aws-plugin講座
Single Command Deployのための gradle-aws-plugin講座Single Command Deployのための gradle-aws-plugin講座
Single Command Deployのための gradle-aws-plugin講座
 
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
 

Ähnlich wie Draft: Observability, Service Mesh and Microservices

JavaScript And Keywords
JavaScript And KeywordsJavaScript And Keywords
JavaScript And Keywordsuupaa
 
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.Kensaku Komatsu
 
Build Windows ラップアップ
Build Windows ラップアップBuild Windows ラップアップ
Build Windows ラップアップSunao Tomita
 
AWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャAWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャ真吾 吉田
 
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所真吾 吉田
 
Voicepic@FukuiMASeminar
Voicepic@FukuiMASeminarVoicepic@FukuiMASeminar
Voicepic@FukuiMASeminarManabu Shimobe
 
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤Masahiro Kiura
 
Multibranch Pipeline with Docker 入門編
Multibranch Pipeline with Docker 入門編Multibranch Pipeline with Docker 入門編
Multibranch Pipeline with Docker 入門編kimulla
 
GKEで半年運用してみた
GKEで半年運用してみたGKEで半年運用してみた
GKEで半年運用してみたKatsutoshi Nagaoka
 
Rdbms起点で考えると見えない世界 okuyama勉強会
Rdbms起点で考えると見えない世界 okuyama勉強会Rdbms起点で考えると見えない世界 okuyama勉強会
Rdbms起点で考えると見えない世界 okuyama勉強会Masakazu Muraoka
 
PostgreSQLではじめるOSS開発@OSC 2014 Hiroshima
PostgreSQLではじめるOSS開発@OSC 2014 HiroshimaPostgreSQLではじめるOSS開発@OSC 2014 Hiroshima
PostgreSQLではじめるOSS開発@OSC 2014 HiroshimaShigeru Hanada
 
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話JustSystems Corporation
 
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側Yusuke Naka
 
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...Amazon Web Services Japan
 
Backlogでの Perlのつかいかた
Backlogでの PerlのつかいかたBacklogでの Perlのつかいかた
Backlogでの PerlのつかいかたRyuzo Yamamoto
 
クラウド運用のためのストリームマイニング
クラウド運用のためのストリームマイニングクラウド運用のためのストリームマイニング
クラウド運用のためのストリームマイニングShin Matsumoto
 
サーバーレスの今とこれから
サーバーレスの今とこれからサーバーレスの今とこれから
サーバーレスの今とこれから真吾 吉田
 
20140926 mt cloud_handson_seminar
20140926 mt cloud_handson_seminar20140926 mt cloud_handson_seminar
20140926 mt cloud_handson_seminarSix Apart
 
HTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なことHTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なことMasakazu Muraoka
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Dai Utsui
 

Ähnlich wie Draft: Observability, Service Mesh and Microservices (20)

JavaScript And Keywords
JavaScript And KeywordsJavaScript And Keywords
JavaScript And Keywords
 
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.
最新Web 通信系API総まくり!WebRTC, Streams, Push api etc.
 
Build Windows ラップアップ
Build Windows ラップアップBuild Windows ラップアップ
Build Windows ラップアップ
 
AWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャAWSによるサーバーレスアーキテクチャ
AWSによるサーバーレスアーキテクチャ
 
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
サーバーレスのアーキテクチャパターンとそれぞれの実装・テストの勘所
 
Voicepic@FukuiMASeminar
Voicepic@FukuiMASeminarVoicepic@FukuiMASeminar
Voicepic@FukuiMASeminar
 
認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤認証/認可が実現する安全で高速分析可能な分析処理基盤
認証/認可が実現する安全で高速分析可能な分析処理基盤
 
Multibranch Pipeline with Docker 入門編
Multibranch Pipeline with Docker 入門編Multibranch Pipeline with Docker 入門編
Multibranch Pipeline with Docker 入門編
 
GKEで半年運用してみた
GKEで半年運用してみたGKEで半年運用してみた
GKEで半年運用してみた
 
Rdbms起点で考えると見えない世界 okuyama勉強会
Rdbms起点で考えると見えない世界 okuyama勉強会Rdbms起点で考えると見えない世界 okuyama勉強会
Rdbms起点で考えると見えない世界 okuyama勉強会
 
PostgreSQLではじめるOSS開発@OSC 2014 Hiroshima
PostgreSQLではじめるOSS開発@OSC 2014 HiroshimaPostgreSQLではじめるOSS開発@OSC 2014 Hiroshima
PostgreSQLではじめるOSS開発@OSC 2014 Hiroshima
 
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
 
WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側WebRTC開発者向けプラットフォーム SkyWayの裏側
WebRTC開発者向けプラットフォーム SkyWayの裏側
 
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
AWS Black Belt Tech シリーズ 2015 - AWS CodeCommit & AWS CodePipeline & AWS CodeD...
 
Backlogでの Perlのつかいかた
Backlogでの PerlのつかいかたBacklogでの Perlのつかいかた
Backlogでの Perlのつかいかた
 
クラウド運用のためのストリームマイニング
クラウド運用のためのストリームマイニングクラウド運用のためのストリームマイニング
クラウド運用のためのストリームマイニング
 
サーバーレスの今とこれから
サーバーレスの今とこれからサーバーレスの今とこれから
サーバーレスの今とこれから
 
20140926 mt cloud_handson_seminar
20140926 mt cloud_handson_seminar20140926 mt cloud_handson_seminar
20140926 mt cloud_handson_seminar
 
HTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なことHTML5時代のwebクリエイターに必要なこと
HTML5時代のwebクリエイターに必要なこと
 
Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会Gmo media.inc 第9回西日本ossの普及を考える会
Gmo media.inc 第9回西日本ossの普及を考える会
 

Draft: Observability, Service Mesh and Microservices