LAC WATCH

セキュリティとITの最新情報

RSS

株式会社ラック

メールマガジン

サイバーセキュリティや
ラックに関する情報をお届けします。

サービス・製品 | 

ベンチマークからみるIBMメインフレーム─AWS EC2 vs IBM LinuxONE

こんにちは。ラックでIBMメインフレームを担当している中田です。

クラウドシフトが叫ばれる中で、実はいまメインフレームが見直されています。IDC Japanの調査によると、2019年通年でメインフレームは売上金額ベースで二桁成長しています。さらに直近となる2020年第2四半期は48%増を記録しているのです。

今回はベンチマークという側面からそのメインフレームの特徴と、なぜ今でもメインフレームが使われ続けるのか、その理由について迫ってみたいと思います。

ちまたのメインフレームのイメージとは

いろいろ言われますよね。「古い」とか「レガシー」とか「DX(デジタルトランスフォーメーション)を実施する上で障壁になる」などとよく言われてしまいます。

一方で堅牢なシステム運用ができる、セキュリティーもバッチリという声もあります。確かにメインフレームには古い要素もいっぱいありますが、なんだかんだ、この2020年代においても依然として使われ続けているという事実があります。単純に企業がメインフレームからクラウドへの移行に躊躇しているだけではないのか、といった指摘では説明がつきません。そのあたりをベンチマークによる客観的な数字を用いて、明らかにしてみたいと思います。

Linux同士で対決させてみる

ラックが取り扱っているメインフレーム「IBM Z」は、ネイティブにLinuxを稼働させることができます。例えばAWS(アマゾンウェブサービス)のクラウド型サーバである「Elastic Compute Cloud(EC2)」で動いているようなRed Hat Enterprise Linux(RHEL8)も、メインフレームで動きます。ただし、IBM ZのCPUアーキテクチャは、x86アーキテクチャベースのものとは異なりますので、IBM Zに搭載したCPU専用のRHEL8が用意されています。

コンパイラ環境は同じですので、ソースコードを移植すれば、EC2で動いているプログラムをIBM ZのLinux環境で稼働させることができます。

同じプログラムが動くということは、ベンチマークを実施していろいろな観点から性能を比較できるということです。そして、比較することにより、メインフレームが持つ特徴が見えてきます。さらに、ビジネスでの活用を見据えた魅力まで展望できるでしょう。

では、ここから客観的な数字を見ながら、メインフレームの特徴を掘り下げていきます。

Linux同士でのベンチマーク概要

メーカーさんは基本的には良いことしか言いません。根っからの技術屋としてはぜひ疑ってかかりたいところです。今回は、「IBM LinuxONE」インスタンスとEC2インスタンスを用意し、性能を比較してみました。

IBMのメインフレームアーキテクチャとEC2インスタンスで使われているx86アーキテクチャは全く設計が異なるため、計算性能が同等となるように、それぞれ比較するインスタンスを選択します。

基準としたのは後述のベンチマーク、円周率計算838万件での処理時間が近似値のものです。LinuxONEとは、IBM ZをLinux専用機として稼働するようにしたサーバで、性能や特性についてはIBM Zと全く同じです。LinuxONEインスタンスについては米マリスト大学が無償で提供しているものを利用しました。

インスタンススペック詳細

AWS(x86アーキテクチャ)

  • EC2 c5.large Intel® Xeon® Platinum 8275CL CPU @ 3.00GHz
  • vCPU 2 Memory 3586MB
  • OS RHEL8

IBM LinuxONE

  • LinuxONE Instance IBM LinuxONE III 5.2GHz
  • vCPU 2 Memory 4096MB
  • OS RHEL8

実はLinuxONEのクロック周波数は、今や5.2GHzに突入しています。メインフレームであるIBM Zも全く同じ中身ですので、メインフレームのクロック周波数は5.2GHzになります。20年前のIBM Zのクロック周波数である770MHzと比べて、約7.4倍という数字を達成するまでに強化されているのです。

進化し続ける LinuxONE CPUアーキテクチャーのグラフ

出典:日本アイ・ビー・エム株式会社

ただし、アーキテクチャがx86アーキテクチャベースとは全く異なりますので、クロックでのEC2との単純比較はできません。

ベンチマーク内容

全く同じソースプログラムをそれぞれでコンパイルして実行し、比較しました。今回は、ものすごく意地悪なベンチマークを用意してみました。メーカーさんからのクレーム覚悟です。

1. CPU計算性能をフルで使うようなケース

円周率の計算を800万桁と1億桁の2通り実施し比較してみました。使ったソースはこちらです。

単純にAWS c5.largeとLinuxONEでどのくらい差が出るのかを見ます。いわゆる「科学技術計算系」の速さがどのくらいなのかを見るものです。

2. 大量のバッチ処理を想定したケース

ランダムでファイルに読み書きするプログラムを作成し、それを1,024個同時に実行させてみました。当然こんなにたくさんの処理を同時に実行すると、システム内部で「切り替え」が大量に発生します。専門的にはこれをコンテキストスイッチといいますが、この大量の切り替えが原因でシステム全体の性能が出ない、という事例もたくさんありますので、このあたりも見てみましょう。

ベンチマーク比較から考察

1. CPU計算性能をフルで使うようなケース

