IBMメインフレームLinuxONEを分析する！

少し前になるが、メインフレームのリボーンとも言えるIBM LinuxONEが登場した。
今回はその登場の背景について分析して見よう。

＝整理が進むサーバーライン！＝

昨年1月、IBMはLenovoにx86ベースのサーバーラインSystem xを売却 した。
2013年度の経営悪化で、同2014年10月には半導体部門もGlobal Foundriesへ売却してハードウェア事業を縮小し、クラウドのSoftLayerと人工知能Watsonへのシフトを鮮明にした。結果、サーバービジネスは下図（Source：ITcandor）のようになった。世界サーバー市場のトップはHPの22.6%、2位はDellで17.7%、IBMのそれは3位だが9.3%である。後ろにはCiscoのUCSが5.2%と迫っている。もはや以前の勢いはない。しかし、Linuxサーバー市場だけを見るとIBMは18.6%でトップ、2位はHPの17.7%、3位はDellの11.6%と続く。

 ＝伴ってOSの整理も進む！＝
ハードウェアベンダーとしての顔をIBMが維持するのであれば、市場のマジョリティーであるx86系の売却はなかった筈である。ただ、売却できないメインフレームやPower製品は多くのユーザーがいる限り、製造を続けなければいけない。ここにIBMの悩みがある。ここまでの脱ハードの結果、IBMがサポートするOSは３種類となった。System z上のzOS、Powerで動くAIX、そしてPowerとSystem zで稼働するLinuxだ。歴史的にIBMメインフレームのOSとして君臨してきたのはｚOS、そのハードウェアは名機IBM System/360だった。その後、2000年末にz/Architectureが発表されてSystem zシリーズとなり、今年1月にはIBM z13が発表された。z13の心臓となるCPUは22nm CMOSのPU（Processor Unit）だ。これは自社設計開発のチップを売却先のGlobal Foundariesが製造したものである。つまりOSは3種となったが、依然として、CPUは難物のSystem zとAIX用のPowerがある。下図はOS単位のIBMサーバーの売り上げを示したものだが、Unixを系譜にもつAIXサーバー売り上げは2012年来低減傾向。同様の傾向にあるzOSはそれでもAIXの2倍はある。伸びているのはLenovoからのOEMであるLinuxサーバーのみだ。こうみると、長期的にはAIXもｚOSも出来れば、徐々にLinuxに移行したいところだろう。

＝登場したLinuxONE！＝
そして登場したのがLinuxONEである。
このブランド名でサポートしているハードウェアはSystem z。稼働OSは当面SUSEとRed Hatだが、来年にはUbuntuも加わる予定だ。IBMによると、既存、System zユーザーの1/3はLinuxを使用しており、ニーズは高いと説明する。提供されるのは、IBM z13ないしはzEC12ベースの「LinuxONE Emperor（皇帝ペンギン）」とIBM zBC12ベースの「LinuxOne Rockhopper（岩飛びペンギン）」だ。Linuxのマスコットのペンギンにあやかったシリーズである。前者の大規模向けは350～8000台のVM、後者の中規模システム向けでは40～600台のVMが稼働できる。LinuxONEはクラウドやビッグデータで必要な各種のオープンソースソフトウェアを採用し、さらにユーザーコミュニティー促進のために、IBMはLinuxONE Developer Cloudを提供予定だ。位置付けは超大型のLinuxサーバーである。

＝メインフレームの良さは何か！＝
こう見てくると、メインフレームの良さは何だったのか、という疑問に突き当たる。
これまでｚOSは閉ざされた世界の高速トランザクションマシンとして重要視されてきた。バンキングやエアーラインなどミッションクリティカルで高速かつ完全なセキュリティーが求められる分野である。しかしながら、LinuxONEはオープンソースベースだ。製造を止めることが出来ないSystem z上で、これまで通りｚOSユーザーには閉鎖性を武器にし、Linuxユーザーにはブレードサーバーを超えた高速性とセキュリティー重視の製品を提供する。このややもすると二律背反の回答を求めて、Linux Foundationの中にIBMはOpen Mainframe Projectを立ち上げた。初期メンバーはIBM、BMC、CA Technologies、Marist Collegeだ。「セキュリティー重視のLinuxとは何か」、これがプロジェクトのテーマである。諸兄は、既にLinux FoundationにはCarrier Grade Linux、そしてトヨタが主導して始まったAutomotive Grade Linuxプロジェクトがあることを知っているだろう。IBMの求める回答がここから生まれるかもしれない。

