Javaエンジニアのための“クラウド時代の過ごし方”

2016/5/24

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

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

Java Day Tokyo 2016

自己紹介

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

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

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

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

» 会長

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

• SNS

» http://arclamp.hatenablog.com/

» @yusuke_arclamp

1

Agenda

•クラウド時代とは何か

•クラウド時代のキーワード

»クラウド

»DevOps

»アジャイル

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

•どう過ごすべきか？

•まとめ

2

クラウド時代とは何か

3

エンジニアの仕事

ソフトウェアを「作る」•仕様を決める

•エンジニアがコードを書く

以上

4

でも「作る」だけじゃ使えない

ソフトウェアを作っても…•インフラがないと意味がない

•リリースしないと意味がない

•停止したら意味がない

•使いやすくないと意味がない

•改善し続けないと意味がない

»仕様、性能…

5

クラウド時代とは

「作る」から「運営する」へ•「ソフトウェアを作る」より「サービスを運営する」ことが大事

•ソフトウェアは使ってもらってビジネス的な効果をあげないと意味がない

»売上が上がる

»経費が下がる

6

サービスを運営する

7

ｻｰﾋﾞｽ機能

（ｺｰﾄﾞ）ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

サービスを運営する

開発だけが重要ではない•全ての要素のバランスで成り立つ

»良いコードは大事（でも、それだけじゃない）

▸構造：システム構造、フレームワーク

▸プロセス：WF/アジャイル、ドキュメント

»ソフトウェアがITサービスとして安定稼働し、業務が回ってサービスとして価値を提供する

▸運用、業務、企画なども関わる

8

「作る」から「運営する」へ

サービス運営は終わらない活動•しかも、要求はどんどん変化していく

»初回リリースはゴールではなくスタート

•では、どうやって変化に適応し続けるか？

9

クラウド時代のキーワード

10

クラウド時代のキーワード

アジャイル

クラウド/DevOps

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

11

クラウド時代のキーワード

アジャイル

クラウド/DevOps

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

12

アジャイル

プロジェクトマネジメントの基本•計画する：QCDSを決める

•実行する：計画従って作業する

•計測する：計画と実績のズレを測る

•調整する：ズレに対応する（QCDSの変更）※QCDS：Quality（品質）、Cost（費用）、Delivery（期限）、Scope（機能）

•ウォーターフォールの限界

»計画が、そんなに精度よくできない

13

アジャイル

アジャイルの考え方•計画：精度が出るぐらい短期にする

»リソースは固定化する

•計測：動くソフトウェアで判断する

•調整：定期的に関係者全員で話し合う

•調整を重視したマネジメントスタイル

»WFは計画と効率を重視している

14

アジャイル

変化に適応するプロセス•「早く作る」ための手法ではない

»適切なものを適切なタイミングで作るための手法

»変更が多いなら調整タイミングを増やした方が無駄が少ない、と考える

»計画精度が高いならWFのほうが無駄が少ない

•企画から開発への流れにリズムをもたらす

15

クラウド時代のキーワード

アジャイル

クラウド/DevOps

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

16

クラウド

ソフトウェア化するハードウェア•狭義には「ハードウェアの仮想化」

•広義には「コンピューティングリソースにおける規模の経済と従量課金」

•重要：ソフトウェア定義されるハードウェア

»ハードウェアの操作がソフトウェア化される

»ハードウェアのコピーや自動化ができるようになる

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

17

クラウド

クラウドの類型化

18

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

仮想化OS

OS

ミドルウェア

コード

設定

データ

オンプレ IaaS PaaS SaaS

＜ユーザーの管理範囲＞

クラウド

Platform as a Service•特に注目すべきはPaaS

•ミドルウェア＋稼働状態＝PaaS

»OSSフレームワークは静的コンポーネント

»PaaSは動的コンポーネント

•使うことで制約を受けるが便利になる

19

クラウド

PaaSのレベル•低：AWS RDS

»DBMS+CPU+ストレージ＋バックアップ＋…

•中：AWS BeansTalk

»LB+APSV＋監視＋自動再起動＋…

•高：Heroku

»Git＋CI/CD+APSV+…

20

クラウド

クラウドネイティブ•クラウドを前提にしてシステムを作ること

»特にPaaSの活用

•クラウドの制約に従うことで効率化する

»オンプレの作り方をクラウドに持ってくるのではなく、クラウドに最適化されたやり方でアプリケーションを考え直す

»特に運用が楽になる

21

DevOps

継続的なリリースにために•変えていきたい開発 vs 安定させたい運用

»昔は「作る」と「動かす」を分離することが効率的だった

•でも、もっとリリース回数を増やしたい

»10回/日以上

22

DevOps

CI/CDの発展形•継続的インテグレーション

»レポジトリからのチェックアウト＆自動テスト＆自動ビルド

»ハードウェアの自動構成＆自動デプロイ

•開発と運用の情報共有

»変更ログや通知の共有

