テックポエマーの10min IT News! - 2020/07/11 - 「悪の帝国の今とOSS」 を公開しました

techpoem

www.youtube.com

今回はせっかくなので新しく作った新アバターを配信で使って見ました。

今週はMSにしろOracleにしろOSSと絡めた話が多かったですね。どちらもOSSのイメージなんて10年前は無かったので感慨深いです。かつては悪の帝国とか言われたりOSSは敵だと言ってた会社なんですよねぇ。

あと、なんといっても個人的な驚きと期待のニュースはGoogleによるNorthの買収ですね。

今週のサマリ

動画中の引用記事

Product Update

Helidon 2.0 Release

medium.com

Coherence Community Edition Release

coherence.community

blogs.oracle.com

理化学研究所、Oracle Cloudで「富岳」の高度な計算資源の有効活用と研究成果創出を促進

www.oracle.com

active.nikkeibp.co.jp

Announcing Azure Functions extension for Dapr

cloudblogs.microsoft.com

LINE上で自社サービス展開可能な「LINEミニアプリ」、法人向けにエントリー受付を開始

k-tai.watch.impress.co.jp

MRデバイス「HoloLens 2」、マイクロソフトストアで販売開始

www.moguravr.com

Google acquires smart glasses company North

www.moguravr.com

www.bynorth.com

blog.google

世界１位の謎の半導体 アーム (ARM)とは？

CPU ポエム

TL;DR

  • ARMはx86と同じISA。ライセンス方式なので実装は色々ある
  • 省電力特化というポジションからHPCやサーバにも手を伸ばし始めている
  • A64FX由来のCPUとかが流行ると良いなー

はじめに

先週はARMに関してビックなニュースが立て続けに起こりました。そう、MacのAppleシリコン採用のアナウンスとスーパーコンピュータの富岳がTop500で4冠を達成したことです！

www.apple.com pc.watch.impress.co.jp

この２つはどちらもARMというCPUアーキテクチャをベースにしています。

そしてARMはiPhoneをはじめとするほぼ全てのスマホで採用されているため、世界最速のスパコンで使われているCPUであると同時に数百億台以上のデバイスで動作するまさに最強のCPUなのです！ MacがIntelのCPUから乗り換えても安泰ですね！

と、言う気持ちにもなるかもしれませんが本当にそうでしょうか？ 今回はその辺も含めて少しARMに関して語ってみたいと思います。

ARMはCPUそのものでは無く命令セット(ISA)

CPUというとIntelのCore i7/XeonやAMDのRyzen/EPCYが有名ですがARMはそれらとは少し違います。ARM自体はARM社が設計しライセンスしている命令セット・アーキテクチャ (ISA)です。Core i7やRyzenは具体的なCPU製品です。

ISAとはマシン語で利用するCPUのAPIです。つまりISAが同一であればOSやその他のソフトウェアからは同じCPUとして見えます。逆に実際のCPUの実装はマイクロアーキテクチャと呼びます。そのため一口に「ARM CPU」といっても様々な実装があります。これは同じx86命令セットを採用する初代Pentiumと現在のCore i7が全く違う実装なのと同じです。

これが何を意味しているかというと、スマホに使われているA12やSnapdragonと富岳に使われているA64FXは異なるマイクロアーキテクチャを採用しており全然違うCPUだということです。富岳はスマホに使われているチップを大量に乗せてスパコン1位になったわけではないですし、Macに今後採用されるCPU(A12カスタム？)がスパコンに使われているのと同等なものでもないのです。

富岳はSPARCアーキテクチャはすでに廃れていてソフトウェアスタックが貧弱なこと、Macは色々あるでしょうが少なくとも一つの理由としてiPadやiPhoneと開発リソースを共有したいということからARMをそれぞれ採用したと思います。

ちなみにARM以外で有名なISAだとx86, RISC-V, Power, MIPSがあります。

ARMとライセンス

ARMの特徴的な点として積極的にライセンス販売をしていることです。通常CPUメーカーは独自のマイクロアーキテクチャとISAをセットで開発して自社か限られた企業のみで展開します。圧倒的シェアのため互換CPUが乱立したx86でさえ現在は本家IntelとAMDくらいです。Power系CPUもIBMで開発されます。

一方で、ARMのビジネスモデルは大きく異なりCPUライセンスをCPUを作りたい会社に売ることで利益を得ています。カスタムのSoCを作りたいとか極端な低消費電力や性能が必要で独自のチップを必要とするケースは多くあります。ただ、ここで独自のISAを作ってしまうとコンパイラを始めとしたソフトウェアスタックをすべて独自に開発する必要があり非常に困難になります。そこで既存のISAを使い独自のマイクロアーキテクチャを使う事ができればこの問題が解決できます。ARMはまさにそこに注目してISAをライセンスするビジネスを行っています。

ARMのライセンス方式は大きく分けて以下の2つがあります。

  • Architecture License
  • Cortex License

アーキテクチャライセンスはISAのみを提供して自由にARM互換チップを作れるライセンスです。マイクロアーキテクチャをすべて自前で用意するため難易度は高いですが、自由度も高く技術力による差別化もしやすいので専用チップを作りたい場合に選びます。富士通のA64FXやMacのAシリーズ、QualcommのSnapdragon はアーキテクチャライセンスです。

Cortex ライセンスはARM社が作るリファレンス実装であるCortexをベースにカスタマイズをするライセンスです。手早くSoCを作りたい場合に有効な方式です。多くの企業はこちらを使っていると思います。

この辺りの説明はこちらの図が分かり易かったです。

ちなみにIntelもかつてはXScaleというARMチップを開発していましたし、AMDもサーバCPUブランドのOpteronの名を冠した「Opteron-Aシリース」を持っています。

ARMアーキテクチャの特徴

ARMは低消費電力向けのCPUというイメージが強いですが、それはむしろマイクロアーキテクチャに依存する部分が大きいはずです。

ISAとしては命令セットが少なくシンプルなRISCでありつつ条件実行など頻繁に使われる最低限の高度なCISC風の命令セットを採用したことが、初期段階での低消費電力かつ高性能なという特徴につながってはいたと思います。しかし、それ以上にターゲットが低消費電力だったのでマイクロコードを省いたりキャッシュを小さくしたりアウトオブオーダーやスーパースカラーといった高速化処理を省くといった実装のシンプルさがそのあたりを支えていたと思われます。

