トーク

Javaでは定期的に訪れる脆弱性対応。4半期に1度のペースで Oracle Critical Patch Updates が発表されます。
また依存ライブラリに目を向けると、最近では Spring4Shell など深刻な脆弱性が発表されたことは記憶に新しく、慌ただしい対応を余儀なくされた方もいらっしゃるかと思います。

脆弱性対応のより早い、より安全なリリースを妨げる要因は何があるでしょうか。
・リリースに停止が伴う：事前に顧客周知するなどのリードタイムが発生
・手動テスト：品質担保に時間がかかる。そのため網羅的なテストができず懸念が払拭できない

私達の開発チームでは早く、安全に脆弱性対応ができる状態です。
それは様々なプラクティスが積み重なり、上記のような要因を解消できたのだと考えております。
・無停止リリース
・自動テストの充足（ユニットテスト、E2Eテストなど）
など

本発表ではそれらのプラクティスをお伝えし、みなさまが安心して脆弱性に対応できる一助になればと思います。

DeNAのわたしが所属するチームではJavaアプリケーションをECS on Fargateで運用を始めました。まずはGCアルゴリズムを指定せず動かしてみたところ、Serial GCが選択されていることが発覚。JVMから見えるcpu数を見ると複数のCPUが使えるはずのECSタスクであるにも関わらず1つに見える現象に遭遇しました。

問題の発見から行った調査、原因の解決までJVMの実装も合わせて紹介します。

LINE STORE(https://store.line.me/)という、LINEの各デジタルアイテムを販売するWebアプリケーションを開発しています。
LINE STOREでは、多くの場面でLINE STOREの公式アカウントからユーザにメッセージ配信を行っています。
たとえば、ユーザがスタンプ購入後の購入完了通知やボーナスクレジット付与通知などです。

このメッセージ配信処理を、同期処理からメッセージングマイクロサービスを使った非同期処理に移行し、課題を改善したことを共有したいと思います。
以下のような、よりソフトウェアアーキテクチャの視点で共有します。
・同期処理における課題
ex) メッセージAPI障害時に、メッセージの再送しづらい問題、メッセージAPIのレイトリミットへの対策
・非同期メッセージングサービスの説明と利点。移行するにあたって検討した事項
ex) メッセージAPI障害時の自動リトライ、レイトリミッターの適用、Webアプリケーションとメッセージングサービスのそれぞれの役割の決定
・非同期メッセージングサービスのテクノロジースタック
　ex) Apache Kafka、Decaton(LINEのOSS、Java Job Queue Library)、Spring MVC

kintoneは2011年のリリース以降、開発チームが90名になるまで成長し、コードベースも肥大化を続けてきました。しかし、組織もコードベースもモノリシックなまま成長を続けてきたため、メンバーの認知負荷やコミュニケーションコストの増大などによって、開発体制がスケールしない問題を抱えていました。今後、開発を加速かつスケールさせるために、領域専任のチーム体制への移行に挑戦しています。技術面でも、開発を加速するための改善に取り組むプロジェクトを、エンジニアが起案し、チームを発足して進められるようになりました。JUnit 5へのアップデートや、Joda-TimeからJSR-310 Date and Time APIへの移行、さらにフロントエンドのクラス構文への移行など、多岐に渡る改善プロジェクトが進行しています。組織面と技術面の両輪で開発を加速するための取り組みについてお話しします。

マイクロサービスアーキテクチャの普及とともに、分散トレーシングも広く知られるようになってきました。分散トレーシングの導入を検討されている方も多いのではないでしょうか。
本セッションでは、マイクロサービスアーキテクチャを採用したシステムにおける分散トレーシングの実践例をご紹介します。
マイクロサービスのシステムは処理の複雑さから、ボトルネックやバグの特定が難しく、ログの集約だけではデバッグや監視しきれません。
セッションで取り上げるプロダクトは、リアルタイムな画像処理システムで、高速なレスポンスが求められます。遅延のボトルネックを特定し、早期に改善を図ることが重要でした。そこで、分散トレーシングソリューションのJaegerを利用して効率的かつ早急なボトルネック改善を目指しました。
分散トレーシングソリューション導入の利点や工夫など、ノウハウの一部を共有します。

なんでもかんでも1台のサーバーに入れて巨大なシステムを構築していないでしょうか？
システムが巨大化するとレスポンスタイムの低下や、開発速度の低下等のいくつかの問題が発生するようになります。
Red Hatではアプリケーションを小さく作り複数のサーバーに分割してシステムを構築することを推奨しています。
そうすることで、不必要なレスポンスタイムの低下や開発速度の低下を防ぐことができるようになります。
しかしながら、サーバーを複数台に分割する場合は1台ですべてを作る場合に比べていくつかの注意点が必要になる場合があります。

Red Hat Application FoundationsはJava EEを実装するJBoss EAPやMicroProfileを実装するQuarkusやそのほかのミドルウェア、インテグレーション製品のどれを使っても良いというサブスクリプションになります。
このセッションではRed Hat Application Foundationsに含まれる製品やそのほかのOSSを使用して、どうやってアプリケーションを分割していくのかと、分割する上での注意点について説明します。
Red Hatの製品はすべてがOSSでベースとなるアップストリーム製品(≒github上等でOSSライセンスで公開されているリポジトリ)があります。
Red Hatのサポートが不要な場合はサブスクリプションを購入しなくても使用することができます。
ですので、Red Hatのサブスクリプションを購入したことがない方、購入する予定のない方でも聞くことができます。

すでに巨大なJava EEサーバーで構築されているシステムを抱えている方や、これからシステムを分割していきたい方、1台のサーバーでしか作ったことがない方の知識の助けになると思いますのでぜひご参加ください。

