Techopediaスタッフ、2016年8月31日
まとめ：ホストRebecca Jozwiakは、データベースのトラブルシューティングと効率の問題について、アナリストのEric KavanaghとDez Blanchfield、およびIDERAのBill Ellisと議論します。
あなたは現在ログインしていません。ビデオを見るにはログインまたはサインアップしてください。
Rebecca Jozwiak：ご列席の皆様 、こんにちは。2016年のHot Technologiesにようこそ。今日のトピックは、「アプリケーションの実行速度が遅いですか？ そして、私たちは皆、ものがゆっくり動いているときに起こりうる問題をあまりにもよく知っていないのですか？ これはレベッカ・ジョズウィアックです。今日、ここで新しい役割をやっているエリックのために私が記入します。 はい、今年は暑く、テクノロジーに関して言えば、私が言ったように、本当にしたくないことの1つは、システムのあらゆる部分の低速実行です。 消費者の例を使用するために、レストランを持っている場合、食べ物がどれほど素晴らしいかは関係ありません。サービスが遅い場合は、おそらく戻ってこないでしょう。 これで、レストランで何かがゆっくり実行されている理由を理解するのは簡単です。 たぶん、キッチンのスタッフが不足しているか、いくつかの機器に不具合があったか、待機スタッフが少し怠けていて、それを簡単に特定して修正することができます。
しかし、データセンターについて考えるとき、それはまったく異なる話です。 それはネットワークの問題、物事を妨害する悪いクエリ、アプリケーションのパフォーマンス、または障害のあるケーブルでさえ、いくつかの問題を引き起こす可能性があります。 そして、その種の複雑さでのトラブルシューティングは、せいぜい難しいことです。 それは今日私たちが話していることの一種です。 そして、私が言ったように、今日はアナリストとしてエリック・カバナが声をかけています。 データサイエンティストのDez Blanchfieldがいます。IDERAのBill Ellisがいます。彼は、アプリケーションのパフォーマンス管理に役立つ彼の会社のソリューションについて話します。 それで、ボールをエリックに渡します。 エリック、床はあなたのものです。
エリック・カバナ：いいですね、いいですね。 実際、トラブルシューティングを行うことができる困難や容易さについて話し、すぐにそれを理解できるため、これは非常によく似ています。 パフォーマンスの問題は、常にネットワークにある何らかの種類の問題に起因します。 つまり、たとえば古いハードウェアと同じくらい簡単かもしれませんが、最終的にはトラブルシューティングを必要とするような状況です。 それが今日お話しすることです。 そして、ここからスライドにジャンプしてみましょう。
ここに問題があります。 トラブルシューティング-それが好きな人にとっては楽しいです、それはクールなことです。 トラブルシューティングをするのが好きな人を見つけたら、その人につかまって、仕事を成し遂げるためのツールを手に入れてください。 しかし、肝心なのは、トラブルシューティングには問題があり、常に問題があり、常に問題が発生するということです。トラブルシューティングについて話し始めると、実際に得られるのは根本原因分析です。 問題の原因は何ですか？
まあ、ただ座ってメインフレームの日でさえも考えてみると、起こりうるあらゆる種類の問題がありました。 当時は、トラブルシューティングを行うための優れたツールすらなかったため、自分のことを本当に知っている人がいなければなりませんでした。そのため、コマンドプロンプトを本当に知る必要がありました。これについてはすぐに説明します。 そして、実際にお気に入りのスライドの1つを入れるのを忘れました。今日のショーの間に、多分Dezのプレゼンテーション中にそれを探します。 しかし、私は見たことのない人のために、これまでで最もおもしろい英国のテレビ番組の1つである「ITクラウド」と呼びたいと思いました。そしてトラブルシューティングの観点から、アイルランドの2人のITの1人であるアイルランド人会社全体が、通話を開始するたびに常に同じことを言います。「オフにして再びオンにしてみましたか？」ですから、オフにして再びオンにしてみてください。 あなたは、その単純なことがいくつかの問題を解決できる頻度に驚くでしょう。
自宅でトラブルシューティングを行った人は、おそらくあなたの子供ではなく、両親や友人と一緒にトラブルシューティングを行ったことがあります。 ただし、トラブルシューティングは簡単ではありません。簡単になることはありませんが、今日は簡単にするためにできることのいくつかについてお話します。 ですから、コマンドプロンプト–はい、確かに、DIRを実行するコマンドプロンプトしかなかった頃のコンピューティングの初期の頃を思い出すのに十分な年齢です。 それはファイルのディレクトリを見て、実際に何らかのコマンドが実行されたことを肯定的に感じるでしょうか？ もちろん、データサイエンティストのDezは、コマンドプロンプトの使用方法を知っています。 そして、コマンドプロンプトを使用できる場合、それは素晴らしいことです。なぜなら、私たちのほとんどは、ある種のGUI、グラフィックユーザーインターフェイスを使用しているからです。しかし、常に何かがあり、GUIとその下のコマンドラインの間には常に切断があります。 ランダムな例を挙げると、最近の基本的なプログラムのどれだけのコードをドキュメントに焼き付けたいかを知りたい場合は、Microsoft Wordの最新バージョンに進み、「hello world」と入力して、「名前を付けて保存そして、その結果のドキュメントをテキストエディターで開くと、おそらくページとタグのページが表示されます。 これはコードの肥大化と呼ばれますが、コードの肥大化はトラブルシューティングにはあまり適していません。
もちろん、クライアントサーバーが登場し、それは素晴らしいことでした。 ある意味ではその方向に戻りますが、状況に伴う複雑さを考えてみてください。問題はどこにあるのでしょうか、クライアントにあるのか、サーバーにあるのか、ネットワークにあるのでしょうか。 それはどこにある？ ウイルスについて考えているだけのこれらのサイト、およびウイルスがネットワーク上のウイルスに侵入すると、どうなりますか？ どこにでも行くことができます。 最近、データ侵害は狂っています。 これらはパフォーマンスの問題を引き起こします。 IPアドレスで特定できるロシアのハッカーがいます。 彼らはロシア人であるか、非常に近いか、プロキシを使用して非常に巧妙なウクライナ人やポーランド人、さらにはアメリカ人であると確信しています。 しかし、ハッカーが私たちの小さな古いサイトであるInside Analysisに長年来て、あらゆる種類の問題を引き起こしています。 スタッフが機能しなくなるだけで、作業を完了できません。 以前は機能していたものは機能しません。 どうして知っていますか？ それが何であるかをどのように知っていますか？ ここにある別の例は非常に複雑な環境です。雑草に入り込んで、特にプラグインを大量に入手している場合は、状況がどのように発生し、どのように機能するかを本当に理解するのは非常に困難です。 ものはかなり早く狂ってしまいます。 私は自分自身に先んじるようなものです。
私はここに投入しました。常にアップグレードに注意してください。 アップグレードは常に私から日光を怖がらせます。 確かにオペレーティングシステム。 マイクロソフトが実際にオペレーティングシステムをこのバージョンからそのバージョンにアップグレードできると提案した時代を思い出します。 まあ、私は数回試しましたが、それは決して機能しませんでした。 環境が大きく、複雑になるほど、状況はさらに扱いにくくなることを覚えておいてください。 そして、仮想化があります。 VMwareがITに対して行ったことについて考えてください。 ITに革命をもたらしましたが、この抽象レイヤーも作成しました。 その基本的なレベルでレイヤーの抽象化がある場合、それはまったく新しいボールゲームであり、まったく新しいボールです。実際に自分がやっていることを再評価する必要があり、古いツールはすべて変更する必要がありました。 そして今はもちろんクラウドですよね？ 顧客にとって、クラウドは非常にシンプルであり、ユーザーインターフェイスが非常に単純であるため、クラウドは優れていますが、クラウドを実際に制御することはあまりありません。 しかし、舞台裏にいる人々には、最近知って理解する必要があるものがたくさんあります。 環境は非常に複雑になっています。 そして確かに電子商取引では、最近取引されるすべてのお金を考えます。 だから、すぐにキャッシュレス社会に賛成してくれないだろう。 ここの一番下の行は、日ごとに状況がより問題になっているということです。
また、パフォーマンスを最適に保つには、常にトラブルシューティングの要素が含まれます。 誰かがあなたに言ったことを気にしません、完璧なツールはありません、特効薬はありません、そして、ここで別の興味深い視点で、私たちはまだシリコンを話すことを学んでいます。 私たちはまだ、ネットワークでさえも非常に細かいレベルでどのように機能するかを理解することを学んでいます。 システム管理ソフトウェアを見ると、最近かなり良くなっています。 しかし、それでも、あなたは上下する線を見て、現実の表現を見て、何が起こっているのかを知っている人を連れて、最適なツールを見つめることができる手がかりを合わせます何が機能していて何が機能していないかを理解し、多くの試行錯誤を繰り返します。 それで、私はそれをDez Blanchfieldに引き渡します。そして、IDERAのBill Ellisから話を聞きます。彼は彼の知識に恥をかかせるでしょう。 それで、Dez、それを取り去ってください。
Dez Blanchfield：やあ、エリックに感謝。 ありがとうございました。 私の小さなセグエにうまく導かれました。 私のタイトルである「パフォーマンスアート」は、今日お話ししていることの文脈では非常に適切だと思います。パフォーマンスアートについて考えるとき、多くの点で、ダンスや音楽などの創造的なことを考えるからです。 そして率直に言って、問題を解決している場合、そして非常に大規模なIT環境とビジネスシステムでは、確かに芸術の要素があり、多くの場合黒人の芸術があります。最新のアプリスタックは、これまでにない速度で非常に急速に複雑さを増しています。 そして、私たちは追いつくのに率直に苦労しており、たとえばUberなどの組織とPokémonGo開発チームがあります。彼らは、天文学的な速度で成長と複雑さ、複雑さの増加を経験しています。 そのレベルの成長を考えていなかったので、それについて書かれた本さえありません。 私の考えでは、アプリケーションスタックのコア定義は指数関数的に変化しているので、なぜそうなのかを説明してから、目の前の課題に導きます。 。
非常に簡単に、これらすべてを知っていますが、それらを要約するために、初期の頃、私はアプリケーションアーキテクチャバージョン1.0と呼んでいました。 これはサーバーコンピューターであり、この場合は多数の端末が接続されたメインフレームであり、端末に問題がなければ、問題を診断するのは比較的簡単でした。端末とサーバーコンピューター間のケーブルを追跡できます。 、それはゼロケーブルまたはコネクタ、または端末に関連していない場合は何らかの問題であり、画面に何かが表示されている場合、問題の原因となっているものがマシン自体。 また、ハードウェアからソフトウェアレイヤーおよびユーザーインターフェイスまでのスタック内の場所をゆっくり診断できます。 私がバージョン1.1と呼ぶものでは、もう少し複雑にしました。 デバイスを中央に配置して、より多くの端末を配置できるようにしました。 そして、それらは何らかの通信デバイスであり、多くの場合、マルチプレクサまたはマルチプレクサであり、専用回線またはダイヤルアップ回線を介して実行されるため、メインフレームが遠く離れた場所にありました。 SMAリンクまたは何らかのWAN接続を介して接続され、これらの端末は引き続き同じ方法で動作します。 ただし、問題が端末と通信デバイス間で発生したのか、通信デバイスとメインフレーム間で発生したのかを把握する必要があるため、もう少し複雑になりました。 しかし、スタックはメインフレームで比較的類似したままでした。
バージョン1.2は、デバイスを追加し、プリンターなどを追加し、それらをクラスター化して、デバイスのすべての問題をローカルで処理するフロントエンドプロセッサーについて考えています。そして、メインフレームの遠い端にあるターミナルなど。 もう少し複雑です。 ただし、メインフレームの一貫したテーマは、ローカルで実行されるアプリであったため、問題解決はアプリケーションスタック内でほぼ同じままでした。 そして、端末、プリンター、クラスターコントローラーの問題を解決するスキルを持った人々がいました。 しかし、その後、私たちは物事を複雑にし、ネットワークを構築しました。突然、同じ種類のアーキテクチャがネットワーク層を導入しました。 突然、ネットワークスイッチが使用され、ワークステーションはさらに複雑になりました。 また、このバージョンのアーキテクチャでは、ワークステーションにグラフィカルユーザーインターフェイスアプリがよくありました。 アプリスタックを実行しているサーバーがあるだけでなく、ローカルで実行されているアプリケーションの別のスタック、そしてもちろんサーバーに接続するデバイスの同じ基本モデルもありました。 次に、私が2.1と呼んでいるものの最近のモデルに飛躍的な進歩を遂げました。ここでは、そのアプリスタックを採用し、診断をはるかに複雑にしました。 そして、フロントエンド、Webブラウザー、PC、モバイルデバイスなどに、さらに多くのデバイスを導入しました。 そして、ここで、アプリケーションスタックは、オペレーティングシステムとハイパーバイザーの統合として、少し深く掘り下げ始めました。
右側のこの画像には、ネットワークインフラストラクチャ、ストレージサーバー、仮想マシン、オペレーティングシステム、そして従来の3層のデータベースメタルウェアアプリケーションなどを含むスタック全体が右側にあります。 このモデルでのアプリケーションの問題とパフォーマンスの問題を診断することは、かなり難しくなりました。 非常に多くの可動部分があり、そのスタックをドリルダウンしようとするのは悪夢であり、それに対処するために追加のスキルセットと組織を含める必要がありました。 アプリケーションチームだけでなく、突然インフラストラクチャの担当者が増え、データベーススペシャリストがいました。純粋にデータベースに取り組んでいるだけで、データベースの使い方を知っていたシステムプログラマとは対照的でした。 今では、IT部門が「サービスとして」の非常に広範な複雑さに対処しなければならないシナリオがあり、世界が爆発し、問題解決の課題が悪夢からほとんど耐えられないものに変わったいくつかの点で。
そして、これは解決可能な規模として生じ、私たちはサービスを提供しようとしています。 私がアプリケーションスタックと見なすもののバージョン3-これはサービスモデルとして導入されました。左側の従来のモデル、エンタープライズITスタック、消費者およびサプライヤとして最後にすべてを管理する必要がありました。サービス–アプリケーションセキュリティデータベース、オペレーティングシステム、仮想化サービスストレージ、ネットワーキングデータセンターなど–すべてを管理する必要がありましたが、すべてにアクセスできたため、能力と技術スキルセットをスケールアウトし、すぐにドリルダウンできましたそのスタックを通して、私たちは物を見つけることができました。 しかし、インフラストラクチャサービスとプラットフォームサービス、およびソフトウェアサービスモデルが登場したため、バックエンドインフラストラクチャへの突然のアクセス、プラットフォームへのアクセス、およびサービスを提供したツールへのアクセスはすべて一種の奪われました。 インフラストラクチャサービスを利用し始めたとき、オペレーティングシステム、データベース、セキュリティ環境アプリケーションスタックなどの上位4ピースしか利用できませんでした。 その下はすべて黒魔術でした。 また、プラットフォームサービスに移行すると、アプリケーションスタックを管理しているだけなので、さらに興味深いものになります。
ソフトウェアをサービスとして利用する場合、その従来のモデルはウェブメールまたはインターネットバンキングであり、ウェブブラウザにアクセスするだけなので、その背後にあるものを間違いなく診断しようとします。 そして、これをタイムゾーン、時間のスロット、または必要に応じて世代に分けて、左から右に、2000年代以前からアクセスできる従来のスタックに移動しました。環境全体に渡り、それを掘り下げることができます。 しかし、時間の経過とともにますます複雑になりました。 2000年代初頭から2000年半ば、2000年代後半から現在まで、インフラストラクチャサービス、プラットフォームサービス、ソフトウェアサービスから現在に至るまで、本質的にビジネスサービスに言及しています。 そして、複雑さが劇的に増加しました。 さらに多くの可動部品があります。 しかし、スキルの利用可能性はますます難しくなり、利用するのがますます難しくなっています。 適切なツールに適切にアクセスして適切なスキルセットを持つ人々を見つけ、このスタックを取得して飛び込み、どこが遅いのかを見つけます。 それは私のラップトップかデスクトップか、電話かタブレットか、3Gまたは4G経由の接続か、ADSLまたはISDNとの専用リンクですか？ または、ダイヤルアップでさえ、最近ではそうではありませんが。 Webサーバーは終了ですか、Webサーバー内にあるものですか？ アプリサーバーですか？ それは、CPUのメモリとディスク、およびアプリケーションサーバー内のネットワークパフォーマンスに関係していますか？ データベースはそこで実行されていますか？
そして想像できるように、ビッグバンイメージのように拡大し始める複雑さ、この増え続けるバブルの腕の周りに潜り込み、潜り込むスキルを身に付けようとしている複雑さを非常に素早く描くことができます。知識と場所を分析してバラバラにする。 そして、データベース環境を引き離し、そのデータベースを引き離し、その中に飛び込む能力を持っていたとしても、人間は物理的なスケールに対処できない時代になりました。そのデータベース内の詳細。 現在、管理する必要があるデータベースの数は急速に増加しています。 現在、すべてがデータベースによって強化されています。 最近では、データベースを使用していないアプリケーションはほとんどありません。 また、データベースの種類も急速に成長しています。 従来のSQLデータベースだけでなく、SQL、SQL以外、グラフデータベース、ドキュメントデータベースなどもあります。 そして、これらのさまざまなタイプのデータベースが持つこれらのさまざまなタイプの機能はすべてあり、その結果、それぞれに異なるパフォーマンスの課題と異なるパフォーマンス基準があります。 ロギングデータベースとドキュメントデータベースは、従来のACID準拠、ANSI 92準拠のSQLデータベースとは非常に異なる方法で実行され、異なる機能を実行します。 そして、そこに保存したものの種類。
私たちは、エリックがこれをほのめかしているところに、人間が私たちが構築しているものの複雑さや構築する速度に追いつくのに苦労しているところです。現在、このインフラストラクチャを管理する唯一の方法であり、直面している問題を監視し、調査する唯一の方法は、ツールと適切な種類のツールを使用することです。 そして、常に、適切な世代のツール。 バックエンドインフラストラクチャを実際に理解するツール。 SQLモニター、またはSQLクエリツールを何かに投げて、クエリを分解し、それが機能する理由を確認し始めるだけではもう問題ありません。 実際には、クエリの形成とクエリを形成するための適切な方法、およびバックエンドでインフラストラクチャと通信するためのクエリの適切な方法、およびその実行方法を理解するツールが必要です。 そして、それらの相互作用のタイミングとそれらが起こる順序を見るため。
そして、それははるかに複雑な課題であり、まとめの質問点につながります。つまり、開発しているアプリスタックの複雑さが増すにつれて、パフォーマンスツールとそれらを管理するために使用するツールは必然的に必要になりますよりスマートになり、より多くのものを見ることができるようになります。 しかし、バックエンドで実行されていることを掘り下げ、それについて発見できること、および潜在的に相互作用とパフォーマンスが配信されていることを理解するために実行される何らかの分析も可能ですなぜパフォーマンスが遅くなったり速くなったりするのか。
それから、私はIDERAの親愛なるビル・エリスに話を聞き、彼らがこの問題をどのように解決するかについて今日彼が言わなければならないことを見ていきます。 ビル、あなたに。
ビル・エリス：わかった。 私の名前はビル・エリスです。ありがとうございました。 アプリケーションがゆっくり実行されていること、Preciseを取得する時間について説明します。 IDERA製品であるPreciseの機能と、それがどのように役立つかを見てみましょう。 多くの場合、エンドユーザーから電話がかかってきたためにパフォーマンスの問題が発生したことがわかりますが、それ自体が本当に大きな問題です。 IT部門の全員のうち、電話が鳴るまで誰も知りませんでした。 さて、次の大きな問題は、この特定の個人をどのように支援するかであり、それは本当に些細な問題ではありません。 これから1つのポイントがあります。 それはこのスライドを超えており、他のスライドを超えています。 そして、私はあなたがそれが何であるかを得ることができるかどうか見てほしい。 しかし、前述したように、アプリケーションには多くの異なる技術が必要であり、アプリケーションスタックは高く成長しています。 そして、多くの人がブラウザーを介してアプリケーションにアクセスしますが、驚くべきことに、スクリプトなどを使用してブラウザーで行われている処理がますます増えており、もちろん、ネットワーク、Webサーバー、ビジネスロジックコード、およびデータベースがあります。 タイムカードレポート、在庫検索、発注書、データベースの更新など、すべての重要なビジネストランザクションがデータベースとやり取りすることを検討してください。 そのため、データベースは本当にパフォーマンスの基盤になります。 もちろん、データベースはオンにすることも、ストレージのダウンストリームに依存することもできます。 これらのテクノロジーはそれぞれ密接に結合されており、何が起こっているのかを見ることができます。 何を測定できるようにするかが重要です。
今、私たちが見つけた1つのことは、多くの顧客がツールを持っていることであり、彼らは各技術のためのツールを持っていますが、持っていないのはコンテキストです。 コンテキストは基本的に、アプリケーションスタックのすべての層の間でドットを接続する機能であり、これは実際には比較的単純です。 以前は12層の制限がありましたが、基本的には変更されており、無制限の層があり、混合環境をサポートしているため、Preciseソリューションで基本的に非常に複雑になります。
今、高レベルで、これは問題を解決する方法であり、クリックからディスクへのエンドユーザートランザクションであるトランザクションに焦点を当てており、どれが遅いか、どれがリソースを消費しているかを教えてくれますが、重要なのはこれです–トランザクション時間全体だけでなく、各ステップで費やされる時間だけでなく、ロケーションを取得してユーザーIDを取得できます。 時間はパフォーマンスの通貨であり、リソースが消費されている場所にも現れます。 問題の発生場所を事前に把握していないため、問題がどこにあるのかを診断できるように、各層で適切なメトリックと分析を行う必要があります。
さて、今日のプレゼンテーションではこの分野に焦点を当てますが、アプリケーションスタックのすべての層で基本的に同じレベルの可視性を提供し、重要なことは、これが誰に、何、どこ、そしてこの部分、これが理由を教えてくれます。 そして、それが問題を知るだけでなく、問題を解決するために絶対に不可欠な理由です。 プレゼンテーションで非常に明確に出てきたもう1つのことは、これを行うことができないということです。 自動化が必要です。 自動化とは、アラートを発することを意味します。できれば、エンドユーザーコミュニティの前に、継続的なトレンドがあり、トレンドアラートからの逸脱を蓄積していることを伝えるものがあります。 そして、私たちは砂の中にラインを提供します、あなたは実際にSLAに違反しています。 今、あなたはたくさんの異なる情報を提供しています-誰もがビュッフェを消費する必要はなく、一部の人々は単に軽食を食べたいだけです、これはサラダです。したがって、情報をアップロードできるポータルを提供します。またはパフォーマンスに関する特定のコミュニティの情報ニーズ。 アプリケーションの実行速度が遅くなったため、Preciseを取得します。 本当に4つのことに集中します。 1つは、エンドユーザーを入力する場所です。 繰り返しますが、ドットをつなぐコンテキストと、調査の第3部では、アプリケーションの問題のほぼ90％がデータベースにあることを示しています。したがって、パフォーマンスソリューションの大部分が1つのSQLステートメントを伝えるのは、本当に一種の悲惨なものです。 しかし、そのSQLステートメントの実行速度が遅い理由はわかりません。
したがって、理由は常に重要なことであり、Preciseはすべての層、特にデータベースについて、理由を示すのに優れており、SQL Server、Sybase、DB2をサポートするサポートマトリックスについて少しだけ説明します。および/またはバルク。 ソリューションのルックアンドフィールは非常に似ているため、複数のアプリケーションを見ているが、アーキテクチャがわずかに異なる場合。 ここで共有している情報には、ルックアンドフィール、アプローチがあり、使用中の基盤となるテクノロジーがどうであっても同じです。 正確なWeb対応です。 私たちがやって来て、私たちは正確に認証します。そして私たちが入って行くことで、私たちが最初に見たいのは、場所によるパフォーマンスです。 そして、ここで実際に人々が実際に彼らの処刑にアクセスしている異なる場所を見ることができます。 完全にレンダリングされる前に誰かがページを放棄したかどうか、またはエラーがあるかどうかを確認できます。
現在、これらのアプリケーションの1つのことは、ネットワークまたはアプリケーションサーバーからの距離が異なることです。 ここには、ある程度のネットワークがあることが非常に簡単にわかります。 人々が忙しくなったとき、そして別の興味深いことを見ることができます。ブラウザ内で処理がどのように行われるかを話しました。 そして、人々がChromeまたはIEでアクセスしているかどうか、またはそれが何であれ、それを知っていると、1つのブラウザタイプの反転が実際に別のものより優れていることが非常に頻繁にわかります。 現在、公開されていることもあれば、ブラウザーを制御していないこともあります。アプリケーションは、エンドユーザーコミュニティにブラウザーの種類を推奨できる内部向けである場合があります。正確に提供することができます。 それでは、アプリケーションを見ていきましょう。
皆さんが私のポインタを見ることができるかどうかはわかりませんが、一番上のグラフを説明したいと思います。 y軸は平均応答時間を示します。 X軸は1日の時間です。 そして、実際には積み上げ棒グラフとその積み上げ棒グラフがあり、合計はパフォーマンスを示し、その後、アプリケーションの個々のステップまたは個々の層で費やされる時間の階層を示します。 クライアントからWebサーバーを介して、緑色はJavaです。この場所では、Tuxedoを使用してデータベースにアクセスします。 これで、画面の下半分にアクセス中のさまざまなWebメニューが表示され、下向きの小さな緑色の矢印が表示されます。 降順で表示され、上にバブル表示され、Webメニューが表示を開始します。 実際に個々のテクノロジーの実行時間、応答時間を表示し、実際にそれらのWebメニューごとに棒グラフがあるので、何が起こっているのかを把握し始めます。 エンドユーザーが呼び出すすべてでこれを並べ替えたことを思い出してください。しかし、エンドユーザーを見つけるにはどうすればよいですか。 ここに来て、特定のユーザーでフィルタリングできるメニューを開くので、そのユーザーをAlex Netに設定し、[OK]をクリックしてから、Alex Netのアクティビティのみに注目します。 これにより、ITおよびIT管理がエンドユーザーに直接応答できるようになりました。特に、6秒の実行と3秒強の応答時間でコンテンツ管理を見ていました。 まあ、3秒はかなり良いです、それはひどいではありませんが、それは、おそらくそれは遅いです。
これでできることは、この情報をさまざまな方法で切り刻むことができるということです。 このトランザクションは誰にとっても遅いと言えますか？ アレックスにとっては、昨日よりも遅くなっていますか？ 特定の場所にいるすべてのユーザーにとって遅いですか？ または、それが何をしているのかというと、何が起こっているのか、問題がどの程度普遍的であるのかを知ることができ、エンドユーザーを識別することが非常に重要です。インフラストラクチャ、エンドユーザーがどのようにアプリケーションを実行しているかについてです。 多くの場合、新しい従業員や新しい職務に就いている人がいて、特定のSAP画面や特定のPeopleSoftパネルに精通しておらず、小さなポインターが必要な場合があります。フィールドを空白のままにするか、ワイルドカードを入力するなどですデータベースから大きな結果が返されるように強制します。 しかし、ユーザーIDがあれば、実際に電話をかける前に電話をかけることができます。 私たちが見つけた他のことは、ユーザーコミュニティがITが彼らが何をしているのかを知っていると、それは多くの場合彼らがより良く振る舞うようになり、多くの問題、問題であった多くのこと、蒸発するのは、人々が行動しているため、もう少し慎重に操作するだけです。 彼らは細心の注意を払ってシステムを使用しています。
エンドユーザーの識別は不可欠です。 最終的には、ITが特定のエンドユーザーを支援できることが不可欠です。 さて、ここで行ったことは、「フロー」タブに行ったことです。 それは左上隅で見ることができます。 そして、Webメニューの特定のコンポーネントに注目しました。 そして、右側にはその特定のトランザクションの分析があります。そのため、一番上は実際にはブラウザ、そしてビューです。GUI内のアイコンの少しに慣れるのはWebサーバーのためです。属性ポイントが表示されます。 そして、「J」はJava用、「T」はTuxedo用、そして当然「Q」はSQL用です。 基本的に、そのキャッシュ値は特定のSQLステートメントを識別します。 これが何をするか検討してください。 個々のSQLステートメントを含む、基になるアプリケーションコードに対するトランザクションのユーザーを特定しました。 さて、これらの個々のSQLステートメントを見ると、合計応答時間のうち、それぞれが約6％を占め、上位4つのSQLステートメントを合計すると、トランザクションの約4分の1を占めていることがわかります。時間。
現在、多くの場合、データベースは操作が最も簡単です。 通常、安価ではるかに優れたパフォーマンスを得るのが最も簡単です。 次に、何が起こっているのか、そして何が起こっているのかを調べるためにもう少し深くする必要があります。実際に個々のSQLステートメントを明らかにすることを例にできます。ある種のデータベースツールとデータベースツールの機能がありますが、1つのテクノロジーだけを分離して見ているのは、そのテクノロジーの健全性に注目することです。 そして多くの場合、人々はトップ10のリストを見ます。 これで、このSQLステートメントは非常に高速になり、トップ10リストに載ることはありませんが、このトランザクションが依存するSQLステートメントです。 そして、その言葉であるコンテキストで私ができることは、個々のSQLステートメントのコンテキストで、これを深い視線に向けることができるようになったことです。
今、その人は個々のSQLステートメントのコンテキストでPreciseを開くことができ、Preciseは使用する実際の実行計画をキャプチャします。これはDBAにとって重要な実行時間であり、実際に表示されます。ストレージでの待機に時間がかかります。 時間の50％がCPUで使用されているので、時間を費やしている場所、その時間をどのように動かしているのか、人々に選択肢を与えるというアイデアを得ることができます。 。 理想的には、問題に対する低リスク、低コストのソリューションを求めています。 これで、SQLステートメントはハッシュ値によって追跡され、画面の左側の中央にこの小さな「調整」ボタンがあり、それが何をするのか、SQLタスクに行きます。 そして、このSQLタスクは一種の事前に構築されたワークベンチであり、これが何をするかは、実行計画から始めてSQLステートメントに影響を与えるものを具体的に分析することを可能にします。 実行計画は、ステートメントが解析されるときにオプティマイザーによって選択されます。これは、食物の例えに戻ると、SQLステートメントを解決するためにたどるレシピです。
また、一部のレシピは他のレシピよりも複雑であるため、調査結果を提供します。 そして、特定のインデックスでシーケンシャルI / Oを実行している多くの時間で、実際にここに表示されます。 そして今、酸素に戻って、この指標に従ってください。 そのインデックスは最近デフラグされましたか？ifの状態はどうですか？ どの表スペースに住んでいますか？ 表スペースは、それが参照する表から分離されていますか？ そして、それはあなたが問題を解決しようとするかもしれない方法に関するあらゆる種類のアイデアをあなたに与え始めます。 明らかに、インデックスを構築しています。 インデックスをあるテーブルスペースから別のテーブルスペースに移動するよりもはるかに簡単で、リスクがはるかに低いため、私たちがやりたいことは、オプションを構築することです。問題を解決するため。
また、Preciseは、SQLステートメントにキャストされるバインド変数をキャプチャするなどのこともできます。 明らかに、キャストされる変数は結果セットのサイズを制御します。 また、SQLステートメントの実行にかかる時間と、Javaを介して.NETを介してWebサーバーキャストとネットワークに最終的にエンドユーザーブラウザーでレンダリングされるアプリケーションによって渡されるデータの量を制御します。 。 データベースで何が起こるかは、そのブラウザー時間に直接影響します。 したがって、このレベルの可視性を確保して、何が起こっているかを正確に把握し、DBAに最も多くのオプションを与えて、特定の状況で最も適切なオプションを選択できるようにすることが重要です。
現在、これらは引用の一部であり、これらはたまたまグローバルに展開されているPeopleSoftショップからのものです。 Preciseは、PeopleSoftとSAP、Siebel、Oracle、E-Business Suite、自社開発のJavaおよび.NETアプリケーションをサポートしています。 Javaから.NETに戻ってJavaに戻る複数のJVMへのWebサービス呼び出しを行う場合、すべてを追跡できます。 オンプレミスでも、クラウドでもかまいません。 重要なことは、物事を計測する必要があるということです。
そして、顧客の一人からの引用をいくつか引用します。「正確な前は、DBAはOEMを使用していました」-それはデータベース専用のツールであり、基本的に「インスタンスは見栄えがいい」と言っていました。特定のトランザクションの問題を伝えたり対処したりするのに役立ちます。 正確にそれを行うための可視性を提供しました。 したがって、SQLステートメントに関する情報を保持することは、データベースからパフォーマンスを完全に引き出すための可視性をDBAに与えるために重要です。 そしてそれは本当に良かったです。 あなたが見ているかもしれないツールのいくつかを超えて。
そして、IT管理者は、Preciseが複雑なURLをパネル名に変換できるという事実を本当に気に入っていました。 こうすれば、エンドユーザーが電話して「ちょっとこれに問題がある」と言ったら、そのユーザーが誰なのか、何を実行しているか、どのようなパフォーマンスか、実際にレンダリングを測定しているのかを特定できます。エンドユーザーのブラウザでの時間。 これは、エンドユーザーエクスペリエンスの真の尺度です。 また、そのユーザーIDを持つことは、電話をかける特定の人を支援するために絶対に不可欠です。
Preciseはこれをどのように行いますか？ それで、アーキテクチャを共有したいと思います。 正確には、独自のサーバーに配置し、VMに配置する必要があります。クラウドに配置できます。 フロントエンドでは、ダッシュボード、アラートインターフェイス、またはエキスパートGUIのいずれを使用していても、PreciseはWeb対応です。 データ収集側では、実際にいくつかの異なるテクノロジーに対してエージェントレスを行うことができます。 しかし、多くの場合、エージェントが必要になりますが、エージェントを持つことにはプラスとマイナスがあります。 大きな利点は、収集されたデータがLAN経由で送信される前に前処理できることです。 つまり、監視ソリューションがターゲット環境に与える全体的な影響を最小限に抑えることができます。
代替手段として考えてみましょう。「エージェントレス」を使用している場合、データコレクターはまだ存在します。それはどこにあるかという問題であり、呼び出しを行い、ターゲットアプリケーションに関する生データをLAN経由で渡します。 そして、実際にはかなり高価です。 したがって、前処理により、実際にフットプリントを最小限に抑えることができます。 物理と仮想の両方を監視できます。 そして、仮想テクノロジーについて私が言いたかったことの1つは、実際に焦点を当てているということです。 Preciseが重点を置いているのは競合です。 VMwareテクノロジーが実際にゲストVMのリソースを最小化するのはいつですか？ そしてそれは本当に簡単になります。 ゲストVM内のみを表示している場合、画像の一部しかありません。 競合を自動的に検出して警告できるため、これは本当に不可欠です。
Preciseは最大500個のインスタンスを監視できるため、非常に大規模な展開には基本的に複数のPreciseサーバーがあります。 また、グローバル展開の場合、通常は各データセンターの高精度サーバーになります。 ちなみに、非常に大規模な展開では、実際にこれらを統合して、企業全体で現在の状況を確認し、レポートなどを提供できるようになります。今述べたように、多くのテクニカル分析があります。 誰もがエキスパートGUIにアクセスする必要はないため、カスタマイズ可能なダッシュボードを提供しています。 そして、これらの各ポートレットまたはウィジェットは、すべてオプションです。 そして、誰かが行きたいと思うかもしれません。「ねえ、私たちの環境内のどの階層でもアラートを発することができますか？ あるいは、インフラストラクチャについて質問があり、Tuxedoのパフォーマンスにさえなるかもしれません。 またはロードバランシングです。 ここでは、この負荷分散の部分でちょっとおもしろいです。 左側の中央にあるポートレットを見ています。 実行回数は各Webサーバー間で非常に似ていることがわかります。 しかし、応答時間は一番上では大きく異なります。 実際にドリルインして、そのWebサーバーの応答時間が他のWebサーバーよりもはるかに遅い理由を正確に調べることができます。
負荷分散に関する1つのことは非常に重要です。負荷分散ポリシーは、すべての負荷分散ポリシーがすべてのアプリケーションに適しているわけではないことを知っています。 実際に、負荷分散ポリシーを検証することは本当に役立ちます。 実際、一部のWebサーバーがオフラインになる新しいPeopleSoft Fluid GUIなどのいくつかのアプリケーションを使用しています。 そしてそれは本当に重要なことです。 PeopleSoft Fluid GUIを展開している場合は、お問い合わせください。 他のお客様が直面していることについて、多くの洞察と多くの知識を提供できます。 これらの各ポートレットは非常に詳細にできます。 真ん中の右のように、青と緑で、実際に剣の先端パターンを示しています。これは、WebLogic層内のガベージコレクションが期待どおりに実行されていることを示しています。 これらの各ポートレットは、高度に焦点を絞ることも、非常に高いレベルにすることもできます。 そして、それが重要である、または重要になる可能性がある理由は、多くの場合、この情報をIT内に保持するだけでは十分ではないことです。場合によっては、この情報をアプリケーションの所有者や、時には上級管理職と共有する必要があります。
「データセンターでの成功」など、いくつかのストーリーを共有したいと考えました。これらはデータベースに焦点を当てており、中間層に焦点を当てた他のストーリーもあります。 しかし、今日はデータベース層に焦点を当てたいと思います。 画面のフリーズを見てみましょう。 さて、ここで起こったことは、この特定の店にはビジネスSLAがあり、午後3時までに注文が届いた場合、注文はその日に発送されるということです。 そのため、その時間枠では倉庫は非常に混雑しています。 そして、画面がフリーズするのはとてもイライラしていました。 そしてスーパーバイザー–これは小さな会社です–スーパーバイザーは実際にIT部門に入り、もちろんDBAに上がって、「今、何が起こっているのですか？」と言います。何が起こっていた。 これが多層アプリケーションであるJD Edwardsです。これが注文画面です。 ビジネスが何であるか、基本的にはジャストインタイムの在庫を把握できるため、基本的に倉庫アプリケーションを検討しています。 そして今、あなたは基本的に多くのさまざまな顧客サイト、異なる店舗に出荷しています。 そして、私たちがしたことは、Preciseを開いたことです。
この場合、Oracleを見る前に、ここではSQL Serverを見て、上半分はSQLステートメントが実行中に時間を費やす場所の積み上げ棒グラフを示しています。 すべての弱い状態は、y軸で説明されます。 もちろん、x軸は時間の経過とともに表示され、スタックバーグラフは、実行中のものとシステムの使用方法に応じてタイムスライスから変化することがわかります。 この特定のケースでは、上から3番目のSQLシーケンスに注目しました。 テキストはSELECT FROM PS_PRODであり、実際の実行計画をキャプチャしたことがその列でわかります。 また、実行回数全体を確認できます。 この特定のSQLステートメントが、私たちが見ているこの時間枠でのリソース消費の9.77％に関与していたという事実-そしてそれが重要なポイントであり、時間枠であり、Preciseはローリングヒストリを保持しているので-特定の時点で、または時間の経過とともに何が起こったかを調べます。 トレンドを見ることができます。
このSQLステートメントでは、積み上げ棒グラフが濃い青色で表示されています。 つまり、すべてのCPUを使用しています。 その特定のSQLステートメントでこの「TUNE」ボタンをクリックして、先に進んで焦点を合わせましょう。 私たちが行うことは、「この特定のSQLステートメントについてDBAは何を知っているのでしょうか？」と言うように設計されたワークショップにそれを取り入れることです。そして、右側に「選択された履歴」。 そして、私があなたに今して欲しいことは、左側に移動し、「変化vs持続時間平均」、平均持続時間と言うことです。 そして、これらのバーはそれぞれ1日のイベントを表します。
あなたは水曜日、木曜日、金曜日に見ることができます、実行時間はそうでした、私はポイント2に丸めるつもりです。 y軸はポイント4秒を示しているので、ポイント2です。 SLAでは、画面のフリーズはほとんどなく、操作は順調に進んでいます。 残念ながら、2月27日に実行計画が変更されたため、実行時間が即座に変更されました。 突然、実行時間が4倍、おそらく5倍になり、物事は非常に貧弱に動作しています。 現在、Preciseのリポジトリでは、動作に影響を与える可能性のあるすべての変更を実際にジャーナルします。 ここで、実際に軸平面の変化をキャプチャしたことがわかります。 中央の1つに「テーブルボリュームが変更されました」と表示されているため、テーブルが大きくなり、SQLステートメントの解析時にオプティマイザが1つの実行プランまたは別の実行プランを選択します。
さて、幸運なことに、今週の月曜日はフリップフロップしたので、良い時でした。 残念ながら、それは再びフリップフロップし、エンドユーザーは画面のフリーズを予測し始め、その画面の再送信を開始し、実行カウントを何度も押し上げます。 膨大な量の詳細がありますが、この問題を解決し、将来的にそれを回避するには、1つの追加情報が必要です。 そして、それらの実行計画の比較の下にそれが示されています。 3月5日、高速かつ効率的であった場合、左側に実行計画が表示されます。 3月12日に遅くて非効率だったとき、フィルター結合を行っていることがわかります。 フィルター結合は、より多くのCPU消費を強制し、より多くの作業を行います。 結果は同じで、ただもっと多くの仕事をしています。 パントリーに行ってすべての食材を一度に手に入れるのではなく、一度に1つの食材を食べに行くようです。 したがって、これを行うためのこの種のより効率的な方法があります。 これを通常知っているDBAは、クエリプランを使用して、この遅い実行プランを回避し、高速で高いパフォーマンスを確保することができました。
さて、次の種類の戦争の話は「報告は遅れています」でした。多くの人がこのシナリオで特定できると思います。 アドホックレポートを作成したり、NVISIONなどのツールを使用したり、サードパーティのレポートツールを使用したりできます。 そして何が起こるかは、ツールがSQLを開発することです。 多くの場合、SQLは実際にはそれほど適切にコーディングされていません。 そして、これは、サードパーティのアプリケーションがあり、SQLが社内で記述されていないという状況にも当てはまります。そのため、DBAとして、「私はSQLを制御しません。まあPreciseは、他のデータベースツールが提供していることを知らない何かを提供します。それはオブジェクトビューです。 推奨事項とモデリングとの組み合わせ。 そして、私たちにできることは、実際に頭の視界を変えることです。 アクティビティを見るだけでなく、システム上で最も重いオブジェクトを調べましょう。 また、画面の下部には、オーダーラインSQLと「in MS-SQL」列が表示されます。 注文明細表は、システム内の他の表よりも10倍忙しいようです。 上半分で気づくと思いますが、スペースの割り当てが増えており、実行しているソフトウェアのバージョンをサーバーの仕様で確認することもできます。 Preciseは実際に、プライマリ設定に対する変更の追跡を確認します。 もう一度、原因と結果。
オーダーラインテーブルに注目すると、詳細な履歴リポジトリでできることは、オーダーラインテーブルに反するSQLステートメントを実際に相関させることができることです。 そして、これらのSQLステートメントのwhere節を調べ始めることができます。 そして、異なるSQLステートメント間でwhere句がかなり似ていることに気づき始めます。 そして、私はあなたにあなたの録音システムであなたが同じことを見つけることを提案します。 ビジネスユーザー、ビジネスアナリストは、最終日、先週、先月、最後の四半期、昨年の集計ビジネスアクティビティなどを行いたいと考えています。 where句、order by、group byに非常に似たものが表示されます。つまり、これらのSQLステートメントに意味のある特定のインデックスが存在することになります。
したがって、Preciseには推奨エンジンがあり、右上隅にあることがわかります。実際に推奨を取得することができます。 「ねえ、私はすべてのSQLステートメントを実行しています、どのインデックスがそれらに対処しますか？」と言ってください。インデックスが表示され、実際にDBLを見ることができます。 現在、Preciseは読み取り専用であり、ボタンをクリックしてインデックスを作成する機能は提供していませんが、Precise以外では簡単に実行できます。 しかし、ここで重要なことは、Preciseを使用すると変更を評価およびモデリングできるため、画面の左下隅にこの評価ボタンがあることです。 そして、それは、前後のSQLステートメントを表示することです。
これらのSQLステートメントを見てみましょう。 ここに、「MS-SQLで」というこのコラムがあり、1時間4分と書かれていますか？ その上位のSQLステートメントは、約64分のリソースを実行または消費します。 予測される改善率は98％です。 これらの変更により、処理にかかる時間を節約できます。 次のSQLステートメントは27分で、基本的に3分の1を節約します。 これは約10分の処理です。 まとめると、これらの提案された変更により、実際には数時間および数時間分の処理を節約できます。 そして、これを事前に知ることができ、これをモデル化することができます。 また、「what-if」機能を使用して、「まあ、そのインデックスを作成したくない、または列の順序を変更するとどうなりますか？」と言うことができます。したがって、このモデリング機能を使用できます何が起こるかを正確に知るために。
もう1つ重要なことは、変更を加えると、個々のSQLステートメントについて実際に測定できることです。 前の例でSQLステートメントの履歴を見ました。モデル化された節約を達成したかどうかを実際に確認できます。 そのため、フィードバック、フィードバックループを完成させることは非常に重要です。
さて、これが私があなたのために持っていた最後の例です。 これはSAPショップであり、大規模なアップグレードを行っており、カスタムトランザクションを使用していたため、基本的にエンドユーザーはパフォーマンスに満足していませんでした。 そして、私たちがしたことは、そのエンドユーザーが経験したことに集中することができたということです。 そして、リストの一番上にある「CHOUSE」を見ることができ、応答時間は61秒強です。 この処理は実行に1分かかります。 これで、SAP向けの積み上げ棒グラフが表示されます。 右側には、クライアント時間とキュー時間が表示されます。 青はアプリケーション時間、SAP環境ではABAPコード、そしてデータベースです。 データベースは、Oracle、SQL、HANAのいずれかです。 基本的にそれを示すことができます。
ここで、Preciseで行うことは、そのトランザクションとそのユーザーに対して、SQLステートメントが出力される内容に焦点を合わせることです。 繰り返しますが、そのコンテキストはドットを接続します。 この一番上のSQLステートメントは丸で囲まれ、2ミリ秒で実行されます。 データベースが非常に高速に実行されている場合、データベースを非難することはできません。 実行回数は非常に多くなります。 実際に、ABAPコーダーに戻って、「ねえ、何が起こっているの？」と言うことができます。実際、データベース内のコードが間違った場所に置かれ、ループ内の間違った場所にネストされていることがわかりました変更し、その後測定することができます。 実際にパフォーマンスの結果を確認できます。 SQLステートメントレベルだけでなく、カスタムコードレベルでも。 そして、彼らは4秒半の実行時間で生きることができました。 したがって、これらはPreciseを活用する方法のほんの数例に過ぎません。 簡単に要約すると、Preciseはロケーション別、エンドユーザーID別にパフォーマンスを示し、アプリケーションスタックを通じてコンテキストを提供します。 根本原因を詳しく調べることができます。 そして、大きな差別化要因の1つは、SQLステートメントだけでなく、SQLステートメントの実行速度が遅い理由を知ることができ、競合を識別し、基本的に問題を解決するためのより多くのオプションを提供できることだと思います。 これは、Preciseが提供するものであり、軽量な方法で私たちを消費することができます。非常に深く、非常に困難な問題がある場合、私たちもそれらを取り入れることが大好きです。
エリック・カバナ：申し分なく、それは非常に素晴らしい詳細でした、ビル。 これらのスクリーンショットをすべて表示していただきありがとうございます。 そして、私の観点から、あなたは本当に私が時間の冒頭で説明していたことを本当に達成しました、それはあなたが正しいツールを持っている必要があるということです。 映画で誰かが一度言ったように、方程式の中のすべての要素を識別するのに必要なコンテキストの量を可能にするツールが必要です。 しかし、Dezに引き渡します。彼にはいくつか質問があるので、ビジュアルキャンディのためだけにこれらのスライドをもう1つプッシュしたいと思います。 私は実際に待って、これを取り戻させてください。 しかし、デズ、あなたはいくつかの質問を持っていると確信しています、それを取り去ってください。
Dez Blanchfield：うん、そうだね。 このツールは、私が最初から知っていたので、長い道のりを歩んできました。そして、あなたが実際にスタックの奥深くに実際になったことに気づきませんでした。 それは非常に驚くべきことです。 本当に迅速に、いくつかのことを。 展開モデルは、従来の展開モデルまたは典型的な展開モデルの概要を1〜2分ですぐに確認できます。 仮想マシンとして利用可能であると述べました。 クラウドで実行できます。 そして、おそらく出てくる質問の1つで、Q&Aセクションでいくつかの質問が出されたと思います。 要約すると、通常の展開モデルと必要な軸の種類は、従来はオンプレミスで展開されていましたか、それともホストされていましたか、それともクラウドに展開されていましたか？ 通常表示される展開モデルの種類は何ですか？ そして、それを機能させるには、どのタイプの軸が必要ですか？ ネットワークアクセスなどのセキュリティレベルで変更する必要がありますか？ または、これはエンドユーザーとして動作するだけですか？
ビル・エリス：ええ、だから現在のインストールの大半はオンプレミスです。 より多くの人がアプリケーションスタックのコンポーネントをクラウドに配置しているため、それも同様に処理できます。 実行するサーバーが必要な展開は、特定の仕様を満たします。 履歴リポジトリを保存するデータベースが必要なので、これらの前提条件を満たすことは最初の一歩です。 次は、アプリケーション自体についてある程度の知識が必要であり、インストールはウィザード駆動型であり、基本的に空白を埋めることです。 取得している情報の深さから、Webプロセスレベルから実行中のコードまで、ある程度の特権が必要です。 トランザクションなどのメタデータを使用しているユーザーとは完全に分離された資格情報の下でエージェントが実行されるため、セキュリティデータモデル、またはセキュリティモデルが必要です。 正確にはTCP over IPを介して通信するため、特定のポートを開く必要があります。 簡単な例として、デフォルトポートが2702のようになります。このタイプの詳細なものは、人々が興味を持っているものであれば、より詳細に調べることができます。 しかし、通常、私たちは非常に迅速に価値を実現しています。 誰かが大きな問題に直面している場合、私たちはしばしばそのものをインストールし、数時間で状況に明るい光を当てることができます。
Dez Blanchfield：ええ、私も間違いなくその意味を理解しました。 展開モデルでは、非常に大規模で最大500個のインスタンスと、それをフェデレーションする方法について説明しました。 入門レベルでは、誰かが望んでいる場合はどうなりますか。IDERAが無料トライアル、無料デモへのアクセスを提供していることを知っているので、ウェブサイトでほとんどすべてを再生できることを覚えています。 ここの人々にとって、私は以前にそれを逃したと思いますが、典型的なサイトがどのように見え、人々がどのようにこれにアクセスし、それをプレイし始め、そのタイプを取得するのかについて疑問が生じたと思いますいくつかのパフォーマンスの問題に対処する方法があるかどうかを見ることができる経験のですか？ ODSをダウンロードして、ハイパーバイザー、Hyper-V、またはラップトップで起動できますか、それを実行するために専用のマシンが必要ですか？ 前にアーキテクチャの概要を説明しましたが、ごく簡単に1〜2分で、たとえば概念実証を行うためのエントリレベルの展開ではどのように見えますか。
Bill Ellis：ええ、だから私たちのモデルはIDERAツールとは少し異なります。 弊社の営業担当者に連絡したいというエンバカデロのシナリオにもっと適合します。 課題とは何かについて話し合いたいと思います。その後、通常、SEの1つが割り当てられ、基本的に誰かとインストールを行います。 通常、ラップトップではPreciseを実行しません。 収集を行うために、アプリケーションが存在するデータセンター内にVMまたはサーバーが必要です。 しかし、私たちはそのすべてのステップを通してあなたを助けたいです。 誰かがそれを追求することに興味があるなら、あなたは間違いなくIDERAに連絡したいです。
Dez Blanchfield：私が感銘を受けた他のことの1つは、つまり、今日取り上げてきたことの多くは、パフォーマンスの問題に対応することです。 しかし、私にとっては、そして人々がそれらを使用しているライブ環境で、最初のスライドショーとして誰かが電話を取り、「アプリケーションの実行が遅い、助けて」と言うように思えました。しかし、アプリケーションのプレリリースまたはアップグレードまたは新しいパッチと修正を行う場合は、一連の容量計画とストレステストを行い、Preciseで環境全体を確認し、実際に問題を見つけてから、エンドユーザーを環境に配置することもできます。 それはあなたが前に見たユースケースですか、それとも人々がそれをやっているのですか、それは典型的なユースケースではありませんか？
Bill Ellis：もちろん、アプリケーション開発ライフサイクルまたはアップグレードライフサイクル全体でもPreciseを使用したいと考えています。 Preciseはスケーラビリティビューを提供し、実行時間と応答時間を重ねて表示します。 明らかに、実行回数と応答時間の両方が同時に増加した場合、スケーリングしていないため、何かをする必要があります。 このタイプのことは非常に役立ちました。 今は少し真実ではないと思いますが、人々が本番アプリケーションをVMwareに導入し始めたとき、彼らは少しためらいました。そして、最初はこういうことになるでしょう、実際にできることは、リソースの消費量を示すことです。これにより、アプリケーションをより効率的にすることができます。 アプリケーションライフサイクルのすべてのステップで、必ずPreciseを使用する必要があります。 しかし、パフォーマンスはパフォーマンスが最も重要な場所であり、Preciseは年中無休のプロダクションモニタリングを対象としているため、可視性なしでプロダクションアプリケーションを実行することは望ましくありません。
Dez Blanchfield：もちろんです 。 その仕様に関するもう1つの簡単な質問-深度テスト、移民、UATなど-このツールを使用することは素晴らしいことであり、アプリ開発者は開発ライフサイクルのライフサイクルを通じて絶対にこのツールにアクセスできることが大好きだと思います。 今見ているより複雑なアーキテクチャにより、専用サービスから仮想化および仮想化に移行し、クラウドホスティングへのアウトソースの採用に移行しつつあります。コンテナ化に。 多くの人々がこれを展開し、ある種の地域またはゾーンをモデル化しているのを見たことがありますか？だから誰かが持っているかもしれません。米国では、個人を特定できるデータは、実際のアプリケーション層からWeb層まで、より安全な環境にある必要があることがよくあります。 そのため、人々はデータベースとアプリケーションを内部に保持するかもしれませんが、Azureや、またはAmazon WebサービスとソフトウェアなどのクラウドプロバイダーにWebレイヤーと配信エンドとアプリケーションなどを配置できるこれらの展開があります。 通常の展開ではどのように機能しますか？ その地域に別のコレクターセットがあり、それらがさらにいくつか集約されているということですか？ 正確な世界では、古いレガシースタッフのITを1か所で実行する今日のバイモーダルアプローチのように見えますが、商品は時々クラウドにありますか？
Bill Ellis：ええ、だから私たちは混合環境をサポートしています。 考慮すべきことの1つは、クラウドプロバイダーとは異なる契約があることです。 それらのいくつかは、クラウド内でのあらゆる種類のエージェントまたはあらゆる種類の外部監視を許可しません。 Preciseでインストールおよび監視するには、その種類のアクセスを許可する種類の契約が必要です。 間違いなくいくつかの制限がありますので、時にはそれらを取り締まらなければならないので、これらの契約に署名するとき、そして/またはPreciseをデプロイする必要がある場合は、それらを考慮する重要な種類の基準です。
Dez Blanchfield：ええ、HDInsightやSQLのようなものを調達しているので、特にAzureのようなものの一部としてサービスの一部としてそれを調達している場合、従来のデータベース環境でさえ多くのインスタンスを見てきましたサービスとしてのプラットフォームとして、通常のツールは非常に深く潜ることができます。なぜなら、それらは実際に内部にあるものを見ることにそれほど熱心ではないからです。 そして、あなたは監視できる特定のレベルまたは深さになり、魔法のカーテンの向こう側に見えない突然のすべてになります。 セルフサービスは重要ですか？ これは、従来、技術チームやCIOのスタッフのみがアクセスできるネットワークオペレーションセンター内で実行されるものですか、それともエンドユーザーに一定レベルのアクセスを提供できるものですか？ たぶん、受付や従来の人事や財務担当者である必要はありませんが、データサイエンティスト、アクチュアリー、統計学者、非常に負荷の高い作業をしている人など、より経験豊富なユーザーです。 これらの重いクエリを実行したときに何が起こっているのか、どこで痛みが生じているのかを確認するために、何らかのセルフサービスアクセスにアクセスできるので、ワークロードの実行方法を調整できますか？
Bill Ellis： Preciseには非常に優れたセキュリティが備わっているため、異なるアクセスレベルを持つユーザーを設定できます。 非常に基本的なレベルでは、ダッシュボードだけが監視を提供します。 そして、あなたが知っているように、誰かがExpert GUIに行きたいと思った場合、あなたが見ることができるものと彼らができることを制限することができます。 そして、以前の質問に戻って、ヘルスケアにはすべてのHIPAA法があるので、いくつかの考慮事項があり、実際にはいくつかの展開オプションがあるので、両方の環境で作業することができます。 このプレゼンテーションで見たデータで考慮すべきことの1つは、テーブルの内容ではなく、パフォーマンスに関するすべてのメタデータであるということです。ですから、実際には、これらの種類のデータにアクセスすることはありませんプライバシーの問題。
Dez Blanchfield：ああ、そうだった。 スクリーンスナップの4番目または5番目のスライドについてユーレカの瞬間があり、パフォーマンスだけでなく、パフォーマンスデータを引き出しているだけでなく、あなたが言ったように、メタデータを引き出していることに気付きましたスタックのさまざまなレベルでは、実際にはコンテンツを見ていません。 そして、これは短期間に展開して環境で何が起こっているかを調べることができるツールの1つであるため、興味深いことだと思いますが、データ自体にアクセスする必要はありません。 乗組員の走り方も見ることができます。 最後に、すぐにエリックに返事をします。質問がある場合は、レベッカにまとめてもらいます。前に、オーバーヘッドはわずかであると言いました。物事の監視側からの顕著なオーバーヘッドでさえ、単に背景を見るだけであるのか、それとも考慮に値しないほど無視できるほどのオーバーヘッドですか？
ビル・エリス：ええ、データベース層では、各テクノロジーは少し異なると思います。 データベース層では、Preciseはオーバーヘッドが最も少ないことでよく知られています。 中間層には、ある種のバランスをとる行為があります。それは、正確であるだけでなく、可視性とオーバーヘッドの点ですべての人に適用されます。 そのため、オーバーヘッドの量を制御するための高度なツールを多数提供しています。 私たちは本番環境向けに設計されており、開発とQAの問題を解決することは間違いなく便利ですが、本番環境で何が起こっているのかを知ることは何もありません。
デズ・ブランフィールド：エリック、最後に質問がありますか？
エリック・カバナ：ええ、文脈が本当に重要だと指摘してくれた素晴らしい仕事をしたと思います。これは、物事のインターネットのこの時代に向かっているなら、すべてが装備されていることを望んでいるようなものです。 そして、製造業の現在の標準はそれを行うことだと思いますが、これは朗報ですよね？ これらのさまざまな環境のすべてから情報を引き出して、それらをすべてつなぎ合わせたいと思うからです。 そして、私はあなたにいくつかのフォローアップコメントのためにそれを引き渡すだけだと思います。 ITアナリストである一部のアナリストが、この複雑な環境で何が起こっているかを監視および分析し、次に何を変更すべきかを把握できるビジュアルインターフェイスを提供することが、皆さんの焦点です。 それは単なるツールではないからです。 ツールが必要ですが、その詳細を掘り下げて答えを見つける人が必要ですよね？
ビル・エリス：ええ、私はそれを一番上まで沸騰させ、どこで最も買い戻しがあるかを優先していると思いますか？ すべての問題がデータベースにあるわけではないため、状況は異なります。 データベースが10分の1秒で実行されている場合、アプリケーション層では3秒かかります。これが最も買い戻しの多い場所です。 そして、問題の層を特定し、層内で何が起きているのかを特定して、買い戻しがどこにあるかに本当に焦点を当てることができます。 それにより、アプリケーションの解像度と最適化が本当に加速され、会議室に集まった人たちよりもずっと速く、ずっと良く、ずっと楽しくなります。
エリック・カバナウ：そうです。 先日、「単に意見を述べるだけでなく、情報を得る」などのような素晴らしいミームを見ました。会議に参加して、情報を入手し、データを指し示すことができます。 それが鍵であり、私たちはそこに着いています、ありがとう。 わかりました。最後にまとめますが、後で見るためにこれらのウェブキャストをすべてアーカイブします。 いつでもチェックしてください。 Techopedia.comにあるすべてのWebキャスト、Hot Techシリーズ、Briefing Roomシリーズを今すぐリストします。オンラインでそれらの人々をチェックしてください。 それで私たちはあなたに別れを告げるつもりです。 ビル、今日はありがとうございました。 デズ、あなたとあなたの努力に感謝します。 そして、次回、皆さんに話をします。 気を付けて。 バイバイ。
