Java Day Tokyo 2016 Javaエンジニアのための “クラウド時代の過ごし⽅” 2016/5/24 鈴⽊雄介 グロースエクスパートナーズ株式会社 執⾏役員 ⽇本Javaユーザーグループ 会⻑ ⾃⼰紹介 鈴⽊雄介 • グロースエクスパートナーズ（株） » 執⾏役員/アーキテクチャ事業本部⻑ » 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 サービスを運営する 構造 機能 （ｺｰﾄﾞ） プロ セス 業務 運⽤ 開発 IT ｻｰﾋﾞｽ ｻｰﾋﾞｽ 満⾜度 企画 7 サービスを運営する 開発だけが重要ではない • 全ての要素のバランスで成り⽴つ » 良いコードは⼤事（でも、それだけじゃない） ▸構造：システム構造、フレームワーク ▸プロセス：WF/アジャイル、ドキュメント » ソフトウェアがITサービスとして安定稼働し、業務 が回ってサービスとして価値を提供する ▸運⽤、業務、企画なども関わる 8 「作る」から「運営する」へ サービス運営は終わらない活動 • しかも、要求はどんどん変化していく » 初回リリースはゴールではなくスタート • では、どうやって変化に適応し続けるか？ 9 クラウド時代のキーワード 10 クラウド時代のキーワード アジャイル クラウド/DevOps マイクロサービスアーキテクチャ 11 クラウド時代のキーワード アジャイル クラウド/DevOps マイクロサービスアーキテクチャ 12 アジャイル プロジェクトマネジメントの基本 計画する：QCDSを決める • 実⾏する：計画従って作業する • 計測する：計画と実績のズレを測る • 調整する：ズレに対応する（QCDSの変更） • ※QCDS：Quality（品質）、Cost（費⽤）、Delivery（期限）、Scope（機能） • ウォーターフォールの限界 » 計画が、そんなに精度よくできない 13 アジャイル アジャイルの考え⽅ • 計画：精度が出るぐらい短期にする » リソースは固定化する 計測：動くソフトウェアで判断する • 調整：定期的に関係者全員で話し合う • • 調整を重視したマネジメントスタイル » WFは計画と効率を重視している 14 アジャイル 変化に適応するプロセス • 「早く作る」ための⼿法ではない » 適切なものを適切なタイミングで作るための⼿法 » 変更が多いなら調整タイミングを増やした⽅が無駄 が少ない、と考える » 計画精度が⾼いならWFのほうが無駄が少ない • 企画から開発への流れにリズムをもたらす 15 クラウド時代のキーワード アジャイル クラウド/DevOps マイクロサービスアーキテクチャ 16 クラウド ソフトウェア化するハードウェア 狭義には「ハードウェアの仮想化」 • 広義には「コンピューティングリソースにおけ る規模の経済と従量課⾦」 • • 重要：ソフトウェア定義されるハードウェア » ハードウェアの操作がソフトウェア化される » ハードウェアのコピーや⾃動化ができるようになる » ⾮機能要件がコーディングできる 17 クラウド クラウドの類型化 ＜ユーザーの管理範囲＞ オンプレ IaaS PaaS SaaS データ 設定 コード ミドルウェア OS 仮想化OS ハードウェア ネットワーク 18 クラウド 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 サービスを運営する 構造 運⽤ 狭義の 機能 IT DevOps MSA （ｺｰﾄﾞ） ｻｰﾋﾞｽ プロ セス 業務 ｻｰﾋﾞｽ 満⾜度 開発 アジャイル 企画 31 どう過ごすべきか？ 32 クラウド時代のエンジニア 考えることが増えた • 企画、開発、運⽤のすべてにエンジニアとして やれることがある » これまでが分業されすぎてきた サービス運営 企画＋開発＋運⽤ 企画＋開発＋運⽤ 運⽤ 企画＋開発＋運⽤ 開発 ITサービス運営 企画 33 クラウド時代のエンジニア 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 宣伝 コミュニティに⾏こう ⾃分が悩んでいる道の先にいる⼈に会える • そして、発信しよう • ⽇本Javaユーザーグループ http://www.java-users.jp/ • ⽉1回のナイトセミナー • 年2回の1⽇イベント（CCC） 42
© Copyright 2024 Paperzz
