Download as PDF, PPTX
![API リクエスト例
https://github.com/m3dev/octoparts/blob/develop/models/src/main/
scala/com/m3/octoparts/model/
{
"requestMeta": {"id": “req-12345", "userId": “sera"},
"requests": [{"partId": “beer", "params": [{"key": “beerId”, "value": "1"}]}]
}
{
"responseMeta": {"id": “req-12345", "processTime": 26},
"responses": [{"partId": “beer", "id": “beer”, “contents”: “{”name”: “yonayona”}”,
“statusCode”: 200, “mimeType”: “application/json”, ”cookies”: [], "cacheControl":
{"noStore": false, "noCache": false}, "warnings": [], "errors": [], "retrievedFromCache":
false}]
}
リクエスト例
レスポンス例](https://image.slidesharecdn.com/jissenscala-150221002105-conversion-gate02/75/Scala-jissenscala-24-2048.jpg)
Uploaded byKazuhiro Sera
Scala が支える医療系ウェブサービス #jissenscala
https://jissenscala.doorkeeper.jp/events/19660
More Related Content
Similar to Scala が支える医療系ウェブサービス #jissenscala
![[Japanese] Skinny Framework で始める Scala #jjug_ccc #ccc_r24](https://cdn.slidesharecdn.com/ss_thumbnails/jjugccc2014spring-140518040446-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Scala が支える医療系ウェブサービス #jissenscala
- 1. Scala が支える 医療系ウェブサービス Kazuhiro Sera@seratch 2015/02/21 #jissenscala
- 2. アジェンダ •サービス要件・チームの現状を紹介 •Web 開発における技術変遷 •Play Framework導入事例 •実戦での OSS Octoparts 紹介 •Skinny Framework 導入事例 •その他の事例、実践内容 •所感、まとめ
- 3. 自己紹介 •2009 年から現職、ソフトウェアエンジニア •主に Java/Ruby/Scalaでコードを書く仕事 •基盤開発チーム：全社共通サービス・ライブラ リの開発・保守、AWS 管理等を担当 •ScalikeJDBC プロジェクトリード •Skinny Framework プロジェクトリード •Scalatra, json4s メンテナ（PR 待ってます）
- 4.
- 5.
- 6.
- 7. サービス要件の特徴 •m3.com は医療従事者向け会員制サービス •AskDoctors など一般の方向けサービス •サービスは小規模を含めると50 以上 •システム障害に非常にシビアなサービス •医療現場に近いシステムの場合、安定性が第一 •創業時 (2000 年) から続くサービス、DB •既存のレポート向けデータ集計も考慮した設計
- 8. チームの特徴 •事業別で約 10 (変動)のチームに分かれる •オンプレミスが中心、インフラチームは全チー ムを横断で対応する体制 •新卒はほとんどいない（今年度は 1 名入社） •内製比率を高く保つことにこだわっている •Java が得意なエンジニアが多いが Java/Ruby/ Scala 全てこなすケースも増えている
- 9.
- 10. Web 開発の歴史 •創業期: シンプルなServlet、XML 中心な Java フレームワーク、Zope の活用 •2000 年代中盤: SAStruts、Spring MVC、 Play1が主流、ほぼ Java のみ •2010 年代: 既存 Java システムに JSON API を提供させて段階的にフロントエンドを刷新、 Rails、Play2、Skinny など Java 以外の言語 での開発が活発に
- 11. アプリ開発技術の変遷 創業期 2008 -2012 2013 - 2015 開発言語 Java Python Java Java Ruby Scala Web フレーム ワーク 独自 MVC Servlet / JSP Zope SAStruts Spring MVC Jersey (JAX-RS) Play Framework 1 etc.. Ruby on Rails Play Framework 2 Skinny Framework Spring MVC ORM JDBC そのまま 独自 JDBC S2JDBC Doma Spring JDBC Hibernate ActiveRecord ScalikeJDBC Skinny ORM Doma
- 12.
- 13. m3.com を支える技術 2015 年からの新しいm3.com は 多くの Scala OSS に支えられています （Play、ScalikeJDBC、Skinny・・・）
- 14. 新 m3.com 構成 JSON JSON JSON JSON JSON Octoparts等の詳細は後ほど紹介 トップページ等の レンダリング
- 15.
- 16.
- 17. Play 導入状況 •2.0 リリース時(2012 年) から一部で導入、 当時から稼働し続けるシステムもある •2014 年∼ Scala がメインの開発チームのリー ドにより Play の導入が増えた •現在、ロンチ前のものも含め 6 件の実績 •必要に応じて Scala/Play にキャッチアップす るエンジニアが増加中
- 18. Play 事例（一部） 既存 Javaシステム のリニューアル 2 件 長年運用していた Servlet、JSP ベースのシステムを REST API に置き換え。データモデル class の共有、 Swagger 連携、ScalikeJDBC (複雑なクエリ対応、 commons-dbcp2)、Elasticseach (elastic4s)、Sentry (raven-logback)、metrics-play、scaldi-play。 Octoparts (OSS) https://github.com/ m3dev/octoparts 複数のバックエンド API コールを並列実行してまとめ て返すミドルウェア。Netflix が公開している Hystrix を 使ったバックエンド障害検知・切り離し・自動復旧。 キャッシュの設定・キャッシュ削除 API。 Elasticsearch + Kibana 連携でバックエンド API のパ フォーマンスを視覚化。
- 19. ライブラリ・運用 •定番で連携しているのは Scaldi、Swagger、 Dropwizard Metrics,Sentry あたり •基本的には Play が提供する API を使う •DB アクセスは ScalikeJDBC のみ •Octoparts を挟んだシステム間 API 連携 •Jenkins ジョブで sbt universal:package-zip- tarball 実行 & アプリサーバに配布 •Play の daemon は upstart で起動停止
- 20.
- 21. Octoparts とは バックエンド API呼び出しを並列化するだけでなく キャッシュ・障害検知・切り離し・自動復旧まで 賢くやってくれるシステム間連携の仲介役
- 22. Hystrix ・Netflix が公開している Javaで実装された OSS ・Octoparts は内部的に Hystrix の Command として バックエンド呼び出しを行う（#run() で）
- 23.
- 24. API リクエスト例 https://github.com/m3dev/octoparts/blob/develop/models/src/main/ scala/com/m3/octoparts/model/ { "requestMeta": {"id":“req-12345", "userId": “sera"}, "requests": [{"partId": “beer", "params": [{"key": “beerId”, "value": "1"}]}] } { "responseMeta": {"id": “req-12345", "processTime": 26}, "responses": [{"partId": “beer", "id": “beer”, “contents”: “{”name”: “yonayona”}”, “statusCode”: 200, “mimeType”: “application/json”, ”cookies”: [], "cacheControl": {"noStore": false, "noCache": false}, "warnings": [], "errors": [], "retrievedFromCache": false}] } リクエスト例 レスポンス例
- 25.
- 26. Hystrix ダッシュボード ・Hystrix が元々持つ機能 ・Circuitと Thread Pool の状態を可視化 ・どの Part がどの程度スローダウンして いるか現状がリアルタイムで分かる
- 27. ES + Kibana ・Fluentd経由で Elasticsearch + Kibana で Part 単位の 応答状況を可視化（success/timeout/failure/cached success、応答時間） ・本番環境のリアルタイムな状況把握に利用
- 28.
- 29. Skinny 導入状況 •Rails、Play2 に次いで採用事例が増えている •Play1メインだったチームが Skinny に移行 •Scala フリークではなかったチームが選択 •本番稼動 5 件、開発中含め計 6 件の実績 •2014/03 ∼ まだ若いフレームワークだが、特 にトラブルなく本番稼働中
- 30. ライブラリ・運用 •普通の Web アプリ要件は標準機能で間に合う •既存の社内Java ライブラリ（Servlet 関連も 含む）をそのまま組み込む •本番運用は Jenkins で war を社内 Maven リ ポジトリに publish、Tomcat に配る •運用側から見ると従来の Java と全く同じ
- 31. Skinny 事例（一部） アンケートサービス Angular.js サーバサイド、Gruntで JS ビルド。既存の ServletFilter 組み込み。Skinny ORM の複数データソー ス・スキーマ対応。管理 UI は scaffold ベース。 トラッキングデータ 集計基盤 データ分析の ETL（複数 DB・ログファイル）を crond でキックした skinny-task で実行。社内の担当者向け Web UI（設定入力、結果データダウンロード）。各種 メール通知（入力催促・結果通知）。 リアルタイム判定 API サービス 履歴データを元にリアルタイムで判定して結果を返す API サーバ。複数の条件判定を Servlet 上の Future 待 ち合わせで並列化。98 %tile 50ms 応答。管理 UI は i18n 機能で日英対応。
- 32. Play と Skinny •事実、Playは Scala 界隈でのデファクト •後発の動機 = 違う方向性のものを求めた •Skinny MVC は Future 前提の実装を求めな いアプリ要件・開発チームと相性がよい •会社としては常にすべての技術選択に開発チー ムによる主体的な判断を尊重する
- 33. Jenkins CI •sbt-scoverage でカバレッジ計測 •scctの頃に比べればかなり安定している •テスト結果が変わってしまうことがある対策と して、テスト実行とカバレッジ計測のジョブを 分けて、カバレッジ計測のジョブではテスト失 敗を無視…
- 34. Zipkin •Twitter 社の OSS分散トレーシングシステム •2013/10 から本番ボトルネック調査に活用 •自前の ServletFilter を仕込んでデータ取得 •運用が重くならないようにデータは Thrift で 受けて Redis に保存 http://twitter.github.io/zipkin/
- 35.
- 36. Typesafe Subscription •Typesafe Subscriptionを契約 •Play、Scala、sbt に関する Q&A サービス •Q&A は英語のみ、24 時間以内の回答保証 •何度か利用実績がある
- 37. Apache Spark •オンラインでの ApacheSpark Workshop に 参加（Typesafe 社、2 日間） •社内 Tech Talk 等での情報共有 •一部で既存のログ集計・データ分析への応用を 始めている
- 38. 現場を見て私の所感 •レビューで議論に時間をかけすぎない •定番のコードスタイルは徐々に見えてくる •動作検証のためのテストコードは当然必要 •不要に Scala のハードルを上げないコード •Futureを扱うセンスに長けたメンバの需要 •同期処理が十分速ければよい場合もある •未来のアップデート対応コストへの意識
- 39. まとめ •Scala が支える医療系ウェブサービスの話 •3 -4 年前は一部のメンバだけのもの •今は機が熟して 普通に 使われるものに •Java の会社→Java/Ruby/Scala の会社 •Web 開発に Rails、Play2、Skinny •適材適所で Scala をうまく使おう
- 40.