Movatterモバイル変換

マイクロサービス化デザインパターン2018/11/02鈴木雄介Graat 代表日本Javaユーザーグループ会長AWS Dev Day Tokyo 2018

自己紹介鈴木雄介• Graat（グラーツ）» グロース・アーキテクチャ＆チームス株式会社» 代表取締役社長» http://www.graat.co.jp/• 日本Javaユーザーグループ» 会長» http://www.java-users.jp/• SNS» http://arclamp.hatenablog.com/» @yusuke_arclamp1

本セッションについて• マイクロサービス”化”デザインパターン»NOT 「マイクロサービスデザインパターン」• 想定している聴講者»現状の資産を、どうやってマイクロサービス化していくのか？に悩んでいる方»マイクロサービスを始めたものの、どこから手を付けるべきか、悩んでいる方2

アジェンダ• マイクロサービスとは• マイクロサービス化の観点• マイクロサービス化の導入プロセス• まとめ3

マイクロサービスとは4

マイクロサービスとは目的：システム全体の変更速度を上げる• ユーザーからのフィードバックを早く反映する5ユーザー企画実装運用

マイクロサービスとはアジャイル（2001年）• 小さなチームによるタイムボックス型管理»「大きな計画」の限界▸予測精度が低い、進捗が管理しきれない、PMに依存する»「小さな計画を繰り返し立案する」というアイデア▸予測範囲を狭める、動くソフトウェアで確認する、チームで解決する• 課題：Monolithicではうまくいかない»複数チーム間の調整コストが高くなる6利用企画実装運用

マイクロサービスとはMonolithic• 巨大な一枚岩のシステム»機能同士がメソッド呼び出しやデータを通じて密結合になっており、機能間の依存関係も不透明• 結果として、一部の変更が全体に波及する»影響調査、リグレッションテスト、リリース調整などのオーバーヘッドが発生»稼働状態では特定機能の性能劣化が全体に波及7

マイクロサービスとはクラウド（2006年～）/DevOps（2009年～）• クラウド＝インフラとミドルウェアのソフトウェア化»サーバ環境を構築する手順がコード化できる• DevOps＝開発と運用の協業»必要な処理をコードにまとめ、自動化する▸Chef、Puppet、Ansible...»様々な情報共有▸デプロイ、バージョン、メトリクスなど8利用企画実装運用

マイクロサービスとはNoOps（2011年～）• NoOps=運用作業込みでのプラットフォーム化»運用機能込みでアプリケーションの稼働環境をプラットフォーム化してしまう»代表的なのはブルーグリーンデプロイメント（無停止リリース）• Webアプリ用PaaSの興隆»AWS Elastic Beanstalk（2011年～）»Cloud Foundry、OpenShift…9利用企画実装運用

マイクロサービスとはMicroservices（2014年～）• システム全体を「サービス単位」で変更していく»サービスのリリース/切り戻しは自動化され無停止で実施可能»チームをまたがる影響調査やリリース調整は不要• マイクロサービス＝アジャイル＋DevOps/NoOps»目的：システム全体の変更速度を上げる10利用企画実装運用

マイクロサービスとはCloud Native Architecture（2017年～）• ものすごく沢山のノードを管理する»複雑化したサービス群を管理するためのツールを利用▸コンテナオーケストレーション： Kubernetes、Amazon ECS/EKS▸サービスメッシュ：Istio• まさに現在進行形の領域»「Cloud Native」ではない名前になると思われる11

マイクロサービス化の観点12

マイクロサービス化の観点誰も最初はマイクロサービスではなかった• 先端企業だってマイクロサービス化していった»Netflixは2008年からAWS化し、自動化をしながら足りない管理機能を開発してきた»2011年ぐらいに「マイクロサービス」と名付けられただけ• マイクロサービスまで至る歴史をたどるべき»アジャイル→DevOps→NoOps→Microsrvices→Cloud Native»アジャイルやDevOpsを飛ばしてMicrosrvicesは無理13

マイクロサービス化の観点アジャイル化• それぞれのチームが好きなタイミングでリリースする»大きな計画の中で同期をとって開発していくならMonolithicのほうが効率が良い。分割にはオーバーヘッドが伴う• チームサイズは5-9名が理想»サービスはチームが扱える大きさであるべき▸1チームで複数サービスを管理することは問題なし• XPの開発プラクティスは基本»テスト駆動開発、ペアプロ（モブ）、リファクタリング、ソースコードの共同所有、継続的インテグレーション、YAGNI14

マイクロサービス化の観点運用の自動化• 運用作業が自動化/ツール化された状態»それを開発するのはDevOpsエンジニア/SREエンジニア»インフラ・運用担当者の新たな役割»単純な運用作業/オペレーターは不要• 開発者はツールを使ってコードを稼働させる»「アプリを作る」から「サービスを動かす」へ»非機能要件も意識するようになる15

マイクロサービス化の観点プラットフォーム化• 運用作業を織り込んだプラットフォーム»WebアプリPaaSなどは最初から可用性を備える• サービスを支えるプラットフォーム»サービスの数が増えてきても疎に連携できる基盤• サービスを管理するプラットフォーム»増えたサービスを管理し、自動化する基盤16

