アプリケーションのモダナイゼーション:マイグレーションの際に優先すべきこと(Part 2)

記事をシェアする:

この投稿は、2020年11月18日に、米国 IBM Cloud Blog に掲載されたブログ(英語)の抄訳です。

アプリケーションのモダナイゼーション・プロセスにおいて、何を、なぜ、どのように移行するか

先日のブログの記事「アプリケーションのモダナイゼーション：まず最初にすべきこと（その1）」では、アプリケーションのモダナイゼーション・プロセスを確認しました。次の大きな課題は、移行すべきアプリケーションをどうやって決めるかということです。

まず、デュー・デリジェンスを行い、ビジネス・チームと協力して、必要性や重要なロジックの有無の観点から、どのようなアプリケーションが企業にとって本当に付加価値を与えているのかを確認します。次に、モノリス・アプリケーションを分析し、論理的なマイクロサービスに分解する方法を確認します。より良いマイクロサービスに進化させるモノリス・アプリケーションの内部のエンティティを理解するには、多くの一般的なテクニックがあります。

マイクロサービスへの進化のジャーニーにおいては、モノリス・アプリケーションは20個以上のマイクロサービスに分解されるかもしれません。それぞれのマイクロサービスが活用されるには、特別な扱いが必要です。

マイクロサービスの成熟

マイクロサービスのモダナイゼーションに責任を持つことは、子供を育てることに責任を持つことに似ています。まずマイクロサービスを作成、進化、管理、育成することを意識的に決定します。途中で間違いが起こるかもしれませんが、最終的にはマイクロサービスは成熟し、ビジネスや社会に付加価値を与えることができます。

マイクロサービスの内部に存在する物理的なコードは、それを育成するために時間とエネルギーを投資するエンジニアリング・チームを奨励します。何千行ものコードの作成に相当な時間を費やしているため、エンジニアリング・チームがマイクロサービスを作成してから1週間ほどで削除することはほとんどありません。

マイクロサービスからコードの一部を取り出して、そのロジックを維持、修復、進化させ続けることはよくあることです。特にこの活動は、企業内の複数のエンジニアリング・チームがマイクロサービスの背後にある技術的な選択肢を広げたいと考えている場合に当てはまります。

マイクロサービスと10-10-10ルール

アプリケーションをモダナイズし、マイクロサービス一式を構築する際の良い指針として、その実行中に以下の要素を制限することで構成される「10-10-10ルール」 というものがあります：

• メンテナンスを担当する開発者:10人
• メンテナンス中のマイクロサービス:10個
• それらのマイクロサービスと相互作用する業務アプリケーション統合のポイント:10箇所

これらの数値は、チームが処理できる作業量や変更量、およびマイクロサービスを周辺で運用できる柔軟性の量を決定するのに役立ちます。もし、少人数で管理するマイクロサービスが多すぎると、アプリケーションのモダナイゼーションを十分に推進することができません。あるいは、統合ポイントが多すぎると、結果として、対処可能な範囲を超えるリスクやエクスポージャーが発生する可能性があります。

このルールの下で、モダナイゼーションの要素の進化を管理したり、新しいアプリケーションを刷新することができます。さらに、マイクロサービスを24時間365日機能させるために必要な配信、サポート、その他のタスクを管理できます。

マイクロサービスを業務契約にする

多くの組織では、マイクロサービス一式をラッパーに入れて、各コンポーネントをデプロイするための実行フローを制御しています。これらのラッパーは単一のアプリケーション・プログラミング・インターフェース（API）を使用しており、別の10個のマイクロサービスやさらに別の10チームへの統合ポイントを提供しています。このラッパーは、マイクロサービスのセットをビジネス契約に変え、企業に利益をもたらすことができます。

例えば、100個のマイクロサービスがあり、それぞれが異なるAPIを持っているとします。ビジネスAPIのセットをまたがってお客様の環境にあった使いやすいAPIをユーザー・インターフェースにすることができます。大規模なクラウド・ネイティブ企業の場合は、APIの階層を作成して、あるAPIと顧客管理についてやりとりすることができ、そのビジネス契約は期待通りの動作をします。

ビジネス契約は、APIのパフォーマンスに関するSLA(サービス・レベル・アグリーメント)のようなものです。APIのパフォーマンスを進化させることを目的としたビジネス契約を導入すれば、アプリケーションの変更に柔軟に対応しながら、責任を持って提供することができることを確立できます。

アプリケーションのモダナイゼーションと将来に向けた計画

アーキテクチャーを決定する際は、何を迅速に変更する必要があるのか、何を変更する必要がないのか、そしてどのようなビジネス契約をお客様に提供するのかのバランスをとる必要があります。例えば、構造化されたデータベースから非構造化されたデータベースへのモダナイゼーションを行っているとしましょう。なぜそのようなことをするのでしょうか？データ・ストレージの柔軟性を高めたいのか、保存したいデータの型を変更したいのか、それとも他の理由でしょうか。

中には、進化が必要なサービスもあります。ビジネス・プロセスを改善するために、最新のアプリケーションに拡張できるようにAPI契約が必要な場合があります。ビジネスが1つのプラットフォームから別のプラットフォームへと進化し、同時にアプリケーションを近代化する必要があるため、これらの決定を行う必要があります。

アプリケーションのモダナイゼーションとIBM Cloud Satellite

IBMは、データ、AI、機械学習などを中心としたコア・ソリューションを提供していますので、これによりAPIの周辺の付加価値を高めることができます。アプリケーションを移行したり、アプリケーションの周りにロジックを構築して、その相互作用を管理したりすることもできます。

アプリケーションの近代化への旅の一環として、ぜひIBM Cloud Satellite の利用を検討してみてください。IBM Cloud Satellite は、マネージドサービスである Red Hat OpenShift on IBM Cloud のような IBM Cloud サービスを、ご利用のインフラストラクチャーに提供する分散クラウドです。

IBM Cloud Satelliteについてより詳しいことは

このブログは、「アプリケーションのモダナイゼーション」についてのブログ・シリーズの第2部です。シリーズの第1部である「アプリケーションのモダナイゼーション：まず最初にすべきこと（その1）」もあわせてご活用いただけますと幸いです。

翻訳：IBM Cloud Blog Japan 編集部

*このブログは、2020/11/18に発行された“Application Modernization: What to Prioritize for Migration (Part 2) ”(英語)の抄訳です。

関連情報

• アプリケーションのモダナイゼーションとは
• アプリケーション・モダナイゼーションのコンサルティングとサービス
• クラウド・アプリケーション開発のコンサルティング・サービス