DeSCヘルスケアにおけるGo 活用事例紹介 #DeNAgo

DeSCヘルスケアでのGoの活用事例の紹介になります

Transcript

1. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. DeSCヘルスケアにおけるGo 活用事例の紹介 DeNA.go #2 July 18, 2019 栗田佳祐 DeSC Healthcare Inc. && DeNA Life Science Inc. 1
2. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. 自己紹介 ▪ 栗田佳祐 ▪ サーバーサイドエンジニア ▪ 2012〜2015：ブラウザゲーム ▪ 2015〜現在：DeSCヘルスケア ⁃ 2015.10-2017.10：KenCoM (後述) のサービス開発 ⁃ 現在：利用することでユーザーの健康を促進する新規サービスを開発中 ▪ @kurikei 2
3. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. アジェンダ ▪ 自己紹介 ▪ ヘルスケア事業部の紹介 ⁃ ミッション ⁃ サービス ▪ アーキテクチャとディレクトリ構成 ▪ レイヤードアーキテクチャとDIの利用ケースの紹介 ▪ 暗号化の手法と透過的に行うための仕組みの紹介 3
4. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. ヘルスケア事業部のミッション 4 https://healthcare.dena.com/
5. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. ヘルスケアのサービス紹介 5
6. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. 技術概要 ▪ これらのサービスを利用している前提でお話します ⁃ Google Cloud Platform • Google App Engine(GAE) ⁃ Go 1.11 • Cloud Firestore • Cloud Functions ⁃ Firestoreの作成/更新イベントをトリガーして非同期処理を行う ⁃ CircleCI ⁃ OpenAPI 3 6
7. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. アーキテクチャとディレクトリ構成 ▪ レイヤードアーキテクチャ(+DIP)を採用 ▪ ディレクトリ構成 src/app └ application └ domain │└ user │　└ user.go │　└ repository.go └ infrastructure │└ firestore │　└ user_repository.go └ interface │ └config・・・設定の定数など └ lib ・・・どのレイヤーからも呼ばれる処理（ログなど） 7 infrastructure domain application interface レイヤーの依存関係
8. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. ▪ レイヤードアーキテクチャとDIの利用ケースの紹介 8
9. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. domainでインターフェイスを定義し、infrastructure層の具体的実装をDI 9 domainではインターフェイスを定義 ・infrastructure/firestore/user_repository.go ・di.go ・domain/user/repository.go infrastructureでは具体的な処理を記載
10. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. 変更が見込まれるライブラリもDIで差し替え可能な状態にしておく ▪ GoogleAppEngine/Go 1.12では appengine パッケージが利用不可になる ⁃ 代替コストの大きいものは引き続きappengineパッケージを利用しつつも、いつでも差し替えられる準 備はしておく 10 抽象層を定義 具体的な実装（変更の可能性のあるパッケージに依存） DI を行う。具体的な実装が変わる場合はここで差し替える
11. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. ▪ 暗号化の手法と透過的に行うための仕組みの紹介 11
12. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. レイヤードアーキテクチャ(+DI)を採用するメリット ▪ レイヤードアーキテクチャを採用することでメリットは大きい ⁃ 関心事が分離できる ⁃ レイヤーごとに変更のライフサイクルは異なる • domain層はしばしば機能要件によって変わる • infrastructure層は外部要因によって変更を余儀なくされる ⁃ あるレイヤーの変更時に別のレイヤーの変更がいらなくなる 12
13. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. レイヤードアーキテクチャを採用する際の課題と向き合う ▪ 一方で、シンプルなAPIの実装でもコード差分が大きくなりやすい ⁃ どうしても各レイヤーで関数を定義する必要がある ⁃ コード差分が大きくなると必然的に書くテストが増える ▪ gomock を利用してテスト中ではmockをDIすることで、レイヤーの最小限の責務のみテ ストを書く ⁃ DBにデータからデータが取得できる/正しく保存されてるかはテストするのはinfrastructure層のみ ⁃ その他のレイヤーは主に下記のテストする • interface層・・・レスポンスコードやレスポンス形式のみテスト • application層・・・ドメインが返すエラーに応じて、interfaceそうに適切なエラーを伝播させる • domain層・・・ドメインロジックそのもののテスト ▪ gotests コマンドでテストの雛形生成 13
14. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. 透過的な処理を行うメソッドを挟み込む ▪ DBの取得時/保存時に透過的に処理を行う関数を挟む ⁃ Google Cloud Datastoreを利用している人には PropertyLoadSaver がおなじみ ⁃ 個人情報の暗号化/復号/タイムスタンプの更新 などをドメイン層からは意識せず確実に行う • 社内のセキュリティ規定を満たすために個人情報はカラム暗号化も行う • 暗号化にはエンベロープ暗号（後述）を用いている 14
15. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. 透過的な処理を行うメソッドを挟み込む 15 infrastructure層にEntityを定義 取得時に インフラ層のEntityに castする 基底メソッドはEntityインターフェイス を満たす引数を取り、取得時は LoadPropertiesを必ず呼ぶ （この中でデータの復号を行う）
16. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. エンベロープ暗号化の採用 ▪ セキュリティポリシーにより（データベースの暗号化とは別に）カラムの値の暗号化が必 要 ▪ 鍵管理にはKMSを利用 ▪ すべての値に対してKMSで復号すると、問い合わせに時間がかかる ▪ エンベロープ暗号の手法を用いる ⁃ Key Encryption Key(KEK)は KMSで管理し、アプリの初期化時にメモリ上にのみロード ⁃ 保存時（暗号化） i. カラムごとにData Encryption Key(DEK)を作成 ii. データをDEKを用いて暗号化 iii. メモリ上のKEKを用いてDEKも暗号化し、iiのデータと共に保存 ⁃ 取得時（復号） i. KEKによって暗号化されたDEKを復号 ii. 複合されたDEKを用いて、データを復号 16 エンベロープ暗号化　 https://cloud.google.com/kms/docs/envelope-encryption?hl=ja#balancing_deks_and_keks
17. Copyright (C) 2018 DeNA Co.,Ltd. All Rights Reserved. まとめ ▪ レイヤードアーキテクチャとDIを利用することで変更に強い構成にする ▪ レイヤードアーキテクチャを採用することでどうしても書かざるを得ないテストはmockや 自動生成を利用することで早くかけるようにする ▪ 守らないといけない情報は確実にまもりつつ、パフォーマンスと両立させる 17