マイクロサービス化の導入ステップ17

マイクロサービス化の導入ステップ段階を経て進めていく• Step1：最初のサービスを分割する»Monolithicからサービスを切り出していく• Step2：サービス基盤を整備する»サービスを増やしていくための基盤を整備する• Step3：サービスを管理する»数が多くなってきたサービスそのものの管理を自動化していく18

マイクロサービス化の導入ステップStep119

Step1方針• 最初のサービスを切り出す»サービスとのWebAPI連携»URLベースの書き換え»共有メモリでの認証情報共有»共有データベース»PaaSの利用20

Step1最初のサービスを切り出す• 分割は「リリースサイクルを早めたい場所」»まずはビジネス視点で整理を行う▸変更要求が多いところ▸複数の機能を横断する場合があるため注意して整理»そのうえで制約条件を整理し、分けられるポイントを探る»サイズはチーム（3名～9名）でメンテできるかどうか21

Step1サービスとのWebAPI連携• サービスをWebAPIで同期呼び出しする»メリット：既存の延長で拡張できる▸認証認可などを考慮外にできる»デメリット：適用できるケースが多くない▸改修が発生するポイントが新サービス部分に寄るのであれはOK22新ｻｰﾋﾞｽシステム一部改修

Step1URLベースの置き替え• URLベースで一部の処理を新サービスに置き換える»メリット：旧システムの手術リスクを回避、新サービスのFW自由»デメリット：URLベースですり替えが可能な場合に限る▸例：ECサイトの一部機能を置き換える23システム新ｻｰﾋﾞｽ早めたいシステム廃止/aaa//bbb//aaa//bbb/URL置き換え現状ﾙｰﾀｰﾙｰﾀｰ

Step1共有メモリでの認証情報共有• セッション情報をバックエンドの共有メモリへ»メリット：認証機構にほぼ変更が不要»デメリット：セッション情報の形式によっては言語縛り▸※既存がDBであれば、そのままDBでもよし24新ｻｰﾋﾞｽシステム廃止共有メモリログイン処理ｾｯｼｮﾝElastiCache

DBStep1共有データベース• データの分割は避け、共有データベースから»メリット：コスト最適化»デメリット：データベースに関する変更では同期が必要▸Read Onlyな部分はview化すると変更影響を抑えられる25新ｻｰﾋﾞｽシステム廃止新ｻｰﾋﾞｽシステム廃止テーブル共有ビュー経由共有

Step1PaaSの利用• 新サービスにはWebアプリPaaSを採用»メリット：運用作業が自動化される▸リリース、障害復旧、ミドルウェアアップデート、▸操作は手動でもいいし、時間があればCI/CD»デメリット：PaaSの制約に従う必要がある▸既存システムとのギャップが大きく運用できるかは課題あり26新ｻｰﾋﾞｽシステム廃止EC2EBRDSElastiCacheGit CodePipeline

Step1ポイント• サービスの分割点はビジネス視点で決定すること»制約の範囲で最適な範囲を見つける• 技術的に無理しすぎない»全部ではなく、部分的に新しいものをいれる»新しい概念が必要な技術へのチャレンジは慎重に▸コンテナ、NoSQL、サーバレス…»実際には運用周りでの変更をどこまで救えるかが重要27

Step2方針• サービスが増えてもサービス間を疎に保つ基盤づくり»認証のSSO化»ログ基盤»非同期キューの導入»DBインスタンスの分離»環境設定の外部注入29

Step2認証のSSO化• 認証をSSOに変更する（OpenID Connectなど）»メリット：サービスが増えることに対応しやすくなる▸ユーザー情報として既存テーブルを利用可能することもOK»デメリット：既存システムも認証基盤の変更が必要30DBﾕｰｻﾞｰ新ｻｰﾋﾞｽシステム廃止SSO基盤新ｻｰﾋﾞｽ

ログ基盤の導入• ログを基盤側に送信して管理する»メリット：ノード数に非依存、イベントフックによる自動化▸ログにユーザーキーを付けることで抽出可能にしておく»デメリット：特になしStep231新ｻｰﾋﾞｽシステム廃止新ｻｰﾋﾞｽKinesis FirehoseKinesis Streams※イベントをフックして自動通知などに展開可能ログ基盤

Step2非同期キューの導入• サービス間の連携に非同期処理を導入»メリット：サービス同士を疎結合に連携▸性能面でも仕様面でも安定する。ECサイトの受注処理など»デメリット：非同期ゆえ、後続処理での問題発生がありえる▸サービスAはOKを返しているのに、サービスBでNGの場合のリカバリ32ｻｰﾋﾞｽAキュー基盤ｷｭｰｻｰﾋﾞｽBSQS

