CHK-009_マイクロサービス アーキテクチャのすゝめ ～エンタープライズ システムを分割リリースせよ!!～

1. マイクロサービス アーキテクチャのすゝめ
～エンタープライズ システムを分割リリースせよ!!～
2016/5/17
森屋 英治
株式会社アークウェイ 代表取締役社長
鈴木 雄介
グロースエクスパートナーズ株式会社 執行役員
CHK-009

2. 本資料について
チョークトークにおいて、MSAを議論
するにあたり、MSAに至るまでの経緯
について記載したものです。
チョークトークの結果を記載したもの
ではありません。
1

3. 本資料について
• 要求とITシステム
• アジャイル
• クラウドとDevOps
• マイクロサービスアーキテクチャ
2

4. 要求とITシステム
3

5. 要求とITシステム
要求は変化する
• 要求は価値から生まれる
• 価値を最大化し続けるためには変化し続けるす
るしかない
• だから、要求も変化し続ける
• では、ITシステムは、どう対応するのか？
4

6. 要求とITシステム
変化との戦いの歴史
• アジャイル
• クラウドとDevOps
• マイクロサービスアーキテクチャ
5

7. アジャイル
6

8. アジャイル
プロジェクトマネジメントの基本
• 計画する：QCDSを決める
• 実行する：計画従って作業する
• 計測する：計画と実績のズレを測る
• 調整する：ズレに対応する（QCDSの変更）
※QCDS：Quality（品質）、Cost（費用）、Delivery（期限）、Scope（機能）
7

9. アジャイル
ウォーターフォールの失敗
• 計画の失敗：そもそも計画が正しくない
• 実行の失敗：計画された通りに作れない
• 計測の失敗：ただしく進捗を測れない
• 調整の失敗：ズレがあっても調整できない
8

10. アジャイル
アジャイルの考え方
• 計画：精度が出るぐらい短期にする
»リソースは固定化する
• 計測：動くソフトウェアで判断する
• 調整：定期的に関係者全員で話し合う
• 調整を重視したマネジメントスタイル
»WFは計画と効率を重視している
9

11. アジャイル
変化に適応するプロセス
• 「早く作る」ための手法ではない
»適切なものを適切なタイミングで作るための手法
»変更が多いなら調整タイミングを増やした方が無駄
が少ない、と考える
»計画精度が高いならWFのほうが無駄が少ない
• 企画から開発への流れにリズムをもたらす
10

12. クラウドとDevOps
11

13. クラウド
クラウドとは
• 狭義：
»ハードウェアの仮想化技術
• 広義：
»コンピューティングリソースにおける規模の経済
»所有ではなく利用
»資産から従量課金へ
12

14. クラウド
ソフトウェア化するハードウェア
• SDx（ソフトウェア定義されるハードウェア）
»ハードウェアの操作がソフトウェア化される
»ハードウェアのコピーや自動化ができるようになる
»非機能要件がコーディングできる
13

15. クラウド
クラウドの類型化
14
ハードウェア
ネットワーク
仮想化OS
OS
ミドルウェア
コード
設定
データ
オンプレ IaaS PaaS SaaS
＜ユーザーの管理範囲＞

16. クラウド
Platform as a Service
• 特に注目すべきはPaaS
• ミドルウェア＋稼働状態＝PaaS
»OSSフレームワークは静的コンポーネント
»PaaSは動的なコンポーネント
• 使うことで制約を受けるが便利になる
15

17. クラウド
PaaSのレベル
• 低：AWS RDS
»DBMS+CPU+ストレージ＋バックアップ＋…
• 中：AWS BeansTalk
»LB+APSV＋監視＋自動再起動＋…
• 高：Heroku
»レポジトリ＋DevOps+APSV+…
16

18. クラウド
クラウドネイティブ
• クラウドを前提にしてシステムを作ること
»特にPaaSの活用
• クラウドの制約に従うことで効率化する
»オンプレの作り方をクラウドに持ってくるのではな
く、クラウドに最適化されたやり方でアプリケーシ
ョンを考え直す
»特に運用が楽になる
17

19. DevOps
継続的なリリースにために
• 変えていきたい開発 vs 安定させたい運用
»昔は「作る」と「動かす」を分離することが効率的
だった
• でも、もっとリリース回数を増やしたい
»10回/日以上
»そのためには何をすればいいのか？
18