欧州から見た世界のクラウド…ITCondorの報告！

前々回はSynergy Researchの「２Q Public Cloud売り上げ」について取り上げた。今回はITcandorの報告を見てみよう。ITcandorはIT業界で豊富な経験を持つ英在住のMartin Hingley氏のブログでもある。氏の情報は米国情報の溢れる日本にとって、欧州から見た世界のIT業界を俯瞰する上で大いに役に立つ。 

＝タイプ別クラウド売り上げ予測 （2009-2020）＝
下図はITcandorが推測したタイプ別のクラウド売り上げだ。氏によると、エンタープライズの直近のハードウェア売り上げは＄146B（約17兆5,200億円）、これまでデータセンター構築に向けられていたこれらの投資は自営センターからクラウドへ顕著に移動しているという。クラウド売り上げの実績は2015年半ばまでのPaaSを1とすると、IaaSが約倍の2、SaaSは3となっていた。しかし2020年までの長期予測ではPaaSが1で、IaaSは2の比率は変わらないが、SaaSは大きく伸びて4～5倍となる模様だ。これを金額で見ると、今年6月現在ではIaaS/PaaS/SaaSの総計は$94B（約11兆2,800億円）、これが2020年には$206B（約24兆7,200億円）と2倍強となる。

＝プロバイダー別ではどうか！＝
クラウドタイプやプロバイダー別に見るとどうなるか。
6月末時点のクラウドサービス総売り上げ（$94B＝約11兆2,800億円）の内訳は、IaaS/PaaSが$45B（5兆4,000億円）、SaaSが$49B（5兆8,800億円）となった。プロバイダー別では、$5.8B（6,960億円）を達成したIBMが全体の6.2%を占めてトップとなった。しかしAmazonなどのプロバイダーと異なり、IBMは総合的なサービスを展開するSIerとして、これには各種の関連サービスが含まれている。IaaS/PaaS分野のトップはAmazonで12.1%、金額では$5.445B（6,534億円）。同様にSaaS分野のトップはSalesforce、シェア11.1%、金額では$5.439B（6,527億円）となった。

＝為替で大きく変わる！＝
以上見てきたように、ITcandorの分析は、前々回のSynergy Researchと大きく異なるように見える。何故だろう。 理由は２つ考えられる。ひとつはITcandorが企業発表のデータをそのまま使用しているのに対し、Synergy Researchは独自の加工分析を施している。企業はなかなか生の数字を出したがらない。Amazonにしたところで、今年4月に発表された１Q決算から初めて詳細な数字がでた。それまでは財務諸表の「Others-その他」の中の主要部分がクラウドと考えられていた（詳細はここ）。IBMの場合、クラウド関連のコンサルからSI、そしてPublic/Private上での実稼働売り上げが含まれていると思われる。これらの扱い次第で、AWSがトップとなったり、IBMが上になったりするわけだ。もうひとつは為替である。強いドルに比してユーロと円は安い。その結果、下図のように大きなかい離が生まれる。

Rackspaceの新たな選択－Amazonと提携！

先週、RackspaceがAmazonと提携するというニュースがWSJなど幾つかの米メディアから流れた。米国時間の火曜日から始まるAmazonのカンファレンスAWS re:Invent 2015（10/6-9）でのアナウンス予定についてである。先行情報によると、Amazonはエンタープライズ顧客をしっかりとサポートするためにRackspaceと提携する。これはAWSの弱みであるサポート強化をRackspaceから受けるためだ。受けて立つRackspaceはAWSを販売し、定評あるFanatical Supportを提供する。（正式発表はここ）

＝競合から共存へ！＝