»チャットbotによる自動通知

23

DevOps

カナリアリリース•カナリアリリース

»ブルーグリーンデプロイ、A/Bテスト

»本番環境を丸々コピーして新しいバージョンをリリースし、ユーザーのアクセス先を切り替えていく

•その先

»ダークカナリア：本番環境での機能テスト

»カオスモンキー：本番環境での再起動テスト

24

DevOps

運用を不要にしていく•理想は「運用の完全自動化」

»事件が起きたときの対応チームのみ

•開発時点で運用のことを考慮する

»運用しやすいように開発すればいいじゃん

»面倒なことはソフトウェアで自動化しよう

•開発から運用への流れにリズムをもたらす

25

クラウド時代のキーワード

アジャイル

クラウド/DevOps

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

26

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

サービス連携によるサービス•サービスの連携でサービスを実現する

»（小さな）サービスによって（大きな）サービスを動かす

»サービス＝独立した非機能要件を持つシステム

•先進企業の仕組みを調べたら、似たような仕組みだったのでMSAと名付けた

»技術論が先ではないことに注意

27

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

変化するために分割する•モノリシックでは部分の変更が全体に波及する

»変更で大変なのは事前調査とテスト

•サービスに分割されていれば変更の影響はサービス内部にとどまる

»APIに変更がなく、データベースは共有しない

▸API自身もバージョン管理すればよい

»よって、サービスは、それぞれのサイクルでリリースできる

28

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

変化とサービス分割•「サービスが適切に分割されていれば」

»あるサービスの変更が他のサービスに影響したら意味がない

•サービス分割はドメインに従う

»ドメイン≒業務

»システムへの変更要求は業務に起因するので当然

»DDD（ドメイン駆動設計）

29

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

変化するための技術とプロセスの集合•より良いサービス運営に最適化した結果

»アジャイル、クラウド/DevOpsの流れの先

• MSAは「する」ではなく「なる」

»MSAにしたい、というのは危険な発想

»変化に適応するサービスを突き詰めると勝手にMSAになるはず

30

サービスを運営する

31

ｻｰﾋﾞｽ機能

（ｺｰﾄﾞ）ITｻｰﾋﾞｽ

満足度

構造

開発 企画

運用 業務

プロセス

アジャイル

DevOps狭義のMSA

どう過ごすべきか？

32

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

考えることが増えた•企画、開発、運用のすべてにエンジニアとしてやれることがある

»これまでが分業されすぎてきた

33

開発

企画

ITサービス運営

運用

サービス運営

企画＋開発＋運用

企画＋開発＋運用

企画＋開発＋運用

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

Javaエンジニアの価値•「ちゃんとJavaでアプリが作れる」は価値

•加えて、サービス運営の視点を持つ

»例：開発生産性 ＜ 保守性

▸解析性、変更性、試験性など

34

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

エンジニアの生きる道 1/2•スペシャリストになる

»特定の技術やプロセスの専門家

»JavaのWebアプリ、SPA（JS）、AWS、Git+Jenkins、スクラム＋開発ツール、UI/UX、ログ解析など

»「圧倒的な専門性」を軸にする

35

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

エンジニアの生きる道 2/2•ゼネラリストになる

»分野をまたがってバランスを調整する役割

▸少なくとも業務と技術を跨ぐこと

»技術に立脚するならアーキテクト

▸エンタープライズ、ITサービス、Webアプリ、IoT、クラウド、データなど

▸業務に立脚するならビジネスプロデューサー、プロダクトオーナー、ITサービスデザイナなど

36

まとめ

37

まとめ

クラウド時代とは•「ソフトウェアを作る」から「サービスを運営する」へ

»使ってもらってビジネス的な効果をあげないと意味がない

•開発者だけではユーザーの価値にならない

38

まとめ

アジャイル、クラウド/DevOps•企画と開発の一体か

»定期的に調整しながら成果を出していく

•開発と運用の一体化

»ソフトウェア化するハードウェア

»クラウドネイティブへの移行

»面倒なことは自動化してしまえばいい

39

まとめ

マイクロサービスアーキテクチャ•サービス分割によるシステム構築

»変化の影響をサービス内に押し込めることでシステム全体として変化を許容する

»プロセス＋技術の両輪

▸アジャイル、クラウド、DevOpsがベース

»サービス分割≒ドメイン分割

»「する」ではなく「なる」

40

まとめ

クラウド時代のJavaエンジニア•ソフトウェアを作るだけでは価値にならない

»ITによってサービスを運営することが価値

»よりよく運営するために何をすべきか？は、あらゆるエンジニアが考えるべきこと

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

»正解はないし、新しい職種も生まれてくる

41

宣伝

コミュニティに行こう•自分が悩んでいる道の先にいる人に会える

•そして、発信しよう

42

日本Javaユーザーグループhttp://www.java-users.jp/• 月1回のナイトセミナー• 年2回の1日イベント（CCC）