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
組織とプロダクトの変化に合わせたクラウド選択 / Henry Engineer Meetup #5
Search
nabeo
February 12, 2026
Technology
84
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
組織とプロダクトの変化に合わせたクラウド選択 / Henry Engineer Meetup #5
https://henry.connpass.com/event/381632/
nabeo
February 12, 2026
More Decks by nabeo
See All by nabeo
kotlin-lsp の開発開始に触発されて、Emacs で Kotlin 開発に挑戦した記録 / kotlin‑lsp as a Catalyst: My Journey to Kotlin Development in Emacs
nabeo
3
1.1k
SRE 文化の醸成: stream-aligned チームに Enabling するために実施した事例の解説 / Cloud Operator Days Tokyo 2025
nabeo
0
300
kotlin-lsp を Emacs で使えるようにしてみた / use kotlin-lsp in Emacs
nabeo
0
510
Docker Compose で手軽に手元環境を実現する / Simplifying Local Environments with Docker Compose #CinemaDeLT
nabeo
0
630
OpenTelemetry Collector 自身のモニタリング / Monitoring the OpenTelemetry Collector itself
nabeo
0
630
ヘンリーにおける可観測性獲得への取り組み
nabeo
2
2.4k
AWS CDK (TypeScript) を継続的にメンテ可能にするために取り入れているノウハウ集
nabeo
0
1.4k
AWS Organizations 組織を移動する時に 考えること 100 連発 (AWS Control Tower への組み込みを添えて) / Hatena Engineer Seminar #20
nabeo
2
3.5k
AWS Transit Gateway を使った内部ネットワークの構成変更の話 / AWS Transit Gateway and Me
nabeo
0
790
Other Decks in Technology
See All in Technology
元銀行員がAIだけでアプリを量産!「バイブコーディング実演セミナー 」
tatsuya1970
0
110
コミットの「なぜ」を読む
ota1022
0
120
Kiro Ambassador を目指す話
k_adachi_01
0
130
本当の”仕事”を手放せる未来が見えた
mu7889yoon
0
130
【FinOps】データドリブンな意思決定を目指して
z63d
0
330
Multi-Agent並列開発を 安全に回すための技術 / Technology for Safely Multi-Agent Parallel Development
tooppoo
0
170
事業会社における 機械学習・推薦システム技術の活用事例と必要な能力 / ml-recsys-in-layerx-wantedly-2026
yuya4
0
160
When Platform Engineering Meets GenAI
sucitw
0
170
いまさら聞けない「仕様駆動開発入門」 〜AI活用時代の開発プロセスを考える〜
findy_eventslides
2
200
4人目のSREはAgent
tanimuyk
0
160
Agile and AI Redmine Japan 2026
hiranabe
4
480
元・セキュリティ学習経験0大学生による業務紹介 / An Introduction to the Job by a Former College Student with Zero Security Training Experience
nttcom
0
100
Featured
See All Featured
Designing for Timeless Needs
cassininazir
1
260
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
370
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
32
3.5k
Design in an AI World
tapps
1
250
4 Signs Your Business is Dying
shpigford
187
22k
Raft: Consensus for Rubyists
vanstee
141
7.6k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
How to Talk to Developers About Accessibility
jct
2
250
Navigating Team Friction
lara
192
16k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
65
56k
SEO for Brand Visibility & Recognition
aleyda
0
4.6k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.5k
Transcript
Copyright © Henry, Inc. All rights reserved. 組織とプロダクトの変化に 合わせたクラウド選択 株式会社ヘンリー
SRE 渡辺 道和 (nabeo) Henry Engineer Meetup #5 1
Copyright © Henry, Inc. All rights reserved. • 渡辺道和 a.k.a.
nabeo ◦ 2023年6月にヘンリーに SRE としてジョ イン ◦ 元々はオンプレのインフラエンジニアだっ たけど、徐々にクラウドシフトした ◦ 好きな AWS サービスは AWS Transit Gateway X: @nabeo Blog: https://nabeop.hatenablog.com/ 自己紹介 2
Copyright © Henry, Inc. All rights reserved. 準備はいいですか? 3
Copyright © Henry, Inc. All rights reserved. かんぱーーーーい!!! 🍻 4
Copyright © Henry, Inc. All rights reserved. 1. Google Cloud
を選択した背景 2. AWS への変更を決断した背景 3. まとめ 5 今日の話題 : なぜ AWS 移設をするのか?
Copyright © Henry, Inc. All rights reserved. 会社紹介資料: https://speakerdeck.com/henryofficial/company-deck-for-engineer?slide=5 6
株式会社ヘンリーと Henry
Copyright © Henry, Inc. All rights reserved. 7 Google Cloud
を選択した背景 2019年から2020年の話
Copyright © Henry, Inc. All rights reserved. • クリニック (診療所)
向けのレセコン一体型電子カルテを SaaS でつくる • バックエンドで Server-Side Kotlin を使うことは決定していた ◦ Null 安全性: 医療機関でのワークフローの途中状態としてデータの欠損が想定される ◦ 複雑なドメインを表現できる ◦ 初期開発メンバーは JVM 言語を扱い慣れていた • 開発メンバーは数人で、フルコミットのインフラ担当はいなかった ◦ 開発メンバーも何かしらの本業を持っていた状態だったが、高速でサービスを立ち上げる必 要があった 8 Henry 開発開始当時の状況
Copyright © Henry, Inc. All rights reserved. • 最初は AWS
(EKS) が検討されていたが、Cloud Run が GA したあとに方針 が変わった • コンテナの実行基盤を Cloud Run としたことでクラウドプラットフォームも AWS から Google Cloud に変わった ◦ インフラ担当がいない少数の開発チームが高速にサービスを立ち上げるという意味では Google Cloud という選択は正解だったと思う ◦ 1人目のフルタイム SRE がジョインしたあともインフラ部分の運用負荷が低いので、サービ スの信頼性や開発生産性向上のために工数を割くことができた 9 Google Cloud という選択
Copyright © Henry, Inc. All rights reserved. 10 AWS への変更を決断した背景
組織と対象医療機関の変化
Copyright © Henry, Inc. All rights reserved. • 開発開始当初から組織規模は大きく変化した ◦
2026年時点でフルタイムのエンジニアは40人以上在籍している ◦ AWS に知見が深いエンジニアも多い • 採用市場を見渡しても、AWS 経験者は多い ◦ 試しに、エンジニア向け転職サービスで経験職種を SRE にしたときにキーワード検索をする (2026年2月時点) ▪ AWS: 約500名 ▪ Google Cloud: 約250名 組織規模の変化 11
Copyright © Henry, Inc. All rights reserved. • 病院では外来に加えて入院に伴うワークフローが追加される ◦
可観測性: 機能としての複雑性が格段に向上する ◦ 信頼性: 日中帯以外での利用が増える 12 クリニック向けから病院向けへの変換
Copyright © Henry, Inc. All rights reserved. • インフラの抽象度が異なる ◦
Google Cloud はインフラレイヤーが高度に抽象化されているため、サービスの開発に集中で きる ▪ 例) 単純な Web サービスだと Cloud Run だけで十分 ◦ AWS はインフラレイヤーの抽象度が低いが、コントロールできる範囲が広い ▪ 例) Web サービスを構築する時は ALB/NLB と ECS が必要になる • インフラの抽象度はユーザがコントロールできる範囲に関係する 運用工数は上がるが、信頼性確保という観点で AWS を選択することにした 13 インフラ視点での Google Cloud と AWS の違い
Copyright © Henry, Inc. All rights reserved. • Henry のバックエンドは
Server-Side Kotlin を採用している ◦ サービス特性と Kotlin は相性が良い ◦ Kotlin を docker コンテナでうごかすとしたら :thinking_face: • Kotlin (JVM) は起動が遅い ◦ Cloud Run は起動レイテンシーを10秒に納める必要があった (今は違うらしい) ◦ Cloud Run のスケールアウト時の特性と相性が悪い ▪ 余裕を持ったパラメータ設定にしておいて、急激なスケールアウトを抑制している 起動レイテンシーなど不利な部分をインフラ部分でのコントロールで補う 14 Kotlin アプリケーションとの相性
Copyright © Henry, Inc. All rights reserved. 15 まとめ
Copyright © Henry, Inc. All rights reserved. • 何を求めるかで最適なクラウドプラットフォームは異なってくる ◦
Google Cloud はサービスの開発に集中できる ◦ AWS は細かい制御が可能 • 必要に応じて最適なプラットフォームに移動できることが理想 ◦ とはいえ、今回みたいなことは今のフェーズだからできる 16 全てのケースで最適なクラウドプラットフォームは存在しない
Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報 採用募集ページ
募集中の採用ポジションや募集要項 がご確認いただけます。 オープンポジションのカジュアル面 談も募集していますので、お気軽に お申し込みください。 技術ブログ はてなブログ ヘンリー製品開発チームが運営する 技術ブログです。 会社公式ブログ note ヘンリーで働く人や医療業界や事業 のことが幅広くしれる公式ブログで す。 CEO の逆瀬川も個人で NOTE を発 信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届 けするポッドキャストです。 17