2020年4月2日木曜日

19インチラックに搭載のメインフレーム（汎用機）上で動くLINUX OS

FLEXCUBEの検索結果はこちら

関連情報:

https://neovisionconsulting.blogspot.com/2019/07/blog-post_1.html?m=1

コメント:

世界中の銀行やクレジットカードなどのWEB決済のWEBサーバーは、古いメインフレーム（汎用機）から、

19インチのラックマウントに収まるIBM製の最新のメインフレーム（汎用機）上のLINUX上で、勘定系ならFLEXCUBEなどや、2019年現在では、上記の環境で、JavaのWEBサイトやイントラネットが数多く導入されている様です。現在C10K問題対応のCycloneフレームワークは、Python2からPython3に移行バージョンアップの為のメンテナンス中です。AIや機械学習などとの相性は良いかも知れません。又、個人的かつ将来的には、プログラム言語Nimは、C10K問題対応で、ベンチマーク上では、最適化されたC言語の次に高速でコンパクトな容量の少ないシステムメモリー上で動作するので、後はAIや機械学習のAPIライブラも充実すれば幸いであります。RustやNimは将来性が高く期待しております。

石塚　正浩の考える優れた理想のプログラム言語とフレームワークの組み合わせについて
1、C10K（クライアント1万同時アクセス問題）に対応する
事。

2、AIと機械学習ライブラリがある事。

3、チームでの開発効率で、コードの視認性と良い意味での

非個性で、良い意味でバラエティ豊かな表現は出来ず、統

一感が出せる事。

4、セキュリティ（脆弱性）の問題が発生しにくい事。

5、マルチコア、マルチスレッド性能が高い事。

6、プログラムが読み書きしやすい事。

7、コールバック地獄対策がされている事。

8、コンパイル言語である事。

9、ポインターの概念が無い事。

10、電子署名周りのための暗号化ライブラリがある事。
※10、JavaとGoでは、電子署名周りのための暗号化ライブラリが実装されている様ですが、他の言語は未確認です。
11、ガベージコレクションが無い事。

上記1～3に該当で、有力なのは、Go lang+GinとPython+Cycloneくらいしか知りません。しかしGo言語のフレームワークはまだ色々ありそうです。
Nimは、C言語の次に早いけど、バラエティ豊かに表現できそうで非個性と言うにはどうかな？それと機械学習ライブラリがあるか現時点では分からないと言う点です。
Juliaは、思っていた程、早くなさそうで期待はずれな感じです。
Go言語と機械学習ライブラリについては、以下にまとめてあります。
http://neovisionconsulting.blogspot.com/2018/08/gotensorflow-prediction.html?m=1
Go言語で開発したWEBサイトを動かすときには、メモリ使用量が少なくて済むというメリットがあります。
Pythonは、AIと機械学習ライブラリは一番充実しており、その方面での開発のしやすさは、メリットとなっております。しかしプログラム言語単体の処理速度はPythonよりGo言語の方が早い様です。
Go lang+GinとPython＋Cycloneはどちらもクライアント一万同時アクセス問題に対応しておりますので、とても高速です。１秒間に１万件のDATAを処理出来ます。Python＋Japrontoフレームワークは、一秒間に百万件アクセスに対応しているらしいです。

上記の1から5の全てと8と11に対応している理想のプログラム言語は、
Rust（ラスト）になります。
Rustは、JAVAやGolangより高速で動作致しますので、銀行やクレジットカードなどミッションクリティカルな現場でますます重要性が増していくと思われます。
2のAI（機械学習）に関してましては、2020.02.22現在Tensorflowバインディングが公開されている状況です。TensorFlowもどきを作られた方もいらっしゃいますが、GPUには未対応の様です。
Rustで開発する場合のチームでの統一感や統合性を出しやすい仕組みについて
https://neovisionconsulting.blogspot.com/2020/02/rustwebgolang_11.html

GoからRustに変更してパフォーマンスを改善しました
https://www.atmarkit.co.jp/ait/articles/2002/10/news038.html

