JavaOne2017参加報告 Microservices topic & approach #jjug

Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved.
2017年10月21日
ヤフー株式会社森下大介
JavaOne2017参加報告
Microservices topic & approach

自己紹介
• 名前：森下大介(42)
• 所属：ヤフー株式会社 MSC開発本部
• 経歴：
• SIer系2社で14年、ヤフーで6年
• C, C++, Java, PHPなどで開発
• Javaは前職でSwingとJavaEEを利用しての開発、
現在は主にSpringを利用してサーバーサイドの開発に従事

ゴール
• 行ってみてわかったことを共有
• Microservices関連の各セッションで
語られていた内容を通して、
今何が議論されているのかを伝える

アジェンダ
• 行ってわかったこと
• 参加したセッションの紹介
• Microservicesの話題や取り組み事例
• MicroProfile
• 考察
• まとめ

Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved. Copyright © 2017 Yahoo Japan Corporation. All Rights Reserved.
行ってわかったこと

ホテルは早めに予約する
• 10月のサンフランシスコは宿泊料が高い（普
段の２〜３倍）
• 会場近くのホテルは埋まっていくし直前に予
約すると特に高い
• 疲れたらすぐ戻れるように会場近くにとれる
のがベスト

なるべく疲れないようにする
• 時差あり、慣れない環境で５日間・朝から晩
まで続くので体力勝負
• 体調がきつければセッションを一部スキップ
する、ホテルに戻るなど
• 10月の現地はわりと寒いので服装に注意
• 移動はUberがとても楽だった

参加セッションは必ず事前登録する
• 登録済みの人が優先でセッション会場
に入れる（入り口でチェックされる）
• 未登録の場合は別の列に並び、もし椅
子が空いてたら入れてもらえる

技術系・資料ありセッションはわかりやすい
• 技術系のお話や、資料に沿って解説し
てくれると英語でもわかりやすい
• 資料がタイトル程度だったりパネル
ディスカッション系はむずかしかっ
た・・・

参加した
セッションの紹介

Microservices系
• 12 Factors for Cloud Success [CON5598]
• http://bit.ly/12factors-app
• A Competitive Food Retail Architecture with Microservices
[CON2486]
• A Practical Guide to Cloud-Native Java Apps and Continuous
Delivery [TUT6632]
• Architecting for Failure: Why Are Distributed Systems Hard?
[CON3636]
• Choreographing Microservices Through Messaging [CON1662]

Microservices系
• Java PaaS: Then, Now, and Next [CON5945]
• Microservices Data Patterns: CQRS and Event Sourcing [CON7610]
• https://istio.io/
• http://microservices.io/patterns/data/event-sourcing.html
• http://microservices.io/patterns/data/cqrs.html
• Need-to-Know Patterns for Building Microservices [CON4382]
• Spotify: Java Microservices at Scale [CON7953]
• https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
• https://github.com/spotify/apollo
• Successful Java EE DevOps in the Cloud [CON7627]
• Three Microservice Patterns to Tear Down Your Monoliths [CON4277]

MicroProfile系
• Cloud-Native Java Done Right [CON1896]
• https://openliberty.io/
• https://projects.eclipse.org/projects/technology.microprofile
• http://microprofile.io/blog/2017/10/eclipse-microprofile-1.2-available
• Java EE 8 on a Diet with Payara Micro 5 [CON3013]
• https://www.payara.fish/payara_micro
• Panel: Accelerating the Adoption of Java EE 8 with MicroProfile
[CON1825]

Microservicesの
話題や取り組み事例

モノリスからMicroservicesへ
自社の事例を話してくれたREWE Group、Spotify、Deramworks
全てで共通していたこと
• まずモノリスがあった
• サービスの拡大によりスケールする必要に迫られた
• そのためにMicroservicesアーキテクチャになっていった
• 組織と文化もそれにあわせて変えていった
• 数年かけて継続している長い取り組み、旅は続いている

組織・文化
SpotifyやREME Digitalの発表では組
織・文化についてかなり強調。
システムのスケールに合わせて組織もス
ケールするにはどうするか？

組織・文化
コンウェイの法則
• 組織のコミュニケーション構造がシステムに反映される
• 逆法則も（Service間コミュニケーションの形が組織に反映）
Autonomy（自主・自立性）を何より重視
• Squad（分隊）と呼ぶチームにメンバーが所属
• 非セントラライズ／自主的な活動／独立リリース／オーナーシップ
• 独立リリース可能な状態を維持する、破壊的な変更はちゃんと手続きを経る
• 同期型APIならエンドポイントの移行期間を設ける
• 非同期型を同期型よりも推奨
参考：https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Microservicesをとりまく仕組みについて
仕組み補足
CI/CD 小さく・頻繁に本番環境にデリバリする
Container, Orchestration Docker, Kubernetesが常に登場していた。このコンテナオーケスト
レーションに関係するサービスなどもよく紹介されていた
Service Registry Serviceのホスト名・ポート番号を名前で抽象化
Asynchronous 可能な限り同期より非同期を選びたい
Fault Tolerant 一部のエラーで全体が影響を受けないように分離する
Monitoring 現状がどうなっているかを可視化する
Tracing どこにボトルネックがあるか追跡できるようにする
これらが必ずセットで語られている。スケーラビリティや、
Microservicesが本質的に抱える難しさをサポートする仕組み。

議論の対象の変化
FrameworkやLibraryは自前で開発したり
ラッピングするものではない
• それらはもうConsumeするである
• 議論の対象は「Service」という部品をどう協調
動作させるか？になっている

