〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！

Size: px

Start display at page:

Download "〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！"

ああすほがり
5 years ago
Views:

1 AWS Dev Day Tokyo 2017 マイクロサービスを設計するすべての開発者に送るクラウド時代のマイクロサービス設計徹底解説! グロースエクスパートナーズ株式会社 2017/5/31 鈴木雄介日本 Java ユーザーグループ執行役員会長

2 AWS Dev Day Tokyo 2017 マイクロサービス化設計入門マイクロサービスを設計するすべての開発者に送るクラウド時代のマイクロサービス設計徹底解説! グロースエクスパートナーズ株式会社 2017/5/31 鈴木雄介日本 Java ユーザーグループ執行役員会長

自己紹介鈴木雄介グロースエクスパートナーズ ( 株 )» 執行役員 / アーキテクチャ事業本部長» http://www.gxp.co.

3 自己紹介鈴木雄介グロースエクスパートナーズ ( 株 )» 執行役員 / アーキテクチャ事業本部長» 日本 Java ユーザーグループ» 会長» SNS» 2

4 主な対象と前提既存でモノリシックなシステムが存在»SoR 系 ( モード 1) と SoE 系 ( モード 2) のシステムが混在しそれぞれに連携しているマイクロサービスにこれから取り組む / 取り組み始めたいきなりマイクロサービス化することは技術的にも組織的にも容易ではない気がしている具体的な作り方は話しません» アイコンのみ付けてます 3

5 アジェンダなぜマイクロサービスかマイクロサービス化設計» サービス分割» メッセージング» 無停止デプロイ» レジリエンス» テスト戦略などまとめ 4

6 なぜマイクロサービスか 5

7 なぜマイクロサービスかウェブサービスの状況システム全体は巨大化していく» システム全体の中には様々な機能 (SoR/SoE) がある» それぞれが独自のライフサイクルを持っているでもビジネス環境の変化には素早く適応したい» 機能やリソースの変更を素早く無停止で行いたい 6

8 従来のアプローチモノリシックにおける戦略アプリ内の適切な機能分割設計» アプリ内を分割してコード変更の影響範囲を限定するクラス設計パターンマルチティア UI/Logic/DAO など» そのアプリを 1 つのノードとして配備しそれぞれ連携アプリインフラシステムアプリインフラシステムアプリインフラシステム 7

9 従来のアプローチモノリシックの弊害実行時の影響範囲が見えにくい» 設計時の分割だけでは実行時の依存関係を把握することは困難» 部分への性能劣化が全体に波及しやすい» 影響調査とリグレッションテストに工数を消費巨大化すると難易度があがる» 個別変更でも全体調整» 部分変更でもシステム全体をリリース 8

10 マイクロサービスのアプローチサービス化による戦略アプリを機能ごとにサービスで分割していく» サービス = 稼働状態にあるアプリケーション機能だけではなく非機能も切り分けられている» サービスは個別ノードに配備しゆるやかに連携しているサーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) サーヒス ( アフリ + インフラ ) システム全体 9

11 マイクロサービスのアプローチマイクロサービスアーキテクチャ実行時の影響範囲が限定しやすい»API を通じたサービス同士の依存関係が明確» サービスが独立しており他とは疎結合巨大化してもサービス単位で管理» サービス単位に好きなタイミングで仕様変更リソース変更ができる速さではなく独立性が重要 10

12 なぜマイクロサービスかマイクロサービス化の目的と手段システム全体が巨大になろうとも機能別に好きなタイミングで機能やリソースの変更を行いたいそこで機能をサービス化してノード分割しそれらを管理することにした» クラウドによる仮想化技術の普及が管理ノードの増加を後押し» 自動化によりインフラ構築コストを 0 にすることができる 11

13 マイクロサービス化設計 12

14 マイクロサービス化設計マイクロサービス化設計における考慮点サービス分割横断的関心事の分離データの分離メッセージング無停止デプロイレジリエンステスト戦略チーム体制 13

15 マイクロサービス化設計サービス分割 14

16 サービス分割サービスの分割はどうあるべきか? 増 : 細かく分割するほど機能単位での再利用性が高まる減 : ノード間連携のオーバーヘッドは大きく管理も難» 分散コンピューティングの限界よって適切な大きさ / 数に分割する必要がある» 先進的な企業で数百サービスマルチノード = 数千ノード 15

