株式会社ヘンリーで SRE をやっている 
id:nabeop です。
今回は SRE チームが中心になって Henry のクラウド基盤を Google Cloud から AWS に移行しようとしているプロジェクトについて紹介します。
なぜ、クラウド基盤を移行するのか?
レセコン一体型電子カルテの Henry は開発当初からクラウド基盤として Google Cloud の Cloud Run や Cloud SQL を使っていました。Henry の開発当初はインフラ担当のエンジニアがいない状態でも少ない人数で最速でサービスを開発する必要があったため、インフラ部分が抽象化されている Google Cloud を選択するのはごく自然な選択だったと思います。
Henry の開発が進むにつれて、開発当初はクリニックを想定していましたが、回復期リハビリテーション病院や急性期のような複雑な機能が必要な医療機関での利用も想定されるようになりました。このように開発開始当初に想定していたよりも複雑な機能が求められつつ、高い信頼性が求められる医療機関さんへの導入を見据え、コンテナの実行基盤を Cloud Run から GKE など抽象化レベルが低く、我々がより細かいコントロールが可能なサービスへの移行についても検討はしました。しかし、Henry のサービス特性などを総合的に考えた結果、クラウド基盤として AWS が適切であると判断しました。
また、急性期の医療機関さんのように24時間/365日で高い稼働レベルを求められる医療機関さんが使い始めるまえにクラウド基盤そのものの移行というリスクの高いプロジェクトを完了しておきたいという背景もありました。
移行プロジェクトの現在地
Henry のアプリケーション部分は Docker コンテナで稼働しているため、クラウド基盤を変更しても全く動かないということはありません。しかし、Google Cloud と AWS では異なる部分もあるため移行を本格的に開始するにあたり下記のような検討を実施しました。
- Google Cloud で構築している内容と同等の構成を AWS で実現するにあたっての懸念点の整理と大まかなコストの試算
- PoC として Henry の最低限の機能を AWS 上で構築し、上記の懸念点以外に大きな見逃しがないかの確認
現在は、PoC 検証によって大きな見逃しはないものの、Google Cloud と AWS での機能差異や AWS では実現が難しい機能が存在することは確認できたので、これらのギャップを埋めるためのアプローチや不確実性の解消のための検証を実施しています。具体的には以下のような検証やアプローチの検討があります。
- Google Cloud (Cloud SQL for PostgreSQL) から AWS (Aurora for PostgreSQL) データマイグレーション時の手順と想定されるダウンタイムの予想
- アプリケーションの CI/CD パイプラインの作り直し
- AWS での置き換えが難しい機能を Google Cloud で維持するための手段の検討
- アプリケーションの移行手順の検討
- ECS サービスの構成の検討
今は上記の内容のうち、予想される不確実性のうちリスクが高いものや不確実性が大きいものを優先して検証しています。
Henry 本体の開発スケジュールとの兼ね合いはありますが、これらの課題を順次解決していき来年中には AWS への移行を完了させる見込みです。
we are hiring!!!
稼働済みのサービスのほぼ全ての機能でクラウドサービスの移行をするというのは今のタイミングでしかできない珍しい取り組みだと思います。また、AWS に移行したあとにも高い信頼性が求められる医療機関さんにも安心して使っていただけるように DR やセキュリティ周りの強化に踏み込んでいく予定です。
AWS 移行プロジェクトだけでなく、高い信頼性が求められる医療機関さんに安心してお使いいただけるシステムにしていくには、さまざまな課題を解決する必要があります。ヘンリーではこれらの課題を一緒に解決してくれる仲間を募集しています。
ヘンリーでの SRE の取り組みに興味をもたられたら、ぜひ気軽にカジュアル面談などでご説明させていただきたいです。
コメント