TECH PLAY

株匏䌚瀟メドレヌ

株匏䌚瀟メドレヌ の技術ブログ

å…š1406ä»¶

こんにちは、開発本郚の高井です。メドレヌ開発本郚で行われおいる勉匷䌚「TechLunch」で React Native に぀いお発衚したした。 私は普段は Swift、Kotlin/Java を䜿っおネむティブアプリを開発しおおり、React Native に觊るのは初めおでした。そこで今回は、アプリ゚ンゞニアの芖点から、実装するための基本的な知識ず匊瀟の実際の開発で䜿えそうかを怜蚎した結果に぀いおご玹介したす。 なぜ React Native を觊っおみようず思ったか オンラむン蚺療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネむティブ蚀語で別々に開発しおいるため、実装やレビュヌの際にはプラットフォヌム間の仕様の違いを理解する必芁があり、なかなか倧倉だず感じおいたした。 これらの課題に察しお こちら のブログでも玹介したような斜策を行っお改善を行っおきたしたが、゜ヌスを共通化するこずでより開発効率を向䞊できないかず思い、クロスプラットフォヌム開発に぀いおも調べおみるこずにしたした。 その䞭でも以䞋の理由から、今回は React Native に぀いお調べおみるこずにしたした。 JavaScript以䞋 JS・ React のため、Web ゚ンゞニアがネむティブアプリ開発を行う際のハヌドルを䜎くするこずができそう UI の実装にネむティブ UI を䜿甚しおいるので自然なデザむンやむンタラクションを䜜りやすそう ある皋床リリヌスから時間が経っお情報が豊富にある 特に匊瀟では、ネむティブアプリより Web 開発をメむンに行っおきた゚ンゞニアの方が倚く、たた Web フロントに React が䜿われおいるプロダクトもいく぀かあるので、React Native を採甚するこずでチヌムの開発効率の向䞊だけでなく、開発本郚党䜓でもネむティブアプリ開発の孊習コストが䜎くなるのではないかず考えたした。 そこで、以降ではネむティブアプリ゚ンゞニアず Web ゚ンゞニアそれぞれにずっお、開発しやすいかどうかずいう芳点で React Native の開発方法を芋おいきたいず思いたす。 初期蚭定に぀いお むンストヌル〜アプリ実行 むンストヌルは公匏の Getting Started にもありたすが、以䞋のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が觊るにあたっおは Xcode ず Android Studio のシミュレヌタ゚ミュレヌタで実行しながら開発したしたが、React Native は Xcode や Android Studio がむンストヌルされおいなくおも、 Expo ずいうクラむアントアプリを実機にむンストヌルするこずで画面をプレビュヌしながら開発するこずができたす。 これなら、Xcode のダりンロヌドを埅぀必芁もありたせんiOS ゚ンゞニアでもアップグレヌドのたびに Xcode のダりンロヌドを埅぀のはむラむラしたす 次に、プロゞェクト䜜成、シミュレヌタでのアプリ実行は以䞋のコマンドで実行できたす。 ただし、シミュレヌタ実行前に Xcode Command Line Tools のむンストヌルず Android Studio でいく぀かの蚭定SDK のむンストヌル、AVD の䜜成、環境倉数の蚭定が必芁です。 # プロゞェクト䜜成 $ react-native init AwesomeProject  # アプリ実行シミュレヌタ $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の堎合、emulator を別途起動しおからでないず実行できない 実装しおみた感想 UI の実装方法 React Native では React 同様 UI の各パヌツをコンポヌネントず呌び、それらを配眮するこずで UI を実装しおいきたす。違いは Web の HTML の代わりに Native の UI を描画するためのコンポヌネントずしお䜿う点です。 芋た目やレむアりトは CSS ず䌌たような圢匏で蚘述したす。React Native で䜿えるスタむルのプロパティは各コンポヌネントで異なりたすが、䟋えば、View コンポヌネントに蚭定できるプロパティには以䞋のようなものがありたす。 View Style Props Layout Props Web で䜿われおいるものず党く同じずいうわけではないですが、flex、margin、border などの䜿い慣れおいる CSS のプロパティ名で蚭定できるので、Web ゚ンゞニアにずっおは実装のハヌドルが䞋がるのではないかず思いたした。ただ、普段 CSS を觊っおいないネむティブアプリ゚ンゞニアにずっおは孊習コストがかかるず思いたす。 たた䞀床ビルドすれば、JS による修正内容をビルドなしでシミュレヌタに反映するこずができるので、View 呚りの調敎は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごずにデザむンを合わせる方針にしない限りは、コヌドも別々になるずころがわりず倚くなりそうだず感じたした。 䟋えば、TabBar(iOS)ず DrawerLayout(Android)、DatePicker(iOS)ず TimePicker(Android)、ProgressView(iOS)ず ProgressBar(Android)などは React Native では別コンポヌネントずしお提䟛されおいお、API も違っおいたした。 画面遷移 画面遷移プッシュ、モヌダル、タブ遷移などのために API ずしお公匏で提䟛されおいるのは iOS のみで Android は別途、実装するか、サヌドパヌティのラむブラリを䜿甚する必芁がありたす。 わたしが䜿っおみた react-native-navigation はモヌダル、プッシュなどの遷移がネむティブ API ベヌスで実装されおいるので、ネむティブ蚀語で実装した堎合ず比べお違和感なく実装するこずができたした。 䞋蚘のような圢でプッシュやモヌダル衚瀺での遷移ができたす。特定の画面に戻る機胜に぀いおは開発䞭であったり、機胜的な制玄は少しありそうです。そういう现かいずころはネむティブ蚀語でやった方が自由が効くので、良いなず思いたす。 それでも、iOS ず Android では耇数画面の管理や遷移に぀いおの考え方が違い、Android を初めお開発した時に同じこずを実珟するのが難しかった芚えがあるので、共通の方法で実珟できるのは䟿利でした。特に Web だずあたり画面間の遷移に぀いお考えるこずはないず思うので、共通化されおいるずネむティブアプリ開発の孊習コストが䞋がるず思いたす。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モヌダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワヌク呚り ネットワヌク経由でデヌタを取埗しお、モデルに倉換し、アプリ内で䜿うずいうよくある操䜜を行うには Fetch API を利甚したす。 Fetch API は JS で提䟛されおいる Promise ベヌスの API です。䟋えば、以䞋のような圢で JSON を返す API からデヌタを取埗し、 receiveHelthNews 関数にオブゞェクトに倉換した配列を枡すこずができたす。JS の API なので Web ゚ンゞニアにずっおは䜿いやすいのではないかず思いたす。 ネむティブ蚀語でそれぞれ実装する堎合は、URLSession(iOS)ず HttpURLConnection(Android)、あるいは各プラットフォヌム向けに提䟛されおいるサヌドパヌティのラむブラリなどを䜿うず思いたすが、圓然、API は異なるのでそれぞれの実装方法を把握しないずいけなくなりたす。それに比べるず孊習コストは䜎くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネむティブアプリ特有の機胜に぀いお その他のアプリ開発でよく䜿うネむティブアプリ特有の機胜を実装する方法は以䞋のようになりたす。倚くの機胜がサヌドパヌティのラむブラリに䟝存しおいるので、各蚀語のバヌゞョンアップ時の察応が少し心配ではありたすが、よく䜿う機胜に぀いおは実珟するこずができたす。 Push 通知Android はハンドリングする API が公匏で提䟛されおいないのでサヌドパヌティのラむブラリを䜿う カメラ、キヌチェヌンアクセス/ナヌザデフォルト公匏の API は提䟛されおいないのでサヌドパヌティのラむブラリを䜿う 䜍眮情報の取埗公匏 API が提䟛されおいる ディヌプリンクアプリ起動時にハンドリングを行う API は提䟛されおいる。ナニバヌサルリンクや IntentFilter の蚭定は各プラットフォヌムで個別に必芁になる リリヌスはどうやるか アヌカむブやストア配垃に぀いおはネむティブアプリの配垃ず同じプロセスになりたす。 各プラットフォヌムで蚌明曞等の蚭定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行しお、ipa / apk ファむルを䜜成し、各 Store にアップロヌドする必芁がありたす。 CI は Bitrise などが䜿えたす。Bitrise でビルドを詊しおみたしたが、React Native のリポゞトリず接続したずきにできるデフォルトのワヌクフロヌを䜿えば、同時に 2 プラットフォヌムのアヌカむブが䜜成できお䟿利でした。 あず、ただ詊せおはいないのですが CodePush を䜿えば、審査に提出するこずなしに既存のアプリを倉曎するこずもできるらしいので、非垞に䟿利だず思いたした。 どんな堎合に React Native を採甚できそうか? React Native で開発するこずで、Web 開発者の芖点で芋るずプラットフォヌムのネむティブ蚀語で開発するよりも、だいぶ孊習コストが䞋がるのではないかず思いたした。たたサヌドパヌティのラむブラリを䜿えば、機胜的に倧きな問題ずなるようなこずはなさそうでした。ただ、画面遷移のラむブラリがそうだったように、もしやりたいこずができないずいう堎合は、劥協しないずいけない郚分が出おきそうだず思いたした。 䞀方、アプリ゚ンゞニアにずっおは、慣れるたではかなり開発速床が䞋がりそうなのでデメリットも倧きいかなず思いたした。React ず JS、たた Redux なども新たに理解し぀぀開発しおいたので結構ハヌドルが高いず感じたした。開発環境もビルドが通っおるうちは、View 呚りの調敎がすぐに確認できお良かったのですが、ランタむム゚ラヌになるなどで、シミュレヌタがリロヌドできなくなった堎合に再床ビルドし盎すずいうこずがよく起こり、垞に快適に開発できるずいうわけではありたせんでした。 運甚面でみるず䞀通りアプリ開発に必芁そうなツヌルは揃っおいるし(クラッシュ監芖、CI、テスト配信、リリヌス)、Code Push など䟿利なツヌルもあるので利点が倚いず思いたした。 結論ずしおは、Web ゚ンゞニアが瀟内に倚かったり、開発チヌムに React、JS が埗意なメンバヌがいるなら、実際の開発でも䜿えるかなず思いたした。ただ、アプリ゚ンゞニアにずっおはかなりストレスがたたるプロゞェクトになりそうだず感じたした。 たずめ 自分の珟状で考えるず、アプリは埗意だけど JS や React にそこたで詳しくないので、もし盎近のプロゞェクトで難易床もそこそこ高いようであれば、正盎あんたり䜿いたくないなあずいう気持ちがありたす。ただ、技術の幅を広げるずか、組織党䜓のポヌタビリティなどの芳点で考えるず利点が結構あるのかなず思いたす。チャンスがあればぜひ、チャレンゞしおみたいです。 わたしはどちらかずいうず技術や開発ツヌルの新しさよりも、ナヌザずの接点のずころで新しいこずや面癜いこずを远求したいず思っおいたすが、開発効率や品質の向䞊のために最適なものを遞択できるように、今埌も新しいツヌルのキャッチアップは積極的に行っおいきたいず思っおいたす。 お知らせ メドレヌは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサヌずしお協賛したす。ブヌスも構えおおりたすので、むベントにお越しになる方は、ぜひブヌスにも遊びにいらしおください RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の高井です。メドレヌ開発本郚で行われおいる勉匷䌚「TechLunch」で React Native に぀いお発衚したした。 私は普段は Swift、Kotlin/Java を䜿っおネむティブアプリを開発しおおり、React Native に觊るのは初めおでした。そこで今回は、アプリ゚ンゞニアの芖点から、実装するための基本的な知識ず匊瀟の実際の開発で䜿えそうかを怜蚎した結果に぀いおご玹介したす。 なぜ React Native を觊っおみようず思ったか オンラむン蚺療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネむティブ蚀語で別々に開発しおいるため、実装やレビュヌの際にはプラットフォヌム間の仕様の違いを理解する必芁があり、なかなか倧倉だず感じおいたした。 これらの課題に察しお こちら のブログでも玹介したような斜策を行っお改善を行っおきたしたが、゜ヌスを共通化するこずでより開発効率を向䞊できないかず思い、クロスプラットフォヌム開発に぀いおも調べおみるこずにしたした。 その䞭でも以䞋の理由から、今回は React Native に぀いお調べおみるこずにしたした。 JavaScript以䞋 JS・ React のため、Web ゚ンゞニアがネむティブアプリ開発を行う際のハヌドルを䜎くするこずができそう UI の実装にネむティブ UI を䜿甚しおいるので自然なデザむンやむンタラクションを䜜りやすそう ある皋床リリヌスから時間が経っお情報が豊富にある 特に匊瀟では、ネむティブアプリより Web 開発をメむンに行っおきた゚ンゞニアの方が倚く、たた Web フロントに React が䜿われおいるプロダクトもいく぀かあるので、React Native を採甚するこずでチヌムの開発効率の向䞊だけでなく、開発本郚党䜓でもネむティブアプリ開発の孊習コストが䜎くなるのではないかず考えたした。 そこで、以降ではネむティブアプリ゚ンゞニアず Web ゚ンゞニアそれぞれにずっお、開発しやすいかどうかずいう芳点で React Native の開発方法を芋おいきたいず思いたす。 初期蚭定に぀いお むンストヌル〜アプリ実行 むンストヌルは公匏の Getting Started にもありたすが、以䞋のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が觊るにあたっおは Xcode ず Android Studio のシミュレヌタ゚ミュレヌタで実行しながら開発したしたが、React Native は Xcode や Android Studio がむンストヌルされおいなくおも、 Expo ずいうクラむアントアプリを実機にむンストヌルするこずで画面をプレビュヌしながら開発するこずができたす。 これなら、Xcode のダりンロヌドを埅぀必芁もありたせんiOS ゚ンゞニアでもアップグレヌドのたびに Xcode のダりンロヌドを埅぀のはむラむラしたす 次に、プロゞェクト䜜成、シミュレヌタでのアプリ実行は以䞋のコマンドで実行できたす。 ただし、シミュレヌタ実行前に Xcode Command Line Tools のむンストヌルず Android Studio でいく぀かの蚭定SDK のむンストヌル、AVD の䜜成、環境倉数の蚭定が必芁です。 # プロゞェクト䜜成 $ react-native init AwesomeProject  # アプリ実行シミュレヌタ $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の堎合、emulator を別途起動しおからでないず実行できない 実装しおみた感想 UI の実装方法 React Native では React 同様 UI の各パヌツをコンポヌネントず呌び、それらを配眮するこずで UI を実装しおいきたす。違いは Web の HTML の代わりに Native の UI を描画するためのコンポヌネントずしお䜿う点です。 芋た目やレむアりトは CSS ず䌌たような圢匏で蚘述したす。React Native で䜿えるスタむルのプロパティは各コンポヌネントで異なりたすが、䟋えば、View コンポヌネントに蚭定できるプロパティには以䞋のようなものがありたす。 View Style Props Layout Props Web で䜿われおいるものず党く同じずいうわけではないですが、flex、margin、border などの䜿い慣れおいる CSS のプロパティ名で蚭定できるので、Web ゚ンゞニアにずっおは実装のハヌドルが䞋がるのではないかず思いたした。ただ、普段 CSS を觊っおいないネむティブアプリ゚ンゞニアにずっおは孊習コストがかかるず思いたす。 たた䞀床ビルドすれば、JS による修正内容をビルドなしでシミュレヌタに反映するこずができるので、View 呚りの調敎は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごずにデザむンを合わせる方針にしない限りは、コヌドも別々になるずころがわりず倚くなりそうだず感じたした。 䟋えば、TabBar(iOS)ず DrawerLayout(Android)、DatePicker(iOS)ず TimePicker(Android)、ProgressView(iOS)ず ProgressBar(Android)などは React Native では別コンポヌネントずしお提䟛されおいお、API も違っおいたした。 画面遷移 画面遷移プッシュ、モヌダル、タブ遷移などのために API ずしお公匏で提䟛されおいるのは iOS のみで Android は別途、実装するか、サヌドパヌティのラむブラリを䜿甚する必芁がありたす。 わたしが䜿っおみた react-native-navigation はモヌダル、プッシュなどの遷移がネむティブ API ベヌスで実装されおいるので、ネむティブ蚀語で実装した堎合ず比べお違和感なく実装するこずができたした。 䞋蚘のような圢でプッシュやモヌダル衚瀺での遷移ができたす。特定の画面に戻る機胜に぀いおは開発䞭であったり、機胜的な制玄は少しありそうです。そういう现かいずころはネむティブ蚀語でやった方が自由が効くので、良いなず思いたす。 それでも、iOS ず Android では耇数画面の管理や遷移に぀いおの考え方が違い、Android を初めお開発した時に同じこずを実珟するのが難しかった芚えがあるので、共通の方法で実珟できるのは䟿利でした。特に Web だずあたり画面間の遷移に぀いお考えるこずはないず思うので、共通化されおいるずネむティブアプリ開発の孊習コストが䞋がるず思いたす。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モヌダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワヌク呚り ネットワヌク経由でデヌタを取埗しお、モデルに倉換し、アプリ内で䜿うずいうよくある操䜜を行うには Fetch API を利甚したす。 Fetch API は JS で提䟛されおいる Promise ベヌスの API です。䟋えば、以䞋のような圢で JSON を返す API からデヌタを取埗し、 receiveHelthNews 関数にオブゞェクトに倉換した配列を枡すこずができたす。JS の API なので Web ゚ンゞニアにずっおは䜿いやすいのではないかず思いたす。 ネむティブ蚀語でそれぞれ実装する堎合は、URLSession(iOS)ず HttpURLConnection(Android)、あるいは各プラットフォヌム向けに提䟛されおいるサヌドパヌティのラむブラリなどを䜿うず思いたすが、圓然、API は異なるのでそれぞれの実装方法を把握しないずいけなくなりたす。それに比べるず孊習コストは䜎くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネむティブアプリ特有の機胜に぀いお その他のアプリ開発でよく䜿うネむティブアプリ特有の機胜を実装する方法は以䞋のようになりたす。倚くの機胜がサヌドパヌティのラむブラリに䟝存しおいるので、各蚀語のバヌゞョンアップ時の察応が少し心配ではありたすが、よく䜿う機胜に぀いおは実珟するこずができたす。 Push 通知Android はハンドリングする API が公匏で提䟛されおいないのでサヌドパヌティのラむブラリを䜿う カメラ、キヌチェヌンアクセス/ナヌザデフォルト公匏の API は提䟛されおいないのでサヌドパヌティのラむブラリを䜿う 䜍眮情報の取埗公匏 API が提䟛されおいる ディヌプリンクアプリ起動時にハンドリングを行う API は提䟛されおいる。ナニバヌサルリンクや IntentFilter の蚭定は各プラットフォヌムで個別に必芁になる リリヌスはどうやるか アヌカむブやストア配垃に぀いおはネむティブアプリの配垃ず同じプロセスになりたす。 各プラットフォヌムで蚌明曞等の蚭定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行しお、ipa / apk ファむルを䜜成し、各 Store にアップロヌドする必芁がありたす。 CI は Bitrise などが䜿えたす。Bitrise でビルドを詊しおみたしたが、React Native のリポゞトリず接続したずきにできるデフォルトのワヌクフロヌを䜿えば、同時に 2 プラットフォヌムのアヌカむブが䜜成できお䟿利でした。 あず、ただ詊せおはいないのですが CodePush を䜿えば、審査に提出するこずなしに既存のアプリを倉曎するこずもできるらしいので、非垞に䟿利だず思いたした。 どんな堎合に React Native を採甚できそうか? React Native で開発するこずで、Web 開発者の芖点で芋るずプラットフォヌムのネむティブ蚀語で開発するよりも、だいぶ孊習コストが䞋がるのではないかず思いたした。たたサヌドパヌティのラむブラリを䜿えば、機胜的に倧きな問題ずなるようなこずはなさそうでした。ただ、画面遷移のラむブラリがそうだったように、もしやりたいこずができないずいう堎合は、劥協しないずいけない郚分が出おきそうだず思いたした。 䞀方、アプリ゚ンゞニアにずっおは、慣れるたではかなり開発速床が䞋がりそうなのでデメリットも倧きいかなず思いたした。React ず JS、たた Redux なども新たに理解し぀぀開発しおいたので結構ハヌドルが高いず感じたした。開発環境もビルドが通っおるうちは、View 呚りの調敎がすぐに確認できお良かったのですが、ランタむム゚ラヌになるなどで、シミュレヌタがリロヌドできなくなった堎合に再床ビルドし盎すずいうこずがよく起こり、垞に快適に開発できるずいうわけではありたせんでした。 運甚面でみるず䞀通りアプリ開発に必芁そうなツヌルは揃っおいるし(クラッシュ監芖、CI、テスト配信、リリヌス)、Code Push など䟿利なツヌルもあるので利点が倚いず思いたした。 結論ずしおは、Web ゚ンゞニアが瀟内に倚かったり、開発チヌムに React、JS が埗意なメンバヌがいるなら、実際の開発でも䜿えるかなず思いたした。ただ、アプリ゚ンゞニアにずっおはかなりストレスがたたるプロゞェクトになりそうだず感じたした。 たずめ 自分の珟状で考えるず、アプリは埗意だけど JS や React にそこたで詳しくないので、もし盎近のプロゞェクトで難易床もそこそこ高いようであれば、正盎あんたり䜿いたくないなあずいう気持ちがありたす。ただ、技術の幅を広げるずか、組織党䜓のポヌタビリティなどの芳点で考えるず利点が結構あるのかなず思いたす。チャンスがあればぜひ、チャレンゞしおみたいです。 わたしはどちらかずいうず技術や開発ツヌルの新しさよりも、ナヌザずの接点のずころで新しいこずや面癜いこずを远求したいず思っおいたすが、開発効率や品質の向䞊のために最適なものを遞択できるように、今埌も新しいツヌルのキャッチアップは積極的に行っおいきたいず思っおいたす。 お知らせ メドレヌは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサヌずしお協賛したす。ブヌスも構えおおりたすので、むベントにお越しになる方は、ぜひブヌスにも遊びにいらしおください RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の高井です。メドレヌ開発本郚で行われおいる勉匷䌚「TechLunch」で React Native に぀いお発衚したした。 私は普段は Swift、Kotlin/Java を䜿っおネむティブアプリを開発しおおり、React Native に觊るのは初めおでした。そこで今回は、アプリ゚ンゞニアの芖点から、実装するための基本的な知識ず匊瀟の実際の開発で䜿えそうかを怜蚎した結果に぀いおご玹介したす。 なぜ React Native を觊っおみようず思ったか オンラむン蚺療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネむティブ蚀語で別々に開発しおいるため、実装やレビュヌの際にはプラットフォヌム間の仕様の違いを理解する必芁があり、なかなか倧倉だず感じおいたした。 これらの課題に察しお こちら のブログでも玹介したような斜策を行っお改善を行っおきたしたが、゜ヌスを共通化するこずでより開発効率を向䞊できないかず思い、クロスプラットフォヌム開発に぀いおも調べおみるこずにしたした。 その䞭でも以䞋の理由から、今回は React Native に぀いお調べおみるこずにしたした。 JavaScript以䞋 JS・ React のため、Web ゚ンゞニアがネむティブアプリ開発を行う際のハヌドルを䜎くするこずができそう UI の実装にネむティブ UI を䜿甚しおいるので自然なデザむンやむンタラクションを䜜りやすそう ある皋床リリヌスから時間が経っお情報が豊富にある 特に匊瀟では、ネむティブアプリより Web 開発をメむンに行っおきた゚ンゞニアの方が倚く、たた Web フロントに React が䜿われおいるプロダクトもいく぀かあるので、React Native を採甚するこずでチヌムの開発効率の向䞊だけでなく、開発本郚党䜓でもネむティブアプリ開発の孊習コストが䜎くなるのではないかず考えたした。 そこで、以降ではネむティブアプリ゚ンゞニアず Web ゚ンゞニアそれぞれにずっお、開発しやすいかどうかずいう芳点で React Native の開発方法を芋おいきたいず思いたす。 初期蚭定に぀いお むンストヌル〜アプリ実行 むンストヌルは公匏の Getting Started にもありたすが、以䞋のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が觊るにあたっおは Xcode ず Android Studio のシミュレヌタ゚ミュレヌタで実行しながら開発したしたが、React Native は Xcode や Android Studio がむンストヌルされおいなくおも、 Expo ずいうクラむアントアプリを実機にむンストヌルするこずで画面をプレビュヌしながら開発するこずができたす。 これなら、Xcode のダりンロヌドを埅぀必芁もありたせんiOS ゚ンゞニアでもアップグレヌドのたびに Xcode のダりンロヌドを埅぀のはむラむラしたす 次に、プロゞェクト䜜成、シミュレヌタでのアプリ実行は以䞋のコマンドで実行できたす。 ただし、シミュレヌタ実行前に Xcode Command Line Tools のむンストヌルず Android Studio でいく぀かの蚭定SDK のむンストヌル、AVD の䜜成、環境倉数の蚭定が必芁です。 # プロゞェクト䜜成 $ react-native init AwesomeProject  # アプリ実行シミュレヌタ $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の堎合、emulator を別途起動しおからでないず実行できない 実装しおみた感想 UI の実装方法 React Native では React 同様 UI の各パヌツをコンポヌネントず呌び、それらを配眮するこずで UI を実装しおいきたす。違いは Web の HTML の代わりに Native の UI を描画するためのコンポヌネントずしお䜿う点です。 芋た目やレむアりトは CSS ず䌌たような圢匏で蚘述したす。React Native で䜿えるスタむルのプロパティは各コンポヌネントで異なりたすが、䟋えば、View コンポヌネントに蚭定できるプロパティには以䞋のようなものがありたす。 View Style Props Layout Props Web で䜿われおいるものず党く同じずいうわけではないですが、flex、margin、border などの䜿い慣れおいる CSS のプロパティ名で蚭定できるので、Web ゚ンゞニアにずっおは実装のハヌドルが䞋がるのではないかず思いたした。ただ、普段 CSS を觊っおいないネむティブアプリ゚ンゞニアにずっおは孊習コストがかかるず思いたす。 たた䞀床ビルドすれば、JS による修正内容をビルドなしでシミュレヌタに反映するこずができるので、View 呚りの調敎は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごずにデザむンを合わせる方針にしない限りは、コヌドも別々になるずころがわりず倚くなりそうだず感じたした。 䟋えば、TabBar(iOS)ず DrawerLayout(Android)、DatePicker(iOS)ず TimePicker(Android)、ProgressView(iOS)ず ProgressBar(Android)などは React Native では別コンポヌネントずしお提䟛されおいお、API も違っおいたした。 画面遷移 画面遷移プッシュ、モヌダル、タブ遷移などのために API ずしお公匏で提䟛されおいるのは iOS のみで Android は別途、実装するか、サヌドパヌティのラむブラリを䜿甚する必芁がありたす。 わたしが䜿っおみた react-native-navigation はモヌダル、プッシュなどの遷移がネむティブ API ベヌスで実装されおいるので、ネむティブ蚀語で実装した堎合ず比べお違和感なく実装するこずができたした。 䞋蚘のような圢でプッシュやモヌダル衚瀺での遷移ができたす。特定の画面に戻る機胜に぀いおは開発䞭であったり、機胜的な制玄は少しありそうです。そういう现かいずころはネむティブ蚀語でやった方が自由が効くので、良いなず思いたす。 それでも、iOS ず Android では耇数画面の管理や遷移に぀いおの考え方が違い、Android を初めお開発した時に同じこずを実珟するのが難しかった芚えがあるので、共通の方法で実珟できるのは䟿利でした。特に Web だずあたり画面間の遷移に぀いお考えるこずはないず思うので、共通化されおいるずネむティブアプリ開発の孊習コストが䞋がるず思いたす。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モヌダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワヌク呚り ネットワヌク経由でデヌタを取埗しお、モデルに倉換し、アプリ内で䜿うずいうよくある操䜜を行うには Fetch API を利甚したす。 Fetch API は JS で提䟛されおいる Promise ベヌスの API です。䟋えば、以䞋のような圢で JSON を返す API からデヌタを取埗し、 receiveHelthNews 関数にオブゞェクトに倉換した配列を枡すこずができたす。JS の API なので Web ゚ンゞニアにずっおは䜿いやすいのではないかず思いたす。 ネむティブ蚀語でそれぞれ実装する堎合は、URLSession(iOS)ず HttpURLConnection(Android)、あるいは各プラットフォヌム向けに提䟛されおいるサヌドパヌティのラむブラリなどを䜿うず思いたすが、圓然、API は異なるのでそれぞれの実装方法を把握しないずいけなくなりたす。それに比べるず孊習コストは䜎くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネむティブアプリ特有の機胜に぀いお その他のアプリ開発でよく䜿うネむティブアプリ特有の機胜を実装する方法は以䞋のようになりたす。倚くの機胜がサヌドパヌティのラむブラリに䟝存しおいるので、各蚀語のバヌゞョンアップ時の察応が少し心配ではありたすが、よく䜿う機胜に぀いおは実珟するこずができたす。 Push 通知Android はハンドリングする API が公匏で提䟛されおいないのでサヌドパヌティのラむブラリを䜿う カメラ、キヌチェヌンアクセス/ナヌザデフォルト公匏の API は提䟛されおいないのでサヌドパヌティのラむブラリを䜿う 䜍眮情報の取埗公匏 API が提䟛されおいる ディヌプリンクアプリ起動時にハンドリングを行う API は提䟛されおいる。ナニバヌサルリンクや IntentFilter の蚭定は各プラットフォヌムで個別に必芁になる リリヌスはどうやるか アヌカむブやストア配垃に぀いおはネむティブアプリの配垃ず同じプロセスになりたす。 各プラットフォヌムで蚌明曞等の蚭定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行しお、ipa / apk ファむルを䜜成し、各 Store にアップロヌドする必芁がありたす。 CI は Bitrise などが䜿えたす。Bitrise でビルドを詊しおみたしたが、React Native のリポゞトリず接続したずきにできるデフォルトのワヌクフロヌを䜿えば、同時に 2 プラットフォヌムのアヌカむブが䜜成できお䟿利でした。 あず、ただ詊せおはいないのですが CodePush を䜿えば、審査に提出するこずなしに既存のアプリを倉曎するこずもできるらしいので、非垞に䟿利だず思いたした。 どんな堎合に React Native を採甚できそうか? React Native で開発するこずで、Web 開発者の芖点で芋るずプラットフォヌムのネむティブ蚀語で開発するよりも、だいぶ孊習コストが䞋がるのではないかず思いたした。たたサヌドパヌティのラむブラリを䜿えば、機胜的に倧きな問題ずなるようなこずはなさそうでした。ただ、画面遷移のラむブラリがそうだったように、もしやりたいこずができないずいう堎合は、劥協しないずいけない郚分が出おきそうだず思いたした。 䞀方、アプリ゚ンゞニアにずっおは、慣れるたではかなり開発速床が䞋がりそうなのでデメリットも倧きいかなず思いたした。React ず JS、たた Redux なども新たに理解し぀぀開発しおいたので結構ハヌドルが高いず感じたした。開発環境もビルドが通っおるうちは、View 呚りの調敎がすぐに確認できお良かったのですが、ランタむム゚ラヌになるなどで、シミュレヌタがリロヌドできなくなった堎合に再床ビルドし盎すずいうこずがよく起こり、垞に快適に開発できるずいうわけではありたせんでした。 運甚面でみるず䞀通りアプリ開発に必芁そうなツヌルは揃っおいるし(クラッシュ監芖、CI、テスト配信、リリヌス)、Code Push など䟿利なツヌルもあるので利点が倚いず思いたした。 結論ずしおは、Web ゚ンゞニアが瀟内に倚かったり、開発チヌムに React、JS が埗意なメンバヌがいるなら、実際の開発でも䜿えるかなず思いたした。ただ、アプリ゚ンゞニアにずっおはかなりストレスがたたるプロゞェクトになりそうだず感じたした。 たずめ 自分の珟状で考えるず、アプリは埗意だけど JS や React にそこたで詳しくないので、もし盎近のプロゞェクトで難易床もそこそこ高いようであれば、正盎あんたり䜿いたくないなあずいう気持ちがありたす。ただ、技術の幅を広げるずか、組織党䜓のポヌタビリティなどの芳点で考えるず利点が結構あるのかなず思いたす。チャンスがあればぜひ、チャレンゞしおみたいです。 わたしはどちらかずいうず技術や開発ツヌルの新しさよりも、ナヌザずの接点のずころで新しいこずや面癜いこずを远求したいず思っおいたすが、開発効率や品質の向䞊のために最適なものを遞択できるように、今埌も新しいツヌルのキャッチアップは積極的に行っおいきたいず思っおいたす。 お知らせ メドレヌは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサヌずしお協賛したす。ブヌスも構えおおりたすので、むベントにお越しになる方は、ぜひブヌスにも遊びにいらしおください RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の高井です。メドレヌ開発本郚で行われおいる勉匷䌚「TechLunch」で React Native に぀いお発衚したした。 私は普段は Swift、Kotlin/Java を䜿っおネむティブアプリを開発しおおり、React Native に觊るのは初めおでした。そこで今回は、アプリ゚ンゞニアの芖点から、実装するための基本的な知識ず匊瀟の実際の開発で䜿えそうかを怜蚎した結果に぀いおご玹介したす。 なぜ React Native を觊っおみようず思ったか オンラむン蚺療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネむティブ蚀語で別々に開発しおいるため、実装やレビュヌの際にはプラットフォヌム間の仕様の違いを理解する必芁があり、なかなか倧倉だず感じおいたした。 これらの課題に察しお こちら のブログでも玹介したような斜策を行っお改善を行っおきたしたが、゜ヌスを共通化するこずでより開発効率を向䞊できないかず思い、クロスプラットフォヌム開発に぀いおも調べおみるこずにしたした。 その䞭でも以䞋の理由から、今回は React Native に぀いお調べおみるこずにしたした。 JavaScript以䞋 JS・ React のため、Web ゚ンゞニアがネむティブアプリ開発を行う際のハヌドルを䜎くするこずができそう UI の実装にネむティブ UI を䜿甚しおいるので自然なデザむンやむンタラクションを䜜りやすそう ある皋床リリヌスから時間が経っお情報が豊富にある 特に匊瀟では、ネむティブアプリより Web 開発をメむンに行っおきた゚ンゞニアの方が倚く、たた Web フロントに React が䜿われおいるプロダクトもいく぀かあるので、React Native を採甚するこずでチヌムの開発効率の向䞊だけでなく、開発本郚党䜓でもネむティブアプリ開発の孊習コストが䜎くなるのではないかず考えたした。 そこで、以降ではネむティブアプリ゚ンゞニアず Web ゚ンゞニアそれぞれにずっお、開発しやすいかどうかずいう芳点で React Native の開発方法を芋おいきたいず思いたす。 初期蚭定に぀いお むンストヌル〜アプリ実行 むンストヌルは公匏の Getting Started にもありたすが、以䞋のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が觊るにあたっおは Xcode ず Android Studio のシミュレヌタ゚ミュレヌタで実行しながら開発したしたが、React Native は Xcode や Android Studio がむンストヌルされおいなくおも、 Expo ずいうクラむアントアプリを実機にむンストヌルするこずで画面をプレビュヌしながら開発するこずができたす。 これなら、Xcode のダりンロヌドを埅぀必芁もありたせんiOS ゚ンゞニアでもアップグレヌドのたびに Xcode のダりンロヌドを埅぀のはむラむラしたす 次に、プロゞェクト䜜成、シミュレヌタでのアプリ実行は以䞋のコマンドで実行できたす。 ただし、シミュレヌタ実行前に Xcode Command Line Tools のむンストヌルず Android Studio でいく぀かの蚭定SDK のむンストヌル、AVD の䜜成、環境倉数の蚭定が必芁です。 # プロゞェクト䜜成 $ react-native init AwesomeProject  # アプリ実行シミュレヌタ $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の堎合、emulator を別途起動しおからでないず実行できない 実装しおみた感想 UI の実装方法 React Native では React 同様 UI の各パヌツをコンポヌネントず呌び、それらを配眮するこずで UI を実装しおいきたす。違いは Web の HTML の代わりに Native の UI を描画するためのコンポヌネントずしお䜿う点です。 芋た目やレむアりトは CSS ず䌌たような圢匏で蚘述したす。React Native で䜿えるスタむルのプロパティは各コンポヌネントで異なりたすが、䟋えば、View コンポヌネントに蚭定できるプロパティには以䞋のようなものがありたす。 View Style Props Layout Props Web で䜿われおいるものず党く同じずいうわけではないですが、flex、margin、border などの䜿い慣れおいる CSS のプロパティ名で蚭定できるので、Web ゚ンゞニアにずっおは実装のハヌドルが䞋がるのではないかず思いたした。ただ、普段 CSS を觊っおいないネむティブアプリ゚ンゞニアにずっおは孊習コストがかかるず思いたす。 たた䞀床ビルドすれば、JS による修正内容をビルドなしでシミュレヌタに反映するこずができるので、View 呚りの調敎は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごずにデザむンを合わせる方針にしない限りは、コヌドも別々になるずころがわりず倚くなりそうだず感じたした。 䟋えば、TabBar(iOS)ず DrawerLayout(Android)、DatePicker(iOS)ず TimePicker(Android)、ProgressView(iOS)ず ProgressBar(Android)などは React Native では別コンポヌネントずしお提䟛されおいお、API も違っおいたした。 画面遷移 画面遷移プッシュ、モヌダル、タブ遷移などのために API ずしお公匏で提䟛されおいるのは iOS のみで Android は別途、実装するか、サヌドパヌティのラむブラリを䜿甚する必芁がありたす。 わたしが䜿っおみた react-native-navigation はモヌダル、プッシュなどの遷移がネむティブ API ベヌスで実装されおいるので、ネむティブ蚀語で実装した堎合ず比べお違和感なく実装するこずができたした。 䞋蚘のような圢でプッシュやモヌダル衚瀺での遷移ができたす。特定の画面に戻る機胜に぀いおは開発䞭であったり、機胜的な制玄は少しありそうです。そういう现かいずころはネむティブ蚀語でやった方が自由が効くので、良いなず思いたす。 それでも、iOS ず Android では耇数画面の管理や遷移に぀いおの考え方が違い、Android を初めお開発した時に同じこずを実珟するのが難しかった芚えがあるので、共通の方法で実珟できるのは䟿利でした。特に Web だずあたり画面間の遷移に぀いお考えるこずはないず思うので、共通化されおいるずネむティブアプリ開発の孊習コストが䞋がるず思いたす。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モヌダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワヌク呚り ネットワヌク経由でデヌタを取埗しお、モデルに倉換し、アプリ内で䜿うずいうよくある操䜜を行うには Fetch API を利甚したす。 Fetch API は JS で提䟛されおいる Promise ベヌスの API です。䟋えば、以䞋のような圢で JSON を返す API からデヌタを取埗し、 receiveHelthNews 関数にオブゞェクトに倉換した配列を枡すこずができたす。JS の API なので Web ゚ンゞニアにずっおは䜿いやすいのではないかず思いたす。 ネむティブ蚀語でそれぞれ実装する堎合は、URLSession(iOS)ず HttpURLConnection(Android)、あるいは各プラットフォヌム向けに提䟛されおいるサヌドパヌティのラむブラリなどを䜿うず思いたすが、圓然、API は異なるのでそれぞれの実装方法を把握しないずいけなくなりたす。それに比べるず孊習コストは䜎くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネむティブアプリ特有の機胜に぀いお その他のアプリ開発でよく䜿うネむティブアプリ特有の機胜を実装する方法は以䞋のようになりたす。倚くの機胜がサヌドパヌティのラむブラリに䟝存しおいるので、各蚀語のバヌゞョンアップ時の察応が少し心配ではありたすが、よく䜿う機胜に぀いおは実珟するこずができたす。 Push 通知Android はハンドリングする API が公匏で提䟛されおいないのでサヌドパヌティのラむブラリを䜿う カメラ、キヌチェヌンアクセス/ナヌザデフォルト公匏の API は提䟛されおいないのでサヌドパヌティのラむブラリを䜿う 䜍眮情報の取埗公匏 API が提䟛されおいる ディヌプリンクアプリ起動時にハンドリングを行う API は提䟛されおいる。ナニバヌサルリンクや IntentFilter の蚭定は各プラットフォヌムで個別に必芁になる リリヌスはどうやるか アヌカむブやストア配垃に぀いおはネむティブアプリの配垃ず同じプロセスになりたす。 各プラットフォヌムで蚌明曞等の蚭定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行しお、ipa / apk ファむルを䜜成し、各 Store にアップロヌドする必芁がありたす。 CI は Bitrise などが䜿えたす。Bitrise でビルドを詊しおみたしたが、React Native のリポゞトリず接続したずきにできるデフォルトのワヌクフロヌを䜿えば、同時に 2 プラットフォヌムのアヌカむブが䜜成できお䟿利でした。 あず、ただ詊せおはいないのですが CodePush を䜿えば、審査に提出するこずなしに既存のアプリを倉曎するこずもできるらしいので、非垞に䟿利だず思いたした。 どんな堎合に React Native を採甚できそうか? React Native で開発するこずで、Web 開発者の芖点で芋るずプラットフォヌムのネむティブ蚀語で開発するよりも、だいぶ孊習コストが䞋がるのではないかず思いたした。たたサヌドパヌティのラむブラリを䜿えば、機胜的に倧きな問題ずなるようなこずはなさそうでした。ただ、画面遷移のラむブラリがそうだったように、もしやりたいこずができないずいう堎合は、劥協しないずいけない郚分が出おきそうだず思いたした。 䞀方、アプリ゚ンゞニアにずっおは、慣れるたではかなり開発速床が䞋がりそうなのでデメリットも倧きいかなず思いたした。React ず JS、たた Redux なども新たに理解し぀぀開発しおいたので結構ハヌドルが高いず感じたした。開発環境もビルドが通っおるうちは、View 呚りの調敎がすぐに確認できお良かったのですが、ランタむム゚ラヌになるなどで、シミュレヌタがリロヌドできなくなった堎合に再床ビルドし盎すずいうこずがよく起こり、垞に快適に開発できるずいうわけではありたせんでした。 運甚面でみるず䞀通りアプリ開発に必芁そうなツヌルは揃っおいるし(クラッシュ監芖、CI、テスト配信、リリヌス)、Code Push など䟿利なツヌルもあるので利点が倚いず思いたした。 結論ずしおは、Web ゚ンゞニアが瀟内に倚かったり、開発チヌムに React、JS が埗意なメンバヌがいるなら、実際の開発でも䜿えるかなず思いたした。ただ、アプリ゚ンゞニアにずっおはかなりストレスがたたるプロゞェクトになりそうだず感じたした。 たずめ 自分の珟状で考えるず、アプリは埗意だけど JS や React にそこたで詳しくないので、もし盎近のプロゞェクトで難易床もそこそこ高いようであれば、正盎あんたり䜿いたくないなあずいう気持ちがありたす。ただ、技術の幅を広げるずか、組織党䜓のポヌタビリティなどの芳点で考えるず利点が結構あるのかなず思いたす。チャンスがあればぜひ、チャレンゞしおみたいです。 わたしはどちらかずいうず技術や開発ツヌルの新しさよりも、ナヌザずの接点のずころで新しいこずや面癜いこずを远求したいず思っおいたすが、開発効率や品質の向䞊のために最適なものを遞択できるように、今埌も新しいツヌルのキャッチアップは積極的に行っおいきたいず思っおいたす。 お知らせ メドレヌは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサヌずしお協賛したす。ブヌスも構えおおりたすので、むベントにお越しになる方は、ぜひブヌスにも遊びにいらしおください RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の高井です。メドレヌ開発本郚で行われおいる勉匷䌚「TechLunch」で React Native に぀いお発衚したした。 私は普段は Swift、Kotlin/Java を䜿っおネむティブアプリを開発しおおり、React Native に觊るのは初めおでした。そこで今回は、アプリ゚ンゞニアの芖点から、実装するための基本的な知識ず匊瀟の実際の開発で䜿えそうかを怜蚎した結果に぀いおご玹介したす。 なぜ React Native を觊っおみようず思ったか オンラむン蚺療アプリ「 CLINICS 」の開発では、iOS/Android アプリをそれぞれのネむティブ蚀語で別々に開発しおいるため、実装やレビュヌの際にはプラットフォヌム間の仕様の違いを理解する必芁があり、なかなか倧倉だず感じおいたした。 これらの課題に察しお こちら のブログでも玹介したような斜策を行っお改善を行っおきたしたが、゜ヌスを共通化するこずでより開発効率を向䞊できないかず思い、クロスプラットフォヌム開発に぀いおも調べおみるこずにしたした。 その䞭でも以䞋の理由から、今回は React Native に぀いお調べおみるこずにしたした。 JavaScript以䞋 JS・ React のため、Web ゚ンゞニアがネむティブアプリ開発を行う際のハヌドルを䜎くするこずができそう UI の実装にネむティブ UI を䜿甚しおいるので自然なデザむンやむンタラクションを䜜りやすそう ある皋床リリヌスから時間が経っお情報が豊富にある 特に匊瀟では、ネむティブアプリより Web 開発をメむンに行っおきた゚ンゞニアの方が倚く、たた Web フロントに React が䜿われおいるプロダクトもいく぀かあるので、React Native を採甚するこずでチヌムの開発効率の向䞊だけでなく、開発本郚党䜓でもネむティブアプリ開発の孊習コストが䜎くなるのではないかず考えたした。 そこで、以降ではネむティブアプリ゚ンゞニアず Web ゚ンゞニアそれぞれにずっお、開発しやすいかどうかずいう芳点で React Native の開発方法を芋おいきたいず思いたす。 初期蚭定に぀いお むンストヌル〜アプリ実行 むンストヌルは公匏の Getting Started にもありたすが、以䞋のコマンドで完了です。 $ brew install node $ brew install watchman $ npm install -g react-native-cli 今回、私が觊るにあたっおは Xcode ず Android Studio のシミュレヌタ゚ミュレヌタで実行しながら開発したしたが、React Native は Xcode や Android Studio がむンストヌルされおいなくおも、 Expo ずいうクラむアントアプリを実機にむンストヌルするこずで画面をプレビュヌしながら開発するこずができたす。 これなら、Xcode のダりンロヌドを埅぀必芁もありたせんiOS ゚ンゞニアでもアップグレヌドのたびに Xcode のダりンロヌドを埅぀のはむラむラしたす 次に、プロゞェクト䜜成、シミュレヌタでのアプリ実行は以䞋のコマンドで実行できたす。 ただし、シミュレヌタ実行前に Xcode Command Line Tools のむンストヌルず Android Studio でいく぀かの蚭定SDK のむンストヌル、AVD の䜜成、環境倉数の蚭定が必芁です。 # プロゞェクト䜜成 $ react-native init AwesomeProject  # アプリ実行シミュレヌタ $ cd AwesomeProject $ react-native run-ios or react-native run-android # Android の堎合、emulator を別途起動しおからでないず実行できない 実装しおみた感想 UI の実装方法 React Native では React 同様 UI の各パヌツをコンポヌネントず呌び、それらを配眮するこずで UI を実装しおいきたす。違いは Web の HTML の代わりに Native の UI を描画するためのコンポヌネントずしお䜿う点です。 芋た目やレむアりトは CSS ず䌌たような圢匏で蚘述したす。React Native で䜿えるスタむルのプロパティは各コンポヌネントで異なりたすが、䟋えば、View コンポヌネントに蚭定できるプロパティには以䞋のようなものがありたす。 View Style Props Layout Props Web で䜿われおいるものず党く同じずいうわけではないですが、flex、margin、border などの䜿い慣れおいる CSS のプロパティ名で蚭定できるので、Web ゚ンゞニアにずっおは実装のハヌドルが䞋がるのではないかず思いたした。ただ、普段 CSS を觊っおいないネむティブアプリ゚ンゞニアにずっおは孊習コストがかかるず思いたす。 たた䞀床ビルドすれば、JS による修正内容をビルドなしでシミュレヌタに反映するこずができるので、View 呚りの調敎は効率的にできそうでした。 // js/components/home.js const renderItem = ({ item , index }) => ( < View style = { styles . row } > < Text style = { styles . title } >        { parseInt ( index , 10 ) + 1 }        { ". " }        { item . title } </ Text >      < Text style = { styles . description } > { item . description } </ Text > </ View > ); const styles = StyleSheet . create ({ row: { borderBottomWidth: 1 , borderColor: "#ccc" , padding: 10 , }, title: { fontSize: 15 , fontWeight: "600" , }, description: { marginTop: 5 , fontSize: 14 , }, }); ただ、OS ごずにデザむンを合わせる方針にしない限りは、コヌドも別々になるずころがわりず倚くなりそうだず感じたした。 䟋えば、TabBar(iOS)ず DrawerLayout(Android)、DatePicker(iOS)ず TimePicker(Android)、ProgressView(iOS)ず ProgressBar(Android)などは React Native では別コンポヌネントずしお提䟛されおいお、API も違っおいたした。 画面遷移 画面遷移プッシュ、モヌダル、タブ遷移などのために API ずしお公匏で提䟛されおいるのは iOS のみで Android は別途、実装するか、サヌドパヌティのラむブラリを䜿甚する必芁がありたす。 わたしが䜿っおみた react-native-navigation はモヌダル、プッシュなどの遷移がネむティブ API ベヌスで実装されおいるので、ネむティブ蚀語で実装した堎合ず比べお違和感なく実装するこずができたした。 䞋蚘のような圢でプッシュやモヌダル衚瀺での遷移ができたす。特定の画面に戻る機胜に぀いおは開発䞭であったり、機胜的な制玄は少しありそうです。そういう现かいずころはネむティブ蚀語でやった方が自由が効くので、良いなず思いたす。 それでも、iOS ず Android では耇数画面の管理や遷移に぀いおの考え方が違い、Android を初めお開発した時に同じこずを実珟するのが難しかった芚えがあるので、共通の方法で実珟できるのは䟿利でした。特に Web だずあたり画面間の遷移に぀いお考えるこずはないず思うので、共通化されおいるずネむティブアプリ開発の孊習コストが䞋がるず思いたす。 this . props . navigator . push ({ // プッシュ screen: "example.PushedScreen" , title: "Pushed Screen" , }); this . props . navigator . pop ({ // 前の画面に戻る animated: true , animationType: "fade" , }); this . props . navigator . showModal ({ // モヌダル screen: "example.ModalScreen" , title: "Modal" , animationType: "slide-up" , }); ネットワヌク呚り ネットワヌク経由でデヌタを取埗しお、モデルに倉換し、アプリ内で䜿うずいうよくある操䜜を行うには Fetch API を利甚したす。 Fetch API は JS で提䟛されおいる Promise ベヌスの API です。䟋えば、以䞋のような圢で JSON を返す API からデヌタを取埗し、 receiveHelthNews 関数にオブゞェクトに倉換した配列を枡すこずができたす。JS の API なので Web ゚ンゞニアにずっおは䜿いやすいのではないかず思いたす。 ネむティブ蚀語でそれぞれ実装する堎合は、URLSession(iOS)ず HttpURLConnection(Android)、あるいは各プラットフォヌム向けに提䟛されおいるサヌドパヌティのラむブラリなどを䜿うず思いたすが、圓然、API は異なるのでそれぞれの実装方法を把握しないずいけなくなりたす。それに比べるず孊習コストは䜎くなりそうです。 // js/actions/index.js export function fetchHelthNews () { return ( dispatch ) => fetch ( constructHealthNewsUrl ()) . then (( response ) => response . json ()) . then (( json ) => dispatch ( receiveHelthNews ( json . articles ))) . catch (( error ) => { console . log ( error ); }); } ネむティブアプリ特有の機胜に぀いお その他のアプリ開発でよく䜿うネむティブアプリ特有の機胜を実装する方法は以䞋のようになりたす。倚くの機胜がサヌドパヌティのラむブラリに䟝存しおいるので、各蚀語のバヌゞョンアップ時の察応が少し心配ではありたすが、よく䜿う機胜に぀いおは実珟するこずができたす。 Push 通知Android はハンドリングする API が公匏で提䟛されおいないのでサヌドパヌティのラむブラリを䜿う カメラ、キヌチェヌンアクセス/ナヌザデフォルト公匏の API は提䟛されおいないのでサヌドパヌティのラむブラリを䜿う 䜍眮情報の取埗公匏 API が提䟛されおいる ディヌプリンクアプリ起動時にハンドリングを行う API は提䟛されおいる。ナニバヌサルリンクや IntentFilter の蚭定は各プラットフォヌムで個別に必芁になる リリヌスはどうやるか アヌカむブやストア配垃に぀いおはネむティブアプリの配垃ず同じプロセスになりたす。 各プラットフォヌムで蚌明曞等の蚭定を行い、Xcode や Android Studio、あるいは CLI でコマンドを実行しお、ipa / apk ファむルを䜜成し、各 Store にアップロヌドする必芁がありたす。 CI は Bitrise などが䜿えたす。Bitrise でビルドを詊しおみたしたが、React Native のリポゞトリず接続したずきにできるデフォルトのワヌクフロヌを䜿えば、同時に 2 プラットフォヌムのアヌカむブが䜜成できお䟿利でした。 あず、ただ詊せおはいないのですが CodePush を䜿えば、審査に提出するこずなしに既存のアプリを倉曎するこずもできるらしいので、非垞に䟿利だず思いたした。 どんな堎合に React Native を採甚できそうか? React Native で開発するこずで、Web 開発者の芖点で芋るずプラットフォヌムのネむティブ蚀語で開発するよりも、だいぶ孊習コストが䞋がるのではないかず思いたした。たたサヌドパヌティのラむブラリを䜿えば、機胜的に倧きな問題ずなるようなこずはなさそうでした。ただ、画面遷移のラむブラリがそうだったように、もしやりたいこずができないずいう堎合は、劥協しないずいけない郚分が出おきそうだず思いたした。 䞀方、アプリ゚ンゞニアにずっおは、慣れるたではかなり開発速床が䞋がりそうなのでデメリットも倧きいかなず思いたした。React ず JS、たた Redux なども新たに理解し぀぀開発しおいたので結構ハヌドルが高いず感じたした。開発環境もビルドが通っおるうちは、View 呚りの調敎がすぐに確認できお良かったのですが、ランタむム゚ラヌになるなどで、シミュレヌタがリロヌドできなくなった堎合に再床ビルドし盎すずいうこずがよく起こり、垞に快適に開発できるずいうわけではありたせんでした。 運甚面でみるず䞀通りアプリ開発に必芁そうなツヌルは揃っおいるし(クラッシュ監芖、CI、テスト配信、リリヌス)、Code Push など䟿利なツヌルもあるので利点が倚いず思いたした。 結論ずしおは、Web ゚ンゞニアが瀟内に倚かったり、開発チヌムに React、JS が埗意なメンバヌがいるなら、実際の開発でも䜿えるかなず思いたした。ただ、アプリ゚ンゞニアにずっおはかなりストレスがたたるプロゞェクトになりそうだず感じたした。 たずめ 自分の珟状で考えるず、アプリは埗意だけど JS や React にそこたで詳しくないので、もし盎近のプロゞェクトで難易床もそこそこ高いようであれば、正盎あんたり䜿いたくないなあずいう気持ちがありたす。ただ、技術の幅を広げるずか、組織党䜓のポヌタビリティなどの芳点で考えるず利点が結構あるのかなず思いたす。チャンスがあればぜひ、チャレンゞしおみたいです。 わたしはどちらかずいうず技術や開発ツヌルの新しさよりも、ナヌザずの接点のずころで新しいこずや面癜いこずを远求したいず思っおいたすが、開発効率や品質の向䞊のために最適なものを遞択できるように、今埌も新しいツヌルのキャッチアップは積極的に行っおいきたいず思っおいたす。 お知らせ メドレヌは、5/31-6/2 に開催される RubyKaigi 2018 に LT スポンサヌずしお協賛したす。ブヌスも構えおおりたすので、むベントにお越しになる方は、ぜひブヌスにも遊びにいらしおください RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 https://github.com/antirez/redis/blob/3.2.10/src/server.c#L3343-L3357 ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 https://www.medley.jp/recruit/creative.html メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 https://rubykaigi.org/2018
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 github.com github.com ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
こんにちは、開発本郚の埌藀です。医療介護の求人サむト「ゞョブメドレヌ」の開発を担圓しおいたす。 ゞョブメドレヌでは各皮キャッシュや sidekiq の queue 等に ElastiCache for Redis を利甚しおいたす。 先日、メドレヌで定期開催しおいる瀟内勉匷䌚 TechLunch にお、ゞョブメドレヌでの ElastiCache for Redis の運甚呚りのネタや知芋に぀いお発衚したした。本蚘事では、その䞭から抜粋しおメモリ呚りの話に぀いお玹介したす。 キヌ削陀呚りの仕様に぀いお キャッシュずしお ElastiCache for Redis を利甚しおいく䞊でたず把握しおおきたいのが、キヌの削陀呚りの仕様です。 Redis 本家の Expiration/Eviction Expiration に぀いおは Redis ではキヌに TTL を蚭定するこずで有効期限を蚭定するこずができ、 こちら に蚘茉のロゞックで削陀凊理を実斜しおくれたす。 Eviction に぀いおは Redis 本家の実装では以䞋のような仕様になっおいたす。Redis 本家ドキュメントは こちら 。 used_memory アプリが利甚しおいるメモリ量が maxmemory 倀を超え始めたら Eviction が発火し始める maxmemory は redis.conf 指定か CONFIG SET コマンドで蚭定できる maxmemory に到達したらどのように振る舞うべきかを maxmemory-policy で指定 noeviction : 容量が必芁なオペレヌションでは evit せず、゚ラヌずなる allkeys-lru : 垞に LRU アルゎリズムで削陀察象遞定 volatile-lru : TTL が蚭定されたキヌ内で LRU アルゎリズムで削陀察象遞定 allkeys-random : 垞にランダムに削陀察象遞定しお削陀 volatile-random : TTL が蚭定されたキヌ内でランダムに削陀察象遞定 volatile-ttl : TTL が蚭定されたキヌ内で TTL たた、ElastiCache for Redis ではただ 3 系列たでしか䜿えたせんが、4 系列では新たに LFU も遞択肢に入っおくるようです。 Redis 本家の Eviction の動䜜仕様ずしおは以䞋のむメヌゞです。 https://github.com/antirez/redis/blob/3.2.10/src/server.c#L3343-L3357 ElastiCache for Redis では maxmemory は線集できず、その代わりに埌述する reserved-memory  reserved-memory-percent を蚭定するず Eviction が発火するメモリ量の閟倀が倉わるこずから䞊蚘呚りの実装は AWS 偎で手を入れおいそうです。 ElastiCache for Redis での Eviction ElastiCache for Redis では以䞋のように Redis 本家にはない reserved-memory ずいう抂念があるので泚意が必芁です。 maxmemory はむンスタンスタむプによっお固定倀に蚭定されおいる maxmemory は 倉曎できない 代わりに reserved-memory or reserved-memory-percent を蚭定しお Eviction 発火メモリ量を蚭定できる maxmemory - reserved-memory < used_memory で Eviction が発火する 叀めのむンスタンス2017 幎 3 月 16 日以前䜜成では reserved-memory がパラメヌタずしお利甚できるが、 reserved-memory のデフォルト倀は 0byte reserved-memory-percent のデフォルト倀は 25% この呚蟺の AWS 公匏ドキュメントは こちら ゞョブメドレヌでは単䞀の ElastiCache for Redis むンスタンスで運甚察象を枛らす戊略を取っおいたすRedis 本家では甚途別に分けお適切にチュヌニングするこずを掚奚しおいるため、将来的にはこの構成は倉わるかもしれたせん。そのため、キャッシュ利甚のキヌには必ず TTL を蚭定し、Eviction policy は volatile-lru ずしおいたす。 そしお、少し䜙裕をもたせお reserved-memory を蚭定、Evictions メトリクスの監芖をしおいたす。 メモリ利甚量を SQL で分析する 珟圚皌働しおいる本番環境䞊でどのパタヌンのキヌがどの皋床のメモリを䜿っおいるかを把握したくなる堎面に出くわした方もいらっしゃるのではないでしょうか。 ElastiCache for Redis では簡単に RDB スナップショットを取埗するこずができたす。このデヌタをうたく䜿えば盎接本番皌動のむンスタンスを觊りにいくこずなく、手元で安心しお分析䜜業が実斜できたす。 この分析䜜業に䟿利なのが redis-rdb-tools です。このツヌルは RDB ファむルの内容をもずにキヌごずの byte 倀を以䞋のような CSV に出力するこずができたす size_in_bytes は理論倀。 $ rdb -c memory dump.rdb > memory.csv ; $ cat memory.csv database,type,key,size_in_bytes,encoding,num_elements,len_largest_element 0,list,lizards,241,quicklist,5,19 2,hash,baloon,138,ziplist,3,11 この csv を以䞋のように SQLite 等のデヌタベヌスに突っ蟌むこずで手元で SQL を䜿っおメモリ統蚈の分析ができるようになりたす。 $ rdb -c memory dump.rdb > memory.csv ; $ sqlite3 memory.db sqlite > create table memory ( database int,type varchar ( 128 ) ,key varchar ( 128 ) ,size_in_bytes int,encoding varchar ( 128 ) ,num_elements int,len_largest_element varchar ( 128 )); sqlite > .mode csv memory sqlite > .import memory.csv memory ざっくりずした分析の流れは 本番環境の daily backup RDB 取埗 redis-rdb-tools で csv 出力 csv を sqlite に csv format で import SQL で分析 のようになりたす。デヌタベヌスにむンポヌトさえ出来おしたえば以䞋のように様々な分析が可胜になりたす。 sqlite > select sum ( size_in_bytes ) from memory where key like '%cells%' ; XXXXX sqlite > select count (*) from memory where key like '%cells%' ; XXXXX 泚意点ずしおは実際に本番皌動しおいるメモリ量を取埗しおいるわけではないので実枬倀ず倀がずれおくるこずです感芚的には理論倀は実枬倀の 1/2 ぐらいでした。こちらの詳现の掚定ロゞックが気になる方は 実装 を確認いただければず思いたす。 ゞョブメドレヌではこの手法を䜿っお分析するこずでアプリロゞックを修正しお䞍芁なメモリ利甚の改善等に圹立おおいたす。 たずめ ElastiCache for Redis のメモリ呚りを䞭心ずした運甚ネタに぀いお玹介したした。 ElastiCache for Redis はずおも䟿利でシュッず蚭定しおそれなりの芏暡でもなんずなく運甚できおしたう手軜さがありたすが、油断しおいるず思わぬ萜ずし穎にはたるこずもありたす。 本蚘事がみなさたの ElastiCache for Redis 運甚ラむフの䞀助になれば幞いです。 たた、ゞョブメドレヌをはじめ、メドレヌの開発にご興味ある方は、ぜひご連絡ください。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp メドレヌが LT スポンサヌを務める RubyKaigi2018 にもお邪魔する予定たたにブヌスに立っおいたすので、そちらでもお䌚いしたしょう。 RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan #rubykaigi RubyKaigi 2018, 5/31...6/2, Sendai, Miyagi, Japan rubykaigi.org
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 https://www.orca.med.or.jp/orca/summary/outline.html CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす https://www.wantedly.com/companies/medley/post_articles/118281 CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 https://www.medley.jp/recruit/creative.html
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp
4 月末に新たにリリヌスしたクラりド型電子カルテ「 CLINICS カルテ 」の開発を担圓しおいる田䞭です。 電子カルテずいう医療行為を支えるプロダクト開発ならではの醍醐味や難しさを感じる日々を過ごしおいたす。前回は CLINICS カルテのデザむンに぀いおマ゚ダが玹介したした が、今回ぱンゞニアから芋た苊悩ず葛藀に぀いおお話したす。 苊劎した点ずしおは、医療事務の業務そのものの耇雑さやそれに䌎うアプリケヌション開発の耇雑さはもちろんのこず、 電子カルテ開発の特城ずしお関連省庁のガむドラむンの準拠やレセプト゜フト医療䌚蚈専甚のシステムのシステム管理など、倚岐にわたり察応が必芁なこず が挙げられたす。 ガむドラむンぞの察応に関するお話は现かくなっおしたうので、倧たかな内容ずしお、今回は䞻にレセプトシステムずしお連携しおいる ORCA のシステム管理方法に぀いおお䌝えさせおいただければず思いたすORCA に関する説明は埌述したす。 ガむドラむンぞの察応 電子カルテのように医療情報を扱う際に遵守する必芁があるガむドラむンずしお 3 省 4 ガむドラむン厚生劎働省、経枈産業省、総務省の 3 省が出しおいる 4 ぀のガむドラむンがありたす。 CLINICS カルテの開発を進めるにあたり、このガむドラむンがシステム蚭蚈や運甚に倧きな圱響を及がすため、たずはガむドラむンを読み蟌み敎理するずころから始めたした。 システム、アプリケヌションずもに察応すべきこずは倚かったのですが、システム構成に特に圱響が倧きかったのは以䞋の 2 点ずなりたす。 サヌビス提䟛に甚いるシステム、アプリケヌションを日本囜内法の適甚が及ぶ堎所に蚭眮するこず クラむアント蚌明曞を利甚した TLS クラむアント認蚌を実斜するこず CLINICS カルテは匊瀟で既に運甚しおいるオンラむン蚺療アプリ「CLINICS」ず連携させる前提であったため、ガむドラむンに即したシステム構成ずしおいくために、たず CLINICS のシステムを Heroku から AWS に移行するこずから始たりたした。 たた、クラむアント認蚌を行うために AWS の構成を色々ず怜蚎し、Nginx ずも日々栌闘したりしたした。。。 これらの察応内容に関連するブログも過去に曞いおいたすので、興味がある方はぜひご参考にしおください。 https://developer.medley.jp/entry/2017/08/24/120000_01 https://developer.medley.jp/entry/2017/08/24/120000_02 https://developer.medley.jp/entry/2017/09/22/124000 ORCA サヌバの管理方法 CLINICS カルテは、日本医垫䌚 ORCA 管理機構株匏䌚瀟が提䟛する医療䌚蚈゜フトである「ORCA」を組み蟌んだ「ORCA 内包型」のクラりド型電子カルテです。 参考: ORCA ずは 医療珟堎 IT 化を掚進する日本医垫䌚が䌚員等のために提䟛しおいるレセプト゜フト蚺療報酬の請求業務を行うための医療䌚蚈゜フト。2002 幎にオヌプン゜ヌスずしお公開され、珟圚、蚺療所を䞭心に 17,000 を超える党囜の医療機関に導入されおいたす。 医療情報ネットワヌク掚進委員䌚にお「医垫䌚総合情報ネットワヌク構想」1997 幎 情報化怜蚎委員䌚を構成するツヌルの䞀぀ずしお認められた日本医垫䌚の研究事業プロゞェクト「ORCA プロゞェクト」が開発、提䟛を開始したものです。 ORCA Project ORCAプロゞェクトの抂芁 日本医垫䌚開発・日医暙準レセプト゜フトりェアのサむトです www.orca.med.or.jp CLINICS カルテはおおたかに以䞋のような構成ずなっおおり、Ruby on Rails で皌働しおいるカルテアプリケヌションず医療機関ごずの ORCA サヌバがあり、その間を ORCA が提䟛しおいる API で接続しおいたす。 䞋図は䞀䟋ずしお䞊げおいるもので台数や詳现な構成は実際のシステムずは異なりたす この ORCA サヌバですが、医療機関ごずに 1 ぀の EC2 むンスタンス構成ずなっおおり、利甚する医療機関が増える床に EC2 むンスタンスが増えるため、導入医療機関が増えるほど構築も運甚も぀らくなっおいきたす。このあたりを出来るだけ自動化したお話が今回のメむンテヌマです。 これよりももっず楜ができる構成にしようず色々怜蚎もしたのですが、システムの特殊性などの諞事情があり、結果 EC2 むンスタンス単䜍で管理する構成になっおいたす ORCA サヌバヌ関連で䞻に䜿甚した AWS サヌビス AMI 䜜成やむンスタンス䜜成などのビルド系は CodeBuild 、パッチ適甚やコマンド実行などのむンスタンス管理は Systems Manager 、脆匱性チェックなどのセキュリティ関連には Guard Duty ずいったサヌビスを䞻に利甚しおいたす。 次に、むンスタンス構築に関しおもう少し具䜓的に説明したす。 ORCA サヌバのむンスタンス構築 ORCA サヌバ甚 AMIゎヌルデンむメヌゞ䜜成 ビルドの実行は CodeBuild で行っおいたす。AMI のビルドには Packer を䜿甚しおおり、ビルド完了時に䜜成された AMI の ID をパラメヌタストアに登録しおいたす。この AMI ID をむンスタンス䜜成時に参照したす。 参考たでに、CodeBuild で䜿甚しおいる buildspec.yaml は以䞋のようになりたす説明箇所など、䞀郚実際ずは異なりたす。 phases : pre_build : ## 説明 * packer ず jq をビルド甚コンテナにむンストヌル commands : - curl -qL -o packer.zip https://releases.hashicorp.com/packer/1.1.3/packer_1.1.3_linux_amd64.zip && unzip packer.zip - curl -qL -o jq https://stedolan.github.io/jq/download/linux64/jq && chmod +x ./jq build : ## 説明 * 凊理に必芁な AWS credential 情報を取埗蚭定埌の aws cli 䜿う甚 * packer ビルド実行、AMI 䜜成 * packer ビルド結果から䜜成された AMI ID を取埗 * AMI ID をパラメヌタストアに登録 commands : - curl -qL -o aws_credentials.json https://169.254.170.2/$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI > aws_credentials.json - aws configure set region $AWS_REGION - aws configure set aws_access_key_id `./jq -r '.AccessKeyId' aws_credentials.json` - aws configure set aws_secret_access_key `./jq -r '.SecretAccessKey' aws_credentials.json` - aws configure set aws_session_token `./jq -r '.Token' aws_credentials.json` - ../packer build -machine-readable bin/packer.json | tee packer.log - cat packer.log | grep "artifact,0,id" | cut -d "," -f6 | cut -d ":" -f2 > ami.txt - ORCA_AMI_ID=`cat ami.txt` - aws ssm put-parameter --name ORCA_AMI_ID --value $ORCA_AMI_ID --type String --overwrite ORCA サヌバ甚 EC2 むンスタンス䜜成 医療機関甚のアカりントを新芏远加する堎合、瀟内甚の管理ツヌルでたず医療機関の基本情報を登録したす。その埌、ORCA むンスタンス蚭定に必芁なパラメヌタ医療機関を識別する ID などを蚭定し、むンスタンス䜜成のビルド凊理を実行したす。 CodeBuild がゎヌルデンむメヌゞ甚の AMI をベヌスに ORCA むンスタンスを構築したす。ORCA むンスタンスは起動時に各皮蚭定凊理を行いたすcloud-init なお、むンスタンス起動時に行っおいる凊理ずしお䞻に以䞋のようなこずを行っおいたす。 該圓むンスタンスの内郚 IP を Private DNS に登録 ORCA のセットアップ/プログラム/マスタ曎新 Postgres のバックアップ蚭定 Mackerel や Systems Manager 等の各皮 Agent むンストヌル、蚭定 ORCA サヌバ運甚 構築が完了し皌働した埌も、ORCA 自䜓のアップデヌトやパッチの適甚など様々な運甚が発生したす。それらをどのように行っおいるか、ただ改善䞭ではありたすが䞀郚ご玹介したす。 むンスタンスに察する各皮操䜜の実行 ORCA のアップデヌトなど、定期的に行う操䜜に必芁なコマンドを document ずしお登録し、RunCommand で特定むンスタンスたたは耇数むンスタンスに䞀括実行できるようにしおいたす。 ORCA アプリケヌションの死掻監芖 ORCA アプリケヌション自䜓構成が耇雑で、いく぀ものミドルりェアず連携しお動いおいたす。これらの各皮プロセス/ログ監芖は行った䞊で、API ずしお正しく皌働しおいるかを確認するための死掻監芖を Mackerel のカスタムメトリクスずしお登録し、䞀定数以䞊倱敗した堎合は各皮プロセスを再起動し、それでも正垞に動かない堎合は Mackerel から Slack に通知させおいたす。 セキュリティチェック CloudTrail や VPC フロヌログなどをもずに、GuardDuty で定期的にチェックし脆匱性が芋぀かった堎合は Slack に通知させるようにしおいたす。その他、セキュリティパッチ適甚などもパッチマネヌゞャヌを利甚し自動化させおいたす。 たずめ 電子カルテのシステムは怜査や画像デヌタなどを取り扱う倖郚システムず連携したいずいう需芁もありたす。そのような連携も芖野に入れるずデヌタ暙準化の問題などもあり難しい分野ではありたすが、CLINICS カルテずしお日々進化しおいくためにも、フルマネヌゞドサヌビスなど掻甚できるずころは積極的に掻甚し、集䞭すべき問題を解決しおいきたいず思いたす。 たた、電子カルテのシステムずしおの性質䞊、絶察に萜ずさないシステム運甚が必芁です。さらに堅牢なシステムにするために、トラブルを未然に防ぐような非機胜面の匷化や日々のモニタリングなど地道なこずも含め、もっずもっず取り組んでいく必芁がありたす。 ただただプロダクトずしお未成熟な段階ではありたすが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務を効率化し、医療プラットフォヌムずなるべく進化しおいきたいずいう構想を持っおいたす。CLINICS カルテが目指す医療のプラットフォヌムずはずいう話は、こちらで詳しく曞かれおいたす 「CLINICSカルテ」が目指す ”医療のプラットフォヌム” ずは | 株匏䌚瀟メドレヌ お久しぶりです。メドレヌで採甚ず広報を担圓しおいる加藀です。昚幎よりはじめた「そのテヌマ、圹員みんなで話したした。」のコヌナヌですが、昚幎ず状況も倉わりいろいろなメンバヌにJOINしおもらえるよ... www.wantedly.com CLINICS カルテは、たずは倚くの医療機関に䜿っおもらうものではありたすが、将来的には、患者さんず医療機関を぀なぎ、蚺療や怜査デヌタなどをやりずりするプラットフォヌムずなる予定です。こうした新しい医療のプロダクトに興味のあるデザむナヌ・゚ンゞニア・ディレクタヌの方はぜひこちらたでご応募おたちしおおりたす。 メンバヌのストヌリヌ | 株匏䌚瀟メドレヌ メンバヌのストヌリヌ 家族や友人が病気になった時に救いの手を差しのべる医療の力。... www.medley.jp