17 サービス分割サービスの粒度はサービスによるナノ : 0-3 人月程度の単機能な API マイクロ :3-20 人月程度で複数の API を提供 Amazon API Gateway 既存のシステム単位に近いサービス粒度» ミニ : 人月程度 3-6 人でメンテ» 中規模 : 人月程度 7-10 人がかりでメンテ» 大規模 : 中規模以上 16

18 サービス分割サービスはドメイン単位にする? ドメインとは?» ドメイン業務 ( 利用者視点での関心事のカタマリ )» 商品登録ドメイン発注ドメイン物流ドメインドメインはボトムアップで発見すべき» 実践してフィードバックによって学んでいくしかない例 : コードにして検証して改善する» ただそれだけだと辛い 17

19 サービス分割サービス観点で分割する業務や利用の観点で変更が発生する要因をくくる» 変更要因のタイミングや理由が同じモノをくくる» 同時に変更が発生するものは一緒にしておけばいい作り手の観点ではないことに注意が必要» 従来のモノリシックにおける分割とは観点が異なる例 :UI/ ロジック /DAOのような技術特性での分割もちろんサービス内部は作り手の観点でよい» ただし技術的な限界は存在する 18

20 サービス分割変更発生要因が分離しうる要素 No 要因例 1 ユーザー種コンシューマーか社内部門か 2 目的探したいか注文したいか 3 利用プロセス個別処理か一括処理か 4 利用状況 PC 利用かモバイル利用か 5 ユーザー思考容易にか細かくか 6 ビジネス要件商品登録か物流か» フロントエンド (SPA) とバックエンドの分離などはユーザー種が原因と考えることができる 19

21 サービス分割いかに技術制約を超えていくかサービス分割は分けれるものを分けるだけ» 変更の発生要因の違いは常に分割点になりうる問題は分割時の技術制約をどうするか» ここから後の話の 20

22 マイクロサービス化設計横断的関心事の分離 21

23 横断的関心事の分離横断的機能の分離わかりやすい例は認証認可ログ設定管理» 複数のサービスで共有する機能» 複数のサービスを俯瞰的に見る機能サービス分割のために横断的関心事の早期分離が必要» いわゆるプラットフォームの機能を拡充させる 22

化専用サービス化サーヒス A サーヒス B サーヒス A サーヒス B サーヒス A サーヒス

24 認証認可認証機能な段階的な移設» 共有データ :AとBの機能仕様が共有される必要がある»API 化 : サービスAにサービスBの都合が含まれる» 専用サービス化 : 横断的関心事として切り出される共有データ API 化専用サービス化サーヒス A サーヒス B サーヒス A サーヒス B サーヒス A サーヒス B 認証サーヒス Amazon Cognito RDB インメモリ AWS Directory Service 23

25 ログ基盤リクエストの分散トレースサービスをまたがったトレーサビリティの確保» リクエストやサービス間通信にIDを発行する» 各サービスからはログ基盤にログを送信する監視分析» さらにログをベースにした異常検知アクセス / メトリクス分析サーヒス A サーヒス B サーヒス C ログ基盤ログ検索ログ監視 Amazon Kinesis Amazon CloudWatch ログ分析 24

26 設定管理設計情報の集中管理環境に依存する設定情報を集中管理する» 各サービス内に設定ファイルを配置するのではなくネットワーク経由で取得する» Spring Cloud Config 設定管理サーバ 1 起動時に設定を取得サーヒス A サーヒス B サーヒス C 25

27 AWS のプラットフォーム機能 26

28 マイクロサービス化設計データの分離 27

29 データの分離データは各サービスが管理するデータをサービス間で共有することは避けるべき» テーブル構造の変更が強制的に同期されるからとはいえデータの特性や種類に応じて方式を選択»RDB の機能は有効活用ただし 2 フェーズコミットを避ける» 不整合の許容範囲を決めることが重要許容できないなら疎結合化は困難になる» メッセージングの仕組みとの組み合わせで検討 28

30 データ分離 Amazon RDS Amazon ElastiCache Amazon DynamoDB 共有データ : テーブルを共有する変更同期が必要ビュー : 参照公開前提だが変更同期が必要トリガー / ストアド : 変更同期は不要非機能同期が必要 ETL: 全て非同期になる共有データビュートリガー / ストアド ETL サーヒス A サーヒス B サーヒス A サーヒス B サーヒス A サーヒス B サーヒス A サーヒス B AWS Glue 29

