Migration Toolkit for Applicationsを使って組織のシステムのクラウドへの移行を促進させる 3. 使用(アセスメント)編

OpenShift AppDev SSAの瀬戸です。

Migration Toolkit for Applications(以下MTA)という製品をご存知でしょうか?Red Hatが出している静的解析ツールで、古いバージョンのJBoss EAPやOpenJDKなどのミドルウェアで動いているアプリケーションを最新のミドルウェア上で動作させるために必要な修正を洗い出してくれます。

実は、それだけではなく、組織のアプリケーションのモダナイゼーションのサポートもしてくれます。この記事では何回かにわけて、どういった機能があるのかと実際の使い方をご紹介したいと思います。

ちなみに、MTAは無償でお使いいただくことが可能です。

前回はMTAをインストールしてログインできるところまで説明をしました。今回は実際に使っていきたいと思います。 アプリケーションをMTAに登録して、モダナイゼーションをするべきかどうかアセスメント(評価)をしたいと思います。

MTAってなんだ?って人は以下の記事を参照してください。

rheb.hatenablog.com

MTAをインストールしたことがない人は以下の記事を参照してください。

rheb.hatenablog.com

ログイン直後だと以下のような画面が表示されているはずです。

ログイン直後

初期設定

アプリケーションを登録する前にいくつかの設定が必要になります。 左上のプルダウンからAdministrationを選択することでMTA自体の設定を変更することが可能です。

権限のプルダウン

Assessment questionariesに登録されているLegacy PathfinderのRequiredをYesに設定します。これはMTAに登録されているデフォルトの質問集です。Red Hatのコンサルタントが何を気にしてクラウドに移行するかを検討するかをまとめたものになります。今回はアセスメントの内容のカスタマイズまでは行わずに、この質問集をそのまま使います。

Assessment questionaries

その他にもGitのセキュリティの設定や、Proxyの設定等が行えます。必要に応じて他のものも設定を変更します。

アセスメント前の情報の登録

MTA自体の設定が終わったら、次はアセスメントに必要な情報を登録していきます。

左上の権限を選択してAdministrationからMigrationの方に戻ってきます。

まずは、ステークホルダー(関係者)の情報を登録します。

ステークホルダーの情報を登録するのは非常に重要です。

組織内のアプリケーションを横断的に変更しようとした場合に、アプリケーションの管理者が見つからないからといって、勝手にアプリケーションを変更したりはしません。あらためて責任者を立てる等、何かしらの対応を行います。責任者がわからないまま何かしらの対応をしようとした場合に、あとから責任者が出てきて、「俺何も聞いてないんだけど?」の一言でブロッカーとなってしまう可能性があります。

そのため、MTAでは最初にステークホルダーを登録する必要があり、誰がやったのか等の履歴をきちんととる必要があります。

ステークホルダーの登録はControlsから行うことができます。 ControlsからStakeholdersを選択して、Create newを押してください。

ステークホルダーの新規登録

ステークホルダーの情報を登録します。

ステークホルダーの情報入力

Saveを押せば一覧画面に表示されます。

ステークホルダーの登録後

これでステークホルダーの情報を登録できました。

アプリケーションの登録

ステークホルダーを登録したらアセスメントを行うアプリケーションの登録を行います。 Application InventoryからCreate newを選択します。

アプリケーションの登録

アプリケーションの情報を入力していきます。 必須なのはNameだけですが、Ownerとアプリケーションのソースコードの情報も入力しています。

なお、サンプルとして載せているgitのリポジトリは次の通りです。この後の静的解析で使用しますので、特にこだわりがない場合は以下の値を入力してください。

アプリケーションの情報入力1

アプリケーションの情報入力2

Saveを押すとアプリケーションの登録が終わります。

アプリケーションの一覧

アセスメントの実施

ここから実際にアセスメントを行います。アセスメントでは担当者が把握しているアプリケーションの管理状態を入力し、アプリケーションのクラウドへの移行に対してどれくらいの問題を内在しているのかの基礎情報を入力します。

アプリケーションの右側の縦になっている…をクリックし、Assessを選びます。

評価開始

Legacy Pathfinderを選択します。

使用するアセスメント

ステークホルダーを登録します。これはこのアセスメントの回答者です。今回は既に登録した情報を使用します。実際にMTAで移行のアセスメントをする場合は自分自身の情報をステークホルダーとして登録するのを忘れないようにしてください。

ステークホルダーの指定

アセスメントが始まりますので、回答していきます。

