2017年6月に開催されたInterop Tokyo 2017で、マネジメント&モニタリング部門のグランプリを受賞した「Cisco Tetration Analytics」は、IT運用でコストが掛かる部分を、可視化と自動化によって包括的に改善するツールだ。従来のIT運用管理製品とは全く異なるアーキテクチャで、IT運用の自動化、近代化を実現する。
2017年6月に開催されたInterop Tokyo 2017で、「Cisco Tetration Analytics(テトレーションアナリティクス)」はマネジメント&モニタリング部門のグランプリを受賞した。受賞理由は、「IT運用でコストが掛かる部分を、可視化と自動化によって包括的に改善する」ツールだということにある。
Tetration Analyticsは2016年6月にシスコが発表した製品。早くも2017年2月にバージョン2.0が登場し、小規模なデータセンターおよびパブリッククラウドにおける利用の敷居が大幅に下がった他、運用サイクルをこの製品だけで回していくための機能が強化された。これによって、世界中でユーザー組織の数が急増している。
本記事では、このユニークなツールがなぜ多くの組織に評価されているのかを、具体的に、かつ分かりやすく解説する。なお、別記事「Tetration Analyticsの意外な使われ方と、意外でない効果」では、Tetration Analyticsの利用シーンとメリットを具体的に紹介しているので、こちらもお読みいただきたい。
IT運用といえば、IT運用管理プラットフォームが広く使われてきた。これらの製品の多くは、構成管理を基本とし、変更管理、チケットシステムなどの機能を備えている。こうした従来型のIT運用管理プラットフォームは、運用管理の枠組みを整えるという点ではメリットをもたらすが、実際の運用における作業の効率化や、問題の解決を直接支援してくれるわけではない。
最近では、ITが以前のように静的なものではなく、日常的にダイナミックな変化をすることが当たり前となっている。また、サーバ仮想化やコンテナの利用、ユーザー数の増加とユーザーの多様化、データセンターやクラウドを跨るアプリケーション間通信が増加するなど、ITは複雑化している。
一方で、ITは社内向け、社外向けを問わずサービスとして認識されるようになっており、アプリケーションオーナー、ITインフラ担当者はコスト効率を意識しながら、ユーザーによるサービスの安全で快適な利用を図っていかなければならない。
問題は、アプリケーションの可視化や可用性、パフォーマンス、セキュリティの確保などを、コスト効率よく実行する作業を支援してくれるツールが、これまで存在しなかったことにある。セキュリティ対策にしても、トラブルシューティングにしても、これまでは手探りで、場当たり的な対応しかできなかった。その結果として、何らかの問題が発生するたびに大きなコストが発生し、関係者を悩ませることとなっていた。
Tetration Analyticsは、こうした世界と決別し、全く新しい観点から運用を直接支援。アプリケーションおよびITインフラの担当者が、自信を持ってサービスを提供できるようにしてくれる。即効性、具体性が、多くのプロフェッショナルから評価を受ける最大の理由だ。
昔は「アプリケーション=サーバ(などの単一ハードウェア)」だったが、現在ではデータセンター内のさまざまな要素が、サービスとしてのアプリケーションの可用性やパフォーマンスに影響を与えるようになっている。パブリッククラウドの場合は、さらに不確定要素が多い。
それなのに、データセンターおよびパブリッククラウド上の自社仮想セグメントはブラックボックスで、何が起こっているのかが正確に把握できない。これは、運用担当者にとっては問題を発見し、これを調査し、解決するための糸口すらないに等しい。工具がないのに大工仕事をやれと言われているのと同じだ。
そこで、Tetration Analyticsでは、サーバセンサーやデータセンタースイッチから全ての通信のフローデータを取得、蓄積する。この情報からダッシュボード上でデータセンターの状況がリアルタイムに表示される。さらに後から任意の日時にさかのぼってフローデータを確認したり、検索したりできる。
ネットワーク製品で有名なシスコの製品だからといって、最新のデータセンタースイッチ上のセンサー機能が必須というわけではない。サーバセンサーのみで活用している企業も多数存在する。サーバセンサーでは通信データの他、プロセスリストやCPU利用率などの情報を併せて取得、これらも蓄積される(データセンタースイッチについてもバッファ情報などが取得される)。
ネットワーク機器からサンプリング取得したフローデータにより、トラフィックトレンドの情報を取得できる製品と、Tetration Analyticsとの違いは2つある。
1つはサンプリングではなく、全ての通信についての情報を取得・蓄積し、リアルタイムでの表示および過去のデータを含めた検索を、高速に実行できるようにしていることだ。これによって、障害やセキュリティインシデントが発生した際には、まずその発生を、チケットが上がってくる前に検知し、根本原因および発生経緯を正確に調べられるようになっている。
もう1つはサーバセンサーの存在だ。各サーバ(物理および仮想マシン)の稼働情報が取得できるため、パフォーマンス上の問題が発生した場合、サーバ側とネットワーク側のどちらが、どのように問題の原因となっているのかを突き止めやすくなる。
サーバセンサーだけでも機能を果たせるため、Tetration Analyticsはパブリッククラウドの仮想セグメントにも導入できる。
パブリッククラウドの仮想マシン上で動くアプリケーションが遅いというとき、原因は仮想マシンのスペック不足、同一物理サーバ上の他の仮想マシンの悪影響、仮想セグメントのネットワークのパフォーマンス不足などが考えられる。原因を究明したい場合、場当たり的に関連データをかき集めて、できる限りの分析をするしかないが、それでも十分でないことがあり得る。
一方、Tetration Analyticsのセンサーをパブリッククラウド上の仮想マシンに導入し、普段から情報を収集しておけば、何らかの問題があった場合に、Tetration Analyticsだけで、即座に原因究明に取り掛かれる。
データセンターの可視化に基づき、「一貫しない、その場限りの対応」「不十分な情報を想像で補完しなければならない状況」から、「確立されたプラットフォームに基づく、迅速で効率的な、証拠に基づく正確な対応」へと、IT運用を変えられること、これがTetration Analyticsの根本的な魅力だ。
通常、ITインフラ担当チームによる原因究明や問題解決に時間が掛かったり、説明が不確かだったりすると、アプリケーション担当チームの側で不信感が高まったり、責任のなすりつけ合いになることが多い。一方、Tetration Analyticsを双方の可視化プラットフォームとして活用し迅速にどちらに問題があるのか証拠を提示できれば、不毛な議論の余地はなくなる。
なお、Tetration Analyticsで見逃せないポイントの1つに、DevOpsへの対応がある。「DevOps」という言葉はあいまいだが、最近ではアプリケーション単位でチームを細分化し、さらにアプリケーション側の担当者が、運用までを担うケースが出てきている。
Tetration Analyticsでは、こうした組織体制にも十分対応できる。特定アプリケーションに関するデータへのアクセスを、そのアプリケーションのチームに許すことで、アプリケーションチームは自ら運用が行える。
Tetration Analyticsにおけるもう1つの柱は、取得したトラフィックフロー情報に基づいて、ホワイトリスト型のセキュリティポリシーを作成、これを半自動的に適用する機能だ。
セキュリティポリシーの適用は2つの手法で行える。1つは個々の物理サーバあるいは仮想マシンに対するパケットフィルタ(ファイアウォール)の自動適用。もう1つはシスコのデータセンターSDN(Software Defined Networking)である「ACI(Application Centric Infrastructure)」のポリシーへの自動変換だ。いずれの場合も、ポリシーを作成したら、これを各サーバやネットワークスイッチへの個別設定ではなく、まとめて適用できる。
ホワイトリスト型のセキュリティポリシーでは、特定の仮想マシンや物理サーバが通信できる相手を明示的に設定、これ以外の相手とは通信できないようにする。また、通信を許可する相手との通信の内容、すなわちポート番号についても、明示的に許可する。こうした設定により、想定していない通信を防ぐことで、アプリケーションの保護を強化できる。
Tetration Analyticsにおけるサーバレベルのポリシー適用は、各サーバのパケットフィルタへの設定として実行される。主要な商用ファイアウォール製品に見られるような高い機能はないが、各サーバにおいてフィルタを実行するという点で、各サーバの保護に有利だ。
一方で、ACI(Application Centric Infrastructure)によるポリシー適用は、ネットワークレベルで隔離されるため、確実性が高い。
こうした特性の違いを考慮し、両者を使い分けたり、併用したりすることが可能だ。
ホワイトリスト型ポリシーの作成をやるべきだと考える人は多い。だが、実行が非常に難しいことも事実だ。なぜなら、現在のアプリケーション環境は、他システムとの連携や各種のシステムサービス、バックアップサーバなど、必ずしも明白ではないが必要な通信が発生していることが往々にしてあり、不用意にこうした通信を遮断するわけにはいかないからだ。
ホワイトリスト型のセキュリティへの移行では、それぞれのアプリケーションオーナーにドキュメントを提供してもらったり、聞き取り調査を行ったりするのが一般的だ。しかし、こうした情報が不正確なこともある。このため、「ミスが怖くて、ホワイトリスト型への移行に踏み切れない」ということはよくある。
Tetration Analyticsの最大の特徴はここにある。センサーを設置し、ある程度の期間、データセンター内の通信データを取得すれば、自動的に各サーバ間の通信関係を図示してくれる。常時行われていない通信であっても、確実に記録し、分かりやすく示す。その過程では、通信プロトコルに基づき、データベースサーバ、アプリケーションサーバなどを識別することもできる。
Tetration Analyticsには、こうした通信関係のマッピングに基づき、ホワイトリストポリシーを提案する機能もある。担当者がこれを確認し、場合によっては修正を行って作成を選択すれば、ポリシーを作成できる。
さらに、ポリシーの実行を選択すれば、これをサーバあるいはネットワークに対し、即座に適用できる。
前述の通り、Tetration Analyticsは2017年4月にバージョン2.0が提供開始となった。主要な進化ポイントは、機能と利用オプションの2つに分けられる。
機能における最大の改善点は、前項で紹介したポリシーの自動適用。もともとTetration Analyticsでは、通信モニタリング結果からホワイトリストポリシーを提案する機能と、確定したポリシーをワンクリックで適用する機能を備えていた。
ただし、初期バージョンでは、ポリシーの半自動的な適用が、ACIとの連携の場合に限定されていた。バージョン2.0では、サーバへのパケットフィルタの適用も、ワンクリックでできるようになった。
もう1つは、利用シーンを大きく広げる新エディションの投入だ。これには、中規模データセンター向けの「Tetration-M」と、パブリッククラウドユーザー向けの新たな展開オプションがある。
Tetration Analyticsは、初期バージョンでは最大約1万サーバに対応するエディションしかなかった。このため、非常に大規模なデータセンターを持つユーザー組織でない限り、導入は難しかった。
だが、バージョン2.0で登場した「Tetration-M」により、100〜200台規模のデータセンターでも、十分導入できるようになった。
一方のパブリッククラウド向けオプションでは、パブリッククラウド上に仮想マシンでTetration Analyticsシステムを構築でき、自社仮想セグメント上の仮想マシンを対象とした管理ができるようになった。
こうして導入の敷居が大幅に下がったTetration Analytics。日本でも、導入や具体的な検討を始める企業や組織が増え始めており、期待が高まっている。導入例とメリットについては、別記事「Tetration Analyticsの意外な使われ方と、意外でない効果」をご覧いただきたい。
Copyright © ITmedia, Inc. All Rights Reserved.
提供:シスコシステムズ合同会社
アイティメディア営業企画/制作:@IT 編集部/掲載内容有効期限:2017年9月20日