20. DevOps
CI/CDの発展形
• 継続的インテグレーション
»レポジトリからのチェックアウト＆自動テスト＆自
動ビルド
»ハードウェアの自動構成＆自動デプロイ
• 開発と運用の情報共有
»変更ログや通知の共有
»チャットbotによる自動通知
19

21. DevOps
運用を不要にしていく
• 理想は「運用の完全自動化」
»事件が起きたときの対応チームのみ
• 開発時点で運用のことを考慮する
»運用しやすいように開発すればいいじゃん
»面倒なことはソフトウェアで自動化しよう
20

22. 21https://www.flickr.com/photos/willfolsom/5681274525/

23. カナリアリリース
22
Web App DB
ルーター100
100

24. カナリアリリース
23
Web App DB
ルーター100
100
Web App DB

25. カナリアリリース
24
Web App DB
ルーター100
95
Web App DB
5

26. カナリアリリース
25
Web App DB
ルーター100
100
Web App DB

27. カナリアリリース
26
ルーター100
100
Web App DB

28. カナリアリリース
コードからサービスまでを自動化
• コードをレポジトリからチェックアウト
• ビルドして、テストして、アーカイブして
• デプロイ先のサーバを起動して
• そのサーバにリリースして
• サービスレポジトリにサービスを登録して
• ロードバランサの設定を段階的に変更して
• サービスの稼働状況を監視して
• 何かあったら色々する
27

29. カナリアリリース
カナリアと変更と品質
• 別名：ブルーグリーンデプロイ、A/Bテスト
• カナリア（部分的な犠牲）を許容することで、
スピードを落とさずに全体的な品質を維持する
»きちんとしたテストなんかしている暇がない
• もちろん、すべてのITシステムが同じ考え方で
はないが参考になる部分はある
28

30. 必要な技術群
• デプロイ管理
» Jenkins、spinaker
• コンテナ、コンテナ管理
» Docker
» Kubernetes、Marathon+Mesos、spinaker
• ルーター
» Vamp、Zuul+Ribbon
• サービスレポジトリ
» ZooKeeper、Eureka
• 分散ログ集約
» Elasticsearch、Vector
29

31. ダークカナリアリリース
「本番環境でテストする」
• 開発者にしか見えないリリース
30

32. Chaos Monkey
• 平日日中にサーバをランダムにダ
ウンさせるためのOSS
• Netflixではインスタンスは毎週、
アベイラビリティゾーンあるいは
リージョン丸ごとは毎月障害
31

33. マイクロサービス
アーキテクチャ
32

34. マイクロサービスアーキテクチャ
サービス連携でサービスを作る
• サービス同士の連携によるシステム実現
»（小さな）サービスによって（大きな）サービスを
動かす
»サービス＝独立した非機能要件を持つシステム
»動的コンポーネントの組み合わせでシステムを作る
• 先進企業の仕組みを調べたら、似たような仕組
みだったのでMSAと名付けた
»技術論が先ではないことに注意
33

35. MSAとは
変化するために分割する
• モノリシックでは部分の変更が全体に波及する
»変更で大変なのは事前調査とテスト
• サービスに分割されていれば変更の影響はサー
ビス内部にとどまる
»APIに変更がなく、データベースは共有しない
▸API自身もバージョン管理すればよい
»よって、サービスは、それぞれのサイクルでリリー
スできる
34

36. MSAとは
変化とサービス分割
• 「サービスが適切に分割されていれば」
»あるサービスの変更が他のサービスに影響したら意
味がない
• サービス分割はドメインに従う
»ドメイン≒業務
»システムへの変更要求は業務に起因するので当然
»DDD（ドメイン駆動設計）
35

37. MSAとは
変化のための技術論と組織論の集合
• より良いサービス運営に最適化した結果
»アジャイル、クラウド/DevOpsの先にあるもの
»持続的な改善活動、インフラの変化、継続的なリリ
ース…
• より良いサービス運営のためには技術論と組織
論が重要、という当たり前の話
»かつ、その技術論と組織論は標準化せず、ドメイン
に最適化すべきである
36

38. MSAへの取り組み
MSAは目的ではない
• MSAに「する」ではなく「なる」
»よりよりサービス運営を技術論や組織論からつめて
いったら勝手にMSA的になる（はず）
»MSAは良い参考文献
• 特に重要なのは全体視点のアーキテクト
»企業におけるドメインを理解し、技術論と組織論の
バランスを取れる人
37