クラウド時代のエンジニアについて #sesfukui

クラウド時代のエンジニアについて

2016/7/16

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

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

ソフトウェア技術者サミット in 福井 2016

自己紹介

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

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

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

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

» 会長

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

• SNS

» http://arclamp.hatenablog.com/

» @yusuke_arclamp

1

アジェンダ

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

•クラウドの進化

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

•クラウド時代のエンジニア

•まとめ

2

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

3


クラウドの類型化

4

ハードウェアネットワーク

仮想化OS

OS

ミドルウェア

コード

設定

データ

オンプレ IaaS PaaS SaaS

＜ユーザーの管理範囲＞


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

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

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

5


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

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

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

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

»IaaS（Infrastructure as a Service）

»例：AWS EC2

6


2.ミドルウェアのプラットフォーム化•仮想化できるのはインフラだけじゃない

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

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

•プラットフォームを利用する

»PaaS（Platform as a Service）

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

7


2.ミドルウェアのプラットフォーム化•プラットフォームも高度している

»Webアプリ基盤：AWS Elastic Beanstalk

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

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

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

»OSSライブラリと一緒

8


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

»つまり、if文が書ける

▸if {性能が悪ければ} then {サーバを足す}

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

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

»システム丸ごとコードで表現できる

9


クラウドファースト• 3つセットでクラウド技術

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

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

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

•クラウドファースト

»プラットフォームと自動化を最大限利用する

»オンプレからの単純移行（IaaS）では意味なし

10


ビジネスのスピードアップ•クラウドでITサービス運営が早くなる

»サービス＝「企画」「開発」「運用」という営み

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

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

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

»そのためにクラウドが大きな変化をもたらした

11

クラウドの進化

12


進化の歴史をたどってみる•アジャイル

• DevOps

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

13


アジャイル

14

アジャイル

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

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

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

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

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

•「企画→開発」のスピードアップ

»ウォーターフォールへの批判

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

アジャイル

プロジェクトマネジメントの基礎•プロジェクトマネジメント

»計画：QCDSを設定する

»実行：計画に従って作業を行う

»計測：計画と実績を比較する

»調整：計画と実績のズレを調整する

• QCDS

»Quality（品質）、Cost（費用）、Delivery（期日）、Scope（範囲）

16

アジャイル

ウォーターフォールの課題•ウォータフォール

»計画：全体を予測し、リソースを調達する

»計測：フェーズごとの中間成果物

»調整：プロジェクトマネージャーの力量

•失敗しがちなこと

»計画：正しく予測ができない

»計測：中間成果物では良くわからない

»調整：力量が足らない

17

アジャイル

アジャイルのアプローチ•計画：定期的で小さくする

•計測：動くソフトウエアで管理する

•調整：関係者全員を集めて話し合う

•プロセスからチームへ

»「個人の能力」から「チーム力を活かす」

»顧客も含めてチーム

18


DevOps

19

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

DevOps

DevOpsのテーマ•開発と運用は仲が悪い

»ITサービスを安定稼働するために変更プロセスを煩雑にする

»リリース回数を増やそうとすると相反する

• DevOpsが目指したこと

»徹底した自動化

»開発と運用における情報共有

»開発と運用が協業する文化

21

DevOps

カナリアリリース•ブルーグリーンデプロイメント

»本番環境をコピーして、新バージョンをリリース

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

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

•カナリアリリース

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

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

22

カナリアリリース

23

Web App DB

ルーター100

100


24

Web App DB

ルーター100

100

Web App DB


25

Web App DB

ルーター100

95

Web App DB

5


26

Web App DB

ルーター100

100

Web App DB


27

ルーター100

100

Web App DB

DevOps

カナリアリリース•可能な限りサービスを止めない

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

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

»もちろん、すべてのITシステムが同じ考え方ではないが参考になる部分はある

• A/Bテストへの応用も可能

»一部のユーザーに違うバージョンのアプリを試してもらう

28

DevOps

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

»「秘密のカナリア」

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

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

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

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

DevOps

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

»モンキー：サーバー

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

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

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

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

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

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


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

31


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


技術面 1/2•大きなシステムをサービスに分解する

»サービスごとにライフサイクルを分けられる

»サービスごとに非機能要件も分けられる

•サービスごとにリリースタイミングを分けることができる

»モノリシックなシステムは変更影響調査やテストに時間がかかっていた

33


技術面 2/2•サービスは疎結合に連携する

»キューを使った非同期メッセージング

»同期の場合はサーキットブレーカー付で

»データは共有せずに分散配置

34

処理A

処理B

ﾒｯｾｰｼﾞ

キュー

②キューに追加④キューから読み込み

①リクエスト

③処理完了

⑤キューを削除


組織面•サービスは1つのチームが担当する

»技術的観点の分割からサービス観点の分割へ

»それぞれが適切なリズムで活動できるようになる

»大型システムにおいても自主性をもったチーム運営を可能にする

»たくさんの（優秀な）アジャイルチーム

35


おさらい

36


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

• 2006年：クラウド＆ AWS EC2

• 2009年：DevOps ＆ AWS RDS

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

• 2011年：AWS Elastic Beanstalk

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

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

37


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

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

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

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

38

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

39


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

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

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

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

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

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

40


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

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

»DevOpsとITIL

»MSAとSOA

•それよりも「マインドセット」の変更を

»態度：be Agile

»技術：プラットフォームに合わせる

41

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

42


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

»実践できなくても、ちゃんと横目で見る！

•マネジメントも大事

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

»MSAに見られるような統合が促進される

43


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

»設計書に書いてあることを実装する作業はなくなる

•個人力からチーム力

»個人の力をチームの力に変えていくことが大事

44


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

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

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

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

45

開発

企画システム作り

運用

サービス運営

企画＋開発＋運用




ビジネスの中心になる•「ITがビジネスの最重要課題」なら、エンジニアがビジネス活動の重要な位置にいるべき

•エンジニアにもビジネススキルが必須

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

»チームビルディング

46

まとめ

47

まとめ

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

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

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

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

48

まとめ

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

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

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

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

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

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

49

まとめ

クラウド時代のエンジニア•技術の使われ方を意識する

•システム作りからサービス運営へ

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

•ビジネスの中心になる

50

最後に

51

お知らせ

今日の話が本になります•クラウドファーストアーキテクチャ設計ガイド

• 2016年8月刊行予定！

52

クラウド時代のエンジニアについて #sesfukui

Technology