クラウドの発展とデベロッパーの役割について

2016/7/16

鈴木雄介グロースエクスパートナーズ株式会社 執行役員

日本Javaユーザーグループ 会長

【S-1】

#devsumiS1

自己紹介

鈴木雄介• グロースエクスパートナーズ（株）

» 執行役員/アーキテクチャ事業本部長

» http://www.gxp.co.jp/

• 日本Javaユーザーグループ

» 会長

» http://www.java-users.jp/

• SNS

» http://arclamp.hatenablog.com/

» @yusuke_arclamp

1

アジェンダ

• クラウドがもたらしたもの

• クラウドの発展

• エンタープライズとクラウド

• クラウド時代のデベロッパー

• まとめ

2

クラウドがもたらしたもの

3

クラウドがもたらしたもの

クラウドにおける3つの変化• 1.インフラのサービス化

• 2.ミドルウェアのプラットフォーム化

• 3.システム構成のコード化

4

クラウドがもたらしたもの

1.インフラのサービス化• 仮想化技術の応用

»SDx：ソフトウェアであらゆるものを定義する

»広大なデータセンターの上に自分のための仮想インフラが構築できる

• インフラを「所有」から「利用」へ

»IaaS（Infrastructure as a Service）

»例：AWS EC2

5

クラウドがもたらしたもの

2.ミドルウェアのプラットフォーム化• ミドルウェアの仮想化

»AWS RDS（Relational Database Service）はデータベースサーバーのレンタルではない

▸バックアップもクラスタ構成も設定するだけ

• 高度化するプラットフォーム

»Webアプリ基盤：AWS Elastic Beanstalk

»開発ライフサイクル込み基盤：AWS CodeDeploy / AWS CodePipeline

6

クラウドがもたらしたもの

2.ミドルウェアのプラットフォーム化• プラットフォームを利用する

»PaaS（Platform as a Service）

»アプリとインフラの境界線がなくなる

• 積極的にプラットフォームの制約を受け入れる

»制約を受け入れて利用したほうが便利

»OSSライブラリと一緒

7

クラウドがもたらしたもの

3.システム構成のコード化• 仮想化されたインフラやプラットフォームがコードから操作ができる

»つまり、「構成する」ことの自動化ができる

• 非機能要件がコーディングできる

»これまでは機能要件しかコーディングできなかった

»サービスそのものがコードで表現できる

8

クラウドがもたらしたもの

クラウド技術の可能性• 3つセットでクラウド技術

»1.インフラのサービス化

»2.ミドルウェアのプラットフォーム化

»3.システム構成のコード化

• クラウドファースト

»2.プラットフォームと3.コード化を有効活用

»オンプレからの単純移行（IaaS）では足りない

9

クラウドがもたらしたもの

ITサービス運営のスピードアップ• ITサービス運営＝企画→開発→運用という営み

»「アプリを書く」ことが早くなるのではない

• 「作る」だけでは価値じゃない

»システムを動かして、ビジネス価値を生み出す

10

クラウドの発展

11

クラウドの発展

クラウドが何をもたらしたのか• クラウドが何をもたらしたのかを理解する

• 15年前から、僕らはITサービス運営のスピードアップに取り組んでいた

»アジャイル

»DevOps

»マイクロサービスアーキテクチャ（MSA）

12

クラウドの発展

アジャイル

13

アジャイル

アジャイルのはじまり• 2001年：アジャイルソフトウェア開発宣言

»プロセスやツールよりも個人と対話を、

»包括的なドキュメントよりも動くソフトウェアを、

»契約交渉よりも顧客との協調を、

»計画に従うことよりも変化への対応を

• 主に「企画→開発」にフォーカス

14参考：http://www.agilemanifesto.org/iso/ja/

アジャイル

ウォーターフォールの進め方• 最終成果物に向けて、フェーズごとの中間成果物を定め、段階的に品質を確認する

15

基本設計 実装 テスト要件定義計画

受入

文書 文書

アジャイル

ウォーターフォールの課題• 欲しい最終成果物が変化してしまう

»終わるころには欲しいものでは異なる

• 中間成果物では品質が確認できない

»文書を見ても評価できない

• 調整が後手後手になりやすい

»情勢の見極めがPMの力量に左右される

16

アジャイル

アジャイルのアプローチ• 期間とリソースを定め、計画と評価を繰り返す

• 評価は関係者全員で動くソフトウエアを確認

17

設計 実装 ﾃｽﾄ計画

受入 設計 実装 ﾃｽﾄ

計画

受入 設計 実装 ﾃｽﾄ

計画

受入

アジャイル

アジャイルのメリット• 「今」欲しいものを得られる

»次のリリースがあるという安心感

• 定期的に評価ができる

»フィードバックを元に進めていける

• プロセスではなくチーム

»状況が共有できるので判断が行いやすい

18

アジャイル

「仕事の仕方」の違い• WF：やるべきことを終わるまでやる

»必要な期間とリソースを調達する

»一発リリースと保守活動