上記の1から9対応で、ただし3と4を除いて全て対応しているのは、Nim（ニム）です。
Nimのマルチコア、マルチスレッド性能は現在調査中です。
Nimは、ベンチマークの結果、最適化されたC言語の次に早い様です。
NimはC10K問題にも対応しています。
メリットでもありデメリットなのは、Nimは、Pythonライクな構文でプログラム出来ます。
プログラミングの書き方は、Pythonライクなので読み書きしやすく、視認性も良く、チームでの開発効率は悪くないです。
しかしGolangに比べれば、悪い意味で表現豊かに出来るので、もしコーディングルールがチームでしっかりしていない場合、たいして打ち合わせしないでWEBサイトやイントラネットなどを開発すると、統一感が出すのが大変である。
NimにもPythonやGoの様な厳格なフォーマッターが登場すれば、上記3のチームでの統一感をを出しやすくなり解決するかも知れません。
お互いに予想していたのと違う物が出来てばらばらで、修正の手間が大変だと言う事です。
脆弱性対策とチームでの統一感を出す一定の品質を担保にするには、ユーザー定義したプラグマをコンパイル時に使用して、エラー、ワーニング、ヒントなどを見てチェックすると良い様です。
https://blog.hirokiky.org/entry/2019/06/03/202745
参考情報：
（もうPythonの細かい書き方で議論しない。blackで自動フォーマットしよう）
NimでもRustの様にコンパイル時に厳格に厳密にメモリリークも含む虚弱性診断のセキュリティチェックを行うオプションを付けられるようになるか、将来バージョンアップした時に改善される事を希望致します。
最速＜最適化されたC言語＜ Nim ＜　Rust　＜　Go　＜　Java ＜遅いの順で左側に行くほど早い様です。
http://h-miyako.hatenablog.com/entry/2015/01/23/060000
参考情報：シェアしました。
ーーー

The Nim version is the fastest for Pandas. Rust is the best overall power for websites!（Pandas用にはNim版が最速。WEBサイト用など総合力ではRustが最高！）
https://neovisionconsulting.blogspot.com/2020/03/the-nim-version-is-fastest-for-pandas.html

ーーー
2020.02.02現在、
Python２＆3では、グローバルインタプリタロック（訳注：LL言語のスレッドが持つ排他ロックの仕組み）の問題が解決されておりません。

代替え方法として、
他の真のマルチコア、真のマルチスレッド対応のプログラム言語を使用するしか方法は無いと思います。
-----------
ーーーーー
なぜ私達は Python から Go に移行したのか
https://frasco.io/why-we-switched-from-python-to-go-19581e27de7c
シェアしました。
ーーー
この頃流行りの言語たち（他）でベンチマーク（Dart, Go, Julia, Nim, Python, Rust 他）
http://h-miyako.hatenablog.com/entry/2015/01/23/060000
ーーーーー
さようならPython、こんにちはGo
https://yakst.com/ja/posts/5253
シェアしました。
----
■Spanner（Google）　DATABASE
Google検索結果はこちら
https://www.google.com/search?sxsrf=ALeKk02AMOqDbwLwyqk5NyM89j-yZAGK2Q%3A1583816172122&source=hp&ei=7B1nXoOkBdGNoASBgrr4CA&q=Spanner%EF%BC%88Google%EF%BC%89&oq=Spanner%EF%BC%88Google%EF%BC%89&gs_l=psy-ab.3..0i30l7j0i8i30.2912.2912..6486...2.0..0.82.82.1......0....2j1..gws-wiz.....10..35i362i39.wemX0KXGBw4&ved=0ahUKEwiDys6Cj4_oAhXRBogKHQGBDo8Q4dUDCAg&uact=5
■高速なACID対応NewSQL　DATABASE
CockroachDB正式版 Ver1.0リリース。
Google Spannerクローンを目指した「CockroachDB」正式版 Ver1.0リリース。
VoltDB
オープンソース VoltDBとは
FoundationDB、ACIDの条件も満たす。＆　NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決！
毎秒1400万回のライト(write)を行うNoSQLデータベースFoundationDB、ACIDの条件も満たす。＆　NoSQLを超えるSQLデータベース「VoltDB」。Cassandraとベンチマーク対決！

通知

谷川耕一[著]

edited by DB Online 2018/05/24 06:00

