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.

要求の変化とマイクロサービスアーキテクチャ

4,251 views

Published on

要求開発アライアンスの2016年5月セミナーでの資料です。

Published in: Technology
  • Be the first to comment

要求の変化とマイクロサービスアーキテクチャ

  1. 1. 要求の変化と マイクロサービスアーキテクチャ 2016/5/17 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長 要求開発アライアンス 2016年5月セミナー #redajp
  2. 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. Agenda • 要求開発とITシステム • アジャイル • クラウドとDevOps • マイクロサービスアーキテクチャ • まとめ 2
  4. 4. 要求開発とITシステム 3
  5. 5. 要求開発宣言(抜粋) • 情報システムに対する要求は、あらかじめ存在 しているものではなく、ビジネス価値にもとづ いて「開発」されるべきものである。 • ビジネス価値を満たす要求は、直接・間接にそ の価値に関わるステークホルダー間の合意形成 を通じてのみ創り出される。 • 要求の開発は、命令統制によらず参加協調によ る継続的改善プロセスを指向すべきである。 4 2004年12月23日 すずかけ台にて
  6. 6. 現在的なテーマ SoRからSoEへ • 要求開発の意義は変化なし。ITシステムの存在 はより大きなものに • SoRからSoEへの広がり »SoR:情報を”記録”する »SoE:ユーザー同士の”関係性”を作り出す • SoEでは「ユーザーの要求が変化していく」こ とが主眼になる 5
  7. 7. サービス運営モデル 6 サービス 機能 (コード) IT サービス 価値 構造 開発 企画 運用 業務 プロ セス
  8. 8. サービス運営モデル サービス運営モデル • 利用者の満足度はサービスの利用で生まれる • サービスはITを含む包括的なものである • コードを動かしてITサービスとなる • コードは構造とプロセスに支えられる • それらには様々なステークホルダーが関わる 7
  9. 9. システム開発のこれから 「作る」から「運営する」へ • 「ITシステムを作る」から「サービスを運営す る」ことへ »サービスを運営し、価値を生み出してこそITシステ ムの価値が認められる • しかも、価値は変化していく »外部要因:競合他社のサービスや環境変化 8
  10. 10. 要求開発とITシステム 要求は変化する • 要求は価値から生まれる • 価値を最大化し続けるためには変化し続けるす るしかない • だから、要求も変化し続ける • では、ITシステムは、どう対応するのか? 9
  11. 11. 要求変化との戦い 変化との戦い • アジャイル • クラウドとDevOps • マイクロサービスアーキテクチャ 10
  12. 12. アジャイル 11
  13. 13. アジャイル プロジェクトマネジメントの基本 • 計画する:QCDSを決める • 実行する:計画従って作業する • 計測する:計画と実績のズレを測る • 調整する:ズレに対応する(QCDSの変更) ※QCDS:Quality(品質)、Cost(費用)、Delivery(期限)、Scope(機能) 12
  14. 14. アジャイル ウォーターフォールの失敗 • 計画の失敗:そもそも計画が正しくない • 実行の失敗:計画された通りに作れない • 計測の失敗:ただしく進捗を測れない • 調整の失敗:ズレがあっても調整できない 13
  15. 15. アジャイル アジャイルの考え方 • 計画:精度が出るぐらい短期にする »リソースは固定化する • 計測:動くソフトウェアで判断する • 調整:定期的に関係者全員で話し合う • 調整を重視したマネジメントスタイル »WFは計画と効率を重視している 14
  16. 16. アジャイル 変化に適応するプロセス • 「早く作る」ための手法ではない »適切なものを適切なタイミングで作るための手法 »変更が多いなら調整タイミングを増やした方が無駄 が少ない、と考える »計画精度が高いならWFのほうが無駄が少ない • 企画から開発への流れにリズムをもたらす 15
  17. 17. クラウドとDevOps 16
  18. 18. クラウド クラウドとは • 狭義: »ハードウェアの仮想化技術 • 広義: »コンピューティングリソースにおける規模の経済 »所有ではなく利用 »資産から従量課金へ 17
  19. 19. クラウド ソフトウェア化するハードウェア • SDx(ソフトウェア定義されるハードウェア) »ハードウェアの操作がソフトウェア化される »ハードウェアのコピーや自動化ができるようになる »非機能要件がコーディングできる 18
  20. 20. クラウド クラウドの類型化 19 ハードウェア ネットワーク 仮想化OS OS ミドルウェア コード 設定 データ オンプレ IaaS PaaS SaaS <ユーザーの管理範囲>
  21. 21. クラウド Platform as a Service • 特に注目すべきはPaaS • ミドルウェア+稼働状態=PaaS »OSSフレームワークは静的コンポーネント »PaaSは動的なコンポーネント • 使うことで制約を受けるが便利になる 20
  22. 22. クラウド PaaSのレベル • 低:AWS RDS »DBMS+CPU+ストレージ+バックアップ+… • 中:AWS BeansTalk »LB+APSV+監視+自動再起動+… • 高:Heroku »レポジトリ+DevOps+APSV+… 21
  23. 23. クラウド クラウドネイティブ • クラウドを前提にしてシステムを作ること »特にPaaSの活用 • クラウドの制約に従うことで効率化する »オンプレの作り方をクラウドに持ってくるのではな く、クラウドに最適化されたやり方でアプリケーシ ョンを考え直す »特に運用が楽になる 22
  24. 24. DevOps 継続的なリリースにために • 変えていきたい開発 vs 安定させたい運用 »昔は「作る」と「動かす」を分離することが効率的 だった • でも、もっとリリース回数を増やしたい »10回/日以上 »そのためには何をすればいいのか? 23
  25. 25. DevOps CI/CDの発展形 • 継続的インテグレーション »レポジトリからのチェックアウト&自動テスト&自 動ビルド »ハードウェアの自動構成&自動デプロイ • 開発と運用の情報共有 »変更ログや通知の共有 »チャットbotによる自動通知 24
  26. 26. DevOps 運用を不要にしていく • 理想は「運用の完全自動化」 »事件が起きたときの対応チームのみ • 開発時点で運用のことを考慮する »運用しやすいように開発すればいいじゃん »面倒なことはソフトウェアで自動化しよう 25
  27. 27. 26https://www.flickr.com/photos/willfolsom/5681274525/
  28. 28. カナリアリリース 27 Web App DB ルーター100 100
  29. 29. カナリアリリース 28 Web App DB ルーター100 100 Web App DB
  30. 30. カナリアリリース 29 Web App DB ルーター100 95 Web App DB 5
  31. 31. カナリアリリース 30 Web App DB ルーター100 100 Web App DB
  32. 32. カナリアリリース 31 ルーター100 100 Web App DB
  33. 33. カナリアリリース コードからサービスまでを自動化 • コードをレポジトリからチェックアウト • ビルドして、テストして、アーカイブして • デプロイ先のサーバを起動して • そのサーバにリリースして • サービスレポジトリにサービスを登録して • ロードバランサの設定を段階的に変更して • サービスの稼働状況を監視して • 何かあったら色々する 32
  34. 34. カナリアリリース カナリアと変更と品質 • 別名:ブルーグリーンデプロイ、A/Bテスト • カナリア(部分的な犠牲)を許容することで、 スピードを落とさずに全体的な品質を維持する »きちんとしたテストなんかしている暇がない • もちろん、すべてのITシステムが同じ考え方で はないが参考になる部分はある 33
  35. 35. 必要な技術群 • デプロイ管理 » Jenkins、spinaker • コンテナ、コンテナ管理 » Docker » Kubernetes、Marathon+Mesos、spinaker • ルーター » Vamp、Zuul+Ribbon • サービスレポジトリ » ZooKeeper、Eureka • 分散ログ集約 » Elasticsearch、Vector 34
  36. 36. ダークカナリアリリース 「本番環境でテストする」 • 開発者にしか見えないリリース 35
  37. 37. Chaos Monkey • 平日日中にサーバをランダムにダ ウンさせるためのOSS • Netflixではインスタンスは毎週、 アベイラビリティゾーンあるいは リージョン丸ごとは毎月障害 36
  38. 38. マイクロサービス アーキテクチャ 37
  39. 39. マイクロサービスアーキテクチャ サービス連携でサービスを作る • サービス同士の連携によるシステム実現 »(小さな)サービスによって(大きな)サービスを 動かす »サービス=独立した非機能要件を持つシステム »動的コンポーネントの組み合わせでシステムを作る • 先進企業の仕組みを調べたら、似たような仕組 みだったのでMSAと名付けた »技術論が先ではないことに注意 38
  40. 40. 特徴 • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ処理 • 分散ガバナンス • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 • 進化的な設計 39
  41. 41. MSAの2つの側面 技術面:分散配置と統合 • サービスによるコンポーネント化 • スマートなエンドポイントと単純なパイプ処理 • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 組織面:持続性と分権 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • 分散ガバナンス • 進化的な設計 40
  42. 42. MSAの技術面:分散配置と統合 サービスをサービスで構成する • 静的構成から動的構成へ メッセージによる統合 • 動的要素同士はメッセージで協調動作する サービスをマネージする • 個別要素と全体サービスの管理 41
  43. 43. MSAの組織面:持続性と分権 サービス全体を持続的に動作させる • ITシステム開発からサービス運営へ ドメイン固有の技術と運営 • ドメインごとの自主性、標準化への否定 ドメイン個別のライフサイクル • 個別再構築の許容、犠牲的アーキテクチャ 42
  44. 44. MSAとは 変化するために分割する • モノリシックでは部分の変更が全体に波及する »変更で大変なのは事前調査とテスト • サービスに分割されていれば変更の影響はサー ビス内部にとどまる »APIに変更がなく、データベースは共有しない ▸API自身もバージョン管理すればよい »よって、サービスは、それぞれのサイクルでリリー スできる 43
  45. 45. MSAとは 変化とサービス分割 • 「サービスが適切に分割されていれば」 »あるサービスの変更が他のサービスに影響したら意 味がない • サービス分割はドメインに従う »ドメイン≒業務 »システムへの変更要求は業務に起因するので当然 »DDD(ドメイン駆動設計) 44
  46. 46. MSAとは 変化のための技術論と組織論の集合 • より良いサービス運営に最適化した結果 »クラウドもDevOpsもアジャイルも変化に対応するた めの方法論 ▸インフラの変化、継続的なリリース、持続的な改善活動… 45
  47. 47. MSAと企業システム 企業システムにおける全体視点 • 企業システムでも全体視点は重要 »もはや連携がないシステムは存在しない »個別システムが良くできても全体としてよくなけれ ば意味がない • MSA的な発想は重要 »アジャイル、クラウド、DevOpsが重要なように »アーキテクチャに議論を落とす • 誰がやるのか?は、日本の課題 46
  48. 48. MSAと企業システム SOAとMSA • SOAは「既存資産があるうえで、どのようにシ ステムを連携させるのか」というテーマ »システム間連携が増えてきた中で、既存資産の再構 築をせずに連携部分で頑張ろうとした仕組み »リッチな連携機能としてEAI/ESB/BPM • MSAを企業システムに取り入れる場合は、必ず SOA的な課題に取り組む必要がある 47
  49. 49. MSAと企業システム 今後に向けて • もっとも重要なのはビジネス価値への集中 »価値を最大化し続けるために変化する • 変化に適応するためには、 »クラウド/DevOpsといった技術 »アジャイルのようなマネジメント論 »ドメインに従ってサービスを分割する 48
  50. 50. MSAとは 組織におけるサービス運営論 • より良いサービス運営のためには技術論と組織 論が重要、という当たり前の話 »かつ、その技術論と組織論は標準化せず、ドメイン に最適化すべきである 49
  51. 51. MSAへの取り組み MSAは目的ではない • MSAに「する」ではなく「なる」 »よりよりサービス運営を技術論や組織論からつめて いったら勝手にMSA的になる(はず) »MSAは良い参考文献 • 特に重要なのは全体視点のアーキテクト »企業におけるドメインを理解し、技術論と組織論の バランスを取れる人 50
  52. 52. まとめ 51
  53. 53. まとめ 要求は変化する • 要求はビジネス価値にもとづいて「開発」され るべきもので、ステークホルダーの参加協調に よる継続的改善が必要 • ビジネス環境の変化に伴い、要求はどんどん変 化していく • では、ITシステムはどう対応すべきか? 52
  54. 54. まとめ アジャイル • 変更が多いなら調整を中心にしたマネジメント が望ましい • 「早く安く」ではなく、適切なタイミングで適 切な判断をするための手法 53
  55. 55. まとめ クラウド/DevOps • ソフトウェア化されるハードウェア • PaaSの活用 »動的なコンポーネント • 運用を自動化する »カナリアリリース、その先へ 54
  56. 56. まとめ マイクロサービスアーキテクチャ • サービスによってサービスを構成する »サービス=稼働しているアプリケーション »変化の影響をサービス内部に限定する • 技術論と組織論の両輪 • 企業システムでも間違いなく重要になる »変化に適応するシステムを考えていれば行き着く 55
  57. 57. サービス運営モデル 56 サービス 機能 (コード) IT サービス 価値 構造 開発 企画 運用 業務 プロ セス
  58. 58. 最後に 銀の弾丸は存在しない • 変化との戦いは続く »アジャイル、クラウド/DevOps… • MSAも正解ではない »適応しにくいドメインもあるはず »技術と組織の融合が実現されているのは面白い 57

×