31 データ分離イベントソーシング» データのステートではなくデータへのイベントを共有する非同期ではあるが時間的ズレを小さくできる»CQRS/ コマンドクエリ責務分離コマンド : 更新などのロジックを含む処理クエリ : 検索などの単純な処理イベントソーシングサーヒス A イヘントストアサーヒス B ステート 30

32 マイクロサービス化設計メッセージング 31

33 メッセージングサービス同士を連携させる RESTful API over HTTP» もっともシンプルで分かりやすい実装メッセージキューによる非同期化» 機能同士の非機能を分離することができる同期型 Amazon SQS サーヒス A サーヒス B 非同期型 Pub/Sub 型サーヒス B サーヒス A キューサーヒス B サーヒス A キューサーヒス C サーヒス D 32

34 不整合の許容 Amazon のクーポン非同期による不整合の許容» サービス間の疎結合を重視する» 運用でリカバリするほうがメリットが大きければクーポンもあり 33

35 API バージョニングサービス間のバージョン管理 1/2 URL ベース»URLにサービスのバージョンを表現してしまう» 単純で実装しやすいが古いサービスの維持が必要になる V1 GET /v1/customer/1 V2 GET /v2/customer/1 34

36 API バージョニングサービス間のバージョン管理 2/2 互換性維持» 複数バージョンの機能を維持しパラメタで判別例 :HTTP ヘッダの値 (X-Protocol-Version)» バージョン切替は返却データ形式であればMVCのビュー切替などロジックであればアダプタパターンなど V1 GET X-Protocol-Version:1 /customer/1 V2 GET X-Protocol-Version:2 /customer/1 35

37 マイクロサービス化設計無停止デプロイ 36

38 無停止デプロイ Continues Deploy コードがサービスになるまでの一連を自動化» コードチャックアウトビルドテストパッケージング» サーバ構築サーバ設定デプロイ起動起動確認チケット管理 V1.1 チケット A チケット B Git コート V1.1 AWS CodeCommit V1.1 AWS CodeBuild V1.0 サーバチャット CI/CD ツール V1.1 サーバサーハ構成レホシトリサーハ設定 AWS CodePipeline 37

39 無停止デプロイ AWS Elastic Beanstalk Elastic Load Balancing AWS CodeDeploy ブルーグリーンデプロイメント瞬断せずにリリースを行うための手法»1. 新 verを重複して構築»2. ルーティングを制御して新 verを解放»3. 旧 verを削除

40 無停止デプロイ別名 : カナリアリリースカナリア = 炭鉱で天井に吊しておく鳥» ガスは空気より軽いので一番最初に危険に気付くカナリア = 最初に新バージョンにアクセスするユーザー» 何らかの障害が発生したら切り戻しを行う» 少しの犠牲によって大部分を救うことができる 39

41 無停止デプロイ無停止スケールアップ瞬断せずにリソース増強する手法»1. 新しいインスタンスを重複して構築»2. ルーティングを制御して新しいインスタンスを解放»3. 古いインスタンスを削除

42 インテリジェントルーターサービスディスカバリとルーティング現在有効なサービスを判断するための方式» 新しく起動したサービスは自分の居場所を自分で登録する» レジストリに問合せてサービスを発見しルーティングする» Netflix Eureka Zool レジストリ 3 サービスの発見 1 自分自身の登録 2 リクエストルーターサーヒスA サーヒスA サーヒスA 41

43 マイクロサービス化設計レジリエンス 42

44 レジリエンスマイクロサービスにおける可用性障害が発生しないようにするではない» レジリエンス= 復元力» 個別サービスの障害でシステム全体が停止しないようにする» 従来の停止しない部分を積み重ねる方式は限界階層型障害を避ける事が重要サーヒス A サーヒス B サーヒス C 43

45 サーキットブレーカー自分のことは自分で守るサービス呼び出し時の異常処理対応» 障害発生時のパターン化» タイムアウト自動リトライデフォルト値値のキャッシュ例外処理記述など» Netflix hystrix Spring Retry 機能 A エラー処理サーキットフレーカー機能 B 44

46 マイクロサービス化設計テスト戦略 45

47 テスト戦略マイクロサービスにおけるテスト戦略サービス間テスト» サービス内のテストは閉じている» 他のサービスを呼び出し部分のテスト手法本番環境のテスト» レジリエンスのテスト 46

