tsalakh ain sus noam Huyah ol guf

勉強会のメモ。その他備忘録。参考にさせて頂いたサイトや資料はリンクさせて頂いていますが不都合があればご連絡ください。

【勉強会】Spring Fest 2018

noindex

20181031_SpringFest2018

springfest2018.springframework.jp

KEYNOTE

  • Sébastien Deleuze さん

各技術状況

Java

  • 2017年10月でJava8のシェアが75%
  • Java11はLTS、次は17がLTS、3年ごと、それ以外は6ヶ月サイクル
  • Spring5.0のサポートEOLは2019/03、どんどんアップデートする予定
  • GraalVM：ハイパフォーマンスpolyglot VM、native executable

Kotlin

  • 主にAndroid開発、だけどサーバでも使われてる
  • 2日前にKotlin 1.3リリース
  • Coroutines：ライトウィイトなスレッド

Spring Framework 5.1

  • Java9/10に関してはベストエフォートのサポート
  • 性能改善してる

Spring Boot 2.1

  • 2.1が昨日リリース
  • Java11サポート、Spring 5.1ベース、Tomcat9
  • パフォーマンス改善（Startupの時間、ヒープ消費）
  • Spring Data JDBC導入、ORMがフルでいらない場合のネイティブSQL

Roadmap

Spring Framework 5.2

  • 来年リリース
  • Kotlin1.3サポート
  • Coroutinesサポート
  • GraalVMをサポート

demo

  • 1分くらいでnative executable作る
  • Spring Bootの起動が7msで終わる

R2DBC

  • Reactive Relational Database connectivity
  • 非同期のSQLドライバ
  • Minimal driver SPI
  • Reactiveトランザクションをサポート　via Reactor
  • rowがストリームで返ってくる

RSocket

  • ネットワークのReactive
  • Reactive streams back pressure over the network
  • RequestResponse/FireAndForget/Request-Stream/Channel（双方向ストリーム）どれもいける
  • Java/JavaScript/C++/Kotlinをサポート

Spring Fu

まとめ

  • プライオリティー
    • 性能
    • リアクティブ（SQLやネットワークにも）

SpringとPCFで作るクラウドネイティブ

決済システムの内製化への旅 - SpringとPCFで作るクラウドネイティブなシステム開発

  • Pivotal 槙 俊明 さん
  • ソフトバンク・ペイメント・サービス株式会社 鈴木 順也 さん

www.slideshare.net

内製化に至る道のり

2016年

開発はベンダーに丸投げ、開発できる社員がゼロの状態でJOIN

  • 課題：運用の手作業が多く、ミスも多い
    • 支援ツールを内製化、運用作業を自動化
    • SpringBoot,Selenium/Selenide
    • GitHub,Slack,Confluence,JIRAを導入して開発環境を整備

2017年

  • 課題：サービス状況をすばやく把握できてなかった

    • ElasticStackを導入

  • 課題：古いアーキテクチャのため、開発が高コスト、監視が困難

    • SpringBoot/SpringCloudを導入
    • Jenkins/Nexus/sonarqubeを導入、CIを当たり前に

2018年

システム本体の内製化をスタート、PivotalCloudFoundry導入

  • スピード感のある開発・リリース
  • 継続的な改善サイクル
  • 監視を強化して障害に強いシステム

PivotalCloudFoundryを選んだ理由

  • コードを書いた後のインフラ整備が1分で終わる
  • DevとOpsの責任分界点が明確

Why PaaS？（Kubernatesじゃなく）

  • 「I'd like less responsibility」
  • 開発者に余計なことをさせたくない、PaaSはできることが良い意味で限られている

全体アーキテクチャ

  • DevはPrdと同環境で用意する
  • MW系の管理は、Cloud Foundry BOSHで管理（ChefやAnsibleでなく）
  • APIGatewayでルーティング（Spring Cloud GatewayのProxyExchangeで実装）
  • システム間連携にはHystrixを入れてCircuit Brakerを実装
  • 非同期連携はRabbitMQ＋Spring Cloud Stream、返せなかったらDeadLetterQueue
  • アプリケーションのオートスケール、PCF App Autoscaler（PaaSではおなじみの機能）

12 Factor App

  • アプリで重要なのは3,6,7,8,11
    • 6,7,8はSpring Bootならほぼ満たされる
    • 3、環境依存の設定は環境変数に格納
    • 11、標準出力からLogStashへ

絶対ロストしたくないログは、トランザクションデータと割り切ってRDBへ