同期 < 非同期
要件が許すなら同期よりも非同期のほうがより良い
• 非同期で複数処理を同時実行してパフォーマンス向上
• Service同士の協調動作を同期呼び出しでつないで行
なった場合にエラー処理が難しい
• 同期呼び出しではインタフェース変更に弱くなりやすい

データ処理パターン
Eventual Consistency（結果整合性）
Microservicesでは各Serviceが利用するデータストアを
各々で選ぶため、複数の異なるデータストア間で内容を同
期させたい場面がでてくる。
異なるデータストア間の内容の整合性が「Eventual
Consistency」でもよい場合は非同期連携で各データスト
アに反映すればよいため、相性が良い。

Event sourcing
参考：http://microservices.io/patterns/data/event-sourcing.html
Event Sourcingは、「データストアをイベント記録に使う」と
いう説明がされてましたが、insert(追記)のみ行いupdate(更新)
はしないやりかた。ひたすらログをとっていくような形。

CQRS
参考：http://microservices.io/patterns/data/cqrs.html
では実際に特定エンティティの現在の状態をどのように知るかというと、前述のEventual
Consistencyの考え方で非同期連携で別の参照用データストア（別RDBMS、KVS、インメモリ
キャッシュ等）にその更新ログの内容でアップデートをかけて、参照はそちらに対して行う。
この登録（Command）と問い合わせ（Query）の責任を分離することを
「Command Query Responsibility Segregation」と呼ぶ。
• 登録処理を行うService：データストアに登録更新系の操作を行う
• 参照処理を行うService：現在のデータの状態を反映している別データストアに問い合わせる

Eventual Consistency, Event sourcing, CQRS
Event sourcing
Command Query
Service A Service B
Send Event
(Eventual Consistency)
Store A Store B

MicroProfile

MicroProfile 1.2
機能概要
Config 1.1で追加。microprofile-config.propertiesによる設定値管理
Fault Tolerance Circuit Breakerなど
Health Check ヘルスチェック
Metrics アプリケーションのメトリクス取得
JWT Propagation セキュリティ関連
JavaOne開催期間中の10/3にMicroProfile 1.2が公開され、紹介されていた。
http://microprofile.io/blog/2017/10/eclipse-microprofile-1.2-available
JavaEEの機能であるCDI・JAX-RS・JSON-Pの他に、以下のような
Eclipse MicroProfileとしてのMicroservices向けな新機能が盛り込まれている

MicroProfileの今後
バージョン
MicroProfile 1.3 トレーシングの機能などが追加される模様
MicroProfile 2.0 JAX-RS, CDI, JSON-PがJavaEE8相当になり、JSON-Bが追加
JavaEE自体もEclipse Foundationがリードしていく
(プロジェクト名：EE4J(Eclipse Enterprise for Java))ことになり、JavaEEと
MicroProfileが両方共Eclipse Foundationのプロジェクトとなったことから、今後
これらがどのように連携してくのかというのも話題として出てました。
なお、MicroProfile1.3と2.0が既に予定されている。

複数ServiceにまたがったTransaction
Long Running Action
「Strong Consistency」はスケールしないことから、今日では「Weak／Relaxed
Consistency」が受け入れられ始めているということで、MicroProfileの「Long
Running Actions」という仕様（ドラフト）について紹介されていた。
とはいえ、MicroProfileとしてもまだ先の話のようなので、もしこのモデルに賛同でき
ない人はぜひ参加して協力してねとのこと。
分散トランザクションをサポートするTransactionManagerとして、Narayana.ioが紹
介されていた。JavaEEのアプリケーション・サーバー「WildFly」の一部だが単独で
も利用できる模様。

考察

必要性を考える
Microservicesの形を今とっている企業は、
「スケーラビリティ」と「リリーススピードや回数アップ」の
必要性に迫られて不断の努力をつづけた結果としてそうなって
いる。
どこでも最初はスモールスタートでモノリスから始まってて、
決して最初からMicroservicesを想定したわけではない。
今の自分達はその必要性に迫れているか？を考えたほうがいい。

組織や文化とセットで考える
Microservicesは、担当が個々のServiceをオーナシップや自立
性をもって独立して開発してデプロイ出来る組織・文化があって
こそで、そもそもそうなることが目的。
システムの形が仮にMicroservicesになったとしても、そこに人
間側の組織や文化が対応していないとやる意味はない。

トレードオフも考える
Microservicesは何の引き換えも無しにただメリットを享受でき
るものではない。よく言われる「銀の弾丸は無い」ということ。
周辺の多岐に渡るエコシステムを把握して使いこなし、
組織や文化にまで踏み込んでいかないと本当の効果がでない。
どこまでの複雑性や変化を受け入れられるかを考えながら、
どれだけ分割を行なっていくかを考えたい。
※個人的には、ほど良い分散システムをめざしたい。
（特に複数Service間Transactionとかやりだすとつらそうな気がします)

まとめ

まとめ
• 行くなら特にホテルを早めに予約しよう
• Microservicesは自立と引き換えに複雑性を抱える。
必要性とトレードオフをしっかり考えよう
• Microservicesの話題の注目ポイント
• システム自体の話はコードレベルからService自体を部品とみなしての組み
合わせ方や周辺エコシステムに移っている
• システムの構造を反映した組織や文化にまで踏み込んだ話になっている
• JavaEEとMicroProfileはどちらもEclipse Foundationのプロジェクトに。
MicroProfile専用の機能が定義され始めている

EOP

JavaOne2017参加報告 Microservices topic & approach #jjug

More Related Content

What's hot

Viewers also liked

Similar to JavaOne2017参加報告 Microservices topic & approach #jjug

More from Yahoo!デベロッパーネットワーク

JavaOne2017参加報告 Microservices topic & approach #jjug