小さなサービスも契约する时代
- 1. 小さなサービスも 契約する時代 マイクロサービスのテストをすばやく回し デプロイを安全にやるよい方法 サイボウズ 西日本開発部 大阪オフィス 三苫 亮 Osaka Venture Today Meetup #4 2018/10/26
- 2. 自己紹介 ? 三苫 亮 (みとま りょう) ? @mitomasan ? サイボウズ西日本開発部 ? kintone開発チーム Yakumoプロジェクト ? サーバーサイドエンジニア ? 2015年9月中途入社 ? 週2日出社、週3日在宅
- 3. 目次 ? 今日のゴール ? マイクロサービスとは ? テストにおける课题 ? どうすればいいのか？ ? コンシューマ駆动契约 ? サイボウズでの事例 ? まとめ
- 5. 想定聴衆 ? 自動テストを知っている ? JUnit とか RSpec とか ? Selenium による E2E テストとか ? マイクロサービスアーキテクチャについて知っている ? 概要レベル
- 6. コンシューマ駆动契约とは マイクロサービスアーキテクチャで構築されたシステムで各サービスを任意の タイミングでリリースできるようにすると、全体が結合された環境で行うテスト は非常に高価になりこの方法ですべてのユースケースをテストすることはできな くなる。 各サービスは自分がどのサービスから呼び出されているか把握することが困難 になり、互換性を壊す変更をリリース前に検出することが難しくなる。 コンシューマ駆动契约とはサービスの利用側?提供側で (状態, 入力, 出力) の組 を契約と定義し、サービス利用側(コンシューマ)が契約を結ぶことを責務とし、そ の契約を壊していないことを利用側?提供側双方でテストすることで結合環境で のテストの代替として上記の問題を解決するものである。 三苫の理解より長すぎるゾ！
- 7. コンシューマ駆动契约とは マイクロサービスアーキテクチャで構築されたシステムで各サービスを任意の タイミングでリリースできるようにすると、全体が結合された環境で行うテスト は非常に高価になりこの方法ですべてのユースケースをテストすることはできな くなる。 各サービスは自分がどのサービスから呼び出されているか把握することが困難 になり、互換性を壊す変更をリリース前に検出することが難しくなる。 コンシューマ駆动契约とはサービスの利用側?提供側で (状態, 入力, 出力) の組 を契約と定義し、サービス利用側(コンシューマ)が契約を結ぶことを責務とし、そ の契約を壊していないことを利用側?提供側双方でテストすることで結合環境で のテストの代替として上記の問題を解決するものである。 三苫の理解より課題を説明してから解決を説明します 課 題 解 決
- 8. マイクロサービスとは
- 16. マイクロサービスの良いところ その1 ? 技術的異質性 ? サービスごとに別の技術を使える ? 回復性 ? サービスの一つが障害を起こしてもそのほかは稼働し続ける ? スケーリング ? サービス単位でスケールアップ?スケールアウトできる ? デプロイ容易性 ? サービス単位でリリースできるので変更差分を小さくできる
- 17. マイクロサービスの良いところ その2 ? 組織面の一致 ? チームとサービスを一致させることで チーム間の折衝が減らせる ? 合成可能性 ? サービスが単機能であるほど再利用しやすい ? 交換可能にするための最適化 ? レガシーになっても、リライトできる規模
- 18. テストにおける课题
- 20. どのバージョンでテストする？ システム ロードバランサ データベースA サービスA v1.1 データベースB サービスB v1.3 データベースC サービスC v1.0 新しいBのテストしたいけ どAとCはどのバージョン想 定してテスト書いたらいい のよ？ 来週にはv1.1に あげるで～
- 22. コンシューマ駆动契约とは マイクロサービスアーキテクチャで構築されたシステムで各サービスを任意の タイミングでリリースできるようにすると、全体が結合された環境で行うテスト は非常に高価になりこの方法ですべてのユースケースをテストすることはできな くなる。 各サービスは自分がどのサービスから呼び出されているか把握することが困難 になり、互換性を壊す変更をリリース前に検出することが難しくなる。 コンシューマ駆动契约とはサービスの利用側?提供側で (状態, 入力, 出力) の組 を契約と定義し、サービス利用側(コンシューマ)が契約を結ぶことを責務とし、そ の契約を壊していないことを利用側?提供側双方でテストすることで結合環境で のテストの代替として上記の問題を解決するものである。 三苫の理解よりこれが課題です。 課 題
- 23. どうすればいいのか？
- 24. 歯を食いしばってやろう ? こういうのは愚直にやるのが一番？ ? サービス間の関連は多対多関連 ? 負荷が指数的に増加する可能性 ? 指数的なものとそのまま戦う人は時間に殺される
- 25. クライアントライブラリは 自動生成の時代！ ? クライアントライブラリを Swagger や Open API Generator で自動生成して提供すれば 形式不正なAPI呼び出しはなくせるのでは？ ? そういう話ではない。 ? 互換性の崩れた古いクライアントライブラリを 意図せず使い続けられたら結局困る。
- 27. 不十分なテストで本番に突っ込んで 異常検知したら取り下げる ? これはこれでアリ (^_-)-☆ ? 程度の差はあれ十分なテスト（≒障害の芽をすべて摘 む）とは幻想なので、大なり小なりすべてのチームが 採用している方針 ? ここに至るまでどこまで手を尽くせるかという話
- 28. コンシューマ駆动契约
- 30. APIの通信をテストするための情報 ? サービスの状態(State) ? 入力(Request) ? 出力(Response) サービスA サービスB State : ID=12345でuser=三苫が登録されている Request : GET /v1/users/12345 Response : {“name”: “三苫 亮”}
- 31. APIの通信をテストするための情報 ? サービスの状態(State) ? 入力(Request) ? 出力(Response) サービスA サービスB State : ID=12345でuser=三苫が登録されている Request : GET /v1/users/12345 Response : {“name”: “三苫 亮”} これを契約と定義する
- 33. 契約にメタ情報を付与してDB化してみる 利用者 : サービスB (version:1.0.0) 提供者 : サービスA (version:2.0.0) State : ID=12345でuser=三苫が登録されている Request : GET /v1/users/12345 Response : {“name”: “三苫 亮”} 契約 契約 契約
- 34. 利用側モック 提供側が守るべき契約をDBに 問い合わせできる サービスA サービスB 提供側モック 契約 契約 契約 守ってほしい契約を利用側が作ってDBに登録 守るべき契約を提供側がDBから読み込む
- 36. コンシューマ駆动契约とは マイクロサービスアーキテクチャで構築されたシステムで各サービスを任意の タイミングでリリースできるようにすると、全体が結合された環境で行うテスト は非常に高価になりこの方法ですべてのユースケースをテストすることはできな くなる。 各サービスは自分がどのサービスから呼び出されているか把握することが困難 になり、互換性を壊す変更をリリース前に検出することが難しくなる。 コンシューマ駆动契约とはサービスの利用側?提供側で (状態, 入力, 出力) の組 を契約と定義し、サービス利用側(コンシューマ)が契約を結ぶことを責務とし、そ の契約を壊していないことを利用側?提供側双方でテストすることで結合環境で のテストの代替として上記の問題を解決するものである。 三苫の理解よりこれで解決！ 解 決
- 37. ここで用語を整理 ? APIの提供側→プロバイダ ? APIの利用側→コンシューマ ? APIの仕様の合意→契約 ? 利用側が起点となって提供側と契約する →コンシューマ駆动契约 ? コンシューマ駆动契约 →Consumer Driven Contract →CDC
- 38. CDCは何を解決しないか ? 契約していないサービスの互換性の保証 ? 契約は全サービスが行わないとあまり意味がない ? 契約が壊れた時のチーム間コミュニケーション ? 問題を検出するまでが範囲 ? APIの実際の動作の保証 ? インターフェイスが壊れていない事だけ保証する ? サービス間の実際の疎通 ? 全体の結合テストを価値の高いユースケースに 絞って作る必要はある ? テストピラミッドの考え方
- 39. サイボウズの事例
- 40. kintone ? 業務改善プラットフォーム ? 業務アプリを簡単に作る ? ストック＆フローの データを貯めていける
- 41. Yakumoプロジェクト ? kintone を自社DCからAWSに移行するプロジェクト ? US向け ? 詳しくはこちら↓ ? /teppeis/kintone-awsdvopsqa-111906067 ? kintone は元からマイクロサービス的な構成 ? 自作ミドルウェアが複数あり HTTPリクエストを投げている ? 自作ミドルウェアをAWSに最適化したものに再実装する 過程で全体結合したテストを行うのが難しくなり コンシューマ駆动契约を実践することに
- 43. コンシューマ駆动契约を実現するツール ? Pact ? https://docs.pact.io/ ? もともとは Ruby で書かれた コンシューマ駆动契约を実現するためのツール ? 契約を JSON 形式の Pact ファイルで表現する ? 特定の言語依存がない ? 今では多くの言語で Pact ファイルを用いた CDC テストができる ? Yakumo では Java, kotlin, Go でテストを書いている
- 45. xUnit コンシューマ側 ? プロバイダーにアクセスするクライアントの 単体テストを Pact を使って実装 ? Pactでモックサーバーを立ち上げて単体テストする テスト対象の クライアント Pactによる モックサーバー
- 47. プロバイダ側のテストは誰が書く？ ? 今のところコンシューマ側のテストを書いた人が プロバイダ側のテストも対応する ? 使いまわせる State が増えると プロバイダ側の対応は不要になってくる
- 48. 課題 ? 今は契約のJSON(Pact file)はモノリポジトリに ファイルとして置いてあるだけ ? 契約をDB(Pact Broker)においてバージョンを指定して テストできるようにするのはこれから ? サービスの状態(State)を表す語彙が チームで標準化されていない ? “normal state” とか “has one queue” とか曖昧な 言葉でしか定義されていない
- 49. まとめ ? コンシューマ駆动契约を導入することで サービスを結合せずに確認できる範囲を 増やすことができる ? 万能ではないし結合して実施するテストが 全く不要というわけでもない ? サイボウズも Yakumo というプロジェクトで Pact を活用してやっていってるゾ！
- 50. 参考 ? Pact ? https://docs.pact.io/ ? pact-jvmではじめるコンシューマー駆動契約 ? /setoazusa/pact-for-jvm ? 運用中のサービス間の堅牢性をあげるために Pact導入を試みた話 ? https://developers.freee.co.jp/entry/introduction-of-pact ? 実践 Pact:マイクロサービス時代のテストツール ? https://techlife.cookpad.com/entry/2016/06/28/164247