Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018

14,578 views

Published on

2018年11月2日に行われたAWS Dev Day Tokyo 2018での講演「マイクロサービス化デザインパターン」の資料です。

Published in: Technology
  • Be the first to comment

マイクロサービス化デザインパターン - #AWSDevDay Tokyo 2018

  1. 1. マイクロサービス化デザインパターン 2018/11/02 鈴木雄介 Graat 代表 日本Javaユーザーグループ 会長 AWS Dev Day Tokyo 2018
  2. 2. 自己紹介 鈴木雄介 • Graat(グラーツ) » グロース・アーキテクチャ&チームス株式会社 » 代表取締役 社長 » http://www.graat.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. 本セッションについて • マイクロサービス”化”デザインパターン »NOT 「マイクロサービスデザインパターン」 • 想定している聴講者 »現状の資産を、どうやってマイクロサービス化していくのか?に 悩んでいる方 »マイクロサービスを始めたものの、どこから手を付けるべきか、 悩んでいる方 2
  4. 4. アジェンダ • マイクロサービスとは • マイクロサービス化の観点 • マイクロサービス化の導入プロセス • まとめ 3
  5. 5. マイクロサービスとは 4
  6. 6. マイクロサービスとは 目的:システム全体の変更速度を上げる • ユーザーからのフィードバックを早く反映する 5 ユーザー 企画 実装 運用
  7. 7. マイクロサービスとは アジャイル(2001年) • 小さなチームによるタイムボックス型管理 »「大きな計画」の限界 ▸予測精度が低い、進捗が管理しきれない、PMに依存する »「小さな計画を繰り返し立案する」というアイデア ▸予測範囲を狭める、動くソフトウェアで確認する、チームで解決する • 課題:Monolithicではうまくいかない »複数チーム間の調整コストが高くなる 6 利用 企画 実装 運用
  8. 8. マイクロサービスとは Monolithic • 巨大な一枚岩のシステム »機能同士がメソッド呼び出しやデータを通じて密結合になってお り、機能間の依存関係も不透明 • 結果として、一部の変更が全体に波及する »影響調査、リグレッションテスト、リリース調整などのオーバー ヘッドが発生 »稼働状態では特定機能の性能劣化が全体に波及 7
  9. 9. マイクロサービスとは クラウド(2006年~)/DevOps(2009年~) • クラウド=インフラとミドルウェアのソフトウェア化 »サーバ環境を構築する手順がコード化できる • DevOps=開発と運用の協業 »必要な処理をコードにまとめ、自動化する ▸Chef、Puppet、Ansible... »様々な情報共有 ▸デプロイ、バージョン、メトリクスなど 8 利用 企画 実装 運用
  10. 10. マイクロサービスとは NoOps(2011年~) • NoOps=運用作業込みでのプラットフォーム化 »運用機能込みでアプリケーションの稼働環境をプラットフォーム 化してしまう »代表的なのはブルーグリーンデプロイメント(無停止リリース) • Webアプリ用PaaSの興隆 »AWS Elastic Beanstalk(2011年~) »Cloud Foundry、OpenShift… 9 利用 企画 実装 運用
  11. 11. マイクロサービスとは Microservices(2014年~) • システム全体を「サービス単位」で変更していく »サービスのリリース/切り戻しは自動化され無停止で実施可能 »チームをまたがる影響調査やリリース調整は不要 • マイクロサービス=アジャイル+DevOps/NoOps »目的:システム全体の変更速度を上げる 10 利用 企画 実装 運用
  12. 12. マイクロサービスとは Cloud Native Architecture(2017年~) • ものすごく沢山のノードを管理する »複雑化したサービス群を管理するためのツールを利用 ▸コンテナオーケストレーション: Kubernetes、Amazon ECS/EKS ▸サービスメッシュ:Istio • まさに現在進行形の領域 »「Cloud Native」ではない名前になると思われる 11
  13. 13. マイクロサービス化の観点 12
  14. 14. マイクロサービス化の観点 誰も最初はマイクロサービスではなかった • 先端企業だってマイクロサービス化していった »Netflixは2008年からAWS化し、自動化をしながら足りない管理 機能を開発してきた »2011年ぐらいに「マイクロサービス」と名付けられただけ • マイクロサービスまで至る歴史をたどるべき »アジャイル→DevOps→NoOps→Microsrvices→Cloud Native »アジャイルやDevOpsを飛ばしてMicrosrvicesは無理 13
  15. 15. マイクロサービス化の観点 アジャイル化 • それぞれのチームが好きなタイミングでリリースする »大きな計画の中で同期をとって開発していくならMonolithicのほ うが効率が良い。分割にはオーバーヘッドが伴う • チームサイズは5-9名が理想 »サービスはチームが扱える大きさであるべき ▸1チームで複数サービスを管理することは問題なし • XPの開発プラクティスは基本 »テスト駆動開発、ペアプロ(モブ)、リファクタリング、ソース コードの共同所有、継続的インテグレーション、YAGNI 14
  16. 16. マイクロサービス化の観点 運用の自動化 • 運用作業が自動化/ツール化された状態 »それを開発するのはDevOpsエンジニア/SREエンジニア »インフラ・運用担当者の新たな役割 »単純な運用作業/オペレーターは不要 • 開発者はツールを使ってコードを稼働させる »「アプリを作る」から「サービスを動かす」へ »非機能要件も意識するようになる 15
  17. 17. マイクロサービス化の観点 プラットフォーム化 • 運用作業を織り込んだプラットフォーム »WebアプリPaaSなどは最初から可用性を備える • サービスを支えるプラットフォーム »サービスの数が増えてきても疎に連携できる基盤 • サービスを管理するプラットフォーム »増えたサービスを管理し、自動化する基盤 16
  18. 18. マイクロサービス化の導入ステップ 17
  19. 19. マイクロサービス化の導入ステップ 段階を経て進めていく • Step1:最初のサービスを分割する »Monolithicからサービスを切り出していく • Step2:サービス基盤を整備する »サービスを増やしていくための基盤を整備する • Step3:サービスを管理する »数が多くなってきたサービスそのものの管理を自動化していく 18
  20. 20. マイクロサービス化の導入ステップ Step1 19
  21. 21. Step1 方針 • 最初のサービスを切り出す »サービスとのWebAPI連携 »URLベースの書き換え »共有メモリでの認証情報共有 »共有データベース »PaaSの利用 20
  22. 22. Step1 最初のサービスを切り出す • 分割は「リリースサイクルを早めたい場所」 »まずはビジネス視点で整理を行う ▸変更要求が多いところ ▸複数の機能を横断する場合があるため注意して整理 »そのうえで制約条件を整理し、分けられるポイントを探る »サイズはチーム(3名~9名)でメンテできるかどうか 21
  23. 23. Step1 サービスとのWebAPI連携 • サービスをWebAPIで同期呼び出しする »メリット:既存の延長で拡張できる ▸認証認可などを考慮外にできる »デメリット:適用できるケースが多くない ▸改修が発生するポイントが新サービス部分に寄るのであれはOK 22 新サービス システム 一部改修
  24. 24. Step1 URLベースの置き替え • URLベースで一部の処理を新サービスに置き換える »メリット:旧システムの手術リスクを回避、新サービスのFW自由 »デメリット:URLベースですり替えが可能な場合に限る ▸例:ECサイトの一部機能を置き換える 23 システム 新サービス 早めたい システム 廃止/aaa/ /bbb/ /aaa/ /bbb/ URL置き換え現状 ルーター ルーター
  25. 25. Step1 共有メモリでの認証情報共有 • セッション情報をバックエンドの共有メモリへ »メリット:認証機構にほぼ変更が不要 »デメリット:セッション情報の形式によっては言語縛り ▸※既存がDBであれば、そのままDBでもよし 24 新サービス システム 廃止 共有 メモリ ログイン処理セッション ElastiCache
  26. 26. DB Step1 共有データベース • データの分割は避け、共有データベースから »メリット:コスト最適化 »デメリット:データベースに関する変更では同期が必要 ▸Read Onlyな部分はview化すると変更影響を抑えられる 25 新サービス システム 廃止 新サービス システム 廃止 テーブル共有 ビュー経由共有
  27. 27. Step1 PaaSの利用 • 新サービスにはWebアプリPaaSを採用 »メリット:運用作業が自動化される ▸リリース、障害復旧、ミドルウェアアップデート、 ▸操作は手動でもいいし、時間があればCI/CD »デメリット:PaaSの制約に従う必要がある ▸既存システムとのギャップが大きく運用できるかは課題あり 26 新サービス システム 廃止 EC2 EB RDS ElastiCache Git CodePipeline
  28. 28. Step1 ポイント • サービスの分割点はビジネス視点で決定すること »制約の範囲で最適な範囲を見つける • 技術的に無理しすぎない »全部ではなく、部分的に新しいものをいれる »新しい概念が必要な技術へのチャレンジは慎重に ▸コンテナ、NoSQL、サーバレス… »実際には運用周りでの変更をどこまで救えるかが重要 27
  29. 29. マイクロサービス化の導入ステップ Step2 28
  30. 30. Step2 方針 • サービスが増えてもサービス間を疎に保つ基盤づくり »認証のSSO化 »ログ基盤 »非同期キューの導入 »DBインスタンスの分離 »環境設定の外部注入 29
  31. 31. Step2 認証のSSO化 • 認証をSSOに変更する(OpenID Connectなど) »メリット:サービスが増えることに対応しやすくなる ▸ユーザー情報として既存テーブルを利用可能することもOK »デメリット:既存システムも認証基盤の変更が必要 30 DB ユーザー 新サービス システム 廃止 SSO基盤 新サービス
  32. 32. ログ基盤の導入 • ログを基盤側に送信して管理する »メリット:ノード数に非依存、イベントフックによる自動化 ▸ログにユーザーキーを付けることで抽出可能にしておく »デメリット:特になし Step2 31 新サービス システム 廃止 新サービス Kinesis Firehose Kinesis Streams ※イベントをフックして 自動通知などに展開可能 ログ基盤
  33. 33. Step2 非同期キューの導入 • サービス間の連携に非同期処理を導入 »メリット:サービス同士を疎結合に連携 ▸性能面でも仕様面でも安定する。ECサイトの受注処理など »デメリット:非同期ゆえ、後続処理での問題発生がありえる ▸サービスAはOKを返しているのに、サービスBでNGの場合のリカバリ 32 サービスA キュー 基盤 キューサービスB SQS
  34. 34. ETL基盤 Step2 DBインスタンスの分離 • データベースを分離する »メリット:データベースの疎結合化 ▸トリガー、ストアドなどによりインスタンス間コピー ▸マスタなどはETLによる連携 »デメリット:データの不整合の発生 33 新サービス システム 廃止 インスタンス間コピー 新サービス システム 廃止 ETL
  35. 35. Step2 環境設定の外部注入 • 環境に依存する設定情報はランタイムに取得させる »メリット:環境によってビルド結果が変わらない ▸一度作ったビルド済みファイルがすべての環境で使えるように »デメリット:設定サーバが必要になる 34 新サービス システム 廃止 新サービス ログ基盤 設定 サーバ
  36. 36. Step2 ポイント • サービスの数を増やしていくことができるようにする »基盤として整備をしておかないと、あとで問題になる »儲からないが、やっておかないといけないこと »マイグレーションの場合、PaaSだけでは対応しきれない • 分割と集約のバランスを考える »サービス間を疎結合にできないなら分割すべきではない »キュー、Lambdaのようなものをピンポイントで利用する 35
  37. 37. マイクロサービス化の導入ステップ Step3 36
  38. 38. Step3 方針 • さらに大量のノードを管理するための基盤づくり »コンテナの導入 »バッチサーバの廃止 »コンテナオーケストレーターの導入 »サービスメッシュの導入 »イベントソーシング 37
  39. 39. Step3 アプリケーションのコンテナ対応 • コンテナによってアプリの実行環境をパッケージ化 »メリット:ミドルウェアの管理がアプリと同期 ▸PaaSの制約に縛られない構成が可能。代表的なものはDocker ▸ミドルウェアの設定が楽。アップデートも楽に。 »デメリット:CI/CD必須 38 OS アプリケーション ネットワーク構成 ミドルウェア設定 git ネットワーク設定 ミドルウェア設定 OS アプリケーションgit
  40. 40. ジョブジョブ Step3 バッチサーバの廃止 • バッチアプリを起動するタイミングでノードを手配する »メリット:バッチアプリ単位で最適化が可能 ▸性能(スケールアウト/アップ)、起動時間 »デメリット:管理が面倒 39 バッチ サーバ バッチ サーバ バッチ サーバ ジョブ ジョブジョブ ジョブ ジョブジョブ バッチ サーバ バッチ サーバ バッチ サーバ
  41. 41. Step3 コンテナオーケストレーターの導入 • コンテナ化されたアプリの管理を自動化する »メリット:アプリの起動制御が自動化 ▸ECS、EKSなど »デメリット:管理が面倒 ▸それなりのノード数でないと管理コストに見合わない可能性も 40 コンテナ オーケストレーター コンテナ コンテナ コンテナ サーバ コンテナ サーバ コンテナ サーバ コンテナ 設定情報
  42. 42. Step3 サービスメッシュの導入 • サービス間メッセージのルーティング管理を行う »メリット:ノードの状況を管理し、ルートを設定 ▸ノード個別のサーキットブレーカーなどを不要に ▸ESBを分散管理型にし、ルーティングのみに特化 41 新サービス 新サービス サービスメッシュ プロキシ プロキシ
  43. 43. Step3 イベントソーシングの導入 • データのステートではなく、変更イベントを共有する »メリット:データ構造の共有から離れることができる ▸どんなステートに対して処理すべきかだけわかっていればいい »デメリット:複雑 42 新サービス システム 廃止 イベントソーシング ストリーム イベント フック
  44. 44. Step3 ポイント • 大量になってきたサービスをいかに管理するのか? »この分野は現在進行形なので、まだまだ未成熟な領域 »数年で落ち着いてくるはず • 導入が早すぎると管理コストばかりがかかる »いわゆるオーバーキル問題 »コンテナだけは早めでもいい 43
  45. 45. まとめ 44
  46. 46. マイクロサービスとは Microservices(2014年~) • システム全体を「サービス単位」で変更していく »サービスのリリース/切り戻しは自動化され無停止で実施可能 »チームをまたがる影響調査やリリース調整は不要 • マイクロサービス=アジャイル+DevOps/NoOps »目的:システム全体の変更速度を上げる 45 利用 企画 実装 運用
  47. 47. マイクロサービス化の観点 誰も最初はマイクロサービスではなかった • 先端企業だってマイクロサービス化していった »Netflixは2008年からAWS化し、自動化をしながら足りない管理 機能を開発してきた »2011年ぐらいに「マイクロサービス」と名付けられただけ • マイクロサービスまで至る歴史をたどるべき »アジャイル→DevOps→NoOps→Microsrvices→Cloud Native »アジャイルやDevOpsを飛ばしてMicrosrvicesは無理 46
  48. 48. マイクロサービス化の導入ステップ 段階を経て進めていく • Step1:最初のサービスを分割する »Monolithicからサービスを切り出していく • Step2:サービス基盤を整備する »サービスを増やしていくための基盤を整備する • Step3:サービスを管理する »数が多くなってきたサービスそのものの管理を自動化していく 47
  49. 49. さいごに 明日からマイクロサービス化をはじめよう! • マイクロサービス”化”であることを理解する »いきなり完成形を目指すのでなくStep by Stepで • 目の前の課題が、その技術で解決すべき課題が考える »技術を先に決めるとオーバーキルになりがち • マイクロサービス化プロセスがチームを育てる »最初からできる人を望むのではなく、段階的に成長してもらう 48

×