こんにちは。IBMデベロッパー・アドボケイトのSai Vennamです。今回はハイブリッド・クラウド・アーキテクチャー・シリーズのパート2、レガシーまたはモノリシック・アプリケーションのモダナイゼーション戦略についてお話ししましょう。
このシリーズのパート1では、ハイブリッド・クラウドの接続性について説明し、これと同じサンプル・アプリケーション、Stock Traderを使用しました。
今回は、Stock TraderがオンプレミスのVM上で動作する、モノリシック・アプリケーションだったところからお話ししましょう。
[アーキテクチャーの概要]
アーキテクチャーはほとんど同じで、SOAつまりサービス指向アーキテクチャーを使用しています。SOAは、マイクロサービスを使用したアーキテクチャーの前身となる手法です。 モノリスそのものの内部については、Java EEベースのアプリケーションを想像するとわかりやすいでしょう。
これがフロントエンドのUIアプリケーションでポートフォリオと連携します。基本的にはさまざまなポートフォリオを管理し、株価を追跡しています。
株価を取得するには別のサービスにアクセスし、証券取引所のパブリックREST APIエンドポイントと通信します。
すべてのデータとポートフォリオ情報は、オンプレミスのデータベースに保管されます。ここにはいくつかのサービスも配置されています。
ロイヤルティー・サービスは、ポートフォリオに含まれる個々の株のロイヤルティーを追跡し、変化があればユーザーへの通知も行います。その場合は、メッセージ・キュー・サービスを利用して、Eメールなどで通知します。以上がアーキテクチャーの概要です。
[モノシリックの解体プロセス]
このアーキテクチャーはStock Traderという架空の会社で、きわめて有効に機能し、会社は成長して事業を拡張しました。もしかすると国際的企業になっているかもしれません。同社はこのアプリケーションを使用している、一部のユーザーの待ち時間が増加していることに気付きました。
Stock Traderのアーキテクトは、モノリスから脱却すべき時が来たと判断しました。今こそモノリスを解体してパブリック・クラウドを活用すべきです。ではその方法を見ていきましょう。
ステップ１: リソースの識別
解体プロセスの最初のステップは、モノリスから分離する部分を特定することです。
例えば、ポートフォリオ・サービスは他のサービスと密接に関連しているので、パブリック・クラウドには移動したくありません。ロイヤルティー・サービスも同様です。この部分を移動すると不要なネットワーク・ホップ(機器の中継)が大量にでき、ユーザーの問題をさらに悪化させるでしょう。
分離する部分として適しているのはUIつまりフロントエンドです。分離すると複数の地域にフロントエンドを配置できるようになります。端的に言えば、UIはフロントエンド・コンポーネントであると同時に、そのフロントエンドのバックエンドでもあり、これらすべてのバックエンド・サービスを呼び出してデータを表示します。
ですからUIから着手するとよいでしょう。そうすれば小さい部分から始めて、将来のより効率的な解体のために体制を整えることができます。これで第1ステップである、リソースの識別は完了しました
ステップ２: リファクタリング
次に行うのはリファクタリングです。ただし、この部分をモノリスからクラウドに移動するのは簡単ではありません。それにはさまざまな理由がありますが、最大の理由は、パブリック・インターネットではこれらのサービス間の円滑な通信ができないことです。
この通信はソフトウェア・ベースの呼び出しであり、JavaプラットフォームのSOAアーキテクチャーを基盤にしています。そこで、パブリック・インターネットに適しているRESTなどを利用する必要があります。まずはグルー・コードを作成しなければなりません。基本的には、UIがポートフォリオにアクセスできるエンドポイントを作成します。
さらに、ポートフォリオとロイヤルティー側のREST APIエンドポイントを公開し、UIがアクセスできるようにします 。これをグルー・コードと呼びます。サービス間で同じ通信経路を維持しつつ、パブリック・インターネットでもそれを使用できるからです。これが第2ステップです。
ステップ３: デプロイ
リファクタリングが完了したら、次はそれをパブリック・クラウドにデプロイします。したがって第3ステップはデプロイです。
UIをパブリック・クラウドに配置します。UIへのアクセスに使用するポイントを公開する必要があります。こちら側も同じです。UIがモノリスから公開されます。
従来のAPIフローでは、ユーザーはブラウザーから、このモノリス・アプリケーションにアクセスします。このフローは引き続き有効です。これについては確認済みです。作成したグルー・コードによる不具合は発生していません。
ステップ４: 反復
さて、この次のステップが重要です。パブリック・クラウド内のUIに直接アクセスする新しいAPIフローも、有効であることを確認する必要があります。
効果的な戦略としては、最初にユーザー・トラフィックの10%程度をパブリック・クラウドのUIに送信し、残りのトラフィックをオンプレミスに送信します。これにより本番での問題点を把握し、多くのユーザーへの影響を回避することができます。最終的にはすべてのエラーを検出し、エラーのないパブリック・クラウドを実現します。
そうなったら、古いUI部分を使用中止にしてすべてを削除し、パブリック・クラウド側のUIを利用します。モノリスの一部を分離してパブリック・クラウドに移動できたら、次にどの部分を分離するか検討します。
[モノリスの移動に伴うさらなる検討項目]
これまでにUIをパブリック・クラウドに移動しました。事態は順調に進んでいるとしましょう。世界各地のどのユーザーもアプリケーションにアクセスするときの応答時間が短くなりました。運用が上手くいっているので、これ以上モノリスの解体を進める必要はないかもしれません。この点について検討することは非常に重要です。
ボトルネック: 株価
サービスのリファクタリングやマイクロサービスへの変換は費用がかさむため、必要性が生じるまでモノリスを現状のまま維持するのが合理的な場合もあります。しかしそうは言いながらも、このアプリケーションは拡大し続け新しいボトルネックが見つかりました。それは株価です。
これらのポートフォリオとそれを使用するさまざまなユーザーの現状を見ると、他の部分をスケールアウトする必要はそれほどありません。ただしユーザーは株価に頻繁にアクセスし、株価を取得するために証券取引所を使用しているので、株価をスケールアウトする必要があります。
残念ながら、このモノリシック・アーキテクチャーで株価をスケールアウトするには、すべてをスケールアウトしなければなりません。しかしオンプレミスにはそのための十分なリソースがありません。
ユーザー・ベースの拡大に伴って、ユーザー・エクスペリエンスが再び低下してきました。そこで、パブリック・クラウドのスケーラビリティーを活用するために株価を移動したいと思います。ただし時間の余裕がありません。ユーザー・エクスペリエンスは既に低下しています。株価をリファクタリングして、マイクロサービスを作成するだけの時間はありません。
[リフト・アンド・シフト]
そこで利用できるのがリフト・アンド・シフトです。基本的には、モノリス全体をそのままパブリック・クラウドに移動します。
Stock Traderのモノリス全体をここに移動したとします。ここにはすべての部分が配置されていますが、実際にスケールアウトしたいのは株価です。これはモノリス全体ですが使用したいのは株価を取得する部分だけです。この中に株価を取得する部分があります。
モノリス全体をリフト・アンド・シフト方式でパブリック・クラウドに移行したら、スケーラビリティーの利点を活用できます。パブリック・クラウドのリソースを使用し、この例のように8倍にスケールアウトすることも可能です。
これが最良のアプローチでないことは承知していますが、市場開拓の必要性から時間に限りがあります。モノリスをコンテナー化してパブリック・クラウドに移動すれば、クラウドのリソースを活用でき、モダナイゼーション・プロセスの次のステップの検討に移ることができます。
[革新と改善]
ここで1つ申し上げておきたいのは、次に書かれている「革新と改善」とは、常にアプリケーションを改善する方法を探す必要があるということです。
UIがパブリック・クラウドに配置されていることはわかりましたが、その通信チャネルはどうでしょうか。基本的にUIは必ずモノリスに戻ってポートフォリオやロイヤルティー、その他のサービスを利用します。
ここで最初に気付くのが、UIはポートフォリオにアクセスしてからこちらに戻ってパブリック・クラウドのモノリスにアクセスし、株価を取得しなければならないということです。その後またポートフォリオにアクセスし、こちらのUIに戻ります。
こうして多数の不要なネットワーク・ホップ(機器の中継)が発生します。私たちはこのモダナイゼーションのプロセスを通じて、常に革新と改善を行えます。UIで株価を直接取得し、データベース・ストレージのアクティビティーを非同期でオフロードしましょう。そうすれば既存のアーキテクチャーで簡単に革新と改善を行えます。
それにはこれらのアプリケーションをリファクタリングし、UIがパブリック・クラウドのモノリスと直接通信して株価を取得できるようにします。このように、クラウドへの移行では常に革新と改善を行います。
[パブリック・クラウドでモノリス全体を使用する方法]
サーバーレス
では次に、パブリック・クラウドでモノリス全体を使用する方法について考えてみましょう。これは最良のアプローチではありませんが、市場投入までの時間を短縮できます。ここでは新しいテクノロジーを活用します。例えばサーバーレスです。この部分を切り出して、サーバーレス機能を利用して株価を取得します。
クラウドでサーバーレス・プラットフォームを使用すると、Functions as a Serviceを利用して証券取引所のパブリックAPIにアクセスできます。このようにサーバーレスを使ってIEXのパブリックAPIを利用します。
そしてもう一度、4ステップのプロセスを繰り返します。私たちは分離する部分を特定し、取得し、サーバーレス・アクションにリファクタリングし、本番にデプロイしました。次に、レガシー・フローと新しいAPIフローをテストします。これがレガシー・フローです。新しいAPIフローはサーバーレス・アクションに直接アクセスします。
このフローが有効であることを確認したら、株価のためだけにパブリック・クラウドに移行した。モノリシック・アーキテクチャー全体を削除できます。
本日はこの4段階のプロセスを使用して、モノリシック・アーキテクチャーから個々の部分を分離し、パブリック・クラウドに移動する方法についてお話ししました。ここに書かれた3つ、すなわちモノリシックの解体、リフト・アンド・シフト、継続的革新と改善によって、モノリシック・アプリケーションのモダナイゼーションを成功させる体制が整います。
最後までご覧いただきありがとうございました。