GAE/Jで盛大に失敗する方法

Transcript

1. GAE/Jで盛大に失敗する方法
   GCPUG Okayama #11
   

   View Slide

2. 森藤　敏之（もりとう）
   - @mmorito_0318
   所属
   - 株式会社エムネス
   - 遠隔画像診断センター
   - 医療支援サービス「LOOKREC」
   イベント / 勉強会（担当）
   - GCPUG - 広島支部 organizer
   - Cloud Native Hiroshima
   

   View Slide

3. カープ優勝
   おめでとうございます！
   

   View Slide

4. これは、GAE/J に魅了された者たちの物語です。
   決してJavaを批判するものではないことをご理解ください。
   はじめに
   

   View Slide

5. - サーバー:
   - データベース:
   - キャッシュ:
   - その他:
   Google App Engine（Java）
   Datastore
   Memcache
   魅了された者
   登場人物
   

   View Slide

6. - GAEのJava7 Runtime が2019年1月16日にShatdownする
   - 弊社アプリケーションの完全移行が2018年11月までに完了予定
   発表のきっかけ
   

   View Slide

7. 背景
   

   View Slide

8. - 人口100万人あたりのCT/MRI 設置台数
   日本はダントツで1位 CT units per million population
   OECD Health at a Glance 2017
   MRI units per million population
   

   View Slide

9. - 人口100万人あたりの放射線科医数
   人口100万人あたりの 放射線科医数
   日本はダントツで最下位 高額医療機器（CT/MR）と放射線科医の数
   

   View Slide

10. - データの保存や移行に莫大な時間とお金がかかる
    - 超高額で囲い込みの激しい医療業界の常識を撤廃
    - 深刻な医師不足を解消するためのネットワーク作り
    - 機械学習などのIT技術を用いて、医療をサポートしたい
    クラウドへ移行する決意
    Google Cloud Platform 上で構築へ
    いつでも、どこでも、だれにでも高品質な医療を提供する
    

    View Slide

11. View Slide

12. 順調に開発が進み…
    

    View Slide

13. Googleからの取材
    2014年8月
    

    View Slide

14. あれから2年....
    我々はアプリのリプレイスを余儀なくされる。
    

    View Slide

15. なにがダメだったか
    

    View Slide

16. 失敗①　スピンアップ
    Frameworkなし :
    Slim3 :
    Slim3 + Struts(仮) :
    Slim3 + Struts(仮) + アプリ :
    約2.5s
    約3.3s（+800ms）
    約5s　（+1700ms）
    約10s （+5000ms）
    開発速度重視のため
    

    View Slide

17. - NoSQLであるDatastoreを非正規化したRDBのような使い方
    主要なKindで自動インクリメントするKeyを設定
    - KeyでGetできないため、
    シングルプロパティインデックス・カスタムインデックスを貼りまくる
    失敗②　テーブル設計
    

    View Slide

18. - Queryでデータ取得することによる弊害
    - Memcacheに載らない
    - トランザクションに引っかからない
    - Frameworkに搭載された禁断のインメモリフィルタに手を出す
    ※多めに取得してクライアントに返したいデータ以外を 捨てる
    失敗②　テーブル設計
    

    View Slide

19. - JSPの結果を返すリクエストがコンスタントに1秒を超えるようになる
    失敗③　レスポンス
    

    View Slide

20. - 一方でAjaxを使い、signedURLを数百単位で要求してくるリクエストなど
    もあるが、スケールの恩恵を受けづらくなる
    失敗③　レスポンス
    

    View Slide

21. - 軽い気持ちで30分毎に直近500件のデータを検索し、
    他のテーブルに情報を更新する処理をCronジョブで実行
    番外編　バッチ処理
    翌月の請求額が 40万円UP↑↑
    

    View Slide

22. 対応策
    

    View Slide

23. - インスタンスタイプを　F1 → F2　へスケールアップ
    愚策①　チューニング
    - インスタンスが落ちるまでの時間を　最大（15秒）に設定
    スピンアップやJavaのクラスロードに直面する
    リクエストを極力減らし、1秒でも速く処理させるため.....
    

    View Slide

24. - Memcache を　共有 → 1GB専有　に変更
    愚策②　キャッシュ
    

    View Slide

25. - アプリケーションを　単一Service → 複数Service　にデプロイ
    良策③　ディスパッチ
    業務単位毎に別のServiceへルーティングを設定
    （バッチ処理なども別Serviceへ）
    

    View Slide

26. そして、バージョン2開発へ
    

    View Slide

27. - AppEngineの言語を　 Java → Go　に変更
    - クライアントを　JSP → Angular2系（SPA）に変更
    - Datastoreの設計を見直し　インデックス数が ゼロ に
    Memcacheのヒット率もキャッシュサイズも大幅アップ　
    - Serviceを分けてデプロイ。適切な　 ディスパッチ　を設定
    バージョン2
    スピンアップが約20msに
    サーバ処理時間は200ms以内に
    基本構成　AppEngine / Datastore　は変更せず
    

    View Slide

28. View Slide

29. Googleからの取材（2回目）
    2018年6月
    

    View Slide

30. View Slide

31. - うまく動作しない、性能が出ないのは、
    だいたいクラウドサービス側よりもアプリ側に原因がある場合が多い
    - 現在は、AppEngine にも 2nd Gen が登場し、
    いろいろと過渡期のため、機能要件に応じて適切なプロダクトを
    選択していく必要がある
    - クラウドサービスならではのベストプラクティスやハマりどころ
    が存在するため、Slackとかで雑に質問してみると良いかも
    - なんにしても口座へのダメージ回避が最優先（性能改善にも繋がる）
    まとめ
    

    View Slide

32. View Slide

33. ありがとうございました
    

    View Slide