現在は様々なマイクロアーキテクチャのARMがあり高性能向けの実装のCPUも多くあります。それらのCPUも現代的なニーズとして高性能と低消費電力を両立したものが多いですが、必ずしもISAがARMだから低消費電力というわけではないと思われます。どちらかというと現在のニーズに最新の技術で１から設計した結果ではないかと。ただ、CISCであり過去のしがらみも多そうなx86よりは...ってのはあるのかもしれないです。IntelやAMDが複数の向けの全く異なるマイクロアーキテクチャを同時に運用するのもしんどいので共通的な部分を増やしたいでしょうし。x86にもCrusoe/Efficeonのような例もありますしね。

現在利用されているARMは主にAArch32と呼ばれる32bitのARMv7, AArch64と呼ばれる64bitのARMv8、次世代規格のARMv9です。スマホなどではARMv8が主流だと思います。また、ARMはそれぞれのユースケースマイにプロファイルを用意しており以下のようになります。

AArch32

基本的にはRISCのため以下の特徴を持ちます。

これに加えてCISC風の豊富なアドレッシングモードを持ちます。またThumb/Thumb-2と呼ばれるよりコード効率の良い命令セットやx86のSSEのようなSIMD拡張命令であるNEONを持ちます。

AArch64

AArch32から命令セットを大きく刷新しています。基本的には汎用レジスタが64bitになったことが最も大きいと思います。ただし、命令長は32bitです。また、歴史の積み重ねで不要になった条件付き実行などの命令セットも多くが削除されており効率かつスッキリとした実装に変わったようです。SIMD命令もNEON改ASIMDとして強化されています。

ARMv8は従来の32ビット命令を全てサポートしているので、x86-64と同様に32bit OSや32bit アプリケーションを動作させることができます。また、サーバ用途を見据えているためVT-xのような仮想化支援機能もついています。最近はAI支援()、セキュリティ機能も強化されているようです。

そして、HPC向け限定ですが富士通と共同開発したScalable Vector Extension (SVE)もSIMD命令として追加されました。用途が違うので当面の間ASIMDとは共存していく関係のようです。

ARMv9ではセキュリティの強化、マトリックス演算/ベクタ演算の強化、メニーコアを見えたトランザクショナルメモリ対応、カスタム命令セットなどが予定に上がってるようです。

AArch64の特にAプロファイルはIntel/AMDにも負けないかなり高機能な命令セットであることがわかります。

代表的なARM CPU

代表的というか個人的に気になってるCPUを書いていきます。趣味の問題でサーバ用とが多めです。

Cortex-X1

CortexはArm社のリファレンス実装です。Cortexシリーズは汎用用途とされていますが、実際問題ARMの利用は基本的にスマホなのでサーバ向けというよりはスマホ向けのCPUになります。X1はその中でも最新のCPUとなります。

まず5nmという驚異的なプロセスが目を引きますね。CPUはプロセスを微細化することで小さくできますし結果として同一面積での処理能力を向上させることができます。

マルチコアはヘテロジニア戦略で異なる世代のCortexや性能の違うコアを複数配置することで全体的な性能と消費電力のバランスをとるBigコアとLITTLEコアを採用しています。

また、X1に限らず最近のCortexは分岐予測機構やスーパースカラはもちろん複数の命令を融合させて実行効率をあげるフューズドMicro-OPsもサポートします。この辺はIntelやAMDが使ってる高速化技術と同様のものですね。

ref: 5nmプロセス向け。性能が2割向上したArm「Cortex-A78」 ～新フラグシップGPU「Mali-G78」なども - PC Watch

Snapdragon XR2

QualcommのSnapdragon XR2はVR（仮想現実）やAR（拡張現実）などのXRプラットフォームをターゲットにしたSoCです。

XR2はSnapdragon 865をベースにしています。865は7nmのプロセスルールで製造されていて、CPUがKryo 585、GPUがAdreno 650となります。Kryo 585はCortex-A77/Cortex-A55をベースにしていて、big.LITTLEを採用した8コアのCPUです。クロックは2.84GHz、L3キャッシュが4MBとなかなかのスペックです。

Geekbench 5の結果は以下となります。

CPUマルチコアシングルコア
Snapdragon 8653450900
Intel Core i5-8250U3200750

ref: 【6/14最新】Geekbenchスコア、スマホSoC別総まとめ | telektlist

モバイル向けとはいえCore i5はTDP 15W、Snapdragon 865はおそらく7WなのでそれでPC向けのCPUよりスペック高いとは恐るべし。

DSPのHexagonはディープラーニングの推論向けの機能も強化していて、さすがにPC向けのRTX 2050には敵わないけど15 TOPSと結構な性能が出るみたいです。

チップINT8（8ビット整数演算）
Hexagon15 TOPS
GeForce RTX 205048 TOPS

Apple A13

Apple A13 Bionicは所謂Appleシリコンですね。天才プロセッサデザイナーのジム・ケラーがA4,A5をデザインした事でも有名ですね。

ARMv8.3-AベースですがマイクロアーキテクチャはCortexとは完全に別物と思われます。CPUは2.65 GHzで、big.LITTLEを採用し２つの高性能コア（Lightning）と4つの高効率コア（Thunder）の合計６コアのCPUとなります。

Geekbench 5の結果は以下となります。シングルコア性能はSnapdragon 865を超えていますね。Macに搭載された場合はTDPの制約も減るでしょうからどこまで性能が伸びるかも気になります。

CPUマルチコアシングルコア
Apple A13 3400 1330
Intel Core i5-8250U3200750

ref: 【6/14最新】Geekbenchスコア、スマホSoC別総まとめ | telektlist

また、DSPとは別にNPUと呼ばれるDP推論用のチップも積んでいます。でもその割には1 TOPSしか性能がなくてだいぶしょぼく感じるのだけど、整数演算とは別の部分を強化してるかもしれない

チップINT8（8ビット整数演算）
Apple A131 TOPS
GeForce RTX 205048 TOPS

A64FX

富岳に乗ってる富士通製のSoCです。CPUは1.8GHz の48コアです。一気にコア数が増えましたね。

スパコン向けだけあってモバイル向けのCortex等とは根本的にマイクロアーキテクチャが違います。というか、ほぼほぼ京でも使われているSPARC64と同様のようです。

f:id:pascal256:20200628114658p:plain

というのも富士通ではメインフレーム、UNIX サーバ、スーパーコンピュータでマイクロアーキテクチャを共通化させています。UNIX サーバ及び京などのスパコンはSPAC、メインフレームは独自のISAです。別のISAやチップ自体のカスタムはしつつもベースのマイクロアーキテクチャは共通化することで品質の安定とコストダウンをはかっているようです。今回もその戦略にのっとり富岳はARMのISAを使いつつも既存のSPARC64やGS21と同様のマイクロアーキテクチャを採用していることになります。x86系CPUがすでにCISCでも何でもないように現代ではISAは飾りという印象が強いとはいえ、単一のマイクロアーキテクチャで複数のISAをサポートするのはなかなかユニークな戦略だと思います。今後、RISC-Vとかが仮に普及してもそのまま対応できますしね。

