トーク

普段Java以外の言語で開発しているプログラマが、今年発売された書籍「プロになるJava」で再勉強した話をします。

一年の内、数ヶ月レガシーなJavaシステムを触る程度のプログラマが、書籍を通してモダンなJavaに触れ、簡単なWebシステムを作成してみた感想をお話します。
また、他の言語での開発経験があるプログラマが、Javaに入門/再入門する際のポイントについても取り上げます。

不動産業界の業務システム開発プロジェクトにおいて、
複数のSpring Batchアプリケーションと、Spring BootのWebアプリケーションからなるシステムの開発を行っています。

本セッションでは、これらのアプリケーションのCI/CDをCircleCiで構築するにあたって、
DBマイグレーションからテストデータ投入までをパイプラインに組み込むなど、考慮した点や工夫した点などを紹介できればと思います。
AWS環境でSpring Bootアプリケーションを構築する際の参考事例としてお聞きいただければと思います。

GitHub Actions は GitHub が提供している CI/CD ツールです。
担当しているサービスは Java/Spring Boot で構築しており、サービス公開してから3年が経ったが、
・テスト環境へのデプロイが手動のため、メンバー作業の属人化や定常的な運用コストが発生していた
・静的解析ツール未導入のため、レビューやテストなど人の手作業で品質を上げていた
など改善の余地がありました。

本セッションでは、
Git 未経験者（私）が上記の課題に対して、
GitHub Actions を用いた「ビルド・デプロイの自動化」や「静的解析ツール・コードフォーマッターの適用と自動化」を実装し、
そこで得られた成果や苦労、学び・気づきについてお話します。

内容の概要としては、
・前提の説明
・実施前後の効果と成果
・実装方法
・GitHub Actions のテストの方法・レビュー観点
・実施後の運用課題
を予定しております。

マイクロサービスにおいては一部のサービスが障害を起こして応答が不能になったり、ネットワーク的にリクエストが到達不能になることがあります。その際に無対策だと連鎖的に各サービスがダウンし、アーキテクチャー全体が機能不全に陥ってしまいます。

対策としてはサーキットブレーカーの適用が挙げられます。サーキットブレーカーは局所的な障害がアーキテクチャー全体に波及しないように障害を分離する機構です。しかし、自力で実装するのはコストが高いのが難点です。

Resilience4jはJavaでフォールトトレランスを実現するためのライブラリです。数多くの機能を備えますが、その中の一つにサーキットブレーカーがあります。本セッションでは以下内容について解説したいと思います。

・Resilience4jの概要
・Resilience4jを利用したサーキットブレーカーの実現方法の解説
・Resilience4jを利用したリトライの実現方法の解説
・弊社サービスである「楽楽勤怠」での適用例

FizzBuzz問題のコードを通してJava 1.7からJava 17までの新しい機能や文法をおさらいしていきます。
※FizzBuzz問題：1から順に、3の倍数の場合は「Fizz」、5の倍数の場合は「Buzz」、3の倍数かつ5の倍数の場合は「Fizz Buzz」、それ以外の場合は数字をそのまま出力するプログラミング問題。

【このセッションの目的・ゴール】
・Javaの新しい機能を少しでも知ってもらう
・Javaの新しいバージョンに興味を持ってもらう

【対象】
・Java 8以降の新機能についてざっくり知りたい方
・最近Javaを書いていない方

【注意点】
・各新機能についての解説は概要にとどまり詳細な使い方の説明はしません
・if, forなど基本的な構文は理解している人を想定

【詳細】
Java 9以降リリースサイクルが変更となり、半年に一度の高い頻度で新機能がリリースされるようになりました。
リリースサイクルの変更に伴い、新しい機能を追っていくコストは少し大きくなっています。
そこで本セッションでは、FizzBuzz問題という簡易なコードを通し、よく使われそうな新機能周りを横断的にお話していきます。
まずJava 7で書かれたFizzBuzzコードを示し、バージョンを少しずつ上げて、よく使いそうな新機能で一部を書き換えたものを次々提示していきます。
どのバージョンで何ができるようになったか、大まかにわかるようになり、Javaの進化を体感できるようなセッションになると思います。

【紹介予定の機能など】
・StreamAPI
・メソッド参照
・Optional
・var（ローカル変数の型推論）
・テキストブロック
・Switch拡張（Switch式、パターンマッチ）
・Sealed Classes

【自己紹介】
所属：虎の穴ラボ株式会社
役割：エンジニアリングマネージャー、テックリード
主に書いている言語：Ruby, Java, Kotlin

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