Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ITトレンドに見る日本のエンタープライズITについて

33,010 views

Published on

2017年9月に都内某所の勉強会で利用した資料です。

Published in: Technology
  • Sex in your area is here: www.bit.ly/sexinarea
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: www.bit.ly/2AJerkH
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Sex in your area for one night is there tinyurl.com/hotsexinarea Copy and paste link in your browser to visit a site)
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Girls for sex are waiting for you https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Meetings for sex in your area are there: https://bit.ly/2TQ8UAY
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

ITトレンドに見る日本のエンタープライズITについて

  1. 1. ITトレンドに見る 日本のエンタープライズITについて 2017/9 鈴木雄介 グロースエクスパートナーズ株式会社 執行役員 日本Javaユーザーグループ 会長
  2. 2. 自己紹介 鈴木雄介 • グロースエクスパートナーズ(株) » 執行役員/アーキテクチャ事業本部長 » http://www.gxp.co.jp/ • 日本Javaユーザーグループ » 会長 » http://www.java-users.jp/ • SNS » http://arclamp.hatenablog.com/ » @yusuke_arclamp 1
  3. 3. アジェンダ • ITトレンドの流れ »Agile »Cloud »DevOps »Microservices • 日本のエンタープライズITの状況 • 今後にむけて 2
  4. 4. ITトレンドの流れ 3
  5. 5. ITトレンドの流れ 2001年からの流れの理解 • 基本的なテーマは「ITサービスの改善速度を上げる」 4 2001年 Agile 2009年 DevOps 2006年 Cloud 2014年 Microservices
  6. 6. ITトレンドの流れ ITサービスの改善速度を上げる • いかにITサービス提供サイクルを早く回すか 5 ビジネス 要件 企画 開発 運用
  7. 7. ITトレンドの流れ Agile 6
  8. 8. Agile アジャイルとは • 2001年:アジャイルソフトウェア開発宣言 »プロセスやツールよりも個人と対話を、 »包括的なドキュメントよりも動くソフトウェアを、 »契約交渉よりも顧客との協調を、 »計画に従うことよりも変化への対応を • ウォーターフォールの否定 7参考:http://www.agilemanifesto.org/iso/ja/ ビジネス 要件 企画 開発 運用
  9. 9. Agile ウォーターフォールの考え方 • 最終成果物に向けて、フェーズごとの中間成果物を定め、 段階的に品質を確認する • 中間成果物は基本的に文書 8 基本設計 実装 テスト要件定義 計 画 受 入 文書 文書 文書 文書文書
  10. 10. Agile ウォーターフォールの課題 • 途中で「欲しい最終成果物」が変化してしまう »終わるころにはビジネス要件がさらに変化してもらう • 中間成果物では品質が確認できない »文書を見ているだけでは評価できないことがある • プロジェクト全体の状況把握が困難 »PMに集まる情報だけでは情勢の見極めにくい 9
  11. 11. Agile アジャイルの考え方 • リソースを定め、短期&定期的に計画と評価を繰り返す • 評価は関係者全員で動くソフトウエアを確認 10 設計 実装 テスト計 画 受 入 設計 実装 テスト計 画 受 入 設計 実装 テスト計 画 受 入
  12. 12. Agile アジャイルのメリット • 「今」欲しいものを得られる »このリリースで何かを得たいか、を決めればいい • 定期的に動く成果物で評価できる »動く成果物へのフィードバックから改善をしていく • チームが判断する »現場チーム内で状況が共有できるので判断が行いやすい 11
  13. 13. Agile Scrum 12 スプリント プランニング スプリント レビュー スプリント バックログ デイリー スクラム プロダクト バックログ インクリメント プロダクト プロダクト利用 仕様検討 スプリント レトロスペクティブ 開発作業 リリース フィードバック 顧客 プロダクト オーナー 開発チーム アイデア
  14. 14. Agile ウォーターフォールとアジャイル • 計画主導 vs 調整主導 »ウォーターフォールは「計画からズレた時に調整する」 »アジャイルは「毎回、調整する」 13 GOAL GOAL START GOAL START GOALGOALGOAL
  15. 15. Agile Agileがもたらした変化 • ITサービスは変化し続ける »要件が社内ではなく社外にある場合、ユーザーからのフィードバ ックによって改善させていくしかない »「プロジェクト(有期)」から「プロダクト(無期)」へ • チーム活動を主体にする »絶対的なリーダーを求めるよりもチーム活動を重視する • ただし、すべてに最適ではない »SoR < SoE、Mode 1 < Mode 2 14
  16. 16. ITトレンドの流れ Cloud 15
  17. 17. Cloud クラウドとは • 2006年「雲(クラウド)」 »データやアプリケーションをインターネットの向こう側にあるサ ーバーに配置し、ユーザーの持っているパソコンやスマートフォ ンなどのデバイスから利用可能にする。すべてが雲の中のどこか にあればいい ▸Google社CEO エリック・シュミット »ITリソースを所有するのではなく、利用する ▸「発電機の購入」から「発電所による電力の従量課金」 16
  18. 18. Cloud クラウドにおける3つの変化 • 1.インフラのサービス化 • 2.ミドルウェアのサービス化 • 3.システム構成のコード化 17
  19. 19. Cloud 1.インフラのサービス化 • 仮想化技術の応用 »SDx:ソフトウェアであらゆるものを定義する »広大なデータセンターの上に自分のための仮想インフラを構築 • インフラを「所有」から「利用」へ »IaaS(Infrastructure as a Service) »例:AWS EC2 18
  20. 20. Cloud 2.ミドルウェアのサービス化 • サービス化されたミドルウェア=プラットフォーム »PaaS(Platform as a Service) »AWS RDSはデータベースサーバーのレンタルではない ▸バックアップもクラスタ構成も設定するだけ • 高度化するプラットフォーム »Webアプリ基盤:AWS Elastic Beanstalk »開発ライフサイクル込み基盤:AWS CodeDeploy/CodePipeline »サーバレス:AWS Lambda 19
  21. 21. Cloud 3.システム構成のコード化 • 仮想化されたインフラやプラットフォームがコードから操 作ができる »つまり、「構成する」ことの自動化ができる • 非機能要件がコーディングできる »これまでは機能要件しかコーディングできなかった »サービスそのものがコードで表現できる 20
  22. 22. Cloud Cloudがもたらした変化 • アプリとインフラの境界線が曖昧に »すべてがコーディング可能に。機能要件と非機能要件が曖昧に • プラットフォームを積極的に利用する »プラットフォーム=動くライブラリ 21
  23. 23. ITトレンドの流れ DevOps 22
  24. 24. DevOps DevOpsのはじまり • 2009年:DevOps »Agile 2008:Agile Infrastructure & Operations ▸政府系データセンターの移行にスクラムを導入した事例発表 ▸インフラ/運用系にアジャイル文化を導入しようとする機運 »Velocity 2009:10+ Deploys Per Day ▸Flickrにおける開発と運用の協業について »Devopsdays Ghent 2009 ▸ここから「DevOps」が生まれる 23参考:「The (Short) History of DevOps」(Damon Edwards) https://www.youtube.com/watch?v=o7-IuYS0iSE
  25. 25. DevOps Dev❤Opsのテーマ • そもそも開発と運用は仲が悪かった »「変更」と「安定稼働」は相反する • 頻繁に変更することが前提になった »リリース回数の圧倒的な増加 »システムの停止=価値の棄損 • 開発が運用のことを意識すればいい »大抵の運用作業が自動化できてしまう 24 ビジネス 要件 企画 開発 運用
  26. 26. DevOps ブルーグリーンデプロイメント • システム構成の自動化がもたらしたアイデア »本番環境をコピーして、新バージョン用の本番環境を作る »ユーザーのアクセスを切り替える ▸もちろん、切り戻しも一瞬 25 1.0 1.1 1.0 1.1 1.0 1.1 1.0 1.1
  27. 27. DevOps カナリアリリース • ブルーグリーンの発展としての考え方 »前提:無停止リリースが可能で切戻しコストも低い • 一部の犠牲(の可能性)によって全体を救う »仮リリースが非常に容易にできてしまう ▸一部のユーザーにだけ新バージョンを提供し、エラーが出たら切戻す ▸本番でしか出ない問題は本番で確認するしかないし »検証時間をかけるぐらいならリリースしてしまえ ▸※もちろん、程度問題 26
  28. 28. DevOps カオスモンキー • 本番環境をランダムにダウンさせる製品 »モンキー:サーバー »ゴリラ:アベイラビティゾーン »コング:リージョン(≒データセンター) • 自動化スクリプトのテスト »本番環境でしか確認ができない »もしものために平日日中に実行する 27参考:https://github.com/Netflix/SimianArmy
  29. 29. DevOps DevOpsがもたらした変化 • リリース(変更)が日常の行為 »Amazonは1時間に最大1000回もデプロイする ▸ http://www.publickey1.jp/blog/12/amazon11000_aws_reinventday2_am.html »繰り返すからこそ自動化するメリットが出る • コードが運用組織を不要化していく »運用機能を開発すればオペレーターは不要 »不要になるぐらい自動化しないとリリースが日常化しない 28
  30. 30. Microservices 29
  31. 31. Microservices マイクロサービスアーキテクチャとは • 2014年:「Microservceis」 by James Lewis »2011年:先端的なウェブサービス企業が似たようなアーキテクチ ャスタイルを取っていることが議論に »33rd Degree 2012「Microservices - Java, the Unix Way」 • DevOpsの発展系 • 実体に名前を付けたもの »コンセプトありきではない 30 参考:http://martinfowler.com/articles/microservices.html 参考: http://2012.33degree.org/talk/show/67 ビジネス 要件 企画 開発 運用
  32. 32. Microservices マイクロサービスの特徴 • Componentization via Services • Organized around Business Capabilities • Products not Projects • Smart endpoints and dumb pipes • Decentralized Governance • Decentralized Data Management • Infrastructure Automation • Design for failure 31 https://martinfowler.com/articles/microservices.html
  33. 33. Microservices モノリシックの弊害 • 1つのシステム内に全ての機能 »実行時の依存/影響範囲が見えにくい »影響調査とリグレッションテストに工数を消費 »部分への性能劣化が全体に波及しやすい • 巨大化すると難易度があがる »個別変更でも全体調整 »部分変更でもシステム全体をリリース 32
  34. 34. Microservices マイクロサービスアーキテクチャ • 機能別にサービスを分割する »APIにより実行時の依存/影響範囲が限定しやすい »サービスが独立しており、他とは疎結合 • 巨大化してもサービス単位で管理 »サービス単位に好きなタイミングで仕様変更、リ ソース変更ができる ▸「速さ」ではなく「独立性」が重要 33
  35. 35. Microservices マイクロサービス化の目的と手段 • アジャイルを巨大システムで実現するための仕掛け »システム全体が巨大になろうとも、機能別にアジャイルチームが 活動することを保証する • 機能別のサービス分割が推進された理由 »DevOpsの推進によりサーバ管理コストが低減された ▸先端企業では数万ノードを管理している »ネットワークのオーバーヘッドは依然として課題 34
  36. 36. Microservices SOAとMSA • SOA »巨大な既存システム群を活用し、それぞれを自動連携させる ▸EAI/ESB/BPMのような「賢い連携機能」 »封建制的(個別システム内までは口を出さないが中央はある) • MSA »発展的にシステムを分割してきた結果 »民主主義的(クラウドが産業革命をもたらした) 35
  37. 37. Microservices 課題:不整合の許容 • 疎結合=非同期=不整合 »コンポーネント間を疎結合にす ると不整合が発生する可能性が 高まる • Amazonのクーポン »密結合にするなら運用でリカバ リしたほうがよい 36
  38. 38. Microservices 課題:障害対応 • レジリエンス(復元力) »パーツごとに障害発生を抑止する考え方の限界 »接続先の障害発生を前提として影響範囲を限定化する考え方 »品質を下げるのではなく、品質の定義が変わる • サーキットブレーカー »対向システム呼び出し時の異常処理対応をパターン化する ▸タイムアウト、自動リトライ、デフォルト値、値のキャッシュ、例外処理 記述など 37
  39. 39. Microservices 課題:テスト • 無限のテストケース »個別パーツのテストがパスしても、組み合わせでエラーになる »しかも、個別パーツは好き勝手にバージョンアップする ▸Test Doubles(スタブ/モック)の限界 • Consumer-Driven Contract testing »コンシューマーが要求するAPI挙動を契約として定義し、プロバ イダが契約を検証して破壊的変更を防ぐ 38
  40. 40. Microservices マイクロサービスがもたらす変化 • 現在でも進化を続けている状況 »サーバレス、コンテナオーケストレーション、非同期ストリーム • プラットフォームと個別サービスというエコシステム »オンラインゲーム向け、IoT向けなどのドメイン特化プラットフォ ームの出現 ▸新たなプラットフォーマーの出現 ≒ 現代のWintelは誰になるのか »標準化のEU、実力主義の北米 39
  41. 41. ITトレンドの流れ サマリ 40
  42. 42. ITトレンドの流れ サマリ 41 2001年 Agile 2009年 DevOps 2006年 Cloud 2014年 Microservices 2010年 ブルーグリーンデプロイメント 2011年 Microservicesのアイデア 2012年 カナリアリリース 2006年 AWS EC2 2009年 AWS RDS 2011年 AWS Elastic Beanstalk 2014年 AWS Lambda
  43. 43. ITトレンドの流れ サマリ • システム開発にアジャイルの考え方が求められた »計画駆動から調整駆動へ • クラウドの発展によりアジャイルに適した仕組みが進化 »自動化による疎結合アーキテクチャの実現 • 現時点ではMicroservicesとして進化中 »マネジメント論+アーキテクチャ論 42
  44. 44. 日本のエンタープライズITの状況 43
  45. 45. 日本のエンタープライズITの状況 ITトレンドについていけているのか? • なかなか厳しい状況 »新興ウェブサービス企業はついていこうとしている »危機感のあるユーザー企業で取り組みが推進されつつある • 理由 »8割のエンジニアがSIer側に勤めている(北米は逆) »稟議というボトムアップ&合議主義な意思決定システム »エラーゼロを重視する文化と完成された体系 »ITシステムを資産化して償却する会計制度 44
  46. 46. 日本のエンタープライズITの状況 Agile • 稟議という意思決定システムは計画主導になりがち »「やってみなければ分からない」が通じにくい • 外部調達なチームを維持するが困難 »社内にエンジニアが少ないのでリソース調達が外部頼りになる »準委任契約のコストは資産ではなく経費 • 継続的に改善し続ける=「保守」から抜け出せない »「守りの作業」が中心になりがち 45
  47. 47. 日本のエンタープライズITの状況 DevOps • 運用部と開発部という組織の壁 »お互いが文書でやり取りすることになれてしまっている • 過去の知見/観点から抜け出せない »クラウドを仮想化インフラ(IaaS)としてしか扱えない »自動化文化 • エラーゼロが常識 »エラーゼロであるべき領域はあるが、多くのケースではリロード で済んでいるのは? 46
  48. 48. 日本のエンタープライズITの状況 Microservices • AgileやDevOpsを積み上げていないと実践できない »単にシステムを分けることを目的にしてもうまくいかない »AgileやDevOpsを積み上げていくと自然になっていく • 企業にとってITサービスがプロダクトではない »いまだにプロジェクトであり、コスト(資産)である »デジタルトランスフォーメーションが未成熟 47
  49. 49. 今後にむけて 48
  50. 50. 今後にむけて 乗り越えるべきこと • デジタルトランスフォーメーション »ITサービスは戦略であり継続的に金がかかる »意思決定システム、会計制度、品質の再定義 • 外部ITサービス開発企業とのパートナーシップ »エンジニアの外部調達はしばらく続く »段階的に内製化を推進していく 49
  51. 51. 今後にむけて 期待をこめて • 改めてAgileの機運は高まっている気がする »デジタルトランスフォーメーションへの経営的興味 • アーキテクチャ論としてアジャイルを語れる »マネジメント論だけの状況よりも具体的 • Microservicesは段階的に取り組める »全部を作り直すのではなく、必要な部分からMicroservices化 »再構築でMicroservicesはナンセンス 50

×