こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 https://www.medley.jp/team/creator-story-incubation.html さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 https://www.medley.jp/team/creator-story-incubation.html さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、インキュベーション本部でエンジニアをしています世嘉良です。 インキュベーション本部は 2020 年 2 月から新規事業の開拓などを目的に新設されたのですが、その中でも若手の部類として日々頑張っています。 CTO 平山のインタビューとともにインキュベーションチームの紹介記事が、コーポレートサイトに掲載されています。こちらもぜひご覧ください。 www.medley.jp www.medley.jp さて、今回は社内で行っている勉強会：テックランチの中で「Kotlin/Native」について発表する機会があったので紹介させていただきます。 Kotlin/Native について Kotlin は JetBrains 社によって 2011 年に発表されたプログラミング言語です。 現在では Android 開発などで主流の言語となっており、多くの人に利用されていると思います。 Kotlin/Native とはそんな Kotlin を使って様々なプラットフォーム上で実行可能なファイルを生成しようというプロジェクトです。 Kotlin/Native - Kotlin Programming Language 仕組みとしては Kotlin のコードをもとに LLVM を生成し、それを様々なプラットフォームで利用可能なネイティブバイナリにコンパイルすることで追加のランタイムや JVM なしで動作するようにしています。 サポートしているプラットフォームは下記のとおりです。 iOS (arm32, arm64, simulator x86_64) macOS (x86_64) watchOS (arm32, arm64, x86) tvOS (arm64, x86_64) Android (arm32, arm64, x86, x86_64) Windows (mingw x86_64, x86) Linux (x86_64, arm32, arm64, MIPS, MIPS little endian) WebAssembly (wasm32) コードの共通化について Kotlin/Native のチュートリアルを参考に、Android / iOS で共通化の流れを追ってみます。 作成されるプロジェクトは Android / iOS でそれぞれ “Hello, World!” を出力するシンプルなプログラムです。 Kotlin Playground: Edit, Run, Share Kotlin Code Online 通常のプロジェクトとは別に SharedCode というプロジェクトを作成し、この中に Kotlin/Native (Android / iOS 共通のコード) を記述していきます。 それぞれのコードのレイアウトは以下の通りです。 ※ SharedCode を読み込むためのマルチプラットフォームのための gradle ファイルも必要で、先程のウェブサイトに記載されています。 commonMain の中に 「expect」 というキーワードを使って抽象型のようなものを宣言し、 androidMain / iOSMain といった各プラットフォームの実装の中で 「actual」 というキーワードを使用してその内容を記述します。 // commonMain expect fun platformName (): String // androidMain actual fun platformName (): String { return "Android" } // iOSMain actual fun platformName (): String { return UIDevice.currentDevice. systemName () + " " + UIDevice.currentDevice.systemVersion } このチュートリアルには記載ありませんが、「expect」 というキーワードはクラスや関数・アノテーションといったすべてのものに定義することができます。 Platform-Specific Declarations - Kotlin Programming Language また iOSMain 内であれば iOS の Foundation フレームワークといったように、各プラットフォームごとのフレームワークもそれぞれ利用することができます。 こうしてできた、SharedCode のライブラリは Android/iOS のプロジェクトから使い慣れたライブラリと同じようにインポートすることができます。 Kotlin/Native の制約について JVM 上で Kotlin を動かしていた時には標準ライブラリやメモリ管理には Java の資産を利用することができましたが、Kotlin/Native ではそれを利用することができないという制約があります。 具体的にアプリを作成する際には下記の点に注意が必要でした。 Java の標準ライブラリを使用しているライブラリを利用できないため Kotlin で記述されたライブラリのみが使用する iOS アプリを開発する際には memScope, alloc / free などを利用してメモリ管理を自分で行う必要がある Java の資産が利用できない Kotlin に対して心配することもありましたが、Kotlin/Native 向けに様々なライブラリが 提供されておりそれらを利用することで問題を解決しました。 現状は日付管理ですらサードパーティ製のライブラリで操作する必要があるのが不満ですが、Kotlin/Native の発展によってこういった不便さは解決されるように願っています。 「suspend」 関数を iOS 側から直接呼び出すことができない (コールバック関数やなどに変換して呼び出す必要がある) Kotlin で定義した宣言や型の一部が Swift だと別名になっている (「 objc_runtime_name」 や 「swift_name」 を参照する必要がある) 「companion object」 や 「object」 などシングルトンの宣言に対してオブジェクトをフリーズするか 「ThreadLocal / SharedImmutable」 のアノテーションを付与する必要がある こちらは iOS で利用する場合の注意ですが、いくつかの Kotlin の機能が利用できなかったり、追加の記述が必要なものがあります。 詳しくは下記の資料を参照ください。 Kotlin/Native as an Apple Framework - Kotlin Programming Language kotlin-native/IMMUTABILITY.md Kotlin/Native の利用例 まだまだ利用例が少ないため参考になる資料などがあまりないのですが、以下の実装がオープンソースとして公開されているため構成や雰囲気を掴むためにはちょうど良い資料となりました。 GitHub - JetBrains/kotlinconf-app: KotlinConf Schedule Application GitHub - DroidKaigi/conference-app-2020: The Official Conference App for DroidKaigi 2020 Tokyo まとめ 弊社では 「CLINICS」 というオンライン診察を行うことができるアプリをリリースしています。 CLINICS を長期的に運用していくための技術調査の一環として、近年の Android 界隈で話題にあがっていた「Kotlin/Native」について検証し発表してみました。 まだまだ発展途上感のある技術ですが、実用性のあるプロジェクトだと思いますのでご興味のある方はぜひ一度お試しください！

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

