Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

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

27.776 Aufrufe

Veröffentlicht am

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

Veröffentlicht in: Technologie
  • Paid To Write? Earn up to $200/day on with simple writing jobs. ◆◆◆ http://t.cn/AieXSfKU
       Antworten 
    Sind Sie sicher, dass Sie …  Ja  Nein
    Ihre Nachricht erscheint hier

マイクロサービス化デザインパターン - #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

×