JJUG CCC 2018 Spring に行ってきたメモ
JJUG CCC 2018 Spring
Container技術が流行ってきた昨今の様々な現場の話を聞けて楽しかったです。 幅広い話を聞いてきました
聞いたセッションは下記。
- JavaでWebサービスを作り続けるための戦略と戦術
- Concourse CI入門 ライブ環境構築＆ビルド
- 日本最大級の求人検索エンジン「スタンバイ」を支える技術
- Java10まとめと、どうなるJava11
- JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜
- Spring Boot on Kubernetes : Yahoo! ズバトク事例
- DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
ビズリーチの方の"JavaでWebサービスを作り続けるための戦略と戦術"がかなり参考になりました。
また、ジャストシステムの方の"DDDとクリーンアーキテクチャ"も実践的な事例の話で刺激的でした。
いずれのセッションでも、貴重なノウハウを拝聴できて面白かったです。 登壇者の皆様、ありがとうございました！
以下聞いたセッションのメモ書き
JavaでWebサービスを作り続けるための戦略と戦術
感想
スピーカーの方の熱意が伝わってきた。
開発の理想とそのために何をやってきたのか、という話。
手段としてDockerFileを学んでいくべきだというメッセージも強かった。
まとめ
- 開発環境とは、本番用ではないものすべてのアプリケーションが動く環境を指す
- エンジニアではない人も触れるもの
- 動くソフトウェアを作るためのもの
- 誰かのPCでは動かない、とかはNG
- あるべき姿
- setup.shでミドルウェアが全部入る
- VitrtualBoxがあるかどうか判定→インストール というところから全部一括で行う
- プロジェクトごとに作成する→複数プロジェクトに参画している人では動かせない、ではNG
- 仮想OS on 仮想OS
- docker on VitrtualBox on Mac
- dockerはなぜ利用するか
- 単純に早い
- 未来像として、Container技術に集約されそうな未来がある。
- dockerfileを作成するのはアプリ開発者である→学ぶべき
- ツールの変更
- 目指す先
- PR一つに対してそれ専用の検証環境が一つ自動構築されるのが理想
- 環境の空きを待つことなく、いつでも誰でも、確認したいものについて確認できるようにする
- setup.shでミドルウェアが全部入る
- 老朽化した技術からの脱却
- フロントエンド
- Swaggerすごい。
- 手動・自動テスト
- テストコードに価値はなく,その実行結果を見たあとの行動に価値がある
- PRごとにjenkinsで自動テストが走る
- MRも工夫。誰かがレビューコメントしないとMergeボタンが押せないようになっている
- セキュリティ
- AWSのシークレットOS環境に渡す
- など。
- バージョンアップ
- こまめにバージョンアップするしか無い。
- この脆弱性は関係ない、で対応してないとあとから強烈なバージョンアップを強いられる。
- こまめにバージョンアップするしか無い。
- まとめ
- 誰でも、いつでも、安定的に再現性高めにテストができる世界という理想を目指す
Concourse CI入門 ライブ環境構築＆ビルド
資料
https://backpaper0.github.io/jjug-ccc-2018-spring-concourse/slide/index.html#1
感想
Concource使ってみなきゃ。
jenkinsと比べて書き方のコツさえ掴めばすべてコードベースで管理できて良さげ。
（あとあんま関係ないけどViewも鮮やか。）
まとめ
- アーキテクチャ
- Concource自体がマイクロサービスチック。
- Web,Worker,DBの３つのインスタンスから構成される。
- パイプラインやビルドログはポスグレに保存される
- worker自身はATCからの指示だけで動く、DBは直接見ない
- ので死んでしまっても立ち上げ直せば良い
- pipelineとかjobの構造は資料の図がとてもわかりやすかった
- YAMLのアンカーとエイリアス
- ただ結局、GUI上どのようにJOBが扱われるのかとか、ymlの管理とかは触ってみないとわからなさそう。やろう。
日本最大級の求人検索エンジン「スタンバイ」を支える技術
資料
感想
Elastic SearchのPluginすごい。
やりたいことや運用を楽にするためにどういう構成にするのか、どんなPluginを利用するのか、選択肢が豊富。
まとめ
検索周りの話を中心に。
- スタンバイ:800万件以上の求人情報を収集して、検索できるしくmi
- クローリングなどから収集したデータをElasticSearchに格納
- 利用者はそこから検索する
- 検索のサジェストはログから生成
- Elastic Search
- インデックスのしかけ
- 検索周りのしかけ
- フレーズマッチングとtitleなどマッチ箇所に応じた重み付け
- ワード単体のマッチングによる検索結果の補完
- Elastic SearchのPlugin
- 全体の仕掛けを運用する際の課題と解決
Java10まとめと、どうなるJava11
（このあたりから私の体力が尽きてくる
資料
https://www.slideshare.net/nowokay/java10-and-11
感想
リリースモデルの復習と新規機能について。
Raw Stringの話とStringの新API、Single-Fileでのjava実行、HEISEI問題が興味をそそられる話でした。
対応していかなきゃ。
まとめ
気になったものベースで
- 新リリースモデル
- JDK 10
- var を用いた型推論
- Heap Allocation on Alternative Memory Devices
- JDK 11
- about java support
- End of HEISEI問題
- NewEraという対応の仕方をする模様
- 2019/4には入るかも
- 現在議論中なので積極的に参加していきましょうとのこと
- NewEraという対応の仕方をする模様
- End of HEISEI問題
JavaエンジニアのためのDocker入門 〜 仮想開発・テスト環境構築 〜
感想
そもそもコンテナとはどういう存在なのか、というところから。
docker経験ありnot基礎知識みたいな感じの身なので、参考になった。
まとめ
- Dockerコンテナ
- あたかもサーバのように動いているもの
- コンテナ上には。OSは入っていない。ミドルとアプリだけが入っている
- 追記：ホストのKernelやベースOSの機能を共有しているっぽい
- Docker hubリポジトリ
- イチから書くのは面倒。なのでdocker imageを共有する仕組みがある
- ただし、玉石混交なので信頼できない個人のイメージよりは、公式か、自分で書いて作ったほうが良い。
- 注意すべきこと
- コンテナは基本使い捨て。永続化したい情報とかは乗っけない方が良い。
- bashで入ってなにか作業して整えた→ちゃんとその変更分もdockerFileに記述してやることで、冪等性を確保する。
- Java10のDocker対応
- JVMがDockerで動いていると認識していなかったのが治った
- 今まではホストの設定しかみていなかったっぽい？
- JVMがDockerで動いていると認識していなかったのが治った
Spring Boot on Kubernetes : Yahoo! ズバトク事例
感想
めっちゃくちゃ濃かった。
貴重なノウハウを共有していただけてありがたいです。
まとめ
結構情報が抜け落ちているのであとで資料を見たい
- yahoo!ズバトク
- くじやキャンペーンを掲載するためのプラットフォーム
- 需要のUPに対して運用や改修のコストがかかりすぎていて辛かった
- 現行システムでは限界だったので、k8sを利用して作り直した
- kubernetes
- コンテナのオーケストレーションプラットフォーム
- fail overの管理や異常検知、スケーリング、リクエストの負荷分散など課題の解決に有効そう
- コンテナのオーケストレーションプラットフォーム
- システム移行
- k8sを有効活用するためにtwelve-factor appに沿うように改善。
- ヘルスチェック
- actuatorを利用
- Graceful Shutdown
- Jettyの機能だけではうまく実現できなかった→自前で実装して実現
- ログ出力
- Spring Cloud Sleuth→依存を追加するだけでリクエストで一意なIDを出力。
- 40サービスあるので、こういった仕掛けがないと厳しい。
- ヘルスチェック
- 開発フローの改善
- Git上でオペレーションが簡潔するフロー
- PRがトリガーになって運用が走る構造
- 実働10分程度でデプロイ完了できるように。(もともと数時間
- 大変だったこと
- 社内の連携や考え方のスイッチなど。
- まだ改善の余地あり。
- k8sのデザインパターンなどを踏まえる
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
感想
実践的！DDDやクリーンアーキテクチャをどう組んでいったのか、プラクティスの話は新鮮だったので参考にできればいいなと。
まとめ
- 長いことやってるPJ
- スクラップ＆ビルドしている
- コンセプトはあり、仕様の概要は決まっている
- 諸々の問題
- サーバから全データをダウンロード
- 全コンポーネントがDBと接続
- DBの変更に対してのWEBサーバ影響がでかい
- 解決策としてのDDD
- 設計段階
- 実装前の準備
- 実装してみてわかったこと
- やってみてよかったこととわるかったこと
Java Day Tokyo 2018 に行ってきた話
Oracle Java Day Tokyo 2018
OracleのJavaイベントに参加してきました。
昨年も参加したイベントですが、コンテナを導入していくぜって雰囲気の昨年と比べると、コンテナを実践していくぜ、JVMを改良していくぜといった雰囲気の話が多かった印象です。
私は主にリリースモデルやコンテナ周りのセッションを聞いてました。
概要はこちら
本記事は私のメモ書きと感想です。
keynote
所感
リリースサイクルの話と11に向けて各パラレルで動いているProjectの話が大半だった
昨年との比較としては、昨年はコンテナに注力していくぜ！だったのがコンテナはもう当たり前に使うものだ、みたいな潮流になっていた。
コンテナやサーバーレスといったアーキテクチャの新しい選択肢について、具体的なメリットの説明が加えられるようになっていたので、これからもその流れなんだろうなと。
GCとかフライトレコーダーとかの開発・改善も徐々にオープン化したりして進めているっぽい。
率先してオープンにしていっているのは良い変化なんだろうなと。
フライトレコーダーのデモはeclipseにembedされてた感じのものだったけど、分析結果が明瞭で利用価値がありそうだった。
サーバーレスとかコンテナをサポートするよ！っていうところが強調されてた。特にjava ee。
process上にdocker浮かべてってのも紹介されていたけど、処理を分散、パラレルで実行、は良さそう。
検索部分だけでもこういう仕組み仕込むと面白いかもしれない。
[TEC-2] Container Nativeアプリケーション開発とアーキテクチャの勘所
MicroServicesにおける課題を解決するためのContainer、みたいな筋が明確で、一番参考になったかもしれない。
資料
http://otndnld.oracle.co.jp/ondemand/javaday2018/TEC-2
まとめると
- MicroServicesには課題がいっぱい
- 課題を解決する一つの手段がConainerとそのオーケストレーションツールを利用した方法。Kubernatesがその実装の一つ。
- 活かせない例
- 一つのコンテナに多くの機能を詰め込みすぎるケース
- Container自体の品質が悪いケース
- 活かせる例
- 低レイヤーの共通処理は別コンテナに切り出す
- initContainerパターン
- 様々なデザインパターン
- 活かせない例
- Oracle Cloudのツールを使うと比較的容易に実践できる。
- [Oracle COnteiner Pipelines Werker[(http://www.wercker.com/)
[TEC-3] Running Java applications on Docker: practical tips and valuable insights
dockerでjavaを動かす際のメモリやCPU周りについてのTIPSについて。
資料
http://otndnld.oracle.co.jp/ondemand/javaday2018/TEC-3
まとめ
- ３つの問題
- アプリから実際に使えるメモリが見えない
- アプリから実際に使えるCPUが見えない
- docker上だとエントロピーに基づくランダム数を出すことが出来ない
- 解決策
- デバッグとインテグレーションテスト
- 基本的にはmavenを活用すれば大丈夫そう。
- サンプル
[JSE-3] JDKの新しいリリースモデル
OpenJDKとOracle JDKのリリースモデルについて。
独特なサイクルになるので注意すべきって話と、11LTSになるといろいろ話が変わるという話。
資料
http://otndnld.oracle.co.jp/ondemand/javaday2018/JSE-3
まとめ
- 機能か、リリースか
- 大規模な更新を待つとどうしてもリリースが不定期になる
- 小規模な機能開発でもリリースしていきたい
- クラウド環境に適応しているか
- マイクロサービスを意識したモデルに変更したい
- コンテナイメージも配布を始めた。
- フィーチャーリリース
- 年６回のリリースで、3月9月に機能リリース
- SE 8 の商用機能の利用が可能に
- LTSリリース
- 3年ごとのフィーチャーリリースのバージョンに設定
- 利用可能になる商用機能
- ZGC
- Flight Recorder
- 他。
- JDKに含まれなくなるものも一部ある
- Java Plugin から移行のお願い
- 切実な雰囲気。
- JRE
- 基本的には配布するアプリケーションベンダー側でアップデートしてほしい雰囲気
- リリースに対する要望
- より速く計画的に完成した機能をリリースする
- よりシンプルかつ再配布可能なバイナリのライセンス体系
- Oracleのバイナリ配布サイクル
- これからの開発について
[JSE-5] Java SE 10、そしてJava SE 11への移行ガイド
現場目線での移行のポイント解説
資料
http://otndnld.oracle.co.jp/ondemand/javaday2018/JSE-5
まとめ
- CHECK1 Deprecated
- Deprecated;forRemovalなもの 絶対消えるので修正しないといけない
- NO MORE Applet No More Java Web Star
- CHECK2 Prohibit Access to JDK Internal APIs
- sun~,com.sun~など・・・ -
- 一応、command lineからは --add-exportしてあげると公開できるので、普通に動かせるようにはなる。
- CHECK3 Reflection
- illegal rflctive access operation has occuredと出る
- --add-opens すると一応実行できる
- CHECK4 Remove Java EE Module
- packageを複数のモジュールに紐付けられなくなるので、ちゃんとjava eeの方の本流の方に戻していかないと使えなくなってしまう
- JAXBとかJAXWS → 11では使えない
- --add-modulesで追加してあげると、一応動く。追加でモジュールを使えるようにする。
- つまり標準のモジュールパスを拡張してあげればよい
- ただし11では完全になくなる
- つまり標準のモジュールパスを拡張してあげればよい
- CHECK5 Module Defines* Dependency Disclosure scope
- jarファイルのメタ情報としてモジュールの情報を付与できる
- この辺ちょっとうろ覚え...
- CHECK6 Module path class path
- Class Pathの世界とModule Pathの世界を両立させる必要がある
- ライブラリの依存関係的に、モジュールパスだけではうまくいかない
- 一方で、class pathというのだけではうまくいかない
- 直接アクセスするか、間接的にアクセスするのか、でmodule,non moduleを分けて考える
- --add-moduleds ALL-MODULE-PATHといった呪文で解決してやる。
- Class Pathの世界とModule Pathの世界を両立させる必要がある
- CHECK7 JavaFXがない
- CHECK8 Incubator Module
- 名前が変わる場合がある。
- 例えばIncubator 配下のモジュールがリネームされることがある。
- ModuleInfo とかで注意しとかないとまずい
- 名前が変わる場合がある。
[BN-3] 50分で最新技術学習の基礎を身に付ける
爆速で技術用語を総ざらいする感じ。
資料
http://otndnld.oracle.co.jp/ondemand/javaday2018/BN-3
まとめ
- マイクロサービスについてそれっぽいことが言えるようになる。
- 大体資料の通り。お見事。
総括的な感想
ざっくり言えば、Containerを利用してマイクロサービスを実践していく流れと、それによって要請されるJavaの方向性との両方に気を配っていくべきだと感じた。
dockerやkubernatesなどサポートする環境が整ってきたこともあり、そろそろ自分でも触ってみることが大事かなと。
書籍やセッションを聞くと、わかった気にはなるし、[BN-3]セッションの内容のように、それっぽいことは言えるようにはなる。
ただその一方で、それを形にしてどう？と言えないと現場で使えるとは言えないんだろうなと。
そんな感じ！！