　ここ最近は、ハードウェアに関する記事を書く機会が大きく減った。そんな中、ゴールデンウィーク中に米国で開催されたDell Technologies Worldでは、より長く最新テクノロジーに対応できるように筐体から見直したモジュラー型サーバー「PowerEdge MX」の発表があった。また3月に行われたIBM THINKでも、POWER 9プロセッサベースのマシンでNVIDIAのGPUをより効率的に使えるようにするための協業の話も飛び出し、ちょっと新鮮な気分を味わった。

IBMは自社ブロックチェーンサービスのプラットフォームにIBM Zを採用

cap — IBM THINK 2018で展示されていたz14 デュアルフレームのマシン
（本文中に出てくるz14 Model ZR1とは別）

　ところでハードウェアの話題と言えば、ここ最近ちょっと気になっているのがメインフレーム。その代表はもちろんIBMのフラグシップマシンIBM Zだろう。言わずもがな、これは「レガシー」とも表現されるマシンだ。クラウドの時代に何を今更メインフレームかと思われるかもしれない。とはいえIBMは、2018年4月にZの新モデル「IBM z14 Model ZR1」および「IBM LinuxONE Rockhopper II」を発表している。これらは、「クラウドコンピューティングに最適な最新のメインフレーム」と位置づけられている。

　IBM z14 Model ZR1は、クラウドデータセンターやプライベートクラウド環境に容易に配備できるよう、業界標準の19インチラックに対応したシングル・フレーム・デザイン筐体を採用している。つまり、既存のデータセンターに設置されている19インチラックにメインフレームを搭載できると言うこと。ストレージやネットワークなどをメインフレームサーバーと同じラック内に格納でき、それで「コンパクトにまとまったデータセンター」を実現できる訳だ。結果的に、メインフレーム環境のキャパシティ増加と設置スペース削減を両立している。

　このようにクラウド時代にも対応するメインフレーム製品をIBMが新たに投入するのは、いまだ世界中でメインフレームが重要なトランザクション処理を担っているから。クレジットカードのトランザクションの86％、年間約8兆ドルの処理がメインフレームで行われている。またATMの290億トランザクション、1日あたり約50億ドルの処理もIBMメインフレームの上で実行されている。IBMメインフレームが処理している1日あたりのトランザクション量は300億以上あり、これはGoogleの検索処理をも上回っているそうだ。

　この堅牢なレガシーサーバーにオープンなLinuxを載せているのが、IBM LinuxONEだ。実はIBM Zでは、2000年頃からすでにLinuxが稼働している。既存システムの更新ではなく新規導入されるメインフレームの用途としては、Linuxサーバーの統合プラットフォームと言うのが多いとも聞く。現状対応しているLinuxディストリビューションはRed Hat、SUSE、Ubuntuで、それらの上ではJavaが動き、MySQLやPostgreSQLなどのオープンソースソフトウェアももちろん利用できる。国内でも三菱UFJ銀行が2,100台のPCサーバーを4台のz/Linuxに統合しており、みずほ銀行でも同様に100台以上のサーバーをZに統合している事例がある。

　またIBMが提供しているブロックチェーンのソリューションにおいては、クラウドで提供する「IBM Blockchain Platform」でIBM LinuxONEが稼働している。エンタープライズ用途でブロックチェーンサービスを提供するためには強固なセキュリティ性が求められ、全てを暗号化するZをあえてIBMはプラットフォームに選択しているのだ。具体的にはZの上でSecure Service Containerを動かし、それを使ってHyperledger Fabricを構成している。セキュリティ以外にも高いパフォーマンス、可用性、拡張性を評価しメインフレームを採用している。

※この続きは、会員の方のみお読みいただけます（登録無料）。

次ページ≫　エンタープライズ企業のデジタル変革ではメインフレームが役に立つ

エンタープライズ企業のデジタル変革ではメインフレームが役に立つ

　メインフレームが新たなデジタル変革の時代にも重要な役割を担う、そう主張するのは何もIBMだけではない。CA Technologiesのメインフレーム担当ゼネラル・マネージャーのアショック・レディ氏は、既存のエンタープライズ企業がデジタル変革に取り組む際には、GoogleやFacebookなどのデジタルネイティブな企業がそれを行う際よりも高い信頼性を求めると指摘する。デジタル変革の中で高い信頼性を提供するプラットフォームとしては、メインフレームにも大きな価値があるという。

