Pro Yearly is on sale from $80 to $50! »

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

5b1f54cf0af2f41f7c1bf93ce0f0debf?s=47 mmorito
October 28, 2018

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

5b1f54cf0af2f41f7c1bf93ce0f0debf?s=128

mmorito

October 28, 2018
Tweet

Transcript

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

  2. 森藤 敏之(もりとう) - @mmorito_0318 所属 - 株式会社エムネス - 遠隔画像診断センター - 医療支援サービス「LOOKREC」

    イベント / 勉強会(担当) - GCPUG - 広島支部 organizer - Cloud Native Hiroshima
  3. カープ優勝 おめでとうございます!

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

  5. - サーバー: - データベース: - キャッシュ: - その他: Google App

    Engine(Java) Datastore Memcache 魅了された者 登場人物
  6. - GAEのJava7 Runtime が2019年1月16日にShatdownする - 弊社アプリケーションの完全移行が2018年11月までに完了予定 発表のきっかけ

  7. 背景

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

    Health at a Glance 2017 MRI units per million population
  9. - 人口100万人あたりの放射線科医数 人口100万人あたりの 放射線科医数 日本はダントツで最下位 高額医療機器(CT/MR)と放射線科医の数

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

    Cloud Platform 上で構築へ いつでも、どこでも、だれにでも高品質な医療を提供する
  11. None
  12. 順調に開発が進み…

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

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

  15. なにがダメだったか

  16. 失敗① スピンアップ Frameworkなし : Slim3 : Slim3 + Struts(仮) : Slim3

    + Struts(仮) + アプリ : 約2.5s 約3.3s(+800ms) 約5s (+1700ms) 約10s (+5000ms) 開発速度重視のため
  17. - NoSQLであるDatastoreを非正規化したRDBのような使い方 主要なKindで自動インクリメントするKeyを設定 - KeyでGetできないため、 シングルプロパティインデックス・カスタムインデックスを貼りまくる 失敗② テーブル設計

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

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

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

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

  22. 対応策

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

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

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

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

  27. - AppEngineの言語を  Java → Go に変更 - クライアントを JSP → Angular2系(SPA)に変更 -

    Datastoreの設計を見直し インデックス数が ゼロ に Memcacheのヒット率もキャッシュサイズも大幅アップ  - Serviceを分けてデプロイ。適切な  ディスパッチ を設定 バージョン2 スピンアップが約20msに サーバ処理時間は200ms以内に 基本構成 AppEngine / Datastore は変更せず
  28. None
  29. Googleからの取材(2回目) 2018年6月

  30. None
  31. - うまく動作しない、性能が出ないのは、 だいたいクラウドサービス側よりもアプリ側に原因がある場合が多い - 現在は、AppEngine にも 2nd Gen が登場し、 いろいろと過渡期のため、機能要件に応じて適切なプロダクトを

    選択していく必要がある - クラウドサービスならではのベストプラクティスやハマりどころ が存在するため、Slackとかで雑に質問してみると良いかも - なんにしても口座へのダメージ回避が最優先(性能改善にも繋がる) まとめ
  32. None
  33. ありがとうございました