クラウドへの移行にはさまざまな形があります。アプリケーションをデータセンターからクラウドに直接移植する方法（リフト＆シフト）を選択する企業もあれば、クラウドならではのメリットを生かすためにアプリケーションを完全に再構築する企業もあります。どのようなアプローチであっても、移行後に答えたい3つの主要な質問があります。
- アプリケーションが遅くなった？
- 私のアプリケーションは以前よりも安定していないのでしょうか？
- 前述の質問のいずれかが原因で、私は顧客を失っているのでしょうか？
これらの質問に答えるには、まずいくつかの基本的なテストを実行して、システムのパフォーマンスと可用性のベースラインを確立します。ベースラインは、アプリケーションの現在のパフォーマンスと可用性の測定値であり、移行後にビジネスケースを検証するための比較として使用します。場合によっては、 移行受け入れテストを実行するときにベースラインを変更することがあります。移行中の比較ポイントとしてベースラインを使用して、順調に進んでいることを確認することもできます。
1.コンポーネントの識別
クラウドへの移行を開始する前に、アプリケーションスタック全体のすべての階層を特定します。移行したいコンポーネント（アプリケーション、サービスなど）をすべてリストアップします。アプリケーションスタックを以下のようにセグメント化します。
- アプリケーション（バックエンド／マイクロサービス／cronジョブ）
- メッセージキューなどの依存関係にあるサービス
- データベース
- Webサイト
- 基盤となるサーバーとインフラ
ヒント
アプリケーションベースラインの作成を開始する前に、アプリケーションとインスタンスへのアクセス権があることを確認してください。アプリケーション・オーナー、DevOpsエンジニア、プロダクト・マネージャーを巻き込んでアクセスしてください。
2.互換性の判断
移行したいアプリケーションを特定したら、New Relicプラットフォームでどのアプリケーション層を監視するかを確認する必要があります。組織内の関係者と協力して、組織内で可能な、あるいは許可されているインスツルメンテーションの量を決定します。これは重要なステップであり、より多くのインストゥルメンテーションが可能であればあるほど、ベースラインが向上するため、有益なステップとなります。
ここでは、特定したコンポーネントに応じて、ベースライン化に使用するNew Relic製品を紹介します。
- APM : APMを使用して Web アプリを監視します。 サポートされている各言語の正確な互換性の詳細については 、「New Relic エージェントと製品の互換性と要件」を参照してください。
- Infrastructure : インフラストラクチャを使用してホストを監視します。 サポートされている OS と環境については、「インフラストラクチャの互換性と要件」を参照してください。 オンホストインテグレーションを使用すると、他の製品やサービスを計ることもできます。
- : 外形監視 を使用してSynthetic monitoring WebAPI フロントエンドと 監視します。場合によっては、 またはインフラストラクチャを使用してオンプレミス環境を計装できない場合があります。 たとえば、組織のポリシーにより、ファイアウォールの背後にエージェントをインストールすることが禁止されている場合があります。 このような場合、アプリケーションに Web フロントエンドがある場合は、ベースラインを確立する機能を提供しながら非エージェント監視を提供する外形監視を使用します。
3.モニタリングの導入
作成したコンポーネントと製品のマッチングに基づいて、アーキテクチャ全体にエージェントやモニターを展開します。
4.指標の収集
エージェントとモニターを導入した後は、ビジネスにとって最も重要な指標を特定し、これらの指標を使ってKPIを定義します。いくつかの推奨事項をご紹介します。
- Response time: リクエストに応答するまでにかかる時間。
- Throughput: アプリケーションを通じて受信したリクエストの数。
- Requesting queuing (Apache, IIS, NGINX): リクエストがアプリケーションに到達するまでにかかる時間。
- Database call duration: データベース呼び出しを完了するまでにかかる時間。
- DB call counts: アプリケーション コードによってデータベースに対して行われた呼び出しの数。
- Error rate: 報告されたエラーの割合。
- Apdex score: Web アプリケーションとサービスの応答時間に対するユーザーの満足度を測定するための業界標準。
- DNS setup timing: DNS に接続してデータを受信するまでにかかる時間。
- SSL setup timing: SSL 接続を確立するのにかかる時間。
これらのメトリクスの一部は、サービス マップ、 APM 、 browser summary ページで見つけることができます。
APM のナビゲート、解釈、使用についての詳細な情報は、New Relic University のチュートリアルをご覧ください。
5.ダッシュボードの設定
KPI を定義したら、ダッシュボードで簡単に視覚化できます。ダッシュボードは、New Relic 製品が収集するすべてのデータを 1 か所で表示できるようにします。ダッシュボード データはイベントで構成され、各イベントにはイベント タイプ、タイムスタンプ、およびキーと値の属性があります。
イベントの詳細については、 Data collection および Default events for New Relic products を参照してください。
指標とイベント、およびNRQL クエリ言語を使用して、New Relic で KPI とビジネス指標データを見つけることができます。これらの KPI のパフォーマンスを追跡するダッシュボードを構築することもできます。
移行後、これらのベースラインを 移行受け入れテスト のベースラインと比較します。
専門家のアドバイス
デフォルトの機器では取得できないデータが必要な場合は、カスタムデータを簡単に取得することができます。
また、New Relic University Custom data tutorial series で、APM のカスタムインストルメントについて詳しく学ぶことができます。