CA Technologies　メインフレーム担当ゼネラル・マネージャー　アショック・レディ氏 — CA Technologies　メインフレーム担当ゼネラル・マネージャー　
アショック・レディ氏

　「既存のエンタープライズ企業のほうが、デジタルネイティブな企業よりも求める信頼性は高いものがあります。エンタープライズ企業がデジタル変革を行う際には、デジタルトラストが重要になります」（レディ氏）

　この高い信頼性を実現するデジタルトラストを考えた際に、元々堅牢性と安定性を備えるメインフレームこそが最適なプラットフォームとなる。とはいえ、一方でメインフレームを安定的に運用するための人材はどんどん減っている。そのため、メインフレームの環境を最適化し、いかに効率的にメインフレームを運用できるようにするかが課題となる。「メインフレームの技術者がリタイアしていく中では、AIや機械学習の技術を使って必要な情報を自動で収集、分析して、事前に対応することも必要です」とレディ氏は言う。

　その上でオープンシステムと同様に、さまざまなデバイスからのアクセスに対応する認証の仕組みや、データが国外などに意図せず流出するようなことを防ぐデータ保護の要求にも応える必要がある。メインフレームの人材不足を補い、オープンシステムと同様なDevSecOpsの実現をメインフレームプラットフォームでも実現できるようにするのが、CA Technologiesのメインフレーム活用の新たな戦略となるのだ。

　またAIや機械学習技術を活用する際には、実はメインフレームのほうがオープンシステムよりもリソースが少なくて済む場合もある。その上で、今はメインフレームにオープンなシステム技術がどんどん入ってきている。メインフレームであれば、これらの新しい技術を使って実ビジネスを展開していくような際にも、プラットフォームにもともと高い信頼性と安定した稼働が補償できる環境がある。そのためAIや機械学習のような新しい技術を活用するような場合にも、実はメインフレームの利用にはさまざまな面でメリットが発揮できることになる。

　「今後もメインフレームがなくなることはないでしょう。これからもメインフレームがデジタルエコノミーの一部の役割を担っていきます。メインフレームを活用してデジタル変革を起こす企業のサポートを、CAは行います」（レディ氏）

　多くの企業が、デジタル変革のためにメインフレームを新規に導入するとの判断は下さないかもしれない。とはいえ、自分たちが行うデジタル変革に高い信頼性と安定性が求められるのならば、その要件を満たす環境をオープンシステムを組み合わせて自分たちで作り上げるのではなく、最初からそれらが備わっているメインフレームを活用する選択もあるだろう。自分たちが行いたいデジタル変革のプラットフォームには、いったい何が求められておりそれを実現するには何を選択すればいいのか。必ずしも安価なパブリッククラウドのプラットフォームが求める答えの正解ではなく、IBMが自社ブロックチェーンサービスにZを選んだように、最初から堅牢で高いセキュリティ性のあるメインフレームを選ぶ考え方もあるはずだ。

LINUX runs on an IBM Z mainframe (general purpose machine) on a 19-inch rack mount. (Red Hat Enterprise, SUSE® Linux Enterprise Server, Ubuntu, etc. run.)
（19インチラックマウント上のIBM　Zメインフレーム（汎用機）の上でLINUXが動作します。（Red Hat Enterprise、SUSE® Linux Enterprise Server、Ubuntuなどが動作致します。））
https://www.ibm.com/it-infrastructure/z/os/linux

IBM z15 encryption everywhere
IBM z15 あらゆる場所での暗号化
https://www.youtube.com/watch?v=1A3XixTjC9w
https://www.facebook.com/masahiro.ishizuka.54/videos/3017120514986467/

DevOps practices for IBM mainframe applicationsIBMメインフレーム・アプリケーションのDevOps実践
https://www.youtube.com/watch?v=vIT1tze1Xlw
https://www.facebook.com/masahiro.ishizuka.54/videos/2976992688999250/

勉強の為にシェアしました。

DevOps問題とは？
開発チームとインフラ運用チームのギャップを埋める「DevOps」とは？

皆さんはDevOps（デブオプス）という言葉をご存知でしょうか。

