Download as PDF, PPTX
要求の変化とマイクロサービスアーキテクチャ
- 1.
- 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ（株） » 執行役員/アーキテクチャ事業本部長 »http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
- 3. Agenda • 要求開発とITシステム • アジャイル •クラウドとDevOps • マイクロサービスアーキテクチャ • まとめ 2
- 4.
- 5. 要求開発宣言（抜粋） • 情報システムに対する要求は、あらかじめ存在 しているものではなく、ビジネス価値にもとづ いて「開発」されるべきものである。 • ビジネス価値を満たす要求は、直接・間接にそ の価値に関わるステークホルダー間の合意形成 を通じてのみ創り出される。 •要求の開発は、命令統制によらず参加協調によ る継続的改善プロセスを指向すべきである。 4 2004年12月23日 すずかけ台にて
- 6. 現在的なテーマ SoRからSoEへ • 要求開発の意義は変化なし。ITシステムの存在 はより大きなものに • SoRからSoEへの広がり »SoR：情報を”記録”する »SoE：ユーザー同士の”関係性”を作り出す •SoEでは「ユーザーの要求が変化していく」こ とが主眼になる 5
- 7.
- 8. サービス運営モデル サービス運営モデル • 利用者の満足度はサービスの利用で生まれる • サービスはITを含む包括的なものである •コードを動かしてITサービスとなる • コードは構造とプロセスに支えられる • それらには様々なステークホルダーが関わる 7
- 9.
- 10. 要求開発とITシステム 要求は変化する • 要求は価値から生まれる • 価値を最大化し続けるためには変化し続けるす るしかない •だから、要求も変化し続ける • では、ITシステムは、どう対応するのか？ 9
- 11. 要求変化との戦い 変化との戦い • アジャイル • クラウドとDevOps •マイクロサービスアーキテクチャ 10
- 12.
- 13. アジャイル プロジェクトマネジメントの基本 • 計画する：QCDSを決める • 実行する：計画従って作業する •計測する：計画と実績のズレを測る • 調整する：ズレに対応する（QCDSの変更） ※QCDS：Quality（品質）、Cost（費用）、Delivery（期限）、Scope（機能） 12
- 14. アジャイル ウォーターフォールの失敗 • 計画の失敗：そもそも計画が正しくない • 実行の失敗：計画された通りに作れない •計測の失敗：ただしく進捗を測れない • 調整の失敗：ズレがあっても調整できない 13
- 15. アジャイル アジャイルの考え方 • 計画：精度が出るぐらい短期にする »リソースは固定化する • 計測：動くソフトウェアで判断する •調整：定期的に関係者全員で話し合う • 調整を重視したマネジメントスタイル »WFは計画と効率を重視している 14
- 16.
- 17.
- 18.
- 19.
- 20.
- 21. クラウド Platform as aService • 特に注目すべきはPaaS • ミドルウェア＋稼働状態＝PaaS »OSSフレームワークは静的コンポーネント »PaaSは動的なコンポーネント • 使うことで制約を受けるが便利になる 20
- 22. クラウド PaaSのレベル • 低：AWS RDS »DBMS+CPU+ストレージ＋バックアップ＋… •中：AWS BeansTalk »LB+APSV＋監視＋自動再起動＋… • 高：Heroku »レポジトリ＋DevOps+APSV+… 21
- 23.
- 24. DevOps 継続的なリリースにために • 変えていきたい開発 vs安定させたい運用 »昔は「作る」と「動かす」を分離することが効率的 だった • でも、もっとリリース回数を増やしたい »10回/日以上 »そのためには何をすればいいのか？ 23
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33. カナリアリリース コードからサービスまでを自動化 • コードをレポジトリからチェックアウト • ビルドして、テストして、アーカイブして •デプロイ先のサーバを起動して • そのサーバにリリースして • サービスレポジトリにサービスを登録して • ロードバランサの設定を段階的に変更して • サービスの稼働状況を監視して • 何かあったら色々する 32
- 34. カナリアリリース カナリアと変更と品質 • 別名：ブルーグリーンデプロイ、A/Bテスト • カナリア（部分的な犠牲）を許容することで、 スピードを落とさずに全体的な品質を維持する »きちんとしたテストなんかしている暇がない •もちろん、すべてのITシステムが同じ考え方で はないが参考になる部分はある 33
- 35. 必要な技術群 • デプロイ管理 » Jenkins、spinaker •コンテナ、コンテナ管理 » Docker » Kubernetes、Marathon+Mesos、spinaker • ルーター » Vamp、Zuul+Ribbon • サービスレポジトリ » ZooKeeper、Eureka • 分散ログ集約 » Elasticsearch、Vector 34
- 36.
- 37. Chaos Monkey • 平日日中にサーバをランダムにダ ウンさせるためのOSS •Netflixではインスタンスは毎週、 アベイラビリティゾーンあるいは リージョン丸ごとは毎月障害 36
- 38.
- 39.
- 40. 特徴 • サービスによるコンポーネント化 • ビジネスケイパビリティに基づく組織化 •プロジェクトではなくプロダクト • スマートなエンドポイントと単純なパイプ処理 • 分散ガバナンス • 分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 • 進化的な設計 39
- 41. MSAの2つの側面 技術面：分散配置と統合 • サービスによるコンポーネント化 • スマートなエンドポイントと単純なパイプ処理 •分散データマネジメント • インフラの自動化 • フェイルを前提とした設計 組織面：持続性と分権 • ビジネスケイパビリティに基づく組織化 • プロジェクトではなくプロダクト • 分散ガバナンス • 進化的な設計 40
- 42.
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55. まとめ クラウド/DevOps • ソフトウェア化されるハードウェア • PaaSの活用 »動的なコンポーネント •運用を自動化する »カナリアリリース、その先へ 54
- 56. まとめ マイクロサービスアーキテクチャ • サービスによってサービスを構成する »サービス＝稼働しているアプリケーション »変化の影響をサービス内部に限定する • 技術論と組織論の両輪 •企業システムでも間違いなく重要になる »変化に適応するシステムを考えていれば行き着く 55
- 57.
- 58.