株式会社メドレー の技術ブログ
全1359件
こんにちは、開発本部の高井です。メドレー開発本部で行われている勉強会「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
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
こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 CLINICS カルテ 」のデザインを担当しているマエダです。 この電子カルテは、医療情報という複雑かつ独特なデータを扱うため、これまで自分自身が取り組んで来たような Web サービスとは違ったデザインのアプローチが必要でした。 今回は、そんなデザイナーの苦悩と葛藤についてお話します。医療に限らず、複雑な業務フローの業界でデザインに悩む人のお役に立てれば嬉しいです。 デザインに取り掛かる前の準備 CLINICS カルテは「日医標準レセプトソフト（ORCA）」を完全内包しているカルテなのですが、医療にかなり詳しい人でないと、「レセプトソフトって？」というところから疑問ですよね。 自分も同様で、レセプト？オーダー？DO 処方？…など医療の用語がわからない状態だったので、医療知識の理解や業務フローなどを知るところからプロジェクトに入り始めました。 デザイン業務を行う前に、医療事務の書籍を読んだり、医療事務がどのようにレセプト業務を行っているのかを学ぶことで、どのような UI が適しているかなど掴んでいきました。 ちなみに、皆さんが医療機関で受診した時に診療費の一部負担して支払われると思いますが（よく「3 割負担」など聞くこともあるかもしれません）残りの診療費については、 加入している医療保険の保険者（健康保険組合など）が支払います。 この診療費の請求のために発行する明細を診療報酬明細書（レセプト） といい、レセプトを作成し診療報酬を請求する業務のことをレセプト業務と言います。 そのレセプトを作成するための専用システムを「レセプトソフト」と言いますが、数あるレセプトソフトの中でも、日本医師会がオープンにして提供している「日医標準レセプトソフト（ORCA）」を、CLINICS カルテは内包しています。 実際に ORCA を使ってみると、レセプト業務を知らない初心者には難易度が高い操作性に戸惑い、ウェブデザイン歴 14 年のマエダも機能ひとつひとつ理解するのに苦しめられました。 Web サービスの管理ツールの利用に慣れていると、操作順序だったりボタンをクリックした後の挙動についてある程度予測できるのですが、ORCA はぜんぜん予測できない…。 そんなときに大活躍したのが、超大作 1400 ページ程もある ORCA の操作マニュアル。人生でこんなに読み込んだマニュアルはないと断言できるほど、カルテをデザインした際に大変重宝しました。 最初は操作に非常に大変でしたが、業務フローを理解したうえで、操作に慣れてくると ORCA の UI が請求業務をする上で理にかなっていることも理解できて、UI の奥深さにあらためて気付かされました。 ORCA は実際にダウンロードして試してみることができるので、興味のある方はぜひ触ってみてはいかがでしょうか。 ORCA 日レセクライアント： https://www.orca.med.or.jp/receip t/download/java-client/ ORCA 操作マニュアル： https://manual.orca.med.or.jp/5.0/html/ また、医療機関にカルテ入力〜会計処理までのフローのヒアリングなども行い、カルテのデザインをする上での前提知識を蓄えたり、既存カルテの課題なども整理することで、CLINICS カルテをどのようなデザインにしていくか、徐々に UI 方針を固めていきました。 ようやくデザインへのアプローチのお話 さて、ここまできてやっとデザインについての話です。 昨今の Web デザインはワイヤーを引いて、モックを Sketch 等のデザインツールで制作し、動作検証するためにプロトタイピングツールで触れるようにした後、システム実装に取り掛かるというのが一般的だと思います。しかし、カルテは画面ごとに細かい機能がたくさんあり、それぞれの機能についてデザインして、プロトタイピングして…という一連の作業を行うとデザイン業務だけで恐ろしいほどの工数がかかるのが目にみえてました。 そこで私は、デザインに取り掛かるアプローチを普段と変えてみることにしました。 デザインするけどデザインツールは使わない カルテはほぼコーディングだけでデザインしました。俗にいうインブラウザコーディングというやつでしょうか。 これによりワイヤー → デザインツール → プロトタイピングという、一連の工程を大幅に短縮して開発することができました。 カルテが動作する開発環境のほかに UI デザイン用の環境があります。UI デザインの環境でコーディングした HTML/CSS ファイルを開発環境に移植することができるため、エンジニアは UI 実装する手間も大幅に削減でき、システム開発に専念することができたのもよかった点です。 またインタラクションも CSS で制御するようにしたため、動作の部分もデザイナー自身の思い描いたイメージに合うように調整できたので、制限もあるプロトタイピングツールを使うよりも実際の挙動に近いかたちで検証できたこともメリットでした。 ちなみに 以前にマエダが書いた記事 として CLINICS アプリでデザイン言語システムを導入した事をお伝えしましたが、CLINICS カルテの UI は絶賛改善中のため、まだ導入はしていません。ある程度 UI 設計の軸が固まった段階で改めて整理したいとおもっています。 UI の方針を定義することの重要性 私自身これまで Web サービスをいくつも手がけてきましたが、カルテのデザインほど UI に悩まされた経験はありませんでした。 これまで見てきた電子カルテは機能毎にいくつものポップアップが表示されたり、深い階層を辿ったりするため、かなり独自の UI になっているように思えました。さらに、医療機関によって個別にカスタマイズされていることが多く、裏をかえせば UI のあるべき姿の方針が開発側ではなく、ユーザである医療機関側に委ねられているように思えました。実際に医療機関にヒアリングをしても、UI へのこだわりを持っている方が多い印象を受けました。 こうなると、電子カルテを使っている医師は職場を変わる度に新しい電子カルテの使い方を学びなおすということになります。また、医療機関間で情報連携しようと思った時も、データの保管形式などにバラツキが出てしまいます。 そこで CLINICS カルテでは、開発者側が UI 方針をしっかり定義し一貫性をもった操作性を提供することが診療効率の改善にもつながると考え、UI 開発を重要視しています。 カスタマイズに慣れている医療機関からすると、こうしてプロダクト側から UI を提示されることは珍しいことだと思います。しかしカスタマイズをしない分、UI の良し悪しが導入の判断を左右するという自負を持ちながら、どのような UI が最適なのかを日々模索し続けています。 見た目的には問題なくても、触ってみるとクリック数が多くなってしまったり、適切な導線設計をしたつもりが逆にユーザーを迷わせる導線になってしまったりと、機能ひとつとっても「作る → 検証 → 改善」の工程を幾度となく繰り返しながら、使い勝手向上と機能の両立を目指しています。右脳と左脳が行き来するため脳内キャッチボールが発生し、疲弊することもしばしばありましたが、その分想いの強いプロダクトとしてリリースできたことはデザイナーをしていてもなかなか巡り合うことのできない貴重な経験を得られたと思っています。 上流工程としてだけでなく運用フェーズのデザインの重要性 プロダクトに携わるデザイナーの役割がどんどん幅広くなってきている昨今、広範囲でプロダクトに携わらないと、本質を捉えたデザインができず、プロダクトの方向に迷いが生じてしまうことになるので、全体像を理解したうえでデザインにどう落とし込んで行くかが重要になってきます。 デザイナーは上流工程だけでなく、システムがどういう設計で成り立っているのか踏まえ、実運用も理解することで、今後の改善やアイデアに活かせると思います。 どこが課題でどれを優先して開発するかなどもデザインする上で重要で、それも踏まえて企画検討することがプロダクトとして良いものにできるかどうかに影響します。 上流だけでは結局のところ表面的な部分だけの品質を重視してしまいがちですが、全体像を捉えることがプロダクト品質を底上げするようにしていくことの大切さを、このプロダクト開発に携わることで学ばせてもらっています。 まとめ すでに実際にご利用いただいてる医療機関もあり、実運用からのフィードバックを経て日々進化している CLINICS カルテ。まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務の課題解決をしていきます。 実際に CLINICS カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！
こんにちは。プレスリリースや前回の平山のブログでも紹介がありました、患者とつながるクラウド型電子カルテ「 CLINICS カルテ 」のデザインを担当しているマエダです。 この電子カルテは、医療情報という複雑かつ独特なデータを扱うため、これまで自分自身が取り組んで来たような Web サービスとは違ったデザインのアプローチが必要でした。 今回は、そんなデザイナーの苦悩と葛藤についてお話します。医療に限らず、複雑な業務フローの業界でデザインに悩む人のお役に立てれば嬉しいです。 デザインに取り掛かる前の準備 CLINICS カルテは「日医標準レセプトソフト（ORCA）」を完全内包しているカルテなのですが、医療にかなり詳しい人でないと、「レセプトソフトって？」というところから疑問ですよね。 自分も同様で、レセプト？オーダー？DO 処方？…など医療の用語がわからない状態だったので、医療知識の理解や業務フローなどを知るところからプロジェクトに入り始めました。 デザイン業務を行う前に、医療事務の書籍を読んだり、医療事務がどのようにレセプト業務を行っているのかを学ぶことで、どのような UI が適しているかなど掴んでいきました。 ちなみに、皆さんが医療機関で受診した時に診療費の一部負担して支払われると思いますが（よく「3 割負担」など聞くこともあるかもしれません）残りの診療費については、 加入している医療保険の保険者（健康保険組合など）が支払います。 この診療費の請求のために発行する明細を診療報酬明細書（レセプト） といい、レセプトを作成し診療報酬を請求する業務のことをレセプト業務と言います。 そのレセプトを作成するための専用システムを「レセプトソフト」と言いますが、数あるレセプトソフトの中でも、日本医師会がオープンにして提供している「日医標準レセプトソフト（ORCA）」を、CLINICS カルテは内包しています。 実際に ORCA を使ってみると、レセプト業務を知らない初心者には難易度が高い操作性に戸惑い、ウェブデザイン歴 14 年のマエダも機能ひとつひとつ理解するのに苦しめられました。 Web サービスの管理ツールの利用に慣れていると、操作順序だったりボタンをクリックした後の挙動についてある程度予測できるのですが、ORCA はぜんぜん予測できない…。 そんなときに大活躍したのが、超大作 1400 ページ程もある ORCA の操作マニュアル。人生でこんなに読み込んだマニュアルはないと断言できるほど、カルテをデザインした際に大変重宝しました。 最初は操作に非常に大変でしたが、業務フローを理解したうえで、操作に慣れてくると ORCA の UI が請求業務をする上で理にかなっていることも理解できて、UI の奥深さにあらためて気付かされました。 ORCA は実際にダウンロードして試してみることができるので、興味のある方はぜひ触ってみてはいかがでしょうか。 ORCA 日レセクライアント： https://www.orca.med.or.jp/receip t/download/java-client/ ORCA 操作マニュアル： https://manual.orca.med.or.jp/5.0/html/ また、医療機関にカルテ入力〜会計処理までのフローのヒアリングなども行い、カルテのデザインをする上での前提知識を蓄えたり、既存カルテの課題なども整理することで、CLINICS カルテをどのようなデザインにしていくか、徐々に UI 方針を固めていきました。 ようやくデザインへのアプローチのお話 さて、ここまできてやっとデザインについての話です。 昨今の Web デザインはワイヤーを引いて、モックを Sketch 等のデザインツールで制作し、動作検証するためにプロトタイピングツールで触れるようにした後、システム実装に取り掛かるというのが一般的だと思います。しかし、カルテは画面ごとに細かい機能がたくさんあり、それぞれの機能についてデザインして、プロトタイピングして…という一連の作業を行うとデザイン業務だけで恐ろしいほどの工数がかかるのが目にみえてました。 そこで私は、デザインに取り掛かるアプローチを普段と変えてみることにしました。 デザインするけどデザインツールは使わない カルテはほぼコーディングだけでデザインしました。俗にいうインブラウザコーディングというやつでしょうか。 これによりワイヤー → デザインツール → プロトタイピングという、一連の工程を大幅に短縮して開発することができました。 カルテが動作する開発環境のほかに UI デザイン用の環境があります。UI デザインの環境でコーディングした HTML/CSS ファイルを開発環境に移植することができるため、エンジニアは UI 実装する手間も大幅に削減でき、システム開発に専念することができたのもよかった点です。 またインタラクションも CSS で制御するようにしたため、動作の部分もデザイナー自身の思い描いたイメージに合うように調整できたので、制限もあるプロトタイピングツールを使うよりも実際の挙動に近いかたちで検証できたこともメリットでした。 ちなみに 以前にマエダが書いた記事 として CLINICS アプリでデザイン言語システムを導入した事をお伝えしましたが、CLINICS カルテの UI は絶賛改善中のため、まだ導入はしていません。ある程度 UI 設計の軸が固まった段階で改めて整理したいとおもっています。 UI の方針を定義することの重要性 私自身これまで Web サービスをいくつも手がけてきましたが、カルテのデザインほど UI に悩まされた経験はありませんでした。 これまで見てきた電子カルテは機能毎にいくつものポップアップが表示されたり、深い階層を辿ったりするため、かなり独自の UI になっているように思えました。さらに、医療機関によって個別にカスタマイズされていることが多く、裏をかえせば UI のあるべき姿の方針が開発側ではなく、ユーザである医療機関側に委ねられているように思えました。実際に医療機関にヒアリングをしても、UI へのこだわりを持っている方が多い印象を受けました。 こうなると、電子カルテを使っている医師は職場を変わる度に新しい電子カルテの使い方を学びなおすということになります。また、医療機関間で情報連携しようと思った時も、データの保管形式などにバラツキが出てしまいます。 そこで CLINICS カルテでは、開発者側が UI 方針をしっかり定義し一貫性をもった操作性を提供することが診療効率の改善にもつながると考え、UI 開発を重要視しています。 カスタマイズに慣れている医療機関からすると、こうしてプロダクト側から UI を提示されることは珍しいことだと思います。しかしカスタマイズをしない分、UI の良し悪しが導入の判断を左右するという自負を持ちながら、どのような UI が最適なのかを日々模索し続けています。 見た目的には問題なくても、触ってみるとクリック数が多くなってしまったり、適切な導線設計をしたつもりが逆にユーザーを迷わせる導線になってしまったりと、機能ひとつとっても「作る → 検証 → 改善」の工程を幾度となく繰り返しながら、使い勝手向上と機能の両立を目指しています。右脳と左脳が行き来するため脳内キャッチボールが発生し、疲弊することもしばしばありましたが、その分想いの強いプロダクトとしてリリースできたことはデザイナーをしていてもなかなか巡り合うことのできない貴重な経験を得られたと思っています。 上流工程としてだけでなく運用フェーズのデザインの重要性 プロダクトに携わるデザイナーの役割がどんどん幅広くなってきている昨今、広範囲でプロダクトに携わらないと、本質を捉えたデザインができず、プロダクトの方向に迷いが生じてしまうことになるので、全体像を理解したうえでデザインにどう落とし込んで行くかが重要になってきます。 デザイナーは上流工程だけでなく、システムがどういう設計で成り立っているのか踏まえ、実運用も理解することで、今後の改善やアイデアに活かせると思います。 どこが課題でどれを優先して開発するかなどもデザインする上で重要で、それも踏まえて企画検討することがプロダクトとして良いものにできるかどうかに影響します。 上流だけでは結局のところ表面的な部分だけの品質を重視してしまいがちですが、全体像を捉えることがプロダクト品質を底上げするようにしていくことの大切さを、このプロダクト開発に携わることで学ばせてもらっています。 まとめ すでに実際にご利用いただいてる医療機関もあり、実運用からのフィードバックを経て日々進化している CLINICS カルテ。まだまだプロダクトとして未成熟な段階ではありますが、「医療の課題を解決する」ため、CLINICS カルテでは医療業務の課題解決をしていきます。 実際に CLINICS カルテを利用する方は医療機関の方に限られてしまうのですが、興味のあるデザイナー・エンジニア・ディレクターの方はぜひこちらまでご応募おまちしております。 www.medley.jp 次回は CLINICS カルテのエンジニア兼飲み友の苦悩と葛藤について発表いたしますので、ご期待ください！