DevOpsとは「開発チーム（Development）」と「インフラ運用チーム（Operations）」を合わせた造語です。
よく混同されがちなアジャイル開発との違いですが、アジャイル開発は開発手法のことを指し、DevOpsは組織論と言われています。
DevOpsを実現するための手法の1つがアジャイル開発と言われてますが、特に決まった定義は存在しておらず、概念としては「開発チームとインフラ運用チームが連携し、協力してアプリケーションやソフトウェアを開発・運用すること」を指します。

■DevOpsを理解するためのオススメ本
・LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)
・The DevOps　逆転だ！究極の継続的デリバリー
・The DevOps ハンドブック理論・原則・実践のすべて

このDevOpsですが、開発チームの目的が「新しい機能の追加」である一方、
インフラ運用チームの目的は「安定稼働」にあるため往々にして摩擦が生じることが問題となっています。

ここではよくある、DevOpsの抱える問題点と、問題となる摩擦を解消する
F5 BIG-IP Cloud Editionについて紹介します。

開発チームが市場投入を急ぐ理由

開発チームがここまで導入を急ぐ理由はなんでしょうか。
昨今、新しいサービスを展開するためには、アプリケーションの存在が不可欠になってきています。
またアプリケーションを開発できる環境や数多くの手法が整備され、市場にサービスを展開しユーザニーズのフィードバックに合わせた改修を進めることが非常に重要になってきています。
このため先駆者になることが後のビジネスに大きく影響を与えるのです。

アプリケーションが市場投入されるまでのIT企業の動向

●現在の IT のアプリケーションに対する投資の
　40% は DevOps モデル

●70% 以上の設定、デプロイ手順は自動化されている

出典: F5 SOAD report

つまりDevOpsが上手くいっていない場合、
導入が遅れビジネスチャンスを逃す可能性があります。

増えるサイバー攻撃とアプリケーションセキュリティの脆弱性

市場へのアプリケーションリリースを優先するがために、セキュリティ面の施策が疎かになってしまう場合があります。
アプリケーションを狙ったサイバー攻撃は多様化・高度化の一途をたどっており、その被害は後を絶ちません。

アプリケーション増加率とサイバー攻撃へのセキュリティ問題

●アプリケーションの数は2021年までに19%のCAGRで増加

●企業が展開するアプリケーション数は平均で200個以上、スマートフォンユーザーは端末上で80個以上のアプリケーションを利用

●WAFで保護されているアプリケーションは25%未満、という回答が36%

●Webアプリケーションに対する攻撃はデータ漏洩の原因の第一位(29%)

●2016年に盗難されたクレデンシャル情報の数は30億以上

出典: F5 SOAD report

データ漏えいの原因　第1位は『webアプリケーション攻撃』から

増加するアプリケーションの数とセキュリティの脆弱性を突かれたwebアプリケーション攻撃によって、被害に遭う件数が増加しています。

本来ならば開発チームとインフラ運用チームが協力して、迅速かつ確実にビジネスの価値を高め、エンドユーザに届けることが理想ですが、それぞれの意見の食い違いにより、十分な施策や時間が与えられないことが要因ともいわれていますが…

DevOps問題：開発と運用の意見の食い違い

開発とインフラ運用、セキュリティチームで摩擦が生じるのは何故でしょうか。
それぞれの現実と理想が食い違い、衝突しているためです。

理想
●アプリの導入＝ビジネス
●ビジネススピードを上げたい
●ユーザニーズを直ちに実現したい

現実
●インフラ設備の手配・セキュリティ対策などにより、サービスリリースまでに時間を要する

理想
●安定したサービスを実現するインフラを提供したい

現実
●各アプリに応じた実装が求められインフラが複雑化
●安定・安全の実装方法がアプリリリースのペースに合わない

理想
●統一性を持ったセキュリティ機能を実装したい

現実
●一元的なセキュリティの管理が難しい
●アプリケーションに応じたセキュリティの適用が難しい

開発チームは「機能の追加」を目的にしているのに対し、インフラ運用チームは「安定したシステムの状態を保つ」ことを目的にしているので、両者の理想を叶えることが難しくなります。
さらに、セキュリティチームはアプリケーションに対するセキュリティ対策を求めるため、３つのチームの要求にどうしても衝突が生じてしまいます。