クラウドデータ連携、とくにツール・サービスからの連携には従来のバッチ連携に対してリアルタイム連携のニーズが増えています。
リアルタイム連携で増え続けるSaaS やクラウドDB を扱うために「データアクセス仮想化」がホットです。
rデータアクセス仮想化とは？を実例を引きながら解説します。実際にCData Connect Cloud というツールでSalesforce データやTwitter などのクラウドデータのSQL Server への仮想化についてもデモします。

Apache Maven is an ubiquitous build tool in the Java ecosystem, some even claim it's the defacto standard build tool. Configuring Maven is deceptively simple, after all it's just a matter of writing XML, isn't it? Things look differently when the rubber meets the road. One must know the intricacies of the build lifecycle; how plugins, goals (mojos), and phases come together; rules for dependency resolution; configuration inheritance between parent - child POM files; enhancing the build with profiles; and more. These features may trip you over if the rules that govern them are unclear. We'll present a series of scenarios to test your knowledge on Maven rules. we guarantee you'll leave this session with a few bits of new information and better understanding of the Maven build tool.

機械翻訳：
Apache Mavenは、Javaエコシステムにおいてユビキタスなビルドツールであり、事実上の標準ビルドツールであると主張する人さえいます。Mavenの設定は驚くほど簡単で、XMLを記述するだけです。しかし、実際に使ってみると、状況は一変します。ビルドライフサイクルの複雑さ、プラグイン、ゴール（Mojos）、フェーズの組み合わせ、依存関係の解決ルール、親子POMファイル間の設定継承、プロファイルによるビルドの拡張などを知っておく必要があります。これらの機能を制御するルールが不明確だと、つまずく可能性があります。このセッションでは、Mavenのルールに関する知識を試すために一連のシナリオを提示します。このセッションで、いくつかの新しい情報とMavenビルドツールのより良い理解を得られることを保証します。

Persistence is the soul of modern architecture. It is a way to have a state in the stateless application, mainly in distributed systems such as microservices and cloud age app style.

We handle various persistence sources such as SQL, NoSQL, or even web services. With a considerable amount of options or flavors, how can we have a business away from these details or have a loose couple between the application and the persistence engine?

This presentation will discuss the new trends in the modern persistence model around enterprise architecture.

機械翻訳：
永続性はモダンアーキテクチャの魂である。主にマイクロサービスやクラウド時代のアプリスタイルなどの分散システムにおいて、ステートレスなアプリケーションにステートを持たせるための方法である。

SQLやNoSQL、あるいはWebサービスなど、さまざまな永続化ソースを扱います。このように様々なオプションやフレーバーがある中で、どのようにすればこれらの詳細から離れたビジネスを行うことができるのか、あるいはアプリケーションと永続化エンジンの間に緩やかなカップルを持たせることができるのでしょうか。

本発表では、エンタープライズ・アーキテクチャにまつわる最新の永続化モデルの新しいトレンドについて説明します。

Helidon is a brave, small but powerful opensource framework for writing microservices. And if you need get the maximum performance – making your apps reactive is currently the best way to do it! In this session we will dive deeper and see how to create extremely performant reactive microservices with Helidon “SE” flavour. Since Helidon has its own powerful Reactive Engine, we will learn how to get the most requests served in async operations and Messaging.

But the game changer Project Loom is already here, and Helidon supports it out of the box, we will make a live comparison of what is better – the hard reactive approach, or regular blocking code optimised with Loom! Welcome to the Danger Zone!

機械翻訳：
Helidonは、マイクロサービスを書くための勇敢で小さいが強力なオープンソースフレームワークである。そして、もしあなたが最大のパフォーマンスを得る必要があるなら、アプリをリアクティブにすることは現在それを行うための最良の方法です。このセッションでは、Helidonの「SE」フレーバーを使って、非常にパフォーマンスの高いリアクティブマイクロサービスを作成する方法について、より深く掘り下げて見ていきます。Helidonは独自の強力なReactive Engineを持っているので、非同期処理とメッセージングで最も多くのリクエストを処理する方法を学びます。

しかし、ゲームチェンジャーであるProject Loomはすでに登場し、Helidonはそれを箱から出してサポートしているので、ハードなリアクティブアプローチと、Loomで最適化した通常のブロックコード、どちらが優れているかをライブで比較します。デンジャーゾーンへようこそ

Time-series data, or data being associated with its respective time of occurrence, is everywhere. From the obvious cases, such as metrics, observability, IoT data, all the way to logs, invoicing, or payment records. While storing some of these in relational databases is standard practice, people often reach for specific time-series databases when volume gets high. But imagine if you could have all of them in the same database: PostgreSQL.

Join me for this session to learn more about the different types of time-series data and have a look at the naive, the native, and the scalable approaches to storing it in PostgreSQL. We’ll contrast their usability and performance characteristics and show you why Postgres is the only database you need!

機械翻訳：
時系列データ、つまり発生時刻と関連付けられたデータは、あらゆるところに存在します。測定基準、観測可能なデータ、IoTデータなどの明らかなケースから、ログ、請求書、支払い記録まで、あらゆるものがそうです。これらのデータの一部はリレーショナル・データベースに格納されるのが標準的ですが、量が多くなると特定の時系列データベースにアクセスすることが多くなります。しかし、これらをすべて同じデータベースで管理できるとしたらどうでしょう。PostgreSQLです。

このセッションでは、様々なタイプの時系列データについて学び、PostgreSQLに時系列データを格納するための素朴な、ネイティブな、そしてスケーラブルなアプローチについて見ていきます。それぞれの使い勝手と性能の特徴を比較し、なぜPostgreSQLだけが必要なのかを説明します。