BuriKaigi2019に参加してきた

今年も BuriKaigi がありました。

toyama-eng.connpass.com

私は、Java側のセッションを聞きました。

下にそれぞれのセッションの個人メモを貼ってますが、印象に残ったところとして、

  • JDKの有償ライセンスは思ったより安い?
  • 当たり前だけど、Kubernetesが向かないプロジェクトもある。
  • Kubernetesの要素って、なんであんなにジェネリックな名前なんだろ。。?
  • Loomはまだまだ?使えなさそうだけど、これが出て、ライブラリもアップデートされたら勝手に性能が上がりそう。
  • スレッドとかロックとか、知らない・覚えてないことがいっぱい。。。
  • GraalVMはいろいろヤバそう。(いい意味で)
  • RESTのゆるふわさをどうにかするために、ODataとかOpenAPIとかGraphQLが出てきたと考えれば、理解しやすい感じ。
  • ODataは初めて聞いたけど、表形式のデータを提供するためには、考えることが減らせそう?(APIパラメータとか)

って感じでした。

懇親会やその後の2次会、次の日の朝など、いつもは話せない人たちだったり、観測範囲の違う人たち(.NET側)と話せてよかったです。

Oracle Code One 2018 の概要 と JDKライセンスモデルの変更(最新版)

https://www.slideshare.net/itakashi/jdk-burikaigi-2019

Oracle Code One 2018

Java One から、 Code One になった。

JDK

JDK 11 ドキュメントの日本語版が公開。 (英語以外では、日本語のみ)

1/15のアップデートで、Java8の最終アップデート。 次からは、新しいライセンスになる?

去年、世界中でやったアンケートで、8割ぐらいJava 8。 LTSで行こうと思ってる人が3割ぐらい。 都度考えようと思ってる人も3割ぐらい。 Open JDKを使っていく人は8%。少なめ。

今までのリリース Open JDKのコミュニティが、コード公開までしてる。バイナリは作ってない。 JavaFXとかを追加して、Oracleがバイナリとして提供。BCL(企業内でのコピーなどはできる。)ライセンス。

いままでのアップデートリリース Oracleがアップデートリリースを開発。年4回。 セキュリティやバグフィックス、たまに機能追加もあった。 Open JDKのアップデートリリースは、同期されてなかった。

JDK11以降のリリース Open JDKがコードを作るのは変わりなし。 Oracle Open JDKとして、オラクルが無償提供。6ヶ月ごとに出てくる。(オラクルによるアップデートのリリース) Oracle JDKは有償。商用ライセンス or OTNLA for Oracle Java SE。バージョン固定のニーズに特化。開発・テスト・試作・デモ用途には無償。

Oracleでは、リポジトリが2つある。OpenJDKとOracle JDKOracle JDKの方は、11, 17などのタイミングで、ブランチが切られ、個別にアップデートされていく。

メジャーバージョンアップは3月と9月。 アップデートは1, 4, 7, 10月。

リリース情報は、今までどおりOpenJDKのサイトで確認できる。 Deprecatedになったら、最短1年で削除される可能性がある。Release Notesを確認する。 for removable = trueになったら、ほんとに1年で消える。

Java8の無償サポートは続くが、今のところはNon-corporateのみの制限になっている。 有償サポートであれば、25年3月まで伸ばせる。 Java6を使ってるのは、いいかげんまずい。 有償サポートの契約では、バージョンの固定が無い。8のサポートだけ欲しくても、11とかも利用できる。

1プロセッサで年間36,000円。 プロセッサの数え方は、チップベンダーなどにも依存する。

Oracle Code One 2018 Java関連のフィードバック

(スライドは見当たらず)

一昨年まではJava Oneだったので、Javaだけだった。 Oracle Code Oneになって、Java以外もある。(とはいえ、Javaがメイン)

セッションのスライドや動画は、公開されている。 ハンズオン資料も公開されている。

OracleJava関連のいろいろなものをオープン化していく。

Javaでコンテナやるってのは向いている。 管理ツールなども、いままでのものが使いやすい。 ただし、ランタイムが大きい。普通にやると、500Mのイメージとかになる。 Jigsawとかでうまくできると、100Mを切れる場合がある。 slimというイメージを使うと、ベースイメージの容量を減らせる。 Alpine linuxにポートするのがProject Portola。(12に入る?)

Java on Kubernetes 全部デモ

(スライド無し)

Podは、いくつかのコンテナをまとめたもの。

IstioというProxyサーバ?を置くことで、DI/AOP的にできる。

Podの冗長構成をするために、"Deployment"という仕組みがある。 アプリのローリングアップデートとかも仕組み化されている。 サービスの死活監視とかもしてくれる。(ちゃんと書けば)

Deploymentを管理するためには、yamlで書く必要がある。

kubectlで、コンテナに対してport forwardしたり、コマンドを実行できたり。 /bin/sh を実行させることで、ログインすることもできる。

