JJUG CCC 2019 Fallに参加しました

Report このエントリーをはてなブックマークに追加

2019年11月23日（土）に開催されたJJUG CCC 2019 Fallに行ってきました。
自分の学び・メモと所感をまとめておきます。

Spring Cloud AWSをクラウドエンジニアがいじってみた

インフラエンジニアの視点で語ってくれるのは新しい発見があるかも、と思って参加。
メモできなかった部分も多く、資料が公開されていないのがちょっと残念。不正確なメモもあるかもしれません。

学び、メモ

  • Spring Cloud AWSとは
    • Spring Cloud xxxの中で、AWSに特化したモジュールの集合体
    • AWSのSDK固有の表現を可能な限り排除し、Springベースに統合したもの
  • 登壇者の印象
    • リソースの使い捨て、疎結合、単一障害点などはうまくできる
    • スケーラビリティなどの面ではイマイチ（メモしきれなかった…）
  • 設定
    • 認証情報はインスタンスプロファイルから自動的にとってきてくれる
  • セッション情報を外部化する理由
    • スティッキーセッションにすると、オートスケールしても負荷が分散されにくい
    • EC2の可用性は99%なので、結構落ちる。そのため外部にセッション情報をもたせたい
  • RDS
    • プロパティを設定しておくと、@TransactionalのreadOnly=trueをリードレプリカに振り分けできる
  • SQS
    • Bean定義をするだけで、メッセージの送信元を定義することができる
    • @SqsListenerを付けるだけで簡単にメッセージを読み出すメソッドが定義可能
    • ただしメッセージの複数受信と複数送信ができないため、頻繁な送受信が行われるシステムには不向き
  • Lambda
    • RDSと相性が悪い。
      • ステートレスで、コネクションプールの実装が難しい
      • 内部でスケールアウトしてしまうと、最大同時接続数が制御できない
    • RDSとの相性問題を緩和するには？
      • DynamoDBを使用するなど

所感

やはりインフラエンジニアの視点だと関心事が異なるので、新しい発見が多く得られたので良かったです。

JavaはそもそもLambdaとの相性が悪い印象を持っていましたが、Spring Cloud AWSでも解決されないんだなぁと感じました。
少なくとも、タイムリーにリクエストを捌くことが求められるAPIには向かないと思っています。

@Transactional(readOnly=true)で自動的にリードレプリカに振り分けられるのは一見「便利そうだなー」と感じましたが、現実では使い所がかなり限定されそうだと感じました。（質疑応答でも指摘されていました）
実際にはSELECT（＝readOnly）の処理とINSERT/UPDATE（readOnlyでない）の処理が混在することが多いというのはその通りだと思いますし、 @Transactionalを多層にしてreadOnlyがtrueとfalseのものが混在した場合、どんな動作をするのか気になります。

AWSにロックインされるのはそれなりにリスクなので、プロダクションへの採用は結構ハードルが高いかも、と感じました。
逆に、個人でちょっと遊んでみるにはかなりハードルが低そうです。

開け！ドメイン駆動設計の扉

DDDについてのステップアップセッション。GMOインターネットの成瀬さんの発表。
残念ながら、発表資料は諸事情につき公開できないそうです。

学び、メモ

  • ドメイン駆動設計のモチベーション
    • 仕様書はありますか？→ないよ
    • 詳しい人はいますか？→いないよ
    • そしてエンジニアは旅に出る（去る or コードを探す旅）
  • ドメイン駆動設計が今評価されている理由
    • 数年前にスピードが重視された。その結果、今苦労していませんか？
    • DDDは最初のスピードを捨てて、長期的に変化に耐えられるようにしている。その効果が発揮・理解されてきている
  • その他
    • ドメイン駆動設計のゴールとは、ソフトウェアの利用者とコードが地続きになること
    • ドメインとコードを行ったり来たりすることが重要
    • リファクタリングをする勇気を持つことも必要
      • ドメイン駆動設計についての書籍を、来年2月に出版予定とのこと

所感

DDDの考え方について、改めて知ることができて良い機会でした。
「当たり前のことを当たり前に実践する」という言葉がありましたが、これは普段心に留めている言葉なのでとても心に響きました。

Spring Update 2019

Pivotalジャパンの槙さんの発表。資料はこちら。

学び、メモ

  • Spring Framework 5.2
    • RSocketサポート
      • RSocket: HTTPの代わりとして、マイクロサービス間での双方向通信を想定したプロトコル
    • WebMvc.fn
    • proxy
      • これまではサブクラスのプロキシを実行時に作成していた
        • 実行速度とメモリへ影響あり、final使用不可、GraalVMのnativeイメージ作成に制約あり
      • Proxyを使わないようにできるが、動きが変わるので注意
        • fooのなかに入っているものが、コンテナに入っているものと別物になるから
        • IntelliJ IDEAなら叱ってくれるので検知しやすい
  • Spring Boot 2.2
    • バナーが8bitカラーに対応
    • Lazy Initializationを有効にして、全部まとめて起動時間を短縮できるようになった。
    • デフォルトがJUnit5になった
    • Health機能が改善された
    • GraalVMで動かすための設定が減っている。
      • 今後は設定が自動生成できるようになっていく予定。ただしサードパーティライブラリは別途、要対応
      • GraalVMは起動速度とメモリ消費量「だけ」に特化したマーケティングなので注意
      • デモのビルドでは、3分くらい時間がかかっていた
    • 今後6ヶ月毎のマイナーバージョンアップを行うようになった。サポートポリシーはこれまで通り、1年以上の予定

所感