f:id:pascal256:20200627234740p:plain ref: 富士通ではメインフレーム、UNIX サーバ、スーパーコンピュータでマイクロアーキテクチャを共通化

なので、A64FXは完全に富士通設計なので他のスパコンでIntelやAMDのCPUを使ってるのとはわけが違います。賛否はあるにしてもそこは大事です。

続いて性能をみていきましょう。

このサイトを見る限りだと富岳の2.7 TFlopsはEPYC 7451が0.9 TFlopsなのでCPUとしては桁違いに速いけど、V100の7.8TFlopsよりは遅いからGPU程ではないって感じです。ただし、A64FXというか富岳の真骨頂は15万8976個のCPU、コア数にして730万コアという意味のわからない数を使った超並列処理です。これは２位のSumitが240万コアのPower 9を使ってるのと比較しても極端に多い数字に見えます。そして他のスパコンと違ってGPUなどのアクセレラレータを使ってないのが最大の特徴になります。そのため、OpenMPなどで普通に並列化できます。SIMDへの最適化はもちろん必要でしょうけど、CUDAなどの特殊なプログラミングはいらないのです。

f:id:pascal256:20200628114801p:plain

これが「プログラミングが簡単」と散々言われてる理由ですね。単純にそれなりに速いCPUがものすごくたくさんあるだけという構成なんです。そしてこの構成を支えるためにTofu-Dという超低遅延のインターコネクトと1TB/sというメモリバンドを実装しています。

また、ベクトル演算のために512bitのSIMDであるScalable Vector Extension (SVE)も実装しています。SVEはArm社と共同開発した標準仕様なのでJEP 338: Vector API (Incubator)とかGCCにも取り込まれているのがポイントです。仮に富士通の独自仕様としていたらこの辺のアップストリームへの取り込みは難しかったかもしれません。

A64FXや富岳についてはいろんなところで情報が出ているので見てるとなかなか楽しいです！

ちなみにA64FXを搭載したマシンですが、実は１ノード400万円くらいから買えるようですw www.hpc.co.jp

スペックシートを見ると空冷で2Uの普通のラックのようなので、メニーコアでメモリ帯域が極太なArmサーバとしても買えるお値段な気はします。Dellですら48コアとか160万円くらいはするわけで。最低４ノードでログインノードも追加でいるみたいなので2000万円くらいは実際かかるにしても考えれるお値段。Javaとか普通に動くみたいだからSparkとかCoherenceとか無駄に入れてみたいw

富士通は国内では数少ない世界レベルのHPC/ハイエンドサーバ向けCPUを開発できる会社なので、今のARMブームと富岳の実績で是非世界展開して欲しいです。メガクラウドに売れればワンチャンなんだけど、商売下手だからな。。。この会社。

AWS Graviton

GravitonはAWSのEC2で利用できるサーバ向けARM CPUです。CortexではなくNeoverse N1というサーバ向けのIPをベースにしています。

v1は低スペック向けとして登場させましたが、Graviton 2は性能を大幅に強化しデータベースのような重たいワークロードも含めてArm v8.2準拠で開発されています。int8/fp16もサポートしているためAI分野のCPUとしてもそれなりに期待が持てます。

f:id:pascal256:20200628115401p:plain

EC2で選べる構成は以下の通りです。

  • 汎用 (M6gおよびM6gd)：仮想CPU数最大64、メモリは最大256GB
  • コンピューティング最適化 (C6gおよびC6gd)：仮想CPU数最大64、メモリは最大128GB
  • メモリ最適化 (R6gおよびR6gd)：仮想CPU数最大64、メモリは最大512GB

最大の特徴はSMT、つまりハイパースレッディングが無いことです。そのためこの64コアは全て物理コアとなります。SMTは完全なコア分離では無いので適切なパフォーマンスが出ないこともあります。それが全て物理でこのコア数というのは中々面白い作りですよね。また、8.2準拠なのでセキュリティ機能のTrustZoneも備えます。これによりデータを暗号化したままメモリに保持することができます。

クラウドで動くことの多いWebアプリケーションなどはCPUを気にした実装をしていることはほぼ無いでしょう。そういったニーズに低消費電力で高性能なARM CPUがいい感じにマッチする訳ですね。

ちなみに一番恐ろしいのは「彼らはGravitonをどこにも出荷していない」ということです。これは自分たちで消費するだけでCPUの開発コストはペイするという意味です。GoogleをはじめとしたメガクラウドがDC内で使うチップを自作しているのは有名な話ですが、その辺を改めて意識させられるエピソードでした。ユーザに提供するI/Fさえ変えなければクラウドベンダーは膨大なコンピュートリソースを好きに組み替えれるので、今後は彼らが市場のプレイヤーになってきます。他の企業の動向も気になりますね。

Ampere Altra

ARMベースのメニーコアのAmpere Altraです。大変ややこしいですがNvidiaの新GPUのAmpereとは何の関係もありません。紛らわしい。。。

www.youtube.com

gigazine.net

AmpereはAltraを世界初のクラウドネイティブプロセッサと呼んでいます。クラウドネイティブプロセッサはクラウドのワークロードに合わせて「予測可能な性能」「ハイパースケール」「低消費電力」を上げています。確かにどれもクラウドでは重要な要件です。

まず予測可能な性能とハイパースケールを実現するためにAltraは3GHzの80コアのCPUです。Gravitonと同じくSMTを使わずに実現しています。AMD EPYCですら64コアなのでヤバイですね⭐︎

Garvition同様にARMv8.2準拠です。AltraもNeoverse N1をベースにしているので基本的な設計は似ているのだと思います。

２基の128bitのSIMD、各コアに1MB大きなL2キャッシュメモリとチップあたり32MBのL3キャッシュ、AI向けに8bit整数と16bit浮動小数の強化、メニーコアに強いインターコネクトのメッシュ構造、セキュリティ機能とサーバ向けとして十分なスペックを持っています。

f:id:pascal256:20200628115119p:plain

