アプリケーションの合理化: 移行工程でこの最初の一歩が必要な理由
Google Cloud Japan Team
※この投稿は米国時間 2020 年 12 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。
アプリケーションの合理化とは、アプリケーション インベントリを調べ、どのアプリケーションを廃止、保持、再投稿、再プラットフォーム化、リファクタリング、再定義する必要があるかを判断するプロセスです。これは、すべての企業にとって投資または投資撤退の決定を行う際に重要となるプロセスです。アプリケーションの合理化は、アプリケーションを実行している場所（クラウド内かどうか）に関係なく、アプリ ポートフォリオ全体を良好な状態に維持するうえで重要です。また、クラウドへの移行を検討している場合、アプリケーションの合理化はクラウドの採用または移行の取り組みへの第一歩となります。
本ブログでは、アプリケーション ポートフォリオの合理化とモダナイゼーションを行うための段階的なプロセスを説明しながら、推進要因と課題を探っていきます。また、この投稿は、アプリの合理化とモダナイゼーションのトピックを取り扱うブログ投稿シリーズの初回でもあります。
組織のアプリケーション合理化には推進要因がいくつかあり、それらは主に冗長性の削減、技術的負債の返済、増大する費用への対処を中心としたものです。以下は具体的な例です。
M&A（合併と買収）により新たに買収したビジネスのアプリケーションとサービスを導入しているが、その多くは、すでに配備されているものと重複している可能性がある。
サイロ化された事業部門が IT 組織の監視と管理の範囲外に存在するソフトウェアを独自に購入している。
デジタル トランスフォーメーションに着手し、オペレーションの改善とメンテナンス費用の削減を目指して既存の投資を再検討している。ビジネス価値を最大化し、リスクを最小化するには、アプリ モダナイゼーションのための CIO ガイドをご参照ください。
アプリケーションの合理化に関連する課題にはどのようなものがあるか、いくつかご紹介します。
高い複雑性と無秩序な拡散により、可視性が制限され、膨大なアプリケーション ポートフォリオ全体のどこで重複が起きているかを確認するのが困難になっている。
得体の知れないアプリケーションが存在する。廃止計画を十分に実施しなかった、または正常に完了しなかったという理由だけで、アプリケーションが実行されていることがよくある。
最新のアプリケーション インベントリが利用できない。より新しいアプリケーションとクラウド サービスを考慮していますか？
すべてのアプリケーションの場所と動作を把握している場合でも、特定のアプリケーションに最適なアプローチを決定するための秩序だった決定モデルまたはヒューリスティクスが不足している可能性がある。
適切な事前計画と目標設定がなければ、取り組み全体の ROI と TCO を測定するのが難しくなり、変革プロセスの途中で複数のイニシアチブが放棄されることになる。
アプリケーション インベントリを取得する
アプリの合理化に進む前に、アプリケーション インベントリの意味を定義しましょう。
アプリケーション インベントリは、組織内に存在するすべてのアプリケーションのカタログとして定義されています。
これには、ビジネス機能、アプリケーションの所有者、ワークロード カテゴリ（ビジネス クリティカル、内部など）、テクノロジー スタック、依存関係、MTTR（平均復元時間）、連絡先など、アプリケーションに関するすべての関連情報が含まれます。IT リーダーが十分な情報に基づいて意思決定を行い、アプリケーション ポートフォリオを合理化するには、信頼できるアプリケーション インベントリを用意することが重要です。アプリのインベントリがない場合でも、絶望する必要はありません。まず、発見プロセスに取り組み、すべてのアプリのインベントリとアセット、リポジトリを 1 か所にカタログ化します。
アプリケーションの合理化とモダナイゼーションを成功させるための鍵は、エンジニアリングの問題のようにアプローチすることです。つまり、簡単な作業から複雑な作業へ順を追って進めることであり、継続的な改善のためのフィードバック ループを使用する反復プロセスです。
青写真を作成する
アプリケーションの合理化、モダナイゼーションにおける重要な概念は、各アプリケーションの適切な青写真を見つけることです。
保持 - アプリケーションをそのまま維持する（現在の環境でホストする）
破棄 - アプリケーションを廃止し、ソースで計算する
再ホスト - 同様のコンピューティングを他の場所に移行する
再プラットフォーム化 - アプリケーションをアップグレードし、ターゲットに再インストールする
リファクタリング - アプリケーションに変更を加えて、クラウド ネイティブ特性に近づける
再定義 - 再設計と再構築
アプリケーションのモダナイゼーションへの 6 ステップ
以下に概説する 6 ステップのプロセスは、アプリケーションのモダナイゼーションのための構造化された反復的アプローチです。ステップ 1～3 は、モダナイゼーション工程のアプリケーション合理化の側面を示しています。
ステップ 1: 発見 - データを収集する
データは、アプリの合理化プロセスの基盤です。すべてのアプリのアプリ インベントリ データを一貫した方法で収集します。事業部門全体に複数の形式のデータがある場合は、データを正規化する必要になる場合があります。通常、古いアプリ インベントリはなんらかの形で CMDB データベースまたは IT スプレッドシートで探し出せます。組織にアプリケーション インベントリがない場合は、自動化された方法または手動でアプリケーション インベントリを構築する必要があります。自動アプリ検出には、Stratozone、M4A Linux、Windows 評価ツールに加え、Splunk、dynatrace、newrelic、appdynamics など APM ツールがあります。また、他のツールも取り組みを始めるのに役立つ可能性があります。WebSphere Application Migration Toolkit、Red Hat Migration Toolkit for Applications、VMWare cloud suitability analyzer、.NET Portability Analyzer のようなワークロードに固有のアプリ評価ツールは、インフラストラクチャとアプリケーション層全体の技術的品質の全体像を描くのに役立ちます。おまけに、データ、インフラストラクチャ、メインフレームの各ティアでも同様の合理化を行うことができます。今後の情報をお見逃しなく。
Google では、まず問題をソフトウェアとして考えてから、全体的に自動化します（SRE 思考）。インフラストラクチャ、アプリケーション、データの自動発見プロセスを構築できれば、長期的にアプリのモダナイゼーション プログラムの状態を体系的に追跡して評価するのが容易になります。アプリの合理化プログラムに DORA 指標を組み込むと、組織はパフォーマンスに焦点を当てることで、エンジニアリング効率を測定し、ソフトウェア開発の速度を最適化できます。
ステップ 2: コホートを作成する - アプリケーションをグループ化する
アプリケーション インベントリを取得したら、価値と労力を考慮してアプリケーションを分類します。ステートレス アプリケーション、マイクロサービス、シンプルな依存関係のアプリケーションなど、労力が少なくビジネス価値の高いアプリケーションは、モダナイゼーションまたは移行を行う第一段階の候補となります。
ステップ 3: モダナイゼーションの工程を計画する
アプリケーションごとに、現在の状態を理解して、クラウド移行時の適切な宛先にアプリケーションをマッピングします。アプリケーションの種類ごとに、可能なモダナイゼーション パスのセットの概要をご説明します。今後のブログで、このセクションの他のコンテンツをご紹介しますので、どうぞご注目ください。
クラウド未対応（保持、再ホスト、再定義）- 通常、VM 上で実行されるモノリシックなレガシー アプリケーションであり、再起動に時間がかかり、水平スケーリング可能ではありません。こうしたアプリケーションは、ホスト構成に依存する場合があり、高度な権限特権も必要とします。
コンテナ対応（再ホスト、リファクタリング、再プラットフォーム化）- 再起動、Readiness Probe と liveliness probe を備えること、stdout へのログが可能なアプリケーションです。こうしたアプリケーションは簡単にコンテナ化できます。
クラウド互換性（再プラットフォーム化）- 通常はコンテナ対応に加えて、外部構成、シークレット管理、優れたオブザーバビリティが組み込まれているアプリケーションです。こうしたアプリケーションは水平スケーリングも可能です。
クラウド対応 - ステートレスで、破棄可能で、セッション アフィニティがなく、エクスポータを使用して公開される指標があるアプリケーションです。
クラウド ネイティブ - API ファーストで、クラウド認証アプリおよび認可アプリを簡単に統合できます。ゼロへのスケーリングを行い、サーバーレス ランタイムで実行できます。
以下の図は、このカテゴリのそれぞれがモダナイゼーションの工程のどこに位置するか、そしてモダナイゼーションを開始するためのおすすめの方法を示しています。
これにより、クラウド移行の取り組みが促進されます（リフト＆シフト、移行と改善など）。
この段階に達すると、アプリケーションの移行パスまたは変更パスが確立されます。このクラウドへの移行を工程として考えると理解しやすくなります。つまり、モダナイゼーション アクティビティの移行のたびに、さまざまな抽象化レイヤーが利用可能になるため、アプリケーションは移行とモダナイゼーションを複数回行う場合があります。
ステップ 4: 計画と実行
ここまでで、第一段階のアプリケーションに関する十分なデータを収集しました。エンジニアリング、DevOps、オペレーション / SRE チームとともに、実行計画をまとめる準備が整いました。Google Cloud は、アプリケーションをモダナイズするためのソリューションを提供します。Java に関する 1 つの例をこちらでご覧ください。
この段階の最後には、以下が手に入ります（これらは一例です）。
クラウドで本番環境ワークロードを実行して維持できる経験豊富なチーム
アプリの変換と繰り返し可能な CI / CD パターンのレシピ
セキュリティの青写真とデータ（転送時および保存時）のガイドライン
アプリケーションのテレメトリ（ログ、指標、アラートなど）とモニタリング
クラウドで実行されているアプリに加え、古いアプリをオフにし、インフラストラクチャとライセンスの節約を実現
Day 2 運用のランブック
インシデント管理のランブック
ステップ 5: 費用対効果の評価
費用対効果（ROI）の計算には、次の組み合わせが含まれます。
直接コスト: ハードウェア、ソフトウェア、オペレーション、管理
間接コスト: エンドユーザーの運用とダウンタイム
モダナイゼーションの取り組み後、現状の ROI と予測 ROI を把握するのが最善です。これをダッシュボード内で行い、継続的に収集される指標で追跡することが理想です。これにより、アプリケーションが環境を越えて本番に流れ、節約を実現できます。Google CAMP プログラムは、データドリブンの評価とベンチマークを実施し、技術、プロセス、測定、文化に関する一連のプラクティスとともに、ソリューションと推奨を提供して、節約の目標を測定して実現します。
ステップ 6: 手順を繰り返す
アプリの合理化手順を実行することでフィードバックを収集し、残りのアプリケーションについてそれを繰り返して、アプリケーション ポートフォリオをモダナイズします。後続の反復ごとに、主要な結果を測定し、目標を設定して、自己推進型、自己改善型のアプリの合理化を可能にする仕組みを作ることが重要です。
まとめ
アプリの合理化は複雑なプロセスではありません。これは、経営陣のサポートを受けながら組織内で実装と伝達が可能なデータドリブンかつアジャイルな継続的プロセスです。
今後の情報にご注目ください。次のステップとして、アプリケーションの合理化とモダナイゼーションの過程の各ステップと、どのように Google Cloud が役立つかを詳しく説明した一連のブログ投稿を公開します。
-Google Cloud カスタマー エンジニア Poonam Lamba
