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

Technology