そして、このコアではシングルスレッドのみが動作することを強調して説明しています。SMTを使わないのでクラウドや仮想環境で起こりやすいノイジーネイバー問題を極力減らすことができますし、Spectre/Meltdownのようなサイドチャネル攻撃にも強くなります。また、性能面でもクラウドのようなマルチテナンシなワークロードではキャッシュの効果も薄いためHTは性能劣化に繋がるという点を強調しています。また、HTを持たない分IO Waitを減らすためにキャッシュ周りを強化していると思われます。これは確かにクラウド環境を意識したCPUと言えるでしょう。

現段階でもEPYC 7742に匹敵、あるいは部分的には超える性能を発揮します。消費電力周りもいろいろ考えられていて、2020Q4か2020の早くには Ampere Altra Maxという128コアのCPUも予定されています。ヤバイですね⭐︎

Marvell ThunderX3

MarvellはThunderXというARM CPUを作っている会社です。元々、Caviumという会社で開発されていましたがMarvellに買収されました。現在の最新版はThunderX2です。

jp.marvell.com

ThunderX2は既に出荷されているサーバ向けARMなので最も入手しやすいでしょう。クロックは 2.5 GHz から 3.0 GHz。１コア４スレッド、最大32コア搭載可能ということでワンチップで128スレッドが動作します。スレッド数でみれば EPYC 7742と同じですね。発売日はもっと前ですが。ARMv3.1準拠となります。ちなみにHPEの次世代メモリドリブン型コンピュータ、所謂 the Machineのデモ機にも使われています。

また、第三世代としてThunderX3もアナウンスがされました。

www.anandtech.com

これは96コア、384スレッドという他社の追従を許さない圧倒的なメニーコアを実現します。またアーキテクチャバージョンもARMv8.3+になります。サンプル出荷は2020Q4頃と言われています。 現時点ではあまり詳細はあまりありませんが、ThunderX2の方向性を正統進化させたものになるようです。特にSIMDの強化で浮動小数計算が向上していてHPCやAIをある程度見据えた結果かもしれません。

f:id:pascal256:20200628102036p:plain ref: Marvell ThunderX3 Arm Server CPU with 768 Threads Per Node in 2020

ThunderXシリーズの最大の特徴は先ほど紹介した２つのCPUとは異なりNeoverse N1では無いので、SMTが可能なことです。これはむしろNeoverse E1に近い構成です。

ハイパースレッディングのメリットはI/O待ちで発生するストールと呼ばれる空き時間を削減することです。見かけ上の数を増やして待ち時間でパイプラインの空いてるところを埋めてコアの効率性を高めることが基本的な目的になります。

ThunderXでは現在のワークロードはI/Oヘビーのものが多くCPU律速になることは少ないのでHTを４つ持つことで性能を上げるという戦略をとっています。クラウドネイティブなアプリケーションは小さなワークロードの集合なのでCPU性能を上げるより数をこなせることがスループットの向上になるというコンセプトです。

これはNeoverse N1を選択した先の２つのCPUが述べるようにマルチてナンシーのワークロードではセキュリティや性能の面で不利になるケースもあります。なので、ThunderXは単純にIaaSの基盤というよりはある程度上で動くワークロードが占有される大規模アプリケーション、例えばHPCやビックデータ処理、あるいはSDN/NFVなどのネットワーク基盤をターゲットにしてるのでは無いかと予想されます。

ちなみに2020/06のTop500にはA64FX以外では唯一のノミネートとなります。

Astra - Apollo 70, Marvell ThunderX2 ARM CN9975-2000 28C 2GHz, 4xEDR Infiniband | TOP500

HPEにより開発されたAstraは1.8 PFlopsと上位陣に比べると100倍以上性能が低く見えますが、それでも244位と真ん中くらいの性能は維持しています。この辺りのレンジのHPCは構成要素がサーバとも近いので、立ち位置としては悪く無いのでは無いかと思います。

Opteron(K12)

Opteron(K12)はAMDの次世代ARM CPU(2017年当時)です。2017年には出る予定でしたが未だ姿を見たものはいません。

既に、Opteron A1100としてサーバ向けチップは持っていますが、これはCortex-A57をカスタマイズしたものです。K12はマイクロアーキテクチャを刷新すると言われておりRyzenやEPCYにも利用されているZenアーキテクチャが使われる予定だったという噂です。

つまり、x86とARMのISAで同じマイクロアーキテクチャを使う見込みだったわけですね。実現していれば富士通の戦略とも似て居てとても面白いと思います。

歴史の結果としてはRyzenとそのサーバブランドであるEPYCが馬鹿売れしたので、リソースの選択と集中の観点からもK12は無くなってしまったようです。他のARMチップとはマイクロアーキテクチャが大きく異なる可能性があったので、ちょっと残念ですが、また構想が復活してくれる事を祈ります。

ARMの今後とサーバ向け需要

ARMはスマホ市場は既に制しており、ここには大きな成長は無いと言われています。そのため、サーバ市場やHPC市場、あるいはノートパソコンやPCに可能性を見出しています。

歴史に的にこの挑戦は何度かされましたが、結果としては大きな成功は得られていません。ノートパソコンもChromebookやNetbookで多少の市場はあるもののChromebookですらハイエンドはIntel CPUです。

ただ、ソフトウェアスタックの進化やクラウドの推進によりCPU ISAの価値は大きく変わりました。いまはItaniumが出た時代とは違います。AWSという巨大市場で性能の高いサーバ向けARMがサポートされた事も大きなターニングポイントです。Macのアップルシリコンや実はこっそり出てるSnapdragon対応のWindowsマシンがハイエンドでもARMという事を後押ししてくれます。富岳のスパコンランキング世界一という実績も低スペックへの懸念を払拭してくれるでしょう。

というわけで、今はかつて無いほど流れは来ているので、このままPC及びサーバ向けの市場に広がるかが今後の分水嶺になるかと思います。

今後、サーバ用途にも少なからず入ってくればARMの未来も明るいですが、RISC-VやオープンソースとなったMIPSも控えています。x86からARMに切り替える事ができたらば、その他のCPUに切り替えることも出来てしまうので今後がどうなっていくか本当に楽しみです。特に富士通のA64FXは日本発のCPUということもあるし、スペックは高そうに見えるのでHPC以外にも売れてくれないかなーと個人的には興味津々です。

まとめ

ARMがスパコン市場でもPC市場でもIntelの牙城を崩しつつあるのはは本当にすごい事だと思います。特に富岳が１位を取れたのが嬉しくて勢いで記事をまとめて見たのですが、結構調べながら書く事が多くて思いの外時間を使ってしまいました。結果的にARMの勉強になったので良かったです。