Deploymentで管理されているものは、基本的にprivate IPしかふられていない。(外部からアクセスできない) "Service"(Load balancer的なもの)を定義することで、外部からアクセスできる。(ただし、基本的にはprivate ID) typeを変えることで、パブリックにできる。(ただし、あんまり使わない)

Ingressを経由するのが、正しい外部公開の仕方。

https://github.com/yoshioterada/k8s-Azure-Container-Service-AKS--on-Azure から勉強するのがよい。3章が特に重要。

kubeは、万能ではない。 マイクロサービスとか、新機能をどんどん追加していくとかは向く。 長く安定的に動かす基幹システムとかは、あまり向かない。(学習コストの方が高くつく)

Project Loom - 軽量スレッドと限定継続

https://speakerdeck.com/skrb/project-loom-qing-liang-suretudotoxian-ding-ji-sok

Loom自体はまだ固まってない。

Thread 糸 Fiber 繊維 Loom 織機

並列・並行は難しい。そもそも、それぞれの単語が難しい。 スレッドセーフでもスケールしない。 CPUが遊んでる。使い切れない。ロックがとれないとか、IOのウェイトとか。 待ち状態になったら、スイッチするべき。

wait - notifyAllのペアで使う。 java.util.concurrent では、そのあたりをうまく実行してくれている。

Context switchは遅い・重い。中断するだけで、大量のメモリを必要とする。 ->OSによらず、JVMが管理するスレッドが必要 => Fiberの導入。

中断/再開の仕組み -> (限定)継続と言っていいのでは? Fiber = Continuation + Scheduling(ForkJoinPoolが使える)

java.lang.Continuation run / yield / Runnableでのタスク記述

計算処理だけであれば、Parallel streamとかを使えばいい。 IO待ちとかに、Fiberが使える。

java.lang.Fiber スレッドはそのままで、その上のタスクだけが切り替わる。 Runnable / Callableでタスク定義 schedule park / unpark(駐車するという意味)ただし、ユーザは使わない。 CompletableFutureに変換して、待ち合わせる。 たとえば、LockSupportがparkメソッドを利用している。 それ以外にも、Thread, java.util.concurrent, I/OのNetworkingやPipeが対応してる。(Fileは未実装)

制限 ネイティブスタック・モニタからはyeildできない wait/notifyAllではなく、ReentrantLockなどを利用したら使える。

Fiberは、おおよそThreadの代わりになる。 ThreadLocalやThread.currentThreadが使えない。

LinuxMacはサポートされてるけど、Windowsがまだ。

おれの書いたPHPがこんなに速いわけがない(PHP7.3比3倍)

(資料見当たらず)

GraalVM : Oracleが開発してるJVMをベースにした多言語環境 CE版と商用EEがある。(本番で使う段階ではなさそう。。?)

Graal と GraalVMは別物。

Graal Javaで書かれたJITコンパイラ 現状Client(C1)とServer(C2)があるが、C2部分を置き換えるもの。 C2は秘伝のタレ化(新機能の追加を出来る人がいない)してるので、それを置き換えたい。

Truffle AST処理エンジン 動的言語のためのLLVMと言える。

Sulong LLVM bitcode -> Truffle ASTに変換出来る SwiftはLLVMが改造されてる?ので動かない。

Polyglot Truffleをベースにした多言語環境 言語をまたがった最適化が可能。

Microsoft AzureではじめるJava開発

https://slides.com/hiroyuki_onaka/java-on-azure-burikaigi/#/

Azure x Javaの選択肢 AKS / Virtual Machines / App Service / Functions(まだプレビュー)

今回はApp Serviceの話。

warが動く。wildflyも動く。

App Serviceにも、WindowsLinux、コンテナのバリエーションがある。

特に理由がなければWindowsでいいが、最新のもの使いたければContainer。 windowsならfreeプランで試すことも出来る。

Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)

https://www.slideshare.net/sugimomoto/java-api-rest-vs-graphql-vs-odata-vs-openapi-swagger

API management市場が2022年で3000億円規模になる予想。 (Apigeeとか。)

APIエコシステム」が重要性を増していく。 freeとかmoneyforwardがAPI提供したり。 提供者側の文脈が多いけど、利用者が必要。

RESTは原則が定義されているだけで、規約などは無い。 デシリアライズ先のクラス定義が面倒。 リクエストのパラメータなどは、ドキュメントを見る必要がある。

Swagger (OpenAPI) RESTをうまく記述するためのフレーム。 (主に)yamlで記述する。 Codeの生成や、モックの作成が出来る。

OData RESTの上にプロトコルを乗せたイメージ。 表形式のデータの取扱をしやすくした。(SQLのイメージに近い) 使えるURLパラメータが全て決まっている。 Metadata Endpointサポート。 サービスごとにAPIの仕様を学ぶ必要が無い(統一されている)

GraphQL Web API用のクエリ言語 1つの画面で複数のリソースの情報を表示する必要があるので、画面側でリクエストしたい情報を組み立てる必要が出てきた。