このラボでは、2つ目のEC2インスタンスでアプリケーションの更新バージョンを使用します。 これにより、ラボ1のサンプルアプリケーションの変換を簡単に確認できます。
このセクションの目的
🔷 サンプルアプリがどのように複数のサービスを利用しているかを確認する。
🔷 サービスフローとバックトレースを使用して、変換されたアプリケーションを評価する。
先ほど見たように、サンプル・アプリケーションは、フロントエンド、バックエンド、データベースの3層構造になっています。
リホスティング（リフト＆シフトとも呼ばれる）は、一般的な移行ユースケースです。リアーキテクチャとリプラットフォームは、従来のアーキテクチャを壊し、個々のコンポーネントをクラウドサービスやマイクロサービスに置き換えるステップと言えるでしょう。
Dynatrace と OneAgent を使用して、サービス、プロセス、およびユーザーリクエストに関する優れた情報を取得する方法を学びました。これは、モダナイゼーションする必要がある、ビジネス上の利点に基づく個々の機能またはアプリケーション全体を決定するのに役立ちます。ここでの考え方は、機能的な移行で機能ベースのビジネス上のメリットに焦点を当てることです。
このラボでは、バックエンドサービスを複数のサービスに分割したサンプルアプリケーションを使用します。これらのサービスをDockerイメージにすることで、Kubernetesのような最新のプラットフォームや、以下に示すようなクラウドマネージドサービスにサービスをデプロイできるようになります。
#1 . サンプルアプリケーション
このラボでは、Dockerコンテナとして実装されたフロントエンドと複数のバックエンドサービスで構成されたサンプルアプリを利用します。
#2 . Dynatrace環境
Lab0のプロビジョニングスクリプト内でDynatrace OneAgentはホストにインストール済みです。データはすでに送られておりSaaS側では収集を開始しています。
#3 . JMeterプロセス
Lab1同様バックグラウンドでトラフィックを生成するためにJMeter が動作しています。
サンプルアプリのパブリックIPアドレスの確認
パブリックIPアドレスを確認するためにAWSコンソールのEC2インスタンスページにアクセスします。dt-orders-servicesインスタンスの詳細タブからパブリックIPv4アドレスを確認します。
サンプルアプリへのアクセス
アプリケーションを確認するためにパブリックIPアドレスをコピーして、アドレスバーに貼り付けます。このときHTTPSではなくHTTPでアクセスするようにしてください。
💥 TECHNICAL NOTE
Lab1との違いは、バックエンド・サービスのバージョンのリストです。この点については、ラボの後半で改めて説明します。
左側のDynatraceメニューのサービスをクリックして、監視しているサービスを見てみましょう。
マネジメントゾーンのドロップダウンで、dt-orders-servicesを選択します。フィルタリングされたリストはこのようになるはずです：
frontendサービスを開きます。
サービスフロー分析
フロントエンドのサービスに移ったので、サービスフローを見て何が変わったか見てみましょう。サービスフローの表示ボタンをクリックしてください。
応答時間の観点
サービスフローのページになります。
アプリケーションがどのような構造になっているかが一目で確認することができます。
- frontendはorder、customer、catalogの3つのサービスを呼び出しています。
- orderサービスはcatalogとcustomerサービスを呼び出しています。
このような情報はメトリクスやログからは決して見えない情報です。
上の画像において：
- 応答時間の観点でデータを表示しています。スループットの観点に切り替えることができます。
orderボックスをクリックすると、レスポンスタイムのメトリクスが展開されます。orderサービスが呼び出しているcatalogとcustomerサービスは応答時間に対して同程度影響していることが分かります。そして、モノリス版のアプリケーションと同じように、レスポンスタイムに占めるデータベースの時間はわずかであることがわかります。
スループットの観点
上の画像において：
- ボックスをクリックして、スループット視点に変更します。
- ボックスをクリックすると、応答時間のメトリクスが展開されます。
サービスバックトレースの確認
それでは、左側のメニューの サービス をクリックして、サービス一覧を表示しましょう。 今度はcatalogをクリックします。
catalogサービス画面で、バックトレースの表示ボタンをクリックします。
catalogサービスがどのように呼び出されているか確認してみましょう。
- スタートのポイントは
catalogになります。 catalogはorderサービスから呼び出されています。catalogはfrontendサービスから呼び出されています。frontendはMy web applicationからへのブラウザのトラフィックが確認できます。 もし表示されなくても問題ありません。
👍 どのように役立つのか
サービスフローとサービスバックトレースを使用することで、これら2つのツールは、ホスト、プロセス、サービス、およびアプリケーションの観点から、アーキテクチャの残りの部分との相互依存関係を完全に把握することができます。
👍 モノリスアーキテクチャとの違いの把握
Lab1で確認したfrotnendのサービスフローと本ラボのfrontendのサービスフローの違いを確認してみましょう。また、Lab1で確認したbackendのバックトレースと本ラボのcatalogのバックトレースの違いを確認してみましょう。
クラウドに移行する際、移行が計画通りに進んでいるか、サービスが以前と同じように、あるいはそれ以上に機能しているか、新しいアーキテクチャが計画通りの効率性かどうかを評価したいものです。Dynatraceは、これらのすべてのステップを自動的に検証し、移行と検証のプロセスをスピードアップするのに役立ちます。
サービスフローを理解する能力を持つことで、リアーキテクチャやリプラットフォームの意思決定をよりスマートに行うことができます。Kubernetesのような新しいテクノロジーをサポートすることで、新旧にまたがるプラットフォームでモダナイゼーションを安心して行えるようになりました。
時間が経つにつれて、このサンプルアプリケーションは、AWS LambdaやAWS Relational Database Service (RDS)やAmazon Aurora - MySQLおよびPostgreSQL互換リレーショナルデータベースやAmazon API Gatewayのような他のサービスのような他の技術を追加し、さらに変更されることが想像できます。
💥 TECHNICAL NOTE
ここでは取り上げませんが、組織はDevOpsアプローチを確立し、継続的インテグレーション（CI）パイプラインを確立して、各サービスを独立してビルドしテストしています。そして、そのプロセスに継続的デプロイメント（CD）を追加することで、顧客への迅速な機能提供能力を大幅に向上させることができます。 Dynatraceは、DevOpsをサポートする多くのソリューションを持っています。詳しくはこちらをご覧ください。
チェックリスト
このセクションで、あなたは以下を確認しました：
✅ 複数のサービスから構成されたサンプルアプリを監視できていることを確認
✅ サービスフローとバックトレースを用いて、サンプルアプリの構造を理解