2016年7月16日に開催された「ソフトウェア技術者サミット in 福井 2016」における基調講演「クラウド時代のエンジニアについて」の資料です。 https://fitea.doorkeeper.jp/events/45122

1. クラウド時代の
エンジニアについて
2016/7/16
鈴木雄介
グロースエクスパートナーズ株式会社 執行役員
日本Javaユーザーグループ 会長
ソフトウェア技術者サミット in 福井 2016

2. 自己紹介
鈴木雄介
• グロースエクスパートナーズ（株）
» 執行役員/アーキテクチャ事業本部長
» http://www.gxp.co.jp/
• 日本Javaユーザーグループ
» 会長
» http://www.java-users.jp/
• SNS
» http://arclamp.hatenablog.com/
» @yusuke_arclamp
1

3. アジェンダ
• クラウドがもたらしたもの
• クラウドの進化
• エンタープライズとクラウド
• クラウド時代のエンジニア
• まとめ
2

4. クラウドがもたらしたもの
3

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

6. クラウドがもたらしたもの
クラウドにおける3つの変化
• 1.インフラのサービス化
• 2.ミドルウェアのプラットフォーム化
• 3.システム構成のコード化
5

7. クラウドがもたらしたもの
1.インフラのサービス化
• 仮想化技術の応用
»SDx：ソフトウェアであらゆるものを定義する
»広大なデータセンターの上に自分のための仮想イン
フラが構築できる
• インフラを「所有」から「利用」へ
»IaaS（Infrastructure as a Service）
»例：AWS EC2
6

8. クラウドがもたらしたもの
2.ミドルウェアのプラットフォーム化
• 仮想化できるのはインフラだけじゃない
»AWS RDS（Relational Database Service）はデー
タベースサーバーのレンタルではなく、データベー
スのサービス化
▸バックアップもクラスタ構成も設定するだけ
• プラットフォームを利用する
»PaaS（Platform as a Service）
»アプリとインフラの境界線がなくなる
7

9. クラウドがもたらしたもの
2.ミドルウェアのプラットフォーム化
• プラットフォームも高度している
»Webアプリ基盤：AWS Elastic Beanstalk
»開発ライフサイクル込み基盤：AWS CodeDeploy /
AWS CodePipeline
• 積極的にプラットフォームの制約を受け入れる
»制約を受け入れて利用したほうが便利
»OSSライブラリと一緒
8

10. クラウドがもたらしたもの
3.システム構成のコード化
• 仮想化されたインフラやプラットフォームがコ
ードから操作ができる
»つまり、if文が書ける
▸if {性能が悪ければ} then {サーバを足す}
• 非機能要件がコーディングできる
»これまでは機能要件しかコーディングできなかった
»システム丸ごとコードで表現できる
9

11. クラウドがもたらしたもの
クラウドファースト
• 3つセットでクラウド技術
»1.インフラのサービス化
»2.ミドルウェアのプラットフォーム化
»3.システム構成のコード化
• クラウドファースト
»プラットフォームと自動化を最大限利用する
»オンプレからの単純移行（IaaS）では意味なし
10

12. クラウドがもたらしたもの
ビジネスのスピードアップ
• クラウドでITサービス運営が早くなる
»サービス＝「企画」「開発」「運用」という営み
»「アプリを書く」ことが早くなるのではない
• 「作る」だけでは価値じゃない
»システムを動かして、ビジネス価値を生み出すこと
が重要
»そのためにクラウドが大きな変化をもたらした
11

13. クラウドの進化
12

14. クラウドの進化
進化の歴史をたどってみる
• アジャイル
• DevOps
• マイクロサービスアーキテクチャ（MSA）
13

15. クラウドの進化
アジャイル
14

16. アジャイル
アジャイルのはじまり
• 2001年：アジャイルソフトウェア開発宣言
»プロセスやツールよりも個人と対話を、
»包括的なドキュメントよりも動くソフトウェアを、
»契約交渉よりも顧客との協調を、
»計画に従うことよりも変化への対応を
• 「企画→開発」のスピードアップ
»ウォーターフォールへの批判
15参考：http://www.agilemanifesto.org/iso/ja/

17. アジャイル
プロジェクトマネジメントの基礎
• プロジェクトマネジメント
»計画：QCDSを設定する
»実行：計画に従って作業を行う
»計測：計画と実績を比較する
»調整：計画と実績のズレを調整する
• QCDS
»Quality（品質）、Cost（費用）、Delivery（期日）
、Scope（範囲）
16