RackspaceとAmazonは周知のようにこれまで競合関係にあった。2006年Mossoから始まったRackspaceクラウドはNASA Amesと共同でOpenStackプロジェクトを立ち上げた。2009年のことである。以来、Rackspaceは自社クラウドを徐々に整備して、完全なOpenStackベースに置き換えてきた。並行して、米国内ではOpenStackをPrivate Cloudとして採用する大企業が増加。この分野のSIで成功している企業がMirantisである。 しかしPublic Cloudでは、先行するAWSが大きなパイを握り、エンタープライズで実績のあるMicrosoftやIBMが追い上げている。混沌とした状況の中、既報（1、2、3）のようにRackspaceは昨年もだえ苦しんでいた。企業売却か事業継続か。そして選択した戦略は「競合から共存へ」だ。同社がもっとも得意とするのは充実した人材によるサポートである。企業がオンプレをPublic Cloudに移行する際、もっとも気になるのはセキュリティーやサポートである。だからこそ、各種のDedicate Servcieが流行るのだ。Rackspaceはこの高品質なサポートの提供でこれまで業績を伸ばしてきた。この武器を競合相手にも提供しよう、それがRackspaceの生き残りをかけた決意となった。今年7月中、まず手始めにRackspaceはMicrosoft AzureのリセラーとなってAzure Supportを開始。そして今度はAWSを販売し、そのサポートを受け持つ。競合の彼らが出来ないことをRackspaceが担当し、新しいエンタープライズ需要に応える覚悟だ。勿論、これまで通り、出来ればOpenStackをPublic Cloudとして販売したい。しかし、それは市場に委ね、競合相手のサービスも付加価値をつけて、販売・サポートする。これこそが現実的な解である。先週末には、同社株価は6.8%アップ、今後の動きを注目したい。

膨らむPublic Cloud売り上げ！ －２Q 2015－

米調査会社のSynergy Researchから、2015年２QのPublic Cloudに関する報告が出た。この報告書の興味深いところは、Public Cloudの市場規模の拡大を投資と売り上げの両面から分析した点である。まずは概括しよう。 

＝設備投資となる「Cloud Build」と「Colocation」＝
発表された図で示される上段の「Cloud Build」と「Colocation」の2つは、Public Cloud Providerによる設備投資を意味し、下段の３つ「Cloud Infrastructure」「Software as a Servoice 」「Internet Service」は売り上げを示している。つまり、どういう投資流入があって、売り上げがどうなって、結果、市場規模はこんな感じだという分析だ。詳しく見ていこう。上段から、まず、「Cloud Build」は設備増強のために費やすハードウェアとソフトウェアへの投資である。同報告書によると、これは年率26%で伸び、２Qでは$7.0B（約8,400億円）。このまま1年に引き延ばせば$28M（約3兆3,600円）というとんでもない金額となる。もうひとつの「Colocation」は、設備増強に伴うセンターリース料で、年率9%で伸び、２Qでは$2.8B（約3,360億円）、年間に伸ばすと$11.2B（約1兆3,440億年）と、こちらも大きな投資であることが解る。これらの大きな投資は、Public Cloudがビジネスとして順調に伸びているということの証左でもあろう。

上図の「Cloud Build」はハードウェアとソフトウェアの投資だと述べた。今回の調査の直近で同じSynergy Researchから発表された「Cloud Infrastructure Market Share Trend」（下図）によると、ハードウェアでは、このところ、Ciscoが優位にHPとデッドヒートを続けてきたが、HPが逆転し始めたという。これは従来型専用機器から汎用機によるSDN（Software Defined Network）の流れと無縁ではないかも知れない。ソフトウェアではMicrosoftが一定の水準を確保しているがIBMはH/S共に過去の勢いはない。

＝売り上げは「IaaS」や「SaaS」、さらに「Internet Service」＝
次に売上げの方を見てみよう。
まずクラウド売り上げの核となるのは「Cloud Infrastructure Services」だ。これにはIaaSやPaaSが含まれ、２Qでは$5.5B（約6,600億円）、勿論、Public Cloudを利用したプライベートユースやハイブリッドユースが含まれる。もうひとつのSaaS売り上げは$6.6B（約7,920億円）となり、IaaS/PaaSを超えている。これは当たり前と言えば当たり前で、まずIaaSの普及があって、その上でPaaSを利用したアプリ開発が進み、結果としてSaaSビジネスが拡大するという流れである。さらに、サーチやSNS、eメール、eコマースなど従来からのInternet ServiceがPublic Cloudで稼働する市場は途方もなく大きい。

＝２Q総計では$20B（2兆4千億円）規模＝
以上を整理すると、Public Cloud市場は、流入する投資と急成長の売り上げの両方が相まって、２Q総計で$20B（2兆4戦億円）を超える規模となった。大雑把な内訳は、H/Sとセンターのリース料などの投資が約$10B弱、IaaS/PaaS/SaaSなどの売り上げが$12.1Bだ。今後はこの両輪のバランスがどう変化するのかがポイントとなろう。

