Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
GAE/Jで盛大に失敗する方法
Search
mmorito
October 28, 2018
Programming
0
580
GAE/Jで盛大に失敗する方法
mmorito
October 28, 2018
Tweet
Share
More Decks by mmorito
See All by mmorito
Road to SRE NEXT@広島
mmorito
0
270
Google Cloud によるDICOM管理
mmorito
0
48
JBUG広島#11
mmorito
0
380
データ分析やAIの "運用" について考える
mmorito
0
460
JP_Stripes in Setouchi #01
mmorito
0
160
Cloud Native Kansai #01
mmorito
0
1.2k
Cloud Native Sapporo #01
mmorito
0
410
自社サービスにStripeを導入する話
mmorito
1
820
Introduction of Firebase
mmorito
0
980
Other Decks in Programming
See All in Programming
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
540
GraphRAGの仕組みまるわかり
tosuri13
8
490
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
230
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
110
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
110
童醫院敏捷轉型的實踐經驗
cclai999
0
200
NPOでのDevinの活用
codeforeveryone
0
420
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
500
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
110
既存デザインを変更せずにタップ領域を広げる方法
tahia910
1
240
都市をデータで見るってこういうこと PLATEAU属性情報入門
nokonoko1203
1
570
生成AIコーディングとの向き合い方、AIと共創するという考え方 / How to deal with generative AI coding and the concept of co-creating with AI
seike460
PRO
1
330
Featured
See All Featured
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.8k
The Invisible Side of Design
smashingmag
300
51k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.3k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.5k
Building an army of robots
kneath
306
45k
Facilitating Awesome Meetings
lara
54
6.4k
How GitHub (no longer) Works
holman
314
140k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Optimizing for Happiness
mojombo
379
70k
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Transcript
GAE/Jで盛大に失敗する方法 GCPUG Okayama #11
森藤 敏之(もりとう) - @mmorito_0318 所属 - 株式会社エムネス - 遠隔画像診断センター - 医療支援サービス「LOOKREC」
イベント / 勉強会(担当) - GCPUG - 広島支部 organizer - Cloud Native Hiroshima
カープ優勝 おめでとうございます!
これは、GAE/J に魅了された者たちの物語です。 決してJavaを批判するものではないことをご理解ください。 はじめに
- サーバー: - データベース: - キャッシュ: - その他: Google App
Engine(Java) Datastore Memcache 魅了された者 登場人物
- GAEのJava7 Runtime が2019年1月16日にShatdownする - 弊社アプリケーションの完全移行が2018年11月までに完了予定 発表のきっかけ
背景
- 人口100万人あたりのCT/MRI 設置台数 日本はダントツで1位 CT units per million population OECD
Health at a Glance 2017 MRI units per million population
- 人口100万人あたりの放射線科医数 人口100万人あたりの 放射線科医数 日本はダントツで最下位 高額医療機器(CT/MR)と放射線科医の数
- データの保存や移行に莫大な時間とお金がかかる - 超高額で囲い込みの激しい医療業界の常識を撤廃 - 深刻な医師不足を解消するためのネットワーク作り - 機械学習などのIT技術を用いて、医療をサポートしたい クラウドへ移行する決意 Google
Cloud Platform 上で構築へ いつでも、どこでも、だれにでも高品質な医療を提供する
None
順調に開発が進み…
Googleからの取材 2014年8月
あれから2年.... 我々はアプリのリプレイスを余儀なくされる。
なにがダメだったか
失敗① スピンアップ Frameworkなし : Slim3 : Slim3 + Struts(仮) : Slim3
+ Struts(仮) + アプリ : 約2.5s 約3.3s(+800ms) 約5s (+1700ms) 約10s (+5000ms) 開発速度重視のため
- NoSQLであるDatastoreを非正規化したRDBのような使い方 主要なKindで自動インクリメントするKeyを設定 - KeyでGetできないため、 シングルプロパティインデックス・カスタムインデックスを貼りまくる 失敗② テーブル設計
- Queryでデータ取得することによる弊害 - Memcacheに載らない - トランザクションに引っかからない - Frameworkに搭載された禁断のインメモリフィルタに手を出す ※多めに取得してクライアントに返したいデータ以外を 捨てる
失敗② テーブル設計
- JSPの結果を返すリクエストがコンスタントに1秒を超えるようになる 失敗③ レスポンス
- 一方でAjaxを使い、signedURLを数百単位で要求してくるリクエストなど もあるが、スケールの恩恵を受けづらくなる 失敗③ レスポンス
- 軽い気持ちで30分毎に直近500件のデータを検索し、 他のテーブルに情報を更新する処理をCronジョブで実行 番外編 バッチ処理 翌月の請求額が 40万円UP↑↑
対応策
- インスタンスタイプを F1 → F2 へスケールアップ 愚策① チューニング - インスタンスが落ちるまでの時間を 最大(15秒)に設定 スピンアップやJavaのクラスロードに直面する リクエストを極力減らし、1秒でも速く処理させるため.....
- Memcache を 共有 → 1GB専有 に変更 愚策② キャッシュ
- アプリケーションを 単一Service → 複数Service にデプロイ 良策③ ディスパッチ 業務単位毎に別のServiceへルーティングを設定 (バッチ処理なども別Serviceへ)
そして、バージョン2開発へ
- AppEngineの言語を Java → Go に変更 - クライアントを JSP → Angular2系(SPA)に変更 -
Datastoreの設計を見直し インデックス数が ゼロ に Memcacheのヒット率もキャッシュサイズも大幅アップ - Serviceを分けてデプロイ。適切な ディスパッチ を設定 バージョン2 スピンアップが約20msに サーバ処理時間は200ms以内に 基本構成 AppEngine / Datastore は変更せず
None
Googleからの取材(2回目) 2018年6月
None
- うまく動作しない、性能が出ないのは、 だいたいクラウドサービス側よりもアプリ側に原因がある場合が多い - 現在は、AppEngine にも 2nd Gen が登場し、 いろいろと過渡期のため、機能要件に応じて適切なプロダクトを
選択していく必要がある - クラウドサービスならではのベストプラクティスやハマりどころ が存在するため、Slackとかで雑に質問してみると良いかも - なんにしても口座へのダメージ回避が最優先(性能改善にも繋がる) まとめ
None
ありがとうございました