ちなみに、組み込みからスパコンまで使われてるARMアーキテクチャですが、他にも同じように広範囲に使われてるCPUアーキテクチャはあるでしょうか？ 実はあるんです。それはx86とMIPSとPowerです。有名どころって大体そうなんですよね。みんな同じアーキテクチャでどこまで行けるかという勝負になるので、シェアの大小はあっっても実績だけは少なからずあったりします。

それではHappy Hacking!

参考:

IPAのデータサイエンティスト スキルチェックリストを読んでみたらとても良かった

はじめに

Twitterにも呟きましたが、IPAのITSS+にあるデータサイエンティスト スキルチェックリストを読んでみたら思いの外よかったので紹介記事を書いてみます。

なお、私自身はデータサイエンティストでもデータエンジニアでも特に無いので中の人から見たら現実と相違してるとかはあるかも。

何が良いの？

そもそもこのチェックリストの何を私がそんなに称賛してるかなのですが、みなさん「データサイエンティスト」ってどんな職種だと思いますか？

AIを使いこなして会社の課題を解決する人ですか？　データを分析してダッシュボードにする人ですか？　データを集計したりビックデータ処理基盤を作る人ですか？　あるいはアルゴリズムの研究者ですか？

たぶん、どれも正解です。今の所データサイエンティストはAI/ML/BIに関わる全てを含んで使われることが多いと感じるので、実際の定義はお「そう思うならそうだろ、おまんなかではな」状態です。

そこが曖昧なせいで、周りにもデータサイエンティストになりたいとか雇いたいと言う話もあり、それが叶ったのも見たことがあるのですが求める実際のスキルや働き方が違い不幸になった結果も知っています。

なので、自分が話すときにはせめてアナリスト(ビジネス分析)なのかサイエンティスト(アルゴリズム系)なのかエンジニア(基盤系)なのかは分けて話してましたがオレオレ定義なので定義から説明が必要なことも当然しばしば。

で、たまたまこう言うのあるよと言われて見つけたのがITSS+のデータサイエンティスト スキルチェックリストです。

このチェックシートの良いところは図のようにデータサイエンティストの領域をフェーズ分けして可視化した上で、チェックシートではデータサイエンス力、データエンジニアリング力、ビジネス力 を大項目としてカテゴライズしていることです。

f:id:pascal256:20200524163645p:plain ref: ITSS＋/「データサイエンス領域」 タスク構造図（中分類）

これによってフワッとしてた「データサイエンティスト」の人物像を明確にし、どのフェーズを動かす人間が必要でそれにはどのスキルセットが必要かがクリアになります。

スキルレベル判定基準

スキルセットは以下のような方法で評価していくようです。判定方法は各項目を何%満たしてるかでチェックするようなので機械的で良いですね。各領域に求められる詳細な説明もPDFにはきちんと載ってますので要参照。

  1. Senior Data Scientist（業界を代表するレベル）
  2. Full Data Scientist　 （棟梁レベル）　
  3. Associate Data Scientist（独り立ちレベル）
  4. Assistant Data Scientist （見習いレベル）

スキルカテゴリ一覧

データスキルチェックリスト自体はこちらにありますが、PDFにあるカテゴリの一覧だけ参考に転載しておきます。 チェックリストは膨大なので読むの大変ですが、そもそもどんなこと書いてあるかはこちらのカテゴリ一覧で雰囲気掴めるかと。

カテゴリ ID サプカテゴリ 項目数
データサイエンンス力 1 基礎数学 24
2 予測 23
3 検定/判断 7
4 グルービング 12
5 性質・関係性の把握 15
6 サンプリング 5
7 データ加工 15
8 データ可視化 38
9 分析プロセス 4
10 データの理解・検証 23
11 意咲合いの抽出、洞察 4
12 機械学習技法ー 39
13 時系列分析 9
14 言語処理 16
15 画像・動画処理 10
16 音声/音楽処理 6
17 パターン発見 3
18 グラフィカルモデル 4
19 シミュレーション/データ同化 5
20 最適化 9
デークサイエンスカ項目数 271
データエンジニア力 1 環境構 28
2 デーク収集 18
3 データ構造 11
4 データ蓄積 18
5 データ加工 14
6 データ共有 15
7 プログラミング 24
8 ITセキュリティ 16
データエンジニア力項目数 144
ビジネスカ 1 行動規範 15
2 契約・権利保護 9
3 論理的思考
4 着想・デザイン 7
5 課題の定義 17
3 データ入手 3
7 ビジネス観点のデータ理解 6
8 分析評価 3
9 事業への実装 7
10 活動マネジメント 30
ビジネスカ項目数 113
スキル項目数合計 52S

使い方

個人的にはまず自社が必要としているデータサイエンティストのスキルを自分たち自身が理解するために利用することが第一でしょう。時間と予算が無限にあるならば全てを100%満たせる超人を揃えることも夢では無いかもしれませんが、時間と予算には限りがあるので大抵は夢です。

なので、そもそもどう言うスキルセットの人間が必要なのか？ どのタイプのスキルは社内人材で転用できそうなのか？　どのスキルは外部から新規雇用をするのか？　どのスキルは外注するのか？　など人事/採用的には考える必要がありますよね。

特に「最初の一人目」は薄くても良いので全領域、特にビジネス力が必要です。プラットフォームが「あれば」データが分析できる人間も、エンジニアリングだけができる人間も最初の一人目としては厳しくて、それらが見よう見まねで良いからできてビジネス側と会話してソリューションに落とし込める人間が必要です。もちろん、最初からチームを組んで分担できればなお良いですね。

だいたい不幸になるケースは最初の一人目にそもそも自社にデータ分析基盤が無いのにサイエンティストを雇うとか、データエンジニアだけ雇って基盤は作ったけどこのあとどうしよう？ となるパターンです。こういったフレームワークを活用すればそのような不幸なミスマッチを避けやすくなります。

こうして採用戦略/育成戦略を立てやすくなるのが企業側のメリットですね。

もちろん、被雇用者側にもメリットはあって自分のスキルを可視化する事でどこを伸ばしていくのか、どこを強みとして押していくのかを整理してキャリアパスを作りやすくなります。

こう言ったみんなで共通の認識を作るという点に関してはIPAのような公の機関が出してる「標準」あるいは業界団体やベンダー/コンサルが作ったフレームワークが役立ちます。

まとめ

「標準」と聞くとやっぱりプロセスが重いとか古臭いとかで軽視しがちな所もありますが、IPAのITSSにしろ共通フレームワークにしろカスタマイズするにしても軸として採用しとくと色々便利だったりはします。

