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

組織とプロダクトの変化に合わせたクラウド選択 / Henry Engineer Meetup #5

Avatar for nabeo nabeo
February 12, 2026

組織とプロダクトの変化に合わせたクラウド選択 / Henry Engineer Meetup #5

Avatar for nabeo

nabeo

February 12, 2026
Tweet

More Decks by nabeo

Other Decks in Technology

Transcript

  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
  2. Copyright © Henry, Inc. All rights reserved. 1. Google Cloud

    を選択した背景 2. AWS への変更を決断した背景 3. まとめ 5 今日の話題 : なぜ AWS 移設をするのか?
  3. Copyright © Henry, Inc. All rights reserved. 7 Google Cloud

    を選択した背景 2019年から2020年の話
  4. Copyright © Henry, Inc. All rights reserved. • クリニック (診療所)

    向けのレセコン一体型電子カルテを SaaS でつくる • バックエンドで Server-Side Kotlin を使うことは決定していた ◦ Null 安全性: 医療機関でのワークフローの途中状態としてデータの欠損が想定される ◦ 複雑なドメインを表現できる ◦ 初期開発メンバーは JVM 言語を扱い慣れていた • 開発メンバーは数人で、フルコミットのインフラ担当はいなかった ◦ 開発メンバーも何かしらの本業を持っていた状態だったが、高速でサービスを立ち上げる必 要があった 8 Henry 開発開始当時の状況
  5. Copyright © Henry, Inc. All rights reserved. • 最初は AWS

    (EKS) が検討されていたが、Cloud Run が GA したあとに方針 が変わった • コンテナの実行基盤を Cloud Run としたことでクラウドプラットフォームも AWS から Google Cloud に変わった ◦ インフラ担当がいない少数の開発チームが高速にサービスを立ち上げるという意味では Google Cloud という選択は正解だったと思う ◦ 1人目のフルタイム SRE がジョインしたあともインフラ部分の運用負荷が低いので、サービ スの信頼性や開発生産性向上のために工数を割くことができた 9 Google Cloud という選択
  6. Copyright © Henry, Inc. All rights reserved. • 開発開始当初から組織規模は大きく変化した ◦

    2026年時点でフルタイムのエンジニアは40人以上在籍している ◦ AWS に知見が深いエンジニアも多い • 採用市場を見渡しても、AWS 経験者は多い ◦ 試しに、エンジニア向け転職サービスで経験職種を SRE にしたときにキーワード検索をする (2026年2月時点) ▪ AWS: 約500名 ▪ Google Cloud: 約250名 組織規模の変化 11
  7. Copyright © Henry, Inc. All rights reserved. • 病院では外来に加えて入院に伴うワークフローが追加される ◦

    可観測性: 機能としての複雑性が格段に向上する ◦ 信頼性: 日中帯以外での利用が増える 12 クリニック向けから病院向けへの変換
  8. Copyright © Henry, Inc. All rights reserved. • インフラの抽象度が異なる ◦

    Google Cloud はインフラレイヤーが高度に抽象化されているため、サービスの開発に集中で きる ▪ 例) 単純な Web サービスだと Cloud Run だけで十分 ◦ AWS はインフラレイヤーの抽象度が低いが、コントロールできる範囲が広い ▪ 例) Web サービスを構築する時は ALB/NLB と ECS が必要になる • インフラの抽象度はユーザがコントロールできる範囲に関係する 運用工数は上がるが、信頼性確保という観点で AWS を選択することにした 13 インフラ視点での Google Cloud と AWS の違い
  9. Copyright © Henry, Inc. All rights reserved. • Henry のバックエンドは

    Server-Side Kotlin を採用している ◦ サービス特性と Kotlin は相性が良い ◦ Kotlin を docker コンテナでうごかすとしたら :thinking_face: • Kotlin (JVM) は起動が遅い ◦ Cloud Run は起動レイテンシーを10秒に納める必要があった (今は違うらしい) ◦ Cloud Run のスケールアウト時の特性と相性が悪い ▪ 余裕を持ったパラメータ設定にしておいて、急激なスケールアウトを抑制している 起動レイテンシーなど不利な部分をインフラ部分でのコントロールで補う 14 Kotlin アプリケーションとの相性
  10. Copyright © Henry, Inc. All rights reserved. • 何を求めるかで最適なクラウドプラットフォームは異なってくる ◦

    Google Cloud はサービスの開発に集中できる ◦ AWS は細かい制御が可能 • 必要に応じて最適なプラットフォームに移動できることが理想 ◦ とはいえ、今回みたいなことは今のフェーズだからできる 16 全てのケースで最適なクラウドプラットフォームは存在しない
  11. Copyright © Henry, Inc. All rights reserved. 採用情報や事業や技術について、積極的に発信しています! 採用情報 採用募集ページ

    募集中の採用ポジションや募集要項 がご確認いただけます。 オープンポジションのカジュアル面 談も募集していますので、お気軽に お申し込みください。 技術ブログ はてなブログ ヘンリー製品開発チームが運営する 技術ブログです。 会社公式ブログ note ヘンリーで働く人や医療業界や事業 のことが幅広くしれる公式ブログで す。 CEO の逆瀬川も個人で NOTE を発 信しているのでぜひ! 理想駆動ラジオ Spotify プロダクト開発・運営の様子をお届 けするポッドキャストです。 17