18. アジャイル
ウォーターフォールの課題
• ウォータフォール
»計画：全体を予測し、リソースを調達する
»計測：フェーズごとの中間成果物
»調整：プロジェクトマネージャーの力量
• 失敗しがちなこと
»計画：正しく予測ができない
»計測：中間成果物では良くわからない
»調整：力量が足らない
17

19. アジャイル
アジャイルのアプローチ
• 計画：定期的で小さくする
• 計測：動くソフトウエアで管理する
• 調整：関係者全員を集めて話し合う
• プロセスからチームへ
»「個人の能力」から「チーム力を活かす」
»顧客も含めてチーム
18

20. クラウドの進化
DevOps
19

21. DevOps
DevOpsのはじまり
• アジャイルを「開発→運用」に適用する
• 2009年：DevOps
»Agile 2008：Agile Infrastructure & Operations
▸政府系データセンターの移行にスクラムを導入した事例
»Velocity 2009：10+ Deploys Per Day
▸Flickrにおける開発と運用の協業について
»Devopsdays Ghent 2009
▸ここから「DevOps」が生まれる
20
参考：「The (Short) History of DevOps」（Damon Edwards）
https://www.youtube.com/watch?v=o7-IuYS0iSE

22. DevOps
DevOpsのテーマ
• 開発と運用は仲が悪い
»ITサービスを安定稼働するために変更プロセスを煩
雑にする
»リリース回数を増やそうとすると相反する
• DevOpsが目指したこと
»徹底した自動化
»開発と運用における情報共有
»開発と運用が協業する文化
21

23. DevOps
カナリアリリース
• ブルーグリーンデプロイメント
»本番環境をコピーして、新バージョンをリリース
»ユーザーのアクセスを切り替える
»もちろん、切り戻しも一瞬
• カナリアリリース
»ブルーグリーンデプロイメントがベース
»一部のユーザーだけに特定のバージョンを提供する
22

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

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

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

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

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

29. DevOps
カナリアリリース
• 可能な限りサービスを止めない
»数％の犠牲（の可能性）によって全体を救う
»日中リリースが可能で切戻しコストも低い
»もちろん、すべてのITシステムが同じ考え方ではな
いが参考になる部分はある
• A/Bテストへの応用も可能
»一部のユーザーに違うバージョンのアプリを試して
もらう
28

30. DevOps
ダークカナリア
• カナリアリリースを応用
»「秘密のカナリア」
• 開発者だけがアクセスできるテスト用バージョ
ンを本番環境にリリースする
»連携先システムも含めて、ステージング環境の構築
が困難な場合は有効
»もちろんバグが残っている可能性があるので、適用
する機能は限定される
29参考：「Scaling micro services at Gilt」http://www.slideshare.net/trenaman/javaone-2015-scaling-micro-services-at-gilt

31. DevOps
カオスモンキー
• 本番環境をランダムにダウンさせる製品
»モンキー：サーバー
»ゴリラ：アベイラビティゾーン
»コング：リージョン（≒データセンター）
• 自動化スクリプトのテスト
»本番環境でしか実施できない
»もしものために平日日中に実行する
30参考：https://github.com/Netflix/SimianArmy

32. クラウドの進化
マイクロサービス
アーキテクチャ
31

33. マイクロサービスアーキテクチャ
MSA
• 2014年：「Microservceis」
»2011年：先端的なウェブサービス企業が似てような
アーキテクチャスタイルを取っていることが議論に
»33rd Degree 2012「Microservices - Java, the
Unix Way」
• アジャイルやDevOpsをベースにしたアーキテ
クチャ
32
参考：http://martinfowler.com/articles/microservices.html
参考： http://2012.33degree.org/talk/show/67

34. マイクロサービスアーキテクチャ
技術面 1/2
• 大きなシステムをサービスに分解する
»サービスごとにライフサイクルを分けられる
»サービスごとに非機能要件も分けられる
• サービスごとにリリースタイミングを分けるこ
とができる
»モノリシックなシステムは変更影響調査やテストに
時間がかかっていた
33

35. マイクロサービスアーキテクチャ
技術面 2/2
• サービスは疎結合に連携する
»キューを使った非同期メッセージング
»同期の場合はサーキットブレーカー付で
»データは共有せずに分散配置
34
処理
A
処理
B
ﾒｯｾｰｼﾞ
キュー
②キューに追加
④キューから読み込み
①リクエスト
③処理完了
⑤キューを削除