特に、スキル分類とかは自社や自分自身で組み上げたオレオレ定義を使うよりは、ある程度大きな団体が作り普及した標準ないしはデファクトスタンダートを採用する事でスキルの可視化やコンバートがしやすくなり評価や採用/転職に活用しやすくなるので積極的に使いたいですよね。

とはいえ、ITSSv3 個人的にはちょっとだけ古いとやはり思うのでITSS+に書かかれてる内容やDEVOPS, クラウドインフラ, スマホアプリ開発などある程度トレンドを反映したv4をそろそろ作ってくれないかなと期待する今日この頃です。

それではHappy Hacking!

参考

Microsoft Build 2020に参加してきた

勉強会

実は去年に引き続き、なのですがMicrosoft Build 2020に参加してきました。 と言っても今年はコロナの影響でオンライン開催。

f:id:pascal256:20200521153350p:plain f:id:pascal256:20200521153313p:plain f:id:pascal256:20200521153210p:plain

初の大きなオンラインイベントということもあり、48時間耐久レースということもあり、なかなか楽しめました。とりあえず自分のツイート+αをまとめてみました。 togetter.com

今回は大手のオンライカンファレンスという事でTeamsやSkypeを駆使ししたセッションになってるのが印象的でした。MSだからZoomではないのですw

Hanselmanとゆかいな仲間たちのデベロッパーキーノートは内容ももちろんですがWFHのネタがいっぱい散りばめられてて面白かったですね。キーノートの最中に子供が映り込んだり、自分をバーチャル背景に写してこっそり休憩したりw

キーノートに関しては下記のブログが爆速でまとめられています。

blog.azure.moe

個人的にはWSL2が思った以上にマイクロソフトの中で基本的な開発ツールチェインとして組み込まれたことですね。Visual Studioとかともきっちり統合されています。

あと、Windows Terminalの正式リリースやパッケージマネージャであるwingetも大きいですよね。最近気になってるPowerAppの話も聞けてよかったです。

Daprを今までIstio的なものと思ってたのですが、それとも少し違いそうなので少し触ってみたいとも思いました。

JavaやGCPがメインなのであまりMicrosoft製品をガッツリ使うことは少ないのですが、やはりこういうセッションを聞くと楽しくなりますねー。情報盛り沢山でBuildは良い。。。

コロナの影響下でみんな大変ですが、こうしてカンファレンスにオンラインでも参加しやすくなったのはメリットですね。次はGCPのNext OnAir2020かな。

それではHappy Hacking!

参考:

DockerでCucumberのQuickstart環境を作ってみた

ruby test tdd

はじめに

BDDなe2eテストと言えばやはりCucumberですよね。

Gherkinを使って自然言語のようにテストケースが書け、具体的なステップをRubyやJavaで書けるので非常に便利です。

今回、久方ぶりにCucumberを使う必要がありそうなので便利そうな設定をいくつか入れてDocker化しておきました。これでRubyとかが入ってない環境でも問題なく利用できます。

今回実施してる設定は以下の通り

  • ChromeのHeadlessモードを使ったテスト
  • デバッグ用にオプションで指定したらChromeをGUIモードで起動するように設定
  • テストに失敗したら自動的にスクリーンショットをとってテストレポートに含めるように設定
  • Dockerコマンドのラッパースクリプトとしてqcmbコマンドの作成

以下のGitHubリポジトリに置いてあるのでCloneすれば使えます。Chromeを使ってるのでJSやCSSを実際と違う形で解釈したりレンダリングしないので安心感がありますよね。

github.com

使い方

テストの実行

とりあえずcucumberを実行するなら以下のコマンド。featuresディレクトリ配下のテストを実行.

qcmdは単にDockerのラッパーコマンドで実際はdocker run -it --rm -vpwd:/usr/src/app koduki/cucumber cucumberを実行しています。

$ ./qcmb

標準出力ではなくHTMLでレポートが欲しい時は下記のようにCucumberのコマンドを実行。出力先はreportを前提にいくつかの設定がされているので注意。

$ ./qcmb --format html --out report/index.html

テストが失敗した時のスクリーンショットも上記のreportディレクトリに出力されます。

ディレクトリを削除したい時はcleanを実行

$ ./qcmb clean

GUI mode で起動

CI/CDで利用することを考えるとヘッドレスモードがベストなのですが、たまにデバッグでGUIモードでChromeを立ち上げたい事もあります。

DockerはCLIベースの環境ではありますが、LinuxなのでX11をホスト側に飛ばすのは簡単にできます。

Macでの準備

MacにX11とProxyをインストールします。

$ brew install socat
$ brew cask install xquartz

Xquartzを起動してXteam を xquartz上で開きます。

open -a XQuartz

パーミッションを許可してProxyをXteam上で起動します。

$ xhost + 
$ socat TCP-LISTEN:6000,reuseaddr,fork UNIX-CLIENT:/tmp/.X11-unix/X0

qcmbコマンドの--Xheadless=falseオプションを指定して起動します。スクリプトの中で環境変数DISPLAYにホストマシンのIPアドレスなどを連携しています。

$ qcmb --Xheadless=false

設定の解説

support/env.rb

Docker内だとChromeを実行しようとするとDevToolsActivePort file doesn't existが出ます。そのため--no-sandbox を有効にする必要があります。 また、環境変数に応じてHEADLESSモードとGUIモードのそれぞれが選べるようにしています。

require 'capybara/cucumber'
require 'webdrivers'

Capybara.register_driver :docker_chrome_headless do |app|
  browser_options = ::Selenium::WebDriver::Chrome::Options.new
  browser_options.args << '--headless'
  browser_options.args << '--no-sandbox'
  browser_options.args << '--disable-gpu'
  browser_options.args << '--window-size=1920,1080'
  Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    options: browser_options
  )
end

Capybara.register_driver :docker_chrome do |app|
  browser_options = ::Selenium::WebDriver::Chrome::Options.new
  browser_options.args << '--no-sandbox'
  browser_options.args << '--disable-gpu'
  browser_options.args << '--window-size=1920,1080'
  Capybara::Selenium::Driver.new(
    app,
    browser: :chrome,
    options: browser_options
  )
end

def driver
  is_no_headless = ENV["CHROME_NO_HEADLESS"]
  if is_no_headless then :docker_chrome else :docker_chrome_headless end 
end

Capybara.configure do |config|
  config.default_driver    = driver()
  config.javascript_driver = driver()

  config.app               = nil   
  config.run_server        = false
end

support/screenshot.rb

Cucumberのテストが失敗したときに自動でスクリーンショットをとってテストレポートに埋め込むようにしています。