48 テスト戦略 Test Doubles» 本物を動かすのが大変なのでスタブやモックを使ってテストする» コンシューマー側でプロバイダの想定する挙動を実装しそれを使ってテストする» プロバイダの変更が発生するとモックの変更が必要になるサーヒス A サーヒス B のモック 47

49 テスト戦略ダークカナリア ( 秘密のカナリア )» 本番環境上に開発者しかアクセスできないテスト版をリリース» 本物を使ってテストする ( ただしできないものもある ) サーヒス A サーヒス B サーヒス A テスト版 48

50 テスト戦略 Consumer-Driven Contract testing» コンシューマーが要求する API 挙動を契約として定義しプロバイダが契約を検証して破壊的変更を防ぐ»pact-jvm サーヒス A サーヒス C サーヒス B 契約サーヒス B 契約サーヒス B 49

51 テスト戦略本番環境での障害注入テスト Netflix s Failure Injection Testing (FIT)» ランダムにサーバーやデータセンターに障害を発生させ障害復旧が自動的に行われることを検証» Netflix Chaos Monkey などレジリエンスの検証は本番環境でテストする» コードのテストではなくサービスのテスト 50

52 マイクロサービス化設計チーム体制 51

53 チーム体制コンウェイの法則サービス構成とチーム構成を同一にする» アーキテクチャは組織に組織はアーキテクチャにしたがう» チーム構成 =サービス構成 =ドメイン構成» チームにサービスの自治権を与えるプラットフォームを管理するチームは必要» 横断的関心事の管理チーム 52

54 まとめ 53

55 なぜマイクロサービスかマイクロサービス化の目的と手段システム全体が巨大になろうとも機能別に好きなタイミングで機能やリソースの変更を行いたいそのために機能別にサービス化を行い機能の独立性を高めていった» 機能間の依存性を管理し可能な限り疎結合にしていく 54

56 マイクロサービス化設計マイクロサービス化設計における考慮点サービス分割横断的関心事の分離データの分離メッセージング無停止デプロイレジリエンステスト戦略チーム体制 55

57 マイクロサービス化設計今日話ができていないことコンテナ (Docker)» コンテナオーケストレーション非同期ストリーム処理 Amazon ECR Amazon ECS»HTTP の限界を超えていくサーバレスマイクロサービス向けフレームワークその他もろもろ Amazon API Gateway Amazon AppStream Amazon SWF AWS Step Functions 56

58 マイクロサービス化設計マイクロサービス向けフレームワーク Spring Cloud» Spring Cloud Config» Spring Cloud Netflix»Spring Cloud Bus» Spring Cloud Cluster» Spring Cloud Consul» Spring Cloud Security» Spring Cloud Sleuth»Spring Cloud Data Flow» Spring Cloud Stream» Spring Cloud Task» Spring Cloud Zookeeper»Spring Cloud for AWS» Spring Cloud Connectors» Spring Cloud Contract 57

59 マイクロサービス化にむけて明日からでも取り組むべきサービスの分割はいまからでもできる» 今できないものが未来になってできることはない» 技術の制約を超えるには不整合の受入れが必要現時点をマイクロサービス LV1 だと捉える» 大規模サービス+ 共有データ+ETLからのスタートでよい» どこを切り出していけばいいのかを考える 58

60 マイクロサービス化にむけてマイクロサービス化成熟レベル Level 名称状況 1 ほぼモノリシック数個の大規模サービスが共有データ /ETL 連携 2 マイクロサービスの初期段階複数のサービス群が API 連携部分的なプラットフォーム提供 3 マイクロサービスプラットフォームの整備 CI/CD+ インフラ自動化インテリジェントなルーティング処理 4 高度なマイクロサービス高度なサービスやインフラの管理イベントソーシングストリーム処理 5 先進的マイクロサービスマイクロサービスに関する技術開発や OSS の提供 59

61 AWS Dev Day Tokyo 2017 マイクロサービス化設計入門 2017/5/31 鈴木雄介グロースエクスパートナーズ株式会社執行役員日本 Javaユーザーグループ会長

PowerPoint プレゼンテーション

PowerPoint プレゼンテーション NEC モバイルバックエンド基盤入門応用編 ver 7.5.0 2018 年 10 月 1 日日本電気株式会社 Push 通知クライアントへの Push 通知 : APNs / FCM Android / ios で使用可能ユーザがアプリを起動していなくてもサービス提供側からスマートフォンやタブレットにメッセージを送る仕組みモバイル機器はプラットフォーム毎に Push 通知の仕組みが提供されています