ETL基盤Step2DBインスタンスの分離• データベースを分離する»メリット：データベースの疎結合化▸トリガー、ストアドなどによりインスタンス間コピー▸マスタなどはETLによる連携»デメリット：データの不整合の発生33新ｻｰﾋﾞｽシステム廃止インスタンス間コピー新ｻｰﾋﾞｽシステム廃止ETL

Step2環境設定の外部注入• 環境に依存する設定情報はランタイムに取得させる»メリット：環境によってビルド結果が変わらない▸一度作ったビルド済みファイルがすべての環境で使えるように»デメリット：設定サーバが必要になる34新ｻｰﾋﾞｽシステム廃止新ｻｰﾋﾞｽログ基盤設定サーバ

Step2ポイント• サービスの数を増やしていくことができるようにする»基盤として整備をしておかないと、あとで問題になる»儲からないが、やっておかないといけないこと»マイグレーションの場合、PaaSだけでは対応しきれない• 分割と集約のバランスを考える»サービス間を疎結合にできないなら分割すべきではない»キュー、Lambdaのようなものをピンポイントで利用する35

Step3方針• さらに大量のノードを管理するための基盤づくり»コンテナの導入»バッチサーバの廃止»コンテナオーケストレーターの導入»サービスメッシュの導入»イベントソーシング37

Step3アプリケーションのコンテナ対応• コンテナによってアプリの実行環境をパッケージ化»メリット：ミドルウェアの管理がアプリと同期▸PaaSの制約に縛られない構成が可能。代表的なものはDocker▸ミドルウェアの設定が楽。アップデートも楽に。»デメリット：CI/CD必須38OSアプリケーションネットワーク構成ミドルウェア設定gitネットワーク設定ミドルウェア設定OSアプリケーションgit

ジョブジョブStep3バッチサーバの廃止• バッチアプリを起動するタイミングでノードを手配する»メリット：バッチアプリ単位で最適化が可能▸性能（スケールアウト/アップ）、起動時間»デメリット：管理が面倒39バッチサーババッチサーババッチサーバジョブジョブジョブジョブジョブジョブバッチサーババッチサーババッチサーバ

Step3コンテナオーケストレーターの導入• コンテナ化されたアプリの管理を自動化する»メリット：アプリの起動制御が自動化▸ECS、EKSなど»デメリット：管理が面倒▸それなりのノード数でないと管理コストに見合わない可能性も40コンテナオーケストレーターコンテナコンテナコンテナサーバコンテナサーバコンテナサーバコンテナ設定情報

Step3サービスメッシュの導入• サービス間メッセージのルーティング管理を行う»メリット：ノードの状況を管理し、ルートを設定▸ノード個別のサーキットブレーカーなどを不要に▸ESBを分散管理型にし、ルーティングのみに特化41新ｻｰﾋﾞｽ新ｻｰﾋﾞｽサービスメッシュﾌﾟﾛｷｼﾌﾟﾛｷｼ

Step3イベントソーシングの導入• データのステートではなく、変更イベントを共有する»メリット：データ構造の共有から離れることができる▸どんなステートに対して処理すべきかだけわかっていればいい»デメリット：複雑42新ｻｰﾋﾞｽシステム廃止イベントソーシングストリームイベントフック

Step3ポイント• 大量になってきたサービスをいかに管理するのか？»この分野は現在進行形なので、まだまだ未成熟な領域»数年で落ち着いてくるはず• 導入が早すぎると管理コストばかりがかかる»いわゆるオーバーキル問題»コンテナだけは早めでもいい43

マイクロサービスとはMicroservices（2014年～）• システム全体を「サービス単位」で変更していく»サービスのリリース/切り戻しは自動化され無停止で実施可能»チームをまたがる影響調査やリリース調整は不要• マイクロサービス＝アジャイル＋DevOps/NoOps»目的：システム全体の変更速度を上げる45利用企画実装運用

マイクロサービス化の観点誰も最初はマイクロサービスではなかった• 先端企業だってマイクロサービス化していった»Netflixは2008年からAWS化し、自動化をしながら足りない管理機能を開発してきた»2011年ぐらいに「マイクロサービス」と名付けられただけ• マイクロサービスまで至る歴史をたどるべき»アジャイル→DevOps→NoOps→Microsrvices→Cloud Native»アジャイルやDevOpsを飛ばしてMicrosrvicesは無理46

マイクロサービス化の導入ステップ段階を経て進めていく• Step1：最初のサービスを分割する»Monolithicからサービスを切り出していく• Step2：サービス基盤を整備する»サービスを増やしていくための基盤を整備する• Step3：サービスを管理する»数が多くなってきたサービスそのものの管理を自動化していく47

さいごに明日からマイクロサービス化をはじめよう！• マイクロサービス”化”であることを理解する»いきなり完成形を目指すのでなくStep by Stepで• 目の前の課題が、その技術で解決すべき課題が考える»技術を先に決めるとオーバーキルになりがち• マイクロサービス化プロセスがチームを育てる»最初からできる人を望むのではなく、段階的に成長してもらう48

Movatterモバイル変換

Change Language

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

Embed presentation

Recommended

More Related Content

What's hot

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

More from Yusuke Suzuki

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