• アジャイル：期限までに今やるべきことをやる

»決められた期間とリソースの範囲内でやる

»段階リリースで改善活動

19

クラウドの発展

DevOps

20

DevOps

DevOpsのはじまり• アジャイルを「開発→運用」に適用する

• 2009年：DevOps

»Agile 2008：Agile Infrastructure & Operations

▸政府系データセンターの移行にスクラムを導入した事例

»Velocity 2009：10+ Deploys Per Day

▸Flickrにおける開発と運用の協業について

»Devopsdays Ghent 2009

▸ここから「DevOps」が生まれる

21

参考：「The (Short) History of DevOps」（Damon Edwards）https://www.youtube.com/watch?v=o7-IuYS0iSE

DevOps

Dev❤Opsのテーマ• そもそも開発と運用は仲が悪い

»「変更」と「安定稼働」は相反する

• 前提が変わってしまった

»アプリは変更してなんぼ

»システムの停止＝価値の棄損

• 運用の完全自動化（Opsの不要化）

»クラウド技術の成熟との強い相関

22

DevOps

ブルーグリーンデプロイメント• システム構成の自動化がもたらしたアイデア

»本番環境をコピーして、新バージョン用の本番環境を作る

»ユーザーのアクセスを切り替える

▸もちろん、切り戻しも一瞬

23

ブルーグリーンデプロイメント

24

Web App DB

ルーター100

100

ブルーグリーンデプロイメント

25

Web App DB

ルーター100

100

Web App DB

ブルーグリーンデプロイメント

26

Web App DB

ルーター100

95

Web App DB

5

ブルーグリーンデプロイメント

27

Web App DB

ルーター100

100

Web App DB

ブルーグリーンデプロイメント

28

ルーター100

100

Web App DB

DevOps

ブルーグリーンデプロイメント• 可能な限りサービスを止めない

»数％の犠牲（の可能性）によって全体を救う

»日中リリースが可能で切戻しコストも低い

• カナリアリリース

»ブルーグリーンデプロイメントがベース

»一部のユーザーだけに特定のバージョンを提供する

29

DevOps

ダークカナリア• カナリアリリースを応用

»「秘密のカナリア」

• 開発者だけがアクセスできるテスト用バージョンを本番環境にリリースする

»連携先システムも含めて、ステージング環境の構築が困難な場合は有効

»もちろんバグが残っている可能性があるので、適用する機能は限定される

30参考：「Scaling micro services at Gilt」http://www.slideshare.net/trenaman/javaone-2015-scaling-micro-services-at-gilt

DevOps

カオスモンキー• 本番環境をランダムにダウンさせる製品

»モンキー：サーバー

»ゴリラ：アベイラビティゾーン

»コング：リージョン（≒データセンター）

• 自動化スクリプトのテスト

»本番環境でしか実施できない

»もしものために平日日中に実行する

31参考：https://github.com/Netflix/SimianArmy

クラウドの発展

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

32

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

MSA• 2014年：「Microservceis」

»2011年：先端的なウェブサービス企業が似てようなアーキテクチャスタイルを取っていることが議論に

»33rd Degree 2012「Microservices - Java, the Unix Way」

• アジャイル＋DevOpsをアーキテクチャ論に展開したもの

33

参考：http://martinfowler.com/articles/microservices.html参考： http://2012.33degree.org/talk/show/67

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

モノリシックなシステムの課題• 部分の変更が全体に波及する

»全体への影響調査

»全体でのリグレッションテスト

• 技術の選択に幅がなくなる

»システム全体を単一の構造で作る

»技術の切れ目でチームも構成しがち

▸コンウェイの法則

34

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

MSAの特性（技術面）• 部分の変更を全体に波及させない

»システムをサービス同士の連携で実現する

»サービス同士が疎結合になっていれば、サービスはいつでも変更してよい

▸APIによる連携

▸サービスの無停止リリース

• 個別サービスの変化がシステム全体の変化

35

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

MSAの特性（組織面）• サービス単位でマネジメントすればよい

»サービスの切れ目でチームを分ける

»サービスごとにリズムと技術を最適化

• たくさんのチームでシステムを作る

»アジャイルを最も効率的に機能させる仕組み

36

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

MSAの注意点• アプリ管理ではなくシステム管理

»巨大なシステムをいかに管理するか

• 設計指針ではなく結果論

»アジャイル＋クラウド＋DevOps＋サービス指向を突き詰めていった結果、自然にそうなる

• 「MSAで再構築」は「愚」

»MSAは今にすぐに取りかかれる

37

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

いかにサービスを分けるか• ドメイン（問題領域）

»≒業務

»変更ベクトルの濃淡に境界線を引いたもの

• ドメインモデル

»ドメイン専門家の頭の中

»≠UI/UX（ユーザーとのインタラクション）

▸APIによってドメインとUXを分割するべき

38

クラウドの発展

おさらい

39

クラウドの発展

おさらい• 2001年：アジャイル