CI/CD

  • PivotalのConcource
    • ビルドパイプラインが視覚的にわかりやすい
    • 設定はYAML

CI

GitHubにPush -> JUnit/SonarQube -> Nexusにアップロード -> テストサーバにデプロイ

CD

ConcourceCIを手動クリック -> masterブランチにマージ -> UT -> バージョンタグ -> ビルド -> Nexusアップロード -> 本番環境へデプロイ

というのは一例、実際には人によるリリース判断が入る

リグレッションテスト

  • JMeterで負荷テスト、E2Eテスト
    • 開発中は、毎日継続的に実施
    • JMeterのレポートのHTMLをSlackに通知

Javaのバージョンアップ

  • 複数のバージョンを同時にテスト可能なCI環境を用意
  • 簡単にデプロイ可能なDev・Staging/Prod環境を用意
  • 塩漬けするのではなく、アップデートし続けられる環境を準備

Observability

Metrics/Tracing/Logging

  • Metrics：Grafana/Prometheus/Micrometer
  • Logging：Elasticstak
  • Tracing：ZIPKIN

アプリ側には依存を追加するだけ

エンタープライズアジャイル

エンタープライズアジャイルと Spring/Wagby の親和性

エンタープライズアジャイルとは

  • エンタープライズアジャイルの推進は、SoRとSoEの統合につながっている
  • 核となる技術として、Springは最適
  • SoEは好きな技術で作ったとしても、SoRはSpringにしておくべき

SoR

社内利用、経費削減のためのIT

SoE

社外利用、売上アップのためのIT

DX：デジタルトランスフォーメーション

全ての企業がSoEへ踏み出さなければ、Amazonに蹂躙されますよ、という恐怖感

アジャイルの思想

「利用者と開発者が密にコミュニケーションをとって、必要なものを作る」

不要かもしれないものでも、計画してしまったら作るしかない、というエンタープライズへのアンチテーゼ

大規模案件でも使えるのか

  • 大手SIerが実績として掲げる「アジャイル開発」の事例は、ほぼ例外なく小規模案件
  • アジャイル開発には、丸投げ不可・責任の押し付け合い不可、というドグマが存在
  • ユーザに、コードを書く以外のことはなんでもやる、という気概が求められる
  • SoEでアジャイルがうまくいくのは、ユーザにその気概があるから

なんのためのエンタープライズアジャイルか

  • 開発費と保守費の削減
  • 開発スピードアップ
  • ユーザによるシステムイニシアチブの確保

SoRを支える情シスの心構え

改めて、エンタープライズアジャイルとは

  • SoRとSoEの垣根をなくすムーブメントにつながる
  • SoRはなくならない、が、抜本的な改革が必要

楽天トラベルでのSpring

Rakuten Travel and Spring

  • 楽天トラベル Kalburgi Gajraj さん

Spring Initializr

  • 楽天では、InitializrのWebをラップして使ってる

Spring Cloud Configurations

  • パッケージにコンフィグファイルを含まなくてよくなる
  • 突発の変更に柔軟になる
  • コンフィグレーションリポジトリから、コンフィグサーバへの通信はSSH
  • コンフィグサーバからAPPサーバへはBASIC認証

（GitHubに本番の設定ファイルもいれるんだろうか？）

Actuators

Actuatorのエンドポイント（例）

  • /health：ヘルスチェック
  • /info：Mavenの情報？
  • /env：Spring Configurationの環境情報
  • /loggers：ログの設定、ここで変更もできる？

Spring Boot Admin でActuatorのAPI呼ばなくても可視化してくれる

Swagger

  • 可視化に使ってる
  • APIの簡易テストドライバとしても

Observability

Observability with Spring-Based Distributed Systems

  • 楽天トラベル Thomas Ludwig さん

What is observability

  • データとコンテキストとして、何か気づきを得られる
    • 部分的な故障
    • 予想できないことを予想する
    • 知らなかったことを知れる Beyond traditional monitoring

障害は必ず起こる、どれだけ早く検知・理解・修復できるかが重要

Observabilityの3つの側面

  • Logging
  • metrics
  • tracing

Logging

Spring Cloud Sleuth でリクエストにtraceIDを埋める

  • アプリは依存性を追加するだけ
  • 設定はSpring Cloud Configで設定は共通設定

Metrics

Micrometer で、Metrics backendにデータを送る

  • backendはいろいろ対応してる（Prometheusとか、Datadogとか）
  • micrometer-registry-prometheusをdependencyに追加するだけ
  • 設定はSpring Cloud Configで設定は共通設定