36. マイクロサービスアーキテクチャ
組織面
• サービスは1つのチームが担当する
»技術的観点の分割からサービス観点の分割へ
»それぞれが適切なリズムで活動できるようになる
»大型システムにおいても自主性をもったチーム運営
を可能にする
»たくさんの（優秀な）アジャイルチーム
35

37. クラウドの進化
おさらい
36

38. クラウドの進化
おさらい
• 2001年：アジャイル
• 2006年：クラウド ＆ AWS EC2
• 2009年：DevOps ＆ AWS RDS
• 2010年：ブルーグリーンデプロイメント
• 2011年：AWS Elastic Beanstalk
• 2012年：カオスモンキー ＆ カナリアリリース
• 2014年：マイクロサービスアーキテクチャ
37

39. クラウドの進化
全てはアジャイルから
• アジャイルのムーブメントを運用にまで延ばし
たのがDevOps
• その間にクラウド技術が発展し始め、プラット
フォーム利用や自動化が促進
• ムーブメントと技術が統合した姿がマイクロサ
ービスアーキテクチャ
• エンタープライズでも適用事例が←イマココ
38

40. エンタープライズとクラウド
39

41. エンタープライズとクラウド
エンタープライズとは
• 安心安全で絶対に間違いが許されない？
• エンタープライズにおける2つのシステム
»SoR（System of Record/記録のシステム）
»SoE（System of Engagement/絆のシステム）
• SoEはWebサービスが参考になる
»ただし、信頼には足る必要性がある
40

42. エンタープライズとクラウド
良い悪いではない
• 適切にツールとして使うことが大事
»アジャイルとウォーターフォール
»DevOpsとITIL
»MSAとSOA
• それよりも「マインドセット」の変更を
»態度：be Agile
»技術：プラットフォームに合わせる
41

43. クラウド時代のエンジニア
42

44. クラウド時代のエンジニア
技術の使われ方を意識する
• 技術そのものだけではなく「技術の使い方」の
トレンドを意識する
»実践できなくても、ちゃんと横目で見る！
• マネジメントも大事
»建築では工法と構造が一体なのは当たり前のこと
»MSAに見られるような統合が促進される
43

45. クラウド時代のエンジニア
システム作りからサービス運営へ
• 「要件を満たすアプリを作る」から「価値があ
るサービスを運営する」
»設計書に書いてあることを実装する作業はなくなる
• 個人力からチーム力
»個人の力をチームの力に変えていくことが大事
44

46. クラウド時代のエンジニア
スキルを縦か横に拡げる
• 機能別から価値を出すためのチーム分けへ
• スペシャリストかゼネラリスト
»スペシャリスト：特定領域の専門家
»ゼネラリスト：専門家を繋いで価値に繋げる
45
開発
企画
システム作り
運用
サービス運営
企画＋開発＋運用
企画＋開発＋運用
企画＋開発＋運用

47. クラウド時代のエンジニア
ビジネスの中心になる
• 「ITがビジネスの最重要課題」なら、エンジニ
アがビジネス活動の重要な位置にいるべき
• エンジニアにもビジネススキルが必須
»コミュニケーション能力やプレゼン能力
»チームビルディング
46

48. まとめ
47

49. まとめ
全てはアジャイルからはじまった
• アジャイルのムーブメントを運用にまで延ばし
たのがDevOps
• その間にクラウド技術が発展し始め、プラット
フォーム利用や自動化が促進
• ムーブメントと技術が統合した姿がマイクロサ
ービスアーキテクチャ
• エンタープライズでも適用事例が←イマココ
48

50. まとめ
クラウドファースト
• クラウドを利用してITサービス運営を早くする
»単純にIaaSを使うのではなく、プラットフォームや
自動化スクリプトを使い倒す
• 技術を使う側に発想の転換が必要
»アプリとインフラの境目がなくなる
»非機能要件もコーディングできる
»プラットフォームの制約を受け入れる
49

51. まとめ
クラウド時代のエンジニア
• 技術の使われ方を意識する
• システム作りからサービス運営へ
• スキルを縦か横に拡げる
• ビジネスの中心になる
50

52. 最後に
51

53. お知らせ
今日の話が本になります
• クラウドファーストアーキテクチャ設計ガイド
• 2016年8月刊行予定！
52