• 2006年：クラウド ＆ AWS EC2

• 2009年：DevOps ＆ AWS RDS

• 2010年：ブルーグリーンデプロイメント

• 2011年：AWS Elastic Beanstalk

• 2012年：カオスモンキー ＆ カナリアリリース

• 2014年：マイクロサービスアーキテクチャ

40

クラウドの発展

全てはアジャイルから• アジャイルのムーブメントを運用にまで延ばしたのがDevOps

• その間にクラウド技術が発展し始め、プラットフォーム利用や自動化が促進

• ムーブメントと技術が統合した姿がマイクロサービスアーキテクチャ

• エンタープライズでも適用事例が←イマココ

41

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

42

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

エンタープライズとは• 安心安全で絶対に間違いが許されない？

• エンタープライズにおける2つのシステム

»SoR（System of Record/記録のシステム）

»SoE（System of Engagement/絆のシステム）

• SoEはWebサービスが参考になる

»ただし、「信頼」には足る必要性がある

»SoRとの連携については注意が必要

43

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

良い悪いではない• 適切にツールとして使うことが大事

»アジャイルとウォーターフォール

»DevOpsとITIL

»MSAとSOA

• まずは「マインドセット」の変更を

»態度：be Agile（定期的な改善）

»技術：プラットフォームの活用

44

クラウド時代のデベロッパー

45

クラウド時代のデベロッパー

コーディング対象の拡がり• 機能要件だけではなく非機能要件もコードに書けるようになってきた

»アプリとインフラは不可分に

• PaaSを選ぶ ≒ OSSフレームワークを選ぶ

»PaaS＝アプリ＋インフラのフレームワーク

»制約に従うなら使った方が便利

46

クラウド時代のデベロッパー

システム開発からサービス運営へ• 「要件を満たすアプリを作る」から「価値があるサービスを運営する」へ

»効率的に作るよりも、効率的に動かす

• 企画→開発→運用のあらゆる所でエンジニア能力が求められるように

»効率的に作るよりも、より適切な機能を提供する

47

クラウド時代のデベロッパー

「技術」の多様化• より特定の目的に沿った技術の登場

»それらの技術をいかに組み合わせて楽をするか

»IoT、AIなどなど

• より特定の目的に沿った方法論の登場

»企画：戦略理解→ユーザ中心設計→機能リスト

»開発：アジャイル、各種ツール

»運用：DevOps、各種ツール

48

クラウド時代のデベロッパー

技術の使われ方を意識する• 技術そのものだけではなく「技術の使い方」のトレンドを意識する

»「おしゃれな技術」という理解は無意味

»何に最適な技術なのか？を理解し、無理をさせない

• 使い方にはマネジメントプロセスも含む

»建築では工法と構造が一体なのは当たり前のこと

49

クラウド時代のデベロッパー

スキルを縦か横に拡げる• 機能別から価値を出すためのチーム分けへ

• スペシャリストかゼネラリスト

»スペシャリスト：特定領域の専門家

»ゼネラリスト：専門家を繋いで価値に繋げる

50

開発

企画 シス

テム

作り

運用

サービス運営

企画

＋開

発＋

運用

企画

＋開

発＋

運用

企画

＋開

発＋

運用

クラウド時代のデベロッパー

ビジネスの中心になろう• 「ITがビジネスの最重要課題」なら「デベロッパーがビジネス活動の中心」にいるべき

»ビジネスパーソンとしてのデベロッパー

• デベロッパーにもビジネススキルが必須

»コミュニケーション能力やプレゼン能力

»チームビルディング

51

まとめ

52

まとめ

全てはアジャイルからはじまった• アジャイルのムーブメントを運用にまで延ばしたのがDevOps

• その間にクラウド技術が発展し始め、プラットフォーム利用や自動化が促進

• ムーブメントと技術が統合した姿がマイクロサービスアーキテクチャ

• エンタープライズでも適用事例が←イマココ

53

まとめ

クラウドファースト• クラウドを利用してITサービス運営を早くする

»単純にIaaSを使うのではなく、プラットフォームや自動化スクリプトを使い倒す

• 技術を使う側に発想の転換が必要

»アプリとインフラの境目がなくなる

»非機能要件もコーディングできる

»プラットフォームの制約を受け入れる

54

まとめ

クラウド時代のデベロッパー• 色々と拡がった

»非機能要件もコーディング対象

»システム開発からサービス運営へ

• 多様化した「技術」の使われ方を意識する

• スキルを縦か横に拡げる

• ビジネスの中心になろう

55

最後に

56

お知らせ

さらに詳しく知りたいなら• クラウドファーストアーキテクチャ設計ガイド

» 第1章 クラウドファーストの意味

» 第2章 クラウド技術の構成

» 第3章 クラウドファーストに至るまでの歴史

» 第4章 エンタープライズとクラウドファースト

» 第5章 アーキテクチャー設計ガイド

» 第6章 クラウドファーストにおけるエンジニア

57

https://www.amazon.co.jp/dp/4822237818