クラウドネイティブ化は、本当に必要なのか？〜移行パターンと成功のポイント～

スピーカー Takumi Mizuno  Cloud Ace, lnc. / Sr.Specialist  Web アプリケーション
エンジニアとして 3 年間で 15 案件に参画し、要件定義、設計、実装、テストまで幅広く担当。  現在は Application Modernization 領域に参画し、クラウドネイティブなシステムに移行するための設計や開発を行っている。  得意領域は、アプリケーション設計 (DDD, Microservices)。 

1. はじめに  2. なぜクラウドネイティブ化が必要なのか  3. 移行パターン  4. 成功ポイント  5.
クラウドネイティブ化における考え方のシフト  6. まとめ  アジェンダ 

目指すこと  • なぜクラウドネイティブ化が必要かを理解してもらう   • ユースケースに適した移行アプローチを理解してもらう   • クラウド
ネイティブ化のイメージを持ってもらう     目指さないこと  • クラウドネイティブ化の具体例を知ってもらう   発表の位置づけ 

なぜクラウドネイティブ化が必要なのか〜 DORA から分かるクラウドリフトのみとクラウドネイティブの比較〜

• ビジネス  ◦ レガシーシステムがビジネス要件に適合できない（新しい要件に適合したい）  ◦ レガシーシステムがビジネス変化に追いつけない（アジリティを高めたい）  ◦ ビジネス価値を高めたい  •
そのほか  ◦ レガシーシステムが複雑すぎる（保守性を高めたい）  ◦ 長期的なコストを削減したい  ◦ リスクを減らしたい（セキュリティ, コンプライアンス, 可用性, etc.）  モダナイゼーションの動機  参照：7 Options To Modernize Legacy Systems

State of DevOps Report https://cloud.google.com/devops/state-of-devops/

クラウドらしい、サーバーレスやマネージドサービス等の活用を行う場合、     単に「クラウド利用」する場合と比べて、   30%  組織パフォーマンスが高くなることが予測される   クラウドネイティブ化の効果 
参照：Accelerate State of DevOps Report 2023

単なる「クラウド利用」では結果がまちまち  引用：Accelerate State of DevOps Report 2023

オンプレと同様の運用方法を行っており、クラウドの恩恵を受けられないまま、「新しい環境への複雑さ」と「認知負荷」が増えただけになっている。  「クラウド利用」だけではダメな原因  認知負荷  クラウドの恩恵  参照：Accelerate State of DevOps Report
2023

クラウドらしい活用をすることで、全体的なパフォーマンスが上がっていることが分かる。  クラウドネイティブによるパフォーマンス向上  引用：Accelerate State of DevOps Report 2023

-   -   参考：クラウドが従業員に与える影響  引用：Accelerate State of DevOps Report
2023

クラウドネイティブ化の効果  引用：Accelerate State of DevOps Report 2023

移行パターン〜メリデメとユースケースで比較〜

「リプレイス」            ビジネス要件から刷新し、ゼロから再設計または書き直す。   「リビルド」 
          ビジネス要件を維持しながら、ゼロから再設計または書き直す。   クラウドネイティブ化のプラン  「リプラットフォーム」            実行環境を新しいものに移行。コードの構造、機能、動作は変更せず、最小限のコード変更にとどる。  参照：7 Options To Modernize Legacy Systems ※画像はOpenArt AIで生成

クラウドネイティブ化のプラン  リプラットフォームリビルドリプレイス use case 1. 定期的なリファクタが実施されている
2. 今後、ビジネス改善を行う予定がない 1. 定期的なリファクタが実施されていない 2. 今後、ビジネス改善を行う予定がある 1. 定期的なリファクタが実施されていない 2. 直近で、ビジネス改善を行う予定がある pros 1. 移行コストを抑えながら、運用コスト削減ができる 1. 運用コスト削減だけでなく、アジリティや保守性の向上、セキュリティやコンプライアンス等のリスク低減も可能 1. 他の移行プランよりビジネスへの効果がある可能性が高い 2. 運用コスト削減だけでなく、アジリティや保守性の向上、セキュリティやコンプライアンス等のリスク低減も可能 cons 1. リファクタが定期的に行われていない場合、他の移行プランより移行コストが上がる可能性がある 2. 運用コスト以外は改善されにくい 1. リプラットフォームより移行コストが上がる可能性がある 1. リプラットフォームより移行コストが上がる可能性がある

成功ポイント〜 DORA metrics による DevOps とビジネス成果の紐づけ〜

確認ポイント  • モダナイズが目的になっていないか  ◦ そのモダナイズはビジネス課題を解決するのか？  ◦ モダナイズによる痛みを受け入れられるか  • 「ものさし」を持っているか  •
長期的な視点が持てるか  ◦ 未知への柔軟で迅速な対応にどれだけ投資できるか 

モダナイズが目的になっていないか  • そのモダナイズはビジネス課題を解決するのか？  ◦ どのような課題があるのか？  ▪ 運用コストがかかりすぎている  ▪ トイルが多く、現状維持の活動に追われている  ▪
ビジネスの要求速度にシステム改修が追いついていない etc.  • モダナイズによる痛みを受け入れられるか？  ◦ モダナイズにかかる工数  ◦ 認知負荷の増加  ◦ 過渡期の運用負荷の増加 

「ものさし」を持っているか  以下の 3 つが明確にすることが重要なポイントである。  1. ものさしは何か（評価基準）  2. 現状どれくらいできているのか（現在地）  3. 目指すべき目標はどこか（ゴール） 