コンテナーの世界（８） ミニマルOS －RancherOS

＝こんどこそ、Rancher Labs！＝ 

　シリコンバレーの北西にあるクパティーノ市のRancher Labsから、Docker専用のLinuxディストリビューションRancherOSが出た。話の本論に入る前にこの会社の生い立ちについて触れておこう。Racher Labsの入るオフィスビルはStevens CreekとN. Wolfeの角、何と筆者が以前いたオフィスと同じビルだ。奇遇な話である。同社のファウンダーは4名。核となるのはSheng Liang氏だ。氏は元Sun Microsystemsのリードデベロッパーで2008年に、当時名を馳せたCloud.comを立ち上げた。その時の事務所もクパティーノだった。当時、同社が開発したのはApache CloudStackのもとになったオープンソース製品である。しかし、ビジネスの方は、台頭し始めたOpenStackに押され気味となり、統合の道も模索したが結局、2011年にCitrixに買収された。そのCitrixもクラウド事業が上手く立ち上がらず、Apache Foundationにコードを寄贈、現在に至っている（詳細は当ブログのここ ）。そして、Liang氏は、買収されたCitrix時代の3人の仲間と2014年にRacher Labsを立ち上げた。当初受け取ったシーズファンドは$10M（約12億円）、この6月にはさらにAシリーズとして$10Mを受け取った。

＝ミニマルOSを目指すRancherOSの試み！＝
さて同社が今年7月に発表したRancherOS βは、Dockerを効率よく稼働させるミニマルOSである。この小型OSの市場には既にCoreOSやSnappy Ubuntu Core、さらにRed HatのProject AtomicからはRHELだけでなく、FedoraやCentOSなども出て、ひしめき合っている状態だ。これらに打ち勝つために、RancherOSは、ブートに特別な仕組みを持ち込んだ。通常、Linux機に電源を入れると、ブートローダーがカーネルを呼び込み、次にプロセスID（PID） 1で initプログラムが起動する。しかしRancherOSではここですぐにSystem Dockerが読み込まれ、その上で各種サービスを実行する。これらは初期ルートファイルのinitrd（initial ram disk）に相当し、そのサイズはたったの20MBだ。この仕組みによってRancherOSは5秒以内で起動ずる。CoreOSが100MB以上なので、RancherOSが如何に小さいかが解る。ユーザアプリはというと、System Dockerが持つUser Dockerサービスが作成するコンテナー上で稼働する。

＝ストレージ向けConvoy、ELKスタックも！＝

Rancher Labsにとって今年の夏は忙しかった。6月中旬にβを発表すると、1か月後、すぐにDockerCon 2015だ。デモ、プレゼンの毎日だ。そして8月に入るとMesos対応、さらに8月12日、Docker 1.8が出た。この1.8では前回のリリースでは試験的なサポート（Experimental Support）となっていたストレージのコンシステンシーを保つVolume Pluginが正式リリースとなった。Rancher Labsだけでなく、このシリーズで既に触れたコンテナー向けSDSのPortworxやClusterHQ（詳細はここ）などがこれを組み込むべく猛烈に働いている。Rancher LabsがRancher Convoyを発表したのは8月19日。これを使えば、コンシステントなボリュームを作成し、例えばAmazonS3のバックアップをそれに採ったり、リストアが可能となる。季節が秋となり、9月17日には、Elasticの開発した検索エンジンElasticsearchとログ収集のLogstash、フィルタリングのKibanaを統合したログ管理システムをELK Stackとしてリリース。同社にとって、今年の秋は実りの多いことが予感される。

コンテナーの世界（７）－マネージメントツール －Panamax & StackEngine－

「コンテナーの世界」－第7回は、Docker向けマネージメントツールなどを開発している２つのプロジェクトを紹介しよう。

＝DockerをLegoのように扱うたツール＆ライブラリー：Panamax＝