このアセスメントに使用されている質問集はRed Hatのコンサルタントがアプリケーションの移行時にどういった考慮が必要かを考えた質問です。 Red Hatのコンサルタントがどういうことを気にしながらアプリケーションのモダナイゼーションを行っているのかが気になる人は、質問の内容を一通り確認するとよいでしょう。実際に移行をしなくても、現在のアプリケーションの運用でどれくらいの課題が内在しているかを把握するための一助となるかもしれません。

質問の内容をyamlとしてダンプしたものを以下のgistに保存してあります。必要に応じて参照してみてください。

Legacy Pathfinder.yaml · GitHub

質問

最後まで選択するとSaveとSave and reviewというボタンが表示されるので、今回はSaveを押します。reviewは後程別途行います。

アセスメントの終了

これでアセスメントは終了です。

静的解析

引き続き、静的解析を行います。静的解析では、事前に登録してあるルールに基づいてソースコードやバイナリを解析し、アプリケーションのコンテナ化、ミドルウェアの最新化にどういった修正が必要なのかを機械的に洗い出してくれます。先ほどアセスメントを行いましたが、どうしても担当者の思い込みや間違いが発生する可能性があります。静的解析ではそういったのを防ぎ、移行するのにどれくらいの修正が必要なのかを確認することができます。ただ、これで発見できるものがすべての修正ではありません。ただ、他のアプリケーションと比較することでどちらの方の移行が難しそうかといったことを判断することができます。

MTAはモダナイゼーションのために使用できるという説明をしましたが、静的解析ではもうちょっと具体的に、最新版のEAP 8への移行、やSpringからQuarkusへの移行、アプリケーションのコンテナ化をするために必要なタスクなどを洗い出すために使用する事ができます。

アプリケーションのチェックボックスを選択してから、Analyzeを押します。

静的解析開始

次に静的解析を行うアプリケーションのソースコード、バイナリの場所を指定します。アプリケーションの登録時にgitリポジトリの情報を登録してあるため、Source Codeを指定します。

ソースコードの指定

移行先を指定します。今回のサンプルアプリケーションはEAP 7.XからEAP 8.0への検証用に作成したアプリケーションなので、JBoss EAP 8を指定しています。これ以外にも最新のOpenJDKやコンテナへの移行等を検証することが可能です。

移行先の指定

その後、nextを押していき、最後にRunを押すことで、静的解析が実行されます。細かい挙動のカスタマイズをすることもできますが、今回は省略しています。

実行終了までには数分程度かかります。

静的解析中

終わると、アプリケーションにどういうテクノロジーが含まれているかを参照できるようになります。

アプリケーションに含まれているテクノロジー

また、どういった修正が必要なのかについてはissuesから参照する事ができます。こちらでアセスメントの結果だと簡単に移行できると思っていたが、修正があまりにも多い場合等はアセスメントの結果を見直す必要が出てきます。

イシューの一覧

レビューを行う

ここまででアプリケーションを取り巻く環境のアセスメント及びに、静的解析による難易度の測定が行えました。実際にその結果を見ながらレビューを行います。

アプリケーションの左の縦になった…をクリックしてreviewを選択します。

レビュー開始

さて、この先では実際にアプリケーションをどうやっていきたいのかを今まで解析した結果を基に入力していきます。 右側にはアセスメントで入力した結果が表示されています。

レビュー画面

Proposed Actionには6Rからどれを行うのかを選びます。6Rってなんだっけ?と思った人は概要編を参照してください。 Effort estimateは作業の大変さを見積もった結果を入れます。Business criticalityやWork priorityについても今までのアンケートを基に入力していきます。ただし、これらに関しては何を入れるのかの指針についてはありません。それぞれの企業で自分たちの状態を勘案し適切に選択する必要があります。

ここは企業の状況によって適切に選択する必要があり、非常に難しいところです。今回は一つのアプリケーションだけの入力になっていますが本来は他のアプリケーションと見比べながら優先順位をつけていきます。Red Hatではお客様と一緒に移行の順番を考えられるようにコンサルティングサービスを提供しています。困ったらお問い合わせください。

ここで入力が終わればMTAを使うレクチャーは終わりです。これを企業内でアプリケーションがあるだけ繰り返して入力をしていきます。

アプリケーションのグルーピングを行うためのタグ打ちの機能や、どのビジネスサービスからどのアプリケーションが使われているのかを管理する機能等もあります。実際に使われる際にはそちらもぜひお試しください。

まとめ

MTAの実際の入力方法を説明しました。システムのモダナイゼーションをしたいとだけ言われても途方に暮れてしまいますが、MTAを使う事でそのとっつきにくさを軽減することができます。ぜひご活用ください。

* 各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。