「ものさし」を持っているか  DORA が提唱するソフトウェアデリバリーパフォーマンスの評価軸  • 速度  • 変更のリードタイム  ◦ コードの変更を
commit してからデプロイするまでの時間  • デプロイの頻度  ◦ 変更を本番環境に push する頻度  • 安定性  • 変更時の障害率  ◦ デプロイにより障害が発生し、すぐに対処する必要が生じる頻度  • デプロイ失敗時の復旧までの時間  ◦ デプロイの失敗時に復旧にかかる時間  参照：Accelerate State of DevOps Report 2023

「ものさし」を持っているか  参照：DORA Quick Check DORA では、Quick Check で現在地の計測が可能。業界ごとの水準と比較も可能。  

長期的な視点が持てるか  • 長期的な視点が持てるか  ◦ 未知への、柔軟で迅速な対応にどれだけ投資できるか 

クラウドネイティブ化における考え方のシフト

クラウドネイティブ化のアプローチ  • サーバーレス化  • 疎結合アーキテクチャ化  ◦ フロントエンドとバックエンドの分離  ◦ マイクロサービス化 
◦ ゼロトラスト化 etc.  • DevOps 改善  ◦ CI/CD  ◦ オブザーバビリティ  ◦ SLO　　　　　　　　　　　　　　　　　etc.  • AI 導入 

参考：技術的アプローチの効果  引用：Accelerate State of DevOps Report 2023

クラウドネイティブ化のアプローチ  • サーバレス化  • 疎結合アーキテクチャ化  ◦ フロントエンドとバックエンドの分離  ◦ マイクロサービス化 
◦ ゼロトラスト化 etc.  • DevOps 改善  ◦ CI/CD  ◦ オブザーバビリティ  ◦ SLO　　　　　　　　　　　　　　　　　etc. 

サーバーレス化例 

考え方の違いを生む要因  引用：PaaS、IaaS、SaaS、CaaS の違い

IaaS とサーバーレスの考え方の違い  • 課金モデル  • 運用  • カスタマイズ性  • アーキテクチャ 
• ゼロトラスト 

IaaS とサーバーレスの考え方の違い  • 課金モデル  ◦ IaaS は、使用状況に関係なく、プロビジョニングしたインスタンスに応じて課金が発生。サーバーレスは使った分だけ課金される従量制。  • 運用 
◦ サーバーレスはフルマネージド型が多いため、クラウドプロバイダーがインフラ管理をやってくれる範囲が大きい（運用負荷の低減）  • カスタマイズ性  ◦ IaaS の方が高い。（運用コスト削減とカスタマイズ性はトレードオフ）  

IaaS とサーバスの考え方の違い  • アーキテクチャ  ◦ サーバーレスはユースケースに特化した製品が多い。そのため、おのずとマイクロサービスのような構成になっていく。その考え方のシフトができると、「まずは新機能をサーバレスサービスで開発してみる」のような方針も可能。
  • ゼロトラスト  ◦ サーバーレス化を進めていくと、どのリソースも外部APIベースのアクセスが多くなる。そのため、内部ネットワークの管理負荷の低減に繋がる。（代わりに認証/認可をキッチリ行う必要性があるが、そこはサーバーレスの機能を活用することで負担は多くない）  

まとめ

目指すこと  • なぜクラウドネイティブ化が必要かを理解してもらう   • ユースケースに適した移行アプローチを理解してもらう   • クラウド
ネイティブ化のイメージを持ってもらう     目指さないこと  • クラウドネイティブ化の具体例を知ってもらう   発表の位置づけ 

クラウドらしい、サーバーレスやマネージドサービス等の活用を行う場合、     単に「クラウド利用」する場合と比べて、   30%  組織パフォーマンスが高くなることが予測される   クラウドネイティブ化の効果 
参照：Accelerate State of DevOps Report 2023

クラウドネイティブ化の効果  引用：Accelerate State of DevOps Report 2023

「リプレイス」            ビジネス要件から刷新し、ゼロから再設計または書き直す。   「リビルド」 
          ビジネス要件を維持しながら、ゼロから再設計または書き直す。   クラウドネイティブ化のプラン  「リプラットフォーム」            実行環境を新しいものに移行。コードの構造、機能、動作は変更せず、最小限のコード変更にとどる。  参照：7 Options To Modernize Legacy Systems ※画像はOpenArt AIで生成

確認ポイント  • モダナイズが目的になっていないか  ◦ そのモダナイズはビジネス課題を解決するのか？  ◦ モダナイズによる痛みを受け入れられるか  • 「ものさし」を持っているか  •
長期的な視点が持てるか  ◦ 未知への柔軟で迅速な対応にどれだけ投資できるか 

クラウドネイティブ化のアプローチ  • サーバレス化  • 疎結合アーキテクチャ化  ◦ フロントエンドとバックエンドの分離  ◦ マイクロサービス化 
◦ ゼロトラスト化 etc.  • DevOps 改善  ◦ CI/CD  ◦ オブザーバビリティ  ◦ SLO　　　　　　　　　　　　　　　　　etc. 

IaaS とサーバーレスの考え方の違い  • 課金モデル  • 運用  • カスタマイズ性  • アーキテクチャ 
• ゼロトラスト 

Thank you.

クラウド ネイティブ化は、 本当に必要なのか？ 〜移行パターンと成功のポイント～

クラウド ネイティブ化は、 本当に必要なのか？ 〜移行パターンと成功のポイント～

More Decks by Cloud Ace

Featured

Transcript

クラウドネイティブ化は、本当に必要なのか？〜移行パターンと成功のポイント～

クラウドネイティブ化は、本当に必要なのか？〜移行パターンと成功のポイント～