Springは、新しい技術についてもどんどん取り込んでいくことが強く実感できたセッションでした。 内容的に結構ついていけなかった部分もあり、キャッチアップ不足かもと反省。
あとはSpring開発コミュニティのバナーに対する愛は伝わってきました。 バナーの機能は結構いろいろあるなーと思っていましたが、ここまで改良の歴史があるとは…。

Java界隈では最近GraalVMが持て囃されている印象ですが、「起動速度やメモリ消費量以外はむしろJITに劣る」ということを知れたのは一番の収穫でした。

こわくないソースコードリーディング生活

Acroquest Technologyの進藤さんの発表。資料はこちら。

学び、メモ

  • 重要なのは、ソースコードの読み方を知ること
  • ソースコードを読むときはIDEがオススメ
    • マウスオーバーでの変数・引数の確認や、型へのジャンプができる
    • ソースコードを取得して開いたりすることもできる
  • ソースコードを読むときのコツ
    • 適度に読み飛ばすことも必要。読み飛ばしていい所を理解できるようにする
    • 読み飛ばす所の区別を付けるためにも、読む目的・目標を設定する
    • まずは広く浅く読む。詳細を見すぎると全体像が見えなくなる
  • スライドの中で例題とされていたOSS
    • Apache Commons
      • Javaの基本的な文法を理解していれば簡単に読めるらしい
    • Commons DBUtils：軽量なRDBアクセスライブラリ
    • Javalin：軽量Webフレームワーク
      • 後でステップカウントしてみた所、テストコードを除くと7600行程度しかない模様
  • SourceTrail
    • 最近OSSで公開されたソースコードエクスプローラ
    • クラスの依存関係や呼び出し階層をグラフィカルに表示できる

所感

個人的には以下のような場面でソースコードを読むことが多い気がします。

  • OSSの公式リファレンスを読んでもよくわからないとき、疑問が浮かんだとき
  • 使い方が分からないとき（テストコードを中心に読む）
  • バグっぽい動きをしたとき

みんな、どんなときにどのくらいソースコードを読むんだろう？と思いながら聞いていましたが、「目的を決めるのが重要」ということは人それぞれなのだろうと思いました。

Commons DBUtilsは存在自体を知らなかったので、意外な収穫でした。会場でも知っている人は少なかったようです。
また、SourceTrailも知りませんでした。これまでIntelliJ IDEAのクラスダイアグラム生成機能を使っていましたが、SourceTrailも一度試してみようと思います。

Serverless時代のJavaについて

AWSの方による発表。 発表資料はこちら。

学び、メモ

  • コールドスタートについての対策
    • 不要なライブラリを減らす
    • プレーンJavaを使う
  • フレームワークを使う場合
    • Micronautを使う
    • GraalVMを使う

所感

残念ながら、個人的にはあまり収穫がありませんでした。強いて挙げるとすれば、LambdaでJavaを使べきでないという確信が強くなったことでしょうか…。
AWSの人の発表なので、ポジショントーク感が強かったです。

コールドスタートが懸念になるのであれば他の言語を使うべき（プレーンJavaにしてまで使う理由が見当たらない）と思いましたし、 GraalVMを採用するにはリスクもコストも大きすぎるように感じられました。
現時点ではGraalVMは容易に使えず、GraalVM⇔JITの互換性が低いように思いますが、これが今後どのくらい改善されるかに注目しています。 最低でも3年はかかりそうな気がしますが、それまではJavaでLambdaを使うのは現実的ではないかなーという結論に至りました。

SwaggerではないOpenAPI Specification 3.0によるAPIサーバー開発

ヤフーの方による発表。 発表資料はこちら。

学び、メモ

  • SwaggerとOpenAPI
    • コミュニティの断絶があり、OpenAPIにforkされた
    • Open APIの方が開発が活発で、コントリビュータが多い
  • 開発規模（資料）
    • 3ヶ月でフルスクラッチ開発したマイクロサービス
    • 自動生成が21660行、自前での実装が17794行。すなわち、54.9%が自動生成
  • Generation Gapパターン
    • 生成コードはリポジトリ管理せず、継承や委譲を使って自分たちのコードを実装する

所感

OpenAPI Specからコードを自動生成する枠組みは知らなかったので、事例として良い勉強になりました。
またGeneration Gapパターンという名前を知ることができたのも良かったです。
この考え方は自力で思いつくかもしれませんが、それを共通言語でやりとりできることも重要なので、大きな収穫でした。

現時点ではまだ採用に見合わないかなーと思いましたが、うまく使いこなせば開発を大きく効率化できそうだと感じました。
この辺りは継続して情報収集したいと思います。

その他、気になって目を通した資料

全体の所感

あくまで個人的な主観をざっくりまとめると、以下のような感じ。

  • Spring Cloud AWS: とりあえず触ってみたい
  • Azure Spring Cloud: ぱっと見良さそう？今後に期待
  • GraalVM: 話題になっているけど、まだまだ先は長そう
  • Lambda, Serverless: Javaとの相性の悪さを再認識
  • OpenAPI 3.0 Specification: コード自動生成、良さそう。今後に期待
  • SourceTrail: 試してみよう

結構テーマが偏っていた気もするけど、いろいろと収穫があったのでよい一日になりました。
発表者の方々、運営者の方々、ありがとうございました！

関連記事


  1. Spring Fest 2019に参加しました
  2. JJUG CCC 2019 Springに参加してきました
  3. アノテーションを活用した影響調査にトライしてみた
  4. Groovyの == 演算子と equals() は厳密に同じではない
  5. DDLを自動生成してJavaと各DBのデータ型を比較してみた
  6. 既存コードへのCheckstyle導入におけるルールの選定
  7. Checkstyleで汎用的に使えそうなルールをピックアップしてみた

comments powered by Disqus