Panamaxは米3大キャリアの一角を占めるCenturyLinkが昨年夏に発表したプロジェクトだ。目的はテンプレートを用いて、より人間的なコンテナーの管理ツールを整備すること。キャッチフレーズは「Docker Management for Human」。実際のところ、複数のアプリを連携させるマルチコンテナー開発にはかなりの手がかかる。Panamaxではこの煩雑さを緩和するための自動化や直截的なドッラグ＆ドロップによるプロビジョニングを目指している。このために用意されたDrupal, GitLab, Grafana on InfluxDB, MediaWiki, OpenStack, Rails, WordPressなどの公式アプリ群はPanamax Public Templatesとして登録され、ドラッグ＆ドロップしながらデプロイする。これらテンプレートの拡充に向け、昨年は同社による賞金10万㌦（約1,200万円）のコンテストも行われた。下記のデモでは、「WordPress」をPanamax Templates & Docker Ripositoryから探すと、単独のWordPressだけでなく、幾つもの使用例にあったテンプレートが表示される。「WordPress with MySQL」を選べば、WordPressのバックエンドにMySQLがリンクされたコンテナーセットがワンクリックでプロビジョニングされる仕組みである。

過去を振り返ると、米キャリアは西海岸を核とするAT&Tと東のVerizonの２強、これからかなり離れて中西部のQwest Communicationsが３位だった。当時５位で中南部ルイジアナのCenturyLinkがQwestを買収したのは2010年、そして経営刷新を目指してクラウド事業に参入した。翌2011年にはクラウドサービスを展開していた大手計算センター SAVVISを買収してクラウド事業に参入。さらに2013年にはIaaSのTier 3、PaaSのAppFogを買収して体制を強化した。CenturyLinkの責任者は「PanamaxはDockerをより簡便に、Legoのように簡単に組み合わせて使用する。これによって、デベロッパーはラップトップから、Dockerだけでなくベアメタル上でも簡単に展開が出来る」と説明する。

＝コンテナーAppマネージメント：StackEngine＝ 
StackEngineはテキサス州オースチンが本社。昨年、$1M（約1.2億円）のシーズファンドを受け、ステルスを抜け出てた。同社の狙いは、コンテナーの世界のアプリケーション管理ツールになること。つまり、Linuxの設定やサーバー管理ではChefやPuppetが普及しているが、StackEngineはそのDocker版を目指している。StackEngineの適用の<ステップ１>は、コンフィグ管理だ。扱うコンテナーはオンプレミスでも、Public Cloudでも、Hybridでも構わない。これらリソースをプール管理し、開発やQA、本番などステージ毎に管理する。DevOpsのためには、関わる複数ユーザや役割がアサインできる。<ステップ２>はアプリのデプロイメントだ。これにはDocker RegistryやGitHub、Jenkinsなどを使ったデプロイ、テンプレートからのローンチも可能だ。この過程でDockerアプリは用意されたエディターでドラッグ&ドロップで組み合わせることが出来る。<ステップ３>は実行時のコンテナーオーケストレーション。オーケストレーションの実行はリソース状況からホストが決められ、さらにユーザが好めば、MesosやKubernetesに代わる２次元オーケストレーションモデルも用意されている。

StackEngine Overview

＝２社の違いとエコシステム！＝
２つの似たようなサービスと製品を紹介した。
前者のPanamaxは、基本的にはCenturyLinkクラウドのサービス強化として始まった。勿論、他からのアクセスも可能なプロジェクトなので、多くの興味が集まっている。目的はテンプレートによるデプロイの簡素化だ。一方、StackEngineのカバーする範囲はかなり広い。各ステージ毎のコンテナー管理からデプロイや実行までだ。２つはダブっている部分もある。テンプレートによる簡易開発か、総合的なコンテナー管理か、が違いである。このような動きは、Dockerを中心としたコンテナー技術がまだまだ未熟であることの証左でもある。これまでシリーズで述べてきたストレージ関連のPortworxやClusterHQ、ネットワーク関連のSocketPlane（Docker買収）やWeave、Flannel、セキュリティー/モニタリング関連のTwistLockやSysdigなどは、Docker（もしくは標準化が進むコンテナー技術）を核としたエコシステムとなるのか、はたまた、一部ベンダーはDockerを脇に押しやり、自身がプラットフォームとして中心となることを狙っているのかもしれない。

コンテナーの世界（６） －モニタリング＆セキュリティー！ －TwistLock & Sysdig