こんにちは、メドレープロダクト開発室 エンジニアの岸田です。 先日、社内勉強会 TechLunch にて、弊社の提供する医療介護分野の人材プラットフォーム「ジョブメドレー」の開発で利用している CircleCI での CI/CD についての取り組みを発表しましたので、紹介させていただきたいと思います。 ジョブメドレーの開発で CircleCI をどのように利用しているか ジョブメドレーの開発では、主に次の 2 つを CircleCI を用いて行なっています。 ユニットテスト・構文チェック デプロイ デプロイに関しては、ECS 環境と EC2 環境への 2 通りのデプロイを CircleCI を利用して行なっています。 そのため CircleCI の Workflow は「ユニットテスト・構文チェック」「EC2 へのデプロイ」「ECS へのデプロイ」の 3 つに分かれています。 3 つの Workflow を大まかに説明させていただきます。 ユニットテスト・構文チェック ジョブメドレーは主にサーバサイドを Ruby on Rails、フロントエンドを React を使って開発をしています。 そのためユニットテストには RSpec ・ Jest を、構文チェックには Rubocop と ESLint 利用しています。 この Workflow は 3 つのジョブで構成されています。 ライブラリのインストール bundle install ・ yarn install などを行い、ユニットテスト・構文チェックの実行に必要な依存ライブラリをインストールし、CircleCI のキャッシュ機能を用いてキャッシュを行なっています RSpec の実行 2 コンテナを利用しての並列実行を行なっています 構文チェックと Jest の実行 RSpec と比較して Jest でのテストコードはボリュームが少なく・実行時間が短いため、構文チェックと一緒に 1 つのジョブにしています この Workflow はどのブランチでも GitHub へ Push が行われるたびに実行されるようにしています。 EC2 へのデプロイ この Workflow ではデプロイを行うための準備と、文字通り EC2 へのデプロイを行なっています。 デプロイには Ruby gem の Capistrano を利用しています。 下記のような 2 つのジョブで構成しています。 ライブラリのインストール 前述のユニットテスト・構文チェックの Workflow の 1 つ目と同じ役割です ビルドとデプロイ Rails の assets:precompile や yarn build などの処理と、Capistrano を用いたデプロイを行なっています この Workflow は特定のブランチでしか実行されないようになっています。 ECS へのデプロイ この Workflow では ECS へデプロイするための Docker image 作成とそのためのビルドなどを行なっています。 ジョブは下記のように 4 つで構成されています。 npm package のインストール フロントエンドのビルド Gem のインストールと Rails の assets:precompile Docker image の作成と Push こちらの Workflow も特定のブランチでしか実行されないようになっています。 抱えていた課題と assets:precompile ジョブメドレーの開発では CircleCI の各ジョブが全て正常に完了することを PR をマージする条件の 1 つにしています。 しかし各 Workflow ・ジョブの実行時間が長く、ジョブの実行待ちをしなければいけないという状況がよく起こってしまっていました。 特に時間がかかっていたのが、下記の 3 つでした。 「EC2 へのデプロイ」Workflow の「デプロイ」ジョブ 「ECS へのデプロイ」Workflow の「Gem のインストールと Rails の asset_precompile」ジョブ 「RSpec の実行」ジョブ RSpec の書き方などを改善することで短縮できるため、割愛させていただきます これらについて調査したところ、1・ 2 は、assets:precompile が主に時間を使っていることが分かりました。 この点について原因と行なった改善を説明をさせていただこうと思います。 assets:precompile に時間がかかる ジョブメドレーでは Rails のアセットパイプラインを利用して、アセットファイルのコンパイル・最小化などを行なっています。 これを実行する際に assets:precompile コマンドを利用しています。 また、同コマンド実行時にコンパイルしたファイルを AWS S3 バケットにアップロードするために asset_sync gem を利用しています。 このコマンドの実行には 9 分から 10 分ほどの時間がかかっており、下記の 2 つの原因で遅くなっていました。 毎回 1 からコンパイルを行なっていた コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する 毎回 1 からコンパイルを行なっていた こちらについては読んで字のごとくですが、デプロイ Workflow が実行されるたびにアセットファイルの変更有無に関わらず、毎回 3 分ほどを費やして全てのアセットファイルをコンパイル・最小化していました。 こちらの解決策としては、 CircleCI の公式ドキュメントでも例が載せられています が、 assets:precompile コマンドで生成されるファイルが置かれるディレクトリ（ public/assets ）を CircleCI でキャッシュさせることで対応しました。 キャッシュさせることで、毎回 3 分ほどかかっていた処理を 1 分ほどに短縮することができました。 コンパイル後のファイルをアップロードする S3 バケットに大量のファイルが存在する こちらついてはもう少し背景が複雑かつ、まだ解決まではできていません。 まず asset_sync を利用したファイルのアップロード処理ですが、毎回 6 分以上の時間がかかっていました。 CircleCI のログをよくよく見てみるとアップロード自体に時間がかかっているのではなく、「どのファイルをアップロードすべきか」を判断する処理に多くの時間を費やしていることが分かりました。 （1 ファイルもアップロードしていないが 6 分 20 秒かかっている） そこで、 asset_sync gem のソースコードを読んでみると、「アップロード先の S3 バケットにあるファイルを全て取得し、 assets:precompile コマンドが生成したファイルのファイル名と比較する」という処理がありました。 この処理が怪しいのではないかと思い、S3 バケットを確認してみたところ数十万件以上のファイルが存在することが分かりました。 数十万件以上のファイルの情報を取得していることを考えると 6 分以上時間がかかるのも納得です。 この問題の解決策は下記の 2 つが考え得ると考えました。 不要なファイルを S3 バケットから削除する 前回のデプロイとの比較をして S3 にアクセスせずにアップロードすべきファイルかどうかを判断するようにする 1 つ目の方法は正攻法で、数十万ファイルを全て使っているわけではないため利用されていないファイルを削除してしまう方法です。 asset_sync も早くなり、S3 の利用料も少なくなるためこの方法を取れるのであれば、この方法で解決するのが良いように思います。 ジョブメドレーでもこの方法を取れないかと検討しましたが、ジョブメドレーから配信している HTML メールなどでも利用しているファイルがあるため一概にアクセスされていないからといって削除することができず、この方法での解決は一旦断念しました。 2 つ目の方法は assets:precompile コマンドが生成する manifest ファイル（生成したファイルのリストなどが記述されている）と CircleCI のキャッシュ機能を使って短縮する方法です。 manifest ファイルは、コンパイル後のアセットファイルが出力されるディレクトリ（ public/assets/ ）に同じように出力され、また、上記で public/assets を CircleCI のキャッシュ機能でキャッシュするようにしたため、manifest ファイルも一緒にキャッシュされるようになっています。 assets:precompile の実行により今回作成された manifest ファイルと、キャッシュされていた manifest ファイルを比較して差分が出たファイルだけを S3 にアップロードするようにしようという試みです。 この処理は asset_sync gem ではできそうになかったので、シェルスクリプトと Rake タスクを作成して実行してみたところ、「アップロードすべきファイルかどうか」を判断するための時間がほぼなくなり、6 分以上の短縮をすることができました。 ただし検証が不十分なため、実運用に乗せることはまだできていません。 CircleCI のジョブ実行時間を短縮する小さな改善事項 上述の通り、各 Workflow で大きく時間を費やしているのは assets:precompile と RSpec の実行でしたが、細かな点としては他にも小さい改善をしたことがあります。 コードのチェックアウト CircleCI では組み込みのコマンドとして checkout コマンドがあります。 これは対象のリポジトリのブランチをクローンしてくれるコマンドですが、ジョブメドレーはモノレポに近い構成になっており、コードベースのサイズや履歴が大きいためクローンするだけである程度の時間がかかってしまっています。 そこでまずは、 .git ディレクトリを CircleCI のキャッシュ機能を利用してキャッシュするようにしてみました。 すると、 checkout コマンド自体は大きく短縮しましたが、キャッシュの save/restore に短縮した以上の時間がかかるようになってしまいました。 別の方法として checkout コマンドを利用せずに、Git の Shallow clone や Sparse clone を駆使して必要なファイルや履歴だけをクローンするということができます。 現在は Sparse clone を一部導入してみており、Shallow clone も導入したいと考えています。 Docker image の作成 ジョブメドレーでは ECS へのデプロイの際に CircleCI 上で Docker image をビルドしているため、 docker build コマンドの実行時間も可能な限り抑えたいと考えています。 短縮する方法は様々あるかと思いますが、CircleCI 上でも Dokcer Buildkit を利用することがきますので、それを利用してビルドすることで簡単に短縮することができます。 詳しくは Docker のガイド に記載の通りではありますが、DOCKER_BUILDKIT=1 を指定して docker build を実行するだけで利用することができ、ジョブメドレーでは 2 分ほどかかっていたビルドを 40 秒ほど短縮することができました。 まとめ 今回は、TechLunch で発表したジョブメドレーにおける CircleCI の活用と改善の取り組みについて紹介させていただきました。 今回紹介させていただいた以外にも様々な用途があり、今後もさらにうまく活用していきたいと思っています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry https://sentry.io/ 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel https://mackerel.io/ja/ GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda https://aws.amazon.com/jp/cloudwatch/ https://aws.amazon.com/jp/lambda/ どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic https://newrelic.co.jp/ New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics https://firebase.google.com/?hl=ja Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 https://ja.pagerduty.com/ CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。