Alertに関して。

Double Alerts にしない

  • サービスが増えると、1つの障害が何箇所でもアラートが出る
  • ユーザにエラーが返ってないなら、アラート不要

Tracing

Zipkinで、プロセスを跨いだ分散トレーシング

  • spring-cloud-zipkin-starterを依存性を入れるだけ
  • 設定はSpring Cloud Configで設定は共通設定
  • 取得される値はサンプリング、サンプリングの％はConfigで設定
  • 非同期でも、トレースできる

テストにも使える

  • traceId以外に共通のIDを持たせるとか（楽天トラベルでは、IDcorrelationId）
  • Zipkin Browser ExtensionでtraceIdを画面リクエストのヘッダに埋めたり

まとめ

  • Observabilityを意識しよう
  • ツール組み合わせよう

LINEでのSpring

500+のサーバで動くLINE Ads PlatformをささえるSpring

  • LINE株式会社 渡邉 直樹 さん

www.slideshare.net

（Springに限らず、LINEの広告管理システムで使っている技術の説明。）

Java

maxGCPauseMillis

  • maxGCPauseMillis,default 200ms
  • 20msに設定したら悪化した
  • あまり積極的な設定にするとむしろ遅くなる（と公式にも記載あり）
  • 結局、ヒープを増やした
  • Java11のZGCに期待

Java以外

Golang

  • JavaのGCが遅い、G1GCでも数十ms使うことがある
  • GoのGCは高速なので、Go採用

Kafka

  • 高速、安定
  • 一度入れてしまえば、後から非同期でコンシュームしてデータが見れる
  • Consumerごとにどこまでデータを読んだかを管理している、データを消さない、ってところがいい
  • 高負荷で受けられないとか、送った送ってない問題
  • 各サービスは、Kafkaに書き込むまでを責務とすることで、責務分解が明確になる
  • QueueやJob schedulerとしても使える

️⃣### Kafka難しくないの？

  • SpringBootと相性がいい
  • コードをあまり書かなくていい
  • spring-kafkaもいいけどSpringのバージョンに引きずられる
  • 公式のkafka_clientが十分おすすめ
  • Kafka streamsはシンプルに使えてイイ

LINEのアーキテクチャ選定の基準

  • LINEのアーキテクチャはDev Leadが決定
  • 揃えられるものは揃える（理由があればOK）
  • 速度が第一条件（基本コンパイル型）
  • 流行ってるから使いたい、とかはNG

LINE Adsチームの最近の開発

  • SpringBoot2
  • Reactor
  • Kafka
  • actuator/micrometer -> Prometheus/Grafana

Reactor

  • Ractive streams
  • Non-blocking + Back pressure
  • BackPressureはあまり使ってない、Kafkaがあるから
  • WebFlux, Lettuce5
  • Flux, Mono

Lettuce5

  • Reactive API
  • Redisとつながる
  • 戻り値がMono/Flux
  • すごくスッキリ

Spring Data REST / Spring Cloud Contract

Spring Data REST と Spring Cloud Contract

  • 株式会社タグバンガーズ 小川 岳史 さん／山﨑 大 さん

www.slideshare.net

Spring Data REST

HATEOAS

SpringData RESTのレスポンスは、DATA部とLINK部で分かれている

  • LINK部はHATEOASというスタイルに準拠している
  • HATEOAS:Hypermedia As The Engine Of Application State
  • 次にできるアクションのリンクを返せる
  • フロントエンド側でURLを組み立てなくていい

例えば、statusがPENDINGかPAIDだったらキャンセルできる、みたいな仕様の時

  1. フロントに実装すると、ロジックが流出してしまう
  2. Web/Android/iOS で重複実装が発生

バックエンドで実装できた方がイイ

SpringDataRESTの実例

  1. 管理機能
    • 現実的に、エンドユーザ機能は単純CRUDではすまないケースが多い
    • 管理機能のみに導入した
  2. 全文検索
    • HibernateSearchというライブラリ使うとElasticSearch繋げる（！！）
  3. マルチテナント
    • SpringSecurityと組み合わせて、WHERE句にテナントを埋めるようにHibenateをカスタマイズ

Spring Cloud Contract

解決したい課題

  • 破壊的な変更をデプロイする前に、ビルド段階で検出したい
  • 自動テストがダイジ

解決案

  • モックに置き換える
    • モックは本当に正しいの？
    • モックは誰がメンテするの？