この「コンテナーの世界」シリーズでは、前半（ １、 ２、 ３ ）ではコンテナー技術の動向、後半（４、５ ）では新しいエコサイクルを作るSDSやSDNのスタートアップを紹介してきた。今回はモニタリングでセキュリティー改善にに取り組むスタートアップを紹介しよう。

＝TwistLockは新たなコンテナーセキュリティに取り組む！＝
企業がコンテナー技術を導入する際の課題は幾つかある。なかでもセキュリティは厄介だ。今年5月、ステルスモードから抜け出たばかりのTwistLock（本社：Tel Aviv & San Francisco）はコンテナーのセキュリティの改善を目的に設立された。Twistlockとは、本来、貨物コンテナーを船舶やトラックで輸送時に固定する緊締装置のこと。眠っていたLinuxコンテナー技術の目を開けさせたのはDockerだ。しかし単一Linux上で複数のコンテナーを連動実行させるには不安定な要素が多い。それをしっかりと固定させるのがTwistLockの役目である。コンテナーがこれまでの仮想化技術にとって代わるには、安全に稼働させる仕組みが要る。そのための第一歩が発表した「Virtual Container Security Suite」だ。企業が必要とする幅広いコンテナー利用の可視化とその制御が当面の狙いである。ひとつひとつのコンテナーは、膨大なエンタープライズアプリ群の部品であり、実際のところデベロッパーはそれらを再利用しながら開発を進める。このため、連携型のコンテナーアプリには脆弱性が内在する。TwistLockはこれらへの対応として、洗練したUIで静的なコンテナーイメージとランタイムの両方を可視化させ、加えてパッケージングにはセキュリティーポリシーの導入を要請する。この際、公開脆弱性情報のVCEやプロバイダー、オープンソースプロジェクトなどが提供する情報を元にセキュリティーの脅威を最小化しようと試みる。TwistLockは発表と同時に$2.5M（約3億円）の資金も手に入れ、テイクオフ体制に入った。

TwistLock Diagram

＝Sysdigもモニタリングでセキュリティに挑戦！＝
次に紹介するSysdigは「Container Visibility Company」を目指してLoris Degioanni氏が2013年に設立した会社だ。Sysdigのβリリースは昨年の4月、システムレベルのモニタリングとトラブルシューティングツールだった。それが進化し、クラウドサービスとなったものが今回発表されたSysdig Cloudだ。Sysdigの利用はSysdigコンポーネントをDocker開発環境のコンテナー上に展開するだけ。Sysdigのアーキテクチャー（下段Slideshare参照）では、通常のアプリやコンテナーとやり取りするカーネル間にフッキングのインスツルメントレイヤーがあり、これによってコンテナー上のSysdigはクラウドを利用しながら、収集される全アプリデータを分析する。対応するソフトはCentOSやCoreOS、ubuntuなど各種OS、DockerやRocketなどの各種コンテナー、MySQLやPostgreSQL、Riakなどの各種DB、さらにAWSクラウドなどでも構わない。Sysdigが提供する分析サービスは３つ。①Real Time Dashboard－全てのパフォーマンス情報をリアルタイムで表示し、これによってシステムの異常や特殊な動きを見つけ出す、②Historical Replay－これらの表示データは全てクラウド上に格納され、どの部分でも遡って再表示が出来る、③Dynamic Topology－さらにSysdigは全てのコンテナー化されたインフラを自動的にトポロジーとして図式化する。同社が考えだしたこの方式は「ContainerVision」として、現在特許申請中だ。VCからの投資は、設立時に$2.3M（約2.7億円）のシーズファンド、今回の発表時にSeries-Aとして$10.7M（約138億円）を獲得し、拡販への体制が整った。

＝エンタープライズのコンテナーセキュリティーとは！＝
以上見てきたように、同一OS上でリソースシェアリングするコンテナー技術は、これまでのハイパーバイザーに比べて、パフォーマンスは高いが、セキュリティー面で難がある。この課題に関するパーフェクトな解決策は見当たらない。そこで運用時に徹底したモニタリングをしてトラブルの早期発見に努め、合わせてパフォーマンス監視も実行する。また、開発時の再利用のリパッケージングにはポリシー適用も効果的だ。いずれにしても、エンタープライズアプリのコンテナー利用は、クローズドな環境が幸いして、当面は徹底したモニタリングやポリシー適用で凌ぐことになるようである。