皆様こんにちは。 プロダクト開発室 エンジニアの濱中です。 新型コロナウイルス感染症が猛威を振るっておりますが、皆様いかがお過ごしでしょうか。先日の緊急事態宣言を受けて、メドレーも全社員が原則リモートで業務に当たっています。オンライン医療事典「MEDLEY」にも、 コロナウイルス関連の特集 が組まれていますのでぜひご覧ください。 さて先日、社内勉強会 TechLunch にて、弊社の提供するクラウド診療支援システム「CLINICS」のサービス運営で使われている監視ツール群について発表したので、ご紹介させていただきます。 CLINICS の概要と、サービスにおける監視の立ち位置について 公式ページ で「クラウド診療支援システム」と銘打っている CLINICS ですが、より詳細には、電子カルテシステム・オンライン予約システムも提供しています。これら予約・診療・カルテの 3 プロダクトで医療現場の業務を一手に引き受けることを目的としたサービスが CLINICS です。 このうち、電子カルテシステムは、「 日医標準レセプトソフト ORCA 」という製品を内包する形で提供しており、ORCA 自体は独立した環境で動作しています。 当然ながら、ORCA 自体が CLINICS とは独立した 1 プロダクトであるため、CLINICS 側に問題がなくても ORCA サーバがパフォーマンス低下や不具合を起こしてしまったり、あるいは CLINICS の web サーバとの通信がうまくいかなくなるケースも考えられます。 電子カルテシステムは医療機関の診察・会計といった日常業務の重要なパートを担っており、ここで障害が発生すると業務が止まってしまいます（最悪、患者さんをお待たせしてしまうこともあります）。 そのため、業務に大きな影響を与える箇所を中心に、複数の監視ツールでアプリケーションの動作状況をチェックしています。 監視ツールあれこれ ここからは実際に CLINICS で利用しているツールを簡潔にご紹介していきます。 Sentry Application Performance Monitoring & Error Tracking Software Application performance monitoring for developers & software teams to see errors clearer, solve issues faster & continue learning continuously. sentry.io 弊社の他プロダクト（「 ジョブメドレー 」、「 介護のほんね 」）でも利用している監視ツールです。 基本的には、アプリケーションで例外が発生すると自動でアラートを投げてくれますが、アプリケーション側で catch してしまうものや、例外ではないが通知したいイベントについて、任意にアラートをあげることも可能です。 CLINICS では例えばアカウント ID やアクセスした API エンドポイント・パラメータなど渡して、エラー調査に活用しています。 Mackerel Mackerel（マカレル）: 始めやすくて奥深い、可観測性プラットフォーム Mackerel(マカレル)は誰でも簡単に始めやすく奥深い可観測性プラットフォーム。運用をイージーにするオブザーバビリティを高め、未知の問題に立ち向かう開発者に力を与えます。サーバー監視をMackerelではじめてみませんか？無料プランや2週間のトライアルもあります。 mackerel.io GUI で簡単に監視設定が可能なサービスです。 前職で使っていた時は GUI でできるところまでしか触っていなかったのですが、設定ファイルを手製すれば、自作スクリプトの出力をチェックしたり、チェックに失敗した時何か処理をしたり…といったマニュアルな監視も可能です。 現在 CLINICS においては、ORCA インスタンスがそれぞれ独立して動作していますが、Mackerel ではこの ORCA インスタンスを監視しています。また監視するだけでなく、動作不良を起こした時の再起動処理なども担当しています。 AWS CloudWatch & Lambda Amazon CloudWatch（リソースとアプリケーションの監視と管理）| AWS Amazon CloudWatch は、AWS リソースと AWS で実行するアプリケーションのモニタリングサービスです。様々なメトリクスやログを収集・追跡することで、システム全体のリソース使用率、アプリケーションパフォーマンス、およびオペレーションの状態について可視化することができます。 aws.amazon.com AWS Lambda（イベント発生時にコードを実行）| AWS AWS Lambda を使用すれば、サーバーのプロビジョニングや管理なしでコードを実行できます。課金は実際に使用したコンピューティング時間に対してのみ発生し、コードが実行されていないときには料金も発生しません。 aws.amazon.com どちらも AWS の提供するツールです。 CloudWatch は主にログの記録と監視を行うためのツールです。複数の機能がありますが、CLINICS では主に Logs, Metrics, Alarm を使用しています。 Logs はその名の通り、主に AWS のツールが発行するログを収集・検索・閲覧する機能で、問題発生時の HTTP リクエストのパラメータを確認する時などに利用しています。 Metrics は、「プロダクト（EC2 ならインスタンス, RDS なら DB インスタンスなど製品の一単位）」×「メトリクス種別（CPU 利用率など）」を一単位として、統計情報を可視化するツールです。 それらに閾値を設け、超えた場合にアラートを発行するのが Alarm…という位置付けです。 対して Lambda は、そもそも監視ツールではありません。定期実行、あるいは何かのイベント（S3 に何かアップロードされた、など）をトリガーとして、処理を行うツールです。処理した結果を、さらに別のツールへ連携（Slack 通知などの外部連携も含む）させることも可能です。 CLINICS では、上記アラート通知のほか、 SessionManager 経由でインスタンスに ssh ログインした時の通知や、時間のかかるインポートタスクなどが終了した時の通知などにも利用しています。 New Relic スタック全体をモニタリング、デバッグ、改善 登録は無料、クレジットカードは不要です。New Relic Oneとクイックスタートでインスタントオブザーバビリティを手に入れれば、インストゥルメントを数クリックで実行できるようになります。 newrelic.co.jp New Relic は、CLINICS ではパフォーマンス評価ツールとして利用しています。 メインとなるのは APM(Application Performance Monitoring)で、アプリケーション内のどの処理にどれだけ時間がかかったかなどを閲覧することができます。 医療機関は時間によって診察ペースが大きく変わるため、1 回 1 回は少しの遅延であっても、業務フローのコアな部分に絡んでいる場合、遅延が響いてくることはあります。 このような、「エラーは出ないけど、レスポンスが遅い」というご連絡を受けた時の調査・メンテナンスに主に活躍してくれます。 Sentry のようにエラー検知を行なったりもでき、ツール自体の多機能さから取得できる情報の多さが段違いといった印象です。 Firebase Crashlytics Firebase | Google's Mobile and Web App Development Platform Firebase は、デベロッパーがユーザーに人気のアプリやゲームを開発できるよう支援する Google のモバイルおよびウェブアプリ開発プラットフォームです。 firebase.google.com Firebase もまた”多機能な”ツールですが、CLINICS では監視機能として Crashlytics を使っています。 CLINICS では、患者さんが予約・オンライン診療を行うためのアプリを iOS / Android で公開しており、医療機関向けの Web アプリケーション側と連携して動作します。このネイティブアプリで発生したクラッシュを集計しているのが Crashlytics です。 Android の場合は build.gradle に設定を追記してアプリをビルド、iOS の場合は cocoapods で外部ライブラリとしてインストールすることで集計が可能になります。Unity アプリにも対応しているとのことです。 その他、監視ではないですがアプリを利用している端末や OS バージョンなどの統計情報の収集も可能です。 PagerDuty による監視集約 PagerDuty｜インシデント管理プラットフォーム｜PagerDuty株式会社 PagerDuty（ペイジャーデューティ）はシステムのインシデント対応を一元化するプラットフォームです。DX時代におけるオペレーショナル・レジリエンスを高め、障害対応に費やす時間を軽減することで、貴重なエンジニアリソースをビジネス拡大に充てることができます。 ja.pagerduty.com CLINICS ではここまでに挙げてきたツールを使って監視を行っておりますが、昨年、複数の監視ソースからのアラートを一本化すべく、インシデント管理サービス PagerDuty を導入しました。 導入後は、全てのアラートツールはアラートを一旦 PagerDuty に集約し、PagerDuty から Slack 通知を行うという形式になりました。 また、PagerDuty が出すアラートは、担当者が確認してレスポンスを返す（acknowledge）ことを行わずに一定時間が過ぎた場合、電話や SMS での通知へ展開していくように設定することができます。これによって、クリティカルなエラーの見落としを確実に防げるようになりました。 まとめ CLINICS で利用している監視ツール+α を紹介させていただきました。 これらのツールを駆使しながら、ユーザの皆様に安心してお使いいただけるようサービスの安定稼動に尽力しています。 ご覧いただきありがとうございました。