そもそもsupport配下にあるRubyスクリプトは名前に関係なく読み込まれます。これを利用してこの中にフックポイントであるAfterを追加してシナリオ終了後の動作を記述します。 あとは見た通りですがシナリオが失敗したときに、スクリーンショットをとってレポートに埋め込んでいます。

After do |scenario| 
    if scenario.failed? 
        path = "report/#{scenario.__id__}.html"
        page.driver.browser.save_screenshot(path)
        embed(path, "image/png")
    end 
end%

例: テストレポートとスクリーンショット

f:id:pascal256:20200507092702p:plain

まとめ

かなり久しぶりのCucumberだったので結構調べながら作りました。

Cucumberは10年経ってもやはり現役で多少は競合はあるものの圧倒的なシェアは流石ですね。Gherkinは仕様記述言語とまでは言えないもののログインとかの動作の意味が厳密に定義されるので自動テストをしなくてすら有用な文法だと思います。この手のツールを使ってテストケースと実際の自動テストの実行の解離が小さくなることがやはり良いですよね。

それではHappy Hacking!

参考リンク

メインフレーム、無停止サーバ、クラウドにおける信頼性

java architecture ポエム ft server

「メインフレームの異常処理」という記事が話題になってましたがとても面白かったです。 qiita.com

せっかくなので自分が知ってる範囲で各システムの信頼性における考え方を書いてみました。特にシステムが死んでも仕掛かり中のプロセスが正常完了する事を「無停止システム」としてフォーカスしています。 詳しいわけじゃないからあまり詳しくは話せないので、指摘とか頂けると嬉しいです

メインフレーム

  • ホスト機/汎用機とも。国内の富士通とか日立はIBMアーキテクチャをベースにしている。独自進化部分もあるけど。NECとかユニシスはまた別アーキテクチャ。
  • 金融や行政系を中心に現在もたくさん利用されている
  • Fail Softに基づいたハードレベルの冗長化や障害時の切り離し
  • 単独マシンで信頼性を実現。ハードウェアレベルのクラスタ機能もあるのでさらに複数マシンを使ってさらに信頼性を上げることも可能
  • ハードウェアのエラー時の処理をハンドリングする仕組みを用意している
  • 逆に言えばアプリケーションエンジニアがハードウェア障害を意識する必要がある
  • z Systemなんかは現代でも最高スペックのマシン。DockerとかLinuxを動かすことも実はできる
  • 単独メーカで全てを製造しているのでシステム全体で一貫したセキュリティモデル/信頼性モデルが構築できるのは魅力

HPE NonStopサーバ

  • Tandem)とも。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
  • Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え
  • 複数マシンを束ねてシステムの信頼性を実現。(少なくとも現代では)ソフトウェアが中心の信頼性
  • プロセスペアという仕組みを使いメインのプロセスをサブプロセスで監視し問題があれば別サーバで動かす
  • CPUは非同期なので性能は出しやすい
  • OSは独自。旧来からのGuardian環境だけではなく、POSIX風のOSS(Open System Services)も使えてJavaとかKVSも動く
  • Java言語ライブラリやJavaEEなどの内部実装をプロセスペアを発展させたTMF やTS/MPで書き換えてより高速/高信頼な実装を実現している
  • 文化的にはOSからパッケージ、アプリケーションまでプロセスペアやTS/MPを活用して無停止性をキープする事を強く意識している
  • 専用ハードウェアを必要としていたが、現在はソフトウェアベースになっておりx86はもちろんVMware上でも同等の信頼性で動作する

Stratus FT Server

  • Strutsじゃないよ。ストラタス。銀行のATM、証券売買、クレジットカード処理と言ったメインフレーム以上の無停止性が要求される金融トランザクションを中心に利用
  • NEC ftServerもあるけど違いは良く知らない
  • Fault Tolerantに基づいたハードレベルの冗長化や障害時の自動切り替え。
  • 複数マシンを束ねてシステムの信頼性を実現。ハードウェアが中心の信頼性
  • ロックステップ処理と呼ばれるCPUレベルで同期しながら処理を実行するので片方が死んでも処理を継続できる
  • もちろんHWの交換はシステムを止めずに実施が可能。
  • OSはVOS(Virtual Operation System)。Windows／Red Hat Enterprise Linuxなどをサポートしている。VOSとかだとPL/1とかCOBOLで開発
  • 専用ハードウェアだが、汎用OSも動くのは魅力的なポイント

オープン系: クラスタ

  • ここではOSレベルのクラスタシステム. 今でもx86系で冗長構成を組む一般的な方法の一つ
  • Fail Overを基本としたマシンレベルの冗長化や障害時の切り替え
  • 複数マシンを束ねてシステムの信頼性を実現
  • アクティブ/スタンバイを基本として障害時にシステムを待機系に切り替える。ただしFTサーバとは違い分オーダーの時間がかかり実行中の処理もエラーになる
  • OSはUnix/Linux/Windowsなどなど。
  • システム構成もシンプルで費用も安いが原理的に無停止稼働ができない

オープン系: 負荷分散(シェアードナッシング)

  • ここではロードバランサに繋がった負荷分散のシステム。Webサーバを中心に一般的
  • システム全体でFault Tolerant/Fail Softを目指すマシン単位の冗長化
  • 複数マシンを束ねてシステムの信頼性を実現
  • アクティブ/アクティブ構成なのでサーバ障害時には対象システムを切り離すだけで良いので運用が非常に楽
  • WebやAPサーバなどステートレスなサーバでは無停止が実現できるが、DBなどステートフルなシステムには冗長性の観点では単純適用できない

クラウド/仮想環境: Live Migration

  • クラウドインフラやVMwareで実施されるHypberviosrレベルの信頼性確保技術。クラウドを支える技術として裏で使われてる
  • Hypberviosrを抽象化しているのでハードウェアレベルの個々の故障を見えなくするマシンレベルの冗長化
  • 複数マシンを束ねてシステムの信頼性を実現
  • 例えばGCPの場合は稼働中にゲストOSのメモリコピーを行いVMの停止を極小にすることでアプリレイヤーからは遅延に見える程度の無停止性を実現している
  • 信頼性の責務をOSより下のHWとOSより上のアプリケーションで明確に分離できるのが特徴

