Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

mmorito
October 28, 2018

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

mmorito

October 28, 2018
Tweet

More Decks by mmorito

Other Decks in Programming

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