まずは円周率の計算を実行し、それぞれのアーキテクチャの計算処理能力の「速さ」について比較してみます。このベンチマーク結果は、「処理時間が短い」ほど「速い」、すなわち「良い」ということになります。

838万桁

  • AWS c5.large    43秒
  • IBM LinuxONE  41秒
円周率838万桁の計算処理能力の「速さ」についての比較

1億桁

  • AWS c5.large    1,504秒
  • IBM LinuxONE  2,004秒
円周率1億桁の計算処理能力の「速さ」についての比較

1億桁のケースではAWS c5.largeが優位となりました。かなり複雑な科学技術計算にはIBM LinuxONEは得意ではないという結果になりました。1億桁の円周率演算はほとんど現実味がないワークロードなのかもしれませんが、傾向として押さえておく分にはいいことであるということで実施してみました。

とはいえ838万桁ではほぼ互角ですので、一般的な計算ワークロードにおいてはほぼ互角と考えてよいと思います。

2. 大量のバッチ処理を想定したケース

こちらはファイルにランダムで入出力処理を行うプログラムを1,024個、多重で同時に実行した結果を比較してみます。

1024多重におけるプロセス平均処理時間

  • AWS c5.large    589秒
  • IBM LinuxONE  149秒
1024多重におけるプロセス平均処理時間

このベンチマーク結果は、「処理時間が短い」ほど「良い」ということになります。

1024多重における最大コンテキストスイッチ回数(回/秒)

  • AWS c5.large     461,124回/秒
  • IBM LinuxONE  1,958,728回/秒
1024多重における最大コンテキストスイッチ回数(回/秒)

このベンチマーク結果は、「回数が多い」ほど「切り替え性能が良い」、すなわち「良い」ということになります。

この結果は、LinuxONEインスタンスのほうがAWS c5.largeに比べて集中的に処理が実行できることを示しています。単一OS環境上で同時に処理できる量が異なるという傾向が見えてきました。処理時間とコンテキストスイッチ回数の比較から推測すると、AWS c5.largeの4インスタンス分をLinuxONEにまとめて処理させられると考察できる結果です。

ベンチマークで明らかになったメインフレームの特徴

ここまでに分かったメインフレームの特徴をまとめてみます。

  1. 非常に高度な科学技術計算ワークロード以外ではx86アーキテクチャとあまり変わらない計算性能
  2. x86アーキテクチャと比べて、単一OS環境上に集約させて処理しても性能が劣化しない

特に2の「x86アーキテクチャと比べて、単一OS環境上に集約させて処理しても性能が劣化しない」については、その他のプラットフォームアーキテクチャには存在しない特徴です。

実際に、メインフレームで構築された大規模システムをダウンサイジングし、x86アーキテクチャあるいはクラウドへ移行した場合、ほとんどのケースでサーバ台数あるいはクラウドサーバインスタンスが非常に増えてしまいます。

これこそが、メインフレームの性能の高さを物語っています。もともと単一のメインフレームで行っていた処理を他のプラットフォームへと移行して実行する場合、サーバ台数やインスタンスを増やして、並行処理させるというシステム構成が必要になってしまうのです。

OSやデータベースなどCPU(コア数)の規模に応じて課金されるソフトウェアを利用する場合、x86アーキテクチャサーバではライセンス費用が非常に高額になってしまいます。少ないコア数で稼働できる単一のメインフレームで実装すれば、x86アーキテクチャによるサーバ構成と比べて、ソフトウェアライセンスの費用を削減できるのです。

日本アイ・ビー・エム社の説明資料においてもこのことが記載されており、特にコンテキストスイッチの性能の高さについて記載されています。

1024多重における最大コンテキストスイッチ回数(回/秒)

出典:日本アイ・ビー・エム株式会社

集中処理のメリットとは?

データベースの稼働について掘り下げてみましょう。理想のデータベースエンジンとは、システム全体でデータに対する一貫性を持つことができた上で、かつ水平方向へのスケーラビリティーを持つシステムです。

今時であれば、処理量に応じてデータベースインスタンスコンテナを増減できるようなシステムであれば理想です。ただしデータベースエンジンが分散すると、問題になるのが分散したデータベースエンジン同士のデータに対する一貫性です。

これに対する解決策として、例えばグーグルが「Google Spanner」を提供*しています。絶対的なタイムスタンプをもとに整合性を保証する手法です。

* Cloud Spanner | Google Cloud

しかし、単一データベースインスタンスで構築できた方が、一貫性を保ち、リカバリしやすいシステムを設計する上では好都合です。特に、ラックが得意としている金融系システムにおいては、システム内の複数データベースに対して一斉にある時点での整合点を取るシステムが多い上に、レスポンスも要求されます。そのため、水平方向へのスケーラビリティー(サーバおよびクラウドインスタンス数を増やしてキャパシティー拡張すること)に対しては現実性が低いのが実状です。

よって集中処理が得意なメインフレームを垂直方向(メインフレームのCPUアップグレード)に拡張すれば、システム全体の整合性と一貫性を保ちつつ、処理性能を上げられます。それがメインフレームの大きな特徴です。こういった特徴から、大規模な金融系システムにおいてはメインフレームの利用はまだまだこれからも続くでしょう。

ラックは、これからも社会インフラを支えるメインフレームソリューションを全面的に提供してまいります。

参考情報

メインフレームLinuxの実装(後編) - @IT

この記事は役に立ちましたか?

はい いいえ