そこで、Spring Cloud Contarct

  • ただ、ConsumerもJavaじゃないと使えない
  • Angularでは使えなかった

そこで、Pact

  • SpringBoot2からPactがサポートされた

Consumer Driven Contract

APIを使う側がどう使うつもりか、を定義する

  • Consumer:APIを使う側
  • Provider:APIを提供する側
  • Contract = 契約

ConsumerのContractファイルでテストできる
破壊的なAPIの変更があれば、ここで気づける

Spring Cloud Contract

  • Contractファイルからビルド時にテストを自動生成できる
  • モックも自動生成（WireMockの定義ファイル）できる

Pact

さまざまな言語をサポート

Micrometer/Prometheus

Micrometer/Prometheusによる大規模システムモニタリング 〜ヤフーインターネット広告システムでの導入事例〜

  • ヤフー株式会社 池田誠さん

Prometheus

  • 時系列DB＋モニタリングシステム
  • pull方式（ZABBIXはpush方式）
  • KeyValueのテキストデータでデータ連携
  • PromQLという独自クエリで検索／可視化が可能、Grafanaでダッシュボード
  • 注意点
    • 時系列DBが冗長化できない
    • 同一構成のPrometheusを用意するか、InfluxDBなど別の時系列DBを使う（有償）

Micrometer

  • メトリクス収集のライブラリ
  • SpringBootならDependency追加＆設定のみでOK
  • 様々なモニタリングシステムと連携可能、CloudWatchもOK
  • 設定
    • pull型なら、Actuatorでエンドポイント公開
    • push型の場合は送信先を設定
    • CloudWatchの場合は認証情報なども必要

取れるもの

  • WebController/REST APIの実行回数とか
  • JVMのメトリクスとか
  • CPU使用率も
  • カスタムメトリクスも作成可能(JOBの実行回数とか)

採用理由

要件

  • IaaS/PaaS/CaaSのどのPFにも導入可能なこと
  • 監視対象アプリへの導入が容易、SpringBootならコード修正不要なこと
  • アラートが出せること
  • グラフ可視化できること
  • メトリクスがカスタマイズ可能なこと

Micrometer

-

というか、他に競合製品がない

Prometheus

  • 時系列DBなのでグラフ描画に最適
  • pull方式のためエージェントレス（PaaSには課題あり）
  • 1万ノード監視の実績
  • SRE本でも紹介
  • コミュニティーが活発で将来性マル

数千台あるとエージェントレスでもきつい

数千インスタンスをPrometheusに設定する運用コストが高い

  • そこで、サービスディスカバリを導入
  • Netflix-Eureka（eureka-client-starter）
  • Eureka連携ツールは自作

Prometheusのサーバスペック

特別大きくない

  • SPEC = VM(IaaS)、CPU:2.1GHz 8core、MEM:16GB、Disk:500GB
  • AWSのXLarge-２XLarge相当

課題

PaaS

PaaSの場合、Prometheusがpullが綺麗にとれない

  • 原因
    • PaaSのルータがバランシングしてしまい、インスタンスが狙い撃ちできない
  • 対策
    • PushGatewayというサービスを挟んで一時手当（対応模索中）

JAX-RS

Micrometer導入後数時間でGC連発

  • 条件
  • 原因
    • Pathパラメータごとにメトリクス収集され、データが爆増し、メモリ逼迫
  • 対策
    • JAX-RSのインターセプターを自作して回避
    • Micrometer1.0.5+はJAX-RSの場合uriがUNKNOWNにされる
    • メモリ枯渇はしないが、、、これはこれで課題なので結局自作インターセプタで回避
    • 最新だと解決済みかも（未検証）

SpringMVCなら何もしなくてもPathパターンごとに収集可能

カスタムメトリクスを使う場合、メトリクス数の爆増に注意。メモリ逼迫もだし、検索性能も劣化する

Prometheusの性能問題

  • 複雑なクエリを並列実行するとOOMキラーが発動してPrometheusが死ぬ
    • 複雑＝1時系列あたり数万メトリクスで、数週間分とる、とか
  • 対策
    • PrometheusのRecordingRuleで回避可能かも（検証中）

まとめ

  • 良かった点
    • 導入コスト超低い
    • カスタマイズ性抜群、見たい人が見たいものを勝手に見てくれる
  • 悪かった点
    • PromQLの習得に学習コストがかかる
    • Webに情報が少ない
  • Yahooレベルの大規模システムでも利用可能なのでみなさんもぜひ