ソフトウェア: Jakarata EE/EJB

  • OSではなくミドルウェアレベルの信頼性。
  • 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
  • 複数マシンを束ねてシステムの信頼性を実現
  • 基本的にはEJBでの信頼性確保技術としてはフェイルオーバーとリトライがある
  • フェイルオーバーはエラー時に透過的に別のサーバで実行される。ただしDBなどトランザクションは対応していない
  • トランザクション処理はロールバックされるのでリトライを実行することでシステム全体としての無停止性を確保できる
  • ただし、実際のアプリ実装ではシステム側でのリトライは運用課題も多いので素直にユーザにエラーを返すケースも多い。システム間接続だと場合による。
  • EJBに代わり現在主流のCDIには同等機能はないがMicroProfileのFault Toleranceでエラー時の処理を記述するフレームワークが追加される
  • Weblogicなどはデプロイや障害時のフェイルオーバを含めてミドルウェアレベルの無停止を標榜しているが、最近はJavaEEで頑張らずシステム全体の無停止の枠組みにパーツとして組み込むことが主流

ソフトウェア: Oracle RAC

  • OSではなくミドルウェアレベルの信頼性。OracleのRAC(Real Application Cluster)を使った信頼性機能。
  • DBシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
  • 複数マシンを束ねてシステムの信頼性を実現
  • RACはシェアードエヴリシングなので障害時にマシンを切り離しても透過的に利用できる
  • 特にTransparent Application FailoverはSQL実行中のサーバにて障害が発生した場合、SQL文を他のサーバへフェイルオーバー（リカバリ）を実施
  • Oracle DBの専用機能なので適用範囲が限定されるがDBとしての無停止を実現している

ソフトウェア: Erlang/OTP

  • OSではなく言語レベルの信頼性。類似の仕組みをAkkaなどはミドルウェア/ライブラリレベルで実現している
  • 分散アプリケーションを実装しシステムとしてのFault Tolerantを目指すマシンレベルの冗長化
  • 複数マシンを束ねてシステムの信頼性を実現
  • let it crashと呼ばれる思想に代表される適切に落として素早く復旧させる信頼性確保の方法
  • Supervisorがプロセスを監視し、問題があったら自動でフェイイルオーバーやリカバリを行う
  • 個人的にはNonStopのプロセスペアと少し思想が近い気がする
  • 分散システム全体として無停止を担保するが利用できる言語には少し制約がある

ソフトウェア: Cloudで良くありそうなMSAや非同期キューをベースとした無停止デザイン

  • アーキテクチャーなんだけど具体的な名前を思いつかないのでフワッとした表題に。名前はまだない？
  • クラウドでは無停止システムってどう考えて作るっけ？ と思って良く使われそうな考え方を書いておく
  • OSや各アプリケーションではなく分散システム上のサービス単位でFail Soft/Fault Tolerantを実現
  • 複数マシンを束ねてシステムの信頼性を実現だが、マシン単位はもはやあまり気にしてない
  • 基本的には止まることを前提に回復性に極振りしたデザイン
  • MSAにより各サービスの障害時の影響範囲の局所化とリカバリ速度の向上と、可能な限りシェアードナッシングによるアクティブ・アクティブの冗長構成が基本
  • 可能な限り非同期/結果生合成を受け入れて、とりあえず信頼性の高いキューに一時保存。失敗したらロールバックとリトライをすることで無停止性を担保
  • データはインフラとしては事実上無限のリソースがある事を前提に複数のストレージに同時に書き込むと言うのが基本
  • OSとかのレベルの無停止性を実質期待してないのが最大の特徴。体系化/フレームワーク化はもう少し蓄積が必要な印象
  • Kafkaだったりk8sだったりIstioだったりなんとかDBだったり実装は決定版がある分けでもまだない
  • まだ過渡期だけど思想的にはサービスメッシュなどを活用してアプリケーションからはいくつかの制約を満たせば透過的に無停止性が担保されるはず

まとめ

他にもたくさんある気はするのですが、メインフレーム/無停止サーバ/オープン系/クラウドにおける信頼性確保の基本的な戦略を書いてみました。

意図的にハードウェアレベル、OSレベル、システムレベル、ソフトウェアレベルをまとめて書きましたが実際はこれを混在させてシステム全体の信頼性を組み上げます。銀の弾丸はないと思うのでそれぞれを把握して適切なものを選ぶのが大事ですね。

特にNonStopやftServerといった高可用性サーバは存在自体がマイナーですが、アーキテクチャ的には結構面白いので誰かの詳細な解説があると教えて欲しいです。

クラウドでももちろん無停止サービスは実現できますが、高可用性サーバを使うと商用パッケージからOSライブラリに至るまで全て無停止を意識しているので無停止サービスの実現が容易というのも魅力ではありますね。 これはNode.jsは実行基盤だけではなくライブラリなども非同期を強く意識しているので非同期プログラミングがしやすい、という話に似ています。

この辺はクラウドでのノウハウやパッケージが揃ってくれば変わってくると思いますが、現状はクラウドでは「アーキテクトが自分たちのシステムに最適な仕組みを個別に考えて実装」というラインです。もちろんk8sをはじめ良いミドルウェアやCloud環境自体の機能も強化されてきてますけど「レールに乗って作れば無停止になる」というところにはまだ至れてません。今後のノウハウ蓄積が大事ですね。

あと、最後に書いてる「Cloudの無停止でありそうなデザイン」は具体的な名前があれば誰か教えてください。MSAは大部分はカバーするにしても無停止システムデザインという意味では要素にすぎない気がするし。

それではHappy Hacking!

参考リンク

テックポエム:010 - 祝！ JDK14 リリース

java techpoem

www.youtube.com

スライドはこちら: テックポエム 祝！ JDK14 リリース - Speaker Deck

今回はRecord型やパターンマッチングなど目玉機能といえるものが多く入ったリリースでした。

一方で、それらはまだpreview版で通常は利用できないので、今後に向けての中間リリースとしての側面も強いです。

これは、JavaがChromeなどと同じく機能の有無ではなく定期的にリリースをするRapid Releasesのモデルを採用したことによる効果だと思います。

preview版がproductionになったりpreviewで新機能を早くから試せたり、特に今回リリースではないShenandoah GC向けの改修が地味に入ってたりするのは象徴的だなー、と個人的には思います。

TLDR;

  • JDK14が無事にリリース。LTSの17に向けての下準備多数
  • RecordやPattern Matching、Text Blocks がプレビューながら追加
  • JFR Stream API, Switch式など新APIや構文も追加
  • ZGCのWin/Macサポート、CMSの廃止などGC周りの改修もあり
  • 詳しくはきしださんのJava 14新機能まとめ参照 https://qiita.com/nowokay/items/ec85d97a7cecaaac8123
  • 一応言っておくけど、今もJavaは無料で使えます